表計算ソフトは、自分が使いものにならなくなったと告げてはくれません。エラーも出ず、落ちもせず、壊れる日というものがありません。代わりに起きるのは、一人の担当者が静かにシステムそのものになっていくことです。その配車担当だけが、どのシートが最新か、どの顧客の運賃が古いままか、どの行を並べ替えてはいけないかを知っている。その人が休むと業務は半分の速度になり、なぜなのかを誰も正確には説明できません。
これが本当の合図であり、ファイルの行数を数え始めるよりずっと前に現れます。以下では、輸送システムが実際には何でできているか、タイの事業者が導入時に何を測ったか、そして自社の表計算ソフトがすでに限界を越えているかを見分ける試験を扱います。
一つの言葉、四つの製品
「輸送システム」は一つの物として売られます。実際には四つであり、多くの現場では別々に購入されています。
- 業務の記録。 一荷口につき一行。誰が発注し、何を、どの車両が引き受け、いつ着き、いくら請求したか。これが背骨で、他のすべてはここを読みます。
- 計画。 どの納品先をどの車両に、どの順で載せるか。ルート計画と配車です。
- 位置。 車両が今どこにいて、さきほどどこにいたか。追跡とテレマティクスであり、計画ソフトとは別の製品分類で、供給元も通常は別です。
- お金。 記録を請求書、乗務員の賃金、一件当たり原価に変えること。
「システムが要る」と言う現場の多くが本当に欲しいのは、一つ目と三つ目です。同じ荷口を三か所に打ち直すのをやめたい。電話に「運転手に確認します」と答えるのをやめたい。よくある誤りは二つ目を買いに行くことで、それは実演がいちばん見栄えするからです。
ソフトが実際に触れたもの
タイの研究がこれをきちんと図にしています。事例の会社はバンコクと周辺に五つの集荷拠点を持ち、チャンタブリー県とナコンサワン県の小売配送センターへ幹線輸送し、そこから地場配送を行います。研究者は同じ四十工程を、クラウド型輸送管理システムの導入前後で、秒単位、工程ごとに測りました。
変化した工程は次のとおりです。
| 工程 | 導入前 | 導入後 |
|---|---|---|
| 運賃を計算し顧客に金額を伝える | 40秒 | 10秒 |
| 送り状をゾーン別に集計する | 1,500秒 | 60秒 |
| 積載明細を発行し費用をゾーン別に集計する | 1,500秒 | 30秒 |
| 着地で送り状を郡別に仕分ける | 1,800秒 | 10秒 |
| ルートを割り当てる | 1,800秒 | 10秒 |
| 費用を計算し着払いを集金する | 120秒 | 5秒 |
| ルート別の費用伝票を発行する | 600秒 | 180秒 |
| 車両を発車させる | 300秒 | 180秒 |
| 乗務員が書類を提出し返品を報告する | 3,600秒 | 600秒 |
| その日の配送と返品を集計する | 600秒 | 60秒 |
次に、変わらなかったものを見てください。幹線輸送は前後とも54,000秒。地場配送の走行は前後とも14,400秒。荷送人の車両からの荷卸し、計数、ゾーン別仕分け、積込み、書類との照合、引き渡し、戸口での集金。そのどれもが前後で同じ数字です。
幹線15時間と配送走行4時間、合わせて68,400秒は、111,218秒の作業サイクルの61.5%にあたり、ソフトはその一秒にも触れていません。
これはシステムへの批判ではありません。輸送システムとはそういうものです。それは書類を整理し計算する機械です。打ち直し、集計し直し、探し回る作業を取り除きます。トラックを速くはしません。速くなると謳う主張はすべて、トラックの走らせ方を変えられるようにするという主張として読むべきで、それは別の、はるかに難しい話です。
悪化した一工程
一つだけ逆向きに動きました。送り状一枚の発行が70秒から120秒に増えたのです。著者は、担当者が新しいシステムに不慣れだったためとしています。
50秒は大したことがないように聞こえます。しかし標本期間には150枚の送り状が発行されており、合計7,500秒になります。
改善したすべての工程を合計すると、粗い節減は10,715秒、3時間近くになります。そこから窓口で返してしまった7,500秒を差し引くと、正味は3,215秒、すなわち53分35秒です。遅くなった一工程が、得られた分の7割を食べました。
ここから二つのことが導かれ、これが研究全体でもっとも役に立つ部分です。
システムは仕事を上流へ移す。 ゾーン別集計が1,500秒から60秒に縮んだのは、集荷の時点で誰かが荷口を正しく入力したからです。窓口の人が、他の全員の節減の代金を払っています。そこを見越しておかないと、窓口が隘路になり、そこの担当者がシステムをいちばん嫌う人になります。
サイクル全体を測らなければ、間違った数字を信じることになる。 直したかった工程だけを測った人なら、3時間の節減と報告したでしょう。実際の数字は53分でした。
では53分にいくらの価値があるか
何かの形が変わるまでは、ゼロです。
一日53分の後方業務時間は実在しますが、車両一日分が金であるのと同じ意味での金ではありません。それが金になるのは、一つのシフトが消えるとき、集計をしていた人が赤字の路線を追い始めるとき、あるいは事務職を増やさずに物量を増やせるときです。そのどれも起きなければ、費用が別の科目へ移っただけで合計は同じです。あらゆる輸送の節減に当てはまる試験がここでも当てはまります。車両一日分、シフト、あるいは拠点が実際に消えたときだけ、その節減は本物です。この点は単位当たり輸送費の実際で詳しく扱っています。
だからこそ、二つ目のタイの事例を一つ目の隣に置く価値があります。スワンナプームの民間運送会社は、車両を空車で拠点へ戻していました。月額の輸送費は51,200バーツから47,020バーツへ下がり、月4,180バーツ、すなわち8.16%の節減でした。
タイ語本文を読むと帰属は明確です。節減はミルクラン方式のルート形態を採用し、総走行距離が縮んだことから生まれました。輸送管理システムは、そのルートを計画し、車両を追跡し、新しい形態を維持したものです。8.16%を稼いだのはソフトではありません。トラックの走らせ方の変更が稼ぎ、ソフトはその変更を計画可能にし、維持可能にしたのです。
ここから、契約前に問うべき質問が出てきます。これを入れたら、私たちは何を今までと変えるのか。 答えが「同じ仕事を、入力を減らして」だけなら、買っているのは書類棚であり、値段も書類棚として付けるべきです。
表計算ソフトが終わっている五つの試験
行数でも車両数でもありません。五つとも今週のうちに観察できます。
- 二人が同時に同じファイルを必要とする。 配車と請求の両方がそのファイルに入る必要が出た瞬間、順番待ちをするか、食い違う写しを二つ持つかのどちらかになります。
- 計画を配った後に変更が要るのに、安全に変える方法がない。 15時に緊急の注文が入る。誰かがシートを直し、刷り直し、一人の乗務員が昨日の版を持って出て行きます。
- 先月のことを聞かれると、その月を作り直す羽目になる。 「3月にこの顧客のこの路線でいくら請求したか」がファイル四つを開くことを意味するなら、履歴は存在しても読める状態にありません。
- 一日を回せる人が一人しかいない。 冒頭に述べたことで、五つのうちもっとも高くつきます。どの予算にも決して現れないからです。
- 同じ事実を三か所に入力している。 受注表に一度、納品書類に一度、会計に一度。打ち直しのたびに三者が食い違う機会が生まれ、実際に食い違います。
三つ目は測定されています。別のタイの事例では、記録ではなく担当者の経験で業務を組んでいた運送会社が、まともなデータベースを作る前後で自らを計時しました。情報を一件調べる平均時間は一件当たり1.05分から0.13分へ、一件の原価を出す平均時間は2.10分から0.30分へ下がりました。おおまかに言えば、事実が10秒以内に見つかるならシステムがあり、数分かかるなら人が探しているということです。
ルート計画ソフトを最初に買うことがまれな理由
実演はいちばん見事で、採算を取るのはいちばん難しい。理由は三つあります。
正しい答えは返ってこない。 大半のルート計画ソフトは最適解を出しません。与えられた制約と需要の範囲で見つけられる最良の計画を返すだけです。実際の門が15時30分に閉まる納品先を入れれば、16時を自信を持って組んできます。
毎日供給し続けなければならない。 ソフトの購入費は小さい方の費用です。毎朝正確な需要データを供給することが大きい方で、人手の時間としても規律としてもそうです。前四半期のデータで計画用途に使うなら、ルート計画ソフトは安価で非常に有用です。毎日対話的に使うなら、それは恒常的な一つの職務です。
手作業の計画を壊すのは納品先の数ではない。 そう見えるのはもっともです。五か所を回る一台には120通りの順序があり、人の頭に収まります。十か所なら3,628,800通り、十二か所なら479,001,600通りです。しかし配車担当は順序を数え上げてはいません。地図を見て地理で判断し、単純な一巡なら機械との差は数パーセントに収まります。人に本当にできないのは、納品時間帯、門の高さ、フォークリフトのない現場、一箇所当たりの上限、軸重の制限、運転時間の上限を、候補のすべてについて同時に成り立たせることです。手作業の計画にはそもそも組み込めない制約があり、だから手作業の計画は静かにそれらを落とします。
したがってルート計画ソフトの正直な試験は、納品先がいくつあるかではありません。仕事の形が日ごとに本当に変わるのか、そして同時に成立させねばならない硬い制約を抱えているのかです。納品先が毎週同じなら、一度組んで四半期ごとに見直す固定ルートの方が、毎日データを与えねばならない日次最適化より優れています。自社がどちらの体制かは拠点の安定度で決まり、その点は固定ルートか毎日計画かで詳しく扱っています。
買う順序
- 業務の記録。 一荷口、一行、一か所、入力は一度だけ。これは製品になる前に共有データベースであっても構いません。他のすべてがここを読み、これなしには何も動きません。
- その記録を読む原価計算。 記録が信頼できるようになれば、一件当たり、顧客当たり、路線当たりの原価はほとんど無料で付いてきます。
- 位置情報、顧客が電話してくるなら。 追跡が今風だからではなく、電話が痛みになっているときに買います。
- ルート計画は最後。 仕事が本当に変動し、制約が効いている場合に限ります。
そして四つのどれよりも先に、納品先の記録があります。門の高さ、受入時間帯、進入条件、そして門前で実際に取った座標。計画システムは計算機であり、誤った住所を与えられた計算機は、時刻まで付けた自信満々の誤答を返します。この記録はすでに手元にあるデータから作れます。その方法はソフトより先にマスタデータにあります。
それが直せないもの
受注の型は直せません。仕事の半分が締切後に入ってくるなら、システムは混乱をきれいに並べ直すだけで、費用は同じです。
誤ったマスタデータには耐えられず、データが誤っていると教えてもくれません。計画を出してきます。
法令が求める書類も消せません。あのタイの研究は、まさにその理由で削除できない工程を見つけました。システムは必要な書類を速く出せますが、その書類が不要だと決めることはできません。
その研究からもう一つ、持ち帰る価値のある細部があります。どの指標を残すかを問われたとき、その小規模事業者は14項目に絞りました。信頼性が7項目、応答の速さが6項目、顧客からの代金回収が1項目です。走行キロ当たり原価は一つもありません。現場の運営チームが本当に見るべきものを問われると、求めるのはサービスと現金です。それは最初のシステムが何に答えるために作られるべきかのかなり正確な説明であり、費用のダッシュボードから実演を始める供給元を測る良い物差しでもあります。