ネジを10本使えば10本残る世界ではない。
かつおぶしを削れば水分が飛び、スープを煮詰めれば重量が変わる。
大手パッケージの生産管理ソフトを買っても、そのままでは絶対に動かない現場だった。
食品工場で必要だったのは、コードを書くことではなく、現場の部門長に弟子入りし、職人の「歩留まり」という感覚を数字に変えることだった。
今回は、かつおぶし工場に1年以上常駐し、現場の知恵と経営の数字を泥臭くつないでいったときの話を書く。
目次
- かつおぶし工場に、1年以上常駐した
- 最初に必要だったのは、システムではなく体制づくりだった
- 三つの部門に弟子入り
- 大手の生産管理パッケージを買った。でも、そのままでは使えなかった
- 一番難しかったのは「歩留まり」だった
- 生産管理、在庫、原価管理がつながっていく
- 今振り返ると、これもWITSだった
- システムを作る前に、会社の中にあるものをつなぐ
かつおぶし工場に、1年以上常駐した
かつおぶし、スープ、だしパックを製造する食品加工工場で、生産管理、工程管理、日報、在庫管理、原価管理のシステムを構築した時の話だ。当時のデータベースはOracleで、開発にはDBマジックを使っていた。
まず必要だったのは、仕事そのものを知ることであり、そのために約1年間、事務所に常駐させて頂いた。
最初に必要だったのは、システムではなく体制づくりだった
会社としては、管理会計を導入しようとしていた。コンサルタントも入り、経営側には会社のトータルシステムを導入したいという明確な目的があった。
ところが、管理会計で数字を分析しようにも、元となる数値を集めないことにはどうにもならない。生産数、投入原料、使用副資材、仕掛品の量、ロスが出たのか、その製品には実際いくらかかっているのか。まず、そうした現場の数字を集める必要があった。
現場の体制も整え、GM、製造本部長を外部から迎え、新しい体制を作っている途中だった。製造本部長も大変だったと思う。私たちSEも、もちろん外部の人間である。
しかし、工場のことを一番よく知っているのは、昔からそこで働いている現場の方々だった。
三つの部門に弟子入り
工場には、大きく分けて三つの製造部門があった。かつおぶし、だしパック、スープである。
同じ会社でも工程はまったく違う。そこで、それぞれの部門長に弟子入りするような気持ちで、どんな原料を使うのか、どう加工するのか、途中で何が仕掛品になるのか、次の工程には何を渡すのか、副資材はどこで使うのかなどを細かく見学し、「業務フロー図」を作成した。
原料・仕掛・製品・工程を理解した上で、「部品表」をいかに作ればよいのかを検討していった。
簡単に「部品表」と書いているが、食品の場合は工業製品とは少し感覚が違う。ネジを10本使えば10本なくなる、というような世界ではない。原料を加工すると、水分が飛んだり、削ったり、選別したりして重量が変わり、その上に副資材も関係してくる。
だから、実際に現場で仕事をされている方から話を聞かなければイメージが湧かないし、現場の協力なくして完成しないものだった。
幸い、現場の方々がとても良い方たちだった。仕事の話だけではなく、一緒にご飯を食べに行ったりしながら、少しずつ工場のことを理解していった。この人間関係も重要だった。
大手の生産管理パッケージを買った。でも、そのままでは使えなかった
この仕事では、大手ソフトウェアベンダーの生産管理パッケージを購入した。カスタマイズ可能なものだった。
汎用的な生産管理システムだったが、簡単にそのまま使えるものではなかった。むしろ、その中にあった所要量展開、つまりMRPの部品展開のロジックは非常によくできていた。
そこで、その優れた部分のみを使うことにした。原料・仕掛・製品を部品表にし、製品をいくつ作るなら原料がどれだけ必要なのかを展開する。そのロジックは活かし、それ以外は現場の実態に合わせて、ほとんど作り直した。
使える考え方とロジックは使い、現場に合わないところは自分たちで作る。
これは今でも同じだと思う。パッケージに会社を合わせるのか、会社にパッケージを合わせるのか。その前に、本当は「自分たちの仕事がどうなっているのか」を知る必要がある。
これは食品用の生産管理ではなかったため、結果としてそのような作り方になったのである。
一番難しかったのは「歩留まり」だった
部品表ができれば、それを展開して必要な原料を計算し、生産計画を行う。ところが、食品加工では、ここに大きな問題がある。
歩留まりである。
食品では、原料を100入れたからといって、製品が100できるわけではない。加工途中で重量が減り、不良が出て、ロスも出る。
では、100の原料から、最終的にいくつ取れると考えるのか。この歩留まり率をどう設定するかで、必要な原料の量も、生産量も、原価も変わってしまう。このさじ加減が難しかった。
システム側から見れば、「歩留まり率」という一つの数字を登録するだけである。しかし、その一つの数字を決めるためには、現場の経験が必要だった。過去の実績も見る。部門長の経験も聞く。実際の製造結果とも比べる。そうしながら、不良率や歩留まり率を調整していった。
現場の人が経験で持っている「このくらい」という感覚を、システムで使える数字に変えること。
ここが一番難しかったのだと思う。
生産管理、在庫、原価管理がつながっていく
生産管理だけを作ったわけではない。工程の実績を取り、在庫につなげ、最終的には原価管理までつなげた。
原価は、費目別・部門別・製品別という切り口で計算できるようにした。
販売側ではオンライン発注にも対応し、そこで蓄積されたデータを、管理会計を担当する部門へCSVで渡せるようにもした。
こうして、現場で作る。工程実績が残る。在庫が動く。原価が計算される。その数字を経営側が見る、という流れが少しずつつながっていった。
経営側が管理会計を導入しても、その元になる現場の数字がなければ分析できない。逆に、現場で一生懸命データを入力しても、それが経営判断に使われなければ、何のための入力なのか分からなくなる。
現場の仕事と経営の数字をつなぐ。
そのための生産管理システムだったのだと思う。
今振り返ると、これもWITSだった
当時はもちろん「WITS整理法」などという名前はなかった。しかし、今、自分の仕事をWITSの四つに分けて振り返ると、この工場でやったことはかなりきれいに整理できる。
W ― Will：経営の意思
管理会計を導入し、経営判断に使える数字を持ちたい。そのために、生産管理、在庫管理、原価管理、工程管理、仕入・販売管理、分析表づくりまでをつなげていく。
システム導入が目的だったのではない。経営を数字で見られる会社にしたい。それが経営の意志だった。
I ― Intelligence：組織の知恵
この仕事で最も重要だったのは、現場の知恵である。
工場長も外部から来た人。私たちSEも外部の人間だった。だからこそ、かつおぶし、スープ、だしパック、それぞれの部門長から工程を一から教えてもらった。
原料、仕掛、製品、副資材、加工の順番、歩留まり、不良。そうしたものは、システムの仕様書には書いていない。現場の人たちの頭の中にあった。
その知恵を聞き出し、整理し、部品表や数字に変えていった。これがIである。
T ― Tools：仕事を支える道具
Tはもちろんシステムである。
Oracleをデータベースに使い、DBマジックで開発した。大手ベンダーの生産管理パッケージも導入したが、そのまま使うのではなく、優れていたMRPの部品展開ロジックを活かしながら、現場に合う形に作り直した。
ツールに仕事を合わせるのではない。かといって、全部を一から作る必要もない。
良いものは使い、合わないところは変える。
これも、この仕事から学んだことの一つである。
S ― Story：現場と経営を、同じ数字でつなぐ
今回、Sは少し分かりにくいところである。しかし振り返ってみると、現場と経営の間にあったものを、共通の言葉と数字に変えていった仕事だったとも思う。
部門長が経験で持っていた歩留まり。現場でしか分からなかった工程。経営側が知りたかった製品別・部門別の原価。それらを、部品表や工程、歩留まり率、原価という形にしていった。
現場とSEが同じ話をする。工場長と部門長が同じ数字を見る。そして最終的には、現場と管理会計部門が同じデータでつながる。
Sを「伝える言葉」と考えるなら、今回は、現場の知恵を、会社の中で共有できる数字と言葉に変えることだったのかもしれない。
システムを作る前に、会社の中にあるものをつなぐ
1年以上工場に常駐して、工場長と一緒に現場を回り、部門長の皆さんから仕事を教えてもらいながら作った生産管理システムだった。
今なら、もっと短期間で作れる部分もあるだろう。データベースも、開発ツールも、クラウドもAIも、当時とはまったく違う。
しかし、たぶん一番時間がかかるところは今も変わらない。
会社の中にある知恵を見つけ、それを整理し、数字やルールにして、経営と現場をつなぐこと。
システムは、そのための道具である。
WITS整理法を考えるようになった今、昔の仕事を振り返ってみると、私はずっと同じことをやってきたのかもしれない。
行動前にデザインすべし。走りながら改善すべし。
かつおぶし工場での1年間も、まさにそんな仕事だった。
コメント