システム見積金額を大きく削減

問題の背景

Y社の事業は順調に成長していましたが、一方で売上や取引先の増加に伴い、業務過多に陥り、現場対応も限界に達していました。現行システムは各セクションが独自のものを使用し、システム間の連携は皆無。Y社が今後も成長を続けるためには、新システム構築と業務の見直しは不可欠でした。

これまでY社は何もしてこなかったわけではありません。過去10年近くで、新システム構築のプロジェクトを何度か立ち上げています。しかし、各セクションの意向が強いためか、業務が特殊すぎて仕様をまとめきれなかったのか、過去のプロジェクトはすべて途中で頓挫していました。

Y社は「次こそは」と不退転の覚悟で再度プロジェクトを立ち上げます。社内には「またどうせ失敗するだろう」という悲観的なムードもある中、新プロジェクトがスタートします。

見積金額が6億円と4億円

半年後、プロジェクトメンバーとシステムベンダーが協力して、すべてのセクションの業務要求をまとめ上げました。しかし、業務が特殊であったため、Y社に合うパッケージシステムが見つかりません。

そこで、システムベンダーが提案してきた案は2つ。1つはすべてスクラッチ開発する案。見積金額6億円、開発期間3年です。もう1つは、約30%程度適合するパッケージを核にして、大幅なカスタマイズを施す案。見積金額4億円、開発期間2年半です。

Y社にとって、4億円はこれまでにないシステム投資額です。ただそれ以上に問題なのは、新システムが稼働するまであと3年かかってしまうことでした。ずっと社員に負担をかけてきて、さらに3年耐え忍んでもらうのは・・・Y社の経営陣はなかなか結論を出せないでいました。

業務要求をスリム化する

そんな頃、人づてに当事務所のことを知ったY社からご相談がありました。まず聞かれたのは、「Y社の事業規模にとって、4億円はシステム投資金額として妥当なのか」ということでした。

会社のシステム投資金額は一律に決められるものではありませんが、年商や社員数、事業の種類によって、ある程度の相場感というものはあります。Y社の場合、今後の成長まで加味すれば、新システムの業務範囲から見て、そこまでおかしな金額ではありませんでしたので、そのように答えました。

次のご質問は「開発期間を短縮する方法はないか」でした。システムベンダーの提案内容をざっと見て、第2案もほぼスクラッチ開発であることはわかりました。

中川:「開発期間を短縮するには限界があります。年単位で稼働を早くしたいなら、パッケージ比率を高めるしかありません。」

Y社:「当社に合うパッケージ製品を何か知ってるのですか?」

中川:「いいえ、知りません。ですが、システムの視点で業務要求を再整理して要件をスリム化し、業務単位で異なる複数のパッケージを組み合わせできれば、開発を抑えてパッケージ比率を高められる可能性はあると思います。」

システムの視点とは何か ~3つの例~

業務要求は、現場のリクエストを一言一句そのまま写実する作業ではありません。最終的に作るのはシステムです。常にシステム実装のことを考え、システムの視点も入れながら、現場のリクエストを整理していきます。

ここでは、よくあるシステムの視点を3つお話しします。

実行系システムと計画系システム

実行系システム(例:ERP)は「仕入先に商品を発注する」「売上を集計する」など、実際の業務を処理するシステムです。これに対し、計画系システム(例:SCM)は「適切な発注量を計算する」「工場の生産計画を作る」など、現場の意思決定を助けるシステムです。

両者は大きく仕様が異なり、市販のパッケージもそれぞれ独立して存在します。ですから、実行系に高度な計画機能を盛り込もうとしたり、計画系に本来実行系がやるべき機能を実装しようとすれば、開発は肥大化、システム自体が失敗しかねません。

両方必要な場合は、実行系と計画系の業務要求をきちんと線引きし、システム間のデータ連携を考えます。

伝統的な管理会計・原価計算

伝統的な管理会計・原価計算は、情報を細かく捉えたがる傾向があります。たとえば、この経費は、どの部門の誰が使用し、どの得意先・案件のために使用したのか。この原価は、どの製造部門が、どの製造番号の何の作業の時に、何の機械を使って使用したのか。

売上やコストを多様な要素と関連付けできれば、管理や分析はしやすくなります。しかし一方で、要素の種類が増えるとデータは指数関数的に細分化されます。

製造部門(例:10部門)×製造番号(例:年1000件)×作業(例:100タスク)=生成データの種類(例:1,000,000通り=10×1000×100)

データ量は増え、システムは複雑化し、それを入力する現場担当者の業務も増えます。あれもこれもと、いたずらに要素を増やしすぎないように注意します。

内部統制(申請・承認)

「仕入先に商品を発注する」「得意先に見積書を提出する」「立替経費を会社に請求する(精算する)」など、色々な場面で、上長に申請・承認をもらう行為が発生しています。

だからと言って、購買管理システムの「発注メニュー」、販売管理システムの「見積メニュー」、経費精算システムの「経費精算メニュー」、それぞれに同じような「申請承認機能」を開発するのは大いなるムダです。

共通化できる業務は外出し、別なシステムでの共同運用を考えます。特に電子申請承認系は多くのパッケージが存在しているので、自社の要望にマッチした製品が見つかることでしょう。

業務要求を見直した結果

当事務所はプロジェクトメンバーと一緒に「業務要求」を見直しました。必要に応じて再度、現場担当者にヒアリング。本当に必要十分な業務ラインはどこなのかを探っていきました。

また、システム構想(グランドデザイン)では基本方針を変えました。全業務を網羅的にカバーする汎用パッケージがないことは確認されていましたので、主要業務それぞれの専用特化型パッケージまで調査範囲を広げ、適合性を検討しました。

業務要求をスリム化し、複数ベンダーの複数パッケージを組み合わせて使う方針で、再度見積りを取り直した結果、トータルのシステム見積額は、当初の4億円の半分以下に。懸案だった開発期間も1年半まで短縮することができました。

専用特化型パッケージの標準機能で、Y社の要求を叶えることができたのが幸運でした。

※上記内容は、複数のプロジェクト経験を部分的に組み合わせ、登場人物・状況・数字等は改変し、フィクションも一部交えています。