何年も前に、私が若くて世間知らずで、言語が付属していない限り、すべてをゼロから作成したとき、私は2つの場所に2人の営業担当者がいて、リードと連絡先を共有しようとしていました。私はピカピカの新しいハンマーであるPHPを発見したばかりなので、もちろん、今日のMySQLベースの原始CRMシステムとして記述できるものを作成しました。彼らはそれを愛していました-この時点で歴史のほとんどで、すべての競争相手はローカルのAccessデータベースを使用していました。
私はそれ以来、あなたが車輪を再発明しようとしない方が人生がどれほど楽になるかを学びました。私は再び、オンラインCRMシステムを必要とする成長している会社に直面しています。もちろんCRMシステムの機能については大まかに認識していますが、MS DynamicsやSAPのような製品が提供する製品についてはあまり詳しくありません。
私はこれらの企業が何千万ドルとユーロの開発に費やしているものを正確に理解しようとするマーケティングの綿毛を整理するのに苦労しています。それらのほとんどは、OutlookとSharepointの統合や、クリックアンドドラッグのインターフェイスを介してワークフローを作成する機能など、私があまり興味をそそらないいくつかの簡単な機能を備えた、かなり単純なエンタープライズアプリケーションのようです。
だから私の質問ですが、カスタムCRMシステムをゼロから開発しようとするのはおかしいですか?
CRMソフトウェアを作成していたときに雇用主のために働いていたとき、「重要な」誰かが尋ねた
なぜCRMソフトウェアを作成し、既存の大量のCRMパッケージの1つを使用しないのですか?
私が答えた:
非常に多くのCRMパッケージがあるという同じ理由で。
私は説明を続けました、特定の(多くの?)タイプのビジネスには、彼らにとってより効果的であるため、彼らが彼らの顧客に対処したい特定の方法があるということです。 顧客の管理がビジネスのコアコンピテンシー*である場合、なぜ他の誰かが規定した方法/ソフトウェアを使用するのですか(これにより、現在利用できる高度にカスタマイズ可能なソリューションが排除されました)?
最近では、具体的に言えば、利用可能なCRMソリューションの1つ(思い出せないほど安くはありません)のコスト+カスタマイズを行い、それを使用するためのトレーニングにかかる時間は、生産と保守にかかる時間よりも短いです。あなた自身のものはそれから既存のものを得ます。
最善の策は、IMEは、実装するUI /プロセスをモックして、機能やコストと比較するまで、会社が顧客とどのように対応したいかについて、強力な要件分析を行うことです。既存のパッケージの場合、あなたの答えはあなたに明白でなければなりません。
1 *全員says顧客とのやり取りはコアコンピテンシーですが、多くの場合それは正しくありません。 IME、リトマステストは、「コンサルタント」が少なくとも2回自宅を訪問するかどうかです。
独自のものを構築するいくつかの理由:
OTSソリューションが必要なものを提供できる場合は、それらを使用することをお勧めします。既存のソリューションの機能に慣れていない場合は、ベンダーにデモを依頼してください。彼らはおそらくあなたに何かを設定することをとても喜んでいるでしょう、そして実際にソフトウェアを試乗することは光沢のあるパンフレットを読むよりもはるかに優れています。一部のソリューションには、ベースシステムが希望どおりに動作しない場合に必要なものを取得するためのプラグインフレームワークがある場合があります。次に、独自のプラグインをコード化するか、既存のプラグインを購入する(自分で行うより安く/高速であると想定)ことができます。
SAPのCRM実装について話すことはできませんが、Microsoft Dynamics CRM 2011(以前のバージョンではそれほど多くありません)は、印象的なソフトウェア(「エンタープライズ」ソフトウェアに関する限り)です。 CRMソリューションが組み込まれているのは、実際にはアプリケーションプラットフォーム/フレームワークです。一連のコードを必要とせずに、ブラウザーベースのインターフェイスから非常に広範囲にカスタマイズできます。CRMとは関係のないアプリを構築できます。これは、Microsoftの営業担当者が使用するだけの行ではありません。また、(SalesForceのように)クラウドサービスとしても利用でき、ローカル展開と同じようにカスタマイズできます。
私は製品との愛/憎しみの関係があります。これは大きなフレームワークであり、SharePointほど頭を悩ませるようなフラストレーションではありませんが、それでも威圧的で、時には鈍感です。フレームワークで何かを行う方法を理解するのに、最初からビルドするよりも時間がかかる場合があります。また、何があっても、フレームワーク内からうまく実行できないものや、イライラするものがあります。また、パフォーマンスは多くの場合に望ましいものです(それはまったくひどいものではありませんが、決して最適ではありません)。
とは言え、購入とビルドのシナリオと同様に、最も重要なことはビジネスニーズを明確に把握することです。それらを知っている場合は、それらをさまざまな製品の機能にマッピングできます。ギャップを考慮する必要があります。一致するギャップがさらにある場合は、おそらくビルドする必要があります。そうでない場合は、一般的にそれを購入する方が良いオプションです(もちろん、私の意見です)。
基本だけが必要な場合...そして、phpがsugarcrmを使用していることがわかっている場合(オープンソース、無料)
そして、はい、あなたは夢中になるでしょう。
自分でロールしない理由は、まだ発生していない何百もの便利な拡張機能と、まだ作成していない何百ものバグ、既存のソフトウェアですでに解決されている問題です。
最初は、他の人の実装を理解するよりも自分で作成する方が常に簡単に思えますが、その学習曲線は、要件を完全に収集するためだけに行うよりも実際には高くありません。その後でも、コーディングとデバッグを行う必要があります。
少なくとも、オープンソースの実装から始めてください。その半分を捨てても、それはまだ大きな足です。