作業指示アプリの概要

To download the app, visit: Library
:::Work Instructions App Suite の概要について説明します。

作業指示アプリの定義

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

{高さ="" 幅=""}。

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

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

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

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

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

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

単一手順

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

{height=""幅=""}。

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

{ボタン上のトリガーがすべてのアプリデータを完了レコードに保存します。｝

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

複数の手順（ステップごとに1つのタスク）

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

{高さ="" 幅=""}。

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

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

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

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

{height=""幅=""}。

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

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

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

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

1ステップ1タスク

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

{高さ="" 幅=""}。

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

{高さ="" 幅=""}。

ID をフィルタリングすることで、選択された手順に関連するタスクのみが表示される。このダイナミックな設定により、オペレーターは選択内容に応じて異なる手順やタスクを完了することができます。

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

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

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

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

{height="" width=""}.

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

{height=""幅=""}。

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

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

プロシージャー・ビューアー（モバイル）

Procedure Viewerアプリケーションは、Procedure Scrollerアプリのモバイル版です。最初の画面では、オペレーターは「プロシージャーを選択」「プロシージャーをスキャン」「現在までに完了したプロシージャーに関する分析を表示」のいずれかを選択できます。

{高さ="" 幅=""}。

プロシージャー・スクローラー・テンプレートと同様に、オペレーターがプロシージャーを選択すると、プロシージャーIDが使用され、同じIDを共有するタスクがそれぞれのレコードに表示されます。

{高さ="" 幅=""}。

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

{height="" width=""} タスクの詳細情報を収集するには、次のようにします。

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

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

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

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

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

{height="" width=""} パラメータを使用して、作業指示の制限を設定します。

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

タスクステップの[不具合ログ]ボタンにより、作業者は材料に不具合があった場合、その不具合の詳細をログに残すことができます。すべてのデータはSubmit Defectボタンをクリックすると保存されます。

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

プロシージャー作成

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

{高さ="" 幅=""}。

**追加]**ボタンを使用して、ユーザーは、手順、タスク、およびパラメータを選択項目に追加したり、[**編集]**ボタンを使用して選択項目を変更したりできます。

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

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

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

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

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

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

{高さ="" 幅=""}。

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

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

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

{高さ="" 幅=""}。

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

{height="" width=""}のようになります。

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

{高さ="" 幅=""}。

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

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

{高さ="" 幅=""}。

ニーズにぴったりのアプリを設計するための詳しい情報やリソースについては、チューリップ大学の「業務指示ソリューション設計」コースを受講してください！