직접 만들까요, 패키지를 살까요

현장의 질문들 - 11

연구관리 시스템을 알아보면 결국 이 질문에 부딪힙니다. 패키지를 사야 하나, 만들어야 하나.
그런데 실제 시장에는 셋이 있습니다.

흔히 자체개발이라고 부르지만, 정확히는 업무 맞춤형 개발입니다. 사내에서 혼자 만드는 것이 아니라 우리 업무에 맞춰 만드는 것이기 때문입니다. 이 글에서는 맞춤형이라고 쓰겠습니다.

판단 기준은 하나로 좁혀집니다. 우리 업무를 패키지에 그대로 담을 수 있는가.

패키지가 맞는 경우

먼저 패키지가 좋은 경우를 봅니다. 여기에 해당하면 다른 선택을 고민할 이유가 없습니다.

정해진 규칙과 절차로 도는 업무

대상 업무가 정해진 규칙이나 절차에 따라 진행된다면 패키지가 맞습니다. 회사가 달라도 하는 일이 비슷하기 때문입니다.

회계와 인사가 대표적입니다. 법이 정한 방식이 있고, 절차가 정해져 있습니다. 여기서 우리만의 방식을 고집할 이유가 없습니다.

이미 검증된 구조

패키지에는 다른 회사들이 겪은 문제가 이미 반영되어 있습니다. 처음부터 만들면 그 문제들을 우리가 다시 겪게 됩니다.

변화 대응을 벤더가 합니다

규제가 바뀌거나 제도가 바뀌면 벤더가 따라갑니다. 맞춤형이면 우리가 판단하고 우리가 반영해야 합니다. 이건 생각보다 큰 차이입니다.

그리고 결정적으로, 저렴합니다

패키지는 그대로 쓰면 매우 저렴합니다. 이것이 패키지의 가장 큰 장점입니다.

다만 조건이 붙습니다. 그대로 쓸 수 있어야 합니다.

손을 대기 시작하면 달라집니다

패키지에 손을 대기 시작하면 값이 빠르게 올라갑니다.

그 제품의 구조를 아는 사람이 붙어야 하고, 다음 버전을 올릴 때 그 수정이 유지되는지도 매번 확인해야 합니다. 처음에 비교했던 그 가격이 아니게 됩니다.

왜 그렇게 되는가

패키지는 우리 회사만을 위해 만들어지지 않습니다. 여러 회사가 함께 쓰는 물건입니다.

그래서 우리 업무와 상관없는 것들을 함께 짊어지고 있습니다.

버전을 올릴 때 수많은 사용자에게 어떻게 전달할 것인가

구독형이라면 구독 정보를 어떻게 관리할 것인가

기존 시스템과의 연계는 회사마다 다르니, 모든 상황을 상정한 구조를 갖춰야 함

우리는 그중 한 가지만 쓰는데, 나머지도 함께 있습니다. 일반화의 부담이라고 할 수 있습니다.

그리고 두 가지가 빠져 있습니다

하나는 운영 부담입니다. 기능은 있는데, 누가 그 기능을 유지할 것인가는 설계에 잘 들어가지 않습니다. 마스터를 누가 갱신하고, 권한을 누가 관리하고, 오류를 누가 확인할 것인가. 도입한 뒤에야 드러납니다.

다른 하나는 현실의 사정입니다. 패키지는 여러 회사에 공통으로 쓰일 방식으로 만들어지다 보니, 가장 잘 정비된 조직을 기준으로 설계되는 경향이 있습니다. 잘못 만든 것이 아니라 그렇게 만들 수밖에 없습니다. 여러 회사의 서로 다른 사정을 다 담을 수는 없기 때문입니다.

R&D는 팀 안에서도 다릅니다

R&D 관리가 특히 어려운 이유가 여기 있습니다.

저희가 본 바로는, R&D는 회사마다 다르고, 같은 회사 안에서도 팀마다 다르고, 같은 팀 안에서도 다릅니다. 합성과 제제가 같은 팀에 있어도 기록하는 것이 다르고, 승인받는 순서가 다릅니다.

어떤 단위로 묶어도 하나의 형태로 모이지 않습니다.

회계나 인사에는 표준이 있습니다. R&D에는 그런 표준이 없습니다. 무엇을 기록할지, 어떤 순서로 승인할지, 어디까지를 한 건으로 볼지가 조직마다 다릅니다.

그래서 R&D 관리는 "그대로 쓸 수 있는" 경우가 드뭅니다.

다만 R&D 안에도 규칙대로 도는 업무가 있습니다

시험 의뢰와 결과 회신, 문서 결재, 연구비 집행 같은 것들입니다. 이런 업무까지 새로 만들 이유는 없습니다.

어디까지가 우리만의 방식이고 어디부터는 일반적인 절차인지를 가르는 것. 이것이 판단의 출발점입니다.

맞춤형의 값과 대가

맞춤형은 필요한 기능만 우리 업무에 맞춰 만듭니다. 그래서 가볍습니다. 쓰지 않을 기능이 화면에 없고, 우리와 상관없는 구조를 짊어지지 않습니다.

그리고 만들어진 것이 우리 자산입니다. 소스가 우리 것이므로 필요할 때 고칠 수 있습니다.

회사는 자라고, 하는 일도 바뀝니다

소스가 우리 자산이라는 것이 왜 중요한지는 시간이 지나야 드러납니다.

연구원 10명일 때는 결재 한 번이면 되던 일이, 50명이 되면 나뉩니다. 팀이 생기고, 권한이 갈리고, 보고 체계가 생깁니다. 조직이 바뀌면 시스템도 따라가야 합니다.

시스템이 한 시점의 방식으로 고정되어 있으면, 회사가 바뀔 때 시스템이 짐이 됩니다. 실제 일하는 방식과 화면이 어긋나기 시작하고, 사람들은 시스템 밖에서 일하게 됩니다.

이 점에서는 패키지에도 답이 있습니다. 여러 회사가 함께 쓰는 물건이라, 규모가 커졌을 때 필요한 기능이 대개 이미 들어 있습니다. 그때 가서 켜면 됩니다.

그런데 새로운 분야가 들어오면

규모가 커지는 것보다 어려운 변화가 있습니다. 하던 일이 아닌 일이 들어오는 것입니다.

화장품만 하던 회사가 건강기능식품을 시작하고, 소재를 공급하던 회사가 완제품 개발에 들어갑니다. 드문 일이 아닙니다.

패키지는 대개 하나의 산업, 하나의 사업 방식을 전제로 만들어집니다. 그래서 새 분야의 업무는 담을 자리가 없습니다. 담으려면 고쳐야 하고, 고치기 시작하면 앞에서 말씀드린 그 지점으로 돌아갑니다.

그러면 대개 새 사업은 시스템 밖에서 시작합니다. 엑셀로 관리하다가, 몇 년 뒤에 또 한 번 도입을 검토하게 됩니다.

다만 모든 신사업이 같은 부담을 주는 것은 아닙니다. 저희 경험으로는, 산업이 바뀌는 것보다 사업 방식이 바뀌는 쪽이 더 큽니다. 화장품 수탁개발을 하다 제약 수탁개발을 시작하는 것보다, 같은 화장품 안에서 수탁개발을 하다 자사 브랜드를 시작하는 쪽이 관리해야 할 것이 더 많이 달라집니다.

결국 같은 질문으로 돌아옵니다. 우리가 지금의 방식 그대로 커 갈 것인가.

대가도 있습니다

소스가 우리 자산이라는 것은 고칠 수 있다는 뜻이면서, 고쳐야 한다는 뜻이기도 합니다.

규제가 바뀌면 우리가 판단하고 우리가 반영합니다. 패키지는 그것을 벤더가 합니다. 무엇이 바뀌었는지 알아채는 일부터 우리 몫이 됩니다.

만들 수 있느냐가 아니라, 계속 손볼 수 있는 상태로 둘 수 있느냐를 물어야 합니다.

그리고 가장 큰 위험

맞춤형에서 가장 흔한 실패는 우리가 말한 대로만 만들어지는 것입니다.

우리 업무를 우리가 설명하는데, 그 설명에 빠진 것을 짚어줄 사람이 없으면 지금 방식이 그대로 화면이 됩니다. 종이로 하던 불편이 화면으로 옮겨오는 것입니다.

그래서 맞춤형을 택하실 때는, 같은 업종을 여러 번 해본 곳인지를 확인하셔야 합니다.

어느 쪽이든 남는 일

마지막으로 하나만 더 말씀드립니다.

어느 쪽을 고르든 마스터와 업무 정비는 그대로 남습니다. 우리가 쓰는 시약 목록, 시험 항목 이름, 결재 경로는 어느 패키지에도 들어 있지 않습니다.

틀은 사 올 수 있어도 내용은 채워야 합니다.

판단 기준

첫 줄이 전부입니다. 그대로 쓸 수 있으면 패키지가 가장 좋은 선택입니다. 고치기 시작해야 한다면, 어디까지 고칠 것인지부터 따져 보셔야 합니다.