CRMパッケージの効果的な選定・導入方法

パッケージの利点は平均的なユーザー要求を取り入れていることだ。ユーザー要求を事細かにヒアリングする手間を省くことができる。CRMパッケージの有効な選定・導入方法について、幾つかの視点から述べてみる。

公開 2008年12月22日 08時00分

更新 2024年04月09日 13時15分

[オープンストリーム]

印刷する

自社のビジネスの進むべき方向を再確認する

　どの企業でも自社のビジネスに合ったパッケージを選定したいと考えている。しかし、パッケージ選定をする際によく見受けられるのが、自社の現状のビジネスに適合するパッケージを選ぼうとすることだ。パッケージを選定してしまってから機能不足を嘆いても手遅れの場合が多いため、CRM（顧客関係管理）の場合は自社の現状そして今後の顧客サービスに必要な機能を十分に検討する必要がある。従って、パッケージ選定よりも先に自社の「顧客サービスのあるべき姿」や、それに合わせたビジネスプロセスの再構築を重視すべきだ。

　2、3年先の自社の「顧客サービスのあるべき姿」を定義し、企業の関係者で十分に共有した上で、「パッケージの選定」というプロセスに入る必要がある。ここでいう「顧客サービスのあるべき姿」とは、CRM導入前に見極める2、3年先のビジネスのゴールを意味する。例えば、「顧客情報と顧客集客のためのイベントをひも付けて徹底した顧客の囲い込みを実現する」とか、「顧客の将来的なビジネスの企画や計画を管理しながら、具体化するタイミングに合わせてタイムリーな提案を実施する」などの施策を意味する。

　その次に重要なことは、パッケージを購入した後のベンダーの保守体制などを十分に検討することだ。「顧客サービスのあるべき姿」を定義しても、ビジネスはいずれ硬直化し、システムも陳腐化していく。ビジネスの変化とともに発生するシステムのバージョンアップや改修という作業に、ベンダーがユーザーサイドに立ってどこまで対応してくれるかが重要な要素になる。

パッケージの選定手順

　パッケージ選定においては、細部にわたる情報を各方面より入手する必要がある。開発元、販売元の情報・実績から保守・運用体制を調査するとともに、パッケージ製品自体の機能、さらにパッケージ製品が選定基準に合致しているか否かを細部にわたり検証することになる。おおむね以下のような項目を重点的に調査し、比較することになる。

業務適合性
機能拡張性（柔軟性）
稼働環境の拡張性
ベンダーサポート
導入実績

　特に重要なことは、現場で発生する作業に適したパッケージを選定することである。これは1の「業務適合性」のことで、標準機能だけで現場作業をどこまで実施することができるか、これがパッケージ導入の一番重要なポイントとなる。

　CRMパッケージにおける業務適合性とは、例えば、

「クレーム管理」機能によって、過去のクレームと対策を管理できるか
既存顧客だけでなく「見込み客」の管理や案件の確度まで管理ができるか

などのほか、「名寄せ機能」など作業の効率化に及ぶものまで多様である。

　ただし選定作業が各論に陥ってしまうと、時間を必要とするだけでなく、目標実現に最適なパッケージが選ばれなくなり、当初の「顧客サービスのあるべき姿」を無視した選定に至ってしまう可能性がある。

プロトタイピングとフィット＆ギャップ分析

　筆者はパッケージを導入する前段階でのプロトタイプ検証では、以下のような3段階にわたるフィット＆ギャップ分析（※）を勧めている（図1）。

（※）フィットギャップ分析─＠IT情報マネジメント用語辞典

図1●フィット＆ギャップ分析での実施内容

　3段階で分析を進めていくことで、各段階でパーケージの機能を細かく理解できるだけでなく、課題ややるべき作業を共有することができる。これは、パッケージ導入プロジェクトのスケジュール進行を円滑に進めるための一助となるとともに、一定の品質を維持することにもつながる。

　特にCRMパッケージ導入においては、「顧客管理」「納品管理」などといったCRM本来の機能と、後続する「受注」「出荷」「納品」までの基幹系機能との情報連携は重要なポイントである。CRMパッケージで顧客管理だけに注力しても自社のサービスの向上は達成できないため、やはり日常のサービスの状況を基幹系システムから取り入れる仕組みについてチェックしておくことは重要なポイントである。

他システムとの連携

　パッケージ導入において、金額面でも工数面でも最大となるユーザー要件は「パッケージが標準で搭載していない機能が欲しい」という要望である。時にはパッケージ導入に要する費用の30％程度のアドオン要件が発生することもある。独自の帳票や管理機能など、標準機能だけではビジネス上のボトルネックになるような機能を要求されることがある。この場合、一般的にデータベースや共通機能のインタフェースは上位互換が保たれるが、モジュール構成や内部仕様が変わるため、パッケージ上で開発したアドオンは大きな影響を受けることになる。

　そこでパッケージのアーキテクチャ上でアドオン機能を開発するのではなく、パッケージとデータ連携を取りながら、パッケージの外部にアドオン機能を位置付けることを推奨する。企業独自の機能やパッケージに搭載されていない機能をサービス化し、SOA（サービス指向アーキテクチャ）環境上で開発することにより、柔軟なシステム構築を行うことが可能になる（図2）。

図2●CRMパッケージと他システムとのデータ連携

　図2の上部は、CRMパッケージのプログラム修正や追加開発を検討したものだが、この場合、CRMパッケージのバージョンが変わると動作確認や作り直しが必須となってしまう。しかし図2の下部では、パッケージの外部に追加機能を位置付けることで、パッケージ自体は変更やバージョンアップをスムーズに行うことができるとともに、他システムとの連携の際も影響が少ない。特にCRMパッケージでは、顧客にひも付く「納品情報」や「過去の納品履歴」などを基幹系システムと連携するような要求が多く見られる。また、SaaS（Software as a Service）型CRMを導入する場合にも同様な要求は多いので、この場合はサービス提供ベンダーと実現策について相談する必要がある。

標準機能でビジネスをどこまで実現できるか

　今回、筆者が特に述べたかったことは、パッケージを導入する際に、「パッケージそのものに何かの機能を追加し、より便利な機能に向上させようと考えるべきではない」ということである。パッケージの標準機能だけで自社のビジネスをどこまで実現できるか、そのことに最大限注力するべきで、それこそがパッケージ選定の重要なポイントとなる。

　どうしても追加機能が必要な場合は、前述したようにパッケージの外部に位置付けることを推奨する。パッケージが標準で持つ機能をそのまま生かすことが、本来の活用方法である。