Government Finance Officers Association
ERP Implementation and Technology Governance
April 5-6, 2017Portland, OR
Course Instructors
o Mike MuchaDeputy Executive DirectorDirector, Research and ConsultingGFOA
o Barry McMeekinConsulting Practice ManagerGFOA
o Ryan LawlerManagerGFOA
S2
Introductions
o Name?
o Organization representing?
o Project role?
o ERP project status (Thinking about it? Procurement?
Implementation? Upgrade/optimizing?)
o Vendors?
o Class expectation
S3
ERP Modules
HR/Payroll
Budget
Finance
Applicant Tracking
Forecasting
Fixed AssetsUtility Billing
Property
Budget Prep
Business Intelligence
Contracts
Bids
Grant Management
Projects
Accounts Payable
Accounts Receivable
General Ledger
P‐Cards
Purchasing
Employee Records
Risk Management
Position Control
Time EntryPension Admin
Payroll
Self ServiceCashiering
Work Orders
BenefitsPerformance
Evals
Employee Relations
Training / Learning
Business License
Special Assessments
Property Tax
CRM
Permitting
Performance Management
S4
Business Process Scope
o Accounting Project/grant accounting
• Time entry, HR, payroll, purchasing, AP, contracts
o Procure to pay Purchase requisitions
• Inventory, GL, budget, purchasing, AP
o Asset Management Capital asset acquisition
• Purchasing, AP, projects, capital assets, GL
S5
ERP projects have a rough record
Only 35% of IT projects are successful in terms of being completed on-time or on budget.
-- Project Management Institute
S6
What defines project success?
o On time?
o On budget?
o What about scope? Did we get what we paid for?
o What about the experience? Do we still get along?
S7
It’s probably even worse than this…!
Only 35% of IT projects are successful in terms of being completed on-time or on budget.
-- Project Management Institute
S8
What Does a Failed Project Look Like?
Lack of Communications
Stakeholders Left Out
Poor Executive Support
Re-Create the Old System
Rush to FixThings
Break Other Things
Resources are Strained
Short Cuts Taken
System Scaled Back
System Doesn’t Work
Shadow Systems Created
Project Not Organized
Inadequate Staffing
Unclear Goals
Lack of requirements
QA and Testing Suffer
System Doesn’t Meet Needs
Participation Suffers
No Accountability
S9
Characteristics of Successful ERP Implementations
o Strong Executive Sponsorship
o Commitment of Resources
o Communication
o Focus on Business Process Standardization
Why? Why? Why? Why? Why? Why?
o Manageable Scope
o Ability to Make DecisionsQuickly
S10
Why GFOA provides ERP implementation training?
o Most (if not all) ERP vendors follow one of two approaches to implementation Homework Approach Consulting Approach
o The more prepared you are going in, the better
o Governments continue to make the same errors
o ERP project success is necessary for well run governmentsGFOA best practices Transparency, accountability, efficiency, data-
driven
S11
Course Goals
o Understand ERP projectso Learn how to identify and mitigate riskso Learn how to use ERP projects as an
opportunity to improve process and implement best practices
o Identify how to transition out of the project and maintain a successful system
o Clear up myths and misconceptions about ERP implementation projects
o Don’t make the same mistakes as other governments that failed before
S12
S13
The “Facts” of ERP Implementation
o ERP projects are difficult
o ERP projects are NOT impossible
o Don’t believe everything you hear
o Many organizations fail with ERP even before the project starts (no chance to succeed)
o ERP vendors do NOT share your goals
o Way too much emphasis is put on software
S14
Government Finance Officers Association
Typical Implementation Approach
S16
If it’s too good to be true, it probably is
o No software will work out of the box
o ERP is not the answer for everything
o Faster is not always better
o You get what you pay for Lowest price is not always cheaper
S17
Generic ERP Implementation Approach
Planning / Initiation
Knowledge Transfer
Design
Build
Test
Cutover
Planning / Initiation
Knowledge Transfer
Design
Build
Test
Cutover
S18
Generic “SaaS” Implementation ApproachS19
Planning / Initiation
Knowledge Transfer
Prototype
Build
Test
Cutover
Planning / Initiation
Knowledge Transfer
Prototype
Build
Test
Cutover
Contract signing
Financials
HR/Payroll
9-12 21-28
PlanningDesign
Planning
ConfigurationTesting/Go-live
Phase 1
Phase 2
Typical Implementation Schedule –Sequential Phases
Planning/Design
Configuration Testing/Go-live
S20
Typical Implementation Schedule –Parallel Phases
21
Contract signing
Core Financials
Core HR/Payroll
Extended Functionality
9-12 16-18 24+
Planning
Planning
Configuration
Configuration Testing/Go-live
Testing/Go-live
Phase 1
Phase 2
Phase 3
o Proper readiness
o Project management
o Business process improvement
o Change management
o Quality control Testing
Common ERP Implementation Oversights
Major topic of training
S22
Implementation Model Differenceso Consulting approach Significant vendor involvement in project Typically 1:1 match on the project team Strong project management, business process
improvement Dedicated team
o Homework approach Limited vendor involvement (primarily in training
role) 1 consultant for entire project (or major function) Project management and business process
improvement is responsibility of government Consultants split time between multiple projects
S23
This slide is intentionally left blank.
S24
Government Finance Officers Association
Implementation Readiness
ERP Readiness: The Countdown to Implementation
What is ERP?
Project Planning
Building the Business Case
RFP and Requirements
ProposalAssessment
Demos
ImplementationPlanning
Final Details
18 - Months 12 9 6 3 0
Project Management
S26
What to do before the project starts…
o Defined governance structure
o Staffing plans
o Facility space reserved
o Project readiness Define goals
• What does project success look like?
System inventory
Business process analysis• Department review
SOW complete
S27
Risk: Lack of Project Governanceo Scenario: Small city with experienced
staff. Long history of working together and a project champion (dept. head) who was very enthusiastic about project.
• Formal Governance Structure• Project Charter• Active (Involved) Executive Leadership
Critical Success Factor
They were looking for a very quick implementation and didn’t have time to create formal governance structure. Everyone “knows” roles and will know what to do… until there is thefirst problem.
S28
Importance of Project Governance
o Formal rules, procedures, and structures by which the project will be governed.
o Avoid informal assumptions that people have about how the project will be governedWho can make what decisions?
Who settles disagreements on project issues?
What authority do team members, the project manager, executive steering committee members, and the executive sponsor have?
S29
Example Project Structure
Executive SteeringCommittee
Project Manager
Admin. Support
Project Team
Functional Leads / Business Process Leads
Technical Leads
S30
Leadership Roleso Project sponsor Take interest Communicate business case Understand the pain Listen (and when necessary act)
o Steering committee Provides direction - does not manage Makes major decisions Free up resources Criteria for Members:
• Empowered to make project policy decisions• Champion for the project• “Work well” with the other committee members• Ability to support the project manager and project team
Must demonstrate project is a priority
S31
Project Teamo Project manager Coordinate the project Manage the team Ensure quality
o Project team The “doers” Take responsibility for project tasks Make business process decisions Coordinate subject matter experts
o Subject matter experts Contribute organizational and functional knowledge Attend and participate Become system power users
S32
Staffing Estimates
o Project manager 1.
Should be only responsibility
o Project team .5 to .75 FTE
Must be primary responsibility
o Subject matter expert .1 to .25 FTE
Role does not consume majority of time
S33
Staffing Plans and Resource RosterS34
"Well, they got a little behind so everyone had to hold off on vacations, work a few nights and weekends, and come in over the Christmas holidays, but they survived.“
ERP vendor talking about recent project
S35
Creation of a Project Charter
o Make it as simple as you can
o Developed collaboratively Project team
Steering committee
o Commitments Resource commitments
Time commitments
Goal commitments
Process commitments
o Enforce it - make players accountable.
S36
Facility Needs
o Meeting rooms Rooms for 10-15 peopleMultiple rooms at once
o Computer rooms Rooms with workstation Used for training / system configuration
o Private workstation for consultants Can be shared
o Project home Documentation Project supplies
S37
Project Goals
o Project goals help define the scope
o Establish common expectations
o Document vision and guiding principles / values for the project (Project Charter)
o Create the scorecard by which success will be measured.
Why are we doing this project?
S38
Evaluate the project against goals
o Review project goals to determine success
o Make scorecard part of regular discussions
o Celebrate and recognize end of the project
Score Explanation
No Indicator not met
Improve Indicator not met although conditions are improving
System Capacity for success exists, although condition not achieved
Complete Project has met indicator goal
S39
Congruence of Goals
Gov Vendor
S40
Exercise Time
o Why are you doing this project?
o Why are you doing it now?
o What does the end look like?
o Think for 2 minutes.
S41
Business Process Documentation
o Maps end-to-end process transactions
o Defines Process issues
Efficiency issues
Organization impact
Technology impact
S42
Process Map Example
Purchasing [FINAL] Map Name: PUR_PO_BPSub-Process: Purchase Order – Blanket Purchase Order Map No.: 65C
Ven
dor
Re
ques
ting
Dep
artm
ent
Cen
tral
Pu
rch
asin
g
Various
1. Identify Need2. Approve?
EndNo
CASPS
5. Create/Authorize Master
Blanket3. MasterBlanket?
Yes No
CASPS
4. Create/Authorize BP
Yes
Varies
6. Generate/Distribute BP
Varies
7. Receives BPTo BP Call (Map No.
65D)
From Requisition
(Map No. 64A/B/C)
S43
System Inventory
o Create a system inventory identifying: All purchased systems
All custom developed systems
All excel spreadsheets, access databases and other ad-hoc data storage tools
All paper file locations
Other systems• Reminder systems
• Methods of communication
S44
Data Conversion
o Where is the current information?One system vs. Multiple systems?
o How trusted is the information?
o Is it necessary to convert? Can users go back to the old system?
S45
Develop business process requirementsS46
Importance of Requirements
o Critical component to the contract Defines scope (both software and
implementation)
Holds vendor accountable to “sales "promises
o Benchmark for warranty
o Traceability throughout project Scope
Design
Test
Acceptance
S47
Finalizing the Contract
o Master terms and conditions
o Third-party agreements
o Statement of work
Master Agreement
Services Agreement
License Agreement
Hosting Agreement
Order List
SLA
SOW
3rd Party Agreement
Requirements
Support Agreement SLA
S48
SOW (“are we there yet”) Checklist
o Finalize scope
Software modules
Customizations
Interfaces
Conversionso Finalize project team
o Determine schedule
Determine start dateo Identify tasks (Work breakdown structure (WBS)
o Deliverables identified
(to be completed prior to award)
S49
Statement of Work (SOW) Components
o Deliverable expectation documents (DEDs)
o Acceptance procedureso Confirm scopeo SOW should be very detailed regarding
roles and responsibilities Avoid surprises and “I thought they were
going to do that” Get it in writing
o Avoid “we” and “shared” responsibility
S50
Government Finance Officers Association
Planning / Initiation
Planning / Initiation
Knowledge Transfer
Design
Build
Test
Cutover
Project Initiation
o Project planning Schedule
Project plan
Project management Procedures/expectations
o Project kick-off
o Install of software
S52
Project Decisions
o Communication plan
o Risk management plan How are risks identified and management
o Issues List
o Schedule of project management activities
o Process for project documentation SOW typically defines “what”
Need to define “how”
S53
Communications
o Project awareness is key
o Participation in the project is essential
o Multiple communication methodsWebsite, newsletter, emails, etc.
Don’t assume people read them.
o Presentations Department head meeting
Department meetings
o Communications from multiple people
S54
Content
o What we are doing?
o Why should I care?
o Why are we doing it?
o When will it happen?
o What’s in it for me?
o Where can I go for more info?
o When can I expect next steps?More info, see progress, need to participate,
etc.
S55
Issue Trackingo All project issues and decision points tracked
in one place (Issues are not all bad). Reported by/date Status (i.e. new, open, closed, pending) Module/business process Priority Issue Comments Findings Recommendations Resolution assignment Date tested Date closed
S56
Project Kick Off
(project really kicked off a few weeks before)
o Face to face meeting of project team Vendor and government
o Set expectations / discuss project policies
o Visible to the organization
o Build momentum for upcoming project activities System design
S57
Testing: Initial System Test
o Determine if the system was installed properly
o All components of the system should work
o Users should be able to access all modules, menus, etc.
o Document any technical issues Errors
Poor response
Awkward operation
S58
Government Finance Officers Association
Project Management
A project manager has 3 roles60
Skillset
o Ability to get others involved in the project And know who to get involved when Encourage and motivate Hold folks accountable
o Manage documentation (must be organized)
o Ability to comprehend and speak to both business and technical issues But not necessarily be an expert in either
o Proactiveo Have a true love for details
S61
Primary Taskso Manage day-to-day activities during the implementation.
o Manage client staff
o Manage the vendor
o Monitor project scope And ensure project is delivering value
o Create and enforce project standards
o Assess progress to project plan
o Maintain ongoing communications
o Report to steering committee
S62
Beware of the “Do-It-All” Project ManagerS63
Project Management Toolkit
o Project plan
o Project status reports
o Status meetings
o Outlook calendar appointments
o Project collaboration tool SharePoint
Asana
Basecamp
Others
S64
Risk: Incomplete Project Plan
o Scenario: Contract signed after difficult negotiations. Everyone was eager to begin implementation and couldn’t wait for the full project plan to be developed. Implementation begins.
• Project Plan for Full Project• Detailed Project Plan• Full Transparency on Dependencies
Critical Success Factor
Staff is unsure what comes next. Key scope negotiated in the contract is skipped. Project management procedures never defined and of course neverfollowed.
S65
Project Plan Components
o Identifies implementation methodology Identifies activities or tasks by phase Includes cross-phased activities such as change
management and project administrationo Identifies sequencing Identifies dependencies
o Identifies resourceso Identifies deliverables (and includes
adequate review time from government side)o Tracks progress Is actively managed and updated
S66
Project Plan Expectationso Managed in a project management tool Example: MS Project
o Includes all detailed tasks Conduct meetings Work on deliverable Submit deliverable Review deliverable Finalize deliverable Sign off on deliverable
o Developed at the beginning of the project for all phases (although can be assigned dates later)
o Very difficult to recover from lack of a project plan
S67
Project Management Procedures
o Status meetings
o Steering committee meetings
o Status reports
o Change control
o Quality assurance
o Communication plan
S68
Status Reportso Project statuso Summary of accomplishmentso Status of key milestones deliverableso Project timelineo Issues/Riskso Planned risk mitigation strategyo Progress towards government project goals /
criteria of project successo Summary of change requests
o Consider audience of status report -should be for steering committee
S69
Vendor Management
o Vendors need constant monitoring
o There will be issues
o Need to hold vendor responsible for contract commitments
o Set clear expectations Project team
Project schedule
Deadlines
Project quality (acceptance process)
S70
Managing Change Orders
o Change orders $$ Increase in scope Project delays Customizations
o Change order process can be effective tool at driving project quality and limiting cost increases Enforce SOW Insist on project completion Achieve quality outcomes Prevent unauthorized work – INSIST ON CHANGE
ORDER PRIOR TO WORK
S71
This slide is intentionally left blank.
S72
Government Finance Officers Association
Knowledge Transfer
Planning / Initiation
Knowledge Transfer
Design
Build
Test
Cutover
Knowledge TransferS74
Knowledge Transfer: Government to Vendor
o Policies / procedures Consultants should review any prior
documentation
MOUs, code, laws, etc.
o Project policies
o Government culture
o Expectations / unique considerations
S75
Knowledge Transfer: Vendor to Government
o Project team training “Standard” training on base features in the
system
Training on all modules
Attended by small group
o On-site vs. group training
S76
Goal of project team training is to prepare for business process analysis
o Become knowledge in what is possible
o Challenge the status quo
o Engage in discussion around system features
o Vendor understands more about you
S77
This slide is intentionally left blank.
S78
Government Finance Officers Association
Business Process Analysis
Why business process analysis?o Examine a business process and:
improve quality,
eliminate waste,
minimize cost,
reduce time,
and improve service.
o ERP provides excellent opportunity, but not all improvements are tied to ERP
Most of the big ones are not!
S80
Big Picture Focus – 2 Key Areas
Process System
S81
New Process Focus
o Business process and policy design How will we conduct business?
What rules guide that process?
o Policy changesWhat policies need to change to facilitate
efficiency gains?
o Roles and responsibilitiesWho is responsible for tasks?
Who is accountable for decisions / process quality?
S82
What is a best practice?o GFOA defines best practices as the most
efficient and effective way of accomplishing a task or achieving an outcome, based on repeatable procedures. GFOA best practices identify specific policies and procedures as contributing to high quality government management.
o What by itself is NOT a best practice? Standard system process
• System best practice vs. industry best practice What other governments are doing What consultants recommended for their previous
clients.
S83
Expectationso Review of “as-is” maps and current process
documentation Discuss challenges System inventory
o Identify process improvement opportunitieso Discuss “to-be processo Identify policy changeso Identify implementation issues System issues Change management issues
o Documentation
S84
Business Process Analysis Documentation
o Definition of the process When it applies. What it is used for
o As-is process What are current strengths What are opportunities for improvement
o To-be design To-be considerations Justification
o Change impacto Issues / follow up items
S85
Where does business process analysis fit?
o Homework approach Not designed for in-depth business process
analysis
Should start prior to project
Business process review will compete with project pace if attempted concurrently.
o Consulting approach A primary focus of the knowledge transfer and
system design phase (however, government should have some idea of process improvements prior to start)
S86
Risk: Process change recommendations left to the vendor team
o Scenario: The software vendor manages the entire project on how to best use the software. Meetings focused on how to best transition from software A to software B.Business processes outside of the software are
assumed to be fixed. Software is configured around inefficient/ ineffective processes.
• Business Process Focus• Business Process Focus• Business Process Focus
Critical Success Factor
S87
This slide is intentionally left blank.
S88
Government Finance Officers Association
Change Management
Change Management
o Organized approach to helping the organization (People) transition to something new
o Change is not easyMany people like the way things are
o With ERP projects there is a lot of change
o Change is not easy
o Change is required The environment today is not the same as the
environment yesterday
S90
Change Management and ERP
o Well run ERP projects take an integrated approach to change management
o Ongoing research continuously points to lack of organized approach at change management as cause of project failure
o GFOA research with past clients and ERP projects identify change management as “something we wished we did more of”
S91
Change management in ERP projects has been a challenge
o Change management is not well integrated into the project
o Change management effort is overlooked
o Change management is viewed as “not my responsibility”
o Change management is not well understood
S92
What is change management?
o Change management is an approach to transitioning individuals, teams, and organizations to a desired future state.
o Change management is the management of change and development within a business or similar organization.
o Change management is the application of a structured process and set of tools for leading the people side of change to achieve a desired outcome.
S93
Prosci Change Management Model - ADKAR
o Prosci's ADKAR Model is an individual change management model. It outlines the five building blocks of successful change, whether that change occurs at home, in the community or at work. The name "ADKAR" is an acronym based on the five building blocks: A Awareness of the need for change D Desire to participate and support the change K Knowledge on how to change A Ability to implement required skills and
behaviors R Reinforcement to sustain the change.
S94
Practical Change Management
o Training
o Project communications Awareness
Delivering key messages
Listening to feedback
o Overcoming inevitable resistance Teamwork, collaboration, trust
o Building culture of inclusion
o Leadership and support
S95
Change Management Gimmicks
o Meeting “ice-breaking” exerciseso Project naming contestso Creating logoso Project newsletterso Project websiteso Making t-shirtso Buttons with slogans
* Can be activities to help with change management, but should not be the full effort
S96
Change impacts in projects are real
o Roles change Some that have been established a long time
ago
o Processes change
o Winners and losers will emerge
o In general people like change…Only when it happens to the other guy
o Impacts of the project may not be known
S97
Change management is not a cure for problems in a project
o If you only had more “change management”
o Change management will not make up for poor project management or poor project decisions
o Change management can’t exist by itself
o Change messages must be connected to the project
o Can’t be reactive
S98
Creating the Change Management Plan
o What is changing?
o How will it impact the organization?
o Who are the key stakeholders? How is each involved?
o What does each need to be successful?
o What are the barriers to overcome?
o What can the project (project team) do to help?What strategies will be the most effective
S99
Impacts
o Need to learn new skills
o Need to adapt to new culture
o Need to adapt to new roles
o Need for support from supervisors Change takes time
o Need re-assurance Significant level of uncertainty
o ERP projects create change for the entire organization – change created by limited number of decision makers
S100
Major Components of Change Management
o Communications / training
o Overcoming resistance
o Project culture
o Leadership and support
S101
Overcoming Resistance
o Are you open to change?
o Resistance is normal Can even be good.
o Listen
o Get to root of problems
o Develop specific plans for easing fears
o Some people will never be supportive
S102
Project Culture
o Strive to create a project culture that values participation, teamwork and transparency
o Governance structure will determine roles and decision making ability Be sure to set clear expectations
o Project will not be easy, but we’re in it together Trust is key
o Shared vision. Make sure everyone understands goals and that work will be required to meet goals.
o Teamwork
S103
All Too Common Approach to Leadership in ERP Projects
S104
Executive support and leadership
o #1 Way to kill a project is have Disconnected leadership Project is not a priority
No accountability
“Take care of your own approach”
Resistance grows and organization
will lack any ability to enforce
project standards
S105
Structure of Change Management Function
o Change management lead Coordinate efforts Coordinate communications Not responsible for change management
o Project team Be alert for change issues Communicate changes Understand and own decisions
o Sponsors executive team Ultimately responsible for setting culture Manage employees and provide necessary
support to succeed Respond and deal with negative issues
S106
Barriers and Obstacles
o What change management issues can we expect?What are the project’s goals?
What is required to reach them?
o Major changes?
o How will leadership be involved?
o How will staff respond to the change How will different stakeholders respond?
What will happen if there are issues?
S107
Exercise
o What are your government’s goals for the project?
o What is required to meet those goalsWhat will need to change?
o What obstacles can get in the way?What is needed to support the change?
S108
Government Finance Officers Association
Design
Planning / Initiation
Knowledge Transfer
Design
Build
Test
Cutover
Risk: System Design Decisions Not Documented
o Scenario: Meeting notes are documented and tracked per meeting. All notes are kept separate.
No where is there a comprehensive design document. Inconsistencies exist and there is lack of clear direction on system overall. Piece by piece design. Integrated system doesn’t really appear that integrated
• Take time to prepare full system design documentation
• Clearly document strategy prior to building software
Critical Success Factor
S110
System Design Components
o Chart of accounts
o Department/position structure
o Business process design
o System codes
o System configuration design
o Workflow
o Security
S111
Chart of Account Components
o Fund (General Fund)
o Organizational unit (Police Department)
o Program/activity (Patrol)
o Account classification (Salary) Expense
Revenue
Balance Sheet
o Project (DUI Enforcement Grant)
S112
Use of Common Features –Projects (Project Ledger)
o Most (if not all) modern systems utilize a project ledger for tracking projects
o Project ledger allows for tracking additional detail outside of the chart of accounts Usually allows user defined segments specific
to each project/use
100 - 50 - 0515 - 5100 - 123 - City Hall – Eng Review - Grant
S113
Chart of Account Design Suggestions
o Define segments• Each segment should have a strict definition that is
followed
o Start simple and then build detail Starting with the old chart of accounts without first
cleaning up inconsistencies will repeat the same mistakes that likely plagued the old system
o Don't store unnecessary data in CoA Use projects and work orders Don’t repeat or bring forward ineffective
numbering or accounts
o Finance is not the only stakeholder of the CoA
S114
Design Expectations
o Design proposal for each major business/ moduleModule or unit design Integration designMapping to functional requirements Potential Interfaces Required Reports Scope validation Security/workflow requirements
o Technology design System landscape
S115
Design Process
o Gap analysis Identify goals and requirements (needs)
Review system options• Compare business process needs to available
options (Gap Analysis)
Identify design schemes (e.g., number ranges, etc.)
Document decisions
Test decisions (conference room pilots)
S116
Design Documentation
o Organized by business process
o System process
o Checklist (decisions on system features)
o Considerations for Security
Data conversion
Interface
Enhancements
Reports
o Requirement traceability
S117
System Design Decisions
o Iterative process that should be completed while testing in the system Full visibility in how the decision will impact
system use
o Conference room pilots testing session for full module Test business process
S118
Security Design Issues
o Data securityWhat data are user allowed to see
Depends on design of CoA
o Application securityWhat system features can user access
Depends on application features• How are security features grouped
S119
Conversions
o Validate SOW scope for data conversionWhat data has to be available on the first day
of “Go-Live”
What data can be converted at a later date?
What data is not being converted?
What are the data conversion assumptions?
What are the data conversion tools?
S120
Conversion Strategy
o Very difficult to move large amounts of history due to re-mapping
o Open items are typically converted.
o Clearing accounts should be limited and cleaned as soon as possible
o Legacy applications may be kept “live” for a period of time
o Data warehouse with legacy reports may be used
S121
Workflow Design
o Define workflows based on business rules e.g., purchase > $5K requires city manager
approval
o Assign steps (transactions) to roles o Tip: Limit the number “approvers” Challenge who really needs to approve vs.
who can be notified.
S122
Enhancementso Common principle among all
implementations to utilize standard features in software May require process change (not always easy)
o Common principle among all implementations to utilize standard features in software
o 100% customization free is almost impossible With SaaS products, “customizations” may take
on a different approacho Not all customizations are bad Many applications are developed through
customer requests
S123
Enhancement Process
o Contract enhancements Planned with system design and built into
process Contract modifications
o New gaps Determine if enhancement is necessary Determine impact on project schedule Develop specifications Program modification Thoroughly test Document
S124
Different Approach to Enhancements
Unique Customization Change to Base Application
Developed for 1 customer Feature added for all clients
Add on code to base Change to existing base code
Considerations for upgrade (but not supported)
Supported in upgrade
Worked Into project (performed by project team)
Delivered outside of project
S125
Interface
o Detailed interface specifications Full description
Technical details
Operating procedures
Impact on business process
o Consideration: What is the status of the other system? Vendor status
System status
Upgrade frequency
S126
Reports
o Two theories on reporting 1) Getting information out of the system is
critical so reporting must be priority during the project
2) You don’t know how the system works, so don’t customize any reports until you are familiar with standard features
o Management reporting vs. external reporting
S127
Reports
o Identify specifications for in-scope reports Consider need to communicate with external
stakeholders
Avoid defining reports for internal users• Other methods of accessing data
Create a reporting list• Prioritize reports
• Determine how to allocate reporting requirements to internal reporting resources
Get trained on reporting tools
S128
Testing: Business Process Test
o Test proposed business process flows in the system
o Testing objectives: Match roles and responsibilities to system
transactions
Determine if system will support business process
Determine if roles are appropriate for system transaction
S129
Requirements Traceability
o Original requirements should be tracked throughout project
o Original requirements tracked to: Business Process Improvements
Design
Build Decisions
Testing
Acceptance
o Vendors may not want to do this
S130
Government Finance Officers Association
Build
Planning / Initiation
Knowledge Transfer
Design
Build
Test
Cutover
Risk: No Issue or Requirements Tracking
o Scenario: Requirements were developed during the RFP process, but now that the project team is actually on the software, some requirements don’t apply. Vendor suggests that it’s a waste of time to look at the requirements…… Key features
are missed. Go-live is approach and the scope is not close to what was promised. Oops.
• Traceability• Document designs back to contract. • Test against the contract
Critical Success Factor
S132
Standard Configuration
o Project team members will utilize system set-up tables to set configuration in the system. Based on system design
o Use of pre-configured templates and accelerators may be an option Faster set up assuming all pre-selections “fit”
Risk of missing out on key system decision process
S133
System build is an iterative process
Build
Test
Build More
Test More
Test Again
S134
Who completes the build?
o It depends….
o Advantages to vendor build:Quicker
Know what they are doing
Many one time set-up options
Free up government resources
o Governments: Better ownership of system
Less cost
S135
Data Conversion
o Typical Process Identification
Mapping
Documentation
Legacy system data extraction / cleaning
Crosswalk
Load data
Verification and testing
Data conversion is often a repeated process throughout the implementation
S136
Testing: Unit Testing
o Testing a single transaction or a series of transactions within a module, ensuring it functions as intended. Develop detailed scripts with complex
transactions
What can break the system going forward?
o Purpose: verify that every transaction can achieve the desired results relative to specifications and design documents. Focus is on intra-module functionality, rather than inter-module integration.
S137
Testing: Regression Testing
o After new features are added or modifications applied, testing previously tested functions for new issues
S138
Testing: Integration Testingo Testing the integrated ERP system to ensure that data
is transferred across various modules in accordance with the design. Based business scenarios such as: Create Purchase Requisition -> Budget check-> Process
Purchase Order -> Enter Goods Receipt -> Record Asset -> Park Invoice > Post Invoice > Pay Vendor-> Reports
Hire Employee -> Select Benefits -> Develop Positioning -> Record Time -> Run Payroll -> Post pay to GL-> Post to Project-> Promote Employee -> Post Pay Change -> Retire Employee
o Purpose: ensure different modules work together seamlessly by testing end-to-end processes
S139
Requirements Traceability
o Original requirements should be tracked throughout project
o Original requirements tracked to: Business Process Improvements
Design
Build becisions
Testing
Acceptance
o Vendors may not want to do this
S140
Issue Escalation
o Pre-determined path for resolving issues
o Don’t be afraid to use escalation process
o Document issues / Document resolution
S141
o Blank slideS142
Government Finance Officers Association
Test
Planning / Initiation
Knowledge Transfer
Design
Build
Test
Cutover
Types of Testing
o System testing
o Business process test (Conference Room Pilot)
o Unit testing
o Regression testing
o Integration testing
o Parallel testing
o User acceptance testing
S144
Risk: No Formal Testing
o Scenario: The planned go-live date is fast approaching. Everyone in the organization knows that the system is to go live on July 1. Implementation is falling behind. As long as we are done by July 1, all is good.
….Except that leaves no time for testing!!
• Project plan clearly defines testing periods• Develop formal scripts with complex
scenarios.• Don’t Cheat!
Critical Success Factor
S145
Testing: Parallel Testingo Processing current input data and files in
both the old and new or modified system simultaneously, and then comparing the results. If the output from both systems is identical, it indicates the new, modified system is functioning properly. Assumes old system was working correctly
o Purpose: verify the new system can produce the same results as the old system; typically used in payroll/utility billing. Not used in finance or other areas where output
is significantly different (example: CoA change)
S146
Testing: User Acceptance Testing (UAT)
o Test procedures that lead to formal 'acceptance' of new systems. UAT is a critical phase of any 'systems' project and requires significant participation by the 'End Users'.
o Purpose: obtain end users acceptance of the new system.
o Testing criteria should be functional requirements
o Should be performed 30 days prior to go-live
S147
Essential Components of Testingo Develop a testing strategy
o Identify test scenarios (what to test)
o Develop test scripts
o Review test scripts
o Collect data to support the identified test scenarios
o Perform testing Make required modifications to documentation
o Repeat if necessary
S148
Testing Strategy
o A good testing strategy clearly identifies: Objectives
Methodology
Resources (e.g, testers, system, facilities)
Roles and Responsibilities
Assumptions
Timelines
Testing processes
Method of documenting and following up on issues
Sign-off procedure
S149
Development of test scripts should be a formal process
o Test scripts should be a deliverable Initially provided by vendor and then modified
by government
o Test scripts detail the steps involved in each test scenario, stating the expected results for each of those steps
o Test scripts guide the testing process.
o Test scripts should refer to the user procedure detail wherever possible
S150
Test scrips should include scenarios
o Scenarios should adequately test all applicable business processes
o Scenarios should be process driven, incorporating at least one, but more often many, business functions
o Process experts and functional users should identify the test scenarios.
o Scenarios are coordinated by the Test Facilitator to ensure cross functional testing
S151
Exercise: Test Script Development
o Review standard test scripts
o Develop a detailed scenario that includes: Specific data to enter
Complex scenario
Method of determining if test worked
S152
Testing Lessons Learned
o Schedule testing into the project plan Don’t cheat timelines
o Assign project team members Include subject matter experts
o Expect issues
o Try to test complex issues / processesWhat if we were to do X
o Document. Document. Document
S153
Requirements Traceability
o Original requirements should be tracked throughout project
o Original requirements tracked to: Business process improvements
Design
Build decisions
Testing
Acceptance
o Vendors may not want to do this
S154
Government Finance Officers Association
Cutover
Planning / Initiation
Knowledge Transfer
Design
Build
Test
Cutover
Cutover includes all necessary steps after system “works” to go live
o End-use training
o Go-live plan
o Contingency planning
o Set-up of support structure
S156
Risk: Inadequate Training
o Scenario: Budgets are due, end of year is coming, open enrollment is starting, departments are short staffed, so there is no time to attend full day training sessions. We can learn later when it works for “us.” Everyone must make time (or have it made for them). Training must be a priority. There are others depending on differentroles. • Formal Training Plan
• Training Accountability (for participation and learning)
Critical Success Factor
S157
Creating a Training Plan
o Should be done as part of system designMatch training needs to business
process/system design decisions
o Process based trainingOrganize training based on business process
or organizational role / function
Consider training on process/change areas only (no system training)
Not modules
S158
Training MatrixS159
Training Roles
o Training coordinator Schedules training
Follows up with those missing training
Makes sure training is effective
o Trainers Core users / subject matter experts
Be cautious when using project team members
S160
Training Facility Needs
o Training room Classroom style training room with computers
at each workstation (10-15)
At least 2 training rooms
o Training lab Dedicated area for training follow up
Practice on the system
1 on 1 assistance
S161
Development of Training Materials
o System documentation can be start of effective training materials
o Prepare “Quick Guides” Short 3-5 page summaries
FAQ listings
o ToolsMS Word
Web videos• Screenflow
S162
“Quick Start Guides”S163
Role of Vendor in End User Training
o Vendor led end user training Vendor resources teach training
Usually different resource than implementation lead
Advantages: • Well developed examples
• System expertise
• Experienced trainer
Drawbacks• Little government knowledge
• Very generic training
S164
Role of Vendor in End User Training
o Train the trainerGovernment users provide training
Vendor assists with setting up training
Overall, vendor not really involved
o Hybrid training approach Use combination of government and vendor
trainers
Government resources available to answer questions and provide project perspective
S165
Training Lessons Learned
o Don’t underestimate training effort
o Training won’t be complete when you go live
o Need for training materials
o Need for government specific training
o Training often occurs at critical point for implementation (resource constraints)
S166
Following Up on Training
o Open labs / refresher training
o Training surveys Require attendees to provide feedback on
training
o Training certification Require attendees to demonstrate learning /
competency
S167
Are you ready to go live?
o No one remembers when you went live
o Forced go-lives are difficult to recover Change management issues
User confidence
Risk to future phases
o Create a contingency planWhat if we don’t go live on X date
• Additional conversions
• Maintenance for legacy system
S168
Cutover Plan
o A cutover plan is the final road map for system acceptance and execution. Development of it is a collaborative process that requires involvement of all project teams (functional, development, testers, IT infrastructure, trainers, and project managers).
o Includes both system and process steps For example: When to process last PO
o Should be clearly communicated to the organization
S169
Going Live
o GFOA Observation: Most “Go-Lives”, and the short period after, are “uneventful” Final data conversions
Initial hesitation to use system
Plan execution
o Expect high call volume shortly after when transactions are required (e.g., requisitions)
o Establish cheat sheets or job aids
o Staff helpdesk with technical and functional resources
o Establish your escalation process
S170
Post Go-Live Support
o First 30-60 days Ensure all users have completed required (core) training
Provide for one-on-one for those who are having difficulty
o Set-up a lab environment where users can perform real work with assistance available
o Determine the appropriate level of vendor assistance Depends on level of involvement with implementation
S171
Risk: Disconnect Transitioning from Project to Normal Life
o Scenario: Life with the new system will be so different that we have no idea what to prepare for. We can figure that out after we go live.
This creates a gigantic change management nightmare. Project team members are uncertain about future roles and the organization doesn’t have a plan for transitioning.
• Post Project Strategy• Regular Communications About Post
Project Plans
Critical Success Factor
S172
Transition to Support
o What to do with the project team?
o How to support an ERP system? System not owned by one department
S173
Continued User Support
o Create a training evaluation plan and assess training efforts based on the plan
o Continue training efforts and provide refresher as needed
o Establish internal user groups
o Create point person to research new features and continually evaluate improvement possibilities
S174
Issue Tracking
o Establish a method for tracking and resolving issues—maintain a central repository
o Issues should: Be tracked by module/functional area
Be prioritized—does the issue stop business from happening
All issues should be resolved
S175
Requirements Traceability
o Original requirements should be tracked throughout project
o Original requirements tracked to: Business process improvements
Design
Build decisions
Testing
Acceptance
o Vendors may not want to do this
S176
Government Finance Officers Association
Risk Assessment Exercise
o See handoutS178
Government Finance Officers Association
Post Project Transition
Post Project Transition
o Project scorecard
o Post project Assessment
o ROI (holy grail of ERP)
o Third party reviews
o Ongoing support
S180
Evaluate Project Against Goals
o Review project goals to determine success
o Make scorecard part of regular discussions
o Celebrate and recognize end of the project
Score Explanation
No Indicator not met
Improve Indicator not met although conditions are improving
System Capacity for success exists, although condition not achieved
Complete Project has met indicator goal
S181
Tracking ROI
o Return on Investment for ERP is almost impossible to calculate Easy to calculate costs
Impossible to quantify benefits• If project was done right, new capabilities exist that
we not possible before– How to quantify better internal controls?
S182
Quantifying Efficiency Savings
o Time entry process prior to ERP 10 hours x 10 people x average salary of
$50/hour = 130,000 per year
o New Time Entry Process 3 hours x 5 people x average salary of $50 /
hour = $19,500 per year
Savings of $111,500 -
PROBLEM - Where in the budget did we save $111,500?
S183
Need to recognize 2 different types of savings
Budget savings Saving $ Reductions in expenses
Reductions in personnel
Efficiency savings More efficient operations
New features that reduce need for other business process
S184
Third Party Assessments
o Specific to one functional area
o Don’t audit the project
o Going forward, how can we get more out of the system Process tweaks
Configuration changes
Expansion
Upgrade to new features
Improved support
S185
Keeping the System Going
o Not getting stale Evaluate upgrades
Continue to invest• Technology
• People
Take responsibility for system
o ERP governance Formal structure for evaluating changes
S186
Shift focus to system support
o IT as business analysto Need independence from departmental
prioritieso Configuration changes and process tweaks
over programming Focus on business process improvement Can’t program solutions Don’t really want to
o Module integration over application interfaces and shadow system proliferation How to continue to leverage the system Important role of governance to promote the
system
S187
Key Post-Implementation Governance Issues
o Use of ERP steering committee to arbitrate and set priorities Reference point is Government’s strategic
business plan and goals
Business cases drive ERP project selection/priority
o Political dynamic of enterprise solution relative to departmental interests
o Need to recognize that ERP will not solve every need but collective use is better for organization as a whole
S188
ERP System GovernanceS189
Government Finance Officers Association
