Document management systems are like cars. In the case of cars, any car that you buy is going to let you move around. Likewise, any document management systems that your company buys is going to allow you to store documents. But just as with cars, software users don’t usually want the car with just the factory settings; they want to customise it according to their needs.
Some users will opt for the customisations that the brand allows them to make, which guarantees that these customisations will be under warranty: paint colour, anti-fog coated headlamps, front parking assist, navigation system, etc.
Other users will want more complex customisations. They might even modify the engine!
Making changes to the document management systems factory settings and beyond the customisations that the software allows involves two important risks:
Below, we share 3 especially grave errors you must avoid if you are in charge of a document management project that involves software customisation.
A car is a car, it won’t cut the grass. So adding a lawn mower doesn’t make much sense, right? It’s the same with a document management systems. Why insist that a document management systems be able to make calculations or have ERP features?
I’ve participated in processes in which it was insisted that the document management systems be able to calculate the purity of a laboratory sample!
Keep the document management systems features and use integrations with other tools to cover the specific needs you have.
Let me use a different comparison to illustrate this point. Surely, if you order a bespoke suit from a tailor, it will be more expensive than if you go to a store like Zara and buy one off the rack.
The same is true with software. In this case, the higher costs are paid in the medium and long term. An application developed by us or only for us has various disadvantages:
The problems listed above are also applicable for large developments that we decide to do on a market product, which brings us back to point 1.
This is an easy mistake to make. Let me show you some typical examples of some technical requirements for document management projects:
These are just some of the examples that come to mind, but there are many more cases and errors.
Trust the user, trust their professionalism and their ability to discern before deciding to put up all kinds of roadblocks that will demotivate them when using the new software.
Also keep in mind that however much you try, when designing, you aren’t going to have in mind all the possible cases and exceptions that may arise. The best thing you can do is offer visibility and lots of consultation help that users can have as a reference.
I hope this has helped orient you and help you reflect if you are in the phase of defining the requirements for a new project or expansion of your document management systems.
🔥 Mastering Document Management is key in today’s competitive world! 💼💪 🚀 With the right strategies, you can conquer common Document Management challenges and take your company to the next level! 💡📈 #DocumentManagement #BusinessSuccess
A document management system provides a more efficient and structured solution than email for managing important cases and documents.