엔지니어를 위한 Costdown

엔지니어는 어떤 공정의 사이클타임을 줄이기 위해 몇 주에 걸쳐 시행착오를 겪습니다 — 측정하고, 분석하고, 재료를 시험하고, 지그를 조정하고, 품질을 확인하고, 절감액을 다시 계산합니다. 그러려면 기계, 재료, 실제 운영 조건을 제대로 이해해야 하며, 한나절 만에 끝낼 수 있는 일이 아닙니다. 결과는 한 번의 회의에서 발표되고, 사내 보고서에 기록된 뒤, 기술 부서의 공유 드라이브 안에 잠들어 있습니다. 여섯 달 뒤, 정확히 무엇을 했는지 질문을 받으면 보고서를 쓴 본인조차 파일을 다시 뒤져야 정확히 기억해냅니다. 당신이 해결한 것을 엑셀 파일 하나에 묻어두지 마세요 — 그것이 이 페이지가 존재하는 이유의 전부입니다.

보고서가 완성됐다고 경험이 보존된 것은 아니다

보고서는 보통 숫자를 아주 명확하게 기록합니다: 개선 전 55초, 개선 후 41초, 개당 절감액. 그것을 쓴 사람에게는 그 정보로 충분히 명확합니다. 하지만 몇 년 뒤 그것을 읽는 다른 엔지니어는 대개 숫자보다 더 중요한 부분을 모릅니다: 왜 예전 방식이 느렸는지, 지그의 어느 부분을 바꿨는지, 당시 생산 조건이 어땠는지, 그 해법이 왜 효과가 있었는지, 시험 과정에서 품질 문제가 발생하지는 않았는지, 그것을 다른 제품에도 적용할 수 있는지. 보고서는 최종 숫자는 남기지만, 그 뒤에 있는 이유는 대체로 남기지 않습니다 — 그리고 바로 그 이유 부분이야말로 다른 사람이 비슷한 방법을 시도해볼 가치가 있는지 판단하는 데 도움을 줍니다.

Costdown은 엔지니어에게 콘텐츠 작가가 되라고 요구하지 않는다

이 경계는 분명히 해둘 필요가 있습니다. 오해하기 쉬운 지점이기 때문입니다. Costdown은 엔지니어에게 긴 글을 쓰라고 요구하지 않고, 흥미롭게 쓰는 법을 알아야 한다고 요구하지 않으며, 완결된 이야기를 하라고 요구하지 않습니다. 실제로 해야 할 일은 훨씬 좁고, 그들이 원래 하던 일에 가깝습니다: 문제가 무엇이었는지, 무엇을 바꿨는지, 전후 조건은 어땠는지, 측정된 결과는 얼마인지, 그리고 적용 범위를 기록하는 것 — 좋은 기술 보고서라면 원래 갖춰야 할 바로 그 내용이며, 다른 점은 다른 사람이 다시 찾을 수 있는 구조로 기록한다는 것뿐입니다.

형식 정리와 분류를 모두 스스로 할 필요는 없다

경험을 기록하는 데 있어 진짜 걸림돌은, 엔지니어가 기술적인 작업에 이미 모든 시간을 쓰고 나면 프로젝트의 형식을 정하고, 이름을 붙이고, 분류할 시간이 남지 않는다는 것입니다. Costdown은 그 부담을 더 얹지 않습니다: 공정, 기계, 재료는 이미 표준 코드가 있어서 선택하면 되고, 스스로 표현이나 이름 붙이는 방법을 고민할 필요가 없습니다. 엔지니어가 실제로 공을 들여야 할 것은 핵심 내용 — 문제, 변경 사항, 결과 — 뿐입니다. 나머지는 이미 마련된 구조에 채워 넣기만 하면 되며, 기록할 때마다 백지 앞에 서지 않아도 됩니다.

구조를 갖춘 개선은 더 이상 한 번의 회의에만 속하지 않는다

한 엔지니어가 절삭 순서를 바꿔서 어떤 부품의 가공 시간을 줄였다고 가정해봅시다. 사내 보고서에만 적힌다면, 그 일의 가치는 그 공정, 그 공장, 그것이 이루어진 그 순간에 머무릅니다. 구조를 갖춰 기록하면 그것은 다음과 같은 것이 됩니다:

찾을 수 있게 — 다른 공장의 다른 엔지니어가 이 공정이나 재료에 관해 정확히 같은 문제를 만났을 때, 처음부터 혼자 헤매는 대신 그것을 찾을 수 있습니다.
배울 수 있게 — 문제를 해결한 방식의 구조가 명확히 보이며, 어디서 왔는지 알 수 없는 최종 결론만 있는 게 아닙니다.
응용할 수 있게 — 찾은 사람은 원본을 그대로 베끼지 않고, 자신의 기계·재료·생산 규모에 맞게 조정한 뒤 자신만의 결과를 측정합니다.
시스템으로 돌아오게 — 새로운 결과는 또 다른 사례가 되어 다음 사람을 위해 그 자리에 남고, 원래의 엔지니어는 여전히 그 출발점을 만든 사람으로 기록됩니다.

엔지니어는 주기만 하는 게 아니라 — 받기도 한다

Costdown에 경험을 기록하는 것은 엔지니어가 기여만 하고 아무것도 얻지 못하는 일방통행이 아닙니다. 한 엔지니어가 어떤 공정에서 예전에 어떻게 원가를 줄였는지 기록하는 동시에, 그들은 지금 자신이 겪고 있는 다른 문제를 누군가 어떻게 해결했는지 찾아낼 기회 앞에도 서 있습니다. 오늘 지그 개선 사례를 기여한 사람이 다음 주에는 재료 손실을 줄이는 사례를 찾아, 자신이 풀어야 할 바로 그 문제를 만나는 사람이 될 수도 있습니다. 누구도 이 순환의 한쪽에만 머물지 않습니다.

비밀을 공유하지 않아도 경험은 공유할 수 있다

엔지니어는 상세 도면, 완전한 원단위, 공급업체와 합의한 가격, 고객 정보를 밝히지 않고도 개선의 원리와 결과를 공유할 수 있습니다. "소재 배치 방식을 바꿔 재료 손실을 줄였다"라고 적는 것만으로도 다른 사람이 원리를 배우기에 충분합니다. 도면 전체나 재료 구매 계약서를 첨부할 필요는 없습니다. 공유해야 할 것은 다른 사람이 이해하고 판단하기에 충분한 지식이지, 그 뒤에 있는 모든 사내 데이터가 아닙니다.

사례는 완벽하지 않아도 가치가 있다

모든 방안이 성공하는 것은 아니며, 그렇다고 그것이 무가치해지는 것은 아닙니다. 시도했지만 기대한 결과에 이르지 못한 방안 — 특정 생산량 수준에서는 효과가 없었거나, 투자를 회수하지 못한 경우 — 도 여전히 기록할 가치가 있는 정보입니다. 그것은 비슷한 조건에서 정확히 같은 방향을 고민하고 있는 다른 엔지니어가, 다시 처음부터 시도하는 데 힘을 쓰기 전에 올바른 질문을 던지도록 도와줍니다. 경험은 "무엇이 성공했는가"만이 아니라 "무엇을 시도했고, 어떤 조건에서 효과가 없었는가"이기도 합니다.

실제로 해낸 일에 기반한 역량 기록

여러 해 일해온 엔지니어는 이미 다양한 유형의 원가 절감 프로젝트를 수십 건 거쳤을 수 있습니다 — 하지만 그것들이 각각 별개의 보고서 안에 흩어져만 있다면, 자신이 실제로 무엇을 해왔는지 전체 그림을 볼 방법이 없습니다. 각 프로젝트가 구조를 갖춰 기록되면, 그것들은 학위나 이력서에 적힌 "다년간의 제조 경험"이라는 한 줄과는 다른 무언가로 쌓입니다 — 해결한 문제와 측정한 결과의 구체적인 모음이며, 그것을 실제로 만들어낸 사람의 이름이 정확히 붙어 있는 기록입니다.

한 번의 개선, 한 번의 절감으로 끝나지 않는다

한 개선이 사내 보고서 안에만 머무를 때, 그것이 만들어내는 가치는 정확히 한 번뿐입니다 — 그것이 실행된 그때, 오직 한 공장을 위해서만. 그것이 구조화된 사례로 기록되면, 다른 누군가가 그것을 찾아 자신의 조건에 맞게 재사용할 때마다 계속해서 가치를 만들어냅니다. 힘을 쏟은 그 엔지니어에게는, 그것이 "끝난 일"과 "여전히 자신의 것으로 남아 있는 무언가"의 차이입니다 — 다른 누군가가 그것을 이용해 새로운 결과를 만들어낼 때마다, 자신은 여전히 그 출발점으로 기록됩니다.