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

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

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

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

業務改革推進では、全体構想で策定した目指す姿を実現するために、業務要件定義フェーズで検討した業務改革施策を具体化し、実行していきます。

例えば、新しい業績管理制度を導入する場合、業績管理制度の見直しや新しい業績管理単位としての組織設計などが必要になります。また、業務をシンプル化するために、取引先との取引条件（支払サイト、支払手段等）を見直す場合、新しい取引ルールの制定、取引先への説明、取引先との基本契約の変更などを行う必要があります。

また業務改革推進では、システム稼働後におけるルール・プロセス・組織に係わる業務改革施策を具体化し、実行に移すだけではなく、システム稼働前であっても実行できる施策は準備して実行していきます。

業務改革施策立案の内容

目標の最新化
業務要件定義フェーズで検討した業務改革の具体的な目標（例：経営情報の高度化、決算日程の短縮、リードタイム短縮、コンプライアンス強化、生産性向上など）を、選定したERPや会計パッケージを前提として見直していきます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例えば、貸倒引当金の場合、貸倒引当金仕訳計上だけでなく、対象債権の把握、貸倒リスク評価、貸倒見積額算定、貸倒引当金の再評価等についても、ルール、作成帳票（Excelを使って行う場合、そのフォーマット等）や手順などを具体化し、新業務として整理します。

業務運用設計の内容

業務プロセスの最終化と変革点の明確化
業務改革を実現する新しい業務プロセスを業務フローとして最終化していきます。
旧業務フロー（As-Is）と新業務フロー（To-Be）を対比することで、ボトルネックや重複作業といった課題や業務改革による変革点を明確化します。会計システム刷新の場合、会計システムに関連する業務フローを中心に作成することが多いですが、会計システム外で実施している業務を含めて、End-to-Endで業務フローを最終化することが重要です。

制度・業務ルールの変更
業務改革施策に合わせ、制度や業務ルールも変更していきます。例えば、前述のように業績管理制度や取引先との取引ルールなどを変更します。また、勘定科目体系等を変更する場合には、勘定科目規程なども変更します。

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

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

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

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

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

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

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

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

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

既存システムから新システムへの移行の際に、新たに各種マスタを定義する必要があります。
ここでは、特に重要な勘定科目マスタ、組織マスタ、取引先マスタを説明します。

※マスタ定義は、システム要件定義フェーズとして扱うケースが多いですが、ここではユーザーである経理財務部門の責任として行う業務定義ととらえて、業務運用整備フェーズで説明します。

会計システムにおける主要なマスタ定義

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

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

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

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

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

会計システムの組織は、通常会社の実組織に対応して設定します。ただし、実組織ではないダミーの組織を設定し、データの区分管理に利用する場合もあります。例えば、ある費用を各組織の配賦する場合、ダミーで負担組織を設定することもあります。こうした組織設定によるシステム上の意味は、ERPや会計パッケージによって異なりますので、導入時には確認が必要です。

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

通常組織は階層をもっています。ERPや会計パッケージにおける組織も階層管理機能が一般的にあります。例えば、その会社全体を頂点に、事業部や機能別組織などをピラミッド型に上下関係を定義します。

ERPや会計パッケージではこうした階層構造を複数パターン定義できるものもありますが、階層構造のパターン数等については、ERPや会計パッケージによって異なりますので、導入時には確認してください。

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

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

取引先マスタには、各取引先の基本情報と取引条件（サイト、決済手段等）などを登録します。こうした取引先マスタへの設定項目もERPや会計パッケージで異なるため、導入時には確認が必要です。

旧システムの取引先マスタには、ここ数年取引のない取引先があることが一般的です。新システムへの移行にあたっては、これらの取引先を除いて登録するか、含めて登録するかを、移行対象方針として検討する必要があります。

マスタの設定タイミング

新システムにおけるマスタ設定は、これらのマスタがないと新システムの実機検証やテスト等が実施できないため、システム要件定義フェーズの前半から開発フェーズの新システムの設定過程で行います。

一般的には、本番移行前に旧システムと新システムのマスタは同期化（厳密にはデータとして一致しません）して置いたほうが望ましいですが、本番移行時に差分のマスタを登録することもあります。どのように移行していくかについては、移行計画や移行手順の検討時に決定していきます。

今回は、ERPや会計システムパッケージによる「会計システム刷新のキホンのキ」として、会計システム刷新における業務運用整備フェーズの要諦をご紹介しました。次回は、業務運用整備フェーズの秘訣（後編）として、ユーザー教育と業務運用テストをご紹介します。

業務運用整備フェーズは、業務改革施策を具体化し、実行に移すとともに、稼働後の業務運用が適切かつ安定的に行われるための重要なフェーズです。業務運用整備フェーズの詳細な進め方やポイントについては、是非レイヤーズ・コンサルティングにお問い合わせください。