Enterprise 2.0: it's not about people it's about process. Part 2

Enterprise 2.0: it's not about people it's about process. Part 2

Summary: Social ProcessesView more presentations from Mark Masterson.In the last post I made the case for including E2.


In the last post I made the case for including E2.0 tools in existing ERP scenarios. But that only deals with a fraction of the problems we face. In order to get some sort of handle on the scale of the problem, I read a PEP report (PDF download) from 2008. (If anyone has a more up to date version then please reference.) When you look at the amounts of time they are measuring as non-value creating, you'd be hard pressed to wonder how anything useful gets done in the workplace. Back of cigarette packet calculations conducted by Sig Rinde based on PEP's assessment imply (per email to me): "Assuming 60% of all work is unstructured/BRP and 65% of that again is to keep the flows flowing - then giving those flows a proper framework about 40% of all work could be freed and applied to value creation instead. That would amount to a 67% increase in value creation without increasing resource or time spend."

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.

Topics: CXO, Collaboration, SAP, Social Enterprise

Dennis Howlett

About Dennis Howlett

Dennis Howlett is a 40 year veteran in enterprise IT, working with companies large and small across many industries. He endeavors to inform buyers in a no-nonsense manner and spares no vendor that comes under his microscope.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Human documentation has drawbacks

    What I'm taking from this: no one documents stuff. You have to find the person who created it to explain it to you. With Web 2.0 tools you can do that. "Hates: people, and variable names in mixed case. Loves: indenting."

    Unless they are off sick or they quit...
    Robert Carnegie 2009
  • RE: Enterprise 2.0: it's not about people it's about process. Part 2

    Fantastic two part article:
    Do you think that "Service Oriented Social Tools" is what
    we are heading towards? Not just to inject the technical
    capabilities of E2.0 in the business processes where they
    break and human knowledge is required, but also to
    innovate many business processes altogether?
    Andrew Gilboy
  • Isn't that a reductive model?

    I now better understand your point ;) But isn't that a reductive model, specially if you consider organizations from a dynamic capabilities model view where routines are merely related to people (ie micro-foundations for instance) independent from processes, and where fast reconfiguration to react according to the ecosystem is crucial?

    Trapping knowledge sharing into processes will only give birth to another sort of silos... Thanks anyway for shifting and shaking the debate in such a great way.
    • Massive

      This is a huge topic. What I've tried to do is set a marker against which others might choose to riff, expand etc. I'm sure as heck not proposing a 1-size fits all approach.

      I am assuming that what we're attempting to do is move towards end to end process capability anyway but of course plenty of businesses are nowhere near getting this right.
  • RE: Enterprise 2.0: it's not about people it's about process. Part 2

    Robert, your presentation logic seems to refute your assertion. It's both/and. E 2.0 seems to be about both people and process and probably more importantly practice, practice, practice.

    It is so tempting to offer a silver bullet, but dyanmic systems by their nature offer more opportunities for design and practice than anything else.
  • Eurkea! Diagnosis v. Medicine - Where's my glow stick?


    Now I see what the current E2.0 crowd has been talking about: knowledge gathering for process improvement. The current E2.0 dialogue seems to have very positive ideas (Masterson's presentation deck is tremendous) about how the need for change, the opportunity, can be "crowd sourced". The current view is to let the employees, vendors and customers diagnose a problem and identify a solution. But that doesn't solve the problem - it doesn't do enough to address how to "effectively carve out inefficiency" so that your Rave can open. For your club to open there must be some implicit rules.

    Babbleware's position on E2.0 is that it must:

    1) Do no harm - in other words it cannot disrupt or interfere with the existing Enterprise 1.0 solutions already in place (think ERP, Best of Breed or Homegrown). By following this rule E2.0 solutions are able to address E1.0 process shortcomings in a "moderately simple to fix, amend, whatever..." way so that your fan club can be larger.

    2) Increase revenue and/or profit in measurable terms before roll out investment is required. Allowing you to "get closer to finding a better way of stepping around the problems..." with proven solutions to known problems. Your club just got bigger.

    The Rave Club that you hope to develop, and I can just envision the decor of that club, is entirely possible. There really is a silver bullet. The "..rigid processes and upon which many thousands of businesses large and small rely" offer a connection point. Without integration (Rule 1) and with proven value (Rule 2) E2.0 solutions like ours become the medicine. We "effectively carve out inefficiency" based upon subject matter experts diagnosis, measure its impact before roll-out investment and provide the key to the club.

    Each of the existing processes are as unique as the existing system, version, language, etc. in place. Fortunately, though, these processes all interface with employees, vendors and customers as structured data (displayed on screen - think terminal emulation/telnet, in formatted files - think xml or even xls, or even on paper) with sophisticated input requirements and associated algorithms to feed the rigid processes in place. Enteprise Add-On (EAO) applications connect to these interfaces without any change to the existing system. In fact the existing system is blissfully unaware such a connection even exists.

    EAO then extends the original process to a the "custom" desired process that can include new data and technology. Now business can carve out the inefficiency and "outdated" processes that hamper their operation. They can meet new market requirements, regulation changes, create competitive opportunities and begin collaborating across disparate systems found in the vendor - employee- customer ecosystem.

    Now where did I put my glow sticks?
  • The first wedge is to bring process to the unstructured

    Right on, Dennis. The trick is, can we trust the people who serve the current processes to build the requisite people-awareness into their products?

    That's the Catch-22. Separate collaboration products don't work, because they are too separate from the process. But the vendors that support the process have demonstrated a remarkable inability to support collaboration as well.

    My best guess is that we need to seek out small wins...certain processes where it's easier to add in people-awareness, or certain problem areas where no current process exists, and where process can be built into collaboration tools.

    With PBworks, a lot of the benefit we bring lies in bringing process to the completely unstructured, rather than in replacing something that is already structured.
  • I wonder...

    I come from a completely different environment,
    where ridiculously small budgetary, time and
    resource constraints force us to innovate
    constantly. I have seen how carefully designing
    a few key processes while leaving the rest up
    to educated, intelligent agents tends to give
    the best results. Given proper motivation and
    guidance, people will amaze you with their
    resourcefulness. They will find ways to solve
    problems that no architect or business analyst
    could ever envision, reusing the tools at their
    disposal and creating new sources of
    information, processes etc. The question is how
    to empower the employees without totally losing

    Well, you need to closely monitor the things
    they do, how efficiently and correctly they do
    them and determine if there's something you can
    do to help them do it more efficiently. That's
    the missing step in all the projects I've
    worked in. Managers rarely know how exactly
    things are done, or how IT could help them do
    it better. But if you get a technical person to
    sit next to a call center agent the problems
    and the answers become immediately apparent.

    Email, unstructured task assignment, document
    libraries and ad-hoc questions to more
    experienced agents are some of the tools you'll
    see them use. Blogs, twits and whatever else
    may be useful will gladly be used as well, as
    long as it helps them do their job. No one
    needs to tell them to do it. If they know it
    exists and are given time to learn how to use
    it, they'll find ways to use it. But it is OUR
    job to see what they do and determine if a
    particular activity is worth

    I totally disagree that complex, predictable
    processes provide the solution. Just try
    dealing with Oracle's technical support and
    you'll realize that even the best processes can
    not replace a knowledgeable agent, empowered
    with the proper tools. In my experience, the
    cost of a 'perfect' process far outweighs the
  • RE: Enterprise 2.0: it's not about people it's about process. Part 2

    thank you for the detailed information

    If you want to find more information on ERP software reviews, go to www.erp.com. You will get alot of tools and reviews to find the best software application for your business
  • RE: Enterprise 2.0: it's not about people it's about process. Part 2

    thank you for the information, it takes time to understand the concept in depth to implement it

    For more information log on to www.erp.com

    If you want to find more information on ERP software reviews, go to www.erp.com. You will get alot of tools and reviews to find the best software application for your business