郭晓川：2008年至今，任PTC中国售前团队电子高科技行业战略客户技术经理。2001年至2008年，从事SAP后勤模块实施和售前工作，曾参与Lenovo SAP项目、中石化SAP项目等。毕业于武汉大学计算机科学学院 。
PTC中国售前团队电子高科技行业战略客户技术经理 郭晓川
e-works：请您简单谈谈Windchill关于BOM解决方案的思路。
郭晓川：BOM的简称已经不能准确的表达企业所需要的产品信息数据结构了。BOM是Bill of Material的简称，起源于某个部门比如研发、制造为了制定手头的某个任务而列出的关于产品由哪些部件组成的一个简单、明确的列表。
Bill of Material的名字容易让人以为指代的是一个静态的列表、和经过确认之后的明确的列表、仅仅包含Material。而实际上企业内的产品结构信息是多个职能部门设置外部伙伴协同、经过分层分级的流程才能逐步确定下来的信息，静态的列表无法表达，而且所需的信息远超过部件料号和数量这类基本信息。
因此，PTC认为使用Bill of Information，或者Product Structure的表达要更合适。对于产品信息的管理，要想有效的支持企业研发流程以及其他前端（面向客户）后端（面向企业内部协同）的流程，必须从时间范围上覆盖从市场创意到售后退出服务的全生命周期，从职能部门范围上要覆盖研发、市场、销售、采购、预测、测试、制造、服务、质量以及成本的全矩阵的职能组织，从技术学科上要覆盖机械结构、电子电气、软件开发、技术资料等产品所涉及的全面的技术组成。
PTC认为产品信息管理应该提供‘single source of truth’，PLM系统应该为企业的内部和外部的所有利益相关者提供‘唯一真相’。
仅仅管理一份静态的BOM数据不再有意义，真正有业务价值的系统应该做到让和产品信息相关的参与者和数据都与业务流程紧密结合，使得利益相关者对于产品的构成、产品的状态、产品如何设计、产品如何制造、所依据的技术或者业务理由等等，真正的在共识之下开展各自的工作。
同时，产品信息的管理，也要符合企业自身的研发方法和流程，比如，如果企业推行IPD（集成产品开发）或者模块化开发，都需要考虑在流程落地的时候，和数据相关的组织和角色应该是谁，流程中如何使信息在适合的数据结构上准确和高效的表达以及传递。
企业常见的关于BOM的痛点，比如制造BOM出错，根据BOM备料却常常由于BOM的变动而造成呆滞库存，等等，表面上看是静态BOM清单出错，根因还是当企业面临越来越大的时间、成本和质量压力的时候，跨职能、跨学科的团队之间关于产品的构成、状态和过程，要想高效率的协同形成共识并在共识之下开展各自的工作变得更难了。
完全依赖经验和人的话，难免费时费力和出错。比如，在产品开发周期越来越短和关键元器件的采购提前期却仍较长的夹击之中，让采购和预测团队得以和研发团队对备料清单形成共识，就变得更具挑战了，研发阶段的处于内部或者外部原因的变更，使得要想形成并保持共识很费时费力而且容易出错。而优秀的企业则需要各个内部外部的合作各方高效而准确的达成并保持共识。
图1 市场趋势与竞争，对企业配置与变更管理水平的挑战
图2 和BOM/产品信息管理有关系的业务痛点/‘症状’
当然，从静态的BOM管理，到‘Single Source of Truth’中流程、人员和数据的紧密结合，不同业务模式的企业，在不同的阶段所适合的实践的成熟度是不同的。
因此，PTC的产品信息管理方案涵盖了从低成熟度到高成熟度的实践。
基础级别的实践包括：变更管理和配置管理。变更管理的实践包括：标准化自动化的变更，集成的跨学科的变更，集成的产品问题管理。配置管理的实践包括：配置生命周期管理，选配和变型管理，产品配置在企业内部的共享，产品信息向企业的下游平台（比如ERP、CRM）的发放，等等。每个实践PTC都有完整的storyboard（故事板），可以帮助企业理解实践如何通过人/角色、流程、数据来落地实施，这里就不一一展开介绍了。
Windchill中提供完备的配置管理功能，包括生命周期状态、工作流、版本、基线、视图（需求视图、功能视图、设计视图、工程视图、仿真测试视图、制造视图、售后服务视图、成本视图）、有效性、实例管理、问题跟踪管理等，不再一一赘述。
更高级别的实践包括：企业级变更管理、产品配置（包括选配逻辑）与企业外部合作伙伴的共享、模块化开发、自顶向下的设计、平台CAD结构的管理、平台可视化、需求分析和早期BOM规划等。
这些实践所基于的产品有：Windchill的PDMLink、ProjectLink、MPMLink、Workgroup Manager等模块，以及PTC的Creo、Integrity等产品。
Windchill的Work Group Manager使产品相关的MCAD和ECAD和产品结构的管理无缝对接。
Windchill还有Integrity产品覆盖需求和验证管理，及软件生命周期管理。需求与验证管理模块支持需求结构、系统设计结构和工程结构、测试结构之间互相关联，从而可追溯可重用。软件生命周期管理模块则管理所有软件开发制件的创建和变更，然后连接需求、规格、设计文件和模型、代码和测试案例。使得软件信息的管理不再与产品结构的管理脱节。
Windchill还有MPMLink模块提供设计BOM到制造BOM的转换和联动。
具体的功能不再一一赘述。
e-works：请问在Windchill的BOM的解决方案中如何实现产品配置管理？
郭晓川：选配方案的目的是如何在大规模制造下经济高效的实现产品的多样化定制。
产品选配的管理，需要定义和管理产品的配置平台、以及平台衍生出的变型的配置，满足不仅是研发部门，也包括客户、销售区域、市场、客服等各个职能部门对于选配的需求，并提供设计的备选方案和改进方案。
因此，PTC公司对于产品选配管理的方案包括四个方面的最佳实践：通用化产品平台设计，平台和变式的分析和评估，平台CAD结构管理，以及平台的可视化。
1）通用化产品平台设计
Windchill系统帮助用户可以捕捉和定义通用化的产品架构（包括机械、电器和软件），以帮助通用平台的开发，以及随后用户（比如研发部门、市场部门、销售部门）进行基于可配置的产品架构开发产品变型的过程。
- 捕捉产品结构的定义超集（必选的、可选的）
- 接口和模块化架构的定义和管理
- 管理可选配的选项和逻辑制约规则，并且分配到产品结构
- 评估和验证选配逻辑和制约规则
- 过滤、选配出变型信息
2）平台和变式的分析和评估
Windchill系统进而帮助用户进行平台的分析、评估和验证，比如自动的创建关键的设计配置以进行分析和评估，在数字化模装中快速可视化和识别设计问题，跟踪和解决干涉问题：
- 评估选配的守规状况、成本状况
- 在早期就要跟踪产品的目标成本和估计成本
- 系统化的识别潜在的干涉问题，以及后续的跟踪和解决
3）平台CAD结构管理
PTC公司的Windchill系统和Creo系统之间的集成，关联了产品的结构和CAD装配结构，支持了高效的模块化平台开发、可视化和变型生成。
4）平台的可视化
利用产品的3D展示，使得设计、测试、制造规划以及售后服务的内部沟通更加便捷直观。
总之，PTC的Windchill系统和Creo系统，通过以上四个方面的最佳实践，可以帮助客户提升应对大规模定制的能力，模块重用的能力，以及管理大量的产品变型的能力。
e-works：请问在Windchill中如何实现不同视图BOM的转换？
郭晓川：企业中不同的职能部门对于BOM有着不同的关注面和业务应用，可以称之为视图。
比如，企业的业务中存在销售合同BOM，需求BOM、功能BOM、设计BOM、工程BOM、仿真测试BOM、制造BOM、售后支持BOM等等。
比如制造BOM，大多数企业因为已经有了ERP系统或者MES系统，由于制造系统的需要，一定已经通过手工或者自动的方式存在一份列表，明确的定义出生产一种产品到底需要哪些零部件以及数量，常称之为制造BOM。
那其他部门，比如采购、市场、研发、工程、测试、售后等部门所关注的BOM信息，BOM信息源头从哪里来呢？互相之间又是什么关系呢？
比如，设计人员更多是考虑Fit, Form, Function，从功能、外形、接口层面考虑BOM，但是制造或者采购人员则不同，同样的产品，在不同的地区、不同的工厂工艺下，是有不同的制造BOM，或者不同的采购BOM的。
这样，设计人员产出的设计BOM，是不能够描述制造和采购部门关心的产品信息的，同一份设计BOM很可能要对应多份制造BOM（对不同工厂），多份采购BOM（对不同工厂或者地区）。制造部门，和采购部门需要随时知道设计BOM的变化，而且需要有工具辅助他们，当他们根据具体情况考虑是否也修改制造BOM或者采购BOM。
由此可见，如果有技术手段能够随时提醒、或者在产品数据上随时的体现出源头/上游BOM是不是发生了改动，对于职能部门是非常有价值的。
因此，Windchill中的视图功能即是意在于此。企业各个职能部门可以梳理各部门对于BOM信息的依赖关系，以及BOM的创建和修改流程，然后，可以利用视图功能，把其中某个视图作为基础视图，并且定义各个视图之间的上下游关系。在建立了视图关联之后，Windchill可以辅助企业对于这些视图之间的追溯、变更提醒、比较、以及联动。
其他视图，比如制造视图、测试视图，在约定的某个早期的时间点先拷贝基础视图。以后的这个视图的增删改，系统都可以方便的跟踪这些增删改所造成的下游视图和上游视图之间的不同。
这样一旦基础视图比如是设计视图发生变化的时候，系统可以自动提醒制造部门、测试部门、售后部门，提醒这些部门他们的BOM视图有哪些条目是已经和基础视图不同步了，使得这些部门可以及时的知晓并决定如何处理这些差异，是刷新、还是不需要和上游同步，等等。各个视图之间的比较也变得随时可行了。
这样，使得各个职能部门对于BOM保持共识变得便利了，时间变短，工作量变小，而且变更及时；提升了效率的同时也降低了出错率。
企业可以参考利用Windchill中的视图功能，定义设计视图、成本视图、制造视图、售后服务视图等等，并且定义视图之间的上下游关系。在建立了视图关联之后，Windchill可以辅助企业对于这些视图之间的追溯、变更提醒、比较、以及联动。
至于具体的关联规则，还需要在软件实施之前进一步分析，以确定以何种功能实现和表达BOM的不同的职能层面。
e-works：请您谈谈在Windchill中BOM的有效性是如何管理的。
郭晓川：对于某些产品，旧版本的部件/文档需要被新版本的部件/文档所取代，取代的条件是某种日期范围或者批号范围或者序列号范围。这种信息称之为‘有效性’。
这种取代的‘有效性’信息，对于有些行业，是研发人员负责的，比如一台飞机和组装在飞机上的发动机的关系，在研发阶段就需要跟踪哪台飞机安装的是那些台发动机的序列号，又比如某些关键的医疗器械，也是在研发阶段也就需要跟踪产品批号和关键部件的批号的关系。但对于一些大规模制造的行业，这种跟踪是到供应链量产阶段才会出现并记录的，这些行业的‘有效性’信息的业务负责人和维护人是供应链部门而不是研发部门。有效性信息应该在哪个信息系统中管理，是PLM系统，还是ERP系统，要考虑企业的实际业务场景。
用户可以在Windchill中定义三种类型的有效性：日期驱动、批号驱动、序列号驱动，这三种类型都可以指定单值或者某个范围。在定义了有效性之后，可以使用Windchill的变更流程设置和修改某个产品下的有效性条件。之后，在产品结构展开时，就可以使用有效性条件作为展开的过滤条件之一。
总之，Windchill帮助用户在整个产品生命周期中指定配置的有效性，清晰的描述了部件和文档的使用情况，减少了产品信息错误。
e-works：请您谈谈在Windchill中BOM的版本与状态是如何管理的。
郭晓川：Windchill系统中的所有数据对象都有版本管理，版本由修订版本和小版本组成。修订版本，也叫大版本：记录了数据对象生命周期中的某个阶段的状态，由变更流程生成。
小版本：记录了大版本中间的数据的变化过程。用户每次对对象进行一次检出和检入操作后由系统自动为对象生成的版本。如A.1版本、A.2版本。可以在系统中定制所需要的版本编码规则。
图3 Windchill版本规则
Windchill 系统中的每个对象类型均可具有单独的生命周期状态和访问控制策略。当用户创建某种类型的对象时，可以用对象初始化规则指定该项类型的生命周期。生命周期定义了相关联对象可处于的主要状态，比如“正在工作”、“已发布”或“已取消”状态。对象的状态变化受工作流程运行驱动。对象的状态可以与系统自动流程关联，并且可以与权限控制有关。
比如，用户新建了一个文档，文档的类型中定义了它的生命周期模板。生命周期中定义了文档可以有“正在工作”、“已发布”或“已取消”的状态。然后，生命周期使用工作流来定义进程。当文档经由该进程时，用户的决策将影响文档处于生命周期的哪一个状态。例如，任务可能要求产品经理批准某个文档，如果产品经理批准了该文档，则该文档将由“正在工作”变为“已发布”。工作流中的每项任务均有一个角色负责完成此项任务。工作流使用“产品”或“存储库”团队来确定履行该角色的人员，然后将任务发送给指定用户。相关的用户就会收到带有链接的通知邮件；而且，登录Windchill的时候就会看到自己的‘任务总览’中有处理该文档的任务。
PLM平台的基础的能力就是人、流程和产品数据的紧密结合，这是任何一个与产品相关的业务变革（IPD，DFX，等等）被落地执行和固化的前提条件。Windchill的平台具有integrated, internet-based, interoperable（与开发工具无缝交互）的特性，这三大属性使得Windchill在支持人员、流程和产品数据的结合上更具优势和可扩展性，尤其是在考虑IT投入的TCO（总体拥有成本）上。
Windchill有较为完备的OOTB（开箱即用）的产品信息管理的功能，PTC也称之为产品配置与变更管理，除了生命周期状态管理以外，包括：版本、基线、工作流、视图、有效性、替代管理、选配、配置器、变式（变型）BOM，变更的偏离/偏差/豁免，等等。就不一一展开介绍了。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：Windchill BOM管理
相关文章
