So What Makes You Think it Ain't Broke ?

So What Makes You Think
It Ain't Broke ?
Why you should do Business Process Re-engineering
by Melissa Fender

So, you're a successful MIS manager and everything is OK in your shop. Your systems work, at least most of the time. You're operating within your (meager) budget and your staff is generally happy and productive. Am I right so far?

Every magazine you read has two or more articles on client/server computing. It's clearly the way to go. GUIs are great; PCs promote productivity. There just have to be all sorts of packages out there that will revamp your old applications and make them look all shiny and new. You'll be a hero and you might even get a budget increase.

Well, wake up and grab Toto quick; Kansas is a long way off! You can't just leap into client/server and save the world. In fact, the best thing about client/server is that it gives you an opportunity to look at all of your application systems, and assess whether they're really doing what they should.

"Of course they're doing what they should!" you scream. "If they didn't, I'd know." Not so fast. Maybe your systems are not doing what they should. They might not even be close. But how can you tell?

Take This Test!

How many of the following common situations do you recognize? (My explanations for bizarre scenarios, and some just cynical comments appear in italics.)

The users don't ask for changes; they're completely satisfied. Perhaps they have finally quit trying.
The users never stop asking for changes; they're never satisfied. Are they just trying to reduce the number of "work-arounds" it takes to do their jobs?
The users ask for things that have been available for some time. Don't they ever read the memos and manuals you distribute?
When you send staff to help user departments, do they return shaking their heads, saying "They don't understand how to use 'The System'."
When the most productive/creative person in a user department goes on vacation, does havoc occur because no one else understands how to do the job?
Do the two most systems-knowledgeable people in a user department always take vacations at different times by choice, rather than by policy? Do you know who they are? Remember, the most knowledgeable people aren't usually the highest ranking.
You overhear some folks from purchasing comment that the 3-ring binder and Post-it note expenditures are rising at an alarming rate. Then you discover it's your users who are ordering them. The binders store the manual "Personal Databases" needed to keep the business running. The Post-it notes are often used to attach notes to paper forms. These forms are filed away and frequently referenced - another type of manual database.
How frequently does your organization see errors such as duplicate purchase order or credit memo numbers? This happens because some system doesn't assign these numbers or even track them! People have to do it manually, and then keep track of the numbers (in those 3-ring binders)!
You wander into a user department to talk about a report change that you're planning, and discover that they have bought PCs or software and didn't ask for your help. Did they think that you wouldn't help them?
Has the MIS staff ever "helped" a user save time by automating some manual process exactly as it was being done? Might you have automated something that shouldn't be done in the first place? This is how old work-arounds get institutionalized in software.
Is the user response to the announcement of a new version of the system an anxious "What have you changed?" Even worse, perhaps, a bored "Oh, really?" Is there a look of fear? They're probably starting to think about what new work-arounds they'll have to come up with!
If you have a meeting with users, who does the talking? Apart from low mutters about "outsourcing," do they say anything? Do your words bounce around the room and land on the floor with a dull thud? Is the meeting time spent selling your ideas to them so you can pretend that it's what they wanted all along? Do you assume their silence means agreement?
Have your users ever asked you for anything that you just agreed to w ith a "yes" and not a "yes, but ...?" Be honest. Many business people think of the MIS staff as "the yes-but guys."
If you run some sort of help desk or similar support function, are the support technicians getting questions about software or PCs and other equipment that they (and you) don't know anything about? Are your users having more positive experiences with technology on their home PCs on weekends than they are in their offices every day? Try changing one of your favorite reports by adding a column of numbers that doesn't add up. Does anybody call to let you know? Does anybody care? Or do they just accept it as another MIS effort unconnected with reality?
Is there a huge gap between what people know that the company did and what the systems report? Does anyone really trust the system? Be honest! For example, in production scheduling, do they believe forecasts, inventory levels and order history, or do they simply produce to match last year's sales?
Do your systems record data rather than track or analyze it? Have you ever seen ripped-up copies of MIS reports in executive trash cans? They appear next to the empty bottles of Mylanta that support executive "gut-feelings."
A business consultant has appeared in a one of your user's departments, and is making recommendations about information systems. You didn't even know the consultant was coming!
Do your user departments play games with their budgets to get the job done on their own - buying PCs, software, services, etc?
Is your annual budget allocated with little or no participation from you? Are your requests for budget increases refused, often with a shake of the head and a comment about money disappearing into the MIS black hole? Did you ever try asking your user departments to share their budgets with you to finance MIS projects? If they say "no," you'll at least know what they really think of you.
When people leave the company, do they talk about what is wrong with the way things get done? Try asking the Human Resources (HR) department to help evaluate how much the level of frustration with systems processes contributes to low morale, or even employee turnover. HR might even be willing to add this to the exit interview process.
Does the company employment agency always seem to send a new temporary employee, usually younger and "less trainable" than the l ast? Do they never voluntarily return because the environment is so stressful?
Do your customers or your sales staff complain that it's difficult to do business with your company? Do your orders go out on time with no surprises? Are invoices sent to the right address and person? Are they accurate and understandable? Ask your sales staff what they think - then, ask your credit department.
Your company announces a major decision -- an acquisition, merger or sale -- and you didn't know a thing about it. You investigate where reports have to go to now. Maybe you should really be investigating why executive management thinks that MIS shouldn't be part of the strategic planning process.
Your company announces a major reorganization. MIS continues to report in to the CFO, though indirectly. It's clear that MIS remains outside any strategic planning process. Did you think that ensuring good response time was your strategic contribution? If so, it's clear why you're outside the process!

Why Reorganizations Fail
Speaking of reorganizations, let's discuss that topic briefly before we consider the results of the quiz. Usually, reorganizations waste everyone's time. They lead to complaints, frustration and delays for employees and customers alike; they usually do not produce the expected results. Mostly, they lead to more reorganizations.

Reorganizations don't work because they address the people and not the processes -- but the people are not what is "broken." Most people work long and hard to do their jobs. They try to "work smart." But when the processes don't support what they're trying to do, they can't work efficiently -- no matter how hard they try. They lose most of their time detouring the places where the system disconnects with what they actually need to do. Consider the tremendous waste of time and creative energy here -- energy that could be applied to improving the business.

Reorganizations try to integrate new roles and responsibilities with old systems and processes. Most reorganizations don't do the one thing they must do to be successful: they don't examine the changes in business processes necessary to support the new structure. Reorganization plans rarely consider the process changes, much less document how to put them in place alongside the new structure.

Now back to the quiz. Count the situations you recognized. (You should find at least. If you didn't, contact me, and describe your situation.) All MIS managers should reexamine the business goals regularly and decide how well MIS is supporting them. It is a daunting task. No one said it's easy, just worthwhile. Since the toughest part of anything is getting started, let me give you some pointers on that.

Getting Started
First, make a quick assessment. What are the most obvious issues? They might be symptoms of major structural problems that will require serious system redesign. If you're lucky, they may be simple problems you can mend fairly easily.

Second, don't buy anything. Resist the temptation to rush out and acquire tools, new systems, application generators, etc. in hopes that they will simplify or accelerate the solution. All that will do is convince the users that MIS is about to waste more money and still deliver nothing. Tools won't mend the processes; only people can do that.

Third, see the company through the eyes of your users. Get as close as you can to living and breathing what they do. Learn what they need from MIS. The only way to come close here is to get the users to tell you. The problem is, they might not tell you. Often, they'll talk to an outsider who has no "axe to grind," but not to MIS. They might talk to you, but tell you what they think you want to hear rather than what is real.

Fourth, get some qualified help from outside the company. You are allowed to hire a consultant at this point who can help you throughout the process. This process can be scary if you've not done it before, and more so if you have. You can't do it in a day, or even a week. Having someone else point the way allows you to keep running the department and still participate in the analysis.

Business Process Re-engineering
You must understand the business goals of the company -- the needs of the business. It helps to know the strategic plans and what management sees as its priorities. Where are the real profits coming from? Which parts of the business are less profitable or not profitable and why? What kinds of information does management need to help it decide what to do? Can MIS provide any of it, directly or indirectly, better than it does now?

To accomplish your goal, you must get broad support from both departmental users and executive management. They'll need to take time away from their normal activities to help you. To obtain that level of cooperation you must show both groups that you mean what you say and that you can achieve benefits for them.

So, the next step is to build credibility. The easiest and best way is by accomplishing a "quick-fix." Implementing users' suggestions to improve the help desk function is one good idea. How traumatic would it really be to let the accounts payable system generate supplier numbers, and store the last one used? Get the idea? Generally, find out something simple and quick that will make a difference to the people whose support you seek. Note that you need to do this without buying anything, so that the credit goes to you, not to the new purchase.

Having won the necessary support, your next step is to investigate and document the existing business processes. Assess the "disconnect discrepancy," or how far the systems stray from supporting the business properly. Focus on the strategic systems. If you improve those, you really add value to the business and its bottom line. Stick to line operations and anything that involves direct customer contact: orders, billing, manufacturing, inventory and distribution. Put payroll, pensions, accounting and other areas on the back burner for now.

Make sure you really understand the disconnects. Visit user departments and observe what they do. Watch what they write down and put in a binder or on a Post-it note; it's probably a workaround to a system deficiency. Check whether they must enter the same data more than once.

Building a Data Model
One of the most important things you need to do is build a corporate data model. The data model is, or should be, the foundation of all information in the corporation -- whether it's stored online or not -- and the basis for every process and system. Building a data model is not trivial. A basic mistake can cause applications to fall down or become unmaintainable years later. Again, consider getting some outside help with this.

Once you have a workable data model, document the business processes. Design and document the ones you want, understand the ones you have, and note the differences between them. You can eliminate some of those differences easily. Make the easy changes that will help your users and give you more credibility. The differences that remain are the grist for your re-engineering mill.

What you are going to build is a road map. It starts where you are now, and heads in the direction the company is trying to go. It has discrete steps that represent individual projects along the way. You need those steps because they are the only paving on the road; otherwise, you will become stuck in the mud.

Conclusion
A big advantage of this type of plan is that it clarifies where to begin. You start with the first project on the critical path. However, how you take the roadmap from blueprint to bricks and mortar is the big "M" -- methodology. That is a topic in its own right, and the subject of another article.

	*We appreciate your comments and observations. If you have questions or would like more information, please contact the author at:*
	Bluebird Enterprises Inc. 357 Beechwood Road Berwyn, PA 19312-1063 Telephone: 610-647-8662 Fax: 610-647-7796