Executive Summary

There is no arguing with the numbers: 100 million Sharepoint licenses, $1 billion dollar Microsoft business. SharePoint is definitely out there, and it's installed in a lot of places. The problem is that very few know what to do with it. This is particularly true when it comes to using it for "true" Enterprise Content Management (ECM) applications, as discussed in this article. To be fair, part (perhaps a large part) of the problem, is that SharePoint is able to do so many things. That coupled with all the the talk and noise about it, generates such undeniable confusion that it turns the quest for the "right" solution into a navel pondering exercise. In the absence of clear direction, we at Kollabria thought we should try to answer the question: Can SharePoint be used as an ECM platform?

Using Microsoft SharePoint as an ECM Platform

We can't deal with everything related to SharePoint here in this article, but let's say that what you wanted to do was to improve the productivity of business processes centered around business content, you know, like paper documents, e-mail, forms, electronic documents. And what you really want to do is "collaborate," and have that collaboration be structured according to various business processes. On top of that you realize that part of your solution requires you to be concerned about security, and making sure that items of record were properly managed. You basically want to use SharePoint to improve the efficiency of certain business processes, so that you can do more with less, so to speak. In that case then you are talking about ECM. Crummy label, and we don't like it any more than you do (mainly because it is empty and not very descriptive), but that's what it is in industry terminology. ECM spans the spectrum. A simple thing like adding a name to your company address book is a form of ECM, so is having 10,000 users managing one million document images as part of a customer call center operation. You never know what people mean when they talk about it, and this is particularly true in the SharePoint world because both are given equal volume from the industry loudspeaker. Even worse: both are treated on the same level of complexity. Clearly, in the context provided above, we are talking about something much more involved than that. There are many reasons why you might want to use SharePoint to build this kind of solution, not the least of which is the fact that one common information repository, management and collaboration layer beats managing and implementing multiple proprietary systems. That said, there are many different software platforms that can be purchased to do this kind of end-to-end ECM, and they are specifically built to do that. It's hard to take that advantage away from them. In terms of price, they range from cheap (remember: you get what you pay for) to painfully expensive. A common question we get is related to whether this can all be done using Microsoft SharePoint, instead of any of these other software platforms. The answer is a resounding, "maybe yes, maybe no."If you try to do end-to-end ECM with SharePoint and you don't know anything about configuring and implementing an ECM solution, then the answer is, "NO." If you think you know ECM and you've never done it, and you say to yourself "How hard can it be?", then the answer is also, "NO." If you do understand ECM and you have both the planning/project management skills as well as the technical know-how, then the answer is a resounding, "YES." It can be done, it is being done, and it is being done successfully. The sad part is that, in the vast majority of cases, the opposite is all too common. Think about it this way, Microsoft has delivered the parts to your new Porsche, curbside delivery. All you have to do is put it together. From what we hear, there are a lot of people trying to put that Porsche together with car parts strewn all over the driveway, using a manual that was written to assemble a go-cart.

The Importance of ECM Experience

Those who successfully build their ECM solution on SharePoint, depend on a resource (integrator/VAR/consultant) who has built this kind of solution before (that has really built a true solution, not the kind that simply stayed in a Holiday Inn Express). Alright, that may be unfair--at the very least you need someone who knows what they don't know. Knowledge and experience with ECM solutions plays a critical role in the successful deployment of this kind of solution and its importance should not be underestimated. In order to properly deploy an ECM solution using Microsoft SharePoint, we must first understand the limitations of SharePoint itself--in other words, we must understand what it was built to do out of the box, so that its "weaknesses" can be supplemented with the right products, tools and know-how. Microsoft has a fairly healthy universe of 3rd-party software companies that deal with precisely those issues. SharePoint has weaknesses in relation to ECM, and those need to be understood before starting a project, not after. You don't want to deal with a database that can't manage the volume, a viewing system that takes hours to render an image, an infrastructure that provides all the security of a locked screen door, and search and retrieval that has all the attributes commonly associated with finding a needle in a haystack. We're not saying that this is what will happen, it only happens when you don't understand fully what kind of car you want to build, and for what purpose. SharePoint does not discriminate, it lets you do whatever you want even if the outcome is evil, wicked, mean and nasty. That is why the second critical skill, to understand the nature of an ECM project, the planning assumptions, configuration criteria, functional user requirements and project management skills that make for a successful implementation is such an important ingredient. Conceptualizing an ECM Solution ECM isn't rocket science, although judging by the confusing terminology the industry uses, it may as well be. In order to do ECM there are three key elements that must be considered. All ECM solutions have these three elements, and differ only in the extent to which the solution requirements emphasize one or more of them.

Information Capture

In order to manage information, it must be captured and provided to the ECM application, this can certainly be done using SharePoint. That capture process may involve capturing information from existing data sources like e-mail, databases or websites (for example) and then manipulating it in order to make it properly and securely available for the ECM user.

Capture may also involve the scanning of documents, or all of the above. Designing an effective capture solution requires a fairly rigorous understanding of just how to do that. It's not the case, for example, that simply hooking up a couple dozen network scanners will do the trick for document capture. If you like the idea of having hundreds of users pump 50K files (per page) onto your network from every scanner or MFP, morning, noon and night, with settings chosen by them instead of what is defined as standard--then have at it. Ditto if you like the idea of having them float (unsecurely) over your WAN, headed for uncontrolled desktops, fax servers and printers all across the enterprise. Double ditto if they are barely legible, upside down, backwards, top secret and attached to Outlook address book lists that span the globe.

Obviously this is not the intent. So to that end the capture process must be controlled, configured and managed in accordance with the functional requirements of the user and the security interests of the enterprise. SharePoint simply gives you the ability to do it, it does not give you the ability to manage it beyond very rudimentary controls. That said, those controls can be added, purchased, written and, if need be, customized--provided you understand what is involved in doing so.

Management

The purpose of an end-to-end ECM solution is to generate increases in user productivity. Punishing them by putting all information under all fingertips at all times is not the way to go. An ECM solution has to provide access to the right information for the right people. It has to have management features that allow a quick triage, to provide the user in department X with the right information in the right instance. It has to have the security features that control that access, manage the users relationship with that information, predictably (workflow) deliver it to the right user at the required time. This does not have to be complicated, but it does have to be planned out, thought out, and properly implemented, preferably by someone who knows how to do this. A skilled resource will plan the functional user requirements for each application running on the SharePoint "layer." They will determine the performance requirements needed for the databases, viewing applications, search requirements and other core capabilities and will configure SharePoint to allow it to provide those services. This has to be done whether you are using an ECM platform that comes with many of these features already built, they still need to be properly configured and implemented. If you want to create the management infrastructure (i.e, the SharePoint-based application that the user interacts with), you can go back out to the driveway and weld together some parts that look like they might do the job, or you can use components already built, and specifically designed for that job, and better yet are specifically built to work with SharePoint.

Preservation

Storage is not preservation. Storage is a place where you put things, preservation means guaranteed availability. They are not the same thing. You don't go through the trouble to capture and manage information in a more efficient manner in order to lose it. Preservation is one of those often overlooked system requirements. It's easy to lose information, and it's just as easy to send it all to a server in France with the push of a single button. Making the right information available to the right people under any and all circumstances takes planning, and a solid understanding of the functional requirements of the solution is needed. It also requires a solid understanding of the capabilities SharePoint provides in this regard. Since you don't really want to keep all information forever, and likewise you don't want people to simply delete directories they don't need anymore, particularly if that involves content related to company records or compliance-related initiatives. Those requirements need to be understood before embarking on the solution quest. It is not generally the case that every application requires lifecycle management, but it is the case that information required by the ECM solution must be available to the right people under all circumstances. For this reason alone, the solution architect thinks of "preservation" and not simply content storage.

Conclusion

When planning an ECM solution, all three of these requirements must be carefully thought out, designed and implemented according to the functional requirements of the application. This is true, no matter what you use to build the ECM solution. There is nothing about SharePoint that says that none of those requirements can be met. It can all be done with SharePoint but, like anything else, you have to know what you are doing, and you have to know how to do it. SharePoint is a facility that lets you do many many good things, ranging from creating a better file server environment, to building a fully blown ECM solution, and to creating an enterprise ECM infrastructure for numerous possible applications. It's not a question of what it can do, it's a question of how to do it. There are numerous 3rd party products that utilize SharePoint, integrate with it, and utlize its core competence, allowing a qualified solution architect to build whatever they want. So the question is not can you do this with SharePoint, the question is learning how to do it with SharePoint.