Introduction

Modern businesses rely on good information systems to support decision making, manage routine processes and operate efficiently.  This dependence on digital technology is set to increase in future as manufacturing companies embrace new trends such as Industrie 4.0.  The amount of data available for decision support is also set to increase dramatically as new sensors from the IIoT (industrial internet of things) become prevalent throughout the supply chain, including suppliers and your customers.  

To maintain competitive advantage, many companies have embarked on digital transformation programmes that involve extending, enhancing and replacing their IT systems.  Taking advantage of the new digital economy, and trends like Industrie 4.0, could have a profound impact on market behaviour and could even force new business models on traditional “brick and mortar” companies.

When embarking on a new capital megaproject, it can therefore be very difficult to define the requirements for new business systems.  A capital plant can take five or more years from concept to commissioning, which is arguably a generation in the life of information technology.  The approach is therefore to define just the core systems necessary, and ensure that the IT organisation itself is set up to continue the evolution of these core systems in line with the future requirements.

In this article, I describe a generic process for defining and implementing the core business systems during a capital project.  There are, however, many possible scenarios and this generic process will need to be adapted for your own situation.

What an owner expects from the business system

From an owner perspective, there are several important outcomes expected from any business system, namely:

• The core system must support the business strategy: Owners expect that core systems must facilitate and not hinder the operation going forward.  This means that the systems should support the operational processes, and be flexible enough to support new processes as the business evolves. 
• Good information from data: Data has little value unless it is processed into information that supports actual decision-making.  The business system should be designed to produce reliable, timely and relevant information in a way that is accessible and easy to use.
• Predictable and optimised business processes: The business system should support routine processes in a way that is efficient, while handling exceptions in a structured way. 
• Compliance and governance: Owners rely on their business information systems to assist with legislative compliance, as well as internal governance.  The business system should provide tools to help monitor and manage compliance.

A General Process for implementing a Business System

Overview

A typical business system implementation consists of seven distinct stages, starting with initiate, followed by analyse, define, design, build, deploy and operate stages.  

These stages will generally follow a linear process, i.e. they start at stage 1 and proceed sequentially.  However, in certain scenarios the business might require a more flexible approach.  The project may also be broken down into multiple sub-projects or work packages, each following an appropriate methodology.

Figure 1 illustrates the generic project life-cycle when implementing a new business system.  From a planning perspective, the stages would be aligned to the capital project milestones and gate review processes.  

Figure 1:  A generic business systems project life-cycle

In the description that follows for each stage, for simplicity we will assume that there are no dependencies between the project to implement business system and the main capital project.  In practice, there is a need to closely integrate these projects and someone should be appointed into this role. 

Initiate

The goal of the initiate stage is to ensure the business systems project is properly constituted, the objectives are clear and that the project is adequately resourced in the early stages.  In a capital project environment, the business system is generally a small part of the capital expenditure and will often not attract much attention until later in the process.  Establishing the dependencies between the capital project and the business systems should be an outcome of the project framing process at the very beginning of the project.

 A typical initiation stage for a business systems project is shown in Figure 2.

Figure 2:  Initiating a business systems project

Regarding Figure 2, the initiate stage comprises the following five steps:

• Step 1 is to determine how the systems project will be set up in relation to the main capital project. Will the business systems be delivered within the scope of the capital project or handled separately?  How will progress reporting work?  What are the key milestones in terms of timing?  Who controls the respective budgets and how will expenditure be authorised?
• Step 2 is to appoint and mandate a sponsor for the systems project. This person might also be the sponsor for the main capital project, or alternatively someone from the business with a significant stake in the outcome (like the CFO or COO).  Reporting lines must be established to be clear and unambiguous between the sponsor, the business owner and the project management team.
• Step 3 is to determine how the budget will be approved and how expenditure and progress will be reported back to the owner. Remember that this work can take place ahead of FID (final investment decision) for the main project.  The business systems are often on the critical path for establishing the new business and if this work starts too late, it could negatively impact the overall schedule.  Work will therefore often start during the feasibility stage of the main project.
• Step 4 involves building the team that will be responsible for executing the systems project. Due to the nature of these projects, there will be several key business stakeholders that will need to be available on a part-time or full-time basis.  In greenfield situations, these people might not yet be appointed in which case proxies need to be found.  The typical team for a systems project will include subject matter experts, business users, business analysts, representatives of internal and external stakeholders as well as IT specialists.
• Step 5 is the project kick-off (for the systems project). This is an important step that aligns team members to the overall business objectives.  This kick-off meeting will also cover the process to be followed during subsequent stages and develop the high-level plan.

Analyse

The analysis stage can have a material impact on costs and ultimately project success.   During this stage, the high-level system requirements are developed to support the business strategy. The different steps in the analysis stage are shown in Figure 3.

Figure 3:  The analysis stage for system projects

Regarding Figure 3, the analysis stage comprises the following five steps:

• Step 1 involves strategy and is to determine the requirements from the business strategy in terms of the value chain and the proposed organisation structure. This also involves understanding the business drivers.  The key performance indicators (KPIs) and information requirements along the value chain are documented, as well as mapping of the organisational unit responsibilities with each high-level process in the value chain.
• Step 2 involves modelling the high level “as-is” business processes (if these exist) and the “to-be” processes to determine the gap. In the case of a greenfield project, there is often nothing substantive in place and the new business does not exist yet.  In this scenario, you might agree to base the “to-be” processes on the standard functionality of a preferred software solution (e.g. Enterprise Resource planning – ERP), or adopt the processes from other established businesses in the same industry.
• Step 3 is to determine the main data entities that are involved in the processes (again at a high level). Examples of data entities are as follows: Employees; Customers; Materials; Equipment; Sales orders; Purchase orders; Catalogue number; etc.
• Step 4 involves grouping the process management and data entities into logical software application areas, such as materials resource planning, customer relationship management, supply chain management, human capital management, health and clinic systems, laboratory information management, supply chain forecasting, safety systems and so on. Some of these applications might be consolidated into a single large system (such as ERP).  Other software might be needed for very specific industry functionality or unique requirements of the owner.  You may also need to do bespoke development in specialised circumstances.  The output of step 4 is a high-level application architecture that supports all the business processes.  At this stage (while the final vendor is unknown), it is still a good idea to know who the likely vendors are and the characteristics of their respective solutions. 
• Step 5 is to optimise by looking for ways to simplify or rationalise the proposed system and review the impact of the envisaged applications on both the business and the IT organisation. This optimisation step will also identify new efficiencies, prevent duplication, break down organisation silos and ensure that adequate expertise will exist to operate and support the envisaged system.

The result of the analysis stage is a high-level business requirement specification that integrates data, processes, applications and organisation.  This specification will be tightly aligned to business strategy.  This document needs to be signed off by the stakeholders ahead of proceeding with a more detailed design.

Define

During definition, requirements are developed using the framework developed during the analysis stage.  This is quite an intensive process and involves detailed business process modelling.  Requirements are the specifications for the system that will be procured/implemented.  During this stage, any functional gap is further analysed to develop detailed requirement for the proposed new system, and the scope of any development work.

Until the vendors for the package solutions have been finalised, it is important to keep this analysis at a high enough level to develop a generic specification.  This will be used to go out on a RFP (request for proposal) which ultimately leads to final vendor selection.  The level of detail at this stage should be sufficient for the vendor to be able to provide accurate pricing and for the team to perform a proper system selection.  

During this stage, it is important to develop the proposed implementation methodology to be followed, as well as any software development methodologies that will be used.  This is normally done at an application or software interface level.  

You should also have a good idea at the end of this stage as to how you will outsource some or all the work.  For example, will you work with a system integrator, through your IT partner, an application specialist, IT service provider, etc.

The stage ends with the vendor selection process.

Design

To start detailed design, you will need to have identified the vendors of any packaged software applications.  You should realise that any changes in system selection beyond this point, will have a material impact on the project.

Once the commercial software packages are selected, it is possible to do detailed process modelling.  Functional gaps can then be finalised and the detailed scope of work for the various development and integration projects can be finalised.

It might not always be possible to select all the vendors upfront, so certain work packages might lag while vendor selection takes place.  This is one of the real-world complexities that will need careful coordination and management of any dependencies.

The exact design process followed during the rest of this stage will depend on the selected vendors’ methodology, as well as the nature of the development required.

The selected vendor’s methodology will cover the Definition and the Design/Build phases in some detail, even down to actual system configuration.  Vendor methodologies have been extensively tested and optimised in multiple situations, and therefore we recommend adopting them where possible.  However, be aware that introducing different methodologies at a relatively late stage into a project can create confusion in that there might be different terminology used between your own project processes and that of the vendor.  Here it is very important that managers of the respective work packages ensure that every team member has clarity on exactly the methodology they are following for each software application, interface or bespoke development.  This is particularly important for part time resources who work on multiple applications over the project life-cycle, and who are therefore potentially working with multiple approaches.

Build

During the build stage, all the system functions are configured, together with any software development work.  This stage involves relatively high effort and hours billed by an expanded project team.  Because the design has been finalised in the previous stage, strict change control should be enforced from this point on.

Testing of the system is also completed during the build stage.  End user documentation and training is also prepared in line with the skills levels, using tools and content specific to the vendor solution.

Deploy

During deployment, the development and test environments will be moved into production.  This is normally described as “go live”, but in complex environments is not necessarily a single event and various systems might go-live at different times.  

During deployment (and as late as possible) end users will be trained in the use of the new system. 

Deployment must be supported by a change management process that ensures that all end-users buy in to the new system and become competent in their new roles.    Deployment is also normally characterised by high level of support and by an emphasis on skills transfer from the project team into the business.

Operate

The operate stage is characterised by a period of stabilisation, followed by business process optimisation (BPO).   This work will usually be the responsibility of the IT organisation who plays a coordinating role with the business.  

The various improvement, upgrade and optimisation projects are typically arranged into a portfolio of potential IT projects and prioritised in line with the business value and the cost/availability of resources. 

From this point on, all further investments are motivated and approved based on the incremental value to the business.   IT management systems, such as COBIT (Wikipedia, 2017a) or ITIL (Wikipedia, 2017b), are used to ensure that the systems adapt and sustainably add business value.

Concluding Remarks

Implementing a new business system is a complex undertaking, especially when done in support of a new capital investment.  A clear understanding of the process that will be followed is important, as is an understanding of how this process relates to the main project milestones.  The process starts with a high-level requirement definition that progressively gets more detailed as vendors are selected, business processes are finalised and interfaces are built.  This requires a great deal of planning, coordination and control to be successful.  The outcome is a business system that meets the owners’ requirements exactly, supports the business strategy and can be sustainably operated.

For more information on implementing business systems in a capital environment you can refer to the OTC Business Systems Toolkit (OTC, 2016).

References

Wikipedia, 2017a, COBIT – Control Objectives for Information and Related Technologies.  Available from https://en.wikipedia.org/wiki/COBIT  Accessed on 20 March 2017.

Wikipedia, 2017b, ITIL – Information Technology Infrastructure Library.  Available from https://en.wikipedia.org/wiki/ITIL  Accessed on 20 March 2017.

OTC (Owner Team Consultation), 2016, OTC Toolkits Overview, Available from http://www.ownerteamconsult.com/toolkits-overview/  Accessed on 23 March 2017.