What Is the Future for Processes?

To understand the future of processes, you must dig a little deeper than many people do.

Process thinking goes back well over a century, to the origin of modern iron and automobile production.  The raw materials and finished goods of such manufacturing and production processes are literally spatial — 3-dimensional.  What can you do to significantly improve productivity in a 3-dimensional world?  The answer these days is simple:  You build robots.  Robotization has literally changed the world during the past 30–40 years.

Rather than manufacturing and production processes, however, the world is now increasingly focused on white-collar and digital processes.  What 3-dimensional presence do the raw materials and finished goods of these processes have?

Well, exactly none.  The raw materials and finished goods of these processes aren't physical and simply have no spatial presence whatsoever (except maybe for paper artifacts).  Robots (at least physical ones) aren't an option.  That fact of life makes a huge difference in how you have to think about automation for such processes.

Instead, the raw materials and finished goods of such processes are all about your operational business knowledge — your intellectual capital — and your capacity to express and apply it.  That capability, in turn, depends directly on your business terminology and business language.  For white-collar processes you have no choice — the world is semantic.  So you must deal with the subject matter semantically.

That takes us in a very different direction than most professionals currently foresee.  For one thing it takes us toward natural language and away from diagrams.  That's a huge shift in mindset.  Imagine having a business conversation with your smart phone about gaps and ambiguities in business policies and in the meanings of the vocabulary you use to talk about subject matter knowledge.  Don't think that's possible?  Have you watched your kids talking to their smart phones lately?

Sooner or later businesses will realize that operational business knowledge differentiates their product/services and enables their ever-more-automated processes to function.  Capturing, managing, and re-using that intellectual capital puts a premium on structured business vocabulary (concept models^[1]) and on business rules expressed in structured natural language.^[2]  Those business rules are the only way you have to ensure quality from white-collar and digital processes.

What about Case Management?

Many 'processes' people are looking to implement these days are clearly best viewed as case-oriented — e.g., patient care, mortgage applications, etc.  Individual cases must be orchestrated through various states, often with undesirable or wayward transitions.  There is significant variation in the paths that various cases take.  Things just don't always move along as predictably as on a production line.

For such problems you'll want a more case-oriented style of modeling.  (For business practitioners that technique may or may not prove to be CMMN.^[3])  You might not use traditional process modeling at all.  Whatever your approach you'll definitely want to be very clear about what milestones are relevant, and which business rules apply for each.  That puts a premium on business rules.

What about Cognitive Computing?

People are also starting to ask why current processes are so dumb.  For example, why can't they:

• learn from experience? 
• be more goal-driven?
• dynamically balance between conflicting goals? 
• self-adapt? 

Some people suggest use of cognitive computing to help make processes smarter.  I doubt anybody today really knows how far this idea can be taken.  I can, however, say two things with certainty:

• If you don't know what your business rules are (i.e., what rules guided previous executions), can you really expect a machine to figure them out?  A machine can undoubtedly identify patterns, but that's a far cry from demonstrating compliance, guaranteeing consistent results, or customizing appropriately case-by-case.
  
• Suppose self-adapting processes do become reality.  The question I have is what will keep such processes from going out of bounds?  How do you avoid them doing things that are undesirable, self-defeating, or even illegal?  These are critical questions that will always bring you right back to business rules.

For further information, please visit BRSolutions.com      

References

[1]  Refer to "What Is a Concept Model?" by Ronald G. Ross,  Business Rules Journal, Vol. 15, No. 10 (Oct. 2014), URL:  http://www.BRCommunity.com/a2014/b779.html  

[2]  E.g., in RuleSpeak®.  Refer to http://www.rulespeak.com/en/  

[3]  Case Management Model and Notation  

SOURCE: BRCommunity

Positive Business Outcomes with IBM Case Manager

1-2-3 Tips for Maximising Case Management

Technology and data executives are constantly keeping their eyes on the big picture, overall business process management, broad technical structures, digital content and workflows. But there’s a hole in that oversight–the crucial issue of case management. Jeroen Jansen, General Director of Netherlands-based Informed Consulting, came to that realization in college. He started thinking less about computers and more about how people (read: customers, employees) use them.

“The human brain does things that computers will never do,” Jansen thought at the time. “Computers were great for structured data. But people work with documents (and images, graphics, sound, video and more) and that’s a whole other ballgame.”

Shifting his focus from broad technical structure to users’ needs, gave Jansen better insight into where IT is working well, where things could improve and what should happen next.

“It’s the clash between business process management and case management,” he says. “Companies that spent the last 15-20 years converting to ‘digital-everything’ focused on creating an optimum workflow to manage all that information. It’s a good start, but one size does not fit all.”

Jansen cites a favorite example: airlines. Reservations have become so completely digitized and automated, that a harried traveler stuck at the airport is directed by an agent at the counter to “log into the carrier’s website” for help. That, Jansen says, is business process management taken to the extreme.

“The original thought in the IT world was to build generic, database-centric user interfaces that highlighted and maximized the powerful capabilities of the ECM,” says Jansen. “But over time such an interface becomes increasingly complex to use and workers may turn away.”

Case management, on the other hand, focuses on helping users complete their specific, unique tasks. It empowers workers, unleashing decision-making and creativity, benefiting the overall enterprise. It’s like an IT version of the Harley-Davidson story, where a nearly-bankrupt company shook off its antiquated assembly line in favor of small teams with greater responsibility and decision-making power. Now the company is firing on all cylinders.

The key, Jansen says, is enabling workers to access data on their own terms. It’s the thinking behind Informed Consulting’s SPA4D solution, which leverages the power of both EMC Documentum and Microsoft SharePoint.

Building multiple, custom-configured interfaces may seem daunting, even excessive to some organizations. Until they see the results. Jansen cites as an example, Abbott Pharmaceuticals, with 30,000 Documentum users.

“We gave the tech-types the complex tools they needed,” Jansen says. “Others got a simpler, more intuitive experience with the look and feel of solutions already familiar to them. Usage doubled!”

Jansen and his team applied similar techniques in their work with the Municipal Government of Amsterdam, replacing a decade-old system with one that created a much friendlier relationship between employee and enterprise. “The moment they saw it,” he says, “they got excited!”

Jansen offers these tips to maximize case management:

1. Let the users do the talking, especially younger employees. Far from being reluctant to change, a generation that’s grown up with touch screens, text messages, Twitter and Instagram knows exactly what it wants.
2. Push your team to customize an interface for each distinct group of users, based on tools they’re already familiar with.
3. A custom-tailored experience means a better relationship with data.

That way, a highly-skilled engineer in the back office can delight in an interface’s power and complexities, while a salesperson, researcher, customer service representative, airline mechanic or compliance officer can get a simpler, custom-tailored experience and better use of the data, Jansen says.

SOURCE: EMC SPARK

Introduction to Lean Six Sigma and Process Capability

ISIS Papyrus Adaptive Case Management

So many things can go wrong on the way to providing excellent Customer Experience (CX). Like a chain, the weakest link can destroy all the effort of the other parts. But while it’s important to go over all these factors, it’s also imperative to identify common weakest links.

The Weakest Link in CX – System or Person?

In the video above, customer-facing agents certainly ruined the CX. You can’t replace the need to select the right people to deliver service. But you can give those people the right tools to provide the best service possible. What most systems lack is the ability to optimize customer-facing processes. Creating and implementing such processes doesn’t necessarily mean shoehorning all customer interactions into a box. Your employees must have room to make exceptions and show flexibility.

So…what type of system facilitates the creation of customer-oriented processes, which at the same time enforces order, but also allows for dynamic changes when changes are required?

Top Answer: A BPMS (Business Process Management Suite).

BPM suites are now recognized as having the optimal capabilities to manage and improve all organizational processes – including those that are customer facing.

In this white paper, we demonstrate how BPM can transform your company’s CX.

Not all BPMSs have the ability to provide both order and end user flexibility. Gartner identifies the ability to react to and handle Change as a key element in an intelligent BPM strategy. PNMsoft Sequence has emerged as a leader in this area. With our unique HotChange® technology, process designers and end users can adapt processes to changing conditions, enabling customer agents to make exceptions on the fly.

Imagine how the Car Rental agent in the video above could have provided better service to Jerry Seinfeld, with the aid of a Change-oriented BPM suite. Such a system, when faced with a lack of resources (i.e. cars), could then assist the agent by providing alternate options on screen (e.g. a different car with similar specs), which the agent could offer before the customer begins to get annoyed. Better yet, the BPM-powered system could foresee a resource shortage beforehand and head it off, by alerting other departments who could obtain more of those resources before they run out.

Where’s the Front End?

BPM systems don’t have to replace front end Customer Service systems – although in many cases they can. Alternatively, they can integrate with the front and back ends, forming a process engine in the middle. This middle process layer can surface hard-to-access back office data, showing field agents and service reps the data they need, when they need it. It can also update those back office systems when changes occur, so that data is flowing smoothly in both directions.

Case Management and CX

BPM suites like Sequence can also be used as Case Management software, for complex customer management scenarios. We’ve seen this work wonders for our clients in the banking community, where customer service is critical for retention, and there is the added pressure of heavy regulation and compliance.

SOURCE: PNMSOFT

No Model is a Good Model

During the presentations at the Workshop on Adaptive Case Management (ACM) on Monday, there was a growing question about the models: Not just how models should be constructed, but whether we should be using models at all. These ended up forming a major discussion at the end of the day, and even into the rest of the week, culminating with the final keynote questioning our obsession with models in BPM.  This is my take on the main positions in the debate.

Every presentation at the workshop dealt with modeling: (1) can CMMN model what is needed by ACM, (2) comparison of 5 different modeling approaches, (3) a way to model variants in process, (4) consistency checking of models, (5) modeling crisis scenarios with state charts, (6) using semantic web to compare models, (7) modeling based on speech acts, (8) more consistency checking within models, and (9) using viable system model for ACM.

It is not just this workshop.   I have been seeing this everywhere.  Lloyd Duggan gave a mini course on case management where he said that the difference is that BPM uses BPMN and case management uses CMMN.  If you read the papers, you see statements like:  “We needed to model, so we chose CMMN.”   There are comparisons between approaches based on comparing how models are built.  There is a build-in assumption that to do anything we start with a model.

Questioning The Value of Modeling

The assumption is a blind spot:  If it is true that modeling is effective, we should be able to show that through the use of a model we allow the user to get more done than when a model is not used.  However, this question is rarely, if ever, asked. The second presentation compared the expressibility of various modeling techniques, however the actual advantage of modeling was never demonstrated. Almost no research is done comparing cases where a model is used, to a control case where a model is not used.

A Convenient Crutch

One might suspect that models are foremost in research, because they are quite a bit easier to study than real office behavior.  Interview some people, make a model, and then put the model under a microscope.  You can experiment with the model, find the ways that it fails.  Two of the talks were about ways to find inconsistencies within a given model, to avoid deadlock type situations in the model.  However, these deadlocks have nothing to do with the behavior of the actual workers in the office, it is simply a flaw in the model.

Through all of this, we lose sight of our real goal: making workers more effective.  We really do need to do controlled studies:  consider a set of offices, measure the performance, then give one set of offices use the ACM technique, while another set continues operating manually.  Measure the increase in performance.   We need to keep our eyes on actual knowledge workers productivity, and not get distracted by our attractive technical developments.

Who is Modeling?

We need to be clear about who is modeling.  When talking of an ACM system, we all know that such a system is built from software.  That software might be modeled.  The issue is not whether the programmer of the system uses a model to make the software.  That would be a question of the use of modeling in software development — a completely separate issue from the use of modeling in ACM by the knowledge workers.  When an approach to ACM is presented as “providing modeling” we know that means modeling by the knowledge worker, or by someone close to the knowledge worker, as part of the knowledge work.  When we talk about modeling being “part of” the ACM System, it means that modeling capability is presented as part of the features for the intended users of the system — not the programmers who make the system.  I know these lines are blurred somewhat in some systems that can be “customized” by programmer.  Still, lets keep this modeling discussion about those models created by the knowledge workers themselves.  For example, a law office, we consider the modeling done by lawyers, even when only 10% of the lawyers actually make models, but lets not consider modeling done by someone who only does modeling,a nd never does any law.

An Example of a Non-modeling Approach

One of the best examples of a system that supports extensive, complex knowledge work is Git Hub.  Software product designers and programmers have a very complex, knowledge intensive task to accomplish.  Git Hub offers a simple, elegant way to coordinate this work:

• issues can be logged by anyone at any time.  The issue describes the problem or the work to be done.
• team members can discuss any issue using a chain of comments, either asking questions of clarification, or stating positions.
• issues can be tagged and classified in different categories, such as bug,  feature, enhancement, urgent, ignore, and others.
• issues can be grouped into milestones, which have an intended release date.
• programmers can focus on all the issues in a milestone, marking off issues as the work implied by the issue is completed.  Everyone on the team can be aware of the status of the milestone.
• Milestones can be adjusted and replanned by moving issues in and out of the molestone.

That is it.  Simple and effective.  Used effectively by thousands of projects today.  There is no modeling capability.  There is no automation of the knowledge worker tasks.  There is no need for a modeling language at all.  And it works.

Another example I have used in the past is Easy Chair, which is a system used to collect, review, and judge papers submitted to a conference.  This system is used by hundreds if not thousands of conferences every year, and most academics are familiar with it.  It allows knowledge workers to get their work done — very effectively by all accounts — but it offers no modeling capabilities at all.

Both of these are software systems, so one might assume that the programmers who developed them used models.  We don’t care.  This discussion is not about modeling in software engineering, but modeling by the knowledge worker as part of doing knowledge work.

Everything is a Model

One particular rat hole that the discussion kept going down is the position that anything you do to customize is a model.  For example, in Git Hub you can specify the labels that are used for categorization:  I might have 5 varying levels of urgency, while someone else might only have three.  In Easy Chair you can decide whether abstracts can be sent in ahead of the submission, or whether the full submission must be given at once.  These changes effect the way that the users must behave with the system.

In some purist technical way, any setting that one person makes effecting another is modeling.  These trivial mechanisms are not what most people mean by modeling.  I think we know by modeling, we mean some flexible, abstract, general purpose representation of the work being done.  When we say the work can be modeled, we don’t mean that there is a check-box somewhere that directs work differently.  Or a label.

The true gray-area is that of checklists.  A checklist is a general purpose representation of a collection of tasks.  One might argue that this is modeling.  For example, grouping the issues into a milestone in Git Hub, is modeling the work to be done for that milestone.  No!  I am not buying it.  The difficulty in modeling has to do with a certain level of abstraction.  Checklists are concrete.  If we want to discuss the merits of modeling, we must be talking of models that are more abstract than a checklist.

For What Purpose?

My stated position was that we must consider and measure the benefit of a model.  WE can not assume that it offers a benefit, and as you can see there are good examples of knowledge work systems that require no modeling by the knowledge workers.  They offer no possibility for it, and there does not appear to be any problem.

Models could be useful for a purpose.  For example, a model of the work can be very important in predictive analysis, where you use patterns of behavior together with emerging workload, to predict how many resources you will need.  A call center wants to make sure they have enough knowledge workers available on days when load is expected to peak.  Presentation #5 was about emergency response, and having a model to simulate potential scenarios before an emergency can be critical.  It can also be useful to take inputs and warn about potential problems as the emergency is unfolding.  A model can be used in numerous simulation situations.  Some of these models would be implemented by a specialist who does only models:  for example the person who makes a model to predict problems in a flood, might not be an actual emergency rescue worker.  The question still remains whether a system to support emergency responders needs modeling capabilities.

If we include modeling in an ACM System, then we should be very clear what the purpose and goal of such modeling is.  We should then not only show that it achieves this goal, but that also, as a result of the modeling, the work of the actual knowledge workers is made more effective.

The rest of BPM as well

Outside of the workshop, we saw a lot of the same sentiment: we are too hung up on modeling.  Far too many papers assume modeling, and then study the model.  Studies of model correctness constraints are about assuring that certain modeling rules are not broken — not necessarily whether the business that uses the model improves from it.

Leon Osterweil, a hero in the 1990s in the software process model domain, whose work I have cited many times, attended the conference and participated on a panel about agile BPM.  However, it is somewhat ironic and humbling to realize that in the software development space, real progress has been made not by developing an elaborate executable process model, but instead by going the other way to agile approaches, such as SCRUM.  SCUM has a method to be sure:  two week sprints, daily stand-up meetings, visible status, develop test before developing the code, but these are less like automated processes, and more like simple patterns of interactions on which programmers manually create the software.  Git Hub does a brilliant job of coordinating developers work, without having any readily apparent enforcement of something you might call a process model.

Marlon Dumas gave the closing keynote for the BPM Conference including a history of the BPM field from 1990 to date.  He also decried the focus we give on models: measuring models, improving models, etc. to the exclusion of knowing whether we are actually creating the business.  He showed how at different times we moved from studying process, to studying models, to studying analytics.  He urged a change in culture for the papers next year and beyond.  Modeling and analytics are tools to use to improve a business process, but they are not themselves the business process.  The model should not be the focus of the research.  Instead, we should focus on returning to study the actual business process, the actual work being done, and show how we can make the business more effective, possibly with the use of models.

No Model is a Good Model

I think a whole lot more can be done to support knowledge workers without the need for modeling.  We need to study those.  Modeling might be useful in situations, but we should be clear about the purpose of that modeling, and we should measure whether the model is actually effective in improving the work of knowledge workers.  We should not be blinded by the assumption that modeling is a necessary part of ACM.

SOURCE: social-biz.org