状況の面白さは、良いスタートが嘆かわしい結末につながるように思えます。 またはそうではない...多分反対に、悪いスタートは予期しない終了につながりますか？
私の話は、世界的な危機が私ができる限り多くの人に届いた年の2009年の冬に始まります。 会社がメインベンダーとの作業を緊急に自動化する必要が生じたとき。
2009年冬
従業員3人の会社の小さなIT部門は、奇跡を起こすことを任されていました。 会社のERPシステムを作成する必要があります。 そして奇跡が起こりました。 システムのメインコアは1か月も経たないうちに作成され、その後ドキュメントの作成を開始しました。
2009年夏
在庫会計システムは、膝の上には実装されていませんでした。いいえ、倉庫、ロジスティックデスクで作成されました。 忘れられない出来事、詳細が記載された箱はすでに印刷され、貨物を受け取るための書類が作成され、車は去りました。そして、パッケージに貼り付けるためにステッカーを印刷することがなぜできないのかと思います。
2009年秋
詳細は倉庫で押収され、貼り付けられ（数回）、サービスセンターに送信されます。
システムに戻るものはすべて消化することができず、Excelによって保存されます。
「ベンダーと連携するサービスを作成する必要があります」-次の目標は聞こえます。 興味深いことに、データはすでにIndo-excel-managerialパスを通過していることがわかります。
はい、これが本当のお金であることを忘れないでください。 移動のための特定の文書システムの腸での形成時に、現在の口座から引き落とされます。 もちろん、その安定性と正確性は、それを作成したすべての開発者によって損なわれます。
2009年冬
開発者として、ベンダーからセントラルオフィスへ、セントラルオフィスからサービスセンターへ、そしてベンダーとの結婚として部品を移動するサイクルを終了します。 これに先立ち、すべての詳細はあなたに来て、サービスセンターに残り、処分され、このデータはすべてそこにあります。 もちろんExcelで。
2010年冬
SOAPを介してベンダーと連携するためのサービスが完了し、動作し、データが到着します。 ただし 、インターネットが落ちた場合、その側からのデータは依然として消え、誰も知らないが、消えます。 ただし、すでに確立されているIndo-excel-managerアクセスを使用すると、3〜5日以内に受け取るべきものをいつでも確認できます。
2010年春
簿記は、これがいかにそうであるかに興味を持つようになりました-あるパターンで行っていた詳細が、今では別のパターンで行って、...理論上および秘密で、あなたはそれらの動きの全歴史を見ることができます。 誰がどれだけ受け取ったのか、帰らなければなりません。 この関心は、請求書、および詳細を送信するための他のドキュメントを作成するのがよいほど大きくなっています。
2010年夏
請求書を作成しました。 これで、ロジスティクス担当者は、箱を収集した後、一連のドキュメントを印刷できます。 ただし、倉庫管理者のみが署名できます。
サービスセンターへの供給を生成するプロセスを変更するための戦略的な決定が行われます。
2010年秋
サービスセンターの負債の長い手動分析の後、前払いなしでサービスセンターへの有料スペアパーツの配送を停止する決定が行われましたが、保証スペアパーツを含む貨物は古いスキームに従って作成する必要があります。 考えるべきことがあります。
2010年冬
機能は、セントラルオフィスに対するサービスセンターの負債を分析するために作成されます。 その後、数人のマネジャーが1年前の6ヶ月間の負債を処理します。 長く骨の折れる仕事は彼らの帰国から始まります。
2011年冬
マルチベンダーシステムへの移行を準備しています。
そのため、ERPシステムは2年以内に少数の開発者グループによって作成できます。 ネットワーク管理者（データベース）が存在しない場合でも、レガシーシステムの継続的なサポート。 メディアの空き領域が定期的に不足しています。 関連する開発の並行開発：
- 倉庫在庫
- スペアパーツの機器を分解する機能（プロジェクトは終了しました）
- サイトエンジニアを修理するための作業指示書の発行
もちろん、その機能は非常に控えめです。 認定はされませんが、会社の生活と同じように機能します。 彼女は奇妙な方法を繰り返します。
そのため、次に会社に行って「何か」を見たときに、それが最善の解決策になるかもしれません。
追伸 興味深い場合は、システムのコアの実装、データストレージへのアプローチ、売上高文書の作成（作成、会計、変更）を考慮して、このトピックを継続できます。