さらに、この会社の従業員がこれらのプロセスを実行するための環境を設定することは非常に重要です。 これはビジネスプロセス規制と呼ばれます。
したがって、CRMの実装に取り組むとき、私は個人的に次の一連のアクションを順守します。これはすべての同僚にも推奨します。実際に私の利便性と活力を証明しました。
- ビジネスプロセスの説明。 この段階で、作業は紙の上または便利な環境で行われます。 最も重要なことは、開発者と顧客の両方にとって明確な何らかのスキームまたはアルゴリズムを取得することです。
- 調整。 受け取ったビジネスプロセスの説明は、会社の経営陣と合意します。 この段階では、経験豊富なビジネスコンサルタントまたは開発者が特定のプロセスの最適化を提供し、問題のある問題をすべて明確にすることもできます。
- 実装のための環境の選択。 ビジネスプロセスの詳細な説明は、問題の明確な声明と考えることができます。 そして今、将来の作業のアルゴリズムが明確な場合、開発者は独立して、または顧客と共同で、さらに作業を実行する環境を選択できます。 CRMシステムに直接。
多くの場合、CRMシステムの選択は、ソフトウェア製品のコストと特定の会社の従業員のスキルを考慮して事前に行われます。 この場合、選択したCRMシステムの機能を考慮して、ビジネスプロセスの説明をすぐに作成できます。
そして、これらの問題を解決するための2つの異なるアプローチについてお話したいと思います。これらのアプローチは、すべての一般的なCRMにある程度実装されています。
- ビジネスプロセスのプログラミング。
- ビジネスプロセスを「描く」。
これらのアプローチの違いは、名前から明らかです。 最初のケースでは、開発者はアルゴリズム化と特定の一連のコマンドを使用し、CRM環境で一連のコマンドとしてさらに実装します。 2つ目は、ビジネスプロセスはグラフィックフローチャートの形式で表され、チームはオブジェクトと矢印の形式で表されます。 これらの自動化オプションのそれぞれについてもう少し見てみましょう。
ビジネスプロセスの自動化の問題を解決するためにBPMSシステムを使用することは検討しません。興味のある方はここで読むことができます 。
ビジネスプロセスプログラミング
この方法は、ZOHO CRMやSaleforce CRMなどの一般的なシステムで使用され、Step by Stepテクノロジーを使用したビジネスプロセスの実装で構成されています。 「ステップバイステップ」。
同時に、プログラムを作成する前にアルゴリズムを作成するときと同じように、任意の便利な形式でビジネスプロセスを設計できます。 しかし、すべてのプロセスは、アクションと条件の段階的なシーケンスの形で実装されます（各ブランチはほとんどの場合、新しいプロセスです）。
この場合のプロセスの説明は、1つまたは別のCRMの環境で採用されているコマンドを使用してテキスト形式で作成されます。 したがって、このアプローチはプログラミングと呼ぶことができます。
ZOHO CRMの例を次に示します。 オブジェクトには主に2つのタイプがあります。
- ワークフローでは、さまざまなフィールドに応じてこのアクションまたはそのアクションを設定できます。
- 承認プロセスは、特定の承認プロセスを定義します。 このようなプロセスをいくつか追加することができ、それらは次のように機能します。 各プロセスについて、実行時、承認者を指定できます。 そして、それに応じて、システムはプロセスの動作を制御します。
承認プロセスの例 
ワークフローの例 
したがって、ビジネスプロセスは、特定のオブジェクトで実行する必要があるアクションのシーケンスと、特定のアクションを実行する条件に応じて条件を決定することで定義されます。
このアプローチでは、グラフィカルな表記はなく、あるアクションから別のアクションへの段階的な移行のみがあります。 また、ビジネスプロセスで何かを変更する必要がある場合は、グラフィックブロックや矢印ではなく、値とコマンドの特定のリストを作成する必要があります。
このアプローチについて、アルゴリズムの説明はテキスト形式で実装されていると言えます。 たとえば、ZOHO CRMで特定のProvelプロセスを使用する場合、次のように指定する必要があります。
- それが機能するときの基準。
- 誰が承認すべきか。
- 承認後に実行するアクション（タスクの作成、システム内でのアラートの送信、SMSの送信など）。
- プロセスが承認されていない場合はどうなりますか。たとえば、何もしない、コメントを付けて改訂のために請負業者にタスクを返すなど。
一部のシステムでは、そのようなプログラミングは特定のオブジェクト、ほとんどの場合、取引に厳密に結び付けられています。 たとえば、Megaplanでビジネスプロセスを説明する機会は、この方法で実装されます。 トランザクションを介してのみ、特定のケースで何が起こるかを指定できます。ビジネスプロセスのユーザーと参加者のすべてのアクションは、特定のトランザクションに必ず結び付けられます。 他のシステム、たとえばZOHO CRMでは、トランザクションとシステム内の他のモジュールの両方にアクションを添付できます。
業務プロセス図
このアプローチは、たとえばBitrix24 CRMや1C CRMに実装されています。 ここでは、これらのシステムの特定の内部形式ですべてのビジネスプロセスを描画する必要があります。 そのため、Bitrix24には「ビジネスプロセス」という独自の概念があり、このセクション内には、ビジネスプロセスを描く必要がある表記があります。
Bitrix CRMのビジネスプロセスの例 
この表記はBitrix24プログラマーによって作成されました。このシステムにビジネスプロセスを実装するには、この表記でそれらを描画する必要があります。 CRMはBitrix24システムのモジュールの1つにすぎないため、Bitrix24では、システム全体を操作するときのアクションのシーケンスだけでなく、トランザクションを操作するときの個別のアクションも記述できることを理解することが重要です。
同様に、1C CRMは独自の表記法を実装していますが、これはBitrix24プログラマーが作成した表記法とは異なります。 また、グラフィカルアプローチに準拠する他のシステムでは、完全に独自の開発が使用されるか、システムのニーズに合わせてサードパーティの開発者からのグラフィック表記が使用されます。 そして、システムで正しい作業を行うたびに、表記法を事前に検討する必要があります。
1C CRMのビジネスプロセスの例 
実践では、標準的な要素が豊富にあるにもかかわらず、グラフィカルな表記法の学習には、ビジネスプロセスをテキスト形式で記述するためのルールを理解するよりも時間がかかります（最初のアプローチ）。 さらに、テキストアルゴリズムを使用してCRMシステムでアクションの1つまたは別のシーケンスを作成するには、ほとんどの場合、便利なコンストラクターと多くのヒントがあります。これにより、開発者は、環境を予備的に調査することなく必要なプロセスを実際にプログラムできます。
アプローチの長所と短所
最初のアプローチの主な利点は上記のとおりです。開発者にとって非常に便利であり、表記法を深く勉強する必要がなく、プログラマや開発者にとって通常の方法でビジネスプロセスをアルゴリズム化できます。
このオプションの明らかなマイナス：ユーザーの可視性の欠如。 同時に、調整のための便利な環境で開発者が顧客のビジネスプロセスのグラフィカルな図（ブロックと矢印の形式のブロック図）を作成し、プログラミングを実行し、結果をユーザーに慣れさせることを煩わせることはありません。 すべての開発者がアプリケーションを作成およびファイナライズするときにこれを行うように。
さらに、便利で合理化されたビジネスプロセスでは、通常、会社自体のスキームの変更の導入に関連するまれなケースでいくつかの変更が必要です。 したがって、素人の視界の欠如と修正の難しさは、実際には重大な問題ではありません。 ほとんどの場合、既製のシステムを使用している顧客は何年も働いており、会社の作業スキームが変更されたときに変更が必要になります。通常、ビジネスプロセス、システム。
2番目のケースでは、1CおよびBitrix24 CRMの作成者によって考案された表記が使用されます。 一方で、このアプローチは明確で理解しやすいため、ユーザーにとって非常に便利です。 一方、それを使用するには、1CまたはBitrix24の表記法を学習するために追加の時間を費やす必要があり、これらのシステムでの作業に関する情報はあまり必要ありません。
もちろん、各システムにはドキュメントとヘルプのいくつかのセクションがありますが、特定のイデオロギーはありません。 開発者が提供する情報はすべて、ベンダーのドキュメントです。 つまり 表記法を学習するために、ユーザーにはシステムのビジネスアナリストや経験豊富なユーザーからのソリューションではなく、システム開発者の観点からの簡単なガイドが提供されます。 したがって、そのような作業方法がプロセスを視覚化する能力を開発したこと、およびなじみのない表記法に迅速に適応する能力を持っていることは非常に有用です。
グラフィカルアプローチのもう1つの欠点は、表記がシステムの動作能力に課す重大な制限です。 プログラミングするとき、柔軟性と機能ははるかに高くなります。
その結果、私は個人的に、より柔軟なシステムを使用することを好みます。 ビジネスプロセスをプログラミングします。ビジネスプロセスを調整する段階でグラフィックス（フローチャート）を作成することにより、お客様に可視性を提供します。これは、通常IDEF 3またはBPMNで行います。 。 ここでの主なことは、顧客との相互理解です。
一方、会社のビジネスプロセスが比較的単純で、プログラマではないユーザーがプロセス自動化の作業を行う場合、グラフィカルなアプローチの方が便利です。 ビジネス分析とITに精通しているユーザーでさえ、ビジネスプロセスを表すグラフィカルバージョンがユーザーにとってはるかに理解しやすいという理由だけで、プロセス図を明確に「描画」し、表記法で階層を定義できます。 そのようなツールが設計されているのは彼らのためです。 プロセスを正しく実行するために描画することですが、プログラマを引き付ける必要があります。 グラフィカルな表記法を習得することは、プログラミングプロセスよりも簡単であると考えられています。 ここでは、柔軟性とプログラミングの容易さ、ユーザーの可視性、開発者の参加なしにビジネスプロセスを変更する能力など、誰もが自分の好きなものを自分で決定します。
