패션브랜드 PM의 ERP 대시보드 제작후기 3탄
이전 ERP 대시보드 제작후기 2탄에서는, 사업계획장표와 마케팅 KPI와 관련된 지표를 제작했다. 그에 대한 내용이 궁금하실 분들을 위해 링크를 남겨두겠다.
https://brunch.co.kr/@mk-kang/36
2탄에서 적지 않았던 것이 있다면, 마케팅 KPI 관련된 수치들은 개발 공수가 많이 들어갔다는 점이다. 물론 그 전에, API 문서나 구현해야 할 지표 등은 정해서 드렸다. 하지만 API 중에는 '액세스 토큰'이라는 것의 만료 시간이 짧은 것들이 있었기 때문에 이것을 같은 시간에 가져오게 하기 위해서는 '크론탭'이라는 것을 활용해야 했다.
크론탭이란, 리눅스 환경에서 프로그램이 정해진 스케줄에 따라 실행되도록 설정을 하는 것이라고 한다. 크론탭을 잘만 활용한다면, 특정 시점에 특정 행동을 진행하게 프로그램을 짤 수 있다. 당시 개발자들은 여기에 대해 아는 부분들이 전무했고 그들도 이번 프로젝트를 통해 큰 성장을 했을 것이라고 생각된다.
이번에 소개할 지표는, 매출 관련 지표이다. 우리 브랜드의 경우 20개 넘는 채널들을 이용하고 있었고 그 제품의 카테고리 또한 매우 다양했다. 또한 거의 모든 제품들이 계절 별 주기를 타는 제품들이었기 때문에, "몇 개월 전" 그래프 보다는 "전년 동월" 그래프가 더 활용하기에 수월했다. 그래서 채널 별, 제품 별로 전년 동월 비교 데이터를 가지고, 시각화시켜보기로 했다.
아래 이미지는 'AS IS"이다.
내가 UI 설계 담당을 맡으면서 가장 아쉬웠던 점 중 하나는, 모든 그래프마다 시간 지정하는 것을 못넣는다는 것이었다. 아마 촉박한 시간 때문이었겠지만, 기간을 설정하지 못하고 모든 지표들이 1년 단위로 지정되었어야 했다. 그게 아쉬웠다.
각설하고, 왼쪽 위에는 "매출"과 "재고"를 버튼 형태로써, 아이템 카테고리 별 매출 및 재고를 볼 수 있도록 제작하고자 했다. 디폴트 값은 "전체"였고 각 아이템 카테고리 별로 나눴다. 이 과정에서, 회사가 제품 카테고리를 개판으로 만들었다는 것을 파악했다. 예를 들면, WALLET인데 그 재질이 KNIT이기 때문에 LUCKY KNIT로 들어가있는 점 등이다. 이 부분 때문에, 회사에서 관리하고 있었던 전체 유통코드 파일을 바꾸기도 했다.
그리고 위 이미지의 3번, 화살표 버튼을 누르면, 4번처럼 제품 카테고리들이 나오도록 세팅해뒀다. 그리고 ON/OFF 버튼을 추가하여, 버튼이 ON일 때는 위 이미지 UI처럼 막대 그래프로 나타내고 OFF일 때는, 라인 차트를 활용하여 그 카테고리의 추이를 볼 수 있도록 UI를 제작했다. 나는 이 형태가 매우 혁신적이었다고 생각했고 이대로 적용만 된다면 회사 경영진들이 큰 도움이 될 것이라고 봤다. 그들에게 PT할 때도 그렇게 진행했다.
위에는 제품 별로 카테고리를 나눠놨지만 채널 별 매출도 위와 유사하다. 채널의 경우, 회사마다 보안 이슈가 있을 수 있으니, 가려놓도록 하겠다. 채널의 경우도 별 반 다르지 않다. 모든 채널들을 다 나눠놨다. 어떤 채널은 온라인인데 오프라인으로 들어가있고 또 어떤 건 오프라인인데 온라인으로 들어가 있다. 이 부분들은 모두 변경하고 싶었고 그에 대한 로직까지 다 짰지만 그렇게 실행시키지 못했다. 개발자의 줄지은 퇴사에 시간이 없었기 때문이다.
위 채널 / 아이템 별 매출 비교 대시보드는, 모두 회사 내부에서 관리하는 엑셀 시트를 기준으로 만들어진다. 임의로 구분해놓은 유통 코드 및 채널 장표에서 구분해놓은 것을 끌고와서 데이터를 구분한다. 그래서 제품의 경우, 대-중-소의 카테고리로 나눠지고 대분류에는 KNITBAG의 상위 카테고리만 차별점이 있었고 중분류는 제품의 재질로 구분했다. 즉, KNIT, LEATHER, CANVAS 등이다. 그리고 소분류는 가방을 메는 형태, 크로스인지 백팩인지 등으로 나눠진다.
보는 사람에 따라 데이터 구분을 잘 해야 하겠지만, 통상적으로 제품 소재 별 매출은 확인할 필요가 없다고 생각했다. 그 이유는, 레더는 겨울에 그리고 니트는 여름에 잘 팔리는 것은 거의 기정 사실이기 때문이다. 우리가 대시보드를 만드는 목적 중에 하나는 데이터에서 발견할 수 있는 이상 증상을 좀 더 빠르고 효율적으로 파악하고 미래를 예측하여 더 나은 비즈니스 전략을 수립하기 위함이다. 그래서 착용 형태에 따라 구분하는 것이 맞다고 생각했고 그렇게 주장했었는데 당시에는 받아들여지지 않았다. PP, 즉 상품 기획 쪽에서만 확인할 대시보드라는 것이 그 이유였고 나는 그것에 대해 말씀을 드렸지만 변경되지 않았다. 그리고 이 일이 있고 몇 달 뒤, 다시 착용 형태로 바꾸라는 말을 듣고 말았다.
어쨌든, 나는 개발 팀에서 나누는 카테고리로 이 대시보드 데이터를 마이그레이션 한다는 사실을 잘 모르고 있었기 때문에 처음 UI를 설계할 때부터 구분을 지을 생각을 하지 못했다. 그래서 개발자 분에게도 이중으로 브랜드 구분자를 넣어 추가 개발자고 요청드렸고 정말 죄송했던 기억이 난다. 어찌됐든, 이렇게 제작될 수 있다는 것을 미리 알았더라면 제품 매출 대시보드를, "브랜드 별", "제품 소재 별", "제품 착용 형태 별"로 제작을 요청드렸을 것이다. 후에야 이런 말을 듣게 되었고 여러 브랜드를 영위하고 있었기 때문에 상위 브랜드 드롭다운과 제품 소재 드롭다운을 추가하여 UI 설계를 완료헀다.
채널 같은 경우는, 온라인 및 오프라인도 문제였지만 국내인지 해외인지도 제대로 구분이 안되었다. 그리고 편집샵과 오픈 마켓 등으로 된 구분들은 왜 있었는지 모르겠으며 백화점은 메인이라고 백화점 채널로 떡하니 남겨놨다. 대시보드를 만든다는 것은, 가장 높은 기준을 세우고, 그 범주에 맞게 부분부분 만들어나가야 한다고 생각한다. 그런데 우리 대표님은 반대로, 보고 싶은 카테고리를 만들고 큰 부분을 만들어나갔다. 그러다보니 계속 카테고리가 바뀌었고 그 어려움은 모두 개발자들이 떠앉게 되었던 것이다. 이 부분 관련해서는, 유통코드 및 채널 장표 PM으로써 새로 개편했을 때의 스토리가 있으니 그 때 다시 적어볼 것이다.
아래 이미지는 "TO BE"이다. 제품, 매장 별 카테고리 대시보드 UI를 설계했고 실제로 만들어진 대시보드이다.
개발된 대시보드를 보면, 매출과 재고를 아예 두 그래프로 나눠놨다. 재고를 나타내는 창고 쪽 재고 수량을 제대로 추적할 수가 업성 창고 API 문제부터 해결해야 할 상황에 이르렀다. 때문에 창고 수량을 제대로 마출 수 없었고 이렇게나마 두 가지 지표로 나타내는 것으로 합의를 봤다.
또한 기존에 설계했었던, ON/OFF 토글 버튼으로 LINE CHART와 BAR CHART로 변경시키는 UI는 세상에 내보낼 수 없었다. 이 역시 시간이 부족했다는 핑계였다. 내가 UI를 고심해서 설계를 해놔도 개발자가 개발을 해놓지 않으면 아무 쓸모가 없는 사람이었다. 분명 대표님 이하 이사님 PT할 당시, 내가 설계해놓은 UI에 대해 상당한 만족감을 보이셨기 때문에 그런 대시보드를 원하셨을 것이다. 하지만 그렇게 개발되어 있지 않았고 그에 대한 책임은 내게 돌아왔었다.
아래 이미지는, 브랜드 구분자로 카테고리를 나눠 드롭다운 시켜놓은 것이다. 처음 UI 설계 시에는 없었으나, 데이터를 어떻게 나누고 있는 지를 개발팀으로부터 들은 뒤, 대표님 이하 이사님의 요청사항을 반영하여 추가 개발했다. 이중으로 개발 업무를 드린 개발자 분들에게 죄송하다.
아래 이미지는 제품 및 채널 카테고리를 나눠놓은 것이다. 기존에는 이렇게만 분류되어 있었고 추후에는 좀 더 세분화하여 나타낼 예정이었다.
매출 대시보드 UI를 설계하고 대시보드가 만들어지는 과정들을 경험하면서 기초가 중요하다는 사실을 참 많이 느꼈던 것 같다. 대시보드를 무작정 만드는 것이 아니라, 그 대시보드 안에 들어가야 할 데이터들이 어떻게 설계되어 있는지 파악하는 게 우선이었다. 뿐만 아니라, UI를 설계하기 전에 부족했던 내 지식도 한 몫 했따. 만약, 회사에서 구분자로 나누고 있는 채널 / 제품 카테고리 장표가 있었다는 사실을 알았더라면, UI를 설계하기 전에 그 장표의 구조를 먼저 파악했을 것이다.
기존에 있는 매장 코드들을 활용하는 것이 아닌 여러 코드들을 분리시켜 다양한 대시보드를 제작했을 것 같다. 모든 매장들을 온라인과 오프라인으로 나눠 대시보드를 제작했을 것이고 그들을 또 매장 유형 별로 나눠 대시보드를 만들었을 것이다. 또한 B2C인지 B2B인지 혹은 D2C인지 등에 따라도 나누었을 수도 있다. 이런 모든 점들이 내가 갑작스럽게 지식이 없던 상태에서 투입되어 일어난 일이라 생각했고 또 기초 데이터가 확실하게 정립되어 있지 않았기 때문이라고 생각했다.
다음에도 유사 업무들을 맡게 된다면, 먼저 데이터 구조와 어떻게 스키마 구조가 짜여져 있는 지를 파악하고 개발자와 이야기를 나누며 만들어나갔을 것 같다. 혹시나 다음에 또 이런 일이 있다면 말이다. 다음에는 대시보드 제작기 4탄으로 돌아오려고 한다.
