INFO245 Implementation Strategies

1
INFO245 Implementation Strategies
2
Introduction

• This section will analyse three basic questions
  regarding implementation strategy
• What rationales do organizations use when they
  decide to implement ERP?
• Should business processes or ERP software be
  changed?
• How should ERP functionality be rolled out?

3
Business Rationales for ERP

• Business Rationale One basic question why are
  we doing this?
• Categories
• Technology Replace outdated hardware and
  software with more scalable, flexible and
  maintainable technology
• Business Process Replace inefficient legacy
  processes with new processes that are grounded in
  best practices
• Strategic Implement a technology platform that
  gives the organization abilities it did not have
  before
• Competitive Provide the organization a better
  ability to compete in their industry

4
Should we change process or software?

• Forrester Research conducted a survey and found
  the following of firms following policies
• choose application that fit their business and
  customise a bit - 37
• customise applications to fit their business - 5
• reengineer business to fit application - 41
• no policy - 17

5

• Designing ERP Systems
• Basic strategies Change business process or ERP
  software Possible scenarios
• Small change to each
• Big process change with small software change
• Small process change with big software change
• Big change to each

6

• Small process and software changes
• AKA Small-r Reengineering
• Used when current processes closely match chosen
  software
• Advantages
• faster, cheaper, more predictable implementation
• Disadvantage
• may reduce benefit resulting from process change

What rationale(s) would be used to justify this
small-r reengineering?
7
Small process and software changes

• Generally target generic processes (i.e., A/P
  or G/L)
• Largely favored by
• small-medium size firms and ERP software vendors
• Firms that are implementing generic applications
  such as Accounting
• Firms where IT not viewed as strategic

8
Large process and small software changes

• Big business process change and small software
  change
• Advantages
• Easy upgrades, lower development and maintenance
  costs, increase opportunity for improvement or
  standardization from software best-practices
• Disadvantages
• Homogenization of unique, value-creating process
• Risk associated with large scale change to
  process/job descriptions.
• Difficult to implement in decentralized firms

9
Large process and small software change

• Largely favored by
• Firms looking for software to facilitate business
  change
• firms that think modifying software is more
  difficult and more costly than changing processes
  and peoples work routines
• ERP Vendors

10
Large software and small process change

• Change the software to match existing processes
  or to implement a best practice not available in
  ERP packages.
• Advantages
• Avoid losing competitive advantage of a
  industry-best practice

11
Large software and small process change

• Disadvantages
• Software costs and maintenance effort
• Requirement to retain large IT staff with very
  specific expertise
• Largely favored by
• Large firms with unique, industry leading
  business practices that provide a competitive
  advantage.

12
Large process and software change

• Aka Big R Reengineering
• Requires extensive resources and time
• Boeing and BAAN
• Advantages
• Process/software alignment
• First mover benefits
• ERP partner sometimes willing to share cost and
  risk (why?)
• Disadvantages
• Expense
• Time
• Risk
• Likely implementers
• Large firms industry leaders

13
Implementation Failure and Success Factors
BIG-R
Extensive
Potential project failure because of process
changes
Potential project failure because of process
changes and IT changes to software
Extent of change to organisational processes
Small-r
Minimal
Potential project failure because of IT changes
to software
highest probability of successful implementation
Minimal
Extensive
Extent of Software Change
14
How can we change software?

• Assume traditional ERP, not open source
• Assume not Big R reengineering
• Option 1 customize core software code
• Seldom a good idea
• Option 2 write your own custom code (or hire a
  consultant) outside of the ERP system use
  standard interfaces to link to ERP system
• Expensive and time consuming
• Option 3 Purchase add-ons from third party
  vendors.

15

• Third Party Add-Ons
• Add-Ons are software packages that
• are written by third-party developers
• are written to work with specific ERP systems
• enable functionality not in the ERP system
• are encouraged and certified by the ERP vendor
• Provided by ERP Software Partners
• These partners provide complete, technically
  verified turnkey software solutions that extend
  and add value to SAP solutions. In addition,
  third-party software vendors can develop
  applications based on SAP's standard,
  release-stable interfaces. www.sap.com
• Example IBM Datastage provides the ability to
  input data into SAP R/3 database during data
  conversion.

16
Which Approach?

• Depends on the organization
• Capabilities (absorb change, implement large
  systems)
• Constraints (size, resources)
• Tolerance for risk

17
ERP Modules
ERP Systems have numerous Modules that impact
many business areas within an organization.
18
Implementation Approaches

• Big Bang
• All modules implemented in all business units in
  all geographies at the same time
• Issues?
• Phased
• Modules implemented one at a time or in small,
  logical groups
• Issues?
• Wave
• Hybrid approach that can take many forms
• Implement all modules in a given geography
• Move on to next geography, etc.

19
Big Bang

• All modules, all locations, all users at the same
  time
• Three steps
• All software configuration options chosen and
  implemented
• Thoroughly test individual modules and interfaces
  between modules and other systems
• Typically a many month process
• Testing feedback allows tuning application
• Shut down legacy system(s) and start up
  production ERP system
• Done in very short time (few days)
• Legacy system is gone.no return to legacy system
  possible

20
Big Bang - Advantages

• No need for temporary interfaces (to legacy
  systems)
• Limited need to maintain legacy systems
• Mothball them
• Lower risks (maybe)
• Resources more fully engaged
• More likely key resources not lost (turnover)
  before implementation complete
• Functionality Linkage
• All ERP functions will be available (unlike
  phased approach) faster time to benefit
• No going back
• Enforce process change

21
Big Bang Advantages (cont)

• Shorter implementation time
• ERP implementations sometimes fail due
  implementation time
• Changing requirements (as business changes)
• Personnel turnover
• Political maneuvering
• Although resource requirements roughly equal to
  phased (person years), overall timeframe can be
  shorter as
• all modules implemented at one time
• No need to design and build temporary interfaces
  to legacy systems
• Example if implement financials in phased
  approach?
• Cost can be lower under certain conditions

22
Big Bang - Disadvantages

• Huge resource requirements
• Bigger team required (although for shorter time)
• Project management more difficult and complex
  with larger team
• Lack of focus on individual modules
• All modules implemented, cant give each module a
  lot of attention
• Big Bang Big (Potential) Failure
• A failure in just one module can mean overall
  failure
• Why?
• Kind of failure attracts media attention, affects
  stock price, etc.
• No way to go back to legacy system
• Once turned off, legacy systems cant be
  reactivated.
• No way to demonstrate progress until entire
  system implemented

23
Phased Approach

• Modules implemented one at time or in small
  groups
• Sometimes, only selected locations implement the
  module
• Modules are implemented sequentially
• Requires significant attention to existing
  systems
• Why

24
Phased Approach - Advantages

• Resource requirements less
• Smaller project team - fewer resources required a
  given point in time (although needed longer)
• Focus on module functionality
• Lower Risk
• No chance of enterprise-wide failure
• Legacy System Fallback
• Legacy system can run in parallel mode
• Knowledge Transfer
• Project team has time to learn can apply
  knowledge (of package) in subsequent phases
• Faster time to working system
• Although not complete, project team can
  demonstrate business value faster.

25
Phased Approach - Disadvantages

• Temporary interfaces to legacy systems
• Cost
• Risk
• Ongoing legacy system maintenance
• Cant shut off legacy systems until late in
  implementation
• Turnover
• Longer overall timeline greater likelihood of
  losing key resources before end of project
• Legacy system fallback why an issue?
• Longer project

26
Organizational Characteristics Influence

• Size and complexity
• Determined by
• number, characteristics of customer base,
• product lines / product complexity
• Process complexity
• Small, simple organizations Big Bang
• Large, complex organizations Phased

27
Organizational Characteristics Influence

• Hierarchy and Control
• Determined by the number of layers in the
  management hierarchy and degree to which
  organizational controls are in place
• Controls maturity of management processes
• Related to size and complexity
• Flat organization, loose controls Big Bang
• Loose controls organization does not have the
  maturity to sustain a very large project
• Hierarchical Organization, tight controls
  Phased

28
Extent of Implementation Influence

• Relates to the number of ERP modules to be
  implemented and the extent of modification to
  modules required
• Few Modules, little modification Big Bang
• Many Modules, extensive change Phased

29
Running Parallel

• Run ERP and Legacy at the same time until its
  clear its safe to turn off legacy systems
• Perceived Advantages
• basis of comparison between old and new systems
• provides a fall-back if new system doesnt work
  out
• Disadvantages
• double effort to enter data and maintain two
  systems
• old system may not be good for comparison
• may have many errors
• may have little in common with new system due to
  new re-engineering
• In reality cant run parallel in some modules
• Example?