Why SOPs and software should be designed together
A process that cannot be run, measured or audited properly is incomplete. Designing SOPs separately from the systems that will support them is a design failure.
Standard operating procedures and software implementations are almost always designed in sequence. First the process, then the system. The process team defines how the work should be done; the technology team builds the system to support it. The two teams meet somewhere in the middle, usually late, usually when the gaps are already expensive.
Why this order does not work
The problem is that a process designed in isolation from the system that will run it is missing half the information. A process needs to be runnable, which means someone needs to own each step and have the tools to execute it. It needs to be measurable, which means the data it produces needs to be captured in a way that can be reported on. It needs to be auditable, which means evidence needs to be stored against the process, the role and the event that triggered it.
None of those requirements can be fully answered without knowing how the system works. And the system cannot be configured properly without knowing what the process actually needs.
The better model
The approach TwinCoreTech takes is to design operating model, process and system together, in that order. What does the operation need to do? How should the process flow? What data does it produce, what evidence does it capture, who owns it, and how is performance measured?
Only once those questions are answered does configuration begin. The result is a system that reflects the process as designed, and a process that can actually be run, measured and audited in the system that supports it.