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.

Intalio User Conference Take Away's

I just spent two days with the Intalio folks at a BPMS users conference. I have been researching BPM as the next extension of my background in process, six sigma and quality. I like Intalio because they are an open source solution being built by a bunch of passionate pioneers in the industry. It was a great opportunity for me to continue to explore the possibilities associated with BPM.

I have been spending a lot of energy thinking about how to make the business more agile and transparent. I had become disillusioned with process charts because they were static, not real, not executable. However, every time I wanted to change a core application it cost too much money and took too much time. BPM seemed somewhat artificially to me, a more sophisticated mapping tool until the concept of web services became more mainstream. The reality of using a web service as part of executable BPEL generated from a process flow built using BPMN suddenly made this process real.

In my case, it seems that encapsulating key functions of my core applications via web services in a layer of BPM would really give me the ability to "Mash Up" business process that are alive and can allow rapid logic, task or flow changes without changing the underlying services that are built on the core applications. I have run many improvement projects that wrote lots of custom code into application effectively building process into them... process that would surely change as the business did. An adaptive business, it would seem, is one where processes are configurable. As you learn, they learn. Sometimes the best way to learn is to just try it. Traditionally, that was very hard with many processes and applications... at least in an enterprise way.

I was challenged to rethink how I discovered, tested, and deployed processes. I saw examples of business process mash ups where processes were built, tested, and deployed in minutes. I have pages and pages of ideas, notes, discoveries, and questions. As I begin to sythensis this, I will share my thoughts. As I practice it; I will share my thoughts.

What I saw was both exciting and scary. Exciting because I saw a tool capabilities and a way of thinking that could really change, for the better, how we make the organization more adaptive. Scary because it is yet another layer and dependent on the organization thinking and acting differently. Not to mention, I need to get those key web services built.

Let me pause with this thought... I see that I would no longer be building processes. Instead, I would be building process services. Services that could be called by an application based on some event just as easily as they call on the application to do something based on an event. For someone who straddles the business and IT, that is a fascinating concept that has so many possibilities.