Abstract
Many of us have heard or, maybe even worse, have been part of horror stories when implementing an ERP (Enterprise Resource Planning) application. Budget overruns, scope creep, poor expectation settings, wrong focus,…Instead of starting to design the solution from a white sheet of paper one can also use Business Flows, supported by the application, as a starting point.
This paper will provide an insight in how the use of Business Flows can help in achieving an implementation of an ERP implementation in time and budget, while living up to the expectations of the end user. Based on this alternative way of working a project management method called “Applications Implementation Method for Business Flows” has been developed.
The first part of the paper will provide a theoretical insight of this Application Implementation Method for Business Flows. The second part will consist of a case study.
Introduction
A Business Flow is a sequence of related business processes designed to achieve a critical business objective, incorporating leading business practices. A flow can also be a series of flows.
An Application Implementation Method, supporting this approach, has been build and tried out in many different application implementation projects.
This method uses preseeded implementation assets in order to accelerate the implementation timeline and to keep the focus of an implementation on business processes and benefits, rather than software features and functions. Some hallmarks of a Business Flows approach include:
- A Business Process Focus
- Use of pre-defined Business Flows supported by the application as a starting point of the Future Process Model
- Rapid establishment of a working software environment for use of mapping the customer's business to the Business Flows supported by the application
- Early introduction of iterative hands-on user testing cycles
This presentation will give a more in depth overview of this Application Implementation Method and will be supplemented with a real live Project experience of a Flemish Government Agency in Belgium.
Introduction of a Business Flow
What is a Business Flow?
Definition - A Business Flow is a sequence of related business processes designed to achieve a critical objective, incorporating leading business practices. A flow can also be a series of flows.
Business flows often cross-organizational and application boundaries, reflecting how business is actually conducted within an enterprise. “Order to Cash” is an example of a business flow, that addresses the revenue cycle of a business. Because Business Flows are expressed in neutral business language familiar to business people, they improve the implementer's ability to communicate with customers about how they can manage their business using the ERP application. This focus on business processes, rather than on product features and functions, contributes to better communications between customer and implementers, resulting in improved understanding of business requirements and software options/capabilities, etc.
An example of the “Procure to Pay” Business Flow is given in exhibit 1 below.
Exhibit 1: Procure to Pay Business Flow
Business Flows reflect standard business practices for an industry, optimized for the ERP application to be implemented. They represent a leading practice approach to employing standard functionality contained in the ERP application to satisfy common business requirements. The Application Implementation Method for Business Flows employs the Business Flows as the starting point for an implementation.
What are the Benefits of using Business Flows during an implementation?
By positioning Business Flows supported by the ERP application as the proposed future process model, and employing iterative, hands-on testing cycles to refine the model, it's possible to expedite the establishment of an application instance suitable for testing early in the project, thereby achieving significant savings in time and effort. Indeed, possible suitable solutions are allready embedded in the preconfigured ERP application. By doing so one does not start from a white sheet of paper on the drawing board.
With a predefined Future Process Model (i.e. Business Flows) serving as the starting point for a flow-based approach, the proposed, initial configuration of the new system is already defined. An environment reflecting that proposed configuration can quickly be established, and the customer can begin working with the system very early in the implementation. The early introduction of hands-on familiarization, testing, and experimentation by the customer is key to accelerated progress. Providing the customer with the opportunity to work with the new system early on helps to build confidence in the proposed configuration, and begin the validation/refinement process sooner.
Additionally, by effectively demonstrating how the customer can operate the business using Business Flows employing standard functionality of the ERP application, the approach also increases the likelihood that the Application software will be implemented without unnecessary customizations or extensions, resulting in additional savings.
We dive into the details now
Highlights of the approach
Top Level Flow:
Exhibit 2 below depicts some of the key activities that comprise the Application Implementation Method for Business Flows.
Exhibit 2: AIM for Business Flows “Top Level Flow”
Most obvious among these characteristics are the iterative Conference Room Pilots, represented here as CRP 1, CRP 2 and CRP 3. CRP 1 is primarily intended to familiarize the customer with the Business Flows being implemented, and to conduct an initial mapping of the customer's business to those Business Flows. CRP's 2 and 3 concentrate on refining the mapping, incorporating approved changes, and testing/retesting the revised environment to confirm it's ability to support the customer's requirements. Because CRP 1 is conducted in an Application environment based on the standard Business Flows, the pre-seeded implementation assets employed (i.e. Test Scripts, etc.) are useable without modification. Changes identified during CRP 1 are reviewed with the customer and, if approved, incorporated in the implementation assets in preparation for the next CRP cycle. Likewise, refinements identified in CRP 2 are also reviewed with the customer and, if approved, incorporated in the delivery materials in preparation for CRP 3.
Several business architecture workshops are planned during the Definition Phase, which are designed to assist the customer in defining suitable fundamental decisions on basic functional architecture of the solution (e.g. Chart of Accounts), which have implications across the entire implemented application. Application extensions, if required to fill gaps in functionality, are identified during the first and second CRP cycles, designed and built during Elaboration and Build phases, and tested during CRP 3. Should more than one iteration of CRP 2 and/or CRP 3 be necessary due to the complexity of the engagement, or other criteria, the method provides the flexibility to plan those additional iterations, as indicated in the diagram.
Phases of the project:
The goal of the Definition phase is to plan the project, and rapidly establish a pre-configured and tested environment for familiarizing the customer with the Business Flows being implemented. During Definition, workshops are conducted to educate the customer about critical decisions to be made regarding application architecture components, such as the Chart of Accounts Structure. One Conference Room Pilot (CRP) is planned for the Definition Phase – CRP 1. The focus of CRP 1 is to familiarize the customer with the Business Flows being implemented and map the Business Flows to the customer's business, while identifying any potential changes that are required to “personalize” the system to better fit the customer's needs.
The goal of the Elaboration phase is to refine the solution through a second iterative testing (CRP) cycle. This second Conference Room Pilot provides the first opportunity to validate the customer's tailored set up of the ERP application. It also provides an initial look at some of the other changes resulting from process or configuration modifications identified during CRP 1.
Elaboration also encompasses the design of custom extensions, refinement of the technical architecture design, and a number of Data Conversion and Performance Testing preparatory activities.
The goal of the Build phase is to confirm that the overall solution meets the customer's business needs. During the Build phase, the CRP 3.0 environment is prepared incorporating custom extensions for the first time, and also incorporating sample converted legacy data. Application configuration changes resulting from CRP 2.0 are also validated during this test cycle.
During Transition, the project team deploys the new system into the organization. All the elements of the implementation must come together to transition successfully to actual production.
The Production phase starts immediately with the production cutover. Production marks the last phase of the implementation and the beginning of the system support cycle. Included in this final phase is a series of refinement and measurement activities.
The differences with a classical Application Implementation Method
An overview of the differences between a traditional implementation approach and the Flow Driven approach is given in exhibit 3 below.
A comparison of the traditional implementation with the Business Flow Approach, highlights many of the differences, and some similarities:
Exhibit 3: Comparing Implementation Approaches
- Traditional -- future-state processes are undefined and open-ended at the start
New Approach -- standard Business Flows serve as the future-state processes – a pre-defined starting point - Traditional -- we analyze current business environment, define future-state model (often heavily influenced by current procedures), derive business requirements, and map requirements to the ERP application.
New Approach -- focus on implementing Business Flows, supported by the application, as the future business model, and map that model to the customer's business. - Traditional -- based on the “waterfall' concept of systems engineering, where all Analysis was completed before design began, and Build followed Design, etc.
New Approach -- more iterative in nature, incrementally converging on the right solution over multiple testing/modification cycles. - Traditional -- Business System Testing environment typically built from scratch using an installed, unconfigured instance updated with the customer's tailored data. It often took weeks or months with sometimes unpredictable results.
New Approach -- starts with a pre-defined and tested, fully configured environment for dependable and predictable hands-on testing/familiarization. - Traditional -- Emphasis on mapping business requirements to application features and functions New Approach -- keeps emphasis on Business Flows and how they can be employed to run a customers business.
- Traditional -- Business System Testing conducted in Build, often months into project.
New Approach -- testing begins within days of project startup. - Traditional -- one System Testing evolution in the Build Phase
New Approach -- employs multiple, iterative testing cycles - Traditional --end-users often not involved until Acceptance Testing
New Approach -- end-user involvement throughout the development lifecycle. - Finally, and most significantly, both approaches allow for the resulting solution to be tailored to fit the customer's business – it is important to recognize that the new approach does NOT place any restrictions on the final solution.
The concept of iterative Conference Room Pilots
The iterative testing cycles utilized in the Business Flows approach are conducted in a Conference Room Pilot, or CRP, style. A Conference Room Pilot (CRP) refers to the technique and activities surrounding the planning and execution of one or more formal test scripts aimed at validating the application system against the client's business needs. The origin of the term comes from the practice of placing workstations in a conference room and arranging them in a particular order (usually by logical process or Business Flow) for testing. Test scripts were then passed down the line from one tester to the next according to the natural flow of the business process.
A CRP usually involves performing tests to check the validity of application setups, the integration of business flows within the target application system, the validity of converted data, and the adequacy of end-user procedural documentation. Additionally, a CRP may be employed to determine the degree to which a defined Business Flow matches a customer's business need, and to identify changes that are necessary and appropriate for the customer scenario. It is important to establish the goal of each CRP ahead of time and to then review the execution of the CRP to determine whether or not the goal was achieved.
Each CRP iteration identifies potential changes to the pre-configured environment. These potential changes are documented and categorized according to priority. Each of the potential changes is then analyzed and a resolution determined. Resolution of potential changes may include any of the following alternatives:
- change in application configuration
- manual workaround
- custom extension, or
- a decision to forego (or postpone) a change and adopt the standard Business Flow, as defined
Based on the agreed resolutions, the following deliverables are updated as appropriate:
- Business Flows
- Business Procedures
- Application Setup documents, and associated software tools for loading the modified setup data
- System Test Scripts
Tasks that need to be performed in each phase of the project
In exhibit 4 below the relationship between the phases and the processes is given. A process defines a set of tasks related by subject matter, required skills and common dependencies. A process usually spans several phases in the project.
Exhibit 4: relationship between phases and processes.
Business Process Mapping
Business Process Mapping addresses the activities surrounding the customer's initial familiarization with the Business Flows, and the initial mapping of the customer's business to the Flows. It also encompasses the definition of customer data needed to “personalize” the system for the customer, e.g. the Chart of Accounts.
Application and Technical Architecture
During the Application and Technical Architecture process, the project team designs an information system architecture around the organization's business vision. Included are the ERP Application, third party, and custom applications; computing hardware; and networks and data communications infrastructure.
Module Design and Build
The Module Design and Build process produces custom application extensions to fill gaps in functionality identified during Conference Room Pilots 1 and 2. Custom systems include program modules (forms, reports, alerts, database triggers, and so on) that must be designed, built, and tested before they can be incorporated into the new system. Module Design and Build addresses the design and development of the custom modules.
Data Conversion
The Conversion process defines the tasks and deliverables required to convert legacy data to the ERP application. The first step of this process is to explicitly define the data business objects identified for conversion along with the legacy source systems. System testing, training, and acceptance testing require converted data before production cutover.
Documentation
The Documentation process begins with documentation standards created early in the project to build quality operation support reference materials. Documentation requirements and implementation complexity are closely correlated, and the amount and level of detail in the documentation varies by project.
Business System Testing
The Business System Testing process is a formal, integrated approach to testing the quality of all application system elements. It focuses on preparing for testing early in the project lifecycle, linking testing requirements back to business requirements, and securing project testing resources. The Business System Testing process takes on additional significance in a Business Flows implementation because of its early introduction in the project and the iterative nature of the testing, or Conference Room Pilot cycles, in the approach.
Performance Testing
The Performance Testing process helps the project team define, build, and execute a performance test on specific system configurations.
Adoption and Learning
The Adoption and Learning process accelerates the implementation team's ability to work together through team building and organization-specific application learning. Learning needs of all personnel impacted by the implementation are considered, and appropriate training materials and learning events are developed and conducted.
Production Migration
The objective of the Production Migration process is to migrate the organization, systems, and people to the new enterprise system. The Production Migration process encompasses transition to production readiness, production cutover, and post-production support.
Deliverables that need to be produced in each phase of the project
Below is given an extract of the deliverables that will have to be produced:
- Business Flow Diagrams: these are updated on a need by basis during the project
- High Level Solution Document: The purpose of this document is to describe the Functional architecture and the supporting business justification for the implementation of the solution. This document provides a helicopter view on the applications set-up parameters that have a profound effect on the way the application is laid out and on the basic functioning of the applications, and puts them in a framework in which the business-flows will be executed. It is possible that this document will need to be adapted during the project.
- Business Requirements Mapping Document: this document maps each of the process steps from the Business Flows supported by the ERP with the business requirements of the customer. If a gap is identified, closure of this gap by either a workaround or a customization will be indicated. It is essential to note that the entry point will be the business process as supported by the application and not the business requirement of the customer.
- Testscripts: starting from standard testscripts, delivered by the ERP application vendor, describing the business flows as supported by the application, one will need to adapt these to the specific business needs of the customer.
- Detailed Set Up documentation which describes the detailed parameter setting of the ERP application.
- Functional Specification of the customizations: this will be an output of CRP2 in the elaboration phase.
The other deliverables or timing thereof are similar to the traditional approach and are therefore not elaborated in this paper.
Case Study : The Department Fleet of the Ministry of the Flemish Community
A short overview
DAB Vloot (=Fleet) is part of the Ministry of the Flemish Government in Belgium. This local government agency employs 500 people and has the following tasks:
- Bring the sea pilots to the ships to be piloted to the port of Antwerp or Rotterdam.
- Provide hotel services to the pilots at sea or onshore
- Mark the seaways at sea and the river Scheldt in Belgium
- Have ships available and operational on short notice for providing help in case of emergencies at sea.
- Operate river ferry services on several rivers in the Flemish part of Belgium.
All communication and documentation of this project had to be in Dutch.
The department Fleet had the following key objectives for this pilot project:
- Implement an integrated ERP application whereby the logistic transactions would generate the financial transactions, avoiding re-entering.
- Provide good analytic financial reporting in order to be able to monitor the operational efficiency of the department.
- Demonstrate that it is possible to implement an ERP application within time and budget.
The approach that the Department Fleet wanted to use in this project
The customer did not want to start the project without a good mutual understanding of the project plan and the Business Requirements.
Because of this, the customer did not want to start the implementation of the ERP application without the process flows defined upfront. The Customer had its own framework for modeling and used this to model its ‘to be’ processes. This was not finished when the project started but the work done provided a good basis to start from. We used this material in our definition and elaboration phase for the Business Process Mapping process.
The customer was very committed in minimizing customizations.
How did the Department Fleet experience the project
The customer experienced that more than one language is being used
- during iteration session
- in the deliverables
Therefore it is important to capture all that is being discussed/covered during the workshop is also documented in the deliverables. A method that might be used is to have the Business Requirements Mapping document updated online during the workshop. This has not been tested in the field yet.
There is more than the application point of view since the reference frames differ from both parties. Iteration can be a good way to deal with it, when documentation is being understood. During the project the customer experienced that the documentation needs more detail and description.
The iterative approach is good only when the outcome of each iteration is being fully understood and matched with the process flows of the customer. The kind and amount of questions raised during the sessions covering the detailed parameter setting of the ERP application showed how well understood the IT solution was.
The Business flows approach does give the opportunity to have an implementation team from the customer, which is able to learn and understand the new application by constantly practicing in the CRP pilot environment early in the project. But it is highly preferable if some people have a thorough understanding of the ERP product / modules, before the start of the project. Therefore training before the start of the project is very beneficial and recommended.
The main conclusions from a client perspective
Be prepared as ‘receiver’ of the IT-application
Business flows are crucial in:
- making good deals, fixed scope, fixed price, timeframe,…
- Evaluating the result, documentation
There is more than AIM for Business flows needed to have a good project:
- change management
- communication, communication, communication
- reporting is too often the ‘stepmother’
- IT - infrastructure is never 'easy to get done
The Implementer's ‘logical’ view of different phases is not always the client's reality (e.g. IT-readiness)
AIM for Business flows, gains:
- faster implementation
- less ‘lost’ education/training @Software Supplier
- Implementer gets more ‘confronted’ with the workflow
- possibility to change some decisions during the project (iteration really is step forward)
Re-use within the Ministry is possible because of better understanding of the application that has been rolled out and matching with business flows.
Lessons Learned both from a client perspective as from a application vendor perspective
In view of the iterative concept of the method it is not enough to have a detailed list of the deliverables. It is even more important to agree upfront on the format, timing and evolving content of the deliverables during the lifecycle of the project.
Detailed set up discussions and agreement between CRP1 and CRP2. This will also enhance knowledge transfer. First version of the set-up document needs to be delivered at that time.
User training should be organized in line with the business flows and given by persons who know the customer's business and requirements. The classical module training does not work anymore.
Flow based implementations can be executed within a short time frame, but there are limits. To make sure that the implementation becomes a real success and that the customer can take full advantage of the new application, the customer still needs enough time to absorb the new functionality and business procedures within its organization. This fact cannot be underestimated.
Summary
Experience has shown that a Business Flow approach for implementing an ERP application can indeed accelerate the implementation timeline and keep focus on the implementation of business processes and benefits, rather than software feature and functions.
In order to achieve rapid implementation of supported business flows preseeded implementation assets are needed. These assets need to be provided by the application vendor or its partners.
The main hallmarks of the Business Flows approach include:
- A Business Process Focus
- Use of pre-defined Business Flows supported by the application as a starting point of the Future Process Model
- Rapid establishment of a working software environment for use of mapping the customer's business to the Business Flows supported by the application
- Early introduction of iterative hands-on user testing cycles
Although rapid implementation is possible field experience has shown that the customer still needs enough time to absorb the new functionality and business procedures within its organization.