프랜차이즈 수발주 시스템 구축 가이드, 주문 한 건이 발주에서 정산까지 흐르는 길

프랜차이즈 수발주 시스템이란 가맹점이 본사에 상품과 식자재를 주문하고, 본사가 그 주문을 모아 물류센터로 넘기고, 출고와 입고를 확인한 뒤 단가를 적용해 정산까지 이어지는 흐름을 하나로 관리하는 업무 시스템이에요. 가맹점 쪽에서 보면 주문을 넣는 발주이고, 본사 쪽에서 보면 주문을 받는 수주라서 둘을 합쳐 수발주라고 불러요. 화면 한두 개로 끝나는 기능이 아니라, 본사와 가맹점과 물류센터 사이를 흐르는 주문 데이터의 배관에 가까워요.

가맹점이 몇 곳일 때는 카카오톡과 전화와 엑셀 시트로도 돌아가요. 흔들리기 시작하는 건 점포가 늘어나는 구간이에요. 마감 시각을 넘긴 주문이 섞이고, 같은 품목을 다른 이름으로 적어 보내고, 출고한 수량과 받은 수량이 다르다는 말이 월말에야 올라와요. 이때 본사 담당자가 마주하는 질문은 대개 같아요. 시스템을 사야 할까요, 만들어야 할까요. 그 판단을 하려면 먼저 우리 본사가 무엇을 정해야 하는지부터 알아야 해요.

이 글은 점주가 보는 화면을 설계하는 글이 아니에요. 주문 한 건이 발주 버튼에서 출발해 본사 집계를 지나 물류 출고와 입고 확인을 거쳐 월 정산에 닿기까지, 각 구간에서 무엇이 확정되고 그 결과가 어디에 기록되는지를 따라가요. 점주가 쓰는 앱의 화면 구성과 기능 목록은 가맹점주가 손에 쥐는 앱에는 어떤 기능부터 담아야 하는지 다룬 글에 따로 정리해뒀으니 그쪽을 함께 보면 좋아요.

수발주 시스템은 점주앱과 무엇이 다른가요?

이 둘을 같은 것으로 이야기하는 본사가 있어요. 그런데 개발을 맡기는 순간 둘은 다른 물건이 돼요. 점주앱은 가맹점주가 손에 쥐는 화면이에요. 로그인하고, 품목을 고르고, 수량을 넣고, 주문 내역을 확인하는 곳이죠. 수발주 시스템은 그 버튼을 누른 뒤에 벌어지는 일 전부예요. 주문이 본사 기준으로 어떻게 모이고, 어떤 규칙으로 걸러지고, 어떤 형식으로 물류에 전달되고, 어떤 단가가 붙어 청구서가 되는지를 담당해요.

그래서 점주앱만 잘 만들면 문제가 풀릴 거라고 기대했다가 실망하는 자리가 생겨요. 앱은 나왔는데 본사 담당자는 여전히 엑셀을 열어 주문을 합치고 있어요. 주문을 받는 창구만 바뀌었을 뿐 집계와 출고와 정산은 손으로 하고 있으니까요. 둘 다 필요하지만 개발 범위를 나눌 때는 서로 다른 덩어리로 봐야 해요. 화면 수로 범위를 세면 점주앱은 비교적 또렷하게 떨어지는 반면, 수발주 쪽은 화면이 거의 없는 기능에 규칙이 가장 촘촘하게 얽혀 있어요.

주문 한 건은 발주부터 정산까지 어떤 경로로 흐르나요?

수발주 시스템을 설계할 때 가장 먼저 그려야 할 그림은 화면 목록이 아니라 주문 한 건의 여정이에요. 점주가 발주를 넣는 순간부터 그 금액이 정산에 반영되는 순간까지 몇 개의 손을 거치는지, 각 손에서 무엇이 확정되는지를 적어 내려가면 필요한 기능이 자연스럽게 드러나요.

일반적인 경로는 이렇게 흘러요. 점주가 발주를 등록해요. 마감 시각이 되면 그 회차의 주문이 잠겨요. 본사가 전 점포 주문을 품목별로 합쳐요. 합친 수량을 물류센터가 다루는 단위로 바꿔 출고 지시를 만들어요. 물류가 피킹하고 출고해요. 배송이 도착하고 점주가 입고를 확인해요. 차이가 있으면 반품이나 차감으로 처리해요. 확정된 수량에 단가를 곱해 월 정산이 만들어져요.

이 여덟 구간에서 시스템이 하는 일은 뜯어보면 단순해요. 각 구간의 결과를 기록으로 남기고, 다음 구간으로 넘길 때 형식을 맞춰주고, 앞 구간으로 되돌아갈 때 무엇을 바꿀 수 있는지 규칙을 지키게 하는 거예요. 다만 그 규칙을 시스템이 정해주지는 않아요. 본사가 정해줘야 해요. 아래 표는 각 구간에서 무엇이 확정되고, 그 확정값이 어디에 원본으로 남아야 하는지를 정리한 거예요.

지금 사람이 메우고 있는 구간은 어떻게 찾아내나요?

시스템을 알아보기 전에 해볼 일이 하나 있어요. 지난 회차 하나를 골라 주문이 지나간 길을 그대로 따라가 보는 거예요. 점주가 보낸 메시지부터 물류로 넘어간 파일, 도착 후 오간 연락, 월말 청구서까지 순서대로 늘어놓으면 어느 구간이 시스템 밖에서 처리되고 있는지가 눈에 보여요.

따라가면서 표시할 지점은 네 가지예요. 첫째, 같은 값을 사람이 두 번 입력한 자리예요. 점주가 보낸 수량을 담당자가 엑셀에 옮겨 적었다면 그 자리가 첫 번째 구멍이에요. 둘째, 담당자가 되물은 자리예요. 이 주문이 맞는지, 이 품목이 무엇인지 다시 물었다면 규칙이 시스템이 아니라 사람 머릿속에 있다는 뜻이에요. 셋째, 결정은 내려졌는데 기록이 남지 않은 자리예요. 마감을 넘긴 주문을 받아주기로 한 판단이 대화창에만 있다면 근거가 사라진 거예요. 넷째, 같은 값이 두 곳에 다르게 적혀 있는 자리예요.

이렇게 표시한 지점의 개수보다 위치가 더 중요해요. 구멍이 발주 접수와 집계 사이에 몰려 있다면 주문 수집과 집계 자동화가 먼저고, 출고와 입고 확인 사이에 몰려 있다면 물류 연동이 먼저고, 입고 확인과 청구 사이에 몰려 있다면 정산 정확도가 먼저예요. 같은 수발주 시스템이라도 어디부터 여는지가 달라져요. 규칙으로 적을 수 없는 판단이 너무 많다면 개발보다 운영 정책 정리가 앞이에요.

발주 마감 시각은 왜 시스템보다 먼저 정해야 하나요?

마감 시각은 사소해 보이지만 시스템 전체의 뼈대예요. 마감이 정해져야 집계가 언제 돌지 정해지고, 집계 시각이 정해져야 물류에 넘길 시점이 정해지고, 그래야 배송일이 계산돼요. 마감이 흐릿하면 그 뒤 모든 일정이 흐릿해져요.

정해야 할 것은 시각 하나가 아니에요. 요일마다 마감이 다른지, 공휴일에는 어떻게 되는지, 마감 직전에 넣은 주문을 수정하거나 취소할 수 있는지, 마감을 넘긴 주문은 반려할지 다음 회차로 자동으로 넘길지를 정해야 해요. 특히 마지막 항목이 구조를 갈라요. 넘긴다고 정하면 시스템은 회차라는 개념을 정식으로 가져야 하고, 반려한다고 정하면 알림과 재등록 흐름이 필요해요. 둘은 만드는 방식이 달라요.

회차 개념을 제대로 잡아두면 나중에 편해져요. 주문 한 건이 어느 회차에 속하는지, 그 회차가 지금 어떤 상태인지가 값으로 남으면 집계와 출고와 정산이 모두 그 값을 기준으로 움직일 수 있어요. 반대로 날짜만으로 회차를 대신하면 하루에 두 번 마감하는 품목군이 생기는 순간 구조를 다시 손대야 해요.

현장에서 자주 나오는 요구가 하나 더 있어요. 특정 점포에만 마감을 늘려달라는 요청이에요. 신규 점포나 대형 점포에 예외를 주는 운영은 드물지 않은데, 이걸 시스템에 넣을지 담당자가 수동으로 풀어줄지를 미리 정해야 해요. 예외를 시스템에 넣기로 하면 권한 관리와 이력 기록이 따라와요. 예외가 늘어날수록 개발 범위가 커지니, 착수 전에 어떤 예외까지 허용할지 선을 그어두는 편이 안전해요.

발주 단위와 최소 주문 수량은 어디까지 정해둬야 하나요?

발주 단위는 집계가 어긋나는 원인으로 자주 지목되는 자리예요. 같은 품목이라도 물류에서는 박스로 움직이고 점포에서는 낱개로 쓰는 경우가 있어요. 점주가 낱개 수량으로 주문했을 때 시스템이 박스로 올림할지, 낱개 출고를 허용할지, 올림한다면 남는 수량을 어떻게 안내할지를 정해야 해요. 이 규칙이 없으면 물류에서 사람이 매번 판단하게 되고, 그 판단은 기록에 남지 않아요.

최소 주문 수량과 최소 주문 금액도 같은 성격이에요. 품목별로 걸지, 주문 전체에 걸지, 배송 권역별로 다르게 걸지에 따라 검증 로직이 달라져요. 냉장과 냉동과 상온을 따로 배송한다면 배송 온도대별로 최소 금액이 따로 필요할 수도 있어요. 온도대를 나누기로 하면 주문이 하나여도 출고와 배송은 여러 건으로 갈라진다는 점을 처음부터 구조에 넣어야 해요.

품목 코드 체계도 이 단계에서 정리해야 해요. 본사 기간계에 쓰는 코드, 물류센터가 쓰는 코드, 점주에게 보여주는 이름이 서로 다른 경우가 있어요. 셋을 잇는 매핑을 누가 관리하고 신규 품목이 생겼을 때 어디서 먼저 등록하는지를 정해두지 않으면, 시스템을 잘 만들어도 새 품목이 들어올 때마다 흐름이 멈춰요.

단가는 누가, 언제, 어떤 기준으로 붙나요?

단가는 수발주 시스템에서 조용히 사고가 나는 자리예요. 주문할 때 보이는 단가와 정산할 때 적용되는 단가가 다르면 점주는 곧바로 이의를 제기해요. 그래서 어느 시점의 단가를 확정 단가로 볼지 먼저 정해야 해요. 주문 등록 시점인지, 마감 시점인지, 출고 시점인지에 따라 시스템이 저장해야 할 값이 달라져요.

단가표가 하나가 아닌 경우도 있어요. 신규 점포 지원 단가, 프로모션 기간 단가, 물량 구간별 단가처럼 층이 쌓이면 어느 것이 우선인지 규칙이 필요해요. 이 우선순위를 문서로 적어두지 않으면 개발 쪽에서 임의로 정하게 되고, 나중에 왜 이 금액이 나왔는지 설명할 사람이 없어져요.

단가 변경 이력도 중요해요. 지난달 주문을 다시 열었을 때 그때의 단가가 그대로 보여야 해요. 현재 단가표만 저장하는 구조로 만들면 과거 정산을 재현할 수 없어요. 개발을 맡길 때 이 요구를 명확히 적는 편이 좋아요. 이런 업무 규칙을 문서로 옮기는 방법은 업무 규칙을 어떻게 적어야 개발팀이 같은 그림을 보는지 정리한 글을 참고하면 도움이 돼요.

본사 집계 단계에서는 무엇이 결정되나요?

집계는 전 점포의 주문을 품목별로 합치는 단계예요. 단순 덧셈처럼 보이지만 실제로는 여러 판단이 섞여 있어요. 어떤 주문을 이번 회차에 포함할지, 취소된 주문을 뺄지, 권역별로 따로 합칠지, 긴급 주문을 별도로 처리할지가 모두 이 단계에서 결정돼요.

어긋나는 지점은 대개 세 곳이에요. 첫째는 마감 경계예요. 마감 직전 수정과 취소가 집계에 반영되는 시점이 애매하면 합계가 흔들려요. 둘째는 단위 환산이에요. 낱개 주문을 박스로 바꾸는 계산이 집계 전에 일어나는지 후에 일어나는지에 따라 총량이 달라져요. 셋째는 예외 주문이에요. 신메뉴 테스트 물량이나 본사 직영점 주문처럼 규칙에서 벗어난 건을 어디에 넣을지 정해두지 않으면 담당자가 손으로 빼거나 더해요.

집계 결과가 손으로 수정되기 시작하면 시스템의 신뢰가 무너져요. 수정이 필요하다면 수정 자체를 기능으로 만들고 누가 언제 무엇을 바꿨는지 기록에 남기는 편이 나아요. 엑셀로 내려받아 고치고 다시 올리는 흐름은 편해 보이지만 추적이 끊겨요. 집계 결과를 물류로 넘긴 뒤에 수정이 들어오면 어떻게 할지도 함께 정해야 해요. 넘긴 뒤에는 잠그기로 할지, 회신 전까지는 정정 파일을 다시 보내기로 할지가 운영 정책이에요.

물류센터가 자사냐 위탁이냐에 따라 무엇이 달라지나요?

이 질문은 개발 범위를 크게 바꿔놓는 갈림길이에요. 본사가 직접 물류센터를 운영하면 재고와 피킹과 출고를 시스템 안에서 다룰 수 있어요. 위탁을 쓰면 그 영역은 위탁사 시스템이 갖고 있고, 우리는 파일이나 연동으로 주고받아야 해요.

위탁을 쓸 때 가장 먼저 확인할 것은 위탁사가 어떤 형식으로 주문을 받고 어떤 형식으로 결과를 돌려주는지예요. 정해진 규격이 있으면 우리 시스템이 그 규격에 맞춰야 하고, 없으면 파일 규격을 우리가 정의해 협의해야 해요. 주고받는 주기도 중요해요. 하루 한 번 파일로 주고받는지, 건별로 즉시 주고받는지에 따라 점주가 보는 상태 정보의 정확도가 달라져요.

혼합 구조도 드물지 않아요. 상온은 위탁, 냉장은 자사처럼 나뉘면 주문 하나가 서로 다른 경로로 갈라져요. 이때 점주 화면에서는 하나의 주문으로 보이되 내부적으로는 여러 출고 건으로 나뉘는 구조가 필요해요. 이 구조를 처음부터 잡지 않고 나중에 끼워 넣으면 데이터 구조를 크게 고쳐야 해요.

출고 수량과 입고 수량이 다를 때는 어떻게 맞추나요?

주문한 수량, 출고한 수량, 실제 받은 수량이 항상 같지는 않아요. 결품이 생기고, 파손이 생기고, 오배송이 생겨요. 이 차이를 언제 누가 확정하느냐가 정산 다툼의 핵심이에요.

정해야 할 것은 세 가지예요. 입고 확인 기한, 미확인 시 자동 처리 기준, 차이 신고 방법이에요. 기한을 두지 않으면 확인하지 않은 주문이 쌓여 정산이 밀려요. 자동 처리 기준을 두지 않으면 기한이 지난 주문을 어떻게 볼지 매번 사람이 판단해요. 차이 신고에 사진이나 증빙을 요구할지도 이 단계에서 정해야 하고, 그러면 파일 업로드와 보관 기간이 요구사항에 추가돼요.

이 부분을 나중에 정하려다 정산 기능을 다시 짜게 되는 본사가 있어요. 입고 확인이 정산의 입력값이기 때문이에요. 확인되지 않은 수량으로 청구할 수 없다면, 정산은 입고 확인 상태를 참조해야 하고 그 상태는 기한 규칙에 따라 자동으로 바뀌어야 해요. 순서를 거꾸로 잡으면 개발이 길어져요.

차이를 어떤 방식으로 되돌릴지도 미리 정해두면 좋아요. 다음 회차에 이월해 다시 보낼지, 그 자리에서 금액을 차감할지, 반품 전표를 만들지에 따라 데이터가 남는 모양이 달라져요. 세 가지를 모두 쓰는 본사라면 어떤 상황에 어떤 처리를 쓰는지 기준까지 적어둬야 담당자마다 다르게 처리하는 일이 줄어요.

재고와 결품은 어느 단계에서 확정해야 하나요?

결품을 언제 알려주느냐는 점주 경험을 크게 좌우해요. 주문 시점에 재고를 확인해 아예 주문을 막을 수도 있고, 집계 후 물류가 확정할 때 알려줄 수도 있고, 출고 시점에 확정할 수도 있어요. 앞으로 갈수록 점주는 편해지지만 시스템은 더 정확한 실시간 재고 정보를 필요로 해요.

주문 시점에 재고를 확인하려면 재고 데이터가 항상 최신이어야 해요. 위탁 물류를 쓰면서 재고를 하루 한 번만 받아오는 구조라면, 주문 시점 재고 확인은 오히려 잘못된 정보를 주게 돼요. 재고를 숫자로 보여주지 않고 주문 가능 여부만 표시하는 선택도 있어요. 보여줄 수 있는 정확도를 먼저 확인하고 결정하는 게 좋아요.

대체품 규칙도 함께 정해야 해요. 결품이 났을 때 유사 품목으로 대체할지, 대체한다면 점주 동의를 받을지, 단가는 무엇을 적용할지가 모두 결정 사항이에요. 대체를 허용하면 주문 한 건에 원래 품목과 대체 품목이 함께 남아야 하고, 정산은 실제 나간 품목을 기준으로 계산돼야 해요. 부분 출고를 허용할지도 같은 자리에서 정해요. 허용하면 미출고 잔량을 이월할지 소멸시킬지까지 이어서 정해야 해요.

기존 ERP와는 어디서 붙고 어디서 끊어야 하나요?

본사에 이미 기간계 시스템이 있다면 수발주 시스템은 새로 짓는 집이 아니라 기존 건물에 붙이는 통로예요. 중요한 건 어디까지 새 시스템이 갖고 어디부터 기존 시스템에 넘길지를 정하는 일이에요. 경계가 흐리면 같은 데이터가 양쪽에 따로 쌓여 서로 다른 숫자를 말하게 돼요.

보통 품목 마스터와 거래처 정보와 회계 전표는 기존 시스템이 원본을 갖는 편이 자연스러워요. 수발주 시스템은 주문과 출고와 입고 확인을 담당하고, 확정된 정산 데이터를 넘겨요. 반대로 단가표는 기간계에 있을 수도 있고 수발주 쪽에 있을 수도 있어서 본사마다 달라요. 어느 쪽이든 원본이 하나여야 한다는 원칙만 지키면 돼요.

연동 방식과 주기도 계약 전에 정리해야 해요. 실시간 연동인지 일 단위 배치인지, 실패했을 때 재시도를 어떻게 할지, 같은 건이 두 번 전송됐을 때 어떻게 걸러낼지가 실제 개발 공수를 크게 바꿔요. 연동 범위를 어디까지 계약에 넣어야 하는지는 외부 시스템 연동을 외주로 맡길 때 책임 범위를 어디까지 잡아야 하는지 다룬 글에 정리해뒀어요. 오래된 사내 시스템을 함께 손봐야 한다면 기존 시스템을 옮길 때 무엇이 먼저 깨지는지도 같이 보면 좋아요.

POS 데이터는 발주에 어디까지 쓸 수 있나요?

점포 판매 데이터에는 무엇이 얼마나 팔렸는지가 쌓여 있어요. 이 데이터를 발주와 이으면 판매량 기반 추천 발주나 자동 발주를 생각하게 돼요. 끌리는 기능이지만 전제가 꽤 무거워요.

먼저 판매 품목과 발주 품목이 같은 단위가 아니에요. 음료 한 잔이 팔렸다고 원두가 얼마나 나갔는지 계산하려면 레시피 정보가 필요해요. 이 레시피를 누가 관리하고 메뉴가 바뀔 때 어떻게 갱신하는지가 정해지지 않으면 추천 수량은 금방 틀어져요. 그리고 판매 데이터를 어떤 방식으로 받아올 수 있는지, 전 점포가 같은 방식으로 데이터를 보내고 있는지도 확인해야 해요.

그래서 첫 버전에서는 판매 데이터 연동을 보조 정보로 두는 선택이 현실적이에요. 지난 기간 발주 이력을 기준으로 기본 수량을 채워주는 정도만 해도 입력 부담은 줄어요. 자동 발주는 데이터 신뢰가 쌓인 뒤에 붙여도 늦지 않아요. 첫 범위를 어디까지 잡을지 고민된다면 1차 개발 범위를 어디서 끊어야 하는지 다룬 글이 판단에 도움이 돼요.

월 정산과 미수금은 시스템의 어디에 들어가나요?

정산은 수발주의 끝이자 본사가 시스템을 만드는 진짜 이유인 경우가 있어요. 주문이 많아질수록 청구 계산이 무거워지고, 계산이 틀리면 가맹점 관계가 상해요.

정산 기능을 설계할 때 먼저 정할 것은 정산 주기와 마감일이에요. 월 단위인지 반월 단위인지, 마감일 이후 올라온 입고 확인과 반품을 이번 정산에 넣을지 다음으로 넘길지를 정해야 해요. 그다음은 청구 항목 구성이에요. 상품 대금 외에 배송비, 로열티, 광고 분담금처럼 본사마다 다른 항목이 붙어요. 이 항목들이 수발주 시스템 안에서 계산되는지, 회계 쪽에서 합쳐지는지도 정해야 해요.

결제와 미수 처리도 빠질 수 없어요. 자동이체인지 계좌 입금인지, 미수가 쌓였을 때 발주를 막을지 경고만 할지가 운영 정책이에요. 발주를 막기로 하면 그 판단 기준과 해제 절차를 시스템에 넣어야 하고, 누가 해제할 수 있는지까지 함께 설계해야 해요. 정산서를 확정한 뒤에 금액을 고칠 수 있는지도 미리 정해두면 좋아요. 고칠 수 있게 만든다면 확정 이전 값과 이후 값이 모두 남아야 근거가 지켜져요.

이력과 감사 추적은 어디까지 남겨야 하나요?

수발주 시스템이 주는 가치는 화면이 아니라 기록이에요. 월말에 금액을 두고 이야기가 오갈 때 근거가 되는 건 누가 언제 무엇을 했는지에 대한 기록이거든요. 그래서 어떤 행위를 이력으로 남길지를 설계 단계에서 목록으로 정해두는 편이 좋아요.

최소한 이 다섯 가지는 남겨야 나중에 되짚을 수 있어요. 주문의 등록과 수정과 취소, 마감과 회차 상태 변경, 집계 결과의 수동 조정, 출고와 결품의 확정, 정산 금액의 확정과 정정이에요. 각각에 대해 행위자와 시각과 변경 전후 값이 함께 남아야 의미가 있어요. 변경 후 값만 남기면 무엇이 어떻게 바뀌었는지 알 수 없어요.

보관 기간과 조회 권한도 함께 정해야 해요. 이력은 쌓일수록 무거워지니 얼마나 오래 보관할지, 오래된 이력을 별도로 보관할지 정해두는 편이 좋아요. 그리고 지난 시점의 정산을 다시 계산할 수 있어야 하는지도 요구사항으로 명확히 적어야 해요. 재현이 필요하다면 단가와 규칙이 시점별로 저장되는 구조가 되어야 하고, 이 요구는 나중에 붙이기 어려운 축에 들어가요.

솔루션을 살지 만들지는 무엇으로 가르나요?

시중에는 수발주 기능을 제공하는 상용 솔루션이 여럿 있어요. 사는 쪽이 빠르고 초기 비용이 가벼운 경우가 있어요. 그런데 사는 선택이 언제나 옳은 건 아니에요. 판단을 가르는 기준은 대체로 네 가지예요.

첫째, 우리 운영 규칙이 표준에서 얼마나 벗어나 있는지예요. 마감과 단가와 배송 구조가 일반적인 형태라면 솔루션이 잘 맞아요. 온도대가 복잡하거나 단가 층이 여러 겹이거나 권역별 규칙이 다르면 설정으로 담기 어려워요. 둘째, 기존 기간계와 물류 시스템과의 연동 가능성이에요. 솔루션이 열어주는 연동 방식이 우리 환경과 맞는지 확인해야 해요. 셋째, 데이터 소유예요. 주문과 정산 데이터를 우리가 자유롭게 꺼낼 수 있는지가 나중에 크게 작용해요. 넷째, 점포 수가 늘어날 때 비용이 어떻게 변하는지예요.

중간 선택도 있어요. 표준 기능은 솔루션을 쓰고 본사 고유 규칙만 별도로 만들어 붙이는 방식이에요. 다만 이 구조는 두 시스템 사이의 경계를 명확히 해야 유지가 돼요. 어느 쪽으로 가든 견적을 받게 되는데, 항목별로 무엇을 비교해야 하는지는 개발 견적서에서 무엇을 읽어야 비교가 되는지 정리한 글을 보면 정리가 돼요. 인력 투입 기준으로 산정된 견적이라면 투입 공수가 타당한지 어떻게 따져보는지도 함께 확인해보세요.

점포가 늘어날 때 배관의 어느 구간부터 다시 설계해야 하나요?

점포가 늘 때 배관에서 먼저 모양이 바뀌는 곳은 마감과 물류 구간이에요. 처음에는 마감이 하루 한 번이고 물류센터도 하나예요. 점포가 지역으로 퍼지면 센터가 늘고, 센터마다 배송 일정이 달라지고, 그러면 마감도 센터별로 갈라져요. 회차 개념을 미리 잡아두지 않았다면 이 시점에 구조를 다시 손대야 해요.

그다음은 집계와 정산의 처리 시간이에요. 집계는 마감 직후 정해진 시간 안에 끝나야 물류가 그날 안에 움직일 수 있어요. 점포와 품목이 늘면 이 계산이 길어지고, 정산 마감도 같이 길어져요. 처음부터 과하게 설계할 필요는 없지만, 집계와 정산이 일정 안에 끝나야 하는 작업이라는 점은 설계에 반영해두는 편이 좋아요.

세 번째는 예외 규칙이에요. 점포가 적을 때는 예외를 담당자가 기억해요. 늘어나면 기억이 안 돼요. 어느 점포가 마감 예외인지, 어느 점포가 별도 단가인지, 어느 품목이 특정 점포만 취급인지가 값으로 남아 있지 않으면 사람이 매번 확인하게 돼요. 예외를 데이터로 관리하는 구조인지가 확장 국면에서 차이가 벌어져요.

마지막은 이력의 무게예요. 주문과 출고와 정산 이력은 지우기 어려운 데이터라 계속 쌓여요. 조회 화면이 느려지거나 기간 조회가 버거워지는 형태로 먼저 드러나요. 오래된 이력을 어떻게 다룰지는 초기에 정답을 낼 필요는 없지만, 오래 보관해야 한다는 전제만큼은 처음 설계에 넣어두는 게 좋아요.

업체에 보내기 전에 어떤 규칙 문서를 만들어야 하나요?

수발주 시스템은 업무 규칙이 곧 기능이에요. 규칙이 정해지지 않은 상태에서 개발을 시작하면 개발사는 질문을 하고 본사는 회의를 하고 일정은 밀려요. 반대로 규칙이 정리돼 있으면 견적도 정확해지고 업체 간 비교도 쉬워져요.

아래 표는 착수 전에 문서로 확정해두면 좋은 규칙과, 각각을 어느 수준까지 적어야 하는지를 정리한 거예요. 문장으로 길게 쓸 필요는 없어요. 항목마다 선택지를 적고 그중 무엇을 고를지 표시하는 정도면 충분해요. 중요한 건 고르지 않은 항목을 비워둔 채로 두지 않는 거예요.

이 목록을 업체에 보내는 문서로 바꾸는 방법은 따로 정리해뒀어요. 무엇을 요구할지 담는 형식은 개발 업체에 보낼 요청 문서를 어떻게 쓰는지를, 규칙을 화면과 예외 단위로 쪼개는 방법은 기능을 어느 수준까지 적어야 개발이 흔들리지 않는지를 보면 돼요. 포텐랩도 이런 프로젝트를 시작할 때 규칙 정리부터 함께 하는 편이에요.

수발주 시스템 구축은 어떤 순서로 열어야 안전한가요?

한 번에 전부 만들려는 시도는 위험해요. 수발주는 실제 물건과 돈이 움직이는 시스템이라 틀리면 바로 손해로 이어져요. 그래서 흐름을 끊어서 순서대로 여는 방식이 안전해요.

먼저 발주 등록과 마감과 집계까지만 만들어 일부 점포에서 돌려봐요. 물류 출고는 기존 방식을 유지한 채로요. 여기서 품목 코드와 단위 규칙이 실제로 맞는지 드러나요. 다음으로 출고 지시와 입고 확인을 붙이고, 차이 처리 흐름을 검증해요. 마지막으로 정산을 연결해요. 정산을 가장 늦게 붙이는 이유는 앞 단계의 데이터가 정확해야 정산이 의미를 갖기 때문이에요.

단계마다 무엇을 확인하고 넘어갈지를 미리 정해두면 개발사와 본사 모두 편해져요. 수발주에서는 화면이 뜨는지보다 숫자가 맞는지가 확인 기준이에요. 같은 주문 묶음을 손으로 계산한 결과와 시스템이 계산한 결과가 일치하는지를 회차 단위로 맞춰보는 방식이 확실해요. 완성된 기능을 넘겨받을 때 무엇을 확인해야 하는지는 개발 결과물을 어떤 기준으로 확인하고 인수하는지 정리한 글에 담아뒀어요.

오픈 이후도 미리 생각해둬야 해요. 수발주는 규칙이 계속 바뀌는 시스템이라 오픈이 끝이 아니라 시작이에요. 단가 정책이 바뀌고 물류센터가 늘고 품목이 추가될 때 누가 어떻게 반영할지를 계약 단계에서 정해두는 편이 좋아요. 운영과 개선을 누가 맡을지는 오픈 이후 운영과 개선의 범위를 어떻게 계약에 담는지 다룬 글을 참고하면 도움이 돼요.

지금 본사가 먼저 해야 할 일은 무엇인가요?

시스템을 알아보기 전에 종이 한 장을 꺼내 주문 한 건의 여정을 그려보세요. 점주가 발주를 넣는 순간부터 정산까지 몇 번의 손을 거치는지, 각 손에서 무엇이 확정되는지, 그 확정이 어디에 기록되는지를 적어요. 기록되지 않는 확정이 보이면 그 자리가 지금 사람이 메우고 있는 구멍이에요.

그 구멍의 개수와 위치가 곧 우리에게 필요한 시스템의 모양이에요. 구멍이 집계와 출고 사이에 몰려 있다면 물류 연동이 중심이고, 입고 확인과 정산 사이에 몰려 있다면 정산 정확도가 중심이에요. 모양이 보이면 솔루션을 살지 만들지도 판단할 수 있고, 업체를 만나서도 같은 언어로 이야기할 수 있어요.

자주 묻는 질문

수발주와 구매·조달은 무엇이 다른가요?

구매와 조달은 본사가 외부 공급처에서 물건을 사 오는 과정이에요. 수발주는 그렇게 확보한 물건을 가맹점이 본사에 주문해서 받아 가는 과정이고요. 흐르는 방향이 달라서 다루는 규칙도 달라요. 구매는 공급처와의 계약과 입고가 중심이고, 수발주는 마감과 집계와 정산이 중심이에요. 두 흐름이 같은 품목 마스터를 쓰는 경우가 많아 코드 체계를 한쪽으로 통일해두면 나중이 편해요.

본사에 물류센터가 없고 협력사가 점포로 바로 배송하면 수발주 시스템이 필요한가요?

필요해요. 물건이 본사 창고를 거치지 않아도 주문을 모으고, 협력사별로 나눠 전달하고, 배송 결과를 받아 정산으로 잇는 일은 그대로 남거든요. 오히려 협력사가 여럿이면 주문 한 건이 여러 곳으로 갈라지기 때문에 어느 품목을 어느 협력사에 보낼지, 결과를 어떤 형식으로 회신받을지를 더 일찍 정해둬야 해요.

수발주 시스템은 웹으로 만들어야 하나요, 앱으로 만들어야 하나요?

본사 관리 화면은 표와 집계가 많아 웹이 편해요. 점주가 쓰는 발주 화면은 매장에서 휴대폰으로 열게 되는 경우가 많아 모바일 사용성이 중요하고요. 다만 설치를 강제하면 초기 전환에서 이탈이 생길 수 있어서, 모바일 웹으로 먼저 열고 반응을 본 뒤 앱을 붙이는 방식도 선택지로 올라와요.

개발 기간은 어떻게 가늠하나요?

기간을 좌우하는 건 화면 수가 아니라 규칙의 복잡도와 연동 대상 수예요. 단가 층이 여러 겹이고, 온도대가 나뉘고, 기간계와 위탁 물류와 판매 데이터를 모두 이어야 한다면 같은 화면 수라도 훨씬 오래 걸려요. 규칙 문서를 먼저 만들고 나서 업체에 기간을 받는 편이 정확해요.

기존 엑셀 발주 이력을 새 시스템으로 옮길 수 있나요?

옮길 수는 있지만 어디까지 옮길지 정해야 해요. 과거 주문을 전부 옮기려면 그때의 품목 코드와 단가를 현재 체계에 맞춰야 하는데 여기서 손이 많이 들어가요. 참고용이라면 읽기 전용으로 보관하고, 신규 주문부터 새 체계로 쌓는 선택이 현실적인 경우가 있어요.

세금계산서 발행까지 수발주 시스템에서 해야 하나요?

보통은 기존 회계 시스템이 담당하는 편이 자연스러워요. 수발주 시스템은 확정된 청구 금액과 그 근거를 만들어 넘기는 역할을 하고, 발행과 전표는 회계 쪽이 맡는 구조예요. 두 곳에서 각각 발행하면 금액이 어긋났을 때 어느 쪽이 맞는지 판단할 수 없어요.

긴급 발주나 행사 물량은 정규 회차와 어떻게 나눠 처리하나요?

별도 유형으로 구분해 두는 편이 나아요. 정규 회차에 섞으면 집계 합계가 흔들리고, 나중에 왜 이 수량이 나갔는지 되짚기 어려워져요. 유형을 나누면 승인 절차와 단가 적용을 따로 걸 수 있고, 배송도 별도 건으로 처리할 수 있어요. 대신 누가 긴급 건을 승인할 수 있는지 권한을 함께 정해야 해요.

오픈 이후 운영 규칙이 바뀌면 매번 개발이 필요한가요?

어떤 항목을 설정 값으로 빼두었느냐에 달려 있어요. 마감 시각, 최소 주문 기준, 단가표처럼 자주 바뀌는 항목은 담당자가 화면에서 직접 바꿀 수 있게 만들어두면 개발 없이 운영할 수 있어요. 반대로 정산 계산 방식이나 승인 흐름이 바뀌면 개발이 필요하니, 무엇을 설정으로 열어둘지 초기에 합의해두는 게 좋아요.

함께 읽으면 좋은 글

• 점주가 쓰는 앱에는 무엇부터 담나
• 견적서 항목을 뜯어보는 법
• 요구사항을 문서로 굳히는 법