システム化の前に、業務を整える

システムは、業務のごちゃごちゃを整理してくれない

新しい業務システムを入れれば、今の仕事が一気に整う。

業務が散らばっている会社ほど、そう期待したくなります。顧客管理ができる。見積もりも作れる。受注も管理できる。請求や入金も見える。そう説明されると、今の困りごとがまとめて片づくように見えます。

しかし、実際にはそう簡単ではありません。

システムは、業務のごちゃごちゃを自動で整理してくれるものではないからです。

ルールがない業務をシステムに入れても、ルールは生まれません。例外だらけの運用をそのまま載せれば、システムの中にも例外だらけの運用ができます。マスタが整っていなければ、入力はできても、あとで集計、検索、連携のところで行き詰まります。

経営管理の現場でよく起きる問題は、システムそのものの良し悪しだけではありません。

現状の業務が整理されていないまま、いきなりシステム化しようとすることにあります。

そのまま載せると、そのまま残る

導入前の現場では、顧客情報、見積書、受注情報、請求、入金確認がそれぞれ別々に管理されていることがあります。

顧客情報は担当者ごとのファイルにある。見積書の形式は人によって違う。請求書は別の表計算ファイルを見ながら作る。入金確認は通帳や明細を見ながら手作業で消し込む。拠点、本社、請求先、納品先の関係も、明確なルールがなく、その都度判断している。

この状態でシステムを入れると、何が起きるでしょうか。

一見すると、入力先は一つ増えます。けれど、業務の流れは整理されていないままです。顧客をどの単位で登録するのか。見積と受注をどうつなげるのか。請求先と納品先が違う場合にどう扱うのか。例外処理を誰が判断するのか。こうしたルールが曖昧なままだと、現場は結局、これまでのやり方を残します。

その結果、システムにも入力する。従来の表計算ファイルにも残す。担当者の手元にもメモが残る。

二重入力や二重管理は、それ自体が本質的な問題ではありません。システム移行の途中では、一定期間の並行稼働が必要なこともあります。新旧の数字を照合し、現場が新しい運用に慣れる期間も必要です。

問題は、並行稼働があることではありません。

業務のルールやマスタが整理されていないために、何をシステムに一本化できるのかが決まらず、結果として二重管理が常態化してしまうことです。

大がかりな要件定義をしよう、という話ではない

ここで誤解してはいけないのは、「システム化の前に業務を整理する」といっても、大がかりな要件定義をしようという話ではないことです。

最初から完璧な業務フロー図を作る。すべての例外処理を書き出す。全社のマスタを一気に統一する。詳細な要件定義書を何か月もかけて作る。

もちろん、大規模なシステム導入であれば、そうした工程が必要な場合もあります。

しかし、中小・中堅企業の経営管理では、最初からそこまで大きく構えると、かえって前に進まなくなることがあります。現場の困りごとは今日も続いています。資料は探しにくい。数字は集まりにくい。確認作業に時間がかかる。そこを放置したまま、完成形の設計だけに時間を使うのは現実的ではありません。

必要なのは、完璧な設計図ではありません。

小さく始める範囲を決め、その範囲だけは業務の流れ、ルール、マスタを最低限そろえることです。

スモールスタートとは、整理しないまま始めることではありません。

整理する範囲を小さく切ることです。

スモールスタートにも、最低限そろえるものがある

たとえば、まず見積から請求までを対象にするのであれば、その範囲で最低限決めるべきことがあります。

顧客はどの単位で管理するのか。会社単位なのか、拠点単位なのか、請求先単位なのか。

見積番号、受注番号、請求番号はどうつながるのか。過去の見積を参照するとき、どこを見ればよいのか。

値引きや特別対応は、誰が承認するのか。標準的な処理と例外処理をどう分けるのか。

顧客マスタ、商品マスタ、担当者マスタのどれを正とするのか。古い名称や重複登録をどう扱うのか。

これらをすべて完璧に決める必要はありません。しかし、何も決めないままシステムに入れると、最初は動いているように見えても、件数が増えたところで行き詰まります。

同じ顧客が複数登録される。担当者によって分類が違う。見積と請求がつながらない。集計した数字を見ても、どの前提で入力されたものか分からない。結局、確認のために別の表を見に行く。

この状態では、システムは経営管理の土台になりません。

単に、もう一つの入力先になります。

マスタが整っていないと、数字は信用されない

経営管理で特に重要なのは、マスタの整備です。

顧客、商品、部門、担当者、案件、拠点。こうした基本情報の持ち方が曖昧なままだと、どれだけ入力しても、あとで数字を使う場面で困ります。

売上を顧客別に見たい。商品別に粗利を見たい。拠点別に採算を見たい。担当者別に案件の進捗を見たい。

そう思ったときに、マスタが重複していたり、分類ルールが人によって違ったりすると、集計結果が信用されません。

「この数字は正しいのか」

「この顧客は別名で登録されていないか」

「この売上はどの部門に入れるべきなのか」

「この商品分類は誰が決めたのか」

こうした確認が毎回発生すると、経営者も現場も数字を使わなくなります。

経営管理の仕組みは、数字を集めるだけでは意味がありません。集めた数字を見て、判断できる状態にする必要があります。そのためには、業務の流れだけでなく、数字の前提になるマスタを整えることが欠かせません。

まず、小さく整える

この判断について、私はこう考えています。

「100点を目指して時間がかかるよりも、まず速やかに出せそうな業績管理の仕組みを先に走らせることによって、早く成果を刈り取ったり、あるいは経営管理に社内を巻き込んでいく、有益であるということを示す、すなわちクイックウィンをスモールスタートにて達成したいから、このように判断をした。」

ここで言っているスモールスタートは、業務を整理しないまま、とりあえずシステムを入れるという意味ではありません。

むしろ逆です。

全体を一気に整えようとすると時間がかかる。だから、まず対象範囲を小さく切る。その範囲だけは、業務の流れ、例外処理、マスタの持ち方を最低限そろえる。そして、実際に使いながら改善していく。

たとえば、最初は全社の顧客管理を完璧に作るのではなく、特定の事業や特定の取引類型に絞る。すべての帳票を置き換えるのではなく、見積から請求までの流れだけを整える。すべての例外をシステムに入れようとするのではなく、標準処理と例外処理の線引きを決める。

小さく始めるからこそ、何を標準にするのかを決めやすくなります。

小さく整えるからこそ、現場も変化を受け入れやすくなります。

システム選びの前に見るもの

業務システムの導入で見るべきなのは、機能の多さだけではありません。

見積書を誰が作るのか。

過去の見積もりを誰が参照するのか。

顧客情報はどの単位で持つのか。

請求先と納品先が違う場合に、どの情報を正とするのか。

入金確認は誰が、どの資料を見て行うのか。

例外処理は誰が判断し、どこに記録するのか。

経営者は、そこから何を見て判断したいのか。

この問いが曖昧なままでは、どんなシステムを入れても、現場は自分たちのやり方で補います。その結果、表計算ファイルも残り、紙も残り、個別のメモも残ります。

もちろん、それらを一度に全部なくす必要はありません。移行期間には並行稼働も必要です。例外処理をすべてなくすこともできません。

それでも、どの範囲を標準化するのか。どのマスタを正とするのか。どの例外は残し、どの例外はルール化するのか。ここを決めずに進めると、システムは業務改善の手段ではなく、現状の混乱を写し取る箱になってしまいます。

まず業務を動く形にする

経営管理というと、きれいな数字、正確な資料、高度なシステムを思い浮かべるかもしれません。

しかし、実際の支援現場では、その前にやることがあります。

業務を、動く形にすることです。

誰が見ても同じ顧客を指している。見積と請求がつながっている。例外処理の判断者が決まっている。どのマスタを正とするかが分かっている。最低限、そこが整っていれば、最初の仕組みは大きくなくても構いません。

逆に、ここが曖昧なままシステム化すると、入力は増えても、判断に使える数字にはなりません。現場にとっては「また入力するもの」になり、経営者にとっては「資料はあるが信用しきれないもの」になります。

システム化の前に必要なのは、大がかりな要件定義ではありません。

小さく始める範囲を決め、その範囲の業務ルールとマスタを整えることです。

あなたの会社で、システム化したい業務は、いまどのくらい整理されているでしょうか。例外処理は誰が判断しているでしょうか。顧客や商品などのマスタは、あとで集計や検索に使える状態になっているでしょうか。

もしそこが曖昧なままなら、先にやるべきことは、システムを選ぶことではないかもしれません。

まず小さく業務を整えること。

それが、システム化を経営管理につなげるための最初の一歩です。

株式会社シザコンサルティングでは、中小・中堅企業の経営管理の仕組みづくりを支援しています。システムを入れたいが、業務ルールやマスタが整理されておらず、経営判断に使える数字につながるか不安がある方は、無料相談をご利用ください。

https://forms.gle/5iDPnoXr8HZDqqoe7

※ 本記事は実際の支援案件をもとにしていますが、企業の特定を避けるため、企業名・個人名を伏せ、日付や部門構成などの属性は変更しています。経営管理上の構造や判断の内容は、実際の事例に基づいています。