그 회사에서는 됐다는데, 왜 우리는 안 맞습니까

구축의 순서 - 1

동종업계 사례 발표를 듣고 옵니다. 잘 정리돼 있고, 화면도 깔끔하고, 성과 숫자도 나옵니다. 질의응답도 매끄럽습니다.
돌아와서 회의를 합니다. "우리도 저렇게 해봅시다."
그런데 6개월 뒤에 보면 잘 안 굴러갑니다. 도입은 했는데 쓰는 사람이 별로 없고, 처음에 기대했던 장면은 안 나옵니다.
우리가 못해서가 아닙니다. 그 발표에 없던 것들이 있기 때문입니다.

베스트 프랙티스에 없는 것들

먼저 짚고 시작하겠습니다. 타사 사례가 쓸모없다는 이야기가 아닙니다. 다만 거기에 원래 담기지 않는 것들이 있습니다.

하나, 도착점은 보이는데 경로가 안 보입니다.
발표에 나오는 것은 지금 상태입니다. 3년 전에 무엇부터 시작했는지, 도중에 무엇을 포기했는지, 어디서 한 번 엎고 다시 했는지는 나오지 않습니다. 우리에게 필요한 것은 그 순서인데, 그건 발표 자료에 안 들어갑니다.

둘, 그 회사의 배경과 문화는 표현할 방법이 없습니다.
어느 회사에서 그 체계가 굴러가는 이유는 화면 설계 때문만이 아닙니다. 20년간 그 회사가 일해온 방식, 부서 사이의 관계, 말하지 않아도 통하는 관행 같은 것들이 밑에 깔려 있습니다.

그런데 이런 것은 발표로 옮길 수가 없습니다. 발표하는 쪽도 그것이 자기 회사의 특수한 조건이라는 걸 잘 모릅니다. 너무 당연해서 말할 생각을 못 합니다.

앞선 글에서 이야기한 것과 같은 구조입니다. 모두가 아는 것은 말해지지 않고, 말해지지 않은 것은 전달되지 않습니다.

셋, 발표에는 성공만 담깁니다.
실패한 시도는 발표되지 않습니다. 중간에 접은 기능, 만들어놓고 아무도 안 쓰는 화면, 두 번 엎은 코드 체계. 정작 우리에게 값어치 있는 것은 "그건 해봤는데 안 되더라"인데, 그건 어느 발표에도 없습니다.

그리고 발표는 성과를 보여주는 자리이니 결과가 다소 다듬어집니다. 탓할 일은 아닙니다. 다만 그것을 그대로 우리 계획의 근거로 삼으면 곤란해집니다.

그래서 출발점은 남의 회사가 아니라 우리 회사입니다. 지금 우리가 무슨 일을 어떻게 하고 있는지를 먼저 봐야 합니다.

기업은 단위기능의 집합입니다

회사를 조직도로 보면 부서가 보입니다. 그런데 부서는 사람을 나눈 것이지 일을 나눈 것이 아닙니다.

일로 나누면 다른 것이 보입니다. 과제 후보를 평가하는 일, 개발 계획을 세우는 일, 단계 진입을 심의하는 일, 실험 조건을 정하는 일, 위탁처를 고르는 일. 이런 것들을 단위기능(Function)이라고 부르겠습니다.

부서 이름은 같아도 그 안에 든 단위기능은 회사마다 다릅니다. 어느 회사의 개발팀에는 시장 조사가 들어 있고, 다른 회사에서는 기획팀이 합니다. 조직도만 봐서는 이게 안 보입니다.

여기서 구분 하나를 짚고 가겠습니다. 실무에서 자주 섞이는 부분입니다.

연구원이 열 명인 회사에서는 한 사람이 여덟 개 단위기능을 맡습니다. 백 명이 되면 갈라집니다. 단위기능이 늘어난 것이 아니라 Role이 나뉜 것입니다.

그래서 순서가 있습니다. 단위기능을 먼저 적고, 그다음에 Role을 붙입니다. 반대로 하면 조직도를 옮겨 적은 것에 지나지 않습니다. R&R을 정한다면서 부서 이름부터 그리기 시작하면 대개 이렇게 됩니다.

무엇이 회사 간 차이를 만듭니까

그러면 단위기능의 구성은 무엇에 따라 달라집니까.

산업이 아닙니다.

같은 화장품 회사인데 자사 브랜드를 만드는 곳과 ODM으로 수탁하는 곳은 하는 일이 전혀 다릅니다. 앞의 회사는 무엇을 만들지 스스로 정합니다. 뒤의 회사는 고객이 정해서 옵니다. 시작점 자체가 다르니 그 뒤가 다 다릅니다.

반대로 화장품 ODM과 제약 CDMO는 산업이 다른데도 닮았습니다. 둘 다 고객 요청에서 시작하고, 받을지 판단하고, 납기 안에 맞춰야 하고, 고객 승인을 받아야 합니다.

차이를 만드는 것은 사업모델입니다.

한 회사가 둘 이상을 겸하는 경우도 많습니다. 자사 브랜드도 하고 ODM도 하는 화장품 회사가 그렇습니다. 그때는 두 세트를 다 갖되 과제마다 어느 쪽인지 지정합니다.

산업과 규모도 영향을 줍니다. 다만 역할이 다릅니다. 사업모델은 어떤 단위기능이 있는지를 정하고, 산업은 각 단위기능의 규제 요건과 무게를 정하고, 규모는 Role을 몇 개로 나눌지를 정합니다.

유형이 다르면 중요한 자리가 다릅니다

마지막 줄을 봐 주십시오.

자사제품형은 결정이 드물고 무겁습니다. 포트폴리오 확정은 연에 한두 번이고, 한 번에 수십억이 걸립니다. 한 건의 값어치가 크니 기록에 공을 들일 수 있습니다.

수탁개발형은 잦고 가볍습니다. 처방 조정 판단이 매주 일어납니다. 한 건에 5분씩 걸리는 체계를 만들면, 아무리 잘 만들어도 3주 만에 멈춥니다.

같은 체계를 그대로 옮기면 안 되는 이유가 여기 있습니다. 자사제품형 회사에서 잘 돌아가는 방식이 수탁개발형 회사에서는 부담만 되고 아무도 안 씁니다. 기능이 부족해서가 아니라 무게가 안 맞아서입니다.

그래서 시작점이 다릅니다

수탁개발형 회사에 전략부터 시작하라고 하면 안 맞습니다. 그 회사에서 전략 결정은 연에 몇 번 없고, 매일 일어나는 것은 실행 쪽 판단입니다. 거기서 성과가 나와야 사람들이 계속 씁니다.

"무엇부터 해야 합니까"에 하나의 답은 없습니다. 그런데 유형이 정해지면 답이 나옵니다.

첫 작업은 적어보는 것입니다

시스템을 고르는 일도, 컨설팅을 받는 일도 아닙니다.

우리 회사의 단위기능을 적어보는 것입니다. 부서 이름이 아니라 일의 이름으로요.

적어보면 대개 이렇게 됩니다.

대부분은 이미 관리되고 있습니다. 주문, 자재, 생산, 회계, 실험 기록. ERP가 있고 20년째 돌아갑니다. 잘 굴러가고 있고, 이 구축의 대상도 아닙니다.

그리고 몇 개가 남습니다. 아무 시스템에도 없고, 사람 머릿속과 개인 폴더에만 있는 것들입니다.

그 몇 개가 이 구축의 대상입니다.

다음 편에서는

그러면 그 둘을 어떻게 가릅니까.

무엇이 이미 담겨 있는 일이고 무엇이 남는 일인지, 그 기준을 다음 편에서 다루겠습니다. 이걸 안 하고 시스템부터 깔면 결재 단계만 늘어납니다.