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
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.
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.
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.
- Kay Winkler
- 3 months ago
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).
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.
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.
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. :)
- E Scott Menter
- 3 months ago
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.
- Emiel Kelly
- 3 months ago
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.
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.
"Cordonnier sans chaussures"?
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.
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.”
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 . . .
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.
“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.
[ “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.
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.
- Page :
However, you are not allowed to reply to this post.
Join the Discussion
Webinar:Your Digital Disruption Survival Plan
Thursday, July 13th @ 1:00pm Pacific/4:00pm Eastern
In this fast-paced and informative roundtable discussion, three leading experts on business process management will explore the right methods and capabilities that make difference between success and failure with enterprise process management initiatives