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.

ECM Naming Convention Checklist

Overview

In general, the naming convention should entail enough descriptive qualities to make it obvious to which group the content belongs. Being able to quickly identify content context is important. The basic building blocks should follow how the organization’s security model is structured. For example, if the company uses Active Directory and assuming it is representative of the security structure, the names usually follow a convention:

(Area)(Department)(Category/Function)((Sub Function))

Not all of the above keys have to have a value. This is a guideline which helps focus the naming of the objects and structures that follow. Keep in mind that exceptions are always part of a naming convention.

Goals

Naming conventions give content a location and relevance tag. It tells the User what it is and where it belongs. By consistently following a convention, the system will be able to scale and still be coherent.

Scope

Each department has its quirks as to how they work. It is important to hone in on how they describe their content with the enterprise in mind. Try not to spend an inordinate amount of time splitting hairs over details. For multipurpose departments, move the structure out to a general level which encompasses all of their responsibilities, then work on describing each path, but keep it simple. Think about how the names will understood by Users who are not privy to your knowledge abbreviations.

Abbreviations

Every organization uses common and idiosyncratic abbreviations depending on its industry. The challenge is to be concise, yet clear. Some abbreviations can be too short and cause confusion. For all naming conventions it is critical to be as concise as possible.

Exceptions

Focus on the core convention and structure and note the exceptions. The exceptions should be handled by metadata or other means.

Assumptions

The main assumption is that the naming convention will be followed and enforced. Each department should be given some control over how they want to describe their content, however, there will be some common structures that will be imposed.

Common Structures

Before creating your own convention, check with other sources of content to make sure there is no convention in place. If there is, compare yours with theirs to see if adopting theirs makes sense. Maybe the first two levels should be incorporated, with the third being what you focus on. The values should be abbreviations if possible and obvious in meaning.

Example

(Area)-(Department)-(Control Number)-(Doc Type Identifier)

Taxonomy

This can be thought of as a way to get to your content. It could be a folder structure, or a cascading categories. Be careful to not go too deep; at some point metadata will take over in describing the nuances of content.

Example

(Area)/(Department)/

                (Specific Level 1)/(Special Level 2)…/

                                (Doc type)

A “Specific Level” could be a functional or category/doc type pair.

Content

Document Types

The naming of doc types should be clear and concise. It should be obvious what department and function they belong to.

Example

(Department)-(Functional/Category Name)-(Doc type name)

File Names

File names become important during normal file exporting and migrations. When content is used outside of the system there should be identifiers that help place the content in context. There could also be a reference back to the system’s numbering system.

Example

(Department)-(Doc type name)-(Content Relevant Identifier (for example Title or Patient MRN))(System Number).(Format)

Title and Headings within Document

The title should be concise, especially if it will be in the filename. It should also reflect any metadata values associated with the document.

Document Information Block within Document

A block of information as a header or footer to a document is a feature of paper-based control documents. In the block you’d have the Title, Doc Number, Doc Date, Doc Affective Date, and so on. This is metadata for the printed page. If there is the need to print a footer with this information still makes sense, but the content within the document should not have this, it should be implemented only during printing or saving to a file outside of the system. The properties of the exported files could also be used to metadata population.

Metadata

System

System metadata already follow a naming convention and usually are proceeded with “SYS” to denote them. The corresponding database tables follow functional naming conventions which are sometime cryptic, but logical.

Dublin Core

The Dublin Core is a common set of metadata of all ECM systems. These include author, doc date, description, name, etc. Don’t duplicate these unless there are naming rules that are different.

Department specific

Keeping track of which metadata is used for which purpose or application can be challenging as the system grows. Naming metadata specific to its purpose and project is advised.

Example

(department)(project name)(metadata name)

References or Relations

If a cross reference is needed, make sure the object naming is consistent with the purpose of the link.

Processing

Business processes or workflows naming need to follow the same naming conventions as all the other preceding objects. It should incorporate the common elements as well as the specific ones.

Publishing

When the ultimate goal of the ECM workflow is to publish to a portal, the naming conventions should follow the same conventions as the portal. Having to map or lookup values may not scale when added to a portal’s level of use.

Security

As mentioned above, the security hierarchy and its naming convention are a first indication of how well organized the company’s structure is. The naming of the groups should be considered when thinking about the naming of projects, folders, and doc types.

Compliance

Many systems have to comply with regulations like 21CFR part 11. This type of scrutiny applies to the information architecture and system’s content.

Regulations

Outside regulation bodies could impose certain naming conventions which need to be followed.

Audits

Auditors need to be able to ask for information in general with an understanding that you will know what they need. It’s vital to only search for what they focusing on, and this requires a good naming convention and robust metadata.

I18n

Introducing a foreign language to the system multiplies the complexity of the solution. Not only are the metadata values multiplied, the naming conventions are multiplied as well. Most ECM systems can accommodate this, however, folder names and metadata might have to the duplicated with the foreign values.

Search

Search is only as good as the metadata value quality and full text indexing comprehensiveness.

Change Management

As organizations change, areas and departments get moved around and new names are designated.

Regression Mapping

Keeping track of structural changes can be challenging. Depending on the scale of the change, creating a map to previous taxonomies or department names can be helpful.

Obscured by ECM Clouds

If your CTO says it is “impossible” for the hyperconverged cloud to go down, you know you and everyone else will be in for a long night at some point during the cloud's stabilizing period. Nothing is infallible, not even the cloud. If you are pushing the technology edge, then you need to own up to the inevitability of a confluence of issues. So you have to ask yourself, “What steps would have to be skipped, or overlooked, during the design, development, and implementation of a cloud system to get to the point of an emergency downtime of your fool proof network?”

Hypothetically, let’s say one bug in the software could blue screen all of the domain controllers in every redundant location at the same time. There are a few points to consider when reviewing this type of failure:

The inexperience of those in control at the technical and the blind faith managerial level

With new technology even the experts make mistakes. When the outage happens, are the persons caught in the headlights fully trained and part of the initial design and development, or are they the “B support team”? This is a critical mistake made over and over again, by IT leadership and financial stewards, where it is deemed okay to bring in experienced consultants to design and implement a new technology solution and then leave it to the less experienced support to team to maintain and upgrade, without proper training and onsite support.

Lack of resources to provide an acceptable factor of safety

In the rush to curtail costs, the system suffers. The “secure and agile IT services” cloud is not a one off capital expense. Cutting operational costs too drastically will show its shortcomings in emergency outages and other incidents over time. As with any system, the change must be methodical with a factor of safety that is understood by all business partners. It’s no excuse to cut corners because there’s “no budget.” Try saying that to a surgeon.

Make sure someone is always accountable

In many cases, the business is cajoled into taking what IT says for granted, but when the system goes down they might be surprised to find out that no one is ultimately held accountable. “Virtualizing and hyperconverging its data center” also could end up virtualizing the accountability of the system, which in turn means that a Root Cause Analysis will never fully explain what really happened, if it ever gets sent out…

Lack of decoupled, identical Test environment

If your company cannot afford a decoupled test environment that mimics the cloud set up, it is adding risk to the implementation. The vendor should at least provide a comparable test environment to test bug fixes and service packs. If you had this and the outage still occurred, this points to the infrastructure team, their manager, their director, and ultimately their CIO.

Cognitive Bias toward “If it runs, don’t upgrade”

There can be a bias with some CTOs to only fix bugs with bug patches, and to never upgrade the virtualization system software unless the infrastructure requires it. In the end, “hyperconvergence” is a term that is meant for theoretical analysis, not ROI, because the hidden costs of implementing this new technology are everywhere, you just have to know where to look. Also, the risks for implementing an internal cloud are greater than going with the established, large cloud services.