『今さら聞けない基幹システム構築のポイント』～Back to BASIC～ 第02回 レガシーシステム刷新を成功に導くPointについて

フューチャーナレッジコンサルティング株式会社 代表取締役 福岡 博重 氏

1. 部品構成表BOMの役割理解

部品構成表BOMが最優先定義内容であることを本コラムの第1回でお伝えしました（図１）。

図1

BOMは基幹システムにおいて次の各用途で使用されます。

• 生産管理：リードタイム(LT)が設定された階層BOMにより納期から生産開始日を逆算し併せて製造指図も計画される
• 工程・進捗管理：上記で発行された製造指図の開始と終了を入力することにより進捗が確認できる
• 在庫管理：材料倉庫からの工程への払出、工程の進捗に伴う仕掛品の所在、工程作業の完了に伴う製品倉庫への入庫の指示が出る
• 購買管理：受注に対してBOMを利用してMRP展開することにより必要な資材の所要量と必要時期の指示が行われる
• 歩留り管理：理論的な員数定義と歩留りをBOMに定義することにより投入数量のアドバイスが出る
• 原価管理：BOMの構成に資材の金額と標準作業時間(ST)と加工費単価を定義しておくことにより製品原価を自動計算させる

以上のように部品構成表BOMが基幹システムの背骨となります。
同様に、製品を開発するためには必ず設計部隊による図面作成が行われます。昔の職人は図面で製品を作っていました。今日の設計部隊は、図面とそれに関連し、かつ階層化した設計BOMを作成するのが一般的になりつつあります。設計BOMに追加情報を肉付けすれば製造BOMとしてそのまま生産、購買発注に使用できるようになるからです。

2. レガシーシステム刷新シナリオ

現在レガシーシステムで運用を行っており、近いうちに保守切れとなったり、レガシーシステムの仕様を知っている技術者の退職、バージョンアップの必要性に迫られるなど、さまざまな事情でシステムを刷新せざるを得ない企業は多数あります。刷新シナリオの「改善」と「改革」について説明します。

図2

図3

図2と図3の縦軸にはシステムの機能レベルを表示し、また、横軸は時間を表しています。円の大きさはシステムの規模を概念的に表しています。表の中の等高線は数年おきに外部環境が変わり、変化した環境に対応するためにシステムの概念、前提と優先順位を変える必要があることを示しています。まだ等高線の変化は徐々に現れるのではなく断層のように表面化することを表しています。
システム刷新に対するひとつの考え方は、既存システムをそれなりに安定して使うことができており、社内の各部門からは機能追加の要望は出ているものの現在使用しているシステムの機能なり業務プロセスを根本的に見直す必要はないと言われていることで“改善”を加えた刷新を試みるというものです。このシナリオは図2の青の矢印で示しています。会社内部の立場から見ると一見して正しい判断のようにも見えますが、時代時代で外部から要求される業務要件には対応できていないのです。
図３と比較してみてください。レガシーシステムの刷新のベクトルが右上45°を向いています。これは現状の位置から見ると外部環境から要求される改革を実現する機能と業務プロセスに応えるだけではなく、業務部門からの改善要望にも応えていることを示しています。こちらのシナリオを採用すべきだということは自明です。

3. 企業を取り巻く環境の変化

図4

それでは今までどのような環境が変化したかを具体的に説明します。図4の左側が過去の環境および環境に起因する考え方を示し、右側が最近の状況を表しています。例えば、多くのレガシーシステムを構築した時代には製造業はどこも活況を呈していて、工場で製品を作れば売れる状態でした。その際は面倒くさい管理は行わず、受注すればすぐ生産直結状態です。現在は需要予測を行い、売れ筋製品は適正在庫を持ち注文に対応するのが一般化していますし、品種も多品種によりお客様の需要に応えるのが当たり前です。
作れば売れる状態であれば工場の管理は単位時間にどれだけ生産性を上げられるが関心事です。多く作ればそれだけ評価が高まります。今は作り過ぎれば不良在庫が増えかねません。そのため生産性をやたらに上げることは評価条件ではなくなり、多品種のそれぞれが適正な利益を上げられる（製造原価をきちんと捉える）ようにするのが工場管理になっています。
これらの前提が時代とともに変化していますので、純粋に工場の業務の担当者レベルからの改善を取り入れても見当違いな刷新が多く見受けられるのです。

4. システム刷新を一挙にすべきか段階導入すべきか

システム刷新の際は、企業の置かれている状態の変化を捉えた大胆な改革を取り込んだシナリオを取らなくてはならないことが理解いただけたと思います。
一挙にシステム刷新を検討するのですが、以下のように躊躇する場面もあります。

• 予算化が難しい。基幹システムに多額の費用がかかる
• 業務の将来構想とそれを支援するシステム機能が描けない
• 既存システムの精通者が不在
• 最新の基幹システムでできることがよくからない
• 現行業務課題の解決策がわからない
• DX(デジタルトランスフォーメーション)を何から始めれば良いかわからない

逆に、段階導入が適した条件（「適した」が言い過ぎとすると「段階導入または業務系の基礎データを事前に整備をせざるを得ない」に近い）は以下のとおりです。

• 部品構成表(BOM)が階層化されていない
• 品目コード体系の見直しが必要
• 山積み、山崩しが必要だができていない
• リードタイム設定がされていない

これらの場合は、新しい考えのシステムを使いこなす前に業務部門での準備ができていないとシステムの導入が始まらないと理解すべきです。これらの業務系の準備は少なくとも数ヶ月から半年はかかります。
新しい基幹業務システムは主要業務が連動しているため一括導入が基本です。分割導入を実施しようとすると何本ものインターフェースプログラムを作らなくてはなりません。また作成したインターフェースを数年で使わなくなるため無駄な投資になってしまいます。
段階導入を推奨するのは以下のような場合です。

• 基幹システムを一挙に入れ替えるリスクが高すぎる場合
• 事業部別の分散経営を実践している会社で一つの事業部が一つの会社のような運営を行なっている場合
• 基幹システムへ各業務の現場から適切なデータ提供（データ項目、内容、タイミング）ができていない場合

5. 段階導入でメリットを出すシナリオ

医学でも工学でも工場の検査でも、品質の状態や経営の状態、変更の管理を実施するために今までより格段に細かいデータ、多方面のデータ、さらにリアルタイム性が要求されるようになってきました。

図5

製造現場においても同様なことが起こっています。図５の一番上の行をみてください。昨今経営層、幹部層から実施をしたい代表的な重要業務をリストアップしています。中段の行には上段でリストアップした業務をこなすための基幹業務内で処理される代表的なロジックを上げています。一番下の行は重要業務に適切な答えを出すため現場から収集すべきデータを示しています。
例えば納期回答に関しては最近の基幹業務システムからは在庫の有無、材料なのか中間品なのか積送中なのか製品在庫なのかを見極め、調達LT、製造LT、および輸送LTの数字を足し合わせ、納期回答が自動でできるようなロジックが埋め込まれています。レガシーシステムでは、一般的に受注した製品を生産するために使用する部材がいくつ必要かの所要量計算は行なってくれますが、いつ必要かは計算してくれない場合が多いのです。
同様に、生産計画変更については、変更すべき製造オーダーの進捗が実際どの工程にあるのか、変更した時に必要とされるタイミングで部材が揃っているのか、部材の発注残があるか、といった実績データを駆使する必要があります。
そのためレガシーの基幹システムを置き換える際に“在庫の所在”であるとか“各種LT”であるとか“製造指図に対する進捗”であるとか“作業時間を記録している日報”であるとか、現場の工程や外注を論理倉庫と見立てて“受払”を提供する実績系のシステムを、段階導入の最初のフェーズとして実施することをお勧めします。ここまできめ細かいデータは基幹システムで扱うと重くなってしまうのと、現場におけるデータ入力修正等の柔軟性を考慮した外付けのシステムとして活用する場面が多いのです。

6. 実績/MES系でシステム導入を開始するメリット

図6

経営情報の高度化の道筋を一番左のカラムに書いてあります。図6下からモニタリング（実績データを収集すること）から始まり、管理・統合その次が計画（この部分は一般的に現在のERPで提供される機能）またはその次が分析になります。
分析を行うためには結果の数字であるとか指標をドリルダウンして変化を起こした元データを探り当てることにより原因を見極めます。さらにレベルアップさせるためには最適化であるとか自律性を持った仕組みするのが今後の動きになります。このレベルアップのシナリオを支える基盤となるのが現場からのデータとなります。

7. ACDPを考える(図7)

図7

一般的な問題解決の手順としては、P(Plan)→D(Do)→C(Check)→A(Action)をぐるぐる回せと言われています。管理者が業務を運営する場合にはこの手順で良いのですが、システムを設計、構築する場合はこの流れを踏襲してはまずいのです。システム導入の際にはA→C→D→Pの手順、つまり管理者がどのようなアクションを要求するのか、そしてその根拠は何をチェックしているのかを事前に想定して、必要な現場データをどのぐらいのインターバルで収集しておけば良いのかを準備するのです。
図7はその流れを示しています。経営レベル、管理レベルで要求される内容とチェック項目とアクションを先読みしてシステムの実績系を準備しておけば良いのです。同様のことがKPI(Key Performance Indicator)設定についても言えます。目的を持ってデータを収集する仕組みは多くのメリットを生じさせる訳です。
逆に目的や使用者不在でやたらに細かくデータを集めたがる人もいます。このようなことがまかり通ると無駄なデータ収集と記帳の工数をかけすぎてしまい、何も役に立たない作業になりかねませんので注意が必要です。

まとめ

8.1 改善ではなく改革を目指すこと

レガシーシステム刷新を行う際には、企業の置かれている環境が間違いなく変化しているため、既存システムの機能に業務ユーザーからの要望機能のみ要件として移行するのではなく、改革を目指してください。

8.2 一挙に移行か段階移行か

システムを一挙に刷新するのが基本です。しかし、①新しい基幹システムで要求される定義およびロジックが成り立たない場合と、②経営および管理者層の期待に応えることができないデータの細かさ、範囲、切り口、速報レベルの場合は段階導入を推奨します。

• ① 基幹システムで要求される定義とロジックについては「今さら聞けないシリーズ第１回 部品構成表BOMの役割理解」を参照してください。そこで要求される定義（BOMの階層化等）がまだ確立していない場合が当てはまります。
• ② 経営および管理者層の期待に応えられない場合は、データの発生源における情報の収集部分をきちんと成立させる必要があります。“在庫の所在と数量”“指示に対する進捗”“原価計算のための作業時間”“工程のタクト、納期回答のためのリードタイム”の整備です。

これらの情報は基幹システムにおいても一部持つことができますが、BOMの階層が深くなりすぎたり、データの収集が細かくなってしまうと基幹システムが重くなりすぎてしまうことで、受注であるとか、納期回答のための計算、在庫引当処理に影響を与えてしまいます。そのため、段階導入で外付けの実績/MES系の仕組みを最初に構築するのが良い解決法です。
また、基幹システムはバックアップ、メンテナンス、翌週の生産管理のためにMRP計算行い休日は使用できない場合が多くなります。そのような際に軽い実績系の仕組みを活用すれば24時間入庫、出庫、出荷作業が切れ目なく稼働させることができます。

8.3 PDCAではなくACDPを考える

レガシーシステムの刷新を機に業務に役立つシステムを構築することを考えてください。経営層が要求する内容と分析結果を想定しその結果をタイムリーに提供できるように現場のデータを実績系システムできちんと捕まえることができるようにすべきです。そのための導入の際の思考手順がACDPなのです。

これまで2回にわたってお届けした本コラムが、お客様のレガシーシステム刷新のための一助になりましたら幸いです。

• 第03回 製造原価のコストコントロール ～『限界利益』のポイントについて～