長年使い続けた基幹システムを、次の業務基盤へ
建設会社の基幹システムは、一度導入すると長期間使われることが少なくありません。
工事ごとの原価管理。
材料費や経費の入力。
現場別の損益確認。
会計、人事、営業管理とのデータ連携。
日々の業務に深く組み込まれたシステムほど、簡単には入れ替えられません。
今回ご相談いただいたのは、長年利用してきた建設業向け原価管理システムの刷新を検討している大規模建設会社でした。
現行システムは、業務に合わせて長年カスタマイズされています。
そのため、
「新しい製品へ切り替えれば終わり」
という話ではありません。
既存システムのサポート終了を見据えながら、
どの業務を残すのか。
どの業務を変えるのか。
どの機能を標準化するのか。
周辺システムとどうつなぐのか。
現場の業務を止めずに、どう移行するのか。
を数年単位で考える必要があります。
今回の課題は、単なるシステムの入れ替えではありません。
企業の中核業務を止めずに、次の業務基盤へ移行すること。
それが検討の中心でした。
課題は「古いシステム」ではなく、「業務が深く依存していること」
基幹システムの刷新では、
「古くなったから新しくする」
と考えがちです。
しかし、実際の難しさはシステムの年数だけではありません。
長く使われたシステムほど、
現場独自の入力方法。
社内固有の承認ルール。
部門ごとの運用。
他システムとの連携。
長年追加されてきたカスタマイズ。
が積み重なっています。
つまり、システムを入れ替えるということは、
企業の業務そのものを見直すこと
でもあります。
今回のご相談でも、現行システムは建設現場の原価管理に深く組み込まれていました。
現場ごとに材料費や経費を入力する。
工事単位で収支を確認する。
本社側で全体を集計する。
会計や人事、営業管理の仕組みとデータをつなぐ。
こうした一連の流れが存在しています。
そのため、新しいシステムを選ぶだけでは十分ではありません。
まず、
現在の業務が、どのようにシステムへ依存しているのか
を整理する必要があります。
サポート終了が先でも、準備は今から始める
基幹システム刷新でよくあるのが、
「サポート終了までまだ時間がある」
という判断です。
しかし、大規模なシステムほど、実際の移行には時間がかかります。
製品を比較する。
要件を整理する。
新しい業務フローを決める。
必要なカスタマイズを設計する。
周辺システムとの連携を作る。
データを移行する。
利用者へ教育する。
一定期間、旧システムと新システムを並行して確認する。
これらを考えると、サポート終了直前に動き始めるのでは遅い場合があります。
今回の検討でも、システム選定から開発、移行、定着までを考えれば、数年単位の準備が必要でした。
重要なのは、
期限の日から逆算して動くことです。
基幹システム刷新は、期限直前に行う交換作業ではありません。
経営、業務、システム、現場運用を数年かけて切り替えるプロジェクトです。
建設業の原価管理は、一般的な会計管理だけでは足りない
建設業では、一つひとつの工事が重要な管理単位になります。
同じ会社の中でも、
現場が違う。
工期が違う。
材料費が違う。
外注費が違う。
進捗が違う。
利益率が違う。
という状況があります。
そのため、会社全体の売上や利益を見るだけでは足りません。
必要なのは、
工事ごとの損益を、適切なタイミングで把握できること
です。
たとえば、
材料費が当初予定より増えていないか。
外注費が計画を超えていないか。
経費の入力が遅れていないか。
工事の進捗に対して原価が先行していないか。
利益率が悪化している案件はないか。
といった確認が必要になります。
原価管理システムは、単なる入力画面ではありません。
現場の情報を集め、
本社で確認し、
経営判断につなげるための基盤です。
そのため刷新では、
「今ある機能を再現すること」
だけを目的にしてはいけません。
現在より早く、正しく、経営判断に使える情報が得られるか。
ここを見る必要があります。
現場で使えなければ、基幹システムは定着しない
建設業向けシステムでは、本社だけを見て設計することはできません。
実際に情報を入力するのは、各工事現場の担当者である場合があります。
そのため、
現場から操作できるか。
通信環境が安定しない場合にどうするか。
入力項目が多すぎないか。
同じ情報を複数のシステムへ入力していないか。
承認に時間がかかりすぎないか。
といった点が重要です。
高機能なシステムでも、現場で使いにくければ入力が遅れます。
入力が遅れれば、原価情報も遅れます。
原価情報が遅れれば、経営判断も遅れます。
つまり、
現場の使いやすさは、経営情報の鮮度に直結します。
基幹システム刷新では、管理部門だけではなく、実際に入力する現場の業務を確認する必要があります。
既存カスタマイズを、そのまま再現しない
長年使われたシステムには、多くのカスタマイズが存在します。
それらには、今も必要なものがあります。
一方で、
過去の運用を続けるためだけの機能。
現在は使われていない機能。
別の方法で代替できる機能。
標準機能で十分な処理。
も含まれている可能性があります。
ここで、
「今ある機能をすべて新システムでも再現する」
という進め方をすると、新しいシステムも複雑になります。
開発期間が伸びる。
費用が増える。
保守が難しくなる。
将来の更新がしにくくなる。
という問題につながります。
そのため、刷新時には既存機能を次のように分けて考えます。
残す業務。
事業に必要で、今後も継続するもの。
変える業務。
現在のやり方より改善できるもの。
廃止する業務。
現在は使われていない、または価値が低いもの。
標準機能へ合わせる業務。
独自開発を減らし、製品の標準機能を活用できるもの。
大切なのは、
古いシステムを新しい技術で作り直すことではありません。
次の10年を考え、業務そのものを整理することです。
システム選定は、機能一覧の比較だけでは決められない
基幹システムの選定では、多くの製品を比較します。
必要な機能があるか。
建設業に対応しているか。
クラウドか、オンプレミスか。
現場から利用できるか。
カスタマイズできるか。
こうした比較は重要です。
しかし、大規模刷新では、それだけでは足りません。
たとえば、
既存データをどう移行するのか。
周辺システムと安定して連携できるか。
将来の変更に対応しやすいか。
利用者が増えても運用できるか。
障害時にどう対応するか。
権限管理はどうするか。
導入後のサポート体制はどうか。
といった点も確認する必要があります。
つまり、選ぶべきなのは製品だけではありません。
数年間一緒に移行を進め、その後も安定して運用できる仕組み全体
を選ぶ必要があります。
周辺システムとの連携が、刷新の成否を左右する
基幹システムは単独で動いているわけではありません。
会計。
人事。
営業管理。
勤怠。
購買。
請求。
経営管理。
企業によってさまざまな仕組みとつながっています。
そのため、原価管理システムだけを新しくしても、
他システムとの連携がうまくいかなければ、業務は改善しません。
たとえば、
同じ情報を複数回入力する。
CSVで毎回手作業を行う。
連携エラーを人が確認する。
データ反映に時間がかかる。
という状態では、システムを新しくしても負担が残ります。
刷新時には、
どのシステムが正しいデータを持つのか。
どのタイミングで連携するのか。
エラー時に誰が対応するのか。
データの変更履歴をどう残すのか。
まで整理する必要があります。
システム連携は、画面では見えにくい部分です。
しかし、日々の業務を支える重要な部分でもあります。
大規模利用では「導入」より「移行」が難しい
利用者が多いシステムでは、新しい仕組みを作ることだけが課題ではありません。
実際には、
旧システムから新システムへ、どう安全に移るか
が大きな課題になります。
データ移行。
利用者アカウント。
権限設定。
操作教育。
マニュアル。
問い合わせ対応。
並行稼働。
切替日。
障害時の対応。
これらを準備する必要があります。
例えるなら、
走っている列車の乗客を降ろさずに、線路を切り替えるようなものです。
会社の業務は、システム刷新のために何か月も止めることはできません。
そのため、
どの業務から移行するか。
どの部門で先に試すか。
どのタイミングで旧システムを止めるか。
問題が起きたときに戻せるか。
を事前に設計します。
大規模な刷新ほど、完成したシステムの機能だけでなく、
移行計画の品質
が重要になります。
最初からすべてを決めきらない
大規模システムでは、最初にすべての要件を決めようとすると、検討が長期化しがちです。
また、実際に使ってみなければ分からないこともあります。
そのため、刷新では段階的な進め方が有効です。
**現状分析
↓
業務と要件の整理
↓
候補製品の比較
↓
一部機能での検証
↓
詳細設計
↓
開発・設定
↓
データ移行
↓
一部部門での利用
↓
改善
↓
全体展開**
この順番で進めます。
特に重要なのは、実際の利用者を早い段階から巻き込むことです。
管理部門だけで決めたシステムが、現場では使いにくい。
現場の要望をすべて入れた結果、システムが複雑になる。
こうした問題を避けるため、
経営。
管理部門。
情報システム部門。
現場。
それぞれの視点を整理する必要があります。
成果は「新しいシステムを導入したこと」ではない
基幹システム刷新は大きなプロジェクトです。
そのため、システムが稼働すると、
「導入が完了した」
こと自体が成果に見えます。
しかし、本当に見るべきなのは、その後です。
たとえば、
工事別損益を把握するまでの時間が短くなったか。
現場の入力負担が減ったか。
二重入力が減ったか。
月次締めが早くなったか。
データ連携の手作業が減ったか。
利用者からの問い合わせが減ったか。
経営判断に必要な情報を早く見られるようになったか。
といった変化です。
機能数ではなく、
業務と経営がどう改善したか
を確認する必要があります。
今回の検討から見えたこと
今回のご相談では、
長年使ってきた原価管理システムのサポート終了を見据え、
次の業務基盤を早い段階から検討したいという課題がありました。
重要なのは、単なる製品の入れ替えではありません。
建設現場の原価管理。
本社での集計。
周辺システムとの連携。
既存カスタマイズ。
データ移行。
利用者教育。
運用。
これらを一つの計画として考える必要があります。
そして、最初にやるべきことは製品を決めることではありません。
まず、
現在の業務を整理する。
本当に必要な機能を確認する。
不要なカスタマイズを見直す。
将来の業務に必要な情報を決める。
移行に必要な期間を逆算する。
そのうえで、最適なシステムを選びます。
Sekimosoft合同会社では、新しいシステムを導入すること自体ではなく、
導入後に業務と経営がどう改善するか
という視点からご提案しています。
システムは手段です。
大切なのは、
現場の入力負担が減ったか。
工事ごとの損益を早く把握できるようになったか。
手作業の連携が減ったか。
経営判断に必要な情報が早く届くようになったか。
そして、
事業を止めずに、次の基盤へ移行できたか。
という成果です。
基幹システムのサポート終了を、まだ先の話だと考えていませんか
「現在のシステムが数年後にサポート終了する」
「長年のカスタマイズが多く、簡単に移行できない」
「現場と本社で使うシステムを見直したい」
「複数の製品を比較しているが、判断基準が分からない」
「大規模な刷新を、どこから始めればよいか分からない」
このような課題がある場合は、まず現在のシステムと業務を整理することから始めます。
何を残すのか。
何を変えるのか。
何をやめるのか。
どのシステムと連携するのか。
いつまでに何を決める必要があるのか。
を整理します。
基幹システム刷新では、
サポート終了の日ではなく、移行準備を始める日が重要です。
大きなシステムを一度に入れ替える前に、
まず現在の業務と将来の姿を整理する。
それが、事業を止めないシステム刷新の第一歩です。
まずはDX診断で、自社の基幹システムと業務にどのような改善余地があるか確認してみてください。
