2015年に出版した
『業務効率UP+収益力UP 中小企業のシステム改革』幻冬舎 (2015/9/18) より
書籍内のコンテンツをタイトルごとに公開いたします。
コンテンツの最後に、コンサルタントのコメントを追加しておりますので、合わせてご覧ください。
P.142～
第4章
「To Beモデル」のシステム構築＆改修で、業務効率・収益力を向上させる
現実の業務とかけ離れたシステムの業務プロセス
フロントエンドシステムがこれほどまでに現場において不評であったことには明確な理由があります。
おそらく、業務プロセスを精査することも、現場の人間にヒアリングをすることもなく、出来合いのパッケージ・システムを導入したことが原因だと思われますが、システムが要求する業務プロセスと、実際の業務プロセスとがかけ離れていたのです。
システムが想定する、あるべき業務プロセスとは次のようなものでした。
システム・ベンダーの考えでは、これが一般的な業務プロセスでした。そして、このプロセスに従って、各段階でシステムにデータを登録することが、現場の人間には求められていました。
ところが実際の業務プロセスは、このモデルとはかけ離れていました。
まず、第一段階で「見積り」があるのはいいとしましょう。しかし、現場の人間は「見積り」業務を行っても、それをシステムで計算することはせず、従来どおり、エクセルの見積計算シートを使い続けました。
その理由は、見積り入力システムが使いにくかったからです。
操作性の面においては決定的にエクセルのほうが使い勝手がいいことに加え、見積り額は何度も計算し直す必要があるため、それができないシステムを使うメリットはありませんでした。システムには、入力修正機能が備わっていないため、エクセルで計算して、結果だけをシステムに入力するしかなかったのです。
見積りにおいて計算のやり直しが何度も必要になるのは、見積り段階で粗利を把握する必要があるためです。従来のエクセルシートは、コストと客先への提示額を入力すると、自動的に粗利を計算してくれて、なおかつ提示額のみ見積書に反映する仕様になっていました。
システムのインタフェースはさまざまな面でエクセルに劣っていましたから、実務には使えず、形式的な結果入力として使われました。
業務の手順として「見積りの手続きを踏む」ことは当然ですが、「見積りを行う」ことと「見積りシステムへ入力する」こととは同一ではありません。実際の業務としての「見積り」は相変わらずエクセルで行っていたために、システムへの入力は、現場の手間が増えただけの話でした。
コストが把握できる見積りシステムでなければ使われないのは当然の結果と言えるでしょう。
第二段階の「受注」においても、同じような問題が発生していました。何をもって「受注」とするかの見解が、それぞれの人間の間で異なっていたからです。
一般的に「受注＝金額確定」のイメージがありますが、建設業界では金額が決まらない状況で受注することがよくあります。
特に、二次請け、三次請けの工事が大半を占めるＫ社では「この工事取れそうだから、予定あけておいてね」くらいの約束で「受注」が決まることもしばしばです。
しかし、会計上、あるいはシステム上で、金額が未確定のまま「受注」とすることは困難です。また、社内のＩＳＯ基準でも、注文請書または受注メモ等が受注の証憑とされています。
Ｋ社に限った話ではありませんが、建設業界の慣習では、電話による口約束の依頼で工事に着手し、売上時に注文書をもらって金額を確定し、辻褄を合わせているのが実情だからです。元請ですら注文書をもらえない状況では、なおさら二次請け、三次請けのＫ社が注文請書をもらうことは困難でしょう。
そのため、現実の業務では「受注」となるような口頭での依頼であっても、システム上で「受注」とすることはできません。金額が確定していないからです。
加えて工事には不確定要素が多く、必ずといっていいほど当初の見積りどおりにはいかない業務の特性もあります。受注時点で金額が確定しないのは、工事が完了するまで金額が確定しないのが、建設業界では一般的だからです。この特性が、一層受注の不確定さを助長しています。
つまり、施工技術者の集団であるＫ社では、リスクを伴う受注時点での金額確定は、どのようにしても困難でした。それなのにシステムのほうは、最初の「受注」時点で金額の入力を要求しますから、現場の人間は困って、使わなくなってしまうのです。
実際の業務では、やはり従来どおりのエクセルシートが使われていました。これは、単なる受注確認ではなく、３カ月予測の資料作成などのための案件管理として行われていました。
システム導入時も、「受注管理」という定義ではなく、確率を含めた工事の「引合案件管理」としておけば、金額の修正もスムーズにできて、システムが有効に利用されたのではないでしょうか。
第三段階は、システム上では、工事の「実行予算」の入力となっていましたが、現実の業務では、あまり入力されることはありませんでした。
エクセルシートを使った見積書作成段階ですでに実行予算はできあがっているので、システムを使う意味がありません。見積登録と同様に、これも結果をただシステムに入力するだけなので、工事予算はほとんど登録されていませんでした。
ヒアリングを行ったところ「支払い申請と連動するのであれば入力してもよい」との意見もありましたが、システムとしての対応は困難な状況にあります。また入力できる明細行数が少ないため、システム設計時に存在しなかった建設部門等では、「そもそも使えないもの」とされていました。
第四段階では、工事が行われるとともに、コストが確定し、受注金額との差額が、第五段階で売上として計上されることになっています。
ところが、現実の業務では、工事が行われてもコストがすべて確定することはありません。
工事に使う部材コストだけは確定しますが、労賃（人件費）は工期と連動しているので、工事が終わらなければ確定しないからです。
また、あるべき業務プロセスとしたモデルでは、最初の予算どおりに売上を計上し、請求を行ってから、追加工事分は後から交渉をして確定させて請求することになっていました。これも実際の業務とは異なります。健全なビジネスでは約束は約束なのかもしれませんが、現実は違います。
現実の業務では、必ず追加工事が発生しますし、追加工事分の発注や金額交渉などはないままに、作業を行います。そして、工事が終わった後で、元請業者や外注業者とのコスト交渉を行います。
システムの想定する業務プロセスと、実態の業務プロセスとを比較すると、システムの要求が絵に描いた餅であることがよくわかります。
これは、システム設計時に現場の実務担当者がプロジェクトに参画しておらず、業務手続きに関する実現可能性の議論がされていなかったことが原因であると考えられます。
業務実態に即した「あるべき（Ｔｏ Ｂｅ）」論ではなく、一般的な「あるべき」論で業務を指導した監査法人と、それを容認した経営陣の責任は大きいでしょう。
ITコンサルタントのコメント（2022年10月21日）
当事例でわかるのは、如何にシステム構築時の上流工程であるシステム化構想や要件定義、基本設計が重要かということでしょう。
監査法人に言われるがままに導入することになったことに何かしらの事情はあったにせよ、記事本文後半に「システム設計時に現場の実務担当者がプロジェクトに参画しておらず」とあるように、現場の実運用が置き去りにされたままシステム構築してしまい、失敗した事例です。
基幹システムのように規模の大きなシステム構築になると、一般的にはウォーターフォールと言って、システム化構想⇒要件定義⇒設計⇒開発⇒テストを順に進めていくことが多いのですが、先に行う工程で認識違いや考慮漏れが起こり、気付くのが遅れるほど、プロジェクトの成否に与えるインパクトは大きくなります。場合によってはプロジェクト自体凍結してしまうこともあり得ます。
当事例では、要件定義時点から、できればシステム化構想から、現場の担当者を参加させ、現状の運用を十分にヒアリングし機能に盛り込むことで、このような大きな失敗となることは防げていたはずです。
一方、本文では触れていませんが、「業務側をパッケージ仕様に合わせる」という選択肢もあります。業務プロセス自体を見直すというものです。
当事例ではとにかく急いで現状業務に合ったシステムを構築する必要がありましたが、システム構築の目的が業務改革や効率化であった場合には、現状の運用をヒアリングして機能に落とし込むだけではなく、業務プロセス側を見直しパッケージ仕様に合わせることで、長年の運用の中で属人化、非効率化していた業務が改善できることもあります。
ただし、「システムを業務に合わせる」「業務をシステムに合わせる」どちらのアプローチをするにせよ、システム化構想、要件定義など上流工程が非常に重要であり、必ず「現場の声を聴く」「現場と業務プロセス改善に向けた検討を進める」など、経営と現場、システム関連部門が一丸となって進める必要があることは言うまでもありません。
