ベンダーソフトウェアを変更するリスクをどのように伝えることができますか？

私が働いているところに大きな問題があり、その名前は「カスタマイズ」です。私たちは、ITと会計部門は、以前にその古い（10年以上）ベンダーのソフトウェアシステム持って愛さカスタマイズすることを。このソフトウェアは非常にバグが多くなり始めました。その後、私はカスタマイズの大部分の後に雇われました。

システムで見つかったほとんどすべての問題は、カスタマイズの直接的な結果です。私たちが変更するすべてのものは、ビジネスに不可欠な金融ソフトウェアを破壊するリスクがあります。しかし、会計部門は（私たちは常にそう！と言ったので）とのために少し尊敬があるように思われる変化を示唆し続けてインパクトのある方法の変更があるかもしれません。

一部の変更は問題を引き起こしません。ベンダーソフトウェアでフォームをカスタマイズすることができます（また、意図されています）。フォームフィールドを移動したり、削除したりできます。しかし、無害なカスタマイズのたびに、ストアドプロシージャやトリガーなどの変更を提案して、ベンダーアプリケーションのデータベース内のデータを操作します。

私は最近（ほとんど）、情報が完全に互換性がないため、あるベンダープログラムから別のベンダープログラムに顧客をインポートしようとするのをやめさせました。それがどのように解決されたかという私の問題は、システムがユーザー側で機能しなかったことがわかったためです。タスクは思ったより複雑だったので、あきらめました。ユーザー側のタスクがどれほど簡単であるかに関係なく、必要な操作は実行されるべきではありませんでした。

特にデータの有効性が危ぶまれている場合、このシステムの動作方法を変更するとリスクがあることをどのように伝えることができますか？私は新規（6か月）の雇用者であり、現状のままですが、財務データとサポート契約の有効性を危険にさらしています-ベンダーのサポートが「Xがカスタマイズされた」と聞いた場合私たちをサポートしたり、それが私たちのせいだと言ってください。

システムをカスタマイズすることのリスク/報酬は、あなたの会社があなたのスペースの他のビジネスとは異なる何かを提供できる競争上の優位性を提供することです。

私が携わった大規模な組織は、カスタマイズから競争上の優位性を引き出し、その考え方の中で、彼らはより効率的に物事を行い、より多くの機能を提供し、より多くのお金を稼ぎます。

これらの状況で私がコミュニケーションするという事実は、それがトレードオフであることです。システムにこれらの変更を加える際に、組織はシステムの独自の内部知識ベース/専門知識を開発していますが、それらは簡単に実行することはできません。この内部知識ベースは、これらの変更を追跡および管理できるように、より適切に保守および編成する必要があります。また、ベンダーサポート契約や、会社がこのプロセスに使用するIT資産のその他の側面を無効にする可能性があることも意味します。

私が話す最大のリスクは、企業がこのデータ管理哲学を採用したときのベンダーソフトウェアのバージョンアップグレードです。これは、何かが壊れる可能性が最も高いリスクの1つです。会社は、行われているトレードオフを理解する必要があり、誰もがそれらをサポートするために必要なプロセスに参加する必要があります。

文化については、類推や哲学を導入できますが、これらのシステムを変更する社内のビジネススペシャリストにさらに依存する環境を作成していることに気付くには、ビジネスの責任者が必要です。

自動車の例えでは、自動車にどのような変更が加えられているかを知る必要があるメカニックではなく、特別なメカニック、より多くのお金、または一定期間そのサービスの損失が発生する可能性があることを理解する必要があるオーナーです。オーナーを教育することがこの会話の鍵です。

オフィスの住人とコミュニケーションを取りますか？私は類推に行きます。

これらすべての変更が、典型的な4ドアの国内セダンをエキゾチックな外国車に変えていることを伝えます。チューンナップから粉砕された光、トランスミッションのオーバーホールまで、整備工場に持ち込むたびに、より高価になります。「私たちは部品を持っていません、特別な知識を持つディーラーだけがそれに触れることができます、我々は試みました、マニュアルはドイツ語です」。

あなたはそれを動かし続けることを担当するメカニックです。データベースはエンジンです。システム全体が車です。会計士は車を運転します。会計士が見逃したかわいいウサギは、新しい顧客の姓のウムラウト文字です。彼らが車を包んだ街灯柱は、車内にディスコボールを追加したいときに導入された重大なバグです。

他の人は、アナロジーや他の言語を使用してあなたの主要な質問に答える良い例を提供しました。

しかし、タスクの割り当てがどのようにあなたに届くかについてのあなたの明確なコメントに基づいて、私はそのような状況であなたに役立つ類似性があるかどうかはわかりません-人々が彼らが求めていることを誤解しているようには見えませんが、むしろ彼らは気にしません。私はそこにいた-私たちはおそらくそこにいた-そして、これらの状況では、警告するのではなく教えることを意図した用語でそれらをソファにするのではなく、問題について完全に明確にするために多大な努力をする傾向があります。

あなたができることに集中します。これは、データの整合性とベンダーサポート契約を危険にさらすカスタマイズを求める全員の心を独力で変えるのではなく、CTO（およびCFO）に​​直接話し、手元の問題については非常に明確です。

具体的には：

• CTOまたはCFO（またはそれを保持している人）にベンダーとのサービス契約を確認するよう依頼します。これは、契約に違反する可能性のあるタスクを実行するように求められているためです。タスク実行可能性レポートでそれを指摘できるようにしてください。彼らはあなたにそれを与えないかもしれませんが、それらの言葉を言うことはしばしば彼らのポジションの人々にあなたが真面目であり、状況が潜在的に真面目であることをよりよく理解させました。

• あなたがいる場合行う契約書のコピーを入手し、あなたのタスクの実行可能性報告書を書くとき明確な違反があった場合、その後、そこから直接引用。

• 契約のコピーを入手していない場合は、ベンダーとの関係に関して、変更によって会社がどのように悪い立場に置かれる可能性があるかについて、予約を非常に明確にしてください。

• ベンダーの合意のために問題が問題にならず、変更のカスケード効果のために「単純に」問題がある場合は、それが何を意味するのかを概説してください。 「そして、それはカードの家のように倒れます」という行を使用する前に箇条書きのポイント。

要するに、問題とその影響を非常に明確かつ簡潔に指摘するためにできる限りのことをしてください。既に意思決定者の前に実行可能性レポートを作成する機会があることは良いことです。「これは悪いことだと理解していると言って署名する必要があります。これはお勧めしませんし、この影響について責任を負いません」と言うための構造または管理サポート（またはエトス）がありません。悪い決断」（ベンダーであり、クライアントである場合のように）が、会社とその資産の最大の利益になるものを検討していることを示す多くのことを紙に書くことができます。

ストアドプロシージャとトリガーを実装するよう指示されている場合は、ビジネスプロセスに大きな問題があります。

あなたの最大の課題は、ユーザーをここに導き、彼らの考え方を変えることです。彼らはあなたに問題や要件を提供する必要があります。たとえば、ここからここに移動するデータが必要です。

最小のリスク/最大の利益でソリューションを実装しているのはあなたである必要があり、将来の開発問題を防ぐのに役立つ方法でこれを行うことができるのはあなたです。

ユーザーのサインオフまたは要件の形でいくつかの制御を行い、提供された開発のサインオフも役立ちます。ユーザーが求めているものに対して何らかの責任/説明責任をとる必要がある場合、ユーザーはそれについてもう少し考えるかもしれません。

あなたは、あなたの選択がビジネス要件のリスクの高い実装か全くないかのどちらかであることを暗示しているようです。それはめったにその黒と白ではありません。会計士がストアドプロシージャを直接求めているとは信じられませんが、もしそうであれば、求めているのではなく、意味を伝える必要があります。ビジネス要件が何であるかを確認し、それを実装する最もリスクの少ない方法を見つけます。

ベンダーが、ユーザーが必要とする要件を安全に実装するために必要なフックを提供していない場合、その問題はユーザーではなくベンダーにあります。

基本的にソフトウェアを開発しているので、開発方法論が必要です。変更はどのように文書化されますか？テスト済み？QAに展開しましたか？運用環境に展開しますか？等。もしあなたが方法論とそれに関連する費用を考え始めたら、彼らは理解し始めると思います。おそらくコストは十分に正当化されており、車が街灯柱に巻き付かないように手順を実装する必要があります。