A couple of days ago, one of our readers asked me to elaborate on a previous post in which I explained why users have so much trouble getting used to a document management or an ECM system.
Today, as it turns out, after speaking with a client, I got the information I needed to write a second part of that post.
Added to the main reason that I suggested in the previous post (that users don’t see the benefits of using the system), we also have to add another one that’s no less important: the users don’t trust the system.
I went to see the client (a prominent firm in the construction/infrastructure industry) because I wanted the client to tell me a little bit more about how they use Athento and why it’s important for them. This person, who has considerable experience in the field of mega-structures and construction in general, told me: “Athento has won them over.” However, he also told me that, before starting the project, he was very concerned about a factor that was, for him, critical: If the program started to produce errors once it was put into place, no matter how small the glitch, the workers who had started to use it were going to give up using it very quickly because human beings, in the beginning, always find it easier to keep working as they always work, rather than changing.
This was his point: If the trustworthiness of the system can’t be guaranteed, the project is doomed to failure.
I believe that this client’s right. Using new software can be stressful for people because what we’re asking them to do is to change the way they work. And, if on top of everything else, the software doesn’t work in the way people want, we’re asking too much by hoping that they’re going to use it.
Developers are used to problems; users, no.
What can we do to prevent users from ditching document management software, document capture software, Enterprise Content Management or any kind of software?
Key Point 1: Guarantee that we have the necessary infrastructure.
Users don’t like waiting, or having to repeat a task various times “because the application got hung up”. These things don’t always depend on the software: things like downloading and uploading speeds, a lot of times, are more of an issue with hardware. Do we have the necessary infrastructure? Does the server that hosts my document management software have the required characteristics to handle the quantity of users who work with the system, or the work load to be carried out? Being certain that we’ve got the necessary infrastructure is fundamental, before users are put in contact with the software.
Key Point 2: Test, test, and test (again).
Before putting software into production, we have to demand extensive texting and that the software meets certain criteria of quality. It’s a good idea to begin by bringing together small groups of users to use the software. That way, if faults or defects in the way the system functions are discovered, those flaws can be fixed before the entire team goes into panic mode and the idea that “the application doesn’t work” takes hold. This if fundamental, especially when it comes to discrete development projects.
Key Point Three: Worry about the system’s stability and robustness.
Don’t take this lightly, and it is always recommendable – especially when we’re talking about key businesses processes – to hire a quick, efficient support system service that can convincingly resolve any problems with the software. Sometimes, as in the case with airlines, it’s likely that someone who has had a problem will come back to use the system if the problem has been solved in a satisfactory manner. This is more true than with someone who’s never had to confront a problem.
I’d like to encourage you to comment and share your experiences and which formulas you think can be applied to prevent a failure in trust from system users.
Document Capture Software: Athento
Comparing Document Capture Solutions (Athento, Kofax, Ephesoft etc.)
Document Management Success Case at BBVA, managing 7 million records.