Enterprise 2.0: it's not about people it's about process. Part 2
Sig likes to think about unstructured work as representing attempts to handle Barely Repeatable Processes (BRP.) These are the exceptions that bedevil our ability to smoothly add value even though we otherwise might have perfectly good business processes.
The above slideshow from Mark Masterson makes the point that when dealing with exceptions, the best tools available to us are the knowledge that resides in people's heads. Ergo - the argument goes: implement social software as a way of capturing that information for current/later use. I don't have a problem with this except that as currently iterated, most of the tools represent yet another IT silo outside the process flow. Even so, I'd encourage folk like Mark to keep refining their thinking so that critics like myself stand a chance of being persuaded.
I returned to Sig Rinde who has been developing a process engine the last few years designed to address this problem. He argues the nub of the problem lays in the lack of granularity around IT led processes such that it is extraordinarily difficult to carve out a broken piece, fix and replace. Even if that replacement is temporary and even if there is SOA in place. I doubt my friends and foes at SAP/Oracle/Microsft/IBM would protest that statement. Sig also says that because of the massive waste he calculates, the embedding of social tools inside lightweight process engine generated applications just makes sense.
The best example of a broken process I can think of impacted me the last few days when a bank doubled up on standing orders. It was relying on an automated process but did not have a flag that said something like: "If you see this duplicated then please check." To make matters worse, the call center procedures were so borked the person handling the call had no sensible way of fixing it. Two hours of frustration later and a supervisor figured out what to do. But only after I stated the bleeding obvious. Whether my experience is an outlier is another matter but it would make sense to capture the essence of the event for future use, build a process to handle it and plug-in/out as circumstances dictate. At the wacky extreme, you could argue there is no need to fix the problem but simply have something in place such that when it happens, the process can be temporarily amended. That then satisfies all those who are terrified of introducing yet another potential area of process brittleness until it is shown that our BRP is in fact an Easily Repeatable Process.
Sig's current answer to resolving the technical-human interface issue is to embed ESME into Thingamy. See the screenshot below:
Is it as elegant as it might be? Perhaps not but that doesn't take away from it's ability to sit inside the process engine UI while delivering immediate value back to the user. Sig's take on what he's doing can be found here.
It seems to me that even if you cannot easily retrofit ERPs with social computing tools, there is a solid case for having BRP solving technology that includes social computing tools. ESME's integration to Thingamy might just be a first iteration but I can readily see how you might discover, access and attach say wiki content and rich media. That then expands the pool of knowledge from which we can draw, yielding more potential value. Taking this approach means blogs/wiki/Twitteresque style apps suddenly become features for integration and not the focus for IT budgets. That's a problem for the SocialText, Atlassian and Yammers of this world because in my scenario they go away as discrete applications. I'm not alone in my thinking. David Terrar (disclosure: His company Wordframe sponsors my personal weblog) takes a similar position though he prefers a more exotic, platform play than I am currently envisaging.
Am I describing a Utopian view pf the world? I am constantly amazed at how often I can ask a seemingly innocuous question only to be told it can't be done. My natural inclination is ask: 'why?' If we've spent trillions of dollars creating rigid processes to safely handle business value creation then why shouldn't it be moderately simple to fix, amend, whatever? And why shouldn't the human element have a constructive part to play inside those processes? That's a big question at many levels. If the answer to the first part means unraveling what we have then I'm not going to be leading a very large fan club either in IT or the business. If I can get closer to finding a better way of stepping around the problems then I might fare better. If that allows me to effectively carve out inefficiency, I'll have a rave club on my hands. But life isn't that simple or for that matter so black and white.
Michael Bechauf of SAP and I have had a robust email conversation around this. His view via email: "...no matter how smart people like Sig are, their claim that they have found the holy grail of being able to optimize processes without the rigid nature required for efficient processes and software systems, is just too good to be true. It’s a nice vision, but would you really allow the country be run by unpredictable processes like Twitter?" I'm not sure Sig would claim 'holy grail' status but his position is one that makes a lot of sense in the context of solving business problems while embracing the social aspects that accompany them. There is a middle ground here. Social media people will likely raise their hands in horror at Michael's perspective. Whether you agree or not is irrelevant. Michael is simply stating the bleeding obvious from the vantage point of someone living inside an organization that builds rigid processes and upon which many thousands of businesses large and small rely. The fact many of those processes are flawed is well understood. Solving the problems is immensely challenging. Embedding the social tools inside BRP engines may be Michael's and our escape route to removing the 'social' connotations which rankle people like me while benefiting from their efficacy. No social business design required and E2.0 becomes less of a crock.
In closing on this 2 parter, I'd like to reference a valuable talking point made by BabbleWare Inc:
...the current #e20 crowd does realize they are selling to business, right?
My instant reaction is - yeah - and that's a part of the problem. For as along as I can remember. E2.0 mavens have shunned the IT community on the grounds E2.0 is a business issue solved with tools that have the ease of use offered by consumer grade apps. That brings with it all sorts of governance issues E2.0 players can sidestep. However, in the process led scenarios I am describing, there is a definite place for inclusion of IT. One of the reasons the ESME team developed with SAP NetWeaver in mind was because we could leverage the SAP security model. That meant from a dev perspective, we were unlikely to fall foul of governance.
Disclosure: I was part of the original ESME team and developed the original outline use case marketing material. I have no commercial arrangement with SAP or anyone connected to the ESME team. Sig is an Enterprise Irregular whose radical views I admire though I may not always agree.
UPDATE: A couple of Twitter followers have made the point that the way this is presented looks like a binary (either/or people v process) position. That's a reasonable interpretation based on the title but perhaps less so once the content is examined. What I am trying to emphasize is the central role of process.