자동화 기회 파악
모든 프로세스가 자동화에 적합한 것은 아닙니다. 수동 검토 프로세스가 Omni에 적합한지 확인할 수 있는 신호를 살펴보세요:| 신호 | 중요한 이유 |
|---|---|
| 반복적인 확인 작업 | 동일한 검증 단계가 모든 문서에 적용됩니다 |
| 일관된 기준 | 승인/거부 결정이 주관적 판단이 아닌 정의된 규칙을 따릅니다 |
| 대량 처리 | 팀이 하루/주에 수십 또는 수백 건의 문서를 처리합니다 |
| 인적 오류 위험 | 피로나 일관성 부족으로 문제를 놓칠 수 있습니다 |
| 구조화된 입력 | 문서가 예측 가능한 형식을 따릅니다 (인보이스, 등록 증명서, 서식 등) |
Omni로 자동화할 수 있는 일반적인 프로세스
- 인보이스 검증 — 금액, 날짜, 벤더 정보, 항목별 합계 확인
- 벤더 온보딩 — 사업자등록 문서 검증 및 AML 감시 목록 심사
- 컴플라이언스 서식 검토 — 필수 필드가 존재하고 유효한지 확인
- 사업자등록 검증 — 기업 정보 추출 및 교차 확인
- 계약서 검토 — 주요 조건, 날짜, 당사자 정보 확인
- 직원 문서 확인 — 제출된 자격증, 라이선스 또는 신분증 검증
Omni는 명확하고 문서화 가능한 규칙이 있는 프로세스에서 가장 잘 작동합니다. 검토 프로세스가 주관적 판단이나 문서화할 수 없는 기관 지식에 크게 의존하는 경우, 완전 자동화보다는 부분 자동화가 필요할 수 있습니다.
SOP를 Omni 워크플로우에 매핑하기
다음 다섯 단계를 따라 수동 프로세스를 Omni 워크플로우로 전환하세요.현재 수동 프로세스 문서화
Omni에서 무엇이든 구축하기 전에, 팀이 현재 검토를 어떻게 처리하는지 정확히 기록하세요:
- 누가 검토를 수행합니까?
- 어떤 문서를 수신합니까?
- 각 문서에서 무엇을 확인합니까?
- 어떤 결정을 내립니까 (승인, 거부, 에스컬레이션)?
- 검토 후 결과는 어디로 전달됩니까?
입력 문서 식별
검토를 위해 제출되는 모든 문서 유형을 나열하세요. 구체적으로 작성합니다:
- PDF 인보이스인가요? 스캔된 사업자등록증인가요? 스프레드시트인가요?
- 케이스당 여러 문서가 있나요, 아니면 하나뿐인가요?
- 문서 간 교차 참조가 필요한가요?
승인/거부 기준 정의
팀이 수행하는 각 확인 항목에 대해 정확한 기준을 작성하세요:
- 문서가 승인되려면 무엇이 필요한가요? (예: “모든 필수 필드가 존재하고 합계가 항목과 일치”)
- 문서가 거부되는 조건은 무엇인가요? (예: “인보이스 날짜가 미래” 또는 “사업자등록이 만료됨”)
- 시니어 리뷰어에게 에스컬레이션되는 조건은 무엇인가요? (예: “AML 심사에서 일치 항목 발견” 또는 “핵심 필드를 읽을 수 없음”)
자연어 정책으로 작성
이전 단계의 확인 항목과 기준을 구조화된 정책 문으로 결합합니다. 번호가 매겨진 단계와 명시적인 언어를 사용하세요.템플릿:자세한 예시와 모범 사례는 정책 작성 가이드를 참조하세요.
실제 사례
다음 예시는 수동 검토 프로세스가 Omni 워크플로우로 어떻게 전환되는지 보여줍니다.예시 1: 인보이스 검토
이전: 수동 프로세스
이전: 수동 프로세스
재무팀 구성원이 각 인보이스 PDF를 열고 수동으로 확인합니다:
- 벤더명과 인보이스 번호가 존재하는지
- 인보이스 날짜가 적절한지 (미래가 아니고 90일을 초과하지 않는지)
- 항목별 금액이 명시된 합계와 일치하는지
- 세금 계산이 정확한지
- 시스템에 중복된 인보이스 번호가 없는지
이후: Omni 워크플로우
이후: Omni 워크플로우
정책:엔진: Text Verifier - Glove (모든 필드 추출 및 검증)출력 스키마:결과: 검토 시간이 단순한 인보이스의 경우 5-10분에서 수 초로 단축됩니다. 팀은 플래그된 케이스만 수동으로 처리합니다.
예시 2: 벤더 온보딩
이전: 수동 프로세스
이전: 수동 프로세스
새 벤더가 온보딩될 때 컴플라이언스 담당자가:
- 사업자등록증에서 회사명, 등록번호, 설립일을 검토합니다
- 대표자의 신분증을 확인합니다
- AML/제재 데이터베이스에서 대표자 이름을 수동으로 검색합니다
- 문서 간 기업 정보를 교차 확인합니다
- 결과를 스프레드시트에 기록합니다
이후: Omni 워크플로우
이후: Omni 워크플로우
정책:엔진: Text Verifier - Glove + AML Search - Person출력 스키마:결과: AML 심사가 자동화되어 즉시 처리됩니다. 문제없는 케이스는 자동 승인됩니다. 컴플라이언스 담당자는 플래그된 벤더에만 집중합니다.
예시 3: 컴플라이언스 문서 확인
이전: 수동 프로세스
이전: 수동 프로세스
컴플라이언스 팀이 제출된 규제 문서를 검토합니다:
- 모든 필수 섹션이 존재하는지 확인합니다 (헤더, 서명, 날짜, 라이선스 번호)
- 만료일이 미래인지 확인합니다
- 문서가 올바른 기관에 발행되었는지 확인합니다
- 참조 번호가 내부 기록과 일치하는지 검증합니다
이후: Omni 워크플로우
이후: Omni 워크플로우
정책:엔진: Text Verifier - Glove (완전성 및 필드 정확성 검증)출력 스키마:결과: 만료된 문서가 자동으로 감지됩니다. 리뷰어는 이름이 부분적으로 일치하거나 섹션이 모호한 엣지 케이스만 처리합니다.
효과적인 출력 스키마 설계
출력 스키마는 각 분석에서 반환받는 구조화된 데이터를 결정합니다. 다운스트림 시스템을 염두에 두고 설계하세요. 모든 출력 스키마에는 다음 세 가지 블록이 포함되어야 합니다:| 블록 | 목적 | 예시 필드 |
|---|---|---|
| 추출된 데이터 | 문서에서 추출한 원시 값 | vendorName, invoiceNumber, registrationDate |
| 검증 결과 | 항목별 승인/거부 및 사유 | amountsMatch, dateValid, fieldsConsistent |
| 결정 | 최종 판정과 라우팅 상태 | result, verificationStatus, reasons |
verificationStatus 기반 라우팅
각 분석에는 verificationStatus 하나가 올라오며, 값은 approved, pending_review, rejected 중 하나입니다. 이 enum으로 시스템을 분기하세요.
| verificationStatus | 권장 조치 |
|---|---|
approved | 자동 승인·시스템 반영 |
pending_review | 사람 검토 대기열로 전달(AI 요약·추출 데이터 포함) |
rejected | 정책에 따라 거부·종료 처리 |
구현 패턴
성과 측정
Omni 워크플로우를 배포한 후 다음 지표를 추적하여 영향을 측정하세요:| 지표 | 측정 방법 | 목표 |
|---|---|---|
| 검토 시간 단축 | 케이스당 평균 소요 시간 (도입 전 vs. 후) | 자동 승인 케이스에서 50-80% 단축 |
| 오류율 | 잘못된 결정의 비율 (Omni 결과를 수동 표본 검사와 비교) | 수동 오류율과 동일하거나 낮음 |
| 처리량 | 일/주당 처리된 케이스 수 | 자동 처리로 인한 대폭 증가 |
| 에스컬레이션 비율 | 사람 검토로 라우팅된 케이스의 비율 | 정책 개선에 따라 시간이 지나면서 감소해야 함 |
권장 배포 접근법
단일 워크플로우로 파일럿 실행
가장 처리량이 많고 규칙 기반인 검토 프로세스를 선택하세요. 해당 프로세스에 대한 Omni 워크플로우를 생성하고 1-2주 동안 수동 프로세스와 병행 운영합니다.
다음 단계
워크플로우 생성하기
대시보드에서 첫 번째 워크플로우를 구축하는 단계별 가이드입니다.
정책 작성 가이드
효과적인 검증 정책을 작성하기 위한 모범 사례입니다.