개요
이 영상 스크립트는 컨설팅 과정에서 이력서 파싱 시스템의 데이터베이스 연결 전략을 심층적으로 논의하고 구축하는 과정을 담고 있습니다. 주요 목표는 이력서 정보와 기업 정보를 효과적으로 연동하고, 이 과정에서 발생할 수 있는 다양한 문제점(예: 기업명 불일치, API 호출 제한, 데이터 누락)을 해결하기 위한 자동화 시나리오를 Make (구 Integromat) 플랫폼을 사용하여 개발하고 개선하는 것입니다.
영상은 기업 정보 자동 업데이트, 이력서 데이터 파싱 및 관계형 데이터베이스 연동, 오류 처리 메커니즘 구현, 그리고 최종적으로 이러한 데이터를 활용한 KPI 대시보드 구축까지의 과정을 다룹니다. 실제 시나리오 시연과 문제 해결 과정을 통해 실무적인 팁과 주의사항을 공유하며, 검색 가능한 지식 자료로서 시스템의 효율성과 안정성을 높이는 데 기여할 수 있는 구체적인 방법론을 제시합니다.
주요 학습 포인트
•
Make (구 Integromat)을 활용한 이력서 파싱 및 기업 정보 연동 자동화 전략 수립
•
Bizno API 연동 시 제약사항(호출 제한, 검색 정확도) 이해 및 대응 방안 모색
•
기업명 불일치 문제 해결을 위한 데이터 정규화 및 관계형 매핑 전략
•
Make의 새로운 모듈(데이터 입력 트리거)을 활용한 시나리오 개선 방법
•
오류 처리(중복 데이터, 데이터 형식 오류 등) 및 안정적인 시스템 운영을 위한 실무 팁
•
KPI 대시보드 설계를 위한 요구사항 분석 및 Notion을 활용한 시각화 방안
요약
1. 이력서와 회사 정보 연동 시 기업명 불일치 문제 및 Bizno API를 활용한 해결 전략
•
구간별 주제: 초기 문제점 정의 및 Bizno API를 통한 기업 정보 자동 업데이트 시나리오 소개
•
핵심 요점:
1.
기업명 불일치로 인한 관계형 매핑 오류: 이력서에서 파싱된 기업명과 데이터베이스 내 기업명이 다를 경우, 관계형이 제대로 형성되지 않는 문제가 발생합니다.
•
이력서의 기업명은 파싱되어 들어오므로, 기존 DB의 기업명과 정확히 일치해야 합니다.
2.
Bizno API를 활용한 사업자 번호 및 정확한 기업명 자동 업데이트: 사업자 번호가 없는 기업 정보를 대상으로 Bizno API를 호출하여 사업자 번호와 표준 기업명을 가져와 업데이트하는 시나리오를 구현했습니다.
•
이 시나리오는 조건(사업자 등록 번호 없음)에 따라 실행되며, 로딩 시간을 줄이기 위해 검색 조건을 명시적으로 관리합니다.
•
Bizno API는 기업명을 표준화된 명칭으로 변경해주는 부가 기능도 제공합니다.
3.
기존 트리거 방식과 전체 업데이트 방식의 차이: 기존에는 사용자가 수동으로 체크하고 실행해야 하는 트리거 방식이었으나, 새로운 시나리오는 사업자 번호가 없는 모든 기업 정보를 대상으로 일괄 업데이트를 시도합니다.
•
현재 1279개 회사 중 1081개가 사업자 번호가 없는 상태입니다.
•
중요 참고사항:
◦
Bizno API는 무료 사용 시 하루 API 요청 건수가 200건으로 제한됩니다.
◦
200건 초과 시 오류가 발생하므로, 하루 작업 종료 시점에 맞춰 200건씩 순차적으로 업데이트하는 전략을 사용합니다.
2. Bizno API 연동 시나리오 운영 방안 및 예외 처리
•
구간별 주제: Bizno API 호출 제한 대응, 검색 불가 기업 처리 및 데이터 검증 필드 추가 논의
•
핵심 요점:
1.
API 호출 제한 관리: Bizno API의 일일 호출 제한(200건)에 맞춰, 초과 시 오류가 발생하고 해당 기업 정보는 가져오지 못하게 됩니다.
•
이를 위해 매일 정해진 시간에 자동으로 200건씩 처리하는 시나리오를 설정합니다. (예: 저녁 9시)
2.
검색 불가 기업 처리: Bizno API에서 검색되지 않는 기업에 대한 알림 또는 별도 관리 방안이 필요합니다.
•
어떤 기업이 처리되었고 어떤 기업이 처리되지 않았는지 확인하기 위해 데이터베이스에 플래그 필드(예: 'Bizno 검색 여부')를 추가하는 것을 제안합니다.
3.
Bizno 검색 실패율 및 원인 분석: Bizno에서 첫 번째 검색 결과로 가져오지 못하는 경우가 약 10-15% 정도 발생할 수 있습니다.
•
이는 주로 영문 기업명 검색 제한(무료 API의 경우) 때문일 수 있습니다. (예: 'SK'는 검색되나 영문 'SK'는 유료 전환 유도)
•
수동으로 사업자 번호를 찾아 입력하는 방안도 고려합니다.
•
부가 설명:
◦
챗GPT API를 통해서는 대부분의 기업 정보가 검색되지만, Bizno API의 정확한 명칭을 사용하는 것이 데이터 일관성에 유리합니다.
•
중요 참고사항:
◦
Bizno API에서 영문 기업명 검색이 제한되는 것은 유료 플랜 사용을 유도하기 위함일 수 있습니다.
3. 기업 정보 입력 표준화 및 상태 관리 방안
•
구간별 주제: 기업 정보 입력 프로세스 표준화 및 데이터 상태 관리 필드 정의
•
핵심 요점:
1.
기업명 입력 표준화: 향후 모든 기업명 입력은 Bizno API를 통해 검증된 표준 기업명을 사용하도록 프로세스를 통일합니다.
•
기존 시나리오(수동 입력 또는 다른 경로)는 사용하지 않고, Bizno API 연동 시나리오를 통해 업데이트된 기업명을 기준으로 합니다.
2.
기업 정보 상태 관리 필드 변경: 기존 '출처' 필드 대신, 데이터 처리 상태를 명확히 하기 위한 새로운 필드를 도입합니다.
•
초기 상태: '입력 전' (기본값)
•
처리 상태: '수동 입력', 'Bizno' (Bizno API를 통해 정보가 업데이트된 경우)
3.
Bizno API 처리 여부 체크 필드 추가: 'Bizno에서 검색됨' 체크박스 필드를 추가하여, 해당 기업 정보가 Bizno API를 통해 성공적으로 처리되었는지 여부를 명시적으로 관리합니다.
•
이 필드는 Bizno API 연동 시나리오가 실행될 때 자동으로 체크됩니다.
•
부가 설명:
◦
이력서에서 추출된 기업명이 Bizno API의 첫 번째 검색 결과와 일치하지 않을 경우, 사용자가 수동으로 Bizno에서 검색하여 정확한 기업명으로 변경하고 사업자 번호를 입력해야 합니다.
•
중요 참고사항:
◦
Make 시나리오가 웹훅(Webhook) 방식이 아니므로, 업데이트 후 즉시 체크하는 것보다 시나리오 내에서 업데이트와 동시에 상태를 변경하는 것이 효율적입니다.
4. Bizno API 연동 시나리오 테스트 및 자동 실행 설정
•
구간별 주제: Bizno API 연동 시나리오 실제 테스트, 결과 검증 및 자동 실행 스케줄링 설정
•
핵심 요점:
1.
시나리오 테스트: '동국생명과학' 기업을 예시로 Bizno API 연동 시나리오를 실행하여, 사업자 등록 번호 입력 및 기업명 표준화, 'Bizno 검색됨' 체크박스 자동 체크 기능을 검증합니다.
•
초기 테스트 시 사업자 등록 번호가 즉시 반영되지 않는 경우가 있었으나, 시간차를 두고 확인 시 정상적으로 업데이트됨을 확인했습니다.
2.
API 호출 제한 해제 및 자동 실행 설정: 테스트를 위해 걸어두었던 API 호출 제한(1건)을 해제하고, 매일 저녁 9시에 100건씩 자동으로 실행되도록 스케줄링합니다.
•
불안할 경우, 일일 처리 건수를 150개 정도로 제한할 수도 있습니다.
•
처리할 기업 정보가 없을 경우, 시나리오가 자동으로 중단되도록 설정합니다.
•
부가 설명:
◦
시나리오 실행 시, 체크되지 않은 (Bizno API로 처리되지 않은) 기업 정보를 대상으로 실행하도록 필터링합니다.
•
중요 참고사항:
◦
모든 기업 정보가 Bizno API를 통해 표준화된 이후에 이력서 처리 시나리오를 실행해야 데이터 중복 및 불일치 문제를 방지할 수 있습니다.
5. Make 신규 모듈을 활용한 이력서 처리 시나리오 개선 (점프 기능)
•
구간별 주제: Make의 새로운 '데이터 입력 시 실행' 모듈 소개 및 이를 활용한 이력서 처리 시나리오 재구성
•
핵심 요점:
1.
Make 신규 모듈 소개 (데이터 입력 트리거): 기존의 웹훅(번개 아이콘)이나 시간 기반(시계 아이콘) 트리거와 달리, 특정 데이터가 입력되면 실행되는 새로운 모듈이 추가되었습니다.
•
이 모듈은 특정 조건(예: 다른 모듈 실행 완료)에 따라 실행되며, 다른 시나리오나 모듈로 '점프'하여 실행하고 그 결과를 다시 받아오는 기능을 제공합니다.
2.
신규 모듈을 활용한 이력서 처리 시나리오:
•
입력: 이력서에서 파싱된 '회사 이름'(텍스트)
•
처리:
1.
입력된 회사 이름으로 Bizno에서 파싱.
2.
회사 정보가 DB에 없는 경우: 기업 정보 파싱 후 회사 DB에 새로 생성하고, 회사 ID, 사업자번호, 회사명을 반환.
3.
회사 정보가 DB에 있는 경우: 해당 회사 ID, 사업자번호, 회사명을 반환.
•
결과: 회사 이름, 사업자 등록 번호, 회사 DB ID.
•
후속 처리: 반환된 회사 ID를 사용하여 People DB와 회사 DB 간의 관계형을 설정. 휴대폰/이메일 유무에 따라 분기 처리 (정보 없으면 즉시 관계형 설정, 정보 있으면 중복 이력서 검사 후 핵심 역량 분석 및 관계형 설정).
•
부가 설명:
◦
이 신규 모듈 덕분에, 이력서 처리 시 회사 정보가 없으면 즉시 생성하고 관계를 맺는 복잡한 로직을 보다 효율적으로 구현할 수 있게 되었습니다.
◦
이력서 작성자가 회사 이름을 잘못 입력하면 Bizno에서 첫 번째 결과로 찾아오지 못해 처리가 실패할 수 있습니다.
•
중요 참고사항:
◦
이 시나리오가 정상적으로 작동하려면, 사전에 회사 DB의 모든 회사 이름이 Bizno API를 통해 100% 표준화되어 있어야 합니다. 그렇지 않으면 중복 회사가 생성될 수 있습니다.
6. Google Drive 연동 이력서 처리 시나리오에 신규 모듈 적용 및 테스트
•
구간별 주제: Google Drive에서 업로드된 이력서 처리 시나리오에 Make 신규 모듈(점프 기능) 적용 및 시연
•
핵심 요점:
1.
Google Drive 연동 시나리오 수정: Google Drive에 이력서 파일이 업로드되면 실행되는 기존 시나리오에, 회사 정보를 처리하는 새로운 점프 모듈을 통합합니다.
•
챗GPT가 파싱한 최종 재직 회사명을 점프 모듈의 입력값으로 사용합니다.
2.
시연: '프리시전바이오 주식회사' (DB에 없는 회사) 이력서를 Google Drive에 업로드하여 시나리오를 실행합니다.
•
점프 모듈이 실행되어 Bizno에서 회사 정보를 검색하고, DB에 없으므로 새로 생성한 후 회사 ID, 사업자번호, 회사명을 반환합니다.
•
반환된 회사 ID를 사용하여 People DB에 후보자 정보를 생성하고 회사 정보와 관계를 맺습니다.
3.
재실행 시나리오 (회사가 이미 DB에 있는 경우): 동일한 이력서를 다시 처리하면, 이번에는 점프 모듈이 DB에서 해당 회사를 찾아 기존 회사 ID를 반환하고, 중복 생성 없이 관계를 맺습니다.
•
부가 설명:
◦
점프 모듈은 변수 정의(Set Variable)와 유사하게 작동하며, 지정된 입력값을 받아 내부 로직을 실행 후 결과값을 반환합니다.
◦
이력서에 기재된 원래 회사명은 별도 필드(텍스트)에 저장하고, 관계형 매핑은 Bizno에서 검증된 표준 회사명을 기준으로 합니다.
•
중요 참고사항:
◦
Make의 와치(Watch) 모듈은 한 번 처리된 파일은 신규 파일로 인식하지 않으므로, 재테스트 시 수동으로 해당 파일을 다시 선택하여 실행해야 합니다.
◦
가장 중요한 전제 조건: 이 시나리오를 안정적으로 운영하기 위해서는, 회사 DB에 있는 모든 회사 정보(약 1280개)가 사전에 Bizno API를 통해 정확하게 업데이트되고 표준화되어 있어야 합니다. 그렇지 않으면 회사 정보가 중복 생성될 위험이 큽니다.
7. 이력서 내 회사명과 Bizno 검색 결과 불일치 시 문제점 및 한계
•
구간별 주제: Bizno API 검색 시 첫 번째 결과가 실제와 다른 경우 발생할 수 있는 문제점과 현재 시스템의 한계 논의
•
핵심 요점:
1.
잘못된 회사 정보 연동 위험: 이력서에 기재된 회사명이 Bizno API에서 검색했을 때, 실제 회사가 첫 번째 결과로 나오지 않는 경우 (약 10-15% 확률), 시스템은 첫 번째 검색된 (잘못된) 회사 정보를 기준으로 새로운 회사 정보를 생성하고 관계를 맺을 수 있습니다.
•
이 경우, 동일한 실제 회사에 대해 여러 개의 (하나는 정확하고 다른 하나는 부정확한) 회사 레코드가 DB에 생성될 수 있습니다.
2.
구현의 한계: 현재 시스템 구조상, Bizno API가 반환하는 첫 번째 결과를 기준으로 처리하므로, 이러한 오류를 완벽하게 방지할 방법은 없습니다.
•
AI(챗GPT)를 통해 사업자 번호를 추출하더라도 정확도가 낮아 (거의 안 나옴), 이를 기준으로 검색하는 것은 현실적이지 않습니다.
•
사용자가 수동으로 검색해도 잘못된 정보를 선택할 가능성이 있습니다.
3.
대응 방안:
•
회사 정보 입력 완료 후 더블 체크 과정을 통해 정확성을 확보합니다.
•
Bizno에서 검색되지 않거나 잘못 연동된 경우는 수동으로 수정합니다.
•
부가 설명:
◦
사업자 번호는 구글 등 일반 검색 엔진에서는 잘 노출되지 않으며, 전문 사이트에서 검색해야 하는 경우가 많습니다.
•
중요 참고사항:
◦
현재로서는 최선의 방법이며, 운영하면서 발생하는 문제를 지속적으로 모니터링하고 개선해야 합니다. 회사 정보 입력 완료 시점에 최종 검토 단계를 두는 것이 중요합니다.
8. Google Drive 연동 시나리오 담당자별 분리 및 오류 관리 방안
•
구간별 주제: Google Drive 이력서 처리 시나리오의 담당자별 분리 운영 가능성 및 기존 오류 원인 분석
•
핵심 요점:
1.
담당자별 시나리오 복제 및 운영: Google Drive 이력서 처리 시나리오를 담당자별로 복제하여 운영할 수 있습니다.
•
Make에서 시나리오를 복제(Clone)하고, Google Drive 폴더 경로만 각 담당자별 폴더로 변경하면 됩니다.
•
복제 시 기존 Notion 데이터베이스 연결 정보는 그대로 유지하도록 설정해야 합니다.
2.
오류 발생 시 문제점: 여러 담당자가 동시에 하나의 시나리오를 사용하거나, 한 시나리오에 많은 파일이 한꺼번에 입력될 경우, 오류 발생 시 전체 작업이 중단되고 원인 파악이 어려워집니다.
•
중복 파일, 데이터 형식 오류(예: URL 필드에 URL이 아닌 값 입력), 잘못된 ID 참조(예: Notion ID 대신 Google Drive ID 입력) 등이 주요 오류 원인이었습니다.
3.
오류 관리 개선:
•
URL 필드를 텍스트 필드로 변경하여 입력 유연성을 높였습니다.
•
오류 발생 시, 담당자가 직접 Make 시나리오 실행 과정을 모니터링하여 오류 지점과 원인을 파악하도록 하는 것이 더 안정적일 수 있습니다.
•
중복 파일 발생 시, 시나리오가 멈추지 않고 해당 파일을 별도 폴더로 이동시키는 등의 예외 처리 로직을 강화할 필요가 있습니다.
•
부가 설명:
◦
한 시나리오 내에서 여러 작업이 동시에 실행되는 것은 문제 없으나, 여러 입력이 한 시나리오에 동시에 몰리는 것은 문제를 야기할 수 있습니다.
◦
이전에 발생했던 오류 중 상당수는 Notion 페이지 ID가 들어가야 할 곳에 Google Drive 파일 ID가 잘못 매핑되어 발생한 것이었습니다.
•
중요 참고사항:
◦
담당자별로 시나리오를 분리하면, 오류 발생 시 해당 담당자의 문제로 국한시킬 수 있어 전체 시스템 안정성에 도움이 됩니다.
◦
총 경력 입력 필드에서 '19년 4개월'과 같이 텍스트와 숫자가 혼용된 값을 숫자 필드에 입력하려다 오류가 발생한 사례가 있었습니다. 해당 필드를 텍스트로 변경하거나, 프롬프트를 통해 숫자만 입력되도록 유도하는 방안을 고려해야 합니다.
9. 기타 자동화 시나리오 (미연결 회사 관계 맺기) 및 이메일 발송 문제 해결
•
구간별 주제: 회사와 관계형이 맺어지지 않은 인물 데이터 자동 연결 시나리오 소개 및 이메일 발송 시스템 오류 해결
•
핵심 요점:
1.
미연결 회사 관계 자동 맺기 시나리오: People DB에서 회사 정보와 관계형이 맺어지지 않은 사람들을 검색하여, 해당 회사 정보를 Bizno에서 찾아 자동으로 관계를 맺어주는 시나리오를 추가로 만들었습니다.
•
이 시나리오는 데이터를 새로 생성하는 것이 아니라, 기존 People 데이터와 Company 데이터를 연결하는 역할을 합니다.
•
회사명이 정확하게 DB에 입력된 이후에 실행해야 효과적입니다.
2.
이메일 발송 시스템 오류 (JD 발송, 회사소개서 발송):
•
JD 발송 문제: 담당자들이 JD 발송 실행 버튼을 눌러도, 대표에게만 이메일이 가고 담당자 본인에게는 가지 않으며, 후보자 상태 변경도 제대로 이루어지지 않는 문제가 있었습니다.
◦
원인: Make 시나리오 설정 시, 수신자 및 발신자 정보가 대표자 기준으로만 설정되어 있었고, 각 담당자별로 분기 처리가 구현되지 않았기 때문입니다. (부산 출장 시 개별 설정하기로 했던 부분)
•
회사소개서 발송 문제: 회사소개서 파일을 이메일 본문에 이미지 카드 형태로 첨부하여 발송하는 기능이 제대로 작동하지 않습니다.
◦
일반 첨부파일 형태로는 발송 가능하나, 본문 내 삽입은 어렵습니다.
◦
대안: 워딩(텍스트)과 함께 일반 첨부파일 형태로 발송하는 것으로 변경합니다.
•
부가 설명:
◦
스팸메일 방지 등을 위해 특정 메일 계정(예: 회사 대표 계정)으로만 발송이 허용되는 경우, 담당자별 개별 메일 발송이 어려울 수 있습니다.
•
중요 참고사항:
◦
담당자별 이메일 발송 기능은 각 담당자의 계정 정보를 Make 시나리오에 개별적으로 설정하고 라우팅하는 작업이 필요합니다.
10. CRM 데이터 오류 수정 및 콜 생성 시 담당자 자동 할당
•
구간별 주제: CV(이력서) 생성 시 다른 사람 이름이 표시되는 오류 수정 및 콜(Call) 생성 시 담당자 자동 할당 기능 개선
•
핵심 요점:
1.
CV 생성 시 담당자 불일치 오류: CRM 데이터에서 CV(이력서)를 생성할 때, 간혹 다른 담당자의 이름이 표시되는 오류가 있었습니다.
•
원인: People DB에 해당 후보자를 관리하는 '컨설턴트' 정보가 누락된 경우 발생합니다.
•
Google Drive를 통해 후보자가 생성되면 생성자가 'Make'로 기록되어, 담당자 정보가 비게 됩니다.
2.
콜 생성 시 담당자 자동 할 dangereux (할당): 콜 생성 버튼 클릭 시, 해당 버튼을 클릭한 사람(페이지를 실행한 사람)의 이름이 담당자로 자동 할당되도록 수정했습니다.
•
기존에는 별도의 컨설턴트 필드를 참조했으나, 실제 액션을 취한 사람을 기준으로 하는 것이 더 정확하다고 판단했습니다.
3.
입력 완료 vs 통화 완료:
•
입력 완료: 데이터 입력이 완료되었음을 의미하며, 입력 완료 체크 시 해당 목록에서 사라지도록 필터링됩니다. (일반적인 작업 완료 표시)
•
통화 완료: 실제 통화가 완료되었음을 나타내는 상태값입니다. (구체적인 설명은 이어지지 않음)
•
부가 설명:
◦
콜 예정일자가 기록되고 입력 완료를 누르면, 해당 항목은 '오늘 콜할 리스트' 등 다른 뷰로 이동하거나 필터링됩니다.
•
중요 참고사항:
◦
이메일 발송 시나리오(개별 메일 발송)는 각 담당자별로 메일 서버 접속 정보 등을 설정해야 하므로, 현장(부산) 방문 시 설정하기로 했습니다.
11. KPI 대시보드 구축 요구사항 (개인/팀 성과 추적)
•
구간별 주제: KPI 대시보드 구축 목표 및 주요 요구사항 정의 (개인 및 팀 성과 추적, 트렌드 분석)
•
핵심 요점:
1.
대시보드 구축 목적:
•
개인 및 팀의 KPI 달성 현황을 실시간으로 추적하고 팔로우업합니다.
•
업무 트렌드를 파악하여 성과 개선 및 위험 관리에 활용합니다.
•
매니저뿐만 아니라 개인도 자신의 성과를 확인하고 자기 관리에 활용하도록 합니다.
2.
주요 KPI 항목:
•
채용 성공 (CRM Success) - 가장 중요한 지표
•
BD 콜 (Business Development Call) 성공 건수
•
통화 완료율
•
신규 고객 유치 (미팅 건수로 카운트)
3.
데이터 집계 주기: 주 단위, 월 단위로 데이터를 취합하고 시각화합니다.
•
부가 설명:
◦
과거 수동으로 관리하던 KPI 시트(주 단위 업무량, 타겟 대비 성과, 전환율 등)를 자동화된 대시보드로 구현하고자 합니다.
◦
전환율 예시: CV 발송 대비 인터뷰 확정 비율, 인터뷰 진행 대비 오퍼 발행 비율, CV 발송 대비 오퍼 발행 비율 등.
◦
개인의 SWOT 분석, 정성적 목표, 수치화된 목표, 중장기 전략 등을 포함하여 개인의 커리어 개발을 지원하는 도구로도 활용합니다.
•
중요 참고사항:
◦
대시보드는 단순히 숫자를 보여주는 것을 넘어, 트렌드를 분석하고 개선점을 도출할 수 있도록 설계되어야 합니다.
12. KPI 대시보드 구체화 (표시 항목 및 데이터 소스)
•
구간별 주제: KPI 대시보드에 표시될 구체적인 항목 논의 및 기존 데이터베이스와의 연동 방안 모색
•
핵심 요점:
1.
대시보드 구성 요소 (기존 수동 관리 자료 기반):
•
담당자별 주 단위 KPI 현황
•
업무 태스크 목록
•
주간/월간 목표 설정 및 달성도
•
연간 타겟 대비 진행 상황
•
주요 전환율 (CV 대비 인터뷰, 인터뷰 대비 오퍼 등)
2.
ATS (Applicant Tracking System) 현황판 연동:
•
기존 ATS 페이지에 표시되던 담당자별 월별 석세스 금액(누적 합산) 등을 KPI 대시보드와 통합하여 한눈에 파악할 수 있도록 합니다.
3.
프로젝트 진행 현황판: 담당자별 진행 중 프로젝트 수, 각 프로젝트의 경과일, 주요 이슈 등을 관리하는 현황판도 대시보드 내에서 접근 가능하도록 합니다.
•
개인이 자신의 프로젝트 현황을 쉽게 볼 수 있도록 구성합니다.
4.
데이터 시각화 목표: ATS, TRM, CRM 세 가지 주요 영역의 현황을 한 페이지에서 파악하고, 실적 달성 현황을 명확하게 시각화합니다.
•
부가 설명:
◦
기존에 인라인(inline) 데이터로 관리되던 정보들을 개별 데이터베이스로 분리하고, 이를 대시보드에서 통합적으로 보여주는 형태(OKR 대시보드 예시)를 지향합니다.
•
중요 참고사항:
◦
대시보드는 개인의 업무 계획 수립 및 자기 점검을 돕고, 관리자는 전체적인 업무 흐름과 위험 요소를 파악하는 데 활용될 수 있도록 다각적인 관점을 제공해야 합니다.
13. KPI 대시보드 구현 (데일리/위클리/먼슬리 리포트 및 목표 설정)
•
구간별 주제: Notion을 활용한 KPI 대시보드 실제 구현 시작: 데일리, 위클리, 먼슬리 리포트 구조화 및 연간 목표 입력 방식 정의
•
핵심 요점:
1.
데이터 표시 순서: 데일리 -> 위클리 -> 먼슬리 -> 쿼터 -> 애뉴얼 순으로 드릴다운 또는 토글 형태로 제공합니다. (데일리, 위클리가 기본 노출)
2.
연간 목표 설정:
•
매년 11-12월경, '연간 목표' DB에 담당자별로 연도와 목표치를 수동 입력합니다. (예: "2026년 (김인홍)")
•
입력된 목표값은 Make를 통해 자동으로 하위 기간(먼슬리, 쿼터 등) 목표로 분배되고 관계형이 설정됩니다.
3.
데일리 플랜:
•
오늘, 이번 주, 지난주, 이번 달, 지난달, 전체 보기 등의 필터 제공.
•
개인별 자신의 데이터만 보이도록 설정 (관리자는 전체 확인 가능).
4.
위클리 리포트:
•
주요 항목: BD콜, 이력서(CV), 신규 고객 미팅, 인터뷰 순으로 배치.
•
각 항목별 목표 달성률 등을 표시.
•
주간 타겟을 직접 입력하고 관리할 수 있는 표(템플릿)를 페이지 내에 삽입. (DB와 연동되지 않는 단순 메모용)
•
부가 설명:
◦
위클리/먼슬리 리포트 페이지 내에 표 템플릿을 만들어, 회의 시 논의된 주간/월간 타겟을 기록하고 관리할 수 있도록 합니다.
◦
세부 데이터는 패널 형태로 클릭 시 보이도록 하여 메인 화면을 깔끔하게 유지합니다.
•
중요 참고사항:
◦
대시보드는 개인별 맞춤형 뷰와 관리자용 전체 뷰를 모두 제공해야 합니다.
14. KPI 대시보드 - 매출 현황 및 예상 매출 시각화
•
구간별 주제: 실제 매출(석세스) 및 예상 매출을 Notion 차트를 이용해 시각화하는 방안 논의 및 구현
•
핵심 요점:
1.
매출 데이터 소스: CV 데이터베이스의 '후보자 연봉', '계약 요율'을 곱하여 계산된 '수수료' 필드를 활용합니다.
•
월별 리포트 DB ( 먼슬리 리포트)에는 이미 합격 건수(석세스 횟수)가 집계되어 있습니다.
2.
실제 매출 시각화 (월별 석세스 금액):
•
먼슬리 리포트 DB의 담당자별 월별 계약 수수료 합계 금액을 차트(막대 그래프 등)로 표시합니다.
•
데이터가 충분히 쌓이면 연도별 추이, 개인별 성장 곡선 등을 꺾은선 그래프로도 표현 가능합니다. (향후 팔로우업)
3.
예상 매출 시각화:
•
CV 데이터베이스에 '매출 예정일' (월 단위 또는 날짜) 필드를 추가합니다.
•
각 CV가 성공했을 때 예상되는 출근(매출 발생) 시점을 이 필드에 입력합니다.
•
X축을 '매출 예정일'(월별 그룹화), Y축을 '수수료'로 하는 차트를 생성하여 담당자별/전체 예상 매출을 시각화합니다.
•
필터 조건: 인터뷰 단계 이상 (CV 제출 ~ 레퍼런스 체크)의 후보자 대상.
•
표시 기간: 최근 3개월 또는 '오늘 이후' 및 '이번 달 포함' 조건으로 필터링하여 현재와 미래의 예상 매출을 보여줍니다.
•
부가 설명:
◦
Notion의 차트 기능은 피벗 테이블과 같은 복잡한 데이터 집계는 어렵지만, 기본적인 그룹화 및 합산/평균 시각화는 가능합니다.
◦
예상 매출 데이터는 실제 확정 데이터가 아니므로, 참고용으로 활용하고 DB에 영구적으로 남길 필요는 없을 수 있습니다.
◦
차트 하단에 관련 CV 목록을 테이블 형태로 표시하여, 각 예상 매출의 근거 데이터를 쉽게 확인할 수 있도록 합니다. (담당자별 그룹화 가능)
•
중요 참고사항:
◦
정확한 매출 데이터를 위해서는 CV가 '합격' 상태로 변경될 때, 해당 CV와 먼슬리 리포트 DB 간의 관계형이 정확히 맺어져야 합니다. (이를 위한 자동화 버튼 또는 로직 필요)
◦
과거 데이터를 수동으로 입력하여 그래프를 만드는 것은 매우 трудоемкий (힘든) 작업이므로, 시스템 도입 이후의 데이터부터 누적 관리하는 것이 현실적입니다.
15. KPI 대시보드 - 주요 전환율 지표 추가 및 최종 검토
•
구간별 주제: KPI 대시보드에 주요 전환율 지표(CV 대비 인터뷰 등)를 추가하고, 전체 구성 검토 및 향후 일정 조율
•
핵심 요점:
1.
주요 전환율 지표 추가:
•
CV 발송 건수 대비 인터뷰 진행 건수 (CV 대비 Int)
•
인터뷰 진행 건수 대비 최종 합격(GP: Gross Profit 발생) 건수 (Int 대비 GP)
•
CV 발송 건수 대비 최종 합격 건수 (CV 대비 GP)
•
BD 콜 건수 대비 신규 고객(New Client) 계약 건수 (BD 대비 New Client)
•
이러한 비율 지표는 먼슬리, 쿼터, 애뉴얼 리포트 DB에 계산 필드로 추가하고, 대시보드에서는 해당 리포트 페이지 내부에서 확인할 수 있도록 합니다. (메인 대시보드 화면 복잡도 감소)
2.
대시보드 구성 완료:
•
매출 현황 (실제/예상)
•
데일리 플랜
•
주간/월간 리포트 (목표 설정 및 전환율 포함)
•
이 외에 추가로 필요한 KPI는 현재 없음.
3.
구현 방식: 전환율 계산은 각 기간별 리포트(먼슬리, 쿼터, 애뉴얼) DB 내에서 수식 필드를 사용하여 구현합니다.
•
부가 설명:
◦
전환율 지표는 담당자의 업무 효율성과 각 단계별 성공률을 파악하는 데 중요한 자료가 됩니다.
•
중요 참고사항:
◦
전환율 지표 추가 작업은 기존 DB 구조에 필드를 추가하고 수식을 설정하는 작업이므로, 별도 시간을 할애하여 진행하기로 합니다.
◦
다음 컨설팅 세션(6월 4일)에서 마무리 작업을 진행하고, 6월 13일에는 부산 현장에 방문하여 직원 대상 이메일 발송 시스템 세팅 등을 지원하기로 합니다. (강의 일정과 겹치지만 부산 내 이동으로 조율)
