A Series Of Information Processing Steps That Represent All Or Part Of An End-To-End Process
The topic of "Software" is too often seen as a black art or magic box, one that can only be understood by the high priests of technology. A whole mystique has grown up around software. Now it is time to blow that away.
So what is software? Simply - software is just automated processes. A series of information processing steps that represent all or part of an end-to-end process. When you’re buying the software you’re buying processes done by a computer. Often, configurable processes, but processes all the same.
Therefore when you install the software you are installing a new set of processes in the midst of the rest of your organization’s processes. This is a bit like taking a chunk of jigsaw pieces from another puzzle and placing it (force-fitting it) into the existing jigsaw that is your organization.
If you haven’t done your homework right, you’ll find it does not fit well. Gaps will be created where the software processes don’t connect well with your organization’s existing processes. Disjoints may occur where the software’s process philosophy is different from the rest of the organization.
Installing new software is like installing new processes.
To avoid problems when installing new software, you need to treat it like you would for any new process installation.
You need to FIRST identify your current processes and then simplify them into your desired processes (taking 40-50% of the process steps out).
Now once you have defined how you want to run your business in process terms, THEN (and only then) should you look at the software’s processes. You’ll find that
- (a) some processes match exactly (that's good);
- (b) some software processes are better than your processes (that's great);
- (c) some software processes are worse than your processes, but can be lived with (okay);
- (d) some of your processes are not supported by the software at all
For (d), a decision has to made as to what to do — forego these processes or change the software, but this decision can now be made in the full knowledge of the role and impact of these processes and how valuable they are.
Note: It is these unsupported processes that are often the ones missed in software evaluations that have been done without the preceding process simplification work, and which then cause major downstream performance problems.
In Conclusion
Even if you decide to ‘just take the software vanilla”, you are still deciding to take another set of processes and impose them into the middle of your existing processes, thereby creating (often unseen) business risks.
Don’t think software, think processes.
I'd love to get your comments below.
