As a systems man with over thirty years of experience, I always enjoy hearing embarrassing snafus costing millions of dollars. It is like reading a mystery thriller to discover "whodunit." In the systems field it is typically a matter of bad planning, bad designs, lack of documentation, and poor project management resulting in overruns and slipped schedules; it can also be caused when the system implementation (aka, "start-up") backfires. As to the latter, a doctor friend of mine recently told me about his experience with a new system at a local hospital. You may remember me briefly discussing this earlier, "Turning Everyone Into Data Entry Clerks." It's been three months since then, and my doctor friend brought me up to date regarding the massive system, which was used to accommodate all of the administrative needs of a hospital and intended to satisfy government requirements for managing patient records. Not surprising, the system appears to be designed more for the needs of bureaucrats as opposed to medical workers.
The system is a comprehensive soup-to-nuts approach for hospital administration. It is a "packaged solution" which means you are buying into another person's interpretation of the problem which may or may not be the same as yours. Nonetheless, the system has been installed in other hospitals and tweaked to suit their particular nuances. It is a PC based client/server system and although it can be accessed remotely, it is not done so through a web browser. There is, of course, a login and password procedure which dictates access privileges, thereby prohibiting people from unauthorized use of the system.
There were two approaches for implementing the system, either phased in as a series of stages, or all at once. For some unknown reason, the hospital opted to use the brute force approach and ram it all in on a single start-up date in February. I believe the date will best be remembered as "bedlam" and it is interesting to see what went right and what went wrong.
Prior to the installation, there was a massive amount of training required to use the system. Some doctors and nurses took the training seriously, but others checked in and out of the classroom simply to get the credit. Regardless of how well the students studied, everybody experienced different levels of confusion as the system started up. Although is is very sophisticated in terms of its capabilities, the system is not intuitive to use and was obviously programmed more from a technician's perspective as opposed to a medical worker. For example, there were no design standards implemented which are normally intended to simplify the "look and feel" of the system thereby making it easier to learn and use.
To assist in the initial start-up, a team of 100 geeks were stationed in a meeting room for two weeks where it came to resemble "Mission Control" in Houston. During start-up, it wasn't uncommon to see 15 geeks at a time in front of a computer screen with a blank perplexed look about them. They neither exuded confidence about the system or communicated well with the medical staff.
Physicians and nurses complained about the rudimentary nature of the training. For example, there was no "hands-on" training whatsoever, nor was there any documentation such as manuals, reference cards, or even Help text. The system made extensive use of keywords, but unfortunately there was no reference materials to look up the proper codes which, again, were not intuitive. For example, instead of "Admit" (a patient), the proper keyword was "Register As" (???).
Even the most well trained medical personnel stumbled through system start-up. Not surprising, three months later, many are still learning it. So much so, nurses are spending more time on computers and substantially less time treating patients. According to my doctor friend, whereas it used to take him three hours to visit and treat twelve patients, under the new system, it now takes him nine hours to perform the same task. This is obviously a quantum leap backwards in terms of productivity. There was also a computer crash one night causing doctors to revert back to paper charts as opposed to waiting for the system. The harsh reality is that all of the medical providers are being held hostage to the system, thereby causing a significant decline in patient care.
Despite all of this, management appears to be satisfied with the system which is somewhat typical for companies and systems of this size. This is probably because they are not intimate with how the system works and how the medical staff likes the system. A simple survey of user satisfaction may prove enlightening to management.
Basically, the vendor botched the training and implementation of the system thereby nearly grasping defeat from the jaws of victory. So what could they have done better; what were the lessons learned from this experience?
First, the system should have been designed according to industry standards, not just the whims and peculiarities of the vendor, thereby making it easier to learn and use, not to mention more intuitive. For example, if the F1 key is the generally accepted standard to access Help text, provide an F1 Help key. If people understand "copy" and "paste" from a clipboard, be sure to give it to them.
Second, design the system with the end user in mind, not the programmer who will only do what is technically elegant as opposed to practical. To do so, involve the end user DURING design, not afterwards when it is too late and costly to make corrections. Designers should worry more about ergonomics and less about the technical details of the computer. Just remember, an elegant solution to the wrong problem solves nothing.
Third, provide suitable documentation, something the end user will comprehend and find useful, not some technical mumbo-jumbo. A user manual with overviews, step-by-step instructions, task lists, examples, and indices are extremely useful. Better yet, provide it all online in the form of Help text. In other words, have the answers for all of their questions at their fingertips.
Some would say the problems experienced with this system are unique to the medical community. This is simply not so, as you can find system snafus like this in any field. The medical community certainly doesn't hold a monopoly over such problems.
As I said, I have loved reading about system snafus over the years. Interestingly, the system start-up problems being experienced in the 21st century are no different than those experienced in the 20th. However, you would think we would have learned a thing or two over the years. Evidently we haven't.
P.S. - See my paper, "Evaluating Purchased Packages," for selection guidelines.
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