Hopefully this topic will be controversial enough!
UPDATE: the presentation went over quite well... and I've posted it online if you want to take a peek.
I've heard a lot of buzz about Enterprise 2.0 lately... and lots of Enterprise Content Management folks (including Newton, Pie, and Billy) still seem to be frustrated by the general lack of a coherent definition of what exactly is Enterprise 2.0? Frankly, I think the very act of defining Enterprise 2.0 defeats the whole purpose, but I appreciate that some people need guidance...
The world is filled with "thought leaders" trying to railroad people into a narrow definition that is properly aligned with their own technology and ego... Some say E 2.0 is just Web 2.0 for the enterprise. Some say its emerging enterprise architectures (SOA, ESB, CEP, IdM) that make services easier to govern and re-use. Others -- like the lame-os at Wikipedia -- say its nothing more than enterprise social software. Others say its just the Knowledge Management Beast rearing its ugly head yet again...
triple ish on that last one...
In my upcoming book, I spend a chapter on how Enterprise Content Management fits in with Enterprise 2.0... and after swimming in blogs for the past year I think I have synthesized an approximate definition that might make everybody happy:
Enterprise 2.0 is an emerging social and technical movement towards helping your business practices evolve. At its heart, its goals are to empower the right kind of change by connecting decision makers to information, to services and to people.
Swish! Leave a comment and tell me what you think... Hot or not?
Its vital to understand that E 2.0 is still a moving target... we know that the enterprise is changing radically, but we don't have enough hard data to say what its changing into. However, I feel its just the latest leap in the neverending goal to make information and services more re-usable.
As an added twist, E 2.0 also has at its core the goal of connecting people with each other in order to discover the tremendous value that exists outside "the process." If the purpose of process is efficiency, then why do so many people in enterprises complain that their process is horribly inefficient? It might be because your process just plain sucks, or it might be because the process is keeping you from changing something that has drastic side-effects outside your view of the company. The point is not to mock or destroy "the process," but to help processes evolve at the optimal rate. This is not possible unless all decision makers can see first-hand how their changes negatively affect other departments. This cannot be done with metrics alone: you need friendly hallway conversations between people who normally would hate each other.
Unfortunately, after coming up with that definition I was staring point blank at something a little unsettling... If people focus on the wrong things, Enterprise 2.0 will FAIL HORRIBLY the same way Knowledge Management FAILED HORRIBLY! For those who forget, Knowledge Management was some snake oil sold 20 years ago saying that access to information was the #1 problem... its not. The problem is access to the right information at the right time in the right format. My industry -- Enterprise Content Management -- emerged from the ashes of Knowledge Management, trying to implement the few good ideas that it offered.
So... how did Knowledge Management fail? What implications does this have for the failure of Enterprise 2.0? I'm no psychic, but I anticipate that people might make similar mistakes... it all boils down to one problem: you're probably focussing on the wrong thing! How could you fail? Here's five ways:
1) By Focusing on Information, Instead of Knowledge
Firstly, remember that the goal is not access to information... the goal is getting the right information in the right format to the right people at the right time! Its not about overwhelming people with data, its about trying to come up with relevance filters that help people quickly find what's important. You can achieve this goal with Enterprise Content Management, but you could limp along with manual processes and shared file systems (like Sharepoint ;-)).
People forget that in the past, those information brokers who "hoarded" data were doing you a favor. They kept you from seeing garbage that you frankly didn't need to know to do your job. Eliminating this broker simply created information overload. Instead, you should train and empower this broker to help people find the information they "need to know," even if they need to know everything.
2) By Focusing on Services, Instead of Applications
Secondly, remember that the goal is not access to services... the goal is safe, secure, and auditable access to re-usable enterprise scalable resources! This is not just Service-Oriented Architectures, its also about creating a culture dedicated to re-using existing services, helping services adapt to new requirements, and ensuring those services are safe. You can achieve this goal with a Service-Oriented Architecture, Identity Management, and some decent governance... although you could limp along with some manual processes and a Resource-Oriented Architecture (like ReST), or a hodge-podge of enterprise mashups.
Unfortunately, if you focus on just the services, you lose sight of why you cared about making services in the first place: so you can create bigger, better, and faster applications. Some architects say that the term "application" should be banned and everything should be services... I'm unconvinced. Unless you stay grounded in the reality of why you care about services, odds are you won't be making good services.
3) By Focusing on People, Instead of Social Capital
Thirdly, remember that the goal is not access to people... the goal is to build social capital so your business processes can evolve more smoothly! This means empowering employees to connect, especially if they would never hang out socially. Its not about getting connected to people with similar interests... its about finding and closing the structural holes in your enterprise that act as social bottlenecks to innovation. You could do this with enterprise quality Facebooks apps, or you could simply help employees buddy-up with some kind of speed dating between two departments that normally hate each other.
Its not how many people you know... its how many kinds of people you know. If development, sales, support, manufacturing, and the board of directors don't chit chat, they never see how their decisions affect others. They never hear about new developments, unless "the process" allows metrics to be taken and shared. But the process can't help you here: you need something more informal.
You may also need a facilitator to help with language/culture barriers, or gateways to help filter out the garbage "friend requests" from flatterers and toadies. Some people just call this "good management." I agree, but I also think its important to remember that software can make a good manager great, but it can't make a bad manager good.
4) By Focusing on Change, Instead of Evolution
Fourthly, remember that the goal is not change... the goal is process evolution! Change is easy, but evolution means change that will survive and thrive. You need to change into what is next, but you cannot destroy what you are. That will only lead to catastrophe.
Change helps you survive tomorrow, tradition helps you survive today. You need to be able to change quickly when needed, but slowly when it's too disruptive. Its about incremental change that can vary with speed... its not about one giant monolithic system that takes 5 years to install... nor is it about managed chaos where everyone does whatever they want as long as they blog about it.
Case in point, imagine an online voting system to mine for good ideas about product direction. Be warned that the crowd doesn't always know best... these voters are likely to be your youngest workers, and therefore those with the least experience. Either that, or they're the laziest workers who spend all their time trying to be "the idea guy," with no clue about how tough something is to implement.
5) By Focusing on Success, Instead of Failure
Lastly, remember that the goal is not success... the goal is to fail faster than the competition! There is no such thing as a failed experiment: there are only experiments where you fail to learn. The only way to survive is to learn faster than the competition, and to take risks. Too often "success" is defined as that which makes the boss happy... it should instead be defined as that which allows people to determine risk, and take the right ones.
Assume somebody analyzed the risks properly, communicated those risks efficiently, took the risk, failed, then communicated what he learned. Further assume that this is NOT inside a dysfunctional company. Can anybody give me one good reason why that person shouldn't be rewarded?
Continued in 2 weeks...