本节书摘来自异步社区《sap入门经典(第5版)》一书中的第2章,第2.3节,作者: 【德】迈克尔 米斯巴赫(michael missbach) 更多章节内容可以访问云栖社区“异步社区”公众号查看。
由于参与实施、使用和支持sap的利益相关人类型各异,单一视角永远不可能获得每一个人的共鸣。几乎不可能有人能拥有如此广泛丰富的经验,能够掌控整个sap实施以及其他复杂业务解决方案的复杂度。因此,长期以来的经验证明,从其他视角审视如何开发、管理和改进业务解决方案绝对是大有裨益的。从这种观点看,功能、技术和项目实施角度都是行之有效的视角。对于it利益相关人来说,从业务、功能要求和项目的角度审视业务解决方案有助于弥补他们的知识空白。正如下面将要讨论的那样,通过这种方式,分别从功能角度和更深化的技术角度观察问题之后,再换成端到端的项目实施角度,这就几乎使所有利益相关人都能一窥业务解决方案的全貌了。
2.3.1 功能视角
功能视角是熟悉业务运行方式的人最容易掌握的视角,而对于功能专家之外的人来说又是最难掌握的。这种视角解决的是解决方案的周边环境问题——不是方式、时机或者工具的问题,而是单纯的内容问题。它要回答的问题是“一个业务流程具体要做什么?”
也就是说,功能视角用于处理以下问题。
以分步的方式描述或沟通工作的流程(业务流程的工作步骤)。功能视角提出这样的问题:对于执行业务流程、实现特定的最终状态来说哪些工作步骤是必不可少的?
描述业务流程展示出的属性和特质。因此,功能视角力求发现每个业务流程反映出的特性和属性,以及反映出它们的程度。
在不考虑技术问题和sap问题的情况下独立处理这些工作流程和特性问题,恰当的功能透视甚至不会提及sap,因为它与应用程序提供商提供的特定解决方案根本不相关。
不难想到,持有这种视角的重要利益相关人是最终用户,他们的日常工作就是执行业务流程。业务流程设计师、同类业务的主管以及其他与解决方案所体现的功能有牵连的人也都是重要的利益相关人。
2.3.2 技术视角
技术视角处理的是解决方案各个部分的平衡问题。它帮助功能视角主体从技术角度了解业务解决方案是如何通过技术实现的。重要的考虑因素包括以下几方面。
关注系统的关键维度,识别并确定系统提供性能、可用性、可伸缩性、安全性、敏捷性、可管理性等业务所需特性的方式。
描述解决方案中业务应用方面的所有组件和其他sap组件、数据与相关的依赖关系、接口要求、底层技术架构,以及所有实现前述功能视角目标所必需的底层关系和集成要点。
尽可能地提供一个与技术不相关的视角,观察技术如何帮助实现功能透视。
技术视角利益相关人主要包括企业和技术构架设计师、解决方案开发人员和程序员、基础设施和其他方面的技术专家,以及其他侧重技术的供应商、销售商和合作伙伴。业务工程师也会发现这种视角非常有用。
2.3.3 项目实施视角
项目实施视角很容易理解,它回答的问题是解决方案用什么来建构、需要多长时间,以及利用哪些资源。这种实施视角需要考虑以下方面的问题。
描述和详细制定部署方案,因此需要收集机构和第三方资源、时间期限、约束限制(业务、功能和技术等)等。
描述用以实现公司战略目标和战术功能需求的sap产品和组件,以及这些需求得到充分开发和满足的程度。
一般来说,实施视角利益相关人包括项目经理和协调员、技术专家、开发人员/程序员、测试人员、业务流程负责人、高管人员、业务主管、超级用户等。
设计阶段我们经常遇到的一大诱惑就是倾向于以特定学科领域或专业知识领域来限定具体的视角。显而易见,业务和功能视角可能集中于业务关注点,而技术视角可能会被看作是“it”工作,实施视角一般被看作“项目管理”工作。但这些狭隘的偏见应该予以避免,并且应该牢记sap的成功实施取决于公司及其合作伙伴的通力合作。应该打破偏见壁垒、构建跨领域的团队,并且让所有团队都能在整个实施过程中发表独特的见解。
2.3.4 4种视角相互结合
本章中描述的这4种视角结合在一起形成了业务解决方案的目的(什么原因)、功能(什么内容)、技术基础(什么方式)以及实施细节(用什么实现)。把一个解决方案分解成这些视角使公司能够打破业务和技术界限而进行良好的沟通。
但是您可能会注意到,本章并没有对具体的sap产品和组件进行介绍。这是因为在确定具体的erp解决方案之前,应该先开发出稳定的业务线路图。根据特定的软件提供商(包括sap)提供的解决方案来规划线路图是本末倒置,没有任何意义。首先查明业务需求,然后才能确定sap和其他提供商如何在应用解决方案空间内最大限度地处理好这些需求。在后面的章节中,我们将讨论从概念性的线路图过渡到公司实施方案、技术平台和功能业务解决方案所不可缺少的sap具体细节。