엑셀 발주를 ERP로 옮기기 전, 자동화할 일 하나를 고르는 법

발주 담당자의 일이 엑셀에서 끝나지 않는 경우가 있습니다. 재고표에서 품목을 골랐는데, 같은 거래처명·품목 코드·수량·단가를 다시 ERP에 입력합니다. 전송 뒤에는 성공 여부와 코드 오류도 확인해야 합니다.

SION.LAB이 공개한 이카운트 ERP 발주 자동화 구축 흐름도 이 장면에서 시작합니다. 엑셀을 확인하고, ERP 규격에 맞게 바꾸고, 전송 결과를 기록하고, 실패한 건을 복구합니다. 여기서는 성과 수치가 아니라 업무를 나눈 판단을 살펴봅니다.

중소기업 업무 자동화를 시작할 때 먼저 고를 것은 AI나 RPA 같은 도구가 아닙니다. 시작 조건과 끝나는 조건이 분명한 업무 한 덩어리입니다. 입력 자료와 처리 규칙, 사람이 확인할 지점, 실패했을 때 돌아갈 길까지 한 장에 적을 수 있다면 첫 후보로 검토할 수 있습니다.

자동화의 첫 산출물은 견적서가 아니라 현재 업무표입니다.

도구보다 먼저 업무 한 덩어리를 고릅니다

“발주를 자동화하고 싶다”는 말은 아직 범위가 넓습니다. 재고 판단, 수량 결정, ERP 전송, 결과 확인이 한 문장에 섞여 있기 때문입니다. 도구부터 정하면 범위가 늘고 예외의 담당자가 흐려집니다.

반대로 경계를 먼저 정하면 대화가 구체적으로 바뀝니다. 예를 들어 시작은 “담당자가 확정한 엑셀 파일이 지정 폴더에 들어온 시점”, 끝은 “ERP가 발주 번호를 돌려주거나 실패 사유가 검토 목록에 남은 시점”으로 잡을 수 있습니다. 재고를 더 살지 말지 결정하는 일은 이번 범위에서 제외할 수도 있습니다.

첫 후보를 고를 때는 다음 세 문장을 완성해 보세요.

• 이 일은 무엇이 들어오면 시작되는가?
• 시스템은 어떤 결과를 남기면 끝나는가?
• 끝나지 못했을 때 누가 어디에서 다시 시작하는가?

세 문장에 여러 부서와 시스템이 계속 추가된다면 한 번 더 나눕니다. 첫 파일럿은 한 담당자가 반복하는 한 흐름일수록 결과를 확인하기 쉽습니다.

발주 업무를 입력·규칙·실행·확인·복구로 나눕니다

발주 자동화 화면의 Tree View는 단순한 화면 장식이 아닙니다. 엑셀의 한 줄을 거래처·부서·프로젝트·품목 단위로 구조화하고, 각 품목의 코드와 수량이 ERP가 받을 수 있는 형태인지 확인하기 위한 업무 지도입니다.

이 다섯 단계가 중요한 이유는 자동화 범위와 책임을 동시에 보여주기 때문입니다. “엑셀을 읽는다”는 입력이고, “이 수량이 적절한가”는 판단이며, “ERP가 받았는가”는 완료 확인입니다. 서로 다른 성격의 일을 한 버튼에 묶지 않아야 규칙이 바뀌거나 오류가 생겨도 해당 단계만 고칠 수 있습니다.

좋은 후보는 반복 횟수보다 실패를 설명할 수 있습니다

많이 반복된다는 이유만으로 좋은 자동화 후보가 되지는 않습니다. 입력 형식이 매번 달라지거나, 잘못 처리했을 때 되돌릴 수 없거나, 결과를 확인할 담당자가 없다면 오히려 수동 작업보다 위험해질 수 있습니다. 다음 세 조건을 함께 봐야 합니다.

첫째, 반복성이 있습니다. 같은 시작 신호와 비슷한 입력 자료가 정기적으로 들어옵니다. 주기가 일정하지 않아도, 같은 화면과 같은 열을 반복해서 확인한다면 후보가 될 수 있습니다.

둘째, 규칙과 판단을 구분할 수 있습니다. 필수값 누락, 코드 불일치, 허용 범위처럼 문장으로 적을 수 있는 조건은 시스템이 확인할 수 있습니다. 반면 거래 관계, 계약 해석, 긴급 구매처럼 맥락에 따라 답이 달라지는 결정은 승인 단계로 남겨야 합니다.

셋째, 복구할 수 있습니다. 대표 이미지의 로그처럼 INFO·WARNING·ERROR를 나누는 이유는 실패를 없다고 가정하지 않기 위해서입니다. 어느 입력이 실패했는지, 이미 성공한 건을 다시 보내지 않아도 되는지, 수동 처리로 넘길 기준이 있는지를 먼저 정해야 합니다.

한 조건이라도 설명하기 어렵다면 입력 양식을 통일하거나 담당자별 처리 방식을 합치는 일이 먼저일 수 있습니다. 개발하지 않는 결론도 정상적인 진단 결과입니다.

사람에게 남길 판단은 실패의 종류에서 드러납니다

실패했다고 모두 같은 방식으로 재시도하면 안 됩니다. 부동산 문서 발급·재시도 공개 Works는 한 요청 안에서도 문서별 진행 상태를 따로 보존하는 구성을 보여줍니다. 연결 지연처럼 다시 시도할 수 있는 실패와, 인증·권한·대상 식별처럼 사람이 확인해야 하는 종단 실패를 구분해야 이미 발급된 문서까지 처음부터 반복하지 않습니다.

AI가 답을 만드는 업무도 같은 원리입니다. 스마트스토어 AI 응대 공개 Works는 생성한 답변을 신뢰도와 상태에 따라 승인 대기·검수 필요·수동 처리로 나누는 구성을 보여줍니다. 이 글에서는 공개된 성과 수치를 일반화하지 않고, “어떤 답변을 사람이 읽고 승인해야 하는가”를 화면에 남긴 설계 판단만 살펴봅니다.

시스템은 형식 변환, 필수값 검사, 일시 오류 재시도처럼 예측 가능한 구간을 맡습니다. 사람은 권한이 없거나 확신이 낮은 결과, 취소하기 어려운 실행, 거래·법률·안전 판단을 맡습니다. 이 경계를 업무표에 적어야 책임도 분명해집니다.

15분 업무표를 직접 작성해 봅니다

아래 표를 복사해 반복 업무 하나만 적어 보세요. 완벽한 요구사항 정의서가 아니라, 현재 일하는 방식에서 모르는 부분을 찾는 도구입니다. 한 칸에 여러 행동이 들어가면 행을 나누고, 담당자마다 답이 다르면 아직 합의가 필요한 항목으로 표시합니다.

표를 쓴 뒤에는 “사람 판단”과 “실패 복구”를 먼저 검토하세요. 둘 다 비어 있다면 담당자의 머릿속에 있던 예외가 아직 드러나지 않은 것일 수 있습니다. 최근 오류 메일이나 메신저 질문에서 조건을 찾아보세요.

첫 파일럿은 작동보다 운영 가능성을 확인합니다

첫 파일럿의 목표는 “100% 자동화”가 아닙니다. 정상과 실패가 모두 관찰되고, 담당자가 멈추거나 되돌릴 수 있으면 다음 범위를 판단할 근거가 생깁니다. 맞춤 ERP·CRM 구축 과정도 화면 전에 업무 흐름·권한·연동·운영 인계를 정합니다.

시작 전에 최소한 다음 항목을 합의합니다.

• 결과와 알림을 매일 확인할 운영 담당자
• 자동 실행을 멈춰야 하는 오류와 영향 범위
• 완료를 증명할 발주 번호·파일·로그 같은 기록
• 재시도 횟수와 같은 입력의 중복 전송 방지 기준
• 시스템을 쓸 수 없을 때 돌아갈 수동 처리 순서
• 파일럿 종료 뒤 확대·수정·중단을 결정할 날짜

이 기준이 준비되면 개발사와의 첫 대화도 달라집니다. 기능 목록을 늘어놓는 대신 “어디부터 어디까지 자동으로 처리하고, 어떤 경우에 누구에게 돌려줄지”를 함께 검토할 수 있습니다.

상담을 요청하기 전, 반복 업무 3개의 발생 빈도·입력 자료·대표 예외·최종 확인자를 적어 두세요. 완성된 문서가 아니어도 현재 업무의 경계를 확인하는 데 충분합니다.