Databases for large scale integration
Document Sample


Databases for large scale
integration
Focus on ERP projects
Enterprise Wide Applications
• As the name indicates…
• Keywords:
– Integrated
– Centralised
– Best practice
– Cross functional
– “mega packages”
– Costly (inc. hidden costs)
– Highly complex
– High impact on business
Definition
• No simple definition
• American Production and Inventory
Control Society (APICS)
an accounting-oriented information system
for identifying and planning the enterprise-
wide resources needed to take, make,
ship, and account for customer orders
• Transaction-oriented / operational
Family of applications
• Enterprise Resource Planning systems
• Supply Chain Management
• Customer Relationship Management
• Other more specialised applications such
as planning, warehouse management …
• Merging into ERPII / XRP –encompassing
all aspects of the business
A Complete Family Tree
Late 90’s
CRM Early 00’s
SCM Sales Force
Logistics Automation
Electronic Contract
Invoicing Management
Electronic Customer Service
Marketplaces & Support
Contract Marketing
Management Automation
Documentation
Management
Early 00’s
ERP II Product Data Management Engineering Change Orders
New Product Introduction Collaborative Product Design
Time frame and key milestones
EOQ Safety Stock BOMP Work Orders 1950s
MRP 1965
MRPII 1975
More functions
become
ERP 1990
Integrated in the
process to add up
to complete
business solution ERM / ERPII 2000
1950’s: unlimited demand
Deliver
Supplier Make Customer
1960’s : inventory costs money!
Deliver
Supplier Make Customer
Plan
Buy
1960’s : inventory costs money
Deliver
Supplier Make Customer
Plan
Buy MRP
1970’s : first wave of integration
Deliver
Supplier Make Customer
Plan
Sell
Buy MRP MRP II
1980’s : sales order processing
SOP
Deliver
Supplier Make Customer
Plan
Sell
Buy MRP MRP II
1990’s : back-office integration
Accounting & Finance Human Resources
Deliver
Supplier Make Customer
Plan
Sell
Buy MRP MRP II ERP
2000’s : the extended enterprise
SCM Accounting & Finance Human Resources
CRM
Deliver
Supplier Make Customer
Plan
Sell Service
Buy MRP MRP II ERP
What’s next?
SCM Accounting & Finance Human Resources
CRM
Deliver
Supplier Make Customer
ERP II
Plan
Design
Sell Service
Buy MRP MRP II ERP
Goals of ERP implementations
• Standardisation / centralisation
• Control – eg: integration of financial data
• End fragmentation of legacy systems
• More visibility on key processes
• Optimisation / productivity gains
• Competitive advantage?
• Platform for other projects = infrastructure /
backbone
• Mechanism for integration of latest technologies
(eg: RFID)
Other strong points
• No more uncoordinated applications – eg
quality control
• No more re-keying
• Solution to reporting problems across the
board
• “Sorting out” HR
• Harmonising nomenclatures – eg: product
codes, inventory files …
Problems with ERP
• Impact on business processes (eg: flexibility)
• Understanding the “fit” problem
• Doubtful benefits realisation (50% failure rate?)
– Measurability
– True origin of benefits
• Impact on firm in wider sense
– People
– Clients / suppliers / partners…
• Cost / disruption factor
– $
– Time
– Learning curve
• Coping with evolution (version control)
Gorry and Scott Morton (1971)
“The integrated management information
systems ideas so popular in the literature
are a poor design concept. More
particularly, the integrated or company
wide database is a misleading notion and
even if it could be achieved, it would be
exorbitantly expensive”
Gorry A. and Scott Morton. M. (1971) A Framework for Management Information Systems,
Sloan Management Review, Fall, 55-70.
Dearden (1972)
“The notion that a company can and ought
to have an expert (or a group of experts)
create for it a single, completely integrated
super-system - an MIS - to help it govern
every aspect of its activity is absurd”
Dearden, A (1972) MIS is a mirage, Harvard Business Review, January / February
Preparing for the implementation
• 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
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
Workflow
Workflow
Workflow
Workflow
Shop floor control
Sales management
Field services
planning
…………..
How it works
How it works
Workflow
Workflow
Workflow
Workflow
Sales management
Shop floor control
Field services
Independent versus complementary integration
One way versus two way integration
…………..
Inventory
+ see figure 16.4
planning
ERP Traceability ERP
Data Flow
Module Module
Drill Down
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
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 As-Is +
New requirements
• Consultation of documentation
• Surveys
• Targets:
– Staff
– Suppliers
– Customers
– Other constituencies when needed (eg: vendors…)
Overall 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)
The ITT
• 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
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 again
• 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 Global changes are
considered implemented at local level
primarily
2 - Impact on Business High / Medium / Low Only high impact changes Difficulty in ensuring
will be considered consistent reporting of impact
2a – Savings Quantified Number of transactions * See point 9 below Full justification for perceived
time saved per time interval saving must be presented
3 - SAP standard functionality Yes / No Only standard functionality Except for “must have”
will be considered additions **
4 - Support Project Business Yes / No / Maybe Only unambiguous Yes will
objectives be considered
5 - Impact on project Yes / No Only changes without overall Impact on Alliage project
impact on the project will be focuses on the impact on time
considered of delivery of deliverables
6 - Risk High / Medium / Low Only low risk changes will be trade off to point 4 above
considered
7 – Change in SOP Yes / No / Minimal Only properly documented Reference of QMS approuval
And QMS approuved changes document required
8 - Training Yes / No / Minimal Only changes with minimal bullet points max
training requirements
9 – Costs Number of man days Project requirements to be In case where total resource
IT checked against accumulated usage goes beyond
Users usage of key resources. Alliage budget, steering
QC committee may
recommend scope
enlargement in special
cases
10 – Pay back / Return on Duration of payback period Only changes that pay for Also take intangible benefits
Investment (comparison of 2 and 10) themselves within 12 months 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
• Open items
• Balances
• Conversion or interfaces often required
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
The story continues
• 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
Related docs
Get documents about "