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?
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
- 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
- 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
- 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.
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
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.
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.
© Copyright May 1994, UNISPHERE Magazine
P.O. Box 740908, Dallas, TX 75374-0908
Reprinted with permission. All rights reserved.
Free subscription information available upon request.