Unified TIBCO BPM Strategy

Jay Lillie and Rachel Brennan, product managers for Nimbus Control and AMX BPM respectively, presented in the final session at TUCON 2012, discussing a unified BPM strategy that covers both methodologies and technologies. While AMX BPM is about the enterprise-strength (and mostly structured) business process automation technology, Nimbus Control is about documenting processes and procedures. Nimbus uses a notation called UPM, which is somewhat simpler than BPMN for viewing procedural documentation rather than process automation. A single box in UPN, plus its connectors, covers the when, what, why and who; it also allows for hierarchical representation of each of these boxes, so that departments may be represented at the highest level, whereas specific procedures are represented at lower levels. Nimbus Control’s sweet spot is as an “intelligent operations manual”, providing an online reference and guidance for workers who are doing manual processes.

The point of this presentation, though, was to look at the best practices methodology that they are developing for a BPM development project, and represent that methodology in a Nimbus model. A bit meta, but whatever works. That includes five strategies:

• Get a big picture first, starting bigger than you think that you need and gathering a wide variety of information and requirements, then using constraints to work inwards and narrow the scope. That way, you are more likely to solve the real problem, not your original perception of what the problem is. I saw a great example of this when someone came up after my session this morning and said that he really wants to use some of these new technologies, but that he works in (essentially) product development and not directly with the  customers – hopefully, I helped him to think about how their entire end-to-end business, from inputs and product development through to sales and customer support, with its feedback to product development, is one big process: start with that, then narrow down the scope of implementation, rather than siloing up front.
• Link constraints, requirements and process, which allows you to scope the solution and get agreement on the high-level goals between business and IT.
• Consider metrics earlier rather than later, but don’t confuse metrics with requirements. This allows you to build in the ability to measure and act on the things that matter for your business performance.
• Plan a workshop specific to your solution. Involve the right subject matter experts at the right time, and don’t waste their time by lumping together large groups to discuss widely varying topics that may only be of interest to a few people in the room at any given time.
• Build user-facing test cases immediately, with test plans that work for both business and IT, and include signoff mechanisms. Scenarios must be tied to underlying processes, so that any changes to the processes will trigger the need to review the test plan.

They’re still working on this TIBCO Implementation Methodology (TIM), and it’s not just about BPM because they’re a stack vendor: although it’s starting with BPM and using a lot of the business-focused Nimbus methodology, it’s expanding out to include other products in the TIBCO portfolio.

I’m going to duck into the BPM engineering roundtable to finish off my time here at TUCON, so this is likely the end of my coverage from here this time since that may be under NDA.

Disclosure: TIBCO paid for my airfare and hotel costs to attend TUCON, and kicked in a speaking fee when they asked me to make a presentation on short notice. Rachel also promised me a Furla handbag, but I think that she was kidding.