SOPs.Clear stepsfor everyday work.
Recurring work should not need explaining from scratch each time someone else does it. SIXIS documents the process in practical instructions the team can use, check and update.
Recurring work should not need explaining from scratch each time someone else does it. SIXIS documents the process in practical instructions the team can use, check and update.
Tell us what must be explained often See how we workWhen the thing depends
of repeated explanations.
Instructions are useful for sufficiently stable activities, where omissions or different interpretations produce errors and follow-ups.
A new colleague learns only by asking.
The steps exist in the experience of a few people. Everyone explains it a little differently, and an important detail appears only after a mistake. Integrating a colleague requires repeated interruptions and there is no common verification benchmark.
The same activity is done differently.
Some people check the documents before starting, others after. The necessary information is requested at different stages, and the result reaches the next incomplete peer. The difference comes not from a justified exception, but from unwritten rules.
The documentation no longer reflects the real thing.
A manual exists, but applications, responsibilities, or conditions have changed. The team bypasses him and keeps the explanations to conversations. It is not clear who can change the instruction or which variant is valid.
We describe the steps.
We check them in progress.
We write the instruction together with the people who know the activity and check it with who should be able to use it.
We do not mechanically document every gesture. We choose the details necessary for the activity to be done correctly and for the exceptions to reach the right person.
The SIXIS collaboration modelWe delimit the activity.
We determine when it begins, what result it must produce and where the colleague's responsibility ends. We choose a recurring activity with a concrete problem. If the process is still unclear, we clarify it before we fix the steps in a document.
From you Priority activity and examples of repeated errors or questions.
We observe the real way of working.
We go through cases together with the people who perform the activity. We write down the data, checks and decisions used. We compare practice with approved rules and identify differences that need to be resolved, without treating every existing custom as a correct rule.
From you People who know the activity and the examples or materials needed.
We redact the instruction.
We write the steps in the order of use, with concrete actions and checks. We specify the necessary information, the result of each stage and the completion criterion. We use examples or images when they clarify a step, without loading the document with details that don't help.
From you Confirmed rules and materials that may be included in the instruction.
We document exceptions and validate.
We determine what the colleague does if information is missing, a difference occurs or he does not have the authority to continue. The instruction is checked by the responsible person, then followed by a user who does not rely on the author's explanations for each step.
From you Validator and colleagues who may test the instruction.
We establish use and updating.
We agree where the valid version is found, who can modify it and when it must be revised. We keep relevant changes and link with company rules. We review post-use questions to correct ambiguous steps or missing information.
From you Place of Retention, Maintainer, and Feedback from Use.
A WORKING EXAMPLE
Receipt of equipment
for repair.
A firm repairs equipment under warranty or out of warranty. The front desk must gather the necessary information without promising a diagnosis or acceptance of the warranty before the inspection.
- The reception steps are explained.
- The instruction shows what data and documents are required, how to identify the equipment, and where to note the problem described by the customer. Photos or accessories are registered according to the rule approved by the company.
- Incomplete cases have a solution.
- If the necessary proof is missing or the series is not legible, the colleague knows what he can record and to whom he asks for clarification. Do not assume that a warranty claim is equivalent to its acceptance.
- Submission to verification has a criterion.
- The case is forwarded when the required information is complete or the exception is authorized. The technician receives the agreed data and the customer finds out what's next, with no promises beyond the reception stage.
RELATED CAPABILITIES
What the instruction does
applicable.
A work instruction needs a clear process, confirmed responsibilities and a valid variant that is easy to find.
Process mapping
Clarifies activity routing and handovers prior to documenting execution steps.
Roles & Responsibilities
Determines who executes, who checks, and to whom exceptions are transmitted.
Documents & approvals
Organizes the validation and use of the correct version of the instructions.
Workflow automation
Can automate predictable steps after work rules are clear.
Questions about
work instructions.
What is worth documenting and how do we avoid instructions remaining unused.
What is an SOP in the context of SIXIS?
An instruction for executing a recurring activity: when it starts, what information it uses, what steps are taken, and how the result is checked. May include exceptions and escalation rules. The shape and level of detail are chosen for the people who use it.
How does it differ from a process map?
The map shows the stages and connections between people or systems. The instruction explains the concrete way to execute an activity in that route. We can use the map as a starting point, but we don't turn it into an SOP just by adding more text next to the same steps.
Do we have to document all the company's activities?
No. We document the relevant activities in the process we are improving: for example, preparing an offer, submitting an order or tracking a payment. We prioritize steps that are frequent, sensitive to omissions, or difficult to explain to a colleague and validate the instructions with the people who use them.
Write the instruction without team involvement?
We need people who know the activity and a person in charge who can confirm the rules. We can organize the information and write the steps, but we don't invent the firm's practice. Without validation, an orderly document may describe a way of working that the team cannot apply.
Can we include screenshots or examples?
Yes, when it helps the user recognize a field, document or result. We choose materials that can be used and maintained. Sensitive data is removed from examples, and captures must be revised if the application or steps change.
What do we do with situations that do not fit into the usual steps?
We document the known exceptions and the rule for a new case: what must be stopped, what information is kept and who is asked for a decision. The instruction cannot anticipate every situation. It is important not to force the colleague to improvise an approval he does not have.
Can the instructions be used to train new colleagues?
Yes, if they are adapted to the required level of knowledge and verified by use. I can support the training, along with examples and exercises appropriate to the activity. They do not automatically replace the technical training, clearances or checks required for certain roles.
Who updates them after implementation?
We establish a person responsible and the moments of review, for example the change of an application or the occurrence of a repeated error. The team must be able to signal an unclear step. Updates are validated and published as the current version, so old explanations don't continue to circulate.
What activity must
always explained?
Choose an activity that colleagues often do and for which the same questions appear. We start with the actual steps and things to check before teaching.