1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 23 March 2017
  5.  Subscribe via email
From Boris Zinchenko: What are the boundaries of applicability for a business process? How interchangeable are processes between organizations and divisions within an organization? Are processes specific to a region or country or do they have a universal nature?
Accepted Answer Pending Moderation
In general a process is the means to solve a problem. A process should deliver a useful product or service that solves a problem for a customer. Parts of different processes might be the same, but the problem to be solved should always be leading.

That "useful service or product to solve a problem" defines the boundary for me. That's universal, but in practice it differs from company to company of course. Besides that there are may ways to solve a problem, so also many ways to manage a process.

Like I wrote here

Or for the Dutch speaking or Google translators: My piece on process goals and results can be found here
Sharing my adventures in Process World via Procesje.nl
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
If you reframe a business process as "any amount of steps (loosely or strongly coordinated) that have a clear business goal", then you should remove any boundaries of applicability.

Business processes per se are not really interchangeable (as every customer just feels the need to tweak whatever you give them, because they feel a bit special) but the actual process patterns (that make up the business processes) are highly reusable, if properly framed and architected.
CEO, Co-founder, Profluo
Patterns be good. Process composition from patterns be good.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
I don't subscribe to the idea that processes, other than end-to-end processes can or should have plan-side "goals". Anytime you have a mix of structured work vs unstructured work, it is the run-time Case that hosts goals\objectives.

When you have users and software threading together, on-the-fly, process fragments in a context-situational (i.e. Case) manner, each process fragment (including process fragments of one step each) cannot have as a goal other than to complete the 'last" step in the process fragment.

Say I havea "build->test>ship>" process. Clearly we can have a goal plan-side.

Not so if I split this up into three process fragments.

Under this scenario, when I complete "build", all I have accomplished is completion of a pre-requisite to "test"

Seems to me the "boundaries" for Cases\run time process template instances are "actions that do not advance the organization's strategy to preserve and augment competitive advantage".

If a corporation builds watercraft, it probably should not be spending time designing a new chair lift for a ski resort. Change the strategy to "products that keep the business running 365 days a year" though, and no problem with watercraft/chair lifts.

There is great value having processes that are interchangeable but edits to the processes will be needed /wanted (people relate to "their workflow"/"their forms", providing it is not expensive) and edits will also be needed to make changes to terminology.
  1. http://www.kwkeirstead.wordpress.com
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Max J. Pucher
Blog Writer
Accepted Answer Pending Moderation
The answer is NO, but ...

An orthodox business process will have boundaries encoded in the flow and the logic. There is no additional boundary necessary or even possible. Therefore a large number of process variants are necessary to apply the process at different organisations.

If you submit to a goal-oriented process definition and execution such as in ACM where the business user is capable of adding and modifying work necessary then boundary rules become essential. Boundary rules are needed for action compliance, data validation, event handling and checklists. That does away with the need for pre-defined flows and the process becomes universally usable. It does not require the usual high-number of flow variants.
Agreed. Now I gotta go gargle with Listerine.
how did the gargling work out?
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Great question! And my take would be "absolutely". As one would have to procure to segregate the technical scope of a BPM implementation (not to duplicate legacy or ERP functions, for instance), the business processes themselves should be segregated by their core functions and goals as well. That allows for clear ownership, associated project management control and focused KPI measurements. Of course, that does NOT mean process isolation or silos! Through methodologies, process frameworks, standardization (such as BPMN, CMMN, DMN etc.), even API's, conceptual as well as technical integrations will be achieved. It is of absolute importance that processes are horizontally and vertically integrated and "talking" to each other. However, in a capacity of highly standardized pieces of the bigger BPM puzzle and not as huge process blob.
NSI Soluciones - ABPMP PTY
Kay, that is a typical non-answer with a list of platitudes about BPM, worthy of any politician ...
  1. Kay Winkler
  2. 3 years ago
  3. #3610
:) I will take that as a compliment! But in all seriousness Max, I don't know how to put the answer any clearer than "absolutely". In short, I absolutely I agree that processes have to be put into boundaries, while avoiding to create knowledge and data silos.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
In short: it depends (best answer, ever ;) )

From my point of view, it is a matter of flight height.

If you are high, you see the macro-process, and yes, it is definitely interchangeable between organizations or business units. The set of tasks/steps/conditions/flows will be similar, as the KPI's and the involved roles.

But, if you are in the detailed view of the same process (ground level), well, it simply won't fit other organizations or business unit needs. Some boundary conditions will be different, some special cases should be treated different, some exceptions arise.

This is because process templates work. They are not definitive processes to be used as-is. They are a starting point, useful for most organizations (view from the heights), that must be adopted, adjusted and customized to particular needs (view from the ground).
CEO at Flokzu Cloud BPM Suite
I can't disagree more. There is just work that needs to be done to achieve goals. Flight height is an abstraction of process perspective that makes them look simple when they aren't. But you said it: 'The REAL process does not fit anyone else than the tiny little organisational unit it was hardcoded for. Even with process templates you end up coding AND MAINTAINING a huge amount of process variants, killing any opportunity at standardisation and therefore cost savings.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Bravo the question on boundaries and process. Earlier correspondents have shared important insights on technical implications of boundaries and process. The concept is super important because meaning is very much dependent on defining a boundary of any object -- for example, in practical terms a failure to manage project scope is the doom of many projects. And yet the question of boundary, limit and scope keeps coming up.

Let's look at another aspect of boundary, which is the "edge of the corporation"; the edge defines the limits of the firm. I described the relevance of the definition of the firm to business process in the BPM.com series with Paper I, Part 3 -- "Link Work Of Business And BPM Software Technology"

Per the paper, business processes necessarily tend to standardization, for economic reasons:

"The idea that repetitive work is a special case, ignores economic pressure on organizational structure. In fact, repetitive work is and has to be the dominant pattern in any business.

Nobel Prize-winning economist Ronald Coase is noted for his 1937 insight that defined the tendency for organizations to evolve to a certain size. The tendency to a given size was based on the costs of organizing the business of the organization (specifically transaction costs of contracting out versus direct management). The result, which is also nicely intuitive, is that organizations tend to specialization. Specialization has always been characteristic of organization, but with global trade we can see specialization increasing more and more.

Almost by definition then, organizations are built around the idea of people working together doing the same thing over and over again. Except in the short term, repetition is necessarily part of all business models. (And even mass customization and case management still fall under the umbrella of specialized, repetitive work – it just depends on the level of analysis one is using.)

Why is the economics of the firm relevant to the question of the importance of process boundaries? Because the set of processes maintained by most organizations will be limited. The limits on the variety of processes maintained by management is driven by the economics of organization, especially the cost of building and maintaining processes. A typical firm will be successful when they perform work that others want -- and when they do that work as bounded processes, very, very well.

Here's a thought experiment. Consider that boundaries are unimportant to business processes. The idea is almost inconceivable. One ends up with unappetizing spaghetti.

On technical criteria then, good process design mandates process boundaries. But also on economic criteria, a successful business is likely to be built around a tightly defined set of bounded and well-practiced core processes.
I agree. Your definition of boundary has nothing to do with mine. And yes, you always end up with spaghetti when you do BPM ... but usually spaghetti tastes good .. so this must be tape worms or the like ... ugghhh!
  1. John Morris
  2. 3 years ago
  3. #3614
LOL Max stretching out the spaghetti metaphor. Maybe Peter could make a BPM.com question "most effective BPM metaphors to use with business executives". : )
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Yes and no ( instead of "it depends" ). Unique processes of each company are created from a limited set of universal "practical process patterns". See [ref1].

  1. http://improving-bpm-systems.blogspot.ch/search/label/practical%20process%20patterns
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
In general, as suggested by my brother-in-barbed-business-banter Emiel, the boundaries of BPM are the boundaries of the problem you're trying to address. I'd add that this quality distinguishes BPM from typical business silos. From the point of view of the customer, or supplier, or internal end user needing to accomplish one or more goals, organizational boundaries are arbitrary, whereas BPM process/application boundaries are natural. The former are created by management, tradition, and politics, whereas the latter conform (or ought to conform) to the dimensions of the underlying goals themselves.

For example: Need to know where your shipment is? That information may be spread across a variety of organizational units: shipping and receiving, AR/AP, customer service, and sales. Those boundaries are artificial from the standpoint of the guy who hasn't yet received the 12" LED desk lamp (black) he ordered last week. BPM driven applications, properly configured, offer a unified view of the data and processes the customer needs in order to sort the problem out.
Scott's opinions only. Logo provided for identification purposes only.
A boundary by definition is something you are not supposed to step over. So boundaries in BPM are only related to work items or ACTIONS. They are not related to organisational or application boundaries. As you say, one huge advantage of process management is that it enables a business to transcend both as long as the value stream contains an agreed upon goal to be achieved. Boundary rules are mostly to ensure compliance. So when the question asks if there should be boundaries in BPM then there is no need to elaborate on corporate boundaries. You are not talking about the same thing ... IMHO
  1. Emiel Kelly
  2. 3 years ago
  3. #3611
Reading all the comments, made me indeed aware that I interpret (and maybe Scott, too) the word "boundary" a little different. I interpreted it as "where does a process start and where does it end". Nothing about technical boundaries, organizational boundaries or compliance things.

So to me it's just "I have a problem" till "problem is solved"

And the process between can come in many variants. If your problem is "I want to move to another house and need a mortgage", then the process to solve that problem will be quite straightforward and maybe even predictable upfront.

If the problem is "I've been suffering from headaches for 3 weeks now", the process to solve that might not be known upfront and can go many ways depending on the progress.

So, understanding the problems you want to solve, should define what your process will look like. "Conveyor belt like", or "I have no clue yet what we will do for this case"

Would you call that boundaries? I don't care.

Max: So when the question asks if there should be boundaries in BPM then there is no need to elaborate on corporate boundaries.
Actual question: How interchangeable are processes between organizations and divisions within an organization?

Looks like today may not be the day we break out long streak of disagreements. :)
Really not much to disagree about/ agree about.

Industry areas have boundaries (government mandates); organizations define boundaries (i.e we manufacture watercraft made in the USA); ROIs and annual budget allocations define Case boundaries); then, at the process/process fragment/step level, we are looking to BPM to provide orchestration with an appropriate level of governance that prevents/discourages extreme, unwanted, deviation away from policy/procedure and Case level boundaries.

Max is right with "So boundaries in BPM are only related to work items or ACTIONS" because the purvue of BPM (for most) does not extend to ACM or to the formulation/upkeep of corporate strategy.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
By definition every process has a start and finish but otherwise should be no boundaries such as seamless interactions between processes and of course sharing data. For example in a case management system could have over 50 processes supporting individuals and teams doing whatever. We even have the capability to build as a shared service to allow other departments to use with customisation yet allowing individual departmental and "group" view of activity all under approved authorisation. Everything should be reusable even supporting different languages ...
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Re-visiting my comment above where I got sidetracked by a response dealing with the definition of a process.

Does anyone disagree with . . .

"boundaries" for Cases\run time process template instances are "actions that do not advance the organization's strategy to preserve and augment competitive advantage". ?

In English, ". . . don't design processes to manage work that is not at least supportive of business strategy".

In addition to constraining the scope of processes, as above, we should guard against allowing legitimate process template instances to take on work when we know there will be a poor outcome.

e.g. we are about to start an assembly of a series of parts and QA has posted an alert that certain parts are off spec.

Here, we reasonably want to have in place a pre-processing rule set at the 1st step to detect alerts like this and block the process from moving forward.

Conclusion: Every "end-to-end process needs boundaries, many steps along processes along process fragments or at ad hoc Case insertions (processes of one step) need or can benefit from boundaries.
  1. http://www.kwkeirstead.wordpress.com
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Unfortunately, this discussion is a nice example of our (and the whole BPM) inefficiency because of the terminology chaos......

"Cordonnier sans chaussures"?
  1. John Morris
  2. 3 years ago
  3. #3615
... maybe an ontology would help. Except for front-line practitioners, ontology is too academic. Even knowing the word may be career-limiting, unless one is working for an F1000 company, which affords a specialist R&D group.
Yes, John, I should have said "terminology and ontology" chaos. BTW, ontology is not "too academic" any more, EU is using it a lot and some international standards express their terminology as an ontology.
The question, as I read it, seemed straightforward, but the responses, for sure, are all over the place. (""inefficiency").

Is it not true that most systems have, by design, boundaries? So why not processes?

i.e. the camera works within a temperature range 0 to 40°C; the ATV should not attempt to engage slopes of more than 15 degrees, the car tire tread must be greater than 3 millimeters for acceptable
traction/stopping distance. Algorithms similarly have boundaries.

I don't see how, in a Case management system where processing of structure/unstructured sequences in theory could be engaged by a user in any order, a Case could be properly managed in the absence of in-line pre-condition rule sets at process anchor nodes.

My group is building a Homicide Investigation app that has very strict protocol to be followed on the one hand ("chain of evidence") then, within the same Case, a need to "connect-the-dots"

There are no constraints relating to the engagement of processing of any "process template instance" other than pre-condition rules at the anchor node of each process. ("you may not engage processing here unless/until you complete ____".) Of course the site supervisor can override the software but the consequences of doing to may jeopardize the entire Case.
You are perfectly right Karl. The system-of-interest must have boundaries. But, there is always a bigger system.
  1. John Morris
  2. 3 years ago
  3. #3621
+1 Karl -- "Is it not true that most systems have, by design, boundaries"? I mentioned above a thought experiment where "boundaries did not apply". The thought experiment was not really successful, because the proposition was "inconceivable". Maybe that's its own success. I tend to think in terms of systems (having read something by Ludwig von Bertalanffy a long time ago). Practical pragmatic systems work is great, but sometimes a theory is helpful too. So also +1 Alexander, "ontologies are now no longer only found in academia"...
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
The necessity of "in-line pre-condition rules at the anchor node of each process", should be a no-brainer to any BPM specialist who has transitioned to ACM, is in the process of transitioning to ACM, or feels they should be thinking of transitioning to ACM. Never mind luddites, few of us can afford to spend time on them.

Say we have a BPM process. The reason it is a process is because of the presence of directional arcs that connect the nodes.

Under ACM rules, workers are free to skip steps, re-visit steps, record data at steps not yet current, even quit a process in mid-execution

Say we delete all of the directional arcs.

What do we end up with ?

Answer: a set of tasks, where, in the absence of pre-condition rules at each task, you have no concept of precedence, no way to provide orchestration.

Rule #1 for ACM is "don't force staff to follow rigid protocols - follow the protocol, don't follow the protocol"

Rule #2 for ACM is "two workers, one following available process templates, the other not following available process templates, need to basically achieve the same outcome on repetitive work".

Steve Jobs quote: "“It doesn’t make sense to hire smart people and then tell [force] them what to do; we hire smart people so they can tell us what to do.”
Just in case. . . transitioning to ACM does not mean one has to abandon BPM.

BPM is a core component to ACM,

If you doubt this, conceptualize a map where you get up in the morning, put on your pants, then shoes, then socks, then underwear. See how that works . . .
  1. John Morris
  2. 3 years ago
  3. #3624
At a meta level, the whole BPM/ACM is same -- it's just a question as to where fuzzy process graph and logic are stored. ACM is an acknowledgement that the real world is more complex and variable than can be explicitly and cost-effectively modeled in BPM. So we'll push some of the modeling and logic into human brains, and deliver an orchestration platform which is more forgiving, and relying substantially on humans (or robots). BPM existed before workflow, in the world of "business forms" (up until about the 1980's I think). After a while one is left wondering about all this technology though. If ACM is back to the future, are we really any further ahead? Of course ACM makes an individual actor orders of magnitude more productive than someone working on paper forms.
@John.. where to store the fuzzy process graph and logic is an issue that perplexes many.

How about using a model similar to a Chinese Restaurant?

You can order "a-la-carte" or you can order various dinners. No problem at all with a "dinner for one for two", or, if you like, "two dinners for three for four" - the restaurant is happy to oblige. Some have "all -you-can" eat buffets.

We thought about this and came up with the absolutely innovative solution of ..... wait for it.... a "menu".

At the menu you find end-to-end-processes, process fragments, then, for each step along any process, we find a "process of one step" so that users are able to re-visit completed steps, record data at not-yet-current steps. etc.

One of the menu items features a process of one step sporting nothing at its data collection form but a blank memo field - you can type in or engage voice-to-text, whatever you like.

Rule sets are at forms (i.e. attributes of steps).

Our "solution" seems to cover all bases.
@John.... I really like "ACM is an acknowledgement that the real world is more complex and variable than can be explicitly and cost-effectively modeled in BPM "
@Karl, what are your definitions of ACM and BPM?
@Alexander. I am happy with the "What is BPM" definition at bpm.com

“Business Process Management (BPM) is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.”

As regards ACM, a search at wfmc.org for "adaptive case management" under BPM glossary, gives this

"A productive system that deploys not only the organization and process structure, but it becomes the system of record for the business data entities and content involved. All processes are completely transparent, as per access authorization, and fully auditable. It enables nontechnical business users in virtual organizations to seamlessly create/consolidate structured and unstructured processes from basic predefined business entities, content, social interactions, and business rules. It moves the process knowledge gathering from the template analysis/modeling/ simulation phase into the process execution phase in the lifecycle. It collects actionable knowledge—without an intermediate analysis phase—based on process patterns created by business users. ACM differs from business process management (BPM) in that the case information is the focus and the thing around which the other artifacts are organized. And it is the case information that persists for the long term."

This one apparently comes from "Collaborative Planning and Social Business"

Personally, I think "It collects actionable knowledge—without an intermediate analysis phase" is on somewhat shaky ground. For sure, if you data record all interventions at a Case then you have "actionable knowledge" on what got done at the Case but not on what did not get done at the Case.

I don't see the harm having an "intermediate analysis phase" based on data across similar Cases, so why they put in a qualifier is a mystery to me.

I am sure there are other ACM definitions floating around.
I get 305 hits for BPM at this Forum compared tp 90 for ACM
Thanks @Karl. Now we need a definition of "business process" and "business process instance" (or "case"). Please note that the definition of BPM mentions "business activity flows" which are actually "cases". So far, the sentence "ACM differs from business process management (BPM) in that the case information is the focus" is not valid about the difference between ACM and BPM. Also " the case information is the focus" sounds like that ACM is an operational tool. The sentence "It collects actionable knowledge—without an intermediate analysis phase—based on process patterns created by business users" is rather dangerous because it puts popularity more important that correctness. “What is right is not always popular and what is popular is not always right.”
Probably a good idea to do a few rounds on “business process” and “business process instance”.

[ “Business process instance” (or “case) ] bothers me because my Case repositories almost always end up with a set of interventions that are guided by multiple business process instances. These include ad hoc Case interventions consisting of one step each. So, a “Case” is not the same as one “business process instance”.

I have no problem with [“business activity flows” which are actually “cases”].

“The case information is the focus and the thing around which the other artifacts are organized” in the Collaborative Planning and Social Business source material sounds a bit contradictory – surely in “Case” it is the Case itself (i.e. a bucket) that has the focus and, if we dare to enter, we find Data + Rule Sets + RALB + FOMM at work?

When you consult a Case History, this, for me, is where you see “information”. I am not entirely sure why we have to say that “information” is “actionable knowledge”.

I have spent years trying to highlight the difference between knowledge and information and am pretty confident that what we have in Case Histories is “information”.

Case Histories are chronological, date, time-stamped, user-“signed” evidence of interventions (data as it was, at the time it was collected, on form versions that were in place at the time the data was collected).

The main purpose of a Case History, aside from avoiding lawsuits, is to enable decision-making i.e. what should the next intervention be at this case ? - do we simply execute the BPM steps that are current or do we skip, re-visit other steps, record data at not-yet-current steps, invent a step, exit from a particular process instance or shut down the case (e.g. patient has died, plaintiff has withdrawn, customer has cancelled the order).

Knowledge, on the other hand, is best presented to users in multi-root trees (things within things within things) with a very important qualifier of being able to carry out free-form searches across whatever the domain is.

Knowledge yields information, information enables decision-making/action. Knowledge in KBases is not the same as user knowledge /experience/intuition brought to bear in a Case at a particular moment along a Case timeline.

We may need to re-visit “adaptive” – I take this to mean the ability of a specific case outcome to be impacted by a particular guided execution of a set of structured workflows and ad hoc interventions.

I need to re-read your book, re-read "Mastering The Unpredictable". I also need to look up satisficing, optimizing and adaptivising in “A concept of corporate planning” (Russell L Ackoff).

The other treasure trove we have are the Questions at this Forum. We need to be able to ask “what did Alexander Samarin write about adaptive case management?” from 2013-2017. I will be talking to Peter Schoof about this in April.
  1. John Morris
  2. 3 years ago
  3. #3639
Very good discussion concerning the relationship between "BPM process instance" and "case".
@John.. Thank you for your expression of interest - I have been pitching Case Management to healthcare since 2000.

Here is 201 5 article "It's all about that Case, 'bout that Case"

  1. John Morris
  2. 3 years ago
  3. #3641
LOL @Karl "All About The Case" . . . but also your note about patient histories is key . . . here in the Province of Ontario, big consulting has been billing 8 figures + for patient records -- and our family doctor hasn't seen any changes yet. Also reading your post brought to mind the idea of "narrative", i.e. the medical story of the patient. Narrative is also related to business process too and getting increased attention as software is beginning to come out of the lab on this.
@John ,, (sigh) - your doctor should not hold his breath - he WILL see changes but unless the 8-figure folks have made BPM a core component of their deliverable, the outcome will be to transform the good doctor from a physician into a data troll.

He will not like it.

Narratives are important - you have to write a script (tedious, takes time) but the results are things tend less to fall between the cracks. Looks like we came out of the lab early, as we have had narratives in our Case Management apps since 1995.

Curiously, I only have one healthcare customer using the narrative generator.

Law enforcement customers, on the other hand, seem to relate very positively to narrative report generators - we developed a hostage, barricade, suicide subject profiling/critical incident management system for DOJ./FBI and, as I recall, each Case received a narrative toward the end of the workflow.
  1. John Morris
  2. 3 years ago
  3. #3646
Maybe another question for the Forum, something along the lines of "BPM, Case, narrative, human understanding and decisioning" . . .
  1. more than a month ago
  2. BPM Discussions
  3. # 13
  • Page :
  • 1

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