ケーススタディ · B2B SaaS · 製造業OEE
損失の可視化と問題追跡をEvomoに追加する — ProchizがExcelを手放せなかった2つのギャップ。
EvomoはIoTを活用した製造業向けOEEプラットフォーム。クライアントのProchiz（チーズ製造業）では、ダウンタイムの損失金額が自動計算されず、問題の担当者も不明確なまま運用されていた。ユーザーインタビューと現場の運用フローを調査し、2つの機能要件を定義・設計した。
役割
UI/UXデザイナー
期間
2スプリント · 2022年3〜6月
クライアント
チーズ製造 · B2B SaaS
フォーカス機能
損失計算 & 問題追跡
設計プロセス
報告書分析→ペルソナ定義→機能設計（03 & 04）→反復・スプリントレビューTL;DR
損失計算機能はParetoビューに期待損失列（pcs・金額）を追加した。Prochizの月次報告書で必須の列だったが、Evomoは未対応だった。問題トラッカーはPICアサイン・是正処置の記録・ステータス管理を実装した。副作用として、毎週Excelで手作業していたライン別問題レポートがTrackerを使うだけで自動生成されるようになった。
00 / コンテキスト
Evomoは現場のIoTデータを管理者まで届けるプラットフォーム。
Overall Equipment Effectiveness — 工場の設備がどれだけ効率よく動いているかを0〜100%で表す指標。100%は無停止・無不良・フル速度を意味する。
Evomoの仕組み
IoTセンサー
データ収集
OEEダッシュボード
管理者が確認
意思決定
IoTセンサー機械に設置
各機械にセンサーが取り付けられており、稼働・停止をリアルタイムで自動検知する。オペレーターが手動でログを取る必要はない。
ドラッグまたはクリックで各ステップを確認
01 / 問題
Prochizの月次オペレーションに、Evomoが対応できていない5つのワークフローがあった。
優先度の高いギャップをクリックすると、対応して設計したFeatureが表示されます。
Evomo 既存機能
OEEターゲット未設定
レポートを毎回Excel手作業
歩留まりデータExcel手作業
期待損失が算出されない
クリックして詳細 ▾
問題追跡・担当者・記録なし
クリックして詳細 ▾
優先度マトリクス — 影響度 × 実装コスト
02 / ディスカバリー
Prochizから届いたCSVが、インタビューより先に答えを示していた。
Prochizのチームは既存の月次報告書・ダウンタイムログ・生産スプレッドシートをCSVで共有してくれた。データを確認してからインタビューに臨み、EngineerとPlant Managerに実際の運用フローを確認した。CSVで見えていた2つのギャップはインタビューでそのまま裏付けられた。
インタビューで確認された2つのギャップ
月次報告書に「ダウンタイムによる期待損失（pcs）」列があった
Plant Managerへのインタビューで確認：この列は月次報告書に必須で、経営陣への説明に直接使われている。Evomoはこの数値を計算しておらず、毎月Excelで手入力していた。
ダウンタイムログに「是正処置・担当者」列があった
Engineerへのインタビューで確認：問題が発生したとき、誰が対応するかをログに残すのは当然の運用だった。Evomoには担当者アサインも追跡ステータスもなく、全て別途Excelで管理していた。
3つのペルソナ
Plant Manager
ユーザー
プラント・技術・QC・生産スーパーバイザー
ペイン
データ処理に工数がかかる / 管理職と現場の認識を合わせるのが難しい
アクセス権
Dashboard · Analysis · Chat · レポートDL
Director
ユーザー
Dir · HoM · HoMS · BU Head · Engineering Head
ペイン
OEEデータの取得が遅い / データ精度が確認できない / 工場全体を俯瞰できない
アクセス権
Dashboard · Analysis（生産＆ダウンタイム）· レポートDL
Engineer (Admin)
ユーザー
Engineer（Admin）
ペイン
正確な生産計画に必要なデータが揃わない
アクセス権
設定フル権限（Runtime · Machine · Schedule · Reason · Product）
03 / 設計判断
損失計算と問題追跡 — 連動するOEEワークフローの2機能。
損失計算は既存のダウンタイムデータに損失の定量化を加え、問題追跡は構造化された追跡とレポートを追加する。どちらも既存のIAに組み込み、新規ページは追加しない。
Feature 03
期待損失（Expected Losses）
Pareto / Availability ビューに1列追加。新しいレポートページは作らない。
データはすでに存在していた。不足していたのは計算ロジックと列の表示だけ。新しいページを作ると毎回ナビゲーションコストが発生する。列の追加は1回の学習コストで済む。
なぜこの列が重要か
ダウンタイムが長時間続いた場合、どれだけの生産量が失われたかが即座に分かる。この数値がなければ、管理者はダウンタイムを「時間の問題」としてしか捉えられない。期待損失（pcs）を表示することで、「このダウンタイムで生産量がX個減少し、それが直接的な売上損失につながる」という意識をAdminが持てるようになる。特にダウンタイムが長引くほど損失額が積み上がるため、早期対処への動機づけとしても機能する。
計算式
Expected Loss (pcs) = Downtime (min) ÷ Cycle Time (min / pcs)
Expected Loss (value) = Expected Loss (pcs) × Product Price (Rp / pcs)
サイクルタイムと製品単価はEngineer（Admin）が設定画面で事前に入力する。
Paretoビュー — 追加されたpcs列（期待損失）。
Feature 04
中核機能Problem Tracker — 問題を発見したその瞬間から、記録・対処・報告まで一気通貫。
なぜこれが最重要機能なのか
Prochizの月次報告書には「問題発生 → 対処 → 再発防止」の記録が毎回含まれていた。このワークフローをEvomo内で完結させることで、毎週Excelで手作業していた「ライン別問題レポート」を自動生成できる。
損失削減のチェーン
01
問題発生
機械が停止、ダウンタイム記録
02
損失を数値化
期待損失（pcs）が自動算出
03
PICに即通知
Tracker起票 → 担当者へ通知
04
週次レポート
クローズ済み問題がライン別に集計
ロール別ウォークスルー
Operasional（作成）
-Bf5-cM2v.png)
機械ダッシュボードからタイムラインのダウンタイムブロックをタップすると「Input Reason」モーダルが開く。Nama Reason・開始・終了時刻は自動入力済みで、OperasionalはReasonと備考を入力するだけでよい。
ダウンタイムは機械に取り付けられたセンサーによって自動的に記録されるため、ユーザーが手動で時刻を入力する必要はない。ただし、センサーが対応していない場合や例外的な状況では、手動入力も可能な設計になっている。
ダッシュボード — ダウンタイム自動記録
%20-%20dashboard-DHkPxRFE.png)
オペレーターダッシュボード上でダウンタイムはセンサーから自動記録される。ダウンタイムカードをタップすると「Input Reason」モーダルが開く。
Input Reason — 原因入力フロー
%20-%20input%20reason-b0OAXNjX.png)
モーダル内でReasonを選択 → Keteranganを入力 → Submitで送信。開始・終了時刻はセンサーから自動入力済み。
Superadmin
Superadminのフロー：Issue一覧からIssue詳細を開き、Edit IssueでPICを割り当てて保存する。
Paretoビュー — ダウンタイム原因を確認
SuperadminはParetoビューで各ダウンタイムのReason・損失量を確認。対応が必要なダウンタイムのドットをクリックし「Issueとして登録」を選択する。
Issue一覧 → Edit Issue
Issue一覧ページに移動し、対象のIssueの「Edit」を選択。Edit Issueダイアログが開き、StatusをIn Progressに変更してPICを割り当てる。
Edit Issue — ステータス・PIC・是正指示
ダイアログ内でStatusを選択、PICを指名、Tindakan Perbaikan欄に是正指示を記入してSubmit。担当者に通知が届く。
Operasional（修正）
-pTgI_XMw.png)
Operasional (fix) のフロー：割り当てられたIssueをEdit Issueで開き、In Progressに更新してLog Actionで是正処置を記録し、最終的にClosedにする。
通知 — 割り当て済みIssueを確認
%20-%20notifikasi-CDtv2TAo.png)
SuperadminがPICを割り当てると、OperasionalのダッシュボードにNotifikasiが届く。通知をタップするとIssue一覧に移動する。
Issue一覧 → Edit Issue
%20-%20issue%20list-BqEp_DsC.png)
Issue一覧で割り当てられたIssueを確認し、Editを選択。ダイアログを開いてStatusをIn Progressに更新し、作業を開始する。
是正処置を記録してClose
%20-%20edit%20issue-BpFZyTUm.png)
Tindakan Perbaikan欄に実施した是正処置を記入し、StatusをCloseに変更してSubmit。Issue一覧に結果が反映される。
プロトタイプ
設計上の判断
起票はParetoの行から
損失金額が見える状態で起票できる。別ページへ飛ぶと文脈が途切れる。
Superadmin: まずOpenにしてからPICを割り当てる
確認してから委任。Open = 承認済み・未割り当て の状態が現場の実態に合う。
Operasionalの起点は通知
現場スタッフはダッシュボードを常時見ていない。通知が唯一の合図。
ステータスは3つだけ
インタビューで全員がこの3状態だけを使っていた。「承認待ち」は存在しない。
セッション個人化フィールド
同じラインでも担当者によって文脈が違う。週次レポートで「誰のシフト中か」まで追跡できる。
クローズ済みはTrendsにも保存
問題はクローズで終わらない。翌週のPareto分析への入力になる。
04 / 結果
2つのギャップ — ビフォー・アフター。
損失計算と問題追跡が変えたこと。
| ジョブ | 設計前 | 設計後 |
|---|---|---|
| 期待損失の算出 | 手動計算 | Paretoビューで自動算出 |
| 問題追跡・週次ライン報告 | 手書き台帳・Excelで週次手作業 | ダウンタイム→問題トラッカー → PIC通知 → 週次集計レポート自動生成 |
Plant Manager — 週次 BoD プレゼンテーションへの活用
Plant Managerは毎週、取締役会に各ラインの稼働状況を報告する必要があった。損失計算と問題追跡を組み合わせることで、このプレゼンに必要なデータが一元化される。
損失計算
各ダウンタイムによる損失（pcs・金額）がParetoビューで確認できる。「今週はこのラインで合計XX個・XX万円分の損失が発生した」と数値で示せる。
問題トラッカー
Problem Trackerの週次集計ビューで、「何の問題が・誰が対処し・どんな是正処置を取ったか」がライン別に揃う。BoDへの説明に必要な情報をExcelなしで提示できる。