システムを導入するとは？#8（番外編）
生産管理システムの概要を学習し、「生産管理システムの全体は分かったが実際にシステムを導入するために必要なことは何だろうか？」という疑問からスタートした”システムを導入するとは？”
「システムを外注するときに読む本」を参考図書としてまとめてきました。
最後に番外編と称して、第1~7章の全体のまとめてと参考資料を一括でまとめた記事を作成します。
各章の振り返り
各章のタイトルにnote記事のリンクを貼ってますので、詳細はリンク先を確認ください。
総じてこの本では、発注者側もプロジェクトの一員としてベンダに丸投げせず自分ごととして真摯に取る組むべき心得と具体的な検討方法について教えてくれています。
第1章 システム作りは業務フロー図から
＜概要＞
システムを導入するときは、現状のフロー図を作成し、
現状の良い部分（残したい部分）
課題（システムによって効率化したい部分）
を明確にする
＜最も大きな学び＞
業務フロー図を書き課題を抽出する段において、課題を解決した先の効果をしっかり関係者に示し、導入後すぐは業務効率が落ちても中期的な目的を忘れずに進める体制づくりが重要
第2章 発注者がこれだけは知っておくべき最低限のこと
＜概要＞
発注者もベンダのヒアリングに答えれば良い。という他人事マインドでなく、自分の業務を改善することで会社全体が良くなるというマインドに切り替え、システム要件定義書、機能要件定義書、非機能要件定義書をレビューする
＜最も大きな学び＞
発注者側もベンダ丸投げ、情報システム部丸投げという姿勢を改めしっかり関係者を企画段階から参画させておくことが重要。ベンダ側も役割と責任を明確にし、出来上がって運用が回るまでは関係者は離さない。というくらいの強い意思が必要。
第3章 失敗しないベンダの選び方
＜概要＞
ベンダ側のリスク管理能力を見極めることが重要で、ベンダ側の社内で発生したリスクも逐次共有する関係構築が必要
＜最も大きな学び＞
当たり前のようで、お金を出して頼む側、受託して言われた通りにやる側という関係ではシステム導入は進まないということが分かりました。
ベンダ側は開襟し、発注者側は傾聴する。この関係が作れないようであれば目先の売上・利益のためにプロジェクトは受託しない方がよいです。
第4章 社内の協力を得るために
＜概要＞
トップがシステム導入の目的を明確にし、繰り返し関係者に共有し、ステアリングコミッティを実施し関係者に自分事にさせる必要がある
＜最も大きな学び＞
トップメッセージは現場に行けば行くほど時間軸が見えなくなり他人事になりがちです。未来志向のある上司がプロジェクトに参画したメンバーを会社から評価されている、と見なしプロジェクトに専念できるようなマインドが必要
第5章 リスク管理で大切なこと
＜概要＞
第4章と同じく、ベンダ側と腹を割って話関係構築が不可欠
＜最も大きな学び＞
アメリカでは「ベンダのリスクもユーザーと共有すべき」が常識。日本はどうして多数の人を調整する人が低く見られがちなんでしょうか。
この課題は第3部でも持ち越します。
第6章 ベンダとの適切な役割分担
＜概要＞
要所要所でチェックポイント会議を実施しトラブルの顕在化を解決に向けてアクションプラン策定を実施する
パッケージソフトの導入はパッケージソフトの長所を理解して現状を打破しながら、今の良い点は残せないかも考える
＜最も大きな学び＞
この章のパッケージソフトの説明は秀逸でした。所感でも記載しましたが再掲しておきます。
＜6-3 所感＞の再掲
私は「日本人は業務をシステムに合わせるのではなく、システムを業務に合わせる」と長年思っています。だからパッケージソフトでなくカスタマイズソフトが多く、高額な割に結局使えない。と思っています。
まさにこの本でも同じ事を述べていて衝撃でした。「パッケージソフトが他社の良いやり方を自社に取り込む」という目的を果たすという一文は感動すらしました。
とは言え、自分たちの業務を全て壊せない現実に対しても導入前にきっちり業務プロセスで
・パッケージソフトで効率化したい業務
・残したい業務
→カスタマイズで対応できるか
→カスタマイズ出来ないなら、この業務では使わないと割切る
と示しています。100%納得の内容でした。
第7章 情報漏えいを起こしてしまったら
＜概要＞
リスクを完全に防ぐことはできないので、起きた時どうするかという情報のトリアージを実施しておく。また影響度の大きい自体が生じた場合は捨てる覚悟も必要
＜最も大きな学び＞
言わずもがなとても重要な内容です。こちらはコンパクトにまとめていますのでぜひnote記事をご一読ください。
参考：Appendix資料一覧（全11ファイル）
この記事が気に入ったらサポートをしてみませんか？