1. 重要：识别每个备选方案的约束、假设与风险；
2. 约束：对与是否属于需求，有一定争议；所谓需求，是解决方案应该满足的所有条件和需求，所以约束，某种角度也可以归为约束；包括，在写需求文档的时候，也会把这些约束写进去；  另一种说法：需求是“要做什么”，而约束只是一种限制条件，比如不能超过预算，不能对现有的系统做修改，不能超过限定日期；
3. 假设：
4. 风险：

【评估组织当前状态】

在需要评估阶段，为商业论证中的决策做准备；是否需要通过项目，完成问题的解决，不是详细的分析；

1、

· 更细致地分析情况以发现重要信息，例如情境说明书中所述问题的根本原因；

· 并非完整的现状分析，而是希望了解当前组织的长远与近期目标，导致目标无法达成的根本原因，或是任何可能有助于机会达成的重要因素；

（注意：完整的现状分析，应该是要到 详细的需求定义之时）

2、组织架构与文化

组织架构定义 企业中工作人员之间的正式关系；

组织文化是组织成员所共有的信仰、价值与标准；

3、能力与过程

（组织内部的一些资源和能力，项目可能会比较简单；有可能组织内部没有这样的能力，有可能要开发新的系统、招新的人力等等；）

· 能力与过程描述企业所执行的活动；

· 企业所具备的知识，所提供的产品与服务，所支持的职能，以及用来决策的方法；

4、技术与基础设施

· 企业所使用的 信息系统支持操作人员执行过程、决策，以及与供应商和客户进行交互；

· 可以包括计算机硬件、物理设备，后勤，及其运营与维护；

5、政策

发现影响解决方案的空间范围，可能对所采取的行动形成制约的政策；

6、业务架构

了解当前状态的各项因素如何相互交织，以便提出有效的改变建议；

7、内部资产

识别当前状况中所使用的企业资产（有形或无形）

8、外部影响

行业结构、竞争对手、客户、供应商、政治与监管环境、技术、宏观经济因素；

【评估组织目的和目标】

· 目的（goals）通常比较宽泛（笼统），可能持续一年或一年以上（比较长的时间）

· 目标（objectives）（量化目标）用来促进目的的，更具体，相比“目的”，期限更短，常常是一年或以下；

· 目的/目标和项目（集）之间常常通过商业论证相关联；

（【分解模型】分解图，把一个比较笼统的目的，分解为阶段性具体目标，为长远的目的服务）

（解决方案，分为几个模块，每个模块包含哪些功能，功能里又有哪些具体的操作）

【SMART目标】

specific具体的

measurable可衡量的

achievable可达成的

relevant相关的

time-bound有时限的

【SWOT分析】

· 内部因素

优势 Strengths

劣势 Weaknesses

· 外部因素

机会 Opportunities

威胁 Threats

（SWOT分析仅限于从战略层次进行考察，需配合更详细的分析）

【PEST分析】

宏观环境分析

politics政治

economy经济

society社会

technology技术

【相关标准】

目的与目标提供了可用于选择项目集及项目的决策标准；

· 当目的与目标  涉及 提高收入、则扩展市场 与 增加 新产品的项目集及项目将成为关键；

· 当目的与目标 涉及 降低成本，则流程改进或节支的项目集及项目将至关重要；

【对情境进行根本原因分析】

将问题分解为问题根本原因或机会贡献因素，以便给出可行与恰当的解决方案；

· 根本原因分析：用于发现问题的潜在原因，从而制定解决方案以对其进行减小或消除；

· 机会分析：探究潜在机会的主要方面，从而确定开发新产品或服务来促成机会达成的可行性。机会分析可能需要额外的工作来研究潜在的市场；

【方法】五问法 Five Whys

询问问题的原因，可重复多达五次或五层；

示例：

客户为什么不满意？——因为没有按时工作

我们为什么没有按时完成？——因为项目耗时比我们预想的长得多

为什么耗时会长得多？——因为我们低估了项目的复杂性；

我们为什么会低估项目的复杂性？——因为我们没有使用适当的估算方法；

我们为什么没有这么做？——因为我们的项目经理们没有接受过这些方法的培训；

【方法】鱼骨图Fishbone Diagram（单方向的因果）

石川图/因果图

【方法】关联图（多方向互相因果）

· 是一种特殊的 因果图（一个问题的原因可能是另一个问题的结果）；

· 将包含多个相互交织的变化因素的复杂问题可视化；

【方法】过程流Process Flows

· 记录与分析当前及未来的流程

· 可与根本原因分析 结合使用，关注当前流程中各方面因素如何引起所要研究的问题；

【确定  针对现状所需的能力】

确定纠正根本原因与贡献因素，或是利用机会的方法；

可提出流程改进或新增能力的建议；

通过正式的根本原因分析，避免  过快 跳至 解决方案；

【能力表】Capability Table

问题/当前制约因素--根本原因--新能力/功能

【方法】亲和图

· 对各种设想进行归纳分类（大类/小类），使得相关设想相互关联；

· 可用于组织与整理主要的原因类别；并根据解决它们所需要的能力进行归类；

【方法】标杆对照

· 竞争分析通常可分为三类：

浏览公开文件如报告或网页；

研究主要可变因素，或在竞争对手处秘密购物；

逆向工程？

· 类似于竞争分析，标杆对照可针对其他组织在面临相同挑战时的应对措施提供深刻见解；

（同样的行业，不同的行业，也可以是不同部门）

【方法】能力图

即使多个业务部门都具备某项能力，在能力图中每项能力 只出现一次；

【发现组织能力差距】

· 在  当前状态  与  所需状态  之间的任何差距或缺失的能力 就是需要新增的 能力；

· 这些能力通常被称为“将要”（to be）特征与功能；

· 方法：差距分析

分析与对比期望绩效 与 组织实际绩效；

识别与确定 改变现状所需采取的步骤；

用于建立商业论证；

《识别问题或机会》

业务部门假想的解决方案；

问题来源：可能来自于组织内部，也可能来自于组织外部；

---书面---

商业问题：描述阻碍企业实现其最大价值的情景

商业机会：描述未企业增加价值的机会

避免过早关注解决方案，重点应该放在当前环境并分析已有信息上；

【项目驱动因素】

许多因素可能促使企业投入一个新项目；来自组织的不同层次：

CEO老板层面（自上而下）：需要实施一项战略目标；

自下而上：现有过程、功能、系统存在的问题；

项目经理等（中层管理）：经理人员需要额外的信息或功能；

--

外部驱动：客户需要、竞争对手（你不这样做，可能就会被落在后面）、技术环境（技术环境改变形成的问题来源）、法规制度（比如监管机构，行业相关规定规则，在寻求解决的时候，是一定要考虑的）等；

【识别干系人Stakeholder】

干系人：能影响项目决策、活动或结果的个人、群体或组织；

以及会受到或自认为受到项目决策、活动或结果影响的个人、群体或组织；

——相应的：在需要评估时，会进行干系人识别 以 评估所分析的领域会影响到哪些干系人；

（不管他是不是受到影响，但他认为自己可能会受到影响，其实已经影响到你，你也需要认真考虑；

影响：实际存在、潜在、不确定性的）

【可能的干系人】

启动或负责项目的发起人；

从一个改进的项目（集）受益的人

对解决方案提供财务或其他支持的人

使用解决方案的人

角色与/或所执行的工作可能随解决方案而发生改变的人

可能监管或制约潜在解决方案的人

将要实施解决方案的人

将会支持解决方案的人

【方法：RACI模型】

Responsible负责执行——比如多个开发

Accountable问/负责——最好是只有一个人

Consulted咨询——向这部分人收集信息

Informed告知——状态结果需要通知到这些人

【调查问题或机会】

了解问题或机会以获得对现状的正确理解，

但避免在本阶段进行完整的需求分析；

方法：

访谈；——问题所有者的干系人

文档分析——搜集已有文档，当前操作规范

流程建模——有助于发现流程中的瓶颈

观察法；——实地观察，在实际的工作环境中；问题/机会的调用；

【文档分析】

利用分析现有文档并识别与需求相关的信息，来挖掘需求；

文档示例：

商业计划书；市场文献；协议；征求建议书；当前流程；逻辑数据模型；业务规则库；应用软件文档；业务流程或接口稳定啊；用例；其他需求文档；问题记录；政策、流程与法规文件：如法律、发典、条令等；

文档分析的方法（三步）：

准备；

确保所要审阅的内容是相关的、最新的、真实的、可信的、可理解的；【有效的！与现在是吻合的】

定义需挖掘的数据与数据集；

文档审阅与分析：【文档收集可能是片面的，文档可能是不清楚不齐全的-有局限性；文档分析和访谈结合使用；访谈中如果和文档不一致，就要去确认核实；】

进行详细审阅并记录笔记；

发现矛盾或重复之处；

注意：需要进一步研究的缺失之处；

记录结果：（可以是正式报告，也可以是适合的其他非正式记录方式）

确保工作成果的内容与详细程度适合于计划中的听众；

提供视觉辅助、以提升听众理解；

【搜集相关数据以评估情境】

搜集相关数据以了解问题或机会的规模（“估量”现状）

方法：

1标杆对照Benchmarking-将一个组织的指标数据或流程与行业中的相似组织进行比较；

（将组织实践与竞争对手、政府或行业协会的最佳实践进行对比）

确定研究领域->发现领域中的领先企业->调查研究以理解它们的实践->使用信息请求书或实地考察搜集信息->确定差距->制定实施建议；

（可以照抄照搬的办法；但其不是创造性的思维，能够做到的是，最多和它一样好，不能突破）

2帕雷多分析-80/20法则-基于帕雷多原则进行决策分析的方法（各个领域普遍适用的原则）

（发现的问题很多，但并不是都要在当前的项目中完成）

估计每项行动所能提供的价值，选择一组最有效的行动，使得2它们所提供的总价值在合理前提下接近可能的最大价值；

（根据问题出现的频率来排序；

计算累积的百分比；

看一下，出现频率最多的几个问题累积占百分比，可能把排名前三的问题解决了，就解决了80%以上的问题——看哪些问题是需要着重解决的）

【场景分析】更多从用户的角度解决问题

从解决方案的用户（人员或其他系统）及其与解决方案的交互角度描述一个特定的解决方案；

从用户与所交互的系统角度考察当前环境，以更好地理解问题或发现可利用的机会；

场景可以为后续的用例或用户故事设定基础，因而在需求分析中起到重要作用；

【用户体验历程图】在使用解决方案中所经历的操作；

采用图形化的形式描述系统的实际用户在一个流程的整个过程中的路径；

【起草情境说明书】

记录当前需要解决的问题或需要开拓的机会；

如果没有情境说明书，或说明书有误，或者干系人对情境/情境说明书有不同看法，则所提出的的解决方案不恰当的风险就非常大；

情况说明的格式如下：

“A”问题会造成“B”结果，所产生的影响是'C"

情境说明将包含在正式商业论证中；

【获取情境说明书批准】

获取事先确定的相关干系人的同意；

如果跳过正式的情境说明书和批准步骤，就比较难以确定是否已了解当前情境的本质；

商业分析师发起并促成批准过程（可能是正式或非正式的）

商业分析师需要运用协调，谈判与决策

《需要评估》

一、

对问题要达成的目标，进行确定；

1. 定义业务问题

审查业务问题（或机会）

划定本次项目解决的问题；（或为商业论证（business keys，问题是什么，解决这个问题能够带来多大的收益，同时评估投入成本，判定是否有开始项目的必要）提供输入）

【商业论证】：在立项之前，决定是否立项，商业论证，为立项提供决策支持；

2. 确定价值主张

确定采取行动的 价值主张-->商业论证的过程

3. 定义方案范围

通过澄清业务需要 与 方案范围，协同建立项目长远与近期目标，从而保证产品与组织目标保持一致；

项目BA所负责的范畴；

4. 识别干系人

通过审查长远、近期目标与需求来识别干系人，从而使相关各方有所代表、告知和参与；

5. 确定干系人的价值

确定产品对干系人的价值，从而为需求的优先级划分提供基准；

二、

需要评估的领域——

理解一个业务问题或机会，并对不同输入进行评价、以帮助建立一个有效的解决方案；

· 识别问题或机会

· 评估组织当前状态

· 建议 满足商业需要的行动（涉及到投入成本计算）

· 组合商业论证（带来的效益与投入比较）

三、为何要做 需要评估

1、保证 所解决的  是 需要解决的问题；最重要的；需要分析 --现象-- 的 -->【原因】--真正的需求--制定解决方案；

认清问题的本质：机身和机翼的故事

发现战场回来的飞机，机身很多受到创伤

就认为，弱点在于机身，加固机身；之后的结果，并没有很好的改善；

事实是，战场中机翼一旦受创，生还的可能性极低；机身即时有一定受创，但依然可以返回；

所以，不仅要加固机身、更加需要加固机翼；

遇到业务人员的需求，多问几个why--追究问题的源头，可能会发现更好的解决方案；

流程中出现的问题，或者是出现的“机会”

（问题：期望的是十分，实际可能是8分，和期房有差距，有待改进；

机会：实际和期望，可能没什么差距，因为技术环境或者业务环境的改变，发现新的改进契机）

有些问题原来是

-------书面描述---------

帮助组织深入理解业务问题或机会，从而保证所解决的是需要解决的问题；

如果忽视了需要评估，结果将是解决方案不能解决潜在的商业问题或是完全解决问题，也可能是提供一个不需要的或包含不必要功能的解决方案；

需要评估中完成的大多数分析用于商业论证的开发。需要评估和商业论证是确定项目目标的基础，并未项目章程提供了依据。

检查行业环境，找到当前商业问题或机会；

可以由商业干系人依据内部方法论正式提出，或是由商业分析师提议；

需要分析工作是在项目或项目集开始之前执行，因此包含了项目前活动；

㘝外部因素发生了改变，应当回顾之前所做的需要评估与决策，并确保它们对正在解决的商业情境仍然有效；

《需求的定义》

1、PBA工作围绕 需求

2、需求定义：

A. 某个产品、服务或成果必须达到的    条件/能力（根据合同或其他正式的强制性规范）；

B. requirement和needs的区别：

needs：问题的所有者 客观上存在的；

需求分析人员：通过去了解needs，整理、分析，形成产品的需求方案，完整准确地反映needs；needs是输入、requirements是输出；

如果需求分析不当，needs与requirements可能会有偏差；

而我们的项目是基于requirements，所以做出来的产品，可能不能完全满足实际需要；

C. 

需要：来自于企业、个人或群体；

商业分析师：与企业个人或群体进行沟通；对需要 进行描述何分析 得到 需求（能力或条件）；（需求可以是文档形式、或者敏捷中的瀑布流形式、或者其他形式）

需求：作为 解决方案团队的 输入；根据需求，来设计满足需求的 产品、服务或成果；

产品、服务或成果：理论上，是应该满足需求的，也是满足需要的，能够解决 问题所有者 的问题；

BA：是 用户 和 解决方案团队之间 沟通的纽带和桥梁；

需求：真正要解决的问题，和 解决方案  之间的纽带和桥梁；

需求的重要性在于，保证最终的解决方案 能够真正的 解决问题；

3. 需求类型（来源、时间轴）

3.1 商业需求：最高层级，描述整个组织的高层级需要，如果要实施，这种需求不够明确，需要进行细化；

3.2 干系人需求：比如若干具体业务部门的需求；

3.3 解决方案需求：将需求提交给 解决方案团队，根据干系人需求，进行解决方案的设计分析；

3.4 转换/过渡需求：

当前状态过渡到将来状态（比如项目上线，新系统取代原有系统），需要一些临时的能力与运营变化（比如，需要数据切换，需要培训干系人，操作人员的职责分工等等）

时间段：

转化需求：过渡期，渡过后，这部分需求就失去意义；

解决方案、干系人、商业：持续、可能review、reuse；

4. 需求的分类-解决方案需求

功能需求&非功能需求

功能需求：产品能开展的行为；（直接反映业务人员的需要）

非功能需求：确保产品有效，所需的环境条件与必须品质；（系统正常运行的额外条件，比如：在线率、时间性能、安全性、可扩展性、移植性、用户友好度等等）

【功能需求：能用；非功能需求：好用】

【在需求定义时，可以事先替干系人想到，有一些非功能需求，也可以事先确认，比如，页面加载多久是可以接受的，并且以专业角度告知，与网络状态相关（除了系统本身）】

【要验证需求，需要有验证指标依据；】

5. 其他需求类型（不在商业分析师角色职能范围内，但在实际工作中，也有可能被分派此类需求任务）

项目需求：项目需满足的行动、过程或其他条件；

质量需求：必须达到的条件或局部的能力，借此验证成果属性的可接受性和评估成果的质量一致性；

6. 其他定义：项目、项目集、解决方案

一个项目是 为创造一个独特的产品、服务或结果而进行的临时性工作；

一个项目集是 一组相互关联且被协调管理的项目、子项目集与项目集活动，以便获得分别管理所不能提供的优势；

一个解决方案   通过解决一个问题或利用一个机会来满足业务需要，以获得 [项目或项目集的]产品、服务或最终结果；

PBA
一、在项目中，运用商业分析领域的专长，来提升项目整体成功的角色；

二、CBAP 与 PBA知识体系比较：

CBAP（BABOK作为背景了解）——PBA

a. 策略分析——a.需要评估

b.商业分析计划与监督（监督，如何评价BA工作绩效、调整，但基本上也是制定计划）——b.计划

c.启发与协作+需求分析与设计定义——c. 分析

d.需求生命周期管理——d.跟踪与监督

e.方案评价——e.评价

三、它们包含的知识理念是相通的，只是概念名词（说法）可能不一样；

四、

项目中的BA——PBA

企业/组织中的BA——CBAP

一、所需储备之

行业知识：懂行，才能真正理解需求，才能做好需求满足；

沟通纽带：业务人员和技术人员沟通的纽带，既懂商业又有一定技术能力/意识的人；

影响力：deliver思想

谈判技能：达成一致

组织技能：有条不紊地开展

问题解决：定义问题、对问题分析、对问题管理

系统性思维：IT系统对整个公司、各个部门造成的影响；

技术意识：思考系统实现的时候、与技术团队沟通时，需要具备的能力

teamwork：融入团队、才能开展以上种种事宜；

二、商业/业务分析VS项目管理

2.1 职能

从职能上讲，这是两个角色，但在实际的职务中，可能是一个项目经理同时担任了这两个角色；

需求是 整个项目生命周期的第一步，商业分析，就是识别、分析、管理这些需求，以形成正确的项目目标；

项目管理贯穿整个项目生命周期；

需求分析后的项目管理，是将知识、技能、工具、技术应用于项目目标的实现的过程；

2.2 协作

如果BA和PM是2个职位

规划：BA和PM必须紧密协作

需求的规划，是商业分析的工作之一

也是项目管理的工作之一

需要合适的分工、协作（输出--输入）

非功能需求包括性能、可用性、兼容性、维修性等，非功能性需求一旦出问题，可能导致整个系统无法使用。

净现值：将未来所有成本与收益折算为当前的价值。

内部收益率：当净现值为0时的的利率（或贴现率）。

立场分析

狩野模型

识别商业需求

建议相关解决方案，并启发、文档化和管理需求

需要评估，分析，跟踪与监督，评价，规划

问题机会

情境分析

建议

评价

定义问题--》设定解决问题的目标--检查差距和能力缺陷

--》弥补能力，需要哪些行动办法

约束 假设 风险

备选评估，

    加权评分排序，

    成效分析（PBP，ROI，IRR，NPV）

    力场分析

     狩野模型Kano Model

     净推荐值 用户忠诚度

     目标对齐模型（业务关键度/差异化，矩阵）

        合作     差异

        放弃     均等

     价值流程图

什么是商业分析？

商业分析是知识、技能、工具和技术的应用，目的是：

确定问题和识别商业需要；

针对问题识别并建议可行性的解决方案来满足这些需要；

启发，文档，并管理干系人以满足商业和项目的目标；

促进产品、服务、或者项目集、项目最终结果的成功实现；

简而言之，商业分析是识别商业需要，建议相关解决方案，并启发，文档化和管理需求的一系列活动。

确定问题并识别解决方案：需要评估

评估的方向和准确度非常重要，需要确定准确的目标

非功能需求，一定要量化能明确目标，制定出目标的标准是什么。