9 Lamoda Warehouse Automationラップ

2つの赤の広場と5階の高さの倉庫は、年中無休で、年中無休（24時間年中無休）です（休みは1月1日のみです）。 毎日300人以上のオペレーターが交代し、8,000,000を超える商品を保管およびサービスしています。 彼らは世界中の商品を扱っており、ロシア、ウクライナ、ベラルーシ、カザフスタンの4か国からユーザーの注文を収集しています。 このような規模では、ビジネスには完璧な自動化が必要です。



カットの下で、ウェアハウスの開発と自動化のチームリーダーである私、Pasha Finkelsteinは、優れた開発チームと非常に具体的なビジネスタスクをアタッチすると、オープンソースソリューションが成長できることを説明します。

基本的なロジック

倉庫の3つの主なプロセス：商品の受け取り、保管、出荷。 倉庫の簡略化されたサイクルは、一次識別、品質管理、配置、注文の選択と予約、検索、仕分け、梱包、配送サービスへの転送のようになります。 顧客が製品を返品すると、このサイクルが繰り返されます。 これらのプロセスに参加する各物理エンティティには、たとえばトラック、商品、キャビネットセル、小包、梱包材、コンテナなど、独自の情報表現があります。 商品のステータスのすべての重要な移動と変更は会計システムに変換され、倉庫内の商品に対する絶対にすべてのアクションがログに記録されます。



WMS（倉庫管理システム）は、サプライヤの商品が入ったトラックが倉庫に到着してから商品が顧客に出荷されるまで、倉庫内の各製品のライフサイクルを制御します。

ファッション自動化の詳細

当社はファッションとライフスタイルの分野で働いており、倉庫で特定のタスクを引き起こします：製品は壊れやすい（メガネ、時計）、非標準サイズ（ウィンターブーツまたはジュエリー）、プレミアム（特別なパッケージ）-またはその他の特定の特性を持つことができます倉庫で考慮する必要があります。 したがって、保管場所での手作業の使用を完全に放棄することは不可能です。







他のすべてのプロセスは自動化されています-商品の受け取り、出荷エリアへの移動、仕分け、梱包、出荷の準備。 これらの各プロセスには、特別な機器と運用プロセスが必要です。 マジックは、これらのすべてのプロセスが「結合」し、システムのおかげで一緒に機能し始めると発生します。



倉庫自動化のあらゆる監視-オペレーターのエラー、最適でないプロセスなどに寄与するインターフェースであること -これは、出荷の遅延、複雑な全体のダウンタイム、大きな損失です。 さらに、ミスが発生するたびに、ネガティブなカスタマーエクスペリエンスが生まれます。 したがって、倉庫が時計のように機能することが重要です。

オープンソースと独自の開発への道

最初の段階では、外部倉庫を使用しました。 ボリュームの増加に伴い、運用プロセスを完全に制御し、これらのプロセスを頻繁に変更する必要があることを理解し始めたため、自社の倉庫と開発に移行することにしました。

その後私たちが直面した主な問題は、すべての詳細における運用プロセスの精緻化でした。 従業員がどこにどのように行くか、何回スキャンするかなど。 そして、これらのプロセスでは既に、WMSを展開する必要がありました。WMSは、運用活動を管理し、定期的な運用を自動化します。

始めるために、彼らはJavaでオープンソースソリューションを採用し、特に適切な基盤が既にあるため、独自の開発チームを編成することを決定しました。 機能を強化し、システムのコアを取りました。レガシーとファットクライアントを取り除き、リファクタリングを実行し、オペレーティングプロセスをサポートする新しいサービスを開発しました。

自動化ステージ

主な変更は、プロセス自体の再構築とともに「波」によって実行されました。

これまでに、彼は近代化の9つの段階を経てきましたが、これにこだわるつもりはありません。

• 最初と2番目の段階では、注文の出荷プロセスを自動化しました。コンベア、商品の仕分けロジック、パレットによる注文の自動仕分けを追加しました。
  
  
• 3番目と4番目の段階では、受け入れプロセスに焦点を当てました。さまざまなタイプと保管ゾーンごとに、入荷する商品の流れを分離する方法を学びました。
  
  
• 5番目のフェーズでは、フロア間に自動エレベータが追加されました。これが、保管エリアでの作業の始まりです。
  
  
• 第6フェーズは、受付ゾーンと出荷ゾーンを閉じて、すべての自動化をループしたときに最も重要でした。
  
  
• 7番目と8番目のフェーズでは、受け入れゾーンのプロセスに変更を加え、新しいゾーン、エレベーター、コンベヤーを追加しました。既存の自動化をスケーリングしました。
  
  
• 第9フェーズでは、倉庫に新しい建物を追加し、既存の自動化システムと統合しました。
  
  

実装

コアテクノロジー：Java、Postgres、Wildfly、Redis、ActiveMQ。



WMSはJava 8で記述されています。しかし、それほど前のことではありませんが、Java 11への移行を妨げる最後のモジュールを修正し、近い将来に更新する予定です。



倉庫に直接設置されたサーバーラックは、WMS用に予約されています。 これにより、電気やインターネットがオフになっていても、WMSが機能するという自信が得られます。 影響を受けるのは、アカウンティングシステムへのメッセージに遅延が生じることだけです。 WildFlyはアプリケーションサーバーとして使用されますが、まだ最新バージョンではありません。 後者への移行も計画中です。 移動のためにすべてがすでに書かれていますが、機能テストと負荷テストをまだ実行できていません。新しい年の前には、負荷が比較的高くなっています。 実績のあるActiveMQも使用されます。









PostgreSQLに保存するデータ。 私たちのシステムの主な本質は明らかに製品です。 倉庫の従業員は、同じバーコードを50回スキャンするなど、作業を簡素化するための回避策を考え出すことがあります。製品自体は、スキャンせずに、詳細、ジーンズ、Tシャツに入らずに、手で単に投げられるため、特定のユニットを識別するラベルを入力しましたインフラストラクチャでサポートします。 これらのユニットに関する情報は、2テラバイトのPostgreSQLデータベースに保存されます。



そこのほとんどの場所は商品でさえ占められていませんが、倉庫作業員の行動の監査によって占められています。 ビジネスに不可欠なシステムであるため、ウェアハウスは、システムに何かが現れたり消えたりした理由を知る必要があります-追跡不可能な変更を許可することはできません。 現在、データベースのこの部分をMongoDBの別のエンティティに取り込むことを考えています。



倉庫スタッフのワークステーションは、シンWebクライアントです。 自動化の開始時のどこかで、これはすべてファットクライアントの原則に基づいて機能し、特にインターフェイスの変更を含む大規模なリリースでは特定の問題が発生しました。 これと、ダウンタイムを設定しないとリリースできないという事実-早朝、夜勤が終わる週に2回までしかデプロイできなかったため、便利なスケジュールとは言えません。 これで、WMSをWebに移行しました。年末までに、太ったクライアントを完全に放棄し、ユーザーインターフェイスの変更を大幅に簡素化します。 いずれかの段階で追加されたWebおよびクラスタリングにより、リリースの頻度と時間に関する制限がなくなります。ユーザーは、何か問題が発生した場合にのみリリースについて学習します。







倉庫には興味深い「エキゾチック」なものがあります。 たとえば、 Technoradarで言及されているHaskellには、アイテム選別機を視覚化するためのバックエンドが記述されています（これは、1つのパッケージから商品をまとめて組み立てオペ​​レーターに渡すことができるマシンです）。 関数型スタイルで便利に解決される純粋に計算上の問題があります。 当然、大規模なプロジェクトにHaskellを使用する人はいません。



Technoradarについての記事で言及したウェアハウスのもう1つの要素は、各製品の正しいアクションシーケンスを「監視」する自己記述型のステートマシンです。 システム全体と同様に、単純な一連の制約から繰り返し開発されました。 今では非常に便利なもので、システムに深く統合されています。 近い将来、それをオープンソースにしたいと思っています-おそらく私たちだけでなく役に立つでしょう。

オートメーション機器

設備なしの自動化！ 倉庫全体がコンベアのネットワーク全体に絡み合っています。



上記の品目分類機は出荷段階で機能し、特定の注文のために在庫から収集された数万個の商品をレイアウトできます。 かつて、ソーターは、必要な商品を集めるために倉庫の周りをトロリーで移動する必要性からオペレーターを救いました。 注文は分割され、各オペレーターは自分のフロアからのみ商品を収集し（移動にかかる時間を節約します）、選別機は異なるフロアからの商品が自動的に正しい注文になるようにします。 運用プロセスを4倍に変更することで、注文の組み立てが加速され、エラーの数が大幅に削減されました。



すべての自動化機器は、パートナーによって提供されます。 特定のユニットを管理するために、WMSの隣のサーバーラックにある独自のシステムがあります。 システム間では、統合はかなり高レベルのプロトコルで構成されます-SOAPを介して通信します。 WMS内の運用プロセスから、たとえば、商品が入ったコンテナをポイントAからポイントBに移動する必要がある場合、システムに切り替えます。つまり、 システムの観点から見ると、実際の内部の複雑さにもかかわらず、この自動化はすべて非常にシンプルに見えます。



もちろん、この見かけの単純さはすぐには機能しませんでした。 自動化の最初の段階では、技術の「相互研削」がありました。 コンベアが文字通り商品を燃やした-コンベアベルトの速度が速すぎると、商品を「噛み」、燃え尽きてしまい、他の注文の組み立てがブロックされました。 おそらく、最初のフェーズを開始した自動化の開始時に最も困難なストーリーが発生しました。 昨日、倉庫は完全に手動でしたが、今日、スイッチを切り替えた後、倉庫は自動になります。 しかし、何も機能しませんでした。システムの統合エラーにより、互いのメッセージが誤って解釈され、数日間の倉庫のダウンタイムと数百万の損失が発生しました。



現在、パートナーは当社の倉庫にいます。新しい自動化のラウンドに関しては、機器の手配を計画しており、新しいブロックのテストを支援しています。

チームとスクラムバン

このシステム全体の開発は、現在12人のチームで行われています。 近代化のピークの最後の段階の1つで、個別に自動化されたプロセスを1つの全体に結合する場合、最大20人の開発者のみが参加しました（この段階には132人月が必要で、1,500を超えるコミットが含まれていました）。 しかし、大規模な変換が終了すると、一部の人々はGoまたはPythonを学ぶことに決め、他の開発チームに切り替えました。



チームには、製品の機能とITからのプロジェクト（平均で5〜6人のPMが1人）を組み合わせる「クラシック」プロジェクトマネージャーがいます。 彼の仕事には、主な顧客であるディレクターと運用プロセス開発部門に代表される倉庫とのコミュニケーションが含まれます。 私たちの側では、技術的な近代化-正しいスタック、更新などの選択についてより懸念しています。 -そして、倉庫のスタッフはプロセスの最適化を考えています。



時々、私たち自身がフィールドの研究開発に時間を割きます。 文字通りの意味で、私たちは倉庫に行き、シニアシフトと、通常のオペレーターと通信し、彼らが抱えている問題、作業するのに便利で不便なことを特定します。 つまり、ユーザーエクスペリエンスの調査を実施します。



たとえば、このアプローチのおかげで、商品の受け入れを行う従業員の職場のインターフェースが変わりました。 当初は、テキストの説明ではなく、多くのフィールド、ボタン、略語を備えた企業向けの複雑なインターフェイスでした。 しかし、私たちはプロセスとデザインを最適化して、メインのGoogle検索ページにより似たものにしようとしました。それほど美しくはありませんが、非常に機能的です。 インターフェースが単純であり、オペレーターが使用できるオプション、クリックする場所、スキャンする対象が少ないほど、エラー（およびそれらの修正に必要な時間）が少なくなります。

そして、詳細の最適化に関する蓄積された知識は、最も予期せぬ瞬間に私たちを追い越します：一度私たちのチームが施設にいれば、ある瞬間、ほとんどすべての参加者がレジの一連の行動を見ました。 約40秒後、同僚が一般的な考えを表明しました：「あまり最適ではありませんが、単純化できます。」

チーム内の役割間の関係は非常に古典的ですが、開発方法論にはスクラムバンを選択しました。



「入力」データは標準ではありませんでしたが、方法論で多くの実験を行いました。 たとえば、かなりまれなリリースがありました。 上記の1週間に2回のリリースという制限はプロセスの一部に影響を及ぼしましたが、実際にはデプロイの頻度ははるかに少なく、平均して2週間に1回です。 さらに、倉庫の自動化ハードウェアがありました。これは、きれいな滝のために外部企業によって開発されており、すべての変更は2年前にすべての必要な文書とともにスケジュールされます。 しかし、私たちは彼らの例をたどることができませんでした。定期的にシステムにいくつかの変更を加える必要があり、顧客にそれぞれのタスクについて詳細なタスクを書かせることは無意味でした。



だから、スクラムバンはすべての人を幸せにする妥協案です。 反復プロセスを使用しますが、スプリントはリリースです。 1か月に1回、お客様と面談し、リリース計画を立てます。何週、何週目に展開するかを話し合います。 スプリント内に、かんばんが実装されます-タスクのバックログ、進捗など。 確かに、このプロセスは徐々に変化しています。たとえば、かんばんボードはありません。 ある開発者がタスクを完了すると、次のリリースの計画と開発者の能力に従って、プールから次の開発者が与えられます。



このアプローチが気に入っています。 反復内で必要な柔軟性を提供し、特定のコミットが実装される日付の予測可能性をビジネス顧客に提供します。 そして、この方法論が私たちにとってそれほど重要ではありません。 主なことは、すべてが機能することです。

他のみんなとは違います-インベントリと監視を例として使用します

運用プロセスの開発では、業界のニーズから始めたため、かなりの数の個別の機能があります。



良い例は在庫です。 法律によれば、年に1回倉庫で実施する必要がありますが、当社のビジネス要件により、在庫のより厳密な監視が決定されます。 まず、ウェブサイト上で商品の入手可能性に関する関連情報を反映したいと考えています。次に、B2Bパートナーとファッションブランドは同じ関連情報を必要としています。 そのため、在庫は、複数の建物からなる5階建ての複合施設全体で、1日365日、1日365日棚上げされます。 また、このプロセスはWMSによって完全にサポートされています。そのようなソリューションを実装することは困難です。



現在、在庫は次の更新の処理中であり、このプロセスの効率を高めています。







独自の開発のもう1つの例は、監視です。 Webクライアントを介して実装され、非常に興味深いメトリックを表示および追跡できます。 さらに、これらのメトリックの視覚的表現は私たちにとって重要です。 実際、監視は単純なスケジュールで描かれた倉庫であり、すべてがうまく機能する場所と問題が観察される場所（特定のオペレーターまで）を明確に確認します。 最も重要なことは、この観点から、これらの問題が発生する理由を理解できることです。

KPI倉庫労働者とRedis

新しい技術の導入、更新、リファクタリング-それはすべて素晴らしいです。 しかし、WMSは実際のビジネスで機能するため、ここではこれらの問題だけでなく、解決する必要があります。 私たちの仕事の一部は、内部の「ハッカー」からの保護です。これは、タスクをバイパスしてKPIを実行するための新しい方法を発明する、リソースに富んだ倉庫従業員です。



たとえば、ユーザーが複数のワークステーションから同時にシステムにログインするのを防ぎ、セッションタイムアウトを実装するために、Redisをスタックに追加することを余儀なくされました。 実際、倉庫作業員は、同じログインで作業し、KPIを超えた場合にボーナスを受け取るほうが、自分の生産性を上げるよりもはるかに収益性が高いことに気付きました。



ビジネス上の問題を解決するにはシステムのさまざまな場所での変更が必要であったため、技術的な観点から非常に興味深い課題でした。



倉庫のスタッフからの驚きはそこで終わりませんでした。 セッションのリリースのほぼ直後に、PostgreSQLはクラッシュし始めました。 数日間、基地の予期せぬ劣化の理由を調査しましたが、この問題が再び機知に富むことがわかりました。 一人の女の子はしばしば喫煙に行きました。 彼女が職場を離れたとき、彼女はセッションからノックアウトされ、再びログインするために、シニアシフトを見つけて彼のバッジをスキャンする必要がありました。 倉庫内をさまようことを減らし、カートの1つからバーコードを引き裂き、スキャナーボタンをテープで固定し、このバーコードを常にスキャンするように設定しました。 そして、バーコードが800単位の商品が入っているカートからのものでない場合、これは長い間気付かれないことがありました。 各スキャンで、商品を検証するために巨大なSQLクエリが生成され、そのような「内部DDoS」でデータベースが「殺され」ました。 単位時間あたりのスキャン数とカート内の商品数の制限に注意する必要がありました。



そのような物語はすでにかなり多くあり、私たちは常に新しい物語に直面しています。 この場合、システムは毎回新しい条件に適応する必要があります。 このような状況では、管理方法だけに自分を制限することはできません。一度起こったことを非常にうまく繰り返すことができます。

次はどこへ行くの？

プロセスの最適化と倉庫の自動化は、完了することは不可能のようです。 それは会社で5年間続き、上で述べたように、ステージ9の後でも停止することはありません。 同社は引き続きB2CおよびB2Bで事業を拡大しているため、近い将来、別の大きなプロジェクトを計画しています。別の倉庫を開くには、既存のシステムを大規模に書き直すか、新しい場所で同様のシステムを最初から作成する必要があります。 そして、これは、ビジネス、物理的施設、運用プロセス、技術的ソリューションの接合部における新たな興味深い課題です。