SharePoint Will Not Own ECM (At Least, Not Anytime Soon)
I beg to differ with you, Professor Shepley. SharePoint is not about to own ECM (cf. Joe Shepley’s post, SharePoint will own ECM). SharePoint is actually a long, long way from becoming, quote, “the main player in the ECM space, ahead of ‘big ECM’ (IBM, EMC, Oracle, Open Text, Alfresco, et al.).” And here’s a list of the reasons why.
Reason #1: Existing ECM investments. Not everybody’s an ECM “newbie.” I can see SharePoint making sense for a “greenfield” organization – particularly a smaller organization that has no ECM tool whatsoever. But the fact is plenty of organizations (particularly larger organizations) already have an ECM solution in place. For these folks, deploying SharePoint means creating yet another silo for their content. Then there’s the whole migration issue: how to move all that stuff from your existing ECM repository over to SharePoint. If, for instance, you’ve got large volumes of images stored in a FileNet repository, you’ll think long and hard before you go migrating them over to SharePoint so you can rip out your existing ECM implementation.
Reason #2: The advanced and specialized content management capabilities that SharePoint can’t provide. I’m thinking about imaging, for instance – particularly in high-volume scenarios. Or workflow. Or archiving. Or enterprise report management. Or management of complex files like engineering drawings. On the records management front, Microsoft is chipping away at it – but so far has nothing to offer those organizations that still need to manage paper. And email management with SharePoint is still a manual, drag-and-drop operation. My point being, if you’re going to depend on SharePoint to meet your content management needs, and you happen also to have needs for any of these other pieces of ECM functionality, you’ll be doing it through one or more Microsoft partners, with some third-party tool(s). A single-product solution it ain’t.
Reason #3: The cost issue. Many people still seem to be under the delusion that this SharePoint product is “practically free”! That may be the case, if you’re talking about the earlier incarnations of the product. But for anyone looking to put in SharePoint 2010, you’d better make sure to factor in the costs associated with upgrading your environment to accommodate its 64-bit architecture. Then ask yourself: Will your existing applications run on 64-bit? What will it cost to upgrade those applications? And, for that matter, in the short term, are there even 64-bit versions now available for all of your business-critical applications? These are all questions you need to ask – and the answers will have implications for your overall costs of moving to SharePoint.
Reason #4: The content management needs of process workers vs. knowledge workers. What’s your workforce look like? For organizations that rely on process workers performing largely transactional business processes, ECM makes sense – and will continue to make sense. (Example: an insurance company, processing claims, with the need for capturing high volumes of supporting documentation for claims – and the need to pull those documents into the claims management system.) The case for SharePoint over ECM really makes sense only for those organizations (or for those departments within an organization) where the users are primarily knowledge workers (with needs for document management, document routing, and collaboration).
Anyone else care to weigh in on this one?
Hi Linda,
Re #1: SharePoint offers a lot in this case. You dont _have_ to migrate all the content if you dont want. You can index it all and use the great search capabilities to find it. You can then use SharePoint for the ECM where it makes sense. Also, you can have SharePoint store the “blob” in your existing ECM solution if you really want. That way you can give your users the great SP experience they deserve & they dont need to “use” the clunky outdated old ECM system directly.
Re #2: With remote blob storage SharePoint scales in all sorts of new ways that can help address this concern.
Re #3: Implementing SharePoint on x64 bit hardware doesnt mean you need to migrate your other applications to x64. Unless you are also putting them on the same servers … which isnt a smart thing for a variety of reasons. Users can happily be running on x32 PCs and SharePoint can happily interoperate with other systems running on x32.
Re #4: I disagree. You buy an ECM solution for its Features. You should buy SharePoint if it meets your needs better than the next ECM system, not on who the users are. You are right that SP has excellent features that cater to end users … but most of the features are also equally applicable to “process workers” too.
Well, as usual this has risk to turn into the traditional pro/con Microsoft discussion. Still, there are of course differences which I believe also has to do with different corporate cultures and business models.
My biggest problem with Sharepoint has not to do with its architecture or features but a mindset. There are many MS-people in IT-departments around who know MS-products and does not do that much to follow what is happening in the world outside what is covered in the MS Enterprise agreement. MS-products are not that terribly complicated to install and most IT-admins therefore would accept a task to install Sharepoint. In fact most of them have probably been at conferences and marketing events and being introduced to the product. After all it is heavily marketed. So many IT-departments will offer Sharepoint when the business people ask for “something that help with this collaboration thing”. Some will even do some comparisons with other vendors just to conclude that they look complicated and expensive. The point is that most of them naturally have no experience from ECM (and most MS Sales people don’t either) and that is usually why it goes wrong.
The whole problem boils down to the fact that Enterprise Content Management is not only a platform – it is a concept to approach information management in a corporation. That means that there has to go a lot of thinking and modeling into any ECM-project to be able to adapt the platform to the way each company works. Many people like simple solutions but the problem is usually complicated which means that simple solutions tend to fail after a while. Sharepoint is just too easy to install. It does not require much input and thinking from the business side and will sometimes be set up using a default configuration as a start. No way that will happen with Documentum. It will take weeks to get it up and running – weeks that also includes thinking a lot about metadata, access rights, processes and so forth. More expensive? Yes it is but I would argue that any “real” ECM-project will cost roughly the same independent of which of the major platforms you choose. In the light of things license costs has a tendency to be the smaller amount and no one ever pays the list price (that is often used in comparison) for platforms like EMC Documentum, IBM Filenet or Oracle UCM.
However, from an architectural standpoint there are of course important differences. The major one being the fact that Sharepoint from the beginning was a workgroup-oriented info sharing software. That concept is way different from an ECM-concept. As a result it was not until SP 2010 that you could have a unique URL to address each content object and make sure that in order to use it in several sites it would not be duplicated and therefore kissing goodbuy to version management. There are quite a few concepts in the architecture that are that different between the platform. For some they matter, for some they don’t but the worst is when people don’t care.
Another thing is customizations. As long as you use Sharepoint without any major configuration changes or development efforts it is fairly straight forward. However, when the business side after a while asks for things that requires more customizations then it becomes hard very quickly. The curve becomes much steeper. On the other hand most major ECM-platforms have another curve since they are meant to be customized from the beginning. Whole frameworks are there to use. Expensive sure – but you will always be able to do what the business side ask. Not so much on the Sharepoint side. And workarounds can be expensive as well.
That leads to installations of Sharepoint that in many respects is just a web GUI of the old Windows File Share and that is just sad because Sharepoint deserves better than that.
Finally I would strongly argue that you need ECM-capabilties in the platform just as much for process workers as for knowledge workers. Anything else it just not taking ECM and information management seriously. Do we really want stove-pipes for yet another set of business requirements.
Thanks for stirring the pot!
Bob, I am consulting with my experts regarding your responses to #1, #2, and #3. As for #4, I still contend that it matters who your users are — i.e. the nature of the work performed by those users, plus a consideration of the systems they rely on most to do their work. Take, for instance, those insurance claims processors I cited. Maybe SharePoint will fulfill some of their DM needs, but once you start trying to pull supporting documentation into one of those big, hairy, homegrown claims systems, all bets are off.
Alexandra, I agree with you about the mindset issue. The concept of information management, particularly as it applies to unstructured content, is one that Doculabs has “evangelized” for years now. Your comment about customizations is spot-on; it sounds to me like you’ve spent some time down in the trenches! You might want to take a look at our white paper for more discussion on this topic (and stay tuned for updates to reflect SharePoint 2010 functionality).
Linda,
Good article and discussion. I tend to agree with you. It seems like the ECM industry are like lemmings going over the Microsoft cliff, chanting Sharepoint, Sharepoint, Sharepoint, the entire time.
Bob is 100% correct, You buy the system you need (to me, that includes considering who your users are/what they do — flip side of the same coin as to what you’re both saying). However, Alexandra in turn makes a good point about the desire for simple and the ongoing chants of SharePoint and the attendant marketing.
It’s going to be interesting to see this debate evolve as SharePoint 10 starts hitting and problems start popping up with it.
Waiting for that backlash.
Bryant
I have worked with SharePoint for the last five years within large organizations in Law, Finance, Publishing and Communications, and the thing it does best is to fragment businesses into multiple, disconnected information domains.
Site administrators have full control of content and site membership. But the focus for every department, workgroup and project team always ends up inward facing.
This is in stark contradiction to what is happening with organizations rolling out proper Enterprise 2.0 implementations. I was approached to pilot and then launched into live an employee community using Telligent Community Server.
We now have over 130 groups representing every aspect of the business from multiple business units from all over the world. Members join multiple groups and make new contacts well outside their usual work areas. The potential for innovation and knowledge sharing is considerable.
Enterprise 2.0 is about openness and transparency, SharePoint is about control and protection. I hear about the great improvements in SharePoint 2010 wikis, blogs etc, but silos with blogs and wikis are still silos.
Companies have a clear choice to make: do they want Enterprise 2.0 and all that that implies, or do they want the Enterprise 1.0 status quo, with a bit of social networking thrown into the mix. The choice is simple.
Companies afraid of change and who think they can still drag the old ways of doing business into the 21st century will cling to SharePoint 2010. Companies who take-up genuine E2.0 ECM vendors will react quickly to change and outperform their slower rivals in the marketplace.
I like that: “Silos with blogs and wikis are still silos.”
The challenge is that most large organizations, particularly in the industries you cite (Law, Finance, Publishing, and Communications), have a need to impose some control and protection around their content. Enterprise 2.0 technologies offer new ways of working and knowledge-sharing, along with great potential for creativity and innovation. But for all too many organizations, some of “the old ways of doing business” involve compliance, records management, and legal requirements – requirements that are not going away anytime soon (if ever).
Let’s do away with the silos, let’s have transparency and the ability to share information – but let’s also be able to appropriately manage the content that those various groups are creating, and to manage it throughout its lifecycle. Because you just might have to produce it someday – e.g. in litigation discovery.