One of the familiar refrains in the halls of Enterprise 2.0 is that social software’s primary value is for knowledge workers or knowledge-intensive industries. This now gets repeated so often that most people don’t even question its truth.
Like so many orthodoxies, this one’s due for a re-think.
The whole notion of a knowledge worker or a knowledge industry is confused. It suggests that there’s a certain class of workers who problem-solve and innovate for a living, and another class of workers that don’t. But that’s just not the case. An assembly-line worker who thinks about how to reduce the failure rate of brake systems rolling off the assembly line is a knowledge worker, at least in my book. A consultant who reads bullet points from a deck that someone else has written is not exactly doing knowledge work. Knowledge is a characteristic of how the work gets done, not of the work itself.
If you don’t believe me, just compare the cappuccino you get at a world-class cafe like Lovers and Madmen in Philadelphia to what they sling down the street at McDonald’s. Both were made by baristas, but only one was made by a knowledge worker.
There is, however, a fundamental difference between activities that are more routinized and those which are more bespoke. Doing warehouse pick-and-pack for the latest James Patterson thriller is a routinized activity. Sourcing a clean copy of Russell and Whitehead’s 3-volume Principia Mathematica is bespoke. Soliciting $10 donations over the phone is routinized; soliciting $5 million donations is bespoke. Building the prototype of a new car model is bespoke; building the 100,000th instance of that same car is routinized.
Routinized and bespoke activities require different types of supporting tools. Routinized activities require process tools to run the activity at scale as efficiently as possible, with as little variation as possible. Bespoke activities require a toolkit, a basket of techniques, tools, tips, tricks, and experts upon which a practitioner can draw to meet the needs of the moment.
In the early days of Enterprise 2.0 (mid-2000s) enterprise social software was good at toolkit-style functionality. Blogs and wikis gave people useful frameworks and reference materials for doing bespoke tasks. But there wasn’t much functionality for businesses that run a lot of routinized process.
These early tools appealed to high-end consultancies, law firms, PR agencies, and tech startups, which lean towards more bespoke activities. I suspect that’s where people first got the idea that enterprise social software was for “knowledge workers.”
But social software has changed, and changed fast. In the past year, business has started to embrace social software for more routinized processes as well.
The combination of activity streams, robust APIs, and mobile means that social software now integrates with–and improves–industrial-strength process. In London, for example, Southeastern Railway is using social software to automatically alert railway staff when trains are delayed–and to enable those staff to collaborate in real time to get the trains back on track (sorry…couldn’t resist the pun). In Ohio, Industrial Perfection Mold and Machine uses social software on shop floor iPads to regulate and improve the manufacturing process.
Which type of activity should your business try to optimize? My answer: Both.
Every business runs on a combination of routinized and bespoke activities. Running the trains in and out of London may routinized, but when a train breaks down the work becomes very bespoke. Tier 1 customer support is routinized; Tier 2-3 customer support is bespoke.
What businesses really need is an integrated combination of the two: Stream-based tools for routinized activity and wiki-based toolkits for the bespoke stuff.
To borrow a line from the Anita Bryant of my youth: “Social software. It’s not just for knowledge workers anymore.”