- May 27, 2011
- 0 Comments
In an apparent bid to become tomorrow’s ERP system, Appian makes an appeal to “stop application sprawl“.
But they perked up when talk started shifting to how Appian could wrap or replace existing point solutions in addition to automating currently unstructured processes. A few minutes later, full of excitement, they said the following before the whole group, “After we adopt Appian, we will need to be convinced why any point solution would be better than what we could create for our own needs in BPM.”
It is a little counter-intuitive for a BPM services guy like me to complain about pushing more BPM. But I’d just say this: your BPM platform is not your application replacement platform. It is your process -aka BPM- platform. Your firm won’t be better off having all of its systems inside Appian (or another BPMS) if there isn’t any process improvement and rationalization happening along the way.
Rather than seeing someone say that they would adopt the BPM solution over any point solution that can’t prove it is better, the framing should be in terms of process: before buying a point solution, we need to understand how it will fit within the overall fabric of our processes, and whether that “fitting” effort will outweigh the benefits of buying a point-solution application (presumably best-of-breed).
We’re not doing anyone favors if we just hand them the BPM hammer and let them think that all their issues are nails.
But if you do find yourself doing a “rip and replace” project, keep this in mind:
When building a BPM solution, we are often integrating with and replacing parts of legacy systems. Often one of the first requirements from the business will be that the new system does everything the old system did in order to be accepted. This is generally a bad false start to a project.
However, one of the best tactics is to figure out what the 2-3 key NEW capabilities your solution will bring to the business that are so compelling that some minor discomfort over less important details will not derail the project. You can call this marketing, but it is truly understanding where the real value opportunities are in your project. Sometimes these capabilities are things the users will clamor for, sometimes things that the management team will clamor for, and rarely, things that IT will clamor for. Make sure that at least one of your major stakeholder groups is squarely behind a few of the wow features of your BPM project. If you don’t have that excitement in one area, my experience is that you’ll find uncomfortable scrutiny on an exact comparison of the new solution versus the old solution.