엔지니어링 팀이 우리가 기대하는 속도로 움직이려면, 그들의 업무에 영향을 주는 사람, 제품 데이터, 프로세스가 완전히 정렬된 상태를 유지해야 합니다.
모든 설계 변경은 선행 및 후속 팀 전반에 파급 효과를 일으키며, 모두가 동일한 정보를 기반으로 작업하도록 유지하기를 더 어렵게 만듭니다.
바로 이 지점에서 제품 수명주기 관리(PLM)가 필요합니다. 최신 PLM software는 아이디어 단계부터 생산까지 제품 정보를 관리합니다.
PLM은 버전 혼선, BOM 불일치, 문서화되지 않은 변경, 수작업 인계로 인해 발생하는 오류를 방지하는 데 도움을 줍니다.
그렇다면 실제로 일상 업무에서 엔지니어링 팀이 더 빠르게 움직이도록 어떻게 도와줄까요?
제품이 점점 더 복잡해지고 팀이 여러 지역에 분산되는 경우가 많아지면서, 엔지니어들은 정보를 찾고, 의사결정을 검증하고, 자신이 올바른 리비전을 기준으로 작업하고 있는지 확인하는 데 더 많은 시간을 쓰게 됩니다.
엔지니어링 팀은 정기적으로 다음과 같은 질문에 대해 실시간 답변이 필요합니다:
이런 질문에 답하느라 엔지니어링 업무가 중단되어서는 안 됩니다. 정보를 찾기 어려우면 팀은 재작업, 수동 확인, 불필요한 반복 커뮤니케이션에 시간을 빼앗기게 됩니다.
오늘날의 PLM tools는 엔지니어가 필요한 정보에 쉽게 접근할 수 있게 해주므로, 검색에 쓰는 시간은 줄이고 설계에 더 많은 시간을 쓸 수 있게 합니다.
신뢰할 수 있는 제품 기록은 제품 개발 전반에 걸쳐 엔지니어링, 구매, 제조 부서에 단일한 진실의 원천(single source of truth)을 제공합니다. 이를 통해 모든 팀은 자신이 올바른 리비전을 기준으로 작업하고 있다는 확신을 가질 수 있습니다.
연구에 따르면 PLM 사용자의 85%는 이러한 systems help them 정보 검색을 더 쉽게 해준다고 답했으며, 거의 75%는 데이터 정확성이 높아졌다고 보고했고, 3분의 2 이상은 설계 정보에 더 시의적절하게 접근할 수 있다고 말했습니다.
하나의 신뢰할 수 있는 제품 기록이 있으면 엔지니어링은 자신 있게 설계를 릴리스할 수 있고, 구매 부서는 승인된 부품과 대체품을 검토할 수 있으며, 제조 부서는 올바른 리비전을 기준으로 생산할 수 있고, 경영진은 상태 회의에 의존하지 않고도 진행 상황을 추적할 수 있습니다.
엔지니어링 변경은 드물게 단 하나의 컴포넌트에만 영향을 미칩니다. 조립품, 공급업체, 도면, 테스트 계획, 제조 공정, 규정 준수 문서까지 영향을 받을 수 있습니다.
PLM이 없으면 이러한 영향은 대개 이메일 스레드, 채팅 메시지, 공유 스프레드시트, 비공식적인 지식에 의존해 관리됩니다. 제품, 팀, 공급망이 커질수록 이러한 변경을 수작업으로 관리하는 일은 훨씬 더 어려워집니다.
오늘날의 변경 관리는 훨씬 더 “GitHub-inspired” 방식이어야 합니다. 즉, 부품, 도면, BOM의 리비전을 추적하고, 누가 무엇을 왜 변경했는지 확인하며, ECO를 승인 워크플로로 라우팅하고, 검토자에게 알림을 보내고, 누락된 데이터 때문에 반려되는 변경 주문 수를 줄일 수 있어야 합니다.
변경 주문이 완전하고, 가시적이며, routed automatically 되면 팀은 승인 추적에 쓰는 시간을 줄이고 엔지니어링 문제 해결에 더 많은 시간을 쓸 수 있습니다.
Octopart 사용자에게 이것은 PLM의 가장 중요한 속도 이점 중 하나입니다: it helps engineering and sourcing collaborate before component choices become expensive to change.
예를 들어, 워크플로에 Duro PLM을 통합하면 엔지니어링 팀은 Duro의 Octopart API 액세스를 활용해 save hours of time manually copy/pasting component data할 수 있습니다.
그 다음 컴포넌트가 추가되면, 가격 데이터(및 기타 모든 데이터)를 PLM 내부에서 직접 새로 고쳐 팀이 최신의 정확한 정보를 유지할 수 있습니다. 또한 수동 가격 확인에 드는 시간을 수시간 절약할 수 있어, 비용이 감당하기 어려워지거나 더 나쁘게는 수급이 불가능해질 경우 팀이 다른 컴포넌트로 전환할지 판단하는 데 더 많은 시간을 확보할 수 있습니다.
이것이 Octopart 사용자에게 PLM이 제공하는 ROI입니다. 부품을 구할 수 없거나, 단종되었거나, 너무 비싸거나, 소싱이 어렵다면 제품 출시는 어려워질 수 있습니다. 소싱 검토가 설계가 거의 완료된 후에 이뤄지면 팀은 일정 지연이나 압박 속 재설계로 이어지는 후반 단계의 트레이드오프를 강요받게 됩니다. PLM은 팀이 출시까지의 시간을 줄이는 의사결정을 내릴 수 있도록 훨씬 더 이른 시점에 필요한 데이터를 확보하도록 설계되었습니다. 엔지니어는 설계 맥락 안에서 공급업체, 수명주기, 비용, 가용성, 대체 부품 데이터를 확인할 수 있습니다.
더 빠른 제품 개발을 가로막는 가장 큰 장벽 중 하나는 순차적인 인계입니다. 엔지니어링이 설계를 마치고 소싱으로 넘기면, 소싱이 문제를 발견한 뒤 다시 되돌려보내는 식입니다.
PLM allows cross-functional teams to review designs and contribute earlier in the development process.
제조팀은 릴리스 전에 설계를 검토할 수 있고, 구매 부서는 BOM이 아직 발전하는 동안 위험한 부품을 표시할 수 있으며, 품질 부서는 릴리스 패키지가 완성되기 전에 요구사항을 검증할 수 있습니다.
이 점은 특히 분산된 팀에서 중요합니다. PLM은 이들에게 공유 제품 기록을 제공하므로, 지속적인 회의나 수동 상태 업데이트에 의존하지 않고도 개발을 계속할 수 있습니다.
수년간 유지되는 하드웨어 제품에는 제품의 기억이 필요합니다. 특히 엔지니어가 떠나고, 공급업체가 바뀌고, 컴포넌트가 단종될 때 더욱 그렇습니다.
의사결정의 맥락이 누군가의 기억, 오래된 이메일 스레드, 또는 local spreadsheet에 저장되어 있으면 팀은 결국 설계의 근거를 잃게 됩니다.
PLM은 “무엇을”과 함께 “왜”를 보존하는 데 도움을 줍니다. 좋은 제품 기록은 다음 질문에 답할 수 있어야 합니다: