CSM은 knowledge base를 남긴다
호랑이는 가죽, 인간은 이름을 남기지만...!
CSM이라서 다른 팀의 어느 누구보다 잘 만들 수 있는게 제품과 관련된 knowledge base (날리지베이스)라고 생각한다.
물론 다른 팀과 부서들도 날라지베이스를 만들어서 활용할 수 있다.
knowledge base (놀리지 베이스, 날리지 베이스, 지식베이스)라는 게 생소할 수 있다.
What is a Knowledge Base?
A knowledge base is a self-serve online library of information about a product, service, department, or topic.
https://www.atlassian.com/itsm/knowledge-management/what-is-a-knowledge-base
날리지베이스란?
날리지베이스는 제품, 서비스, 부서 또는 토픽에 대한 정보를 담은 셀프 서비스 온라인 라이브러리이다.
CSM에게 필요한 날리지베이스는 보통 제품에 대한 것이다. 예를 들어서, 쿠팡에 대한 데이터를 가져올 때, api가 있는 게 있고 없는 게 있다. 쿠팡 윙 (coupang wing)은 api가 있지만 서플라이어 허브 (Supplier Hub)는 api가 없다. 이런 내용을 날리지베이스에 하나씩 기록해 나가는 것이다.
날리지베이스를 만들 때 <중요한 포인트>는 다음과 같다.
1. 검색이 잘 되도록 만든다.
날리지베이스는 검색이 생명이다. 검색이 잘 되어서 관련된 내용이 이미 있는지 체크할 수 있어야 한다.
2. 여러 사람이 동시에 접속하여 찾거나 업데이트 할 수 있게 한다.
날리지베이스를 어떤 걸로 만드는지는 크게 중요하지 않다.
노션으로 만들 수도 있고,
구글 문서로 만들 수도 있고,
구글 스프레드 시트로도 만들 수 있다.
다만, MS 워드나 엑셀로 만들면 안 되는데, 그 이유는 여러 사람이 접속해서 동시에 보고 업데이트를 하는 게 불가능하기 때문이다. 한 가지 문서가 여러 다른 사람들에 의해서 버전이 여러 개로 분할되는 것만큼 최악인 상황도 없다. (마치 드라마 로키에서 분기점이 나오는 느낌으로…)
난 주로 노션으로 만들어 왔는데, 나쁘지 않다.
3. 수정에 대한 내용도 확인할 수 있도록 만든다.
과거 히스토리에 대한 내용을 파악할 수 있으면 좋다. 내용을 업데이트 할 때, 기존 내용을 지우는 방향이 아니라, 남겨 두고 취소선을 긋거나 다른 색으로 처리를 하는 등으로 살려 놓으면서 표기를 하는 게 좋다. 히스토리를 남겨 놓는 이유는 원래는 어떤 내용이었는지를 파악하면 업무에 있어서 도움이 되기 때문이다. 예를 들어서 A가 안 되고 B만 되었는데, 기능이 업데이트 되면서 A와 B가 둘 다 되게 되었다고 치자. 기존 고객사가 예전에는 A는 안 되었는데 업데이트 된 건가요?라고 물어봤을 때, 옛날부터 근무하던 사람은 바로 대답할 수 있겠지만, 최근에 들어온 사람은 A가 안 되었다는 사실을 모를 수가 있다. 그 때 날리지베이스의 히스토리가 있다면 최근에 입사한 사람도 그 사실을 알 수 있게 된다.
수정 사항이 계속 누적되기 때문에 작성일과 최종 업데이트 날짜를 추가하면 좋다. 굳이 두 개의 항목을 쓰고 싶지 않다면, 그냥 “최종 업데이트 날짜”만 기입해 놓아도 된다. 처음 작성하고 업데이트가 되지 않은 글이라면 최초 작성일이 최종 업데이트 날짜가 될 것이다. (그리고 작성자 / 최종 수정자를 쓰는 것도 좋다. 하지만 이 항목은 필수는 아니다. 만약 써있다면 다른 사람이 보고서 상세 내용을 그 사람에게 물어볼 수 있어서 편하다)
4. 해당 질문이 누구 (내부/고객사)로부터 나왔는지도 표기하면 좋다.
이렇게 되면 일종의 VOC로도 기능할 수가 있다.
(물론 VOC용은 따로 트래킹할 수 있도록 만드는 걸 권장한다. VOC를 모으는 법에 대해서는 별도의 아티클로 정리하겠다.)
내부에서 나온 질문인지, 고객사로부터 나온 질문인지. 고객사로부터 나왔다면 어떤 고객사들이 질문한 것인지에 대해 정리한다면, 나중에 데이터를 모아서 분석을 할 수 있다. 고객사로부터 나온 질문들은 모아서 외부용 아티클 / 가이드 작성에 참고할 수도 있다.
5. 일단 내부용으로 만든다.
이 말은 엄청 공들여서 작성하지 않아도 된다는 뜻이다. 일단 시작은 가볍게 휘뚜루 마뚜루 해보자. 다람쥐가 도토리를 모으듯이 꾸준히 모으다 보면 양이 많아지고, 그러면서 점점 체계가 갖춰질 것이다. 날리지베이스 아티클을 하나씩 모으다 보면 ‘이 항목을 추가하는 게 좋겠군’ ‘이건 별로 필요 없어서 빼도 될 것 같군’ ‘모아 놓은 날리지베이스를 이렇게 활용할 수 있겠군’과 같은 아이디어가 마구마구 샘솟는다. 만약 아이디어가 별로 샘솟지 않아도 상관없다. 뭐든지 모으다 보면 무엇이라도 되기 때문이다. 꾸준히 하는 게 중요하다. 작성도 꾸준히 하고, 업데이트도 꾸준히 하고!
위에서 나열한 포인트를 지켜서 날리지 베이스를 만들었다면, 다음과 같이 활용할 수 있다.
<날리지베이스의 활용>
1. CSM들의 지식in이 될 수 있다.
이게 가장 중요한 포인트이다. CSM이 날리지 베이스를 만드는 것은 사실 이 목적을 위한 것이다. 스스로의 기억에 도움을 주고, 다른 동료들이 모르는 걸 찾아볼 수 있는 지식in을 만드는 것이다. 계속 누적되다 보면 기록의 힘을 느낄 수 있을 것이다.
2. 신규 입사자 온보딩에 좋다.
기존 직원들 외에 신규 입사자가 들어왔을 때에도 아주 좋다. 기본적으로 중요한 온보딩 내용들은 온보딩 자료에 적혀 있지만, 그 외에 경험을 통해 배운 중요한 내용들이 적혀 있는 것이다. 그 내용들은 내부이든 외부이든 어디선가 한 번이라도 질문이 나온 내용이다. 그렇기 때문에 신규 입사자가 들어왔을 때, 충분히 궁금해할 수 있는 내용들이고, 해당 내용이 적혀있는 문서를 먼저 본다면 온보딩이 훨씬 수월해질 수 있다. 신규 입사자가 뭔가 물어봤을 때, 날리지베이스 찾아봤나요?라고 먼저 안내할 수도 있다. (아니면 관련 날리지베이스 링크를 던져주거나)
3. 고객사를 위한 외부 아티클 / 날리지베이스를 구축할 때 베이스로 삼을 수 있다.
외부 고객을 위해 가이드 문서를 제작해야하는 것도 CSM의 업무이다.
조직에 따라서 기획 파트에서 이를 담당하는 경우도 있고, 별도의 팀이 있는 경우도 있다.
하지만 아무래도 고객들과 바로 접하는 사람은 CSM이다보니 그들에게 어떤 내용이 필요한지 잘 알고 좋은 문서를 작성할 수 있다. 만약 동일한 질문이 고객사에게서 나왔다면, 미리 작성한 아티클 링크를 던져주면 빠르게 해결할 수 있다. 일석이조!
이전 회사에 만들어 놓은 날리지베이스는 어떻게 되었을까 궁금하다. 잘 있을런지… 관리하거나 활용하는 사람이 여전히 있을지 모르겠다. 직원들이 엄청 바뀌어서 더 이상 사용하는 사람이 없을지도 모른다.
지금 속해 있는 회사의 날리지 베이스도 내가 떠난 뒤에도 잘 살아 있을지 모르겠다.
이렇게 보면 날리지 베이스에 대해 주인 의식이 있는 직원이 계속 있어야 날리지 베이스도 유지 보수가 잘 될 수 있는 것 같다. (중요성과 필요성을 느끼는 사람만이 느낄 테니까…)
다들 도움이 되는 날리지 베이스를 잘 만들어서 사용하면 좋겠다.
