Tuesday 22 April 2014

ECM as a service - is it really a service?

As some of you will no doubt be aware, the New Zealand government has embarked upon a programme to deliver Enterprise Content Management as a service.  So what does this mean in reality - well to try and help and reduce the jargon, here are some of the questions I get asked pretty regularly.

Question 1:  What does ECM as a service mean?
In its simplest sense its a software application (or set of them) that is delivered to you in a different mechanism.  Instead of having the software installed on your servers in your office, its installed elsewhere, managed by someone else and you connect to it through the wonders of the Internet.





Question 2: So why is it better?
Better?  Well in terms of benefits the "as a service" model can result in:
  • Easier Administration
  • Automatic updates and patching (and hence reduced cost)
  • Ease of accessibility - all you need is an internet connection
  • Increased compatibility - everyone is on the same version
  • Reduced risk, overheads etc etc
  • Reduced cost....hmmm, we'll pick this up later

Question 3:  So Its going to save me vast amounts of money?
Perhaps.  Just because the service is delivered to you in a different way does not necessarily mean it's going to save you heaps of money.  For some organisations it will save a lot, for others it will save a little and for others it will cost more.  Why?  Well the idea behind a service is that you consume it pretty much as it is and you walk away when you need to.  But for most organisations moving to this service you have migration costs, customisation and integration costs etc etc added to that the level of potential change the organisation is going through and its not a 'service' that you will walk away from in 6 months, or even in some cases 3 years.

Question 3:  So I don't need to do any requirements anymore?
YES YOU DO!  I have heard this question so many times recently its starting to concern me.  The ECM as a service offering still requires you to understand your business requirements, your objectives, your user behaviour and appetite for change, the line of business systems that either consume or connect to the ECM.  You don't need to do requirements as part of an RFP process but you still need them to make sure you're getting what you need, that there is traceability from solution implementation>testing>design>requirements>business objectives.


Question 4:  But I don't need to worry about the technology?
Kind of - you still have the rest of your technology environment to look after, and there are a lot of connections, quite rightly, between your ECM and your line of business applications; whether that's a list of clients from your case management system,  contract IDs from your financial system, property IDs from your asset management system etc - there are many connections.  But, you don't have to worry about patching and upgrades of your ECM service, the supplier does that for you - and that can be a massive cost saving and a major benefit for many organisations - upgrades aren't always painless!


Top tips if you are looking at an ECM or EIM as a service offering

1.  Due Diligence
Above all else - you are responsible for conducting due diligence, even if there is no RFP process.  You need to read the fine print and make sure any assumptions on both sides are clearly documented and understood.  Hidden assumptions can mean hidden costs and complexity.
  • Each of the service offering are structured a little differently so make sure you understand what is being offered in terms of implementation services as well as technology and software.
  • Make sure you understand what is expected of you, how much input do you have, and are expected to provide during the process - is it your responsibility to deliver use cases, requirements documents, test plan etc
  • What is the exit strategy for the service; how easy is it for you to get your content out of the service with no loss of integrity or is that an additional cost/service for the next project
  • Is the provider setup to support you in terms of resources, knowledge, experience, processes, documentation etc.  Since you are consuming a service, much of the internal capability and knowledge you would traditionally develop will be transferred to your supplier so make sure you are comfortable with what is delivered to you in that regard, and if you're not - tell them

2.  Try before you buy
Like any other software application it's a good idea to look at other sites that have the solution you are interested in, do reference checks, have a look at it in terms of possible fit and most importantly in this scenario - talk to organisations that have purchased and/or implemented a cloud service.  This is all about being informed - but it goes both ways (see point 3)
  • Before you commit to the purchase, does your provider have a sandpit or trial environment that you can access for a pre-defined period to allow you to get a feel for the solution at nominal cost?
  • If its a radical change from what you have now, do you need a well scoped proof of concept to be undertaken?  If you do, clearly document and agree the success criteria before you start!

3.  Meet your project team
Yes this is a service you are consuming but this is also the start of a long relationship with a single provider. 
  • In the past, if you wanted to change support providers you could do so easily at the end of the (usually) annual support period - but what happens now?  In the current environment one service = one provider, so it is critical that you establish your relationships early, meet your project team and the people who are the owners of the relationship post go live. 
  • This applies equally from the supplier's perspective, they need to know you, your culture, your objectives, your resources, your skills, your decision making points in order to be able to support you in the best way possible - so open a dialogue and if you see that there is a potential conflict; deal with it early.   
  • Meeting the team on both sides will give you a clear indication of what perhaps hidden assumptions lie behind the service, for example if your supplier doesn't provide a business consultant but provides a number of technical consultants you will want to think about, and clarify who is delivering that aspect of the solution, its artefacts and solution design - and vice versa.

4.  Define and obtain performance metrics
In most of the services there will be performance metrics including standard infrastructure level metrics such as #of users actively using the service, %downtime over the X period etc but what performance metrics do you need - from a technology, business, and compliance perspective?
  • Reporting can often be an added service, so the sooner you can start thinking of those meaningful metrics that you need the more robust the solution will become.
  • Each of the providers will have a different approach here, so check the fine print about the level of reporting you can expect and in what format - the term "report" can be interpreted in many ways so be clear on this
  • What access do you have internally to write your own reports, do you have the necessary passwords and connections, do you need training, support or is this an enhancement to go into the pot and wait for funding?
  • And before we get too excited with reports and all the wonderful things we "could do", let's also be clear on what we are using the report for - if it has no purpose it shouldn't be delivered.  So what do you have in your service agreement, contract, or internal business case, team metrics etc that these reports will feed/deliver for you?  And if you are shrugging your shoulders right now - perhaps now is the time to start thinking.

5.  The supplier is your partner not your enemy
The one thing I have enjoyed about the NZ process has been the open discussions that have been had between agencies and vendors.  Everyone involved wants this process to be successful, and the relationship with your provider will be critical here.  On both sides, I make a plea again for honest and open communications; if we see things that we think can be improved, or a process that isn't clear lets raise it.  When you are looking at your potential provider, look at their structure - how are they envisaging dealing with you and the wider user community to share experiences, lessons, concerns and opportunities.  The vendor community can bring you insight and experience, but you as the customer also need to bring your thoughts, your needs, your viewpoints and your experience to the table.  That way ECM as a service version 2.0 will be a far better product for all concerned.


A final word
I would have renamed the ECM as a service to ECM Platform as a service, because thats a better reflection of what is being offerred 'as a service', the platform is being delivered to you but the rest of the ECM discipline; your information architecture, security and access framework, metadata schema, collaboration and community configuration, compliance regime, training, policies, governance etc are all still largely your responsibility and rightly so.  So if you were hoping that this would be a "insert disk >click next > click done" process - you're wrong.  But then where is the fun in that :)

Comments?
As ever guys, these are my thoughts but please share yours - the more we can get some of the myths debunked, the lessons shared the better off we will all be.