SaaSを導入する場合は、従来のシステム開発に必要だった作業工程の多くを省略することが可能になります。インフラ関連、ミドルウェア関連、アプリ開発、システム運用設計、等等。
よって、短期導入、早期のROIを実現できるわけです。が、実際導入を検討・決定した場合、従来のシステムの開発とは違う新しいものがゆえに、具体的な導入方法が想定しにくいのではないでしょうか。
そこで、システム導入の明確なビジョンと効果設定および組織・プロジェクト体制などの前段は当然固まっていて、さらに、システム連携、個別開発（標準のカスタマイズ機能以外のインターフェース開発やマッシュアップ開発）はなしという前提、、、つまりサービスとして提供されている機能を純粋に利用し導入・展開するまでの工程を整理したいと思います。
1．検討段階で無料試用やデモを利用し、機能やある程度の実現性を検証しておく
ASPとの違いでもある、拡張性・柔軟性が一つのメリットではあるSaaS、とはいえカスタマイズが可能なインターフェース・機能・範囲は限定されています。
利用する業務に適合するかどうか、まず検討段階で”ある程度”検証は必要でしょう。不安にはかられますが、厳密に確認していてもきりはないので、”ある程度”の実現性が見えたら見切り、導入を決定してしまいましょう。（おそらくSaaS検討する方は、機能面以外にもメリットを見出して検討するのでしょうから。）
場合によってはベンダーが提供しているトレーニングやマニュアル等、学習できる機会があれば先に活用して勉強してみるのもいいかもしれません。
2．導入工程
a) 業務要件とのFit&Gap
b) カスタマイズ・設定
c) データやシステム移行
d) ユーザー展開
a) は工程の中でも要になってくるでしょうか。前述の1 でも書きましたが、柔軟とはいえ、業務要件と機能がどの程度適合するか、適合しない部分はどのようにGapを埋めていくかを定義することは重要になってきます。
現状の業務フロー（またはビジネス全体）の中でどのようなところに課題があり、それを解決するにはどのような業務フローで、結果どういった効果を得られるか。
そして業務要件が明確になったところで、フローのどの場面でサービスを利用するか、その際にどのような機能を利用するか、そしてサービスで提供されている機能で充足するかどうかをFit&Gapしていく。
サービスにもよってくるので一概には言えないですが、利用ユーザーと役割（権限）、新・旧の業務フロー、課題・解決策（と欲を言えばKPI設定と期待効果）、大体の利用機能一覧、およびデータやシステム移行の範囲と方法ぐらいはこの段階で明確にしておくといいかもしれませんね。
b) は上記のFit&Gapの結果を踏まえて、実際にサービスの設定に落とし込んでいくわけですが、従来の開発とは違うのは設定内容を画面で逐次確認できるというところでしょうか。いちいち設計・仕様なんて作らず、リアルタイムで設定内容が反映され、結果はネット環境があれば確認可能なので。
なので、カスタマイズ・設定作業は何回かフェーズ分けし、1回毎に関係者に連絡・確認、フィードバック（MTGを開くのがいいかな）を元にまた修正し連絡・フィードバック、といったことを繰り返し行いブラッシュアップしていくという方法がよいのではないでしょうか。
ただ繰り返しもきりがなくなってしまうと元の木阿弥でもあるので、当然ながらスケジュールとフェーズ分けはきっちりと。
c) d) は、必要なデータがあれば移行を（サービスに準じた方法で）行い、システム切り替えタイミングとアナウンス、及びユーザーへの操作マニュアル配布と説明・トレーニングを実施して、はれて稼働といったところでしょうか。場合によってはパイロット試用で一部のユーザーに限定して展開し、段階的に拡大していくといった方法をとってもよいかもしれません。
とまあ、メモ的に簡単にまとめてみました。
最近のコメント