ショップ・フロア・ダッシュボードの作り方

31 Oct 2023
1 読む分
寄稿者

印刷する
共有

ショップ・フロア・ダッシュボードの作り方

更新日 31 Oct 2023
1 読む分
寄稿者

印刷する
共有

記事の要約

この要約は役に立ちましたか?

ご意見ありがとうございます

ショップフロア・ダッシュボードの作成方法

TulipのApp Editorでインタラクティブなダッシュボードを作成する方法をご紹介します。

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

デスクトップダッシュボードは、メールやライブストリーミングリンクを通じて、Tulipの管理者や経営陣の間で共有されます。
生産現場のテレビやタッチスクリーンからアクセス可能なダッシュボード。

現場ダッシュボードは、現場の紙チャートやホワイトボードに代わるものとして人気がある。このダッシュボードを使えば、どのチームメンバーもその日の作業を視覚化することができる。

こんな感じだ：

しかし、ダッシュボードを作成する前に、まずすべてのデータを収集する製造アプリ群を計画する必要がある。製造現場の複数の役割のアプリを一度に考える必要があるため、これは精神的に疲れる作業となります。

そこで、ある企業がTulipを使って、製造現場のKPIを一括して測定できる複数のタイプのアプリを作成した例を紹介しよう。

プロセスを簡単にまとめると、次のようになる：

改善したいKPIを決定する。
成功を決定するハイレベルな指標をすべてカバーする1つのダッシュボードを作成する。
KPIの1つに関連する作業が行われている現場のステーションごとにアプリを作成する。
これらのアプリで、集計が必要な個々のデータポイントを追跡する変数を作成する。
アプリの変数を使用して、各KPIをより深く見るための個別の分析を作成する。
各KPIを深く掘り下げるステップで、ハイレベルダッシュボードと同じアプリにこれらの分析を含める

以下はそのプロセスの簡単な図です：

Tulipでは、アプリのすべてのインタラクティブ機能を利用するために、アプリエディタで現場のダッシュボードを構築できます。次に、現場のタッチスクリーンでTulip Playerを実行し、チームメンバーなら誰でもメトリクスを調べることができます。

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

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

KPIの選択

ダッシュボードや製造アプリの構築に入る前に、対処する必要があるペインポイントを選択します。

このガイドでは、以下のペインポイントを持つ自転車工場を例に説明します：

不良率が高い：不良率が高い：一次パスの歩留まりが低すぎる。
生産の可視性がない：生産データが紙のシートに記録されていたり、記録されていなかったりするため、生産データに簡単にアクセスできない。
機械の稼働時間／停止時間：稼働率がどこにも記録されていないため、チームはベンチマークや目標を設定できない。

これらの痛みに対処するために、この自転車工場は次のことに重点を置くことにした：

リワーク／スクラップ率：どの製品やステーションが手直しやスクラップにつながるかを知る。
製品別サイクルタイム：各 SKU または作業オーダーが各ステーションで費やす時間を知る。
機械／ステーション別の稼働率：どの機械／ステーションがボトルネックの原因となっているか、または十分に活用されていないかを知る。

ここに課題がある：これらのKPIは、フロア上の複数のステーションによって影響を受ける。そのため、プロセスエンジニアは、複数のデータソース（オペレータステーションまたはフロア上のマシン）から根本原因を特定するために、複数のアプリからデータを組み合わせる必要があります。

ハイレベル・ダッシュボードの構築

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

自転車工場が改善すべき各 KPI を網羅している：

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

この現場ダッシュボードにより、オペレーターやプロセス・エンジニアは以下のことができる：

複数の日付範囲にわたるメトリクスを見る：今日／昨日／先週など。
リアルタイムの生産データを目標と比較
個々のKPIをより深く掘り下げ、「詳細」ボタンでより詳細なメトリクスを見る
サイクル・タイム "ボタンで現場のボトルネックを確認

この場合、自転車製造ラインには5つのステーションがあり、「サイクルタイム」は5つのステーションそれぞれのサイクルタイムの比較を表示します。

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

このダッシュボードは、実際には10個の別々の製造アプリからデータを取得しています。個々のアプリを確認し、このダッシュボードのためにデータを収集する方法を説明します。アプリの種類は以下の通りです：

作業指示アプリは、オペレーターがタスクを完了するための一連の作業指示を与えます。作業指示アプリは、オペレーターが作業を完了し、「完了」ボタンを押すたびに、タクトタイムを追跡します。これらのタクトタイムは、個々のSKUごとに分割され、オペレーターは各商品のバーコードをスキャンすることでそのSKUを含めます。そのSKUデータは、アプリの完了ごとに変数で保存される。
パッキングステーションはヘッドレスアプリを使用している。これは、オペレーターがチューリップ・エッジ・デバイスに接続された生産ラインのボタンを押すと、アプリがデータを追跡することを意味します。オペレーターはアプリ自体と対話することはありません。
各品質アプリは、品質スペシャリストが持ち運ぶタブレット上で継続的に実行される。部品を検査するたびに、タブレットに作業内容を記録します。
メンテナンス・アプリは、メンテナンス技術者が持ち歩くタブレット上で実行される。メンテナンス技術者が毎週巡回する際、彼らはアプリを介してあらゆる問題を記録する。問題はフォームフィールドに記録される。このアプリは、巡回が完了したかどうかを表示するだけだ。詳細をクリックすると、週次ラウンドのどの部分が完了したか、または完了しなかったかを見ることができます。
マシン監視アプリもヘッドレスアプリだ。最大30秒のサイクルタイムがあらかじめ設定されたマシンに接続される。勤務時間中に30秒の時間枠で稼働しなかった場合、アプリはダウンタイムを記録する。稼働すれば、アプリは稼働時間を記録する。オペレーター用のインターフェースはない。マシンはOPC UAコネクタを介してTulipに接続されます。

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

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

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

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

アプリの右側にあるボタンは、各KPIのより詳細な分析があるアプリ内の他のステップにオペレータを誘導します。この例では、リワーク率を調査するための4つの分析があります：

作業指示アプリ

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

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

作業指示アプリは、チューリップ・ターミナルのようなものかもしれません：

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

各ステーションがこのアプリのバリエーションを使用している場合、アプリの完了データを介してサイクルタイムを確認するためにデータを結合することは容易であろう。

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

このバーコードデータを使用するには2つの方法があります：

バーコード番号が必要な場合は、変数に保存できます。
コネクタ関数を使用して、SQLデータベースから、またはAPIを使用して、MESまたはデータレコードシステムにSKUに関するより多くのデータを取り込むことができます。そして、そのデータを変数に保存することができます。

トリガーエディタを使用して、バーコードスキャンの後にコネクタ関数を呼び出す例を示します：

ここでは、"Then" ステートメントについて詳しく説明します：

以下は、作業指示アプリの一連のイベントです：

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

以下は、すべてのアプリが連動する図です。

次に、5つのステーションをすべて同じ分析に追加し、各ステーションの結果をSKUごとに分割して、どのステーションがラインを遅らせているかを見ることができます。これは "ディープダイブ分析 "なので、オペレーターが "サイクルタイム "ボタンを押すとダッシュボードに表示されます。

さらに読む

出荷ステーションアプリ

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

この場合、オペレーターは仕事をするのに指示は必要ありません。しかし、各ケースがいつ工場から出荷されたかを追跡したい。

そこで、「ヘッドレスアプリ」を作成する必要があります。つまり、ヒューマン・インターフェースはない。その代わりに、アプリは、ケースが梱包されたときにオペレーターが押すボタンに接続されます。このボタンはチューリップ・エッジ・デバイスに接続され、ボタンが押されるたびにチューリップに通信されます。

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

出荷ステーションのディスプレイで実行される、このワンステップ・アプリの例です：

さて、オペレーターは技術的には「手動インクリメント」ボタンからアプリを使うことができる。しかし、そうする必要があるのは、物理的なボタンが何らかの理由で壊れた場合だけだ。

これがアプリへのデータの流れです。

アプリが完成したら、このデータをMESやERPに接続することができます。

分析

このアプリには変数がないので、アプリ完了時に収集するデータは以下の2点です：

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

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

あなたの自転車工場が平日しか稼働していないとしましょう。月曜の朝に出社したとき、「今日」以外のデータが空白のダッシュボードに表示されるのは避けたい。その代わり、「昨日」のデータを見たければ、本当は金曜日のデータを見たいはずだ。

アナリティクス・ビルダーでそれを実現する方法を説明します。まず、日付範囲を「7日前以降」から「1日前以前」に設定します。これで、今日までの過去6日間のデータが得られます。

次に、フィルターフィールドで「過去2営業日」を選択する。これは今日と、今日より前の最終営業日をカバーする。

この2つのフィールドの交点が「昨日」になります。

アナリティクス・ビルダーではこのように表示されます：

そしてこれがタイムラインビューです。

さらに読む

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

品質アプリ

この工場では、2つの生産ラインの端に品質ステーションがあり、包装前の最終製品を検査している。彼らはタブレット上で動作する同じアプリを使用している。

これは4つの組立ステーションの後に行われるが、アプリの完了時間は製品の総サイクル時間には含まれない。作業指示書」に記載されていないのはそのためである。

また、オペレーターは同じSKUで複数の製品を連続して組み立ててから別のSKUに移るため、アプリはデフォルトで製品のSKUが前の製品と同じであると仮定します。

これがアプリの最初のステップです：

SKUが前の商品と異なる場合、オペレーターは "Scan New Daysheet ID "を押す。すると、バーコード・スキャナーで製品をスキャンするよう指示される画面が表示される。スキャンすると、アプリはコネクター機能を使ってMESシステムに接続し、関連データを取り込む。その後、オペレーターは "良品 "か "不合格 "かを指示することができる。

オペレーターが "Good "を選択すると、アプリは完了し、ステップの左側にある変数の値が完了と一緒に保存される。これにより、後でSKUによる分析が可能になる。

もしオペレーターが "Rejected "を選択すると、フォームステップに送られ、そこで不良を選択することができます。不具合を選択した後、アプリを完了することができます。