このブログも500回目を迎えました。そんな記念すべき回は、今を時めく有名経営者との対談でもなければ、出版予定の発表でもなく…この数か月取り組んでいるシステム案件の備忘的記録を何回か記載します。実に弊社らしい記念回…
世間では、みずほ銀行のシステムがたびたび止まることが話題になっています。全然内情を知らないので、この件の実態がどうなのかはわかりません。しかし、「システムの問題」は大抵の会社で「人災」です。業務が変わり、技術が変わって、市場のニーズも変わっているのに、システムは自分では変わってくれません。しかもアップデートさせるのに、なぜか巨額のシステム代がかかり、日本企業の薄利ぶりでは到底投資が正当化できない。そうしているうちに、構築時の記憶や記録もなくなり、誰もいじれなくなる。
そこで、システムが生産性のネックだとでも指摘しようものなら、日本企業では大変なことになります。「お前がやれ」という話になり、誰も協力せず（能力的に協力できないのです）、膨大な残業をして、そしていろいろな問題を起こしてにらまれます。
しかも大企業ならば、そこに責任を持つ「情報システム部」が曲がりなりにもありますが、日本では100人ぐらいの会社ではそんなものありません。そこには誰もいません。敢えて言うなら、そこには大塚商会が蟻地獄のように待ち構えています。
先日、某中堅システム開発会社の総務で使っているIT資産棚卸の仕組みがEXCELベースで手間がかかっているけど、どんな仕組みが良いか？という相談を受けました。「えっ？あんたら、システム会社だろ。取得、移動、返却の申請記録画面と、それを保管するデータベース設計をして、別にGUIなんて気にせず、新人にちょちょちょとwebアプリ作らせればいいんじゃないの？新人1日分の課題でしょ」と言ったら、どうもピンとは来ていないご様子でした。日本の会社の経営陣の「システム」思考なんてそんなものです。
そして、システム会社はできるだけ一貫した、できるだけ自動化したシステムを作って解決しますが、それは正解とは限りません。そして、都合の悪いことに立派なものを作ると1年かかって、残り2年も持ちません。業務の方がかわってしまうからです。スピードと精度が十分あれば、人力を含めて他の方法でもよいわけでコストパフォーマンスは短期的にはその方がよいです。ただし、そのために必要なのは、システムの知識ではなく、その会社の歴史、そして業務の仕組みや組織の習性を深く知ることだったりします。
そういえば、こんなことが昔ありました。
それからも数年おきにそこそこの規模のシステム対応をなぜか仕事としてきたのですが、毎回毎回膨大な労力を掛けて、孤独に問題を解決し小さな会社にそこそこの大きさのブレイクスルーを起こしてきています。
今回、この件を記載するのは、このゆうパックプリントRが改善のネックになっているEC事業者が相当いるであろう、ということを今回実感したので、きっと参考になるということもあるし、技術面を支えてくれたパートナーがせっかく習熟したのだから、今後もその知識を生かせる機会が得られるとよいという営業的意図もあります。ゆうパックプリントRで検索してもなかなか有効な策が出てこなかったという今回の経験から、そこに記録を残しておこうと思うのです。
それに中小企業がシステムを更新するというのが、技術ではなく、勇気と気合の問題である、ということも改めて今回も書いておきたい。
この件でお困りでしたら、info@kibow.biz までお問合せください。
本件のユーザーさんもそんな情報システム部のない、歴史ある中堅企業。社員のITスキルも並みの日本企業並み、(以下…かな）にしかありません。今稼働している仕組みは10年ほど前にシステムのデフォルト設定を用いて動かしているもので、それを改善しようと思うと誰も手が出せない状況が続いていました。
ただ、経営者はそこには問題を感じていて、私が「全力でやりますが、細かな問題はそれでもいろいろ起きると思いますよ」と始める前に言いましたら、「致命的ではない問題は、問題ではない」と言い切って、各種届出承認までサポートしてくれました。そんな会社の奮闘ぶりのお話です。
１ そもそもなんでゆうパックプリントRに行きついたのか？
もともと1年ほど前から、お客様のEC出荷業務のうち、特に伝票印刷工程をいかに高速化するか、そして特にITに強くなくても誰でもスイッチポンで出力できるようにするにはどうしたらよいか？ということをずっと考えてきた。それはシステムだけではなく、出荷数が少ない時代に真心こめて丁寧に仕事をしてきたチームにとって、月1万件を超えてくると工程や業務設計自体を改変する必要があるが自分たちではなかなかやれないということでもあった。営業と物流現場でのコンフリクトも調整役がおらず、そもそも両方を知る人もいないという状況に、弊社が調整役となることが多くなった。
そんなおり、運送委託会社を日本郵便に変えることになった。これも弊社がお手伝いして提案コンペを弊社が主導で実施しての結果で、事業部の売上高利益率が2％程度改善するというBig Gainであった。しかも、この変更には費用削減以外にいくつか追加的メリットがあった。それは、①翌日配送エリアが拡大する。②住所不明不達が減少することがで期待できる。(ご自分で購入申し込みされているのに、住所不達で連絡も来ない、ということがあるのです）③一体型伝票が安価に利用できる の３つである。
①の配送エリアは東京圏からの発送の場合、九州北部が他社では中一日配達エリアなのだが、日本郵便では翌日配達エリアとなる。このエリアの受注は全体の3％近くあったので、翌日到着可になることは大きかった。（が、これには一つ大きな課題が生じたので、それは別に述べる） ②は、多くの人が転居届を出す郵便局ならではの強み。 ③は1年前にも他社のシステムと合わせて利用の前提で検討したのだが、その時は、一伝票当たり15円のコストがかかる上、それを印字するシステムにも費用が生じるので、そうとうの効率化が生じて、かつ作業がひっ迫してこないと難しい(つまり増員阻止のための施策と捉えないと正当化できない）という結論に至っていたものだった。それが今回は用紙も安価、システムも「ゆうパックプリントR」を使う限りは無料で使えるということになり、導入して省力化することが可能になった。
一方で、このメリットを享受するために対応しなければならない作業もあった。これは、私は前職のコスト削減コンサルティング会社の時にもいくつか事例を対応してきていたのだが、a.集配局に荷物を持ち込み、 b.aの際に、方面別（9区分ぐらい）にかご車を分けて積載 c.正しい住所やサイズが入力された発送データを、aのタイミングでデータ伝送する というシステム的な対応である。このシステム対応に、ゆうパックプリントRが標準で対応していまる、ということはない。そのため、そこの部分を外部で実現する必要が生じた。
お客様側でのシステム対応を主幹する部署というのがないため、ここの対応を実現するというのが、この半年の弊社の結構な大仕事（ただ、これだけやっていたわけではなくて事業の伸長がメイン業務）になったのである。
このシステム対応を実現する方法が、ゆうパックプリントR＋自社であれこれ作ったり集めたり、という以外に方法がなかったのか？と言えば実はあった。これらの機能の大半に対応しているWMSの「エアロジ」というのがそれである。しかも、別途検討していたピッキングリストのバッチ分け出力にも一部対応している。日本郵便切り替え対応の検討を開始して間もなくして、このSaaSを見つけて、具体的検討に入ってトライアルも実施したのだが、今回の導入は見送ることになった。
最初に申し上げて置くと、エアロジはかなり優れた仕組みで、上手く対応すれば、現在の顧客の断片化してファイルのやり取りがあちこちで生じる工程を相当範囲で再統合することができる見通しだった。現在でも次の改善作業の際の有力候補に位置付けている。では、なぜ採用しなかったかというと、大きな理由が二つある。
一つは、エアロジは、WMSであり、基本的には、在庫の出入りをキチンと管理するための仕組みであり、送り状を印字するツールではない、という点にある。
ところが、その在庫管理の顧客の仕組みが現時点では不十分であり、エアロジを導入しようと思うとそこの業務の仕組みも同時に改善することが必然的に必要であるが、それは短期的にはやり切れない大仕事である、と判断したことである。詳しくは顧客の情報になるので省略するが、輸入品でバーコードがないものが大半であることや、非常に少人数で月間1万件の個別ピッキングや梱包作業をこなしたうえで（つまり、あらかじめ箱に入っているものを送り状を貼って出荷しているわけではない）出荷していることなどがこれに影響していた。
送り状印刷と、在庫管理の仕組みの改善のどちらが根本的問題なのかといえば後者であり、後者をやらない限り、前者で問題は生じ続けることは確かである。そして、SaaSに盛り込まれた「ベストプラクティス」(コンサルの好きな言葉ですが）を適用して業務改善を推進するというのは、良く用いられる方法であることも分かっている。業務コンサル的には後者を先にやるべきと主張することもできる。しかし、経営的観点で見るとそうではない。現場に変化を起こし続け、成果を出し続ける中で、組織の強化と上昇志向を植え付けることは、在庫が狂わないことよりもはるかに大事なことである。そもそもそれがないと、在庫が狂うと結局自分たちの不利益になっているということを実感できないでいる。だから、ゆうプリRで早期に実現し、そのあと、もう一回改善することを不効率でも覚悟したのである。
もう一つのエアロジを断念した理由は、実はゆうプリRは今でもゆうパケット(メール便）で一部使用していること、そして印字ソフトを変えるだけならば、今の前後の工程は流用が可能であるので、担当者の習熟も容易であり実現性が見通せるからである。
エアロジは、本顧客規模だと月額10万円、オプションでのRPA機能も使うと15万円程度を要するSaaSなのだが、ベンチャー特有の機能開発や対応の柔軟さがある一方で、マニュアルの整備が追いついておらず書いていないことがあったり、サポートに頼まないと設定できない箇所（それも聞かないとわからなかった）があるなど、実際に自分の会社に適用しようと思うと、安価なSaaSであるからこそ、自分でなんとかしなければならない箇所が多く存在し、トライアルがなかなか前に進まず、全体工程を結合してみるに至らなかった。
これは、会計や勤怠のSaaSでも同じであるが、業務用SaaSはある程度自分で試行錯誤できる力量や業務知識、それに改善の具体的イメージが組織にないと設定方針を決められない。しかし、本件ではそれは(弊社にも）不足していた、という事だと考えている。
そして年200万円の費用が生じることが、工程全体の時間短縮で回収できるか、と考えた時には、実はゆうプリRで実現しても所要時間はそれほど変わらないことも認めなければならない。WMSはあくまでも在庫管理ツールであって、送り状印字ツールではないのである。
そして、もう一つ重要なことがある。日本郵便にしろ、他社にしろ、送り状の印刷の仕組みのうち、あらかじめ枠が印刷された運送会社が提供する用紙に印刷するならば、特に問題はない。しかし、一体型伝票は、基本はA4白紙にミシン目の入ったシール用紙である。(この伝票については別途後述する）。そこに送り状を印字し、バーコードを印刷する場合、運送会社は自社で提供する仕組みで印字されたものであれば、確認の上OKしてくれるのだが、他社開発の仕組みで印字したものに対しては、基本的に厳しく、チェックでOKが出るまでにどれくらいの時間と試行錯誤が必要か、あるいはOKが得られるかどうかも分からない。さらに、他社システムでの一体型伝票の用紙提供を、日本郵便は不可とは言っていないのだが、動物マークの他社は、「自社グループの提供する仕組み以外を使う場合に販売しない」と伝えてきた。それでは移行時に、運送業者とシステムの両方をある日一度に変更しなくてはならなくなりリスクは増大してしまう。エアロジでは、その辺の多くのユーザーのための環境整備は進められていなかった。
年間百万件もあるような大企業ならばこうした手続きを順を追って交渉して進めることもできるだろうが、10万件ぐらいの中小企業では、こうした「不確実性」は回避する方がよい、という結論になる。
こうして、ゆうプリRを用いて業務を構築することになった。
２ ゆうプリRというソフト
最初に申し上げておくと、このソフトの最大の長所は、「サポートが非常に優れていること」である。土曜、祝日もサポートがあり、メールで翌営業日にはだいたい的確な返事がある。この前工程の受注データをエクスポートする側は、「ネクストエンジン」というECの統合管理システム（SaaS）なのだが、このネクストエンジンもサポートが非常に適切で丁寧である。この2つの連結ならば、私が質疑の対応をすれば何とか対処できるだろう、というのが、エアロジで苦労した後での、ゆうプリR採用の背景にはあった。
しかし、その他の点では、ゆうプリRは非常に制限が大きい仕組みだった。しかも難解である。という話がこのあと、次回以降たくさん出てくる。
最初は自分で対処を検討し、一体型帳票のレイアウト変更に着手したのだが、わからないことだらけであった。同じお客様の仕事の中でこれだけやっていてよいというわけでもないし、私にそこまでの素養があるわけではないというあきらめもあり、この関連部分を外部の経験者、システム知識のある人に委託しようと考えた。
しかし、ゆうプリRは広く使われているソフトではあるものの、APIを公開しているわけではないので、これを用いて開発した事業者というのはいない。一方でこれを用いて業務を改善した経験のある物流システムの専門家には、そうとう探し回って一人だけ出会ったのだが、いくつか助言はいただけたのだが、現在の構想が最適解とは違う箇所である（それはわかっていなくもない）という理由で受託を断られてしまった。世の中には、ネクストエンジン＋ゆうプリRでの業務改善を支援してくれる会社というのは、なかなかないのである。（そして、今回弊社がそれになった。）
日数ばかりが経ってしまい全然前に進まないプロジェクトに途方に暮れた私は、とうとう、元システム開発部門の管理職をしていた（20年ほど前）時代のエースエンジニアに協力をお願いすることにした。いわゆる副業人材活用である。当時の私の成果のかなりの部分は彼のおかげであり、彼の全体を見る力hは卓越したものがある。彼ならできる、という確信はあったが、彼にとってメリットがそれほどない20世紀的レガシーな仕組みであること、それも開発というよりはゆうプリRの「理解」「解読」に近い作業であることと、それに顧客に対して自分の知人を起用ことで信用されないことを弊社も恐れてこれまでためらっていたのだが、顧客の役員に恐る恐る、当社で解決可能な方法がもうこれしかないことを説明したところ、承認をしてもらえ、技術者にも了承してもらえて、そこから1か月程で完成した。持つべきものは(賢い）友である。
基本機能をマニュアル通り使うだけでも、結構な落とし穴があるのだが、それでもまあ何とかなる。しかし、一体型伝票を使うためには様々なカスタマイズが発生する。さらに先に述べたようなかご車区分指示の印字などを行おうと思うと、現場の担当者では無理な仕組みである。そして、「聞かないとわからない」仕組みがたくさんあった。(次回少し紹介しようと思う）
そして、信頼するエンジニアの協力を得て決心した。今まで構想はしていたがあきらめていた高速化、効率化の仕組みをいくつかこの機会、移行成功後の第二段階で彼に構築してもらうことで、エアロジ導入のメリットと思っていた箇所をゆうプリRを用いた工程でも実現してしまう事にした。
ここまで短いようだが、5か月近くを要している。当初は、春のうちに業者変更を実現しようと思っていたのだが、夏が終わろうとしていた…
３ 一体型伝票
ECの出荷業務では、大きく分けて3つの帳票が生じる。送り状本体、ピッキング梱包指示書(ピッキングリスト）、納品書である。これらが3つバラバラに出力される(少なくとも送り状は専用シール用紙なので、別に出る）と、これらを突合、具体的にはそれぞれをめくって伝票番号を確認して重ねてクリップ止めする作業が発生する。さらに送り状には、発払いと代金引換の2種類があり、多くの場合は別フォーマットで、システム上別ファイルで出力される。納品書もこの順番で出さないと突合は面倒なことになる。なお、納品書は最近では、電子化するケースが増えてきており、この顧客でも1年ほど前から電子化しているので、残り二つの対処の問題である。
どんなに順番を揃えて出力したとしても、一日に2千件という規模になってくると、この突合作業自体にかなりの時間がかかるし、たまにはクリップの脱落による事故も起きる。これを防止するには、大きく分けて2つの方法がある。一つは、ピッキングリストだけを最初に印刷し、梱包が終わった段階でサーマルプリンタでピッキングリストのバーコードを読んで送り状をオンデマンドで印刷するという方法である。この方法は、2個口化した場合の制御を半自動化できるというメリットがある（ゆうプリR自体にその機能はない）が、梱包担当に、バーコードを読む作業と印刷を待つ作業を追加するというデメリットがある。本来、梱包担当は、検品工程においてピッキングリストの伝票番号を読み、その後商品バーコードを用いた検査工程を行うはずなので、その工程にプリントアウトを紐づけすればこれは工数増にならないはずなのだが、この顧客に関しては特有の事情からその工程がない。そして、ピッキングよりも梱包の方が時間がかかるし、品質上も重要であることから通常は、梱包工程がボトルネックであり、短期的にはここの工程を追加改変することは適当ではないと判断した。
一方一体型伝票は、送り状とピッキングリストや納品書が1枚に印刷されているので、印刷のトータル時間も短縮し、かつ突合作業も発生しない。ただし、複数個口化した場合にはあとから追加印刷が発生する。シール用紙も、送り状部分以外はシールではないのだが、A4の特殊な紙であり市場で同等品を見ても決して安くはない。先ほど、ゆうパックでは日本郵便から安く提供される、と言ったが、それは表面上の話であり、実際には送料の中でその費用も回収されているだけの話であるので、運送会社側の実コストという意味ではサーマルプリンタでオンデマンドで印刷する方がおそらくは1，2％安くできるはずであり、それを交渉要素にできるはずである。
どちらがゴールかと言えば、おそらくはこの顧客も最終的にはオンデマンド後出し印刷である。しかし、それはただ単にシステムを組んでプリンタを買えばよいというものではなくて、人員配置や工程の分割の仕方などを最適化しなければならない話である。わかっていても、主導する弊社も対応範囲を限定しなければ着地しないし、何よりも現場の担当者自身が消化できない。移行にお金も人でもかけられる大企業ではできても、そうではない中小企業では採用できない方法はたくさんあり、最適解ではなくても、部分的前進を行わなければならないことは多くある、というのが「中小企業を助ける」ことを旨とする私たちの考えである。
そして、段階を分けて進んだ方が、結局安くて速いのである。一気にやり、大きな見積もりを出し、長期間かけたがるのは、システム屋の都合である。
と言い切ったところで、だいぶ長くなったので、続きは来週！
