A long time ago I had an interesting discussion with one of my then managers whether ECM should be plumbing or not. This was around the time the people in my group started moving towards ECM related projects and we as a group were still trying to define ECM as a domain for ourselves. At that time my bold statement was that it should be plumbing from an end-users perspective and try to get away from the IT focus. Do I still think this is the case… now that I am much more experienced? Let’s take a look at both sides…
But first what do I mean by ‘plumbing’? In the physical world we have grown up with electricity and reliable water available at any time and we do not have to worry about there being enough quantity* and that complies with the agreed standards such as voltage and frequency for electricity. Having this kind of infrastructure in place has enabled countless different applications from microwaves to internet and from good tasting coffee at your local coffee shop to Jacuzzis in your garden. What I mean in case of ECM ‘plumbing’ is that an end-user or business owner does not have to worry about there being sufficient capacity or availability. Obviously this means a lot of work for the IT organisation.
Why should ECM be ‘plumbing’?
Wouldn’t it be awesome if you could just store your project team’s documents somewhere, collaborate with third parties and not have to worry about using the correct (minimum) metadata. While at the same time having your specific security requirements met and no one from IT bothering you about how much space you are going to use. And everything is setup in a matter of minutes or a few hours with almost no effort.
Records managers can do their job without involving busy end-users when there is a compliance issue or litigation against the company. If every new repository in the organisation, regardless of type of content, is setup according to records management standards from the start or, even better, is seamlessly connected to whatever system the records managers use to do their work. This would save lengthy and, let’s face it, boring discussions with business owners or the IT department to convince them of the need.
When there is a great opportunity in the market which demands for speed then it would be great if you could setup an external website, without having to go through a formal process of approvals from IT architects, having infrastructure discussions, and waiting for resources to become available to capture this market before someone else does this.
Pros:
- If setup correctly this can benefit end-users tremendously through speed and ease of implementation. There are limited number of technologies in use which lowers the learning curve for new employees and reduces licensing costs,. It is easier to keep the IT resource pool trained and relevant, easier to aggregate content / provide access to content through search capabilities across different repositories and there is more time available to improve existing tools.
- There is less lengthy involvement of end-users required in IT projects
- Overall there should be less costs involved in the long run
- Easier to implement compliance initiatives
- Basic IT infrastructure setup is arranged from the start such as security, internal/external access, storage, and scalability
Cons:
- Setting up ECM related services can take a long time and there’s a risk of business needs not being met with sufficient speed
- Standard tools cannot always be used by everyone and require a sound process to be able to deviate from the standard
- Selecting technologies to provide services is more critical because when a service becomes successful it will be more difficult to switch
- Requires top management commitment, significant budgets and active support
- Requires consensus across departments/divisions to become successful. Governance across various parties is always more complex
- Risks of the creation of a bureaucratic support organisation limiting the speed of implementation
Please note: in some case it could be possible to use externally hosted or cloud services instead of developing service in house which could reduce the initial costs and possibly make switching easier (provided there is a good migration path available).
Why should ECM NOT be plumbing?
If there are no limitations regarding technology choices and end-users have full control. For example your team is new to the organisation and is already familiar with a specific tool that is not yet available within the organisation. Having to learn a new tool could take some time for them.
Another situation may arise where there is a group of end-users with unique requirements that are difficult to implement with a generic tool while there are special tools in the market for such a group of end-users. An example, from personal experience, is that is a significant effort to implement the requirements of a legal team in a generic tool such as MS Sharepoint or EMC Documentum.
Pros:
- Unique situations can be addressed without being limited by the current standards and available tools
- There are now many tools available in the cloud or hosted that can be setup quickly at limited costs
- Less commitment from top management required
- Governance is less complex on application level as there are less parties involved
- Smaller budgets required (but in total for the organisation it could be more)
- Potentially faster implementation, especially if it is only for a smaller group of end-users
- Less need for consensus across departments/divisions required
Cons:
- Potentially many tools available within the organisation resulting in higher license costs, a higher learning curve for employees, multiple tools that do the same thing (more or less),…
- Requires a more diverse skill set from the IT department
- Requires significant end-user involvement
- Potentially reinventing the wheel several times
- More overall effort required on installations, upgrades and maintenance of applications
- More effort required to aggregate content or make content available in search capabilities
- More due diligence required before a new tool can be used. For example when using new cloud based or hosted applications there may be a need for involvement of security personnel, legal counsels, records managers, etc
My ‘revised’ conclusion:
ECM should be both… plumbing and no plumbing at the same. There are elements of ECM that would be highly beneficial to an organisation if these would be part of the ‘plumbing’ within the organisation. For example repository services for documents, records, and digital assets. There could be a service to automatically setup internal collaboration spaces / workspaces … It could be possible to automatically archive content and support for business applications such as ERP.
However there will always be situations that are unique where it does not make sense to setup services upfront or are only for a specific type of end-users that have their specific justifiable requirements.
So when should an organisation consider investing in the development of ECM ‘plumbing’?
- The organisation has a well defined vision & strategy regarding the application of ECM within the organisation. The end-user communities and business owners have a business need that can be fulfilled with the service.
- There should be sufficient scale and reuse of the plumbing. In other words the functionality should be sufficiently broad to support many users and situations.
- The services can be setup in a way that requires little resources or no resources in every new setup.
- The organisation can commit for the long run as it will require a significant amount of effort to get it right and there are sufficient resources, including budget, to improve and maintain once a service is setup. Furthermore there is an appropriate governance structure in place to deal with the current and future developments.
- The service can be setup based on internal and external standards. This should reduce future replacement of technology
- The service will not be limited based on technology considerations such as storage capacity available, compliance with the organisations security standards or network capacity. If a service is attractive to end-users this will kill it right away because it cannot deliver on promise.