今日の企業では様々なシステムが使われていますが、その中でも事業の基本的な取引を支えるのが、受発注や会計などの業務を支える基幹システムです。
これまで様々な業界において、基幹システムの企画・選定、導入等のプロジェクトに携わってきましたが、当然ながら、業界毎に必要なシステムの機能には違いがあります。今回は、商社、卸売業における基幹システムに注目して、基幹システムとしてパッケージシステムを検討される際に留意すべき点を考えていきます。
商社・卸売業とは
一口に、商社・卸売業と言っても、事業内容は企業によって大きく異なります。総合商社、専門商社、製造業グループにおける販社、問屋など様々です。
あらゆる商社・卸売業を対象にして話をすると、とても収集がつきませんので、ここでは、
・物（商品）を外部から仕入れる
・その物（商品）を外部に供給する（その物を原料として別製品の製造を行っていない）
という取引を中心に行っている商社・卸売業を前提にします。
このように書くと、一見、シンプルな取引と感じるかもしれません。実際のところ、商社・卸売業の企業の方とお話する際に、決まっておっしゃるのは、「うちは何も変わったことはしていないから」というお言葉です。ですが、私の経験上、特殊なことが本当になかった商社・卸売業はありませんでした。むしろ、他業界よりも独自の仕様・機能が求められることが多いのが、商社・卸売業だと感じています。
今回は、その辺りの話を紐解いていきます。
商社・卸売業の基幹システムに必要とされる標準的な機能
まず、多くの商社・卸売業で必要とされる機能について、整理していきます。当たり前の内容も多いですが、以下のような機能が挙げられます。
・受注出荷に関する機能
受注を入力し、その情報を基にシステム内で出荷指示を出し、出荷が終わったら出荷実績を入力する、という機能です。物を販売するにあたっては、ごく普通の流れであり、商社・卸売業でも当然必要な機能です。
・調達入荷に関する機能
発注を入力し、商品が入荷したら入荷実績を入力する、という機能です。発注情報を基にした入荷予定の照会機能も含みます。物を調達するにあたっては、受注同様に一般的な流れといえます。
・受注発注（直送）機能
受注と発注を同時に入力する機能です。商社・卸売業では、自社で在庫を持たず、必要となった都度調達するケースも多く、そのような取引のときに使用します。
・在庫管理・在庫引当に関する機能
自社で在庫を持たない（必要な際都度調達する）取引が中心であっても、リードタイムの都合等から、在庫として抱える商品もある、という企業がほとんどです。そうすると、在庫管理（どの倉庫に何が何個あるかの管理や棚卸）や受注時の在庫引当（在庫の確保）という機能も当然必要になります。
商社・卸売業の大半で必要となる機能として主なものを挙げてきましたが、いずれもパッケージシステムでもカバーされていることが多い機能と言えます。
商社・卸売業の基幹システムにおける特殊な機能の例
では、商社・卸売業における特殊な取引・特殊な機能について見ていきます。話をし出すと切りがないくらい様々なものがありますが、ここでは、そのなかでもよく求められる機能の例を何点か取り上げます。
・流通加工等に関する機能
商社・卸売業でも、仕入れた商品をそのまま販売するのではなく、加工をして販売することが多くあります。
商品を小分けにする（発注最小ロット100個の商品を、10個ずつ販売）こともあれば、複数商品の組み合わせ（AとBのセット）やタグ付け・梱包などもあります。加工を行うには、加工の指示を出し、その結果を記録（報告）する、という業務が必要です。これらの業務のタイミングは、受注の都度加工するケースと見込みで加工するケースとでも異なります。こういった加工業務に対応した機能というのは、パッケージシステムにはない（あったとしても充分では無い）ことが多いです。企業毎に、加工のプロセスが異なっている、加工時に管理したいことが異なる、という事情があるためです。うちの加工はシンプルだ、と思っている企業であっても、加工を管理したい場合はパッケージの標準機能では対応できないことが多い、と考えておいたほうが無難です。
・社内売買取引
商社・卸売業は部門ごとの損益を厳密に管理する企業が多く、社内の部門間で商品を融通する場合も売買として扱い、渡す側・受け取った側の業績に反映することが珍しくありません。社内取引を売買扱いにすると、実際には販売していないのに売上が計上され、かつ、商品の在庫の金額も変わるため、財務会計の情報と金額が異なってしまいます。その様な背景もあってか、財務会計の基礎情報という位置づけになる基幹システムでは、標準機能だけでは社内売買取引に対応できないことが多いです。
・サービスの販売・レンタル取引
多くのパッケージシステムは、“物”の売買を前提にした作りになっていますが、商社・卸売業で行っているのは、必ずしも物の売買だけではありません。例えば、自分達に充分なメリットがあればレンタルするという形をとることも考えられます。また、商品に保守等のサービスを付けて販売することもよくあります。物の売買を対象にした機能では、このような売買以外の取引への対応は困難です。単なる受注や売上の入力はできたとしても、レンタル時の物の管理（どこに何がある）や期間管理（期間満了時の商品返却、契約更新等）に対応するのは難しいと考えておいた方が良いです。
いずれも、決して珍しくはない取引ですが、パッケージシステムで対応しようとすると、カスタマイズ（追加開発）になる可能性があります。いずれのケースも、システムの根幹となる在庫情報にも関わりますので、大掛かりな開発になる恐れもあります。商社・卸売業においてパッケージシステムの活用を考えられる場合は、上記も参考に、追加開発が必要になりそうな点を早めに見極めておくことが望ましいです。
商社・卸売業において基幹システムを検討される際の留意点
ここまで、商社・卸売業における機能という視点で整理をしてきましたが、例示した機能はほんの一部であり、商社・卸売業で必要なものを全て挙げていくと、それこそ星の数ほど機能が必要になります。それらの機能を全て実装しようとすると、投資費用は膨大なものとなりますし、また、カスタマイズが増えれば増えるほど、パッケージシステムを使うことのメリットも損なわれてしまいます。
そうならないためには、機能の取捨選択が大切です。
取捨選択を進めるには、以下の点を意識してプロジェクトを進めていくことをお勧めします。
・重点投資すべき範囲の明確化
最初から、“いくらお金がかかっても全ての機能を実現する”と考える人はいないと思います。ですが、各ユーザーの要望を聞いてから、不要なものを切り捨てていくのは難しい作業でもありますし、実現されなかった機能を希望したユーザーは不公平感を抱いてしまいます。そうならないためにも、最初から費用を掛けても投資しようとしている範囲を、関係者に明示しておくべきです。当然ながら、その理由も一緒に示す必要があります。それを拠り所にして判断してくことにより、ユーザーにも納得していただきながら機能を選択してくことができます。
・システム目標等の関係者への周知
システムが変わるとなると、ユーザーの方はどうしても“便利になる”ことを期待します。ですが、残念ながら全ての面で便利になることはありません。むしろ、一部の領域については、不便になることもある、と考えておくべきです。混乱を招かないためには、その前提を予め関係者に周知しておくべきです。システムを構築・更新するにあたっては、何らかの大きな目標（コストを下げる、情報を活用する）があるはずです。それを明示したうえで、便利になることばかりとは限らないと伝えておくことができればユーザー側も納得感を得ることができます。
以上、2点挙げましたが、両方に共通して言えるのは、“システム構築の方針”をプロジェクトメンバーだけではなくユーザー側も含めた関係者に周知する、ということです。方針が明確で、それが企業にとって大切なことだと理解できれば、反対する人はいないはずです。
そういう状況に整えたうえで、必要な機能を整理してくことが、投資対効果の高いシステムを実現することに繋がります。
まとめ
・商社・卸売業とは
商社・卸売業は多岐にわたるが、ここでは以下の取引（事業）を対象とする。
☑ 物（商品）を外部から仕入れる
☑ その物（商品）を外部に供給する（その物を原料として別製品の製造を行っていない）
・商社・卸売業の基幹システムに必要とされる標準的な機能
次のような機能はパッケージシステムにも標準機能として搭載されていることが多い。
☑ 受注出荷に関する機能
☑ 調達入荷に関する機能
☑ 受注仕入（直送）機能
☑ 在庫管理・在庫引当に関する機能
・商社・卸売業の基幹システムにおける特殊な機能の例
様々な特殊機能が求められるが、代表的な例を挙げると次の通り。
☑ 流通加工等に関する機能
☑ 社内売買に対応した機能
☑ サービスの販売・レンタル取引に対応した機能
・商社・卸売業において基幹システムを検討される際の留意点
機能の取捨選択をスムーズに進めるためには、システム構築方針を明確にしておくべきである。
☑ 重点投資すべき範囲の明確化
どういった業務領域に重点的に投資するかを定めて明示する。
☑ システム目標等の関係者への周知
いい事（システムが変わって実現できる事）ばかりではなく悪いこと（全てが便利になる訳ではない）も予め知ってもらう。
