BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, April 01 2014, 09:42 AM
  4.  Subscribe via email
Simplicity and ease-of-use were frequent themes at bpmNEXT. So what parts of BPM are still too complex for the user and need to be simplified?
Guest Accepted Answer
The design-time environment is still ripe for simplification with most environments -- particularly since the trend line has pointed in the opposite direction for the last decade. For every new innovation brought to market targeting design-time simplicity, ten more were introduced focused on expanding design capabilities (thus expanding complexity).
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Reference model, of course, as each BPM product has its own (easy to guess, incompatible) version of it.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Keith Swenson Accepted Answer
It is not for lack of "drag and drop." Every talk mentioned drag and drop at some point, as if the difficulty in creating a process was the difficulty of actually getting the shapes onto the canvas. Try this: randomly drag some diagram elements on the screen, and randomly hook them together. Does it run? Almost surely not, because you have to understand the meaning of the shapes, and the hidden logic behind them, such as the process variables that hold and carry values that are then tested and combined within the process.

It is not for lack of "no coding." Every talk mentioned that you didn't have to do coding, while some of these talks proceeded to show elaborate 50 or 60 step processes that certainly had intricate logical dependencies. The difficulty behind coding is NOT typing the letters, nor is it really forming words and syntactically correct sentences. The difficulty is the complicated symbolic logic that is inherently part of the process.

The problem is that our "enlightenment bias" makes us believe that processes should be simpler than they really are. When people start drawing detailed process diagrams, they realize that there is a lot of inherent complexity to reality. They wish for something easy. So vendors also try to achieve something easy.

The problem is that business is too complex for traditional diagram-style BPM. The idea that you can boil business down to something simple enough to diagram is the core of the problem. Complexity is what makes the real world what it is, and it is our biases that make it hard to see that.

http://social-biz.org/2013/12/09/applying-complexity-science-to-management/
References
  1. http://social-biz.org/2013/11/28/15-key-lessons-for-managing-complexity/
Comment
Can't this pass without a challenge.....
Business logic just never changes and can be addressed by less than 13 task types human and system with very flexible links all expressed as data stored in a relational database. They just need to be configured as required. This approach covers ALL the business needs as follows.
• Process engine – orchestrating as required to ensure all works to plan
• Rules engine - reflecting real world of complexity and compliance
• Calculation engine - automating system work
• State engine - real time feed back from any point
• Workflow - everything connected in right order
• Audit trail, events, escalations - managed control and accountability
• Rapid prototyping - user involvement in build
• Time recording - supports activity based costing
• Real time reporting - become predictive
• Build mash ups - one screen multiple data sources
• Linked intelligent Ajax grids - enter data only once
• Roles and performers - people and machines indentified
• Management hierarchy - see who does what and when reallocate work
• Orchestrating legacy - recognising valuable data in legacy
• User interface dynamically created - linking people, roles, task type and data via forms for specific instances recognising that user forms needs to be specific for that task in hand and with intelligent functionality should for engaging for users
• Pre-built templates for custom documents, letters, e-mails, messages etc dynamically populated with instance specific data and edit capability in browser - automating yet giving users ultimate control over external communications
• Process and task versioning control - recognising change is inevitable

Business is in reality simple if you break down step by step what is required to achieve the desired outcome You can build highly complex applications such as a configurator frankly nothing is off the agenda for business needs and it IS all transparently built in a Graphical Process Designer . It uses "declarative" technique from the GPD to set up the design into automatic build ready to run. It is a very simple concept and has been proven it works. Not surprisingly all early adopters were business driven with IT just resisting such a move to simplicity. All described in this research paper published last year. http://www.igi-global.com/chapter/object-model-development-engineering/78620

It was Naomi Bloom a thought leader who commented “It really matters how your vendors build their software, not just what they build” ….how those models can become applications without any code being written or even generated”. “If I’m right, you’ll want to be on the agile, models-driven, definitional development side of the moat thus created…..” “If your Enterprise vendor isn't pretty far down this path, their future isn't very bright” Good advice….

Keith your biases are blinding you to thinking business and keeping you in a box of complexity - step outside smell the roses......it works!
  1. David Chassels
  2. 2 years ago
"The problem is that [we] believe that processes should be simpler than they really are.... [B]usiness is too complex for traditional diagram-style BPM."

Couldn't have said it better myself. So I didn't try. :)
  1. E Scott Menter
  2. 2 years ago
one thing I'd point out: there are tasks for which drag and drop is the RIGHT way to do it, and not a replacement for what should be coding, but an actual improvement in productivity for the coder. The example we showed at bpmNEXT was just that - drag-n-drop to layout your UI is much more efficient than hand-coding it. (of course, we never claimed there was no coding in our demonstration, in fact, the drag and drop is an aid to the coding exercise for user interface).

I get that you don't like the buzzword drag and drop, but it isn't THAT that is the problem, imho, it is more the premise of dialogs and drag and drop *replacing* coding, when coding is likely the right metaphor in many cases. In short, "no coding" doesn't mean simple, it just means no coding. Try filling out a mortgage application, there's no code involved, but it is not simple! :)
  1. Scott Francis
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Shelley Sweet Accepted Answer
Blog Writer
What's too complex I think is the transition from the BPM model - yes, even when the model is in BPMN - to execution of the model. Every time I listen to what happens to get there I am overcome by the complexity. We need to make that transition easier and more explainable.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Tom Baeyens Accepted Answer
The complexity comes from the top-down perspective. First of all, it requires a certain maturity in BPM thinking to know how this benefits an organization. It takes interviews and research to analyze how work gets done. That can be a big puzzle. It takes knowledge of the BPMS to automate processes. Top-down BPM initiatives have some prerequisites, but for critical processes it still pays off.

The simplicity we are missing comes from the bottom-up perspective. When an individual is able to automate his own piece of the puzzle, many of the aspects get simpler. It doesn't require any knowledge on how others get things done. Just start with what you know yourself and what you can automate yourself. That's what we call personal workflow. At Effektif, we ensure that people can automate these simple workflows by themselves in a matter of minutes. For example, each month I get a couple of invoices that I need to upload to my Google Drive. Or as another example, for each software release John does QA, I tag the source code and produce the release notes and Jim upload the file to production. The coordination of tasks for people also is a lot easier when looking from your own personal perspective.
Tom Baeyens
Signavio.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Guest Accepted Answer
I'm going to take a different approach to the question. I still think the hardest thing about BPM is explaining to IT people who don't know what it is why we should use it versus a different product. Given that the vast majority of IT leaders in most organizations come from a time before BPM, the idea that a COTS products such as this family of tools could more easily solve their problems seems almost ludicrous. This happens not only in organizations where we might internally suggest its value, but almost always shows up when trying to sell BPM to a customer. This is especially true in the Federal government where IT leaders still view their projects as too complicated for anything COTS. Often, even after convincing the process owners of the value of these types of solutions, a project concept gets deep-sixed by a CIO or other IT Lead.

I think we as a community have done a better job of trying to talk in terms of case management or document processing, but I still think we need to make sure we are not positioning BPM to senior IT people as a "jack of all trades" solution. Most IT leaders just won't buy that.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Emiel Kelly Accepted Answer
I would say the B and the P. Without understanding what your processes are, how can you decide what kind of grip (maybe supported with some tooling) they need?

15 years ago I came to organizations to help them model their processes, implement some workflow systems. I just did that because I was young and it was my job.

Now I spend most of my time to make people aware of their useful processes. I try to make them aware that a process is just a means to deliver a result. Depending on this result (I'd like to call it the promise) you can think about the design of the execution and management of a process. And sometimes that might be workflow like with no exceptions, while other processes might benefit more from employee-drivenness. Every process is unique, so it is strange to manage them all the same.

In this way you stay a way from the 'block with arrows' view, but start with what counts; the end. You don't have processes for fun, you have processes to deliver what you promise. And that makes BPM daily business. But sometimes a little coaching on what are worth full processes is needed. At least that's what I experience. But of course that's also based on the fact that my starting point is always the business, never IT. IT is just on of many enablers of a process.

Starting with the B and the P is not complex, this is just common sense because you think about what others need from you. And that's what you should have processes for.

But of course it's not as fancy as those shiny drag and drop and automate tools ;-)
Common Sensei at Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
David Chassels Accepted Answer
Complexity exists in the minds of experts and those vendors who cannot afford to sell commodity software that delivers on how business actually works. Vendors who have acquired and not invested in original R&D now have a huge set of complex components to integrate and sell. The biggest issue comes from the misuse of “plain English” that actually hides the underlying complexity of these technologies. We have seen “smart” totally misused by vendors and “intelligent” both wrongly applied to clever integration of technologies. BUT to business is means expectations of smart or intelligent processes to help users. However good to see Jim Sinur leading the correct interpretation?

BPM must address this by using simple meaningful words that business understand and set an expectation in their minds recognising that Business is actually simple; its” people doing things to make things happen” IT has made business complex with complex and very expensive software of which business has little understanding. That must change indeed will change as we have proven how this next generation software that business understands actually delivers in their language.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Anatoly Belaychuk Accepted Answer
Blog Writer
Are we talking about BPM or BPM Software? From my perspective the software albeit complex is not the most complex part of BPM as a discipline.

BPM is complex because one needs to develop capability in process methodology, have vision and strategy in place, be familiar with agile project management and change management - these are mostly social/business/managerial skills. And yes - they have to be combined with technical skills in BPM software. Typical techies are weak in the former while business people are weak in the latter, the individuals combining both are rare.

ERP has similar yet not that tough problems because it's a packaged application anyway while BPM is all about unique and differentiating things hence it's tailor-made by definition. Most people don't even realize a huge difference between ERP, CRM and alike (applications) and BPMS (a platform).

It's a broad range of necessary competencies that makes BPM complex.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Don Schuerman Accepted Answer
Agreeing with Keith. Real businesses are complex. Real processes are complex. Real organizations are complex. Just like real humans are complex. Good BPM practitioners help businesses manage that complexity: eliminating that which doesn't add value, managing and exploiting the complexity that differentiates or that an industry demands. Good BPM software captures that complexity into the processes so that the end users of the systems (employees and customers) don't have to confront it.

That is..and will continue to be..very hard to do.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Instead of commenting on everyone’s personal comment I decided to add another comment to the discussion, because, it seems, everything in BPM is complex – business, processes, tools, technologies, etc. These are certainly symptoms (like pains at a body with long unhealthy life style). What are root causes? Just look in the mirror.

There are two different sources of complexity: 1) Natural, as we use more and more complex products produced by more and more interlinked companies and 2) Undesirable, as we do things with inadequate tools, without using the best available knowledge, via not communicating in the “same” language, by reinventing the wheel, following contradictory recommendations from consultants, drawing a process and executing something else, etc.

We (the BPM industry) have to reduce the undesired complexity to “liberate” the resources to better handle the natural complexity. And we must do it TOGETHER.

For example, although all processes are unique, the majority of them are assembled from patterns. Why should each enterprise reinvent the delegation authority matrix, differently and not optimal? Why is there not a proven set of patterns? Who can come up with BPM tools as executable BPMN fragments which are easy to adjust.

As any normal industry, we must have commonly-agreed terminology, a BPM reference model, executable process patterns, and BPM reference architecture. We have to work closely with business architecture, application architecture and enterprise architecture because every enterprise is a system of processes.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Bogdan Nafornita Accepted Answer
I dream of a BPM framework where business people freely and adaptively add logic, rules, tasks, reminders, concepts, data objects - pretty much with the same viral factor of the open-source software contributions. The framework would "compile" in real-time the "cocktail" to check for overall logic closure and outcome consistency. This framework would most likely take the form of a Business Programming Language, ripe with business objects / classes / data models / rules / functions and, most importantly - a clear business vocabulary.

All attempts we see right now around us: notations / methodologies / tools etc will become just pre-historical artefacts of a unified vision.

We are now focused on describing the spoon.

There is no spoon.
Managing Founder, profluo.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Derek Miers Accepted Answer
Agreeing with many folks above - the real challenge is not in the technology per se - technology and its implementation is the easy part. The real challenge is getting people involved (engaged) and getting them to look past automating their existing cow paths.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Max J. Pucher Accepted Answer
Blog Writer
The question is: 'What parts of BPM are too complex for the USER.' Yes, the IT department and process experts are also users of the system, but they should not be the ones to drive the creation and continuous improvement of processes. Therefore it is not really relevant how complex their parts are. And both will have to have their part as any BPM or ACM solution does not stand alone in the IT infrastructure.

But what about the business USERS. The claims that business users are enabled to design processes with all kind of graphical tools and 6th generation languages are empty. They simply aren't. The point is that business users already have a tool to design processes and it is their business language using their business terminology. So unless the BPM environment allows the definition of a business language ontology that ensures that whatever function is presented to the user on the UI is in their language without ambiguity, all BPM functions are too complex for the business user.

For creating the user interaction, the system should support the creation via user stories in the form: 'As a claims clerk, I want to list all damages so I can assign the right assessor.' That represents a 'context' in which 'actions' are taken. To support the unpredictable side of processes one must be able to define which 'events' can happen. All in business language. Unfortunately some of it will require logic and thus a kind of rules language and yes, there is a lot of room for improvement that an ontology brings to rules writing. But yes, defining steps, data dependencies, rules, context and actions/events is also a form of 'coding' as Keith points out. It simply is not for everyone.

Therefore as much of the logic of a process should be INFERRED by the system through learning from what users are doing in the real process and not what some disconnected process expert thinks the process should be like. I call that a machine-learning agent, but then Keith has a different perspective of what an agent should be, mostly executing a set of predefined rules. Because so many processes are driven today by the need to enforce regulations too many think thats all it needs to do. So wrong.

So for me the following things bring process management closer to the business user:

1) A business language ontology (which needs to be created by an analyst ... with data entities supported by IT).
2) Processes are defined top-down by goals, outcomes and handovers using the business ontology.
3) The user interaction is described through context/action user stories.
4) Processes are created by the business users by adding tasks, dependencies, content and data in their language.
5) A machine-learning agent makes suggestions learned from user actions, (users can tell the agent he is wrong!)
6) As processes are being refined by whoever is skilled enough, they can add guiding or limiting rules using the ontology.
7) Any completed process or parts thereof can be saved as goal-achieving templates.

It is the underlying complicatedness of the technology that makes the functionality simple enough for the business user. Simple technology is mostly not simple to use. BPM flow-diagrams are way to basic as technology to be practical for a non-engineer. I wrote a post on 'The complexity of simplicity.' years ago.

A process management solution needs the ability to let business create its processes as otherwise these processes will also just be complicated and never represent the real-world complexity of a business and its consumer/customer interaction.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Sharmistha Roy Accepted Answer
Agree with comments here talking about BPM adoption - the biggest challenge still lies in getting business owners to stop thinking of BPM as an 'IT' thing. Understanding process efficiency and seeing the value that delivers to the business has got to improve BPM adoption within organizations. Discovery of the state of your business processes is where the real work lies and might still be the hardest part of implementing a strong BPM practice.
Sharmistha Roy
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Lloyd Dugan Accepted Answer
Agree with Keith and others above that business processes are complex. I would add we are all being disingenuous when argue otherwise. However, I don't go so far as to say that should mean we give up having to deal with this complexity. I simply think that we are in an ongoing, likely never-ending journey to figure out how to transform complexity into something more comprehensible. I also think that if we approached process engineering with the same rigor as things like electrical engineering or architectural engineering we would not find ourselves in such a state as we do. Much of problematic nature of complexity arises from the rather sad state of competency in BPM.
Comment
Lloyd
Actually processes are quite simple once you break them down to individual actions. I was doing that in the early 70s talking to people how they worked and mapping out their activities. I was a CA apprentice no special training just asking good questions.

Sadly "IT" has made processes complex, lacking in transparency and not built direct in business language. You are right take an "engineering" approach back to basics and logically move forward. This was the basis of our R&D started 20 years ago and no surprises at Model Development Engineering (MDE) tag. See "how" in paper published last year http://www.igi-global.com/chapter/object-model-development-engineering/78620 Accountants and engineers get it very quickly “IT” struggles that is the real challenge!
  1. David Chassels
  2. 2 years ago
  1. more than a month ago
  2. BPM Discussions
  3. # 16
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.