OpenText and Documentum and Content

Who would have thunk that these two ECM giants would be under the same roof? OpenText is obviously paying a premium for Documentum for its clients and solution services. The dashboard level of this deal must look excellent, however the details of the next 5 years of execution will be interesting. The media’s favorite go to pundit for reactions to Documentum events, John Newton (cofounder of Documentum), says “the product lines will wither away” amid neglect from OpenText in favor of their own ECM solutions. This sounds about right, but maybe OpenText has higher goals beyond the software and solutions, toward the content and process.

It’s not about loyalty

Some folks characterize Documentum’s customers as being loyal. I don’t buy it. Most of the original proponents of Documentum in these companies have moved on to different positions. This is legacy software now in many large companies who’ve had it installed for over a decade. It’s a matter of risk analysis now, not loyalty. Point or more integrated solutions are stepping in and sweeping away the new projects.

Depends on the Industry

Of course, Documentum has its tentacles more into certain industries than others. For example, pharmaceutical companies have relied on custom solutions from Documentum for a while now. With 21CRF regulations controlling content, the move to any other solution will be extremely painful. On the other hand, OpenText has its share of pharma clients as well. Maybe the strategy is to hone in on the huge money maker industries only and dump the rest?

Storage

I’m not sure either platform will supersede the other. For years EMC threw in Documentum as a bonus to its storage solutions. What does this mean? Well, at the metadata architecture and storage level it means that not only OOTB applications, but custom apps and integrations are dependent on the storage addresses. This will be no small feat to migrate to OpenText. I believe Documentum was slowly sinking into EMC’s storage hole anyways. My experience migrating AppExtender files to OnBase is a good example: the content was in blobs with links for Cerner to them. We had to leave the links in place and move the underlying content pointers. We lucked out with this approach, but it left me wondering how other companies deal with a more comprehensive migration.

Older, Large Documentum installs

I have seen multi-tiered, multi-year upgrade and migration plan for large installs of Documentum. The scale of internal Documentum knowledge needed to pull this off, year after year, is daunting. To ask these resources to then switch to a different ECM solution requires years of preparation and training. I worked for EMC as they were implementing Documentum solutions across their enterprise and it was painful even though EMC owned them!

Upgrade pain level

Having worked on both Documentum and OpenText solutions, I can tell you that both of these platforms are difficult to upgrade for different reasons:

OpenText patches and steps and bugs

At a pharma company, I worked on upgrading OpenText for a year and the project was postponed because our upgrade process was not complete and it still took too long to fit into the downtime outage window. This type of story sometimes happens with all large software installs, however the amount of kludgy patches that had to be applied during the upgrade was disconcerting. The steps of the upgrade for both the code base as well as the database changes were way more complicated than other packages. This software upgrade process can make you understand why some CTOs do not advocate upgrading anything unless it is faltering.

Documentum customizations and changes

Most Documentum installs have some or extensive customizations based on the WDK and DFC development. These APIs were excellent at the time. Over time, methods get deprecated and maintenance gets more expensive. Then, after a few years, you have upgrade. This can be a daunting process, even when it’s you who knows the software inside and out. Finding documentation which is specific to the development and changes is probably buried inside the code. This means you have to understand the older and newer APIs. Adding a migration to OpenText on top of this is a nightmare.

Content is King

Coming a full circle on understanding what is most important in the ECM game, maybe the unstructured and structured content itself (and mining it) is the most valuable asset after all. In the next decade, we’ll see. 

Big Data Delays the Inevitable

Just because companies have cheaper storage hardware and more computing power it doesn’t mean they have to spend their savings on Big Data solutions. Most IT shops know their content better than their CIO thinks they do, plus it’s sexy to boast of a Big Data search engine applying algorithms to discover more revenue opportunities. For example, finding potential ICD10 billable work in doctor’s notes at a hospital.

But, aren't most Big Data solutions masking poor information management of the past? Is it really trying to help create better tools and quality control for potential negligent information processing?

In CIO (March 16, 2016) “Is Enterprise content management becoming obsolete and irrelevant?” article, Mitch De Felice builds on the common lament of AI and Big Data marketing that most data is unstructured. Unstructured by whose definition? I’ve seem search algorithms be applied to very structure databases to mine for gold. Some algorithms are benevolent, others are malignant. Some search for patterns and breakthroughs, others for revenue opportunities.

Mitch says, “ECM vendors need to shift their view from data storage to knowledge management.” This has been happening for 30 years. It’s not easy to squeeze knowledge out of “just good enough” data entry. ECM vendors have from day one been offering workflow, indexing, relationships between content and metadata, etc. It’s more fruitful to why “knowledge workers” continue to drag their feet and purchase only the bare minimum of ECM modules.

Inevitably, multiple waves of information management process overhaul will happen. These waves will force much more structure underneath the software tools. Big Data is the option now because most companies are stuck with poor information QC on top of applications that are expensive and difficult to change quickly, let alone retraining Users to provide more knowledge.

What is Your Company’s ECM Narrative?

Does your ECM system have a story title like, “Doc Repo” or “Approval Center”, or is it called by its vendor name? Even a generic name is better than the vendor’s name. A unique name gives the solution an identity. This identity could help expand the solution to other areas of the company. Some companies adopt an IT pet name for their systems and solutions, but many others just call their HR system, “PeopleSoft”, or their ERM system, “AllScripts”, etc. These names just promote the vendor, not the unique solution.

IT Management

Is management creative with IT applications? Is your Director a story teller? Although ECM can survive on the ROI story, it could thrive on stories of larger scale and transformation. If the core driver of the solution’s interests and energy is apparent, why not tell a story around that?

Mission Statement

These statements are created and posted on the wall. They can be inspirational like Google’s, or more down to earth. Regardless, the naming of the IT solutions should reflect the tenants of the company’s mission.

Try to come up with for your ECM solution

First, is there a story of the solution which everyone can relate to? If the majority of the content is based around patient information at a hospital, shouldn’t the story of the system reflect that? For example, “Patient Care Depot.” I know, this isn’t very good, but you get the idea. With a solution name comes the reasons why there is a solution and it’s benefits, not only for IT workers, but for Users and the population or problems it solves.

Second, You’ll need to “balance the flexibility required for innovation with the routinization needed for ongoing operations.” (Tushman and O’Reilly 1996). You can’t create a completely new story which makes no sense or is too obtuse. The purpose of the system name and stories is to bring disparate, silo oriented, groups together with a common understanding of the solution.

The role of translation

The translation of an ECM vision to the specific company’s unique processes and culture can be challenging. A translation implies ‘displacement, drive, invention, mediation—the creation of a link that did not exist before and that to some degree modifies two elements or agents” (Latour 1994, p. 32). With a story, the translation of the system’s benefits can be made more relevant to the varied groups: Accounting has different perspectives than Marketing, but they both need to manage their content.

Transformation

A narrative needs to be transformative:  “Transformational innovation requires offering or doing something fundamentally different; a metamorphosis most organizations don’t excel at. Such innovation is disruptive because it introduces products and services that change the business landscape by providing a dramatically different value proposition. And championing transformational innovation involves going to war with all the elements inside an organization that benefit from the status quo.” (Stephen Denning)

There’s always a beginning, middle, and end of stories. The ECM solution is the middle of an ongoing story. It doesn’t end, it just morphs into another solution and narrative, like Star Wars.

Where large company CMS and ECM solutions Intersect

Wouldn’t it be great if your company could combine the parallel efforts involved with development and deploying internet/intranet/portal websites and document management/workflow systems? Below are some intersections that might help with synergies.

Expectations

Have your integration requirements clearly stated, understanding that there will be performance, security, and functional limitations.

Intersections

Easy

Links to document management application

·         This involves publishing links to documents (with some descriptive metadata) from a backend ECM solution to the Portal for presentation. This link serves up the document in the User’s client, usually in its native format and application.

New browser window from portal link

·         Link from Portal to ECM web solution (assuming SSO is setup) and new window frame. This would allow full access to the functionality and breadth of the underlying application.

     Moderate

CMIS

·         If this is offered, it could be a way to perform basic import/export operations with documents.

Web services

·         Larger ECM solutions will offer web services access. The question is to what extent. Short are building your own custom services using the native API, this could provide enough integration.

     Difficult

Search

·         The scoping of the search criteria, or limiting the search by doc type/metadata values across solutions.

·         Complex search, such as below, are difficult to integrate at the portal level, unless there’s a solid integration between the systems.

o   Fuzzy

o   Sounds like

o   Term proximity

·         Searching indexes and presenting results within a single portal can pose many issues around performance and access control.

     Round About

Through a two-step publishing process

May your CMS has out-of-box connectors to the most common business ECM solutions, like Sharepoint. This could open an opportunity to use Sharepoint as a surrogate repository, where both solutions connect to it, offering up common functionality.

“The Vendor Said”

A vendor’s hyped up solution offering of 5 years ago, might be almost forgotten now. This could mean that, although your product offers a module for CMIS, they implementation and support has waned in the past. 

ECM Upgrade Best Practice

Frequency

Because most ECM systems have a regular yearly release, it is ideal to realize the benefits of upgrading every year. This will help with keeping up with OS and database upgrades as well.

SP2

In general, upgrades to enterprise software should wait for Service Pack 2 of the current release. This allows for initial release bugs to be fixed and stabilized. For OnBase, this usually puts the upgrade window in the third quarter of any given year.

Budget

If an upgrade is planned for every year, the budget line item will smaller and more digestible by management.

Schedule

An upgrade schedule should be regular and expected. The more regular, the easier and less expensive it is. The resources involved with not being trying to remember all the steps from scratch again. The steps themselves will be more up-to-date.

IE, OS and Database

At the enterprise level, you don’t want OnBase slowing down IE releases, or database upgrades. It makes sense to keep up.

Environments

With VMs and multiple environments, upgrade steps can be written and tested many times before the actual upgrade. This should help minimize risk for each upgrade cycle.

Enterprise system upgrade and implementation schedules

It’s important to get on the upgrade train each year (or two) as early as possible. There will always be larger, more important initiatives that will bump OnBase upgrades, but at least you’ll be on the list.

 

When new solutions are being developed, the requirement to be using the latest possible version of software is much more important. Even one year can make huge difference between solution offerings.

Sample Upgrade Matrix

There are concerns and potential issues when it comes to planning and executing upgrades. As the scale and complexity of the solution increases, so does the upgrade matrix.

 

Concern	Solution Details
Impact on Solution
Impact on Users
Environment Setup
Integration
Complexity
Cutover Approach
Downtime requirements
Testing
Upgrade Risk
Risk of Waiting
Resources

"The future is already here..."

“The future is already here — it's just not very evenly distributed.”

-- William Gibson

This quote, when applied to ECM, opens up doors of understanding. To know how solutions start and propagate throughout an organization, you must first start with the group most interested in the future, and why they are pushing IT in that direction.

Sometimes, it’s the promise of ROI, or getting rid of paper, or access to information outside of the secure network. Whatever the vision, the solution (the future) is not distributed all at once. ECM is a message; a movement that is planted, then it spawns to other departments. The success of the distribution is dependent on many factors.

Beginnings

The big bang vs. gradual implementation is always a discussion point when any expensive software is considered. Scoping the implementation just right is essential: the delivery date will slip if the scope of the project is too broad, however the project’s influence will suffer if the scope is too small. First implementations are politically charged. There are managers who feel slighted, disagreements in hallways, new alliances that strain old ones.

Follow Ups

It’s tempting to copy the first implementation with the same formula, the same business requirement steps, the same functional specs, and so on. Be cognizant of this. Each business process is different enough to warrant different approaches. Follow ups should not be delayed; they need to progress until the scope of the initial vision is complete.  For example, all of the incoming orders that were on paper are now scanned and indexed, in every branch. Automation of this piece is complete

Realizing the next phase

Every future has another one on its tails. By the time the final scanner is in place, a new vision is hatching. For example, a director wants to fix a broken process where invoices are getting lost; or there’s an information quality issue with the way the scanned orders are getting indexed. All solutions introduce new issues and therefore new solutions. Innovation never ends, only the sales pitch does. 

The Role of Licensing in ECM

Too many times the potential of your ECM rollout gets sidelined, or delayed because of budgetary issues. The right people have the right skills, the infrastructure is in place, but the needed module license was not in the budget. If you are lucky the management is onboard and willing to take the flack for asking for extra money, however this is unlikely.

Initial rollout 

ECM systems have a lifecycle just like all other software solutions. It could be that a new director is hired and she wants Hyland OnBase instead of Documentum for scanning. If you are in this type of situation where a new system is in the budget plan, then get to work with that 5 year plan.

ROI

Any project that includes converting paper or processes into a software solution has plenty of ROI, you just have to know how to calculate it. This is essential to justify funding the solution’s full lifecycle of licenses. Get as many diverse measurements of costs and savings as possible. Too little attention is given to this. All you have to do is talk to the people who are pushing the paper: how much time is spent trying to find stuff, what kind of decisions wait for this, what is this time worth? And so on…

Get it all now or forever hold your peace

It's easier to buy all the modules up front as one large budget, than it is to piece meal them in later. A module for $15k is nothing in an overall expense of $500k, however, two years later, $15k may not get approved as a standalone budget item. The shine of the new ECM solution wanes as the years go by. The big ROI has passed, it’s just harder to justify. If possible, negotiating all of the enterprise licensing up front would be a better strategy than waiting for buy-in a few years later.

Multiyear change in direction of a strategy

If the nature of the solution changes, it's easier to exchange modules, than it is to buy new ones. Let’s say that one module was never implemented, but a new mobile module is part of what your CIO wants. Exchanging licenses could be easier and quicker than asking for the extra, emergency budget request.

API and integration modules

Purchase the API licenses all at once. They are usually less expensive than the packaged solutions, but can be very useful as the solution matures and integration is revisited. Build in flexibility wherever possible, this means have the option to create minor customization when needed.