When you have been in the systems business for as long as I have, you have been afforded the opportunity to see a lot of things. I've been fortunate to meet many interesting people with some rather forward-thinking business ideas, but I have also met more than my fair share of deadheads. When you witness several system snafus, you learn to appreciate those systems that were successful and made a dramatic impact on business. Here are a few such stories from my travels:
The most interesting strategic system I saw was from an automotive parts manufacturer in the U.S. Midwest who was interested in increasing market share. To do so, they studied the operations of their customers, specifically independent auto parts outlets. Their study found one of the biggest headaches for outlets was in managing inventory. The parts manufacturer thereby devised a plan whereby they provided a free turnkey inventory system for their customers, complete with computer hardware. This greatly streamlined inventory for the outlets as well as simplifying purchase transactions. More importantly, the parts manufacturer was able to monitor inventory levels of the outlets which automatically triggered reorders as inventory levels got low (as opposed to waiting for the outlet to reorder parts). Further, the parts manufacturer was able to monitor sales trends and forecast production schedules. When sales volume slowed, sales promotions and advertising would be triggered to encourage business. All of this created a "win-win" situation for both the parts manufacturer and their customers. The customer got an easy-to-use and reliable inventory system for free, and the parts manufacturer, in turn, gained wider market share as more and more outlets bought into the system. Smart. Very smart. Now here is the kicker, this was done back in the 1970's, well before the general implementation of the Internet by business.
Contrast this with the introduction of bar-code scanners years ago to replace massive cash registers at checkout counters. As each item was scanned, you assumed inventory would be updated automatically and orders triggered when inventory levels became low. Perhaps today it is done in this manner but not so when scanners were first introduced. Instead of promoting a total order processing approach, computer manufacturers sold the scanners as nothing more than a time saver at the checkout counter. Scanners were considered revolutionary at the time, and the vendors didn't want to overwhelm the retailer with such a massive change. As an aside, I knew quite a few cashiers who could outperform the scanners using registers, and probably could still do so today.
The biggest systems development effort I ever saw was Japan's "BEST" project, which was sponsored by the Ministry of Finance and used our "PRIDE" products. As background, the ministry wanted to leapfrog the west in terms of banking systems. To do so, they assembled a team of over 200 analysts and programmers from four of the top trust banks in Japan. Through strong management, our methodologies, and some determined effort, over 70 major integrated systems were developed in less than three years. This resulted in a quantum improvement in banking service; for example, a customer could go into one bank and get a complete portfolio of all of his finances in all of the banks, not just one. Further, the customer could move money from one bank account to another in real-time. The systems devised back then became the foundation for future enhancements which are still implemented to this day. As a footnote, this project was implemented in the 1990's and, because the consortium had control over their information resources, the much feared Y2K problem never materialized.
From time to time our firm is contracted to investigate dysfunctional systems, those where the developers are stymied as to why they will not work. Occasionally, the reason for the malfunction can be complicated and difficult to detect, but more often than not the problem can be easily solved simply by having a different set of eyes to look at the problem. In one particular instance, we were contracted by a large manufacturing company in the northeast who was having trouble implementing their new shop-floor control system. The system was state-of-the-art in terms of programming and DBMS technology, but they simply couldn't get it to work no matter what they tried. Consequently, they called us out of frustration. Instead of studying source code, as the development staff had done, we began by mapping the overall system architecture. Inevitably, we came upon a sub-system whereby the computer displayed errors on the factory shop-floor requiring attention by the foreman. The foreman was to take the corrective action and respond to the computer accordingly. There was only one problem: nobody had told the foreman about any of this. We then wrote a simple administrative procedure (manual) for the foreman who then took the necessary actions and the system operated correctly thereafter ("miraculously" as our client said). This brings up an important point: systems will fail more for the lack of administrative procedures than for well programmed computer procedures. Although the manufacturing company had produced some rather elegant software, they had completely overlooked the man/machine interface.
In another situation, we were asked to perform a Project Audit for an insurance company in Wisconsin. Two system development projects were observed; Project "A" was executed smoothly and professionally. So much so, the project team wasn't recognized for their accomplishment, thereby creating a morale problem. Project "B" was the antithesis of "A" and went out of control almost from its inception. Remarkably the Project Manager and team leaders of Project "B" were well recognized and often complimented for their ability to put out fires during the project. We made note of this in our Audit report but went on to say that the only problem with rewarding their "fire fighters" was they also happened to be the company's chief arsonists. Whereas the "fire fighters" were recognized for screwing up, the Project "A" team went virtually unnoticed for doing a good job. In other words, our report revealed shortcomings in how people were rewarded in the company. The squeaky wheel was obviously getting more than its share of the oil, undeservedly so.
I am frequently asked what the secret to success is in building information systems. Is it a specific programming language or tool? The latest widget or gizmo? Perhaps some new technique promising instant results at significantly low costs? Frankly, it is none of this. It's a simple matter of sticking to the basics: get organized, lay out a road map, demonstrate some leadership, and show some discipline and perseverance. I found all of the major systems that were successful exhibited some commonality: the developers all did their up-front work planning and designing their systems before programming, they maintained a good rapport with the people who would use the system, and they always considered the human element in their designs. In terms of system snafus, the common denominator was simply rushing off to programming before understanding the problem, just the antithesis of the successful companies.
Visiting companies around the world over the years has been a great adventure. It's not exactly swashbuckling, but it sure has been an interesting ride.
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. Bryce & Associates (MBA) 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:
http://www.phmainstreet.com/timbryce.htm
Like the article? TELL A FRIEND.
Copyright © 2012 by Tim Bryce. All rights reserved.
No comments:
Post a Comment