Best Practices for Leadership in Content Integration

 

Content integration is becoming a hot topic lately as organizations start to link their content/document/records management systems with other enterprise applications such as enterprise resource planning (ERP) systems.  This is uncharted territory for most companies and you need to be wary of the "there be dragons here" zones on this map.

 

For a manager who is planning an integration for transactional systems such as SAP or Peoplesoft with something like Documentum, LiveLink, FileNet or SharePoint it is very wise to plan such a project properly, using subject matter experts where appropriate, finding sponsorship and creating realistic budgets and plans.

 

Here are my top best practice points:

 

1) Find appropriate sponsorship for the project.  For example a Director of Supply Chain Management would make a good sponsor for a procurement system integration between SAP and Documentum.  Neither one of these systems is simple or easy and both are very powerful and adaptable systems.  The business processes may be more complex than you realize initially and subtle process changes can have serious impact on the project during deployment.  It pays to have someone where the buck will stop and who owns the responsibility and benefit for the project to steer it through any trouble spots it may encounter.

 

2) Plan a design phase and include SMEs early on.  Make sure you allocate sufficient time, resources and budget to analyze the integration projects early on.  That should include a project manager, senior business analyst(s) familiar with the process or similar ones, plus architect level representatives from the respective technologies involved such as PeopleSoft, Documentum and, also last but certainly not least, representatives from the business units involved.  Perform a 360 degree view of the business process contact points where you talk to associated business units that also use the system to perform pre and post processing of the information or who touch the process or systems in some way that may have impact.

 

3) Take it up a level and sell the concept.  If you look at the immediate contact point for the integration without considering the bigger picture you may be found on a poster of 5 blind men groping an elephant and declaring it to be several different types of animals.  It helps plan on talking to other business units early on and describing your integration.  You may be surprised to find synergies in other departments that can help fund the project.  However the flip side of that benefit is that you need to consider what they will need in your design phase so you don't end up designing something incompatible with their needs.  If you miss this you can end up with a one-off solution that can't be leveraged by anyone else in the organization or possibly causing delays and extra costs in later phases of the projects when they get around to the other business units.

 

4) Include SME's where appropriate.  Most if not all enterprise applications are highly complex applications where an expert can earn a living doing just one application focus.  For example, within SAP you may have SRM and PI specialists, or in Documentum you may have web content or records management specialists and the same goes for Oracle and Websphere to name a few.  Don't make the mistake of allowing an SAP developer say "Documentum is just a black box storage repository so I will just write a web service for it".  The same goes in reverse of course so engage a specialist on both sides of the integration in your project, including design, so you get the best solution.  If you don't have them in house hire them outside.  Some of the best "top guns" are available for hire on short term contracts.  One bonus of an outside consultant is that they can bring new ideas from their experiences in other organizations and they tend to be politically neutral.

 

5) Let each application do what it does best.  For example, use the EDMS systems to do EDMS things and use ERP systems to do the transactional things.  The respective systems may have some cross over in capabilities but if you leverage the core strengths of each program you will have the most robust and scalable system later on, plus you will be achieving better ROI on each system by utilizing it for the purposes it was created and subsequently purchased for.

 

6) Focus on the user experience.  Talk to the users early on.  If they like using SAP for invoicing then leverage it for the workflow and plan the integration around it.  If they hate it or don't use it much then try the EDMS workflow capability.  There are many alternatives and even specialized workflow applications.

 

7) Think out of the box.  This is new territory and you don't have to take the vendors word for it on how things should be done.  One can always listen to various points of view but feel free to chart your own course.  One example is that you can now integrate workflows between various systems.  You can fire an event in another system's workflow based on a workflow in a source system.  If you design asynchronous integrations where the two systems can work independently of one another and still exchange information as required then you can remove future dependencies and hang ups on future upgrades, migrations and new modules, etc.  It takes expert help to design and implement these solutions but it is worth it.

 

8) Do the data mapping early and in detail.  In order for data and content integration projects to go smoothly you need to have the process and then data mapping done in detail and well documented.    Web services are great tools but they are not that easy for administrators to deploy and integrate after the fact.  The well worn phrase "Do it right the first time" is a rule to live by.  These things will change over time.  The process may change and impact the use of the system.  New data fields may be required in or or more systems which will impact the integration.  All of these sorts of contingencies must be kept in mind for the maintenance and upgrade phases of your project.

 

9) Plan forward.  Knowing that the business will change and resources and updates to the system will occur is important in implementing such integrations.  I have run into so many projects where, one month from completion of a deployment, someone says " Oh and what about this legacy integration?".   You need to have budget for maintaining integrations for the life of the system and sometimes beyond.

 

10) Build it adaptable.  The more you plan for adapting the easier things will go for you in the future.  As a manager if you implement a bunch of poorly planned integrations to enterprise systems, you had better plan to be working somewhere else by the time you need to upgrade them to match a changed business process or feature request.  We tend to anticipate having configuration changes and using asynchronous processes with configurable settings.  XML files with server names, user names, encrypted passwords, security defaults, etc. can be a huge help in migrating integrations to new servers and repositories, etc. without having to call the programmer (if you can find them) that wrote it.