主に売掛金ビジネスモデルによって推進されている企業にとって、中核的なビジネス機能の 1 つは注文の入力、追跡、記録です。これに優れた企業は、インフラストラクチャの制約に遭遇することなく組織を拡大し、利益を増やすことができます。注文処理が煩雑で、エラーが発生しやすく、または一貫性がない場合、企業は直接コストと生産性の低下によって財務的に苦しみます。
私の会社、マイヤーズ インターネットでは、顧客ベースの構築、マイヤーズへの継続的なサービスの提供、顧客の問題が発生した際の解決の支援を中心にビジネスの優先事項を展開しています。企業は、注文入力と履行サイクルのさまざまな側面を処理するために、さまざまなシステムを使用しています。これらのシステムは相互に統合されておらず、すべての注文が正しく処理されていることを保証するメカニズムもありません。
マイヤーズ注文追跡システム (MOTS)
他の多くの組織と同様に、Myers は成長を通じて同じプロセスとシステムを維持しながら、中小企業から中規模の企業に成長しました。これらのプロセスのほとんどが確立されていたとき、すべての取引は電子メール、紙の記録、サイト訪問を通じて手動で行われていました。 5、6 年前、Myers のエンジニアは、Allaire の Cold Fusion と Microsoft SQL Server データベースを使用して、MOTS (Myers Order Tracking System) と呼ばれる注文処理を追跡するシステムを構築し、販売部門とアカウント管理部門が注文を管理できるようにしました。サポート、エンジニアリング、設計、情報システム、および会計部門によって入力され、実装されます。このシステムは重要な前進ですが、依然として多くの手動ステップが残されており、他のビジネス システムと統合されていません。
同時期に、顧客や営業担当者がマイヤーズのウェブサイトからオンラインで商品を注文できるシステムも構築されました。このシステムは、新しい Web サイトを作成し、提供された Web サイト パッケージの合計インストール費用と経常費用を計算できます。その後、さまざまな部門に電子メールが送信され、部門は MOTS に注文を入力し、アカウント管理システムで請求情報を作成できます。
建築上の障壁
このタイプのアーキテクチャには、いくつかのシステム問題があります。マイヤーズ社では、より顕著な問題の 1 つに、注文追跡を開始するために必要な手動データ入力と、この手動プロセスの結果として発生するエラーが含まれていました。もう 1 つの問題は、社内の注文入力、注文追跡、請求システムの間の切断、注文の紛失、情報の欠落、およびそれらが引き起こすエラーです。
まれにのみ発生するもう 1 つの問題は、MOTS システム自体に本質的に欠陥があることです。 MOTS の記述方法により、部門割り当て情報がまったくない、または欠落している注文を入力する可能性があります。これが起こると、最終的にはシステム内で順序が失われます。注文が失われると、正確かつタイムリーな会計を達成することが難しくなります。
ビジネスが成長するにつれて、アーキテクチャの欠陥がますます明らかになり、顧客と注文の数が増加するにつれて、注文の紛失や誤入力が頻繁に発生し、その結果、会社の収益が失われることになりました。その影響は測定が困難です。さらに、手動で入力されたデータの量により、遅延や処理の非効率が生じていました。
収益への影響が増大し、導入組織内の効率が低下したため、すべてを結び付けて効率を高め、エラー率を減らすには代替システムが必要であることが明らかになりました。旧システムを以下に示します。
図 1: 古いシステム アーキテクチャ
この図は、手動でのデータ入力が必要なすべての領域を示しています。これらのシステムはどれも統合されていないため、データの損失や歪みが発生する可能性が非常に高くなります。大局的なニーズがすぐに明らかになりました。注文システムは実装追跡システムに直接リンクする必要があります。このシステムには、注文が処理されずにシステムから流出することを防ぐためのセキュリティが必要です。正確な請求と正しい注文履行を保証するには、正確性が必要です。システムは内部コストを最小限に抑える必要があります。したがって、それを実現するには、システムを迅速に作成する必要がありますが、そのシステムが完全に機能する必要があります。
優れた注文入力および追跡システムはコストの削減に役立ちますが、それ自体が収益を生み出すわけではありません。
構造の奥深く
スキーマ設計を開始する前に、対処する必要がある基本的なアーキテクチャの問題がいくつかあります。最初の基本的な技術要件は、追加のコーディングなしでシステムを構成できる必要があることです。これは基本的に、作業を解釈/処理コードにハードコーディングするのではなく、データベースに埋め込む必要があることを意味します。次に、データベースには、注文入力インターフェイスの主要な (そして変更可能な) 側面を表現し、処理を実装できる十分な情報が含まれている必要があります。
上記の問題を解決しようとする過程で、システムは注文入力と注文追跡という 2 つの部分に徐々に適応し、この 2 つの間に明確に定義されたリンクを提供しました。注文入力システムは、正確な製品コード、割引、価格条件を使用して注文を表現する方法を知っている必要があります。注文処理システムでは、各注文を処理して記録するために、さまざまな種類のタスク、関連ジョブ、およびさまざまな部門を追跡する方法を知る必要があります。最後に、注文は定期的かつ予測可能なベースで実装ジョブに変換される必要があります。現在の新システムの構成を次の図に示します。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
