Having spent most of my career working with structured data, I was initially happy to see that the ECM project plan presented at the AIIM ECM Master class, looked a lot like a systems development project plan. Requirements gathering, design, testing, etc., lots of similar tasks. There is a significant difference between ECM and those other applications; ok there are many differences, but I’m going to talk about just one today. The difference that has my attention today is duplicates.
The application systems we wrote were designed to satisfy a requirement that we establish one source for financial information. How much premium has been written? One source. How many claims do we have? One source. How much money are we making? One source. I’m not saying that establishing one source was necessarily easy. I remember days, long ago, when underwriters and accountants might argue about the premium numbers (it’s that whole “month-end” thing), but in general, working toward “one source” was an easy concept to agree with. Establishing one source in ECM is harder, and the very nature of “content” makes it even more complicated – we don’t only have to worry about source, we have to worry about channel too.
Lately, I’ve been proud of the success that we are having collecting, processing and storing certain documents that we prepare. Separate requests came in yesterday from two customers that reminded me that the process is bigger than that. One request was from a customer who wanted a copy of a managed document. The other request was from a customer that wanted to provide information to one of our engineers. In both cases, we are set up to handle the request, but we also have the built-in ability to go off the rails, to avoid the one source rule. That ability comes in the form of email, and it is a formidable foe to ECM success.
The document that one of our customers wants is maintained in a document library on an Internet-facing SharePoint server. Each of our customers has (or can have) access to this library. Once access is established, they are guaranteed to always have the latest version of the document in question, which is the requirement everybody says must be satisfied. However, the request came in via email, and the easiest way to satisfy the request, is to reply to that email and attach a copy of the document to that reply. Easy? Yes, but we need to avoid the easy approach. We need to make sure that every customer understands that we built a system where they can get this document. It’s not to reduce our work. It’s not to reduce contact with our customers. We need to do this so everyone involved in this collaborative process is working from the same document – not just today, but always.
The second request was easier to deal with, mainly because email failed. Our customer had several large documents for one of our engineers, and the email they attached them to never made it off their company server. They asked if we could work with them to exchange these files. Unfortunately, there are tons of ways to move large files today. Fortunately, we have a preferred method, SharePoint, and this customer already has a site set up on our Internet-facing server. Later this morning, we will contact them and walk them through the upload process and they will be happy. I know this, because I have had this conversation before.
While we all understand the importance of having the right number to answer a business question, we are all too comfortable making copies of documents. I am convinced that it will take a generation of people and a lot of work to break us of this habit, but I am equally convinced that we need to start now. #AIIMEducation #E-mail #SharePoint #requirements