Process Maturity

I have been continuing my development of the technical support and product returns process utilizing the BPMS tools and modeling via BPMN. I have begun to think about how I frame this level of model detail and the potential to have the process placed in an executable engine, in the context of our larger business process work. Process maturity has come to mind. I resurrected some of my old references to a process maturity model and noodled on how this current BPM work fits in.

5 Levels
1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimizing

What I am realizing is that BPMN is really a tool set and design approach that helps you systematically move to more mature process that are controlled, measured, automated, and predictable. It would seem that BPMS tools can help accelerate this process under the right conditions and leadership. It would allow you to quickly move through the first three stages and provide you the foundations and “knobs” needed to move through the last two.

Although, I can’t underestimate the human element; which I typically do! It is one thing to design a process, it is quite another to execute it effectively. A large part of maturing your processes is maturing and educating your people’s process management competence. In the past, I tended to underestimate the speed and eagerness of people to embrace these concepts. Concepts that seems so self evident to me, yet the stuff only works when those running the show really get it… and want it.

Extract the Business Rule from the Business Process

As I have worked with the BPMN modeling techniques, I have watched my process models become extraordinarily better, more valuable and more accurately communicate what is really happening; whether good or bad. Modeling people, other processes and applications as interfaces has focused me more concretely on the information flow and functionality of the interactions. Focus on these interactions is what I am seeing improve the modeling.

Also, one of the changes I have made is to explicitly extract the business rules from the process as we build the model. Each “Gateway” or decision point has a pointer to a version controlled business rule. For the process I am modeling (Technical Support and Material Return), I don’t anticipate these rules changing frequently. Despite that, I can really see the value in pulling the decision logic that is based on process data out of the process so that it can be managed independently.

Today, for me, this is a design and modeling technique. We are investigating rules engines, packaged application service availabilities, etc., but don’t have those technology capabilities yet. However, by building the models in this way, I see it as a compelling way to design better process automation in existing applications while building a case for additional layers of technology to move logic out of application and into various kinds of engines.

I think the concept of layers is the secret sauce. Designing in layers. Managing in layers. Implementing in layers. I think this also closely relates to the concept of services. Process service. Decision service. Application service.

The Art of Design

I have been reading a book (presentationzen by Garr Reynolds) to help me more effectively design and deliver messages when presenting. I have seen a marked improvement. As I work more with the concepts in the book, I realize that these design techniques apply to many other aspects of life. The author says as much. One of those area is process design.



"Simplicity is powerful and leads to greater clarity, yet it is neither simple nor easy to achieve... Simplicity can be obtained through the careful reduction of the nonessential."



As I thought about this concept, I saw that it is a more elegant expression of "Lean" prinicples and Value Add anaylsis. So often, when I work on a process it is complex and cluttered. The clutter, which comes in many forms (like "extra" not needed information, functional lines, etc.) get in the way. The clutter can take your focus way from the true intent of the process; make execution less effective. It is about flow and intent. As a business process designer, I need to place the right action, at the right place, with the right infromation. I need to understand the greater purpose for what the business is trying to accomplish. It is not about boxes and arrows. It is as much intuitive as it is systematic.

Elegance. What a different objective when designing yet another business process...

Insights into the process vs. interfaces

I have been modeling a material return and repair process the last week or so and utilizing the Intalio designer. Since my company utilizes TIBCO as a service bus, I have downloaded their Business Studio and requested IT to set it up for me… but back to the topic at hand. As a part of that process model, I have been building an information model and associated XML schema. A couple observations from that work;

• I have found that separating the process from the human and system interfaces is a great tool to really understand “the process”, but also what information is flowing back and forth between the process and a given interface (whether human or machine). It forces you to better articulate the task or function you expect the interface to accomplish (again human or machine)

• Building process services is a different mind set. Rather than building large, wall size processes. I am building small, specific process that accomplishes a specific task and then “calling” them from other processes. So far, I find each individual process easier to understand, validate, and potentially automate. I have even created separate “pools” for each interface so that it is more clear whether I am “calling” a human, system, or process for a given task.

Since I have minimal interfaces that are actual services today, some of the work to keep the process “executable” is more academic than reality at this point. However, by treating each interface as a potential service, it is forcing me to define what I expect the service to do, hence starting the journey toward automating the task via a service with the packaged applications.

SLA's Are CYA's

SLA’s are CYA’s. Confused? Service Level Agreements (SLA) are for Covering Your Ass (CYA). At least, that is what speaker Doug Neal has to say about it. He argued that we need to look risk in the eye; to model and deliver performance. Coming from a world of SLA and having gone through the exercise recently with both internal and external customers I was intrigued by the concept. I was also intrigued by the relationship to BPM.

Doug went on to show an example of how he thought a BPMS is going to be key to helping companies become green. How? By making invisible process transactions visible. Visibility is the beginning. I slowly began to realize that a BPMS gives a record of any transaction; you can prove performance across the board. As managers, we now have the view into our business that gives us both the information and means to manage before things get out of hand. In effect, giving us the ability to adapt in real-time our management and rules. Sounds good. Maybe too good.

When I was at General Electric we talked a lot about the digital cockpit. The digital cockpit was just a fancy name for a metrics dashboard. We used the analogy of an aircraft cockpit… all the instruments (a.k.a. metrics) you need to know how things are going. Doug made a comment over drinks, “What does a cockpit have in it?” The answer is both the instruments and the flight controls. “We have given managers the instruments, but no knobs to control it. A BPMS begins to give us the knobs.” This really resonated with me. How do we build both the real-time instruments and controls to deliver performance?

Reading a white paper from Forrester provided two buckets to think through my processes and the corresponding automation needs. Do I have Human-intensive processes or System-intensive processes? My answer was both, but most of my work has been focused on the Human-intensive processes were individual knowledge and intuition were used in conjuncture with applications, knowledge centers, etc. Our current ESB implementation is more on the System-intensive side orchestrating the purchase and provisioning of our service.

Foresters defined them this way;

• People-intensive processes: Involve a high level of interactions among individuals, business applications, databases, documents, and other people.
  
• System-intensive processes: Involve millions of transactions per day that are handled on a straight through basis with minimal or no human touch and few exceptions. A sub category of this is integration-centric; handling the interactions between packaged applications.

I think inherent in both is the degree of decision making required and how much does the criteria change. One of the presenters at the BPM conference talked about specifically identifying decisions that you make in a process, call them out, and turn them into a “decision service” [Smart enough Systems]. The idea of looking at a process through a decision lens is a great one. I can see a lot of value in focusing on what information is needed to make the decision, what is the logic used to make the decision and what are the outcomes. Having a means to pull this out of packaged applications and out of individuals into an executable process can help speed up and simplify the processes.

A Step Back

I want to step back. Why do I care about BPM automation? A couple thoughts resonate as true;

• Business process is abstract; Unless made real
• Business process is not real on a Visio chart
• Business process changes; Constantly
• Business process is not effective; Unless visible
• Business process in packaged applications takes lots of time and lots of money to create; Forget changing
• Business process as a “service” changes things; Web service adoption changes things… the standardization of BPMN and BPEL changes things…

I am tired of building Visio diagrams that are not real, that become the digital equivalent of the dusty binder sitting on the shelf that no one reads and certainly isn’t how things “really” work. I am tired of simple process changes that can make a big difference to the business taking 6 months to implement. I am tired of having important business functions being under the radar. I want to partner with and drive the architecture of our business with IT. I want to build real, configurable, and executable business processes that use packaged applications as needed, but aren’t constrained by them. I also don’t have a fortune to spend.

That is how I made my way to the hope found in BPM and Intalio specifically. Now comes the challenge of separating what’s possible with hard work and determination, from the hyped impossibility.