おめでとう。 あなたはいくつかのソフトウェアを実装することを決定し、それを成功させたいと考えています。 それはアジャイルか、ウォーターフォールか、リーンか、スクラムか、またはまったく別のものか。 プロジェクトの実装を成功させるには、それを実行するための独自の要件がありますが、
キックオフする前に考慮すべきことがたくさんあります。
ターゲットオペレーティングモデルは適切に定義されていますか?
新しいテクノロジーの実装を急ぐことには多くの落とし穴がありますが、システムが完成したときに全体像がどのように見えるかを考慮せずにシステムの展開/統合を開始することほど一般的なものはありません。 あまりにも多くのプロジェクトが終了しました
技術のいくつかの重要な部分が全体的なスキームに組み込まれていなかったためです。 今日、市場に出回っているすべてのフィンテックとディスラプターは、互いにシームレスに統合しようと努力しますが、完全な理解は必要ありません。
of の それらを接続したいのですが、どのような理由で、途中でターゲットオペレーティングモデルをやり直し、これまでに費やしたすべての労力とリソースを捨てなければならないことに簡単に気付くことができます. それは、飛行機を組み立てようとするようなものです。
飛ばしたり、運転中にタイヤを交換したり。 典型的な TOM には、クライアント対応スタッフが使用するカスタマー リレーションシップ マネジメント (CRM) タイプのシステムがあり、ワークフローとルール エンジンを組み込んだクライアント ライフサイクル管理システムに接続します。
必要なタスクを関係者にプッシュして、データ入力/ドキュメントのアップロード/検証と検証を完了させます。 レコード/ゴールデン コピーのソースとして扱われるマスター データ管理 (MDM) システムがあるかもしれませんが、多くの場合、これはサイロ化されています。
レコードを更新できるさまざまなシステムを備えた、複数の集約または統合されたデータ ストアのシステム。 組み込みまたは統合されたトランザクション監視サービスを備えたトランザクション/トレーディング/レンディング システムが存在する可能性があります。 データ/ドキュメント用のサードパーティ プロバイダが存在する場合があります
またはニュース/ネガティブニュース/上映目的。 これらのすべてまたは一部は、クラウド ベースまたはオンプレミス システムでもかまいません。 繰り返しになりますが、この 1 つの新しいテクノロジーが TOM 全体のどこに適合するかを検討しましたか。それは最終バージョンですか、それともあなたですか。
現在のセットアップに統合していますが、将来これを変更する予定です
現在のすべてのシステムについて、どれくらいの期間サポート/維持する予定ですか?
システムに X ドル / ユーロ / ポンドを費やしたからといって、敗北を認めて破棄するにはほど遠いという、サンク コストの誤謬として知られるよくある間違いがあります。 または、壊れていないので、修正する必要はありません。 それとも定着しすぎているのか
現在のシステムでは、それを取り外したり交換したりできます。 その場合は、気付かないうちにシングル ポイント障害が発生している可能性があります。 最新のテクノロジー ソリューションは柔軟性があり、変化に対応できるように構築する必要があります。 以前の合併/買収
または、システムの融合によりテクノロジーの統合が余儀なくされ、通常のプロセスは単にそれを機能させることです. これらは、何かを行う方法を再考し、より効率的な方法を模索する機会として扱われるべきです。 XNUMX番
これに対して、ほとんどの新しいテクノロジーは、レポート、ダッシュボード、ワークフロー、ケース管理ルール エンジン、構成スタジオなど、同様の製品/モジュール/機能を備えているか、備えていると主張しています。 これの目標は、可能な限り幅広い聴衆にアピールすることであり、
「Y が既にその能力を持っているのに、なぜ X を購入する必要があるのか?」と考える人もいます。 しかし、これを念頭に置いて、CRM をトランザクション監視システムに変えたいと本当に思いますか? または、アカウント システムを MDM のゲートウェイに接続しますか? または、プリンシパルとしての MDM
データエントリーポイント。 最終的に、電話番号が 12345678 のレコードが数千になることはわかっています。
スタッフ配置/役割
実装を成功させるためには、プロジェクトの両側で定義された役割を持つ必要があります。 あなたとベンダー。 それは明らかに予算、範囲、タイムラインによって異なります。 から 4 人のスタッフを必要とする 2 週間のクラウド ベースの実装がある場合があります。
ビジネス/製品アナリスト、開発者、対象分野の専門家、品質保証テスターで構成される 10 週間のアジャイル要件アプローチを伴う 12 週間のメジャー リリースの 2 フェーズである可能性があります。
各事業部門/地域/法域のマネージャーと、すべてを監督するプログラム マネージャー。 プロジェクトのスポンサーを投入すると、エンタープライズ ソフトウェアが高価になる理由が容易にわかります。 これは、スタッフのレベルを考慮する前でもあります
一致するように割り当てる必要があります。 このプロジェクトに携わるスタッフは、かなりの時間、日常業務から離れることになることを忘れないでください。 ベンダーのスタッフが経験豊富で、経験がないことを確認することが重要です。
あなたのプロジェクトの需要を満たすために最近雇われました。
もう 4 つの考慮事項は、パートナーシップ モデルです。 多くの確立されたベンダーには、認定パートナー、一部のブティック企業、およびビッグ XNUMX の一部があり、実装を支援するために起草することもできますが、価格もかかります.
データ移行
新しいソフトウェアを組み込む主要なテーマの XNUMX つは、データ アクセスおよび/またはデータ移行の検討です。 新しいシステムが必要に応じて現在のデータベースにクエリを実行する場合、いつアクセスできるようになるか、どのユーザーがどの権限を持っているか
アクセス権は読み取り専用ですか、それともユーザーは新しいレコードを編集または作成できますか? また、ユーザーが中央レコードを更新する場合、それらの変更を行うための優先順位はどのシステムですか? 別のユーザーが別のシステムで変更を試みた場合はどうなりますか?
あなたの新技術は現在それを編集していますか? これは、すべてのデータ編集リクエストがその新しいテクノロジーを経由する必要があるということですか? すべての新しいテクノロジーが同じ優先順位を要求するとどうなりますか? これらはアクティブな顧客記録システム専用です。
新しい統合単一システムの作成についてはどうですか? 初日からすべてのデータを移行するために、ビッグバン アプローチを採用する必要がありますか? リスクを想像してください。 レビューがスケジュールされている場合などの移行期間についてはどうでしょうか。1 つまたは複数のソースからプルしてレビューを実施します。
次に、クリーン レコードを新しい中央データベースにポストします。 そうすることで、代わりに 12 ～ 18 か月の期間にわたる移行が可能になります。 これは万能のアプローチではありません。 重複の処理を検討する前に、これですべてです。
インテグレーション
エコシステムに新しいテクノロジーを追加することを検討するときは、それが現在のセットアップとシームレスに機能することを確認する必要があります。 これには、最初は 2 つのオプションがあります。特定の問題を解決するための新しい追加、または既存のシステムの置き換えです。
またはシステムが整っています。 どちらの方法でも、アップストリームとダウンストリームの両方で使用するために必要な関連システムに確実にアクセスできるようにする必要があります。 また、廃止されるシステムへの既存のすべての配管を維持できることを確信する必要があります。
常に見過ごされがちな許可に関する質問もあります。 ユーザー アクセス制御: アクセス権を持つデータの新しいテクノロジに対してユーザーが持つ権限を管理すると同時に、管理者権限の要件がないことを保証します。
しかし、将来新しいテクノロジーを追加するとき、その時点ですべての歴史的なシステムのアクセス制御を改良する必要があるでしょうか? 上記と同様に、データの変更/更新の優先順位がどのテクノロジにあるのかを判断する必要があることを忘れないでください。 さもないと
システム A が今日変更を行い、システム B が明日それを元に戻し、システム A が翌日に再試行することをどのように確認しますか。
システム アクセス – Infosec ポリシー
リソースを提供し、関連するシステムへのアクセスをタイムリーに提供するために、関連するチームを社内で関与させましたか。 環境の許可やデータベースへのアクセスなどを要求する前に、最後の瞬間まで待つことを計画している場合は、
目標の日付が突然達成できないことに気付くかもしれません。
購入者 vs ユーザー
新しいテクノロジーのエンドユーザーは意思決定プロセスに関与していますか? 他のユーザーに代わって決定を下す意味はありません。最終的に、構築されているものが自分の目的に合わないと判断した場合。 ビジネスとの戦い
IT はあらゆる場所で常に発生しており、誰が決定権を持つかという点で前後に揺れています。 システムの設計は、多くの場合、すべての問題をすべてのユーザーに対して完全に解決することが期待されています。 100% 解決するためのテクノロジーのオーバーエンジニアリング
立派ですが、最終的にはリソースを大量に消費する取り組みです。 最初の目標は、過半数を解決し、配信が成功するまで待ってから、エッジ ケースを試行することです。 問題の最後の 20% または 10% は、取得の主な目的を妨げてはなりません。
テクノロジーが必要ですが、あまりにも多くの場合、すべてが消費されます。 自問する質問は、最初に決定的に必要なものは何かということであり、オプションをサブセットに限定することです。
そのため、プロジェクトの実装を成功させるために何を考慮すべきかを考えるとき、開始する前に、含める必要がある関連事項が他にもあることに気付く必要があります。 これらは、最初に選択するソフトウェアの決定にも影響します。
場所。 輝くものすべてが金ではありません。 選択しているものは、単一の予想される最終結果だけではなく、全体のすべての考慮事項に適していることを確認してください。
