DXで日本のビジネスをサポート|ソルクシーズ公認ブログ

ITエンジニアのお仕事&キャリア

『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE27】業務フローで自社の説明責任を果たす

ITエンジニアのお仕事&キャリア

ソルクシーズグループのITコンサルタントが執筆した【ユーザー企業側からみたITプロジェクトのノウハウ本】。
IFC本表紙
この本は、目次※を見るだけで
・今、取り組んでいる / これから取り組むシステム開発のフェーズ
・システム開発で自分が悩んでいる問題
に役立ちそうなRULEを見つけることができます。
※目次は、インフィニットコンサルティングの書籍紹介ページでご覧いただけます。

過去に、編集部Bossが気になる箇所について紹介しました。
【RULE02】ITプロジェクトは人選が運命を決める
【RULE05】企画がダメだとすべてダメになる
【RULE30】社内合意していないRFPは無意味
【RULE57】管理者も仕様から逃げない
【RULE73】その遅延は本当にベンダーのせいか
今回は、現場SEに気になるRULEを選んでもらい、編集長である私:れいが読んで紹介します。経営層であるBossが選んだRULEと比べてみるのも面白いかも。
まずひとつめに選ばれたRULEはコレ。
● RULE27 業務フローで自社の説明責任を果たす
「業務フロー」というのは、自社の業務の流れ(フロー)を、時系列に表現したものです。一般的に部署別に枠を分けて、部署間の情報の受け渡しを明確にするためにも利用されます。
システム開発を依頼するとき、ベンダーに自社の業務を理解してもらうためには「業務フロー」を見せるのが一番、と筆者は言います。
しかし、この「業務フロー」を作成していない会社も多いのです。理由は簡単、「作成するのに手間がかかるから」。初回作成時はもちろん、業務手順や情報に変更があったら更新しなくてはいけません。
大変だから作りたくない、その気持ちはわかります。
では、「業務フロー」がないまま、システム開発を始めてしまった場合どうなるでしょう?
筆者によると、システムを作ってから「業務の流れと合わない」「この処理ができない」という問題は多く発生しているそうです。これは「業務の考慮もれ」が原因。
そして「ベンダーが業務をよく理解していなかったから」と責任を負わせてしまう。
「業務フロー」を作るのが大事、と言いたいわけではありません。ベンダーに自社の業務を理解してもらう手段があることを知り、その例として「業務フロー」を活用しましょう、と提案しています。

ベンダーに自社の業務を理解してもらう努力をしていますか?
ライン パール
『情シス・IT担当者[必携] システム発注から導入までを成功させる90の鉄則』(技術評論社) 4月11日 発売
●本に関する詳しい情報、およびご購入方法は「株式会社インフィニットコンサルティング」の書籍紹介ページでご確認いただけます。

タイトルとURLをコピーしました