- Hopefully not your programmers.
I have seen a lot of Information Systems in my lifetime. Most are rather simple if you take the time to study the problem, and create the logical design, then determine the most suitable physical implementation and develop the specifications for the software and manual steps. It's actually a rather simple process, regardless of the intricacies of the data involved.
Problems arise though when the critical front-end work is performed by programmers who are more in tune with technology than business. From their perspective, they see everything in terms of zeroes and ones, not in dollars and cents. Not surprising, they only think in terms of elegant technical solutions, not necessarily what is practical from a business perspective. Let me give you two stories to illustrate my point.
First, we had a large manufacturing customer who designed a new “state-of-the-art” shop-floor control system whereby they wanted to spot errors along the assembly line and then quickly correct the hiccup. From a software perspective, it was a well thought-out and elegant solution coupled with an integrated data base. There was just one problem; it didn’t work. Consequently, we were called in on a consulting basis to try and determine what was wrong. We carefully examined the architecture of the system overall, not just the software components, and quickly found the problem; Whenever an error occurred on the shop-floor, an error message was displayed on a computer screen for the shop-floor supervisor to act on. Unfortunately, nobody instructed the supervisor about the computer screen, the messages, or procedurally how to respond to them. We wrote a simple administrative procedure for the supervisor who then read and responded to the errors properly and the system ran perfectly.
The programmers of the system were thunderstruck as to how quickly we found the problem and devised such a simple solution. They were convinced something was wrong with the logic of the software and focused their energies there to find the problem. In contrast, we stepped back and looked at the overall system architecture and found the problem in the basic design of the system.
Then there is the story of how simple data calculations can upset systems. Les Matthies, the legendary Dean of Systems, was fond of telling this story:
According to Les, a widow one day received a bill in the mail that read:
FIRST NOTICE - You are in arrears in the amount of $0.00, please make restitution as soon as possible. Have a nice day.
"This is stupid," she thought to herself, and discarded the bill.
One month later, she received another bill from the same company:
SECOND NOTICE - You are in arrears in the amount of $0.00; to avoid problems, please make restitution as soon as possible.
Again, she thought this was silly and discarded the bill.
One month later, she received yet another bill from the same company:
THIRD AND FINAL NOTICE - You are in arrears in the amount of $0.00. If you do not make restitution as soon as possible, we will be forced to turn this matter over to our bill collectors.
Although she still thought it was ridiculous, the widow didn't want any trouble, nor did she want a blemish on her credit report. Consequently, she wrote a check to the company in the amount of $0.00.
"There, that should take care of the problem," or so she thought.
One month later, she received a form letter from the company:
Thank you for your recent payment of $0.00. However, you failed to pay the interest penalty of $0.00 ...
Although Les loved to tell this as a system parable, there are many instances of such miscalculations in corporate systems which ultimately drive end-users bananas, for two reasons; lack of adequate system testing, and because of the focus on programming as opposed to systems.
Whenever systems are designed by programmers, you will likely see:
* Poorly defined information requirements as programmers are not trained in how to study the actions and decisions of the business, only computing requirements.
* Superficial data definitions thereby resulting in erroneous information, not to mention considerable data redundancy.
* Lack of documentation defining the overall system architecture, just basic programming specifications.
* Insufficient design reviews and testing which leads to product defects thereby causing problems in quality.
* Project Management delays and cost overruns as many parts of the system have to be redeveloped due to the lack of the other elements mentioned herein.
To prove my point, ask your systems people to design a manually implemented system. If they cannot, they are programmers and should not be serving as a systems analyst. As I keep insisting, it is not that system design projects are complicated, it's because we have the wrong people trying to perform the task. As a perfect example, consider the recent Obamacare system which was delivered late, was fraught with bugs, and cost the taxpayers well over $600 million, an outrageous amount of money.
What this points out is there are significant differences between systems analysts and programmers. Their emphasis and interests are simply different. Whereas the analyst is more of a generalist who understands business, the programmer is rightfully more in tune with technical detail. One tends to be an extrovert, the other is an introvert. The interests and skill sets are simply different. It is difficult, if not impossible to do one, when you are a master of the other; they are that different.
To illustrate, we have always subscribed to the following formula:
Good Systems Design + Good Programming = Great Systems
Good Systems Design + Bad Programming = Good Systems (it may not be elegant, but it serves the business needs)
Bad Systems Design + Good Programming = Bad Systems
Bad Systems Design + Bad Programming = Chaos
The common denominator for success is "Good Systems Design" which happens to be an area most companies neglect. Consequently, programmers are asked to compensate for poor specifications.
"If we built bridges the same way we build systems in this country, this would be a nation run by ferryboats." - Bryce's Law
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 © 2014 by Tim Bryce. All rights reserved.
NEXT UP: OBAMA'S SCORECARD - An excellent representation of the president's record.
LAST TIME: SOME MORE CULTURAL CHANGES
- Strange things affecting our culture.
Listen to Tim on WJTN-AM (News Talk 1240) "The Town Square" with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern), and KIT-AM 1280 in Yakima, Washington
"The Morning News" with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim's channel on YouTube.
No comments:
Post a Comment