Archive for the ‘ECM’ Category
People, Content and Pie
Laurence Hart over at Word of Pie calls us out on our approach to content management . Dean and I are both big fans of his blog, so we were pretty stoked to see a whole post about us.
Laurence raises a lot of valid concerns, all of which we’ve spent loads of time mulling over, and I’ll get to those in a second.
But first, to really understand our solution, you need to know how we got here. Dean and I absolutely understand where Pie is coming from. We have a long history of working in the ECM space with TOWER Software. We’ve read through countless customer requirement lists about compliance, Sarbanes-Oxley, retention, discovery and authoritative versioning. We’ve spent hours designing taxonomies, file plans, and security and access policies. We’ve drafted tender responses, and drawn large Visio diagrams. We’ve written integrations to nearly all the of ECM products in the market today.
After all this effort, once an organization deployed our tailored solution, we’d observe the same pattern. The content management software met the business needs, but it didn’t help the end users. Instead, It got in their way. It often made it harder to find things, and it made them work to understand things that they weren’t specialists in — like taxonomies and retention. User acceptance and training overheads were huge. We had to work like crazy to get people to use our carefully crafted solutions.
OK, you might say — that’s fine. Work isn’t supposed to be fun. You just do what you’re instructed to do. As long as the enterprise as a whole benefits from the solution, the content management program is doing its job.
Except that the enterprises weren’t really benefiting. The push-back from the user community meant that people wouldn’t actively use the solutions to do their daily work. Large, corporate, and eminently scalable repositories all over the world are filling up with dusty, useless content, most of which is almost certainly never going to be seen again. Traditional content management is extremely effective at preserving things. It’s terrible at solving the kinds of tactical problems that people deal with every day. Sure, retention was up. But productivity was down.
(Pie knows this. That’s why he talks so much about invisible, or transparent ECM . Because yes, preserving things is important, but knowledge workers don’t care.)
So, when we started Infovark, we set out explicitly to solve the other problem. The people problem. The fact that people couldn’t connect and share with each other. We decided to build an enterprise product that people would want to use, first and foremost. The capture and retention come second. The point of a transaction is not to get the paper receipt.
OK, that’s where we came from. Now to answer some of Pie’s more technical questions:
- How do you manage the disk usage? Peer-to-Peer is concerning. I’ve used Groove and it can be a disk hog. You would need a fair subscription model to manage the whole thing.
Groove is a disk hog. Transferring files from a peer through a peer is not what we do. For one thing, Groove places content on your machine that’s merely “passing through”, i.e. unrelated to your work. This can be something of a security nightmare. How do you keep that information secure? For another, Groove is about pushing updates out to subscribers. Infovark works like RSS; we pull updates. And we only pull data relevant to you and to which you have access. The network usage is about the same as if I email a document from my computer to yours.
- Are the wiki pages also stored peer to peer?
The Wiki pages are indeed stored locally and accessed remotely.
- What do you do about items once completed and needed to be kept?
As of right now, we don’t do anything! One of the great things about the REST-based approach that Infovark takes is that that content is accessible and available to the whole enterprise. Any content-spidering search product, like the Google search appliance, can easily scoop up the latest version and index it. Periodic backup or archiving would work in the same way. Use your favorite off-the-shelf tools. We’re also planning some specialized versions of Infovark that can address all three needs in the same package.
- Items are listed on a user’s Wiki. Where does it get listed when a user leaves the company?
That’s up to the IT guys. The user’s Infovark could easily be picked up and hosted on a server. Then all you’d need to do is change a DNS entry or leave behind a permanent redirect. It’s kind of like an “Employee Graveyard”. Creepy…
- How do you track/prevent cross edits? Johnny starts to edit something and then I decide to make some edits as well. How is that managed?
Gah! Stop asking hard questions. We’re working on that right now. We’ll get back to you when we get to Alpha in June. 
Let’s all share a point, shall we?
We’re a little late to the party, but there’s a wonderful comment thread over on Shel Israel’s blog about all things social media, and particularly around Sharepoint and Microsoft’s attitude to the emerging Enterprise 2.0 contestants like Jive Software.
All this stems from a quite inspired piece of writing from Dennis Howlett, where he discusses the difference between the established “mega” vendors, and the emerging Enterprise 2.0/Social media products:
In other words they (the “mega” vendors) are transaction based. They are not people based. I’d go further and say they are departmentally constrained, reflecting the internal power structures they were designed to support.
Naturally, this led to something of a flame war, where Microsoft and the SharePoint zealots were out in force, defending the innate awesomeness of SharePoint, and the newer more agile folk were perhaps taunting them a bit more than was polite. All in all, it makes for highly charged and extremely interesting debate.
Personally, I’m not sure either way about SharePoint’s capabilities in this space. I do know that Lawrence’s original comment on Sam’s blog really irked me, and it’s not the first time I’ve encountered him in the blogosphere.
My experience is that I’ve met lots of people who use SharePoint, but very few who really like it. On the other side of the fence, there are converts to the more dedicated social software – (like EMC’s Chuck Hollis), who do seem to have good things to say about the new emerging platforms.
As Dennis says, these are indeed interesting times. And good healthy debate amongst vendors has to be healthy for customers, right?
Ending the Paper Shuffle: Tracking Documents
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.
Ending the Paper Shuffle: Locating Documents
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.
