[SAP] Central Financeの機能・仕組み概要 - グループの財務会計領域シンプル化 [図解説明]

最近、SAP導入プロジェクトでCentral Financeの実装に関与する機会がありました。

書籍を購入したり、Googleで検索をしたりしつつWorkshopのトピックを洗い出し、顧客とCentral Financeの導入に向けて議論をし、要件を確定、そして実装と作業を進めていきましたが、日本にCentral Financeの導入を経験しているコンサルタントはなかなかに少ないようで、Globalと連携をしながら作業をしていくこととなり、個人的には良い経験でした。

本投稿では、日本ではもしかしたら貴重かもしれない、Central Finance導入に関与する可能性のある方々向けに、Central Financeの機能、仕組みについて概要をまとめていきたいと思います。

まずはCentral Financeが生まれた背景から、動作する仕組み、そしてどんなことが可能になっていくのか、また個人的な経験に基づく導入における論点を記述していきます。

以降、Central Financeを縮めてCFINと表記することもありますのでご了承ください。

Agenda

想定読者

Central Financeを導入することになったが、Central Financeをあまり詳しく知らないコンサルタント、SIer、事業会社の情報誌システム部の方
ERP導入プロジェクトのScopeにCentral Financeが含まれているため、Central Financeの概要を把握しておきたいコンサルタント、SIer、事業会社の情報誌システム部の方
ERP導入プロジェクトの提案内容にCentral Financeを含めようとされているコンサルタント、SIerの方

メリット

Central Financeのアーキテクチャー、構成要素がわかる
Central Financeの機能・仕組みがわかる
Central Financeに関連して使用される言葉の意味が分かる

Central Financeが必要とされる背景

従来の財務会計領域システムは複雑怪奇なスパゲッティ状態

まずはCentral Financeが開発された背景から見ていきましょう。

いったん、Central Financeは財務会計領域のソリューションととらえて下さい。Central Financeがあることでどういった変化があるのかを見ていくために、まずはCentral Finance以前の従来の財務会計領域が抱えていた問題を見ていきます。

以下に、よくあるシステムアーキテクチャーの図を示します。例として、複数のグループ企業から構成される企業があるとします。こうした企業では、複数の企業がそれぞれ単体での決算などを実施するのに加えて、グループを束ねた連結決算を実施する必要があります。

グループ企業はそれぞれ、独自にシステムを選んでいたりする場合、独自のERPを持っていることがあります。SAP製品かもしれませんし、Oracleなどの製品かもしれません。そして、同じSAP製品であったとしても、状況によってはバージョンが違う、といったケースももちろんあるでしょう。SAP製品でいえば、ECCを使用している企業と、S/4を使用している企業が存在する、といったケースももちろん起こりえます。

しかしながら、企業としては開示目的の連結財務諸表を作っていかなくてはなりませんので、システムがばらばらであったとしても何とか情報をつなぎ合わせ、一つの財務諸表を作る必要があります。Consolidationとは、日本語で連結を意味します。

開示目的であれば四半期別、あるいは年次で作成すればよいのですが、経営陣は可能であれば日々の意思決定の際や情報の可視化にもこれをうまく使いたいと考えるようになります。

グループ全体として、売り上げがいくら上がっていて、売上原価はどのくらいで、利益を出しているのはどのグループ企業なのか、といった情報がすぐにわかるようになれば、グループ全体としてどこに投資をしていくべきなのかを判断する際に重要なインプットになるのではないか、というアイデアが背景にあります。

このとき、課題になってくるのが、図でも示している３点となります。

最新の情報ではなく、現場と乖離している情報である可能性
データの品質チェックに工数が必要
加工データに対する分析結果の正しさに疑問が残る

データの品質チェックに工数が必要

既に言及しているとおり、グループ企業の情報を加工するというステップが必要になるので、相当程度の工数が必要となります。グループ企業のデータなので、こうした作業をするのもグループ企業側の人員となり、グループ企業側の人の立場としてはグループ統括企業のために自分たち自身の仕事とは無関係なことをやらされている、といった見方になってしまいます。

加工データに対する分析結果の正しさに疑問が残る

加工された情報をつなぎ合わせるというコンセプトであるため、そもそも加工の方法が正しいのかどうか、という点にも疑念が残ります。つなぎ合わせた情報が経営陣に提示された後、そもそもそれをもとに意思決定などをしても本当にいいのだろうか？という疑問も残ってしまいます。

CFINはシンプルなシステムへの変革を推進する

こうした状態を解消するということを謳い文句として、Central Financeは開発され、SAP社より提供されています。

Central Financeはかつて、Simple Financeという名称でした。その意図としては、複雑怪奇な財務会計領域をシンプル化する、というものです。グループ全体としての情報の見える化、集計作業などを自動化することで、Central Financeは情報を最新に保ち、いつでも分析が出来る状態にして、不要な工数は省き、データの品質についても担保を行います。

それでは、具体的な話を見ていきましょう。

Central Financeとは？メリットは？

財務会計伝票を自動再転記し財務会計領域を最新化・高品質化・効率化

Central Financeを活用することで得られるメリットは、以下３点となります。

財務会計データが最新に保たれる
データの品質が高く、チェック工数が不要
現場の最新状況を自動で可視化出来る

先ほどの図と似たものを以下に載せていますが、今回はCentral Financeを活用した場合にどうなるのか、といったものを記述しています。

Central Financeとは、この絵の中では2つの意味合いで用いられます。一つは、各子会社の財務会計領域の情報を吸い上げる集約システムとしてのCentral Financeで、もう一つはこうした集約システムを用いたシステム全体、あるいはシステムランドスケープ全体を指してCentral Financeと言います。

こうしたCentral Financeを用いることで、まず各子会社の財務会計情報が自動で集計されるようになります。これまでは、四半期に一度、などのペースで加工を行った情報を集約していたので、この時点で最新の財務会計データが自動で取得できる、というメリットが存在します。

つぎに、こうした自動で行われる財務会計データの集約ですが、子会社側のシステムでデータの加工などを都度都度行う必要がありません。事前に決めたルールに従って集約が行われますが、都度都度の設定や加工が不要となるため、これまた従来は都度都度発生していた集約された後のデータの品質チェックをするという工数が不要となります。

そして、なによりも最新の情報が常に自動で連携されることになるので、集約システム側では現場の最も新しい情報を見ることが出来ます。

こうしたメリット3点が、Central Financeを活用することで得られます。

なお、集約対象の子会社のシステムをSource システム（インスタンス）、集約を行うCentral Financeのシステム（インスタンス）をTargetシステムと呼びます。

Deployment Optionとしての活用も

Central Financeは、業務的には先ほどご説明した3点のメリットを持ちますが、ERPの刷新を行い、グループ全体のERPをS/4へ移行したいというケースにおいてはDeployment Optionにもなりえます。

例えば、現時点でSAP製品のECCを使用しているとしましょう。ECCは、2027年にサポート期限を迎えますので、後継であるS/4へ移行しようと考えている企業はかなり多い状況です。これに加えて、S/4では財務会計領域のパフォーマンスが改善されているため、早いうちからS/4に切り替えたいと考えている経営陣も少なからずいらっしゃいます。

従来の方法では、各会社が使用しているECCを順次移行するというオプションをとるか、あるいは各社が使用しているECCを同時に移行し、一つのS/4に切り替えるという方法が選択できました。

こちらの従来の方法ですが、順次移行するオプションをとった場合は、経営陣の目線では全拠点の切り替えが変わらないとS/4 HANA Financeの高パフォーマンス、高機能性を十分に享受することが出来ません。

また、統合をするというオプションを選ぶ場合、統合する対象となる拠点で別々に使用されていたコード体系、番号範囲、業務プロセス、カスタマイズなどを整合させる必要があり、こうした部分に相当の労力がかかり、スムーズに切り替え自体が進まないという点が課題となっていました。

こうした状況に対して、Central Financeを活用すると、子会社の業務には変更や影響を与えることなく、S/4 HANA Financeの高パフォーマンス、高機能を享受することが可能となります。

Central Financeは財務会計領域のデータだけを子会社のECCから集約することが出来ますので、子会社のECCで行われている業務には影響がありません。コード体系、番号範囲、プロセスはもちろん、カスタマイズも変更不要です。

しかしながら、財務会計領域のデータはS/4の機能を活用できることになるため、経営陣の目線としてはS/4 HANA Financeへの移行ができているという状況になります。あとは、子会社側の都合に合わせて、S/4への順次切り替え、あるいは統合を進めていけばよい、という考えとなります。

グローバルでECCからS/4へ移行を考えている、という状況であれば、まずCentral Financeで財務会計領域の統合を行い、BI活用やダッシュボード活用などの経営にインパクトを与える領域を先に実装する。続いて、物流関連の領域を統合していくために子会社レベルのECCをS/4へ切り替えていく、というアプローチがSAP社も推奨となっています。

CFIN活用によるビジネス上のユースケース

それでは、CFIN活用のメリットを大まかに見てきましたので、ここからはもう少し具体的なユースケースをご紹介しあます。Central Finance活用のユースケースは以下のとおりとなっています。

財務諸表・KPIのリアルタイム可視化
グループ会社の資金状況のリアルタイム可視化
グループ会社間の比較分析機能
債権債務突合の効率化
決算早期化、頻度の向上
連結機能の拡張
不正取引分析機能の拡張
予算機能の拡張

いろいろと書いているのですが、こうしたユースケースの源泉にあるのは、Central Financeが財務会計データを自動で、かつリアルタイムで取得してくれるからです。

財務諸表、KPIは財務会計データが自動で最新に保たれるのでいつでもリアルタイムの情報を見ることが出来ますし、グループ会社の資金情報も同様です。また、グループ企業間の比較もリアルタイムで実施でき、会社間の取引があればその突合（ICR：Inter Company Reconciliation）も可能です。

決算なども早期化、頻度を増やすこともでき、そして財務会計データが関連する取引情報はリアルタイムで記録、Central Financeに集約されるため、不正取引なども回避することが出来、また何かあっても追跡可能性が高いため分析も可能です。さらに、グループ全体の情報を集約していることになるので、連結機能、予算策定の業務も自動化されます。

Centralで処理可能となる業務

最新の情報を自動で取得する、といった点に加えて、Central Financeが可能とするのは、財務会計領域の業務プロセスの集約化、集中管理です。従来は、各子会社で個別に実施していた支払いなどの処理をCentral Finance側で集約して実施することが出来るようになりました。

Centralで処理が出来る業務を以下に示します。

ICR (Inter Company Reconciliation) 会社間照合
Open Item Management　未消込明細管理
Central Payment 支払い処理
Central Down Payment 前払い金管理
AP/AR Reporting 買掛金/売掛金レポーティング
Credit Management 信用管理
Dispute Management 紛争・係争管理
Collection Management 入金管理

基本的には、Sourceシステム側で実施している財務会計領域の業務プロセスはほぼほぼCentral Finance側で実施でき、ここに複数のSourceシステムの情報を自動で集約していることによって実施可能となる業務プロセスが加わります。

ICR（会社間照合）については、従来はグループ会社間の取引のBuy/Sellの関係を連結決算のタイミングで追跡していくという試みがされていましたが、CFINを活用することでBuy/Sellのデータがリアルタイムで集約されます。したがって、Buy/Sellの照合も自動で実施されるため、大幅な業務効率化が行われます。

このほかの未消込明細、支払、前払い金、信用、紛争・係争、入金管理、買掛金/売掛金レポーティング等は従来はSourceシステム側で個別担当者が対応していたところを、CFIN側の担当者がすべて対応することが出来るようになります。

こうしたCFIN側への業務集約によって、Sourceシステム側の担当者数を削減することが可能となります。Sourceシステム側で削減された人員は、個別グループ会社の事情が強く関係してくる予算策定、収益性分析、資金調達などのより戦略的な業務に注力することが出来るようになるでしょう。

従来、新たに拠点を立ち上げるとなると一定数の管理部門の人員も求められ、そして業務プロセスも整理する、というのが一般的でしたが、CFINを活用することで財務会計領域に関する業務はいわばShared Service化するため、こうした新たな拠点の立ち上げもスピードを増す、かもしれませんね。（ちょっと言い過ぎかもしれません）

CFINのアーキテクチャー（全体）

CFINの概要、活用のメリットを見てきたところで、CFINのアーキテクチャーを見ていきましょう。以下にCFINの構成要素を図解しています。

左側に位置するERP、S/4はSourceシステムで、右側に位置するものがCentral Financeです。大まかにいえば、Sourceシステムの情報をCentral Financeに吸い上げている、というアーキテクチャーとなります。

この他にもいくつか構成要素を書いていますが、Central Financeを構成する主な機能的な要素としては、SLT Server、MDGによるBusiness Mapping、そしてAIFの3つです。以降のセクションでは、これらの3つについて更に解説をしていきます。

詳細な説明に入る前に、こちらの図に示している要素の役割を簡単に説明します。

ERP / S/4 （Sourceシステム）
SLT Server
CFIN Accounting IF
MDG / Business Mapping
Error Detection (AIF)
Internal Accounting IF
SAP HANA (Universal Journal)

ERP / S/4 （Sourceシステム）

ERP / S/4 （Sourceシステム）は、グループ会社が保有し、運用しているERP、あるいはS/4です。SAP製品である必要はありません。これらのシステムで記録された財務会計領域のデータが、Central Financeへ再転記されます。

SLT Server

SLT Serverは、SAP Landscape Replication Transformation Serverの略で、Sourceシステムで記録された財務会計データを検知し、Central Financeへ受け渡す役割を持っています。Central Financeだけに使われるものではなく、BW/4 HANAへのデータの受け渡しなんかにも活用することが出来ます。

CFIN Accounting IF

CFIN Accounting IFは、SLT Serverから受け取った財務会計データを一次的に受け取る役割を果たします。ここでは、Sourceシステムで記録されたデータをそのまま受け取ります。

MDG / Business Mapping

MDG / Business Mappingは、密接に関係しているので並べて説明します。MDGはグループ内のマスターデータを管理しているシステムで、このMDGがCFIN内で行われるBusiness Mapping、マスターデータとマスターデータのマッピングを定義します。

CFINは複数のSourceシステムを持つので、場合によっては同じ会社コードや仕入先を意味しているにもかかわらずSourceシステム間で違うマスターデータを持っているケースというものが存在します。そうしたときに、このSourceシステムが送ってきたマスターデータ：AAAは、実はマスターデータ：XXXと同じなのですよ、ということをCFINに教えてあげる仕組みが、このBusiness Mappingとなります。

AIF

Error Detection （異常検知）の機能として、AIF (Application Interface Framework)というものがあります。異なるシステムからデータを集約するにあたり、疎通が確認出来なかったり、マスターデータ同士のマッピングに不整合があったりすると、もちろんCFIN側はどうしたらいいのかがわからなくなってしまいますので、こうした状況をAIFが検知します。AIFを活用することで、何かしらの不整合があったときにはその原因も合わせて理解することが出来ます。

Internal Accounting IF

Internal Accounting IF（Interface)は、Sourceシステムから受け取ったデータが問題なく書き込みが出来るとなったときに、CFIN内で実際にデータの書き込み（再転記）を行ってくれます。

SAP HANA (Universal Journal)

SAP HANA (Universal Journal)は、Internal Accounting IFが再転記を行うテーブルとなります。CFINはS/4 HANA Financeのテーブルを持っていますので、FIとCOを統合したUniversal Journalを持っています。このテーブルに再転記が行われ、CFINとしての動きは以上となります。

それでは、以降のセクションでより詳細な部分を確認していきましょう。

SLT Serverによるデータ連携

SourceとCFINの連携方法

それではここから、SourceシステムとCFINを連携する際の仲介役になる、SLT Serverの役割を見ていきましょう。

以下にSLT Serverがデータ連携を行う流れを図解しています。左に位置するのがSourceシステムで、ここはSAP製品のERP（SAP-ERPとします）のケースと、SAP以外の製品のERP（Non-SAP ERPとします）が考えられます。

SourceシステムがSAP-ERPの場合

まず、SAP-ERPの場合についてお話をしていきます。SLT Serverとの接続を行うにあたり、SAP-ERPには小さなカスタマイズを行います。これは、Source システムであるSAP-ERP側でデータベースの更新があったらそれを瞬時にとらえて、CFINへのデータ連携を始めるというアクションを開始するためのカスタマイズとなっています。

この、Sourceシステムのデータベースに更新が加わったかどうかをモニターし続け、更新が入ったデータを読み取る仕組みをSLT Read Engineと呼びます。なお、SAP-ERPがECC等の旧製品の場合はこのカスタマイズが必要ですが、S/4の場合は不要で、SLT Serverとの接続だけでデータ連携が可能となります。

この連携は、データベースに更新が加わることでデータ連携が始まるので、データベーストリガーのデータ連携であるといえます。

こうしてデータ連携が開始されると、SourceシステムからデータがSLT Serverに渡されます。ここで、まず受け取り手であるSLT Serverと技術的に接続・疎通ができている必要がありますので、この接続の確認をするのがSLT Server内のTechnical Mappingとなります。ここで問題なく接続ができた場合、SLT Serverが受け取ったデータはSLT Write Engineに渡され、CFINに対して書き込みのアクションが始まります。

SourceシステムがNon-SAP ERPの場合

では次に、Sourceシステムが非SAP製品であった場合についてみていきましょう。非SAP製品がSourceシステムである場合は、こちらの非SAP製品からSLT Server内のStaging Table（一次受けのデータベース）にデータの書き込みを行ってもらう必要があります。

この際、非SAP製品とSAP製品のデータベースのマッピングが必要になります。非SAP製品のデータが持つコードの体系はSAP、つまりCFINが想定しているコード体系とは異なることが大半ですので、単純な項目と項目のマッピングに加え、Sourceシステム側のコード体系をCFIN側のコード体系に合うように修正をかける、といった処理も必要になってきます。

こうした書き込みが行われれば、そのあとはSAP-ERPの場合と同じようにStaging Tableが更新されたことをトリガーにしてSLT Read Engineが更新データの読み込みを行い、あとはSLT Write EngineがCFINに対する書き込みのアクションが始まります。Staging Table自体がSLT Server内にいるので、Technical MappingはNon-SAP ERPの場合は不要となります。

Non-SAP ERPの場合でも、Staging Tableに対してはデータベーストリガーでのデータ連携となります。Sourceシステム側のデータベースの更新をトリガーにしたいのであれば、Staging Tableへの書き込み自体もSourceシステム側のデータベーストリガーにすることで対応が可能となります。

SLTのDeployment Option

SLT Serverの役割、仕組みを説明したところで、Deployment Optionを解説します。先ほどの図では、SLT ServerはSourceシステムとCFINの間に位置するように記述しましたが、実際には3つの位置がオプションとして考えられます。

オプションは、以下の３通りとなります。

SLT ServerをSourceシステム、CFIN双方から独立させて配置する
SLT ServerをSourceシステムと同じインスタンスに配置する
SLT ServerをCFINと同じインスタンスに配置する

SAP社の推奨は①となります。①のメリットは、Sourceシステム、CFINと独立した形でSLT Serverがいるため、Sourceシステム側のシステムメンテナンス、CFIN側のシステムメンテナンスなどに依存しない形でSLT Serverが稼働を継続できます。あるいは、SLT Serverだけに対して何らかのメンテナンスを加えたいときも、Sourceシステム、CFIN側には影響がありません。

ちなみに、SLT Serverが動いていない間にSource システムでデータの作成が行われた場合は、SLT Serverが動くようになった後でそうした差分データをCFINに連携する、ということももちろん可能となります。

②は、SLT Serverを複数あるSourceシステムのうちのどれかに配置することとなります。メリットは、インスタンスの数が削減できる点と、SLT Serverが併存しているSourceシステムと直接接続されているためデータ連携が若干早くなる、といった点がありますが、デメリットとしてはSourceシステムがメンテナンス状態に入るとSLT Serverに影響が出る、という点です。

複数あるSourceシステムのうち、SLT Serverと併存するSourceシステムがメンテナンスに入るだけで、全SourceシステムからCFINに対するデータ連携ができなくなってしまうので、この案はSAP社の推奨とはなっておりません。

③は、SLT ServerをCFINと同じ場所に配置します。メリットはインスタンス数が削減できること、そしてCFINと直接的に接続しているのでCFINへの書き込みが若干早いことです。デメリットは、CFIN側で何かしらのメンテナンスをするときなどはSLT Serverの稼働も止めないといけないという点です。

CFINと記述していますが、実際にはLogistics関連のモジュールもCFINの配置されるインスタンス内で動いている可能性があります。そうした場合、Note適用や軽微なカスタマイズ、メンテナンスが発生する頻度はそこそこあるものです。したがって、そうしたメンテナンスのたびに影響の調査をしたり、場合によってはデータ連携が止まる、といったケースが発生してしまいます。

よって、SLT ServerのDeployment Optionとしては、①＞③＞②の優先順位で検討を行うと良いでしょう。

MDGを用いたデータ整合

従来はデータ整合が課題

それではここから、MDGを用いたデータのマッピング、Business Mappingについて見ていきたいと思います。具体的なシステムの動きや仕組みを話す前に、従来の視点に立ち返って、データの集約におけるデータ整合の課題を見ていきましょう。

以下に、Central Financeを用いて複数のSourceシステムからデータを集約するアーキテクチャーを載せています。こちらを見て頂けるとわかる通り、Sourceシステムは様々で、S/4かもしれませんし、ECCかもしれませんし、SAP製品ではないものであることもあります。

こうした状況でデータの集約を行おうとすると、従来はSourceシステム側のデータを同じ粒度でそろえる、同じものを意味するのであれば同じコードに整理する、といったことが必要です。

異なるSourceシステム間では異なるマスターデータが使用されているのは珍しくなく、同じVendor、Customerを意味しているのに違うコードを使っている、というケースはよくあります。

そうした状況では、データの集約を行う前に前処理として、「このマスター：AAAはこのマスター：XXXと同じである」、といった整理をする活動が必要でした。こうした活動はかなり大規模に実施することもあり、マスター：AAAとXXXのケースでは、「グループ全体でこれからはマスター：XXXを使うことにしよう！」と決め、すべてのマスター：AAAをXXXで上書きする、といった活動をとることもありました。

しかし、過去から現在に至るまでマスター：AAAで積み重ねてきたデータを上書きするというのは現実的ではない為、データの集約を行うシステムの中だけで、そうした「マスター：AAAは実はマスター：XXXのことを意味している」、といった読み替えを行うアプローチをとることが多く、いずれにせよ読み替えを行うための処理ロジックを持つことが必須でした。

MDGの提供するBusines Mappingは、こうしたマスターデータ間の読み替え、つまりマスターデータとマスターデータの間のマッピングを簡単に整理することを可能とします。

データ整合の対象は3種類

次に、データ整備が必要な対象を見ていきましょう。CFINを導入するにあたり、複数のSourceシステムのデータが同じくCFIN内で扱われるようにするために必要となるデータ整備は、以下の３点になります。

マスターデータ：MDG Key Mappingで対応
カスタマイズ：MDG Value Mappingで対応
Cost Object：Cost Object Mapping Frameworkで対応

それぞれに対して、対応する方法が決まっています。ここまでで、MDGを用いて実施するBusiness Mapping、という言葉を用いてきましたが、Business Mappingの中に、さらに3つの手法が対象となるデータの種類3つに分かれているとお考え下さい。

MDG Key Mapping

MDG Key Mappingは、MDGの機能を用いてCentral Finance上でマスターデータとマスターデータのマッピングを行うことを意味します。設定自体はMDGのライセンスを持っている場合はMDGに対して実施することとなります。

場合によっては、MDGのライセンスを持っていないケースもあるでしょう。そんな場合でも、結構大変な作業になるとは思われますが、CFIN上でマスターデータ同士のマッピングを定義することは出来ます。

ただし、CFINを活用しようと考えるような企業であれば、マスターデータの整合性を保つことの重要性については認識されていると思いますので、大半のケースでMDGのライセンスも持っているでしょう。

イメージとしては、CFINで保持するマスターデータに対して、Sourceシステム×Sourceシステムで保持されているマスターデータの組み合わせをマッピングすることとなります。これにより、複数のSourceシステムでそれぞれ異なるコードを用いているマスターデータであっても、CFIN上では同じマスターデータとしてとらえることが可能となります。

マスターデータの例としては、Material Master, Business Partner(Customer Master, Vendor Master)、Profit Center, Cost Center等が該当します。

MDG Value Mapping

MDG Value Mappingは、MDGの機能を用いてCentral Finance上でカスタマイズ値とカスタマイズ値のマッピングを行うことを意味します。設定自体はMDGのライセンスを持っている場合はMDGに対して実施することとなります。

こちらもMDG Key Mappingと同様に、仮にMDGのライセンスが無かったとしてもCFIN上で設定を行うことは可能となります。

カスタマイズの例としては、Sourceシステムで使用しているEnterprise Structure（Company Code, Plant, Sales Organization等）、Document type等が該当します。

これらのカスタマイズも、CFINで保持するカスタマイズ値に対して、Sourceシステム×Sourceシステムで保持されているカスタマイズ値の組み合わせをマッピングすることとなります。これにより、複数のSourceシステムでそれぞれ異なるカスタマイズをしていても、CFIN上では同じカスタマイズ状況としてとらえることが可能となります。

Cost Object Mapping Framework

個々までに話してきたマスターデータ、カスタマイズに対するマッピングと少々毛色が違うトピックとして、Cost Objectが存在します。Cost Objectは、費用をを紐づける相手であり、Sourceシステム側で何かしらの費用が発生するたびにInternal Order、Production Order等のデータが作成されることが一般的です。

従いまして、マスターデータやカスタマイズはそこまで頻繁に更新・新規作成がされないデータでありLong Living Dataと呼ばれる一方で、Cost Objectは頻繁に作成され、費用をつけるという目的が完遂されればその後は使用されることが無い、という意味でShort Living Dataと呼ばれます。

Long Living Dataについてはマッピング情報を定義しておくことは極めて合理的と考えられますが、Short Living Dataについても同じ方針を貫くべきなのかというと、そこに疑問符が付くのはご納得頂けるのではないでしょうか。

よって、CFINでは、Sourceシステム側で毎度毎度Cost Objectが生成されても、CFIN側では一つのCost Objectに費用をまとめておいて管理し、都度都度生成してしまうといったことを避けるといった手法が推奨されています。これを仕組みとしてサポートするのが、Cost Object Mapping Frameworkで、図解すると以下のようになります。

左に図示したSourceシステムでは、例としてProduction Orderが製造活動を行うたびに生成され、費用情報を個別にまとめています。対して右に位置するCFINでは、Central Cost Collector (この場合はCentral Product Cost Collector)が一つあるのみで、これに費用情報がまとめられるようにしています。

このように、Source側でProduction Orderが生成されたらどうするか（Mapping Scenario）、マッピングは1:1かN:1か(Mapping Rule)、マッピングする先はどのCost Objectか（Cost Object Assignment）をそれぞれ定義してくことで全体としてSourceシステム側のCost Object生成に合わせてCFINがよどみなく動くようにするのですが、ここで行う設定全般をCost Object Mapping Frameworkと呼んでいます。

なお、この設定もMDGを介して実施することとなりますが、MDGライセンスが無ければCFIN上に設定も可能です。

MDG、Source System、CFINの連携イメージ

それでは、ここでSourceシステム、MDG、CFINがどのように連携するのか、マスターデータのやり取りとそのマスターデータを用いたデータが連携される様子を例を挙げながらみていきましょう。MDGのライセンスがあるということを前提としています。

第一に、まずMDGがマスターデータを作成すると、それがSourceシステムに伝達されます。ここでは、Customer Masterが新規に作成されたとしましょう。MDGでは、CUST_001というコードが使用されました。

第二ステップは、CUST_001というデータをSourceシステムが受け取るところとなります。このSourceシステムでは、Customer Masterの番号採番ルールが既に決まっており、Cから始まる７桁の番号と決まっていたので、独自に番号を振り直しました。MDGからはCUST_001で送られたものに対して、SourceシステムはC000001 と名前を付けた、という状況になります。

第３ステップあ、SourceシステムがMDGに対して生成したCustomer Masterの番号を送り返すという処理になります。MDGは、Sourceシステム側で採番したC000001という番号を受け取ります。

第四ステップとして、MDGはSourceシステムから返送されたCustomer Masterの番号を自分が採番した番号と紐づけます。ここで、CUST_001とC000001がマッピングされることとなります。これが、MDG Key Mapping(あるいはMDG Code Mapping)と呼ばれるものとなります。このマッピングは、第一～第四ステップで見てきたMDG⇒Sourceシステム⇒MDGという情報の流れで生成することも出来ますし、ユーザーが入力することで設定することも出来ます。

つまり、第一～第三ステップを飛ばして第四ステップをユーザーがマニュアルで設定する、ということももちろんできるという意味になります。導入時は、第四ステップをユーザーがマニュアルで設定する、という作業を行うのが一般的でしょう。

次に、第五ステップですが、ここでSourceシステムからC000001を用いた伝票が作成され、CFINにデータ連携が起こります。

第６ステップでは、CFINがC000001というマスターデータを持ったデータを受け取り、MDG Key Mappingの情報を確認することで、CUST_001というマスターデータに読み替えられます。そして、後続の処理につながっていく、ということとなります。

MDGのDeployment Option

MDGにも、SLT Serverの時と似てDeployment Optionが複数存在します。SAP社による推奨は無いそうなので、ここはインフラ/Basis担当のチームと相談して決めていくことになるでしょう。オプションは以下のとおりです。

MDGをSource、CFINと独立して配置
MDGをCFINと同インスタンスに配置

①の場合はSourceのメンテ、CFINのメンテにMDGが影響を受けないというメリットがあります。

②の場合はCFINと同環境にあるので、CFIN側で何かメンテナンスをするとなればその影響がMDGに及ぶ可能性がありますが、CFINとMDGの間で常に発生するマスターデータ、カスタマイズ、Cost Objectのマッピング等に関するQueryが同インスタンス内で行われるので処理が若干早くなる、というメリットもあります。

SAP社の推奨は存在しない、というのは重々承知の上でですが、①のほうが無難かなぁという印象ですね。

AIFによるエラー検知、連携再実行

さて、CFINの構成要素の最後になります。ここでは、AIF：Application Interface Frameworkをご説明します。

AIFでは、CFINに向けて行われたデータ連携、CFINが行おうとしたデータの書き込みの状況が監視され、エラーがあった場合にはその原因と併せて記録が行われます。カレンダー形式でエラーを俯瞰することが出来、いつどんなエラーが何件発生したのかがすぐにわかる設計となっています。

エラーについてはその理由もログとして残り、マスターデータのマッピングが無い、カスタマイズのマッピングが無い、等の原因がわかります。エラーが発生したときにはメールで通知も可能なので、気づかないということもありません。

また、エラーが起きた場合にはそのエラーを解消するような設定、マスターデータの登録などを行った後で、エラーが発生したデータ連携、書き込みを再度AIF上で実行するということが出来ます。したがって、データの書き込みが失敗したあとに再実行しようとして、Sourceシステム側で何かをしてもらう必要はありません。

CFIN導入における論点

ここまでで、CFINの仕組みなどを見てきました。ここからは、CFINを導入するというプロジェクトが発足した場合、あるいは検討の土台に上がった時点で、考慮しておくべきポイントについて個人的な意見を述べていきたいと思います。

ビジネス上の観点

導入の目的は何か？
Centralで処理を行う業務はどこまでを範囲とするか？

最初に考慮すべきポイントは、ビジネス上でのCFINの立ち位置です。CFINを使うこと、導入することがビジネスにおいてどのようは意味合いを持つのか、どういったことを期待されているのか、といったところから明確にしてプロジェクトを開始することが肝要です。

一つ目は、目的です。CFINでできることは、さまざまありますが、その中でもどれを目的にしているのか。これが明確でないと、プロジェクトの期間中に発生する検討事項に対する視点がぶれてしまいます。

データが自動で集められるようになればいいのか、それとも業務を集中管理・実行することも目的なのか、これが大きなポイントですが、ここを決めずにCFIN導入を始めて、「出来れば業務をCentralで実行したいんだけど・・・」という話を途中で世界各地域に存在するグループ会社のCIO, CFOと議論しても、結論が出るまでに相当の時間を要することは容易に予想できます。結論が出るまでの間、CFIN導入プロジェクトが停止してしまう、というのは望むところではないでしょう。

したがって、プロジェクト開始前にCFIN導入の目的を整理しておくことは非常に重要です。

二つ目は、Centralで業務を行うことを目指すのであれば、どこからどこまでをCentralで実施するのか、といったスコープを明確にしておくことです。支払いの例でいえば、支払いの実行までをCentralで実行するのか、あるいは支払いは地域の慣習に合わせて個社で実施させるのか、といった線引きを明確にし、関係者に周知する。

こうしたスコープによっては、CFIN導入プロジェクトがただのCFIN導入プロジェクトの範疇を超え、業務標準化といった性質により近いプロジェクトに変容していく可能性もあります。そうなると、必要になるコンサルタントの品質、巻き込むべき人材も変わりますので、スコープを決めることも当然ながら、重要となります。

CFIN導入の経験があるというコンサルタントを使うだけでは期待した効果が得られない可能性もありますので、そうしたリスクを低減するためにも成し遂げたいことを明確にすること、これが何よりも重要となります。

テクニカルな観点

アーキテクチャーの論点
データ統合の論点

ビジネス的な論点が整理されましたら、そのあとは比較的簡単です。テクニカルな観点で考慮しておくべきポイントについても整理しておきますと、一つ目はアーキテクチャー、二つ目はデータ統合が上げられます。

一つ目のアーキテクチャーですが、これはSLT Serverをどう持つか、MDGをどう持つか、といった話になります。既存のインフラの状況を考えて検討していくことになるかと思いますが、場合によってはCFIN導入スケジュールにあわえて過渡期対応を検討する、といった別タスクの必要性なんかもわかってくることがあります。

二つ目は、データ統合の方針です。グループ企業が複数あるのであれば、それらのSourceシステムとCFINとの間でデータのマッピングが必要となることはすでに説明した通りですが、CFIN導入に合わせて全体的に見直しをかけるのか、それともマッピングで何とかするのか、あるいはCFINのマッピングでは対応できないケースなどが無いか、といった調査も必要となります。

実際、CFINの導入を行うという点ではやることが決まれば後は設定を行う、必要なデータを流すだけなのですが、その前のデータ統合の方針決定、検討が最も時間を必要とする作業となります。

複数のグループ企業を持つと、データが散在していてまとめて現状を理解するだけで大仕事ですので、ここを担当する人材の品質は相当に重要な要素となります。