Licensee BadgeTraining Badge
Submitted by cwhite on
in

Forums

I have been designated to run SOP's for our Strategic Plan. We are a Landscape/Snow Removal company experiencing good growth and we are starting to set up satellite locations/branches. We feel that we should start documenting procedures so that each location performs consistently.

Anyone have experience setting up SOP's? Any resources on the internet? Any books or business leaders to study?

Any help is appreciated!

TomW's picture
Training Badge

What have you found on Google so far?

ctomasi's picture

Tom,

Our company does this quite a bit. It took a while to build a culture that "got it". As we became multi-site, the value really started to pay off.

We break our documentation in to three main categories:
1) Forms
2) SOPs (high level)
3) Work Instructions (detailed)

Since an SOP may reference one or more forms and/or Work Instructions, it's an overview of what we do (ex: account creations) and the work instruction is how we do it.

SOPs and work instructions have these major sections:

- Title page
- Revision history (rev # or letter, date, author, comments)
- section 1: Purpose
- section 2: Scope (who it applies to)
- section 3: References (to other documents)
- section 4: definitions
- section 5: Responsibility (who does what)
- section 6: process/procedure (the guts of the document)

Don't get wound around the axel (I know, bad pun in this situation.) Start with someone familiar, get some buy in, then start branching out. You should be able to cover everything from equipment maintenance schedule to accounting procedures.

If you want to manage the documents, you may also want to setup a simple repository (could just be a folder on a network somewhere) with the author, reviewers/approvers so changes are controlled. When updates are made, don't forget to notify the affected parties so you don't have half the people using rev A of a document and the other half using rev B. Ex: "Please note that SOP-18 (garage organization) has been updated as of July 5, 2008 to rev C. Please destroy all copies of any earlier documents and use the latest revision from the document repository."

I hope that helps. If you have further questions/issues, don't hesitate to ask. I'm no doc control expert, but I work with several every day.

cwhite's picture
Licensee BadgeTraining Badge

[quote="TomW"]What have you found on Google so far?[/quote]

Good point... I'll eventually use that resource. I want to keep that as one of my later options, after learning from members of MT.

cwhite's picture
Licensee BadgeTraining Badge

Chuck-

Good stuff. Thanks! I remember you from the Chicago Conference and you had some great input there as well.

When talking about SOP's- what is too simple (or maybe insulting for the staff)? How to answer the phone? How to open and process mail? At what point do you cut it off?

ctomasi's picture

Cwhite,

I'm honored you remember me from Chicago. Thank you.

"Too simple" is realtive. As I ramp up my new project (re-insource the help desk), I'll be thinking about standards for answering the phone, responding to email, etc. It's all about what you want to standardize. I can help thinking about the security guards and their smiles.

HMac's picture

Remember to gather support for the eventual SOP - or you risk having it live only on paper! Make sure to ask for lots of input from the frontline staff - regardless of the task, [i]somebody [/i]is doing it today, and their support is necessary in order to standardize and repeat it elsewhere.

The term "best practices" has become a bit overused, but in spirit, I think that's what you're going for here: a repeatable process way of doing something that's been refined by experience.

-Hugh

dad2jnk's picture

Some bits of experience to add.

1. Make sure they are processes or protocols and not standards. Try drawing the protocol on paper in a flow chart, then write the narrative behind it. If you can't draw it out...it's a standard.

2. Someone needs to "own" each process and maintain it. Care and feeding is important, otherwise it will die on the vine. Drive ownership as far down as possible.

3. You need to audit the process to ensure the process is living and that it suits the purpose. The "owner" can not also be the auditor. A corrective action protocol - with follow up - is also needed to drive continuous improvement.

4. You need to establish metrics to measure the success (advantage) of the standardization into protocols and to identify weaknesses. These metrics should be shared with upper management and reported quarterly or so.

5. Use a tool such as value mapping to make sure you are maximizing the value from the process to your customer. This will also drive improvement in your process.

6. From the beginning, overcommunicate to the line managers and their people about why you are doing this. Otherwise, it will be seen as another bureauocratic nightmare from on high.

7. Finally, if your company doesn't have in-house expertise in this, hire a consultant for a while to get your feet on the ground.

Good luck.

Ken

ctomasi's picture

dad2jnk,

All good stuff. Thanks for embellishing on the entire doc control/quality/continuous improvement process.

cwhite, I know it sounds like a lot of work, but treat it like any other new project/initiative. Start small. Pick a process to pilot. Assign an owner. Draft it up. Get some feedback. Grow a little more. Before you know it, you'll wonder how you did without it.

bensimo's picture

Chris,

Chuck has provided great advice. I would like to reinforce what Hugh has said.

Get all the people presently doing what you are about to commit to paper to buy into whatever you produce well before putting it in stone. This make take several iterations of each document and will take time. But the front office most often is unaware of what it really takes to do the work and you don't want to force something down the throats of your most valuable asset, your people. That would be demeaning and disrespectful. Don't become a bunch of bureaucrats who put large obstacles in the path of the line producers.

Best regards, Ben

jdabramson's picture
Licensee BadgeTraining Badge

http://www.usfa.dhs.gov/downloads/pdf/publications/fa-197-508.pdf

I am in aviation and this book has provided a good formula for me.

Joshua Abramson

cwhite's picture
Licensee BadgeTraining Badge

Great stuff folks! The pdf that jd referenced looks fantastic. Definitely will help!

[quote]Remember to gather support for the eventual SOP - or you risk having it live only on paper![/quote]

I've got a great group of DR's as well as others that are interested in making this a reality. We all realize that we need it to continue expanding.

Any recommendations on using MS Visio to create the flowcharts? I've tried in MS Word before, but things get funky (format-wise).

ctomasi's picture

I use Visio quite a bit for workflow diagrams. I prefer the "swim lane" approach as it makes it easier for different parties to understand when they are involved and where the inputs come from and outputs go to.

dad2jnk's picture

I use Visio a lot for many different applications. A great tool.

I agree with Chuck. Visio swim lane diagram works best for complex processes or those that involve different functions in a matrix. For more simple processes, a flow chart works fine.

Try to keep the diagram to one page. If you must spill your diagram on to other pages, then you likely have multiple processes you are trying to cram into one.

Ken

cwhite's picture
Licensee BadgeTraining Badge

Chuck/Ken-

Forgive my ignorance... what do mean by "swim lane"? I think I know, but please clarify.

Thanks!

HMac's picture

Chris:

I was exposed to them in Six Sigma.

Arrange a flowchart so there are vertical columns (like you're looking down from the ceiling of a swimming pool). The columns are most often sorted by the groups responsible for parts of the process (e.g., R&D, Marketing, Sales, Contact Center might share responsibilities for a new product launch). In this arrangement, the vertical axis is time - so as the process unfolds, it moves "down" the swim lanes.

If you lay it out this way, the general movement of the process is left to right, top to bottom. But it's not uncommon to have the process "curl around" between the swim lanes as the different groups touch the process (for example, when you're prototyping something, it's common that it R&D touches it again, to modify it based on tests with customers).

In my experience with swim lanes, they're a real powerful way of illustrating dependencies among various organizational groups, and showing key "handoff" points between these groups.

-Hugh

stephenbooth_uk's picture

A swimlane in Visio is part of a UML Activity Diagram, it basically denotes activities that are the responsibility of a particular actor (actor is a person or thing that does something). Each actor has their own swimlane.

The correct term, under the UML 2.0 standard, is Activity Partition.

Stephen

dad2jnk's picture

Hugh describes them well. Functions are in vertical lanes (even looks like a silo) and time as you progress through the chart. A tip is to use on-page references when you need to cross more than one lane or a lane that is occupied at that point. Using reference circles you avoid a spider's web of lines across your diagram. Looks disorganized and distracting.

As Stephen notes this is a standard template in Visio.

Ken

ctomasi's picture

Visio has a template under Flowchart, called "Cross functional flowchart" (at least that's where it is in 2003).

It is very handy to put the various parties or groups in horizontal or vertical bands then build your process around it.

Example: If I am creating the process for IT to purchase something it might have bands for "IT", "Manager", "Controller", and "Purchasing".

Start with a box in "IT" that says "Get quote for item". That has a connecting arrow to a decision box (diamond) "Is item greater than $1000". If Yes, connect to another box "Create CapX". Eventually I need the manager's signature so one of those magic arrows is going to drop down (assuming horizontal "swim lanes") to the row that says "Manager" and a decision box "Manager approval?". If no, then end. If yes, continue on. I hope this is clear enough to give you the general the general idea.

The manager, controller, purchasing can all see what their actions are based on the roles.

(Sorry to be redundant in the explaination - I should have finished reading the thread before responding.)

cwhite's picture
Licensee BadgeTraining Badge

All-

Thanks for your help in this matter. I am much wiser than before and have some great tools to use.