なぜ案件と売上データを並べて可視化するのが難しいのか

なぜ案件と売上データを並べて可視化するのが難しいのか

以前、自社に利益を還元するレベニュー&プロフィットマネジメントという記事を書きました。

営業組織でマネジメントする領域を5つに分けた時の4つ目のトピックになります。

  1. テリトリマネジメント:マクロ的な観点からの市場動向の把握
  2. アカウントマネジメント:個々のお客様に対する自社の提供価値の定義
  3. ソリューションマネジメント:自社の提供価値の定義
  4. レベニュー&プロフィットマネジメント:自社に還元される利益計画
  5. リソース&スキルマネジメント:実行に当たっての人員構成計画

前記事では、レベニュー(売上)と、プロフィット(利益)について触れましたが、一定量の売上がないことには利益も得られません。

そこで、中期計画や期初に立てた年次計画通りに売上があがるのかを知りたくなるのですが、記事の冒頭に掲載したようなグラフを作るのにはやっかいな課題があることが多いです。

それは、受注前の案件データと、受注後の売上や、受注残のデータは別システムで管理されていることです。

avatar

ここはかなりやっかいです

関連記事:Salesforceでフォーキャスト管理がしづらい理由

本記事では、なぜ案件と売上データを並べて可視化するのが難しいのかについて紹介します。

案件データと売上データ(受注データ)はマスタデータが異なる

別システムで管理している場合でも、多くの場合、案件管理システムのデータは受注や売上を管理するシステムに連携されます。

なのに両方をまとめて一つのグラフで簡単に表現できないのは、双方のシステムで持っているマスタデータが異なるのが原因です。

大きくは顧客マスタと商品マスタです、特に顧客マスタで差が生じます。

もちろん高い精度で管理されていれば差は出なくはなるのですが、取引先に対して口座を開いて契約を締結する粒度の顧客データと、受注前段階で営業側で管理する顧客データだとどうしても受注前のデータのほうがゆるくなりがちです。

差がある状態で2つのデータを並べると、顧客企業の親会社が一致しなかったり、顧客や親会社を自社でどういう業種として扱うかに齟齬が生じます。

すると、単一の顧客や案件レベルでは発生し得ないようなギャップが生まれることになるのです。

案件管理システムのIDを受注システムに連携すれば解決?

とはいえ案件管理システムから受注システムにデータを連携しているのであれば、元データになる案件データのキー項目であるIDを持たせておけばいいのでは?と思うかもしれません。

持たせられれば、受注済みの案件データと受注残のデータを重複させないよう扱いやすくはなります。

ただ、両システムの間で顧客や業種のデータが異なった場合にどう扱うかの課題は残ります。

さらに、こうした顧客企業と親会社の関係や、自社の中でどの業種として扱うかは、日々変わっていきます。そうした時に過去に遡って集計をし直すのか、それとも確定したものは当時のままとして比較するかの決めも必要になります。

財務管理上は、期ごとに締めたものは変えるわけにはいきませんが、今後の事業を考える上で意味のある前年比較をするためには必要に応じて適切なくくりで集計や比較することが求められます。

最適解に向けて粘り強い整備が大切

いろいろな業種のクライアントでこの課題と向き合ってきましたが、一朝一夕になんとかなるものではなく、地道な整備が大切というのが結論です。

システム刷新のタイミングは、データをきれいにするチャンスではありますが、一方でデータ移行を行ったり、複数システムからデータを統合した時には齟齬も生まれやすいです。

また、案件管理と受注管理、というように2つに限らず、別で顧客管理のマスターシステムがあったり、承認ワークフローを管理するシステムが別にあったりと、データの中でもどれが正しいのか判別しづらいこともあります。

ですのでこうしたデータマネジメントはもはやシステム開発などの一時的なプロジェクトではなく、定常業務のマネジメントの中で整備を続けていくことが大切と考えます。

▼私がこの手の管理のあるべき姿を学んだ本です。

avatar

発売されてから時間が経っていますが、本質は変わらないと思います。

このブログを書いている人
電子書籍「システム導入のためのデータ移行ガイドブック」著者。 新卒から外資系コンサルティングファームに所属。15年に渡り販売物流、特にCRM領域のコンサルティングに従事。 100名を超えるプロジェクトのPMOなど全体を推進していく役回りや、ユーザ企業への出向を通じた実務経験を持つ。

このブログでは、自身がかき集めた知識や経験を共有する。クライアントへの提案やソリューション開発に直結しないガラクタのようなもの。将来再利用する自分のために。同じような悩みを抱える誰かのためにブログ「元外資系コンサルのガラクタ箱」を運営