Document management: from folders to a searchable archive

A folder tree is not a poor solution, it is a very old one. It represents exactly one order, namely the one that seemed plausible when the first subfolder was created. As long as everyone involved carries the same order in their head, it works well. The break comes when a document belongs to two orders at once: a supplier invoice is also evidence for a customer order, a contract belongs to the customer and to the contract type, an inspection report to the machine and to the year of inspection. In a tree this can only be solved through copies, and from the first copy onwards two versions exist, one of which will eventually be out of date.

The warning signs look the same in almost every company. Folder paths become so deep that dialogues truncate them. File names carry suffixes such as final, final2 or copy of. Important attachments sit in mailboxes rather than on the shared drive because that route was quicker. After a colleague leaves, the team spends weeks looking for records that only she could reliably place. And when the tax adviser asks a question or an audit comes up, things get hectic, because everything is there but nobody can demonstrate that it is complete.

The effort rarely sits in the individual search but in the sum of small detours: asking which version applies, requesting a document a second time because the first cannot be found, or creating a filing location twice because the existing one was not located. Individually these detours are too small to be reported, and together they are large enough to justify a project (project experience). Anyone wanting to quantify them should measure them the way a process analysis measures other workflows: on real cases rather than on estimates from memory.

Documents in a company are not created for their own sake but for a case: an order, a customer, a machine, an employment relationship or a delivery. That very membership is lost the moment the document is filed as a file. It then survives in the file name, in the folder path or in the head of the person who filed it. An archive in which every document knows its case reverses the search: instead of looking for the document, you open the case and see everything belonging to it — quotation, order confirmation, delivery note, inspection report, invoice, correspondence.

This reversal is the practical core of document management. It also relieves colleagues who rarely work with the archive, because they no longer have to guess search terms. And it makes gaps visible: if a completed order is missing the signed delivery note, that stands out when looking at the case, whereas it goes unnoticed in a folder tree. The prerequisite is that the case has a stable identifier used across the whole company — the same number in the merchandise management system, in the archive and in correspondence.

These attributes do not all have to be typed in. Where documents are produced out of a system, such as quotations and invoices from merchandise management, case, parties and date can be carried across directly. For incoming post, a pre-fill based on sender and document type that the capturing person merely confirms pays off quickly. The fewer keystrokes capture requires, the more complete the archive becomes — that is the most reliable rule in this field (project experience).

On a shared drive, rights usually apply per folder. That is coarse and leads to two familiar patterns: either almost the entire team can see almost everything, or special folders appear whose permissions nobody can survey any more. In a document archive, rights hang on attributes instead: on the document type, on the confidentiality level, on the department it belongs to. That allows rules to be written which also apply to future documents without anyone having to remember them.

The separation of read, change and delete permissions is particularly relevant. Many companies effectively grant all three together because the shared drive barely allows anything else. For personnel records, contracts and certificates that is inappropriate. It also helps to treat deletion not as an individual permission but as the result of a period: what may be deleted follows from the retention rule, not from the judgement of whoever happens to be tidying up.

A simple check before rollout: take five typical document types and answer three questions for each — who may read it, who may change it, who decides on deletion. If the answers differ around the table, that is where the real need for clarification lies, not in the software selection.

Not every company needs a document management system. Where few document types occur, allocation is unambiguous and the archive stays manageable, an orderly filing structure with clear rules carries further than the vendor landscape suggests. Folder structures still achieve plenty: a coarse split by area, a place for completed years, a defined location for templates and a structure readable by people without any additional software. The switch pays off where multiple membership, retention periods, access rights or evidence obligations come into play.

If a system is on the table, only a handful of properties decide the outcome in daily work. The list below describes requirements, not products. It works as a review grid for quotations and protects against demonstrations in which a lot is shown and little is answered. The last point matters most: an archive from which documents can be extracted together with their attributes stays available even if the system is replaced later — the same consideration that applies when replacing legacy systems.

One more point: a system that sits beside the existing workflows will be bypassed. It should appear where the work happens — in the case, in the order, in the inbox. If filing is an extra step at the end of the day, it is left undone. If it is part of the case, it happens along the way. This placement belongs to process documentation and should be settled before the selection, not after it.

A start works better when it begins with one document type rather than with the whole company. Incoming invoices are a good candidate: they arrive regularly, look alike, clearly belong to a case, and their retention is settled. Once that workflow stands and the people involved have mastered it, contracts, certificates and correspondence follow. Every further document type is then an extension of familiar rules rather than a new project.

A short check on the first weeks belongs to the rollout. Not as reporting but as an early warning: how many documents arrive, how many are allocated to a case, how many stay unresolved, and for what reason. Unresolved cases are the most interesting figure, because they show where attributes are unclear or pre-fills are missing. After a few weeks that number usually falls noticeably, provided the feedback is acted upon.

Just as important as the technology is training on real cases. A session in which staff capture their own documents from the current week has a more lasting effect than a demonstration on sample data. Two short sessions two weeks apart achieve more than one long session at the start, because the second session is where the questions that arose in daily work come up. How such a transition is structured is described on the page training and rollout.

Finally, the new archive needs an owner. Attributes go stale, document types are added, periods change, new staff need an introduction. A named person with a fixed slot each month is usually enough in companies of this size. Without that ownership any order decays, and in a few years the company stands where it began — only with a different tool.