調達自動化アーキテクチャ

調達の自動化とは実際何を意味するのか？

"調達自動化"は、固定の承認チェーンを通じて申請をルーティングするルールベースのワークフロー自動化から、人間と同じように既存の画面を操作するロボティック・プロセス・オートメーション（RPA）、さらには文書理解やマッチングのロジックを付加するインテリジェント自動化に至るまで、さまざまなアプローチを網羅しています。査読付きの研究では、RPAについて次のように説明されています。 反復的でルーティンなビジネスプロセスを自動化するためのローコードソフトウェアプログラムの使用であり、エンタープライズソフトウェアカテゴリにおいて最も急速に成長しているテクノロジーであるとされています。これらのアプローチのいずれも調達から支払い（プロキュア・トゥ・ペイ）のプロセスを置き換えるものではなく、そのプロセスの中に組み込まれ、それぞれが明確に定義された特定のステップを担当します。そのため、有益な疑問は、このプロセス内のどのステップが 調達から支払いまでのアーキテクチャ は、ソフトウェアに任せるのに十分なほどルーチン化されているか、それとも依然として人間の判断を必要とするか。

どのワークフローのステップが最初に自動化されるのか、またその理由は何か？

早期の自動化候補として4つのステップが繰り返し挙げられます。これらはそれぞれ、高ボリュームで、ルールに準拠しており、明確な合格/不合格の結果があるためです。具体的には、購買依頼のルーティングと承認、発注書・受領書・請求書の3WAYマッチング、購買依頼の承認完了後の発注書（PO）発行、および3WAYマッチングでフラグが立った不一致に対する請求書の例外処理です。現在の調達ベンチマークによると、 自動化により、ボリュームディスカウントの活用、購買の統合、および手作業によるコストやミスの削減の能力が向上する、これがこれらのステップを出発点として扱い、野望のすべてとはしない理由です。同じベンチマーク作業により、真剣に受け止める価値のある条件が追加されます： プロセスの標準化は、スピードの追求がエラーの増加を招かないようにするのに役立つであり、したがって自動化とは 発注書ワークフロー まだ標準化されていないものを自動化しても、不整合のスピードが増すだけです。標準化は構築の前または並行して行われなければならないからです。

自動化されたパスは、どのような統制を維持する必要があるか？

2つの統制原則は手動調達から変更されることなく引き継がれるが、自動化されたワークフローでは、それらが移行後も維持されると仮定するのではなく、ソフトウェア上で表現されなければならない。1つ目は職務の分離であり、信頼性の高い連邦統制ガイダンスでは次のように定義されている。 エラー、乱用、または不正のリスクを軽減するために主要な義務と責任を異なる担当者間で分割し、取引の承認、処理と記録、取引のレビュー、および関連資産の取り扱いの責任を分離することで、単一の個人が取引やイベントのすべての主要な側面を制御しないようにします。。2つ目は承認である。 取引が、その権限の範囲内で行動する人物によってのみ承認され、実行されること。手動プロセスでは、これらは別の担当者が別々の机で発注書を確認する作業として現れます。自動化されたプロセスでは、ボットやワークフローエンジンが、アクセス可能なすべてのフィールドに技術的に書き込み可能であるという理由だけで暗黙のうちにバイパスできないような、役割モデル、承認しきい値の設定、および権限マップとして現れる必要があります。

ガバナンスを最優先したロールアウトの順序をどのように設定しますか？

レガシーERPの統合は実際にどこで失敗し、データサイロはどこから発生するのでしょうか？

調達自動化プラットフォームがERPと接続するポイントは、実務上ガバナンスリスクが集中する場所であり、自動化システムがERPを単一の信頼できる情報源（シングルソース・オブ・トゥルース）として扱うのではなく、ベンダー、予算、承認データの独自のコピーを保持し続ける場合にデータサイロが構築される場所でもあります。ある自動化ベンダー自身の統合ガイドでは、アクセスリスクについて次のように明確に述べています。 機能に必要な範囲を超えた広範なアクセス権を付与されたコネクターは、本来見るべきではないデータを読み取ったり、触るべきではないフィールドに書き込んだりする恐れがあります。広範なアクセス権は、ワークフローが必要としているからではなく、通常はセットアップの便宜のために付与されるものであり、特定ベンダー自体の製品に関する主張としてではなく、ベンダー提供のチェックリスト項目としてテストを行う価値があります。同じガイドでは、2つ目の、より静かな障害モードについて言及しています。 人間の行動は網羅しているものの自動化された決定が記録されていない監査証跡は不完全であり、本格的な監査では必ず指摘事項として挙がることになります。。ボットが請求書を承認する場合、その決定には人間による承認と同じ記録（適用されたロジック、使用されたデータ、結果）が必要です。

検証されていない自動化が、節約できる額よりも高いコストを伴うのはなぜですか？

自動化を単なるデプロイの問題として扱いたい誘惑に駆られがちです。すなわち、ツールを設定し、プロセスに向け、リリースするというものです。基盤となるワークフロー検証に関する調査は、その間のステップを飛ばさないよう警告しています。ワークフロー管理システム全般を調査した研究者らは、次のことを見出しました。 しかし、その結果として、多くのワークフローが実運用に投入される前に十分に検証されることが少なく、その場しのぎの修正が必要になり、しばしば莫大なコストが発生するという事態を招いています。この発見は、今日のローコード自動化プラットフォームが登場するより20年も前のものだが、根本的な問題は今なお解決されていない。ワークフローの仕様とは一種のロジックであり、実際に処理すべき選択、順序、例外について検証されていないロジックは、人間が実行しようとボットが実行しようと同じように失敗する。ただし、ボットの場合はより高速に、より大量に失敗するという違いがある。 ワークフロー仕様言語は、選択の瞬間、順次実行、並行処理、同期、および反復の指定をサポートする必要があります。 実際のプロセスにはそのすべてが必要であり、正常系のみを検証するパイロットではワークフローをまったく検証できていないと言えるからです。