トップ / コラム / 拠点ごとの在庫と受発注

複数の拠点で在庫と受発注がばらばらのとき|ひとつにまとめる進め方

「本社と倉庫と営業所が、それぞれExcelで在庫を持っている」「営業が電話で倉庫に在庫を確かめてから、お客様に返事をしている」。拠点が増えてきた会社から、よく伺う話です。

困っているのは、たいてい在庫そのものではありません。どの数字を信じればよいのか分からない、という状態です。拠点ごとに数えているので、数字が合わないこと自体は避けられません。

ひとつにまとめるには、システムを選ぶ前に決めておくことがあります。そこが決まっていないと、どの仕組みを入れても数字は合いません。順を追って見ていきます。

目次(8項目)を開く
  1. 「在庫が合わない」の正体は、数え間違いではない
  2. 拠点ごとにずれているのは、だいたいこの5つ
  3. 先に決めるのは「在庫が減る時点」
  4. まとめる・つなぐ・そのまま残すの3つ
  5. 基幹システムを止めずに、外側に足せる場合がある
  6. 相談の前に自社でそろえておく6ステップ
  7. pegのやり方
  8. よくあるご質問

「在庫が合わない」の正体は、数え間違いではない

拠点の担当者は、たいてい正確に数えています。それでも全社の数字が合わないのは、拠点ごとに「いつ在庫から引くか」が違うからです。

受注が入った時点で引いている拠点、出荷の指示を出した時点で引いている拠点、実際に荷物を出してから引いている拠点、月末の棚卸しでまとめて合わせている拠点。同じ商品の「残り12個」が、拠点によって「まだ売ってよい12個」なのか「もう売り先が決まっている12個」なのかが違います。

意味の違う数字なので、足しても全社の在庫にはなりません。ここを決めないままシステムを入れると、画面がきれいになるだけで、電話で確かめる習慣は残ります。最初に決めるのは機能ではなく、数え方です。

拠点ごとにずれているのは、だいたいこの5つ

拠点をまたぐと数字が合わなくなる原因は、ほとんどこの5つに収まります。どれも現場の工夫の結果なので、拠点に非があるわけではありません。

ずれるところ現場で起きていること先に決めておくこと
在庫から引く時点受注で引く拠点と、出荷してから引く拠点が混ざっている全社で引く時点をそろえるか、2段で持つか
商品コードと単位同じ商品に拠点ごとの呼び名や番号が付いている。ケースとバラが混在する正とするコードはどれか。入り数の換算をどこで行うか
拠点間の移動中の在庫出した側では減っているが、着いた側ではまだ増えていない移動中の荷物をどの拠点の在庫として数えるか
預け在庫・返品待ち客先に置いてある分や、戻ってくる予定の分が台帳に載っていない売ってよい在庫に含めるか、別に分けるか
受発注の締め時刻拠点ごとに締めの時刻が違い、「同じ日の在庫」がそろわない締めをそろえるか、そろわない前提で持つか

この5つは、どれも正しい答えを知っているのは拠点の担当者です。開発会社が決められることは、ひとつもありません。だからまとめる作業の重さは、開発側の腕よりも、発注側がこの5つを決める速さで変わります。

並べられた段ボール箱と梱包材料

先に決めるのは「在庫が減る時点」

5つのうち、最初に決めるべきものは在庫から引く時点です。ここが決まると、残りの4つはほぼ自動的に決まります。候補は3つです。

  • 受注した時点で引く。 売ってよい数がその場で分かります。ただしキャンセルや数量変更で戻す運用を決めておかないと、在庫が実物より少ないまま痩せていきます
  • 出荷の指示を出した時点で引く。 倉庫の作業と数字が近くなります。受注から出荷指示までの間は、別に「受注済みの数」を持つ必要があります
  • 実際に出荷してから引く。 実物と必ず一致します。そのかわり、同じ在庫を二つの拠点が同時に売ってしまう余地が残ります

多くの場合は、受注の時点で「取り置き」として押さえ、出荷の実績で在庫を確定する2段構えに落ち着きます。営業に見せる数字と倉庫が見る数字を分けられるので、どちらの現場も無理をしません。

これは機能の選択ではなく、業務の決定です

どの時点で引くかは、営業にどの数字を見せるかという決めごとです。社内で決める話なので、開発会社が代わりに決めることはできません。逆に、ここが決まっていれば仕様書は要りません。

決めないまま運用を続けると、だいたい次の順で進みます。

  1. 営業が電話で倉庫に在庫を確かめる。 台帳の数字が信じられないので、人に聞くほうが速くなります
  2. 確かめている間に、別の拠点が同じ在庫を売る。 押さえる仕組みがないので、早い者勝ちになります
  3. 欠品のお詫びと納期の調整が増える。 ここで初めて「在庫管理をなんとかしたい」という話になります
  4. 現場が自分用の管理表を作る。 手元で持つほうが確かなので、拠点ごとのExcelが増えます
  5. 全社の在庫表を、だれも見なくなる。 入力だけが残り、使われない台帳になります

まとめる・つなぐ・そのまま残すの3つ

「一元管理」と聞くと、全拠点を1つのシステムに入れ替える話に見えますが、選べる形は3つあります。拠点の業務がどれだけ違うかで、向いているものが変わります。

進め方向いている状況気をつけること
ひとつにまとめる(全拠点で同じ在庫データを使う)拠点の業務がおおむね同じ。拠点をまたぐ出荷や振り替えが多い運用をそろえる合意が先に必要。1拠点だけ例外を認めると元に戻る
つなぐ(拠点の仕組みは残し、数字だけ集める)拠点ごとに業務が違う。今のシステムがまだ現役で使える締め時刻と単位の換算を決める。集めた数字は時点の数字だと全員が分かっていること
そのまま残す(在庫は拠点管理のまま、受発注の窓口だけ1つにする)拠点が独立して採算を見ている。まず問い合わせ対応だけ軽くしたい全社の在庫はその場では出ない。やるべきことを絞る判断として明示しておく

全部をまとめるのが常に正しいわけではありません。拠点の業務が本当に違う場合、無理にそろえると、現場が二重入力でしのぐようになります。それは最初の状態より重くなります。

業務のどこまでを見直すかの決め方は、システムを作る前に業務をどこまで整理するかにまとめています。

基幹システムを止めずに、外側に足せる場合がある

拠点の在庫で困っていても、基幹システムそのものは動いている、という会社は多いものです。この場合、基幹を作り直さずに、外側へ在庫の照会や受発注の窓口だけを足す形が選べます。pegでも、大手物流企業で既存のミドルウェアに外付けのアプリを足す案件を担当してきました。大手製造業の基幹システム入れ替えにも関わっています。

足せるかどうかは、既存のシステムからデータを取り出せる道があるかで決まります。確かめ方は、今のシステムを保守している会社への次の質問だけです。

  • 在庫と受注のデータを、決まった時刻に自動で書き出せますか(CSVなどのファイルでも構いません)
  • データベースを直接参照してよい契約になっていますか
  • 外部から呼び出せる窓口(API)はありますか。ない場合、追加できますか
  • 書き出せるのは何の単位で、どの時点の数字ですか

このうちどれか1つが使えれば、外付けで進められることが多くあります。基幹の入れ替えそのものをいつ行うかは、これとは別の判断です。判断の基準は業務システムは何年で作り直すのかに書きました。

外付けを増やすときの約束ごと

便利なので足していくと、同じ在庫の数字が複数の画面に出るようになります。どれが正しいのか分からなくなるのが、いちばん困る状態です。正とするデータは1か所に決めて、ほかの画面はそこを見るだけにしておきます。

相談の前に自社でそろえておく6ステップ

開発会社に相談する前に、この6つをそろえておくと、話が進む速さが変わります。仕様書は要りません。手元にあるものを並べるだけです。

  1. 拠点の一覧と、拠点ごとに今使っているものを1枚に書く。 システム名、Excelのファイル、紙の台帳、電話とFAX。どれも実際に使っているなら書きます
  2. 商品コードを突き合わせる。 同じ商品に別の番号が付いていないか、単位と入り数がそろっているかを見ます。ここがいちばん手間ですが、自社でしか判断できません
  3. 在庫から引く時点を決める。 受注時か、出荷指示時か、出荷実績か。2段で持つならその2つを書きます
  4. 拠点間の移動中の在庫をどう数えるか決める。 出した拠点に残すのか、着く拠点に先に付けるのか、移動中という置き場所を作るのか
  5. 締め時刻をそろえられるか確かめる。 そろえられない拠点があるなら、そろわない前提で作ります。無理にそろえるより確かです
  6. だれが見る数字かを決める。 営業が見る在庫、倉庫が見る在庫、経理が見る在庫は、別の数字でかまいません。1つにしようとすると、どれにも合わなくなります

このうち1と2は、発注側で進めていただく作業です。pegではここを発注側に担っていただくことで、全体の人工を減らしています。ただし「どこから手をつければよいか分からない」状態であれば、洗い出しから一緒に進めます。データの持ち方そのものについては、業務システムの入れ替えでデータ移行が詰まる5つのことも参考になります。

拠点のExcelがそのまま限界に近いという場合は、AccessやExcelで作った社内システムの限界に移し先の決め方を書いています。

pegのやり方

機能の一覧からは入りません。拠点ごとに、今どの順番で仕事をしているかを伺うところから始めます。日本眼科医会の会員管理システムを作り直したときも、機能の比較からではなく事務局の業務を伺うところから始め、試作画面(モック)で見え方と作業の流れを確かめてから、中身の開発に入りました。拠点の在庫でも同じで、画面を見ながら決める部分を残しておくほうが、早く固まります。

判定や計算は、人の頭ではなくシステムの側に置きます。ドローン操縦士協会の講習管理では、実技が10時間に届かなければ修了にできない、要件を満たしていない講師では記録できない、という判定をシステムに持たせました。在庫でいえば「いま売ってよい数」の計算にあたります。ここを人が毎回判断していると、担当者が代わったときに答えが変わります。

進め方の約束は、案件の大きさによらず同じです。

  • プログラム・設計資料・管理者権限を、納品物として契約に明記します
  • お支払いは着手・画面確定・納品の段階に分けます
  • どの案件も必ず2名以上で担当し、引き継ぎ資料を常に最新にしておきます
  • 納品後3か月の無償の不具合対応を契約に入れます
  • 一般に確立された技術と標準の型で作ります。拠点が増えたときに、ほかの会社でも引き継げる形にしておくためです

範囲とご予算が合わないときは、機能を削って形だけ作るのではなく、追加のご相談をするか、お断りすることもあります。未知の技術が必要な案件もお受けしません。

よくあるご質問

拠点が3つくらいなら、Excelを共有するだけで足りますか。

同時に書き込む人が1人で、受注の量が多くなければ足ります。足りなくなるのは、2人以上が同じ時間に書き込むようになったとき、またはお客様から在庫を聞かれてすぐ答えないといけなくなったときです。拠点をまたぐ振り替えが日常的に起きているなら、Excelでは追いつかなくなります。

在庫の数字を完全に合わせることはできますか。

棚にある実物と台帳を常に一致させることは、どの仕組みでもできません。出荷の作業と記録の間には、必ず時間の差があります。できるのは「どの時点の数字か」をはっきりさせることです。合っていない理由が説明できる状態になれば、現場は電話で確かめなくなります。

既存の基幹システムは作り直しになりますか。

必ずそうなるわけではありません。データを書き出せる道が1つでもあれば、外側に受発注や在庫照会だけを足す形で進められることが多くあります。まず保守している会社に、書き出しやデータ参照ができるかを確かめてみてください。

拠点ごとにやり方が違うのですが、そろえないと作れませんか。

そろえないままでも作れます。そろえるべきなのは商品コードと単位だけで、仕事の順番は拠点ごとに違っていて構いません。違いを残したまま数字を集める形にすれば、現場に無理な変更をお願いせずに始められます。

何から相談すればよいですか。

拠点の一覧と、拠点ごとに使っているファイルや台帳があれば十分です。仕様書は要りません。見積シミュレーターに手元の資料を入れていただくと、機能の一覧と概算の目安がその場で出ます。そのまま相談の材料にお使いいただけます。

まずは話すところから

社内に分かる人がいない状態でも、手元にある材料から整理できます。何から話せばよいか決まっていなくてもかまいません。ご相談は無料です。