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?