PDM、CAPP怎样走下去？

作者：张蓬 刘丰田 朱战备

欢迎访问e展厅 展厅 3 PDM/PLM/CAPP展厅 图文档管理系统, CAPP... 案例背景 A公司是一家中型制造业企业，在2003年6月，与国内某知名软件厂商B公司签订了PDM（产品数据管理）/CAPP（工艺数据管理）合同，该合同于2004年2月开始执行调研工作。随后，由于A公司CAD版本陈旧，难于符合PDM实施标准，双方商讨升级版本，致使该项目搁浅4个月之久。后经双方有关人员努力，A公司以一个似乎合理的价格购买了B软件公司的CAD软件。双方随即签订补充合同。二次开发相关内容真正开始实施，已是调研后的第六个月。 第一次实施，B软件公司的工程师到A企业确认计划书。他们用了一个下午的时间，交流了工时定额、材料定额的报表等工艺的情况。在这些问题上，A企业和B软件公司出现了明显的分歧： 1、A企业要求材料定额可以随意做阶段性汇总，而B公司只承诺材料定额可以按部分或按工程汇总。双方在友好气氛下为各自的利益交谈，最后决定材料定额按部分或工程汇总可作为中间表，虚拟部分或工程再重新汇总。但实施时是否真能达成所愿，还不得而知。 2、工时定额确定到工步还是工序？这个各有利弊的问题，各自站在不同角度去考虑。工艺员所定工艺与工时员所定工艺，在企业里会出现不统一问题，且没有想统一的意思。软件方不追究，A企业也只能打疑问。 3、最后软件方还给在场人一个惊叹！标准版里的CAPP没有版本管理和审批流程，也就意味着，一个工艺模板得不到保护，最多只能在日志中查看或是修改ID。领导审批工艺也只有靠电话提醒和回复了。 A企业没有说了算的领导在场，干活的技术人员在提出质疑后，听取了软件方所谓的“合同里只要求标准版，而标准版里确实不提供这两个模块”的解释后也就作罢。最后只能感叹，“那么多钱原来大部分还是给设计部门上CAD和PDM，工艺上CAPP，成为两个系统……” 不过一切皆在融洽的气氛中进行，双方都不想把将来的合作搞得不愉快，A企业没有和软件方继续争论当年的合同是怎么写的。 到目前为止，这个项目还在进行中，A公司希望得到专家的建议促使这个项目成功。 准备工作：一个都不能少 ■ AMT-企业资源管理研究中心 专家顾问 张蓬 看完这个案例，我的第一反应是：这又是一个准备不充分的项目。和许多企业在信息化过程中走过的弯路一样，A企业的选型过程显得仓促而不完善，看起来这样可以节约一些时间，但具体实施的情况表明：该做的准备工作，一个都不能少。 A企业的案例可以引申两个话题，首先是充分的准备工作应该是什么样的？其次是在当前的现状下，A企业如何顺利地完成项目？ 需求与解决方案不匹配 a企业在实施过程中所出现的问题集中体现在a企业的需求和b企业的解决方案不匹配，具体体现在以下方面： ◆ 新系统和a企业的遗留系统在集成方面的不匹配。 ◆ capp和a企业的需求出现了较大的不匹配。 因此，如何使项目的推进很顺利，从根本上取决于a企业所能接受的需求变化范围。需求的不匹配是几个基本的事实，很难通过什么行动来回避。因此，说到底，项目能否顺利推进取决于a企业自身的态度。 重新调研和规划 a企业应该补做的一个工作就是重新做一次细致的需求调研和规划工作，通过这个工作可以明确a企业期望通过pdm、capp等系统的实施究竟解决什么问题。这个工作应该是深入而细致的，基本上能把系统实施的底线搞清楚，同时做到不遗漏。 详细的需求调研可以参照右边的表格内容。 表格的横向部分搜集各种可能的需求,纵向部分是相关的部门、跨部门的使用单位。通过这样的方式，可以明确企业内部对pdm、capp等具体的功能以及对这些功能的需求者。 得到这样的表之后，下一步的工作是对表格中每一项可能带来的潜在效益和实施复杂性进行分析，如下图所示进行排序。 通过这样的分析，可以摸清楚a企业对系统的需求究竟是什么。比如，落在上述矩阵右上角的部分，代表对a企业而言非常重要的那些系统功能与需求，代表着a企业对新系统的基本期望。一般来说，企业往往希望这些功能能够得到不折不扣的实现。在选型过程中，在这些方面的匹配程度往往会作为最重要的评价标准。 具体到a企业，因为选型已经在一定程度上成为定局，那么，在看到b公司软件功能有一定差距的现实情况下，a企业应该首先寻找上述矩阵中右上角的那些功能，尽量要求b公司在这些方面，通过二次开发等手段尽量实现需求。如果实在差得太多，中止与b企业的合作是一个明智的选择。 a企业只是将风险延迟 尽管在案例中，我们可以看到，到目前为止，a企业与b企业在该项目中似乎还很和谐，但表面上的和谐并不意味着合作的顺利，这只是将风险延迟而已。既然是风险，迟早是要爆发的，只不过，破坏程度会更大而已。项目管理领域有一个经典的谚语：不要试图拯救一个正在下沉的船，说的就是这个意思，如果不能在现有的框架内解决问题，那就跳出这个框架，尽管这样可能意味着a企业要遭受一定的波折。 有意思的是，就这个案例，我们可以进一步追问一下，a企业为什么会在选型过程中出现一定问题的呢？我觉得，仅仅用准备不充分是不能回答这个问题的。 案例似乎在告诉我们，a企业信息化的相关人员（高层领导、业务人员、it人员）在沟通上并不充分。在信息化的不同阶段，每一种角色应该做什么工作似乎并不清楚，也就是说出现案例中的这种现象：a企业没有说了算的领导在场，干活的技术人员在提出质疑后，听取了软件方所谓的“合同里只要求标准版，而标准版里确实不提供这两个模块”的解释后也就作罢。最后只能感叹，“那么多钱原来大部分还是给设计部门上cad和pdm，工艺上capp，成为两个系统……” 我觉得，a企业的相关负责人应该仔细思考这样一个问题，如何建立一个稳定的架构来推进信息化工作。而案例中的这个现象也似乎在告诉我们后续的结局：技术人员会发现越来越多的不匹配和不和谐的现象，直到项目出现重大危机时，领导才会出面，然而，已经失去解决问题的最佳时机。 这是项目的范围管理问题 上海贝尔阿尔卡特副总裁兼首席信息官 朱战备 这个案例所反映的问题在信息系统实施中是比较普遍的。在开始实施时a、b公司所碰到的表面上的种种分歧，归结起来本质上主要是项目的范围管理问题。 定义项目范围可能是定义一个项目过程中最重要的部分。事实上，如果你不确定你在进行的是什么，以及你所进行的项目的边界在哪里，你就根本不可能成功。管理项目范围是项目管理中最重要的一部分。但是，如果你没有很好地定义项目范围，那么你的项目将不可避免地面临失败的危险。 糟糕的范围管理是导致项目失败的致命伤，通常在实施pdm项目时会遇到下列问题： ◆ 咨询公司或系统集成商往往有一种“never say no”的气魄。的确，一个实力雄厚的咨询公司是可以通过二次开发和客户化，提出适应客户个性化需求的解决方案。但是，客户化开发需要做的工作，客户往往并不清楚——工作量有多大，由谁来进行，费用是多少，如何配合整体实施进度？不过，如果销售人员对这类问题谈得过深过细，很有可能影响签单。因此，在许多情况下，这些问题被有意回避，成为双方合作和实施中的定时炸弹。 遗憾的是，不少软件公司的销售人员并不十分了解pdm系统的原理与概念，甚至不了解本公司产品的功能，至于对行业存在问题的了解就更难说了；他们主要的特长是“关系学”。在接触客户甚至签单的过程中，销售人员往往会过度承诺（over-promise），他们关心的是“签单”，也就是“成交”，而售后服务顾问关心的是“客户满意”，也就是“成功”。 “成交”和“成功”虽然仅有一字之差，但是公司对两类人员有不同的考核指标，对前者的考核是完成多少销售额，对后者的考核是完成多少服务天数。这种公司内部销售和技术支持部门之间的矛盾，对公司和用户都非常不利。 ◆ 一旦项目开始进行了，在进一步讨论项目实施的范围时，客户与软件公司就会发生这样那样的分歧，一种可能是，客户不停地要求软件公司完成超出原来商定范围的工作，或者和原来商定范围不同的工作；还有一种可能就是，软件公司以超出合同范围为由拒绝提供实际上应该要做的工作。 ◆ 范围蔓延：很多项目经理能够意识到大的范围改变，但是对于小的改变却没有那么敏感了。现在有一种趋势，就是不断地进行项目，不断添加额外的工作而并不经过仔细的考虑。范围蔓延指的是当项目接受了太多小的变化之后所出现的情况。当所有这些小的变化结合在一起，项目小组才意识到需要做的额外工作太多，以至于要超出预算，延误工期。 ◆ 没有发起人的同意：有时软件供应方项目经理会从最终用户，或者客户经理那里收到变更请求。由于这些人都是客户公司内部的，他们认为这些请求都应该被接受。很多项目陷入麻烦是因为他们认为他们获得了进行范围修改的批准，但是后来却发现有权决定这种变更的人—发起人，并没有同意这样做。 ◆ 项目小组的责任：由于项目小组成员和客户有很多联系，他们是最经常会遇到范围更改请求的人。因此，整个项目小组必须理解范围变化管理的重要性。他们必须在范围变化发生的时候立即发现它，并且及时把它反馈给项目经理。如果他们自己答应进行一些额外的工作，他们的这种行为就很有可能导致他们不能够按时完成自己的工作，从而危及整个项目的进行。 科学的范围管理是项目成功的第一步，它的基础是一个科学的范围管理流程，其中包括范围规划、范围定义、范围确认和范围变更，如上图所示。 我们在实施pdm项目时必须意识到范围变化本身并没有什么不对。也就是说在项目进行过程中修改范围并不是什么坏主意。事实上，很多时候，这是一件好事。首先，客户和软件供应方通常都不能确定最终解决方案所需要的所有的需求和功能。其次，就算他们可以，商业环境是随着时间不断变化的，因此项目的需求也会发生变化。如果你不能够容纳变化，最终的解决方案就会达不到应有的价值，或者它甚至有可能是无用的。 定义范围变化管理流程最好的时机是在项目开始之前（作为项目管理程序的一部分）。但是，如果你确实没有建立一个好的流程，任何时候开始都不算太迟。项目管理必须安排一个暂停的时间，由实施双方一起来鉴定并满足范围变更的请求。然后每个人都要学习新的流程。 为了解决a、b公司目前在实施pdm时所遇到的问题，我建议双方的项目经理要尽快坐到一起，对于在合同框架体系下承诺的内容要清晰地表达出来，澄清模棱两可的描述。 对于在合同外的需求或者变更需求，需要通过范围管理的变更流程来控制。对要实现的系统功能有个优先级排序，哪些是至关重要的，哪些是重要的，哪些是需要的，哪些是锦上添花的。这对后面的资源安排很有帮助，当然重要程度需要双方共同讨论加以确认。在此基础上，必须形成一份完整的需求规格书。双方充分沟通讨论，形成统一意见，交由项目指导委员会审批。批准后，就成为项目范围的基准线(baseline)，以后的变更就要更改该文件。 其次，还要定义一个实际可行的范围管理流程，这个流程应该包括确定变化，评估变化的商业价值，评估对于项目的影响，一些小的变化，项目经理可以适当调整项目进程，但是一些比较大的变更需要将这些信息提交给项目发起人进行评估。发起人然后可以决定是否同意该变化。如果同意，发起人还应该理解它对于项目的影响，然后为它追加费用，延长项目时间。 两种方式解决困境 ■ ibm高级专家顾问 刘丰田 中国机械制造企业工程信息化如果照搬西方国家的经验，很难应用到中国的制造业企业当中。经过近几年的市场推广应用，我们发现要想满足中国企业的需求，还必须要在原有的系统之上，开发出具有中国特色的工程信息化系统。 根据我们的实际经验从技术的角度发表一下看法：现在市场上的capp系统无非分两大类：文件型和数据库型。数据库型又有两种形式：编制和管理（包括版本和流程）整合型，编制（标准版）和管理（增强版）独立型。针对文件型capp系统，pdm完全可以把工艺文件作为技术文档管理，这也就不涉及到本文中谈到的问题。 如果是数据库独立型capp系统，案例中的企业可以考虑两种方式解决困境： 一、鉴于合同中只签订了标准版，可以将版本管理和工艺流程管理的任务交给pdm。从文中看，pdm/capp来自一家公司，不管这家公司是两大系统的原厂商还是系统集成商，都应该对两个系统的架构和数据库形式很熟悉甚至有过集成经验。（如果是相对独立的两个数据库，而不是靠视图关系来建立联系的，这样尽管厂家承诺集成的可行性，其结果也是值得怀疑的）在这个假设下，应该实现在pdm结构树中。产品结构树中具体每个零部件对应于工艺文档树中具体文件夹或文档，具体功能如下： 1.capp与pdm间的数据流动关系： ◆ pdm管理设计图形和数据，并生成ebom。 ◆ pdm向capp提供ebom数据，并可实现对其的更新。 ◆ capp完成工艺准备后，将pbom提供给pdm管理，并可实现对其的更新。 2.其它功能： pdm与capp的集成功能： ◆ pdm同步管理capp的用户组织、名称、密码。 ◆ capp提供用户组织、用户信息的操作接口（com）。pdm进行集成开发。可以在pdm中创建、修改、删除组织和用户，能保持两个系统的组织（局部）、用户名、登录名、密码一致。但角色、权限等使用各自系统中的定义。 ◆ pdm中启动capp进行工艺设计和管理。 ◆ 在capp中启动pdm进行产品数据管理。 二．pdm与capp有效集成，pdm统一管理版本和流程，其结果必然会增加pdm的费用，因为要考虑工艺人员使用pdm 的频率并增加点数。这笔费用如果用于购置具有版本和流程管理的capp增强版，性价比又如何呢？这个账企业需要自己算。 下面我从技术角度分析一下pdm和capp 各自均带管理功能的情况，其中e-bom,p-bom的集成功能和用户组织、名称、密码的管理方式与前面一样，关键在于流程的实现： 首先我们定义一下流程：制造型企业常用到的流程有以下三种：任务分派、审批、工程变更。设计原则应尽量减少在两个系统中的切换次数。 任务分派：这个流程完全可以在两个系统中各自进行，因为现在的企业大都是设计所和工艺所分开（案例中企业应该也是这样），其工作顺序性很强。两个流程的结合点就是工艺任务的发派人，只要将这个核心角色在两大系统流程设计时考虑进去就可以了。 审批：设计和工艺的审批过程基本是独立的。其中有交叉的是总工艺师和总工。总工艺师需要在设计过程中进行工艺审查，所以应该在pdm 的设计中加以考虑；而总工可能会同时参与设计与工艺的审定，这就要求总工会在两个系统中不断切换。但这种切换是有限的，毕竟决大多数工艺人员仅需在读取e-bom和提交p-bom时使用pdm系统，节省了流程中的切换。 工程变更：和审批一样，设计变更流程可以在pdm 中做，工艺变更可以在capp中做，置于设计变更是否或何时引起了工艺变更，而工艺变更是否或何时更新pbom, 是由具体负责人决定的，在该负责人处应该考虑实现系统间的切换。(end)

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