Social Process Reengineering?

As much as I hesitate to introduce this term into social software lingo, I think it's exactly what Enterprises are doing with social software on the road to Enterprise 2.0 - striving for a fundamentally new way to work.

The title of this entry had three goals. First, I wanted to convey and play off the stark differences between Social Process Reengineering and Business Process Reengineering. Second, I wanted to leverage the similarities of SPR and BPR to explain that these two processes can, and need, to co-exist rather than compete. Finally, I wanted to ask the question about whether this is the right term of the process. After dozens of conversations with the best minds in E2.0 this week, I've reconciled to a a more targeted and appropriate term: Emergineering!. When the emergineer shows up at your door-step, you welcome him or her as someone who can help support a people-centric process which has an underlying structure and requires various types of leadership, but has an unknown outcome. After you read the rest of this entry on Social Process Reeingineering, please continue on with Emergineering!. June 18, 2010 | # | Jordan Frank The title of this entry had three goals. First, I wanted to convey and play ... June 18, 2010 | # | Jordan Frank

Considering various definitions of Business Process Reengineering (BPR), you can start to see what's in common:

"... the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed." Hammer and Champy (1993)

In reference to BPR, Davenport (1993) says that "Today firms must seek not fractional, but multiplicative levels of improvement – 10x rather than 10%."

We are in the same situation today - but trying to achieve those 10x gains with social systems rather than rigid business workflow systems. 10x, while lofty, has to be the goal to overcome the 9x Email problem discussed by Andrew McAfee (in reference to J. T. Gourville's "Why Consumers Don't Buy: The Psychology of New Product Adoption") and explored further by Greg Lloyd in Enterprise 2.0 - Letting Hypertext out of its Box.

Across whatever set of metrics, Social Software has to give adopters the perception that it's 10x better than the alternative.

Andrew McAfee recently posted an entry which ponders What's the Simplest Thing That Could Possibly Work? McAfee quotes an E2.0 Evangelist from a big tech company who complained:

"Progress is slower than I’d like. I don’t know why more people aren’t doing more. I think part of it is that we have a huge Intranet, and these tools can be hard to find. I think a lot of our people aren’t even sure they exist.”

McAfee's proposed simple solution is to put a box in every intranet page that urges users to Search, Ask or Share - each with a simple text box for input. In the discussion, McAfee references his own rule to deploy "Tools that deliver something novel - that aren't trying to displace an incumbent - avoid the 9x effect."

I am all for the idea of thinking in simple terms, but the suggestion diverges from answering the challenge to deliver a 10x improvement. The suggestion left me wondering "10x over what?" The Search, Ask, Share idea is on target but an action so simple and attractive as Share is dead on arrival if even a few key stakeholders are 9xd in email.

I am on board with avoiding other incumbent tools (except email which is an open wound advertising the pain resulting from broken processes), but it's vital to realize that any time you move communication to an E2.0 system you are displacing a social process (however it manifests - at the water cooler, in meetings, in email) with a social technology process.

Taking a social process reengineering approach, I take a Druckerian vision which agrees with Greg Lloyd's stance in Enterprise 2.0 Schism:

I believe that although both technology and broad bottom-up participation are necessary to achieve the Drukerian vision, neither element alone is sufficient to achieve the noble end of re-engineering how ordinary people work together to achieve the ends of enterprises they choose to affiliate with.

Its the mix of social and technology that come together to enable, in Drucker's words, "ordinary people to do extraordinary things." But not every technology works and not every social group can simply pick up a tool and run.

If McAfee's E2.0 Evangelist from the tech company is so puzzled about why participation in his E2.0 pilot is not succeeding, he should start considering whether people, teams and departments know their Whats, Hows and Whys:

• What process does the system support for my group, team, department, enterprise? What business pain does it alleviate?
• How, mechanically speaking, do people operate the technology defined in What to achieve the result?
• Why does the How create a perception of 10x ROI - Return On Information

For the last 8 years I've worked on social software with companies and organizations in every pocket of industry, multiple governments in the US and abroad, and non-profits. One of my favorite adoption stories runs counter to what many E2.0 evangelists would ever expect. The deployment was led by Peggy Walker, a grandmother of many at a very conservative, very large, very old mid-western firm. The initial group of adopters were age 40 to 60 - a far cry from the typical Facebook and MySpace generation which some would perceive as a pre-req for E2.0 adoption.

What made this adoption story work, in days and weeks not years, was Peggy's six-sigma green belt which helped her focus one eye on process and one eye on leadership. She was a master of what Paula Thornton recently coined as B2.0: Orchestrated Improvisation. Peggy understood the piece parts of what her orchestra members do in their daily work life, understood the process context in which they worked, and, like a good conductor, was able to lead them, like any good conductor, to play together to the symphonic challenge of the day - which was sure to be ever changing but followed certain patterns and basic structures. Whether the technology was new-fangled or old didn't matter - the key was her ability to figure out What, How and Why. Then she could explain the new process (loosely described as a set of interleaved intelligence communities) and how people could use the technology to do their jobs better.

Social Process Reengineering is a far cry from Business Process Reengineering which may require fleets of consultants and man-years of programmers to arrive at rigid processes that improve the flow of goods through a supply chain.

Instead, SPR requires that we understand our social processes, find the underlying pain points, understand social artifacts, and figure out how to structure for emergence. Finally, the role of leader is not Evangelist, it's Conductor. The individuals who lead the deployment, who work with teams to pile-on use case after use case, need to coordinate their orchestra of workers to outcomes which are inevitably new and always extraordinary.

Converse to man-month BPR planning efforts, SPR can happen in minutes over morning coffee or in a Stewart Mader style afternoon Barn Raising. By way of example, I've talked to a dozen customers about replacing Excel based processes with a New Way to Work and many made the switch immediately.

In fact SPR's flexible and emergent outcomes offers the perfect balance needed by BPR which seeks rigid rules driven outcomes based on process optimization. BPR aims to produce workflow systems for predictable business problems whereas SPR, using social software as the supporting technology, is the agent that lets us plan for change, face competitive threats and leap onto market opportunities. While SPR and BPR seem like opposing concepts, one may just be the Yin to the other's Yang.

One of our customer stories takes me right to this point. At KUKA Systems, an IT team seeded their social software deployment by deploying a set of spaces where anyone at the firm could post issues pertaining to their enterprise systems. They took a social approach to discussing, tracking and executing on changes to these business critical process systems. This is a perfect example of a social process that, to McAfee's point, is one of the simplest things you can do and, meanwhile, has a meaningful and tangible 10x impact on the way issues are handled as well as on the productivity and performance of business systems. Maybe I've just reached the bigger picture point to which John Tropea was referring when he referred to the KUKA Systems customer story as the "Seminal enterprise 2.0 task-based/process soln."