I had a chance recently to get into an email dialog with an ocassional reader (thanks Anders) and we had a short but lively conversation through email about business process automation. Anders questions and thoughts were around the question - "What should we automate".
His argument is that the software industry is trying to convince us to automate everything. If it can be done, it can be done in software only better. Now, clearly, there are some things that humans simply do better than machines, and those processes will not be automated. Some processes should be automated simply to remove the drudgery of having to do them by hand - integrated purchasing systems really do save money and time.
What we both think is missing is definition and rules or constructs required to help make the decisions about automating a business function or process, and then the decisions on choosing a packaged software product or building something from scratch. Anders argues that a decision maker should usually choose packaged software for business functions that are not a competitive advantage for the business, and build systems for areas of the business that are a competitive advantage.
I think that most decision makers (who are not IT folks) don't understand the tradeoffs between building a custom system and purchasing a packaged system, regardless of the competitive differentiation of the business function. Mostly, the differences come down to "whole product" issues.
Fans of this blog know I always return to Crossing the Chasm to evaluate an issue like this. The whole product is the set of features and attributes not immediately tied to the base product. When we purchase a packaged software product, the whole product includes support, documentation, training, the future product roadmap and so forth.
When we choose to build a new system ourselves, there are several constraints. First, it can cost more to build a system than to purchase a packaged one. Second, it is usually very difficult to achieve the level of training and documentation that exists for a packaged software in a custom development. I've never seen a really well documented internally developed application. Third, you built it, you own it. There's no one else working with the software to extend it or find the bugs in it. Fourth, an internally developed application is typically limited to the technologies the internal IT group can and will learn and support.
On the flip side, a custom development can be built specifically to your processes and requirements. This is a good thing if your processes are well defined and make sense, but can be a real train wreck if you are "paving the goat path" - automating processes and decisions that didn't make sense to begin with.
The main problem with packaged solutions is that most firms are forced to make a choice - choose to modify their processes and implement packaged software in a "vanilla" fashion - that is, with little configuration, or try to rework the package to fit the existing processes. This rarely if ever works well. I find that most firms need to be willing to adopt the processes inherent in the software application to make the software truly productive.
When you are considering a software package, ask yourself what the bare minimum functions you need in order for the software to work according to your needs. Ignore the bells and whistles cause you'll probably not use them. Then, compare your business processes to the process inherent in the vanilla system. Choose the product that meets your minimum functional needs and most closely matches the business process you intend to follow in the future. This will reduce configuration time, reduce long term support costs and allow the software to function in the way it was intended.
Would you buy a farm tractor with the intent to convert it to an airplane simply because it has a very powerful engine? Why do we insist on doing the same thing with packaged software?
What you automate - the processes - are more important than how you automate - the systems. Whether you choose a custom development or packaged software, focus time on getting the processes right.
With regard to the comment about rolling your own when you get a competitive edge: it does require you to have the ability to maintain it.
Like you say, there isn't another company out there fixing it or improving it, and if you do decide to release it to others to get that bonus, you've just lost your competitive edge.
Posted by: GBGames | March 14, 2005 at 05:36 PM
With regard to the comment about rolling your own when you get a competitive edge: it does require you to have the ability to maintain it.
Like you say, there isn't another company out there fixing it or improving it, and if you do decide to release it to others to get that bonus, you've just lost your competitive edge.
Posted by: GBG | March 14, 2005 at 05:37 PM