1. 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
2. Professional Timeline
• Strong personal
experience with
ERP rollouts,
analysis, audits
and unification
since 2002
40%
60%
• Management
of IT projects
and teams
since 1996
IBM IBMArmy 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
3. 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
5. 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. 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. 7
ACTIVITIES
Board Sponsors
Financial
Reporting
Expert
Demand
Manager
JF Burguet
IT Insfrastructure Project
Manager
Users
Acceptance
Coordinator
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
Source: JF Burguet’s archives + phone calls to Jane Ryan and Ami Kaur on July 4th 2012
PHASE 2 : ERP Solutions Strategy Development
RACI Chart – Roles & Responsibilities
8. 8
ACTIVITIES
Board Sponsors
Financial
Reporting
Expert
Demand
Manager
JF Burguet
IT Insfrastructure Project
Manager
Users
Acceptance
Coordinator
Implementation Area
Analysis
Consulted
Implementation Plan Consulted
Tactical Plan Consulted
Communication Plan Consulted
Source: JF Burguet’s archives + phone calls to Jane Ryan and Ami Kaur on July 4th 2012
PHASE 3 : Solutions Implementation Plan
RACI Chart – Roles & Responsibilities
9. 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. 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)
11. 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. 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 JunApril
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. 13
Configuration Update
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.
15. 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. 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.
18. 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
19. 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
20. Roles & Responsabilities
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. 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
25. 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
