What is the role of two-dimensional process graphing for knowledge workers in Adaptive Case Management (ACM)? It is a given that an ACM system must support some form of process plan. This post explores how a knowledge worker might specify a process plan, what are the requirements on that means of specifying, and what technical training requirements exist for the workers who specify the processes.
Note: this is an excerpt from a position paper I submitted to the First International Workshop on ACM in Tallinn Estonia on Sept 4, 2012 in conjunction with the BPM 2012 Conference.
Within our current technology setting, essentially all discussions of business process make the implicit assumption that Business Process Modeling Notation (BPMN) will be the graphical language for expressing the business process. For the purpose of discussion, consider this decidedly radical proposition: “Any work support system that depends upon processes designed with BPMN (or BPMN-like languages) cannot be considered an ACM system.”
This statement is intentionally bold in order to question our basic assumptions about process modeling. Is it reasonable to expect case managers to ever have the skills to use a two dimensional BPMN-like process language? If not, does this lack of skill in itself become a barrier to effective use? The question is not how BPMN might have to be changed to suit case workers. What this is proposing is that whenever a system depends upon a two-dimensional design format for describing the processes, that dependence itself makes it unsuited for use as an ACM System (ACMS). The proposition is that an ACMS absolutely must not have BPMN, in order to be considered an ACMS.
Please note: this discussion is about the case manager’s use of BPMN for planning. The underlying system might be implemented in any technology: C++, Java, PHP, SQL, or even BPMN if your choose. This discussion is about the representation of the processes that the case manager must deal with. The case manager is a knowledge worker, like a doctor, a police detective, or a judge. A central assumption with ACM is that the processes are unpredictable, and MUST be viewed and modified directly by the case manager. We discuss those things viewed and manipulated by the case manager, and whether BPMN is appropriate for that purpose.
Definitions of Terms
Task – A task is the finest grained unit of activity. It is simultaneously, the finest grained unit of goal. Case managers define tasks/goals, and then break those into subtasks/subgoals. Eventually one gets to a level where the piece of work is assigned directly to someone. In this discussion we need make no distinction between the concept of a goal, a task, or an activity.
Process – A process is defined as a sequencing of tasks/goals. It is more than simply a collection of activities; in many cases tasks/goals must be sequenced in a particular order. Task A is anticipated to be and might be required to be performed before task B. The case manager needs some way to express this. There are higher order patterns like branches and parallel paths which might also be part of the logic of a process.
BPMN: This formally means the Business Process Modeling Notation standard developed by the OMG. At the time of writing, BPMN has gained such predominance that more than 95% of typical process professionals assume BPMN is the graphical language of choice for describing a business process.
BPMN-like: for the purpose of discussion, this term is used to describe any graphical 2 dimensional flowchart-like language. The broader question we hope to ask is not whether BPMN has exactly the right constructs, or what additional expressibility might be needed, but rather whether any 2-dimensional formalism can possibly be useful for ACM.
Business user: a person who uses the system who is not trained as an Information Technology (IT) specialist. All office work involves computer use at some level. Most users are not programmers. They have no specific training in design or management of IT system. When we talk about business user, we mean those people in the office without training in IT.
Developer: a person trained in IT and in this discussion is used synonymously with system administrator or other technical roles.
Case Manager: a business user who is responsible for a case in an ACMS.
Setting
In the early days of business processes management – we called it business process reengineering back then – I published a number of papers about graphical business process definition languages which were designed to be used by business people directly[1,2]. This visual language is surprisingly similar to BPMN with some superficial differences. The main elements were tasks, represented as ellipses instead of the rounded rectangles that BPMN uses today. Transitions between activities were arrows. There were specific nodes for branching and joining either parallel or alternative flow. Start and end nodes were hexagons instead of circles in BPMN. Most notably, events were represented as small circle on the edge of an activity. The diagrams that I drew as examples back then can be isomorphically translated into a BPMN diagram today, and the readability / expressibility is essentially the same.
I call these 2-dimensional languages because they are graph-like. An alternative is a simple list of tasks which does not have any X & Y position information, just a linear order. I have not seriously considered 3-dimensional languages. If you know of any 3-D language that show promise in being easier to use by business users, please comment and let me know.
At that time at Fujitsu, I was able to produce a system that supported the graphical definition of business processes, and the enactment of them.[3] The most important aspect of that system was the ability to change the process at any time by anybody. An application would allow any business user of the system to retrieve and edit a business process at any point in time. In the later 1990’s this was all recoded in Java as an applet that ran in a browser so that any business user of the system could edit processes at any time without having requiring software installation. Simply point the browser at the server, to retrieve your task list, and you can also edit any process as well.
After 10 to 15 years of experience with customers using this system, my observation is that the business users essentially never design a graphical business process. Processes are always designed by either developers, or a specially trained business analyst. By “specially trained” I don’t mean to say that this is exclusive and esoteric. There are process enthusiasts who train themselves on process technology using freely available information. Those enthusiasts do not represent the typical knowledge worker. Even managers who design detailed interaction patterns for their team, will rarely actually draw a picture of the process themselves. Those innovative managers will hire process specialists who will draw the diagrams for them. Even office workers who are comfortable reading a process diagrams and who use them for training about a given process will rarely actually draw the process.
My conclusions (given here without any evidence) are that:
- Drawing a diagram requires a kind of abstract thinking about the process that a business user is not comfortable with. Instead, they want to define activities in terms of responsibilities on people, and not in terms of a flow of a token through a series of tasks.
- Drawing a diagram actually involves some programmer-like skills. For example, a branch node requires variables, which need to be set up in advance so that the branch condition can test those values. Separating the information into discrete units in a format that can be tested is a developer skill unfamiliar to business users.
- Modifying someone else’s diagram is particularly difficult because all of the assumptions that went into drawing the diagram are not present in the diagram. A simple example is that one node may initialize a variable, and another may use that variable, so switching the order of these nodes would break the functioning of the diagram. There is no way to indicate in the diagram might or might not be safe. Like most programming languages, it is designed to embody a set of assumptions, and not to necessarily express those assumptions. We can say that the original rules and assumptions are hidden by the resulting process diagram.
Relevance to ACM
A graphical process definition plays different roles in different styles of process technology. For example, in Process Driven Server Integration (PDSI) – a name for the kind of BPM which is commonly associated with a Service Oriented Architecture (SOA) environment – the process diagram is part of the programming process, or it may simply be in the design spec and completely replaced by the implementation. This programming and designing of the server integration is done by programmers, and not business users, so use of BPMN is not impeded.
For Human Process Management (HPM) – a type of BPM targeted at modeling routine human activities – it is a process specialist, or possibly a programmer, who designs a process which is used by the process participants. Typically in HPM the end user does not have to design processes.
The same is true for Production Case Management (PCM) where once again you have specialists who define the interaction patterns, which are developed and deployed as a finished application to the production users.
ACM however is different from these all of these because there is no distinct design phase. Designing and performing the work are done at the same time. There is no distinction between the users of the system, and the designers of the system. The knowledge workers (i.e. business users) themselves must design the process. Even if templates are supplied by process professionals, the case managers must be able to modify the process to fit their specific need, and so must be aware of all the assumptions built into the process diagrams. The essence of adaptive case management is that the processes are modified by the case managers, and are exchanged between people, in order that the workers can find the best solution for their particular field and situation.
Use of the Language
BPMN-like languages were originally designed for a completely different purpose and mode of use from ACM. Like many formal languages, the idea is that an expert will use the language to express something very precisely. The expression will take into account many understood rules, but may not express those rules directly. Using all this successfully requires programming skill along with an investment of time.
The value proposition is that the up-front cost of developing a process will be compensated by the increased efficiency later of the process. Thus, if you have many identical executions of a process, it is possible that a small increase in per-instance efficiency can counter balance a large up front development cost. Thus in most styles of process technology (PDSI, HPM, PCM) an investment up front is not a particular problem.
For ACM the process is designed by the case manager as they do the work, and usually just for the benefit of that one case. If things work out well, that process may become a template and reused many times, but each case manager must justify the effort of creating the diagram in terms of the case they are currently working on. From this see criteria 1:
- Ability to design a basic process quickly with very little investment by the user is far more important than the ability to define a precise process which uses more time an attention from the business user.
In ACM, process change is an everyday activity. If the ACMS were to require skill in BPMN to change the process, then the case managers without that skill will be prevented from using ACMS as intended. This brings us to design criteria 2:
- Process design must not require a skill beyond what business users possess.
Even if the business user is an expert in BPMN, they still may find it difficult to change the process because of the hidden assumptions problem. BPMN-like languages are designed to express a final process, and not all the steps and decisions along the way to develop the process. This brings us to the design criteria 3:
- For a process definition to be modified by business users, there must be no hidden assumptions.
A Process Language Designed for Change
The third criteria deserves a lot of discussion. It either means that a tremendous amount of additional information needs to be supplied with the program to express all the decisions behind the way the process is designed, or it means that there is a severe limitation on how complicated you process can be. I tend to believe the latter.
A case manager needs to be able to change a process quickly and effectively every time without error. This means that all possible changes need to be valid changes. If the case manager needs to switch the order of two activities for a good reason, there should be no possibility that such a switch can cause a failure of the process to execute. A language that is designed for change will allow (almost) any change,and will walk you through the resolution of any problems that arise because of the change.
It may not be possible for a programmer to express all of the reasons for designing a process in a particular way: why a particular structure, why a particular sequence, why a particular variable name, etc. It is not a matter of simply coming up with a reason for a particular approach, but these assumptions have to be expressed in such a way that they remain meaningful after the process has been rearranged. Writing all the rules behind what possible future process recombinations might be valid strikes me as being similar to proving the correctness of a program, something Gödel proved impossible. Even if it is possible, we can be certain that it is far beyond the skills and patience of a busy business user.
For this reason, I think that the right process definition language for ACM will be one that appears, compared to BPMN, to be very simple. It will appear to be very loose, flexible, and unstructured. However, it will be such that every business user can read and understand without special skills, and it will be one that can be changed in any way, without causing inconsistency. Some will question the utility of such an approach, but this is a case of “less is more”.
Other References
Frank Michael Kraft made a post called Adaptive Processes and BPMN where he asks the same questions. He points out that there are different styles of using BPMN. Different styles mean that two business users might use BPMN in different ways, and this is a problem if one tries to copy and modify the other’s process. It seems that this implies another criterion: the language must not dialects or specializations of usage that might differ across users.
He goes on to say that there might be an “Adaptive Style” of BPMN. If this style was enforced in order to be universal, it might be possible to avoid his dialect problem. It might even be possible to limit the power such that there are no hidden assumptions. I would have to see the details of “Adaptive Style.”
The litmus test will be: I can copy a task from one process, past it into another process, and it works. I can take a task at the end of a process, and move it to the front of the process, and it works. I can take a task, and duplicate it at some other point in the process, and it works. There are many ways to achieve this. One is to automatically “fix up” any syntax problems that arise. Thus, if the activity requires certain inputs from the process, the act of pasting it automatically adds to the process whatever is needed to provide those inputs. There are some simple cases that can be automatically handled this way, but you should also realize that there are some difficult cases that will be impossible to handle. One can attempt to express within the activity all of the external requirements — but this is extremely tedious, if possible at all. Thus the ability to patch things up is questionable at the basic level.
Max Pucher talks about “self healing” processes, but shows that it difficult or impossible to achieve in a post called Flowcharts and Goal-Orientation. He says “A process flowchart assumes all-out predictability” and goes on to say “Flowcharts Can’t Model Goal-orientation.” He has been openly opposed to the idea of using flowchart style languages for ACM, and this is well covered in a post “The Problem with BPM Flowcharts“. He says “BPMN 2.0 and flowchart models cannot represent real business processes, because a large business clearly is a complex adaptive system that consists of individual acting agents with its employees and customers. Trying to simplify a complex business into a ‘complicated’ one by decomposition into small steps, makes the model unable to adapt to the customer agents or to other environmental changes. Agent interaction is emergent and not designed.”
Peter Schoof hosted a discussion topic: Do we need a new modeling language for more adaptive processes? It is interesting to note how many of the commentators hold the assumption that BPMN is the language for ACM processes. This is some indication of a general misunderstanding of the distinction of ACM and other forms of BP technology. But mainly there is a feeling of backlash that there are too many standards today. I think we all feel this way: fewer standard proposals would make our lives easier. Wishful thinking, but the business world is a complex place: we should not expect simple solutions. I reject outright the accusation that this is just a ploy to sell books. However, we should do a thorough search of existing languages, to see if something might already exist that is not a flow-chart like language, and better meets the needs of the knowledge worker.
This is also a topic I have touched on before in “BPMN 2.0: no longer for Business Professionals” and followed up with “BPMN vs. professionals, 2.0“. These posts were discussing BPM, but clearly reflecting the realization that BPMN has become a developer oriented language. Please don’t misquote me as being “anti-BPMN”. I am a huge supporter of BPMN and have been for many years when it is used for the appropriate things. I am not against BPMN, I am just against the notion that it is the perfect answer for all questions.
Summary
The goal here is not to state any conclusions in this paper, only to raise questions for discussion. I hope that the results of the discussion can produce a set of actions items that can resolve the issue. What experiment or measurement is necessary to determine if flowcharts can be effectively used by business users? What experiment would show that checklists function more effectively? How can we determine the likelihood that business users will learn enough formal process modeling skills to be effective at ACM?
If you are able to attend the workshop, please come and join in on this discussion. Or comment below.
References
1. Keith D Swenson, A Visual Language to Describe Collaborative Work, Proceedings of the International Workshop for Visual Languages, Bergen, Norway, Aug 1993, see http://kswenson.workcast.org/1993/199308_VL93/VL93.pdf
2. Keith D Swenson, Visual Support for Reengineering Work Processes, Proceedings of the Conference on Organizational Computing Systems (COOCS ‘93) November 1993, See http://kswenson.workcast.org/1993/199309_COOCS/Coocs93.pdf
3. Keith D Swenson, et. al., A business process environment supporting collaborative planning, Journal of Collaborative Computing 1 (1), Chapman & Hall, 1994, see http://kswenson.workcast.org/1994/199405_Journal CC/1994_JCollabComputing.pdf
Keith D Swenson, Workflow for the Information Worker, Workflow Handbook 2001, Layna Fisher (ed), Future Strategies, 2001, see http://kswenson.workcast.org/2001/Workflow for the Information Worker.pdf
Thinking Matters 
Hi Keith, great post and summary of ACM versus flow-diagrams.
BPMN allows in principle many add-ons and variations of its language and structure but what you say is true for clean BPMN 2.0. We have expanded BPMN in function and at the same restricted it’s use by the business user through menu-driven interaction and then it becomes usable if the implementation is ‘model-preserving’. Meaning you execute the model that you can also modify at any time. Through the menu-driven approach one can guarantee that the user can’t make non-executable changes. The flow-diagram basically becomes documentation only and not the means of design.
I am not in full agreement that a goal, task and activity are identical in concept, if you mean different terms for the same thing. A goal is a declaration of how to verify an outcome. A task identifies an unit of work (including machine-only-executed ones) in detail, and an activity requests a performer to act according to his knowledge. One can throw them all into one by merging attributes but that causes a lot of confusion due a lack of clarity.
In terms of a language that could describe real (and thus) adaptive business processes, I have proposed numerous times that it must be business oriented and use business terminology and not a programming terminology such as BPMN. BPMN lacks the ability to describe business data and rule logic applied atomically. That is the main reason it isn’t sufficient for ACM. The only way this business terminology is usable is when it follows the ontology of a Business Architecture. Using the business terminology one can then describe business data entities, outcomes, goals, KPIs, tasks, activities, performer skill and authority, and a number of other elements such as the mandatory business content.
BTW Keith: Do you think we are even heard on a larger scale?
Regards, Max
I continually struggle with the goal/task/activity thing. Of course they are not exactly the same things. But when it comes to modeling, they are not modeled differently. I can say “your goal is to catch some fish” or I can say “your task is to catch some fish”. Successfully achieving the goal and successfully completing the task are pretty much the same things. Of course, “Find the Higgs Bozon” is a goal, not a task, because of the duration involved. The distinction between a goal and a task depends upon how easy it is to envision the exact actions required to complete. To a fisherman, “catch some fish” is a daily, routine task, but for me it would be a major undertaking. Your distinction of activity is that the person acts according to knowledge. Doesn’t the fisherman act according to their knowledge? Goal can change suddenly into tasks, and tasks can change into goals, when the situation (context) changes, so the distinction is not inherent in the description of the activity, but in the relationship to the context. What I see is that all three are “descriptions of intended activity” and the distinction is mostly your personal relationship to that activity. The real purpose stating that these are equivalent is to avoid the debate about the differences. In any case, ff I make a process diagram, I can treat goals pretty much like tasks: any place on the process diagram that I can put a task, I can also put a goal, and vice versa.
As for being heard: please pay attention to the ACM Workshop. This is the first academically approved discussion of the topic. Many professors, grad student, and analysts have viewed the discussion so far as vendor hype. A “fad”. Having some serious, peer-reviewed papers on the topic will legitimize it for mainstream (academic) audiences. Consider how you might support this activity, at least publicity or reference.
thanks for the comment.
Thanks for the reply, Keith. I find a lot of interest in European universities for ACM, I have been speaking at three already. The problem with universities is that they are too far from reality and in theory a flow-diagram describes how a business works. Also consulting companies such as Deloitte see ACM as the future of BPM, but that has not yet happened at the larger market, mostly because of the substantial money involved in orthodox BPM software and consulting. Anyway …
I can’t agree on the task and goal likeness. It is like saying having a goal is the same as doing it. That is simply not true. As you say yourself a goal can require multiple tasks and they can’t be mixed in any odd way. One could say that an activity request is like a goal, but also that is not correction because assigning an activity might not have a declaration of what constitutes completion of the work. A goal does define the completion criteria but does not define how to get there. it might be one or many tasks (predefined activities) or one or many activities. One could define activity and task as the same thing and a task without a work definition assigned to a performer is now an activity. It is basically what David Chassels describes as user tasks.
As I said one could declare that a task can have a completion definition and then the subtasks are the necessary units of work, but that is an oversimplification. Orthodox BPM assigns tasks and why is defined in the governance bureaucracy, while ACM defines outcomes and goals explicitly and makes them transparent. I think there is the need to discuss these differences because otherwise each BPM product can and will say: ‘Oh, we can do tasks that represent goals.’
A goal definition requires a data definition and a rule when the goal is reached. A task normally has no such functionality, but yes, one can add rules and then turn it into a ‘goal task’. That means that there is no plausible structure to the case because one can add and mix goals and tasks in any way. Further do I propose that the goals need to be upward linked to outcomes and operational targets (KPIs and SLAs).
Will look at the ACM workshop …
Hi Keith
Topical subject!
Some responses to you thoughts which I hope will help.
You are of course right BPR predates BPM. In the early 70s as a trainee Accountant an integral part of the audit was to map out the processes – talking to people and using a simple template map their activities. The purpose being to identify weakness where both audit should focus and then make recommendations to eliminate such weaknesses. The skill set was an enquiring mind and ability to engage with people. That should apply today? The reason why such “languages” as BPMN were required is down to the different world of IT!
I am puzzled at what a 2 and 3 dimensional “language” is about (sorry another turn off for business people). To the business person 3 key dimensions are simple; People their Roles and their Tasks. From this business activity happens. Goals objectives etc can be agreed and of course change will be required as circumstances change. Sadly IT has failed to understand and thus support such fundamentals. This is what drove our founders with a few core requirements; once only entry of information working in a horizontal flow updating as required – one version of the truth. An important element was no programmers; what do they know about business and recognising business logic never changes – people doing something to achieve an outcome.
Once these basic concepts are grasped then a new world of simplicity opens up. The early R&D indentified relative few “task types”, human and system that are required from “IT” to support people with required business logic. They are currently
User tasks
A normal task
A form task
A report task
A web report/form
A program task
A pending task
System tasks
A calculation task
A VB script task
An import/export task
An event task
A sub process task to a process (where libraries of frequently used function processes can be built up for re-use)
A Server Side Message Queue task for external links
A finish task
13 in total but some are client server orientated and not now used. Then the “link tasks” true and false with rules capability and that is it; this builds business applications core code need not change. In fact all this capability was built before it was decided to build a graphical interface to make it easier to build the required application. If you want to see how suggest your read the quick start guide 60+ pages on this site http://bit.ly/qlSUvM
On your conclusion points this new approach supports;
• Drawing the “diagram” is intuitive and once business realise that this actually the build of the application they start to engage. A quote from one user “It captures all my weird and wonderful ideas and all done without telling me that I am expecting too much!”
• Drawing a diagram does not require programmer skills (a core design principle). In fact the skill set is very similar to the old days of audit modelling. Some understanding of how relational data base works and how to manipulate data (as done in spreadsheets) will help. The point is build is driven by business skill sets end to end with IT resources in support ready to deploy.
• It is not difficult for anyone to follow the diagram and change if required. All tasks can have detailed description. Every thing is transparent easily accessed and there is no “programming” language used to build.
You concluded on something that we would support “It will appear to be very loose, flexible, and unstructured. However, it will be such that every business user can read and understand without special skills, and it will be one that can be changed in any way, without causing inconsistency. Some will question the utility of such an approach, but this is a case of “less is more”. The BIG difference is there is no need for a programming language to build – the core code does not change, there is no code generation or compiling. All far to simple for IT and no surprise all early adopters business driven indeed the business units did not involve their IT such was the distrust. But “IT” is changing and need guidance from forward thinkers seeing that there may just be a better way……..?
I see you are ex Fujitsu? After early R&D in late 90s we re-wrote and a John Collins joined us from ICL. He recognised immediately what we had being something ICL had failed to deliver (like many others). Did you come across him? He masterminded the rewrite and did a great job. Sadly he died shortly after he left us.
If you would like to make contact david.chassels@procession.com
David, thanks for the response!
About 3D: some people have experimented with 3-dimensional representations of processes that you can rotate and “fly through” but to my knowledge none of them ever really worked. I was referring to the representation, not the number of different aspects of a particular process diagram.
I don’t believe I came across John Collins, however Fujitsu is a big company, the ICL folks rarely interact with the branches in California.
About your system: I have been there. Your descriptions sound almost identical to the claims made about “Regatta” and “iFlow”. Believe me, a process could be drawn and executed without any programming. We had plenty of people say “it is easy” and I even ran sessions where a group of business users would learn to draw and execute their own custom processes. Read the linked papers.
The proof, however, is not that you can get some people to learn the system and claim it is easy. Please don’t tell me about the system and how it is designed (theoretically) for easy use. The real proof is to have a company full of knowledge workers who ACTUALLY USE IT regularly invent their own, and adjust other’s processes. If you have such a real-live organization in active use I would LOVE to see a careful use-case write-up about it. Consider submitting for an ACM Excellence Award.
What I found is that a professional, like a Medical Doctor, is waaaay too busy to use a diagram even if they know how to do it and it is easy. The doctor want to “ask Jim to do X” and does not want to draw a picture about it. A detective running a case might want “Frank to search the crime scene one more time”, and he wants it done now, not after he draws a picture of it. Instead of drawing a picture, the doctor will tend to simply call Jim on the phone and ask him to do it. The case manager is focused on one case, and adding a task for that. Making a rounded rectangle with the task description is not the problem: the problem is drawing the arrows to link them up. That involves thinking about what you want to do “next time” which is simply not the focus this case. So it never gets done.
Maybe your experience has been different. If so, please post a use case of how people actually used the product in a production setting.
Keith
For years we struggled to define what we had yes workflow then BPM but actually much more. I am beginning to see ACM as a slot – still BPM as a discipline but in delivery ACM. You are raising issues that we are able to address we call it formal and informal processes. One of our partners is a leading expert on value networks which by definition are not always defined in the formal processes. Your examples of the doctor and detective are good examples. Formal processes will ensure that information is created as required but the informal may not have outcomes that fit yet they are important. Users will not waste time to think about such actions as a process but where they need to hand on information already collected that would trigger the formal process likewise the reaction to informal requests where new information is sent in will again bring into the process. Sometimes the only parameter for the informal may be time which gives some control over allocated activity.
All this human interaction applies to any activity in business indeed I would argue that by having a good easy interface for users supporting them in their job of creating new information it empowers them to use their initiative to do a better job as the doctor and detective demonstrate. But this is a learning experience and if users are confident that “IT” could actually deliver on their new ideas (or more likely remove “bad” practice) then efficiency and job satisfaction rise. I do not see users wanting to “build” such capability but having a forum to place ideas will produce the result which can be quickly implemented by business specialists as “their” process.
Our 10+ years experience at UK Sport has seen simple changes implemented by users but we find they prefer to have changes discussed with the analyst who will then quickly implement – full version control with no disruption Why would a users who love helping athletes etc want to learn to implement changes to a “computer system”? We have been running their highly complex grant management for 10+ years and with exceptional results. The best audit trail in government, real time reports easy reporting at year end and costs to administer less that half of other bodies.
The statistics on changes are impressive and conventional “IT” would not support
75 process maps the applications with 226 over life cycle
2406 associated tasks with 5087 over life cycle
538 user interfaces (forms) with 1114 over life cycle
As you will be aware such an approach of control with empowerment is called Systems Thinking. Sadly “IT systems” have set back this movement pioneered by Dr Deming but with good supporting tools that think “BPM” and deliver “ACM” that trend will be reversed.
David, I am in agreement on the task types. I think they are necessary to make the work organization simpler for a performer. I think your list of tasks is however too technical (i.e. VB script or webform task) for a business user.
I just can’t agree on the flow-diagram. If you are working and want to assign work to someone right now, that last thing you want to do is to figure out a flow. You simply add a task (choose a predefined one if right), add resources and assign it to a person or a role, possibly make it dependent. To make work a lot more transparent and reusable I propose that it does require explicit and separate goal definitions. All kinds of people understand goals and they are the best way to define handover criteria between units of work and work completion.
Also events are in my mind not tasks and can’t just be any place in a flow. An event must trigger functionality outside the flow. In effect flow-diagrams can’t handle arbitrary events as they might require rollback of already executed work. So they are in effect pointless from the perspective of the real world of processes as they are being executed.
Hi Max
The only task seen by users is the “form”. So any tools that tackle BPM/ACM must have integrated presentation layer. In client server it was easy to build a form but web brings new
challenges. However at simplest a convertor builds a web form. All forms are is held as data and dynamically populated as required for the right person at the right time with right data etc – the power of being data centric. All this is well within Business analysts skill set. We find users just do not want to build it’s not their day job! Plus the more you do it the faster it gets. The optimal time frame is count number of forms required that becomes the number if man days to build whole application.
As for allocation of work that is all catered for in the pre built manager who can view activity allocate and re-allocate as required. Whist there is an event task I agree events happen as a result of previous activity. Yes there are always exceptions but they can be handled as exception with a separate escalation process. As knowledge is gained so such events can be recognised and catered for within the process.
On goals they are descriptions of what are we trying to achieve. Once agreed look at the steps required to achieve and start building – no need for final spec as change is easy as feed back received from users. New users will quickly pick up. Interesting consequence is that “knowledge” once in the domain of users now is in the domain of the organisation making it easier to bring in new users.
Full agreement on the presentation, less on users being happy with being data centric. Plus the data have to be linked back to the business systems and users can’t handle that part. So users just adding data to forms or creating forms makes often little sense. We have done completely dynamic forms to avoid design efforts and users in the end hated it. Then there is the issue of rule writing which again need proper and valid data. The only thing I haven’t seen in your description how incoming and outgoing content is handled in a case.
Overall you describe an adaptive case management approach so we are in principle agreement on how to tackle processes. Thanks for the detail.
PS: What all that means and I forgot to add that the user has to work with a business data model in his own words as otherwise it won’t work: hence the need for a Business Architecture. A lot more than a flow is needed but in a much simpler way and that’s basically what Keith was all about.
Great questions and thinking from which we all learn – pity our leaders do not do the
same!
Users only use see data that they need via the UI which supports once only entry of data even on the same form using intelligent ajax grids users love it – all very simple and intuitive.
The developer a business professional has to set up an appropriate custom data structure in the RDBMS setting up roles and performers etc (well with an analysts capability) but thereafter no need to worry about data etc all taken care of in our in built Business Architecture where data manages data. We have maintenance forms to allow ease of change when anticipated such as rules. We have a comprehensive tag library to aid connectivity for external legacy data. It all work very well!
I sounds like we are on same mission – systems thinking – to empower people but you have broken through we have not still in UK with many years R&D. But the market is ready…. And now I want to distribute – we are not heading to US that will be done by others – ideas welcome!
Pingback: BPM Quotes of the week « Adam Deane
I found the post and comments very interesting.
I’ve seen a lot of posts talking about Adaptive Case Management. What it’s not obvious to me is the essence of the term “Adaptive”. Is it possible to have a definition for it?
I have little experience on BPM and ACM but what I understood is that there are two different types of work: the routine work and the knowledge work. BPM fits for the former, ACM for the latter. Usually organizations cannot deal only with routine work or knowledge work. Both are needed (the truth is in the halfway). So, do we need separate approaches to improve the business process management or not?
Thank you in advance for any replies.
Regards,
Lorenzo
Lorenzo, ADAPTIVE refers to the capability of the on-the-fly creation of case work or processes and to save them as templates after completion. When the template is reused then it can be adapted as it is used to the current need. I also consider the use of goals as the organizing principle as an adaptive functionality. Not everyone does.
For me ACM encompasses BPM, but many basic ACM products do not have the capability to replace BPM. But you are right that both are needed but not in separate solutions but in ONE.
I made a write up on the meaning of “Adaptive” in the following linked post:
https://social-biz.org/2011/11/13/understanding-what-adaptive-means/
When it comes to adaptive in the digitised solution I would suggest three key areas.
1. In build the ability to rapidly change in iterative development. This allows a business focused spec that focuses on goals / objectives and the detail and can be addressed in build with users.
The time saved by not requiring a traditional spec should ensure quick wins
2. Continuous improvement over the years is a must have to reflect the ever changing environment at the front end of the business. There should be mechanisms in place to allow feed back to improve processes and there should be no fear of change. Good version control is required.
3. The intelligent process offering the ability for a process to adapt dynamically to users decisions. This will bring new ideas to improve both outcomes and importantly the user experience
@Max, Keith and David
Thank you very much. I really appreciated your replies.
Regards,
Lorenzo
Pingback: The Limits of BPMN « BPMS Watch
Pingback: Как идут дела у адаптивного управления делами « Архитектура информационных систем
Pingback: Obizware - Blog – The Limits of BPMN
Pingback: Imperative vs. Declarative Processes Models | Collaborative Planning & Social Business
Pingback: BPMN vs. Patient Treatment Plans | Collaborative Planning & Social Business
Pingback: BPMN « dahlia74march
Pingback: Two Languages Divide but don’t Conquer | Collaborative Planning & Social Business
Great article! I have also found some great BPMN 2.0 Examples using Lucidchart and they are very helpful and easy to use! Check it out!
Pingback: Liens de la semaine (weekly)