1Cのサイトのフルタイム統合を実装しようとする試みの30％から50％が失敗に終わります。 これは私の同僚が私に言ったことです、私のビジネスプランの何かは75％です。 つまり、4つのうち3つの場合-ファイルで何かをひねり、1つで-一般的にレッカー車または蘇生を呼び出します。 そして、なぜそうなるのでしょうか...
...現代の国内制御システムのトップメーカーは、全会一致で1Cと統合できると宣言しています。 当然、これはほとんどの場合、一般的な構成に当てはまります。すべてを予測することはできません。 はい、そしてマーケティングでは、「簡単だ！」と言うようになります。 おそらく決して死ぬことのないスローガン。
クライアントエグゼキューターの観点から統合プロセスを検討してください。 売却シナリオは、マネージャーのいくつかの厄介な動きのために、実際の地獄に変わる可能性があります。
だから、私たちは苦い経験を知り、私たちのことを共有します
先行販売フェーズ：
ダイアログ分析：マネージャーはすでにすりおろしたカラチであり、適切な質問をします。 しかし、先行販売段階では、そのような詳細は原則として顧客には知られていないため、それらを理解するのは長くて退屈です。 そのような質問をしない請負業者を選ぶ方が簡単です。 プロジェクトマネージャーが統合を次の段階に移行しようとすると、プレセールフェーズがよりスムーズに進みます。
しかし実際には、システムの起動後、1Cの製品カタログの構造とサイト上の構造が根本的に異なることが判明した場合、これは大きな問題につながる可能性があります。 誰かが1Cを追加しているという情報は、クライアントが1Cバージョンの変更を計画しているという事実だけでなく、非常に警戒すべき信号です。
原則として、これにより、フルタイムの統合では不十分です。技術仕様の承認フェーズ：
ダイアログ分析：残念ながら、アンロードまたは1Cへのアクセスを提供できないことがよくある問題です。 作業の同じ段階で、顧客プログラマーとのやり取りを開始することをお勧めします（あらゆる種類の驚きはかなり可能です）。 時にはそれが最も安価で最も現実的なオプションです。
お客様とプログラマーとの交渉を手配し、プログラマーがダウンロードへのアクセスを許可するか、要件に応じてダウンロードと設定を提供することに100％同意することを確認します。
書面で手配する。開発段階：
ダイアログ分析：ほとんど保証されたファイル。 プログラマはディレクトリ構造を設計する必要がありますが、データベースからのアンロードが根本的に異なる場合は、事前に考慮する必要があります。 おそらく他のすべてが保存されたかもしれませんが、...
プロジェクト完了フェーズ：
状況分析：まあ、すべてが起こった。 ここで、プロジェクトマネージャーは、彼に従属せず、雇わなかったリモートプログラマーを「操縦」しようとします。 それはすべて、プログラマーがクライアント側でどのような自己重要性を持っているかに依存します...そしてボーをさせないでください、それは> 9000になります:-)
プロジェクト受け入れフェーズ：
そして-イベントのさらなる発展：
ダイアログ分析：顧客のプログラマーにプレッシャーをかけると、仕様を理解していないか、試みたが成功しなかったか、または彼がすでに気の抜けたコードまたは何らかの「普遍的な」形式を既にロードしていたことがわかります。 。 クライアントが彼の1Cニックネーム（時間給）を支払うと、特別な錫が始まります。1Cニックネームは、あなたの「不合理な」要件（または「私たちのベース」の一意性）のために、彼の側で働くには1週間かかると主張します。
一週間で：
ダイアログ分析：簡潔にするために、PMの最も強い動きのみを示します。 実際、ずっと長くセックスをすることができます。 課税することは可能ですが、予算と期限に間に合うことは間違いありません。 クライアントは、責任を負わ
なければなりません（契約では、
アンロードが必要な形式で提供されることを正式に規定してい
ます ）が、PMの目標はプロジェクトを立ち上げることであり、「有罪」を証明することではないため、これは重要ではありません。
主な
ことは 、
「あなたは専門家です、あなたは予見すべきでした」のような会話に入る
ことではありません
。 あなたは予見し、オープンリスクとの統合を継続することに決めました。 そして
、残念ながら
リスクは働いた。原則として、スタジオプログラマー側から2〜3人日で
価格が上昇し 、プロジェクトマネージャーとクライアント側からさらに8〜16時間の神経質な交渉が行われます。 実際には、これは価格の違いを考慮します-フルタイム統合の場合はN、非標準の場合はMMM-。
神経細胞は復元されません。
主なリスクに応じた合計、ほぼこの調整：
| リスク/状況 | 結果 | 対抗 |
|---|
| 事前販売段階で荷降ろしが要求されます。 | - クライアントは簡単に誰かを探します。
- 先行販売に時間がかかりすぎ、プロジェクトは失敗します。
| - 統合を別の段階に進めます。
- 最良の場合と最悪の場合に「分岐」を提供します。
- 考えられるリスクについて顧客に通知します。
|
| ToRのコンパイルの段階では、アンロードは提供されませんでした。 | - 誤って設計されたディレクトリ構造。
- 期限と予算を満たしていない。
| - アンロードを要求します。
- 別のステージに統合します。
- 起こりうるリスクについて書面で顧客に通知します。
|
| 統合は別の段階で行われます。 | | |
| 1Cはサードパーティの開発者によって変更され、古いバージョンまたは不十分な構造のカタログを持っています。 | - フルタイムの統合を実行できない。
- 顧客プログラマーとの長い交渉、時間の損失。
| - 署名された要件の遵守を主張します。
- クライアント側で自分でアンロードを設定します。
|
| クライアント側で社内で1C設定を行う。 | - 予想外の複雑さと、非定型的な構成で起こりうる問題。 プロジェクトに「潜入」するリスク。
- サイトを維持するために負荷がかかるリスクは、1Cの無料相談または1Cで「あなたの前にない」不具合を修正することです。
| - 署名された荷下ろし要件の遵守を主張します。
- 1Cの設定を信頼できる第三者に委託すること（その場合にはすべての請求が行われます）。 候補者は顧客と合意する必要があります。
|
| スタジオは、プロトコルの遵守を主張しています。 | - クライアントの能力不足による関係の破綻のリスクは、要件を個別に実装することです。
- プロジェクトの締め切りを遅らせる。
| - 1Cとの統合を別のフェーズに進めます。
- 1C設定を自分で実行します。
- クライアントが提供できる形式でデータを受信します。
|
| 顧客側のプログラマーは管理できません。 | | - 顧客、彼のプログラマー、スタジオとの毎日の三者通話を整理します。 より高いレベルで問題を解決します（エスカレーション）。
|
| スタジオは、プロトコルの要件を任意の形式に変更することに同意しました。 | - カタログ構造の変更、「無料」での統合のための面倒なプログラミング、期限。
| - 統合のための抵当は大金です。
- 得られた経験を思い出してください。
|