(本記事は、太田 記生氏の著書『DX時代に成長する製造業のIT戦略 ITプロジェクトを成功させるためのノウハウ』＝現代書林、2022年10月19日刊=の中から一部を抜粋・編集しています)
IT戦略の本丸は「基幹システム」の活用
■基幹システムは会社の命である
製造業では従来、ITというと「業務を補助するためのツールや手段」と見られてきました。
しかし、事業の根幹に関わる受発注、在庫、生産、入出荷、請求、入金、支払などの基幹業務を司る「基幹システム」になると話は違います。もし、基幹システムが止まれば主要な業務が止まってしまうからです。
基幹システム（正式名称は基幹系業務システム）とは、生産、販売など企業の基幹となる業務を管理するシステムのことを指し、企業の中枢となるシステムです。「このシステムがなくなったら業務が止まってしまう」ような業務遂行に不可欠なシステムです。部門システムとは異なり、全社規模で運営されます。
基幹システムは単なるツールや手段ではなく、会社の「命」を握るシステムであり、基幹システムの導入は会社の命運をかけたプロジェクトなのです。私自身、基幹システムの導入に関わるコンサルティングを行うことにやりがいを感じていますし、クライアント企業のために絶対成功させなければならないという気概を持って取り組んでいます。
会社の命運がかかっている以上、基幹システムの導入プロジェクトには経営層が関わることが不可欠です。なぜなら、基幹システムの導入プロジェクトにおいては、進行段階に応じて、繰り返し経営判断が求められるからです。
基幹システムがカバーする範囲をどこまでにするのか、パッケージ型システムの標準機能にはない機能をカスタマイズして追加するのか、それとも、従来の業務を見直すのか、場合によっては思い切って業務を廃止するのか。こういった判断は、現場の担当者だけではできません。
経営目線で会社全体としてのメリット、デメリットを考えると、別の判断になることは珍しくありません。経営目線とは、「現行業務を全てそのまま続け、現行業務に必要な機能をそのままIT化することで、本当に売上アップやコスト削減、自社の成長につながるのか」と問うことです。
経営目線で、現場から要求される機能が不必要だと判断した場合は、現場からの要求を抑えるよう説得しなければならないこともあります。
■製造業における基幹システムの対象業務
企業規模が大きくなるほど、生産管理機能のみ、請求管理機能のみといった個別のシステムでの運用では業務効率が低下していきます。部署ごとに個別のシステムを使い、データの連携もなく、社内で何度も同じデータを入力することになってしまうからです。
成長に伴って企業規模が大きくなれば、入力業務の効率化のため、社内の各種データの連携や一元管理が不可欠になります。例えば、見積データや受注データはその後も社内の各部署、各業務で引き継いでいく必要があります。
製造業における基幹システムがカバーするのはおおむね、図表2のように、見積作成から受注、材料や部品の発注、生産、入出荷、売掛金と買掛金の管理までです。これらの業務を統合し、処理するのが製造業における基幹システムです。
そして、財務諸表などを作成する会計システムや、人事・給与・労務システムなどのサブシステムと連携することもあります。
製造業向けのパッケージ型基幹システムは、私が調査しただけでも30種類以上が発売されています。ただ、その内容は様々で、受発注業務に特化したものや、生産管理業務に特化したものなど、カバーする業務範囲が狭いものも含まれています。
■RFPは「IT化のグランドデザイン」
基幹システムの導入にあたって、最初の山場になるのが「RFP（Request ForProposal：提案依頼書）」を取りまとめる段階です。
RFPは、IT化を遂行するにあたって、ITベンダーに具体的な提案を依頼するための文書のことです。ITベンダー、ソフトウェア、サービスを選ぶために必須のアイテムであり、RFPをどのようにまとめるかが、自社にとって最適な基幹システムを導入するための鍵を握っています。
具体的には、社内の各部門にヒアリングし、それぞれの業務のどの要件を、IT化の対象とするのかをまとめます。RFPは「IT化のグランドデザイン」です。
ところが意外に、RFPの取りまとめは疎かにされがちです。
なぜならば、RFPがなくてもITベンダーは提案、見積をしてくれるからです。しかし、ITベンダーは自社が提案したいシステムを前提にしたヒアリング・提案になりがちですので、それでは不十分なのです。
ITプロジェクトの成否は、RFPの策定にかかっているといえます。
■製造業の基幹システムではパッケージ型システムの利用が基本
現在、基幹システムはパッケージ型システムを使うことが一般的となっています。
情報システムの導入方法には大きく2種類があります。オーダーメイドでシステム開発をする「スクラッチ開発1」と、あらかじめ標準的な機能を備えたソフトウェアを用いる「パッケージ型システムの利用」です。以前はスクラッチ開発がシステム導入の主流でしたが、クラウド化の進展もあり、最近ではパッケージ型システムの利用が世界的な潮流となっています。
多くの企業に導入された実績豊富なパッケージ型システムの場合、利用頻度の高い機能を標準化しており、画面などのユーザーインターフェイスも使いやすくなっています。
しかし、全ての企業に対応できるわけではありません。企業には創業以来の積み重ねの中で、それぞれ独特の業務のやり方や慣習があり、パッケージ型システムを導入する際、標準機能で対応できない業務については別途、システムを開発して組み込む必要があります。これを「カスタマイズ」や「アドオン」といいます。
なお、基幹システムに加え、他のサブシステムも含めて、企業内の主要な管理業務を網羅する「ERP2」と呼ばれるシステムもあります。ERPとは、製造業でいえば、受発注、在庫、生産、入出荷、請求、入金、支払などの基幹業務のほか、財務、労務、人事など社内の主要な業務を一元的に管理するパッケージ型システムです。製造業でもERPを導入するケースが見られます。ERPが持つ機能のうち、必要な業務に限定して利用することも可能です。
企業規模や要件によっては、ERPではオーバースペックになることもあります。そこで、基幹業務に絞った「生産管理・販売管理一体型の基幹システム（生販一体型システム）」を導入し、他業務については、必要に応じて個別のシステムを導入するケースも多くありります。
また、ERPを利用しつつ、生産管理など要件が複雑な機能のみ個別システムを利用し、ERPとデータ連携させる方法もあります。
なぜITプロジェクトが暗礁に乗り上げるのか
■既存業務をそのままIT化しようとして失敗
企業のDXの中心的存在となるIT活用ですが、いざプロジェクトに着手してみたものの暗礁に乗り上げるケースが後を絶ちません。
そこには、共通する原因が見られます。
第一の原因は、既存の業務をそのままIT化しようとすることです。典型的なのが、紙の文化を残すケースです。私が関わったプロジェクトでも当初、印鑑を押した社内文書をスキャナーで画像データにし、それを基幹システムで保存したり出力したりできるようカスタマイズしたいという要望が社内から出てきました。
確かに、以前は税務署への対応や、得意先の要望などで紙資料が必要になる場面が多かったのですが、最近は徐々にデータのやり取りで済むようになってきています。また、どうしても書面をデータで保存しておく必要があるのであれば、スキャナーで取り込んだ後、クラウド上のファイル共有サービスなどに置いておくのでも構わないでしょう。わざわざカスタマイズまでして基幹システムに取り込む必要はありません。
■値切ればよい、というものではない
暗礁に乗り上げる第二の原因は、ITベンダーに無理な値下げを要求することです。
システム開発のコストにおいて、多くの割合を占めるのは人件費です。パッケージ型システムの導入であっても、要件定義、設計、導入支援作業、カスタマイズ開発作業、移行作業など、人件費が大きな割合を占めます。
このコストを値切ることで、担当者の人数を減らされたり、未経験者などを任命されるなど、結果的に開発のスピードや品質が落ちることになるのです。納期遅れやバグの増加につながる可能性もあり、その対応に追われるうち、プロジェクトの完了が見えなくなることもあります。
確かに、IT化において予算のコントロールは重要です。しかし、「ざっくり1割、安くしてくれ」といったやり方では駄目だということです。私の場合、「1割安くしてくれ」と言われて、無条件に「はい、分かりました」と答えるITベンダーには懸念を抱きます。なぜなら、無条件に値下げするということは、サービスのレベルを下げるということとほぼイコールだからです。
ここからはIT業界の内輪話になりますが、ITベンダーのSEは、スキルや経験によって待遇に差があり、どの待遇のSEが担当するかで顧客への請求金額が変わってきます。顧客から無理に値切られると、経験の少ないSEをアサインしたり、プロジェクトの規模や難易度から見て、通常ならSEを2人付けるところを、減らして対応する可能性があります。
無理な値下げの影響は、テスト段階でも現れます。テストでは様々な不具合やトラブルが発生しますが、SEの勘に基づく臨機応変な対応力は、個々のSEの経験値によって大きく異なります。
どうしてもコストを削減せざるをえないとき、私が過去に関わったプロジェクトでは、不要不急な要件を削減したり、ライセンスの必要数を減らしたり、使用するハードウェアのスペックを落としたり、テスト環境を省略したりすることを検討しました。テスト環境とは、システム稼働中にも、新機能のテストや検証ができるように本番同等のシステムを本番環境とは別に作ることです。
■社内の抵抗の結果、カスタマイズが膨らんでいく
IT化で暗礁に乗り上げる第三の原因は、パッケージ型システムを前提にしているにもかかわらず、カスタマイズが増加していくことです。
パッケージ型システムのメリットは、あらかじめ標準機能を備えた汎用性の高いシステムのため、スクラッチ開発をするよりも、少ないコストと時間で導入が可能なことです。
ところが、「この機能を入れてほしい」「現状と同じがよい」「新しいシステムでこれができないのは困る」という現場の声を全て取り入れた結果、標準機能にない機能を追加するカスタマイズが膨らみます。その分、システム開発の時間と費用が増加していきます。
カスタマイズしすぎると、将来のバージョンアップのときに、カスタマイズしたところも再びカスタマイズしなければなりません。当初、5000万円かけてカスタマイズしていたら、次も5000万円余分に必要となる可能性があります（バージョンアップのときにカスタマイズした機能を標準機能に組み込んでもらえれば別です）。
結果的に、パッケージ型システムの利点が発揮できないばかりか、プロジェクトの予算が超過する原因にもなるのです。
■IT化は自社の業務改革のきっかけ
意外に認識されていませんが、パッケージ型システムを導入する最大の意義は、自社の業務を改革するきっかけにすることだと私は考えています。
例えば、基幹システムは、製造業であれば受発注、在庫、生産、入出荷、請求、入金、支払といった基幹業務を統一的につなぐものです。その点、パッケージ型システムは様々な企業に受け入れられるように開発されており、標準機能でカバーできる業務範囲が広く、汎用性が高くなっています。
パッケージ型システムを導入することにより、部門の都合を優先して行われてきたこれまでの「部分最適」のやり方を見直し、「全体最適」を目指すことが可能になります。この点をよく理解せず、「うちのやり方とは違う」「それだと我々が困るからこうしてくれ」といった各部門の現場の声にひきずられると、せっかく「全体最適」を目指していたものが、再び「部分最適」に逆戻りすることになりかねません。
したがって、経営目線で見て、経営上のメリットをもたらさず、会社全体としてマイナスになるようなカスタマイズは、勇気を持って削減していくことをお勧めします。
2. ERP：Enterprise Resource Planning の略で、企業が持つ経営資源の情報を統合的に管理すること。また、この考え方を実現するパッケージ型システムのことをERPパッケージと呼ぶ。
中小企業診断士、情報処理技術者(システムアナリスト、ソフトウェア開発技術者)
岡山大学経済学部卒業、同志社大学大学院総合政策科学研究科修了。日本IBMに入社。システムエンジニアとして、都市銀行のインターネットバンキング、マルチペイメントネットワークシステム開発などを担当。
2008年にITプラン株式会社を設立。IT戦略コンサルタントとして、製造業の経営ビジョンとITシステムの構築サポートに取り組む。また、中小企業基盤整備機構のチーフアドバイザーとして新規事業の立ち上げを支援。
2019年からは、ITを活用した旅プロジェクトを立ち上げ、地元岡山の魅力を世界に発信し、地域創生の新たな可能性に挑んでいる。
プライベートでは、宴会の幹事やイベントの裏方として盛り上げたり、家族や子供とゴルフを楽しんだりするのが大好き。
※画像をクリックするとAmazonに飛びます
【こんな記事も読まれています】
・【会員限定動画】サプライウェブで実現するマスカスタマイゼーション時代の企業戦略
・製造業における購買・調達業務とは？課題の解決方法も紹介
・ビジネスや技術のトレンドに反応しながら進化を続けるCRMの事例を紹介