DXでは何のデータを集める?|判断につながる情報だけを使う現場改善
データを集めることが、DXの目的ではありません
DXを進めると、
「せっかくなら全部データ化しよう」
「将来使うかもしれないから残しておこう」
「まず見える化してから考えよう」
となりがちです。
しかし、入力するデータが増えれば、現場の仕事も増えます。
グラフや一覧が増えれば、確認する仕事も増えます。
Jマテ.カッパープロダクツでは、データを集める前に、
「その情報を見て、誰が何を判断し、次に何を変えるのか」
を確認します。
Jマテでは、このようにデジタル化の前に必要な情報と判断基準を整理する取り組みも「DXその前に」の大切なプロセスと考えています。
DXではすべてのデータを集めるべきですか?
必要なのは「取れるデータ」ではなく、「判断に使うデータ」です。誰が何を判断するのかを先に決め、その判断に必要な情報だけを集めます。
現場には、
日報。
チェックシート。
在庫表。
発注記録。
作業実績。
品質記録。
など、多くの情報があります。
しかし、データが多くても、
「どれが最新なのか分からない」
「結局、担当者に聞かなければ分からない」
という状態では、判断には使えません。
大切なのはデータの量ではなく、必要なときに判断できる状態になっていることです。
まず「何を判断したいのか?」から考える
例えば、部品を発注する場面で本当に知りたいのは、
「今、発注する必要があるのか」
ということです。
その判断に必要なのが、
- 現在庫
- 今後の使用予定
- すでに発注している入庫予定
- 必要数
- 納期
であれば、まずこの情報を整えます。
順番は、
データを集める
→ 何か分析する
ではありません。
判断したいこと
→ 必要な情報
→ 必要なデータ
です。
この順番を守ることで、目的のない入力やデータ収集を減らせます。
見える化するデータはどう選びますか?
「数字が変わったときに、誰かの行動が変わるか」で選びます。見ても何も判断・行動しないデータは、無理に見える化する必要はありません。
例えば、
生産数。
在庫数。
稼働率。
不良数。
残業時間。
設備停止時間。
すべて表示することはできます。
しかし、画面に並べることが目的になれば、見るための仕事が増えるだけです。
Jマテでは、
見える
→ 気づく
→ 判断する
→ 行動する
までつながることを「見える化」と考えます。
「正常」と「異常」を先に決める
データを表示する前に重要なのが、判断基準です。
例えば、
「在庫が10個ある」
「稼働率が75%」
「予定より30分遅れている」
という数字だけでは、それが良い状態なのか悪い状態なのか分かりません。
そこで、
この範囲なら正常
ここを超えたら確認
この条件なら作業を止める
この状態なら管理者へ報告する
という基準を先に決めます。
データを集めてから考えるのではなく、判断基準を決めることで、必要なデータが見えてきます。
KPI・定量数値は多いほどよいですか?
KPIは数ではなく「改善につながるか」で選びます。数字を見ても誰も行動を変えないのであれば、管理する指標を増やす意味はありません。
Jマテでは、例えば、
人工(にんく)
ある仕事に何人が何時間必要なのかを見る。これは人数ではなく工数のカウントをする単位です。
星取率(ほしとりりつ)
定時の中で計画した生産をどこまで達成できたかを見る。達成していたら星がとれたと表現する
といった指標を活用しています。
重要なのは、
「この数字が悪化したら何を確認するのか」
まで決めておくことです。
管理画面に多くのKPIを並べることより、現場が次の一手を打てる少数の指標を持つことを重視します。
Jマテの実体験 データを増やすのではなく「つながるKey」を決めていく
Jマテでは、システムごとに別々の情報を増やすのではなく、異なるデータをつなぐための共通Keyを整理することを重視してきました。
例えば製品に関する情報であれば、一意に識別できる製品名称や製品コード、製造単位ではロットNo.などを基準にします。
その共通Keyを使って、
在庫の管理
図面の管理
工程を管理、進捗を確認する情報
段取り設計情報
など、目的の異なるデータを必要に応じて結び付けます。
何でも一つの巨大なマスターへ詰め込むのではなく、
「何を共通Keyにして、どの情報とどの情報をつなぐのか」
を整理する。
これによって、同じ情報を複数の場所へ持つことを減らし、必要なときに必要な情報を組み合わせて使えるようにします。
98件の正常データを見るより、異常な2件を見る
例えば100件のデータのうち、
98件が正常で、
確認が必要なのが2件だけなら、
管理者が本当に見るべきなのは2件です。
すべてを一覧表示して毎日確認するのではなく、
正常なものは流す。
異常なものだけ知らせる。
という仕組みにします。
これは単なる「見える化」ではなく、確認する仕事そのものを減らすためのデータ活用です。
最初から大きなデータ基盤をつくらない
必要な情報が整理できても、すぐに大規模なデータベースや分析システムを構築する必要はありません。
例えば、
入力フォーム
→ Excel・スプレッドシートへ記録
→ 条件に合わないものだけ抽出
→ 必要な人へ通知
という小さな仕組みでも検証できます。
生成AIを使って、
記録内容を整理する。
自由記述を分類する。
報告書のたたき台を作る。
といったところから試すこともできます。
大切なのはツールではなく、
「その仕組みによって判断が早くなったか」
です。
データを集めるDXから、判断を助けるDXへ
Jマテが考えるデータ活用は、
何を判断したいか決める
→ 必要な情報を絞る
→ 共通Keyを整理する
→ 正常と異常を決める
→ 必要な人へ必要な情報だけ届ける
→ 小さく試す
→ 判断や行動が変わったか確認する
という進め方です。
データを取ること。
グラフを作ること。
AIで分析すること。
それ自体がDXではありません。
「その情報を見て、誰が何を判断し、次に何を変えるのか」
までつながって初めて、データは現場の改善に役立ちます。
入力するための仕事を増やすのではなく、判断に必要な情報だけを残す。
確認するための仕事を増やすのではなく、異常に気づける仕組みにする。
それが、Jマテ.カッパープロダクツが考える「DXその前に」です。
次の「DXその前に」
業務を整理し、必要な情報が見えてきたからといって、大きなシステムから始める必要はありません。