by
Mar 04. 2023
결제 프로세스 및 백오피스 개선 프로젝트 회고-2(完)
내부 고객을 위한 백오피스 기획
요구사항을 정리하다.
앞선 글에서 실무자와의 인터뷰를 모두 마치고 문제를 정의했다. 이후 한 일은 요구사항의 중복 제거 등 정제 작업, 그리고 카테고라이징 작업. 작업 후 크게 신경 써야 하는 요구사항은 아래의 것들로 정해졌다.
1. 업무가 이루어지는 공간의 일원화
- 각 팀별로 그들 고유의 워크스페이스에서 작업을 하고 호출하다 보니 노션을 사용했다가 구글 시트를 봐야 한다든지, 백오피스(어드민) 페이지를 보다가 노션을 봐야 한다든지 등 하나의 프로세스 내에서 업무 공간이 분산됐다.
- 파편화되어있는 업무 공간을 하나로 합치는 것이 필요하다.
2. 업무 시스템화를 통해 수동공수를 줄이는 것
- 세금계산서 발급 요청을 직접 작성한 후 담당자를 멘션 한다든지, 입금 확인을 요청한다든지와 같은 자잘한 수동공수를 없애는 것이 그들에게 필요하다.
3. 업무 인계 시 러닝커브를 줄이는 것
- 입사/퇴사의 빈도가 잦은 팀의 경우에는 결제 관련 업무만 하더라도 상황별로 확인해야 하는 툴과 방법이 달랐기 때문에 업무인계에도 그만큼 시간이 소모된다.
- 이때 발생하는 러닝커브를 줄일 수 있는 구조가 그들에게 필요하다.
요구사항을 기준으로 목표 설정하기
요구사항을 기준으로 아래의 목표를 설정했다.
1. 백오피스를 활용한 업무 시스템화
- 여러 툴을 오갈필요 없이 하나의 백오피스 내에서 프로세스가 핸들링될 수 있도록 업무를 시스템화한다.
2. 업무 프로세스 사이클 당 소요 시간의 70% 단축
- 기존 프로세스를 한 사이클 돌리는데 소요되는 시간은 명당 평균 1분 정도로 측정되었다.
- 이 중 이미 작성한 내용을 워크 스페이스만 옮겨 다시 작성하고 담당자에게 구두로 전달 혹은 멘션 하는 과정이 40초 정도로 측정되었다.
- 즉, 시스템화를 통해 이 수동공수로 발생하는 40초를 없애는 것을 목표로 설정한다. (60초에서 20초로 업무 시간 감소 → 업무 시간 66.7% 감소 → 반올림하여 70% 감소로 목표 설정)
3. 업무 프로세스 표준화 및 매뉴얼 가이드라인 작성
- 담당자들의 업무 프로세스가 한 방향으로 흐를 수 있도록 프로세스를 표준화하고 서비스 운영을 위한 가이드라인을 만든다.
- 단, 매뉴얼의 디테일은 각 담당자들이 채운다.
업무 프로세스 표준화
요구사항 정의와 실무자 업무의 리스트업이 완료되었다. 이제 할 것은 분석한 업무 리스트를 가지고 병목현상이 발생하는 부분들을 도려내어 효율적인 프로세스를 만드는 것이다. 다만 거기에 실무자들의 요구사항을 끼얹은..
이번 결제 및 세금계산서 발급 프로세스에서 전 담당자들 별로 업무 흐름에 제동이 걸리는 구간은 명백했다.
영업팀: 여러 툴을 사용하며 문서를 생성하고 다른 관계자들에게 알림을 주는 업무
운영팀: 입금받아야 하는 금액을 건별로 직접 찾는 업무
회계팀: 여러 툴을 사용하며 입금 내역과 세금계산서 신청 정보를 확인하는 업무
이를 기준으로 표준화 진행 시 아래의 규칙을 세웠다.
1. 수동 알림 과정을 없앤다.
- 카카오 알림톡과 배치 시스템을 기획하여 수동으로 알림을 주는 과정을 풀자동화한다.
2. 기존 여러 업무가 혼재된 화면을 업무 특성별(사용자별)로 나눈다.
- 이를 통해 업무별로 확인해야 하는 정보로만 이루어진 화면으로 구성하고 담당자가 필요 데이터 인지에 드는 시간비용을 줄인다.
- 예를 들어, 기존에는 계약을 따오고 마케팅을 신청한 화면과 입금 내용을 기록하는 화면이 혼재되어 있어 담당자들은 불필요한 정보까지 확인해야 했기에 업무를 위해 필요한 데이터 인지에 시간이 소요됐다. 이런 화면들을 입금 확인 처리를 위한 화면, 세금계산서 처리를 위한 화면 등으로 나눈다.
3. 하나의 백오피스 시스템 내에서 흐름이 자연스럽게 이루어질 수 있도록 한다.
- 이를 위해 결제 정보와 세금계산서 정보에 생성되는 레코드들의 흐름이 꼭 필요한 담당자 액션만으로도 이어질 수 있게 기획한다.
고려사항이 반영된 프로세스 도식백엔드 기획
백엔드 기획은 생각보다 복잡했다. 기존에 수동으로 하는 업무를 표준화하는 과정을 거쳤고, 이를 이제 어떤 데이터 흐름으로 문제를 풀지 고민할 차례였다. 가장 먼저 결정한 것은 결제 정보와 세금계산서 정보에 대한 정보를 관리하는 것이었다. 이것을 결정할 때는 앞으로가 간단할 줄 알았다. 하지만 이후에 연달아 터진 3번의 기획 수정이 있었다.
최초에는 결제 정보와 세금계산서 정보가 일대일 관계가 되는 것으로 기획했다. 인터뷰 2번 정도 진행할 때는 운영담당자가 건건이 입금을 확인받는다고 얘기를 했기 때문이었다.
하지만 회원이 직접 입금을 해주는 형태라는 것이 마음에 걸려 과거 사례를 확인해 보니 여러 건의 마케팅을 신청한 후 일괄입금하는 경우가 존재하는 것을 알게 되었다. 이 때문에 결제 정보는 세금계산서 정보와 다대일 관계가 되는 것으로 기획을 수정했다. 이 덕분에 운영팀에서는 입금을 확인할 때 특정 조건에 맞춰 여러 건들을 자동으로 묶어서 한 번에 확인할 수 있게 되었다.
이후 시뮬레이션 중 확인한 마지막 문제가 있었다. 세금계산서도 수정 세금계산서를 발급한다든지와 같은 상황이 충분히 발생할 수 있다는 점. 최종에는 결제 정보와 세금계산서 정보를 다대다 관계를 가지는 것으로 기획이 최종 결정되었다. 이를 통해 회계팀은 하나의 결제 정보 데이터에 근거하여 여러 개의 세금계산서 정보를 만들 수 있게 되었다.
이후 관리해야 할 데이터를 정의하고, 데이터들이 어떻게 흘러갈지에 대한 기획을 진행했다.
구조 개선 후
아래 사진은 결제 구조 개선 후의 Normal Case를 간단하게 도식화한 것이다. 이 케이스의 흐름을 간략하게 설명하면 아래와 같다.
1. 고객이 마케팅을 신청한다.
2. 영업팀이 백오피스 화면 A에서 마케팅 신청서를 검토한 후 검토 완료 기능을 통해 결제 금액을 확정 짓는다. 이를 트리거로 하여 결제 레코드를 결제 대기 상태로 생성하고 운영팀에게 알림을 보낸다.
3. 운영팀은 화면 B(결제 관리 화면)으로 이동하여 입금을 확인한다. 입금 확인이 완료된 결제 레코드는 결제 완료 상태로 업데이트되고, 이를 근거로 세금계산서 레코드를 계산서 발급 대기 상태로 생성한 후 영업팀 및 회계팀에게 알림을 보낸다.
4. 이후 회계팀이 화면 C(세금계산서 관리 화면)에 쌓인 데이터를 보고 세금계산서를 발급하면 프로세스가 종료된다.
이제 더 이상 영업팀, 운영팀, 회계팀은 결제 관련 업무 때문에 여러 툴을 사용하고 수동으로 알림을 줄 필요가 없어졌다. 그들은 이제 데이터를 확인하는 것과 할 일을 처리하는 것에만 집중하면 된다.
