Life in the Swimlane

Unfortunately, I missed the presentation by Robert Shapiro on the BPMN 2.0 update that was hosted by the WfMC, but they were kind enough to share with me the PowerPoint that he talked through. I guess I like where this is going, although it appears to be going too slowly.

I am from the Process Analyst audience and not as concerned with the blending of the needs of developers with the needs of users. Yes, it does make the developers life easier if XPDL is included in a process model, but what percentage of process models actually get to the point where they are part of an automated workflow? I’m just not seeing client’s anxious to get to that point.

I see two drivers for this “inaction.” The first is the cost of the tools and this is being address by the BPM vendors offering SAAS solutions. The second is the dirty little secret that many in the public sector don’t want a system that will broadcast inefficiencies - and BPM certainly does that.

Back to the update by Mr. Shapiro…..

I truly appreciate the multi-level view of process modeling that he describes. The Simple class which provides a high-level map of a process, and the Descriptive class, which gives a level of detail that enables process analysis and improvement, are intuitive.

Form here it seems that we take a turn towards a Domain class, where his presentation sites DoDAF. I can envision other domains establishing a subset of shapes and functions that fit well with their industry. The final view is the Complete class which includes all of the BPMN shapes, functions, etc.

I appreciate that they are attempting to serve the needs of both the Process Analyst and the BPM Developers and rather than creating a strict set of rules are offering guidelines and choices.

OMG meets at the end of the month in Jacksonville and if my schedule permits I will attend to see where they are taking this. I appreciate your feedback on my observations.

Hope you all survive the Santa Process (Thanks to Adobe):

It was bound to happen and perhaps this marks the beginning of the consolidation.  With IBM’s purchase of Lombardi, one of top-tier pure-play BPM Suites has been gobbled up.  I see multiple impacts on the BPM world.  First and fore most, Lombardi benefits from the instant expansion of its sales and marketing staff.  Also, since many of the 300 IBM resources from their performance CoE have experience with Lombardi, the implementation team has expanded.  On the other side of the coin, IBM now has Lombardi, FileNet, and WebSphere that all play in this space. It will be interesting to see how this shakes out inside of Big Blue.

What is the impact on the other pure-plays?  Time will tell but I would not be surprise if Oracle tries to expand its presence with an acquisition.  Though BEA was brought into the fold to provide them with this capability, and they do have the modeling tool already, they are not the first vendor that comes to mind when you think of a BPM solution.  I hope they do not acquire a product that stands on its own well as they tend to assimilate products to the point they they only make sense with other Oracle products (I hope this doesn’t happen with Primavera, but that is another topic for another blog).

I have not heard from the Appian camp how they feel about this but it can’t be viewed well when your biggest competitor instantly gets bigger.  Have Global 360, PegaSystems, HandySoft, Tibco, and Savvion suddenly been thrust in the spotlight as acquisition targets?  Prior to the Lombardi purchase I would have thought that Global and Pega were safe since they have a good market share, but obviously anyone can be targeted at this point.  IMO PegaSystems may be hurt the most by this as they were an IBM Partner.

And where does MicroSoft stand in all of this?  In recent years they seem to believe that their best course of action is to continue to build their own solutions.  While SharePoint will introduct BPM capabilities in their next release, I don’t see anyone in the BPM world taking that seriously.

The beginning of 2010 will be interesting as this ripples through the industry.

An interesting question was raised when the prime for the opportunity we are pursuing asked for input regarding the project organization chart.  On the first draft that was sent to us, the chart almost reflected the tasks rather than the organization.  Were they implying a seperate group for each component of the project life cycle?  So I got to thinking about the linkage between process and organization.

Quite often the process improvement work we undertake leads to re-organization.  In the days of re-engineering this was the harbinger of “downsizing.”  It gave process analysts a really bad name.

So what comes first, the process or the organization?  Should all organizations be structured around business processes?  Or do processes need to be modeled to fit the organization?  I suppose the business driver of both is the business itself.  What is the goal of the business?  What processes are needed to support the goal?  And how do we structure the organization to follow the processes?

From a project perspective, the same method could be followed. What are the goals of the project? What are the business processes that deliver on those goals?  And what structure best fits?

It would be great to hear from others on how they see the interaction between organization and process and how the process community sees this chicken and egg scenario.

It was obvious from the solution presented that they had no idea what BPM was nor the role that a BPMS would play within a complex architecture.  There was a lot of talk about data integration, ETL, a data warehouse, the need for a dashboard, custom interfaces with time entry systems, project management support and a host of IT buzz words captured from the latest technology article in an airline seat-pocket magazine.  There were lines and boxes all over the Visio drawing, a work of art worthy of a fine PowerPoint presentation.  But not a single person thought about the process or how technology should support the process.

The problem is easy to solve if you take a process focus.  What is the intended outcome of the work that needs to be performed? Who will be doing the work?  What tools do they need that will help them accomplish that goal? And how can you tell if its working?

The people in The Room on the other end of the conference call were so hung up on presenting an IT Architecture that captured every node of the client’s platform that nobody was thinking about the reason for the technology in the first place.  I offered for consideration a BPM Suite.  More than just a workflow tool, the BPMS addresses integration, messaging, performance management and data presentation.  The Room went completely silent……I sent an Instant Message to my colleague who was also on the call to make sure that what I said was heard…..he confirmed that he heard it……Someone in The Room spoke up and asked a question that had nothing to do with what I said - and the chatter went back to discussing more lines and boxes on the Visio drawing to address cloud computing and BI tools.

I am supporting but not leading this opportunity as the voices in The Room are convinced that their approach is best.  They may well be correct as I am new to this and don’t know the client all that well.  But the client has asked for a specific description of a BPM solution and how it will be used. 

What I like about BPMS tools is that they are a technology that needs to understand the business before it can be implemented. Without a process, a BPMS is like a box of unsharpened pencils.  It’s there able to help when needed but first has to be sharpened and then guided by a knowledgeable hand.  It then becomes so simple to use that little explanation is needed - it supports the workers understanding of their job.  It is an enabler rather than constrictor.

For now, I will continue to sit on my end of the conference line politely pointing out what I believe is missing in their plan.  Hopefully someone will soon ask for a pencil…..

The vertical market that my firm works in is the Architectural and Engineering space.  It is actually a great spot for process focused IT.  Just about all of our internal and external customers are knowledge workers.  And it is very rare that they conduct their work within the walls of their own office/cubicle or other space.  Sooner or later, they share, collaborate, or review something put together someplace else. So when I try to explain just how BPM can help, they immediately put up a personal firewall and worry that I’m going to introduce structure to their creative process. 

Poppycock!  They have already developed their own structure and I have have no intention of changing it.  My job is to facilitate the handoff to make it as easy as passing it over the cubicle wall.  Only I’m going to suggest that they track where it went, when it got there, and how long it stayed.  This introduces yet another fear that we are going to measure that which cannot be measured and then punish the tardy and meticulous. 

Balderdash!!  We are going to supply data about their process.  What they do with that data is their decision.  They can baseline it to see if things change over time.  They can use it to ensure that charges for their service are adequate to cover their costs.  Or they could just display it on a fancy dashboard and point out to their upper management that they have joined the 21st Century.

Recently, I’ve been involved with a pursuit that screams for a BPM solution.  The potential client is looking for document management, workflow, performance metrics and integration with their legacy systems.  But as the IT “thought leader” working with A&E principals, it is a challenge to get them to hear the same bells that I hear.  Of course cost comes in to play here and that becomes the biggest upstacle when working with team members who feel that Excel is all the technology that they will ever need.

So here I am, the BPM Evangelist who realizes that pushing too hard will just push me out of the picture but caving to the minimalist solution will leave me working 80 hour weeks to get the “architecture” to work.  We have a quick turn-around on this as we have about a week to agree on the solution, document how we would do it, and submit a proposal to competitive bid.

I’ll keep you up to date on how it goes - when I have time to write for this audience as opposed to the potential client.

I hope I can stay afloat with this one……

I have spent the last couple of days surrounded by fellow process geeks listening to Appian introduce the latest version of their BPM Suite.  Some very interesting insights from Forrester, Gartner, and more importantly, some of Appian’s clients who have implemented Appian and deployed several process based applications with the tool.

Appian’s BPM Suite has become more of an application development platform than a pureplay BPM tool.  It will be interesting to see how the general development community accepts this new broader use for their tool. It certainly makes the development of process based applications much easier.

Appian somewhat reminds me of Lotus Notes in its ability to do much more than collaborative workflow, but I don’t want to burden them with that albatross of a label.  But if the other BPM Suites follow suit, perhaps Lotus Notes will be considered the Edsel of software platforms, offering features and capabilities that consumers were not quite ready for at the time but became expected much later.

The most interesting part of the Forum was the sharing of “expert” solutions that have been developed and delivered with the software.  It seems that process architects are very creative when it comes to designing workflows to address complex processes.   And I  am purposely using the term process architect as this tool requires an advanced skill set - not a complicated one, but it is more than a BA or application developer.  The ideal Appian developer combines the talents of a solutions architect and a business analyst, able to visualize the end-to-end application and all of the human and application interfaces needed to make it work. 

There certainly are roles within the Appian framework for the traditional business analyst and for application developers, but what really makes this successful is that process architect who can design, model, and deliver exactly what the business needs.

My next steps are to learn enough about the software to determine who is best suited to become that Process Architect.  There appears to be more coding than I am willing to take on, and more process focus than I am willing to hand over to most of the developers I know.  It may prove that this is a shared role where the technical and business lead both have the capability to develop within the platform.

I will say that the hosts from Appian have been very cooperative and are more than willing show me all I would like to know about their product.  I only hope that my development team is as anxious to learn as the Appian folks are willing to teach.

When BPMN first was announced and introduced, I had a sense of relief that workable standards were being established for process modeling.  It was minimalistic, concise and easy to work with.  It also left many things unclear and had definite room for improvement.

Along came 1.1 which filled some of the gaps, left leeway for use and interpretation and added a bit of complexity in the Events area that seemed necessary from a programmatic stand point.

Then we were treated with haggling, conjecture, bickering, disappointment rumor and a lot of questions as a move towards 2.0 began.  It seems to me that what began as an attempt to enable the clear representation of processes in a standard notation became a complex impossible to decifer format enabling programmers to understand process.  While I have always thought that there was a need for programmers to understand processes I think it is more important for users to understand processes.

Perhaps it is my background in technical writing before becoming a business analyst that makes me focus on the need to translate technical jargon into easy understood and consumable information.  And maybe I just need to study and understand 2.0 more before ranting against it.  But I believe that the purpose of process models has been lost and we are no longer trying to provide an easy to understand depiction of a business process.  It seems to me that 2.0 is trying to serve too many masters and perform the impossible - to provide a single view of process that serves the needs of IT and business users.

Why is this impossible?

The reason that a single tool cannot server both purposes is because people in the programming and technology fields absorb information in a different way that most people.  Most programmers, and I hate to generalize but I’m going to, think in a linear path. Logical, structured, addressing a single activity at a time.  Business users are more scattered.  In my experience the typical business user looks at something and tries to figure out what is wrong with the process or what can go wrong.  The typical developer thinks, “Why would someone do that?”

So as we move down this road, the standards developers are being taken over by more and more technically focused subject matter experts.  We will end up with a tool that is just like UML in that it will hold no interest to the business community.

What’s Next?

I guess for me it will be time to become an expert on 2.0 and attempt to explain it to the business users who are typically my customers.  They will ask me why I can’t create a process model that is easier to understand and I will capitulate and do so.  I will then have to maintain multiple versions of a process model, one for the business users - the real customers, and one for the developers.  Eventually, everyone will agree that this is stupid and we will begin to work on the next generation of a workable standard leaving BPMN in our wake…..

Welcome to Life in the Swimlane, a blog where I will post my thoughts, experiences, and opinions on process improvement, management, and transformation.

As a consultant who has been involved with process improvement since the 80’s, I’ve witnessed and experienced a lot of the good, bad, and ugly in the methodologies that my father called “Efficiency Expertise,”  Hammer and Champy called “Re-engineering” and most refer to as business process improvement.

I know that there is a difference in these terms, as most in this community are aware. But our customers lump them all together - and if we don’t recognize the thoughts of our customers, well, we won’t have any.