BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 05 April 2018
  5.  Subscribe via email
A question John Morris brought up in a recent discussion where he wrote: "It's always a question as to how explicit and detailed a process model should be." So in your experience, how detailed do processes models need to be?
Max Young
Blog Writer
Accepted Answer Pending Moderation
Enough detail so that your predictive model can be disproved :-). If your to be model is predicting the future in any sort of credible way, then it must be open to being wrong :-)
References
  1. http://www.capbpm.com
Comment
  1. John Morris
  2. 8 months ago
  3. #5256
Bravo @Max. Your insight is powerful. You are saying your model (and resulting process automation artefact) should be significant enough to matter. Not "safe". Clearly one needs to include human oversight in such a model, to catch serious issues. The implication is "push the envelope". Because that's probably where the profit margins are. (I suspect that the falsefiability criteria here is related to @Boris' "volatility" argument, below.)
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
All depends, as usual. Maybe you want to use robots and people (as we discussed recently).

You may use the [ref1] which shows a ladder of process practices and links
1) what you want,
2) needed particular step in the ladder, and
3) how explicit and detailed your process models should be.

Thanks,
AS
References
  1. http://improving-bpm-systems.blogspot.com/2015/06/help-sme-becoming-digital.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
- click on the open button
- breathe in
- select the 'start' tab
- breathe out
- select the customer field
- breathe in
- type last name
- breathe out

You can never have too much detail.
Sharing my adventures in Process World via Procesje.nl
Comment
How are you going to control that all such details are followed? With robots?
  1. Emiel Kelly
  2. 8 months ago
  3. #5251
Natural leadership
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Great question. We usually found that the tendency from the users' side is to have insufficient, rather than too much detail, when it comes to process models and definitions.
Regardless of low to no code features that some BPMS offer, one has to keep in mind that the process to be model will pass through a great many hands and roles for review, approval and ultimately, implementation which most of the times is "code-laden". So, in my experience, a rich wealth of actionable information has to go into the process model.
The process model itself, interestingly, also covers several aspects. Some of which can be expressed by graphical expressions (BPMN, DML...) while others would be narrated into an accompanying definition documents (or better - videos of end user stories). The challenge to be overcome, defining the processes to be, is to express in an effective manner their dynamic nature, including all the conditional pathways a case can take within a single form, process or between a group of processes.
NSI Soluciones - ABPMP PTY
Comment
  1. John Morris
  2. 8 months ago
  3. #5257
+1 @Kay, you have highlighted key issues for process champions, specifically the cost (as I interpret the implications of your note) of capturing process information and making process models. Elsewhere we have sometimes called this the "challenge of the tacit". Process automation is very much about making the tacit, explicit.

You've also highlighted (from "many hands" to "code laden") what I believe is the biggest challenge for BPM evangelists, which is the time and cost of translating a need and intention to automation processes, into reality. We sometimes discuss this in the context of the "round-trip problem", but the problem is bigger than the technical challenges of round-tripping.
  1. Kay Winkler
  2. 8 months ago
  3. #5259
Thanks. Yes, sometimes we are lucky and are budget-wise enabled to employ complementary tools such as video based visual prototyping in order to shorten the "translation periods", which, in our experience, works great. It significantly lowers the "language barriers" and also has some effects of scaled economies, as this visual material is highly re-usable during the training and post-go-live phases of a typical BPM project.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Interesting question given that the model can now be the application where all business logic pre coded just needs configured via the graphical model. However there is sometimes a case with complex large processes such as a case management to do a quick high level view of what is going to be addressed. This allows all different departments to see how they fit in before using the build in the model. This over view sets the scene and requires basic knowledge of the end to application requirement. The build takes place in the graphical model with direct input from users in their language and of course covers all aspects with identified users their roles authorizations and who does what when all configured in the graphical model. An example of a case management could have over 75 process models with over 500 adaptive UIs all linked working in sync and using legacy as required. This becomes the actual display of what has been deployed supporting required changes giving transparency and accountability.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
The process design is special kind of description of the system. We model the system to understand how the system works with the aim to act in purposeful way or even to improve the system. What might be good criteria to develop a useful model of the system.... here are my suggestions:

The model (process description) should represent the "reality" in a such way that it helps us
1. to understand what are the critical elements and interactions having meaningful effect to the purpose of the system.
2. to learn about the system and it's behavior
3. to make a meaningful actionable conclusion (either action or improvement)

How detail we describe the system depends on what kind of understanding, learning or conclusions we try to achieve. If we want to understand the logic of business process, too much detail destroys understanding. If we want to develop an it-system almost every detail has to be described (the most detailed description is the code).

My experience is that most process designers describe the business processes too detail and in some cases the model is missing critical elements such as customer process, roles or business rules.

Good to remember: "All models are wrong, some are useful".

Br. Kai
Comment
  1. David Chassels
  2. 8 months ago
  3. #5252
But not if the model IS the application!
  1. John Morris
  2. 8 months ago
  3. #5253
+1 @Kai: "too much detail destroys understanding". This is deeper than it might seem at first glance. I have personal experience of business processes which were good references for specific steps, but rather incomprehensible in terms of the overall objective and flow. An argument for modelling at different levels I think, and for presenting those models (including static, simulation and live instance) at different levels of summation.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Depends on the stage of implementation of an initiative and the target audience.

For top management, a summary representation is best. Except that someone may challenge the model and ask for details. Better to have a couple of levels of detail that you do not show/demo unless there are questions.

Usual motivations for building physical models are to save time and money and anticipate situations e.g.
wind tunnel models for automobiles and airplanes, a scale model of a proposed house/office building.

The motivation can change for electronic "models" i.e. flowgraphs.

As David points out, some environments let you directly build your run-time app which means there is no point building a model.

Nothing precludes building a "model" then later extending it to an app. Clearly this is not the same as building a model then casting it aside to build the app.

Common practice in our shop is to initially park images of in-use forms at process steps as opposed to 'painting' real forms and attaching these to steps. Another tactic that helps to 'get the show on the road' is writing up rules in narrative form at branching decision boxes instead of actually encoding rules.

Something that is common in CPM is the ability to overarch a sequence like "start -1-2-3-4-5- end" with "start - end" (for display to top management). Overarching arcs like this could easily be accommodated at run time via an option that asks these to be ignored.
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Real business models, as a rule, have many levels of hierarchy in diagrams closely related through diagram links. This approach is one of distinctive features of BPM, which up-folds a knowledge contained in individual diagrams to the scale of the universal enterprise model. Amount of diagram links and modeling levels usually associate with maturity of the model as a whole.

Many companies and BPMS systems limit modeling levels to certain predefined amount related to established consulting practice or system architecture. Although justified with formalization and uniformity requirements, such limitations are not entirely justified or objectively stipulated by a business structure behind. Actual business is typically not limited to any imaginable amount of details.

Deepening detalization level of the business model is very important for validation of its consistency. Exactly transparency of process execution on all levels and correspondence of aggregated results improve reliability of audit and facilitate early error or fraud detection. On lower levels of its hierarchy business model directly bridges with application logs, process mining and big data analytics, which ensure smooth streaming of the information into real time enterprise reporting.

Of course, not all stakeholders are able to distinguish and understand all levels of the enterprise model. However, it is not necessary and even counter productive. Well established hierarchy of the model is specially designed to deliver its relevant projection to any niche group of users through various projections of the modeling methodology and targeted publishing portal.

http://caseagile.com/wp-content/uploads/mirror_in_mirror.jpg
Comment
  1. John Morris
  2. 8 months ago
  3. #5254
+1 @Boris, the reference to architecture, which although the reference is in the opposite direction to today's question of detail, business architecture is the essential context of any process modeling. Even if it is only implicit.
@John, Thank you. I made more focus on multiple encapsulation and embedding level structures in business models as such.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
You can ask following questions when mapping modeling business processes.

• What are the major inputs into these activities? (Think of inputs as both
physical entities and information.)
• How is information tracked? Written specs or paper invoices? What
percentage of this information is automated?
• What technology or application is used to convert a particular input into an
output? What equipment or job aids are used?
• What are the major decisions made with the process? Where and when are
these decisions made? By whom? Are approval signatures required? When?
• How long does this step take? Why does it take this long? Is there a range?
Why is there a range?
• What is the cost of performing these activities? Can you give me an
estimate?
References
  1. http://c.ymcdn.com/
Kritika Pandey (Software Analyst)
Comment
  1. John Morris
  2. 8 months ago
  3. #5255
+1 @Kritika re: "cost of performing these activities". Absolutely essential to explore the cost, including possibly before and after any process automation based on modeling. Simulation can help here -- although the use of simulation for what-if process initiatives is not nearly as widespread as it could be.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Do I have enough information in my process model? To rock my world?

The question about "enough detail" may seem pedantic. It is not. The question of "enough information" is at the heart of what management is all about, especially concerning how management uses technology to make change.

The job of the manager, the executive, the leader, is to envision a new reality, and to figure out a way to get there. The best managers do this by mixing both rationality and intuition, based on experience. And the modern organization is by definition realized in rationalized work processes. These managed work processes are themselves the result of the work of management, the work of modeling and the work of manufacturing process technology artefacts. The work of modeling and manufacturing is very much about acquiring information. And information is not free. Acquiring information, modeling and manufacturing process artefacts are all very real costs.

So, given the cost of information, our question now is this: How closely fitted to our requirements can we afford to make our models and our processes? Add in uncertainty and risk and we realize that process modeling is an on-going, never-ending management heuristic. We are always learning and adapting. And balancing budget against need. And then we can win. Japanese car manufacturers worked harder than their American counterparts to rationalize car manufacturing processes.

So, how much information is enough for your process model?

Enough to enable you to maintain your processes at the edge of effectiveness and efficiency for your industry, according to your budget. And that's a moving target. So you are constantly acquiring new information and constantly refining your processes. Do you have the tools and people and skills and programmes -- and financing -- in place to support this forever activity?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
My above comment might sound a little sarcastic, but in the end the power is in the details.

Execution of a process is detailed. It's everything DONE and NEEDED to deliver a result. But it is dependent on the way you want to manage your process. That still needs detail, but on a different aspect of a process.

Metaphor a roadmap.

If you want people to follow your defined route exactly, you have to give them a detailed map with detailed instructions. In this way they can exactly do what you want them to do.

If you make a map for 'knowledge travelers' you might only describe the milestones in detail: 'Be at this point at 10.00 am and bring 5 apples'. For the rest it doesn't matter how you get there.

I think that is always the best way for process design. Decompose the end result into milestones and describe them in detail. Then start thinking of how to get from milestone to milestone and ask yourself if this needs to be modelled in detail. If you want to let robots do it, you probably have to.

So; process result first, way of managing second, details if needed.
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
A goal, roles, rules, content, transactions, ... anything else is an unnecessary restriction that reduces service quality and increases cost.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
  • Page :
  • 1


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