初めての現場ダッシュボードを作成しましょう

初めての現場ダッシュボードの作成方法

TulipのApp Editorでインタラクティブなダッシュボードを構築する方法

Tulip では、生産目標の達成に向けた進捗状況を可視化するために、2 種類のダッシュボードを作成できます：

デスクトップダッシュボード：Tulipの管理者や経営陣間で、メールやライブストリーミングリンクを介して共有することを目的としています
現場ダッシュボード：生産現場のテレビやタッチスクリーンからアクセスできるように設計されたもの

現場用ダッシュボードは、現場の紙のチャートやホワイトボードに代わるものとして広く利用されています。これにより、チームメンバーなら誰でもその日の作業状況を可視化できます。

その外観は次のようなものです：

しかし、ダッシュボードを作成する前に、まずすべてのデータを収集する一連の製造用アプリを計画する必要があります。これは、生産現場の複数の役割に対応するアプリを同時に考えなければならないため、精神的に負担の大きい作業になり得ます。

そこで、ある企業がTulipを使用して、現場のKPIを総合的に測定できる複数の種類のアプリをどのように作成したか、その例をご紹介します。

そのプロセスの概要は以下の通りです：

改善したいKPIを特定します。
成功を判断する上で重要な、すべての主要指標を網羅したダッシュボードを1つ作成する
各KPIに関連する作業が行われている現場の各ステーションごとにアプリを作成する
それらのアプリ内で、集計が必要な個々のデータポイントを追跡する変数を作成します
アプリから取得した変数を使用して、各KPIを詳細に分析する個別の分析を作成します。
それらの分析を、各KPIを詳細に掘り下げるステップとして、上位レベルのダッシュボードと同じアプリに組み込みます

以下に、このプロセスの概要図を示します：

Tulipでは、App Editorを使用して現場用ダッシュボードを構築し、アプリのあらゆるインタラクティブ機能を活用できます。その後、現場のタッチスクリーンでTulip Playerを実行することで、チームメンバーなら誰でも指標を詳細に分析できるようになります。

プロセスの図は以下の通りです：

注：このチュートリアルを利用するには、Tulipの「App Editor」および「Analytics Builder」の基本を理解している必要があります。

KPIの選定

ダッシュボードや製造用アプリの作成に取り掛かる前に、対処すべき課題を特定しましょう。

このガイドでは、次のような課題を抱える自転車工場を例に挙げます：

高い不良率：初回歩留まりが低すぎるが、その根本原因が特定できていない。
生産状況の可視化が不十分：生産データは紙のシートに記録されているか、あるいは全く記録されていないため、個々の工程のサイクルタイムが不明確である。
機械の稼働率／ダウンタイム：稼働率の割合がどこにも記録されていないため、チームはベンチマークや目標を設定できない

これらの課題に対処するため、この自転車工場は以下の点に焦点を当てることにしました：

手直し・廃棄率：どの製品や作業ステーションが手直しや廃棄につながっているかを把握する
製品ごとのサイクルタイム：各SKUや作業指示書が各工程でどのくらいの時間を費やしているかを把握する
機械・作業ステーションごとの稼働率：どの機械・作業ステーションがボトルネックとなっているか、あるいは稼働率が低いのかを把握する

ここで課題となるのは、これらのKPIが現場の複数の作業ステーションの影響を受けるという点です。そのため、プロセスエンジニアは複数のアプリからのデータを統合し、複数のデータソース（現場のオペレーターステーションや機械）から根本原因を特定する必要があります。

概要ダッシュボードの構築

以下は、前述のKPIを追跡するために現場のタッチスクリーンに表示されるダッシュボードの例です：

このダッシュボードは、自転車工場が改善すべき各KPIを網羅しています：

「生産台数」は、1日の間に製造された自転車の台数を追跡します。
「手直し率」は、手直しが必要な部品を追跡します。
「スクラップ率」は、廃棄しなければならない部品の割合を追跡します。
「メンテナンス（週次）」は、メンテナンス点検中に発見された問題を追跡します。
「機械稼働率」は、現場で最も重要な機械の稼働時間と停止時間を追跡します。

この現場ダッシュボードにより、オペレーターやプロセスエンジニアは以下のことが可能になります：

複数の日付範囲（今日／昨日／先週など）にわたる指標を確認する
リアルタイムの生産データを目標値と比較する
「詳細」ボタンをクリックして、個々のKPIをさらに掘り下げ、より詳細な指標を確認する
「サイクルタイム」ボタンを使用して、現場のボトルネックを確認する

このケースでは、自転車製造ラインに5つの独立したステーションがあるため、「サイクルタイム」では、5つのステーションそれぞれのサイクルタイムの比較が表示されます。

ここで難点があります。このダッシュボードは、実際には10個の別々の製造アプリからデータを取得しているのです。

ここでは、個々のアプリを順に確認し、各アプリがこのダッシュボードのためにどのようにデータを収集しているかを説明します。アプリの種類は以下の通りです：

「作業指示」アプリは、オペレーターがタスクを完了するための一連の作業指示を提供します。オペレーターが作業を完了し、「完了」ボタンを押すたびに、タクトタイムを追跡します。これらのタクトタイムは個々のSKUごとに区分されており、オペレーターは各製品のバーコードをスキャンすることでSKU情報を登録します。そのSKUデータは、各アプリの完了時に変数を介して保存されます。
梱包ステーションでは、ヘッドレスアプリが使用されます。これは、オペレーターがTulip Edgeデバイスに接続された生産ライン上のボタンを押した際に、アプリがデータを追跡することを意味します。オペレーターはアプリ自体を操作することはありません。
各品質管理アプリは、品質管理担当者が持ち歩くタブレット上で継続的に動作します。担当者は部品を検査するたびに、タブレット上で作業内容を記録します。
保守アプリは、保守技術者が持ち歩くタブレット上で動作します。保守技術者が週次巡回を行う際、アプリを通じて問題を記録します。問題はフォームフィールドに記録されます。このアプリは、巡回が完了したかどうかの状態のみを表示します。詳細をクリックすると、週次巡回のどの部分が完了し、どの部分が未完了であるかを確認できます。
機械監視アプリもヘッドレスアプリです。このアプリは、サイクルタイムが最大30秒に設定された機械に接続されています。稼働時間中に30秒間機械が稼働していない場合、アプリはダウンタイムを記録します。稼働している場合は、アップタイムを記録します。オペレーター向けのインターフェースはありません。機械はOPC UAコネクタを介してTulipに接続されています。

この現場ダッシュボードを構築するために必要な、Tulipのさまざまな機能は以下の通りです：

「目標」列の各数値は静的テキストです。

「Actual」列の各数値は、「Single Number」テンプレートを使用した埋め込み分析です。つまり、これらの分析はAnalytics Builderで作成され、その後ダッシュボードに追加されました。

ダッシュボード下部のボタンをクリックすると、オペレーターはアプリ内の別のステップに移動します。各日付範囲に関連する分析を作成するには、分析をコピーし、「日付範囲」フィールドを使用して期間を変更する必要があります。

アプリの右側にあるボタンをクリックすると、各KPIに関するより詳細な分析が表示されるアプリ内の他のステップに移動します。この例では、手直し率を調査するための4つの分析が用意されています：

作業指示アプリ

各自転車のサイクルタイムを把握したい場合は、まず（この例では）現場にある4つの組立ステーションと梱包ステーションそれぞれのタクトタイムを合計する必要があります。

工場では複数の種類の自転車を製造しているため、データをSKUごとにセグメント化する必要があります。つまり、後の分析のために、タクトタイムとともにSKUを追跡するための変数をアプリ内に用意する必要があります。

作業指示アプリは、次のような構成になるでしょう：

このアプリには、一貫したデザインで構成された一連の作業手順があり、各ステップにはSKUに関する関連データが含まれています。オペレーターはいつでもアプリを「完了」させたり、「次へ」や「戻る」の矢印をタップして手順を進めることができます。

各ステーションでこのアプリのバリエーションを使用している場合、アプリの完了データを通じてサイクルタイムを把握するために、データを簡単に統合することができます。

アプリの冒頭で、作業員が次のステップに進む前に、ステーションのタブレットに接続されたバーコードスキャナーを使用してバーコードをスキャンするよう要求することができます：

このバーコードデータには、以下の2つの活用方法があります：

バーコード番号のみが必要な場合は、変数に保存できます。
コネクタ関数を使用して、SQLデータベースからSKUに関する詳細データを取得したり、MESやデータ記録システムへのAPIを呼び出したりできます。その後、そのデータを変数に保存できます

以下は、バーコードスキャン後にコネクタ関数を呼び出すためにトリガーエディタを使用する方法の例です：

「Then」ステートメントの詳細については、以下の通りです：

以下は、作業指示アプリにおける一連の処理の流れです：

アプリの開始
オペレーターがバーコードをスキャン
バーコードのスキャンが完了すると、コネクタ関数が実行され、SKUに関連するデータが取得されます
オペレーターがアプリを完了すると、バーコードデータがそのアプリの完了に紐付けられます

以下は、すべてのアプリが連携して動作する様子を示した図です。

その後、5つのステーションすべてを同じ分析に追加し、各ステーションの結果をSKUごとに分類することで、どのステーションがラインの遅延の原因となっているかを確認できます。これは「詳細分析」であるため、「サイクルタイム」ボタンを押した際にオペレーターに表示されるダッシュボード上に表示されます。

出荷ステーションアプリ

自転車工場では、1コンテナにつき6台の自転車を梱包して出荷しています。箱の梱包専用のステーションが1つあります。

この場合、作業員は業務を行うために指示を必要としません。しかし、各ケースがいつ工場を出荷されたかを追跡したいと考えています。

そこで、「ヘッドレスアプリ」を作成する必要があります。これは、ユーザーインターフェースがないことを意味します。その代わりに、アプリは、ケースの梱包が完了した際にオペレーターが押すボタンに接続されています。このボタンはTulip Edgeデバイスに接続されており、ボタンが押されるたびにTulipに通信します。

ボタンが押されるたびに、生産数を6ずつ増加させることができます。

以下は、出荷ステーションのディスプレイ上で動作する、このワンステップアプリの例です：

確かに、オペレーターは「手動増分」ボタンを使用して、技術的にはこのアプリを操作することも可能です。しかし、その操作が必要になるのは、何らかの理由で物理的なボタンが故障した場合に限られます。

データがアプリに流入する流れは以下の通りです。

アプリの完成後、このデータをMESやERPに連携させることができます。

分析

このアプリには変数が存在しないため、アプリの実行完了時に収集されるデータポイントは以下の2つです：

更新された生産数量
ステーションのタクトタイム

これは非常に単純な仕組みですので、複数の日付範囲にわたってこのデータを活用する方法を見ていきましょう。

例えば、自転車工場が平日のみ稼働していると仮定しましょう。月曜日の朝に出勤した際、「今日」以外のデータが空白のダッシュボードが表示されるのは避けたいところです。むしろ、「昨日」のデータを見たい場合、実際には金曜日のデータを確認したいはずです。

Analytics Builderでこれを実現する方法は次のとおりです。まず、日付範囲を「7日前以降」から「1日前以前」に設定します。これにより、今日までの過去6日間のデータが表示されます。

次に、「フィルター」フィールドを使用して「直近の2営業日」を選択します。これにより、今日および今日より前の直近の営業日が対象となります。

これら2つのフィールドの組み合わせが、「昨日」のデータとなります。

Analytics Builderでの表示は次のようになります：

こちらがタイムラインビューです。

Tulipで最も一般的な10のトリガー

品質管理アプリ

この工場では、2つの生産ラインの末端に品質検査ステーションが設置されており、最終製品が梱包される前に検査が行われます。ここでは、タブレット上で動作する同じアプリが使用されています。

これは4つの組立ステーションの後に実施されますが、アプリの完了時間は製品の総サイクルタイムには含まれていません。そのため、「作業指示書」のセクションではこれらについて言及されていませんでした。

また、作業員は別のSKUに移る前に、同じSKUの製品を連続して複数組み立てるため、アプリはデフォルトで、その製品のSKUが前の製品と同じであると想定しています。

アプリでの最初のステップは以下の通りです：

SKUが前の製品と異なる場合、オペレーターは「新しいデイシートIDをスキャン」ボタンを押します。これにより、バーコードスキャナーで製品をスキャンするよう促す画面が表示されます。スキャンすると、アプリはコネクタ機能を使用してMESシステムに接続し、関連データを取得します。その後、オペレーターは「合格」か「不合格」かを指定できます。

オペレーターが「合格」を選択すると、アプリ処理が完了し、ステップの左側にある変数の値が処理完了情報と共に保存されます。これにより、後でSKUごとの分析が可能になります。

オペレーターが「合格」を選択した場合、フォームステップに遷移し、そこで欠陥を選択できます。欠陥を選択した後、アプリを完了させることができます。

以下に、アプリのロジック図を示します：

コネクタ

このシナリオでは、品質担当者が特定の製品を検査していることを確認できるよう、バーコードスキャンによってSKUに関する特定の情報が返される必要があります。

これを実現するには、前述の「作業指示」のケースと同様に、バーコードスキャン時にコネクタ関数を呼び出す必要があります。

分析

このアプリは、欠陥のために出荷が許可されない製品の割合である「手直し率」を表示します。その計算方法は以下の通りです：

「Good」が押されたアプリの完了総数を記録する
「Reject」が押されたアプリの完了件数の合計を記録する

その後、このアプリから得られたデータを用いて、どのSKUが最も頻繁に不適合判定を受けているか、また一般的な欠陥の種類を調査することができます。

「フィルター」フィールドを使用して特定の製品を絞り込み、「数値」フィールドを使用して、「単一数値」テンプレート内で「合格」と「不合格」の比率を作成できます。

メンテナンスアプリ

工場では、毎週、毎月、四半期ごと、および 6 ヶ月ごとに、それぞれ異なる種類の保守点検が行われています。保守技術者は、アプリがインストールされたタブレットを持ち歩き、巡回中に発見した問題を記録する必要があります。

検査の種類ごとに個別の手順セットを持つ1つのアプリを作成できます。アプリの最初の手順では、技術者が検査の種類を選択できるようになります。

次に、技術者が点検しなければならない個々の機械に対応する一連の「フォームステップ」を作成します。

このアプリは非常にシンプルです。最初のルーティングステップが1つあり、その後、各点検ごとにフォームステップが1つずつ続きます。

分析

現場のダッシュボードでは、1つの数値によって、週次点検が完了したかどうかが一目でわかります。

週次点検では、ほとんどの点検で追加の作業は必要ないはずです。しかし、経時的な傾向を把握するために、どのテストに不合格があったかを知っておきたいでしょう。

テーブルテンプレートを使用して、各機器の点検における「コメント」フィールドのみを含むテーブルを作成できます。そうすることで、週ごとにどのような修正が必要だったかを確認できます。

以下は、すべての機器点検のコメントフィールドの例です。「操作」フィールドを使用して、アプリの各フォームステップからコメントフィールドを選択してください。

分析テンプレートの解説

現場ダッシュボードへの機械監視データの追加

「機械属性ウィジェット」を使用すると、個々の機械からのデータをリアルタイムで工場現場ダッシュボードに追加できます。

初めての現場ダッシュボードの作成

現場ダッシュボードにどの指標を表示したいかをイメージすることから計画を始めるかもしれませんが、実際には、現場ダッシュボードを構築する前に作成しなければならない一連の資産があります。これには以下が含まれます：

現場の各ステーションや役割に対応したアプリ
重要な詳細を追跡するための、それらのアプリ内の変数
個々の変数を詳細に分析するレポート
複数の時間枠に対応するための、それらの分析のコピー
単一のアプリ内にある一連のダッシュボード

現場用ダッシュボードをより迅速に立ち上げるためには、まずはアプリの完成データに焦点を当て、最初の概要ダッシュボードを構築することをお勧めします。その後、社内で一定の勢いが生まれた段階で、詳細な分析や複数の期間に対応したダッシュボードを構築していけばよいでしょう。

お探しの情報は見つかりましたか？

community.tulip.coにアクセスして、質問を投稿したり、他のユーザーが同様の質問を投稿していないか確認することもできます！