Does the complexity of BPM hold it back in many organizations? If so, how can BPM be easier to use?
Sure, the systems themselves often aren't intuitive. But if you don't get the thinking right, then it doesn't matter how easy they are to use – you'll still end up with a mess!
Complexity is BPM's friend. Without looking thru the lens of BPM canan organizationeffectively manage its complexity or even achieve simplification of that complexity at the point of customer engagement.Complexity and understanding it by its nature holds things up but if you can't build a discpline to drive thru, design and deliver value to customers, an organization will be in a death spiral.
It's actually the complexity of organizations that a lot of times holds BPM down. Actually, good process management and improvement is always about reducing organizational complexity in order to deliver more value (time, quality, price, etc) to the final customers.
The problem is that as organizations grow in size they usually do it in very a unstructured manner. Because of that, they easily become a huge amount of tangled knots of bureocracy, processes, departments, systems, etc, etc.
The long term goal of a good BPM initiative should always be about reducing complexity, clearing out all the mess created by years of unstructured growth, and aligning the organization from end-2-end (from a strategic and operational point of view).
Complexity can hold people back, but it's less BPM itself than the delivery model used for the BPM project. Large, complex projects are generally much better managed through Agile-style iterative and incremental delivery methodologies than traditional waterfall approaches. Although waterfall delivery has a certain appeal--it lays out everything in advance--it can be tough to get traction. Months can go by as teams collect documents and figure out options and priorities...with nothing to show for it. They're bogged down in analysis paralysis. We've seen complex projects turned around when they move to a more Agile delivery model with a focus on priority requirements and run through the design/build/test cycles for each. You go live faster, deliver value faster, and get more feedback along the way.
Ken Schwarz is Product Marketing Director for Pega Business Process Management and Dynamic Case Management solutions. He is an expert in enterprise middleware and its application to business transformation and competitive strategy. Ken’s career spans marketing, competitive intelligence, international sales, technical service delivery and product development.
Yes, mostly because it involves the number of variables the analyst must juggle and control. There are both components to be managed, as well as design decisions to be made about each. This is why it is wise to use a Bill of Materials Processor, or as we refer to it in our trade as a Repository. In a paper I wrote some time ago (see link), I discovered in the average information system, there are:
NUMBER OF RESOURCES IN AVERAGE SYSTEMS PROJECT: 2,006
NUMBER OF DESIGN DECISIONS TO BE MADE: 49,850
And in just a single program design project:
NUMBER OF RESOURCES IN AVERAGE PROGRAM PROJECT: 98
NUMBER OF DESIGN DECISIONS TO BE MADE: 2,070
So, who and how is someone going to remember and control such complexity; on paper? Hardly. In their head? Impossible. Which is why they do not try to do it.
This is why you need a common Repository, not just for a single project, but to share and re-use components in many projects, thereby promoting integration of systems and expediting design and development.
Complexity is the reason we exist! BPM is about managing the complexity, ideally we can simplify and automate and take those tasks away from human actors. The biggest problem I find with complexity, is that organisations are not able or willing to break down the engagement into smaller manageable chunks, so that we can properly design and deliver the benefits. The most successful projects are the ones that iterate, and provide increasing functionality / complexity over a simple base. Agile is supposedly about short sprints that deliver value, breaking your problem down into manageable chunks however, it is often difficult to strip out, certain fucntionality from a process, e.g. credit scoring, especially when the client is used to having it in the existing system. Trying to conviince a client to wait until sprint 3 or 4 is often daunting, or imposible.
Sure. There are a couple of dimensions here.
The complexity of the underlying process. Individuals may play discrete roles in certain processes whose complexity is only evident when viewed as a whole. Often, the BPM implementation represents the first time the organization tries to take a holistic view of the process. That discovery can be daunting, and worse, that complexity may thereafter be associated with the BPM solution (rather than the process per se) in the minds of the business.
Overpromising. Let's face it: not every BPM solution is as simple as claimed. (I know, I know—I'll give you a second to let that one soak in). And, in line with the preceding point, even if the BPM solution itself is pretty straightforward, inherent complexity in the process simply is what it is, and will have to be untangled. If expectations aren't aligned going into the project, expect trouble.
In the end, though, businesses need to realize that process complexity exists already, whether they acknowledge it or not. They can tackle the problem, or try to avoid it an pay the cost in increased risk and ever-diminishing productivity.
Often times, a BPM solution is adopted to address overly complicated processes. The challenge is convincing the people involved that a change is needed and that an improvement means letting go of the "way" it's been done before. It can be hard for SMEs to conceptualize how they are going to be able to do each aspect of their current work in a new and better way. It is the job of the BPM implementation team to demonstrate how the solution is going to make work more efficient and what existing features can be eliminated or absorbed by automation. In short, it's not really the BPM that suffers from complexity, but really the people who know nothing else BUT complexity. As much as we like think that technology and processes and methodologies will save the day, there still is and always will be the human factor to address.
Another seductively simple question. With profound implications for the success of the BPM project. First, although most people have read the question one way, it's possible to read the question as concerned with "BPM-as-technology". Let's start from there and see where it gets us.
1. BPM ABOUT MODELING REALITY -- BPM technology is fundamentally about "modeling reality". The whole idea behind BPM technology is that there is a first-class citizen of software called "business process", which maps to some useful business reality. So, BPM is about "modeling reality" and then enabling the production and maintenance of business process software artifacts from those models. To assess whether BPM is too complex or not, we have to ask that question about BPM modeling.
2. REALITY IS RICH -- We can choose to apply BPM technology to as small or as large a piece of our business reality as we like. But even the smallest reality can be quite complex. I like to say "reality is rich". So inherent in any BPM technology deployment is the inherent complexity of reality. Many of the contributors above have referred to this challenge.
3. BPM DOESN'T YET PRODUCE HIGH-FIDELITY MODELS EASILY -- If all we needed to sell BPM technology was BPM propaganda (or for that matter, "workflow" propaganda from 15 or 20 years ago), BPM would by now have taken over the world. But "BPM isn't eating the world" -- at least yet. And that's because it's comparatively difficult to produce models of business process reality quickly, that can then be executed, and to continuously evolve those models. The reason is that BPM technology is not yet fully up to the task of delivering executable models; this is primarily a mathematical research and computer science issue. One has to be able to solve complex graphs in real time (or so I'm told). And when we can't do this, we have to resort to "coding" to bash our process model into the shape of our reality. But as soon as you do that, you rapidly lose the flexibility for which we wanted to use BPM technology in the first place. A large portion of any business analyst or BPM developers time is spent "working around the limitations" of any given BPM tool, rather than focusing on evolving business requirements. (The "round-tripping" issue is just part of this problem.)
4. BPM-COMPLIMENTARY TECHNOLOGIES ARE ONLY NOW COMING ON STREAM -- An service escalation pattern in BPM, without abstracted business rules, is a mess of spaghetti, and unnecessarily complex. A basic service call escalation pattern doesn't look business-friendly to the "until recently-enthusiastic sponsoring business executive". The newly delivered DMN (Decision Model and Notation) specification from OMG, possibly used in concert with event-driven technologies, and assisted with support for common "fuzzy" process patterns such as case work, will make the dream of model-driven development possible. I believe that BPM technology is the spine on which these other technologies will be deployed. And the result will be truly amazing.
5. COMPARISON TO CODING -- There is no comparison to coding. Coding also includes the same models of reality, but implicitly (unless you're working from Visio diagrams). Everything is just more difficult. Whatever the limitations of business process software technology, the same thing applies to coding, but times ten.
So, in summary, BPM is too complex, and many users end up discouraged that BPM software-based development isn't orders of magnitude easier than coding-with-frameworks. This frustration is in part a limitation of current BPM technology. Technological advancement is necessary to enable BPM technology to easily model the "richness of reality". The result will be astonishingly superior to what we have now in the world of software artifact production. Then any business or organization can decide to make their processes as complex or simple as is appropriate for their environment. The technology is evolving every year; the circle of BPM-based organizations continues to expand.
BPM itself is as complex as the business that gets managed this way and there is no way to adress that other than just simplifying the business model, so I'll assume we talk about BPMN/S.
BPMN is not complex (you basically have tasks, flows, 3 usual types of gateways, 3 usual types of events, pools, lanes etc) and the methodology is not really rocket science.
But the problem is that it becomes really complex when you try to use it as more than just a communication tool, i.e. pass the baton to a BPMS. Then you have to dig into data modelling, interface modelling, information architecture and software development concepts in order to really make it work. To be clear, this is still miles better than start to custom code the hell out of it.
The only way to mitigate that is to:
[b]be visual but accurate[/b]- use a modelling & execution package that also (at least partly) builds some standard codebase (this includes data model and application model) at the same time within an integrated development environment;
- break down any process in as many
[b]re-usable small global subprocesses[/b](referenced via call activities) so that at least you remove unit testing and focus on integration testing;
[b]iterate fast, right in front of your process customers[/b]: draw the process+data+interface --> build --> run --> collect feedback --> rinse and repeat.
@John Morris: I had the reply prepared from yesterday but the commenting system didn't work for me until today, so I'm not copying your response :)
PS: I am working on your point 4 - even now it is already possible to intelligently integrate BPM and CM in model-based execution tools, but indeed there is a need to code a Java framework around that (to inject some needed anti-fragility into it). I do not see the immediate value of DMN in this (just as SBVR's), apart from the conceptual clarity added.
[b]1. IT used to be hard. In BPM it still is.[/b]
In the real world we have drag and drop. Making connections in milliseconds, totally reorganising look and feel in a few clicks and applying the new look across hundreds of pages in seconds.
In the BPM world it is deemed far too complex for business people to do it. We need business analysts, system architects and software developers.
But you know what – go on the Developer course and you find drag and drop, connections in milliseconds…
[b]2. Implementation used to be easy.[/b]
Time and Motion men measured everything, watched everybody. Then say “Do it this way”, impose it on everyone and walk away, cheque in hand.
BPM people still like to think that’s the way to do it.
It is naive to think you can simply design a horizontal process and impose it on a vertically organised business. It ignores…
[*] The complex relationships within and across sections
[*] The skillsets and experience of individuals.
[*] The build-up of “patches” (with good reasons at the time for implementation) which make the process substantially different from what people think it is.
[*] The training of customers to do it the way the system wants them to.
[*] The effects beyond the organisation and in the eco-system.
[*] The market and competitor effects.
Most importantly, it ignores the law of unintended consequences – where a small change in one area can have totally unexpected effects elsewhere.
There is no single right answer when designing a process, only trade-offs. Those trade-offs change over time.
Therefore your process needs intelligence from multiple inputs. That’s an IT way of saying involve everyone – they all know something somebody else doesn’t. Aggregated they give you a 3D picture.
It also needs to change constantly. Become a trajectory, not a snapshot solution. Check this out to see how you can see something as one thing, when adding time shows it as really something else… [url="https://www.youtube.com/watch?v=0jHsq36_NTU"]https://www.youtube.com/watch?v=0jHsq36_NTU[/url]
The answer to “What is the best process for now” is not what you’re there for. But, simplistically, it is the question BPM people answer.
BPM needs to make the IT simpler so it can get on with the complex stuff – changing minds, methods and interactions in complex eco-systems. It must be so easy to use that it is the default method.
+44 (0) 1491 874368
+44 (0) 7590 677232
We all know that it is easy to make things complex and it is complex to make things easy.
The complexity (and power and beauty) of BPM is that a proper use of BPM (as a trio discipline, tools and practices/architect) makes a complex “thing” called enterprise (including its operations and evolution) easy.
Unfortunately, each BPM vendor, each BPM consultant and each BPM client are doing this (use BPM to make a complex thing easy) separately. This is the root cause of holding BPM back in many organisations.
I suspect this may have been the case. When IT gets involved with frontline activities it rarely truly delivers on user requirements to help them in their job. So it was easier for both sides to accept a compromise even buying into someone else’s view of how to work; COTS or old “BPMSolutions” or not bother and let the spreadsheet rule!
However ironically this may be reversed as new BPM Supporting Software can now step by step build any requirement simple and complex. Complexities which were not fully supported such as product configurators or benefit systems are now readily addressed. It will be the BPM thinking and skills that will begin to extract the detail to allow articulation to translate into next generation Adaptive Solutions. Indeed this should now promote importance of the BPM discipline?
The other angle to the question is that such BPMSS should be easy to use and "how" it works should be readily understood by all to give confidence it will deliver!
- Page :
However, you are not allowed to reply to this post.