스마트공장 도입이 실패하는 5가지 구조적 이유

스마트공장을 구축한 회사에서 가장 많이 듣는 말이 있습니다.

"시스템은 넣었는데, 뭐가 좋아졌는지 모르겠습니다."

이 말이 나오면 대개 솔루션 탓을 하게 됩니다. 제품이 부실했다거나, 공급업체가 성의가 없었다거나. 그런 경우도 있습니다. 그런데 제가 현장에서 본 실패는 대부분 특정 제품이나 특정 담당자의 문제가 아니었습니다. 같은 형태의 실패가 회사를 바꿔가며 반복됐습니다.

반복된다는 건 구조가 있다는 뜻입니다. 그 구조 다섯 가지를 정리했습니다.

1. 목표가 '선정'이면, 끝은 '감리'가 된다

어떻게 나타나는가

사업계획서에는 목표가 분명히 적혀 있습니다. 불량률 몇 % 감소, 생산성 몇 % 향상. 그런데 그 숫자가 어디서 나왔는지 물어보면 답이 잘 안 나옵니다. 현재 값을 모르는 상태에서 목표 값만 적힌 경우도 있습니다.

그리고 감리가 끝나는 시점에 시스템 사용도 함께 시들해집니다.

왜 구조적인가

담당자가 게을러서가 아닙니다. 회사가 실제로 원한 것이 거기까지였기 때문입니다.

목표가 "지원사업에 선정되는 것"으로 설정되면, 선정된 순간 목표는 이미 달성됩니다. 그다음부터 구축은 '해야 하는 절차'가 되고, 감리 통과가 자연스러운 종점이 됩니다. 누구도 잘못한 사람은 없는데 결과적으로 아무것도 남지 않습니다.

지원사업 자체는 활용할 가치가 충분한 제도입니다. 문제는 제도를 목표로 삼았을 때 생깁니다.

무엇을 하면 막을 수 있는가

• 공고와 무관하게, 회사가 해결하고 싶은 문제를 먼저 문장으로 적어둡니다
• 목표 지표는 현재 값을 측정한 뒤에 정합니다. 현재 값을 모르면 목표도 의미가 없습니다
• 구축 완료일이 아니라 구축 6개월 후에 무엇이 달라져 있어야 하는지를 계획서에 함께 적습니다

2. 정리되지 않은 것을 그대로 전산화한다

어떻게 나타나는가

같은 부품을 A반장은 "브라켓", B반장은 "고정판", 도면에는 다른 코드로 부릅니다. 공정 순서도 작업자마다 조금씩 다릅니다. 오래된 공장일수록 이런 상태가 자연스럽습니다. 사람이 알아서 맞춰왔기 때문입니다.

여기에 시스템을 얹으면, 시스템은 그 차이를 알아서 맞춰주지 않습니다.

왜 구조적인가

전산화는 현재 프로세스를 고정하는 작업입니다. 정리되지 않은 상태를 전산화하면 그 혼란이 코드로 굳어집니다. 사람이 하던 시절에는 융통성으로 넘어가던 것이 시스템에서는 오류가 됩니다.

특히 품목코드, BOM, 공정코드, 거래처코드 네 가지가 정리되지 않으면 이후 모든 데이터가 어긋납니다. 재고가 안 맞고, 원가가 안 맞고, 실적 집계가 안 맞습니다. 그러면 현장은 "시스템이 틀렸다"고 판단하고 다시 엑셀로 돌아갑니다.

무엇을 하면 막을 수 있는가

• 솔루션을 고르기 전에 코드 체계부터 정리합니다. 이건 예산 없이 지금 시작할 수 있는 일입니다
• 표준화가 어려운 공정은 시스템에 넣지 않고 일단 남겨둡니다. 전부 넣으려다 전부 못 씁니다
• "현재 이렇게 하고 있다"를 먼저 그리고, "이렇게 바꾼다"를 정한 뒤에 시스템을 설계합니다

3. 현장이 빠진 채 설계된다

어떻게 나타나는가

요구사항 정의서를 사무실에서 작성합니다. 생산관리 담당자와 전산 담당자, 그리고 공급업체가 회의실에 모입니다. 정작 매일 그 화면을 만질 작업자와 반장은 참석하지 않습니다.

오픈 후에 이런 말이 나옵니다. "이거 누르려면 장갑을 벗어야 하는데요."

왜 구조적인가

현장 인력은 라인을 세우고 회의에 들어올 수 없습니다. 시간을 내기 어려운 구조입니다. 그래서 선의로 배제됩니다. 누가 막은 것이 아니라 일정상 그렇게 됩니다.

그 결과 시스템은 관리자가 보고 싶은 것 중심으로 설계됩니다. 관리자에게는 완벽한데 입력하는 사람에게는 불편한 시스템이 만들어집니다. 그리고 입력이 부실해지면 관리자가 보고 싶던 그 데이터도 결국 못 봅니다.

무엇을 하면 막을 수 있는가

• 요구사항 회의에 반장급 한 명은 반드시 넣습니다. 한 명이면 충분합니다
• 입력 화면은 작업 한 건당 터치 수로 검증합니다. 숫자로 보면 논쟁이 끝납니다
• 오픈 전에 실제 작업 환경에서 시연합니다. 회의실이 아니라 라인 옆에서요

스마트공장 도입 실패의 다섯 단계

4. 회사가 감당할 수 없는 시스템을 만든다

어떻게 나타나는가

구축 과정에서 요구사항이 계속 늘어납니다. "이것도 되면 좋겠다"가 쌓입니다. 공급업체는 대체로 받아줍니다. 결과적으로 그 회사만을 위한 시스템이 만들어집니다.

그리고 몇 달 뒤, 그 시스템을 아는 사람이 한 명뿐이라는 사실을 알게 됩니다.

왜 구조적인가

커스터마이징과 운영 리스크는 붙어 다닙니다. 맞춤 기능이 많을수록 그 구조를 이해하는 사람의 범위가 좁아집니다. 표준 기능이면 매뉴얼과 공급업체 지원으로 해결되지만, 맞춤 기능은 만든 사람과 담당자만 압니다.

중소 제조업체에서 그 담당자는 대개 한 명입니다. 그 한 명이 퇴사하면 시스템은 살아 있어도 아무도 손대지 못하는 상태가 됩니다. 기능이 많아서 실패한 것이 아니라, 기능이 운영 인력을 초과해서 실패한 것입니다.

무엇을 하면 막을 수 있는가

• 요구사항이 늘어날 때마다 "이걸 누가 유지할 것인가"를 함께 묻습니다
• 표준 기능으로 80% 해결된다면 나머지 20%는 업무 방식을 바꾸는 쪽을 먼저 검토합니다
• 담당자가 한 명이라면, 그 한 명이 문서를 남기게 하는 것을 계약 조건에 넣습니다

5. 쌓기만 하고 보지 않는다

어떻게 나타나는가

데이터는 잘 쌓이고 있습니다. 대시보드도 있고 그래프도 나옵니다. 그런데 그 화면을 매일 여는 사람이 없습니다.

물어보면 이렇게 답합니다. "보긴 보는데, 보고 나서 뭘 해야 할지를 모르겠어요."

왜 구조적인가

데이터는 그 자체로 아무것도 바꾸지 않습니다. 측정 → 판단 → 조치가 한 바퀴 돌아야 개선이 일어납니다.

그런데 대부분의 구축 프로젝트는 '측정'까지만 범위에 포함합니다. 어떤 값이 어떻게 되면 무엇을 할 것인지, 누가 그 판단을 하는지는 계약서에 없습니다. 그래서 시스템은 정상 작동하는데 아무것도 변하지 않는 상태가 됩니다.

이것이 "뭐가 좋아졌는지 모르겠다"의 정체입니다. 시스템이 실패한 것이 아니라 루프가 닫히지 않은 것입니다.

측정 판단 조치 루프가 끊긴 구조

무엇을 하면 막을 수 있는가

• 지표는 세 개 이하로 시작합니다. 열 개를 보면 아무것도 안 보입니다
• 각 지표에 기준선과 조치를 한 줄로 붙입니다. "가동률이 X 이하로 떨어지면 누가 무엇을 한다"
• 주 1회, 30분이라도 데이터를 놓고 이야기하는 자리를 만듭니다. 이 자리가 없으면 대시보드는 장식입니다

정리하면

다섯 가지를 다시 보면 공통점이 하나 있습니다. 전부 시스템 바깥의 문제입니다.

단계	실패 구조	핵심 질문
목표	선정이 목표가 된다	6개월 후 무엇이 달라져야 하나
준비	정리 없이 전산화한다	코드 체계는 정리됐나
설계	현장이 빠진다	매일 쓸 사람이 회의에 있었나
규모	감당 범위를 넘는다	이걸 누가 유지하나
운영	루프가 닫히지 않는다	보고 나서 무엇을 하나

솔루션을 고르는 데 쓰는 시간의 절반만 이 다섯 가지에 써도 결과는 꽤 달라집니다. 그리고 이 중 상당수는 예산이 확정되기 전에, 비용 없이 시작할 수 있는 일입니다.

 

다음 글에서는 우리 공장이 지금 어느 수준인지 스스로 점검할 수 있는 체크리스트를 정리하겠습니다.