BOM分析文档格式.docx
《BOM分析文档格式.docx》由会员分享，可在线阅读，更多相关《BOM分析文档格式.docx（27页珍藏版）》请在冰豆网上搜索。
“行了，行了，我们没有那么多的时间。
让我来告诉您我们的需求。
实际上我也很忙。
请马上开始开发，并随时将你们的进展情况告诉我。
风险躲在需求的迷雾之后
以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。
在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。
这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。
这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。
若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。
因此可见——需求分析奠定了软件工程和项目管理的基础。
拨开需求分析的迷雾
像这样的对话经常出现在软件开发的过程中。
客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。
那么，我们就拨开雾影，分析一下需求的具体内容：
·
业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。
“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。
其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
下一层次需求——用户需求，必须从使用产品的用户处收集。
因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。
例如：
程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。
用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。
如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。
除非遇到的需求极为简单；
否则不能这样做。
如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。
只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
客户的需求观
客户与开发人员交流需要好的方法。
下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。
如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、
分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，因此要使用术语。
客户应将有关术语（例如：
采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。
这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。
为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。
如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。
s
3、
分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。
通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。
报告应以一种客户认为易于翻阅和理解的方式组织编写。
客户要评审此报告，以确保报告内容准确完整地表达其需求。
一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、
要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；
虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、
开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。
共同合作能使大家“兼听则明”。
参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、
开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；
在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、
描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。
客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。
正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、
允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。
所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、
要求对变更的代价提供真实可靠的评估
有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。
而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。
所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。
开发人员不能由于不想实施变更而随意夸大评估成本。
10、
获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11、
给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；
不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12、
抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。
有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13、
准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。
由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。
但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。
用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。
客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。
如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、
及时作出决定
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。
有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15、
尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。
客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。
开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、
划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。
决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；
开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。
尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、
评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。
如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
更好的办法是先为产品开发一个原型。
这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；
原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18、
需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。
变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；
变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。
所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19、
遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。
这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、
尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。
也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；
如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。
“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：
“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：
“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。
这两种态度都是不对的。
因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：
“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。
我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。
”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
物料清单（BOM）和信息化软件
e-works
张志
2002-7-22
e-works
引言
本文将就静态数据中物料清单（BillofMaterial，BOM）的作用，结合CAD（ComputerAidedDesign，计算机辅助设计）、CAPP（ComputerAidedProcessPlanning，计算机辅助工艺编制）、PDM（ProductsDataManagement，产品数据管理）、MRPⅡ（ManufacturingResourcePlanning,物造资源计划）、ERP（EnterpriseResourcePlanning,企业资源计划）等系统作详细的描述。
什么是BOM？
采用计算机辅助企业生产管理，首先要使计算机能够读出企业所制造的产品构成和所有要涉及的物料，为了便于计算机识别，必须把用图示表达的产品结构转化成某种数据格式，这种以数据格式来描述产品结构的文件就是物料清单，即是BOM。
它是定义产品结构的技术文件，因此，它又称为产品结构表或产品结构树。
在某些工业领域，可能称为“配方”、“要素表”或其它名称。
在MRPⅡ和ERP系统中，物料一词有着广泛的含义，它是所有产品，半成品，在制品，原材料，配套件，协作件，易耗品等等与生产有关的物料的统称。
在通常的MRPⅡ和ERP系统中BOM是指由双亲件及子件所组成的关系树。
BOM可以是自顶向下分解的形式或是以自底向上跟踪的形式提供信息。
在MRPⅡ和ERP系统中中BOM是一种数据之间的组织关系，利用这些数据之间层次关系可以作为很多功能模块设计的基础，这些数据的某些表现形式是我们大家感到熟悉的汇总报表。
BOM有什么作用？
BOM是PDM/MRPⅡ/ERP信息化系统中最重要的基础数据，其组织格式设计和合理与否直接影响到系统的处理性能，因此，根据实际的使用环境，灵活地设计合理且有效的BOM是十分重要的。
BOM不仅是MRPⅡ系统中重要的输入数据，而且是财务部门核算成本，制造部门组织生产等的重要依据，因此，BOM的影响面最大，对它的准确性要求也最高。
正确地使用与维护BOM是管理系统运行期间十分重要的工作。
此外，BOM还是CIMS/MIS/MRPⅡ/ERP与CAD，CAPP等子系统的重要接口，是系统集成的关键之处，因此，用计算机实现BOM管理时，应充分考虑它于其他子系统的信息交换问题。
BOM信息在MRPⅡ/ERP系统中被用于MRP计算，成本计算，库存管理。
BOM有各种形式，这些形式取决于它的用途，BOM的具体用途有:
1、是计算机识别物料的基础依据。
2、是编制计划的依据。
3、是配套和领料的依据。
4、根据它进行加工过程的跟踪。
5、是采购和外协的依据。
6、根据它进行成本的计算。
7、可以作为报价参考。
8、进行物料追溯。
9、使设计系列化，标准化，通用化。
BOM有哪些形式？
按照用途划分
产品要经过工程设计、工艺制造设计、生产制造3个阶段，相应的在这3个过程中分别产生了名称十分相似但却内容差异很大的物料清单EBOM、PBOM、CBOM。
这是三个主要的BOM概念。
工程BOM——EBOM（EngineeringBOM）：
产品工程设计管理中使用的数据结构，它通常精确地描述了产品的设计指标和零件与零件之间的设计关系。
对应文件形式主要有产品明细表、图样目录、材料定额明细表、产品各种分类明细表等等。
计划BOM——PBOM（PlanBOM）：
是工艺工程师根据工厂的加工水平和能力，对EBOM再设计出来的。
它用于工艺设计和生产制造管理，使用它可以明确地了解零件与零件之间的制造关系，跟踪零件是如何制造出来的，在哪里制造、由谁制造、用什么制造等信息。
同时，PBOM也是MRPⅡ/ERP生产管理的关键管理数据结构之一。
实际上BOM是一个广泛的概念，根据不同的用途，BOM有许多种类;
设计图纸上的BOM，计划BOM，计算最终产品装配的制造BOM，计算成本的成本BOM，保养维修BOM等。
根据在不同阶段应用侧重点不同，我们常常见到不同的BOM提法，常见的有：
设计BOM——DBOM（DesignBOM）：
设计部门的DBOM是产品的总体信息，对应常见文本格式表现形式包括产品明细表、图样目录、材料定额明细表等等。
设计BOM信息来源一般是设计部门提供的成套设计图纸中标题栏和明细栏信息。
有时候也涉及工艺部门编制的工艺卡片上部分信息。
设计BOM一般在设计结束时汇总产生，如果存在大量借用关系的设计情况可以在设计阶段开始就基本将设计BOM汇总出来，然后根据新产生的零部件安排设计任务。
对应电子视图往往是产品结构树的形式，树上每个节点关联各类属性或图形信息。
主要在PDM软件中作为产品管理和图档管理的基础数据出现。
制造BOM——MBOM（ManufacturingBOM）：
生产部门的MBOM是在EBOM的基础上，根据制造装配要求完善的，包括加工零部件JBOM和按工艺要求的毛胚、模具、卡具等PBOM。
也可以称其为工艺BOM。
对应常见文本格式表现形式包括工艺路线表、关键工序汇总表、重要件关键件明细表、自制件明细表、通用件明细表、通用专用工装明细表、设备明细表等等。
制造BOM信息来源一般工艺部门编制工艺卡片上内容，但是要以设计BOM作为基础数据内容。
对应电子视图对产品部件往往装配工艺BOM形式，对零件往往是具体加工工艺BOM形式，比较多的是机加工工艺BOM，或生产加工流转路线工艺BOM等，树上每个节点关联工装、设备、工时、加工简图等等工艺信息。
对企业利用价值比较大的是装配工艺BOM，主要在ERP软件中作为生产计划的基础数据出现。
客户BOM——CBOM（CustomerBOM）：
客户BOM实际上有两个含义，一个指从所有产品机构中筛选出客户订购的产品目录。
一个指用户订购的具体规格产品的明细表。
这个主要是对有些按照客户管理和组织产品图纸的企业非常实用的种表现形式。
这种情况在PDM系统中比较常见，到ERP系统中由于还考虑到不同的客户订购产品对生产计划的影响，情况更加复杂一些，可能还扩展到计划BOM的范畴。
销售BOM——SBOM（SALEBOM）：
销售BOM是按用户要求配置的产品结构部分。
对应常见文本格式表现形式包括基本件明细表、通用件明细表、专用件明细表、选装件明细表、替换件明细表、特殊要求更改通知单等等。
在某些制造行业，对销售BOM提出了更高的要求，要求每个BOM可以跟踪每批订单在全生命周期内的物料信息，而且每个客户订单都有一个唯一的或者是根据订单产品种类多少确定的几个销售BOM。
这个时候往往将销售BOM称为客户BOM。
销售BOM信息来源一般是一个系列产品各规格不同类型零部件明细信息的汇总。
对应电子视图往往是产品配置树的形式，树上每个节点关联各类属性或图形信息。
主要在PDM软件中作为产品配置管理的基础数据出现。
维修BOM——WBOM：
维修服务部门的是按维修要求产生的，对应文本格式包括消耗件清单、备用件清单、易损易耗件清单等等。
维修BOM信息来源一般从设计BOM对应记录属性中筛选获得消耗件、备用件、易损易耗件明细。
一般在PDM软件里完成汇总，同样可以在ERP软件里作为基础数据运用。
采购BOM——CBOM：
是根据生产要求外购的原材料、标准件和成套部件等产生的，对应文本格式主要包括外购件明细表、外协件明细表、自制件明细表和材料明细汇总表。
采购BOM信息来源一般来源于设计图纸和工艺卡片上信息汇总。
由采购部门或生产准备部门根据其安排采购计划和生产计划。
PDM系统一般都可以根据图纸和工艺信息汇总出相应采购BOM信息，但
升级会员 