Timberjack Parts

Packaged software selection process

By:
Abhirup Mukhopadhyay(02)
Aniket Singh Mahra(10)
Bhanu Manchanda(26)
Disha Kashyap (32)
Lopa Mudra Panda(58)
 Scope of Timberjack
• Leading manufacture of heavy equipments.
• Formed through number of acquisitions during
1980s and 1990s.
• Operated two service parts operations in Marsta
and Sweden .
1995 :
Market Share : 25%
Sales : 627m USD
Profits : 88 m USD
Employees : 1600
 Why ERP
• Instability of the existing system
• Heavy modifications led to frequent system
failures
• Lack of user reliability
• Future need for integrating manufacturing,
dealer network , parts and service.
• HP’s reluctance to provide further support to
it aging software MM3000.
• Issues with integration of financial data
Timberjack: Sweden Timberjack: Atlanta
• needed a faster change as • had time and wanted to
its operations were badly implement a universal
effected system.
• Not satisfied by the RPF • Satisfied with the RFP
model used to select model
vendors
• Strong preference for QAD • Strong preference for Oracle
• No customization • Needed to customize
 Decision Rationale

• Aging MM300 software

• Instabliity of existing systems
Business •
•
Financial Integration
Employee transfers
• User reliability

• Narrowing down to common requirements of

Atlanta/Marsta
• Disparate systems
Technology • Oracle/ QAD Preferences
• Different application and server requirements
• Risk of obsolescence
 • Customizations Required- QAD : Dealer System , Oracle :
Order Processing
• Implementation Cost / Time : Oracle – High
Implementation • Consultant support
• Overhead Costs (Oracle high)
• Support Fees (QAD high)

• Cyclical Industry
• Backward and Forward Integration
(Manufacturing/Dealer/Service)
Strategic • Integration of North America operations
• Competitive advantage in vendor selection
• Complete “Distribution Package”
 The RFP process
CONSULTANT-COOPERS & LYBRAND
Sessions with
members from Benefits review started Business
each functional at Woodstock statistics and
area dealer system
details
incorporated in
RFP
Ensure all Additional
processes are requirements
covered in detail for Marsta

Hard copies
List of and soft
Consideration for requirements were copies
any additional sent to Marsta for dispatched for
software review vendors

Timberjack list
compared with C&L
Business process list developed for
breakdown prior clients
 Issues regarding the RFP
-Woodstock vs Marsta
ADDITIONAL REQUIREMENTS FOR MARSTA
Requirements related to:
 Multilanguage capability
 EFT for payments to suppliers
 Intrastat reporting used in Europe for
tracking of goods
ADDITIONAL REQUIREMENTS FOR
WOODSTOCK
 Benefits analysis to weight the potential
functionality improvements
OPPOSING VIEWS
 Marsta wanted an enterprise syatem
at the earliest while woodstock was
in no hurry
 Marsta would have preffered a RFP
running for just 5 pages while that
developed by Woodstock went on for
200 pages thus building in a delay in
RFP evaluation by the vendors
 Marsta was focusing short term to
solve its current needs while
Woodstock had a long term
perspective going into the project.
 VENDOR SELECTION

Constraints limiting the potential suppliers

• System to be UNIX based , as specified by DSI
• A preference of Oracle database as corporate standard
• Package’s presence in both Europe and North America

 Vendor list based on manufacturing systems with secondary strengths in

distribution and service
 Out of 13 companies selected, 6 bids were received – Lawson, Oracle,
Computer and Associates, QAD, Scala and American software
 Critical functionality – Planning, customer service, warehousing & finance
 Scala and American software dropped due to lack of functionality & UNIX
based modules
 Narrowing the vendor list
CA QAD
ORACLE • Relied on software Lawson • System was not
•Early presentation acquisition rather • Techinically strong flexible enough t
not received well – than ongoing software packege, make changes
staff inefficiency, development – but lacked some without affecting
complicated concern about functionality that the source code
software & technical support& longterm were critical to difficulties in
problems commitment to the Atlanta team migrating to Oracle
package database

Oracle – QAD –
preference preference
by Atlanta by Swedish
group group

Factors considered for narrowing to two vendors:

License fee for software , Functionality comparison , Implementation consulting cost , Gartner Group
articles
 Factors
Functionality shortfalls – Work
needed in these areas
Total cost of dealer system
modifications
Implementation Consulting
Installation time
Complication
Site visits
Oracle
Order processing module to match
current dealer system functionality
$ 30,000
More consultants over a longer
duration, consulting fee to install in
both sites is $ 500,000 USD, later
reduced by 25%
At least one year
Highly complicated & hence
require more personnel assistance
initially
True Temper
Stepwise implementation
Large no. of people used for
installation
Project took more than 1 year to
complete
QAD
Customization on dealer systems,
order type & safety stocks
$ 200,000
Mod in safety stock program &
order type functionality
requirements
Not much consultants required
as it is not a huge and
complicated package
Six to seven months
Simple & hence easier
implementation with lesser
personnel assistance
Matrix
Running on a low version
package
Modules hard to modify without
affecting the core system
 Recommendation

• Oracle as first choice to

be implemented as
compared to QAD (Sap
based software)
 Reasons to support Oracle
• Covering 95% of functionalities as compared to 88% of
QAD hence low customization and more reliable.
• QAD being SAP as base is more rigid in structure (good
for standards but poor flexibility)
• A huge gap in forecasting and dealer system which are
very essential part of the ERP module needed in
industries( Gap analysis in sec 7)
• Oracle as a organization is more reliable for future
existence hence secured future maintenance.
• Noncompliance penalties applicable over Oracle also
makes it more viable.
 Oppositions
• Need for 2 different systems for
manufacturing and parts and services
• Higher cost for Oracle
• 40% higher overhead required in database
• Expensive hardware and software expected