Transcript Buying software

Preparing for ERP
Team creation
•
•
•
•
•
•
Multi-disciplinary
Full time
Decision making power
Budget
Representative – team leads
Balance between allegiance to team and to area
of competence
• Team spirit
• Team awareness
• Must have support from organisation
Team Characteristics
•
•
•
•
Typical size: 25 to 60+ FTE
Team leads: 10 to 20
Functional area experts
Special roles:
–
–
–
–
–
–
–
Project manager
Integration manager
Data conversion and migration
Training manager
Hardware / IT specialist
Platform expert
Communication about project (internal & external)
Collecting requirements
•
•
•
•
•
Interviews with key individuals
Observation of activities
Consultation of documentation
Surveys
Targets:
–
–
–
–
As-Is +
New requirements
Staff
Suppliers
Customers
Other constituencies when needed (eg: vendors…)
Scope arbitration
• Time and cost often already decided
• Time boxing used to segregate
• Trade off with having to do it again next
year
• Arbitrate between requirements
– Out of scope
– Conflict between areas
– Conflict with proposed project scope
• Steering committee (Director level)
Business Integration
• Focus on end-to-end process rather than single
activity
– Cross functional
– Multi-competence
•
•
•
•
•
Reduced autonomy
Increased communication
Increased reliance on tools
Rationalisation of process?
Benefits do not accrue where the system is most
constraining
Inventory
Shop floor control
Sales management
Field services
planning
…………..
How it works
Workflow
Workflow
Workflow
Workflow
How it works
Inventory
Shop floor control
Sales management
Field services
planning
…………..
Workflow
Workflow
Workflow
Workflow
Independent versus complementary integration
One way versus two way integration
+ see figure 16.4
ERP
Module
Traceability
ERP
Data Flow
Drill Down
Module
Example of Business Integration
• MUTAIR case study
• Meals for plane travelers
• Before: quality / high value service
– Culinary business (chefs in toques)
– Dedicated buying
– Price not an issue
• After: commodity
– Drastic price reduction
– MRP type scheduling / purchasing
Mutair case study
• Process integration:
– p/o, receiving, issue, inventory, invoicing, accounts
payable & accounts receivable
– Bulk buying from agreed suppliers
– Tough negotiation on price of RMs
• But, rationalisation does not always work
– 80% of jobs are OK
– Rest cannot be planned (delays, change of schedule,
special meals…)
• Dysfunctional use of system => dysfunctional
ERP
What can go wrong
• Integrated systems rely on actors to “play the game”
– Need good perception of system
• Here, actors impeded by system
–
–
–
–
–
–
–
Inaccurate data entry
Physical stock VS theoretical stock
Faxed P/Os post-entered / never entered (supplier does not exist)
Ghost deliveries reached the loading bay
Either goods sent back (no stocks)
or invoice cannot be reconciled (payment impossible)
Emergency orders must be entered somehow => wrong codes used
• Overall performance of the process decreases
– May keep going at local level
– But overall vision is totally inaccurate
• Might as well have implemented nothing
Where problems originate?
• In preparation phase for project
• Lack of managerial awareness of risks /
opportunities
• Lack of understanding of how to select software
• Lack of vision of the business impact
• Wrong scope (eg: areas pull out and weaken
project)
• Not enough money for proper analysis
• Wrong team (not at the right level / too militant)
Communication
• Political / change management dimension
• Internal aspects
–
–
–
–
Expected support (we need you!)
Properly justify project (?)
Explain change in roles
Give assurances (when possible)
• External aspects
– Be upfront about new rules
– Adopt participative approach?
– Seek collaboration / leverage other firms’ systems
• Perception of system / team
Benefit realisation
• Only occurs when definitive targets sought
• Only occurs if analysis was realistic and did not neglect
downsides
• May be more intangible than measurable
–
–
–
–
Head count
Upfront implementation cost
Length of learning curve
Investment may not be exhausted by current usage (stage 2 /
ERP2 etc…)
• Whose benefits are those anyway?!?!
– Case of the multi-national
– Case of a dominant coalition
The ITT – more details
• Trade off between detail and speed of
processing of information
– Cover everything
– Sample the functionality
– Buy on faith
• Available in generic format (see handout)
• But always better when tailor made to fit
business goals
• See notion of fit in previous notes
• Also prepare ITT to facilitate analysis
• But some vendors will ignore the format
Other methods – Commercial
presentations
• The armies of darkness….
• Be prepared / ready to question
• Vendors:
– Will always look good / sound good
– Possible to preview software
– Unlikely to be caught off guard
• Consultants:
– Sound also very good
– Try to ensure stable participation
– Seek experience of very similar project / industry
Site visits
• Similar (completed) implementation site
• Volunteered by vendor (with prior
agreement)
• Very realistic
– Can talk to actual / current users
– Can go down to area specific detail
– Can ask about actual support received from
vendor
• But unlikely to hear a horror story
Comparing tenders
• Likely they all look good
• Need a rigid set of criteria to decide
– Criteria
– Type of criterion
– Relative weight
– Rules for computing overall score
• How many would you like to end up with?
• Decide on shortlist
Shortlisted firms
•
•
•
•
On or off site presentation
Intense meeting
Any item unclear in ITT
Any contentious point
–
–
–
–
User requirements
Price
Support / maintenance contract
Technical characteristics (eg: response time)
• Then leave lawyers finish it off
• Don’t expect a clear cut answer
• Recommend for board level decision
Next steps
• Agree on exact schedule
• Freeze scope
• Schedule participation of all required users /
technical staff
• Communicate communicate communicate
• Run awareness workshops etc…
• Negotiate re-skilling arrangements
• Ring fence resources and budgets
• Prepare for IMPLEMENTATION
Implementation phase
•
•
•
•
•
•
Create fine configuration of package
Define roll out strategy
Schedule implementation in phases
Organise data loads
Go live (s)
Define criteria for ramp up period (duration
to full capacity)
• Measure progress and report
ERP roll outs
• Core team (global)
• Local implementation teams
• Roll out step:
–
–
–
–
–
–
Initial meeting with local pm
Local team set up
Bringing local team up to speed
Understand implications of template at local level
Create additional workarounds
Define criteria for acceptance / rejection of additional
demands
Factor
Input values
Decision
Comment
1 - Scope
Global / Local
Only global changes will be
considered
Global changes are
implemented at local level
primarily
2 - Impact on Business
High / Medium / Low
Only high impact changes
will be considered
Difficulty in ensuring
consistent reporting of impact
2a – Savings Quantified
Number of transactions *
time saved per time interval
See point 9 below
Full justification for perceived
saving must be presented
3 - SAP standard functionality
Yes / No
Only standard functionality
will be considered
Except for “must have”
additions **
4 - Support Project Business
objectives
Yes / No / Maybe
Only unambiguous Yes will
be considered
5 - Impact on project
Yes / No
Only changes without overall
impact on Alliage will
be considered
Impact on Alliage project
focuses on the impact on time
of delivery of deliverables
6 - Risk
High / Medium / Low
Only low risk changes will be
considered
trade off to point 4 above
7 – Change in SOP
Yes / No / Minimal
Only properly documented
And QMS approuved changes
Reference of QMS approuval
document required
8 - Training
Yes / No / Minimal
Only changes with minimal
training requirements
bullet points max
9 – Costs
Number of man days

IT

Users

QC
Project requirements to be
checked against accumulated
usage of key resources.
In case where total resource
usage goes beyond
Alliage budget, steering
committee may
recommend scope
enlargement in special
cases
10 – Pay back / Return on
Investment
Duration of payback period
(comparison of 2 and 10)
Only changes that pay for
themselves within 12 months
Also take intangible benefits
into account
Training
–
–
–
–
–
–
–
Design training courses and develop
material
Schedule training overall
Select and train trainers
Create facilities / sandpit
Book staff for training sessions
Coordinate training
Create assessment mechanism and
monitor progress
Data transfers into an application
•
•
•
•
•
•
First time system implementation
Data warehousing projects
Database version upgrade
ERP projects
Move to new version
Called a migration
– From a manual system
– From old to new system
Data transfers between systems
• Static data (eg. Customers)
• Dynamic data (eg. sales orders)
– Additional problems with a live system
• Conversion or interfaces often required
What can go wrong
• Data not available
– feature activated from implementation onwards
– Massive manual data entry (?)
– Eg: different account structure
• Incomplete data
– Some fields are missing
•
•
•
•
Inconsistent data (eg: engineering vs accounts)
Wrong level of granularity
Data not clean - incorrect
Most new system requires changes due to their
different data structure / activity system
Data cleaning must address
• Different department record same info
under different codes
• Multiple records of same company (under
different names)
• Fields missing in input tables (eg: a/c #)
• Different depts. Record different
addresses for same customer
• Use of different units for time periods
Labour intensive tasks
•
•
•
•
Data entry
Data validation
Working on solving conflicts
Allocating new codes
• Solution = introduce as much automation as possible
– SQL
– Custom conversion programmes to extract, modify and upload
data
– Filtering
– Parsing (eg: excel)
– Staging areas for conversion in progress
Example 1 – the supplier file
New supplier code to include city where firm is based
Assignation of category based on amounts purchased
OLD
Sup code
4 digits
Sup name
Sup address
City
Phone
Example 1 – the supplier file
New supplier code to include city where firm is based
Assignation of category based on amounts purchased
OLD
Sup code
4 digits
Sup name
Sup address
City
Phone
NEW
Sup code
3 letters +
4 digits
Sup name
Sup address… Phone Cat
1,2,3 depending
on total purchases
last year
Example 2 – New Cost
Accounting Structure
Maintenance department expenditure:
1 account => separate accounts for different production activities
OLD
Intervention code
Desc. Date
Labour Parts Total
Example 2 – New Cost
Accounting Structure
Maintenance department expenditure:
1 account => separate accounts for different production activities
OLD
Intervention code
Desc. Date
Labour Parts Total
NEW
Intervention code
Desc. Date
labour Parts Total Account
Will data still be available? Will an archive be maintained?
Example 3: merging files
• Complete customer file based on
Accounts, Sales and Shipping
OLD (finance)
CustID name
address city
account number credit limit
balance
discount rates
rep_name
OLD (sales)
CustID* name
address city
sales_to_date
OLD (Shipping)
CustID**
name
address city
Preferred haulier
Example 4: change of business
practices
• Payment by bank draft for international customers
• Automatic payment into account for national customers
• Payment direct into account for all customers
Data Upload
• Several rounds:
–
–
–
–
–
Trials
Static data
Open items
Dynamic data - transactions
Balances
• Staging areas
– Local initially
– Then central area
• Upload into live system
– Specific predefined sequence (RDB)
– Extract, translate, load
– Rental of platform specific tools from vendor
Go live
• A single point in time
• First transaction routed through system –
eg sales order
• In reality loads of data already in –
incremental approach
• Plenty can still wrong although not right
away
• Over first few weeks – ramp up to full
capacity
Post Go Live
• Team is disbanded
– Back into business
– Promoted
– Next wave of roll out
• Structure is permanently altered – eg: shared services
• ERP team put in place
–
–
–
–
Data experts / maintenance
Application experts – on-going developments and fixes
Platform experts – uptime
Business analysts – look to future releases and future
requirements
– Typical size 20 /25 staff full time for a multinational
– Various names used – eg: knowledge centre
What can happen then
• Dysfunctional ERP => uninstall
• Next phase in implementation
– More modules
– More sites
– More interfaces to legacy systems
• Update to new version
• Merger and acquisition => change to other
platform
Conclusion: the ERP community
Site B
Site C
Site n…
Site A
Client - HQ
External Parties:
Regulatory bodies
Auditors
Industry Experts
ERP Consultants
ERP Vendors
Conclusion: managing change
Perception of staff
Allocation of work
Go Live
Package bought
Post-implementation
Time
Increasing Anxiety
Enthusiasm
Benefits
Begin to
appear
Business as
Usual –
Low morale
Conclusion: Critical issues in
ERP implementation
• Deciding scope of project
• HRM and setting up the team (and budget)
• difficulty in making a transition from an old model
to an ERP model
• Preserve previous learning
• overestimation of the pace of change of some
stakeholders (technical change is not sufficient)
• difficulty in obtaining any direct ROI
Conclusion: What happens to
competitive advantage?
Actual Core Business
Unmet Needs
(Hidden Needs
Discourse)
Stated Prioritised
Business Requirements
(as per Consultant Report)
Capabilities of the
Standard Package
(Best Practice / Sales
Discourse)
Surplus to Needs
Paradigm Shift towards
Competive Parity
Workarounds
Lost Knowledge /
Processes
New Processes
Refocused Core Business
Unused functionality
No
Is the Asset
Valuable?
Yes
Yes
Is the Asset
widely available
to competing
firms?
No
Competitive
Disadvantage
Competitive
Parity
Temporary
Competitive
Advantage
No
Is there a long
learning curve
or specific
know-how
required?
Yes
Sustained
Competitive
Advantage
Conclusion: Working on a stronger
rationale
• Prove the need for ERP
• Davenport’s questions:
–
–
–
–
How might ERP strengthen out comp. Adv.?
How might it erode …?
What will the ERP’s effect on the org. culture?
Do we need to extend the system across all
functions?
– Do we need to rollout globally?
– Are there any alternatives?
Conclusion: Sales versus Needs