SaaS ERPをFTSで導入するためのチェンジマネジメント 総論賛成から各論反対／意識改革の分岐点 その6：自走できる組織
これまでプロジェクトメンバーは、SaaS ERPをFTS（Fit to Standard）アプローチで導入するにあたり、チェンジマネジメントのステップを順に第一弾の「認知」から始まり「共感」「内省」「習得」へと段階を重ねてきました。そして、前回掲載の「実践」では、CRPでビジネスプロセスモデルとビジネスデータモデルを決定し、自分たちが主体となってそのモデルをさらに運用モデル評価で検証してきました。またこの過程においてプロジェクトメンバーは、ERPの習熟度を「O」：人に指導できるレベルに到達しています。
次の第六ステップは「自立」、すなわち「定着と自走」の段階です。ここでは、ERPを実際に業務で操作するエンドユーザーを受け入れる段階です。このステップを経て初めてERPの本稼働判定がクリアとなります。裏を返せば、エンドユーザーがERPを操作できない、または、拒絶するようなことになると本稼働を迎えることは叶いということです。
エンドユーザートレーニングで直面した“反発”
新しいシステムは、あらゆる準備が整った状態でエンドユーザーを迎えるはずでした。操作手順のマニュアルも用意され、実データの移行も完了し、使用するメニューも整理されていました。システムの完成度も高く、システム統合テストではエラーも一切なく、技術的には申し分のない状態でした。プロジェクトメンバーは「これで受け入れられるはずだ」と万全の体制で臨んでいました。
ところが、結果は大きく裏切られました。ある事業領域のキーマンをはじめとするエンドユーザーが、新システムの使用を強く拒んだのです。プロジェクト側の予想を超える、激しい反発でした。
その反発の理由は明確でした。
ひとつは、「自分たちの声がまったく反映されていない」と感じたこと。
もうひとつは、「新しい仕組みでは手間ばかりが増えて、これでは現場の仕事が回らない」との訴えでした。
この強い反発の結果、次のようなことが現場で起きました。すでに設計を終えていた領域に対し、従来型の業務に戻すような追加の開発要求が出されたこと。
こうした混乱が生じた背景には、明らかにチェンジマネジメントの不在がありました。そして同時に、ステークホルダーマネジメントが十分に行き届いていなかったことが、事態を悪化させたのです。エンドユーザーが反発したのは、決して彼らが保守的だったからではありません。巻き込まれていなかったが故に、「自分ごと」として受け止める準備ができていなかったのです。
もう少し具体的にお話しします。
この新システムでは、トヨタ生産方式に倣い、データの流れも「一個流し」に設計していました。つまり、モノの動きに合わせて、その都度リアルタイムに処理を行う方式です。ところが、現場が求めていたのは、従来通り一日の終わりに「何十件もの処理を一括で登録できる」仕組みでした。いわば、「だんご生産」ならぬ「だんご処理」が現場の常識だったのです。
つまり、新業務の考え方に慣れるどころか、エンドユーザーに業務モデルの説明すら行われないまま、エンドユーザーへのトレーニングを迎えてしまった。このような状況では、受け入れられるはずがありません。反発は、ある意味で必然だったのです。
このときの反省点は、大きく三つあります。
第一に、プロジェクトの目的である「リードタイムの短縮」や「本質的な生産性向上」を、現場に対して十分に具体的なかたちで共有できていなかったこと。
第二に、反発の中心となった事業領域のキーマンが、プロジェクトに最初から参画していなかったこと。
そして第三に、そのキーマンの影響力が大きく、他のエンドユーザーもそれに倣って拒否反応を示したことです。
このときは、トップダウンでなんとか本稼働にはこぎつけました。しかし、表面的な稼働とは裏腹に、現場では抵抗が続きました。旧業務が密かに旧システムに登録され続けていたのです。
この出来事は、私がユーザー企業のプロジェクトリーダーを務めた30年前の実例です。今振り返れば、まさに「チェンジマネジメントのない導入」がもたらした典型例でした。そして驚くべきことに、こうした事象は、現在でもERP導入の現場で時折耳にします。
反発なくエンドユーザーを迎えるためのチェンジマネジメント
こうした事態を避けるために、これまでチェンジマネジメントの５つのステップを重ねてきました。重要なことは、どの業務領域においても、その業務に精通したキーマンをプロジェクトメンバーとして参画してもらう必要があるということです。
仮に物理的に参画が難しい場合でも、プロジェクト側からそのキーマンをステークホルダーとして位置付け、コミュニケーションの手段を持って意図的に接点を作ります。そして、新しい仕事の仕方を構成する上で、要所要所でアドバイスなどの助けをもらうことで、そのキーマンには、「自分たちの仕事を一緒につくっている」という感覚を持ってもらうことができます。これは、たとえプロジェクトメンバーでなくても、自分ごととして新しい業務のあり方を共に構築するという、双方向の関係構築でもあるのです。
第六ステップ：自立〜定着と自走〜
こうしてキーマンとの関係を築いた上で、いよいよ迎えるのが第六のステップ、「自立」です。この段階では、エンドユーザーの全員が初めて新しいシステムに触れることになります。システムが完成し、操作方法などのマニュアルが整備されたタイミングで、エンドユーザーが実際に業務で使う準備を始めることになるのです。
前述の通り、エンドユーザーの中でもキーマンは、プロジェクトメンバーとして参画しているのが基本です。実務を熟知している彼らが、CRPの段階で新しい業務についての抜け漏れは、すでに解消されているはずです。
しかしながら、人が変われば見方も変わります。システムが完成して初めて操作するエンドユーザーからは、新たな意見や要望が出てくるものです。この場合の対処として、まず大切なのは「否定しない」ことです。
新しい要求が出た場合には、一旦MoSCoWに挙げた上で、新しい業務をまずは覚えてもらいます。その際のポイントは次の4つです。
- プロセスおよびデータモデルの軸は揺るがさない
- 拡張機能開発予算を残しておく
- 本稼働に直結しない要望はMoSCoWで「Won’t」とし、本稼働後の対応とする
- 内製スキルの育成を通じて、将来の変化に自走できる力を備える
この段階に至ると、すでにビジネスプロセスやデータモデルの軸は確定しており、それを大きく揺るがすような変更は行うべきではありません。仮にここで安易に追加開発を認めてしまえば、影響は想定外の範囲にまで波及し、問題が次々と発生してしまいます。多少の不便があったとしても、まずは合意されたモデルで運用を開始することが重要です。
とはいえ、現場のエンドユーザーから、補助的な照会画面やレポートなどの追加要望が寄せられることも想定されます。こうした声を無視せず、そのために残しておいた拡張機能開発の予算をもとに、必要な対応を柔軟に検討することで、現場の納得と安心感を得ることができます。
加えて、これらの要望に対しては、MoSCoWの原則に基づき、本稼働に直結しないものについては「Won’t（今回は見送る）」と明確に位置づけ、本稼働後の段階で対応する旨を丁寧に説明します。そうすることで、単に断るのではなく、誠実に応える姿勢を示し、エンドユーザーの信頼を損なうことなく受け入れを促すことができるのです。
また、こうした“枝”にあたる機能は、プロジェクト中に内製スキルを身につけておくことで、現場主導で対応できるようになり、結果として自走力のある組織づくりにもつながっていきます。
エンドユーザートレーニングにおいては、新たな現場の声にも丁寧に耳を傾けつつ、まずは決定した業務モデルを理解し、運用してもらうという方針でマネジメントを進めてきました。これは、単に使い方を教えるだけではなく、新しい業務スタイルを主体的に受け入れてもらうためのチェンジマネジメントの一環です。
こうした一連の取り組みは、「意識改革」の名のもとに進められてきた活動ですが、それはプロジェクト全体の品質を支える基盤としても機能しています。業務プロセスやデータ、システム、そして人の準備がどれだけ整っているか。それを測る本稼働判定の場面において、その効果は定量的にも、定性的にも、はっきりと現れるのです。
次のパートでは、六つの本稼働判定領域それぞれにおいて、チェンジマネジメントがどのように品質向上に貢献しているのかを整理してみます。
本稼働判定とチェンジマネジメントの関係
本稼働判定は、単に「システムが動くかどうか」を確認するだけではありません。それまで取り組んできたチェンジマネジメントの成果が、組織全体で受け止められ、実践に結びついているかどうかを見極める重要な節目です。
判定の対象は、ビジネスプロセス、ビジネスデータ、技術、人材、移行、運用の6つの領域です。これらはいずれも、チェンジマネジメントの6つのステップと深く関係しており、意識の変化が行動の変化として表れているかが問われます。
例えば、業務プロセスが標準モデルに基づいて定義されているだけでなく、現場がそれを実際に使いこなしているか。データが整備されているだけでなく、整合性や活用の視点まで備わっているか。トレーニングが実施されただけでなく、評価指標であるILUOが「O：指導できる」レベルに達し、現場内でスキルが循環しているか。これらはすべて、現場が継続的改善に向けて自ら動き出せているかを見極める重要な手がかりになります。
つまり、本稼働判定で真に問われているのは、Fit to Standard（FTS）の考え方がどれだけ組織に浸透し、実行されたかということです。“標準に合わせる”のではなく、“標準を活かす”という姿勢が、どれだけ行動変容をもたらし、組織を変革へと導いているか。本稼働判定はその成果を可視化する機会に他なりません（詳しくは、SaaSタイプのERPにおけるプロジェクト品質-顧客変容編-参照）。
なお、この本稼働判定の6領域については、次回のブログで改めて詳しく解説する予定です。ここでは、チェンジマネジメントが本稼働判定に直結するという視点だけを、まずお伝えしておきたいと思います。
問題発見と業務改革を自走できる組織づくり
ビジネス環境の変化とともに、システムを更新する必要が訪れます。この時に、ERPのコンセプトを理解して自社のモデルを構築してきた効果が発揮されます。
ある食品製造業のユーザーは、業態転換に応じて、自社メンバーのみで速やかに対応することができました。具体的には、新製品の構成、新しい配送ルート、販売オーダーのパターン追加、など、多岐にわたる設定が必要な難易度の高い変更だったのですが、トレーニングやCRPで、画面の標準の項目を使用するかどうかに関わらず表示しておいたおかげで、使わない項目にも自然と目が行き、また、あらかじめセットされていたデータモデルもそのまま残しておいたので、それらをヒントとして、柔軟に対応を完遂することができたのです。
また、新しく登録したマスタデータに不備があった場合でも、自分たちでテストをして、データの間違いを見つけることができます。これは、自立の第一段階である「運用モデル評価」と画面やレポートの拡張機能開発を自社で行えるようになったことが功を奏しました。
そして、データモデルをプロジェクトの目的に沿って再構成し、その過程で項目レベルまで熟知したことで、分析において、BIのダッシュボードをブラッシュアップできるほどになりました。特にこの分析において、成果を納めたユーザー企業のプロジェクトマネージャーが言っていたことが記憶に強く残っています。「KPIはビジネスとともに変化します。だから、分析基盤は自社でメンテナンスできるようにするのです」というものです。現場に精通したスタッフが、ERPのデータを項目レベルまで熟知すると、このような産物が生まれます。これは、組織がビジネス環境の変化にアジャイルにシステムをデリバリーできることを意味します。
SaaSタイプのERPは、時代とともに機能が拡張され、ITの進化を取り込んでいきます。その恩恵を最大限に享受するためには、導入時点での「自走力」が鍵になるのです。
本連載で紹介してきたチェンジマネジメントの六つのステップ、その軸にあるのは、プロジェクトメンバー一人ひとりが抱える「心配」と、どう向き合い、どう乗り越えるかという人間の変化の物語です。最初は、自分にできるのか、ついていけるのか、という不安や戸惑いがあります。しかし、ステップを重ねるごとに、仲間とともに学び、試し、振り返る中で、少しずつ「できるかもしれない」という実感に変わっていきます。そしてその実感は、やがて自信となり、さらに他のメンバーへと伝播していきます。この繰り返しがプロジェクト全体を支え、個人のスキル獲得だけでなく、組織全体の行動様式を変えていきます。最終的には、自ら考え、学び、改善し続けるアジャイルデリバリー型の組織へと変容していくのです。
チェンジマネジメントとは、「変化を受け入れること」を強いる活動ではなく、「変化を自ら引き受けられる人と組織を育てる営み」なのです。
