作業指示アプリの概要
  • 18 Jan 2024
  • 1 読む分
  • 寄稿者

作業指示アプリの概要


Article Summary

::: (info) () アプリをダウンロードするには、以下をご覧ください:ライブラリ:::作業指示アプリ・スイートの概要は、どのテンプレートがお客様のニーズに最適かを判断するのに役立ちます。

作業指示書アプリの定義

作業指示書は、一連の手順で構成されています。作業指示書をアプリケーションに組み込むことは、簡単かつ明瞭に作業指示書を完成させるために、アプリの機能を活用することを意味します。作業指示書は、組み立てや検査などの手順を通じてオペレータを導くための手段です。手順は、指示内容を含む一連の作業で構成されています。全体的なプロセスは、手順を組み合わせて完全な作業指示書となる。これらの概念の階層を以下に示す:

Process Hierarchy.jpg

全体として、作業指示書は、手順や作業を通じてオペレーターを歩ませることで、プロセスの遂行を支援します。しかし、作業指示書アプリを作成する場合、どこから始めるべきでしょうか?

チューリップは、ニーズに応じて異なる一連のテンプレートを提供しています。作業指示書に最適なアプリを選ぶために、各アプリの機能を正確に把握しましょう。

作業指示書アプリ・スイート

作業指示書アプリは、アプリベースとテーブルベースの2つのカテゴリに分かれています。アプリベースの作業指示書とテーブルベースの作業指示書の違いを理解することは、ニーズに最適な方法を選択する上で非常に重要です。

アプリベースのテンプレート

アプリベースの作業指示書は静的で、アプリ内にエンコードされます。データはCompletionレコードに集められ、これはアプリのデータの不変レコードである。

単一手順

このアプリは、各タスクが1つのステップに表示される単一の作業指示手順を処理します。オペレータは、タスクを実行し、必要な入力フィールドを記録することで、手順を完了します。

WI Single Procedure.gif

欠陥レポートステップでは、応答を変数に保存するフィールドを使用して、欠陥レポートを入力できます。これらの変数は、ユーザーがCompleteをクリックすると保存され、ボタン上のトリガーがすべてのアプリデータを完了レコードに保存します。

WI Single Procedure Analytics.png

最後に、Analyticsステップは、アプリがユーザーによって完了された場合にのみデータを表示する一連の分析ウィジェットで構成されます。完了レコードがない場合、分析に使用するデータはありません。

複数手順(ステップごとに1タスク)

このアプリは複数の作業指示手順を扱い、各手順は別々のステップグループに分割され、個々のタスクはそれぞれのステップに表示されます。オペレータは、どの手順を通過するかを選択し、各ステップは、ステップ上の指示に従ってユニットを完了するようユーザに促します。

WI Multiple Procedure (1 per step).gif

各作業ステップにある[Log Defect](欠陥の記録)ボタンで、オペレーターは材料の欠陥とその詳細を記録することができます。すべてのデータはReport Defectボタンをクリックすると保存されます。

分析ステップは一連の分析ウィジェットで構成され、アプリがユーザーによって完了された場合のみデータを表示します。完了記録がない場合、分析に使用するデータはありません。

複数プロシージャ(すべてのタスクを1つのステップ)

複数手順(1ステップ1タスク)アプリと同様に、このアプリは複数の作業指示手順を扱い、各手順は別々のステップグループに分かれています。複数手順アプリの主な違いは、このアプリが手順ごとに1ステップのタスクを表示することです。オペレーターは、どの手順を進めるかを選択し、次のステップですべてのタスクを完了します。

WI Multiple Procedure (Multiple step).gif

各タスクステップにあるLog Defectボタンにより、オペレーターは材料に欠陥があった場合、その欠陥の詳細を記録することができます。すべてのデータは欠陥報告ボタンをクリックすると保存されます。

分析ステップは一連の分析ウィジェットで構成され、アプリがユーザーによって完了された場合のみデータを表示します。完了記録がない場合、分析に使用するデータはありません。

テーブルベースのテンプレート

テーブルベースの作業指示は動的で、テーブル自体にエンコードされている。アプリでの選択とオペレーターからのデータがテーブルに保存されます。テーブル内の情報は不変ではなく、テーブルにアクセスできる人であれば誰でもテーブル内のデータを変更できます。

1ステップ1タスク

このアプリは、複数の作業指示手順を処理します。オペレータは、最初に選択した手順に基づいて、手順タスクをステップバイステップで実行します。このアプリは、プロシージャーと タスクの2つのテーブルを使用します。ユーザーがインタラクティブテーブルからプロシージャーを選択すると、プロシージャーIDはタスクテーブルの関連タスクと相関します。

WI One Task per Step.gif

集計は、テーブル内のタスクIDのモードを経由してフィルタリングすることにより、選択されたプロシージャー番号を持つタスクのみを次のステップにロードします。

WI One Task per Step Aggregation.png

IDをフィルタリングすることにより、選択された手順に関連するタスクのみが表示されます。このダイナミックな設定により、オペレーターは、選択したプロシージャーとタスクに基づいて、異なるプロシージャーとタスクを完了することができます。

各タスクステップの[Log Defect](欠陥のログ)ボタンにより、オペレーターは材料に欠陥があった場合、その欠陥の詳細をログに記録することができます。すべてのデータは欠陥報告ボタンをクリックすると保存されます。

分析ステップは一連の分析ウィジェットで構成され、アプリに参照するデータがある場合にのみデータを表示します。レコードがない場合、分析に使用するデータはありません。

プロシージャー スクローラー

このアプリは、複数の作業指示手順を処理するために使用されます。プロシージャは、オペレータが参照する関連する作業指示を選択すると入力されるテーブルに格納されています。

WI Procedure Scroller.gif

ユーザーがSelect Procedureステップでプロシージャーを選択すると、その選択は、ステップの右側にプロシージャーの情報を入力するLinked Placeholderに保存されます。Tasksステップでは、インタラクティブテーブルのタスクは、前のステップで選択されたプロシージャーIDからフィルタリングされます。

WI Procedure Scroller Task Filter.png

Tasks(タスク)ステップのLog Defect(欠陥の記録)ボタンで、オペレーターは材料に欠陥があった場合、その欠陥の詳細を記録することができます。すべてのデータはSubmit Defectボタンをクリックすると保存されます。

分析ステップは一連の分析ウィジェットで構成され、アプリに参照するデータがある場合にのみデータを表示します。レコードがない場合、分析に使用するデータはありません。

プロシージャー・ビューアー(モバイル)

Procedure Viewerアプリケーションは、Procedure Scrollerアプリのモバイル版です。最初の画面から、オペレーターは、プロシージャーを選択プロシージャーをスキャン、または現在までに完了したプロシージャーに関するアナリティクスを表示することができます。

WI Procedure Scroller (Mobile).gif

プロシージャー・スクローラー・テンプレートと同様に、オペレーターがプロシージャーを選択すると、プロシージャーIDが使用され、それぞれの記録で同じIDを共有するタスクを引き出します。

WI Procedure Scroller Task Filter.png

オペレータがプロシージャーをスキャンすると、そのIDは、マシンとデバイスセクションの次のステッ プレベルのトリガーでタスクフィルターにロードされます:

WI Procedure Scroller (Mobile) Load Procedure by ID.png

タスクの詳細情報を収集するには、[タスクの表示]ステップで[**詳細の表示]**を選択します。View Details]ステップは、テーブルレコードから選択したタスクの情報をロードします。

各タスクステップの[Log Defect](欠陥のログ)ボタンで、オペレータは材料の欠陥とその詳細をログに記録できます。すべてのデータはSubmitボタンをクリックすると保存されます。

分析ステップは一連の分析ウィジェットで構成され、アプリに参照するデータがある場合にのみデータを表示します。レコードがない場合、分析に使用するデータはありません。

パラメータ付き手順スクロール

このアプリは複数の作業指示プロシージャを処理します。手順は、オペレータが関連する作業指示タスクを選択できるスクロール要素に入力するテーブルに格納されます。このバージョンには、作業指示パラメータを保存するための追加のテーブル、パラメータが含まれています。

WI Procedure Scroller with Parameters.gif

パラメータを使用して、特定の車種にルーフラックを追加したり、はんだごての温度を特定の範囲内に保つなど、作業指示タスクに制限を設定します。

タスクステップの[不具合ログ]ボタンにより、オペレータは材料の不具合をログに記録し、不具合の詳細を確認することができます。すべてのデータはSubmit Defectボタンをクリックすると保存されます。

分析ステップは一連の分析ウィジェットで構成され、アプリに参照するデータがある場合にのみデータを表示します。レコードがない場合、分析に使用するデータはありません。

プロシージャー作成

このアプリを使用して、本App Suiteのテーブルベースのテンプレートで提供されるそれぞれのテーブル(Procedures、Tasks、Parameters)に手順、手順ステップ、およびパラメータを追加します。

WI Procedure Creator.gif

**追加]**ボタンを使用して、ユーザーは選択したプロシージャ、タスク、およびパラメータを追加し、[編集]ボタンを使用して選択したプロシージャ、タスク、およびパラメータを変更できます。

Procedure Creatorアプリは、テーブルベースの作業指示アプリのテーブルを作成、編集、整理するためのアプリにすぎません。

ニーズに合ったテンプレートの選び方

テンプレートを選ぶ際に最初に決めるべきことは、アプリベースかテーブルベースか、あるいはその両方をミックスするかです。チューリップのサービスでは、アプリベースのソリューションから始めることを推奨していますが、シナリオによってはテーブルベースの方が良い場合もあります。これらのテンプレートタイプに必要なすべてのオプションと設定方法を検討するためには、アプリベースとテーブルベースの作業指示書を理解することが重要です。

まず、アプリベースとテーブルベースのテンプレートがより有用である具体的な表示について説明しよう。

App-basedTable-based
Low-mix processHigh-mix process
Logic-dependent or branching progression through the applicationCommon app progression
Regulated industries where procedures must be tightly controlled, with all changes approvedLess regulated industries where the emphasis is on efficiently delivering work instruction content, which can be changed quickly across many interfaces
Process settings (such as torque,プロセス設定(トルク、温度、ツーリングなど)は、製品ファミリ間で標準的であり、比較的少数である|プロセスは高レベルでは同じかもしれないが、設定やパラメータはSKUに大きく依存し、テーブルから共通アプリにロードできる|ワークフロー全体を通して、デバイスや可変ユーザー入力への依存度が高い|プロセス全体を通して、デバイスや可変ユーザー入力への依存度が低い|ワークフロー全体を通して、デバイスや可変ユーザー入力への依存度が高い|ワークフロー全体を通して、デバイスや可変ユーザー入力への依存度が低い|ワークフロー全体を通して、デバイスや可変ユーザー入力への依存度が高い

ワークフローにアプリのパスを合わせることで、アプリがプロセスに沿い、手順やタスクの暫定的な変更やパラメータに対応できるようになります。これらの変更またはパラメータがプロセスのどこに現れるかによって、アプリの構成やアプリの数が決まります。

次の図は、あなたが独自のアプリを設計したり採用したりするときに従うとよい、一般的なアプリのパスを示しています:

Pretty App Patterns.png

たとえば、Single Procedureと One Task per Stepアプリケーションは直線的なパスをたどりますが、Procedure Scrollerと Procedure Viewerアプリケーションは設定可能なパスをたどります。どのアプリのパスが自分のニーズに最も適しているかわからない場合は、プロセスと、アプリの動作に影響を与える潜在的なバリエーションやパラメータ設定をマップしてください。

もう1つ考慮すべき点は、プロシージャーとそれぞれのタスクを含むプロセスの広がりです。

例えば、2つの新車モデルを製造するとします。1つは高級モデルに基づいた特定のパラメータを持つモデル、もう1つは標準的な機能を持つモデルです。製造する車種を選択することで、手順が決まります。プロセスはこのようになる:

WI Example Process Diagrams.png

異なるモデルに複数のアプリを使用し、データを保存するために完了レコードを使用して、アプリに静的に命令を格納することができます。または、1つのアプリを使用し、オペレータの選択に基づいてアプリケーションに動的に命令をロードすることもできます。これら2つのオプションの例を以下に示します:

WI App-based Design.png

アプリベースの設計では、各作業指示アプリからのデータは別々の完了レコードに保存されます。こうすることで、レコードが重ならず、互いに区別しやすくなります。

WI Table-based Design.png

テーブルベースの設計では、同じアプリケーションを使用して指示をホストしているにもかかわらず、各作業指示プロセスからのデータは別々のテーブルに保存されます。

どのタイプのアプリケーションを選択すべきかまだわからない場合は、以下のフローチャートに従って、どのような構成のニーズがあるかを評価してください。

Flow Chart Final.png

ニーズに最適なアプリを設計するための詳細とリソースについては、チューリップ大学の作業指示ソリューション設計コースを受講してください!


この記事は役に立ちましたか?