Most businesses that have documented their processes have documents nobody reads. That is not a discipline problem; it is a design problem.
Why documents get ignored
- They were written by somebody who does not do the work.
- They describe the ideal rather than the actual.
- They are too long to consult while working.
- They live somewhere nobody goes.
- They were accurate once and are now wrong, and everybody knows it.
Any one of those is enough.
What the followed ones have in common
Written by the person who does it. Even roughly. Someone who does the job knows the exceptions and the shortcuts, and a process that ignores those gets ignored back.
Short enough to use. A checklist beats a manual. If it does not fit on a page, it is probably two processes.
Where the work happens. In the tool, on the form, in the system, not in a folder on a shared drive.
Honest about exceptions. "If X, do this instead, and tell Y" is more useful than pretending X does not happen.
Owned. Somebody is responsible for it being correct, and updating it is part of the job rather than an occasional project.
Start with the expensive ones
Do not document everything. Document the processes where inconsistency costs money or where a handover fails. That is usually a small number: intake, quoting, handover, follow-up, and whatever the business's specific failure point is.
Build it into the tools
The strongest version of a process is one that cannot easily be done wrong: required fields, a step that cannot be skipped, an automatic handover. A process embedded in a tool needs no discipline to follow.
That is not always possible, and where it is not, a checklist in the right place is the next best thing.
Review honestly
Every few months, watch how the work is actually done and compare it with the document. Where they differ, the document is usually the one that is wrong. Update it to match reality, or change reality deliberately, but do not leave the two apart, because that is how a whole documentation set becomes untrusted.