NaNi EXECUTION LAB
LEARNING 運用設計

運用設計

学習時間目安:約60分

テーマ14:運用設計

学習週:Week 15
優先度:統合(作った仕組みを使い続けられるかどうかはここで決まる)


なぜこれを学ぶか

「作った仕組みを使い続けられる設計」まで含めて初めて仕組みになる。
PoC成功後に「運用で死ぬ」ケースが多い。運用設計はDXの最後の砦。


1. 定期運用サイクルの設計

日次:
  ・ダッシュボードの確認
  ・アラートへの対応
  ・データ入力の確認(欠損・異常値)

週次:
  ・週次KPIレビュー
  ・前週の問題・改善点の確認
  ・翌週の予定確認

月次:
  ・月次レポートの作成
  ・マスターデータの棚卸し
  ・システム設定の見直し
  ・ユーザーフィードバックの収集

四半期:
  ・KPIの見直し(目標値・計算方法)
  ・システムアップデートの評価
  ・担当者のスキル確認・教育

2. 更新責任の明確化

誰が・いつ・何を更新するかを定義する:

品番マスター → 設計部門が更新(毎月末)
取引先マスター → 購買部門が更新(追加時随時)
KPI定義 → 管理部門が更新(四半期見直し)
操作手順書 → システム管理者が更新(変更時随時)

→ 更新責任が曖昧だと、マスターデータが腐る

3. 異常対応(コンティンジェンシープラン)

3.1 システム停止時の判断基準

システムが停止した場合、何をするか:

Level 1(軽微):個人PCのエラー
  → 再起動・IT部門へ連絡。業務継続。

Level 2(部分停止):特定機能が使えない
  → 代替手順で業務継続。IT部門へ緊急連絡。

Level 3(全停止):システム全体が使えない
  → 手作業の代替フローへ切替。経営層へ報告。

3.2 手作業への切り替え手順

重要:システムが止まっても業務が止まらない設計

事前に準備するもの:
  ① 紙の記録用紙(Excelで代替可)
  ② 最新マスターデータの印刷物(週次更新)
  ③ 「システムなしの業務フロー」の手順書
  ④ 復旧後のシステムへのデータ入力手順

4. 保守体制の設計

役割の明確化:

システム管理者:
  → システムの設定変更・アップデート管理
  → 障害対応(IT部門または外部ベンダー)

業務管理者:
  → マスターデータの管理・更新
  → ユーザーの操作質問への対応

ヘルプデスク:
  → ユーザーからの問い合わせ窓口
  → よくある問題の一次対応

SLA(Service Level Agreement)の設定例

障害レベル初回応答時間解決目標時間
業務停止1時間以内4時間以内
部分機能停止4時間以内翌営業日
軽微な不具合翌営業日1週間以内

5. 継続的改善の仕組み

ユーザーフィードバックの収集:
  ・月次アンケート(5段階評価+自由記述)
  ・問題報告フォーム(随時)
  ・現場ヒアリング(四半期)

改善の優先順位付け:
  ① 業務が止まる問題:最優先
  ② 品質・精度の問題:高優先
  ③ 使いにくさ・操作性:中優先
  ④ 機能追加要望:計画的に対応

改善サイクル:
  発見 → 分析 → 優先順位付け → 実施 → 効果確認 → 定着

6. 引き継ぎ設計

「担当者が変わっても業務が続く」設計:

引き継ぎ資料に含める内容:
  ① システム構成図(何と何が繋がっているか)
  ② 日次・週次・月次の定常業務チェックリスト
  ③ よくある問題と対処法(FAQ)
  ④ 連絡先一覧(ITベンダー・社内担当者)
  ⑤ パスワード管理(専用のパスワード管理ツールを使う)

引き継ぎ期間の目安:最低3ヶ月の並行運用

推奨参考資料

種別タイトル用途
WebDX白書2023(IPA)DX推進の失敗要因分析
書籍『製造業DX EU/ドイツに学ぶ最新デジタル戦略』(近代科学社)運用継続の欧州事例

✅ 実務チェックリスト

このテーマを「理解した」と言えるための確認項目

  • 日次・週次・月次の運用チェックリストを作成できる(何を確認し誰が対応するか)
  • 障害発生時の対応フロー(検知→報告→切り分け→復旧→再発防止)を文書化できる
  • バックアップの取得方法・保管場所・リストア手順を確認・テストできる
  • 担当者のスキルマップを更新し、特定個人に依存している運用タスクを特定できる
  • ユーザー・管理者・ベンダーとのSLA(サービスレベル合意)を文書化できる

💡 ETO製造での適用ポイント

ETO製造の運用設計では「プロジェクト進行中」と「プロジェクト間のインターバル」という2つの状態を考慮する必要がある。MES・ERPの運用は、案件が活発な時期と新規案件の立ち上げ前後で負荷が大きく変動する。「案件クローズ時のデータアーカイブ手順」「新案件立ち上げ時のマスターデータ準備」を運用設計に含めることが重要だ。

マスターデータの所有権(オーナーシップ)の明確化は、ETO運用の根幹となる。「部品マスターは誰が追加・変更できるか」「顧客マスターの更新は誰の承認が必要か」というルールがないと、データが汚染されてシステム全体の信頼性が低下する。マスターデータオーナー制度の設計が運用設計の最重要事項の一つだ。

ETOでは「同じシステムを毎日同じ方法で使う」のではなく、案件の特性に応じて使い方が変わることがある。この「バリエーション」を許容しながらも標準から外れた使い方を検知する仕組み(異常使用アラート・監査ログ)が、長期運用での品質維持に必要だ。

障害対応訓練(マニュアル運用への切り替え演習)は、ETOでは特に重要。突発的な受注が来た時に「システムが止まったから作業できない」という状態を防ぐため、コアプロセスのバックアップ手順(紙・Excel)を整備し、定期的に演習しておく。


🔗 関連テーマ

テーマなぜ関連するか
ITインフラ(テーマ11)システム構成の理解が運用設計の前提
標準化(テーマ15)運用手順書は標準書の一形態
PoC設計(テーマ13)PoCから本番移行後の運用設計が必要