업무를 시스템에 맞출 것인가, 시스템을 업무에 맞출 것인가

실무 이야기 - 3

들어가며

이 블로그에서 저희는 같은 말을 여러 번 반복했습니다.

그런데 정작 어떻게 나누는지는 한 번도 말씀드리지 않았습니다. 오늘 그 이야기를 하겠습니다.

다만 방법을 이야기하기 전에, 왜 나눠야 하는지부터 짚어야 할 것 같습니다. 그 이유가 R&D라는 영역의 구조적인 조건에서 나오기 때문입니다.

1. R&D에는 PMO가 없습니다

본론에 들어가기 전에, R&D 관리 시스템을 설계할 때 반드시 전제해야 할 조건 하나를 짚고 시작하겠습니다.

건설, 플랜트, 대형 SI 같은 중대형 프로젝트에는 대개 PMO(Project Management Office)가 있습니다. 프로젝트 관리를 전담하는 별도 조직입니다.

이들이 하는 일이 있습니다. 일정을 갱신하고, 진척을 집계하고, 원가를 분석하고, 리스크를 정리하고, 시스템에 데이터를 넣고 보고서를 뽑습니다. 관리가 그 사람들의 본업입니다. 그래서 관리 항목이 많아도 감당이 됩니다. 오히려 정교할수록 그 조직의 존재 이유가 분명해집니다.

R&D는 사정이 완전히 다릅니다.

연구책임자가 연구도 하고 관리도 합니다. 실험을 설계하고, 데이터를 보고, 논문을 읽고, 그러다 시스템에 들어가 일정을 갱신하고 실적을 입력합니다. 대부분의 연구소에 관리를 전담하는 인력은 없습니다. 관리 업무의 원가가 연구 시간에서 그대로 빠져나갑니다.

이 차이가 왜 결정적이냐면, 관리 항목을 하나 늘릴 때마다 연구 시간이 줄어들기 때문입니다.

PMO가 있는 프로젝트에서 관리 항목을 늘리는 것은 전담 인력의 업무가 늘어나는 일입니다. R&D에서 관리 항목을 늘리는 것은 연구원이 연구를 덜 하게 되는 일입니다. 성격이 전혀 다릅니다.

그래서 R&D 관리 시스템 설계에는 다른 영역에 없는 제약이 하나 붙습니다.

관리를 잘하는 것만이 목표가 아닙니다. 관리 로드를 최소화하면서 필요한 관리가 되게 하는 것이 목표입니다. 이 둘은 서로 당기는 방향이라, 어느 한쪽만 보고 설계하면 반드시 실패합니다.

그리고 이 제약이 과제 유형을 나눠야 하는 이유로 곧장 이어집니다.

모든 과제에 똑같은 관리를 요구하면, 작은 과제일수록 관리 로드의 비중이 커집니다. 3명이 6개월 하는 과제에 대형 과제와 같은 입력을 요구하면, 관리 업무가 연구 업무를 압도하는 상황이 벌어집니다.

2. 하나의 양식으로 관리하면 무슨 일이 생기는가

방법 이야기를 하기 전에, 나누지 않으면 무슨 일이 생기는지부터 보겠습니다.

연구원 세 명이 6개월간 겸임으로 수행하는 과제가 있습니다. 그리고 서른 명이 3년간 전담으로 수행하는 과제가 있습니다. 이 둘이 같은 등록 화면, 같은 필수 항목, 같은 계획서 양식을 씁니다.

결과가 무엇을 만드는지 알아낼 수 없는 탐색 과제가 있습니다. 그런데 등록할 때 완료 예정일과 산출물 목록을 채우라고 합니다. 채워야 다음으로 넘어가니까 담당자는 채웁니다. 모르는 값을요.

국가과제 양식을 그대로 사내 과제에 적용한 경우도 있습니다. 정부에 보고하기 위해 만들어진 항목들이 사내 소규모 과제에까지 요구됩니다.

그러면 사람들은 이렇게 대응합니다. 안 맞는 칸은 비우거나, 아무 값이나 넣습니다. 작년 것을 복사해서 붙여넣습니다.

그리고 몇 달 뒤, 아무도 그 데이터를 믿지 않게 됩니다.

여기에 역설이 있습니다. 관리를 잘하려고 항목을 늘렸는데, 늘릴수록 관리가 안 됩니다. 입력을 강제할수록 데이터의 신뢰도가 떨어지기 때문입니다.

3. 이것은 결국 방향의 문제입니다

왜 이런 일이 반복될까요. 문제의 뿌리는 접근 방향에 있습니다.

패키지를 도입한다는 것은 업무를 시스템에 맞추는 일입니다.

ERP나 MES를 생각해 보십시오. 이 시스템들은 검증된 표준 프로세스를 담고 있고, 도입한다는 것은 그 프로세스에 우리 업무를 맞춘다는 뜻입니다. 그리고 이것은 합리적인 선택입니다. 재무, 회계, 생산, 재고 같은 영역은 업무가 상당히 표준화되어 있어서, 굳이 우리만의 방식을 고집할 이유가 없습니다.

그런데 R&D는 다릅니다.

앞선 글에서 저희는 R&D 관리체계에 정답이 없다고 말씀드렸습니다. 산업마다 다르고, 기업마다 다르고, 그 기업의 역사와 사업 모델이 그대로 반영되기 때문입니다.

여기에 패키지 논리를 적용하면 어떻게 될까요. 조직이 시스템에 자기를 구겨 넣게 됩니다. 우리 방식대로 일하던 것을 시스템이 요구하는 방식으로 바꾸거나, 아니면 시스템 밖에서 원래대로 일하고 시스템에는 형식적으로만 입력하거나. 대개는 후자가 됩니다.

과제 유형을 나눈다는 것은 정확히 그 반대 방향입니다.

우리 연구소에 실제로 존재하는 과제들이 어떤 종류인지 먼저 확인하고, 각각에 맞는 관리 방식을 시스템에 담는 것입니다. 순서가 반대인 셈입니다.

4. 유형은 업무의 언어로 나눕니다

그러면 무엇을 기준으로 나눌까요.

여기서 흔히 하는 실수가 있습니다. 관리하는 쪽 시각으로 나누는 것입니다. 규모별로 나눈다든가, 예산 구간별로 나눈다든가, 결재선별로 나눈다든가. 이렇게 나누면 문제가 생깁니다. 연구원이 자기 과제가 어느 유형인지 알기 어렵습니다. 등록 화면에서 목록을 보고 잠시 고민하다가, 대충 하나를 고릅니다. 그 순간 유형 체계는 의미를 잃습니다.

유형은 연구원이 실제로 쓰는 말로 나눠야 합니다.

제약회사라면 이런 말들일 겁니다. 신약, 개량신약, 제네릭, 원료. 연구소에서 "그거 개량신약 과제잖아"라고 하면 다들 압니다. 무슨 일을 어떻게 하는지, 얼마나 걸리는지, 무엇이 어려운지가 그 단어 하나에 담겨 있습니다.

화장품이라면 다른 목록이 나올 것이고, 소재나 부품이라면 또 다를 것입니다. 산업마다 언어가 다르기 때문입니다.

업계 언어로 나누면 좋은 점이 분명합니다. 담당자가 헷갈릴 일이 없습니다. 자기 과제가 제네릭인지 개량신약인지 고민하는 연구원은 없으니까요. 고민 없이 고를 수 있다는 것은, 그 값이 정확하게 채워진다는 뜻입니다.

그래서 패키지가 R&D에서 잘 안 먹힙니다

여기서 앞 장의 이야기와 연결됩니다.

패키지 제품은 유형 목록을 미리 정해서 팝니다. 그런데 그 목록은 어느 산업의 언어도 아닙니다. 여러 산업에 다 팔아야 하니 일반적인 말로 만들 수밖에 없고, 그러면 어느 회사에서도 자기 말처럼 느껴지지 않습니다.

연구원이 화면을 열었을 때 낯선 단어가 나열되어 있으면, 그때부터 시스템은 남의 것이 됩니다.

5. 과제는 한 층이 아닙니다

유형을 세우다 보면 한 가지를 발견하게 됩니다. 성격이 다른 것들이 한 목록에 섞여 있다는 점입니다.

앞서 예로 든 제약을 다시 보겠습니다. 신약, 개량신약, 제네릭, 원료. 여기에 탐색, 비임상, 임상을 나란히 놓으면 어떨까요.

섞여 있습니다. 앞의 넷은 무엇을 개발하는가이고, 뒤의 셋은 개발의 어느 단계인가입니다. 신약 과제가 탐색 단계를 거쳐 비임상으로, 다시 임상으로 가는 것이라면, 이 둘은 나란히 놓일 것이 아니라 위아래로 놓여야 합니다.

그래서 과제 관리에는 계층이 필요합니다. 대과제와 세부과제입니다.

• 대과제 — 신약 A 개발
• 세부과제 — 탐색, 비임상, 임상

층이 나뉘면 보는 것도 나뉩니다

이 구조가 중요한 이유는 계층이 예뻐서가 아닙니다. 각 층에서 보아야 할 것이 다르기 때문입니다.

대과제 층에서 묻는 질문은 이렇습니다. 이 과제는 우리 포트폴리오에서 어디에 있는가. 지금까지 얼마를 투입했는가. 사업화 목표에 다가가고 있는가. 계속 갈 것인가, 접을 것인가.

세부과제 층에서 묻는 질문은 다릅니다. 일정대로 가고 있는가. 참여 연구원은 적정한가. 연구비 집행에 문제는 없는가. 어떤 이슈와 리스크가 있는가.

앞의 것은 경영진과 연구기획이 보는 질문이고, 뒤의 것은 연구책임자가 보는 질문입니다.

여기서 저희가 앞선 글에서 다뤘던 이야기가 다시 나옵니다. 선정의 책임과 실행의 책임은 구분되어야 한다고 말씀드렸습니다. 무엇을 할지 정하는 것과, 정해진 것을 해내는 것은 다른 일이라고요.

계층 구조는 그 경계선을 시스템 안에 그어놓는 일입니다. 개념으로만 이야기하던 것이 실제 구조가 되는 지점입니다.

흔한 함정 하나

계층을 만들고 나면 대개 이런 기능을 원하게 됩니다. 세부과제 진척률을 모아서 대과제 진척률을 자동으로 계산하는 것.

그런데 이게 잘 안 맞습니다. 신약 과제에서 탐색 단계 100%와 임상 단계 100%는 무게가 전혀 다릅니다. 단순 평균을 내든 가중치를 주든, 나온 숫자가 실제 상황을 설명하지 못합니다. 그리고 그 숫자를 보고 판단하면 판단이 틀립니다.

위층은 진척률이 아니라 단계로 보아야 합니다. 지금 어느 단계에 있고, 다음으로 넘어갈 조건을 충족했는가. 숫자 하나로 압축하려는 시도가 오히려 정보를 없앱니다.

참고로 여러 해에 걸친 과제를 연차별로 나누는 경우도 있습니다. 계획과 예산이 연 단위로 돌아가기 때문입니다. 이걸 계층으로 볼 것인지 같은 층에 나란히 놓을 것인지는 설계 시점에 판단이 필요한 지점입니다. 어느 쪽을 택하느냐에 따라 나중에 통계를 뽑는 방식이 달라집니다.

6. 유형과 가변성은 다른 층입니다

여기서 자주 받는 질문이 있습니다. "그래서 유형은 몇 개가 적당합니까?"

유형을 나누기 시작하면 자꾸 늘어납니다. 이 과제도 좀 다르고 저 과제도 좀 다르니까요. 그러다 열 개를 넘기고, 스무 개가 됩니다. 그러면 담당자가 다시 헷갈리기 시작합니다.

절대적인 숫자는 없습니다. 다만 저희 경험으로는 다섯 개 내외면 대부분의 연구소에서 충분합니다.

이게 가능한 이유는, 유형이 모든 차이를 담을 필요가 없기 때문입니다.

유형은 골격입니다. 큰 성격이 다른 것들을 가르는 층이지, 세세한 차이까지 반영하는 층이 아닙니다. 같은 유형 안에서도 과제마다 다른 부분은 관리 항목 수준에서 조율하면 됩니다.

같은 개발 과제라도 규모가 작으면 일정을 마일스톤만으로 관리하고, 크면 더 아래까지 내려가는 식입니다. 이건 다른 유형이 아니라 같은 유형 안의 다른 깊이입니다.

유형이 자꾸 늘어난다면 의심해 볼 만합니다. 아래에서 흡수해야 할 차이를 위로 올리고 있는 것은 아닌지요.

그리고 한 가지 더. 유형은 한번 정하면 끝나는 정답이 아닙니다. 이 이야기는 뒤에서 다시 하겠습니다.

7. 유형별 계획 템플릿 — 실제로 효과가 큰 지점

유형을 나누면 무엇이 좋아지는지, 가장 체감되는 것부터 말씀드리겠습니다.

계획서를 백지에서 쓰는 일은 생각보다 큰 부담입니다.

연구원 입장에서 과제 계획을 세운다는 것은 연구 자체와 다른 종류의 일입니다. 무엇을 얼마나 자세히 써야 하는지, 어디까지가 적정한지 판단이 서지 않습니다. 그래서 시간이 오래 걸리고, 결국 예전 문서를 찾아 복사하게 됩니다.

유형별로 계획 템플릿이 준비되어 있으면 상황이 달라집니다.

과제를 등록하면서 유형을 고르는 순간, 그 유형에 맞는 계획 구조가 이미 잡혀 있습니다. 어떤 항목을 채워야 하는지, 어느 정도 수준으로 써야 하는지가 보입니다. 백지가 아니라 절반쯤 채워진 상태에서 시작하는 것입니다.

효과는 두 가지입니다.

첫째, 계획 수립 부담이 크게 줄어듭니다. 연구원이 계획서에 쓰는 시간이 줄고, 그만큼 연구에 쓸 시간이 늘어납니다.

둘째, 계획서의 수준이 일정하게 확보됩니다. 이게 더 중요할 수도 있습니다.

지금 대부분의 연구소에서 계획서 품질은 작성자에 따라 들쭉날쭉합니다. 꼼꼼하게 쓰는 사람의 계획서와 대충 쓰는 사람의 계획서가 같은 결재선을 타고 올라갑니다. 검토하는 쪽에서도 매번 다른 형태의 문서를 봐야 합니다.

템플릿은 그 편차를 줄입니다. 잘 쓰는 사람의 방식이 템플릿이 되면, 그것이 조직의 기준선이 됩니다. 신입 연구원이 처음 쓰는 계획서도 그 기준선 위에서 시작합니다.

이것 역시 저희가 계속 말씀드려 온 이야기와 같습니다. 개인에게 있던 노하우를 시스템에 담는 일입니다.

8. 유형마다 관리 항목과 기법이 달라집니다

유형을 나누는 진짜 목적은 여기 있습니다. 나눠놓고 똑같이 관리하면 나눈 의미가 없습니다.

과제 관리에서 다루는 항목은 대체로 이런 것들입니다.

• 일정
• 연구비
• 참여 연구원
• Issue & Risk
• 그리고 산출물

그리고 각 항목마다 관리하는 기법이 여러 층위로 존재합니다. 일정 하나만 놓고 봐도 마일스톤으로 큰 흐름만 잡을 수도 있고, Gantt로 일정을 펼칠 수도 있고, Activity와 Task 수준까지 내려갈 수도 있습니다.

핵심은 유형에 맞는 항목과 기법을 고르는 것입니다.

모든 과제에 Gantt를 요구할 필요는 없습니다. 겸임 연구원 세 명이 6개월 하는 과제에 Activity 단위 일정을 요구하면, 그 일정표를 유지하는 데 연구보다 많은 시간이 듭니다. 반대로 대형 과제에 마일스톤 몇 개만 두면 무슨 일이 벌어지고 있는지 알 수 없습니다.

첫 장에서 말씀드린 조건이 여기서 실제로 적용됩니다. R&D에는 관리를 전담할 PMO가 없습니다. 관리 기법을 한 단계 정교하게 만들 때마다 그 부담은 연구원에게 갑니다.

그래서 판단의 기준은 "더 정교하게 관리할 수 있는가"가 아니라 "이 과제에 이 정도의 관리가 필요한가, 그리고 그 부담을 연구가 감당할 수 있는가"입니다. 유형을 나누는 목적이 바로 이 판단을 과제마다 따로 하지 않고, 유형 단위로 한 번 정해두는 것입니다.

관리 항목과 항목별 관리 기법을 어떻게 고르고 조합할 것인가는 그 자체로 큰 주제입니다. 별도의 글에서 자세히 다루겠습니다.

9. 유형 체계는 계속 바뀌어야 합니다

마지막으로 가장 중요한 이야기를 하겠습니다.

앞선 글에서 저희는 관리체계에는 그 기업의 문화가 담긴다고 말씀드렸습니다. 조금 더 정확히 말하면, 경영진의 의도와 정책이 담깁니다.

어디에 자원을 집중할 것인지, 무엇을 중요하게 볼 것인지, 어떤 과제를 늘리고 어떤 과제를 줄일 것인지. 이런 판단이 과제 유형 체계와 관리 항목에 그대로 반영됩니다.

그리고 그 판단은 바뀝니다.

• 사업이 커지면서 조직이 개편됩니다
• 신사업이 생기면서 지금까지 없던 성격의 과제가 들어옵니다
• 외부 협력이 늘어나면서 위탁이나 공동연구 과제가 많아집니다
• 경영진이 바뀌면서 R&D에 대한 기대가 달라집니다

여기서 중요한 것은 타이밍입니다.

변화가 생겼는데 시스템이 따라가지 못하면, 현장은 기다려주지 않습니다. 시스템 밖에서 일하기 시작합니다. 엑셀로 따로 관리하고, 메일로 주고받고, 시스템에는 나중에 형식적으로 입력합니다.

그리고 한번 그렇게 되면 되돌리기가 대단히 어렵습니다. 이미 밖에서 돌아가는 방식이 자리를 잡았고, 시스템으로 돌아오라고 하려면 처음 도입할 때보다 더 큰 설득이 필요합니다.

그래서 두 가지가 준비되어 있어야 합니다.

첫째, 구조적으로 바꿀 수 있어야 합니다. 유형과 관리 항목이 프로그램 코드에 박혀 있으면 못 바꿉니다. 바꾸려면 개발이 필요하고, 개발이 필요하면 예산과 일정이 필요하고, 그러면 타이밍을 놓칩니다. 운영 담당자가 직접 조정할 수 있는 구조여야 합니다.

둘째, 누가 언제 손볼 것인지가 정해져 있어야 합니다. 바꿀 수 있는 구조를 만들어놓고 아무도 안 보면 소용없습니다. 어떤 신호를 관찰할 것인지, 누가 책임지고 검토할 것인지, 얼마나 자주 볼 것인지가 정해져 있어야 합니다.

저희가 구축이 끝난 뒤에도 변화관리를 고객과 함께 수행한다고 말씀드리는 이유가 여기 있습니다. 시스템은 완성품이 아니라, 조직과 함께 계속 조정되는 것이기 때문입니다.

10. 그래서 어디서부터 시작하나

읽고 나서 무엇을 해볼 수 있을지 정리하겠습니다.

지난 2~3년간 수행한 과제 목록을 펼쳐놓는 것부터 시작하십시오.

그리고 이론적인 분류표를 먼저 만들지 마십시오. 실제로 관리 방식이 달랐던 것끼리 묶어보는 것이 먼저입니다. 계획서 양식이 달랐던 것, 결재선이 달랐던 것, 보고 주기가 달랐던 것.

묶다 보면 자연스럽게 덩어리가 보입니다. 그리고 어느 덩어리에도 안 들어가는 과제가 나올 텐데, 억지로 밀어 넣지 마십시오. 그건 별도 유형이거나, 아니면 정말 예외적인 과제입니다.

그리고 이 작업은 IT 부서의 일이 아닙니다. 연구기획의 일입니다. 우리 연구소가 어떤 과제를 하고 있고 어떻게 관리해야 하는지는 IT가 알 수 없는 영역이기 때문입니다.

시스템 구축을 검토하고 계시다면, 업체를 부르기 전에 이 작업을 먼저 해보시길 권합니다. 이것만 정리되어 있어도 이후 과정이 완전히 달라집니다.

정리하며

• R&D에는 관리를 전담할 PMO가 없습니다. 관리 항목을 늘리는 것은 곧 연구 시간을 줄이는 일입니다
• 하나의 양식으로 모든 과제를 관리하면, 데이터의 신뢰도가 무너집니다
• 패키지 도입은 업무를 시스템에 맞추는 일이고, 유형 구분은 시스템을 업무에 맞추는 일입니다
• 유형은 관리자 편의가 아니라 연구원이 실제로 쓰는 업무 언어로 나눕니다
• 과제는 한 층이 아닙니다. 대과제와 세부과제는 보는 질문이 다릅니다
• 유형은 골격입니다. 세세한 차이는 유형 안에서 조율하면 되고, 대체로 다섯 개 내외면 충분합니다
• 유형별 계획 템플릿은 연구원의 부담을 줄이고 계획서 수준을 일정하게 만듭니다
• 유형마다 관리 항목과 기법이 달라야 합니다
• 그리고 유형 체계는 계속 바뀌어야 합니다. 중요한 것은 타이밍입니다

저희는 25년간 다양한 산업의 연구소에서 이 작업을 함께해 왔습니다. 산업이 다르고 회사가 다르니 나온 결과도 모두 달랐습니다. 그것이 정상입니다. 같은 답이 나왔다면 오히려 무언가 잘못된 것입니다.