So it is time to ‘solve’ a business problem with a computer. (peculiar to say). This inevitably involves changes, in processes and tools. Something is uncomfortable and needs to be fixed, or some control needs to be added. Perhaps some data is not being captured and should be.
Lots of reasons to set about on this path. Let’s look at one: The automation of a manual administrative process.
Most companies have unique processes. It is the uniqueness of the things that a company makes or does that give it competitive edge. These processes need improvement and control. It is not these processes that I am talking about.
I want to focus on the other kind: the administrative process. Everything from booking a conference room to recording hours spent on a project is administrative. These processes need improvement as well, but they get very little attention. Usually some tool is being used for part of a process, while the rest is cobbled together with forms, spreadsheets, shared document folders, and the such.
We all have these little corners of flexibility. For the most part, they don’t amount to much. On the other hand, for processes that have to do with order processing, supply chain, and financials, it is quite normal to automate them. That is because these processes typically demonstrate some measurable benefits from automation, since they happen quite frequently.
There’s the rub. Every company benefits from this automation, and they have all invested in the exact same automation. When a wide array of customers can benefit from a single product, then someone will earn good money by providing that product, and automation is that product.
Seems obvious, doesn’t it? That commercial software can and should meet administrative needs. So why is it, when companies invest in packages like Dynamics, SAP, and Baan, they spend a fortune customizing the package so that their own parochial processes are automated in the tool, rather than simply consuming the processes that come “out of the box?”
For example, if I purchase, off the shelf, a system for constructing a contract from clauses and templates, I’m very likely to get a built-in process that is klunky, and overly generic, but quite workable and considerably less error prone than the one already in place, yet the purchase of said ‘contract construction’ tool will usually be met with a long and ongoing effort to ‘improve’ it by implementing all the same steps that the company performed in the past.
If you are going to buy a package, buy it. Roll it out. Let the business learn it. After a while, they will create manual processes around it. Put in measurements as soon as you can and then examine the manual processes at regular intervals, using tools like six-sigma to suggest process improvements.
Only improve the tool after it is running, and only after it has been running for a while, to give time to discover which improvements are actually needed.
I’ll place a heavy bet that simply implementing a tool, with minimal changes, and thereby completely discarding the prior process, will save the company money. Implement first. Then improve.
Doing both at the same time is a recipe for bloated and poorly performing efforts.