BPM looks great on paper: Capture and map all your existing processes, both physical and technological, in an integrated application, and you’ll be able to track performance, automate workflow, and gradually optimize those processes for greater efficiency.
Perhaps the biggest reason BPM fails is that it holds little appeal to key decision makers and top management. While few among these ranks would argue with the importance of effective and efficient processes, from a leadership perspective managing the details of executing a process should come part and parcel with middle management. Just as Captain Picard on Star Trek would issue an order, then quip “make it so,” senior leadership assumes their dictates will be carried out efficiently and effectively and has little interest in the details.
Every junior business analyst has crafted what they believe is the perfect flowchart representation of a process, only to review it further and identify a raft of exceptions that litter their Visio masterpiece with convoluted decision trees in Rube Goldberg-like fashion.
While these exceptions are generally inelegant, they’re often the result of a demand to complete a function in a rapid manner, usually with end-customer revenue at stake. That one-off spreadsheet and strange invoicing procedure might not leverage the corporate ERP system, but they were able to quickly capture customer revenue at some point.
Inelegant exemption processes often were the quickest way to fulfill a customer demand. Doing the detailed and diligent work required to diagram these in BPM software might be more of a problem than it’s worth; these exceptions are often the result of customer requirements that are no longer valid, or machinations that customers should be charged for rather than eating revenue through back-office gyrations.
Combined with customer- or leadership-driven exceptions, another major challenge to BPM software is that most processes grow and evolve organically. Everything from a new intern to a tweak to a product or marketing campaign might trigger a change in a process that instantly renders your BPM software out of date. When BPM is driven by a party external to the process, like IT or a cross-company process team, there’s little chance of that team being notified as the process evolves.