Search results

The purpose of this paper is to provide a common understanding of service‐oriented concepts to enable unambiguous discussion around service‐oriented architecture (SOA). Managers often have limited understanding of SOA, and for some reason, technologists seem to have difficulty explaining the concept using terminology and analogies that managers can understand. This paper addresses the long‐standing communications gap between managers and technologists as they attempt to evaluate how SOA or SOA‐related investments can add business value.

The approach for this paper is to state the problem between managers and technologists and then provide concepts to break down the communication barrier. The paper then goes on to provide an argument for an optimal approach for SOA implementation and investment that meets management requirements.

Unless SOA can be aligned to business processes, it will be viewed as a risky proposition that adds to cost without directly addressing business needs.

Managers need to understand the differing SOA points‐of‐view and what they mean for business performance. If one has difficulty in implementing ERP, then one will have more difficulty in implementing SOA. It is the responsibility of management to understand how these SOA‐related concepts impact the business, if for no other reason than that they are costly and risky. Of course, the concepts vary in cost and complexity, but they all vary in benefit potential to the business.

The originality of this paper can be noted by the fact that confusion around SOA approaches between managers and technologists still exists. This paper seeks to eliminate that widespread confusion by presenting service‐oriented concepts in an unbiased, holistic view.

This paper seeks to describe the evolution of SAP implementation methodologies and tools, in particular, Value SAP, with a focus on the Accelerated SAP (ASAP) implementation methodology and its evolution as a part of SAP's new Solution Manager tool.

The general approach is more focused on monitoring and managing an ongoing SAP implementation project using an enterprise solution architecture. Three options are explored.

Finds that one option supports end‐to‐end business process management – other options can be managed, but with cost and risk.

This paper has reviewed the latest developments in SAP implementation methodologies from a management orientation. The issues in this paper are often taken for granted by researchers, so it is hoped that the focus on these issues will elevate interests in pursuing some of the unanswered questions.

Enterprise integration endeavors are complex because they compel an organization to understand how its cross‐organizational business processes are enabled by multiple systems. For any large‐scale implementation project, specific business process and system information is included in the enterprise‐solution architecture. To understand the totality of any organization's business processes, managers must define and document all core and support processes.

The examples used in this paper are from large public sector organizations, but the underlying methodology and conceptual basis for the paper apply to any complex organization.

The main conclusion of this paper is that end‐to‐end (E2E) business process scenarios must be used for defining the requirements for any system implementation project in any organization. If the new system does not align with the E2E‐business processes, then management requirements cannot be realized. We also note that E2E scenarios must be considered when implementing enterprise software in a non‐enterprise environment.

The paper notes that E2E scenarios represent the requirements definition level for composite applications enabled in a service‐oriented architecture (SOA). Traditional implementation methodologies that enable standard software modules (or integration scenarios across modules) are not effective in non‐enterprise environments.

This paper aims to provide a clarification of the meaning of the term integration.

A taxonomy of integration definitions derived from the academic and trade literature is developed, analyzed, and documented.

Integration is a word that is commonly used when discussing enterprise applications. The term integration is inserted in technical papers, e‐mail messages, correspondence, proposals, and even causal conversations. After many years of project work, and many misunderstandings and failed meetings and workshops, it can only be stated that the word has multiple and misunderstood meanings. For technical papers (research and trade), the term must be provided with context, or it is impossible to have a meaningful conversation. Next, multiple alternative definitions (that are valid in the literature for the appropriate context) are presented and explained in some detail.

The paper is not exhaustive, since new definitions of integration may exist or may emerge.

The main contribution of the paper is that it yields clarity on a key term that is frequently used in information systems research. The paper is useful to any researchers or practitioners who are focused on enterprise system implementation.

The management of the US Department of Defense (DoD) enterprise must change. Years of under‐funding have led to a wide gap between enterprise support requirements and resources. Private sector firms have faced similar choices. This paper shows how the public enterprise can be changed. Our hypothesis is that private sector implementations of standard software will lead to increased effectiveness and efficiency in public sector organizations. Sufficient detail is provided on how to transition to a modern integrated public sector enterprise, and the steps for implementing such a project are outlined, following standard private sector implementation practices. To explain the problem and solution, the DoD installation management enterprise is used as an example.

The US Department of Defense (DoD) is engaged in a multi‐year transformation of logistics planning and execution, known as the Future Logistics Enterprise (FLE). It is currently being defined in policy documents and an implementation plan known as the Future Logistics Architecture (FLA). The systems strategy for the FLE is still emerging, but it is anticipated that commercial standard software will play a significant role in the enablement of the new logistics business processes. A number of products are available for implementation, but this paper focuses on mySAP.com from SAP AG. We show the strategy for aligning the SAP reference hierarchy and the associated reference business process models with the FLA. The result of the mapping and associated analysis is an SAP reference model for the FLE, which can be used as a guide for the software vendor for future product development strategies. This paper reports on the development of the FLA, its alignment with mySAP.com and the development of the SAP reference model.

Business process management has received much attention in the industrial engineering and management literature, and its benefits are well known. Much less has been written in the public sector management literature, and what has been written has been very general. Hence, there is confusion among public managers about how business process management concepts should be implemented. How should public organizations reorganize to accommodate business process management? How are existing or new enterprise systems aligned with business process management methodologies? This paper addresses these issues, and concludes that public organizations will have to change their organizational structures radically as well as their enterprise systems in order to implement business process management concepts successfully. The paper also discusses the benefits of public sector process management, and focuses in some detail on two of the reasons that public organizations have incentive to implement business process management methodologies.

Further data are presented on the efficacy of our SAP process‐oriented research methodology, which focuses on analyzing collaboration across multiple overlapping SAP solutions. Looks at three SAP projects currently being implemented in the US Navy. The projects focus on aviation weapon system program management, aviation supply and maintenance, and naval maritime maintenance. Collaboration was complex and difficult to achieve, given the scope of the project but desirable if it was cost‐effective. The research hypothesis was that development and execution of a methodology for analyzing the gaps and overlaps across multiple SAP software instances to assess collaboration or convergence potential were possible. It was concluded that collaboration was not cost‐effective, and that the three projects should be merged into two SAP solutions (both solutions were version 4.6c of the R/3 software). Results did not provide a general approach for merging SAP projects, but an analytical approach that could be used to analyze convergence possibilities for stand‐alone SAP solutions is provided. It is not believed that a general approach is achievable. There are millions of configuration possibilities and many unique project characteristics. Hence the analytical approach is somewhat general but general convergence principles are beyond the scope of this research.

This paper aims to automate the supply chain operations reference (SCOR) model as an enabler for process‐oriented supply chain business intelligence.

The hypothesis is the following: SCOR model automation is possible using data that is directly extracted from integrated enterprise systems. To test the hypothesis, an alignment product that allows the SCOR model to be automated with information that is directly extracted from the Oracle E‐Business Suite was developed.

In order to achieve the full benefits from the SCOR model, effective business process management and the SCOR key performance indicators (KPIs) must be implemented and used. Unless data collection to support KPI construction is automated, it is difficult to institutionalize the SCOR model as a measurement and benchmarking framework. We have demonstrated that automated support for KPIs is feasible and achievable.

The E‐Business Suite is a single enterprise solution, but we assert that the same procedures could be followed with other enterprise solutions or even applied in a legacy system environment.

The developed solution described in the paper can immediately be applied to the design, development, and deployment of corporate performance management systems.

The purpose of this paper is to consider the question of what is an appropriate enterprise resource planning (ERP) reference model for specifying areas of change in the context of IT-driven ERP implementation and through the model matching. There are other implicit goals to increasing the awareness of the reference models, as this highlights the principles embedded in ERP systems and explains the classification of reference models, which is useful in terms of the reuse of knowledge.

In this paper, a comparison between ERP reference models is conducted using a suitable decision-making technique and the final results are discussed. The comparison depends on nine criteria related to conceptual ERP reference models: scope, abstraction, granularity, views, purpose, simplicity, availability, ease of use for model matching, and target audience.

This study concludes that the business process reference model is best for specifying areas of change in the context of IT-driven ERP implementations. The final ranking of the alternatives based on all criteria places the system organizational model second, followed by the function and data/object reference models, in that order.

This paper is one of very few studies on the selection of appropriate ERP reference models according to the ERP implementation approach and model matching factors. This research also provides an in-depth analysis of various ERP reference model types.