What Are the Most Overlooked Processes in BPM?

No brainer BPM projects:
- Expenses
- Time Slips
- Registrations
- Travel requests
- Purchase requests
- Accounts Payables / Invoicing
- Sales Orders
- Employee on-boarding

Condsidering the distribution of work types in a modern business, (J. March, 1991) it is quite likely that only 20% are actually the low-value, high-volume processes that can be easily automated with the typical flowcharted BPMS and where the volume justifies it. Garth made a pretty good list of them. Another 20% are most likely well encoded into backend systems such as ERP. 40 to 60% are knowledge work and these can't be automated because they are unstructured and unpredictable. Maybe 20% aren't really processes but more like projects or programs and could be supported by a sufficiently dynamic process/case environment.

So I don't think these processes have been overlooked, but current BPMS and the related BPM bureaucracy can't capture and thus manage them. This needs a new kind of process evironment that empowers management, process owners, actors and even customers to jointly create the process and adapt and modify it until fits current expectations. Embedded goals, rules and metrics ensure that they satisfy, are compliant and efficient. Some of it we see in social enablements and ad-hoc and dynamic processes, but I feel that it does nowhere near go far enough. Some propose the an all out 'social approach' might be the only solution, like i.e. Activity Streams. I wonder.

Here is my take on it: http://isismjpucher.wordpress.com/2010/10/27/lipstick-on-a-pig/

I wonder too - I think an activity stream helps in visibility and in providing fodder for analyzing activity holistically but I think the bigger issue is the unstructured nature of most things business people actually do to get their job done.
Ultimately I think the solution is to think about providing a mechanism to support and encourage personal responsibility in getting the process completed in an effective manner. This requires ties to key job performance metrics which should tie to overall company performance. We do a lot better job at setting individual job roles than we do in describing process metrics. Most processes function more like people do - highly collaborative and expertise based so BPM tools should model that behavior and provide visibility into these activities over time to understand trends (both positive and negative) which will ultimately lead to recommendations on areas for improvement.

Agreed that process is always going to change because there are infinite ways to get from point A to point B. The key is to define the roles and specialties of point A and B and understand how they relate to the business goal at hand. Point A and B are static - the key is to understand that static 'map' and build the routes or processes dynamically based on the any number of criteria. Having a stream of activity allows us to understand these specializations but it doesn't resolve how we will use this information to address ad-hoc processes.

Knowledge intensive processes that are highly dynamic and progressive are often overlooked in BPM. It is interesting to note that BPM was originally focused on automation (both for well-defined processes and routine work flows), but somewhere down the line, BPM failed to address the very promise of its origin - empowering knowledge workers in the organization and supporting process agility to the ever-changing business climate. This is slowly catching the attention it deserves to many developers.

Garth's list seems good. Along the same lines,I blogged yesterday before seeing this question, ranting how small, short workflows are now overlooked. Big software sales come from enterprise scale processes. This overshadows where the real benefits can come from, much like Max's research suggests.

Read the full rant here: http://blog.consected.com/2010/10/fix-little-things-and-get-big-results.html