손익이 두 개였던 지점

①의 대시보드는 월마감 엑셀을 그대로 보여줬습니다. 빠르고 편했지만 엑셀에 담긴 숫자가 맞는지는 말해주지 못했습니다.

한 지점의 추정 실적 보고서에서 건당 손익이 몇 달째 마이너스로 나왔습니다. 그런데 이 지점은 상점에서 받는 배송비보다 라이더 원가를 적게 주는 구조라, 구조적으로 적자가 나기 어려운 곳이었습니다. 회사 공식 실적 화면을 열어 보니 같은 달 같은 지점이 흑자였습니다.

먼저 “공식 숫자가 무엇으로 만들어지는지”를 확정했습니다. 공식 화면의 계산식을 읽고, 건별 원천 데이터로 같은 값을 다시 만들었습니다.

한 지점·한 달로 1원까지 맞춘 뒤 같은 계산을 파트 전체로 넓혔습니다. 원시 데이터를 내려받지 않고 BI 서버에서 바로 계산하게 해, 한 파트 80여 개 지점 손익이 30초 안에 나옵니다.

공식 산식이 확정되자 다른 숫자가 왜 다른지 항목별로 비교할 수 있게 됐습니다. 원가를 모아 보여주는 화면에서는 관제·관리비가 기본 라이더비와 거리 요금 양쪽에 한 번씩 들어가 있었고, 거리 요금도 두 번 더해지고 있었습니다.

3개 파트 200여 개 지점을 같은 방식으로 돌렸더니, 공식 기준으로는 흑자인데 다른 화면에서는 적자로 보이는 지점이 열에 아홉이었습니다. 반대로 공식 기준으로도 적자인 곳은 7%였고, 대부분 회사가 전액 부담하는 라이더 지급이 많은 지점이었습니다. 이중 계산을 걷어내자 “전부 적자”처럼 보이던 그림이 “이 몇 곳이 문제”로 바뀌었습니다.

공식 기준으로 손익이 나쁜 지점도 원인은 하나가 아니었습니다. 라이더비에 섞여 있던 할증을 상점·화주가 내는 돈, 배달앱과 회사가 반씩 내는 돈, 회사가 전부 내는 돈, 지점이 내는 돈으로 나눴습니다.

라이더 유형(협력사 · 자체 모집)과 주문 경로(법인 · 배달앱)를 교차하면 네 칸 중 어디서 손해가 나는지가 바로 보입니다. 이 네 칸이 이후 조건 협의의 출발점이 됐습니다.

도구는 BI 화면 위에서 북마크 하나로 열리고, 지점·화주·라이더 유형별 손익을 같은 기준으로 보여줍니다. 무엇을 어떤 기준으로 셀지는 제가 정했고, 구현은 AI(Claude)와 함께 했습니다.

이중 계산 건은 아직 정정되지 않았습니다. 추정 실적 보고서가 어떤 기준으로 만들어졌는지 작성 부서에 확인을 요청한 단계이고, 어느 쪽을 표준으로 삼을지는 정해지지 않았습니다. 그래서 이 기록도 “틀린 숫자를 고쳤다”가 아니라 “두 숫자가 왜 다른지 설명할 수 있게 됐다”로 씁니다.