さて、某アパレル企業では割と昔からITが発達しておりまして、私が入社した1992年段階で既に数店舗だけですがPOSデータを本社に送信していたりしました。

こういうものは当然なんですが、最低限のメリットとして棚卸が容易になるってのがありましたので、数年後には百貨店の消化店舗ではごく少数の例外を除き、POSデータがそろうようになってきました。

そういう中、会社では基幹システムがメインフレームっていう、ちょっとしたスパコンみたいなものを使用していまして、これがレンタル期限が切れるタイミングで一気に当時流行のサーバー・クライアントシステムに組み替えるって話になりました。今のような全部門の業務に組み込めるようなものは存在しておらず、大きくは物流系・基幹の商品の出入りの管理や売上系、企画商品の生産管理系の３つでそれぞれ別のモノにするしかないな、という結論になりました。私が基幹系に深く携わっていた時期ですから、私のところにも話がきて、ベンダー数社の説明会なんかに参加したりしてました。

ところがですね、その途中で人的リストラクチャリングがありまして、このプロジェクトを中心で行っていたメンバーが会社を辞めてたりなんかして、一向に進捗がなかったんですよ。その話を聞いたのが切り替えの4か月くらい前で、なかなか衝撃でした。

とは言え、こちら側の要望は事前に出しています。
①店頭在庫を一定期間維持するように、要するに売れたら在庫が減るのでそこにむけて出荷する。
②初回投入はデータは一気に処理して、物流で数日かけて出荷処理を行う
③優先順位をつけて投入店舗を選択できるようにする

これくらいですかね。各部門、特に物流とはデータ共有しておく事も決めました。

生産のところは若干先行していて「前と同じがいい」っていう愉快な結論をだしてくれてましたから、このあたりはちょっと放置です。

ってことで４か月前に急にプロジェクトの実質的リーダーになっちゃいまして。ベンダーさんが絡んでいるので自社開発ではないんですけど、納期がタイトすぎて。

さて、この段階で私が想定していた(というか会社として合意していた方向性なんですけど)出荷のルール的な物は、

①初回出荷は任意に設定できる
②追加出荷はデータに登録してある「店舗別(運用はランク別)在庫」を補填する、要するに店頭で売れたら出荷。
③全店舗にいきわたらない場合は一定のルールで優先順位を決めて引き当てる
④細部の修正は可能にしておく(ぶっちゃけPOSが入っていない店舗もありましたから、絶対必要です)
⑤ランク登録や店舗別在庫登録はExcelとかのデータを吸い上げる事ができるようにする。
⑥(そもそもなんだけど)POSデータを参照する。

⑦引き当て処理(データ上店舗へ割り振った状態ですね)と出荷指示(大雑把に言えば伝票が出てピッキングを始められる状態です)は独立させる。

てな感じです。大雑把に言えば①店頭展開時期を任意に決めたうえで②店舗規模に応じた店頭在庫(これが半月or１月で変わるわけですが)を維持するように追加投入するってのが大方針です。売れた分を計算して出荷するんじゃなくて在庫データが減った分を計算して出荷するようなメカニズムですね。

なんでこういう風にしたのかっていうと、売れたデータそのままだと、次に必要なのか不必要なのかがそもそもわからないからです。なので必要な(理想的な)在庫を先に設定しておいて、それに近づけさせる方がオペレーション的にわかりやすかったんですよ。

③はまあ前からやってたことです。④は、まあ非常用ではありますけど、イレギュラー前提にしておかないとめんどくさい事になるのが通常でしたからそれまでです。

⑤なんですけど、店舗ランクってのはそう頻繁に変更はしないんですけど、ここで登録する在庫ってのはMD的な時々に応じた理想在庫で、要するにシーズン経過によって変わっていくんです。最低でも月１は変更してましたから、Excelとかでできないと詰みます。ちなみにExcel側でマクロ…は組んだかな？…まあいいか、とりあえず扱いやすいようにしておいて、そこで加工したものが吸い上げられるページに反映するようにしてました。⑥はそもそもですね。

⑦に関しては、物流の平準化ってのとも関連してきますが、全量入荷した商品は引き当てまではしておかないとフリーの在庫量が読みにくいっていう事情もあります。

さて、これが完備されれば、初回投入時期を設定しておけば自動的に引き当てられて、任意の時期に出荷指示が行え、かつ追加に関しては勝手に理想形に近づけてくれる、という、なかなか都合が良いシステムになりそうです。１ボタンにはできませんでしたが、まあほとんど手がかかりません。ついでに言えば誰がやっても似たような結果になります。

さて、ベンダーさんとの折衝の話なんですが、実はベンダーさんのシステムは、入荷→分配→出荷がワンセットで自動で動いてくれる仕組みでした。救いだったのは、在庫から逆算していく方式が私の考えと合致していたところです(というか、そこが合致するベンダーさんを選んだんでしょうけど、最終的な選択には関わってなかったもので)。聞けばミセスフォーマルのような高額少量の商品用のシステムだったようで、物量的にもシーズン展開の速度的にも、その他細部は全部調整というか新規製作です。ベンダーんからしてもなかなかハードですが、さすがに妥協なんかできません。

まあ、結果的には１月だけメインフレームのレンタルの延長ができまして、１月遅れで納品できて間に合いました。実はこの段階では全部の機能を盛り込み切れていなくて、あと私の見逃しとかもあってプチパニックになりましたが、まあそれからさらに１月か２月でなんとかまともに稼働するところにまで持ち込めました。原理は簡単なんですけど運用レベルで適合させようと思うとややこしくなるよなー、ってしみじみ思いましたよ。ふぅ。

ちなみに、１年くらいたった時点でかなりの改修を行ったんですが、楽でしたね、実際。当時プレイングマネージャーだったんですけど、自分の持ちブランド(まあ社内では当時一番大きいブランドではありましたが)だけなら毎日平均１時間もあれば余裕で処理終了です。プログラミングはしていないとは言え、自分のイメージで構築したシステムですから当然なんですけど。クオリティが劇的に上がって(それまでのシステムがあまりに卸売り特化だったってだけなんですけどね)、作業時間も減少しました。私はパソコンもう一台で違う仕事をしながらシステムを動かしてましたから、実質的な作業時間は数分とかそんな感じでした。

でも後から考えたらここで手が空いたことが問題だったのかも知れません。自分の本来の仕事以外の仕事を山ほど抱え込み始めたのもこの時期からです。トホホ。性質の悪い事に微妙に本来の仕事(全店舗＆倉庫在庫の商品のコントロール)に関わってるんだよなー。まあ従来の部門に横串を刺すような部門を作った私が悪いわけなんですが。涙。