ビジネスソリューション|超上流工程|仕様の変更追加|工程の後戻り|システム化計画|要件定義

 

精緻な要件定義(業務運用設計)

 

トラブルの発生を未然に防ぐ精緻な要件定義(業務運用設計)

トラブルの発生を未然に防ぐ精緻な要件定義(業務運用設計)
 
弊社は精緻な要件定義(業務運用設計)を行うことによって、「工程の手戻り」をなくし、システム開発における3大トラブル「予算超過」「納期遅延」「ユーザーニーズとの乖離」を未然に防ぎます。
 
一般的には、「システム化方針の策定」「システム化計画」「要件定義」が超上流工程とされているようですが、弊社では、超上流工程はシステム化ありきではなく、まず事業ありき業務ありきから始めることが大切だと考えています。
 
弊社における超上流工程の構成は、事業上/業務上のニーズや課題、及び、その前提となっている現行のビジネスモデルやビジネスプロセスを分析して、解決のグランドデザインを描き、グランドデザインを具体化する精緻な要件定義(業務運用設計)を行うという3段階となります。
 
 

システム開発における3つの大きな課題

システム開発における3つの大きな課題
 
システム開発には「納期遅延」「予算超過」「ユーザーニーズとの乖離」という3つの大きな課題がつきものです。

どうしてそうなってしまうのでしょうか?
 
要件定義から本稼働に至るまでのシステム開発のあらゆるフェーズにおいて、仕様の変更や追加による工程の後戻りや追加が発生するからです。
 
では、仕様変更/追加とそれによる工程の後戻りはどうして発生するのでしょうか?
 

何故工程の戻りや追加が発生するのか?

何故工程の戻りや追加が発生するのか?
 
ある大手企業IT部門幹部のお話によれば、その原因は「IT部門のBAスキルが不足しているために、エンドユーザー部門からの業務要求に対して経営視点事業視点での精査ができず、正確なシステム化要件が作成できないため、エンドユーザーが欲しいと言っているものをそのままベンダーに投げることになるが、ベンダーもまたBAスキルが十分とは言えず、従ってエンドユーザーの業務要求と実現手段(システム化)の間に乖離が発生し、乖離があるまま開発が始まってしまうことにある。」とのことですが、これは特定の企業に限ったことではなく、一般的な傾向ではないかと考えられます。
 

では、どうすればいいのか?

では、どうすればいいのか?
 
こういった事態を避けるためには、経営視点事業視点により細部に至るまで精緻に考えられ、且つ、経営サイドやエンドユーザーサイドが分かる言葉で書かれた業務及びシステムに関する詳細な要件定義(業務運用設計)が必要になります。
 

問題発生の源は要件定義の行間に存在する

問題発生の源は要件定義の行間に存在する
 
通常の要件定義は粒度が粗いため、見る人によって“解釈の幅“が生じ、その”解釈の幅“がシステム開発の段階に至って、「仕様の変更や追加」となって表面化し、仕様の変更や追加がパッチワークを生み、パッチワークが不具合発生の温床となったり、納期遅延/予算オーバーを招いたりするのです。
これはスクラッチだけでなくERPやパッケージのカストマイズの際にも発生することです。
 
又、解釈の幅があると、ITベンダーは見えない部分があるため、リスクヘッジを考えて予算と納期の見積りを過大にするという副次的な弊害もあります。解釈の幅が生じない業務要件定義を行うためには、業務フローや画面/帳票、あるいは、マスター、データベース、コード体系といったものの論理設計が含まれている精緻な業務運用設計書を作成する必要があるのです。
 
そのような業務運用設計書があれば、経営サイド、エンドユーザーサイド、ITベンダー等関係者の全員が、どんなシステムができるのかについて詳細に共有することができるため、システム開発においても工程の後戻りが発生せず、システム開発全体を早く安く仕上げることが可能となります。
又、それを元に現場の人も参加して机上運用検証を行い、OKとなったら「業務運用設計書」をRFPとしてITベンダーに渡せば、ITベンダーもリスクを見込んでおく必要がないためギリギリの価格を出せることになります。
 
弊社は解釈の幅が生じない「業務運用設計書」を作成し、スムースなシステム開発をサポートします。
<<株式会社エイチ・アイ・コーポレーション>> 〒106-0031 東京都港区西麻布4-8-29-305 TEL:03-6451-1711 FAX:03-6451-1710