デジタルトランスフォーメーションシリーズ：ラストマイル

公開: 2018-04-20

この投稿を読んでいる場合は、おそらくまだ変革プロジェクトの最後の1マイルに到達していません。

多くの場合、変革プロジェクトの最後の数か月は、プロジェクトの計画、コミュニケーション、およびチームの編成がどれほど優れていても、完全に消費されるまで激しくなります。これは、デジタルトランスフォーメーションが会社の非常に大きな組織に頻繁に影響を与えるためです。おそらく、会社がこれまでに見た中で最大の影響でさえあります。

多くの場合、デジタルトランスフォーメーションは、これまでの何よりも、企業の技術的、ビジネス的、および組織的な要素に影響を与えます。

その影響を考えると、企業は簡単に失敗します。途中でスコープを縮小し、ロールアウトをステージングして影響を軽減し、監視を強化して、プロジェクトの速度を落とします。通常、これらのアプローチ（これらのひざまずく反応）は間違いです。以前の投稿で述べたように、デジタルトランスフォーメーションは、企業を変える難しい経験です。会社全体が変更の背後にいること（上から下へ）は、プロジェクトの最終的な成功のレベルを定義します。ひるまないでください！変革がビジネスに与える影響と価値を最大化するために、プロジェクトの最後の数マイルで実行できる手順があります。

プロジェクトの早い段階でミッションステートメントとプロジェクトのコミュニケーションが適切に管理され、配信されていれば、ロールアウトの最終段階で発生する可能性のある多くのノイズを減らすことができます。

最後のフェーズは、現在のプロジェクトが提供できる価値を議論するための絶対に間違った場所です。最も簡単な方法は、騒がしい人たちに、プロジェクトの元の、エグゼクティブがサポートするミッションに戻るように指示することです。とは言うものの、特に、変革の混乱のレベルが明らかになったときに、新しいプレーヤーが現れることがよくあります。

ミッションステートメントとエグゼクティブの承認は、新しいプレーヤーに大きな心を落ち着かせる影響を与える可能性があり、以前のコミュニケーションを彼らと共有することも、彼らがプロセスの一部を受け入れて感じるのに役立ちます。

プロジェクトの後の段階では、タイムラインにプレッシャーがかかり、スケジュールを短縮する方法を探すことがよくあります。ここでは非常に注意する必要があります。

プロジェクトには、しばしば妥協される4つの領域があります。これは、プロジェクトの成功に大きな悪影響を及ぼします。

デジタルトランスフォーメーションプロジェクト：テスト

多くの場合、デジタルトランスフォーメーションはITから管理されます。テストは、技術的およびビジネス上の受け入れテストの組み合わせとして開始される場合がありますが、配信のプレッシャーの下では、これはターゲットとして大きくなります。プロジェクトのテストサイクルを圧縮するのが一般的です。プロジェクトチームがプロジェクトのライムラインで最初に見る可能性のある場所の1つは、ビジネスユーザーの受け入れテストです。これは非常に危険な場所です。

ソフトウェアの受け入れとコメントにビジネスユーザーを関与させることはプロジェクトの重要な部分であり、このサイクルを通過するには時間がかかります。システムとユニットのテストに同じレベルの厳密さが適用されているようには感じられないかもしれませんが、少なくとも同じくらい重要です。タイムラインを節約するためにここをカットすると、ユーザーが完全に拒否したり、構築されたものに挑戦したりするため、多大な手直しが必要になる可能性があります。これはタイムラインに影響を与えますが、プロジェクトの成功への勢いとサポートを損なう可能性もあります。ビジネスユーザーの関心を維持し、可能な限りタイムリーな対応を促します。ユーザーテストを減らす他のコースは、リスクを倍数増やします。

統合フェーズ

新しいソフトウェアの展開は、真空中では起こりません。接続する他のシステムは常にあります。変革プロジェクトでよくある間違いの1つは、これらのレガシーシステムへの統合が以前と同じように機能すると想定することです。ほとんどすべての場合、それは悪い仮定です。

私は最近、最終的な運用開始のために提供する必要のある50を超える統合を特定した顧客と協力しました。専門のサービスチームと協力して、プロジェクトにとって何が重要で、何が遅れる可能性があるかを1つずつ確認することができました。

統合の検証はプロジェクトの後半まで行われないため、統合の部分を加速するのは当然のことです。これは非常に危険なことです。統合の失敗は、変革への最後の大きな課題であるとよく見られます。時間をかけて、どの統合がリアルタイムで、どれがほぼリアルタイムで、どの統合をバッチにプッシュできるかを特定することで、統合の課題を解決することができます。

多くの場合、最も「高価な」リアルタイムコールが必要であると特定された統合は、それほど重要ではなく、ほぼリアルタイム戦略を適用できることがわかります。古典的な例—誰かがカタログ内のアイテムの詳細を見るときに、リアルタイムの在庫検証が本当に必要ですか？ショッピングカートに追加された場合でも、リアルタイムの検証が必要ですか？多くのビジネスケースでは、カートがチェックアウトのために確認されたときに、リアルタイムの在庫呼び出しのみが発生します。

ラストワンマイルに到達する前に統合の問題を文書化して検証できるほど、このテストを生き残る可能性が高くなります。何年にもわたって構築されたレガシーシステム統合は、新しいシステムに接続したときに同じように機能しないことがよくあります。これを早期に掘り下げることは、この重要な取り組みにおいてのみあなたを助けることができます。これは、検証なしで仮定を立てることが戻ってきて、大きな課題を引き起こす領域です。

負荷テスト

統合の取り組みと密接に関連しているのは、負荷テストです。多くの場合、顧客はベンダーのソフトウェアのストックパフォーマンスに基づいて負荷について推測します。これは誤った推論です。特定のニーズに合わせてソリューションを適合させ、カスタマイズしています。変更されたすべての設定とすべてのカスタムワークフローにより、ベンダーがスループットに対して提供したベンチマークからさらに一歩離れることができます。さらに、統合はソリューションのパフォーマンスに大きな影響を与えます。ベンダーがその影響を予測する方法はありません。

パフォーマンス検証の一環として、アーキテクチャ、設定、統合、およびカスタム作業を確認するには、特定のベンダーの関与が必要です。これを怠ると、稼働に大きな問題が発生する可能性があります。最近、40か国での展開計画のうち最初の4つを展開した後、顧客から連絡がありました。4つのうち最大のものはアイルランドでした。彼らはかなりの規模の問題を抱えていました。パフォーマンスチームとの緊急の関与の後、ソリューションの大幅なリファクタリングが必要であることが明らかになりました。システムが負荷テストに合格するまで、追加のロールアウトを遅らせる必要がありました。その結果、CIOにとって回避可能なエグゼクティブチームの困惑が生じました。

その前に、システム負荷テストがプロジェクトの基本的な部分である必要があることを強調しました。欠落している、またはこのステップを十分に表していない場合、ほとんどの場合、ひどい結果になります。

トレーニング

プロジェクトが時間/納期のプレッシャーにさらされている場合、企業が最初に注目することの1つは、トレーニングコンポーネントです。ここでカットすることは、プロジェクトの納期厳守の課題への影響を減らすためのもう1つの簡単な方法のように思われることがよくあります。しないでください！

トレーニングは、デジタルトランスフォーメーションプロジェクトから始めるために、しばしば過小評価されています。誰もそれを使用できないために失敗する新しいシステムを持つことほど悪いことはありません。多くの場合、これはテクノロジーの問題ではありません。人々はシステムを機能させるか、機能させないかです。それらの人々は、彼らが何を使用しようとしているのかを知り、それを受け入れる必要があります。

トレーニングは大きく2つの主要な要素に分類されます。どちらも無視しないでください。

システムトレーニング：これは、プロジェクトで設計したワークストリームとビジネスプロセスを管理するチーム向けのトレーニングです。これは、トレーニングの焦点の大部分が行くところです。システムが展開される理由と方法、および彼らの仕事がどのように変化するかを人々が確実に理解することは、努力の最後の1マイルにとって重要です。長い間存在していたビジネスプロセスを大幅に変更する場合は、ここでかなりの量の作業が発生します。チームが何をしているのか、そしてその理由を知っていることを確認してください！

これは、新しいソリューションの興奮を高めるチャンスであり、これらのチームを買収することで、ロールアウトで避けられないバンプがスムーズになります。このトレーニングは、3つの側面で構成する必要があります。教室またはオンサイトでのベンダートレーニング、ビジネスのために作成された独自性のためのシステムインテグレーターの修正、およびユーザーが安全な環境でミスを犯す可能性のあるサンドボックスエクスペリエンスの実践です。お願いします。何をするにしても、ユーザーがあなたが与えたものを単に受け取ると思い込まないでください。これは、デジタルトランスフォーメーションの成功を主張するために必要な勢いを構築するための優れたアプローチではありません。適切なトレーニング計画を作成し、手抜きをしないでください。人々を訓練に送り、彼らを努力に従事させてください—それは配当を支払います。

エンドユーザートレーニング：これは、デジタルトランスフォーメーションの展開で十分に提供されていない別の領域です。あなたができる最善のことは、エンドユーザーのサンプルと通信し、エンドユーザーがそれに応じてトレーニング計画を把握して作成するのにかかる時間を確認することです。多くの場合、企業はソリューションの「チャンピオン」として一連のエンドユーザーを含めることを好みます。これは、システムをすでに理解しているチームにユーザーコミュニティを「シード」するのに適しています。

ラストマイルは常にクランチが来るところです。しかし、上記の手順は、一歩踏み出すのに役立ちます。