08/07/08 :: [BPM] Social Networks and BPM [permalink]
A few months ago I had written a post about the Web 3.0 and expressed that in its 3rd generation, "the Web will work for me". That's for me where Social Networking would play: always have the best people do the tasks at play. That's what I called several years ago Right Sourcing. Many of you know my otherwise aversion for Web 2.0 concepts applied to the Enterprise.
Mark Masterson posted an article asking whether "Social Processes" would be the Enterprise 2.0 killer app. The Web 2.0 is a bit like Jam, the less you have (to talk about or do something with), the more you need to spread it.
Before I start discussing the topic, I'd like to say that I can't imagine what Enterprise 15.0 is going to look like. My impression is that if people keep labeling everything 2.0, at some point, it will start looking like 1.0 is a failure and we just want to turn the page. But do the 2.0 people really think in terms of understanding why 1.0 is a failure? Do they really think that the "Web" (as a development, middleware and security platform) applied religiously to all aspect of IT is a guaranty for success? Where is the evidence? Where is the evidence that what worked for "content" will work for "information"? This is quite a big responsibility that some people are taking today, without even the shadow of a rationale for it. So let's look at Mark's rationale.
... Well, OK. Except it doesn’t work...
Mark, you must be kidding right? What could we do without computer based information systems today? Banking, Insurance, Retail, Manufacturing. The fundamental premise of an information system is to keep "state" (inventory, balance,...). An information system "knows" where the real world is at. It was painful, granted, but... it works, no?
The real world is so much more complex than we thought
Really? Have you ever considered actually that if you don't used a "state" based formalism to model the states of the real world, the problem could actually look very complex. You are inherently trying to model something that is not sequential and highly concurrent with a sequential formalism that does not know anything about concurrency. Is that really logical? Does it make any sense? Who are the geniuses who are driving this rationale? Could we consider once an for all that Lambda Calculus does not solve all and any problem? could we consider once and for all that "Computer Science" is different from "Information Science", could we consider once and for all that we have been calling Information Technology, organizations that are really "Programming Technology" shops. No wonder "Enterprise Data" organizations are trying to build a bunker to isolate themselves from would be solutions architects and developers. I am actually surprised they have not added "resource lifecycles" to their enterprise data, they could call it done.
all it seems we do all day is manage exceptions to our processes.
Here we are, have you ever considered how impossible it is to describe exceptions with a sequential concurrency challenged programming model? Do you even think the designer and users can really predict all exceptions paths? Now if you were to use a state based formalism things would be quite different. As you model the states (of the real world) and their transitions, exceptions -all exceptions- are surfaced ... how should I say ... serendipitously.
We don't need crap like:
Process is an embedded reaction to prior stupidity
Processes don't exist, states do and with states, "work-flow". A workflow represents the activities that are performed (human tasks or automated) to transition resource lifecycles from one state to another. Exceptions surface as transitions cannot be realized by the work performed by an activity.
Processes fail and silos persist despite dysfunctional matrices.
Do you know why Mark? Look no further than a sequential concurrency challenged programming model based on corny concepts such as client/server, synchrony and CRUD-orientation. People can't build information systems because Computer Science is about "computing" not "information".
The problem is not business processes. The problem is trying to automate business processes.
No, Mark, the problem is the corny programming model that you support. Automation is good, automation works. As you "graft" human tasks to perform transitions from state to state, you have an exclusive vantage point to decide what to automate or not and how. Process Improvement is not about achieving an end-to-end view of "the process", process improvement is about understanding the nature of the real world and facilitating the transitions of the real-world from one state to another. Don't you understand that the reason why Lean approaches limit the number of changes per iteration is simply because they have not surfaced the resource lifecycles and by changing more than 4 or 5 "things" in a process, they can't predict where things are going to go -at all. Automation works just fine once you understand the model of the real-world and step away from Computer Science and enter the world of information science.
In your world, it is not surprising to find out that "processes are barely repeatable", have you ever considered the number of combinations of states, transitions and activities in a typical "enterprise" process? Think about all the states of customer, order, invoice, payment, shipment... think about all the tasks that can be performed to transition from one state to another. How would you think that "processes can be repeatable"? "discoverable"? "express-ible"? You can't, the current thinking of BPM only works because we tackle problems that have few states and few information entities.
this stuff hasn’t lived up to its hype.
How could it have? With people like Assaf Arkin, Howard Smith or Frank Leyman who looked desperately for a "Turing complete" solution to the problem? How in the world could it have lived to its hype?
Back to the drawing board, then! If it's not working, we must just not be doing enough of it. ... This approach seems to lead to process models that are too complex.
Yes, you get it. No sorry you don't:
modeling business processes is programming
It is not programming in the Computer Science sense. What happens when you build a system the way you (and most of the BPM pundits) suggest, many "paths" are missing in action. Users become frustrated as they confronted to a system that should allow them to "transition" from one state to another, because it is logical (from a business perspective). Yes, it is easy to model lifecycles in business terms, but the analysts and developers by focusing on the "business process view" missed that path like holes in Swiss Cheese. Kind of obvious, isn’t it?
enthusiastic attempts to make assembly lines out of every process
Mark, what you are missing is that industrial processes understood a long time ago the notion of States. The first 10 years of my career were spent building industrial process control systems. If you were to look at them (in details) you would see how automata work. Yes, at the "behind-your-desk" level, it looks like a series of activities that people do, you can observe these activities and you can say, ok, check this out, it starts with A, then B, then C and you conclude I need a "programming" environment that allow me to control a sequence of activities. How can someone as sophisticated as you can stay at the "behind-your-desk" level?
The other part is collaboration.
Yes you get that, it be a lot clearer if you would consider the important of a "task container" where collaboration can happen, it has nothing to do with "the process" or the completion of the task.
If we’re going to evolve at a faster pace than our competitors, we can either invent HAL 9000, or make it easy and rewarding to find and collaborate with one other.
You are lost, you say, look Turing does not work, therefore there is no hope for anything else. Don't you think there is a bit more shades of grey between Turing and HAL?
In the most ironic fashion, Andrew's TLA is just one letter away from "states":
SLATES (search, links, authoring, tags, extensions, signals).
Maybe, just maybe, you could consider that you have misspelled the concept that you are looking for to solve an otherwise extremely basic problem. Do you really think that these concepts are related to information systems:
...Blogs fit that description? Or wikis? What about stuff like instant messaging? Or email?
Have you even thought for a second to build information systems from these concepts? Isn't it clear that as long as you will ignore the "states" "SLATES" are going to be useless. You will not be able to efficiently choreograph the workflow except for the most trivial cases where states are somewhat naturally related to the workflow?
We need to build Enterprise 2.0 capabilities -- social networking software functionality -- into our business processes.
Wrong, dead wrong. How will it guaranty that lifecycles are executed per their definition? Social Networking capabilities need to be baked into the task container.
exception handling (inevitably a human labour intensive task) can be made even more efficient.
How in the world could social networking fix missing states or transitions in an information system built by clueless analyst, developers and architects? Just how? You mean there is such a thing as a magical number of humans, when thrown at an unforeseen exception paths, the information system starts behaving properly? States and transitions magically appear? WTF are you talking about? Maybe, just maybe, you could do a root-cause analysis of a problem before trying to apply a fix.
By adding social networking functionality to existing BPM systems, enterprises can get the benefits of Enterprise 2.0 with clear, measurable business results.
Let me make a prediction: By adding social networking functionality to existing BPM systems, you can expect to greatly increase the labor needed to perform tasks because people will "take advantage" of their social network.
And until HAL 9000 goes online, that combination is likely to provide a massive competitive advantage to somebody. Why not you?
Sad, very sad. I am actually impressed at the extend people like you will try to completely ignore the obvious. Scientifically, you could say, I want to look at every possibility, and so you did, there are only two: Turing and HAL. Mark, how low can you go?