このような取り組みは、HABAねっとでは「第3段階 骨格調整」としてお手伝いしています。→ サービスの詳細
一人称の読み物（ストーリー形式）で読みたい方は → ストーリー版はこちら
01 概要
| 業種 | 製造業（樹脂成形） |
|---|---|
| 想定する企業規模 | 従業員約65名 |
| 所在地 | 北陸地方 |
| 該当する段階 | 第3段階 骨格調整（基幹システムと部署ごとの表のつなぎ直し） |
| DX支援の範囲 | 基幹システムの裏のデータベース（Oracle）から、Microsoft Access・Excel・Googleスプレッドシートへ直接データを渡す仕組みづくり |
| 使った道具 | Oracle（基幹システムの裏のデータベース）、Microsoft Access、Excel、Googleスプレッドシート |
本モデルケースは、基幹システムから決まった帳票しか取り出せないために、部署ごとに手元の表が育ち、それぞれが基幹システムの数字を打ち直していた企業が、基幹システムの数字を「正本」に決め、手元の表へ直接数字を渡す形につなぎ直す、という典型的なパターンを描いている。会社の中心の仕組みと、部署ごとに積み上がった表を組み直す、第3段階の仕事である。
02 取り組み前の課題
このような企業では、受注・在庫・出荷の正しい数字は、長年使ってきた基幹システムの中にある。ただ、取り出せるのは導入時に決めた帳票（決まった形の一覧）だけで、部署が見たい形の一覧はない。そのため、部署ごとに手元の表が作られていく。
| 課題 | 詳細 |
|---|---|
| 部署ごとの打ち直し | 営業はExcel（週1回・約2時間）、生産管理はMicrosoft Access（毎朝・約40分）、成形課はGoogleスプレッドシート（週2回・約1時間ずつ）に、帳票や画面から手で写す。合計で週約7時間 |
| 表ごとに数字が違う | 写すタイミングがばらばらで、同じ品物の受注残が表によって違う（例：営業の表480個、生産管理の表360個） |
| 会議が確認で終わる | 月曜の生産会議（60分）のうち、20〜30分が「どの数字が正しいか」の突き合わせに使われる |
| 帳票を足すと重くなる | 部署ごとの帳票を追加で作ってもらうには、見積もりから完成まで時間と費用がかかり、見たい形が変わるたびに頼み直すことになる |
手元の表には、それぞれ育った理由がある。生産管理の表には金型を付け替える順番が、営業の表にはまだ注文になっていない内示（お客さまからの事前の見込み）が入っている。どれも、基幹システムの画面ではできないことを補うためのものだ。表をやめさせれば済む、という話ではない。
03 このケースでのHABAねっとの関わり方
基幹システムの画面や帳票は、データをためておく倉庫（データベース）をのぞく窓にあたる。このケースの基幹システムでは、倉庫にOracle（データベースの製品）が使われていた。
HABAねっとが行ったのは、窓の種類を増やすことではなく、倉庫から手元の表へ直接データを渡す道を作ることだった。営業のExcel、生産管理のMicrosoft Access、成形課のGoogleスプレッドシートが、基幹システムの裏のデータベースから受注残や在庫の数字を直接受け取れるようにした。手元の表の形はほぼそのままで、数字の出どころだけが変わる。
04 取り組みの内容とプロセス
表へ直接つなぐ
正本と決める
2週間見比べる
列を分ける
フェーズ1：基幹システムの裏のデータベースから、手元の表へ直接つなぐ
基幹システムの裏にあるデータベースから、Excel・Microsoft Access・Googleスプレッドシートのそれぞれが受注残・在庫・出荷の数字を受け取れるようにする。帳票を追加で作る必要はなく、部署の見たい形は手元の表の側で決められる。
フェーズ2：基幹システムの数字を「正本」と決める
経営者が、「受注残・在庫・出荷の数字は基幹システムのものを正本とし、手元の表では打ち直さない」という決まりを社内に置く。つなぐ道具を用意するだけでなく、どの数字を信じるかを会社として決めておくことが、各部署の表を一つの中心に向ける。
フェーズ3：打ち直した表と、直接つないだ表を2週間見比べる
切り替えの前に、各部署がこれまでどおり打ち直した表と、データベースから数字が届く表を並べて見比べる。このケースでは、営業と成形課の表は打ち間違いを除いてほぼ一致したが、生産管理の表だけはいくつかの品物で数字がそろわなかった。
原因は、生産管理の担当者が、不良の出やすい品物を写すときに少し多めにしていたことだった。打ち直しの中に、担当者の判断が溶け込んでいたのである。
フェーズ4：「正本の数字」と「付け足した数字」の列を分ける
生産管理の担当者は、データベースから届く受注残の横に「上乗せ」の列を別に作る。営業も、内示の数を「付け足し」の列として分ける。正本の数字と人の判断が並んで見えるようになり、どこからが人の判断なのかがほかの部署にも分かる形になる。
05 成果
| 項目 | 改善前 | 改善後（切り替えから2ヶ月後） |
|---|---|---|
| 基幹システムからの打ち直し（3部署の合計） | 週約7時間 | 週約1時間（付け足しの列の入力のみ） |
| 生産会議での数字の突き合わせ | 60分のうち20〜30分 | ほぼなし |
| 受注残・在庫の数字の出どころ | 表の数だけ（3つ） | 基幹システムのデータベース1つ |
| 担当者の上乗せ・内示の数 | 写した数字に混ざって見えない | 別の列として見える |
| 部署ごとの帳票の追加開発 | 検討中 | 見送り（手元の表で見たい形を作れるため） |
一方で、会議で数字の見方が分かれることが、まったくなくなるわけではない。内示や上乗せの数は今も人が入れており、その付け足しをめぐって営業と生産管理の意見が分かれることはある。
変わるのは、議論の出発点だ。「どの数字が正しいか」ではなく、「正しい数字の上に何を足すか」から話が始まる。同じ会議の時間でも、判断に使える時間が増える。
06 このモデルケースの示唆
このモデルケースから見えてくるのは、「部署ごとの表は、なくす対象ではなく、会社の中心の数字につなぎ直す対象である」ということだ。表が生まれたのは、基幹システムが見せる形と現場が必要な形が違っていたからで、表そのものに罪はない。問題は、表と中心の数字のあいだを、人の打ち直しが埋めていたことにある。
もう一つは、つなぎ直すと、打ち直しの中に隠れていた判断が表に出てくることだ。担当者の上乗せのように、本人には当たり前のひと手間が、ほかの人からは見えていないことは多い。正本の数字と付け足しの数字を分けておくと、その判断を会社で共有し、話し合える形になる。
正本が一つに決まると、手元の表は「写し」ではなく、中心の数字をのぞく「窓」になる。
07 今後の展開
このようなケースでは、受注残・在庫でつなぎ直しが落ち着いたあと、同じ考え方を出荷や材料の受け入れの数字にも広げていくことが多い。どの数字を基幹システムの正本とし、どの数字を手元で付け足すかを、部署ごとに整理していく。
08 同じ課題を抱える方へ
「部署ごとの表の数字が合わない」「結局、誰かが基幹システムの画面から打ち直している」。基幹システムを長く使っている会社で、よくうかがうお話です。多くの場合、表を作った人の問題でも、打ち直している人の問題でもありません。
一度、社内の手元の表が、どの数字をどこから写しているかを並べてみてください。同じ数字を何か所で写しているかが見えると、会社の中心の数字とつなぎ直す候補が見えてきます。
HABAねっとでは、会社の中心にあるシステムと、部署ごとに積み上がった表や道具をつなぎ直す支援を「第3段階 骨格調整」としてお引き受けしています。
素早く、手早く、滑らかに。