現状維持という最大のハードルを越えるためにコストを示す

「現行システムのままでいいんじゃないか」

変革を伴うプロジェクトは必ず抵抗勢力がいて「現状維持」の圧力をかけてきます。

この圧力の中でどう進めればよいのでしょうか？

「現状維持」と「変革」を比較して、「現状維持こそが最悪」というシナリオを示すしかありません。経営層に定量的かつ論理的に比較結果を示し、判断してもらいます。

この現行ロックインの牙城を切り崩すのが「コストシミュレーション」です。主観的、定性的な話に持っていかずに数値で示します。

この時、「イニシャルコスト」だけではなく「ランニングコスト」も含めるようにします。

なぜなら、イニシャルコストだけを見てしまうと、どうしても「何もしない」現行システムの方が費用はかからず、良く見えてしまうからです。必ずランニングコストも含めたトータル金額でみます。

その上で、システムを3年、5年、10年と使った場合の費用をシミュレーションしていきます。

それをグラフ化して「3年目で費用は同じになり、5年目には新システムの方が○○円安くなります」などを示せると、経営層は判断しやすくなります。
 

現行との比較で「アップル to アップル」は難しい

このコストシミュレーションですが、費用の「全て」を盛り込むことがポイントです。

新規ベンダーからの提案書に記載されているのは、ベンダー側が直接担当するシステムのイニシャルコストとランニングコストです。これらの費用は、ベンダーがわかりやすく明細を提示してくれるので、費用に含めるのは簡単です。

一方で現行ベンダーとも比較する場合は、もう少し費用のスコープを広げた上で比較しないと「アップル to アップル」にはなりません。

現行システムと比較する際には、どのような費用を含めるべきなのでしょうか？
 

漏れやすい費用項目

漏れやすい代表的な費用項目を挙げてみます。

① システム連携の総費用

システム連携する「相手側」のシステム費用もきちんと含めます。これは、連携するシステムとデータ種類の数だけ、それぞれ見積もります。そのため異なるベンダーに見積もりを依頼して、費用情報を入手する必要があります。

ただし、そのシステム費用だけ見てしまうと「お金がかかるだけ損する」という話になってしまいます。

そうではなく、連携が自動化されることで、連携にかかる手作業が減る、対応人数が減る、パート・アルバイトの人件費や代行業者の委託費が減るケースも出てきます。

費用として、プラスとマイナスの両方を比較項目として含めます。
 

② 人件費

もっとも見過ごされがちだが、非常に重要なのが社員やパート、アルバイト、派遣、業務委託を含めた人件費です。業務は、システムと人手の「総和」です。現場の業務は、システムで自動化・効率化されなかった部分を人が手作業でやっています。

導入するシステムによって、業務の守備範囲が変わります。システムで自動化や効率化できる範囲も変わります。だからこそ、コストシミュレーションにおいては、業務の範囲をそろえ、その内訳としてシステム費用と人件費の総和で評価するのが、正しいやり方です。

逆を言えば、システム費用だけを見てしまうと「アップル to オレンジ」となり、そもそも公平な比較となりません。システムの守備範囲の狭い方が安くなるのは、当たり前の話です。システムでカバーされなかった部分は人手に転換されるので、そこを含めるということです。

社員の人件費をいくらで見積もるかは悩ましいですが、リアルな職員の給料ではなく、今後、誰が担当してもいいように、平均値で試算します。

この人件費も分解すると、主に業務部門の「エンドユーザー」と情シスの「システム管理者」です。それぞれで、システム導入することによる作業工数の増減を含めていきます。

なお、システムの外でやっているエクセル作業が、新システムで置き換わるなら、そこの工数変動も含めるべきです。エクセルをマクロ化していて、そのマクロの保守を情シスがやっているなら、その保守工数がなくなることも反映していきます。
 

③ クラウド関連費用

オンプレミスからクラウドに移行するなら、それらに関連する費用も大きく変動します。サーバールーム、空調、電気代、あるいはデータセンター費用、監視や保守する社員の人件費などがクラウド費用に置き換わります。

また、それに伴いVPN費用やクラウド側の監視オプション費用など、セキュリティコストも対象となってきます。

クラウドには、テレワーク環境の構築、労働環境改善の側面もあります。わざわざ帰社しなくてもよくなり、交通費の計算が変わってくるかもしれません。顧客サービスの時間拡張により、機会損失を防ぐなどの効果も考えられます。
 

④ 現行システム改修費用

現行システムは、何もしないで良いわけではありません。新システムで実現できる機能、便利になる機能、解決される課題があるなら、揃えるべきです。それらを現行システムで改修した場合の見積もりを取得し、比較対象とします。

また、重要なのは保守費用もあらためて見直してもらうことです。現行費用で削減の工夫ができるのであれば、その提案をもらいます。仮に、現行システムが再び選ばれたとしても、現状で全くなにもしなかったケースよりも「現行改善案」の方が、コスト優位になるようにします。

つまり、現行は完全な「なりゆき」と「改善案」の2つの案を比較対象とします。
どのシステムが選ばれたとしても、プロジェクトの活動が会社にとってプラスとなり、関わったプロジェクトメンバーが評価されるよう計画すべきです。
 

現状維持という最大のハードルを越えるためにコストを示す

　現行システムを推す方々とは、一時的に対立するかもしれません。でも、これはプロジェクトの宿命です。見方をかえると、抵抗が大きければ大きいほど、既得権益を打ち破り、会社にとっては大きな変革を進めている証拠といえます。
　現場の方々は、感情的に厳しい言葉をあびせるかもしれません。しかし、プロジェクト側が感情的に応戦すると「負け」です。泥沼化するだけで、現場の協力がとりつけられなくなります。
　対立した場合は、誰がまちがっているとかの「人」を論点にはせず、何がいけないのかという「課題」を論点にあげます。会社にとっての「共通の敵」という位置づけで、客観的に進めていくしかありません。
　仲良くしてもらえないかもしれませんが、必死に愚直に進めていくと、少しずつ現場の応援者は増えていくはずです。
　そもそも、プロジェクトが立ち上がった背景には現行システムの問題がたくさんあるからです。プロジェクトの初心にかえって、プロジェクトが解決すべきテーマを議論し、客観視していきます。議論をオープンに進めて、公平性や客観性をもった結論が出せれば、全社的に大手を振って進められるようになります。
　ベンダーが決まったあとは、仕切り直しで現場をさらに巻き込んだ形で進めていきましょう。