RedmineはCRMソフトとして使えるか?Part2~RedmineをCRMソフトとして使うためのプラグイン
RedmineをCRMソフトとして使うプラグインを調べてみたら、実はかなりたくさんあった。
そのうち、いくつかのプラグインについてラフなメモ書き。
【1】顧客情報を保持するプラグイン
edavis10/redmine-customer-plugin
Redmineの初期の頃に、RedmineコミッタだったEricが作った顧客プラグインがある。
単に顧客情報を登録して保持するだけのプラグインなので、何の役に立つのだろう、と思ったときがあった。
今振り返ると、CRMソフトのように、顧客情報をRedmineユーザとは違うエンティティで保持してチケットと紐づけたい動機があったのではないか、と推測する。
【2】Redmineにアウトバウンドメール機能を追加してヘルプデスク機能を持たせたプラグイン
コンタクト - コンタクト - Redmine CRM plugin demo - RedmineCRM demo
Redmineをヘルプデスクの問い合わせ管理に使いたい場合、問い合わせメールを受信してチケットに自動登録できるインバウンドメール機能はあるが、顧客へ返信したり通知するアウトバウンドメール機能はない。
Help Deskプラグインを使うと、アウトバウンドメール機能をRedmine上で操作できるようになる。
デモ画面で触ってみると、インバウンドメールを受信した内容はチケットに起票されるだけでなく、FromアドレスやTo・CCアドレスもチケットの上部に表示される。
メールによるRedmineのチケット登録機能には、From・To・Ccがチケットに表示されないので、この機能はありがたい。
【3】RedmineにCRM機能を追加したプラグイン
コンタクト - コンタクト - Redmine CRM plugin demo - RedmineCRM demo
RedmineCRM - Premium Redmine plugins, CRM, Helpdesk, Invoices - Redmine plugins
もっと本格的に、RedmineにCRM機能をプラグインとして売り出しているサイトもある。
上記のCRMプラグインは無償でも提供されていて、crm | Posoxの記事によれば、十分に使えるらしい。
(引用開始)
Redmineで顧客管理と案件管理を容易に実現できるPluginを紹介する。
プラグインは公式サイトからダウンロードできる。※Pro版もあるが、無償版でも十分に有用
このプラグインの優れているところは、顧客管理はさることながら、顧客に紐づいた案件管理が実現できることである。
通常案件は会社又は特定の担当者からの受注になる。このプラグインでは、会社からの引き合い、会社の担当者からの引き合いとステータスをそれぞれ管理できるので、より実態に即した案件管理が実現できる。
また、引き合い、受注など任意のステータスを定義し、ステータスごとの合計金額をリアルタイム表示できるので、案件状況のダッシュボードとしても利用できる。
さらに、案件状況をメール、電話、会議などの状況に応じてノートとして追記できるので、案件状態が即座に共有できることも利点の一つである。
(引用終了)
実際に設定画面を見ると、取引カテゴリや取引ステータスを設定できるので、顧客ごとの案件や商談をチケット管理したときに、それらの属性を追加することができる。
したがって、どの案件が受注見込み(受注に至っていないが確度の高い案件)なのか、を追跡することもできる。
RedmineCRMプラグインで顧客ごとの案件情報を一括管理し、裏では受注・売上・請求情報を会計システムと連動すれば、十分に使える可能性はある。
【4】RedmineがCRMソフトになりきれない理由はどこにあるか?
CRMの基本は、顧客管理と営業支援であり、潜在顧客からいかに見込み顧客を抽出して、実際に契約に結びつけるか、という営業を支援することにある。
その一環で、契約後の顧客問い合わせ管理(いわゆるヘルプデスク)やビッグデータによる顧客行動分析があるが、付随的機能だろう。
すると、顧客ごとの案件を管理したくなる。
並行して2つの案件を受注しようとする場合もあるだろう。
また、顧客がユーザ企業であれば、窓口は情報システム部門だけでなく、各部門に分かれていたり、更に窓口担当者も複数人いたりする。
当然、窓口担当者の中でキーマンの人は別格だ。
顧客は単なる「ユーザ」ではないのだ。
RedmineがCRMソフトになりきれない理由は、「顧客」というエンティティをRedmineにマッピングしづらいからだと思う。
CRMで重要なエンティティは、顧客と案件(商談)だ。
その関係は、顧客◇--案件で構造化できる。
案件はチケットに対応付けるのは自然な発想だ。
案件ステータスはチケットのステータスに対応付けられ、案件とチケットのライフサイクルを同一視できる。
不足した情報は、チケットのカスタムフィールドに案件特有の属性を追加すればいい。
しかし、顧客はRedmineユーザなのか、チケットのトラッカーで区別すべきなのか?
Redmineユーザはチケットを扱う担当者を意味していて、顧客ではない。
顧客特有の属性とチケット担当者の属性は当然違うので、Redmineユーザのカスタムフィールドを追加する手法もありうる。
しかし、Redmineユーザとして同様に扱うのは、最終的には無理があるだろう。
Redmineユーザ△--顧客、チケット担当者という継承関係で構造化できるからだ。
顧客の数が少ない場合、顧客をチケットのトラッカーに対応させて、トラッカーで区別するのは良いやり方だと思う。
Redmineの「トラッカー」は単なるワークフローだけではなく、チケットの種類を一意に識別する識別子でもある。
だから、トラッカーに顧客に必要な属性(住所、電話番号、重要顧客区分など)を追加すると良いだろう。
トラッカー単位にチケットをグループ化しやすいし、顧客ごとの傾向も判別しやすい。
しかし、顧客の数が数千規模になるなら、トラッカーを使うのは現実的ではない。
他によくやる方法は、顧客をRedmineプロジェクトにマッピングする方法だ。
例えば、たくさんの顧客のシステムを細々と長年従事している運用保守では、顧客のシステムをRedmineプロジェクトに対応付けて、タスクをチケット管理する。
Redmineプロジェクトは階層構造を持たせることができるので、粒度に応じて階層化すればいい。
しかし、Redmineプロジェクトが多すぎると、逆にチケット管理しづらくなる場合もある。
現実的には、Redmineのユーザグループを取引先企業、Redmineユーザを担当者にマッピングするのがBetterだろうと思う。
そうすれば、取引先企業の情報は、ユーザグループの属性情報として表現できるし、担当者の情報と明確に区別できる。
取引先企業が大企業で、部署ごとに管理する必要があるならば、Redmineユーザグループを取引先業の部署にマッピングすればいい。
結局の所、Redmineのデフォルト機能では、顧客というエンティティをマッピングしづらいのだと思う。
その理由は、Redmineは本来、CRMソフトとして作られたわけではないからだ。
だから所詮は無理がある。
でも、Redmineには、他の業務にもチケット管理を適用してみたいと思わせる雰囲気がある。
もしCRMとしてRedmineを使いたいならば、顧客情報を保持するテーブルを別途作ればいいだけのことだ。
足りない機能は新規テーブルを作りプラグイン化すればいい。
つまり、Railsを操る技術力さえあれば、CRMのうち欲しい機能を実装するのはそう難しいことではない。
今の僕の興味は、チケット管理が適用できる業務はどの範囲まであるのか、もしチケット管理が向いていない業務へ適用する場合はどんな機能を追加すれば実現できてどんなメリットがあるのか、にある。
色々考えてみる。
【追記】
RedmineCRMプラグインのデモサイトの画面キャプチャをリンクしておく。
画面から雰囲気が分かるだろう。
| 固定リンク
「ソフトウェア」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること(2022.02.09)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
「Redmine」カテゴリの記事
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
コメント