- It's actually not too difficult to spot weaknesses in your systems.
Our company has been conducting Systems Audits for a number of years, and by this, I do not mean analyzing computer hardware and software but, rather, the information systems used throughout a corporation, such as a manufacturing system, a finance system, a billing system, etc. It's actually not too difficult to find deficiencies in a system. If you've done it as long as we have, it becomes rather routine. We've encountered systems that couldn't accommodate foreign languages and local nuances, systems that were difficult to port across different computing environments, and systems that were plain and simply awkward to understand and use ("user nasty" as opposed to "user friendly").
When we begin an audit, we're not so much interested in the programming languages used and other issues pertaining to technology. These may be mildly interesting, but we're more interested in the business problem to be solved and the parts of the organization served. In particular, there are three areas we concentrate on:
1. Documentation - as used in recording design specifications and as an operations manual. As a design tool, there should be sufficient documentation to describe the system architecture and its various components, e.g., inputs, outputs, and files. Unfortunately, this is an area which is typically neglected, if not abandoned altogether. There should be no excuse for this as there have been a multitude of documentation aids available (both graphics and text) for over 35 years, not to mention simple paper and pencil (anybody remember plastic templates?). There is simply no excuse for operating without such tools. It is impossible to maintain your systems without adequate documentation and, consequently, the systems will need to be replaced in its entirety in a short period of time (two to three years at most). Further, "firefighting" becomes the normal mode of operation in the Information Technology department.
From an operations perspective, there should be sufficient documentation to provide instruction in how to use the system, such as administrative procedures, samples of inputs and outputs, and operations considerations, such as backup and recovery. Unfortunately, this is an area that is also neglected. Even simple help text is often omitted or inconsistently applied. Without sufficient instructional materials, the system will be underutilized at best.
2. Lack of data integration - the only way systems communicate internally or externally with other systems is through shared data. Failure to design systems without such integration means it is possible for different systems to produce different calculations, such as inconsistent sales figures. It also leads to...
3. Data redundancy - which is common within most companies today. Although data dictionaries and Data Base Management Systems (DBMS) were deliberately designed to help prevent data redundancy and promote data integration, it is easy to create redundancy if one is so inclined. This is what happens when a DBMS is used as nothing more than a data access method as opposed to what the tool was designed for (sharing).
To determine if any data redundancy exists, we begin by searching on some key data elements as used by the company, such as Customer Number, Product Number, Part Number, Employee Number, etc. These are high profile data elements which will lead to the identification of duplicates, inconsistent data definitions (e.g., length, Validation rules, etc.), and locate data dependencies (those elements bound to the key item). From this, we can quickly determine the number of duplicate data assignments and if systems are sharing data. As an aside, I have yet to find an organization with only one definition for Customer Number.
If a company is inputting the same data element multiple times, there is no guarantee they are doing it in the same manner. If the data is inconsistent, how can we trust the information about such things as Customers, Products, Parts, Employees, etc.? The point is, we cannot which leads to considerable headaches within any company.
If data is assigned redundantly, it means there is also redundant work effort, if for no other reason than to input the duplicate data elements.
By studying these three variables (documentation, data integration, and data redundancy) we can find most of the problems with any information system. Try it yourself. If you encounter these variables, you probably do not trust the information you receive from your systems, your end-users likely have an adversarial relationship with the Information Technology department, and your development staff lacks uniform discipline and organization.
As I said, after you've examined a few systems over the years, it becomes rather easy to spot problems.
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com
For Tim's columns, see:
timbryce.com
Like the article? TELL A FRIEND.
Copyright © 2012 by Tim Bryce. All rights reserved.
No comments:
Post a Comment