『中小食品工場における生産管理システム導入時の課題』

1.はじめに

「ウチはまだそのレベルじゃありませんから」

　年商が5億円から50億円規模の中小食品工場で生産管理システムの導入状況について尋ねると、多くの場合このような答えが返ってくる。「ITに詳しい人材がいない」「予算が無い」「過去に購入したものの稼働できなかった」などの理由からそう考えるのであろう。しかし、大企業よりも中小企業の方が導入しやすく得られるメリットも大きい、というのが筆者の考えだ。

　一般的な生産管理システムは、生産計画・手配計画、製造管理、購買管理、在庫管理、原価管理などのプログラム群によって構成される。各プログラムは工場内の部署や担当者の職務分掌に対応した機能を持ち、単独でも動作するように設計されている。そして、実際の業務が複数部署や複数の担当者が相互にコミュニケーションを取りながら進められるように、生産管理システムにおける各プログラムも連携して操作されるが、関与者が増えるほど調整が増え運用が難しくなっていく。前段で中小企業の方が導入しやすい、と述べた理由はここにある。組織構造の観点からは、分業化の度合いが低い中小企業の方が生産管理システムを適用しやすい、と言えるのである。本稿では、中小食品工場が生産管理システムを導入する際に注意すべき点について、マスタ整備と個別機能(生産計画・手配計画、製造管理、購買管理)の面から述べる。在庫管理や原価管理については文字数の都合もあり、別の機会に述べさせていただきたい。

2．マスタ整備

　生産管理システムにおいて特に重要なマスタはa.品目マスタ（品目とは、商品、製品、中間品、原材料、包装資材などの総称）、b.レシピマスタ、c.工程手順マスタの３つである。マスタが正しくなければシステムは機能しないが、マスタ整備はシステムを動かすための手段に過ぎない。労力をかけるべき領域ではなく、可能な限り時間と工数を減らす工夫が必要であろう。極力シンプルなマスタにすることが、生産管理システム導入に成功するキーである。

2-1 品目マスタ

　商品や製品のマスタは大抵どこの工場でも整備されているが、中間品、原材料、包装資材については未整備の工場が多い。新たにマスタを整備し直す場合は、以下に述べる3つの点について留意していただきたい。

①コード、意味、カテゴリ

まずコードには意味を極力持たせるべきではない。コードに意味を持たせるとは、例えば大分類「製品1」中分類「弁当01」小分類「和食01」連番「0001」と定義して品目コードを「101010001」などと決めていくやり方である。コード体系を知っている者にはコードを見ただけでカテゴリが理解できる、探しやすいメリットがある反面、知らない者にとっては桁数が増えて扱いづらくなるデメリットが生じる。ちょっとした敷居だが、時間の経過とともにシステム関連業務が属人化していく芽を孕んでおり、マネジメントの観点からも回避すべきである。品目の探しやすさはコードに求めるのではなく、項目属性が引き受けることで容易に解決できる。

さらに、現時点では使いやすいカテゴリであっても、将来は実態と齟齬が生じ使いにくくなることが多い。大きな変化（事業分野の絞り込み、新事業進出、企業買収など）がなくとも、特定カテゴリ内でコードが足りなくなる、複数のカテゴリにまたがるコンセプトの商品が生まれる、などは容易に起こり得る。結局、分類とは特定の視点からの切り分け方法にすぎないのであるから、全社共通で長期間に渡って利用され続ける品目コードの採番ルールとしては不適切なのである。

②原材料のコード

品目マスタ整備の際に考慮すべき2番目は、原材料のコードについてである。レシピ構成上の上位品目（例えば製品）によって原産地や栽培方法などの属性が規定される原料は、コードを分けた方が良い。例えば「国産野菜だけをつかった野菜ジュース」と「（輸入野菜も使った普通の）野菜ジュース」の両方を製造している工場の場合は、国内人参と輸入人参はコードを別にとる。さらに「千葉県産にこだわったキャロットジュース」を作っている工場ならば、千葉県産人参は別コードになろう。コードを分けなくてもモノを区別することは、項目属性（原産地、栽培方法、グレード、ロット、場所、消費期限など）を併用すれば可能であるが、現場の負荷は確実に増大する。「人参」＋「国産」と２項目入力するよりも、「国産人参」と１項目で済ませる方がシンプルで良い。

③中間品のコード

3番目は中間品のコードについてであるが、量的変化後または質的変化後に在庫管理が必要な場合にコードを分けるべきある。例えば1日単位で在庫数を把握している工場の場合、前日計量して準備しておく原料は「計量後中間品」としてコードを分け、当日計量して翌日に繰り越さない原料はコードを分けない。『在庫管理が必要な場合に』という制限事項を忘れて、量的変化または質的変化という点だけに着目しコードを分けると、コードの数が増えレシピ階層は重層化する。当然、マスタ維持の負荷も増える。ただでさえ人手の足りない中小工場では、遠からずシステムが稼働しなくなってしまうであろう。同様の理由で、指示を出す工程ごとに中間品のコードを割り振る（例えば野菜の洗浄室と続くカット室に対し別々の指示書を印刷するためにコードを分ける等）方法も勧められない。これを回避するためには、後述する工程手順マスタの工程番号と合わせて指示を出す仕組みが必要である。

2-2 レシピマスタ

レシピマスタすなわち部品表は配合または処方を構造化したマスタであり、品目間の親子関係、投入比率の必須要素に加えて、投入順序、歩留、日付（いつからいつまで使用するか）などで構成される。レシピマスタが間違っていると製造指示書や発注書が正しく出力されないので、導入時点のみならず将来に渡って高い精度が求められる。

ただし、レシピデータの整備には手間がかかる。生産管理システムの導入コストを左右するといって良い。にもかかわらず、レシピマスタ整備の工数削減について具体的に記された文章を筆者は目にしたことがない。せいぜいコピー機能をうたう程度である。マスタ整備の責任は最終的にユーザ企業が負うにせよ、ソフトウェア会社にはユーザ負荷を減らす方法をガイドする責任があるのではないだろうか。重要と思われる点を3つ指摘する。

①商品開発レシピと製造レシピ

　組立加工業の部品表に設計部品表（Engineering BOM, E-BOM）と製造部品表（Manufacturing BOM, M-BOM）が存在するように、食品製造業のレシピマスタにも商品開発担当者が使う開発用のレシピと製造現場が使う製造用のレシピが存在する（両者を分けるべきか？統合すべきか？という議論は本稿では割愛させていただく）。商品開発レシピの特徴は原材料表示内容作成を意識した作りとなっていることである。仕入先から調達する加工食材に含まれる基原原料をレシピに登録することで、重量計算やアレルギー表示にシステムで対応できる。アレルギーのコンタミを考慮に入れたライン計画を除けば、これらの情報は製造現場には不要である。逆に在庫管理の都合で登録する仕掛品情報や投入情報、工程情報などは、商品開発レシピには不要である。

2つのレシピマスタが別々のシステムで管理される場合は、最低でも品目コードは同期を取らねばならない（品目コードは全社的に統一化されていることが前提である）。その際、時系列で先に作成される商品開発レシピが主で、製造レシピが従となる。従たる製造レシピを担当するのは生産管理システムであるが、商品開発レシピの階層情報を流用できることが求められる。商品開発と製造現場の間でレシピ情報の共有を促す仕組みや、マスタ整備の遅延を防ぐ仕組みがあればなお良いだろう。

同じ製品であってもレシピは常に変化し続けるという現実がレシピマスタの精度維持を困難なものにする。特定の日付を境にして使用原材料や配合量が一度に変わるということであれば、レシピに日付を持たせることで対応可能である。だが、食品製造業ではあまり発生しないことであるが、原材料の在庫が無くなったらレシピを切り替える、現場の判断で代替品目を使用することがある、といった場合はどうか。マスタをその都度変更することは現実的ではないので、製造指示または完成登録の際に一時的に変更するような仕組みが必要となる。

②複数階層整備

昔の生産管理システムのレシピマスタは、原材料と仕掛品、仕掛品と製品、といった具合に一階層ごとに定義する方法をとるものが多かった。だがこれでは、製品から原材料までの全体を俯瞰しながらレシピマスタを作ることが出来ない。一度定義した階層の下に新たに階層を追加することを禁止しているシステムもあった。或る製品や仕掛品が他の製品や仕掛品の共通部品である場合に影響が出ることを考慮しているのだと思われる。

このシステム操作上の制約は、既にレシピマスタが整備されていてIT専任のスタッフがいる企業は別として、多くの中小食品工場にとって無視できない多大な負荷が発生する要因となる。マウス操作で複数階層の追加、変更、削除を一度に出来るようにするなど、可能な限り直感的な操作が求められるのではないか。ただしMRPという枠内で言えばレシピマスタの基本構造は昔も今も変わらないのだから、レシピ登録処理の際には当レシピが他品目のレシピに影響を与えないか、与えるのであればそのまま変更を許可するのか、などのチェック機能が必要である。

③レシピに登録する数値

生産管理システムで使う製造レシピは、1製品あたりの数値で登録すべきであろうか。それとも1製造バッチあたりの数値で登録すべきであろうか。商品開発レシピを別で管理する前提で言えば、製造指示の出し方によってどちらかを決めるべきである。おにぎりを100個作れ、という場合は前者で良い。しかしスープのような液体の場合は、〇〇を何キロ投入せよ、という指示の出し方になる。このため製造現場にとって重要なレシピの数値は、製品1個あたりではなく1製造バッチあたりになる。歩留や製造指示の際の単位換算を使えば製品1個あたりのレシピ登録も可能ではあるが、ユーザとしては違和感がぬぐえないであろう。いずれの方法でも登録できるような柔軟さがシステム設計に求められる。

製造レシピ、商品開発レシピのいずれであってもレシピマスタはグラムなどの単一の単位で登録させる、という考えもある。製造指示数は基準となる単位の数値に換算係数を乗じて得る、という考えだ。マスタ整備の方法論としてわかりやすく、原材料表示作成の際に必要な重量計算を考えると便利である。だが、比重の異なる原材料（例えば油）はどう扱うのだろうか。重量ではなく容積で投入量を決定するのである。換算係数を使って無理に端数処理して計算するよりも、最初から製造指示で使用する単位でレシピマスタに登録しておく方が自然であり無駄がないのではないか。

2-3 工程手順マスタ

工程手順マスタあるいは工順マスタは、品目に対し工程の順序や作業区、設備、能力、リードタイム、内外区分などを定義する。一部の簡易的なシステムでは工程手順マスタをあえて省略し、品目マスタにこれらの情報を持たせるものもある。マスタ整備の難易度を下げるメリットがあり、中小食品工場の入門編としてとらえるのであれば良いアイディアである。しかし工程手順マスタを省略すると、製造ラインを切り替える、内製品を一時的に外注する、などの場合に新たな品目コードやレシピを追加しなければならない。同じモノなのに品番が異なるという事態が生じ在庫管理に支障が出る。また、複数工程に対し別々の製造指示書を出すために品目コードを作る必要が出るのは、2-1-③で述べたとおりである。工程手順マスタを省略したところで品目マスタやレシピマスタにシワ寄せが行くか、融通のきかないシステムになるか、のどちらかになると思われる。

2-4 マスタまとめ

最初に述べたとおり、マスタ整備は手段であって目的ではない。マスタ整備の工数に耐え切れず生産管理システムが稼働しなかった、という話は珍しいことではない。そのため、現状のコード体系に特段不便を感じていないようであれば、これまで本稿で述べたことに反していてもそのまま使い続けることも選択肢のひとつだ。桁数の問題が生じているのであれば、現状の品目コードに単純に2桁加えてやっても良い。現場が慣れ親しんだコード体系を捨てるデメリットも存在するのだ。CIOなどIT専任の役員が居ない中小食品工場の場合は、マスタ整備方針は経営トップが判断を下すべき重要なテーマと言ってよい。

3.個別機能

冒頭で述べたとおり、生産管理システムを構成する生産計画・手配計画、製造管理、購買管理、在庫管理、原価管理などのプログラム群は、一定の独立性を保ちつつ相互に連携している。この相互連携は2種類のデータ、すなわちオーダーと実績データを介して実現される。オーダーには受注オーダー、製造オーダー、購買オーダー、移動オーダー等があり、生産計画、製造管理、購買管理の各プログラムを媒介する。指示や注文と言い換えると分かりやすい。少々乱暴な表現ではあるが、実績データはオーダーの実行結果を記録したものである。以上を予備知識として、個別機能について拝読いただきたい。

3-1 生産方式

日本工業規格（JIS規格）では、生産計画を「生産量と生産時期に関する計画」と定義している。生産量と生産時期を適切に計画するためには、工場の製造能力を考慮したスケジューリング的要素が必要であるが、本稿では触れない。中小食品工場の多くが労働集約型であり作業者の頭数さえ揃えれば何とか仕事をこなせてしまうという無限能力状況にあるためである。負荷配分（山積みと山崩し）が問題になることは少ない。資本集約型であっても、大手に比べて機械設備の数が少ない中小食品工場の場合は、自作のExcelシートでも十分対応できているようだ。

以下、生産方式について述べる。受注してから設計に着手する個別受注生産（ETO＝Engineer to Order）で運営される食品工場の存在は寡聞にして聞かない。①受注後に原材料を手配する繰り返し受注生産（MTO＝Make to Order）②受注後に製造する受注組み立て生産（ATO＝Assemble to Order）③見込み生産（MTS＝Make to Stock）のいずれか、と言ってよいだろう。

①繰り返し受注生産

業務用カット野菜工場などに見られる。特に給食施設向けに製造する場合は、献立表が存在するので生産計画数が早い段階で確定され、またブレも少ない。規模の小さい工場の場合は使用量も少ないため、原材料がショートしそうになったら近隣の市場や卸に直接出向いて数時間以内に調達を済ませることも可能である。ただし、原材料である野菜の相場が天候状況等により大きく変動するため、価格が安い時に多めに発注して在庫として確保しておくこともあり、一概に原材料在庫を持たないとは言えない。

②受注組み立て生産

弁当や惣菜、生麺、生菓子などの日配品が該当する（後述のコンビニエンスストア向けは例外）。賞味期限が1日から数日と短いため、製品の作り置きが出来ない。原材料在庫は一定量確保しつつ、製造で減った分だけ小まめに手配をかけるのが一般的である。製造リードタイムが短いものが多いため、受注数が確定した後に製造指示をかけても納期まで余裕がある。ただし、生産設備がボトルネックとなって受注後にイチから製造を開始するのでは納期に間に合わない場合は、仕掛品在庫を持って対応しているようである。

③見込み生産

一般的には飲料や調味料など賞味期限が長く日持ちがする製品が該当する。常温で保存可能な製品は特にその傾向が強い。例外は、コンビニエンスストア向けに収める日配品である。受注数確定から出荷まで数時間しか与えられない。納品リードタイムが製造リードタイムに満たないうえ、賞味期限も1日から2日と極めて短い。このような場合は受注予測を立てて製品の見込み生産を行わざるを得ない。予測が外れれば廃棄となる、リスクの高い方式である。

④生産計画まとめ

食品において賞味期限は生産方式を左右する大きなファクターである。消費者はより期限残の長いロットを選別して購買する傾向があり、賞味期限が長い製品であっても商品としての価値はかなり短い。日配品ほどではないが、需要に合わせた小ロット製造が求められるのである。生産計画立案の期間も長くて1ヶ月程度、多くは2週間程度。一部の工場では、生産計画の機能はほとんど不要と言っても良い場合がある。中小の食品工場では生産計画機能は簡易で良いと思われる。

3-2 手配方式

中小の食品工場を想定すると、手配方式はMRPか製番のいずれかに限られる。原材料調達先との力関係においてそれほど強く立てないので、かんばん方式は現実的にあり得ない。MRPを選ぶか製番を選ぶか、は最も重要な選定ポイントと言って良いだろう。なお、製番紐付け可能なMRPなどのハイブリッド型も存在するが、話を分かりやすくするために本稿では触れない。

MRP(Material Requirement Planning)は日本語訳で資材所要量計画とあてられているとおり、合計でどれだけ必要か、に着目して計算処理を行なう。共通の仕掛品や原材料が多いほど、また原材料点数が多いほど、MRPは効力を発揮する。しかし、製造オーダーや手配オーダーなどの各オーダー間の紐付けが存在しないので、製造工程の進捗を見るには不向きである。同様の理由で、受注オーダーから製造オーダーや手配オーダーをたどることが出来ないため、製造現場への指示の際に出荷先等の情報を提示できない。

MRPは膨大な計算処理を伴うため、以前は一度実行すると数時間以上必要としていた。そのため日中を避け夜間に実行させていた。最近は処理速度が向上したため、日中に何度もMRPを回すことを前提とした業務フローが求められている。特に変更箇所だけを対象に再計算するネットチェンジ機能の速度向上には目覚ましいものがある。（ご参考までに当社ユーザの場合、それまで7～8分かかっていた計算が10秒前後まで短縮された）

MRPは計画数、レシピ、在庫の3つのデータを元に計算する、問題は、かなり高い精度のデータが必要なことである。諸説あるが、それぞれ97%以上の精度が無いと信頼できる手配オーダーが得られない。中小の食品工場ではかなり高いハードルではないだろうか。また、前記3データがいくら正確でも、歩留変動の大きい製品の場合は理論在庫があてにならずMRPに不向きといえよう。

一方の製番方式は、製番（もしくは作番）をキーとして計画オーダー、製造オーダー、購買オーダーなどを紐づけて管理することができる反面、そのままでは手配をまとめることができない。共通の仕掛品や原材料が多い場合は、オーダーを管理する工数が増えてしまう。自社の工場がMRPと製番のどちらを選ぶべきか判断のポイントは、製造指示書に受注情報を記載する必要があるか否か、である。

製造現場が受注情報を必要とする理由は、顧客によって異なる仕様（包材や内容量など）を同一の品目コードで管理している、製造作業と小分け作業が連続して行われている、製造順を現場で判断したい、などである。得意先の仕様に従ってモノ作りをしている企業はどうしても製番寄りの方法をとらざるを得ない。現在はPB中心だが、将来はNBの比率を高めていきたい意向があるならば、製番からMRPへ移行することも考えてシステム設計する必要がある。コストとの兼ね合いもあるので、経営層が判断を下すべき内容である。

3-3 手配計画

手配計画では前段のMRPもしくは製番の結果得られた手配オーダーを、発注書や製造指示書などにする前に一度人間の判断を入れて微調整する。製造オーダーの場合は、数量、納期、作業区（ライン）が変更可能でなければならない。購買オーダーの場合は、数量、納期、発注先、単価、単位の変更機能が必要だ。また、一度出したオーダーは完納ステータスに変わるまで任意のタイミングで変更できる必要がある。所要量計算を行って発注書や製造指示書を出すだけの簡易な仕組みの場合は、そもそもオーダーという概念が存在しないので注意が必要だ。

3-4 製造管理と購買管理

製造管理と購買管理では発令されたオーダーの遂行状況、完了状況、の管理が中心となる。指示通りに物事が進むのであれば良いのだが、現実は思い通りにはならない。製造や納入の納期が遅れたり、原材料の投入量や製品の完成量、歩留がレシピ通りにならなかったり、想定以上に製造時間がかかったり。人手中心の製造工程、原材料のバラつきが、製造オーダーと実績が乖離する主要因である。これらの変動は企業損益に直結するので、速やかに経営層に警告を発する仕組みが必要だ。そして経営層だけでなく、担当者本人も含めた工場全体で警告情報を共有することで、スピーディな防止処置や是正処置が期待できる。

オーダーが無くとも実績を計上できる機能も工場によっては必要であろう。事前指示の無い製造や入荷が発生するのである。前者は細かく指示を出さない・出せない製造現場で発生し、後者は緊急に調達したために発注書を出せなかった場合である。このような混乱を「あるべき姿と違う」と処断すべきこととは筆者は思えない。ヒトモノカネの全てが不足している中小食品工場の現実を受け入れた、柔らかい生産管理システムが求められるのではないだろうか。

4.おわりに

以上、当社が開発した生産販売統合システム「クラフトライン」を中小食品工場に導入した経験を元に課題と解決の方向性について述べた。今回触れなかった原価管理やトレーサビリティなど実績データ収集に近い内容については別の機会に述べてみたい。