企業がSOPを作成する際の主な間違い

劇的な崩壊ではなく、バインダーとベンチの間のギャップで静かに失敗します。病院は注意深い服薬照合手順を書きます。すべての内部レビューに合格し、承認を得て、意図した通りに品質管理システムに存在します。

それから監査員が午前2時に病棟に立ち、夜勤が実際にカルテを照合するのを見て、書かれたステップと実際のステップが数ヶ月前に別れたことを発見します。ドキュメントは書類上では決して間違っていませんでした。ただ作業とのつながりがなくなっていました。

機能していないSOPライブラリがある場合、人々が手順に従わないと仮定したくなります。実際には、多くのSOPは誰かが無視する前に失敗します。ドキュメント自体が作業を必要以上に難しくするために失敗します。

このガイドは、それらの失敗のカタログです。手順をゼロから正しく構築する方法を知りたい場合、それはSOPを適切に作成するための7ステップフレームワークの領域です。特定の問題が「完成したSOPが開かれないまま放置されること」であれば、それは従業員が実際に従うSOPの設計の仕事です。

以下は診断です：手順を失敗させる、繰り返し現れるSOPの間違いと、それぞれをどう修正するかを解説します。

重要なポイント

• ほとんどのSOPの失敗は作成時に組み込まれた欠陥です—過度に複雑、陳腐化、担当者なし—従う予定の人々のせいではありません。読者を責めることは真の修正を隠します。
• 過度な複雑さが最初の殺し屋です。最後まで誰も読まないほど長く、分岐が多く、ヘッジが多い手順は数週間で即興のショートカットに置き換えられます。
• 陳腐化が2番目です。画面やツールと一致しないプロトコルは数秒で見つかります—監査員に、またはその後ライブラリ全体を信頼しなくなる新入社員に。
• 不良な導入が3番目です。技術的に正しく最新のSOPでも、タスクの瞬間に誰も開かない場所に埋もれていれば失敗します。
• これらのすべては予測可能で診断可能であり、それぞれにそうでなければ監視に費やすであろう強制より安価な具体的な修正があります。

SOPが失敗する理由

コンプライアンスマネージャーに、なぜ手順が守られないのかを尋ねると、たいてい「人々が手を抜く」という類の答えが返ってきます。その答えは、問題を他の誰かに置くため心地よいものです。しかしそれは、ほとんどの監査結果においては間違っています。

手が抜かれたのは、SOPが正直なパスをショートカットより難しくしたからです。

変更管理の研究には、長く使い古された知見があります：ほとんどのプロセス変更や標準化の取り組みは定着しない、というものです。通常の説明は従業員の抵抗のせいにします。より有用な説明はもっと静かなものです：その標準は、従われるためではなくファイルされるために設計されていたのです。

監査員のバインダーのために書かれた手順は、プレッシャーの下でタスクを行う人のために書かれたものとは違って読めます。そして2つが分岐するとき、行動はバインダーではなくタスクに従います。

その分岐こそが、ほとんどの粗悪なドキュメントの根源です：怠慢ではなく、間違った読者のために作られたドキュメントなのです。

良いSOPは、それを書いた人がいなくなっても生き残ります。悪いSOPは、その人とともに死にます。作成者はプロセス全体を頭の中に持っているため、ドキュメントのギャップは彼らにとってだけ、彼らにだけ見えません。同じ手順を、初めてその仕事をする誰かに渡してみると、すべての未述の前提が、立ち止まり、推測し、台本から外れる場所になります。

失敗は、従うことの中にあるのではありません。書くことの中にあります。

よくある間違い

失敗パターンのカタログは予想より短いです。いくつかの繰り返しの間違いがほとんどの問題を占め、それらに名前を付けられれば、自分のライブラリをリストと照合して監査できます。

最も一般的なのは孤立したSOPです：「チーム」に属する手順で、つまり誰にも属しません。誰も正確に保つことに責任がないため、古くなり、監査員の前で壊れるまで誰も気づきません。

次によくあるのはタスクに合ったことのないコピーされたテンプレートです：チームが汎用フォーマットをダウンロードし、空白を埋め、誰も実際には実行しないプロセスを説明するドキュメントを出荷します。

次に、良い日に作業がどのように起こるべきかをドキュメント化し、実際の仕事の半分を構成する例外と回避策を省略する理想化された手順があります。

そして、バージョン管理の規律が全くないことから来る単純なワークフローの問題があります：3つのシステムに同じSOPの3つのコピーが存在し、それぞれが少しずつ異なり、どれも最新版だと明示されていません。

これらのそれぞれが、静かに業務の非効率を生み出します。正しいバージョンを探すのに費やされる時間、古いステップに従ったためにやり直しになる作業、機能する手順があれば防げたはずのエスカレーション。

そのコストは現実のものであり、積み重なっていきます。これこそがプロセスドキュメントの不備が招く隠れたコストで論じている核心であり、社内で財務的な根拠を示す必要があるなら一読の価値があります。これら3つの間違いは、単独でも十分な損害をもたらすため、より詳しく見る価値があります。そこで、このカタログの残りでは、それらを一つずつ取り上げていきます。

過度な複雑さ

SOPを確実に沈める最初の間違いは、それを完全なものにしようとすることです。監査員を気にする品質チームは、あらゆる不測の事態に分岐を設け、あらゆる指示にヘッジをかけた40ページの手順を書きます。徹底的ではあります。しかし同時に読めず、読めない手順は安全網ではありません。偽りの安心です。

規制下のラボで次に何が起こるかを見てください。書かれたプロトコルはサブ条項を含む15ステップに及びます；それを1日40回実行する技術者は、重要な4つのステップに圧縮しています。40ページのバージョンは、監査のためにバインダーに残ります。

4ステップのバージョンは技術者の頭の中に存在し、口頭で非公式に、すべての新入社員に教えられます。こうして手順が2つになります；一つは文書化され無視され、もう一つは実在するが文書化されていない。両者が分岐する日こそ、何かが問題を起こし、実際に何が起きたのかの記録が存在しない日です。

過度な複雑さによるダメージは、ドキュメントが長いことではありません。長さが人々をドキュメントから完全に追い出してしまうことです。

手順は、作業のスピードで従えるほど短くなければなりません。さもなければ、作業はそれを迂回します。修正は引き算の規律です：タスクごとに一つのSOP、実際に取られるパスを先に、例外はメインラインに詰め込むのではなく例外として処理します。

更新の欠如

2番目の間違いは、公開された日にSOPを完成したものとして扱うことです。手順は動く標的を記述します；ツールが再設計され、フォームに新しいフィールドが加わり、規制が変わり、それに合わせて動かないドキュメントは古くなります。

陳腐化は静かな殺し屋です。なぜなら、他のどの欠陥よりも速く信頼を破壊し、しかも一気に破壊するからです。

そのメカニズムはこうです。監査結果に何度も何度も現れるものです。監査員が校正SOPを開くと、それはラボが1年前に廃止した機器を参照しています。その単一の古い詳細は、2つのことをします：正式な指摘事項となり、そして誰もこのドキュメントを1年間見ていないことを監査員に伝えます。その時点から、他のすべての手順が疑わしくなります。

同じ崩壊は、監査員がいなくても社内で起こります。新入社員がSOPを開き、もう存在しない画面のスクリーンショットを見て、ライブラリ全体が信頼できないと結論づけます。彼らは次のSOPを開かず、その次の人にも開くだけ無駄だと警告します。

陳腐化がこれほど一般的な理由は、更新が本当に苦痛だからです。手作業で手順を再スクリーンショットして書き直すことは誰にとっても好きな午後の過ごし方ではないため、監査が強制するまで先送りされます。

2つの手を打てば、これは持続可能になります。

散文を書き直すことなくビジュアルを更新できるように手順を構築してください（インターフェースの変更に耐えるSOPテンプレートのパターンをご覧ください）。そして、記憶から書く代わりに作業を記録して手順をキャプチャしてください。このアプローチは作業しながらキャプチャして手順を最新に保つ方法で扱っています。

経済性こそがポイントです：ウォークスルーの更新が、元の作成とスクリーンショットに要した90〜120分ではなく8〜15分で済むようになれば、最新に保つことは監査員が来るまで先送りにする雑用ではなくなります。

不良な導入

3番目の間違いは、他のすべてを生き延びるものです。短く、最新で、正しい手順を書くことはできます。それでも、タスクが発生したときに誰もそれを開かなければ、やはり失敗します。

人々がチェックしないシステムにファイルされ、それが適用されることを告げる明確なトリガーもないSOPは、見えません。そして、誰も手を伸ばさない手順は、存在しない手順と区別がつきません。

ここでの診断はこれがすべてです。なぜなら、導入は独自のプレイブックを持つに足るほど大きな問題だからです。要約版：見つけやすさ、手順が適用される場面を告げる明確なトリガー、そして作業の現場への配置が、正しいドキュメントがそもそも使われるかどうかを決めます。

その完全な方法、つまり事後に強制するのではなく作成時に実行を設計する方法は、従業員が実際に従うSOPの設計の主題です。

不良な導入を、他の修正を無意味にしてしまう失敗パターンとして扱ってください：過度な複雑さと陳腐化を解決しても、なお誰かがそれを開くことを確実にしなければなりません。

修正方法

これらの修正は、新しい作成手法ではありません。

手順が再構築するほど深刻に壊れている場合、正しい動きは、ここで車輪を再発明するのではなく、SOPを適切に作成するための7ステップフレームワークを使って適切に作り直すことです。このセクションが提供するのは、上記の3つの失敗パターンに対応する改善策であり、これによって既存のライブラリを一から作り直さずに修復できます。

過度な複雑さには、引き算します。各SOPを一つのタスクに絞り、理想化されたものではなく人々が実際に取るパスをドキュメント化します。メインラインが作業スピードで従えるほど短く保てるよう、例外は別の参照資料に押し出します。

陳腐化には、名前のある担当者を割り当て、ドキュメントにバージョンと最終確認日を与えます。担当者はこのカタログの中で最も効果的な単一の修正です。なぜなら、孤立したドキュメントを誰かの責任に変えるからです。

エラーは、信頼を静かに侵食するのではなく、修正されるようになります。担当者をキャプチャファーストのメンテナンスと組み合わせ、ビジュアルを正直に保つのに午後まるごとではなく数分で済むようにします。

不良な導入には、作業が行われる場所に手順を置き、それを必要とするトリガーとともに開くようにし、より深い行動面の課題は導入ガイドに委ねます。

そして、根本的な問題が「手順が複数のツールに散在し、単一の置き場所がないこと」であれば、真の解決策は編集ではなくインフラかもしれません。チームに合ったドキュメントソフトウェアの選び方のガイドをご覧ください。まずドキュメントを直し、次にそれが置かれるシステムを直しましょう。

SOPライブラリを監査する

SOPの失敗は神秘的なものではなく、人の問題でもありません。予測可能で、診断可能で、作成時に組み込まれた欠陥の短いリストがそのほとんどを占めます。

手順が従うには長すぎたので、人々は即興しました。それが古くなったので、人々は信頼しなくなりました。タスクの瞬間に見えなかったので、人々は決して開きませんでした。そのどれも、規律の失敗ではありません。

それぞれは作成者が下した決定であり、それはつまり、それぞれをあなたが違うように決められるということです。

だから、監査員がするように自分のライブラリを監査してください。最も重要な5つの手順を選び、それぞれについて尋ねてください：誰かが今日、誰にも聞かずにこのドキュメントだけでこのタスクを行えるか？プレッシャーの下で従えるほど短いか？現在の画面と一致しているか？名前が付いているか？

答えが「いいえ」の場所で、あなたは間違いを見つけたのです。そして今、その修正法を知っています。

SOPの最善のテストは、それがレビューに合格するかどうかではありません。作成者が去った日に、そのプロセスが生き残るかどうかです。

よくある質問