M.Video-Eldorado Group は、2021 年の初めに Hacking Retail 戦略を発表しました。今後 5 年間で、当社は、独自の市場の開発を含め、総売上高を 2 倍の 1 兆ルーブルに、品揃えを 3 倍にすることを計画しています。 「モノリシック」な IT システムでは、このような成長を短期間で実現することはできず、非標準の開発によりプロセス全体が遅くなります。マイクロサービスが役に立ちます。 SAP ERP の一部をどのように「切り落とした」のか、そしてその結果について説明します。
数年前に、M.Video と Eldorado のバック オフィスを統合するプロセスを完了しました。その結果、小売ネットワークの統合されたITインフラストラクチャは、3層構造を表し始めました.最初のレベルでは、統合されたバックオフィスであり、その主要な会計システムは「モノリシック」なSAP ERPです。
その上には、常に拡大しているマイクロサービス プラットフォームがあり、すべてのフロント システム (価格、プロモーション、製品、残高、顧客情報など) に重要なデータを提供し、フロント システムとバック システムの統合を提供します。 2 階にあるこのスキームには、各ブランドの 2 つの独立したフロント オフィスがあります。
一般に、このバンドルはビジネスの現在のニーズを満たしています。しかし、それらは絶えず成長しているため、私たちは常に準最適性を探しており、それを排除することでビジネス プロセスのパフォーマンスが向上し、ワークロードの増加に備えることができます。
真剣に準備します。M.Video-Eldorado は、商品の範囲を拡大し、新しいプロジェクトを立ち上げる大きな計画を立てています。供給量の予想される増加は、2 倍から 5 倍になるはずです。そしていつかではなく、1 年か 2 年以内に。
長時間の待機
できるだけ早く解消する必要のあるボトルネックの 1 つは、ロジスティック カレンダーを計算するためのアルゴリズムでした。もう少し詳しく説明しましょう。物流アクセシビリティの概念があります。これは、商品がポイント A からポイント B にいつ配達されるかを決定します。ロジスティック アクセシビリティ パラメータは、すべてのフロント オフィスで使用され、ビジネス アプリケーションなどからアクセスされます。 - これは、物流単位としての製品の主要なパラメータの 1 つです。
カレンダーには、両方のネットワークのサプライヤ、中央および地域の倉庫、および店舗間で商品を移動する可能性に関する完全な情報が含まれています。出荷が今日の予定の場合、今日のカレンダーが使用されます。しかし、明日はその関連性を失い、「明日」を適用する必要があります。
物流プロセスの作業の安定性を高めるために、計算は3日前に毎日実行されました。このソリューションは、導入のスピードが速いため、SAP ERP では長い間「松葉杖」として提供されてきました。このプロセスには 9 ～ 11 時間かかりました。より高い負荷でテストすると、システムは 24 時間でも計算に対処できないことがわかりました。量を大幅に増やして定性的に高い生産性を達成するには、このサービスをモノリスから取り除くことが重要でした...
現在の状況
SAP ERP の一部であるロジスティクス カレンダーを計算するためのアルゴリズムは、カスタマイズされたボックス ソリューションの形で SAP が提供する PL/SQL プロシージャのパッケージでした。その中の 3 つのカレンダーのそれぞれの計算は、各サプライ チェーンのすべての条件を考慮して、「ゼロから」実行されました。したがって、各段階での計算のほとんどは、単純に互いに重複していました。これが製品の操作の論理であり、技術的負債を完全になくすためのリソースがありませんでした。
さらに、このアルゴリズムは、完成したカレンダーに重複した「ゴミ」サプライ チェーンを残しました。これにより、データベースのサイズが増加しました。必要な 1,000 万のレコードの代わりに、データベースには 2,000 万から 3,000 万のレコードが含まれ、手動でのクリーニングが必要になります。
元のツールは、1 日でここまで最適な状態にはなりませんでした。これはかなり前に導入され、運用の全期間を通じて、企業顧客によって開始された数多くの改善が行われました。何年にもわたる段階的な変更の流れにより、さまざまな不正確さが発生し、その一部は仕様に完全に反映されていませんでした。
同時に、それは重要なビジネス ツールであり、そのパフォーマンスは小売ネットワーク内の数百の店舗の活動に依存していました。したがって、製品開発へのアプローチは非常に慎重かつ迅速でなければなりませんでした。
「モノリス」の一部をかじる
この分野での SAP ERP の生産性向上の可能性 (ちなみに、ERP サービスでは一般的ではありません) が使い果たされていることに気付いたので、マイクロサービスに目を向けました。 M.Video-Eldorado は、この方向性を数年間開発してきました。
100 を超えるマイクロサービスを実行する独自のマイクロサービス プラットフォームがあります。 ERP システムの元のモジュールと同じアルゴリズムに基づいて、多くのサービスを作成する必要がありました。計算の一般的なロジックは維持したいと考えましたが、同じプロセスを繰り返さないようにしました。
作業は主に 3 つの方向で行われました。まず、SAP アルゴリズムから不要な計算を削除して最適化する必要がありました。第二に、重複したサプライチェーンの出現を排除する必要があり、データベースに不要なレコードが蓄積されていました。第三に、ビジネス プロセスの最適化を複雑にする元のアルゴリズムの結果の不正確さを排除する必要がありました。
SAP ERP は会社の主要なバック システムの 1 つであり、すべてのフロント システムからデータを受信することを思い出してください。カレンダーの計算をマイクロサービスに転送する必要があるという事実にもかかわらず、個々の調達ステップ自体、商品の移動は依然として中央会計システムで作成されていました。
ロジスティクスカレンダを生成するために、SAP ERP はビジネスユーザーから受け取った設定を含む 20 以上のテーブルを提供します。マイクロサービス プラットフォームが計算を実行するのは、このデータに基づいています。 ERP 自体も、第 2 および第 3 の配信アームを作成するときに内部計算に使用します。したがって、単純にプロセス全体をモノリスから切り取って転送することは不可能でした。
プロセス図:
1 および 3 - SAP PI によるプロセスは、SAP ERP からカレンダーを計算するための設定を含むデータを受け取ります。
2 および 4 - ERP から受信したデータをデータベースに記録します。
5 - プロセスは、データベースに保存されているデータのバージョンのいずれかを使用します (デフォルトでは最新バージョン)。次に、このデータに基づいてカレンダーを計算し、ステージング テーブルに保存します。操作中、プロセスはオブジェクトに関する情報を要求します。
6 - データは、プロセスが SAP ERP から受信するのと同じ形式でステージング テーブルから本稼動テーブルに転送されます。
7 - カレンダー設定を含む古いデータをデータベースから削除します。
ツール、時間、リソース
私たちは数年間マイクロサービスを作成してきたので、開発ツールの選択に特に迷うことはありませんでした。 Javaの11と春ブーツのよく習得組み合わせ
2は、アクションに入った コードではありませんマジック、Javaのための唯一の標準的なもの- 。コレクション、インターフェースなど
のテーブルですべての操作が完全に実施されたように、我々が最初に新しいアルゴリズムを構築しましたRAM、およびデータベース内で SQL クエリを使用しない。
SAP ERP 運用チーム側では、カレンダー計算用のマイクロサービス プラットフォームにマスター データを転送するための準備が行われました。約40時間かかりました。
将来的には、彼らはプロジェクトをサポートするだけで済みました。もちろん、主な作業はプラットフォーム自体のエンジニアの肩にかかっていました。アルゴリズムのロジックは本質的に作り直されました。ERP からは、カレンダーを計算するためのマスター データと基本的なビジネス原則のみが取得されました。これにはさらに 150 時間かかりました。
一般に、プロジェクトの実施には約 6 か月かかりました。さまざまなアプローチに基づいた多数の自動テストに 2 か月を費やしました。新しい計器の試運転は約 1 か月間続きました。この期間中、私たちは新旧2種類のカレンダーを同時に計算し、結果を研究して比較しました.サービスが劣化していないことと計算が正しいことを確認することが非常に重要でした. その後、新しいツールを実稼働環境に移行することが決定されました。
結果
私たちは最終的に何を得ましたか？カレンダーは 1 回だけ計算されるようになりました。次に、日付の変更に関連する少し追加の計算の結果として、3 日間のそれぞれのインスタンスが取得されます。「松葉杖」アドオンがないため、データベースのボリュームは自動的に最適な状態に維持され、ERP システムの負荷が減少しました。
しかし、私たちが達成できた主な結果は、カレンダー生成時間を 9 ～ 11 時間から ... 10 分に短縮することです。今後の IT インフラストラクチャへの負荷の数倍の増加にはまだ改善が必要ですが、この技術的負債を勝ち取りました。