(本記事は、太田 記生氏の著書『DX時代に成長する製造業のIT戦略 ITプロジェクトを成功させるためのノウハウ』＝現代書林、2022年10月19日刊=の中から一部を抜粋・編集しています)
IT課題は経営課題である
■ITプロジェクトは現場任せになりがちである
私は、IT戦略やIT化は、決して社内の一部門の課題ではなく、経営課題そのものであると考えています。したがって、IT戦略を進めていく上では、経営戦略と一致させて推進することが不可欠となります。
ところが、実際のITプロジェクトは、現場任せになる傾向にあります。
原因のひとつは、「コンピュータやシステムの話は専門的すぎてよく分からない」ということで、IT部門のメンバーに任せてしまうことです。しかし、そのIT部門のメンバーは、実際はパソコン設定やネットワークトラブルの相談窓口だったりします。
特に、基幹システムなど大規模システムの導入には巨額な投資が伴います。中小企業であっても数千万円規模になることは珍しくありません。投資額の面からも全社的な判断が求められます。
■企業の成長に伴ってITの見直しは不可欠
情報システムのハードウェアは通常、保守期限が5年であり、それが情報システムを入れ替えるタイミングというのが一般的な感覚でしょう。
ただ、事業の成長とともに会社の規模が大きくなると、情報システムが合わなくなってくることもあります。会社が成長していくと顧客が変わり、業務も増えていくからです。会社の規模が小さいうちは手作業でできていた業務が、対応できなくなるのです。
例えば、売上が1億円から10億円へ、10倍になったとしましょう。売上が1億円レベルであれば手作業で処理できていた管理業務が、売上10億円になると追い付かなくなるのは当然です。入力の自動化やデータの共有化を図らないと日々の業務が回らなくなってきます。そのような理由から情報システムを導入して何年か経つと新しいシステムに切り替えるタイミングが訪れます。
基幹システムの更改は、ハードウェアやソフトウェアの保守期限の問題だけでなく、企業の成長による業務量の増大や業務内容の変化にどう対応するか、という課題の解決手段に変わってきているのです。
「システムに業務を合わせる」が基本
■パッケージ型システムのメリット
パッケージ型システムの導入にあたっては、システムに業務を合わせていくほうが、業務そのものも効率化、合理化できます。パッケージ型システムの強みは、多くの企業におけるベストプラクティス1をベースに開発されていることです。
企業によっては、他社で適合したシステムが自社でも適合するかどうか分からないとして、スクラッチ開発するケースもあります。しかし、それには相当のプロジェクト体制を組み、システム開発のための人材と時間と、そして何よりも予算を確保する必要があります。
特に複雑な業務を扱う基幹システムの場合、スクラッチ開発で導入することは、費用対効果とプロジェクト失敗リスクの観点からあまりお勧めできません。それよりも、標準化されたパッケージ型基幹システムを選び、最小限のカスタマイズをプラスするほうが合理的です。
後で触れるRFPの取りまとめにあたっても、重要なのは「システムに業務を合わせる」「パッケージ型システムに業務を合わせる」という発想です。
過去からの業務に固執するより、パッケージ型システムに業務を合わせるほうが、システム導入費用を抑えられるケースが多いのです。業務の見える化を行った結果として、「自社の利益の源泉となる業務」であれば、十分な費用をかけてカスタマイズすべき場合もあるでしょう。企業にはそれぞれ独自の業務内容や業務仕様（販売方法や値付け方法、仕入方法、出荷方法など）が利益の源泉になっていることがあり、そういう業務は残さないといけないでしょう。
そして、カスタマイズの是非については、IT部門の担当者やプロジェクトのメンバーだけでは決めるのは難しいです。カスタマイズの是非の判断は状況によって様々だからです。
ある企業では、約10億円をかけてERPを導入することになりました。そして、導入方針を社内に説明する際、経営者は「カスタマイズはしない」と宣言しました。こういうブレない姿勢が、 IT戦略を成功に導きます。
■パッケージ型システムはそれぞれ導入実績が異なる
パッケージ型システムは、それぞれ導入実績に違いがあります。何十社、何百社、千社以上といった豊富な導入実績を持つパッケージ、数社でしか導入されていないパッケージ、中にはまだ1社しか使われていないのに、パッケージ型と称して販売しているケースもあります。
パッケージ型システムには、それぞれファーストユーザー2が必ず存在します。
ファーストユーザーに向けて開発・提供し、さらに多くの企業に導入して検証・改良を加えていくうち、だんだんと使いやすいパッケージになっていきます。複数の企業のユーザーの意見を取り入れてバージョンアップされていくからです。導入実績がどれくらいあるかは、パッケージ型システムを選ぶ際の判断基準になります。
「1社しか使われていないパッケージ」というのは、ファーストユーザーのベストプラクティスをもとにスクラッチ開発したシステムを、パッケージ型としてこれから拡販していこうというケースです。この場合、ファーストユーザーではうまくフィットしても、他社にはフィットしない可能性があります。
私が本書で述べているパッケージ型システムは、「複数の企業に導入され、安定利用されているシステム」が前提です。導入実績が豊富にあり、バグ3出しも終わっていて、標準的な機能がそろっている。それが理想的なパッケージ型システムです。
導入実績の少ないパッケージ型システムを否定はしませんが、「一般的なパッケージ型システム」とは異なることを十分理解した上で、導入を検討する必要があります。
■現状維持の声を乗り越えていくのが最大の関門
それぞれの企業には、それぞれの業務の流れがあります。業種や業態にもよりますが、何よりそれぞれの企業の業務に対する考え方ややり方が、創業以来長年かけて構築されてきています。例えば、データベースソフトや表計算ソフトを使って生産、販売などを管理している企業の場合、基幹システムの導入に伴い、従来の入力方式やデータの扱い方をそのまま引き継ぐことは不可能です。業務の流れや書式が大幅に変わることになり、現行業務に慣れている現場から反発の声が上がるのが普通です。
会社全体としてIT化の必要性は頭では理解できていても、いざ自分が毎日行っている業務の手順が変わるとなると、誰しも不安を感じるものです。その結果、「今の業務を変えたくない」「今のままがよい」といった声が出てきます。私の経験上、それは1人や2人だけの声ではなく、社内の多くの方から反発の声が上がることもあります。社内の抵抗をどう乗り越えていくかが、企業におけるIT化の最大の関門なのです。
また、現場の担当者は「今の仕事で手いっぱいなので」「うちの部署はあまり関係ないので」など様々な理由を付けてプロジェクトに関わろうとしない傾向もあります。重要なのは、経営者が「会社の未来のために不可欠のプロジェクトである」と宣言することです。
ITプロジェクトには経営層が必ず関与する
■経営者が本気であることを示す
私が関わるITプロジェクトでは、経営層に必ず関わってもらうことにしています。具体的には、経営層の方にプロジェクト会議に出席してもらい、報告や議論を踏まえて意見を求めたり、その場で意思決定していただいたりします。
実際に多いのは、IT担当者とITコンサルタントである私が細かいプロジェクトの進行を担い、経営層には、プロジェクトの節目となる会議に参加していただくというパターンです。
私が経営層に必ず参加を依頼する会議は、社内の各部門へヒアリングをして取りまとめたRFPのレビュー会議です。取りまとめられたRFPは、IT担当者や外部のコンサルタントが独断で作ったものではなく、経営方針に基づき、経営層の承認を得て決定したものであるということを、プロジェクトメンバーはもとより、全社員にはっきり明示するのがその狙いです。
その他、ITベンダーの選定会議や、システム移行の判定会議など、プロジェクトの節目となる会議には経営層に参加していただきます。
■IT化を成功に導くには、軸となる経営ビジョンが重要である
企業にはそれぞれの経営ビジョンがあります。私の経験上、経営ビジョンが社内に浸透している企業は業績がよく、成長力があります。IT化を成功に導くには、経営ビジョンとIT戦略をいかに一致させられるかが鍵を握っています。
経営ビジョンが「年商100億円を目指す」であれば、それを実現するキャパシティーを持つITの導入が必要です。経営ビジョンが「利益5億円」「経常利益率10％」なのであれば、それを目指すにふさわしいITを選択する必要があります。
「スピーディーな経営」をビジョンとして掲げている会社であれば、IT化と日々入力の徹底によって商品別、部門別の粗利益率が月次だけでなく日次でも確認できるようにすべきです。
「働きやすい会社」をビジョンに掲げている会社であれば、IT化とテレワーク等を含めた業務改革によって業務を効率化させ、残業や休日出勤を減らし、社員の定着率アップという成果を目指します。
IT化は経営ビジョンを社内に広く浸透させて、全社で達成するチャンスです。
■ITプロジェクトの前に経営ビジョンを固める
会社として経営ビジョンそのものが固まっていないと、IT化へは入っていけません。ITプロジェクトを進める中で経営戦略とのズレが生じることもありえます。その場合は、ITプロジェクトを中止するケースもあります。私の経験でも、経営戦略からもう一度考え直す必要があると経営陣が判断し、RFPができあがった段階でプロジェクトがストップしたこともありました。
プロジェクトのスケジュールが遅れてしまったとしても、後悔しないためには一度立ち止まることが必要です。プロジェクトが行き詰ったときには、経営戦略、経営ビジョンに何度でも立ち返るのです。
■カスタマイズをコントロールする方法
RFP策定のために現場のヒアリングに出向くと、ITや業務に対する様々な要望や不満が噴出します。その中には宝のような意見もあります。大事にしなくてはいけない意見がたくさんあります。ただ、全ての希望に応えていると、コストが膨大になります。
私はそこでよく、コストについての説明を行います。
「このカスタマイズに仮に500万円かかった場合、費用は貴部門で負担されるのですね？」と確認すると、「それは困ります。そこまでしてやる必要はないと思います」となったりします。
一方、小規模なカスタマイズであれば許容することもあります。
帳票のフォーマットについてのカスタマイズの要望は少なくありません。一般的には1企業1フォーマットですが、大口の取引先との関係上必要であれば、顧客ごとに請求書フォーマットを変えたりします。最近、片仮名の長い会社が増えており、標準機能の顧客マスタでは顧客名が20文字しか入らないので、40文字入れられるようにしたこともあります。
また、その企業特有の情報を扱えるようにするカスタマイズもあります。例えば、納入先ごとに販売単価が異なる場合に対応するため、納入先別単価を追加するケース、受注入力時に与信管理機能を追加するケースなど様々です。
このように、パッケージ型システムの導入では、なるべくカスタマイズを抑えるのが原則ですが、場合によっては柔軟に対応します。一番の判断基準は、そのカスタマイズがその企業にとっての利益向上につながるかどうかです。具体的には、現場の業務効率化が進んでコスト削減につながる、取引先から求められており顧客満足のために不可欠、などです。
2. ファーストユーザー：最初に導入・利用したユーザー企業
3. バグ：プログラムの誤りのこと
中小企業診断士、情報処理技術者(システムアナリスト、ソフトウェア開発技術者)
岡山大学経済学部卒業、同志社大学大学院総合政策科学研究科修了。日本IBMに入社。システムエンジニアとして、都市銀行のインターネットバンキング、マルチペイメントネットワークシステム開発などを担当。
2008年にITプラン株式会社を設立。IT戦略コンサルタントとして、製造業の経営ビジョンとITシステムの構築サポートに取り組む。また、中小企業基盤整備機構のチーフアドバイザーとして新規事業の立ち上げを支援。
2019年からは、ITを活用した旅プロジェクトを立ち上げ、地元岡山の魅力を世界に発信し、地域創生の新たな可能性に挑んでいる。
プライベートでは、宴会の幹事やイベントの裏方として盛り上げたり、家族や子供とゴルフを楽しんだりするのが大好き。
※画像をクリックするとAmazonに飛びます
【こんな記事も読まれています】
・【会員限定動画】サプライウェブで実現するマスカスタマイゼーション時代の企業戦略
・製造業における購買・調達業務とは？課題の解決方法も紹介
・ビジネスや技術のトレンドに反応しながら進化を続けるCRMの事例を紹介