食品製造、出荷、販売管理

本社、工場の2拠点間での販売管理/生産管理システム

導入前

本社の受注・販売業務では、電話やFAXにて受けた注文を「短冊」と呼ばれる紙に手書きで記入し、この紙を工場にFAXするというやり方をとっていた。 パッケージの販売管理システムは導入されていたが、登録内容をリアルタイムで生産側である工場と共有することが難しかった。このために、受注はまず紙に手書きで工場にFAXしておき、余裕のあるときに販売管理システムに入力するというフローになっていた。販売管理システムは、どちらかというと請求書を作成 するための素材を登録する用途で使われており、工程の管理には利用できていなかった。

一方、工場では、本社からFAXで送られる情報を元に生産を行うことになる。必要となる商品と数量が、注文毎に五月雨式に来ることになるため、工場側ではまず大きな紙に情報を転記し、商品ごとに正の字を書いて必要数を確認していた。注文がある程度溜まったところで当日の生産計画を調整することになるが、全体の数量を確認するには正の字を見て、その中に大口のお得意様からの受注が入っているかどうかは短冊のFAXを手でめくるという行為が必要で、効率を上げることが難しかった。

また、工場では生産後に梱包、出荷を行う必要があり、これに伴って同梱する納品書、梱包係への指示書など、多数の書類を必要とした。さらに、顧客からの指定や地域により冷凍便/冷蔵便/普通便などの区別を行ったり、冷凍された商品は同じ箱でも入れられる量が変わるなど、各工程で必要となる技術が属人化しており、作業にはある意味職人技を必要とした。

ソリューションの開発

FileMaker Serverを導入し、本社と工場で同時に同じデータベースを参照できるように開発を行った。本社と工場の2拠点において、スプラッシュのスタッフが一定期間常駐して業務を理解し、徹底的なヒアリングを行った。
現状の問題点と必要事項を整理することで、データベース導入後のフローを提案する。さらにミーティングを重ね、利用現場ごとのニーズや都合が衝突しないようにフローの最適化を行った。また、データベースで行う部分と人力で行う部分のバランスについても慎重に検討した。

開発中、ポイントごとにプロトタイプをご確認いただき、開発者と利用者間で活発なディスカッションを行った。一見手間のかかるやり方に思えるが、こうすることで齟齬の発生による手戻りを最小限に抑え、またきめ細かな意見交換によって現場での利用価値を最大限に引き上げることができた。

導入後

本社の受注時に登録された受注情報は、そのまま工場でも参照でき、各商品の必要数がリアルタイムで把握できるようになった。また、繁忙期と通常期でしきい値を調整することで、受注量にしたがった生産計画をある程度自動で生成できるようになった。
納品書や梱包指示書などの必要書類についても、工場側であらためて入力することなく出力が可能となり、梱包内容の調整を行う場合もわずかな労力ですむようになった。
配送便の指定や冷凍/冷蔵の区別など、顧客ごとに対応が異なるものが数多く存在したが、各種マスタの整備を行うことで、受注入力担当者や梱包/発送作業担当者はほとんど意識せずに自動的に適切な対応がなされるようになった。

毎朝の商品数チェックや在庫の調整もデータベース上で管理され、「いつ」「なにが」どのように生産され、出荷可能な状態にあるかをリアルタイムで把握できるようになった。
各顧客の締日にあわせた請求書の発行も一括で自動的に行われ、必要に応じて請求内容の微調整も可能となった。また、蓄積された売上データを元に、各顧客の 売掛残の管理や、不採算商品等の分析もボタンひとつで可能になった。商品ごとや担当部署ごと、顧客ごと、地域ごとの売上実績や年間推移表、前年同月比なども自由に出力することができ、現場担当者だけではなく経営層や管理職のニーズにも対応することができた。