실패를 설계하고, 실행하지 않으면서 성공을 바란다
이 길이 아니야, 돌아
모듈러 아키텍처, 모듈러 디자인 활동을 실행할 때 가장 많이 듣는 불평은 다음과 같습니다.
예전과 달라진 게 없다.
지금까지 효과가 없다.
달라진 게 없다는 불평은 플랫폼에서 모듈러 디자인 체계로 전환하면 공용화가 더 잘할 수 있다고 하는데, 변한 게 없다는 의견입니다.
그런데, 플랫폼에서 모듈러 디자인 체계로 그냥 바꿔두면 공용화가 저절로 잘 될까요? “전사 중장기 계획을 세워두니까, 효과가 없는 것 같다.” “분야별로 중장기 계획을 세우고 취합을 해보자.”
여기서 분야별 중장기 계획을 그냥 주먹구구식으로 만드나요? 전사에 정렬되게, 전사 중장기 목표에 이를 수 있도록 자신의 분야에서 최적화하여 수립하겠죠.
공용화를 더욱 잘하고 싶어서 모듈러 디자인 체계로 전환했다면, 현재 제품군 아키텍처가 공용화를 더욱 잘할 수 있도록 설계가 된 건지 확인해 봐야 합니다. 플랫폼을 모듈로 쪼개놓았는데, 사실은 통합된 플랫폼이 아니라 예전처럼 플랫폼을 세그먼트 별로 따로따로 운영하는 건 아닌지, 모듈로 쪼개놓았지만 그것들을 공용화할 생각은 사전에 해놓지 않은 건지, 공용화하기 위한 현황 분석은 제대로 해놓은 건 맞는지 먼저 확인해 봐야 합니다.
여기서 하나라도 제대로 대답을 못한다면, 사실 포장지만 모듈러 디자인하겠다고 해놓고, 이전 체계와 다를 게 하나도 없는 상황인 겁니다.
두 번째, 효과가 없다는 의견은 앞서 제대로 설계를 해놓았다는 가정에서 효과가 없다고 말하는 건 제대로 실행을 한 건 맞는지 확인해 봐야 합니다. 설계를 해놓았다는 건 계획만 세워두었다는 걸 의미합니다. “난 내년까지 1억을 모을 거야” 다짐을 해놓고, 버는 족족 써버리면 그게 이뤄질 수 있을까요? 멋있게 밑그림을 그려놓았다면 치열하게 지키려고 실행을 해야겠죠.
지금이라도 확인해 봅시다.
제대로 설계한 게 맞나요? 대상 제품군에 대한 Variety Mechanism를 설명할 수 있어야 합니다.
치열하게 실행하고 있나요? Variety 분석 결과와 Variety 관리 계획이 있어야 합니다.
