---
id: "lib-2026-10-16-how-umios-ex-maruha-nichiro-automated-sales"
type: "library"
title: "How Umios (ex-Maruha Nichiro) automated sales planning"
title_original: "「年4200時間の入力」「経験と勘」からの脱却 旧マルハニチロは「販売計画」をどう自動化した？"
lang: "JA"
org: "@IT (ITmedia)"
source_type: "Practitioner post"
date: "2026-10-16"
week: "2026-W42"
url: "https://nosov.ai/library/lib-2026-10-16-how-umios-ex-maruha-nichiro-automated-sales/"
original_url: "https://atmarkit.itmedia.co.jp/ait/articles/2610/16/news033.html"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "@IT write-up of a case co-authored by AWS and Umios on replacing manual sales planning with Chronos-2 forecasts; concrete design and accuracy figures, but vendor-published, PoC-stage and with projected savings."
summary_basis: "full-text"
original_minutes: "5"
tags: ["business transformation", "demand forecasting", "enterprise case"]
---

# How Umios (ex-Maruha Nichiro) automated sales planning

Original title: 「年4200時間の入力」「経験と勘」からの脱却 旧マルハニチロは「販売計画」をどう自動化した？

Tier B (Useful, limited): @IT write-up of a case co-authored by AWS and Umios on replacing manual sales planning with Chronos-2 forecasts; concrete design and accuracy figures, but vendor-published, PoC-stage and with projected savings.

Summary based on the full text.

## In short

An @IT article (16 October 2026), based on an AWS blog co-written with Umios, the 146-year-old frozen-food maker that renamed itself from Maruha Nichiro in March 2026. Sales staff in every branch typed next months' sales plans by hand, an estimated 4,200 hours a year. The company replaced the forecast step with Amazon's Chronos-2 time-series foundation model while keeping branch planners as the final approvers, and fixed the data inputs alongside.

## Key numbers

- ~4,200 hours: annual manual input time for monthly sales plans across all branches of the food-service distribution division, now projected to be saved
- ~4.7 million cells: plan data held in the PPPlan sales-planning system
- 62.57% to 20%: WMAPE for seasonal products before and after adding an explicit Month feature
- 95%: forecast accuracy on standard products in the PoC, on an annual cumulative basis

## What it reports

- Three structural problems: inconsistent input (some branches used the system, some Excel, some had stopped), plans based on individual "experience and intuition", and a lead time that forces forecasting two to three months ahead.
- An earlier PoC on the in-house chat platform UmiChat (based on Claude Sonnet 4) had problems with reproducibility and system integration for one-shot LLM forecasts. Chronos-2 scored better on the same data.
- Fixes: an in-house input app with a nationwide common form and a monthly cut-off on the 20th; Chronos-2 returns P10, P50 and P90 forecasts as a "logical first draft" that planners check and correct over a 10-day window; forecasts update daily to use the latest actuals; a BI view shows forecast, plan and actuals with a divergence alert.
- Acceptance bar: 60-70% accuracy at monthly product, warehouse and sales-section level, aiming for 80-90% later with feature engineering. Standard products reached 95% on an annual cumulative basis.
- Seasonal products peaking in February to April had a WMAPE of 62.57%; adding a Month column cut it to 20%, and extending history from one to three years also helped.
- Data lessons: clearance sales (a 100-yen item sold at 20 yen) were removed from training because they reflect surplus stock, not demand. One frozen product changed its JAN code five times (2010, 2012, 2015, 2021, 2025), splitting its history.
- Next: an agent on Amazon Bedrock AgentCore to explain forecasts in chat inside UmiChat and suggest actions when divergence crosses a threshold.

## How they got it

PoC on standard products, compared against the earlier LLM approach on the same data. Serverless AWS setup (SageMaker JumpStart endpoint, Step Functions, EventBridge, S3) added around the existing database and BI tool.

## Limits

- The 4,200 hours is a projected saving at full rollout, not a measured result.
- Accuracy is reported for standard products in a PoC; "95% accuracy" on an annual cumulative basis is a lenient measure.
- Vendor-published case (AWS co-authored the source blog).

## Why it matters for companies

The design choice is the transferable part: the model produces a draft with a range, and the person who owned the plan still approves it, so the workflow does not change while the guesswork is removed. Most of the work was data discipline: a common input form, a cut-off date, removing clearance sales, linking product codes. It is also a clear case where a general chat LLM was the wrong tool and a purpose-built forecasting model did better.

## Key passages in translation

> 支社の計画策定担当者が最終確定するフローは維持し、AIは「ロジカルなたたき台」を提供する位置付けとした。

The flow in which branch planners make the final decision was kept, and the AI was positioned as providing a "logical first draft".

> 販売実績データは「売れた量」であって「本当の需要」ではない。

Sales records show "the quantity sold", not "the true demand".

> 大規模言語モデル（LLM）によるワンショット予測には再現性やシステムへの組み込みの面で課題があった。

One-shot forecasting with a large language model had problems with reproducibility and integration into systems.

Original: https://atmarkit.itmedia.co.jp/ait/articles/2610/16/news033.html