I hear complaints on a regular basis regarding long lead times getting BPM processes into production, rigidity in the performance of tasks allegedly “imposed” by BPM processes and high rates of failure of BPM initiatives.
It’s easy to understand that long lead times on any initiative reduce motivation, particularly if initial estimates are overly optimistic.
Rigidity in the performance of tasks results in staff refusing or being unable to follow process logic.
If either or both of these do not result in failure of an initiative, lack of a means of sustaining the orchestration that BPM is capable of providing probably is the final nail in the coffin.
We can do something about long lead times.
Let functional unit members map out their own processes in real-time, with the help of a facilitator, at first, with on-call participation of IT or BI for rule set construction, bridging processes across functional units and attending to data import/export, but otherwise cut out any middlemen. Do this and units become the prime movers, able to build, own and manage their processes.
Clearly, you won’t get very far with functional units by telling them they have to learn a new language or notation, so steer clear of any “solutions” that only add to the problem.
Complaints about rigidity go away when you say to staff . . .
“Here is a set of your best practices, consistent use of these will give better outcomes but we hire knowledge workers on the premise that you know “what” to do, “how”, “why”. Accordingly, you can deviate from the best practices as you see fit, with the proviso that environment-level governance will rein-in deviations that are not in the best interest of the organization, customers and staff”.
BPM in conjunction with Resource Allocation Leveling and Balancing (RALB), addresses “when” and “where”, leaving us to find an environment in which to perform and manage tasks.
That environment is CASE and all we really need here is a way for workers to be mindful of their fixed-time tasks and have the capability in respect of floating-time tasks (“to-do” items, if that better describes these) to micro-schedule these in between fixed-time tasks.
Clearly, part of task performance includes data collection plus declarations of completion at tasks, otherwise workers downstream from completed tasks will not be able to plan their workloads.
You need to build up a repository (log) of completed tasks in order for any system to provide advice and assistance in respect of the performance of tasks.
The rest of “sustain” involves providing a User Interface where going there to report on task performance is easier than not going there. Workers who tell the software what is going on do not have to entertain multiple phone calls asking “what did you do, what are you doing, when can my task start?”
CASE accommodates any mix of structured and unstructured work and builds a repository. ACM is concerned with the management of Cases.
Looking back at the origins of BPM, Critical Path Method basically had nodes, directional arcs, branching, merge points, milestones plus the ability to anticipate arrival at project end points.
Seems to me we lost a lot of that going from CPM to BPM.
ACM brought us back to the future.