跨组织ERP实施的需求工程:无证的假设和潜在的不匹配外文翻译资料
2022-03-22 21:18:06
Requirements Engineering for Cross-organizational ERP Implementation:
Undocumented Assumptions and Potential Mismatches
Maya Daneva, Roel Wieringa
Department of Computer Science, University of Twente, The Netherlands
m.daneva@utwente.nl, roelw@cs.utwente.nl
Abstract
A key issue in Requirements Engineering (RE) for Enterprise Resource Planning (ERP) in a cross-organizational context is how to find a match between the ERP application modules and requirements for business coordination. This paper proposes a conceptual framework for analyzing coordination requirements in inter-organizational ERP projects from a coordination theory perspective. It considers the undocumented assumptions for coordination that may have significant implications for ERP adopting organizations. In addition, we build a library of existing coordination mechanisms supported by modern ERP systems, and use it to make a proposal for how to improve the match between ERP implementations and supported business coordination processes. We discuss the implications of our framework for practicing requirements engineers. Our framework and library are based on a literature survey and the experience with ERP implementation of one of us (Daneva). In future empirical research we will further validate and refine our framework.
1. Introduction
From their origin in material requirements planning, ERP systems have evolved into software packages that support coordination of different actors in a company. Current ERP systems contain modules not only for material management, but also for accounting, human resource management and all other functions that support business operations. In the past years, the role of ERP systems as coordination support has been extended to
cross-organizational coordination. By lsquo;cross-organizationalrsquo; we mean that the ERP system is used by different independent, or nearly independent, businesses. For example, businesses cooperate with their customers, suppliers, and other stakeholders to form value webs. Large companies have structured themselves as sets of
nearly independent business units, each responsible for their own profit and loss. ERP implementation is considerably more difficult in such a networked context than in an intra-organizational context because in a networked context, we have different business actors who make decisions based on their own local criteria. Different businesses have different infrastructures, different enterprise systems, different business processes, different semantics of data, different authorization hierarchies, and different decision centers. If these businesses decide to cooperate for a particular purpose, all these differences still exist and none of the participating businesses will be prepared to change their infrastructure, business processes, and semantics, just for this particular cooperation, or to reveal the confidential business rules embedded in their processes and applications.
ERP implementation is the customization and introduction of an ERP system in a (possibly networked) business. One of the most crucial tasks in such a project is requirements engineering, in which the properties of the ERP system to be implemented are aligned to the requirements of the busines(es) that will use it.
ERP vendors and their consulting partners offer standard RE processes for ERP projects. Recent research in ERP RE has identified flaws with these standard processes and proposed creative solutions to reduce the cost of ERP RE by avoiding scope creep, involving the right stakeholders, allocating sufficient resources, and enlisting vendorscopy;and consultantscopy;support to RE problems [3, 4, 8, 9, 10, 11, 16, 28, 34]. Nevertheless, the central problem of ERP implementation still exists: to find a match between the flexibility often required by the business, and the rigidity usually imposed by the ERP system. This problem is aggravated in a cross-organizational context because, as we will see, the rigidity of the ERP system is imposed by built-in assumptions about business semantics, business processes, business communication channels and business goals. If these hidden assumptions do not match the business, the business will experience the ERP system as being rigid and
1
unable to meet the business requirements. In a networked context, there is a mismatch between the ERP and each of the participating businesses.
The present paper proposes to tackle this problem from the point of view of coordination theory [2,6,29,32,33]. Since ERP systems are coordination support systems, we should be able to identify the coordination mechanisms supported by an ERP system. If we explicitly specify these mechanisms in a cross-organizational setting, then the requirements engineer should be able to find a match between the coordination support offered by the ERP system and the coordination mechanisms selected by the cooperating companies.
We will present an inventory of coordination mechanisms implicitly assumed by ERP systems, and analyze the role that selection of these mechanisms plays in balancing rigidity imposed by an ERP system against the flexibility required by the cooperating organizations. We will see that rigidity will allow the benefits of cross-organizational cooperation to be reaped, whereas flexibility will decrease the benefits and, at the same time, increase the cost of implementing and maintaining the ERP system.
The paper is organized as follows: Section 2 provides background and related work. Section 3 presents our inventory of cross-organizational coordination mechanisms supported by ERP packages. Section 4 analyzes the mismatch between business flexibility and ERP rigidity and explains the impact of the coordination mechanisms on t
全文共28079字,剩余内容已隐藏,支付完成后下载完整资料
跨组织ERP实施的需求工程:无证的假设和潜在的不匹配
Maya Daneva, Roel Wieringa
Department of Computer Science, University of Twente, The Netherlands
m.daneva@utwente.nl, roelw@cs.utwente.nl
摘要
在跨组织环境中,需求工程(RE)中企业资源规划(ERP)的关键问题是如何找到ERP应用程序模块和业务协调需求之间的匹配。本文提出了一个从协调理论角度分析组织间ERP项目协调需求的概念框架。它考虑了可能对采用ERP的组织有重大影响的无证协调假设。另外,我们还建立了由现代ERP系统支持的现有协调机制库,并用它来提出如何改进ERP实施与支持的业务协调流程之间的匹配。我们讨论我们的框架对实践需求工程师的影响。我们的框架和库基于文献调查和我们其中一个人(Daneva)ERP实施的经验。在未来的实证研究中,我们将进一步验证和完善我们的框架。
1.简介
从物料需求规划的起源,ERP系统已经发展成为支持公司中不同参与者的协调的软件包。目前的ERP系统不仅包含材料管理模块,还包含会计,人力资源管理和支持业务运营的所有其他功能模块。在过去的几年中,ERP系统作为协调支持的作用已经扩展到跨组织协调。 “跨组织”是指不同的独立或几乎独立的企业使用ERP系统。例如,企业与他们的客户,供应商和其他利益相关者合作形成价值网。大公司已经将自己组建为几乎独立的业务部门,各自负责自己的盈利和亏损。在这样的网络环境中,ERP实施比在组织内环境下要困难得多,因为在网络环境中,我们有不同的业务参与者根据他们自己的当地标准做出决策。不同的企业有不同的基础设施,不同的企业系统,不同的业务流程,不同的数据语义,不同的授权层次以及不同的决策中心。如果这些企业决定为特定目的进行合作,所有这些差异依然存在,参与企业都不会准备改变其基础架构,业务流程和语义,只是为了进行这种特定的合作,或者揭示嵌入的机密业务规则在他们的过程和应用中。
ERP实施是在一个(可能是联网的)企业中定制和引入ERP系统。这样一个项目中最重要的任务之一就是需求工程,其中将要实施的ERP系统的特性与将使用它的业务的需求相一致。
ERP供应商及其咨询合作伙伴为ERP项目提供标准的可重入流程。最近在ERP RE的研究中发现了这些标准流程的缺陷,并提出了创造性的解决方案,通过避免范围蔓延,涉及合适的利益相关者,分配足够的资源,并争取供应商copy;和顾问copy;对RE问题的支持,来降低ERP RE的成本[3 ,4,8,9,10,11,16,28,34]。尽管如此,企业资源规划实施的核心问题仍然存在:找到企业常常需要的灵活性与ERP系统强加的刚性之间的匹配。在跨组织的背景下,这个问题更加严重,因为我们将会看到,ERP系统的僵化是由关于业务语义,业务流程,业务沟通渠道和业务目标的内置假设强加的。如果这些隐藏的假设与业务不匹配,企业将体验到ERP系统僵化,无法满足业务需求。在网络环境中,ERP与每个参与企业之间存在不匹配。
本文提出从协调理论的角度来解决这个问题[2,6,29,32,33]。由于ERP系统是协调支持系统,我们应该能够确定ERP系统支持的协调机制。如果我们在跨组织的背景下明确指定这些机制,那么需求工程师应该能够找到ERP系统提供的协调支持和合作公司选择的协调机制之间的匹配。
我们将介绍ERP系统默认承担的协调机制清单,并分析这些机制的选择在平衡ERP系统所强加的刚性与合作组织所需的灵活性之间所起的作用。我们将看到,僵化会使跨组织合作的好处得到收获,而灵活性会降低收益,同时增加实施和维护ERP系统的成本。
本文组织如下:第2节提供背景和相关工作。 第3部分介绍了我们的ERP软件包支持的跨组织协调机制的清单。 第4部分分析了业务灵活性和ERP刚性之间的不匹配,并解释了协调机制对这个问题包的影响。 第5部分讨论了我们的ERP RE框架的影响,并提出了一些我们认为值得进一步研究的假设。 第6节总结了未来研究的计划。
2.背景和相关工作
本文依赖于我们之前在ERP RE [9,10,11]中的工作以及[3,4,8,28,34]发表的经验。我们的研究也建立在Davenport [12,13,14],Hong和Kim [22],Gattiket和Goodhue [18],Markus [5,31],Scott&Kaindl [37]和Soh等人[ 39,40]分析ERP项目中的一致性视角。尽管ERP文献突出了ERP项目中的不对称问题,但仅仅声称它们源自未满足的组织要求掩盖了各种不对称来源。调查ERP不匹配性质的先前研究很少。一个例外是Soh等人[40]提出的错位类型,他们采用辩证的视角,并通过考虑四对相反的力量来扩展他们的初始失配分类[39]:(1)推动整合与分化,(2)过程取向与功能定位,(3)灵活性与限制性,以及(4)打包领域细节与组织领域细节。然而,他们的类型学来自公共部门一个组织跨部门整合项目的案例。我们在跨组织ERP实施领域探索这些对立的力量。
我们发现最有助于审查失调问题及其来源的理论视角来自协调领域[29]。我们的出发点是观察现代ERP系统被广泛用作规划,执行和监控大量功能分割操作的管理框架,其方式是(i)实时地适应内在的跨组织相互依赖性这些行动的基础,和(ii)使他们的控制。因此,从协调理论的角度来看,这些系统可以被看作协调技术。
我们遵循Malone和Crowston [29]将协调定义为不同商业行为者共同行动的管理。经济社会学中经典的协调机制包括基于市场的协调,其中商品和服务是基于价格的交换和关系协调,其中参与者根据共同和隐含的行为规范为共同目标而工作[2,32,33 ]。支持协调的IT机制包括共享ERP系统和企业应用集成中间件[30]等。
本文调查的问题是哪些ERP机制可用于支持不同的协调机制。跨组织RE的相关性在于对一组组织的理想协调机制的分析将导致对ERP包实施的要求。关于协调机制的偏好通常隐藏在ERP软件包中,因此当选定的ERP软件包不符合所有隐含的但未公开的协调机制时,会导致不愉快的意外。
据我们所知,迄今为止还没有系统地分析协调需求在ERP项目中的作用。到目前为止,还没有统一的框架来描述各种协调机制,也没有一套系统的处理组织协调需求的规则。需求工程师和企业代表仍然必须依赖直觉和经验,而协调问题仍然以很大程度上临时性的方式面临。此外,包括ERP系统评估中协调方面的少数ERP出版物[17,41]仅以一般术语描述了这些方面,而没有详细描述(i)如何达成共同行动协议和(ii) )ERP中的默认协调机制如何满足这些需求。这种模糊性使得很难确定什么替代协调机制在特定组织环境下可能有用,或者直接将这些替代协调过程设计转化为单个活动的规范或使用ERP来支持流程(例如,作为业务流程的一部分重新设计努力[13,14,20])。
3.协调机制清单
我们根据图1所示的方案对协调机制进行分类。
图1.业务-IT对齐框架
水平层将服务供应层次结构中的实体分类:物理实体向软件基础结构提供服务,软件基础结构向企业系统提供服务,向企业提供服务。我们对企业有四种观点:企业有目标,他们执行流程,彼此沟通,并且在这样做的同时,他们用数据交换语义。该框架取自我们之前关于业务IT架构调整的研究。为了激励我们,请读者参考那些论文[15,43]。
我们的兴趣在于框架的上面两层,因为这是联网组织中流程和系统对齐的地方。对ERP实施[5,7,12,13,14,23,25,31,36,38,41]和我们自己在实施基于SAP软件包[9,10,11]的ERP解决方案方面的经验的文献的回顾表明,在企业系统级使用的少数协调技术:
bull;共享数据库,
bull;数据仓库,
bull;ERP功能应用程序模块
bull;工作流管理系统。
还有其他基础设施级别的技术,如企业应用程序集成中间件,用于信息共享的移动技术,还有实验性的Web服务技术。我们推测,业务层面的协调流程与基础设施层面的集成技术之间几乎没有关系,我们不会在这里进行探讨。另一方面,企业系统层面的集成技术对业务层面的协调过程有内置假设,这是本文的主题。顺便提一下,在企业系统层面,ERP只是诸如共享数据库,数据仓库,ERP模块和工作流管理系统等不同可能的集成技术之一[30]。虽然这些技术可以由一家ERP供应商一起提供,但联网业务可能决定使用任何多供应商组合,我们将它们视为不同的技术。但是,我们假设至少我们的一些发现可以推广到企业系统级别的其他集成技术。
我们的评估在业务层面产生了以下协调机制:
bull;以目标为导向的机制是指伙伴关于协调目标的协议。
bull;面向流程的机制涉及建立端到端的组织间流程,例如客户订单履行流程或产品供应流程。
bull;面向语义的机制是指关于关键信息实体的定义和使用通用含义的合作伙伴协议。
bull;面向通信的机制,包括网络组织中信息的传输和解释。
表1描述了我们的研究涵盖哪些协调机制以及如何在最先进的ERP系统中支持这些协调机制。该表构成ERP支持网络环境中的协调并提供示例。它是为了说明不同的协调机制,并不是详尽无遗的。事实上,它不能全面,因为跨组织协调的新方法正在持续实施。
对这些机制的关键观察是,每一个都以copy;copy;shared。开头。现在,在一家公司内部,通常情况下,这些机制是共享的,而不需要每个人都明确地谈论它们。毕竟,在一家公司内,我们可以假定有一种文化和一种共同的做事方式。但是在不同的公司中,一个企业的成员默默地认为是正常的工作方式可能与另一个公司的人默默地假设正常的工作方式有很大不同。即使在一家公司内,也可能存在严重的错配,例如,如果公司由不同的几乎独立的业务部门组成。因此,表1列出了必须在跨组织ERP实施中公开的隐含假设列表。关于共享协调机制的假设在不同的业务合作伙伴之间可能有很大不同。
机制类型 |
隐含的假定协调机制 |
对ERP使用者意味着什么? |
实例 |
目标导向机制 |
网络化组织的共同愿景 |
向客户呈现一张脸并分享企业形象 |
通过使用通用订单统一品牌管理 |
将网络提供给客户的服务共享视图 |
激励不同企业的服务之间的依赖关系 |
更新供应链伙伴的数据库取决于单个事件,例如当库存消耗到临界量时。 |
|
面向处理机制 |
关于业务流程环境的共同协议 |
标准化的操作程序,访问权限和控制模式 |
常见的付款处理程序 |
关于处理器的协议 [12,13,14] |
将组织操作减少到与序列,子功能类别,模块和交叉模块化操作相关的大量程序步骤 |
创建供应商主文件或账户图表 |
|
关于mngnt政策的共同协议[13] |
分享明确且一致的可执行业务规则 |
跟踪员工出勤和缺勤的规则 |
|
解决方案地图[23] |
对行业部门最重要的业务流程的描述,支持流程所需的技术(ERP元素,附加组件)和服务 |
分支机构特定的解决方案图,如mySAP 航空航天与国防解决方案图[23] |
|
共享事务处理引擎[12] |
对跨组织架构中ERP的位置有共同的理解 |
由Oracle Exchange [12]和SAP [23]提供的贸易伙伴门户,拍卖和交换机制,目录, |
|
面向语义的机制 |
共享数据字典[7,9,13,25] |
信息实体的通用定义 |
维护公司客户和业务伙伴数据的集中视图 |
共享报告格式和语义[13] |
输出的标准表示格式和信息内容 |
整合全球现场能力,生产和运输成本,关税和需求数据,以便在多个地点进行安排[13] |
|
关于数据访问权限的授权[38] |
分布式访问数据和分布式应用程序逻辑 |
通过开放的信息共享文化,利用自助服务平衡 |
|
crossorg的共同原则。数据管理[14,23] |
数据一致性[24]并与企业保持一致 |
数据所有权,数据模块化,信任:不需要其他来源来验证数据的准确性[24] |
|
参考模型[7,23,25,38] |
以可重复使用的过程和数据模型的形式表示嵌入到包中的实践 |
R / 3参考模型[7,36] |
|
共享产品模型[25] |
ERP软件包的行 全文共7749字,剩余内容已隐藏,支付完成后下载完整资料 资料编号:[15796],资料为PDF文档或Word文档,PDF文档可免费转换为Word |