TIBCO acquires Nimbus Partner

I really don’t know anything about the acquisition, but it gives me the opportunity to talk about the problems of selling business tools for unstructured (unpredictable?) processes. We were different than Nimbus in that we focused on unstructured process execution, while they focused on process design – but I think some of the lessons we learned hold true.

The main driver for enterprise adoption of process management technologies is the BPMS (Business Process Management Suites) ecosystem (vendors and analysts). BPMS are purchased, owned and used by IT. IT buys a BPMS to build various processes used by the business – but in the end the business sees only the resulting applications and for the most part don’t know or care how they were built. The business may have been involved in some design or brainstorming sessions when the application was being designed – but that usually was long ago and far away from their perspective. The business sees it is as an IT project to automate a process and IT got input from the business. Then sometime much later the business received an application that was supposed to be the new way to execute the process.

This works because IT is convinced that a BPMS allows them to automate business processes faster than doing it using standard programming. The BPMS model works because it took an existing paradigm (IT building applications for the business) – and enhanced it. A BPMS provides a good IT methodology\process for creating business applications (though as I always complain – a BPMS is not the mechanism used to manage the development process – you would think that the dogs should eat the dog food), and the resulting application should be available faster, better documented, more modular and more reusable than if it was done from scratch.

On the other hand, if you have a BPM tool that targets the business, rather than IT – your life will be very hard. If the tool tries to empower the business user and get IT out of the equation – IT certainly aren’t going to press for budget to buy it. On the business side the benefit is at the level of a process owner, or a project owner. So they need to find the budget for it. That means that you need to reach those folks, convince each one to use your tool. After that you probably need to also provide them with some level of training – since there are no real standards that can be leveraged (and don’t day BPMN – that isn’t a business tool). Oh, and you might have to involve IT too – since it is a technical tool. So you have all the pain of an enterprise sale, but without the ability to charge enterprise prices.

So what does this mean? Well first of all it means that the best way to get unstructured process management tools to market are in conjunction with a structured process tool. Almost every real world process is a combination of the two, and being able to sell a solution that spans both is a way to start getting the tool into the market. The structured tool will drag the unstructured tool. I believe that the sale will still be to IT – but it enlarges their arsenal to answer business concerns over “structured” BPMS. Over time you could imagine that things could work the other way (unstructured drags structured), but we are a long way from there.

Another thing we learned is that you can’t sell through partners – since this type of sale to a business user requires a certain amount of evangelism and business knowledge – you need to do it yourself. TIBCO will need to learn how to leverage (and when to bring in) the Nimbus team for a sale – TIBCO won’t be able to sell a joint tool without them.


3 Responses to “TIBCO acquires Nimbus Partner”

  1. Scott Francis (@sfrancisatx) Says:

    “(though as I always complain – a BPMS is not the mechanism used to manage the development process – you would think that the dogs should eat the dog food)” – actually doing this in some cases. For example, when I was at lombardi we used our BPMS to run a good bit of the development/build / QA process. a layer on top of existing automation (source control, testing, compiling, etc.) but also opportunity for human intervention.

    Also, we start with a BPMS representation – but it turns out there’s already a category of software dedicated to running a project – project management software- and building a process for running your BPMS implementation inside a BPMS – much of the effort goes into replicating things that MS Project , Rally Dev, or liquid planner, or others already do. It is a classic time-to-market issue!

    Great post – love the perspective you bring to this post.

  2. business systems consultant Says:

    business systems consultant…

    […]TIBCO acquires Nimbus Partner « Jacob Ukelson's Blog[…]…

  3. Aren’t Software Developers the Archetype Knowledge Worker? « Jacob Ukelson's Blog Says:

    […] What I don’t get is that software development is a shining example of what people in the process community call knowledge work. As far as I can tell, a lot of the latest thinking around managing knowledge work is being done by the business process and case management communities. Even though most of the people talking about tools for BPM and case management are software developers themselves – the tools and methodologies advocated by BPMCase management are not being adopted by the software development and operations community themselves. I see this as vendors not eating their own dog-food (or maybe not drinking their own Kool-Aid) and I have been posting about it for a while – see my last post on this and Scott’s great rebuttal here. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: