계획은 있었지만, 연결은 없었다

[연재를 시작하며] 한 회사의 이야기를 세 편에 나눠 해보려 합니다. 프로젝트 이야기는 보통 결과 한 장으로 요약되곤 하는데, 이 회사의 여정만큼은 순서대로 들려드리고 싶기 때문입니다 – 문제를 발견하고, 실행을 연결하고, 숫자를 되찾는 과정 그대로. 오늘은 그 첫 번째입니다.

차량용 SoC를 설계하는 팹리스 기업입니다. 팹리스는 제조 설비 없이 파운드리와 패키징, 테스트로 이어지는 외부 협력사들의 공급망 위에서 사업을 합니다. 설계만 잘하면 되는 사업처럼 보이지만, 실제로는 수요예측에서 외주 생산과 출하까지를 계획대로 실행하고 그 결과를 경영이 통제할 수 있는 수치로 바꾸는 일이 사업의 핵심이 됩니다.

이 회사를 처음 만났을 때 제가 받은 인상부터 말씀드리면 – 준비가 없던 회사가 아니었습니다. 칩 생산이 본격화되고 물량이 늘면서 장납기 외주 생산을 감당할 계획 체계가 필요하다는 것을 일찍 알아차렸고, 고객 수요예측에 기반한 물량계획 시스템을 선제적으로 갖췄습니다. 외주 협력사와의 일정관리 기능도 있었고, 회계는 더존으로 분개와 재무제표 산출을 돌리고 있었습니다. 그 구조가 창업 이후의 성장을 실제로 떠받쳐 왔습니다.

이 회사 분들이 하신 말인데, 저는 지금도 이 문장을 기억합니다. 시스템이 없어서 온 회사가 아니라, 시스템이 있는데도 무언가 부족해서 온 회사 – 저희에게는 그게 더 어렵고, 그리고 더 흔한 출발점입니다.

들여다보니 단절이 생긴 경로가 보였습니다.

계획 시스템은 계획을 잘 세웠습니다. 문제는 그 계획이 실제로 그대로 실행됐는지 확인할 데이터가 없었다는 것입니다. 협력사의 생산 실적도, 어디에 얼마가 남아 있는지도 시스템 안으로는 들어오지 않았습니다. 그래서 이 회사는 가장 합리적인 선택을 합니다 – 계획 시스템 안에 물류 실행을 다루는 기능을 직접 개발하기 시작한 것입니다.

그 판단을 저는 잘못이라고 생각하지 않습니다. 필요한데 없으면 만드는 것이 성장하는 회사의 정상적인 반응입니다. 다만 그렇게 만들어진 실행 기능은 계획 시스템의 일부였고, 회계는 여전히 더존에 있었습니다. 둘은 애초에 이어지도록 설계된 적이 없는 사이였습니다. 실행이 생겼는데, 그 실행이 회계로 가는 길은 없었던 것입니다.

이것이 이 회사가 겪은 단절의 시작입니다. 없어서 만들었는데, 만든 것이 또 하나의 섬이 되었습니다.

계획과 실적이 이어지지 않으니 예측이 맞았는지 검증할 수 없었습니다. 운영과 회계가 이어지지 않으니 수익성을 계산할 수 없었습니다. 부서마다 기준으로 삼는 숫자가 달라 같은 회의에서 서로 다른 표를 들고 앉아 있었습니다.

그러자 일이 하나 늘었습니다. ‘이 숫자가 맞는가’를 확인하는 일입니다. 결정에 걸리는 시간의 상당 부분이 결정 자체가 아니라 숫자의 신뢰도를 맞추는 데 쓰이기 시작했습니다.

그 모든 것이 한 장면으로 모이는 자리가 있습니다. 회의실에서 누군가 묻습니다 – “그래서 이 프로젝트, 실제로 수익이 납니까?” 매출은 영업 쪽에, 원가는 엑셀에, 고정비는 연말에 배분되는 구조에서 그 자리의 누구도 확실한 숫자로 답하지 못합니다. 답 대신 잠깐의 침묵이 있습니다.

저는 이 침묵이 프로젝트가 풀어야 할 문제를 가장 정확하게 말해준다고 생각합니다. 이 회사의 수익성은 계산이 아니라 추정이었던 것입니다.

저희는 이 회사와 DDA(Digital Discovery Assessment)부터 시작했습니다. 여러 관점의 논의가 있었지만 요약하면 결론은 한 줄이었습니다. 필요한 것은 또 하나의 시스템이 아니라 연결이다 – 계획이 실적으로 이어지고, 실적이 재무로 연결되는 하나의 데이터 구조.

그래서 접근이 달랐습니다. 이 회사가 몇 년에 걸쳐 만들어 둔 것은 시스템이기 이전에 체계였습니다. 어떤 기준으로 수요를 읽고, 어떤 원칙으로 물량을 배정하고, 장납기 리드타임을 어떻게 잡는가 – 그것은 코드가 아니라 판단의 축적이었습니다.

시스템 자체는 교체했습니다. 계획도 SAP 안에서 MPS(Master Production Scheduling, 기준생산계획)와 MRP(Material Requirements Planning, 자재소요계획) 체계로 다시 세웠습니다. 표준 엔진을 쓴다는 것은 그 회사의 방식을 버린다는 뜻으로 오해되곤 하는데, 실제로 한 일은 반대였습니다. 자체 로직 안에 묻혀 있던 판단의 기준을 꺼내어 계획 파라미터와 기준정보로 옮긴 것입니다. 무엇이 진짜 원칙이고 무엇이 그동안의 임시방편이었는지를 가려내는 작업이기도 했습니다.

표준은 제약이 아니라, 미래의 선택지를 지키는 설계입니다. 엔진을 직접 만들면 그 엔진을 평생 직접 고쳐야 합니다. 표준 위에 원칙을 얹으면, 다음 버전이 올 때 원칙은 그대로 둔 채 엔진만 좋아집니다. 산업 특성상 표준이 닿지 않는 외주 생산 영역은 EPSM과 일부 자체 개발로 보완했지만, 계획의 뼈대는 표준 그대로 두었습니다.

기준이 될 모델로는 SAP S/4HANA Private Cloud의 글로벌 하이테크 제조 Best Practice와, 저희가 가지고 있던 팹리스 경영관리 체계(InnoBlock)를 함께 놓았습니다. 그래서 이 프로젝트에서 저희가 쓴 말은 ‘도입’이 아니라 ‘확장’이었습니다. 확장된 것은 시스템이 아니라 경영관리 체계입니다. 계획에서 멈춰 있던 체계가 실행과 회계와 수익성 판단까지 닿는 범위로 넓어진 것입니다.

빠르게 성장할수록 기본기가 더 중요해집니다. 그리고 좋은 설계는 오늘의 문제를 해결하는 것만이 아니라, 내일의 선택지를 남겨두는 일입니다.

다음 편에서는 실행 이야기를 합니다. 12주에서 20주를 넘는 장납기 공급망 위에서, 외주 생산의 실적이 처음으로 손에 잡히기 시작한 이야기입니다.

우리 회사의 숫자는 계산입니까, 추정입니까. → ERP 도입 진단