Time and time again, clients do successfully get a system up and running and it runs well for quite some time. However, over time it will develop what is known as "management system decay". Management System Decay is simply a laxness that has developed over time from the initial implementation. This decay will usually occur in the following areas:
- Procedures and Policies concerning System
- Actual Data itself
- Security Features
- Administration of the overall System
The purpose of "auditing" these existing systems is not to degrade the users, but rather develop a plan bringing back the system to it's original efficiency or improving what is currently in place. It is a process of learning from others through the consultant.
Procedures and Policies Concerning Systems
Over time, the training regime will lesson, new users will come onboard and a more lax approach is likely to take place. This causes the system to decay in it's effectiveness. Let's take a look at an example.
Within a purchasing group, one of the clerks commented that the ships were not filling in the required information to source a part and this required them to query back to the ship to obtain the information or to make an "educated guess" as to what was required.
Upon examination, a few items were found that resulted in some recommendations to be followed. First and foremost, the end users onboard the vessels had no idea that Purchasing required the information that they were so loudly complaining about. There were simply no policy and procedure manuals for the end user. Secondly, the purchasing group did not voice their need for this information, which is a communication problem, as they figured it would be easier to get the information themselves rather than approach those who had the information.
Recommendations were put in place to develop policy and procedures manual covering the most common processes on board the vessel with respect to the system as well as a policy to require minimum information for these processes, otherwise they would not be honored.
Tight control over the data must be enforced at all times. This is the idea of the "database administrator" whose sole function with respect to the system is to ensure that the data contained in the system reflects the needs and desires of the organization. On all too many occasions, when looking at data, we will find cases where the same part is listed in six different areas as somebody thought this was convenient and they had the system privileges to add the data there.
This is a decay of the usefulness of the data, as you cannot develop information from these separate (but same) data elements. This "excess of data" is almost as bad as a "shortage of data". Shortages occur when not enough data has been put into the system to reach "critical mass". This causes the end users not to use the system, as the required information simply does not exist.
Users should have access to the items which they need to perform to do their jobs. Too many privileges can be harmful, as users tend to snoop and "try out" new things which are out of bounds. Conversely, too few privileges can be harmful as well. Once again, security is tied back to the policies and procedures that need to be in place.
Administration of Overall System
When one looks at the replication of database and the communication schedule that is in place with the ships, you will see in many cases different approaches that can be taken to maximize the architecture of the system and provide your users with the timeliest data possible.
One of the most common areas were findings are made is with respect to the preservation of data from a purely technical standpoint. Is the data being backed up? What is the recovery plan? How many of failsafe avenues should we have? What maintenance routines are we running and why?