제조기업의 미래를 위한 PLM 이야기 (10)   2023년 2월부터 10회에 걸쳐 ‘제조기업의 미래를 위한 PLM 이야기’를 공유하였다. PLM의 기능적인 부분보다는 토털 비즈니스 솔루션으로서 PLM의 역할과 가야 할 방향에 대해서 이야기하였다. 이번 호에서는 연재 마지막 회로 실제 PLM의 구축 과정에서 겪는 어려움과 PLM 담당자가 준비해야 할 사항에 대해서 정리함으로써, 성공적인 PLM 구축에 도움이 되고자 한다.  PLM을 한 번이라도 준비해 보신 분들은 아시겠지만, 초기 PLM 기획 단계부터 솔루션 선정, 업체 선정, P&I 설계, 구축, 운영까지 하나의 단계도 쉽게 넘어가지 않는다. 관련자들의 무관심으로 시작해서 결과물이 도출될 때, 뒷북(?)까지 하나도 쉽게 넘어가는 단계가 없다. PLM 컨설팅&수행 PM으로 경험했던 바를 중심으로 성공적인 PLM 구축을 위해 필자가 체득한 경험을 공유하고자 한다.    ■ 연재순서 제1회 변화하는 시대 그리고 PLM의 변화 제2회 기업의 경영 의사결정에 도움이 되는 PLM 제3회 마케팅 요소와 제품 정보를 관리할 수 있는 PLM 제4회 상품 기획과 PLM  제5회 인재 관리를 강화할 수 있는 PLM 제6회 Agile Organization으로의 변화와 PLM 제7회 위기의 시대와 PLM 제8회 PLM과 변화 관리 제9회 클라우드 기반의 아키텍처를 고려한 PLM 시스템 제10회 PLM 시스템 구축의 긴 여정   ■ 김성희 VCIS의 대표이자 PLM 컨설턴트이다. 다양한 PLM 솔루션 및 자동차/기계/반도체/CPG 등 산업군의 PLM 컨설팅을 수행했다. 이메일 | pass829@naver.com 블로그 | https://blog.naver.com/pass829   PLM 구축 목표를 설정하라 모든 일의 성공을 위해서는 목적을 명확히 해야 한다. PLM 프로젝트 역시 마찬가지이다. 아이러니하게도 PLM 프로젝트를 하면서 PLM 구축의 목적이 구체화되지 않은 상태에서 진행되는 경우를 많이 봤다. PLM 프로젝트를 통해서 구체적으로 얻고자 하는 바에 대해서, 구축 담당자와 조직의 구성원들은 명확하게 목표를 인지하고 프로젝트를 진행해야만 성공할 수 있다.   PLM 시스템의 목적 확인 PLM 프로젝트를 진행하는 목적을 명확히 해야 한다. 예를 들어, 도면 관리의 전산화를 목적으로 PLM을 구축한다고 하면 최종 단계의 목표를 정확하게 세워놓고 PLM 프로젝트를 진행해야 한다. 단순 기능이 아닌 시스템의 목표(예 : 조직 내/외부 인원의 자료 공유)를 먼저 수립한 후 단위 기능으로 접근해야 한다.   구축 전 PLM 구축을 위한 PI를 진행하라 PLM 프로젝트의 목적이 명확하게 세워진다면 세부 계획을 수립해야 한다. 이 때, 구축업체의 관계자들에게 도움을 많이 받는다. 유감스럽게 이 부분이 전체 PLM 프로젝트의 성공과 실패에 가장 큰 영향을 준다고 생각한다. 구축업체의 명확한 니즈를 기반으로 프로젝트의 범위를 정의하고 실제 구현할 프로젝트의 기능적인 범위까지 산정해야 하나, 현실은 그렇지 못한 것이 사실이다. 또한, 업체의 PLM 담당자가 많은 준비를 하지만, PLM 전문가가 아닌 이상 세부적인 상황에 대한 경험이 없는 상태에서는 쉽지 않은 일이다. 전체 PLM 구축 비용에 일부만이라도 PLM 구축을 위한 PI 등에 투자를 하는 것이 전체 PLM 프로젝트의 성공을 위해서는 효율적이라고 생각한다.   토털 비즈니스 솔루션으로 PLM을 구축하라 PLM은 더 이상 R&D 기술 자료의 관리가 목적이 되어서는 안 된다. PLM을 통한 조직의 경쟁력을 높일 수 있는 토털 비즈니스 솔루션(total business solution)의 역할이 강화되어야 한다. 제품 기획, 제품의 마케팅 계획 수립, R&D의 인재 관리 등 역할을 수행할 수 있는 시스템이 되어야 한다. PLM을 사용하는 사용자들에게 좀 더 넓은 시각을 제공해줄 수 있는 시스템 즉, 경영적인 마인드를 - R&D의 인원도 설계만 해서는 기업의 경쟁력을 유지할 수 없다. - 할 수 있는 역할을 포함해야 함을 말하는 것이다. 앞으로 변화하는 시대에 대응하기 위해서라도 반드시 필요하다고 생각한다.    PLM은 단기 프로젝트가 아니다 PLM 프로젝트는 단기간에 끝나지 않는다. 일반적인 경우 1단계 데이터 축적, 2단계 기능 고도화, 3단계 PLM 확장의 단계 등 지속적으로 프로젝트가 연속되는 것이 일반적이다. 각 단계별로 수행해야 할 구체화된 항목과 투자 비용, 관계자들의 설득(?) 등이 필요하다. 일관성 있게 지속적으로 추진해야 한다. 그러기 위해서는 PLM 구축 담당자가 준비해야 할 항목이 많다. 그리고 담당자도 많은 에너지를 필요로 한다.(일이 늘 해피하게 진행되지는 않는다.)     ■ 자세한 기사 내용은 PDF로 제공됩니다.

제조기업의 미래를 위한 PLM 이야기 (9)   이제는 클라우드 시스템은 누구나 알게 되었다. 많은 서비스는 점점 더 클라우드 기반으로 변화하고 있으며, PLM 공급사의 움직임도 일관되게 진행되고 있다. SCM, ERP, CRM 등의 시스템은 클라우드로의 비중 확대가 가속화되고 있는 듯(?)하다. PLM은 어떤가? 타 시스템에 비해서 상대적으로 클라우드로의 변화가 느리다. 왜 그런지, 그리고 클라우드 PLM은 모든 문제가 다 해결되었는지에 대해서 이야기해보려 한다. 이번 호에서는 클라우드 시스템의 유형, 클라우드 시스템의 문제점(클라우드 PLM 공급사의 문제점을 말하려는 것은 아니다. 일반적인 클라우드 시스템의 문제점을 이야기하는 것이다.), 클라우드 PLM으로의 변화에 대한 준비, 클라우드 PLM의 목표 등을 이야기해보려 한다.   ■ 연재순서 제1회 변화하는 시대 그리고 PLM의 변화 제2회 기업의 경영 의사결정에 도움이 되는 PLM 제3회 마케팅 요소와 제품 정보를 관리할 수 있는 PLM 제4회 상품 기획과 PLM 제5회 인재 관리를 강화할 수 있는 PLM 제6회 Agile Organization으로의 변화와 PLM 제7회 위기의 시대와 PLM 제8회 PLM과 변화 관리 제9회 클라우드 기반의 아키텍처를 고려한 PLM 시스템 제10회 PLM 시스템 구축의 긴 여정   ■ 김성희 VCIS의 대표이자 PLM 컨설턴트이다. 다양한 PLM 솔루션 및 자동차/기계/반도체/CPG 등 산업군의 PLM 컨설팅을 수행했다. 이메일 | pass829@naver.com 블로그 | https://blog.naver.com/pass829   클라우드 시스템의 유형 클라우드 컴퓨팅은 세 가지 주요 유형으로 구성된다. Infrastructure as a Service(IaaS) : 클라우드 서비스 업체에게서 공간을 대여하여, 그 공간을 활용하는 방법 Platform as a Service(PaaS) : 클라우드 서비스 업체가 공간과 프로그램까지 관리해 주는 방법(소프트웨어 유지, 패치 등 일반 작업 지원) Software as a Service(SaaS) : 클라우드 서비스 업체가 제공하는 프로그램을 사용하는 방법. 일반적으로 클라우드라고 하면 SaaS 방식을 말한다.(완성된 프로그램을 이용하고, 그 비용을 지불하면 된다.)   클라우드 시스템의 문제점 클라우드 시스템의 일반적인 문제점이다. PLM 공급사에서 제공하는 서비스를 말하는 것이 아님을 다시 한 번 밝힌다. 이 부분은 시간이 지나면 어느 정도 해결이 될 수 있다고 본다.(그 시간이 문제지만…)   레거시 시스템과의 연계 클라우드 시스템의 유형 중 SaaS 방식을 사용하는 고객들이 겪는 어려움이다. 기존의 레거시(legacy) 시스템과의 연계가 어렵다. 이를 해결하기 위해 REST API 등을 제공하고 있지만, 한계는 명확한 것 같다. 다양한 환경의 레거시 시스템을 연계하기 위해서는 아직은 시간이 필요한 것 같다.   보안 이슈 이 부분은 크게 언급하고 싶진 않다. 초기 클라우드 시스템이 시장에 나왔을 때 고객들이 가진 심리적인 불안감이라고 본다. 오히려, 메이저 클라우드 시스템 업체의 보안 수준은 일반 기업의 보안 솔루션을 넘어서고 있는 것이 현실이다.   커스텀화의 부재 클라우드 시스템의 유형 중 SaaS 방식의 한계점이다. 고객들의 오랜 기간 동안 최적화된 자신만의 프로세스를 커스텀화(customization)할 수 없는 것은 아쉬운 부분이다. 노코드(no code), 로코드(low code) 방식의 솔루션과 연계 등을 제공하고 있지만 아직은 시간이 필요해 보인다.   속도 이슈 어떤 조직에서 클라우드 시스템을 구축한다고 하면, 그 목적은 어느 곳에서도 편리한 접근성을 확보하기 위한 것이다. 클라우드 서비스 업체의 문제라기보다는 고객사의 내부 네트워크 망을 먼저 확인해봤으면 한다. 과연 클라우드 서비스의 효율성을 극대화할 수 있는지에 대한 내부 검증을 말이다.   관리적인 측면 클라우드 서비스 업체에서 내세우는 여러 가지 장점 중 하나가 비용이다. 초기 투자 비용의 감소를 말하는데, 이 부분은 맞는 말이다. 도입하려는 시스템의 5년 동안 가동률을 감안하면, 총 비용적인 측면에서 경험적으로는 클라우드 서비스가 비용이 더 비싼 것이 현실이다.(물론 여기에 따른 여러 가지 관리 비용, 업그레이드 비용 등을 고려하면 달라질 수 있지만…)   공급사의 신뢰 이 항목은 온프레미스(on premise)라고 달라질 부분은 아니다. 하지만, 클라우드 서비스의 신뢰도는 초기 클라우드 서비스를 도입할 때 중요하게 확인해야 할 항목 중 하나임에는 틀림없다.(큰 회사라고 무조건 안정적이고 좋지는 않다. 시장의 평가를 확인하고 신중하게 결정하는 것이 필요하다.)   데이터의 잠김 데이터의 백업과 복원에 대한 대비책이 얼마나 잘 되어 있는지를 확인해야 한다. 데이터의 중요성은 갈 수록 중요해지고 있다. 그런데, 클라우드 업체의 사정 또는 고객사 내부 사정에 의해서 다른 환경으로 이전이 필요할 때, 데이터의 이관에 어려움이 있다면 머리가 아플 것이다. 여러 가지 문제점이 많지만, 이중 PLM과 가장 밀접한 연관이 있는 부분은 레거시 시스템과의 연계 부분이라고 생각한다. PLM의 특성상 프로세스를 시스템화한 부분이 대부분이라서, 여러 시스템과의 연계가 중요하다. 온프레미스의 경우 시스템 인터페이스를 별도의 구축 항목으로 RFP로 요청한다. 클라우드 서비스(SaaS)에서 아직 이 부분에 대한 명확한 솔루션은 나오지 않았다.    ■ 자세한 기사 내용은 PDF로 제공됩니다.