SIerが勝ち残る為に

今から4・5年前にエリヤフ・ゴールドラット著「ザ・ゴール」を読んだ当時は、その概念をそのままシステムインテグレーションの業務に当てはめることができなかった。しかし、前職を辞める少し前に読み直した際に、ようやく理解することができ、適用するとこのような形になるのではないかという、自分なりの考えをまとめて見た。

もちろん理想論ではあるが、目指すべきはこういう事だと思う。所詮理想、と切り捨て真逆のビジネスを繰り広げるから利益率が上がらないのだと、今も勝手に思っている。

------
利益率が低いのは、ジョブロスが多いから。

ジョブロスが多いのは、見積りの甘さ、もしくは単純に納期遅れ。

見積りの甘さについて。

見積りの甘さは、プロジェクトという不確定要素の多い業務である事から仕方ない面もあるが、プロジェクト完了後の振り返りなどにより、次回の見積りの時に反映させるPDCAのサイクルが必要。

納期遅れについて。

見積りが甘くないが納期遅れを引き起こす原因は、PJメンバーのマルチタスクによるオーバーヘッドの積み重ねによる。マルチタスクをしてしまうと、業務の切り替えの時に必ず、前にどこまでやったか、今はどうなっているかなどの準備工数が必要で、これが見えないコストとして積み上がるため、全体として納期が遅れる。

マルチタスクの内容としては、単純にPJのマルチタスクだけでなく、その他業務上の事務処理などもあげられる。

利益をあげるために必要なのは、経費を落とす事(コストカット)と売り上げをあげることだが、売り上げをあげる事を妨げるコストカットはむしろ売り上げをさげてしまう。

売り上げをあげるにはビジネスフロー全体のスループットをあげる必要があり、これが会社の利益に直結する。

つまりスループットを抑える様なコストカットは利益に結びつかないどころか、むしろ減収させる。

スループットのパフォーマンスはボトルネックのパフォーマンスによって決まるので、ボトルネックのパフォーマンスを如何にあげる事ができるかにかかっている。

ボトルネック以外のパフォーマンスをあげても、スループットには貢献しないし、在庫を増やすだけであり、逆効果につながる。

以前の会社でいえば、構築チームのパフォーマンスが全体のスループットに大きく影響している。

そのため、如何に構築チームのタスクを各PJに集中させるか、そしてそれ以外のタスクを如何に排除できるかが重要となる。

PJ進行中の構築チームに見積りの作成、委員会活動など、スループットを下げるタスクを割り当てるのは全体のパフォーマンスを下げる行為であり、利益が下がる。

では見積りは誰がすべきかと言うと、見積り専任チームとPJ完了した構築メンバーで行うべき。見積りチームは拡販チームがもっと製品知識を学び、基本的な構成はそのチームだけで見積りが作れる体制が必要。複雑だったり大規模な構成の場合は、アイドル状態にある構築チームが見積りに参画すれば良い。

PJ完了した構築チームをアイドル状態において置くことについては、ボトルネックを休ませることにるが、見積りを行うことに加え、新製品の評価や新しい構成の評価など、教育の時間として割り当てることで、常に最新の技術を吸収させる期間にすればよい。

見積り作成チームの評価尺度は、受注したPJの最終的なパフォーマンスによって図るべきである。闇雲にとってくればいいのではなく、精度の高い見積りが必要となり、それによりPJ完了後の振り返りで分析が必要となり、次回の見積り時に反映させる。

重要なことは、ジョブロスが多いために利益率が低いからといって、闇雲に受注を増やせばいいのではなく、いかにジョブロスをなくすかであって、そのためには各PJのスループットを高めることである。

PJを掛け持ちさせてマルチタスク化するのではなく、如何に一つのPJを納期前に完了させるかを考えるべきである。
-------
時間がたった今日、読み返すと多少無理なところもあるとは思うが、基本的な概念はあっていると思う。

転職してSIerとしての仕事をすることはなくなったが、今度は新しい会社でどう適用するか。