オープンループプロセスがビジネスの情報フローを混乱させる方法

公開: 2022-03-11

私はキャリアの過程でかなりの量のビジネスプロセスリエンジニアリングを行ってきましたが、私が見つけた最大の問題は常に同じです。それは開ループビジネスプロセスです。開ループプロセスは主に、責任が複数の人に、そして多くの場合複数の部門に分割されているために発生します。研究開発で新しい機器の要求から始まる情報フローは、組織の境界を越えてベンダー（複数の部門を順番に通過する）に到達する前に財務と購買を通過し、最終的には受信と受信に戻ることができます。運が良ければ、フローを開始したR＆Dグループ。

各段階でコミュニケーションが途絶える可能性があり、プロジェクトマネージャーはこれらのリスクを軽減する必要があります。ビジネスプロセスに組み込まれている情報フローが、例外をキャッチして処理するように明示的に構造化されていない場合、障害はかなり後になるか、まったく検出されない可能性があります。一部の情報フローの失敗により、比較的重要でないアイテムが正しく注文または配信されなくなるだけですが、他の失敗は、組織に莫大な費用をかけたり、ミッションクリティカルな活動に遅延を課したりする可能性があります。

オープンループは数百万ドルの費用がかかる可能性があります

この点を説明するために、最初に、追跡できなくなった数億ドルの機器に税金を支払っていて、この不要な費用を削減したいと考えていた大手製薬会社について説明します。私たちのプロジェクトは、多くの根本的なプロセスの欠陥を発見しました。そのすべてが、年間数千万ドルの不要な税金を追加し、同じものを誤って何度も注文することにさらに多くの費用が費やされました。

責任範囲間の一方向のコミュニケーション

すべての大規模な組織と同様に、責任はサイロにありました。製造業の誰かが機器Xを必要としているので、彼らは財務に通知し、発注書（PO）が生成されます。注文すると、POがベンダーに送信されます。最大1年後、XはReceivingによって配信され、受け入れられます。受信は製造と財務に通知します。財務部門は資産タグを発行します。これは、受信がXに平手打ちされます。Xは生産ラインに配置され、すべてが順調です。

を除いて、すべてがうまくいっていません。まず、従業員が出入りします。同じ役割の誰かが9か月前にXを注文したことに気付かずに、Xを注文するのは簡単です。財務部門は、この注文が重複していることを認識していません。単に別のXが必要であると想定しているため、別のPOが生成され、別の注文が出されます。それとは別に、誤って過剰注文しなくても、すぐに自分の持っているものを見失ってしまいます。

Xが複雑な機器であり、おそらく充填仕上げラインであると仮定しましょう。それは20の主要なコンポーネントで構成されており、そのすべてがその任務期間中に複数回交換されます。 Xの一部に無計画に貼り付けられたアセットタグは、傷みにより消えます。さらに悪いことに、アセットタグは、時間内に受信に到達しないため、適用されない場合があります。その後、誰もXを追跡する方法がわからないため、寿命が尽きたときにXを廃止する方法がわかりません。税の観点から、Xはまだ機能している課税対象品目です。

20年以上の間に、これは重要ではない方法で収益を損なうようになります。さらに、FinanceはERPシステムの一部を1セットの資産指定子とともに使用していますが、Manufacturingはまったく別のERPモジュールを別のセットの資産指定子とともに使用しています。年末現在、2組の数値を一致させることはできず、監査人は、資本設備に関して数千万ドルまたは数億ドルの不一致がある理由を疑問視しています。

これらは、一連のオープンループビジネスプロセスから生じる典型的な問題です。開ループとは、プロセスフローラインに沿って明示的な確認ポイントを構築しない場合です。上記の例では、非常に多くの開ループプロセスがあったため、障害が保証されていました。

双方向の情報フローの作成

これが私たちがこの問題に取り組んだ方法です。すべての重要なプロセスフローを最初から最後までモデル化しました。すべてのオープンループを特定しました。次に、最初からループを1つずつ閉じる簡単な方法を設計しました。

第一歩

製造業にはXが必要なので、財務部門にPOを開くように依頼します。現在、FinanceはManufacturingに確認を依頼し、24か月前のXの以前の注文の詳細を提供しています。誤って注文が重複することはありません。

ステップ2

製造業は、勤務期間中に交換されるXのコンポーネントの内訳を財務に提供します。財務部門は各コンポーネントの資産タグを作成し、製造業に確認します。両方のERPモジュールには、コンポーネントごとに一致するアセットタグが設定されているため、アセットのライフサイクル全体を追跡できます。

ステップ3

受信は財務に通知し、財務は製造に通知します。アセットタグの配置は、各タグが正しいコンポーネントに配置されるように、製造の責任者によって行われます。次に、2つのERPモジュールのすべてのタグ/コンポーネントが再確認されます。

ステップ4

コンポーネントが交換されるたびに、ManufacturingはFinanceに通知し、そのコンポーネントの新しいアセットタグが生成され、Manufacturingによって新しいコンポーネントに配置され、両方のERPモジュールで確認されます。次に、Financeは、ManufacturingがGood Practice Guide（GMP）の廃止プロセスを実行している間に、古いコンポーネントを帳簿から削除するプロセスを開始します。廃止措置の終了時に、ManufacturingはFinanceに通知して、資産を帳簿から削除できるようにします。

詳細はこの単純化された例よりも少し複雑ですが、要点は明らかです。道路沿いのすべての段階で、明示的なチェックと確認があります。

緊急時対応の確保

別のプロジェクトでは、サービス会社が顧客満足度を向上させるのを手伝うように頼まれました。彼らのビジネスはすべてクレーム処理に関するものであり、彼らは入札に勝てないことを懸念していました。さらに、彼らの落札では、その後の顧客からの不満は、彼らの失った口座比率が高すぎることを意味しました。

問題の核心を特定するのにほんの数日しかかかりませんでした。それは再び開ループプロセスでした。見込み客が入札を要求すると、アカウントマネージャーは内部システムを使用して、入札を組み立てる責任者にクライアント要件の概要を送信します。次に、入札作成者は入札を作成し、それをクライアントに転送します。うまくいけば、クライアントは最終的に、通常は必要な変更を加えて応答し、入札作成者はそれを次のバージョンに組み込みます。ある時点で、クライアントは入札を受け入れ、新しいクライアントアカウントが経理によって作成され、請求書が作成され、オンボーディングチームがブリーフィングされます。

最初の問題は、入札作成者からアカウントマネージャーへの明示的な確認がなかったため、入札が作成されて時間どおりに送信されず、誰もそれを知らなかったということでした。これが可能だったのは、内部システムに入札の期日を表示するフィールドがなく、入札の作成者が絶えず過労であったため、入札の提出が遅すぎたためです。ビジネスにおける情報の流れが悪いため、これらの状況は決して表面化しませんでした。

その後、入札の変更はアカウントマネージャーに送信されませんでした。クライアントが最終的に点線で署名したときにオンボーディングチームにブリーフィングしたのはアカウントマネージャーであったため、これは重要でした。多くの場合、ブリーフは、クライアントが実際に受け入れた入札ではなく、アカウントマネージャーの最初の理解に基づいていました。

エンゲージメントが開始されると、クライアントドキュメントが到着し、その週に処理プールに割り当てられたチームメンバーに転送されて処理されます。受領の明確な確認がなかったため、クライアントが処理作業の結果を受け取らなかった理由を尋ね始めるまで、誰もその事実に気付かずに文書が失われる可能性がありました。

処理されたドキュメントがクライアントに返送されたとき、受信時に確認がなかったため、どこかで誰かが不在について不満を言うまで、不足しているドキュメントは表示できなくなりました。

重要なイベントを確認する

入札プロセスの各ステップで、明示的な確認を組み込みました。システムの欠点に対する回避策を作成し、必要な日付やその後の入札の変更など、すべての重要な情報を取得できるようにしました。社内および会社とクライアント間のビジネスにおけるすべての情報フローに対して、明示的なチェックと確認を実装しました。

たとえば、クライアントがドキュメントパッケージを送信すると、クライアントのアカウントマネージャーに電子メールが送信されて通知されます。クライアントアカウントマネージャーは、これを請求処理の責任者に転送します。 3日以内にドキュメントが受信されなかった場合、アラートが発生します。書類を受け取ると、受け取りを確認するメールがクライアントに送信されました。会社が処理済みのドキュメントをクライアントに送り返したときも、その逆が当てはまりました。

ほとんどのクライアントが米国の郵便を使用してハードコピー文書を前後にシャッフルしたため、各ステップで明示的なチェックを使用する閉ループプロセスにより、紛失した文書をすばやく特定し、状況を修正するための手順を実行できました。

設計例外処理手順

例外処理手順を合理的に軽量で効果的な方法で構築する方法を確認するために、私が科学研究機関のCIOであったときに、原因の調査に焦点を当てた私のキャリアで遭遇した別の実例を見ていきます。加齢と加齢性疾患の引き金。

NIHが資金提供するすべての研究機関には、多くの個別の研究室があり、それぞれがプリンシパルインベスティゲーター（PI）によって運営され、さまざまな部下の科学者やポスドクが配置されています。ある時点で、PIは新しいマルチチャンバー試薬トレイを必要とするため、ポスドクの1人に必要なリクエストを作成するように依頼します。ポスドクはリクエストを作成し、それを財務部門に電子メールで送信してPOの発生を要求し、PIにccを送信して、リクエストが送信されたことをPIが認識できるようにします。一方、PIには自動カレンダー通知が設定されており、特定の日付までに確認を受け取っていない場合は、リクエストのステータスを確認するように通知されます。これにより、ポスドクが必要なリクエストの作成または送信を忘れた場合のフェイルセーフメカニズムが保証されます。

現在、ポスドクは同様に、設定された期間内にPOが発生したという確認を受け取らなかった場合に、財務部門にチェックインするための自動カレンダー通知を持っています。財務部門がPOを引き上げると、ポスドクはベンダーに送信されたことを示す確認メールを受け取り、ポスドクはこの確認をPIに転送します。

この段階で、PIまたはポスドクのいずれかが別の自動カレンダー通知を設定して、設定された期間内にベンダーから何も返事がない場合、誰かがベンダーに確認してPOの受信とディスパッチを確認します注文された機器。

ベンダーがPOの受領を確認し、ディスパッチ通知とともにアイテムをディスパッチすると仮定すると、これはPIまたはポスドクにルーティングされます。次に、受領予定日から3日間の最終カレンダー通知を設定して、アイテムが表示されない場合に、ベンダーに連絡して何が起こったかを追跡し、アイテムが正しく配信されるようにします。アイテムが計画どおりに到着した場合、ポスドクは財務に通知し、組織が資産タグを採用している場合は、この一連のプロセスを開始できます。

途中のすべてのステップで、明示的な確認が必要であり、メインプロセスフローが中断された場合に修復アクションが確実に発生するようにサブプロセスを利用できます。ぶら下がっている、確認されていない、またはサポートされていないものはありません。誰もが何が必要で、問題が発生した場合に何をすべきかを知っているので、その場限りのアクションは必要ありません。

SQLから閉ループプロセスを作成する方法を学ぶ

優れたプロセスの本質は、トランザクションの一貫性を確保するためにSQLベースのリレーショナルデータベースが設計された方法と非常によく似ています。アクションが完了したと見なされるには、アクションを確認する必要があります。すべての双方向通信には、プロセスの一部として組み込まれた明示的な確認が必要であり、確認が受信されない場合に正しいアクションが実行されるように従属プロセスが開発されています。成功するプロジェクトマネージャーは、ビジネスの情報フローを改善し、組織に多大な時間とお金を節約するために、閉ループプロセスを作成する必要があります。