안녕하세요. 기획팀 Jung입니다.
이번에는 가장 최근에 배포한 팀별 고객사 관리 기능 기획 과정에 대해 적어보려고 합니다. 23년 초 배포 진행한 가장 큰 기능이기도 했고, 2차 배포 전 1차 배포 회고 겸 정리해 보았습니다.
1. 문제 정의 및 발견
ezstorage 내 센터와 고객사가 점점 많아지고, FA도 들어오면서 문제가 생겼습니다.
한 명의 로지스틱(물류사, 이하 로지스틱) 사용자가 관리하는 고객사(셀러, 이하 고객사)는 정해져 있는데, 100개 이상의 고객사 리스트 및 데이터가 조회되어 불편하고 혼선이 발생한다는 것입니다.
100건이 넘는 고객사 선택 리스트
문제
•
메인 로지스틱 내에 너무 많은 고객사가 노출
◦
담당 고객사를 매번 찾고 선택해야 하는 불편함
◦
많은 고객사 데이터가 한꺼번에 노출되어 작업 혼선
◦
로지스틱을 분리하기에는 너무 많은 비용 발생
⇒ 사용자별 담당 고객사만 조회하기를 원함
2. 현황 파악
현 시스템 내에서 가능한 방법과 제약사항을 먼저 확인했습니다.
ezstorage 내 사용자 타입은 로지스틱과 셀러로 구분됩니다. 로지스틱은 해당 로지스틱 내 모든 셀러 정보를 조회할 수 있는 구조입니다.
여러 로지스틱이 있지만 메인 로지스틱에 대부분 수도권 센터의 대부분 고객사가 등록되어 있습니다.
제약사항
첫째로, 하나의 고객사가 두 개의 센터에서 나눠 출고가 진행되는 경우도 있고, 재고의 이관이 이루어지는 경우도 있기 때문입니다.
둘째로, 택배사 계약 코드를 함께 사용하려면 같은 로지스틱 내에 있어야 가능하다는 것입니다.
마지막으로, 로지스틱이 독립적으로 존재하여(모든 데이터가 별도로 존재) 다른 로지스틱에 데이터 이관 작업이 쉽지 않다는 것입니다. 계정 또한 로지스틱 하위로 속해있어 만약 로지스틱이 변경된다면, 계정도 새로 생성해야 하고, 모든 데이터를 새로 생성해야 하는 구조입니다.
이러한 제약 때문에 로지스틱 변경이 쉽지 않았습니다.
처음 실무자 인터뷰에서는 센터별로 업무를 진행하니 센터별로 사용자를 매칭하여 해당하는 센터 내 고객사 데이터만 조회되기를 원한다는 의견이었습니다.
하지만 현재 시스템 구조상 고객사와 센터가 독립적으로 존재합니다.
하나의 고객사가 여러 센터에 재고를 가지고 있을 수 있고 센터별 재고 이동이 매우 자유로운 상태로 여러 센터에 고객사가 있을 경우 임시 센터가 생길 경우 등 복잡한 예외 케이스가 많이 발생할 수 있었습니다.
현황
1.
로지스틱 분리
•
하나의 고객사가 두 개의 센터에서 출고가 진행
•
택배사 계약 코드 공유
•
로지스틱이 모두 독립되어 있어 로지스틱 이동 시 큰 비용 발생
2.
센터별 사용자 관리
•
현재 센터는 고객사와 별개로 운영
◦
하나의 고객사가 여러 센터에 존재할 수 있고, 임시 센터를 생성하여 재고를 분리해놓기도 함
3. 해결방안
현재 시스템 내에 새로운 개념이 필요하다는 결론에 도달하여 새로운 개념을 도입했습니다.
고객사 그룹
고객사 그룹이라는 개념을 도입했습니다.
사용자가 ㄱ그룹을 관리하고, ㄱ그룹에 n개의 고객사를 매칭 시키고, A그룹을 관리하는 사용자가 로그인하는 경우 A그룹에 매칭된 고객사를 노출해 주는 방식입니다.
이렇게 하면, 그룹명을 자유롭게 설정할 수 있고, 원하시는 센터 이름을 그룹명에 넣어 구분도 가능하게 됩니다.
팀
이후 리뷰 때 새로운 그룹이라는 개념 대신 현재 존재하는 팀 개념에 그룹 개념을 녹이면 어떠냐는 피드백을 받았습니다.
계정 등록 시 팀은 필수 값으로 사용자는 하나의 팀에 속하는 구조입니다. 사용자와 팀이 1:N으로 정의되고 있어 그룹의 개념과 일치했습니다. 또한, 팀은 사용자를 구분하기 위한 개념으로만 사용되고 있고, 팀 설정 시 팀명을 자유롭게 설정할 수 있습니다.
현재 사용하고 있는 팀 개념을 고려해 보았을 때 문제가 없다는 판단이 들어 그룹이라는 새로운 개념을 도입하지 않고 그룹에 잡았던 개념을 팀에 녹이는 것으로 수정했습니다.
팀 관리
팀 개념이 들어가면서 팀 관리 주체를 정해야 했습니다. 시스템 내 사용자별로 권한이 관리자, 매니저, 구성원으로 구분되어 있습니다.
주체별 팀 관리 권한을 부여하도록 방향을 설정했습니다. 현재 시스템 내 관리자, 매니저의 권한 차이가 없어 팀 관리를 기준으로 주체를 먼저 설정했습니다.
관리자는 전체 팀을 관리하는 최고 관리자로 설정했고, 매니저는 해당 팀의 리더로 해당 팀 내 사용자 추가 및 고객사 관리를 진행하는 사용자로 정의했습니다. 구성원은 관리 권한 없이 업무를 처리하는 사용자로 설정하여 권한을 부여했습니다.
팀관리 권한별 기능
•
관리자 : 사용자, 고객사 및 팀 전체 관리
•
매니저 : 본인 팀 사용자만 관리, 본인 팀 내 고객사만 추가 가능
•
구성원 : 사용자, 고객사 및 팀 관리 불가
4. 개발 및 배포 그 이후
1차, 2차로 개발 범위를 나눠 일정을 산정했습니다. 1차 배포 범위는 팀 관리 화면과 매니저 구성원일 경우 팀 내 고객사만 조회할 수 있도록 하는 기능으로 배포를 진행했습니다. 2차 배포 범위는 관리자 로그인 시 팀을 변경하여 팀별 화면을 조회할 수 있도록 하고, 기존 사용자 관리 화면 개선을 추가했습니다.
관리자, 매니저, 구성원별로 메뉴별 조회 결과 및 접근 권한이 달라야 해서 권한별 테스트 케이스를 작성하여 테스트를 진행했습니다. 그리고 무사히 지난주 1차 배포를 완료했습니다. (짝짝
)
)배포 후 팀 관리 설정과 권한 설정이 하루 만에 완료되었고, 아직 큰 이슈 없이 사용 중에 있습니다. 팀별 고객사 관리 기능을 사용자가 잘 사용하는지 확인하기 위해 주기적으로 모니터링해 보려고 합니다.
2차 배포도 무사히 진행하기 위해 열심히 테스트 케이스를 작성하고 꼼꼼한 테스트를 진행해 보겠습니다. 화이팅