[url="http://bpm.com/bpm-today/in-the-forum/profile/899-bogdan-nafornita-yahoo-com"]Bogdan Nafornita[/url] suggested this question: What advantage do you think BPM technology has over other work organization technologies?
My 2cts remain: BPM is for me the
[i]fundamental base[/i]in order to
[i]any other work organization technologies and deriviates[/i].
Example: when a company decides to embrace Lean methodology in order to help improve perfomance; there will be a moment that processes need to be discovered (either manually or automatically) and analysed. Perhaps somewhere else wthin the same company, one have decided to initiate a compliancy exercise, so you need your IST and some reference model. And again somwhere else one have decided to upgrade or integrate ERP systems and need requirements in the context of process. So, all those initiatives need sooner or later insight in processes.
Now here's the drill: You do not want to conduct 3 different (and often separated) exercises discovering process: As the only thing that has changed is your
[i]focus[/i]: Lean, compliancy, ERP upgrade/integration. I strongly believe that this way BPM doesn't have so much as an advantage, but is a
Any technology just supports the given management approach. Some may do it better than others but comparing technologies from different domains, e.g. BPM technology vs. project management technology doesn't make much sense for me. It's the underlying methodology what makes the most difference.
Therefore valid question may be a) what advantage process management has over other management approaches or b) what advantages a given BPM technology has over another BPM technology, e.g. BPMS over process mining or vice versa.
I compared only process-based management disciplines and I use the 6 main functions of BPM:
5. measurement and
as well as the scope span as shown below. See REF1 for the original blogpost.
- Dr Alexander Samarin
- 1 year ago
Also the scope can be stretched to reframe most process goals as case goals: P2P goal can be rethought as the goal of the "invoice as a case".
BPM technology is the ONLY work organisation technology. Other technologies such as CRM, ERP, SCM, HCM are all
[i][quote][b]work recording[/b][/i][/quote] technologies. Where these technologies have work organisation capabilities is when they have BPM technologies embedded in them - as many have now.
As for the technologies, there are more differenceses that you've pointed out - it's not that process management technology covers project management, too. One pecularity is predictability: project thinking assumes that we know what we'll do after what - no conditional branches. Besides project people pretend to know when the project is going to finish. Process mindset is different.
That's why I don't like painting processes and projects same color and prefer to use term "capability" when in need of generalization.
Merging together processes, projects, case, state- and document-based work is a worthy goal (and we at Comindware are working exactly on it) but it can't be done by pretending there is no significant difference between them.
And I won't disagree that projects and processes are in practice very different, even if one can argue that one is the end-case of the other. Especially interesting though is your comment regarding Comindware's objective . . .
Projects, processes and cases are essentially different approaches yet in practice they are heavily intermixed: they call each other, they migrate from one to another, they are mapped to a single high level capabilities map, they all instanitate tasks.
Another interesting point is that projects are managed by processes while processes are managed by a series of projects. It means that managing processes professionally implies project managemet knowledge and vice versa. This deserves a separate post though.
With all respect to who came up with the term work management, in my opinion work is something different than a process.
People do work, organizations have processes.
And to organize/manage my work , I can use all kind of stuff; sticky notes, to do lists, etc. But that doesn't mean my work has any value to a process.
And that is what BPM is about; executing processes for cases. And to keep track of these cases, BPM technology might help.
The least BPM tooling should offer in my opinion is that it should make clear the process status of al the cases in your organization
As (very classic) analogy take a car factory. The conveyor belt is the BPM system. It 'moves and monitors' the case. It knows in what state the car is and whether ar not that is according to what is promised . By taking a look you can tell the customer how long it will take befor the car will be finished.
So it should start with this overview of cases.
But the idea of a conveyor belt is also to move the car from working station to working station.
So mostly BPM tooling (or should I call it workflowl tooling) is used to direct cases from employees to employees, so they can do their work for that case. mmmm.. sounds like workmanagement...
The advantage of BPM as a management tool is that it should and does encompass a range process improvement as well as process automation techniques, I'm reminded of a very heated discussion I once had with my Dutch colleagues who politely reminded me that BPM as a discipline existed in the Netherlands long before the current technology fad we recognise today. In the Dutch school of BPM, process management had always included business architecture techniques, as well as process improvement disciplines such as TQM, Lean and Six Sigma.
With the advent of ERP and CRM solutions technology was embraced to bring standardisation and automation to processes. However this did not preclude good process design, in fact more onus was placed on process design, eliminating the unnecessary, non value add activities. The advent of process based solutions we see today was required to address the inherent rigidity of the ERP/CRM solutions, this allowed process designers to really think out of the box and radically redesign processes, automating complex business rules, while also making them visible and managed by the business, integrating to previously inaccessible systems delivering much needed data to the process at the point it was needed and finally automating the ad hoc processes where allowing the case worker to decide the most appropriate course of action is the simplest and most expedient thing to do.
Business architecture is then required to ensure that new processes and enhanced roles are properly aligned to the new organisation design. That change can be properly managed and embedded by inclusion of staff in the design, build and test of the new solution to ensure real ownership and buy in. BPM not only supports this approach but positively demands it as a way of working.
The advantage of BPM is that it does and should embrace a range of techniques of process improvement, design and automation to be a more integrated approach.
Shortest answer to the question of the advantage(s) of BPM technology over other "work organization technologies":
[b][quote][i]BPM technology is the only technology that surfaces the symbols of work (conceptual models e.g. "tasks", "resources") as first class citizens of the technology, for direct management by business.[/i][/b][/quote]
Here are some implications (i.e. the tl;dr part):
1) DEFINITION -- This definition is almost tautological; BPM technology by definition is about making work a first class citizen of the technology.
Project management software, which also concerns tasks and resources as first class citizens of the technology, can be seen as a special case or end case of BPM technology. And as @Alexander pointed out above, other technologies that we might not think of as BPM technologies, especially ACM, are converging to a common general process automation capability. Today's straight-up BPM technology is distinguished by a focus on repetitive work activities or process instances.
2) ALTERNATIVES -- All other technologies require mediation by some expensive cadre of bit-wranglers. This is more expensive than we dare think about.
3) MATURITY -- The only reason BPM is not more popular is because the technology is difficult to build and is not fully mature in important dimensions. Sometimes it makes more sense to use other technologies ("programming") to get the job done.
4) ONTOLOGY -- The conceptual models of work which become the first class citizens of BPM technology are mostly not yet based on ontology. This does not make the models of work in BPM tools invalid, it is just to note that these models are based on deep folk-understandings of what work is. Ontology on the other hand is the developing science of "scientific conceptual modeling". As ontological science develops further, conceptual models of work will be developed on which all software products related to work automation can be derived. Such an achievement will enable universal process and project model sharing. And ACM, GTD, BPM, project management etc. etc. will all be seen as different aspects and emphases of the same underlying foundations.
5) BENEFITS -- What is the benefit of BPM technology as defined? If managers can work directly with the concepts of work as they respond to market needs for adaptation, then the exciting promise of BPM will be realized. Adaptation of business models in real time!
6) SALES GATEWAY -- The work of Volker Stiehl, in his recent book introduced by Bruce Silver, seems to me to be very important in terms of bridging today's immature BPM technologies to the full promise of BPM. Herr Stiehl suggests that current technologies can be made dramatically more productive by the application of a strict methodology, a methodology of rigorously excluding IT-related interface complexitities from BPM diagrams. Let business analysts and business leaders focus on evolving executable business processes.
7) DOUBLE-DOWN ON BPM FOR SALES -- BPM is not just another technology. it is the technology that business and public services need now. IoT is at the top of the Gartner Hype Cycle and the demand for new business models is increasing every day. BPM products, alllied especially with other irreduceablel technologies such as business rules and analytics and maybe, sometimes, low-code-based software development, are just begging to be used.
The main advantage of BPM use is his own existence as an individualized dimension at organizations, what allows the best dynamic and flexibility in change management of work processes, in response to the market variations or to internal motivation of efficiency improvement.
The possibility to introduce BPM as a central dimension allows the connection to the all other organization dimensions, as business objectives from strategy, IT and Human resources, required skills, risks, etc., what turns easier to control all the impacts of a change in an organization without loss the holistic vision.
The "BPM" inside other IT solutions as ERP, CRM, SCM, etc. it's not the real concept of BPM, because it decreases a lot the possibilities to expedite changes in work processes, increasing costs and decreasing the control and quality.
The projects of changes are processes of implementation of new requirements, which can be found from the business processes analysis, by internal motivations or external imperatives.
It is weird to try to answer my own question, but the discussion triggered some feeble thoughts in me (so thanks for that, guys), so I'll put them here for good measure (and future self-bookmarking):
[b]BPM as a technology architectural pattern[/b]- many people are still blinded by the inconsistencies of the SoA architecture or of BPEL and try to either go to the microservices extreme (or various lightweight stateless interaction patterns) or the full-own-stack way. There is a simple, native elegance to the way BPMN as an architectural style is able to address the challenges of long-running processes (as most business processes are) - error-treatment, compensation, status inquiry, engine consistency, service rationalization, messaging patterns and in general stateful interactions. I think the
[i]emphasis on stateful orchestration[/i]is one of the key differences to other patterns out there.
[b]BPM as a business communication pattern[/b]- again, the temptation of many is to go the zero-code way and drop this to the unsuspecting business users. I believe this has limited market impact - most users don't want to learn about tasks and gateways and pools and lanes. But frankly
[i]BPMN is the friendliest of the modelling notations out there[/i]. Things can definitely be improved on the business side via domain-specific language and more natural language overall, but so far I think BPMN comes closest.
These two views need to be reconciled to their real value via a separate construct. Could it be a SCIL (Service Contract Implementation Layer) a la Volker Stiehl? Could it be a special type of ESB, combined with a rules engine? Could it be an interface with a BPM-focused information design?
Time will tell :-)
- Page :
However, you are not allowed to reply to this post.