brunch

You can make anything
by writing

C.S.Lewis

by 루크의 IT이야기 Apr 07. 2020

나 매출 부서야! IT본부 까불지 마!

지원부서 평가

본부장(이사)라고 하면 왠지 사원들과는 무언가 달라보이지만, 실상을 놓고 보면 회사에서 살아남기 위해 몸부림 치는 한명의 회사원이랍니다. 중견 교육업계에서 월급쟁이 중 한명인 IT본부장으로 재직하면서 배웠던 다양한 조직운영에 대한 지식과 경험을 공유하려고합니다.


지원부서 평가

필자가 다녔던 회사는 매분 기마다 지원부서 가라는 것을 했다. 20여 년 가까이 IT부서에 있었지만, 매출 부서가 지원부서를 평가를 하는 경우는 사실 처음 겪어본 일이었다.


이 지원부서 평가라는 게 무엇이냐면 매출을 일으키는 매출 부서(영업, 출판, 학원 본부)가 지원을 해주는 지원부서를 매분기별로 평가하고 이 평가 내용을 바탕으로 1등부터 꼴찌까지 등수를 매기고 이 평가 결과를 전사에 공지하고 시상하는 제도였다.


이 지원부서 평가에서는 자격증팀, 공무원팀, 개발팀, 디자인팀, 서비스기획팀, 시스템팀, 인사팀, 재무팀, 총무팀 (약 20여개의 팀)까지 매출 부서를 제외한 모든 부서를 지원부서로 놓고 평가를 했다.


좋게 이야기를 하면, 일을 잘 도와주는 부서를 뽑아 상을 주자는 의미의 평가였다.


지원부서를 평가하는 매출 부서의 입장에서는 어떨지 모르겠지만 평가를 받는 지원부서의 부서장인 필자의 경우 매우 당황스러운 제도였다. 지원부서 매출 부서를 무슨 종족(??) 나누듯이 나누 것도 이상했고 지원부서를  매출 부서가 평가하는 것도 너무나 어색하고 이상했다.


지원부서 평가 보고서

아래는 매 분기마다 작성하는 지원부서의 팀에서 작성하는 분기별 업무지원 보고서이다.

회사의 기밀(??)을 지키기 위해 숫자는 X 표시를 했으니 양해 바란다.


지원부서 평가 발표자료



왜? 지원부서 평가제도가 생기게 되었을까?

지원부서 평가라는 제도에 대해 처음에는 정말 이해가 되지 않았지만, 왜? 지원부서 평가가 생겼는지 사연을 들어보면 한편으로 이해가 갔다.


교육업의 특성상, 매출 부서와 마케팅 부서는 시즌에 대한 이슈, 타사의 대응에 따른 맞대응 등으로 시간에 쫓겨 매우 급하게 업무를 처리를 해야 하는 경우가 빈번하였다.


이렇게 급박한 업무 요청에 대해 IT부서에서 원활하게 도움을 주지는 못할 망정, 항상 못한다 안된다는 부정적인 피드백과 더불어 업무의 지원이 원활하지가 않았던 적이 많았고, 이로 인해 실제 영업 활동에 많은 영향을 받았던 일이 많아 이러한 지원부서의 비협조를 근본적으로 없애기 위해, 매출 부서가 지원부서를 평가하는 프로세스를 만들었다는 것이었다.


이를 매출 부서의 입장에서 바라보면, 타사의 맞대응을 하려면 급한데, IT부서는 왜 이리 도와 주시 않느냐 였다.


빨리 좀 만들어줘 급하단 말이야!


필자가 다녔던 회사 역시 초기  IT본부에서 왜? 그렇게 방어적이고 수동적으로 그리고 발 빠르게 대응해 주지 못한 부분에 대해 근본적인 문제가 있을 알게 되었다.


 IT부서가 매출 부서가 요청한 업무가 하기 싫어서, 혹은 도와주기 싫어서 도와주지 않았다기보다는 근본적인 문제는 IT시스템이 매우 낙후가 되어 있어서였다. 운영 관리시스템이 자동화되어있지 못하다 보니 배너 하나 변경하는데도 많은 개발 리소스가 소요되었고, 통계자료를 하나 뽑는데도 DBA의 도움이 필요하다 보니, 어떠한 시스템을 하나 만들거나 운영하는 데 있어 예상 이상으로 개발 리소스가 너무 많이 들어가는 것이었다.


이렇게 개발 리소스가 많이 들어가다 보니 당연히 새로운 요청 업무에 있어서는 대응이 늦어질 수밖에 없었고, 결국 이러한 대응으로 인해 매출 부서와 마케팅 부서의 업무 요청을 원하는 일정에 맞춰 주지 못했던 일이 번했던 것이었다.


또 하나는 이렇게 업무를 요청하는 부서 중에 운영 툴이 잘 자동화되어있는 회사에 있다 온 인력의 있는 경우 더더욱 우리 회사의 IT 지원 상황에 대해서 이해를 하지 못했고, 여기저기서 IT본부를 디스(??) 하는 첨병 역할을 하게 되고, 이는 결국 지원부서를 통제하기 위한 제도에 대해 최고 경영진에서는 고민을 하는 계기를 만들게 되었다. 


이러한 이유들이 매출 부서가 지원부서를 평가하는 지원부서 평가 제도가 생길 수밖에 없는 근본적인 원인을 제공하게 된다.


흔한 업무 요청 사례를 하나 들어보면

30여 개의 아이템이 있고 이를 운영하는 30여 개의 웹사이트가 있는 회사라고 가정해보자.

통합 배너 운영관리 시스템이 없는 상황에서 마케팅 부서에서 모든 아이템 메인 페이지에 동시에 회원 모집 프로모션 배너를 적용해 달라는 요청이 온다면?? 개발 시간이 얼마나 걸릴까??


운영 툴이 자동화되어있지 않은 경우 하나의 웹사이트에 배너를 적용하는데 손 빠른 개발자가 5분 정도 걸린다고 가정하면, 30여 개의 웹사이트에 배너를 교체하는 데는 약 150분의 시간이 걸릴 것이다.


그런데 만일 운영 툴이 자동화되어있다면? 1분이면 끝낼 일을 무려 150분의 시간이 걸려서 업무를 처리하게 되니, 요청부서나 개발부서나 속 터지기는 매한가지 일 것이다.


여기서, 그럼 시간을 좀 더 내서 운영 툴을 자동화하면 되지 않느냐?라고 이야기할 수도 있지만, 이렇게 급박한 업무들이 매일매일 돌아가고 개발자들의 의욕이 떨어진 상태라면?? 개발자들에게 야근을 시켜 운영 툴을 자동화하는 일은 말하는 것만큼 쉽지가 않다.


운영 툴 자동화는 IT업무 생산성에 가장 중요한 일이다.


또 다른 예를 하나 들어보면

마케팅 부서에서 회원들을 대상으로 강의 만족도 설문조사를 이틀 안에 만들어달라는 요청이 왔다고 가정해보자. 마케팅 부서에서 설문조사를 만들어달라고 할 때, IT부서에서는 아래 3가지 방법 중 한 가지를 선택하여 설문조사 프로그램을 개발할 수가 있을 것이다.


1안. 직접 설문조사 프로그램을 개발자가 공을 들여 한 땀 한 땀 만드는 방법

2안. 기존에 만들어놓은 설문조사 프로그램이 있다면, 마케팅 부서의 니즈에 맞춰 설문조사를 튜닝하여 설문조사 다시 개발하는 방법

3안. 서베이 몽키(https://ko.surveymonkey.com/) 혹은 구글 설문조사와 같이 외부 서드파티 프로그램을 활용하여 설문조사를 진행하는 방법이 있을 것이다.


대부분의 IT부서에서는 안타깝게도 1안 또는 2안을 가지고 구축 일정을 요청부서와 뮤니케이션한다.

1/2의 경우는 짧으면 3~4일, 길면 일주일 정도의 개발 시간이 소요될 것이고, 설문의 내용이 변경될 때마다, 계속 개발 리소스가 들어가는 반면, 3의 경우는 기본적인 솔루션에 대한 사용법만 마케팅 부서에 알려주면, 그 이후에는 개발부서에서 할 일은 설문조사를 위한 URL 만 마케팅 부서에서 필요한 곳에 링크만 걸어주면 되니 사실 개발 리소스는 1h 정도면 충분할 것이다.


3안의 경우도 물론 회원정보를 연동하여 이를 결과와 연동해서 보여줘야 한다는 이슈가 있을 수도 있지만, 결국은 요청부서의 니즈를 파악하는 방법이 비즈니스 적인 관점에서 업무 요청을 바라보느냐 아니면 개발의 관점에서 요청 업무를 바라보느냐에 따라 IT 리소스의 극명한 차이 그리고 요청부서의 지원부서에 대한 평가가 극명하게 갈리게 되는 것이다.


만일 1으로 만들었다고 가정해보자, 마케팅 부서는 당연히 설문조사 이후에 설문 결과 데이터를 또 요청할 것이고 심지어는 분석까지 요청할 수도 있을 것이다. 그러면 개발 리소스는? 얼마나 들어갈까?


1/2의 경우 개발 리소스가 0.5 MM 이 든다고 가정하면, 3안은 1 day의 리소스면 충분할 것이다. 과연 여러분은 마케팅 부서와 협의를 통해 1/2안의 구축을 위해 개발 일정을 확보하는 것이 현명할까? 아니면 3번 안을 선택하는 것이 현명할까?


이 글을 본 독자라면 누구나 3안이 당연하다고 이야기하겠지만, 안타깝게도 대부분의 IT부서에서는 1/2안으로 결정을 하고 커뮤니케이션을 하고, 개발을 진행하게 될 것이다.


대부분의 IT 관련 업무 요청들은 생각만 조금 바꾸면 좀 더 쉬운 해결 방법이 있음에도 불구하고, 경험이 부족하거나 개발적인 관점만을 고수하다 보니 결국을 업무 요청부서와 트러블이 생길 수밖에 없는 상황이 만들어지게 되는 것이다.


IT에 근간을 두고 있는 회사가 아니라면 대부분의 IT부서는 업무 요청부서가 존재하고, 이 업무 요청부서의 업무 요청을 얼마나 빠르고 신속하게 대응을 해주느냐가 IT부서의 조직 성과를 좌우하는 것이 현실이다.


대부분의 IT 부서장의 경우 너무 개발의 관점에 치우친 나머지 마케팅적인 관점, 그리고 비즈니스적인 관점을 놓치는 것이 너무나 안타깝다.


필자는 IT본부장이지만 PM과 기획 background를 가지고 있고, 운이 좋게도 몇몇 회사에서는 마케팅을 전담해서 업무를 수행한 적이 있었다. 이러한 경험을 바탕으로 모든 요청부서의 업무를 개발적인 관점에 한정 짓지 않고, 마케팅과 비즈니스적인 관점에서 접근을 하다 보니, 요청부서의 니즈가 무엇인지 근본적인 니즈를 파악하기 위해 많은 노력을 기울이고 있다.


IT 부서장들이여 비즈니스&마케팅적인 관점에 대해 공부하자


이러한 근본적인 문제로 인해 지원부서 평가라는 프로세스가 생기기는 했지만, 지원부서 입장에서는 달갑지 만은 않은 것이 현실이기도 했다.


지만 어쩌겠는가? 필자도 이 글을 읽는 여러분도 모두 회사원인 것을!!


지원부서 평가 1등?

지원부서 평가가 썩 마음에 들지는 않지만, 제도가 만들어진 이상 1등을 해보자! 라는 생각으로 지원부서 평가 1등을 받기 위한 스터디에 들어가게 된다. 지원부서 평가 제도가 생긴 이후로 필자가 IT본부장으로 오기 전까지 개발팀은 한 번도 50% 안에 들지 못했다. 사실 1등이라기보다는 전체 50% 안에만 들자가 1차 목표였다. ^^;


지원부서 평가에 있어서 지원부서를 실질적으로 평가하는 사람은 매출 부서의 누구일까?? 과연 매출 부서의 부서장 홀로 앞서 보여주었던 지원부서 평가 발표자료만을 보고 평가를 할까??


은 사람들이 그렇게 오해할 수도 있지만 현실은 조금 다르다. 필자가 IT 본부의 본부장이지만 IT본부의 모든 팀과 부서원들의 업무를 완벽하게 파악을 하고 있지 못하는데 하물며 매출 부서의 부서장이 어떻게 IT본부의 모든 업무를 명확하게 파악을 하고 이를 평가하겠는가?


실제로 지원부서를 평가하는 사람은 매출 부서의 부서장 이기라기보다는 지원부서에 업무 요청을 하는 실무 요청자가 평가자라고 보는 것이 타당할 것이다.


필자가 우연히 알게 된 사실인데 실제 몇몇 매출 부서의 부서장의 경우 지원부서를 평가할 때는 매출 부서의 실무자들을 통해 지원 부서가 얼마나 협조적으로 일을 도와주는지를 파악하게 되고 결국 매출 부서의 협업 담당자의 지원부서에 대한 평가 내용을 근거로 해서 지원부서를 평가하게 되는 것이다


그러면 지원부서에서는 이러한 상황에서 매출 부서로부터 좋게 평가를 받으려면 어떻게 해야 하는 걸까?


필자가 속해 있는 IT본부의 개발팀은 안타깝게도 지원부서 평가에서 항상 낮은 순위를 기록하고 있었다.


왜? 이렇게 매출 부서로부터 낮게 평가를 받고 있는지 개발팀 내의 현황을 파악해보니 좋지 않게 평가를 받는 요소 중의 하나가 매출 부서와 주요 커뮤니케이션을 하는 개발 담당자가 매우 부정적이고 수동적인 응대로 인해 매출 부서 담당자로부터 좋지 않은 평가를 받고 있었고 이러한 이유로 인해 개발팀의 지원부서 평가에서 매우 좋지 않은 영향을 받고 있다는 사실을 알게 되었다.


그러면 이러한 문제를 해결하기 위해서는 두 가지 방법이 있을 것 같다. 


하나는 커뮤니케이션을 주로 담당하는 개발 담당자의 업무 R&R 조정을 통해 역할을 변경하거나, 이 개발 담당자의 지원부서의 마음가짐(??)을 가지도록 교육을 하는 방법이 있을 수 있을 것 같다. 제일 좋은 방법은 담당자에게 커뮤니케이션에 대한 중요성과 마인드를 개선하기 위한 교육을 시키는 것이고 이러한 교육을 통해 담당자가 개과천선(??)을 한다면 이것보다 좋은 해결책이 없지만, 사실 사람은 그리 쉽게 변하지 않아, 교육과 더불어 업무 R&R 을 통해 담당자의 역할을 일정 부분 변경하여, 좀 더 커뮤니케이션이 원활한 담당자로 주요 커뮤니케이션 담당자를 변경 하기도 했다.


필요하시죠? 만들어드립니다.

하지만, 결코 담당자의 커뮤니케이션만으로는 지원부서 평가를 좋게받기는 어렵다. 근본적으로 지원부서가 좋게 평가 받기 위한 방법은 매출 부서에서 가장 필요하고 매출에 도움이 될만한 무엇인가를 만들어 주는것이다.


필자가 매출 부서를 위해 만든 서비스 중에 가장 효과를 본 서비스는 바로 히트맵이었다.

사용자의 클릭을 이미지화해서 보여주는 히트맵


히트맵은 위의 화면에서 보이는 것처럼 웹을 이용하는 서용자가 홈페이지에 접속 후 어디를 제일 많이 클릭했는지는 보여주는 데이터 시각화 툴이다.


이 히트맵의 경우 별도 솔루션을 구매하여 적용할 수도 있고, 자바나 파이썬 등의 라이브러리를 활용하여 손쉽게 개발을 할수도 있다.


이 히트맵 기능이 매출 부서에 무슨 큰 도움이 되었나 싶기도 하지만, 필자가 있던 회사에서 마케팅 담당자는 자기가 올린 배너를 몇 명이나 클릭을 했고 어느 위치의 배너가 가장 효과적인지에 대한 정보를 전혀 파악을 하고 있지 못해, 부서장이 한마디 하면 배너의 위치를 바꾸고, 누가 한마디 하면 배너의 디자인을 바꾸는 등 한마디로 전혀 데이터에 기반한 웹사이트 운영을 하고 있지 못했다.


팝업을 띄우면 모든 방문자가 본다는 착각?


IT나 웹을 운영해본 경험이 없는 요청자가 가장 많이 실수하는 부분이 바로 팝업을 띄우거나 홈페이지에 배너를 도배하면 모든 배너를 모든 홈페이지 방문자가 모두 클릭해서 그 정보를 확인해 볼 것이다라고 착각을 하는 것이다.


필자가 운영하고 있는 회사의 홈페이지의 경우도 비슷한 문제가 있었다.


필자의 회사에서는 각 아이템 메인 페이지에 접속을 하기 위해 글로벌 메인 페이지라는 게이트 페이지를 운영하고 있었는데, 이 글로벌 메인 페이지의 방문자수가 가장 많았다. 이렇게 방문자수가 많은 페이지다 보니 매출 부서에서는 글로벌 메인 페이지에 배너를 띄우기를 희망했고, 동일한 위치에 무려 5개의 레이어 팝업이 겹쳐지게 노출이 되게 되었고, 이는 각각의 매출 부서들이 요청한 배너를 모두 적용하다 보니 발생한 문제였다.


필자가 매출 부서의 부서장들에게 필자의 경험을 바탕으로 이렇게 띄워진 레이어 팝업은 오히려 사용자의 사용성에 좋지 않은 영향을 주기 때문에 절대로 적용하면 안 된다고 수차례 이야기를 했으나 그 당시 신뢰도가 높지 않은(??) 필자의 의견이 전혀 반영되지 못하였다.


하지만 히트맵을 글로벌 메인 페이지에 적용하고 방문자들의 클릭 위치를 확인해보니 특정 위치에 방문자들의 클릭이 몰리는 것이 확인되었고 그 위치는 바로 레이어 팝업 닫기 위치에 그 클릭이 몰려있다는 것을 히트맵을 통해 확인하게 되었다.


결국 이러한 히트맵에 대한 정보를 근거로 매출 부서에서 요청한 모든 배너를 내릴 수가 있었고, 이렇게 만들어진 히트맵의 기능을 각 아이템(자격증 또는 공무원) 메인 페이지에 적용한 후 어떠한 배너가 가장 많이 클릭이 되는지에 대한 정보를 매출 부서에 제공해주었고, 이로 인해 매출 부서의 배너 운영 및 온라인 마케팅 활동에 도움을 주었고, 결론적으로는 매출에 도움을 주게 된다.


이러한 히트맵의 기능은 매출 부서에서 요청을 한 업무가 아니라, 필자와 IT본부의 인프라개발팀에서 스스로 알아서 매출 부서의 매출에 도움이 되는 기능을 만들어 제공을 했고 히트맵 이외에도 다양한 마케팅 서포트 기능 제공을 통해 IT본부의 인프라 개발팀은  IT본부 설립 이례 최초로 지원부서 평가에 50% 안에 드는 쾌거를 이루게 된다.


결국 지원부서가 매출 부서에 좋은 평가를 받기 위해서는 그들이 무엇을 원하는 지를 사전에 파악하고, 그들이 무엇인가를 요청하기 이전에 매출에 도움이 될 수 있는 무언가를 만들 때 좋은 평가를 받을 수 있다는 것이다.


말하지 않아도 알아서 그들이 원하는 것을 해준다.


이렇게 좀 더 앞서 매출 부서를 위한 지원업무는 결코 개발적인 관점을 고집할 때는 만들어낼 수 없는 성과이며 긍정적인 마인드와 적극적인 행동 그리고 비즈니스와 마케팅적인 관점에서 IT 업무를 바라볼 때 만들어 낼 수 있는 성과라고 생각한다. 더불어 이를 수행해줄 수 있는 실력있는 본부원들이 있어야 가능한 일이다.


이후 약 2년여간 흐른 시점 필자가 만들었던 인프라 개발팀은 최근 2분기 연속 지원부서 평가에서 1위를 하게 되고 이는 필자의 회사에서 지원부서 평가가 생긴 6년이래로 최초의 일이다. 이러한 일을 계기로 인해 IT 부서는 무엇보다 큰 자긍심을 가지게 되고, 필자의 본부에 있던 인프라 개발팀의 팀장과 파트장은 회사의 연간 우수사원으로 선정되기에 이른다.


이 자리를 빌려 힘들지만 필자를 믿고 끝까지 따라와 준 김ㅇㅇ팀장과 박ㅇㅇ 파트장 그리고 오ㅇㅇ, 이ㅇㅇ매니저에 감사의 말씀을 전한다.


지원부서 평가란?

지원부서 평가에 대해 좀 더 이야기를 해보자면 대표이사, 매출 부서장이 매분기별 지원부서를 평가하고 그 평가 결과를 전사에 공지하는 것이 과연 옳은 일인지에 대해서는 아직까지도 긍정적이라고 생각하지는 않는다.


하지만 결론적으로 이러한 지원부서 평가로 인해 지원부서들이 좀 더 적극적으로 매출 부서를 도와주는 문화가 생기게 되었고 이는 회사의 성장에도 기여를 한 것으로 보인다. IT 부서장이 느끼기에 썩 좋은 제도는 아니지만 필자가 다니고 있던 회사 차원에서는 적절한 제도가 아닌가 생각된다.


나 매출 부서야! IT본부 까불지 마!


더 이상 나 매출 부서야 IT본부 까불지 마!라는 이야기가 나오지 않도록, 매출 부서가 희망하는 지원사항은 문제없이 원활하게 지원을 할 수 있도록 조직문화와 시스템이 개편되어 이제는 지원부서 평가 제도가 없어도 되겠다 라는 최고 경영진의 의사결정이 이루어지기를 기대해본다.

매거진의 이전글 이 연봉 싫어? 그럼 나가!
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari