- 印刷する
あなたが、トレーサビリティのために完全な系図記録を提供する必要がある規制産業の生産管理者だと想像してみてください。オペレーターは手作業でプロセスデータを書くことに時間を費やしており、間違った測定値、下手な手書き文字、記入忘れなどのミスが発生する可能性が高くなります。このようなミスは、組織全体にダメージを与えかねないコンプライアンス上の問題につながります。プロセス・アプリのデジタル・ソリューションを導入し、標準化されたフォーマットでデータを取得することで、一般的な不一致をなくします。別のトレーサビリティ・アプリでは、データを並べ替えたりフィルタリングしたりして、プロセス改善を促進する傾向を見つけることができます。このソリューションにより、時間が節約され、エラーが発生しやすい手入力が回避され、顧客や品質保証のための明確で追跡可能なデータが作成されます。
系図とトレーサビリティにより、製造施設はas-built-configurationのコンテキストを確認することができます。ディスクリート製造の場合、これにはサブアセンブリや最終アセンブリを構成する部品番号、シリアル番号、シリアル化されていない部品や原材料のロット番号などが含まれます。このユースケースでは、構築プロセス中に取得されたすべてのデータを、メタデータ(誰が、いつ、何を行ったか、確認事項)と共にレビュー用に保存する。
このユースケースの主な目標は以下の2つである。最終顧客や監査人が利用可能な、業界準拠の系譜記録をキャプチャする 製造業ではコンプライアンスが規制の対象であるため、これは業務に不可欠な要素です。必要な基準を満たしながら、労力を最小限に抑えるデジタルソリューションで、完全な監査証跡を作成することができます。
- 前方または後方へのトレーサビリティを可能にする生産から出荷までの製品のデジタル・トレーサビリティは、説明責任を生み出します。下図は、デジタル・トレーサビリティが生産工程におけるさまざまなシナリオにどのようなメリットをもたらすかを示しています:
Scenario | Digital traceability benefit |
---|---|
Standard work:アプリのメタデータ(完成度)は、作業者情報、日付、選択された値を含むデータを自動的に保存します。 |
影響と要件
デジタルと従来の系図手法は同じ結果をもたらしますが、デジタルソリューションはより簡単で自動的なトレーサビリティを提供します。現在、プロセスで生産追跡アプリを使用している場合、系図のための重要なデータをすでに取得しています。デジタルソリューションは、各ロットの関連データを収集し、必要なときにデータを表示することで、完全な履歴を提供します。
系図の主な目標は、次のような方法でコンプライアンスに対処することです。 *コンプライアンスのコストを削減する 自動化されたデータ収集により、データの取り扱いと分析を行い、人的ミスを制限する *プロセスを簡素化し、トレーサビリティを実現する デジタルストレージにより、データを必要な人がすぐに利用できるようにする *プロセスの改善を可能にする データトレンドを利用し、問題が発生したときの特定と、その結果として改善すべき主要分野を特定する
データの可用性は、これらの目標を達成するための重要な要素である。情報の検索、フィルタリング、共有が簡単に行え、通常の紙のプロセスよりもミスが少なくなります。ペルソナによって、品質レビューや業務傾向の把握など、必要とするデータは異なる。
さらなる利点として、コンプライアンスは製品の品質向上にもつながります。これには、品質逸脱の影響を受けた仕掛品の迅速な特定と手直しが含まれる。製品品質は以下を達成することができる: *顧客満足度の向上顧客の期待に応え、リピートビジネスを構築し、顧客市場で良い評判を確立する *収益性の向上 ROIと全体的な収益を増加させるとともに、欠陥によるサービスコストを減少させる *リスクの低減 欠陥製品に起因する挫折や潜在的な罰金を回避する。
系図はすべての産業に関連し、規制された産業では必須である。このユースケースは、特定のオペレーションに応じて、複雑度は低/中程度です。例えば、マルチレベルのバッチ処理には追加の設定が必要ですが、シンプルな個別アセンブリではアプリと1対1の関係になり、データ収集が容易になります。最小限のセットアップでは、基本的なアプリの構築と、テーブルと完了レコードによるデータ収集が必要です。
始め方
デジタル系図の主な構成要素は2つある: 1.データの収集2.データを一箇所で見る
このユースケースでどのようなものかを理解するために、この2つを見ていきましょう。
データの収集
テーブルとコンプリートメントを組み合わせて、製品データとプロセスデータを保存する。
テーブル
系図は複数のプロセスで収集されたデータで構成されるため、拡張性のあるテーブル構造を確立する必要があります。スケーラブルなテーブル構造: * デジタルツインモデルに従う(物理的な場所/製造現場を反映したテーブル) * 物理的なもの(例:在庫アイテム、設備・資産)または業務上の成果物(例:不具合イベント、作業指示)を表すテーブルを持つ * マスターデータ(業務外で作成されたデータ)または完了レコード(アプリケーションのメタデータ)からの重複データを保存しない
アプリ・アーキテクチャでは、テーブル構造が各アプリを互いに接続するものです。下の図では、アプリ(青い四角)がすべて直接つながっていないことに気づくだろう。テーブル(緑の菱形)は、プロダクションを通じて作業指示情報を移動させます。
この図では、作業指示は Work Orders テーブルに格納されます。最初の組み立てステーションは、作業指示情報を使用して作業を開始します。各ステーションは、ユニットに関連するデータをユニット・テーブルに格納します。Unitsテーブル(下の例)には、各ユニットに関する情報があります。これらのレコードは、トレーサビリティ・アプリや、品質検査、梱包・出荷などの他のアプリで使用できます。
このアーキテクチャーにより、データはStations間で正確であり、複数の場所に存在することはありません。系図のために収集されたデータは様々なプロセスアプリから来るので、トリガーが適切なテーブルのテーブルレコードに書き込み、更新することを確認してください。 テーブル構造は大規模である必要はありません。Tulip Common Data Modelを出発点として、特定のニーズに合わせて調整することができます。
補完
Completionは不変のアプリメタデータを保存しますが、Variable値を保存するトリガーを設定することもできます。この情報は、アプリのセッション中に何が起こったかを知らせます。系図の場合、完了レコードはプロダクション条件に関する情報を取得します。
完了レコードは、ログのように各アプリに固有であることに注意してください。他のアプリでこの情報を使用することはできませんが、Analyticsを使用して完了データを視覚化することができます。
系譜データを一元管理
異なるプロセスからテーブルにデータを収集した後、別のアプリケーションでユニットの情報を表示したいと思うでしょう。系図アプリは、ユーザーが簡単にデータにアクセスできるようにシンプルであるべきです。
下のアプリ例では、ユーザーはインタラクティブなテーブルウィジェットからユニットを選択できます。
アプリは次のステップに進み、選択したユニットのデータをテーブルレコードウィジェットに表示します。
これは、特定のユニットの情報を取得するための基本的なアプリのデザインです。系図アプリは、記録を検索する必要がある条件に応じて、さまざまなペルソナに合わせることができます。
以下の表は、検討することができる追加のアプリ機能の例です:
Scenario | App feature |
---|---|
A quality manager notices a reoccurring issue with a produced part | Create a table filter for units that were produced during a specified datetime period |
A vendor issues a recall on one of the materials used in production | Create a table query that retrieves records that include the relevant material ID |
A customer asks to see full unit history | Export a CSV file from the interactive table widget of unit history |
チューリップのリソース
系図/トレーサビリティ・アプリを構築するためのTulipの機能について詳しく知りたい方も、Tulipの既成テンプレートを使いたい方も、ぜひご活用ください。