さまざまな企業での情報システムの実装とその後のメンテナンスに長年の経験があります。 ほとんどの場合、この経験は成功しましたが、ここではまず、この問題が失敗する原因について説明し、間違いの可能性について警告します。 私は自分自身の実装方法を意味します。これは繰り返し使用してきたもので、それらのほとんどを回避するのに役立ちます。
失敗の最初で最も重要な理由： 情報システムの誤った目標設定 。
これは、一般的なプロジェクトの主要な問題の1つです。 顧客は多くの場合、情報システムとは関係のない目標を選択するか、わずかに依存します。 例：売上の増加、大きな市場シェアの占有、企業経営の異なる文化の創造など。しかし、企業が需要の落ち込む商品を生産する場合、情報システムはどのように役立ちますか？ マーケティング部門はここで問題を解決する必要があります。 企業の文化を変える必要がある場合-これは人事管理とCEOの問題です。 しかし、情報システムにお金を与える価値があるという希望を抱く人もいます。そして、ビジネス組織に関連する問題は自分で解決するでしょう。 システムの「ベストワールドビジネスプラクティス」に基づいて繰り返しテストされ、構築された高価な外国製システムを「駆動」する売り手の約束は、この信念を強めるだけです。 しかし、実際には、非効率的な管理スタイルを持つ企業は、情報システムを使用した場合にのみ効果を発揮しません。 製品の需要が低下した場合でも、それは決して変化しません。 確かに、情報システムにより、その実装を含め、損失を迅速かつ正確に計算できます。
情報システムを実装するという目標を正しく設定することが、この実装の成功の鍵です。 情報の処理に関連する目標は正しい：ストレージ、データ取得、計算に関連するタスク、グループ化、分析。 システムを実装するとき、これはすべてより少ない時間を必要とします。 ただし、失敗したプロセスを加速すると、システムが存在しない場合よりも、会社にとってさらに不利な結果につながることを忘れないでください。
これは、顧客との交渉における最近の事例の1つです。 顧客は、製品構成システムを変更して、生産作業を合理化することを望んでいます。 彼によると、新しいシステムは利用可能な製品オプションの限られた選択のみを提供する必要があります。 そうすれば、生産部門と承認部門での作業が容易になり、標準ソリューションのセットが表示されます。 ただし、顧客には既にコンフィギュレーターがあります。 すぐに疑問が生じました：なぜ変わるのですか？ 答えは驚くべきものです。別のコンフィギュレーターが「正しく動作するようにします」、製品に必要なドキュメントを作成し、注文処理スキームを変更し、顧客と協力する文化を調整します。 マネージャーは問題が何であるかを理解していることがわかりますが、状況を変え、ビジネスプロセスを再編成する難しさをこの責任のない部署に移すために、彼らは自分の無力さに署名します。 原則として、そのようなプロジェクトは何年もクラッシュするか、引きずられます。
情報スペシャリストがビジネスプロセスを変更する方法を知っていると想定しても（ロジックに秩序があります）、彼らはまだ必要な管理リソースを持っていないため、期待される結果はまずソフトウェアに依存しません。 ここでは、結果と原因が明らかに混同されています。 ABC情報システムを備えたエンタープライズAがあるとします。 同社は安定して運営されており、噂はなく、混乱はなく、注文は時間通りに完了し、デバッグされたメカニズムの体系的な活動があります。 ABCシステムのおかげですべてが順調であると結論付けることができますが、これは100％ではありません。 もちろん、企業AにABCシステムが存在することはビジネスに貢献しますが、重要ではありません。 ある企業Bの経営者が、ABCシステムの実装後に、企業BもAと同じように機能することを期待して、ABCシステムを実装することに決めた場合、彼は驚くでしょう。 お金は使われますが、期待される効果は現れません。 企業Bでの作業方法は変わりません。
効果的な目標
繰り返しますが、情報システムの実装に効果があると考える目標は、既存のビジネスプロセスを加速したり、データ処理のために新しいビジネスプロセスを作成したりすることに関連しています。 特にこれらのプロセスに影響を与える権利がない限り、他の部門のタスクを情報システムに移さないでください。
情報システムの実装により、以前は受け入れられない期限のために存在する権利がなかったビジネスプロセスを実行できます。 さらに、新しいビジネスプロセスの開始は、システムの実装を成功させるための前提条件であると考えています。 明らかに、以前にファイルを使用して作業を実行し、現在はマシンを持っている場合、これは別のプロセスになります。 計画が不十分だった場合、その生産性のためにマシンはさらに大きな損失をもたらします。
したがって、目標を決定しましたが、今では参照条件を正しく作成することが残っています。
参照条件
これは、情報システムの実装における成功の2番目に重要な要素です。 効果的な目標は、まだ存在しないビジネスプロセスを加速することであることを思い出させてください。 顧客は一般的な用語でのみ、必要なものを理解しています。 作業の最初の段階ですでに詳細なマルチページTKを作成するのは良い選択肢と考えられています。 これは、特に請負業者にとって有効です。 顧客はすべてに署名しますが、請負業者が何をするかを完全には理解していません。 一方、作業指示書に記録されていない新しいフィールドまたはフォームごとに、請負業者は顧客に簡単に追加のお金を要求します。 その結果、顧客は、データが不完全または冗長なプロセスを受け取りますが、正式には契約は要件に厳密に従って実行されました。 顧客は不満を抱き、この請負業者に再度連絡することはありません。
不適切なTKに署名したのは顧客ではないことが判明しましたが、請負業者はまったく異なるものを開発して提案しました。彼は顧客が何を夢見ているかを推測しませんでした。 パラドックスに注目してください。 請負業者は自分でTKを作成しますが、同時に顧客が本当に欲しいものを推測する必要があります。 原則として、これは可能です（ショー「バトルオブサイキック」の参加者）。 詳細なTKを作成した経験があり、実装段階で約30％の変更が加えられました。 よくある話：プロジェクトに取り組む過程で、顧客は新しいアイデアを持っていたので、以前の決定を放棄して考慮に入れなければなりませんでした。 したがって、私は非常に詳細なTKの支持者ではありません。 それらには多くの時間がかかり、最終的には試運転と実装の段階で調整されます。 調整を行わないと、顧客との関係が損なわれる可能性があります。 応答で詳細なTKを参照しようとすると、「まあ、あなたは専門家です。あなた自身は事前にすべてを知っているべきです」と聞くでしょう。
期待される結果の説明を含む一般的な作業ブロックのみがTORに反映されるべきだと思います。 顧客が何を望み、請負業者が何をする必要があるのかを正確に説明してください。 TKの修正は、新しいツールが登場したときに、顧客が必然的に新しいビジネスプロセスを持つことになるため 、避けられません 。 以前のビジネスプロセスを保持しようとすると、プロジェクトが失敗します。 もちろん、古いものすべてが完全に削除されるわけではなく、情報システムを備えた企業の能力の向上に応じて調整されます。 TKが停止する必要がある最大値は、システムがサンプルとともに処理するドキュメントのリストです。 したがって、コンパイルされたTORは、一般的な要件に関しては変更されませんが、実際には、特定のフィールドおよびプロセスまで、実装プロセス中に明確化されます。 この場合、請負業者はいずれにせよ、予想される作業量を知っています。 プロジェクトを成功させるには、1〜2回の反復が必要です。一定量の作業が実施され、結果に応じて、顧客は請負業者に同意します。 TKの過度の詳細化に費やす可能性のある時間は、テスト操作の結果に応じてシステムの反復調整に使用する方がはるかに効率的です。
TKを準備するための別のオプションがあります：それは顧客の最終的な目標を宣言します。 そして、ここで、以前に書かれたテストとの矛盾にすぐに気付くことができます。 これは、情報システムが一部であるプロジェクトを起草する場合です。 統合された企業管理システムの実装経験があり、顧客が売上高を2倍に増やした場合に連絡先の主な金額が支払われました。 問題は、それはどうですか？ 答えは簡単です：顧客の目標は、掘削のビジネスプロセスの自動化と最適化、クライアントとの作業プロセスの高速化、契約に基づくコストの正確な計算、契約に参加するマネージャーへのボーナスの正確な計算、財務計画です。 これらすべてのタスクが解決されていないという事実に基づいて、私は契約書に署名しました。 残念ながら、1年で顧客の売上を100％増加させることはできませんでしたが、83％も良い結果となりました。 私の報酬は比例して支払われました。
作業を正常に完了するための次の重要な文書は、作業スケジュールです。
勤務スケジュール
スケジュール- 顧客と請負業者の両方が実行しなければならないアクションを説明する特定の作業の計画を含む文書。 スケジュールは、両当事者の作業の運用監視に必要です。 原則として、すべてのシステムとサブシステムを、それらのプロセス、ドキュメント、開発および実装されるレポートとともにリストします。 例：仕事の組織に関連する顧客の行動、コミュニケーションの確立、スタッフのトレーニングなど。 スケジュールの各ポイントで、価格と期間を付加することができます。これにより、請負業者と顧客の間で決済を行うことができます。 もちろん、仕事は並行して進めることができます。 ガントチャートなどを使用するのは良いことですが、必須ではありません。
システムの起動
システムの起動に先立って、システムの実行者が顧客の例をテストします。 肯定的な結果を受け取った後、システムの実際の実装と立ち上げに取り組みます。 実際のタスクを使用せずに、通常の顧客の参加なしに実験例でのみ試運転を行うと、目標を達成できません。 目標は、商業運用を開始するために対処する必要があるコメントを収集することです。 この段階を、顧客のパフォーマーを含む高度なテストと呼ぶ方が正しいでしょう。 実際のパイロット運用は、システムの導入後に開始され、ジョブの少なくとも50〜70％が参加します。
スタッフは訓練を受けており、ユーザー向けの簡単な指示が作成されています。 この段階は数分から数週間続くことがあります。 請負業者の従業員から受け取ったコメントが、資格のある顧客の開発者によって、できれば顧客の場所ですぐに削除された場合、極端なプログラミング方法はうまく機能します。 したがって、最大2週間で、システムの起動と適応に関連する問題の大部分を解決できます。 顧客の管理の厳しい要件を伴う大規模な立ち上げがなければ、試運転が何ヶ月も遅れる可能性があります。 厳格なリーダーシップ要件がない場合、人々は古い方法で働きます。 どんな革新でも、人々は誰かが彼らの生活を止めているという感覚を得るだけです。
試運転の段階の後、すぐに産業が続きます。 それらの違いは、解決しなければならないコメントの数、および重大な問題がない場合、どの操作が不可能になるかだけです。
その結果、システムの立ち上げと実装の次の段階が得られます。
- 実際の例で顧客従業員の関与を伴うテスト;
- すぐにトラブルシューティングを行う経験豊富な操作。
- 産業開発。
この方法は、さまざまな規模の企業で何度もテストされています。 ある時点で顧客の会社の従業員は、請負業者の従業員と同様に不快です。 しかし、幸いなことに、この不快感はすぐに消え、会社は問題を解決するための建設的なアプローチで体系的な作業に入ります。