Process, Work Practices & Social Software

Ross Mayfield ignited a debate with a bold statement

If a knowledge worker has the organization's information in a social context at their finger tips, and the organization is sufficiently connected to tap experts and form groups instantly to resolve exceptions -- is there a role for business process as we know it?

Ross goes on in this post to attack process as something bad, the root of all corporate inflexibility. His post also enlists Clay Shirky who states:

"Process is an embedded reaction to prior stupidity."

Now, technically, Clay is correct -- process is a structure that an organization views as the "right" way a set of inter-connected business activities should be executed. For an enterprise to view it as being the proper way to work, there must have been a wrong way before it. But Clay also admits that he over-stated the case (perhaps being melodramatic to make a point).

Process is full of good and bad. If not defined correctly it can cement in bad methods of doing work. If not managed in a life-cycle manner, it can become out-dated and circumvented by workers trying to innovate and rise above burdensome and bureaucratic rules.

But Ross seemingly believes that social software makes process unnecessary. Or at least he asks a rhetorical question and based on the rest of his post, he appears to believe that to be the case.

I disagree and believe the topic would have been better served by framing it as a process vs. work practice debate.

Process is clearly important. Companies need process to ensure compliance with certain regulatory statutes, to achieve a high confidence level in the quality of their production lines and to establish metrics from which they can gauge organizational productivity and performance. There are likely a host of reasons why process will remain important and not something organizations should simply abandon.

To that point, I an reminded of a presentation a in 2004 given by John Seely Brown who talked about process as establishing the structure around work (tangible) and practices as establishing the structures within work (intangible). He went on to talk about the natural tension between the two forces but in the end business process and work practices are both important, but in different ways.

I would take Ross' point about process and instead talk about the need for strategists and decision makers to focus also on work practices and how social software can not only improve those work practices but can create feedback loops that enable process to be managed and made more adaptive over time. That does not mean that social software is a silver bullet.

Let's examine process and elasticity. In economics, elasticity examines variables and their proportional change relative to each other. A process is comprised of many variables. Organizations apply structure (process) to fix some variables (sometimes arbitrarily) and allow pre-determined variance in others as the optimum way to get work done.

I would imagine that some process structures are very inelastic. They are rigid for a reason (e.g., manufacturing of a drug, SOX compliance, ISO 9000 requirements). Within these structures, work practices might have very little room for local interpretation and variance in terms of how work is conducted (free-form changing of various work variables). On the other hand, there are some processes whose work practices can be more elastic. The way in which a company process handles an RFP request might allow for more localization and flexibility of work practices as people reach out into a community of experts or other experienced in topics covered in the response to the RFP.

In other words, the greater the elasticity of the process, the greater the variability in work practices and the greater the value social software can deliver to make that process perform more efficiently and effectively (the assumption being that with more variables "in play", social software can provide greater collective intelligence in navigating through multi-faceted, cause-effect decisions).

I might not have my economics metaphor perfect but the point is that understanding the inter-relationships between process, process elasticity (variables, cause-effect influences) and work practice variability can establish a business case for use of social software. Process benefits by use of social software rather than social software as a replacement for process.

Comments

[Neil Macehiter]

What you are highlighting here, IMHO, is the fact that business processes vary a great deal. In some cases, business processes are highly structured, with significant amounts of automated support for roles within those processes and extensive control of the interactions and collaborations between roles e.g. straight-through-processing or call centres. In others, the processes are largely ad-hoc, with limited automated support for individual roles and limited, if any, control of interactions e.g. strategy-setting processes in most organisations. The problem is that when we in IT talk about business processes, we tend to focus on the former.

Rather than imposing an artificial distinction between business processes and practices, which I think many enterprises will struggle with, I think it is far better to focus on business processes, recognising these differences.

[Neil Macehiter]

Mike,

I am attempting to send you a trackback on this post but am struggling:

Pinging http://www.typepad.com/t/trackback/3870814...

Problem: Server said 'In an effort to combat malicious comment posting by scripts, I've enabled a feature that requires a weblog commenter to wait a short amount of time before being able to post again. Please try to post your comment again in a short while. Thanks for your patience.'

[Mike Gotta]

Thanks Neil. I'll have to submit a ticket to the Typepad folks. I'm not sure what the problem is related to in regards to setting the trackback.

Regarding Process vs. Practice, we could be in violent agreement or just slightly off -- someone once said "process doesn't get work done, people do" -- and that's my point. People interpret and apply process and it's important that we understand why groups of people work differently within the same structure. Sometimes it is due to culture, sometimes it is due to how a team is adjusting "work" across multiple in-flight processes that they are involved in. That's how we uncover best practices actually -- one group performs a process far better than other groups working with the same process -- why? We look at how that group has localized and socialized work practices and then try to generalize that into a best practice that can be applied elsewhere. Without understanding work practice, we tend to live in an ivory tower of process.