【第13回】業務運用整備フェーズの秘訣は何か（前編）

業務運用整備フェーズの位置付け
業務運用整備フェーズは、新システム稼働前ならびに新システム稼働後の安定した業務運用を支えるためのフェーズです。

業務運用整備フェーズの進め方
業務運用整備フェーズには、新システム導入に向けての業務改革施策（ルール・プロセス・体制等）を具体化する業務改革推進、新システムを前提とした業務マニュアル・手順書等を具体化する業務運用設計、新システムを前提としたマスタ定義、新システムや新業務を行うためのユーザー教育、新システムを実際に使って新しい業務を検証する運用テストがあります。

その中で今回は、業務運用整備フェーズの前編として、業務改革推進、業務運用設計、マスタ定義を中心に説明します。

業務改革推進では、全体構想で策定した目指す姿を実現するために、業務要件定義フェーズで検討した業務改革施策を具体化し、実行していきます。
例えば、業務のシンプル化のため、取引先との取引条件（納入条件、検収条件、支払条件等）を見直す場合、新しい取引ルールの制定、取引先への説明、取引先との基本契約の変更等を行う必要があります。
業務変革推進では、システム稼働後におけるルール・プロセス・組織などに係わる業務改革施策を具体化し実行に移すだけではなく、システム稼働前であっても実行できる施策は準備して実行していきます。

業務改革施策立案の内容

目標の最新化
業務要件定義フェーズで検討した業務改革の具体的な目標（例：リードタイムの短縮、顧客満足度の向上、コンプライアンス強化、生産性向上など）を、選定したERPを前提として見直していきます。

業務要件定義フェーズで検討した業務改革施策について、システム要件定義フェーズで軌道修正がでる場合もあります。例えば、当初はシステム化対象であった施策が、投資対効果の観点から、対象外となる場合などです。したがって、業務運用整備フェーズでは、これらの業務施策体系の見直しにともない、目標を最新化します。

業務改革施策の具体化と実行
ルール・制度の見直し、組織の見直し、業務プロセスの見直し、システム化範囲の拡大など、全体最適を目指したユーザー部門としての業務改革施策を具体化し、実行に移していきます。

業務改革施策の具体化と実行にあたっては、経営層や他部門との調整が多く含まれます。これらは、一般的に時間がかかることが多いため、早め早めの準備と調整を行うことが重要です。
例えば、取引先との取引条件の見直しなど、数か月から1年くらいかかる場合も少なくありません。

実行計画の見直し
業務要件定義フェーズで策定した実行計画を業務改革施策の具体化と実行に合わせ、見直しを行います。システム要件定義を受け、また経営層や他部門との調整を踏まえ、業務改革施策の優先順位付けを見直し、実施時期や実現時期など最新化した実行計画にブラッシュアップしていきます。

業務改革施策には、システムに関係ないものも多く含まれます。しかし、システム刷新が目的化すると、これらの施策が後回しになりがちです。システムは、あくまでユーザー部門の目指す姿を実現するための方法の一つとして、システムと関係がないものも、しっかり実行していくことが重要です。

また、実行計画では、改革に取り組むためのリソースも明確にする必要があります。この点が曖昧だと、実行段階で工数不足でできないなど、実行計画が絵に描いた餅になるからです。

業務変革推進におけるポイント

Fit to Standard視点での業務改革施策検討
業務運用整備フェーズと並行して行われるシステム要件定義フェーズでは、Fit to Standard視点で要件が詳細化されます。この時、ERPの標準機能では実現できない業務も明らかになります。

ERPの標準機能で実現できないGAPについては、業務改革によって業務を変更する必要があります。
しかし、こうした業務の変更は、関連部門ユーザーから抵抗が出る場合も少なくありません。関連部門ユーザーに対し、業務改革がなぜ必要なのか、業務を変えないとどんな不都合があるか、などを理をもって説明していくことが重要です。

業務改革推進組織の設置
業務改革はユーザー部門だけでなく、経営層や他部門も巻き込んで行う必要があるため、業務改革を専門的に実施する推進体制が必要になってきます。レイヤーズ・コンサルティングでは、この業務改革をおこなっていく組織を独立した組織やチームとして組織化することを推奨しています。

システムプロジェクトは、どうしてもシステム導入を中心にプロジェクトが進められるため、業務改革が後回しになりがちです。業務改革という明確なミッションを持った業務改革推進チームをつくることによって、こうした惰性を防ぐことができます。業務変革推進チームにとっては、基本構想で描いた目指す姿を実現するために、業務改革を実現することがミッションであり、システム導入はそのための手段の一つとなるからです。

業務改革の段階的実施
業務改革は、新システムの稼働を待たなくてもできるものは、前倒しで実施すべきです。特に、既存のシステムであっても業務改革が実現できる領域は、率先して業務改革を行っていくことが重要です。

しかし、一般的には、システム導入にリソースの多くが割かれ、システム導入前に業務改革施策を実行に移すことを躊躇するケースも多く見受けられます。これは単にツケを後回しにしているだけです。業務改革の効果を早期に刈り取るためにも、業務改革は先手、先手で進めることが重要です。

業務運用設計では、新システムを前提として行う業務を具体的に設計します。業務運用設計においては、新システムを直接操作する業務だけでなく、その周辺の業務についても含めて、具体的に設計します。

ERPでは、システム操作マニュアルやシステム操作を中心とした業務フローなどが予め準備されていることもあります。業務運用設計では、これらにとどまらず実際に業務を行って行くうえで必要なルールや手順を具体化し、業務マニュアル等にまとめていきます。

業務運用設計の内容

業務プロセスの最終化と変革点の明確化
業務改革を実現する新しい業務プロセスを業務フローとして最終化していきます。
旧業務フロー（As-Is）と新業務フロー（To-Be）を対比することで、ボトルネックや重複作業といった課題や業務改革による変革点を明確化します。

基幹システム刷新の場合、基幹システムに関連する業務フローを中心に作成することが多いですが、基幹システム外で実施している業務を含めて、End-to-Endで業務フローを最終化することが重要です。

制度・業務ルールの変更
業務改革施策に合わせ制度や業務ルールも変更していきます。例えば、前述のように取引先との取引ルールなどを変更します。また、取引先評価基準などを見直す場合には、取引先管理規程等も変更します。

組織の変更
業務改革施策に合わせ、組織も変更していきます。例えば、前述のように業績管理制度の見直しにともなう、業績管理組織の変更（カンパニーの設置）などです。組織変更にともなって、権限・責任やレポートラインといったコミュニケーション設計も行います。

業務マニュアルの作成
新しい業務プロセス、制度・ルール、組織などに応じて、実際に業務を行って行くうえで必要なルールや手順を具体化し、業務マニュアル等にまとめていきます。

業務運用設計におけるポイント

業務の体系化・見える化
新システムの導入にあたって大切なことは、実際の業務運用で目指す業務の姿を実現することです。
しかし、実際はシステム導入が目的化し、新システム導入後も業務の属人化やブラックボックス化が解消できないことも少なくありません。基幹システムの刷新にあたっては、業務の継続性の担保や業務品質の確保のために、業務運用設計を十分に行い、業務を体系化し見える化することが必要です。

レイヤーズでは、業務運用設計において下記のような内容のドキュメントで業務全体の体系化（見える化）を行い、これらに基づき関係者に業務運用を周知徹底するようにしています。

これらは、新システム導入前から整備していくことが重要です。既存システム運用時においても業務を体系化し、これに基づいて業務を運用し、新システム導入後は新しいルールやプロセスに変更したうえで、これらに基づいて業務を運用していきます。

※業務の体系化
業務要件定義フェーズの現状詳細分析で、現状業務を上記のドキュメント体系で整理することをご紹介しました。その段階で現状業務の体系化が終わっている場合には、業務運用整備フェーズでは、それらを最新化していくことになります。

業務運用設計のための体制確保
業務運用設計ためには、基幹システム刷新プロジェクトの開始の際に、業務運用設計に係わるユーザー体制・工数を十分確保できることを見込んでおかなければいけません。基幹システム刷新は、情報システム部門や導入ベンダーに丸投げできるものではありません。以前は基幹システム担当の情報システム人員もある程度いましたが、昨今では他のDX案件にリソースが取られ、ほとんど基幹システム刷新に対するリソースがないことも少なくありません。

したがって、ユーザー部門は、基幹システムの主管部門として実際の運用までしっかりした体制を用意していかなければいけません。しかし、どうしてもユーザー部門のリソースが限られている場合には、コンサルタント等の外部リソースの活用も考えて業務運用設計を行ってはいかがでしょうか。

既存システムから新システムへの移行の際に、新たに各種マスタを定義する必要があります。ここでは、特に重要な組織マスタ、取引先マスタ、BOM・BOP、標準原価マスタ、勘定科目マスタを説明します。
※マスタ定義はシステム要件定義フェーズとして扱うケースが多いですが、ここではユーザーであるユーザー部門の責任として行う業務設計ととらえて、業務運用整備フェーズで説明します。

ERPにおける主要なマスタ定義

組織マスタの定義
ERPにおける組織の設定とは、会社の組織階層をERP上に反映させることを指します。
ERPに組織を設定することにより、組織単位でデータを区分管理したり、組織単位でアクセス権や承認権をコントロールしたりすることが一般的です。

ERPの組織は、通常会社の実組織に対応して設定します。ただし、実組織ではないダミーの組織を設定し、データの区分管理に利用する場合もあります。例えば、ある費用を各組織の配賦する場合、ダミーで負担組織を設定することもあります。

また、組織の設定において、費用のみ計上できる組織（コストセンター：CC）、収益・費用が計うえできる組織（プロフィットセンター：PC）、収益・費用・資産・負債が計うえできる組織（インベストメントセンター：IC）などの区分する場合もあります。こうした組織設定による区分は、ERPによって異なりますので、導入時には確認が必要です。

通常組織は階層をもっています。したがって、ERPにおける組織も階層管理機能が一般的にあります。
例えば、その会社全体を頂点に、事業部や機能別組織などをピラミッド型に上下関係を定義します。
ERPではこうした階層構造を複数パターン定義できるものもありますが、階層構造のパターン数等については、ERPによって異なりますので、導入時には確認してください。

※施設・場所等のマスタ
組織とは異なりますが、ERPでは施設や場所などを表す各種マスタを設定します。
例えば、生産における工場や工程、在庫を管理するための倉庫やデポ、ストックポイント等もマスタとして設定します。これらのマスタの種類は ERPによって異なりますので、導入時には確認してください。

取引先マスタの定義
取引先としては、得意先、仕入先、銀行等があります。 ERPにおいては、これらの取引先をマスタに登録する必要があります。ただし、これらを同一のマスタに登録するか、それぞれ別のマスタに登録するかは、ERPで異なるため、導入時に確認が必要です。

特に、既存システムとERPで取引先マスタの持ち方が異なる場合、上流システム（販売システムや購買システムなど）の主管部門を巻き込んで、取引先マスタ（コード体系含む）を変えることが必要なこともあるので、注意してください。

取引先マスタには、各取引先の基本情報と取引条件（サイト、決済手段等）などを登録します。こうした取引先マスタへの設定項目もERPで異なるため、導入時に確認が必要です。既存システムの取引先マスタには、ここ数年取引のない取引先があることが一般的です。ERPへの移行にあたっては、これらの取引先を除いて登録するか、含めて登録するかを、移行対象方針として検討する必要があります。

BOM・BOPの定義
生産管理システムを利用する場合、BOM（Bill of Materials：部品表）とBOP（Bill Of Process：工程表）の設定が必要です。BOMは、製品を製造するために必要な部品や材料とその構成の情報を表したマスタで、品目マスタ（部品や材料の番号、名称、内外製、サプライヤー、ロットサイズ、リードタイムなど）と部品構成マスタ（部品間の親子関係）があります。BOMは、レシピや材料表などといわれることもあります。

BOPは、製品を製造するために必要な生産工程や工程順序、設備、作業内容、工数、工程品質などの情報を表したものです。BOMもBOPも製造において不可欠なものであり、ERP内で在庫管理、購買計画、所要量展開（MRP）、生産スケジューリングなどに活用されます。ERPのBOMやBOPは、それぞれのERPの考え方で構造化されています。したがって、既存システムとBOMやBOPの考え方が異なる場合には、ERPの導入に合わせてBOMやBOPを変更していかなければいけません。

特にBOMは既存システムにおいても、様々なシステムに連携しているので、BOM変更の影響度は早い段階で検証することが重要です。また、BOMやBOPを変更する場合、開発部門、生産部門、購買部門、サービス部門、販売部門等の関連部門の有識者を集めた専門チームを組成することが必要です。

加えて、製品や部品などについては、設計変更が発生しますが、設計変更の対応方法（切り替え管理、有効日管理も含めて）はERPで異なるため、導入時に確認が必要です。こうしたBOMの設定は、複雑で多大な工数を要することが一般的ですが、ERPによっては、ユーザーの設定作業を効率化する方法を用意していることもあるので、導入時に確認が必要です。

※メーカー以外の場合
メーカー以外の場合は、BOMやBOPの設定は必要ありませんが、商品などに関する品目マスタの設定は必要です。品目マスタの設定は、メーカーの場合と同様です。

標準原価マスタの定義
ERPの原価計算は、標準原価を用いることが一般的です。
したがって、ERPで原価計算を行う場合には、標準原価の設定が必要です。標準原価は、一般的にBOMとBOPを使って設定します。

BOMやBOPは、生産管理のために物量標準の情報を持っています。標準原価は、この物量標準（標準数量や標準時間等）と、それぞれの価格標準（標準価格や標準賃率等）を使い、階層や工程順序に応じて積上げて計算します。

勘定科目マスタの定義
勘定科目は、会社が通常使っている勘定科目をERPに設定します。ERPを導入する際に勘定科目体系を一新するケースや、グループ共通の勘定科目体系をつくるケースもあります。

勘定科目の設定においては、選定したERPの仕様に基づき、科目コード、科目名称、科目分類（資産・負債・純資産・費用・収益）、システム用のコントロール区分（ERPによって複数存在）などを設定します。科目コードの桁数は、ERPの制限があるため、それに沿って変更しなければいけない場合もあります。

現行の勘定科目の中に、顧客、取引先、プロジェクト、セグメント等などを意味する項目を設定している場合は、選定したERPがこれらを別のマスタに設定できるかによって、勘定科目体系からこれらを分離したほうが望ましいこともあります。ERPのマスタの種類や元帳残高テーブルのキー項目などを十分確認したうえで、勘定科目を決定してください。

勘定科目は、大科目・中科目・小科目や勘定科目・補助科目・内訳科目といった階層構造をもって定義している会社が多いのではないでしょうか。こうした勘定科目の設定は、ERPによって異なります。
階層構造がまったくないものもありますし、2階層や3階層のものもありますので、導入時に確認することが必要です。

マスタの設定タイミング

ERPにおけるマスタ設定は、これらのマスタがないとERPの実機検証やテストが実施できないため、システム要件定義フェーズの前半から開発フェーズの中で行います。一般的には、本番移行前に既存システムとERPのマスタは同期化（厳密にはデータとし一致しませんが）して置いたほうが望ましいですが、本番移行時に差分のマスタを登録することもあります。どのように移行していくかについては、移行計画や移行手順の検討において決定していきます。

今回は、「クラウド時代！ユーザー主導のERP導入とは」として、基幹システム刷新における業務運用整備フェーズの秘訣（前編）をご紹介しました。次回は、業務運用整備フェーズの秘訣（後編）として、ユーザー教育、業務運用設計をご紹介します。

今後の基幹システム刷新は、情報システム部門やベンダーへ丸投げはできません。ユーザー部門が主導して、ERPを Fit to Standardで導入していくことが成功の秘訣といえます。詳細な Fit to Standard でのERP導入のポイントについては、是非レイヤーズ・コンサルティングにお問い合わせください。