需求管理规范 (5)
摘要
根据软件能力成熟度模型（CMM）的理论和思想，在软件研发过程中包含多个过程域，软件研发过程改进离不开任何一个过程域的改进。软件的需求管理是这众多个过程域中比较早开始的，是整个软件范围界定的过程，它的成果是软件执行的依据和基础。软件的需求管理是一项复杂而富有经验性的工作，需求管理的成功与否直接关系到项目的成败，需求管理过程的改进在整个软件研发过程改进的作用至关重要。
本文从软件研发过程中的需求管理过程去研究软件研发过程改进中的重要的需求管理改进过程。立足于软件研发过程改进的复杂性七命题，成功为某企业制定了一套优化的需求管理过程规范。
关键词：需求管理过程改进软件研发
Abstract
According to the software Capability Maturity Model (CMM) theory and ideology, in the process of software R & D domain contains more than one process, software process improvement research and development process of any one domain can not be improved. Demand management software, is the relatively large number of domains as early as the beginning of the process is to define the scope of the entire software process, its results are based on software and infrastructure implementation. Demand management software is a complex and rich empirical work, the success of demand management is directly related to the success or failure of projects, demand management to improve the process of research and development throughout the software process improvement is crucial.
In this paper, the process of software R & D management process needs to study the process of software R & D important to improve the demand management to improve the process. Based on the software research and development to improve the complexity of the process of Proposition 7, the success of an enterprise has developed a set of demand management to optimize the process of norms.
Key words: Requirement Management Process Improvement Software R & D
目录
1前言 (4)
2需求管理复杂性分析 (4)
3需求管理策略 (5)
4某某企业需求管理过程规范 (6)
4.1有关的角色及职责 (6)
4.2软件需求管理过程的概貌 (7)
4.3Discover阶段 (8)
4.4Define阶段 (9)
4.5需求维护 (12)
5软件过程改进七命题 (13)
1前言
在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。
2需求管理复杂性分析
软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：
1、需求的描述问题。缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。不同层次的客户(用户)关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。
2、需求的完备程度问题。需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。
3、需求开发的工期问题。在需求上花费了大量的时间，客户、软件公司是否能够忍受?为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已!他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。
4、需求的细致程度问题。需求到底描述到多细，才算可以结束了?仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能
的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家(客户、用户、需求分析人员、设计人员、测试人员)认为描述清楚了，就可以进入设计阶段了。
5、需求的变化问题。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。
需求变化的原因很多，如：
·一开始没有识别全，需要增加需求；
·业务发生了变化，需求必须变化；
·需求错误；
·需求不清楚。
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办?管理它!使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。
3需求管理策略
需求管理需要遵守以下策略：
1、需求一定要与投入有必然的联系。
需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。
2、需求的变更要经过出资者的认可。
需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。笔者曾经经历过一个项目，为了避免项目的风
险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。
3、小的需求变更也要经过正规的需求管理流程。
小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。
4、精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义的越细，越能避免需求的渐变，这是2个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更精致，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。
4某企业需求管理过程规范
4.1有关的角色及职责
角色职责描述
市场人员负责discover阶段所有工作，并帮助开发项目经理和设计师在define 阶段初期很快地了解业务和客户
开发项目经理协调discover阶段的所有活动；与设计师共同完成需求文档；维护scope matrix。
设计师与开发项目经理共同完成需求文档
行业专家提供行业咨询
高层团队指导discover和define阶段的工作
SEPG 负责过程的培训，提供过程支持，负责过程的跟进和改进
4.2软件需求管理过程的概貌
需求可定义为“（正在构建的）系统必须符合的条件或具备的功能”，也有人定义为“用户解决某一问题或达到某一目标所需的软件功能”。
而需求管理是一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。需求管理的目的是在顾客和将处理顾客需求的软件项目组之间建立对顾客需求的共同理解。
需求管理的目标是：
1)使软件需求受控，并建立供软件工程和管理使用的基线。
2)使软件计划、产品和活动与软件需求保持一致。
4.2.1 过程图
Discover阶段Define阶段需求维护阶
段
本阶段的目的是了解客户的问题，分析并确定公司是否开展此行业的项目。这里的客户不一定针对一个企业，有可能是一个行业。在进行具体的调研时，目标是本行业的一个或几个典型用户。市场人员主要对客户的问题，客户的现状，和客户的业务模式三方面进
行了解，然后对照公司的业务发展方向和实际现状进行可行性分析，并负责编写可行性分析报告。
然后发起可行性分析会议，邀请公司高层，行业专家和利益相关者一起来商议公司是否开展此项目。一旦决定做此项目，下来将寻找有意向的用户。找到合适的用户后，就可以正式开始创建开发团队进行开发系统的定义，设计，编码等工作。
(2)Define阶段
目的是得到一套客户认可的详细的需求说明文档，用来指导后期的软件开发工作。开发项目经理和设计师通过与客户沟通交流，分析项目目标和成功因素，识别项目风险和假设，以及系统的功能需求和技术需求，最终整理出一套详细的需求说明文档，包括总体系统的需求信息，每个子系统的需求信息，数据字典，等。
为了指导后期的开发和跟踪需求实现的状态和范围，项目经理需要根据需求来建立本项目的Scope Matrix。在Scope Matrix中随时跟踪每项功能的In或Out，以及现在处于开发的什么阶段。
所有需求文档完成之后，由项目经理和设计师发起并组织阶段审核会议，并邀请客户和行业专家参加。审核的内容包括所有需求文档和Scope Matrix。一旦审核通过，则开始制定下阶段的计划，准备进入概念阶段。
(3)需求维护阶段
目的是管理需求的变更。在软件开发过程中，需求不可避免会有大或小的更改。为了更有效地管理需求的变更，这里规范了需求变更，需求跟踪，和需求配置管理的要求。对每项内容的详细内容，将在后面的章节中介绍。
4.3Discover阶段
4.3.1 过程图
4.3.2 活动
1、理解客户的需求
●活动：与客户沟通交流，了解他们的原始需求。并分析公司开发此项目的业务机
遇，业务目标，客户和市场的需求，以及业务风险等问题。
●职责：由公司高层负责，市场人员具体执行。
2、了解客户的现状
●活动：评估客户的现状，如信息化程度，人员的计算机技能水平，业务模式等。
●职责：由公司高层负责，市场人员具体执行。
3、了解客户的业务模式
●活动：了解客户当前的业务模式，包括业务角色及其关系。
●职责：由公司高层负责，市场人员具体执行。
4、编写可行性分析报告
●活动：根据前面三项内容，对本项目做评估，分析是否开展此项目
●职责：由公司高层负责，市场人员具体执行
●模板：依据提供的“可行性分析报告的模板”整理。根据实际内容，允许对模板
进行裁剪。
5、可行性问题的决策
●活动：审核可行性分析报告的内容；决定是否开展此项目
●参与人：市场人员（发起者和组织者），行业专家，公司高层决策人员。
●主要沟通内容：可行性分析报告
●输出：作出结论的可行性分析报告
●职责：市场人员发起，组织，和主持会议，做会议记录。负责可行性分析报告的
修订和决策记录。
●说明：决定开展此项目后，方可进入define阶段。在进入Define阶段之前，需要
由项目经理和设计师确定项目的整体计划和define阶段的详细计划。
4.4Define阶段
4.4.1 过程图
1、准备
●活动：了解discover阶段的输出文档，安排交流的客户代表
●职责：市场人员帮助开发项目经理和设计师了解可行性分析报告中的内容，并共
同联系客户代表；开发项目经理和设计师理解可行性报告中的相关内容，为后面工作的开展作好准备。
2、分析项目目标和成功因素
●活动：通过与客户的沟通，定义项目目标和成功的关键因素
●职责：开发项目经理和设计师共同完成，市场人员可协助。
3、识别项目的风险和假设
●活动：通过与客户的沟通，识别项目的风险和假定，并分析他们对项目的影响，
给出风险的减缓方法。
●职责：开发项目经理和设计师共同完成，市场人员可协助。
4、获取功能需求和技术需求
●活动：通过与客户的沟通，获取功能需求和技术需求，即明确系统的功能需求和
使用什么样的技术
●职责：开发项目经理和设计师共同完成，市场人员可协助。
5、编写需求说明文档
●活动：根据前面几个步骤的沟通结果，整理项目的需求文档。需求文档不一定是
一个，可以是几个文档。但必须包括内容：总体系统的需求信息，每个子系统的需求
信息，数据字典。公司建议将总体系统的需求信息与每个子系统的需求信息分开写成文档。在总体系统的需求中，从系统整体出发来阐述，而每个子系统的需求只针对子系统本身来阐述。
●职责：开发项目经理和设计市共同完成。
●模板：依据提供的“总体系统的需求说明模板”“子系统的需求说明模板”“数
据字典的模板”整理。根据实际内容，允许对模板进行裁剪。
●高质量的需求说明文档的关键特点：
●完整：不应该遗漏要求和必需的信息。发现缺少的信息很难，因为根本不存在。
如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。
●一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生
冲突。
●可修改性：每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清
晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。
6、建立Scope Matrix
●活动：根据系统的需求建立Scope Matrix，以指导后期的开发。Scope Matrix的
所有内容必须忠实于整理出来的需求文档。如果需求文档的内容不足以得到完整细致的Scope Matrix，可以回过头来完善需求文档；如果实在确定不下来的内容，可以在Scope Matrix中标注出来，待以后确定。
●职责：开发项目经理和设计市共同完成。
●模板：依据提供的“Scope matrix的模板”整理。根据实际内容。
●如何在Scope matrix中描述功能域：
7、Define阶段的审核
●活动：以会议的形式沟通需求的内容，对需求进行Quality review.
●参与人：项目经理（发起者和组织者），设计师，行业专家，和客户
●审核内容：数据字典，总体系统的需求说明，各子系统的需求说明，Scope
matrix
●输出：Review notes。Review notes要求填写在公司规定的Quality review notes
的模板中。
●职责：
●设计师发起，组织，并主持审核会议，做会议记录。会后总结review notes.
●开发项目经理。与设计师共同完成审核工作。
●说明：Define阶段审核通过后，方可进入设计阶段。
4.5需求维护
需求维护的关键内容是需求变更管理。需求的变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。对于需求变更的管理，我们主要使用需求变更控制流程，需求跟踪矩阵，和需求配置的管理方式。
4.5.1 变更控制
2、变更审核小组
●成员组成：项目经理，设计师，和客户代表
●职责：处理每一份需求更改申请单
3、变更申请单
变更申请单的模板请参见“需求更改单模板”文件。本模板包含两部分内容，第一部分是更改申请的信息，第二部分是审核小组的分析和决策信息（包括他们的签字）。
需求更改的提出者可以是客户，也可以是开发团队的任何人。
4.5.2 需求跟踪
●活动：使用scope matrix来跟踪每项需求是否要求实现，以及需求实现的状态
●职责：由开发项目经理负责维护scope matrix。
4.5.3 需求配置管理
●活动：保存需求方面的所有文档的所有版本
●职责：每个有关需求的文档以及升级文档均要求保存到CVS。
●要求：所有资料均放入CVS。按照规定的目录存放资料。现有两个：Client和
Requirement目录。文件的每个修改版本都要求保存。
5软件过程改进七命题
1、成熟度命题：需要不断地组织学习以持续地改进全组织的软件支持过程能力。
2、效果命题：需要明确地努力和定期地强化其效果。
3、领导命题：需要高层领导的发起、参与和支持。
4、过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提高群体认知活动的效力和效率。
5、文档命题：需要文档（解释和沟通）支持过程活动可视化，使得复杂的智力密集的支持过程活动得到有效地控制。
6、团队命题：需要全体人员的协作和努力。
7、投资命题：需要计划，配备专职人员以及管理时间和资金投入。
如果与软件开发过程复杂性五命题相比较可以发现增加了领导、团队和投资三命题。要注意效果命题主要关心软件支持过程改进，而领导、团队和投资特指软件过程改进。其中原来的地图原理由过程命题和文档命题所代替，同时，也说明了软件过程改进复杂性工作程序四个过程的必要性。
Watts S. Humphrey认为软件过程改进的关键在于：（1）为改变软件过程，需要有人为此工作（领导命题、团队命题和投资命题）；（2）无计划的过程改进只是一相情愿（过程命题和文档命题）；（3）自动化差的已定义过程将产生差的已定义结果（能力命题）；（4）改进应该以小的、可测试的步骤进行（能力命题、效果命题和投资命题）；（4）培训、培训再培训（能力命题和投资命题）。
如上企业的需求管理过程规范模型中，立足于过程改进，从软件研发过程改进的复杂性七命题出发，从人员、计划、自动化性、细化和培训等多个方面对需求管理过程进行规范，
并制定相应可执行的措施，并且每条措施都描述了严格的活动、职责、要求等详细规范。
参考文献
［1］韩万江.姜立新，软件开发项目管理［M］.北京：机械工业出版社，2004
［2］何新贵.软件能力成熟度模型［M］. 北京：清华大学出版社,2001:167－169.
［3］杨一平.软件能力成熟度模型CMM方法及应用［M］.北京：人民邮电出版社，2001
［4］王永贵. 产品开发与管理［M］.北京：清华大学出版社，2007-6
［5］丁兴良林俊黎燕. 项目流程管理[M]. 北京：经济管理出版社，2008
［6］舒冠成. 流程管理（第3版）[M].北京：北京大学出版社， 2008-06年
中国财务及企业管理软件用户需求调查
中国财务及企业管理软件用户需求调查 【行业分类】计算机软件【地区分类】中国【时间分类】 【文献出处】计算机世界 【标题】中国财务及企业管理软件用户需求调查（2000 年文献）（8918 字） 【副标题】<<计算机世界>>市场研究中心 【正文】 一目前使用财务及管理软件的情况 客户目前拥有财务及管理软件的情况如表1所示。由表中可以看到，80%以上的受访者单 位目前已经在使用财务软件或者管理软件，其中使用了财务软件的占7 5%, 使用了管理软件的 约占30%,财务软件的普及率已经很高，管理软件的拥有率也正在逐步上升，使用财务及管理软件在各个单位中已经不是什么新鲜的事情了。 在尚未拥有这两类软件的单位中，大约2/3目前正在考虑采购，无采购意向的占1/3。从总体来看，不拥有这两类软件、同时也未考虑采购的仅占6.56%，也就是说，绝大多数的单位或者已经在使用财务及管理软件，或者正在考虑购买的问题，这两类软件在各单位中基本已经达到了完全覆盖的程度。 在拥有财务及管理软件的单位中，用户对于目前使用的财务及管理软件态度不太一致，对财务软件的满意度高于对管理软件的满意度。 对财务软件表示满意的客户约占60%，表示不满意的占17%。尽管从总体倾向性上看，表示满意的客户比率大大高于表示不满意的客户比率，但考虑到财务软件的发展已有十几年时间，财务软件市场的竞争又十分激烈，有17%的客户表示不满意已是一个比较高的比例了。这部分客户的软件提供商需要注意，如不能充分满足客户的需要，就有被淘汰出市场的可能性。 对管理软件表示满意的比例仅为38%，而表示不满意的则占28%，用户的满意度明显低于财务软件的情况。管理软件的应用环境比财务软件更复杂，而在国内的发展与应用时间也不及财务软件长，所以用户满意度较低也是正常的。但管理软件上的竞争正在日益加剧，有关开发商应当多了解客户的要求，追求更高的满意程度。 财务及管理软件更新换代的速度非常快，在目前拥有财务或管理软件的受访者中，有3/4 表示在未来一年内可能升级或者更换现有的软件。虽然由于样本量的限制，这一比例并不代表所 有财务及管理软件用户升级或者更换的程度，但也可以看出，财务及管理软件的市场机会是非常多的。虽然目前一些大厂商的市场份额非常大，市场已经被瓜分殆尽，但由于每年都有大量的老客户要升级或更换原有软件，如果新厂商能够进行有效的渗透，与大厂商争夺老客户仍然是有可能的。 从老牌厂商的角度来说，大量老客户升级或更新软件既是自己的新的业务机会，也是不可忽 视的市场重组的威胁，在积极发展新客户的同时，做好老客户的工作同样重要。有关的研究结果表明，开拓新客户的单位成本远远高于维护老客户的单位成本，对于已经拥有庞大客户群的老牌 软件厂商来说，把精力更多地放在维护老客户上，可能会是更为有效的维持市场份额的手段。 二客户对财务及管理软件的功能及服务诉求 计算机的应用范围非常广泛，从管理角度使用计算机也已经是比较成熟的技术。从客户所反 映的情况来看，目前各单位对于计算机在管理领域中的应用仍主要集中于财务方面，其中财务管 理和财务控制是各单位最希望利用计算机实现的管理职能，在相当多的企业中，仍然只有财务软件，而无其他管理软件。 我国的管理软件发展从财务软件开始，正是源于这样一种需求。计算机在财务领域中的应用，解放了广大的财务人员，也大大促进了各单位财务的规范化管理。但与此同时，我们可以看到，除了财务部门这样一个传统的与数字相关的部门外，在各类单位中，管理的计算机化水平还非常 低，利用计算机辅助管理的观念还非常薄弱。仍然有不少人认为计算机就是计算用的工具，只能用于算账，而没有认识到计算机在信息整理、决策支持等方面的强大能力。 除了财务领域之外，各单位最希望利用计算机实现的管理职能主要为人力资源管理、销售管 理和客户档案管理，这些领域应当成为未来管理软件应用的最重要的方面。同时，各管理软件厂 商还应当进行更多的宣传推广活动，帮助客户了解计算机在其他领域中的应用，并提供更简便易 行的解决方案，以促进管理软件市场的发展。
产品管理规范
产品管理规范 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
产品管理规范 公司管理体系文件编号： 产品管理规范版号： 页码：共21页 编制：日期： 审核：日期： 批准：日期： 1 目的 实现以市场为导向的产品规划，有计划有组织地进行研究与产品开发活动。 有效地调动营销部门以及生产部门的创造性思维，把市场与消费者的认识转换在新产品中，确保产品开发和企业产品战略的一致性，快速、合理应对市场需求，规避产品投资风险，并为企业获得最大限度的利润。 2 范围 本制度适用于本公司产品开发、上线、管理全过程，对产品管理的流程做出规定，是公司管理产品规划工作的依据，各相关营销、生产部门必须遵照执行。 3 职责 产品管理是企业在产品生命周期中对产品规划、开发、生产、运营和支持等环节进行管理的业务活动，包括需求管理、市场管理以及开发管理 4 内容 具体如下： 产品战略规划
产品战略包含：1 产品路线 2 产品策略 3 产品计划 产品研发 产品研发包含：1 需求阶段 2 设计阶段 3 开发阶段 4 测试阶段 5 发布阶段（上线） 产品生命周期 产品生命周期包含：周期管理（1 导入期 2 成长期 3 成熟期 4 衰退期）组织、主要人员及职责 1组织结构 2重要角色 重要角色负责人：产品负责人、研发负责人、产品管理负责人、运营负 责人。 重要角色包括：产品经理（需求提出人）、需求管理员、技术人员、运 营人员。 3其中对重要角色职责及相关要求定义如下： 产品管理会 产品管理会由产品中心、运营中心、产品研发中心总监以及参与在产品生命周期过程中的产品规划经理、用户研究人员、产品负责人、开发负责人、运营负责人等共同组成。 主要职责： （1）制定运营计划，确定运营目标； （2）优化产品，制定运营策略； （3）监控产品质量，把控经营结果；
需求管理规范V
密级：内部公开 文档编号：SL_RD_XQGLGF 需求管理规范 ------------------------------------------------------------------- XXX科技公司对本文件资料享受着作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
目录
1.目的 为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前 期获得有效的输入，特制订本规范。 2．范围 本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。 3．术语 4.部门/角色与职责
5.内容 5.1流程图 图1需求开发与管理过程活动示意图
5.2主要活动 需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。 （需求的收集和整理） 产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。 （这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。） 产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。 除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。 其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。 根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。 产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。 （需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。） 需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。 UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。 在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。 需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求的评审 应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审
《产品需求管理》
●理解产品包需求（OR，Offering Requirements）的概念、产品包需求分层、需求工 程方法论 ●如何与其他部门协作采集高价值的用户需求、掌握需求的变化 ●掌握如何用模板和工具来参与并指导相关部门识别、采集高价值的用户需求 ●如何透过需求描述的表象得到的顾客效用与价值，即掌握顾客的心声 ●基于培训和讨论、整理出需求调研访谈指南 ●掌握筛选、解释需求的工具，评审分析市场需求的价值 ●学习如何有效的激励其他部门配合，让需求管理流程形成一个快速畅通的闭环 ●分享讲师在著名企业产品开发、研发管理实践经验和十多年的咨询/培训经验，并 通过现场的互动和全方位案例资料（如：流程、模板、查检表等）的展示帮助学员“学以致用”，理清适合自己企业在产品需求管理方面的工作思路以及具体的实践方法和工具。 客户的需求不断变化，如何快速高效地推出满足客户需求、具有差异化优势和竞争优势的产品，并最终获得市场的成功，是企业的核心问题！我们发现国内许多科技型企业在产品需求管理方面存在如下问题： 1. 产品开发没有实现市场驱动，是“闭门造车”，关注技术而不关心客户；产品开发出 来后才找客户、找卖点； 2. 缺乏完备的需求收集、汇总、整理和分析机制，导致研发和市场脱节，需求无法有 效传递和落实，相关环节和部门（如：客户、市场部、开发部、测试部等）对需求 的理解也不一致，经常针对需求“吵成一锅粥”； 3. 对客户/市场需求分析不充分、不透彻、不完整，导致产品需求变化频繁，产品开发 大量返工，“计划不如变化快”，开发过程“失控”； 4. 需求管理各个阶段的职责不清晰，也缺乏组织支撑；往往了解市场的不懂技术，懂 技术的不了解市场，不知道需求应该由谁负责；
咨询业客户的需求分析
咨询业客户的需求分析 同行经常一起谈论并由衷地感慨：现在培训咨询行业太难做了，主要的问题便是竞争激烈。笔者认为竞争的核心问题便是看看谁可以更加准确、快速、持久地满足客户需求。 客户的需求究竟是什么呢？ 第一个类型的客户需求：因为客户自己非常清楚，而且拥有经验，他们其实并不是非常需要培训咨询公司来协助的。 第二个类型的客户需求：客户从来没有尝试过的工作，但是他们自己拥有做好的能力，这样的客户需求，会在培训和咨询公司的支持下，慢慢地自己做起来，这种需求也不长久。 第三个类型的客户需求：客户明白这些工作非常需要，但是自己没有足够的人力物力来做，必须要请培训咨询公司来协助，这种需求比较长久。 第四个类型的客户需求：客户自己没有想到，而且自己的实力也不足以支持这些工作。 第一个需求所有培训咨询公司都会退避三舍；第二、三个需求便是很多培训咨询公司的核心竞争力体现。 第四个需求往往会被忽略，因为客户和培训咨询公司恐怕都无法找到的，也就谈不上共同合作。 上海诺曼通企业管理有限公司作为培训咨询行业的后起之秀，我们未来的核心竞争力，将会在满足客户的第四种需求上不遗余力。具体说，在两个方面加强我们的实力。世界咨询师(培训师) https://www.360docs.net/doc/ad9071470.html, 第一、客户需求的盲点。①身心建设。②代沟弥补。③④低端普及⑤高端提升⑥其他。 第二、客户需求的弱点。①体系建设。②手段丰富。③时效结合。④横向交流。 ⑤效果固化⑥其他。
谈及了盲点，我们再分析一下弱点。
除了以上设想和工作手段，我们可以清晰的认知培训咨询公司的核心价值。那就是三维视角和动力的法则
文章标题: 管理咨询培训行业的发展趋势 引用网址: https://www.360docs.net/doc/ad9071470.html,/management-consulting-training-21601-1.html
需求管理规范
目录 2 1.前言......................................................................................................................... 3 2.需求管理背景......................................................................................................... 3 3.需求管理流程......................................................................................................... 4 4.指导规范................................................................................................................. 6 5.需求管理体系......................................................................................................... 6 5.1.制度 .............................................................................................................. 7（一）总则 .............................................................................................................. 7（二）机构职责 ...................................................................................................... （三）总体工作流程 ............................................................................................ 10 10（四）需求提出 .................................................................................................... 10（五）需求分析 .................................................................................................... 11（六）需求评审 .................................................................................................... 12（七）需求跟踪 .................................................................................................... 12（八）需求实现 .................................................................................................... 12（九）附则 ............................................................................................................ 13 5.2.细则 ............................................................................................................ 13 5.3.流程图 ........................................................................................................ 14 5.4.评审细则 .................................................................................................... 15 5.5.模板 ............................................................................................................ 5.6.编写指南 .................................................................................................... 16 16 6.合理性评价...........................................................................................................
化妆品行业客户关系管理分析报告
化 妆 品 行 业 C R M 分 析 报 告 小组：5与伦比 成员：李倩倩、许艳青、杜倩杰、闫韩东、田晓伟、孙圳
CRM（Customer Relationship Management）即客户关系管理。是指企业用CRM技术来管理与客户之间的关系。在不同场合下，CRM可能是一个管理学术语，可能是一个软件系统，通常所指的CRM，指用计算机自动化分析销售、市场营销、客户服务以及应等流程的软件系统。它的目标是缩减销售周期和销售成本、增加收入、寻找扩展业务所需的新的市场和渠道以及提高客户的价值、满意度、赢利性和忠实度。CRM项目的实施可以分为3步，即应用业务集成，业务数据分析和决策执行。CRM是选择和管理有价值客户及其关系的一种商业策略，CRM要求以客户为中心的企业文化来支持有效的市场营销、销售与服务流程。
1.妮维雅CRM分析……….……………………..………………..（4 ） 2.温碧泉CRM分析….……….……………………………………..（7 ） 3.宝洁CRM分析 (10) 4.欧莱雅CRM分析 (14) 5.佰草集CRM分析 (17) 6.自然堂CRM分析 (21) 综合分析 (24)
妮维雅 一．调查地点 郑州北大学城英才街妮维雅专柜（包括商场里的专柜） 调查时间 9月25号下午2点pm 调查人： 5与伦比小组全体成员 二.介绍 妮维雅（NIVEA），NIVEA灵感来自拉丁语niveus, -a, -um（雪白之意）。是一个由德国公司Beiersdorf所有的、大型全球性护肤品与身体护理品品牌。1911年Beiersdorf研发了，拥有Eucerit的油基乳剂皮肤软膏后成立该公司，该乳剂为同类第一种稳定的乳剂。30年代期间Beiersdorf开始生产防晒油、剃须膏、洗发水及面部护理产品。"NIVEA"商标在第二次世界大战后被很多国家没收，Beiersdorf最终于1997年购回所有商标权。2003年8月美国商业周刊杂志公布的最新全球100个最有价值品牌排行榜上，妮维雅品牌名列第92位。作为品牌百强的公司；它CRM的发展引起了人们的注意，人们迫切的想了解它的
业务需求管理制度
业务需求管理制度 第一条总则 规范各部门有关业务需求的提出、变更及维护，为整体业务系统建立统一的需求管理机制和跟踪机制，从而提高沟通效率及需求反馈的响应速度和透明度，保障产品开发结果与需求的一致性，特制定本细则。 第二条适用范围 本规定适用于管理所有业务部门提交到本部的所有需求。 第三条定义 1、业务需求：对需要在整体业务系统中实现或调整的业务功能的说明或描述； 2、业务需求方：为公司整体业务系统提出所要实现或调整功能的部门，包括无线运营部、销售服务部和财务结算部等； 3、业务需求承接方：负责承接业务需求，目前由产品技术部的产品专员对接各部门的需求。 第四条需求的重要程度 需求部门所需功能对整体业务系统的影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。 a)非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节； b)重要：业务系统所需的该项功能对整体业务系统影响大； 页脚内容1
c)一般：业务系统所需的该项功能对整体业务系统影响一般，如页面显示文字、字体、颜色等。第五条需求的紧急程度 需求部门所需功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非常紧急为最高级别。 a)非常紧急：所提业务需求非常急迫，如不尽快实现，关键业务流程不能被正确执行、且无可替代措施； b)紧急：所提业务需求比较急迫，如不尽快实现，业务流程不能被正确执行，但存在可替代措施或方法； c)一般：所提业务需求急迫性一般，不会对现有流程存在较大影响。 第六条需求提交 各部门通过JIRA填写详细需求信息，向需求承接方发起需求任务，在需求提出时需注意以下几个方面： 1、详细描述需求背景、需求内容，包含需求介绍、功能性需求详细描述及数据需求描述，明确本部门需求对接人； 2、提出需求时应说明需求的重要程度和紧急程度； 3、提出需求时应认真考虑业务需求的合理性、完整性和前瞻性，充分考虑各种流程、各个环节以及异常流程的处理； 4、为更加清楚地说明业务需求变更情况，可附带附件、附图等文档。 第七条需求分析 1、需求承接方就接受到的需求进行需求分析，需求不明确的地方与需求方及时进行沟通，并在 页脚内容2
产品需求分析管理和产品规划培训课程
产品需求分析管理和产品规划培训课程 课程背景 营销大师科特勒指出：“以市场为导向、以客户为中心”就是对市场需求的管理！市场需求管理是公司战略、市场计划、新产品开发的依据，决定了公司竞争力的延续，直接影响到公司效益。 但是：“有价值的客户需求在哪里，对有价值的需求如何进行汇总、分析。”目前大量的理论体系到此为止，如何在实际的操作层面上进行下去？如何执行？根据权威机构统计：项目缺陷的56％来源于需求定义错误，80％的缺陷修复成本用于修复需求导致的错误，需求的正确与否直接影响产品开发周期、产品开发成本，甚至直接决定产品最终的市场成败。 通过和众多国内科技企业接触，我们发现这些企业中普遍存在如下问题： 1.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”； 2.产品开发过程需求工作持续时间短，需求分析不充分；需求没有有效地分层分级，对不同阶段需求应该详细到什么程度没有明确的定义； 3.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解一致性； 4.产品开发闭门造车，关注技术，不关注客户； 5.产品开发出来才找客户、找卖点； 6.不清楚业界众多需求分析工具如何在不同需求分析阶段进行恰当运用等； 本课程结合以上企业在市场需求管理中存在的问题进行深入的探讨，结合多年企业的实践和研发管理咨询的案例，就企业在市场需求的收集、整理、归类、分析、分解与分配、执行与验证等环节的问题展开深入的讲解，并分享大量企业的案例。 课程特色 课程的实践性：讲师从事过市场需求管理的工作多年，同时完成过近10个咨询项目，通过大量的案例和演练，让学员非常便于理解；具体的操作方法和工具：课程涉及的市场需求分析和市场需求管理的方法和工具十分具体，操作性非常强；讲师独特的专业背景：讲师都是从研发做起，在知名企业担任研发中高层领导，并且在成功的企业有成功的实践经验。 培训收益 1.了解研发需求工程过程与其他研发流程体系的接口关系； 2.掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 3.掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 4.掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 5.掌握对产品包需求进行分解和分配，确保需求与设计协同一致，减少模块间耦合的方法； 6.掌握对客户需求、产品包需求、设计需求进行持续验证和跟踪的机制和方法； 7.掌握构建需求收集长效机制，提升公司整体需求管理能力的机制和方法； 8.掌握支撑研发需求工程各个阶段工作运作的工具和操作方法。 课程大纲 一、例分析：某案例公司市场之路
创业市场环境及顾客需求分析
创业市场环境及顾客需求分析经济环境 随着生活水平的不断提高，居民消费意识逐渐提升，更注重精神型、享受型消费。而鲜花作为一种情感消费的载体也越来越受人们的欢迎。不管是生日、聚会、典礼、祭祀等，送鲜花都是永不过时的情感表达方式。 2社会文化环境 在中华民族历史悠久的古老文化中，鲜花是一种美好的象征。例如男女之间通常以玫瑰表达爱意，而康乃馨则代表了对母亲的感恩，菊花则成了清高和隐士的代名词。人们也习惯用鲜花来传达情感。 3行业环境 这几年，中国鲜花速递行业可以说是暗潮汹涌，竞争激烈。每年都会有一批新的鲜花速递网站诞生，这其中多数是传统零售花店的经营者，挤入鲜花速递网站的行列来掘金。据了解，目前我国鲜花速递网站有中国鲜花礼品网、莎啦啦鲜花网、七彩鲜花网、中礼鲜花网、爱尚鲜花网、维纳斯鲜花网、花集网、588鲜花礼品网、花之盟、贝蕾丝鲜花网等。 因鲜花网站的运营与传统花店经营存在极大的差异，经营者网站经营能力的经验缺乏，势必导致运营成本偏高，高价不合理
的参与广告投入竞争，低价血拼以期获取订单。这些让整个行业的竞争变得无序可依，但经济杠杆终将平衡参与者的市场行为，现状是这些新进的网站多则一年、少则两三个月以后就从公众的视线中消失，最终一直能稳定经营和发展下去的，还是上述寥寥数家鲜花速递网站。 4竞争对手分析 银川市经营花店的商户很多，其中网上经营鲜花的也有很多已经发展到一定规模，有一定的知名度和顾客群。家花卉实体店拥有专业的园艺技师，对花卉的掌握及相关园艺知识均有大量工作经验。多数早期经营花卉的实体店面拥有良好的地理优势，其品牌知名度高，拥有固定的客户源。对花卉的保养及培育方面，多家实体花店拥有较多的经验，能够有效控制花卉的订货批量和次数。在供应商的合作当中，其拥有与花卉供应商的长期合作关系，较为一致的合作共赢目标。在现代物流配送方面，采用保鲜式物流配送货车，保障鲜花的新鲜度。 顾客需求分析 消费者购买的需求主要有一下几个方面 、节日鲜花： 情人节鲜花:当代众多的年轻人、都市白领追求时尚与浪漫，在情人节之际更是凸显无疑，依据年轻人的心理，在情人节这个独特的节日里，鲜花需求量较大。
需求管理规范 (2)
需求管理体系改进方法研究 需求管理过程 当软件开发完成需求开发工作之后，不可避免地会遇到软件需求的变更。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。需求管理的主要工作如下： 1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。 2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。 3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。 4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。 5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。 6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。 7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。 8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）
XXXX-需求管理规范V1.1
密级：内部公开 文档编号：SL _RD_XQGLGF 需求管理规范 编制：XX生效日期：2018-03-09 审核：XXX批准： ------------------------------------------------------------------- XXX科技公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
2017-07-21 0.1 创建XX XXX
目录 1.目的.............................................................................................................................. - 3 -2．范围........................................................................................................................................ - 3 -3．术语........................................................................................................................................ - 3 - 4. 部门/角色与职责.................................................................................................................... - 3 - 5. 内容......................................................................................................................................... - 4 -5.1 流程图................................................................................................................................. - 4 -5.2 主要活动............................................................................................................................. - 5 - 5.2.1需求获取（需求的收集和整理）..................................................................... - 5 - 5.2.2需求分析............................................................................................................. - 5 - 5.2.3需求定义............................................................................................................. - 5 - 5.2.4需求的确认......................................................................................................... - 6 - 5.2.5需求的实现......................................................................................................... - 7 - 5.2.6需求的测试......................................................................................................... - 7 - 5.2.7需求跟踪............................................................................................................. - 7 - 5.2.8 需求变更............................................................................................................ - 7 - 6.相关附件、表单....................................................................................................................... - 8 -
产品需求开发管理规范
产品需求开发管理规范 为规范需求管理流程，特制定本规范。请相关岗位人员参考执行，以提高沟 通效率，降低项目风险。 0 流程图 需求处理流程 产品业务客户技术测试与售后阶段 沟通处理需求提出需求收集需求问题反馈整理分析需求需求设计 （原型）接收反馈客户打回/接收 需求评审需求文档编写通过不通过需求评估开发排期确认不通过 通过 功能开发单元测试 功能测试性能测试确认验收 发布使用商务沟通 收费功能 上线检测 涉及部门/岗位人员类型说明： 客户：包括已经购买或潜在客户，及终端用户。 业务：是指销售、代理商或其他一线与客户接触的工作人员。 产品：产品规划设计人员。 技术：技术经理、开发工程师、设计师（UE\UI ）等人员。 测试：测试经理、测试工程师等。 售后：售后服务人员，包括热线电话或在线客服等。
需求收集一般分为两种途径，一线业务人员（销售或代理商）与售后服务部。需求收集后需要提交至产品部进行需求分析，根据具体情况给出需求处理结果，如果需求存在异议产品人员可以与客户联系沟通确认清楚。在此过程中产品人员应该根据客户所处的商务阶段（如有合同条款）判断是否需要另行收费，技术人员需要配合产品评估大致工时，以确定收费金额。 在此过程中可能存在需求打回的情况，需要产品人员给出分析结果并与相关人员沟通确认。在确定打回后业务人员应积极配合沟通客户，以确保客户满意度。无论是打回还是受理都需要向客户反馈情况。 输入：需求收集表（根据具体情况可能包含可行性分析，或与产品一起提出）、需求检测工单 输出：需求跟踪表 参与人：业务、售后、产品 2原型设计 原型设计是产品人员根据所确定的需求进行功能设计的过程，用相应方法能完整的展示传递功能、交互、验证等信息。可以用word、Excel、PPT等方式进行描述，最好是使用Axure。 输入：需求跟踪表 输出：功能原型（rp文件） 参与人：产品
汽车零部件行业需求分析及解决方案(精品)[详细]
汽车零部件行业需求分析及解决方案 1、行业总体需求分析 (1)与主机厂计划保持协同,适应主机厂频繁的需求变化 汽车零部件制造厂的生产一般要按整车厂的生产计划,同时考虑整车厂的配件需求、市场的配件需求而制订,由于市场变化莫测,而整车厂一般又采用准时供货制,因此很难保证计划的稳定性,这必将对整个物流的计划和采购带来很大的不确定.因此如何在生产及采购计划上与整车厂商保持更好的协同将是ABC有限公司管理上必须重点考虑的问题. (2)提高“准时制供货”能力 目前,整车厂普遍采用“准时制供货”的供货方式,供应商根据客户的需要作时间安排,提前一小时或数小时将产品送达生产线供装配使用.另一方面,整车厂的要求也十分严格,如果导致整车厂的生产线停顿,供应商便要支付违约赔偿.其实,无法按时供货衍生的问题远远不只赔偿违约金.很多情况下,一旦出现生产线停顿,客户的信誉将会受到影响,竞争对手也会乘虚而入,使企业失去商业机会.为达到“按时交付”,供应商一般在客户工厂或周边(一般3英里范围之内)租用库房,使货物可预先运到仓库,让客户根据需求随时取用.不过,由于对信息传递的不及时,以及对市场变化的估计不准确,为了保证货物的及时供应,必须保留较高的库存,这就可能造成不必要的资金浪费.因此,如何既能保证按时交付,又可避免库存积压风险将是“准时制供货”不可回避的难题之一. (3)强化成本控制,从容应对主机厂降低成本要求 成本作为构成企业核心竞争力的关键要素之一,素来为制造企业所密切关注.如何降低成本,也一直是汽车零部件企业不断追求的目标,特别是在整车厂迫于竞争压力而不断压低采购成本的今天,在成本上领先(那怕是细微的领先)更是汽车零部件企业梦寐以求的目标.因此,对零部件供应商而言,如何准确、及时地把握产品的生产成本并找到改善的关键将是管理中需要重点解决的又一难题. (4)保证质量稳定,进行全程质量追踪,提高客户、供应商服务水平 由于消费者对整车在安全及性能方面的要求日益提高,相应地汽车零部件生产商若要确保竞争优势就需要不断地提高质量,并在采购、生产、销售等各环节健全质量控制体系,保证产品质量的稳定.因此,如何保证产品质量的稳定也是ABC有限公司管理中需要引起高度重视的问题. 汽配行业有许多产品属于安全件,如发动机、变速箱、制动器等,因此需对原物料、中间生产过程、及产成品的质量进行跟踪,以便发生异常时可从产成品到半成品、原材料、供应商等进行跟踪追溯,以符合汽车行业质量标准要求.但手工作业情况下往往只能发现问题表面状况,无法有效的追溯来源,很难消除问题的根源. (5)工艺管理和在制品控制 由于汽车零部件工艺复杂,加工工艺路线不确定性,生产过程所需机器设备和工装夹具种类繁多.因此,对在生产线生产中的零部件,从第一道工艺开始到最后一道工艺完成,其间所要经过的时间通常需要数天甚至数周,可是针对制造进度:各道工艺分别已经完成多少数量,差多少数量未完成,还要花多少时间才能完成,以及各道工艺当前在制量为多少,目前进行到哪一道工艺等等信息无法准确及时的得到.经常造成在制品数量过多,在制品帐务不准.如何解决工艺管理及在制品的控制,也是零部件企业管理上不可回避的一大难题. (6)产品数据及设计变更管理 随着汽车消费需求个性化时代的逐步来临,汽车零部件的更新换代也越来越快,零部件厂商不同程度地参与了整车厂商的产品研发与试制,因此,汽车零部件企业在产品数据管理方面也面临着越来越大的压力,稍有疏忽就可能造成严重的损失,而这也是零部件供应商需要在管理中予以重视的环节.
需求管理制度
零壹移动互联 需求管理制度（版，2015年） 修改记录
目录 第一章总则................................................. 错误!未定义书签。第二章职责与分工........................................... 错误!未定义书签。第三章需求总体说明......................................... 错误!未定义书签。第四章需求提交............................................. 错误!未定义书签。第五章需求评估............................................. 错误!未定义书签。第六章需求开发............................................. 错误!未定义书签。第七章系统测试............................................. 错误!未定义书签。第八章需求上线............................................. 错误!未定义书签。第九章生产问题管理......................................... 错误!未定义书签。第十章需求变更控制与管理................................... 错误!未定义书签。第十一章需求进度监控及查询................................. 错误!未定义书签。第十二章附则............................................... 错误!未定义书签。