用PLM提升研发的质与量

作者：e-works 杨惠芬

欢迎访问e展厅 展厅 3 PDM/PLM/CAPP展厅 图文档管理系统, CAPP... 为了在PDM的基础上持续强化研发能力，日月光集团高雄厂信息中心副总经理盛敏成决定进一步导入PLM，预计应用范围将会扩及项目管理、文件管理、协同工作等。 2005年岁末，一个温暖的午后，日月光副总经理盛敏成从一个刚刚结束的会议中走出来，不疾不徐地谈起了一些新的IT应用计划，原来，2003年就已经导入产品数据管理（PDM）的日月光，为了因应逐渐全球化的业务运作，正准备进一步导入产品生命周期管理（PLM），然而从PDM到PLM，所意谓的不只是研发控管范围扩大了，更深一层的意义是，日月光想要透过Web化解决方案，来符合业务全球化的策略面思考。 从PDM延伸到PLM，研发控管才能由点到线 目前，日月光的PDM应用，可以说是完全着重在与产品相关的开发上，例如工程资料等，未来则要在PDM的基础上，持续导入PLM，然后把应用范围扩大到产品开发项目管理、产品生命周期管理、文件管理、工作流程驱动、协同工作等方面，对于日月光来说，PDM是一个「点状」的研发控管，PLM则会把相关的点都串连成「线」。 盛敏成说，一个产品从无到有，其实是一连串的过程，首先你必须要有想法，然后才能选择要用什么材料来做，而所做出来的产品雏形（prototype），还要能够符合检测标准，才能开始进行初步生产以确保品质稳定性，最后才会正式迈入量产阶段，否则一个好的创意，也可能只是一个艺术品，而每一个环节的IT工具运用都相当重要。 日月光为了提升研发的质与量，预计近期内就会正式导入PLM，其中的项目管理也是重点项目之一。过去，日月光的项目管理，因为是由旗下工程师自己用Notes开发出来的系统，因此，虽然具备项目开发「进度管理」的基本功能，但是对于开发过程中所产生的文件，却无法直接与项目管理系统连结，进而影响了整体开发工作的效益提升。 PLM应用，还要扩展到客户端 值得一提的是，日月光的PLM导入，除了涵盖一般性的系统功能，为了降低与客户之间的沟通频度与无效性，还特别增加了「协同工作开发功能」。盛敏成表示，日月光是做代工的，既然产品所有权不是自己的，而是客户的，当然所需要的沟通就会更多，例如打线、封装方式等，因为每一家代工厂所能提供的技术不同，客户的需求也不是每次都一样，所以沟通是一定需要的。 但来来回回的沟通过程中，所发生的误差也不胜枚举。为了改善这些问题，日月光计划在PLM的导入中，增加「协同工作开发功能」，在这样的前提下，客户不仅可以直接在线上查询到设计进度，日月光还会提供客户AutoCAD等软件来做开发环境仿真，进而提早掌握可以符合生产形态的元素，例如，制程技术的限制以及开发端的设计条件、参数设定等。 结合KM把研发资源化为活水 盛敏成说，产品在开发的过程中，其实会产生许多可以重复使用的资料，如果这些资料可以累积出一定的量，势必可以提升一个公司的研发能力。这些可以重复使用的数据元素，可能是设计图，也可能是一些参数设定、文件规格、盖印规格等，日月光为了能够充分使用这些研发资源，预计将在PLM的导入计划中，把知识管理（KM）与工作流程紧密地整合在一起。 简单地说，就是产品开发过程中所产生的资料，相关人员都必须整理出来，而且放到知识管理系统以后，才能把产品开发的工作递交到下一个流程。 从另一个角度来看，知识管理也是一种内部的技术移转，因为一张设计图可能会有100多个衍生产品，在这样的前提下，这张设计图至少可以被重复使用100次，但是，如果只有一个人知道这张设计图的存在，那幺其它人势必就需要投入时间来完成，同时也造成了开发资源的浪费。 组织改造，加速凝聚PLM导入共识 盛敏成说，IT毕竟只是一个工具，真正改变的其实还是人，因为当PDM的应用延伸到PLM之后，研发工程师的工作方式也会跟着改变，举例来说，当一个问题发生的时候，以前的工作方式，可能会把问题追踪的焦点放在「人」身上，A甚至觉得就是因为跟B的关系不好，所以才会使得问题迟迟没有得到解决，事实上会发生这样的问题，主要就是因为开发过程中，没有把所有的记录保留下来，最后往往需要花费更多的时间来找出问题，PDM与PLM的导入则使得问题处理的方式，可以循着系统记录来找。 这样的转变，甚至影响了IT的需求与供应。盛敏成说，2003年导入PDM的过程，虽然已经分成两个阶段来完成，但是内部的反弹依旧存在，部分员工甚至觉得IT部门很鸡婆，只会没事导入一些IT工具来要求研发人员配合，后来，大家采用PDM之后，渐渐地体会到这项工具的好处，例如，问题发生的时候可以循着系统记录追踪、可重复使用的开发组件取得更容易、甚至是工作产出的证明等。 面对接下来的PLM导入工作，由于涉及范围更广，因此2005年初开始，日月光就不断地进行沟通。最后，因为遇上工程部门的组织改造，如何证明人力配置的适当性，变得很重要，否则可能就会开始检视裁员的必要性，这个时候开发人员对于系统工具的态度，自然就从被管理、被监督、被要求转变成可以证明工作表现的工具需求。 每5年一次的软件授权，企业压力大 每5年就要重新续约一次的软件授权机制，对于大多数的企业来说，是很大的成本压力，盛敏成表示，目前的软件授权大多是5年一次合约，简单地说，就是每5年就要重新购买一次软件使用权，面对这样的现况，营运规模较大的公司，或许还有「以量制价」，甚至是「不续约」的谈判筹码，但是，对于营运规模较小的厂商来说，软件授权确实是一个很大的成本压力，而最理想的周期应该是以10年来作成本摊提基础。 除此之外，软件厂商也应该要提供持续性的服务，而不只是把产品卖了就没事，最起码也应该在软件上线后，来了解一下客户的使用情形，有没有什幺问题，盛敏成说，这就像是生孩子的过程一样，怀孕初期要小心安胎，生出来之后还要持续观察是不是健康，而1年后是不是又真的会走会跑了，但是这些最基本的，软件厂商往往都没有做到，更别提系统出现问题之后的处理了。 以日月光的情况来说，更不可能允许任何系统问题来影响生产，因此，大部分的问题都必须自己想办法解决，才能把系统对生产造成的影响降到最低，再则，因为软件系统的关连性与复杂度都比较高，一时之间，很难立刻定义出真正的问题在哪里，如果要等到真正的问题源找出来之后，软件厂商才能提供支持，那幺，对于生产所造成的影响势必有增无减。这个时候，软件厂商如果愿意充分支持，会比较容易得到使用者的肯定，事实上，软件授权本来就应该把技术服务纳为其中，而不只是软件本身的授权。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (1/5/2006)