「Flexbbyパラメトリックを設計する際、既存のイベントハンドラーとプラットフォームアクションを使用して、組織内のほとんどのプロセスをカスタマイズする機能を実現しました 。
また、Pythonで記述されたアドオンスクリプトの形式で追加のビジネスロジックを開発する機能も追加しました（システムでの使用は、ルールよりも例外である可能性が高い） 。
「当社のシステムは数十種類のイベントを処理しますが、お客様に固有のケースが発生した場合は常に拡張します。他のほとんどのシステムは、作成と変更の2つのイベントのみを処理します 。
「新しいプラットフォームは、非標準的な何かが発生した場合、無制限の数の異なるアクションを形成する機会を提供し、特定のイベントが発生した場合にPythonスクリプトを記述して実行できます。 」
「私たちの新しい開発は、ビジネスオートメーションの仕事を根本的に変えました。現在、クライアントごとにプログラミングを行う必要はありません。午前中にクライアントと会い、夜に完成したアプリケーションをテストします 。 」
ただし、10回伝えるよりも1回見せたほうが良いでしょう。
単純な電子文書管理では、組織のニーズを満たすことができません。 顧客はビジネスアプリケーションの従来の機能に満足しなくなり、ビジネス管理に関連するタスクを解決するためのツールを手に入れたいと考えています。 そして、管理は会計よりもプロセスのアプローチです。
現在、ITオートメーション製品の機能開発は傾向を示しています。
•ユニバーサルBPMシステムはますます人気が高まっているため、企業の完全に異なるエンドツーエンドプロセスを自動化できます。
•古典的なEDMS、CRM、ERPシステムは、プロセス管理機能を獲得し始め、会計システムのみではなくなりました。
•一部のシステムの機能は他のシステムに浸透し始め、ドキュメント管理サブシステムを備えたCRMシステムまたはプロセス管理サブシステムを備えたERPシステムを見ることができます。
EDMSを補完する人気のある機能は次のとおりです。
•自動請求および行為の作成。
•主要財務諸表の文書を収集するプロセスの自動化。
•取引相手の承認プロセスの自動化。
•契約上の義務の履行に対する制御の自動化。
•契約に基づく支払いスケジュールの制御の自動化。
レビューでは、新しいFlexbbyパラメトリックプラットフォームに基づいて、次の自動化の可能な領域を検討します。
| 面積 | プロセス/ドキュメント |
|---|---|
| オフィス/記録管理 | 着信、発信、委任状、プロトコル、注文、内部規範文書、注文、サービスノート、説明ノート、注文など |
| 契約作業 | 契約テンプレートの調和、契約の調和、カウンターパーティの調和、契約履行の監視、契約の更新と自動更新 |
| 電子アーカイブ | 文書の紙コピーの保管、文書のストリーム入力（紙文書のデジタル化）、オリジナルのアプリケーション |
| 財務書類 | 行為の作成、請求、会計書類の原本の受領の管理、支払い管理の自動化。 予算管理 |
| 販売、CRM | クライアントベースとの連携、リードとの連携（リード）、トランザクションとの連携（販売機会）、注文と販売の連携、アクティビティとの連携 |
当社の新しい開発により、ビジネス自動化の作業が根本的に変わりました。 現在、各クライアントのプログラミングを扱う必要はありません。 朝にクライアントと会い、夕方には完成したアプリケーションをテストしています。
Chancelleryから順番に始めましょう。これは典型的なEDMS機能です。
簡単な例を見てみましょう- 「着信文書」 。
Flexbby Parametricを適切に構成するには、顧客で受信ドキュメントを操作するプロセスの簡単な分析を行う必要があります。 システムのほとんどのサプライヤは、おそらく簡単にカスタマイズ可能なソリューションを提供しており、社内のプロセスで考えられるすべての機能を考慮に入れることができます。 このプラットフォームでは、ビジネスプロセスは 「ツリー」の形で登録されるのではなく、ネットワークとして構築され、新しい接続をいつでも作成でき、ビジネスロジックの構成を変更できます。 そして、これはプログラムコードの改良を必要としません 。したがって、すべての変更は、アプリケーションの使用期間全体を通して本当に迅速かつ費用効果的に導入されます。
典型的なプロジェクトは次のとおりです。
•コンサルタントが最初にプロセスを説明します。
•プロセスを設定するための要件をおそらく満たすシステムが選択されます。
•長くて苦しいセットアッププロセスが始まります。
•システムの機能を考慮して、プロセスが再設計および再構築されます。
製品（Flexbby Contracts、Flexbby Sales、Flexbby Service、Flexbby One）のカスタマイズおよび変更メカニズムを設計する際、 すぐにアジャイルアプローチを投資しました 。
•システムの検査と実装の時間を大幅に短縮します。
•プロセス所有者との最初のインタビューの後、システムでそれらを構成します。
•初期段階では、会社のプロセスがシステムの機能に違反するリスクを予測します。 プラットフォーム内でのプロセスの変更または新しいモジュールの作成 について 、 十分な情報に基づいた決定を下します。
Flexbbyパラメトリックを設計する際、 既存のイベントハンドラーとプラットフォームアクションを使用して、組織内のほとんどのプロセスを構成する機能を実装しました。
また、Pythonで記述されたアドオンスクリプトの形式で追加のビジネスロジックを開発する機能も追加しました（システムでの使用は、ルールよりも例外である可能性が高い）。
ただし、10回伝えるよりも1回見せたほうが良いでしょう。
最初に、複数の顧客と連携する際に「着信文書」プロセスを検証した結果を説明します。
ドキュメントは次のプロセスを通過します。
このプロセスの役割*：
• 秘書は、入ってくる文書を登録する従業員のグループです。
• ヘッド -これは、ドキュメントを解決し、請負業者とレビュアーを任命する従業員です。
• 知り合いは、入ってくるドキュメントに慣れる必要がある従業員です。
• 請負業者は、対応する発信レターを準備し、着信レターで作業を行う従業員です。
- 役割は、特定の従業員（フルネーム）に割り当てるか、このポジションを保持している特定の人（会社の従業員）を参照せずにスタッフユニット（ポジション）に割り当てることができます。
Inboxを使用するためのパイロットソリューションをテストする段階で、 いくつかの重要なポイントを特定しました。
- 各受信ドキュメントには特定のカテゴリがあり、それに基づいて、ContractorとReviewerを自動的に追加するためのルールを構成できます。これにより、Contractorsを任命したManagerを大幅にアンロードできます。
- 受信文書を遡及的に登録する必要がある場合もありますが、すべての従業員がこれを実行できるわけではありません。
- 入ってくるドキュメントは時々 Contractsに分類されました 。 したがって、それは条約の目的に関連付けられなければなりませんでした。
- ドキュメントを入力する際のユーザーエラーを最小限に抑えるために、 多くのチェックを構成する必要がありました。
システムでドキュメントタイプのプロセスを設定する前に、2つのディレクトリ（状態とロール）を構成します。
Statesはシステム内の単純な参照であり、すべてのプロセスで同じです：
ロールを構成します。
Flexbby Parametricの利点の 1つは、プロセスが個別に構成さ れ、ドキュメントタイプに関連付けられることです。 カスタマイズされたプロセスは、無制限の数のカスタムドキュメントタイプに使用できるため、 カスタマイズのコストが大幅に簡素化および削減されます。 通常、ドキュメントが移動する会社では、3〜4つのテンプレートプロセスが強調表示されます。 基本的に、ほとんどのドキュメントは、パラメータとテンプレートがわずかに異なります。 したがって、プロセスを一度セットアップしてから、制限なしでドキュメントで使用および再定義できます。
次に、受信プロセスをセットアップします 。
これは、システムで構成されたプロセス図の外観です。 括弧内の数字は、この州にある文書の数を示しています。
実装されたシステムの動作バージョンから意図的にスクリーンショットを撮ります。
赤いボックスは、どこにも移行のないドキュメントが米国にあることを示しています。
システムは柔軟性があり、ドキュメントがプロセスに沿って移動している場合でもプロセスを再構成できます。ビジネス管理者は、スタックしているドキュメントを追跡でき、実行可能なプロセスで実行するための一時的な設定を行うか、オプションとしてシステムから削除したり、アーカイブします。
設定の主なものは、 プロセスでの役割の設定と遷移の設定です。
Rolesを設定することから始めましょう。
システムのグローバルディレクトリでロールをすでに定義しています。
次に、特定のプロセスについて、このロールを実行できるユーザーを決定します。
システム内のユーザー、組織の従業員、特定の従業員（フルネーム）を参照せずに常勤単位にすることができます。
特定の従業員を設定すると、その従業員が解雇された場合、彼に届いた文書はこの従業員の決定を待ちますが、そのような状況では、システムは決定または代替の条件付きまたは無条件の委任の可能性を提供します。
次に、プロセスに移行が構成され、 移行を実行できるロール/ロールが定義されます。
移行については、移行が実行される初期状態と最終状態が決定されます。
遷移の場合、遷移ボタンの名前が決定されます
および移行の結果は、ドキュメントの履歴に記録されます。
次に重要な設定は、移行条件です。
許可されたメンバー
このオプションを使用すると、この移行を完了する必要がある参加者の人数を構成できます。
最も単純なケースは、1人の参加者がいて、彼だけが決定を下す場合です。
しかし、特に多くの権限が中間管理職に委任されている多くの組織では、たとえば3人のうち2人がこの決定を下す必要があります。 この場合、コスト要求は、あなたのレベルの少なくとも2人のマネージャーによって確認されます。 3人のコーディネーターを追加するように従業員を設定できます。2人がドキュメントを確認した場合、3人目の決定を待たずに行動を続けます。
達成率
この設定を使用して、移行を完了するために必要な意思決定者の割合を設定できます。 100％に設定すると、プロセスのすべての参加者がこの決定に投票する必要があります。
最大割合
多数決により採択された決定。
最優先メンバー
この設定により、参加者の優先度に基づいて遷移に関する決定が行われるように、遷移を構成できます。 ドキュメントを承認する過程で、他の参加者が別の決定を下した場合でも、マネージャーにドキュメントを調整する権利がある場合があります。
参加者がいない場合の自動転送
特定のネゴシエーション状態がスキップされるようにプロセスを構成できます。
たとえば、テンプレートの合意は、それに対する不一致のプロトコルがある場合にのみ、弁護士と会計士によって合意されます。 したがって、Flexbby Parametricハンドラーを使用して、契約開始者がプロトコルをアップロードした場合にコーディネーターの追加を構成できます。
プロトコルがロードされていない場合、システムは自動的にテンプレート契約に同意し、署名のために送信します。
この決定を行うときにダイアログを閉じます
決定が行われたときにドキュメントのダイアログ（ウィンドウ）を自動的に閉じるように構成します。
二度目の決定の場合に参加者の決定を覚えておいてください
決定を思い出すことができます。 これは、ドキュメントが輪になって回ることができ、投票した人の意見が考慮されなくなった場合に必要です。
すべての参加者の決定を待つ
他の条件に従って、移行基準（必要な有権者の割合など）に達した場合でも、参加者のすべての決定を待つ可能性を構成できます。
プロセスのレビューを終了します。 いくつかの興味深い設定と「ユースケース」がありますが、これについては別の投稿で説明します。 たとえば、専用の役割「契約管理者」がいて、契約を任意の州に移動する権利があるが、通常のユーザーはこの参加者をプロセスに表示する場合、契約プロセスの設定を解析できます。 実装のプラクティスでは、ユーザーが多くの間違いを犯すため、プロセスへのそのような参加者が必要であり、そのためプロセスが停止したり、間違った方向に進んだりすることが示されています。
次に行う必要がある設定は、ドキュメント自体のタイプを構成することです。
以下のパラメーターは、文書タイプのセットアップで定義されます。
- ドキュメントが通過するプロセス （上記で設定）：
以下で個別に説明する通信のタイプは 、Flexbby Parametricプラットフォームの非常に重要な要素です。 これにより、システム内のオブジェクトとDocuments内のオブジェクトの役割との関係を柔軟に構成できます 。 範囲-多国間契約または複雑なb2b販売。買い手に加えて、取引に関与する3〜4つの法人があり、売り手はすべての関係者の影響を考慮する必要があります。
- 次に、 ビジネスルール 、 インターフェイス 、 ファイルタイプ 、 印刷可能なフォームテンプレート 、 パラメーターが構成され、 プロセスロールの参加者が再定義されます。
各アイテムについて、複数ページのテキストを書くことができます。いくつかのケーススタディに限定します。
そして、 通信設定から始めます 。
前述のように、着信ドキュメントは個人または法人に関連付けられます。また、任意の契約に関連付けることもできます（これはたとえば）。
最初に、 リンクロールが設定されます。 この場合、「From who」と「Contract」の2つのロールを構成する必要があります。
「From」ロール-検討中のケースに3人の参加者を含めることができます（この場合、これらはオブジェクトクラスであり、Flexbby Parametricの詳細を別の投稿で強調する予定です）。
ロール内には多くの設定がありますが、詳細については説明しません。
通信ロールの主な構成は、オブジェクトを選択することです（システム内のPythonで記述されています）。 つまり、Connectionsを使用すると、追加のコード開発なしでプロセス内のオブジェクトを接続し、ビジネスロジックの処理を提供できます。
利用可能なオブジェクトクラスのテーブルの例 ：
Pythonで実装されたクラスをシステムインターフェイスに表示する例：
次に、 コミュニケーション自体を構成します。これは、オブジェクト設定（ドキュメントタイプ）で既に示されています。
関係は、オブジェクトのクラスによって定義されるロールで構成されます。 リンクインターフェイスでの表示の優先度、リンク内のオブジェクトの最小および最大許容数、オブジェクトテーブルの表示でリンクを非表示にする機能、およびリンクトランスフォームが示されます。 非常に重要な機能：あるドキュメントのプロセスが別のドキュメントを生成するとき、たとえば、契約から自動アカウントが作成されるとき、あるオブジェクトの接続が別のオブジェクトのリンクに自動的に変換されるように変換が設定される必要があります。
コミュニケーションが提供する設定と機会については、別の投稿で検討します。
結果は、オブジェクトのカードを見ると、コミュニケーション設定が「From who」+「Contract」の場合：
契約なしで「誰から」だけの場合：
接続により、システム構成の柔軟性が向上し、顧客のビジネスロジックをカスタマイズできます。これは、システムを設計する場合でも想像するのが困難です。
たとえば、ある顧客は、オフィスサービス契約をオフィスレンタル契約にリンクし、有効なオフィスレンタル契約がない場合、オフィスメンテナンス契約を締結できないようにする必要がありました。
または、さまざまな国にある法人を通じて販売し、経営陣により接続されている顧客会社があり、取引ではどの法人を通じて支払いを行うかを示す必要がありました。 特定の会社の選択に基づいて、請求書が作成され、目的のルートに沿って送信されました。
そしてもう一つのケース。 すべての売り手がすべての法人を通じて販売できるわけではなく、売り手が彼に承認されていない法人を示した場合、そのような取引には追加の承認が必要でした。
カスタマイズ可能なオプション
ドキュメントカードに表示されるさまざまなタイプのフィールドのセットを設定できます。
ドキュメントカードに表示される内容の例：
設定での表示方法。
すべてのパラメーターのリスト。
1つのパラメーターを設定する例。 以下に、ビジネスプロセスロジックを設定するときにパラメータ値を処理する方法を説明します。
イベントハンドラーとアクションは、 Flexbby Parametric の基盤です。
ハンドラーは、システムで発生するイベントを監視し、 条件に応じて特定のアクションを実行します。
私たちの経験が示すように、イベントハンドラの概念を使用してビジネスシステムを作成および拡張することは、はるかに簡単です。 ケースを考慮せず、疑わしい場合でも、後で別のハンドラで追加できます。 たとえば、特定の種類の契約で仕様の新しいバージョンが作成された場合、企業のチーフエンジニアに通知する必要があります。
「Requests the answer」が選択されている場合は、受信ボックスへの応答の日付を入力する必要性を処理する単純なハンドラーを分析してみましょう（これらのパラメーターを入力した少し高い）。
プロセスが状態を変更すると、イベントによってトリガーされます-イベント「移動」。
私たちのシステムは数十種類のイベントを処理します。お客様でユニークなケースが発生した場合、常にそれを拡大しています。 他のほとんどのシステムは、作成と変更の2つのイベントのみを処理します。
次に、 Conditionsを課し、関連するオブジェクトのフィールドの値を確認します。
そして、ハンドラーをトリガーするための条件と、実行する必要のあるアクションを規定します。
Flexbby Parametricは、非標準の何かが発生した場合、無制限の数の異なるActionを形成する機能を提供します。特定のイベントが発生した場合、Pythonスクリプトを記述して実行できます。
Flexbby Parametricによって処理されるイベント、およびアクションについては、別の投稿でも書きます。
最も重要なことは、オブジェクトカードでどのように見えるかです。
「登録」ボタンをクリックすると、通知が表示され、プロセスはすべてのデータが入力されるまで次のステータスに進みません。
インターフェース設定について少し
Flexbbyパラメトリックでは、条件、プロセスのステータス、ユーザーロールなどに応じて、ドキュメントカードオブジェクトを非表示にできます。 さまざまなビジネスルールを柔軟に構成できます。
この設定は、パラメーターの値に「いいえに設定」という回答が必要な場合、送信ドキュメントテーブルを非表示にします。
ドキュメントカードの外観。
このパラメーターには、「Set to」Yesの回答が必要です。
このパラメーターには、「いいえに設定」という回答が必要です。
最後まで読んでくれたみんなに感謝します。
フレックスビーになろう！