The Process Ninja Meets Nimbus

 
I'm a regular reader of the blogs of Ian Gotts and Mike Gamage from Nimbus, so I was really interested when I got a call out of the blue from Mark Cotgrove, Nimbus's EVP of Emerging Markets & Global Alliances who happened to be in Sydney.

Mark was kind enough to speak to me at Length about Nimbus Control - something I had been interested in doing for quite some time. Nimbus have big plans (I won't say too much about that) but I'm keen to see them improve their footprint as it's a product I was impressed by. OK, so it's always difficult when someone demos their product because they always make it look good, but I like to think that I have the knowledge to be able to cut through the bullshit.

So without writing a 10 page blog post on Nimbus Control, here's the executive summary: I liked it. Why did I like it? Well, the thing that stuck in my mind about Nimbus is that it's built as a tool for end users - not business process people. That might sound disappointing for some of you out there but it shouldn't be. Think of Nimbus as a highly evolved operations manual for staff and you are getting there. It's for the guys in the call centre or the factory floor to use as an aid to do their work - much like the chap at the end of this video fopr Nimbus's client Carphone Warehouse. 

These guys aren't interested in BPMN swimlane diagrams or enterprise architecture - they just want to do their jobs, as quickly and as simply as they can. Therein lies the difference: a focus on staff using the tool rather than a tool by which to build or automate business process. I'm not saying Nimbus can't do that, but there is a fundamental shift of focus onto the users.

I also liked a number of features of Nimbus - it's ability to manage process compliance was impressive as was the ability to map processes very rapidly (something that is extremely painful to do in some other process tools). OK, so their Universal process notation  takes some getting used to and requires a bit of a mind shift, but the logic of it does make sense to me. I am not 100% convinced that it is the easiest notation to look at and understand and I have issues with the fact that the notation can hide the complexity of processes within multiple layers, but they do assure me that there are ways to see the end to end process in a single view.

Nimbus has been criticised in some quarters as being limited from an enterprise architecture perspective, and interestingly Mark argued that the linkage of enterprsie architecture from top to bottom in an organisation can't be done, as there is a fundamental difference in the language. To a certain extent I can see the difficultly, but I'm not convinced it's an unsurmountable problem. Probably a discussion deserving a post to itself.

Until then, have a look at Nimbus Control and check out some of the interesting videos on Nimbus TV.

Cheers,

TPN

Comments

[mark cotgrove]

Hi Craig, just a note of clarification as I’m not sure I explained myself well enough wrt to what we see as the relationship between EA, the automation (BPMS) space and what Nimbus Control does.

 
EA and us – we see EA as a separate discipline to process management although any EA model needs to reference process models as assets. The understanding that EA requires of the process model however is not the same as that required by the end-user to actually do the process. There is no question that our content is clearly part of the EA picture, however it is just one asset class along with all the other assets classes that an EA model manages. Although Nimbus Control can do EA, generally we prefer to allow our process models to be referenced by the specialist EA tool in question.

Process automation (BPMS) and us – this is where I meant to make the commetop about the top to bottom process picture; the key is language. It is clearly possible to build a high level process picture of an organisation which decomposes down to low levels where there will be requirements to build automated workflows. My point is simply that the human description of a process needs to contain a different set of complexities and information from the same process described in such a way that a BPMS engine can automate it.

Both views require information and structure that simply doesn’t exist in the other view hence why we believe that there should not be one language for the whole stack, but two. Humans need a language they understand, (we propose UPN) the automation engines likewise, hence BPMN; the two languages are complimentary, but necessarily different. Ensuring that the two models work together requires humans, this is where the BA skill set comes in.

Our process perspective is totally complimentary to both the EA and automation spaces as proven by many of our clients; simply that the spaces are different, need to be treated differently and have different languages that are required to provide the information that each discipline requires.

[Richard Blakemore]

Hi Craig. I will definitely check Nimbus out. Have you ever looked at Xsol? www.xsol.com.

It is deliberately not BPMN 2.0 compliant, seeming instead to focus on getting automated processes done and dusted and rolled out within hours. If you have had a look at it, I would be interested in your feedback...