将
系统工程(SE)和产品生命周期管理(PLM)的最佳技术结合起来,将为制造企业的持续改进和数字化转型奠定基础。
为了生产智能、互联的产品,工程团队必须采取系统方法,来管理整个产品生命周期中的信息和流程。问题是,大多数工程师都局限在两个学科中的一个——系统工程(SE)或产品生命周期管理(PLM)。
虽然系统工程和产品生命周期管理都可以管理复杂的产品,但也有明显的差异。这两个历史悠久的学科如果结合起来,就会创造出生产下一代复杂产品所需的方法。然而,重新规划工程组织如何管理产品开发并不是一件容易的事。
“随着系统工程和PLM 团队的协作,
要学会规划变革,
选择具有开放API 和灵活架构的工具,
使组织能够轻松适应变化。”
实现系统级的方法
如今的产品,多个系统相互嵌套,同一个设计中可能包含电气、机械和软件等多个层次。为了管理相互依赖的多个学科,工程团队必须使用系统级的方法。系统工程和PLM 作为系统级学科,具有相对优势——就像同一枚硬币的两面,目标是按时、在预算内( 或低于预算),交付优质产品。每个学科如何实现这个目标各不相同,但理解这些至关重要。
系统工程的起源,最早可追溯到用笔和打字机在纸上设计的时代。它始于航空航天和国防工业,企业花费数月甚至数年的时间,开发出一种满足客户需求的产品。无论是过去还是现在,这类客户仍然主要是政府机构,需要精确地满足客户要求。系统工程师的任务是获取这些要求,以及在生命周期中其它利益相关者的需求,并将其转换为系统模型,以指导开发最终产品或系统所包含的软件或硬件。
另一方面, PLM 在生命周期的后期出现,着力于物理设计、计算机辅助设计(CAD) 模型和物料清单(BOM) 上。PLM 的基本元件是零件、子组件或装配结构。起初它们主要由系统工程师来定义。
尽管这两种方法都使用相同的信息,并且相互补充,但是它们的起源和重点各不相同。局限在系统工程方法中的工程领域的领导,可能并不愿意为PLM 费心;同样,在PLM 工作的机械工程团队的领导,也不想把一天的时间都花在管理需求上。他们都选择集成方法的原因是这个行业正在发生变化。为了跟上竞争的需要,这两个团队也需要这样做。
工程组织的协作
计算机程序员MelvinConway 在1968 年就指出,系统设计的结构必定复制设计该系统的组织的沟通结构。这一理论后来被称为“康威定律”,意味着产品将反映构建产品工程团队的组织结构。如果系统工程和PLM 组单独工作,这可能会出问题。
当系统工程和PLM 团队独立工作时出现的挑战源于文化和技术的不一致。他们已经规范了他们的做事方式,并期望对方适应并效仿。除了彼此独立之外,其它部门甚至同一公司的工程职能部门( 例如软件团队),也会因为自说自话导致沟通困难。独立的信息系统也使这一过程变得更加困难。
系统工程和PLM 团队正在开发相同的产品,但由于所用的开发工具以及数据处在不同的数据库,共享信息并不容易。因此,在生命周期中,团队和下游之间的数据处理和切换过程,非常容易出错。康威认为,这些错误将出现在最终产品中。一个完全集成的系统概念——在产品生命周期中,每条产品信息都是相互连接和一致的——就是个神话。然而,这并不意味着不可能实现整体产品的开发。
面向未来的工程组织
面向未来的工程组织,听起来可能像是一项艰巨的任务。尤其是在今天,团队正忙于应对日益复杂的产品、法规和激烈的全球竞争。实现这一愿景的第一步,是创建系统工程和PLM 合作的环境。要做到这一点,工程领导应该考虑:
联合系统工程和PLM 团队——在概述了他们的共同目标“随着系统工程和PLM 团队的协作,要学会规划变革,选择具有开放API 和灵活架构的工具,使组织能够轻松适应变化。”和集成开发方法的好处后,整合系统工程和PLM 团队将取决于跨学科的沟通。如果组织中还不存在类似的沟通论坛,那就创建一个。如果已经存在,那就鼓励人们使用。
为这两个学科创建包容性流程——摆脱" 自我为中心" 的信仰体系,设计新的流程,将每个学科的各个部分连接起来。通过保留一些有利于其它团队的最佳实践来满足每个团队的需求。
将信息连接并集成到工程中的单一可信来源中——系统级设计需要系统级平台。多供应商解决方案将具有管理开发过程每个阶段所需的广度。超越文档、PDF 和电子表格的界限非常重要。
规划变革——保持灵活性,选择具有开放应用程序接口(API)和灵活架构的工具,使组织能够轻松适应变化。在当今的数字时代,今日之最佳实践,未必使用于明日。
咨询外部合作方——集成方法还需要考虑客户、供应商和工程过程中其它参与者的需求。联合供应链上下游合作方召开会议,并利用来自现场的反馈来改进新流程。
将系统工程和PLM 的最佳技术结合起来,将为持续改进和数字化转型奠定基础。开发颠覆性产品和系统需要采用颠覆性方法,这需要正确的变更管理流程和技术。
联系客服