BPM Exchange Social Network

What started as a discussion has now turned to a complete post, reanimating in fact an old debate about using BPMN as a standard notation suitable for aligning business needs and IT capabilities. Although few BPM software vendors still resist the adoption of BPMN today, I will not spend time to justify why they should seriously consider BPMN, as this has been discussed and reviewed so many times in the BPM community, three years ago by Dr Bruce Silver. One should understand that today, industry giants, including IBM, SAP, Oracle and Microsoft, have already adopted BPMN. To people who still doubt BPMN as a minimum requirement to participate in a BPM project with an implementation in mind, I tell you this: if you can’t beat them, follow them!

There are other drivers to BPMN wide adoption that preceeded its support by software giants. And we actually decided more than 3 years ago to adopt it and recently enforce it on BPM Exchange, as a minimum required to drive BPM projects to success.

Now, the main point of this post is how to use BPMN effectively, at different levels, in a typical BPM project, while involving both technical and non-technical people. Through this little story, I will illustrate the power of this standard notation from OMG – the organization responsible for BPMN and other BPM standards. The story I’m about to tell you is inspired by a recent case I worked on. You will find here a typical scenario where BPMN can really help, at least for expressing business needs. For the sake of confidentiality, the character names have been changed.

So the story is about Joe “Plumber”, a small business owner, who recently hired management consultants to help him move to the next level in his company development. The consultants highly recommended he put a new complaints management program, to allow him stay closer to his customers, retain them and maybe improve his skills as a plumber!

Joe has multiple customers and he knows he will probably need IT support to handle this new need (Customer Complaints Process). Joe has implemented a CRM system, say SugarCRM, the Open Source clone of Salesforce.com. So Joe asked Bill “Geek”, an external IT consultant who takes care of the CRM system, to help him out and see if he can help:

Bill: Joe, great, do you have a specification document or RFQ so I can assess what is to be done in our information system?

Joe: Not really and you know, I don’t have much time to write a spec and nobody in our company has that time now.

Bill: Not a problem, I know a friend of mine, Patricia “Facilitator” that can help. She is a business analyst and she has good reputation in RFQ writing. It won’t take much of you time and she may help specify your needs in a day or two.

Joe: Ok, bring her in to see what she has in store.

So, before getting further, allow me to remind that with BPMN, we often consider three levels (or depths) of modeling:

• Business Level (Level 1): this is the first level for the process description, where Joe and Patricia will try to sketch a high-level overview of the process. They will capture the “happy path” of the process.
• Functional Level (Level 2): at this point, Patricia will interview further Joe about some details regarding special events or exceptions that need to be handled. She will also capture people or system activities, specific decision criteria, business rules, and maybe paper forms used in the process.
• Technical Level (Level 3):  at this level, Patricia will work with Bill to see how the current IT portfolio of services can support the new process, including its exceptions and “unhappy paths”.

These are similar to the 3 levels Dr. B Silver explained in his blog (descriptive, analytical and executable) and revisited lately, although there may be some differences of course. Will this be a specification for the OMG OCEB exams?

Now, back to our story. Two days later, Patricia was on the phone with Joe, asking him general questions so she can grab his requirements. After a 30 minutes conversation, she could come up with a BPMN diagram that looks like this:

DIAGRAM1 : Descriptive BPMN

The day after, she interviewed Joe again about specific business rules, exception paths and key performance indicators. Joe expressed the need to be able to track 3 performance indicators:

1. Nature of complaint categories: product capabilities, installation service, billing, warranty.
2. Root cause of complaints, depending on their nature
3. Minimum, average and maximum time between complaint initiation until resolution
4. Percentage of unhappy resolutions
5. Cost of complaints management process

At the end of the interview, Patricia was able to evolve form a descriptive to an analytical BPMN diagram, to end up with the following first iteration:

DIAGRAM2 : Analytical BPMN (in progress)

In this second diagram, Patricia added relevant forms, data and events to help tracking the KPI that Joe wants. This is not the final draft, but this can already be submitted to Bill for review. In fact, and if there one single idea I would like you to keep from this post, it would be: the anaytical diagram is the RFQ!

Now, Patricia has what Joe needs from Bill to implement and what Bill knows better what to implement as new functionality in the IT system to handle this requirement. Bill and Patricia will probably go to a third round if they want to implement the new process in a BPMS. But this is another story (a subject for another post?).

So, this is one of the powerful points BPMN brings to the table, it saves so much time to business people, while being far more precise than a traditionnal RFQ. Again, images worth a thousand words.