부서마다 숫자가 다른 회사, AI 분석 전에 맞춰야 할 기준

같은 달의 실적을 놓고 영업과 운영의 숫자가 다릅니다. 영업은 계약한 건을 세고 운영은 서비스를 시작한 건을 셉니다. 대표는 어느 숫자가 맞는지 묻지만 두 부서는 각자의 자료가 정확하다고 설명합니다. 이 상황에 AI를 연결해 보고서를 만들면 서로 다른 숫자가 더 보기 좋은 문장으로 나올 수 있습니다.

AI 분석 전에 각 부서가 무엇을 한 건으로 세고, 어떤 날짜와 상태를 기준으로 포함했는지 확인해야 합니다. 이름이 같은 지표라도 포함 대상과 상태, 기준일이 다르면 다른 질문에 답하는 숫자입니다. 먼저 그 차이를 설명할 수 있어야 회사 전체의 현황을 함께 해석할 수 있습니다.

모든 부서가 하나의 숫자만 써야 한다는 뜻은 아닙니다. 계약한 건수와 시작한 건수는 각각 필요할 수 있습니다. 다만 둘을 같은 이름으로 보고하거나 차이를 오류로 취급하면 불필요한 재확인이 반복됩니다. AI에는 합의된 기준에 맞춰 자료를 정리하도록 하고, 기준을 정하는 판단은 업무를 아는 사람이 맡아야 합니다.

계약한 고객과 서비스를 시작한 고객은 다른 대상을 셉니다

가상 예시로 기업 교육 서비스를 운영하는 회사를 보겠습니다. 영업은 계약이 확정되면 신규 고객으로 등록합니다. 운영은 첫 교육을 진행해야 신규 고객으로 집계합니다. 같은 회사가 여러 교육 과정을 계약했을 때 한 고객으로 볼지 여러 신청 건으로 볼지도 부서마다 다릅니다. 누구도 입력을 잘못하지 않았는데 보고 숫자는 달라질 수 있습니다.

대표가 알고 싶은 것이 앞으로 제공할 서비스의 규모라면 계약 기록이 필요합니다. 지금 지원해야 하는 고객을 보고 싶다면 시작한 서비스가 더 직접적인 자료일 수 있습니다. 한 숫자를 정답으로 고르기 전에 어떤 결정을 위한 질문인지 분명히 해야 합니다. 질문이 다르면 지표를 나누는 것이 혼선을 줄일 수 있습니다.

먼저 이름을 바꿔서 대상이 보이게 합니다. 신규 고객이라는 표현보다 신규 계약 고객, 서비스 시작 고객처럼 상태를 드러내는 방식입니다. 다만 이름만 구체적으로 바꿔도 포함 규칙이 다르면 문제는 남습니다. 계약 취소, 시작 연기, 기존 고객의 추가 계약을 어떻게 처리하는지 설명할 수 있어야 합니다.

AI로 고객 메모를 정리할 때도 같은 구분이 필요합니다. 계약 예정이라는 표현과 계약 확정이라는 표현을 섞어 집계하면 예정 건이 실적으로 들어갈 수 있습니다. 자유롭게 작성된 메모에서 후보 항목을 추리는 역할은 검토할 수 있지만, 최종 집계 상태는 확인된 업무 기록과 연결해야 합니다. 메모를 매끄럽게 요약했더라도 계약 체결 여부는 별도로 확인해야 합니다.

집계 기준을 맞출 때는 포함 여부가 애매한 거래를 살펴보세요

합계만 놓고 대조하면 담당자는 어느 행에서 차이가 났는지 다시 찾아야 합니다. 기준이 다른지 확인하려면 포함 여부가 애매한 실제 거래를 함께 보는 편이 좋습니다. 계약은 했지만 시작하지 않은 건, 취소 후 다시 신청한 건, 여러 부서가 나눠 맡은 건이 대표적인 검토 대상이 될 수 있습니다.

앞의 가상 회사에서는 교육을 연기한 고객을 생각해볼 수 있습니다. 계약은 유효하지만 해당 기간에는 교육이 없습니다. 영업의 계약 현황에는 남고 운영의 실제 진행 현황에는 빠지는 것이 각 질문에 맞을 수 있습니다. 이 차이를 하나의 오류로 고치려 하면 오히려 필요한 정보가 사라집니다.

이때는 두 숫자가 각각 무엇을 설명하는지 확인하고, 보고에서 어떻게 구분해 표시할지 합의합니다. 계약 이후 시작까지의 상태를 구분하면 차이가 발생한 이유를 추적할 수 있습니다. 같은 거래가 어느 지표에 포함되고 제외되는지 설명할 수 있어야 합니다.

포함 여부가 애매한 거래가 드물더라도 처리 원칙은 남겨두는 편이 좋습니다. 담당자가 바뀌었을 때 같은 건을 다르게 집계하지 않도록 하기 위해서입니다. 모든 가능한 예외를 미리 열거할 필요는 없습니다. 새로운 예외가 나오면 누가 판단하고 어디에 기준을 추가할지 정하면 됩니다.

고객, 계약, 작업 가운데 무엇을 한 건으로 볼까요

고객 하나에 계약이 여러 개 있고 계약 하나에 작업이 여러 번 발생할 수 있습니다. 한 고객의 작업이 세 번 있었다면 고객은 1개사, 작업은 3건입니다. 작업마다 적힌 고객 이름을 그대로 세면 고객 수가 실제보다 많아질 수 있습니다. 자료를 연결하기 전에 집계 단위를 적어야 합니다. 회사 내부에서 당연하게 쓰던 ‘건’이라는 말이 실제로 무엇을 뜻하는지 확인하는 과정입니다.

여러 지점을 가진 고객도 생각해볼 수 있습니다. 본사 계약을 기준으로 하나의 고객으로 볼 수도 있고 실제 서비스를 제공하는 현장별로 운영 대상을 셀 수도 있습니다. 두 방식이 모두 필요하면 고객 단위와 현장 단위를 구분해서 관리합니다. 어느 단위인지 드러내지 않은 합계로 부서 실적을 비교하면 해석이 흔들릴 수 있습니다.

AI가 이름이 비슷한 기록을 묶도록 시도하더라도 고객이나 계약을 확정하는 기준을 생략할 수는 없습니다. 같은 이름의 다른 거래가 있을 수 있고, 이름이 다른 같은 거래도 있을 수 있습니다. 실제로 같은 대상을 가리키는지 확인할 근거를 남겨야 숫자의 차이를 다시 검토할 수 있습니다.

기준일과 상태 변경을 정하지 않으면 매번 지난달 숫자가 달라집니다

지표 정의에는 어떤 날짜를 기준으로 포함하는지도 들어갑니다. 요청일, 확정일, 시작일, 완료일은 서로 다릅니다. 업무가 여러 기간에 걸쳐 진행된다면 어느 날짜로 집계하느냐에 따라 같은 거래가 다른 달에 들어갈 수 있습니다. 보고 작성일과 집계 기준일도 구분해야 합니다.

가상 예시로 정기 관리 계약을 제공하는 회사가 있다고 하겠습니다. 요청은 이전 기간에 들어왔지만 실제 작업은 다음 기간에 끝났습니다. 요청량을 보면 접수 시점을, 완료한 작업을 보면 완료 시점을 사용할 수 있습니다. 두 지표를 비교할 때는 기간 차이를 고려해야 합니다. 담당자가 입력한 날만 기준으로 삼으면 실제 업무 발생 시점과 어긋날 수 있습니다.

또 하나는 마감 이후의 변경입니다. 이미 보고한 계약이 취소되거나 완료 표시가 잘못됐다는 사실을 뒤늦게 발견할 수 있습니다. 이전 보고를 수정할지 현재 보고에서 변경 내용을 보여줄지 회사의 운영 목적에 맞게 정해야 합니다. 내부 운영 보고에서는 당시 마감 기준과 뒤늦게 확인한 변경을 구분해 보여주면, 대표가 이전 판단을 다시 살펴볼 필요가 있는지 알 수 있습니다.

변경 전후의 관계를 남기지 않고 숫자만 덮어쓰면 대표는 자료가 틀렸는지 상황이 달라졌는지 알기 어렵습니다. 변경된 건과 사유를 확인할 수 있으면 추가 질문이 구체적이 됩니다. AI로 전후 차이를 요약할 때도 수정 사실과 실제 업무의 변화를 구분하도록 요구해야 합니다.

지표마다 짧은 설명서를 두면 AI가 사용할 기준도 분명해집니다

지표 설명서는 복잡한 문서일 필요가 없습니다. 같은 이름을 보고 같은 자료를 선택할 수 있을 만큼의 내용이면 됩니다. 정의만 써두고 원자료와 담당자를 빼면 실제 집계에서 다시 해석이 갈릴 수 있습니다. 다음은 앞의 교육 서비스 가상 예시에 적용한 구성입니다.

회사에서 사용하는 지표마다 이 항목을 작성하고, 실제 업무에 필요한 예외를 보완하면 됩니다. 원자료를 찾는 위치도 함께 적어 집계 담당자가 기준과 기록을 대조하도록 합니다. 핵심은 설명서를 읽은 다른 담당자가 같은 자료를 보고 같은 포함 여부를 판단할 수 있는가입니다. 애매한 표현이 있으면 연기나 취소된 거래를 대입해 수정합니다.

FlowOS는 AI 분석을 준비할 때 집계 기준과 그 기준에 해당하는 원자료를 함께 정리하도록 제안합니다. 지표를 계산하는 규칙과 AI가 설명을 정리하는 역할이 구분돼야 결과를 검토하기 쉽습니다. 계산 결과가 왜 달라졌는지 설명할 때도 어떤 기준이 바뀌었는지 추적할 수 있어야 합니다.

기준 설명을 AI에게 전달했다고 해서 일치가 자동으로 보장되는 것은 아닙니다. 선택한 자료와 출력이 합의한 정의에 맞는지 실제 기록으로 확인해야 합니다. 담당자는 이 설명서를 참고해 어떤 기록을 집계할지 정하고, 계산 결과와 AI의 설명이 같은 기준을 따랐는지 검토합니다.

모든 부서의 숫자를 하나로 합칠 필요는 없습니다

부서마다 필요한 관점은 다를 수 있습니다. 영업은 앞으로 들어올 일을 보고 운영은 현재 감당해야 할 일을 보며 대표는 두 흐름 사이의 차이를 볼 수 있습니다. 이 차이를 없애려고 하나의 지표로 압축하면 회사의 상태를 설명하는 정보가 줄어들 수 있습니다.

공통으로 맞춰야 할 부분과 별도로 유지할 부분을 구분합니다. 같은 고객을 식별하는 기준이나 상태의 의미는 함께 정할 수 있습니다. 반면 부서별로 보는 기간과 업무 범위는 목적에 따라 다를 수 있습니다. 별도 지표에는 그 차이가 이름과 설명에서 드러나야 합니다.

예를 들어 완료한 작업 수와 고객에게 최종 확인을 받은 작업 수를 둘 다 관리할 수 있습니다. 전자는 내부 처리 현황을, 후자는 인계까지 마친 현황을 보여줍니다. 두 숫자가 다른 것은 원인 분석의 출발점이 될 수 있습니다. 어느 쪽을 대표 보고에 쓸지는 보고 목적에 따라 정하면 됩니다.

문제가 되는 것은 다른 숫자의 존재보다 서로 비교할 수 없는 숫자를 같은 기준인 것처럼 읽는 일입니다. AI로 부서 보고를 합칠 때도 단위나 기준일이 다른 항목을 하나의 합계로 묶지 않도록 확인해야 합니다. 합치기 어렵다는 사실을 보고에 남기는 것이 억지로 일치시킨 숫자보다 유용할 수 있습니다.

빈값과 해당 없음도 구별해야 합니다

표에 아무 값이 없다는 사실만으로 대상이 없다고 판단할 수는 없습니다. 아직 입력하지 않은 것인지, 해당 업무가 발생하지 않은 것인지, 자료를 확인할 수 없는 것인지에 따라 의미가 다릅니다. 이 상태를 같은 값으로 바꾸면 부서별 기록의 완성도 차이가 실적 차이처럼 보일 수 있습니다.

가상 회사에서 어떤 교육 과정의 종료 확인이 비어 있다고 생각해보겠습니다. 교육이 취소됐을 수도 있고 정상적으로 끝났지만 담당자가 입력하지 않았을 수도 있습니다. 전자는 운영 상태이고 후자는 기록 상태입니다. AI가 문맥으로 추정해 빈칸을 메웠다면 확정된 완료 기록과 구분해 검토해야 합니다. 자료가 없다는 사실도 보고에서 숨기지 않습니다.

이를 위해 모든 칸에 복잡한 사유를 적을 필요는 없습니다. 판단에 영향을 주는 항목부터 미입력, 해당 없음, 확인 중 같은 상태를 업무에 맞게 구분할 수 있습니다. 담당자가 그 상태를 선택할 수 있어야 하고, 확인 중인 항목을 누가 정리할지도 알아야 합니다. 상태 이름만 추가하고 후속 확인이 없으면 빈칸이 다른 표시로 바뀔 뿐입니다.

기준을 맞춘 뒤에는 각 부서가 별도로 만든 합계만 대조하지 말고, 같은 원자료의 일부를 각자 집계해볼 수 있습니다. 결과가 다르면 어떤 행의 포함 여부가 갈렸는지 설명하도록 합니다. 합계가 같아도 포함한 거래가 서로 다를 수 있으므로, 취소되거나 연기된 거래처럼 집계 여부가 애매한 건을 함께 확인합니다. 이렇게 하면 집계 기준을 읽은 담당자들이 같은 의미로 이해했는지 확인할 수 있습니다.

대표가 이 과정에 참여할 때는 모든 행을 직접 확인할 필요는 없습니다. 어떤 차이는 별도 지표로 유지하고 어떤 차이는 공통 기준으로 맞출지 결정하면 됩니다. 부서별 보고 목적을 유지하면서 회사 차원에서 비교할 지표와 집계 기준을 정하는 역할입니다.

기준을 바꿀 때는 과거와의 비교 조건도 함께 남깁니다

사업 방식이 바뀌면 지표 정의도 바뀔 수 있습니다. 고객 단위를 새롭게 구분하거나 완료 상태를 더 엄격하게 정하는 변화는 필요할 수 있습니다. 문제는 기준 변경을 설명하지 않은 채 이전 기간과 비교하는 것입니다. 숫자의 변화가 운영 변화인지 집계 방식 변화인지 구분해야 합니다.

새 기준을 적용한 날짜와 바꾼 이유를 남깁니다. 과거 자료를 새 기준으로 다시 계산할 수 있다면 그 여부를 표시하고, 어렵다면 직접 비교하기 어려운 구간임을 설명합니다. 이전 기준을 무조건 유지할 필요도 없고 과거 자료를 모두 다시 만들어야 하는 것도 아닙니다. 대표가 차이를 알고 해석할 수 있어야 합니다.

AI가 보고 문장을 작성할 때도 기준 변경 정보를 함께 확인할 수 있게 합니다. 집계 기준의 변경을 빠뜨리면 실제 영업이나 운영 실적이 좋아지거나 나빠진 것처럼 설명할 수 있습니다. 변경된 기준과 확인된 업무 변화를 나눠 보여주는 방식이 필요합니다. 실제 원인을 모르면 모른다고 남겨야 합니다.

기준 변경을 승인하는 사람과 이를 자료에 반영하는 사람도 구분할 수 있습니다. 결정은 됐지만 일부 파일에만 반영되면 다시 숫자가 갈립니다. 변경된 설명서와 적용 상태를 함께 확인하면 부서별 집계 방식이 조금씩 달라지는 일을 발견하기가 쉬워집니다.

다음번에 부서 숫자가 다르게 나오면 합계를 다시 계산하라고 지시하기 전에, 같은 거래 하나를 선택해 각 부서가 그 거래를 포함하거나 제외한 이유를 물어보세요. 대상·단위·상태·기준일 가운데 어디에서 판단이 갈렸는지 찾는 것이 출발점입니다. 각 지표의 기준을 합의한 뒤에는 AI가 그 기준에 맞는 자료를 찾아 설명하도록 시험할 수 있습니다.

부서별 보고 숫자가 달라 AI 분석을 시작하기 어렵다면, 차이가 난 보고서와 집계 기준을 준비해 FlowOS에 문의할 수 있습니다.

함께 읽으면 좋은 글

• 지표의 원자료와 보고 기준 시각 연결하기