Fast Oracle Financials Rollouts with Reference Models

Transcription

1 Fast Oracle Financials Rollouts with Reference Models Keywords: Michael Mohl PROMATIS software GmbH Ettlingen Business process model, test cases, project activities, project collaboration, operational concept description, Oracle Applications, Oracle E-Business Suite Introduction In the modern world of scarce resources and raising demands, the problem of growing cost pressure remains common for different business areas. Oracle E-Business Suite (EBS) implementation projects are not an exception. Along with the technical progress, market growth and permanent sophistication of customer requirements, most companies do not intend to raise the implementation budgets proportionally. In contrast, the IT-budgets are permanently decreasing. Therefore, it is not surprising that employment of well structured business process models becomes a proven and reliable means to ensure the quality and efficiency in software solutions development. This paper shows how this balancing act can be driven to a success by using ready-made business process reference models, test data and test cases in combination with a suitable project method. Especially in financial accounting there indeed is a great amount of analogies particularly in European rollouts. It s shown by means of practical reports how these goals can be achieved on the basis of a business process-oriented project method in combination with reference models. Special subjects to be mentioned are the (international) master data maintenance of clients, suppliers and items as well as the local and European tax requirements (VAT declaration report, European sales listing), the preparation of test data and test cases, multilingual training material and furthermore the documentation and approval of milestones. Best practices in different application fields elaborated during more than 15 years of Oracle EBS implementation experience has lead to development of a new comprehensive project method for software implementation: PROMATIS IQPM. The software-oriented architecture (SOA) concept, so popular nowadays has found its application in IQPM by representation of processes parts as atomic project services and complex processes by the means of orchestration. IQPM: All-Around Project Support The ultimate goal of the IQPM approach are top-quality project results, reached through a significant improvement in project management and execution. Standardization of project activities and documentation leads to fairly decreased project duration, associated risk minimization, and consequent cost reduction. Compared with conventional methodologies the PROMATIS IQPM views the project execution integrated in a conceptual framework. The composition of the model allows arranging single project services to form a unified whole, i.e. a supporting project framework, spanning across different projects within typical project organization. The essential features of IQPM are its comprehensiveness and flexibility. The focal point of the model is the knowledge base repository of best practice standard solutions derived from the

2 company s experience. The repository contains reference models, templates, guidelines, standards, and the entire specification of the IQPM meta-model. Moreover the reference models can be tailored according to specific customer requirements. The IQPM outline is shown in Fig. 1. The core project execution models are grouped into four classes according to project type: Business Reengineering, Packaged Business Applications (Oracle E-Business Suite, Oracle CRM On Demand, etc.), Custom Development and Business Intelligence. The supportive services include program- and project management, integrated knowledge- and quality management, strategic aspects of business change management. Fig. 1: IQPM Project Process Model Unlike traditional process models the IQPM defines a multi-dimensional framework for project processes, phases and activities. The entire process is divided into phases which contain single activities and steps. Fig.2 provides an overview of project phases based on a spiral model for project implementation developed for Packaged Business Application projects. This model serves as a framework for the project manager and the project team, providing description of all activities that should be performed during implementation of Oracle E-Business Suite, e.g. data migration, system integration testing, user trainings, etc.

3 Fig. 2: Spiral Implementation Model for Oracle EBS The last but not least component of PROMATIS IQPM are the Business Service Knowledge Bases (BSKB). The BSKB depict the standard business process flows supported by Oracle E-Business Suite and serve as knowledge framework for implementation of packaged business software. Service-Oriented Process Models for Implementation of Oracle E-Business Suite As the project is started, first the requirements engineering takes place. It usually includes business process modeling, which builds a basis for succeeding system design and architecture phases. Unfortunately there is a common problem for all ERP system implementation projects: the real world processes vary from those portrayed in the packaged software. The BSKB models offer a simple solution. Usage of service-oriented representation, i.e. functions of Oracle EBS are depicted as services, allows for creation of a multi-layer model with different degrees of abstraction. The serviceoriented approach for business process modeling helps reduce the complexity of the real world processes and enables flexible business process management through business service orchestration. Moreover, this approach provides a ready-to-use solution for implementation of business services. Newly created business services can be implemented according to the BPEL standard (Business Process Execution Language) and easily integrated with Oracle E-Business Suite.

4 Fig 3: Business Process Models for Oracle EBS The multilayer-hierarchy defined for the process models is shown in Fig. 3. The left side of the figure represents the process model hierarchy. The business services, orchestrated at the top level (Demand2PurchaseOrder, PurchaseOrder2Receipt and ReceiptPayment), pictures a rough business process taking place at the company level. The result of this orchestration (Procure2Pay) is in turn a business service, which may be used at a higher level of business service orchestration. The L 1 decomposition shows the process flow within the business service. The process parts should be described with the use of common notions, in order to facilitate process comprehension by all stakeholders involved. At the L 2 -Level each process component is described in detail, including description of Oracle E-Business Suite functionalities that will be used. Here process steps are assigned roles which will be later mapped to appropriate responsibilities in Oracle EBS. Finally, the system manuals constitute the L 3 -Level of the process model hierarchy. They are created for specific user roles and describe the actions that should be taken in the system in order to accomplish the process steps. These role-specific user manuals are called User Instructions. A user instruction is shown in Figure 4.

5 Figure. 4: User Instruction Implementation of standard software with the use of BSKB models has many advantages. Among others, as it is shown in the Fig. 3, the system manuals (user instructions) can serve as a reference point for system testing. Clearly, the number and the matter of planned test cases are defined in the customer requirements specification. Furthermore, when speaking of standard software products it is possible to define the standard test cases according to standard functionality provided and business patterns common for a specific country or region. Fig. 5: Behavior Model for Test Cases A test case model is shown in Fig. 5. Each test case consists of a number of input objects, activities and an output objects. Furthermore, the input data for the test case usually contains a parametric

6 description of a business object, e.g. supplier as a business object, supplier information as object attributes. Specially for tax requirements different test cases (e.g. for domestic suppliers, requisition for goods and services) are available. Basically any business object can be easily depicted in an object model, see Fig. 6. Fig. 6: Object Model - Supplier (Extract) On the one hand the aim of object modeling is the formal representation of a real world object in order to reveal its environment-specific characteristics. On the other hand it should deliver the systemspecific information to the end user in a friendly way, e.g. what input data is required by the system. The subject matter of the object model should represent the relevant features of the modeled environment. Therefore, there is a clear relationship between the test case and the object model. The data input for a test case is an instance of a business object. The object modeling defines data structures for formal representation of business objects. The object instances, used in the test cases are the data structures filled with corresponding values, and furthermore, reference object instances can be created for all standard test cases. These reference instances contain example data sets. Once the project testing takes place, the test data can be easily delivered by the customer based on the example data sets provided in the test model. The output objects of the test case model contain textual description of the test results, e.g. what postings should have been done, how the tax should have been calculated, etc.

7 Based on user instructions, test cases and object models, customer specific training materials can be generated in multiple languages. Also the processes for maintaining - specially for master data (customers, suppliers and items) - can be standardized because of similar legal and tax requirements inside the European Community. Contact data: Michael Mohl PROMATIS software GmbH Pforzheimer Str. 160 D Ettlingen Telefon: +49 (0) Fax: +49 (0) michael.mohl@promatis.de Internet: