SAPでは満たされない部分を埋める
これまで、SAP導入により財務会計や統制/監査は満たされるが、システムを入れるだけでは管理会計やデータ分析は不十分である。それにはデータ体系化のレベルを高めなければならない、という論を展開しました。ここで求められる全体観とは、『計画⇔実績』『経営⇔現場』『入力⇔出力』『業務⇔システム』など、かなり幅広い視野とバランスにより成り立つと考えます。
こう考えると、かなり途方もない話に聞こえるのですが(もちろん、事実高いハードルですが)、最大のポイントは、『マスタ設計レベル』と考えます。なぜなら、マスタがデータを横串でつなぐ役割を果たしてくれるからです。特に管理会計では品目マスタではないでしょうか。これに分析に必要な属性が漏れなく設定されている必要があります。
そして、勘定科目と異なり、品目はビジネスの変化とともに、定義や項目、親子関係などひんぱんに変化するため、これを柔軟に吸収できる必要もあります。
このように運用された品目を軸として、あらゆるデータが体系化する設計と運用が出来ていれば、SAPによるデータの見える化の準備の8割は出来たといっていいのではないでしょうか。
◼️まとめ
①品目マスタをビジネス要件の変化に柔軟に運用させる
②その品目マスタがあらゆる会計データに漏れなくセットされる必要がある
SAPのデータを直接分析する難しさ
前回書いたように、あらゆる業務データを一元管理するのがSAPのキモです。であれば、そのデータを直接見て分析したり、次の戦略を練りたくなるのが経営陣の自然な希望でしょう。それができて投資対効果のバランスも取れるってモンです。
ところが、そう簡単に行かないのが多くのSAPユーザー企業での現実ではないでしょうか？
基本的な原因は、『入力→データベース→出力の関係が複雑すぎること』にあると思います。つまり、出力/分析するのに分かりやすい構造でデータベースという素材が提供されてれば良いのですが、SAPのデータはリレーショナルデータベースという構造と業務プロセスを数珠つなぎに関連付けるという特性が相まって、分析者が非常に扱いにくい状態といえます。よって、『分析したい観点をデータ構造に翻訳できるブリッジ役』が不可欠と言えます。
さらには、多くの企業で以下のような課題があるのではないでしょうか？
①計画対実績を分析したいが、計画データはSAPに入力していない、あるいはメッシュが粗い。
②製品別の分析をしたいが、品目マスタの属性情報が不十分で、分析業務に堪えられない。
③各組織のデータを重ね合わせていくと入力項目の漏れがある。
④マスタの自動名寄せができない。特に品目や科目。
いかがでしょうか？どれか一つでも当てはまると、システム上の直接データ分析は出来ない事態になります。要するに、『出力→データベース→入力』という逆算でシステムを見れて、さらに業務に落とし込める人材が必要なのですが、得てしてモジュール分業制のSAPだとコレがなかなか難しいですよね…
◼️まとめ
①分析がうまくいかないのは、データの体系化が不十分だから
②SAPで財務会計はうまくシステム化できても、管理会計はさらなる体系化や詳細化したデータが必要
③それを全体最適で設計できる人材が非常に不足している
SAPの得意な事/苦手な事
前回の続きとして、SAPの特徴をまとめ、そこから生じるメリットとデメリットを話そうと思います。
SAPを一言で言えば、大量のテーブルが複雑に絡み合ったモンスターシステム、と思います。
「そりゃリレーショナルデータベースなんだから、大量のテーブル(二次元のデータリスト)で構成されているに決まってんだろ」と言われたらその通りですが…
コレを業務プロセスと表裏一体かつ数珠つなぎにデータを更新させる所に、この高額システムが他国/他業種で使われる万能性やウリがあると思うのです。
『業務とシステムが表裏一体』というのがミソで、これにより『企業データを体系的かつリアルタイムに漏れなく保持する』というSAPの最大の特長が実現されます。つまり、会社をデータで定量的につかみたい人たちには、非常に有益なワケです。一方で、『データを数珠つなぎして全体をつかむ』為にデータ入力時の負担が大きくなります。これによって、「データの源流は大変だが、川下の人たちは助かるよ」ということになります。
川下の経営陣や経理や監査や係数管理部門にメリットがあればまだイイのですが、問題は川下の経営陣がシステムを見てなかったり、レポートを使いこなせてなかったりというジレンマがあることで…この辺はまた改めて書きます。
◼️まとめ
SAPというモンスター級のデータベースにより、
①経理や監査はメリットがある。
②データ入力者は負担あり。
③経営陣にもメリットありのハズだが、何故か享受していない。
業務経歴
◼️SAP導入(20代)
外資系コンサルでビッグプロジェクトを経験しました。やる気とガッツと若さで乗り切ったかんじですね…
良かったのは、SAP/会計/英語を身につけ、仕事のデカさや器の大きな人のカッコ良さを勉強できたことですね。SEとして、基礎を固める良い時間だったと思います。
一方、『部分』しかつかめない物足りなさ、隙あらば上から目線で語りたがるコンサルのアホさ、決められた物を作るが課題解決や新たな価値提供までに至らぬ業界体質も経験しました。
この時の問題意識から、全体を体系的に考える、システムを業務プロセスとのクルマの両輪として捉える、システムを使いこなすために積極的な提案をする、ということを考え始めました。ここらがこのブログで書きたいメインテーマでもあります。
◼️SAP運用保守(30代中盤まで)
グローバルに販社を展開する日本企業でSAPの運用保守をしました。主な達成事項は…
①FI/CO/SD/MM/BW/SEM/BASISと幅広く＆グローバルにカバー。⇒やっとSAPに自信が持てるようになりました。
②運用保守を管理するツールを自作(案件/工数/移送/成果物を体系的に管理できる。)⇒Excel台帳による旧石器時代から大幅進化…と自画自賛！社内であまり誉めてくれないのでw
③複数のベンダーを一つにまとめて、さらにAMOを導入してコストの変動費化。⇒この５年で外部ベンダーへの支払は半分に削減。
④サーバを物理からVMwareの仮想へ移行。インフラ系はあまり詳しくないですが、良い経験でした。
…とまあ、自分のやりたい事を思う存分やらせてもらえ、前職で出来なかった『全体・業務・提案』を実現できて、ホントに社内SEに転職して良かったです。
そして、SAPで出来ない事/苦手な事も見えてきた頃です。
①経営者の為のシステムであり、現場では使いにくい。
②そのわりに、経営レポートはExcelで作っており、経営陣はシステムを直接見ない。
…何なんでしょうね、このジレンマ。
SAPなんて高額パッケージを使う意味あるの？…ってあたりを今後書いて行こうと思います。
自己紹介
大阪在住で社内SEをしてます。SAP、Web/Mobile開発、情報系システムで悩み考えることを書きます。
ITは会社の役に立っているのか？もっとビジネスのロケットになれないか？志高く持ちながら…。
好きな言葉は『一期一会』です。
