- リリース ノート
- 基本情報
- インストール
- 構成
- Integrations
- 認証
- アプリおよびディスカバリー アクセラレータを使用する
- AppOne のメニューとダッシュボード
- AppOne の設定
- TemplateOne 1.0.0 のメニューとダッシュボード
- TemplateOne 1.0.0 セットアップ
- TemplateOne のメニューとダッシュボード
- TemplateOne 2021.4.0 のセットアップ
- Purchase-to-Pay Discovery Accelerator のメニューとダッシュボード
- Purchase to Pay Discovery Accelerator の設定
- Order to Cash Discovery Accelerator のメニューとダッシュボード
- Cash Discovery Accelerator の設定への注文
- 基本コネクタ (AppOne 用)
- SAP コネクタ
- SAP Order to Cash Connector for AppOne
- SAP Purchase to Pay Connector for AppOne
- SAP Connector for Purchase to Pay Discovery Accelerator
- SAP Connector for Order-to-Cash Discovery Accelerator
- Superadmin
- ダッシュボードとグラフ
- テーブルとテーブル項目
- アプリケーションの整合性
- 使い方 ....
- SQL コネクタを使用する
- 便利なリソース
データのボリューム
データの量は、常にパフォーマンスと直接のトレードオフになります。 プロセス マイニングは、プロセス グラフを構築するための詳細に元々こだわりがあります。
ただし、これらの一意のタイムスタンプがすべて設定されている場合は、パフォーマンスに影響します。 一般に、すべてのプロセス マイニング ツールとすべてのインメモリ ツールアプローチの理論上の制限があります。
アプリケーション に使用されるデータのパフォーマンスとコネクタのパフォーマンスを明確に区別 します。ロボットは同じプラットフォームを使用しますが、いくつかの違いがあります。つまり、ユーザー (開発者とエンドユーザー) に受け入れられるものは何か、実行されるアクションの種類です。
大量のデータが コネクタ と アプリケーションの両方に影響を与える可能性がありますが、コネクタ内ですべての問題は解決 できます。
パフォーマンスのエンドユーザーが経験するパフォーマンスは、データ ボリュームに直接関連します。 データ ボリュームは、最大のテーブルの行数によって決定されます。 一般に、パフォーマンスのエンドユーザー のユーザー エクスペリエンスを決めるのは、行の数のみです。 列の数は、データベースからデータを読み込むときにのみ増加します。
プロセスあたりのイベント数は約 5,000,000 件 (500 万件)、最大で約 50,000,000 件 (5000 万件) のイベントが理想的です。 ケースやイベントの数が増えると、データの解析やビジュアリゼーションの表示に時間がかかるようになります。
UiPath Process Mining プラットフォームは引き続き動作しますが、大量のデータが挿入されると、反応速度が低下する可能性があります。事前にデータ量を確認することをお勧めします。 上記の数を超える場合は、データセットを最適化または制限することをお勧めします。
データ量が大きい場合は、主に以下の 2 つの方法で対処する必要があります。
- 最適化;
- データの最小化
最適化では、Superadmin による調整を行うことで、ダッシュボードの表示を高速化できます。その実現には、アプリケーションの設定を特定のデータセットに合わせて調整します (詳細については、「アプリケーションの設計」をご覧ください)。
このセクションでは、データの最小化について説明します。データを最小化する場合は、エンド ユーザーに表示されるデータを、特定の業務の質問に合わせて調整して減らすことができます。
ここで説明する手法は互いに並んで存在することも、複数の技術のメリットを活用するために組み合わせることもできます。 さらに、最小化されたアプリケーションとともに、データを最小化せずにアプリケーションを維持することもできます。より遅いパフォーマンスを許容できる特定の分析では詳細レベルが必要になる場合があるからです。
ツアー データセットに表示されるレコードの数を制限すると、アプリケーションのパフォーマンスが向上するだけでなく、プロセスの理解度も向上し、ビジネスでの承認性も向上します。
データのスコーピングは コネクタ内で行えます。
制限のオプションの 1 つとして、日付や期間をフィルター処理して表示する期間を制限します。 たとえば、10 年間から 1 年間の期間を制限できます。 または 1 年から 1 か月。 以下の画像に例を示します。
特にプロセス マイニングへの取り組みの開始時には、限られた量のアクティビティをお勧めします。 そのため、専門知識の強化にさらに着手できます。
以下に、アクティビティの範囲に関するガイドラインを示します。
範囲 (アクティビティの値) |
説明 |
---|---|
5-20 |
プロセス マイニングを開始する際の推奨範囲です。 洞察を得るために必要な情報を提供する簡単なプロセスです。 |
20-50 |
エキスパートレンジ クリアバリアントで展開する。 |
50-100 |
明確なバリアントがある場合に最も便利です。 これは、やや関連するプロセスを意味しますが、主に独自のプロセスです。 |
100+ |
サブプロセスに分割することをお勧めします。 |
以下に、データのフィルター処理に関する提案をいくつか示します。
- 関係のないアクティビティ: プロセスに直接影響を与えないアクティビティは、除外される可能性があります。
- 第 2 のアクティビティ: いくつかのアクティビティ、つまり変更アクティビティは、プロセスのどこでも実行できます。 これらは大幅に多数のバリアントに吹き飛ばしました。
- 最小限に発生するイベント: データセット内で数回発生するイベントは、フィルター処理されて除外される可能性があります。
- 小規模なプロセス: サブプロセスのみを分析します。
- グループ化アクティビティ: データセット内の一部のアクティビティは、ビジネスにより理にかなっているアクティビティを表す、小さなタスクのようになることがあります。 グループ化するには、コネクタ内にロジックが必要であり、重複するアクティビティが生じる可能性があります。
- 可能であれば、コネクタのパフォーマンス内で コネクタ を使用 してアクティビティをフィルター処理します。これにより、変更を簡単に元に戻すことができます。また、アクティビティを元に戻すことができます。 データ抽出またはデータ読み込みのアクティビティをフィルター処理しないでください。
イベントが多いケース (外れ値) が 1 つの場合、イベント レベルで集計値を計算する式が影響を与えます。 この影響を受けるダッシュボードの項目の [始点/終点] フィルターは、これらの外れ値があるかどうかを計算するのに時間がかかる場合があります。 コネクタ 内でこのようなケースをフィルター処理して、データセットから除外することをお勧めします。
他のインスタンスでは、外れ値がフォーカスする主要な領域である可能性があります。 プロセスが順調に進んでいる場合、または Six Sigma の方法論を採用している場合は、問題に集中したいと考えています。 すべてのケースが正しく表示されるのではなく、問題が起こっているケースのみが表示されます。
以下の画像でご確認ください。
コネクタでは、多くの詳細を持つ属性を削除できます。 たとえば、 Event Detail 属性の長い文字列などです。
多くの未使用の属性の開発が完了すると、データセットに含まれる可能性があります。 コネクタ の出力データセットで使用できる属性の可用性をパブリックに設定することをお勧めします。他の属性を使用可否をプライベートに設定します。
事前集約は、多くの BI ツールで使用され、大量のデータに関する洞察を得るために使用される手法です。 データセット内のレコード数を減らすために、特定の属性に対するデータを集約する必要があります。 BIでは、これは通常、各サプライヤーの値を合計するものなので、各サプライヤーに 1 つのレコードしかありません。
以下の画像でご確認ください。
プロセス マイニングではより多くの設定が必要ですが、最初に必要なのはプロセス バリアントの集約のみです。 各バリアントには、1 つのケース レコードと、関連する数のイベントがあります。 これにより、データ量を大幅に減らすことができます。
正しい結果を表示するには、各バリアントが表すレコードの数も表示する必要があります。イベント終了の場合は、各イベントの中央値の期間を使用できます。 バリアントのみを使用して一結び付けるのは高すぎる可能性があるため、最も一般的なフィルター (バリアント、ケースの種類、ケース終了の月の組み合わせなど) を確認する必要があります (経時的な傾向を示す場合)。
ただし、属性を追加するとレコードの数に対して的な影響があるため、パフォーマンスとユース ケースが慎重にバランスする必要があります。
事前集約は、プロセスの概要とs 一般的なトレンドに最も適用されます。
サンプリングとは、特定の期間内に発生しているケースとそのイベントの割合を取る手法です。 たとえば、すべてのケースとそのイベントの 10% のみが表示されるように設定できます。 この方法では、各ケースがデータセットに表示される可能性が同様に高いため、例外や外れ値が引き続き発生します。
以下の画像でご確認ください。
カスケードサンプリングとは、サンプリング率が一定の割合で経時的に低下する手法です。 たとえば、過去 1 週間のデータの 100% の場合、2 週間前の 90%、3 週間前の 80% などを示します。
データ のシャーディングは、データをスコーピングするソリューションの手法です。組織は、単に 1 つの部分をスライスするのではなく、データを複数のデータセットに分割できます。 アプリケーションをモジュールを使用して分割し、複数の小さなデータセットをコネクタからエクスポートする必要があるため、この設定には追加の設定が必要です。
データのシャーディングでは、元のデータセットは複数のシャードに分けられます。 各シャードが小さいほど、速度は上がります。 ユーザーがアプリケーションにログインすると、該当するデータ シャードだけが読み込まれます。
シャーディングの一般的な単位は 、「企業コード」 または 「部門」です。 たとえば、50 個の企業コードの場合、各シャードには企業コードが 1 つ含まれ、基本的には元のデータセットよりも約 50 倍高速になります。
シャーディングの概要は、以下の画像でご確認ください。