About Us Our Team Our Investments News Investor Info Blog

Archive for the ‘Business Process Management’ Category

In-Situ Process Discovery

Friday, May 8th, 2009

I was thinking the other day about why it is so hard discover how existing business process actually work.  Well, to be honest there are lots of reasons - butI think there is one that overshadows the rest - because in most cases discovering how the process actually executes is like detective work - after the fact you need to start interviewing possible participants and piece together the story from a set of connected facts. Slowly over time, just like a detective, the real picture unveils itself and can be understood and analyzed. This is hard, painstaking work - as any CSI aficionado can tell you.

Now what if you had a reliable eye-witness, one that actually saw most of what happened? Well in that case everything changes. CSI wouldn’t be a very interesting show if all they had to do is to walk up to Joe (a trained eye-witness) and asked “Hey Joe, What happened?” - of course that doesn’t completely solve the problem (e.g. understanding motive, filling in any missing pieces not visible to the witness) - but it makes everything much, much easier.

The same is true for process discovery - if you have a faithful eye-witness view of how the process works today - much of the pain in process discovery would be removed. That is what I call in-situ process discovery. I think we’ll start seeing a lot more interest in this type of discovery in the BPM space.

Process vs Innovation?

Thursday, March 19th, 2009

I was reading an interesting discussion on a BPM forum about whether innovation is a odds with process. If you understand process to be a rigidly structured, unchanged prescription of how work gets done, then there certainly is truth to that. The main task of those types of processes is to make sure work is standardized, and done the same way. Innovation is frowned upon.

On the other hand if you think of process as including ad-hoc and unstructured business processes - then processes actually help with innovation. If you can gain understanding of how things actually get done  (as opposed to how they are supposed to happen) - then you can use that insight to generate innovation.

Take any structured process (e.g. CRM), and look at the work it generates outside of the system (for example via email). Sometimes the work is really an odd ball one off. But in other cases (especially if it repeats itself) it may be an indication of a new unfufilled need, or a change in the environment that should be handled. Exactly the kind of input you need to create useful innovation.

I think companies are loosing a lot of potential innovation by not capturing and analyzing the exceptions to their main stream processes - I think they would be surprised by what they learn.

Unstructured, Semi-Structured and Structured Processes

Sunday, February 15th, 2009

I was thinking about a comment from Dennis Byron where he asks (and answers) “Are there ten times as many unstructured processes in the world as structured processes just as there is ten times as much unstructured data as structured data?”

So I thought I’d try to take this analogy a bit further. Before I do that I’ll define business process using a modified wikipedia definition: “A business process or business method is a collection of related activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers.” Wikipedia actually used the term “structured activity” - but I don’t understand what that means, so I left it out. So now on to the different types of processes:

  • Unstructured processes - every instance of the process can be different from another based on the environment, the content and the skills of the people involved. These are always human processes. These processes may have a framework or guideline driving the process, but only as a recommendation.
  • Structured processes - a rigorously defined process with an end-to-end model, that takes into account all the process instance permutations. No process instance can stray from process model, Just like structured data - there is a specific data model associated with the data - and the data cannot stray from that model - and if it does, the data is invalid.
  • Semi-structured processes - these are processes in which a portion of the process is structured, and sometimes unstructured processes are invoked (during exceptions, or when the model doesn’t hold).

While thinking that through I came to conclusion that, as opposed to data, there really is no such thing as a true structured business process once you get people involved (and most business processes require people sooner or later). If you really want an end-to-end model of a business process that works - the best you can hope for is a semi-structured process.

Human Process Management is the Key to Driving Higher BPM Business Value

Monday, November 10th, 2008

I was reading the latest Forrester BPM report on eBizQ and found it to be quite an interesting  read - especially for the endorsement it seemed to give human process management as a required extension to BPM - without actually naming it as such. That was my only quarrel with the authors - they expect BPM suites to be extended to handle unstructured, ad-hoc, chaotic (their term) human processes. That makes it sound like handling those types of process is just a small feature of an BPMS, a small extension that BPM suites should add. In my experience that isn’t the case - building an system to manage these types of human processes is  no trivial task, and don’t expect BPM vendors to be able to do it - it just requires a different type of thinking -especially since to get people to adopt it you need to unseat an entrenched “competitor” - email.  Here are some of the quotes that relate directly to human process management:

  • in real life, processes change all the time; in fact, our interviews consistently show that processes never stop changing

  • The outcome of a discounting decision may be captured in the BPMS by integrating or embedding a business rules engine, but the way the decision was made — the reason for the discount — is often recorded in an obscure email thread, if at all.”

  • “But many real-world, people intensive processes are so rife with exceptions that it’s impossible to model all the permutations in a traditional process modeling tool. These ad hoc, chaotic processes are difficult to support even using today’s BPMS tools”

OK -so even for the most structured processes in an organization - the ones that have actually been implemented via a BPMS - even those processes are constantly in flux - which means that almost always the users are going to need to morph and change the process before the IT department can reprogram system - no matter how good the tools are. So how is this actually handled in the real world? - no surprise here, it is done via email. These above quotes from the paper make it clear that no matter how well designed the process implementation is - it can’t anticipate every nuance of the process, or every new context - there will always be the need for a tool that allows end users the flexibility to handle the ever changing requirements and demands of real life business processes without IT involvement - while still allowing for management, monitoring and optimizing. Email provides the flexibility, and HPMS built on top of email - provides the rest. If not - BPM initiatives will bring only limited business value.

So in short - even for companies embarking on enterprise BPMS - remember H comes shortly after B, and you’ll need a good HPMS to round out your BPMS.

Models and Pasta

Sunday, November 2nd, 2008

I was reading various posts about modeling (in the BPMN sense) and it seems to me that many of them are confusing the ability to use modeling tools to codify requirements, and the use of modeling tools to actually generate the code needed to execute the process. 

I remember that we started thinking about model driven development over 10 years ago at IBM Research. If you could only let the business analyst model the process - and then generate the actual executable from that model - what a jump in productivity and agility. It was even worked with various toy examples. The difficulty is that designing a detailed enough model of a process to generate an actual executable program required the same effort (if not more) and the same set of skills that you needed to develop the program to implement the process.  So in reality the model became a spec or requirements doc for the developers. You could imagine these models being a good way to implement agile programming for BPM - where the analysts and developers use those tools as part of an iterative development process - but alas most of their usage is closer to waterfall development than iterative development.

Take a look at the  real life BPEL diagram shown in the drool’s blog - it made the process description the worst kind of unmanagable spaghetti. Even with all the complexity shown, it isn’t even close to the most complex business process you can find out there - whether it is a human process or a business process.

So are BPMN and BPEL a step forward or backward in enterprise application development? I think they are a good way to collect initial, high-level requirements (BPMN) and as a machine readable, system independent language for business models (BPEL). Lets not fool ourselves though, as with any tool for collecting requirements - it ends being a recommendation to the developers - not a production code generator. That is unless you limit the process domain being modeled to processes that consist of a small set of simple, well-defined, recurring, easily tailorable task templates - with relatively simple control flow logic between the tasks.