加速する製造現場のデジタル化の最前線で、変革者である企業のリーダーや製造現場の方々と、歩みを共にする弊社のメンバーだからこそ知っている、変革の舞台裏、成功事例集の行間に隠されたストーリーを垣間見る本連載。
過去3回に渡り、製造DXプロジェクトにおける目的設定の重要性についてお伝えしてきました。成功するDXプロジェクトには、関わる誰もが共感できるような、強くて明確な目的意識があることを実例を交えてご紹介して参りましたが、果たしてそれだけで上手くいくのでしょうか。第五回目となる今回は、プロジェクトの推進に焦点を当てて考えていきたいと思います。なお、過去の連載分もご覧になってみてください。
お客様のDXプロジェクトから学んだこと
以前、弊社の生産系のソリューションを担当する技術部門のマネージャーが、弊社が関わった多数のDXプロジェクトを定量的に評価したことがあります。うまく推進出来たとされるプロジェクトと、苦戦したと言われるプロジェクトとの間にどのような違いがあったのか分析し、改善するためです。評価はまず、「プロジェクトの”狙い”」、「プロジェクト推進の”体制”」、「意思決定における”ガバナンス”」、「既存システムの”マスタ”がどのくらい流用できたか」、「新たに導入するシステムと隣接する”他システム”との互換性」という5つの項目について、各5段階の評価基準を策定し、基準に基づき各プロジェクトの責任者に採点してもらうことから始めました。補足になりますが、”体制”と”ガバナンス”については、弊社等外部のパートナーを含まず、「お客様の社内の”体制”と”ガバナンス”がどうか？」という視点で評価させていただいています。
そして、スムーズに推進できたと言われるプロジェクト群と、苦戦したと言われるプロジェクト群に二分し、先述の5項目それぞれについての、平均値を算出して比較し、両者の平均値の差異が大きい項目ほど、プロジェクトの成否に与える影響が大きいと考えます。
結果は上図の通りです。生産システムの導入によるDXプロジェクトというと、どうしてもマスタの流用性や他システムとの互換性といったテクニカルな面に目が行ってしまいますが、実はどのようなタレントがアサインされ（体制）、各自がどのような役割と責任のもとで意思決定をしていくか（ガバナンス）という”人”に関わる側面の方が、成否に対する影響度は高いようです。
同じ時、同じ場所で、同じ手順で進めても、結果が同じとは限らない
とある産業機械メーカー様の新工場に、弊社の生産システムを導入いただいた時のお話をさせて頂きます。これは、工場の実行管理や品質管理といったMES（Manufacturing Execution System）の領域に加え、在庫、保全、従業員情報などの管理までを含む、統合的な製造オペレーションの管理を行うため、MOM（Manufacturing Operations Management）という大掛かりな仕組みを、２つの異なる生産方式の部門に導入するという大規模なプロジェクトのお話です。２つの部門は、共通のトップマネジメントのもとで連携をとり、共通機能の検討を行いつつも、具体的な生産要件の違いにより仕様が異なる部分については、それぞれのユーザーとなる部門が主導して検討を進めました。仮にこの2つの部門をＡ部門とＢ部門とします。
2つの部門のシステムは、ほぼ同時期に概ね同様の検討工程を経て、システムの本稼働を迎えましたが、いざ現場で動かしてみると、両部門の反応は全く異なるものでした。現場からの僅かな変更要求に対応するだけで、概ねスムーズに現場に適用されたＡ部門に対し、Ｂ部門はというと、現場から「この機能がないと仕事が出来ない！」、「緊急で変更が必要だ！」と、多くの変更要求が発生し、結果的に社内外の関係者が総出で対応にあたることとなってしまったのです。
メンバーのアサインメントがプロジェクトの成否を分ける
下図はこのプロジェクトにおいて、実際に仕様変更が発生したタイミングをスコープごとに集計したグラフです。変更要求がプロジェクトの序盤に集中しているＡ部門と比べ、Ｂ部門の方では、プロジェクトの初期にしっかりと要件を詰め切れていなかったことが、見て取れます。ではなぜ、このような差が生まれてしまったのでしょうか？
実はA部門とB部門とでは、プロジェクトへの力の入れ様に差があり、それがこのような結果の違いを生んだようです。A部門では、プロジェクトを今後にとって重要な取り組みだと位置づけ、普段は重要な顧客案件の現場を仕切っているような精鋭陣をプロジェクトにアサインしました。こうして出来たA部門の検討チームでは、一つ一つの業務を深く知り、かつプロセス横断的な視点もある人材が、適格に現状を分析し、新たに導入しようとしている仕組みとのギャップを調査しました。そして、限られた経営リソースの中で何処を優先するべきか、しっかりと議論した結果、プロジェクトの序盤に的確に仕様を固めることが出来、かつ稼働後の変更要求は片手で数えられる程度で済みました。一方でB部門はというと、通常業務が優先だと捉えたため、プロジェクトにアサインされたのは比較的社歴の浅いメンバーでした。若手の有望株なので、優秀な人材でしたが、それでも業務のすべてを俯瞰したり、各所の細部に渡る検討のような経験がものを言う世界において、十分に要件を詰め切れなかったりすることが少なからずあったようです。
複数の部門を跨ぐプロジェクトにおいて、部門ごとの力のかけ方に差が出たり、その結果アサインされるメンバーの力量にも差が出たりするということはよくあることです。幸いこのプロジェクトにおいては、強いリーダーシップと、部門間の協力関係があったことで、予定通りにGO-LIVE(稼働開始)を迎え、稼働後の変更要求についても大きな問題になることなく対処が出来ましたが、序盤であれば、たいしたことのない変更要求であっても、終盤や稼働後になってくると甚大な手戻りになることも少なくありません。それに、「いつまで経っても立ち上がらない」と、現場から不満が募ったり、メンバーも疲弊したり・・・・・・。プロジェクトをヘルシーに推進するためにも、（難しいとは思いますが）各部署から最低1人はエース級の人材をアサインすることをお勧めします。
ユーザー部門とIT部門の協調がプロジェクトを成功に導く
さて、MOMのように、大規模なシステムの導入プロジェクトでは、IT部門と業務部門の関わり方も重要です。以前、筆者が個人的に交流のあるITコンサルタントからお聞きしたお話です。このコンサルタントに相談を持ち掛けた企業では、現行のシステムの老朽化をきっかけに、DXプロジェクトと称して新たなシステムの導入を検討していました。システムの保守期限が切れ、社内外にメンテナンスできるエンジニアもいなくなり、いよいよ「なんとかせねば！」と重い腰を上げてのプロジェクトでした。しかし、現場のユーザーにヒアリングをしてみると、新たなシステムに求める要求は、「今のシステムと同じ」でした。長年に渡り、自社の業務を知るエンジニアが、その時々に必要な機能を作り足してきた「今のシステム」には、作り手のこだわりが詰まっていますし、使い手にとっても細部にまで気が利いています。そんな愛着のあるシステムを変えると聞き、「なぜわざわざ変える必要があるんだ？このままで良いじゃないか！」と、反発が生まれたのです。気持ちは分からなくはありません。
「IT部門がやっているプロジェクトだから」と、ユーザー部門が“他人事ムード”になってしまったので、「それならば」と実際にシステムを利用する業務部門に意見を求めると、「どうせ新しくするなら、この際これも一緒に作ってよ」、「この辺も楽になるといいな」と、個別の業務に特化した機能要求ばかりが膨らんだりします。見積りは当初の予算を大幅に超え、仕方なく諦める機能を取捨選択しようとしても、ユーザー部門は忙しさを理由になかなか意思決定にも参加してくれなかったり、「必要な機能を勝手に取り除かれた」とヘソを曲げられたり・・・。結局収集がつかなくなり、最後は経営層の独断でプロジェクトは凍結することになったというのです。
この例のように、IT部門のみに任せっきりになり、先述した例で言うところのA部門やB部門のような実務を担当する部門の関わりが薄いと、プロジェクトはなかなか上手く進みません。現場の業務の詳細までは把握していないIT部門にとって、使い手の都合を十分に考慮することは簡単ではありません。後々になって要件漏れが多発してしまったり、To-Be重視で”あるべき論”に囚われてしまったりと、現場から「使えないシステムだ」と後ろ指を指されてしまうという事態の多くが、こうしたケースによるものです。
では、現場を熟知した実務部門だけでプロジェクトを行うのはいかがでしょうか？結論から言うと、それはそれでなかなか上手く事が運ばないようです。業務部門が「自分たちの現場で使いやすいように」と、As‐Is重視で要件を詰めてしまうと、特定の工場でしかおこなわない特殊な業務のやり方まで拾ってしまったりします。個別最適なシステムになってしまうのです。こうして出来た訛りの強いシステムは、単一の工場で用いる分には活躍しますが、いざ他の工場にも展開しようとすると、なかなか方言が消えずに苦労するものです。また、サーバーやネットワークなどのITインフラの都合までは考えられず、気づいたら実現性が低い内容だったということも、実務部門が主体のプロジェクトではしばしば目にします。
ITの専門的な知識があり、事業横断的な最適化を図るIT部門と、業務を熟知し、工場単体でのパフォーマンスの最大化を目指す業務部門、両者が協調し、バランスを取りながら進めることが重要です。またこの時に、責任の所在が曖昧になり、お互いが責任転嫁をしてしまったり、部門間の調整に時間がかかってしまったりすることがある点には注意が必要です。全体をまとめるリーダーをきちんと設け、意思決定のプロセスを明確にすることが重要なのです。
さて、今回はDXプロジェクトの推進において、重要なポイントの一つであるプロジェクト推進の体制について、推進チームにアサインするべき”タレント”と、部門を跨いで協働する際の関わり方の２つのポイントに分けて、お話をさせて頂きました。次回はもう一つの重要なポイント、意思決定におけるガバナンスについて考えていきたいと思います。
ビジネス・ディベロッパー。変革の提案をおこなう営業担当者や、ビジネスの上流から共に変革を描くコンサルタント、現場の仕事とシステムをいかに良くするかに日々奔走する技術のメンバーや、成功した事例を世に知らせようとするマーケティング担当者など。そんな彼ら、彼女らが知る、変革の舞台裏、成功事例の行間に隠されたストーリーが、今まさに変革を進めようとする方々の一助となればと思い、それらの一部を紹介させていただきます。