IT戦略の進め方について
IT化の主要な目的は、「企業の継続的な発展をさせること」であり、そのためには「売上拡大」と「コスト削減」の両方を実現するIT戦略を遂行する必要があります。
IT戦略によるIT化は大きく3つのメリットがあります。
1.業務効率化
代表的な事案が、情報の多重入力がなくなることです。部門ごとにシステムがバラバラな場合は、同じ情報を複数回入力しなければなりませんが、その効率化が図れます。
また、在庫回転率の分析ができるようになることで、不要な発注削減や、余剰在庫、不良在庫を見つけ出して保管費用、在庫処分費用を圧縮し、コスト削減に貢献することができます。
2.経営判断・意思決定の迅速化
IT化により、売上、粗利益、粗利益率をはじめ、各種データがスピーディーに確認できるようになります。そのためには、遅滞のない日々のデータ入力が欠かせなくなりますが、それが実現できればデータ分析が迅速に行えるようになり、利益を上げるための経営判断、意思決定がスピードアップします。
3.コア業務への集中化
業務効率化によって、社員はよりやりがいのある有益な業務へ注力できるようになります。
■RFPの策定
実際にIT化を進める上では、RFP（Request For Proposal）の策定が重要になってきます。
システム検討や導入の際によく耳にする「RFP」という語。これは、日本語訳すると「提案依頼書」となります。発注側企業のIT担当者や情報システム部門の担当者が、システムインテグレーターやシステムベンダーに対してシステム構築・リプレイスを依頼する際に、自社システムに必要な要件や実現したい業務（解決したい課題とあるべき姿）などを示す書類です。システム発注の際には必ず策定すべきものです。
RFPは、IT化を進める会社自身が主体となって進めるのが望ましいですが、リテラシーやリソースの関係でプロジェクトの遂行のハードルが高い場合があります。その場合は、ITコーディネータなどの専門コンサルタントに伴走してもらいながら進めていくという方法もあります。
それも難しいという場合は、ITベンダーに任せるという選択肢もありますが、可能な限り自社で方向性は決定していくような進め方をお勧めします。
■RFP回答書
RFPの内容をITベンダーが、RFP回答書という形で提出する流れが一般的です。RFP回答書を見るポイントとしてしては2点あります。
①標準機能で要件に対応できるか
→パッケージシステムによる提案の場合、その標準機能で要件に対応できるか否かを確認します。
②カスタマイズで要件に対応できるか
→パッケージシステムの標準機能でなく、カスタマイズで要件に対応するかどうかを確認します。カスタマイズの場合、別途構築や構築後の更新運用などを検討する必要がでてくるため留意が必要です。
言い換えると、提案してきたITベンダーにおける、パッケージシステムの得意・不得意は、RFP回答書である程度把握できるということになります。
■ITベンダー担当者の途中交代
ITベンダーのエース級の社員は、契約フェーズ以降になると担当交替する場合が結構あります。交代後の担当者との相性は未知数になるため、せめて要件定義フェーズまでは担当してもらえるかなど、事前に交渉しておくことが望ましいと言えます。
■ITベンダーとの契約
2020年12月にIPAが、 情報システム・モデル取引・契約書（ 第2版）を公開しました。これにより、システム開発プロセスがフェーズ分けされ、契約の大半が、 法律行為以外の事務処理を委託する 「準委任契約」になりました。
具体的には、以下のように示されています。
・パッケージ型システム：ライセンス契約 ※同時アクセス数、インストール数、利用者数
・カスタマイズ部分の開発：請負契約
・要件定義・設計の実施支援、データ移行作業、導入支援：準委任契約
陥りがちな留意点としては、同じITベンダーにしか発注しない状態（ベンダーロックイン）があります。相見積もりやプレゼン開催などで、数社と打合せや調整を行う時間・費用があるために、そのプロセスを省略してしまいがちですが、1社のみのお付き合いとなると、競争原理が働かず、コストや品質の点などのリスクが高まりますので、少なくとも、数社のITベンダーと調整していくことをお勧めします。
その後、システム開発を実際に進めていくことになります。
■システム開発
①要件定義
・FIT＆GAP分析
②基本設計・詳細設計
③プログラミング
④マスタ作成
⑤導入
⑥受入テスト
※要件定義だけではなく、RFPに合致しているかを確認する。
⑦並行稼働テスト
※現場負荷がかかるため、人員を増やすなど適切なサポートが必要
※判定会議_必ず経営層に参加してもらう
⑧本格稼働
※現場からの要望については、 丁寧に対応しつつも、「安易なカスタマイズを避ける」というのが基本姿勢
※テスト時で再びカスタマイズ要望が出た場合、緊急性があれば、対応するが、基本的には本格稼働の後、業務が落ち着いてから対応するのが望ましい
※要件定義は、システム詳細の議論がメインのため、全体像をデザインしたRFPに立ち返ることが重要
-------------------------------------
