We were talking about whether we (the company) should retire our legacy system in favor of SAP. He said that if he really had his choice, we should develop our own solution in-house. Puzzled, I pushed further and asked him what would drive him to reach such a conclusion with SAP, Oracle, our legacy product and a number of other industry-specific solutions available. He responded that he doesn't want to change the way he manages the business to make it fit with some off-the-shelf application according to how some software developer or any other company thinks his business should be managed.
He went on to tell me that too many people buy software under the impression that the software is going to make life better. They waste a lot of time listening to salespeople talk about various products, capabilities and features. In the end, they spend too much money on a product full of features they don't need and will never use and spend too much time re-engineering their existing processes to accommodate the software's interface, reporting capabilities or other limitations. Then he pointed out that a number of companies have been driven close to bankruptcy as a result of failed SAP and other ERP solution implementations.
What does this have to do with Business Continuity? Well, for now let's neglect the increased risk exposure due to ERP implementations and instead let's look at Business Continuity Management software. We've got LDRPS, eBRP, MyCOOP and I'm sure plenty of others. What do these have in common? They have in common with each other the exact same issues they have in common with SAP, Oracle and other ERP systems. While they are customizable to some extent, there is a management and planning methodology built-in. To get the most out of the software, you have to re-engineer your management processes to fit.
At first glance one might think that re-engineering the process to fit an industry standard is a good thing. Well, let me tell you that industry standards and best practices are guidelines. They are a starting point. They're not prescriptive, especially not for a mature program, and should not be read or used as such. Off-the-shelf BCM software is designed to appeal to and fit into, I estimate, 70-80% of the developer's market. And for those, it only fits 50-60%. Everything else the customer does has to be changed to fit the software or they have to opt out of using that feature.
So while none of the mentioned (and unmentioned, for that matter) BCM solutions are bad, the decision to purchase and implement any solution should be made with the understanding that software is, in fact, rarely a solution-in-itself. Calling niche software a solution is a misnomer. The software is, instead, a tool to help achieve a solution. It is therefore imperative to have your own measurable objectives identified and processes clearly understood, optimized and documented. Then, when looking at software, do not make adjustments to your objectives and performance metrics, and only consider adjusting your processes where the tool you're investigating provides an opportunity for automating something manual or gaining some other efficiency.
Don't let software dictate to you how to run your business continuity program.
3 comments: