PoC 계약, 범위·기간·비용·성공 기준을 먼저 못 박습니다

오픈이노베이션에서 가장 흔한 실패 유형이 무엇이냐고 물으시면, 저는 실증까지 갔는데 그다음이 없는 경우라고 답합니다.

기술이 안 됐던 게 아닙니다. 결과도 나쁘지 않았습니다. 그런데 끝나고 나서 아무 일도 안 일어납니다.

이 지점을 여러 번 겪고 나면 원인이 하나로 모입니다. 시작할 때 안 정한 것들이 끝날 때 문제가 됩니다.

무엇을 검증하는지부터 정합니다

「일단 한번 붙여보자」로 시작하는 검증이 많습니다. 무엇을 확인하려는 건지가 흐릿하면 결과를 해석할 기준도 없습니다.

검증에는 네 유형이 있습니다.

네 번째를 조금 더 말씀드리겠습니다. 기술 성능만 확인하고 도입했는데, 현장 작업자가 기존 방식을 계속 쓰는 경우가 있습니다. 화면이 어렵거나, 기존 시스템과 따로 놀거나, 교육이 없었거나.

이 경우 보고서에는 도입 완료로 남고 현장에서는 아무것도 안 바뀝니다. 그리고 다음 해에 「해봤는데 별로였다」로 정리됩니다.

범위는 좁을수록 좋습니다

넓게 잡으면 시간이 오래 걸립니다. 오래 걸리면 담당자가 바뀝니다. 담당자가 바뀌면 그동안 쌓인 맥락이 같이 나갑니다.

좁히는 방법은 네 가지입니다.

기간은 3개월

이유가 넷 있습니다.

사람이 안 바뀝니다. 인사이동은 대개 한 해에 한두 번인데, 이 길이면 그 사이를 통과합니다.

상대가 버팁니다. 개발자 두세 명을 석 달 빼는 건 감당이 되지만, 반년을 빼면 그 회사 자체가 휘청입니다.

보고 주기와 맞습니다. 분기 안에 결과가 나오면 그 분기 실적으로 잡힙니다.

그리고 잊히지 않습니다. 반년이 넘어가면 처음에 무엇을 확인하려 했는지를 양쪽 다 흐릿하게 기억합니다.

더 긴 검증이 필요하면 잘라서 가십시오. 석 달짜리 두 구간으로 나누고, 앞 구간 결과를 본 다음 뒤 구간을 열지 정하는 방식입니다.

비용 분담과 대외 공개는 같이 정합니다

협의가 가장 자주 막히는 지점입니다.

기준은 단순합니다. 이 검증으로 더 얻는 쪽이 더 냅니다. 우리 라인의 문제를 푸는 거라면 우리가 대고, 상대가 이력을 쌓는 게 주목적이면 상대 몫이 커집니다. 실제로는 대개 나눠서 부담합니다. 우리가 재료와 시험 비용을 대고 상대가 인력을 붙이는 형태가 많습니다.

문제는 비용을 상대에게 미루면서 대외 공개까지 막는 경우입니다.

「우리랑 하는 게 기회 아니냐」는 논리에 일리가 없지는 않습니다. 대기업 이력은 실제로 값이 있습니다. 다만 그 이력을 쓸 수 있어야 값이 생깁니다. 비밀유지 조항 때문에 어디에도 말할 수 없으면 남는 게 없습니다.

이 표가 절대 기준은 아닙니다. 다만 두 칸을 함께 놓고 협의하면 대화가 훨씬 빨리 끝납니다.

성공 기준을 숫자로 적으십시오

「잘되면 도입하겠습니다」로 시작한 검증은 끝나고 나서 판단이 갈립니다. 개발사는 됐다고 하고 발주사는 부족하다고 합니다. 둘 다 진심입니다. 기준이 없으니까요.

기준선은 지금 상태에서 가져오면 됩니다.

사람이 검사해서 불량을 열에 아홉 걸러내고 있다면, 기계는 그 선을 넘겨야 의미가 생깁니다. 한 건 처리에 10분이 걸린다면 몇 분까지 줄어야 도입할지를 먼저 적어둡니다. 설비가 한 달에 세 번 선다면 몇 번까지 줄어야 성공인지를 숫자로 박아둡니다.

지표는 영역별로 나눠 잡으시면 됩니다.

지표는 여러 개 잡되 등급을 나누십시오. 반드시 넘겨야 하는 항목과 그 정도면 받아들일 수 있는 항목으로요. 그래야 결과가 애매하게 나왔을 때 판단이 섭니다.

그리고 멈출 선도 함께 적으십시오. 어느 수치 아래면 중단한다는 기준이 있으면, 안 되는 검증에 몇 달을 더 붓지 않습니다.

다음 단계 조건을 계약에 넣으십시오

이게 빠지면 검증이 성공해도 거기서 멈춥니다.

성공 기준을 넘겼을 때 무엇이 자동으로 일어나는지를 적어두는 겁니다. 구매 협의를 개시한다든지, 다음 범위 개발을 우선 협상한다든지, 현업 부서로 이관해 정식 검토를 시작한다든지.

이걸 안 적어두면 검증이 끝난 시점에 처음부터 다시 설득해야 합니다. 그때는 프로그램 예산이 아니라 사업부 예산이라 결재선도 달라져 있습니다.

결과물의 권리를 나눠 적으십시오

계약서에서 자주 비어 있는 칸입니다.

먼저 배경기술을 명확히 합니다. 각자 이 검증 전부터 갖고 있던 기술은 각자 보유한다는 조항입니다. 이게 없으면 검증 과정에서 오간 것들의 경계가 흐려집니다.

그다음 신규 결과물입니다. 세 가지 방식 중 하나를 고릅니다.

공동 소유로 하는 방식. 지분과 사용 조건을 함께 적어야 합니다. 안 적으면 나중에 한쪽이 쓰려 할 때마다 합의가 필요해집니다.

발주사 귀속으로 하고 개발사에 사용권을 주는 방식. 발주사가 비용을 전부 댄 경우에 씁니다.

개발사 귀속으로 하고 발주사에 사용권을 주는 방식. 개발사의 기존 제품을 우리 환경에 맞춘 경우에 자연스럽습니다.

어느 쪽이든 적혀 있는 것이 중요합니다. 비어 있으면 검증이 성공한 다음에 다투게 되고, 그 시점에는 이미 서로 기대가 다릅니다.

현업을 처음부터 넣으십시오

마지막으로 하나 더 말씀드리겠습니다.

담당 조직이 검증을 다 끝낸 다음 결과만 현업에 넘기는 순서가 있습니다. 이렇게 가면 현업 입장에서는 처음 보는 물건이 도착하는 셈입니다. 그리고 처음 보는 물건에는 질문이 붙게 마련입니다.

설계 단계부터 현업 담당자를 넣으면 두 가지가 달라집니다. 성공 기준이 현실적으로 잡히고, 결과가 나왔을 때 이어받을 사람이 이미 있습니다.

예산도 두 칸으로 잡아 두십시오. 검증에 쓸 돈과 도입에 쓸 돈입니다. 결과가 잘 나왔는데 다음 예산 편성까지 반년을 기다리는 경우를 여러 번 봤습니다. 그 반년 안에 사람이 바뀌면 그동안의 진행이 통째로 원점입니다.

계약서에 네 칸이 채워져 있습니까

지금 진행 중이거나 준비 중인 검증 건의 계약서를 펴 보십시오. 네 칸이 채워져 있는지 봅니다.

성공 기준이 숫자로 적혀 있습니까. 성공했을 때 다음이 무엇인지 적혀 있습니까. 결과물의 권리가 나뉘어 있습니까. 그리고 현업 부서 담당자 이름이 어딘가에 있습니까.

네 칸이 다 비어 있으면, 그 검증은 끝나는 날이 마지막 날이 됩니다.

다음 편 — 오픈이노베이션 KPI, 매칭 건수를 세면 벌어지는 일