一般的に理解されているALCOAで十分か
ライフサイエンス分野では、データインテグリティは非常に一般的な概念ですが、しばしば無視されて、システムにのみ関連づけられます。 ALCOAについても、誰もが知っていますが、そのコンセプトはシステムのみに関連づけられることが見うけられます。
Attributable(帰属性):情報を誰がどのように受け取ったかについて本格的な分析を行う代わりに、バリデーション中にテストするシステム上の監査証跡に、通常はまとめられています。場合によっては、情報は非公式な方法で収集され、その後、バッチ記録(署名および検証済み)にコピーされ、情報システムに再度コピーされます。チェーンは、常に実証できるわけではありません。しかし、システムには、それを証明する重要なテストによる監査証跡があります。
Legible(判読性): 一般に、保存されているデータへのアクセスができることに重点が置かれており、「データの意味」については考えられていません。例えば、品目マスターに「モノ言う」コードがあることがよくあります。1xxxが購入した原材料、2xxxが生産した資材だとします。この生産チェーンが変更されると(中間品、完成品を購入していた) 、情報が古くなり、誤解を招く可能性があることは明らかです。CMOの別の例: 顧客書類に関連して、CMOは異なるベンダー(ソースリスト)を使用する義務があります。一般的な方法は、品目/ベンダー/製造業者ごとに品目コードを作成することです。この情報は購買には明確ですが、倉庫、計画、生産には誤解を招きます。
C+O+A: Contemporaneous(同時性)、Original(原本性)、Accurate(正確性)は、ALCOAの中で最も考慮されていない部分ですが(あまり技術的でないため)、最も重要でもあります。多くの場合、情報システムは、情報処理工程の最後になっており、その中間に紙ベースの作業があり、紙ベースの情報とシステムベースの情報との間の対応が完全とは言えない場合があります(データ検証やダブルチェックについて話しているのではなく、紙ベースの情報とシステムベースの情報の違いについて話しています)。よくある例を使うと、通常、紙ベースでは、資材の入荷時に、ステータス管理のチェックリストを使います。この場合、何か問題があると、多くの場合、倉庫は資材を送り返して逸脱を起票しますが、ERPシステムでは何も行いません。したがって、システムのAPR/PQR(年次製品レビューや製品品質レビュー) で、入荷したバッチが返送されたという証拠が示されずに、問題となります。
システムが古いデータを扱うことで同時性が欠如することは、情報システムにとって最大の脅威です。典型的な例には、紙ベースのバッチ記録(BRレビュー後)に基づく生産時の原材料の消費が含まれます。これには在庫に差異が生じる可能性があります。別の例は、バッチ到着時にブレンドされるタンク内です。システム内で完了する場合、タンク内に入ってくるバッチがなくなれば、これで対応は十分です。
|
Example of differences between physical flow and information flow
|
TO BEシナリオの効果的分析の定義という問題に直面したデジタルガバナンスの経験について
デジタルガバナンスは、以下の2つの点で機能します。
- 企業が、IT部門を組織し、戦略的な実装計画作成に役立ちます。
- 情報システムの処理フローと物理フローの同期を支援します 。
効果的分析には、何度に耳にしているように、目に見える変化の抵抗と向き合うことが重要です。 例えば、
- 「私たちは、他の人とは違います」
- 「私たちには、柔軟性が必要です」
- 「私たちには、これはすでに完了しており、単なる練習です。」
- 「実際のシステムには、いくつかの変更だけが必要です。」
- 「変更するには、もっと人員が必要です。」
- 等々
重要なポイントは、次の3つです。
- PQEのノレッジベース(25年と数千のプロジェクトから構築)に基づいた分析では、現状の状況を一旦「忘れ」、TOBEシナリオをユーザーに提供します。ナレッジベースの利用は、ユーザーがシステムで何をできるか理解するのに役立ちます。そのため、使用される方法論は、標準的な現状からTOBEまでの分析とは異なり、より効果的です。
- 多機能作業グループを作成します。これは、一部の(見落とされた)活動の結果を、理解してもらうのに非常に役立ちます。多くの場合、工程の最初の段階で、主要な作業を行うことで、大幅な節約が可能になります(たとえば、資材/サービスのみが必要な場合は、完全な発注をしないほうが簡単ですが、後で、財務部門が請求書の検証などに、さらに作業をする必要があります)。フロー全体をカバーする分析チームが存在する場合にのみ、どの作業が効果的で、どの作業が効果的でないのか(多くの作業が見つかっています)、または重複した作業はないのか、を理解することができます。
- 料金と人材のバランスをとる必要があるため、管理職の関与が重要です。全体的な節約では、一部のステップ(通常は開始時)には必要な作業が多くなり、他のステップ(通常は最終および制御ステップ)では必要な作業が少なくなる場合があります。
この種の活動が完了していない場合でも、始めるのに遅すぎることも早すぎることもありません。
もちろん、情報チェーンの効率の向上には、特定のリクエストから分析を開始するのが最善です。通常、これらのケースは、次の事項からシステムをより効果的に使用する必要性があります。
- 情報チェーン内でより効率的なフローを実現し、使用中のシステムをより効果的に使用できるかどうかを検証するリクエスト(バッチ記録管理、生産プログラミングと管理、在庫管理の最適化が、最も頻繁に起こる問題点)
- ERPと機器の統合によるビジョンインダストリー4.0を工場で推進する必要性
混乱期間(必要な大きな変更のリリース、予測される組織変更)は、サプライチェーンと情報チェーンをオーバーラップさせるために分析を実行する必要がある重要な機会です。
- 到着時に、既に使用されているシステムに非常に多くの重大な問題があることが判明し、企業はシステムを変更する必要があるのか、それとも、システムの使用方法に問題があるのか、を理解したいと考えていることがあります。典型的な例は、社内基準を使用するのがより困難な工場/子会社が存在する企業や、組織の影響が過小評価されている中小企業です。PQEの他のベンダーからの独立性は、分析の正確性にとって重要な点となります。
- リクエストが進行中のERPプロジェクトに関連している場合があります。(主に製品主導のプロジェクトの)最終段階で、ユーザーが期待した機能を確認できないことがよくあり、このような場合、変更管理が過小評価されるのが一般的です。私たちはこうしたプロジェクトを多く見てきましたが、一般的に企業はプロジェクトを終了して、その後、修復することを好みます。場合によっては、プロジェクトが正しく管理されておらず、いつ終了するかを知ることが不可能です (例えば、Go Live日の延期など)。この場合は、分析を行って実際の状況を把握し、返金またはプロジェクトを再開することをお勧めします。
- 他のケースはバリデーション活動に関連します。場合によっては、バリデーションは、企業がGMP工程に準拠するようにシステム改善ができるかどうかを知りたいという合意でもあります。
したがって、どの段階でも、物理フローをマッピングし、提供情報と同期する分析は、常に有益です。
記事の全編はこちらをお読みください 。