アリーナ・ダヴィドヴァ 氏 0:00:06.2: 

皆さん、こんにちは。お集まりいただきありがとうございます。Anaplan と共に歩んできた。S&OP ジャーニーの進展をお話しします。本題に入る前に、当社 Danfoss 社がどんな会社なのか、このステージに立つまでになった経緯をご紹介します。Danfoss は、業界をリードするテクノロジー パートナーです。本社はデンマークにあり社員数は約 4 万人です。製造拠点は、世界中に約 100 カ所ありすべての主要大陸をカバーしています。事業は 3 つのセグメントで構成されており私はその中の気候ソリューション部門に所属しています。ここで注目していただきたいのは、工場が 35 拠点あるという点です。さらに、その倍以上の配送センターがあり、工場が配送センターに供給するネットワークがあります。DC（配送センター）同士も相互に販売しネットワーク内で原材料や中間製品を融通しています。工場同士もニーズに応じて原材料や中間品を供給し合っています。このように Danfoss のネットワークは非常に複雑で多くの人が工場や配送を管理しています。こうした複雑さ、異なる関係者間のつながりを考えると、このネットワークのあらゆる部分における変更を可視化し、他の拠点の適切な構造に常に影響を与えることができる、S&OP プロセスの共通プランニングアプローチが求められていたことは非常に明確でした。

 

アリーナ・ダヴィドヴァ 氏 0:02:16.8: 

プランナーとして一番避けたいのはプランニングを立てて確認/承認まで済ませたのに翌日にはすべてが変わってしまうことです。そのために強固なツールと共通の手法が必要だと気づきました。こうして Danfoss の S&OP 変革が始まりました。バラバラなやり方から共通手法のアプローチへと進化しました。2016 年にこの取り組みが始まり2018 年には Anaplan とパイロット運用を開始しました。特定の拠点では、実運用を開始しました。その後、製品ラインや工場、DC が次々と参加し成熟度も上がっていきました。年次評価で成熟度を評価するようになりました。昨年はより優れたインターフェースとダッシュボードを備えたAnaplan 2.0 を導入しました。現在では、約 600 人が Anaplan を使って S&OP プランニングを行っています。さらに多くの人が情報を提供し日々のプランニングにデータを反映させています。これが私たちの現状です。では、全体像をご紹介したいと思います。当社では、ファイナンスではなく S&OP のために Anaplan を使っています。これを略して SIOP (Sales, Inventory and Operations Planning) と呼んでいます。「I（インベントリ）」を含めているのは特に年末期に在庫データが重要になるからです。

 

アリーナ・ダヴィドヴァ 氏 0:04:00.6: 

では、何をしているかを先にご説明したいと思います。毎週、ERP システムである SAP S/4 HANA から原材料マスターやトランザクション データを取得します。して Anaplan 上で需要プランニング、在庫プランニング、オペレーションを実施します。Anaplan には多数のモデル、ロジック、計算式や依存関係が組み込まれています。在庫サイクルの最後には安全在庫を ERP に戻し、S&OP に反映させます。容量の確認やバランス調整を行ったうえで予測も SAP に戻しています。これらの作業は様々なレベルで可能です。原材料、製品、部品などです。どのレベルで行うかは工場ごとの判断に委ねられています。重要なのはすべてが連携されていることです。需要プランニングにて増減の判断や将来に向けた安全在庫の調整などすべての判断は Anaplan 上で共有されています。その情報は ERP にも展開され購買や日々のプランニングに活用されます。

 

アリーナ・ダヴィドヴァ 氏 0:05:28.4: 

これが全体像ですが、もちろん多くの要素から成り立っています。それぞれの要素が連携/統合され同期して動く必要があります。今日お話しするのはその中の 1 つである「フットプリントの変化」です。マグナスさんにお手伝いいただきます。あなたは長年 Anaplan でS&OP をプランニングしてますよね。当社は 2 年先までのプランニングを実施しており、原材料マスターも把握しています。月次サイクルがあり、月のどの時点で何をすべきかを把握している担当者もいます。では、予想外の変化が起きたらどうでしょうか。現代のビジネスではよくあることです。例えば、スエズ運河でのトラブルや、テロの問題で流通設計を早急に見直さなければならなかったり、新工場の建設や新たな環境への移行もあります。そうした変化を支える手立てはあるのか?最小限の在庫で顧客に最適なルートを届けられるのか?についてご紹介ください。

 

マグナス・ホフリッツ 氏  0:06:34.6: 

お役に立てるかもしれません。表示しますね。こちらが工場の全体図です。黄色は週単位の需要を示しています。何がしたいですか?

 

アリーナ・ダヴィドヴァ 氏 0:06:58.9: 

最新技術を導入した新しい工場があるとしましょう。第 32 週の需要をそちらに移すのはどうでしょう?

 

マグナス・ホフリッツ 氏  0:07:12.0: 

第 32 週は…ここですね。中央あたりです。どのくらいの需要を移したいですか?全部ですか?

 

アリーナ・ダヴィドヴァ 氏 0:07:22.8: 

はい、すべて移しましょう。

 

マグナス・ホフリッツ 氏  0:07:23.6: 

全部ですね、了解です。では 100％ 移します。はい、完了しました。他にやりたいことはありますか?

 

アリーナ・ダヴィドヴァ 氏 0:07:35.1: 

第 32 週以降の予測が新工場にすべて割り当てられましたね。でも実際には最初の日からフル稼働はできません。段階的に立ち上げていく必要があります。オペレーターの訓練や設備のチェックも必要です。段階的に移行できますか?

 

マグナス・ホフリッツ 氏  0:07:56.6: 

なるほど、徐々に切り替えたいんですね。ではやってみましょう。生産を重複させながら移行する形にします。旧工場の生産を止めるのは少し後にして、新工場を少し早めにスタートします。こんな感じでどうですか?

 

アリーナ・ダヴィドヴァ 氏 0:08:10.8: 

いいですね。

 

マグナス・ホフリッツ 氏  0:08:16.7: 

よかったです。

 

アリーナ・ダヴィドヴァ 氏 0:08:17.9: 

さらに、すべてを一箇所に集めるのは不安です。工場が異なる大陸にあるので製造を旧工場に半分は残したいです。

 

マグナス・ホフリッツ 氏  0:08:36.4: 

問題ありません。50％ にしましょう。100％ のところを 50％ に変えればこのような感じになります。

 

アリーナ・ダヴィドヴァ 氏 0:08:49.9: 

すぐに変更でき、結果が即反映されるのは助かります。

 

マグナス・ホフリッツ 氏  0:08:55.4: 

そのとおりです。

 

アリーナ・ダヴィドヴァ 氏 0:08:58.5: 

では、これは一時的な変更の場合はどうですか?旧工場で改修を行う間だけ数か月だけ新工場を使いたいです。

 

マグナス・ホフリッツ 氏  0:09:06.3: 

一時的な割り当てですね。もちろん対応できます。年末の週、例えば第 48 週にすべての需要を旧工場に戻すようにしましょう。

 

アリーナ・ダヴィドヴァ 氏 0:09:20.8: 

ERP に展開する時も、その期間だけ新工場に割り当てられるということですか?

 

マグナス・ホフリッツ 氏  0:09:27.3: 

はい、今後のすべての需要は両工場のこの設定に沿って反映されます。

 

アリーナ・ダヴィドヴァ 氏 0:09:34.9: 

ありがとうございます。もう 1 つ質問があります。生産を移すときに、同じ機材を使う場合、旧工場で生産を停止し、機材を梱包/配送し、新工場で設置を行う必要があります。その間は生産できませんが。販売は続けたいです。この期間用に、旧工場で事前生産して。在庫で対応することは可能ですか?

 

マグナス・ホフリッツ 氏  0:10:05.2: 

まず順を追っていきましょう。旧工場の生産を少し早めに止めるということですね。例えば 26 日で停止するとしましょう。新工場での開始は第 32 週 となると、およそ 5 週間、生産が止まりますね。その間、どうしたいですか?

 

アリーナ・ダヴィドヴァ 氏 0:10:30.7: 

その期間の分を事前生産して。販売できるよう在庫を確保したいです。

 

マグナス・ホフリッツ 氏  0:10:38.3: 

なるほど、5 週間分の需要を、前倒しで生産ですね。処理を実行します。少々お待ちください。はい、できました!

 

アリーナ・ダヴィドヴァ 氏 0:10:54.8: 

何が表示されているのですか?

 

マグナス・ホフリッツ 氏  0:10:59.1: 

旧工場の予測データをもとに5 週間前倒しで生産をプランニングしました。これにより、設備の撤去や移設中でも顧客への納品に対応できる在庫が確保されます。

 

アリーナ・ダヴィドヴァ 氏 0:11:15.4: 

なるほど、グレーの部分が前倒し生産分ですね。これで、移設中も販売を継続できるわけですね。

 

マグナス・ホフリッツ 氏  0:11:27.9: 

そうですね。

 

アリーナ・ダヴィドヴァ 氏 0:00:06.2: 

これなら問題なさそうです、ありがとうございました。

 

マグナス・ホフリッツ 氏  0:11:28.9: 

ロール プレイ形式で流れをご説明しましたが、実際に 6 か月前に、アリーナさんとこのような会話をしました。ツールの使い方がイメージできたと思いますが、ここで実際のプロセスも少しご紹介したいと思います。どう構築したのかを知っていただくために設計から構築、テスト、リリースまでの 4 つのステップをご説明します。大きなソリューションの中の小さな機能の 1 つに当たります。最初のステップは「要件の収集」です。私は 7 名の S&OP マネージャーとサプライチェーン責任者にヒアリングしました。具体的なユースケースを集めプロセスの理解を深めることが目的です。次に、それらを標準文書として整理しました。業務プロセス、手順、フットプリント変更のタイムラインなどを文書化しました。要件を整理した段階で次にツールの設計に入りました。システム設計として、私が思いついた選択肢は 2 つありました。1 つはサプライチェーン内の連携を操作する方法です。需要の流れを変えるという前提で調整するのです。

 

マグナス・ホフリッツ 氏  0:13:05.6: 

もう 1 つの選択肢は需要を行きたい場所に直接誘導する方法でした。ご想像のとおり、どちらにもメリットとデメリットがありました。前者はユーザーからの入力が多く必要で将来のネットワーク設定も複雑でした。一方、後者はバックエンドの複雑さが増しますが、ユーザー側は直感的に操作しやすくなります。私は後者を選びました。ユーザーがすぐに使える設計であることを優先したかったからです。このようにしてシステム設計の方向性が決まりました。次はバックエンドです。ここにモデル構成やアーキテクチャの図があります。この機能が全体設計にどう組み込まれているかイメージを持っていただけると思います。これがバックエンドです。そしてフロントエンドではこの機能専用のページを作成しました。ユーザーはそこでプロジェクトを作成し設定を入力できます。デモでもお見せした操作に似ていますが、実際はもう少し機能があります。入力後に対象製品を割り当てて、どの製品を移行対象とするかを選びます。すべて 1 ページで完結し入力した瞬間にリアルタイムで反映されます。フロントエンドが完成したら次は UAT（ユーザー受入テスト）です。標準的なテスト スクリプトを用いて有資格ユーザーで確認を行いました。15 名ほどのユーザーと専用のテスト環境を用意しました。アリーナさんは、ここにいますね。

 

アリーナ・ダヴィドヴァ 氏 0:15:00.6: 

そうですね。

 

マグナス・ホフリッツ 氏  0:15:00.7: 

これで問題なかったですよね。つまり、共通の場があるということです。質問を投稿したり、意見を共有したり、デモ動画をアップしたりできる場所です。UAT が完了すればすぐに本番環境で稼働させることができます。とてもシンプルです。プロダクション環境に同期し社内のユーザー コミュニティに展開します。新機能のリリースを知らせ、トレーニング資料も更新します。これが小規模な開発プロセス例です。実際の使い心地はどうでしたか? ユーザーからのフィードバックは?

 

アリーナ・ダヴィドヴァ 氏 0:15:35.0: 

リリースされて配信された後ですが、S&OP マネージャーと詳細なセッションを実施し、その後すぐに活用を開始しました。現在では複数のプロジェクトが進行中です。原材料マスターが未更新でも需要の移動が可能です。週ごとの数量やコードが変わってもすでに対応できる体制になっています。事前に変化を想定して柔軟に対応できるようになっています。

 

マグナス・ホフリッツ 氏  0:16:08.6: 

小規模開発におけるデモのご紹介でした。ご質問があれば、ぜひお聞かせください。

 

[拍手] 

 

Audience 0:16:25.9: 

質問です。チームは 1 人体制ですか?

 

マグナス・ホフリッツ 氏  0:16:27.8: 

いえ、私たちのソリューションは、巨大なハニカム構造の一部にすぎません。モデル ビルダーが約 4.5 名、アーキテクトが 2 名います。モデルは非常に大規模で SKU は約 100 万件、500 ギガバイト規模です。これは小規模な機能ですが非常に実用的で重要です。だからこそ今回、皆さんにご紹介したかったのです。

 

アリーナ・ダヴィドヴァ 氏 0:17:09.6: 

この仕組みは複数の Excel やスプレッドシートを置き換え、すべてを一元管理できます。在庫や展開も含めて一元的に操作が可能です。質問者があちら側にいますね。すこし遠いですね。

 

Audience 0:17:25.5: 

マグナスさんに 1 つだけ、意思決定プロセスについて深掘りしたいです。他の製品と比較して、なぜ Anaplan を選んだのか教えてもらえますか?

 

マグナス・ホフリッツ 氏  0:17:36.7: 

想定外の話題ですが、少しだけお話ししますね。私たちがこの取り組みを始めた理由と背景です。確かに様々な選択肢がありました。当時 16 の異なる S&OP システムを1 つに統合したいと考えていました。すでに S&OP の変革を進めていたため IDT は当然の選択肢の 1 つでした。ただし他のツールも検討していました。求めていたのは、Danfoss の多様なビジネスに合わせてカスタマイズできるツールでした。小売、B2B、多様な業態に対応する必要がありました。顧客単位、製品単位、地域単位でのプランニングなど柔軟に対応できることが重要でした。結果として Anaplan を選んだ理由は自社仕様に合わせたモデル構築が可能だったからです。以上でしょうか? ご清聴ありがとうございました。