クラウド内のCRM

こんにちは、Habr！

この記事では、Microsoft Dymanics CRM 2013 Onlineソフトウェア製品での経験を共有します-何をどのように使用できるか、一般的な展開で起こりうる問題、典型的な機能-利点、欠点、最小の費用で問題を解決する方法



提示されたすべての論文は、特定の顧客とシステムを実装する実際の経験に基づいています。 したがって、一般的なタスクの説明を省略し、システムをセットアップしてビジネスの要件に適応するときにほとんどの企業が遭遇する可能性のあるニュアンスに焦点を当てようとしました。 だから...

クラウドはなぜですか？

クラウドソリューションのオプションが魅力的になったとき（私たちの主観的な意見）：

• CRMシステムが必要ですが、「何、なぜ、どのように」という明確なビジョンはありません。
• システムの潜在的なユーザーの数は非常に少ないです。
• ソリューションの展開に必要なインフラストラクチャの不足。
• 新しいソリューションの内部サポートシステムの組織を最適化したい。
• ソリューションを取得（サポート）するための財務コストを最小限に抑える必要があります-ここではすべてが明確です-30日間の試用期間、低サブスクリプションコスト、かなり有利な支払条件（繰延支払）。

その結果、ビジネス要件に拡張および適応できる可能性を備えた「すぐに使用可能な」豊富な機能を得ることができます。 機能や機能の説明に専念する意味はありません。過剰な情報はすべてオープンソースの情報で入手できます。

登録済み。 次は？

さらに、ユーザーを構成します。 また、2つのオプションがあります。CRMオンラインユーザーをクラウドで手動で作成するか、既存のADドメインとの統合を構成します。 Active Directoryとの統合について説明します。



AD統合を使用する利点は明らかです。 管理の観点から-ユーザー、一般的なログイン、およびパスワードを管理するための単一のメカニズムがあります-ドメインとCRMで個別のアカウントセットを維持する必要はありません。 ユーザーが退職すると、CRMを含む会社のすべての情報リソースへのアクセスがブロックされます。 パスワードの複雑さ、不正な試行回数など、同じドメインポリシーを使用することもできます。 ただし、統合を構成するには、追加のリソースが必要になります。

• 同期するだけの場合は、DirSyncソフトウェアを備えたドメイン内のサーバーが必要です。
• シングルサインオン（シングルサインオン）を整理する場合は、ADFSインフラストラクチャが必要です。

お客様は、DirSyncを介したAD同期のシンプルなオプションに満足しています。

ADとの同期のセットアップに関する詳細は、 ページで見つけることができます

メールシステムのセットアップ。

CRM OnlineおよびCRM On-Premisesでのメールの操作は、別の記事のトピックです。 ここで、CRM Onlineの最も完全なメールがクラウドサービスExchange Online、Gmail、Yahooと統合されることに注意してください。 外部コネクタを使用する場合（サーバー側の同期）、CRM Onlineからの送信メールとユーザーメールボックスの同期プロセスには制限があります。 この場合、外部コネクタを介したメール同期が使用されます。

メール設定の詳細については、 こちらとこちらをご覧ください。

初期データの読み込み

アクセスが設定されたら、作業を開始できます。 ただし、原則として、履歴データを新しいシステムに転送する必要があります（または必要です）。 一般的な場合、ここではすべてが簡単です。CRMは主要なオープンデータ形式をサポートしています。また、XML形式のテンプレートをアップロードして、ダウンロードするデータを準備することもできます。



ここにどんな落とし穴がありますか？ 実用的なビジネスケースを検討してください。



CRMは地理的な概念のディレクトリを整理します。 実装は、「連邦地区」-「ロシア連邦の対象」-「和解」という原則に従って、新しいシステムエンティティを作成することで実施されました。 つまり、階層ディレクトリの構造が編成されています。 このようなソリューション（おそらく理想的ではない）は、ユーザーとデータ管理の観点から非常に便利です。 これにより、都市ごとの分析をさらに拡大することができます（たとえば、人口、個人の責任の統合、関心ごとの分類など）。



CRMが準備したテンプレートにはデータが含まれており、システムに正常にアップロードされます。 先に進みます。



現在も、CRMテンプレートに基づいて、会社の顧客に関するデータを準備しています。 各クライアントのデータには、その地理的位置に関する情報が必ず含まれています（連邦地区、ロシア連邦の構成エンティティ、決済）。 ダウンロードを開始します。



ここで最初の問題に直面しています -システムはインポートエラーを生成します（重複データへのリンク）。 問題は何ですか？



しかし、事実は、ロシア連邦の異なる地域に同じ名前の多くの入植地があるということです。 ディレクトリの階層構造を編成したという事実にもかかわらず、ロード用のデータを含むテンプレートを準備するときに、ロシア連邦のどの主題に同じ名前の特定の地域が存在するかを示し、インポートするとき、システムはこの事実を無視し、各フィールドを一意と見なします。 同じ名前の都市が多数あるため、CRMはそのようなデータをロードできません。



状況から抜け出す方法は？ 会社の裁量で、いくつかがあります。

• たとえば、必要なすべての属性を持つ1つの複雑なエンティティの形式で参照情報を整理するための別のシステムが、実践が示すように、「自己」などのコミュニケーションの整理は最良の選択肢ではありません。
• スクリプトを使用したデータ読み込みの編成（適切な技術専門家の関与が必要）;
• 集落の名前の変更：それぞれに一意の名前があり、インポートが成功した後、情報を失うことなく名前を変更できます（これは、データのその後の調整のための追加の作業量です）。

どの方法を選択するかは、各企業が自ら選択します。 主なことは、潜在的な問題を把握し、計画段階で起こりうるリスクを考慮することです。

ところで、 組織と連絡先をインポートするときに同様の問題が発生する可能性があります。 組織の「電話」フィールドと連絡先の「勤務先電話」フィールドに競合が発生する可能性があります（CRMはこのフィールドに同じ値を許可しません）。 出力は、電話番号の異なる値、またはカスタムフィールド（属性）の使用です。

主なCRM機能の完成（製品）

システムのメインセクションの初期セットアップ中に、さらに移動するときに他に何に直面できますか？

靴や衣服を製造および販売する会社の例について、次の実用的なビジネスケースを検討してください 。 原則として、そのような企業は、商品単位の特性のほぼ最小セットで動作することに慣れています。

• 名前;
• 色
• サイズ
• 記事番号;
• 季節

...その他。 これらのフィールドは、製品カードに入力されます。例：

品目番号	お名前	色	サイズ	季節
000142	靴靴	黒人	42	落ちる
000143	靴靴	黒人	43	落ちる

すべてがうまく論理的です。 しかし、残念ながら、将来的には、商業的なオファー、注文、アカウントを生成するために標準機能を使用することができなくなることを理解します。



実際、ドキュメントの仕様に製品を選択する場合、「名前」フィールドのみがその識別に使用できます。 したがって、製品アイテムの同じ名前のリストが表示されます（記事、色、サイズなどは使用できません）。 仕様を扱う標準機能の変更はかなり面倒です。 さらに、セクションごとに個別に変更する必要があります（可能性のある取引、商業提供、注文、請求書）。



はるかに低コストでより普遍的なオプションは、フォームプロパティに登録されるjs-scriptの作成です 。

さらに、製品カードに別のフィールドを導入し、そのフィールド自体の名前を記録し、システムフィールドの名前を「name」から「full name」に変更します。 スクリプトの原則は次のとおりです（例）。「名前」、「色」、「サイズ」フィールドから情報を読み取り、セパレータ（スペース、コンマ）を介して「フルネーム」フィールドにデータを自動的に書き込みます。 したがって、「靴靴、黒、42」の形で商品の一意の名前を自動的に取得します。 この値は、標準のCRM仕様に自動的に表示されます。







このようなスクリプトを作成するには、 string.formatのような関数が適しています。これは.Net形式のマスクを取ります

この関数をソリューションに接続した後、フィールドの形式とリストを受け入れ、値を計算し、フォーマットされた結果を目的のフィールドに書き込む小さなラッパーを作成できます。

function calcName(name, mask, params) { var name = Xrm.Page.getAttribute(name); var vals = []; for (param in params) { var val = Xrm.Page.getAttribute(params[param]); val = val != null ? val.getValue() : ""; vals.push(val != null ? val : ""); } name.setValue(mask.format.apply(mask, vals)); }        .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここに見られるように

'name'はフィールドエンティティ名の名前です

'{0} {1} {2}'-スペースを介して3行を接続するマスク

['etrnova_fullname'、 'etrnova_colour'、 'size']-マスクに置き換えられるフィールドの名前。







結果が達成されました。 おそらく、このソリューションは完璧ではありませんが、簡単かつ迅速です。 さらに、複合フィールドの形成のためのこのメカニズムは、システムの他のセクションに適用できます（必要な場合）。

CRMの写真

ご存じのように、Microsoft Dymanics CRM 2013では、すべてのオブジェクトに写真（写真）を含めることができるようになりました。

ただし、制限があります。

• それらは「画像」タイプのフィールドに保存されます。
• フォームの左上隅にのみ表示されます。
• オブジェクトごとに1つの画像フィールドのみが存在できます。
• 画像サイズは144x144pxに制限されています。

このような制限が連絡先オブジェクト（パートナーの写真など）に影響しない場合、他のオブジェクトの実用的なアプリケーションは非常に条件付きになります（数量制限と小さなサイズ）。



しかし、実際には、画像の数とサイズを制限せずに作業する必要があることがよくあります。たとえば：

• 製品カード（製品画像）;
• 顧客（商品化）。

そのような機能を、どのような方法で、どのようなコストで実装することは可能ですか？ 見てみましょう。



いくつかのソリューションがあり、それぞれに欠点があります。 「写真」フィールドがある子エンティティを作成できます。 JavaScript APIを使用して、写真をリストに表示するフィールド。 このアプローチを使用する優れた商用ソリューションがあります。 このアプローチの欠点は、写真のサイズに関する前述の制限です。 それを回避するために、Base64形式のテキストフィールドに写真を書き込むことができます。 もちろん、これはスペースの過剰な消費につながりますが、写真がそれほど多くない場合、解決策はまったく受け入れられます。

この場合、画像のサイズに制限はありませんが、写真を含むファイルのサイズには制限があります〜500kb; また、写真は144x144よりも大幅に大きくなる可能性があります。



最後に、この制限を完全に回避したい場合は、サードパーティのシステムに写真を保存し 、エンティティ内にリストを表示するインターフェイスを作成できます。 もちろん、このようなソリューションはインストールとサポートの点ではるかに複雑ですが、場合によっては正当化されます。



私たちの場合、2番目のオプションが最も望ましいことが判明しました。一方で、タスクに十分なサイズの写真を保存する機能を提供する一方で、3番目よりも展開するのが難しくないためです。 それを実装するには、Photoエンティティを作成し、その中にストックフィールドを作成します... EntityId、... EntityType、ImageContent、フォーム上に、次のような一連の画像を表示および編集するためのインターフェイスを実装します。











したがって、問題を解決し、システムの機能を拡張することが可能です。 このソリューションを適用できるビジネスタスクはもっとたくさんあると思います。

組織と連絡先

ほとんどの場合、システムが提供する組織や連絡先との作業を整理するための基本的な機能は十分です（通常のシステムツールを使用して可能なパーティションの追加設定を考慮する）。



ユーザーがしばしば遭遇する唯一の不便は、もっぱらわが国の詳細によるものです。 さまざまな理由で、同じ会社に複数の法人が存在する可能性があることは周知の事実です。 この場合、連絡先は同じままです。

残念ながら、標準のCRM機能を使用すると、連絡先を1つの組織のみに関連付けることができます。「親組織」機能の使用は必ずしも便利ではありません。特に、連絡先へのリンクは組織の関連する連絡先ビューに表示されません。

このシステムの欠陥を簡単に回避することは可能ですか？ できます。



実際、「連絡先」フィールドを残して、おそらく「プライマリ連絡先」に名前を変更する必要があります。また、顧客と連絡先の間に多対多の関係を作成することもできます。 フォーム上で、連絡先の編集を表示するために特別なプレートをフォームに追加する必要があります。 メインの連絡先は、プレゼンテーションで使用されるだけでなく、複数の接続をサポートしないグラフを作成するときにも使用されます。







この手順の後、連絡先情報を生成（編集）するときに、リストから複数の組織を選択することが可能になります。

したがって、連絡先カードは、関連付けられている組織を示します。 データを保存すると、指定した連絡先が指定した各組織のリンクビューに自動的に表示されます。

アクセス権の変更

標準のCRMアクセス権システムを使用すると、ユーザー、部門、組織レベル、およびワーキンググループレベルで、情報セクションとレコードへのアクセス権の役割を操作できます。 ほとんどの場合、このユーザー権利管理システムで十分です。 ただし、実際には例外があります。 例-会社には、割り当てられた地域のトランザクションを制御する地域マネージャーがいます。 さらに、会社のスタッフ構造では、すべての地域マネージャーが同じ構造単位にあります。



通常の方法で運用する場合、解決策は次のようになります。レコードへのアクセス権を配布するために「人工」スタッフユニットを導入する必要があります。 これは、一方では技術専門家のサービスに頼ることなく問題を解決しますが、他方では、新しい問題を作成します-CRMの会社のスタッフ構造は既存のものとは異なり、さらにこれらの人為的に作成されたユニットの数は地域マネージャーの数に等しくなります



しかし、この問題を解決する別の方法があり、組織が属する地域（関心、取引）に関する情報に基づいて書き込み許可が与えられます。 これを行うには、まず、CRMアクセスシステムがどのように構成されているかを詳しく見てみましょう。 ユーザーが特定のレコードに対して特定のタイプ（読み取り、変更など）にアクセスしようとするとします。 なぜ彼はそれを得ることができますか？ 次の2つのオプションがあります。

1. ユーザーのロールの中には、エンティティへの必要なアクセスを取得できるロールがあります。
2. ユーザーにアクセスが許可されています（「共有」）。

したがって、エンティティの地域に対応する地域マネージャーの各レコードを「共有」できます。 これは単純な作業であり、地域を定義するフィールドを変更するときに共有アクセスを提供（または削除）する特別なプラグインを作成することにより、簡単に自動化できます。



セクション「関係のタイプ」に注目しましょう。 「Assign」、「Sharing」などの項目が表示され、これらのアクションごとに動作のタイプを決定できます。 たとえば、「共有」アイテムの動作の「カスケード」タイプを選択すると、次のようになります。誰かがエンティティへの共有アクセスを提供すると、子にもアクセスできるようになります。

もちろん、地域のマネージャーには、レコードだけでなく、すべての子レコードに対する権利も与えてください。 これを行うには、比率を構成します。

おわりに

だから

1. すぐに使用できるMicrosoft Dynamics CRM 2013 Onlineは、強力で十分なツールです。
2. Microsoft Dynamics CRM 2013 Onlineには、プログラミングなしでビジネスプロセスとシステムオブジェクトをカスタマイズできるシンプルさと柔軟性があります。
3. 設定では実行できないMicrosoft Dynamics CRM 2013 Onlineの機能拡張は、プログラミングツールを使用して迅速かつ簡単に解決できます。
4. 使用されているテクノロジーとソリューションアーキテクチャにより、ほとんどすべての企業の特定の活動にシステムを適合させ、既存の情報システムとソリューションを統合できます。

この製品は議論の余地があり、曖昧です。一方で、プログラミングに頼ることなく、通常のツールを使用してビジネス要件に合わせてカスタマイズすることができます（UI、データベース構造、ビジネスプロセス）（そして、これがその強さと競争上の優位性です） ） しかし一方で、これはその「弱さ」です-ユーザーはこのフルタイムの機能のフレームワークに巻き込まれ、技術の専門家（つまり、プログラミング）の助けを借りてのみ機能のさらなる拡張が可能です。



このステートメントは、ユーザーインターフェイスのカスタマイズ、ビジネスプロセス、およびシステムの基本ロジックに当てはまります。



すぐに使用できるソリューションは、シンプルなビジネスソリューションとして使用できます。基本的な機能を超える複雑なビジネスプロセスやビジネス要件の場合、残念ながら、改善なしではできません。