조달 자동화 아키텍처

구매 자동화는 실제로 무엇을 의미하나요?

"구매 자동화"는 고정된 승인 체계를 통해 구매 요청을 라우팅하는 규칙 기반 워크플로 자동화부터, 사람이 하듯 기존 화면을 조작하는 로봇 프로세스 자동화(RPA), 그리고 문서 이해 또는 대조 로직을 추가하는 지능형 자동화에 이르기까지 다양한 접근법을 포괄합니다. 동료 평가를 거친 연구에서는 RPA를 다음과 같이 설명합니다. 반복적이고 루틴한 비즈니스 프로세스를 자동화하기 위해 로우코드 소프트웨어 프로그램을 사용하는 것을 말하며, 엔터프라이즈 소프트웨어 카테고리에서 가장 빠르게 성장하는 기술로 꼽힙니다.. 이러한 접근 방식 중 어떤 것도 조달-대-결제(procure-to-pay) 프로세스를 대체하지 않으며, 그 내부에서 각각 명확하게 정의된 특정 단계를 담당합니다. 따라서 유용한 질문은 이 프로세스 중 어떤 단계를 구매-대-결제(procure-to-pay) 아키텍처 어떤 업무가 소프트웨어에 맡길 만큼 일상적인지, 어떤 업무에 여전히 사람의 판단이 필요한지 구분합니다.

어떤 워크플로 단계를 가장 먼저 자동화해야 하며, 그 이유는 무엇인가요?

네 가지 단계는 처리량이 많고 규칙의 지배를 받으며 명확한 승인/반려 결과가 나오기 때문에 초기 자동화 후보로 반복해서 나타납니다. 여기에는 구매 요청 라우팅 및 승인, 구매 주문서·입고증·송장 간의 3차 대조(three-way match), 구매 요청 승인 완료 시 PO 발행, 3차 대조에서 식별된 불일치에 대한 송장 예외 처리가 포함됩니다. 현재 조달 벤치마킹에 따르면 자동화는 볼륨 할인 활용, 구매 통합, 그리고 수작업으로 인한 비용 및 오류 감소 능력을 향상시킵니다., 이는 이러한 단계를 최종 목표가 아닌 출발점으로 삼아야 하는 이유에 해당합니다. 동일한 벤치마킹 작업을 통해 진지하게 고려해야 할 조건이 하나 더 추가됩니다. 프로세스 표준화는 속도 향상 추구가 오류 증가로 이어지지 않도록 보장하는 데 도움을 줍니다., 따라서 구매주문서 워크플로 아직 표준화되지 않은 프로세스를 자동화하면 비효율성이 더 빠르게 확산될 뿐입니다. 표준화는 구축 작업보다 먼저 이루어지거나 병행되어야 하기 때문입니다.

자동화된 경로에서 유지해야 하는 통제 항목은 무엇인가요?

수동 구매에서 두 가지 통제 원칙이 변경되지 않고 그대로 유지되며, 자동화된 워크플로는 마이그레이션 과정에서 이러한 원칙이 유지된다고 가정하는 대신 소프트웨어 내에서 이를 구현해야 합니다. 첫 번째는 직무 분리입니다. 권위 있는 연방 통제 지침에서는 이를 다음과 같이 정의합니다. 오류, 오용 또는 부정의 위험을 줄이기 위해 핵심 직무와 책임을 여러 사람에게 나누고, 거래 승인, 처리 및 기록, 거래 검토, 관련 자산 관리의 책임을 분리하여 그 누구도 거래나 이벤트의 모든 핵심 측면을 혼자 통제하지 못하도록 합니다.. 두 번째는 승인입니다. 거래는 권한 범위 내에서 행동하는 사람에 의해서만 승인되고 실행됩니다.. 수동 프로세스에서는 서로 다른 책상에서 구매 주문서를 처리하는 별개의 담당자들로 나타납니다. 자동화된 프로세스에서는 도달할 수 있는 모든 필드에 기술적으로 쓰기 권한이 있다는 이유만으로 봇이나 워크플로 엔진이 임의로 우회할 수 없는 역할 모델, 승인 임계값 구성, 권한 맵으로 나타나야 합니다.

거버넌스 우선 롤아웃은 어떤 순서로 진행해야 하나요?

기존 ERP 연동은 실제로 어디에서 실패하며, 데이터 사일로는 어디서 비롯될까요?

조달 자동화 플랫폼이 ERP에 연결되는 지점은 실무적으로 거버넌스 위험이 집중되는 곳이며, 자동화 솔루션이 ERP를 단일한 공식 기록 시스템(system of record)으로 다루지 않고 공급업체, 예산 또는 승인 데이터의 별도 복사본을 자체적으로 유지할 경우 데이터 사일로가 구축되는 곳이기도 하다. 한 자동화 업체의 통합 가이드에서는 이러한 액세스 위험을 명확하게 지적하고 있다. 기능상 필요한 것보다 더 넓은 권한이 부여된 커넥터는 보지 말아야 할 데이터를 읽고 건드리지 말아야 할 필드에 쓸 수 있습니다.. 광범위한 액세스 권한은 워크플로에 필요해서가 아니라 주로 설정의 편의를 위해 부여되며, 특정 벤더 자체 제품에 대한 주장이라기보다는 테스트해 봐야 할 벤더 소스의 체크리스트 항목으로 다룰 가치가 있습니다. 동일한 가이드에서는 두 번째로 조용한 실패 모드를 언급합니다. 사람의 작업은 기록하지만 자동화된 의사결정은 기록하지 않는 감사 추적은 불완전하며 본격적인 감사에서 지적 사항을 발생시키게 됩니다.. 봇이 인보이스를 승인하는 경우, 해당 결정에는 담당자가 승인할 때와 마찬가지로 적용된 로직, 사용된 데이터, 결과가 무엇이었는지에 대한 동일한 기록이 필요합니다.

검증되지 않은 자동화가 절감액보다 더 많은 비용을 초래하는 이유는 무엇인가요?

자동화를 구축 문제로만 취급하여 도구를 설정하고, 프로세스에 적용한 뒤 출시하려는 유혹이 생기기 쉽습니다. 기초적인 워크플로 검증 연구는 그 사이의 단계를 건너뛰지 말라고 경고합니다. 워크플로 관리 시스템 전반을 연구한 연구진은 다음과 같은 사실을 발견했습니다. 그러나 그 결과 실무에 배포되기 전에 철저히 검증되는 워크플로는 거의 없으며, 이로 인해 오류를 임시방편으로 수정해야 하는 경우가 많고 종종 막대한 비용이 소요됩니다.. 이 발견은 오늘날의 로우코드 자동화 플랫폼보다 2십 년 앞선 것이며, 근본적인 문제는 사라지지 않았습니다. 워크플로 사양은 일종의 로직이며, 실제로 처리해야 하는 선택, 시퀀스, 예외 사항에 대해 검증되지 않은 로직은 사람이 실행하든 봇이 실행하든 동일한 방식으로 실패합니다. 단, 봇은 더 빠르게, 더 큰 규모로 실패할 뿐입니다. 워크플로 명세 언어는 선택의 순간, 순차적 실행, 병렬 처리, 동기화, 반복을 명세할 수 있어야 합니다. 실제 프로세스에는 그러한 모든 요소가 필요하며 예외 없는 정상 경로(happy path)만 테스트하는 파일럿은 워크플로를 전혀 검증하지 못한 것이기 때문입니다.