The Next Decade: BPM & The New Social
This is an excerpt from my keynote at BPM2010, held at Stevens Institute of Technology, Hoboken, New Jersey, USA on Tuesday, September 14, 2010.
As we chart the course of human technological achievement it is amazing how scalable technology is; how empowering software is. Here's where we are today. In every company of any size there's a hard core technical person; the programmer, the Java developer. And even in companies of substantial size it's really incredible how few of those people there are. Software leverages the genius.
In order to fully exploit this person we've created an entire IT organization to surround him or her. This group runs the software written by the developer, it deals with the processes and maintenance, and typically it provides the interface through which this person gets requirements; roles like business analysts are often in the IT organization. Typically, there's about five of these support people for every one of the developers and, in total, we call this "IT."
And for every six people in IT, there's about 240 real business users! This shows how leveraged IT is and is one way to think about how the power of software has led to the scale that companies are able to achieve today.
But there is a downside to all this scale, a price to pay: Agility. There's a bottleneck that's created when only a few people can actually change the systems that run our companies. Those 240 people are getting stuff done in every way possible. And they are interacting more and more with outside companies to get all their work done, not to mention the growing diversity of their customer set as we all go global. The complexity in the 240 is rising and they all have demands for "Change!" that simply can't be met. The six are under siege.
The velocity of communication in The 240 is way, way faster than the throughput of the six.
Of course we've created tooling for the six. They were our market for software and hardware. The tooling's gotten better and, most recently, even BPM has helped them do their jobs better. But let's not be fooled: even the easiest-to-use BPMS's mostly require the six to do the development. We've moved out from the one, but 90% of the BPMS development that occurs today is done by business analysts or by regular developers. We have made their jobs easier, allowing them to be more productive, but we haven't truly changed the fundamental dynamic.
As I mentioned, there is a price to pay for this leverage. The first was the bottleneck we created on the development side. The second is that the understanding of the business process has to be communicated to the six by the 240. We've created go-betweens. Business Analysts are not performing high level (and high value) quantitative analyses of their businesses; instead they are interviewing the business subject matter experts and structuring their input into some form that the developers can understand. Again, there's been tooling that helps this (for example, BPMN-based models) that speed this up and move the explicit structured conversation closer to the 240, but by and large even this is the domain of the six. Business people just don't care about the abstractions that are required for scale. They just want to get their jobs done, get home as early as they can and spend time with their family.
So the next great challenge is before us: how do we turn the notion of scale on its ear? How do we gain the involvement of the 240 real business people so that without training they can contribute their knowledge of how things work, their requests for how things should work into the explicit, unambiguous conversations required for automation? And, by doing so, how can we increase the velocity of communication for everyone, so that requirements can be more exact, more quickly and communicated more effectively, so that the scale of software can be enhanced even further.
This is the magic of the new social: turning the notion of scale away from leverage of one-to-many, to the leverage of many-to-one. That is, harvesting the direct knowledge of the many and feeding it in a structured, consumable form to the one. Can we, for example, double the 240 to 480?
By the way, this not only makes the normally unstructured conversations of real business people (documents, spreadsheets) into structured information but it also makes explicit the requirements directly from the askers instead of of from translators. It makes language itself a shared model!
Comments