编号 | 阶段 | 活动 | 活动号 | 活动描述 | 角色 |
1 | 概念阶段 | 概念启动 | PAC-05 | 根据产品路标规划和规划基础活动的成果,产品经理/项目经理对概念启动的可行性进行分析。PAC及相关专家进行产品概念启动评审,给出评审结论。评审通过,则组织成立PDT,开始概念阶段工作。整个评审工作从提交材料到给出评审结论一般不超过6个工作日。
E P1 E! d8 k* Z% @概念启动关键看业务潜力、市场机会及公司的资源和能力;应透彻分析竞争环境与公司的SWOT。
! X3 C. E& ~! i, c+ ~7 j$ l概念启动时LPDT必须参加,如果PDT核心团队已经确定,也可参加;LPDT及PDT团队可以提出评审建议。
2 d- }& _6 h. @. ~6 O主要内容:- q5 D7 P+ C; ~$ \" J; z" u+ Z
● 对产品的关键技术和主要功能的整体描述,包括硬件、软件和服务等;) C. s) V" t3 |" s2 N m5 t
● 对产品的市场定位和指导方针,包括市场机会、品牌或细分市场等;
1 Q3 z3 E$ J4 b● 项目和产品的投资期望,如价格、成本、税前收入、年销售、库存周转、生命周期、项目到计划DCP为止的花费预算及项目总预算等;" |$ q/ p) i2 R3 f
● 项目的时间进度,如各DCP的预计时间;6 b4 Z8 h% y3 S# I: z
● 项目团队的基本组成,如PDT核心组成员等。 | PAC |
2 | 概念阶段 | 组建PDT核心组/确定必要的外围组成员 | PAC-10 | 选择和落实为完成该产品概念阶段任务所需的PDT成员,主要包括PDT经理和核心组成员,SE和POP,及必要的外围组成员。 | PAC |
3 | 概念阶段 | 接受概念阶段任务书、立项通知书 | LPDT-03 | 与PAC沟通,充分理解任务书、立项通知书 ;7 X9 {- K1 P$ p; ?+ V Z& Q
● 与PAC确认PDT核心组和需求分析组等资源到位;
; d( b; v. v% `; p● 将项目任务书发布给PDT成员。 | LPDT |
4 | 概念阶段 | 准备项目环境 | POP-10 | 在财务系统中获得并建立项目会计帐目代码来获取项目支出和实际的花费;获得并保存产品的零部件清单;在合适的信息系统中为PDT成员建立用户ID、权限等;获取合适的IT工具使用许可;建立项目文件、项目模板(WBS 1级)和数据库;和IT一起工作来保证项目操作能被充分支持; 在PDT建立和运行过程中,提供和维护产品数据管理(PDM)配置信息数据,包括项目、资源等。 | POP |
5 | 概念阶段 | 团队培训 | LPDT-04 | 在PDT开始工作前对PDT团队的系统培训,主要包括以下内容:9 M( x/ t$ q* N( M
● 团队建设培训;4 v+ H+ b- p/ q7 B) u% W
● 集成产品开发流程培训,重点是概念阶段流程培训;0 W4 q4 D: p# Z$ |+ h# j
● 业务计划培训; z9 p" R! J. {. i" \& H7 O* }
● 市场需求培训;0 \' d, k2 z6 B- h8 X
● 项目管理培训。 | LPDT |
6 | 概念阶段 | 创建和分发沟通计划 | LPDT-08 | 根据项目任务书和公司项目管理的要求,分析项目相关人员的信息和沟通需求,创建沟通计划,并分发给项目组和相关人员。 | LPDT |
7 | 概念阶段 | 项目开工会 | LPDT-13 | LPDT召集PDT核心组举行的PDT第一次会议,参考议程:
- M" m5 p$ M9 _( k' S, t2 ~% o● 项目目标介绍(LPDT);
' b- F3 }) e+ T' T" J: p● 项目任务书宣读和接受仪式(LPDT);1 _7 R. l& F8 |! v* a* @ G! D+ x
● 宣读PDT核心组任命(LPDT);/ d7 }3 |5 O: v4 w
● PDT核心组成员相互介绍(核心组成员);
! U# ]0 t4 G1 M! r$ J0 _+ D● 概念阶段流程简要介绍(PQA);
: z* t+ F0 V5 E' ?- C● 概念阶段团队成员的角色和职责(PQA);- ~2 _; Z3 U) ?/ h! y- P1 I
● 前期工作回顾(LPDT)(可选,如果有预研阶段的话);
! [( O) K7 s- k, r● 概念阶段交付件介绍(LPDT);# N! r7 c; C \; `* g" g
● 明确概念阶段项目计划、考评和汇报关系、日常沟通方式(LPDT);
/ v, ^( Q: k" A2 l2 L● 团队和个人测评指标及激励机制(LPDT);
2 v$ b' ^$ x' x3 F, }/ ?6 t$ N● 签订资源承诺书(可选);
+ n( L5 Q% X9 c& `% H( T● 领导动员。 | LPDT |
8 | 概念阶段 | 制定概念阶段项目计划 | LPDT-20 | ● LPDT组织PDT核心组成员共同讨论制定项目概念阶段计划(只限于概念阶段活动)(WBS1/2/3/4级)(Work Breakdown Structure,工作分解结构),为概念阶段工作提供指引。! a9 L0 I( X. ^% E
● 依据WBS模板分派工作(LPDT);
2 W% g" b8 ` a, n( B: x0 |9 o制订本业务领域计划,包括时间、成本、约束条件(核心组成员);
6 V4 n; @ {; q9 _# r共同讨论制订计划(核心组成员);
+ \ }* C1 L ^! [/ I计划应分解到可以控制的工作包(核心组成员);
+ Z: U* s4 t0 e8 F+ u' f工作包必须在40小时以内(核心组成员)。 | LPDT |
9 | 概念阶段 | 制定概念阶段项目计划 | FPDT-20 | ● 参与计划的制订,提供数据。 | FPDT |
10 | 概念阶段 | 制定概念阶段项目计划 | RDPDT-20 | ● RDPDT需要对各方面提出的需求进行技术分析,再根据后续流程的需要制定概念阶段的具体工作计划。 | RDPDT |
11 | 概念阶段 | 制定概念阶段项目计划 | CSPDT-20 | ● 针对产品的特性,分析产品的可行性服务计划,对产品可行性服务进行评估;# J$ q" s" M4 d1 u+ r3 ]0 }: x
● 评估的内容包括:现有服务网络的利用能力、建立网络的可行性、服务设备设施的投放能力、服务技术支持的能力、服务基础投入等;
1 L3 j% A4 F( f7 c* Q● 根据分析结果,制定可行性服务计划; | CSPDT |
12 | 概念阶段 | 制定概念阶段项目计划 | MNFPDT-20 | ● 根据项目开工会(LPDT-13)、开工阶段调查表、概念阶段WBS(3/4)级模板,制定制造概念阶段项目计划(WBS1/2/3/4);
, m$ W# C6 a9 y1 P. ]● 制造代表(MNFPDT)通过了解产品的开工会,需要初步评估本部门的生产技术的贮备情况,如有必要,则制定概念阶段项目计划,对有可能进行的项目做人员和技术的初步准备。并知会制造职能经理。 | MNFPDT |
13 | 概念阶段 | 制定概念阶段项目计划 | PROPDT-20 | ● 明确概念阶段涉及采购的部品,主要是主芯片、LCD、Camera、Memory、特殊功能芯片(如回波抵消芯片等);
5 _0 @0 F) I: ]- |. T● 确定收集的供应商范围; | PROPDT |
14 | 概念阶段 | 制定概念阶段项目计划 | MKTPDT-20 | ● 根据从其他市场专家处获得的信息,包括产品销售量、市场基本情况、新市场热点、新技术发展情况等;对新产品的配置、技术、概念等提出建议。 | MKTPDT |
15 | 概念阶段 | 开始监控项目执行 | LPDT-20A | 按照里程碑及关键任务监控项目执行。根据LPDT-20的计划,对整个项目组计划中涉及的活动的质量和进度进行监控。 | LPDT |
16 | 概念阶段 | 开始监控财务活动 | FPDT-25 | 记录项目支出,启动项目费用核算,开始监控项目财务指标。 | FPDT |
17 | 概念阶段 | 开始监控研发活动 | RDPDT-25 | 根据概念阶段项目计划对具体研发活动的执行进行监控,并定期对项目计划进行更新。本工作将贯穿整个概念阶段的开发工作。 | RDPDT |
18 | 概念阶段 | 开始监控技术支援活动 | CSPDT-25 | 按上述计划时间点跟踪,异常及时反馈项目经理。 | CSPDT |
19 | 概念阶段 | 开始监控制造活动 | MNFPDT-25 | 按照项目计划及关键工作列表监控制造部分的工作,并关注与制造相关的其它部分的工作;通过项目成员周总结/PDT双周总结/月报等手段向LPDT、职能部门经理、PAC的职能负责人进行项目的报告及汇报。 | MNFPDT |
20 | 概念阶段 | 开始监控采购活动 | PROPDT-25 | 按上述计划时间点跟踪,如有异常及时反馈项目经理。 | PROPDT |
21 | 概念阶段 | 开始监控市场活动 | MKTPDT-25 | 通过大量信息搜集、数据研究,分析同行或是相关行业厂商行为,特别是那些主要领导型厂商行为。 | MKTPDT |
22 | 概念阶段 | 参与监控研发活动 | SE-02 | 参与监控研发的进度和质量活动。 | SE |
23 | 概念阶段 | 协助监控项目执行 | POP-12 | 按上述计划时间点协助进行跟踪。 | POP |
24 | 概念阶段 | 设定产品目标成本 | FPDT-27 | 根据产品目标价格趋势、PAC对产品目标毛利的要求,确定产品目标成本,并作为产品包需求的一部分,成为方案决策的依据之一。 | FPDT |
25 | 概念阶段 | 制定产品质量目标和计划 | PQA-10 | 根据公司质量方针和策略,结合本产品的质量要求,制定本产品要达到的质量目标,以及为达成这些质量目标所采取的策略和行动的计划。 | PQA |
26 | 概念阶段 | 验证市场需求 | MKTPDT-30 | 依据《产品线规划书》对公司当前的和潜在的客户进行访谈;介绍公司当前的产品;审视竞争前景;确定客户细分;审视客户需求、目前的客户满意度;相对价值的价格;上市时间;服务/保证;迁移计划;整体成本等;根据以下要素确定市场定位:类型、特征、渠道组合、价格、市场份额、客户满意度;确定市场引导区域;确定改进领域;决定概念优化策略。 | MKTPDT |
27 | 概念阶段 | 验证市场需求规格 | MKTPDT-35 | 依据《产品需求包》中的《市场需求》部分对市场需求规格进行验证,确保需求的正确性。 | MKTPDT |
28 | 概念阶段 | 验证可用性需求 | SE-06 | 对《产品需求包》需求列表中有关产品易用性需求的部分通过客户访谈等形式进行验证,并产生《产品需求包》需求中易用性需求部分。 | SE |
29 | 概念阶段 | 参与验证易用性需求 | IDE-10 | 与PDT市场成员一起工作以定义市场需求;与PDT客服成员一起工作以定义安装和可服务性需求;评议和优化市场需求和可服务性需求;设计参照基准;进行基准比较并获取与竞争对手可以竞争的UCD(以用户为中心的设计)信息。 | IDE |
30 | 概念阶段 | 确定是否需要组建Sourcing team | PROPDT-27 | Sourcing team参与制定初始物料/供应商选择计划。这个计划主要用于评估基于PDT提供的新产品,初步设计中涉及的物料的采购风险和预估成本。开发工程师须提供物料/模块的规格信息。其他如市场初步量的需求、项目开发计划、须采购的关键物料清单、供应商选择标准、供应商选择的风险评估与规避计划等都应包括在该计划中。 | PROPDT |
31 | 概念阶段 | 启动供应商认证流程 | PRO-10 | 如果需要,Sourcing team将启动供应商认证流程。 | PRO |
32 | 概念阶段 | 进行知识产权/智力资产分析和评估可选方案 | RDPDT-30 | 检查基于以前项目经验教训的智力资产以防重犯过去的错误;探索能使用在新项目上的内部技术(共用基础模块);评估时间进度、成本和交付的风险;检查概念和技术可申请专利的专利权和法律问题。 | RDPDT |
33 | 概念阶段 | 进行知识产权/智力资产分析和评估可选方案 | SE-05 | 检查基于以前项目经验教训的智力资产以防重犯过去的错误;探索能使用在新项目上的内部技术(共用基础模块);评估时间进度、成本和交付的风险;检查概念和技术可申请专利的专利权和法律问题。 | SE |
34 | 概念阶段 | 探索可选概念和提供技术可选方案 | EE-10 | 协作产生多个概念并检查每一个的优缺点;选择一个概念进行进一步的定义;提出并评估融入概念的产品、元器件、制造工艺等的多种技术选择;研究外部的产品、元器件和工艺(制造)技术;评估项目风险;确定预备技术作为备用;根据项目具体需要,视情况与研发代表和采购代表共同决定:是否需要引入关键供应商参与概念形成过程并参与产品开发。 | EE |
35 | 概念阶段 | 探索可选概念和提供技术可选方案 | ME-10 | 协作产生多个概念并检查每一个的优缺点;选择一个概念进行进一步的定义;提出并评估融入概念的产品、元器件、制造工艺等的多种技术选择;研究外部的产品、元器件和工艺(制造)技术;评估项目风险;确定预备技术作为备用;根据项目具体需要,视情况与研发代表和采购代表共同决定:是否需要引入关键供应商参与概念形成过程并参与产品开发。 | ME |
36 | 概念阶段 | 探索可选概念和提供技术可选方案 | IDE-20 | 协作产生多个概念并检查每一个的优缺点;选择一个概念进行进一步的定义;提出并评估融入概念的产品、元器件、制造工艺等的多种技术选择;研究外部的产品、元器件和工艺(制造)技术;评估项目风险;确定预备技术作为备用;根据项目具体需要,视情况与研发代表和采购代表共同决定:是否需要引入关键供应商参与概念形成过程并参与产品开发。 | IDE |
37 | 概念阶段 | 探索可选概念和提供技术可选方案 | SWE-10 | SWE协助SE根据用户需求探索可选的软件实现方案,评估相关技术风险。 | SWE |
38 | 概念阶段 | 探索可选概念和提供技术可选方案 | TE-15 | TE根据多个技术方案提供相应的测试技术方案,并检查每个的优缺点。 | TE |
39 | 概念阶段 | 定义RAS其他需求 | SE-03 | 提出RAS(Reliability、Availability、Serviceablity可靠性、可用性、可维护性)和其他产品需求,这些需求的提出可以基于公司现有的规范、上一版本产品的缺陷/设计经验等。当存在公司产品间的共享、平台借用时,需要分析其他产品对本产品的需求。 | SE |
40 | 概念阶段 | 定义可制造性/可测试性需求 | AME-15 | 基于以前的经验以及经验数据库的案例,在系统工程师开发产品需求时提供输入以便产品可避免已知道的制造、装配和测试问题。从设计对制造的影响、设计方法论、制造方法论、制造能力、物理布局,是否适应大批量生产等方面考虑可制造性及制造可测试性的需求。具体内容参见模板。 | AME |
41 | 概念阶段 | 定义可测性需求 | TE-10 | 可测试性需求包括软件可测试性需求、硬件可测试性需求。 | TE |
42 | 概念阶段 | 定义可服务性需求 | CSS-10 | 确定可服务性需求,为系统工程师开发产品需求提供输入,按如下方式操作:7 r- \* u0 y$ ?# u" y
● 进行客户访谈,了解客户在安装维护方面的需求;% a$ y L9 e# Y3 D: [. g2 x
● 根据模板进行可服务性需求整理并按照需求对技术支持的重要性进行排序;
# v% {& a1 i3 d ? w2 O● 和需求分析组讨论可服务性需求,就产品准备满足的需求达成初步共识;3 x# d, V5 ~5 }& ?
● PDT小组讨论各部分需求,包括市场(代表客户)、研发、测试、技术支持(可服务性需求)、生产需求满足情况,根据开发进度等多重因素对需求进行分析;" ~: A) @9 y, A
● 所有需求整合成一个需求项目列表,提交SE进行产品需求设计输入。 | CSS |
43 | 概念阶段 | 产生和评估产品包概念并选择概念 | RDPDT-35 | 协助SE选择评价不同软、硬件概念的优缺点,选择一个概念。 | RDPDT |
44 | 概念阶段 | 产生和评估产品包概念并选择概念 | SE-07 | 检查市场需求报告;
( R9 N$ h' \5 [1 L$ C定义概念评价标准和建议;
& [" G( K' U5 g" j2 e定义技术生存能力、准备就绪评价标准;( E7 n) v) M; ?2 j/ n- [
产生多个产品包概念;
% h- g% J" ]7 p* V% F' G% Y. a记录每个概念的优缺点;3 t9 `7 g- ^# [* ]6 K
根据标准对每个概念评价;) r. V2 C2 i4 Q) c+ C* X
选取一个概念。 | SE |
45 | 概念阶段 | 产生和评估产品包概念并选择概念 | EE-12 | 协助SE选择评价不同硬件概念的优缺点,选择一个概念。 | EE |
46 | 概念阶段 | 产生和评估产品包概念并选择概念 | SWE-12 | 协助SE选择评价不同软件概念的优缺点,选择一个概念。 | SWE |
47 | 概念阶段 | 产生和评估产品包概念并选择概念 | ME-12 | 协助SE选择评价不同结构概念的优缺点,选择一个概念。 | ME |
48 | 概念阶段 | 产生和评估产品包概念并选择概念 | IDE-27 | 协助SE选择评价不同工业设计概念的优缺点,选择一个概念。 | IDE |
49 | 概念阶段 | 产生和评估产品包概念并选择概念 | TE-17 | TE对产品包概念确定测试技术的最佳方案。确定新测试工具的需求,明确测试工具可获得性。明确试验局需求;( o1 `7 X* D; l6 f, G
协助SE选择评价不同测试概念的优缺点,选择一个概念。 | TE |
50 | 概念阶段 | 制定标准策略 | SE-09 | 根据概念阶段所能够获得的信息,尽可能分析出与本产品有关的各个标准方面的状态,并与产品设计需求建立对应关系,为计划阶段进行的各产品设计活动(“系统设计和设计规格定义”、“概要设计”等)提供来自标准方面的约束,以保证产品的设计符合有关标准,并为计划阶段进行“制定产品企业标准”活动打基础。 | SE |
51 | 概念阶段 | 定义产品包需求和产品概念 | SE-10 | 将市场需求、可制造性、可服务性、可获得性和功能需求集成为产品需求,它覆盖了与客户接触的所有点,也就是销售、获得、计划、安装、培训、支持、维护、升级、退出等。/ v9 L; z; I Z" B. ~3 |) N
● 集成产品需求包需求:明确包括特征在内的、前期定出的各种优先级;集成地理需求(NLS);集成适用于当前产品包的技术建议;集成智力财产、智力资产建议;集成可服务性需求和建议;确定初步的RAS的质量需求;集成可制造性需求和建议;准备产品需求包需求报告。6 @- d; @% w c
● 定义产品概念:回顾最初的系统架构假设、标准假设、CBB(公共基础模块)/重用目标;定义最初的产品架构假设;回顾产品包需求报告;开发设计需求;定义CBB设计元素;进行硬件元素、软件元素、技术支持和服务元素的初步选择;确定初步的问题定位需求;开发初步的产品包假设;开发高层产品包概念。 | SE |
52 | 概念阶段 | 技术评审1 | SE-20 | TR(技术评审)1是在CDCP(概念决策评审)前针对产品需求包和产品概念的评审。对产品需求包(包括市场需求、可服务性需求、可制造性需求、可采购性需求等)的完整性/完备性/技术的可行性进行评审。评审通过后将需求置于更改控制之下。
- }5 h4 ^! M5 |& q● TR1重点关注产品包需求的完备性以及选择的产品概念是否满足产品包需求。同时,TR1还对产品设计需求的关键点进行评估:
5 L7 @6 W+ I% e8 r. D! j0 q" @ ■ 评估产品设计需求是否充分映射产品包需求; 1 L& z( n/ P4 {$ m( s& P2 W
■ 确保产品包需求的技术可行性以及产品概念的有效性;5 T6 r- m: `) m# u* x
■ 判断本阶段的交付件描述是否明晰而足以指导产品规格的设计。
7 }0 p& `& @& i. w: r● TR1同时关注下列目标:" B$ b: r6 P7 }5 B, B# c
■ 评估产品标准策略;
( @- K- D" d) p3 q# L. @ ■ 评估部件重用计划。 6 k8 ?; u, \2 }: \7 a& i' ^0 P
● TR1通过后需求应被置于更改控制之下。
, A4 E3 E5 } ?; ~# `" |● TR1是针对产品的R级版本进行的。 | SE |
53 | 概念阶段 | 技术评审1 | PQA-20 | TR(技术评审)1是在CDCP(概念决策评审)前针对产品需求包和产品概念的评审。对产品需求包(包括市场需求、可服务性需求、可制造性需求、可采购性需求等)的完整性/完备性/技术的可行性进行评审。评审通过后将需求置于更改控制之下。
( h5 ?- L$ V p9 ~1 ^; N5 z5 c! J( b, V● TR1重点关注产品包需求的完备性以及选择的产品概念是否满足产品包需求。同时,TR1还对产品设计需求的关键点进行评估:4 |$ q1 M/ L6 L: D6 m0 U& q
■ 评估产品设计需求是否充分映射产品包需求;
0 J T$ u; E2 `% s& b: f2 m) t& e ■ 确保产品包需求的技术可行性以及产品概念的有效性;
2 p8 K6 {; g, ?) Z* P ■ 判断本阶段的交付件描述是否明晰而足以指导产品规格的设计。7 F- Y2 n c6 y* K0 j5 {* R& V. b
● TR1同时关注下列目标:( q7 N& b# }0 Y: }* _6 m5 v
■ 评估产品标准策略;5 U3 O- e1 X8 G1 B2 J
■ 评估部件重用计划。 " A* K: A% m, k6 s ?- k8 c
● TR1通过后需求应被置于更改控制之下。 # m' V( z. O- \8 @
● TR1是针对产品的R级版本进行的。 | PQA |
54 | 概念阶段 | 产品需求包基线化 | SE-30 | 根据技术评审1的结果,解决产品需求的相关问题,刷新产品需求,形成需求基线。 | SE |
55 | 概念阶段 | 监控和管理需求更改 | SE-40 | 需求定义之后,仍可能随时间而变化,因为从潜在的客户那里得到了更多的信息;若在出现这些更改时将之包括在产品需求包之中,则项目的目标和完成标准将不断变化,将导致出现不良影响;结构化的需求更改控制将使产品更稳定,因为所有变更被置于控制之下。可以提出需求更改,但它们只能通过一个结构化流程进行更改(交付更改管理)。如果基线化后的需求发生较重大或频繁的变更,SE需要在经验教训总结中进行分析。 | SE |
56 | 概念阶段 | 创建早期BOM (开发过程中更新)提供新器件规格 | SE-35 | 根据对早期产品需求包结构的了解提供一个目标产品粗略的概览。应该自上而下的建立,包括最上层器件、装配件、子装配件。这些信息将用于早期与设计、制造、采购等各个功能部门就产品概念进行的沟通。《系统配置》初稿。 | SE |
57 | 概念阶段 | 制定初始的EC计划 | SE-45 | 是从无到有的工程变更(EC)计划,是为了保证基础记录和技术设计信息能有序而及时地从开发向制造发布。(体现在质量计划中,不单独制定) | SE |
58 | 概念阶段 | 进行总体风险评估 | LPDT-25 | 通过确认各方面的风险,评估其潜在影响,并制定计划以控制风险,缓和风险发生所带来的冲击。 | LPDT |
59 | 概念阶段 | 制定对外合作策略 | LPDT-21 | ● 审阅选定的产品概念和技术路线;
# {. ?; x9 \* k" { h3 A6 b: O0 E● 分析选定的技术路线,确定需对外合作解决的技术:
1 Y/ b, O8 ~' ^7 Z ■ 相关技术在产品中的作用;
; i( H6 s4 |- ^# u5 T ■ 相关技术在公司的现状与业界情况的比较分析;
7 ~5 x2 Z$ |+ }3 r j8 i" O ■ 分析对外合作的原因(解决有无、缩短TTM(产品上市时间)、经济性考虑等)。
8 \* o' z3 x' U, `- a5 A● 依据对产品概念、技术路线和可能的资源状况分析,提出可资源外包解决的技术(人力不足或非公司核心技术可以外包):2 n/ V4 }: Z* c- f
■ 人力不足或非公司核心技术可以外包;
2 [/ H; w. X. r8 F4 T/ P0 g ■ 委托测试等。0 y. v7 n0 r. o9 q! a
● 合作分析:; Q3 g8 S' D7 H. b
■ 工作量估算;' U, e; B, |- m% D5 j
■ 可能的风险及控制方法;
# b' Y' [3 l# O2 c2 }6 S ■ 对外合作项目费用占产品研发费用的比例;. D; e! i3 K( f4 l+ N; L
■ 该项目同时可以对公司其他产品或技术带来何种收益(可能依此分摊费用)。- {# R5 V2 C2 k+ Z2 s# C# Q
● 可能的合作对象(可选,尽量提出以便指导计划阶段),根据具体合作业务的需要,采购代表参与确定可能的合作对象。
8 ?* I. V: z; b● 合作知识产权归属建议,参考《研发外协管理流程》。 | LPDT |
60 | 概念阶段 | 制定信息安全计划 | LPDT-27 | 根据项目的具体特点和公司有关信息安全的规定,决定本产品的信息安全要求和实施计划,确保项目的成果得到有效保护。主要内容包括:产品信息安全要求、产品设计安全计划、文档管理安全计划、组织管理安全计划、工作环境安全计划、变更管理和沟通计划等。 | LPDT |
61 | 概念阶段 | 实施初步的财务评估 | FPDT-30 | 预测所有的产品成本估计,包括:硬件、软件、开发、工具、生产、市场和销售、定单履行、客户服务等;开发收入的估计(基于按区域、渠道的销售预测等);开发收益率估计;项目投资总额、投资报酬率、净现值、内含报酬率等估计。 | FPDT |
62 | 概念阶段 | 准备开发和验证计划 | RDPDT-40 | 制定开发和验证的高层计划,包括主要里程碑、主要活动、资源、进度、开发和验证成本、主要的技术风险等。 | RDPDT |
63 | 概念阶段 | 制定订单履行策略 | FF-10 | 制定一个履行客户订单的策略,包括ESP客户的总体方案(ESP:Early Support Program早期支持程序)—如何生成订单,通过哪个渠道,订单如何被传递、接受、处理、安排计划、构建、交付并在客户现场完成安装;以及如何将订单的状态通知到客户(也包括现场销售及渠道支持人员):电话/传真,web站点,检查表,邮件,电子邮件等。 | FF |
64 | 概念阶段 | 支持制定销售预测 | S-10 | 支持行销人员以按地理、渠道及产品特性等来做出销量预测。 | S |
65 | 概念阶段 | 制定初始的市场计划 | MKTPDT-36 | 进行按区域、渠道等的销售量估计,开发按区域、渠道等进入市场的策略。综合性地描述产品要满足的市场需求和与产品容量及产品组合相关的潜在细分市场(销售预测)和完成销售预测而需要采取的战术性活动,类似产品在何处销售、需要关注的目标市场、如何承受竞争压力等问题都需要详细的描述(市场策略)以及目标市场的竞争对手分析,包括价格和目标用户。 | MKTPDT |
66 | 概念阶段 | 制定制造策略 | MNFPDT-30 | 制订产品生产的高层策略,定义如何以及在哪里制造产品,是否使用外部单位等,包括初始生产产品、量产产品。具体内容参见模板。 | MNFPDT |
67 | 概念阶段 | 制定客户服务策略 | CSPDT-30 | 定义客户服务和支持将如何提供,是否使用第三方或渠道或网站,将提供哪类的支持、在什么区域等,为制定业务计划和建议做准备。* P2 r7 \. D8 d* J7 \1 H" F3 M
● 根据模板,进行策略分解,确认需要考虑哪些方面策略;* E7 Q; h) H" W6 w# N7 D
● 和职能部门领导了解目前的服务和支持策略,听取领导的建议;, C) G$ _; y, N4 s* J, o
● 按照模板,分部份确认工程服务策略,确认维护策略、确认收费服务策略、预估服务成本和收入、预估人力资源需求、其他策略等。 | CSPDT |
68 | 概念阶段 | 制定销售预测 | MKTE-14 | 根据销售专员的反馈,结合市场分析结果,按地理、渠道及产品特性等来做出销量预测。 | MKTE |
69 | 概念阶段 | 制定初始的供应商&物料供应计划 | PROPDT-30 | 确定候选的供应商,确定关键元器件供应商,调查供应商,基于公司供方选择与评价标准选择供应商,跟踪记录、验证供应商等;从供应商处获得关键器件的材料成本预估,进行成本结构分析,选择主要的和候选的供应商。对所用的材料和器件进行ROM (Rough Order of Magnitude,粗略定货数量) 的成本估算;确认关键和独家供应商事宜,包括以下内容,具体内容请参见模板。2 C |( a W5 K+ _
● 制定关键器件供应商选择标准;
$ s, I% Y I4 X5 B5 r8 f+ Z● 制定采购应急计划;
9 B. Z% X* h: P6 j1 D6 M" t; X● 进行采购“合理成本”分析;; ^! p0 T6 ]* ~2 q [! A R
● ROM成本估算。 | PROPDT |
70 | 概念阶段 | 制定业务计划和端到端项目计划(WBS1/2级) | LPDT-30 | 定位产品的市场细分;提供市场/机会分析;提供竞争分析;识别风险、优先级;目标市场和价格;确定在产品概要概念中的技术方法;提供项目投入产出的财务分析,主要涉及研发项目支出预算、产品盈利能力预测等;提出并证实建议;用标准模板准备业务计划,概念DCP前分发给PAC。项目计划和业务计划是概念阶段的关键交付件,用于项目的总体控制和项目风险分析。主要步骤如下:
1 h& J) b+ ]4 w● 制定项目计划-基于模板在LPDT统一把握下,各PDT成员完成各自部分,然后综合讨论确定。
6 R' ~) Y2 N0 w# ~: T. l● 制定业务计划-11个部分分解到PDT各个成员,PDT成员根据前面的输出写作,由LPDT整合汇总。
3 u' A+ C: L+ A% p b* w● 确定主要事件/里程碑。& v% I @" u5 d5 E: k8 N2 }( e
● 工作量评估和资源预估。
* c( u. ?+ o; B● 风险分析管理。 | LPDT |
71 | 概念阶段 | 制定业务计划和端到端项目计划(WBS1/2级) | FPDT-40 | ● 参与制订业务计划和和端到端项目计划。 | FPDT |
72 | 概念阶段 | 制定业务计划和端到端项目计划(WBS1/2级) | RDPDT-50 | 项目计划和业务计划是概念阶段的关键交付件,用于项目的总体控制和项目风险分析,RDPDT参与计划的主要工作内容如下:0 l3 B8 r" p7 ?" O9 G6 _; Z
● 制定开发项目计划:在LPDT指导下基于相关的标准模板,完成开发项目计划,经过综合讨论后形成项目计划。
& S3 u# D/ G- ?; q/ |# O, N5 G) T● 协助LPDT制定业务计划:提交概念阶段的开发业务计划给LPDT。
, N$ |. `1 S# _6 }6 _, l& p) `● 确定产品技术开发过程中的主要事件和里程碑。
7 ?- L, X6 f2 h+ V1 H; ^3 U$ p● 进行开发过程中的工作量评估和资源预估。
) z. \, z4 F+ O8 R7 W/ V● 进行风险分析管理。 | RDPDT |
73 | 概念阶段 | 制定业务计划和端到端项目计划(WBS1/2级) | CSPDT-40 | | CSPDT |
74 | 概念阶段 | 制定业务计划和端到端项目计划(WBS1/2级) | MNFPDT-40 | ● 根据模板参与制定后续生产中和生产相关的关键事件和里程碑。 | MNFPDT |
75 | 概念阶段 | 制定业务计划和端到端项目计划(WBS1/2级) | PROPDT-40 | 识别风险、优先级;提供包括成本分析的财务分析;提出并证实建议;用标准模板准备业务计划,概念DCP前分发给PAC。9 k6 O [ D: H* F9 I6 q7 P
项目计划和业务计划是概念阶段的关键交付件,用于项目的总体控制和项目风险分析。主要步骤如下:
7 ^6 U6 \" B' c) x! N% F● 制定项目计划-基于模板在LPDT统一把握下,各PDT成员完成各自部分,然后综合讨论确定。# l7 Z* G# O5 Q9 l
● 制定业务计划,根据前面的输出写作,由LPDT整合汇总。: x2 B1 ^, H, {( J9 U
● 确定主要事件/里程碑。
( B6 P# o- H) O* a, I; C# Y1 f6 Z● 工作量评估和资源预估。. [: m- p1 v3 C5 n: j4 [9 M& r% ^8 d
● 风险分析管理。 | PROPDT |
76 | 概念阶段 | 制定业务计划和端到端项目计划(WBS1/2级) | MKTPDT-40 | ● 纳入年度项目规划,确定各阶段产品的基本规格、大致上市时间、产品定位、定价和所要达成的市场任务。 | MKTPDT |
77 | 概念阶段 | 与PAC成员充分沟通 | LPDT-40 | 为了提高决策时效率和质量,要保证PAC委员在正式决策评审会前,对业务计划有充分的了解,PDT成员在正式决策评审会前与PAC委员进行充分沟通。建议程序如下:% `; ?; Z8 P- U+ F$ p' |3 Z6 o
● 在决策评审材料提交给PAC成员后的3到4天内,与委员们进行沟通。每次沟通都要有纪要,沟通的内容就是决策评审材料(业务计划和项目计划),沟通后如有必要在业务计划中修改的,在决策评审前修改完成。
. Y# y4 r+ x' c! L& T● 沟通的问题汇总及答复意见在决策评审会议上要进行汇报。 | LPDT |
78 | 概念阶段 | 概念决策评审 | PAC-20 | PAC对PDT提交的《初始业务计划》和建议进行评审,在会上做出该项目继续/终止的决定,并书面通知PDT评审结果。如果决策结果是“继续”,PAC将做出下一阶段开始前所需的承诺,项目就进入计划阶段;如果决策结果是“终止”,立即解散并终止项目。5 d i5 l1 c1 B4 b, y
在初始的业务计划中,PDT将给出如下方面的内容:针对给定目标细分市场存在的机会分析、目标客户群、拟开发的产品描述、成本及风险估计、初始销量预测及初始财务评估。$ w1 a H% _& a7 p0 T6 q4 t
概念阶段的财务估算按V版本进行,包括V版本的第一个特性版本的计划决策评审点之后到最后一个特性版本GA点为止的所有WBS1/2级计划所需要的全部投资的估算。
, {3 Q, n2 O+ K. \6 Y v" K4 P# n 评审时需关注:该概念阶段业务计划作为一个产品,是否具有足够的业务发展潜力(相对于其他项目而言)?更多考虑的是战略可行性。
5 n; a5 v% l2 @2 ^5 v● 对市场的了解
. ?& c4 V9 t- G! y5 ^● 产品(定位、竞争分析、市场地位、分销渠道)
! v* T. m5 b, @5 Y● 业务潜力(相对其他产品而言)4 a G" z& U- \/ N
● 开发计划* W1 J1 F9 l, I* v7 U' h8 y
● 分销渠道 | PAC |
79 | 概念阶段 | 更新项目数据库 | POP-16 | ● 更新项目计划/合同(LPDT);
) ` v, `& v9 U* m● 修正/发布产品包(LPDT);
( K/ `+ q5 e, ]0 c3 N4 v● 更新集成项目文件/模板(LPDT);5 P7 B& A$ c+ w4 F! o1 {9 t
● RDPDT更新共用硬件数据库(Aspect);
6 {) w7 @& j% \● 调整组织/技能/资源(LPDT); [: p& [# K8 g" ]9 _, V5 s
● 调整设施及场地(LPDT);9 T( ?( k$ }+ L+ @% D8 R
● 调整资金(与FPDT一起);
. |/ X; e" ^' R● 确定关键文档,在哪里存放文档的软、硬拷贝。 | POP |
80 | 概念阶段 | 关闭项目数据库 | POP-15 | ● 关闭项目计划/合同(LPDT);5 v" c' T: p7 O% E0 M' `
● 关闭产品包(LPDT);- J0 a. }6 G) r$ ?
● 关闭集成项目文件/模板(LPDT);0 l3 \. g3 m+ b+ B4 n/ U H$ C
● RDPDT关闭共用硬件数据库(Aspect);2 s% a% U) i2 D' U* `% F
● 解散组织/技能/资源(LPDT);(如果项目中止)* r [; K- s. x8 |; s' h+ m- R
● 释放设施及场地(LPDT);
- `5 N. J: i' g* W6 z● 释放资金(FPDT);. r* H( d" T! y
● 确定关键文档,在哪里存放文档的软、硬拷贝。 | POP |
81 | 概念阶段 | 项目经验教训总结 | LPDT-42 | 概念决策评审后PDT对概念阶段工作的成功经验和失败教训进行总结,并按照统一的模板和要求形成案例存储在统一的IT数据系统,并推动共享、查询和继承应用。 | LPDT |
82 | 计划阶段 | 增扩PDT | PAC-30 | PDT选择和落实为完成该产品计划阶段任务所需的PDT扩展组成员,PAC批准资源。 | PAC |
83 | 计划阶段 | 团队培训 | LPDT-46 | 在PDT开始工作前对PDT团队的系统培训,包括以下内容:, J* i5 H6 w! t9 H% j. {; ]
● 团队建设培训;
# ^$ `6 G @% S( |# w# @5 w● 产品开发流程培训,重点是计划阶段的流程;
7 U% U4 c" T/ ^9 s7 `: g● 系统工程培训;
, S7 P, ?4 I3 N8 {: i● 项目管理培训。 | LPDT |
84 | 计划阶段 | 增加扩展组成员并更新项目文档 | POP-20 | 更新项目文档及数据库,将外围组成员加入进来。同时也要更新智力资本数据库。 | POP |
85 | 计划阶段 | 开工会 | LPDT-50 | 通知和分配附加的团队成员给项目;建立团队,将新成员引导进入项目,解释他们的角色和对他们的期望。参考议程如下: $ Y; Q% K" `! P( o, S
● 项目目标介绍(LPDT);' o/ U' O' h$ b. v. {8 U6 u, |4 b
● 宣读PDT扩展组任命(LPDT);
2 P( Z) Q4 O6 v' i" x. y- |1 @, |● PDT成员相互介绍(核心组和扩展组成员);; F* R$ Z; V: t4 R1 }0 B# _
● 计划阶段流程简单介绍(引导者或LPDT);
! ?% Q- C+ b& B● 概念阶段回顾和交付件介绍(LPDT);1 z w3 a- O8 D! ]7 {
● 计划阶段团队成员的角色和职责(LPDT);
/ M: u( a$ T+ h3 R● 计划阶段目标交付件介绍(LPDT);
$ T: h& n$ C5 u, M, @! A+ T- d3 K● 明确计划阶段项目计划、考评和汇报关系、日常沟通方式(LPDT);
! J: o8 q* z& H1 x6 w' k7 O' N1 A● 团队和个人测评指标及激励机制 (LPDT);
$ o5 k1 X6 C2 l0 J; O0 y* s }● 签订资源承诺书(可选);$ B9 M2 E. G- k+ Y* O2 K& `( R
● 领导动员。 | LPDT |
86 | 计划阶段 | 制定计划阶段项目计划(WBS3/4级) | LPDT-55 | 组织PDT成员共同讨论制定项目计划阶段项目计划,为计划阶段工作提供指导。0 Q7 r+ V0 u1 v1 F1 _
依据WBS模板分派工作(PDT经理);4 O1 P. {: T- l6 d. g' q D
核心成员制订本业务领域计划,包括时间、成本、约束条件;, z# M1 k. Z2 K0 b5 n( c
共同讨论制订计划;, h$ v: Q- J( V0 @+ i/ u
计划应分解到可以控制的工作包;1 R2 t5 N" V# F; A
工作包必须在40小时以内。 | LPDT |
87 | 计划阶段 | 制定计划阶段项目计划(WBS3/4级) | FPDT-45 | ● 参与制定计划阶段项目计划(WBS3/4级) | FPDT |
88 | 计划阶段 | 制定计划阶段项目计划(WBS3/4级) | RDPDT-55 | ● LPDT组织PDT核心组成员(各PDT代表)共同讨论制定计划阶段的项目计划,为计划阶段工作提供指引,RDPDT需要制定计划阶段项目的(研发)计划书。 | RDPDT |
89 | 计划阶段 | 制定计划阶段项目计划(WBS3/4级) | CSPDT-45 | ● 针对概念阶段分析结果,根据日程安排,制定计划阶段工作表;
" H8 t/ g8 a8 @' }- y. o7 `● 对概念阶段的分析结果进行工作细化,形成计划阶段具体工作流程;
6 I- e% b$ y# y$ V2 ~● 制定可行性服务的详细需求,需求应基于概要的BOM结构树和系统设计概念框图,以及来自硬件、软件、结构、工艺/以用户为中心的设计产生的输入,修改标准的WBS模板,形成包括资源、成本、时间进度估计的详细计划,阐述具体技术支持;* Y2 u& ]& u* {2 j/ p
● 提交PDT小组讨论,进行技术实现的可行性评估。 | CSPDT |
90 | 计划阶段 | 制定计划阶段项目计划(WBS3/4级) | MNFPDT-45 | ● 根据项目开工会,确认任命PP、AME组成的制造项目小组。) E* c# |. G4 w+ P2 S
● 对该阶段的工作量和工作资源做评估。' u l' P' ^/ o" H w3 W9 K
● 确认计划阶段制造部分的关键事件的里程碑。 | MNFPDT |
91 | 计划阶段 | 制定计划阶段项目计划(WBS3/4级) | PROPDT-45 | 组织PDT成员共同讨论制定项目计划阶段项目计划,为计划阶段工作提供指导。; A/ Q( g8 _3 @' S( F( O3 R1 {" H
● 分析影响计划实施的因素,主要是关键部品;
- M, Z' z6 B. u* I' T1 R: [6 L1 m● 落实上述影响因素的具体进度,结合项目开发的主计划,制定关键部品的进度计划。 | PROPDT |
92 | 计划阶段 | 制定计划阶段项目计划(WBS3/4级) | MKTPDT-45 | ● 根据年度规划的各产品定位、定价、市场任务,制定阶段产品具体规格、计划上市时间、量产时间;# x% X4 B) u8 ], V2 m {6 w5 g
● 与项目组确认软件功能,提供功能细节要求;
1 \. q; ?% S) W' T) J- P! @- X● 确定UI界面风格,设计UI界面。 | MKTPDT |
93 | 计划阶段 | 分解目标成本 | SE-55 | 根据产品结构,将产品目标成本分解成模块或关键物料的成本,以便研发和采购控制成本。 | SE |
94 | 计划阶段 | 优化产品质量目标和计划 | PQA-30 | 进一步优化产品质量目标和计划, 产品质量计划由LPDT及各功能领域代表审核,并作为业务计划的一部分纳入业务计划进行管理和监控。 | PQA |
95 | 计划阶段 | 开始监控项目执行 | LPDT-56 | ● 根据LPDT-55的计划,对整个项目组计划涉及的活动的质量和进度进行监控。 | LPDT |
96 | 计划阶段 | 开始监控项目执行 | FPDT-46 | | FPDT |
97 | 计划阶段 | 开始监控项目执行 | RDPDT-58 | ● 根据项目计划本阶段具体研发活动的执行进行监控,并根据需要定期对项目计划进行更新,本工作将贯穿整个计划阶段的工作。 | RDPDT |
98 | 计划阶段 | 开始监控项目执行 | CSPDT-46 | | CSPDT |
99 | 计划阶段 | 开始监控项目执行 | MNFPDT-46 | ● 根据计划阶段项目计划(WBS3/4)监控制造活动,必要时给予相关的资源和调,使项目能按计划进行。 | MNFPDT |
100 | 计划阶段 | 开始监控项目执行 | PROPDT-46 | ● 根据PROPDT-45的计划,进行监控。 | PROPDT |
101 | 计划阶段 | 开始监控项目执行 | MKTPDT-46 | ● 针对阶段产品,通过信息整理、数据研究、市场调查等手段,监控竞争环境、竞争对手等。 | MKTPDT |
102 | 计划阶段 | 开始监控项目执行 | SE-45 | ● 定期地对设计和开发活动进行检查以确保开发人员正确地按产品包技术规格进行开发; 使用PDM的EC模块来使规格的更改受控(在PDM实施前,使用变更管理和公司其它的相关流程)。 | SE |
103 | 计划阶段 | 开始监控项目执行 | POP-22 | | POP |
104 | 计划阶段 | 制定发布策略 | MKTPDT-47 | 制订发布策略、公关策略、宣传策略。
3 r+ ^0 R# @1 i$ E7 p4 Z0 D2 C, \发布策略:市场发布时间、地点、方式;
% l! w# I- e5 X公关策略:主要是确定针对客户、政府、行业主管部门、社会大众开展那些公关活动,怎样开展,步骤是什么;+ @, O3 d7 ]. M- @4 I/ y
宣传策略:主要是宣传内容、宣传思路、宣传方式及何时启动宣传,宣传要突出产品差异性,突出产品的独特卖点。 | MKTPDT |
105 | 计划阶段 | 需求分解和分配 | SE-50 | 与硬件工作师、软件工程师及结构工程师一起协作,分析产品包需求,将需求分解成硬件、软件或结构子系统;然后每一块(硬件、软件、结构)进一步将需求分配到更下一层子系统、部件或模块之中; 需求分解要确定某些特殊需求如何由硬件、软件或结构或任何组合形式实现;需求分配要清晰地决定需求的哪些部门由硬件实现,哪些部分由软件实现,哪些部分由结构实现,它们之间的接口也要定义清楚。 | SE |
106 | 计划阶段 | 硬件需求分解与分配 | EE-20 | 分析硬件需求,将需求分割成子系统、部件或模块;“硬件需求”的分解和分配将确定某些特殊需求如何采用子系统、部件或模块的组合来实现,并定义它们之间的接口关系。 | EE |
107 | 计划阶段 | 软件需求分解与分配 | SWE-20 | 分析软件需求,将它们分割成子系统或模块;“软件”需求的分解和分配要确定某些特殊需求如何采用子系统或模块的组合来实现,并定义它们之间的接口关系。 | SWE |
108 | 计划阶段 | 结构需求分解与分配 | ME-20 | 分析结构需求,将需求分割成子系统、部件或模块;需求的分解和分配要确定某些特殊需求如何由子系统、部件或模块的组合实现,定义各子系统、部件或模块的装配关系;确定可能采用的新工艺、新技术。 | ME |
109 | 计划阶段 | 系统方案和规格设计 | SE-60 | 基于产品需求分解和分配方面的协作活动,生成系统、子系统、部件、模块及接口的技术规格及系统设计方案,要求表达清晰以减少误解及重复;生成产品技术规格以及系统设计概念框图。 | SE |
110 | 计划阶段 | Build 划分 | SE-65 | SE组织开发人员依据设计需求和设计规格进行Build(模块)划分,生成Build计划和BBIT(Building Block Integrate and Test,构建模块渐增测试)的策略。Build计划是后续制订开发计划和测试与验证计划的依据。. [# x; x# U6 N1 E4 K# D2 e
Build划分的关键步骤如下:, s2 m6 u6 j: [+ z% N# u
● 根据设计需求和设计规格建立功能-模块矩阵 ;" N: s" f. Q+ } L
● 初步分析、整理功能跟踪矩阵,建立unique-combination(关联);
1 Q% x9 Y; H/ r0 _- F● 划分Build;
+ E) W' s+ d, t● 画Build拓扑图并整理模块进度计划。 | SE |
111 | 计划阶段 | 技术评审2 | SE-70 | 对产品需求的分解和分配及确定的产品规格、系统总体方案进行评审。评审通过后将产品规格置于变更控制之下。6 m4 E6 z2 d$ C" q- R; w* a7 R
● TR2重点关注产品设计需求到产品设计规格的完备性。 4 t. }+ x! p' K8 T
● TR2的准备活动包括各功能领域完成专项评审,在TR2的评审会上将由PDT核心团队在综合层面进行讨论,确保设计规格包括并适应每单元和构建模块(譬如单板、软件模块)的设计。
; @3 ~! [1 P$ s# z; a: \● TR2的评审过程包括对关键设计规格和要点的综合讨论,也对产品架构(配置)进行细致审阅(走读),以确保后续的概要设计(HLD)能有效进行。
# ^: D6 G! B4 h7 n/ o: w● TR2通过后产品设计规格应被置于更改控制之下。6 o! {4 s2 X, `. {. I
● TR2的目的是确保:
" f+ T3 W0 W2 | ■ 设计规格充分映射了设计需求,并足以指导后续的IPD流程及功能领域子流程的产品开发活动; - F) o0 \) ]# K6 t: g7 j
■ 定位产品规格和配置中的缺陷和限制,评估风险,形成规避策略和应急计划; 8 c6 P% e4 y% N/ C* O
■ 形成有效的产品配置。% `( y+ u/ Q- S1 ~* K; n& J7 G
对于顾客要求控制的产品,应通知顾客参加设计和开发的评审活动。 | SE |
112 | 计划阶段 | 技术评审2 | PQA-40 | 对产品需求的分解和分配及确定的产品规格、系统总体方案进行评审。评审通过后将产品规格置于变更控制之下。# w& `4 f: N! W3 J
● TR2重点关注产品设计需求到产品设计规格的完备性。 5 Q' g/ Y& R. c* ]0 i
● TR2的准备活动包括各功能领域完成专项评审,在TR2的评审会上将由PDT核心团队在综合层面进行讨论,确保设计规格包括并适应每单元和构建模块(譬如单板、软件模块)的设计。
9 _6 R, R0 q- _● TR2的评审过程包括对关键设计规格和要点的综合讨论,也对产品架构(配置)进行细致审阅(走读),以确保后续的概要设计(HLD)能有效进行。
, p% a' i2 d( Z2 ~8 J+ d: P R● TR2通过后产品设计规格应被置于更改控制之下。 Q1 x: N) M: ] G5 L& S0 x
● TR2的目的是确保:+ i \; s2 S- y# v, s& R/ R
■ 设计规格充分映射了设计需求,并足以指导后续的IPD流程及功能领域子流程的产品开发活动; 0 x, R/ N) `# z- P
■ 定位产品规格和配置中的缺陷和限制,评估风险,形成规避策略和应急计划;
8 |$ P% F/ r, [7 ]4 j8 ?: {! p$ A: f ■ 形成有效的产品配置。+ P6 r8 [9 ?) x8 n3 O4 a
对于顾客要求控制的产品,应通知顾客参加设计和开发的评审活动。 | PQA |
113 | 计划阶段 | 系统规格基线化 | SE-80 | 将评审通过的《产品系统设计方案》(包含内容产品规格书)作为基线;8 u2 q) x7 J# p K# d5 ~
对后续产品开发过程中产生的规格更改进行控制。 | SE |
114 | 计划阶段 | 制订产品包需求跟踪矩阵 | SE-85 | 系统工程师根据基线化的产品包需求、设计需求和设计规格建立需求跟踪矩阵,明确产品包需求如何一级分解到构建模块上。 | SE |
115 | 计划阶段 | 开始监控设计规格 | SE-90 | 定期地对设计和开发活动进行检查以确保开发人员正确地按产品包技术规格进行开发; 开发过程中可以采用查阅文档、参加各类评审会等手段并使用配置管理及涉及制造部分的使用EC(工程变更)控制规格变更。 | SE |
116 | 计划阶段 | 开发BBIT策略 | EE-35 | 开发人员根据Build计划确定BBIT策略,确保Build构建的质量。 | EE |
117 | 计划阶段 | 开发BBIT策略 | SWE-35 | 开发人员根据Build计划确定BBIT策略,确保Build构建的质量。 | SWE |
118 | 计划阶段 | 概要设计 | SE-95 | 系统工程师组织各专业工程师(硬件、软件、结构、EMC(电磁兼容)等)合作,按照《概要设计》文档模板要求,开发和精练概要设计,包括硬件概要设计、软件概要设计、结构概要设计等。 | SE |
119 | 计划阶段 | 知识产权分析 | SE-98 | 根据项目需要检索专利文献和科技论文,分析其可利用性和专利风险;并确定产品专利申请计划和商标使用方案,特别是专利申请计划,以保护公司知识产权;具体分析内容参见《知识产权分析报告模板》。 | SE |
120 | 计划阶段 | 硬件概要设计 | EE-30 | 基于概要的BOM结构树及系统设计规格,开发一个到板级的硬件概要设计;与系统工程师一起来解决与其它功能开发小组之间的冲突和问题。提交长周期物料需求报告。必要的话,提出需求和/或规格更改方面的建议。 | EE |
121 | 计划阶段 | 软件概要设计 | SWE-30 | 基于系统设计规格和软件需求规格说明,进行模块级即需要多少个模块以及每个模块的环境及功能等的软件系统概要设计;准备这一层次的软件系统配置,与系统工程师一起来解决与其它功能开发小组之间的冲突和问题。必要的话,提出需求和/或规格更改方面的建议 。 | SWE |
122 | 计划阶段 | 结构概要设计 | ME-30 | 基于概要的BOM结构树及系统设计概念框图,进行结构系统概要设计,阐述硬件系统所需要的放置、供电、线路安装/连接及板件冷却的方法;准备这一层次的结构系统配置,与系统工程师一起来解决与其它功能开发小组之间的冲突和问题。必要的话,提出需求和/或规格更改方面的建议。汇同PAC团队的其它人员对产生的工业设计方案进行评审、选定;汇同采购代表,确定外协厂家和备选厂家。 | ME |
123 | 计划阶段 | 工业设计概要设计 | IDE-30 | 根据结构工程师提出的设计输入文件,进行系统、全面的方案设计。基于结构系统概要设计,提供外观设计给结构工程师以维持品牌形象;提供人机工程设计给结构工程师以满足用户易用性的需要;,阐述了以用户为中心的设计的各个方面,包括所有顾客接触点;包括工艺设计以及易用性和人机工程设计等各方面。会同PAC团队的其他人员对产生的工业设计方案进行评审、选型。 | IDE |
124 | 计划阶段 | 制定系统测试及验证计划 | TE-20 | 基于概要的BOM结构树和系统方案,以及来自于硬件、软件、结构、工艺测试和认证、信息开发和翻译等方面的工程师/专家的输入,修改标准的WBS模板,形成包括了资源、成本、和时间进度估计的详细计划,阐述了系统测试(内部和外部的)、品质保证,以及各国准入法规。 | TE |
125 | 计划阶段 | 制定资料开发计划 | TD-10 | 基于概要的BOM结构树和系统设计概念框图,以及来自于硬件、软件、结构、工艺/以用户为中心的设计、测试和认证、信息开发和翻译等方面的工程师/专家的输入,修改标准的WBS模板,形成包括了资源、成本、和时间进度估计的详细计划,阐述了技术文档的开发和在线信息(信息计划)的开发。 | TD |
126 | 计划阶段 | 制定翻译计划 | TD-15 | 基于行销计划(考虑不同的地区和渠道)以及详细的信息计划,修改标准的WBS模板,形成包括了资源、成本、和时间进度估计的详细计划,阐述技术文档和在线信息的翻译 (翻译计划)。 | TD |
127 | 计划阶段 | 产品数据结构设计 | SE-99 | 产品BOM结构树设计;组织对产品BOM结构树评审。 | SE |
128 | 计划阶段 | 开发初始BOM | SE-99A | 使产品包结构开发规范化并且在EC控制之下。开发这种清单以支持设计和模块(build)流程。确定初始BOM中物料的物料编码,对尚未编码的新物料,向物料主数据管理员申请编码。 | SE |
129 | 计划阶段 | 开发初始BOM | PROPDT-47A | 使产品包结构开发规范化并且在EC控制之下。开发这种清单以支持设计和模块(build)流程。确定初始BOM中物料的物料编码,对尚未编码的新物料,向物料主数据管理员申请编码。 | PROPDT |
130 | 计划阶段 | 如果提前采购定单批准,向ERP申请物料编码 | PROPDT-49 | 根据PDT做出的提前采购决定和初始BOM,向ERP系统物料主数据管理人员申请物料编码,并将物料编码补充到采购申请中。 | PROPDT |
131 | 计划阶段 | 长周期物料采购 | PRO-10A | 如果提前采购被批准,采购人员执行采购。 | PRO |
132 | 计划阶段 | 技术评审3 | SE-100 | 是对产品子系统及模块的概要设计方案进行评审。评审通过后将产品配置置于变更控制之下。' ~, A% e7 _' A
TR3是在计划阶段对概要设计(HLD)的评审,确保设计规格已经完全、正确地在概要设计中得到体现。TR3的结果将作为开发阶段的后续详细设计活动是否继续投入资源的根据。) Y: {4 _0 H* `
TR3的准备活动包括各功能领域完成专项评审,在TR3的评审会上将由PDT核心团队在综合层面进行讨论,确保概要设计足以指导产品项目计划制订、产品业务计划制订、以及后续的详细设计(LLD)活动。' v0 O5 Q& J6 p% G
TR3的评审过程包括对概要设计各主要冲突点的讨论,也需要跟踪设计规格、共用模块重用计划、产品策略、产品配置的落实情况。
5 ]2 I( |$ }& I0 h* l) bTR3通过后产品概要设计应被置于更改控制之下。
+ o/ H/ |$ {8 J0 x' ATR3的目的是确保:
. G3 _) N4 O9 R* O! l& d● 概要设计(HLD)完备,足以指导后续的详细设计(LLD)活动;
8 x" W2 V. D2 ^+ x7 D4 Q3 Z● 保证产品设计规格到概要设计(HLD)之间的完备性;
8 B- x7 {% L9 z; B9 P9 k● 定位概要设计中的缺陷和限制,评估风险,形成规避策略和应急计划。 | SE |
133 | 计划阶段 | 技术评审3 | PQA-50 | 是对产品子系统及模块的概要设计方案进行评审。评审通过后将产品配置置于变更控制之下。
1 M3 p) k. g+ V- [TR3是在计划阶段对概要设计(HLD)的评审,确保设计规格已经完全、正确地在概要设计中得到体现。TR3的结果将作为开发阶段的后续详细设计活动是否继续投入资源的根据。, w- k4 h' I5 o# a
TR3的准备活动包括各功能领域完成专项评审,在TR3的评审会上将由PDT核心团队在综合层面进行讨论,确保概要设计足以指导产品项目计划制订、产品业务计划制订、以及后续的详细设计(LLD)活动。
% \0 H$ q4 m8 W! k% fTR3的评审过程包括对概要设计各主要冲突点的讨论,也需要跟踪设计规格、共用模块重用计划、产品策略、产品配置的落实情况。
( E7 M3 b! }4 }. X% H4 D9 }: sTR3通过后产品概要设计应被置于更改控制之下。3 b$ ]* W9 }# `9 o& m9 ^" [
TR3的目的是确保:1 H+ ?: D5 B2 \: J
● 概要设计(HLD)完备,足以指导后续的详细设计(LLD)活动; 9 v& W, d& s3 x+ w$ h
● 保证产品设计规格到概要设计(HLD)之间的完备性;
3 z. u" U* j. H4 G; ]● 定位概要设计中的缺陷和限制,评估风险,形成规避策略和应急计划。 | PQA |
134 | 计划阶段 | 概要设计基线化 | SE-110 | 将评审通过的产品概要设计作为基线;
( @1 Z8 T# ^, `, v9 P' x2 k; j对后续产品开发过程中产生的配置更改进行控制。 | SE |
135 | 计划阶段 | 制定命名规则 | MKTE-15 | 参考业界、竞争对手及公司已有的商标、命名规范制定产品的命名规则。 | MKTE |
136 | 计划阶段 | 优化信息安全计划 | LPDT-59A | 优化概念阶段制定的信息安全计划。 | LPDT |
137 | 计划阶段 | 制定客户服务/支持计划 | CSS-20 | 基于概要的BOM结构树和系统设计概念框图,以及来自硬件、软件、结构、工艺/以用户为中心的设计产生的输入,修改标准的WBS模板,形成包括资源、成本、和时间进度估计的详细计划,阐述技术支持。 | CSS |
138 | 计划阶段 | 制定制造计划 | AME-30 | 基于制造策略,更新标准的WBS模板,形成包括资源、成本和时间进度估计的详细计划,阐述如何制造产品;与采购一道决定哪些元器件或零件需要制造,哪些应采购,部件在哪里制造(哪个地点,哪条生产线等等),包括业务和项目两方面。 | AME |
139 | 计划阶段 | 整合物料需求计划 | AME-31 | 整合PDT相关核心成员提出的产品上市过程的物料资源需求(预测)计划,包括功能样机、初始产品、量产产品、生产物料等需求计划,特别是关键器件、长货期器件等在整个产品生命周期内的需求(预测)数据,提交给采购代表做为与供应商谈判时器件采购数量的依据。0 Y* S( K( d! J. e. A6 }
整合物料需求计划的目的是保证产品上市过程中所有的物料资源需求在预算的前提下尽早明朗化,并对资源需求的合理性统一规划,同时指导硬件工程师、物料计划工程师及时启动采购计划下达工作。 | AME |
140 | 计划阶段 | 装备和工艺总体方案设计 | AME-35 | 根据产品各单板的技术特点以及市场预测,结合生产可测试性需求在产品中的实现情况,给出该产品在以后制造过程的生产测试解决方案;规划出本产品需要新开发的测试仪,并对测试仪的总体方案进行简要说明;结合总体方案及测试仪开发涉及到的关键技术,初步估计开发工作量及开发方式(外包或自行开发等)。根据硬件的可生产性设计与结构件的可装配性设计的实际,给出硬件、结构件的生产解决方案。如,单板加工及结构件装配所需的工装、工具的考虑,生产流程、关键工序及生产场地等的考虑。给出制造策略的落实措施。 | AME |
141 | 计划阶段 | 更新供应商&物料选择计划 | PROPDT-47 | 更新概念阶段《初始供应商&物料选择计划》,根据项目计划设定采购业务相关目标,包括供应商选择与评价、采购订单下达、到货、质量、成本、库存等方面的指标设定,更新标准的WBS模板,形成包括资源、成本和时间进度估计的详细计划。 | PROPDT |
142 | 计划阶段 | 制定订单履行计划 | FF-20 | 基于定单履行策略(如何产生定单,通过何种渠道,他们将如何被接受、处理、安排调度、制造、交付和在客户现场安装)。修改标准的WBS模板,形成包括资源、成本、和时间进度估计的详细计划,阐述定单履行。 | FF |
143 | 计划阶段 | 销量承诺 | S-20 | 如果可能,与行销一道制定按渠道、地域等等的销量承诺。销量承诺对详细的财务、市场、开发、测试、采购、制造和技术支持计划有极大的影响。 | S |
144 | 计划阶段 | 做出提前采购决定 | LPDT-57 | 对一些长货期器件和关键器件(包括功能样机、初始产品、RAMP UP产品、量产产品)的是否进行提前采购进行决策,AME参与其中,根据决策结果制定长货期和关键器件采购计划, 此活动由MNFPDT组织,由LPDT批准决定。此活动为例行工作,滚动进行。但是,计划阶段的实际采购下单仅针对必需的功能样机物料。 详细说明请见模板。 | LPDT |
145 | 计划阶段 | 做出提前采购决定 | MNFPDT-48 | 对一些长货期器件和关键器件(包括功能样机、初始产品、RAMP UP产品、量产产品)的是否进行提前采购进行决策,AME参与其中,根据决策结果制定长货期和关键器件采购计划, 此活动由MNFPDT组织,由LPDT批准决定。此活动为例行工作,滚动进行。但是,计划阶段的实际采购下单仅针对必需的功能样机物料。 详细说明请见模板。 | MNFPDT |
146 | 计划阶段 | 做出提前采购决定 | FPDT-48 | 对一些长货期器件和关键器件(包括功能样机、初始产品、RAMP UP产品、量产产品)的是否进行提前采购进行决策,AME参与其中,根据决策结果制定长货期和关键器件采购计划, 此活动由MNFPDT组织,由LPDT批准决定。此活动为例行工作,滚动进行。但是,计划阶段的实际采购下单仅针对必需的功能样机物料。 详细说明请见模板。 | FPDT |
147 | 计划阶段 | 做出提前采购决定 | PROPDT-48 | 对一些长货期器件和关键器件(包括功能样机、初始产品、RAMP UP产品、量产产品)的是否进行提前采购进行决策,AME参与其中,根据决策结果制定长货期和关键器件采购计划, 此活动由MNFPDT组织,由LPDT批准决定。此活动为例行工作,滚动进行。但是,计划阶段的实际采购下单仅针对必需的功能样机物料。 详细说明请见模板。 | PROPDT |
148 | 计划阶段 | 做出提前采购决定 | AME-32 | 对一些长货期器件和关键器件(包括功能样机、初始产品、RAMP UP产品、量产产品)的是否进行提前采购进行决策,AME参与其中,根据决策结果制定长货期和关键器件采购计划, 此活动由MNFPDT组织,由LPDT批准决定。此活动为例行工作,滚动进行。但是,计划阶段的实际采购下单仅针对必需的功能样机物料。 详细说明请见模板。 | AME |
149 | 计划阶段 | 制定对外合作计划 | LPDT-58 | ● 审阅业务计划和项目端到端计划
% o' L$ ~5 z# R7 Z" V2 \● 审阅对外合作策略报告
' O2 S; \& o, m4 o& n8 Z2 u6 M● 审阅各合作项目立项建议书及立项评审表,根据具体对外合作项目的需要,采购代表参与相关合作项目。7 Y2 ^( q/ V7 B- B
■ 产品合作项目: z3 z$ X; u" s
■ 运营商合作项目
9 l- J! e5 i4 i( S5 H ■ 技术合作项目
; v( ~. Y. ^4 R5 G- k● 优化细化各合作项目计划
7 b3 [5 @- F1 W. S% y5 W$ _+ s, s ■ 各合作项目要求的启动时间和要求完成时间,及项目成果(含阶段成果)提交时间
2 V! T0 i# J) @: L5 }9 H ■ 工作量估算及人力需求计划(公司内部投入需求、对外部 人力需求)
: O" K- U% z& d0 R5 ^* ?+ f( l ■ 合作费用分析:投资分析、占产品研发预算比例' Q4 t( H7 S0 }: `* [2 v/ s% M
■ 各合作项目成果验收标准
) g8 p1 z2 R5 z/ F' b* K. C ■ 风险预测(内部风险如需求可能变动、技术方案变动;外部风险如达不到技术要求、时间延误等)# V5 C' L1 E) @, Y8 \+ F) E5 v% w
● 细化后的合作时间计划/人力投入计划/费用计划/验收标准,放入业务计划中。 | LPDT |
150 | 计划阶段 | 优化总体风险评估 | LPDT-59 | 对概念阶段的风险评估进行优化和细化。 | LPDT |
151 | 计划阶段 | 优化财务评估 | FPDT-50 | 优化早期的成本估计——硬件、软件、开发、订单履行、制造、行销和销售、客户服务等等,基于以概要设计、配置和规格等表现的改进后的系统定义,优化WBS 3/4级计划和开发/技术支持/制造/采购/和行销的估计。 | FPDT |
152 | 计划阶段 | 编制优化的财务分析报告 | FPDT-52 | 还要优化从市场获得的收入的估计(基于销售区域、渠道等的预测),以及优化利润率估计。 | FPDT |
153 | 计划阶段 | 优化开发项目计划 | RDPDT-60 | 修改硬件、软件、结构、工艺/以用户为中心的设计、测试、认证、质量保证、信息和翻译方面的研发WBS 3/4级模板,制定研发部分的详细工作计划。在工作计划的基础上进行详细的资源、成本和时间进度估计并将这些信息提供给财务成员,以帮助其准备财务评估,并报告LPDT以便准备业务计划和项目计划。 | RDPDT |
154 | 计划阶段 | 优化采购项目计划 | PROPDT-50 | 修改WBS 3/4级计划,制定项目中采购部分的详细工作计划。基于工作计划制定详细的资源、成本、时间进度估计,并将这些信息提供给PDT核心组财务成员,以帮助其准备财务评估,报告LPDT以便准备业务计划和项目计划。 | PROPDT |
155 | 计划阶段 | 更新市场计划 | MKTPDT-48 | 基于获得潜在客户和停止销售的市场策略,与合作伙伴和销售渠道一起宣传和促销产品包,采取一些销售激励措施等,修改标准的WBS模板,形成包括资源、成本、和时间进度估计的详细计划,阐述行销。包括早期客户支持(ESP)计划。 | MKTPDT |
156 | 计划阶段 | 优化技术支持项目计划 | CSPDT-50 | 修改标准的技术支持WBS 3/4级模板,制定项目中技术支持部分的详细工作计划。基于工作计划进行详细的资源、成本、时间进度估计并将这些信息提供给PDT核心组财务成员,以帮助其准备财务评估,并报告LPDT以便准备业务计划和项目计划。 | CSPDT |
157 | 计划阶段 | 优化制造项目计划 | MNFPDT-50 | 修改标准的制造WBS 3/4级模板,制定项目中制造部分的详细工作计划。基于工作计划进行详细的资源、成本、时间进度估计并将这些信息提供给PDT核心组财务成员,以帮助其准备财务评估,并报告LPDT以便准备业务计划和项目计划。 | MNFPDT |
158 | 计划阶段 | 优化市场项目计划 | MKTPDT-50 | 修改行销WBS 3/4级模板,制定项目中行销部分的详细工作计划。基于工作计划制定详细的资源、成本、时间进度估计并将这些信息提供给PDT核心组财务成员,以帮助其准备财务评估,报告LPDT以便准备业务计划和项目计划。 | MKTPDT |
159 | 计划阶段 | 监控和管理配置 | SE-120 | 定期对设计和开发活动进行检查,确保设计人员正确按概要设计进行,开发开发过程中可以采用查阅文档、参加各类评审会等手段并使用配置管理及涉及制造部分的使用EC(工程变更)控制规格变更。 | SE |
160 | 计划阶段 | 制定标准计划 | SE-121 | 综合分析各输入文档,规划出所有与本产品有关的、有必要进行的标准项目,并明确各标准项目的计划启动时间、计划完成时间、项目负责人和人力资源需求,以及其他标准活动,输出《产品标准计划》。0 g! f" g4 O- H$ P* q, N; }5 J
此活动重点是:0 f/ B) I2 ^: Y# C# ^0 T" K: E$ _
● 决定技术路线的选择。+ X" G/ O2 i- E0 r
● 规划标准项目。 | SE |
161 | 计划阶段 | 优化项目计划和 业务计划 | LPDT-60 | 合并由财务、研发、技术支持、制造、采购和市场的输入,优化成更详细的业务计划和项目计划。并为项目提供建议。在计划决策评审会议之前分发这些材料给PAC成员;制定计划决策评审会议时间表8 ^5 C4 I, W. B4 a
项目计划和业务计划是计划阶段的关键交付件,主要步骤如下:
* k ?+ n- G: H6 A# t● 优化业务计划-11个部分分解到PDT各个成员,PDT成员根据前面的输出写作,由LPDT整合汇总。
" A% D- g: p6 n) `* u( X, n● 制定总项目计划-基于模板在LPDT统一把握下,各PDT成员完成各自部分,然后综合讨论确定。 | LPDT |
162 | 计划阶段 | 拟制合同书 | LPDT-70 | 基于项目计划和评估制定合同文件,在PAC与PDT之间达成有关产品开发项目和交付的协议。LPDT在完成业务计划和总项目计划后拟制合同书。合同书以承诺的方式对产品开发的进度、质量以及财经指标加以约束,明确PDT与PAC在开发过程中所负的责任和承担的义务,并作为考核依据。 | LPDT |
163 | 计划阶段 | 与PAC充分沟通 | LPDT-80 | 为了提高决策时效率和质量,要保证PAC成员在正式决策评审会前,对业务计划等有充分的了解,PDT成员在正式决策评审会前与PAC成员进行充分沟通。建议程序如下:$ B) |$ e. T& z. N9 ^9 p% g
● 在决策评审材料提交给PAC成员后的3到4天内,与成员们进行沟通。每次沟通都要有纪要,沟通的内容就是决策评审材料(业务计划和项目计划),沟通后如有必要在业务计划中修改的,在决策评审前修改完成。
* A. M5 Z' b+ Y● 沟通的问题汇总及答复意见在决策评审会议上要进行汇报。 | LPDT |
164 | 计划阶段 | 计划决策评审 | PAC-40 | 计划决策评审点是PAC对PDT提交的优化的业务计划和建议书以及合同书进行评审,在会上做出该项目继续/终止的决定,并书面通知PDT评审结果。如果决策结果是“继续”,则PDT与PAC签订合同,项目进入开发阶段。PAC授权PDT管理被批准的项目按计划执行以及按照合同条款对项目的交付负责,项目由此进入开发阶段。PAC要提供从开发阶段开始直到GA(General Availability)点的资金,承诺确保必需的资源到位。如果决策结果是“终止”,立即解散并终止项目。
" `+ J3 V4 r6 N( u3 o优化的业务计划以初始的业务计划为基础,提供了更多的细节内容及对计划的承诺。
& p8 \7 ]4 @. [) \. O/ \合同中包括了项目的关键参数,包括销量、预期的单元成本、利润、开发成本以及产品正式发布及规模供货(GA)日期等,每一项都要用括号注明允许的误差。项目合同需列出允许的偏差。项目进入开发阶段后,合同代表了PAC做出的坚实承诺,即每个主要部门都将支持项目以及给PDT必要的资源。 另一方面,PDT将承诺按合同要求完成项目的交付目标。6 K, Q D* e0 c% X5 S( ]% O. M
在公司现阶段,计划决策评审和可获得性决策评审是按特性版本进行的,这主要是与公司目前的预测、规划、计划水平相关联。
4 Z9 s7 t2 p+ I1 k4 o目前,公司在对V版本做第一次计划决策评审时,细化的项目计划(WBS3/4)一般只能做到第一或第二个特性版本,具体做到哪一个特性版本,要根据我们的规划及计划水平而定,但项目计划(WBS3/4)做到哪一个特性版本,如计划决策评审通过,PAC与PDT所签定的合同中要考核的内容就列到哪一个特性版,其它特性版本原估算的投入作为参考内容列入合同,但不做为考核条款。财务分析上仍按V版本进行,PDT核心组仍按V版本设置,但外围组成员会随着特性版本合同执行以及GA点之后,发生变化。
* D! [& u3 ~9 v, _8 z" ] 评审时需关注:建议的产品能否被及时推向市场并赢利?# b7 a, d/ B# D. W* N# V+ I
● 具有竞争力的产品(分销渠道和客户)
2 V5 ]" W& Q9 }. Z. ~● 业务潜力2 R/ a. L, O; I+ {: _% J
● 开发计划
5 t! t* m4 |+ O+ x● 分销渠道
* b4 h R$ j% D( Y$ t7 _● 风险管理 | PAC |
165 | 计划阶段 | 更新项目数据库 | POP-25 | ● 更新项目计划/合同(LPDT);: K4 q0 J. o$ I
● 修正/发布产品包(LPDT);
7 V+ q! P. b: O6 s● 更新集成项目文件/模板(LPDT);
5 T! z/ G# G3 }● RDPDT更新共用硬件数据库(Aspect)8 y, y* C: M5 [5 W" b: I* F
● 调整组织/技能/资源(LPDT);, K" L, M0 _* _" t/ y3 J0 ?2 a
● 调整设施及场地(LPDT);+ G7 g; f# c' C7 K: N
● 调整资金(与FPDT一起);5 K, `& R1 D. x( H ]
● 确定关键文档,在哪里存放文档的软、硬拷贝。 | POP |
166 | 计划阶段 | 关闭项目数据库 | POP-26 | ● 关闭项目计划/合同(LPDT);* ?6 }+ n( y) Y1 S$ \5 b0 C4 z
● 关闭产品包(LPDT);
: N# U8 M, v. ~! g" ]● 关闭集成项目文件/模板(LPDT);
9 M, f N1 m$ ~0 |* J0 U' U● RDPDT关闭共用硬件数据库(Aspect)3 w. i! V* v7 M: L$ v% |
● 解散组织/技能/资源(LPDT);
5 S; c2 S- M( R1 n0 i, x3 r● 释放设施及场地(LPDT); Q3 X/ v$ ^) ^- h# o. d
● 释放资金(FPDT);, n- q0 C- s* q# n+ }# s
● 确定关键文档,在哪里存放文档的软、硬拷贝。 | POP |
167 | 计划阶段 | 项目经验教训总结 | LPDT-82 | 计划决策评审后PDT对计划阶段工作的成功经验和失败教训进行总结,并按照统一的模板和要求形成案例存储在统一的IT数据系统,并推动共享、查询和继承应用。 | LPDT |
168 | 开发阶段 | 增扩PDT,进行产品开发全员任命 | PAC-50 | 确定项目开发、验证和发布阶段后续工作的外围组成员并按合同分配资源。 | PAC |
169 | 开发阶段 | 更新项目环境 | POP-30 | 更新项目文档及数据库,将外围组成员加入进来。同时也要更新智力资本数据库。 | POP |
170 | 开发阶段 | 项目开工会 | LPDT-83 | LPDT召集 PDT核心组成员和扩展组全体成员举行开发阶段开工会,建议的会议议程如下:
" J! L, N; [. U5 p$ i3 M● 项目目标介绍(LPDT)- I" p X3 f# ^- [& S0 z7 O9 t
● 开发合同书发布或签字仪式(LPDT)
1 D' c8 u5 m/ h● PDT任命宣读(LPDT)
3 A3 n2 y4 h, r+ S% K* o! X● 签定承诺书(LPDT和业务代表)
1 q; ?( Y& {! W- @8 W5 \$ H' f● PDT成员相互介绍(全体PDT成员)4 A% t3 D' A) g! [
● PDT中角色和职责介绍(LPDT)
& k( ?. i) b- I' u$ _● 开发阶段流程以及流程求助渠道介绍(LPDT或引导者)' P1 m5 a/ S3 F3 J$ F
● 计划阶段回顾和计划阶段交付件介绍(LPDT)/ p+ ^" W! G$ O; c8 @7 a
● 开发阶段目标交付件介绍(LPDT); k2 p& A, v, ] @$ Z, G
● 开发阶段工作计划以及重要任务配合和计划风险说明(LPDT)
' X/ h+ Y" F( j3 C6 R3 a0 b, ]: c● 明确开发阶段工作计划、考评和汇报关系、日常沟通方式(LPDT)
) q3 M0 ^: ]$ u4 o8 C● 团队和个人测评指标及激励机制 (LPDT)
( u; h( L7 q! j: w2 i% t● 相关领导动员讲话 | LPDT |
171 | 开发阶段 | 开始执行项目监控 | LPDT-90 | 协调并跟踪项目任务绩效;跟踪时间进度、成本、资源和交付件;管理项目范围和更改;管理资源,必要的话重新分配资源;必要的话,向上反映问题;定期性地报告项目状态。 | LPDT |
172 | 开发阶段 | 开始执行项目监控 | FPDT-55 | | FPDT |
173 | 开发阶段 | 开始执行项目监控 | RDPDT-65 | ● 协调并跟踪项目任务完成过程中人员工作的绩效;跟踪项目的时间、进度、成本、资源和交付件;管理项目界定的范围和更改情况;管理项目内部的各类资源,必要的话可以重新进行资源分配;及时向上级反映开发过程中出现的疑难问题,定期性地报告项目状态;使用各类项目管理工具对项目进行管理。 | RDPDT |
174 | 开发阶段 | 开始执行项目监控 | CSPDT-55 | ● 制定开发阶段过程监控计划;
6 N2 A; e1 P; N& q7 i● 对项目开发过程进行监控,对客户服务需求实现结果进行测试; | CSPDT |
175 | 开发阶段 | 开始执行项目监控 | MNFPDT-55 | ● 根据开工会LPDT-83,确认在开发阶段的制造相关事件和里程碑。对项目进行过程进行监控,必要时给予资源等支持,使得任务能按时完成。 | MNFPDT |
176 | 开发阶段 | 开始执行项目监控 | PROPDT-55 | ● 根据计划阶段制定的进度安排,进行监控、协调并跟踪项目任务绩效;跟踪时间进度、成本、资源和交付件;管理项目范围和更改;管理资源,必要的话重新分配资源;必要的话,向上反映问题;定期性地报告项目状态; | PROPDT |
177 | 开发阶段 | 开始执行项目监控 | MKTPDT-55 | ● 根据项目设计日程表,开始执行项目设计监控,包括ID设计、UI设计、功能细节规划、进度情况等;提供样机使用报告并提出修改意见 | MKTPDT |
178 | 开发阶段 | 开始执行项目监控 | SE-125 | ● 协调并跟踪项目任务绩效;跟踪时间进度、成本、资源和交付件;必要的话,向上反映问题; | SE |
179 | 开发阶段 | 开始执行项目监控 | POP-35 | ● 确定关键文档,在哪里存放文档的软、硬拷贝。在《配置管理计划》中明确。 | POP |
180 | 开发阶段 | 执行对外合作计划 | LPDT-91 | 各合作项目经理(产品合作、运营商合作、技术合作)依据对外合作合同/业务计划负责监控实施对外合作计划,保证合作计划与产品开发的同步,并将合作成果应用于产品开发中。
0 b' E2 L$ `0 K8 _* Y' G5 u! G如遇需求变更或计划调整,应按产品开发要求走变更流程,并通过对外合作部/业务部合作分部与合作方达成一致或协调解决。 | LPDT |
181 | 开发阶段 | 监控执行信息计划 | LPDT-95 | 监控执行信息计划 | LPDT |
182 | 开发阶段 | 开始监控产品质量目标和计划 | PQA-60 | 通过例会、阶段会议、度量分析、交付物审计等,监控质量计划的执行情况。5 ~ _- T" R# {9 [
当实际执行情况与产品质量计划发生偏差时,PQA应提醒LPDT采取相应的补救措施,要求LPDT更新计划。更新后的计划必须经过再次审核和批准。 | PQA |
183 | 开发阶段 | 组建Build小组 | RDPDT-66 | 开发代表组建Build小组,各开发项目组指定兼职成员加入到Build小组。Build小组负责准备BBIT(Building Block Integrate and Test)的集成方案、用例、环境并负责执行BBIT活动。 | RDPDT |
184 | 开发阶段 | 跟踪产品目标成本 | FPDT-56 | 根据产品清单和采购价格,计算产品的实际成本,比较实际成本与目标成本的偏差。并反馈给研发、采购和PAC。 | FPDT |
185 | 开发阶段 | 执行标准计划 | SE-127 | 项目计划中需要执行的标准工作活动主要有3类:实施标准项目、参加国内外标准会议、标准研究,这些工作在计划和执行过程中都必须配合产品开发阶段的其他活动和国内外标准会议的时间表,并以促进产品开发和增强产品市场竞争力为目标。 | SE |
186 | 开发阶段 | 优化市场计划 | MKTPDT-68 | 根据产品、客户的需求和与产品相关的潜在细分市场,在原有市场计划的基础上进一步分析和细化需要采取的战术性活动, 类似产品在何处销售、需要关注的目标市场、如何更好地贴近和满足客户、如何提升竞争能力等问题都需要详细的描述 (市场策略)以及具体的措施, 包括价格、目标用户和ESP计划。 | MKTPDT |
187 | 开发阶段 | 制定发布计划 | MKTPDT-68A | 在计划决策评审通过之后,根据发布策略、具体的发布活动及交付件制定详细的发布计划。 | MKTPDT |
188 | 开发阶段 | 开始进行EC管理,发布初始BOM | SE-130 | 所有技术信息放入数据库并通过正式的工程更改(EC)流程或变更控制程序来管理更改;使用“交付件更改管理”使能流程来决定提议的更改。EC release管理并不是冻结数据,而是对更改进行控制,每个人都应该被告知有关的更改以便每个人都基于相同的信息进行工作。 | SE |
189 | 开发阶段 | 设计制造工艺 | AME-40 | 评审现有的生产线能力以确定设备和制造工艺的重用程度;评估自动化技术;对工艺进行成本/效益分析;调研开发供制造和测试用的新设备的需求;选择有效的制造工艺和设备并进行制造工艺设计。 | AME |
190 | 开发阶段 | 装备详细设计 | AME-45 | 参考装备总体方案和各单板概要设计内容,并考虑到各单板详细设计的规格细化和变更情况,制定各单板的生产测试方案;制定各测试仪的设计规格书。单板生产测试方案主要解决FT(功能测试)中各测试项目如何具体实现以及ICT(在线测试)、老化、软件加载的方法;测试仪规格书主要解决测试仪如何设计出来。以单板生产测试方案和测试仪规格书共同指导后续装备的开发。 | AME |
191 | 开发阶段 | 选择供应商 | PRO-20 | 采购人员从现有供方资源和SE确定的新物料候选供方中选择谈判对象,组织商务谈判事宜,依据供方管理文件优选供方。 | PRO |
192 | 开发阶段 | 制定市场资料计划 | MKTE-25 | 在PDCP通过之后,召集营销相关人员讨论要开发的资料,并制定详细的市场资料开发计划。 | MKTE |
193 | 开发阶段 | 准备发布/局部公开/定价/培训 | MKTE-26 | 开始修改标书应答标准模板文档来准备标书应答文件包(市场紧迫性、竞争紧迫性、机会丧失可能性、暴露以前产品的缺陷等);开始收集信息来完成RFA文档;(RFA意味着向PDT和PAC施加压力来发布产品,PDT和PAC在可获得性决策评审点进行检查和平衡);开始准备对销售员工的培训计划,包括师资培训计划,明确候选客户并准备秘密发布(这些客户可能是早期支持的候选客户);准备局部发布的材料、信函、保密协议等。 | MKTE |
194 | 开发阶段 | 启动销售订单环境 | MKTE-27 | 召开订单软件开发的开工会,讨论订单软件的开发策略、算法以及初步的开发计划。 | MKTE |
195 | 开发阶段 | 制定销售订单环境计划 | MKTE-29 | 根据开工会讨论的结果,制定详细的订单软件开发计划。 | MKTE |
196 | 开发阶段 | 执行订单履行计划 | FF-30 | | FF |
197 | 开发阶段 | 确定BETA测试和ESP客户 | MKTE-25 | 基于制定的BATA(试验局)客户选择标准寻找、评估、选择和确定BATA客户。 | MKTE |
198 | 开发阶段 | 确定产品/模块/单板命名 | MKTE-28 | 根据产品命名规则,在确定产品及部件的具体名称。 | MKTE |
199 | 开发阶段 | 开发和审视市场资料 | MKTE-29A | 根据营销类资料计划,各责任部门编写资料,并组织相关部门进行评审。 | MKTE |
200 | 开发阶段 | 监控并管理配置及更改 | SE-140 | 作为持续进行的活动的一部分,对开发和设计活动进行定期性的检查,确保产品需求、规格、配置和其它的产品技术文档没有被随意更改; 使用EC管理来使产品需求、规格、配置和其它技术文档的更改受控。 | SE |
201 | 开发阶段 | 设计检视 | SE-150 | 作为持续进行的活动的一部分,通过参加由硬件、软件、结构、测试、工业设计、采购、市场和其他项目组成员召开的技术会议或阅读会议纪要来进行设计检查;特别的,查实产品是否符合特定的需求和规格,并对所有偏差或更改进行标注;这项活动为“监控和管理配置及更改”活动提供输入。 | SE |
202 | 开发阶段 | 企业标准、企业内控标准起草 | SE-156 | 《企业标准》、《企业内控标准》皆源于《产品规格书》,并在开发过程中参照国际、国内标准,运用技术与经济相结合原则,在不增加成本基础上,为达到优于其他制造厂家同类产品质量而选择合适的功能、性能指标编入到标准文本中,两标准的各项指标定位要恰到好处,并要体现层次和梯度:根据国家规定,《企业标准》所列功能、性能指标可优于国际、国内同类标准中相应的部分,而《企业内控标准》在功能、性能指标上必须优于、严于《企业标准》的规定。 | SE |
203 | 开发阶段 | 知识产权分析 | SE-158 | 根据项目需要检索专利文献和科技论文,分析其可利用性和专利风险;并确定产品专利申请计划和商标使用方案,以保护公司知识产权。具体分析内容参见《知识产权分析报告模板》。 | SE |
204 | 开发阶段 | 硬件详细设计 | EE-60 | 基于硬件概要设计,使用标准的设计工具来进行详细设计,描绘出明确的板、卡、元器件要完成的功能和界面,对每一个板/卡/元器件,开发电路设计、原理图、零部件清单、网表等;按照测试计划合并测试点来支持测试;可能需要设计测试设备及测试软件;在数据库中维护设计信息。详见《硬件单板详细设计流程》。
- \- {8 p) y4 a+ e3 J* u/ S- @4 O对于军用产品需要识别关键元器件,并给出《关键元器件清单》。 | EE |
205 | 开发阶段 | CAD设计 | EE-65 | 根据硬件详细设计说明书、网表、结构PCB要素图等文档的要求进行PCB板的布局、布线和后仿真。设计完成后投板。详见《硬件单板PCB设计流程》。进行逻辑编码与仿真。 | EE |
206 | 开发阶段 | 单元测试 | EE-90 | 硬件工程师准备好相应的物料,单板PCB投板回来后,逐步加工好单板,进行单板软硬件、逻辑调试,测试单板上模块电路特性是否符合设计要求。提交单板测试报告。 | EE |
207 | 开发阶段 | 软件详细设计 | SWE-50 | 基于分配给软件的需求和规格,使用标准的设计工具来进行软件详细设计,描绘出详细的模块、要完成的功能、输入、输出和界面格式。 | SWE |
208 | 开发阶段 | 编码 | SWE-70 | 基于分配的软件需求和规格、软件详细设计,进行编码、链接编辑并且在编程数据库中维护代码及其历史资料。 | SWE |
209 | 开发阶段 | 单元测试 | SWE-72 | 进行测试和调试代码、并且在编程数据库中维护代码及其历史资料。 | SWE |
210 | 开发阶段 | 结构详细设计 | ME-50 | 基于分配到结构的需求和规格以及工业设计/人机工程设计的建议,使用标准的设计工具来进行详细设计:在数据库中维护设计信息。 | ME |
211 | 开发阶段 | 结构试制/试装/测试 | ME-70 | 基于详细设计和测试计划,,组装结构元件和硬件单元进行单元测试,报告并解决问题,通过刷新特定的项目数据库中的文件来跟踪更改;报告构建单元测试的结果;明确可制造性/可服务性/质量/可靠性问题及可能的解决办法。 | ME |
212 | 开发阶段 | Block集成和测试 | EE-95 | BBIT验证构建模块的外部接口和与其他构建模块之间的接口,包括与已有系统的接口,以及其他需要测试的部分。通过回归测试确保增加新的Building Block后,已有系统能正常运行。
5 P! i! e! |. ]3 A' L备注:目前先做系统联调,EE/SWE负责编写系统联调方案,SE最终确定系统联调方案。TE跟踪参与联调过程。EE/SWE负责编写联调报告,TE预审联调报告,SE批准联调结束。 | EE |
213 | 开发阶段 | Block集成和测试 | SWE-95 | BBIT验证构建模块的外部接口和与其他构建模块之间的接口,包括与已有系统的接口,以及其他需要测试的部分。通过回归测试确保增加新的Building Block后,已有系统能正常运行。. V7 s' J/ L+ S7 E
备注:目前先做系统联调,EE/SWE负责编写系统联调方案,SE最终确定系统联调方案。TE跟踪参与联调过程。EE/SWE负责编写联调报告,TE预审联调报告,SE批准联调结束。 | SWE |
214 | 开发阶段 | Block集成和测试 | TE-50 | BBIT验证构建模块的外部接口和与其他构建模块之间的接口,包括与已有系统的接口,以及其他需要测试的部分。通过回归测试确保增加新的Building Block后,已有系统能正常运行。7 Z3 ?- c; |( Q- B6 U
备注:目前先做系统联调,EE/SWE负责编写系统联调方案,SE最终确定系统联调方案。TE跟踪参与联调过程。EE/SWE负责编写联调报告,TE预审联调报告,SE批准联调结束。 | TE |
215 | 开发阶段 | 硬件设计审查 | TE-45 | 对单板硬件原理图、PCB等设计文件作设计审查分析,在底层设计上保证测试对象功能实现上的可靠性与正确性。测试工程师重点开展的是原理分析和可靠性分析,包括器件可靠性应用分析,系统FMEA(失效)分析等。(条件不满足,可以不做) | TE |
216 | 开发阶段 | 测试设计和更新测试计划 | TE-30 | 基于以前制定的测试计划,更新和细化测试计划,包括:硬件、软件和结构测试,测试纲要,测试规格等;指定渐增的构件版本和相应的测试组合;更新的测试计划用于电子(硬件)、软件和结构的开发与测试。 | TE |
217 | 开发阶段 | 开发“开发用”测试工具 | TE-40 | 基于测试计划,设计和开发“开发阶段”使用的测试装备;识别标准/非标准测试装备、测试设备和测试程序;获得和保护测试装备和工具来支持开发测试。 | TE |
218 | 开发阶段 | 信息开发 | TD-30 | 基于详细设计和开发活动编写技术文档、操作手册、使用手册参考文档、在线支持文件/资料等。 | TD |
219 | 开发阶段 | 翻译及验证 | TD-40 | 基于翻译计划和开发的技术(及其他)文件,在需要的地方利用第三方完成翻译工作,第三方要签订保密协议。加载翻译的文件,运行系统来验证翻译是否正确,记录偏差、疑点和问题并加以解决。 | TD |
220 | 开发阶段 | 信息产品测试 | TD-42 | 利用内部环境对信息产品的实用性、可用性、一致性进行测试。 | TD |
221 | 开发阶段 | 下达功能样机物料计划 | AME-46 | 在计划阶段技术评审3后,根据产品物料需求计划,启动功能样机物料申购工作,此活动一直持续到产品开发阶段技术评审4。按照相应的物料下达方式,由硬件工程师完成器件(包括委托设计电源)申购、PCB投板,配套设备、软件申购工作,结构工程师完成结构样件试制申请等工作。 | AME |
222 | 开发阶段 | 产品数据准确性管理与齐套 | SE-159 | 根据产品配置和一级计划,确定产品数据交付件;根据产品详细设计,调整优化产品数据结构;EC的一致性管理与发布,包括跨产品线产品数据的关联应用;监控产品数据交付件按计划归档,产品数据齐套性检查;PART(零件)信息、BOM清单、技术文件、中试文档的准确性管理与齐套发布;及时处理产品数据问题;推广产品数据的新技术、新工具的应用,培训相关产品数据知识。 | SE |
223 | 开发阶段 | 更新BOM 并在初始生产前向制造发布(SIT和BETA系统) | SE-161 | 在IPD流程的各个关键点,产品构造的最新情况应提供给制造。 | SE |
224 | 开发阶段 | 技术支援准备 | CSS-30 | 准备培训资料,就新产品对技术支援的同事进行培训;参与测试(包括beta测试),学习产品和如何对安装、配置和开通、操作、故障检测、诊断、解决和管理等进行技术支援(参见前述的技术支援计划)。 | CSS |
225 | 开发阶段 | 准备可安装性/可服务性测试 | CSS-38 | 确定可安装性/可服务性测试的测试项目,搭建测试环境,准备测试资源等。 | CSS |
226 | 开发阶段 | 订购功能样机物料 | PRO-30 | 在和主要供应商谈判之后,订购功能样机物料(假定技术资料——图纸、规格等在EC控制之下,当产品包开发通过EC流程逐步进行更改时,供应商将及时得到更新信息。) | PRO |
227 | 开发阶段 | 企业标准、企业内控标准定稿 | SE-162 | 优化《企业标准》、《企业内控标准》初稿,进行定稿。 | SE |
228 | 开发阶段 | SDV(系统设计验证) | EE-120 | 按更新的测试计划,整合渐增的产品构件版本并按计划进行测试;验证产品是否符合原先规定的功能。 | EE |
229 | 开发阶段 | SDV(系统设计验证) | SWE-110 | 按更新的测试计划,整合渐增的产品构件版本并按计划进行测试;验证产品是否符合原先规定的功能。 | SWE |
230 | 开发阶段 | SDV(系统设计验证) | ME-110 | 按更新的测试计划,整合渐增的产品构件版本并按计划进行测试;验证产品是否符合原先规定的功能。 | ME |
231 | 开发阶段 | SDV(系统设计验证) | TE-55 | 按更新的测试计划,整合渐增的产品构件版本并按计划进行测试;验证产品是否符合原先规定的功能。 | TE |
232 | 开发阶段 | 可安装性/可服务性测试 | CSS-41 | 按已定的测试项目进行测试。具体见操作指导书。 | CSS |
233 | 开发阶段 | 下达初始产品(性能样机)物料计划 | AME-47 | 根据调整后的产品物料需求计划表中确定的性能样机需求规模、时间、产品配置关系,物流计划员负责从单板BOM清单中提取专用物料、公用物料,按规范制定物料计划。计划文件经相关人员审核、会签、批准后下达。 | AME |
234 | 开发阶段 | 订购性能样机物料 | PRO-39 | 在和主要供应商谈判之后,订购性能样机物料(假定技术资料——图纸、规格等在EC控制之下,当产品包开发通过EC流程逐步进行更改时,供应商将及时得到更新信息。) | PRO |
235 | 开发阶段 | 试制准备 | PP-05 | 在试制准备过程中通过熟悉产品完成产品整机、单板、模块的3种指导书的拟制;制订产品制造系统验证方案和产品一致性验证方案。对产品在制造系统方面和产品一致性方面进行评估,并关注用生产线试生产(该生产线就是用来生产新产品的生产线,以便评估生产线), 完成试产规划报告为生产初始产品作好准备, 并保证顺利通过技术评审4A。 | PP |
236 | 开发阶段 | 开发生产测试设备 | AME-50 | 基于更新的测试计划,提供质量、可靠性、环境和其他性能、鉴定等方面的需求,承诺的销售量,设计和开发在生产过程中使用的测试装备;确定标准/非标准测试装备,测试夹具和测试程序;在生产过程中,获得测试装备和工具来支持测试。 | AME |
237 | 开发阶段 | 开发制造工艺 | AME-60 | 基于所承诺的销售量设计制造工艺流程;与采购人员一起进行“自制/购买”分析,决定外购供应商;评估现有的制造设备和工具的符合度、容量、能力、可获得性等,根据需要选择额外的生产设备,布置生产线,设计工艺路线,模拟并反复平衡生产线;获得、安装、集成并测试生产线;准备生产初始产品。 | AME |
238 | 开发阶段 | 技术评审4A | SE-165 | 在SDV(系统设计验证)完成后,对产品技术上的成熟度进行评估,确保所有存在的问题和风险都进行了评估,并生成了相应的改进计划,以保证供应和制造能力足以支撑初始产品生产活动。- P8 B# V3 M7 M& b- L1 o, t) A
TR4A作为IPD流程中一个关键的技术评审点,其目的包括:
( n% I9 ~3 Z6 b& ~9 `- m● 对SDV测试结果、遗留问题及风险、改进计划进行评审,判定是否进入SIT(系统集成测试);
$ E( t/ \; V& S! m● 评估功能样机的成熟度是否可以进入初始产品测试;
/ l# T9 e& v& S$ u+ r* s! f● 根据进行TR4A评审的产品版本所具有的有限的功能和性能规格,判断该版本是否适合启动Beta测试;8 e5 I" I p; O% ]# ? |
● 对采购和制造能力进行基线化,保证足以支撑初始产品生产(从而保证SIT的启动),以及开发阶段的Beta测试活动(如果需要进行Beta测试)。( [" x3 T5 e2 l3 G
● TR4A针对一个Build版本进行,TR4A应该在该Build启动初始产品生产和启动Beta测试之前进行。 | SE |
239 | 开发阶段 | 技术评审4A | PQA-80 | 在SDV(系统设计验证)完成后,对产品技术上的成熟度进行评估,确保所有存在的问题和风险都进行了评估,并生成了相应的改进计划,以保证供应和制造能力足以支撑初始产品生产活动。- Y% S; M' p5 r4 Q& f- Z
TR4A作为IPD流程中一个关键的技术评审点,其目的包括:, k3 }5 S R. j X2 P
● 对SDV测试结果、遗留问题及风险、改进计划进行评审,判定是否进入SIT(系统集成测试); , f; B% ?% b+ ?0 t. Q" b
● 评估功能样机的成熟度是否可以进入初始产品测试;
1 ?+ T0 Q( g. F- v6 X; S● 根据进行TR4A评审的产品版本所具有的有限的功能和性能规格,判断该版本是否适合启动Beta测试;! ^, ^6 X3 \% v" ~* U9 W! i4 {
● 对采购和制造能力进行基线化,保证足以支撑初始产品生产(从而保证SIT的启动),以及开发阶段的Beta测试活动(如果需要进行Beta测试)。( N" n/ C1 ]! M6 t
● TR4A针对一个Build版本进行,TR4A应该在该Build启动初始产品生产和启动Beta测试之前进行。 | PQA |
240 | 开发阶段 | 更新BOM并发布最新版本给制造 (SVT和beta)系统用 | SE-170 | 更新BOM并发布最新的版本到制造(生产SVT(系统验证测试)和Beta测试用的系统)。2 b& }( b; X! P, N- A. ]& A7 ]4 K
描述:在IPD流程的各个关键点,产品构造的最新情况应提供给制造。 | SE |
241 | 开发阶段 | 组织技术培训 | RDPDT-67 | | RDPDT |
242 | 开发阶段 | 下达初始产品(试产产品)物料计划 | AME-61 | 在技术评审4A后,物料计划工程师制定试产产品物料计划文件,按照相关计划操作流程进行排产、下达专用物料采购计划(包括PCB、结构件、外购设备、软件)、制定专用物料半成品加工计划。以后每两周根据开发设计更改信息滚动刷新试产产品物料计划。 | AME |
243 | 开发阶段 | 订购试产产品物料 | PRO-45 | 在和主要供应商谈判之后,订购试产产品物料(假定技术资料——图纸、规格等在EC控制之下,当产品包开发通过EC流程逐步进行更改时,供应商将及时得到更新信息。) | PRO |
244 | 开发阶段 | 生产初始产品 | PP-10 | 利用开发完成的产品制造工艺,生产初始产品(性能样机、BATA、试产产品);借此机会来微调工艺流程。 | PP |
245 | 开发阶段 | 制造系统验证 | MNFPDT-56 | ● 利用开发完成的产品制造工艺,生产初始产品(性能样机、BATA、试产产品);借此机会来微调工艺流程,并通过对制造系统的验证工作进行有效的指导和控制,以保证验证效果,提高验证效率,按时完成验证计划。
. }% F' @6 G8 e● 组织实施产品在试产验证过程中制造系统验证数据的分析处理和产品一致性测试,完成对产品在制造工艺系统方面和产品一致性方面的评估,以及各种问题的及时分析总结、反馈和处理,并跟踪至彻底解决。 | MNFPDT |
246 | 开发阶段 | 制造系统验证 | PP-15 | ● 利用开发完成的产品制造工艺,生产初始产品(性能样机、BATA、试产产品);借此机会来微调工艺流程,并通过对制造系统的验证工作进行有效的指导和控制,以保证验证效果,提高验证效率,按时完成验证计划。- b+ D. K9 B3 v* a' ]% s6 v
● 组织实施产品在试产验证过程中制造系统验证数据的分析处理和产品一致性测试,完成对产品在制造工艺系统方面和产品一致性方面的评估,以及各种问题的及时分析总结、反馈和处理,并跟踪至彻底解决。 | PP |
247 | 开发阶段 | SIT(系统集成测试) | EE-140 | 基于测试计划(渐增的构件和测试),逐步构建系统并对从生产线生产出来的首批产品单元进行集成测试(渐增测试和最后的全面测试)。验证产品是否符合原先规定的功能。5 {4 J+ _( D2 I% P
对于顾客要求控制的产品,应通知顾客参加验证。 | EE |
248 | 开发阶段 | SIT(系统集成测试) | SWE-130 | 基于测试计划(渐增的构件和测试),逐步构建系统并对从生产线生产出来的首批产品单元进行集成测试(渐增测试和最后的全面测试)。验证产品是否符合原先规定的功能。 b g. N3 r9 C9 d7 J# {
对于顾客要求控制的产品,应通知顾客参加验证。 | SWE |
249 | 开发阶段 | SIT(系统集成测试) | ME-122 | 基于测试计划(渐增的构件和测试),逐步构建系统并对从生产线生产出来的首批产品单元进行集成测试(渐增测试和最后的全面测试)。验证产品是否符合原先规定的功能。
% P8 B9 g% b3 ?3 T: K' V对于顾客要求控制的产品,应通知顾客参加验证。 | ME |
250 | 开发阶段 | SIT(系统集成测试) | TE-60 | 基于测试计划(渐增的构件和测试),逐步构建系统并对从生产线生产出来的首批产品单元进行集成测试(渐增测试和最后的全面测试)。验证产品是否符合原先规定的功能。
2 g0 U6 m/ F1 d0 u( R: E, `对于顾客要求控制的产品,应通知顾客参加验证。 | TE |
251 | 开发阶段 | BETA测试准备 | TE-65 | 进行安装工具准备、人员培训、勘测、工程计划、发货跟踪等BATA测试的各项准备工作。 | TE |
252 | 开发阶段 | 技术评审5 | SE-230 | TR5是在发布给客户前对项目整体状态在设计稳定性和技术成熟度方面的独立评估活动。TR5目的是确保产品符合预定的功能和性能要求,以满足前期确定的产品包需求。
# x' d9 N0 Y5 d1 r. T# F/ E3 hTR5在SIT结束后进行,TR5要保证产品在试制前在功能和性能方面的问题均已发现和解决:
# O, n5 a; k% L( A% H O● 检查初始产品的规格是否符合计划阶段产品规格的要求;
+ s, C0 z1 g- n● 检查初始产品的制造过程是否影响产品的功能、可靠性和性能规格。
% |# F) Q, P* @3 I$ g( a& W/ z● TR5是进入验证阶段的必要和充分条件。完成TR5就表明小批量初始产品生产和销售已经准备就绪。 | SE |
253 | 开发阶段 | 技术评审5 | PQA-90 | TR5是在发布给客户前对项目整体状态在设计稳定性和技术成熟度方面的独立评估活动。TR5目的是确保产品符合预定的功能和性能要求,以满足前期确定的产品包需求。
+ G b" K& Q1 }TR5在SIT结束后进行,TR5要保证产品在试制前在功能和性能方面的问题均已发现和解决:
9 t2 ~ n8 V5 F& {& d' P: L) v● 检查初始产品的规格是否符合计划阶段产品规格的要求;
- u8 c2 n `9 c; i# p; Z' Q● 检查初始产品的制造过程是否影响产品的功能、可靠性和性能规格。3 ^7 l6 n6 s4 Q9 p+ g" q
● TR5是进入验证阶段的必要和充分条件。完成TR5就表明小批量初始产品生产和销售已经准备就绪。 | PQA |
254 | 开发阶段 | 准备早期销售决策评审材料 | LPDT-96 | 准备早期销售决策评审材料 | LPDT |
255 | 开发阶段 | 准备早期销售决策评审材料 | FPDT-57 | | FPDT |
256 | 开发阶段 | 准备早期销售决策评审材料 | MKTPDT-69 | | MKTPDT |
257 | 开发阶段 | 与PAC充分沟通 | LPDT-97 | 为了提高决策时效率和质量,要保证PAC委员在正式决策评审会前,对业务计划有充分的了解,PDT成员在正式决策评审会前与PAC委员进行充分沟通。建议程序如下:$ w* Z6 J2 P9 L( W& ^
● 在决策评审材料提交给PAC成员后3到4天后与委员们进行沟通。每次沟通都要有纪要,沟通的内容就是决策评审材料(业务计划和项目计划),沟通后如有必要在业务计划中修改的,在决策评审前修改完成。
) V: ]6 X9 g+ F) I! O( I● 沟通的问题汇总及答复意见在决策评审会议上要进行汇报。 | LPDT |
258 | 开发阶段 | 确定试验局客户 | MKTPDT-68B | | MKTPDT |
259 | 开发阶段 | 做出早期销售决策 | PAC-51 | ● 早期销售决策的时间要求:早期销售的产品必须是通过技术评审5的产品;技术评审5是对系统集成测试的结果做评审,评审对象是生产环境下生产的初始产品;技术评审5通过后标志开发阶段完成。
! C; o0 e$ j- g j9 [8 d8 T/ N# B● 早期销售决策的目的:& Y" F/ ]% J4 A' u
■ 一般是为抢占市场,实质上是为了满足市场部点及重点客户的需求。
" X1 F( t* k( z( C6 \ J9 D; H ■ 一定程度上,也存在验证市场需求的功能(广义的需求,从¥APPEALS方面的理解)。
7 f; w+ f' f/ z ■ 决定试产产品是否可以销售,一般为内部发布、外部局部公开。
, }: m+ n( ]8 U( Q/ H● 有些新产品在没有大批量供货的能力或没有准备充足的工程/服务人员时,不能一下子就在国内/国际所有的办事处/地区面对所有客户都公开发布;其次,对于关系客户,从销售策略上讲,希望让关系户产生优越感,使他们知道他们在我们心中的地位很高,有助于巩固客户关系;再次,希望关系客户成为我们的实验局客户或早期销售客户。: T. f: ?1 _% v) J& p8 m3 F% a; b
● 早期销售评审的重点:对市场部点、重要客户的需求的把握,与产品规划的功能权衡。早期销售的产品可以按SE规划的BUILD来划分(不同的BUILD实现的功能可能不同),将产生对应的客户版本(C版本),这时产品(BUILD的功能/质量)可能还不具备发布的条件。早期销售的产品对于产品规划来可能是不完备的,对管理来说可能是多了一种产品状态。 | PAC |
260 | 验证阶段 | 继续执行项目监控 | LPDT-100 | ● 对项目的执行进行持续的每周例行监视和控制。 | LPDT |
261 | 验证阶段 | 继续执行项目监控 | FPDT-58 | ● 视项目和计划情况需要时对项目的执行进行持续的每周例行监视和控制。
2 P) `4 \, P7 f$ b# _! b& s● FPDT提供项目预实分析报告。 | FPDT |
262 | 验证阶段 | 继续执行项目监控 | RDPDT-68 | ● 对项目计划进行每周例行监督和控制,继续项目的绩效考核工作,对于项目执行过程中发现的一些影响计划的各类问题,需要及时向上汇报。 | RDPDT |
263 | 验证阶段 | 继续执行项目监控 | CSPDT-58 | ● 对项目的执行进行持续的每周例行监视和控制。 | CSPDT |
264 | 验证阶段 | 继续执行项目监控 | MNFPDT-58 | ● 根据SE-230技术评审3所形成的关键事件和里程碑,对项目进行监控。 | MNFPDT |
265 | 验证阶段 | 继续执行项目监控 | PROPDT-58 | ● 对项目的执行进行持续的每周例行监视和控制。 | PROPDT |
266 | 验证阶段 | 继续执行项目监控 | MKTPDT-69A | ● 根据项目设计日程表,继续执行项目设计监控,该阶段主要包括产品配色、标准配置、包装、说明书、颜色名称、相关增值服务等并拟订功能确认书初稿以备广告设计、公关宣传等。& |6 ]( A( G( B# H$ Z- i$ k
● 确认软件功能实现情况。
2 Z# f5 Q' Y0 K! d4 o& f● 在PP1阶段,确认UI,铃声,游戏及配色效果。 | MKTPDT |
267 | 验证阶段 | 继续跟踪目标成本 | FPDT-59 | 根据产品清单和采购价格,计算产品的实际成本,比较实际成本与目标成本的偏差。并反馈给研发、采购和PAC。 | FPDT |
268 | 验证阶段 | 提供最终产品配置给订单履行 | RDPDT-69 | 将产品的详细配置清单提供给定单履行。 | RDPDT |
269 | 验证阶段 | 继续监控产品质量目标和计划 | PQA-100 | 在验证阶段,继续监控产品质量目标和计划。 | PQA |
270 | 验证阶段 | 监控并管理配置及更改 | SE-240 | 作为持续进行的活动的一部分,对开发和设计活动进行定期性的检查,确保产品需求、规格、配置和其它的产品技术文档没有被随意更改;使用EC管理使产品需求、规格、配置和其它技术文档的更改受控。 | SE |
271 | 验证阶段 | 设计检视 | SE-250 | 作为持续进行的活动的一部分,通过参加由硬件、软件、结构、测试、工业设计、采购、市场和其他项目组成员召开的技术会议或阅读会议纪要来进行设计检查;特别的,查实产品是否符合特定的需求和规格,并对所有偏差或更改进行标注;这项活动为“监控和管理配置及更改”活动提供输入。 | SE |
272 | 验证阶段 | 更新BOM并发布最新版给本给制造 | SE-235 | 在IPD流程的各个关键点,产品构造的最新情况应提供给制造。 | SE |
273 | 验证阶段 | SVT(系统验证测试) | TE-70 | 对初始产品单元进行性能、可靠性、环境测试。 | TE |
274 | 验证阶段 | 内部认证/标准测试 | TE-71 | 他国准入、进行测试内部认证/标杆、法规等方面。 | TE |
275 | 验证阶段 | 技术资料出版、发运、储存 | TD-50 | 当技术文档和其他文档经过评审和验证后,印刷纸件文档(技术手册、安装手册、用户手册等)及其翻译版本,运送到销售渠道并纳入存货目录。 | TD |
276 | 验证阶段 | 继续制造系统验证 | MNFPDT-59 | 通过对制造系统的验证工作进行有效的指导和控制,以保证验证效果,提高验证效率,按时完成验证计划。
% {: w6 X9 |3 c( _& c! `# _组织实施产品在试产验证过程中制造系统验证数据的分析处理和产品一致性测试,完成对产品在制造工艺系统方面和产品一致性方面的评估,以及各种问题的及时分析总结、反馈和处理,并跟踪至彻底解决。 | MNFPDT |
277 | 验证阶段 | 继续制造系统验证 | PP-30 | 通过对制造系统的验证工作进行有效的指导和控制,以保证验证效果,提高验证效率,按时完成验证计划。
6 U+ b l; H' z* ~5 l组织实施产品在试产验证过程中制造系统验证数据的分析处理和产品一致性测试,完成对产品在制造工艺系统方面和产品一致性方面的评估,以及各种问题的及时分析总结、反馈和处理,并跟踪至彻底解决。 | PP |
278 | 验证阶段 | 下达量产物料计划 | AME-70 | 在技术评审5后,物料计划工程师根据市场代表滚动刷新的并经市场相关部门评审通过的要货计划, 按照相关计划操作流程录入预测、排产计划、下达物料采购计划(包括PCB、结构件、外购设备、软件)、制定物料半成品加工计划。以后每两周根据调整的市场要货计划滚动刷新生产物料计划。到发布阶段后期及时检查生产物料的齐套性,启动生产。 | AME |
279 | 验证阶段 | 采购长货期量产物料 | PRO-50 | 通过ERP系统下单--这不在IPD范围。 | PRO |
280 | 验证阶段 | 采购量产物料 | PRO-55 | 通过ERP系统下单--这不在IPD范围。 | PRO |
281 | 验证阶段 | 执行订单履行活动 | FF-40 | 按订单履行计划执行活动(如何产生定单,通过何种渠道,他们将如何被接受、处理、安排调度、制造、交付和在客户现场安装)。 | FF |
282 | 验证阶段 | 建立订单环境 | FF-50 | 加载产品构件、标准配置和配置规则到销售配置器中,建立用户定单系统的界面。 | FF |
283 | 验证阶段 | 接受培训,准备销售力量 | S-30 | 培训销售队伍并用市场的辅助品(如小册子等)、工具(如配置器等)武装他们以便让他们在发布日能够开始销售。 | S |
284 | 验证阶段 | 制定客户迁移计划 | MKTE-35 | | MKTE |
285 | 验证阶段 | 继续准备发布/局部公开/定价/培训 | MKTE-30 | 继续发布准备;继续收集信息来完成RFA文档;(RFA是为了向PDT和PAC施加压力来发布产品,PDT和PAC在可获得性决策评审点进行检查和平衡);继续准备对销售员工的培训计划,包括师资培训计划,明确候选客户并准备秘密发布(这些客户可能是早期支持的候选客户);准备局部发布的材料、信函、保密协议等;获得准入证,准备媒体发布,完成培训资料的准备,准备好正式的发布申请。 | MKTE |
286 | 验证阶段 | 验证销售配置器 | MKTE-31 | 销售工具开发完成后,相关部门对销售工具进行验证及评价,为发布销售工具系统作好准备。 | MKTE |
287 | 验证阶段 | 进行BETA测试 | TE-75 | 在客户的环境安装首批产品单元并在实际条件中测试产品;包括功能测试,压力测试等。 | TE |
288 | 验证阶段 | 支持BETA测试 | CSS-45 | 协助TE完成BETA测试,负责技术资料的验证。 | CSS |
289 | 验证阶段 | SVT2 | TE-76 | 针对对BETA测试发现的问题进行回归测试。 | TE |
290 | 验证阶段 | 技术评审6 | SE-270 | TR6是一个关注于系统级的评审,确保产品的制造能力已经能适应全球范围内发货的需求。
. j; f: r% N) y8 MTR6关注于以下几方面:& t( S# v: v1 {2 G
● 系统总览
9 H7 s, \- @7 | v7 ^! X● 计划评审、量产评审、供应商评审! z3 M6 s) ~# O! h+ c$ `
● 制造计划周期(包含装备、装配计划、测试计划、资源)
! A: m0 l, l& F● 物料管理计划的执行,以支持放量生产
/ z7 U, W# g0 {2 s● 产品保证(遗留问题是否解决, 产品质量目标是否符合要求). u, o+ e. n" J$ V- ]
● 可靠性、可维护性、可安装性、可服务性目标是否符合要求5 r0 J# l; H( m) a5 _3 L
● 所有特性(含功能、性能)的目标是否符合要求' Z& i' ?8 p+ D, b1 U" ^% h
● Beta测试中的问题是否已经被解决
9 p" x7 m% A S8 Y, e( v# R在SVT后进行。TR6是验证阶段唯一的技术评审。TR6是ADCP和GA的判断准则之一。TR6关注于产品生产问题的状态和解决情况。
- d" \6 `' W* [4 m当决定产品是否能从试制中心转到制造部门,并开始放量生产时,需要考虑TR6的结果。 `# ~! |% q8 C$ d: }' W' ~
TR6的目标是评估产品级交付件的技术成熟度,分析继续进行发布阶段的后续活动(切换到生产、放量等)的风险。因此TR6有如下5个目的:+ g& D/ G9 d. W; i0 O( A
● 作为ADCP参考输入,TR6检查产品是否可以推向市场并且确认进入发布阶段可能存在的风险。+ Y7 s. D$ X! I
● TR6评审对Beta测试的产品规格和产品制造的输出、问题和解决方案的冲击。8 E0 U( x$ o8 h6 X, z2 w
● TR6确认最终产品配置已经文档化,所有EC(变更请求)已经生效、已经执行并且测试完成。 - a* g0 F, n, N" x; F) }8 C0 B Z' V0 l
● TR6确保生产和产品支持系统已经被验证,并且适合进入小批量生产。 " p {5 _8 V9 U O3 s2 _
● TR6确保技术和销售支撑系统已经准备好,并且进入发布阶段后必需的相关信息已经完成。 | SE |
291 | 验证阶段 | 技术评审6 | PQA-110 | TR6是一个关注于系统级的评审,确保产品的制造能力已经能适应全球范围内发货的需求。 & U/ j. b! h5 K
TR6关注于以下几方面:
6 J: P+ |8 D# H- \1 n, U8 C* B z● 系统总览4 g* c- N5 Z8 Q3 [1 V! C0 b
● 计划评审、量产评审、供应商评审
! J5 c# c5 x$ g4 F6 d● 制造计划周期(包含装备、装配计划、测试计划、资源)% n$ Q" W; [3 n! A( s
● 物料管理计划的执行,以支持放量生产
/ J' Y' a. W3 f/ u● 产品保证(遗留问题是否解决, 产品质量目标是否符合要求)
; O. f, ^1 `+ |8 ? a/ C( t● 可靠性、可维护性、可安装性、可服务性目标是否符合要求
7 C: b* y1 P+ Z8 V" O/ t● 所有特性(含功能、性能)的目标是否符合要求/ m" I) b4 a4 Q( @
● Beta测试中的问题是否已经被解决
6 R' F, H4 M8 T( b在SVT后进行。TR6是验证阶段唯一的技术评审。TR6是ADCP和GA的判断准则之一。TR6关注于产品生产问题的状态和解决情况。" R6 z* v; z6 p) m+ g+ ^% _/ B# N
当决定产品是否能从试制中心转到制造部门,并开始放量生产时,需要考虑TR6的结果。
; |6 x8 T" J3 ]5 l$ xTR6的目标是评估产品级交付件的技术成熟度,分析继续进行发布阶段的后续活动(切换到生产、放量等)的风险。因此TR6有如下5个目的:
; e. U6 l' l7 ^, f● 作为ADCP参考输入,TR6检查产品是否可以推向市场并且确认进入发布阶段可能存在的风险。
- |4 Y3 p1 `- I! R: d% j9 P8 x6 k● TR6评审对Beta测试的产品规格和产品制造的输出、问题和解决方案的冲击。3 }- A, l1 j. U5 _9 Q/ I+ R0 U
● TR6确认最终产品配置已经文档化,所有EC(变更请求)已经生效、已经执行并且测试完成。 1 V! c% O! M# S8 ~0 i% P" W) T
● TR6确保生产和产品支持系统已经被验证,并且适合进入小批量生产。
" @, n" x' \" H8 T: V● TR6确保技术和销售支撑系统已经准备好,并且进入发布阶段后必需的相关信息已经完成。 | PQA |
292 | 验证阶段 | 更新BOM并发布最新 版本给制造(量产用) | SE-271 | 在IPD流程的各个关键点,产品构造的最新情况应提供给制造。 | SE |
293 | 验证阶段 | 外部系统认证测试和标杆测试 | TE-80 | 借助第三方或其他受约束的环境,进行行业标准鉴定(入网)测试和竞争对比测试。 | TE |
294 | 验证阶段 | 优化业务计划和风险评估 | LPDT-110 | 评审单个的功能就绪情况和风险评估并用更新的成本和期望收入优化业务计划;为发布制定总体建议。 | LPDT |
295 | 验证阶段 | 实施可获得决策的财务分析 | FPDT-60 | 基于更新的成本和收入评估,进行产品定价并准备一份定价书,清晰列出批量折扣、折价品和其他优惠保证的条款和条件。 | FPDT |
296 | 验证阶段 | 产品准备评估 | RDPDT-70 | 评审产品的技术各个方面,包括产品成熟度、质量、可靠性等;明确未解决的问题,评估风险,制定风险规避活动计划,明确并按优先等级解决问题,分析Beta测试反馈、对比测试和入网鉴定测试的反馈,并为发布评估全面的产品准备就绪情况--产品是否可操作和稳定,是否满足规定需求和规格,是否符合规定的成本目标等等。 | RDPDT |
297 | 验证阶段 | 技术支持准备评估 | CSPDT-60 | 评审产品的技术支援的各个方面。明确未解决的问题并评估风险,制定风险规避活动计划并评估为发布评估技术支援方面全面的准备就绪情况---技术文档是否可以满足批量要求,技术支援基础结构是否可操作,技术支援的同事是否经过安装支持和故障排除的培训,是否明确了要打的补丁及其优先级;有没有其它变通方法等。 | CSPDT |
298 | 验证阶段 | 制造准备评估 | MNFPDT-60 | 审视所有的制造方面的输出。明确尚未解决的问题并评估风险,制定风险缓解行动计划。评估面向发布的总体制造准备完成程度---产品能否在不同的地点按照要求的质量批量生产,制造的基础架构能否运作(生产线设备、测试设备、工艺路线、操作指导、培训等);制造工艺是否经过测试与验证;制造人员是否受过维护与解决生产线问题的培训等。 | MNFPDT |
299 | 验证阶段 | 采购准备评估 | PROPDT-60 | 审视所有采购方面的输出。明确尚未解决的问题并评估风险,制定风险规避计划。评估面向发布的总体采购准备完成程度---是否能通过不同的供应商采购到符合质量要求的供批量生产的物料,采购系统是否是可操作的和稳定的以支持物料采购等。 | PROPDT |
300 | 验证阶段 | 市场准备评估 | MKTPDT-70 | 对产品包行销的各个方面进行审视,明确尚未解决的问题并评估风险,制定风险缓解行动计划。评估面向发布的行销总体准备完成程度---如行销材料是否齐备;销售培训材料是否齐备;定单环境(例如配置器等)是否可以稳定运行,是否策划安排了促销活动,销售人员与客户的激励是否到位,客户的迁移计划是否可行,早期支持程序是否可行等。 | MKTPDT |
301 | 验证阶段 | 需求可追溯性评估 | SE-280 | 审视发布产品的文档;Beta测试的结果;QA报告;将产品的特性/功能与产品的特定需求对比,保证合同中签订的所有的需求与特性已经满足,如果有例外或背离通知产品经理。 | SE |
302 | 验证阶段 | 测试结果评审和准备评估 | TE-90 | 审视所有的测试方面的交付,明确尚未解决的问题并评估风险,制定风险缓解行动计划。评估面向发布的总体测试准备完成程度; 审视所有的测试报告与测试设备;审视制造验证测试结果;审视测试设备的安装与程序指导;审视建议的给在线测试人员的培训材料。 | TE |
303 | 验证阶段 | 资料准备评估 | TD-60 | 审视所有的文档方面的交付,明确尚未解决的问题并评估风险,制定风险缓解行动计划。评估面向发布的总体测试准备完成程度;审视所有产品文档,在线帮助,检查准确度,变更及材料修正。 | TD |
304 | 验证阶段 | 订单履行准备评估 | FF-60 | 审视所有的订单履行方面的输出。明确尚未解决的问题并评估风险,制定风险缓解行动计划。评估面向发布的总体订单履行方面的准备完成程度;如产品能否在各地合适地配置和订购;有没有合适的培训与帮助来支持订货问题;客户订单是否可以精确转化为制造订单;零部件的库存是否充足,可以满足预期的需求;运作机制是否可以满足发货;早期支持程序是否可行等。 | FF |
305 | 验证阶段 | 销售准备评估 | S-40 | 审视该产品包的与销售相关的各个方面,明确尚未解决的问题并评估风险,制定风险缓解行动计划。评估面向发布的总体销售准备完成程度;现场销售人员是否得到充分的培训来支持产品包销售; 销售人员是否了解产品的特性/功能/好处(benefit);他们是否有事实和知识(Facts and knowledge)来在竞争中胜出;销售人员是否有智力资本(Intellectual capital)来对RFP做出快速响应;是否有知识资产的装备保证对RFP迅速反馈;是否有销售人员进行配置、定价并提供客户快速报价的支撑机制。 | S |
306 | 验证阶段 | 准备可获得性决策评审材料 | LPDT-120 | 通过汇总各个重要的功能部门发布准备情况,整理DCP的信息包;评估风险与风险规避计划;评估可能的竞争对手的行动与已知竞争性产品;评估何时产品将可以大规模获得;何时销售渠道可以充分利用起来;何时制造部门可以进行大批量生产;提供并且总体评估发布的准备就绪情况并提出包括特定GA日期的发布建议;将DCP信息包分发给PAC,并排定DCP日期。 | LPDT |
307 | 验证阶段 | 准备可获得性决策评审材料 | FPDT-70 | 通过汇总各个重要的功能部门发布准备情况,整理DCP的信息包;评估风险与风险规避计划;评估可能的竞争对手的行动与已知竞争性产品;评估何时产品将可以大规模获得;何时销售渠道可以充分利用起来;何时制造部门可以进行大批量生产;提供并且总体评估发布的准备就绪情况并提出包括特定GA日期的发布建议;将DCP信息包分发给PAC,并排定DCP日期。 | FPDT |
308 | 验证阶段 | 准备可获得性决策评审材料 | RDPDT-80 | 通过汇总各个重要的功能部门发布准备情况,整理DCP的信息包;评估风险与风险规避计划;评估可能的竞争对手的行动与已知竞争性产品;评估何时产品将可以大规模获得;何时销售渠道可以充分利用起来;何时制造部门可以进行大批量生产;提供并且总体评估发布的准备就绪情况并提出包括特定GA日期的发布建议;将DCP信息包分发给PAC,并排定DCP日期。 | RDPDT |
309 | 验证阶段 | 准备可获得性决策评审材料 | CSPDT-70 | 通过汇总各个重要的功能部门发布准备情况,整理DCP的信息包;评估风险与风险规避计划;评估可能的竞争对手的行动与已知竞争性产品;评估何时产品将可以大规模获得;何时销售渠道可以充分利用起来;何时制造部门可以进行大批量生产;提供并且总体评估发布的准备就绪情况并提出包括特定GA日期的发布建议;将DCP信息包分发给PAC,并排定DCP日期。 | CSPDT |
310 | 验证阶段 | 准备可获得性决策评审材料 | MNFPDT-70 | 通过汇总各个重要的功能部门发布准备情况,整理DCP的信息包;评估风险与风险规避计划;评估可能的竞争对手的行动与已知竞争性产品;评估何时产品将可以大规模获得;何时销售渠道可以充分利用起来;何时制造部门可以进行大批量生产;提供并且总体评估发布的准备就绪情况并提出包括特定GA日期的发布建议;将DCP信息包分发给PAC,并排定DCP日期。 | MNFPDT |
311 | 验证阶段 | 准备可获得性决策评审材料 | PROPDT-70 | 通过汇总各个重要的功能部门发布准备情况,整理DCP的信息包;评估风险与风险规避计划;评估可能的竞争对手的行动与已知竞争性产品;评估何时产品将可以大规模获得;何时销售渠道可以充分利用起来;何时制造部门可以进行大批量生产;提供并且总体评估发布的准备就绪情况并提出包括特定GA日期的发布建议;将DCP信息包分发给PAC,并排定DCP日期。 | PROPDT |
312 | 验证阶段 | 准备可获得性决策评审材料 | MKTPDT-80 | 通过汇总各个重要的功能部门发布准备情况,整理DCP的信息包;评估风险与风险规避计划;评估可能的竞争对手的行动与已知竞争性产品;评估何时产品将可以大规模获得;何时销售渠道可以充分利用起来;何时制造部门可以进行大批量生产;提供并且总体评估发布的准备就绪情况并提出包括特定GA日期的发布建议;将DCP信息包分发给PAC,并排定DCP日期。 | MKTPDT |
313 | 验证阶段 | 与PAC充分沟通 | LPDT-130 | 为了提高决策时效率和质量,要保证PAC委员在正式决策评审会前,对业务计划有充分的了解,PDT成员在正式决策评审会前与PAC委员进行充分沟通。建议程序如下:( M2 W' e- h6 {' U0 h6 j
● 在决策评审材料提交给PAC成员后3到4天后与委员们进行沟通。每次沟通都要有纪要,沟通的内容就是决策评审材料(业务计划和项目计划),沟通后如有必要在业务计划中修改的,在决策评审前修改完成。7 Q/ C; L7 v6 o
● 沟通的问题汇总及答复意见在决策评审会议上要进行汇报。 | LPDT |
314 | 验证阶段 | 可获得性决策评审 | PAC-60 | 这是产品正式公开发布及推向市场前的最终决策评审,需要PAC明确做出继续/终止的决策。可发布决策评审应在任何主要的发布花费投入之前进行。 这一决策评审的目的是证实在计划阶段制定的业务计划中的估计和假设,并评估产品发布前公司的准备情况。与其它决策评审一样,PDT向PAC提供是否将该产品推向市场或取消项目的建议。如果决策结果是“继续”,则由PAC分配资金,项目进入发布阶段。* E8 V: ^, c* `9 W G3 |
在公司现阶段,发布是按一个一个特性版本进行的,所以每次发布评审要验证计划决策评审时所签合同中有关该特性版本的内容,并对业务计划进行更新。. ]6 A* E. P+ u2 V) E; l
在GA日期之后PAC要成立一个生命周期管理团队(LMT)来代替PDT继续负责在产品的整个生命周期内监管产品,PDT随后将被解散。在公司现阶段,产品是按特性版本一个一个发布的,所以,在第一个特性版本发布后,就要成立LMT,以后,每一个特性版本发布后,PDT与LMT都会有一个交接的过程,直到PDT完成最后一个特性版本后才能彻底解散,完全由LMT负起监管责任。, r0 w( R$ r! R( l2 m, K
Availability DCP决定了AD(Anouncement Date)的精确日期。同时也决定了产品达到量产规模能大量上市满足普通客户需求的日期(GA,General Availability)。
D9 ^3 V/ i3 N. Q2 L评审时需关注:该产品是否已准备好发布和发货?
9 K. c9 E$ H. w7 j! ]2 g Y( P● 业务展望( V2 V+ [- z( J1 `" I9 E- R8 E3 y, k: e
● 发货质量/ |: p, j2 n9 ?# ]/ X* x
● 发布和宣传推广计划
$ v* b& n, U* Z$ U5 N# L, G) T2 Q! K6 y) u● 渠道搭建2 D5 m0 P* L9 P5 B% r
● 服务架构7 Y7 b# S/ m1 x7 F
● 风险 | PAC |
315 | 验证阶段 | 项目经验教训总结 | LPDT-132 | 可获得性决策评审后PDT对概念阶段工作的成功经验和失败教训进行总结,并按照统一的模板和要求形成案例存储在统一的IT数据系统,并推动共享、查询和继承应用。 | LPDT |
316 | 验证阶段 | 支持试验局开通 | S-35 | | S |
317 | 验证阶段 | 支持试验局维护 | S-45 | | S |
318 | 验证阶段 | 关闭项目数据库 | POP-39 | ● 关闭项目计划/合同(LPDT);8 u) m% Q' S0 P* g1 q
● 关闭产品包(LPDT);
4 _' |8 A% w5 {7 i; @● 关闭集成项目文件/模板(LPDT);, }, J( p, M, L+ ^ e1 m) b
● RDPDT关闭共用硬件数据库(Aspect)
4 e* ^, ^# L" V● 解散组织/技能/资源(LPDT);
e% C$ ~/ j) ^. }: C7 ~3 F$ d● 释放设施及场地(LPDT);; n% f: v0 G7 k0 e5 @0 R
● 释放资金(FPDT); ?! ^' Z' d2 `7 s7 w
● 确定关键文档,在哪里存放文档的软、硬拷贝。 | POP |
319 | 发布阶段 | 更新项目文档 | POP-40 | 更新所有的项目文档。 | POP |
320 | 发布阶段 | 继续执行项目监控 | LPDT-140 | ● 对项目的执行进行持续的每周例行监视和控制。 | LPDT |
321 | 发布阶段 | 继续执行项目监控 | FPDT-80 | ● 需要时对项目的执行进行持续的每周例行监视和控制。 | FPDT |
322 | 发布阶段 | 继续执行项目监控 | RDPDT-90 | ● 每周对项目的执行情况进行例行的监督和控制。 | RDPDT |
323 | 发布阶段 | 继续执行项目监控 | CSPDT-80 | ● 对项目的执行进行持续的每周例行监视和控制。 | CSPDT |
324 | 发布阶段 | 继续执行项目监控 | MNFPDT-80 | ● 对项目的执行进行持续的每周例行监视和控制。 | MNFPDT |
325 | 发布阶段 | 继续执行项目监控 | PROPDT-80 | ● 根据项目进度,定期通知计划员查核材料状况;& o8 _5 f p4 ~2 }# |3 b$ l3 t
● 采购员进行跟踪并回复到货进度,保证物料齐套;
9 p( {& S7 R4 c! C: C1 t, H● 对项目的执行进行持续的每周例行监视和控制。 | PROPDT |
326 | 发布阶段 | 继续执行项目监控 | MKTPDT-90 | ● 继续监控准备上市的项目情况以及后期计划修改情况;输出功能确认书上市定稿;辅助有关部门确定说明书、其他功能说明以及产品宣传物料内容的准确性 | MKTPDT |
327 | 发布阶段 | Beta测试退出检查 | TE-94 | TE组织PDT相关人员按照局点退出CheckList检查该局点是否可以结束试验局状态,局点退出标准为:
7 i7 b4 T- `# H7 [● 完成了试验局最终的责任移交;1 J$ y1 {& H; u R4 J& w
● Beta测试评估通过;2 H' K6 o3 ~$ X6 a% N4 D: M( k
● 试验局协议已经完成;5 x$ I4 u1 G! Z$ z& Q
● Beta测试协议转合同谈判工作已经完成;
3 a0 N0 R( A1 B/ H% Y● 局点升级到GA级版本/拆除局点设备的工作已纳入相应工作计划中;: ^8 q0 U. Q7 {+ I' v
● 各局点的文档已升级替换成正式发布的文档;
) q) q! ?% t4 O● 试验局相关资源已释放;- Z. R& v3 q/ L) y y( R5 d' t) C
局点退出检查通过后,TE发布局点退出公告,局点退出后,该局点的全部责任主体变成工程部。 | TE |
328 | 发布阶段 | 技术资料出版、发运、储存(继续) | TD-70 | 当技术文档和其他文档经过评审和验证后,印刷纸件文档(技术手册、安装手册、用户手册等)及其翻译版本,运送到销售渠道并纳入存货目录。 | TD |
329 | 发布阶段 | 向量产操作切换 | MOPS-10 | 在这一点,制造流程已经被验证,初始产品被成功地生产出来;生产线被成功地转移到制造操作人员,他们将逐渐放大产能到量产规模,并维护生产线直至制造结束时间。 | MOPS |
330 | 发布阶段 | RAMP UP生产 | MOPS-20 | 在切换后的生产线上建立批量生产能力;订购制造用器件,测试采购系统并监控供应商绩效;下载面向生产的产品文档、制造指导书等;培训生产操作与测试人员;监控质量、生产周期,并提升流水线人员的技能;通过生产线人员参与讨论识别瓶颈与问题从而加快学习过程,明确解决办法、变通方法与长期的解决方案;重新平衡生产线,如果必要的话,增添新设备;利用“交付更改管理”使能流程来生成和评估产品设计的工程更改数量。 | MOPS |
331 | 发布阶段 | 确定发布材料 | MKTE-38 | 完成所有的发布材料最终稿。 | MKTE |
332 | 发布阶段 | 完成客户迁移计划 | MKTE-39 | 根据详细的工作计划执行用户迁移活动;准备可根据不同用户进行修改、调整的标准迁移计划;准备可根据需要进行修改、调整的标准用户协议,培训技术人员,指定人员来全面审视用户的具体情况。 | MKTE |
333 | 发布阶段 | 支持客户迁移计划 | CSS-70 | 根据详细的工作计划执行用户迁移活动。 | CSS |
334 | 发布阶段 | 向办事处/地区部分发市场资料 | MKTE-39A | 所有营销类资料开发完成后,向区域机构或全球的营销人员发送。 | MKTE |
335 | 发布阶段 | 完成订单环境的建立 | FF-70 | 加载产品构件、标准配置和配置规则到配置器中,建立用户定单系统的界面。 | FF |
336 | 发布阶段 | 试验局升级到GA级产品/拆除局点设备 | CSS-72 | 负责按照试验局升级计划组织各试验局办事处技术支持工程师对各试验局局点进行版本升级,升级过程严格按照技术支援升级流程进行,升级结束后必须完成文档刷新任务。 | CSS |
337 | 发布阶段 | 培训行销/销售人员 | MKTE-45 | 培训行销/销售人员,使他们对产品包的功能、性能及其它交付有足够了解,支持他们以后的行销/销售活动。 | MKTE |
338 | 发布阶段 | 完成发布准备/透露/培训 | MKTE-50 | 完成修改RFA标准模板文档来准备RFA包(市场紧迫性、竞争紧迫性、机会丧失可能性、暴露以前产品的缺陷等);根据收集到的信息来完成RFA文档;完成对销售员工的培训,包括师资培训;获得准入证,准备媒体发布,完成培训资料的准备,准备好正式的发布申请。 | MKTE |
339 | 发布阶段 | 渠道备货 | FF-80 | 向各个分销渠道发货,使得在GA点之前各个销售渠道能够满足部分客户的发货要求。 | FF |
340 | 发布阶段 | 接受培训和准备销售力量 | S-60 | 培训销售队伍并用市场的辅助品(如小册子等)、工具(如配置器等)武装他们以便让他们在发布日能够开始销售。 | S |
341 | 发布阶段 | 发布产品包和公布GA日期 | MKTE-60 | 向外界正式公布产品包及GA日期;发布新闻;设置WEB站点;就旧系统向新系统的迁移,与现有客户群进行特别沟通。 | MKTE |
342 | 发布阶段 | 开始销售标准产品包 | S-70 | 在产品发布与销售人员得到培训之后,销售代表开始与潜在客户联系,寻找销售目标并将完成的合同输入制造系统来生产。 | S |
343 | 发布阶段 | 制定和沟通GA确认通知 | LPDT-155 | 里程碑点GA (一般可获得性) 标志着发布阶段的结束。在GA点,PDT成功退出可获得性决策评审(ADCP),并且完成了计划中对于批量发货所承诺的所有交付件。本活动的目的在于通知所有利益相关人(包括佳讯功能部门高层领导)产品包已达GA点。PAC秘书会确保在PAC数据库中归档GA确认书。 | LPDT |
344 | 发布阶段 | 向PDT和销售发布价格 | MKTPDT-100 | | MKTPDT |
345 | 发布阶段 | 关闭项目数据库 | POP-50 | | POP |
346 | 发布阶段 | 协助做好客户关系工作 | S-50 | | S |
347 | 发布阶段 | 试验局设备转订单合同 | FF-75 | | FF |
348 | 发布阶段 | 项目结束经验教训总结 | LPDT-150 | 项目结束经验教训总结 | LPDT |
349 | 生命周期 | 组建LMT团队 | PAC-170 | 在GA点后组建LMT团队;LMT关键在于管理与协调市场销售/生产/采购/订单/售后服务之间的工作,并对产品的财务表现进行评估和管理。' X2 `2 q7 E! f7 A! @
LMT在GA点以后产品进入生命周期直到产品生命周期终止的整个过程中的工作包括:负责维护相应产品和服务;周期性或在批准/授权后更新产品;建议采取价格行动;提供补丁、升级和深层的问题支持;准备生命周期终止资料。 | PAC |
350 | 生命周期 | 协助组建LMT团队 | LPDT-160 | 协助组建LMT团队。 | LPDT |
351 | 生命周期 | 解散PDT团队 | PAC-90 | 在GA点之后,宣布解散PDT团队,并对PDT进行评价。 | PAC |
352 | 生命周期 | 准备项目环境 | POP-60 | 项目操作员准备项目环境,此时的项目环境与前开发阶段的项目环境有比较大的不同,对环境的要求比较低,主要用于存在产品维护记录、销售记录等信息,也不需要集中的项目办公环境。 | POP |
353 | 生命周期 | 更新项目文档 | POP-70 | 将生命周期阶段经常会使用的文档材料,统一放入项目文件夹,这部分文档主要是维护操作、用户指导之类的文档,为了信息安全考虑,设计文档不放入此时的项目文件夹,如果市场问题解决,需要设计文档时,需要走文档申请流程。 | POP |
354 | 生命周期 | 项目开工会 | LLMT-10 | LMT团队需要根据前期LLMT制定的产品维护计划对产品包进行维护, 包括进行量产技术支持, 售后服务技术支持, 产品质量情况分析和改良,成本管理方面的工作。 | LLMT |
355 | 生命周期 | 产品维护管理 | LLMT-20 | LMT团队需要根据前期LLMT制定的产品维护计划对产品包进行维护, 包括进行量产技术支持, 售后服务技术支持, 产品质量情况分析和改良,成本管理方面的工作。 | LLMT |
356 | 生命周期 | 提供持续的客户服务 | CSS-80 | ● 对服务资料进行日常发布、归档;
0 O; Y9 @5 y) P3 H: o● 跟踪服务支持项目的持续化运作,完善服务支持项目;
\) s0 }! P9 ~4 s7 e● 跟踪服务体系的运行,调整完善服务流程;
: Z" D6 q1 `6 Z! U0 Q● 持续跟踪客户反馈,提交客户需求报告,分析并解决客户问题。 | CSS |
357 | 生命周期 | 持续销售 | S-80 | ● 保持对渠道伙伴和销售团队的监控和管理(持续);2 V) G1 E" g3 W2 W7 i
● 按月度进行销售预测和制定销售计划,向销售团队和渠道伙伴下发销售任务,并总结完成情况(持续);
0 |# y% S" G2 b. @: [* f● 随市场变化分析竞争对手的定价策略,寻找差异,决定是否跟进打击(持续);* t. Q, L* Y9 E& E6 ]# q% c2 x/ k
● 根据销售目标及竞争战略主动实施定价策略,达到目标销量或目标占有率(持续);
" O- w# v0 x4 M6 M● 根据销售目标及竞争战略主动实施定价策略,达到目标销量或目标占有率(持续);
) G+ e: E$ A; A6 m● 保持对渠道情况的关注,挖掘新的渠道伙伴,开拓新的不冲突渠道(持续);5 a" k$ X2 r6 ^4 m
● 根据市场反馈和消费者意见调查,提出功能改进建议(持续); | S |
358 | 生命周期 | 初步分析生命终止请求 | LLMT-25 | 受理生命终止请求并进行初步分析。 | LLMT |
359 | 生命周期 | 准备生命终止评审材料 | LLMT-30 | LLMT接到有关产品生命终止的请求后,需要组织团队成员准备售后、市场、财务方面的产品生命终止评审材料。LLMT需要就生产和技术支持方面提出评审意见。LLMT要主持LMT进行内部沟通, 并将情况进行汇总。 | LLMT |
360 | 生命周期 | 准备生命终止评审材料 | FPDT-10 | 提供财务数据供生命终止评审。 | FPDT |
361 | 生命周期 | 准备生命终止评审材料 | MNFPDT-10 | 从产品库存、相关半成品库存、原材料库存、生产主计划、在制品、故障机维修、生产工装、历史订单发货数量、新/老产品替代关系等诸多因素考虑准备生命终止评审材料。 | MNFPDT |
362 | 生命周期 | 准备生命终止评审材料 | CSPDT-90 | 产品生命周期结束提交持续服务的计划和需求;+ z$ ~- Y# Q# j: Z5 B% w
为客户提供生命周期结束后的持续化服务。 | CSPDT |
363 | 生命周期 | 准备生命终止评审材料 | MKTE-70 | 在产品的生命末期,提出结束产品的评审材料,提出产品退市方案、遗留问题解决方案。 | MKTE |
364 | 生命周期 | 与PAC充分沟通 | LLMT-40 | LLMT在内部沟通汇总后,将情况提交给PAC并与PAC进行充分沟通,最终PAC可以就产品是否进行生命终止做出决定。建议程序如下:9 h, b! x& H) T
● 在决策评审材料提交给PAC成员后3到4天后与委员们进行沟通。每次沟通都要有纪要,沟通的内容就是决策评审材料(业务计划和项目计划),沟通后如有必要在业务计划中修改的,在决策评审前修改完成。
+ b h$ J- V# ^3 c0 @4 Z* f7 ~) y0 j● 沟通的问题汇总及答复意见在决策评审会议上要进行汇报。 | LLMT |
365 | 生命周期 | 生命终止决策评审 | PAC-100 | 在产品生命周期结束时,生命周期管理团体(LMT)要向PAC给出停止销售、停止生产、停止服务等方面日期的建议,由PAC做出继续/终止的决策。PAC必须要审核产品生命终止的发布是否与新产品战略保持一致、是否与推出的新产品的客户迁移策略相协调一致以及是否已很好地考虑了潜在的客户满意度方面的问题。如果通过,将按照计划分步骤地停止销售、停止制造、停止支持。如果不通过,则LMT要继续支持该产品及服务,重新定出以后EOL DCP的时间表。
8 X' e+ `) o, T& X6 O9 M) n评审时需关注:该产品应该继续保留在市场上吗?如果不需要,是否有将策略和费用都考虑进去的详细退出计划? V: E @3 R/ t
● 业务! h( u: T7 D5 s
● 开发! \; J& M/ @5 Z. ^5 g
● 市场
; d( W+ d6 A( U7 M& l0 S8 L' C8 {● 销售6 X9 Z7 |1 v" L" H0 R
● 支持结构 | PAC |
366 | 生命周期 | 项目经验教训总结 | LLMT-50 | LLMT需要安排LMT团队成员对项目经验数据库进行更新, LLMT需要就产品包的维护提交总结报告并添加到项目经验数据库中。 | LLMT |
367 | 生命周期 | 关闭项目数据库 | POP-80 | ● 协助解散组织/技能/资源(LLMT);
$ [2 `" J& N# e# N4 X x● 协助释放设施及场地(LLMT)。 | POP |
368 | 生命周期 | 宣布EOL | MKTE-75 | 宣布生命周期终止,产品退出市场。 | MKTE |
369 | 生命周期 | 关门采购 | PRO-80 | 根据销售部提出的生命周期终止安排,售后提出具体的物料需求,采购中心一次性采购所需部品。 | PRO |
370 | 生命周期 | 产品退市 | S-90 | 在产品退市阶段,提出产品退市方案,并为渠道伙伴和销售团队解决遗留问题(预期一年)。 | S |