業務システム導入の種類と特徴
業務システム導入には様々な種類がありますが、大きく分けて「受託開発」と「パッケージ」を利用する形式があります。
「受託開発」はユーザのニーズに沿って開発できるため、ニーズはほぼ実現できます。ただその会社向けだけに作るので、納期まで長期間を要したり、費用が高くなりがちです。
受託開発の開発手法としては、ウォーターフォール開発とアジャイル開発があります。
・ウォーターフォール開発
要件定義（設計）⇒詳細設計⇒開発のようにフェーズで切っていく導入方法
・アジャイル開発
細かい単位で機能を開発し、ユーザと同意をとりながら導入する手法
ドキュメントではなく開発テストを繰り返しながら導入していく。
一方「パッケージ」はユーザニーズは最大公約数で満たすこととなりますが、公約数の幅はだいぶ広がってきています。また費用は比較的リーズナブルかつ短期で納品が可能です。
パッケージを利用する場合、そのまま導入するノンカスタマイズとパッケージに追加のアドオン開発する形式があります。
・ノンカスタマイズ
市販のパッケージに手を加えず、そのまま導入する方法
SaaSなどもここにあたる。
・カスタマイズ（アドオン開発）
市販のパッケージにユーザ要望の機能を追加開発して導入する方法
これから説明するCRPという導入手法は、その特性上、パッケージ形式での採用が主体となります。
CRP（Conference Room Pilot：カンファレンスルーム・パイロット)とは
ではCRPとはどういうものなのでしょうか。「CRP（Conference Room Pilot）」は、実機・実データで業務運用の実現を評価できるプロトタイプ型のシステム導入手法です。
Conference Room（会議室）とPilot（試みる）の頭文字をとってCRPと言われています。会議室で試みるという意味で、要するにプロジェクトチームによる事前検証を行うことを指します。あらかじめ導入設計時に検証することになります。
ユーザ／ベンダー間にある業務・システム理解の乖離、ユーザのシステム習熟度、課題確認手法など、システム導入における課題解決に貢献できる手法です。
一般的なウォーターフォール型の導入課題
ウォーターフォール型の導入はパッケージでも一般的です。まずは要件定義を行い、設計をしていくわけですが、ベンダー側とユーザ側のやり取りは机上打ち合わせ中心となります。そこで要件確認・設計する上で課題として生じるのが、ベンダーとユーザの認識違いです。一つの言葉をとっても、ベンダーとユーザの認識には少なからずギャップがあります。
例えば「外貨管理がしたい」という要望があったとします。
ユーザが意図している外貨管理とベンダーが認識している外貨管理の概念が違っている場合もあります。
- 👨ユーザ：外貨管理＝取引入力、外貨データ、為替予約、為替差損益自動計算 という要件を実現したい！
- 👩💻ベンダー：外貨で取引入力できればOK！
ユーザとベンダーそれぞれの「外貨管理がしたい」の意味するところが違い、ユーザのほしいものができないという事態になりかねません。
要件確認・設計時点で、ベンダー側の業務知識や説明能力、さらにはユーザ側のシステム理解力に依存することになります。またテキストで書かれた設計書をたとえ読み違えていても、稼働直前まで分からないという問題点もでてきます。ベンダーの主張としては「言われたことは（理解の範囲で）やりました」となるでしょう。
業務フローの変更などを行った場合、データ移行後、稼働直前で初めて入力し、受入検証・試行稼働で手戻りが発生すると致命的です。リスクとして費用の増大や納期の大幅遅延、また単なる旧システムの焼き直しで終わってしまうことも考慮しておかねばなりません。
齟齬が生じにくいCRPによる導入
一方CRPは導入早期に実機・実データで検証を行い、パッケージ標準機能と実業務を比較しながら進められる導入方法です。ユーザのデータを登録してトレーニングを行い、実際に使用しながら業務要件の確認、対応方針の検討などを行っていきます。パッケージの標準フレームワークと業務を比較し、業務フロー改善の検討が可能となります。
CRPではシステム上で業務を可視化しながら要件定義ができるため、この段階で齟齬が生じにくくなります。また本稼働までシステムを使い続けることになり、ある程度システムに習熟することが可能です。打ち合わせに出ることだけでなく、実際に使うことで利用するユーザのシステム稼働への関心やモチベーションを維持することにも役立ちます。
本稼働前に検証が済んでおり、習熟もある程度できるため、稼働直前に現場に大きな負担をかけずに、担当者の導入負担を大幅に軽減することができます。
CRP 実際の進め方
コンサルタント、ユーザ両者が画面や帳票という目に見える共通のツールで会話をしながら進めます。帳票のラインや欄をどうするか、本当に必要なものかどうか等をパッケージシステム上で行うため、齟齬が少なくなり、検証もすぐに行えます。さらに変更依頼が具体的かつ明確に行うことができます。
CRPのデメリット
まずはコスト面からみていきます。
・コスト
CRPでは要件定義フェーズで1回、実装で1回と実質的に導入を2回行います。そのため、CRPなしでうまくいった場合のウォーターフォール型導入より若干工数がかかります。ただCRPなしの導入の場合、成功するか失敗するかで費用や納期に大きなブレが生じます。万が一導入を失敗してしまうことに比べればCRP導入はトータルリスクは低いと言えます。
成功したCRPなし導入 ＜ CRP利用 ＜＜＜ CRPなしで失敗した導入
次に業務フローの問題で、CRPが実施できない場合もあります。
・業務フローのカバー率
要件定義段階で実機を使うため、システム化範囲の業務フローがパッケージの機能と して実装されていないとユーザ側が確認し、業務イメージ を想像することができないため、CRPが実施できません。主要業務フローの8割以上がカバーされているのが最低ラインと考えます。
パッケージの一部が完全に欠落しているがCRPをやりたい場合、まずはその部分だけを開発してからCRPを実施するという考えもあります。
ビジネス・アソシエイツ CRPに関する体制
私たちビジネス・アソシエイツでは、業務要件の可視化をタイムリーに実現できるパッケージシステム Plaza-iを20年以上にわたり提供しています。
- ワンソース
業種・業態別パッケージではなく、ビジネス・アソシエイツは対象となる業種・業態についてすべて一つのプログラムで提供しています。パッケージでの自由度が高まるため、方針決定などにおいてCRPで確認できる範囲が広がります。 - ビジネスロジックのパラメータ化
この選択をした時だけ出てくる機能・画面というように出し入れができる設計としています。 - ユーザーズガイド
ドキュメントに集約することで、機能を知らなくてもユーザーズガイドを見れば、ある程度実装できるようにしています。
またCRPを10年以上実施してきたので、CRPの導入に長けたコンサルタントによる導入ノウハウを蓄積してきています。またCRPに関してバックアップ・レビュー体制ならびに、CRP導入コンサルタントの育成をPlaza-iの導入を通じて行ってきました。
CRPのようなプロトタイプ型の導入を検討される際には、その導入方法に通じたコンサルタントがいるかどうかも、システム導入を成功に導くため、選定の際に確認されるとよいかと思います。
