顧客の世界が変わりました-これをどのように処理しますか？

少し前、私たちは、SQL Serverをバックエンドとして使用して、顧客の古いメインフレームシステムを新しいイントラネットASP.NETソリューションで置き換えるプロジェクトを任されました。これの一部は、ビジネスのリエンジニアリングでもありました。基本的に、システムを変更するとき、ビジネスをよりよく行うにはどうすればよいかを考えていました。

したがって、最初のタスクは、論理データモデルと物理データモデルを組み合わせて実行することでした。顧客はこれらの議論に参加しており、完全にサインオフしていました。次のフェーズは、各モジュールの設計と構築を実際に行うことでした。さて、長い話を簡単に言うと、プログラミングは完了しており、システムの並列テストに取り掛かっています。これまでのほとんどのモジュールで問題はありません。

私たちには1つのシステムがあります。ビジネスユーザーにアプリケーションとレポートのみを表示する場合は、すべて問題ありません。新しい統合ワークフローと連携し、以前の手動プロセスを自動化し、仕様どおりに機能します。移行されたレガシーデータについては、並行テストでいくつかの問題が明らかになりました。レガシーシステムのビルダーは、新しいスキーマとビジネスプロセスを理解するのに非常に苦労しています。したがって、レガシーデータを取得して新しいスキーマに入れる方法を理解するのに非常に苦労しています。このため、彼らはビジネスユーザーと利害関係者の会議を呼び出し、新しいシステムは古いシステムが提供したデータを提供しない（実際にはそうである場合）-これは新しいシステムの見た目を悪くします。

これは控えめに言ってもイライラします。新しいシステムはうまく機能し、必要なすべての機能を提供します。ITスタッフが新しいテーブルに古いデータを入力できない場合は、ビジネスユーザーは新しい機能に満足しています。

これを処理する方法についての提案を求めています。いくつかの政治的動きのために、新しい「アーキテクト」はシステムがどのように機能するかを理解しておらず、ITスタッフが要求している変更の影響を十分に理解できません。ITスタッフはシステムにいくつかの根本的な変更を望んでいます。これは本質的に不要であり、実際には悪い設計ですが、彼らは顧客です。

何かご意見は？

あなたのチームは彼らのためにデータ変換を行う必要があります。あなたは本当にそもそも彼らのためにそれをすべきだったのです。

私は、常に高価なプラットフォームの移行の数とベンダに関与してきた、常にすべてのテストを行って、すべての移行スクリプトを書いて、レガシーシステムを理解する責任があり、独自のデータ変換チームを持っており、一般的に必ずそのすべてを作りますそれがすることになっていることを行います。

一部の企業には、自分でできる優秀なITスタッフがいる場合があります。他の人はそれを自分でできると主張するかもしれませんが、実際にはできません。後者の場合、落ち着くのに十分なほど謙虚である必要がありますが、経営陣が内部チームが十分な仕事をしていないと判断した場合にステップアップする準備もする必要があります。

これは、あなたのシステムとあなたの実装。あなたとあなただけがそれが成功することを確認する責任があります。お客様が自分でこれの一部を実行できると期待しないでください。彼らが自分でこの部分を行うことを絶対的に主張する場合にのみ、そのオプションを検討する必要があります。その場合、あなたはあなたの尻をカバーする必要があります-彼らが自分でこれを行うことを選択した場合、彼らは責任があると言っている契約に何かがあるはずですその結果のため。

彼らは必要に応じてチームにベビーシッターをするためにあなたにお金を払うことができます、そして彼らが望むなら最初からやり直すためにあなたにお金を払うことができます。特に、期間限定または定額の契約をしている場合、この状況は死です。

ポイントは、あなたが言うように、彼らは顧客であり、それは彼らがあなたのために働かないことを意味します。実際、あなたが私のような皮肉屋なら、彼らの一部は彼らの仕事の安全を守るためにあなたに対して積極的に取り組んでいるのではないかと疑うかもしれません。いずれかの一部を行うために顧客に頼ってあなた実装することは間違いです。

手動でデータ変換を行うために最低賃金のデータ入力スレーブをいくつか雇う必要がある場合は、それを行ってください。結果をあなたの手に戻すための何か。

彼らは手形を支払うものなので、結局のところ、それが最善の解決策ではなく、後退するものであっても、彼らが求めているものを彼らに与えなければなりません。

しかし、おそらくメインフレームを使用していた人々がポイントを持っていることを考慮する必要があります。私の妻は銀行で働いていました。そこで彼女はメインフレームシステムを使用して、何百もの異なるタイプのコードを使用してさまざまな金融取引を入力しました。それは本質的に独自のミニ言語でした。銀行が数百万ドルを費やしてGUIベースのシステムを実装し、複雑さと関連する手順を大幅に削減したとき、彼らは後に生産性が急増し、決して後戻りしないことを発見しました。

問題は、メインフレームシステムは不必要に複雑で学習曲線が高かった一方で、キーボードですばやく入力するだけで1時間に数百のトランザクションを入力できるようになったため、GUIシステムよりもはるかに高速でした。それはユーザーベースによる大量の拒否につながり、プロジェクトは完全な失敗として廃棄されました。生産性が回復しました。

道徳は、顧客の懸念を完全に却下しないことです。真剣に検討し、提供しているソリューションがすべての利害関係者のニーズを満たしているかどうかを自問してください。

新しいシステムは古いシステムが提供したデータを提供しない（実際に提供する場合）。

あなたはこれを非常に真剣に受け止めるべきです。

次に：

1）レガシー担当者と協力して、懸念事項をすべて解決するよう管理を保証します。

2）彼らが言っていることが欠けていること、そしてなぜそれが必要なのかを完全に理解するようにしてください。これを保証するためにレガシーの人と協力してください。次に問題を再現し、「はい、それが私たちの懸念です」と彼らに言わせます。

懸念事項に同意する場合：

3）次に、ソリューションを提案し、レガシーチームにソリューションの入力\検証を取得します。

4）是正措置を進めます。

あなたがレガシーの人たちと完全に同意せず、彼らが懸念が無効であると信じている場合：

3）Legacy Guysが正しいと言ったのと同じ言語を使用して、経営陣の懸念を表明します。そして、あなたがそれに気を配るべきかどうかを経営陣に決定させてください。

「レガシーガイはXXXを恐れています。YYYが原因で問題が発生するかどうかはわかりません。懸念事項は正しいのですか？」

私は大きなことをお勧めします-パニック窒息メール、彼らの管理だけでなく関係者全員を襲ってください。短く、要点を絞ってください。
2点：

1）会議/電話で懸念事項に対応します（時間を提案します）

2）追加の変更の手間と費用がかからないため、システムには完全な信頼があります。

あなたは彼らの懸念のリストを持っているように聞こえます、そしてあなたは会議のポイン​​トバイポイントでそれらを降りることができます。あなたはただパニックを止めて、彼らを少し冷やして、それから彼らに真実を打つだけです。古いデータから新しいデータへのマッピングを支援することもできます。彼らがまだ変化を要求するなら...まあそれは彼らのお金です。

まず、ITセクションはあなたのインターフェースである可能性がありますが、実際の顧客はITセクションではなく、ITセクションが機能するビジネスであることを指摘しておきます。ビジネスを傷つけてITをなだめるために何かをすることは、良いサービスとは言えません。

非公式にITに腰を下ろしてください。それらをドーナツを購入します。生徒の役割を教師に取り、「私たちのソフトウェア設計の何が問題になっていますか？」彼らが言っていることと彼らが言っていないことの両方を聞いてください。当初の仕様では見落としていた点や、過去の問題点に懸念がある場合があります。再び、彼らは何か新しいことへの恐怖のために反応しているかもしれません。しかし、要点は、あなたが彼らの異議を親密に知っている場合、あなたは前向きな結果をもたらし、彼らの異議に答えるためにより良い立場にあるということです。

問題はレガシーシステムから新しいシステムへのデータ移行にあると述べました。ITセクションでデータの移行に問題がある場合は、迅速かつクリーンに行うための小さなツールを構築することを検討します。

古いデータの新しいシステムへの移行をサポートするには、お客様のITスタッフに相談してください。新しいデータ形式を理解しているあなたの会社の誰かは、物理的にそこに行って、IT担当者が移行を行うのを助けるべきです。

そうすれば、新しいシステムについてIT担当者に教えることができ、データが正しく移行され、実装がよりスムーズになります。