문제해결과 협업을 위한 워크플로우
신입사원 시리즈 #3 매일 외국 지사들과 커뮤니케이션하고 있습니다
신입사원 시리즈
매달 1개의 직장생활 회고 에세이를 쓰기로 결심했다. 매달 경험한 문제 해결의 과정, 그중 배운 점들 및 고민을 기록하고자 한다.
직장에서 매일매일 발생하는 문제들, 신입사원 때는 작은 의사결정 하나를 내리는 것에도 수십 번의 고민과 결단이 필요하고 조직과 시스템에 익숙하지 않으니 연락책과 원인을 파악하는 것도 어렵기 마련이다.
나 또한 그랬으나, 5개월차인 이제는 여러 글로벌 서비스의 운영에 익숙해지고 있다. 5개월은 제법 의사결정을 내릴 수 있을 정도로 여러 문제 해결 케이스가 쌓일 만한 시간이다. 한국 지사와 외국 지사의 여러 이해관계자 사이에서 중간 연락(point of contact)을 담당하며, 문제 발생 시 이슈 보고(escalating)&대응 방안을 제안 또는 결정하는 일을 수행하고 있다.
오늘은 여러 다른 이해관계자들과 협업 시 문제를 해결하기 위한 소통의 방법에 대해 나름의 노하우를 풀어보려 한다.
내가 안 하면 아무도 안 챙기니까 ;)
그동안 발생했던 케이스들은 주로 새로운 담당자들이 팀에 합류했을 때 집중적으로 발생했다. 자신들 담당인데도 대응을 어찌해야 할지 몰라 솔루션을 구하거나 며칠이 지나도록 소극적으로 대응하는 일도 있었다.
이런 일들을 겪으며, ‘집요함’은 소통의 원칙처럼 되었다. '이렇게까지 해야 할까?' 싶었던 것들이 '이렇게까지 집요해야 한다.'임을 한발 늦게 알게 되었으므로. 만일 소통에 공백이 생긴다면, 고객 및 내부에 그 영향이 고스란히 돌아오기 때문에 뒤늦게 더 일이 커지는 것이 두려워 집요하게 소통하게 되었다.
회사에서 여러 이해관계자와 집요하게 소통하기 위한 나만의 체크리스트를 소개한다. daily basis에서 발생하는 문제/이슈들을 파악하고 대응방안을 마련, 사후 보고까지 나만의 워크플로우가 있으면, 중요한 것들을 놓치지 않을 수 있다.
gpt로 생성문제 정의 및 원인 분석 -> 영향 및 시급성 평가 -> 데이터 및 지표 검토 -> 해결책 옵션 및 실행 가능성 평가 -> 이해관계자 및 책임 할당 -> 결과 및 피드백 측정
단계별로 나누었으나 거의 동시에 처리해야 한다. 하나씩 살펴본다.
1. 문제 정의 및 원인 분석
문제 해결의 첫 단추는 늘 정확한 문제 정의이다. 문제로 인해 영향받는 시스템 또는 프로세스, 그리고 원인을 스스로 설명할 수 있어야 한다.
문제가 예컨대 시스템의 문제인지, 휴먼에러인지 등에 따라 연락해야 할 팀도 달라지므로 문제 원인을 명확하게 파악하고, 혹여 이슈 케이스가 여러 개라면 원인이나 상태 등의 기준에 따라 분류한다.
이 과정에서 나는 상사나 협업하는 이들에게 설명할 수 있을 정도로 쉽고 정확하게 설명하기 위해 노트 테이킹을 많이 활용한다. 직접 손으로 쓰는 것만큼 좋은 정리 방법이 없다. 이에 관한 글은 지난 편 참고.
2. 영향 및 시급성 평가
문제 원인을 파악했다면, 문제의 영향력과 긴급성을 평가하여 우선순위를 설정하는 단계이다. 이를 위해 문제의 규모와 범위를 명확히 파악해야 한다. 이 문제가 조직, 고객, 비즈니스 성과에 미치는 영향은 무엇인지, 다른 프로세스에도 영향을 미치는지를 고려해본다. 영향은 재정적 손실, 고객 만족도, 프로세스 지연 등으로 나누어 접근할 수 있다.
시급성 평가를 위해서는 이 문제가 즉각 해결해야 하는지 아니면 장기적으로 해결해야 할 문제인지 정의하는 작업이 필요하다. 예컨대 고객이 돈을 지불하는 유료 서비스의 퀄리티에 문제가 생김으로써 고객의 비즈니스에 직접적인 임팩트를 주고 있는 상황이라면 다른 문제에 비해 훨씬 높은 우선순위를 부여해야 할 것이다.
또한, 임팩트를 받은 고객이 회사의 매출에 차지하는 비중이 클수록 더 엄중하게 다루어져야 한다. 임팩트의 규모는 내부적으로 문제의 시급성을 알리고 협조를 구하는 등 협업할 때도 중요하게 어필되는 부분이다. 실제로 회사에서 빠른 협업을 구할 때 ‘이 고객은 우리 회사 매출의 xx%를 차지합니다. 그러니 빠른 도움 부탁드려요.‘ 와 같이 말하고는 했다.
3. 데이터 및 지표 검토
앞서 2단계를 위해서는 3단계가 필요하다. 문제의 규모와 범위, 발생 빈도 등을 데이터로 뒷받침함으로써 문제 해결 및 개선을 위한 기준을 수립하는 것이다. 데이터로 뒷받침할 수 있을 때 상부에도 보고하거나 이해관계자의 협조를 구하기 용이하고, 고객과의 커뮤니케이션을 진행할 때도 효과적이다.
KPI(Key Performance Indicators)나 SLAs(Service Level Agreements)를 중심으로 검토하여 어떤 지표들이 영향을 받았는지 확인한다. 이를 통해 대응 방안의 규모 및 대응의 시급성 등을 파악할 수 있고 개선되어야 할 게 무엇인지 알 수 있다.
특히 임팩트 기간뿐만 아니라 그 전전달(L2M), 전달(L1M) 또는 2주전(L2W), 1주전(L1W)의 데이터도 같이 확인함으로써 문제 발생 이전의 정상적인 상태 및 추세도 같이 확인한다.
이를 엑셀이나 스프레드시트에서 표현한다면, 컬럼에 기간별 확인할 지표들을 작성하고 로우에는 데이터를 확인할 고객의 아이디를 나열한다. 그러면 아래 사진과 같이 대시보드가 완성된다.
기간에 따른 핵심 지표들의 추이를 확인한다. 이때 조건부 서식 기능을 통해 한눈에 그 수준이 시각화될 수 있도록 보고하는 게 좋다.주요 지표는 SLA 및 그와 직접적인 관계에 있는 선행 지표를 기본으로 하고, 후행 지표로서 문제의 결과로 비즈니스 전체에 핵심이 되는 지표도 같이 본다. 예를 들어 채팅 서비스라면 채팅 응답률, 고객이 남긴 채팅 만족도 지표가 핵심 KPI가 될 수 있다. 전체 비즈니스의 핵심 지표로는 그 결과로 일평균구매건수(ADO)가 떨어졌는지도 같이 확인한다. 물론 구매건수에는 영향을 주는 변수가 많으므로 결과 해석 시에 신중한 접근이 필요하다. 또한, 고객에게 계약서와 같은 형태로 약속된 지표가 있다면 그 지표의 준수 여부가 가장 중요하게 검토되어야 한다.
4. 해결책 옵션 및 실행 가능성 평가
문제 원인 정의 및 뒷받침되는 지표가 준비되었다면, 이제 여러 가지 해결책을 검토하고 그중 실행 가능한 최선의 방안을 선택할 차례이다. 해결책은 비즈니스 및 케이스별로 상이할 것이라 간략히 이야기하고 넘어가고자 한다.
내가 경험했던 케이스 중에는 고객이 서비스에 지불한 비용을 돌려주는 방안과 보상으로 서비스 기간 연장, 보상으로 별도의 크레딧을 제공하는 등 서너 가지 방안을 두고 고려하였고 최종안을 결정하기 위하여 선행 케이스 및 고객 CS 히스토리 확인, 계약서 검토, 예산 검토 등을 수행하였다.
5. 이해관계자 및 책임 할당
해결책을 정할 때는 측정 가능한 목표(goal)를 정하고 데드라인을 명시하며 액션 아이템에 대한 각 담당자를 구체적으로 지정한다. 예를 들어 법률팀을 통해 계약서에 보상에 대해 명시된 내용이 있는지 확인, 파이낸스팀을 통해 예산을 검토, 거버넌스팀에게 선행 케이스 및 해결책에 대한 컨선을 확인해 줄 것을 요청한다. 하나의 문제를 해결하기 위해 비단 해결책을 수행하는 이들뿐만 아니라 간접적인 여러 이해관계자의 협력(collaboration)이 필수적임을 느낄 수 있는 부분이다.
gpt로 생성해결책이 결정된 이후에 실제로 수행함에 있어서도 역할을 명시해야 한다. 특히나 역할이나 체계가 불명경우 더더욱 각 PIC의 역할을 명확하게 할당하는 것이 중요하다. 나는 주로 사내 메신저 그룹챗에서 각 액션을 수행 또는 컨펌해야 하는 PIC들을 정확하게 태그(ping)하여 구체적인 액션 플랜을 전체 이해관계자와 얼라인한다. 특히 이때 액션 아이템별로 담당자를 태그하는 이유는 그렇게 하지 않으면 다들 다른 일들로 바빠 제대로 검토하지 않는 경우도 있기 때문이다. 이런 사소한 스킬이 문제 해결의 속도나 퀄리티에 큰 차이를 만든다.
책임 할당을 위해 활용할 수 있는 DACI 프레임워크(Driver, Approver, Contributors, Informed)가 있다. 이는 업무를 리드하는 이와 승인자, 같이 수행하는 이들, 진행 상황을 공유하는 이들의 역할과 책임을 명시하여 프로젝트의 효율성을 높이기 위한 프레임워크이다. 조직의 규모가 클수록, 여러 지사 간 협업 시에 유용하다.
DACI Framework
Driver (책임자): 문제 해결을 이끌어갈 사람은 누구인가?
Approver (승인자): 해결 방안을 최종적으로 승인할 사람은 누구인가?
Contributors (기여자): 문제 해결에 기여할 사람들은 누구인가?
Informed (정보를 받아야 할 사람들): 진행 상황을 공유받아야 할 사람들은 누구인가?
출처: https://project-management.com/daci-model/이때 Driver는 액션 플랜을 수행하는 가장 중요한 담당자이며, Approver는 보통 해당 팀의 리드가 된다. Contributors는 앞선 예시에서의 파이낸스팀이나 리걸팀 등이 될 수 있다. Informed는 보통 approve 하거나 액션을 수행하는 contributor가 아니므로 비교적 빼먹기 쉬우나 내용 공유가 필요한 이들이다. 문제를 핸들하는 팀의 다른 구성원들이나 후속조치 등을 위해 같이 팔로우업해줘야 하는 팀, 그밖에 업무에 영향을 받는 이들에게도 상황과 계획을 상세히 정리해서 공유한다. 내가 경험했던 케이스에서는 Cs팀이 informed에 해당했다. 그들은 문제 해결을 위한 액션에는 크게 관여하지 않으나 추후 잘 해결되었다든가 얼마 정도는 더 기다려야 한다 등의 결과를 공유받아 고객과 소통하는 데 있어 핵심적인 이해관계자였다.
6. 결과 및 피드백 측정
문제 해결 후 결과를 데이터와 지표로 확인하고 피드백을 통해 개선하기 위한 단계이다. 따라서 해결책이 수행된 이후에도 바로 손을 떼지 않고 지표가 안정화되었는지를 지속적으로 모니터링한다. 고객을 직접 응대하는 CS팀과 같은 이해관계자에게도 고객으로부터 추가적인 컴플레인이나 관련 문의가 들어왔는지를 확인한다.
개인적으로는 이때 이번 문제 해결에서 배운 점은 무엇이며, 향후 문제 해결에 적용할 수 있는 교훈은 무엇인지 같이 정리하는 자기회고(Self Reflection) 시간을 가진다.
마무리
때로 관련 업무 담당자조차 확인할 수 없어 메신저를 빙글 뱅글 돌며 어렵게 진행하는 일들도 있지만, 그럼에도 불구하고 많은 것이 AI 자동화로 대체 가능한 시대에 이것만큼은 사람의 손이 꼭 필요한 일이라고 생각하면 즐겁기도 하다. 그러므로 일의 본질은 소통이다. 어떤 조직에서 어떤 역할을 맡든, 발생한 문제의 원인과 배경을 파악하고 이해관계자들과의 협업을 통해 솔루션을 도출한 뒤 해결에 이르는 일련의 과정이 수반되므로. 그러니 오퍼레이션들이여 힘을 내자. 매일같이 문제 상황을 마주하는 운영직, 또는 조직에 속한 누구라도 이 글의 어느부분이라도 도움이 되기를 바라며 글을 마친다.
