I was reading a nice blog entry on CMS Watch by Theresa Regli titled The Death of Taxonomies Revisited. http://www.cmswatch.com/Trends/1737-Death-of-Taxonomies-Revisited    There are some very good insights in the article and I highly suggest reading it.  Among the insights is that the title "taxonomist" should be heaped onto the junk pile.  I agree, and prefer the term Information Architect instead, and for a number of reasons.  Standalone content management systems are giving way to true information management solutions that incorporate both structured and unstructured content.  More and more, unstructured content is being integrated with its structured sibling.  ECM systems are being aligned with Business Intelligence (BI) initiatives.  Master Data Management (MDM) is helping to drive information architecture development.  In Theresa's own words, "taxonomists need to adapt and work with technology to improve the results of what they can achieve for enterprises." 

So, does that mean that taxonomies are dead?  Of course not.  It simply means that we need to think more broadly about how people will use information, both structured and unstructured and the relationships that exist between the two.  As for the traditional taxonomy, I don't think those are done any more than I think folksonomies will take over the world.  Are there areas where folksonomies make sense?  Sure.  Are there areas where multi-faceted taxonomies make sense?  Absolutely.  What is right for one company or situation may not work for the next.  Information Architects need to keep an open mind and look at all sources of information available to them. 

The question for me is when the traditional ECM vendors will adapt. With traditional ECM solutions, the question has been whether or not to use folders.  For some users, that's fine, but not for all.  One issue that all taxonomists need to be aware of is how the taxonomies will be implemented within the target content management system.  Having a fantastic mulit-faceted taxonomy is only of value if the content can be easily tagged and presented to the user in a useful, intuitive way.

I'll be at the Taxonomy Boot Camp this week in San Jose, California.  I hope to see you there!

The latest blog entry is actually a guest blog entry.  This time an entry in the AIIM Digital Landfill regarding implementing SharePoint with another ECM.  A few goodies from my experience with implementing SharePoint with another ECM vendor's solution.  Many think it's just about adding a couple fo Web parts, but is it?  That depends...

http://aiim.typepad.com/aiim_blog/2009/10/8-things-to-consider-when-implementing-sharepoint-with-another-ecm-engine.html

Excerpt:
With any ECM deployment, it is important to have a solid implementation plan to be successful.  When combining multiple content solutions, it is critical.  Unfortunately, many SharePoint implementations are more organic than well thought out.  SharePoint sites are often created with little thought with respect to long term use.  As a result, when it comes to linking into another ECM solution, users are hit with unexpected changes and restrictions to sites they have become accustomed to.  Understanding the functionality people use, or expect to use, from each system is vital to the successful blending of the capabilities.  This list of things to consider is not an exhaustive list, but is intended to help get the planning process started...

Some time back, an executive from an ECM company told me that Knowledge Management (KM) just never really panned out.  My response was "Sure it did.  We just call it social networking now."  After all, a major component of KM includes bringing peers together to share knowledge and content around an area of common interest.  Social networks are thriving both on  the Web and within companies around the world.  The whole point of social networking is to add value to the others in the network through the thoughtful sharing of ideas and content such as lessons learned.  That sounds a lot like what we used to call KM.

For example, John Mancini and AIIM International have just recently released a new eBook titled 8 reasons you need a strategy for managing information before its too late .  It's an interesting book for a number of reasons:

• Each  chapter of the book started out as a blog entry submitted by a guest author willing to share his or her experiences with others and thus make it available for peer review
• All contributors share an interest in one or more aspects of information management (ECM, KM, Taxonomy, etc.)
• All of the contributors belong to a common social network, AIIM, and follow John's blog, the Digital Landfill
• I'm one of the authors (shameless plug)

The point is, John and the folks at AIIM created a pretty nice way for peers to collaborate and share ideas.  AIIM members, as a social network of sorts, can challenge and add to the body of knowlege that has been submitted thereby improving the knowledge base.  The Digital Landfill blog provides the technology to enable the collaboration just as tools like SharePoint do in companies around the globe.

I've been fortunate to be involved in a number of KM deployments in my career.  Most of that work has been in the energy industry which has found ways to make KM work quite well and achieve very strong returns on investment.  Creating social networks (some companies call them Centers of Excellence or Communities of Practice) once took a lot of time and effort.  Thanks to tools like SharePoint, social networks are springing up all the time.  Some of the largest companies in the world are now using SharePoint for global KM initiatives.  The challenge many companies face with SharePoint is the increasing number of silos of knowledge.  The trick is to encourage the collaboration and social networking while creating a common framework that enables networks of networks for true, global knowledge sharing.  For that, you need an information architecture.  That's a plug...read the book.  And not just my bit.  There's a lot of great information in there.  I think you'll like it.

Best,
Michael

There’s a lot being written on Enterprise Content Management (ECM) governance these days.  Just about anyone who’s implementing SharePoint has been told that a well defined governance program is a must.  To that end, there are plenty of free resources to be found regarding SharePoint governance which can be used in helping to define a well built, and fully encompassing ECM governance plan, even if you’re not using SharePoint.  It should be noted that, while these templates are a good place to start, they are not in themselves complete enough to provide a true ECM governance program.  There are a few elements that must also be taken into consideration that are dependent upon the organizations implementing them.

Enterprise vs. departmental deployments

Many companies have been able to get by without a true ECM governance program due to the fact that the existing deployments were departmental in nature.  Changes to the system were driven at the departmental level, along with IT involvement.  The impact of the changes had no impact on other departments.  With SharePoint however, numerous departments are typically deployed and, as a result, the IT department must interface with more areas of the business.  Changes to one area have a strong likelihood of impacting others.  While it’s very convenient for the department to own their technology and dictate the usage of their own systems, that approach is inefficient and detrimental to an enterprise-wide information management strategy.  The fact that SharePoint governance is such a hot topic has a lot to do with the technology, but also that enterprise systems require more cooperation than do departmental deployments.

Effective ECM Governance must include the business side of the house

A key lesson learned from the departmental deployments is that the getting the business involved is critical to the ongoing viability of the system.  While the IT organization may have the database architects, taxonomists/information architects, systems analysts and others needed to maintain the systems, the business users still own the responsibility for how they interact with that system.  If there is a change to the information architecture, it’s normally because the business requested it.  For example, if a new metadata field is requested, it’s not because IT wanted it, but rather because the business needed it.  Another benefit of bringing the business into the process is that, when changes are requested, it’s easier to communicate the impacts of those changes to the other members of the business community.  A change requested by one business group may negatively impact other business groups.  The role of the governance program is to ensure that changes are handled in an orderly way and do not negatively impact other areas of the business.

Executive sponsorship is critical

As they say, if it’s not important to the executives, how important should it really be for anyone else?  In this case, the executives must also include the business, and not just IT.  The reason that executive sponsorship is so critical is that changes cost money.  It’s the role of the executives to provide the proper funding to ensure the ongoing viability of the platform.  It’s also the role of the executives to act on change requests that are controversial.  The business and IT organizations can and will request changes that may not make fiscal sense and “no” is a perfectly acceptable answer, though not always the right one.  While many of the free templates describe the importance of executive sponsorship, they do not and cannot know who the best sponsor is within the company.  Corporate culture and personnel dynamics will play a role in determining who are the right people.

Governance is an inclusive process

In developing compliance programs, I like to use the RACI (Responsible, Accountable, Consulted and Informed) process.  The success of a governance program is dependent upon the how well the roles, policies and procedures are defined.  It’s critical to understand, for any change that will be made, who is responsible for making the change.  What is often missing in governance programs, especially when one considers enterprise deployments, is the determination of who should be consulted before making a change and who needs to be informed that a change has been made.  Every company has subject matter experts who may not be a part of the governance body, but exist witihin the business community.  Those people should be included in the governance process.  Those individuals may not specifically own the element of the system being changed, but they may interact with it and be impacted by the change.  Bringing subject matter experts into the change process will greatly improve the impact of the changes on the user community.  With that said, it is important to limit the number of actual decision makers.

Summary

There’s no one-size-fits-all program for ECM governance, but there are some great free tools out there, specifically on the SharePoint side of things.  They can help get a jump on defining a governance program, but don’t necessarily take into consideration the importance of bringing the business into the process.  In the case of a blended SharePoint and traditional ECM solution, there is a lot to be gained as well.  Governance programs will vary from company to company so finding the right fit may take a little bit of trial and error.  Then again, that’s what governance is all about…managing change.

It seems as though almost every company I talk to these days has SharePoint installed somewhere.  Most of those companies already have at least one other ECM solution installed so all of those new SharePoint seats are being implemented instead of an already established ECM solution.  In fact, in many of those companies, the number of SharePoint users now greatly exceeds the number of users on the traditional ECM solution.  In just a few short years, SharePoint has gone from the scrawny little kid to one of the bullies on the ECM block.  How did this new kid on the block get to be such a force and what does it mean to existing ECM vendors?

Traditional ECM’s ERP-like model

Many major ECM companies have modeled themselves after ERP companies (or are ERP companies).  Just as customers would say “we’re an SAP shop” or “we’re an Oracle shop,” ECM vendors wanted to be thought of in the same light, and in some respects, they were.  With a high per seat cost and a deployment model that often required a small army of consultants directly from the vendor, ECM vendors were a lot like their ERP counterparts.  Is it any wonder ECM deployments often stalled after the first department?  Companies often spent considerable sums of money just to train a small group of individuals who would then be responsible for maintaining what had quickly become a one-of-a-kind solution, driving up the costs even further.  While this model sustained the ECM vendors, it was not a model that led to explosive growth.  Few companies that have purchased enterprise licenses from a traditional ECM vendor have actually deployed them to the entire company.  Studies by Gartner and AIIM affirm that few companies have any strategy for enterprise ECM deployments and less than half of most company’s information is actually managed by an ECM solution.  All of this led to a large opportunity for a player willing to take a different look at how the ECM market works.

The SharePoint model

If there’s one thing that can be said about Microsoft, they plan for the enterprise.  SharePoint has been able to reach a much broader audience even though it lacks many of the features offered by traditional ECM engines.  SharePoint has excelled at exploiting the holes left by the traditional players.  After all, if less than 45% of a company’s information is currently managed, users will have a difficult time finding what they need.  When a tool like SharePoint comes along that provides users the ability to quickly and easily capture and share the information that is important to them, they will embrace it with gusto.  Consider the following:

·         SharePoint provides adequate collaboration features without having to purchase an add-on.  This includes simple collaboration workflow capabilities, and content sharing capabilities.

·         Standard templates are provided to quickly and easily create sites to meet the needs to teams and projects.  These templates allow the site creators to very quickly deliver a working site and still have the ability to give it a custom look and feel.  Features are easily added without requiring a team of developers which is why SharePoint has become a focal point for social networks and other knowledge based applications.

·         Content libraries are easily added to enable content collaboration.  This has both good and bad implications, but from a user’s point of view, having access to a site where they can put information that they can share with their peers overrules the need of the company to control content silos.

·         Microsoft has a very large and robust partner program that encourages innovation.  Traditional ECM players have not encouraged the same level of innovation and, in many cases, have discouraged partners by pulling services in house.  As a result, SharePoint resources are relatively easy to find and new solutions are continually being developed for the platform.

Back to the traditional players

While SharePoint’s features have been good enough for most users, they’ve not been good enough for all users.  As a result, many companies that had been pushing to standardize on SharePoint across the enterprise have had to scale back and re-incorporate traditional ECM players within their plans.  The question is, for how long?  What can the ECM players of today do to ensure their value in the SharePoint world?  All of the ECM players now provide some integration with SharePoint.  The initial assumption was that users would collaborate in SharePoint and then move the documents to the ECM engine.  This leaves the traditional ECM player serving as nothing more than repositories for static content and as the records management solutions in the near term.  Is this a viable long term strategy?

What’s next for traditional ECM COMPANIES?

What happens next is yet to be seen.  Microsoft will continue to add functionality to SharePoint, and as they do, the gap between SharePoint and the traditional ECM players will continue to narrow.  Where does that leave traditional ECM players?  A few possible thoughts:

·         If a Web Part provides access to a repository where users can store and collaborate on content, does it matter if it comes from Microsoft or an ECM vendor?  ECM vendors should be looking to expand the capabilities of their SharePoint interfaces.  The strength of these vendors lies in the robust capabilities of their repositories rather than their user interfaces though they are doing all they can to play catch up.  Rather than promote the use of document libraries, ECM vendors should be making it easy for users to have full access to a robust, proven ECM repository and doing that transparently. 

·         Embrace the flexibility and openness of SharePoint.  It should not take a team of professionals to stand up a new site.  SharePoint has benefited from having an easily customized and tailored interface that just about anyone can use.  As a result, users have been able to create new and unique ways to use the product.  The ability to “make it their own” has had a definite impact on the adoption rate of SharePoint in general.  ECM vendors need to encourage that flexibility and creativity within their own solutions.

·         Focus on the enterprise.  ECM vendors have become accustomed to selling departmental solutions rather than enterprise infrastructure and they’re not using all of the tools in their toolbox.  The big players bring a lot of capability to the table including solutions for data management and business intelligence that would greatly improve the ability to deploy ECM to the enterprise.  All too often though, these product groups are segmented and know little about each other’s products and how they relate.  The big vendors need to encourage collaboration across product lines develop solutions that benefit the client and assist in enterprise deployments.

·         Provide the SharePoint Web Parts as a core component and not an add-on.  In other words, don’t promote the use of SharePoint document libraries, making it easier to exclude the use of the ECM repository unnecessarily. 

·         Interoperability is a two way street.  If I like a certain SharePoint feature, can I incorporate it into the vendor’s interface?  When someone provides a better interface that lets me continue to use the features I like, I’ll be more likely to transition.

Conclusion

There’s a lot of change in the ECM realm and the future looks very bright.  SharePoint is obviously not driving all of the change, but it is definitely having an impact.  Changes to ECM user interfaces will continue as vendors seek to keep pace with how users access information.  Vendors who embrace enabling technologies such as data management and taxonomy management will enjoy an advantage over point solutions in the quest for the enterprise.  With a new release of SharePoint on the horizon, the next twelve months should be fun to say the least.  

Well, after a bit of a break from blogging (selling a house and moving is a bit time consuming), I'm back at it.  This time, I did a guest blog spot with AIIM.  Here's the link in case you're interested...
http://aiim.typepad.com/aiim_blog/2009/08/8-things-you-need-to-know-about-developing-an-ecm-information-architecture.html 


Cheers!
Michael

In all of my years of in the knowledge, content and records management space, I've run across some pretty elegant implementations and some pretty bad ones.  These days, a lot of my clients are the ones who need help recovering from the latter.  One of the issues is that, while we call it Enterprise Content Management (ECM), the "enterprise" aspect is clearly lacking with most implementations.  Traditionally, ECM systems have been quite costly and difficult to implement.  As a result, most ECM solutions were either departmental or, in most cases, just point solutions such as image enabled Accounts Payable.  While these systems may have met the needs of the single department, they did not scale to the rest of the enterprise very well.  To make things worse, in many companies, each department often implemented their own unique system to ensure control of their content leading to numerous isolated silos of content and no cohesive information management strategy. 

Findings in a 2008 AIIM  report  titled "Findability: The Art and Science of Making Content Easy to Find," noted that 69% of respondents believe that less than 50% of their organization's information was searchable online.  My guess is that the number would actually fall well below that 50% number.  Unfortunately, many employees don't know where to find the information they need.  What's worse, those that do know where it resides often simply don't have the access.  There are a number of reasons for this:

• Each disparate content system has its own unique information architecture
• Each system likely has its own search engine, not linked to any other system
• Each system had its own security model with different levels of security for different components of the system

Enter SharePoint
In part because of the cost of ECM systems, and in part because of their difficulty to deploy, many companies have turned to Microsoft's SharePoint.  A relatively low cost solution which is easily deployed, and perhaps too easily.  At last, departments could have quick and easy access to content repositories the problem was solved...right?  Well, not so fast.  Many companies that decided to replace their ECM systems with SharePoint discovered that the functionality just wasn't yet there for what they needed.  Now, instead of replacing the ECM system, they're needing to augment that system.  Instead of solving the problem, what many of these companies have done is compound it.  A new, unique information architecture and a new information governance headache that is widely documented by IT organizations around the world.  How do we alleviate this headache?

Putting the "Enterprise" back in ECM
One thing we do know is that companies will continue to deploy ECM solutions, including SharePoint, at the departmental level.  It's always important to control the deployments to ensure success.  Before the deployments begin though, some strategic planning will go a long way.  Lack of planning surely leads to chaos.

1)  Scalability:  When it comes to sizing the system for growth, most vendors will have benchmarks to help you determine the system elements you'll need to scale to the enterprise.  That includes elements such as the amount of disk, the network throughput, server specifications and the like.  A good Systems Architect will help determine the requirements.  Planning for growth at the beginning will prevent costly upgrades later.  This is one area that most companies do reasonably well.

2)  Design the foundation:  One would never build a house without a good blueprint, but for some reason, ECM systems aren't treated the same way.  The best thing one can do is to truly understand how the content will be utilized within the company.  It is critical to understand how users expect to interface with the content.  All too often, ECM Requests for Proposal are nothing more than feature wish lists without a clear understanding of how the information will be used.  Before the deployment begins, it is important to have a solid information architecture defined which incorporates the records management requirements, search and browse requirements, taxonomies and metadata standards.  If available, use existing information discovery tools and Master Data Management (MDM), efforts to assist in the information architecture design.  Also, be sure to include the records organization as well as impacted departments in the design process.

3)  Readiness Assessment:  Before deploying the system, it's important to have a deployment roadmap.  Which departments are the most likely candidates for the initial deployment?  Is the records retention policy complete for all departments?  Which departments have a strong understanding of how the information is accessed and utilized?  Which departments have a strong understanding of the technology?  Are there other projects that could impact any particular group's involvement?  There's plenty to consider when determining any department's readiness, but it will help with setting expectations and ensuring a quick win with the first group.

In the coming weeks, I'll be blogging on each of these topics in further detail.  If you need more information on any of these areas, feel free to give us a call.

Best regards,
Michael Elkins

If you're like many of my clients, you're implementing SharePoint along with one or more existing ECM solutions.  In some cases, clients want all of their content in the ECM engine either to take advantage of their existing records management programs or simply for consistency.  Others want to use the document libraries in SharePoint for all of their collaboration and project efforts, migrating records later when needed.  Every company is different so how SharePoint is ultimately linked to the ECM system depends upon the requirements of the client, but here are a few things to think about as you get started:

1. A consistent user experience:  SharePoint sites are very easy to create.  As a result, just about anybody can and does create unique sites.  If you want consistency in how sites are created and where content resides, you will need to have in place a governance program for your SharePoint system.  That governance program should be an extension of the ECM governance program you already have.  Since most companies don't have a governance program, Microsoft publishes a number of templates to facilitate the whole thing.  The big win here is, you'll want to make sure that your content resides where you need it to, and it's classified the way it should be.  That may mean limiting who can create sites or how sites are created. 
2. Know the functionality of your Web Parts:  Most ECM companies now provide Web Parts for SharePoint that enable users to access content that resides within the ECM engine directly from SharePoint.  In most cases, this functionality is limited so I suggest you have a firm grasp on what does and doesn't work for you.  For those who want to ensure all content resides in the ECM, make sure you have the capability you need in the Web Part to accomplish that requirement.  In most cases, the capabilities of the Web Parts are very basic.  While you're at it, make sure you are fully aware of the SharePoint document library functionality you're giving up as well. 
3. Does content start in SharePoint and move to the ECM?  In most cases, the ECM vendors provide a method for content to be created in SharePoint and then pushed to the ECM engine at a later time.  That "push" process will often leave a pointer in the SharePoint system so that users can still access it from the SharePoint document library.  That's fine if SharePoint will always be your user interface, but in most cases, that isn't true.  Consider the following:
   • If you need to migrate content from file shares or other systems, that content is mostly likely going to be migrated directly to the ECM engine.  If the migration is not pushed through SharePoint, the SharePoint system will not likely have any awareness of the migrated content because it did not go through that push process.
   • Content that existed in the ECM engine prior to implementing SharePoint may not be visible from the SharePoint engine for that same reason.  That leads us to search or browse...
4. Is it a document or a list?  Some content in SharePoint is considered to be a "list" rather than a document.  Most ECM engines understand documents in SharePoint...but not lists.
5. What about search?  Where will your users be searching from?  Does your vendor provide a search Web Part for SharePoint?  Does that Web Part allow you to search both the ECM and the document libraries and return one result?  Separate results?  Can I search from the ECM interface and still find content in SharePoint document libraries?  Part of the answer lies in your search strategy, but you should also consider what your primary interface will be.  If users will use both the ECM interface and SharePoint, you'll need to determine if the search experience needs to be the same from both.
6. Are your information architectures consistent?  If you do push content from SharePoint to your ECM engine, are your information architectures and taxonomies in alignment?  Is the browse experience the same in SharePoint as the ECM engine?
7. Don't forget about Security:  One thing to consider is the alignment of the security models between SharePoint and the ECM system.  Are they the same?  Should they be? 

There are a lot of options when considering your combined SharePoint and ECM solution.  The good thing is that you have options.  It will require strong planning and a bit of communication with your ECM vendor to ensure the functionality you need from the SharePoint connectivity tools meets your needs.  While Microsoft provides nice templates to get you going with SharePoint governance, you'll need to ensure that your governance processes encompass both SharePoint and the ECM system. 

I hope this information helps

Michael

www.kestralgroup.com

 

Do you effectively manage change to your content management system?  Anyone who is implementing a SharePoint system has likely heard the horror stories about what happens when you implement without a well developed governance plan.  Even Microsoft is adamant that governance is needed and posts even plenty of free reference and template information to get you started (see below).  So what is this governance thing and why is everyone so focused on governance these days?  The answer is that change is inevitable and, in the past, companies have not done such a great job of managing that change.  Another key aspect of IT/data governance is the alignment of IT with the business to ensure that the organization’s goals, objectives and strategies are created, sustained and expanded upon.  I’ve seen far too many companies where the IT group is not so affectionately known as “those people.” 

Many companies, and specifically those whose stocks are publicly traded, have some form of governance in place related to compliance requirements such as Sarbanes-Oxley, but typically don’t cover the full scope of the ECM system.  What everyone should know is that when ECM systems are installed, the fun has just begun.  For example, information architectures change over time.  Taxonomies are added or modified.  Metadata fields and their associated values also change.  If companies have implemented any thesauri, those will likely change or expand.  Unfortunately, in most companies, the impact of change is often not known until after the change has been made and the impact ripples out through the organization with “those IT people” getting blamed when things break.  In addition to the impact on end-user satisfaction, the cost impact of correcting mistakes after they’ve been made is substantially greater than finding the mistake before it has been rolled out to the entire organization.  Planning for change greatly reduces the number and impact of those mistakes.

If you are just starting to develop a governance system, start small.  It may take a couple of trial runs to identify the right governance process or model for your organization.  Just as with the ECM system, change is a natural process.  When developing an effective governance program or process, these key elements will help you be successful:

1)      Get executive buy in:  Any effective governance body must have senior executive buy in.  Their role is ultimately to guarantee that the resources, including people and funding, are in place to ensure the ongoing viability of the system.  In some cases, requested or needed changes to the system will require funding that was not planned.  Hard decisions will need to be made, and senior leadership will need to be involved.  Failing to plan for change is planning for failure.

 

2)      Identify the components of your system that are likely to change and who owns each component:  Most companies have a pretty good idea of the system level changes such as performing upgrades, adding servers or patching the system.  Where most companies fall down with respect to the governance of their ECM systems is with the information architecture.  Most companies don’t have well documented information architectures, let alone the procedures to manage the ongoing changes.  When they are well thought out, changes to taxonomies, metadata elements, dropdown values and thesauri can greatly improve the effectiveness of the system.  When done haphazardly, changes to the information architecture can be very costly and render the system virtually useless.

For system level changes, IT often owns the process.  For example, when a patch needs to be applied to the system, it is typically IT involved in applying the patch and ensuring some level of testing takes place, even if the users are doing the testing.  That's not always the case when it comes to the information architecture.  For example, when a change is requested for a metadata element, the request will typically come from the business and not IT.  The business plays the key role in determining what the change is and how it is implemented.

 

3)      Involve the business:  IT may take care of the system, but at the end of the day, the users come from the business side of the house.  While the system resides in IT, the data belongs to the business and they must be an integral part of the change process.  Involving the business in the ECM governance process ultimately saves the company time and reduces the overall support costs of the system.

 

4)      Identify the key roles:  While it is important to identify who is responsible or accountable for an element of the system undergoing change, it is also critical to identify others who would be impacted and should be informed of any pending change.  Both in the IT organization and within the business, there are people who are considered subject matter experts who should be consulted.  As you may have guessed, I’m a strong believer in building RACI charts which identify, for each step in the change process, the following:

·         Who is Responsible for completing that step in the process

·         Who is Accountable for ensuring that step is completed

·         Who is Consulted prior to the completion of that step

·         Who is Informed of the results once that step is completed

The process of developing the RACI charts will force you to really look at your processes and identify the people, not only in IT, but also within the business to ensure a strong alignment.

5)  Determine who gets a vote:  The more people at the table, the harder it is to come to a decision.  Identifying a small team of individuals comprised IT and business leaders who are responsible for approving changes to the system.  This group of “voters” must represent the best interests of the company and rely on input from subject matter experts and key business users to determine the ultimate outcome of a change request.  The RACI process helps to identify the key business users and subject matter experts who will assist the voters with their decision process.

Governance is about managing change.  Effective governance requires a strong understanding of what can change, will change and who is impacted. 

Additional Information and Resources:

Microsoft SharePoint governance information

http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx

 

The IT Governance Institute

http://www.itgi.org

 

Information Management (formerly DM Review) is a great source for information

http://www.information-management.com/channels/data_governance.html

Every year, companies waste millions of dollars because of the poor quality and usage of their data.  I can’t begin to tell you how many new credit card applications I’m offered from companies that should know that I already have the very card they’re offering me.  In most cases, the data exists to eliminate the waste, but it’s highly likely that the data exists in multiple systems and are described differently in each one.  To solve this problem, companies are now turning to Master Data Management (MDM) tools to improve data quality and usage.  Among other things, MDM tools allow companies to do the following:

·         Identify and map the numerous disparate data sources that exist throughout the enterprise.

·         Consolidate data sources when it makes sense.

·         Normalize data sources to ensure that metadata elements share common names, definitions and even values across systems.

While these tools have provided tremendous gains in data quality and usage for ERP and CRM systems, they rarely find their way to the ECM systems that have typically been implemented at the  departmental level.  It should be noted that the departmental nature of ECM systems has also led to companies often having multiple disparate systems, each with its own information structure.  In cases such as these, MDM tools can greatly reduce the cost and time needed to consolidate these systems or, at a minimum, normalize the information architectures to allow for greater interoperability.  The same can be said for consolidating systems following a merger or acquisition.

Thinking about the deployment of ECM systems, consider that, although, one of the first things companies do before implementing an ECM system is take an inventory, that inventory usually consists of identifying only the content to be captured and not the metadata that exists elsewhere that could and should be used.  Understanding the definition of metadata elements is critical to the quality and ease of integration.  If “Customer Name” is defined differently in each system, the ability to utilize the data across platforms is much more difficult and time consuming if it is possible at all.  In many cases, metadata dropdown values are already defined in ERP, CRM and other core systems.  Creating new, different dropdown options only decreases the overall quality and increases the long term costs of using and maintaining the system. 

Clients who already utilize a master data model and who include it in their ECM architecture will quickly realize a number of core benefits including:

·         Faster deployment of ECM initiatives

·         Improved findability of content due to data quality and standardization

·         Greatly facilitated application integration due to common data definitions

·         Reduced training costs and an improved user experience

·         Facilitated consolidating or normalizing systems

·         Enables ECM metadata to be easily included in Business Intelligence (BI) initiatives

However, even without the MDM tools in place, a metadata inventory is still a highly recommended practice prior to building any ECM information architecture.  Alignment with core systems is critical to the success of any enterprise capable deployment.