심사·승인은 위챗 그룹에 의존: 심사 흐름, 공문, 조직 권한을 어떻게 시스템으로 구현할 것인가

서두: 출장 승인은 그룹 메시지에 의존하고, 승인 담당자를 찾는 것은 물어보는 데 의존한다

약 200명 규모의 제조업체에서 연초 이후 첫 출장 신청은 이렇게 처리됐다: 직원이 그룹 채팅방에서 담당자를 @멘션하면, 담당자는 ‘OK’라고 답하고 직원은 이를 캡처해 저장한다. 월말에 재무팀이 출장 경비를 정산할 때는 캡처한 내용을 하나하나 예산과 대조한다. 연말에 인사팀이 ‘직원 출장 일수’를 집계하려고 하니, 캡처가 불완전하고 부서 간 데이터가 맞지 않는다는 사실이 드러났다.

이는 개별적인 현상이 아니다. 국내 많은 기업에서 승인 업무는 다음과 같은 방식으로 진행된다:

• 사람을 찾는 것은 물어보는 데 의존한다: 신입사원이 입사한 첫 주에 가장 자주 묻는 질문은 “휴가를 내려면 누구에게 승인을 받아야 하나요? 경비를 정산하려면 누가 심사하나요?”이다.
• 그룹 메시지를 증빙으로 삼는다: 위챗이나 딩딩 그룹 채팅방에서 ‘@사장님 승인 완료’라는 메시지를 승인 통과로 간주하여 사후 감사를 할 수 없다.
• 부서 간 데이터가 맞지 않는다: 영업부는 고객 방문이 이미 승인되었다고 보지만, 마케팅부는 아직 승인되지 않았다고 주장하고, 재무팀은 영업부의 캡처를 근거로 지급을 진행한다.
• 권한은 구두로만 관리된다: 어떤 매니저가 퇴사했지만 권한이 회수되지 않아, 새로 들어온 직원은 전임 매니저가 승인한 계약이 누구에게 남아 있는지 모른다.

이러한 문제들의 근본 원인은 ‘승인이 얼마나 복잡한가’에 있지 않고, 승인 프로세스가 시스템에 반영되지 않았기 때문이다. 그룹 메시지, 구두, 캡처는 모두 임시적 매개체일 뿐이며, 부족한 것은 구조화되고 기록이 남으며 추적 가능한 매개체다. OA 시스템(사무자동화 시스템)은 바로 이 일을 구조화하는 역할을 한다: ‘누가, 어떤 사안을, 언제, 누구에게, 어떤 규정에 따라 승인했는지, 승인 후 데이터가 어떻게 정리되는지’를 한 가지 승인 흐름 속에 모두 담아낸다.

01 비즈니스를 어떻게 분해할 것인가: 승인 흐름의 3층 구조

승인 업무를 분해해 보면, 실제로는 세 가지 층으로 나뉜다:

1. 사안 층: 직원이 ‘출장, 휴가, 경비 정산, 계약, 인감 사용, 구매’ 등 구체적인 사안을 발의하며, 각 사안에는 금액, 일수, 첨부파일, 관련 비즈니스 객체(예: 출장 신청은 판매 주문과 연결되고, 경비 정산은 영수증과 연결됨)가 포함된다.
2. 프로세스 층: 사안이 한 노드에서 다음 노드로 흘러가며, 각 노드의 승인 담당자는 부서, 직급, 금액, 품목 등에 따라 동적으로 결정되며 고정되어 있지 않다.
3. 데이터 층: 승인 통과 또는 거절 후에는 데이터가 비즈니스 시스템(HR, 재무, 영업, 계약 데이터베이스)으로 다시 반영되어야 하며, 승인 흐름 안에만 머물러서는 안 된다.

세 층의 관계는 다음과 같다: 사안이 입구이고, 프로세스가 줄기이며, 데이터가 출구이다. OA 시스템을 구축할 때 프로세스만 설계하고 데이터 출구를 따로 마련하지 않으면, 승인 흐름은 고립된 섬이 되고, 사안만 설계하고 프로세스를 설계하지 않으면 ‘양식 작성 시스템’으로 전락하게 된다.

02 어떻게 설계할 것인가: 동적 노드, 권한 매트릭스, 기록 남기기의 3종 세트

노드 설계: 승인 담당자는 고정되어 있지 않다

많은 OA 시스템에서는 처음부터 승인 담당자를 고정해 놓는다: ‘출장 신청 → 부서장 → HR → 총괄이사’. 그 결과 부서장이 교체되거나, HR이 행정부로 통합되거나, 총괄이사가 출장을 가면 시스템 전체가 혼란에 빠진다.

올바른 방법은 다음과 같다: 승인 담당자는 규칙에 따라 동적으로 결정된다. 규칙의 차원은 일반적으로 네 가지다:

• 부서 차원: 신청자가 속한 부서의 현재 책임자와 연결된다(조직도를 실시간으로 조회).
• 직급 차원: 금액, 일수, 계약 금액에 따라 서로 다른 구간과 심사 등급이 설정된다.
• 역할 차원: 계약 금액이 50만 위안을 초과하면 법무팀이 반드시 개입해야 하고, 해외 출장 시에는 안전 및 규정 준수가 필수로 합동 서명이 필요하다.
• 대리인 차원: 승인 담당자가 휴가나 출장을 갈 경우 자동으로 대리인에게 전환되며, 대리인은 조직 관계나 HR에 의해 지정된다.

이 네 가지 차원을 조합해 ‘규칙 표현식’으로 만들어, 프로세스 엔진이 규칙에 따라 실시간으로 노드를 계산하도록 한다 승인 담당자의 이름을 고정하지 않는다. 부서 이동이나 조직 개편이 있어도 프로세스 템플릿을 수정할 필요가 없다.

권한 설계: 메뉴, 데이터, 필드의 3단계 권한

권한은 ‘시스템에 들어갈 수 있는가’가 아니라, 세 단계로 나뉜다:

• 메뉴 단계: 해당 모듈을 볼 수 있는지 여부(일반 직원은 ‘조직도 관리’를 볼 수 없다).
• 데이터 단계: 해당 데이터를 볼 수 있는지 여부(영업 1부는 본 부서 직원의 경비 정산만 볼 수 있고, 영업 2부의 데이터는 볼 수 없다).
• 필드 단계: 해당 데이터의 특정 필드를 볼 수 있는지 여부(일반 승인자는 신청자의 급여 필드를 볼 수 없지만, HR은 볼 수 있다).

세 단계 권한을 분리한 뒤, OA 시스템은 복잡한 조직 구조—그룹-지사-부서-팀—을 지원할 수 있게 된다. 부서 간 데이터는 ‘내가 볼 수 있는 내 선 + 내가 그 선의 책임자’라는 두 가지 규칙을 병행해 관리된다.

기록 남기기 설계: 승인 로그의 7가지 요소

모든 승인 작업에는 반드시 7가지 요소를 남겨야 한다:

1. 작업자: 누가 클릭했는지.
2. 작업 시간: 초 단위까지 정확히 기록된다.
3. 작업 동작: 동의, 거절, 이관, 추가 서명, 취소.
4. 작업 의견: 거절 의견은 반드시 기재해야 하며, 동의는 비워둘 수 있다.
5. 노드 위치: 현재 프로세스의 어느 단계인지.
6. 관련 데이터 스냅샷: 승인 시 비즈니스 객체의 필드 값(금액, 첨부파일)을 원래 상태 그대로 보존하며, 사후에 비즈니스 객체를 수정해도 승인 기록은 변경되지 않도록 한다.
7. 장치와 IP 흔적: 어떤 장치, 어떤 IP에서 발송되었는지(규정 준수 감사를 위해).

이 7가지 요소 중 하나라도 빠지면 감사 시 서로 책임을 미루게 된다. 흔히 발생하는 오류는 ‘작업 의견은 비워둘 수 있다’는 점인데, 이로 인해 거절 사유가 없어져 직원이 반복적으로 재신청하면서 승인 흐름이 지연된다.

03 어떻게 개발할 것인가: 프로세스 엔진, 양식 엔진, 메시지 버스의 3종 세트

OA 개발의 핵심은 N개의 페이지가 아니라 세 가지 엔진이다:

프로세스 엔진

프로세스 엔진은 코드를 직접 작성하지 않고, 구성만으로 프로세스를 실행할 수 있다. 지원해야 하는 특성은 다음과 같다:

• 직렬, 병렬, 합동 서명, 혹은 서명의 4가지 기본 흐름—정식 입사 신청은 직렬(HR → 상급자 → CEO), 구매는 병렬(재무와 구매 담당자가 동시에 심사)이다.
• 조건 분기: 금액, 품목, 신청자의 직급에 따라 분류되며, 5천 위안 이하의 경우 간편 흐름, 5천에서 5만 위안 사이에는 부서와 재무의 이중 심사를, 5만 위안 이상에는 CEO까지 추가한다.
• 되돌리기와 거부: 신청인에게 거부, 임의의 노드로 거부, 이전 노드로 거부 등 세 가지 유형의 거부를 모두 지원해야 합니다.
• 추가 서명과 전달 서명: 결재 담당자는 업무를 동료에게 넘길 수 있으며(전달 서명), 다른 동료를 함께 참여시켜 심사할 수도 있습니다(추가 서명).
• 취소와 폐기: 신청인은 아직 결재가 완료되지 않은 사항을 취소할 수 있고, 관리자는 이상이 있는 사항을 폐기할 수 있습니다.

프로세스 엔진이 구축된 후, 코드 작성 없이도 새로운 종류의 결재를 추가할 수 있게 됩니다, 그림을 그리거나 양식을 구성하는 것만으로도 바로 서비스에 적용할 수 있습니다. 이것이 OA가 ‘결재 외주 개발’과 차별화되는 핵심입니다.

양식 엔진

양식은 ‘제로 코딩 설계’를 지향합니다: 필드 유형(텍스트, 숫자, 날짜, 첨부파일, 관련 비즈니스 객체), 검증 규칙, 필수 입력 및 선택 입력, 표시·숨김 조건 등 모든 항목을 시각적으로 드래그 앤 드롭 방식으로 구성할 수 있습니다. 이렇게 하면 HR 부서에서 경비 정산 필드를 조정하거나 영업 부서에서 계약서 관련 필드를 추가하더라도, IT 부서의 일정 조율이 필요하지 않습니다.

양식 엔진은 다음을 지원해야 합니다:

• 필드 단위 권한: 같은 양식에서도 각 결재 담당자가 보는 필드가 서로 다릅니다(일반 결재 담당자는 신청인의 휴대폰 번호를 볼 수 없습니다).
• 필드 연동: “계약 유형 = 서비스 계약”을 선택하면, 서비스 계약 고유의 필드가 자동으로 확장됩니다.
• 데이터 반영: 승인이 완료된 후 업무 시스템(계약 상태, HR 출근 관리, 재무 전표)에 자동으로 반영됩니다.

메시지 버스

승인 통과 또는 거절 시, 신청자와 관련 업무 시스템(HR, 재무, 영업) 모두에게 즉시 알림이 전송됩니다. 메시지 버스를 통해 일괄 발송:

• 시스템 내 알림: 사이트 내 메시지와 처리 대기 항목 추가.
• IM 알림: 기업 위챗, 딩딩, 피수 웹훅을 통해 해당 그룹 또는 개인에게 전달.
• 이메일 및 문자 메시지: 중요한 단계별 백업 알림(계약 승인, 해외 출장 등).
• 업무 시스템 메시지: 승인이 완료되면 업무 시스템의 처리 대기 항목에 메시지를 작성합니다(재무는 경비 정산 대기, HR은 입사 대기).

메시지 버스는 ‘장식’이 아니라 승인 흐름의 ‘순환 고리’입니다—알림이 없으면 신청자는 다음 단계에서 누구에게 연락해야 할지 몰라 전체 프로세스가 막히게 됩니다.

마무리: 실행 순서, 리스크 및 지표

OA 시스템 도입은 세 단계로 나뉩니다:

1. 1차(1개월): 휴가, 출장, 경비 정산 등 높은 빈도의 세 가지 업무를 도입해 전 직원을 포괄합니다. 먼저 위챗 그룹 내 승인을 시스템으로 옮깁니다—이 세 가지만 옮겨도 부서 간 데이터가 즉시 일치합니다.
2. 2차(2~3개월): 계약, 인감 사용, 구매, 결제 등 중간 빈도의 네 가지 업무를 도입해 재무 시스템과 연동합니다. 이번 단계에서는 데이터 반영까지 연결해야 합니다(계약 승인이 완료되면 계약 데이터베이스에 자동으로 보관).
3. 3차(필요에 따라): 성과 평가, 승진, 정규직 전환, 채용, 퇴사 등 인사 전반의 업무를 도입합니다. 이 단계는 HR 주도로 진행되며, HR 주요 데이터까지 연동해야 합니다.

일반적인 리스크:

• 규칙이 지나치게 유연함: 승인 흐름 설정이 너무 자유로워 결과적으로 다음 단계가 누구인지 아무도 모릅니다. 원칙: 프로세스 템플릿은 30개를 넘지 않아야 하며, 그 이상이 되면 통제 불능 상태가 됩니다.
• 대리인 미배정: 승인 담당자가 출장 중인데 대리인을 배정하지 않아 프로세스가 3일 동안 멈춰 아무도 심사하지 못하는 경우. 시스템은 “프로세스가 24시간 이상 정체”를 감지해 자동으로 경고를 발령합니다.
• 데이터 미반영: 승인이 완료됐지만 HR 시스템의 출근 기록이 업데이트되지 않았거나, 재무 시스템에 전표가 생성되지 않은 경우. 데이터 반영 시에는 ‘이중 확인’이 필요하며, OA 시스템에서 작성 후 업무 시스템의 인터페이스를 직접 호출해 수신 여부를 확인합니다.

검증 항목의 성공 여부를 판단하는 지표:

• 승인 평균 처리 시간: 도입 전에는 위챗 그룹에서 3일간 처리했으나, 도입 후에는 시스템에서 1일 이내에 처리가 완료됩니다.
• 부서 간 데이터 일치성: HR, 재무, 영업 세 부서의 기준을 비교한 결과 오류율이 80% 이상 감소했습니다.
• 감사 추적 가능성: 과거 승인 기록 20건을 무작위로 추출해 7대 요소가 모두 갖춰진 비율이 100%에 달했습니다.

승인을 위챗 그룹에서 시스템으로 옮기는 것은 단순히 ‘시스템 도입’을 위한 것이 아니라, ‘사람 찾기’라는 행위를 사람 의존에서 규칙 의존으로 전환하기 위함입니다. 일단 규칙이 정립되면, 누가 퇴사하든 조직이 어떻게 변화하든 승인 절차는 혼란을 겪지 않습니다.