系统规划是信息系统生命周期的第一个阶段其任务是对企业的环境、目标及现有系统 的状况进行初步调查根据企业目标和发展战略确定信息系统的发展战略对建设新系统 的需求做出分析和预测同时考虑建设新系统所受的各种约束研究建设新系统的必要性和 可能性。根据需要与可能给出拟建系统的备选方案。对这些方案进行可行性分析写出可 行性研究报告。可行性研究报告审议通过后将新系统建设方案及实施计划编写成系统设计 任务书。信息系统建设是投资大、周期长、复杂度高的社会技术系统工程。系统规划可以减少盲目 性使系统具有良好的整体性、较高的适应性建设工作有良好的阶段性以缩短系统开发周 期节约开发费用。目前国内企业建设的信息系统单项应用的多综合应用的少系统适 应性比较差难以扩充。缺乏科学的规划是造成这种现象的原因之一有些规模较大的项目 由于没有系统规划和科学论证上马时轰轰烈烈上马后困难重重导致骑虎难下的局面不 仅造成资金、人力的巨大浪费而且为今后的系统建设留下隐患。因此系统规划是信息系统 建设成功的关键它比具体项目的开发更为重要。10.1 系统规划概述长远规划对于任何需要经过较长时间努力才能实现的事情都是非常重要的例如人的职 业规划就是如此。现代企业的结构和活动内容都很复杂外部环境和市场需求变化很快而企 业信息化建设需要经过长期的努力因此必须进行系统规划根据企业目标和发展战略以 及信息系统工程建设的客观规律并考虑到企业面临的内、外部环境科学地制定信息系统长 期发展战略合理安排其开发建设的进程。1. 系统规划的需求我国企业从20世纪80年代开始进行信息化建设随着IT 技术的发展和社会经济的进步 特别是国际化和信息化的推进信息系统建设的需求日趋紧迫。尽管企业信息化已经有了很大 的发展但不少已经建成或正在建设的系统仍然存在很多问题。这些问题主要体现在以下几个 方面(1)系统建设与企业目标和发展战略不匹配项目匆忙上马跟随潮流忽视企业内生的 需求。已经建成的系统解决问题的有效性低系统建成后对企业管理并无显著改善。(2)系统建设周期长不能适应环境变化和企业变革的需要不能满足日益变化的市场 需求。(3)耗巨资建设新的信息系统或者引进国外先进的信息系统但企业的组织结构陈旧348 系统分析师教程(第2版)管理思想落后导致“一只脚在马车上另一只脚在飞机上”,从而使信息系统沦落为奢侈的摆 设品。(4) IT 和系统开发技术日新月异但企业人员素质普遍偏低不能合理地操作和使用信息 系统更谈不上系统运行管理和维护。(5)系统技术方案不合理承建方出于自身利益的考虑给用户强加不需要的功能把用 户作为新技术的试验品。而建设方限于自身的技术水平和能力对此也是无能为力。(6)系统开发、运行与维护的标准、规范比较混乱企业各自为政甚至一个企业的内部 出现多套不同的标准。国家有关标准未能得到有效地执行而且某些国家标准的可执行性还 有待商榷。这样导致系统成为一个个的信息孤岛无法实现信息共享和整合。(7)企业还处在原始积累阶段资金不足却自不量力东施效颦。资源短缺投入太少 而对系统的期望又过高导致信息系统建设变成“烂尾工程”。造成以上问题的原因是多方面的其中一个主要原因就是人们更多地关心信息系统的开发 技术和具体功能而对于系统的总体方案考虑较少对发展战略问题不够重视。总之在信息 系统建设中往往缺乏科学而有效的系统规划。2. 系统规划的主要步骤根据系统规划的主要任务可以按照以下步骤开展系统规划工作(1)对现有系统进行初步调查。根据企业战略和发展目标从类似企业和本企业内部收集 各种信息站在管理层的高度观察企业的现状分析现有系统的运行状况。(2)分析和确定系统目标。系统目标应包括服务的质量和范围、政策、组织和人员等它 不仅包括信息系统的目标还要反映整个企业的目标。(3)分析子系统的组成和基本功能。自顶向下对系统进行划分并且详细说明各个子系统 应该实现的功能。(4)拟定系统的实施方案。可以对子系统的优先级进行设定以便确定子系统的开发顺序。(5)进行系统的可行性研究。编写可行性研究报告召开可行性论证会。(6)制定系统建设方案。对可行性研究报告中提出的各项技术指标进行分析、比较落实 各项假设的前提条件制定系统建设方案并根据该方案及其实施计划编写成系统设计任务书。 系统设计任务书经上级主管部门批准后正式作为系统建设的依据。10.2 项目的提出与选择企业在信息化过程中可能会实施各种信息化项目建设多种信息系统。这些系统的建设 不是“随心所欲”而为而是有其特定的目标的从大方向来看信息系统建设的目标就是促 进企业管理提高工作效率从而提高企业竞争力从小的方面来看各种信息系统都有其自 身的使命和目标。因此系统分析师要善于根据这些目标来确定系统的工作范围提出系统选 择方案并给出选择结果。第10章 系统规划与分析 34910.2.1 项目的立项目标和动机企业在运营和管理过程中对于信息系统项目的建设可能具有多种动机通常可归结为4 种模式分别是进行基础研究、进行应用研发、提供技术服务和产品的使用者。1. 进行基础研究此类项目通常由大学、科研院所、企业集团从事基础研究的部门提出和实施。小规模的研 究团队可能仅仅是企业中的一个从事研发工作的部门中等规模的研究团队可以是研究所或研 究院等类似的独立建制的单位大规模的研究团队可以是国家973计划这样跨行业、跨地域协 作的国家级研究项目组织。基础研究通常都被看作是一种长期的战略性投资目标不是为了短 期的市场收益和支持当前的市场或行业应用而是为了开拓未来的市场创造全新概念的产品、 产业或生活方式建立企业、行业甚至国家的竞争优势。基础研究更多体现为一种探索性研究成果多体现为某种理论体系和技术成果通常没有 具体的产品发布目标也没有苛刻的时间限制甚至连阶段性目标和长期目标也是由研究人员 自己来设定的。在研究过程中需要研究人员充分发挥想象力和创造力突破现有理论或技术 模型的框架提出全新的理论体系和技术或产品。2. 进行应用研发此类项目通常由企业进行立项和开发企业立项的基本动机是得到应用产品并向目标 客户群进行销售从而占有市场份额并获取利润。产品一般会基于某类特定客户群体的需求进 行设计有明确和具体的研发目标需求有严格的时间限制和资源预算大多以项目方式进行 组织。应用研发型的产品具有一定的通用性客户可能是面向个人消费者的工具(例如办公软 件、杀毒软件等)和面向特定领域的工具(例如AutoCAD工程绘图软件、Rose 建模软件等), 也可能是面向特定行业中具有一定普遍适用性的业务、可作为产品进行销售的企业级系统(例 如ERP 、CRM、新闻发布系统等)。3. 提供技术服务对此类项目进行立项的企业通常能向目标客户群提供比较全面的技术服务而不是单一 的软件产品。服务范围可能包括提供技术和解决方案的咨询、利用现有产品进行系统集成和 服务、面向特定客户的项目定制开发、对现有系统进行升级和改造、提供系统应用相关的技 术支持、服务和培训等一个企业可以提供其中的一项或多项内容。这些企业通常可能以系 统集成商、项目定制开发商、咨询商、整体解决方案提供商等各种角色出现。此类企业通常 会面向一个特定行业具有相对稳定的客户群体具有系列化的产品和基于这些产品的技术 解决方案企业对自己所处的应用领域有比较深刻的理解能够整合技术、产品、方案和应 用通过提供一种综合性的技术服务而不是单一产品来占有市场份额和获取比提供产品 更高的利润。350 系统分析师教程(第2版)4. 产品的使用者产品的使用者是系统的最终用户。对他们来说项目的立项动机既不是得到产品进行销售 也不是为了提供技术服务而是通过采购产品或技术服务来得到使用价值。例如个人消费者 购买绘图软件是为了存储和处理个人数码相机中的照片企业通过部署ERP 系统可能是为了达 到科学计划生产、提高管理水平、降低库存成本、提高资金周转率等目标并期望通过这些目 标的实现来增强企业竞争力获取更大的市场份额。产品的使用者可能采用各种方式来进行项目立项例如采购或定制开发。具体采用哪种 方式需要根据企业的实际情况(例如技术实力)和成本而定。10.2.2 项目立项的价值判断项目提出后能否达成一个成功的立项取决于人们对项目收益预期的价值判断。不同类 型的信息系统项目立项具有截然不同的价值观和侧重点。通常以基础研究为目标的项目是 高度技术研究导向的以应用产品开发为目标的项目重点关注的是技术在具体领域中的应用和 推广以技术服务为目标的项目则是高度客户业务导向或客户满意导向的产品的最终用户则 主要关注系统的使用、影响和代价等应用性问题。这些价值观彼此之间并不矛盾只是使用信息技术的程度不同对于信息系统项目预期价 值的视角不同。但这些对项目基本的价值判断决定了系统分析师在项目从立项到完成的全过 程中需要长期、重点关注的问题与侧重点之所在。从企业的角度来看待信息系统项目立项项目并不是一个简单的、通过技术开发来得到系 统和完成项目的过程。通常企业总是通过产品开发、提供技术解决方案、整合外部资源、提 供咨询和技术服务、销售或运营、进入买方价值链或开创新的领域这6个层面来获得价值和利 润得到前者作为基础之后才能去谋求后者。根据企业定位不同或企业所处的时期不同可 能扮演不同的角色侧重面也就不一样。企业并不把系统立项和开发完成看作是获取价值的终点而仅仅是一个起点。不同的企业 或同一企业的不同时期看待信息系统的价值和作用也截然不同。企业最终需要的可能是获取 利润、占有市场份额、提高影响力、广泛的社会效益等这些潜在的商业价值目标信息系统则 常被作为支持性手段来支撑这些目标的实现。因此在很多情况下系统分析师需要超越技术开发的范畴去考察信息系统建设背后的目 标问题以便确定信息系统项目的工作范围、开发边界、项目的阶段性目标以及未来系统需 求变更的根源。从获取用户初步需求开始更进一步地去观察项目价值和目标以及项目背后 的企业战略问题辅助企业的经营管理层勾画项目远景目标和项目实施的路线蓝图完成项目 计划到实施的最终决策过程并最终通过合理确定软件项目的开发边界规避那些因开发目标 错误导致的根源性失败。10.2.3 项目的选择和确定当项目建议提出来后就需要对项目进行选择和确定。在实际工作中并不存在一个统一的模式进行项目的选择和取舍但存在一些进行项目评估的基本原则通过使用这些原则可 以逐步排除那些不符合需求的建议项目选择和确定满意的项目。1. 选择有核心价值的项目这个策略的关键在于确定什么样的项目是有价值的。由于立项单位所处的行业、在行业中 的位置和立项目标等因素不同对信息系统项目的价值判断也有所不同。但是一般来说有 核心价值的项目总是和企业的核心业务相关的也可以说信息化的关键就是核心业务的信 息化。2. 评估所选择的项目在判断出一个具有潜在价值的项目后还应评估项目实施的约束、风险、成本和效益。通 常这部分内容可以在项目的可行性研究工作中完成。所谓项目约束是指在系统开发过程中“不能做什么”的原则。这些约束有些来自客户 有些来自企业本身还有些来自外部环境可能包括企业约束、资源约束、能力约束、环境约 束和用户约束等。一些明显的约束条件可以在立项阶段就评估出来但隐性的约束则容易被忽 视从而导致各种项目实施中的风险。项目约束通常是开发者不可控制的因素对于这些约束 必须时刻关注才能尽可能规避风险。如果明显违背这些约束条件就会导致信息系统项目不可 避免的失败。对于购买产品或技术服务的企业来说除了考察上述项目约束外还应该评估项目实施后 的影响。例如对自身业务变更的影响、组织机构和人员职责的影响、相关的系统维护、运行 规约和规章制度等以及项目的效益、当前成本、未来的总持有成本是否能接受等。经过项目初步评估后可筛选掉多数不符合企业要求的建议项目。3. 项目优先级排序经过项目评估后如果还有多个建议项目但企业资源有限不可能同时建设这些项目 就需要对已选择的项目进行优先级排序合理使用企业资源使资源得到最优配置。具体的 排序方法是根据企业已有资源情况进行项目的成本效益分析考察净现值、投资回收期等 指标。4. 评估项目的多种实施方式对于已经确认有价值并且有能力开发的项目则可以进一步参照企业现状考察项目的实 施方式。这个过程一般由项目的负责人和企业中高层经理进行决策。根据具体情况不同企业 要开发信息系统既可以自己组建开发团队进行项目开发也可以把系统开发任务承包给其他 企业或者购买产品并进行系统集成还可以自己完成技术方案和设计然后把编码和测试任 务进行外包等。对这些项目实施方式的取舍主要依据是对项目风险、收益和资源开销等方面 的考虑其根本目标是为了优化和合理运用投入项目的资源。5. 平衡地选择合适的方案人们在选择可行的方案时总是希望能尽量得到一种高质量、低成本的产品和方案。开发人员通常也很愿意在系统开发中向产品中加入激动人心的“创造性”的内容。另一方面客 户单位在面对诸多的投标方案时会听到各种各样关于技术先进性、快速开发、产品质量稳定 可靠、价格如何低廉、推荐的方案有多少成功应用等宣传。这些内容本身存在很多矛盾简要 列举如下(1)技术风险。采用成熟的技术可能享受不到新技术带来的好处但流行的新技术可能是 不稳定的从而导致风险。新技术也意味着开发人员需要更多的学习时间从而导致开发成本 的增加。(2)用户锁定性。不基于某种快速开发技术或平台构造的系统可能会提高项目开发时间而 导致更多的开销和成本但基于某种平台的产品又可能使得用户未来“绑定”在某种平台之上 减少了自由选择的能力甚至未来被迫接受厂商的定价和服务。(3)扩展性。不考虑系统的扩展性将导致业务变更时受阻于已经建设的信息系统重新 改造这些系统既增加成本又导致大的影响几乎是一种灾难另一方面如果过多考虑系统的 扩展性用户常常可能在当前的采购中购买了一些自己并不需要的特性从而支付了更多的成 本由于信息技术发展迅速当用户期望进行系统升级的时候常常会发现原来的开发平台早 已被淘汰和抛弃。(4)目标偏离。出于希望达成交易的需要供应商更愿意宣传技术先进、价格低廉、快速 提交、系统的新特色和新性能等因素。在用户对信息技术、作用和代价不甚明确的时候容易 受到宣传的影响从而偏离对原有目标的关注。事实上对系统功能和性能的要求常常是充满矛盾的任何时候都不存在一个完美无缺 的方案只存在一个对当前的项目目标相对比较合适的方案。选择项目的基本原则应该是“合 适”,而不是尽可能的“好”。实际上任何超出预期设定目标的“好”性能通常都意味着某 方面更多的成本或者潜在的风险。系统分析概述在信息系统生命周期中系统分析是系统开发中最重要、最困难的阶段它是应用系统思 想和方法把复杂的对象分解为简单的组成部分找出这些部分的基本属性和彼此之间的关系 的过程。信息系统分析强调业务问题方面而非技术或实践方面。实践证明系统分析工作的 好坏在很大程度上决定了信息系统的成败。1. 系统分析的任务系统分析阶段的基本任务是系统分析师和用户在充分了解用户需求的基础上把双方对新 系统的理解表达为系统需求规格说明书。新系统既要源于现有系统又要高于现有系统。也就 是说新系统要比现有系统功能更强效率更高使用更方便。系统分析师要在系统规划的基 础上与用户密切配合用系统的思想和方法对企业的业务活动进行全面的调查分析详细 掌握有关的工作流程收集与系统有关的各种资料分析现有系统的局限性和不足之处找出 制约现有系统的瓶颈确定新系统的逻辑功能。第10章 系统规划与分析 3532. 系统分析的难点开发软件系统最困难的部分就是准确说明开发什么,因为用户往往很难给出完整、正确 的原始需求也很难想象出未来的软件应该提供哪些功能以解决自己的业务问题。这些都 需要软件开发人员协助通过多次的讨论方能最终确认。而如果前期需求分析不透彻一旦 出错将最终会给系统带来极大损害并且以后再对它进行修改也极为困难容易导致项目 失败。系统分析阶段的难点主要包括以下三个方面(1)系统分析师与用户对系统的理解不同。一方面系统分析师通常是IT 专家但缺乏足 够的用户业务领域的知识系统分析师在分析过程中往往被各种信息流程所淹没难以厘清头 绪更难以分析出制约现有系统的瓶颈问题另一方面用户精通业务但通常缺乏足够的IT 知识。对于一些具体的业务用户往往认为这是理所当然的因此无须介绍。但事实上系统 分析师却难以理解。(2)系统分析师与用户沟通困难。系统分析师与用户所处行业不同知识结构不同经历 不同使得双方的交流十分困难。这样就容易导致系统调查出现遗漏和误解。这些遗漏和误 解就是系统的隐患会使系统开发偏离正确的方向。(3)环境的不断变化。系统分析阶段要通过调查分析抽象出新系统的逻辑模型锁定 系统边界、功能、处理过程和信息结构为系统设计奠定基础。但是企业内、外部环境总 在不断地发生变化对信息系统提出新的要求。只有适应这些要求信息系统才能生存下去。 在系统分析阶段系统分析师需要充分考虑环境的变化但是这有时是十分困难甚至是不可 能的。10.4 问题分析系统问题分析是软件工程中的一个重要阶段它是指通过对问题领域进行综合分析以识 别和定义系统问题从而为后续的软件开发和系统设计提供指导和支持。在系统问题分析中 分析人员需要收集和分析相关的数据、信息和需求以了解问题领域的特点、需求和限制条件 同时还需要识别和分析问题领域中的各种问题和矛盾从而为系统设计和实现提供基础和支持。10.4.1 研究问题的领域在问题分析阶段项目团队首先试图了解当前系统。每个系统所有者、用户和分析员对系 统具有不同层次的理解——不同的详细程度、不同的表述方式、不同的感知和不同的观点。组 织良好的研究可以对各方都有启迪作用甚至包括系统自身的管理人员和用户。研究问题领域 很重要业务问题、机会、指示和约束条件都存在于这个领域中。这个任务将由项目经理领导但由资深系统分析员主持。一个人同时扮演这两个角色十分 常见。其他系统分析员也可以参与进来进行面谈、为会议做记录和记录调查结果。详细的研 究应该包括来自支持该系统和项目或受其影响的所有业务部门的系统所有者和用户代表。为了覆盖正被研究的系统的全部范围包括足够的用户就显得特别重要。在某些组织中一个或多 个有经验的用户被全职“出借”给项目作为业务分析员但是很少有哪一个用户能够完全代 表所有用户的利益。然而业务分析员可以作为推动者让合适的人参与进来同时保持与业务 部门和管理层的有效沟通。系统设计人员和构造人员很少参与这个任务除非他们被请来确定 当前系统的某些技术限制。在这个阶段经常使用上下文图作为辅助工具。上下文图是一种用于显示系统或过程在其 环境中与其他实体之间的交互作用的图形工具。上下文图显示系统或过程与外部实体之间的输 入和输出关系以及它们之间的控制和反馈关系。上下文图通常用于系统或过程的需求分析和 设计阶段以帮助系统分析师和设计师更好地理解系统或过程与其环境之间的相互作用因此 上下文图也被称为环境图或系统图。构建上下文图包括以下几个步骤(1)确定系统的边界。首先需要明确系统的边界即系统所包含的所有元素和外部环境的 界限。(2)识别外部实体。在系统的边界内部需要确定和系统进行交互的外部实体例如用户、 其他系统、外部设备等。(3)识别过程。在系统边界内部需要识别所有的过程即系统内部执行的所有活动例 如数据处理、计算、通信等。(4)绘制上下文图。根据前面的识别结果可以开始绘制上下文图。上下文图应该明确展 示系统的边界、外部实体和过程并通过箭头表示它们之间的相互关系。(5)验证上下文图。绘制完成后需要对上下文图进行验证确保它能够准确地表示系统 的边界和交互关系。如果有必要可以修改和完善上下文图。10.4.2 分析问题和机会除了了解当前系统以外项目团队必须同系统所有者和系统用户一起分析问题和机会。真 正的问题分析是一项很难掌握的技能特别是对于没有经验的系统分析员来说更是如此。经验 表明大多数新系统分析员没有真正地分析问题就想解决问题。他们可能会这样陈述一个问题 “我们需要”或者“我们想”。如果这样做的话他们就正在以一种方案的形式陈述问题。更老 练的问题解决者已经学会了在陈述任何可能的问题之前真正地分析这个问题他们分析每个问 题的原因和结果。结果可能是一个不同的、更深的或更基本的问题的症状。对于那个问题也必 须分析原因和结果直到原因和结果不再引发其他问题。因果分析可以得出对问题的真正理解 并且能够得出虽然并不十分明显但更有创造性和更有价值的方案。通常由系统分析员推动该过程但是所有的系统所有者和用户应该主动地参与到因果分析 中因为他们是问题领域专家。系统设计人员和构造人员通常不参与这个过程除非要求他们 分析可能存在于当前系统中的技术问题。常见的一种记录因果分析的文档格式如表10-1所示。第10章 系统规划与分析 355表10-1 问题、机会、目标和约束矩阵项 目 会员服务信息系统 项目经理李四创 建 者 张三 最后修改人张三创建日期2023年1月21日 最后修改日期2023年1月31日因果分析 系统改进目标问题或机会 原因和结果 系统目标 系统约束条件订单响应时间 不可接受 ①吞吐量增加而处理订单的 职员人数减少了。处理一个订 单的时间仍保持相对不变②系统过于依赖键盘。对大多 数订单来说都要输入很多相同 的数据值。当前系统的结果是 每个订单的处理时间比理想情 况下要长③订单的仓库提货单的设计没 有把订单处理的效率最大化。 由于仓库的工作量在增长所 以订单处理延迟是不可避免的 ①处理一个订单的时间减少30%②消除所有订单中50%的键盘 数据录入工作③对于剩余的订单尽可能地 减少键盘输入可以使用计算 机屏幕上的点选对象来代替键 盘输入④将数据编辑工作从一台共享 的计算机转移到桌面计算机⑤用会员服务系统和仓库系统 之间的无纸化通信代替现有的 提货单①不会增加订单处理 人手②开发的系统必须与现 有的Windows 10桌面标准兼容③新系统必须同已经批 准的自动识别系统(条 形码)兼容10.4.3 制定系统改进目标给定我们对当前系统的范围、问题和机会的理解我们现在就可以制定系统改进目标了。 这个任务的目的是建立成功的准则对系统的任何改进都将按照该准则进行度量。制定系统改 进目标也确定了任何可能限制系统改进的灵活性的约束条件成功的准则应该按照目标进行 度量。目标代表了制定对新系统的预期的首次尝试。除了目标以外我们还必须确定已知的约 束条件。约束条件是针对实现目标的限制或界线。最终期限、预算和所需的技术是约束条件的 例子。系统分析员推动这个任务其他参与者包括已经参与了问题分析阶段中其他任务的系统所 有者和系统用户。再次说明我们仍然不关心技术问题所以系统设计人员和构造人员不参与 该任务。对于每个验证过的明显问题分析员和用户应该定义专门的系统改进目标他们也应 该确定可能会限制或阻碍实现这些系统改进目标的约束条件。系统改进目标应该是精确地、可度量地定义新系统预期的业务性能陈述。它可能受到约束 条件的调节约束条件分为以下4类进度、成本、技术、政策。10.4.4 汇报调查结果和建议问题分析阶段需要以一个沟通任务作为总结。我们必须向业务团队汇报调查结果和建议。 项目经理和主要负责人应该一起推动这个任务其他的与会者应该包括整个项目团队这包括 整个系统的所有者、用户、分析员、设计人员和构造人员。同往常一样会议应该对来自业务356 系统分析师教程(第2版)团队的所有感兴趣的人员开放。而且如果为该项目建立了一个内联网站在整个问题分析阶 段中网站应该得到不断地维护确保项目进展的持续沟通。常见的书面报告提纲如表10-2所示。表10-2 常见书面报告提纲1.总结(大约2页)①性能问题、机会和因果分析②总结问题、机会和指示③简单陈述系统改进目标④简单解释报告内容 4.当前系统分析(大约510页)①性能问题、机会和因果分析②信息问题、机会和因果分析③经济问题、机会和因果分析④控制问题、机会和因果分析⑤效率问题、机会和因果分析⑥服务问题、机会和因果分析2.背景信息(大约2页)①面谈和小组会议的人员清单②被探索的其他信息资源清单③描述使用的分析性技术 5.详细建议(大约510页)①系统改进目标和优先权②约束条件③项目计划●范围重新评估和提炼 修改后的主计划●用于定义阶段的详细计划3.当前系统概述(大约5页)①战略意义②当前系统的模型●接口模型(显示项目范围)●数据模型(显示项目范围)●地理模型(显示项目范围)●过程模型(只显示功能性分解)6.附录①详细的系统模型②其他相应文档10.5 业务流程分析组织结构图描述了系统内部各部门的划分以及这些部门之间的相互关系功能分析图则 反映了这些部门所具有的管理功能这些都是有关信息系统工作背景的一个综合性的描述但 它们只反映了系统的总体情况而不能反映系统的细节情况。下一步的任务就是要明确这些职能 是如何在有关部门具体完成的以及在完成这些职能时信息处理工作的一些细节情况这项工 作称为业务流程分析。业务流程分析的目的是了解各个业务流程的过程明确各个部门之间的业务关系和每个业 务处理的意义为业务流程的合理化改造提供建议为系统的数据流程变化提供依据。业务流 程分析可以帮助系统分析师了解业务的具体处理过程发现和处理系统调查工作中的错误和疏 漏修改和删除现有系统的不合理部分在现有系统基础上优化业务处理流程。第10章 系统规划与分析 35710.5.1 业务流程分析概述流程就是做事情的顺序是一个或一系列连续有规律的行动这些行动以确定的方式发生 或执行导致特定结果的实现。一般来说流程由一系列单独的任务组成并使输入变成输出。从本质上讲企业的业务流程就是由一系列具有先后顺序且互相关联的活动所组成的经营过程。 由于企业业务流程的整体目标是为顾客创造价值因此以顾客利益为中心以员工为中心 以及以效率和效益为中心是业务流程的核心。在传统企业中组成企业的基本结构是职能相对单一的部门由这些部门分别完成不同的 任务整个企业是一个金字塔式的层级结构每个人、每个岗位以致每个部门都只对其直接 上级负责主要职责是完成上级交给的任务在任务和任务间经常出现脱节和冲突。因此在 传统企业里各项业务工作大多是独立的或是若干项业务构成一些流程的片段但很少有能 够贯穿企业的、畅通的业务流程自然也就没有专职人员对各条业务流程具体负责。而信息系 统是管理创新它的运行基础是企业的业务流程。据有关资料统计业务流程不通畅是导致企 业信息系统项目失败的主要原因之一。可见对企业现有的业务流程进行分析是信息系统建设 的必要前提条件。1. 业务流程分析的步骤业务流程分析是工作量大烦琐而又细致的工作。它的主要任务是调查系统中各环节的业 务活动掌握业务的内容和作用以及信息的输入、输出、数据存储和信息处理方法及过程等 为建立系统数据模型和逻辑模型打下基础。业务流程分析的具体步骤如下通过调查掌握基本 情况描述现有业务流程确认现有业务流程对业务流程进行分析发现问题并提出解决方 案提出优化后的业务流程。2. 业务流程分析的方法业务流程分析的主要方法有价值链分析法、客户关系分析法、供应链分析法、基于ERP的 分析法和业务流程重组等。(1)价值链分析法。价值链分析法是由美国哈佛商学院教授迈克尔 ·波特提出来的是一 种寻求确定企业竞争优势的工具即运用系统性方法来考察企业各项活动和相互关系从而找 寻具有竞争优势的资源。价值链分析法找出或设计出那些能够使顾客满意实现顾客价值最大 化的业务流程。价值链就是一个创造价值的工作流程在这一总流程基础上可把企业具体的 活动细分为生产指挥流程、计划决策流程、营销流程、信息搜集与控制流程、资金筹措流程等。 其中有些业务流程特别重要对形成企业核心竞争力起着关键作用这样的业务流程称为基本 业务流程对应于价值链中的基本活动其他业务流程是对企业的基本经营活动提供支持和服 务的称为辅助业务流程对应于价值链中的辅助活动。价值链思想认为企业的价值增加过程 按照经济和技术的相对独立性可以分为既相互独立又相互联系的多个价值活动这些价值活 动形成一个独特的价值链。价值活动是企业所从事的物质上和技术上的各项活动不同企业的 价值活动划分与构成不同价值链也不同。(2)客户关系分析法。客户关系分析 ( Customer Relationship Analysis,CRA) 是处理有关客户的数据分析他们与企业的关系以提高企业未来的销售、服务和成本控制的过程。客户 关系分析法就是把客户关系管理( Customer Relationship Management,CRM) 用在业务流程的 分析上。CRM 的目标是建立真正以客户为导向的组织结构以最佳的价值定位瞄准最具吸引 力的客户最大化地提高运营效率建立有效的合作伙伴关系。从CRM 的角度分析业务流程 企业的业务流程应当是以客户与企业的关系以及客户行为为依据的而不是传统的按照企业 内部管理来实施的。(3)供应链分析法。供应链分析法是从企业供应链的角度分析企业的业务流程它源于供 应链管理( Supply Chain Management,SCM)。供应链是指用一个整体的网络用来传送产品和服 务从原材料开始一直到最终客户(消费者),它凭借一个设计好的信息流、物流和资金流来完 成。供应链分析法主要从企业内部供应链和外部供应链两个角度来分析企业的业务流程分析 哪些流程处于供应链的核心环节。(4)基于ERP的分析法。ERP 企业资源计划的基本思想是将企业的业务流程看作一个紧密 连接的供应链将供应商和企业内部的采购、生产、销售以及客户紧密联系起来对供应链 上的所有环节进行有效管理实现对企业的动态控制和各种资源的集成和优化从而提升企业 基础管理水平追求企业资源的合理、高效利用。(5)业务流程重组。通过重新审视企业的价值链从功能成本的比较分析中确定企业在 哪些环节具有比较优势。在此基础上以顾客满意为出发点进行价值链的分解与整合改造原 有的业务流程实现业务流程的最优化。3. 业务流程分析的工具业务流程分析的传统工具是业务流程图 ( Transaction Flow Diagram,TFD)、业务活动图 (Business Activity Mapping, BAM) 和统一建模语言 ( Unified Modeling Language,UML) 的活 动图。虽然目前有些信息系统开发方法中已不再使用TFD, 而是用物理数据流程图直接替代 或采用UML中的活动图但是仍有部分系统分析师看重它们的简单、易懂、消除歧义等特 点在开发中应用这种工具。10.5.2 业务流程图TFD是分析和描述现有系统的传统工具是业务流程调查结果的图形化表示。它反映现有 系统各部门的业务处理过程和它们之间的业务分工与联系以及连接各部门的物流、信息流的 传递和流动关系体现现有系统的边界、环境、输入、输出、处理和数据存储等内容。TFD是 一种用尽可能少、尽可能简单的方法描述业务处理过程的方法。由于它的符号简单明了所 以非常易于阅读和理解业务流程。但是TFD 对一些专业性较强的业务处理细节缺乏足够的表 现手段它比较适用于反映事务处理类型的业务过程。它用一些规定的符号及连线表示某个具体业务的处理过程帮助分析人员找出业务流程 中的不合理流向。TFD 基本上按业务的实际处理步骤和过程绘制是一种用图形方式反映实 际业务处理过程的“流水账”。绘制这本“流水账”对于开发者理顺和优化业务过程是很有帮 助的。1.TFD 的基本符号TFD基本图形符号有6个符号的内部解释可直 接用文字标于图内。这些符号所代表的内容与信息系 统最基本的处理功能一一对应如图10-1所示。圆圈表示业务处理单位矩形框表示对业务处 理的描述报表符号表示输出信息(报表、报告、 文件、图形等),不封口的方框表示存储文件卡 片符号表示收集资料矢量连线表示业务过程联系 (物流或信息流)。第10章 系统规划与分析 359收集资料 存储 业务过程联系 图10-1 TFD 的基本符号2.TFD的绘制业务流程分析是在已经理出的业务功能基础上将其细化利用系统调查的资料将业务处理 过程中的每个步骤用一个完整的图形将其串起来。TFD 根据系统调查中收集到的资料和调查的 结果按业务实际处理过程用基本符号将它们绘制在同一张图上。在绘制TFD的过程中发现问 题分析不足优化业务处理流程。TFD 的绘制并无严格的规则只需简明扼要地如实反映实 际业务流程。图10-2就是一个TFD 的示例。本岗用料计划库长库存台账库工订货单采购员催货通知填写领料单领料单审批领料单已批准领料单查阅库仔 账、等级流 水账、缺货 通知、生成库存报表等 缺料通知单查阅订货通知、催货、申 请补充订货、 办理入库补充订货通知供货 单位未批准领料单用料台账入库单提货通知单有关 部门库存报表图10-2 某企业物资管理TFD360 系统分析师教程(第2版)在绘制TFD时要依据业务调查的语义描述进行分析其关键是找出业务流程中的内部实体 (业务处理单位)和外部实体。它们的主要区别是外部实体是为系统传递信息或接收系统处理后 的信息的实体而内部实体是参与系统的信息处理过程、完成某一处理动作的角色、岗位或部 门。例如在图10-2中“供货单位”和“有关部门”是外部实体而其他的都是内部实体。10.5.3 业务活动图BAM是一个有效的业务流程描述工具其主要功能是提供业务流程情况的全面模型。该模 型不但有图例表述业务活动流动的情况还能提供相关的业务活动细节有助于系统分析师理 解业务流程运作的过程。BAM的具体应用主要有三个一是在业务流程调查时可以用BAM 对业务流程进行识别二是在业务流程分析时可以用BAM 描述新的业务流程三是在业务 流程实施过程中可以用BAM 实现业务流程的不断优化。1.BAM的基本符号BAM已是一种比较成熟的方法其基本符号如图10-3所示。业务活动或行为从业务活动有条件退出 的机会。这是一项决策 表示一种“或”情况业务职能外部BAN连接符号 (连接另一个BAM)业务的起始或终止报告或存档用换页连接符号 (同一个BAM)流动方向指示图10-3 BAM的基本符号图10-4 业务活动图编号符号说明如下(1) 行为符号。BAM由一系列的圆圈组 成每个圆圈代表一项单独的工作步骤都 有一个名称。当已达到业务职能分解层时 圆圈外面加一个方框。(2)决策符号。许多工作行为包含两种 决策两种决策的结果可能分别导致新的行 为。多种决策则产生多个行为圆圈。一般决 策以圆圈边上添加一个菱形来表示。(3) BAM 编号如图10-4所示。2.BAM法的应用BAM的启动一般是从部门的职责开始根据部门职责列出一连串的业务活动。根据业务复第10章 系统规划与分析 361杂程度可将复杂的业务分成若干较低层次的细小活动。通常一项业务可能分成3到4个层 次最复杂的业务甚至可以分成7个层次具体的划分需要根据系统的实际情况决定。业务流程分解的目的是让系统分析师充分理解各项业务活动从最高层次的业务到最低层 次的业务职能层所有与其他职能的相互作用都要列入BAM 中从而确定业务之间的相互关 系。图10-5是一个简单的BAM示例。订单表格存档销售人员送出订单 ··订单核查 确认·所有信息·清晰程度·订货项目号无误·促销号无误·销售人员身份/地域·库存情况·信用状况·付款情况 附注的 订单与销售代表联系图10-5 某企业订单处理BAM示例由于BAM的作用是识别企业的业务流程因此系统分析师必须持有一种科学的、客观 的态度要能容纳做事情的各种方法不要带自己的主观色彩去看问题。BAM中的信息必须是 事实而不能是系统分析师的解释。这就要求系统分析师注意从业务活动参与者本身的角度来 反映和理解业务活动须有高度的灵活性和宽容度。10.5.4 业务流程建模业务流程建模( Business Process Modeling,BPM) 是对业务流程进行表述的方式它是过 程分析与重组的重要基础这种表述方式大大优化了软件开发和运行效率。系统模型在系统开 发中扮演着一个重要的角色按照系统论的观点系统是由相互作用和相互依赖的若干组成部 分结合而成具有特定功能的有机整体。因此一个业务流程是由完成该流程的要素构成的系 统。一般来说任何企业都有不止一个业务流程这些流程之间存在交叉和嵌套等关系。这时 在总体上理解和认识业务流程就不是一件容易的事情了往往需要借助于先进的工具、技术和 方法特别需要借助于信息技术。在这种情况下建立业务流程模型就成为非常关键的一个 环节。1.BPM概述企业业务流程包含三个要素分别是实体、对象和活动。业务流程发生在实体之间它们 可以是企业间的、功能间的也可以是人与人之间的业务流程的功能就是对对象进行操作 这些对象既可以是物理的也可以是逻辑的业务流程涉及管理活动和业务操作活动。BPM可分为三个层次。第一个层次是模型的要素即目标、知识和数据。其中目标是建 模的目的知识包括现有系统的知识和模型构造知识数据是指系统的原始信息这三个方面 构成了BPM的输入。第二个层次是模型的构造它是具体的建模技术的运用过程。第三个层次 是对模型的可信性分析它是指分析所建模型能否满足系统目标。业务流程建模可以采取两种方式自顶向下和自底向上。自顶向下的方式从企业任务目标 出发根据流程上的价值链来确定最基本的流程逐层分析业务目标直至底层。此过程涉及将 业务需求细化为系统需求再将系统需求细化为功能。自底向上的方式是分析现有系统从已 有业务流程活动及其联系出发用于明确业务细节问题。描述业务流程模型最常见的方法是形式化描述和图示化描述。形式化描述方法的特点是精 确、严谨易于系统以后的实现但难以掌握和理解模型可读性差往往只有专业人员才会 使用因此难以推广。图示化方法由于其直观、自然易于描述系统的层次结构、功能组成 且简单易学通常还有工具软件的支持因而成为业务流程的主要描述工具但这种方法的 精确性和严谨性不够。目前常见的方法有标杆瞄准 ( Bench marking)、组织动态本质建模法 ( Dynamic Essential Modeling of Organization,DEMO)、Petri 网、业务流程建模语言和基于服务 的BPM等。2. 标杆瞄准标杆瞄准是一个连续、系统化地对外部领先企业进行评价的过程它通过分析和评价确 定出代表最佳实践的经营过程和工作过程以便合理地确定本企业的业务流程。人们形象地把 标杆瞄准法比喻为一个合理、合法地复制优秀企业成功经验的过程。事实上企业中的许多业 务流程在不同的行业中都是相似的因此运用标杆瞄准法对这些项目实施瞄准尤其是在不 同的行业对同一项目实施标杆瞄准时对企业的参考价值可能更大。实施标杆瞄准的程序如下(1)确定需要进行标杆研究的流程和影响流程成败的关键因素。(2)确定瞄准目标的标杆企业、组织及其流程。(3)通过走访、调研、会谈、专业期刊、广告等采集数据并进行分析。(4)从众多标杆数据中选定最佳改进标准。(5)根据标杆指标评估企业的既有流程并确立改进目标。虽然标杆瞄准法可以通过创造性地采用优秀企业的最佳实践来加快业务流程分析加强企 业间的联系促进相互学习但是由于企业所处的阶段和环境不同环境的动态变化通常造 成不同企业间的假设、条件和影响因素的可比性偏弱。因此全面使用标杆瞄准法进行大规模 业务流程分析的做法有点“东施效颦”,收效甚微。正因为如此大多数企业都把标杆瞄准法作 为BPM 的辅助方法。第10章 系统规划与分析 3633.DEMODEMO定义了信息系统中行为角色之间的通信方式这种通信方式可以看作一种对角色 行为的支配方式而这种支配方式是通过在行为角色之间创建指导其行动的约定来实现的 其理论基础是对话行为理论( Speech Action Theory) 。DEMO的核心是业务事务( Business Transaction), 业务流程由一系列相关业务事务组成业务事务是一种通信模式和客观行为它 通过两个行为角色实现分别是发起者和执行者。一个业务事务包括三个阶段分别是要求阶 段、执行阶段和结果阶段如图10-6所示。要求阶段和结果阶段由在主观世界中的发起者和执 行者之间通信的行为组成执行阶段是执行者执行所提出的要求的客观行为。要求阶段 执行阶段 结果阶段A1: A2: A2: A1:图10-6 事务阶段描述图从DEMO的抽象角度分析DEMO 包括基础层、信息层和文件层的概念业务事务在基础 层上实现其内涵是由信息系统的通信行为角色创造新的、原始的信息。这一特点与信息层和 文件层的作用形成对比信息层的作用是为企业提供来源于基础层的原始信息文件层为企业 提供信息操作的中介。可见信息层和文件层的核心是基础层在构建信息系统时必须对企 业的这三个层次进行设计和分析。DEMO通过6种模型来描述信息系统的构成包括交互模型、业务流程模型、事务模型、 行为模型、事实模型和互约束模型。其中业务流程模型由预先确定的事务类型以及这些事务 之间的因果关系和条件关系组成。因果关系表示在两个事务之间一个事务的执行促使了另一个 事务的开始条件关系表示在两个事务之间一个事务的完成就形成了另一个事务开始或完成的 条件。使用DEMO方法进行业务流程建模的步骤是描述企业事务各个阶段的角色确定事务 阶段之间的因果和条件关系在流程表中描述因果和条件关系检查所有事务阶段的角色。4.Petri 网Petri 网作为一种从流程的角度出发描述和分析复杂系统的模型工具适用于多种系统的图 形化、数学化建模为描述和研究具有并行、异步、分布式和随机性等特征的信息系统提供了 强有力的手段。使用Petri 网描述业务流程主要有以下原因(1) 形式化的语义。Petri网具有严密的数学基础为形式化描述和语法建立奠定了基础。每 个Petri网都有形式化的语义定义一个Petri网模型加上相应的语义就能够描述一个业务流程。(2)直观的图形表示。 Petri 网是一种图形化语言。经典的Petri 网有两种元素分别是变迁 (用方框表示)和位置(用圆圈表示),而有向边表示这两种元素之间的关系。 Petri 网的图形表364 系统分析师教程(第2版)示特点使Petri 网尽管具有严密抽象的数学表示对用户来说却较容易理解结构清晰。(3)丰富的分析技术。Petri 网模型一个很重要的特点在于它提供了丰富的系统分析技术 如对系统活性、有界性、安全性等分析计算。(4)基于状态的表示方式。一般工程领域的图形表示方法往往是基于事件的表示。Petri网 基于状态的描述能清晰地区分一个任务是处于授权状态还是处于执行状态因此Petri 网可以 实现竞争性业务活动。在建模过程中如果使用条件和事件的概念那么位置就代表条件变迁则代表事件。一 个事件有一定数量的输入和输出位置分别代表事件的先决条件和事后条件。位置中的符号代 表可以使用的资源或数据。例如图10-7用Petri 网描述了两个活动使用一个公共资源时利 用通信原语控制资源的使用保证活动间同步的例子。活动1 活动2图10-7 活动同步机制的Petri 网描述图10-7中每个活动有三种状态分别是等待资源( P1 或P4) 、占用资源执行的处理 (P2 或P5) 和不占用资源执行的处理 ( P3 或P6) 。另外系统有一个资源空闲 ( P7) 状态。以活动 1为例如果公共资源R 被活动2所用时就进入等待资源状态 ( P1), 如果资源可用则进入 占用资源执行的处理状态( P2); 资源利用完毕后释放资源使资源返回空闲状态( P7), 而 活动本身进入不占用资源执行的处理状态( P3) 。在有的状态中有一个黑点“●”,称为标记或 令牌表明系统或活动当前正处于此状态。在图10-7中“●”标记在P2 和P4 状态中说明 活动1正处于P2 状态而活动2正处于P4 状态。应用Petri 网可以有效地对企业业务流程进行建模和系统仿真实现业务流程的执行和控制 管理。由于现有的大部分业务流程建模的工具和分析方法都没有考虑到企业实际流程的复杂性 没有考虑到相同的流程对象在不同系统、不同企业中的可迁移性因此在使用中经常会遇到 障碍和问题。而Petri 网由于引入了分层、抽象和继承的思想能够实现业务流程的全部或部分 自动化在此过程中文档、信息或任务按照一定的过程规则流转实现企业各成员间的协调 工作以达到业务的整体目标。5. 业务流程建模语言主流的业务流程建模语言标准有业务流程执行语言 ( Business Process Execution Language, BPEL) 、 业务流程建模语言 ( Business Process Modeling Language,BPML)、业务流程建模标第10章 系统规划与分析 365注 ( Business Process Modeling Notation,BPMN) 、XML流程定义语言( XML Process Definition Language, XPDL) 和 UML5 种。从语言的表现形式上来说可以将它们划归为两大类即文 本类和图元类如图10-8所示。BPELBPMLXPDL文本业务流程建模语言图10-8 业务流程建模语言的划分文本类的流程建模语言将业务流程模型以纯文本的方式描述在一个或多个文档中其中没 有存储任何图形化显示的信息图元类的流程建模语言则将业务流程模型分解成若干个图元元 素来存储通常每个图元元素都有正式的外观和含义。(1) BPEL。BPEL 也称为Web服务业务流程执行语言 ( Business Process Execution Language For Web Service,BPEL4WS) 或 Web服务业务流程执行语言 ( Web Service Business Process Execution Language, WSBPEL), 它是一种使用XML 编写用于自动化业务流程的形式规约语 言。用XML 文档写入BPEL中的流程能在Web服务之间以标准化的交互方式得到精心组织 这些流程能够在任何一个符合BPEL 规范的平台或产品上执行。通过允许用户在各种创作工具 和执行平台之间移动这些流程BPEL 可以保护用户在流程自动化上的投资。(2) BPML 。BPML 与BPEL的设计理念非常相似也用XML 这种结构化的方式对流程和 流程执行的语义进行描述在语法上也有循环和分支等控制结构同时也是一种可执行的建模 语言。BPML 是业务流程建模的元语言就像XML 是业务数据建模的元语言一样。现在曾 提出BPML 语言的业务流程管理创新计划( Business Process Management Initiative,BPMI) 已 经放弃对其支持转而推广 BPEL。这个转变是在BPMI被对象管理组织(Object Management Group,OMG) 收购后为了参与到BPMN 领域而做出的因为BPMN丰富了UML的流程符 号这一点对OMG 非常有用。(3) XPDL。XPDL 是工作流管理联盟(Workflow Management Coalition,WfMC) 定义的 一套流程建模标准用来在支持BPM的各种工具和引擎间交换流程设计的定义。由于XPDL 对流程的描述既是基于XML文档能够直接在流程引擎上执行又记录了模型中的图元信息 所以很适合作为一种模型设计图的中间交换格式而独立存在。开发者的实现和它的外部接口可 以独立分开因为不管是如何实现的采用什么图形描述只要外部接口符合XPDL 规范就 可以保持相同的表示形式。(4) BPMN 。同为BPMI 的标准之一BPMN 是BPML 的有力补充。作为一个图形化的流 程建模语言它能够弥补BPML 等文本类建模语言在图形表示上的先天不足。BPMN 中的图元366 系统分析师教程(第2版)在表达力上等价于文本类语言中的XML 片段但这些图元本身是不能被流程引擎执行的因 此 BPMN的用途更多地在于其图形化的直观表示。BPMN 也支持提供一个内部的模型可以生 成可执行的BPEL。因此BPMN的出现弥补了从业务流程设计到流程开发的间隙。(5) UML。UML 常被看作是系统建模和设计活动中的“瑞士军刀”,它所囊括的10多种 图形化表示方案可以用来捕获系统动态或静态的各个方面。但就BPM 领域而言UML的作 用不是很明显。在UML 中主要使用活动图来对业务流程进行建模。活动图用来表示系统中 各种活动的次序依据对象状态的变化来捕获动作(将要执行的工作或活动)与动作的结果。 活动图中一个活动结束后将立即进入下一个活动。图10-9是一个简单的UML 活动图示例。图10-9 UML 的活动图示例常见的UML 2.0模型图如表10-3所示。表10-3 UML 2.0模型图名 称 作 用用例图 描述系统与外部系统和用户的交互。用例描述也用于以文本化的方式描述每个交互步 骤的顺序活动图 描述一个业务过程或者一个用例的活动流程类图 描述系统的对象结构显示构成系统的对象类以及那些对象类之间的关系对象图 描述对象与对象之间的关系是类图的实例化第10章 系统规划与分析 367(续表)名 称 作 用状态机图 用于建模在生命周期中事件如何改变对象的状态——对象可以经历的各种状态以及 引起对象从一个状态向另一个状态转换的事件组合结构图 分解类、组件或用例的内部结构顺序图 以图形化的方式描述了在一个用例或操作的执行过程中对象如何通过消息互相交互 说明了消息如何在对象之间被发送和接收以及发送的顺序通信图 描述对象之间的交互关系交互图 组合了顺序图和活动图的特征显示在每个用例的活动中对象如何交互定时图 另一种交互图它关注一个对象或一组对象在改变状态时的时间约束条件组件图 表示系统中组件与组件之间以及定义的类/接口与组件之间的结构关系部署图 显示系统中软件和硬件的物理架构包图 表示模型元素的组合虽然UML的活动图可以用来对业务流程进行建模但UML 面向对象的特性决定了其在以 流程为导向的建模领域的尴尬地位。活动图缺乏对流程模型所需的一些构造的支持而且它与 BPEL等可执行建模语言的转换比较困难。6.基于服务的BPM基于服务的流程建模是把BPM 技术和服务的思想结合在一起充分发挥服务的松散耦合和 可复用的特征更加便于业务流程的分析、设计与优化。在基于服务的BPM 中 系统分析师必 须对每一个业务流程进行认真的定义和说明明确哪些业务流程可以转化为服务认真设计及 定义服务并需要区别服务和构件。服务应该是独立的、自包含的请求在实现这些服务时不 需要前一个请求的状态也就是说服务不应该依赖于其他服务的上下文和状态。