As before, you will need to take the elements of these structures and weigh what will work within your organizational context. My hope is that you will be able to use some of the elements of these structures when creating an ECM organization for yourself.

The following three structures are scaled for small, mid-sized and large organizations. Again, these are not the only possible options but I have found that our clients have had success implementing ECM using structures similar to these.

Click here for a larger image

The most important aspect of this particular structure is that the ECM group is not part of the IT department, Legal group or even an administrative or business services group. This organization has chosen to align ECM with overall business operations in a group called Technical Operations and Competence. This division is responsible for helping the organization achieve operational excellence across their core business, and includes such functions as Engineering Standards, Maintenance and Reliability, Environment, Health and Safety (EHS), Training and Development, and, finally, the ECM function.

The concept of moving ECM out from under IT applies equally to smaller organizations although there does need to be a certain level of scale to justify moving ECM into it’s own area. One key benefit of this model is that the ECM team is able to focus exclusively on the business benefits of content management and not get caught up in the minutiae of IT systems operation. This is not to say that the technology aspects or ECM are not important; as I said last time the best ECM solutions come from open conversations with your technical team. However, the root cause of many failed ECM implementations is an over-emphasis on the technology and not enough focus on the business problems ECM will address.

You have likely noticed that this structure doesn’t reference an executive steering committee. That is indeed a shortcoming of this particular structure, although this is offset somewhat by the fact that the team reports into a Vice President. Also, there was an executive steering committee in the initial project phase of this particular ECM program but as the ECM team transitioned to an operational mode it was decided that reporting to a single VP was sufficient to ensure business alignment.

Click here for a larger image

This organization shares many of the structures used by the larger organization but the key difference is that this group reports into IT (although the overall program is guided by an executive steering committee to ensure proper business alignment).

The other important aspect of this structure is that the core ECM roles report into a Director of Information Management, who has a dotted line relationship with the technical personnel responsible for ECM development and day to day operations. Again, I believe this separation of business alignment and technical execution is important to ensure that the ECM solutions continually focus on providing business value.

Click here for a larger image

This organization has a small but mighty ECM team and again reports into the IT function. The fundamental ECM roles have been collapsed down into a smaller group but note that there is a specific role focused on Change Management. This was the topic of the comments posted in response to Part 1 of this blog, with one person going to far as to suggest that the acronym ECM should stand for Enterprise Change Management.

I won’t go that far but I do agree that one of the keys to any successful ECM program is to ensure that your user community is ready, willing and able to adopt ECM-based business processes.

Finally, there is a shared accountability for managing the tasks of the ECM Operations (and development) team between the IT Manager and the ECM Program Manager. They report directly to the IT Manager but have a dotted line relationship to the ECM Program Manager to ensure they are engaged in meeting the business objectives and strategies set out by the ECM team.

I hope you have found these posts to be useful. I welcome your comments and would be happy to share further observations and experiences in the comments section or directly. You can drop me a note on Twitter @GregClarkC3 or send me an email at greg.clark@c3associates.com.

But first, a caveat. The roles as well as the org structures I will discuss next time are intended to be a starting point. We don't live in a perfect world (at least I don't, not so sure about you…) and we can't always count on creating the ideal organizational structure. Existing structures, HR policies, sponsorship issues and other organizational dynamics can get in the way.  My goal is to give you a guideline based on my experience with what works.

And one final point. Although many of the roles listed below are called "teams" this can often be one person or multiple roles can be performed by a single person, depending on the scale of your organization, your budget and your ECM program.  Again, this is a guideline to help you develop a structure that works best for you and your organization.

Steering Committee

The role of the steering committee is akin to that of the Board of Directors of a company; they provide high-level direction for the activities of the ECM program and sign off on major program deliverables.   The steering committee should be made up of senior executives (ideally C-level executives or, if that isn't feasible in your organization, their direct reports).

Your project sponsor should be a member of your steering committee and should be your go-to person when you need to escalate issues or if you need business guidance. You should have regular meetings with your steering committee. Ideally once a month but no less than quarterly.

Program Manager

The Program Manager  runs the ECM program and is responsible for the initiatives conducted under the ECM banner. This person is ultimately responsible for all deliverables, budgets, timelines and program objectives. Some specific tasks of the program manager include:

• - Drive the creation and execution of the ECM strategy
• - Liaison to the steering committee
• - Manage vendor relationships
• - Hire and manage the ECM team
• - Contribute to or lead the development of an appropriate information architecture
• - Identify, track and act upon key metrics for the ECM program

Project Team

The project team leads the implementation and design of discrete ECM initiatives. This can include document imaging rollouts, shared drive migrations, team site deployments, the creation of new workflows, system upgrades and many other projects.

The core skills on your project team should be a combination of strong project managers and ECM-savvy business analysts. I have often seen these roles combined and this is my preferred structure. Only in very large projects will you require a standalone project manager

Information Governance Team

The information governance team is responsible for the creation and implementation of your ECM governance framework . This includes aligning ECM activities with the relevant corporate policies by creating guidelines, standards and procedures related to ECM.

The information governance team also works closely with the project team to develop and implement metadata standards, taxonomy standards and the overall information architecture for your ECM solution.  They are the "go-to" team for questions about content disposition or exceptions to your ECM principles (for example, when is it okay to copy content rather than link a single document in multiple locations).

And yes, the information governance group also includes the more traditional records management roles. This includes the creation and application of a corporate retention and disposition schedule and can also include the management of a records centre or corporate library.

Change Management Team

This role is responsible for ensuring that your end user community is ready, willing and able to adopt ECM. While this  activity is often rolled into the accountabilities of the projects team, in my experience it is best to have a person or a team dedicated to ensuring the significant changes that can come from an ECM implementation are accounted for. This is often the single biggest cause of ECM project failure. When we consider that the change required to succeed with many core use-cases for ECM (for example, moving from a "File / Save As…" world to the need to add metadata to a simple MS Office document), there is little wonder end users will often rebel.

The change management team works actively with the project teams and the program office to ensure they incorporate good change management practice as part of each project plan.  The information gathered as part of this process is incorporated an overall change management strategy, which identifies the change impact of each ECM activity and ensures that communication, training and support plans  are in place to ease the end user transition to your ECM solution.

Training Team

The training team's role is relatively straightforward; ensure that your user community knows how to use the ECM toolset.  This is often more of an art than a science. My advice is to focus on providing your end users with "one best way" for performing a particular task. Even though the tool likely supports a variety of methods for achieving the same thing, there's nothing more confusing than giving someone three ways to save a document.

The training team should be ECM experts in their own right. Although it can be tempting to repurpose existing trainers to also provide ECM training, the complexities and subtleties of ECM are often lost on people who are not experts. Where this isn't possible, use the ECM experts from your other teams to implement a "train the trainer" approach.

Support Team

Your support team is often made up of members of your projects team, change team or training team (or all the above).  The role of the support team is to provide second-level support to your end user community. They must be ECM experts and should know the nuances of your ECM toolset very well. They will work closely with your help desk and technical team to identify and trend issues, and will help prioritize system fixes or enhancements.

Technical Team

Your technical team is tasked with keeping your ECM system up and running. Despite the complexities of ECM applications, you know this team is successful when it looks easy.  Technical teams generally have development groups, operational / system administration groups and may also have their own infrastructure groups.

It is critical that your technical team have a close working relationship with your all other teams. Although your projects, change, training, governance and support teams should be ECM experts, the best solutions come from open conversations with the technical team.  This will ensure that the implications of any proposed customizations, new modules or other system changes are well understood and communicated to your user community.

Other Roles

We can't forget end users, of course. They're the reason we are doing all of this in the first place. Ensure that you have a good feedback loop through each of your teams so the end user experience is  understood and incorporated into the continuous improvement of your ECM program.

It is also common to have a close relationship between the ECM team and the communications and / or portal team. There groups are often a separate entity, but there is significant overlap in areas like governance and information architecture.

The Role of Consultants

It is important to recognize that consultants or vendor professional services teams can and should play a role in your ECM program. They have the expertise that comes from having implemented ECM in a variety of different organizations and you should be able to take advantage of their knowledge and experience.

However, when working with consultants it is critical to have an employee assigned to shadow the consultant and ultimately take over their role. Although it can be valuable to engage consultants to establish or revamp your ECM program, it can be risky to become too reliant on them.  If your consultants don't want to mentor your employees to eventually replace them, find different consultants. 

I hope this has been a useful guide. Next time I will share some sample ECM organizational structures. In the meantime, I welcome your comments and feedback.

Cross-posted to my AIIM ECM Expert Blog.

And my stand is this: I believe we shouldn’t give up on the information lifecycle.

Although it is tempting to think that by using separate systems, one for “collaboration” and one for “records” we can remove the burden on end users from worrying about how to classify a document, I believe this is false economy.

The risks of separating collaborative and records content can be high. Having a formal records platform for only final records leaves the very good question of what becomes of all the drafts and versions that led to the document becoming final. I’m no lawyer, but I can tell you that in any discovery process you will be asked for the draft and work in progress documents even if you have legitimately disposed of your “record” copy.

I agree with those who commented that we can’t always achieve perfection. My post from last month speaks to this and I definitely stand by the fact that we can’t let the perfect be the enemy of the good.

I believe we can have “good” even while not losing sight of the information lifecycle. Although those words may scare some people, information lifecycle management doesn’t necessarily equate to a lot of overhead. In fact, proper information lifecycle management should mean LESS overhead.

The term I’ve used in the past is “subversive” RM. By this I mean end users don’t know (and probably don’t care) about when something is declared a record or what the classification is. This can be achieved relatively easily by using simple metadata inheritance at the container level.

I advocate a big bucket approach instead of a big budget approach. Wherever possible consider creating a retention schedule based on retention period instead of content type. This means that users likely won’t be able to use retention as a search item but let’s face it, most users don’t use records classifications as search terms anyway.

At the end of the day it comes down to business value and risk. Every ECM project should focus on maximizing business value while minimizing risk. Clearly it can be a challenge to rationalize these two things but in my next post I will address strategies for creating an ECM organization structure that can help resolve these questions and help you achieve your content management goals.

But a funny thing happened on the way to ECM nirvana. Both organizations decided to pursue a “parallel” strategy; one system for collaboration and work-in-progress documents and one for “official records” or final versions (often copies) of documents that have completed the collaboration cycle (and yes, the rise of SharePoint plays a part in this decision, but that’s a discussion for another day).

I will freely admit my first reaction was “are you nuts?” After all, as a red-blooded ECM professional my mission in life is to reduce duplication and promote information lifecycle management. But I’m always willing to listen to both sides of any story (and they’re my clients so they’re always right, right?).

On the positive side, establishing a process to manage only final copies of records mirrors the paper world; if an organization has a well-established physical file management system why not try to replicate that in the electronic world? The other benefits are that final versions of documents are more likely to have a natural structure which leads to more intuitive metadata and greater discoverability (at least in theory), and content disposition is simplified because the retention schedule for “official” copies is often easier to determine.

On the other hand, isn’t the point of ECM to manage information through it’s lifecycle? If we are never going to achieve true ECM why do it at all? You also have the problem of costs; the cost to train people to know when to move a document to its final state and to know where to put it can be high; this is especially true if those people don’t attend training or if they do, still choose not to move final copies to the approved location. The alternative is to assume that any documents that need to be moved to an official repository will be managed by administrative personnel. Again, this increases costs and impacts efficiency, both areas ECM is intended to improve. And there are always the potential risks (and risks always translate into costs one way or the other) from duplicate content in multiple systems. This is gravy for lawyers in an eDiscovery process because it creates the possibility of confusion about which version was used to make a decision.

At the end of the day it is difficult to say definitively which is the best approach. Every organization is unique and has its own history, business drivers, processes and rationale for certain courses of action. General ECM best practice would dictate that information is managed through its lifecycle using a single system or at least seamlessly integrated systems, but this isn’t always possible. What I will say is that minimizing duplication and streamlining business processes through good information management usually means managing the information lifecycle. This should be the approach wherever possible and I suspect in most cases this will be the most cost effective approach in the long term.

Ensuring you have a good understanding of the capabilities of your current platform will also help; in many cases the traditional ECM tool may be perceived to have “failed” but in fact meets all of your functional requirements. The other alternative is to look into the possibility of integrating a collaboration platform with a system of record. Even if the truth is both of these platforms are technically capable of managing the information lifecycle, if users perceive that one is better than the other for a particular task you will have more success managing more content, and that’s really what we are trying to achieve.

The participants were a diverse group but there were many records managers in attendance. The session itself was very interactive and we had a great discussion about Microsoft SharePoint and the future of ECM.

One of the most interesting aspects of the discussion was an attitude shift from many, if not all of the records professionals in attendance. In the past I have observed that many RM-led ECM initiatives have focused on the records management aspects of the content to be managed. Often this meant that end users were trained to file their documents into a structure that mirrored the corporate records retention schedule. While this might make perfect sense to records managers, unfortunately most users in your organization are probably not records managers. As a result, many implementations failed to meet user adoption targets because users didn’t feel the structures they were being asked to use fit the context of their regular business day.

I call this the 20/80 approach; 20% of your content is managed perfectly while 80% is scattered across partially-deployed ECM systems, email inboxes and shared drives.

Amongst the records professionals at the AIIM event, however, there was a clear shift in attitude and approach over what I have experienced with similar groups in the past. They strongly believed that building business-focused structures and small-but-mighty metadata models tailored to core business processes was preferable, even at the expense of “perfect” records management. This is the manifestation of what I have long believed; it is better to have 80% of your content under some form of management even if this isn’t perfectly aligned with the retentions schedule. Yes, you still need tighter management of a small portion of critical or high-risk content, but you should never let the perfect be the enemy of the good.

The conclusion I draw is that while SharePoint is clearly having an impact on the ECM market (in addition to the fact that it is the fastest growing server product in Microsoft history, esteemed organizations like AIIM have started to dedicate entire communities to SharePoint), at this point it appears that SharePoint's success has not come at the expense of incumbent vendors.  It will be interesting to see how this evolves but for now, it seems like there is room enough for everyone.

And just to continue the earlier trend of putting SharePoint into the mix of all ECM discussions, there was a great debate on the AIIM ERM Community blog this summer about the merits of SharePoint records management.  James Lappin feels there are significant shortcomings in SharePoint records management, Mike Alsup disagrees.

1. Traditional ECM remains strong even as SharePoint rises. It seems that everyone (myself included) has been talking about the impact of SharePoint on the ECM space, and SharePoint's influence is undeniable. Many analysts, consultants, customers and even casual observers have been predicting that SharePoint will eventually become the de-facto standard ECM application at the cost of market share and license revenue for traditional ECM players.  Then along comes Open Textand the aannouncement of their results for fiscal 2010.  Total revenue is up 16% and profit increased 24%.  That doesn't sound like a company on its way to irrelevance. 
2. Records Management still matters.   Even though most of the hype in our industry seems to be reserved for trends like Enterprise 2.0, open source, and the impact of cloud computing on ECM, enabling proper records management is still a big part of the value proposition for ECM.  Nothing brings this fact into sharper focus than the mountains of electronic and paper records that will be produced as part of the investigationand lawsuits related to the BP spill in the Gulf of Mexico.
3. The future of ECM is cloudy (and Cloudy?). It is natural and healthy for any industry to take stock of where it is in its' evolution, and the ECM industry seems better than most at navel gazing.  Joe Shepley published a good piece on his vision for Second Wave ECMand AIIM's fearless leader John Mancini shares his thoughts in a recent YouTube video.  There are enormous opportunities in ECM (cloud computing, continued data proliferation, Enterprise 2.0) and significant challenges, including significant debate on the definition of Enterprise Content Management itself.  John Mancini says that "ECM as a term is stressed", which tells me that even AIIM is thinking about the future of this acronym.

   Others are also debating the definition of ECM. Laurence Hart, though his Word of Pie blog, has been trying to come up with a new definition for ECM for several years now.  His most recent attempt to define ECM was last week and it has spawned some interesting discussion in his blog comments.  I'm always up for a good debate and this discussion has me thinking.  Should ECM include both structured and unstructured information?  Should it include web content? How about reusable chunks of content that can be used to pull together documents (e.g. standard paragraphs for a contract)?  Tweets? Facebook pages? Just good old fashioned documents?  

   I don't have a good answer (okay, I don't have a short answer) to these questions but I suspect you probably have an opinion, which I  encourage you to share below.

   ]]> http://www.c3associates.com/2010/09/things-i-learned-about-ecm-on-my-summer-vacation/feed/ 1 http://www.c3associates.com/2010/07/lessons-from-the-knee-of-the-master-battle-tested-tips-for-ecm-success/ http://www.c3associates.com/2010/07/lessons-from-the-knee-of-the-master-battle-tested-tips-for-ecm-success/#comments Fri, 16 Jul 2010 04:03:39 +0000 Greg Clark http://www.c3associates.com/?p=554 Not many people have heard of Duncan Stanners. Forget Twitter, LinkedIn and Facebook, Duncan was quietly plying his craft when the internet was but a twinkle in the DoD's eye. But make no mistake, Duncan Stanners has had the kind of success implementing knowledge management programs that most of us can only dream about. 

   Duncan recently retired after 20+ years of service at Shell Canada  (which is now wholly owned by Royal Dutch Shell) and I recently had the privilege of joining him and several of our peers in the Calgary knowledge and information management community at a retirement luncheon in Duncan's honour.  In the true spirit of knowledge management, Duncan shared some of the lessons he learned from the successes and challenges he faced over the years. The summary below was shared in the context of implementing a knowledge management program but it applies equally to any RM, ECM or information management program as well. 

   1. Go where the energy is. Duncan suggests that while there may be many opportunities to make a big impact with your initial implementation efforts, don't try to boil the ocean. When choosing where to focus, find the group with the most enthusiasm for your project, pick a problem and solve it. This not only builds goodwill with the folks whose problem you've solved, it also builds momentum and a positive reputation for your program team. 
       
   2. If you can't find energy, create it.  This is easier said than done but by focusing on the value your program will bring their area of the business and to them as individuals you will gain their trust and enthusiasm.  Again, find a problem and solve it.
       
   3. When talking to customers, don't talk about KM (or RM, IM or ECM), talk about their business.  This helps build trust and shows that you are there to help them solve business problems. It also has the handy side effect of helping your learn more about their slice of the organizational pie, which helps you apply your expertise in ways that are specific to their business context.
       
   4. If you can't create a hard-dollar ROI, focus on real risks. There is seldom a conversation about information management that doesn't at some point come back to the question of value for money (and nor should there be).  But hard-dollar saving s from de-duplicating the shared drive and improving information access do not always offset the initial costs of your program. However, a risk-based approach that uses hard cost measures based on things that have actually happened will help make your case. Sell your program on the same basis that you sell a safety initiative; the benefits of working more safely are irrefutable , and once they understand the similarities between the two they will be supportive.
       
   5. "You're already doing knowledge management. You're just doing it badly".  Duncan's point is that most groups within your organization are already doing knowledge management (or records, information or content management) but because they are using ineffective processes they are not managing their knowledge or information well.  Your job as an expert is to help guide them through the process to managing that knowledge or information better. Duncan suggests that you find cases where you have successful practices and repeat these until you succeed.
       
   6. Tools won't sell the thing.  At best, tools and technology can facilitate adoption and at worst they can constrain it, but the best tool in the world will not help if you are not helping real-world business users solve real-world business problems.
   ]]> http://www.c3associates.com/2010/07/lessons-from-the-knee-of-the-master-battle-tested-tips-for-ecm-success/feed/ 0 http://www.c3associates.com/2010/06/where-should-the-records-and-information-management-function-live-in-your-organization/ http://www.c3associates.com/2010/06/where-should-the-records-and-information-management-function-live-in-your-organization/#comments Thu, 24 Jun 2010 04:50:31 +0000 Greg Clark http://www.c3associates.com/?p=546 I am often asked where I think the Records and Information Management function should exist within a company’s org chart. This question usually comes up in the context of a frustrated practitioner who is having a difficult time getting traction for their ECM program or from business users how are frustrated at being told by IT, RM or someone else that they need to manage their information in a certain way that may not be immediately intuitive to them, or does not support their business processes.

   The first question to ask is whether it really matters. Shouldn’t a first class Records and Information Management (IM) program succeed by virtue of its own momentum and the value it creates irrespective of what the boxes on the org chart say? In a perfect world that would be true, but unfortunately we don’t live in a perfect world (if you need proof see my earlier post about the Calgary Flames missing the playoffs).

   So where should the Records and Information Management function live? Not in IT, at least not in most cases.

   Notwithstanding the fact that the “I” in “IT” stands for “Information”, the mandate of most IT organizations is to keep servers running and to manage vendor relationships. I know that many, if not most IT professionals are truly dedicated to helping their customers manage their business more efficiently, but at the end of the day the great majority of IT organizations are not set up to accommodate the challenges of managing information well.

   And these challenges are many. Perhaps the most important comes from the fact that Information Management implementations do not have a natural beginning, middle and end. Information Management is an ongoing process that evolves and changes over time to support changing business requirements and the needs of their user community. Information Management is not a project and it certainly is not a technology deployment.

   IT groups on the other hand generally operate a project management office tasked with standing up servers, upgrading software and rolling out new technologies. Each of these tasks fit well with a traditional “waterfall” project management methodology that expects right and wrong answers along the way. Information Management on the other hand is more art than science. Yes, it is critical that IM projects are managed properly and that appropriate controls are in place to ensure the implementation stays on track, but the key aspects of IM projects are people and process rather than technology. Change management is critically important and, let’s face it, most IT organizations are not adept at the people side of change.

   That leaves the question of where the Records and IM function should live within your organization. In my experience there are three good answers depending on the makeup and business challenges of your organization.

   1) If you are in a heavily regulated industry or are likely to face more than your fair share of lawsuits you likely want to align your IM program closely with your corporate legal group, reporting in to chief legal counsel.

   2) If your objectives are to enhance operational efficiency or improve the bottom line of your business by managing your information better, align your IM program with an operational support area or even a strategic marketing or R&D group.

   3) Finally, if you are in a situation where the only logical spot is within IT, try to ensure that you carve out the IM function from the other core teams in the IT group. One of my clients appointed a Director of Information Management a s a direct report of the CIO, which made her a peer of the more traditional IT roles of Infrastructure and Application support and gave her a seat at the table to advocate for IM.

   In the end, when push comes to shove the core mandate of each part of your organization will ultimately prevail. In the case of IT, generally speaking their mandate is to keep the servers running and as a result the processes and political power tends to support this objective. Many IT groups can walk and chew gum at the same time but if they start to stumble they’ll spit out the gum before they fall over. Placing IM in a part of your organization where it can fulfil its mandate is one of the first steps on the road to success.

   Cross-posted to the AIIM ERM Community blog.

   ]]> http://www.c3associates.com/2010/06/where-should-the-records-and-information-management-function-live-in-your-organization/feed/ 0 http://www.c3associates.com/2010/06/the-fundamentals-of-a-successful-records-and-information-management-strategy-part-1/ http://www.c3associates.com/2010/06/the-fundamentals-of-a-successful-records-and-information-management-strategy-part-1/#comments Fri, 11 Jun 2010 04:41:47 +0000 Greg Clark http://www.c3associates.com/?p=542 My two part series on the impact Microsoft SharePoint may have on the information managment marketplace was well recieved so I thought I might try another two-part article. I’ve been thinking a lot lately about the characteristics of successful records management and Enterprise Content Management implementations; why can some organizations successfully deploy ECM where others struggle mightily?

   Much of this has to do with organizational culture and the fit of a particular ECM strategy to the business problems faced by a given organization. Readiness is key as are executive buy-in and a well-chosen and well-implemented tool. But these things can be said for pretty much any software application; if the bosses aren’t onside and a good change management strategy isn’t in place, the implementation will fail.

   Jeetu Patel of Doculabs recently summarized his perspective on why ECM implementations have high falure rates and what you can do about it on John Mancini’s Digital Landfill blog. I highly recommend you read the post and watch the associated slide show. I’m hopeful that my post is complementary to Jeetu’s perspectives.

   So what is it that makes information and records management implementations so special? What challenges do these implementations present that other systems do not? In my mind, there are two big differences;

   1.Information Management hits people where they live, for better or worse. At best, records and information management are tied in with business processes and improves them to the point where users can’t believe they ever lived without proper RM / IM and ECM tools. For example, scanning invoices and initiating an automated Accounts Payable workflow process will make any approving manager wonder why they ever thought hand-coding invoices and routing them in multicoloured folders was a good idea. Same for users of Business Process Management applications like insurance claims processing or engineers using a GIS map integrated with a document repository. On the flip side, ECM asks users to change deeply ingrained work habits. Most of us have been using “File / Save as…” then navigating 10 folders deep on a shared drive for as long as we can remember. While most users don’t like storing documents on their shared drives (often lovingly called the “S: mess”), most will take this over a different structure imposed by an ECM system any day (even when you can prove that it’s actually less work to store documents in the ECM system!). Add to this the complexity that many organizations add by expecting their user community to remember a complex records classifications scheme or other detailed metadata and you have a recipe for failure.

   2.The other big difference with ECM tools is that they are largely optional. An accountant may not like the way the new ERP system works, but she doesn’t have much of a choice when creating quarterly financial statements. ECM systems, while core to many business processes, can often be worked around by users who insist on storing documents on local drives or USB keys. This isn’t always the case, but it crops up most often when phasing out shared drives with ECM systems and is related to the work habits noted above.

   In my next post I’ll talk about what you, the budding ECM deployment guru, can do to overcome these challenges and give your implementation the best chance for success.

   Cross posted to the AIIM ERM Communities blog.

   ]]> http://www.c3associates.com/2010/06/the-fundamentals-of-a-successful-records-and-information-management-strategy-part-1/feed/ 0 http://www.c3associates.com/2010/05/enterprise-content-management-at-a-crossroads-the-case-for-microsoft-sharepoint-part-2-of-2/ http://www.c3associates.com/2010/05/enterprise-content-management-at-a-crossroads-the-case-for-microsoft-sharepoint-part-2-of-2/#comments Fri, 21 May 2010 21:06:24 +0000 Greg Clark http://www.c3associates.com/?p=532 This is the second of a two-part series that summarizes the main points in the ongoing debate about the impact of Microsoft SharePoint on the ECM community.  Last week I reviewed several reasons why traditional Enterprise Content Management vendors will continue to thrive despite Microsoft's push into the ECM space.  This week, it's Microsoft's turn.  As before, my goal is to summarize the key points in the discussion about the impact of SharePoint and allow you to draw your own conclusions.

   Please leave your feedback or comments below, drop me a note on Twitter or feel free to contact me directly at greg.clark@c3associates.com.

   Here are a few reasons SharePoint may become the dominant force in the Enterprise Content Management space. 

   1. SharePoint 2010 is more than just basic ECM.  Where SharePoint 2007 could still be considered "basic content services", SharePoint 2010 has addressed most of the shortcomings that prevented this platform from competing head-to-head with traditional ECM tools.  A couple of months ago I summarized the eight reasons SharePoint 2010 is a true ECM system and based on the feedback I have heard from several of my clients, most feel that SharePoint has reached the tipping point where they will start to seriously consider shifting their ECM platforms over to SharePoint.  For most organizations considering a net-new ECM implementation, SharePoint is often the only candidate, especially where the organization is already committed to the Microsoft stack.  Microsoft has invested heavily in building out key ECM functionality like records management and has significantly improved SharePoint's ability to handle metadata and very large lists, among many other improvements.  The list of functional differences between SharePoint and traditional ECM systems has become so small that traditional ECM vendors will have an increasingly difficult time differentiating their products from SharePoint.  
   2. SharePoint is the silver bullet of user adoption.  User adoption is a challenge that has dogged the ECM industry from the very beginning.  Many organizations feel the only thing preventing ECM from becoming truly successful is a poor user interface that limited user uptake (for an excellent summary of this question, read the wisdom shared by experienced ECM practitioner Mike Alsup, who reminds us that user adoption is about far more than a slick user interface), it seems that everyone wants to believe that SharePoint 2010 is the answer to all of their prayers.  Whether it is or not seems almost beside the point; perception is reality and that poses a big problem for traditional ECM vendors.  The fact remains that SharePoint offers an excellent user experience. To Microsoft's credit, SharePoint has been designed with the information worker in mind.  The tool "thinks the way the worker thinks" and user uptake of SharePoint tends to be quick and requires minimal training. This can pose a problem where the implementation is unplanned, leading to a rapid  proliferation of SharePoint sites and some would argue simply replicating the shared drive mess in SharePoint. However, as integrators and Microsoft partners learn how to plan and govern SharePoint deployments, the intuitive user interface will help SharePoint dominate the ECM space in the same way that MS Office has dominated the desktop.  
   3. Size matters. The sheer scale of Microsoft poses a big problem for traditional ECM vendors.  They clearly can't outspend Microsoft on marketing and Microsoft's partner ecosystem is unmatched anywhere.  In the first part of this two-part series I said that one key advantage for traditional ECM platforms is their strong vertical story. This could be quickly eroded by many of the partners who have built and continue to build tightly integrated solutions suited to nearly any industry you can think of.  Yes, traditional ECM vendors have a head start in this area but Microsoft and their partner are hot on their heels.  Further, there is a wealth of SharePoint information freely available from MSDN, Codeplex and the many thousands of SharePoint MVP and partner blogs and websites.  It seems that if it can be known about SharePoint, it will be available somewhere for free and this will lead to rapid innovation and an improved product.  
   4. SharePoint has a strong social story.  SharePoint started life as a collaboration platform and has evolved from this into a social computing platform. As the demands grow to provide Facebook-like tools in an enterprise context, SharePoint is very well positioned to meet this need. SharePoint may not be best of breed but many enterprises seem comfortable collaborating using a platform from a know n quantity such as Microsoft. To date, the efforts of traditional ECM vendors to "socialize" their platforms have not received widespread adoption and there are questions about their continued desire to play in this space in light of stiff competition from Microsoft.  
   5. SharePoint is much more than just ECM.  SharePoint is a portal, a document management system, a business intelligence tool, a records management system, a social networking platform, a web content management system, development platform and an enterprise search tool.  Many established ECM vendors can say many of these same things, but the Microsoft story is especially compelling for organizations already committed to the Microsoft stack.
   6. Microsoft will win because they're Microsoft.  The intangible advantage that Microsoft has is based on their history. Whenever Microsoft sets their mind to do something, very little will get in their way.  Remember the early days of the relational database wars?  Ask yourself when the last time was that you came across a Sybase database and you have some idea what that might mean for some traditional ECM vendors.   And if you don't think Microsoft is targeting traditional ECM vendors with SharePoint 2010, think again.  With SharePoint 2007, Microsoft started the process of embedding SharePoint into their core Office suite but was clear that most organizations still needed a traditional ECM system for the higher ECM functions. For more on this, see my blog post outlining some of the functional gaps between SharePoint and traditional ECM. With SharePoint 2010, Microsoft has changed their focus from partnering with traditional ECM to trying to out-compete them (of course they won't say this officially but their all-out marketing push at the 2010 AIIM show is a clear indicator).

   I hope this short series has been useful. I'm sure there are other reasons why SharePoint may or may not dominate the ECM space and I am keen to hear your perspective. 

   Please leave your comments below and I will reply as best I can.

   ]]> http://www.c3associates.com/2010/05/enterprise-content-management-at-a-crossroads-the-case-for-microsoft-sharepoint-part-2-of-2/feed/ 0