基幹システムが古くなった。更新したいが、何から手をつければいいか分からない。ベンダーに相談しても、自社の要件をうまく伝えられない。
このケースでは、30年前に構築した基幹システムの更新に向けて、業務フローの整理からRFP（提案依頼書）の完成までをどう進めたかをご紹介します。
本記事は、当社の支援内容をもとにした想定事例です。実績が蓄積され次第、お客さまの許可を得て実事例に差し替えてまいります。
ご相談の内容
化学品卸売業を営む従業員50名の会社の経営者から、ご相談がありました。
ご相談の内容は、「基幹システムが古くなっている。更新したいが、どう進めればいいか分からない」というものでした。
この会社の基幹システムは、約30年前に構築されたものでした。Windowsベースではあるものの、画面は黒い背景に白い文字が並ぶだけのテキスト入力方式です。マウスでクリックして操作するようなグラフィカルな画面ではなく、キーボードで一つずつコマンドを打ち込んでいく。しかもキーボードの操作がそのソフト独特の設定になっており、一般的なWindowsの操作とは異なる独自のキー割り当てが使われていました。
長年使い続けてきたベテラン社員は手が覚えているので問題なく操作できます。しかし、新しく入った社員にとっては、このシステムを使いこなすこと自体が大きなハードルになっていました。操作を覚えるまでに時間がかかり、入力ミスも起きやすい。マニュアルも十分に整備されていない。「システムが使える人」と「使えない人」に分かれてしまい、業務が特定の社員に集中する原因にもなっていました。
経営者ご自身も、システムの老朽化は以前から認識していました。しかし、基幹システムの更新は会社全体に影響する大きなプロジェクトです。何から始めればいいか分からない。ベンダーに相談しようにも、「何をどう伝えればいいか分からない」。そのまま何年も手をつけられずにいた、とおっしゃっていました。
まず、プロジェクトチームを組むところから
基幹システムの更新は、一つの部署だけの話ではありません。受発注、在庫管理、経理、営業――業務の流れは部署をまたいでつながっています。ある部署でシステムに入力された情報が、別の部署の業務の入力データになっている。一箇所を変えれば、他にも影響が出ます。
そこで、特定の担当者だけで進めるのではなく、各部署から代表者を出してもらい、社内横断のプロジェクトチームを編成していただきました。メンバーには、各部署の管理職と、実際に業務を回しているエースの作業者を入れてもらいました。管理職は部署全体の業務を俯瞰できますし、エースの作業者は現場の実態を最もよく知っています。この両方の視点が必要です。
プロジェクトチームとは、以後定期的に打ち合わせを行い、進捗の共有や方向性の確認を行う体制を作りました。基幹システムの更新は数ヶ月にわたるプロジェクトです。途中で「聞いていなかった」「勝手に決まっていた」という声が上がると、プロジェクト全体が止まってしまいます。関係者が最初から参加し、自分ごととして進めることが重要です。
経営者の話を聞く ― トップインタビュー
最初に行ったのは、経営者へのインタビューです。
ここで聞くのは、システムの機能や業務の細かい話ではありません。「どんな会社にしたいか」「今後どういう方向に成長したいか」「5年後、10年後にどうなっていたいか」という経営のビジョンです。
なぜ業務の話ではなく経営の話から始めるのか。基幹システムは会社の業務の根幹を支える仕組みです。一度更新すれば、次の10年、15年はそのシステムとともに仕事をしていくことになります。目の前の不便を解消するだけでなく、経営者が目指す方向に合った仕組みにする必要があります。
たとえば、「今後は取扱品目を増やして新しい顧客層を開拓したい」という方針があれば、商品マスターの拡張性や顧客管理の柔軟性がシステムに求められます。「現在の売上規模を維持しつつ、少ない人数で回せる体制を作りたい」であれば、入力作業の自動化や情報の一元管理が優先されます。経営の方向性によって、システムに求める要件は大きく変わるのです。
この段階で経営の方向性を把握しておかないと、現場の要望を集めただけの「便利にはなったが、経営には活きない」システムになってしまいます。
各部署の業務を聞き取る
事前準備：調査票と帳票の収集
ヒアリングの前に、各部署に調査票を配布しました。担当している業務の内容、業務の流れ、使っているシステムや帳票、日常的に感じている不便や問題点、「こうなったらいいのに」という要望などを、事前に書き出してもらうものです。
ヒアリングの場で一から「どんな業務をしていますか」と聞いていると、業務内容の説明だけで時間が終わってしまいます。事前に調査票で基本的な情報を把握しておくことで、ヒアリング本番では「なぜそのやり方になっているのか」「どこに問題を感じているか」という、より踏み込んだ質問に時間を使えるようになります。
あわせて、業務で使っている帳票のサンプルも収集しました。伝票、注文書、納品書、報告書、管理台帳、Excelの集計表。紙もデジタルも含めて、業務の中で使われている書類を一通り出してもらいます。
帳票は業務の流れを映す鏡です。どんな情報が、どこで発生し、誰に渡り、どこに記録されるか。帳票を追うことで、口頭の説明だけでは見えない業務の実態が浮かび上がってきます。「この帳票は何のために作っているのですか」と聞くと、「前任者から引き継いだのでよく分かりません」という回答が返ってくることも珍しくありません。誰のために、何のために存在しているのか分からない帳票が、30年の間に蓄積されていることもあります。
ヒアリング：現場の声を聞く
各部署の管理職と、実際に業務を回しているエースの作業者に、1回あたり1〜2時間のヒアリングを行いました。
ヒアリングで主に確認するのは、現在の業務プロセスです。「この業務はどういう順番で進むか」「誰が何をどこに入力して、その情報は次にどこに行くか」「この帳票はどこで作られて、誰に渡り、最終的にどこに保管されるか」。業務の流れを一つずつ、具体的に確認していきます。
同時に、担当者が日常的に感じている問題点も拾っていきます。ここで出てくる声は、非常にリアルで具体的です。
「受注データを基幹システムに入力した後、同じ情報をExcelにも手入力している。二重入力になっているが、基幹システムからデータを取り出す方法が分からないので仕方なくやっている」
「在庫データがリアルタイムに反映されないので、営業が顧客に在庫状況を聞かれるたびに倉庫に電話で確認している。1日に何回もこのやり取りが発生する」
「月末の売上集計に丸2日かかる。基幹システムからデータを取り出して、Excelに貼り付けて、関数で集計して、上司に報告する資料を作る。毎月この作業を繰り返している」
「取引先ごとに単価が異なるが、基幹システムには反映しきれていないので、受注のたびに過去の伝票を探して単価を確認している」
こうした問題点は、システムのカタログには書かれていない、その会社ならではの課題です。
化学品卸売業ならではの事情もありました。取り扱う薬品の種類が非常に多く、納品の形態もさまざまです。メーカーから顧客に直送するケース、自社の工場で調合してから納品するケース、倉庫から仕分けて出荷するケース。同じ「受注→出荷」でも、製品や取引先によって業務の流れが異なります。在庫管理は手書きの台帳がメインで、棚卸しにも大きな人手がかかっていました。
ただし、化学品は日持ちするものが多く、単価も比較的安い。食品のように厳密な賞味期限管理が必要なわけではありません。一般的なコンサルタントであれば「在庫管理をきちんとして、トレーサビリティを導入しましょう」と言うかもしれません。しかし、この会社の実態を見ると、そこまで厳格な管理は業務上必要なかったのです。こうした業務の実態や優先度を無視して、「あるべき論」を押し付けても、現場には合いません。
現場の方が長年感じてきた不便や非効率を一つずつ拾い上げつつ、業界の商習慣や業務の実態も踏まえて、「何を変えるべきか」「何は変えなくていいか」を見極めていく。このヒアリングを全部署に対して行い、会社全体の業務プロセスと問題点を洗い出しました。
業務プロセスを図に起こす
ヒアリングの結果をもとに、各部署の業務プロセスを図に起こしました。
整理するのは2つの流れです。一つは「人の作業の流れ」。誰が、どんな順番で、何をしているか。受注を受けたら、まず何をするか。次に誰に情報を渡すか。その人は何をするか。この流れを時系列で図にしていきます。
もう一つは「帳票の流れ」。どんな帳票が、どこで作られ、どこに渡り、どこに記録されるか。注文書が届いたら受注伝票を起こし、その伝票の情報をもとに出荷指示書を作り、納品書を発行する。この帳票の流れを人の作業の流れと重ね合わせることで、業務の全体像が可視化されます。
図に起こして初めて見えることがあります。
「この情報は3つの部署で同じものを別々に入力している」――受注情報を営業部が基幹システムに入力し、物流部がExcelに転記し、経理部がまた別のシステムに入力していた。元の情報は同じなのに、3回入力している。
「この帳票は作っているが、実は誰も見ていない」――以前は必要だったが、業務フローが変わった後も惰性で作り続けている帳票が見つかった。
「この承認プロセスがボトルネックになっている」――ある承認者に書類が集中しており、その人が不在だと業務が止まる。
業務の中にいると、自分の担当範囲しか見えません。全体を俯瞰して図にすることで、部署をまたいだ無駄や重複が明らかになります。30年間、少しずつ変化しながら積み重なった業務プロセスには、当時は合理的だったが今は意味がなくなっている手順や、人が変わるたびに追加された非効率な作業が、想像以上に残っていました。
問題点を課題として整理する
各部署から集めた問題点は、そのままでは数が多く、個別具体的すぎて対策が立てにくい状態です。「受注入力が二重になっている」「在庫がリアルタイムに見えない」「月末集計に2日かかる」「過去の伝票を探すのに時間がかかる」――こうした個々の問題点を、そのまま一つずつ解決しようとすると、対症療法の積み重ねになってしまいます。
そこで、問題点を集約し、カテゴライズし、課題として抽象化していきます。
たとえば、「受注情報の二重入力」「在庫データのリアルタイム反映がない」「月末の手作業集計」は、いずれも「情報がシステム間で分断されており、手作業で橋渡ししている」という一つの課題に集約できます。「取引先ごとの単価確認に時間がかかる」「過去の伝票を探す手間」は、「マスターデータが整備されていない」という課題です。
課題は2つの側面から整理しました。
一つは、あるべき姿と現状のギャップです。経営者のビジョンや各部署のヒアリングで出てきた「こうありたい」という姿と、現在の業務プロセスの差。この差が、解決すべき課題です。
もう一つは、現場から出てきた問題点を集約・抽象化したものです。個々の問題点をカテゴリに分類し、「結局のところ何が問題なのか」を構造的にまとめます。
この2つの視点から課題を整理することで、「何を、なぜ、どの順番で解決すべきか」が明確になります。
あるべき姿を描く
課題が整理できたら、次は「あるべき姿」の業務プロセスを設計します。
まず当社から、たたき台を提案しました。現状の業務プロセスと課題をもとに、「こういう流れにすれば、この課題が解決できるのではないか」という案です。
たとえば、受注情報が一度入力されたら、在庫の引き当て、出荷指示、請求処理まで自動で連動する流れ。取引先ごとの単価がマスターデータとして登録されていて、受注時に自動で反映される仕組み。月末の売上集計がボタン一つで出力できる状態。こうした「こうなったら理想的」という業務プロセスを、具体的な図として描きます。
このたたき台に対して、プロジェクトメンバーから意見をもらいます。「ここは賛成だが、ここは現場的に難しい」「この部分はもっとこうしたい」「この業務は取引先との関係があるから、すぐには変えられない」。こうしたやり取りを何度か繰り返しながら、あるべき姿の業務プロセスを一緒に作り上げていきます。
ここで重要なのは、何でもかんでもシステム化すればいいわけではない、ということです。
たとえば在庫管理。手書きの台帳で管理しており、棚卸しにも人手がかかっている。一般的には「在庫管理システムを入れてリアルタイムに在庫を把握しましょう」となりそうなところですが、この会社の場合、取り扱う化学品は日持ちするものが多く、単価も安い。厳密なリアルタイム在庫管理の必要性は、実はそこまで高くなかった。一方で、受発注の情報の流れや売上集計の手間は深刻で、そちらの改善が先でした。
生産管理についても検討しました。自社工場での調合工程はあるものの、工程自体は複雑ではない。大掛かりな生産管理システムを入れるほどの必要性はなく、既存のやり方で十分回る部分でした。
また、業界の商習慣も制約条件として考慮しました。取引先との受発注のやり方や伝票の形式など、自社だけでは変えられない部分があります。「本来はこうすべき」という理想論ではなく、業界の慣習の中で実現可能な形を設計する必要がありました。
すべてをデジタル化すれば効率が上がるとも限りません。現場での作業性を考えると、紙のままの方が使いやすい場面もあります。デジタルにしなくても、そこまで詳細な情報が必要ない業務もあります。「デジタル化すべきところ」と「今のままでいいところ」を、業務の必要性と優先度に基づいて仕分けていく。これが、あるべき姿を設計するうえで最も重要な判断でした。
現行のプロセスとあるべき姿の乖離が大きすぎる部分については、一度に変えるのではなく、フェーズを段階的に分けました。まず優先度の高い課題――この会社の場合は受発注と売上管理の情報の流れ――から取り組み、効果を確認した上で次のフェーズに進む計画にしています。「理想的だが実現できない計画」ではなく、「着実に進められる計画」にすることが大切です。
どんな会社にしたいか、どう成長したいか、どこまで変えるか。こうした方向性の判断は、最終的には経営者とプロジェクトメンバーに決めていただきます。当社の役割は、その判断に必要な材料を揃え、具体的な選択肢を提案し、決まった方向性を実現するための道筋を設計することです。
RFP（提案依頼書）としてまとめる
あるべき姿の業務プロセスが固まったら、それを実現するために「どんな情報が必要か」「どんな機能が必要か」を一つずつ洗い出しました。
たとえば、「受注情報が入力されたら、在庫の引き当てと出荷指示が自動で連動する」というプロセスを実現するには、受注管理機能、在庫管理機能、出荷管理機能が必要で、それぞれがリアルタイムに連携する必要がある。「取引先ごとの単価が自動で反映される」には、取引先マスターと単価マスターの管理機能が必要で、契約条件に応じた単価の自動適用ロジックも求められる。
こうした要件を、機能単位で整理していきます。あわせて、現行システムからのデータ移行の要件、ユーザー数やアクセス権限の設計、運用・保守の体制なども含めてまとめます。
これに、課題の解決策とその優先順位をロードマップとして加え、RFP（提案依頼書）として一つの文書にまとめました。
RFPとは、ベンダーに「当社の業務はこうなっていて、こういう課題があり、こういう機能を持ったシステムを実現してほしい」と伝えるための文書です。業務フロー図、課題一覧、機能要件、ロードマップ――これらが一冊にまとまっていることで、ベンダーは「この会社が何を求めているか」を正確に理解できます。
RFPがない状態でベンダーに相談すると、ベンダーのソフトを前提に話が進みます。「うちのソフトにはこんな機能があります」「御社にはこのプランが合うと思います」。自社の要件が整理されていないので、ベンダーの提案が自社に合っているかどうか、判断する基準がありません。
RFPがある状態で相談すれば、自社の要件を前提に話が進みます。「この機能要件を満たせますか」「このデータ移行は対応可能ですか」「この業務フローを実現するための提案をお願いします」。複数のベンダーから提案を受ける際にも、同じ要件で比較できるため、「どのベンダーの提案が自社に合っているか」を客観的に判断できます。
見えてきたこと
業務フローの整理からRFPの完成まで、数ヶ月にわたる一連のプロセスを通じて見えてきたことがあります。
一つは、業務の中に想像以上の無駄や重複が潜んでいたことです。30年間、少しずつ変化しながら積み重なった業務プロセスには、当時は合理的だったが今は意味がなくなっている手順や、人が変わるたびに追加された非効率な作業が残っていました。「昔からこうやっているから」で続けてきた業務が、実は大きなコストになっていた。これはシステムを新しくするだけでは解消できません。業務プロセスそのものを見直す必要がありました。
もう一つは、現場の方が持っていた問題意識の深さです。ヒアリングの場で出てきた問題点は、どれも具体的で、長年の実務経験に裏打ちされたものでした。日々の業務の中で「こうなったらいいのに」と思いながらも、「仕方がない」と受け入れていた。その声を拾い上げて、あるべき姿の業務プロセスとシステム要件に反映していく。この作業が、RFPに現場の実態を反映させ、説得力を高めることにつながりました。
そして、プロジェクトチームの意識が変わったことも大きな成果でした。最初は「上から言われたから参加している」という温度感だったメンバーも、自部署の業務が全体の中でどうつながっているかを知り、他部署の問題点を聞くうちに、「これは自分たちの問題でもある」と感じるようになっていきました。基幹システムの更新は、単なるIT投資ではなく、会社全体の業務を見直す機会でもあるのです。
今後の展望
RFPが完成したことで、この会社は「何を実現したいか」を具体的にベンダーに伝えられる状態になりました。現在は、RFPをもとに複数のベンダーから提案を受け、比較検討を進めている段階です。
基幹システムの更新は、古いソフトを新しいソフトに入れ替えることではありません。業務プロセスそのものを見直し、あるべき姿を描き、それを実現するための要件を明確にする。この準備があるかないかで、導入後に「使えるシステム」になるか「使われないシステム」になるかが分かれます。
当社では、ベンダーに相談する前の段階――「そもそも自社の業務がどうなっていて、何をどう変えたいのか」を整理するところからご支援しています。業務フローの可視化、現場の声の収集、問題点の抽出と課題の整理、あるべき姿の設計、そしてRFPの作成まで。この一連のプロセスを、経営者やプロジェクトメンバーと一緒に進めていきます。
企業によって業務のやり方はさまざまです。業界標準や一般的な指標はありますが、それを無理に当てはめて標準化するのではなく、その会社の実態に合った、無理のない運用ができる範囲で提案することを大切にしています。当社から「こういうやり方にした方がいいのではないか」という改善案を提案しつつ、現場の方から「そこまでやらなくてもいいのでは」という声を聞きながら、一つずつ詰めていく。このやり取りの中で、その会社にとって本当に必要な仕組みが見えてきます。
システムの更新を検討しているが何から始めればいいか分からない、という段階で構いません。まずはお話を聞かせてください。
