jf burguet - erp experiences

Jean-Francois Burguet

• IT Project Manager since 1996

• IT People Manager since 2002

• 9 relevant ERP experiences, including :

• 1 full Pan-European rollout (Maconomy) • 2 national rollouts (Navision + Whitenet) • 1 due diligence analysis (Whitenet) • 2 functional analysis (Peoplesoft + SAP) • 2 Pan-European infrastructure audits (SAP) • 1 functional unification (Pluservice) on-going

• Strong believer in team work

1

Professional Timeline

• Strong personal experience with ERP rollouts, analysis, audits and unification since 2002

40% 60%

• Managementof IT projects and teams since 1996

IBM IBM Army IKEA EDELMAN RANDSTAD VODAFONE

ARRIVA

Management of IT Projects / Teams

Pan European rollout (2002-2004)

Italian rollout

Analysis Audit

Italian rollout

Unification (on-going)

Analysis & Local support

Due diligence

2

Audit

EXAMPLE

MACONOMY Pan-European Rollout (2002-2004)

The Company: Edelman Public Relations Worldwide

The Context: 14 European offices, 780 employees (2001)

The Rationale for Change: standardize the financial processes, improve reporting of key data, replace multiple outdated solutions.

The Objectives: “Support the business processes with minimum of customisation, offering financial tools to manage operations on-line and in real-time.”

The contenders: Peoplesoft (US Headquarter’s suggestion) + Sharpowl

The Implementation Team: G. Schwab (European Finance Director) Executive Sponsor M. Golby (CIO) Executive Co-Sponsor S. Pleesz (Chief Finance Controller) Financial Reporting Expert J. Ryan (CFO Edelman London) Demand Manager A.Kaur (Accountant) User Acceptance Coordinator E. Long (Freelance) Lead Project Manager JF Burguet (European IT Director) IT Infrastructure

3

4

The ERP Implemented

5

ERP Selection : the rational in favour of Maconomy

• The application interface is more user friendly. • Easier workflow processes for approving Client Invoices, Purchase Orders, Expenses,… • The drill down facility to a source document (original entered document) is better. • Maconomy offers one completely integrated web solution. • The Resource Planning module is available immediately. • Change Management and culture changes will be easier with it because of it is more PR oriented. • Maconomy is already up and running successfully in other PR agencies.

Source: JF Burguet’s archives + phone calls to Jane Ryan and Ami Kaur (July 2012)

Comparison of Software Costs (London office only) Full Users 10 @ £1850 (accounts staff) £18,500 Time & Expense 110 @ £110 £12,100 Web Portal (one –off) £20,500 Workflow Spider (one –off) £ 5,000 API Toolset (one –off) £13,350 Annual maintenance charge = 20% X £85,600 = £17,120 Total £159,450

Qualitative

Quantitative

6

ACTIVITIES

Board

Sponsors

Financial Reporting

Expert

Demand Manager

JF Burguet

IT Insfrastructure

Project Manager

Users

Acceptance Coordinator

Executive Management Initial Project Vision

Not involved

Review Business Direction & Needs

Informed

Conduct Internal Assessment

Consulted

Conduct External Assessment

Informed

Define Key Issues, Opportunities & Needs

Consulted

Establish ERP Solutions Strategic Direction

Consulted

PHASE 1 : ERP Solutions Strategic Direction

Source: JF Burguet’s archives + phone calls to Jane Ryan and Ami Kaur on July 4th 2012

RACI Chart – Roles & Responsibilities

7

ACTIVITIES

Board

Sponsors

Financial Reporting

Expert

Demand Manager

JF Burguet

IT Insfrastructure

Project Manager

Users


Business Development Plan

Not involved

Applications Architecture Consulted

ICT Architecture Responsible

Policies, Standards & Guidelines

Consulted

Organization, Management & Planning Frameworks

Informed

Support Infrastructure Consulted

ERP Solutions Strategic Plan

Consulted


PHASE 2 : ERP Solutions Strategy Development


8

ACTIVITIES

Board

Sponsors

Financial Reporting

Expert

Demand Manager

JF Burguet

IT Insfrastructure

Project Manager

Users


Implementation Area Analysis

Consulted

Implementation Plan Consulted

Tactical Plan Consulted

Communication Plan Consulted


PHASE 3 : Solutions Implementation Plan


9

JFB’s main learned lessons • Foster passion: select a dedicated team in charge of the ERP implementation. This

should be a full time job for most team members. Ideal if they do not report hierarchically to each other. Must work from the same location > 80% of the time.

• Customisation: limit as much as possible new code or functions being customized

beyond their normal configuration parameters. It will make testing simpler and future application upgrade easier / cheaper.

• Logs & transparency: all issues should be written down into a central document

reviewable by all stakeholders.

• Plan to do a lot of testing : leave enough time to confirm the behaviour of all the

functions before the application is released into production. Involve users a lot.

• Load and performance simulation: don’t trust the vendors nor the formulas. Visit other

clients with similar size implementations and inquire about their infrastructures. Talk to their users. Use load and performance simulators (ie IBM’s Rational Performance Tester).

• Disaster Recovery : build the infrastructure to guarantee the disaster recovery time

objectives (RTO) defined by the business. Define SLA accordingly.

10

• User profiles & access rights: user profiles should not be

duplicated. Give minimum access to everyone and release additional rights progressively. Log changes.

• Reporting: Business reporting should be defined early

and be ready for the first testing sessions. Rolling out without all the business reports ready maintains the dependency of legacy systems and increases workload.

• No delegation: people close from the business should

be involved from the start. This is not just “a Finance or IT” project, it is a company project.

• Data: legacy systems data import into the master data

databases should be “cleaned-up” and categorized with the help of the business. Data clean-up and categorization after roll-out is a nightmare.

• Communication: define the communication flow (who

talks to whom when). Be proactive. Meet future users frequently.

Include people close to

the business

Learned lessons (con’t)

ERP Implementation Success Factors

IT Infrastructure

Management Commitment

Change & Risk Management

11

Data flows &

Business Process Mapping

Measurable objectives

Excellent communication

Quick Wins

Managed expectations

United project team

Flexible planning

Experienced professionals

Aligned Project Goals & Business Goals

12

May Jun Jul Aug Sep Oct

Detailed design

Go-live

preparation,

execution and

support

Training

Build

Test

April

2002

Detailed design

Build

Test

Training

Support

Nov

Prototype design

and build (CRP)

Jan

Analysis

Feb Mars

Detailed design

Test

Supp

Dec

Build

Release 1 (GL, AM, AP, PO)

Release 2 (AR, BI)

May Jun April Jul

2003

Project Management / Technical Coordination

Implementation Plan - GANTT

Deploy &

roll-out

Training

Deploy &

roll-out

Detailed design

Go-live

preparation,

execution and

support

Training

Build

Test

13

Configuration Update 13

ERP have literally thousands of parameters to be configured. Per function, keep track of the progress and set priorities based on the logical relationships of these functions and on the user testing availability.

14

Budget Update

15

Severity

Probability

Low

Low High

High

•Business interruption

•Missing functionality

in delivered solution

Decisions made

untimely

Cost Control/

Schedule

Slippage (Lite

Deployment)

Resource

Continuity &

Retention

User Buy-In/Training

Allocation of

Business

Resources

Post Production Support

Bank Holiday

MP PM not experienced with

ERP implementation

Diverse Team

Purchasing

AM roll out starting later

Chart of account merge

Risk Update

16

Risk Update Risk Area Description Mitigation Plan

6 Business

Interruption

With implementation of a new business operational

system, there is always risk of interruption in normal

business functions.

Testing will be carefully planned and managed

to ensure system integrity, and a detailed

conversion/deployment plan will be prepared

(including system fall back) with checklists for

implementation.

7 Allocation of

Business

Resources

The project plan has business resources from each

area (GL, AP, PO and AM). Active involvement of

these resources is critical to the success of the

project. If these resources are unable to participate

on the project at the planned level, the project

schedule will be at risk.

Project Team staffing variances monitored on a

weekly basis to ensure that scheduled resources

are working on project assignments at expected

levels.

To ensure adequate ongoing participation of

Finance a bi-weekly one hour slot has been

booked with Finance Director.

8 User Buy-in Risk of variable commitment across the organization

to this project, and the Maconomy based financials

solution, can lead to resistance to the solution and

make it very difficult to execute the project according

to the plan.

Suggestions to mitigate this risk:

Senior management communication to the

organization on the critical importance of this

project to the organization.

Communications to the business units on the

status of the project, and expectations for them

on go-live implications/impacts.

Backup Slides

17

SAP Teamwork P1 INC P2 & P3 INC Design &

Configuration

EOL EOS

Capacity Performance

Failover

&

Testing

Patching

&

releases

Road

map Maintenance Monitoring

Application Workload &

Vendor

proactivity

5 P1 application

failure

Maintenance & applic. failure

Very complex Not enough

testing

Asynch with

business cycle

High customization

No automatic warnings

Scheduling

Backup

Single snapshot used only for

backup purposes

VTA (October

2012)

Need to reinforce the backup

infrastructure unclear

Not visible enough to

support teams

Restore

Over 35 hours due to the high volume of data to transfer from

tape to disk

unclear

Database 2 P1 on hold unclear

Storage Lacking

expert

knowledge

ICMS Hitachi Almost full and not expandable

unclear Warnings

only above thresholds

Servers Windows

ICMS (Sybase)

Not visible enough to

support teams

Servers Unix

Offshore

availability

ICMS dependency

matrix

OS HW (2015)

Prod environment

different from test

environment

OS

Middleware Move to Citrix in

Sept

Network 4 P1

(outage) Switches

SAP (Mission Critical) - Detailed RAG Audit 2012

(**) based on the last 12 months

Tarantella still in place

Ver 2.2

18 Source: JF Burguet’s own work for Vodafone

RACI Chart A RACI Chart is a table used to describe the roles and responsibilities of various teams or people in delivering a project. It is especially useful in clarifying roles and accountabilities in cross functional/cross departmental projects and initiatives.

The RACI diagram splits project activities and tasks down to four participatory responsibility types that are then assigned to different roles in the project. These responsibility types make up the acronym RACI which stands for :

• Responsible - Owns the process. Those who do work to achieve the task. There can be multiple resources responsible.

• Accountable - To whom 'R' is 'Accountable' , who must sign off / (Approve) work before it is effective. The resource ultimately answerable for the correct and thorough completion of the task. There must only be one 'A' specified for each task.

• Consulted - Has information or capability that is necessary to complete the work. Those whose opinions are sought with two-way communication.

• Informed - Must be notified of results, but need not be consulted. Those who are kept up-to-date on progress, with one-way communication.

19

Roles & Responsabilities

20

20

Project Team Structure Key Roles

ROLES DESCRIPTION

Executive Sponsor The Executive Sponsor is an executive or business leader that is responsible for the overall

success of the project and resolves issues regarding project scope, schedule, resource conflict,

approval and funding, etc.

Steering Committee Approve and Oversee the following:

Business Strategy

• Ensures Project Alignment to Manpower’s Vision and Objectives

• Approves Local Country Business Case

• Holds Local Project Managers Accountable

Accountability

• Reviews Project Progress and Performance on regular basis (I.e., monthly)

• Reviews Program Planning and Performance

• Approves Scope, Schedule or Budget Changes

Organizational Readiness

• Supports Communication Initiatives

Project Manager The Project Manager has ownership and accountability of the overall delivery of the solution. This

person assists in the creation of deliverables, budget, schedule, risk mitigation, change

management, etc. This individual manages and reports progress, and escalates issues to

appropriate management and project sponsors. This individual is accountable to the executive

sponsor for the successful execution of the project.

… …

21

ACTIVITY DESCRIPTION DELIVERABLE

Applications Architecture

(AS-IS and TO-BE)

Document the frontline and back-office applications and business processes required to support the enterprise and their interactions and interfaces with other applications.

Data flow mapping Supported functions Users roles and access rights Report lists and descriptions

ICT Architecture

(AS-IS and TO-BE)

Develop an architectural landscape defining the high level functions (layers), components and interfaces within the ERP Solutions.

Telecom Networking Architecture IT Servers Architecture ICT Applications Design IT Suppliers & Contracts IT Risk Analysis IT Migration Plan

IT Specific Activities

Source: Edward G. Bottrell

22

The ERP Selection Process

Source: Bahar Kenaroglu (2004)

Technical

Factors

Functional

Factors

Project

Factors

Cultural

Factors

Resource &

Effort

Awareness

ERP Implementation Readiness Profile

Source: Collegiate Project Services

24

Data flow mapping (AS-IS)

Source: ISACA

25

Data flow mapping (AS-IS)

Each activity in the process should be examined for the following process issues: • Handoffs from one person to the next • Bottlenecks • Rework • Role ambiguity • Data duplication • Cycle time • Flow time • Non value-added steps

Each decision in the process should be examined to determine: • Authority ambiguity • Decision necessity • Decisions time (too early / too late)

Source: Marianne Bradford

jf burguet - erp experiences

Documents