040205 Connect Custom Processes
2023-04-10
위 벳지는 수강을 완료하고 받은 뱃지입니다.
Get Data into the EMS
02. Refine your Data Pipeline
Connect Custom Processes
1 맞춤형 프로세스 연결
11 소개
111 학습 목표
때로는 프로세스 커넥터가 없습니다.
Celonis는 100개가 넘는 프로세스 커넥터를 제공하여 실행 관리 과정에서 유리한 출발을 할 수 있도록 하지만 경우에 따라 프로세스 커넥터가 없을 수도 있습니다. 지금까지 이러한 시스템에 대한 수요가 충분하지 않았거나 시스템이 맞춤형, 자체 개발 또는 레거시이기 때문일 수 있습니다.
그러면 어떻게 해야 합니까?
괜찮아요! 이 교육에서는 프로세스 커넥터가 없을 때 데이터 요구 사항을 식별하는 모범 사례 방법론을 배웁니다 . 실제로 시스템에 연결할 수 있는 방법을 찾고 있다면 “ 시스템에 연결 “ 과정을 검토하십시오.
이 교육을 마치면 다음을 수행할 수 있습니다.
케이스 ID(고유 식별자)를 선택하여 프로세스를 매핑하는 방법알아보기- 정의된 프로젝트 범위에 대한 데이터 요구 사항 식별
- 프로세스, 이벤트 로그 및 테이블 관계의 기본 이해
112 사용자 지정 프로세스를 연결하는 단계
사용자 지정 프로세스를 연결할 때 따라야 하는 특정 단계 순서가 있습니다. 높은 수준에서 성공적인 프로세스 연결을 위해 다음 단계를 권장합니다.
- 프로젝트 범위 정의
- 데이터 요구 사항 식별
- 소스 시스템에 대한 데이터 연결 설정
- 데이터 추출, 변환 및 로드
이 과정에서는 Order-to-Cash 프로세스의 모범 사례를 함께 살펴보겠습니다. 이제 사용자 정의 프로세스를 연결하는 핵심 프로젝트 단계를 살펴보십시오!
- 프로젝트 범위 정의
- 데이터 요구 사항 식별
- 소스 시스템에 대한 데이터 연결 설정
- 데이터 추출, 변환 및 로드
12 프로세스 이해
121 사례 ID/고유 식별자 선택
고유 식별자/케이스 ID의 목적은 무엇입니까?
고유 식별자를 사용하면 서로 다른 사례를 구분하고 활동과 타임스탬프를 올바르게 할당할 수 있습니다. 이벤트 로그에서는 이러한 고유 식별자를 ‘ 케이스 ID ‘라고 합니다.
케이스 ID는 기본적으로 각 케이스와 직접 관련된 모든 활동 및 타임스탬프를 문서화하기 위한 참조 번호입니다. 따라서 우리의 사례 테이블에서 고유해야 합니다.
사례 ID는 단일 필드이거나 데이터 세트의 여러 필드 조합일 수 있다는 점에 유의해야 합니다.
프로젝트의 케이스 ID
개별 프로세스 흐름이 있는 개체의 가장 세밀한 단위를 나타내기 때문에 전체 프로세스에서 판매 주문 항목을 따를 것입니다.
PerfectOrder 시스템에서 케이스 ID는 다음의 조합입니다.
- 판매_주문_ID
- 제품 번호
… 이 프로세스의 판매 주문 항목 수준에 대한 모든 정보를 저장하는 Sales_Order_Item 테이블에 있습니다.
분석하려는 프로세스에 따라 케이스 ID는 서비스 티켓 번호, 인보이스 번호 또는 추가 유형의 식별자가 될 수도 있습니다.
그러나 고유 식별자를 어떻게 선택했습니까?
ID 선택은 다음 사항에 영향을 미칩니다.
- 프로세스 다이어그램 및 분석의 세분성
- Celonis의 프로세스 시각화
- 다룰 수 있는 사용 사례 및 질문
고유 ID의 선택은 종종 직관적입니다. 어쨌든 다음 사항을 염두에 두는 것이 좋습니다.
- 더 세분화된 고유 식별자를 선택합니다.
- ID 간 명확한 1:1 매핑 보장
- 프로젝트 범위와 전략적 목표를 염두에 두십시오.
13 시스템 환경 이해
131 여러 시스템 다루기
여러 시스템 다루기 “다중 시스템 및 프로세스” 과정을 이수한 경우 이 단원 은 복습일 뿐이므로 건너뛸 수 있습니다 .
오늘날의 기업에서는 수십 개의 IT 시스템이 종단 간 비즈니스 프로세스를 지원합니다. 종종 이러한 분리는 조직 분리의 결과입니다. 결국 이러한 사일로는 부서 간 커뮤니케이션, 협업 및 가장 중요한 원활한 프로세스 실행을 차단합니다.
Celonis에서는 고유 식별자를 사용하여 여러 소스 시스템의 데이터를 하나의 응집력 있는 데이터 모델로 쉽게 결합하고 표준 ERP, 자체 개발, 레거시 또는 맞춤형 시스템인지 여부에 관계없이 각 사례의 전체 수명 주기를 추적합니다.
단일 프로세스가 여러 시스템에서 병렬로 실행 되거나 여러 시스템에서 순차적으로 실행될 수 있는 경우를 자주 봅니다.
병렬 시스템
여기서 구매 오더는 지역에 따라 시스템 A 또는 시스템 B에서 생성됩니다.
데이터 통합 내에서 여러 시스템의 데이터를 변환하고 단일 이벤트 로그를 생성합니다.
순차 시스템
여기에서 기회는 시스템 A에서 생성되고 응용 프로그램은 시스템 B에서 생성됩니다.
병렬 실행과 마찬가지로 모든 관련 데이터를 추출하고 데이터 통합 내에서 하나의 단일 이벤트 로그를 생성하여 end-to-end 프로세스 시각화를 구축합니다.
132 프로젝트를 위한 시스템 선택
시스템을 선택하는 이유는 무엇입니까? 일부 프로세스에는 수십 개의 시스템과 애플리케이션이 있습니다. 이러한 모든 시스템을 Celonis에 통합하는 것이 기술적으로 가능하지만 프로세스 마이닝 및 실행 관리에 어떤 시스템이 필요한지 이해해야 합니다. 이는 우리가 지출해야 하는 노력에 대한 혜택을 극대화하는 데 도움이 됩니다.
특히 단기 평가 또는 가치 증명 프로젝트에서는 모든 시스템을 연결하는 대신 대부분의 프로세스를 캡처하여 기술적 노력을 최소화하고 전략적 평가 그 자체.
프로세스를 연결할 시스템을 선택할 때 도움이 되는 몇 가지 주요 질문이 있습니다.
- 어떤 시스템에서 프로세스가 실행됩니까?
- 타사 시스템이 있습니까?
- 어떤 시스템이 절대적으로 관련이 있습니까?
- 추가 연결의 가치는 무엇입니까?
우리 프로젝트에는 결국 세 가지 시스템이 있었습니다.
- PerfectOrder
- Expand PayWisely
- Expand BillNow
PerfectOrder 및 PayWisely 선택
이것이 우리가 초기 범위에서 BillNow를 제외하고 PerfectOrder와 PayWisely만 연결하기로 결정한 이유입니다.
Celonis를 사용하면 여러 소스에서 데이터를 쉽게 연결하고 추출할 수 있으므로 나중에 BillNow 시스템에 연결할 필요가 있는 경우 쉽게 연결할 수 있습니다.
14 데이터 요구 사항 식별
141 데이터 요구 사항 소개
빠른 요약을 할 준비가 되셨습니까? 지금까지 우리는 프로세스를 정의하고 고유 식별자를 식별하며 프로젝트와 관련된 시스템을 선택하는 방법을 배웠습니다. 지금이 이 프로세스를 시각화하기 위해 데이터 요구 사항을 매핑할 완벽한 시간입니다.
앞에서 배운 것처럼 데이터 요구 사항을 정의할 때 고려해야 할 네 가지 중요한 사항이 있습니다.
- 활동 데이터 - 이벤트 로그를 생성하기 위해 프로세스 마이닝의 주요 성분으로 사용됩니다.
- 차원 - 공급업체 및 제품 범주와 같은 특정 속성에 대한 프로세스/지표를 표시합니다.
- 주요 지표 - 데이터 추출 전에 가장 중요한 계산에 맞출 수 있습니다.
- 번역 및 이름 매핑 - 특정 기술 용어를 의미 있는 텍스트 필드로 변환합니다.
이러한 정보의 개요를 작성한 후 최종 테이블 요구 사항 목록을 작성하고 테이블 관계를 정의합니다. 종종 시스템 전문가는 이미 “테이블 관계”의 시각화를 사용할 수 있습니다.
다음 장에서는 각 항목을 자세히 살펴보고 요구 사항을 자세히 식별하는 방법을 알아봅니다.
142 데이터 탐색기로 데이터 탐색
새로운 시스템이나 프로세스를 처리할 때 한 가지 문제는 당면한 데이터를 빠르게 탐색하는 것입니다. 데이터베이스 SQL 쿼리를 사용하는 대신 Celonis의 데이터 탐색기 사용을 고려할 수 있습니다. 데이터 탐색기로 데이터를 탐색하려면 다음을 수행하기만 하면 됩니다.
- 잠재적으로 관련된 모든 테이블 추출
- 추출된 모든 테이블을 데이터 모델로 로드
- 데이터 모델을 Studio의 지식 모델에 연결
- 데이터 탐색기 인스턴스 생성
- 탐험을 시작하다
143 활동 데이터
이벤트 로그는 프로세스 마이닝 프로젝트의 주요 요소이므로 먼저 이벤트 로그의 데이터 포인트를 식별합니다. 사례 ID, 활동 이름 및 이벤트 시간은 이벤트 로그에 대한 최소 요구 사항을 형성합니다. 또한 사용자 이름이나 사용자 유형과 같은 활동과 관련된 다른 필드를 항상 가질 수 있습니다.
타임스탬프는 어디에서 캡처합니까?
타임스탬프는 일반적으로 세 가지 유형의 테이블에 저장됩니다.
- 일반 개체 테이블
- 변경 로그
- 워크플로 또는 상태 로그
활동 개요
이제 살펴봐야 할 부분을 알았으니 모든 관련 활동을 설명할 차례입니다! 이전에 다운로드한 템플릿( 놓친 경우 여기에 있음)에는 이미 “(2) 활동” 시트에 몇 가지 샘플 활동이 포함되어 있습니다.
각 활동에 대해 일련의 질문에 답하는 것이 중요합니다. PerfectOrder에서 ‘판매 주문 항목 만들기’ 활동을 위해 함께 해봅시다.
- 활동 이름은 무엇입니까?
- 이 활동의 수준은 무엇입니까?
- 이 활동에 대한 타임스탬프를 저장하는 테이블은 무엇입니까?
- 이 테이블의 어느 필드가 타임스탬프입니까?
- 전역 사례 테이블과의 관계는 무엇입니까(있는 경우)?
- 고유 식별자를 나타내는 필드는 무엇입니까?
- 이 활동에 조건이 있나요?
앞서 언급했듯이 이 템플릿은 나중에 변환을 구축할 때 훌륭한 맵입니다.
이 정보가 데이터 통합에서 이 활동을 생성하는 데 어떻게 도움이 되는지 아래 예를 살펴보십시오!
(1) Sales_Order_ID와 Item_No를 결합하여 고유한 키를 생성했습니다. (2) Celonis Process Explorer에 표시되는 활동 이름입니다. (3) 이 활동에 대한 날짜 및 시간 필드를 결합하여 타임스탬프를 생성했습니다. (4) Sales_Order_Header 테이블과 Sales_Order_Item 테이블을 조인했습니다. (5) 마지막으로 주문이 더미가 아닌 항목만 보고 싶다고 말했습니다.
| 케이스 ID | 활동 | 타임스탬프 |
| 00101 | 판매 주문 항목 생성 | 2020년 5월 14일 16:38:11 |
| 00102 | 판매 주문 항목 생성 | 2020년 5월 14일 16:45:35 |
| 00201 | 판매 주문 항목 생성 | 2020년 05월 15일 09:21:32 |
| … | … | … |
| … | … | … |
144 치수 (Dimensions)
프로세스 탐색을 시작하면 활동 데이터만으로는 쉽게 답변할 수 없는 많은 질문이 있습니다.
예를 들어 배송된 모든 상품의 10% 이상이 프로세스 탐색기에서 고객에 의해 반송되고 있다고 상상해 보십시오. 가장 먼저 떠오르는 질문은 무엇입니까?
- 이 고객들은 누구입니까?
- 그들이 반송하는 제품은 무엇입니까?
- 이러한 결함이 있는 제품을 생산하는 공장은 어디입니까?
- 눈에 띄는 제품이나 식물이 있습니까? 이것들을 자세히 살펴봐야 할까요?
- 나머지보다 훨씬 더 잘 수행하는 식물이 있습니까? 그들은 무엇을 다르게합니까?
즉시 드릴다운하여 프로세스에서 이 큰 문제의 원인을 이해하고 싶을 것입니다. 이것이 바로 치수가 필요한 이유입니다.
치수 정의
치수를 정의할 때 다음 사항을 확인하는 것이 중요합니다.
- 주요 이해 관계자는 어떤 차원에 관심을 가집니까?
- 성능이 좋지 않은 메트릭이나 프로세스 비효율성이 있는 경우 그 이유를 알아보기 위해 어떤 차원을 살펴봐야 합니까?
다음은 Order-to-Cash 프로젝트에 포함할 수 있는 차원의 몇 가지 예입니다.
- 고객 마스터
- 플랜트 마스터
- 제품 카테고리
- 제품 라인
145 주요 지표
로젝트를 통해
- 영업 생산성 향상
- 배송 이행 및 품질 가속화
- 운전 자본 최적화
각 이니셔티브의 진행 상황을 모니터링하기 위해 이해 관계자와 함께 몇 가지 Order-to-Cash 주요 지표를 확인했습니다 .
| 영업 생산성 향상 | 배송 이행 및 품질 가속화 | 운전 자본 최적화 |
|---|---|---|
| 판매 주문 자동화율당 최초 적법 비용 | 전체 배송률 정시 배송률 | 영업 미수일 |
자동화율 또는 DSO(Days Sales Outstanding)와 같은 가장 일반적인 메트릭의 경우에도 계산 방법은 고객마다 다를 수 있습니다. 재작업 루프를 제거하고 모든 관련 데이터를 캡처하려면 처음부터 프로젝트 팀과 이러한 메트릭의 정의를 일치시키는 것이 중요합니다.
각 이니셔티브의 메트릭에 대해 다음을 이해하는 것이 중요합니다.
- KPI - 모니터링하려는 메트릭은 무엇입니까?
- Formula - 이 메트릭을 어떻게 계산하시겠습니까?
- Data - 수식 내에 이러한 데이터 요소가 포함된 테이블과 필드는 무엇입니까?
146 번역 및 이름 매핑
SAP와 같은 많은 시스템에는 특정 코드 필드를 의미 있는 텍스트로 변환하는 데 도움이 되는 변환 및 이름 매핑 테이블이 있습니다.
이러한 변환 테이블은 단순히 다른 테이블에서 관련 값을 찾는 데 사용되는 조회 테이블 역할을 합니다. 일반적인 번역은 이유 코드, 고객 ID, 회사 코드 및 문서 유형입니다.
이러한 테이블을 사용하면 사용자가 이해하기 쉬운 분석, 프로세스 및 차원을 구축할 수 있으므로 이러한 테이블이 데이터 집합에 있는지 이해하는 것이 중요합니다.
직접 확인하십시오! 어느 것이 더 낫습니까?
147 데이터 요구 사항: 모두 통합
이 시점까지 우리는 활동 데이터를 식별하고 , 관련 측정 기준을 선택하고, 주요 측정 항목에 정렬하고 , 최종적으로 변환표가 있는지 확인했습니다 . 이제 이 모든 조각을 모아서 테이블 요구 사항을 정의합니다.
이를 위해 템플릿의 “ (5) 테이블 요구 사항 목록” 시트를 작성합니다 . 프로세스를 실제로 연결하기 위한 데이터 연결이 확보되면 이 문서가 훌륭한 가이드 역할을 한다는 점을 기억하는 것이 중요합니다.
템플릿이 준비되었나요?
-
먼저 테이블 요구 사항의 최종 목록을 정의합니다.
이 장 전체에서 우리는 ‘PerfectOrder’ 및 ‘PayWisely’ 시스템에서 실행되는 주문-현금 프로세스에 대한 활동 및 차원과 같은 프로세스의 다양한 부분을 설명하는 방법을 배웠습니다.
테이블 요구 사항의 최종 목록을 만들기 위해 다음과 같이 다양한 부분에 필요한 모든 테이블을 나열합니다.
- 활동(Activities)(예: Sales_Order, Invoice_Status_Log)
- 차원(Dimensions )(예: Plant_Master, Customer_Master)
- 주요 메트릭(Key Metrics)(예: Sales_Order, Sales_Order_Item)
- 번역 및 이름 매핑(Translations & Name Mappings )(예: Company_Codes)
-
둘째, 기본 키를 결정하고 테이블 관계를 이해합니다.
Celonis에서는 관계형 데이터 모델을 사용하고 관계형 데이터 모델에서는 데이터를 검색할 때 모호성이 없도록 각 테이블에 대한 고유 식별자를 갖는 것이 중요합니다.
그렇기 때문에 이 단계에서 이미 각 테이블의 기본 키를 이해하는 것이 항상 좋은 생각입니다. 기본 키는 단일 열이거나 여러 열의 조합일 수 있습니다.
예를 들어 Customer_Master 테이블 에서 Customer_ID는 기본 키인 반면 Sales_Order_Item 테이블 에서 기본 키는 Sales_Order_ID와 Item_No의 조합입니다.
다음 두 가지 기준은 기본 키를 정의할 때 중요합니다.
각 행을 고유하게 식별합니다. 기본 키의 값은 테이블 내에서 항상 고유해야 합니다. 예를 들어, Customer_Master 테이블의 기본 키로 Customer_Name보다 Customer_ID를 사용하는 것을 선호합니다. ID는 고유하지만 경우에 따라 이름이 중복될 수 있기 때문입니다.
또한 null이 아닙니다. Celonis의 강력한 데이터 모델을 위해 기본 키에는 항상 값이 있어야 합니다. 대부분의 경우 기본 키는 소스 시스템 수준에서 올바르게 유지 관리되어야 하므로 기본 키에 null 값이 표시되지 않습니다. 그러나 어떤 이유로든 null 값이 많이 표시되면 언제든지 시스템 전문가에게 문의할 수 있습니다.
기본 및 외래 키를 이해하면 나중에 Celonis에서 데이터 모델을 구축할 때 도움이 됩니다. 프로세스 마이닝 임무를 안내할 수 있는 기존 데이터 모델 맵이 이미 있는지 시스템 전문가에게 문의하십시오!
-
마지막으로 각 테이블에 대한 필터 및 조인과 같은 추가 세부 정보를 간략하게 설명합니다 .
데이터 통합을 통해 매우 세분화된 수준에서 데이터 요구 사항을 구성하고 관리할 수 있습니다. 테이블을 쉽게 추가 또는 제거하고, 필터 및 조인을 정의하고, 열 범위를 제한하고, 모든 필드를 가명화할 수 있습니다. 그렇기 때문에 각 테이블에 대해 다음 세부 정보를 수집해야 합니다.
필터(Filters) - 프로젝트 범위에 따라 데이터 추출을 제한해야 하는 필터가 있습니까? (예: 날짜, 회사 코드)
열(Columns ) - 전체 테이블을 있는 그대로 추출해야 합니까, 아니면 열을 제한해야 합니까? 이는 Sales_Order_Item 테이블과 같은 거대한 테이블에 특히 중요합니다.
가명화할 열(Columns to pseudonymize) - 가명화해야 하는 사용자 이름 및 고객 이름과 같은 민감한 필드가 있습니까?
조인(Joins ) - 테이블을 조인해야 합니까? 조인 조건 및 필터란 무엇입니까?
