Two weeks ago, we shared the first part of our series on Standard Operating Procedures (SOPs) with a focus on how to create them. But now comes the part that really matters. Once you’ve created a robust set of SOPs, how do you sustain the gains? How do you make sure they are still viable over the next few years?
Remember the idea of an “active” document in Part 1 of our series? Let’s talk about how to make that happen.
“Active” means it is not a policy that is enforced as the “rule of law.” Rather, “active” refers to the ability to evolve over time. More often than not, when SOPs become hard policy they can turn into a roadblock, especially when it comes to process change and improvement. We want to avoid that. However, active documentation doesn’t mean the process can be interpreted differently or that it can be changed on a whim by anyone. You need to design a process to maintain the integrity of your SOPs and allow them to be a positive addition to your culture.
While these SOPs may be completed, they are by no means final. It is okay for these documents to go through iterations. In fact, it's expected, as long as there is a process for making and communicating changes to the teams involved.
If you read Part One, you’ll understand the emphasis on ownership throughout these processes. If you haven’t read it, now’s the time to look back, specifically at the RAPID Decision Making model by Bain & Company, so you can follow along here in Part 2.
In any company, the people change often, but the roles rarely do. That’s why building process responsibility into certain roles is key. As a person moves up or out, the individual fulfilling the job knows that the processes are their responsibility and they have a structured process to go about changing them.
This is a process that has worked in the past. However, it won’t run on its own. It takes leadership and ownership from each level to work.
Typically, Operations owns the process since they live through most of the jobs in the distribution center. They should have a majority control, and the owner of the process should be a single role with authority to make decisions for all operations. It is up to this person to assign responsibility of the following to designated roles.
1. Request a Process Change
“We’ve always done it this way” is the response of those who are stuck and have given away control. Unfortunately, it’s also the response heard by associates and front-line leaders who propose a new way of doing the job.
When someone in the business has an idea, they will fill out a process change request form. The form can be as simple as you want, as long as it provides some structure for the person to refine their idea and for the review team to understand it. A good starting form will have a section for drawing a new layout design, area for written description, specific sections of the SOP they are requesting to change, and of course, information like name, shift, and department.
Establish an expectation for how to submit these too. We often recommend the employee submit the process change request form in-person to their area manager or shift manager. This is more effective than creating a drop-off box, where no facetime occurs between the employee and manager.
Once the request form has been submitted, it goes for review. The review team should consist of functional or shift operations leaders who have a broader range of process authority than an area manager. This will allow for consistency in the decision-making process across all jobs and work areas in the facility. Shift managers or assistant managers work perfectly.
The process change request is shared and each member of the review team provides input. Is there enough information to make a decision? Is there any negative impact that isn’t acknowledged? At this point, the request is either kicked back for some rework or further research, or it moves forward in the process and awaits a decision.
If you are the owner of this process, be sure to put a time table for this part and hold your counterparts on the review team accountable. We recommend that all process change requests be reviewed weekly and the associate receive an update.
If the process change request is agreed upon, the most senior operations leader will make the final decision and approval. From here, there is either 1) A rollout of the change in process to everyone or 2) The person (or group) who requested the change is given specific reasons why the change is not being pursued.
4. Communicate & Set Expectations
Here’s where it really matters. You have now run this change through the process. It’s been questioned and challenged, maybe verified by an engineering group or other support department. It’s good to go and should be a welcomed change. That is, if it gets rolled out correctly. I’ll save my classic rollout and communication mishaps, because I’m sure you’re already recalling your worst examples as you read this.
The beauty of this process is that it’s understandable to all. Associates to Senior Managers take part in the change process, so when it comes time to change, be sure to explain in depth what actually went into this decision as well as what is actually being changed. Your team on the floor will appreciate the transparency. If they don’t agree with the change, they have knowledgeable resources in both their counterparts, area manager and senior leadership to help walk them through the reasoning.
Setting expectations this way, where it’s understandable to all and can’t be interpreted differently from person-to-person and shift-to-shift, is where your culture begins to be rewarded.
Doing all of this correctly can lead to big culture changes. A document that was created by associates and has clear guidelines for how a process can change is very powerful for setting expectations in a variety of ways.
Here’s a few examples in a building with active standard operating procedures:
When an incident occurs, the SOP and subsequent best method is reviewed vs the statements in the incident investigation. Was the employee at fault by neglecting the proper method that has been a well-communicated expectation? Or does the SOP fail to prevent such an incident and need to go through a process change?
Training & Onboarding
A new hire leaves the building after their first day. They walk out with printed copies of how to do every job the right way in their new department, which was covered with them by their on-the-job trainer. Any questions they may have the next day can be answered with the SOP. They start their new job with the best method for the job explained to them in detail by multiple people.
The picking team has fallen into the habit of not leaving their locations in pick-ready condition for the next picker. The area manager is tired of following up and setting expectations verbally and debating the right way a location should look. They submit a process change request to define what a pick-ready location looks like. It’s approved and amended in the SOP. Each shift cascades the communication of the change in expectations to their teams, having each associate signing off that they have received the new expectation.
These are real examples. These situations occur in every distribution center, but the results can be wildly different without active standard operating procedures.
Establishing SOPs isn't just about the documentation and putting the process on paper. It's about creating a tool that adds consistency to how your leadership manages the processes that all associates work in.
At LogistiPoint, we have experience laying the right foundation for your distribution center. Whether it’s a new facility looking to start off on the right foot, or one that has been around but has some foundational process management cracks showing—we can help you lay the right foundation.