There has been a lot of talk about automating the classification of documents and records. Most of the focus is on the accuracy of classification and eliminating errors. Less often, there is a discussion about removing the burden from employees.
Let’s take that concept a step further. When you look at the average request for proposal (RFP) for document and content systems, most of the requirements are focused on organizational needs. That makes sense as people simply need to save, find, update and share documents in the course of their work. Organizations also need to worry about degrees of classification, security, retention, disposition, architecture and integration with other systems.
"There needs to be a balance between the needs of the people and the organization."
It all comes down to balance. As the organization has many more requirements than the people using the system, those requirements take priority. That is the wrong approach. There needs to be a balance between the needs of the people and the organization.
People are the key
What we forget when acquiring document and content management systems is that it is people that define the success of the system. They decide to put documents into the new repository and not work around it using email or a cloud-based file sharing system. Employee adoption is the key of success.
This does not mean that the organization’s needs should be ignored. It means that those requirements should not be met at the expense of usability. A content management system (CMS) may have the best retention system on the planet. If there are no documents in the system to retain, how does it serve the organization?
That is why we need to start with what people do every day. How do they do their job? How do they work with content? How can technology make their job more efficient while supporting the needs of the organization?
Let’s look at a newsletter editor. Content submissions are coming in from multiple sources, typically in email. Submissions will be in Word documents or embedded directly in the email. While there had been a push to store submissions in a central repository, it required people to navigate through a complex interface to submit content. The author would still send an email elaborating on the article to the editor.
It is a lot of work.
Now imagine if those same authors saved the article, and supporting images, in a location on their computer. That location is a logical representation of a content repository. The technology doesn’t matter as long as the author can simply hit "Save" to save the file. They can browse to the location without having to navigate through a web application and start a discussion thread with the editor. If the author wanted, they could send an alert to the editor, but why bother? The editor knows exactly where to look and receives daily alerts for submitted articles.
This is how that process would ideally work. Authors could just simply save their article with no additional steps.
Now the question is: How can this be achieved while still meeting the organization’s goals around security, classification and retention? This use case, along with others, serves as a framework to start identifying the proper components.
Some will argue that the ideal scenario may have to be compromised in order to find a CMS that can meet the "mandatory" organizational requirements. While a valid point, ask yourself this: If nobody puts content into the system, how well are those requirements being met?