Efficiency!  In the same way that computer systems such as EXPANDABLE help your business to be more efficient, so to do well defined business process and user procedures.  Why? They remove the “tribal knowledge” element.  If we know how business processes are performed by each individual, management can better understand the role that employees play.  They can find efficiencies, and cross train employees which ultimately can save on the bottom line.

You can validate computer systems to reduce risk and meet business requirements, but it’s the human element that is the least consistent.  Good procedural directions and training is the best bet.

A policy should be the over-riding set of general guidelines for business process (i.e. IT may have an IT Policy which states that systems will be backed-up each business night, weekly backup tapes will be stored in a secure off-site location, rooms housing servers shall be locked, Network user password shall be changed every 90 days, etc. But the details on how each of these items are performed belong in procedures that are used by the IT department.)

A Procedure should explain how the organization expects business processes to be carried out (Multiple procedures will contain detailed instructions on how a high level policy will be performed, including how often,  and by whom, etc.)

2. Don’t create a separate policy and procedure for every single process or eventuality

“Micro” policies and procedures don’t work!  I see it over and over, and they create more problems than they ever solve.  It’s simple human nature, if you make a process difficult to find or use, it simply isn’t as likely to be followed, plus they are just hard to manage.

One company I worked with had an e-mail acceptable use policy, a internet usage policy, a limited personal internet usage policy, an instant messaging policy, a password policy, a printer policy, a remote access policy, and a laptop security policy.  I am happy to say that all these policies eventually found a more user friendly home in the IT User Guide.

If at all possible consider grouping SOP topics by the intended audience.  A computer user in Sales needs to understand that Policy requires them to change their user password every 90 days, and they need to have Procedures on how to change their password.  However, sales personal don’t need to have documentation on how to manage all user accounts the way IT does.

Many times I find that the best place to start when writing a procedure is to write down the steps to perform whatever process you are trying to document.  Depending on the subject matter expert, this step can be done in a multitude of ways: detailed steps, outlines, process flow diagrams or maybe someone else taking notes while the subject matter performs the process.  Whatever works for that individual!  The key here is not to over think it, just capture the process!

After you have drafted the steps, a pass or two may be required to transform the raw process into something that anyone can follow to achieve the same results (back to the recipe analogy).  Also although company policy sometimes varies on the use of screen shots, where appropriate a picture or diagram can say a thousand words.  A note of caution here, too many pictures can make your documents to long, so try to be judicious with included images you probably don’t need a screenshot for each and every action.  Just like in a good recipe, it’s key that the steps are clear so that a consistent outcome/ cookie is the result!

Companies may have different formats for the rest of the document but I can assure you that once you have defined the process the rest of the pieces which make up a Standard Operating Procedure such as Purpose, Scope, Equipment, etc., will be much simpler to define.

By investing in well-written Standard Operating Procedures, companies will save money in training costs and achieve quantifiable goals.   SOPs really are a recipe for success.

Penny Goss is a compliance specialist with expertise in both the pharmaceutical and medical device-manufacturing environments. Penny performs software validation, risk assessment, audit remediation and independent software review services for her medical technology clients. In addition to compliance work, Penny’s technical writing services include RFP’s (from the original needs assessment, Request for Proposal development, and quantifiable vendor evaluation to aid clients in selecting software that best fits their needs), business process mapping,  and last but not least review/development/refinement of policies and standard operating procedures/custom work instructions. If you have questions, or would like assistance in developing standard operating policy and procedures at your company, contact penny@gosslv.com. To learn more about the services Penny provides, visit www. gosslv.com.