このブログ投稿では、ゲスト作成者であり分析の専門家であるMike Norrisから、分析の近代化イニシアチブで回避するための計画と落とし穴に関する知識を共有できることを光栄に思います。
分析の近代化イニシアチブを検討するとき、調査すべきいくつかの質問があります…物事は現在機能しているのに、なぜこれを行うのですか？ どのような圧力が予想されますか？ 目標はどうあるべきですか？ 避けるべきことは何ですか？ 成功する計画はどのように見えるべきですか？
なぜアナリティクスを近代化するのですか？
ビジネス分析では、イノベーションは前例のない速度で提供されています。 「最新情報」とホットを活用するという絶え間ないプレッシャーがあります。 Hadoop、Data Lakes、Data Science Lab、Citizen Data Analyst、すべての人のためのセルフサービス、思考のスピードでの洞察…など。 おなじみですか？ 多くのリーダーにとって、これは彼らが投資に関して大きな決定に直面する時です。 多くの人は、より多くの機能を提供しようとして新しい道を歩み始め、不十分です。 他の人々は近代化の道を試み、リーダーシップからのコミットメントを維持するのに苦労しています。
これらの近代化の試みの多くは、新しいベンダー、テクノロジー、プロセス、および分析製品の追加をもたらします。 この形式のモダナイゼーションは、より迅速な初期勝利を提供しますが、通常、分析パズルの既存の部分を置き換えるのではなく、それらと重複するため、技術的負債とオーバーヘッドを残します。 これらのタイプの「近代化」は、より飛躍的なものであり、私が「近代化」と見なすものではありません。
分析の文脈で近代化と言うときの私の意味の定義は次のとおりです。
「近代化とは、私たちがすでに持っている分析の改善、またはすでに使用されているテクノロジーへの機能や機能の追加です。 近代化は常に改善目標を達成するために行われます。 目標は、ユーザーコミュニティとIT /分析のリーダーシップの間のパートナーシップを通じて定義する必要があります。」
これらの目標は次のとおりです。
- 表面的な –よりセクシーな外観のコンテンツまたは改善されたユーザーエクスペリエンス。
- 機能的な –パフォーマンスの向上または機能と機能の追加
- 拡張 –組み込みエクスペリエンスを提供するか、プロジェクトとワークロードを追加します。
ビジネス分析分野での20年以上にわたって、私は何百もの企業や組織と協力して、インストール、アップグレード、構成、戦略的計画およびプロジェクトについて支援および助言を行ってきました。 遅れて従事するとき、近代化プロジェクトの間に現実の線量の担い手になることはしばしば私を苦しめます。 非常に多くの人が計画なしで、またはさらに悪いことに、計画があり、その計画の検証がない状態で始まります。 最悪の事態は、ITと分析の近代化をオールインワンの大規模プロジェクトとして組み合わせたものです。
期待し、克服するためのプレッシャー
- すべてがクラウドとSaaSでなければなりません –クラウドには多くの利点があり、まったく新しい戦略や投資にとって当然の選択です。 すべてをオンプレミスからクラウドに移行するのは、会社の戦略と「期日」を組み合わせたものであるため、悪い戦略であり、空白で運営されている悪いリーダーシップに起因します。 日付にサインアップする前に、メリットと影響が理解されていることを確認してください。
- すべてをシングルソーシング –はい、必要なものすべてを提供できる会社があります。 単一のソースベンダーがあなたに利益を売ることができますが、それらは本物ですか、それとも認識されていますか？ 分析スペースは大部分がオープンで異質であるため、最善を尽くすことができます。そのため、適切な選択を行ってください。
- 新しい製品の方が優れています –新しいイコールの方が車で機能する可能性がありますが、製品の進化でない限り、通常はソフトウェアでは機能しません。 長年の実社会での経験と歴史を持つベンダーは、追いつくのが遅いように見えますが、これには正当な理由があります。 これらのベンダーは、他のベンダーにはかなわない堅牢な製品を提供する傾向があり、その製品の使用が増えるにつれて、その製品の生涯価値ははるかに高くなります。 はい、多少の遅れはありますが、必ずしも交換が必要であることを示しているわけではありません。 多くの場合、分割線が明確であれば、複数のピースが存在する可能性があります。
- 巨大な結果を急ぐ –残念ながら、割り当てられた時間が正確になることはめったにないため、意味のある進歩と結果を示すために、マイルストーンと勝利を定義した小さな計画を立てることをお勧めします。
- それはすべてはるかに速くなります –これは大きな目標と願望ですが、常に現実であるとは限りません。 アーキテクチャの提供は大きな要因であり、統合がどれだけうまく行われているか、周囲の依存およびサポートサービスと機能のコロケーションも同様です。
- 今、未来を近代化することは私たちを証明します –オープナーで述べたように、イノベーションは飛んでいるので、これは進化し続ける領域です。 常に最新の状態を保ち、更新が計画されていることを確認してください。 更新後、活用または利用可能にする新しい機能を評価します。
- 近代化は単なる「アップグレード」であり、簡単になります –アップグレードではなく近代化。 つまり、アップグレード、更新、交換、および新しい機能と機能の活用を意味します。 最初にアップグレードしてから、新しい機能を活用します。
分析の近代化計画の準備
近代化の取り組みを行う前に、成功率を向上させるために共有するいくつかのことを行うことをお勧めします。
1.目標を決定します。
「簡単な消費とコンテンツ作成を可能にする美しい分析の高速でシームレスなソースを提供する」というような目標を持つことはできません。 これは、プロジェクトを承認するための素晴らしい目標ですが、危険と破滅に満ちた包括的な目標です…それは単に大きすぎます。 一度にXNUMXつのテクノロジーの変更に焦点を合わせて目標を作成し、望ましい結果を測定します。 多くの場合、近代化はXNUMXつずつ、経験ごとに行う必要があります。 これは、より小さなプロジェクトと目標を意味します。
これは、より多くの時間と全体的な労力を意味し、おそらくユーザーにとっては変更が多すぎることを意味すると人々は主張するでしょう。 私の経験では、はい、この計画は長く見えますが、とにかく実際にかかる時間をより反映しています。 ユーザーエクスペリエンスの変更の頻度については、意味のある変更の完全なセットが得られるまで結果を本番環境にプッシュしないことでこれを処理できます。 私が見た「一度にすべてを実行する」近代化計画は、予想よりも12〜18か月長く実行されますが、これは説明がはるかに困難です。 さらに悪いのは、計画を実行するチームにかかるプレッシャーと、途中の課題から生じる絶え間ない否定性です。 これらはまた、大きなピボットにつながり、飛躍的な動きをもたらします。
小さな変更に焦点を当てる最大の理由は、分析が途中で失敗した場合、問題のトラブルシューティングと解決がはるかに迅速かつ簡単になることです。 変数が少ないほど、問題の解決が速くなります。 私はこれが単純に聞こえることを知っていますが、私はモンスターの近代化の取り組みを行うことを決定した複数の会社と協力してきました。
- 分析プラットフォームがアップグレードされる予定でした
- クエリテクノロジーが更新されました
- 分析プラットフォームがクラウドに移行
- 認証方法がWebシングルサインオンプロバイダーに交換されました
- データベースベンダーが変更され、オンプレミスが所有および運用するモデルからSaaSソリューションに移行しました
物事がうまくいかなかったとき、彼らは実際の解決策にたどり着く前に、問題の原因を特定するために多くの時間と労力を費やしました。 結局、これらの「一度にすべてを行う」プロジェクトは、時間と予算を超えて実行され、部分的な目標の達成とプロジェクトを取り巻く否定性のために、さまざまな結果をもたらしました。 これらの多くは、最終的には「可能な限り最高の状態で稼働させる」プロジェクトになりました。
2.目標ごとに計画を立てます。
計画には、透明性、完全性、正確性のために、すべての利害関係者からの意見を含める必要があります。 ここでの私の例は、データベーステクノロジーの変更です。 一部のベンダーは他のベンダーとの互換性を提供しており、これは彼らが価値を生み出すまでの時間について話すときに販売に役立ちます。 各データベースベンダーはまた、既存企業よりもパフォーマンスが優れているという立場を推し進めようとします。 問題は、これらのステートメントが重複していないことです。 ベンダーの互換性を活用して既存のワークロードのパフォーマンスを向上させることで、あるデータベーステクノロジーから別のデータベーステクノロジーにワークロードが移動するのをまだ見ていません。
また、データベースベンダー/テクノロジーを変更すると、ほぼ確実に、さまざまなレベルのSQL互換性、公開されたデータベース関数、さまざまなデータ型が得られます。これらはすべて、最上位にある既存のアプリケーションに大きな打撃を与える可能性があります。 重要なのは、そのような大きな変更の予想される影響を調査および決定できる人々と計画を検証する必要があるということです。 専門家は、後で驚きを排除するために従事する必要があります。
3.計画を立てる.
すべての目標がからかわれているので、それらのいくつかは並行して実行できることがわかるかもしれません。 分析プラットフォームを使用する場合、さまざまなグループまたはビジネスユニットが、最新化されるデータベースなどのさまざまな基盤となるコンポーネントを使用しているため、これらを並行して実行できる場合があります。
4.すべての計画を分析的に調べてクリーンアップします.
これは非常に重要なステップであり、多くの人が省略しています。 私はあなたがあなたの分析に対してあなたが持っているどんな分析でも使うことをあなたに勧めます。 これは、時間とリソースを無駄にしないための鍵です。 無効になっているデータ、分析プラットフォームのどのコンテンツが使用されなくなったか、関連性がなくなったかを判断します。 私たちは皆、XNUMX回限りのタスクのために分析プロジェクトやコンテンツを作成しましたが、ほとんどの人はそれを削除したり、自分でクリーンアップしたりするのも嫌です。 です digital 誰かがそれを維持、アップグレード、または近代化する必要がある瞬間まで、ただ放置するだけの費用がかからないコンテンツ。
分析コンテンツの80％が死んでいる、使用されていない、新しいバージョンに置き換えられている、または文句なしに長い間壊れていることに気付くとショックを受けますか？ 最後にチェックしたのはいつですか？
何を検証する必要があり、何をクリーンアップまたはゴミ箱に移動する必要があるかを確認せずに、分析コンテンツの検証を必要とするプロジェクトを開始しないでください。 分析に対して使用する分析がない場合は、いくつかを前進させる方法を見つけてください。
5.近代化プロジェクトと個々の計画が全体的に完了していることを評価します.
悪い目標である「簡単な消費とコンテンツ作成を可能にする美しい分析の高速でシームレスなソースを提供すること」に戻り、それを高レベルから分解してみましょう。 メモリとディスクを処理するためのインフラストラクチャの変更、データベースのアップグレードまたは変更、SAMLやOpenIDConnectなどの最新のシングルサインオンプロバイダーテクノロジへの移行、および分析プラットフォームの更新またはアップグレードが行われる可能性があります。 これらはすべて良いことであり、近代化に役立ちますが、それを覚えておく必要があります エンドユーザーは利害関係者です。 それらのユーザーが何年も前と同じコンテンツを取得しているが、それよりも速い場合、満足度は最小限になる可能性があります。 美しいコンテンツは、新しいプロジェクトだけのものではなく、最大の消費者グループに配信する必要があります。 既存のコンテンツの最新化はめったに見られませんが、 最大の影響 ユーザーに。 これは、管理者や分析プラットフォームをサポートするチームの他のメンバーにとって特に重要です。 それらのエンドユーザーを満足させないことは、チームが提供しているものを回避するために他のツールが持ち込まれ、最終結果が悲惨なものになる可能性があります。 このトピックについては、数週間以内に次のブログで取り上げます。
6.最後のアドバイス.
頻繁にバックアップを取り、本番環境のみでモダナイゼーションプロジェクトを実行しないでください。 大規模で広範囲にわたる変更に対応するために、シミュレートされた実稼働環境を用意するように努力してください。 これもまた、生産の外部と内部で機能するものの間の変数と違いを最小限に抑えるのに役立ちます。
あなた自身の近代化の旅に頑張ってください！
あなた自身の近代化イニシアチブについて質問がありますか？ お問い合わせ あなたのニーズと私たちがどのように助けることができるかについて話し合うために！
