부서별 업무 매뉴얼을 하나로 합치기 전에 공통 규칙과 부서별 예외를 구분해야 합니다. 문서 파일을 합쳐도 같은 용어가 서로 다른 뜻으로 쓰이거나 적용 조건이 충돌하면 직원과 AI 모두 어떤 규칙을 따라야 할지 알기 어렵습니다. 통합의 출발점은 목차 정리가 아니라 적용 범위 합의입니다.
모든 부서가 같은 방식으로 일할 필요는 없습니다. 공통으로 지킬 조건을 정하고 업무상 이유가 있는 차이는 예외로 남기면 됩니다. 다만 예외가 누구에게, 언제까지 적용되는지와 충돌할 때 누가 결정하는지가 함께 있어야 합니다.
먼저 조건을 맞추어야 하는 이유는 매뉴얼의 모순이 인계와 집계 오류로 이어질 수 있기 때문입니다. 같은 주문을 영업팀은 완료로, 운영팀은 보류로 이해하면 다음 행동이 달라집니다. 적용 범위를 정리하면 필요한 부서 차이는 유지하면서 공통 보고와 자동화에서 사용할 상태를 일관되게 해석할 수 있습니다.
같은 단어를 쓰는지부터 대조합니다
“접수 완료”, “마감”, “승인” 같은 말은 부서마다 뜻이 다를 수 있습니다. 영업팀은 고객 요청을 받으면 접수 완료라고 하고 운영팀은 필수 자료가 모두 들어와야 같은 상태로 표시할 수 있습니다. 이 상태를 하나의 시스템에 넣으면 서로 다른 건수가 집계됩니다.
매뉴얼을 읽으며 업무 상태, 거래처 구분, 금액 기준처럼 여러 부서가 함께 쓰는 용어를 골라 봅니다. 용어를 통일할 때는 단어만 바꾸지 말고 시작 조건과 완료 조건을 붙입니다. 기존 용어를 유지해야 하는 부서가 있다면 대응 관계를 적어 조회와 보고 때 혼동하지 않게 합니다.
설명용 예시로 “출고 완료”를 운송장 생성 시점으로 볼지 실제 인계 시점으로 볼지 정한다고 합시다. 두 상태가 모두 필요하면 하나를 없애기보다 “출고 준비”와 “운송사 인계”로 나눌 수 있습니다. 실제 업무의 차이를 지워서 문서만 간결하게 만들지 않습니다.
공통 규칙은 짧게, 예외 조건은 구체적으로 씁니다
| 구분 | 남길 내용 | 작성 예시 |
|---|---|---|
| 공통 규칙 | 모든 적용 부서가 지킬 조건 | 출고 요청에 품목과 수량 필수 |
| 부서별 예외 | 대상과 달라지는 처리 | 설치팀은 현장 일정을 추가 확인 |
| 유효 조건 | 적용 기간·대상·상태 | 설치가 포함된 주문에만 적용 |
| 결정 역할 | 규칙 충돌을 해결할 담당 | 운영 책임자와 설치 책임자 협의 |
| 근거와 버전 | 결정 이유와 참조 문서 | 현장 배정 필요, 확정본 위치 연결 |
표는 설명용 예시입니다. “부서 상황에 따라 예외 가능”이라고만 쓰면 현장의 판단을 문서 밖으로 밀어냅니다. 어떤 상황인지와 무엇이 달라지는지 적고, 조건이 미정이면 공통 규칙에 섞지 않은 채 검토 대상으로 둡니다.
공통 규칙을 부서 문서마다 복사하는 대신 정본을 연결하면 갱신 지점을 줄일 수 있습니다. 각 부서 문서에는 공통 규칙의 적용 버전과 추가 조건을 남깁니다. 공통 규칙이 바뀌었을 때 어느 부서 예외를 다시 확인해야 하는지도 연결해 둡니다.
충돌은 문장 다듬기로 해결하지 않습니다
두 매뉴얼의 조건이 다르면 먼저 이유를 듣습니다. 한쪽이 오래된 문서일 수도 있고, 서로 다른 고객 유형을 다룰 수도 있습니다. 업무상 이유가 있는 차이라면 조건을 나누고, 같은 상황에 서로 다른 지시가 있다면 책임자가 결정해야 합니다.
AI로 두 문서를 요약해 합치는 작업은 차이점을 찾는 데 활용할 수 있습니다. 하지만 충돌하는 두 규칙 중 하나를 AI가 자연스럽게 선택했다고 해서 회사의 합의가 된 것은 아닙니다. 후보 문장과 원문 위치를 나란히 놓고 담당자가 채택·보류 여부를 표시합니다.
결정이 끝나지 않은 항목은 통합본에서도 미확정으로 남겨 둡니다. 직원이나 AI가 그 상황을 만나면 확인할 역할을 안내해야 합니다. 모호한 부분을 매끄러운 문장으로 덮으면 실제 처리 시점에 충돌이 다시 나타납니다.
공통 규칙과 예외가 적용되는 흐름
실제 업무를 넣어 통합본을 검토합니다
통합본을 만든 뒤에는 각 부서가 최근 처리한 업무를 하나씩 가져와 봅니다. 공통 규칙만 적용되는 건, 부서 예외가 필요한 건, 조건이 겹치는 건을 나누어 따라갑니다. 어느 문서를 찾아야 했는지, 결과가 원래 업무 조건과 맞는지 기록합니다.
문서를 작성하지 않은 직원에게도 같은 사례를 맡겨 봅니다. 같은 조건에서 서로 다른 결론이 나온다면 용어, 적용 순서, 예외 설명 중 어디가 부족한지 확인합니다. 교육으로만 보완하기보다 문서에서 판단할 수 있도록 고칩니다.
시스템에 반영할 때는 문서 검토와 동작 검증을 구분합니다. 매뉴얼에 “설치 주문은 일정 확인”이라고 썼어도 ERP에서 일반 주문과 같은 경로로 넘어가면 규칙이 적용된 상태가 아닙니다. 입력 필드, 상태 변화, 담당자 알림에 해당 조건이 연결되는지 확인합니다.
통합 후 갱신할 사람까지 정합니다
공통 규칙의 책임자와 각 부서 예외를 관리할 사람을 따로 둡니다. 변경 요청에는 이유와 영향을 받는 업무를 적고, 확정 뒤에는 관련 문서와 시스템의 반영 여부를 남깁니다. 담당자 부재 시 검토할 대체 역할도 정해 둡니다.
ERP의 필드와 승인 흐름까지 연결해야 한다면 개발 전 요구사항 정리를 참고하세요. 문서와 다른 예외 업무가 시스템 밖에 남는 문제는 패키지 ERP의 한계를 다룬 글과 이어집니다.
통합 전에 확인할 항목
- 같은 업무 상태와 용어를 부서가 같은 뜻으로 쓰고 있습니까?
- 공통 규칙과 예외의 적용 조건이 분리되어 있습니까?
- 서로 다른 규칙이 충돌할 때 결정할 역할이 있습니까?
- 미확정 사항을 확정 규칙처럼 정리하지 않았습니까?
- 부서별 실제 사례로 문서와 시스템 동작을 확인했습니까?
시온랩의 맞춤 ERP·CRM은 현장 흐름에 맞춰 화면, 필드, 승인 규칙을 설계하는 도입 단위입니다. 부서별 매뉴얼을 통합할 때 정리한 용어와 예외 조건은 그 설계의 입력이 됩니다. 문서를 하나로 만드는 것에 앞서, 같은 조건에서 같은 처리가 이루어지는지부터 확인해 보세요.
