BPM and SaaS

I know I have been remiss in keeping this blog thing going. As I have alluded to before, the reality is that there are just not enough hours in the day. So as a next step, I thought I would start writing a bit about some of the work I have been involved in lately, drawing attention to the growing interest in BPM-SaaS oriented plays. As (if/when) I get permission to talk about these services more openly, I will post links and invitations, etc.

The first one I can start to talk about is Appian Anywhere (A2) – the Appian Enterprise (AE) product delivered on demand over the Web. It has been in private beta for a while now. I have been building the online training and video help for A2 which is due to launch sometime soon … probably early next year.

It has been very instructive for me - firstly, to have to get down into the innards of the BPMS and build actual applications … and secondly to appreciate just how much effort is required. That last point is at the level of developing effective applications and also building effective online training. Along the way, I have also discovered a few things about process modeling and what BPMN really enables (A2 is one of the stronger BPMN implementations), and also what is not in the process model but you need to be wary of.

I have had to grapple with application implementation issues that are really not part of the “process” model. I am really pointing at issues that the user has to deal with in getting their BPM system to present the related data and docs of the application (all deemed to be neatly outside of the scope of the BPMN specification). A2 (and AE) have one of the sexiest (Ajax) forms environments I have seen (I’ll see if I can put a clip up on YouTube). But even that forms environment relies on a robust set of process variables being defined for the process … which of course must be accurately mapped to all related processes and to the data sources themselves.

In A2 you declare the related variables at the outset (in the Process Properties), with a wide selection of types from the Boolean Yes/No through users, people, files, numbers, text, date-time, etc. Even discussion forums, folders, groups and messages can be defined as variables. Alternatively, you can just start process modeling and declare your variables as you need to, right in the middle of defining the process. Whenever, a new variable is needed, there is always an option to create one. The data itself is automatically persisted (although you do get the option of mapping the data to MySQL, Oracle and SQL Server).

Manipulating these variables is pretty straight forward – whenever you need to make a decision, place them on a form, or use the embedded Expression Editor - the context of the variable is automatically carried forward. For example, inserting a text data field into an external database, will automatically provide the text variables to choose from. If the field were of a type Date-Time then the declared Date-Time variables are presented to choose from.

The point that I am trying to make here is that defining useful processes is a lot more than merely the order of activities and the assignment of tasks to individuals. You need ways of dealing with the process relevant data … and that is where the complexity really comes in.

Which in turn points to one of the challenges in BPM modeling for SaaS - who really is the target market, and how much complexity can they handle? There is always the temptation to just keep adding functionality to the process model (as you think of yet another wrinkle in the usage scenario). But the same is also true of the BPM Suite vendors. The problem becomes more “what you want to do/support”, and inevitably the development environment for a BPMS becomes ever more “complex.”

If your target market are really business users without Business Analyst training, then this sort of development environment (in A2) is probably just a bit too complex. But dont get me wrong, if your target market are those people who would have otherwise defined a robust process model to support the build out of a workflow or Java app, then A2 is a doddle.

As a final thought, on this BPM-SaaS thang, I am seeing a lot of interest. I recently recorded a Webinar for Search-CIO which will probably air in early January (when I get links I will post here). Point is that all sorts of folks are now engaging in the promise of BPM at all sorts of levels. My perception is that if we can fix the usability angle (getting people to do it for themselves), then we will finally start to see this BPM market start to explode and be taken more mainstream. In my last posting, I mentioned Itensil who I believe have made some big strides in this area - but they have done that by deciding not to support the transactional process (which is the core of most BPM Suites). They are focused solely on the needs of knowledge workers in their collaborative processes (what I describe as “roughly repeatable practices” rather than “rigorous procedures”).

Case Handling Discussion

Mea Culpa - yes, like others in this space, the challenge is keeping the blog going. Usual story of not managing to keep the clones working properly while I am sleeping. Lots of things to start sharing here … and now that I am out from under the endless train of deliverables and trainign courses, I should be able to find the odd bit of time.

The reason for this long awaited posting … I felt I wanted to pick up on discussions emerging in the BPM space - driven by Henk de Man’s presentation at the OMG meeting last week. He was talking to the need for better modeling approaches to support Case Handling (or Case Management depending on your perspective).

Like James Taylor (name now corrected),  I thought Henk’s presentation was also interesting. And as I pointed out during the session, a great many processes should be viewed in the Case Handling context. Readers might also be interested in the papers I produced that discuss these sorts of issues. But really getting at it from the pov of the Customer and Processes - “Business Processes and Customers - Difficult Domains to Integrate” available in the White Papers section of the BPM Focus web site.

The core of Henk’s presentation was that BPMN style modeling is not much help when trying to capture the essence of Case Handling. His own product has a strong Case Handling orientation and uses “States” and “Events” to enable some of the flexibility that Case Handling apps demand. In my experience, the key differentiating factor (between a tranditional workflow/BPMS app and Case Handling) is that the emphasis is with Case - it may have many processes and documents associated with it.

I suggested to him that he investigate Role Activity Diagrams (a way of modeling at how the Roles involved change state as a result of the actions and interactions that occur). This is perhaps much more appropriate for the state based view he was hankering after. The best reference on this is Martyn Ould’s book “Business Process Management - A Rigorous Approach”

But all should understand that Case Handling approaches have been around for a very long time. They are everywhere you look once you get it in your head. Think of these:

• Government - State and local government, NGOs, Police, Justice (investigations), Land mgt …
• Financial Services
• Insurance - Every claim is an exception
• Banking - Trade exception handling, premium account management
• Healthcare - From clinical provision to administrative management and payment
• Oil & Gas Exploration- Knowledge workers spread thinlyaround the world
• Pharmaceuticals - Clinical trials, compound development, marketing campaign management
• Virtually all “professions
• Wide range of Small to Medium sized contexts
• All sort of Procurement situations
• Customer Contact Centers - across virtually all industries, where they validate, identify work items and then resolve … here 80% of all calls are WISMO (What Is the Status of My Order)
• Even the weekly Staff Meeting is a kind of case handling situation if you look at it from a process point of view.

All of them have continually unfolding, evolving scenarios. That is where BPM needs to concentrate its efforts. The transactional space that has characterised efforts to date is really pretty straight forward. Case Handling involves synchronous interaction with users, long running case resolution situations, multiple process fragments, knowledge work, …

Interesting vendors in this space are few and far between. At one level it is big systems implementations such as Cordys, Pega and Graham Technology. But there is a simpler more accessible level that is best characterised by folks like Itensil (in my mind one of the most itneresting I have come across). I am sure, that with care you could implement TIBCO, Appian and Lombardi to build effective Case Handling situations, but it is really a quesiton of adopting the right style of design thinking. And with more and more of these vendors offering SaaS delivery mechanisms, I think we are going to see an ever increasing level of innovation in this area.