Infovark

It’s time to wrap up our long-running series about moving information. We’ve managed to take the sting out of Locating and Versioning documents within your enterprise through clever application of web tools. This is the final part of the series, where we talk about how to fix the tracking problem.

Our basic premise is that the most obvious place to find something is where you left it. Since you created the item on your PC, that’s where it should live. Your coworkers know you drafted the document, created the slideshow, or assembled the spreadsheet, so they’ll expect to find it somewhere on your PC, too. It matches the paradigm we use every day in the physical world.

Jimmy the photographer was working on the layout for page three. Lois wanted to have a look at it, so she dropped by his desk. What about the front page? Clark was working on the cover story. Oh, there it is, still in Kent’s typewriter. Where’s that Clark gone now? He’s never around when you need him…

The tracking problem is driven by three needs. The first need is to locate the current version of an item. We’ve largely mitigated that problem by applying version control to the information at the point where it was created and giving the information a unique address on your organization’s network so that your coworkers can find it.

Since you generally know what sorts of things your coworkers do, you’ve got a pretty good idea of what business information they’ll have on their machines. For cases where you might not know the right person, you can navigate links in the social network to find the right stuff. And in the worst case scenario, you can always run an off-the-shelf search engine over all of the documents. Since we’ve done the hard work of making them addressable and versionable, creating a full text index of their contents is no problem.

The second tracking need is to monitor the status of a work in progress. Based on what we’ve seen during our time as management and technology consultants, this is the item that generates the most email traffic in a typical enterprise. This is the reason why most knowledge workers spend a significant chunk of their time asking for or filling out status reports. I like to call it “Management by Magic 8-Ball“.

Manager: “Is it done yet?”
Employee: “Ask again later.”
Manager: “When will it be done?”
Employee: “Cannot predict now.”
Manager: “Will we meet the deadline?”
Employee: “My sources say no.”
Manager: “Will a week’s extension be enough to finish?”
Employee: “Signs point to yes.”
Manager: “OK. I’ll see what I can do.”

Not the most efficient use of time and resources, is it? The exchange above is another symptom of the way enterprise software works today. Each knowledge worker is a black box as far as most office productivity tools are concerned. According to this school of thought, a manager assigns a task, the employee disappears into a cubicle for a while, and some time later the employee emerges with the task complete. In the abstract, it seems like a decent way to organize things. How the employee gets the job done should be irrelevant, so long as the job gets done, right?

In practice, it’s a disaster. What happens inside that cubicle is vital to the operation of an innovative, collaborative business. Coworkers need to know that information, as do managers. And in today’s fast-paced business world, they need to know in real-time. Hence the endless requests for status updates in email, or the tried-but-true “Management by Walking Around.”

Wouldn’t it be easier for everyone involved if the there were more visibility into what happens inside that cubicle? An architect can see the progress being made on a construction site without having to deluge the foreman with requests for status updates. What we need is a way to publish updates as they happen. Let’s call it workstreaming for now, since I can’t think of a better term.

Knowledge workers interact with their computers to get most things done. In theory, that means the computer should be able to notify managers or coworkers when work product is updated. Rather than reading endless status reports, a manager could subscribe to his employee’s RSS feeds. A coworker can monitor a document of interest on her friend’s computer. Most importantly, these things can be done silently, without interrupting the knowledge worker’s train of thought. They can concentrate more on getting their tasks done and less on responding to requests for information.

But what about…

Then there’s the third tracking need: Auditing. Sometimes it’s important to know how information flowed through an organization. One example is process improvement; You might want to figure out how to improve response time for calls received by your customer support line. Another example is for an audit or an investigation; You might need to prove that sensitive financial data was protected during the sales and order fulfillment process. Most solutions to this problem advocate centralized management schemes, intensive processes, and strict governance. There’s a large market for discovery and compliance tools to address this need, because the problem is complex and expensive.

It’s also — thankfully — rare. Fortunately, only a few industries and government labor under the sort of onerous rules that make compliance tools worthwhile. For the rest of us, it’s overkill. Unfortunately, it’s the compliance-laden parts of knowledge work that have so far driven the development of new tools and technologies. ERM, EDM, ECM, BPM… the mere fact that these tools sell themselves by acronym should be a tip-off that they were designed to appeal to industry analysts and can only be deployed by a small army of specialists.

Yes, auditing and compliance are tough problems. A web-centric approach to enterprise software might have little to offer organizations that have risk management as a key strategic objective, beyond increased transparency. But most businesses would rather boost productivity and improve the bottom line.

The Enterprise 2.0 vibe is about improving collaboration by bringing simple, successful, scalable tools from the Web 2.0 generation of consumer technologies into the workplace. Enterprise 2.0 tools are about making a knowledge worker’s daily tasks easier and more fun. And making things fun and easy spurs creativity, cooperation, and innovation — the only durable sources of competitive advantage.

So how can web technology help address the problem of paper shuffling? To recap the previous post, the three key problems are:

1. Tracking documents.
2. Versioning documents.
3. Locating documents.

Let’s tackle these problems in reverse order. The web has a simple solution for locating documents: the Uniform Resource Identifier, or URI. You might have heard it called the Uniform Resource Locator, or URL. The two concepts are closely related, but the differences aren’t important for this discussion. Unique Ids are nothing new; record numbering or library classification schemes like the Dewey Decimal System have been around for a long time. But the URI standard supported by the W3C is the first such system to be truly global.

It’s more than a classification system, however. It’s an addressing system. In addition to assigning a unique Id, a URI tells you how to access the document. It also tells you where it lives and who owns it.

For instance, the URI http://www.microsoft.com/en/us/default.aspx tells us that a unique document named default.aspx lives at the domain named www.microsoft.com. If we look up the domain name, we’ll find it’s registered to Microsoft Corporation of Redmond, Washington, United States of America. It also tells us that we can interact with the document using Hypertext Transfer Protocol, or HTTP. That’s a lot of information in just a few characters. It’s a simple yet powerful system.

If we want to take advantage of this well understood and widely adopted international standard in the enterprise, we need a way to assign a URI to every block of information that has importance to the business. Many existing enterprise content management tools already do this, Microsoft SharePoint, EMC Documentum, and Oracle Stellent being the big three. But all three of these tools ask employees to do something very odd from a web perspective: They ask that the employee send their local files to a central server in order to get published with an addressable URI.

This is weird. We don’t email our public web pages to Google in order to have them appear in its index. Why do we send corporate documents to a centralized server? “To give it its unique number,” an organization’s records manager might reply. But this is old-school thinking; We’re not talking about a librarian stamping a number on a physical book.

It’s far easier to move a unique number from a central server to a workstation then to transfer an entire spreadsheet from a workstation to a server, only to pass it back again so that the employee can continue working on it. In other words, have the librarian send a sticker with the URI on it to the worker and let the worker slap it on the document. The label’s much easier to ship than a book.

But that approach is old-school thinking, too. We don’t need to move the book or the unique identifier: We’ll let the workstation create its own URI.

On the Internet, when you want a document from Microsoft, you type http://www.microsoft.com into your browser. Why not go to http://mary.mycompany.com when you want to get a document from Mary in Accounting? The same technology that makes the “big I” Internet work can make our “little i” intranets work, too.

All we need is a small program that assigns a URI to an employee’s documents and allows the employee’s workstation to act as its own webserver. Naturally this program needs to be secure, but we have two advantages. The first is that an organization knows its members. Nobody can log into the corporate network without a valid user account. On the public Internet, everyone is anonymous, but on your intranet, you can identify all of your coworkers. Second is that the same corporate firewall that prevents network attacks from the Internet can also prevent leaks coming from your intranet. (You do have a corporate firewall, don’t you?) With a few sensible precautions baked into this mini-webserver, you’ve neatly solved the addressability problem.

The system is remarkably intuitive. If you know Bill was tasked with coming up with the latest marketing presentation, you won’t have to search a vast corporate repository for it; You’ll find it on his machine. When Steve finishes work on his policy memo, he doesn’t have to upload it to headquarters and remember where to file it. He just asks this little program to publish it. Ding! Now it’s got a unique number and it’s available for all to see.

That’s how we’d solve the problem of locating information: It’s easiest to locate information if you never need to move it in the first place.

Sometimes, you just have to close your eyes, trust your gut, and leap.

Gordon, Warren, and I did just that when we quit our day jobs to form infovark. We saw an opportunity to bring Web 2.0 technologies and tools, but more importantly, Web 2.0 culture, into the modern business enterprise. We’ll do that by making tools that knowledge workers love. Tools that will help them get their work done. Tools that will make them more productive.

We’ve targeted enterprises, because they’ve been the holdouts in adopting Web 2.0. Individuals have flocked to these applications, but organizations are slow to change. Some companies are actively resisting the new wave. It’s not all their fault, however. Many enterprise software vendors have themselves been slow to adapt.

But to invert a phrase, a lack of speed kills. Or to put it another way, incrementalism is the slowest way to fail.

The companies that embrace the democratizing influence of Web 2.0 will be able to adapt faster than those that don’t. They will be more responsive. Web 2.0 is about the two-way flow of information: what Tim-Berners Lee called the read/write web. Consumers can provide direct feedback to companies, rather than being passive recipients of advertising. Employees can be active contributors to learning organizations, rather than browsers of stale corporate knowledge bases. The companies that understand this will have a competitive advantage over those that do not. They will evolve, while the organizations or industries that don’t will become extinct.

Extinction doesn’t happen all at once, though, which is the reason for the title of this post. It will happen so slowly that most folks won’t even notice it happening until it’s too late. Business as usual is comfortable. An aversion to risk seems a prudent and responsible approach. But it will ultimately fail, because the competitive environment changes. At time of great technological or social upheaval, it changes rapidly.

Advocates of Enterprise 2.0 tend to be passionate about it, because they can see the upheaval coming. You can sense the messianic tone in John Newton’s recent Manifesto for Social Computing in the Enterprise, or Bex Huff’s take on business evolution. The prophets of Enterprise 2.0 have been preaching for some time: The Cluetrain Manifesto was published almost eight years ago.

We’re passionate about it, too. We want to help knowledge workers and their enterprises succeed. And to succeed, we’ll all have to change.

Jim McGee has a well worth reading post about emergence and its importance in enterprise 2.0. He contends that:

“In some respects, “emergence” is a fancy organizational development word for “messy.” The more our systems must deal with the complexities of the real world, the messier they must be to accommodate that messiness.”

There’s definitely some truth to this. Part of the appeal of these “2.0″ technologies comes from the fact that they are easier to adopt and less rigid. The innate flexibility of tools like del.icio.us and flickr is an important part of their acceptance and appeal. Billy Cripe also weighs in with his idea of where to find the ROI in Enterprise 2.0:

“Don’t be a hammer looking for a nail. Someone “implementing Enterprise 2.0″ is either too high up to understand what problem is being solved by a particular approach or simply wants to impress with the latest buzzwords.“

Both of these points got me thinking about how best to define emergence and Enterprise 2.0. In order to fully understand this notion of emergence within the enterprise, I thought it might be worth taking a look at a few different models of “Enterprise Software” and how this concept of emergence affects their ability to actually improve the way that an organization functions. As an example, let’s take the following enterprise:

Figure 1: An enterprise of people with no necks.

This typical organizational hierarchy consists of various layers of management and knowledge workers performing tasks. Some of those tasks require software that is only used by specialist teams. For example, an ERP accounting system like SAP or Great Plains requires training and subject matter expertise to use effectively. Systems like these are a critical part of the modern enterprise, but they aren’t emergent, nor are they designed to be emergent. There’s not much, if anything, that additional flexibility, or ‘messiness’ can bring to this aspect of an enterprise. (If del.icio.us only allowed me to bookmark my favorite financial transactions, I doubt it would have the same appeal…)

Figure 2: Adoption of an ERP tool within an enterprise.

So we probably aren’t going to see things like Great Plains, or SAP Financials implement a bunch of Web 2.0 features (unless they get really caught up in fad-thinking).

However, not all enterprise software works like this. There is a class of enterprise software that requires that it be adopted by the whole organization. Because of my background, I think automatically about Enterprise Content Management, but the same is true for groupware like Notes or Outlook, and to a lesser extent, for collaborative systems like eRoom or SharePoint.

Let’s use the ECM example. In any organization, people have systems for managing content. Most of them suck, because they are messy, ill defined, inconsistent, and often made up on the spot. So far, the only approach to solving this has been to implement a new, improved, well defined content management system. Of course, this only really becomes effective if you can implement it across the whole enterprise - otherwise you’ve just added yet another method of managing content to a messy, disorganized enterprise. So the goal for something like ECM is this:

Figure 3: The Ultimate Goal of ECM (that’s what the E is for)

Anyone who’s tried to deploy an ECM system to an enterprise knows that this is no easy feat. In fact, I can’t think of a single enterprise where this is true. (Although I’m willing to entertain the possibility that one may exist. Maybe some of the ECM Bloggers like James and Laurence can set me straight.) In my experience, most efforts at deploying ECM within an organization end up looking like this:

Figure 4: What lots of “Enterprise” Rollouts really look like.

How did we get here? The system was sold to someone in middle management with purchasing authority, who encouraged his direct reports to use it, and maybe they did, and maybe a couple of other teams somewhere along the line jumped on board, and maybe Harold from Accounting moved teams to HR, so he uses the ECM system properly, even though his colleagues still plonk everything onto a share drive… and so on. You get the picture.

This is precisely the problem that Enterprise 2.0 can solve.

The traditional approach is to build something autocratic, and deployed from the top down, that works along vertical reporting lines. Working this way, silos of information are preserved. and communication is kept within the traditional areas.

The emergent approach is work from the bottom up, in a manner than allows the system to spread virally along horizontal functional lines. By making the system less restrictive, and easy to use the system is more likely to become the solution of choice for knowledge workers. And as they communicate better, they share information and increase their awareness.

Figure 5: An Emergent system, on the path to Enterprise 2.0 domination

It’s very elegantly explained by Euan Semple, discussing the quickest way to ‘do Enterprise 2.0′:

“Do Nothing! And then your bright, thoughtful and energetic staff will do it for you. Trouble is they will do it outside your firewall on bulletin boards, instant message exchanges personal blogs and probably on islands in Second Life and you will have lost the ability to understand it, influence it, and integrate it into how you do business.”

So, in an enterprise context, does ‘emergent’ have to mean ‘messy’?

I don’t think so. For a system to be emergent, the emphasis needs to be on how quickly the users will adopt the system rather than on its structure. That explains why a hallmark of these Web 2.0 technologies is that they are accessible and less restrictive.

I don’t think this notion necessarily precludes systems that offer a traditional structured approach to enterprise information, but it does mean that if your notion of “best practices” don’t ‘t fit perfectly with your users are actually doing, you will find that your enterprise solution won’t emerge very far at all…