ArcWorkbench business transformation

Define Corporate Vision and Goals

A Vision Statement, agreed by the organisation's executive group, is confirmed. Such a statement will probably already exist within most organisations, but sometimes needs clarification. It will provide a reference for project outputs and guidance in establishing the project approach. It should identify the fundamental culture of the organisation, its visionary goals and the strategic approach to attain them.

Create Project Initiation Document

The Project Initiation Document (PID) confirms the project objectives and terms of reference, and defines a structure for overall management of the project. The purpose of the PID is to provide a concise statement that confirms the project's overall business case, timescales, resource requirements and major risk areas, and to provide a strategy for implementing the change. The PID defines:

• Overview of the business framework
• Project scope, objectives and business benefit expectation
• Project strategic approach and policy constraints
• Project outline plan and resource requirements
• Project Deliverables
• Project risks and countermeasures
• Summary business case

Define Project Management Controls

Project team roles and reporting hierarchy are confirmed, with named staff members from the client organisation and external consultants allocated to particular project roles. Procedures are defined for:

• Identifying and managing ad-hoc issues and new risks
• Configuration management and change control of project output deliverables
• Formal management reporting

Define High-level and Detailed Plans

Planning is undertaken at two levels. The first level is the outline project plan, which is included in the PID, identifying project phases and inter-dependencies with a rough timescale for their completion. The second level of planning breaks each project phase into stages and detailed tasks. Both levels of planning focus upon the deliverable outputs required from phases/stages within the context of the agreed project strategy and policy constraints. From this basis, estimates of resource requirements and timescales for undertaking projects and project stages are made.

Define a High-level Business Process Model

A high-level business process model is defined. The model should be defined by a 2-3 level hierarchy, showing how business processes inter-link with each other. Development of the business process model is normally done in a workshop environment, from the basis of a pre-defined high-level Draxmont Owl generic model, relevant to the client's industry (an example Level 1 model is show below):

Define the Existing Organisation and Budgetary Structure

Depending upon the scope of the project, an organisational structure is defined that identifies the different organisation sites, and within these sites the Departments that exist and the roles being undertaken by staff within them. Department Activity, Capital and Overhead budgets are identified.

Identify Current Activity

The activities being undertaken by each type of Role within a Department are identified. Department managers are asked to estimate the percentage of their Activity Budget that each activity absorbs. Activities are mapped to the high-level process model, providing an estimate of the cost of individual processes.

Define Process Operating Policies

An organisation may wish to impose certain operating policies or constraints on how it wants a process to be undertaken. For instance, a facilities management organisation responsible for a number of different client facilities may want the process associated with capturing service requirements and scheduling service engineers to be managed by a central call centre team, rather than a team for each client. Alternatively, it may be judged necessary to retain a process in-house, rather than outsource it, for strategic reasons - even though an efficiency case could be made for outsourcing it. Each Process would be discussed with senior managers to determine if any policy or constraint requirements should be applied to its design.

Identify Key Operating Environment Attributes

A number of open and closed questions will need to be asked about the operating environment of each process. Answers to these questions will provide reference points for challenging the both the existing process design and any proposed future design. Irrespective of the organisation, many of these questions will be common across different types of organisation, other questions will common within the same type of organisation, and just a few likely to be specific to an individual organisation. Draxmont Owl has compiled a generic set of such questions, from which a relevant portfolio can be assemble for each particular project. Advance warning of these questions will provide the client organisation with sufficient time to answer them as accurately as possible.

Process Inputs and Outputs

A Business Process can be regarded as a "black box". Inside the box is a process design mechanism and resources (people, machines, etc.) to convert inputs into outputs, according to the rules and logic of the design mechanism.

All processes will have inputs and outputs. Inputs might be information, physical materials or services coming from either other internal processes or externally (i.e. other organisations). Outputs are provided to either other internal processes or external organisations/customers. Both inputs and outputs can have a quality rating (say poor to excellent) and may involve an external cost (inputs) or external income revenue (outputs).

Each process is reviewed to determine its current inputs and outputs, their quality, where they are coming from and going to, and any associated external costs/revenue involved.

Process Key Performance Indicators

Key Performance Indicators (KPIs) monitor the effectiveness and efficiency of a Process. KPIs are quantifiable measures. Similar processes will have similar measures across different organisations. The values that each organisation can apply to these measures will determine the effectiveness and efficiency of one organisation compared to another.

KPIs will be identified for each process. Assessments will be made of the value that the client organisation can apply to each KPI. A realistic improvement target value will be established for each KPI (within an appropriate period), based upon the current value of the KPI and the value that competitor organisations are expected to achieve.

The improvement targeted for each KPI will be examined and translated, where possible, into a financial benefit expectation. For instance, this might be a saving in internal costs or an improvement in external revenue.

Process Improvement Capability Analysis

The capability of each process to improve business performance will be analysed. Process improvement potential will ranked from different viewpoints:

• The current internal cost of the process
• The potential for reducing the cost of the process by meeting KPI targets
• The financial benefit potential available from KPI improvement
• The potential for improving the output quality and service of the process
• Comparing processes in this way will highlight which processes have the highest priority for re-design and which processes should be central to development of the systems strategy

Identify Process High-Level System Requirements

Analysis of each Process's business improvement potential will provide focus for defining the primary functional requirements that systems must have to support the Process. A workshop should be undertaken with senior managers to review process analysis findings. In doing so, previous defined process policies should also be reviewed, and if necessary changed and enhanced (process analysis may identify that fundamental change is required). For each process, relatively high-level system functionality requirements to support it should be defined. At this stage, these requirements would be independent of the detailed process design. Detailed refinements of the process design should not change the need a requirement.

Identify Current System Capability

For each high-level system requirement, an assessment should be made of the capability of current systems to meet its needs. Combining these findings with the improvement potential of a process will highlight the business processes that should be central to the development of the future system strategy. For instance, if the processes with the highest potential for improvement are generally well served by current systems, then the future systems strategy should be developed around maintaining current systems. However, if not, then new systems will need to be identified that could potentially meet the requirement need.

Define the Future System Strategy

The approach to developing a System Strategy is likely to be different depending upon where the centre of gravity lies between retaining current systems and identifying new systems. If the majority of current systems meet the needs of key requirements, then any additional new systems would most likely be specialist systems focusing on specific processes. These specialist systems would need to be integrated with existing systems.

If the majority of current systems do not meet the needs of key requirements, then the strategy will probably be more focused upon implementing a new enterprise-wide system that supports most of the business processes, perhaps with a few specialist systems integrated with it. The advantage of using such an enterprise-wide system is that integration issues are minimised. Key elements of developing the system strategy will be:

• Considering vendors who are going to stay in business and continuously develop their products
• Deciding upon the extent to which third-party specialist vendor products will be required to bolt onto core enterprise-wide systems
• Deciding upon the technical infrastructure architecture upon which data and application systems will be stored and delivered to users. This will include decisions on communication standards, database standards, operating system standards, and application development standards. All will have implicit technical skill requirements - that may or may not be readily available
• Deciding upon whether the organisation, itself, will manage the day-to-day delivery of data and applications to users, or whether it will subcontract this to a specialist IT service provider

Define the System Infrastructure Development Strategy

Working with the system supplier a schematic vision of the hardware, software, database and communications infrastructure should be defined. A strategy for evolving the full systems infrastructure should be established (e.g. all-at-once, site-by-site). This should be based upon business priorities, the dependency sequence for installing the various infrastructure elements, and the risks (and their countermeasures) involved in the strategy.

From this a detailed project plan should be developed for installing each element of the hardware, software, database and communications infrastructure. Key elements of developing the system strategy will be:

• Defining the logical hardware/software architecture, showing how Application, Database, Integration and Report Servers interact with each other, and with networks and end user machines
• Defining the physical deployment architecture of specific hardware and software elements across organisational sites
• The technical specification of specific elements of deployed hardware (e.g. memory, disk storage, processor speed, make and model)
• The technical specification of specific elements of deployed software (e.g. type, version, patch level)
• Specification of how the infrastructure will support system failure and achievement of disaster recovery
• Specification of how the infrastructure will be protected from unauthorised access
• Specification of performance response targets (e.g. the number seconds - maximum and, say, 95% of cases - for login, saving a record, accessing new screens, running reports)
• Defining the frequency of archiving different data sets, out of the main system database into an archive database

Define a Database Environment Strategy

During the development of new systems a number of different database environments are likely to be required, in addition to the live system environment. These would include environments for application development and configuration; migration script development and testing; integration development; testing; training; and, perhaps, a "play-pit" environment for users to access after training and before system go-live.

Policies will need to be defined for ensuring how all of these environments remain synchronised with each other.

Define the System Management Organisation

A system management organisation should be established to manage the systems infrastructure and to provide system services to Users. The size of this organisation will vary from a single individual for small installations to a full IT department of technical specialists for large installations. Conceivably aspects of system management services could be outsourced to a third party organisation. However, a "system administrator" role is likely to be retained in-house to provide a basic system configuration service and to manage user access to the applications.

Define Requirements

The Systems Strategy will identify areas of the business process model that require support from new systems, development of existing systems, and the provision of services for the external delivery of systems. A requirements specification is created, but care should be taken to focus it to the really key issues that a system/service needs to address.

These days the functionality available from the major enterprise-wide package system suppliers, with their alliance partners, is sufficient to meet the needs of most organisations, ideally with minimal customisation of software. Over-prescribing requirements (beyond those that are key) is unnecessary, as it may constrain thinking to that of existing paradigms, where the design of a system or service itself may open up opportunities for improving processes that have not previously considered.

System and Service Selection

The requirements specification would identify the key requirements of each business process. This may involve new systems, development of existing systems, provision of a system delivery service, or a combination of all three. This would form the basis of one or more Invitation-to-Tender document, sent to groups of prospective suppliers.

These suppliers would be requested to specify how their system would meet each requirement. Where the supplier's system/service does not meet a requirement in full, then the supplier would be requested to identify the feasibility of customising the system/service, to meet the requirement. Suppliers should be encouraged to outline how the functionality of their system/service could support the process model as a whole, in addition to responding to the specific requirements identified.

A formal assessment procedure would compare the capability of each supplier system/service to meet the process model needs. A scoring mechanism would be used to ensure demonstrable objectivity.

Process Improvement Teams

Process Improvement Teams should be formed to review and recommend changes to the operation of one or more business processes defined within the existing Business Process Model. These teams should include people with hands-on experience of the business process concerned and also people from other processes that interface with it, and people with a detailed understanding of the functionality of the systems that will support the process. Some people may be involved with more than one team. Teams are likely to include both client staff and external consultants.

Initial Process Improvement Workshops

The overall objective of process improvement workshops should be to change the way that things are done within the process, so that it more effectively and efficiently addresses achievement of Key Performance Indicator targets. A key aspect in doing so should be to recognise the capabilities and functionality that can be provided by new systems supporting the process. Key events taking place in the current Activity Chain should be identified with attribute measures such as volumes and frequency of work being handled; data security issues; and the existing organisational roles which are involved with particular activities. Opportunities for changing the way that things are done, to improve the process, should be identified. Recommendations should be provided for:

• Rules and Policies to be adopted within the business process
• Changing the process activity chain
• Changing roles and responsibilities
• Using (and not using) system functionality to support the new activity chain
• Change implementation issues that will need to be addressed
• The potential for external customers and suppliers to be incorporated into the process (reducing internal resource requirements)

The business process model should be refined and developed further to reflect the new vision of how the process would be conducted.

Design and Build Initial Prototype System

Prototyping is concerned with configuring the new application system and using real life data to prove the working logic of the new business process design. Ideally, development of the prototype system should be conducted in two cycles. Each cycle should have an agreed time-box within which the prototype will be constructed.

A two-stage, time-boxed, prototype approach will support achievement of fast and demonstrable business benefits and maintain the momentum of the project. An initial prototype design should make no attempt to alter or enhance system out-of-box functionality. This will force people to question their existing paradigms for the process design.

To begin with, solutions for addressing business process requirements should be sought from the existing functionality, utilising the inherent configurability and screen design utilities provided by the system. All configuration changes to the out-of-box system would be recorded, for audit purposes. This is essential for supporting the development of a second prototype and downstream project activities concerned with data migration, and also longer term needs for system upgrades.

Final Process Improvement Workshops

The first prototype stage should meet 95% of the requirements of the new business process design specified in the Initial Process Improvement Workshop. The first prototype should be demonstrated in a second, and final, Process Improvement Workshop. It is likely that changes will be requested to the initial prototype design. Such change requests would be formally captured within the Workshop, along with a consensus view of their importance. Their impact on project timescales and costs would be analysis. A senior management group would critically review and either approve or reject each change request. For those change requests that are approved, each would be classified to be included in the second prototype, or delayed until after the system has been cut over into a live working environment. In doing so, the time-box period allocated to the second prototype would be considered, along with a judgement of how essential the requirement is immediately upon the system being cut over into a live working environment.

Design and Build Final Prototype System

A second prototype system would be developed, that would incorporate the approved change requests (essential for live cut-over).

User Training

Suppliers (both application software and technical hardware) will most likely have standard training courses available, which can be used as the basis for all user and system management training. These courses should be examined, and if necessary adapted and enhanced, to construct optimal training modules for the organisation's staff.

Each role defined within the new business processes should be related to the training module(s) that it requires. A training schedule should be developed and individual user training programmes defined, based upon user roles and the training modules.

The training schedule and individual user training programmes should be discussed and agreed with senior user managers. Ideally, formal user training should be scheduled to complete approximately one to two weeks before users are required to use the live system.

System Testing

Test specifications should be defined for different elements of the business process model. These specifications should define a range of business scenarios that could take place. Each scenario should define a number of steps involving user interaction with the system. Specific outcome expectations should be defined for each step, in terms of changes that should occur to system data. A checklist should be defined for confirming that such expectations do occur.

System testing should be undertaken at two stages, within a dedicated "test" environment. The Project Team should undertake the first stage. The purpose of the first stage is to identify most, if not all, of the issues and problems that may exist in the system's operation. Organisational Users should undertake the second stage, after they have received formal training in aspects of the system that they are asked to test.

All tests undertaken against each test specification should be recorded as either a pass or fail. All issues and problems that are identified during testing should be formally logged and investigated. Investigation may confirm that rectification action is required, or it may identify that the tester has misinterpreted the rules of the business process model. Either way, a response to the issue or problem should be formally recorded.

Define a Data Migration Strategy

Data required to support the operation of a system may either already exist in current (legacy) systems or may need to be created from scratch (i.e. the data doesn't currently exist). A strategy will need to be defined that specifies:

• What data is required to be populated into the new system's database (not all possible data needs defining, only that data required by aspects of the system being used by the business process model).
• How data will be populated into the new system's database. Data may be manually entered through application screens or via some kind of automated upload process, such as development of SQL (Standard Query Language) database procedures.
• How existing data, to be automatically uploaded, will be extracted and uploaded from current systems, either directly into the new system's database, or into an intermediary storage location (e.g. another database, spreadsheet, text file, etc).
• What data quality checking and manipulation needs to take place before uploading into the new system's database.
• The sequence of uploading different elements of data.
• Whether different strategies will be required for data associated with different organisational sites.

Develop Data Migration Scripts

The Data Migration Strategy is likely to involve the automated upload of some, if not all, existing data into the new system's database. Such an automation process will involve the development of data migration scripts (SQL procedures), and possibly the creation of an intermediate data storage mechanism, such as a spreadsheet and/or text file.

Even if the data to populated, doesn't currently exist, it may be more efficient to input data into a spreadsheet, rather than directly into application screens, convert the data into a text file, and then create an SQL script to upload it into the new system's database.

Create a Cutover Plan

Implementing a new business process model and its associated systems into live organisational operations might be done as a single exercise, or across a number of phases.

If over a number of phases, then each phase should be established to cover a homogeneous area of business processes and organisational sites. The period between implementing each phase should be a minimum of one to two weeks. This will allow the core project team members to address any teething problems and provide users with adequate support. It is imperative that the core project team members are available, and seen to be available, to users during each implementation phase. They should provide support cover to users at all times during this 1-2 week period, when users are actively using the system. This may mean Project Team members providing 24-hour shift cover.

In the first few weeks of use, users will need some project team members to be readily available, to provide ad-hoc on the job re-training and support. There are also likely to be minor changes required to the new business process design and other minor changes to user interface screens, reports and user access rights. Project team members will have to be involved in a hands-on manner during this time to recognise and assess these change requirements.

Each cutover phase should have a step-by-step cutover plan. This plan will list the sequential steps that need to take place, the time required to undertake each step and the dependency that steps have on each other. The plan should involve steps associated with:

• Suspending current system use.
• Making any necessary final configuration changes to the new system.
• Automatic population of data into the new system's database (e.g. via SQL scripts).
• Undertaking elementary testing of the new system in the live environment.
• Formal Approval/Rejection to continue with the Cutover.
• Provision of user access to the new system environment, or re-establishment of the original, current system, environment for users.

Cutover plans should be tested in a "test" environment. This will establish their resilience and identify the time period required to achieve the cutover (to enable the organisation to plan operational contingency measures whilst the availability of systems support is suspended).