您的位置:网站首页 > CAD新闻

PLM实施中的一些挑战

时间:2011-02-26 19:30:58 来源:

现在越来越多的企业都已经在开始进行PLM/PDM的实施,作为一个优秀的PLM系统实施,它往往可以优化我们的业务流程,也可以为我们节省成本以及时间,但是,在实施过程中我们同样会碰到大大小小的许多挑战,按照自己以往的一些经验大致罗列如下:

准备一份愿景文档

任何一项组织性的变革都需要有明确的愿景作为指引,企业的CXO推动PLM项目过程中必须确立清晰的愿景以及路标图,表明项目需要作什么以及达到什么样的目标等等。

此时CXO担任的就是一位团队领导角色,借助团队成员的努力,一方面将PLM的商业愿景推销给企业的高层,另一方面则需要将PLM的收益在企业的各个层面进行沟通和展示,一旦企业的管理层和操作层对PLM都有了清晰的理解并达成一致后,最佳的做法就是将所有这一切内容都通过文档清晰的记录下来,这份文档将成为PLM项目实施的指南。

因此,在这个时期最重要的输出就是一份愿景文档,这份文档清晰的描述了项目实施过程中的关键里程碑,实施方法论,不同的阶段点以及检查点,最后,它也会描述出系统实施后在短期以及长期可以达到的收益,也就是,项目的投资回报(ROI)。

获得员工对变革的支持

一旦愿景文档完成后,它很容易获得企业高层的认可(呵呵,这份文档真的很重要,或者就是一个愿景图,领导都喜欢看),但是系统的成功实施更大程度需要最终的用户支持:

i) 心理上的厌恶感

改变现存的系统都会带来很多人的反弹:我们使用的系统很好啊,为什么要改变它呢?现在这个系统我们已经使用多年,为何要改变学习新的系统呢?改变的阻力永远会存在,但是,技术是在不断的进化过程中,我们可以利用技术的进步来改变现有的业务,设备以及软件等,以达到最终节省时间和成本的目的。

不想改变是人类通常的一个行为习惯,主要是因为人对新生事物总是具有一定的恐惧,害怕新的系统会影响他们每天惯常的生活。

ii) 征服有厌恶感的员工

向员工讲述变革就如同向顾客推销商品,都是非常重要的,否则很容易影响大家的士气。我们平常使用最多的方法就是组织团队研讨会,研讨会上可以组织大家对变革展开讨论,通过头脑风暴的形式讨论出各种方案,尝试不需要投资即可获得收益的可能性,如果大家的结论是没有这种可能性,投资新的系统则会变成一个大家可以接受的方案。当然,任何的方案都需要保证组织的获益,大家才有可能对现状和未来展开认真的评估:做好变革的准备,以及投入热情去学习如何改善做事的方法。

那些有过PLM系统使用经验的员工也可以在研讨会上现身说法,阐述PLM系统如何有效的帮助大家处理日常的事务,并且明确新的系统不会对自身的工作产生威胁,甚至对新产品的开发带来极大的优势,并且可以很好的改善企业的业务流程等。

软件的评估和选型

这是一个竞争的世界,成百上千的软件供应商活跃在这个领域,评估他们的一个首要目的是为企业选择一个正确的系统,按照以往我所实施的PLM项目的经验,简单总结了以下的软件包选型流程:

i) 准备一份PLM需求文档

一个企业必须准备一份文档来描述他们对PLM系统的想像,这是企业自己的“PLM需求文档”。

首先,让企业所有相关成员都展开自己的想象力,即想像PLM系统将如何提升自身的工作效率,并将所有的这些想像都记录下来,包括各个层面的员工,上到VP,下到未来所有操作层的员工。

让我们给出一些例子辅助大家进行想像,例如,有的产品设计工程需要在家里、在因特网上、甚至身处国外都需要对产品的设计图纸进行存取,从这个概念上来看,我们可以将这些需求想像为“Web-Based”的功能;还有一些员工可能需要在新老器件替换后获得成本的分析数据,则可能归纳为对PLM系统的“成本分析”的功能;因此通过大家的头脑风暴,可以收集到大部分的PLM系统功能需求,当然,这些需求需要被大多数成员所认可,这份文档将作为软件包选型的一个基线。

ii) 软件选型

我们的经验是组建一个由专家组成的PLM软件选型委员会,这个委员会的成员可以来自于PLM实施领域的业务专家、技术专家以及来自于设计、制造、采购等部门的专家。

一旦选型委员会成立,则开始与软件供应商进行接触,包括各个层面的供应商,如果获得供应商的反馈,则可以将前面提到的企业愿景文档以及需求文档提供给供应商,甚至包括自身的项目预算限制。列出合适供应商的短清单(short list)可以减少很多弯路,只有那些提供的方案匹配或者接近企业愿景和需求的供应商才可以进入这个短清单列表。

一旦列出短清单,则可以与供应商展开进一步接触,当然,企业不能仅仅只满足于供应商的Demo,而应该提供一些数量的历史数据让供应商进行功能展示,在这个阶段,还需要考虑软件对其他系统,例如ERP系统以及CAD软件的集成支持。

如果企业完成了功能清单列表(都列在PLM需求文档内),就可以准备一份供应商的记分卡,当然,记分卡会给每一个功能点一个权重,通过打分,我们可以量化每一供应商的能力,并且可以使用条状图、饼图等对这些数据进行分析,即使一个很简单的比较,也可以很容易看出谁更好,下面是一个典型的记分卡例子:

PLM 评估: 记分卡
 
(S) 标准0- 不支持1- 需要高度客制化2- 需要中度客制化3- 需要请度客制化4- 系统缺省功能
序号
 
功能点
 
权重 (W)
 
供应商 1 (W*S)
 
供应商 2 (W*S)
 
供应商3 (W*S)
 
供应商4 (W*S)
 
1 通过Internet或者Intranet进行Web登录 10 40 40 40 30
2 任务可以发送至用户的inbox内 8 16 0 0 32    
3 支持产品过程的变更管理 7 21 14   28 21     
4
与CAD工具及项目管理工具双向同步
8 24 32    8 16   
5 基于用户的产品配置(用户可以在自己的视图内创建产品配置)全球配置(在组织内共享) 10 20 20     40 30 
6 很容易创建多层复杂的BOM,从Excel、csv或者文本格式输入BOM,并可以在每层进行成本核算 8 24 16 32 16    
7 与供应商进行协作:与合作伙伴以及供应商之间进行有限的数据协同 8 24 8 16 24    
8 易于创建Excel、PDF或其他格式报表 10 10 20 40 30    
      179 150 204 199

在决定采购一个软件之前,还需要对PLM的硬件有清晰的了解,例如:需要多少台服务器?有多少台客户端?局域网的网速要求多少?是否需要采购第三方软件?所有这些问题都需要考虑清楚,而且需要有清楚的预算。到此,你可以作出你最终的决定了。

表1记分卡内描述的是企业的8项基本需求,按照计算的结果,供应商3也许是一个比较好的选择。但是,进一步仔细观察,供应商4提供的方案所需的客制化最少;另外,供应商3虽然得分最高,但对于需求2他根本无法支持,而且,他需要非常多的客制化,综合来看,我们会认为供应商4是一个最好的选择。

然而,如果我们将成本也作为一个考量的指标的话,则我们需要更细致的考虑。假定供应商4的软件成本为10万美金,而供应商1的软件成本为6万美金,即使供应商4提供的产品更优,我们还是很容易作为选择来。还有,我们还需要看看供应商的实施能力以及产品的技术支持能力,有的供应商只会在软件采购前表现出极大的热情,为避免类似的问题出现,我们可以考察一下供应商以前的客户,当然,有时候供应商自己提供的客户名单并不可靠。

因此,如果你能全面考虑以上各个方面,将会比较容易找到一个合适的供应商。

业务功能差距分析

一旦系统安装完成,下一步就是进行业务的差距分析以及业务和系统功能的对照。

i) 业务功能差距分析

任何软件都有其优势,否则企业也不会作出采购的决定,但是软件也不可能在没有客制化的情况下满足企业所有的业务需求。所以我们需要对软件有清晰的认识,它的各项功能。

在前面我们已经完成了一份PLM需求文档,这份文档清晰的描述了我们的需求以及我们现在的业务流程。在此我们需要重新将需求与系统功能一一进行对照,尤其是不能满足我们的业务需求的部分,如果对照过程中发现需求的实现过程中存在不一致的方案,那我们有必要审视一下这新的方案,它是业界最佳的方案吗?是否采用新的方案仍然可以实现我们预期的收益呢?

当然,如果一项需求在企业内是不容忽视的,则需要在分析过程中明确可以折中的方案是什么,并且对于折中的方案需要谨慎的进行评估。

识别客制化的内容和优先级

一旦差距分析完成,那些需求无法通过系统缺省功能满足则非常清晰,并且明确描述满足客户需求方案的复杂程度以及工作量评估,这份清单将提交给项目指导委员会进行决策,项目指导委员会将对客制化内容进行评估,并给出每项需求的优先级。

i) 识别客制化内容

首先,项目指导委员会需要下属的各业务小组对这份差距分析文档进行合理性分析,尤其是阐述每项业务需求的必要性,并且给出业务改变的可能性,即在无需客制化的情况下是否可以按照新的PLM系统对自身的业务进行改变?我们在实施过程中需要尽可能的减少系统的客制化的内容,因为大量客制化不仅会加大系统维护的工作量,而且在未来系统升级过程中也会增加升级的复杂程度,并且在未来的升级过程中供应商很有可能将客制化的功能作为标准功能在系统中实现,所以在项目实施过程中只客制化某些必需的业务需求,这一点相当重要,否则,企业花这么多金钱购买软件包干嘛?

ii) 分配优先级

仔细评估可以减少客制化内容。对一个企业来说,某些业务需求虽然重要,但不一定非常急迫,所以我们在给业务需求排序时需要把握需求的重要紧急程度,重要紧急的需求当然排在首位,重要但不紧急的需求则可以在后续的阶段中实现,我们在排序过程中可以给每项需求一个最终的截止时间点,以方案项目团队合理的调度资源。