What do we discuss: a new management discipline, a new class of software products or a new practice of addressing existing business needs by existing technologies? As this is not clear in each piece of text, I will be very explicit. I will discuss the last option which is about how to shape a business system to become flexible enough to really help the business to deal with individual cases (not just with the mass production).
Considering that many technologies, methods, standards, enterprise roles are intermixed within this topic, I will address it through a few views:
- systems thinking view
- BPM (as a discipline) view
- case manager (or relevant authority) view
- business system architecture view
Applications of case management process modeling include licensing & permitting in government, insurance application and claim processing in insurance, patient care and medical diagnosis in healthcare, mortgage processing in banking, problem resolution in call centres, sales and operations planning, invoice discrepancy handling, maintenance and repair of machines and equipment, and engineering of made to order products.
I would add: crisis management, classic project management, legal cases, plane building, developing and publishing an international standard, preparing a multi-stakeholder document (e.g. an international treaty or a public law which should be checked by many governmental agencies and potentially discussed in the Internet). May I also include some games, please? Like the chess?
What is common in these examples?
- there are some rules how to carry out cases;
- human-being’s knowledge, creativity and abilities are the critical success factor;
- it is not possible (or practical?) to predict an exact sequence of “non-creative” (or mechanical) actions for the whole case lifecycle,
- it is highly desirable to plan ahead some next actions to evaluate potential risks, time, resources, values, etc.
Systems thinking view
Generally, case is a complex, dynamic, adaptive, open, self-evolving and socio-technical system.
The socio-technical aspect is primary important and any automation should be designed with the human-centred perspective by keeping the “operator” in command of the whole system, requiring that the operator be informed and involved with monitoring the automation.
All parts of the system are important (participants, rules, documents, data, etc.) and, in accordance with the “systems thinking”, they can best be understood in the context of their relationships to one another and to the external environment, rather than in isolation. So, to provide better guidance of the “trajectory” (course of evolution/changes/actions) of the system then it is necessary to obtain / preserve / reflect more knowledge of relationships between the parts.
Some of such knowledge may come from the history of a case (i.e. its trajectory).
Because of very dynamic and open (high degree of influence from the external environment) nature of cases, it is not possible to predict a future trajectory of the system, but it is possible plan it. As any plan is an approximation, to be better prepared unknown, a few different scenarios may be considered. Three types of scenarios can be recommended: optimistic, pessimistic and realistic.
To guide the trajectory of the system, the feed-back control loop approach can be used. Smaller loops and/or nested loops can improve the ability to follow to the real situation. The frequency of loops may change during the time – the system may have periods with a turbulent behaviour and some quite time.
BPM (as a discipline) view
BPM as a management discipline (how to use processes to manage the enterprise) is about “to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries”.
The meaning of the word “model” has to be clarified. It means to make known, to describe or to communicate a plan (or plan of work or process template) of how to carry out future actions to obtain a desired outcome. Such a plan may have non-functional characteristics (risks, time, resources, values, etc.) and can be tested by some simulation. Usually, such a plan of work is prepared by the case manager and is subject to approval by some stakeholders of a particular case.
The meaning of the word “automate” has to be clarified also. It means to instrument the proposed plan of work by some existing or new tools.
Obviously, those 6 BPM functions (model, automate, execute, control, measure, and optimise) are applied iteratively and continuously. How often? It is a choice of the people who implement a BPM-centric system. BPM discipline does not limit them. Possible variations are:
- 1 (to be precise, the same version) process template for N process instances – a traditional use of workflow technology.
- 1 process template for 1 process instance – individual tailoring of a generic process template for a particular case. An example is “Defined Process” [capability level 3] from CMMI; another example is a legal procedure [bankruptcy procedure] defined by the law which is actually a skeleton (with a lot of exceptions) for all instances.
- No process template before the process instance – the template is built as needed within the process instance (or at runtime). Small process fragments are used. Some of them are predefined in a library of process patterns, some of them have to be created on demand.
What are optimisation criteria? Again, it is a choice of the organisation. The latter may use the BPM for perfecting internal work (inside-out) or serving each customer differently (outside-in).
So, the BPM discipline is rather applicable for managing of cases.
Case manager (or relevant authority) view
Any tools for case management shouldn’t try to replace a human, but assist him/her to carry out repetitive or complex calculation/data processing activities. Planning of future actions at runtime is mandatory. Such a planning may comprise several scenarios, may have different horizons (next action only, a few next actions, all further actions, etc.), may involve some simulation and may use different characteristics (risk, values, money, impact, etc.) Planning can be nested: the top-level planning is the case lifecycle.
Support of decision making is necessary because of increasing amount of information involved in the decision making. Sensing of this information and events is vital.
Perfect capturing of relevant data and information is certainly the area for automation. Especially, for handling of small fragments of information in addition to whole documents. For example, patient’s data must become anonymous for a review by a group of external experts. Each fragment (and any logical aggregation of fragments) should be treated as a separate unit with its own history, identification, permissions, relationships, presentations, audit trails, etc.
And finally, help people with coordination of actions. Coordination may be between organisations, units, people, systems, etc. Also coordination can be static, dynamic, un-structured and networked. It is important to provide and enrich a library of coordination patterns (e.g. a review by a group of experts).
Again the OMG’s RFP for the Case Management Process Modeling gives a good overview:
Typical elements of a case management process are assessment of needs, evaluation of potential solutions, implementation of a selected solution and monitoring and evaluation of results. Case management typically requires a great deal of knowledge work, undefined interactions between a case manager and other participants, long running case resolution efforts, multiple process fragments and engagement of supporting services.
Business system architecture view
The aim is to provide an “actionable work execution coaching/guidance” for the business. It seems that a good set of existing technologies should be deployed and employed TOGETHER: BPM, BRM, ECM, CEP, EDA, SOA, MDM, RBAC, process/data mining,
The current situation with BPM software products shows that vendors are trying to add more and more features from different technologies into their products (e.g. by acquisition of separate tools). So, products are more and more complex, expensive and heavy (difficult to test and to evolve). Is it a time when the “created” complexity became an obstacle for further progress (including innovations)?
The solution for reducing complexity is well-known – use architecture with pluggable (through commonly-agreed and standard interfaces) blocks of specific functionality. Also, this should bring the flexibility thus enable business innovations.
Imagine that each case is handled by a personalised and dedicated "virtual" business micro-system. The micro-system is optimised for a particular case and evolves together with the case lifecycle – see below.
Conclusion
The title of this post is its conclusion – let us architect the use of existing technologies instead of blaming these “speechless means” for brining complexity into enterprise systems.
Thanks,
AS
11 comments:
Good post.
There are two ways to look at the situation: One, where we look at all that's happening in the technologies and keep trying to map the field out, and another - when faced with a situation in business, look for what's best at the time and with the tools at disposal. I think a balance of both may be needed but the customer scenario always precedes everything else. As for analysis and theory building purposes, the generality matters. The attempts at convergence may continue but all that may have no value unless applied to a situation.
I have posted something on my point of view on these aspects:
One is about the convergence and the fact that the synergetic approach would be critical (that's theory part). http://wp.me/pN8i1-30
Another, is where I believe that in a customer situation what we call a particular solution doesn't matter. BPM happens on the ground when required and in the form required. A separate qualification of such may not be always necessary: http://wp.me/pN8i1-3f
Good post.
There are two ways to look at the situation: One, where we look at all that's happening in the technologies and keep trying to map the field out, and another - when faced with a situation in business, look for what's best at the time and with the tools at disposal. I think a balance of both may be needed but the customer scenario always precedes everything else. As for analysis and theory building purposes, the generality matters. The attempts at convergence may continue but all that may have no value unless applied to a situation.
I have posted something on my point of view on these aspects:
One is about the convergence and the fact that the synergetic approach would be critical (that's theory part). http://wp.me/pN8i1-30
Another, is where I believe that in a customer situation what we call a particular solution doesn't matter. BPM happens on the ground when required and in the form required. A separate qualification of such may not be always necessary: http://wp.me/pN8i1-3f
Thank Ashish for the comment.
Agree about a balanced approach – understand at the customer’s needs, architect the solution with the use of existing tools and, perhaps, new products, implement the solutions, etc. What I don’t like is if I need a saddle then I have to buy also a horse and a chariot. Sure that vendors like to offer overlapping functionalities and thus confuse the client. I wouldn’t call this “systematic convergence” because those expansions are based neither on standards nor a commonly-agreed BPM reference model – see http://improving-bpm-systems.blogspot.com/2010/03/linkedin-bpm-ecosystem-blurring.html
Concerning the calling a particular solution – also agree. One of my examples of BPM is about applying a business process modeling procedure to help people to communicate in an enterprise tool selection project. Again, a good technology should be pluggable.
At the same time I consider that BPMS (BPM as software) is an enabler for disruptive changes on how IT deliver tools (currently applications) to the business.
Thanks,
AS
Hmm, so far so good, but the last line in your reply prompted me to share another one of my posts :)
Do Not Treat Process Solutions as Applications - http://wp.me/pN8i1-4t
So, what would you say to that?
And as for the convergence, I tend to agree in hindsight that the word "systematic" is misplaced. Point to be conveyed was that the lines are not as blurry and chaotic if we know the whole picture and apply the energies on creating synergetic models rather than worrying about the blur...
I was busy writing this post and didn’t comment yours.
“Application mindset” - I would say that it is possible to architect an enterprise system which is process-oriented (i.e. processes the main enterprise artefacts). This means that the system handles all BPM-related artefacts (process, services, events, rules, roles, data, documents, audit trails, KPIs) together (but may be with different IT tools - ECM for documents, BRM for rules, MDM for data, etc.) to construct processes.
By definition, all those artefacts are versionable though their lifecycle.
Such a system is specially architected to make changes very easy – improving processes will be done by assembling of better compositions from better artefacts; use of DSLs will simplify handling of artefacts, owners of business artefacts will be able to change them directly, etc.
But, the architecture comes first as I describe in my book.
Thanks,
AS
IMO modern technologies are a big help. It brings a total transformation an advance strategic planning services ideas, not only for business but also to the economy itself.
Agree with Audrina and would like to add that well-architected use of modern technologies is even a bigger help.
Thanks,
AS
Alexander
Congratulations, it's probably the best post on the matter so far! I enjoyed both ACM vs. BPM part and the word against spreading BPM umbrella too wide; similar thoughts of mine - http://mainthing.ru/item/204/
But the puzzle misses one thing: the project. Doesn't it correspond to the case, isn't case planning that you describe similar to project planning, won't we end up with Gantt charts in case planning?
Anatoly
Thanks Anatoly,
The BPMS.RU meeting in Moscow helped me :)
I should repeat again - in my view the case management will cover the classic project management. Gantt charts may be generated automatically based on WBS dependencies, currently available resources and other case attributes.
Thanks,
AS
This just made my day much brighter. Thanks a lot. Something else I across was this Residential Architect.Take a look!
How To Change Blogger Background
Best Free Seo Tools to Optimize Your Blog
Profitable for your business - Guest Blogging
What Function Margin at Your CSS / Tips For Beginner
How to Host Jquery Script in Blogger / Blogspot
How to Earn Money with Chatika, Clicksor & Adhitz Learn in Urdu
How to Reduce site/blog Loading Speed Time?
Social Media & Email Subscription Box For Blogger
SiteMap
How to Make / Install Back To Top Button With
NoFollow | Understanding tag (rel = "nofollow") Attribute
Change Blog's Background Color Automatically with JavaScript
How to Make a Box Convert / Parse HTML and Functions
how to increase visitors easily to 2000
How to Make 2 Column Element in Lower Post
How To Add Message Box Like Wordpress With Close Button
RSS Feed Directories List
Best Alternatives to Google Adsense in 2013
How to Change Blog's Mouse Cursor with CSS?
Post a Comment