We make it simple.
|
[
Article
]
|
How to improve your chances of a successful software roll-out (Part 2)
(This is Part 2 of an article on a topic of some concern to most SME businesses. It can be read as a continuation of Part 1, or as a stand-alone piece. Click here to read Part 1.) Everyone needs to adjust their mental model. Computerization efforts are more likely to succeed if their implementers recognize and address a quite subtle problem, which is, that it's really hard to escape the clutches of an obsolete mental model. It's a subtle problem because we don't often question our mental models; in fact, we tend to see everything through the filter of our current paradigms, whether they're still valid or not. It takes quite a jolt to get us to change the way we view the world. Let's examine the work paradigm in non-computerized organizations. In non-computerized organizations, people are expected to do certain tasks - sales, or purchasing, or cashiering - and also document what they have done, through reports. Now, in a paper-based system, preparing reports usually takes much longer than the underlying tasks themselves; so organizations respond by batching their reporting. Salesmen will close sales and accumulate invoices all week, and then prepare a sales report on Friday. Warehouse people dutifully log inventory ins and outs, then prepare a stock-on-hand report on Friday. But when you batch your reporting like this, then you have a built-in delay between the basic action and your ability to see how that action affects the other moving parts of your organization. If you're seeing the consequences of your actions only after a one-week lag, then you can't react very swiftly or very well to issues that impact on your success - such as out-of-stock branches, or inventory build-up of obsolete products, or unhappy customers, or flawed merchandise receiving procedures. Most people - living through these situations day in and day out throughout entire careers - accept these delays as part of the natural state of things. Now, one of the most alluring promises of computerization is that the age-old pattern of doing-and-then-recording gets streamlined, thus improving process accuracy and process times. The computer speeds up the recording part of doing-and-recording. It reduces days-long or hours-long processes to mere minutes, so that the day-to-day work reality for most workers is transformed. They now have more time on their hands. Sales people can now spend a lot more of their time with customers, and far less of it shuffling paper. This increases your chances of making more sales and creating happier customers. Credit and collections folks can now spend more time doing credit investigation and dunning trade debtors, and zero time cobbling up receivables ageing reports or billing statements, because the computer does all that automatically. Everybody is now able to spend more of their workday doing real things in the physical world, and far less non-revenue time making reports. Everybody can now be more productive. But the shocking thing is, if you don't watch it, you'll reap none of these benefits. And companies have squandered this opportunity again and again. How? By clinging to the old batch-processing mental model even as they already have information technology solutions in place. This is not really surprising; people will instinctively continue to apply old patterns of thinking to new realities... until someone jolts them awake. Galileo learned this the hard way, when the Catholic Church threatened to barbecue him for suggesting that the planets do not revolve around Earth. So, similarly, prisoners of an obsolete mental model will tend to continue to batch-process their work, just as they've done all their working lives. And this is the danger point for the transition leader. This is when managers are in danger of losing control of the computerization effort. What's the danger here? The danger comes from the basic reality that businesses are repetitive cycles of processes. A trading company purchases stocks, replenishes its branches, sells merchandise, then purchases stocks again, and so on. In this environment, every worker 's output is needed by a co-worker further down the line; every worker needs someone else's output to do his job. This holds true for both blue-collar workers, who handle physical things, and knowledge workers, who handle information. Now, when software users input data at their own convenience, according to their own self-established deadlines, they in effect disregard downstream co-workers and processes that rely on their output. And this slows down crucial processes. It causes the company to take longer getting anything done. The company becomes less nimble than it could be. This creates unhappy customers and higher costs. For example, if sales are not being inputted on time, the computer will overstate inventory levels. The merchandise is already gone - sold - but the computer, unaware of recent sales, thinks the stock is still in the warehouse. And since inventory is consequently overstated in the reports, Purchasing will order insufficient quantities during the next buying cycle. And because the branches then end up getting too little inventory, stock-outs occur and the company loses sales.
When you slow down crucial processes, you tend to create unhappy customers and higher costs.
Let this happen a few times, and people all over the company start losing faith in the computer data, and in the software. "How can we believe the computer when it causes stock-outs? Something's wrong with the software!" And when people no longer believe the computer, the first thing they instinctively do is to start creating compensating mechanisms. They start creating freestanding islands of departmental data. Pretty soon the main departments are offering numbers from their own data hoard that competes, and often conflicts, with the computer data. Creating "independent" departmental data makes things worse, not better. Your problem is that now you have two or more sources of information; which one will you believe? What people who are already in this quagmire are likely to do is to consult both the computer and their own departmental data hoard. This alone consumes time. And what if the two data sources don't tally, which is likely? Why, they'll research the issue and resolve it somehow. Which takes up yet more time. There goes the speed you were hoping for from computerization; there goes the promise of "greater accuracy and clarity." At this point, you have lost the clarity that comes from having a single source of truth, because you lost your nerve at the first sign of trouble and allowed that second and third source of competing truth into the picture. Isn't this precisely the scourge of a manual system? At this point, the computerization effort has fallen back into the slimy embrace of a zombie resurrection of the old manual system. And at that point, you can conclude that the computerization project is in serious trouble. Sound familiar? How to avoid this fate? The implementers of computerization must internalize the following basic ideas, and communicate it to everyone in the company: 1. Maintaining the computer data must be subject to time discipline - specifically, strict intra-day deadlines for data-encoding. Workers should not be allowed to unilaterally choose when they will input data; instead, they should be required to input transactions within, say, 30 minutes of the occurrence of the underlying business event. Only when data is inputted in a disciplined, time-conscious way, can the data be counted on to be up-to-date, and therefore believable and reliable. 2. Strict intra-day deadlines aren't enough; you need to synchronize the strict deadlines throughout the company. However faithfully you observe them, intra-day deadlines are meaningless if you allow individual departments to set their own deadlines without regard for upstream and downstream departments. Rather, a computerization czar - the COO, ideally - must ensure that the deadline for each key activity consciously takes into account intermeshing deadlines for upstream and downstream key activities. Will you still be able to count on your data five years after roll-out? We stand by you. Since 1985.
Without time discipline, decisions that need a hard inventory figure - say, purchasing - would require a delicate and time-consuming back-and-forth between the parties involved before useful actions could be enacted. With a judiciously established deadline, there is clarity, there is no fuss, and the computer data can be counted on for serious decision-making. With high confidence in the completeness of the stock-on-hand data, the purchasing department can in turn start processing purchase orders by 6pm. It can then purchase the correct quantities needed to meet market demand - neither too much nor too little - and it can promise that all PO's will be out by, say, 12 noon of the following day. 3) Do not allow competing islands of information to coexist with the computer data. When users express skepticism about the data in the computer, fix the basic problem by addressing the cause; do not lose your nerve and give in to the easy but false solution of parallel data. In the above example, the way to eliminate vague data was to impose clear cut-off times (deadlines) on data inputting, and emphatically not to create supplementary freestanding data. The proper response was to make the single source of truth more reliable, not to allow competing and potentially conflicting sources of data into the company's information flow. 4) One sure way to doom a computerization effort is to delegate it to middle management. Senior executives with hidden agendas - or who merely lack enthusiasm - can easily undermine middle-manager types. To forestall this, the CEO or COO must be personally engaged with the computerization rollout. Nobody expects the top guy to be a computer expert; that's not what he's needed for. What he's needed for is, first, his deep understanding of the business, and second, the clout to knock (hard) heads together. Computerization projects often snag on obsolete procedures that lower-level people - focused on the little picture - insist on preserving. The top guy has the perspective and the authority to discard these obsolete behaviors. Nobody outranks the top guy; so the project can't be stonewalled by other senior types. Being engaged includes (a) showing through word and deed management's strong commitment to the computerization project, and (b) bringing to bear sufficient management authority to resolve certain disputes that are sure to arise in the course of the project. Computerizing a company is often a tricky, contentious process. Some people will oppose it out of fear of change, fear of loss of power, or from sincere convictions about alternative ways of doing things. Top management is the only entity strong enough to get the last word, and make it stick. -rsr (This is Part 2 of an article on a topic of some concern to most SME businesses. It can be read as a continuation of Part 1, or as a stand-alone piece. Click here to read Part 1.) Questions? Reactions? Write to balmori@balmorisoftware.com. |
New!
SURE! General Ledger Ver. 8 web-enabled variant is now available. Encode data or print reports from anywhere in the world (or through your workplace LAN). Click here for more. |