Please login or join to subscribe to this thread
Like any system, you'd want to ensure you are getting must have requirements from all key stakeholders. Some main areas of consideration are:
- Security and access control
- Access methods (e.g. browser only, dedicated client, mobile)
- Integration expectations
- Scalability - can it address the needs of today as well as the future
- Search capabilities
- Automated business workflows (e.g. approval, document forwarding)
When you are referring to is more formally known as configuration management. The 4 main things to consider in configuration control are:
4) Status accounting
There are many sources that describe these in great detail, but here is a good summary: https://www.informit.com/articles/article.aspx?p=26858&seqNum=5 It is written with respect to software, but the origins go back to the part numbering system invented by Ford back in their very early days of mass manufacturing.
This may sound overly dramatic, but document repositories can catch a bad rap and end up abused or neglected, or be completely ignored. I am ever amazed by what people can get emotional about. Too much freedom, and people try to make it something it's not. Too much control, and people stop using it. Some things to consider that might help you have a better implementation are:
- Why are they moving from the previous system?
- Does the new system eliminate or perpetuate problems people had with the old system?
- What are the differences in system capabilities? Are the differences pros, cons, or neutral?
- What is better about the new system? What is worse? (be honest about any shortcomings)
- Will new processes or behaviors be expected? I know, its JUST a document repository, but you'd be surprised...
- Who finds value in the system and related processes? Who doesn't? Why?
- Who can help you champion the change?
- What is the process and timeline for sunsetting the old system?
My recommendations is going to IEEE standards on the matter. ANSI IEEE 1042 for example.
To follow in Aaron's footsteps, you should expect to add data/document deduplication to your checklist. That's because people are used to manage versions by changing filenames (for example, Final Report 30March2022 v1.2. Yes, I've seen such names in a document management system.)
Kiron and Keith made suggestions I support.
It is not only about the repository but about how it is embedded in the organisational system, e.g. processes, roles, interfaces.
I would look in addition into a) the needs of the expected users, now and in future, their use cases, and b) the value the system would be expected to create.
Please login or join to reply