It’s been a long time since I started out on the Four Pillars journey, sometime in the middle of 2003 I guess. At the time, I suggested that enterprise applications would converge to become one of four “pillars”: Publishing, Search, Fulfilment and Conversation.
Most people got the Search pillar, where all I was stressing was that we would move from deterministic models of looking at information through to probabilistic ones, particularly as we realised the lack of accuracy of the information we were getting via the traditional forms-based or tree-structure approaches. I guess most people “got it” because search had been around for a long time, and everyone was familiar with the concepts.
While this was not the case in the middle of 2003, most people have now “got” two of the other pillars, Publishing and Conversation. RSS readers are common now, people understand the syndication of content; blogs, wikis and IM, the constituents of conversation applications (beyond the traditional e-mail) are also common, even if usage patterns show an inverse relationship with age.
What many people didn’t get was the pillar I tried to describe as Fulfilment. The process by which a customer gets what he wants. Buying a book, booking a train ticket, selling the contents of your garage, eating out, watching a film, whatever.
Fulfilment. A state of feeling that you got what you wanted, where you wanted it, when you wanted it and how you wanted it. A state of satisfaction.
I’ve written a number of posts on why customer experience is the only remaining differentiator in a commoditising world, particularly when guest blogging for Shane Richmond at the Telegraph last November: on the economics of the customer, on customers and differentiation, on customers and predictability.
One of the reasons I chose to work where I work is that everyone here is focused on this issue, on improving the customer experience. And with all this as backdrop, you can understand why I want to figure out ways of improving processes that serve the customer. Giving the customer what he wants, precisely what he wants, as quickly as he wants it.
This is not going to happen unless we get our processes defined right, refined right. So we spend a lot of time trying to work out what that means, making sure we are documenting the processes correctly, that they really do reflect the customer experience. Making sure that we understand where we’re losing time or accuracy. Making sure we understand what we’re going to do to gain back the time and the accuracy.
Which is where the opensourcing of processes comes in. Why Michael Hugos’ post on visibility resonated with me so much, and why I wrote my earlier post on the subject.
Many many years ago, probably in the mid-1980s, I remember reading an article called Don’t Allocate, Isolate. Probably in the Harvard Business Review or the Sloan Management Review. While looking at aspects of cost analysis, the authors were suggesting that enterprises spent too long arguing about who paid and how much, rather than really understanding what was spent and on what.
I feel similarly about processes. We should document rather than analyse or critique them. Just document the reality. There’s nothing magical or differentiating about processes per se, it’s how we execute them that matters. Which means that standardisation of processes should not be that difficult. Unless we want to make it difficult.
Maybe we do the same thing with the time and accuracy aspects of processes. Maybe we should avoid getting into the angels-dancing-on-pinheads syndrome. No finger-pointing, no blame cultures while we do something very simple. Measure how long it takes for the customer to get what he wants. Measure how often we get his want right.
These things need to be incontrovertible truths, not for debate. Truths that cannot be varied by the diktats of the Word-Excel-PowerPoint troika.
Expose the process, as if it were code. Expose the completion times and error rates, as if it were code. Let everyone see them. Even the customer. Particularly the customer. Why don’t we learn from the Fedex model?
Michael Hugos’ Universal Product Codes are elements that can be expressed adequately in the tag-meets-microformat spaces; when we do this, we have the DNA we need to track processes across systems silos as well as departmental silos.
When we expose the simple things, we may start seeing some of the magic of democratised innovation:
The Linus’s Law effect, as transparency attracts eyeballs; the peer ratings effect, as people compete for peer recognition by improving things faster and better; the collaborative filtering effect, as people learn from a people-who-did-this-also-did approach; the Because Effect, as customers flock and stay because of the experience and not with shackles and restraints.
There is so much we can discover as we do this. I’d like to believe that one man’s department is another man’s firm, that processes by themselves aren’t different in different firms, that we just like believing they are.
An aside. First we believe that our processes are different. Then we believe that our processes are differentiating (in order to keep the Emperor Clothed). And we keep on believing it, even though we also believe in open architectures and platform independence and the power of standardisation and Moore’s Law and Metcalfe’s Law and Gilder’s Lemma and the War for Talent and and and.
You know what? Sometimes I think we make enterprise processes behave like vendor-lock bloatware. We work to ensure that any and all efficiency gains are absorbed by Topsy-related process growth.
We must find a way to apply opensource principles to core processes.
Like this:
Like Loading...