Enterprise

Resource
Planning
ABOUT THE AUTHOR

Rajesh Ray is an engineer, having his Master’s degree in Operations and

Systems Management and CPIM from APICS (American Production and Inven-
tory Control Society).
Mr Ray has worked with the world’s largest ERP and Enterprise Solution
vendor, SAP, at their headquarters in Germany and India for six years. He is
currently leading ERP, SCM, SRM and PLM product areas at IBM GBS. (IBM
Global Business Service is the world’s largest ERP and Enterprise Solution
consulting firm.) He has ten years of experience in implementing ERP, Supply
Chain and PLM solutions in the capacity of project leader, solution architect,
business consultant, business analyst and implementation consultant for custom-
ers in the sectors of automobile, retail, consumer goods, electronics, metal and
engineering industries in different continents. He has experience of deploying
enterprise solutions with large global clients like Nestle, Unilever, British American Tobacco, Best Buy, Tesco,
Mitsubishi, Panasonic, Thysenkrupp Steel, and companies in India like ITC and Tata Steel.
An honorary member of CII National Logistics Council, Mr Ray is a member of APICS. He is a frequent
speaker in different enterprise solution forums, and has authored a book Supply Chain Management for
Retailing published by Tata McGraw-Hill. He has around 34 publications in different international
journals.
 Enterprise
Resource
Planning

Rajesh Ray
Senior Managing Consultant
&
Product Lead (Supply Chain Management)
IBM, India

Tata McGraw Hill Education Private Limited

NEW DELHI
McGraw-Hill Offices
New Delhi New York St Louis San Francisco Auckland Bogotá Caracas Kuala Lumpur
Lisbon London Madrid Mexico City Milan Montreal San Juan Santiago Singapore Sydney
 Tata McGraw-Hill

Published by the Tata McGraw Hill Education Private Limited,

7 West Patel Nagar, New Delhi 110 008.

Enterprise Resource Planning

Copyright © 2011, by Tata McGraw Hill Education Private Limited. No part of this publication may be reproduced or
distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise or stored in a
database or retrieval system without the prior written permission of the publishers. The program listings (if any) may
be entered, stored and executed in a computer system, but they may not be reproduced for publication.

This edition can be exported from India only by the publishers,

Tata McGraw Hill Education Private Limited

ISBN-13: 978-0-07-070088-8
ISBN-10: 0-07-070088-5

Vice President and Managing Director—McGraw-Hill Education: Asia/Pacific Region: Ajay Shukla
Head—Higher Education Publishing and Marketing: Vibha Mahajan
Publishing Manager—B&E/HSSL: Tapas K Maji
Associate Sponsoring Editor: Piyali Ganguly
Assistant Manager (Editorial Services): Anubha Srivastava
Senior Copy Editor: Sneha Kumari
Senior Production Manager: Manohar Lal
Production Executive: Atul Gupta
Deputy Marketing Manager: Vijay S Jagannathan
Senior Product Specialist: Daisy Sachdeva
General Manager—Production: Rajender P Ghansela
Assistant General Manager—Production: B L Dogra

Information contained in this work has been obtained by Tata McGraw-Hill, from sources believed to be reliable.
However, neither Tata McGraw-Hill nor its authors guarantee the accuracy or completeness of any information
published herein, and neither Tata McGraw-Hill nor its authors shall be responsible for any errors, omissions, or
damages arising out of use of this information. This work is published with the understanding that Tata McGraw-Hill
and its authors are supplying information but are not attempting to render engineering or other professional services.
If such services are required, the assistance of an appropriate professional should be sought.

Typeset at The Composers, 260, C.A. Apt., Paschim Vihar, New Delhi 110 063 and printed at
Sheel Printers Pvt. Ltd, D-132, Hoisery Complex, Phase-II, Noida.

Cover Design: Aishwarya Padhye

Cover Printer: Sheel Printers Pvt. Ltd

RAXYCRBZDRXZZ
To my father, (Late) Sri Rabindranath Ray
my mother, Sibani Ray
my brother, Surhid Ray
my wife, Piyali Ray
and
my son, Purab Ray
 Preface

Enterprise Resource Planning and Enterprise Applications have revolutionised the way corporates treat infor-
mation today. In the 1970s, Information Technology (IT) used to be a support service and was traditionally
limited to the MIS department of an organisation, which was known for producing some month end reports
and for data crunching. The CIO (Chief Information Officer) as a position in an organisation was not known
to the world and the IT managers of those days used to be good in programming and had hardly any business
understanding. In most companies less than five percent of employees were so-called IT users. However,
things have changed in the last few decades. Most of the leading organisations of today have understood
that their success depend a lot on how effectively they can use information that get generated everyday
from millions of data points through interaction with customers (customer order data, customer service data
etc.), suppliers (purchase order data, vendor management data etc.), employees, and at a factory shop floor
(production data, quality data etc.). Each employee of these organisations is an IT user who creates data,
analyses it and is, finally, empowered to take decisions based on it.
IT had also changed our everyday life. We no longer go to the bank and stand in a long queue for with-
drawing money– it is a two-minute transaction in an ATM and immediately the bank sends a text message
in the mobile to confirm the transaction. Internet is a popular medium today to plan our travel and to buy
our train/flight ticket.
A lot of this information technology revolution in the last few decades has been made possible by ERP
(Enterprise Resource Planning) and other enterprise applications (like CRM – Customer Relationship Man-
agement, SRM – Supplier Relationship Management, PLM – Product Lifecycle Management, SCM – Supply
Chain Management etc.). Those companies which have implemented these packages successfully and have
made possible that they be used effectively by employees through proper training and change management
have seen dramatic improvement over the others in their performance. However, for every success, there
have been multiple cases where companies did not realise the benefits forecasted at the beginning of the
project as the implementation was not proper and the users never used the system to its true potential.
Organisations need to guard against such pitfalls.
This book is not only on ERP but also covers other enterprise applications like PLM, CRM, SCM, SRM
etc. which are growing at a faster rate than core ERP application as the ERP market is getting saturated.
This text is intended for students (who want to learn these topics for the first time), for practicing execu-
tives (who want to move to a career in ERP from their traditional role in finance, operations, marketing or
HR and want to know what ERP or CRM is all about) and finally for managers who are responsible for
viii Preface

selecting, implementing and maintaining an ERP/CRM/PLM/SCM package in their organisation. The book
contains all the topics they need to know about the selection of a package and a consultant, project prepara-
tion, implementation methodology, training, maintaining the system, details about each package, etc.
The text is divided into six sections. The first section (Chapter 1) explains the concept of ERP, history
of the ERP evolution, benefits and challenges of ERP and, finally, recent trends in the ERP market.
The second section (Chapters 2 to 19) discusses in detail the lifecycle of an ERP/Enterprise Application,
i.e., its selection, implementation and finally the ongoing support. This section has extensive coverage on
ERP business case building, package and consultant selection, ERP project management, team formation,
BPR, business process modelling, Gaps Identification, configuration and testing, managing ERP security,
data migration, cut over and go live, training, change management, application support, etc. While these
topics are discussed mainly in the ERP context, they are equally applicable for any other enterprise solution
like CRM, PLM, SRM, SCM, etc.
The third section (Chapters 20 to 31) discusses different functional areas covered by ERP and Enterprise
Applications. This section covers areas like human capital management, financial management, sales and
service, customer relationship management, procurement, inventory management, supplier relationship man-
agement, supply chain management, production planning, logistics execution, quality management, mainte-
nance management, product lifecycle management, etc. Students and professionals can refer to the chapters
according to their areas of interest and get the details. While students with specialisation in HR, finance and
marketing will find HCM (Human Capital Management), financial management and CRM–Sales–Service
interesting, students with specialisation in supply chain/operations will find other areas relevant. Similarly
professionals from the purchase function will find procurement, inventory management and SRM interest-
ing, R&D people can get into the details of PLM, and factory shop floor production managers can find
production planning, quality management and maintenance management most relevant. This section has
a wide variety of functional areas covering almost every business function. While the section is package
independent, while developing the content I have referred mostly to the functionalities of leading packages
in the space, for example, SAP and Oracle for ERP, Siebel for CRM, etc.
The fourth section (Chapters 32 to 34) mainly covers different technology areas of ERP and Enterprise
Applications, for example, data warehousing, reporting and business intelligence, data mining, analyt-
ics, portal, content management, knowledge management, etc. The last chapter of this section discusses
different emerging technology areas like SaaS, Cloud Computing, RFID, SOA, Hosted ERP, M Commerce,
EAI, etc.
Increasingly ERP vendors are coming up with more and more industry-specific offerings. The fifth sec-
tion (Chapters 35 and 36) covers the subject of ERP for manufacturing and service industries. This section
is a major differentiator of this book which, I hope, the readers will enjoy reading.
Finally, the sixth section covers a series of case studies. These are chosen carefully covering different
types of enterprise applications (like ERP, SCM, CRM etc.) and different types of projects (Implementation,
Global Rollout etc). Cases are picked up from different industries and cover both leading Indian as well as
global companies.
Chapter-end material covers a set of objective-type questions, descriptive-answer questions, fill in the
blank and true and false exercises, and finally, a set of assignments. These will be helpful for students for
ensuring proper understanding of every chapter.
 Preface ix

I would like to thank M.V. Subha, Anna University, Coimbatore; S. Jaya Bharathi, Anna University,
Coimbatore; Nilay Yagnik, NMIMS University, Mumbai; Shailaja Rego, NMIMS University, Mumbai;
Shreeram Gupta, SVIM, Indore; Vinod Vaze, Wellingkar, Mumbai; S.C. Sood, Gyan Jyoti Institute of Man-
agement and Technology, Punjab; A.N.K. Prasanna Anjaneyulu, Institute of Public Enterprise—Osmania
University, Hyderabad; D.P. Sharma, Asian School of Business Management, Andhra Pradesh; Anil Kumar,
Institute of Management Technology, Maharashtra; Debarshi Mukherjee, Indian Business Academy, Uttar
Pradesh; Kavindra Kumar Singh; Santosh Kumar, Invertis Institute of Management Studies, Uttar Pradesh;
Nalin Chander Jha, ILM Institute for Higher Education, Haryana; V.P. Vignesh Kumar, PSN College of
Engineering & Technology, Tamil Nadu; and Vaibhav Panwar, Institute of Management Studies, Uttarakhand
for their valuable feedback on the contents of the book.
I hope you will find this book both interesting and useful. Please feel free to send in your feedback and
suggestions. Your inputs will be helpful in improving upon the text in future.

RAJESH RAY
[email protected]
 Contents

Preface vii
SECTION 1
Introduction to ERP and Enterprise Applications
1. ERP Overview 3
Definition of ERP 3
Need for an ERP 4
History of ERP Application 8
Benefits from an ERP System 10
ERP and Enterprise Applications—Emerging Trends 17
ERP—A Subset of Enterprise Applications 18
Summary 19
Exercise 19
SECTION 2
Implementation and Support
2. ERP Implementation—Life Cycle, Methodologies and Strategy 27
ERP Life Cycle 27
Methodology for Implementation 44
Summary 53
Exercise 54
3. Business Case and Return on Investment Analysis for ERP 56
Cost of ERP Implementation 56
Benefits of ERP Implementation 59
Case Study: Building a Business Case 62
Summary 63
Exercise 64
4. Selecting Consulting Partner 65
Things to be Considered for Partner Selection 66
Request for Proposal Method for Selection of Consulting Partner 68
In-house Implementation Team vs. External Consultants 70
ERP Consulting Companies 71
Doing Part of ERP Projects from Offshore 72
 xii Contents

Summary 74
Exercise 74
5. ERP Package Selection 76
Introduction 76
ERP Selection—A Two-Step Process 77
Summary 86
Exercise 86
6. ERP Project Team and Project Organisation Structure 88
Introduction 88
Project Organisation Structure 89
Roles and Responsibilities of Different Project Team Members 90
Core Team Selection 93
Consultant Selection 94
Summary 95
Exercise 96
7. ERP Project Management 97
Introduction 97
Project Scoping 98
ERP Implementation Project Plan 107
Resource Plan 108
Project Procedures and Standards for Governance 111
Project Charter 113
Project Risk Management 115
Summary 117
Exercise 118
8. Managing Requirements 120
Concept of Requirement 120
Types of Requirements 121
Requirement Gathering Process 122
Summary 125
Exercise 125
9. Business Process Reengineering 126
Business Process Reengineering (BPR) 126
Pros and Cons of BPR 128
BPR/Process Redesign—Reasons for Failure and Keys to Success 129
Reengineering Phases 130
Role of Information Technology in BPR and Business Engineering 140
BPR and ERP 141
Benchmarking 142
Best Practices 144
Summary 145
Exercise 146
 Contents xiii

10. Business Process Modelling and Business Modelling 149

Business Process Modelling—Introduction 149
Business Process Hierarchy 151
Standards for Business Processes and Process Modelling 152
Process Modelling Maturity and Multi-Dimensional Modelling 155
Process Modelling Software 156
Business Modelling 158
Integrated Data Modelling 160
Summary 160
Exercise 161
11. Gaps Identification and Strategies to Bridge the Gap 163
Introduction 163
Reasons for Gaps and Five Types of Gaps 163
Gap Document and Gap Management Strategy 166
Development Specifications—Functional and Technical 168
Gap Development Options 168
Summary 170
Exercise 170
12. Configuring and Testing of the Solution 171
Configuration 171
Testing 173
Summary 182
Exercise 182
13. Managing ERP Security 184
Introduction 184
Types of ERP Security Issues 184
System Access Security—Authorisations 185
Data Security and Technology for Managing Data Security 187
Summary 188
Exercise 188
14. Data Migration 190
Migration of Data 190
Summary 198
Exercise 198
15. Cutover Planning and Go Live Preparation 200
Cutover 200
Go Live Preparation 201
Summary 205
Exercise 205
16. Training 206
Introduction 206
Training Objectives 207
xiv Contents

Training Strategy 208

Training Environment and Technology 210
Train the Trainer Approach 211
Training Delivery 212
Training Content Development 213
Training Evaluation 214
Training Roles 214
Summary 215
Exercise 215
17. Change Management 217
Introduction 217
Change Management for the ERP Project Team 218
Change Team and Change Management Roles 222
Change Management Activities During Lifecycle of a Project 223
Search for Change Management Methodology—Six Key Processes of ASAP 224
Summary 226
Exercise 227
18. Success or Failure of ERP Implementation 229
Reasons for Failure of an ERP Implementation 229
Reasons for Success of ERP Implementation 235
Summary 239
Exercise 239
19. Application Support 240
Introduction 240
Support Cycle 241
Transition 242
Steady State Support 244
Upgrade Phase 248
Different Levels of Support 252
Service Levels and SLAs 253
Service Desk 256
Vendor Support: An Overview of Support Strategies from Leading ERP Vendor SAP 259
Different Support Models and Outsourcing Support 262
Support Roles 265
Methodology for Support 266
Measuring ERP Performance and Continuous Improvement 268
Summary 270
Exercise 270
SECTION 3
ERP Functional Modules
20. Human Capital Management 279
Introduction 279
Human Capital Management Systems 279
 Contents xv

Leading HR Solutions from ERP Package Vendors—SAP and Oracle 291

Strategic Vs. Operational HR Processes and HR Outsourcing 293
Employee Health and Safety 294
Summary 295
Exercise 296
21. Financial Management 298
Introduction 298
ERP Financial Application 298
Financial Modules in Detail 300
Emerging Areas in Financial Management 303
Summary 305
Exercise 305
22. Procurement and Inventory Management Through ERP 307
Procurement 308
Inventory Management 321
Summary 329
Exercise 329
23. Supplier Relationship Management 332
Understanding Supplier Relationship Management 332
Electronic Procurement 335
Summary 348
Exercise 348
24. Production Planning and Execution 350
Understanding MRP II Concepts 350
How ERP Production Planning (PP) Module Supports MRP II Processes 364
Critical Master Data Elements for Production Planning 368
Managing Different Production Scenarios 372
Summary 374
Exercise 375
25. Supply Chain Planning 377
Supply Chain Planning 377
Supply Chain Planning Solution—Modules 383
Collaborative Planning Solutions 391
Summary 396
Exercise 397
26. Sales and Service 399
Introduction 399
Sales and Distribution Processes and How ERP Supports That 400
Sales and Distribution Master Data 405
The Concept of Perfect Order 407
Managing Global Trade (Export and Import) 409
Managing Customer Service 414
xvi Contents

Summary 415
Exercise 415
27. Logistics Execution: Warehouse and Transport Management 417
Logistics Execution 417
Transport Management 427
Summary 431
Exercise 431
28. Customer Relationship Management 434
Customer Relationship Management (CRM) 434
Summary 444
Exercise 444
29. Quality Management 446
Quality Management 446
Summary 454
Exercise 454
30. Maintenance Management and Enterprise Asset Management 456
Maintenance Management 456
Summary 466
Exercise 466
31. Product Lifecycle Management 468
Introduction 468
What is Product Lifecycle Management—Business Drivers and Value Proposition 469
Different Phases of Product Lifecycle—Information and Application for Different Phases 471
Difference of PLM with ERP 474
PLM–Functionalities 475
Product Safety and Environmental Compliance—An emerging Area of PLM 480
PLM Vendors 481
Summary 482
Exercise 483
SECTION 4
Technology Areas of ERP and Enterprise Applications
32. Portal, Content Management and Knowledge Management 489
Introduction 489
Portal 490
Summary 499
Exercise 500
33. Data Warehousing, Data Mining, Business Intelligence and Analytics 502
Introduction 502
Data Warehousing 503
Data Extraction, Transformation—Cleaning and Data Loading 510
Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP) 512
 Contents xvii

Data Mining 516

Analytics 518
Business Intelligence 519
Summary 520
Exercise 521
34. ERP and Enterprise Applications—Emerging Trends 524
New Models of Deploying ERP and Enterprise Applications 524
New Technologies that Made Models of Deploying ERP More Effective 533
Summary 542
Exercise 543
SECTION 5
ERP for Industries
35. ERPs for Different Manufacturing Industries 551
Introduction 551
ERPs for Petroleum, Oil and Gas Companies 552
ERPs for Auto Industry 554
ERPs for Pharma 557
ERPs for Consumer Product Goods (CPG) 559
ERPs for Mining Industry 561
Summary 562
36. ERPs for Different Service Industries 564
Introduction 564
ERPs for Retail 564
ERPs for Healthcare 571
ERPs for Educational Institutions 574
ERPs for Telecom 577
ERPs for Banks 578
ERPs for Insurance Companies 580
ERPs for Utility Companies 581
Summary 583
SECTION 6
Case Studies
Cases of ERP and Enterprise Application 587
mySAP Business Suite Implementation at ITC 588
Nestlé GLOBE Project—A Successful Example of Global Rollout 589
Oracle ERP Implementation at Maruti Suzuki 591
Siebel CRM Implementation at Bharti Airtel 592
i2 Supply Chain Solution Implementation at Asian Paints 593
Summary 594
Index 595
 Section

Introduction to ERP
and Enterprise
Applications
 SECTION INTRODUCTION

ERP Overview
The first section of this book has one chapter that starts with an introduction to ERP, why it is needed, its
history, how it benefits business and challenges of ERP solutions. This section also discusses how ERP is a
subset of a larger set of enterprise applications and some of the emerging trends in this space.
The ERP software had its origin in MRP and MRP2 applications and encompasses every process within
the organisation. Over time, ERP application vendors had come up with new offerings to meet specialised
requirements of Marketing (CRM application), R&D (PLM application), Procurement (SRM application)
and Planning (SCM applications).
ERP software came up with lot of promises in terms of unifying enterprise, one database, online real-time
information etc but this came up with a series of challenges in terms of implementation, people issues and
change management. ERP became a buzzword of 90s with almost every large corporate going for it but as
the hype is settled down now, people are increasingly looking at doing projects faster, cheaper and ensuring
quick ROI. This had increased the pressure on ERP vendors to come up with more customised solutions
for SME clients, more industry-specific offering instead of vanilla package and making their offering more
end-to-end.
 1
ERP Overview
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Definition of ERP
Need for an ERP
History of ERP Applications
Benefits from an ERP System
ERP Challenges
ERP and Enterprise Applications – Emerging Trends
ERP – A subset of Enterprise Applications

DEFINITION OF ERP
If you are a professional working in the corporate world, or a management student or someone from the so
called IT world, then perhaps you had already heard this term “ERP”. While there are many ways of defining
what ERP is, let us try to understand these three terms “Enterprise Resource Planning” separately.

Enterprise
The enterprise is any organisation that has a set of common goals.

Resource
What are the resources of an enterprise? Resources can be in the form of human resource (manpower),
capacity (machine, plants, warehouses, etc), inventory resources (finished goods and raw materials stock),
etc. For any organisation the biggest challenge is the utilisation of these resources effectively for creation
of best possible value for its stakeholders (i.e., its employees, shareholders etc.).

Planning
For effective utilisation of resources, an enterprise needs to plan and undertake a variety of planning activi-
ties like demand planning, distribution planning, production planning, capacity planning, material planning,
maintenance planning, financial planning and budgeting, quality planning, new product planning, etc.
 4 Enterprise Resource Planning

However, it is important to note that an ERP software not only helps in planning but also assists in a set
of execution activities for the organisation like creating purchase order, raising invoices, managing accounts
or making deliveries of finished goods. Today’s ERP applications help in running an enterprise’s business
functions like financial accounting, production management, procurement, quality, asset management, sales,
distribution, etc and covers almost all the organisational processes like procure to pay, order to cash, human
resource management, etc.
There are hundred ways of defining “ERP” application. In this book we define ERP as:
ERP is an integrated information system built on a centralized database and having a common
computing platform that helps in effective usage of enterprise’s resources and facilitates the flow
of information between all business functions of the enterprise (and with external stakeholders).

NEED FOR AN ERP

ERP was one of the biggest revolutions in the corporate world for the last two decades. Last fifty years
have witnessed emergence of many management theories like BPR, TQM, JIT, Six Sigma, etc but none
of them had seen such widespread adoption. ERPs had given a new status to information technology. It is
no longer a support function, it is now embedded into every organisational process. ERPs have made the
position of corporate CIO mandatory for organisations implementing ERPs (most of them earlier used to
have an IT manager at the helm of affairs for taking all IT decisions). ERPs had made it possible for the
functional managers, who used to run production in factories, do selling in the market or maintain accounts
in a corporate, to move to IT, an area that was almost reserved for programmers or network engineers just
thirty years back.
While studying such changes, the obvious question which comes to our mind is why invention of the
ERP software had changed everything so drastically. It is true that invention of ERP technologies was
a milestone in itself, but in the last thirty years, organisations globally were also going through a set of
changes which made it necessary for an integrated information system and that was perhaps the reason why
ERPs had a rapid success as soon as these applications were introduced. This was not the case for lot of
emerging technologies in the past. Let us try to understand these changes in little more details.

From Department to Enterprise

Traditionally organisations are always structured around departments, i.e. sales department sell products,
production department produces them, procurement department procure items and quality department does
quality inspection. It is expected that overall organisation’s objectives will be achieved if all these individual
departments work as per their plan. However, that is not always the case as every department has their own
set of objectives and sometime these may not be aligned, i.e. one department’s objective may go against
that of another department. For example, sales department make unrealistic delivery promises (say, next day
delivery) while selling and it becomes a challenge for logistics team. Another example can be production
department wants long production runs, i.e. fewer varieties to be produced on a particular day and each
variety should have a large lot size. This reduces machine downtime and can increase production incentives
for employees at factory shop floor, but this is against what sales guys want, i.e. more varieties.
Such conflicts within departments were well known and was quite an accepted phenomenon in the
corporate sector for a long time. However, things started to change in the last three decades. Increasingly,
organisations around the world are taking an “Enterprise” view. An enterprise view means a large change
from the traditional way of looking at organisations and these are:
 ERP Overview 5

The whole enterprise has a set of objectives. Any department can not have a separate/conflicting
objective from that of the enterprise.
Objective/KPI (Key Performance Indicator) of every department is derived from organisational
objective.
The whole enterprise works like a system where each department is a part/sub-system of this. Each of
these sub-systems knows what others are doing, what is their objective/KPI and why they are doing
so.

From Function to Process

The concept of reengineering in 80s had taught organisations around the world the need for process view.
If you had ordered a company some product, it is not production or materials or sales function that deliver
you the product, but the order fulfillment process of the other organisation delivers the product to you.
This order fulfillment process cuts across several functions, i.e. orders are first taken by sales function,
warehouse function checks whether the stock for the items are available, if not then the items need to be
produced by production function, for this production if some components are needed from outside then that
need to be produced from outside and finally the goods need to be transported to individual customer by
transportation/shipping department of the company. So, this process cuts across several functions, i.e. sales,
production, procurement, warehousing, transportation, etc. If there is any delay made by any function in
the whole process, i.e. say, procurement function could deliver the components five days after the schedule,
the whole process gets delayed. It does not matter whether everyone else had done their jobs on time. This
simply proves one point that measuring efficiency of a function is not of any use, if the process as a whole
is not efficient.
Journey from function to process forced organisations around the world to realign their organisation
structure and start measuring process efficiency as a whole instead of functional KPIs. This is also one of
the reasons why ERP applications became a great success as ERPs are designed around processes and fa-
cilitates process thinking. Organisations had first redesigned their future TO BE processes for order to cash
or procure to pay and then took help of ERP to enable these processes.

From Information Silos to Integrated Information System

Traditionally before the ERP era, every department used to have their own systems. For example, procurement
department had a system for creating purchase order and vendor management; production/manufacturing
department had a system for production planning and scheduling; sales department had a system for creating
invoices and maintaining customer records; finance department had a system for financial accounting, and
human resource department had a system for payroll. Figure 1.1 explains such departmental silos which used
to be the reality before emergence of ERP systems. The major challenges of such systems were:
Duplication of data: These systems necessitates entering the same data several times in different
systems. For example, purchase department creates a vendor and material record for creating purchase
order in purchasing system, the accounts department creates the same vendor and material record once
more in accounting system for making payment. Multiple departmental systems need entering a lot of
redundant data in different systems.
No integration between these different systems: Another problem with such isolated systems is that
they do not interact with each other. However, in practice, it is not possible to run a business process
without this interaction. For example, as soon as production department makes a production plan, it
needs to communicate the procurement team what materials need to be procured to produce as per the
plan. Similarly, if the procurement department is releasing a purchase order, the store needs to know
so as to keep themselves ready to receive the material, and the accounts department needs to know
 6 Enterprise Resource Planning

Fig. 1.1 Information Silos for Different Departments

that for updating their fund projection requirements, i.e. on what date which vendor to be paid and
how much. However, if the systems are not integrated, these information exchanges are not possible
and there needs to be manual intervention at each stage. Usually, these departmental systems used to
have minimal integration at very high level in the form of summary reports, i.e. if the company’s CEO
wants to see sales vs. production vs. delivery of a selected set of products on a regular basis, a report
can be prepared by taking sales data from sales system, production data from production system and
finally delivery data from logistics system.
Systems can not update online all relevant information: Ideally, as soon as the goods are received
and stored, the inventory quantity should be updated and inventory valuation to be changed in ac-
counts system. However, these online changes are possible only when the systems are integrated. If
systems are not integrated, then at any point of time, the data most of the departments are seeing in
the system are old data and not the most recent one. The most recent order had only updated the sales
system, the production people whatever order information they have based on a old report is already
old.
Such standalone departmental information systems are “information silos” that have several issues as
discussed above, but they had served organisations for years with these limitations before the ERP changed
all these practices.
One of the greatest benefit of ERP systems is that it had broken all these information silos making in-
formation integration and seamless information flow across the enterprise a reality. For example a simple
goods receipt transaction in ERP system can trigger several activities, i.e.
Stock and value of inventory get updated
An inspection lot automatically gets created to trigger a quality inspection
Stock and consumption account updated
Purchase order history gets updated
A transfer request is created to move the goods in the warehouse
All these happen instantaneously. So, every department within the organisation (quality department, ware-
house department) knows a goods receipt has happened and the next step of action for them is automatically
triggered. It also automatically updates all relevant records, i.e. stock and inventory record gets updated,
purchase order history gets updated (so the items already received do not show in pending items list for
vendor), all consumption records get updated and so on. Figure 1.2 explains how an integrated information
system like ERP can bring all organisational functions in single database.
 ERP Overview

Fig. 1.2 Central Database and Integrated Information System

From Departmental Database to Companywide Integrated Database

As discussed earlier, ERP is about integrated information system that needs an integrated database. All
departmental databases are replaced by a single integrated relational database for the entire company. One
database provides several advantages:
No data duplication: The same data need not be entered twice by anyone in the organisation, if
someone had created a vendor, a material or a customer master record that can be accessed by the
entire organisation, provided user has proper authorisation.
Data standardisation: There is only one way of creating data in the ERP systems. For example, if a
user wants to create a new vendor or customer, some mandatory fields need to be entered in a particular
format along with some optional fields. This helps in data standardisation as it is not left to the user
that what data will be entered while creating a particular record.
Data tracking: ERP system also helps in creating data created in the system through its complete life
cycle. For example, once a purchase order is created in the system, it can be tracked whether vendor
has made deliveries against this, goods have been received, payment have been made, etc.
 8 Enterprise Resource Planning

All these are possible as ERP offers a single integrated database for the entire organisation. If the data
is going to be spread across several systems, it would be impossible to achieve these.

HISTORY OF ERP APPLICATION

Most of the ERP applications had their origin in material requirement planning (MRP) and manufacturing
resource planning (MRP II) applications. MRP applications had their origin in 60s and basically addressed
material planning problems. It was further enhanced by closed loop MRP solutions. 70s had seen the
emergence of MRP II solutions that addresses traditional gaps of MRP solutions and incorporate additional
processes like forecasting, sales and operations planning, etc. Late 70s and 80s had seen the emergence of
ERP solutions which used MRP and MRP II building blocks and encompasses every process within the
organisation. The history of this evolution is shown in Figure 1.3 and is discussed below:

Fig. 1.3 History of ERP and Enterprise Applications

Material Requirement Planning (MRP)

This is discussed in detail in Chapter 24. MRP software started answering the following few fundamental
questions for manufacturers:
Which finished products are needed to be manufactured?–MRP uses a concept called master produc-
tion schedule that answers this question.
What is the quantity of raw materials/components needed to make these finished products? – MRP
uses a concept called bill of material (BOM) that defines how much of raw material/component is
needed to make one finished product.
How much of this are available in stock? – The company’s inventory records give this information.
Inventory in hand and inventory in transit both need to be considered.
 ERP Overview 9

How much to order? – If the items are procured from vendors – MRP helps to calculate the quantity
(considering if already something is ordered) and when to place the order.
How much components/sub assemblies are to be manufactured in-house?–MRP also helps to calculate
the quantity to be manufactured in-house.
MRP was a magic solution for 60s and 70s which provided a scientific basis for production and material
planning. However, it has several restrictions like it will not able to plan looking at available capacity, it will
not able to replan quickly, it is not integrated with other organisational processes like quality management,
sales, etc.

Closed Loop MRP

This is explained in details in Figure 24.11 of Chapter 24. The biggest challenge of MRP logic is that it
goes by finished goods requirement and not look at feasibility of the plan. For example, an automobile
manufacturer’s forecasting for next year is 1000 cars, MRP tells that it need to manufacture thousand gear
boxes (assuming zero stock of gear box) and buy four thousands tires to make 1000 cars. However, if the car
manufacturer has capacity of producing only 800 gear boxes and its suppliers can supply only 3000 tires, MRP
does not bother about this reality. So, an MRP plan always needs to be validated and compared with reality
and checked with its feasibility. Closed loop MRP made it possible where an ERP plan is always checked
against available capacity and alerts/triggers are provided to the planner, if the same is not feasible.

Manufacturing Resource Planning (MRP II)

This is explained in details in Figure 24.1 of Chapter 24. MRP II extends beyond manufacturing and produc-
tion and includes processes from business planning, sales planning, forecasting, demand management, etc.
The greatest strength of MRP II is its sales and operations planning (SOP) process, i.e. it integrates busi-
ness plan, financial plan, production plan, capacity plan and material plan. Another big difference of MRP
II applications with that of MRP was that these applications were not only used for planning but also used
to help in all supply chain execution processes like creating purchase order, creating invoices and billing
document, inventory management, etc.

Enterprise Resource Planning (ERP)

Finally, ERP software started emerging in late 70s and early 80s. Whatever available as part of MRP and
MRP II applications were already part of ERP, and ERPs had much more process and functionality cover-
age than MRP and MRP II. ERPs started offering functionalities in the areas of warehouse management,
plant maintenance, quality management, service management, human resource, etc which were traditionally
not covered by MRP II. ERP applications also have capabilities of collaboration and integration with other
advanced e-Business applications like CRM, SRM, PLM, etc.
Another important difference of ERP application with MRP and MRP II applications is that unlike others
it is not restricted only to manufacturing industry and can be equally used for service business, for example,
by a bank or a utility company.
Below are few examples of how some of the ERP applications had started their journey:
1972: Five engineers in Mannheim, Germany begin the company, SAP, with the idea of producing
and marketing standard software for integrated business solutions.
1975: Richard Lawson, Bill Lawson, and John Cerullo started Lawson Software, a pre-packaged
enterprise technology solutions as an alternative to customized business software applications.
1977: Jack Thompson (J), Dan Gregory (D), and Ed McVaney (ED) formed JD Edwards.
1978: Jan Baan begins The Baan Corporation that offered leading Baan ERP for several years.
1987: PeopleSoft was founded by Dave Duffield and Ken Morris.
10 Enterprise Resource Planning

The term ERP was first officially coined in the early 1990s by the Gartner Group. Their definition of ERP
included criteria for evaluating the extent that the software was actually integrated both across and within
the various functional departments. By early nineties, SAP became the leader in the ERP market with their
killer ERP application portfolio, named SAP R/3. SAP is still the world’s largest ERP and enterprise solution
vendor and world’s fourth largest software company by revenue (after Microsoft, IBM, and Oracle).

Enterprise Applications and Industry Specific ERPs

Finally, ERP applications started moving into specialised spaces like supplier relationship management (SRM),
customer relationship management (CRM), product life cycle management (PLM), advanced planning and
scheduling (APS), etc. These spaces used to be earlier occupied by specialised vendors like Siebel, i2, Win-
chill, etc. ERP vendors started coming up with Enterprise Business Suite and Industry-specific offerings.

BENEFITS FROM AN ERP SYSTEM

This is discussed in detail in Section 2, Chapter 3. In this chapter high level business benefits from an ERP
system is covered in brief.
ERP had taken the corporate sector by storm in the last few decades. Almost every large Fortune 500
companies have today one or the other ERPs. ERPs are these days getting popular among small and medium
business sector. It’s important to understand the reason for this mad rush and why companies are going for
this.
While there can be both quantitative (where benefits can be seen in hard rupees) and qualitative reasons
for selecting ERP as detailed in Chapter 3, in most cases the qualitative reasons become more important for
justifying an ERP investment. Quantitative reasons are used later for building a business case and return
on investment (ROI) estimates. Some of these qualitative reasons that organisations traditionally used as
reasons for going for an ERP investment are shown in Figure 1.4 and are as follows:

ERP Brings Best Practices

It is, perhaps, the top most reason by which ERP investment is justified in most of the companies. We had
discussed “Best practices” in detail in Chapter 9. This is one of the greatest value addition by ERP pack-
ages, where based on experience from numerous leading companies, ERP comes up with a predefined way
of running a process. A company can quickly adapt to this. While most of the companies do huge develop-
ments to fit their processes into ERP and thereby not following ERP standard processes, it is a not a rec-
ommended approach unless and otherwise the company has a specific requirement which is not addressed
by ERP solution. For example, ERP vendors come up with predefined process for planning production in
different manufacturing environments (Make to order, assemble to order, make to stock, process industry,
etc), the company need to select the right method and try to adopt to the extent possible the corresponding
best practice.

Integration.. Integration… Integration

ERP unifies the organisation in terms of processes, data and information. This point is discussed earlier in
this chapter and importancy of this need not be reiterated.

ERP Facilitates Intra-organisation Communication and Inter-organisation

Collaboration
ERP facilitates departments to communicate to each other as discussed in this chapter. ERPs traditionally
were always known for such integration within enterprise, but of late ERPs also came up with enhanced
 ERP Overview 11

Fig. 1.4 ERP Benefits

capabilities of inter-organisation collaboration, i.e. with suppliers and partners. While ERPs today provide
such basic collaboration capabilities, other enterprise applications like SRM and CRM facilitate advanced
inter-organisation collaboration.

ERP Provides Online Real Time Information

The need for it has already been discussed in this chapter. This is a need for every organisation today with
companies want to see up to date inventory status, order book position, etc. As ERP offers one centralised
database, order entered anywhere in the organisation or any material movements at factories or distribution
centers automatically gets updated.

ERP Facilitates BPR

Business process redesign (BPR) principles helps in better TO BE process design and ERP makes it possible
to run this TO BE design. Often organisations had seen that a good TO BE process design, if not enabled
by information technology, it only remains as a process in paper and never gets executed. For example, a
good TO BE process for order management needs tool for order entry, checking availability of stock against
order, order status tracking, etc.

ERP Automates All Transaction-oriented Processes and Makes it More

Efficient
One of the main reasons why companies went for ERP is its capability to automate all regular transaction
12 Enterprise Resource Planning

processes like accounting, payroll, inventory management, creation of purchase and sales order, invoicing
etc. By automation, ERP makes these processes faster and error free. Employees working in the functions no
longer spend much time in these routine tasks and can contribute to more value adding tasks. For example,
sales guys need not spend a lot of time maintaining customer records, order entry or invoicing but can now
spend more time on their actual work, i.e. selling.

ERP Helps in Better Data Management and Reduces the Need for Data
Redundancy
This has already been discussed in this chapter earlier. ERP helps to manage data and reduces data redun-
dancy as data entered/created once in the system need not be recreated and this data is available to everyone
in the organisation.

ERP can Reduce Cash to Cash Cycle Time or Order Fulfillment Cycle Time
ERP can reduce such cycle time in different ways. For example, before ERP when every department were
using their own separate applications, if a customer calls the company to place an order for a particular
product, the sales team will first take down this information and pass on this enquiry to warehouse to check
whether the product is available. The warehouse takes a few hours to few days to confirm back that whether
the product is available. If the product is not available, the order is sent to factory for production who plan
for its production and in turn, communicate procurement team if items need to be procured to make the
item. Once the item is produced, it is communicated to sales department, a shipment plan for the order is
made and finally the order is despatched and billed by the accounts team. The whole process can take from
a few days to a few weeks depending on the complexity of the order. In an ERP world, as soon as customer
enquires about a product, the sales team can check its availability online and if it is not available in stock,
within minutes the production team knows that this need to be produced and procurement team knows what
items need to be procured to make the production happen. This automation and instant sharing of informa-
tion can reduce the cycle time of the whole process.

ERP Provides Better Flexibility

ERP offers much better flexibility than traditional home grown applications. Several scenarios can be
configured in ERP based on the way configuration is done. For example, an ERP can support different
manufacturing scenarios for make to stock, make to order, process, etc depending on the configuration.
However, home grown applications typically works in a fixed logic and if this logic has to be changed it
needs complete new programming. ERP gives the organisation flexibility, i.e. if they enter new business
tomorrow, the ERP system can be configured according to the new business need.

ERP can Provide Better Customer Satisfaction

ERP can provide better customer satisfaction by offering capabilities like online order status tracking, cus-
tomised pricing, better field service, etc. These days there is a new generation application, called customer
relationship application, that is specifically targeted to provide better customer service through capabilities
line internet sales and service, mobile sales and service, call centre, multi-channel (for example, customers
can buy in an online channel and take deliveries in a physical store), etc.

ERP Helps in Better Planning, Analysis and Decision Making

ERP provides a set of planning capability like material requirement planning (MRP), distribution require-
ment planning (DRP), capacity requirement planning (CRP), master production scheduling (MPS), sales and
 ERP Overview 13

operations planning (SOP), financial budgeting, etc. Of late, ERP vendors started coming up with specialised
supply chain planning applications. Present ERP system create lots of operational data everyday, which
can be taken up for analysis and better decision making. For example, how the sales trend is, how the new
product is performing, what about the latest promotion campaign, etc. Gradually, ERP vendors have moved
this analytic layer to a different set of application called analytic or business intelligence applications.

ERP Challenges
While ERP provides a number of obvious benefits, this is not without challenges. Several ERP implemen-
tations failed in the past as these projects could not manage these challenges well. Sometimes companies
believe that all challenges will get over as soon as the project goes live, but that may not be true in all cases.
An organisation can face several types of challenges with an ERP solution and these can fall into three dif-
ferent categories as shown in Figure 1.5 and these are:
Challenges during ERP implementation
Challenges for ongoing maintenance and operation of ERP system
Challenges of managing people

Fig. 1.5 ERP Challenges

Challenges During ERP Implementation

Behind every successful ERP implementations, there are several cases where the implementation was not
of such a success. In chapter 18, we had discussed in detail the reasons for such implementation failures.
In this chapter let’s understand few common challenges of ERP implementation.
Scope, Scope, Scope: One of the common challenges for most ERP implementations. Chapter 9
explains in details the importance of scoping and an approach for ERP project scoping (nine levers
of scoping). Several organisations do not follow any scientific method of project scoping and scopes
keep on changing during the life cycle of the project. New requirements/change requests keep on
coming even after business blueprint signs off. This is something that need to be managed effectively
by project management with support from top management to ensure project success.
Large budget and Long timeline: ERP project’s budget can run into several millions of rupees and
the project can run for several months. This poses challenges to organisations in terms of commit-
ting investment of huge financial and human resources for a long duration. Several companies had
14 Enterprise Resource Planning

underestimated ERP cost just in terms of ERP software license cost, hardware cost and consulting
charges. However, there are several other costs that need to be considered as part of it like training
cost, ongoing maintenance, cost of replacing people who had now become ERP project team member,
contingency, etc. Another challenge is that an ERP project depending on size can run between 6 and
24 months and there are global ERP implementation and rollout projects like Nestlé wenton for more
than 8 years. The organisation needs to manage their operations for such a long time without few of
its key people as they would become full time ERP project team members. It is important to keep
enthusiasm alive among team members for such a long time. For this reason several people believe
that ERP projects need to show early success, i.e. the project need to achieve low hanging benefits
early enough.
Business process redesign: Any ERP implementation involves some amount of BPR exercise and
the corresponding risks. Challenges of BPR are discussed separately in Chapter 9. It is important to
note that in earlier days several organisations used to take up a full blown BPR exercise prior to ERP
implementation and that used to increase ERP deployment time a lot. Many of such pure play BPR
initiatives failed in the past without resulting in any quantitative benefit for the organisation. Today’s
organisations mostly do not follow this approach and like to adopt an ERP-driven BPR approach, i.e.
to design the process in a way that selected ERP package can support. This reduces overall project
risk.
Unrealistic expectation and infeasible deadlines: Unrealistic expectation from ERP system is one of
the first challenges that ERP project team (especially the consulting team) faces from the organisation.
ERP is expected to solve every problem that the organisation is facing today. This sometime makes the
ERP project scoping difficult and put lot of pressure on the core team delivering the project. While it
is important to ensure that ERP provides a set of business benefits to the organisation, these expecta-
tions should be realistic and achievable. Another typical issue with ERP project is infeasible deadline
as too many things need to be achieved within too short time. The pressure is put on the project team,
the project team member gives a timeline to complete an activity, the project manager wants to crash
that to meet the project deadline and the project director wants to reduce it further. This ultimately
can cost the quality of deliverables and frequent lapses on dates.
ERP system need to interface with several other systems: While this depends a lot on how well the
project scoping is done, in several instances it becomes a challenge at the beginning of the project to
estimate how complex it is to build those interfaces and in some cases even their technical feasibility.
This may result in time and cost overrun and can impact the overall project timeline.

Challenges for Ongoing Maintenance and Operation of ERP System

ERP implementation gets over in a few months, but the application need to be supported for its entire life-
time, i.e. for several years. This include resolving issues on regular basis, applying software patches as and
when required, upgrading the application to a newer version at regular intervals, etc. An organisation can
face several challenges during this stage like:
Having right people to do the support job: Often challenges to retain people for a relatively mo-
notonous job of resolving issues on regular basis. In most cases, best people want to get into new
implementations and do not want to continue in a support role. This is one of the reasons most or-
ganisations today want to outsource their ERP maintenance job to specialised IT organisations even
if in some cases it is costlier.
Managing multiple vendors: Again a typical challenge in the support phase is that an organisation
may need to manage a separate vendor for the ERP support, another vendor for hardware support,
another for networking, etc. This sometimes becomes a challenge where to and fro of issues among
 ERP Overview 15

different vendors are common, i.e. ERP support vendor thinks that the system performance is an issue
for hardware support vendor and the hardware vendor thinks the reverse.
Managing regular upgrades: ERP vendors frequently come up with new upgrades of their package
and stop supporting older versions of the package. While upgraded version comes up with new features,
these new functionalities may not be required by the organisation all the time. However, they need to
upgrade it as ERP vendors stop supporting older versions after some time or do it at very high cost.
This is also the reasons that many companies do just a technical upgrade to ensure that their version
is supported and no functional upgrade. Each upgrade is a separate project that costs financial and
other organisational resources and sometimes there may not be any strong business reason for doing
so.
Technology obsolence and rapid emergence of new technology: Technology obsolence is one of
the biggest challenges of today. SaaS and Cloud computing are changing the model in which ERP
solutions are getting deployed without investment in hardware and software. Business requirements
which needed large developments yesterday are becoming part of the standard application today. New
models of software developments are evolving in the form of SOA (service oriented architecture).
Mobile and collaborative applications are becoming the need of the day. Organisations need to manage
such technology obsolence and emergence of new technology in an effective way to ensure smooth
transition and introduction of new technology only if there is a real business need.
Challenge of managing large application portfolios: ERP vendors over the years had come up with
several other applications for specific business needs like data warehousing applications, reporting
applications, supplier relationship management applications, customer relationship management ap-
plications, product lifecycle management applications, etc. In some cases, these applications come
from different vendors, viz. ERP from SAP, CRM from Siebel and SRM from Ariba. Managing such
application portfolio can give rise to various challenges in terms of managing multiple vendors, having
different support skills, managing different upgrade cycle and complex application interface issues.
Managing transition from implementation team to support team: Ongoing maintenance and support
of ERP system depends a lot on how effective the transition was from the implementation to support
team. As in most cases, ERP implementation and support are managed by two different teams. It is
important that support team has required knowledge transfer, document handover and transition of
open issues from the implementation team. This is discussed in detail in Chapter 19. In most cases,
support team faces challenges at least in the beginning months when the implementation team leaves
the project site within weeks of ‘Go Live’ and a new team takes the responsibility of managing the
system. This is also typically the phase when number of issues are maximum as all end users are in
the process of getting familiar with the system.
Challenges of realising benefits: Completing an ERP project in 12 to 24 months is one big challenge,
but getting real benefits out of it in the next three to five years as budgeted while building the business
case, is definitely a bigger challenge. In most cases, organisations find it difficult to measure such
benefits on a quantitative scale due to lack of data, no defined responsibility and no defined KPI to
measure process improvement. Whether ERP had really given the benefit proposed in terms of inven-
tory turn improvement? Whether order fulfillment lead time had come down? If yes then from what
earlier value to what current value?

Challenges of Managing People

Managing people in the organisation during ERP project and post-project is one of the largest challenges
the organisations face today. Managing people may mean different challenges in terms of managing large
 16 Enterprise Resource Planning

project team, managing change within the organisation, managing employee training, ensuring top manage-
ment support for the project, relocating employees for the project, having plan in place to retain ERP core
team after the project and managing their career aspirations, etc. Success and failure of several ERP projects
depend on how effectively a company could manage these things. Let’s discuss these issues in little details
in this chapter.
Managing Change: Managing change effectively decides the success and failure of an ERP project and
understanding its importance one complete chapter (Chapter 17) is devoted for this. While the basic
objective of this exercise is to take out fear from the employees and making them more comfortable
to the new way of working through a variety of measures like training, communication, etc, typically
large organisations where ERP affects life of thousands of people and organisations having significant
aged population sees a lot of resistance and challenge here.
Managing large project team: ERP projects need managing large project teams. Depending on size
of the project, the team size can vary. For large global projects, it is common to have people working
in several countries, in different languages, in different time zones and under multiple project and
programme managers. This kind of project can involve multiple vendors from onsite and offshore
(like an onsite vendor for business blueprinting, an offshore vendor for doing system programming
and developments and another third vendor for creating end user training material). Managing people
from different organisations, their interpersonal issues for a long duration project and keeping all of
them aligned towards a set of common project objectives is not a easy task – as organisations had
found in the past.
Managing employee retention and relocation: ERP project necessitate relocation of large number
of project core team people from their current location (may be current factory or sales office) to the
new ERP project office. In the similar way, their vacant places need to be occupied by a new set of
employees who will fill the gap for next 12 to 24 months, i.e. the project duration. Employee relocation
obviously brings with it a set of logistics challenges in terms of identifying new accommodation for
employees, new schools for their children, etc. There are more challenges at the end of the project, i.e.
relocation of the project team, finding new and interesting roles for them in the organisation (as by this
time their skill had become ‘Hot Skill’ and they will find good job offers in consulting organisations
or in the companies who are in the process of starting an ERP project).
Challenges of ensuring support from top management throughout the project: Top management
support is essential throughout the project life cycle though top management in any organisation has
hundreds of other priorities besides the ERP project. This support become more essential at challenging
times, i.e. before the project goes live when tons of data need to be migrated to the new application
within short time; when the system is first opened up to all end users and there is lot of resistance
from them in accepting the new way of doing work; taking hard decisions like not accepting a major
process change when the project is deep in realisation, etc.

Managing ERP Project Challenges

As discussed earlier, an ERP project can have different types of challenges and managing these challenges
effectively is quite important for the success of the ERP project. How to manage such risks and challenges
is discussed in Chapter 7. It is important to identify all such risk elements, analyse the probability of occur-
rence and impact of each one of them on overall project success, prioritising them and finally developing a
risk mitigation plan for top risk elements. Risk assessment is not a one-time process and need to be done at
regular intervals during the project life cycle as new risks may emerge with the progress of the project (for
 ERP Overview 17

example, a major milestone is missed or an important resource suddenly leaves the project). An organisa-
tion needs to have a structured approach for managing such risks and challenges and this is an important
project management task.

ERP AND ENTERPRISE APPLICATIONS—EMERGING TRENDS

Last few decade has seen enormous growth of licence revenues both for ERP (SAP, Oracle, etc) and other
enterprise applications like CRM (Siebel), SRM (Ariba), etc. Market position of different ERP package
vendors is explained in details in Chapter 5 and in Figure 5.3. While SAP and Oracle remained as market
leaders, the next slots today are occupied by The Sage Group, Microsoft Business Solution, SSA Global,
etc. Oracle had made lots of large-scale acquisitions in the past like JD Edwards and Peoplesoft (in ERP
space), Siebel (in CRM space) and Retek (a specialised ERP for retail) and this helped them to achieve
the number two slot. While Microsoft had strengthened its position over the years, its ERP solution is till
popular mainly among small and medium enterprises.
Growth of ERP vendors had also led to lots of downstream revenue for consulting companies in terms
of implementation, maintenance/support, etc. Chapter 4 discusses this in detail. While IBM and Accenture
holds the top two slots in terms of ERP consulting revenues for the last few years, there are many companies
in the second and the third tier as shown in Figure 4.3 of Chapter 4 and they are making booming business
in this field.
ERP and enterprise application space had also seen emergence of many specialised service providers
over the years. For example, there are specialised vendors who just offer ERP training. Siemens Information
Systems Limited (SISL) is such an example who offers SAP training courses globally. There are vendors
who specialise in ERP related developments or testing or ERP system security.

Emerging Trends in the Marketplace

There are few clearly visible trends in the ERP marketplace for the last few years. Few of them are as fol-
lows:
ERP vendors are coming with more enterprise applications making life difficult for nitch
vendors: ERP vendors are coming up with more and more enterprise application solutions like CRM,
PLM, SRM, SCM, etc and trying to sell these applications to their existing ERP customer base. It
has become difficult for specialised enterprise application vendors to survive and most of them are
getting taken over by large enterprise vendors. Recent takeover of Siebel CRM (who used be number
one CRM vendor) by Oracle and Business Object (who used to be number one reporting and analytics
vendor) by SAP are few such examples.
SME is everyone’s focus: As almost all large organisations today have some or other ERP in place,
ERP vendors are fighting to grab market share in SME (small and medium enterprise) space where
still there are lots of untapped opportunities. ERP vendors are increasingly coming up with specialised
offerings for these enterprises to make implementation faster, cheaper and better.
Going vertical: ERP vendors are coming up with more and more industry vertical solutions, i.e. ERP
features meeting specialised industry needs. This sometimes means taking over industry-specific
ERPs (For example, Oracle had taken over Retek, a retail specific ERP in recent times) or develop-
ing industry-specific applications (for example, SAP had built specialised industry solutions for 27
industries).
Vendor consolidation: Consolidation will continue both for ERP package vendors and ERP consulting
companies. In the past there were various examples of vendor consolidation like JD Edwards was taken
18 Enterprise Resource Planning

over by Peoplesoft and later on Oracle had taken over Peoplesoft. Similarly, in the consulting space,
Coopers and Lloyd were taken over by Price Waterhouse to make PricewaterhouseCooper (PwC) and
later on IBM had taken over PwC. The trends will continue.
New deployment models: New ERP deployment models like SaaS (software as a service) and Cloud
Computing are emerging to make ERP deployment more cost effective both in terms of hardware and
software as companies no longer need to buy them upfront. They need it when they use the applica-
tion.
Maintenance is the new focus area: Maintenance is becoming a mainstream revenue both for ERP
package vendors and ERP consulting companies. Today large ERP vendors like SAP earns more from
their maintenance revenue then new licence selling. As large organisations today spend lots of money
for maintaining their applications, this has become a new focus and ERP vendors are coming up
with specialised methodologies for maintenance (like SAP has come up with Run SAP methodology
recently) to run maintenance more efficiently.
Enterprise applications upgrade had become a booming business: Large organisations are already
running ERP and some of the enterprise applications (like CRM, SRM, etc) for few years now. ERP
vendors are coming up with new versions in every 24 to 36 months and this forces user companies
to upgrade their application after regular interval. Every upgrade is a project in itself and source of
additional revenue for consulting companies and in some cases also for hardware vendors as newer
versions need faster processing power and higher capacity servers.
There are newer type of ERP projects today – Migration, Consolidation, Harmonisation: In ear-
lier days people could think of only two (implementation and support) or maximum three (including
upgrade project) types of ERP projects. As ERP application space is getting more and more matured
new types of ERP projects are emerging for example:
Migration: Here the company moves from one ERP or enterprise application to another. For
example, from JD Edwards ERP to SAP ERP, from Peoplesoft ERP to Oracle ERP, from BAAN
ERP to SAP ERP, from Siebel CRM to SAP CRM, from Ariba SRM to SAP SRM etc. In most
cases, the driver for such migration is the old ERP vendor got sold, not in a position to provide
proper support or the company believes it is risky to run an ERP of a company which is not
financially stable (for example, BAAN) and make sense to move to some stronger ERP vendor
(say, SAP).
Consolidation and Harmonisation: In this case a company having ERP running on different
versions on different landscape, hardware, etc wants to consolidate and move to one ERP instance
and a single landscape to reduce overall maintenance cost and to get benefit out of integration.
This is very common among large enterprises where different countries and businesses had
implemented ERP at different point of time and over the years, the application landscape had
become extremely complex and the company wants to consolidate the landscape.

ERP—A SUBSET OF ENTERPRISE APPLICATIONS

This book is on enterprise applications and ERP is a subset of that. The concept of ERP and enterprise ap-
plications is shown in Figure 3.3 of Chapter 3. ERP covers all basic transaction modules of an organisation
like finance, sales, distribution, procurement, inventory, quality, etc. and enterprise applications goes much
beyond that. While ERP is also one of the enterprise applications, examples of other enterprise applications
are:
Supplier relationship management (SRM)
Customer relationship management (CRM)
 ERP Overview 19

Product lifecycle management (PLM)

Supply chain management (SCM)
Along with ERP, this book also discusses all other enterprise applications as increasingly ERP vendors are
widening their footprint in these applications and more and more organisations who have some ERP in place
are implementing these solutions.

Summary
This chapter explains the concept of ERP, its history, benefits, and challenges.
ERP is an integrated information system built on a centralised database that helps in effective usage of
enterprise’s resources and facilitates flow of information between all business functions of the enterprise and
with external stakeholders.
In the past, there were four major drivers for companies to move to enterprise information systems and they
were: Moving from department structure to enterprise structure, journey from function to process, from
information silos to integrated information system and finally from departmental database to companywide
integrated database.
ERP applications had their history in MRP, closed loop MRP and MRP II applications. Finally ERP applica-
tions today are moving towards enterprise applications, a set of other applications (PLM, SRM, SCM, CRM,
etc) beyond ERP. This book focuses not only on ERP, but also on all these enterprise applications.
ERP benefits business in a number of ways like bringing best practices, online real time information, infor-
mation integration, automation, better data management, facilitating BPR, reducing cash to cash cycle time,
better customer satisfaction, etc.
ERP also provides a set of challenges during implementation, support and a set of people challenges. Imple-
mentation challenges can be in terms of scope creep, huge budget, long implementation time, interface
building with lots of other applications, business process redesign, etc. Operational challenges fall into things
like managing multiple vendors, managing upgrade, technology obsolence, managing migration and realising
benefits. Finally, people challenges can be: change management, top management support, employee reloca-
tion, etc.
Emerging trends in ERP space are: specialised solution for SME, industry-specific solutions, focus on upgrade,
migration and consolidation projects, new generation deployment models like SaaS and vendor consolida-
tion.

Exercise
I. Objective Type Questions
1. Give a definition of ERP.
2. What were four major drivers of ERP revolution in the last four decades?
3. What is the difference between department view and enterprise view of the organisation?
4. How is process approach different from functional approach?
5. How is integrated information system better than departmental information silos?
6. What are the three major challenges of information silos?
7. What is MRP?
20 Enterprise Resource Planning

8. How is closed loop MRP different from MRP?

9. What is MRP II?
10. What are enterprise applications?
11. What are best practices?
12. How does ERP reduce cycle time of operation?
13. What are the three major categories of challenges for ERP?
14. What is meant by ERP upgrading?
15. What is meant by “Going Vertical” for ERP vendors?

II. Descriptive Type Questions

1. What is meant by “enterprise”, “resource” and “planning”?
2. Explain why a “process” approach is better then “functional” approach.
3. Explain the major disadvantages of individual departmental information systems.
4. How does ERP facilitate simless information flow? Explain this with an example.
5. What are the advantages of a corporate wide integrated database?
6. How MRP systems work? What fundamental problems do they solve for manufacturers?
7. What are the additional processes included in MRP II over MRP?
8. What are the ten business benefits of ERP system?
9. What are the ERP implementation challenges?
10. What are the people related challenges in ERP project?
11. Explain the issues related to ERP maintenance and support.
12. Explain some of the emerging trends in ERP market.

III. Fill in the Blanks

1. ERP stands for _______________ _____________ _______________.
2. MRP stands for _______________ _____________ _______________.
3. MRP II stands for _______________ _____________ _______________.
4. PLM stands for _______________ _____________ _______________.
5. CRM stands for _______________ _____________ _______________.
6. SCM stands for _______________ _____________ _______________.
7. SRM stands for _______________ _____________ _______________.
8. SOA stands for _______________ _____________ _______________.
9. SaaS stands for ________________ ______ ____ _______________.
10. BPR stands for _______________ _____________ _______________.
11. TQM stands for _______________ _____________ _______________.
12. JIT stands for _______________ _____________ _______________.
13. SOP stands for _______________ _____________ _______________.
14. APS stands for _______________ _____________ _______________.
15. B2C stands for _______________ _____________ _______________.

IV. State Whether the Following Statements are True or False

1. MRP stands for Manufacturing Resource Planning.
2. BPR stands for Business Process Redesign.
3. SOA stands for Sales Oriented Architecture.
4. Closed loop MRP checks feasibility of the MRP plan.
5. Enterprise application is a subset of ERP.
 ERP Overview 21

V. Assignments
Study a company (from primary or secondary sources) which had recently gone for ERP implementation. What
are the business benefits they achieved through ERP? What are the challenges they faced during the implementa-
tion and after the system had gone live? What lessons they learnt from the ERP project?
 Section

Implementation
and Support
 SECTION INTRODUCTION

ERP LIFE CYCLE:

IMPLEMENTATION AND SUPPORT
Enterprise Resource Planning applications have a long life cycle from the point a company plans to imple-
ment such a solution, budgets for it, selects the right package, selects the consulting partner, start the actual
implementation, become operational with it and finally starts using it for day-to-day life when the application
need to be supported. ERP life cycle is about all these activities. In most cases, such life cycle is divided into
particular phases and name of the phases may differ as per implementation methodology adopted. However,
most of the methodologies divide such life cycle in phases like:
Pre-implementation
Project preparation
Business blueprinting
Realisation
Go Live preparation and Go Live
Support
Pre-implementation activities start before the start of actual implementation and may involve things like
first putting together a team for carrying out activities in this phase. This is followed by developing a business
case for the project, i.e. approximate cost and projected benefits calculation for ERP deployment. Chapter 3
discusses this. The next logical step in this stage is selecting the consulting partner for implementation based
on a set of defined criteria. Some organisations use RFP route for partners selection. The partner selection
process is discussed in Chapter 4. Implementation partner selection is followed by ERP package selection.
This is one of the most important activities in the ERP life cycle and need to be done with lot of care for
the success of the project. The process is discussed in Chapter 5.
Project preparation is the set of activities that is done when the actual ERP project starts. The phase
will start with the formation of a project team composed of company’s own core team and consulting team
members. It’s important to set up project organisation structure and also reporting relationships at this phase.
Project team formation is discussed in Chapter 6. This is also the phase where all project management stan-
dards are established, project vision/mission statements are worked out, project charter is prepared, project
scope is finalised, and project planning is completed. ERP project management fundamentals are discussed
in detail in Chapter 7.
The next phase in the ERP project life cycle is called Business Blueprinting. Blueprinting typically starts
with identifying a set of business requirements/expectations from ERP. This requirement definition can be
very granular or at high level depending on the organisation, and the process is detailed in Chapter 8. One
of the most critical activities in Business Blueprinting is Business Reengineering where a better TO BE
process is designed based on BPR principals reducing non-value adding steps, reducing handoffs and taking
care of user’s future expectations/pain points. This is covered in Chapter 9. Business blueprinting phase
also involves process modelling of AS IS and TO BE processes. Process Modelling is discussed in detail in
Chapter 10. Finally, Business Blueprinting involves Gap identification i.e. gaps between TO BE Process
models and what standard ERP can offer. These gaps need to be documented and analysed and strategies to
bridge these gaps need to be developed. This is covered in Chapter 11.
 Section Introduction 25

Realisation phase of the project is the phase where the system is built through configuration, development,
and testing as per the customer’s requirement and TO BE design as finalised during Business Blueprint
phase. Configuration and customisation of the ERP system is done to suite the business requirement of a
particular company. This is discussed in Chapter 12. Once the configuration is done, the system need to
be thoroughly tested before handing over to end-users. There can be different levels of testing required i.e.
functionality testing (also known as Unit testing), end-to-end scenario testing (also known as Integration
testing), testing by a business user (also known as user acceptance testing), and Volume-Stress testing. These
are discussed in Chapter 12. It is important to control which users will use the system and what type of
transactions they are allowed to do in the system. This authorisation and system security related issues are
discussed in Chapter 13.
Training is a very important activity in ERP life cycle. First, company’s core team members need to be
trained so that they can understand ERP’s functionalities and can do system configuration; at the later stage,
all end-users need to be trained so that they can use the system effectively. Training does not end as the ERP
project goes live and this is an ongoing activity as always new users get added, new ERP functionalities
come with newer version etc. ERP projects involve a lot of planning for training content building, trainers,
training logistics, training schedule, venue for trainings etc. These are discussed in Chapter 16.
After realisation, the preparation for Go Live starts. Go Live preparation involves data migration, cutover
planning and pre go live audit. Data migration means migrating all master data and open items from the
legacy application to the new ERP. Data need to be cleaned and validated by business users before load-
ing. Data migration is discussed in Chapter 14. Before moving from the old system to the new system,
every activity need to be planned in detail. This process is known as Cut Over-planning and is discussed
in Chapter 15. Finally, before Go Live, it is important that a set of external experts verifies that whether
the company is really ready for Go Live or this need to be differed. The discussion on such Go Live audit
is also part of Chapter 15.
Managing change is an important issue during ERP project life cycle as ERPs can cause lot of uncertainity
and fear among user community making its acceptance a bigger challenge. The most advanced ERP system
implemented by the best consulting company is of no use if finally users do not use it. Chapter 17 discusses
this critical issue of change management. Chapter 18 discusses the reasons for success and failure of an
ERP implementation.
Once the system Go Live, the support phase starts. Typically just after Go Live, there are more issues
and it takes time before the system finally stabilises. It is important to have proper knowledge transfer to
the support team as in most cases implementation and support teams are different. This process is called
Transition and involves transfer of knowledge, documents, and open issues to the new team. Transition is
discussed in Chapter 19. Regular support needs monitoring of service level agreements (SLAs) between
business and the support team so that an issue is resolved within agreed time frame. The concept of SLAs
is discussed in Chapter 19. Finally, the option of upgrading the ERP system to the next version needs to
be evaluated after regular intervals to avail advanced functionalities.
 2
ERP Implementation:
Life Cycle, Methodologies Chapter
and Strategy

Learning Objectives
In this chapter we will discuss the following concepts:
ERP Life Cycle: Activities, Deliverables, and Milestones in Pre-implementation; Project Prepara-
tion; Business Blueprinting; Realisation; Final Preparation and Go Live; and Support
Methodology of Implementation: Why you need a methodology; Methodology from ERP
Vendor–ASAP from SAP; Methodology from consulting company–Ascendant from PWC IBM;
Different Methodologies for different types of ERP projects; ERP implementation methodology for
small and medium business.
Implementation Strategies:
Different ERP implementation strategies.

ERP LIFE CYCLE

ERP implementation life cycle talks about all the activities needed in an ERP project. While these activities
need to be undertaken in a particular sequence, some of them can be carried out parallely. Activities during
ERP implementation can be divided into different phases. Names of these phases differ as per implementa-
tion methodology selected. For example, leading ERP vendor SAP’s implementation methodology ASAP
(described later in this chapter) divides the entire ERP project implementation activities into five different
phases known as: Project preparation, Business Blueprinting, Realisation, Final Preparation and Go Live,
and Support. However, in this chapter, we had added one more phase before project preparation known as
Pre-implementation which details some of the activities needed even before the project starts. Some consult-
ing companies name Business Blueprinting phase as “Design phase”, Realization phase as “Build Phase”
and Support phase as “Manage Phase”. For example, leading ERP consulting company, IBM, has an ERP
implementation methodology called “Ascendant” in which Pre-implementation phase is called “Evaluation
phase” and Support phase is known as “Sustain phase”. While as per different methodologies of different
ERP vendors, the name of these six phases may differ a bit, the activities in each phase is almost same for
any ERP implementation.
28 Enterprise Resource Planning

ERP support cycle talks about all the activities that need to be undertaken during ERP support. So, an
ERP life cycle consists of both implementation and support activities.
ERP life cycle = ERP implementation life cycle (Activities during ERP implementation project)
+
ERP support life cycle (Activities during ERP support)
Figure 2.1 lists the implementation and support activities of ERP life cycle.

Pre-implementation Phase
ERP implementation is a big investment for any company both in terms of time and cost. So, any such
initiative needs meticulous planning. The phase in which planning activities are undertaken before actual
implementation is called “Pre-implementation Phase”. For some companies, this phase may start years before
the start of actual implementation phase. Planning complexities may differ from one organisation to another,
based on size of organisations. For example, planning for a multinational conglomerate having different
lines of business, operations in multiple geographies and having number of factories and distribution centres
will be very different from a company having operation in one country, a single factory and few distribution
centres. Nevertheless, the major activities in this phase are almost same for all organisations.
Pre-implementation Phase–Activities Figure 2.1 shows activities for this phase. These activities
are also listed in Table 2.1 below:

Table 2.1 Pre-implementation Phase Activities

Line No. Activity Sequence

No.
1 Have a crack team in place (for few initial steps in ERP journey) 1
2 Feasibility study / ROI analysis / Business case 2
3 Getting budget for ERP implementation 3
4 High level requirement definition, prioritisation of requirements 4
5 High level scope definition 4
6 Request for proposal (RFP) for implementation partner selection 5
7 Evaluation and selection of consulting partner for implementation – Contract with 6
consulting partner
8 RFP for package selection 7
9 Evaluation and selection of ERP package–Contract with package vendor 8

Brief Description of Activities

Having a Team in Place First step is to identify a person or a small crack team of fairly senior people
in the organisation who will lead during the first few steps of company’s ERP journey. This is not the ERP
implementation core team, but a team which make the organisation ready for ERP in terms of getting the
necessary budget approval, selecting the consulting partner, identifying the business requirements for the
company at high level, selecting the core team for implementation, etc. Typically in small companies, IT
Fig. 2.1 ERP Life Cycle—Implementation and Support Activities
ERP Implementation—Life Cycle, Methodologies and Strategy
29
30 Enterprise Resource Planning

head or senior member from the IT team handles this though ideally someone from IT department should
not be the first choice as ERP projects are not IT projects. Some companies recruit people from outside
having similar experience for this role.
Feasibility study/ROI Analysis/Business Case This involves getting the approximate cost and projected
benefits calculated by deploying ERP. This needs to be quantified, i.e. savings need to be projected in Rs.
X crore and cost of Rs. Y crore with solid justification to convince top management to make an investment.
However, the business justification need not be always quantitative, especially when company’s customers
had mandated ERP systems. For several suppliers who supply products to leading auto makers or leading
retailers in the U.S. and Europe—the customers expect their suppliers on a leading ERP that supports EDI,
electronic payment, demand collaboration, etc. In such cases business justification may become simple. This
is discussed in detail in Chapter 3.
Getting Budget The next important activity is to get the budget approved for the project from senior man-
agement, based on the cost and benefit projections. Sometimes budget approval is a lengthy process running
into several months. However, it mainly depends on how simple and convincing are the cost calculation
and benefit projections.
High Level Requirement Definition, Prioritisation of Requirements The next step is to identify a complete
list of requirements and expectations from an ERP system. This activity can be done by an internal team
and, in some cases, the company can engage an external consulting team to do this. Some companies want
to by-pass this step. However, it is always recommended to spend some time on this as it helps understand
what the company is actually looking for in an ERP solution without being confused by the features and
functionalities of different packages. Time to be spent in this step will depend on the amount of granularity
you want. For example, you can tell that you are looking for procurement functionality in an ERP solution
or you can get into the next level and tell that you are looking for a procurement solution which can sup-
port e-Procurement functionality or you can go to the third level and tell that you are looking for a solution
which can support e- Procurement functionality for direct materials having strong integration with planning
function. Obviously, when you become more granular to define your requirement, it takes more time and
needs involvement of more people from the business. Requirement definition is detailed in Chapter 8.
High Level Scope Definition This step defines where to implement the ERP and where not to; which pro-
cesses should be taken and which should not be; which modules are relevant and which are not; etc. Scope
definition is detailed in Chapter 7.
RFP for Selection of Implementation Partner and Evaluation and Selection of Consulting Partner This
step involves request for proposal (REP) for selection of implementation partners, and evaluation and selec-
tion of consulting partner as well as contract with the consulting partner. In this stage, RFPs are released to
different consulting companies to submit quotation giving a list of requirements and scope. The responses
are evaluated on different criteria and finally the consulting partner is selected. Then the company enters
into a contract with the consulting partner. This is detailed in Chapter 4.
RFP for Evaluation and Selection of ERP Package These are activities related to releasing RFPs to dif-
ferent ERP vendors to submit quotation giving a list of business requirements. The responses are evaluated
on different criteria and finally the package is selected. Then, the company enters into a contract with the
ERP package vendor. This is detailed in Chapter 5.
Number of Activities and their Sequence can Change Depending on the Type of Project It’s important
to understand that it is not mandatory that a company need to follow all these steps for starting an ERP
 ERP Implementation—Life Cycle, Methodologies and Strategy 31

implementation. It is also not important that the activities happen in the same sequence as mentioned. Though
the first step is always to have a business case and get fund for the project, the further steps may vary and
there can be different models for executing these steps. Some instances are:
A company may decide that it will get its ERP implementation done by a group company and do not
need partner selection part (For example, a Tata group company decided to engage TCS for its ERP
implementation. Similarly, ITC engaged ITC Infotech for implementing an enterprise solution).
Few companies may skip package selection. For example, a company may decide to go for SAP with-
out doing any package evaluation and selection exercise because all their group companies are on the
same solution or their customers had asked them to go for a particular ERP or they got a very good
deal from the package vendor for buying licenses in volume for all their group companies together.
Typically, it makes sense to have the entire group on the same ERP platform as that brings a lot of
benefit in terms of easy dataflow within group companies, easier financial consolidation and better
reporting. Many companies usually decide not to release a formal RFP for vendor or package selec-
tion.
A company may choose to have two different consulting partners – one for identifying their busi-
ness requirements, scoping the project, package selection and then releasing the RFP, and another for
implementation.
There can be several consulting partners to be chosen for implementing the ERP– one onsite consulting
partner for business blueprinting and package configuration, one offshore partner for development,
one service provider for carrying out all the training related activities during the project, etc.
Pre-implementation Phase—Critical Deliverables Pre-implementation phase need to have a set
of deliverables from the core team and the consulting team (if a consultant is engaged for this) to help the
company during this phase. Some of the critical deliverables of this stage are as shown in Figure 2.2 and
these are:
Business case
High level requirement document
High level scope document
RFP for consulting partner selection (optional)
RFP for ERP package vendor selection (optional)
Contract with consulting partner
Contract with ERP package vendor
Pre-implementation Phase—Major Milestones Major milestones of project preparation stage
are:
Acceptance of business case by the senior management of company and sanctioning of budget for the
project;
Identification of high level scope and requirements;
Release of RFP for consulting partner and ERP vendor;
Completion of contract procedures for consulting partner and ERP vendor

Project Preparation Phase

The purpose of this phase is to provide detailed initial project planning and preparation for the project. This
is a critical stage of the project and the project success depends much on right performance of certain steps
at this stage.
Fig. 2.2 ERP Life Cycle—Deliverables
32
Enterprise Resource Planning
 ERP Implementation—Life Cycle, Methodologies and Strategy

Project Preparation Phase–Activities Figure 2.1 shows activities for this phase. These are also
listed in the Table 2.2 below:

Table 2.2 Project Preparation Phase Activities

Line No. Activity Sequence No

1 Project team selection (core team and consultants) 1
2 Detailed project scoping 2
3 Project vision/mission statement creation 2
4 Deciding implementation strategy, methodology to follow 2
5 Finalising project methods, standards and governance 2
6 Technical preparation 2
7 Project planning, resource planning, training planning 3
8 Project charter preparation 4
9 Conducting project kick off meeting 5
10 ERP overview training to senior management, ERP process training to core team 6

Brief Description of Activities

Project Team Selection (Core Team and Consultants) This activity involves selection of company’s own
people for the core team and selection of consultants from the consulting partner company for the project. This
also involves having the project organisation structure in place. This is discussed in detail in Chapter 6.
Detailed Project Scoping This activity relates to identification of detailed project scope around nine levers
like location, business, process, application, interface, reports, data migration, user technology, etc. This is
discussed in detail in Chapter 7.
Project Vision/Mission Statement Creation Long term vision and mission statement being the basic driving
factors for the project need to be articulated as an activity of the project preparation phase. This is discussed
in detail in Chapter 7.
Deciding Implementation Strategy, Methodology to Follow This activity is about deciding which implemen-
tation strategy to adopt – whether Big Bang makes sense or is it OK to go with a phased rollout strategy.
This also involves deciding which implementation methodology to follow among different options available;
like vendor’s implementation methodology (Example: SAP’s ASAP) or consulting company’s methodology
(Example: IBM’s Ascendant). Implementation strategy and methodology are covered in Chapter 2.
Finalizing Project Methods, Standards and Governance This is an important activity during the project
preparation phase. Processes need to be established, and templates need to be frozen so that they could be
used by all project team members during the entire project period. This is covered in Chapter 7.
Technical Preparation This activity includes preparing application landscape strategy, developing solution
architecture, hardware sizing, etc.
34 Enterprise Resource Planning

Project Planning, Resource Planning, and Training Planning Planning for the entire project, sequence and
duration of activities, start and end dates of the project need to be done during this phase. Project plan is
followed by a resource plan, detailing who will be assigned to which task and how many people are needed in
which month/week. A high level training plan also needs to be developed at this phase. Project and resource
planning is discussed in detail in Chapter 7 while training planning is discussed in Chapter 16.
Project Charter Preparation Project charter is a document that details project mission and vision, scope,
business case, project plan, project team details and project assumptions and constraints. This is discussed
in detail in Chapter 7.
Conducting Project Kick off Meeting Project kick off meeting is a formal meeting to launch the project
where the project charter is presented and the team is introduced.
ERP Overview Training to Senior Management, ERP Process Training to Core Team A high level ERP
overview training explaining what the ERP is all about, the modules and the processes of the ERP, and the
changes it would bring in need to be explained to the senior management. This can be a half- or one-day
training programme. A detailed training, covering ERP processes, need to be imparted to the core team so
that they can understand properly the processes and best practices of the ERP. This help them do the next
phase of the project, i.e. Business Blueprinting effectively. Training can be given either by the ERP vendor
or by the consulting company.
Project Preparation Phase—Critical Deliverables Project preparation phase need to have a set of
deliverables from the core team. Some of the critical deliverables of this stage shown in Figure 2.2 are:
Detailed project scope document
Project vision and mission statement
Technical architecture document
IT landscape strategy document
Hardware sizing document
Project plan
Resource plan
Training plan
Project charter
Project Preparation Phase—Major Milestones Major milestones of project preparation stage
are:
Signing off the detailed project scope by the project sponsors;
Staffing the project team to support the Business Blueprint Phase;
Completing project strategies and getting them signed off by the project sponsors;
Holding the project kick-off meeting; and
Putting the steering committee and project team in place.

Business Blueprinting Phase

The purpose of the Business Blueprinting or Design phase is to have detailed initial project planning and
make preparations for the project. The document prepared in this phase describes in detail the company’s
business functions and define technical requirements to enable those business functions.
Business Blueprinting Phase—Activities Figure 2.1 shows activities of this Phase. These activities
are also listed in Table 2.3.
 ERP Implementation—Life Cycle, Methodologies and Strategy 35

Table 2.3 Business Blueprinting Phase Activities

Line No Activity Sequence No

1 High level process modelling of AS IS process 1
2 Developing detailed requirement definition (conducting workshops, knowing pain points, 2
current process improvement areas)
3 Business process reengineering 3
4 Detailed process modelling of TO BE process, design process steps 4
5 Gap identification and analysis, and strategy to bridge the gap 5
6 User authorisation, roles and security planning 5
7 Blueprint audit by external team 6
8 Getting blueprint signed off 7
9 ERP configuration training to the core team 8

Brief Description of Activities

High Level Process Modelling of AS IS Process This activity involves modelling current processes of the
company at high level. The purpose of this is to understand the process at high level without going deep
into details as these processes will be discontinued. This is covered in Chapter 10
Developing Detailed Requirement Definition This activity identifies a complete list of requirements and
expectations from the ERP system. For this activity there is the need for understanding current pain points
and improvement areas of current process which is done through a series of business process workshops.
This is discussed in Chapter 8.
Business Process Reengineering (BPR) One of the most critical steps in this phase is to design a better
process based on BPR principles like reducing non-value adding steps, reducing handoffs etc. The process
should take care of user’s future expectations and should be based on his current pain points. This is dis-
cussed in Chapter 9.
Detailed Process Modelling of TO BE Process, Design Process Steps This involves detailing the TO BE
processes of with detailed process definition document that enumerates new process models, process steps
and input-output relationships. This is discussed in Chapter 10.
Gap Identification and Analysis, and Strategy to Bridge the Gap There will be always gaps among TO BE
process models, customer expectations and what standard ERP can offer. These gaps need to be documented,
and analysed. The strategy to bridge these gaps also needs to be developed. There can be different ways to
address the gap like complimentary solutions, customisation or enhancements in the solution, developments,
etc. This is discussed in Chapter 11.
User Authorisation, Roles and Security Planning This involves planning for which users will use the
system, the kind of authorisation profile they will have, the roles they will have to play, etc. This is discussed
in Chapter 13.
Blueprint Audit by External Team It is important that the business blueprint is reviewed by a set of expe-
rienced consultants. In some cases, the company may like to get this review done by the product vendor or
another independent consultant. Business blueprint audits/quality reviews can suggest as to whether some
36 Enterprise Resource Planning

development requests can be addressed by standard ERP solution, whether some of the process designs can
be made better to meet business objectives, etc. It is always good to have this before the blueprint ends.
Getting Blueprint Signed Off Blueprint can formally close with signing off the blueprint by the process
owners from the company side. Ideally, this should freeze the requirements, i.e. the requirements should not
change further in the rest of the project life cycle. However, practically changes will keep coming during next
phases and a valid change request detailing the need and impact of the change needs to be considered.
ERP Configuration Training to the Core Team A training covering ERP configurations need to be given
to the core team so that they understand how the system needs to be configured. This training grooms them
for the next phase of the project i.e. Realisation phase. Training can be imparted either by the ERP vendor
or by the consulting company.
Though this is the common approach for business blueprinting, the approach can differ depending on the
project. There are companies which do not want to spend much time on AS IS modelling as any way those
processes would be replaced. There are companies which do not want to spend time in process redesign and
will go ahead with ERP-defined processes. Small companies which can not afford much time and money for
the business blueprint may go ahead spending a few weeks for blueprinting and shortening drastically the
time for AS IS modelling, redesign, etc. However, it is important to remember that the business blueprint
is the foundation of a good solution implementation and more time spent on designing the solution often
works out to be beneficial for the overall project implementation.
Business Blueprinting Phase—Critical Deliverables Business blueprinting phase need to
have a set of deliverables from the core team. Some of the critical deliverables of this stage are shown in
Figure 2.2. These include:
AS IS Model (High level)
Detailed requirement document
TO BE process definition document
Gap document
Authorisation plan
Detailed business Blueprint document covering TO BE processes, gap areas, enhancements, interfaces,
roles, authorisations, etc.
Business Blueprinting Phase—Major Milestones Major milestones of this stage are:
Signing off the business blueprint document by the project sponsors;
Freezing the business requirements;
Agreeing jointly to the gap document by the company and the consulting team;
Completion of the authorisation plan;
Completion of blueprint audit.

Realisation Phase
The purpose of realisation phase is to build the system through configuration and its development to the
specifications of the business and process requirements documented in the business design/blueprinting
phase. The main purpose of the realisation is to verify that the system is complete, stable and ready for be-
ing transferred into production. Realisation, therefore, involves designing, building and testing the solution,
and making it ready for production.
Realisation Phase—Activities Figure 2.1 shows the activities for this phase. These are also listed in
Table 2.4.
 ERP Implementation—Life Cycle, Methodologies and Strategy 7

Table 2.4 Realisation Phase Activities

Line No Activity Sequence No

1 Configuration/Customisation 1
2 Unit and integration testing 1
3 Developments for gaps 1
4 End user training plan 2
5 Integration test sign off 2

Brief Description of Activities

Configuration/Customisation Configuration or customisation is an important activity in the realisation
phase to make the ERP system suit business requirements of the company. Configuration can be divided
into baseline configuration and final configuration. Configuration document is an important deliverable for
ERP project. This is discussed in Chapter 12.
Unit and Integration Testing The system need to be thoroughly tested before handing over to the users.
Testing is done at different stages. Unit testing is done to ensure a particular transaction or a particular
functionality (a unit of the software) is working. Integration testing ensures proper working of a complete
end to end scenario. This is discussed in Chapter 12.
Developments for Gaps For meeting the gaps and building the required functionality in any project, there
will always be some programming/development. While care need to be taken that there is no source code
modification, some extra coding is unavoidable during every implementation. This is discussed in Chapter
11.
End user Training Plan This involves planning for preparation of training modules, location of trainers,
arrangement of training logistics, fixing of training schedule and venue for trainings, etc. For a large com-
pany having thousands of end users, this can be a mammoth task and may need a full-time training manager.
This is discussed in Chapter 16.
Integration Test Sign Off This means integration test is completed as per the satisfaction of the company
and all the scenarios are working as expected. This is a major milestone for the project and typically as-
sociated with a payment schedule for the consulting partner, i.e. 20% of the overall consulting fee will be
paid once the milestone of integration test sign off is completed.
Realisation Phase—Critical Deliverables Realisation phase expects a set of deliverables from the
core team. Some of the critical deliverables of this stage are shown in Figure 2.2 that includes:
Configuration document
Test strategy and test plan
Unit test scripts
Functional and technical specifications for developments
Data migration strategy document
End user training materials
Integration test sign off scripts
38 Enterprise Resource Planning

Realisation Phase—Major Milestones Major Milestones of this stage are:

Completion of all configurations;
Completion of all developments;
Completion of all Unit and Integration testing;
Signing off integration test by the business;
Completion of end user training content development.

Final Preparation and Go Live Phase

Realisation phase is followed by Final Preparation and Go Live phase. Purpose of this phase is to make the
system ready for final D Day, i.e. the day of Go Live. On successful completion of this phase, the company
is ready to run its business in the new productive ERP system.
Final Preparation and Go Live Phase—Activities Figure 2.1 shows activities for this phase.
These are also listed in the Table 2.5.

Table 2.5 Final Preparation and Go Live Phase Activities

Line No Activity Sequence No

1 Stress and volume testing 1
2 User acceptance testing and user sign off 2
3 Conducting end user training 3
4 Data migration—Migrating open items 3
5 Cut over planning—Preparing Go Live checklist 3
6 Help desk support finalisation 3
7 Closing open project issues 3
8 Pre-Go Live audit by an external team 4
9 Going Live 5

Brief Description of Activities

Stress and Volume Testing This testing is done to ensure that the system can handle the real life transaction
volumes without affecting system performance (For example, a system performance issue can take long time
when volumes are high as lot of jobs are in the queue). This is discussed in Chapter 12.
User Acceptance Testing and user Sign Off End user acceptance testing to authenticate that the system is
performing as expected by final users. Typically end users are expected to give a sign off for new system.
This is discussed in Chapter 12.
Conducting End user Training Training of all the end users in new processes, new system transactions,
new way of working and how they need to carry on their daily activities in the system once the system goes
live. Typically this training is handled by the core team, i.e. company’s own people following “training of
the trainer” approach. As discussed earlier, it can be a mammoth task if there are large numbers of end us-
ers. This is discussed in Chapter 16.
Data Migration—Migrating Open Items This involves migrating all master data and open items (like
purchase order, sales order, contracts, etc) from the legacy application to the new ERP. It needs to be
 ERP Implementation—Life Cycle, Methodologies and Strategy 39

ensured that data is cleaned and validated by business users before loading. As the data is voluminous, some
automation of this activity is expected. This is discussed in Chapter 14.
Cut over Planning—Preparing Go Live Checklist For moving from old system to new ERP application,
activities need to be planned in minute details. Transactions need to be stopped in the old application for
a brief period and moved to new. This is known as Cut Over Planning. The day a company moves from
the old legacy system to the new ERP application is called “Go Live” date. A detailed checklist need to be
prepared to list all the activities that are expected to be completed before “Go Live” and to track them to
ascertain as to whether the same are completed or not. This is discussed in Chapter 15.
Help Desk Support Finalisation A round the clock Help Desk need to be planned before the system goes
live because, the users may face difficulties/problems that need speedy resolution.
Closing Open Project Issues Ideally, a company should complete all its ERP project related activities before
“Go Live”, though in most cases projects go live with a number of open issues. However, it is important to
ensure that before “Go Live”, all critical project activities are completed.
Pre Go Live Audit by External Team It is important that a set of external experienced consultants review
as to whether the company is really ready for the ERP application. In some cases, the company may like
to get this review done by the product vendor itself or by another independent consultant. Sometimes, the
audit report recommends to postpone the go live date in view of non closure of too many critical issues.
This is discussed in Chapter 15.
Going Live Finally the D Day comes. The company moves from the legacy application to the new system.
From this day all transactions are made in the new system.
Final Preparation and Go Live Phase—Critical Deliverables This phase expects a set of de-
liverables from the core team. Some of the critical deliverables of this stage are shown in Figure 2.2 which
includes:
End user acceptance testing document
Stress and volume test result
Cut over plan
Go live checklist
Help desk support plan
List of open project issues
Technical operation manual for end users for running the system
Go live audit report
Final Preparation and Go Live Phase—Major Milestones Major Milestones of this stage are:
Satisfactory stress and volume testing results
Completion of data migration
Completion of cut over planning
Putting the go live checklist in place and completion of all activities as per the checklist
Closing all critical open issues
Submission of satisfactory go live audit report
Going live with the new system.

Support Phase
Support phase starts when the ERP system goes live. This phase supports the ERP implementation and
evaluates its upgradation to the next version.
40 Enterprise Resource Planning

Support Phase—Activities Figure 2.1 shows activities for this Phase. These activities are also listed
in Table 2.6.

Table 2.6 Support Phase Activities

Line No. Activity Sequence No.

1 Knowledge transfer to support team 1
2 Transition of project documents and open issues 1
3 Regular support, monitoring service level agreements (SLAs) 2
4 Measuring performance improvement 2
5 Upgrading to next version of ERP 3

Brief Description of Activities

Knowledge Transfer to Support Team The implementation team and the support team may not be the same.
From core team side while some of company’s own team members may continue after implementation with
the support team and from consulting side there may be a new consulting company who had been offered
the support contract. So, it is important that knowledge of business processes configured in the system, gets
transferred from the implementation team to support team. This process is called “Transition” and sometimes
this activity itself can be long enough (running across several weeks) to justify itself as a different phase
altogether. This is discussed in Chapter 19.
Transition of Project Documents and Open Issues Along with transition of knowledge, all relevant docu-
ments that will help the support team support the end users effectively also need to be transferred to them.
These documents include business blueprint documents, configuration documents, development specifica-
tions, test scripts, etc. This is also discussed in Chapter 19.
Regular Support, Monitoring Service Level Agreements (SLAs) When regular support phase starts, there
will be regular tickets coming from different users of the system to help desk which are then assigned to
respective ERP module consultants to provide solutions. Depending on the criticality of the issue, service
level agreements (SLAs) need to be finalised (For example, most critical issues will be closed within four
hours, moderately critical issues within 2 working days and less critical ones within 5 working days, etc).
SLAs need to be monitored on a regular basis and SLA performance need to be reported to top management.
If there are regular breaches in SLA, corrective action need to be taken. This is discussed in Chapter 19.
Measuring Performance Improvement This is about measuring business benefits from ERP implementa-
tion. This typically starts when the system becomes steady, say after 3-6 months of implementation. This
is discussed in Chapter 19.
Upgrading to Next Version of ERP Once one particular version of ERP is operational for 24-36 months, the
company may evaluate the option of upgrading the ERP to the next version which the vendor may suggest.
This becomes a new project and needs separate business justification for going for it. These days leading
ERP vendors also force companies to upgrade their system after regular duration without which they either
no longer support very old versions of ERP or support it at a very high annual maintenance cost. This is
discussed in Chapter 19.
 ERP Implementation—Life Cycle, Methodologies and Strategy 41

Support Phase—Critical Deliverables This phase expects a set of deliverables from the core team.
Some of the critical deliverables of this stage are shown in Figure 2.2. These are:
Transition checklist
Transition KT
Service level agreement (SLA) contracts
SLA performance reports
Support Phase—Major Milestones Major milestones of this stage are:
Successful completion of transition;
Initiation of SLA monitoring.

Putting it all Together—ERP Life Cycle—Phase, Activity, Sequence, Deliverable

and Chapter Mapping
Table 2.7 puts together all components of project life cycle – Different phases, activities during these phases,
their sequence, deliverables of each phase and finally mapping these to the chapters of this book for a ready
reference on what is discussed and where.

Table 2.7 ERP Life Cycle – Phase, Activity, Sequence, Deliverable and Chapter Mapping

Line Activity Sequence Deliverable Chapter

No. No. No.
ERP Implementation Life Cycle
Phase – Pre-implementation Business case
High level requirement document
High level scope document
RFP for consulting partner selection
RFP for ERP package selection
Contract with partner
Contract with ERP package vendor
1 Have a senior crack team in place (for 1
few initial steps in ERP journey)
2 Feasibility study/ROI analysis/business 2
case
3 Getting budget for ERP implementation 3
4 High level requirement definition, priori- 4
tisation of requirements
5 High level scope definition 4
6 Request for proposal (RFP) for imple- 5
mentation partner selection
7 Evaluation and selection of consulting 6
partner for implementation – Contract
with consulting partner
(Contd)
42 Enterprise Resource Planning

(Contd)
8 Request for proposal (RFP) for package 7
selection
9 Evaluation and selection of ERP package 8
– Contract with package vendor
Phase – Project preparation Detailed project scope document
Project vision and mission
statement
Technical architecture document
IT landscape strategy document
Hardware sizing document
Project plan
Resource plan
Training plan
Project charter
10 Project team selection (Core team and 9
consultants)
11 Detailed project scoping 10
12 Project vision/mission statement 10
creation
13 Deciding implementation strategy, meth- 10
odology to follow
14 Finalising project methods, standards and 10
governance
15 Technical preparation 10
16 Project planning, resource planning, 11
training plan
17 Project charter preparation 12
18 Conducting project kick off meeting 13
19 ERP overview training to senior man- 14
agement, ERP process training to core
team
Phase – Business blueprinting AS IS model (high level)
Detailed requirement document
TO BE process definition document
Gap document
Authorisation plan
Detailed business blueprint
document

20 High level process modelling of AS IS 15

process
(Contd)
 ERP Implementation—Life Cycle, Methodologies and Strategy 43

(Contd)
21 Developing detailed requirement defini- 16
tion (Conducting workshops, knowing
pain points, and current process improve-
ment areas)
22 Business process reengineering 17
23 Detailed process modelling of TO BE 18
process, design process steps
24 Gap identification and analysis, and 19
strategy to bridge the gap
25 User authorisation, roles and security 19
planning
26 Blueprint audit by external team 20
27 Getting blueprint signed off 21
28 Giving core team ERP configuration 22
training
Phase – Realisation Configuration document
Test strategy and test plan
Unit test scripts
Functional and technical specifica-
tions for developments
Data migration strategy document
End user training materials
Integration test signing off scripts
29 Configuration/customisation of ERP 23
system
30 Unit and integration testing 23
31 Developments for gaps 23
32 End user training planning 24
33 Integration test signing off 24
Phase – Final preparation and go live End user acceptance testing
document
Stress and volume test result
Cut over plan
Go live checklist
Help desk plan
List of open issues
Technical operation manual for end
users
Go live audit report
34 Stress and volume testing 25
35 User acceptance testing and user 26
signing off
(Contd)
44 Enterprise Resource Planning

(Contd)
36 Conducting end user training 27
37 Data migration – Migrating open items 27
38 Cut over planning – Preparing go live 27
checklist
39 Help desk support finalisation 27
40 Closing open project issues 27
41 Pre-go live audit by external team 28
42 Going live 29
ERP Support Life Cycle
Phase–Support Transition checklist
Transition KT
Service level agreement (SLA)
contracts
SLA performance reports
43 Knowledge transfer to support team 30
44 Transition of project documents, open 30
issues, etc
45 Regular support, monitoring SLAs 31
46 Measuring performance improvement 31
47 Upgrading to next version of ERP 32

METHODOLOGY FOR IMPLEMENTATION

Whether ERP implementation is an art or science? As ERP implementation needs a set of steps to be done
in a particular sequence, so a scientific approach towards this helps in making the implementation a success.
In the 80s and 90s different consulting companies through their experience in several engagements started
to build a systematic way of ERP implementation. The drive for building some methodology was mainly
internal so that they need not depend on a set of experienced consultants only to make the implementation
a success and not to leave the implementation to their art and style of doing things, rather to build a list of
steps which, if followed judiciously by any team, can make the implementation a success. Over the time,
different consulting companies came with a list of proven activities, deliverables, templates and accelera-
tors to facilitate any ERP implementation. When designed and applied for a specific client environment,
the methodology provides the guidance, framework, and process check-points that drive the project team
to succeed.
In the late 90s, the package vendors themselves started to come up with methodologies for implementing
their solution. One of such very successful methodology is ASAP (Accelerated SAP) which the leading ERP
solution provider SAP developed and can be used for implementing any of SAP’s solution (like: SAP ERP,
SAP CRM, SAP Supply Chain Management, etc). ASAP had been used in implementation of thousands of
SAP solutions around the world as one of the most talked about methodology for ERP implementation.
In this chapter, we will also discuss another implementation methodology which is developed by a con-
sulting company and is also widely popular. This is known as Ascendant methodology, first developed by
PriceWaterhouseCoopers (PWC) and later adopted by IBM (after PWC take over) globally as a methodology
 ERP Implementation—Life Cycle, Methodologies and Strategy 45

for any package solution implementation. Ascendant is powered by ASAP, but the point of difference is that
it can be applied for implementing any packages beyond SAP, i.e. Ascendant can be used for Oracle ERP
implementation.
Study of methodologies developed both by a package vendor and a package consulting company will give
us good understanding of what a methodology means and how it helps in implementing an ERP solution,

One Example of Methodology from ERP Vendor: ASAP from SAP

Figure 2.3 shows critical phases of an ASAP methodology.

Fig. 2.3 ASAP Roadmap

Objectives of ASAP Main objectives of ASAP are to:

Implement SAP solutions in a quick and cost effective manner.
Maximise the utilisation of resources.
Incorporate a process-oriented approach to implementation.
Involve the user community.
Use it as a repeatable “model” with other implementations of SAP
Phases in ASAP ASAP divides any SAP implementation in five phases. Each phase has a structured set
of activities, deliverables, templates and accelerators to make the project a success. These five phases are:
Phase 1: Project Preparation The purpose of this phase is to provide initial planning and preparation
for the SAP project.
Phase 2: Business Blueprint The purpose of this phase is to achieve a common understanding of how the
company intends to run its business within the SAP System. The result is the business blueprint, a detailed
documentation of the results gathered during requirements workshops. The business blueprint document
represents the business process requirements of the company. It is the agreed statement of how the company
intends to run its business within the SAP system.
46 Enterprise Resource Planning

Phase 3: Realisation The purpose of this phase is to implement all the business process requirements
based on the business blueprint. This phase builds the solution based on the requirements gathered in the
earlier stage.
Phase 4: Final Preparation The purpose of this phase is to complete the final preparation (including
testing, end user training, system management and cut-over activities) to finalise the readiness to go live.
The final preparation phase also serves to resolve all critical open issues. On successful completion of this
phase, the company will be ready to run its business in live SAP system.
Phase 5: Go Live and Support
The purpose of this phase is to move from a project-oriented, pre-production environment to live produc-
tion operation.
Tools in ASAP ASAP comes with a set of tools for SAP implementation and these are:
1. Implementation Assistant
Roadmaps—Steps to complete project
Knowledge corner – Comprehensive library of reference material that helps implementation
2. Q&A Database: This helps in
Setting the project scope
Document business requirements in detail
Helps in creating the business blueprint
3. Project IMG—Helps in quick customising of the application
4. Transports—Helps in moving the configurations from one landscape to another (Say, development to
quality)
5. BC sets – Helps in recording configurations so that these can be reused in other implementation
(say, another business division of the company)

One Example of Methodology from Consulting Company:

Ascendant from PWC IBM
IBM’s Ascendant methodology is based on SAP’s ASAP methodology. Ascendant builds upon ASAP with
additional templates, accelerators, examples, and deliverable roadmaps. It is also fully integrated with
SAP solution manager. The Ascendant method uses phases, work packages, activities, and tasks to sup-
port the implementation of ERP. It defines an integrated programme method that focuses on six key areas
(domains):
Project management
Business
Organisation
Application
Architecture
Operations
Each component of the integrated programme consists of a work stream of activities which are mapped
across all key phases of project delivery. There are seven phases in the IBM Ascendant method and these
phases are same as ASAP except for the addition of the evaluation phase at the beginning and the sustain
phase at the end. The Ascendant method is designed to be scalable and encourage the iterative definition
and refinement of deliverables throughout the project lifecycle. The project lifecycle is composed of specific
activities and deliverables.
Figure 2.4 explains Ascendant ERP Roadmap and the phases are detailed below.
 ERP Implementation—Life Cycle, Methodologies and Strategy 47

Fig. 2.4 Ascendant Roadmap

Phases in Ascendant
Phase 0: Evaluation The purpose of this phase is to select software and an integrator, and to propose an
implementation strategy. In many cases the business and strategic goals are defined via stakeholder interviews,
workshops and visioning conferences. The information extracted from these sessions is used to build a clear
vision of business requirements, evaluate solutions and to define high level programme scope. Under this
newly defined scope, business benefits are identified and a case for change is made and approved.
Phase 1: Project Preparation The purpose of this phase is to provide detailed initial project planning
and preparation for the client company project. It is at this phase of the methodology when the detailed
planning and scoping is conducted. Although each ERP project has its own unique objectives, scope and
priorities, the steps in the project preparation phase help identify and plan the primary focus areas. Informa-
tion acquired during evaluation stage aligns with the proposed ERP implementation package with a business
case and results in the following activities/deliverables:
Stakeholder assessment
Initial project scope defined
Approved business case
Agreed project proposal
Major milestones achieved during this phase include:
Signing off the detailed project scope by the project sponsors;
Preparation of detailed project plan including release strategy, business process design standards,
development standards and configuration guidelines;
Staffing the project team to support global design;
Completing project strategies and signing off by the project sponsors;
Holding project kick-off meeting;
Completion of quality check.
48 Enterprise Resource Planning

Phase 2: Business Blueprint The purpose of the business blueprinting or design phase is to create a
detailed description of client’s business requirements, define the technical requirements to enable those
business functions, and develop and begin implementing an approach to manage the impacts to the organi-
sation. The methodology supports these tasks with a suite of tools and accelerators, including test scripts
and technical design best practices.
This phase also includes the creation of the system technical design, definition of required custom pro-
gramming, and the establishment of a development system that is ready for prototyping. Major milestones
achieved during this Phase;
Installation of development technical environment;
Completion of business process workshops;
Design and documentation of business processes;
Defining interfaces, conversions, enhancements, bolt-ons;
Building and demonstration of proof of concept;
Approval of business design/blueprint by Project Sponsors;
Completion of quality checks
Phase 3: Realisation The purpose of this phase is to configure the system to the specifications of the
business and process requirements documented in the business design/blueprint. The main purpose of the
Realisation or Build phase is to verify that the system is complete, stable and ready for transfer into pro-
duction. This phase marks a significant shift in the project from designing and building the solution toward
testing, cut-over and go-live. Some of the activities completed in this phase include design and development
of security, reports, forms, conversions, enhancements; establishing archiving strategy; establishing quality
assurance; design/size of production systems; and design and development of end user training. The major
milestones that must be achieved are:
Completion of baseline configuration and confirmation;
Completion of final configuration and confirmation;
Completion of conversions programmes;
Completion of application interface programmes;
Enhancements completion;
Completion of bolt-on configuration and enablers;
Completion of Reports;
Completion of system integration test.
Phase 4: Final Preparation The purpose of this phase is to validate readiness for go-live, including
testing, end user training, site preparation, system management and cut over activities. This Final Preparation
phase serves as a last opportunity to resolve crucial open issues. The major milestones that will be achieved
during this phase include:
Completion of conversions;
Delivering end user training;
Establishing help desk;
Testing technical environment;
Obtaining final approval for going live.
Phase 5: Go Live The purpose of this phase is to move from a pre-production environment to a live
production operation. Major milestones of this phase include:
Final promotion to production;
Processing live transactions;
Transfer to support organisation.
 ERP Implementation—Life Cycle, Methodologies and Strategy 49

Phase 6: Sustain During this phase the main activities are to provide a framework to sustain and improve
the performance of the system after going live and to set up an on-going support organisation for the end
users. In addition to providing the end users a help desk to troubleshoot system issues, a post-implementation
training programme is implemented to provide refresher and new hire training as well as advanced skills
training. Typically, activities in this phase include:
Review and follow-up of training;
Development of a long-term strategy for user support;
Monitoring systems performance and tuning issues;
Conducting upgrades for correction and functional releases;
Designing and implementing a strategy for archiving documents;
Review and evaluation of systems operations;
Learning document lessons.

Different Methodologies for Different Types of ERP Projects

ERP projects are of different types like (i) a company first time implementing one ERP solution (Implemen-
tation projects), (ii) a company already having one ERP and replacing it with another (Migration project,
for example, Oracle ERP is getting replaced by SAP) (iii) upgrading to newer version of the ERP (Upgrade
projects), (iv) had already implemented ERP for one location and now rolling it out in other locations (Rollout
projects). All these different types of projects need different methodologies as one ERP methodology may
not suit all. Let us understand different types of ERP projects.

Different Type of ERP Projects

ERP implementation projects: These are the classic ERP projects, implementing an ERP solution
for the first time in a company. This book mainly concentrates on such type of projects.
ERP upgrade projects: Existing ERP customers need to upgrade to the next version of ERP for better
functions and/or when the application vendor denies to support the older version any longer or agrees
to support at a much higher annual charge. This is discussed in Chapter 19.
ERP global rollout projects: A multinational company having operations in different countries or a
company having different businesses may adopt this approach. In this case, based on common require-
ments of different countries/businesses, a global template is created which is then rolled out in different
countries after adding country-specific enhancements. This ensures commonality of processes which
are central and still providing local flavour as and where needed. This also reduces project risk (as
for most of the countries the solution is tested and working in some other country) and overall project
cost. Global Template concept is explained in Figure 2.5.
ERP migration projects: These are the cases where a customer who is on a particular ERP wants to
migrate to another. In the past many companies who were on JD Edwards, Oracle or Peoplesoft had
migrated to SAP or Oracle as those companies were taken over and no new functionality enhancements
were available in their existing ERPs. Some customers of these ERPs even had problem in getting
proper support. For a pure migration project from a client’s perspective, there is no business benefit
expected as exactly similar processes need to migrate to a different environment.
ERP harmonisation/consolidation projects: These are the cases when a company has different ERP
instances for different countries/businesses and wants to consolidate these into one to reduce total cost
of operations.
50 Enterprise Resource Planning

Fig. 2.5 Global Template Concept

As there are different types of ERP projects, the same methodology may not suit every type. So package
vendors and consulting companies came out with several versions of the methodology to suit specific type
of project requirement. For example, SAP came up with a separate ASAP methodology version for upgrade
and global rollout projects. SAP also has a methodology for application support known as Run SAP.

ERP Implementation Methodology for Small and Medium Business

Small and medium business is the largest growth segment for all ERP solutions these days as most of the
Fortune 500 companies and large organisations have already gone for it. However, the implementation ap-
proach that works fine for large companies may not be suitable for small organisations for reasons like:
Small companies may not afford the implementation approach that spans across 24-36 months and
costs a few hundred million dollars.
In most cases, these companies have fairly few senior management officials running the organisation.
Therefore, they may not afford to send them as project core team member for a long duration thereby
hampering their day-to-day running of business.
In many cases, their business requirements are as complex as large organisations.
Like large organisations they can not spend money on a BPR project prior to implementation and may
not be aware of how processes are run in leading companies in the world. They expect consultancy
from the project team in terms of best practices of running a particular process.
Keeping in view the above shortcomings, both ERP package vendors and implementation consultancy
companies have come up with solutions to address them.
 ERP Implementation—Life Cycle, Methodologies and Strategy 51

A. Pre-configured Template ERP package vendors have come up with pre-configured industry tem-
plates for several industries. These templates has a reference set of business blueprint documents, recorded
configurations, master data formats, reports relevant for the industry and other accelerators which help in
speedy implementation of the ERP solution. Figure 2.6 shows such an example of pre-configured industry
template. Most of the leading consulting companies like IBM, Accenture, etc are also coming up with such
industry templates to accelerate the process of implementation.

Fig. 2.6 Pre-configured Industry Template

B. Separate Solutions for SMB Segment ERP vendors are targeting this segment with all together
different solution. For example, SAP has two different solutions for this segment – “All in One” for middle
industry segment and “Business One” for small industry segment. Business One is altogether very different
from SAP’s standard ERP.
C. Fast Forward Implémentation Méthodologies ERP vendors are coming up with new imple-
mentation methodologies for targeting this segment. For example, IBM has come up with another version
of Ascendant known as Ascendant Express shown in Figure 2.7 for this segment having very different steps
from normal Ascendant methodology like Quick scan, Validation, Activation, Simulation, etc. This mostly
tries to leverage the pre-configured template and activate the configurations.

Different ERP implementation Strategies

Different companies follow different approaches for ERP implementation, each of which has their own ad-
vantages and disadvantages. Figure 2.8 shows a comparison of different implementation approaches. Some
of the common approaches are:
Big bang (All locations, all modules)
Rollout (Selected locations, all modules)
Big bang and Modular (All locations, selected modules)
Rollout and Modular (Selected locations, selected modules)
52 Enterprise Resource Planning

Fig. 2.7 IBM’s Ascendent Express Methodology for SMB Clients

Fig. 2.8 Comparison of Different Implementation Approaches

Big Bang In this approach, the company goes for implementing all ERP modules in a single go in all
locations. This is a common approach for small companies going for implementing ERP in one or two
locations. However, this is not very common in case of large ERP implementations running across several
locations and having several modules. Advantage of this approach is that it reduces the total implementation
time and related cost. Disadvantage of this approach is the high risk of failure. Besides, it demands time and
effort from a lot of senior personnel in the organisation at the same time and, therefore, for some companies
it becomes difficult to run the business after leaving so many senior people for the ERP project. It is not a
recommended approach for large implementations.
 ERP Implementation—Life Cycle, Methodologies and Strategy 53

Rollout In this approach, the company first goes for ERP implementation in one location for all the
modules. This location is a representative one, i.e. having good representation of company’s all business
processes, and this is the place where the company builds their global template that covers most of the com-
pany processes. Later this template is rolled out to several locations having location-specific enhancements,
if required. An example of this can be a European company had done its first implementation in Germany
and built its global template covering its all common processes here. When they rolled out the template to
France, while most process parts were common, France-specific sales tax, accounting and duties needed to
be added to the template, i.e. the template needed to be localised. Rollout can also be based on different
businesses or divisions of a company. An example is given below.

Singapore Ministry of Defense (Mindef) had gone for SAP implementation for its different units like
Navy, Air Force and Ground force. The implementation first started in its navy business where the
global template was built and afterwards the same was rolled out to air force and ground force
division with specific enhancements added for each business during rollout.

The advantage of rollout approach is low risk and the company can leverage the learning from implemen-
tation at earlier location (except the first) i.e. what worked, where they had problem, etc. It does not put
lot of pressure on the company in terms of time and effort from a large internal team. However the only
disadvantage here is that the project may go on for long time.
Big Bang and Modular In this approach, the company wants to go live for all locations, but for selected
modules. The company may decide that in the first stage they need to put the basic transaction systems in
place and will first implement financial, materials management and sales. Later on they will go for other
modules like plant maintenance, production management, human resource, etc. for all locations.
Rollout and Modular In this approach, the company takes a template rollout approach as described
earlier, but first the basic requirements are implemented in one location and then rolled out to other locations.
Next, the company upgrades the template with more advanced functionality and then again starts rolling
out template in all other locations. This approach has minimum risk, gives lots of scope for learning from
earlier implementations and is better in terms of change management. The only drawback here is that more
time is needed to complete the implementation. Given below is an example of such an approach.

Nestlé's ERP implementation project known as “Globe” is a good example of rollout and modular
approach. The company had first implemented Version 1.0 of its global template and started imple-
mentation in countries like Malaysia, Singapore, Thailand, and then it was rolled out to Australia,
Europe, South Africa and the U.S. Later on the template was upgraded to Version 1.5 with lots of
advanced functionalities and the company followed the same rollout approach across the globe.

Summary
An ERP life cycle has six phases known as: Project Preparation, Business Blueprinting, Realisation, Go Live
Preparation, Go Live and Support. There are activities before implementation starts and these are known as
pre-implementation activities.
54 Enterprise Resource Planning

Pre-implementation involves defining business case, getting budget, preparing high level scope and require-
ment document, creating RFP for ERP vendor and consulting company, selection of consulting partner and
ERP vendor and finally entering into contract with them.
Project preparation involves creating project planning, detailed project scoping, project team formation, project
charter formation, training and technical preparation.
Business Blueprinting phase mainly concentrates on designing TO BE processes and identifies gaps.
In Realisation phase, the system is built with configurations, developments, testings, etc.
Finally, before going live, data needs to be migrated to the new system, cut over activities need to be com-
pleted as per go live checklist and open issues need to be closed.
Project support phase typically starts with a transition of knowledge from implementation team to support
team. During normal support phase, SLAs are monitored and finally after using the system for few years, it
needs to be upgraded.
Different ERP vendors and consulting partners had developed methodology to implement ERP which more
or less covers the same set of activities as described above. ASAP and Ascendent are two such popular
methodologies.
Different types of ERP projects like Implementation projects, Upgrade projects or Rollout projects need dif-
ferent types of methodologies.
For small and medium businesses, ERP vendors and consulting companies are coming up with pre-configured
templates or fast forward implementation methodology.
There are different strategies for ERP implementation such as: Big Bang, Rollout, Big Bang and Modular,
Rollout and Modular, etc. Each has its own advantages and disadvantages.

Exercise
I. Objective Type Questions
1. What is meant by “ERP life cycle”?
2. What are the phases in an ERP life cycle?
3. What are the deliverables and milestones of Pre-implementation stage of an ERP project?
4. What are the deliverables and milestones of Project Preparation stage of an ERP project?
5. What are the deliverables and milestones of Business Blueprinting stage of ERP project?
6. What are the deliverables and milestones of Realisation stage of an ERP project?
7. What are the deliverables and milestones of Final Preparation and Go Live stage of an ERP project?
8. What are the deliverables and milestones of Support stage of an ERP project?
9. Feasibility study is carried out in which phase of an ERP project?
10. In which phase of ERP project high level scope is defined?
11. ERP package and vendor selection is done in which phase?
12. Project plan and project charter is finalised during which stage?
13. What is Gap document? In which phase of project it is prepared?
14. What is a methodology?
15. What is ASAP?
16. What is Ascendent?
17. What is Global Rollout ERP project?
18. What is ERP migration project?
19. What is ERP consolidation project?
20. Name some of the ERP implementation methodologies for SMB sector.
 ERP Implementation—Life Cycle, Methodologies and Strategy 55

21. What are the four common ERP implementation strategies?

22. What is a Big Bang strategy?
23. What is a Rollout strategy?
24. What is a Modular strategy?

II. Descriptive Type Questions

1. Explain the critical activities of Pre-implementation stage of an ERP project? What are the typical deliver-
ables of this phase? What are the major milestones of this phase?
2. Explain the critical activities of Project Preparation stage of an ERP project? What are the typical deliver-
ables of this phase? What are the major milestones of this phase?
3. Explain the critical activities of Business Blueprinting stage of an ERP project? What are the typical deliv-
erables of this phase? What are the major milestones of this phase?
4. Explain the critical activities of Realisation stage of an ERP project? What are the typical deliverables of
this phase? What are the major milestones of this phase?
5. Explain the critical activities of Final Preparation and Go Live stage of an ERP project? What are the typical
deliverables of this phase? What are the major milestones of this phase?
6. Explain the critical activities of Support stage of an ERP project? What are the typical deliverables of this
phase? What are the major milestones of this phase?
7. Sometime ERP implementation may not follow defined sequence—why? Explain with some examples.
8. Why an ERP implementation needs a methodology? Who can provide a methodology for implementation?
Give examples of some popular methodologies?
9. What is ASAP? What are its objectives? Explain different phases of ASAP. What are the tools of ASAP?
10. What is Ascendent? What are its objectives? Explain different phases of Ascendent.
11. What are different possible types of ERP projects? Explain each of them.
12. Why different ERP projects need different type of methodologies?
13. Why ERP implementation for SMB sector needs different methodologies. Explain some of these method-
ologies.
14. Explain four common ERP implementation strategies. Explain Pros and Cons of each.

III. State Whether the following Statements are True or False

1. Project charter is a deliverable during Business Blueprint phase
2. Gap document is a deliverable during Business Blueprint phase
3. Configuration document is a deliverable during Project Preparation phase
4. All in One is a solution from SAP for small industry segment
5. In Big Bang all ERP modules are implemented at selected locations
6. In Rollout all ERP modules are implemented at selected locations
7. In ERP migration project, companies migrate from several ERPs to one
8. In ERP consolidation project, companies migrate from several ERPs to one
9. ASAP is an implementation methodology for any ERP
10. Q&A database is a tool of ASAP

IV. Assignments
Study an organisation that had taken up an ERP project in the past and note down following details:
What strategy for ERP implementation (Bigbang, Rollout etc.) they had selected and why?
What methodology they had adopted for ERP implementation?
What type of activities they had done in different phases? What were the critical milestones and deliverables
for each phase?
 3
Business Case and Return
on Investment Analysis Chapter
for ERP

Learning Objectives
In this chapter we will discuss the following concepts:
Costs of an ERP implementation
Benefits of an ERP implementation
Case study – Building a business case

As discussed earlier, ERP implementation requires large investment on the part of any organisation and like
any other investment, this needs to give reasonable return to the business, justifying the investment. Like
any software project, establishing a return on investment (ROI) for ERP investment is not easy. It is easier to
make a reasonably good estimate for the implementation cost. It is, however, difficult to project the benefits
as these need lots of assumptions and most of which occur over a longer time-frame during the ERP life
cycle. Let us first study the easier part of the equation, i.e. the cost of implementing an ERP solution.

COST OF ERP IMPLEMENTATION

ERP implementation involves different direct and indirect costs as shown in Figure 3.1. These costs need
to be approximated at reasonable details before a decision for ERP investment is made. These costs are
detailed below:

Direct Costs
Hardware (Server, PCs, LAN, etc) cost: Based on the number of ERP users and number of transac-
tions, ERP vendors recommend the server or hardware size needed to run the application. Approximate
sizing estimate from few vendors can be used for budgeting purpose. Some of the package vendors
provide online tool in their site where if some necessary inputs (like estimates on transaction volumes,
etc.), are provided, the tool provides an approximate estimate of server size. Besides server, an ERP
implementation may need new PCs to be purchased, new LAN connections to be established, etc.
OS (Operating System) cost and DB (Database) Licence fee: Again here a lot of options are avail-
able in terms of different OS (like Windows NT, Unix, etc) and Database (like SQL, Oracle, DB2,
 Business Case and Return on Investment Analysis for ERP 57

Fig. 3.1 Costs of ERP Implementation

etc). An ERP implementation may call for buying new or additional OS and DB licences and these
costs needs to be accounted for.
ERP Application licence fee: This is the cost of the software licence. ERP vendors provide different
types of licences depending on the type of user for the application. For example, SAP has three types
of licences to offer: Developer licence (People who will do development in the application), Profes-
sional licences (People who will do configuration in the software) and User licence (People who will
use the application as end user). Cost varies depending on the licence type. Developer licence is the
costliest licence followed by professional and the user licences. On the other hand, the number of
users will be highest in user category followed by professional and developer.
ERP application maintenance costs: There is a yearly maintenance charge for all ERPs. This varies
between 18-22% of license fee. Though this is not exactly part of the implementation cost, yet this
need to be considered. Typically, companies calculate maintenance cost for the next 3-5 years after
implementation as during this period, the ERP software is supposed to provide maximum benefits.
Complimentary software license fee: ERP implementation may call for buying licences of other
software that may be needed for running the project. These can be software for project management
(like MS project), business modelling software (like Visio or Aris), separate software for managing
project documents, etc.
Consulting service cost: One of the large portions of the total cost is the cost for consulting services.
There can be multiple consulting organisations involved in the project: One for defining the company’s
requirements (RFP preparation), another one for actual software implementation, etc. Cost may vary
widely depending on whether the company is going for a large consulting firm or one of the top Indian
IT firms or a small consulting organisation.
Post-implementation support from consulting company: Some companies may outsource the post-
implementation support to another company. Cost for maintaining the application by third party vendors
need to be considered. This is over and above the normal support charges paid to ERP vendor.
58 Enterprise Resource Planning

Training: This involves costs like travel of trainers and trainees, hotel expenses, renting out training
rooms and PCs for training duration, etc. For a company having multiple locations and large number
of users, this cost can be substantial as during the project and, especially before going live, large
number of end users need to be trained and that involves travel for core team and consultants. There
should be some ongoing budget as well for training as new employees keep on joining/new modules
get rolled out, etc.
Project management office cost (PMO cost): This include regular costs of running the project, i.e.
the rent of project office, office equipment (PC, laptop, printer, xerox, etc), vehicles and phones for
the project, cost of project office clerk, etc.
Other costs: This includes cost of temporary people engaged during data migration, cost of third party
audits after blueprint completion and before going live, etc.

Indirect Costs
Besides direct costs, there are also other costs involved in the implementation process which the company
do not pay out directly, but need to consider for total cost calculation. Such indirect costs include:
Cost of employees involved in the project and cost of their replacements: If you give your best
functional guys to the implementation team which you suppose to, that would definitely cost the
organisation in terms of finding a replacement, getting the new person trained and still you may not
get the same level of performance/service.
Operation disruption: There will some unavoidable operation disruption for the business during
ERP going live in terms of loss of productivity for employees for shorter duration as they are exposed
to a new system. There can be also operation disruptions during implementation as large number of
employees are called for training for a few days leaving their regular work, etc. Though every com-
pany wants to keep this as low as possible, the fact is that there will be some unavoidable costs to the
organisation for such operational disruption.
Table 3.1 gives an example of a typical cost estimate for implementing an ERP project. For some of the
cost elements (like ERP software, hardware, operating system software, database software, etc), there will
be annual maintenance charges. All cost elements are estimated for a five-year horizon.

Table 3.1 ERP Investments Costs

Cost Items Licence Type No. of Cost/ Yr1 Yr 2 Yr 3 Yr 4 Yr 5 Yr 6

Users Lac
Developer 20 1L 20L
Professional 30 80K 24L
ERP Software
User 450 50K 225L
Total 269L
ERP maintenance fee to Say: 20% per year for first three 54L 54L 54L 59L 59L
package vendor years and 22% per year for the 4th
and 5th years
Hardware 150L 10L 10L 10L 10L 10L
Operating system 10L 2L 2L 2L 2L 2L
(Contd)
 Business Case and Return on Investment Analysis for ERP 59

(Contd)
Data base 15L 3L 3L 3L 3L 3L
Other softwares 20L
Consulting charges for 800L
ERP implementation
Post-implementation 50L 50L 50L 50L 50L
support charges to con-
sulting company
Training 30L 3L 3L 3L 3L 3L
Grand Total 1294L 122L 122L 122L 127L 127L

BENEFITS OF ERP IMPLEMENTATION

This is the difficult part of the estimation as benefit realisation of ERP implementation starts when imple-
mentation ends and this benefit accrual happens for several years. There are always conflicts when it is
claimed that a business benefit has been realised only because of an ERP implementation. There are large
companies who run multiple initiatives at a time. There are companies which implement an ERP, a Just-in-
time Process and a Six Sigma simultaneously. Now if the company improves its performance on inventory
turn, there will be always debate that which initiative has brought about the improvement. However, in this
chapter we will discuss about the most common areas where ERP implementation had shown benefit in the
past. Figure 3.2 shows benefits areas of an ERP implementation.

Fig. 3.2 Benefits of ERP Implementation

60 Enterprise Resource Planning

Direct/Tangible Benefit Areas

Inventory Reduction: This is one of the first areas where companies can see result for simple reasons
like:
After the ERP implementation you can know which stock is lying where. If there are excess stock
in one warehouse and in another place the stock is reaching safety limit, you can quickly do a stock
transfer and need not purchase fresh stock (if the transport cost is much lower than ordering new
purchases).
You can know which stocks are nearing expiry so that the same could be consumed first.
You can do better inventory planning as at any point you know how much you need, how much you
have and how much need to be ordered with minimum safety stock requirement.
Items can be made or bought only when needed.
Deliveries can be coordinated with actual need dates.
ERP bills of material ensure that only matched sets are obtained rather than too much of one component
and not enough of another.
No inventory built-up of obsolete materials.
The good part of this reduction is that it is not a one-time reduction, but provides ongoing savings of the
inventory carrying costs. As inventory carrying cost is huge for any organisation including material cost, cost
of warehousing, handling, obsolescence, insurance, taxes, damage, shrinkage, etc. Even a 10% improvement
in overall inventory turn can work out to be a huge financial benefit for a mid-size organisation.
Better Customer Service and Reduced Lost Sales This is one area where most of the customers
had seen benefits in the past after the ERP implementation due to:
Capability of making an availability check before making any customer promise.
Reduced cases of stockouts as all inventory information is available online and you know days before
a product reaches its safety stock limit.
Reduced lead time of shipment as a customer enquiry can be quickly converted to an order, can be
sent online to factory and despatched quickly. At any point orders can be tracked by customer with
latest status update.
Quick configuration of product and pricing: If you are interested in buying not a standard PC, but
PCs with special configurations, an ERP system helps you to quickly configure the product with the
set of HDD, Floppy drive, RAM and Monitor configuration you want and price them immediately.
Sales guy need not ask several people for confirming customer the price.
These improvements in customer service can help more sales to happen and reduce the lost sales.
Reducing Number of Days of Outstanding This is the third area where most of the ERP imple-
mentations had shown benefits. ERP supports better collection procedures that reduce the number of days
of outstanding receivables and, thereby, provides additional available cash. This is possible through:
Fast and accurate invoice creation during shipment. There is lesser chances of invoice error and dis-
putes with customer and resulting in faster settlement.
ERP systems can show reports of accounts which are delinquent for last 30/45/60 days. Regular follow
up on these accounts can reduce outstanding amounts.
Credit checking during order entry ensures that orders are not taken from customers who’s past pay-
ment records are bad.
Improved credit management and receivables practices typically reduce the days of outstanding receiv-
ables.
 Business Case and Return on Investment Analysis for ERP 61

Material and Labour Cost Reductions This is another possible area where ERP can bring benefits.
Material cost reduction can be achieved through:
Consolidation of purchase requirements from all the departments of the organisation helps introduction
of economy of scale and thereby reduction in the cost of procurement.
Better vendor schedule through MRP run helps no last-minute escalation and follow-up. No excess
inventory is stocked and orders are placed as per requirement.
Better visibility of future requirements helps vendors plan material better and get raw materials at
competitive prices.
Labour cost reduction is achieved through:
Less overtime through better production planning
Minimising rush jobs and parts shortages and lesser time requirement for expediting material handling,
extra set-ups, disruptions, etc.
Better visibility of required work for supervisors help them adjust capacity or loads to meet sched-
ules.
Quick reaction on shop floor to reflect changes in demand situation in market.
Corrective actions, such as notifying customers of changes in the promised delivery dates, or altering
production schedules to satisfy demand can be taken early.

Non-tangible Benefit Areas

Some non-tangible benefits accrued from the ERP implementation are:
Easy data entry
Availability of information at the click of the mouse
Implementation of best practice processes followed by leading companies in the world that come as
a part of ERP package
Faster operation – quick goods receipt, purchase order, sales order or invoice creation with minimum
data entry.
Table 3.2 shows a typical chart which can be used for benefit calculation from an ERP solution.

Table 3.2 Expected Benefits from an ERP Solution

Benefits Current value Expected Yr 1 Yr 2 Yr 3 Yr 4 Yr 5 Yr 6

Savings %
Sales increase
Reduction in material cost
Reduction in labour cost
Inventory reduction
Reduction in number of days
of outstanding

After estimating costs and benefits, it is important to do a comparative analysis to see whether ERP invest-
ment really has a return on investment (ROI). The actual decision of investment need to be done after this
ROI analysis is completed. Figure 3.3 shows the framework for costs and benefits analysis.
62 Enterprise Resource Planning

Fig. 3.3 Costs and Benefits for ERP

CASE STUDY BUILDING A BUSINESS CASE

Below is a case study of an Indian company how they had developed a Business case for ERP implementa-
tion.

Business Case—Company XXX

The following business case has been worked out for projected sales of Rs. 2000 crore for the year ending
March, 2008. The base figures considered for calculation pertain to the figures from the business plan of the
company for the year 2008.
The cost savings/benefits are presented under the following heads:
1. Productivity improvement in terms of labour cost
2. Material cost reduction
3. Finance cost
4. Debtors
Each head has an accompanied rationale explaining as to how the savings will accrue.
1. Productivity Improvement:
Current labour cost = Rs. 200 crore
Savings envisaged over the next 5 years = 2%
Savings due to improved productivity for the next 5 years = Rs. 4 crore
Rationale:
Redesign the order fulfillment process by removing waste/non-value adding activities
2. Material Cost:
Total material purchase = Rs. 1000 crore
% Reduction possible through economy of scale = 1%
Savings in material cost for the next 5 years = Rs. 10 crore
 Business Case and Return on Investment Analysis for ERP 63

Rationale:
Vendor improvement and better negotiation
Reduced transaction cost
Better economies of scale (reduced vendor base and multi-point reduction)
Reduced inventory at vendor site
3. Finance Cost:
Turnover: 2000 crore: Current inventory holding: 400 crore, Current inventory turn: 5
(Increase inventory turns from 5 to 6)
Inventory value @ 5 turns = Rs. 400 crore
Inventory value @ 6 turns = Rs. 333 crore
Reduction in inventory = Rs. 67 crore
Savings in finance cost (interest @ 12%) for next 5 years = Rs. 8 crore
Rationale:
Better visibility of inventory across all locations
Scientific ordering and inventory management system implementation
4. Debtors:
Current accounts receivable – 500 crore, i.e. 1.37 crore/day
(Reduce from 50 days to 40 days)
@ 50 days, accounts receivables = Rs. 68.4 crore
@ 45 days, accounts receivables = Rs. 54.79 crore
Savings = Rs 13.6 crore
Savings in debtors (@ 12% interest for the next 5 years. = Rs. 1.62 crore
Rationale:
Regular pending payment analysis
Auto reminders
Less Billing disputes

Total Cost Reduction—Benefits:

Productivity improvement = Rs. 4 crore
Materials cost = Rs. 10 crore
Inventory (finance cost) = Rs. 8 crore
Debtors = Rs. 1.62 crore
Total (for the first five years) = Rs. 23.62 crore
Total cost for this project is detailed in Table 3.1.
So it’s clear that while the savings start flowing after the implementation, the full benefits can be realised more
in subsequent years as the investment is marginal.

Summary
Decision to make an investment on ERP implementation may be taken after judicious analysis of cost and benefits
from the implementation. While making a cost calculation simple, a benefit analysis needs to be done with a set
of assumptions.
Typical ERP implementation has several direct cost elements like hardware, ERP software license cost, ERP
software maintenance cost, consulting cost during implementation, consulting cost during support, training
costs, PMO costs, etc.
64 Enterprise Resource Planning

Indirect cost elements are: core team cost, cost of finding replacement for the core team members, operation
disruption cost, etc.
Direct tangible financial benefits of ERP implementation are: inventory cost reduction, reduction in material
and labour costs, reduced days’ outstanding and reduced lost sales, etc.
Intangible benefits are easy data entry, best practice processes, availability of better information and reports,
etc.
A final decision of ERP investment is taken after evaluating these costs and benefit elements on a quantitative
scale.

Exercise
I. Objective Type Questions
1. What are the typical hardware cost elements for an ERP project?
2. What are the leading operating system (OS) and database (DB) used in an ERP project?
3. What are the different licencing policies that ERP vendors follow?
4. What kind of complimentary software may be needed in an ERP project?
5. What kind of cost elements is included under training for an ERP project?
6. What are the indirect costs for an ERP project?
7. What are the intangible benefits from an ERP implementation?

II. Descriptive Type Questions

1. What are the direct costs of ERP implementation? Explain each one of them.
2. What are the indirect costs of ERP implementation?
3. What are the direct/tangible benefits of an ERP package?
4. What is the approach for building a business case for an ERP project?
5. How does an ERP implementation help in inventory reduction and better customer service?
6. How does an ERP implementation help in material and labour cost and days of outstanding?

III. Assignments
Do some primary and secondary research to understand – how few companies have justified their ERP investment
– what costs they considered, what benefits they forecast? Whether they had used any quantitative approach for
such justification or it was a management decision based on qualitative criteria.
 4
Selecting Consulting
Partner Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Things to be considered for partner selection
Request for proposal method for selection of consulting partner
In-house implementation team vs. external consultants
ERP consulting companies
Doing part of ERP projects from offshore

Selecting the right consulting partner is another important decision for ERP implementation. Consulting
partners can be selected for different phases of the project like to prepare the requirement document (RFP),
to do the implementation or to do the post-implementation support. Depending upon the kind of work you
want them to do, profiles of consulting companies can change. For example, for listing requirement/RFP,
you will perhaps look for a consulting service provider who have predominantly lots of business consulting
experience; for package implementation, the consulting company need to have strong product knowledge
and strong project management skill.
These days it is common to break a large implementation project among several consulting companies,
entrusting each company do a part of the whole work, i.e. there is one consulting company doing business
blueprinting and system configuration, another company doing developments and reports creation from
offshore, a third company doing technical maintenance of the system and there is a fourth company who
prepare all training materials for end users. The main reason for this kind of arrangement is to bring down
the overall implementation cost. However, this kind of implementation needs close coordination among
different companies. Most of the consulting service providers today use an onsite-offshore model where
part of the implementation work is done from a different location (i.e. an offshore location like India) and
activities that need closer customer interaction are only done onsite, i.e. at the customer place. However, this
is a common arrangement only for countries where the cost of implementation is quite high and in the case
of implementation in countries like India or China, most of the work is done at the customer location.
66 Enterprise Resource Planning

THINGS TO BE CONSIDERED FOR PARTNER SELECTION

Several factors need to be considered for selecting an implementation partner as shown in Figure 4.1. These
are explained here in details

Fig. 4.1 Selection Criteria for ERP Consulting Partner

Vendor’s Industry Experience

Whether the vendor has done quite a few ERP implementation in your kind of industry and know industry
issues and processes. Some of the large ERP consulting companies like IBM or Accenture have industry
template for most of the industries containing industry-specific processes and related system configurations.
This helps in quick implementation.

Process Consulting Experience

Any ERP implementation will need experience in process design, especially during Business Blueprinting
phase. Vendor’s experience, specifically in areas where you are looking for business benefits, the imple-
mentation consulting service providers need to have expertise in that area. For example, if you are looking
for improving your order fulfilment process efficiency through ERP implementation, you will expect your
consultant to share some best practices on order fulfilment, i.e. how leading companies of the world manage
this process, what metrics they follow, and what are the areas you need to improve or change the process.
Without improvement in process, if ERP is used just to automate your existing practice, chances of getting
much business benefits are remote. Remember that old equation:
Old Process + New Technology = Costly Old Process
 Selecting Consulting Partner 67

Client Reference and Client Satisfaction Level

Asking the consulting company to provide a list of client references preferably in the same industry and
in some cases in the same country (in case where implementation is limited to one country) is a common
practice. Experience in ERP implementation in the same industry states about consulting organisation’s
industry-specific business process knowledge. Implementation experience in the same country gives an
idea about its knowledge on country-specific regulatory requirements like excise, tax, modvat, etc. It is also
important to check how satisfied these clients are with the ERP implementation in their company.

Ability to Provide End to End Service

This can be a major criteria for some companies where they expect the service provider to do everything,
from RFP preparation to package selection to process consulting to configuration to testing to training and
to post-implementation support. A consulting company having capability in only one software package, say
SAP or Oracle, may not be in a position to offer service like package comparison.

Quality of Project Management

Knowledge in industry, process and product is not enough, if the project can not be delivered on time and
within the agreed budget. Strong project management skill is one of the key requirements for the consulting
company to drive the project, reaching milestones on time and keep the cost under control.

Quality of Tools and Methodologies

Most of the leading consulting companies have their own methodologies and tools for ERP implementation.
For example, IBM uses Ascendant methodology for ERP implementation. Methodologies help in a step by
step structured approach of what need to be done at each phase of project. Some consulting companies have
their own tools to speed up implementation and these can be things like data migration tool, auto testing
tool, etc. Strength of methodology and tools can be a deciding factor for which consultant to choose.

Presence in Different Geographies

For multi-country rollouts, it is important that the consulting company has office and preferably people who
can speak local language at different locations in different countries.

Global Delivery Capability

Delivery from low-cost countries has become a popular model for ERP implementation. Having presence
in low-cost countries (like India) with more number of consultants to bring down the total delivery cost is
presently used by several global players like IBM, Accenture, Cap Gemini. For large implementations these
days, it is difficult to win business for consulting companies if they do not have capability in this area.

Reputation
Reputation and branding are important factors of partner selection. The consulting company’s financial posi-
tion, ERP service revenue, alliance status with ERP vendors, vision, etc. all play a role here.

Price and Value for Money

Lastly, the most important criteria is pricing. Innovative pricing models, transparency in pricing, milestone-
based pricing, activity-based pricing, etc can help in the selection process. In many cases, two or three
 68 Enterprise Resource Planning

consulting service providers may come very close on the points mentioned above, and then price becomes
the major factor for the selection of one service provider and not others.
For selecting service providers for maintenance and support work, you can look at additional factors like
ability to provide hosting support, ability to provide application support, revenue from application mainte-
nance business, etc.
At the end, for selecting the final service provider, importance of all these criteria need to be decided and
each vendor’s rank on a particular criteria need to be established. The vendor having maximum point will
likely to be selected. Table 4.1 shows an exemplary matrix for selection of an ERP consulting company.

Table 4.1 ERP Consulting Company Selection Matrix

Criteria Weight Vendor 1 Vendor 1 Vendor 2 Vendor 2 Vendor 3 Vendor 3

rank weighted rank weighted rank weighted
rank rank rank
Industry experience 15% 3 0.45 4 0.6 3 0.45
Project management 10% 2 0.2 3 0.3 3 0.3
experience
Price 30% 3 0.9 3 0.9 4 1.2
Process consulting 5% 4 0.2 3 0.15 3 0.15
experience
End to end service 5% 3 0.15 4 0.2 4 0.2
Client references 15% 3 0.45 4 0.6 4 0.6
Global delivery 5% 4 0.2 3 0.15 3 0.15
capability
Methods and tools 5% 3 0.15 4 0.2 4 0.2
Presence 5% 3 0.15 4 0.2 4 0.2
Reputation 5% 4 0.2 3 0.15 3 0.15
Total 3.05 3.45 3.55
Ranks:
5 = Very good on this parameter
4 = Good on this parameter
3 = Average on this parameter
2 = Bad on this parameter
1 = Very bad on this parameter
Vender 3 is selected as per evaluation.

REQUEST FOR PROPOSAL METHOD FOR SELECTION OF

CONSULTING PARTNER
Request for proposal (RFP) method for consulting partner selection is common for large ERP projects and
mandatory for ERP implementations in government organisations. An RFP can have different sections like:
How and when the proposal/bid need to be submitted: This section has details on the date and time
by which the bid need to be submitted, bid security amount to be deposited, bid validity period, etc.
Overview of company’s business, current operations, locations from where it operates, etc.
 Selecting Consulting Partner 69

Current IT systems (Legacy systems) the company is using and which of them need interface with
ERP systems
High level scope of the project
Benefits the company is expecting from the implementation
Detailed scope of work: What the company is expecting the consulting service provider to do. For a
full-scale implementation, the company will look for things like: Project management and planning,
development of business blueprint, showing conference room pilot, system architecture design and
implementation, configuring ERP solution, data conversion and migration, conducting change man-
agement workshops, preparation of training material and conducting training, documentation, final
preparation and go live, providing go live and support, etc. Each of these activities can further be
detailed to identify the detail scope.
High level project duration that the company is looking for the implementation
The details of payment schedule and bonus / penalty related to that
Confidential Information: An ERP implementation exposes a company’s business processes and con-
fidential data to the consulting service providers. This may be a serious issue in certain industries like
audit firms, government, defence organisations, etc. If these things are used with wrong intention by
a consulting service provider, this may have issues in terms of loss of competitive advantage. RFPs
typically have a clause on non-disclosure agreement to protect the company from such risk.
Bidders for this RFP are supposed to submit their bids by a particular date and time. Bids are first evalu-
ated technically and then financially. The best bidders are awarded the contract.
Example
Given below is an extract from a particular RFP, “How payment schedule is articulated for selecting con-
sulting service provider”.

Description of task Payment schedule Milestone/deliverable

1 Project initiation 5% (Installment 1) Upon submission of inception report
2 Infrastructure recommendation 5% (Installment 2) Upon submission of infrastructure requirement report
3 TO-Be study and Gap 20% (Installment 3) Upon submission of solution blueprint document
analysis complete with GAP resolution
4 Solution development 20% (Installment 4) On completion of conference room pilot
5 Solution validation 20% (Installment 5) Upon end user acceptance after UAT
6 Execute cut over 20% (Installment 6) Upon go live acceptance
7 Post Go Live Support 10% (Installment 7) Upon post go live Support completion, on
stabilisation acceptance
Note:
1. Invoices will be raised on completion of milestone activities (as applicable), which are listed above. Stage payment
shall be released after fulfillment of the deliverables indicated under each activity at each phase, against a certificate
of acceptance of respective deliverable issued by Purchaser
2. Taxes and Duties: Except as otherwise specifically provided in the contract, the service provider shall bear and pay
all taxes, duties, levies, and charges assessed on them by all municipal, state, or national government authorities,
in connection with the goods and services supplied under the contract.
Performance bonus/penalty: If the project completes one month before due date as mentioned in the RFP project plan,
the consulting service provider is eligible for 3% bonus over the contract value. For any delay beyond 1 month 5%
penalty will be levied on service provider based on contract value. If there is a delay on company’s part for procurement
of hardware or not able to provide core team people on time – then this penalty is not applicable.
70 Enterprise Resource Planning

IN-HOUSE IMPLEMENTATION TEAM VS. EXTERNAL

CONSULTANTS
Whether ERP implementation team can not be done by in-house team? Why do you need external consult-
ants? These questions are usually discussed at company board meetings when the company first think about
implementing an ERP. Sometimes the principal reason for such discussion is high cost of ERP consultants.
Another reason is that ERP being the business software, the knowledge about company’s business is essen-
tial for implementing this. Company’s own people have much better knowledge about company’s business
than external consultants.
In the past, a few companies had taken this approach. They formed a core team of senior managers from
business and IT departments, got them trained in ERP software and started implementing on their own.
However, most of these implementations failed. Some of these implementations had taken help from external
consulting team mid-way during the project to complete this.
It’s important to understand that implementation is the core business of ERP consulting companies. They
have better trained people who had done several implementations, are aware of processes and industry chal-
lenges and can solve complex technical issues. These consulting companies over the years had developed
methodologies and tools to make the implementation faster, better and cheaper. They have better relation-
ships with ERP vendors and can get preferential support for them. A company trying to implement ERP on
their own misses out on all these.
The advantages and disadvantages of this approach are:

In House Implementation—Advantages
Need not pay external consultants
Team may have better process knowledge

In House Implementation—Disadvantages
External consulting team will have better package knowledge
In house team do not have access to methods and tools which a consulting company brings as a part
of their implementation methodology
Implementation is not their core competency
May lack on ERP project management skill
Overall may not work out to be cost effective if all internal costs are factored
Figure 4.2 shows Pros and Cons of In-house implementation.

In House Implementation—Where It may Work

This strategy works well for roll out kind of project. If a global company had done the first ERP imple-
mentation at a particular country with help from a consulting company and then wants to roll out the im-
plementation in 50 other countries where they have operations, then the strategy may work. During the first
implementation they built a core team, who worked with the consulting company for 12-18 months during
the first implementation, learnt the package very well, had got a full life cycle implementation experience,
built a global template and now trying to roll out the same template in different countries with little bit
country-specific changes. The old in-house team can now handle such implementations with little bit external
consulting help on specific areas.
 Selecting Consulting Partner 71

Fig. 4.2 In-house Implementation Pros and Cons

ERP CONSULTING COMPANIES

A host of companies provide ERP implementation services these days. These companies range from Global
consulting companies, large system integrators to small local IT companies. The leading players in this
segment are:
IBM
Accenture
Deloitte
Cap Gemini
HP-EDS
CSC
Bearing Point
Infosys
Wipro
TCS
HCL-AXON
Cognizant
T Systems
Siemens
Atos Origin
Intelligroup
L&T Infotech
The top tier consists of two players: IBM and Accenture. These two companies have presence in almost
all countries in the world. They have implemented enterprise solutions in few hundred companies. They use
right onsite and offshore model to bring down cost and have right consulting skill to understand clients’ busi-
ness requirement and build that in the solution. They consistently rank in the Leader segment in “Gartner’s
Magic Quadrant of ERP Service providers for Europe, 2009”, “Gartner’s Magic Quadrant of ERP Service
providers for North America, 2009”, “Forrester Wave™: SAP Implementation Providers, Q3 ’09”.
 72 Enterprise Resource Planning

In the next tier, there are global consulting companies like Deloitte, Cap Gemini and Bearing point; global
IT companies like CSC and HP–EDS; and leading Indian IT consulting companies like Infosys, Wipro, TCS
and HCL–AXON. All these companies come under leader segment in “Forrester Wave™: SAP Implementa-
tion Providers, Q3 ’09”. These companies also have lot of implementation experience and have presence
in low-cost countries to bring down cost of implementation. However, few of them lack in terms of global
presence and industry consulting experience.
The next tier includes companies like Cognizant, T Systems, Siements, Atos Origin, Intelligroup, L&T
Infotech, Logica, Fujitsu, etc.
The lowest tier of enterprise consulting is covered by innumerable IT and consulting companies that have
presence in a particular country, in a particular industry or which work as a subcontractor to the companies
mentioned above during a particular phase of the project.
Figure 4.3 shows different players in this segment.

Fig. 4.3 Global ERP Consulting Companies

DOING PART OF ERP PROJECTS FROM OFFSHORE

Doing part of ERP projects from offshore, i.e. from a low-cost country, is a strategy almost all leading ERP
consulting companies are following today. The reasons are obvious—Much reduced labour cost (in countries
like India or China compared to that of U.S. or Europe); specialised expertise for each set of activities (like:
configuration, testing, data migration, etc); and time zone difference that make it practically possible to work
round the clock on project deliverables from some part of the world to reduce the total project duration.
Though in every phase of the project some activities can be covered from offshore, the percentage dif-
fers in different phases. Typically, the Realisation phase of the project is the one where there is a scope of
offshoring maximum percentage of activities. In an article “Offshore SAP Implementation, Upgrades, And
Support: What You Need To Know” dated April 5, 2005 by Stephanie Moore of Forrester Research had
argued that in project phases like Realisation, Final Preparation and post-Go Live Support close to 50-70%
of the activities can be done from offshore. The reason being unlike Business Blueprinting phase where
 Selecting Consulting Partner 73

there is a need to reach out to a Business User for understanding a process, the activities in Realisation and
Final Preparation stage mostly need limited inputs from business users.
Table 4.2 shows the offshore activities in quantifiable terms for each phase of an ERP implementation
project.

Table 4.2 Phase-wise Type and Quantity of Offshore Activities

Project Phase % of activity % of activity Type of activity from offshore

from onsite from offshore
Project Preparation 100% 0%
Business Blueprint 90% 10% Building proof of concept/demo scenarios, blueprint
documentation (partial)
Realisation 30% 70% Configuration, testing, developments
Final Preparation and 50% 50% Data migration, end user training content
Go Live preparation
Support 20% 80% Resolving issues, running routine utility jobs, system
developments, managing change requests

Activities that are commonly get offshored:

Development
Unit testing, volume testing
Training content preparation
Activities that can be offshored in limited extent:
Configuration
Data migration
Activities that is difficult to offshore:
Business blueprinting
Integration testing
User acceptance testing
End user training
Change management activities
As testing, development and configuration takes close to 40-50% of project effort, doing these activities
offshore can give substantial cost benefit to the project. The important thing to remember is that it is dif-
ficult to do an activity 100% offshore. There is always need of some onsite presence. For example, during
development, the onsite coordinator ensures that functional specifications are written properly onsite and
transferred to the offshore team; the offshore team understands it well; and post-development, these objects
are tested properly by the onsite core team members. Success of such onsite-offshore model depends a lot
on how effective this coordination is.
While leading Indian IT companies like Infosys or Wipro already doing a good percentage of their ERP
project works for their clients in Europe and US from India, all global consulting companies (like: Accen-
ture, IBM, Delloite, HP, Capgemini, etc) have opened Global Delivery Centres (GDCs) in India and China
to deliver large component of ERP projects from offshore. Gradually, offshore capability of a consulting
partner has become one of the most important parameters for consulting partner selection as everyone wants
to do ERP implementation cheaper, faster and better.
74 Enterprise Resource Planning

Summary
A variety of factors need to be considered while selecting a consulting partner for an ERP project. Partner’s
reputation, industry experience, process experience, methodology and tools for implementation, end-to-end
service capability, project management capability, client references and satisfaction and finally pricing are
the deciding factors for selection.
Large organisations, especially government organisations, adopt RFP (Request for Proposal) method for
partner selection.
While hiring external consultants is the most common method of ERP implementation, in some cases
companies decide to do the implementation of their own with their in-house team. While this approach is
quite successful for rollout projects and for a first-time implementation, in most cases it may work out to be
risky.
ERP consulting companies can be grouped into three tiers – while the top slot is occupied by IBM and Ac-
centure, Global consulting companies like Cap Gemini, Delloite, Bearing Point and HP are in the middle tier.
Leading Indian consulting companies like Infosys, TCS and Wipro also come under this group. The bottom
of the pyramid is occupied by numerous small players.
Doing a part of ERP project from a low-cost country (offshore) provides substantial cost and time zone
advantages. Typically, activities during Realisation, Go Live Preparation and Post-implementation Support
can be offshored. Large global consulting companies are opening their Global Delivery Centres in countries
like India and China to offer such services.

Exercise
I. Objective Type Questions
1. Who are the two leading ERP consulting companies globally?
2. What activities can be done during support phase from offshore/remote locations?
3. What activities can be done during final preparation phase from offshore/remote locations?
4. What activities can be done during realisation phase from offshore/remote locations?
5. In which phase of a project maximum activities can be done from offshore?
6. What are the two advantages of in-house implementation team?

II. Descriptive Type Questions

1. What things need to be considered for an ERP partner selection?
2. Define an approach to develop a selection matrix for the ERP partner selection?
3. What can be the different components of RFP for selecting consulting partner?
4. What are the advantages and disadvantages of having an in-house ERP consulting team vs. having an outside
partner?
5. What type of activities in an ERP project can be done from offshore? In what phase of ERP project how
much of activity can be offshored?
6. How is the ERP consulting market segmented and who are the leading ERP consulting companies?
 Selecting Consulting Partner 75

III. Fill in the Blanks

1. RFP stands for _______________ _____________ _______________.
2. GDC stands for _______________ _____________ _______________.
3. _______________ is the ERP project phase in which maximum activity can be done from offshore.
4. The top two ERP consulting companies are _________ and _____________.
5. Types of activities that can be done from offshore during project realisation are _______, ___________ and
_________.

IV. State Whether the following Statements are True or False

1. Business Blueprinting is the phase where maximum activity can be done from remote location.
2. In support phase most of the activities can be done from a remote location.
3. RFP process is must for consulting partner selection.
4. Maximum percentage of payment is made during project initiation to the consulting partner.
5. GDCs are generally located at low cost countries like India, China, etc.

V. Assignments
Visit a company which had recently gone for ERP or in the process of ERP implementation. Talk to some
of the business managers and IT department who were part of the team who had selected the consulting
partner. How had they gone about their ERP partner selection process? Why had they selected a particular
partner?
 5
ERP Package Selection
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Criteria for initial package screening
Initial package shortlisting
Final package selection
RFP process for package selection
Finalising the contract with ERP package vendor
ERP package market

INTRODUCTION
There are more than hundred ERP packages available in different sizes, with different features and for dif-
ferent pockets. Each of them had its origin in a particular industry having a set of business processes and
later more modules were added to it. Some features of ERP packages are:
Some of them can be very strong in particular processes like Peoplesoft in human resource, BAAN
in manufacturing, etc.
Some of them can be strong in particular industry like Mincom in mining, Retek in retail industry,
Ramco in Utilities, etc.
Some of them can support particular database (like JD Edwards supports DB2, Oracle supports Oracle
database, etc) and some of them support all leading databases (like SAP).
Some of them support particular operating system (like few ERPs only runs on Windows operating
system), some of them support all leading operating systems, etc.
Selecting the right ERP package can be a make or break for success of ERP project. Several factors need
to be considered for this selection. It is also important to remember that no package will meet a particular
company’s 100% need as these packages were not created particularly for this company, but for a wide
variety of companies. The idea of selection is to find out a package which is “good fit” with the company’s
business requirements and can support the company’s long-term goals. What a company thinks as a “good
fit” can be differed by another company. However, if the ERP package meets 75-80% of a company’s
business requirements, then it is considered as a “good fit”.
 ERP Package Selection 77

Who Will do the Selection?

Typically, a small team from the company, comprising of different department heads and company’s top
management (CIO or CFO), is a part of the selection committee. They have fair idea about company’s busi-
ness requirements and what the company is looking for. The selection committee also has few consultants
who know the leading packages well. The selection committee defines the selection process and the selec-
tion criteria; attends all presentations by the vendor; puts relevant questions to them, makes a comparative
analysis of different ERP vendors and finally selects the ERP package.

How to Deal with ERP Vendors?

Usually, each ERP vendor claims that they have the best solution for the company and tries to impress the
selection committee through great presentations. Sometime these presentations confuse the selection com-
mittee as each vendor’s presentation looks pretty alike and each ERP solution presented seems meeting the
company’s requirements. So, it is extremely important to do a good preparation and keep a game plan ready
before attending such presentations. Some of the tips that can help are:
Have your list of requirements ready and during the presentation, ask the vendor questions on how
some of the tricky requirements of the company can be met with.
Ask the vendor to give a demo and to run some of your critical business scenarios in their ERP system.
This not only helps understand the scenario being addressed in the ERP, but also gives a first-hand
look at the ERP screens of the vendor, telling how user friendly is the ERP’s user interface, etc
Ask for reference sites where the selection committee can visit and hear from the users, what problems
they are facing with the ERP, what business benefits they are getting, etc. It always makes sense to
visit a reference site in the same industry segment as that of the company implementing ERP.
Ask the vendor how different are their ERP packages from that of other ERP vendors?

ERP SELECTION—A TWO-STEP PROCESS

Most of the companies follow a two-step approach for package selection. Evaluation process can start with
large number of packages (say, five packages) and based on a set of criteria, few of them (say, two to maxi-
mum three) are short-listed. This process is called screening. Now these two or three packages are compared
against the list of requirements of the company. As there can be few hundred requirements, comparison of
more than two or three packages will be labourious and time-consuming. After the detailed evaluation of
these short-listed packages, one package is selected and the company enters into contract with the vendor
of the selected package. Figure 5.1 shows the detailed process of ERP selection.

Criteria for Initial Package Screening

A company can look at a set of criteria as shown in Figure 5.2 for ERP package screening, i.e. for selecting
3-5 packages from hundreds of ERP packages available in the market. These criteria are detailed below:
A. Product Strategy, Vision and Investment in Innovation This criterion includes product’s
long-term strategy and roadmap, what is planned in the next few releases of the product, what kind of
innovations the product vendor has brought in the application market, whether the product supports the
emerging trend in the industry, etc.
Product strategy will include product’s strategy for different geographies (i.e. different countries may
need specific, but varied enhancements as per their country regulations in areas like tax, excise duty, mod-
vat, accounting practice, import-export rules, etc) and for different industries (to meet industry-specific
78 Enterprise Resource Planning

Fig. 5.1 ERP Package Selection Process

Fig. 5.2 ERP Package Selection Criteria

requirements). For companies in mid market segments, the products may have specific offerings that suit the
budget of these companies. The application vendor’s total investment in R&D as a percentage of revenue is
a good indicator of their seriousness in innovation. The leading application vendors publish their applica-
tion roadmap and statement of direction these days which talks about where their application is headed and
what new features is going to come in the next few releases. Before taking any decision on a package, it is
worth looking at these documents.
 ERP Package Selection 79

B. Financial Viability of the Application Vendor This has become a major area of concern these
days as in the past many application vendors had either gone bankrupt or changed hands several times.
Examples of such application vendors are given below:
JD Edwards, one of the top five ERP vendors, was first taken up by Peoplesoft and then by Oracle.
Peoplesoft, one of the top five ERP vendors, was taken over by Oracle.
BAAN a leading ERP vendor was bought and sold several times.
Manugistics, one of the top three SCM vendors, was sold to JDA.
Siebel, the top CRM vendor, was sold to Oracle.
Retek, the leading retail CRM vendor, was sold to Oracle.
Commerce One, the leading e-Procurement vendor, no longer exists.
Though merger and acquisition is a part of enterprise application market, yet every time when there is a
change in the management of the application vendor, it creates confusion for customers regarding who will
support the application in future, whether they will get the same level of support when the new manage-
ment of the application company will come up with the next release/upgrade of the product, whether earlier
announcements regarding the product upgrade will still remain valid, etc.
This is one of the reasons why most of the companies want to stick to the two largest vendors of enter-
prise application market (SAP and Oracle). An application vendor which meets 90% of your requirements,
but can not support you after 2 years is not the right choice. It is perhaps, a better decision to go with a
vendor which meets 80% of your requirements, but financially very strong. Another point is that vendors’
application roadmaps usually change with time and so, the vendor who is at 80% today may cover up the
rest 10% by the time your project actually starts.
Financial viability of the application vendor can be obtained from company’s balance sheet. The important
things to look for are company’s turnover (the more the turnover, the less is the chance for the vendor being
taken over), company’s revenue growth (a negative growth for last few quarters is not a good indicator),
cash reserve, financial ratios, etc.
C. Installed Base and Local Presence This measures the number of places where vendor’s applica-
tion is implemented. It is recommended to look for installed base in the same industry and same geography.
For example:
A company which is in oil and gas business and looking forward to an ERP implementation need
to look for how many installations the application vendor has in the same industry. More number of
installation here means the application has functionalities that suit the requirement of this industry.
In the same way, a company in a particular geography (say, India) may look for how many installations
the product has in Indian market and if there are more installations being done. It means that the com-
pany has made India-specific extensions in areas like excise duty, tax, payroll, etc. More installations
in a specific country also mean that the company has local offices and local infrastructure to support
those installations. A company need to be careful if the chosen ERP vendor’s entire infrastructure is
in a country 3000 KMs away.
In the same way a multinational company rolling out an ERP application in 30 countries, may look
for installations of the particular vendor in all these/or most of these countries.
In some cases, if you are interested in implementing specific part of the application first (say, human
resource), it is better to look for number of installations where the vendor’s similar module (human
resource in this case) is implemented.
80 Enterprise Resource Planning

D. Partnerships This may mean variety of things like:

Implementation partnerships with consulting companies: How many consulting companies can
implement the application vendor’s package? If there are many consulting companies, the organisation
will have better options to select the consulting service provider and can adopt a proper methodology
as described earlier to select the service provider. If there are only few consulting companies who can
implement the application, choices in the hand of organisation is limited. For example, if you are a
company in India and looking forward to do an ERP implementation, but for the package you have
selected, there is only one consulting company in India which can offer consulting services. In that
case, you do not have any option to do any evaluation of the consulting service provider. Most of
the leading ERP providers like SAP and Oracle have lots of consulting partners. For example, these
products can be implemented by a number of global consulting companies (IBM, Accenture, HP, Cap
Gemini, Delloite, KPMG, CSC, etc) and leading Indian IT players (like Infosys, Wipro, TCS, Cogni-
zant, etc). This is one area where leading vendors score higher than the nitch application vendors.
Application partnership with other third party applications: Any ERP vendor can not meet all
business requirements of any organisation. So, it is important that ERP vendors know these gaps and
tie up with other application vendors who provide offerings in this area. These partnerships can be for
a typical industry-specific requirements (say, an ERP provider tie up with a nitch vendor in healthcare
sector to meet healthcare industry-specific requirements), for a typical country requirements (say, an
ERP provider tie up with a nitch vendor in U.K. who develops applications to meet U.K. payroll and
customs requirements) or for a specialised business process related requirements (say, an ERP vendor
ties up with a nitch vendor which provides application for shipment tracking). Leading ERP vendors
like SAP and Oracle today has tie up with hundreds of such Independent Software Vendors (ISVs) to
offer solution for a customer for any country, for any industry and for any specific business process.
As ERP vendor and an ISV go together to market for such opportunities which is a win-win for both
of them.

E. Technology Maturity Technology maturity of the application means multiple things like:
a. How many different database platforms the application supports? There can be several choices like
IBM DB2, Oracle, SQL, Sybase, etc.
b. How many different operating systems the application supports? The choices here can be Unix, Win-
dows NT, etc.
c. How many different server platforms can be used to run the application? The choices here can be IBM
platform, HP platform, etc.
d. How many different middleware platform the application supports?
e. Whether the application supports industry standards like Rosettanet?
f. Whether the application can be hosted?
g. Scalability of the solution: The scalability of the solution is important. For example, if the transac-
tion volume goes up twenty times from the current volume, the application should be able to support
that.
h. Flexibility of the application.
i. Integration and openness of the system, i.e. the extent to which the product supports open technology
standards and has tools for integrating with other third party applications.
Technology maturity of the application is an important criteria for selection of an ERP package as tech-
nology keeps on changing and the selected application need to support technology innovations during the
entire application life cycle.
 ERP Package Selection 81

F. Vendor’s Customer Services How the ERP vendor supports the entire life cycle of the applica-
tion is also an important criteria for ERP package selection. ERP vendor can provide customer service in
a variety of ways like:
Providing regular software support like bug fixing, etc
Supporting implementation of future releases of the application
Supporting future upgrades of the application
Community programs for customers, i.e. keeping them updated about the latest patch, new releases,
new functionalities, etc.
These are discussed in detail in chapter 19 ‘Application Support’.

G. Cost of the Software Finally, cost of the software is one of the most important criteria for final
selection, especially for most of the small and medium customers. Increasingly, companies are looking at
total cost of ownership of the application, i.e. if the vendor’s license cost is high but it can provide tools and
accelerators which reduce implementation time and cost, the TCO (Total cost of ownership) comes down.

Initial Package Shortlisting

Based on the above criteria, packages are given different weightage (as mentioned in Table 5.1). Packages
(top two to three packages) scoring highest in this method are shortlisted.

Table 5.1 Weightage and Criteria for Shortlisting Packages

Initial Shortlisting Criteria Package 1 Package 2 Package 3 Package 4 Package 5

Product strategy, vision 4 3 3 4 2
Financial status of vendor 4 3 2 3 3
Installed base, local presence 4 4 3 2 3
Partnership 5 4 3 4 2
Technology maturity 4 4 3 3 2
Vendor’s customer service 4 3 3 4 3
Cost of the application 2 3 4 4 5
Total 27 24 21 24 20

Packages 1, 2 and 4 are taken for the next level of evaluation, based on the total weightage given to pack-
ages.
Key to weightage:
5 – Very good
4 – Good
3 – Average
2 – Bad
1 – Very bad

Final Package Selection

Top three packages shortlisted through the earlier exercise are taken up in this round for detailed function-
 82 Enterprise Resource Planning

ality evaluation against the business requirements of the company. Against the functional requirements as
mentioned in RFP, different package vendors indicate whether the application can straight away meet the
requirement, whether the requirement can be met in an alternate way or whether the requirement can not
be met at all. There can be hundreds of such requirements. In the following example, the company has 300
such requirements, out of which only five are evaluated.

Functional requirements Criticality Package 1 Package 2 Package 4

FM PM NM FM PM NM FM PM NM
1 Creation of purchase order Vital Y Y Y
2 Creation of invoice Vital Y Y Y
3 Capability to book order Vital Y Y Y
4 Entering enquiries in the system Essential Y Y Y
5 Capability of e-Procurement Desirable Y Y Y
..
..
300
FM: The application meets the business requirement directly
PM: The application partially meets the requirement, i.e. the requirement can be met by development or changes in the
source code of the application
NM: The application does not meet the business requirement
How the business requirements are met, based on that individual vendor is given a point against a particular
functionality and the point distribution is as follows:

Requirement category FM PM NM
Vital 6 5 0
Essential 4 3 0
Desirable 2 1 0

Now based on this, different package vendors are evaluated:

Functional requirements Criticality Package 1 Package 2 Package 4

FM PM NM FM PM NM FM PM NM
1 Creation of purchase order Vital 6 6 5
2 Creation of invoice Vital 6 5 0
3 Capability to book order Vital 5 6 5
4 Entering enquiries in the system Essential 4 3 3
5 Capability of e-Procurement Desirable 2 2 2
..
..
300
Total 18 5 14 8 2 13 0
Total Score 23 22 15
 ERP Package Selection 83

In this example, both Package 1 and Package 2 come pretty close in terms of functionality. Choices between
the two will be mostly driven by cost and service quality. This is an example of how scientifically packages
can be evaluated and selection can be made in favour of one.

Deviations in Package Selection Process The package selection process described above is though
an ideal way of selecting an ERP package, yet it is not necessary that every time the package selection needs
to follow this process. There can be deviations in this process due to the following:
A company tells its main supplier to implement a particular ERP so that both can be on the same
platform and interatction between them would be easier. This is quite common for automobile com-
panies and their part suppliers. A supplier’s ERP choice is mostly determined by the ERP their main
customer uses.
A group company wants to implement the same ERP what the mother company has: It can be a good
decision provided most of the business requirements are met by this ERP. The same ERP will actually
solve lot of problems of integration/business consolidation, etc.
For a small company the ERP decision can be driven a lot by the ERP price. They may not go for the
best ERP which meet all their business requirements for one simple reason “It is costly”.
For certain industries one ERP may be very popular as it offers lot of industry-specific nitch function-
ality. Retek for Retail Industry, Mincom for Mining industry, Aspentech for oil and gas industry are
examples of such ERPs.

RFP Process for ERP Package Selection Request for Proposal (RFP) process for selecting an ERP
package is quite common for large ERP projects and mandatory for all government organisations who intend
to go for ERP. A typical RFP document can have different sections detailing with:
How and when the proposal/bid need to be submitted: Details on the date and time by which the bid
needs to be submitted, bid security amount to be deposited, bid validity period, etc.
Overview of company’s business, current operations, locations from where it operates, etc.
Current IT systems (legacy systems) the company is using and which of them need interface with ERP
systems
High level scope of the project
Benefits the company is expecting from the implementation
Detailed scope of work: What the company is expecting from the ERP vendor to do. This can have
things like ERP installation, providing training in the software, providing support for all software bugs,
doing an audit before the system goes live, etc.
The details of payment schedule
Bidders for this RFP are supposed to submit their bid by a particular date and time. Bids are first evalu-
ated technically and then financially. The best bidders are awarded the contract.
RFP document can specify in detail on what date what is expected out of the ERP package vendor. Table
5.2 is an extract from a government RFP for ERP package selection.
84 Enterprise Resource Planning

Table 5.2 Package Selection Calendar (RFP based)

When What Who

1st Jan. Issue RFP to ERP package vendors Company
7th Jan. Workshop hosted by the company to enable ERP package vendors to explain the Company
list of requirements and expectations to help them respond better
12th Jan. Submit questions/clarifications on RFP ERP Vendor
18th Jan. Formal response to questions Company
31st Jan. Submit RFP response ERP Vendor
7th Feb. Presentation by ERP vendors to selection committee to explain their response ERP Vendor
20th Feb. Detailed review of RFPs Company
25th Feb. Questions/clarifications to ERP vendors on their response (if any) Company
7th March Respond to these questions/clarifications ERP Vendor
25th March Final evaluation of responses Company
31st March Deciding and announcing the winner Company

One of the ground rule for RFP-based response is that each vendor should have same information for
quoting their price, i.e. if one vendor knows more about the company, its processes, its current IT systems,
etc more than what is provided in RFP document, then he may be in a preferential position and may give a
better price quote. This should be prevented as far as possible.

Finalising the Contract with ERP Package Vendor

The final step in the ERP package selection process is completing the contract formalities with the ERP
vendor. Contract is a legal obligation for both the parties. Generally, for the package vendor there will be
standard contract clauses covering the following things:
Payment term: Sometimes this becomes an area of dispute between package vendor and the company.
While the vendor will like to have 100% payment against installation, companies prefer to give dif-
fered payment as the project progresses
Intellectual property or copyright clauses: This covers the clauses like who own the source code (the
package vendor), who own the modifications and customisation rights to the code etc. Any misuse of
the package can be a contract violation
List of deliverables along with software
How training for the software will be handled
How the software maintenance will be handled, what will be included in the maintenance, different
support mode—onsite, telephonic, etc, yearly maintenance costs
How future upgrades for the software will be provided and at what cost
Software installation help to be provided
Prerequisite to install the software – the hardware specification, operating system needed, database
needed, etc
Any audit or review by the package vendor during package implementation (like final blueprint audit,
audit before going live, etc)
Licence cancellation costs
 ERP Package Selection 85

Generally legal teams from both sides do a final validation of the contract clauses before signing. Some-
times this can be a time consuming process as there can be several negotiations on contract clauses before
agreeing on something which benefits both sides.
It is important to remember that ERP package procurement is not a one-time transaction with ERP ven-
dor. Help of ERP vendor is needed through out the package life cycle for supporting the application, for
upgrading, for training the company in new functionalities of the ERP package, etc. It needs to be a win-win
relationship for both.

ERP Package Market

There are innumerable packages in ERP space to fit the budget of every possible customer. However, for
the ERP market, SAP and Oracle are the undisputed market leaders for the last several years where SAP
enjoys almost double market share than that of Oracle. The next few players in this market are: Infor, The
Sage Group, Microsoft Business Solutions, Lawson, Epicor, IFS, etc. Figure 5.3 shows different players of
ERP market. There are innumerable small ERPs in the lower end of the market and there are ERP packages
which cater to particular industry segment. For example, Mincom, is a very strong ERP for mining segment,
Retek (before it was taken over by Oracle) was a strong ERP for retail industry. Ramco, a leading ERP
package vendor out of India is a strong player in utility segment.

Fig. 5.3 ERP Market—Leading Players

The major challenge for small ERP today is that SAP and Oracle have also come out with low cost of-
ferings for SMB (Small and Medium Business). SAP has offerings like All In One (for the mid-segment of
the market) and Business One (for small companies) for this segment. SAP and Oracle is also coming out
with pre-configured templates (which is loaded with industry-specific configurations, business blueprints,
test cases, etc) to reduce time and cost of implementing solutions. This had come to a stage where from a
TCO (Total cost of ownership) perspective implanting SAP’s Business One or All In One is not very ex-
pensive to that of implementing IFS or Epicor. The major risk of going for low cost solutions today is that
the company may go out of business in next few years and the lifelong support of the application becomes
86 Enterprise Resource Planning

a challenge. That is one of the reasons why even in SMB segment, SAP and Oracle are doing good busi-
ness and several companies in India having turnover between 300-400 crore (Typically a segment for Tier
2 ERP vendors) had opted for these two ERPs. In SMB segment also there are ERPs from large business
houses like Microsoft Business Solution (from Microsoft) and Lawson (Owned by IBM) and stability of
the company offering the solution is not an issue here.

Summary
Selecting the right ERP package is critical for the success of the ERP implementation.
ERP packages come with different features, different technology platforms and at different budget.
A selection committee is formed to decide the ERP package for which the company would go for.
It is important to assess the ERP vendors effectively by asking them pointed questions in their detailed pres-
entations and visiting the reference sites.
ERP package selection is a two-step process starting with screening of lot of packages and finally detailed
evaluation of a few.
Product strategy, vision, financial viability, installed base in the same country and in the same industry,
technology maturity, cost and customer service are some of the important factors considered for screening
of ERP packages.
Final package selection is based on an evaluation of each specific requirement as to whether a particular ERP
meets it fully, partially or does not meet.
Sometimes package selection is also influenced by group companies, customers, cost, etc.
Government organisations and sometimes large private organisations follow RFP process for ERP package
selection which has defined dates for doing predefined set of activities.
Entering into a contract with the ERP vendor is the final step in ERP package selection process.
ERP market is presently dominated by SAP and Oracle, followed by Microsoft business solution, Lawson,
etc. There are hundreds of small ERPs in the low end of the market where the competition has been intensi-
fied with low cost solutions of SAP and Oracle entering the market.

Exercise
I. Objective Type Questions
1. Who are the two leading ERP vendors globally?
2. Name few other leading ERP vendors.
3. Name some industry-specific ERPs and their focus industries.
4. Name some ERPs which are strong in particular processes and what processes do they focus?
5. What are the top three acquisitions by Oracle in recent times?
6. Typically how many packages does a company shortlist for final evaluation?
7. ERP package selection is a two-stage process – what are the two stages?
8. What is the final step of ERP package selection process?
9. What is meant by installed base?
10. What is meant by copyright clause?
 ERP Package Selection 87

II. Descriptive Type Questions

1. Explain the typical process steps for an ERP package selection.
2. What are the criteria for initial package screening? Explain each one of them in few lines.
3. Why financial viability and installed base are important criteria for ERP package selection?
4. What is meant by technology maturity of a package vendor?
5. What are the different types of partnerships that an ERP package vendor can have and why it is an important
criterion for package selection?
6. How is the final package selection done?
7. Give some examples and reasons why in some cases the package selection is not done in the traditional
way and get influenced by other factors.
8. Explain the RFP process of ERP package selection.
9. What are the typical terms of contract with an ERP package vendor?
10. How ERP package market is segmented and who are the players?

III. Fill in the Blanks

1. ISV stands for _______________ _____________ _______________.
2. SMB stands for _______________ _____________ _______________.
3. TCO stands for _______________ _____________ _______________.
4. Peoplesoft was taken over by ____________.
5. Retek is a _________ industry-specific vendor.
6. Siebel is a leading __________ __________ management solution package.
7. Peoplesoft is strong in _________ ___________ processes.
8. Leading Operating systems that ERP vendors support are ________, _______ and __________.
9. Package vendor need to provide regular support like ________ fixing.
10. Submitting RFP response is ___________ _____________ responsibility.

IV. State Whether the following Statements are True or False

1. ERP software bugs are handled by the consulting partner.
2. SAP’s Business One solution is an offering for SMB sector.
3. Generally ERP code is the copyright of the company who buys the ERP package.
4. RFP process of package selection is mandatory for government organisations.
5. Openness of ERP software means flexibility of business process in the package.

V. Assignments
Visit a company which had recently gone for ERP or in the process of ERP implementation. Talk to some of the
business managers and IT department who were part of the team who had selected the ERP package. How had
they gone about their ERP package selection process? Why had they selected a particular package? Whether they
had used any quantitative rating approach or qualitative criteria?
 6
ERP Project Team and
Project Organisation Chapter
Structure

Learning Objectives
In this chapter we will discuss the following concepts:
ERP project organisation structure
Roles and responsibilities of different project team members
Consulting team
Core team

INTRODUCTION
Success or failure of an ERP implementation depends mainly on the composition of the implementation team.
Different team members have different roles. While from the business side it is expected that the team in
charge of implementation will spell out the business requirements clearly, work with the consulting team to
configure the system and finally test it thoroughly before going live, from the consulting side the expectation
is that they will have very good knowledge in the application, will be able to model the business require-
ments to a software solution, train the core team from business side and finally do the handholding when
going live. Senior leaderships are expected to drive the implementation, handle change management, take
critical decisions on TO BE design options, handle project escalations and finally sign off the deliverables
at every stage of the project before it moves to the next stage.
ERP project team is generally made up of two different teams—one from consulting side and the other
from the organisation implementing the ERP solution. The second team is also called the core team. The two
teams compliments one another skill-wise. While the first team brings with it lots of product knowledge and
implementation experience, the second team brings with it the necessary business knowledge. Successful
knowledge transfer from one to other ensures that the project is successful, i.e. the processes are designed
with right business inputs (where core team can provide lots of inputs) and designed processes are rightly
mapped/configured in the application package (where consultants play a bigger role).
 ERP Project Team and Project Organisation Structure 89

PROJECT ORGANISATION STRUCTURE

Figure 6.1 shows a typical ERP project organisation structure which is discussed below:
At the highest level, there will be a project sponsor. A typical project sponsor will be a CIO or CEO
or CFO of the organisation implementing ERP.
Below the project sponsor, there will be a steering committee comprising of different heads of depart-
ments like marketing, finance, operations, human resources, etc. Steering committee also has members
from the consulting organisation selected for ERP implementation. A fairly senior level executive
from the consulting organisation can be part of it and typically named as “Project Director”. Steering
committee meets at regular frequency (say, once in a month) and takes critical decisions about the
project.
Process owners are typically the final decision-makers about a process.
Below the steering committee, there are project managers both from the company side and the consult-
ing organisation side who are responsible for running the project and handling all day to day issues.
Below the project manager for the consulting team, there are different functional module leads (module
lead for production, procurement, finance, human resource, maintenance, quality, etc) and Technical
lead (for programming, system administration, etc). Leads will have team members under them, i.e.
procurement team lead may have three procurement consultants reporting to him. There can be few
industry SMEs (subject matter experts) also who can add value to the project by bringing knowledge
about some best practices of the industry (industry in which the company is) during process design and

Fig. 6.1 Project Team Structure (Client & Consulting Company)

90 Enterprise Resource Planning

generally they are not full time members in the project. Project manager can also have an integration
manager responsible for overall integration aspects of the project and success of integration testing
phase. Finally, this team also can have few change management consultants.
Below the project manager of the company implementing ERP, there will have a set of core team
module leads (i.e. leads for procurement, finance, human resource, etc) and a set of extended team
members who do not spend full time in the project but will be needed to provide inputs on specific
processes which core team members can not provide. Each of the core team module lead can have
team members below them. In some projects, project manager can also have a training manager and a
data manager. While training manager has the overall responsibility of organising training programmes
for the entire organisation, data manager will ensure availability and accuracy of data loaded into the
system. Depending on the size and complexity of project, these can be either full time or part time
roles.

ROLES AND RESPONSIBILITIES OF DIFFERENT PROJECT TEAM

MEMBERS
Different people play different roles in the project. Brief roles and responsibilities of different people
associated with project implementation are discussed here:

Project Sponsor
Communicates company’s long-term goals and visions to the implementation team
Is a member of the executive committee
Takes responsibility for the project
Maintains regular and visible contact with the project
Assists in clearing organisational obstructions to the project
Makes business decisions on issues escalated by the steering committee
Accept deliverables on behalf of the company

Steering Committee
The Steering Committee meets once in each month during the project period to receive an update on the
progress of the project and to resolve any issues. The committee is also responsible for providing a vision
of the company’s long-term goals and objectives, setting priorities, and approving scope. They will aid
in promoting the system implementation and provide support to the project throughout the organisation.
This committee is generally responsible for resolving issues that cannot be resolved by the implementation
team.

Process Owner
Process owners are typically the final decision-makers about a process. There can be process owners for
each critical process like order fulfillment process, procure to pay process, etc. In a typical organisation,
generally you do not have this position and you have departmental heads. However, these positions are
important for ERP implementation as ERP looks everything from a process perspective that can cut across
several departments. Most of the organisations promote some of their existing senior departmental heads
to this role. For example, the current operations head can become the process owner for order fulfillment
process. The process owner need to have fair understanding of each area of the process and preferably had
worked in each of those areas at some point in his career. Process owners are not full-time positions and
mostly needed for taking decisions regarding the process, final signoff for TO BE process design, etc.
 ERP Project Team and Project Organisation Structure 91

Project Manager—Client
Project manager from company’s side will have the primary ownership of the project deliverables and will
provide day-to-day direction to the project teams. He will also be responsible for maintaining the project
plan, streamlining resolution of issues, and communicating the project status to the steering committee. In
general, the client project manager will provide overall project management for the implementation as well
as play an active role in the integration between the individual teams. He must proactively anticipate project
deviations and be responsible for taking immediate corrective action. He has the power/right to decide on
all project-relevant issues and the budget and can escalate the strategic issues to the steering and executive
committees for a quick decision.

Project Manager—Consulting
The primary role of the consulting project manager is to assist the client project manager to manage the
project by proper scope definition, development of the project plan and training schedule, and attendance
at steering committee meetings. The consulting project manager is a senior ERP consultant responsible for
ensuring that all the consultants provide superior advice and performance to the project.
The consulting project manager and the client project manager together
Manage project operations according to defined methodologies;
Control project scope and monitor project work plans;
Provide leadership and direction to all members of the project team;
Review project plans and deliverables;
Approve significant changes to project plans;
Control costs and expenses to agreed budget;
Analyse the project progress;
Locate and secure resources for the project;
Ensure good communication between teams within the project;
Ensure deliverables are completed on schedule and are presented to executive sponsor for sign-off;
Coordinate the review of the design and configuration of the ERP software to ensure compatibility
with the business requirements;
Ensure timely resolution of issues or appropriate escalation of issues;
Report project status to the executive sponsor on a regular basis;
Ensure contractual obligations are met with all project vendors;
Manage the improvement of business processes;
Ensure effectiveness of the project structure and roles.

Integration Manager
The primary role of the integration manager is to coordinate all functional, technical and change management
teams. He facilitates integration training, coordination of all quality checks for the project, attends the steer-
ing committee meetings and advises the project manager on all integration issues.

Data Manager
Data manager takes the responsibility of ensuring proper data in the ERP system. This means extracting
data from legacy systems, cleaning of data, creating data which is needed for the ERP, but not available in
legacy applications, and finally loading data. There are several ERP implementations which could not go
92 Enterprise Resource Planning

live as per the plan for non-availability of right data. This is a very critical position and generally manned
by a senior member of the company implementing ERP.

Training Manager
Large ERP implementations need lots of coordination in terms of ERP training activities. Activities can
range from identifying the training needs, preparing training content materials, identifying trainers, organis-
ing trainings, evaluating training effectiveness, etc. A large Indian public sector organisation had recently
gone live with ERP and around 20000 users needed to be trained. A training manager is responsible for
coordinating all such activities.

Industry Subject Matter Expertise (SME)

Increasingly companies are looking just not ERP package experience from the consulting team but also
expertise in industry processes and best practices (in the industry in which the company is, i.e. a company
in consumer goods industry will look for experts from the same industry). These industry subject matter
experts (SMEs) are valued, especially during the project business blueprinting stage for better TO BE design
of processes. The consulting company needs to have few of these guys who can bring tremendous value to
the client in terms of adopting what best companies in the industry are doing.

Change Management Consultant

These consultants drive all change management initiatives in the project in terms of continuous communi-
cation, designing new organisation structure, new roles, incentives for project team members, etc. Change
management consultant need to work closely with change team from client’s side and human resource
department.

Project Team Leads

The project team leads with assistance from a senior consultant are responsible for the day-to-day manage-
ment for each of the project teams. The responsibilities of the project team leads are to:
Directly manage the application project teams;
Manage project operations according to the project management methodology;
Control project scope and monitor project work plans;
Provide leadership and direction to project teams;
Assign tasks and coordinate resources;
Control costs and expenses to the agreed budget;
Identify critical resources;
Report project status to the project manager;
Manage project operations according to the defined methodology;
Ensure deliverables are developed and completed on schedule;
Ensure all testing is completed according to the testing methodology;
Ensure that all integration issues are handled and that adequate integration testing is completed;
Propose changes of planned activities and schedules to the project manager;
Review design and configuration of the ERP software to ensure compatibility with the business re-
quirements;
Assist in the improvement of business processes;
Ensure timely issue resolution or appropriate escalation of issues; and
Implement the ERP system as per the approved schedule.
 ERP Project Team and Project Organisation Structure 93

For large projects there can be several project team leads depending on the area of specialisation like
Functional lead for financial processes, human resource processes, logistics processes, etc.
Technical leads for consulting in areas like system support, ERP administration, database administra-
tion, operating system administration, network administration, desktop support and development.
Change management lead: Large projects may need a separate change management team for develop-
ing a comprehensive communications and training strategy, developing role-based training curriculum,
schedule and communicate the project end user training, and communicating information about the
project to the company, etc.

Team Members
Project team members work under team leads and helps in all regular project activities like business blue-
printing, system configuration, testing, data loading, etc. They can be either software consultants from the
consulting side and people with different process background from the core team side.

Extended Team Member

For large organisations having complex processes, there is high chance that one or two core team members
may not know all processes relevant for the function. For example in an automobile company having dif-
ferent departments (like plastic component making, assembly line, paint shop, gear box division, leather
components division, machined items, forged items, etc), one or two person(s) from production may not
know the processes for all departments. In this case though the core team will have one or two people as
full-time member, one person from each of these shops may become an extended core team member and
spend time in the implementation as and when required to give necessary business inputs, data validation
or solution testing.

Project Office
The Project Office will provide administrative support to the project team. This ensures that project team
members can remain focused on delivering project objectives and are not sidetracked on administrative
duties. The project office will be involved in everything from logistical support to document production, to
publication of meeting minutes, to tracking schedules, developing presentations, interview confirmations,
and conference/meeting room bookings.

CORE TEAM SELECTION

In every ERP implementation, there is a team from business organisation which participates throughout
the implementation. This team is known as core team which is supposed to bring with them knowledge of
existing processes, critical requirements, existing constraints etc.

Role of Core Team

The role of core team during project implementation is critical in view of the following:
Providing business inputs to design the right processes which need to be configured in the system.
They explain to consulting team current way of doing things, problems with the current way of doing
things and improving the same.
Configuring the system.
Validating data before loading into the new system (only core team members know which data is
correct and what is junk).
94 Enterprise Resource Planning

Ensuring that the solution will meet the need of their organisation in future through its testing.
Training the end users in the solution (using Train The Trainer concept).
As ERP is a hot skill, most of companies take bond from their employees to be part of the core team so
that they do not leave the organisation during or just after the ERP implementation. A bond of 18-24 months
is common. Several companies also design special incentive plans based on the success of implementation
as this team need to spend many sleepless nights in the office for success of the project, especially before
‘Go Live’. It’s also important to find new roles for the project team members after the project goes live.
Sometimes it is difficult for them to go back to their old roles perhaps due to filling of the posts they were
holding earlier or being settled in a new location for the project. These are change management issues which
need to be handled with care.

What Type of People You Need in Core Team

The obvious answer to the question “what type of people does a core team need?” is that ERP being a
complex project, the organisation needs to put their best people in core team and not the people whom they
can spare. For example, if the core team member selected for implementing financial management processes
does not know the integrity of current processes followed in the organisation and the pain points of current
processes and possible ways to improve the same, it is unlikely that the TO BE processes designed in the
system will be better than today and will be meeting company’s future needs. Lots of companies take help
of the consulting service provider to define a set of criteria for the core team. Below is such an example
of a set of criteria:

CORE TEAM SELECTION CRITERIA FOR COMPANY ABC

The core team member should have worked at least three years in the current company and at
least for last one year in his current role (it ensures that he has fair idea about company’s way
of working and the processes in his department)
He should have carried out different functions in the same area. (This may mean that the
materials management core team member had worked earlier in procurement, stores function,
import, etc so that he understands the processes in detail of different sub-functions)
Should be computer literate
Should be acceptable to people in his team

Small Companies Implementing ERP has a Bigger Challenge

However, sometimes finding such people is always a challenge, especially for small organisations, where
there is not enough people in middle management and senior management level. If there is only one man-
ager in the finance team who only has the global view of all financial processes in the company, then it is
difficult for the organisation to spare him for the ERP project because it will seriously affect the business.
So, finding the right profile will be a bigger challenge here.

CONSULTANT SELECTION
We discussed the process of selecting consulting company earlier. The process for selecting individual
consultant who will be boarded in the project team is a separate challenge as this team finally makes the
 ERP Project Team and Project Organisation Structure 95

difference. If the company selects the best consulting company for doing their ERP implementation, but
right consultants are not deputed in the project, the big name of the consulting company does not make
much difference.
As we discussed earlier, the ERP consulting team is made up of team leads/senior consultants, team
member/consultants, industry subject matter experts, change management consultants, etc. Every company
wants the best and most experienced people with right industry knowledge to be part of the consulting team.
Some companies even mention in their RFP (request for proposal) the kind of consulting profile they are
looking for, i.e. they need consultants with at least two full life cycle implementation experience, team leads
with at least three implementation experiences, etc. Some companies take interview of consultants before
they induct them in the project.
At times, it becomes a tough task for the consulting companies to get every people on board with right
product knowledge, process knowledge and industry experience. A few consulting service providers use the
concept of “shadowing,” i.e. while they bill the client for a fixed number of consultants as agreed to in the
project contract, they actually put few more freshers in the project who can help the team and at the same
time get a lifecycle implementation experience – which help them to become deployable quickly in other
projects. This is a win win for both the consulting company and the organisation. While the organisation
gets some extra hands during the project free of cost, the consulting company get some project experienced
consultants who can be quickly positioned in a senior role in next project.
Several consulting companies also came up with innovative models of “Centres of Excellence” (COEs).
These are a set of experts who work on multiple projects and support several project teams on technically
challenging issues. Any project consultant can always seek help from them, if required. For example, IBM
Global service, the world’s largest ERP consulting company, has several such COEs based on industry ex-
pertise (like retail COE, metal COE), technology expertise (like RFID COE) or particular service expertise
(like testing COE).

Summary
Having the right team in place is one of the key success factors for any ERP implementation.
ERP project team is made up of both teams from consulting side and a team from the company implementing
ERP.
There are different roles in the ERP project team like project sponsor, steering committee, process owner,
change manager, data manager, integration manager, industry SME, project manager, team member, etc. Each
of these team members have different roles in the project.
The company implementing the ERP need to have correct core team in place for the implementation. The core
team member needs to have right process knowledge. Sometimes, moving these kind of people from core
operations to ERP project team for a long-term is a challenge, especially for smaller companies. Sometimes,
consultants help in team selection.
Finally, the need for good consultants for successful ERP implementation is well known. While companies
are coming up with innovative models like “Centres of Excellence”, the right mix of process knowledge,
knowledge of the package and industry in a consultant will always be in demand.
96 Enterprise Resource Planning

Exercise
I. Objective Type Questions
1. Who is typically an ERP project sponsor?
2. Who is a process owner?
3. What does the steering committee do?
4. Who is an integration manager?
5. Who makes up the ERP project core team?
6. What is meant by SME?
7. What is the role of an extended team member?
8. What is a Centre of Excellence?
9. What does a data manager do?
10. What is “Shadowing”?

II. Descriptive Type Questions

1. Explain a typical ERP project organisation structure.
2. What are the roles and responsibilities of different ERP project team members?
3. What is the role of ERP core team? How is the core team selected?
4. What are the main activities of the project managers both from the client side and from the consulting
side?
5. How many types of leads are possible in ERP project? What are their roles?
6. How are individual consultants selected for an ERP project?

III. State whether the following Statements are True or False

1. Process owner should be someone from the IT department of the company.
2. The extended team member is a full time member of the project team.
3. Core team comes from the consulting side.
4. Integration manager looks after all integration aspects of the project: Functional, technical, change manage-
ment, etc.
5. Centres of Excellence always work in one project at a time.
 7
ERP Project Management
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
� ERP project scoping and it’s nine levers
� ERP Implementation Project Plan
� Resource Plan
� Project methods, standards, governances
� Project Charter
� Project Risk Management

INTRODUCTION
ERP implementation is a project of several months and like any other project, the success depends on how
effectively the project is managed within the committed timeline, budget and scope. Depending on the or-
ganisation size, an ERP project can involve several people, can run over 12 to 24 months and can cost a lot
for the organisation. For example, world’s leading food company Nestlé’s ERP project (known as GLOBE)
was implemented across more than 50 countries, involved more than 60,000 business users, ran around six
years and costing few hundred million Euros. As ERP projects can really be huge, managing a project of
this scale needs very effective project management skill. That’s more the reason for success or failure of an
ERP project, it is the project management office which either first gets the credit or is blamed.
What is the responsibility and activities of a project management office and that of an ERP project
manager? Often it is hard to answer this as the project manager is responsible and accountable for almost
everything in the project. For most of the activities, it is expected that he will get the job done by someone
in the project team and will not do it by himself. But he is finally responsible for it. Global project manage-
ment organisation PIMBOK identifies nine areas on which project management is based and these are:
1. Integration Management
2. Scope Management
3. Time Management
4. Cost Management
5. Quality Management
98 Enterprise Resource Planning

6. Human Resource Management

7. Communication Management
8. Risk Management
9. Procurement Management
Project management is directly responsible for few deliverables: There are few activities for which
project management office is directly responsible and these are critical project deliverables. Project scope
document, project plan, resource plan, project charter, project risk management strategy and project methods
and standards are few such areas where the project management team is directly responsible for the deliver-
able. In this chapter, these six items are covered in detail.
Project management need to monitor and track all activities in the project: There is a list of activities
which the project management team need to monitor on regular basis. The project management team’s moni-
toring activities include whether business blueprinting workshops are happening as per the plan, whether
blueprint documents are signed off by the customer, whether the individual ERP module lead has created the
gap document for his module, whether configurations are happening as per the schedule, whether module
consultants have created the configuration documents, whether developments are completed, whether testing
is carried out as per the project plan, whether users accepted the testing results, whether go live checklists
are prepared, etc. While individual module consultants and module leads are responsible for each of these
activities like business blueprinting, configuration, testing, developments, etc, the project manager need to
do the coordination and overall monitoring of the progress and the issues. He also needs to track the project
plan or work plan and update it on a regular basis and produce planned vs. actual reports.
Project manager is the single face to customer’s senior management: The project manager needs to be
present in all the steering committee meetings, executive committee meetings and integration meetings.
The objective of this executive committee meeting is to address the issues that involve decisions from the
top management. The project management should circulate well in advance the issues, so that committee
members can do their homework and come prepared for the discussions. It is the duty of the project man-
agement team to analyse alternative solutions, their advantages, disadvantages, consequences and circulate
them to the committee members well in advance of the meeting.
In this chapter, we discuss in detail the direct deliverables of project management in detail.

PROJECT SCOPING
Scoping the project correctly is one of the important criteria for successful ERP implementation. Numerous
projects got into problem as during implementation there is misunderstanding between what the consultants
believe they should do and what the organisations expect out of the consulting team. There can be serious
time overruns in the project, if scoping is done at too high level or a one-page word document (which is
actually the case in most of the projects).
Now first let us understand what is meant by scoping.
Scoping are all those activities which need to be done as a part of the project.

Nine Levers of ERP Project Scoping

A typical ERP application may need scoping in nine different dimensions as shown in Figure 7.1. These
are:
� Location Scope
� Business Scope
 ERP Project Management 99

Fig. 7.1 Nine Levers of ERP Project Scope

� Process Scope
� Application Scope
� Interface Scope
� Report Scope
� Data Migration Scope
� User Scope
� Technology Scope
It is important to define the scope in all these nine dimensions so that the scope document is all exhaus-
tive. Each of these dimensions is detailed below.

Location Scope
This includes the list of factories, warehouses, distribution centres where the ERP solution will be imple-
mented. More importantly, this part also needs to detail out what is not there in the current project’s scope,
i.e. factory XXX and warehouse YYY is not part of current implementation. Location scoping also talks
about the implementation location of the project, i.e. where the project team members and project manage-
ment office (PMO) will be located. Some companies takes a rollout approach for implementation, i.e. first,
the solution is implemented as pilot in one factory, one warehouse or one distribution centre and later on
it is rolled out to all others. In this case, preferably the location scoping exercise needs to articulate clearly
that which locations will be the part of primary implementation/pilot and where the solution will be rolled
out later.
A typical location scoping can be like this:
Implementation location: The company’s head office at Mumbai
Locations covered:
� Head office
100 Enterprise Resource Planning

� Plants at Ahmedabad and Pune

� Central warehouses at Mumbai, Bangalore, Delhi, Kolkata, Chennai and Hyderabad
� All distribution centres connected to these six warehouses.
Locations not covered:
� Contract manufacturers at Chennai and Kolkata will not be part of this implementation.
� Third party warehouses at Coimbatore and Bhopal are not part of this implementation.

Business Scope
This includes things like whether all the business of the company under scope for implementation or part
of it is included and part of it is not. For example, a company can decide that it will do the implementa-
tion only for their domestic business which contributes to 95% of the turnover and from which they expect
maximum benefits of the implementation to come from. The company may not include the export business
in their implementation right now as it is 5% of the turnover. Doing implementation in the distribution
centres located at US and Europe is a challenge as lots of developments are needed in the solution to meet
export regulations and particular forms requirement, but in return of all these, the company do not expect
much business benefit from this implementation.
In the same way, the company may decide to keep some business in the scope of implementation and
some business not part of it. Here is an example:

ITC, the largest tobacco and consumer goods company of India had done SAP implementation
for their tobacco, food, matches and agarbatti business. ITC’s hotel and hospitality business was,
however, not a part of the SAP implementation project. The company found lots of similarity in
the four businesses, the outputs of which follow the same ITC’s distribution channel to reach the
market and going for an SAP implementation for them together under the same project scope,
whereas the hotel business is a different business altogether being service-oriented and follow-
ing a total different channel for sales and marketing. Logically, the company decided to keep this
business out of scope.

Process Scope
This part details out the organisation processes which are part of the project implementation and the ones
which are not. This needs to be detailed out to the extent possible as this is one area which is revisited
several times during the project life cycle when new processes gets added or something in the list gets
deleted. It is difficult at the pre-implementation stage to come up with this list with greater details as at
this point the knowledge about the package is very limited for the organisation’s internal team and on the
other hand, for the consulting team the knowledge about organisation’s business processes is very limited.
However, it is expected that at the high level (at least at scenario and process level) the scope is known
that helps the organisation to clearly articulate what they want (to put it part of RFP, i.e. request proposal)
from the consulting company and for the consulting service provider, it is helpful to give a good quotation
knowing the details reasonably well. Additions/deletions expected at the activity level as the organisation’s
core team understands the application better and few more of its interesting features which they had not
thought earlier and in the similar way the consulting company understands its clients better. However, major
changes in scenario and process level should be prevented as that can change the project plan, timeline and
budget for the project.
 ERP Project Management 101

As the project blueprinting starts, it is expected that within first few weeks, the consulting service provider
and the core team together will come up with a detailed process scope document and which is signed by
both the consulting company and the organisation.

Table 7.1 Defining Process Scope for Different Business Divisions of the Company

Division Scope
Scenario - Process - Activity Scope Div. 1 Div. 2 Div. 3
Scenario (Level 1)
Process (Level 2)
Procurement Procurement of materials Activity (Level 3)
Purchase requisition X X X
Purchase order X X X
Goods receipt X X X
Invoice verification X X X
Source administration RFQ / Quotation X X
Outline purchase agreement X X
Inventory Management
Goods movement Inbound movement X X X
Outbound movement X X X
Goods issue X X X
Stock transfer X X X
Reservation X X
X: Indicates that this is a part of the scope

Application Scope
This is about the detailed application modules which should be implemented as a part of the project. There
can be different versions of defining the application scope depending on when this scope is defined.
For example, if this scope is defined at a stage when the particular package is still not selected, the exact
module names of the package is not known and only the broad application area can be part of the scope.
As most of the leading ERP applications provide solution in few known areas, at this point the application
scope definition can include things like:
� Finance and accounts
� Procurement
� Inventory management
� Sales order processing
� Quality management
If this is done at a stage when the package is selected, the application scope definition can be at a
much higher level of details and can detail out the exact functionality of the application which needs to be
102 Enterprise Resource Planning

implemented. Again, this is something which gets further refined during first few weeks of blueprinting to
get its final version. Below is such an example of a detailed scope.

Table 7.2 Detailed Application Scope – How a Company Defines it for their Project

Functional Area In Scope Out of Scope

Production Planning Demand management, material requirement and planning Product cost planning
Sales and distribution Sales planning, sales order processing, shipping and transporta- Sales returns
tion, stock transfer, sales and billing
Quality management in Inspection lot, result recording, usage decision
production
Plant maintenance Preventive maintenance planning
Finance General ledger accounting, accounts payable, accounts receiv- Investment management
able, bank reconciliation and asset management, cash manage-
ment, funds management
Costing Cost center and profit center accounting, profitability analysis Product costing
Asset management Asset accounting
Materials management Materials requirement planning, purchase requisition, RFQ/ Outline agreements
quotation, purchase order processing
Inventory management Inventory management, invoice verification
Warehouse management Warehouse transactions Batch management

Interface Scope
Any time when an ERP decision is taken, the company is running with a set of legacy applications. It is a
wrong assumption that an ERP will replace all of those. There are different reasons for this:
� There can be specialised system which is required for a particular business process and ERP does not
support it.
� There can be systems which company’s management do not want to change as they believe that the
functionality offered by them are better than most of the ERP solutions.
For these different reasons, an ERP system need to be interfaced with several applications, i.e. the data
need to flow between ERP and these applications for smooth running of the business. How many of such
interfaces need to be developed and tested should be estimated as part of project scope. Again something
that needs to be estimated at two stages. Preliminary estimation should be done before you make the RFQ
for consulting the service provider so that they can understand the effort involved and can make a reasonable
estimate. A detailed interface document is expected within 4-6 weeks of project’s blueprinting start date.
Example of few common interface areas:
� Interface with design systems: Some companies have strong design systems and ERP solutions need
to be integrated with these as ERP does not help much in designing the actual component or product
(Product life cycle management – PLM applications help a bit on this front now-a-days by manag-
ing product data, storing design, etc. Companies rarely use ERP for actual design)—an area typically
dominated by CAD/CAM vendors.
 ERP Project Management 103

� Interface with shop floor control systems: There can be specialised shop floor control (SFC) and
manufacturing execution systems (MES) that bring data from different PLCs, DCS systems in the
shop floor and help in manufacturing execution – again a typical gap area for ERP solutions.
� Interface with Point of Sale (POS) systems: A typical requirement for retail industry. Though lead-
ing ERPs like SAP and Oracle had come up with their own applications in this area, there are lot of
specialised nitch vendors and ERP systems are expected to integrate with the solutions if the company
does not want to replace existing POS application (Replacing POS application is a bigger decision for
the retailer because the POS may be running across thousands of stores of the retailer whereas ERP
is running only at head offices and distribution centres).
� Interfacing with weigh bridge application: When a truck enters into factory, empty weights are taken,
at weigh bridge and weight are also taken while leaving. The difference between this is supposed to
be the materials entering the factory and need to be transmitted directly to ERP solution. This is a
common interface area for ERP application.
� Interfacing with laboratory management information systems: These systems collect hundreds
of data points for each sample on different parameters. Some of these need to flow to ERP. Again a
common integration area.
� Interfacing with specialised industry applications: There are certain industries where there are
specialised applications which are widely popular. For example, for airline industry, ticketing and
reservation systems need to be globally integrated and there are players like Galileo who build pack-
age applications for this area. Any airlines will not like to change over to an ERP application for
this—rather ERP need to build interface with these applications.
Figure 7.2 shows the case for ERP implementation for a retail company where the retail ERP solution had
to interface with several other retail specific specialised applications for smooth data flow and functioning
of business.

Reports Scope
This is one of the high expectation areas from any ERP systems. ERPs are supposed to generate online re-
ports on different business processes and in a format which the user defines at the click of a button. Though
most of the leading ERPs provide lot of reports as part of their application, in most cases that is not enough.
Any implementation typically involves developments of reports. Now a days most of the ERP solutions
had come with business intelligence and data warehousing applications (For example, SAP has SAP BW
and SAP BI solution for this) to meet this need. However, at scoping stage, it is important to get this list
of reports—understand their complexity at high level—how much will come from standard package and
how many of them need to be developed. This is important to make a good estimation for the consulting
company and to make a realistic project plan. Below is an example of list of reports (a small part of the list
is shown) asked by a company while doing implementation for their logistics processes.
� Purchase Order Summary
� Purchase Order Detail (Consignee-wise)
� Product-wise plan for the month
� Destination-wise plan for the month
� Major customer-wise plan for the month
� Region-wise order and despatch
� Planning vs. despatches
� Pending orders
� Region-wise order balance
104 Enterprise Resource Planning

Fig. 7.2 A Food Retailer’s ERP—ERP Integrates with Several Specialised Systems

Data Migration Scope

In ERP system before it goes live, lots of data elements need to be migrated from the existing legacy ap-
plication to ERP. As typically these datasets are of large volume, the migration needs a lot of effort. In
some cases these data need to be cleaned, i.e. obsolete products, customers, vendors need to be identified
 ERP Project Management 105

and they should not be migrated or if there are erroneous address or accounts code for customers, this need
to be corrected before sending it to the new ERP system. Scope should clearly define which data elements
need to be migrated and who will do what. For example, who will do data cleaning (the organisation or the
consulting company)?

Table 7.3 Data Migration Scope for an Actual ERP Project

Master data to be migrated

� Material master data
� Customer master data
� Vendor master data
� Asset master data
� Chart of accounts
� Cost centers/Profit centres/Cost elements
� Pricing condition master data
� Production planning master data – Bill of material, routing, work centres, etc
� Plant maintenance masters
� Quality management masters
� Warehouse master data

Transaction data objects – Open items to be migrated

� General ledger (GL) balances and open items
� Customer open items
� Vendor open items
� Budget values
� Loans and advances
� Open internal orders
� Stock balances – Finished, semi-finished, WIP, production raw materials,

consumables, spares
� Material in transit–High seas, on port
� Open service contracts and orders
� Open contracts and purchase orders
� Open sales contracts and orders

User Scope
It is also important to estimate the expected number of users for the application. This estimation in some
cases need to be done at project budgeting stage itself as the cost of application licence depends on this. If
the company already has an existing legacy application, the number of users in future for ERP application
can be derived from application-wise number of users for current application. If there is no existing legacy
application exists, the estimation can be based on number of supervisory and management staffs in different
departments who are expected to use the system. A typical example of such can be as follows:
� Finance: 20
� IT: 7
� Manufacturing: 20
� Marketing: 3
� Customer order: 20
106 Enterprise Resource Planning

�Planning: 5
�Purchase: 5
� Sales: 10
� Shipping: 8
� Warehouse: 18
User scope estimation helps the consulting service provider to estimate how much effort is needed to
build authorisations in the future ERP system.

Technology Scope
This includes other technology related activities that need to be performed during the project, again some-
thing on which the consulting service provider need to have clarity so that he knows how many resources
he needs to plan for this. This is also important for the organisation as they know how much extra load will
come during implementation on their IT team to carry out technology related activities during the project
on top of their current job. These can be things like:
� Installation of ERP software components in all landscapes (i.e. training, development, quality assur-
ance and production)
� System administration, including backup and recovery standards
� Setting up of technical transport management
� Sizing the landscape documents for all servers including client strategy
� Server deployment strategy for the ERP for production environment
� System performance monitoring during project lifecycle

Scope Exclusions
Scope exclusion defines the items that will not be done as a part of the project. This will document things
like which locations and business processes are not part of the current implementation. This may include
things like interfaces which will not be built and the rational for that or reports available in current system
which will not be part of the future ERP. An organisation that is giving the ERP implementation contract
to an outside company may decide to do a lot of activities of their own and taking out from the scope of
work of consultants. Table 7.4 shows a list of activities for an actual ERP project which the implementing
organisation had taken away from the scope of the consulting service provider and decided to be done by
the corporate IT group.

Table 7.4 List of Items Excluded from Consulting Company’s Scope

� Evaluation, procurement and/or installation of hardware, software, network products/vendors, any add-on
components to the ERP system
� Infrastructure planning and development
� Data archiving
� Installation of operating system (OS)
� Create a disaster recovery (DR) site
� Training on subjects other than that relevant for ERP implementation
� Manage telecommunications facilities and network
� Manage the legacy applications in the interim
(Cotnd)
 ERP Project Management 107

(Cotnd)
� Any mobile applications or integration with mobile networks
� Network design (WAN, LAN) and related infrastructure for connectivity
� Licences for any interface software, project management and documentation software (E.g. Visio, MS Project,
MS Office Suite, etc), mail systems (Lotus/Outlook), etc
� Costs related to hardware and infrastructure, systems operations
� Data migration of historical data would be only to the extent of open items/balances at the time of go live.

It is always good to have the exclusion list clearly known to project team members, i.e. both by consul-
tants and the core team members so that down the line there is no confusion.

ERP IMPLEMENTATION PROJECT PLAN

Developing a project plan is one of the important deliverables for the project management team. While the
project manager can take inputs from several stakeholders for developing this plan, it is his responsibil-
ity to deliver a plan which is feasible and in line with the project budget, and which documents when and
what project activity need to be done by whom. Project plan also depends on the implementation strategy
of the company. For example, if the company wants to go for a Big Bang strategy, the plan will look very
different from the plan, if they want to adopt a Rollout strategy. As the plan provides a guide to the project
and is used to monitor its progress, it is important to communicate the plan to all project stakeholders who
need to know about the project.
Granularity of a project plan depends at which point it is created and for which audience. For example,
at project preparation stage, it is OK to develop a plan at high level and then gradually detailing it as the
project progresses. Few weeks down blueprinting, when there is a fear idea about the project scope and
company’s business processes, this plan need to be detailed at most granular level breaking it into different
work streams. In the same way, for top management, it is OK to have a project plan at high level who would
use it for monitoring the project. However, for a project manager who needs to work daily with the plan
needs, a much detailed plan with activity break up in weeks or days, showing activity start and end dates,
amount of work, estimation of percentage completion, lateness, costs, etc. The detailed plan also shows
the tasks that is dependent upon the completion of others (interdependencies) and the tasks that can run in
parallel.
A project plan is typically prepared in a spreadsheet (like Excel) or with the help of specialised project
management software like MS Project. While Excel is readily available, MS Project type of specialised
project management software provides lots of added functionality like capturing many details about the
project, showing activities which are on critical path and facilitating reporting of various parameters like
costs, resource usage, overdue activities, etc.
An ERP project plan is composed of several plans like:
� Activity, deliverables and milestone plan: This plan details at what stage of the project which activi-
ties to be done and which deliverables need to be submitted to client by what date.
� Resource plan: This is given in detail later. A resource plan details at which stage of the project, how
many people of which skill set are needed and for what duration.
� Training plan: This details out the people to be trained, venue and schedule of trainings, training
contents, etc. Planning for training core team, power users and end users is part of this plan.
� Testing plan: This details out plans for different testing activities during the project, i.e. unit testing
(where particular functionality or development is tested), integration testing (where the complete
scenarios are tested), volume testing (where the company’s business processes are tested with real
108 Enterprise Resource Planning

life full volume data), end user testing (when final users of the application test the functionality or
scenario that they will run in their normal day to day life). In which environment testing will be done,
who will create test data, who will do the testing, etc. are also part of it.
� Data migration plan: This plan details how data will be migrated from old system to new system,
who will do the migration, during what period the data migration will happen etc.
� Change management plan: This details how changes will be communicated in the organisation, the
plan for communicating what is happening in the project front to the whole organisation, the frequency
of such communication, etc.
Figure 7.3 shows a high level project plan indicating different phases of the project (like project prepara-
tion, blueprinting, realisation, go live preparation), critical activities for each phase, major milestones and
timeline for each major phase. This being a high level plan, the time bucket is in months.

RESOURCE PLAN
Resource planning is done after the project planning. Project plan gives an idea about phase-wise activities,
based on which the resource planning is carried out. Project team includes members from both the consult-
ing team and the core team. A typical resource plan is given below:
Project Phases Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar
Project Preparation
Business Blue Print-
ing
Realisation
Final Preparation &
Go Live
Post Go-live
support
Position Org Location
Programme Client Onsite 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5
Manager
Programme Consulting Onsite 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5
Manager Company
Project Manager Client Onsite 1 1 1 1 1 1 1 1 1 1 1 1
Project Manager Consulting Onsite 1 1 1 1 1 1 1 1 1 1 1 1
Company
Integration Consulting Onsite 0 0 1 1 1 1 1 1 1 0 0 0
Manager Company
Data Manager Client Onsite 0 0 0 0 0 1 1 1 1 1 1 0.5
Offshore Project Consulting Offshore 0.5 0.5 0.5 1 1 1 1 1 1 0.5 0.5 0.5
Manager Company
Logistics Lead Consulting Onsite 1 1 1 1 1 1 1 1 1 1 1 1
Company
Consultant - Consulting Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Materials Company

(Contd)
 ERP Project Management 109

(Contd)
Core Team - Client Onsite 3 3 3 3 3 3 3 3 3 3 3 3
Materials
Consultant - Consulting Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Production Company
Core Team - Client Onsite 3 3 3 3 3 3 3 3 3 3 3 3
Production
Consultant - Sales & Consulting Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Distribution Company
Core Team - Sales & Client Onsite 3 3 3 3 3 3 3 3 3 3 3 3
Distribution
Consultant - Quality Consulting Onsite 1 1 1 1 1 1 1 1 1 1 1 1
Management Company
Core Team - Quality Client Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Management
Consultant - Consulting Onsite 1 1 1 1 1 1 1 1 1 1 1 1
Maintenance Company
Core Team - Client Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Maintenance
Finance Lead Consulting Onsite 1 1 1 1 1 1 1 1 1 1 1 1
Company
Consultant - Consulting Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Finance Company
Core Team - Client Onsite 3 3 3 3 3 3 3 3 3 3 3 3
Finance
Consultant - Consulting Onsite 1 1 1 1 1 1 1 1 1 1 1 1
Costing Company
Core Team - Client Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Costing
Technical Lead Consulting Onsite 1 1 1 1 1 1 1 1 1 1 1 1
Company
Consultant - Consulting Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Technical Company
Core Team - Client Onsite 2 2 2 2 2 2 2 2 2 2 2 2
Technical
Programme Consulting Offshore 4 4 4 4 4 4 4 2 2
Developer Company
Report Developer Consulting Offshore 2 2 2 2 2 2 2 1 1
Company

The above resource plan states how many resources are needed in which month, whether resources need
to be at client site or at offshore location, how many resources needed from the consulting company side
and how many from the client side. There are programme managers and project managers from both sides.
Integration manager is needed mainly for the integration testing period and will be part of the team from final
blueprinting stage to the end of realisation phase. In the same manner the data manager will be part of the
Fig. 7.3 High Level Project Timeline and Milestones
110
Enterprise Resource Planning
 ERP Project Management 111

core team mainly during data migration and need not be a full-time member of the project. In this project, it
is decided to do all the developments related to specific functionality and report related developments from
offshore, i.e. from a low cost country. Developments start from later part of business blueprinting phase,
once the requirements are known. These need to be completed much before the project goes live. There are
leads from the consulting side for all key areas like logistics, finance, technical, etc who guide a team of
consultants and core team members for each respective package module.
The resource plan also shows how there can be different roles during different phases of project (Integra-
tion managers or data manager come during a particular phase of the project and leave when their activity
is completed) and the project resourcing do not remain uniform throughout the project period, i.e. there will
be ramp up and ramp down of resources during the entire project life cycle.
In a typical ERP project, a lot of time of the project manager goes in managing project resources. This
include things like resource planning, getting those consultants, if consultants are not available internally
within the consulting organisation then hiring them, on boarding activities for every consultant, perfor-
mance monitoring of consultants, etc. There will be always issues like for a nitch ERP module skills are
not available, performance of particular consultant in the project is not up to the mark, the consultant is not
experienced enough or a core team member is very junior one and not in a position to give right business
inputs, etc. While the resource management issues are maximum in the beginning of the project (as lots of
new resources to be located and boarded in the project team together), this generally comes down as the
project progresses.

PROJECT PROCEDURES AND STANDARDS FOR GOVERNANCE

This is another deliverable from the project management side and the purpose of this activity is to establish
the basic standards and procedures for the project. The idea is that everyone in the project follows the same
standards and processes so that consolidating information becomes easy and everyone does every task at the
same level of details and it is not left to individual consultant’s imagination. The standards and processes
relates to
� Change request management standards: How will change management be handled? During the
project life cycle, scope change is common. Impact of such a scope change needs to be understood
and an apex change management governance body need to approve such changes only in case it is
absolutely necessary. The process of how change request need to be created, how it will be forwarded
to change management governance body, what guidelines the change management governance team
will follow to approve the change and how these changes will be implemented finally needs to be
defined at the project preparation phase.
� Issue management standards: The process for how issues will be handled in the project; whether
any tool will be used for logging issues in issue database; once the issue is resolved, how the same
is updated in issue database how the issues will be escalated and reported during different review
meetings, etc. need to be defined.
� Project communication management standards: Project preparation stage also needs to define how
overall project communications will be made. This can include things like at what frequency all project
stakeholders will be communicated (different options can be: weekly, monthly, quarterly, etc), what
will be the medium of communication (again there can be different modes of communication like
E-Mail, Electronic Newsletter, Physical newsletter, etc), what items to be communicated (common
items can be: project status, important milestones achieved, activities in the next phase, etc), who will
do the communicatison, etc. This needs detailed planning.
112 Enterprise Resource Planning

� Project monitoring and status reporting standards: This needs scheduling different meetings like
steering committee meeting schedules, meeting schedules for the core team and extended core teams,
etc needs to be planned. While steering committee meetings typically happens once in a month or at
times adhoc meetings depending on urgency of some issues, core team meetings can happen on weekly
basis. Agenda for such meetings and review items need to be planned. Minutes of such meetings need
to be prepared and circulated to all key stakeholders.
� Testing standards: During project preparation stage, testing strategy needs to be worked out. This
include things like how many rounds of testing need to be done, in which environment test will hap-
pen, who will create test data, how much test data need to be created, what happens if a test fails, the
procedure for re-testing, who does the testing, etc. There are different types of testing – Unit testing
to test the developments, integration testing to test complete scenarios, volume and regression testing
to see system’s performance with full volume real life data load, etc. It is important to decide at this
stage that which of these tests are necessary and how many rounds of each test is required.
� System configuration standards: This includes standards on system configurations. Several companies
these days choose to start the implementation with a pre-configured template for their industry (either
provided by the package vendor or their consulting partner) and do only those configuration changes
which are absolutely necessary. Configuration standards also include the templates for configuration
documents.
� Development strategy and standards: This include templates for writing functional and technical
specifications for developments, the process of how development will be handled, the process of
handling development change requests, the process of testing the developments and ensuring that
developments really meet business user’s requirements etc.
� Authorisation standards: This defines the standards for the authorisation strategy that the project
will adopt. There can be different options here like providing authorisation based on user’s role in the
system or providing authorisation transaction by transaction. In the first case any user from procure-
ment department using the system can have the access to set authorisations like creating purchase
order, changing purchase order, vendor evaluation/rating, checking a system report on pending order
status, etc. Authorisation standards also define what kind of testing need to be done to check that the
authorisations are correct and how authorisations are added and removed in the package as new people
join the organisation or existing employees leave.
� Project documentation standards: During project preparation stage, generally formats are prepared
for all major project deliverables. Consulting team and core team have to agree on common formats
for different project management documents and project deliverables. Common project management
document formats can be:
� Project status report
� Module status report
� Minutes of meetings
� Project issue log
� Project risk register
� Project charter
Common project deliverables can include things like:
� Formats for business process workshop output
� Formats for business blueprint document
� Formats for test scripts
� Formats for development specifications (i.e. functional and technical specifications)
 ERP Project Management 113

It is also important to decide where the documents will be stored, how different versions of the same
document will be maintained, whether any naming convention to be followed for the documents, how the
document hierarchy will be maintained, etc.
Establishing project procedures and standards is an important step to establish the right governance model
for the project. These standards need to be referred throughout the implementation. This need to be done
early enough in the project preparation stage itself and need to be communicated to all team members so
that in the midway of the project the company should not discover that three consultants looking after sales
process, production process and procurement process, write development specifications in three different
ways and the development team is totally confused and do not know which one to follow.

PROJECT CHARTER
Project charter is one of the project management deliverables of the ERP project preparation stage. This
contains a short brief about the project with details like:
� Project overview: This details current situation (‘As Is’ situation) and ‘To Be’ situation after the
project, i.e. what is expected from the project and what the project will deliver.
� Project scope: This is discussed in detail earlier in this chapter. Scope is a deliverable with project
charter. This describes in detail what work will be undertaken during the project.
� Project goals and objectives: Describe the overall goal that the project is expected to achieve and
this should be aligned to corporate and organisational strategies.
� Project deliverables: These are high-level deliverables to meet project objectives. It is important to
finalise the deliverables early enough because in some cases payments to implementation service pro-
viders can also be linked to deliverables. Generally a set of deliverables are planned after each phase
of the project and successful execution of deliverables ensures completion of that particular phase.
� Business case summary: Executive summary of project’s business case.
� Total estimated project cost: Rough cut project cost from start to finish. Again this is something
discussed in detail in project pre-implementation chapter.
� Implementation strategy: This is about high level implementation strategy for the project, i.e.
whether this will be a big bang implementation or a phased rollout approach. This is discussed in detail
earlier.
� Project stakeholders: This section lists out the names of the people and organisations having interest
in the project. It is obvious that there will be people inside the organisation who will have interest in
the project and there can be external organisations like customers and suppliers who may have interest
in the project.
� Assumptions and constraints: Assumptions are items that are believed to be true and constraints are
items that are beyond the control of the project team and that limit options. The example below shows
a list of such assumptions and constraints for a particular project.
� Risk assessment: Risks are the factors that may have a negative impact on the project and managing
risk on an ERP project is crucial to its success.
Example: Sample table of content from a project charter
1 Introduction 1.4 Project Assumptions and Constraints
1.1 Statement of Work 2 Scope
1.2 Project Objectives 2.1 Functional Scope
1.3 Benefits 2.2 Technical Scope
114 Enterprise Resource Planning

2.2.1 Software 4.1.6 Project Planning and Monitoring (Review

2.2.2 Hardware Meetings)
3 Project Organisation and Roles 4.1.7 Quality Assurance
3.1 Executive Sponsor 4.2 Implementation
3.2 Executive Committee 4.2.1 Project Plan
3.3 Steering Committee 4.2.2 Training Plan
3.4 Project Manager 4.2.3 Knowledge Transfer
3.5 Project Integration Manager 4.2.4 Change Management
3.6 Project Office
3.7 Project Team Leads 5 Project Management Standards and
3.7.1 Functional Team Leads Procedures
3.7.2 Technology Project Team 5.1 Project Monitoring
3.7.3 Change Management Team 5.2 System Configuration
4 Project Plan 5.3 Communication Plan
4.1 Methodology Overview 5.4 System Landscape
4.1.1 Proposed Implementation Strategy 5.5 System Authorisation Standards
4.1.2 Scope Management 5.6 System Problems and Error Handling
4.1.3 Issue Management 5.7 System Enhancement and Modifications
4.1.4 Complexity Management Approval
4.1.5 Risk Management

Project Vision and Mission Statement

As we have discussed earlier, ERP projects can be of huge scale affecting almost every one in the organisa-
tion. It’s common to start such a project with a vision and mission statement. The company’s senior man-
agement needs to articulate such a vision. Most projects start with a vision statement at very high level like
“The project is intended to improve company’s capability of customer service and operational efficiency”.
Sometimes, it can be very specific as well like a simple one line vision taken by FedEx while starting a
redesign project for their order fulfillment process with the help of information technology/ERP and that is:
“We will deliver the package by 10:30 the next morning”. FedEx will do whatever it takes to achieve this
vision. It’s important that the vision gets translated to measurable objectives and metrics.

Project Kickoff—A Formal Meeting to Present Project Charter

Typically project charters are presented in the project kickoff meeting. This meeting is a formal announce-
ment of the start of the project to the whole organisation and other concerned organisations. The goal of
project kickoff is to:
� Introduce project team members (Project manager, consultants, etc) to the organisation and explain
their roles, responsibilities in the project.
� Explain high level project plan, implementation strategy, timeline, project goals and objectives, and
different deliverables at different stages of the project
� Outline key organisational change management goals and objectives
� Create excitement about the project among the project team and the entire organisation. Generally
kickoff meetings are attended by senior leadership team of the organisation and this activity shows
their commitment to the organisation.
 ERP Project Management 115

It is important that the excitement created during project kickoff need to be maintained throughout the
project lifecycle and kickoff meeting is followed by regular communication to the rest of the organisation
about the progress, achievements, etc.

PROJECT RISK MANAGEMENT

Risks are the factors that may have a negative impact on the project and managing risk on an ERP project
is crucial to its success.

ERP Project Risk—Reasons

There can be several risks in an ERP project as shown in Figure 7.4 in terms of
� Untested technology, i.e. the project is going to implement the latest version of ERP software which
is not implemented in many sites
� Core team is manned with non-experienced staff
� Aggressive time-frame of implementation
� Too large scope for the project, i.e. the company is trying to do too many things in too short time
� Frequent change in scope
� Very low computer literacy of employees
� A group within the company is very much against this project
� The company has remote locations where the software need to be implemented and where connectivity
is a major issue
� The company has very few senior members in the organisation and will not be able to devote full time
members in the project team
� Lack of top management support
� No prototyping is planned in the project plan (due to aggressive time-frame)

Fig. 7.4 Reasons for ERP Project Risk

116 Enterprise Resource Planning

Risk Management is a Five-step Process

It is important to understand these risk elements, assess their impact and develop a risk management strategy
and risk mitigation plan. This risk management approach can be a five-step process as shown in Figure 7.5
and are as follows:
1. Finding potential risk elements of the project
2. Analysing the impact of each of these elements, i.e. which elements are most risky and which ones
are not so risky, determining severity of the potential failure on the budget, project timeline, or the
users’ requirements
3. Assessing the probability of occurrence of these risk elements, i.e. which ones have high probability
4. Based on inputs on top three steps, prioritising the risks, deciding which risks should be eliminated
completely because of potential for heavy impact on critical business processes
5. Developing a risk mitigation plan for top risk elements. Risks can be mitigated either by removing them
fully or by reducing the probability or their impact. There is also an identified person for mitigating
every risk and a set of known actions to resolve it. A monitoring plan need to be developed for risks
that need regular management attention.

Fig. 7.5 Five Step Project Risk Management Approach

To execute this five-step process, it is important to define a risk management process, develop a risk
assessment tool that can identify potential risk elements, conduct risk workshops and meetings with key
project stakeholders and document and analyse the implementation risks. One of the easiest and most ef-
fective ways to find potential risk elements is to talk to other organisations that have done similar projects,
i.e. implemented similar ERP package of approximately same size and in the same industry as yours. There
can be risks which may be more important for a particular stakeholder of the project. For example, a fixed
cost implementation project may be more risky for consulting service provider as he is not getting paid in
case there is any cost overrun.

Risk Assessment Tool

This can be in the form of a set of tailored of risk assessment questions, addressing key issues that impact
the ERP system implementation. There need to be an effective mechanism for administering such a tool (i.e.
on-line, paper and pencil survey, interactive technology).
 ERP Project Management 117

Risk Workshops
The purpose of the risk workshop is to understand the root causes of the implementation risks; put them in
context with the project; and drive towards corrective action. Workshop participants are asked questions for
each of the implementation risks. The questions can be as follows:
� What is behind the concern?
� What does it mean for the project?
� What can we do about it?
The result of the workshop is a set of specific actions and assigned tasks that address the implementation
risks.

Periodic Risk Assessment

It is important to remember that risk management is not a one-time activity and there need to be periodic
risk assessment process as new risks can creep in any time during the project life cycle. For example,
hardware ordered has not been received on time, project scope changed suddenly or some critical resources
leave the project just before integration testing, etc. Project team risk assessments can be conducted every
three months over the course of the ERP implementation. The project team risk assessment sessions include
project updates, administration of the assessment question set, and open-ended discussion about the ERP
implementation. Follow-up risk workshops to develop risk mitigation strategies and action plans are sched-
uled as needed. The implementation risks associated with the project team as uncovered by the assessments
and associated workshops are documented. At regular intervals, these results need to be analysed to track
the changes in risks over time. Documentation over time also allows the team to assess the effectiveness of
the actions previously taken and plan new actions in response to changing risks.

Summary
� Nine levers scoping approach for ERP covers: Location scope, Business scope, Process scope, Interface
Scope, Application scope, Reports scope, User scope, Data migration scope and Technology scope. Getting
clarity on these nine scoping levers may not be possible at the beginning of the project as it need in-depth
understanding of company’s current business processes, applications, etc. However, it is important to get
clarity on this and document it within few weeks of project beginning.
� While documenting what is included in the scope, it is also necessary to document what is not included.
These are the typical areas of dispute in a project between the company and their consulting partner. So,
this need to be clearly articulated as early as possible so that both side has right expectations on the project
deliverables.
� Project plan lists the project activities on a time scale with assigned resources for each activity. The plan
detailing depends on the level at which it is presented, i.e. may be at a very high level for senior manage-
ment, but may be very detailed for project managers who need to work out the plan on daily basis.
� Resource plan shows during which period of the project how many resources are required and with which
skill. People from consulting and core team can be separately shown here. Project manager typically spends
much time in the project in managing resources.
� Project methods and standards is a list of processes and standards that need to be followed for change requests,
issue management, development, testing, status reporting, etc. These need to be circulated in the beginning
of the project so that everyone follows the same standards.
118 Enterprise Resource Planning

� Project charter is a brief description document about the project, detailing its purpose, vision, business case,
plan, standards, assumptions, etc. It is important that both the consulting company and the company imple-
menting ERP sign this so that both have same expectation about the project. This should be presented in
project kick off meeting.
� There are different reasons for ERP project risk. Project risk management is a five-step process involving
risk identification, risk analysis, risk assessment, risk prioritisation and finally risk mitigation plan.

Exercise
I. Objective Type Questions
1. What are the nine areas of PIMBOK project management?
2. What are the nine levers of project scoping?
3. What are the typical deliverables for which a project manager is responsible?
4. What are the kinds of activities a project manager needs to monitor?
5. What is meant by location scope?
6. What is meant by project governance?
7. What is a project charter?
8. What is data migration?
9. What is meant by scope exclusion?
10. What are the components of an ERP project plan?
11. Why risk assessment is needed periodically?
12. Give some examples of risk assessment tool.
13. What is PMO?
14. Why is a disaster recovery plan important for an ERP project?

II. Descriptive Type Questions

1. Explain the nine levers of project scope.
2. Explain what is meant by process scope and application scope.
3. What is interface scope? Explain some common examples of application interface.
4. What is master and transaction data objects for data migration in an ERP project?
5. Give some examples of technology scope and scope exclusion.
6. Explain different components of ERP project plan.
7. What are the components of an ERP project-resource plan?
8. What are the standards and processes for an ERP project?
9. Explain the parts of a project charter.
10. What are the typical risks of an ERP project? Explain the five steps of risk management process?

III. State Whether the following Statements are True or False

1. Risk assessment is a one time activity in an ERP project.
2. Activity is a level of detail below process.
3. Process is a level of detail above scenario.
4. Project charter is presented in project kick off meeting.
5. Risk management is a three-step process.
 ERP Project Management 119

IV. Assignments
� Study the ERP project plan for a company which had gone for ERP implementation in recent times. What
are the activities it contain? How a resource plan changes in different phases of the project?
� Study ERP project scope for a company. What does it contain?
 8
Managing Requirements
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Concept of Requirement
Types of requirements
Requirement gathering process: Business Process Workshops; and Business Analysis
Question Sets

The basic driver of an ERP implementation is always a set of business requirements that ERP is expected
to achieve. If the expectation from ERP and these business requirements are not known at the beginning of
the project then it becomes difficult to assess at the end of the project that whether the implementation is
really successful and it has delivered the expected value. How to get these requirements and the process of
addressing it are discussed in this chapter.

CONCEPT OF REQUIREMENT
Requirement is a set of needs for the business or for users that trigger the need for a system (in this case
an ERP system).
Requirement definition is the process of understanding these requirements and documenting it in “Re-
quirement definition document”.
It is important to note the following points regarding requirement:
Granularity of requirement: With what granularity the requirements will be defined depends on the
organisation. While some organisations define requirements at much higher level, few others like to
define it at the granular level. Granularity can also change depending on at what organisational level
the requirement is defined. For example, a CEO’s vision from ERP system can be better customer
satisfaction and an efficient supply chain. This high-level vision can lead to several business require-
ments at the next level like efficient supply chain means running the supply chain with lower inventory,
better fill rate, reduction of order fulfilment cycle time and overall lower supply chain cost. These
business requirements can lead to number of expectations from ERP system.
 Managing Requirements 121

Requirements mean different things to different people: As described earlier, the requirements are
different for different people. While at a senior management level a requirement can be a new process
to reduce inventory, at an operator’s level the requirement can be a little change in his way of working
(instead of his decision on selecting manually the machine to produce, his requirement is that software
should guide him in selecting the machine) whereas for the software developer the requirement can
be ‘To design a new user interface’.
It is important to state requirements clearly: This is one of the typical problem areas of ERP
project where requirements are defined vaguely. For example “ERP system needs to bring end to end
supply chain efficiency” or “We want a very user-friendly system”. What these requirements exactly
mean is left to subjective interpretation. These kinds of requirements are difficult to meet. It is a good
practice to define the requirement quantitatively, i.e. “We expect 95% uptime for the system” or “Any
background jobs should complete within 3 hours”. It is easy to design the system against these defined
parameters instead of something like “Very high uptime” as very high may mean different things to
different people.
Requirement should be verifiable: There should be few clearly defined parameters against which a
requirement can be tested when it is met. These test criteria need to be defined.
Prioritisation of requirements is important: Requirements can be grouped as vital, essential and
desirable to rank their priority. It is important to take care of all the vital and essential requirements
definitely before the system goes live while few of the desirable ones can be postponed, if required.

TYPES OF REQUIREMENTS
There can be different types of requirements as follows:
Business requirements: These are high-level objectives of the company going for ERP and documented
in project’s vision or scope document. These can be things like the project is aimed to “Design an
effective supply chain” or “Improve customer service”.
Functional requirements: These are the features or capabilities needed/expected in the software to
meet business requirements described above. The example of this can be ‘The software should have
optimisation capability’ to decide most optimum product mix that the company should produce or
“The software should have simulation capability” to analyse different what-if scenarios. Most of the
requirements in a project fall into this category. A particular process is expected to run in a particular
way and the software needs to meet the expectations from the process.
Legal requirements: These requirements are imposed by different government bodies, excise laws,
tax laws, modvat rules, etc. The software need to provide reports and information in defined formats
for such requirements.
User requirements: These can be requirements from end user. Example of this can be a user expects:
‘A simple purchase order entry screen where most of the values are defaulted’, and he need to enter
minimum information to create a new purchase order. This can also be to get information in the form
of a report in a particular format.
Maintainability requirements: The system should be such that it is easy to maintain. ERP systems
are business critical and few of its transactions (like invoicing, sales, inventory transactions, etc) need
to run on 24 × 7 basis – maximum uptime of the system is critical.

Who all Can Give Business Requirements?

Business requirements can be given by different people. While main inputs are given by company’s manage-
ment and end users, there are number of people outside the organisation who also can give business require-
122 Enterprise Resource Planning

ments. For example, customers can give requirement like they want to check the status of their order, legal
department may want particular reports to be presented in particular formats, regulatory agencies (Excise
or Tax department) want excise and tax to be calculated and filed in a prescribed way, etc. Requirements
can also come from technical support team, hardware team, etc.

REQUIREMENT GATHERING PROCESS

Requirement gathering is an important step of business blueprinting phase. The main purpose of this activ-
ity is to:
Have an understanding of company’s current business processes. This needs understanding of company’s
industry, key drivers of the business, company’s business processes, its current systems (manual or
computerised), discussions with users and study documents available. Both ERP product vendors and
consulting companies come up with lots of accelerators (like questionnaire, template, etc) which helps
in quick understanding.
Understanding of current pain points: The task of understanding company’s current business processes
should be undertaken with a view to identify problem areas. The existing problems and constraints
are identified. These are typical areas where current process has problems and users expect ERP will
solve these problems.
Have an understanding of expectations from future system: These are client’s wish list from the future
system. In some cases this wish list can really become dreams and it is important for the consulting
company to have a control on such wishes, otherwise this may really affect project duration.
Identify areas of improvement in current process.
It is also important to remember that it is not always the case that the company’s users or business process
owners will come up and tell about requirements. As you show them ERP system, they may come up with
new requirements/expectations of things which they do not do in their current systems, but they like to do
it in future.
In most of the cases such requirement gathering happens through a series of workshops.

Business Process Workshops

Business requirement gathering mainly happens through process workshops. Output of such a workshop is
a detailed analysis of the business process and can contain details like:
Details of workshop: Time, date, location, attendees, etc.
Process area overview: Written description of the process area covered by the workshop, what’s
included and what is not, its mission, its scope, primary products and services, a high-level bulleted
list of the requirements and expectations from the process area.
Business objectives, expected benefits and metrics: Business improvement objectives and expected
benefits that will be addressed by this project/solution. List associated KPIs or metrics as applicable
and address the business drivers here.
Process Diagrams: Provide links to all related process maps or diagrams.
Process Area Description: Document “As-Is” state and comments regarding the future state, i.e. the
way the process is expected to work after “Go Live”. This helps in common understanding of process
objectives and requirements.
Roles/jobs: Role/job of the current organisation working on this process.
Business process scope: This list the business processes and process steps which are in scope and
which are in and out of scope. This should also document all process variants, i.e. goods receipt process
 Managing Requirements 123

for spare parts may be different from that of raw materials and these are two process variants of the
goods receipt process.
Detailed process description/explanation: Describes the processes with as much detail as possible.
Business process inputs: List inputs and initiating events for the process.
Business process outputs: Listing of outputs to the next process(es) including output documents
(forms) used in this process. This will also include any operational reports used to work/manage this
process.
Legacy systems used to run the process now – which ones will be replaced and/or interfaced to:
This lists various legacy system used currently to enable the process—which ones will be discontin-
ued with introduction of ERP and which ones will be interfaced in future to ERP system. Explain the
current functions performed by the legacy system.
Process gaps/functional deficits: A high-level gap of the process requirement and what is available
in the ERP package.
Process improvement areas: There are the areas where the company expects improvements by de-
ploying the ERP software.
Process roles: Who performs this process in the organisation and what type of high-level authorisa-
tion the user needs to run the process, i.e. he should be able to view few things, enter few things or
change certain things in the system.
Generally, business process workshops are scheduled by the consulting team with the core team members
and other people in the organisation who are actually doing the process. These workshops are done process-
wise (procure to pay, order fulfillment, etc). It may run through several weeks during business blueprinting
phase and there can be multiple such workshops. The output of these workshops can be documents covering
the details mentioned above and a visual process model.

Business Analysis Question Sets

Having a set of structured questions is another quick way to understand the company’s current business
process, pain points and improvement areas. This is one area where both ERP package vendor and consulting
service provider can add value, based on their experience in several ERP implementations in the past.

SAP Q&A DB

SAP has something called Q&A DB as a part of their ASAP methodology which covers a set of
questions for every organisational process. This database contains a few hundred questions for all
key processes in the organisation like production, procurement, sales, etc and helps in understand-
ing a company’s business processes from an ERP implementation angle quickly. This is a part of
ASAP methodology and is widely used globally for SAP implementation. Figure 8.1 explains the
content of SAP Q&A DB.

Different consulting firms also have developed their own question sets and analysis tools for understand-
ing client’s business within a short time-frame. Below is an extract from one such question set developed
for production planning process.

Production Planning Questions

1. What is the configuration of manufacturing facilities?
124 Enterprise Resource Planning

Fig. 8.1 SAP Q&A DB

2. What is the number of production stages?

3. How many plants are there?
4. What is the number of parts and how is the flow of parts?
5. Where are intermediate storage locations?
6. How many people are involved in the process?
7. What are the product ranges?
8. How is the BOM structure and levels?
9. How many routings are there?
10. What is the manufacturing/storage/transportation cost?
11. What is the production cycle times and what does it include?
12. What is the throughput per day?
13. Where do you have the most inventories? How much and why?
14. How long is a production run? What is the batch size? What is the set-up time?
15. Are you able to track specific customer orders?
16. Are you able to expedite them? How often are you asked to expedite?
17. What are the performance indicators in your department? How is the production department mea-
sured? How are departments within production measured? What reports are generated for production
management?
 Managing Requirements 125

18. What are the key manufacturing issues? What are the bottlenecks in the process: Machines, people,
material, space?
19. What is the duration of a production plan? How frequently is it updated? How detailed is it? How
closely is it adhered to?
20. What are your planning time fences – Are they fixed or rolling?
21. What are your criteria of allocating orders to the various plants?

Summary
Requirement is a set of business needs for which a company implements ERP solution.
Granularity of the requirement increases as we move from top management level to end user level
Requirements should be unambiguous, verifiable and prioritised
Requirements can be business requirements, functional requirements, end user requirements, legal require-
ments or requirements from maintainability point of view
Requirements can be given by management, users, customers, legal and different regulatory agencies
Requirement gathering process follow four steps: Understanding of current business process, current pain
points, expectations from future system and identifying areas of improvements.
Business process workshops are conducted during business blueprinting stage of an ERP project to gather
requirements
Business analysis question sets prepared by ERP product vendors and consulting companies implementing
ERP is another quick way to understand current business process and to gather requirements

Exercise
I. Objective Type Questions
1. What is a business requirement?
2. What are the different types of requirements?
3. Who can give business requirements?
4. What are the four main purposes of requirement gathering process?
5. What is a “maintainability requirement?
6. What is the difference between a “functional requirement” and a “user requirement”?
7. How do business analysis question sets help?

II. Descriptive Type Questions

1. What are the characteristics of a requirement?
2. What are the different types of requirements? Explain each one of them.
3. Explain the purpose of requirement gathering process.
4. What are the things discussed in business process workshops?
 9
Business Process
Reengineering Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
BPR definition and need for BPR
Pros and cons of BPR
BPR – Reasons for failure and key to success
Reengineering phases
Process redesign vs. process improvement/BPR vs. TQM
Role of information technology in BPR/business engineering
BPR and ERP
Benchmarking
Best practices

BUSINESS PROCESS REENGINEERING (BPR)

To discuss business process design, let us first understand what is meant by a “Business Process” and what
“Reengineering” is.

Business Process
According to Davenport: “A business process is a set of logically related tasks that use the resources of an
organisation to achieve a defined business outcome.”1
A business process can also be defined as a collection of activities in a particular sequence that has one
or more “inputs” and generates one or more results that represent added value for an organisation. A process
has a clear beginning and an end, and clearly identified inputs and outputs. Processes are cross-functional
and not restricted within a single function.

1Davenport,T. and Short, J., The new industrial engineering: information technology and business process redesign, Sloan Manage-
ment Review, #32, 1990
 Business Process Reengineering 127

Examples of process are:

Enquiry to order – Order acquisition process
Components to finished products – Assembly process
Requirements to samples – Product development process
As shown in Figure 9.1, a simple process like delivering against a customer order may have several steps
and each of them can perform a part of this process. For example:
Sales department first enters the order
Production department manufactures against that order
Quality department does the quality check and give the final approval to deliver it to the customer
Warehouse does picking and packing of the order
Distribution team transports the goods
Finance team finally do the billing

Fig. 9.1 A Business Process Running Across Multiple Departments of the Organisation

So, business process has some fundamental principles, which are given below:

BUSINESS PROCESS PRINCIPLES

1. It has a number of steps

2. Each step has specific input and output–for example inputs to production process is customer
order and output is finished products that need to be quality tested
3. Each step can run by separate organisational entity/department and done by separate people.
4. Each step should add value to the whole process.

Reengineering
According to Michael Hammer, the father of BPR, “Reengineering is the fundamental rethinking and radi-
cal redesign of business processes to achieve dramatic improvements in critical, contemporary measures
of performance, such as cost, quality, service, and speed”.2
2Hammer, M., Beyond Reengineering, NY: Harper Business, 1996
128 Enterprise Resource Planning

Three important concepts in reengineering are

1. Fundamental Rethinking: BPR is not about doing small changes; it is all about new way of thinking
to do the process.
2. Radical redesign: The new process should look very different from the old one.
3. Dramatic improvements: A reengineered process can bring significant improvement in the process
performance in terms of cost, time or service performance.

Need for BPR

As we defined what Business Process and Reengineering is the next logical question is why you need it.
The simple answer in most cases is “To remain in business”. As an analyst told “Globalisation had made
one thing most evident that if anyone in the world can do your job faster, better and cheaper then no longer
your job will remain as your job”. Let us look at some reasons why you need to look at BPR now:
As Economies in most countries around the world is maturing and not growing fast enough – the
competition among existing companies had intensified as everyone is looking at the same business pie.
Merger and acquisitions or takeovers are becoming the order of the day. If you need to be in business you
need innovative business models, breakthrough products or brands and most importantly running the pro-
cesses better faster and cheaper then your competitor.
Fall of protected markets around the world also intensified competition as goods and services can move
across the border without restriction. This further intensified competition.
Finally, the rise of information revolution had shown the way the information technology can be used
effectively to redesign a process. Walmart had used IT effectively to redesign their replenishment process
known as vendor managed inventory and given the responsibility of managing the process to supplier. Dell
had used IT effectively to change the way people order products and also changed its model of delivering
the product. There are numerous examples on this count.

PROS AND CONS OF BPR

Business Process Reengineering has both its advantages and disadvantages as shown in Figure 9.2. These
Pros and Cons are discussed as follows:

Fig. 9.2 Pros and Cons of BPR

 Business Process Reengineering 129

Pros
Several companies had seen benefits in lot of areas by adopting reengineering. Here are few areas where
typically reengineering brings benefits:
Enterprise integration: Departments are consolidated, several jobs are combined into one job
Worker empowerment
Handoffs are eliminated. Benefits of elimination of handoffs are: no transits, no waiting for another
operator, no waiting in queues, no setups, no supervision/coordination required
There are fewer rules and less coordination is required
Number of steps in a process are reduced, i.e. process is simplified. Inspections, checks and controls
are reduced or eliminated
Every process step is reassessed–Can it be eliminated? Can it be taken off line? Can it be performed
in parallel? Can it be combined? Is it a bottleneck? Can its variance be reduced?
Work is performed where it makes the most sense (For example, Wal-Mart moves the replenishment
function to its suppliers)
Reconciliation is minimised
A case manager provides a single point of contact
IT enables decisions to operate autonomously

Cons/Challenges
A lot of BPR initiatives in the past had failed. After running the project for several months, the business
benefits were never realised. It costed a lot in terms of organisational resources and precious time of senior
executives in the organisation, but at the end, the project had been abandoned in between. Sometimes suc-
cessful BPR prototyping actually made lots of existing jobs redundant. Instead of finding more interesting
assignment for these people, the organisation had thrown them out and this resulted in problems in accepting
the new process during larger rollout. Another challenge of BPR is the high resistance. This kind of initia-
tives are resisted by larger population in the organisation for reasons like fear and rumours.

BPR/PROCESS REDESIGN—REASONS FOR FAILURE AND KEYS TO

SUCCESS
Reasons for Failure
Though benefits of reengineering are well known, there were several reengineering initiatives in the past
which had failed. Figure 9.3 shows reasons for such failures. These reasons include:
No focus on processes.
Spending a lot of time for analysing the current situation – It does not make sense as anyway you are
going to throw it out
Proceeding without strong executive leadership
Going directly from conceptual design to implementation and avoiding prototyping
Ignoring the concerns of people
Poor scoping–100% improvement to a 1% value-adding process is only 2% value addition
Looking for recipes
Fading top management commitment
Tweaking the process instead of radically redesigning it
Assigning less-than-best people to reengineering
130 Enterprise Resource Planning

Fig. 9.3 BPR—Reasons for Failure

Keys to Success
While there is no sure shot formula to succeed in BPR initiatives, few of the things which can lead to a
successful BPR project are as follows:
Committed leadership and top management commitment in the project
Prototyping every process before large-scale implementation
Showing early success within first three to six months. Even if the success is a small one, this interests
everyone in the organisation in the project
Communicating effectively. This helps in managing change. If people are not aware of what the proj-
ect is all about, this can result in fear (of things like job loss) or issues related to acceptance of the
project.

REENGINEERING PHASES
Business process redesign follows a set of steps as described below and shown in Figure 9.4. These steps
need to be followed in right sequence to make reengineering effective.
Step 1 – Have the reengineering team in place
Step 2 – Selection of process to be redesigned
Step 3 – Process diagnosis/Understanding the existing processes
Step 4 – Process Redesign
Step 5 – Prototyping—Design and build a prototype of the new process
Step 6 – Full-scale implementation
 Business Process Reengineering 131

Fig. 9.4 Reengineering Phases

Have the Reengineering Team in Place

Once you start your reengineering project, the first step is to have a team in place – the team who will actu-
ally do the reengineering. As shown in Figure 9.5, there can be different players in this team having specific
roles and responsibilities. Let’s understand some of these roles:
The Leader
Who? Self-appointed and charged with the reengineering zeal, he possesses the necessary clout to push
the reengineering through. Involved in the internal operations of the company. Have within his domain the
entire scope of the reengineering effort.

Fig. 9.5 Reengineering Team

132 Enterprise Resource Planning

Tasks
Identifies the key business processes of the organisation
Appoints senior managers as process owners
Creates the environment by motivating and supporting the team
Establishes measures of performance and rewards
Articulates and communicates the need to reengineer
Process Owner
Who? Manager of a function involved in the process. Has line responsibility.
Tasks
Appoints the reengineering team for the process
Obtains resources for the team
Motivates, inspires and advises the team
Supports and protects radically new ideas
Manages the process once reengineering is over
Reengineering Team
Who? A team of five to ten people. It comprises two groups–Core members (full-time) and Associate
members (Part-time).
Tasks
Produce ideas and plans and debate them exhaustively
Redesign the process
Sell the designed process to the people
Continue through to implementation
Steering Committee
Who? Senior managers. Can include but not limited to process owners
Tasks
Settle issues outside the scope of individual processes
Determine order of priority
Allocation of resources
Settlement of inter-process disputes
Reengineering Coordinator
Who? A senior manager conversant with reengineering techniques
Tasks
Advise the leader on overall management of the "hard" part
Coordinate the ongoing reengineering activities
Provide common approaches
Help in selecting insiders and outsiders for teams
Monitor the process owner
Anticipate and develop infrastructure for the effort
 Business Process Reengineering 133

Change Coordinator
Who? Senior Manager with strong people background. Has been involved in managing large-scale change.
Has been with the company long enough to know its culture.
Tasks
Helps the leader fashion the change management programme
Follows up on the implementation of the programme
Tests and reports periodically the reactions of the rest of the folks
Figure 9.6 shows the different kinds of roles that different reengineering team members play.

Fig. 9.6 Reengineering Players and their Relationships

Selection of Process to be Redesigned

This is one of the most important steps as it involves selection of the right processes to be redesigned. This
step is divided into some sub-steps:
Having a List of High-level Processes Before selection of right processes for redesign, it is impor-
tant to have a list of all high-level processes within the organisation. This is a difficult task as in most cases
the activities done in each and every department in the organisation may be listed as processes (Figure 9.1
shows a list of activities for a high-level process. Often these activities can be termed as a process). For
example, Finance department may tell customer’s credit check is a process, invoicing to the customer is
a process and sending payment reminders to customers is a process. However, these are part of the same
high-level process of “Order Fulfillment” or “Customer Order Management”. Typically, as a thumb rule, an
organisation can have few (may be 5-10) high-level processes like:
Order fulfillment process (OFP) or Customer order management process
134 Enterprise Resource Planning

Procure to pay process (PTP)

Demand generation process
Product development process (PDP)
Employee hire to retire process
Benchmarking Approach for Process Selection It is important to understand how these processes
are measured. One of the measures of order fulfillment or procure to pay or product development processes
can be the duration, i.e. how many days it takes. Data need to be gathered on performance metrics of the
same process within industry, or outside industry, i.e. how many days it takes for companies in the same
industry to do OFP / PTP or PDP and how many days it takes for companies outside the industry to do the
same processes. If you find there is a wide gap between company and its peers in the same industry for a
particular process (For example, company does OFP in 15 days, its competitor in the same industry who
is the market leader does OFP in 5 days), this process can be taken up for reengineering. This approach is
called benchmarking approach for Process selection.
Select Processes that can Show Quick Benefits It is important that the process chosen can show
quick benefits in terms of reengineering. If it takes 18 months to show the first benefit of reengineering,
the chances are high that the reengineering team will loose their momentum and the whole organisation
will loose interest in the project. It is important to show some quick results in the first 3-6 months. For this,
select a process that has such ample low-hanging fruits, i.e. things that can be changed quickly for a better
result. Then, develop the business vision and process objectives.

Process Diagnosis/Understanding the Existing Processes

The first initiative for process improvement is to understand the current process in greater details. This is
called “Process Diagnosis” and helps in gaining quick insights into the problems of the current process.
Few cautions for this exercise are:
Do not spend too much time in analysis–this may often lead to paralysis. Have a quick scan.
Break rules and assumptions during this diagnosis – As Hammer argued that many things were done
in organisations because “that was the way they had always been done”, not because they had added
value.
Key steps in process diagnosis as shown in Figure 9.7 are:
Map current process in terms of inputs, outputs, customers and the conversion it performs. Understand
the steps in the process. Assess whether the customer values the process.
List the key steps/activities, along with activity timings and information systems utilised
Categorise the activities into value adding, non-value adding and waste activities
Understand the issues in the process
For these issues, examine the rules behind them and assumptions behind each of these rules
Typical Non-value or waste activities of a process are:
Expediting
Storing items
Moving material (in and out of the company and inside)
Checks and controls in a process
Inspection
Reworking
Reconciliation
 Business Process Reengineering 135

Fig. 9.7 Process Diagnosis Steps

Examples of some common process problems

No end to end ownership of the process, lack of ownership
A large number of audits and reconciliation which do not add value for customer
Everyone measures task performance and not process performance
Very few of the process steps are value adding
Reasons for such process problems
Several hand-offs and transfers of ownership in the processs
Fragmentation of process across several departments
Process is underdesigned or overdesigned
Poor training and education of process participants
Example of problems, rules and assumptions of a process are:

Problems Rules Assumptions

Hand-offs Enquiries go from marketing to R&D R&D and Marketing must exist as separate
departments
Delay Loan application must be processed by one A document cannot exist in two places at
department after another sequentially the same time

Reengineering principle tells about breaking these limiting rules and challenge assumptions of the process.
In the above example, why enquiries need to go from marketing to R&D? Why marketing and R&D can
not coexist? A lot of these may not be practically possible to change, however, it is important to question
every assumption and every process rule.

Process Redesign
This is the phase in which the actual redesign is done. As told earlier, there is no sure shot recipe or ten
defined steps which need to be followed and you get a better process. Process redesign is about innovation
and about fundamental rethinking.
136 Enterprise Resource Planning

Reengineering Principle However, based on numerous projects in the past, a few common principles
evolved as shown in Figure 9.8. Table 9.1 shows a few of them.

Fig. 9.8 Reengineering Principle

Table 9.1 Redesign Principles

Reengineering Principle Details

Maximize value adding (VA) steps, Recognise steps that are VA, NVA and Waste. VA steps are the only steps
Minimize non-value adding (NVA) which work for the customer.
steps and Eliminate Waste
Parallelise work Try to remove sequence using technology and accomplish tasks simultane-
ously. Use concurrent engineering. This speed up the process by reducing
time lag between early and late steps. Precedence in a process need to be set
only in case there is a need.
Try to simplify process Avoid over engineering. Simple processes are less costly and more flexible.
Multiple versions of the same Different versions of the process are needed for different markets and differ-
process ent situations. While in 90% of the cases the process may follow the simple,
standard path, in 10% cases the process may follow large complex path. A
good example of this can be loan processing in a bank. The bank may define
a process that in case of loan up to Rs 10 lakh, some simple documentation
and decision of loan disbursement manager is enough, while for loan beyond
Rs 10 lakh, there need to be elaborate documentation and review process and
loan disbursement manager and bank branch manager need to jointly authorise
and approve the loan.

(Contd)
 Business Process Reengineering 137

(Contd)

Enable workers to make decisions This is also called vertical compression, i.e. workers need not look at the
vertical hierarchy to get decision on a process. Process decision-making is
not strictly a management task. Workers are empowered and decision-making
becomes part of their work. This helps in fewer communication delays, lower
management overhead and better customer response.
Reduce audits, checks and controls It costs to put controls and so, use it only when it makes economic sense.
Implement deferred controls. Design quality into a process and identify prob-
lems when they occur. Downstream inspections does little to improve quality
and add higher costs in the form of rework.
Provide single point of contact for They are also called Case Managers in reengineering term. As shown in Figure
the process 9.9, a case manager is a single point of contact for a process, is the process
“owner”, has access to all people and information systems involved in the
process and is empowered by management to change the process.
Combine several jobs into one Assign multiple process activities to one person and avoid division of tasks.
This helps the person to get a complete view of the entire process and take
decisions which are good from complete process perspective. This is in con-
trary to the principles of Industrial Revolution which talks about division of
tasks, specialisation of labour and no need for communication
Organise around processes (exit Teams need to be formed to perform an entire process and work should not
departments, enter process teams) be split by function. It is better to co-locate such process teams where each
person understands another's responsibility. Cross training is a necessity. This
also reduces management overhead in terms of coordination within different
functions. Figure 9.10 shows such a process-centred organisation where there
is a process owner for each process and process owners depends on several
centres of excellence for bringing competency in the process. Each such centre
of excellence can be managed by a coach. For example, for managing an order
fulfillment process, order fulfillment process owner may need people with
different expertise who come from different centres of excellence.
Enabling bosses - "coaches" In the world of reengineering, there is no boss. Bosses turn to coaches who
help a process team to meet their objectives.
Adopt customer perspective Be available when the customer wants to interact. Understand customer’s
wants and needs (What are the customer’s goals, objectives–wants and needs?
Are we meeting these? Are there unknown wants?).
Automate appropriately Avoid automating current processes unless needed as automation can also
mean doing wrong things faster. Automate repetitive tasks. Leave interesting
jobs for people.
Organisational structure should
support business process

Who and What all can add Value to Redesign This being the most important stage, you can
engage some outsiders beyond the reengineering team to give inputs on the process.
An outsider who will look into the process with a fresh eye and will raise questions about all the rules
and assumption of the process which was explained earlier. To an insider, sometimes it is difficult to
question this as they had lived with the rule so many years.
138 Enterprise Resource Planning

Fig. 9.9 Case Manager Concept

IBM Credit (Source: Sia and Neo, JMIS 1997, p 71)

Fig. 9.10 Hammer’s Process–Centred Organisation

Source: Hammer, Beyond Reengineering, 1996, p. 126.

An information technology person can provide inputs on how technology can be used to better design
the process or break some of the rules and assumptions. Think about that old rule in the banking
industry that if you want to take money from your account, you need to visit your bank where your
account is. Technology like ATM and internet banking had broken this assumption and changed the
rule of the game.
A person who had seen the same process in a company, runs it much more efficiently.
Levers of Process Redesign Reengineering affects everything in the organisation. Changes are seen
mainly in these five areas:
Roles and responsibilities – New roles (like case manager) emerge and existing responsibilities
changes (bosses turn coaches)
Measurements and incentives – Process measures become more important than task measures. Incen-
tives are based on whole process performance and not on how an individual function is performing.
 Business Process Reengineering 139

Sales guy does not get incentive because he had booked more order in this quarter, but he gets incen-
tive as part of order fulfillment team if the process is a success.
Organisational structure – Organisation structure changes. The structure becomes more flat. In a
process-centered organisation, there are process owners and centres of excellence for each skill man-
aged by coach.
Information Technology – Information technology becomes an enabler for process redesign.
Skills – From narrow functional skill to multi skilling becomes important where a person understands
the entire process. In BPR terminology they are often called as “Case Managers”. Figure 9.9 shows
one such example of case manager who handles the entire credit management process.

Prototyping and Detailing the New Process

This is an important step which is often missed out and one of the major reasons for BPR failure. The process
need to be first run for a small set, i.e. if you are designing a order fulfillment process, run it for a small
set of customers on trial basis. If it is a new procure to pay process, run it with a small set of your long-
standing suppliers who are ready to share some risk with you. Now you can test the process that whether it
is really working, and what are the issues with the process. If the process fails in a real life situation, you
can take the learning from this failure and refine the process further and retest.
Prototype also helps in detailing the process as this is the first time the process is in use. What will be
the exact process steps, inputs and outputs for each step
How information system can be used in each step?
How the process will be measured?
What are the new skills needed to run the process?
What will be the new roles?
What organisational structure is needed to support?
How knowledge transfer of the process will happen? What all things should be contained in the train-
ing material? How many days’ training will be needed? Who will provide training?
While answer to most of these questions is already prepared during the redesign phase, the final version
of it is only ready after the prototyping. During redesign you may think three days training on the new
process is enough but only during prototyping you discover the training audience is pretty different then
what reengineering team thought and actually you need five days of training.

Full-scale Implementation
The final stage of redesign where the new process need to be rolled out in a large scale. Depending on the
type of process, it may be to all suppliers (for procure to pay process), to all customers (for order fulfill-
ment process) or to all products (for product development process). The cutover from old process to the
new to be planned in detail. Change management is a big challenge now as you are touching the entire
organisation.

Process Redesign Vs. Process Improvement/TQM

Sometimes process redesign and process improvement are used in the same way. However, these two are
very different concepts. While the first one is about radical process design, the second one is more about
regular small improvements. Figure 9.11 explains this difference. Table 9.2 shows how these two approaches
are different on several parameters.
140 Enterprise Resource Planning

Fig. 9.11 Business Reengineering vs. TQM

Table 9.2 Difference between Process Improvement and Process Redesign Approaches

Parameter Process Improvement/TQM Process Redesign/BPR

Level of change Incremental Radical
Starting point Existing process Clean slate
Frequency of change Continuous One-time
Time required Short term Long term
Participation Bottom up Top down
Typical scope Narrow Broad
Risk Moderate High
Primary enabler Statistical control IT
Type of change Cultural Cultural/Structural

ROLE OF INFORMATION TECHNOLOGY IN BPR AND BUSINESS

ENGINEERING
Information technology was one of the major drivers for business process reengineering (BPR) revolution.
However, it is important to remember that run-of-the-mill use of IT (for things like payroll processing,
accounting, etc) does not provide competitive advantage and is not of much help for business process reen-
gineering initiatives. For successful BPR, focus need to be on:
Designing processes around IT
Disruptive use of IT
Strategic use of IT

Business Engineering—Definition
Some people like to define information technology-driven business process engineering as business engi-
neering, i.e.
 Business Process Reengineering 141

Business Engineering (BE) = Business Process Reengineering (BPR) + Information Technology (IT)

The way we defined BPR in this book, we always assumed that information technology is an integral part
of BPR and from that prespective there is no difference between BPR and BE. However, there is always a
possibility that you are reengineering a process without use of IT at all and in that case this will be a BPR
project, but not a BE project. Moreover, BPR projects without using IT is not common these days and only
exists in theory.
Table 9.3 shows few examples of how information technology can be used to change the rules of a busi-
ness process.

Table 9.3 Use of IT in Changing Rules of Business Processes

Old rule of business Disruptive use of IT New rule of business

Information can be available only Shared relational databases Information can be available simultaneously in
in one place at a time as many places as required
Only experts can perform complex Expert systems A normal employee can do the work of an
work expert
Managers make all decisions Decision support tools Decision-making is part of everyone’s job
Plans get revised periodically High-performance computing Plans get revised instantaneously

BPR AND ERP

The major benefit of an ERP implementation comes from improvement of process and not by merely auto-
mating the existing processes through ERP. If every process remains same and just ERP automates that, in
most cases there is not much payback on ERP investment. There is an old proverb:

Old process + New technology (to enable old process) = Costly old process
Ideally, BPR to be used to build TO BE processes or future business model for ERP. This leads to the ques-
tion that whether you should take up a pure reengineering initiative before ERP project.

Whether to do a Full Blown BPR, no BPR or Take a Middle Path?

Perhaps the most ideal solution is you first redesign the processes and then enable those best designed
processes with ERP. However, there can be several issues with this approach like:
It will definitely take much longer time and cost to implement the solution.
There is no guarantee that those best designed processes will be supported by the ERP solution.
This whole approach may take three to four years time by which your business dynamics can change,
i.e. you had acquired new company or opened new line of business–then it is starting all over again
from scratch.
For these reasons, several companies these days take a middle path, i.e. to the extent try to follow the best
practice processes that come along with the ERP solution (as these processes are also tested over thousands
of companies in diverse industries) and along with that do a limited BPR of existing processes (not a full
blown BPR) in a way that gives them competitive advantage ensuring the process is supported by the ERP
142 Enterprise Resource Planning

solution. This approach ensures that the implementation time-frame is not too long and TO BE processes
designed mostly supported by the ERP solution.

To What Extent to do BPR—Rules are Not Same for all Organisations

To what extent you will do BPR in most cases depends on ERP project timeline, the size of the organisation
and its process maturity. While a large organisation which wants to spend 12 months in business blueprint-
ing and can afford a separate team may look for a full-blown BPR before ERP configuration starts, a client
from small and medium business (SMB) which can afford just three months for business blueprinting will
go for limited BPR and will be mostly guided by the ERP best practices process.

Me and My Competitor has Same ERP—Where is the Competitive Advantage?

Which processes you should take up for BPR before going for ERP implementation again differs by or-
ganisation. One of the common questions against fully following ERP best practices is that if you and your
competitor both implement the same ERP with the same set of best practice processes, then where from your
competitive advantage comes? The approach taken by several companies is to do BPR for the processes
where they believe that they are different and the ones which are most important for them. For example, a
consumer goods company may do BPR for their distribution processes, but may follow the standard finan-
cial processes as given by an ERP solution. An automotive company may do BPR for their manufacturing
processes and adapt to standard ERP processes for human resource management.

BENCHMARKING
Benchmarking is defined as “the process of comparing one's business processes and performance metrics to
industry bests and/or best practices from other industries”. Best is generally measured in terms of quality,
time and cost, i.e. the goal of benchamarking is to do things better, faster and cheaper.
The process of benchmarking involves management identifying the best firms in their industry, or any
other industry where similar processes exist, and compare the results. The company with which the processes
are compared is called “Target”. For example, a consumer goods company while doing benchmarking for its
promotion ROI (return on investment) measures may set the target looking at the leader in the same industry
and will like to adopt similar processes in promotion planning. However, the same company may choose a
leader from another industry, say a leading automotive company for doing benchmarking of its inventory
management processes. Figure 9.12 shows an example of financial benchmarking for a company against a
set of financial KPIs.
There can be different types of benchmarking as shown below:
Process benchmarking: Here the focus is on business processes with a goal of identifying and ob-
serving the best practices from one or more benchmark firms.
Financial benchmarking: Perform financial analysis of the company and its benchmark company to
assess overall competitiveness and productivity.
Performance benchmarking: Assessing competitive position by comparing products and services
with those of target firms.
Product benchmarking: This is for designing new products or upgrades to current ones.
Functional benchmarking: Here a company can focus on a single function (for example, human
resource) to improve the operation of that particular function.
A typical benchmarking exercise can have following steps:
1. Identify problem areas: It is always better to focus on few business processes or few functional areas
before starting benchmarking exercise.
Fig. 9.12 Financial Benchmarking for a Company
Business Process Reengineering
143
144 Enterprise Resource Planning

2. Identify targets (leaders in the similar industry or other industries that have similar processes):
At this stage, it is important to identify which companies can be taken up as reference. There are
companies which are known across industries for excellence in particular processes. For example,
Toyota in Just in Time inventory management, P&G and Walmart in VMI/inventory replenishment
process, Motorola in Six Sigma quality management, etc. A target can also be a company from the
same industry and this is more important for industry exclusive processes like a mining company need
to learn best practices in the exploration process from another mining company in the same industry
and not from a consumer goods company.
3. Identity measures and best practices in the target company: Once the target companies are identi-
fied, it is important to identify the reasons for which the company is best in a particular process, how
the process is done, how it is measured, how IT is used in the process, etc.
4. Implement new and improved business practices: Finally, it is time for implementation of the best
practices process. Once the best practices process is identified, the plan needs to be made on how to
implement the same in the company and implementation needs to start.

How Benchamarking helps ERP Projects?

Some companies prefer to start an ERP project after a benchmarking exercise where it is clearly understood
what process performance the company is expecting after the project completes and what business processes
they want to adopt from best practices companies. Benchmarking sets a clear guideline for the project, say
the company wants to improve inventory turnover through ERP implementation, they want to achieve a
level of inventory turn of 12 from the current level of 6 and for doing so they want to design their TO BE
processes in line with company A, which is a market leader in the industry and which is already operating
at an inventory turn of 14. This may be sometimes a much better approach to start an ERP project then
making a TO BE design out of company’s own intelligence and which is till date not a proven one and will
be done first time for the company.

BEST PRACTICES
What is Best Practice and from Where They Come?
These days most of the leading ERP solutions offer numerous best practices as part of standard package.
Best practice can be defined as “A particular way of doing a business process that is proven and had given
benefits to numerous companies”. There are different origins of Best practices, for example:
In some cases a particular best practice is invented by a particular company and later on offered by ERP
vendors as part of their suite. For example, Just in Time or Kanban was invented by Toyota, Vendor
Managed Inventory process was invented by P&G and Walmart and Cross Docking was invented by
Walmart – but all these processes are now part of leading ERP packages.
In some cases, a particular best practice may be invented not by a particular company, but by a set of
companies in the same industry. For example, in retail industry a body called ECR (efficient consumer
response) had come up with a set of best practices for retailers in the areas of category management,
assortment planning, material handling, etc. Most of the leading ERPs today offer these practices as
part of their retail version of the ERP solution.
Finally, in some cases ERP vendors also came up with specific best practices. As these vendors had
seen how a particular process is done across several industries, over time they gained knowledge on
this process and learnt the best way of doing it and made it available as part of their solution.
 Business Process Reengineering 145

Best practices may differ depending on a particular industry and sometimes on a particular country. This
is because a best practice for scheduling vendors for production items for an automotive company which has
thousands of vendors may not make sense for a petro chemical company which has very few production raw
materials and few long term vendors. In the similar way, best practices of excise accounting and tax man-
agement for India may not make sense for the US, as the laws are very different in both the countries.

What ERP Vendors Offer as part of Best Practice?

Most of the ERP vendors these days have come with a best practice library-specific to every industry. This
sometimes comes as a pre-configured solution with
Best practice processes
Recorded configuration settings to activate these processes (for example, SAP has something called
BC sets that can record all SAP related configurations for a process)
Documentation of the business blueprint and configuration of the process. This helps in training
Test scripts to test the process
Master data sets for the process
This helps in quick implementation of processes with minimal effort. While for every company, these
processes need little adoption, i.e. it may not meet 100% of a company’s requirement and may need some
company specific settings. What companies had seen is that in some cases these best practices processes
can be reused to the extent of 80% and that means lot of savings in terms of blueprinting, configuration and
testing effort.
Initially, ERP best practices were mainly targeted for small and medium companies which want a rapid
ERP implementation as a host of things needed during implementation is already in place (like business
blueprint, configuration document, test scripts, etc). Nowadays, it is also getting popular with large enter-
prises looking for a quick ERP deployment.

LEADING ERP PROVIDER SAP PROVIDES FOLLOWING BEST PRACTICES PACKAGE

SAP Best Practices Baseline Package: It provides generic business scenarios that can be
used as the basis for designing a particular solution. For example, basic processes like ac-
counting, master data set up, etc can be part of this.
SAP Best Practices Industry Packages: It is designed to meet industry-specific needs. For
example, SAP best practices for retail helps in point of sales (POS) processes.
SAP Best Practices Cross-industry Packages: It provides predefined business scenarios
that focus on the areas of customer relationship management, supply chain management and
business intelligence.
Source: http://help.sap.com

Summary
In this chapter, Business Process Reengineering (BPR) concepts and the need of BPR for ERP implementation
are discussed in detail, covering the following points:
146 Enterprise Resource Planning

Reengineering talks about three main concepts: Fundamental rethinking, radical redesign and dramatic
improvements.
While BPR can lead to a better process in terms of fewer steps, less non-value adding activities and lesser
reconciliation, it provides several challenges in terms of high chances of failure, massive resource commit-
ment from organisation prespective and difficult change management.
Keys for BPR success is top management commitment, showing early success, prototyping and effective
change management.
Reengineering is a six-step process: Putting together the team, selection of process, process diagnosis,
process redesign, prototyping and full-scale implementation.
It is important to challenge every rule and assumption during the redesign process.
Redesign principles are good thumb rules to follow during the redesign process
Innovative use of IT, new process measures, new roles, new organisation structure are some of the outputs
of the new redesigned process.
While BPR talks about radical improvements, TQM talks about incremental improvements that keep on
happening regularly.
Business engineering is about using BPR with IT. Use of IT is needed is for innovative purpose for BPR
and not for routine jobs.
While using a full-blown BPR approach for every TO BE process before starting an ERP implementation
may be an ideal one, that may not be always practical due to time and budget constraint. A mixed approach
of doing BPR for the processes that give competitive advantage or most important and following standard
ERP best practices process for others is mostly a common strategy that companies follow.
Benchmarking helps to define targets for a company in terms of process performance and adopting best
practices from a target company which can either be a leader in the same industry or a leader across indus-
tries.
Leading ERPs these days are coming with a set of pre-configured best practice processes that include busi-
ness blueprints, configurations, test scripts, master datasets, etc. This helps in quick implementation of the
process. SMB (small and medium business) sectors is the main target for such pre-configured best practice
solutions.

Exercise
I. Objective Type Questions
1. What are the three important concepts of BPR?
2. What are the four fundamental principles of a “Business Process”?
3. What are the six phases of a reengineering project?
4. Who is a reengineering process owner?
5. Who is a reengineering change coordinator?
6. What is a benchmarking approach for process selection?
7. How does “Process Diagnosis” help?
8. Give examples of seven “Non-value adding” process steps.
9. Give examples of four common process problems.
10. What are five levers of process design?
11. How does prototyping help in new process design?
12. Give three differences of BPR and TQM.
13. What is business engineering?
 Business Process Reengineering 147

14. What are the five types of benchmarking?

15. What are the four steps of benchmarking?
16. What is “best practice”?
17. Who are case managers?
18. What is meant by “multiple versions” of the process?
19. What is “concurrent engineering”?

II. Descriptive Type Questions

1. What is a business process? Give some examples of business process. What are the fundamental principles
of business process?
2. What is BPR? What are the three important concepts of BPR? Why is BPR needed?
3. What are the pros and cons of BPR?
4. Why did BPR projects fail in the past? What are the key criteria for its success?
5. What are the reengineering stages? Explain each of them.
6. Who all make the reengineering team? Explain the role and tasks of each one of them.
7. Explain the process of selecting the process to be redesigned. What are the different approaches for process
selection?
8. What is process diagnosis? What are its key steps? Give some examples of problems, rules and assumptions
of process.
9. Explain some of the redesign principles.
10. What are the levers of process redesign?
11. How process design can be compared with process improvement? Do a detailed comparison.
12. How can information technology help in BPR? What is business engineering?
13. How are BPR and ERP projects related? How much BPR should be done in an ERP project? Discuss pros
and cons of different approaches.
14. What is benchmarking? Explain different types of benchmarking. Define the Benchmarking steps. How
does benchmarking help ERP projects?
15. What are best practices? From where do they come? What do ERP vendors offer as part of the best prac-
tices?

III. Fill in the Blanks

1. BPR stands for _______________ _____________ _______________.
2. NVA stands for _______________ _____________ _______________.
3. Business Engineering = ______________ + _______________.
4. Three important concepts of BPR are ______________ rethinking, radical _________ and ___________
improvements.
5. Steering committee for a BPR project is made up of _________ _________.
6. Reengineering principle is: ___________ VA, ___________ NVA and ____________ waste.
7. Case managers are single ___________ _________ ___________ for a process.
8. A process can have ____________ versions.
9. Reengineering combines _________ jobs into __________.
10. Reengineering principle talks about automating _________ tasks.

IV. State Whether the following Statements are True or False

1. Reengineering talks about one particular way (version) of doing a job.
2. Reengineering necessitates organisation structure to become more flat.
148 Enterprise Resource Planning

3. Risk in process improvement is higher than process redesign.

4. Reengineering brings more audits and checks into the process.
5. Reengineering simplifies process.
6. Reengineering necessitates bosses to monitor the process.
7. Reengineering enables workers to make decisions.
8. TQM generally had broader scope than BPR.
9. IT is primary enablers for TQM.
10. Redesign brings in new roles.

V. Assignments
Study an organisation that had taken up a BPR project in the past and note down the following details:
Which processes they selected for BPR?
How was the process looking before BPR (put a visual diagram for the process and details the process
steps)?
How does the process look after BPR (put a visual diagram for the process and details the process
steps)?
What had really changed?
What benefits had the company got out of this exercise?
Whether there were new roles created during this redesign?
What are the new process measures?
How information technology (IT) is used in this process? Is there a change in the way the IT was getting
used earlier (before redesign) and now (after redesign)?
 10
Business Process Modelling
and Business Modelling Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Business process modelling
Business process hierarchy
Standards for business process and business process modelling
Process modelling maturity and multi dimensional modelling
Process modelling software
Business modelling
Integrated data modelling

BUSINESS PROCESS MODELLING—INTRODUCTION

Different organisations name this activity differently. This is either known as Business Process Modelling
or Process Modelling or Process Mapping.

What is This?
Process model is a visual representation of different activities and steps of the process, data flows and in-
puts–outputs for different steps of the process. It can also show which organisational entity runs the process
now.

Why Do You Need It?

One of the important step in Business Blueprinting is to design better processes. Value of an ERP imple-
mentation mainly comes from how better you design the processes and not by merely automating the
current processes by using ERP. To design a better process, the first step is to understand how the process
is happening today. One way is to understand the process is to write down its all steps, different decision
points, inputs and outputs to the process, who do each part of the process, etc. However, it is often seen
that if you write a process using several pages (for large process it may run into hundreds of pages), it is
still difficult to understand the process steps and dependencies from a word document. More importantly, if
150 Enterprise Resource Planning

you are documenting this process for doing some process improvement, you need to show the current and
future processes to several stakeholders for taking a decision, a word document running into several pages
is a challenge to present.
Instead a simple diagram that explains the process, several process steps and input-output for the process
can help a lot. It is easy to document, easy to present and if people see the current process diagram and the
redesign the process diagram side by side, they can quickly visualise the improvement areas and can take
decision. Process modelling software can help in this area to diagrammatically represent a process. Process
modelling covers the depiction of processes as flow diagrams that capture relationships between events as
well as cost and resource constraints.
There is a traditional challenge of putting a business process in software and that is because business
people and IT experts often do not speak the same language (while a business owner will talk about sales,
inventory, the IT expert is bothered with Java code or C++ programming). Business modelling tools tried
to bridge this gap.

IT IS NEEDED BECAUSE:

This is visual and easy to understand. It quickly shows the activities under a process and steps
under each activity. It also shows the relationship and data flows between them and which
organisational entity does it.
Easy to identify improvement areas in current process – point of handoffs, unnecessary steps
that can be eliminated, etc
A quick comparison of AS IS and TO BE processes.
Can help quickly to navigate from business scenario to business process to an activity and
even to a step within the activity.
Bridge the gap between IT people and business users who generally do not speak the same
language. This is a common ground for communication across the enterprise.

Some Thumb Rules for Process Modelling/Process Mapping

While mapping or modelling a process, it is important to follow some thumb rules as follows:
Each process should have specific inputs and outputs.
Each process should cross a number of functional boundaries.
While mapping a process, focus on goals and ends, i.e. the purpose of the process and not much on the
steps, i.e. how the process is done. Differentiate between the means (forms, documents and procedures)
and the end (value added, deliverables). You can always come up with a different way of doing the
process, if the process goals are met.
Processes should relate to customers and their needs, either directly or as contributors to other pro-
cesses.
Identify only inputs and outputs of the processes–why the process exists.
Process map creation must be evolved by a cross functional senior management team.
While designing a process, assume no organisational structure or boundaries. If you start today and
have to do it in the best manner possible, how would you do it? This is, especially important for TO
BE process modelling.
Think outside all constraints. Process design is all about innovation. Again, something important for
TO BE models.
 Business Process Modelling and Business Modelling 151

Difference Between AS IS and TO BE Modelling

There is no hard and fast rule. However, the general guideline is the AS IS Model need to be modelled with
less details and TO BE process need higher detailing.
AS IS Modelling
Purpose: Process Improvement Often while doing AS IS modelling companies forget the end purpose
of the exercise, i.e. process improvement. While months or years can be spent understanding the details like
how each activity in the process is done today, who does it, how much time it takes, what forms or reports
are used etc, this exercise may not be of much value as anyway the process will be thrown away in the
future. This is analysis for paralysis syndrome. During AS IS modelling, the ground rules described above
need to be remembered. It is important to understand why the process exists, purpose of the process and
process goals. Detailing the steps is not much important here as there can be always a new way of doing
the process with new steps, what is important is the understanding of the purpose of the process and so, in
most cases, a high level process models meets the purpose.
TO BE Modelling
Purpose: To Explain the New Way of Working to Business Users, ERP Configuration While TO
BE modelling need to do modelling with sufficient details as there may be new steps, new data flows, new
input-output relationships, new roles, new organisation structure to support the process and new measures
to measure the process performance. Information technology can be used differently in TO BE design, then
how it is used today. All these need to be explained to all the people in the organisation along with what is
the benefit of doing this in a new way (TO BE way) compared to the way they used to do it earlier (AS IS
way). So TO BE modelling need to be with sufficient details detailing each activity and step of the process,
input-output relationships, who does it, etc.
Detailing is also important for another reason. These processes need to be finally configured in the ERP
system. To do that configuration, any ERP will need step-level details so that this can be modeled to an ERP
transaction. If modelling is not done with sufficient details, this purpose is not solved.

BUSINESS PROCESS HIERARCHY

What Is This?
Business process hierarchy is a logical grouping of business scenarios, business processes, activities and
steps. Business scenarios are at the highest level and can be made up of several business processes. Business
processes are the second level in the hierarchy and each business process is made up of a set of activities
and each activity can be made up of a set of steps.
Figure 10.1 shows an example of a business process hierarchy which covers the following:
Supply chain management is a business scenario.
Supply chain management scenario can have several processes like order management, production
planning, procure to pay, etc. Order management process in this example is exploded further.
Order management process can be made up of several activities like order taking, checking credit
worthiness of customer, pricing, delivery scheduling, etc. Delivery scheduling activity in this example
is exploded further.
Delivery scheduling activity can be made up of several steps like delivery date calculation, scheduling
of trucks for delivery, finalising route for delivery, etc. One of these steps “delivery date calculation”
is shown in the example.
152 Enterprise Resource Planning

Fig. 10.1 Business Process Hierarchy

How Does It Help?

Business process hierarchy helps in various ways like:
It helps to see people processes at different levels. The company’s CEO or senior leadership team
may be interested in seeing at scenario level, a process owner may like to see it at process level and
a factory shop floor operator or accounts clerk may be interested in steps that he need to perform.
Based on the organisational role, people can explode and analyse the process. A finance person
may be interested in blowing up only the financial activities and want to see the detailed steps.
It is easy to navigate from scenario to process to activity to step
It is easy to define roles at different levels, i.e. who is supposed to carry out a particular step, who
is responsible for an activity, who is the overall process owner and who sets direction for an overall
scenario. These role definitions are extremely important during ERP implementation as you know now
who is supposed to do what and if something is not happening as per the plan, whom to follow up.

STANDARDS FOR BUSINESS PROCESSES AND PROCESS

MODELLING
Standards for Business Process Definition
One of the biggest challenge in process design and process modelling is that there is no hard and fast rule on
what you define as a process. For example, activities and steps included in order fulfillment process (OFP) for
a company may be very different from the activities in OFP for another company. One company may include
supplier payment activity as a part of the procure to pay process, the other company may make it a part of
the financial process. Lack of standards about process definitions create problems while trying to integrate
 Business Process Modelling and Business Modelling 153

one company’s process to another which is frequently becoming a requirement these days for reasons like
merger and acquisition (M&A) or collaboration among companies and its suppliers and customers.
Fortunately, in last two decades, standards started evolving in various forms like enterprise process
standards, standards for specific process area and standards for specific industry processes. While it is not
mandatory that you follow these standards while defining your processes, it is always good to follow this
because of their global acceptance. Several years of research had gone behind developing these standards
and increasingly ERP vendors started supporting these standards in their application. Some of such common
process definition standards are:
Enterprise Process Standard—APQC Process Classification Framework America’s most
leading quality body APQC defines a process classification framework where all business processes are
defined in terms of seven operating processes and seven management and support processes as shown in
Figure 10.2. Each of these fourteen processes are detailed up to five levels. An organisation can follow these
process definition standards as it covers almost every process of an organisation with sufficient details. Most
of the leading ERPs today support APQP for process definitions.

Fig. 10.2 APQC Process Classification Framework

Supply Chain Process Standard—Supply Chain Operation Reference Model (SCOR) SCOR
is a body of supply chain professionals of more than 900 leading companies across the world. As shown in
Figure 10.3, this groups all supply chain processes in five major categories, i.e. plan, source, make, deliver
154 Enterprise Resource Planning

Fig. 10.3 SCOR Standard for Supply Chain Processes

and return. Each of these is further broken down at lower levels. SCOR has a standard way of modelling
supply chain processes and also offers a set of metrics by which supply chain process performance can be
measured. SCOR is a widely popular process standard and all leading supply chain application in the market
support SCOR standards. For example, SAP’s supply chain software SAP APO was built on SCOR supply
chain process standards.
Industry Process Standards Some of the industries are also coming up with their own standards for
defining processes. For example, retail industry has a body called ECR (Efficient Consumer Response) which
is developing standards for retail-specific processes like category management, assortment, merchandise
management, etc.

Collaboration Process Standards There are organisations like VICS (Voluntary Intra-industry Com-
merce Standards) which is defining standards for collaborative processes within companies, i.e. standards
for processes like VMI (Vendor Managed Inventory) and CPFR (Collaborative Planning Forecasting and
Replenishment).

Standards for Business Process Modelling

As standards are evolving for process definition, there are also standards for doing process modelling. Some
of the widely accepted standards of process modelling is listed in Table 10.1.
 Business Process Modelling and Business Modelling 155

Table 10.1 Industry Standards for Business Process Modelling

Business Process Modelling– Standard Details

Industry Standards
Event driven process chains EPC were originally developed by IDS Scheer to illustrate SAP processes within
(EPC) the ARIS framework. However, their application has since extended beyond
this and EPCs are now considered one of the leading standards for modelling
business processes.
Business process modelling BPMN is a standardised graphical notation for modelling business processes. The
notation (BPMN) notation is strongly IT-oriented and is maintained by a standards organisation,
called the Object Management Group. Both IBM and IDS Scheer are members
of OMG, which also governs standards for processes and methodologies.
Unified modelling language UML is a leading standardised specification language for object modelling in the
(UML) software engineering sector. It was compiled by three object-oriented software
methodologists within rational software and is supported by the rational unified
process methodology.

PROCESS MODELLING MATURITY AND MULTI-DIMENSIONAL

MODELLING
Figure 10.4 gives a snapshot of maturity of process modelling. In the most basic level, modelling means
visually depicting basic process flows. In the next level, organisation elements and roles can be added, to
this that defines who does these activities. In the third level of modelling resources and controls can be

Fig. 10.4 Process Modelling Maturity Continuum

156 Enterprise Resource Planning

added, i.e. these talks about what checks and balances in place at different stages of process and how many
people (or other resources) carry out these activities or steps. In the next level of modelling infrastructure
and data is added, i.e. what data get generated during the activity or process, what data is an input to the
process and what data is output. Finally, time and cost are added to the process model to denote how much
time it takes to do a particular step and how much it costs.
So, a process model can have multiple dimensions. Table 10.2 shows these multiple dimensions of process
models.

Table 10.2 Multiple Dimensions of Process Models

Dimension Description
Graphical model This provides the pictorial representation of the process model

Resource model This allows to define all resources so that they can be associated to the model
Information model This provides a view of data and how data is used within a business process
Organisation model This provides the definition and structure of all of the organisation units and their
associated resources
Analysis model This is where the definition of key process metrics and attributes are defined and
then analysed

PROCESS MODELLING SOFTWARE

Software is widely used for process modelling. Even for a medium size company, the number of processes
can range between 40-100, the activities can go up to a few hundreds and steps can range up to a few
thousands. It is very difficult to draw visual models for such a large number of objects. Moreover, complex
modelling like adding resources, data and organisation is almost impossible to do without help of a software
tool. Software tool also helps to blow up a part of the process, do advanced simulation and other analysis.
Process modelling software can be divided in two categories—Basic or simple process modelling tool
and advanced modelling tools. Microsoft Visio is very popular in the first category, i.e. as basic process
modelling tool. Tools like IDS Sheer’s ARIS and IBM’s Websphere Busines Modeler are popular in advanced
business modelling tool category.

Capability of Process Modelling Software

Capabilities of process modelling software can be divided mainly into three categories: modelling capabil-
ity, simulation capability and capabilities of having pre built process models for specific business process
or particular industry. While basic tools supports the first category, i.e. modelling capabilities, it does not
have capabilities in the other two. Advanced tools support all three requirements.
Multi-Dimension Modelling Capability of Process Modelling Software This is the most
fundamental requirement from any modelling software in terms of simple graphical tool or wizard that help
a user to create process models, define rules or functions and define roles—workgroups and organisation. It
also helps in modelling process hierarchies, KPIs/metrics, etc. Users can define inputs/outputs in terms of
processes or documents here. Some of the tools have a content repository where process related content can
be stored. These capabilities are supported both by basic and advanced tools. It is important to remember
 Business Process Modelling and Business Modelling 157

the greatest challenge of modelling tools is its simplicity, i.e. it should be simple to create a process model
by end users, it should be simple to navigate and the process maps created by the tool should be easy to
understand. If the tool is not simple enough, there is high chance that it will not be used by end users and
instead will be used only by consultants or IT people. This should not happen in a project as this defeats
the very purpose of modeling.
Simulation Capability of Process Modelling Software Advanced process modelling tools like
ARIS or Websphere Business Modeler provides simulation capability. For a single AS IS process in a
project, the team may come up with three better future process options, i.e. three different TO BE designs.
Now these need to be compared based on a set of criteria and the best TO BE option need to be selected.
For example, you design three TO BE processes for distribution planning and see which one of them can
happen at the lowest time and with the lowest distribution inventory. That process is then finalised as the
final TO BE process. Simulation capability of advanced process modelling tools helps in coming up with
several what-if design scenarios, compare them and help choosing the optimal one. Some of the important
capabilities here are:
Manual and statistical simulation
Visualisation of process simulation when in action, provide trends, variance, etc.
Users can save and manage multiple what-if scenarios of multiple simulations
Results of different simulations can be compared side by side
Multiple processes that depend on same resources can be simulated simultaneously
Help choosing optimal solution
Capability of Providing Pre-built Templates Advanced process modelling tools like ARIS or
Websphere Business Modeler provides Pre-built process models for industry-specific business processes
(say, retail industry-specific business processes), for horizonal business processes (say, supply chain man-
agement-specific business processes), for Industry standard process frameworks (like SCOR, APQP, etc), to
support process methodologies (like Six Sigma, TQM, Lean, etc). These Pre-built templates help in quick
modelling as a good part of the existing template models can be reused.

Process Modelling Software Vendors and Products

Microsoft Visio Visio is the most popular process modelling tool for ERP implementations globally
for three simple reasons–easy of use, low cost and modelling–is mostly done by Microsoft popular symbols
(of decision box, arrow, etc). It also has the ability to publish and share diagrams and provide flexibility to
import/export data into multiple formats. Figure 10.5 is an example of process modelled using visio.
IDS Scheer ARIS Modelling Tool IDS Scheer, founded in 1984 by Prof. (Dr.) August Wilhelm Scheer,
regarded by many as the founder of business process modelling, is a leading business process modelling tool
and used globally by several ERP engagements. The IDS Scheer portfolio of tools is all based on the ARIS
framework (Architecture for Integrated Information Systems). IDS Scheer is the market leader in business
process modelling tools and has more than 7,000 customers in over 70 countries. Figure 10.6 is an example
of how a process is modelled using ARIS.
IBM Websphere® Business Modeler This is an advanced process modelling tool from IBM’s soft-
ware group. This has advanced modelling capability in terms of documenting current and future processes,
running simulations to compare costs, execution time and resource requirements and evaluate alternative
process designs.
158 Enterprise Resource Planning

Fig. 10.5 A Simple Process Model Developed in Visio

Source: Example of Process model developed by IBM, GBS for a large telecom company using VISIO

BUSINESS MODELLING
What is This?
Business modelling is a visual representation of an enterprise’s business as one large system showing differ-
ent sub-systems, the processes they support, and the interconnection between them and showing how data
is flowing between different subsystems.

Why Do You Need It?

Very few ERP projects are greenfield, i.e. the company do not have any system and so, they are going
for ERP. In most cases company was using several legacy systems, each of which was supporting a set of
business processes and through ERP implementation, a number of them get replaced. There will be some
applications which may still remain for example very specialised company-specific processes which ERP
does not support. It’s important to understand the current landscape and visualise how the landscape will
be in future before ERP implementation is started.
A business model visually shows what will be the future application landscape, ERP will take care of
which processes, for which processes legacy applications will remain, how data flow will happen between
ERP’s different modules and legacy applications.
Business modelling can be done with any level of detailing. If done with sufficient details, it can also
show how each of the processes runs through different applications (ERP’s different modules and legacy
 Business Process Modelling and Business Modelling 159

Fig. 10.6 Multi-Year Annual Supply Planning (Example of Process Model Developed using ARIS)
160 Enterprise Resource Planning

applications), i.e. which step of the process is done in which application, what input data it needs and what
output it creates, how this output is fed to the next process, etc. It also shows which individual of the or-
ganisation run the process currently and who is supposed to run it in future.
A business model need to be done keeping company’s business strategy, long-term goal and vision in
mind. For example, if a company wants to sell products over internet or want to track products through their
supply chain using RFID, this need to be a part of business model. Company’s future business model will
visually represent which applications will talk to the online order booking system, which of the applications
need to be web-enabled, how data will flow between these front end applications (i.e. web ordering) and
back end applications (for example, accounting).

INTEGRATED DATA MODELLING

As discussed earlier, ERP is a highly integrated system where all the applications seat on a single database.
An ERP implementation can replace company’s several old legacy applications and legacy databases. Do you
need to do a data modelling during ERP implementation? The answer is no to the extent you use standard
ERP. For example, if you are doing a goods receipt, it automatically updates stock, credits vendor’s account,
updates inventory valuation and ERP’s integrated database automatically takes care of that.
However, if you do any development, i.e. ERP’s standard processes do not meet your requirement and
you need to do separate programming to meet a particular customer’s specific business process requirement,
then data model need to be developed for that part of the customer specific process. For example, if you
want to have a specific logic for customer credit check and that need some development in the ERP system,
then it is important to understand the data model for ERP’s corresponding standard function (i.e. Standard
credit check in ERP) which tables its updates, how the data flow happens, what are the inputs and outputs,
etc. Understanding this is important so that you know what tables the development effect, which related
integration points get affected, etc.
ERP data models can be very complex and any change or addition here need to be done with lots of
caution as entry in one table can affect several connected tables and sometime it’s difficult to estimate the
implication immediately.

Summary
In this chapter, we discussed the concept of business process modelling and business modelling which are impor-
tant steps during business blueprinting stage of the project.
Business process modelling is a visual representation of process, its activities and steps. It can also have
details like which organisational element does it, resources required to do the process, time and cost required,
etc.
While the AS IS processes need to be modelled at high level, TO BE processes need to be modelled with
sufficient details.
Business process hierarchy is a logical group of business processes into scenarios, processes, activities and
steps.
Standards are evolving both for business process definition and business process modelling. While APQC,
SCOR, VICS or ECR are some of the popular standards for business process definition, standards like EPC
and BPMN are common standards for business process modelling.
 Business Process Modelling and Business Modelling 161

Process modelling maturity talks about in which sequence you should add more objects and complexity in
the process model. There are five levels starting with basic process flows, followed by organisation elements,
resources and controls, infrastructure and data, and finally time and cost.
Softwares are popular for process modelling. While Visio is a basic level modelling software, ARIS and
Websphere Business Modeler are advanced process modelling tools. Advanced software comes with simula-
tion capability and pre-built templates.
A business model shows high-level process flows, applications and data flow for a company. A TO BE
business model needs to be developed, keeping the company’s strategy and long-term plan in mind.

Exercise
I. Objective Type Questions
1. What is business process modelling?
2. What are AS IS and TO BE processes?
3. What is business process hierarchy?
4. What is APQC process classification work?
5. What is SCOR?
6. What are meant by industry process standards?
7. What are different types of collaboration standards?
8. What are the three different business process modelling standards? What are they?
9. What are the five dimensions of process models? What are they?
10. What is business modelling?
11. What is integrated data modelling?

II. Descriptive Type Questions

1. Why is business process modelling important in an ERP project?
2. Give some rules of process modelling.
3. What is AS IS and TO BE modelling? Define their purposes.
4. Explain the business process hierarchy. How does business process hierarchy helps?
5. What are the standards of business process definition? Explain different types of process definition stan-
dards?
6. What are the different types of business process modelling standards?
7. What is multi-dimensional process modelling? What are the different dimensions of process models and
what are they?
8. What is process modelling software? What are the capabilities of such kind of software? What is meant by
simulation capability of process modelling software?
9. Who are the leading process modelling software vendors?
10. What is business modelling? Why it is needed?
11. Explain integrated data modelling

III. Fill in the Blanks

1. APQC stands for __________ ___________ ____________ _________.
2. SCOR stands for __________ ___________ ____________ _________.
3. VICS stands for __________ ___________ ____________ _________.
162 Enterprise Resource Planning

4. CPFR stands for __________ ___________ ____________ _________.

5. VMI stands for __________ ___________ ____________.
6. ECR stands for __________ ___________ ____________.
7. EPC stands for __________ ___________ ____________ .
8. UML stands for __________ ___________ ____________.
9. BPMN stands for __________ ___________ ____________ _________.
10. ARIS is leading _________ ____________ software.
 11
Gaps Identification
and Strategies to Chapter
Bridge the Gap

Learning Objectives
In this chapter we will discuss the following concepts:
Reasons for gaps and five types of gaps
Functional gaps
Interface gaps
Gaps in user experience
Report gaps
Conversion gaps
Gap document and gap management strategy
Gap development options
Development specifications – Functional and Technical

INTRODUCTION
In any ERP project there will be always some gaps between the list of business requirements and what is
offered in a standard ERP solution. Though package vendors are coming up with hundreds of new function-
alities every year with latest versions, there will be always some specific processes which are not addressed
in their ERP packages and this leads to gaps. While the effort need to be made during package selection to
identify a package which has least possible gaps, it is impossible to find a package which is 100% fit, i.e.
there is no gap. On the whole, if the package meets 80% of business requirements with what a standard
ERP solution provides, it is considered as a good fit.

REASONS FOR GAPS AND FIVE TYPES OF GAPS

One of the important objectives of business blueprinting is to identify these gaps process-wise and to have
a plan in place to fill these gaps. Gaps can be for various reasons and on that basis, the gaps are grouped
here in five categories which are discussed below:
164 Enterprise Resource Planning

Functionality Gap
A. ERP Supports the Process, but the Company Does it in a Different Way for No
Reason If a company has different way of running a business process (for example, procurement process)
than what standard ERP suggests, then a gap is found. Most often companies like to automate their current
way of doing and that may need developments in ERP. These processes need to be investigated in detail and
if there is no specific benefit in doing it in a way which is different from ERP, then these processes need
to be changed to ERP way of doing. Sometimes this needs involvement of senior stakeholders from the
company side to explain business users the benefits of following ERP best practices. As it involves changing
a well-established process in the company, change management is critical here.
B. ERP Supports the Process, but the Company Does it in a Different Way for a
Particular Reason These are the processes where company wants to do a part of the process differently
from standard SAP for a specific business reason. A good example of this is shown as follows.

ITC, the large Indian consumer goods company follows the practice of “Pay and Pick,” i.e. they
send materials to its distributors after receiving full payment. They had implemented SAP supply
chain solution for optimum replenishment quantity calculation. SAP solution calculates optimum
replenishment quantity based on distributor’s forecast, safety stock requirement, lead time, etc
and not consider whether distributor had made the payment or not in the calculation. So, this
part needed a development. From standard SAP, the company gets ideal replenishment quantity,
which is further optimised based on money availability (this part was done through development)
and finally replenishment quantities are calculated.

In this category, some gaps are always expected in an ERP project and typically can be met by configura-
tions or developing “Enhancements”.
C. ERP Does Not Support the Process In most cases, these are industry-specific or company-
specific processes. The difference with earlier one is instead of part of the process, the full process itself is
not supported. Few examples of this are shown below:

Nestle, the world’s leading food company has a process called “Direct store delivery” where the
products are delivered directly from the factory to the store. When Nestle went for ERP (in this
case it was SAP), the process at that point was not supported by SAP and this whole module had to
be developed. Later on SAP made it a part of their standard consumer goods industry solution.
Medtronic, the world’s leading medical electronics company gives the entire medical equipment
solution to a hospital on loan basis. When Medtronic went for ERP (in this case also it was SAP),
this entire module called “Loner” was developed by Medtronic’s implementation partner IBM.
This later became part of SAP’s standard solution.
Global Green Company (GGCL), based at Bangalore, uses a specific decision support system
for their agri forecasting, a process not supported by any of the ERPs.
 Gaps Identification and Strategies to Bridge the Gap 165

Developments of these categories are complex and may need huge cost and effort. ERP solutions are
increasingly trying to bridge these gaps with better understanding of industry-specific requirements and new
industry solutions. However, a good amount of gaps are always expected in this category and typically can
be met by configurations or developing “Enhancements” of complex nature.
D. ERP Alone will not Support the Process and Needs Additional Bolt on These are typi-
cally defined as scope creep. For example, any ERP solution lacks optimisation capability (for which there is
supply chain planning applications). If some requirements need planning, looking at actual capacity available
at shop floor or based on constraints, then the ERP solution will not be in a position to do that. In the same
way, if someone wants to manage the entire product development process in ERP, there is high chance of
having areas where ERP does not support (these are supported by special category of applications called
Product Lifecycle Management or PLM). It is important to identify such areas very early in the project,
preferably during project scoping, as this may call bringing additional applications under implementation
scope. With only ERP in scope, a good part of these will remain as gaps only and the company needs to
leave with those gaps.
E. ERP can Support the Processes but Business Requirements are like Wish List In most
cases these business requirements are motherhood statements, wish list or very generic ones like “ERP should
provide end to end visibility”. It is important to first define the scope of such requirements very clearly and
limit it to something which is manageable and achievable during the project time-frame. Sometimes these
requirements are done in phases, i.e. first let us establish a visibility and material tracking system within the
factory, next try to extend this to distribution centers and so on. Business user’s expectation management
is critical here as sometimes trying to achieve this may need a lot of investment in terms of time and cost
with very little return. A good part of these gaps may remain as gaps only and the company needs to leave
with those gaps.

Interface Gaps
There may be a need of an ERP solution to be integrated with several other applications in the company’s
landscape.
Some of these may be other leading enterprise applications like CRM from Siebel, e-Procurement
application from Ariba or Supply chain planning application from i2 Technologies.
Some of them may be homegrown applications which were developed over the years in the company,
do specific functionality and which is not possible to be replaced by ERP.
In some cases ERP applications has to be integrated with devices in the factory shop floor (like PLC
or SCADA systems), devices in testing lab (like LIMS or laboratory management system), devices in
retail store (like Store Point of sale - POS system) and other devices (like weigh bridge).
While for applications in the first category most of the interfaces (like adapters) may be already available
if you are implementing any of the leading ERPs. For example i2, Ariba or Siebel have standard interfaces
already built for SAP and Oracle ERP. However, if you are not using any of those leading ERPs, these
interfaces may have to be built.
For applications in the second category, mostly interfaces need to be built ground up and need to figure
in the gap document.
For applications in the third category, leading PLC, POS or LIMS vendor today trying to make their ap-
plication compliant with leading ERPs like SAP and Oracle. However, as there are thousands of vendors in
the market offering such applications depending on the device the company already have in place, interfaces
need to be built or something may be available. An area where some gaps are always expected in an ERP
project and known as “Interface Gaps”.
166 Enterprise Resource Planning

Gaps in User Experience

These gaps arise for reasons like:
A factory shop floor ERP user does not want to get into three different ERP screens for creating a
production order. He wants in one screen all the five entries that he needs to make for creating a pro-
duction order. This is a diversion from standard ERP screen and specific screen need to be developed
for him.
The person raising purchase order wants to enter few more fields (say vendor’s credit rating by a third
party agency) while creating the order in ERP system and ERP purchase order screen does not have
a provision for this. In this case, the screen needs to be modified to suit the user.
A total new module needs to be developed in ERP (the Medtronic or Nestle example cited earlier) and
this obviously need corresponding screens to be developed.
These type of gaps are very common in any ERP project and typically called as “Forms Gaps”.

Report Gaps
These gaps arises when standard reports provided by ERP solutions do not meet business requirements.
Gaps can be either in the form of new reports to be developed altogether or existing reports to be modified
(may be with few changes in rows and columns) to suit user’s requirement.
For all these changes in earlier days separate programming were required to be done in ERP solution.
Most of the ERP vendors these days have come up with business intelligence solution as a bolt on to the
standard ERP and report requirements are taken care by this. Business intelligence solutions (discussed in
the later chapter) provide lots of flexible reporting options and that reduces development needs in the core
ERP solution.
These is a common gap area in any ERP project and typically called as “Report Gaps”.

Conversion Gaps
ERP systems may need data from other applications (some of them may be home-grown legacy applications)
for successful functioning. For example, if a company uses a separate system for its R&D (Research and
Development) and product development functions, few data elements from this need to move to ERP solu-
tion for product costing. There can be cases where data coming from a legacy application can not be taken
straight away into an ERP application as ERP systems need data in a particular format. Say, the product
development system has material codes in five digits and ERP system needs in eight digits or the product
development system does not have information in which plant the product is produced and this is a primary
key for ERP system, then these data elements need to be converted. These are called conversion gaps and
conversion programmes need to be written for this. These conversion programmes become very important
in data migration stage. Mostly, all ERP projects have conversion gaps.

GAP DOCUMENT AND GAP MANAGEMENT STRATEGY

Once the types of gaps are understood, it is important to have a comprehensive gap document and gap
management strategy in place as discussed below:

Prepare a Comprehensive Gap Document

This should list all the gaps identified in the project and proposed solution to address those gaps. A typical
gap documents can run into hundreds of lines so it is important to prioritise those gaps – which one need
 Gaps Identification and Strategies to Bridge the Gap 167

to be met immediately, which one next and so on. There may be gaps (few may have functionalities) which
can be even addressed after the project goes live. A typical gap document can look like this:
Gap Document
Gap Description Proposed strategy to address the gap Priority

Proposed strategies to address the gaps are shown in Figure 11.1 can be any of these:
1. Need another bolt on solution along with ERP
2. Need report developments (R)
3. Need interface developments (I)
4. Need conversion developments (C)
5. Need enhancement developments (E)
6. Need form developments (F)
7. Need process changes to suit ERP
8. Gap will remain – expectation need to be set accordingly
Item numbers 2-6 are also called RICEF objects.

Fig. 11.1 Strategies to Manage Gaps

For RICEF objects, prepare a complexity matrix (high, medium and low) to estimate the time needed to
do these developments. This is important as the current trend is to outsource such developments in a low-cost
country or to another consulting company who are cheaper and have expertise in such developments. The
core implementation team only does the final round of testing once these developments are completed.
Building the gap document and complexity matrix are important business blueprint deliverables.
168 Enterprise Resource Planning

GAP DEVELOPMENT OPTIONS

For RICEF objects, the system needs to be modified to meet the gaps. There are four different ways in which
the ERP system can be adapted to meet the requirements:
Customer Development: The ERP System contains a customer namespace in which a particular
company’s own (in this case the company implementing the ERP solution) repository objects can be
created.
Enhancements: This allows the customer to enhance ERP repository objects without using modifica-
tions.
Customising: This is where the system parameters are set. Customising is a mandatory part of setting
up the ERP System.
Modification: Modifications are changes to ERP repository objects. When the system is upgraded,
all the versions of modified objects must be compared with the new ERP version and reconciled.
As Figure 11.2 explains while customising, developments and enhancements are allowed in the ERP system
to meet specific requirements of a customer, modifications (i.e. changes in the existing code of ERP) should
not be done as ERP is a highly integrated application and any code change at one place may have implication
at lot of other places. Moreover, any modification makes it difficult for upgrading the application.

Fig. 11.2 Change Levels in an ERP System

DEVELOPMENT SPECIFICATIONS—FUNCTIONAL AND

TECHNICAL
Functional Specification (FS)
These are documents developed by functional consultants along with core team for each development object
 Gaps Identification and Strategies to Bridge the Gap 169

so that technical team clearly understands what needs to be developed. A typical functional specification
document can have following details:
Identification number for the functional specifications (FS) – Typically, a naming convention is
used so that a particular FS can be quickly identified.
Date of the FS
Which Technical specification (TS) it refers to—TS is described later in this chapter. Ideally each
functional specification should refer to one technical specification.
Who had requested for this FS
Brief description of the FS
Business justification of this development – Justification can be in the form of legal requirements that
can not be fulfilled or lack of information required for the business or losing functionality compared
to the old system. This point also needs the requestor to mention that whether there is any alternative
in the standard system, what that alternative is and why that alternative is not accepted by the business
(i.e. What are the problems with the alternative: complexity, performance problem, etc).
Type of development required: Requestor needs to mention here the type of development i.e. reports,
forms, conversions, interface, application development, etc
Priority of the FS: High, medium, low, etc.—This helps the development team to do planning, look-
ing at the overall project timeline.
Specialised requirements depending on type of FS: For example, for an FS on interface, type of
interface (real time, batch, etc) and direction of interface (inbound, outbound or both) need to be defined.
For a report, details need to be provided on things like table field, check box, radio buttons, table and
field name, etc and the expected report layout need to be a part of FS. For an interface or conversion,
mapping need to be provided between legacy application field and ERP screen field name.
Business needs and requirements: This details the business process gap, the purpose of the FS and
how the gap can be met technically. The detailed process logic, development logics, parameters, etc.
should be part of this FS.
Test case for testing the development: Typically, each FS contains a section of how this develop-
ment can be tested by the tester after completion. The FS requestor can provide the type of testing
need to be done by the developer to ensure that the development is working before giving back to the
requestor. In some cases, FS can also contain some sample test data to facilitate this testing process.
Sign off of the FS: This need to be signed off by the consultant and core team member requesting
for the development and project managers from both client and consulting team side.

Technical Specification
Each functional specification described above need to have a technical specification (TS) attached to it.
Technical specification is prepared by the development team or technical team. This specification is written
in a language which programmers/developers can understand and can develop the particular object. Typical
TS can have details like:
General information
Description and purpose
Assumptions
Technical solution
Selection screen
Detailed logic diagrams and detailed logic notes
Security requirements/Authorisation details
170 Enterprise Resource Planning

Additional information and attachments

Unit test plan

Summary
ERP implementation can have five different types of gaps in the form of: Functionality, Reports, Interfaces,
Conversions and User experience.
A comprehensive gap document and gap management strategy is a major deliverable of business blueprint-
ing.
Managing a gap may also need additional bolts in applications.
There can be different options of developing gaps like: custom developments, enhancements, customising
and modification.
Functional and technical specifications need to be developed for each of the development objects.

Exercise
I. Objective Type Questions
1. What are the five different types of gaps in an ERP project?
2. What are functional gaps?
3. What are interface gaps?
4. What are conversion gaps?
5. What is a gap document?
6. What are the different gap development options?
7. What is a custom development?
8. What is an enhancement?
9. What is customising?
10. What is modification?
11. What is a functional specification document?
12. What is a technical specification document?

II. Descriptive Type Questions

1. What can be the different reasons for functionality gaps?
2. Explain interface gaps. Give some examples of different types of interface gaps.
3. Give some examples of user experience gaps and report gaps.
4. Explain conversion gaps.
5. What are the contents of a typical gap document?
6. Explain different gap development options.
7. What are different contents of the functional specification document?
8. What are the contents of the technical specification document?
 12
Configuring and
Testing of the Solution Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Configuration
What is configuration
Phases in configuration
Configuration document
Who does configuration
Testing
Purpose of testing
Types of testing
What testing is done at different phases of a project
Testing approaches
Testing definitions
Test management steps
Integration testing
Automated testing
Offshore testing

CONFIGURATION
Once the business requirements and company’s expectations from the ERP system are known, the system
needs to be configured as per company’s requirement.

What is Configuration?
ERP systems are not created for one specific customer so it comes up with a variety of options from which
a business needs to choose the one which suits their business requirement. For example:
A goods receipt in an ERP system can be done against a purchase order, against a long-term contract
or goods receipt without any purchase order or contract. You need to choose one of these options
172 Enterprise Resource Planning

through configuration. You can also do configuration in a way that all these three options are possible
depending on the type of material. For example, for procurement of a machine, goods receipt with
purchase order is needed, for procurement of regular production raw materials goods receipt against
a long-term contract is applicable and for emergency purchases of small value consumables, goods
receipt without purchase order can be used.
An ERP system supports production against a particular customer order (make to order production) or
production against a forecast without a confirmed customer order (make to stock production). Based
on the way you configure the system, ERP supports these different production strategies.
There are different ways a system can be configured, sometime it may be ticking one of the options avail-
able, sometime it may be maintaining specific values in a table (For example, for make to stock production
strategy – maintain value as 10, for make to order strategy – maintain value as 20, etc.

Phases in Configuration
ERP configuration is generally divided into two phases as follows:
Baseline Configuration The purpose of the baseline configuration is to configure settings from the
baseline scope for scenarios, processes and functions. The baseline scopes are typically the priority require-
ments of the company which can be implemented quickly. Mostly baseline processes can be configured
without programming or enhancements. For example, as a part of the order entering process, the company
may want to check the credit worthiness of the customer – the basic credit check functionality is a standard
ERP functionality and can be a part of baseline configuration, which you can configure quickly and show
the company core team. At this stage the business users may come up with a specialised credit check rule
requirement, i.e. something which standard ERP does not support and needs to be developed. This will not
be a part of the baseline configuration and may be covered during final configuration.
Final Configuration The final configuration is an iterative process which is done, based on detailed
business requirements. This is an iterative process because if the business requirement has something which
can not be made available by standard ERP, some developments/enhancements need to be done in ERP
functionality and post this, it may call for some additional configurations. Based on the value chains in the
enterprise, and functional requirements, process scope appropriate number of cycles (cycle 1, cycle 2 through
to cycle n) to be configured sequentially. The final configuration is a transformation process that expands the
baseline solution, defined during the business blueprinting and baseline configuration, through cycles (1 to
n) resulting in a solution that satisfies all stated business requirements. The cycles in the final configuration
represent an iterative process that coordinates the configuration with your business processes and business
requirements. This is normally carried out at the same time as the development activities. The result of the
final configuration using cycles is a completely configured system that is based on the business requirements,
the planned user procedures, the documented issues, and the system prepared for the integration test.

Configuration Document
Detailed configuration document is one of the important deliverable of realisation stage. How the system
was configured to meet a particular business process helps even the support team after the implementation,
in case there is a change in business process and it needs reconfiguration. The configuration document needs
to refer to the particular business process for which the configuration was done and these documents are
generally prepared with lot of screen shots from the system for easy understanding. The client team should
go through these documents fully to ensure that all processes are covered, it is easily understandable and
 Configuring and Testing of the Solution 173

sufficient enough for them to handle any changes and reconfigure issues in the future, once consultants
leave the project.
Generally during project preparation phase a template of configuration document is circulated within the
project team so that everyone knows what level of details is expected in this document. Without the template,
a consultant can create the configuration document in his own way.

Who does Configuration?

The obvious answer to this question is “ERP Consultants”. But, this is a wrong assumption. Though gener-
ally consulting team takes lead here in the beginning as they know the software better, the company need to
ensure that their people in the core team and the extended core team understand it and can do that themselves
during the later part of the project. This is important for supporting the ERP system during its application life
cycle, new configurations will keep coming and every time it is not possible to hire a consulting company
for doing those changes. Lot of companies take the approach of taking help of consultants to configure the
system for the first project and for further rollouts configurations are done by the core team with limited
support from consultants. It is obvious that core team member may take more time for this work than con-
sultants, but it is worth investing that time.

TESTING
Once the system is configured and developments are completed, the system needs to be thoroughly tested
before given to the final users. Testing is an important activity during the realisation or build stage of the
project and can take thirty to forty per cent of time during this phase.

Purpose of Testing
Testing is done to ensure that
After configuration, a particular functionality is really working the way it is expected to work and it
meets business requirement
After development, testing is needed to see whether development is done as per the specification
The business scenario as a whole is working. There may be cases where functionalities piece by piece
are working, but the scenario as a whole is not working
The business scenario is working for large volume of data, i.e. customer invoicing module is working
when say 50000 invoices need to be created on the last date of the financial year, i.e. on 31st March.
There may be cases where scenario may be working for a small set of data, but failing for real life
large volume of data
So, purposes of testing can be broadly classified under following categories which may also be seen in
Figure 12.1:
Functionality–Features and capabilities
Performance–Speed, availability, tolerance for load
Usability–Ease with which the software can be employed
Security–Vulnerability to unauthorised usage
Compliance–Conformance to internal standards or external regulations
Depending on these different needs, there are different types of testing performed to ensure smooth
operation of a system.
174 Enterprise Resource Planning

Fig. 12.1 Purpose of Testing

Types of Testing
Testing can be broadly divided in two categories and these are:
Functional testing: This type of testing ensures proper functionality of the software.
Performance testing: Goals of performance testing is the identification of bottlenecks that slows
down the system.
Functional Testing Functional testing can be further subdivided into the following:
Unit testing: This checks that individual functionality is working fine. Example of this can be once you
had completed the configuration of goods receipt process, you want to test that whether this function
is working fine. In case some development is done, those developments are immediately unit tested
after completion before giving a signoff to the development team. This is the lowest level of testing
where the programme or transaction is tested and evaluated for errors. Unit testing is normally the
first test that is completed during the configuration effort, and is focused towards the program’s inner
functions, rather than towards the integration.
Integration testing: This checks whether one full business scenario that cuts across several business
processes and functions (this can be different departments in the company) is working fine. A good
example of this can be order fulfillment process that starts from order taking (sales and distribution
process) to manufacturing of items (production department) to delivery of goods and getting payment
from customers (accounts). An integration test can test configurations across different ERP modules
and also test developments.
User acceptance testing: This is done typically during later part of realisation where the end-users
test the scenarios/processes/transactions they are going to use post go live and ensure that these are
working as per their satisfaction.
Regression testing: This ensures that the system changes (i.e. implementation of new patches, etc.)
do not affect the way the rest of the system works. This is important as during the life cycle of appli-
cation several time patches need to be applied and it needs to be ensured that such patch application
does not affect system performance. Several companies use a set of reusable test cases/scenarios for
such testing.
 Configuring and Testing of the Solution 175

Performance Testing Performance testing can be further subdivided into the following:
Load testing: During a load test, the performance of the system depending on the amount of users
working simultaneously in the system, is tested and monitored. Virtual users can be deployed for this.
For example, if there are ten thousand users for a company implementing ERP, the system need to be
tested in a condition when all the ten thousand users would log in into the system and the results to
be monitored: whether the system is becoming very slow, how is the overall performance, etc.
Stress testing: This tests performance of the system under extreme conditions, i.e. under mass data
or pick volume load. Assume that on 31st March of every year maximum invoicing happens for a
company and so, the invoicing transaction need to be tested under such pick load (say ten thousand
invoices in a day).
Figure 12.2 shows the different types of testing described above.

Fig. 12.2 Different Testing Types

What Testing is Done at Different Phases of a Project

Table 12.1 shows what testing is done in different phases of the project and with what objectives.

Table 12.1 Different Testings at Different Phases of a Project

Project Stage Type of Testing What gets tested Objectives

Realisation Unit testing Particular configurations/developments Developments/configurations are
OK
Integration testing Business scenarios Scenarios are working fine
Final prepara- User acceptance Particular scenario/transaction for an End users can do their functions as
tion testing end user desired
Load test/Stress Volume of transactions System works under full transac-
test tion load
Realisation/ Regression testing Scenarios after applying patches The newly affected patches does not
Support affect system functionality

Testing Approaches
There are mainly two approaches to testing which are described as follows:
176 Enterprise Resource Planning

Manual testing: In manual tests, after the creation of test case descriptions, all test activities are
performed manually by testers, and the test results are recorded manually. No test automation tools
are used. This is used mainly during unit and integration testings.
Automated testing: In this approach, help of automated testing software is taken. After the creation of
test cases, all test activities are performed automatically by automated test software. After the testing,
the result of each test case is recorded automatically by the testing software. This approach reduces
cost as tester’s time is not needed. Automatic testing is, especially useful for regression testing (i.e.
testing needed after applying any new patch) or after an ERP upgrade where all functionalities need
to run as before. For SAP projects ‘eCATT (Extended computer aided test tool) is widely used as an
automated test tool.

Testing Definitions
Below are few terminologies frequently used in testing
Test case: A test case describes the object to be tested.
Example: After completing the configuration of the credit check functionality, a consultant wants to test
that – this can be a test case.
Test catalog: A test catalog is a set of test cases.
Example: Sales and distribution test catalog can have a set of test cases for testing sales order creation test
case, availability check test case and credit check test case.
Test plan: A test plan is a set of test cases, which must be tested, in a particular period for a particular
purpose. Before a test is performed, all test cases relevant for the test are collected into a test plan.
Example: In the month of January, the project team wants to test all the processes under “order fulfillment”
scenario. This makes a test plan and project team will be given a deadline to submit all the test cases by
31st Dec.
Test package: A test package is a person and period-oriented view of a test plan. It contains all tests
which a tester is to perform in a specified period. A test plan is split into smaller test packages to be
performed by a tester. Comprehensive tests can be performed by several testers. The same test case
can be assigned to several test packages.
Example: Order fulfillment scenario of the earlier example can be broken down to five different test pack-
ages given to five testers where each one of them need to perform the test within a predefined period.
Test status: After a test, the tester sets the test case status, e.g. pass or fail. Cause of error or test
failure is also logged.
Test objects: This tells what type of testing it is, i.e. transaction, report or authorisation
Test report: The report contains all details about test plan, test plan attributes, information about
the system used for training, overview of test package, assignment of test package to tester, test case
descriptions, details of test packages, test case status, test case status change history, test notes and
messages.
Figure 12.3 shows different testing terminologies.
The test case description is mainly for testers to help them to understand the errors discovered by testers.
A test description contains:
Description: Description of test activities to be performed
Preparation/Prerequisites: Details of preparation required and prerequisites of the test
Execution: Details of test procedure
Check/Expected result: Details of the expected result of the test, or checks to be performed
Person responsible: Name of the creator of the test case and person supposed to execute the test
 Configuring and Testing of the Solution 177

Fig. 12.3 Testing Terminologies

Duration: Expected duration of the test, i.e. how long the test will take
Notes: Additional notes which can be of help to the tester while performing the test
Test cases should use consistent naming convention. Each project prepares project-specific guidelines for
such naming convention.
Figure 12.4 shows a test scenario. It starts with a test script identification name. In the example the name
is TSU MM – 01 – it denotes a test script for unit testing in Materials management area. The test script
description TSU MM – 01 – Procurement talks about this test script is in Procurement area. The test script
talks about the business process to be tested. The test script also notes down the steps to be tested with
transaction code, input data and expected result. The tester is supposed to do each of these steps, note down
the output and document that whether each of the steps is successful or it had failed. Finally the script needs
to be signed off both by the consultant and core team member responsible for testing.

Test Management Steps

Effective management of testing activities is an important step for any ERP implementation. This needs
to be planned with sufficient details for effective execution. Important steps in test management shown in
Figure 12.5 are described as follows:
Define Test Scope: Important point here is to define test goals, scope and criteria to consider the
test is complete. For example a test for invoicing process can be considered complete only when all
configurations related to the process are tested, all related developments are tested and the process is
working fine under load.
Define Test Cases: Test cases and Test plans are need to be defined. Test cases should be such that
it covers all the representative processes in the organisation. For example for integration testing, the
project team members may go through several iterations before finalizing the final integration test
scenarios.
Define Test Plan: Detailed test plan should include things like: Business processes, Output, Reports,
Interfaces, Conversions, Enhancements, Authorisation, etc.
178 Enterprise Resource Planning

Fig. 12.4 Test Script

Fig. 12.5 Test Management Steps

 Configuring and Testing of the Solution 179

Approve Test Plan: Test plans need to be approved by business process owners and members of the
test team
Getting test system in place: This calls for having testing server and infrastructure in place. Actually
ordering for such hardware need to start much earlier so that infrastructure is in place by the time
testing starts.
Creating test data: Each test scenario need a dataset to test. This data need to be created in the test
system. While creating data for a unit testing for testing a particular transaction is much more simpler
then creating a dataset for integration testing – which need to be planned across several intersecting
processes.
Defining testing responsibilities: This calls for defining who will do the testing, who is responsible
for accepting the test results, etc.
Planned and actual completion dates of testing: Plan and actual completion date of each testing
scenarios need to be tracked.
Managing issue log during testing: Any issues occurring during unit, integration or end user testing
need to be added to the issue log, and closed after the issue is resolved.

Integration Testing
Integration testing is a major milestone for any ERP project. This test includes verification of dependencies
of business processes on the value chain and interfaces, output, enhancements, cross enterprise workflow,
authorisation, etc. In order to do the final integration test, all configurations, relevant interfaces, system en-
hancements and developments should be completed. Figure 12.6 explains the concept of integration testing
which cuts across different organisational boundaries like sales, production, purchasing, accounting, etc.
Generally there are two cycles of integration testing with different purposes:
First Cycle Integration Testing: The purpose of the first cycle of integration testing is to check all
cross functional integration points for high-frequency and impact business processes. The focus of test-
ing is that data crosses from one function (ERP module) to another. Examples of integration points can
be: creation of a delivery note to be passed to materials management module for warehouse processing
or running of materials resource planning (MRP) in materials management module to automatically
generate production orders in production planning.
Second Cycle Integration Testing: The purpose of second cycle of integration testing is to end-to-
end scenario testing. An example of an end-to-end scenario would be taking of a sales order, passing
of the demand to manufacturing, MRP (materials resource planning), manufacturing of the product,
receipt into finished goods, shipping to the customer, invoicing, billing and receipt processing.
As testing is no longer function by function, but is now cross-functional. Therefore, the test teams for
each business process must include members from each enterprise process area being tested.

Automated Testing
Testing is a process which needs lots of manual effort. But, a little bit of automation here can save lot of
time and cost. It is not that all testing processes can be automated. No one will like to automate the first
round of unit or integration testing, but it is possible to automate some other types of testing like regres-
sion testing which need to be done during every patch upgrade of software life cycle where known usage
cases are run and that should yield expected results. Once the test case is prepared, there is no point in
putting effort in this again and again and testing software can automate the process of testing and ensure
that software functions are tested and bugs are fixed before they go into production. As increasingly test-
ing as an activity is broadening its focus from application functionalities towards scalability, performance
180 Enterprise Resource Planning

Fig. 12.6 Integration Test Cutting Across Several Business Functions

under stress, and usability improvements, the scope for automated testing software has boomed and all
large implementations are looking at doing a portion of their testing by using these automated tools. This is
evident from several large scale acquisitions in the past like HP Software and Mercury, IBM and Rational,
Oracle and Empirix, etc.
The automated testing software was first introduced by Amnon Landan and Aryeh Finegold who first
developed the first mercury interactive testing tool in 1991. From finding bugs in software, these tools had
matured today to support different stages of testing like functional tests to verify a process result and ensure
function traceability, load tests to ensure scalability and verify performance based on similar scripts, etc.
Today the leading automated testing software vendors are:
HP (Products: Quality Centre, QuickTest Professionals) – HP has acquired Mercury recently – the
most popular automated testing software
IBM (Products: Rational Manual Tester, Rational Functional Tester, Rational ClearQuest, etc)
Empirix (Product: e-Tester)
Compuware (Products: Quality Manager, QADirector)
Figure 12.7 gives a snapshot of HP/Mercury automated testing tool.

Offshore Testing
As testing is a labour-intensive operation, for ERP implementations in Europe, US and other developing
countries, it is common to offshore this activity in low-cost countries like India. Some of the Indian software
companies like TCS, Wipro, HCL, and Patni, etc have dedicated testing practice and there are companies like
AppLabs, RelQ, Disha etc, whose 100% revenue comes from offshore testing. There are numerous advantages
 Configuring and Testing of the Solution 181

Fig. 12.7 Automated Testing Tool (Mercury)

of using a proven service with professional testers rather than using an ad hoc team. Some of the advantages
of doing testing offshore by a specialised team or a specialised service provider are as follows:
Save on labour costs: The most obvious benefit of doing anything offshore and do not need any
elaboration.
Save on tool costs: Most testing specialised communities/service providers have made investment
and built expertise in specialised testing tools and automated test scripts and thereby decreasing costs.
Economies of scale also permit providers to invest in the tools.
Reducing implementation time: Offshore testing reduces time it takes to perform quality check on
applications, enterprises can increase the size of their testing staff by sending some or all of their
testing offshore. Splitting testing efforts between onshore and offshore locations also enables shops to
take advantage of time zone differences, effectively doubling the number of hours in each test cycle.
Using offshore resources to test new functionality at night, i.e. developed during the day decrease
implementation time.
Testing expertise: Offshore testing providers and specialised teams have spent years learning how to
optimise testing processes and this can benefit the implementation team.
182 Enterprise Resource Planning

Summary
Configurations are used for making the ERP package suitable for particular business’s requirement
Configurations can be divided in two stages: Baseline and Final
Configuration document is an important deliverable for ERP project realisation phase
Testing is needed to check whether a particular functionality or a particular development is working as de-
sired
There can be different types of testing like: Unit testing, Integration testing, User acceptance testing, Regres-
sion testing, Load testing, Stress testing, etc
Different testings are done at different phases of a project
Testing approaches can be either manual or automated
Test management has a set of pre-defined steps
Automated testing is a popular approach for regression testing
Increasingly offshore testing is gaining acceptance with scope of substantial cost reduction.

Exercise
I. Objective Type Questions
1. What is configuration?
2. What are the two phases of configuration?
3. What is baseline configuration? What is final configuration?
4. What does a typical configuration document contain?
5. Who does configuration?
6. What is the purpose of functionality testing?
7. What is the purpose of performance testing?
8. What is the purpose of usability testing?
9. What is the purpose of security testing?
10. What is functional testing? What are the different types of functional testing?
11. What is performance testing? What are the different types of performance testing?
12. What is unit testing?
13. What is integration testing?
14. What is user acceptance testing?
15. What is regression testing?
16. What is load testing?
17. What is stress testing?
18. What are the two different testing approaches? What are they?
19. What is automated testing?
20. What is test case?
21. What is test catalog?
22. What is test package?
23. What is test plan?
24. What is integration testing?
25. What are the leading automated testing tool software vendors?
 Configuring and Testing of the Solution 183

II. Descriptive Type Questions

1. Give some examples where an ERP system needs to be configured?
2. Explain different phases of configuration.
3. What are the different purposes of testing? Explain each of them and why are they done?
4. What are the different types of testing? Explain different types of testing in detail.
5. Explain different types of functional testing? What is the purpose of each?
6. Explain different types of performance testing? What is the purpose of each?
7. In what phase of project what testing is done and why?
8. What are the different types of testing approaches? Which type of testing approach is suitable in what case?
What is automated testing and why it is done?
9. Define test case, test catalog, test package, test plan, test status and test report.
10. Explain different testing terminologies.
11. What are the typical steps of test management?
12. What is integration testing? What is its purpose? What are the different cycles of integration testing and
what are the purposes of them?
13. What is automated testing? What is its purpose?
14. What are the benefits of doing testing from offshore?
15. What are the contents of a typical test case?

III. Fill in the Blanks

1. Two phases of ERP configuration are _______________ and _____________,
2. Functionality testing tests _______________ and _____________.
3. Broad two categories of testing are ______________ and _______________.
4. Four types of functional testing are ___________, ___________, _____________ and _______________.
5. Two types of integration testing are ________ and _________.
6. Two different testing approaches are ________ and _________.
7. A test catalog is a set of _______ ________.
8. A test package is a ___________ or ________ _________ view of a test plan.

IV. State whether the Following Statements are True or False

1. Unit testing is done at final preparation stage.
2. Load testing is done during final preparation.
3. Integration testing is a part of final preparation.
4. Unit testing checks the full business scenario is running fine.
5. Regression testing tests that individual scenario is working fine.
6. User acceptance testing is part of performance testing.
7. Stress testing is a type of functional testing.
8. Test catalog is a set of test cases.
9. Automatic testing is not useful for regression testing.
10. Transaction is a type of test object.
 13
Managing ERP Security
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Types of ERP Security Issues
System Access Security–Authorisations
Data security and technology for managing data security

INTRODUCTION
Security and risk management is increasingly becoming a global issue and during implementation of an
enterprise wide system like ERP, this can not be neglected. In most ERP projects, activities in risk manage-
ment is mainly limited to project risk. However, managing risk is a much larger issue and need to be seen
as a whole to ensure that the ERP system is implemented and operated successfully during its lifecycle.

TYPES OF ERP SECURITY ISSUES

Network Security: Today’s ERP systems are exposed to a lot of people outside an organisation’s own
boundary. The need for higher collaboration with suppliers and customers for today’s supply chain
efficiency also imparts higher risk for corporate networks. Selected customer and suppliers with whom
you need collaboration should be allowed within company’s firewall and should be able to see only
relevant data. The network should be also secured from hackers who come up everyday with innovative
technologies to break the code and hack corporate networks. Typically, network risk management is
taken care of by the networking team and not by the ERP project team directly. However, there need
to be a mitigation strategy in place for this risk. Detailed discussion on this is outside the scope of
this book.
System Access Security—Role and Authorisation: This is to ensure that right users have access to
right transactions in the ERP system. These authorisations need to be created and tested during ERP
implementation. This is becoming important with global regulations like SOX compliance which is
about restricting conflicting authorisations in an organisation. An example of conflicting authorisation
 Managing ERP Security 185

is: “The person creating a purchase order should not be allowed to release payment to the vendor”.
This is discussed in this chapter.
Data security: Doing a set of activities of ERP implementation from low cost countries is the recent
trend, especially for large global implementations. While it drives down the cost, it also increases the
data risk as your company’s sensitive data can now be visible to a set of people who do configuration,
testing, etc in your system. Since they are in offshore locations, you may not be in a position to moni-
tor them on regular basis like your other core team members. Though companies typically enter into
NDAs (Non-disclosure agreements) with their consulting partner for ensuring that the data does not
go outside the team, in most cases this is not a full-proof system. Security of data is more important
for certain industries like credit card companies, banks, defence, etc. Technologies like data masking
can help here. This is also discussed in this chapter.

SYSTEM ACCESS SECURITY—AUTHORISATIONS

Designing proper roles and authorisations in ERP system ensures that every user using the system have right
authorisations – nothing more, nothing less. Task of defining roles and authorisations starts from business
blueprinting phase, i.e. when TO BE processes are designed. Roles define who will run those processes in
future and authorisations define what sort of transactions access they need to run those processes. There can
be different authorisation strategies supported by ERPs like:
Activity-based authorisation
Role-based authorisation

Activity-Based Authorisations
In this case authorisation of a user to ERP system is determined by the list of activities that the user does
in the system. Steps for defining such authorisation are as follows:
Identify the activities that a particular process may involve
Prepare a ‘set’ of transaction codes for each identified activity
Prepare an authorisation role for the each set of transactions
Assign the user the specific authorisation role
The advantage of this strategy is flexibility in assigning various combinations of transaction sets. Thus,
each authorisation scenario can be addressed.
Disadvantage of this strategy is transaction codes set should be carefully prepared, otherwise it may end
up creating authorisation roles for each transaction and/or for a combination of the same.
Example of Activity-Based Authorisation (Leave Approval Process)
1. Identify the activities that a particular process may involve. Say, leave approval process involve two
steps:
(a) View leave balances
(b) Execute and approve workflow for leave request
2. Prepare ‘set’ of transaction codes for each identified activity:
(a) View leave balances – Say, transaction code is XX
(b) Execute and approve workflow – Say transaction code is YY
3. Prepare an authorisation role for the each set of transactions.
An authorisation role: Z: HR_APPROVE_LEAVES will consist of transactions XX and YY. This will
be assigned to the user who is supposed to approve leave.
186 Enterprise Resource Planning

Role Based Authorisation

Here instead of looking at every individual what activity they do, the authorisations are created for a “Role”.
For example, a “Procurement Role” will have access to a set of transactions like: To create purchase order, to
change purchase order, to process purchase requisitions, etc. Any person performing procurement function,
automatically gets assigned to procurement role. Steps for creating role-based authorisation are:
Identify the transaction codes that each role in the organisation require
Prepare an authorisation role for the list of transactions identified
Assign the user the specific authorisation role
Advantage of this strategy is: Authorisation roles become specific to an identified role in a function and,
therefore, any future modification in authorisation requirements can be managed easily. There will be few
authorisation profiles in the organisation as it depends on number of roles and not on employees.
Disadvantage of this strategy is: This method requires careful standardisation of roles, keeping in mind
various parameters. Someone need to really think through that one role – what all activities he will be per-
forming in new ERP system – and that may not be direct replica of what he is doing today. As ERP systems
have much advanced features and the kind of things he does in future may change a lot from what he is
doing today (say, he will spend a lot of time in analysis instead of just routine transactions).
Example of Role-Based Authorisation (Role: HR Manager—Bangalore)
1. Identify the roles a particular function may involve.
HR function may require roles like – HR manager, IR officer, etc.
2. Identify the parameters based on which roles may require further bifurcation and thus, standardise
each possible role in a function.
HR manager’s role in Bangalore factory may be different from HR manager’s role in Mumbai factory.
Here location becomes a parameter for further bifurcation of HR manager’s role. Therefore, we end
up with two roles – HR manager (Bangalore) and HR manager (Mumbai).
3. Identify the transaction codes that such role will require.
HR manager, Bangalore may require transaction codes – XX, YY, ZZ – to do administration work.
Further he may require transaction codes – AA, BB – to view reports, execute workflows. All these
transaction codes need to be identified against this role.
4. Prepare an authorisation role for the list of transactions identified.
Say, a role: Z: HR_PA_HRM_BLR will consist of all these transactions XX, YY, ZZ, AA and BB.
Now this role: Z can be assigned to any user performing HR manager role in Bangalore.

Different Types of Authorisations

Based on a particular person’s role, there can be different types of authorisations for a particular transaction
of ERP system: say some user will have only “Create” authorisations, some will have “Change” authorisa-
tions, some will have only “Display” authorisations and some will be able to “All”
For example, while materials manager and goods issue clerk both have access to material master data, one
of them can Create – Change – Delete and Display while others may have authorisation only to Display.

Role Transaction Code Types of authorisation

Material Manager Material master Create
Change
Delete
Display
Goods issue clerk Material master Display
 Managing ERP Security 187

DATA SECURITY AND TECHNOLOGY FOR MANAGING DATA

SECURITY
As discussed earlier, in any ERP implementation, there will be a set of privileged users such as application
developers, testers, administrators and outsourcing vendors who will have access to company’s sensitive/
private data. Sensitive/private data includes: social security numbers, credit card numbers, financial data,
healthcare information, employee salary data or any other type of confidential information. Though the
common practice is to have an NDA (Non-disclosure agreement) between the company and its consulting
partners – this cannot ensure 100% security. Today risks had further increased with offshoring some of the
project activities. Data masking is a technology that is getting popular these days for ensuring higher data
security.

Data Masking
Forrester defines data masking as: “The process of concealing sensitive data in development, test or train-
ing environments so that developers or testers do not get exposed to this data”. Masking scrambles data to
create new data but retains the data’s properties, such as its width, type, and format. Common data masking
algorithms include random, substring, concatenation, date aging, sequential, etc. Data masking can be based
on predefined policies, through an automated or manual process. Data masking offer following benefits:
It meets regulatory compliance requirements such as HIPAA.
It enhances data security for outsourcing application and development.
Data Masking Algorithms Data masking solutions offer multiple algorithms and the most popular
of these ones are:
Shuffling/Reorder: This approach shuffles a few columns, such as account numbers or names or social
security number so that they cease to relate to the original rows. For example, Mr. X moves to another
record, and his name is associated with someone else’s salary, date of birth, account balance, etc. This
approach works well if there are thousands of rows and each record moves to a random row.
Random value: In this approach, a column or row can be masked or replaced with a random value;
for example, the country name can be randomly changed to reflect another value.
Hashing: In this approach, a few characters of the column are hashed with special characters such as
“#” or “*”. For example, the last four digits of a credit card number can be hashed out with pound
signs so that 645-345-2919 is masked to become 645-345-####.
Date aging: In this approach, a DATE field is either increased or decreased based on predefined poli-
cies. An example would be moving the date of birth back by 2,000 days, which would change the date
“12-Jan-1978” to “16-Mar-1972.”
Value changes in increments or decrements/Numeric alternation: With this approach, a column
is changed either incrementally or decrementally based on predefined policies, say account numbers
starting with 1 is multiplied by 101, account numbers starting with 2 are multiplied by 202, etc. A
numeric value can be increased based on a percentage. For example, a salary value could be increased
by 10%. The logic should be such that it is not easy to decode the pattern.
Custom: This approach allows for custom creation of algorithms based on requirements.
Substitution with a random value: This technique substitutes data with some random value, making
the data look real. For example, the employee name “Derek Brown” can be substituted with the name
“John Brown.”
188 Enterprise Resource Planning

Data Masking Tools IBM Optim (IBM acquired through its acquisition of Princeton Softech) is a
popular data masking tool. Optim offers a comprehensive suite of data masking, data migration, and data
archiving solution that supports files, DBMSes such as Oracle, DB2, SQL Server, Informix, and Sybase,
and applications such as SAP, Oracle E-Business Suite, PeopleSoft, JD Edwards, Siebel, etc.

Summary
Security of ERP systems is of prime importance and ERP implementation has various types of security issues in
terms of Network security, Access security and Data security.
For better access security roles and authorisations need to be defined in ERP system. Authorisation can be
role-based or activity-based.
In activity-based authorisation, based on the number of transactions a person use, an authorisation profile is
created for the individual including all those transactions and assigned to him.
In role-based authorisation, an organisation creates a set of roles based on organisation’s functions and anyone
performing that function will get that role and access to a set of transactions associated with the role. Role
can be: sales manager, sales supervisor, production manager, material manager, store clerk, etc.
Data security is another important issue for the company going for ERP implementation and technology like
data masking can help here.

Exercise
I. Objective Type Questions
1. What are the different types of ERP Security issues?
2. What are the two types of ERP authorisation strategies?
3. What is activity based authorisation?
4. What is role based authorisation?
5. What is meant by data security?
6. What is data masking?

II. Descriptive Type Questions

1. Explain different types of ERP security issues.
2. What is activity-based authorisation? Explain this with examples.
3. What is role-based authorisation? Explain this with examples.
4. What are the advantages and disadvantages of two different authorisation strategies? Which is better in
what circumstances?
5. What are the different data masking rules and algorithms?

III. Fill in the Blanks

1. Hashing is a __________ ___________ algorithm.
2. Two types of authorisation strategies are _________ based authorisation and _________ based authorisa-
tion.
3. SOX compliance talks about restricting __________ authorisations in an organisation.
 Managing ERP Security 189

4. NDA stands for __________ _____________ ______________.

5. IBM _______ is a leading data masking tool.

IV. State Whether the Following Statements are True or False

1. Role based looks at what activity every individual does.
2. Random value is a data masking algorithm.
3. Network security ensures that right user have access to right transaction in ERP system.
 14
Data Migration
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Classification of data to be migrated
Process to migrate the data
Data Cleansing and ETL Tools

MIGRATION OF DATA
Transferring data from legacy applications or from old systems to new ERP application is an important step
for ERP implementation. This is something done as part of final preparation stage of a project or during
late realisation. However, the planning for this need to start much earlier. Success of an ERP project can
depend a lot on quality of data that is going inside the system and if proper care is not taken in loading the
system with clean data, it can simply become “garbage in and garbage out”. So, its worth spending time
in data cleaning. There can be other complications also during this stage like ERP systems may need data
which is not existing at all and this need to be created by the project team. For example, implementing plan-
ning modules may need data on service level or safety stock requirement of an item – which most of the
organisations may not maintain in their legacy application (this information is in the head of the executives
and may not be stored in any database) and these data need to be created. Similarly, a company looking for
an ERP implementation in a new plant may need to create new master data on machines, cost centers, etc.
Data migration involves several challenges as shown in Figure 14.1 and discussed as follows:
From which source systems data will come?
How much data need to be migrated?
How to clean the data?
Who will verify and ensure that clean data is loaded into the system?
Which electronic migration method or ETL tool to be used?
What data can be transferred earlier and what need to be transferred just before going live?
 Data Migration 191

Fig. 14.1 Data Migration Challenges

Classification of Data to be Migrated

There are two sets of data which need to be migrated from legacy application to the new ERP systems and
these are Master Data and Transaction Data.
Master data is typically the data set which does not change everyday like vendor, customer, and materials,
etc. It is important that only relevant master data is getting transferred, i.e. there is no point in transferring
the customers or suppliers from your old system with whom you no longer do business. In the similar man-
ner, there is no point in transferring obsolete materials. These are part of data cleaning activity and need to
be taken seriously so that the ERP system is not getting loaded with junk data.
Transaction data are the open items like stock, open purchase orders, contracts, sales orders, etc that
need to be transferred to the new ERP system. Again, the guiding principle here is to transfer only relevant
data, i.e. there is no point in transferring the purchase orders which already got closed three months back,
but those purchase orders against which vendors will give materials in future need to be transferred to new
system, otherwise goods can not be received in the new system against those open purchase orders.
Sometimes, it becomes important to do reporting, based on past data, i.e. you want to see how the vendor
had performed in the last five years. In those cases these old data from legacy applications can be transferred
to some data warehousing application and from there reporting can be done. Old data from legacy applica-
tions should not be transferred to ERP application just for reporting purpose as too much data makes system
performance slow.
192 Enterprise Resource Planning

Examples of some master data objects which are taken up as part of data migration:
Chart of accounts
Cost centers
Profit centers
Asset master
Tax masters
Material master—Finished, semi-finished, spares
Price Masters/condition master
Vendor master
Customer master
Employee master
Machines/equipment masters
Master inspection criteria for quality management
Examples of some transaction data objects/open items which can be taken up as part of data migration:
Open internal orders
Excise balances
Stock balances – Finished goods, raw material, spares
Material in transit
Open service contracts and orders
Open indents
Open RFQs (request for quotations)
Open contracts and purchase orders
Open sales contracts and orders
Loans and advances, contracts
For transaction objects, it is common to set up a cut-off date and the transaction data as on that date will
be migrated to the new system.

Process to Migrate Data

Data can be migrated to the new ERP application system either manually or electronically. Both the process
of data migration are discussed as follows:
Manual Data Migration Figure 14.2 shows basic process for manual data migration. For very small
implementation, data migration can be done manually as well where a set of people check the source system
and then manually punch data in new ERP application. This is time consuming, costly and having high
chance of error. For relatively large data size, manual migration is an impossible task. Nowadays, in nine
out of ten projects, this method is not followed.
Electronic Data Migration This process is most popular these days as volume of data is not a con-
strain here. This is faster, cheaper and having lower chances of error. It is important to remember that even
in case of electronic migration, after the migration is complete; data need to be verified in the new system
manually. Manual verification is the last step even in case of electronic transfer. This is typically a seven-
step process as shown in Figure 14.3. The steps are as follows:
Analysis
Design
Cleansing
Extraction
 Data Migration 193

Fig. 14.2 Manual Data Migration–Basic Process

Fig. 14.3 Electronic Data Migration–Basic Process

Transform
Load
Verification
194 Enterprise Resource Planning

Analysis Before undertaking data migrations, in this phase do an analysis of how much data need to be
moved to ERP, from which legacy systems these data will come and mapping those legacy application data
structures with ERP system. This process is also called data profiling and mapping. Data profiling involves
studying the source data thoroughly to understand its content, structure, quality and integrity. Data mapping
is the next step, i.e. which system’s which table/dataset (source system) will be mapped to which target field
in the ERP system. Figure 14.4 is an example of data mapping, i.e. how legacy tables and data elements are
mapped to ERP tables and fields (in this case the example is SAP ERP). The combination of data profiling
and mapping comprises the essential first step in any successful data migration.

Fig. 14.4 Data Mapping Between the Source and the Target System

Design The design relates old data formats to the new system’s formats and requirements. For example,
material code in the old system may be in a particular format which ERP can not accept – in design phase
it is decided what need to be done to supplement/transform this coding structure to something which ERPs
can accept.
Cleansing Data cleansing is a major task and that may involve removing obsolete data, removing duplicate
entries, fixing misspellings (i.e. customer description wrongly recorded in old system), errors, etc. As shown
in Figure 14.5, for effective data cleaning, data validation rules need to be defined (A sample example of
data validation rule can be – the customers for which there was no transaction in last 24 months will be
considered as inactive customers and will not be migrated from the old system). It is important to get an
understanding of data issues in legacy applications from business process owners as they work with this
data day in and day out and can give valuable inputs in the process. Based on these inputs and data valida-
tion rules, data need to be cleaned. For a large project having huge volume of data this activity can take
 Data Migration 195

Fig. 14.5 Process for Data Cleansing

several months. Typically this activity is done by the project core team from business as they understand
their data better.
Extraction This is an activity of extracting data from data sources (legacy system/s) for further data
processing and finally loading to the ERP system. Generally for these kinds of extractions ETL (extraction,
transformation and loading tools) or data download programmes are used.
Transform This stage applies a series of rules or functions to the extracted data from the source to derive
the data to be loaded to the target system in the format needed by destination system. Some data sources
will require very little or even no manipulation of data and for some sources major transformations may be
needed. Examples of such transformations can be:
Source system has material master data in 10 digits and ERP systems need material masters in 13 digits,
i.e. source system data needs to be padded with three digits for being taken to the ERP system.
Translating coded values–the source system stores 1 for male and 2 for female, but the target system
stores M for male and F for female. This needs mapping “Male” to “1” and “M”).
Load In this step, data is loaded into the ERP system. Again to make the process automated, programmes
can be written and sometimes ERP vendors also provide data loading tools. For example, leading ERP vendor
SAP provides tools like LSMW, BDC, etc for data loading.
Another important point is for loading data is that a particular sequence needs to be followed. You can
not send open purchase orders to the new system before sending the vendors on which those purchase orders
are raised. Table 14.1 is an example of such data loading sequence.
196 Enterprise Resource Planning

Table 14.1 Data Loading Sequence – An Example

Data Object Prerequisite

Material master Profit center
Vendor master General ledger accounts
Open purchase order Material master, vendor master
Open purchase requisition Material master
Stock balance Material master, general ledger account
Open vendor invoices General ledger accounts, vendor master
Vendor excise details Vendor master
Excise tax rates Excise chapter Id
Accounts receivable balances General ledger accounts, Customer master

Several things need to be considered while loading data like:

Huge volumes of data to be loaded
Small time window available for loading (usually nights)
Online versus offline loads
Verification After loading into the new system, data need to be verified preferably by some business us-
ers to determine that whether data is accurately translated, is complete, and supports processes in the new
system.

Data Cleansing
Data cleansing is discussed here separately as this is a very important activity and often in ERP projects,
due to high time pressure, this activity is overlooked. There can be various problems with the data, some
of which are as follows:
Same person with different spellings: Bannerjee, Bandopadhay, etc
Multiple ways to denote the same company name: ABC Systems, ABC Pvt. Ltd, ABCPL, etc.
Same city with different names: Mumbai and Bombay, Calcutta and Kolkata
Different account numbers generated by different applications for the same customer
Required and mandatory fields left blank
Product codes entered at store POS system are incorrect. In case of a problem, store clerk had entered
manually some dummy value like 9999999.
Contradicting data
Data Cleansing Techniques The objective of data cleansing is to make data accurate, consistent,
complete and useful. While data can be always cleaned manually, it sometime becomes practically impos-
sible to clean large database manually. Different algorithms can be used for auto cleaning of data. Some of
these tools are as follows:
Standardising: This transforms data into a standard or consistent format using a set of business rules.
For example, all telephone numbers in the database may be standardised to this format: “999-999-
9999”. For this a prefix or suffix may be added to numbers which are not in the same format.
 Data Migration 197

Matching: Matching is a technique to find out and eliminate duplications in a dataset based on
predefined business rules. This may involve searching, for example, similar names and addresses to
determine whether multiple records exist in the same entity.
Consolidating: This involves analysing and identifying relationships between matched records and
consolidating/merging them into one.
Correcting: Corrects individual data components using sophisticated data algorithms and secondary
data sources. For example, correcting a particular address record of a customer by adding pin code
and to change the address information to correct values by using other data sources, such as a country-
specific address database.
Enriching: This means incorporating value-added data from external sources for advanced analysis,
such as using latitude and longitude coordinates to determine how closely customers live to each
other.
Parsing: Parsing locates and identifies individual data elements in the source files and then isolates
these data elements in the target files. Examples include parsing the first, middle, and last name;
street number and street name; and city and state. Thus, it breaks down data into meaningful pieces.
For example, the text string “1234 OAK ST 999-999-9999” could be parsed into an address of “1234
OAK ST” and a telephone number of “999-999-9999.”
Conditioning: The conversion of data types from the source to the target data store (warehouse).
Scoring: Computation of a probability of an event, e.g. that a customer is likely to buy a new
product.
ETL Tools Extraction, Transformation and Loading tools are widely used for data migration. These tools
can help in auto data cleaning based on rules, data extraction from multiple legacy applications and finally
data loading into ERP and can be useful for large ERP projects having huge data to migrate. ETL tools can
take out data from any source systems, i.e. legacy applications, spreadsheets, standalone database, etc. Some
of the leading vendors and products in this space are:
Business Objects (Product: Data Integrator)
IBM (Product: Information Server)
Informatica (Product: Power Centre)
Oracle (Product: Oracle Warehouse Builder)
Microsoft (Product: SQL Server Integration Services)
How ETL Tools Helps in Data Cleaning ETL tools have advanced capabilities in data cleaning
like:
Capabilities to cleanse and standardise data: Capabilities like data standardisation, cleansing, and
formatting helps in consistency in data capture and reporting.
Capabilities of data matching: Matching rule engines and algorithms helps in determining whether
different versions of similar data. For example, a customer record, location, or product should be
considered the same entity.
Capabilities of data merging and consolidation: Having determined that there is a positive match, the
next task is to delete the duplicate versions of the data and keep the one which is the best version.
Capabilities to verify postal address: Data cleansing supports postal address verification and enrich-
ment (i.e. ensuring correct mailing address; street address, city, state, postal code, country, etc) by
partnering with national postal services around the globe. Some vendors specialise in specific countries
or regions.
Capabilities to verify phone/email active use: Vendors provide verification capabilities of customer
phone numbers and email addresses.
198 Enterprise Resource Planning

Capabilities of enriching data with third-party providers: This may mean adding further things in
data as described earlier, for example, enriching customer record data with customer credit score data
from a third party.
Capabilities of data profiling: This enable data analysts to review source data to gain insights into
where data quality issues might exist and help define what data quality policies, rules, and systems
need to be implemented and monitor and measure the effectiveness of these rules going forward.

Summary
Data migration has several challenges in an ERP project.
Typically, a set of master and transaction data in the form of relevant open items is migrated to the new ERP
system.
Electronic data migration is a seven-step process involving: analysis, design, cleansing, extraction, transform,
load and verification.
Data loading need to follow a predefined sequence.
Data cleaning is an important step and the process can be automated by applying a set of rules.
ETL (Extraction, Transformation and Loading) tool helps in data migration and cleaning by supporting variety
of rules.

Exercise
I. Objective Type Questions
1. What is data migration?
2. What is master data and what is defined as transaction data?
3. Give some examples of master data objects that are typically migrated in an ERP project?
4. Give some examples of transaction data objects that are typically migrated in an ERP project?
5. What ETL stands for? What an ETL tool does?
6. What are the two data migration strategies?
7. What is meant by manual data migration?
8. What is electronic data migration?
9. Name the seven steps of data migration process.
10. What is data profiling/data mapping?
11. What data transformation does?
12. What is meant by data enriching?
13. What is data parsing?
14. Explain data scoring?
15. Name some ETL tools.

II. Descriptive Type Questions

1. What is data migration? What are the typical challenges of data migration?
2. What type of master and transaction data need to be migrated in an ERP project?
3. What is meant by manual and electronic data migration? What is useful when and why?
 Data Migration 199

4. Explain seven-steps of data migration process in detail.

5. What is data cleansing? What are the different data cleansing techniques?
6. What is ETL technology? How do ETL tools help in data cleansing? Name some leading ETL tools.

III. Fill in the Blanks

1. ETL stands for _______________, ____________ and _____________,
2. Informatica is a _________ tool.
3. Enriching is a __________ ___________ technique.
4. Seven steps of data migration are __________, ____________, ___________, _______________, ______
______ and _________________.
5. Data can be migrated both ___________ and _______________.
6. IBM Information Server is a leading ____________ tool.
7. Data extraction is done from _______________ system.
8. Data loading is done to ______________ system.

IV State Whether the Following Statements are True or False

1. Data profiling is followed by data mapping.
2. Consolidating is a data cleansing technique.
3. LSMW is a data cleansing tool for SAP projects.
4. ETL tools need to have capability of data profiling.
5. Verification is the first step of data migration.
 15
Cutover Planning and
Go Live Preparation Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Cutover
Cutover Planning
Go Live Preparation
Go Live Checklist
Go Live Audit

CUTOVER
Cutover is the final stage of ERP realisation before the company moves on to the new system. Based on
the implementation approach, a company may take up few modules for cutover (phased implementation
approach) or complete cutover (for all the modules).

Cutover Planning
For moving from old system to new ERP application, activities need to be planned in minute details
and transactions need to be stopped in the old application for a brief period and moved to the new ERP.
Table 15.1 is an example of such a cutover activity for materials management module implementation.
In the example, transactions in the old system is completed on 28th and three days are planned to move the
open items to the new system before the changeover happens in the new system on 1st.
A real-life cutover plan for a company having multiple factories and distribution centres can be really
complex.

Understanding Criticality of Transaction for Cutover Planning

Cutover need to be planned in a way that there is minimum business disruption. It is important to understand
the criticality of the transaction before planning the cutover. There are some critical business transactions
like customer ordering, invoicing, etc which a business will never like to stop as there may be chances of
revenue loss, whereas something like creating a maintenance order or creating new purchase contracts for
 Cutover Planning and Go Live Preparation 201

Table15.1 Material Management Cutover for Company XXX

Transaction End date for transaction in the existing system

Creation of indents 28-12-2009
Purchase orders for materials 28-12-2009
Placement of service contracts 28-12-2009
Inward entry 28-12-2009
Invoice entry 28-12-2009
Receipt of goods at receipt section 28-12-2009
Goods taken on charge 28-12-2009
Excise invoice entry 28-12-2009
Issue requisitions 28-12-2009
Goods issues 28-12-2009
Goods return note 28-12-2009
Stock verification entries 28-12-2009

vendors can be differed by a week. Typically minimum downtime is taken for most critical transactions,
i.e. last sales order and invoice can be entered in old system up to Friday night and from Monday morning,
these will be done in the new system, whereas for not so critical transactions, a little more downtime can
be considered. Understanding this criticality is important and this need to be a senior management decision
for the company going for ERP as typically every department in the company believe their transactions are
most critical.

GO LIVE PREPARATION
The day a company moves from the old legacy system to the new ERP application is called “Go Live”
date. Ideally, a company should complete all its ERP project related activities before going live, though in
reality it is far from truth and in most cases projects go live with a number of open issues. However, it is
important that before “Go Live”, all critical project activities are completed. These critical activities can
be things like:
All configurations
All developments
All testing (Unit testing, integration testing, user acceptance testing)
Trainings of core ream, power users and end users
Data migration completed
All authorisations are created and authorisation testing completed
In most ERP implementations, before going live, there will be a list of open issues. It is OK to have such
issues till the company is not going live without having some critical issues pending. It is important to have
a detailed list of these issues with an agreed upon time-frame within which such issues will be closed by
the consulting team and core team from company’s side.
202 Enterprise Resource Planning

Go Live Checklist
It is common to prepare a detailed checklist as shown below and a “Go Live” decision is taken only when
each of these critical areas shows a green status. Table 15.2 shows such a checklist.

Table 15.2 Go Live Checklist

Area Assessment Point Status

1 External Certifications Green
Business process performance optimisation completed
Volume testing optimisation completed
Go live early watch report completed
Go live check completed
2 Infrastructure Green
Production server installed and functional
Sandbox system installed and functional
Development system installed and functional
Quality assurance system installed and functional
Server management utilities installed and functional
Terminal servers installed and functional
Network hardware installed and functional
Database management system installed and functional
On-line support services registered
Batch jobs scheduled
3 User Workstations Green
ERP software GUI installed on terminal servers
End users have network access, including offsite users
4 Printers Green
Configure all laser printer or local print queues
Specialised printers identified and set up
High speed/high volume printers set up and tested
5 Security Green
User ID verified
Roles tested and approved
All policies and procedures for ERP system administration
documented
6 Cutover Plan Green
ERP configuration validated
(Contd)
 Cutover Planning and Go Live Preparation 203

(Contd)
Security steps validated
Business data validation process validated
Controlled cutover process identified
Controlled ramp up processes planned
Cutover plan validated
7 Quality Assurance Green
All open defects resolved
Unit testing completed
System testing completed
Integration testing cycle 1 completed
Integration testing cycle 2 completed
Data conversion testing completed
Performance testing completed
Performance test results accepted by business
Final review completed and accepted by business owners
8 End User Training Green
All end users trained
All security administrators trained
Service desk level 1 resources trained
9 Support Green
Enhance support planned
Promotion to production procedures documented
Training systems installed, and configured (for future new users)
Training end-user ID created
Training environment refreshes scheduled
Post-Go Live client strategy in place
Enterprise job monitoring in place
Backup and recovery process in place
Escalation procedures established for all levels of support
Communication activities in place to update end users
Release management to production established and ready
Documentation completed
Procedures are in place for emergency change requests
10 Communication/Change Green
Management
Employee communication planned
End user communication planned
(Contd)
204 Enterprise Resource Planning

(Contd)
Enhance support communicated
Ongoing support communicated
External customer communication
Vendor communications

Legends
Green Component is production-ready, or on schedule to be production ready
Yellow Component is production-ready, but requires minor refinement with an achievable
plan in place or not a show stopper for going live
Red Component is NOT production-ready. Unable to go live

Go Live Audit
It is also common to have an audit done by an external agency before going live. There are different options
on who will do such audit.
Some companies prefer to get the project audited by a different group of the implementation consult-
ing service providers and who are not part of the project team.
In some cases such audits can be done by ERP package vendor itself. For example, SAP has a service
offering for auditing SAP projects before going live and that is SAP’s recommended approach for
solution implementation
A third approach can be getting such audit done by another third party consulting company. It is not
a common practice. However, some companies prefer to follow this approach
The objective of such Go Live Audit is to ensure that the company is really ready for go live. There are
cases in past where several projects went live by any means on a particular date for reasons like:
The financial year is closing on 31st March and if Go Live gets differed beyond 1st April, there is
lot of additional work (as for regulatory reasons company need to take stocks, close books, etc by
31st March and these activities can be very well merged with Go Live as that also need similar set of
activities. If Go Live is differed, these activities need to be done separately only for the ERP project.
There can be also new tax or other regulatory laws applicable in the new financial year)
It is a fixed cost project and the consulting company wants to go live by a particular date as beyond
that extending the project is a loss for them.
The company wants to Go Live on a particular date as the CEO said so.
It is not advisable to delay Go Live as that involves extra cost, plays havoc on the moral of project team,
etc. However, going live with thousands of critical open issues is also not a good option. The audit team can
do a validation from an outsider’s prospective and does a quick health check to see whether the company
is really ready for the D-day.
Typically, go live audit focuses on the following things:
Completeness of Integration testing – Test reports and open issues (whether all the processes are
covered in integration testing, what are the test failures – whether they affect some of the critical
processes, etc)
End user training (whether all the end users who are supposed to use the system post-go live are
trained based on their role – where are the training records, training feedbacks, etc)
 Cutover Planning and Go Live Preparation 205

End user acceptance testing and signoff (whether end users had tested the system for the business
process, they will us post-go live – where are their sign off documents, any feedback from them dur-
ing testing, etc)
Data migration (whether all data are migrated to the new system – which data elements are pending
and are they critical?)
Support help desk (whether this is in place to help users post-go live, whether support desk team
is trained and knows what they are expected to do, whether the process of handling support ticket is
established, etc)
Period End Closing Procedures (whether this is defined across all modules)
Critical open items
Go live audit evaluate the risk of all these issues and provide recommendations. There can be cases where
go live team can conclude that risk is very high in case the project goes live on the date finalised earlier
and date need to be differed. These audits typically range between 2-5 days depending on the size of the
company and across all ERP modules. The audit team is supposed to make a presentation to the project
stakeholders in the final day of the audit and send a detailed document on findings and recommendations
to the project stakeholders within few days of audit completion.

Summary
Cutover and go live is the final stage of ERP project realisation before the company moves to the new system.
These activities need lots of planning for smooth transition to the new application.
Cutover planning details on which date the transactions from the legacy application will stop. Post this date,
the selected transactions will happen in the new system. This activity needs to be planned looking at criticality
of transactions, i.e. ensuring as less downtime as possible for critical transactions.
Go live checklist is a ready reference document for all the points that need to be considered before going
live. Go live decision needs to be taken only when all these critical check points show a green status. There
can be few not so critical open points while going live that need to be closed within an agreed time-frame.
It is always recommended to have a third party audit before going live.

Exercise
I. Objective Type Questions
1. What is meant by cutover in an ERP project?
2. Why understanding of criticality of transaction is important for cutover planning?
3. What is a Go Live Checklist? Why is it important?
4. What is Go Live Audit? Why is it needed?

II. Descriptive Type Questions

1. Explain cutover planning. What things need to be considered when planning for a cutover?
2. What is a Go Live Checklist? What all does it contain?
3. What is Go Live Audit? Typically what things does it focus on?
 16
Training
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Training objectives
Training strategy
Training environment and technology
Train the trainer approach
Training delivery
Training content development
Training evaluation
Training roles

INTRODUCTION
Training is an important element of ERP project and success and failure of a project depends a lot on how
well the company’s people are trained in the ERP software and learnt the newly designed processes in that
software. This is an ongoing activity during the entire project life cycle where first core team needs to be
trained (during the project preparation phase), power and end users need to be trained (during project reali-
sation stage) and finally support team need to be trained (during transition stage). Figure 16.1 shows how
training is a part of the entire ERP project life cycle.
The purpose of aligning training to project timeline is that just after training, people can directly apply
their new learning to the project. For example, before blueprinting, core team members are given ERP pack-
age process training so that they can do the blueprinting effectively. Before project realisation starts they are
given configuration training so that they can do system configurations. End users need to be given training
before the project goes live. But, this does not mean that the training should start just two weeks before the
project goes live and the training remains incomplete. In the same way, the training should not be given six
months before as the trainees will forget things by the time the project goes live.
 Training 207

Fig. 16.1 Training Activities in an ERP Project Life Cycle

TRAINING OBJECTIVES
The main objectives of training in an ERP project are as follows:
Make core team members and power users champion in the respective module they are working on
so that they can design a business process in a way that can be configured in the ERP system, can
configure the system and test the scenarios.
Make the core team members comfortable so that they can train the end users (using train the trainer
approach) and can handhold them during go live and in post go live phase.
Make end users comfortable in the system so that they can run the transactions and scenarios they are
supposed to use in the system.
Build a training content that is comprehensive and simple to understand based on different end user’s
role, i.e. what transactions/processes/scenarios they will use in the system. This material help end us-
ers quickly understand the know-how to perform their jobs and can be a ready-reckoner for anyone
joining the organisation in same role.
Provide tools to measure effectiveness and quality of training
Enable tracking of training completion and find out people who had not yet completed a particular
training which they are supposed to complete.
208 Enterprise Resource Planning

Table 16.1 shows how training objective, activities and target group varies as per the different phases of
the project.

Table 16.1 Training of Various Target Groups During Different Stages of an ERP Project Implementation

Stage Training Objective Training Activities Target Group

Make the core team ready for business Give ERP detailed process training Core team
blueprinting so that they know ERP
processes and what ERP has to offer
End of Project Make the project stakeholders ready so Give ERP process overview training Senior leader-
Preparation that they can understand the ERP solu- ship team
tion at high level
End of Business Make the core team ready for configur- Give ERP detailed configuration train- Core team
Blueprinting ing the ERP package ing
Realisation Prepare for end user training Prepare end user role-based training End User
material, plan for training logistics,
facilities, etc
Final Prepara- Conduct end user training Conduct training classes, take feed- End user
tion back
Final Prepara- Make help desk team ready Conduct training to help desk support Support team
tion team
Post Go Live Train new people coming in the organi- Train new people joining, conduct New employees,
sation, keep trainings go on regular refresher courses for existing End users
employees

TRAINING STRATEGY
Developing a training strategy has a host of challenges as shown in Figure 16.2. These are:
Who needs what kind of training: What different types of trainings are needed and who will be the
audience for those trainings. For example, company’s senior management may need high level overview
of ERP processes, end users may need to learn just the particular transaction they are expected to do
in the system and power users/core team need to be champion in ERP configurations and processes.
Whether some part of the training will be outsourced: Many companies prefer to outsource some
part of the training activities like training content development, training data preparation, etc to other
third parties to save cost.
Which training methods to utilise: There are different training methods available today like tradi-
tional instructor-led classroom training, e-Learning, virtual classroom training, online training, etc and
different training methods may be suitable for different types of audience. For example, a particular
core team user in procurement area may need detailed classroom training in procurement area as they
need to be champion in this area. However, they need to have high level understanding of production
area as production management has lot of integration areas with materials management and for this
an e-Learning material should be good enough.
 Training 209

Fig. 16.2 Challenges for Training Planner

Training environment: Whether the company should have a separate training environment where
people can create sample data and run scenarios to practice and get comfortable. Some companies like
to go for a separate environment (generally common if there are too many end users) and some may
use the existing quality environment (typically for companies having few end users) for training.
Training locations: Whether all trainings will happen at one central location or trainings will be
distributed at different locations. Typically, all core team trainings happen in one central location.
However, the end-user training can happen in one central location or in distributed locations.
Training duration planning: Every stakeholder in the organisation need to be trained during imple-
mentation, but in different depths. For example, steering committee and very senior management may
need a two-hour high level overview training of the ERP solution, process owners may need a one-day
process level training, core team users may need a detailed process and configuration training of two
weeks and end users may need a three-day training for particular transactions they are supposed to
do.
Training content planning: As discussed earlier, for different stakeholders as durations vary, the con-
tent also needs to vary accordingly. For example, ERP core team may use product vendor’s standard
training material, whereas training content for end users need to be developed.
Table 16.2 shows a model training plan developed by exercising the training strategy.
210 Enterprise Resource Planning

Table 16.2 A Model Training Plan

Phase of Whom to Area Trainer No. of Days / Training Content

Project train trainees Hours Method /
Where
Project prepa- Senior leader- ERP overview Project man- 30 4 Classroom Presentation need
ration ship of the or- ager – Con- hours (Project to be developed
ganisation sulting com- office) by consulting
pany project manager
Project prepa- Core team Procurement Package 15 10 Classroom Package vendor’s
ration –Process and vendor days (Project procurement mod-
configuration office) ule content
Project prepa- Core team Sales Package 15 10 Classroom Package vendor’s
ration –Process and vendor days (Project sales module
configuration office) content
Project prepa- Core team Finance– Package 15 10 Classroom Package vendor’s
ration Process and vendor days (Project finance module
configuration office) content
Blueprinting Core team Process model- Consulting 60 2 days Classroom PPT and exercises
ing techniques team (Project need to be devel-
office) oped by consult-
ing company
Realisation End Users Procurement Core team 30 3 days Classroom PPT and exercises
– Purchase transactions Factory) need to be devel-
department oped by a third
party vendor
Realisation End Users Store transac- Core team 30 2 days Classroom PPT and exercises
– Store tions (Factory) need to be devel-
department oped by a third
party vendor
Realisation End users Sales transac- Core team 200 3 days Classroom PPT and exercises
– Sales tions (Branch) need to be devel-
oped by a third
party vendor
Realisation End users Billing Core team 25 2 days Classroom PPT and exercises
– Billing transactions Factory ac- need to be devel-
counts) oped by a third
party vendor

TRAINING ENVIRONMENT AND TECHNOLOGY

Training Environment
Training environment is used to provide structured practice sessions on the system as part of the system
training. The purpose of these structured practice sessions is to reinforce skills taught and address exception
areas. The aim is to move users from a position of being ‘aware’ how to do something to actually being
 Training 211

able to perform an activity in the system. This is achieved by first showing users how to do something,
then giving them the opportunity to try it out for themselves, followed by an assessment and re-inforcement.
This is illustrated in Figure 16.3

Fig. 16.3 Structured Training Sessions—Awareness to Ability

The purpose of the training evironment is to allow users to manipulate dummy data on the application as
part of their training course. This practice ensures that the users understand the tasks they are performing
and feel more comfortable with the new application because they have had "hands on" experience.
Core team members and end users typically uses testing environment.
As the training environment is a simulated work environment used for training purposes, it needs a da-
tabase of “dummy” data, called a training database to operate successfully. Generally following steps are
followed to create such dummy database:
1. Identify training data required
2. Create this data in the system (This needs to be a representative one from business, i.e. some of the
actual materials, vendors, customers, etc)
3. Build the scenarios
4. Test the scenarios
5. Create user IDs for people who will use this training environment (i.e. Logon ID and password)
6. Pilot for few users first
It is a common practice to refresh training environment data at regular intervals as users, while practic-
ing in the system, keep on creating lot of dummy data or create lot of entries by mistake. For this, training
environments generally have a master client and after regular interval (say every weekend), the master
environment data is copied back to another environment where the participants can do practice. This means
all data used in practice exercises is “reset” allowing it to be used again and reducing the amount of data
that needs to be created.

TRAIN THE TRAINER APPROACH

One of the common ERP training deployment program is the Train the Trainer (TtT) approach. With this
approach, consultants train core team members, identified from the business, who, in turn, train end users.
The benefits of this approach include:
Much less cost for the company because if consultants do all these trainings then that would mean
paying for many consulting days for a low-end work.
212 Enterprise Resource Planning

This creates better confidence for core team users as they need to answer most of the end-user queries,
need to prepare themselves for that, need to continue handholding and, in turn, they learn the system
better.
In most cases, core team members are more acceptable to their users as they are the people from their
own company.
It helps in better change management.
The aim of TtT programme is to ensure that the trainers are confident and competent to deliver end user
training. So besides course materials, some companies provide some soft skills also to the trainers so that
they can impart better training. These include:
Teaching how people learn
The importance of using questions
Successful training techniques and instructor behaviors
Training preparation checklist
Handling nervousness
Presentation skills
Handling difficult people
Assessment techniques
Reviewing training execution
Dry-run training sessions to ensure trainers have fully understood system and training requirements

TRAINING DELIVERY
In earlier days people used to believe classroom training as the only model of training. However, nowadays
there are different training delivery methods based on the purpose of training. Table 16.3 shows such dif-
ferent models:

Table 16.3 Models of Training Delivery Methods

Delivery Method Package Format Description

Face-to-face training Instructor led train- ILT is scheduled and facilitated by a trainer in a classroom environ-
ing (ILT) ment. There is normally some system interaction and/or simulation.
The package will be made of components including training slide
presentations, exercise workbooks, datasheets, quick reference
guides and simulations. ILT is used for critical process and system
training.
Face-to-face training Workshop Workshops are scheduled and facilitated by a trainer in a classroom
environment. They will include some formal training as well as in-
dependent practice with the trainer available for question and answer.
Workshops are often used for management information training.
Face-to-face training Seminar Seminars are facilitated by a trainer either ‘face-to-face’ or over
NetMeeting to supplement e-Learning. They provide participants
an opportunity to ask a trainer questions.
(Contd)
 Training 213

(Contd)

Self-paced learning e-Learning An interactive, web-based package which participants complete in

their own work environment. These may have simulated exercises
or quizs embedded as part of the course.

Self-paced learning Weblecture Scripted and automated powerpoint-based material, running over
the company’s intranet, which participants view in their own work
environment.
Self-paced learning Self-study Independent documentation that is read outside of formalised
courses.
Self-paced learning Quick reference Practical help documentation created to be used on-the-job in the work
guide (QRG) environment. These is often be introduced in instructor-led events,
seminars, etc but are designed for ongoing use after go-live.

Self-paced learning System simulations System simulations (known as STTs) provide end users the opportu-
(STTs) nity to view, practice or test themselves on key transactions. STTs
will be used as components of other packages, or may be utilised by
an end user individually to practice specific transactions.

The company needs to decide right training delivery mechanism depending on the audience and type of
training (overview, detailed, etc)

TRAINING CONTENT DEVELOPMENT

Training content development is an important activity and it constitutes the core training materials that
will be used to deliver business process and systems training to end users. In case of companies doing
implementation in multiple countries the main training material is developed in one language (say, English)
and handed over to local trainers for localisation. Training materials include all the components that make
up a training package such as training slide presentations, exercise workbooks, datasheets, quick reference
guides and STT simulations. Development of all training materials follows the standard process as shown
in Figure 16.4.

Fig. 16.4 Standard Process for Developing Training Materials

All new training packages need to be “piloted” to ensure that they are fit for purpose learning. Pilots
occur during the train the trainer programme. All training materials need to be reviewed by subject matter
experts.
214 Enterprise Resource Planning

TRAINING EVALUATION
The purpose of the training effectiveness review is to identify strong and weak areas in the learning solution,
uncover specific learning gaps and identify which learning objectives and training curriculum modules need
to be revised. A number of evaluation techniques can be used to measure the effectiveness of the training
throughout the development process and after each training session. The training materials can be tested
after each phase of the design and development process in order to make improvements prior to release;
methods include conducting expert reviews, user tests and pilot tests.
Post training, the participant’s reaction and knowledge need to be evaluated. Did they like it and did they
learn from it? Questionnaires completed by each participant after each module will measure their perceptions
of the course; whether it met the learning objectives and how effective the instruction on the course was.
This type of evaluation can reveal areas of focus for targeted efforts. Each participant’s learning should be
measured by quantitative means. End user questionnaires are a common method to measure such effective-
ness.

End User Questionnaires

These are a set of questions to be answered by the end users after attending each training package. Key
areas covered are training materials, feedback on the trainer and the perceived overall effectiveness of the
training in the trainee’s job. The purpose is to:
Help maintain consistent standards by identifying and taking remedial action where standards fall
below expectations.
Address issues such as: administration, learning environment, access, facilitation, etc.
Provide an indication of whether users understand roles and responsibilities, system and processes.

TRAINING ROLES
Different project team members need to play several roles to make training successful in an ERP project.
Several large projects have separate training managers for effective execution of training. Table 16.4 shows
some common training roles as found in different ERP projects. Whether these roles will be full time or
part time depends on size of project and the amount of work involved in each.

Table 16.4 Roles and Responsibilities of Training Executing Team in ERP Projects

Team Member Role Specific Responsibilities Effort Estimate

Training manager/Lead Manage team, budget, effort, deliverables, risks and May be a full-time role depend-
issues related to training ing on size of the project or
Manage overall training schedule of the project some senior member spending
Lead overall content development plan 50% of time
Training delivery coor- Co-ordinate training development effort Approximately 5 mandays/
dinator Co-ordinate creation of trainer’s guide and coach’s month
guide
Coordinate ‘train the trainer’ approach
Develop training effectiveness review materials
(Contd)
 Training 215

(Contd)
Training content devel- Develop training materials like: Full-time role for three months
oper Generic training course slides (three people)
Screen capture demo
Supporting trainer’s guide
Training scenarios
Documented training data requirements
Support development of the training evironment

Summary
Proper training of the ERP system is one of the most important criteria for success of ERP implementa-
tion.
Different users need to be trained at different levels. While senior management need a high level overview
training, process owners need to understand ERP processes, core team need to be champion in the system,
end users need to master particular transactions which they will use on regular basis.
Training environments require lots of planning in terms of training environment, content, training locations,
trainers, etc.
Train the trainer approach is one of the tested and successful training methodology adopted in most of the
ERP implementations.
There are different training delivery options.
Every training should be followed by an evaluation to check its effectiveness.
There are different types of training roles having specific responsibilities.

Exercise
I. Objective Type Questions
1. In which phases of the project what type of trainings are provided to core team?
2. In which phases of the project what type of trainings are provided to end users?
3. What is train the trainer approach?
4. What is e-Learning?
5. What are system simulations?
6. What are the common methods of training evaluation?
7. What are the responsibilities of a training manager?
8. What a training content developer is supposed to do?
9. What is the purpose of having a training environment?
10. Why training environments are refreshed at regular intervals?

II. Descriptive Type Questions

1. What are the main objectives of training in an ERP project?
2. What type of training is provided in which phase of ERP project?
3. What are the parts of ERP training strategy? Give an example of output of this exercise.
216 Enterprise Resource Planning

4. What is meant by a training environment? Why is it required and how is this created? How is training
dataset created?
5. Explain the train the trainer approach
6. What are the different training delivery methods? Explain each of them. What type of training is suitable
for what purpose?
7. Who develops the training content? What is the process of developing such content?
8. Why training evaluation is important? How is this done?
9. What are the different types of training roles? What is the responsibility for each of them?

III. State Whether the following Statements are True or False

1. In train the trainer approach, trainers are end users of the business.
2. Senior management should be given ERP configuration training.
3. During the project preparation stage, core team is trained in ERP processes and configurations.
4. End-users in ERP project are trained during business blueprinting.
5. Training environment needs to use actual data.
6. E-Learning is a Self Paced Learning technique.

IV. Assignments
Study an organisation that had taken up an ERP project in the past. Study the company’s training plan and note
down following details:
How had they planned for training during the entire project duration?
What training delivery methods and formats were followed?
In what phase of the project what training was provided?
What approach was taken for training content development?
Who conducted what training in different training phases?
Whether company had used any separate training environment?
Who created training data?
 17
Change Management
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Change management plan for ERP project team
Why people resist change (the new ERP system)
Strategy to handle change for the project team
Change team and change management roles
Change management activities during life cycle of a project
Search for a change management methodology – Six key processes of ASAP

INTRODUCTION
Enterprise Resource Planning or ERP system installation is not enough. In a 1998 worldwide survey of 186
ERP implementations, it was found that several projects which failed, in most cases are for people-related
issues. Barriers to the success of these projects were: Skills and training, oganisational resistance, execu-
tive commitment and absence of clearly defined business case and objective. The Gartner Group in the past
reported:

“Less than 25% of project will deliver hard, monetary benefits.”

“27% have not been able to or did not attempt to measure business benefits. Not doing this
was an obstacle to justifying additional investments.”
“70% of projects fail due to NOT using performance metrics as change agents.”

The above facts demonstrate clearly the importance of organisational change management for the success
of the ERP implementation. One way to do ERP implementation rightly is to address not only technology, but
processes and people. In the case of technology-diven change, the new system is the primary change driver
and, when installing the system, you also need to consider the infrastructure that surrounds it. ERP systems
218 Enterprise Resource Planning

build best practices regarding processes into the software, so new work flows need to be developed and
implemented. Because the new technology effects the people in the organisation, the elements of preparing
the people for the change need to be addressed. During ERP implementation, all three components need to
come together for the benefits of the system to be realised. Figure 17.1 shows these three components. It
is important that this relationship is understood well before a company decides on going for ERP. Change
management is about getting and keeping people’s involvement, commitment and focus and thus reducing
‘implementation risk’.

Fig. 17.1 Integration of People, Process and Technology for Successful ERP Implementation

CHANGE MANAGEMENT FOR THE ERP PROJECT TEAM

Why People Resist Change (The New ERP System)
Before going into the details of how to implement change management for project team members, let’s
understand the reasons why people typically resist an ERP implementation. An ERP implementation may
cause a lot of uncertainty and fear in the minds of people – fear of losing job, fear of failure and uncertainty
about future. Some of these typical questions keep them bothering are shown in Figure 17.2. These are:
Whether my job will remain?
What will be my new role?
Whether I need to do a different job in the new role? Will I be able to do that? Will the work load be
more?
Whether I will be able to operate the new ERP system? If I can not then whether I will be penalised?
I came to a new office for this project – whether I need to go back to my old office after the project
is over? Do I need to do the same old job there or there will be a new role for me there?
I will put so much effort and will learn a new skill – whether this new skill will be valued once the
project goes live or will it be no longer needed?
 Change Management 219

Fig. 17.2 Bothering Questions Making People Resist Changes

What’s in it for me? Why should I put so much effort to learn ERP and to implement it successfully?
Why should I change?
ERP is for young guys, for the new generation, for IT savvy guys. I am an older person, do not un-
derstand much of computer and IT, can I cope up with the new technologies?

Strategy to Handle Change for the Project Team

Success of any ERP implementation depends on how successfully the issues raised above are answered.
First Level – Handle Fear and Uncertainity The first important thing is to take out fear and
uncertainty from people’s mind. This is a basic psychological hygiene factor, but not necessarily once this
is achieved, everyone in the team will be highly motivated. However, without this the next step can not
be achieved. Sometime this is referred to as “Basic Need” as per Maslow’s hierarchy of needs, a popular
subject in organisational behaviour. Strategies to handle this are:
Communication
Training
Handhold by own team member – Create power user, ERP champions
Ensure round-the-clock help desk support, once the system goes live
Leadership support
Communicate.. Communicate.. Communicate This is, perhaps, one of the best ways to take fear out
of people. Continuously communicate to the people about the project as much as possible. Communication
is needed on different areas like
220 Enterprise Resource Planning

Make the entire organisation aware of the project. Inform people regularly about the project status.
Congratulate them as soon as one milestone is achieved.
Make people aware of what new is going to come – new processes, new roles.
Communicate the core team member much before the project ends about what will be their new role
whether they will support the application or they will go back to their old offices in the functional
role from where they came. If they go back whether there will be change in their old role.
Communicate the project team members, if something of high risk is foreseen. While designing strategy
for this risk mitigation is a job of project management, the team need to know it early so that they are
not surprised if suddenly they are asked to come on Sundays.
Communicate project stakeholders the regular status of the project.
Communication is also needed from the senior management team ensuring employees that “ERP
implementation is not to take out their jobs” but to help them in doing something more interesting
and more value-adding for the organisation. Sales guy can now spend more time in selling instead
of calculating data in fifty different excel sheets every week for management reporting – system will
take care of that automatically.
It is the job of project management team to come out with a clear communication strategy. A communica-
tion strategy can have different elements like:
Identifying the right audience for communication–Identify the people who need to know about the
project happenings – these may be employees, project stakeholders
Methods and vehicles for communication according to the audience – This may differ as per the
audience. For CEO or senior management, project status can be communicated in English through
flashy presentation, MS Project, etc. For workers in the shop floor or for the goods receipt clerk, the
communication can be in the form of a simple poster in the canteen in local language without any
ERP jargon. Some companies also do communication on ERP implementation status to employees in
the form of newsletter in local language.
Determine communication frequency/time-frame: Whether project sponsor and senior leadership
need to be communicated every week or every month. How frequently employees should be com-
municated?
Who should be communicated what: It is important to decide what should be communicated to whom
– while senior management can be communicated on project status, issues that need their attention,
project scope changes, etc, for a business process owner, the new way of running the process needs
to be communicated in detail, for a shop floor worker, the communication can be much simpler and
light in content telling where we are in the project, etc.
Determine communicators: Identify who will do the communication.
Training “Fear of ignorance” is another reason for people’s resistance to change – people in an organisa-
tion sometime belief lots of misconceptions about ERP simply because they do not know what ERP is all
about. There are misconceptions like “ERP will take away jobs” or “ERP will automate everything and the
company needs very little people to run the business,” etc. The only way to handle such misconceptions is
training the people – once they know that ERP is something that will help them in their daily work, will
help them to focus on something more value adding – these fears and uncertainity about the future goes.
Importance of training in ERP implementation is well known and that’s the reason a complete chapter
(chapter 16) is devoted on Training.
Having a Team of Power Users and ERP Champions These are the people who are champions or
experts in a particular ERP module and mostly part of the core team or extended core team. As these people
are company’s own people, employees feel more comfortable in learning from them then the consultants.
 Change Management 221

They are referred to by different names in different projects like “ERP champions”, “ERP power users” or
“ERP experts,” etc. Their job is to train users (following Train the trainer approach), test the system along
with user (also known as user acceptance testing) and do the handholding and supporting the users when
the project goes live. Having this team also helps in taking out fear from the people as they know there is
always someone available within the organisation to help him if he needs help and these are company’s own
people and will not leave the project as soon as the system is live like external consultants.
Round-the-Clock Help Desk This need to be in place as soon as the system goes live. Again an important
support for employees to have confidence in the new system – for any problem with the new system, they
can log a call and within defined number of hours they are assured of getting a solution from the expert.
Leadership Support Senior leadership can play a key role in reducing fear and uncertainty. People need
to understand what they are working towards and how they will achieve it together. This needs ensuring
clear direction to all project team members from leadership team, motivating the team and facilitating com-
munication (through status reports, team meetings, etc.). Leadership’s commitment to change throughout
enterprise can go a long way to get people’s support for the project.
Second Level—Getting Motivated and Committed While proper training or communication can
help in taking out the fear factor from the employees, that is not always enough to get them committed or
motivated to the project. This is a bigger challenge for change management team as different people get
motivated in different ways.
There will be always a group of people who are self-motivated and you need not do much for them
– whatever thing they do with lot of enthusiasm.
There will be another group in the core team who may be motivated for not so desirable reasons – they
know that ERP is hot and they need to have one successful project implementation background in their CV
to get a premium in the job market. If the project fails or closes in between, their experience also does not
count much. They can be highly motivated and committed to the project till at least the Go live happens.
There is a third group which wants to see clearly “What’s in it for me”, i.e. why he should put so much
effort in doing the project. Keeping this team committed is always a challenge and an organisation can take
up different strategies to handle this. Some of the common ones are:
Involve employees in each critical ERP decisions, discussions
Design incentive schemes and performance measures: People need to have incentives to adopt new
ways of working
Design new and more interesting roles

Organisational Design
Designing incentive schemes or new roles often comes under Organisational Design (OD). The basic objective
of OD is: “The architecture of the organisation needs to be aligned with the new process and technology”.
New technology will have an impact on the structure of the organisation as new technology may lead to new
processes which leads to new roles and responsibilities and new organisation structure. Process changes feed
changes to roles and responsibilities. New job descriptions are written. New reporting structures are defined.
New performance measures are developed that decides what behaviour the organisation will promote, how
to reward that etc. A transition plan to move from current to target state is developed and implemented. So
organisational design means:
New roles and responsibilities
New reporting structure
New job descriptions
222 Enterprise Resource Planning

New performance measures and incentive systems can play an enormous role in determining and
reinforcing desired culture or behaviours. New technology may change what is important.

CHANGE TEAM AND CHANGE MANAGEMENT ROLES

Change Team
The organisational change management strategy includes creation of the core and extended change teams.
Core Change Team: Implements organisational change management steps in conjunction with the other
ERP activities; directs extended change team resources; reports to the project sponsor and manager.
They are the dedicated resources from HR, OD professionals or consulting team.
Extended Change Team: Introduces and conducts risk assessments, communicates about the project,
implements action plans. They can be part time members from line management or consulting team.

Change Management Roles

Figure 17.3 shows a typical structure of change management team. The lead role in the core change team is
that of the Change Team Lead who reports to the sponsor and manager of the SAP implementation project.
Each organisational change management process has a point role to represent it on the team.

Fig. 17.3 ASAP Change Management Roles

 Change Management 223

Key site sponsors and line managers form part of the extended team which is covered in the core change
team itself by the project risk manager role. Key site sponsors and line managers will be particularly
important in the ongoing risk assessment effort as well as the core sponsorship and communications
processes.
The core change team can consist of numerous people, each focusing on different processes, or it
can simply be one to two people wearing multiple hats. Again, as with the determination of which
processes are implemented, the size of the team will be based upon organisational needs and available
resources.
The core change team is ideally a mix of long- and short-term employees who can bring a wide range
of company experience to the team.
The change team lead must know the organisation well and be well-respected within it. The team
lead will become the symbolic face of the organisational change management programme. Therefore,
the more credibility he/she holds in the organisation, the better roles he performs.

CHANGE MANAGEMENT ACTIVITIES DURING LIFECYCLE OF A

PROJECT
Change management activities spans across entire ERP project life cycle. In this chapter the different change
management activities during different phases of the project are discussed.

Change Management Activities During Project Preparation

In this phase the organisational change management plan is prepared with activities – budget and resource
for the project, change management team is formed and they are trained in change management principles.
Change management work plan is a key deliverable of this phase of the project that clearly defines overall
organisational change management methods and processes including, for example: key deadlines, deliver-
ables and activities; project reporting; organisation wide communication processes etc. Typical activities of
this stage are:
Develop change management plan
Identify change sponsors (for all locations – each factory, each office where ERP is going to be imple-
mented)
Assign people to core change team roles
Create extended change team
Change management training planning

Change Management Activities During Business Blueprinting/Designing ERP

System
In this phase the organisational change management plan is prepared with activities – budget and resource
for the project, change management team is formed and they are trained in change management principles.
Change management work plan is a key deliverable of this phase of the project that clearly defines the overall
organisational change management methods and processes including, key deadlines, deliverables and activi-
ties; project reporting; organisation wide communication processes etc. Critical activities in this stage are:
Change communication framework
Identify point person to manage project communications
Identify methods and ways for communication
Developing communication content
224 Enterprise Resource Planning

Identify frequency of communication to different stakeholders

Conduct change management training
Develop organisational change management training strategy
Select training partner and conduct training
Evaluating training effectiveness

Change Management Activities During Realisation/Building ERP System

The purpose of organisational change management in realisation phase through to project completion is to
facilitate implementation and go live by keeping people involved, focused and motivated. This is effected
by keeping in touch with how the project team and impacted parts of the organisation are feeling about the
ERP implementation, identify and implement appropriate action to address key concerns, sustain sponsorship
and communications strategies, maintain awareness of/implement skills development and knowledge transfer
strategies, and maintain awareness of need for/implement organisational optimisation. Another important
activity of change management at this phase of project is team building. This helps to nurture and strengthen
relationship among project members, promote communication, cooperation and trust.

Change Management Activities During Go Live and Project Closing

Summarising lessons learned is an important activity during project closing. Many of these lessons learned
will be useful to the organisation post-implementation. In completing organisational change management,
the change team resolves any open issues, disbands the core and extended change teams, and recognises
team members as appropriate.

SEARCH FOR CHANGE MANAGEMENT METHODOLOGY—SIX KEY

PROCESSES OF ASAP
While every organisation can do change management in its own way, a structured change management
always helps an organisation to take right steps in perfect sequence and follow a tested path which had
already given success to several other companies earlier. The leading ERP vendor, SAP, came up with such
a methodology for change management as a part of their ASAP methodology for ERP implementation. In
this chapter, the key processes of this methodology are discussed.
ASAP change management methodology comprises six key processes as shown in Figure 17.4 and these
are:
Assessment (Risk assessment)
Communications
Sponsorship
Skills development
Knowledge transfer
Organisational optimisation
Of these six processes three are considered as Core processes, i.e. if assessment, sponsorship, and com-
munications are not done, organisational change management is not done. Skills development, knowledge
transfer, and organisational optimisation are referred to as supporting processes. In the field, the organi-
sational change management team and other project personnel determines the extent to which each of the
supporting processes should be implemented based upon the needs of the organisation, the available resources,
etc. Core processes are the focus for the organisational change management. However, this is not to say
supporting processes are not crucial.
 Change Management 225

Fig. 17.4 Organisational Change Management—ASAP Way

Core Processes
Assessment: This is the foundation of organisational change management approach. It is the process
of identifying and prioritising perceptions of the organisation’s people about the project.
Sponsorship: This is the ongoing process of leadership support, i.e. of senior management, key site
sponsors, line management, supervisors, etc. The change team needs to ensure properly targeted mes-
sages are delivered at the right time to address the current perceptions. Typically in the beginning of
project, general messaging coming from senior management team supporting the project helps. As the
implementation progresses, messaging needs to become increasingly more specific and, therefore, split
up amongst more diverse target audiences. Generally, the more specific and localised the message is,
the more effective it is. Sponsorship at the executive level provides the real and symbolic evidence
that gives the project credibility, is a critical early requirement. Sponsorship at the local level ensures
that the project gains and retains momentum as it progresses. There needs to be the process defined
for senior sponsorship process and key site sponsorship process. Core change team members work
with project sponsor to keep organisational change management issues and ERP project updates on
the agenda at senior leadership meetings and key site sponsors to deliver project updates at scheduled
intervals.
Communication: As with sponsorship, there is a need in the requirement of the organisation for in-
formation–from general awareness at commencement of the implementation, becoming increasingly
specific to the different parts of the organisation as the implementation progresses. Meeting these
information needs will be via town hall meetings, supervisor/manager lunch discussions, newsletters,
websites, videos, etc. There needs to be a formal communications framework in support of the ERP
implementation that outlines the approach for sharing project-related information across the organisa-
tion. The communication framework enables the change team to understand what the relevant mes-
sages are, to whom and how the team will deliver them, and by whom they should be delivered. This
226 Enterprise Resource Planning

framework talks about: What messages need to be delivered to whom, how and by whom? Members
of the extended change team and key site sponsors deliver messages to their divisions/business units.
Local leads provide feedback on communications effectiveness in their divisions/business units.

Supporting Processes
Skills Development (Change management training): This includes things like training strategy;
training needs assessment, etc. Skills development in change management is not restricted to techni-
cal training. Rather, it focuses on growing employees’ understanding of how the ERP implementation
impacts the organisation, its business units, and individuals. The emphasis is on “big picture” strategic
imperatives and their effect on individual roles and responsibilities. Strategy needs to be developed
outlining possibilities for the scope of training content to be covered, the audience that need to be
addressed, activities related to training management, evaluation of training effectiveness, etc. Delivery
of organisational change management related training as a part of end user training. In general, skills
development can include: process training (addresses people’s understanding of how their organisation
operates), impact training (addresses people’s understanding of the ERP impact on the business, e.g.
how ERP creates opportunities for business improvement), ERP training (end user training for the
technology and how it works), skills training (the specific job, team and process skills to work well.
Can even include elementary things like training in the use of a PC).
Knowledge Transfer (Capturing and sharing lessons learned): This is identifying, storing and shar-
ing project-specific information. The purpose of this activity is to create the knowledge transfer team
and develop the knowledge transfer processes. The aim of knowledge transfer is to identify, capture,
and leverage information and experience across the organisation to form a continuous and cumulative
learning process throughout the ERP implementation. The knowledge transfer process ensures that
valuable experience from both internal and external sources is shared and efforts are not duplicated.
Knowledge transfer process includes identification of knowledge resources, methods to capture and
distribute. It is important to define the scope of the knowledge transfer process, who to involve, what
needs to be transferred by whom to who.
Organisational alignment and optimization (Aligning jobs and processes with the new business
environment): This is the process addressing alignment of ERP implementation and organisation. It
is potentially the most complex change management initiative in terms of aligning the new TO BE
ERP processes with new roles, organisation structure and reward process. It will be the change team’s
act to promote and propose such change, but most likely the HR department is to address. Its scope
is huge in impacting organisational structures, reporting relationships, competencies, jobs and per-
formance management systems that must change in order to facilitate the ERP implementation. This
can be made operational by top management, human resource professionals and other organisational
development constituencies. Change team’s deliverable in this is mostly restricted to developing pro-
cess impact maps and job impact reports. Now it is HR and top management’s responsibility to work
on this recommendation.

Summary
Handling change management is crucial for ERP project’s success.
People resist ERP for different reasons – for fear of job loss, for uncertainty regarding new role, fear of not
able to operate the ERP system correctly, etc.
 Change Management 227

First task of change management is to take out the fear factor from people. This can be facilitated by com-
munication, training, power user’s support, help desk support and leadership support.
However, to motivate people it is important to give them better roles, more interesting jobs and design right
incentive scheme. Organisational design initiatives can help here.
Change management needs a team having people with specific change management roles.
Change management activities can change in different phases of the project.
ASAP has a structured change management methodology. Assessment, sponsorship and communication be-
ing core processes. Skill development, knowledge transfer and organisational optimisation are supporting
processes.

Exercise
I. Objective Type Questions
1. What are the three building blocks of successful ERP implementation?
2. What is meant by organisational design?
3. What are the four derivatives of organisational design?
4. What are the five ways to handle fear and uncertainty?
5. How communication methods can change depending on the type of audience?
6. What are the two types of change team an organisation can have?
7. What are the three core processes of ASAP change management?
8. What the three supporting processes of ASAP change management?
9. Who are ERP champions?
10. What is organisational alignment?

II. Descriptive Type Questions

1. Why people resist change? Explain some of the reasons for such resistance.
2. What are the different strategies to handle change?
3. Explain the importance of communication for ERP change management. What are the different possible
communication strategies?
4. How do training and leadership support help in change management?
5. Why organisation design is important for change management?
6. What are the different types of change management roles? What are their responsibilities?
7. How do different types of change management activities change during the life cycle of an ERP project?
8. Explain the three core processes of ASAP change management methodology.
9. Explain three supporting change management processes of ASAP change management methodology.

III. Fill in the Blanks

1. Three ASAP core processes of change management are _______________, _____________ and ______
_________.
2. Three ASAP supporting processes of change management are _______________, _____________ and
_______________.
3. Organisational ___________ is an important element of change management.
4. Organisation design calls for new roles, new __________ ___________, new __________ __________ and
new __________ ______________.
5. Change team is composed of __________ change team and ___________ change team.
228 Enterprise Resource Planning

IV. State Whether the following Statements are True or False

1. Methods and vehicles of communication should be uniform for all.
2. “Fear of ignorance” is the main reason for people’s resistance to change.
3. Key site sponsors and line managers are part of core change team.
4. Identifying change sponsors and change management team is done during project realisation.
5. Change management trainings are conducted during project preparation.

V. Assignments
While change management is most important for any ERP project, most often companies just give a leap service
to this without putting much active effort. Study (Primary and Secondary research) few organisations which had
gone for ERP implementation in the past and note down the following details:
Which activities they had actually done under change management?
Whether they had a separate change team? What were the profile of people in this team? What were their
roles?
Whether the company had any change plan synchronised with the overall project plan?
What communication strategies they followed during the project?
Whether there were any organisational design initiative, i.e. new roles, new job description, new performance
measures and new reporting structures post the project?
 18
Success or Failure of
ERP Implementation Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Reasons for failure of an ERP implementation
Reasons for success of an ERP implementation

ERP project is a massive investment and no organisation wants this to be a failure. In this chapter we will
discuss various reasons for success and failure of an ERP project. These are based on experience of several
companies who had done it rightly or wrongly in the past. While the list is not all exclusive, thirteen im-
portant reasons both of ERP project success and failure are discussed in this chapter.

REASONS FOR FAILURE OF AN ERP IMPLEMENTATION

Some of the reasons where ERP implementations fail are discussed in detail in this chapter.

Poor ERP Package Selection

We had discussed the scientific process of ERP package selection in chapter. However, unfortunately most
of the companies do not follow this kind of approach and go for one ERP-based on their gut feeling that
this will suit them. If a package is selected without doing a proper fitment analysis, there is every chance
that there will be future problems.

CASE SNAPSHOT

A large Steel company implemented ERP successfully in mid 90s. Over the years, the company
bought some iron ore and coal mines to meet their raw material requirement of steel. The com-
pany decided to extend the same ERP operating in their steel units to mine business. Down the
line after four months when the implementation was on the company discovered that this ERP
230 Enterprise Resource Planning

package can not handle typical requirements of mining business like handling logistics at remote
locations, underground safety requirements or handling of hazardous materials like explosives.

However, increasingly companies are getting aware of this and concentrating on going through a scientific
evaluation process before deciding on one ERP.

CASE SNAPSHOT

Arvind Mills, India’s leading textile manufacturer and retailer had selected SAP for their manufactur-
ing business, but had selected Oracle Retek for their retail business as they found each business
has very different business requirement that can be better addressed by separate package.

Inadequate Requirement Definition and Unrealistic Expectations, Scope

If ERP implementation starts without knowing the business requirements clearly or with a set of vague
requirements, obviously it is a challenge to configure the software to suit this. While this is perfectly OK to
start with a few high level requirements, it is important to detail it during business blueprinting.

CASE SNAPSHOT

A Food company started ERP implementation with the vision of “Automation from field to fork,”
i.e. automation of every processes of crop management starting from the field to getting into
factory, processing, distributing and finally reaching customer’s table. This high level requirement
was never detailed during pre-implementation and project scoping stages. Few months down the
implementation, the company discovered that predicting crop growth pattern, agricultural fore-
casting and a good part of crop management processes can not be addressed by the ERP solution
and for that matter by any ERP solution and this is a domain of decision support systems. Trying
to use ERP forecasting module for agri forecasting was a complete failure.

Investment without ROI Justification

It is important that every ERP investment decision is made with proper ROI justification. Sometimes after
heavy investment in ERP solution, the company faces a challenge of justifying it. It is not enough just to
make a good business case to start the project, the business case need to be monitored when the implemen-
tation is complete to say whether really those business benefits promised at the beginning of the project
are really achieved.

CASE SNAPSHOT

A greetings card company, a subsidiary of a large business house having several lines of business had
made heavy investment in ERP and other enterprise applications. Beside all the basic ERP modules,
 Success or Failure of ERP Implementation 231

as the company sells e-cards online and that’s why wanted to go for CRM – Internet selling, the
company at any point need to have a large numbers of card designs as each card is unique – for
this they decided to go for a PLM solution. As greeting cards was a new subsidiary and had not
reached a break even point, it was decided that funding for this implementation will be done by
corporate. Few months down the line, the company discovered that this is extremely challenging
for them to manage such a huge implementation spanning across ten ERP modules, PLM, CRM,
etc with the very small management team they have. The group CFO discovered that the amount
of investment the greeting cards business is going to make in terms of hardware, licence and con-
sulting for this massive implementation is close to half of its turnover and it is difficult even get a
payback justification within next ten years. After six months down the implementation, the scope
was drastically reduced; modules were bought down (just to have ERP modules to have basic
transactions in place) and implementations for CRM, PLM, etc were stopped. There was lots of
unnecessary wastage in terms of money and time for the company and the project team.

Not Able to Support Changing Business Needs

A company does not invest in ERP solution, just to cater today’s business needs, but to meet tomorrow’s
challenges. The challenge frequently is that most often these challenges are not known. The challenges can
come from different dimensions like:
The lines between industries are blurring: Increasingly manufacturing companies are getting into
service business, traditional consumer goods manufacturing companies are getting into retailing, metal
companies are getting into mining to control their raw materials needs, etc. If ERP selected today
does not support tomorrow’s business, it brings additional challenges in terms of going for altogether
a new ERP solution, integrating that with the earlier ERP, maintaining two different applications, etc.
This is one area where large ERP vendors like SAP score as they have industry-specific solutions for
most of the leading industries.
The lines between countries are blurring – The whole world is becoming a global village: Compa-
nies operating in one country may start business in another country tomorrow – that means meeting
a new set of legal and financial requirements. In several implementations companies started with one
ERP discovered after two years that it is not in a position to meet the business requirement when they
entered into a new territory and had to migrate to another ERP. Again one area where leading ERPs
like SAP or Oracle scores.
Industry itself is evolving: Requirements within an industry itself is changing over time. Today “food
safety” had become a global issue for food industry or “Product track and trace” had become very
important for logistics or pharma companies, SOX compliance had become mandatory for certain in-
dustries in certain countries – these were not there a few years back. Today’s solution need to support
these changing business needs otherwise the implementation will be a failure.

CASE SNAPSHOT

A large utility company had gone for an ERP implementation and the implementations for their
power plants completed successfully on time. After six months, the company bought over some
captive coal mines that supply coal to their power plants. While trying to roll out the ERP solu-
tion to mines, the company had a challenge and was not successful in rolling out. They had to go
232 Enterprise Resource Planning

for a separate ERP for their mining business and the vision of their ERP project “One information
system across the integrated enterprise” were defeated. However, owning mines in long term
was always company’s future plan and while doing their ERP selection and building the solution
they should have taken this long-term goal in mind.

Top Management Support Lacking

Often, lack of support of the top management becomes the most common reason for ERP project failure.
This is something essential throughout the project life cycle. This kind of support should not be restricted
just to “lip support”. However, ERP implementation need something much more than this in terms of tak-
ing critical decisions during ERP implementation on time as and when needed, driving change across the
organisation, taking fear out of people (for things like possible job loss after the implementation is over),
regular communication with the team and guiding during escalations, etc. Often, organisational politics
among few powerful wings can become a bottleneck here (the sales team wants the system to be configured
in a particular way that meets their requirement, but counterproductive to the interest of manufacturing team
and to the overall project interest). These are the areas where if top management does not take control of
things, there is a chance that the implementation will fail. There are instances where powerful wing in the
top management wanted to sabotage the ERP project as the project is against their interest.

CASE SNAPSHOT

This is a story of a large public sector organisation. The company started ERP implementation with
much fun fair. Down the line after few months of implementation, the core team was regularly
objecting the top management that they were not getting regular business inputs and, especially
from few areas like finance, accounting, materials management, supplier payment processes, etc.
After repeated requests to top management, there was just one stakeholder meeting. Later on
the project was cancelled without showing any business reason. Years later, it was revealed that
as ERP systems bring transparency to the organisation, some people from the core team were
scared with the new system. They tried their best to sabotage it. Top management also did not
change gear to support the implementation (may be some of them also had wrong purpose).

ERP Core Team have do not have Right Resource

Again a typical challenge for ERP implementation is that the core team for implementation is not made up
of people who can give right business inputs. Obviously, sales team will not like to leave their best sales guy
or maintenance team will not like to leave the person who is first called if there is a machine breakdown for
the ERP implementation project which will go on for next 12-24 months. However, these are the people who
are, perhaps, best suited for the core team. A lot of projects got into problem as the core team was stuffed
with lots of part time members (for them ERP implementation is one among their ten other responsibilities)
or with members who recently joined the company (so they were not having much day to day responsibili-
ties and can be spared into the project). This is one area where top management’s intervention is required
to take out the best people without which the project is at risk. The risks are in two folds:
Core team members were not in a position to give business inputs and that’s why the implementation
team need to run around to lot of other people within the organisation that definitely put challenge on
project schedule.
 Success or Failure of ERP Implementation 233

The bigger risk is that the core team member had given wrong inputs during blueprinting based on
which system was designed and configured. Several moths down the line in the project, the end users
of ERP system indicated that this is something not as per their expectation or this is something not
meeting their business requirements. This may be a disastrous for the project – opening up the busi-
ness blueprints again, resulting in serious cost and time overrun for the project.

User Acceptance Issues

One of the major reasons of ERP failure is that the new system is not accepted by users. This is often con-
sidered as a change management issue. Actions like involving users early enough in designing the system,
explaining them that how the new system will help them better to do their current job, etc can helps users to
own the system and quick acceptance issues. Often there are sophisticated ERP functionalities which were
implemented and were not ever used as users were never convinced that whether this will really benefit
them or “what’s in it for them?”

CASE SNAPSHOT

A large consumer goods company had implemented a sophisticated supply chain planning and
optimisation application that helps the company to get an optimised production, distribution and
material plan. The system was implemented after months of effort of business requirements un-
derstanding, simulation, etc. However, once the system went live it was never popular with the
end users who were more confident of doing their planning in old excel sheets which they built
over the years putting together all their experience. It was difficult for them to leave those excels
sheets as they were the people who designed it. Moreover, the sophisticated operations research
(OR) algorithms that the software uses were never very clear to the users, none of whom came
from an OR background. This application had a functionality where after system had given the
optimised plan, the user can change it based on their intelligence. This was the only functionality
liked by the users, who used to never look at the optimised plan, but used to change it 100%
according to the plan they had derived based on their excel files.

Employees Resist ERP Implementation

As discussed in “Change management” chapter, this can be an important bottleneck for ERP implementation.
The reasons can be fear of losing job, fear of not able to perform the task in the future, fear of losing im-
portance, etc. Top management can play a crucial role here in terms of effective communication throughout
the project life cycle, involving people, etc. This is discussed in detail in Chapter 17.

Training Issues for the Team

As emphasised throughout this book, training is a core issue of ERP implementation. If core team and end
users are not trained in the system properly, they can not use it. Often companies cut budgets on training
front and face challenges down the line.

Poor Communication
Poor communication in the project can result in lots of misbelieve among people in the new system, can help
in spreading rumours and can cause failure of the project. Regular and consistent communication throughout
the project from top management and at different levels is important for project’s success.
234 Enterprise Resource Planning

Project Viewed as an IT Project

Frequently ERP projects are viewed as IT projects because the entire organisation think ERP as another
software and to be handled by the IT team. This view could be disastrous as ERP is a business application
and business inputs are critical for its implementation. History had shown that ERP implementations when
driven by business are always more successful than when driven by IT team who any way does not control
any of the line functions of the organisation. While IT resources are clearly key participants, ERP systems
should not be viewed as IT projects.

Customising the Software too Much

ERP software comes with a set of best practices for industry and processes. If the software is customised too
much to meet the company requirement, there is a high chance that the company will just automate what they
are currently doing and will not actually use any of the best practices that comes with the software. If every
process is not changed at all and only automated then from where business benefits (like higher inventory
turn, better planning accuracy or improved customer service) will come? Justifying the ERP investment,
business case and ROI itself can be a challenge.

Too Tight Project Schedule, Miscalculation of Time and Effort

“Quick ERP implementation” is the recent buzzword by all ERP consulting companies and they are promising
to complete implementation within three to four months and some even are talking about implementation in
few weeks. While everyone wants to do it fast, it is important to understand that there is a set of activities
that need to be done during implementation and crashing the time for each of this beyond a point can af-
fect the quality of the deliverable. Some are even talking about completing blueprinting in three weeks, no
effective process redesign can happen in such time-frame. Even for consulting companies while there is a
methodology that talks about quick implementation, most of them have very few success stories where ERP
implementations could be completed successfully in such kind of time-frame. Frequently, with this kind of
time-frame companies compromise on training, designing a blueprint without any actual process design and
load junk data in the new system straight from legacy application without any cleaning – for one simple
reason that the project schedule does not permit. Even if the project completes on time, after a few days,
the companies discover that actually it is a failure as there was no actual business benefits.

High Turnover Rate of Project Team Members

This is often a problem when people in the core team both from business side and consulting side changes
frequently – that need frequent knowledge transfers (which is never 100% complete), more meeting with
the business (as the business requirements which were explained to the earlier consultant had left the team
now) and this definitely affects project schedules. Before critical milestones of the project, absence of criti-
cal project team member can actually derail the project totally. For example, integration manager left the
project just before integration testing, manager responsible for data migration had left the project before
data migration starts or project manager left the project just before the planned Go Live. Losing these roles
multiple times or substituting lost roles with less capable replacements can dramatically increase risk for
the project.
It is also important that some of these team members are present at least during first phase of support
just after go live. If none of them are present and the entire support is handled by a new team who does not
know what discussion went behind doing a particular blueprint design or a particular configuration – the
risk is higher.
 Success or Failure of ERP Implementation 235

REASONS FOR SUCCESS OF ERP IMPLEMENTATION

Reasons for failure ERP implementation are discussed above. So, for an implementation to succeed, obvi-
ously these things need to be taken care of which means:
ERP package selection need to be well-thought, understanding company’s business requirements and
company’s long-term goals.
Expectations from the ERP system need to be realistic and properly documented in the requirement
definition document.
Investment in ERP needs to have proper ROI justification so that it does not reach a situation where
an ERP system can not pay for itself.
ERP systems are not implemented to cater today’s business requirement only, but also to cater the
needs of future, i.e. supporting the company’s business needs which will emerge in next few years.
An implementation can be defined as a success, only if the implementation meets this requirement.
Support of top management is of utmost importance for any ERP implementation to succeed.
Company’s best brains need to work along with the consultants to design tomorrow’s business processes
and information system. Having the right representation from the business is extremely important for
an implementation to succeed.
User acceptance is critical as without that even if the system goes live, it will never be used by end
users. While user acceptance testing is a critical milestone from the project perspective, involving
users early in the project, taking their inputs while designing the system and finally training them in
the new application goes a long way for success of ERP implementation.
Handling employee resistance is critical for implementation to succeed. It is important to address their
concern and take out fair from them.
Training people at every level, i.e. giving training to senior leadership, core team, power users, and
end users, as per their need is important for success of the implementation.
Communication is essential for success of ERP. While senior leadership communication to every em-
ployee in the organisation goes a long way to address concerns of employees, regular communication
throughout the project ensures that rumours do not spread, everyone in the organisation knows what
is going on in the project and how that is going to change their life in future.
ERP project should not be viewed as an IT project, but as a business project that involves business
people, need business inputs to succeed and intended for business benefits.
For an ERP project to succeed it’s also important to minimise developments and customisation in the
software and too the extent possible use the standard software (through configuration) and standard
best practices business processes offered as part of ERP. Developments and customisation make future
upgrades difficult.
The project plan and duration of the project need to be well planned providing adequate time for each
activity. There is no point in going live quickly having hundreds of open issues, having no time for
process design, training or data cleaning.
For projects to succeed, the core team needs to be full time, present throughout the project duration
and a part of them need to be a part of the support team. While some turnover can not be stopped,
it is important to do a risk mitigation plan for all critical positions and to identify a second line for
them early enough so that if there is a turnover before critical milestone of the project, someone can
take over quickly and the overall project schedule is not suffered.
Beyond these obvious ones, there are few other things that need to be taken care of for success of ERP
implementation. These are discussed below:
236 Enterprise Resource Planning

How You Define A Success—Define Measures

For some people the success of ERP project means the date announced earlier for the system to go live
was never postponed. For some people the project is successful, if it was completed within budget and for
some others this is successful, if it had achieved desired business benefits as promised in the beginning of
the project. It is important that at the beginning of the project, you define the measures by which you can
assess, whether the project is a success or a failure. Without this, the project success will be a “matter of
judgment” and differ from person to person as some people within the organisation will tell the project as
a success and some others will tell the reverse. So, this becomes a total subjective assessment. These mea-
sures or KPIs need to be measured once the project is complete and see whether the project had delivered
on result. Some examples of KPIs can be: the project will reduce cash to cash cycle time by 30%, will
improve inventory turn by 25% and will make forecast accuracy better by 10%. The project will be defined
as a success if it completes within time and budget (No delay in project duration and no overrun on budget
front) and delivers these business benefits as described earlier. Otherwise, it is a failure. All stakeholders
within the organisation should be on the same page about this fact.

Managing Project Scope

A chronic problem with most of the ERP projects. Projects start with lot of motherhood objectives and very
little time spent on detailed project scoping. This is one of the reasons scoping is discussed in detail in
Chapter 7 and nine lever of scoping is a scientific way of defining project scope covering every aspect of
the project. This is a clear guideline of what is supposed to be achieved in the project, what consultants are
supposed to deliver, what is expected out of the core team and most importantly what will be not delivered
as part of the project. The last part is sometime the most difficult part. For any change to this scope, there
need to be separate change request and if the impact of this change is something that affect the overall project
timeline and cost, these changes are not encouraged or need to be approved by project steering committee
or the project sponsor making him fully aware that the project timeline may be impacted for this change.
Numerous ERP project were never complete within time and budget because of large volume of change
requests during project life cycle. It is important to remember that if project timeline and budget changes,
the ROI calculation may go for a toss. It is always better to deliver on an agreed scope first and then take
up new items.

Requirements Prioritisation
Any ERP project will start with a huge list of requirements. A good number of items in this laundry list can
become a wish list. It is important to prioritise this list in “Vital”, “Essential” and “Desirable” where most of
the wish list items can be of “Desirable” category. Some companies prioritise the list of vital and essential
among what is required first, what next and so on. For lots of “Desirable” items expectation, management
becomes important where the project team needs to explain business that the benefit expected from this
feature does not justify investment. The old 80-20 principle may hold good, i.e. the project should first focus
on those 20% requirements that have 80% business impact.

Have Early Success and Pilots

An ERP implementation can continue for 12-24 months and at times for large implementations this time
frame can be much more. Sometimes waiting for 2-3 years to see any result is frustrating both for the core
team and all project stakeholders. It is important to show some early benefits that make everyone in the
organisation interested in the project and can motivate the team. Pilot sites is a good idea and some organi-
 Success or Failure of ERP Implementation 237

sations take up a relatively easier site for pilot where solutions can be implanted fast and benefits can be
shown. This also gives the project team the chance to gain experience from a real life implementation and
ensure that mistakes done here does not reoccur.

Have Good Relationship with ERP Vendor and Consulting Partner

This is extremely critical for a project’s success and often forgotten by many companies implementing ERP
solution. The relationship gets strained on small commercial issues or issues like minor scope change. It is
important to remember that relationship with ERP vendor is not about one transaction where you paid for
the software and the vendor had installed the software and the transaction is completed. Vendor’s help is
required throughout the life cycle of implementation and also during the entire application maintenance life
cycle to support any bug in the software, to upgrade the application or providing guidance on any performance
issue with the application. Similarly, consulting partner is an integral part of the implementation team and
is crucial for the project’s success. If the relationship is good, a partner can go out of his way to make the
things happen for the company and can support the things not mentioned in the written contract.

Good Project Management

Like any other project, project management is important for ERP project success. However, this becomes
more important here simply because of size – an ERP project can run 12-36 months, can consume huge
amount of organisation’s resources and touches almost every employee in the organisation. A good project
management team can only ensure that the project is completed on time, within the desired budget and deliver
the right scope and business benefits. Project management is discussed in detail in Chapter 7.

Having Clean Data in the System

Often this is one area which gets compromised in an ERP project as data migration being an activity during
go live preparation stage when everyone in the organisation is in a hurry to go live after working several
months in the project. There is much pressure from top management to go live on the date specified and
often there is a tendency within the project team to take some shortcut – extract data from legacy systems
and quickly upload in the new ERP without any cleaning or data validation or populate the ERP system just
with mandatory data fields (without which the system will not function) and do not provide information on
other data fields. Loading junk data can be disastrous and the unfortunate part is that the project can very
well go live with this, the effects can only be understood months later when people do not believe informa-
tion provided by the new ERP system is unusable as most of it is junk. While data migration is an activity
during go live preparation, cleaning and validating data i.e. data preparation need to start much before as this
can be a very laborious activity because of data volume. Often in data cleaning and validation, consultants
can not do much help and need to be done by the core team who understands the business and data better.
Without clean data, there is a high chance that the system will become “garbage in and garbage out”.

Quick Decisions
Lots of ERP projects suffer because process owners or steering committee had not taken decision on time
or is taking months to take a decision. There will be crucial decisions that need to be taken during the entire
life cycle of the project for example which TO BE process design is better and to go for, whether to accept
a change request or not, which site to be taken as first pilot site, etc. Often the responsibility is lying with
the business team and any delay here can affect the overall project schedule.
238 Enterprise Resource Planning

Test the Solution Thoroughly

Test the solution thoroughly at every level by core team, by power users and by end users to ensure that
it is doing the right things as desired. ERP implementation has different levels of testing like unit testing,
integration testing, user acceptance testing, stress testing, volume testing, etc. Any shortcut here can result
in the solution not meeting user’s requirement and users will not use the system even if the go live happens
smoothly.

Ensure that the Project has Sufficient Budget till the End
Numerous ERP implementations closed in between as the organisation had exhausted budget for the project.
It is important to do the budgeting exercise carefully and to consider all possible costs during the exercise.
Any budget ideally should also have some reserve and contingency built to ensure that if there is a little
time or cost overrun, the project can sustain. If there is a substantial time overrun, it is obvious that the
budget will be exhausted and any budgeting exercise can not take care of this kind of eventuality. However,
10-15% overall contingency is something that should be planned as their will be always some unexpected
change requests, last minute problems in data migration which was not planned earlier or premium consult-
ing support required to sort out a technical problem that came up during integration testing and which is
difficult to estimate, etc.

Efficient Risk Management

Succeeding in ERP projects will also depend on how effectively the project risks are managed. There can
be different examples like: Whether there is a back-up plan for each critical resource of the project in case
they leave; Is there any disaster recovery plan in place in case there is a hardware crash and data loss just
before going live; Is there a Plan B ready if go live can not happen as per the earlier plan as go live audit
team thinks some of the critical projects issues are still open, etc. Projects having very tight schedule and
larger scope running across several locations can be of high risk. Managing risk effectively is critical for
project success and is discussed in detail in Chapter 13.

Process Owner’s Involvement

While it is common to define few senior managers as process owners in ERP project organisation structure,
the fact is their actual involvement in many projects is always a matter of concern. These roles are not
typically full-time roles and in a relatively large organisation these are extremely senior positions (like vice
president – manufacturing, director – sales, executive vice president – finance, etc). For these extremely busy
guys – ERP implementation is often among hundred other initiatives going on in the organisation. This often
results in that these people are not able to attend planned meetings, delegating the decision making to junior
people in the team who often do not have a holistic view of the process. Success of an ERP implementation
will depend on how actively process owners are involved in designing the process, taking process decisions,
testing the process as per user’s confidence and finally training all future users in the new process.

Who Owns Business Benefits

Business benefits of an ERP implementation starts after the implementation is complete and can occur for
next several years. Once the project is complete, it needs to be ensured that someone really monitors every
month that how much business benefits is really happening (as per the earlier promise during business case
building), if there is a shortfall, what are the reasons for that, what actions need to be taken to take care of
the shortfall and to report senior management regularly on these aspects. Business benefit measures often can
cut across several departments and processes. For example, improvement in inventory turn means improving
raw materials inventory (under procurement team’s control), work in process inventory (under manufactur-
 Success or Failure of ERP Implementation 239

ing team’s control) and finally finished goods inventory (under distribution – logistics team’s control). This
is one of the reasons that sometimes, it is difficult to find an owner of these measures. The company can
go for a focused team doing this exercise. Sometimes, companies engage some external auditors also to do
these measurements and someone within the company need to own these benefits and need to be answerable
if the same is not achieved as per promise.

Summary
Success or failure of ERP projects can be attributed to variety of reasons. In this chapter we discuss a few of them.
Reasons for failure of ERP project can be attributed to variety of causes like: Poor ERP package selection,
inadequate requirement definition, unrealistic expectations, investment without ROI justification, package
not able to support changing business needs, top management support lacking, not having right resource,
user acceptance issues, employees resistance, training issues, poor communication, project viewed as an IT
Project, customising the software too much, too tight project schedule, high turnover rate of project team
members, etc.
Reasons for success of ERP project can be attributed to reasons like: defining measures for success, manag-
ing project scope effectively, requirements prioritisation, having early success through project pilots, having
good relationship with ERP vendor and consulting partner, good project management, having clean data in
the system, quick decisions, thorough testing of the solution, ensuring sufficient budget for the project, ef-
ficient risk management, process owner’s involvement and identifying business benefits owner.

Exercise
I. Objective Type Questions
1. What can be the user acceptance issues in an ERP project?
2. Why ERP projects should not be viewed as an IT project?
3. Why customising ERP software too much is not advisable?
4. Why is it important to define measures of success in an ERP project?
5. How requirements should be prioritised – in which three categories?
6. Why piloting is important in an ERP project?
7. Why is process owner’s involvement important?
8. Who ensures that ERP project is achieving its desired business benefits?

II. Descriptive Type Questions

1. What are the reasons for failure of an ERP implementation?
2. What are the reasons for which an ERP implementation can turn out to be a great success?

III. Assignments
Do some secondary research. Try to find out the reasons why five large ERP projects failed in the past. Also try
to find the reasons for great success of some of the ERP projects. What had the successful project teams done
differently from others?
 19
Application Support
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Support cycle
Transition
Steady state support
Upgrade
Different level of support
Service levels and SLAs
Service desk
Vendor support
Support offerings from SAP
SAP’s tool for maintaining application – Solution manager
Different support models and outsourcing support
Support models
Outsourcing support – Pros and cons
Support roles
Support methodology
Measuring ERP performance and continuous improvement

INTRODUCTION
Application support starts after the system goes live and continues till the business uses the system. Success of
an ERP implementation depends on how effectively the system is used by large number of users and business
benefits are achieved. While “Go Live” for a project is a milestone for the completion of implementation,
it is false to believe that the ERP journey ends there as during the entire ERP lifecycle, there will be new
requirements needing new configuration in the system, the system needs to be upgraded at regular intervals,
new people joining the organisation need to be trained in the system, regular refresher courses need to be
conducted for existing employees, etc. In this chapter some of those important topics are discussed.
 Application Support 241

SUPPORT CYCLE
Figure 19.1 explains a typical support cycle. This cycle can be broken down into the following phases:

Phase 1–Support Planning

Support is the stage after a project goes live, but planning for support activity starts much before go live date
as it needs time to negotiate with support vendor (if the support is outsourced), putting the support team in
place, making a support desk operational and post project planning for people currently in the implementa-
tion team. For some companies this starts as soon as the project entered the realisation phase. Transition
from the implementation team to the new team also needs to start now.

Phase 2–Transition
During go live while the implementation team is busy with making a hassle-free transition of the organisation
to new processes, it is important for support team to get the necessary knowledge transfer, documentation,
etc so that they can support the system better when the implementation team leaves. Any project typically
goes live with a set of open/pending issues. It is important to get a clear decision on pending issues, who
will close these and by what time-frame this will be closed.

Phase 3–Hypercare
The stage just after go live is called hypercare as during this stage more problems are expected than usual
as the users are first time using a new system. Typically during this stage users face lots of authorisation
problem, i.e. they do not have necessary authorisation to do transactions in system, etc. Support team need
do handholding for users, retrain them on specific processes/transactions as required. If they support happens
in onsite offshore mode – more onsite presence from support team is expected at this stage for knowledge
transfer, increased number of ticket support and lastly to know the actual system business users whom they
will support during the entire application life cycle. Depending on project size, a typical hypercare stage
may vary between 2-8 weeks.

Phase 4–Steady State

This is the normal support cycle and typically the longest duration in application life cycle. This continues
till date the business decides to upgrade the application to the next version. Support team carries on typical
support activities at this change like managing incidents, managing change requests, running the regular
background jobs, system monitoring, etc.

Phase 5–Upgrade
Once the application comes to the end of its life cycle, the same will be upgraded to the next version.
Sometimes, the upgrade can happen much before the end of life cycle itself if the business thinks that the
next version has lots of good functionalities which is useful for the business and the application needs to
be upgraded right now. Application upgrade is a separate project and depending on the complexity, the
duration and effort varies. Typically pure technical upgrade is fast but does not give any business benefit
whereas functional upgrades give business benefits. An upgrade project involves almost everything you do
in a typical implementation project (like business blueprinting, configuration, testing, development, etc) but
for a shorter duration.
242 Enterprise Resource Planning

Fig. 19.1 Support Cycle

Once the upgrading is complete, the next support cycle starts for the same application in an advanced
version and goes through the same stages like hypercare, normal support, etc. till the application is again
upgraded to the next version.
The important phases of support cycle are now discussed in detail in this chapter.

TRANSITION
Transition refers to a set of activities relating to the transfer of responsibility for work from one organisation/
a set of people to another organisation/a new set of people. This is a stage typically just after the project
went live and the responsibility gets transferred from implementation team to a new team which will support
the application in future. The transition can be:
To a new organisation (for example, the company who is implementing the ERP solution has selected
separate consulting companies for implementation and supporting the application)
To a new team (for example, the company who is implementing the ERP solution has selected the
consulting company for implementation and supporting the application and after the implementation
is over, the consulting company is bringing a new team for supporting the application. This can also
be the case when the company implementing the ERP solution got the implementation done by an
in-house team and now putting a new team for support)

Activities in Transition Cycle

Figure 19.2 shows a set of activities in the transition cycle. The main objective of transition is a smooth
handover from the project team to the new team which will run the application in future and ensuring that
 Application Support 243

Fig. 19.2 Transition Activities

the new team is properly equipped to run the operation in future and to stabilise this process at the earliest.
Types of activities in a typical transition are as follows:
Knowledge Transition The most important activity during transition is when knowledge gets transferred
from the implementation team to support team. Knowledge can be for things like process design documents
(business blueprints) and rational behind designing a particular process in a certain way, logic for develop-
ments (functional specification and technology specification), results of different testing (test script and test
results), integration issues, application performance related information, etc. Transition needs to ensure that
these things are properly documented and not just remaining within the implementation team. Improper
knowledge transfer is one of the major reasons for many post-implementation issues while running the
application. This is more important when implementation and support is done by two different companies.
Project Documentation Transition Different documents created during the project (business blue-
prints, development specifications, business logics, test documents, issue database, etc) need to be stored
properly and to be handed over by the implementation team to support team. Different companies uses
document management applications for this. This is one of the key deliverable for implementation team to
support team and again something more important when implementation and support is done by two dif-
ferent companies.
Human Resource Transition During transition, planning need to be done for new roles of the exist-
ing project team members. For consulting team, the consulting company plan for them and this is relatively
simple as for consultants this is a part of life, i.e. working for a project, completing it and then again getting
redeployed in another project. However the challenge is mainly for core team who had perhaps came from
different locations to be part of the project and are out of their normal functional role for last 9-18 months
(depending on the duration of the project). These super users need to go back to business or the organisation
need to provide new roles to them. The organisation implementing ERP need to plan for them and actually
244 Enterprise Resource Planning

this planning need to start much earlier before transition. In some cases, some of them can continue with
the support team, in other cases new roles for them need to be found out. Some companies had seen that
after a life cycle implementation, the core team member’s profile had become hot profiles in job market and
there is a risk of high attrition, this had forced some companies even to take a bond from team members
stating that they will serve the company for X number of years post implementation till the system stabilises.
Another challenge at transition stage is to find out the right profile of people for the support team who can
take over from implementation team.
Issue Transition In any typical implementation on the date of go live, there will be lot of open is-
sues. There need to be a plan for reviewing these issues at regular interval and closing these issues over
an agreed time-frame. There need to be a clear understanding that who will close these issues, whether the
implementation team or the support team.

STEADY STATE SUPPORT

This is the normal support cycle and during this phase, support team carry on typical support activities like
managing support tickets raised by different users, managing change requests (changes in business process
and for that related configurations in ERP), running the regular background jobs, system monitoring, etc.
Table 19.1 shows typical activities at this stage:

Table 19.1 Support Activities

Support Activity Group Support Activities

Regular system administration and technical Daily database administration
infrastructure management System performance monitoring - statistics collection - analysis
Managing job schedules
Managing technical infrastructure
Change management Develop and implement change control procedures
Change request management
Applying regular patches, notes, etc
Managing regular tests (while implementing changes)
Transporting changes from development or quality environment
to production
Organisational change management Ongoing organisational change management
Develop new ways of working
End user application support Provide ongoing support to end users – Manage and resolve prob-
lems and issues
Root cause analysis of problem
Perform evaluation of production support effectiveness
(Contd)
 Application Support 245

(Contd)

Knowledge management Deliver continuous end user training

Evaluate learning effectiveness
Document lessons learned and best practices
Solution database
Continuous improvement and ongoing KPI Plan for continuous improvement
management Value realisation
Measuring business benefits

Perform Regular System Administration

One of the main expectations at support phase is to keep the system uptime high and this needs regular
monitoring of system performance, i.e. collecting data on different system operating parameters, analysis
of the same and taking corrective action as necessary. This also calls for daily administration of application
database, regularly running a set of utility jobs that clean logs, indexing the database, etc and managing
the technical infrastructure. These activities ensure that system downtime is minimal and it gives optimal
performance.

Change Management
Changes are part of the life cycle of any application. There can be different needs for change like:
The software vendor has provided a new patch for fixing a bug in the application
There is a new business requirement which has emerged and needs new configurations in the soft-
ware
As a continuous improvement initiative, some system parameters need to be modified
Figure 19.3 explains different roles in change management process. A typical change management cycle
is explained in Figure 19.4 and it works like this. A business user (for a new business requirement or for an
enhancement of existing business process) or a technical team member (for things like upgrading the system
to latest patch level) asks for a change. This request is validated and business impact of this is analysed by
a change management governance body. Once this change is approved, change is first done in development
system. Now the impact of making this change on related business processes need to be thoroughly tested
in quality assurance landscape. Once the testing is successfully completed and the test results are approved
by change management team, the change is transported ultimately to production landscape. This change is
updated in business process documents (in case this is a functional change) so that the document is not far
from what does actually exist in the system. The cycle completes at this stage. Generally this process is
facilitated by the help desk.
Figure 19.5 shows how this change moves across the solution landscape across different environments
i.e. development, quality and production.

Organisational Change Management

This is related to managing softer issues of change. An ERP system necessitates a new way of doing the
work. The support team needs to ensure that the users are actually following this new way at the ground.
This is a slow process and all these changes do not happen as soon as the implementation is over and the
implementation team has left the project site. Support team may need to provide users regular training or
handhold them to ensure that new work practices are followed.
246 Enterprise Resource Planning

Fig. 19.3 Change Management Process–Roles

End User Support

This is regular support to end users in the problems they are facing while using the system on day to day
basis. Generally this process is supported by a help desk or service desk software where users log a ticket
and depending on skill, the ticket get assigned to one of the support team member who works on it and
may get in touch with users if further information is needed and ultimately solves the ticket. In some cases
these tickets may get assigned to the ERP vendor itself. If this issue is regularly occurring, then the sup-
port specialist is supposed to do a root cause analysis of this problem and provide a permanent resolution.
From time to time it is important to measure the effectiveness of support by getting data from end users
and measuring their satisfaction.
 Application Support 247

Fig. 19.4 Change Management Cycle

Fig. 19.5 Change Cycle

Knowledge Management
Delivering continuous end user training is important for successful usage of any ERP system. New people
join the organisation; existing people need to be trained in new functionalities of the solution. Solutions for
recurring problems faced during support phase need to be updated in a solution database which over the
time helps in better self service, i.e. employees can look into the database and solve the problem themselves
and will not need any help from a support specialist. This helps in reducing the number of issues over the
time.
248 Enterprise Resource Planning

Continuous Improvement and Ongoing KPI Management

Continuous improvement is the most important part of an effective support. Year on year, the number of
issues should come down, cycle time to solve an issue should be shortened and there should be continuous
activities to improve the business processes continue. This needs measurement of a set of KPIs on a regular
basis. The measurement results should be compared with the target values. If they are not satisfactory, ap-
propriate activities to improve the business processes should be defined and realised.
Grouping Support Work based on Frequency Support works can also be grouped based on fre-
quency. There are some support activities which need to be done on regular basis while some are done on
weekly or monthly basis.
Example of regular support works:
Change management (Transporting changes/modifications from development to QA to production
server)
Batch job management/job scheduling/background jobs parameterisation and processing; monitoring
jobs
Security management and authorisation support/user administration – creating, changing and deleting
users
Incident management
Problem and change management
Interface monitoring
System monitoring and ensuring system availability
Database administration
Back-up management
Patch management
File system management
Performance tuning
Example of periodic support works
Disaster recovery services
Archiving
Data loading (Loading of production or test data)
Enhancements
Root cause analysis
In some companies beyond application even infrastructure is supported by the same support team. Activi-
ties under infrastructure support can be very different from application support as follows:
Wide Area Network (WAN) support and Local Area Network (LAN) support
Supporting PC
Server and infrastructure hardware support
Operating system support
Supporting file/print server/printers/scanners
Database support (monitoring table space, logs, adjusting database profile parameters)

UPGRADE PHASE
Upgarde is a part of any application lifecycle. Every application is supported for a limited number of years
by application vendor and before this life cycle ends, the application need to be upgraded to the next release.
Upgrading an application can have several pros and cons as shown in Figure 19.6 and as detailed below:
 Application Support 249

Fig. 19.6 Upgrade—Advantages and Disadvantages

Upgrade Advantages/Benefits
The advantages of upgrading an application are:
Application Vendors Stop Supporting the Application In most cases, this is the main reason
which drives upgrading. Leading enterprise solution vendors like SAP and Oracle supports an application
release/version for a specified number of years (in case of SAP, it is 5 years) under standard support and
some enhanced period at additional charges (For example, SAP offers two years of additional support at
increased fee) and beyond that the maintenance charges increase drastically. That’s why most of the custom-
ers like to upgrade their software versions within this specified window of time and thus avoids the risk of
increased support fees in later years.
New Functionalities The latest version comes up with new functionalities which can be useful. For
example, SAP in last few years has come up with many industry-specific solutions. A client from specific
industry who is in older release may find much of these functionalities very useful (For example, a SAP
R/3 V 4.6C client from oil and gas or auto industry may find IS Oil or IS Auto solution in ECC 6.0 version
very useful for him.
Another reason can be a particular functionality which used to be met through development had become
part of standard in upgraded versions. As company specific developments are not supported by ERP vendors,
in lot of cases companies found it useful to move to the upgraded version as the same functionality is part
of standard now and supported by application vendor.
New Version Meets Newer Compliance Requirements Compliance requirements are something
which a company need to adhere to be in business. SOX compliance, HIPAA compliance, compliance to
VAT is example of some of these compliance requirements. These requirements keep coming and always
a part of the latest version of the application. If the application is not upgraded, the only option that the
company has is to develop these which is a costlier option than the upgrade.
Upgraded Version is on Better Platform and Compatible with Newer Offerings from the
Vendor Upgraded version on better platform can provide benefits to the client in terms of flexibility in
developing application and better maintenance. For example, SAP’s Net Weaver platform offers benefits like
SOA based application development to the client over its old non-net weaver application platform.
250 Enterprise Resource Planning

Upgrade Disadvantages/Costs and Risks

The disadvantages of upgrading an application are:
Cost of Upgrade An upgrade is a project in itself and depending on scope, the cost varies. For example,
for a pure technical upgrade the effort will be only limited to upgrading and then testing of scenarios, i.e. to
ensure that what was working in earlier version are also working after the upgrade. For a functional upgrade,
the effort may be much higher as there need to be a business blueprinting exercise, additional configuration,
some more developments to make the new functionality of new version suitable for company, etc. Except
license cost, an upgrade involves almost every other cost of an implementation project for a shorter time
period, i.e. consulting charges, may be additional hardware, cost of internal team, training the team in new
version, etc. Sometimes this may be a significant one and prevent lot of companies to go for an upgrade
without a strong business case.
Business Disruption Upgrades need a downtime of system and depending on the complexity of the
upgrade this may be for longer periods. Though typically changeovers are planned during weekend, some-
times it can prolong and affect critical functions like customer invoicing.
Problems with New Release It is expected that the new release will have more number of bugs and
will take time to stabilise. This is one of the reasons why many companies do not like to go for an upgrade
as soon as the new release is announced and wait for some time before going for it. However, on the other
hand, it is not recommended to skip multiple releases in between as this may create more complications
during upgrade. For example, a client on SAP’s older version of ERP (SAP R/3 3.1) version will have lots
of challenges for upgrading to SAP’s newer version of ERP (ECC 6.0) today as the platform had changed
to Netweaver and there are multiple releases which happened in between.
Temporary Decline in User Productivity New release may come up with entirely new GUI. Taking
a queue from the earlier example SAP R/3 versions used to have a very different GUI from current ECC
version which is more roles-based. There can also changes at screen level like sales order or purchase order
entry screen can be very different in the new version compared to earlier. This may take some time for users
initially to get themselves familiar and there can be temporary decline in productivity for a period.
Upgradation may Become Must for Multiple Applications Together Though there is no
strong business case, there may be simple compatibility issue for which upgradation of multiple applications
become must. For example, a company initially interested in upgrading their ERP system only as there was
no strong business case for upgrading other applications, but later on discovered that the new version ERP
system’s sales module can not talk with the CRM application which was in older version and hence, the
company has to upgrade CRM as well.

Types of Upgrade
There can be two types of upgrades as shown in Figure 19.7. One is just upgrading the technical environment
without doing any new functionality implementation and the second is doing upgrade with new functionality
implementation. Many companies go first for technical upgrade which is simple to do, followed by functional
upgrade. These two options are discussed below:
Technical Upgrade Here only the application’s technical environment (i.e. platform, database, operating
system, Kernel, patch level, etc) gets upgraded. There is no functional enhancement and through a series of
testing, it is ensured that what was working in the earlier version still works in the upgraded version.
 Application Support 251

Fig. 19.7 Types of Upgrades

Advantages:
It is fast and cheap
Change management is minimal as there is no new process or new ways of doing business
Reduces maintenance cost as the company does not pay charges for extended maintenance period.
Disadvantages:
It does not provide any business benefit to the company
Mostly driven by vendor’s product roadmap, i.e. “The vendor will stop supporting the application if
not upgraded”.
Functional Upgrade Here, the new functionalities or an altogether new modules of the new version
is implemented. For example, a client of older version of SAP ERP (Say SAP R/3 3.1H version) upgraded
to latest version of SAP ERP (SAP ECC 6.0) may look for implementing a new module (like Global Trade
service – GTS or Employee Health and Safety – EHS) altogether which is expected to give lots of business
benefits.
Advantages:
This brings business benefits and there can be good business case for this.
Disadvantages:
It takes longer time and cost as there may be new blueprinting, new configuration, new development,
etc
Change management is important here as there may be new ways of doing business (For example,
SAP Global Trade module implementation may ask for running your export and import business in a
different way)
252 Enterprise Resource Planning

DIFFERENT LEVELS OF SUPPORT

Issues raised by users can fall into different types. There will be lot of fairly simple issues which in most
cases the user had raised perhaps as he does not have detailed knowledge of the software of how to use it
or there are simple problems like he is trying to run a transaction for which basic data elements are missing
(for example, he is trying to create an invoice in the system and the customer master record does not exist in
the system). These are called Level 1 issues and almost 60% of issues fall into this level. The next level of
issues can be things which are little complex in nature – may be performance problem in the system (system
has become very slow) or a new business requirement that needs a change request and additional configura-
tion, etc. These are typically handled by Level 2 guys. Finally there will be issues which can be things like
software bugs and these can be handled by ERP vendors only and these are known as Level 3 issues.
Figure 19.8 shows how an issue can flow to different support levels, based on the severity of the issue.
End user or business user first asks the key users or power users if he faces any problem. If it can not be
solved by the key user, the issue is logged by 1st level help desk, who try to provide a solution from solu-
tion database. If he can not solve the problem, depending on the nature of the problem it gets assigned to
either a functional or technical Level 2 support team. Finally, if they also can not provide a solution, the
issue is reported at third level to ERP vendor. The kind of issues handled by each level is discussed in detail
below:

Level 1 Support (1st Level Helpdesk)

This is the first level of basic applications support helpdesk sometime managed by the client themselves

Fig. 19.8 1st, 2nd and 3rd Levels of Support

 Application Support 253

and sometime outsourced to a third party. Volumes of issues are high here but complexities for most of
them are low. This is the first point of contact within the business for all user support requests. This group
typically do following things:
Answers to “how do I?”, i.e. handles queries regarding use of the application
Provide training to new and existing users on current application functionality
Responses to queries that can be handled by a predefined scripted response (FAQ or frequently asked
questions) or a defined procedure, which includes basic diagnostics for problem resolution
Solve repeated incidents which had occurred earlier and for which solution is known. Many companies
develop good solution database to support such issues – solution already exists in the database and
are referred to when needed.

Level 2 Support (In-Depth Analysis and Solution)

This is a second level applications support, provided by a dedicated specialist group generally external to
the business. This group can do things like:
Support issues/requests that cannot be resolved by first level
Application administration services and on going database administration
Management of requests for additional functionality to be included in the base application
Business support including minor enhancements and customisation, report development, etc
Technical support including system administration, performance management, user profile manage-
ment, interface management, etc.
Management of support issues that require involvement of 3rd parties or the software vendor

Level 3 Support (Expert Advice and Vendor Contact)

This support is provided by application vendor for which ERP vendors charges an annual maintenance fee.
This can includes things like:
Support for software patches for “bugs” within the base application
Expert advice regarding application upgrades and potential impacts
Expert services consulting to the 2nd line support group as required
Support requests that cannot be resolved by Level 1/Level 2

SERVICE LEVELS AND SLAs

Service Contract and Service Level Agreement (SLA)
A service contract is a long-term agreement with business partners that specifies the services offered for
that period.
Service level agreements are a subset of contracts where the customer is assured the performance of
certain services within a predefined period of time. For example, if a problem occurs on a customer’s ma-
chines, the customer is assured that a technician will be on site to repair the fault within a specified amount
of time. Service level agreements list the level of service a customer is entitled to and contain functions
for monitoring compliance with those terms. Standard SLA parameters allowing specifying: Time frame of
service availability, ensured fast reaction time, ensured call closure time, etc. SLA can contain things like:
Response time: How long it takes to respond to the customer need – call back within specified time,
technician on site within a specified time
Service window or Availability time: Working hours of the service or support center
Downtime: Maximum number of allowed breakdowns per year
254 Enterprise Resource Planning

Availability: Percentage of assured system availability

Solution time: Maximum period of time allowed for the solution of a problem.
Generally Service level agreements (SLAs) are designed based on severity level of the issue. Issues
having highest severity level are defined as priority 1 (P1) issues. An example of SLAs defined based on
priority is given as follows:

Priority Definition Reaction Standard Service

Level Time Resolution Level
Time Yearly
Target
P1 An incident is designated to be a priority 1 when these types 1 hour 8 hours, 97%
of conditions are experienced: irrespective
Any business, technical, or facility outage where ser- of office
vice must be restored with urgency or deadlines will be hours
missed
Complete non-availability or non-usability of an applica-
tion
Any incident which has a potential significant revenue loss
to the company
Critical system processing has stopped, all locations
are impacted, and users are unable to perform. No
workaround, bypass or alternative is available. Major
financial impact condition exists.
P2 An incident is designated to be a priority 2 when employees 2 hours 24 hours, 97%
can continue to perform their work using a work around irrespective
or delay work with some impact to internal and external of office
customers. hours
P3 An incident is designated to be a priority 3 when employees 4 hours 3 working 95%
can continue to perform their work using a work around or within desk days or on
delay work with no significant impact to internal or external support agreed due
customers. A component, minor application or procedure is times date
down, unusable or difficult to use. There is some operational
impact, but no immediate impact on service delivery. An
acceptable workaround, alternative or bypass exists. One or
more locations are impacted.
P4 An incident is designated to be a priority 4 when employees 8 hours 1 month 95%
can continue to perform their work using a work around or within desk
delay work with no significant impact to on routine opera- support
tions. A component, procedure or personal application is not times
usable. No impact to business, single incident failure, and
a workaround, alternative or bypass is available. Deferred
maintenance is acceptable.

(Reaction time = Time span between the time an issue is reported to support desk and the time when first
response comes from support desk to user that work has started on the issue)
Generally for supporting P1 and P2 issues, support teams are available on call on 24 × 7 basis on rotation.
Priority 3 and 4 calls are generally attended on next business day. There can be reporting/feedback intervals
defined based on type of issues as follows:
 Application Support 255

Priority Level During Desk Support Hours

P1 Initial update 2 hours after open time.
Update every 2 hours after.
P2 Initial update 2 hours after open time.
Update every 6 hours after.
P3 Initial update 1 working day after open time.
Update every 2 days after.
P4 Initial update 2 working days after open time.
Update weekly after.

Another example of Service definition:

Assigned Severity Average Service Incident Target Times for Workaround

Level Response Time or Permanent Resolution
(Initial Call Back Time)
1 Within one (1) hour Within one (1) calendar day
2 Within two (2) hours Within one to three (1-3) calendar days
3 Within four (4) hours Within three to five (3-5) calendar days
4 Within eight (8) hours Within five to ten (5-10) calendar days

For critical incidents, there need to be clearly defined escalation matrix between the support team and
the business. There can be clearly defined matrix in such case as follows:
If a Level 1 incident is not resolved within defined team (say 1 calendar day in the earlier example),
the program manager of support team and program manager of business/client will meet to resolve
this issue.
If a Level 2 incident is not resolved within defined time (say 1-3 calendar day in the earlier example
after being escalated to Level 1, the executive sponsor of client team and support team program ex-
ecutive need to resolve the issue.

Service Level Reporting (SLR)

Generally on a monthly basis Service Level Reports (SLR) are prepared to see SLA adherence. Some of the
common reporting items can be as follows:

Reporting Item Comment

Call resolution Percentage of calls resolved by due date.
Call activity Calls received, resolved and outstanding
Incident statistics General support issues, escalation items and conflict incidents

Beyond call resolution, service level reports (SLR) can also cover performance reports. Below are few
examples of such performance reports:
System Monitoring Performance Reports:
System availability: overview and history
System performance: overview and history
Database performance: overview
Hardware capacity: overview and history
256 Enterprise Resource Planning

Configuration parameter changes (System, database, operating system)

Programme errors: overview and history
Applications Monitoring Performance Reports:
Expensive SQL statements: overview
Performance for dedicated transactions
Software changes: overview and history
Monitoring of background jobs
Interface Monitoring Performance Reports:
Interface errors: overview and history
Response Times Performance Reports:
Average System Response Time
Average Database Response Time
Average Wait Response Time
Average CPU Response Time
These KPIs and performance reports represent how the system is performing technically.

SLA and SLR

The service level agreement (SLA) provides a standard against which service level reports (SLR) can be
evaluated. To monitor achievement of service level goals, each SLR need to be checked against SLA. A
meeting needs to be scheduled with support team at regular frequency to evaluate service level reports and
discuss strategy for maintaining or improving service levels.

SERVICE DESK
The service desk plays a vital role in keeping ERP systems running smoothly. The service desk pro-actively
keeps users informed of all relevant service events, actions and service changes that are likely to affect them.
The objectives of the service desk are:
Providing a single (informed) point of contact for customers.
Facilitating the restoration of normal operational service with minimal business impact on the customer
within agreed levels (SLA) and business priorities.
While there can be manual service desks where a person manually creates a tickets, assigns it to a user
and get it resolved, increasingly companies are using specialized service desk software for supporting various
areas of support as shown in Figure 19.9. Leading service desk management software is: BMC Software’s
Remedy, IBM’s Tivoli etc. Areas where service desk can help are discussed below:
A. Managing Issues/Tickets: Each issue need to be logged and monitored by service desk until resolved.
This means:
Creation of issue/tickets: Incidents can be created manually by user or automatically by e-mail, event
trigger, etc.
Prioritisation of issues: System helps in prioritising the incidents and monitoring SLAs (service level
agreements) as per the priority of the issue.
Proper routing and escalation of issues: System helps in routing and assigning the issue to the right
people who can work on it based on skill level. In case the issue is not solved within agreed time
frame, this needs to be escalated to the next level to take appropriate action.
Status change of issues: The person who had raised the issue or who is working on the issue can
change its status, i.e. view it, update it or close it if it is already resolved.
Fig. 19.9 Service Desk Functions
Application Support
257
258 Enterprise Resource Planning

B. Managing Problem: The difference between an issue and a problem is if an issue reoccurs several times,
then this is no longer an issue and becomes a problem. Thus, the main objective of problem management
tools is to prevent and reduce issues and provide solutions for permanent problem solving so that the issue
does not reoccur. Service desk can group a set of issues depending on the similarity of them into a problem;
assign this problem to proper people/groups who resolve it permanently. For managing problems, service
desk tools have capabilities like:
Problem identification and classification: The service desk tools helps in classifying similar issues
into groups. Ideally to define an issue as a problem, there needs to have multiple issues attached to it
and proof of reoccurrence, then this can be entered as a problem in problem management database.
Problem diagnosis: Service desks assist in the problem diagnosis and subsequent resolution.
Problem closing: Service desk helps in closure of the problem, resolve related issues and monitor in
case there is a reoccurrence of the problem in future.
C. Change Management: Service desk helps in this process by ensuring changes are implemented with
minimal risk and leading service desk software having capabilities like
Workflow engine: This is needed as each change request may go for an approval to change manage-
ment board and once approved go the respective support team member to implement the change by
automatic workflow. This engine ensures appropriate checks and balances in the change management
process.
Scheduling capability: This helps in scheduling changes taking into account system and resource
availability, potential change windows, and dependencies on prior changes.
Tracking and reporting changes: The system allows display of changes by date, track changes, ensure
post-implementation analysis of these changes.
D. Service Request Management
Service desk software helps users to
Create common service requests, i.e. a request to apply a batch or to do a log cleaning
Getting those service requests approved by appropriate authority
Calculating costs of the service requests and their accounting
E. Knowledge Management Tools
Service desk systems can provide various tools for knowledge capture and reuse. The idea is users should
never "reinvent the wheel". Some of the capabilities can be as follows:
Issue resolution database/Solution database: Service desk software helps in creating issue resolu-
tions database that can be a ready reference in case there is a reoccurrence off the issue.
Frequently Asked Questions (FAQs): This assists end users in solving their own problems. These
FAQs are developed over the time.
Easy access of content: Users of service desk can access the content by easy search tools like keyword
search.
F. Reporting
The service desk software monitors support performance and performance on SLAs for issue handling
and resolution. Some of the leading service desk tools provide real time dashboards showing service desk
performance. Metrics track employee productivity, as well as customer satisfaction, etc. Typical metrices
can be:
How many messages were reported (for a given time interval for different ERP component)?
How long did it take to complete the messages?
How many were solved with the internal solution database?
How many were referred to 2nd level?
 Application Support 259

How many were sent to 3rd level, i.e. to the application vendor?
How many were converted into change requests and problem tickets?
How is the satisfaction of end users?

VENDOR SUPPORT: AN OVERVIEW OF SUPPORT STRATEGIES

FROM LEADING ERP VENDOR SAP
In case of package applications like ERP or CRM products, the final level of support (Sometimes called
L3 support) is always provided by the application vendor itself. For this, the company implementing ERP
or any other enterprise solutions (like CRM, PLM etc) need to enter into an annual maintenance contract
with the application vendor and the vendor charges an annual fee (generally a percentage of licence cost)
for this service.
In this chapter the support options from leading enterprise solution vendor SAP is discussed in detail as
a reference.

Support Offerings from SAP

A. Different maintenance options
SAP offers a variety of maintenance options to its clients and these are:
Standard support: Most of the SAP customers generally opt for this.
Maximum attention: This is a premium maintenance package and offer additional services. Customers
needing special care can opt for this.
Extended maintenance: All enterprise applications come with a standard maintenance cycle. Custom-
ers want to maintain their system beyond this period can opt for this offering at additional fee.
B. Different modes of delivering service
SAP offers variety of modes for delivering service like:
Self service (Mainly documented instructions on how to carry out the service by user themselves)
Remote service (Service is delivered from remote location. SAP experts log on to customer’s system
through a remote connection and solve the problem)
Onsite service (SAP consulting team go to the customer location and provide service there)
C. Problem resolution services
SAP offers support at different levels, first giving an option to user to solve the problem themselves by using
notes database, in case the problem can not be solved, SAP’s own global support team takes it up. These
support options are discussed below.
Support packages: From SAP service marketplace, support packages and patches can be downloaded.
A SAP user can subscribe to information on SAP support packages for products (they are using) and
versions/releases that interest them. As soon as there is a new support package is released in that area
from SAP, a message is sent to the user.
Notes database: This contains solution for problems/bugs that are already identified and customers can
access this database in service marketplace via a search engine where search is possible by keyword,
release or component.
Hot news and Top news: Hot news is high priority SAP notes that can cause system to shut down
or data to be lost. Customers affected by such problems are supposed to read these notes. SAP Top
news is ten most important notes for each component and this list is compiled every month.
SAP active global support: If the problem can not be solved from notes, a message can be e-mailed
from SAP service marketplace or from solution manager. SAP team starts working on this issue and in
260 Enterprise Resource Planning

case of an urgent message which affects client’s production system; the first reply is expected within
4 hours as this support is 24 × 7. By checking the inbox in SAP service marketplace, its status can be
tracked.
D. Community Service
SAP had built several communities for collaboration and knowledge exchange of its user group. Some of
the common ones are:
SAP Service marketplace (www.service.sap.com): All kind of SAP services can be ordered from
here like consulting, education, support, etc. All patches can be downloaded from here, notes can be
searched or issues can be logged. A very popular site for SAP users globally. Figure 19.10 shows kind
of services offered from SAP service marketplace.
America’s SAP User Group (ASUG)
SAP customer competence centre net (CCCNet): A site for key account customers with customer
competence centers
SAP Partner Value Net: A site for network of SAP partners
SDN: A site for SAP developers community
BPX Community: A site for SAP Business Process Expert community

Fig. 19.10 Solution Manager—SAP’s Tool for System Maintenance

Specialised Services
SAP also offers a set of specialised services for smooth running of its application. Some of it are a part of
standard maintenance contract and some others come at a cost.
 Application Support 261

E. Different Specialised services

Safeguarding programme
This consists of services that manage technical risk of ERP solution. The different checks can be used for
implementations, upgrades and migrations as well as for continuously optimising and monitoring business
processes. Below are few such examples:
Go Live check: Some leading ERPs provide audit services to checks whether the customer is ready
for go live.
Safeguarding OS/DB Migration check: If the customer is migrating to a different operating system or
database, this safeguarding service checks the risk in the same.
Go Live functional upgrade check: This is a safeguarding service for customers going live after func-
tional upgrade.
Early watch programme
Early watch alert is a performance monitoring service of ERP system at periodic intervals. For this
analysis ERP vendor uses a data collector to gather data in the background from customer’s ERP system and
this data is sent to ERP vendor for further processing. The analysis can provide information on variety of
things based on client need like; current system status, response times for most frequently used transactions,
transactions that use the most resources, distribution of workload, hardware utilisation, potential system er-
rors, database administration, performance analysis, identification of bottlenecks, etc.
Performance optimisation services
This service recommends things that the customer should do for better performance of their ERP systems
and can include things like SQL statement optimisation, customer programme optimisation, business process
performance optimisation, remote performance optimisation, optimisation of database layout, etc. These
services helps in optimisation of application functions, parallel processing, sizing, distribution of load over
database and application server, etc.
Conversion services and data harmonisation consulting
This can be for things like:
Services for application integration optimisation
Interface management: This analyses and optimises the interfaces and focuses on performance and
throughput, configuration, data security and data consistency, interface management procedures.
Business process management
Services for data volume optimisation and data management
System administration optimisation

SAP’s tool for maintaining application – Solution Manager

SAP® Solution Manager is a centralised solution management platform that provides the tools for imple-
mentation, support, operate, and monitor SAP solutions as shown in Figure 19.10. In this chapter we discuss
mainly the support and monitoring capabilities of solution manager and not implementation functionalities.
Some of these are:
Support desk: Support desk of solution manager helps managing incidents and all normal help desk/
service desk functions as described earlier.
Central system administration: This component of solution manager controls recurring administra-
tion tasks centrally and record execution of these tasks.
Solution monitoring: Solution manager performs centralised, real-time monitoring of systems, business
processes, and interfaces, thereby reducing administration effort. Proactive monitoring with automatic
notifications helps avoiding critical situations and fast response to issues.
262 Enterprise Resource Planning

Service level management: Once report and service levels are defined with solution manager, auto-
mated reporting helps managing service levels.
Service processing: Solution manager can make appropriate service recommendations based on
user’s need and act as a vehicle for delivering SAP support services. These include services like, SAP
safeguarding service to manage technical risk; SAP solution management optimisation services, etc
as described earlier.
Upgrade and change management: Change management and upgrade can be accelerated with solu-
tion manager.

DIFFERENT SUPPORT MODELS AND OUTSOURCING SUPPORT

Support Models
There are different support options which a company can adopt and these can be divided in three catego-
ries:
A. In-house options:
Own support centre
Support handled by IT Company of the group
B. Outsourcing options:
Application outsourcing – Onsite model
Application outsourcing – Near shore model
Application outsourcing – Onsite offshore model
Complex application outsourcing to multiple vendors – Onsite offshore model
Full outsourcing
C. Supplemental staffing/Staff augmentation model
Advantages and Disadvantages of Different Models There are advantages and disadvantages
of each of these models. We describe these models in brief in this chapter.
In-house Support
Own Support Centre Here the company manages both help desk (L1) and specialised support (L2) by
their own staff. Lot of companies who had implanted ERP or CRM solution has started their own compe-
tency centers to handle support. Tata Steel who has their own SAP competency centre to support their ERP
application is a good example of this.
Support Handled by IT Company of the Group In this case a group IT Company handles the support
for the company. A good example of this is ITC Infotech which handles SAP support for ITC’s tobacco, food
and several other businesses. Few companies had seen this as a good way of retaining their best core team
talent after implementation, by making a separate IT company within the group which works as a separate
profit centre, handles support for group company and also do consulting engagements for other companies.
A good example of this is BPCL which has an IT group that supports internal applications and also offer
services to companies outside in terms of SAP training, consulting, etc. In some cases, these companies
bring strong vertical industry experience with them. For example, ITC Infotech in consumer goods industry,
BPCL in oil and gas industry, etc.
Support Handled by Company’s Offshore Centre Several leading companies these days had opened
offshore centers in India and China and these centers provide them offshore support. For example, leading
 Application Support 263

multinationals like Sony, Intel, GE had opened their offshore centers in Bangalore and these centers provide
application support to the group companies.
Support Outsourcing
Application Outsourcing Onsite Model In this case the application is outsourced to an IT/consulting
company and the service provider work at client site. Several countries in India follow this model. This is
also a popular model for some companies to start outsourcing before they get confidence that support can
be provided from some other location (Nerashore or Offshore model).
Application Outsourcing Near Shore Model In this case the support is provided not at client location,
but from a location which is close to the client’s place, i.e. at the same state or at least at the same country.
In some cases, it is a popular model in case the company’s factory locations are located at remote places and
support can be provided from nearest city where it is easy to get talented IT professionals. A good example
of this can be for a company at Noida, the support is provided from Delhi.
Application Outsourcing Onsite Off Shore Model This is the most popular model of support these
days for companies in developed continents like U.S., Europe and Australia. Most of the large IT service
providers – both Global (like IBM, HP, CSC, Capgemini) and Indian (Infosys, Wipro, TCS, Cognizant, etc)
follow this model. In this case the team is made of few onsite coordinators and a large offshore team. Onsite
team is in touch with the client on a regular basis while the offshore team work under their guidance. This
is a common model of support for most of the global companies these days.
Below is an example from a company. They had outsourced their support to an IT service provider. The
service provider planned to do a set of activities onsite and a set of activities offshore. The list below shows
the kind of activities planned to be done onsite and the activities planned to be done from off shore.
Activities done onsite:
Severity 1 issue response/high priority issue resolution
Complex functional/technical specification preparation, where user interaction is critical
Business user interaction/liaison
Scheduling/coordination/planning for offshore team
Testing of complex solution that need continuous validation by business users
Complex design/analysis of technical development for customised solutions
Activities done offshore:
Configuration/customisation/enhancements
Functional analysis/specification preparation
Developing modifications/forms
Developing reports
Monitoring system
Scheduling batch jobs
Managing transports for change management
Unit testing and documentation
Integration testing
Complex Application Outsourcing This involves multiple vendors and the company may outsource dif-
ferent part of the support to different vendors based on skill and cost parameters. Support can be provided
both onsite and offshore. A good example of this is Nestle. Nestle is one of the largest SAP implementations
globally (Nestle Globe project) and the support for this is outsourced to different vendors. For example, part
264 Enterprise Resource Planning

of functional support of different SAP modules to IBM, part of technology support to (ABAP, Basis work,
etc) Satyam and Nestlé's own team also manages some part of this support.
Full Outsourcing In this case the complete IT set up for the company is outsourced to a third party and
this third party has also taken over employees of company’s IT department. Large IT service providers like
IBM take up this kind of outsourcing and there are several examples in India of this model where companies
like Ballarpur Industries, Bharti telecom, Idea Cellular, etc have outsourced their entire IT set up to IBM.
Supplemental Staffing/Staff Augmentation Model This is a mix of in-house and outsourcing model
where a company uses a mix of their own staff and external consultants to manage support. The company will
manage with their own staff in areas where they have their own skill available and will opt for an external
resource in areas where there is no inhouse skill or skill within is not competent enough.

Outsourcing Support—Pros and Cons

Outsourcing support is the most common model these days as companies had realised that supporting ERP
applications is not something core to company’s business and should be left to specialists. The other driver
of outsourcing, especially in developed countries, is cost savings. Outsourcing can also offer flexibility in
operations. However, outsourcing is not all about good things as there are chances of loosing control and
sometime making long term financial commitment to a service provider. We will discuss few of these ad-
vantages and disadvantages of outsourcing as shown in Figure 19.11 in this chapter now.

Fig. 19.11 Outsourcing Support—Advantages and Disadvantages

Pros of Outsourcing
Better quality of service and access to better methods and tools: IT or consulting companies spe-
cialising in application support over time had developed better methodologies, tools and processes to
ensure high quality of service at reasonable cost. Outsourcing can also lead to better service level as
if outsourcing vendor does not provide service as per defined SLAs – it is easy to penalise him and
that is sometime difficult if support is handled inhouse.
Lower costs through better tools and productivity improvement: Companies specialising in support
often reduce costs by enforcing standards, by making best-of-breed tools available to their support
staffs, by leveraging facilities that perform application management and support that can be shared
 Application Support 265

among multiple customers. As support staffs in this case solve the same kind of problems for multiple
companies or in most cases solving a problem which they had solved earlier for some other companies
– productivity is higher here and this productivity improvements related to savings can be passed on
to final customers.
Flexibility of easy ramp up and ramp down: For an outsourced service provider, staffing levels can
be moved upward and downward fairly quickly, without undergoing the expense and time required
to either increase or decrease permanent staffing. Experts can only be used for the length of time a
project requires, rather than having to hire those same experts as permanent staff. This is important,
especially in times of economic uncertainty. Some companies are popularising the model of “On de-
mand support”, i.e. do not commit to a fixed number of resources and get at any point what exactly
you need. This also calls for revolutionary pricing models like ticket based pricing instead of paying
for fixed number of resources.
Cons of Outsourcing
Flexibility sometimes may mean committing for a minimum staffing level: Though staffing levels
can be adjusted based on demand, in most cases vendors insists on minimum staffing levels and the
company need to pay for it even if their service is not used.
Chances of loosing control: Any bad performance by the vendor on mission critical applications for
a day can cause serious issues for the company. For example, if the invoice system is down during
the last week of the month, it is difficult for company to sell and invoice product. Though you can
penalise the vendor for non-performance, the cost of lost sales may be much higher then this penalty
amount. This need strong control and monitoring of service providers.
Some cases outsourcing can be costly: In some cases outsourcing can work out to be costly if the
support work volume is not estimated properly or negotiations had not been done properly or the
company has competent in-house staff who are capable of supporting multiple modules.

SUPPORT ROLES
There can be different support roles and depending on size and complexity of support operations these roles
may increase. There can be additional roles depending on from where the support is provided (like onsite
coordinator if good part of support is provided from offshore) or depending on the size of support operation
(A large team may need several team leads). Figure 19.12 shows a typical support organisation structure.
Typical support roles can be as follows:
Support consultants functional: Responsible for the resolution of functional issues logged in the
database. The issues are directed according to the consultant’s experience, service level required and
complexity of the issue. There can be different functional support consultants based on different ERP
modules like production, materials management, sales and distribution, etc taking care of different
clients’ processes like order fulfillment, procure to pay, etc.
Support consultant technical: Responsible for the resolution of technical issues logged in the da-
tabase. Again there can be several technical consultants based on different areas like database, EAI,
ERP programming language, etc.
Support team lead functional: This role is needed if there is a large pool of functional consultants
supporting the client.
Support team lead technical: This role is needed, if there is a large pool of technical consultants
supporting the client.
Service desk representative: Responsible for managing SLA goals, identifying consultants with
required knowledge for assignment of issure, reports SLA information periodically.
266 Enterprise Resource Planning

Fig. 19.12 A Typical Support Organisation Structure

Quality manager: Ensure that all quality processes are followed, right methods and tools are used
during issue resolution and issues and solutions are properly documented. This ensures long term
productivity improvement and delivery excellence.
Service manager: Responsible for the quality of the delivered products, handles any scope change,
coordinates on resources and allocate them, manages all kind of coordination with clients, periodically
report SLA information to client and ensures that SLAs are met.

METHODOLOGY FOR SUPPORT

ERP vendors are increasingly coming up with standards for supporting and maintaining applications. In
this context again SAP is a trend setter. SAP had recently come up with a standard called “Run SAP” for
maintaining SAP applications through its life cycle. SAP Enterprise Support strategy now includes Run
SAP methodology, tools, and processes that are applicable for the complete life cycle management of SAP
environments from implementation to operations and provides guidance for customers beyond the go live
phase and focuses on application management during support.

Run SAP
Run SAP is SAP’s approach for end-to-end operations and support. It provides the methodology for best
practices, content, services, education and tools for end-to-end Solution Operations. Run SAP builds the
framework for end-to-end operations by presenting a methodology with integrated standards and tools. Run
SAP Methodology provides the guidance for implementing end-to-end operations processes and Run SAP
 Application Support 267

Standards are the standards defined by SAP for operations and support. SAP groups Run SAP standards
into six groups as shown in Figure 19.13 and these are briefly discussed below.
End user support standards: This covers standards for issue management, defining the process and
tools to manage the required collaboration between the involved parties. It is used to report, track,
and resolve incidents.
Technical operations standards: This includes the standards for system monitoring and system ad-
ministration. These have active system monitoring and reporting of the technical status of IT solutions
and descriptive system administration guidelines. These standards facilitate the efficient running of a
customer solution.
Organisational operations standards: This contains the standards for upgrades and eSOA, or en-
terprise Service Oriented Architecture readiness. The upgrade area guides customers and technology
partners through upgrade projects and eSOA readiness accounts for both technical and organisational
readiness for enterprise service-oriented architectures.
Business process operations standards: This builds the framework for the standards Business Process
and Interface Monitoring, Data Volume Management, Job Scheduling Management, Data Integrity,
Exception Handling, and Transactional Consistency. The term “Business Process and Interface Moni-

Fig. 19.13 Run SAP—SAP’s Mathodology and Standards for System Maintenance
268 Enterprise Resource Planning

toring” describes the monitoring and management of the mission-critical business processes. Data
Volume Management defines how to manage data growth and quality. Job Scheduling Management
explains how to manage the planning, scheduling, and monitoring of background jobs. Data Integrity
avoids data inconsistencies in end-to-end solution landscapes. Exception Handling explains how to
define a model and contains procedures to manage exceptions and error situations during daily business
operations. Transactional consistency safeguards data synchronisation across applications in distributed
system landscapes.
Change management standards: This provides the standards for Change Control Management,
Change Request Management, and Testing. Change Control Management covers the deployment and
the analysis of changes. Change Request Management enables efficient and punctual implementation
of changes with minimal risks. Test Management describes the approach for functional, scenario,
integration cycles, and technical system tests of SAP-centric solutions.
Application management standards: Application management encompasses the standards for Solution
Documentation, Root Cause Analysis, and Remote Supportability. Solution Documentation describes
the required documentation and reporting regarding the customer solution. Root Cause Analysis defines
how to perform root cause analysis end-to-end across different support levels and different technolo-
gies. Remote Supportability allows for off-site coordination of these functions.

MEASURING ERP PERFORMANCE AND CONTINUOUS

IMPROVEMENT
Companies invest in ERP systems to get business benefits and prepare business case to get necessary budget
for the project before starting the implementation. Once the project is completed and support reaches a steady
state, it is seen whether those business benefits are really achieved. All the benefits may not be obtained
in the first year itself, but it is important to put some metrics so that there is a scientific way of measuring
whether improvements are happening as desired. Typical areas where improvements are expected are shown
in Figure 19.14 and these are:
Improvement in inventory turn
Reduction in cash and to cash cycle time
Improvement in forecast accuracy
Improvement in customer service
Productivity improvements
On time delivery improvements
Performance on these metrics need to measured on a regular basis to see whether ERP implementation
is really giving any business benefit. Some companies do such benefit measurement by internal team and
some others engage external auditors for this. Figure 19.15 shows an example of such value realisation from
an ERP project and enabling processes that made it happen.
This is one of the reasons why it is told that an ERP project never gets over. There is always scope for
further fine tuning and improvement of a process and that means additional change requests for ERP sup-
port team, there will be always new upgrades coming with better functionality that the company can adopt,
there is scope of deploying additional modules as the company’s processes get more matured etc.
 Application Support 269

Fig. 19.14 Areas of Performance Improvement Through ERP

Fig. 19.15 Value Realisation from an ERP Project—Example

270 Enterprise Resource Planning

Summary
Support is an important phase of application life cycle as implementation of an enterprise solution typically
ranges between 6-18 months depending on size of the organisation, but support cycle (i.e. Support and up-
grade) may continue for several years till the organisation uses the application.
This is also the phase when the system is used by much larger number of users and not just within the core
team. During most part of implementation system usage is generally restricted within core team.
Typical ERP support cycle starts with transition, followed by a stage of hyper care and finally a steady state
which continues till date the application is upgraded to the next version.
Transition involves transition of knowledge, documentation and open issues from the implementation team
to support team. This may also involve some human resource transition in terms of new roles and transfers
of employees to a new location.
Change is obvious in ERP life cycle for different reasons like new business requirement, new functionality
implementation, etc. However, the impact of these changes needs to be studied, impact need to be analysed
and first implemented in development system. These changes need to be thoroughly tested in quality environ-
ment before moving into active production environment.
Application upgrade has not only its advantages in terms of lower maintenance cost, newer functionality,
better technical platform, etc but also involve additional cost, business disruption and possible issues with
new application. Any decision to go for an upgrade need to be well thought out.
Application supports can have different levels in terms of first level, second level, third level, etc. Depending
on the severity of the issue, the applications are forwarded to appropriate levels.
Service desk helps in variety of areas like issue management, problem management, knowledge management,
change management, reporting, KPI measurement, etc.
Service level agreements (SLAs) ensure that supports are provided based on the right priority of issues i.e. high
priority issues gets maximum support. SLA reporting is a good measure to check service effectiveness.
There can be different support models depending on whether the support is provided onsite/offshore or who
provides the support company’s in-house team or it is outsourced.
Outsourcing support has several pros and cons as discussed in the chapter.
There can be several support roles in terms of support functional consultant, support technical consultant,
service desk representative, quality manager, etc.
Increasingly ERP vendors are coming with specialised support methodology to ensure consistency in support
approach.
It is important to measure ERP benefits on an ongoing basis to ensure value realisation from an ERP
project.

Exercise
I. Objective Type Questions
1. What are the five phases of support cycle?
2. What is meant by Hypercare phase?
3. How is Steady state different from Hypercare phase?
4. What is meant by application upgrade?
5. What is transition? What are the typical four activities in transition cycle?
 Application Support 271

6. What are the typical activities during support phase?

7. What are regular and periodic support tasks?
8. What are the pros and cons of application upgrade?
9. What can be the problems with new release?
10. Why are there temporary decline in user productivity post upgrade?
11. What are the different types of upgrade options?
12. What is Level 1, Level 2 and Level 3 application support?
13. Which level of support is generally provided by application vendor?
14. What is a service contract?
15. What is meant by SLA and SLR?
16. What is the difference between SLA and SLR?
17. What is a P1 issue?
18. Name some leading service desk management softwares.
19. What is the difference between an issue and a problem?
20. What are the different types of maintenance options an ERP vendor can provide?
21. What can be the different modes of delivering service?
22. What are the different problem resolution services offered by SAP?
23. What is SAP’s tool for managing application?
24. What are the different support models?
25. What are the different in-house support models?
26. What are the different support outsourcing models?
27. What is Run SAP?
28. What is the responsibility of Service Manager and Quality Manager?

II. Descriptive Type Questions

1. Explain the typical five phases of support cycle in details.
2. Explain the four types of activities in a typical transition cycle. Why knowledge transition is most impor-
tant?
3. Explain the activities during steady state support phase of a project.
4. How change management is handled during support phase? What are the typical change management activi-
ties at this phase?
5. Give some examples of regular and periodic support tasks.
6. Explain the advantages of application upgrade.
7. What are the disadvantages of application upgrade? Explain them in details.
8. What are two types of upgrade? Explain advantages and disadvantages of both.
9. Explain the difference between Level 1, Level 2 and Level 3 application supports? What types of activities
are done at each level?
10. What is SLA? What a typical SLA can contain? How issues can be categorised based on response time
requirement?
11. What is SLR? Give some examples of SLR.
12. Explain the functionalities of service desk management software.
13. What are the different knowledge management, issue management, problem management and reporting
capabilities service desk software provide?
14. Explain SAP’s service offerings in detail.
15. Explain the capabilities of SAP’s solution manager tool for application management.
16. Explain different in-house and outsourcing support models. What are the advantages and disadvantages of
each?
272 Enterprise Resource Planning

17. Why methodology is important for support? What is Run SAP? Explain six different Run SAP standards
for application support.
18. What are the different roles in an ERP support organisation? What are their responsibilities?
19. How ERP performances can be measured?

III. Fill in the Blanks

1. SLA stands for _______________ _____________ _______________.
2. SLR stands for _______________ _____________ _______________.
3. Two types of upgrades are ________ upgrade and _________ ___________.
4. Three levels of supports are L1, ___ and _____.
5. SAP offers three modes of delivering service __________, __________ and ______________.
6. _____________ is SAP’s methodology for supporting applications.
 Section

ERP Functional
Modules
 SECTION INTRODUCTION

ENTERPRISE APPLICATIONS—FUNCTIONAL MODULES

ERPs and Enterprise applications had a long journey since their inception. In the 80s ERPs when they first
started, they used to address core processes for an organisation like finance, procure to pay, order to cash,
etc. Departments like finance, sales, quality, procurement, production, maintenance, human resource, etc.
used to run their transactions in the ERP system. Over the time, ERPs had evolved and started coming up
with more advanced modules like service management, warehouse management, transportation, global trade,
employee health and safety, product safety, etc.
90s had seen the next generation of evolution for ERP vendors when ERPs started coming up with
specialised solutions for managing suppliers (supplier relationship management), customers (customer rela-
tionship management), R&D operations (product lifecycle management), supply chain planning (advanced
planning and scheduling – APS), maintenance and field service (enterprise asset management), etc. ERPs and
these new generation solutions (SRM, CRM, PLM, EAM, APS, etc.) are now called enterprise applications
or e-Business suite. Several leading ERP vendors started selling licence off all these applications as one
bundle. ‘mySAP Business suite’ from leading ERP vendor SAP or Oracle’s E-Business Suite are examples
of such bundling. However there are other specialised vendors for each of these new application categories
and some of them were present much before ERP vendors entered this space. Siebel (CRM application),
Ariba (SRM application), Winchill (PLM application), Maximo (EAM application) and i2 (APS application)
are few such examples.
The beginning of this century had seen ERPs going vertical, i.e. ERP vendors started coming up with
industry vertical specific offerings and ERPs suiting specific industry needs. Another trend was as the market
for large enterprises got saturated, ERP vendors targeted small and medium enterprises for licence selling and
started coming out with specific offerings for these sectors. ERP vendors also started making their solution
compatible with new technology innovations like RFID and mobile. Figure S-3.1 explains this evolution of
functional areas for enterprise applications.
It is not only in terms of functional modules that ERP vendors had evolved, ERPs also evolved in terms
of their usage and perception over the years. In the beginning organisations used ERPs mainly to run their
back office business transactions and ERPs used to be perceived as an application for transaction processing
within the enterprise. However, over the years ERPs and enterprise applications got extended beyond the
organisation to suppliers and customers, and started providing visibility beyond the organisation. Enterprise
applications now help organisations to collaborate with their trading partners. These are no longer just back-
end applications to do higher automation and reduce cost for the organisation, but with CRM, they became
front-end applications helping better relationship with customer and increasing revenue. Beyond transaction,
enterprise applications has now come up with sophisticated planning and optimisation capability helping
the organisation along with its suppliers and customers to optimise the entire supply chain. Figure S-3.2
explains how the value proposition of enterprise applications had changed over the time.
Present offerings from enterprise application vendors can be broken down onto the following major
categories:
Human resource management applications (catered by ERP HR module)
Financial management applications (catered by ERP financial module)
 Section Introduction 275

Fig. S-3.1 Enterprise Application—Evolution of Functionalities

Fig. S-3.2 Enterprise Application’s Changed Value Proposition Over the Years
276 Enterprise Resource Planning

Customer relationship management and sales applications (catered by ERP sales, distribution, service
module and CRM applications)
Supplier relationship management and procurement applications (catered by ERP procurement and
SRM applications)
Supply chain management applications (catered by ERP production management, warehouse man-
agement, transportation management and supply chain planning/advanced planning and scheduling
applications)
Production lifecycle management applications (catered by ERP quality management, project manage-
ment for new product development and PLM applications)
Enterprise asset management applications (catered by ERP maintenance management and EAM ap-
plications)
Figure S-3.3 shows how ERP and other enterprise applications cover these different functional areas.
ERP application areas (like sales, distribution, service) and the corresponding new generation enterprise
applications (like CRM) are kept side by side.
In this section, we cover each of these functional areas in different chapters. Chapter 20 discusses ERP
human resource management and Chapter 21 focuses on ERP financial management applications. Chap-
ter 22 covers what ERPs offer in terms of procurement, materials and inventory management. Chapter 23

Fig. S-3.3 Enterprise Applications—Different Functional Modules

 Section Introduction 277

focuses on supplier relationship management, i.e. the new generation procurement applications. Chapter 26
covers what ERPs offer for front-end functions like sales and service and Chapter 28 discusses how these
front-end operations can be further enhanced by CRM applications.
Supply chain applications are covered in Chapter 24, Chapter 25 and Chapter 27. Chapter 24 covers
ERP production/manufacturing management functionalities. Chapter 27 covers ERP warehouse management
and transportation functionalities. These are also called Logistics Execution Services (LES). Chapter 25
discusses advanced supply chain planning and optimisation applications. These are also known as Advanced
Planning and Scheduling (APS) applications and help in optimising the supply chain which is a traditional
limitation of ERP applications.
Chapter 30 covers ERP maintenance management and enterprise asset management applications. Chapter
29 focuses on what ERPs covers as part of quality management and Chapter 31 talks about product lifecycle
management applications. These applications are mainly used by organisation’s R&D team for new product
development.
Figure S-3.4 shows the broad categories of these different enterprise applications and how they had been
evolved from traditional ERP area and a high level overview of what extra they offer on top of the traditional
ERP applications.

Fig. S-3.4 How Different Functional Areas had Evolved

 20
Human Capital
Management Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Human capital management system – Different modules
Recruitment management
Time, attendance and leave management
Workforce scheduling
Compensation management
Benefits and payroll
Talent management/Performance management
Learning management
Personnel management
Employee relationship management and employee self-service
HCM analytics
Two leading human capital management solutions from SAP and Oracle
Strategic vs Operational HR processes and HR outsourcing
Emerging area of human capital management – Employee health and safety

INTRODUCTION
Human capital management is a key process for every organisation and this is a standard offering from
most of the leading ERP vendors in the market. The offerings differ for different packages. In this chapter
we discuss the general modules of HR solution which are covered by most of the leading ERP packages
available in the market.

HUMAN CAPITAL MANAGEMENT SYSTEMS

Human capital management processes in the organisation spread across several processes as shown in
Figure 20.1. These processes cater over the entire life cycle of an employee, start before an employee joins
an organisation and continues till date the employee leaves or retires the organisation.
280 Enterprise Resource Planning

Fig. 20.1 Human Capital Management Areas

While the order in which a company automates their human resource management processes varies as per
the company, typically transaction intensive processes like payroll, employee record management, time and
attendance management, leave management, etc. are first automated. The simple logic for this automation
is the volume of data/records and transactions. Recruitment processes are next to be automated. Strategic
processes like talent management, performance management and learning management processes are last
to automate. Figure 20.2 describes this order of automation.
Next in this chapter different ERP human resource management modules are discussed in detail.

Recruitment Management Module

Human resource management applications help in automating the recruitment process. The drive for such
automation is that companies need to identify and hire the best talent, quickly and cost effectively. These
solutions help companies by managing applicant flow and selection, managing applicant volumes by screen-
ing and selecting the best candidates using a variety of search, analysis and interactive methods and thus,
reduces hiring time and cost per hire. It has been seen that if a company’s recruit-to-hire cycle time for
skilled positions are too high (say, 6-8 weeks), there is a strong chance that some of the best candidates are
being lost to competitors. Recruitment automation helps in reducing the cost and time of hiring by:
Completely electronic recruitment process eliminating all paper documents
Using internet to attract candidates (company website, job portal, etc.)
Automating all record-keeping (digital records of candidate’s profile, certificates, etc.)
Better collaboration between recruiters and hiring managers so that managers can optimise their time
by focusing on best candidates only.
Figure 20.3 shows a typical recruitment cycle of an organisation involving following activities:
Labour forecasting and workforce planning: This step of recruitment process mainly decides that
how many people are needed of which skill, etc.
 Human Capital Management 281

Fig. 20.2 Human Capital Management—Order of Automation

Position management/creating requisitions for new positions: Once the future requirements are
known, it’s important that individual departments who need this people, create requisitions for these
people/skill to HR.
Candidate sourcing: This involves getting CVs from the market against the positions described above.
CVs can come from different sources like company websites where candidates apply with their profiles,
from job portals and getting profiles from different recruitment agencies. Sometimes, it is important
to get a number of profiles for each position for a quality selection.
Screening and application tracking: This is the process of selecting the right candidate from the
prospective candidate list and tracking candidate’s application till closure.
Interviewing: This involves activities like scheduling interview date, finalising interviewer, deciding
the location for interview, arranging interview logistics and finally recording interview feedback.
Selection: Based on the interview results candidates are selected.
Job offer: This is the stage where final job offer is made to the candidates.
282 Enterprise Resource Planning

Fig. 20.3 A Typical Recruitment Cycle

On boarding/Orientation: This is the process of bringing new hires up to maximum productivity. It

starts with a job offer and can involve a variety of tasks including HR/benefits/payroll enrollment, IT
access provisioning, facilities and equipment assignment, ID badges and company orientation. This
also can include things like job-specific training, buddy systems, executive mentoring. A company
having good onboarding system can accelerate enrollment tasks by providing electronic self-service
prior to reporting for work. Logistics can be pre-planned and coordinated so that the employee can
focus on learning his job from day one itself.
Human resource management module of ERP solutions has capabilities to support this entire recruitment
process through capabilities as detailed in Table 20.1.

Table 20.1 ERP HCM Module – Recruitment Capabilities

Process area How ERP solutions can help

Labour Forecasting Forecast near-term labour requirements on the basis of historical data or business
trends
Workforce planning Planning and analysing headcount and staffing costs. Capabilities of modeling long-
term staffing plans based on corporate growth strategies and talent requirements
Position management/creating New job positions can be created in ERP systems with detailed skill requirements.
requisitions for new positions ERP workflows help in authorising these job openings.
Candidate sourcing ERP applications support sourcing by their integration with company portals, dif-
ferent leading job websites, etc. to source profiles for each position.
(Contd)
 Human Capital Management 283

(Contd)
Screening and application ERP human resource module can help in screening candidates by job code matching
tracking and tracking a candidate’s application throughout its life cycle. The application is
screened, if shortlisted is forwarded to the interviewer through right workflow. If
the candidate is not shortlisted, he gets a Thank You mail automatically.
Interviewing ERP applications support interview scheduling to ensure that the hiring process fits
the hiring manager's timeline.
Job Offer ERP systems can come up with pre-defined templates mentioning all terms and
conditions for such offer, which make the process of offer generation faster and
full proof.
On boarding/Orientation ERP systems can provide automated workflows to ensure that new employees are
automatically guided to the next step in their onboarding process
Recruitment analytics/reports ERP systems provide various measures for recruitment like time-to-hire, cost-to-hire,
and candidate-sourcing success, etc.

Time, Attendance and Leave Management Module

Human resource systems help in managing time, attendance and leave of employees. Today there are lots of
technology advancements in this area and traditional punch cards are getting replaced by biometric devices,
mobile devices and HRMS systems need to support these multiple input methods. Capturing employee time
is important for employee’s payroll calculation and the HRMS packages can interpret time data based on con-
figurable pay rules to calculate gross pay of employees. Table 20.2 shows the details of HRMS module.

Table 20.2 ERP HCM Module—Time, Attendance, Leave Management Capabilities

Process area How ERP solutions can help

Time and attendance reporting This module is integrated with employee’s attendance, record time worked for each
employee and this becomes the basic input for payroll, based on which employee’s
gross pay, overtime, bonus or premium pay, sick pay, incentives, etc. are calculated.
Generally companies use separate time punching systems for factory gate entry
and exit with which ERP systems are automated. Through workflow, overtimes are
authorised by senior managers.
Absence ERP system’s HRMS module can report absences with reasons for absence and
analyse absence patterns.
Leave HRMS applications helps in recording leave accrual, leave requests, etc. as per com-
pany leave policies. This also helps in calculating cash payout for unused leave.
Time, attendance and leave Produce reports like productivity analysis, overtime, labour costs, attendance, time
management analytics off, etc.

Workforce Scheduling Module

Human resource management systems help in assigning the company’s workforce to different assignments.
Workforce scheduling (i.e. which employee should be assigned to which work, on which date, for how
many hours and between what time to what time) has come a long way from hand-written paper schedules
(posted on the walls for employees to check their next assignments) to solutions of today that can consider
284 Enterprise Resource Planning

different labour rules and skills, can factor in different constrains, can match production and job schedule to
employee availability and come up with a optimal deployment schedule for workforce. Scheduling module
of HRMS systems can support a variety of employee scheduling methods, from administering shift assign-
ments to constraint-based scheduling and integrate with time management module to check availability of
employees (attendance) and minimisation of overtime costs. As shown in Figure 20.4, Workforce scheduling
solution helps in:
Generating optimised scheduling and shift planning: HRMS solutions can generate most cost-ef-
fective schedule capable of satisfying business needs while satisfying employee availability, employee
union rules, other corporate policies and constraints. This optimised schedule can be in the form of
shift plan for individual employees.
Employee assignment to schedules
Labour Tracking: Labours need to be against schedule to address labour shortages (labour short-
age can arise due to unplanned sick time, no shows, etc.) i.e. if there is absence of scheduled labour,
alternate need to be arranged. Labours also need to be tracked to see whether they are completing the
scheduled assignment on time and taking up the next work as planned.
Dynamic Rescheduling: HRMS solutions can react to dynamic changes such as unplanned sick time;
service interruptions, etc. and reschedule to come up with a new optimised schedule.
It is important that workforce scheduling, and time attendance systems are integrated. Many companies
purchase a time and attendance system from one vendor and a scheduler from another. Because there is a
lack of adequate or no integration between these tools, decisions are made based on incomplete data. For
instance, an employee falls sick, the supervisor reviews the schedule and selects another employee to work,
however that employee already has too many hours in the current week, resulting in the company paying
unnecessary overtime. In this case the important data for that particular decision was in the time and at-
tendance system, which was not integrated with the scheduling system. Thus, complete information was not
available to the supervisor resulting in unnecessary overtime.

Fig. 20.4 Workforce Scheduling

 Human Capital Management 285

Compensation Management Module

Employee salary and compensation represent a huge fixed cost on most of the companies’ total expenses.
ERP’s compensation management modules can ensure a consistent application of compensation policies
across the enterprise, integrated compensation planning-budgeting and by tying compensation more directly
to performance, it ensures top performers are rewarded. Compensation management systems encompass
compensation planning/budgeting, salary administration, salary structure management, market pricing of
jobs, incentive management, etc. Typical capabilities of ERP compensation management module are shown
in Figure 20.5 and these are described below:
Compensation planning and analysis: Supports compensation planning, modeling and budgeting
process at different levels within the organisation.
Compensation structures: Manage compensation structures and levels, analyse pay equity, and as-
sess market pricing of jobs. Some leading HR solutions have partnerships with third party agencies
to provide market salary data. Market surveys are also used to validate the compensation structure of
an organisation.
Compensation workflow and approvals: HRMS systems need to support flexible workflow with
multiple levels of approvals and alerts to enforce compliance of compensation structure with company’s
policy, budgets and profitability goal. Different business units of a company can have different unique
workflows.
Incentive and reward pay: HRMS systems need to support different types of reward payments. This
can be in the form of short-term incentive pay like lump-sum payments, one-time bonuses and different
types of manual or automatic bonus calculations based on individual’s/business unit’s performance.

Fig. 20.5 ERP Human Resource Compensation Management Module

286 Enterprise Resource Planning

This can be in the form of long-term incentive payment like administering company stock options
programmes (i.e. awarding and vesting of stock options etc.)
Commission-based pay: HRMS systems need to have functionality to manage commission-based
incentive compensation plans.
Pay for performance: Leading HR solutions support a pay-for-performance process where performance
evaluations drive compensation decisions and awards.
Compliance: System needs to have right controls in place to enforce compliance with corporate and
governmental policies globally.

Enterprise Incentive Management (EIM) is becoming a separate module itself in several HR

modules as in sales area, companies typically employ a multitude of incentive schemes to encour-
age direct and indirect sales channels to sell more. Companies also need to track and manage
incentive payments so that there is no discrepancy and delays in payment for good work. EIM
applications can save companies on inaccurate commission payment.

Benefits and Payroll Module

Benefits and payment are little different topics. While Payment is more related to month-end salary, benefits
include things like medical benefits, subsidised car or housing loan, etc. that a company offers as part of
total compensation package.
Benefits Leading HR solutions can administer multiple employee benefit plans and programme structures.
Solutions support enrollment processes of employees to these different benefit plans, determine eligibility for
programme participants. Leading HR solutions also support benefits like paid leave programmes (automatic
accrual of paid leaves), medical benefit programmes, housing and car loan benefits, etc.
Payroll Human resource solutions supports different payroll-related things like:
Payroll administration: This includes things like administering payroll data and structures, employee
data, deductions/adjustments, one-time and special payments, direct deposit of payments in employee’s
bank account, etc.
Payroll processing: Payroll module of HR solutions have capabilities like gross and net payment
calculations, income tax and professional tax calculations, provident fund and gratuity calculations,
different allowances and deductions calculation, etc.
Supporting multi-country localisation and taxes: This is one area where tax rule, provident fund
rules, etc. may vary in every country. If a company decides to roll out the payroll module of a single
ERP in multiple countries, then the product needs to support localised payroll requirements, income
tax rules, provident fund and gratuity regulations, professional tax laws of multiple countries. This
is the reason that leading ERP solutions like SAP and Oracle had come up with different versions of
payroll module for different countries, i.e. SAP HR Payroll for U.S., SAP HR Payroll for UK, etc.

Talent Management/Performance Management

Talent management incorporates a variety of strategies and best practices, including competency assessment,
performance management, career planning, succession planning, training, development and fast-tracking
of high performers to identify key contributors and future leaders. Each employee’s skills, competencies,
 Human Capital Management 287

experiences should be catalogued and available online, enabling the allocation of the right employee to
the right job. Ideally, a human capital solution for talent management should provide an integrated set of
applications for strategy, assessment, competency management, performance career planning, succession
planning, learning and development. A talent management module of an HR solution as shown in Figure
20.6 helps in the areas of:
Performance management: ERP HR solutions support online performance management process
including goal setting, self-assessments, and performance appraisals by managers, 360 degree assess-
ments and calculation of performance-based compensation. Every company conducts some form of
annual employee performance review process, often in conjunction with salary adjustments. Effective
performance management starts at the top with a good enterprise performance management process.
First, a financial and business plan is transformed into a set of corporate and departmental goals. The
departmental goals are then transformed into workforce objective, i.e. individual objectives in a cascad-
ing fashion. Aligning corporate goals with individual goals goes a long way to ensuring the execution
of the overall strategy. Secondly, each individual’s performance objectives are then tied to compensa-
tion. By creating tight linkages between goal setting, performance measurement and compensation,
organisations can more quickly adapt to changing business conditions. Furthermore, by implementing
a structured performance management system, employees feel valued and tend to remain more loyal to
the organisation, thus increasing retention. Loyalty built through effective performance management
translates into improved profitability and increased shareholder value.
ERP HR performance management solutions typically offer customisable workflow for manager
control (i.e. employees save their self-assessment which automatically goes to their manager for
review), supports 360-degree performance processes and build a single performance database that
archive particular employee’s past years’ appraisals. Thus, an employee’s performance over the years
can be tracked easily. Powerful analytics of ERP HR performance management module can identify
top performers. Many companies had used ERP HR performance management solution to automate
administration of performance management process, align performance with organisational goals, link
performance to development and career planning and improve the overall quality and timeliness of the

Fig. 20.6 ERP Performance Management/Talent Management Module

288 Enterprise Resource Planning

process. ERP HR modules support configurable performance appraisal forms that are linked to goals
and competencies. ERP package allow user complete the appraisal online or offline and automatically
calculate the results of the appraisal and appraisal results can be linked to compensation calculation.
Advanced HR solutions support 360-degree surveys, upward feedback surveys, self-assessment sur-
veys, and behavioural and skills assessments and these assessments be included as part of the review
process or career development process.
Competency management: Competency models helps to understand what level of skills are needed to
do a particular jobs. It is important to assess employee competencies against the models. Competency
descriptions include exemplary behaviours related to the jobs that the competency is linked to. For
example, exemplary behaviour for an experienced plumber can be that he should be able to complete
100 meters of plumbing in 8 hours shift. Leading HR solutions comes with industry-specific best
practice competency models and can do skills and gap tracking by measuring employee competencies
against these competency models. Competencies can be tracked and rated. Employees can continually
update their competencies as and when they attend a new training or learn a new skill. Leading ERP
HR solutions can provide competency-specific coaching tips, suggested learning options and learning
roadmaps.
Career development planning: ERP HR modules support the development of long-term career de-
velopment plans of employees. Leading ERP HR solutions support a relevant best practice library of
developmental plans that can be modified to fit a particular business or employee need. The solutions
offers flexibility to either allow the employee to create the plan or for the company to create and pub-
lish predefined career plans. The solution allows managers and employees to create and track career
development plans and these plans be created automatically based on current skills, competencies,
future job, and identified gaps and the package can track progress against the plan with associated
reminders and feedback tools. Advanced HR solutions allow targeting high-potential candidates, put-
ting them on a fast track, and providing a separate coaching and career management programme for
them and can have specialised mentoring programme for them.
Succession planning: ERP HR solutions support succession plan creation and management for key
positions, including key competencies, key skills, and current incumbent and potential candidates.
While doing such planning, ERP HR modules also consider work history from outside the current
company. The ERP package can support successor searching, allow employees to search, view, and
apply for open jobs.
Goal alignment of organisation and individual: Leading HR solutions provide a best practice library
of goals that can be modified and the package helps in goal alignment, i.e. product support linking
goals to ensure individual, team, business unit, and enterprise goals are aligned. Users can view these
goals at all levels of the organisation, including status and completeness. Goal assignment can be
done by direct manager and employees and there can be automatic approval workflow, i.e. goal set
by employees need to be approved by employee’s manager. The ERP package can track user progress
against goals, track goal setting completion status, and provide warnings, if there is big difference
between target and what is achieved so far. The solutions also support goals to be linked to a balanced
scorecard and data from other systems can be integrated into the scorecard.

Learning Management
For some ERPs, learning management module is a part of talent management, for some ERPs it is a different
sub-module under HR. Learning management module helps in administering employee training programmes
and course offerings as well as delivers online learning programmes and content. As shown in Figure 20.7,
different areas of learning management solution are discussed below:
 Human Capital Management 289

Fig. 20.7 ERP HR Learning Management Areas

Registration: ERP HR module allows its employees to register for a course/training. Managers can
register employees they supervise and registration can be restricted based on prerequisites.
Course catalogue: The ERP package provides a searchable course catalogue.
Scheduling instructor-led training (ILT) courses: ERP can support conducting different instructor-
led training courses, scheduling of training rooms – instructors—training materials, etc. Advanced
learning solutions can track instructor qualifications to match with appropriate courses.
Supporting training financials: ERPs can support tracking training costs, payments of training fees
in multiple currencies, multiple pricing for different users, and multiple forms of payments.
Tracking: The ERP package can track learner progress.
Content management: The packages help in managing learning content by supporting content creation
(i.e. authoring of content), content integration (Integrate other third party contents), etc.
Learner assessment: The packages have features for testing learner’s learning levels.
Collaboration: Learning solutions of today provides advanced collaborative learning features. This
can be in the form of synchronous collaboration like integrations with virtual classroom providers,
setting up virtual classroom, etc. This can be also in the form of asynchronous collaboration in the
form of discussion groups, chat, communities, blogs and wikis.
Reports: The package enables different types of analysis and reports that can be generated about
learning and there are different ways to distribute these reports to managers, executives, etc.

Personnel Management
HR packages also need to handle personnel management issues like:
Labour relations: This includes supporting processes for grievances and discipline in the organisa-
tion.
Non-employee administration: This includes tracking and managing non-payroll workers such as
contractors, temporary workers, consultants, etc.
Maintaining detailed employee records
290 Enterprise Resource Planning

Employee Relationship Management (ERM) and Employee Self-service

ERM seeks to enhance the relationships of the employee to the enterprise, managers, co-workers and exter-
nal parties. A common way of achieving this is by deploying employee portals that connects employee to
business processes, relevant information, resources and people. ERP can achieve higher levels of customer
satisfaction by delivering online services and making employees more productive. Leading ERP HR solu-
tions provide different technologies here like:
Employee portal: The package offers a personalisable portal designed for employee communications,
content management, and integration to self-service applications. This is discussed in detail in Chapter
32 under Employee Portal.
Employee self-service: Leading ERP HR solutions can deliver comprehensive employee self-service
applications including benefits, maintenance of personal data, leave application, accessing pay slip
and payroll data, registering to a new training, etc. Employees maintain all these data and do all these
transactions themselves.

Human Capital Management Analytics

Human resource solutions can also support different analytics/KPIs and reports needed for effective man-
agement of HR in an organisation. Most of the leading HR packages provide these analytics out of box as
part of their ERP solution and, in some cases, as part of their business intelligence solution. Table 20.3 is
an example of such KPIs/reports for different HR modules.

Table 20.3 Human Capital Management Analytics

HR Analytics area Typical KPIs/Reports

Recruitment Cost per hire
Time to fill vacant positions
Onboarding Onboarding efficiency
Attendance and leave management Attendance percentage
Unapproved leave percentage with drilldown
Compensation Salary comparison with industry benchmarks
Salary increase %
Number of promotions in a year
Learning management Average number of training days per employee
Number of “No show” cases, i.e. employee registered, but not appeared on
the training day
Training feedback
Training budget
Employee relationship Portal usage rate
Workforce scheduling Workforce utilisation
Number of rescheduling cases
 Human Capital Management 291

LEADING HR SOLUTIONS FROM ERP PACKAGE VENDORS:

SAP AND ORACLE
SAP and Oracle are two leading vendors in HR solution space. In this chapter we discuss the SAP HR solu-
tion in detail and give an overview of Oracle HR offerings.

SAP Human Resource Solution

SAP HR solution is part of SAP’s ERP offering. Currently SAP’s offerings are mainly divided into two
main areas:
Talent management
Workforce process management
Talent Management Talent management comprises four key HR processes: Recruitment, Pay for
performance, Educating and developing talent, and Identifying and growing future leaders. This enables the
organisation to find the best people, leverage their talent in the right place and right time, align employees
and teams to corporate goals, maximise the impact of training, and retain and promote top performers. The
solution has following components:
Recruitment: SAP e-Recruiting in SAP ERP HR enables the organisation to build pools of potential
talent, resulting in better hires and a more efficient hiring process. Processes in this module enable
applicants and candidates to self-register and maintain their information in a talent warehouse that
serves as an effective sourcing channel, provides recruiters functionality to find potential hires quickly,
intelligent electronic screening, filtering, sorting, ranking, advanced applicant tracking, analytics
(to measure the effectiveness of the overall recruiting and hiring processes), etc. Candidates can use
the talent warehouse to upload resumes and CVs, register their interests and skills, and even create
a personal page and using this information the organisation can establish and maintain long-term
relationships with candidates. This module also supports recruiter from the job requisition stage to
the closing of the job offer focusing on tasks that must be completed for a specific requisition by a
specific date and trigger the required workflow as required.
Career Management: Enables each employee to manage their career paths and aspirations, either
through self-service capabilities or as a result of planning with their managers. Profile match-ups against
positions can determine skill and knowledge gaps which, in turn, can be tied directly to training plans
to fill necessary qualifications.
Succession Management: Enables a company to identify and track high potential employees and
implement development plans to ensure they are prepared to assume future leadership roles. A company
can also identify specific positions as key and target specific employees as potential successors.
Enterprise Learning: Delivers training, education, and knowledge to employees to ensure that they
have the right skills and information necessary to do their jobs effectively and this is integrated with
employee development plans and individual objectives. SAP also offers a Learning Portal as a part
of its offering. This web-based portal provides learners with personalised access to information about
courses and learners can launch web based courses from the portal. Learners can also enter virtual
learning rooms and collaboration rooms from the portal.
Employee Performance Management : This helps in employee reviews and appraisals, and supports
performance-oriented compensation process. This integrates corporate goals and strategies with team
and individual goals as well as integrates management by objectives.
Compensation Management: This supports several reward strategies such as performance- and
competency-based pay, variable pay plans, and long-term incentives. This also helps in comparative
analysis of compensation packages, using internal and external data.
292 Enterprise Resource Planning

Workforce Process Management This includes essential workforce processes such as employee
administration, payroll, time management, and legal reporting. The solution has following components:
Employee Administration: Manages all employee related data.
Organisational Management: Manages organisational structures, policy, organisational development
capabilities including organisational planning and simulation, organisational development, activity
analysis, and job analysis. It also has ability to simulate, analyse, and experiment with proposed or-
ganisational changes and previous organisational models.
Benefits Management: Provides administration of all types of benefit plans supported by a full range
of self-services to enable employees to more effectively manage their own benefits options.
Time and Attendance: Support processes for planning, managing, and evaluating the working time.
Self-service applications can be used to enter leave data, record working times, display key leave
information, etc.
Payroll and Legal Reporting: Handles all payroll processes, supports legal regulations and ensures
compliance with regulatory changes. This supports payroll accounting, tax, social insurance, travel
expenses administration, incentive wages, loans, etc. Enables employees to easily change their ad-
dress, change their banking information, display and print payment slips using employee self-service
functionality for payroll. It provides several country versions. Key functionalities includes: Basic pay
calculation, absence valuation, legal deductions (taxes, social security), benefits processing, etc.
HCM Processes and Forms: Automate paper-intensive processes such as hiring, termination, organi-
sational reassignment, leave, etc. This accelerates data entry and all involved business roles such as
affected employees, affected managers and HR professionals can be informed through workflow.
Oracle Human Resource Solution Like SAP, Oracle is also a leading vendor in HR solution cov-
ering all end to end HR processes. Table 20.4 gives a brief overview of different Oracle HR modules and
solution areas.

Table 20.4 Oracle HR Modules

Solution Areas Modules

Global Core HCM Human Resource
Payroll
Advanced Benefits
Workforce Management Time and Labour
Workforce Scheduling
Workforce Service Delivery Self-service HR
Oracle Portal
Help Desk for HR
Integrated Talent Management iRecuitment or Electronic Recruitment
Incentive
Compensation Workbench
Learning Management
Performance Management
HR Analytics Oracle HR Analytics
Daily Business Intelligence for HR
 Human Capital Management 293

STRATEGIC VS. OPERATIONAL HR PROCESSES AND HR

OUTSOURCING
Managing human resource processes is extremely critical for companies today for retaining their best talents,
for attracting the best talents from market and to keep its employees motivated. Increasingly, companies
are looking at which of the HR processes are critical for company’s survival and they need to manage
themselves and which one of them are routine activities that can be outsourced to a third party. As shown
in Figure 20.8, the list below shows a grouping a representative list of HR processes in two categories:
Strategic and Operational.

Fig. 20.8 Strategic vs. Operational HR Processes

Strategic Processes
Performance management process design
Compensation and reward planning
Planning job roles
Recruitment process design
Workforce planning
294 Enterprise Resource Planning

Learning management
Employee satisfaction measurement, designing employee motivation schemes

Operational Processes
Employee record management
Leave and absence management
Time and labour management
Tax and compliance services
Payroll
Background checking and reference checks before recruiting
Health and welfare benefits administration
Retirement benefits (Like managing Provident fund, Gratuity, etc.)
Increasingly companies are outsourcing most of the routine operational processes mentioned earlier to
third parties. There are global HR outsourcing companies like Hewitt Associates, Mercer, etc. and thousands
of other companies around the world who provide such HR outsourcing services.
HR outsourcing has been discussed in this chapter as a company’s HR module of the ERP system may
have to be integrated with the systems of outsourcing service providers for regular processing of company-
specific data (say, payroll data).

EMPLOYEE HEALTH AND SAFETY

Employee Health and Safety (EHS) is an emerging area for ERP human resource. Leading ERP providers
like SAP and Oracle have started coming up with specialised EHS module as part of their ERP application.
While EHS modules have sub-modules both in the area of employee safety and product safety, in this chapter
employee safety related features are discussed. EHS module supports systems and processes that ensure
appropriate health and safety controls are incorporated into all operations. This includes provisions for the
systematic identification, evaluation, and control of potential workplace hazards, including potential exposure
and health risks related to chemicals and emissions. EHS software support can span across all processes in
which employees are interacting with product and manufacturing processes, such as R&D, manufacturing,
transportation, storage, and disposal. It has the ability to sense and respond to potential hazards.
Leading ERP solution vendor SAP has two EHS modules to support employee health and safety concerns
and these are:
Industrial Hygiene and Safety
Occupational Health

Industrial Hygiene and Safety

This EHS sub-module supports the full range of industrial hygiene and safety processes like
Risk assessments of different tasks or different work areas and creating exposure logs: what is the
chance of an employee getting exposed to some particular risk depending on task or work area. For
example, an employee working in an underground mine is having higher risk exposure than someone
working in surface mine, i.e. underground mine has higher risk as a work area. In the similar way, an
employee working at a construction site at a particular right is working in a risky working area and
having high risk as per the exposure log.
Incident management: If any accident happens then managing the entire incident from reporting, taking
follow up action to finally cost accounting for the incident.
Safety management of specific work areas.
 Human Capital Management 295

Risk assessment and analytical functions enable to quickly detect risk in a variety of situations for timely
assessment, analysis, and documentation. The application also makes it easy to generate and manage standard
operating procedures for handling various hazards and to handle incidents and accidents while ensuring
legal compliance. This module also provides procedures and practices for performing and documenting site
inspections and makes it easy to generate, track, and control all corresponding actions. Reports like exposure
logs, personal exposure logs, risk assessments, hazardous substance inventories, and incident and accident
logs can be generated.
Figure 20.9 shows a typical industrial hygiene and safety activities of one of the leading ERP
modules.

Fig. 20.9 Industrial Hygiene and Safety

Occupational Health
This module equips occupational health professionals with the tools, functions, and flexibility they need to
provide for the health and well-being of employees. The application enables full-scale health management,
which benefits individual employees. Medical processes for workers can be managed based on their exposure,
injury or illness, and personal, demographic, or health parameters. EHS also helps to establish parameters
for scheduled medical examinations and testing using defined protocols. These results can be maintained.
Support case management based on results and guidelines generates reports and epidemiological analyses.

Summary
In this chapter different human resource processes and corresponding ERP human resource module func-
tionalities are discussed. Typical ERP sub-modules in human resource area are: Recruitment Management;
Time, Attendance and Leave Management; Workforce Scheduling; Compensation Management; Benefits
and Payroll; Talent Management/Performance Management; Learning Management; Personnel Management
and Employee Self-service. Human resource portals (employee self-service) are effective tools for employee
self-service and improving employee productivity.
296 Enterprise Resource Planning

HR systems also provide daily human resource related reports and KPIs that can be monitored to see the
efficiency of company’s HR operations. These are covered under HCM analytics.
In this chapter two leading HR solutions from two ERP package vendors SAP and Oracle have also been
discussed.
Strategic vs. Operational human resource processes are discussed in the chapter. Increasingly, operational
HR processes are outsourced to specialised outsourcing service providers.
The chapter ends with the discussion on one emerging human resource application area called employee
health and safety that takes care of risk and safety issues at workplace. Most of the leading ERP vendors are
coming up with EHS module as part of their application suite.

Exercise
I. Objective Type Questions
1. What is position management?
2. What is labour forecasting? This is a part of which HR module?
3. Give some common examples of recruitment analytics.
4. What is meant by labour tracking?
5. What is dynamic rescheduling?
6. How ERP systems help in designing compensation structure?
7. What is enterprise incentive management?
8. What is succession planning?
9. How do ERPs help in performance management?
10. What is employee self-service?

II. Descriptive Type Questions

1. How can ERP solutions help in time, attendance and leave management of employees?
2. Explain the capabilities of workforce scheduling module of ERP.
3. What are the functionalities capabilities offered by compensation management module of an ERP solu-
tion?
4. What are typical capabilities required in benefits and payroll from an ERP? How do ERP solutions help in
this?
5. How can ERP solutions help in talent and performance management of employees?
6. Explain the capabilities of learning management module of ERP.
7. What functionalities capabilities are offered by personnel management module of an ERP solution?
8. What is employee self-service?
9. Give some examples of HCM analytics.
10. Give the module overview of SAP and Oracle HR solutions.
11. What are the strategic operational processes of human resource? Which processes today’s organisations are
outsourcing and why?
12. What is EHS? What capabilities can an ERP solution offer under EHS module? Why is it important for
organisations?

III. Fill in the Blanks

1. HCM stands for _______________ _____________ _______________.
 Human Capital Management 297

2. EHS stands for _______________ _____________ _______________.

3. HR processes can be grouped as _____________ and _____________.
4. Interviewing is a part of ERP ___________ management module.
5. Labour tracking is a part of ERP ___________ ___________ module.

IV. State Whether the following Statements are True or False

1. 360 degree performance evaluation is a part of the ERP performance management module.
2. Succession planning is a part of learning management.
3. Employee self-service is part of personal management.
4. Planning job roles is a strategic HR process.
5. Payroll is a strategic HR process.

V. Assignments
Study in details the HR modules of three leading ERP solutions, i.e. SAP, Oracle and Peoplesoft. Note down all their
modules and sub-modules. What capabilities they offer? Draw similarities and differences of their capabilities.
 21
Financial Management
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
ERP Financial Application
Financial Modules in detail
Financial Accounting
Management Accounting
Financial Supply Chain Management
Treasury Applications
Emerging Areas in Financial Management
Budgeting/Planning
Consolidation
Business Performance Management (BPM) and Balance Scorecard
Activity Based Costing (ABC)

INTRODUCTION
Financial Management is one of those areas which is most commonly implemented in any ERP project and
is one of those modules which get implemented first. This is due to transaction volumes and legal require-
ments—any company will like to automate the process. Today’s ERP systems made the life of financial
people simple and it is no more sleepless night for closing month end or year end transactions. Finance is
one of those ERP modules which is highly integrated and any transaction done in any other ERP module
can have its financial application as shown in Figure 21.1.

ERP FINANCIAL APPLICATION

ERP financial applications broadly have offerings as mentioned in Table 21.1. While depending on the ap-
plication (SAP or Oracle or any other), the module names may change, any ERP application helps in the
areas of financial accounting, management accounting, accounts payables, receivables, tax accounting, etc.
as shown in Figure 21.2.
 Financial Management 299

Fig. 21.1 Finance is a Highly Integrated ERP Module

Table 21.1 Offerings of ERP Financial Application Categories

Application Category Application Description

Accounts Payable This application automates and streamlines the invoice-to-payment cycle. This helps
in receiving invoice from vendor (by electronic way also), validating vendor invoices
and executing the payment process (supports electronic payment as well by EDI or
automatic bank debit).
Accounts Receivable/ This application automates and streamlines the payment receipt process from customer.
Collection Management This helps in generating and sending invoice for customer (by electronic way also), re-
ceiving payment (supports electronic payment as well by EDI or automatic bank debit)
and helps in handling any payment-related disputes. These applications manage risk in
granting credit to customers, analyse accounts receivable for delinquency and can send
reminders to customers for balance collection.
Accounting General ledger is the heartbeat of businesses of all types. This maintains detailed set of
books for the organisation, trial balances, balance sheet, etc. These systems also provide
a number of reports which may have different audit implications.
Costing and Profitability These applications enable organisations to update and analyse production and operating
costs by product, customer order etc. Some of the ERP applications support activity-
based costing. This application can determine which customers are most profitable or
assess product profitability.
Reporting different Financial applications are needed for accounting and reporting for different employee
expenses expenses for travel, etc.
Budgeting ERP financial tools are also used for creating annual budgets of an enterprise, specific
project budgets, revenue and expense forecasts, etc.
(Contd)
300 Enterprise Resource Planning

(Contd)
Consolidation Consolidation (or aggregation) of financial data (like general ledger) across multiple
companies/business units/legal entities helps in business consolidation.
Financial reporting ERP financial module also helps in producing financial statements as per regulatory
compliance requirements and conformance with global accounting principles (e.g.
GAAP and IFRS).
Internal control and audits ERP modules support different internal controls (checks and balances) and audits for
business.
Tax planning ERP Tax module ensures compliance with various tax jurisdictions and tax types from
corporate tax provision to calculating sales tax and payroll taxes. This can estimate tax
liabilities, helps in e-filing of returns and can report on taxing.
Treasury and cash ERP financial software helps in managing treasury operations, managing cash and
management investments, monitoring liquidity, managing financial risk, and ensuring compliance as
per different financial standards.

Fig. 21.2 The Elements of Financial Accounting

FINANCIAL MODULES IN DETAIL

Traditional ERP financial applications can be broadly classified in four categories as shown in Figure 21.3
and these are:
Financial accounting applications
 Financial Management

Fig. 21.3 ERP Financial Module

Management accounting applications

Financial supply chain management applications
Treasury applications
These four sets of applications are described in brief below:

Financial Accounting
This module of ERP helps in financial accounting as per local accounting standards and as per international
accounting standards (US-GAAP, local GAAP, etc.). This module helps in maintaining different ledgers, trial
balances and is integrated with accounts receivable and payables management. The module automates finan-
cial transactions and help speedy period end accounting tasks and financial closing cycle. This module also
complies with different regulatory compliance standards. This helps in managing following processes:
General Ledger (GL): This records all business transactions and is integrated with other operational
areas of a company as most of the business transactions in a company can have accounting implica-
tions.
Accounts Receivable (AR): This component of ERP financial accounting module manages and records
all customer accounting data. From this component a lot of useful reports on customer’s payment his-
tory can be obtained like for which customers payment is due more than 30, 60 or 90 days.
Accounts Payable (AP): This component of ERP Financial accounting module manages and records
all vendor accounting data.
Assets Accounting: This component maintains the accounts of fixed assets according to company
specific different depreciation standards and accounting rules.
Contract Accounting: This is a specialised type of accounting requirement for managing contracts,
i.e. managing high-volume, recurring time or quantity-based billing.
302 Enterprise Resource Planning

Bank Accounting: This component manages different bank transactions of the company like process-
ing of incoming and outgoing payments, cheques, etc.
Cash Journal Accounting: This component manages all cash transactions.
Inventory Accounting: Helps in different types of inventory (raw material, work in process, finished
goods, etc.) valuation and inventory accounting according to different principles (like first-in first-
out).
Tax Accounting: Supports the calculation and reporting of taxes on sales and purchases.
Creation of different Financial Statements: Financial module helps in creating different financial
statements as per company laws and country-specific regulations.

Management Accounting
Management accounting module of ERP helps in all type of cost and valuation related accounting like profit
centre accounting, cost centre accounting, etc.
Profit Centre Accounting: Supports accounting of different profit centres by assigning costs, revenues
and balance sheet items to respective profit centre.
Cost Centre Accounting and Budgeting: Supports accounting of different cost centres by assign-
ing different cost elements to them; budgets and record costs against the cost centre and analyse
variances.
Project Accounting and Budgeting: ERP Management accounting supports detailed project finan-
cial planning and budgeting and helps project managers to execute the project on time and within
budget.
Product Cost Accounting: ERP cost accounting module helps in calculating cost of goods manufactured
(COGM) or cost of goods sold (COGS) with details like cost of raw material, cost of manufacturing,
cost of distribution, etc. This module works very closely with production management module of ERP
as product costing depends a lot on manufacturing process. In an engineer-to-order (for example, ship
building) or make-to-order (for example, making special grade of steel for a customer) environment,
the focus is on controlling the individual sales order. In a make-to-stock environment (for example,
making soap or detergent type of product), the focus is on controlling the individual production or
process order.
Transfer Pricing: Exchange of goods and services within different divisions of a company is a com-
mon practice – the issue is how to value such transactions. ERP supports different transfer pricing
approach for valuating the goods and services exchanged between these units.

Financial Supply Chain Management

ERP financial supply chain management applications help in receivables and collections management
processes, thus reducing operating costs and improving cash flow. These solutions also help in resolving
payment (invoice) disputes, reducing the collections cycle time and customer credit risk, accelerating cash
flow and lower operating expenses.
Self-service Portals for Customers: These portals provide self-service functions via internet and
enable customers access invoices, account status, and payment information. These portals can also
integrate with customer or supplier portals.
Collections Management: This tool of FSCM has a variety of tools to ensure that collections from
customer happen on time and include things like payment reminders, collection strategies, collection
controlling, etc. This also helps in effective management of past due accounts and faster collection of
delinquent payments though prioritised and personalised collections efforts.
 Financial Management 303

Credit Management: This module of FSCM helps in managing credit limits to customers by analys-
ing customer credit information, employs sophisticated tools to analyse customer credit worthiness
and helps to avoid customer overdue accounts and losses due to bad debt.
Dispute Management: This FSCM tool helps to resolve all invoice and payment related disputes
with supplier or customer quickly and, thereby, reduces days’ sales outstanding (DSO) and improve
cash flows

Treasury Applications
Treasury module of ERP helps in managing cash, liquidity and bank interactions. Focus of this module is
mainly in the areas of
Cash and Liquidity Management: Helps monitor and manage cash flow and liquidity as well as do
cash forecasting. The ERP system provides the opportunity to determine liquidity forecast at different
levels of the company.
Financial Risk Management: Ensures adherence to regulatory compliance and financial reporting
standards.
Managing Bank Interactions: Streamline all payment processes and corporate-to-bank communica-
tions through online connectivity with banks via secure electronic payment networks and thus, reduces
bank fees and cost of cash transfers. This also helps in centralised control of banking balances, cash
management, and payments. This enables a company to connect to its bank, track the entire payment
life cycle of a transaction, and monitor payment status and bank statement.

EMERGING AREAS IN FINANCIAL MANAGEMENT

While ERP financial modules support traditional transaction-intensive areas of finance like financial and
management accounting, cost accounting, treasury operations, etc. Historically these modules fall short in
the areas of planning, budgeting, etc. Up to 90s, ERPs were not strong in these areas and only in the last
decade leading ERP vendors started coming up with specific applications in this category. As planning and
budgeting need lots of historical data crunching, these solutions uses data warehousing and business intel-
ligence solution at its heart. These solutions mainly fall in following four categories:

Budgeting/Planning
Financial budgeting is a core process for most business that shows a high level of estimate of expenses
under different headings, expected income sources and projected fund flows in future. Typically this process
is done once in a quarter or year and spreadsheet is the most popular tool for doing this. Many companies
are replacing spreadsheets with structured budgeting software that can link budgeting to the measurement
and evaluation of business performance. This software also can crunch lots of historical data and have fore-
casting capability to estimate future budgets. SAP’s Business Planning and Simulation (BPS) is a leading
solution in this category.

Consolidation
These applications combine heterogeneous general ledgers for the purposes of statutory reporting and
continued need for consolidation in light of the wave of mergers and acquisitions. Hyperion is a market
leader in this application category. SAP’s Business Consolidation Service (BCS) is getting momentum here
while Oracle also has their offering here.
304 Enterprise Resource Planning

Business Performance Management (BPM)

Of the various BPM applications, balanced scorecards are probably the best known. The balanced scorecard
methodology was developed by Kaplan and Norton and seeks to capture the performance of an organisation
from four key dimensions: financial, customer, internal, and learning and growth and thus emphasises the
role of nonfinancial indicators as predictors of financial performance. This creates the need for bringing
together financial and non-financial metrics within the same application (i.e. cross-functional BPM) and
hence, BPM is an excellent complement to a financial analytic applications suite.

Activity-based Costing (ABC)

All the major financial/BPM suite players (e.g. SAP, PeopleSoft, SAS, Oracle, and Hyperion) offer ABC or
activity-based management (ABM) as part of their suites.

Corporate Performance Management (CPM)/Enterprise Performance

Management (EPM)
These four sets of applications discussed earlier (BPM, ABC, Budgeting, Consolidation) together are also
known as corporate performance management (CPM) or enterprise performance management (EPM) applica-
tions. CPM helps in business decision-making, combining business strategy alignment with business planning,
forecasting, and modeling capabilities. It helps mapping a structured set of data against pre-defined reports,
alerts, dashboards, analysis tools, KPIs, etc. to monitor and improve business processes based on corporate
strategic objectives. CPM starts with developing high-level corporate goals and subsequent pre-defined KPIs,
measures actual results against the KPIs and represents this comparison in a scorecard to be reported to
management and feeding these results back into the business modelling process for corrections in the next
planning cycle. CPM leverages the methodologies such as the balanced scorecard or activity-based costing
to do this. CPM solutions can be a great complement to existing ERP and transaction systems–integrating
data from multiple sources, providing a common view across the enterprise and enabling an integrated fi-
nancial and performance management process that aligns individual goals with corporate objectives. These
solutions typically help in the areas of:
Performance Scorecarding: To help companies set and communicate goals, establish key performance
metrics and accountability and continuously measure performance against company goals and objec-
tives.
Business Modelling: For doing activity or value-based modelling and validating of strategies and
plans against resource constraints.
Planning, Budgeting and Forecasting: Allowing companies to move away from the "yearly" budget
and embrace the concept of continuous planning to make smarter business decisions with dynamic,
event-based plans that provide improved visibility and collaboration in real time.
Financial Consolidation and Reporting: That helps customers reduce financial consolidation and
reporting cycles.
Leading CPM/EPM vendors and solutions are:
SAP SEM (Strategic Enterprise Management)–Have modules like business planning and simulation
(BPS), business consolidation service (BCS), corporate performance management (CPM) etc.
Oracle budgeting solution
Specialised vendors like Brio, Hyperion, SAS (Strategic Vision) etc.
 Financial Management 5

Summary
ERP Financial management module helps in traditional financial areas like financial accounting, management
accounting, treasury applications, financial supply chain management, etc.
Financial accounting helps in the areas of accounts receivables, accounts payables, general ledger, tax
accounting, bank accounting, inventory accounting, etc.
Management accounting has specific focus on profit centre accounting, cost centre accounting, product cost
accounting and project accounting, etc.
Financial supply chain management focuses on collection management, credit management, debtors
management, etc.
Treasury management focuses on cash, liquidity management and risk management.
Financial management is a highly integrated ERP module and transactions done in other ERP modules can
have their financial implications.
Emerging areas of financial management are: budgeting, consolidation, activity-based costing and business
performance management.

Exercise
I. Objective Type Questions
1. What are the four broad categories in which financial applications can be classified?
2. What is meant by AR and AP applications?
3. What is asset accounting?
4. What is transfer pricing?
5. What are the types of applications under financial supply chain management?
6. What is dispute management?
7. What are the types of treasury applications?
8. What is the scope of business consolidation applications?
9. What are the four areas where corporate performance management/enterprise performance management
applications help?
10. Name some leading EPM/CPM vendors.

II. Descriptive Type Questions

1. What are the different categories of applications under ERP financial module? Explain each of them. What
are the four broad categories in which these applications can be classified?
2. What are the different areas under financial accounting? Explain different areas of financial accounting?
3. What is management accounting? What are the different sub-applications under this? How ERP helps in
management accounting?
4. Explain financial supply chain management (FSCM). What are the different ERP FSCM areas?
5. Explain ERP treasury applications.
6. What are the emerging areas of ERP financial applications? How financial budgeting exercise is facilitated
by ERP applications? What are the business consolidation applications?
7. What are the different CPM/EPM applications? Explain their functionality.
306 Enterprise Resource Planning

III. Fill in the Blanks

1. FSCM stands for __________ _________ __________ __________.
2. ABC stands for ___________ __________ ___________.
3. ABM stands for ___________ __________ ___________.
4. CPM stands for ___________ __________ ___________.
5. BPM stands for ___________ __________ ___________.
6. EPM stands for ___________ __________ ___________.
7. Project cost accounting is a ________ accounting tool.
8. COGS stands for _______ ___________ _________ __________.
9. Financial risk management is a part of _________ application.
10. SAP SEM stands for SAP ________ ________ _________.

IV. State Whether the Following Statements are True or False

1. Tax accounting is a type of management accounting application.
2. Product cost accounting is a type of management accounting application.
3. Transfer pricing is a type of financial accounting application.
4. Dispute management is a part of FSCM application.
5. FSCM applications help in managing cash, liquidity and bank interactions.

V. Assignments
Study in details the finance modules of two leading ERP solutions, i.e. SAP and Oracle. Note down all their
modules and sub-modules. What capabilities they offer? Draw similarities and differences of their capabilities.
 22
Procurement and
Inventory Management Chapter
Through ERP

Learning Objectives
In this chapter we will discuss the following concepts:
Procurement
Procurement process
How ERPs support procurement process
Some important functionality of ERP systems to support procurement process
Procurement process variants for different types of procurement
Procurement of materials and services
Procurement of direct and indirect items
Commodity procurement
Government procurement
Procurement maturity model
Master data for ERP procurement
Key performance indicators for ERP procurement
Offerings from two leading vendors in procurement area
Inventory Management
Inventory management process
Concept of inventory management pyramid
Inventory management processes in ERP
Offerings from two leading ERPs in inventory management area
Key performance indicators for ERP inventory management

In this chapter two important logistics processes for any organisation, i.e. Procurement and Inventory Man-
agement have been introduced. For many companies, these processes are the major drivers for implementing
a new ERP system. This chapter starts with procurement followed by inventory management.
308 Enterprise Resource Planning

PROCUREMENT
Procurement Process
Procurement is the process of sourcing material from vendor, inspecting it and finally paying the vendor for
accepted materials. Procurement is a requirement for almost every organisation which is why it is considered
as a very fundamental module of any ERP system. Procurement being a transaction-intensive process, it
is one of the most widely used ERP module. Figure 22.1 shows steps of a typical procurement cycle and
these steps are detailed below:
Determining what to buy and how much—Procurement planning: The first step of procurement
cycle is deciding what items to buy and of how much (quantity). This process is also called procurement
planning process and depending on type of items, the process differs. For regular production items i.e.
items that are needed for producing finished goods, a detailed material requirement planning process
is needed, whereas for one-time purchases and items that are not needed regularly, user department
can create a purchase requisition. For example, a company manufacturing car will need tire, battery
and engine regularly for making the car and these items need to be planned by a material requirement
planning, process, whereas it may need some engineering spares for its machines only in case there is
a breakdown and for these the engineering department can create purchase requisitions as and when
required.

Fig. 22.1 Procurement Cycle

 Procurement and Inventory Management Through ERP 309

Determination of the source of supply and selecting vendor: Determining the right source of supply
is the next challenge for buyer. Once buyer identifies few technically capable vendors, he asks for a
price quotation and delivery terms from them. Once price and commercial terms of different vendors
are compared, purchaser finally selects the vendor for the particular item.
Purchase order creation: In this step a purchase order is created with item details, quantity, price,
delivery terms, etc. This is a legal document between the company and the vendor.
Goods receipt: In this step goods are received. There can be several checks during goods receipt
process like quantity check (whether the same quantity had been delivered as asked for), quality check
(whether goods are of proper quality as per specification provided), etc. Goods receipt is generally
happens at factory level where a goods receipt posting to stock with reference to a purchase order is
done.
Processing vendor payment and invoice verification: The final step of procurement process is pay-
ing vendors after verifying the invoice submitted by him.

How ERPs Support Procurement Process

Figure 22.2 explains how ERP can make these processes more efficient.
Determining what to buy and how much—Procurement planning: ERPs support different strate-
gies of procurement planning and automatic creation of purchase requisition based on finished goods
requirement and past sales. ERPs also support manual creation of purchase requisition in the system
for requirements not regular in nature. Generally for material planning, an MRP procedure need to
be setup in the material master and based on this setting, the ERP system automatically generates
purchase requisition.
Determination of the source of supply and selecting the vendor: ERP systems help buyers determin-
ing possible sources of supply, provided vendor information is maintained in the system and vendor
material linkage (i.e. which vendor supplies what material) is available in the system. The system
supports creation of requests for quotation (RFQs). RFQs can be sent to vendors and their responses
can be entered into the system. The system helps in selection of vendors by making price comparisons
between various quotations.
Purchase order creation: The ERP system facilitates data entry for purchase orders, i.e. as soon
as the vendor and material code is entered, the system populates relevant vendor and material
details (vendor name, address, tax code, material description, UOM (unit of measure), etc.) from
masters. Purchase order creation is also facilitated by copying relevant terms and conditions from
condition master. The system also calculates pricing discounts based on conditions and apply
the same in purchase order. The order status can be monitored online to see whether goods or
invoice have been received for the relevant purchase order item. The system also supports send-
ing purchase order electronically to vendors.
Goods receipt: The ERP system supports different types of goods receipt scenario against pur-
chase order, without purchase order, etc. and different kinds of checks can be activated while
receiving goods. The system can compare the goods receipt quantity with the purchase order
quantity, can reject goods if the quality specification is not met, can block materials, can block
vendors, etc. There can be several checks during goods receipt point like whether the delivery
is the same as what is ordered in the purchase order and the quality of the items. When goods
receipt is against a purchase order, the ERP system suggests data (like items and quantity) from
the purchase order and this makes it easier to enter the goods receipt and check over deliveries
and under deliveries. With goods receipt, the purchase order history is automatically updated
310 Enterprise Resource Planning

Fig. 22.2 Procurement Cycle—How ERP Makes this Process More Efficient

and purchasing department comes to know that if there are late deliveries. Goods receipt also
create accounting document and value of the stock is updated. Goods receipt can also happen
without reference to the purchase order for reasons like urgent purchase.
Quality inspection and shelf life expiration check: Goods receipts from vendor are gen-
erally put under quality inspection stock as most of the materials need to undergo quality
inspection before it is used. However, there can be exceptions to this, i.e. for self-certified
vendors and items, there is no quality inspection and materials are directly delivered to the
shop floor. Materials from new vendors generally go through stringent quality inspection.
Shelf life expiration check may be important for certain items and ERP systems support
this provided the expiry date or production date of the material at the time of goods receipt
is entered in the system. The ERP system checks while receiving goods that whether the
minimum remaining shelf life meets the requirements entered in the purchase order and in
case of an exception, it issues a warning or error message. The shelf life expiration date is
printed on the goods receipt/issue slip.
Under-delivery and over-delivery: When goods are received with reference to a purchase
order, the ERP system proposes the purchase order quantity of each item during goods
receipt. If the actual receipt quantity from the vendor is different from that, then the ERP
 Procurement and Inventory Management Through ERP

system compares the quantity of goods received with the quantity in purchase order and,
thereby, identifies under-deliveries or over-deliveries. In purchase order item, a percentage
value for the under-delivery or over-delivery tolerance can be maintained, and if quantity
of goods receipt is within these tolerance limits, then goods can be accepted.
Processing vendor payment and invoice verification: This is the final process of procurement
cycle after which vendor payments are made and this process is typically done by accounts
department of the company. ERP systems facilitate this process in different ways like:
Invoice entry: As invoice is entered with reference to a purchase order, the system suggests
data from the purchase order and the goods receipts for the purchase order (for example,
vendor, material, terms of payment, etc.). Invoices can be posted in the ERP system in dif-
ferent ways. The company can receive invoices by post and then an employee enters data
and posts them in the system. The company can also receive invoices via electronic transfer
and the system posts them automatically.
Three-way matching and invoice variances: If there are discrepancies between the purchase
order or goods receipt and the invoice, the system warns the user, and can block the invoice
for payment. ERP systems generally do a three-way check before making payments to ven-
dors, i.e. the match between purchase order, goods receipt document and invoice. Price in
invoice should match with purchase order price for an item. The quantity in invoice should
match with goods receipt quantity and purchase order quantity. When all three matches,
the payment is processed. There can be three possible types of variances: Quantity vari-
ance (ERP compares the difference between the delivered quantity and the quantity already
invoiced), Price variance (ERP compares the purchase order price with the invoice price)
and Date variance (ERP compares the planned delivery date to invoice entry date).
Invoice Blocking: ERP systems can block an invoice for payment for various reasons like:
Block due to quality inspection (If vendor’s goods are rejected), Blocking due to amount
(If the invoice value is higher then the purchase order value and more then the value toler-
ance limit), Manual Blocking (ERP systems also allow manual blocking of invoice for
any other reason). Once the blocking reasons no longer apply, ERP systems automatically
release the invoice or it can be released manually.
Parking of invoice: An invoice can be put in temporary parking for various reasons like
missing information during processing an invoice or invoice data need to be checked by
another authority before posting etc.
Credit/Debit memos: Credit memos are received from a vendor if there is an overcharge and
these memos can be entered in ERP with reference to a purchase order or a goods receipt
and are posted as a subsequent debit/credit.
Reports on aging invoices: It can create reports of aging invoices, i.e. invoices which are
not paid for a particular duration, etc.
Posting of the invoice completes the invoice verification process. The system updates the purchase order
history and financial accounting initiates payment for the invoice items.

BEST PRACTICES IN VENDOR PAYMENT

Evaluated Receipt Settlement (ERS): This is an advanced method of vendor payment settle-
ment where goods receipts are settled directly without the vendor having to issue an invoice. ERP
System uses information from the purchase order and the goods receipt and creates a message
312 Enterprise Resource Planning

record at the time of settlement which is sent to the vendor to inform him about the settlement.
In this case, there is no invoice posting in the system, but system creates invoices using settlement
programmes that run at regular intervals.
Several automotive companies run ERS-based vendor settlement for their component manu-
facturers. Say, a company is producing 100 cars a day and there is only one supplier for its tyres,
everyday at the end of the day’s production, the vendor is automatically paid for 400 tyres for
which vendor did not submit any invoice.

Some Important Functionality of the ERP System to Support Procurement Process

A. Purchase requisition (PR): Purchase requisitions (PRs) are needed to request purchasing department to
procure particular quantity of a material or a service for a particular date. PRs can be created by material
requirement planning (MRP) runs or manually. When creating a PR, the requester can specify a source of
supply or a preferred vendor for the item. Sometimes PRs (for example, for high value items) need to be
authorised by particular person in the organisation. PRs can be converted to purchase order.
B. Contracts: Contracts are long-term agreements for buying a set of items at a defined price from a par-
ticular vendor. They do not contain quantity and delivery dates for each of the items. The company entering
into contract with a vendor use delivery schedule against the contract to inform vendor how much quantity
is required on which date. Though contract does not specify the details of quantities it may set the quantity
limit.
For example, an auto company can enter into a yearly contract with the tyre supplier as they need this
item regularly. The contract in this case will specify different types of tyre that the auto company will buy
from the supplier, price for each item, packing instruction, delivery instruction, legal and commercial terms
and a maximum quantity limit of 100000, i.e. the company will not buy more than 100000 tyres during the
year. This contract will now talk about on which date how much quantity to be supplied and for that there
can be separate release orders of 5000 in 1st month, 8000 in 2nd month and so on. Sometimes long-term
contracts also include price variation clause. For example, here if the rubber prices changes a lot during the
year, it is difficult for the tyre supplier to supply tyre at a fixed price and in that case the contract price may
be linked to the rubber price and one of the contract clause can be “For more than + / - 10% variation of
rubber base price (price of rubber at the time of entering into the contract with tyre vendor is considered as
base price) the contract prices has to be renegotiated”.
Central contract and plant specific contract: Contracts can be specific to one particular factory
or it can be centrally agreed. In case of a centrally agreed contract, all the plants of a company can
order against this. Typically, companies having a central purchasing organisation covering several
plants use centrally agreed contract as this help them to negotiate better commercial conditions with
the vendor. Generally for centrally agreed contract though the contract is agreed centrally, individual
delivery orders are given by particular factories specifying on which date which plan will need what
item and of what quantity.
Quantity contract: This type of contract is considered as complete when the agreed total quantity
as mentioned in the contract has been supplied based on individual release orders issued against the
contract. For example, a contract of 100000 quantities will be completed as soon as all release orders
against this will reach this quantity.
Value contract: This type of contract is considered as complete when the agreed total value as men-
tioned in the contract has been supplied based on individual release orders issued against the contract.
 Procurement and Inventory Management Through ERP 313

For example, a contract of 10 lakh value will be complete as soon as total vendor’s invoice value
against this reaches 10 lakh.
C. Quota arrangement: If there is more than one source for a material, the ERP system allows maintaining
these individual sources of supply through quota arrangement. The quota arrangement has a defined validity
period and specifies in percentage how the receipts should be distributed amongst each source of supply.
This includes external procurement or in-house production, as well as various special procurement types.
For example, if a car company has two vendors for tyre, it can tell that for the year 2009, they want to give
60% of their volume to vendor A and 40% to vendor B. In that case, PRs will get split in this proportion
and will get assigned to these two vendors.
D. Forecast delivery schedule and detailed delivery schedule (Firm schedule): One of the typical require-
ments for many vendors is that while they should know how much material they need to supply on the next
date, i.e. on the next day or next week, it is also important for them to have a forecast for relatively longer
period, i.e. how much material will be needed in the next few weeks/next few months. This helps them
in better material planning. For example, the vendor supplying tyres to a car company will like to know
from the car company that how many tyres he needs to supply tomorrow and a high-level estimate of how
much the car company will need in the next few weeks and months so that he can plan his procurement of
essential raw material like rubber and other items in the best possible manner. This necessitates two kinds
of schedule release:
Forecast delivery schedules: These schedules are used to give the vendor a medium-term overview
of the requirements. These schedules may over the time change to a limited extent, i.e. final schedule
can be + / - 10% of this forecast schedule.
Detailed or Firm schedule: Sometimes this is also called just-in-time (JIT) delivery schedule. This is
to inform the vendor just the next set of requirements, i.e. the next delivery schedule. Such schedules
may comprise a daily or even hourly breakdown of requirements over the next few days or weeks.
These are also called firm schedule as these will not change in future.
Scheduled delivery dates that lie in the near future (for example, in the next week) can represent a firm
commitment than those that are further away in time (for example, in the next month). In the car company
example, the tyre vendor may have a firm zone schedule of next one week for which the car company is
committed to buy and a trade off zone schedule for six weeks during which his plan may change and this
is only to help the tyre vendor to procure his raw materials.
E. Source list: Source list is a concept of ERP system that is used to define which sources of supply (vendor)
are allowed or not allowed for a material in a particular plant, i.e. it is a list of allowed, preferred, and/or
blocked vendor for a material for a particular plant, indicating the periods during which procurement from
such sources is possible. If in the source list only one source is defined for a material in a plant, ERP systems
automatically assign this source during the creation of PR and this process is known as automatic source
determination in purchasing. However, if there are multiple sources for an item as defined in the source list,
automatic source assignment does not work.
F. RFQ (Request for Quotation) and Quotation: The ERP system helps in creating the request for quotation
(RFQ) manually or with reference to a PR. If RFQ is created with reference to a PR, the information already
in the PR is copied directly to the RFQ and sent to the chosen vendors, who then submit their quotations.
These quotations (price, conditions, delivery dates, etc.) can be entered in the ERP system with reference
to the corresponding RFQ and the system determines the best vendor for each item individually by means
of a quotation comparison. Purchase orders can be creared with reference to a quotation. The system can
issue rejection letters to the vendors whose quotations are not selected.
314 Enterprise Resource Planning

G. Converting PR to Purchase Order: Once vendors are selected, buyers convert purchase requisitions
into purchase orders. Generally it is done manually. However, ERP systems also allow automatic conversion
of PRs into purchase orders.
H. Purchase Order: A purchase order is a formal request/document to a vendor to supply certain goods or
services under conditions stated in the order. ERP systems allow creating purchase orders with reference to
a PR, a request for quotation (RFQ), or another purchase order and this reduces data entry. ERP systems also
facilitate creating purchase order by suggesting default values. For example, it suggests the ordering address
as well as the terms of payment and freight (in co-terms) from the vendor master record. The system also
finds details of material from material master record. A purchase order can be input for lots of subsequent
activities like the goods receipt and invoice verification which are usually carried out on the basis of the
purchase order. ERP systems support order acknowledgements and sending the purchase order to the vendor
via Electronic Data Interchange (EDI) or e-mail.
Typically, order acknowledgements are sent by the vendor against this purchase order to inform customers
when ordered materials are expected to arrive and help in planning more accurately as the actual delivery
dates and quantities are known.
There can be several variations of purchase order like:
Blanket Purchase Order: These are used to procure consumable materials or services for which it
does not make sense to create separate purchase order and subsequent transactions for each procure-
ment. Blanket purchase orders are valid for a longer period of time (say, 1 year) and invoices can
directly be posted for the materials and services procured for this blanket purchase order.

Procurement Process Variants for Different Types of Procurement

Procurement of Materials and Services Procurement of materials and services is different from
different dimensions. Table 22.1 explains how procurement of materials is different from procurement of
services.

Table 22.1 Material Procurement vs. Service Procurement

Material Procurement Service Procurement

Materials can be inventorised Services can not be inventorised
Specifications are clearly defined during material Sometimes it is difficult to define a service specification during
procurement procurement
For a given specification price comparison is For a given specification service price comparison is difficult
simple – price may differ by time of purchase (early booking vs. late
booking in airlines), ambience (same food in a five star hotel and
in a normal hotel may be priced very differently).

Typical Challenges for Service Procurement In ERP

Service cannot be inventorised: If you buy an item and it is not used, the same can be kept in stock
and used in future. In contrast, if an airline can not sell a seat for a particular flight as soon as the
flight left the airport, the revenue opportunity is permanently lost. Services as intangible goods are
procured for immediate consumption.
 Procurement and Inventory Management Through ERP 5

It is difficult to define a service specification: When materials are procured, exact specification of
the material and quantity is known. In contrast, if the pump of a particular compressor is broken, it is
difficult to define a service specification to the technician as you do not know whether repairing this
will need replacement of some spares and how much amount is needed to do the repair. So defining
the service just by a service code and short description in purchase order is sometimes not enough
and a detailed service specification (statement of work) may exist for each service item.
Price comparison for service is complex: Price comparison is complex as you cannot see the final
output from different vendors at the time of giving the order while in case of products, it is easy to
ask for a sample.
Goods receipt is replaced by service entry and acceptance for service procurement: Service
procurement cycle follows the same five steps as product procurement. However, the fourth step is
different here as there is no goods receipt (GR) in case of a service procurement and this is replaced
by service entry and acceptance. Services performed are stored in a service entry sheet and this sheet
is signed off by the person who had created a requisition for the service.
Procurement of Direct and Indirect Items There is a basic difference in procurement needs of
indirect items (these are also called MRO—Maintenance, Repair and Overhaul items) and that of direct
items. MRO items are generally low-value indirect items, i.e. not part of finished goods and procured for
the needs of internal customers. Direct procurement items are part of finished goods and is driven by market
demand of finished goods. Table 22.2 explains the difference of procurement approaches between direct
and indirect items.

Table 22.2 Direct Items vs. Indirect Items

Direct Items Indirect Items

Demand driven by market demand of end items. Demand not driven by end item demand and mostly driven
by past consumption trend.
Involvement for procurement department is much higher Involvement for procurement department is much lower here
here as they need to collaborate with supplier to design as mostly off the shelf items are procured.
the component or product.
Generally contribute a significant portion by value of Generally contribute a small portion by value of total
total monthly procurement spend. monthly procurement spend as these are typically low-
value items.
Planning is done generally through planning runs of Planning is consumption-based. In some cases, purchase
MRP (material requirement) or advanced planning requisitions are created manually.
systems.
Procurement is always done by procurement team. Procurement can be done by procurement team and also by
end user/employee through e-Procurement or Portal.
Backend integration needed with ERP solutions is much Backend integration needed with ERP solutions is lower
higher here for reasons like delivery schedules release. here.

Indirect Procurement support by ERPs ERP solutions having its origin in MRP had most of its offer-
ings for procurement of direct items in the beginning, but increasingly now they started supporting indirect
procurement. Leading ERPs came up with specialised MRO modules and e-Procurement capability (discussed
in detail in Chapter 23) to support such indirect procurement.
316 Enterprise Resource Planning

Commodity Procurement Commodities are the items which are not branded and can see wide price
variations depending on demand and supply. These can be items like steel, iron ore, coal, oil and most of the
agricultural products like pulses, vegetables, tobacco etc. Some of the commodities like agricultural products
see lot of seasonal variations in price due to availability issues. Commodity procurement is a specialised
procurement process and ERPs provide special procurement tools for managing this. Some examples are:
e-Procurement/Auctions: Leading ERPs provide e-Procurement/auction options to commodity compa-
nies as the challenge here is to get the items at best price of required quality and the company need not
work with the vendor for a longer duration and in collaborative mode to develop the item (long-term
relationship with the vendor for developing an item is common for items like component, packaging
items, etc.). This is the reason that companies in industries like coal, oil and gas, steel, tobacco, etc.
opt for e-Procurement/auction. Some of the good examples in India are SAIL, Tata Steel, and ONGC
had opted for e-Procurement/auctions. This is discussed later in chapter.
Hedging: Hedging is a common strategy for managing commodity risk. In financial terms hedge is
defined as follows: “Hedge is a position established in one market in an attempt to offset exposure to
the price risk of an equal but opposite obligation or position in another market”. This is done by taking
a position in the future market that is opposite to the one in the physical market with the objective of
reducing or limiting risks associated with price changes. The news item below shows how Hedging
is becoming popular in India as well.

The Reserve Bank of India recently permitted commodity hedging, even for domestic transactions.
That is, domestic producers and users of certain select commodities can now hedge the price risk
on their domestic sales/purchases through international commodity exchanges such as the London
Metal Exchange. Previously, such hedging of the price risk on domestic sale/purchase was not
permitted, even if the domestic prices were linked to international commodity prices. The RBI's
latest move permitting hedging even for domestic transactions is significant in that it expands the
breadth and depth of the hedging mechanisms available to a company. In effect, a company will
now be able to hedge its economic exposures right through its operating cycle, covering not only
its regular imports and exports, but also its more important domestic sales and purchases. Active
operations on the hedging front may, in course of time, become fairly routine in Indian companies
with high commodities exposures.
Source: The Hindu Business Line, E-paper, Sunday, Jun 17, 2007

Most of the leading ERPs support e-Procurement and auctions these days while few of them support hedg-
ing as well.
Government/Public Sector Procurement Public sector procurement is again a specialised type of
procurement as it needs to follow separate set of guidelines of different government bodies (for example, any
procurement need at least three supporting quotations to release the order. Any tender news item need to be
published in popular daily newspapers, etc.). In most cases, the rates follow defined standards (for example,
there can be standard rate for laying every meter of pipeline plumbing or brick work). Several ERPs came
up with specialised modules to address this like SAP’s module on “Procurement for Public Sector”.

Procurement Maturity Model and Item-based Procurement Strategy

Figure 22.3 shows procurement maturity model for ERP deployment. Procurement maturity model explains
the maturity of procurement processes for ERP deployment. At basic level the companies do regular trans-
 Procurement and Inventory Management Through ERP 317

Fig. 22.3 Procurement Maturity Model

actions like purchase order creation, vendor payment, goods receipt, etc. to keep their business running. At
matured and innovation level the drive is for better planning, optimisation and collaboration. A company
can deploy ERP at any level and ERP can support processes at each of this level. As it is obvious that the
benefits are more when you are at matured or innovative level of processes and then deploy technologies
like ERP to support these processes.
Figure 22.4 shows how the procurement objective differs for different class of items. For example, for
MRO it is reducing procurement administration cost, while for critical items it is closer coordination with
the vendor. This shows that the kind of procurement tool you use within ERP may differ based on the kind
of product you procure. While collaboration tools may make lots of sense in case of a critical item, it does
not have much value for a routine MRO item.

Master Data for ERP Procurement

Master data in an ERP system are the data records that are stored in the database centrally for a long period
of time and are used by multiple modules of ERP system and thus, prevents multiple storage and redundancy
of data. For materials management module of ERP system, the most common master data elements are:
Material master record
Vendor master record
Terms and conditions master
Service master record and service catalog
Material Master Material master record is a company's main source of material-specific data. It is used
by all modules of ERP system like purchasing, inventory management, materials planning, invoice verifica-
tion, etc. for different purposes like:
318 Enterprise Resource Planning

Fig. 22.4 Procurement Strategy for Different Item Groups

Purchasing data for ordering

Inventory management data for posting goods movements and managing inventory
Accounting data for material valuation
MRP data for material requirements planning
Material master can have different views: Materials are needed by various departments within
a company and each department need different information for the materials. The material master
is sub-divided into information grouped by user departments and each department has a differ-
ent view of the material master record and is responsible for maintaining the data to support
its function. For example, accounts department maintain accounting view, sales maintains sales
view and procurement maintains procurement view of materials.
Different data is valid at different levels: Some material data is valid for the entire company
while some is only valid for certain levels, i.e. only for a particular plant. For example, a par-
ticular material’s size and description may be same for the entire company while its planning
parameters can change depending on the plant.
 Procurement and Inventory Management Through ERP 319

Vendor Master Data Vendor master is another important master from materials management perspec-
tive and data in the vendor master record can be sub-divided into different categories like:
General data: This includes data like vendor's address, contact number, bank details, etc.
Purchasing data: This includes data like purchase order currency, incoterms, vendor's tax data etc.
Accounting data: This comprises accounting data relevant for a vendor.
In ERP system each vendor is given a unique code and this code is referred while creating any purchase
order on the vendor, while receiving goods for them, during vendor rating and for any other transaction with
the vendor.
Terms and Conditions Master This is a standard repository of all terms and conditions for procure-
ment. The company can refer to this master while creating new purchase orders, contracts, etc. It is better
to pick and choose from this master instead of typing every time. A lot of these terms/conditions can be
legally binding.
Service Master Record/Service Catalogue Service master contains detailed information on the ser-
vice. Unlike manufacturing, prices for service can differ based on conditions. For example, a courier service
may charge different price based on delivery condition, i.e. one price for normal delivery and a different
price for express delivery. Service catalogue is a service master file that contains standardised descriptions
of services and given unique service number which can be referred to in purchasing documents.

Key Performance Indicators for Procurement

Some of the common procurement measures are shown in Table 22.3.

Table 22.3 Procurement Measures

Measure Definition
Cost savings Most common KPI for procurement department across organisation. This can be defined
as: “Aggregate amount of money procurement department saved by reducing costs from
one year to the next. This KPI measures the procurement department's contribution to the
financial success of the organisation”.
Supplier performance Performance of suppliers on price, delivery, quality, service, etc. KPI like percent on-time
supplier deliveries measures how well the procurement department gets what the organisa-
tion needs. KPI like supplier quality defect rate can be calculated by dividing number of
defective items by the total number of items purchased and this KPI measures the quality
of purchases made by the procurement department.
Procurement cycle time The average time it takes between requisition submission and purchase order placement is
one measure of procurement cycle time.
Procurement ROI This is a ratio of savings made by procurement department by operating costs. Procurement
operating costs may include cost components like pay, benefits, facilities costs, equipment
and software costs and more. This KPI measures the procurement department's cost ef-
ficiency.
Contract compliance The ratio indicates number of exceptions in contract quantity, price or any other legal
clause.
Purchasing analysis Order value analysis by net order value, ABC analysis, frequency analysis, and so on.
320 Enterprise Resource Planning

Offerings from Two Leading ERP Vendors in the Procurement Area

Procurement and materials management is one of the oldest and core ERP modules and all ERPs offer
a variety of functionalities to support this process. Two leading ERP vendors’ procurement offerings are
discussed here.
SAP Offerings Procurement is a part of SAP MM (materials management) module. SAP MM supports
following procurement scenarios and processes:

Procurement Planning Scenarios

Consumption-based planning
Reorder point planning
Forecast-based planning
MRP-based planning
Procurement Scenarios
Purchase requisition
Purchase of materials to production
Purchase to stock
Purchase by KANBAN
Purchase to sales order
Purchase to projects
Procurement for direct consumption
Internal procurement between plants
Procurement via sub-contracting

Oracle Offerings Oracle has four different products to support the procurement process and they are
as follows:
1. Internet Procurement (formerly self-service purchasing): A web-shopping solution for all employees
that automates finding and requisitioning goods and services using self-guiding online catalogues
coupled with efficient content management. Industry standard XML interfaces allow integration to
customers' existing Oracle, non-Oracle or legacy financial systems.
2. Purchasing Intelligence: A web-enabled analysis tool which provides access to enterprise-wide
procurement information along with the ability to perform ongoing analysis of sourcing decisions,
contract compliance, and supplier performance.
3. Internet Supplier Portal: A self-service solution giving trading partners internet access to purchasing,
receiving and payment information as well as providing suppliers the capability to easily process their
own transactions.
4. Purchasing: This streamlines order planning and management for purchasing professionals.
Apart from these four basic products, Oracle is also used as an advance version of purchasing
solutions:
Oracle Sourcing is the enterprise application that drives more and better sourcing through online
collaboration and negotiation.
 Procurement and Inventory Management Through ERP 21

Oracle Procurement Contracts is used for creating and enforcing better purchasing contracts.
Oracle Daily Business Intelligence for procurement is used for the spend-analysis application that
allows buyers to spot savings opportunities immediately.
Quality
Source: http://www.oracleappshub.com/oracle-purchasing/oracle-purchasing-product-overview

INVENTORY MANAGEMENT
Inventory Management Process

Concept of Inventory Management Pyramid Inventory management processes can be divided

into three levels of processes as shown in Figure 22.5 through an inventory management pyramid. ERP and
supply chain systems can support all these three levels.
Inventory transactions and inventory control: Base of the pyramid talks about inventory transac-
tions and basic inventory control tools. These are absolutely fundamental to run the business and
from regulatory point of view (yearly stock taking and publishing inventory valuation under asset in
the balance sheet is mandated by law). Inventory transactions focus on activities like recording all
inventory transactions like goods issue, receipt, stock transfer, etc. These are the most basic processes
to achieve timely and accurate information on inventory status. Inventory control are processes like
physical inventory, cycle counting, inventory valuation, etc. This ensures that the company has basic
level of control on its inventory, i.e. it knows where how much stock is lying, the value of the stocks
and where the stock is reaching near minimum level, cases of stock-outs, etc. Inventory control is also
enabled through a set of reports and alerts for proactive action for inventory planner.

Fig. 22.5 ERP Support at All Levels of Inventory Management Pyramid

322 Enterprise Resource Planning

Inventory planning: At this level, the company takes scientific approach for deciding where to hold
inventory, how much to hold, when to order, etc. The company can have several approaches like
adopting collaborative approaches for planning inventory and scientific process for inventory replen-
ishment.
Strategic inventory management processes: These are innovative processes that differentiate a
company from others.
Inventory Management Processes in ERP As described above, inventory management processes can
be grouped under inventory transaction processes, inventory control processes and inventory planning pro-
cesses. These three sets of processes are discussed here with how ERP helps in managing these processes.
A. Inventory Transaction Processes
There can be different types of inventory transactions supported by the ERP system and these are:
1. Goods receipt
2. Goods issue
3. Reservations
4. Stock transfer
1. Goods receipt: Goods receipt is one of the fundamental inventory transactions. Goods are received
from the supplier, quality check is done, and goods are returned which are not within quality limit.
Sometimes advanced shipping notification (ASN) are received before actual goods receipt. ERP
systems support several sub-processes under this like:
Receiving goods against a purchase order
Receiving goods against a delivery schedule
Damage identification on receipt
Unloading and unpacking
Capture lots of information on receipt
Reconcile purchase order/delivery schedule line item with receipt
Vendor returns in case the goods are not within quality limits
Receiving advanced shipping notification (ASN) receipt from supplier before receiving the actual
consignment
Posting goods receipt (with total quantity, accepted quantity, date, etc. This becomes the basis
for rating the supplier)
These days with bar codes and radio frequency (RF) scanner at receiving doc, goods receipt process
has become simpler.
2. Goods issue: There can be different types of goods issues like raw materials issue in the factory for
production, issue of materials to quality department for quality inspection, finished goods issue from
warehouse for dispatch, etc. These issues can be recorded in ERP inventory management system so
that the inventories are updated. There can be different types of activities related to goods issue and
they are as follows:
Delivery creation
Packing
Goods issue
Loading
Posting goods issue to inventory management
Creating ASN for customer before making the dispatch
Receiving proof of delivery (POD) from customer
 Procurement and Inventory Management Through ERP 323

3. Reservations: Reservations are requests to the warehouse to have materials ready for issue at a later
date and for a particular purpose and it ensures that a material is available when it is needed. Reserva-
tions are typically done for a customer.
4. Stock transfer: ERP systems allows different types of stock transfers like stock transfer from one
company code to another, from one plant to another and from one storage location to another. A stock
transfer consists of a goods issue from the issuing point and a goods receipt at the receiving point.
B. Inventory Control Processes
1. Quantity control:
It is important for every organisation to know how much inventory is lying at what location. Inventory
transactions described earlier always updates stock position in the system and this stock need to be in tally
with physical stock actually available. Quantity control processes like physical inventory or cycle counting
or stock overview reports help in this.
Physical inventory: Difference of stock figures between what is in the system and what is physi-
cally available is always a challenge. ERP systems help in managing physical inventory process and
controlling the difference between system inventory and actual physical stock. Stocks are counted
and the count results are entered in ERP system. Using the list of inventory differences, variances in
the stocks can be checked and if required, recount can be initiated. If the difference is accepted, it is
posted and the stock is corrected.
Cycle counting: This is a method of physical inventory counting where every material is counted at
regular intervals during the year and intervals/cycles are determined based on the type of material.
Thus, cycle counting allows fast-moving items to be counted more frequently than slow-moving items
and materials can be classified based on cycle counting frequency (for example, A, B, C, D). For each
category, cycle counting frequency can be defined in an ERP system, based on which ERP system
calculates the due date for next cycle counting for each material. Class A items are all high-revenue
products, which typically accounts for about 80% of annual sales and represent about 20% of inven-
tory SKUs. Class B items include products that typically account for about 15% of annual sales and
represent about 30% of inventory SKUs. Class C items include products that typically account for
about 5% of annual sales and represent about 50% of inventory SKUs. To identify A, B and C class,
a Pareto analysis is done depending on annual dollar volume. As Class A items account for the major
part of the business, a high-frequency periodic review policy (e.g. a weekly review) is appropriate in
this case. Similarly, a periodic review policy is applied to control B class products although the fre-
quency of review is not as high as that for class A products. Finally, depending on product value, the
firm either keeps no inventory of expensive class C products or keeps high-inventory of inexpensive
Class C products. Figure 22.6 explains cycle counting and ABC classification process.
Stock overview: ERP systems at any point can display current stock situation at particular factory
level or at total company level. Stock can also be viewed at different batch levels.
2. Value control/Stock valuation
Along with quantity, it is also important to know the value of the stock that the company is currently holding.
Goods receipts are valuated depending on the valuation procedures defined in the ERP system and leading
ERPs support several valuation procedures like moving average price procedure, standard price procedure,
etc. In the standard price procedure, the system carries out all stock postings at a standard price as defined
in the material master and variances are posted to price difference accounts. In the moving average price
procedure, the system valuates goods receipts with the purchase order price and goods issues with the cur-
rent moving average price.
324 Enterprise Resource Planning

Fig. 22.6 Example of ABC Classification of Materials

Every transaction in the ERP system creates a material document as a proof of a transaction involving
stock changes and if the goods movement is relevant to valuation, the system creates one accounting docu-
ment in addition to the material document as every material transaction like goods receipt or goods issue
can increase or decrease stock value.
C. Inventory Planning Processes
Inventory transactions and inventory control defined earlier are basic requirements for a business and a busi-
ness can not run without these. Inventory planning is a more matured component of inventory management.
Though every company does some amount of inventory planning it can differ from most basic to advanced
level depending on maturity of the organisation.
There are two basic drivers for better inventory planning:
Never have a stock out as for a finished goods stock out, there will be customer dissatisfaction and
lost sales. For a raw material and component stock out, there will be production loss.
Never carry excess inventory as this increases cost of operation; moreover there is chance of obsolence
and heavy markdown.
So, inventory planning tries to achieve inventory of right items, at right location, at right time and of
right quantity. ERP and supply chain management solutions support better inventory planning in variety of
ways like:
Designing better process of inventory replenishment: ERP systems support better replenishment
planning from factory to warehouse and from warehouse to store. ERP tools like distribution require-
 Procurement and Inventory Management Through ERP 5

ment planning (DRP) helps in this with a variety of replenishment approaches like push, pull or a mix
of both.
Supporting process of managing different inventory exceptions: ERP systems supports different
inventory exceptions by providing different alerts and workflows which automatically get triggered if
stock at a location is higher/lower than recommended and if there is a stock out.
Taking scientific decision on when to order and how much to order: To decide how much to order
and when, ERP support a set of inventory models like: EOQ (economic order quantity) or Q models,
P Models (periodic review models), Min – Max models, Two bin models, etc. These are discussed
below.
Different Inventory Models supported by ERPs
There are different inventory models as follows:
Q model: As shown in Figure 22.7, EOQ model balances between carrying cost and ordering cost. If
orders are placed too frequently, ordering cost increases, but it reduces the inventory carrying cost. On
the other hand, if orders are placed after long intervals, this increases the carrying cost and reduces
ordering cost. These costs are opposing costs, i.e. as one increases, the other decreases. The sum of
the two costs is the total stocking cost (TSC). When plotted against order quantity, the TSC decreases
to a minimum cost and then increases. This order quantity where TSC is minimum is known as the
economic order quantity (EOQ). The amount ordered each time, an order is placed is fixed or constant.
As per the EOQ model, the ordering should be done at reorder point, i.e. when the quantity on hand
of an item drops to this amount, the item is reordered.

Fig. 22.7 EOQ Inventory Model

P model: The philosophy of P model is opposite of that of EOQ model. As shown in Figure 22.8,
here the inventory is reviewed at regular intervals, i.e. review frequency is set (T). Quantity to place
on order is the difference between maximum quantity (M) and amount on hand at the time of review
(OH). So, here the inventory review frequency is fixed and quantity varies with each order. Manage-
ment needs to set optimal values of T and M to balance stock availability and cost. Targeted inventory
of P model is: TI = d (RP + L) + SS, (d = average period demand, RP = review period (days, wks),
L = lead time (days, wks), SS = Safety stock). Replenishment Quantity (Q) = TI-OH
326 Enterprise Resource Planning

Fig. 22.8 Periodic Review System (P Model)

Min–Max Models: In this model either a pre determined minimum and maximum inventory level is
defined for each item. As soon as the stock reaches close to minimum point, the ordering is done.
Two-Bin Models: One of the simplest inventory models to administer—there are two containers of
inventory—reorder when the first is empty.
D. Strategic Inventory Management Processes
Processes at this level of inventory management provide a company competitive advantage over others and
differentiate themselves. Most of the leading ERP and supply chain management solutions today support
processes at this level and processes can be:
Process of inventory collaboration: As discussed earlier in this chapter, ERP systems support dif-
ferent forms of inventory collaboration like Vendor-managed inventory (VMI). Here, instead of the
company managing the stock of items, the supplier takes the responsibility of managing the stock
based on stock and sales information from the supplier. VMI between Wal-Mart and P&G is a much
talked about case. As stock is replenished more frequently and managed by supplier who has better
information about the sales trend of the product, the inventory in the chain comes down. Vendor man-
aged inventory is supported by SAP and Oracle where collaboration is facilitated through EDI.
Deciding inventory based on service levels: Service level is an important concept where inventory
levels are decided based on service levels, i.e. items that are critical and need higher service levels
 Procurement and Inventory Management Through ERP 327

will require high inventory and items having lower service level need lesser inventory. Most of the
leading ERP vendors support service levels concept.
Best practice processes of inventory management like Cross docking: Cross docking reduces the
inventory at distribution centre warehouses by effective coordination of inbound (shipments from
suppliers to distribution centre) and outbound (shipments from distribution centre to user) shipments.
Items are not taken inside the warehouse at all and sent directly to user. This reduces inventory in
the total supply chain and also reduces the lead time of supply from supplier to user. Wal-Mart, the
leading retailer uses cross docking effectively. Cross docking is a part of warehouse management
module for most of the leading ERPs like SAP and Oracle and best of breed warehouse management
vendor like Manhattan.
Lean inventory management: Lean philosophies talk about reducing waste from the supply chain in
all possible forms. Inventory is one of the largest contributor of this waste. Lean principles suggest a
variety of approach to reduce raw material—work in progress and finished goods inventory and lead-
ing ERPs like SAP and Oracle support lean principles of inventory management through Kanban.

Offerings from Two Leading ERP Vendors in Materials and Inventory

Management Area
All leading ERPs support inventory management processes. Offerings from two leading ERP solution vendors
SAP and Oracle are discussed here.
SAP Offerings—SAP Materials Management Materials and inventory management is a part of
SAP MM (materials management) module. SAP MM supports following materials management processes/
scenarios:

Goods receipt
Goods issue
Goods return
Goods movement to quality management
Stock transfers
Consignment stock management
Physical inventory and cycle counting
Inventory valuation

Oracle Offerings—Oracle Inventory Management Inventory Procurement is a part of Oracle

inventory management module. Some features of Oracle inventory management module are as follows:
Inbound outbound and reverse logistics transactional support
Finished goods, raw materials and work-in-process components tracking
Support for manufacturing, distribution and after-market service and spares environments
Active alerts and intelligent messages for proactive management
Global inventory visibility and product genealogy integrity for both lots and serial numbers
Streamline inventory management processes such as replenishment, order fulfillment, manufacturing
and inventory counting
Compliance support for electronic records and electronic signatures in support of 21 CFR Part 11
regulations
Consigned, vendor managed and project-based inventory tracking
328 Enterprise Resource Planning

ERP VS BEST OF BREED

Though most of the procurement and inventory management requirements of organisations are
met by leading ERPs like SAP and Oracle, there can be specific requirements which ERPs do not
meet today. One of such requirements is “Multi-echolen inventory planning”. An airlines
company needs to maintain spares at different airports and at a central location for maintenance
of its aircrafts. Multi-echelon inventory planning solutions help in deciding whether a particular
spare need to be kept at a central location or at a particular location depending on inventory car-
rying cost and service level requirement of each spare. Similarly, a consumer goods company can
use multi-echelon inventory planning to decide whether to keep more inventory at the factory
and less at the warehouse or more in the warehouse and less in the factory to meet customer
requirements better and to reduce inventory carrying cost.
IBM Global services have a solution called dynamic inventory optimisation (DIOS) which
can meet these kinds of requirements. There are other vendors also who specialise in Inventory
Management and can offer better functionalities in this area then what ERPs can provide.

Key Performance Indicators For Inventory Management

Inventory is something very closely measured in most organisations and there can be several inventory
measures as shown in Table 22.4.

Table 22.4 Inventory Measures

Measure Definition
Stock-outs Number of incidents when a particular item is required and the item is missing in a
particular time period
Inventory turn Annual sales/average inventory level
Inventory carrying costs Sum of all costs associated with finished goods inventory (like, opportunity cost,
shrinkage, insurance and taxes, total obsolescence, channel obsolescence, etc.) as a
percentage of sales turnover
SKU turnover The number of times an SKU cycles or turns over in a year; divide the average inven-
tory level into the annual cost of sales
Inventory aging The percentage of total gross inventory (based on value) covered by expected demand
within specific time buckets
Inventory cycle counting The absolute value of the sum of the variance between physical inventory and perpetual
accuracy inventory or the number of accurate part cycle counts divided by the total number of
cycle counts performed expressed as a percentage
Inventory obsolescence as a The annual obsolete and scrap reserves taken for inventory obsolescence expressed
percentage of total inventory as a percentage of annual average gross inventory value
Shrinkage The costs associated with breakage, pilferage and deterioration of inventories
Storage space utilisation Volume of all materials stored divided by the total volume of the storage facility
expressed as a percentage
 Procurement and Inventory Management Through ERP 329

Summary
A typical procurement process starts with procurement planning, followed by identifying right source of the
item, purchase order creation, goods receipt and finally vendor payment.
ERP applications support all these five stages of the process though a set of ERP functionalities as discussed
in the chapter.
Purchase requisition, contract, request for quotation, purchase order, blanket purchase order, quota arrange-
ments, etc. are useful ERP functionalities.
Requirements for different procurement scenarios like material and service procurement, direct and indirect
items procurement, commodity procurement, government procurement, etc. are different and need different
functionalities from ERP systems.
Procurement maturity model explains the maturity of procurement processes for ERP deployment. At the
basic level, the companies do regular transactions to keep their business running. At matured and innovation
level, the drive is for better planning, optimisation and collaboration. A company can deploy ERP at any
level and ERP can support processes at each of these levels.
Major master data for ERP procurement module are: Material master, vendor master, service master, terms
and conditions master, etc.
Inventory management pyramid defined the maturity of inventory processes. Inventory transactions and control
are basic ERP processes, followed by Inventory planning process and finally there are strategic inventory
management processes.
Goods issue, goods receipt, stock transfers and reservations are example of inventory transaction processes.
Physical inventory, cycle counting and inventory valuation are examples of inventory control processes.
There are different inventory models for inventory planning and these are: EOQ model, P model, Min-Max
model, Two-bin model, etc.
Offerings from two leading ERPs SAP and Oracle are discussed here in procurement and inventory manage-
ment areas.
Some of the KPIs for procurement and inventory management process are also discussed in this chapter.

Exercise
I. Objective Type Questions
1. What is procurement planning?
2. What is RFP and RFQ?
3. How ERPs help in source selection?
4. How ERPs support purchase order creation process?
5. What kind of checks can be activated in an ERP during goods receipt?
6. What are the different reasons for which a vendor’s invoice can be blocked?
7. What is three-way matching?
8. What is ERS?
9. What is PR?
10. What are the difference between quantity contract and value contract?
11. What is a quota arrangement?
12. What is the difference between forecast delivery schedule and firm delivery schedule?
13. What is a source list?
330 Enterprise Resource Planning

14. What is a blanket purchase order?

15. Why is it difficult to compare prices for service?
16. What is hedging?
17. What are the typical challenges of procurement in government sector?
18. What are the four different master data elements for procurement module of ERP?
19. What is a vendor master?
20. What is procurement cycle time?
21. How is supplier performance measured?
22. What is the difference between inventory planning and control?
23. What are the four inventory transaction processes?
24. What are the different inventory control processes?
25. What are inventory models?
26. What is the difference between P and Q model of inventory planning?
27. What is cycle counting?
28. What is ABC analysis?
29. What is Two-Bin model?
30. What is Min-Max model?

II. Descriptive Type Questions

1. Explain a typical procurement cycle for a company. What are the different activities?
2. How does ERP software help in different phases of procurement cycle?
3. How do ERPs help in purchase order and goods receipt process?
4. How do ERPs support vendor payment and invoice verification process? Explain ERS.
5. What is a contract? Explain quantity and value contract. What are plant-specific contract and plant inde-
pendent contract?
6. Explain quota arrangement. What are the different types of delivery schedule and why is it needed?
7. Explain source list and purchase order.
8. What are the differences between material and service procurement? What are the challenges of service
procurement?
9. What are the differences of procurement between direct and indirect items?
10. What are the different types of commodity procurement strategies? Explain auction and hedging.
11. Explain procurement maturity model.
12. How can procurement strategy differ based on the type of the item?
13. Explain different master data for ERP procurement module. What are material master and vendor mas-
ter?
14. Explain different KPIs for the procurement process.
15. What are the three levels in inventory management pyramid? Explain each of them.
16. Explain the four inventory transaction processes.
17. Explain the inventory control processes.
18. Explain inventory planning processes and different inventory models.
19. What are the strategic inventory management processes?
20. Explain different KPIs for inventory process.

III. Fill in the Blanks

1. RFQ stands for _______________ _____________ _______________.
2. ERS stands for _______________ _____________ _______________.
3. MRO stands for _______________ _____________ _______________.
 Procurement and Inventory Management Through ERP 31

4. POD stands for _______________ _____________ _______________.

5. EOQ stands for _______________ _____________ _______________.
6. EDI stands for _______________ _____________ _______________.
7. Three types of possible variances for the invoice are __________, ___________, and __________.
8. Vendor payment generally follows a ________ _______ matching process.
9. Two ways of creating purchase requisition are ___________ and ____________.
10. Two types of vendor delivery schedules are _____________ and ____________.
11. MRO items have low _______ impact and low _________ impact.
12. Sourcing optimisation is a level _________ procurement process.

IV. State Whether the following Statements are True or False

1. Blanket purchase order is valid for a short period.
2. Automatic source determination is automatic assign of PR to source list.
3. Services can be inventorised.
4. Planning of direct items is generally through MRP.
5. Demand for indirect items is generally driven by end item demand.
6. Direct item’s procurement can be done by employees.
7. e-Procurement is a basic process.
8. Goods issue is an inventory planning process.
9. In P model of inventory planning, review frequency is a variable.
10. In Q model, a fixed quantity is ordered every time.

V. Assignments
Study in details the procurement and inventory management modules of two leading ERP solutions, i.e. SAP and
Oracle. Note down all their modules and sub-modules. What capabilities they offer? Draw similarity and differ-
ences of their capabilities.
 23
Supplier Relationship
Management Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Understanding Supplier Relationship Management
Electronic Procurement
Shopping Cart
Procurement Card
Bidding/Auction/Reverse Auction
Catalogue and Content Management
Supplier Collaboration
Offerings from leading SRM vendors – SAP and Ariba

UNDERSTANDING SUPPLIER RELATIONSHIP MANAGEMENT

Supplier relationship management is not one single software, but an umbrella term that refers to a set of
technologies that make procurement process more efficient. Different leading analyst group defines SRM
as follows:
Gartner defines SRM as: “The practices needed to establish the business rules and understanding needed
for interacting with suppliers of products and services of varied criticality to the profitability of the enter-
prise” (Source: Gartner Supplier Relationship Management: Why Does It Matter? 05/2001)
Meta defines SRM as “SRM is a system of applications that automates specific planning, scheduling,
shipment, and payment processes between a manufacturer and its critical direct materials suppliers. SRM
systems track both data and process-interchange flows as well as provide the management and analytical tools
to intelligently track the performance of direct suppliers based on benchmark, historical, and/or contractual
conditions.” (Source: META Group Supplier Relationship Management: Part 1 10/2000)
AMR Research defines SRM as “SRM in its purest form to include extended procurement processes,
such as sourcing analytics (e.g., spend analysis), sourcing execution, procurement execution, payment and
settlement, and closing the feedback loop of supplier score carding and performance monitoring”. (Source:
AMR Research)
 Supplier Relationship Management 333

Evolution of SRM Applications

As shown in Figure 23.1 most of the supplier relationship management applications had its origin from
electronic procurement for low value MRO (maintenance, repair and overhaul) items and office stationary
items for employees. The major driver here was reducing cost of procurement administration, speed and
convenience and taking advantage of consolidating procurement. These e-Procurement applications also had
catalogue management as one of their offerings as employees or procurement department need to select
items from predefined catalogues of vendors.

Fig. 23.1 Supplier Relationship Management—Application Evolution

In the second generation of SRM applications, these applications developed capabilities for procuring
direct items procurement and developed specialised capabilities in the form of tendering, forward and reverse
auctions, etc. as needed for procuring regular production items.
SRM applications gradually ventured into lot of new areas over time like contract management, supplier
analytics, supplier collaboration, self-service, sourcing optimisation, etc.

SRM Applications Come from Different Origin

Figure 23.2 shows how SRM vendors came from different origin. Leading ERP vendors, Supply chain
management (SCM) and Advanced planning and scheduling (APS) vendors, Sourcing vendors and Product
334 Enterprise Resource Planning

Fig. 23.2 SRM Vendors Come from Different Origin

lifecycle management (PLM) vendors all are trying to enter into this space. However, as market is getting
more matured – two leading ERP vendors, i.e. SAP and Oracle and a leading sourcing vendor Ariba are
becoming prominent players in the market.

SRM Applications Solve Different Sourcing Problems for Different Types of

Buyers
Figure 23.3 shows how SRM applications solve different types of sourcing problems for different types
of users using various types of technologies like shopping cart, procurement card, auctions platform, col-
laboration platform, catalogue and content management, workflow, etc. While employees can buy directly
office supplies through e-Procurement, engineering buyers source MRO items through e-Procurement and
strategic sourcing team can source direct production items by SRM auction applications.
In this chapter five important application areas of Supplier relationship management are discussed. They
are as follows:
Electronic procurement
Catalogue management
Content management
Contract management
Supplier collaboration
 Supplier Relationship Management 5

Fig. 23.3 SRM Vendors Serve Different Purpose for Different Types of Buyers

ELECTRONIC PROCUREMENT

e-Commerce seems to have really clicked for the domestic steel industry. The two Indian steel
majors, SAIL (Steel Authority of India) and Tisco have utilised the technology to the maximum
and have generated huge revenues through the e-Commerce platform on Metaljunction.com,
promoted jointly by them two years ago. The e-Commerce platform has helped ensure major
savings for these companies which, in turn, has boosted their bottomlines. SAIL generated busi-
ness of over Rs. 350 crore in the first six months. While sales notched up by SAIL during the
period stood at Rs. 290 crore, procurement through e-Commerce crossed Rs. 60 crore. Tisco,
on the other hand, generated additional revenues to the tune of Rs. 424.61 crore during the first
eight months ended November, 2003. The company sold 206,258 tonnes of steel. During the
same period, Tisco’s procurement was even higher at Rs. 708 crore and so were the savings at
336 Enterprise Resource Planning

Rs. 107 crore or 15 per cent of the transaction value. A SAIL official, looking after e-Commerce
activities told the Financial Express, “SAIL expects to generate additional annual revenues of over
Rs 1,000 crore by next year with savings that could go up as high as 10-12 per cent or over
Rs. 100 crore.” The savings come through doing away with paper work and other logistical
problems involved with physical dealing. Apart from procuring raw material and selling products
through e-Commerce, SAIL even managed to sell some of its idle assets over the past six months.
The number of e-sourcing transactions in case of SAIL increased from 15 to 41 and the activity
has been spread across its various plants. The company is expected to transact almost 10 per
cent of its Rs. 1500 crore worth of stores and spares procurement through this route, the official
added. Metaljunction Pvt Ltd, a 50:50 joint venture between SAIL and Tisco, not only provides a
platform to conduct online business, but also carries out a number of activities right from finding
international vendors to communicating with them and training them on the online bidding pro-
cess. Some of the extremely successful e-sourcing transactions during the past six months were
for hydrochloric acid and water treatment chemicals.
Source: The Financial Express, New Delhi, 18th Dec, 2003
Oil and Natural Gas Corporation Ltd. (ONGC), the largest oil and gas public sector undertaking
(PSU) in India achieved another first position by becoming the only PSU to introduce SAP powered
"Reverse Auction" process. Termed as "Live Action Cockpit" (LAC), the system will enable ONGC
to collect and compare price and bid information of various suppliers in a real-time, open bidding
environment. The reverse auction will ensure transparency in the tendering process and thereby
generate confidence amongst the bidders. It will also add speed to the process of procurement
which will allow ONGC to source best in class technology. On the basis of the pilot project it is
estimated that reverse auction will be able to accrue a cost saving of nearly 10 per cent. SAP is
the trusted partner of ONGC in the area of business software, ONGC had successfully using SAP
ERP for last few years. LAC will be the sole procurement window for all 'high value' tenders,
valuing more than Rs. 1 crore. This process will provide a level playing field to bidders having
necessary techno-commercial capabilities. Adhering to the guidelines the reverse auction process
will ensure standardisation of the procurement process of ONGC. The LAC will bring in higher
efficiency, cost savings and transparency to ONGC's procurement processes as it continues on its
path of being a global oil and gas leader. The reverse auction process enables supplier selection
process by facilitating vendors worldwide to participate in the bidding process seamlessly. This is
among the largest such projects undertaken by SAP in the public sector.
Source: CXOtoday, Mumbai, Mar 18, 2008
Coal India bets big on electronic procurement to boost efficiency: Public sector Coal India
Limited (CIL) plans to procure about one-third of its equipment, consumables, spare parts and
other stores electronically to cut delays and boost efficiencies. Coal India aims to purchase Rs. 3,400
crore worth of equipment and consumables in FY09 through this platform, helping to integrate
buyers and suppliers. This is the first time that the public sector behemoth is offering 4-models
of e-Procurement and even its 8 subsidiaries might opt for this electronic platform, which till now
was restricted to the holding company alone. CIL has also engaged certification agency CERT-
In so that the bidders are satisfied on security requirements while entering the e-Procurement
system. The whole exercise has been carried out for developing a secure and encrypted platform
both for the bidders and also for Coal India. CIL has already signed an integrity pact with Trans-
 Supplier Relationship Management 337

parency International and is, therefore, committed to provide proper and secured services to its
customers. The certifying agency will look into the security aspects of the system as well as audit
of the entire process. The 4 models offered under e-Procurement are – e-Tendering, e-Tender-
ing with multiple bids, reverse e-Auction with price bid and reverse e-Auction with quantity and
price bidding. Under e-Tendering, the physical system will be converted into an electronic tender
whereby buyers will be able to decide the eligibility of the vendor. Eligible vendors can quote from
any place on the internet and the buyer will have the option of obtaining the techno-commercial
bid manually or over the internet. In such a format, price bids can only be seen at the appointed
hour. e-Tendering with multiple bids is almost similar to e-Tendering. Here, the vendors will have
the option of revising their price bids any number of times before the closing time of the bids.
Reverse e-Auction with price bid is a system adopted for the first time by CIL and its service
provider. This is basically a reverse of forward e-Auction. Here buyers can decide the eligibility
criteria of the vendors.
Source: Business Standard, May 27, 2008

Electronic procurement which started as a procurement option for low-cost office supplies and MRO items,
gradually becoming popular and as the articles above indicates that this procurement method is even be-
coming popular for procuring direct production items for its transparency, speed and cost effectiveness.
There are several ways to make the procurement process simpler for the employees like using electronic
catalogues, choosing from a list of previously ordered items, or even entering a general description of an
item. Post procurement, employees can complete the cycle by confirming receipt of products in the system
and entering the vendor’s invoice. e-Procurement software also gives option to vendors to access the system
and confirm delivery and posting invoices.

e-Procurement Options
There are different ways an electronic procurement can happen. This can differ based on the types of items
procured through e-Procurement (direct production items, indirect items, MRO items, etc.). Most common
technology options available for e-Procurement are:
Electronic shopping cart
Procurement card
Auction
Electronic Shopping Carts Shopping cart is a common e-Procurement technology used by employ-
ees for procurement of goods and services. Employees can create shopping cart by searching products in
electronic catalogues, start the shopping process, check the procurement status at any time, confirm goods
and services once that is delivered and can then enter invoice for their purchase order. If user cannot find a
suitable product, they can enter a description of the requirement and based on that e-Procurement systems
can give a list of options from product catalogue having similar name. e-Procurement systems has internal
workflow that checks whether the item request needs to be approved and if it needs an approval, the people
who need to approve the request receive a work item in their inbox.
A typical electronic procurement flow through shopping cart is explained in Figure 23.4 and can have
following steps:
Creating Shopping Cart The first step in creating shopping cart is to find out a suitable product which
meets the requirement of employees. Shopping carts provide several features to facilitate this search like:
catalogue, favourites, and special request. These options are as follows:
338 Enterprise Resource Planning

Fig. 23.4 Shopping Cart Procurement Process

Catalogue: Employee need to select the catalogue he wants to use and search for products in this here
and transfer them to the shopping cart.
Favourites: Favourites can be a list of items that is ordered by the employee frequently so that reor-
dering made easier, or Favourites can be a template of list of items that have been ordered previously
and a shopping cart can be created referring to this.
Manual requests: If the product is not a catalogue item or not covered in favourites, this can be
searched by writing a description of the item.
Shopping cart can be created using any of the three options mentioned earlier and contents of the cart
can be seen once created and gets continuously updated as long as products are added in the cart.
Shopping Cart Approval Once the shopping cart is created, e-Procurement solutions checks whether the
same needs to be approved and if one or more people in the organisation need to approve the shopping cart,
the solution triggers workflow and sends e-mail to all those people concerned. Most of the e-Procurement
solutions available in the market also support strong workflow capability that facilitates approvals of orders
placed by an employee. While in certain cases, approvers for each user is decided centrally, in other cases the
user can define approver in the system and all work items are routed to the approvers. The approver can see
details of the item requiring approval (for instance purchase request for a new item) and decide whether to
accept or reject the item and based on his decision the requestor gets an e-mail in company’s e-mail system.
There can be one or several approvers depending on the value of the item. There can be different statuses
of shopping cart like: To be processed, In approval, Approved or Rejected. If the shopping cart is approved,
it will trigger next steps, i.e. the system creates the purchase order requisition, or reservation documents. If
the normal approver/manager is on vacation, employees can add additional approvers to normal approvers.
Employees can check their shopping cart and see the status, i.e. whether this is approved or not.
Purchase Order and Goods Receipt The approved shopping cart can create a purchase requisition and
purchase order either in e-Procurement system or connected backend ERP system depending on the system
set-up. Purchase order can be sent to vendors electronically (i.e. EDI or mail) or physically (i.e. fax, post).
As soon as the goods are delivered, the system starts a workflow and a mail triggers in the employee’s
 Supplier Relationship Management 339

inbox informing that the goods had come and requesting him to inspect the same and approve. For goods,
the employee who had created the shopping cart can confirm that whether goods have been delivered. For
service procurement, the employee confirms whether the service is performed.
Invoice Payment e-Procurement solutions offer different options of entering invoices. Vendors can enter
the invoice in the system which, in turn, triggers a workflow and the invoice come to employee’s inbox
for their approval. Once the employee approves the invoice, the document is transferred to the financial
accounting systems for further processing.
Alternatively vendor can send the invoice to the employee who had requested the items and employee
enters the invoice or the company’s accountant enters invoice for many employees. In this case after the
invoice is entered, an workflow triggers to the employee who ordered the items for approval. Once approved,
the data is transferred to the backend system to update the accounting. In case of a return, credit memos are
posted by the vendor or employee or in case of an invoice rejection, the vendor is informed by e-mail.
Other Important Functions of Shopping Cart The following functions are available for processing
items in a shopping cart:
Tax Calculation: Tax calculation occurs for shopping cart item.
Purchase order text or internal note: e-Procurement systems provide facility to add text to be forwarded
to the vendor or internal notes can be created to be sent to the approver or purchaser.
Attachments: Documents can be attached providing additional information for approvers or drawing
of the item can be attached.
Availability: The availability check can be done in backend ERP system before ordering and this al-
lows checking whether a vendor can deliver the items in full, can make partial delivery or is not in a
position to deliver.
Sources of supply/possible vendor for the item: Source of supply data is picked up from backend ERP
systems from past purchase orders or contracts. Employee can see and select a particular vendor. The
employee may specify a desired vendor if they do not like the assigned source and the purchaser need
to approve this vendor before releasing the purchase order.
Approval preview: Before ordering the shopping cart, employee can check that whether this shopping
cart needs approval and by whom.
Procurement Card Procurement card (P-card) can be used as a payment method in e-Procurement sys-
tems. P-cards are credit cards offered by companies like American Express and Visa whose invoices can go
to the employee or corporate and using these cards employees can do procurement. If the employee wants
to pay through P-cards, the card information must be entered into the system while creating a user.

Figure 23.5 shows how this process is done in a standard e-Procurement solution like SAP EBP.
The steps in this process are as follows:
While creating a shopping cart in e-Procurement system, procurement card payment needs to
be specified.
Vendor sends the bill to the card company.
The card company sends the periodic statement (say, monthly) to e-Procurement system.
e-Procurement system generates an invoice in the backend ERP system.
This invoice triggers an approval workflow and the cardholder gets a system generated e-mail
to check the charges and approve the invoice.
340 Enterprise Resource Planning

Once he approves the amount, the amount gets transferred to the backend system for
payment to the card company.
Procurement card has a transaction limit and if the shopping cart amount is higher than this
limit then it is not to save the shopping cart.
During the settlement process also workflow can check the cardholder’s approval limit and
the cardholder receives an auto generated e-mail in his inbox, if the amount exceeds his limit.
Depending on how the system is set up, the manager can receive an e-mail, can monitor the
expenses and if needed can give an exceptional approval.

Fig. 23.5 Procedure of Purchase Card with SAP*

P-Card is a Win-Win for Both Buyer and Supplier

Benefits to Buyer
Reduce cost of purchasing and payment by cutting out unnecessary administration of multiple order-
ing and payments to monthly one order and one payment. Throughout the month if the employee is
traveling to ten places and book ten flight tickets and ten nights in different hotels, the company pays
 Supplier Relationship Management 41

only once to P-card company (say, Amex) on the basis of one monthly bill. This reduces administra-
tion of twenty different payments to just one.
Replacing manual processes with electronic ordering, payment and reconciliation. This enables instant
information sharing and processing.
Improved control as all purchases are authorised electronically and controlled within spending lim-
its.
Reconciling transactions are easier as all transaction details are available on the net. This help in quick
reconciliation and resolve discrepancies.
Benefits to Supplier
Greater security for suppliers as here bank guarantees payment.
Low payment transaction costs as payment happens electronically.
Lower administration costs as there is no cost and effort of collecting on accounts receivable and
outstanding debt is virtually eliminated.
Eliminates disputes, as each transaction is authorised beforehand.
Controlling Transactions in P-Card It is the responsibility of the organisation to control transactions
in P-card as any late settlement or misuse here by the employees can cause huge liability for the company
and loss of goodwill in the market. This necessitates establishing proper governance process for all P-card
transactions and regulating usage of such card by different company employees. Different types regulate
this by variety of control measures like:
Setting limits per card and transaction (value and volume)
Restricted use for selected supplier categories and even specific suppliers
Zero “floor limit”, therefore every purchase transaction must be authorised before the purchase can
be processed.
Bidding/Auction/Reverse Auction
Bidding Bidding is a suitable process for selecting the most suitable offer in case an organisation deals
with a large number of requests for quotations (RFQs). There can be several types of bids like:
Public Bids: Here bid invitations are made accessible to potential bidders via marketplaces on the
web. The bidder can reach company’s web page via a hyperlink from the portal, log on to enterprise
buyer system, and enter their bid.
Restricted Bids: In this case bid invitations are made accessible to known bidders via e-mail. After
that the process is same as earlier, i.e. the bidder can reach company’s web page via a hyperlink from
the portal, log on to enterprise buyer system, and enter their bid.
Bids can also be classified as
Online Static Sealed Bid: The bidders are allowed to bid only once with their price within a window
of stipulated time.
Online Dynamic Sealed Bid: Same as the above except the bidders are allowed to improve their price
bids and till the hidden reserve price level is touched.
Forward and Reverse Auctions
Forward auction (FA) This is used for the disposal of excess or obsolete materials. For example, a steel
company can use forward auction to sell scrap or another company can use it to sell obsolete equipment.
Reverse auctions (RA) In a Reverse English auction, sellers bid the lowest price they are willing to sell
an item for and bidding activity. Bidding stops when the auction duration is complete. The item is bought
342 Enterprise Resource Planning

from the lowest bidder at their bid price. English (reverse) auctions also allow the buyer/seller to specify a
reserve price below which the item will not be sold.
Bidding, Tendering and Auction Process Authorised employee in the procurement team can create
bid invitations for materials and services. Once all responses are received for the invitation, these responses
can be evaluated by the purchaser and best bid is accepted. While creating bid in e-Procurement system,
the buyer can attach explanatory texts or documents like technical drawing to explain the details of the
item or create a bid invitation quickly by copying most of the content from a similar invitation. In case of
a restricted bid invitation which is informed to few bidders, the selected bidders get an e-mail. In case of a
public bid invitation, this can be published in company’s website or portal.
If the buyer fills that he can get a price better than the best bid submitted earlier, he can convert the bid
invitation into a reverse auction. The previous bidders receive an e-mail and can then check their bids again.
In this case all bidders can see the best price for the item, but will never see that who has submitted the best
price. If bidders want, they can re submit their best price again. Bidding stops when the time is over and
the item is bought from the lowest bidder. A purchase order can be created for the bidder that has submitted
the best bid in the backend ERP system or directly from the e-Procurement system.
Catalogue and Content Management
Catalogue Management One of the main reasons of using e-Procurement solution is that it forces all
employees to buy materials from few strategic suppliers with whom the company has corporate contract, i.e.
employees are assured of quality materials and the company is assured of best possible price. This also helps
in consolidation of procurement to few suppliers and thus economy of scale. Catalogues help to facilitate
this process in variety of ways:
Catalogues list all products and detailed product information including links to supplier data.
Catalogues help employees to easily find the products that they require and for this they support strong
search engines that can locate product based on description, product attributes etc.
Catalogues can provide price information.
Catalogues can also check availability from a supplier.
There can be several options for making catalogs available to employees. Figure 23.6 shows these several
options and they are detailed below as follows:
External catalogues: In this case, the catalogue is managed, updated and hosted by the vendor at his
own site. This is good for the company as vendor in this case is taking all the responsibility. The only
issue is that for different items, the employee needs to visit websites of different vendors and look and
feel of each of them can be very different may cause problem for employees who are not net-savvy.
Internal catalogues: This is the opposite of first one. In this case, the catalogue is managed, updated
and hosted by the company at his own site. The catalogue can have products of various vendors based
on kind of products the company employees need and the vendors with whom the company has price
agreements. Advantages of this catalogue are that its look and feel catalogue can be controlled; its
uniformity for all products makes it easy for employees to find the products of their need; and it is a
multi-supplier catalogue. The obvious disadvantage is that as the company needs to build and maintain
this, it needs time, one-time cost and recurring expenditure. E-Procurement vendors need tools to build
such kind of catalogues.
A third party manages the multi-supplier catalogue on behalf of the company: This multi-supplier
catalogue is managed by a third party content aggregator on behalf of the company. Advantage of this
is the consistent look and feel for the catalogues from multiple suppliers and the disadvantage is the
recurring expenditure that needs to be paid to the third party.
 Supplier Relationship Management 343

Fig. 23.6 Catalogue Management—Several Options

Different companies select different options based on their business needs. E-Procurement tools sup-
port any catalogue that comply with global standard Open Catalogue Interface (OCI) which describes the
exchange of data between e-procurement and catalogue applications, and enables transfer of products from
an external catalogue to e-Procurement.
Content Management Managing content is a big challenge as vendor’s products get updated frequently
with new additions and discontinuations of products, price changes, change of attribute, etc. e-Procure-
ment applications provide tools to manage this content dynamically, i.e. rather than maintaining product
data manually, catalogue data can be imported from external sources such as third party content providers,
vendors, etc. It is imported in specific formats, then classified, corrected (duplication check, etc.) approved
and then transferred to product master according to company schemes.
Supplier Collaboration Supplier collaboration technologies are becoming the heart of supplier relation-
ship management applications. There are several areas where collaboration can bring business benefits for
both the supplier and the company and there are several technologies which can help in this area. All ERP
and supplier relationship management vendors today support some form of collaboration.
Areas of Supplier Collaboration
Demand/Forecast collaboration: In this form of collaboration companies share their demand fore-
casts with suppliers so that suppliers can plan their production and raw material procurement. It is
common to share both their short-term detailed forecast and long term approximate forecast. In some
cases, if suppliers can not meet this delivery schedule, they provide their inputs and based on which
the plan can be altered. Few companies jointly make their long-term sales plan with inputs from their
suppliers.
344 Enterprise Resource Planning

Inventory collaboration: In this form of collaboration suppliers manage inventory for the company,
based on daily sales and stock status information. This is also called vendor-managed inventory (VMI)
and quite common in retail and CPG industry where retailers send their daily point of sales (POS)
data to their supplier and supplier makes replenishment decision based on that. P&G and Walmart
case study on VMI is a well known example of inventory collaboration.
New product development collaboration: In this form of collaboration, the company and its sup-
pliers together design the new product with inputs from both during the entire product development
process.
Payment collaboration: This form of collaboration is also known as evaluated receipt settlement
(ERS) where steps in the invoicing and payment process are eliminated and payments are issued
automatically to suppliers after materials are received.
Logistics collaboration: Here the company may collaborate with its 3PL partner for load consolida-
tion, return load planning, delivery of products, etc. This can even go up to collaborating with other
companies through logistics exchanges for better load planning and logistics cost reduction.
Forms of Supplier Collaboration There can be various levels of collaboration between the company
and its suppliers. Figure 23.7 explains this and this is described below:
Basic level: Here the company shares its plan to the supplier, but do not allow the supplier to alter
or modify this. The most common example of this is a company sharing its production plan to the
supplier for next few weeks and asking the supplier to make deliveries as per this plan.
Advanced level: This is the next level of collaboration where the company shares its plan with the
supplier and allows the supplier to modify this, if required or the company shares its sales data based
on which the supplier plans. The most common example of this is vendor-managed inventory (VMI)
planning.
Matured level: This is the highest level of collaboration where the company and its supplier together
plan for the future. A good example of this is collaborative planning forecasting and replenishment
(CPFR).

Fig. 23.7 Forms of Supplier Collaboration

 Supplier Relationship Management 45

Technologies for Supplier Collaboration There can be various technologies for supplier collaboration
and this range from most basic technology like EDI to most advanced ones like Inventory collaboration
hub. These are listed below:
Electronic data interchange (EDI): The oldest message-based collaboration technology for transmit-
ting things like purchase order, advanced shipping notification (ASN), invoice, etc.
Portal: The company’s portal give access to its suppliers about delivery schedule, stock information,
quality of receipts, rejection, if any, payment information, etc. Supplier self-service (SUS) portals are
part of supplier relationship management (SRM) solution of few ERP vendors like SAP.
Inventory collaboration (VMI and SNC): Most of the ERP and SRM solutions provide features like
vendor-managed inventory (VMI) and supplier network collaboration (SNC) for supporting this kind
of collaboration need. For example, VMI is supported by SAP in its ERP solution and its advanced
planning and optimisation (APO) solution. SAP also has a solution in SNC area for inventory col-
laboration with suppliers.
Collaborative forecasting: ERP solutions provide advanced collaborative forecasting features in its
advanced demand planning solution. For example, SAP supports collaborative forecasting in its demand
planning (DP) module of APO solution.
Evaluated receipts (ERS): Most of the ERP solutions support ERS functionality.
Example: Direct Material Procurement Collaboration Using Supplier Portal Figure 23.8 gives an
example of direct material procurement collaboration in ERP. Steps of this process can be as follows:

Fig. 23.8 Direct Material Procurement Collaboration using Supplier Self-service

346 Enterprise Resource Planning

1. The company runs MRP (material requirement planning) and plans for direct material requirement.
2. Based on this MRP run, PRs (purchase requisitions) are created; these are converted to purchase order
and published in supplier portal so that vendors can see.
3. Vendors provide their response on this purchase order, i.e. whether quantity is acceptable, any change
is needed, etc.
4. Based on this purchase order quantity, vendors send advance shipping notification to the company.
5. Materials are received by the company.
6. Payments are made by the company to the supplier and these credit memos are visible in supplier
portal.
Offerings from two Leading SRM Vendors—SAP and Ariba
SAP SRM Figure 23.9 gives an overview of different modules of SRM solution from SAP and capabili-
ties of modules are detailed below:
A. Enterprise Buyer Professional (EBP) This is the central piece for SAP SRM solution and empowers em-
ployees with self-service procurement and centralised direct procurement. Key capabilities here include:
Direct Procurement (planned materials, raw and packed) capability - Integration with planning and
execution systems
Indirect procurement
Services procurement

Fig. 23.9 SAP SRM 5.0 Solution Map

Source: www.sap.com
 Supplier Relationship Management 347

Contract management
Supplier portal for supplier self-service
Sourcing cockpit
Workflow
B. Catalogue Content Management (CCM): CCM is SAP’s catalogue content management tool which
provides the structure and processes necessary to successfully create, manage, and maintain a unified internal
catalogue. It includes a TREX search engine that enables users to browse the catalogue at run-time.
C. Bidding Engine: This supports sourcing needs through RFP, RFQ and reverse auction capabilities. It
helps in different decision supports like bid analysis, single and multi-parameter matching, ranking and
winner determination, etc. It has strong integration capabilities with back-end ERP systems.
D. Supplier Self-Service (SUS)/Supplier Portal: A web-based application that gives suppliers access to
its customers’ systems. This drives participation within the supplier community, reduces costs and increases
speed across the value chain. Key capabilities of supplier portal include:
A dedicated supplier homepage that helps suppliers to see next set of orders from their customers,
status of their last goods receipt (accepted or rejected), invoice status, helps them to make service
entry and invoice entry.
Reporting: Web reports accessible to suppliers keeping them up-to-date on their transactions and
performance.
Master data management of catalogue (products and prices) and contracts.
E. Analytics: SAP Decision Support provides analytics to support all SRM processes. In areas like supplier
strategy management, strategic sourcing, relationship monitoring, global spend analysis and document level
procurement process monitoring. Key capabilities include:
Global spend analysis
Supplier base analysis
Sourcing intelligence based on external market data
Procurement history per supplier, material, requester, purchaser, cost centre manager, etc.
Alerts
Supplier relationship monitoring – Performance and reliability KPI, quality monitoring, supplier
scorecards
Contract Analysis – Utilisation of contract in terms of time, value and volume, expiring contracts
Ariba SRM (Spend Management) Solution Ariba is a leading solution in SRM space and its solution
is known as Ariba Spend Management. This solution has following modules:
Ariba Buyer: It automates the full buying cycle for better spend operations and restricts maverick
buying.
Ariba Enterprise Sourcing: This is an enterprise-wide strategic sourcing application for all spend
categories and optimise sourcing activities with flexible bidding options and decision support tools.
Ariba Category Management (ACM): Helps companies source more strategically by enabling
sourcing and procurement professionals to collaborate closely and capture category knowledge for
re-use. It helps in better manage complex categories of spend, including catalogue, travel, third party,
time-based and project-based. This enables companies to take full advantage of negotiated contracts
and preferred terms, purchasing best practices, improved collaboration with suppliers, and payment
compliance and reconciliation. With this companies can improve category spend management across
a broad range of categories including facilities management, IT and management consulting, field
maintenance, legal services, market research, temporary labour, print services, etc.
348 Enterprise Resource Planning

Ariba Analysis: Drives enterprise-wide spend visibility and spend reductions through improved
category management, procurement compliance, operational effectiveness, and supplier performance.
Businesses can aggregate data across systems; can get better analytical reports, dashboards, Alerts,
data in different chart format, etc.
Ariba Contract Compliance: Provides enterprise-wide management of the entire contract lifecycle
and through this buyer can create, search, amend, and re-source contracts as well as monitor contract
usage and supplier price compliance.
Ariba Invoice: Replaces manual activities with electronic invoicing and minimises the costs and er-
rors of manual data entry, invoice matching, and exception resolution.
Ariba Supplier Network (ASN): ASN is the network that provides access to a global supplier
community through a single connection. Buyers can leverage ASN to access global public supplier
directories of thousands of enabled suppliers while benefiting from negotiated visibility, security, and
privacy.
Ariba has few hundreds e-Procurement implementations globally and provided quantifiable benefits to
its clients in procurement area.

Summary
In this chapter we discussed about supplier relationship management solution – evolution of these solutions
and how it is useful for different types of procurement processes for MRO, direct items, office stationery for
employees, etc.
e-Procurement is the largest component of SRM solutions and there are several technologies to support this.
Shopping cart, procurement card, auctions, tendering, etc are few of those.
Managing catalogues is a related technology with e-Procurement and SRM solutions provide different options
for managing catalogue internally, externally or managed by a third party.
Supplier relationship management also helps in different forms of supplier collaboration and in this chapter
the related technologies are discussed.
Modules from two leading SRM solutions SAP and Ariba are discussed.

Exercise
I. Objective Type Questions
1. What is SRM?
2. What was the first generation of SRM application?
3. What are the different origins from where SRM applications came?
4. What are the different categories of buyers that can use SRM?
5. What are the five different application categories under SRM?
6. What are the three different e-Procurement options?
7. What is electronic shopping cart?
8. What are the different facilities provided by electronic shopping cart to facilitate search of an item?
9. What is a P-card?
10. What is the difference between public bid and restricted bid?
 Supplier Relationship Management 349

11. How static and dynamic sales bids are different?

12. What is forward and reverse auction?
13. Reverse auction is typically used for what?
14. What are the three types of catalogues?
15. What is content management?
16. What are the five common areas of supplier collaboration?
17. What are the different technology options for collaboration?
18. What is EDI?
19. What is portal?
20. What is VMI?

II. Descriptive Type Questions

1. What is SRM? How did these applications evolve? How does it help different categories of buyers in an
organisation? What are the fundamental principles of business process?
2. What is Electronic procurement? What are the different technology options for e-Procurement? How
electronic shopping cart helps in e-Procurement? How can goods be first ordered, get necessary approval,
received and finally payments are made through electronic shopping cart?
3. How does P-card help in electronic procurement? How is P-card a win-win both for buyers and sellers?
How are P-card control unauthorised transactions?
4. Explain different types of bids. Explain the tendering and auction process.
5. What is a catalogue? How does it facilitate the procurement process? Explain different types of catalogues
and who manage them. What are the advantages and disadvantages of each?
6. Explain common areas of supplier collaboration. How can the collaboration be at different levels? How is
collaboration facilitated by different technologies?

III. Fill in the Blanks

1. P-card stands for __________ card.
2. P-card is an _________ procurement tool.
3. Zero floor limits is a way of ensuring mandatory _________ for transactions.
4. Favourites are a way to facilitate ___________ for shopping cart.
5. Two types of common bids are _________ bids and _______ bids.
6. OCI stands for ___________ ______________ ___________.

IV. State whether the following statements are True or False

1. In a Reverse auction, sellers bid the lowest price they are willing to sell an item.
2. In a static sales bid, bidders are allowed to bid multiple times.
3. External catalogues are hosted by the company.
4. Portal can be a technology for collaboration.
5. CPFR is a basic level of collaboration technology.

V. Assignments
Study in details the supplier relationship modules of three leading SRM solutions, i.e. Ariba, SAP SRM and Oracle
i-Procurement. Note down all their modules and sub-modules. What capabilities do they offer? Draw similarities
and differences of their capabilities.
 24
Production Planning
and Execution Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Understanding MRP II Concepts
Sales and Operations Planning (SOP)
Master Production Scheduling (MPS) and Available to Promise (ATP)
Material Requirement Planning (MRP) and Closed-loop MRP
Capacity Planning
How ERP Production Planning (PP) Module Supports MRP II Processes
Sales and Operations Planning
Distribution Requirement Planning
Long-term Planning
Master Production Scheduling
Capacity Management in ERP
Critical Master Data Elements for Production Planning
Managing Different Production Scenarios
Just-in-Time/Kanban Systems
Repetitive Manufacturing
Manufacturing in Process Industry

UNDERSTANDING MRP II CONCEPTS

ERP systems had their origin in MRP and MRP II systems. MRP (material requirement planning) was quite
a popular tool among manufacturing industries in the 70s that helped to calculate material requirement.
However, the scope of this tool was only limited to production and procurement teams.
In the late 70s and early 80s, manufacturing resource planning (MRP II) emerged. The main difference
of MRP II with earlier MRP is that it integrates other departments like marketing and finance in the plan-
ning process and not limited to only manufacturing. Business planning stage of MRP II incorporates plans
of finance, marketing and production who all agree on a common plan. Marketing and production also
 Production Planning and Execution 51

coordinate on a regular basis every week or month in the sales and operations planning process and adjusts
the plan as required. Continuous changes in the market space like cancellation of orders, changes in delivery
schedule, additional orders, etc. need to be reflected in the plan. In MRP II, these changes are reflected in
master production schedule (MPS). MPS drives MRP, i.e. requirement of components and raw materials.
As shown in Figure 24.1, MRP II has five major levels:
Business plan
Sales and operations plan
Master production schedule
Material requirement planning
Purchasing and production scheduling

Fig. 24.1 Manufacturing Resource Planning Systems (MRP II)

While the first four is planning activity, the last one is very close to scheduling and actual execution. Each
of the four planning levels has a different planning purpose, has a different planning horizon, and has dif-
ferent levels of detailing and need to be reviewed at different frequencies.

Business Plan
Purpose This plan talks about long-term goals, objectives, business direction in terms of product lines,
markets, etc. and jointly agreed by all teams in the organisation, i.e. marketing, production, finance and
engineering.
352 Enterprise Resource Planning

Planning Horizon This is a long-term plan spanning over next three to five years.
Level of Detailing This plan is done at a high level.
Review Frequency Usually reviewed once in every quarter.

Sales and Operations Plan

Purpose This is a joint plan developed by sales and marketing teams together. This plan details the
quantities of different product groups that need to be produced in each period (i.e. every week or month),
resources (machine capacity, labour, materials, etc.) needed for each period and does capacity availability
check through resource planning.
Planning Horizon Typically 6-12 months.
Level of Detailing This plan is done at product group level.
Review Frequency Usually reviewed once in every month.

Master Production Scheduling

Purpose This plan details the plan of finished products to be made in each period (typically every week).
Against this plan, an availability check is done through rough cut capacity planning. This plan is also used
for available to promise check and to promise date of delivery to customer.
Planning Horizon Typically 6-12 months.
Level of Detailing This plan is done at end product level.
Review Frequency Usually reviewed once in every week.

Material Requirement Planning

Purpose This is a plan for production and purchase of components needed for making the items in master
production schedule. This tells how much quantity is needed (based on finished goods bill of material) and
when it is needed (based on manufacturing and supplier’s lead time).
Planning Horizon Combined manufacturing and purchase lead time.
Level of Detailing Very high–include individual components.
Review Frequency Usually reviewed once in every week.

Purchasing and Production Activity Control

Purpose This is the implementation phase of production planning and control systems. While purchas-
ing controls flow of materials from vendor to factory, production activity control plans and controls flow
of work through the factory.
Planning Horizon Very short may be a day or shift.
Level of Detailing Very high including individual components and machines.
Review Frequency Daily.
 Production Planning and Execution 353

Sales and Operations Planning

Forecasting or Demand planning is a process where the company estimates that how much will be the demand
for the products/services they offer. This need to be in line with company’s financial target (turnover, profit,
etc.) and against a supply plan, i.e. from where these products/services will come, i.e. from which factory,
from which supplier on which date, etc. This supply plan needs to take company’s own capacities and its
supplier’s capacities in consideration. This process of matching demand with feasible supply plan is called
sales and operations planning (S&OP). Without S&OP process, the operational departments (i.e. factory and
procurement) will work independently from that of sales/marketing team creating separate plans for their
respective areas. As shown in Figure 24.2, S&OP process brings the balance between sales and operational
elements. Inputs to sales and operations plans are
Business or annual plan
Operations strategy
Capacity constraints
Demand forecast

Fig. 24.2 S&OP Process Synchronises Supply Chain

Typically S&OP is done at product group level and not at individual product level. Product group is defined
as a group of services or products that have similar demand requirements and common processes, labour
and materials requirements. For example, an F.M.C.G. company may do S&OP at the level of powder de-
tergent and detergent cake level and not at the individual product level (say, individual products may be at
the level of 100 gm, 500 gm, 1 kg, etc.) as machine and material requirements are common for all products
under these product groups.
Sales and Operations planning process can involve multiple inputs as shown in Figure 24.3 and multiple
reviews like:
Demand review: Anticipate total market requirements for company’s products from all perspectives,
using sources such as quantitative forecasts, input from sales and marketing, and what-if analysis.
354 Enterprise Resource Planning

Fig. 24.3 Sales and Operations Planning Inputs

Supply review: Reviews supply chain capacity including inventory requirements, factory capacities,
supplier capacity, logistics capacity (warehouse, handling, and transport) to make certain that there is
sufficient manufacturing and distribution capacity. In this step the potential need for outsourcing (for
additional capacity) is also evaluated.
Financial reconciliation review: Translate the supply and demand plan into financial terms of revenue,
margin, and working capital requirements.
New product review: Analyse the potential for new products to impact the market, considering ramp-
up projections, and cannibalised demand.
Management evaluation and analysis: S&OP need to match different management KPIs, evaluation
of planned versus actual results, an analysis of profitability by customer, channel, and product, and a
look at asset performance. Typical KPIs of S&OP process can:
Minimise costs/maximise profits
Maximise customer service
Minimise inventory investment
Minimise changes in production rates
Minimise changes in workforce levels
Maximise utilisation of plant and equipment
S&OP process may vary as per the type of product, i.e. make to order (for example, an aircraft or ship),
make to stock (for example, soap and detergent) or assemble to order (say, personal computer). The process
may also vary as per the manufacturing strategy the company adopts. For example, level production (try
to produce at a uniform rate through all the months) or chase demand (at a varying production rate as per
demand).
 Production Planning and Execution 55

Master Production Scheduling (MPS)

Master Production Scheduling or MPS is an important link between operation/production plan (of sales and
operations planning) and MRP. As we know that SOP or production planning is done at product group level,
but MPS is done at individual product level and it states the requirements for individual finished products
by date and quantity that need to be produced, i.e. it details what the company plans to produce, expressing
in specific configurations, quantities, and dates. MPS drives material requirements planning. MPS takes into
account the forecast, the production plan, the production priority and other considerations such as backlog,
available-to-promise quantity.
So, in brief,
MPS is the manufacturing build schedule of individual finished products by date and quantity, i.e. it
tells manufacturing which items need to be made on what date
MPS drives MRP
MPS is the basis for making order promises, i.e. it tells company’s sales and marketing team that
which product will be available on what date
MPS is a priority plan for manufacturing, i.e. it tells manufacturing which customer orders are to be
given priority.
MPS Inputs Developing an MPS needs the following inputs:
The production plan
Forecasts of finished goods
Actual orders received from customer
Inventory for all finished goods
Capacity information
Available to Promise Capability of making promises for delivery is a basic requirement for every
business. When the customer calls the company sales representative and asks when a particular material
will be available, be sales team needs to know whether the material is available from ready stock or from
scheduled receipts. If it is available from ready stock and not reserved for other customer, the sales guy can
just add the delivery lead time and give the customer a date on which materials will reach him. In case the
material is supposed to come from a vendor or need to be manufactured, the date of scheduled receipt from
manufacturing or vendor is taken for promising availability. From the available stock or available scheduled
receipts, any thing which is not against a particular customer order (i.e. not reserved for a particular customer)
is something that can be promised to a new customer. This quantity is called available to promise (ATP).

Material Requirement Planning (MRP)

Understanding MRP Fundamentals A. Concept of material requirement planning (MRP) and
consumption-based planning (CBP):

MRP: Requirement of materials is mainly driven by finished product demand which comes from sales and
distribution team based on actual customer requirements (current customer order) and some forecast (fu-
ture customer requirements). This finished product demand triggers demand for dependent items based on
bill of material (BOM) explosion and BOM calculation. For example, for an automotive company, if they
have confirmed customer order for 10000 cars for next year and sales team forecasts another 5000 cars, the
car company’s total demand of finished products is 15000. Each car needs 4 tyres and so, the company’s
356 Enterprise Resource Planning

planning system will trigger a requirement of 60000 tyres that need to be procured from vendors. This
process of planning is called MRP and is, especially useful for planning important assembly groups and
components. Figure 24.4 shows a simple MRP model where finished goods requirement comes from MPS.
Item master is a master data of all finished goods and raw materials. Bill of material is a master data which
stores information on what items of how much quantity is needed to make the finished product. Inventory
record shows how much of stock of raw material is available. Based on these inputs, MRP creates plan
for production and purchase items. MRP creates requirements not only for items that need to be procured
externally, but also for items that need to be produced in-house. In the above example, the MRP planning
run will not only create requirement of tyres, but also requirements for chassis which the car company need
to make in its own factory.

Fig. 24.4 MRP—Inputs and Output

CBP: In the above example, the car company will also need spares for its machines, papers and stationer-
ies to run its office. But the demand for these items can not be directly linked to the demand of finished
products. Planning for these items are done by a method called consumption-based planning which is
popular for planning B and C class of items. This is based on historical data, and uses material forecasts or
statistical procedures to determine future requirements. For example, the company may plan for stationary
consumption in office, based on consumption pattern of last few months and forecast, based on that (say,
1000 units/month) or fix a reorder point (say, 200 units) and orders as soon as the stock falls below that
level. Thus, CBP does not have any relation with the finished product demand.
Table 24.1 explains the difference between MRP and CBP.
 Production Planning and Execution 357

Table 24.1 MRP vs. CBP

Material Requirement Planning (MRP) Consumption-based Planning (CBP)

Mainly followed for production items Mainly followed for consumables, regular spares, office
supplies, etc.
Plan is driven by finished goods requirement Plan is driven by past consumption and forecast
MRP need a BOM explosion CBP does not need a BOM explosion. There can be
several approaches for CBP: forecast-based, time-based,
reorder-based

There can be different types of consumption-based planning like reorder point planning (procurement is
triggered whenever stock level falls below a predetermined point), forecast-based planning (system forecasts
for future requirements based on historical consumption and plan based on that) and time-phased planning.
Figure 24.5 explains different MRP approaches.

Fig. 24.5 MRP Procedures

B. Concept of planning horizon

Planning horizon defines the period for which the planning is done. For example, if the planning horizon is
next one month, the demand elements of next one month are only considered for planning. This necessitates
the planning run to happen on a regular basis, i.e. in this case monthly once.

C. Concept of planning sequence and low-level code

MRP always happens in a sequence. For example, a car at the highest level is made up of a chassis assem-
bly, a gear box assembly, an engine assembly, etc. MRP run first explode bill of material and plan for these
358 Enterprise Resource Planning

assembly items. Now each assembly may be made up of hundreds of other components like the gear box
assembly may be made up of gears, bearings, fasteners, mechanical components, etc. Once the planning for
number of gear boxes required to meet month’s sales target of car is completed, MRP run explodes BOM
of each gear box and plan for component items. This sequence of planning is driven by something known
as low-level code. Here car’s low-level code is zero, i.e. first this needs to be planned, gear box assembly’s
low-level code is 1, i.e. this needs to be planned next, low-level code of gear box components is 2, i.e. this
needs to be planned next. The planning goes on like this. Finished products always have low-level code of
zero.
Figure 24.6 explains the concept of low-level code. Finished product A, contains items B and C. B uses
D as one of its raw materials and D, in turn, needs C and E. Low-level code is always defined by the low-
est level, so though B is available both at Level 1 and 3, its low-level code is 1. A has a low-level code of
zero, i.e. it will be planned first, next B is planned as this has a low-level code of 1, followed by D having
low-level code 2 and finally C and E are planned as both have low-level code 3.

Fig. 24.6 Low-Level Coding

D. Concept of gross and net requirement calculation

In the car example we are using in this chapter, if the company is planning to sell 1000 cars in the next
month and it needs four tyres for each car, is there a need of 4000 tyres from the vendor next month? The
answer is ‘No’. There can be several reasons for this:
In a running factory, you will always have stock for tyres. Say in this case, you have a stock of 300
tyres already available with you.
There will be some items which you had ordered the vendor, but not received till now. Say in this
case delivery for 200 tyres is pending from the vendor from last month.
So, Gross requirement of tyres in this case is 4000
But, the net requirement = 4000 – 300 – 200 = 3500
So, formula for calculating net requirement is:
Net requirement (i.e. net shortage quantity) = Gross requirement – Stock in hand – Planned receipts
(Quantity already ordered)
Figure 24.7 explains the concept of gross and net requirement planning. For items A, B, C, D and E, as
there is some stock in hand, gross requirement will be different from net requirement.
 Production Planning and Execution 359

Fig. 24.7 Gross and Net Requirement

E. Concept of lot sizing procedure

In the earlier example, the net requirement quantity is calculated as 3500. Is it the quantity to be directly
ordered to vendor? The answer may be yes or no. The reason being that the vendor may accept order only in
fixed lots of thousand or the company wants to order in fixed lot of thousand as that is a full truck load. In
both the cases, the quantity needs to be changed to 4000. So net requirement need to be rounded up as per
lot size. Figure 24.8 explains the concept of different lot sizing procedures and they are discussed below.
There can be different types of lot sizing rules like:
Lot-for-lot: In this case, an order proposal is created for the exact shortage quantity. In earlier example
if this lot size procedure is selected, the system will create an order exactly for 3500.
Fixed lot: In this case, an order proposal is created for the fixed lot size, if a material shortage occurs.
For example, if the fixed lot size is 5000 in earlier case, the system will create an order proposal for
5000.
Periodic lot-size: Here the system group together with requirement quantities from one or several
periods to be formed a lot. Periods can be days, weeks or months and all requirement quantities that
fall within a day/week/month are grouped together to form a lot. In the car company example, the
company may follow a weekly lot sizing policy, i.e. create one purchase requisition grouping all part
requirements within a week.
F. Concept of date calculation in MRP—Backward scheduling
If materials are planned according to MRP and requirement dates of finished products in the future are
known, the components and raw materials need to be ordered by a particular date (called release date) to
meet the production schedule. The release date of the purchase requisition is calculated going backwards
from the requirements date and this procedure is called backward scheduling. From the requirement date,
goods receipt processing time in workdays is subtracted to get delivery date of material. From delivery date,
planned delivery time in days, i.e. vendor’s lead time is subtracted to get the date by which the order should
360 Enterprise Resource Planning

Fig. 24.8 Different Lot Sizing Procedures Supported in ERP

Fig. 24.9 MRP Date Calculation–Backward Scheduling

reach the vendor. Processing time for procurement is subtracted from this date to calculate the release date.
Figure 24.9 explains the concept of backward scheduling.
Release date = MRP date – Goods receipt processing time – Planned delivery time (Vendor’s lead time)
– Processing time for procurement
 Production Planning and Execution

G. Concept of time fences

Planning based on MRP necessitates the concept of time fences. Time-fence policy defines during which
period how much change in the end product demand is allowed. As we know, business situations are always
dynamic and there will be always cases of order cancellation by customer, new orders and rescheduling
of orders after you start your MRP planning. However, if all these changes are incorporated, the plan will
become highly unstable, i.e. the company will send a set of purchase orders based on today’s customer de-
mand and will change those quantities tomorrow as the customer order had changed. Vendors also may not
accept this kind of situation. So, MRP planning necessitates a frozen period of short horizon during which
changes are not permitted and this is called frozen period (say, for 1-2 weeks). Beyond this (say, for next
2-4 weeks), little change in demand is permitted (say, + / - 5%) and this is called firm period. Beyond this,
larger change in demand is permitted. Figure 24.10 explains this concept.

Fig. 24.10 Time Fences

H. Concept of exception messages: Any MRP planning run creates a lot of exception messages. Examples
of these can be start date in past, stock level falling below safety stock, etc. These need to be checked and
corrected by MRP controller post planning run. Priority of these messages can be defined, i.e. some messages
need urgent attention (priority 1 messages in red, messages of second priority, in yellow, etc).
MRP Output MRP run creates a set of planning results as follows:
Purchase requisitions for items that is procured from outside
Planned orders if items are produced in-house
These planned orders or purchase requisitions need to be converted to production orders or purchase
orders for execution. Several purchase requisitions can be combined to one purchase order and in the same
way several planned orders can also be combined to one production order.
MRP for Service MRP was one of the most popular planning methods for manufacturing companies
in the 80s. While MRP started its journey in manufacturing industries, it got extended to service industries
362 Enterprise Resource Planning

as well and by the 90s several service industries like hotels, hospitals and retailers started using MRP for
calculating demand for some service items. Service industry came up with something called Bill of Service
or Bill of Labour in line with Bill of Material to make their requirement.
For example, to make a Pizza, there are several activities need to be performed and involve different skill
as given in Table 24.2.

Table 24.2 Estimating Labour Hours for Making Pizza

Labour Hours
Work Centre Operation Labour Type Set-up Time Run Time
1 Assemble ingredients Helper1 0.1
1 Preparation Assistant Chef 0.05
2 Cooking Chef 0.1 0.2
3 Packing Helper 2 0.05 0.1

This is known as bill of service and can help in estimating labour hours required once the number of Pizza
to be made is known. For service industry, it can also helps in estimating the amount of materials required,
i.e. if we know what raw materials are required for 1 Pizza, it is easy to calculate material requirement for
100 Pizzas using MRP principles.
MRP Limitations While MRP is a very popular technique for estimating material and capacity require-
ments, this has several limitations. A different set of applications called Advanced Planning and Scheduling
(APS) address these limitations. Some of the common limitations of MRP are as follows:
It only projects how much material or capacity is required to meet the sales forecast. Can not consider
actual capacity available in shop floor, constraints and vendor’s limitations and plan. This is a major
weak point for MRP where APS solutions score.
Can not do any optimisation.
Requires very high accuracy of data, i.e. bill of material data, system stock, etc. Frequently for com-
panies, system stock differs from physical stock, i.e. stock shown in system does not exactly match
with physically what is available in the company’s store or warehouses. In these cases, MRP run will
not create correct planned orders or procurement proposals.
Can not replan fast enough. In a business environment, things can change rapidly, i.e. new customer
orders can come, demand dates may be rescheduled or orders may be cancelled. In every case in ERP
environment, it needs fresh MRP run which make take hours depending on number of products or
number of plants. However, business in most cases needs much faster replanning capability than what
MRP can offer.
Requires high user discipline, i.e. after every MRP run, the exception messages need to be looked
at/analysed and appropriate corrective action need to be taken so that it does not reoccur during the
next run. Also need high discipline regarding maintaining correct data in system.
Not appropriate for all areas like project or engineer to order type of manufacturing as here every new
order has a unique bill of material.
Closed-loop MRP MRP is known as an infinite planning tool, i.e. it does not consider available capacity
information while planning (assumes capacity is infinite). This means that MRP can give production plans
or procurement plans which are not executable as the amount of factory or supplier’s capacity it needs is
not available. So it is important to do a reality check of the plan. If the plan is not executable, then produc-
 Production Planning and Execution 363

tion plan for finished goods need to be changed at master production schedule stage and a fresh MRP run
is needed. Thus, MRP is a process of iterative planning as shown in Figure 24.11 and Figure 24.1. That’s
why this is also known as closed-loop MRP.

Fig. 24.11 Closed-loop MRP

Capacity Planning
Any organisation has a fixed set of machines and manpower available with them at a particular point of time,
i.e. they have limited capacity. However, the challenge is that the customer requirement keeps on fluctuat-
ing, demanding more or less capacity than what an organisation has. This leads to either less utilisation of
machines/idle capacity or loss of customer order as sufficient capacity is not available. In short, the challenge
of capacity planning is to balance capacity required (resource capacity needed to meet a desired output in
a given time period) with capacity available (resource capacity available with an organisation at any given
point). Capacity management can apply a variety of strategies like overtime, outsourcing, subcontracting,
etc. to create extra capacity and to meet capacity requirements. MRP II suggests capacity planning at dif-
ferent levels as shown in Figure 24.12.
Resource planning that is linked with S&OP
Rough cut capacity planning linked with MPS
Capacity requirement planning linked with MRP
Capacity control with production activity control and detailed scheduling in shop floor
364 Enterprise Resource Planning

Fig. 24.12 Different Levels of MRP II Planning Need Different Capacity Management Tool

HOW ERP PRODUCTION PLANNING (PP) MODULE SUPPORTS

MRP II PROCESSES
All leading ERPs support MRP II process. Table 24.3 shows how SAP ERP supports MRP II process.
Production planning module of SAP is designed around MRP II principle and different sub modules of PP
that support specific component of MRP II is listed in the table.

Table 24.3 How SAP ERP Supports MRP II Processes

MRP II Process Corresponding ERP module name (SAP module)

Sales and Operations Planning PP – SOP – Flexible Planning for Demand Forecasting
PP – SOP – Distribution Requirement Planning
PP – LTP – Long-term Planning
Master Production Scheduling PP – MP – DEM – Master Planning – Demand Management
Material Requirement Planning PP – MRP – Material Requirement Planning
 Production Planning and Execution 5

How ERPs Support Sales and Operations Planning (S&OP) Process

S&OP being a critical organisational planning process, all leading ERPs support S&OP process. For ex-
ample, SAP has a sub-module, called sales and operations planning (SOP) under its production planning
(PP) module. SAP SOP has following functionalities:
Product group: SAP SOP allows creation of product groups for S&OP.
Version management: This allows modeling different planning scenarios using different forecasting
techniques, different capacity information (for example, normal capacity, double-shift production, with
overtime hours), etc. Each planning version is stored under a version number and description.
Rough cut capacity planning: This is used for resource leveling i.e. based on demand planning
which resource need to be operated for how many hours, evaluating different alternate scenarios (for
example, subcontracting, overtime, etc.) when demand exceeds capacity. The objective here is to
maximise utilisation of plant and equipment and minimise overtime, etc.
Transferring SOP data to demand management: SOP plans are sent to Demand Management (PP-
MP-DEM) in the form of independent requirements. Demand management determines the requirement
dates and requirement quantities for important assemblies and specifies the strategies for planning and
producing/procuring finished products.

How ERPs Support Distribution Requirement Planning (DRP) Process

This distribution process is the process of shipment of finished goods from manufacturing locations, i.e.
factories through the distribution system to final customers. Distribution network is a network of warehouses,
distribution centres and retailers that starts with the factory and end with the customers through which
materials move from factory to end customer. Figure 24.13 is an example of distribution network compris-
ing retailers, local warehouse, regional centres, central distribution facility and factory. The objectives of
distribution resource planning (DRP) are as follows:
To improve customer service levels by anticipating customer demand at distribution centres and pro-
viding finished products at the correct location when customer needs arise
To provide an accurate requirement plan for manufacturing
Matching material supply to manufacturing demand and customer demand to product supply
To optimise the distribution of available stock in the distribution network
DRP minimises finished goods inbound inventory in the network.
DRP process is not a direct part of MRP II flow. This is an extension of MRP logic of manufacturing to
distribution network to provide a time-phased finished good inventory replenishment plan in the distribution
network. ERP systems started supporting DRP which uses MRP-type logic to translate local distribution
centre requirements into central distribution-centre requirements which can be then translated to central
warehouse requirements and finally into gross requirements at the factory. Figure 24.14 gives an example
of DRP calculation.
Inputs for DRP planning in ERP System:
Forecast of demand for each SKU (gross requirement)
Current inventory level of the SKU (balance on hand)
Target safety stock
366 Enterprise Resource Planning

Fig. 24.13 Distribution System

Lead time for replenishment

In transit (scheduled receipts i.e., the previously-placed orders that are expected to arrive in a given
week)
Planned receipts of shipments are orders planned, but not yet placed, for the future. These are also
called planned shipments or planned order releases
A DRP run generates stock transport requisition between locations, i.e. it tells what quantity of which
finished goods need to move from which factory to which warehouse/distribution centre. It also recom-
mends movements between warehouse and distribution centre or between two warehouses or between two
distribution centres.

How ERPs Support Long-term Planning (LTP) Process

Companies need long lead time for procuring imported raw materials or for increasing capacity (that may
need buying new imported machine or putting up new factory) or for identifying new vendors, if the present
vendor’s capacity is not sufficient. Some of these logistics decisions need to be taken early enough may be
quarters or years before and this necessitates long-term planning. ERPs support long-term planning process
mainly for following functions:
Long-term capacity requirement planning based on this decisions are taken to buy equipment or to
outsource operations
 Production Planning and Execution 367

Fig. 24.14 The DRP Plan

Planning of critical/long lead time materials – Based on long-term planning purchase, requisitions for
such materials are released
Purchasing budget based on future materials requirement
LTP functionality helps to simulate different versions of the future demand programmes, evaluate dif-
ferent long-term scenarios. The simulation can take into account operative data (for example, master data,
sales orders, purchase orders, production orders). Based on the simulative planning results, the demand plan,
the production and procurement plan are optimised. The current version of demand programme is replaced
with the preferred version in long-term planning. For example, a planner can simulate that if the demand
increases by 10%, what capacities will become bottleneck for him or for which he will have raw materials
shortage and vendors will not have capacity to supply. He can simulate the condition. If demand for his
product increases by 20%, what will happen or if demand falls by 10%, how much additional inventory he
will carry, etc? Among all these simulation versions – the scenario with highest probability or looks to be
most realistic becomes the active or preferred version of long-term plan and based on that purchase requisi-
tions are released or capacities are planned.
368 Enterprise Resource Planning

For most of the ERP vendors, LTP run is a special type of MRP run. However, these two are not exactly
same. The major differences between LTP and MRP are:
LTP run is for a longer horizon say 1-3 years. Typical MRP run is only for one month.
There is no simulation run in MRP which is common in LTP.
MRP run always uses actual bill of material of items so that every raw material for finished good can
be produced. However, LTP only plan for critical raw materials having long lead time etc. and not all
the materials. Thus, LTP may need separate master data from MRP.
ERP systems need specific customisations for LTP to define which factories for which simulation is to
be carried out, what opening stock the simulation is to assume, which order elements to be considered (i.e.
purchase orders, production orders, etc.) in the net requirements calculation, Which version of the available
capacity (Normal capacity, a version with overtime capacity, etc.) to be used etc.

How ERPs Supports Master Production Scheduling (MPS) Process

ERPs support master production scheduling, i.e. planning for end product based on variety of production
strategies. ERP can support different planning strategies to come up with master production schedule. De-
pending on the nature of product and nature of business planning strategy may vary. For example, for a
make to stock product like soap or detergent, the company does not wait for the final customer order and
start production based on forecast. On the other hand, for a make to order kind of product like aircraft or
ship, the company waits for the final customer order and product configuration and then start production.
While for an assemble to order kind of product say personal computer, it’s better to keep the components
ready and do only the final assembly as per customer’s desired configuration. These different types of pro-
duction scenario need different planning strategies to come up with final master schedule. While discussion
of each of these planning strategies is beyond the scope of this book, this is one of the major strength of
ERP applications.

How ERPs Support Capacity Management

ERPs support capacity management at all four levels as shown in Figure 24.12. While during LTP and SOP,
a rough cut capacity check can be performed, a detailed capacity plan machine-wise and production order-
wise can be done during capacity requirement planning along with MRP. ERPs support
Capacity evaluation
Scheduling orders for capacity management
Capacity levelling (in tabular and graphical form)
ERPs support a list of strategies to reschedule orders so that orders can be executed within available capac-
ity. This can include things like forward scheduling (try to find whether the machine is free in any of the
dates going forward then put the order there), order split (i.e. breaking the orders into several pieces and
trying to reschedule it within available capacity), operation overlapping (start activities in parallel), etc.
However ERP capacity management is mostly manual and is based on planner’s intelligence. This is one
area where supply chain solutions (these are also called advanced planning and scheduling i.e. APS solu-
tions) discussed in Chapter 24 scores higher than ERP as they can optimise plan of their own based on the
available capacity.

CRITICAL MASTER DATA ELEMENTS FOR PRODUCTION

PLANNING
Master data are those data elements in ERP system which does not change frequently. An ERP system will
need various master data elements for successful functioning. Figure 24.15 shows master data elements that
 Production Planning and Execution 369

Fig. 24.15 Production Planning Master Data

are important from Production planning perspective. Some of the important ones are:
Material master
Bill of material
Work centre
Routing

Material Master
Material master is the most important master data in ERP system. As shown in Figure 24.16, material
master can store lots of information, some of which are generic and some varies as per factory/plant or sales
organisation. For example, for product A, weight or volume data is always the same. However, production
cost or planning parameters may vary as per the plant (factory) where it is produced, i.e. production cost of
producing product A in factory X may be different from that of factory Y. As shown in Figure 24.17, material
master can have different views in which information are stored and each view stores information relevant
for a particular ERP module. For example, sales view stores information specific to sales, purchasing view
stores information specific to procurement, etc.

Bill of Material
Bill of material (BOM) is the most important master data for MRP and product costing. This defines which
raw materials/components are needed to make the end product and in what quantity. Any MRP run does a
BOM explosion, i.e. break up the end product (parent) sequentially into its lower level components (chil-
dren) in BOM down to fundamental components and determine the required quantity of children for each
370 Enterprise Resource Planning

Fig. 24.16 Material Master Data

Fig. 24.17 Master Data Views

parent. Figure 24.18 gives an example of BOM, where the cycle is made up of frame assembly and handle
bar. Frame assembly, in turn, is made up of two wheels and one frame. Thus, a BOM can have multiple
levels. BOM is also called product structure. Figure 24.18 shows a simple BOM. An actual bill of material
can be much complex.
 Production Planning and Execution 71

Fig. 24.18 Bill of Material

Work Centre
Work centres can be machine, people or production line where an activity is performed. As shown in
Figure 24.19, every work centre is generally associated with a cost centre so that for any activity done
at that work centre, costing can be done. Work centres are important for capacity planning, costing and
scheduling.
Costing: If a product needs ten minutes of processing time at a particular work centre, the cost of
this processing need to be calculated (from hourly rate of work centre) and need to build in the cost
of the product.
Capacity planning: Before MPS or MRP, the planner need to know whether the work centre is
available for 8 hours a day or 24 hours a day. If there are break time in between (say, lunch break for
an hour) or there are scheduled maintenance planned during particular day of the week, then these
information need to be included in the planning database.
Scheduling: If there are overloads, then a particular customer order can be shifted from one work
centre to other.

Routing
Routing tells the sequence of operations/processing that needs to be done to produce finished goods. Each
of these operations can be performed in a separate work centre as shown in Figure 24.20, where to produce
the finished good – three operations are involved – Operation 10 (Assembly), Operation 20 (Painting) and
Operation 30 (Finishing). Each of these operations is done in different work centres, i.e. W1, W2 and W3
and need different time duration, i.e. 20, 15 and 10 minutes. Each of these work centres can be associated
with a separate cost centre.
372 Enterprise Resource Planning

Fig. 24.19 Work Centres

MANAGING DIFFERENT PRODUCTION SCENARIOS

Production process varies widely across industries. For example, in automobile industry it is common to have
big assembly line having several work stations where processing is done to produce the finished product. For
a process industry like chemical or petrochemical, having continuous processing plants, the manufacturing
process can be very different. To support such different production scenarios, ERP solutions have come up
with specific capabilities. In this chapter we discuss three such scenarios for
Process industry
Industries adopting repetitive manufacturing
Industries using Kanban or just-in-time process

Process Industry
Oil and gas, petrochemical, chemical, pharmaceutical etc. are examples of process industry. Some of the
common enhancements in ERP solutions for process manufacturing are as follows:
Batch management: Batch management is widely used in process industry as each batch of the
same material can have different chemical properties. This is due to continuous variation in process
parameters during manufacturing. Batch is also used for material tracking. Sometimes customers also
are interested knowing the batch details of the items they procure.
Characteristics: Characteristics are different parameters to define a material. For example, a steel
rod can have its diameter, length and finish as three separate characteristics. Typically any chemical
composition can have several such characteristics on which values are measured.
 Production Planning and Execution 373

Fig. 24.20 Routing

Recipe: In process industry, bill of material is replaced by recipe.

Process instructions (PI) sheet: Any process industry uses a set of process control equipment in the
form of PLCs, shop floor systems. Data of these process parameters from the process control systems
need to flow to ERP system. PI sheets are used to exchange data between process control system and
ERP system. The PI sheet can display information that is required by the process operator to perform
the process. For example, processing instruction for process operator.

Repetitive Manufacturing
Repetitive manufacturing is typically used in industries where the product complexity is less and product
is stable as there is high rate of production and the same product is produced on a production line for a
long period of time. Consumer goods industry, electronics industry are few common examples of repetitive
manufacturing. Some of the common enhancements in ERP solutions for repetitive manufacturing are as
follows:
Production plans are created on the basis of period and quantity (rather than individual lots and or-
ders), i.e. there will be one production order for making one item throughout the whole day of 10000
pieces.
Back flushing: At the end of the shift or at the end of the day, backflush all the quantities produced
together. Instead of separately reporting production for individual finished goods, it does a production
374 Enterprise Resource Planning

reporting for all the finished goods produced during the day and also automatically report consumption
of all bill of material items (components and raw materials) i.e. their inventory gets reduced.
Specialised material staging: Typically in case of repetitive manufacturing, materials (raw materials
and components) need to be placed besides the assembly line. This needs specialised material staging
capabilities for ERP solutions.

Kanban Manufacturing
Kanban or Just-in-Time (JIT) based manufacturing had its origin in Automotive Industry. However today
it is used widely in other industries.
The basic principle of Kanban is that material is provided in production exactly when it is required. It
remain there as small material buffer in a container. Each container contains the quantity of material that
the work centre/machine operator need for a certain period of time (say for next one hour or say for a shift).
As soon as a container is emptied at the work centre (the demand source), replenishment is initiated from
the supply source (which may be a different work centre or an external supplier or a warehouse).
All leading ERPs these days support Kanban-based manufacturing. Some of the common enhancements
in ERP solutions for Kanban manufacturing are as follows:
Electronic Kanban card: The delivery of material can be triggered by demand source by sending
a Kanban card to supply source. Kanban card describes which material is required, in what quantity
and where these need to be delivered. ERPs support electronic Kanban card which can replace the
physical cards.
Kanban calculation: How much stock to be kept in the container beside the operator. Calculation of
this quantity is important and depends on variety of parameter like production rate, supply lead time
etc. ERP systems help in calculating such Kanban quantity.
Monitoring of Kanbans in circulation
ERPs supporting Kanban also need to support Kanban’s ‘Pull’ principle against ERP’s ‘Push’
principle.

Summary
Most of the ERPs had their origin in MRP and MRP II applications. MRP II has five major levels: Business
Plan, Sales and Operations Plan, Master Production Schedule, Material Requirement Planning, Purchasing
and Production Scheduling. Each of these planning levels has a different purpose, horizon and planning
frequency.
Sales and operations planning balances the sales plan of sales/marketing team with operation plan of a fac-
tory. Generally it is done at aggregated or product group level.
Master production schedule is the plan for finished goods as per the production strategy followed.
Material requirement planning plans for components and raw materials of finished goods.
Consumption based planning is generally done for B and C class items based on past consumption trend.
In this chapter MRP concepts like: planning horizon. low-level code, lot sizing, gross and net requirement,
time fence, etc. are discussed.
Capacity management in ERP is done at four levels, i.e. resource planning, rough cut capacity planning,
capacity requirement planning and capacity control.
Critical master data for production management are: Material, work centre, bill of material and routing.
Three different production management scenarios are also discussed in the book: Process industry, repetitive
manufacturing and Kanban.
 Production Planning and Execution 75

Exercise
I. Objective Type Questions
1. What is MRP II? What are its five elements?
2. What is SOP? What is its purpose?
3. What is MPS? What is its purpose?
4. What is MRP? What is its purpose?
5. What are the four primary inputs of SOP process?
6. What are the typical reviews done during SOP process?
7. What is the KPIs of SOP process?
8. What is MPS?
9. What are the typical inputs to MPS process?
10. How ATP is calculated?
11. What is CBP?
12. What is Planning horizon? Why is it important?
13. What is planning sequence? How is it related to low level code.
14. What is net requirement? How is it different from gross requirement?
15. What are the three common lot sizing procedures?
16. What is backward scheduling? How dates are calculated in MRP?
17. What is time fence? Why is it needed?
18. What are MRP exception messages?
19. What are the two main outputs of an MRP run?
20. What is bill of service?
21. Name few limitations of MRP?
22. What is closed loop MRP? What benefits does it provide over ERP?
23. Name four levels of ERP capacity planning
24. What is DRP?
25. What are the six inputs to DRP process?
26. What is LTP?
27. What planning run supports simulation?
28. What strategies ERP support for rescheduling orders?
29. What is forward scheduling?
30. What are the four important master data elements for ERP production planning?
31. What is batch management?
32. What is back flushing?
33. What is material staging?
34. What is electronic Kanban card?

II. Descriptive Type Questions

1. Explain five levels of MRP II. How these levels vary by purpose, planning horizon, level of detail and
planning frequency?
2. Explain sales and operations planning process. What are its inputs? SOP includes a set of review processes
– what are they? Explain some of the KPIs of SOP process.
3. What is master production scheduling? What are the inputs to the MPS process? Explain the concept of ATP.
4. Explain different MRP concepts.
376 Enterprise Resource Planning

5. What is consumption based planning? How this is different from MRP? For what type of items, CBP is
used and for which items MRP based planning is used?
6. How ERP planning sequence is determined by low level code? Explain with an example.
7. Explain lot sizing procedures. Why is it important for material planning? Explain the three popular lot siz-
ing procedures.
8. Explain the concept of backward scheduling and time fence.
9. What are the main limitations of ERP? Discuss each of them.
10. How ERP supports capacity planning at four levels? What is the major drawback of ERP-based capacity
planning?
11. Explain distribution requirement planning process? What are its objectives? What are the inputs to DRP
process?
12. What is long term-planning? What are its objectives? How does ERP support LTP process?
13. How do ERPs support MPS process?
14. How do ERPs support capacity management? What type of different strategies do ERP support for resched-
uling orders so that it can be accommodated within available capacity?
15. What are the master data elements of ERP production planning? Explain each of them.
16. Explain different characteristics of process industry and how does ERP support that.
17. Explain the characteristics of repetitive manufacturing and Kanban manufacturing

III. Fill in the Blanks

1. MRP stands for _______________ _____________ _______________.
2. CBP stands for _______________ _____________ _______________.
3. MRP II stands for _______________ _____________ _______________.
4. DRP stands for _______________ _____________ _______________.
5. LTP stands for _______________ _____________ _______________.
6. MPS stands for _______________ _____________ _______________.
7. JIT stands for _______________ _____________ _______________.
8. ATP stands for _______________ _____________ _______________.
9. SOP stands for _______________ _____________ _______________.
10. Lot for lot is a _______________ _____________ procedure.
11. MRP run creates ________ orders and __________ requisitions.
12. For service industries bill of material is replaced by bill of __________.
13. CRP is linked with __________.
14. LTP is a special type of _________ run.
15. Work centers are important for _______________ _____________, ________ and _________.
16. In process industry BOM is replaced by _____________.
17. Kanban supports __________ principle against ERP’s ________ principle.

IV. State Whether the following Statements are True or False

1. MRP planning sequence is determined by low level code.
2. MRP works based on gross requirement.
3. In “Lot for lot” lot sizing procedure a lot is always created for a fixed quantity.
4. Closed loop MRP does a reality check of MRP plan.
5. Rough cut capacity planning is linked with MRP.
6. Resource planning is linked with SOP.
7. Operation overlapping is a strategy to reschedule orders.
8. Backflushing is a characteristics of process industry.
9. PI sheet is a requirement for process industry.
 25
Supply Chain Planning
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Supply Chain Planning
History of evolution of supply chain planning software
Understanding the difference between strategic, tactical and operational planning
Difference of supply chain planning and supply chain execution
Difference between ERP and supply chain planning software
Supply chain planning software vendors and products
Supply Chain Planning Solutions – Modules
Network design
Demand planning
Supply chain planning
Detailed production planning and scheduling
Global available to promise
Transportation optimisation
Collaborative Planning Solutions
Vendor managed inventory (VMI)
Collaborative planning forecasting and replenishment (CPFR)

SUPPLY CHAIN PLANNING

History of Evaluation of Supply Chain Planning Software
As shown in Figure 25.1, Supply chain planning software had their history in MRP and MRP 2 applications.
MRP and MRP 2 are discussed in Chapter 24. Over the time MRP 2 got replaced by ERP which has more
advanced capabilities in planning.
While ERP remains the heart of the application portfolio for most of the leading companies, increas-
ingly companies prefer to do planning activities in a separate set of software called supply chain planning
applications or advanced planning and scheduling applications. The major advantages of these applications
378 Enterprise Resource Planning

Fig. 25.1 Supply Chain Planning Solutions have Evolved Over Time

are that they can do optimisation which traditional ERPs can not do (A detailed comparison of ERPs and
supply chain planning applications are detailed in this chapter).
Another area where supply chain applications are evolving, is the area of collaboration. Increasingly ERP
and supply chain software started supporting collaborative practices like vendor managed inventory (VMI)
or collaborative planning forecasting and replenishment (CPFR).

Understanding Difference Between Strategic, Tactical and Operational

Planning
Supply chain planning decisions can vary based on the frequency at which decisions are taken and their
criticality. Based on these parameters, decisions can be taken at strategic, tactical, operational or execution
level. Figure 25.2 shows supply chain planning decisions at different levels which are discussed below:
Strategic Decisions These are the most critical decisions for the company having very long term im-
plications for several decisions. The decisions like where to put the factory, where the warehouse should be
located, whether to look for global sources for procurement, etc. fall in this category. Once these decisions
are taken, it is difficult to come back and even if the company changes its mind later, there is substantial
cost for this change. These decisions also influence company’s long term profit and sales goal. Network
design, long-term planning, etc. are decisions of this category.
Tactical Decisions These are medium-term decisions generally reviewed every month. Sales and opera-
tions planning, master production schedule, material requirement planning, etc. fall in this category.
 Supply Chain Planning 379

Fig. 25.2 Differemt Plannning Horizon Needs Separate Supply Chain Planning Tools

Operational Decisions These are short-term decisions generally reviewed every week. Vendor schedule,
distribution plan, transportation and route plan, etc. fall in this category.
Figure 25.3 shows that the strategic decisions have maximum ROI impact, followed by tactical, and
operational or execution level decisions.

Fig. 25.3 Strategic Supply Chain Decisions have Maximum Impact on ROI

Difference Between Supply Chain Planning and Execution

Supply chain management comprises of both supply chain planning and execution. It is important to un-
derstand their difference.
380 Enterprise Resource Planning

Supply chain planning applications mainly help in the areas of production planning, material requirement
planning, distribution planning, transportation planning, capacity planning, network design, etc. These plan-
ning activities can be either done in ERP or supply chain planning software.
Supply chain execution applications mainly support all transactions related to materials management,
inventory management, order management, warehousing, transportation, etc. These processes are always
done in ERP systems only and supply chain planning software does not help in these areas.

Table 25.1 Difference between Supply Chain Planning and Execution

Supply Chain Planning Supply Chain Execution

Typical processes sup- ** Network design ** Inventory management
ported ** Demand planning ** Procurement
** Supply planning ** Vendor management
** Material planning ** Warehousing
** Sales and operations planning ** Sales order management
** Safety stock planning ** Production order management
** Inventory planning ** Shipping
** Production planning ** Transport execution
** Detailed scheduling ** Quality management
** Distribution planning
** Transportation planning
** Vehicle scheduling
** Route planning
Applications ERP, supply chain planning solutions ERP
Vendor solutions Supply chain planning solutions (SAP APO, SAP ERP, Oracle ERP
i2 Technologies, Oracle APS), ERPs (SAP,
Oracle)

In this chapter the focus will be on supply chain planning applications.

Difference between ERP and Supply Chain Planning Software

While ERP can support basic planning activities, increasingly supply chain software are getting popular for
planning. The difference between the two is shown in Table 25.2. The areas where supply chain software
score better than ERP are its optimisation capabilities, capabilities of handling prioritisation and constraints,
better forecasting (order promising) and simulation.

Table 25.2 Difference between ERP and Supply Chain Planning

ERP Supply Chain Planning

Focus Transaction and basic planning Advanced planning and optimisation
Planning Order Sequential planning of material and capacity Simultaneous planning of material and capacity
(Contd)
 Supply Chain Planning

(Contd)

Prioritisation Can not handle any prioritisation rule Can handle any prioritisation rules (Customer,
Handling product, etc.)
Simulation Have very limited simulation capability Have extensive simulation capability
Constraints Cannot do any constraint-based planning Can do constraint-based planning
planning
Capacity Plan based on infinite capacity Can plan based on finite capacity i.e. available
management capacity
Forecasting Have basic forecasting capability Have advanced forecasting capability (More sta-
tistical forecast algorithms, causal models, etc.)
Replanning Replanning takes long time Replanning can be very fast
Available to Limited order promising capability Advanced order promising capability in terms of
promise alternate location or alternate product

The main issue with ERP-based planning is its infinite planning approach, i.e. it gives a plan not look-
ing at capacity and hence can be infeasible to execute. The supply chain solutions look at capacity and can
provide an optimised plan looking at customer and product priorities and suggest that which orders the
company should execute and which ones need to be deferred or not to be done at all in case of a capacity
shortage. In case of ERP, once the first cut plan is obtained from ERP system, the planner need to use his
best intelligence to do this activity. ERP plans also become infeasible at times as it does not look at supply
chain constraints or constraints at the factory shop floor.
The second major issue with ERP planning is that it takes long time to replan, i.e. if there is a change
in customer order, it needs a new MPS, a new MRP run, etc. to come up with the new plan. Replanning
is the reality in business as every day new priority customer order come (companies need to change their
shop floor production priority to make urgent delivery), orders get rescheduled or cancelled. Supply chain
software can help in quick replanning.
Another issue with ERP planning is sequential planning approach, i.e. first distribution plan is done,
and then production plan follows. Within production plan again first material planning is done followed
by capacity planning. The problem with this approach is that by the time material planning is completed
and capacity planning starts, the stock situation changes and the material plan the company have in hand
becomes an old one. Typically a typical ERP planning cycle can take 2-3 days that means the company is
always working on an old data. In comparison, supply chain solutions do capacity and production planning
simultaneously so there is no planning delay and the company is always working with most recent data.
It is important to remember that the basic purpose for which most companies use ERP is supporting all
back office transactions, whereas in case of supply chain software, it is planning and optimisation.

Supply Chain Planning Software—Vendors and Products

Supply chain planning market is crowded today with lot of vendors like
i2 Technologies
SAP (SAP advanced planner and optimiser solution—APO)
Oracle (Oracle advanced planning and scheduling solutions – APS)
Manugistics
Adexa
Demantra
Logility
382 Enterprise Resource Planning

JDA
Aspentech
IFS
i2 was the market leader in this space for long time. However currently SAP APO has taken over i2 as the
market leader. Some of the vendors concentrate on particular industries like Aspentech is very strong in
process industry while JDA is strong in retail.
Figure 25.4 and Figure 25.5 show the supply chain products for two leading supply chain vendors i2 and
SAP (SAP APO)

Fig. 25.4 Supply Chain Product Suite

Fig. 25.5 SAP APO Supply Chain Product Suite

 Supply Chain Planning 383

SUPPLY CHAIN PLANNING SOLUTION—MODULES

Typical modules of supply chain planning are:
Network design
Demand planning
Supply network planning
Production planning
Detailed scheduling
Transportation planning
Vehicle scheduling
Route planning
These modules are discussed now.

Network Design
Designing the supply chain network, i.e. locating the factories, warehouses and distribution centres in most
optimal location that reduces overall supply chain cost and provide needed customer service is a challenge
for all companies. This is of strategic importance for company’s long-term success and is critical as these
decisions can not be changed at short notice due to huge cost involved. However, fast changing market
demand and short product life cycles forces today’s enterprise to continuously evaluate and optimise its
supply chain. Network design decisions typically involve things like:
Where new locations (plants, warehouses, DCs, and stores) shall be opened?
Which locations shall be closed?
Which products shall be produced at which locations?
Which customers should be assigned to which distribution centres?
What are capacity requirements for plants/distribution centres?
Network design software helps in such decisions. There can be various scenarios when a company may
need a solution for network design for example:
If a company wants to expand its activities to another country, the company can define various scenarios
which then can be evaluated using network design solutions. Market opportunities, market demand
and sales quantities can be simulated dynamically and the model includes all relevant costs for such
location. Network Design solutions can help in determining the cost-optimal number of new locations
in the selected country.
Another scenario for using network design can be a change in product demand. As demands change
over the time, locations might become unprofitable. Network design allows the user to identify locations
which are not cost-optimal and should be closed. In addition, the optimiser might give alternatives for
the opening of new locations, enabling the planner to react to demand changes.
When planning the introduction of a new product, a planner can use network design to determine where
to produce and how to distribute the product. He can decide if new plants and/or distribution centres
are needed, or if existing capacities are sufficient. Different anticipated demands can be simulated to
picture all kinds of possible demand scenarios.
Network design also allows simple supply chain network analysis to determine if a redesign of the
supply chain is necessary, i.e. cost-effectiveness of the supply chain using data from ERP systems.
While deciding the most optimum location, the optimiser in network design software can consider a variety
of cost elements like transportation costs, production costs, storage costs, handling costs, procurement costs,
penalty costs for delayed or non-fulfilled demands, etc. It also considers all location related costs like fixed
operating costs, costs for opening and closure of locations, any government subsidies for the location, etc.
384 Enterprise Resource Planning

Cost is an important parameter for network design solutions as this helps in optimal assignment of locations
to locations, products to locations or production processes to locations.
Some of the network design software can be integrated with GIS application for automatic calculation of
transportation duration and transportation costs. This software helps in giving initial proposals for opening
or closure of locations and these proposals need to be commercially validated before taking any final deci-
sion. It is important to understand that a network which is optimal for service may not be optimal for cost
and this need to be decided that what is of top priority before network design exercise starts. Figure 25.6
gives such an example.

Fig. 25.6 Which Network is Optimal–Making Tradeoff between Service and Cost

Network Design Vendors Leading vendors in this space are:

ILOG Logic Tools
i2 Supply Chain Strategist

Demand Planning
Demand planning tools helps in forecasting future demands. These tools help better forecasting in several
ways for example:
Forecasting at different planning levels: Forecasting for example at specific customer level, regional
level, country level or at individual product or product group level
Consistent planning: While planning can be done at any level, the data can be aggregated (drill up)
or disaggregated (drill down) at other levels. For example, after doing forecasting at individual city
level, the same can be aggregated to region or country level. In the same way after doing forecasting
at product group level, data can be disaggregated to individual product level. Thus, planning data on all
planning levels can be kept consistent (automatic aggregation and disaggregation). Consistent planning
is divided into top down, middle out and bottom up planning. In top down planning, an aggregated
plan is automatically distributed down to detailed level (products, customers, sales areas, and so on)
 Supply Chain Planning 5

according to proportional factors. In middle out planning, mid-level planning data is summarised up
for the overall plan and distributed down to the detailed level. In bottom up planning, detailed data is
automatically summarised up to the overall plan.
Forecasting for quantity or value: Generally demand planning tools can do forecasting for quantity
or value for example, projected sales value in euros or projected sales quantity in pieces.
Data visibility as per planning need: Data can be also viewed in different time buckets like weeks,
months, quarters or years. For example, for very recent future period, say for next two to four weeks,
people may like to see data in weeks, while for medium future term, say for next quarter, people may
like to data in months and for longer future terms, say for next year, a visibility quarter wise may be
fine.
Statistical Forecasting Capability: The main strength of demand planning tools are that they support
a wide variety of univariate statistical forecasting models (based on company’s past sales data) like
constant, trend, seasonal, trend and seasonal, exponential smoothing, linear regression, etc. Figure 25.7
shows different forecasting models.

Fig. 25.7 Different Forecasting Models

386 Enterprise Resource Planning

Forecasting based on number of parameters: Beyond past sales, demand planning tools also sup-
port forecasting based on number of other parameters like: competitor’s sales, industry growth rate,
advertisement expenditure, sales promotion, etc. These models based on a number of causal factors
are called causal models or multi-linear regression models.
Consensus Forecasting: Demand planning tools also support forecasting by different approaches (say,
forecasting by a trend forecasting method, a seasonal method and a causal method) and combining their
results (say 25% weightage to first method, 50% weightage to second method and 25% weightage to
the third) to get a final forecast. This method of forecasting is known as consensus forecasting.
Collaborative Forecasting: In today’s world, a company can not alone decide their future demand
and is influenced by demand figures from their key customers. Collaborative forecasting is a method
where the company collaborates with its key customers to decide forecast for the future. Today internet
and other technologies like portal made such collaboration simple and leading demand planning tools
support such collaboration.
Planning for promotion: Sales promotion is common in certain industries like consumer goods, retail,
etc. Demand planning tools support promotion planning and such occasional uplifts.
Planning for new products: Forecasting demand for new products is always a challenge. Demand
planning tools uses an approach called “Like modeling” to forecast demand of new products using
historical data from similar old products. This provides some baseline for planning for new products
and the forecast can be refined over the time when actual sales data for the product is gathered. This
is also called phase in planning.
Planning for Discontinuation/Phase out: Demand planning tools also support gradual discontinuation
of an existing product. This is also called phase out planning.
Macros: All leading demand planning tools support macros which help in performing complex cal-
culations, to define conditions and exception messages/alerts. Based on alerts E-mails can be sent
automatically to relevant people. For example we can write a macro to calculate forecast error (Forecast
error = <Forecast – Actual sales>/Forecast) and another macro to define that if forecast error is more
than 20% in last month, it should automatically send an e-mail to the marketing manager. Macros are
a very commonly used tool in demand planning software.
Demand Planning Tools Leading ERPs all support some preliminary demand planning capabilities.
For example, demand planning is supported in SAP ECC flexible planning module. Oracle ERP also sup-
ports some demand planning capabilities.
However, supply chain planning solutions have much advanced demand planning capabilities. Tools
like SAP APO demand planning, i2 demand planning, Oracle APS demand planning, Manugistics demand
management, Adexa demand planning, etc. fall in this category. SAP APO Demand Planning and i2 Demand
planner are leaders in this category. There are also lots of specialised demand planning software who are
nitch and specialised vendors.
Some common differences between demand planning capability of an ERP tool and that of an SCM
planning tool are given in Table 25.3.
 Supply Chain Planning 387

Table 25.3 Demand Planning Capability Comparison in ERP and Supply Chain Tool

Demand Planning in ERP Tool Demand Planning in Supply Chain Planning Tool
Some simple statistical forecasting tools Supports extensive statistical forecasting capability with support
for large number of forecasting tools
Does not support causal/multi-variate models Supports causal/multi-variate models
Does not support like modelling Supports like modelling
Does not support advanced promotion planning Supports advanced promotion planning
Does not support collaborative forecasting Supports collaborative forecasting
Provide very little exception handling capability Have capabilities of writing advanced macros, alerts and auto-
mated e-mail for exception handling
Basic drilldown capability Better drilldown and graphical capability
Data for forecasting is not stored in data warehouse Historical data for forecasting is stored in data warehouse – hence
(for example, in case of SAP ERP data is stored in can store much larger size of data with better performance.
LIS based info structures.)

Several companies had implemented supply chain-based demand planning tools to improve forecasting ac-
curacy and to ensure that the entire company works on one number philosophy. Everything downstream, i.e.
production planning, material planning and distribution planning is driven by this one consensus demand
number (i.e. production planner’s or material manager’s estimate of demand is not different from that of
sales team).

Supply Network Planning (SNP)/Supply Chain Planning (SCP)

SNP or SCP tools of APS solution helps in distribution, production and material planning of the entire supply
network. These tools are advanced version of DRP (distribution requirement planning) and MRP (material
requirement planning) functionalities of traditional ERP solutions. SNP/SCP solution creates a rough-cut
quantity-based cross-location production and distribution plan that considers resource capacities, i.e. without
overloading any of the resources. APO supply network planning and i2 supply chain planners are leading
tools in this category. So, typical features of these tools are:
Feasible plan considering constraints: SNP/SCP tools help in creating constrained and feasible pro-
duction and distribution plans. This is a major difference between production and capacity planning
in ERP tools and that of APS tools. APS tools take capacities (production capacity, handling capacity,
storage capacity, transportation capacity, etc.) and constraints (like material availability constraint) of
the supply network in consideration while planning and thus gives a feasible production or material
plan which ERP software can not do. ERPs do planning based on the assumption of infinite capac-
ity, i.e. based on the customer requirements ERP solutions can tell how much production capacity is
required or how much materials need to be procured, i.e. how much vendor capacity is required. It
can not plan based on available capacities, i.e. to guide which products need to be produced or which
customer orders need to be fulfilled in case a company has limited capacity.
Medium-term planning with day bucket: These tools are used for medium-term planning process.
Generally the lowest planning buckets for these tools are days, i.e. it will not do a detailed schedule
within a day, i.e. which machine should run between 2 and 4 P.M. or which products need to be pro-
duced between say morning 10 A.M. – 12 A.M. In the same way unlike demand planning tools, SCP
388 Enterprise Resource Planning

tools also do not plan for very long term say in yearly bucket. Typical planning horizons for these
tools are weeks or months and planning bucket is days, i.e. it gives a daily production, material or
distribution plan for say next 8 weeks or for next three months.
Critical component planning: Typically SNP/SCP tools are used for material planning of critical
components (may be these items have long lead time) or capacity planning of bottleneck resources.
Planning for non-critical materials or resources is still done in ERP.
Prioritisation: SNP/SCP tools can handle prioritisation of customer orders or products. This is some-
thing not possible in ERP. In case there is a material shortage or capacity constraint, the system creates
production or procurement plan for the items/customer orders which are of higher priority and after
that the system allocate capacity or material to other customer orders. Priority can be defined for most
profitable products or most profitable products. These tools works on a principle of penalty cost to
model priorities i.e. non fulfillment of a customer order/product of higher priority has higher penalty
cost. The system works on a principle of reducing total cost while planning and thus, try to first fulfil
these orders as non-fulfilment of these orders increases total overall cost of the plan.
Simultaneous planning: Another difference of ERP-based planning with that of APS-based planning
is that ERP tools always plan sequentially, i.e. first finished goods requirements are planned, then their
production is planned and finally material planning is done. However, in reality this is a problem as
if it takes first 2 days of a week to finalise the sales plan, then another 2 days for production plan and
then 2 days for material planning and by the time production planning is complete, there is already
4 days delay and so, material plan is based on 4-days old sales plan. However, within these 4 days,
there may be additional sales orders or stock situations may change. Thus, ERP-based planning is
always not based on most current data as this is a sequential planning approach. On the other hand,
APS solutions can plan distribution, production and material plan simultaneously, i.e. all are done at
the same time and so, there is no time delay and the planning is always based on most recent data.
Simulation: APS solutions have strong capabilities in simulation and what-if scenario building. This
helps in evaluating lot of alternate plans. For example, a planner can simulate that if his some criti-
cal materials are not delivered by a vendor on a particular date or one of his critical machines breaks
down on a particular day, which orders will suffer and what should be his alternate plan. He should
also evaluate scenarios like whether it makes sense to hold a stock in inventory or to give 10% more
discount and get rid of it, and whether cost of carrying this inventory is more or less than his discount
cost.
Collaborative planning: SNP/SCP tools also support different collaborative planning scenarios over
the internet like vendor managed inventory (VMI) scenario.
Detailed distribution planning and transport load building: Once the materials are produced in
factory, SNP/SCP tools helps in building a detailed distribution plan to different warehouses or distribu-
tion centres based on their requirement and a variety of rules. This process is also called deployment.
As every company wants to ensure that transport vehicles are fully utilised (to save on transportation
cost) while goods move, SNP/SCP tools helps in building full truck loads while transporting goods.
Most of APS tools take transport load building as part of distribution planning so that the distribution
plan always suggest something which is in full truck load. To do this it can pull demand from future
horizon or can follow variety of other logics to make full truck load.
Different planning approaches: SNP/SCP tools can use different planning tools like simple Heuris-
tics based planning or complex optimisation algorithms to create a cross-location, feasible production
and material plan taking demand constraints and penalty costs into account. This result in optimised
purchasing, production and distribution decisions, reduced stock levels, and improved delivery reli-
ability.
 Supply Chain Planning 389

Production Planning/Factory Planning/Detailed Scheduling

Once the gross level production and material plans are created in supply network planning or supply chain
planning tools, this plan is sent to factory planning and scheduling tools to create an up to the minute
detailed plan machine-wise taking different factory capacities and constraints in consideration. While the
lowest planning bucket for SNP/SCP tools is a day, factory planning and scheduling tools can plan up to the
minute and this helps in creating a detailed shift-wise plan for each machine, the start and end time of each
operation and a more detailed material requirement planning. Generally horizon for production scheduling
or factory planning is shorter (say, may be in days or weeks) than the overall supply chain plan (which may
be in weeks or months). Some of the useful functionalities of these tools are:
Up to the minute production schedule and material requirement planning
Simultaneous quantity and capacity requirement planning
Multi-level material and capacity availability check capability
Optimisation capability for set up optimisation and sequence optimisation. These tools can compare
cost/time for different set up options and can recommend optimum set up and optimum sequence in
which production need to run. For example, if there are three products A, B and C that need to run
on the same assembly line and there are several possible combinations like AABBCC, AAABCC or
ABBCCC – the tool may suggest that AAABCC is the most optimum sequence considering minimum
set up time and cost requirement.
Automatic replanning in case there is any change in requirement, say change in sales order. Replan-
ning is very first
Simulation and what-if capability
Can create automatic exception messages
The main difference of planning at this level is that planning is at much detailed level considering ev-
eryday factory constraints (like machine breakdown or delay in supply from a particular supplier or change
in customer order) and detailed up to the minute with specific start and end times for each operation. Like
SNP, these tools are also used typically for planning critical products or bottleneck resources. SAP APO
production planning, detailed scheduling and i2 factory planner are leading tools in this category. By optimis-
ing order sequences, these tools help in reducing lead times, stocks and at the same time improve on-time
delivery performance.
Factory planning and scheduling tools support different approaches for planning and scheduling like
Heuristics-based planning, optimisation algorithms or bottleneck scheduling.
While planning and scheduling are done in such tools (for creating optimum planned production orders
or optimum purchase quantities in the form of purchase requisitions), scheduling orders are sent back to the
ERP system for final execution (i.e. purchase requisitions are converted to purchase orders and are placed
on vendors. Planned orders are converted to production orders and released to the shop floor).

Global Available to Promise (GATP)

An Available-to-Promise (ATP) check is an online search to verify the company’s ability to provide the
requested product, in the requested quantity, and on the date requested by the customer. In ERP systems,
ATP functionality is limited and an ATP check search local inventories only for available products. Supply
chain solutions provide much advanced capabilities in this area. Some of the important capabilities are as
follows:
Alternate products: In case the particular product the customer is looking for is not available, an
alternate providing similar functionality can be offered. GATP solutions allow business to model such
alternates and provide opportunity for up selling and cross selling.
390 Enterprise Resource Planning

Alternate location: GATP solutions can search a product across the entire supply chain network for
availability. For example, the customer is looking for product A and this is not available in the nearest
warehouse/distribution centre of the customer, the search can be extended to all the alternate ware-
houses/distribution centres and if the product is still not available there, the search can be extended to
factory. If the full quantity is not available in one location, GATP can suggest partial sourcing from
number of locations to meet the customer demand.
Multi-site multi-product availability check: In the earlier example, in case product A is not available
in any location, alternate product B can be offered and the search will progress in the same order first in
nearest location, then in alternate location and then in the factory where product B is manufactured.
Multi-level component and capacity check (capable to promise): If the finished product and its
alternate (alternate should be acceptable to customer) is not available in any of the locations, GATP
solutions can make an order promise looking at the future production plan. Thus, GATP is integrated
with production planning and consider capacity constraints. This capability is also known as capable
to promise (CTP).
Rule-based availability check: Users can define complex rules while doing availability check. For
example, a rule can be “Alternate locations search is allowed till the time the transport cost does not
exceed X dollar”. There is no point in offering a product to customer, if the transport cost eats away
the total margin.
Calendars: ATP checks take into account distribution centre calendar or factory calendar (to account
for holidays, etc.) while making promise.
Transportation Optimisation
Transport cost is a significant portion of logistics cost and for certain type of products (like commodity
products such as metal, minerals and fresh food items), this is a substantial percentage of the finished
product cost. While ERP solutions mainly helps in transport related transactions (like freight payment or
transport documentation), supply chain solutions helps in better transportation planning and optimisation
so that transport costs can be reduced. Table 25.4 shows a list of areas where supply chain transportation
solutions can bring benefits.

Table 25.4 Transportation Planning and Optimisation Areas

Technology used Business need What it does

Transport planning Better planning of vehicles These applications help in better planning of vehicles, i.e. when
and vehicle schedul- so that minimum number of what size vehicle needs to be ordered looking at the daily ship-
ing vehicles are used ment plan, service level required and vehicle capacity.
Route optimisation Building optimum route so These applications help in building optimum route keeping
that vehicle travel minimum multiple drop points in mind and ensuring that the truck travels
distance minimum route while dropping at all the points. Special con-
straints can be built like the total transit time should not cross
more than 8 hours for perishable items like milk, which need
to reach processing centre within specified number of hours of
collection.
Optimum truck load Building optimum load These applications help in building optimum load for the truck,
building so that vehicles never runs keeping truck’s space and load carrying capacity in mind. Load
empty can be built, keeping the drop sequence in mind and properties
of materials (i.e. light materials should not be below heavy
material).
 Supply Chain Planning 91

Figure 25.8 shows how a transportation optimisation solution needs to consider a variety of factors while
doing optimisation.

Fig. 25.8 Transport Constraints

COLLABORATIVE PLANNING SOLUTIONS

While planning and optimisation of supply chain within the own enterprise is the priority of every enterprise,
companies are increasingly talking about optimising the entire value chain. As we know supply chain of a
company is composed not only of its own factories and distribution centres, but also includes its customers
and suppliers and the strength of this chain is always determined by the strength of the weakest link. Higher
collaboration among supply chain partners is one proven approach for value chain optimisation. There are
several areas where supply chain collaboration can bring benefits:
Collaborative forecasting: It is important that while forecasting demands for future, inputs from key
customers are taken. A company manufacturing tyres will be better off if they know that the future
production plan of the car company where they supply their tyres instead of totally relying on their
own historical data of demand.
Collaborative replenishment: This is another area where collaboration had shown significant benefits,
especially in certain industries like retail. There are very successful collaborative replenishment model
like vendor managed inventory (VMI – discussed later in this chapter) where replenishment decision
392 Enterprise Resource Planning

to the retailer by consumer good company is based on point of sales data of last day or last week and
not based on forecast.
Collaborative product development: Developing product together with inputs from suppliers is
another area where collaboration can help. For a car company coming up with a new model of car,
the company needs to collaborate with hundreds of suppliers who design individual components. It is
important that the company and its suppliers interact with real time so that the company can guide the
vendors on the design, vendors can give their inputs and if there is a change everyone can evaluate
its effect on other parts at the same time.
Figure 25.9 explains the history of evolution of collaboration solutions. The collaboration technology
had its origin in simple portal solutions where the company used to communicate with its suppliers about
the next delivery schedule, status of last materials received from the vendor (accepted/rejected) or vendor’s
payment status. Vendors are also allowed to communicate in a limited way i.e. through portal. For example,
they can inform the company the revised delivery schedule, etc. Portals can be accessed over internet.
However, the portal is not the real time collaboration in true sense. Vendor managed inventory (VMI) and
collaborative forecasting are next level of collaboration adopted by several companies for collaborating on
replenishment schedules and future forecast. Highest level of collaboration is collaborative planning and
forecasting (CPFR) which has nine defined steps. CPFR is also discussed in this chapter. Figure 25.9 explains
the trust requirement among supply chain partners that increases as we move from portal to CPFR kind of
collaborative arrangement.

Fig. 25.9 Evolution of Collaboration Models

Vendor Managed Inventory (VMI)

Vendor managed inventory is a process where the supplier, i.e. manufacturer/distributor makes inventory
replenishment decisions for customer. Vendor monitors the buyer’s inventory levels and makes replenishment
decisions, i.e. which items to send, how much quantity and on what date. For supplier to plan the customer
 Supply Chain Planning 393

sends demand and inventory information on a pre-arranged schedule typically daily. The APICS Diction-
ary defines vendor managed inventory as “A means of optimising supply chain performance in which the
supplier has access to the customer’s inventory data and is responsible for maintaining the inventory level
required by the customer.”
VMI was popularised in the late 1980s by Wal-Mart and Procter & Gamble (P&G) and later on by
Campbell soup and Johnson & Johnson. The success of P&G’s programme with Wal-Mart helped VMI to
become a globally accepted replenishment practice. P&G started managing diaper inventory for Wal-Mart
long back. Frito Lay’s drivers/sales persons stock the shelves for their small retail customers to keep the
shelves full, the product fresh and the paperwork simple.
VMI Process In VMI, the customer does not generate a purchase order, instead supplier drive replenish-
ment of products and creates the order. Customer sends inventory, daily sales data (In case of retail industry,
this can be POS data) and promotion information to supplier via EDI message. Based on these three infor-
mation from customer (sales, inventory and promotion), supplier generates order on behalf of the customer.
Once the order is generated, that is taken up by supplier’s fulfillment system for order processing. Supplier
sends invoices to customer. Payment is made with an electronic fund transfer from the customer’s bank.
Figure 25.10 explains the process of VMI how it is handled in supply chain solution.

Fig. 25.10 Vendor Managed Inventory

394 Enterprise Resource Planning

EDI is commonly used in VMI, but it is not essential. There are companies like Frito-Lay which used
VMI long before EDI as a technology matured. However, electronic data transfer increases the speed and
accuracy of transaction. Bar coding is another technology which helps VMI by facilitating material receipt
and issue at distribution centres. It is important to understand that identifying right vendors to start VMI
programme is extremely important as once a VMI programme is established and time and effort are put on
building an EDI interface, it binds customers and suppliers and the customers will no longer be interested
to change the suppliers. That is why VMI system requires high level of trust between partners to operate
and succeed.
Advantages of VMI
1. Eliminating Bullwhip effect: VMI reduces the variability of order in the supply chain. Variability
is introduced in the supply chain due to lot size and batching at every node. Studies has shown that
when the end customer experiences 10% variation in actual customer demand, distribution centre may
experience 30% variation and the supplier can see a variation up to 50%. This is called Bullwhip ef-
fect. Figure 25.11 explains the concept of Bullwhip effect, i.e. how a little change at the retailer’s end
can cause a huge variation for the manufacturer. With VMI, exact demand based on daily or weekly
sales is communicated upstream, i.e. from end customer to warehouse to supplier, all these upstream
entities does not take independent decision to change these quantities to add their own buffer and

Fig. 25.11 The Bullwhip Effect

 Supply Chain Planning 5

to take care of lot sizing, etc. Quantity reached to the final supplier is the exact sales figures at end
customer level and this substantially reduces fluctuations along the chain.
2. Uniform production for the supplier: When a critical mass of supplier’s business is operating under
VMI conditions, reduced shipment variations will lead to less peaks and troughs in production result-
ing in better productivity.
3. Lower administration cost: Administration cost reduces as customer spends no time in ordering and
there is no paper work. Many VMI programmes have significantly reduced or eliminated invoicing for
individual replenishments by providing summary billing at periodic intervals—typically monthly—sav-
ing administrative labour for both buyer and supplier.
4. Lower transportation costs: VMI eliminates less than truckload (LTL) shipments. This is achieved
by allowing the supplier to coordinate the re-supply process instead of responding automatically to
order as they received.
5. Lower inventories: Supplier takes on the responsibility of product availability so the customer need
not maintain safety stock.
6. Increased sales and service: Lower out of stock as inventory of right quantity is in right location and
this increases sales and improves customer service.
7. Suppliers know real market demand information: VMI helps in knowing the real product demand
in market. Without VMI, a supplier to a retail store will do production based on distribution centre
orders which is not a real representation of market demand.
Cautions about VMI
1. VMI performs best in a stable pricing environment and not suitable for promotions: Promotions
can disrupt regular flow of product because suddenly high volumes of materials are required for very
short period. Promotions volume need to be synchronised with the planning of routine deliveries. A
poor promotional forecast can disrupt regular VMI order and delivery patterns.
2. VMI requires critical mass: A critical mass of supplier’s business need to be on VMI. If only very
few customers are on VMI, it does not help suppliers in terms of stabilising market demand or getting
real demand information from the market.

Collaborative Planning Forecasting and Replenishment (CPFR)

History of CPFR
Collaborative planning, forecasting and replenishment (CPFR) started as a vision for some of the large re-
tailers like Wal-Mart in 1990s who found the biggest problem of supply chain is that the company and their
supplier do not work with the same forecast numbers and execute replenishment using this. Collaboration
between company and supplier is key for effective forecasting and replenishment planning.
CPFR as an industry standard is sponsored by VICS (Voluntary Intra Industry Commerce Standards) as
well as adopted by Global commerce initiatives GCI. In addition, the UCC (Uniform Code Council) is now
funding the VICS CPFR working group. Although CPFR was originally started by retail/CPG industry, other
industries such as transportation, healthcare, automotive, etc. joined such collaboration programme. Success
of CPFR rollouts at Wal-Mart caused Target, Sears, Kimberly Clark, Procter and Gamble, Sainsbury’s, Tesco
asked their trading partners to join CPFR programme with them.
Using CPFR, customers and suppliers submit their own individual forecasts, then both forecasts evolve
into one shared agreed upon forecast. The joint forecast is created through sharing sales data, existing in-
ventory, and stock out information, promotions and supplier production constraints. CPFR is not restricted
to only collaborative forecasting and replenishment and can extend to areas like: Collaborative product
development, transportation, store design and shared logistics strategies.
396 Enterprise Resource Planning

CPFR: Nine Steps

VICS had developed a 9-step approach for CPFR starting from collaboration arrangement to performance
assessment. Figure 25.12 shows these nine steps. These steps are as follows:
1. Develop collaboration agreement
2. Create joint business plan
3. Create sales forecast
4. Identify exceptions to sales forecast
5. Resolve exception to sales forecast
6. Create order forecast
7. Identify exceptions to order forecast
8. Resolve exception to order forecast
9. Generate order

Fig. 25.12 The Nine Steps of CPFR

While the detailed discussion of these nine steps is beyond the scope of this book, collaborative planning
and forecasting is the highest level of collaboration initiatives between trading partners.
Leading technology companies like SAP, Oracle, JDA, i2, etc. developed CPFR software solutions and
got it certified in accordance with VICS standards.

Summary
Supply chain planning applications had their origin in MRP and MRP 2 applications, which later matured to
ERP and finally to advanced planning and scheduling (APS) applications.
Supply chain planning applications can be divided into strategic, tactical and operational levels with long-
term, mid-term and short-term horizons.
While APS applications helps in supply chain planning, ERP solutions help in supply chain execution.
i2 and SAP APO are two leading supply chain planning vendors.
Network design solution helps in deciding the most optimum network, i.e. where factories, warehouses and
distribution centres of a company should ideally be located.
Demand planning applications helps in creating a better forecast with the help of statistical forecasting tools,
consensus and collaborative planning methods.
Supply chain planning solutions help in optimised distribution, production and material plan for a com-
pany.
 Supply Chain Planning 397

Production scheduling applications helps in the most optimised schedule at factory shop floor.
Global available to promise applications helps in better order promising using alternate product, alternate
location or capable to promise capability.
Transportation optimisation applications help in route optimisation, truck load building and vehicle schedul-
ing.
Vendor Managed Inventory (VMI) where a supplier manages the inventory for the company is a leading
collaborative solution supported by APS solutions. Some of the leading APS solutions also support CPFR.

Exercise
I. Objective Type Questions
1. What is strategic supply chain planning? What kinds of decisions are taken here? What is the horizon of
this kind of planning?
2. What is tactical supply chain planning? What kinds of decisions are taken here? What is the horizon of this
kind of planning?
3. What is operational supply chain planning? What kinds of decisions are taken here? What is the horizon
of this kind of planning?
4. What is the difference between supply chain planning and execution?
5. How the focus of ERP software is different from that of supply chain?
6. Who are the leading vendors in supply chain software market? Who are the leaders in this space?
7. What are the typical modules of a supply chain planning software?
8. What is network design?
9. Who are the leading network design software vendors?
10. What is consensus forecasting?
11. What is meant by consistent planning?
12. What do you mean by supply network planning?
13. What is demand prioritisation? How do supply chain planning tools help in demand prioritisation?
14. What is simultaneous planning?
15. What is sequence optimisation? How do supply chain planning tools help in this?
16. What is global available to promise capability?
17. What is rule based availability check?
18. What is route optimisation?
19. What is truck load building?
20. What is collaborative planning? What are the three common areas of collaborative planning?

II. Descriptive Type Questions

1. Discuss the evolution of supply chain planning software. How did it evolve over the time?
2. What is strategic, tactical and operational planning? Give examples of each. How do they differ by criticality
and time horizon?
3. Discuss the difference between supply chain planning and execution. What are the types of processes in-
cluded in each?
4. Explain the difference between ERP and supply chain planning software.
5. What is network design?
6. What types of decisions are typically taken during network design? Under what conditions companies typi-
cally look for a network design solution? How do network design solutions identify optimum locations?
398 Enterprise Resource Planning

7. How do demand planning tools help in better planning? What are the difference between demand planning
capabilities of supply chain planning tool and that of ERP? Who are the leading demand planning software
vendors?
8. What are the typical capabilities of supply chain planning tool? How these tools help in demand prioritisa-
tion, simulation and simultaneous planning? How do these tools help in planning critical components?
9. Explain the capabilities of production planning and detailed scheduling of supply chain tools.
10. What are the capabilities of GATP module of supply chain planning software? How do different capabilities
of GATP help in better order promise?
11. What are the different capabilities of transportation planning and optimisation tool? What are the different
business problems they try to solve and how?
12. Explain collaborative forecasting, collaborative product development and collaborative replenishment. How
did collaborative solutions evolve over the time?
13. What is VMI? Explain the VMI process. What are the advantages and disadvantages of VMI?
14. What is CPFR? How CPFR was evolved? Explain the nine steps of CPFR process.

III. Fill in the Blanks

1. Network design is a supply chain _______________ process.
2. ERP plans based on ________ capacity.
3. ________ and ________ are leading supply chain planning software.
4. ILOG is a leading ____________ _________ vendor.
5. Linear regression is a __________ _____________ technique.
6. In collaborating forecasting a company forecast along with its ________.
7. Consistent planning can be divided into top down, ______ _______ and ________ __________ planning.
8. GATP stands for _________ __________ _________ _____________.
9. CTP stands for _________ _________ _____________.
10. VMI stands for _________ _________ _____________.
11. CPFR stands for _________ _________ _____________ _________.
12. CPFR is a ___________ step process.
13. GATP tools have capability of checking alternate ____________ and alternate __________.

IV. State Whether the following Statements are True or False

1. ERP can do constraint-based planning.
2. Supply chain planning software have extensive simulation capability.
3. ERP can handle prioritisation rules.
4. Replanning is faster in supply chain software.
5. ERP follows a sequential planning approach.
6. Causal models can do forecasting based on number of parameters.
7. Optimum truck load building ensures that the truck travels through the optimum route.

V. Assignments
Study in details the supply chain management solutions from two leading SCM vendors, i.e. i2 and SAP (SAP
APO solution). Note down all their modules and sub-modules. What capabilities do they offer? Draw similarities
and differences of their capabilities.
 26
Sales and Service
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Sales and distribution process and how ERP supports this
Sales and distribution master data
The concept of perfect order
Managing global trade (export and import)
Managing customer service

INTRODUCTION
Sale and service of products is one of the most critical processes of any organisation and in some cases
that is the basic reason for the existence of the organisation. Supporting this process effectively is one of
the first requirements for any organisation from an ERP system. Sales and distribution is one of the first
modules that ERP vendors came up. It is also among the most used ERP modules by end-users. While ERP
automates all routine sales and order management related transactions, if effectively used it can also achieve
the company’s vision of perfect order. In this chapter we discuss a typical company’s sales processes and
how ERP support that.
Increasingly companies are becoming global and export constitutes a major percentage of a company’s
revenue these days. ERPs had come up with specialised module and functionality to support export processes
and this is discussed in this chapter.
Finally while in most cases the companies in the same industry do not have any strong differentiator in
terms of the basic products they offer, what differentiates one company from the other is their service. ERP
and CRM applications can help companies to improve their service processes and this chapter focuses on
that as well.
400 Enterprise Resource Planning

SALES AND DISTRIBUTION PROCESSES AND HOW ERP

SUPPORTS THAT
Effective processing of customer orders (or sales order) is the need of every organisation and ERP software
helps in bringing efficiency and effectiveness in this process. Figure 26.1 shows a typical sales order cycle
that starts with a customer enquiry and ends with invoicing for delivery of goods or service provided to
the customer. While the steps in this process can change depending on the organisation, the basic building
block remains the same.
Enquiry by customer (verbal/phone/mail/order form).
Availability checks of the material and inform the customer about availability (or non-availability of
material). In case of non-availability of ready stock, inform customer the date by when the material
can be delivered (as now this need to be manufactured or procured). Sometimes the response against
the enquiry can be in the form of quotation where the price of the item, date of delivery and other
commercial terms are mentioned.
Order confirmation after doing the credit check of customer. If applicable at this stage, sales person’s
incentive also can get updated. Check for completeness and accuracy of order entry. This process is
also called sales order processing.
Inventory sourcing: This process defines from where the material need to be sourced, externally from
vendor or internally need to be produced. Based on the source, a set of action need to be triggered to
ensure availability of material on committed date.
Locate the nearest warehouse from where order can be served and order information is transmitted to
warehouse. Order is picked at warehouse. This process is also called shipping.
Transportation department arranges for shipment. This process is also part of shipping process.
Billing and invoicing.

Fig. 26.1 Sales Order Cycle

 Sales and Service 401

Dispatch of goods
Receipt of goods by customers and signing proof of delivery
Collection of payment
Customers need to be kept informed about order status during this entire cycle.
While most of the leading ERPs support all the steps in the sales order cycle described above, today’s or-
ganisations expect more advanced order management capabilities from the ERP system as follows:
Order receiving capability through multiple customer touch points like internet, e-mail, phone, SMS,
etc.
Capability of handling rush orders
Order communication: Ability to communicate order status to customers on a regular basis.
Order promising capability: This may call for capabilities like
Profitable to promise: Should I take the customer order at this time? ERP systems are expected
to guide the sales clerk, what is the best decision at that point?
Available to promise: Is inventory available anywhere in the supply chain to fulfill the order?
Capable to promise: Does my manufacturing capacity allow committing this order?
For leading enterprise solution vendors (like SAP and Oracle), some of these capabilities are not part of
their basic ERP solution and is addressed in other solution components like customer relationship manage-
ment (CRM) and advanced planning and scheduling (APS) solutions.

Managing Pre-sales Activities

This may include proactive sales activities like creating and tracking customer contacts and mailing cam-
paigns (direct mail campaign, internet campaign or telephonic campaign) to them or reactive sales activities
like answering customer queries received by phone or mail or fax. Inquiries may also result from specific
marketing measures like trade fair. Some of the customers may also request for quotation. ERP systems
helps in generating such quotations and these can be saved as documents. If some of these quotations actu-
ally convert to customer order, then this quotation data can be referred to and in most cases can be copied
to the customer order. Data on pre-sales activities and marketing activities is also important to formulate
marketing and sales strategies. For example, if there is repeated sales loss from a particular customer, the
analysis of same can help the company to come up with a better pricing or service strategy for the customer
to win his business. Business intelligence tools helps in this kind of analysis.

Material Availability Date Check

After enquiry, if the customer now wants to go ahead and place an order, it is important to check the avail-
ability of material. There can be two situations i.e. the material is available or it is not available. In case
material is available, the next step is simple, i.e. to go ahead and book an order. If the material is not avail-
able in finished goods stock and need to be manufactured or procured, the customer need to be informed
the expected delivery date. Once the customer is OK with that, the order is placed.
ERP system helps to calculate material availability date working backwards from the customer’s requested
delivery date and taking account the time required for picking, packing, loading and transporting the goods.
In customising of ERP systems, which elements are included in an availability check can also be configured.
For example, an organisation can do availability check only based on the stock available at warehouse or
based on the stock available at factory and warehouse or the availability check can also consider stock ex-
pected in future (from vendors against purchase orders or from factory against production orders). If there
is already some reservation made against a sales order or customer, availability check does not take this into
account as it is not freely available and can not be promised. Sometimes customers allow partial deliveries
402 Enterprise Resource Planning

and this also can be configured in ERP systems.

To be able to give the customer a delivery date for a material ordered, the ERP system takes into account
all of the necessary preliminary leg time for the different processes in shipping and transportation along with
the times needed at the shipping point for preparing and loading goods.
The aim of shipping and transportation scheduling is for the customer to confirm a delivery date for the
material ordered. In backward scheduling, the materials staging date and the transportation planning date
are calculated from the required customer delivery date. If the result of backward scheduling means that the
delivery date required by the customer cannot be confirmed, the system executes forward scheduling.

Sales Order Processing

A sales order is an electronic document that records customer’s request for goods or services and contains
all information to process the customer’s request. ERP systems makes sales order entry simple as it auto-
matically proposes data from master records (like customer master, material master, etc.) and control tables
that is previously stored in the system and thus, reducing possible input errors occurring during sales order
entry. Standard order normally contains:
Customer and material information
Pricing conditions for each item
Delivery dates and quantities
Shipping information
Billing information
The ERP system helps in creating sales order from reference documents, for example, from inquiries and
quotations (or any other business transactions already existing in the system) and in those cases the system
copies the relevant data from inquiry/quotation to the sales order.
Along with sales order entry, ERP systems also help in checking credit worthiness of customer based
on the previous transaction history. If the customer is a first time customer, the provision of taking bank
guarantee or integrating data from independent credit rating agencies are also supported by ERP systems.

Inventory Sourcing
Once the order is taken, the material for it needs to be sourced. There can be different possibilities here like
materials need to be produced at company’s factory or materials need to be sourced from suppliers or in case
the material is available in company’s another warehouse or factory, this need to be transferred. Depending
on the situation and system configuration, ERP can trigger different set of actions like:
Trigger make-to-order production (Production)
Create purchase requisition from external suppliers (Purchase)
Organise the outbound delivery from another warehouse (Stock transfer)
This part is part of material planning module of ERP systems.

Shipping
This include all the processes needed to make delivery of items and may involve activities like
Creating outbound deliveries
Picking in the warehouse
Packing in the warehouse
Planning and monitoring of transport
Posting the goods issue
 Sales and Service 403

There can be several outbound deliveries for a single customer order or several orders can be combined
into one outbound delivery (mainly depends on getting an economic transport load). In order to optimise
picking in warehouse, ERP systems help in creating picking lists which include all relevant deliveries.
A shipment is a collection of inbound or outbound deliveries that are shipped together. Effective trans-
portation processing is required so that deliveries are shipped on time and are received on schedule at the
customer’s site. ERP transportation application component provides essential functions for transportation
and shipment cost processing for goods issues and goods receipts. An ERP transportation order, can have
variety of information like
Means of transport: Indicates the specific vehicle type with which the goods are to be transported,
such as 10t truck, 20t truck or bulk container.
Shipping type: This is used to define the characteristics of the mode of transport, such as road, rail,
or sea.
Special processing indicator: Indicates whether there are any special requirements to be met during
shipping such as express delivery.
ERP systems also help in shipment cost calculation and shipment cost settlement. After cost calculation,
these costs are transferred to financial accounting and costing module of ERP and later on settled with
transporter or forwarding agent.
ERPs of late provide advanced functionality where tendering of shipments can be done over internet and
can be offered to a service agent. Shippers and service agents communicate over the internet, so the service
agent needs neither an ERP nor EDI.
When finally goods issues are posted, the system automatically:
Updates the quantities in inventory management and delivery requirements in materials planning
Updates the value change in the balance sheet accounts for inventory accounting
Generates additional documents for accounting, for example, for controlling
Generates the billing due list
Updates the status in all relevant sales documents.

Billing
Once the material is ready for despatch, a billing document needs to be created for the customer. ERP systems
help in this by copying data from the sales order and the delivery document to the billing document. The
billing document serves several important functions, i.e. it helps to generate invoices and this is the basis for
financial accounting team to monitor and process customer payments. During billing, ERP system carries
out a debit posting on the customer receivables account and a credit posting on the revenue account.
Billing Supports
Creating invoices for products and services
Creating credit and debit memos
Automatically transferring billing document data to accounting
ERP systems support creation of one invoice for one delivery or sales order or several invoices that can
be grouped using selection criteria, such as customer, billing date and destination country. The system can
combine several deliveries into a billing document.
When a billing document is saved, the system automatically generates all the required documents for
accounting. When the billing document is posted, the status in all related sales, delivery and billing docu-
ments is updated, the sales statistics is updated and the customer credit account is updated.
ERP billing process supports complex pricing rules for the customer, different incentives like deductions,
discounts, etc. There can be variety of discount depending on procurement volume, value, year to date value,
404 Enterprise Resource Planning

key customers, etc. ERP systems support different pricing procedures, complex pricing conditions and rules
to meet these requirements.

Payment
Payment is a process that is part of financial accounting module (accounts receivables module) of ERP
systems. Payment process supports
Receiving payments from customer
Making entry in the system, i.e. posting payment against invoices
Reviewing differences
When a payment posting is done, the relevant general ledger accounts gets updated automatically and
during this process, the ERP system carries out a debit posting to the cash account and a credit memo to
the customer receivables account.
Sales and Distribution Documents
Sales and distribution processes create several documents in ERP system as shown in Figure 26.2. These
are:
Sales activities and promotions are documents for sales support in pre-sales.

Fig. 26.2 Documents Created by ERP Sales Module

 Sales and Service 405

Sales documents are documents that are entered during pre-sales and sales order processing. inquiries,
quotations, contracts, scheduling agreements and standard orders are examples of sales document
types.
Outbound deliveries, transfer orders and shipments are documents in shipping processing. The goods
issue document contains changes involving stock and is the basis for the relevant accounting docu-
ments.
The billing document is a document in billing and is the basis for the relevant accounting docu-
ments.

SALES AND DISTRIBUTION MASTER DATA

ERP systems need few master data related to sales and distribution functions and these are:
Customer master data
Material master data
Condition master data
Route master for transportation

Customer Master
Customer master is the heart of sales and distribution function of ERP. The customer master includes all
data necessary for processing orders, deliveries, invoices, and customer payments.
Figure 26.3 shows different fields of customer master data of a leading ERP. These fields are grouped in
three major categories: general data, sales area data, and company code data.
General category is valid for company’s entire sales organisation and can have several tab pages like:
Address: Name, address, language
Control data: Tax information of customer
Payment transactions: Customer bank details
Marketing: Industry, customer classification
Unloading points: Goods receiving hours for customer, unloading points
Export data: Data for export control, if the customer is an overseas customer
Contact persons: Address and contact person of customer/business partners
The sales area data is relevant for sales and distribution. The sales area data in the customer master is
set out on the following tab pages:
Orders: Contain data fields for sales office, currency, sales district, price groups
Shipping: Contain data fields for shipping condition, delivering plant, transportation zone, etc.
Billing document: Customer tax classification, terms of payment, etc.
Partner functions: Ship to party, bill to party, payer, etc.
The company code data is relevant for accounting. It is valid for the respective company code. The
company code data in the customer master is set out on the following tab pages:
Account management: Reconciliation account
Payment transactions: Payment methods
Insurance: Amount insured
Partner Functions In a sales transaction, it can always happen that the party that places the order (may
be the central purchasing department of a group company), is different from the party that receives the order
(may be a subsidiary company of the group) and that is again different from the entity which finally pays
for the goods (may be the financial team of the group sitting in another different country). ERP systems
406 Enterprise Resource Planning

Fig. 26.3 Customer Master in a Leading ERP Solution

manage this through something called partner functions and it is stored in customer master. Following
partner functions are common:
Sold-to party: places the order
Ship-to party: receives goods or services
Bill-to party: receives the invoice for goods or services
Payer: is responsible for paying the invoice

Material Master
The material master also can have several data fields which can be grouped into several views. Figure 26.4
shows the material master fields relevant for sales from a leading ERP solution. Data can be grouped under
following tab pages:
Basic data: Include data fields like Material number, material description, basic unit of measure, etc.
Sales Org 1: Include data fields like delivering plant, material group, tax classification, etc.
Sales Org 2: Include data fields like material pricing group, volume rebate group, product hierarchy,
etc.
Sales: General/Plant: Include data fields like availability check, transportation group, loading group,
etc.
Foreign trade – Export: Include data fields like export/import group, region of origin, etc.
Sales text: Item text for sales.
 Sales and Service 407

Fig. 26.4 Material Master Fields Relevant for Sales

Condition Master
There can be different terms and conditions for delivery to different customers. ERP system maintains these
conditions as a master so that the same can be quickly copied in a sales order and need not be typed separately
reducing data entry errors. There can be also complex calculations related to prices, surcharges, discounts,
freights, taxes, etc. which can be defined in condition master and here calculation is dependent on various
other data for example, a material price can be maintained specifically for a customer or a discount can be
dependent on particular customer or material pricing group. The condition types in ERP define multiple uses
of a condition. Conditions can be based on percentage, quantity-dependent, an amount dependent surcharge
or discount etc. Conditions can be valid for a particular period.

Route Master
The route is the transport channel of an outbound delivery from the delivering plant to the customer. It has
a beginning point and an end point. The route can be used to define the actual transit time (period in which
the goods are being transported) and the lead time for transportation planning.

THE CONCEPT OF PERFECT ORDER

The concept of perfect order is designed to measure the effectiveness of the order management process. It
measures the percentage of orders that proceed through every step of the order management process, without
fault, exception handling or intervention. Each step in the order management process must go smoothly
408 Enterprise Resource Planning

for the order to be considered perfect. The steps may include order entry, inventory availability, accurate
picking, on time delivery, correct invoicing etc. If anything goes wrong (or require manual interventions,
exception processing or expediting), the order is not considered perfect. This metric measures the effective-
ness of the order fulfillment process, crossing the boundaries of functional departments. Companies have
began to measure the % of order that meet the criteria of perfect order and finding to their surprise that less
than 10% orders are perfect, they are reengineering their order management process. Figure 26.5 explains
how perfect order requires coordination of different supply chain functions.

Fig. 26.5 Perfect Order Fulfillment Requires Coordination of All Functions

Perfect order–list of problems:

Order entry error
Missing information (e.g. product code)
Ordered item is unavailable
Inability to meet ship date
Picking error
Late shipment
Late arrival
Incomplete paperwork
Early arrival
Damaged shipment
Invoice errors
Split shipments
Follow up required by customer
Table 26.1 shows a list of measures that can be used to check the effectiveness of order management
process.
 Sales and Service 409

Table 26.1 Perfect Order Measures

Perfect Order Measure Description

On time delivery/order cycle Products are delivered to customer on time
time
Warehouse picking accuracy Correct items are picked in retail distribution centre in correct quantities
On time shipment Products are shipped to customer on time
Product availability Product available to satisfy customer order
Product quality Products are delivered in perfect condition – no defective or damaged consign-
ment
Invoice accuracy The whole order is correctly billed
Payment accuracy Payment is correctly updated in system, loyalty data is updated
Document accuracy All documents are correct, i.e. warranty document, insurance document, delivery
note, etc.
Customer handling accuracy All queries from the customer relating to the order is handled efficiently – Order
status information, customer complaints

MANAGING GLOBAL TRADE (EXPORT AND IMPORT)

Managing global trade effectively is increasingly becoming a bigger challenge for companies. This is because
most of the large companies these days source a significant portion of their items from other countries and
at the same time a good amount of their revenue comes from export. Though global trade provides lots of
opportunity, it also brings lots of complexity in the supply chain in terms of complex customs regulations,
long lead time, legal requirements in terms of abiding by trade agreements between different countries. Post
9/11 incident, there are other complications in global trade in terms of managing risks, several regulations
imposed by different countries in terms of not doing business with restricted parties, etc.

Challenges of Global Trade

Long lead time leading to high transit inventory, higher safety stock and slower cash to cash cycle
time
Poor visibility into the process as lots of entities (customs, shipping, insurance, bank, etc.) are in-
volved
Generally poor service as supplier can not fulfill rush order or can accommodate last minute changes
in schedule
Complexity of global trade—a typical cross border shipment may involve more than 25 parties, 35
documents to be generated or transferred, 600 laws and 500 trade agreements to be considered. A
single error can result in costly delay
Disputes take longer time to resolve
Risk of global trade, especially after 9/11.

Critical Success Factors for Global Trade

Some of the critical success factors for international trade are:
Mitigate financial risk of trading globally. Managing currency fluctuations effectively
410 Enterprise Resource Planning

Improve reputation with enforcing agencies

Start dealing with government agencies electronically. Government systems (excise and customs
authority, different other import–export authority, etc.) are getting modernised. They expect business
to send electronic documents and communication and thus greater demand for automation.
SOX compliance require stringent record keeping and audit trial
Reducing risk of business disruptions through a strong mitigation strategy for non-compliance:
Securing global supply chain has become very important, especially after 9/11. There can be several
types of risks like customs risk, regulatory risks, natural disaster, etc.
Abide by trade compliance and documentation standards: This is becoming more important these
days for reasons like: Incomplete documentation causes border delays and unanticipated costs, cus-
toms fines and license withdrawal. There is corporate brand equity risk of unknowingly selling to a
restricted party.

How ERP Systems Support Global Trade

ERP systems have a separate module that supports different processes related to global trade. For example,
SAP has a separate module called, Foreign trade, for supporting such requirements and recently they have
come out with a specialised module called “Global Trade Services” (GTS) to support transactions related
to international trade. Figure 26.6 shows a list of processes supported by ERP’s global trade module. This
module can be effectively used both for managing export and import. These are discussed in detail below:

Fig. 26.6 ERP Processes in Global Trade

 Sales and Service 411

A. Custom’s management
Product classification – The aim of product classification/harmonisation process for duties and taxes
is to create a consistent classification of goods across the company. Export and import business trans-
actions need official commodity codes to report to customs authorities and these needs to be assigned
to ERP product master. There can be different numbering systems like export control classification
number (ECCN), harmonised tariff systems number (HTS), import list number, commodity code, etc.
There is regular need of reclassification as well whenever there is change in government policies.
Custom duty calculation—Upon importing into any country or while exporting, import or export duty
need to be calculated and paid to customs authorities. There are different types of duty rates that can
be applicable like preferential duty rate, anti-dumping duty rate, value added tax (VAT) calculation,
etc. Duty rate for new items need to be uploaded and if there is any change that need to be maintained
in the ERP system.
Management of different customs master data—Customs management also includes maintaining
different master data like: custom code lists, commodity codes, guarantees, list of authorised consignee
and consignors and different business partners like custom office etc.
B. Sanctioned party list screening – screening of suppliers
Security is becoming a global issue for the supply chain. As a responsible company, you should not source
anything from a supplier who is under a denied list published by different government bodies from time to
time. A supplier/manufacturer can be denied for variety of reasons like connection with terrorist organisa-
tions, using child labour or causing environment concerns. Rules in certain countries needs checking an
organisation’s business partners against multiple lists published by governments around the world. These
days there are intelligent screening software which can screen suppliers having multiple addresses, can
screen all sensitive documents, can do advanced linguistic and phonic search in multiple languages. When
the application detects a prohibited trading party, it blocks current transaction and send alerts. This help
tracking sanctions on non-cooperative countries, fines on non-compliant countries. ERP systems support
this process.
C. Preference processing
These are measures granting preferential customer treatments for goods from certain countries and geographi-
cal areas. Preferential treatments can be: reduced rate of customs duty, i.e. preferential duty rates or in some
cases exemption from customs duty. The legal bases for traffic preferences are several trade agreements. ERP
systems help in preferential processing through maintenance of vendor declaration, determining preferential
origin, determining eligibility for preferential treatment and finally printing vendor certificates that make
vendor’s products eligible for preferential treatment when it passes through customs.
D. Embargo check
Some countries impose tight restrictions on trade with other countries and this introduces significant vari-
ability in the import and export rules under which global corporations must operate. This process is called
Embargo check. For example, such a check may show that a company in Italy can ship certain products
to Russia, but the same check reveals that a U.S. company can not ship an identical product to Cuba. ERP
systems need to support such checks for international trade.
E. Managing import and export licences
If products are imported or exported without proper licence, there can be severe consequences. That is
why the classification of licensable material need to be tracked and proper licence to apply to be given to
transactions for both import and export need to be determined. Both the value and quantity limits issues for
each license need to be tracked via alerts and reporting mechanisms.
412 Enterprise Resource Planning

F. Managing import/export documentation

There can be variety of import documents and efficient import process requires these documents need to be
managed effectively. Some examples of this can be:
Import or export declaration
Transit document
Required forms like entry summaries, certificates of origin, packing lists, etc.
Letter of credit
Documents for managing trade preference processing like managing vendor declarations, determining
preferential origin, printing of preference documents, etc.
G. Import and export processing
There can be variety of processing involved in import and export like:
Entry processing and anti-dumping counter veiling checks: Are there any anti-dumping measures that
need to be taken into account and can challenge import transactions.
Quota checks: Are there any quota to be considered
Bonded warehouse processes/customs warehousing
Declaration before goods receipt: When importing goods you can present these goods to customs right
at the border and place them under a customs procedure with customs declaration
H. Electronic communication with customs authorities/trade systems
These days government authorities are becoming more demanding and they expect electronic communication.
Example of this can be electronically filing all information requiring shipper’s export declaration via AES.
This data must be submitted prior to departure. ERP systems support such electronic communication.

How ERP Systems Manages Global Trade Challenges

ERP systems helps in managing global trade by managing four sets of processes as shown in Figure 26.7.
These are
Managing the physical supply chain
Managing the financial supply chain
Managing government
Managing multiple entities involved
A. Managing the physical and financial supply chain well
Managing Global logistics calls for managing both physical and financial supply chain effectively.
The physical supply chain describes the activities involved in planning and executing the movement of
goods, including making, storing and moving products and their documents (i.e. purchase order, bills of
lading and customs documents). Leading companies are looking to create better coordination across strategic
sourcing and procurement, manufacturing, logistics.
The financial supply chain describes the activities involved in planning and executing payments between
trading partners through various financial instruments, including INCO terms, exchange rates, credit and
country risks. It involves cash flow, working capital and corporate risk management. Leading companies
are looking at how to leverage cash and credit across supply chains to create greater financial efficiency.
Physical supply chain processes: Cross border trade involves many parties, and physical logistics can be
quite complex to coordinate and include the following:
Export/import/customs compliance
Global logistics management—Logistics operations and network design
Supply chain visibility
 Sales and Service 413

Fig. 26.7 Global Trade Challenges

Exception alerts and resolution

Multi echelon inventory management
Global risk and security management
Multi-modal transport planning
Import documentation and compliance
Contingency planning, corporate risk management, business continuity planning
Financial supply chain processes
These are financial aspects of international trade and can include the following:
Duty calculation
Duty drawback
Letter of credit
Tariff management
Electronic paperwork
Invoice reconciliation and claims automation
Financial settlement
Corporate risk management
Contract management
Trade finance – cash, credit and working capital management
Purchase order management
414 Enterprise Resource Planning

Settlement management (e.g. LCs or open accounts)

Pre- and post-shipment financing
Dispute/chargeback management
Foreign exchange management
Insurance management
B. Managing government regulations
Complying with the regulatory requirements and streamlining collaboration with government authorities is
another major challenge for global trade management. ERP systems help in Government compliance and
document regulations by providing electronic version of different documents as stipulated by the customs
and different government agencies for speedy customs clearance. Different states within the same country
can have different electronic filing requirements and may need reports in different formats from ERP.
C. Managing collaboration among number of players
Managing of global trade requires effective collaboration among lot of players like:
Company
Freight forwarders/customs brokers
Logistics technology providers
Financial institutions
3PLs/LSPs
Government agencies like customs, export administration, etc
ERP systems support number of collaboration technologies like EDI, portal, etc. to support such col-
laboration.

MANAGING CUSTOMER SERVICE

The responsibility of a company does not end as soon as the product is sold, but providing service throughout
the usable life cycle of the product is also something important for the company. Increasingly product quality
is considered to be given in the marketplace and service is becoming the major differentiator. From an ERP
perspective, some of the processes which can be supported by an ERP solution are as follows:
Assembly of technical objects on site at the customer
Despatching of spare parts to the customer
Repair of customer devices by field service technicians on site at the customer
Repair of customer devices in the service centre, i.e. in-house
Regular inspection and preventive maintenance of customer devices in the service centre or at the
customer site (i.e. field service)
Managing warranty: A warranty is a vendor commitment to a purchaser of a product, that the product,
or parts of it, fulfills particular requirements for a particular period of time, or for a defined use. If this
is not the case, the vendor commits himself to replacing or repairing the product. This can be either
customer warranty (issued by the company to its customer) or vendor/manufacturer warranty (issued
by the vendor/manufacturer to the company)
Helpdesk: This is used for recording, processing and forwarding of incoming customer requests. This
is also called customer interaction centre
Having ready solution database: The solution database contains symptoms, solutions, and references.
Solutions and symptoms are linked with one another using references. Symptoms are saved in the
solution database together with solutions and linked to these solutions. The search is supported by a
search engine
 Sales and Service 415

Managing returns
Managing service contracts (AMC and maintenance contracts)
While most of these are under the purview of the ERP systems, some of these like helpdesk and customer
interaction centres, managing solution database, etc. comes under the purview of CRM applications.

Summary
In this chapter sales, service and global trade processes of an organisation are discussed and how an ERP solu-
tion can help in that.
Sales process typically follows the sequence of inquiry, availability check, sales order processing, order
picking, transport, billing, despatch of goods and finally payment collection from customer. It is important
to keep the customer informed during this entire process.
To support sales and service processes ERP systems need master data in the form of customer master, mate-
rial master, condition master, route master, etc.
Perfect order is a measure of delivering a customer order without any error in the entire deliver process. This
is a good measure of a company’s order management process efficiency.
ERP systems have come up with specific capabilities to manage international trade for an organisation in the
form of import processing, documentation, import licence, preference processing, embargo check, sanctioned
party list screening, custom duty calculation and product custom classification.
Finally ERP and CRM solutions helps in providing better customer service in the form of spare parts man-
agement, repair of customer devices, managing warranty, customer helpdesk, managing returns, managing
service contracts, etc.

Exercise
I. Objective Type Questions
1. What is profitable to promise, available to promise and capable to promise?
2. What are the multiple channels through which orders can be received?
3. What are the typical contents of a sales order?
4. What are the examples of pricing rules?
5. What are the four important master data for sales and distribution process?
6. What is condition master?
7. What are the reference documents from which sales orders can be created?
8. How Route master can be defined?
9. What are the measures of perfect order?
10. What is sanctioned party list?
11. What is preference processing?
12. What is embargo check?
13. What are the typical export and import documents?
14. Name some of the physical supply chain processes.
15. Name some of the financial supply chain processes.
16. What are the different trading players in global trade?
17. What is warranty management?
416 Enterprise Resource Planning

II. Descriptive Type Questions

1. Explain a typical order management cycle. How does an ERP system support such a cycle?
2. How does an ERP system supports different pre-sales activities? What are the capabilities of an ERP system
to do material availability check?
3. How do ERP systems help in processing sales orders?
4. What are the activities in shipping? How do ERP systems support shipping activities of an organisation?
5. How billing and payment processes are supported in ERP?
6. What are the typical sales and distribution documents created by ERP system?
7. What are the typical fields in customer master field? Explain partner functions.
8. What are the different sales and distribution relevant material master data in ERP system?
9. Explain the concept of perfect order. What are the typical problems in perfect order? How perfect order
can be measured?
10. What are the challenges of global trade? What are the critical success factors of global trade?
11. What are the different capabilities of ERP system to support global trade?
12. What are the capabilities of custom management in ERP solution? What is Product classification?
13. How ERP systems help in managing global trade challenge?
14. What are the typical physical and financial supply chain processes?
15. How ERP systems help in customer service?
 27
Logistics Execution:
Warehouse and Transport Chapter
Management

Learning Objectives
In this chapter we will discuss the following concepts:
Logistics Execution
Warehouse Management
Basic processes and functions of a warehouse
Value added services of a warehouse
Best practices in warehousing – Cross-docking
Warehouse process maturity model
Using information technology and ERP for warehouse management
Measures of warehouse management
Transport Management
Transportation cycle for a company
Using information technology for transport management
Measures of transport management

LOGISTICS EXECUTION
Processes of warehouse management and transportation management are referred to as logistics execution
processes. Typically these are transaction-intensive processes. For example, there can be thousands of goods
receipt in a day in a company’s warehouse and ERP systems can bring efficiency, accuracy and speed in
this activity. For third party logistics service providers or 3PLs (transport companies, companies providing
warehousing services and companies providing both), logistics execution is their core business process and
LES (Logistics execution systems) is the heart of their business. While leading ERP vendors like SAP and
Oracle have strong capabilities in this area, there are best of breed warehouse management system (WMS)
and transportation management system (TMS) vendors (for example, Manhattan is a best of breed WMS
vendor).
418 Enterprise Resource Planning

Basic Functions of a Warehouse

A company can have warehouse for inbound goods (i.e. for storing raw materials, packing items, etc.) or for
outbound movements (for storing finished goods). Traditionally inventory control, goods movement, storage
and shipping (known as pick, pack and ship) are the most important functions of a warehouse. However, a
warehouse presently performs many other functions like managing reverse logistics, value added services,
etc.
Figure 27.1 shows functions of a modern day’s warehouse.

Fig. 27.1 Functions of a Warehouse

A. Goods receipt
Receiving goods is one of the fundamental processes in every warehouse. Goods are received from sup-
plier, quality check is done, and goods are returned which are not within quality limit. Sometimes ware-
houses receive an advanced shipping notification (ASN) before the actual shipment. Use of ERP software
is common in this process as volume of daily transactions can be huge. A warehouse depending on size can
receive thousand of items on regular basis. There can be several sub-processes under goods receipt process
as follows:
Receiving goods against a purchase order
Receiving goods against a delivery schedule
Damage identification on receipt
 Logistics Execution: Warehouse and Transport Management 419

Unloading and unpacking

Capture lots of information on receipt
Reconcile purchase order/delivery schedule line item with receipt
Doing quality sampling check (in some cases)
Vendor returns in case of goods that are not within quality limits
Receiving advanced shipping notification (ASN) receipt from manufacturer before receiving a con-
signment
Posting goods receipt (with total quantity, accepted quantity, date, etc. – this becomes the basis for
rating the supplier)
Typically every goods receipt system has some reporting capabilities like receiving exceptions, vendor
report card, open purchase orders, etc. These days with bar codes and radio frequency (RF) scanner at re-
ceiving doc, goods receipt process has become simpler.
B. Put-away
Once the goods are received in the warehouse, the next important step is to move materials from receiving
area to point of use or storage location. This process of moving material from the dock and transporting it
to a warehouse’s storage, replenishment, or pick area is known as put-away. ERP and leading WMS systems
provide several functionalities to make this process efficient and some of them are as follows:
Calculating resource and space requirement for put-away: ERP or WMS systems can calculate
this based on expected receipts and current backlogs.
Enabling direct delivery (from receipt to the storage location): This is a very efficient process for
material handling as it uses least space for staging and product is handled less and ready for use sooner.
To facilitate direct put-away, ERP and WMS applications can assign locations from an advance ship
notice (ASN) or upon receipt at the dock.
Identifying best put away route: ERP and WMS systems helps in identifying best put-away travel
paths that are sequenced based on the shortest route for the product in the load and reduces travel
time.
Supporting different put-away strategies: There can be a variety of put-away strategies which a
company can use to optimise the storage of goods in the warehouse. Based on this logic, the system
will search for a storage vacant bin in the warehouse when a new material arrives. Leading ERP and
WMS vendors support a variety of put-away strategies and based on this, the system automatically
locates the best location for the goods which are just received.
C. Slotting/Replenishment
Product slotting is the technique of intelligently locating a product in the warehouse or distribution centre
for optimising material handling efficiency, i.e. it identifies the most efficient placement for each item in a
distribution centre or warehouse. Slotting improves picking productivity. Travel time can often account for up
to 60% of a picker’s daily activity. A good product slotting strategy can reduce travel time thereby reducing
picking labour. This is achieved by putting fast-moving goods towards the front, by grouping together those
products that are regularly sold together, to put bulk stock close together for replenishment, by putting heavy
products at hip or shoulder level. All these improve productivity and provide the best ergonomic solution.
Some of the typical capabilities of ERP/WMS tools are:
ABC Slotting: This is one of the popular slotting methods. As 50% of pickers’ time at work is spent
in transit, one way to decrease that transit time while increasing the number of picks per worker is
ABC slotting. Simply, ABC slotting is storing the most-popular merchandise closest to the picking line
and the least-popular items farthest away. To implement ABC slotting, products need to be graded to
A, B, or C based on each item’s sales volume. Place A items (may be shipped 150-200 SKUs daily)
420 Enterprise Resource Planning

near the picking line — typically at the front of the warehouse, B products, (may be shipped 60-70
SKUs daily) should be stored just beyond the A designation, place your C products near the back of
the warehouse (may be shipped less than 10 SKUs daily). Generally A, B, C distinction is based on
daily and monthly sales reports. ERP and WMS packages can recommend where different items in
the warehouse should be stored based on sales history to ensure proper flow.
Slotting optimisation: These will take into account demand patterns at item level and can suggest
improvements to stock location. These applications require lot of data including the measurements,
location, and number of products in a box; the number of boxes on a pallet; the storage conditions of
each article, information about the pick locations of SKU, etc. The system also requires data about the
movement of goods, such as the number of picks per product and its demand forecast. Optimiser can
suggest best locations for storage. Slotting optimisers are part of few advanced warehouse manage-
ment system applications and some of the leading ERPs also provide this as part of their warehouse
management module.
D. Picking
Picking is the process by which the goods are picked from different warehouse locations for delivery against
order. There are different picking methods like:
Single order picking: This entails picking to a single order and the order is placed into the shipping
container, eliminating downstream handling. Generally orders are prioritised by customer-requested
ship date.
Multi-order batch picking: This technique works best when there are a large number of SKUs that
may be ordered and the SKUs are spread over a large area. Batching enables a picker to pull the
products for a number of orders as he passes by each item’s stocking location.
Order consolidation: This method groups orders by destination or by customer. It has the benefit of
pulling product for multiple orders in a single pass through the pick area.
Wave picking: A wave is an automated grouping of orders by a specific set of criteria. Orders may be
grouped by priority, by carrier, by shipment type, or by destination. These combined orders are then
released to pick area as a group.
Zone picking: These orders may be grouped by predefined warehouse zone such as case pick area, bulk
pick area or pallet pick areas. With zone picking an order may be split and subsequently consolidated
in the shipping area.

ADVANCED PICKING TECHNOLOGIES

Picking product is one of the most labour-intensive operations in the warehouse and paper pick
tickets are the most common form of pick documentation used for this. However, they are prone
to human error and are usually less efficient in case of high volumes. So, these days it is common
to use advanced technology options for this. Some of the upcoming technology options in this
area are:
Light picking technology: This is a paperless picking technology. A system of lights throughout the
picking areas is linked to the order management and inventory system. The worker picks product
by following the lighted locations and then confirms each pick in the ERP system. The system is
then able to carry out inventory transactions, complete order records, and drive replenishment
requirements.
 Logistics Execution: Warehouse and Transport Management 421

Voice picking technology: Voice messages deliver tasks to picker and help him to direct to the
correct pick location. This technology is very simple for users as they simply receive a verbal com-
mand, which everyone can easily follow, and then they respond to the system by speaking their
status or actions. Users have no responsibility to make a judgment. This is a hand free and eyes
free technology that offers productivity gains. This technology works like this:
A picker puts on his headset, logs into a terminal that recognises his name, and receives his
first assignment. For instance, the headset might issue the command, “Go to aisle 001, location
3.” When the picker arrives at aisle 001, location 3, he will see a label with a number printed on
it. The picker repeats the number into the headset to let the system know that he is in the right
place. The system tells the picker how many items to pick. After the picker has done this, he will
say something like “ready” to let the computer know that it is the time to hear the next task.
The system then tells the picker how to proceed. As the picker pulls items to fill orders, the ERP
warehouse management module is alerted to the action through a computer the picker wears
on his belt. Voice-directed picking enables workers to keep their hands and eyes free, as pickers
don’t have to look at computer screens or paper lists to determine how to fill orders. They simply
listen to instructions that come through their headsets.

E. Packing
Packing is the process of packing the articles in cartons before dispatching to stores.
F. Loading and goods issue
Goods issue from warehouse typically happens against a customer order (for finished goods) or against a
production order (for production raw materials). These issues can be recorded in inventory management
system so that the inventories are updated. Before doing goods issue, goods can be packed and loaded in
carrier as per the delivery specification. The process can also involve activities like notification of goods
(ASN) to be supplied from a warehouse to a customer and obtaining a proof-of-delivery from the receiving
business partner. So, activities under this can be listed as follows:
Delivery creation
Packing
Goods issue in warehouse
Loading
Posting goods issue to inventory management
Creating ASN for business partner before making the dispatch
Receiving proof of delivery (POD) from business partner.
G. Handling customer return/Reverse logistics
Handling returns from customers is another important aspect of warehousing. Returns first come to retail
store and then to the warehouse at the backyard of the store, and later on these may come to the central
warehouse from where the same may be sent back to supplier for replacement or destroyed. There can be
two instances for return: the customer is paid back the money in that case retailer need to process the credit
refunds or the customer is given back a replacement, the second one is known as warranty claim. In case of
warranty claim, i.e. the product need to be replaced, these returns are taken back to central warehouse where
it is consolidated and the retailer make a warranty claim to suppliers of these articles. Once the suppliers
process these claims, replacements are received at warehouse from where they can be sent to individual
store. An ERP system needs to handle this entire reverse logistics process.
422 Enterprise Resource Planning

Value-added Services of a Warehouse

A warehouse can provide lot of value-added services. Figure 27.2 shows different kinds of value-adding
services that can be provided by a warehouse operator.
Light assembly: Typically this makes sense for consumer durables, office equipment or home furnish-
ing items, where components come from different suppliers and at warehouse they are assembled. Of
course in warehouse only very simple manual assembly kind of operation can be performed.
Repair/Refurbishing: If there are minor defects in incoming shipments, the goods can be repaired at
warehouse.
Quality control/Inspection: Inspection at goods receipt stage is quiet common at warehouse level.
In transit merge: Typical example of this can be a personnel computer retailer where the PC and the
printer come from two different manufacturers, shipments are consolidated at warehouse and delivered
as a complete set to the store.
Kitting: Kitting is an operation where parts come from different suppliers and sold as a complete
kit. A typical example can be for an auto accessory kit - spanner, screw driver and other items can
come from different suppliers, assembled as a “Car repairing kit” at warehouse and the complete kit
is delivered in store as ready to sell item. The warehouse needs to be aware about the Bill of material
(BOM) for the kit for this kind of assembly operation.
Cutting: Items may come in big length from manufacturer which is cut in warehouse in sizes in which
it is sold at store.

Fig. 27.2 Warehouse—Value-added Services

 Logistics Execution: Warehouse and Transport Management 423

Labeling/Tagging: This is the most common warehouse value-added operation where the items are
opened from big pack/container, repacked in smaller packs suitable for store, new labels – bar codes
and price tags are attached.
Specialty packaging: This can be for special seasons like “Christmas packaging”, “Valentine day
packaging,” etc where several products are bundled together. This can be also for special promo-
tion scheme. For example, two soaps and one shampoo is bundled in a special pack at a discounted
price.
Increasingly, companies are using warehouse not just for storing goods but for doing the set of value
added services as discussed earlier. Today’s ERP systems need to support such value-added services.

Best Practices in Warehousing—Cross-docking

Cross-docking is a distribution technique, more common in retail industry where an item is taken from the
manufacturing plant and delivered directly to the store with minimum handling in the process. In this process
materials are unloaded from an incoming truck or rail car in distribution centre and loaded in outbound truck
or rail cars with little or no storage in between, i.e. goods are received at one door and shipped out through
the other door almost immediately without putting them in storage. This requires close synchronisation of all
inbound and outbound shipments. Sometime merchandise from an arriving truck is broken down into case
or pallet loads upon arrival at a cross-dock facility. Cases or pallets are quickly moved across the warehouse
to the shipping dock, where they are placed onto truck loads for individual stores. The speedy transfer of
goods eliminates the need for warehouse storage.
Cross-docking has quite an interesting history. Historically transport companies used to bring small loads
by small tracks/vans at hubs, repack them and used to reload them in large carriers like trailers/trucks etc.
and used to move them for long distance to optimise truck movements. In the 1980s mass merchandise such
as Wal-Mart had used this concept and started cross-docking in large scale. The grocery industry had first
started cross-docking, however, soon this also became popular in automative industry. Components from
several suppliers are consolidated at logistics hubs and cross docked from there to factory. Cross-docking
is now used in several other industries.
Advantages of Cross-docking
Reduction of cost in terms of handling costs, operating costs, inventory storage costs, shrinkage, dam-
age, product obsolence and warehousing costs. By eliminating put away and storage, it significantly
reduces distribution costs.
Reduction of cycle time: Products get to the distributor and consequently to the customer/end user
quicker and thus, increasing throughput. Reduction of cycle time increases shelf life of products,
i.e. products are fresher when they reach customer, and less will be unsold when expiry dates are
reached.
Reduction of inventory levels: Cross-docking reduces inventory in the chain as warehouse inventory
is virtually eliminated. Fewer inventories means less space and equipment required for handling and
storing the products. This also means reduced product damages and product obsolescence.
Better account receivables: If supplier bills at time of shipment, cross-docking can help a company
to get its product through the distribution centre and out to the customer, starting accounts receivable
clock sooner.
Improvement in warehouse space usage: The area needed for the depot is reduced since the ware-
house serves only as a stop over point for the distribution of the goods.
A typical cross-docking centre can be divided into three areas, i.e. receiving area (here goods are received
either in truckloads from different suppliers), staging/sorting area (area where materials are sorted, consoli-
424 Enterprise Resource Planning

dated and repacked), shipping area (here the shipments are loaded into outbound trailers/trucks). Figure 27.3
illustrates this layout.

Fig. 27.3 Cross-docking Layout

How Information Technology and ERP Helps in Cross-docking A company need to have few
IT enablers in place to start cross-docking – EDI, bar codes/RF scanners, warehouse management system
(preferably of an integrated ERP), etc.
EDI between supplier and retailer: This is crucial because all inbound and outbound deliveries of
trucks need to be synchronised and tightly controlled for effective cross-docking. Suppliers gener-
ally send an electronic message known as an advance shipping notice (ASN) to the receiver prior to
the goods arrival detailing when the shipment is coming, quantity, shipment content, etc. The retail
warehouse in the same way can send message to individual store informing them about the shipment
so that stores can keep their receiving section ready. Messages can also flow between cross-docking
centre and the transport company asking number and type of trucks. Thus, EDI is the heart of cross-
docking. ERP systems supporting cross-docking need to have this capability.
Bar codes/RF scanners: Bar codes placed on cartons/pallets allow the receiving warehouse to route
them quickly to the appropriate shipping dock designed for specific store delivery. This also means
that the warehouse needs to invest in few bar code scanners.
ERP warehouse management system: This is another critical element in a cross-docking system.
This determines the sequence for unloading inbound trucks and loading outbound trucks. As workers
remove cartons on pallets from the inbound trucks, they scan the bar codes. The computer system
automatically matches the scanned information about delivered goods with the information received in
the advance shipping notice. The computer checks receipt of goods and update inventory as it directs
 Logistics Execution: Warehouse and Transport Management 425

the workers where to place the goods on the appropriate conveyor for transfer to the correct area of
shipping dock.

ERP VS. BEST OF BREED

Manhattan Associates is the best-of-breed warehouse management solution providers with more
than 1,500 WMS customers worldwide. It is a pure play logistics solution vendor and in terms of
pure warehouse management capability, it scores higher than leading ERPs like SAP and Oracle.
It has strong capability in value-added service, shipping, reverse logistics, RFID, yard management,
labour management, etc.

Warehouse Process Maturity Model

Figure 27.4 explains the concept of warehouse process maturity model. Base of this pyramid talks about the
basic warehousing processes which any manufacturing/logistics oriented company needs to perform to be
in the business. The next layer talks about mature warehousing processes that help a company to improve
greater efficiency in warehouse in most cases with the help of technology and these capabilities help them

Fig. 27.4 Warehouse Process Maturity Model

426 Enterprise Resource Planning

to improve productivity and reduce warehousing cost. The highest level of the pyramid talks about advanced
warehouse practices that very few companies adopt to gain competitive advantage. ERP systems can help
in all these three levels and depending on the maturity of the organisation, it needs to be decided at what
level of sophistication ERP functionalities need to be implemented.

Using Information Technology and ERP for Warehouse Management

Information technology is used in various degrees in modern warehouses depending on the sophistication of
the warehouse, kind of activities performed and level of maturity of warehouse operations. Here are some
examples:

Business Need ERP/Information What it does

Technology used
Efficiency in warehouse ERP warehouse management Support high volume warehouse transactions like goods
transactions module receipt, goods issue, delivery document creation, pick-
ing, packing, etc.
Cross-docking Advance shipping notifications ASNs make the warehouse people ready for receipt and
(ASNs) functionality of ERP better planning of cross-docking inbound shipments with
outbound deliveries
Track and trace RFID with ERP WMS Helps in track in trace of inbound load and outbound
shipments.
Quick inventory update Scanner and bar code Instead of manual entry into system, scanning helps
in quick updating of inventory at point of receipt and
issue.
Material handling ef- Slotting and loading optimisa- These applications help in optimally locating a product
ficiency tion applications in warehouse for material handling efficiency based on
variety of parameters
Optimum usage of ware- Task and resource management These applications help in optimum distribution of load
house labour applications between different warehouse operators

Measures for Warehouse Management

There can be several measures for evaluating the efficiency of warehousing operations for a company. These
measures can be enabled by OLAP and business intelligence applications in the form of KPIs, reports, etc.
There can be variety of measures here as shown in Table 27.1.

Table 27.1 Warehouse Management Measures

Measure Definition
Receiving accuracy A measure of receipt conformity of recorded values to the actual values
Receiving and product storage All costs associated with taking possession of and storing product. Includes
costs as a % of product acquisi- warehouse space and management, product receiving and stocking, processing
tion costs work orders, pricing, and internal product movement. This does not include
incoming inspection
(Contd)
 Logistics Execution: Warehouse and Transport Management 427

(Contd)

Transfer and product storage All costs associated with the storage and/or movement of the product to the next
costs as a % of product acquisi- appropriate stocking location (transfer point) in the supply chain expressed as a
tion costs percentage of product acquisition costs
Picking accuracy Number of picks correctly done by total number of picks in a day. This is done
operator wise.
Picking efficiency Number of picks everyday. This can be done operator wise to measure labour
efficiency.
Packing, loading accuracy Number of packing, loading correctly done by total number in a day. This is
done operator-wise.
Packing, loading efficiency Number of shipments packed, loaded in a day. It can be also measured weight-
wise. This can be done operator-wise to measure labour efficiency.
Warehousing cost as a percentage Total cost of warehousing operations as a percentage of total logistics costs or
of total supply chain cost/sales total supply chain cost or as a part of total turnover.
Measures for value-added service There can be variety of measures here depending on type of service like making
done by warehouse merchandise floor ready, kitting, etc.

TRANSPORT MANAGEMENT
Transport is an important element of cost for every manufacturing/logistics company today as transport costs
are incurred for bringing raw materials to factory, for primary distribution of finished products to warehouse,
for secondary distribution from warehouse to distribution centres and finally for tertiary distribution from
distributor to end customer or retail store. Transport cost percentage may vary depending on the type of
product. For example, for certain food products like rice, salt, biscuit, fresh fruits and vegetables, percentage
wise transport cost can be a good percentage of product cost, whereas for some other categories like fashion
apparels, perfume, etc this percentage may be marginal. ERP and information technology solutions can bring
lot of efficiency in the transport management processes of an organisation. Today’s transport managers in
organisations are facing lots of challenges. Figure 27.5 explains some of those. Today’s transport managers
need to manage several complexities like:
Managing cold chain
JIT deliveries, i.e. frequent deliveries in small lots
Managing global logistics as most companies source from low cost countries these days
Multiple mode and Multi-zone transportation
Pressure on reducing lead times
Increasing compliance requirements
Increasing importance of shipment tracking
Cross-docking
Milk runs
Vendor managed inventory, Continuous replenishment challenges
Special packaging and handlings requirements
Seasonal demand
Better transport management help in cost reduction in following ways:
Reduce expedited order costs due to better planning and system directed exception handling.
Increased load consolidation from LTL (less then truckload) to FTL (full truckload)
Better carrier and mode selection
428 Enterprise Resource Planning

Fig. 27.5 Challenges for Transport Manager

Lower administration cost with automation of tendering, shipment creation and consolidation
Utilise assets (drivers and equipment) more effectively
Lesser transit inventory
Better transport management help in improving service level in following ways:
Lesser out of stock
Lesser lead time
Product remains fresher

Transportation Cycle for a Company

Transportation cycle is the sequence of activities that a company carries despatching goods. A simple trans-
portation cycle as supported by ERP is shown in Figure 27.6. The process shown has following steps:
Receive order: The basic trigger of transportation process is customer orders with specific delivery
date and quantity.
Create shipment: In this step the orders are grouped with common service requirements and freight
terms. Large orders or orders requiring multiple shipments or periodic delivery schedule can be split-
ted.
Create load: Looking at the delivery date and nature of shipment, it is decided whether the shipment
will go by air, sea or road truck, trailer, etc.
 Logistics Execution: Warehouse and Transport Management 429

Fig. 27.6 A Simple ERP Transportation Cycle

Assign carrier to load: Some companies have their own carriers and most of them outsource their
transport operations. In this step company decides the particular load will be given to which carrier.
Carriers are assigned to load based on cost, service, performance availability, etc.
Schedule pickup: In this step, the shipment is released to warehouse for picking and work
scheduling.
Create delivery documents: Here relevant delivery documents are created (like pick sheet).
In transit tracking and resolve exceptions: The company needs to track the consignee from the point
it leaves factory till it reaches the customer. Company can use some manual tracking system like taking
information through phone or can use sophisticated tracking system which gives the detailed status of
each shipment as soon as shipment number is typed in. In case there are some exceptions like delay,
the company needs to take corrective action.
Delivery confirmation: Once the shipment reaches the customer, the proof of delivery (POD) is
collected from the customer. This can be a physical document or sent electronically through EDI.
Sometimes this is the basis for transporter payment.
Freight payment: Once the shipment is delivered, transporter submits his bills which are processed
by the company. In case of transport damage or delay beyond a limit, company can deduct some
percentage of transporter’s payment.
Carrier performance measurement: Generally most of the companies have a system of measuring
transporter’s performance based on criteria like schedule performance, damage record, service flex-
ibility (placing a transport at short notice), etc.

Using ERP/Information Technology for Transport Management

Information technology is increasingly getting used in managing transport better. There are different facets
430 Enterprise Resource Planning

to technology usage, i.e. using more high tech carriers that speed up the process of material handling, using
better network systems for tracking carriers and using information technology for better transport planning.
Table 27.2 shows the use of information technology in transport management.

Table 27.2 Information Technology for Transport Management

Business Need ERP/IT used What it does

Tracking vehicles on Global positioning systems Help in tracking vehicles in transit
the move Wireless technology Wireless asset tracking companies like GobeRanger, Qual-
comm and Savi technology helping in track and trace
Building optimum Truck load building technol- These applications help in building optimum load for the
load so that vehicles ogy truck, keeping truck’s space and load carrying capacity in
never runs empty mind. Load can be built keeping the drop sequence in mind
and properties of materials. Specialised application vendors
like “loadbuilder” helps in three dimensional truck load
building.
Building optimum Route optimisation applica- These applications help in building optimum route keeping
route so that vehicle tion multiple drop points in mind and ensure that the truck travel
travel minimum dis- minimum route while dropping at all the points. Special
tance constraints can be built like the total transit time should not
cross more than 8 hours for perishable items like milk, which
need to reach processing centre within specified number of
hours of collection. SAP’s APO TPVS (Transport planning
vehicle scheduling), i2 route planner, GLOG are leading
applications.
Better planning of ve- Transport planning applica- These applications help in better planning of vehicles i.e.
hicles so that minimum tions when what size vehicle needs to be ordered looking at the
number of vehicles are daily shipment plan, service level required and vehicle capac-
used ity. SAP Transport Management (TM), i2, Oracle’s GLOG,
Manugistics, Manhattan, etc. are leading players in TMS
application space.
Transport consolida- Network optimisation ven- These applications help in recommending points of transport
tion points planning dors consolidation in supply chain network. Logic tools is a lead-
ing vendor in this space.
Supporting transport Transport management ap- These applications support freight costing, settlement of
transactions plications transport vendors, transport documentation preparation etc.
SAP TM, Oracle’s GLOG are leading vendors here.
Visibility in ocean Ocean specific portals Consolidate data from various ocean carriers for shippers to
provide end-to-end visibility.
Better fleet manage- On board computing Enables better matching of available vehicles to potential
ment loads, support better fleet management and help extend ef-
fective engine life through monitoring vehicle use.
 Logistics Execution: Warehouse and Transport Management 431

Measures of Transport Management

Different retailers adopt variety of measures to measure efficiency of transport management. Table 27.3
shows some of these measures.

Table 27.3 Measures of Transport Management

Measure Definition
Transportation cost as a % of supply Transportation costs Including all company paid freight and duties from point
chain cost/as a % of turnover of manufacture to store as a percentage of supply chain cost/turnover
Transport lead time adherence % How many times the transporter had reached the destination within expected
lead time, i.e. in how many occurrences there are delays as percentage of
total number of occurrences
Transit inventory % Percent of transit inventory as part of total inventory
% of empty running In how many occasions in a particular time period (say, month) there are cases
of empty running divided by total number of occasions. This is an indicator
of planning efficiency
Transport settlement error % % of invoices having errors divided by total number of invoices

Summary
In this chapter we have discussed two important areas of ERP logistics execution solution: Transportation and
warehouse management. These are important logistics functions as it contribute close to 50% of logistics cost.
Warehouses has a set of inbound (goods receiving, unloading, put-away, etc.) outbound (picking, packing,
goods issue) and in-house (slotting, inventory management, managing material handling equipment, reverse
logistics, work and resource management, etc.) processes.
Modern day warehouses also perform a set of value-added services like cutting, packaging, repairing, inspec-
tion, kitting, light assembly, labelling, etc.
Warehouse process maturity model defines the maturity of warehouse processes at three levels: basic, matured
and advanced. While ERP can support processes at all these three levels, depending on what level ERP system
is deployed, the particular ERP functionality will change.
ERP and information technology solutions can help in transportation management processes.
There can be different measures for measuring the efficiency of warehousing and transportation process in
different ways like: route optimisation, truck load building, transportation planning, network optimisation,
etc.

Exercise
I. Objective Type Questions
1. What is logistics execution? What are the processes included in this?
432 Enterprise Resource Planning

2. What are the different sub-processes under goods receipt in a warehouse?

3. What is meant by put-away?
4. What is slotting?
5. What is ABC slotting?
6. What is slotting optimisation?
7. What is picking?
8. What are the different picking methods?
9. What is wave picking and zone picking?
10. What are voice picking and light picking?
11. What is reverse logistics?
12. What are the typical value-added services for a warehouse?
13. What is kitting?
14. What is cross-docking?
15. What is track and trace?
16. How picking accuracy and picking efficiency are measured?
17. What is a milk run?
18. What is the difference between building optimum route and optimum load in transport?

II. Descriptive Type Questions

1. Explain the basic functions of a warehouse.
2. How WMS systems support different put-away process requirements?
3. Explain the slotting process. Explain the ABC slotting process and how ERP solutions support that? What
is slotting optimisation? How do warehouse management systems help here?
4. What is picking? Explain different picking methods and technologies like single order picking, multi-order
picking, wave picking, zone picking, voice picking, light picking, etc.
5. Explain the different value-added services that a warehouse can offer.
6. What is cross-docking? What are its advantages? How do technologies help in cross docking?
7. Explain the warehouse process maturity model. What are the basic, matured and advanced processes?
8. What are the different IT/ERP technologies used for effective management of warehouse?
9. What are the different key performance indicators by which a warehouse performance can be measured?
10. How transport management systems help today’s organisations? What are the typical complexities of trans-
port management today? How transport management helps to reduce cost and improve service?
11. Explain a typical transportation cycle for an organisation. How does ERP system help in this process? What
are the leading transport management solutions?
12. What are the different IT/ERP technologies used for effective management of transport?
13. What are the different key performances indicators by which transport performance can be measured?

III. Fill in the Blanks

1. 3PL stands for _______________ _____________ _______________.
2. WMS stands for _______________ _____________ _______________.
3. TMS stands for _______________ _____________ _______________.
4. Light picking is a _______________ picking technology.
5. Cross-docking needs close coordination between ________ and __________ shipments.

IV. State Whether the following Statements are True or False

1. Wave picking is a grouping of picking orders by a set of criteria.
2. Cross-docking is mostly used in oil and gas industry.
 Logistics Execution: Warehouse and Transport Management 433

3. Voice picking is a basic warehousing process.

4. Goods receipt is an advanced warehousing process.
5. Transport planning applications help in designing the most optimum route for transport.

V. Assignments
A. Study in details the warehouse management modules of following vendors and products:
SAP (SAP Warehouse Management System – SAP WMS and SAP Extended warehouse Management System
– SAP eWM)
Oracle (Oracle WMS)
Manhattan Associates (Manhattan WMS)
Note down all their modules and sub-modules. What capabilities do they offer? Draw similarities and differences
of their capabilities.
B. Study in details the transport management modules of following vendors and products:
SAP (SAP Transport Planning and Vehicle Scheduling – SAP TPVS and SAP Transport Management System
– SAP TMS)
Oracle (Oracle GLOG)
i2 (i2 Transport Planner)
Note down all their modules and sub-modules. What capabilities do they offer? Draw similarities and differences
of their capabilities.
 28
Customer Relationship
Management Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
CRM Benefits
CRM – Different Application Areas
Leading CRM products
SAP CRM
Oracle Siebel CRM

CUSTOMER RELATIONSHIP MANAGEMENT (CRM)

Customer relationship management (CRM) is a strategy for managing a company’s interactions with its
customers and sales prospects. Often CRM is equated with a software or technology. While it is true that
CRM involves using technology to organise and automate business processes related to sales, marketing,
customer service and technical support, it is not just about technology as it involves strategy and redesign of
business processes (often from the view of how this process can better serve the customer) with the overall
goal to find, attract, and win new customers, retaining those customers and finally getting feedback from
them to better design company’s product and customer-facing processes. In this process, CRM also reduce
the costs of marketing, sales and customer service. CRM uses people, processes, and technology to gain
insight into the behaviour of customers and this helps in improved customer service, improved opportunity
close rates, streamlined sales and marketing processes, reduced costs and increased share of customer and
overall profitability. CRM can bring together information from all data sources within an organisation (and
from outside the organisation, if needed) to give one holistic view of customer in real time. This allows
customer-facing employees in such areas as sales, customer support, and marketing to make informed
decisions on everything from cross-selling and up-selling opportunities to target marketing strategies to
competitive positioning tactics.
Today CRM is much more matured and broadened as a concept than from where it started, i.e. a name for
a new class of software by enterprise solution vendors. Today, it denotes a company-wide business strategy
embracing all customer-facing departments and involving people, processes, and technology to strengthen
bonding with those which matters most for an organisation, i.e. its customers.
 Customer Relationship Management 435

CRM market is growing rapidly and according to Forrester Research, a leading research organisation,
the spending in just technology component of CRM is expected to reach $11 billion annually by 2010.

CRM Benefits
Customer Relationship management applications can help companies in different ways. CRM can help
companies in different ways as shown in Figure 28.1 and described in detail below:
Higher productivity for the sales team: Productivity increases as all sales and marketing related
routine tasks are taken care of by the CRM application’s specific modules like Sales Force Automa-
tion (SFA). This helps the sales force as they need not spend time on administrative work and can
concentrate on what they are supposed to do, i.e. spending more time in actual sale.
Better cross-selling and up-selling opportunities: CRM increases cross-selling and up-selling op-
portunity. If a particular product is not available in stock, the company’s sales staff (or say, centre
staff) can immediately recommend the best possible alternate (cross-sell) or a premium product (up-
sell). These products are already profiled in CRM application and is available to the sales staff as a
ready-reckoner.

Fig. 28.1 CRM Benefits

Improved customer service and customer satisfaction: CRM field service application is targeted
at providing customers better customer service. Whether customers are really satisfied is reflected
in company’s loyalty scheme, data from which can be brought back to CRM application for further
analysis.
Better opportunity close rates: CRM solutions help in increasing the percentage of leads that are
converted to sales. CRM’s lead management and opportunity management capability helps in regular
436 Enterprise Resource Planning

tracking of all the leads, following up on the next set of action points, managing contacts more ef-
ficiently and thus, improving closure rate.
More focused customer targeting and focused marketing campaigns: CRM campaign management
helps in more targeted campaign based on particular consumer’s past purchase pattern and spending
potential. CRM has made the dream of “One to one marketing” a reality by using technology, i.e.
targeting individual customer with special product, special price and special promotion.
Reduced marketing, sales, support and service expenses: CRM applications like sales force automa-
tion and field service management can help in automating a lot of routine manual sales and marketing
activities and enable more self-service by customers themselves. If after calling to a call centre and then
following a set of FAQ, the clients themselves can solve the problem that they were facing with their
new item, then the field service engineer need not visit them and that saves money for the company.
Better profitability and revenue per customer: CRM analytics capability helps identifying a
company’s most profitable customers. This is important as for any company there are always some
customers who are more important than others. There can be specific strategy for targeting them, i.e.
specialised sales promotion offers. This can lead to additional revenue opportunities.
Increased customer retention and loyalty: CRM applications help better customer loyalty and repeat
business from the same customer. Some CRM applications have separate loyalty management module
and some others can be easily integrated with other loyalty systems. Customer retention is of prime
importance to every company today as companies had seen in the past that owning a new customer
is ten times more costly then retaining an existing customer.

CRM—Different Application Areas

While each CRM product is different and has its own features, Figure 28.2 shows some of the common
CRM application areas. These are discussed in detail below:

Fig. 28.2 CRM Application Areas

Sales Force Automation (SFA) Applications These applications are to help sales force in their
daily jobs and aimed at increasing their productivity. Generally a company’s sales force is distributed across
various regions where the company sales its products. Sales force need to remember or store contact infor-
mation of thousands of company’s existing customers and new prospects. They need to manage new leads
 Customer Relationship Management 437

and sales opportunities. Sales force also forecast the demand for company’s products for next period (say
next month or next week) and as they are closest to the ground, always their forecast is given maximum
weightage. They are also responsible for managing sales in their territory and responsible for tracking sales
performance. Based on sales performance, sales force is provided incentive/compensation. So typical
areas of sales force automation applications are:
Contact management: At the heart of SFA is a contact management system for tracking and recording
every stage in the sales process for each prospective customer, from initial contact to final disposi-
tion.
Lead management: SFA tools help in validating the leads, i.e. whether these are really serious op-
portunities and try to give them some score based on seriousness (i.e. most serious lead can be 5).
These tools also help in routing this lead to the right sales person and assigning to him.
Sales forecasting
Sales performance management: SFA applications also help in managing sales performance, sales
quota (Individual and team quotas) and sales incentives/commissions.
While SFA applications include traditional features for opportunity management, territory management,
sales forecasting and pipeline, workflow automation, quote generation, etc., newly emerging areas like Web
2.0 is getting popularity among SFA vendors.
Field Service Applications These applications typically helps in different after sales service functions,
i.e. helps managing installation, service, or repairs of systems or equipment, activities that are typically per-
formed at customer sites based on warranty, annual maintenance contract or other contractual agreements.
These solutions also support scheduling workforce, i.e. which worker should go to which customer site
and attend which type of equipment/problem based on worker’s availability and skill. Most of these after
sales service activities need some kind of spares, managing reverse logistics (i.e. bringing the equipment
from customer site to company’s own location for servicing, if required) and spare parts management are
also under the domain of field service. As companies need to manage a large number of mobile technicians
distributed across different customer sites, mobile solutions are increasingly becoming an important com-
ponent of field service applications and support employees work at client sites. Core capabilities of field
service applications are:
Filed service management: This include things like managing different service task list, monitoring
SLAs and service contracts, service invoicing, etc. Field service staff also need to have visibility to
the assets/installed base, i.e. where what equipment is lying.
Scheduling workforce: Field service applications help in scheduling workforce, i.e. which worker
should attend which customer for what type of service. This scheduling need to take workers’ avail-
ability, skill and all types of rules and constraints into account. The idea has come out with a cost
optimised schedule that ensures lowest cost of operation while keeping the desired service level. Some
of the advanced field service applications can even take technician’s current geographic position and
the most optimal route into consideration while scheduling, i.e. the technician can travel to a nearest
customer location from his current location and need to travel minimum distance to attend another
customer.
Managing spares/service parts: This include things like spare inventory visibility (i.e. where how
much spare is available), service parts/spares planning; tracking of defective parts, returned parts, etc.
Field service applications helps in managing and optimising service parts and managing forward and
reverse logistics of service parts.
Mobile solutions capability: These include things like supporting different field service essential
transactions through a set of mobile devices (like laptop, tablet PC, PDA, cell phones, Blackberry,
438 Enterprise Resource Planning

etc.). Field technician can be instructed on his mobile, technician can order spare parts needed to do
the particular task through his mobile device and can generate an invoice remaining in the customer
site through his device.
e-Commerce Applications These applications help companies to buy, sell, and do other transactions
over the web. Today, companies use these applications for a variety of purposes like product search/browse
(Example: to search for the cheapest airline ticket on the web), buying through shopping cart (Example:
buying books in Amazon.com where someone can put his orders in his shopping cart), product promotion,
personalisation, cross-sell and up-sell, product configurations, registries, multi-channel ordering, customer
self-service, etc. Today e-Commerce is becoming even more powerful with Web 2.0. As discussed, areas
where e-Commerce applications are increasingly becoming popular are:
e-Marketing: Using e-Commerce for online marketing for things like:
Campaigns: e-Commerce applications help in sending email and web campaigns
Cross-Sell/Up-sell: These applications helps in selling higher value products than what first
customer intended to buy (Up-sell) or sell similar products (Cross-sell)
Personalisation: These applications help in personalisation of company’s web pages, i.e. products
are displayed based on customer’s past buying pattern or his past likings.
Online ordering
Online product configuration
Online auctions
Online exchange and return
Online billing and payment
Call Centre/Contact Centre These solutions provide customer support by answering different types
of customer queries/calls and routing the calls to the most competent person who can handle it. These are
made possible by a variety of technologies like local area networks (LAN), automatic call distributors
(ACD), computer technology integration (CTI), web integration, interactive voice response, voice logging
and messaging, IVR/speech portals, etc. These applications help companies to automate customer service
inquiries through automatically identifying and segmenting callers, routing inquiries, and tailoring services
according to the customer profile and preferences. Today’s call centre solutions provide automated call
centre capabilities by enabling customers to use the keys on a touch-tone phone to access information such
as bank account balances (for a bank call centre), flight arrival and departure times (for an airlines call
centre), and package delivery status (for a courier company call centre). Call centres today are capable of
supporting complex customer interactions, such as scheduling service requests, providing technical support,
and handling financial transactions. Generally all call centres have features like
Predefined escalation route: Calls are automatically routed/escalated, if not answered within defined
SLAs (service level agreements)
Previous records of the caller: This is a standard feature of call centres today. As soon as the caller
calls, his contact details, his previous call history, previous self-service history, previous purchase
history, etc. are visible to the phone agent. In case the caller has a problem with a product that he
bought from the company, the agent already knows what product and model he bought with its detailed
specification and that helps him/her to sort out the problem from a problem database where perhaps
the same problem is already reported by another customer and for which solution is provided. This
also helps the caller to understand that whether already there is an AMC (annual maintenance contract)
with the customer and as per that what the customer is entitled to, i.e. whether the service should be
free or it needs to be priced.
 Customer Relationship Management 439

Support in different time zones in different languages: A basic requirement for most of the global
companies today.
Managing call assignments: This software can assign agents based on agent skills, availability, and
expertise. It can prioritise customer needs and match these to agents.
Knowledge Base: The content repository is the backbone of the call centre that help agents to solve
customers’ problems and helps in customer self-service (i.e. customers themselves can solve their
problem following a set of guided instructions). Call centre software helps in generating FAQ list au-
tomatically. This knowledge-base need to be available to the call centre agent at the time of customer
interaction. Some of the call centre tools provide exhaustive interactive search capability within this
content.
Self-service capabilities: Call centre software support self-service in areas that commonly generate
inquiries from customers, such as service, orders, and billing. The system prompts the user for ad-
ditional information to narrow down the possible problems and solutions. Some call centre software
supports interactive chat between the customer (caller) and the call centre agent for sorting out an
issue.
Workflow: Call centre applications have in-built workflow that ensures calls are escalated to right
authority, if not answered within the defined time, any price proposals made by call centre agents is
approved by appropriate authority, etc.
Reports and Analytics: These reports provide data on how the call centre is performing against SLAs,
the cost of running call centre operations, call centre employee productivity, etc.
While call centre (or phone contact centres) is the most common medium of customer service today,
service can also be provided through other channels like the kiosk, web, email, etc. More recently, e-Service
capabilities—web self-service, knowledge management, email response management, web chat, collaborative
browsing and virtual assistants are gaining importance.
Partner Relationship Management (PRM) Applications These applications help companies
to manage relationship with different channel partners and thus optimise sales opportunity. PRM solutions
can help in different important activities required for working with third-party selling partners like partner
recruitment and profiling, lead distribution and forecasting, taking partner orders, marketing promotion,
partner training, joint business planning, collaborative sales, reporting partner performance and all other kind
of partner service via the web. Important capabilities of partner relationship management software are:
Partner addition: PRM solutions can register and add new partners and can capture partner attributes
or other partner information.
Distributing leads: A company can distribute its sales leads to its partners, i.e. a customer when calls
the company with a product enquiry, the company gives this sales lead to one of its distributors to
take it forward. Company can track these leads at a later point (i.e. how many opportunities actually
got converted to sales, etc.)
Partner profiling: The solution helps in profiling its partners i.e. what type of partner it is.
Managing different partner programmes: PRM solutions support managing different partner pro-
grammes like loyalty programmes, marketing funds management, joint marketing campaigns, promo-
tions, etc.
Partner opportunity tracking
Special partner discounts and approvals: PRM solutions can propose special discounts for partners
based on their past performance. Such discounts need to follow special approval process.
Partner service: Solution supports the process of delivering different services of company through
partners.
440 Enterprise Resource Planning

Managing channel inventory/partner pipeline: Solution help firms track and manage inventory held
in the channel, and tracking and managing partner pipelines.
Enterprise Marketing Management (EMM) Applications These applications are used by
companies to manage their end-to-end process from gathering and analysing customer data across websites
and other channels, to planning and budgeting, to executing customer communications and measuring
results/effectiveness. It helps the enterprise identify and target its best customers and generate qualified
leads for the sales team. A key marketing capability is managing and measuring multi-channel campaigns,
including email, search, social media, and direct mail. Marketing automation also encompasses capabilities
for managing customer loyalty, lists, collateral, and internal marketing resources. As marketing departments
are increasingly obliged to demonstrate revenue impact, today’s systems typically include performance
management features for measuring the ROI of campaigns. These tools support an integrated approach to
marketing strategy, development, delivery, and measurement across the marketing mix. EMM applications
of today focus on processes like:
Campaign management: EMM applications help in managing campaigns and marketing commu-
nications for a company. This helps in campaign optimisation, i.e. suggests what offers should be
included in a campaign and what channels should be used to communicate and optimise the marketing
channel mix problem. These tools also help in designing campaigns/marketing programmes. EMM
tools maintain a list of prospect data to whom the campaign can be targeted, can capture campaign
response and can effectively manage recurring campaign programmes. These applications also help in
campaign execution and tracking across multiple channels (including direct mail, email, web/e-Com-
merce, telemarketing, inbound call centre, etc.).
Customer interaction management
Marketing planning: EWM applications can capture marketing goals, strategies, and metrics and
ensure alignment of marketing plans/programmes with marketing goals. This software can help in
forecasting and scenario planning.
Marketing resource and asset management: This software can help in marketing budget optimisa-
tion, i.e. how to most effectively allocate marketing budget. It manages budgets and costs of marketing
programmes. Advanced EWM applications can measure return on marketing investment and helps in
managing marketing events (like trade shows, seminars, etc.).
Opportunity/Lead management: This helps in managing deals and pipelines with the objective of
converting leads to opportunities. Leading EMM applications support tracking opportunities, including
features like competitive information and win/loss analysis.
Loyalty marketing: EWM applications incorporate tools for managing loyalty or points pro-
grammes.
Customer interaction management
Revenue and Pricing Management Applications These applications help companies to optimise
and manage prices throughout the product life cycle, including initial pricing, promotional, and markdown
or clearance pricing. Price optimisation solutions are used to analyse historical data and incorporate com-
petitive and market information to determine the price sensitivity of a product or a market segment. These
models are then used to generate the optimal pricing policy that helps in achieving a business goal like
maximising margin or improving market share. Price analytics solutions analyse market and historical data
and can provide price insights that might otherwise be hard to identify. Trends like an underperforming
market segment or an underutilised customer demand can be identified quickly based on which managers
can make decisions. These applications can have several sub-segments like:
 Customer Relationship Management 441

Trade promotion management: Tools for managing trade promotions with channel partners.
Promotions: Tools for managing different types of promotions like coupons, rebates, etc.
Pricing and promotion optimisation: Tools to assist marketers in optimising product bundling strat-
egy, product pricing, promotion mix, etc.
Product Configuration Applications These applications help customers to configure a product as
per their desired specification on the web (the good example is a Dell computer which can be configured
online). Based on this configuration, the company’s sales staff can quote and generate a price proposal
quickly. These applications can automate sales and product configuration, proposal configuration, cost esti-
mation and pricing and can compress the entire lead-to-order process. These tools are popular for complex
products and services.
Order Management Applications These solutions help organisations to manage the processes of op-
portunity to order receipt, order receipt to fulfillment, order fulfillment to cash and finally return processes.
These processes can not be addressed only by CRM applications, but through functionalities of ERP, CRM
and SCM applications. Today’s order management applications can accept order from different channels
like direct field sales, call centre, fax, kiosk, mobile device, etc. From opportunity to order receipt cycle,
CRM solutions has major roles to play in terms of opportunity and lead management, providing customer
multi-channel experience, product catalogue management, product configuration, pricing, rebates, quotation,
etc. Order fulfillment processes like demand planning, order promising, availability check, distribution and
logistics processes are mainly handled in SCM and ERP modules. After sales service processes like war-
ranty management, managing service spares, installation and repair, return and reverse logistics processes
are again handled in ERP.
CRM Analytics Sales analytics let companies monitor and understand customer actions and preferences
through dashboards that graphically display key performance indicators (KPIs). Marketing applications
generally come with predictive analytics to improve customer segmentation and targeting, and features for
measuring the effectiveness of marketing campaign. Marketing analytics help marketers to see which pros-
pects are most likely to transact. Marketing and finance personnel also use analytics to assess the ROI of a
sales campaign or a sales promotion programme. Customer service analytics are increasing in popularity
as companies demand greater visibility into the performance of call centres and other support channels, in
order to correct problems before they affect customer satisfaction levels. CRM applications support different
types of customer analytics and reports through dashboards, built in reports, custom reports, trend analysis,
historical comparison, graphics, drilldown, etc.
Leading CRM Products While there are more than hundred CRM products in the market, SAP CRM
and Oracle Siebel lead the pack. Microsoft is increasingly getting popularity for low cost and easy of use.
Table 28.1 shows 2008 market share of different CRM solutions.

CRM Product 2008 Market Share (%)

SAP CRM 22.5
Oracle Siebel 16.1
Salesforce.com 10.6
Microsoft 6.4
Amdocs 4.9
Others 39.6
442 Enterprise Resource Planning

SAP CRM SAP is the global leader in enterprise applications. SAP CRM product is used by approximately
3,000 companies comprising more than 800,000 users globally. SAP CRM is an integral part of SAP’s Busi-
ness Suite, providing end-to-end front-office and back-office support covering all areas of CRM functionality,
with strong capabilities in the areas of sales, marketing, partner channel management, and analytics. SAP
CRM is also integrated with SAP’s wide range of specialised ERP solutions for each industry.
Key capabilities of SAP CRM can be divided in three broad categories, i.e. customer engagement, busi-
ness transaction and customer service. These are discussed below.
Key Capabilities—Customer Engagement In the customer engagement phase of the customer interac-
tion cycle, SAP CRM supports following capabilities:
Marketing analytics: Includes market exploration, marketing planning, lead analysis, and campaign
planning and optimisation. Provides insight into market and customer characteristics, enabling the
planning and optimisation of marketing processes
Campaign management: Enables delivery of complete marketing campaigns, including planning,
content development, audience definition, market segmentation, and communications
Telemarketing: Facilitates lead generation and qualification through a variety of channels. Includes
list management and supports the execution of actual contacts
e-Marketing: Enables implementation and execution of personalised, real-time mass marketing over
the Internet. Starts with identifying, attracting, and differentiating target prospects, and continues with
interaction with prospects through customised content and products
Lead management: Allows development of new leads through lead qualification, routing, and track-
ing, delivering sales opportunities to opportunity management
Key Capabilities—Business Transaction In the business transaction phase of the customer interaction
cycle, SAP CRM supports following capabilities:
Sales analytics: Includes sales and profit planning, pipeline and sales funnel analysis, sales cycle
analysis, and sales organisation analysis, facilitating the optimisation of sales processes
Account and contact management: Enables monitoring and tracking of all relevant information about
customers and business partners
Opportunity management: Provides sales tracking and sales forecasting, identifies key decision
makers, and estimates potential-to-buy and potential closing dates
Telesales: Takes advantage of the Interaction Centre to manage inbound and outbound calls and sup-
port phone-based sales activities. Handles high call volumes and integrates sales information from
enterprise systems and product information from online catalogues
Field sales: Delivers key customer and prospect information to field sales representatives, facilitates
planning and maintenance of sales activities, provides activity reports, creates quotations, and takes
orders
Mobile sales: Supports the field sales force through mobile devices
Handheld sales: Enables efficient use of wireless devices
e-Selling: Provides comprehensive capabilities for selling products and services over the Internet.
Supports all phases of the sales cycle as well as sophisticated product selection, multimedia product
catalogues, advanced personalisation, online product configuration, convenient shopping-basket man-
agement, secure transactions, complete order-status checking, and payment processing and fulfillment.
Includes contract completion, intelligent web analytics, and a flexible web design
Internet pricing and configuration: Allows users to configure products online and compare prices
across catalogues and marketplaces. Includes shopping-basket functions
 Customer Relationship Management 443

Order acquisition: Supports order-acquisition and order-entry processes through product proposals,
quotations, tax determination, and availability checking
Key Capabilities—Customer Service In the customer service phase of the customer interaction cycle,
SAP CRM supports following capabilities:
Service analytics: Includes service status and pr ocess analysis, as well as service cost and profitability
analysis, which allow the planning and optimisation of service and support processes
Customer care and help desk: Supports all types of questions, complaints, and returns, with escala-
tion and workflow processing, as well as activities based on dedicated service-level agreements
Contract and installed-base management: Handles the history and details of customer installations
and contracts, including service-level agreements, warranty processing, and quality monitoring
Enterprise intelligence: Supports guided and interactive resolution of issues through sophisticated
search algorithms and intelligent agents
Field service and dispatch: Delivers and tracks customer and account information for field service
personnel, ensuring rapid and accurate customer service. Provides service planning and forecasting,
scheduling, and dispatching based on tight integration with fulfillment systems
Mobile service: Supports the field service force through mobile devices
Handheld service: Enables efficient use of wireless devices
e-Service: Offers customers, prospects, and business partners online access to dedicated information
such as product catalogue, content, pricing, and solutions. Enables online self-service functions such
as order entry and tracking requests
Oracle Siebel CRM Siebel was the undisputed market leader in CRM upto Year 2005 and one of the
first vendors to make CRM software popular in the enterprise market. Oracle had acquired Siebel Systems
in January, 2006. Siebel has more than 4,000 customers globally and close to 3 million users. Siebel 8.1.1,
the current version of the product has strong capabilities in almost every area of CRM functionality, with
specific strengths in sales, partner channel management, and customer analytics. The product also has strong
customer data management capabilities, eCommerce and customer service features.
Siebel Sales-Features
Account management: This provides a comprehensive, 360 degree view of customer, including service
history, order management, interactions, and account profile
Opportunity management: This includes management of leads, territories, opportunities, contacts,
and all account activities
Sales forecasting: This includes real-time insight into sales and employee performance
Order management: This allows to create quotes, proposals, and product configuration
Territory management
Siebel Marketing-Features
Knowing customer: Siebel CRM captures all vital customer data in one single, unified source to
give a 360-degree customer view. Once the customer is understood better, all marketing strategies and
programmes can be tailored to build loyal, long-term relationships.
Personalised campaigns and e-mail marketing: Siebel CRM e-mail Marketing helps in creating
personalised campaigns. Response rates can be tracked to measure, optimise, and analyse campaign
effectiveness.
Visibility into marketing initiatives: Siebel CRM give instant access to interactive marketing dash-
boards, closed-loop metrics, pre-built and custom analytics, and lead follow-up analysis. Recipients,
leads, opportunities, and closed revenue associated with each campaign can easily be tracked.
444 Enterprise Resource Planning

Siebel Service–Features Siebel CRM service is mainly targeted to improve the field service and post sales
service processes of an organisation. Typical areas of focus of this module are:
Customer service
Field service
Service analytics
Siebel Contact Center–Features
e-mail response: Automatically respond to customer email
Computer telephony integration: Provide caller information to agents automatically 22
Customer dashboard: Present a comprehensive view of critical information about a customer
Contact management: Provide agents with a complete history of all interactions with a customer
Workflow management: Route and track tasks throughout their lifecycles

Summary
Customer relationship management is a set of processes and technology to improve a company’s sales, mar-
keting and after sales service processes.
Main benefits of CRM are: Higher productivity for the sales team, better cross-selling and up-selling oppor-
tunities, improved customer service and customer satisfaction, better opportunity close rates, more focused
customer targeting and focused marketing campaigns, reduced marketing and sales expenses, better profit-
ability and revenue per customer, increased customer retention and loyalty, etc.
Ten different CRM application areas are discussed in this chapter and this include: Sales Force Automation
(SFA), Field service, e-Commerce, Call centre, Partner Relationship Management, Enterprise Marketing
Management, Revenue and pricing management, Product configuration, Order management and Sales-Mar-
keting-Service Analytics.
Features of two leading CRM application from SAP and Oracle is also discussed in this chapter.

Exercise
I. Objective Type Questions
1. What is customer relationship management (CRM)?
2. What is one to one marketing?
3. What is meant by “cross-selling” and “up-selling”?
4. What is “lead management”?
5. What is the concept of “Personalisation”?
6. What is partner relationship management?
7. What is campaign management? This is part of which CRM application?
8. What is opportunity or lead management?
9. What are revenue and price management applications?
10. Name some leading CRM software
 Customer Relationship Management 445

II. Descriptive Type Questions

1. Explain the concept of customer relationship management. How technology can help here? What are the
benefits of CRM?
2. What are the different application areas in CRM? Explain each one of them in brief.
3. What is sales force automation? How SFA applications help sales team in terms of opportunity management,
lead management, territory management, contact management etc?
4. What are the typical capabilities of field service applications? How do these applications help in scheduling
workforce, managing spares and managing field service?
5. How e-Marketing applications helps in sales and marketing?
6. What are the typical features of a call centre application? How call centres provide self-service capability?
How previous calls records help call centres to provide better customer service? How call centre knowledge
base helps in better problem solving for customers?
7. What are the typical capabilities of PRM application of the CRM software?
8. What are enterprise marketing management applications? How do these applications help in campaign
management, marketing planning, opportunity/lead management and managing loyalty?
9. How do revenue and pricing management applications help in price, revenue and promotion optimisa-
tion?
10. Explain the capabilities of product configuration applications and order management applications.
11. What are the different types of CRM analytics? Give some examples of sales, service and marketing analyt-
ics.
12. Explain the capabilities of SAP CRM.
13. What are the different modules of Oracle Siebel CRM? What are their key capabilities?

III. Fill in the Blanks

1. CRM stands for _______________ _____________ _______________.
2. PRM stands for _______________ _____________ _______________.
3. SFA stands for _______________ _____________ _______________.
4. CTI stands for _______________ _____________ _______________.
5. Partner profiling is part of _____________ applications.

IV. Assignments
Study in details the CRM capabilities of SAP CRM and Oracle Siebel CRM. Note down all their modules and
sub-modules. What capabilities they offer? Draw similarities and differences of their capabilities.
 29
Quality Management
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Quality Management
Quality management basics and how ERP supports quality process
ERP QM processes for procurement, production, sales and service
Quality management master data

QUALITY MANAGEMENT
Quality Management Basics and How ERP Supports Quality Processes
Designing products and services as per the specification and flawless delivery of the same to the customer
is the goal of every organisation. This has become more important in recent times for reasons like intense
competition and customers’ expectation for quality products. Increasingly, the line of difference between
manufacturing and service companies are blurring and every manufacturing organisation is providing some
kind of service as well and in most cases the service part is becoming a differentiator between two compet-
ing companies.
From a process perspective, a company needs to ensure quality in three areas:
Quality management in procurement: To ensure that it is getting right raw material from its suppliers
as per specification
Quality management in production: To ensure that products are produced within right specification
with minimum rejects
Quality management in sales and service: To ensure that products are delivered to customer as per
his satisfaction. Right quality after sales service is provided and if there is a failure of the product at
customer end within warranty period – the reason for the same can be tracked.
There are few terms which are frequently used in quality management world and it is important to un-
derstand them before we progress further in this chapter. Figure 29.1 shows some of these:
Material specification
Inspection plans and quality inspection
 Quality Management 447

Fig. 29.1 Quality Management Concepts

Sampling procedure
Statistical process control and control charts
Quality certificates
Quality notification
Quality manual and ISO 9000
Batch management and traceability
Quality audits
Quality costs
Calibration
Laboratory information management systems (LIMS)
Electronic signature
Material Specification These are the standard design parameters like length, breadth, width, weight,
chemical properties, etc. of a product. Sometime these are defined by customer and sometimes based on
the customer requirements the company decides it. Depending on the complexity of the product, material
specification can vary. For example, a simple consumer goods product like detergent powder can have simple
specification whereas a complex product like a commercial aircraft can have thousands of specifications
for its numerous components. The finished goods or service a company produces has its specification and
in the same way it also has specifications for the raw materials it uses from its suppliers to produce the
finished good. For an ERP system, material specification is a master data and generally maintained in the
material master.
448 Enterprise Resource Planning

Inspection Plans and Quality Inspection These are the methods and procedures of inspection.
While the raw materials are bought in factory, goods are manufactured in shop floor and before these are
delivered to customer, goods need to be inspected against specification. Any company will have a set of
inspection plans that defines how the goods should be inspected and which particular characteristics of the
product (Master inspection characteristics) need to be inspected. There are statistical tools to define optimum
inspection plans. Inspection plans and master inspection characteristics again are a set of master data for
ERP systems.
Quality inspection measures, examines, tests, and gages one or more characteristics of a product or service
and compares the results with specified requirements to determine whether conformity is achieved for each
characteristic. Quality inspection can have several steps like: Inspection lots creation, results and defects
recording, usage decision (i.e. whether to use the full lot or not), etc.
Sampling Procedure While inspecting the products, samples need to be taken and the sample need to
be representative for the whole lot as decisions are taken based on the sample inspection results that whether
to accept the whole lot or to reject. Again there are statistical methods for sampling that defines sampling
plans. Sampling procedures for different types of materials are master data for ERP systems. ERP systems
allow to plan and automatically generate samples at goods receipt or in production, i.e. the system indicates
the sampling sizes and associated acceptance or rejection criteria to be used. For example, SAP ERP supports
standardised sampling systems such as ISO 2859 (attributive inspection) and ISO 3951 (variable inspection)
and sampling plans according to ISO 2859-1 and ISO 3951.
Statistical Process Controls and Control Charts SPC is the application of statistical techniques to
control a process. Control charts were developed to differentiate systematic deviations from a target value in
a characteristic from unavoidable random fluctuations of individual measured values. The intent of a process
control plan is to control the product characteristics and the associated process variables to ensure capability
(around the identified target or nominal) and stability of the product over time. ERP supports various quality
control charts, capability indicators (cp, cpk), pareto analysis, trend analysis, and exception analysis. While
a process is in progress, ERP systems help in drawing continuous process control charts and can identify
which process variables are going beyond + / - 3-Sigma limits and going out of control.
Quality Certificates This is related to an inspection lot, a batch or a delivery, in order to document
that it meets the quality requirements. ERP systems support the creation of such certificates that may be
sent to customers. Outgoing certificates are usually created at delivery time. ERP systems also support
the management of incoming certificates, which are delivered together with supplied material. For certain
industries customer quality certificates are very common for example a customer buying steel may ask for
test certificate along with delivery and the certificate has information on the date of manufacture and all the
operating parameters under which the material is produced.
Quality Notification Quality notification is raised whenever there is a quality problem or qual-
ity issue. These can be non-conformities, defects, and failures that are related to products, processes, or
services. Notifications are a flexible tool for recording, processing, and monitoring all unplanned events
in an organisation, e.g. complaints against vendors, customer complaints, or internal problems. A quality
notification can be processed on two levels, at first level it involves defect analysis, i.e. the investigation of
the cause and the introduction of the necessary corrective tasks and activities (long-term), and at another
level there are immediate tasks and activities to provide short-term help. A quality notification may have
several details like:
 Quality Management 449

The problem definition

Tasks, i.e. things that must be done to take immediate remedial action
Details of the business partners (internal and external) who are affected by the problem
Short-term activities that were implemented
Long-term activities that was done to alleviate the problem permanently, i.e. corrective tasks that must
be performed, to prevent the defect from occurring again
Causes of the defects
Quality manual and ISO 9000 This is the process of documenting the quality system and quality
processes in an organisation according to some widely accepted international standards. ISO 9000 is one
such standard. In the automotive industry, ISO 9000 is supplemented by standards such as QS 9000, in the
food and drug industry, it is supplemented by so-called “Good Manufacturing Practice” (GMP) and other
rules. While the organisation need to define its quality systems and processes of its own, ERP systems offers
a variety of tools, such as knowledge warehouse or document management, to maintain a quality manual.
Batch Management and Traceability Batch management is a typical requirement of process in-
dustry (like chemical, petrochemical, oil and gas, etc). This is required if products may vary in quality or
if they originate from different production runs and this is common in process industry due to thousands of
process parameters like temperature, pressure, etc. ERP can provide identification, classification, and inven-
tory management for different batches of a material. Bottom-up as well as top-down analyses are offered in
order to show into which final products a batch of raw material has flown.
Traceability is useful for tracking the reasons, if there is a failure of the product, i.e. on which date un-
der what operating conditions the product was produced, what raw materials were used, what batch and lot
number and from which vendor the raw material was received, etc.
Quality Audits An audit is a systematic examination used to determine to what extent an object meets
previously specified criteria. Audit management means to plan and process audits, finalise audit objectives,
monitor corrective and preventive actions that are based on the findings, and analyse audit data. ERP system
support different types of quality audits like: system audit, process audit and product audit.
Quality Costs This includes different cost parameters like:
Quality appraisal cost: Cost associated with inspecting a product to ensure it meets the internal or
external customer’s needs and requirements.
Costs associated with providing poor quality products or services: There are two categories of costs:
Internal failure costs (costs associated with defects found before the customer receives the product or
service) and external failure costs (costs associated with defects found after the customer receives the
product or service).
ERP systems help in measuring these cost elements. Quality failure also costs on the reputation of the
company and it is difficult to quantify and measure this in ERP systems.
Calibration An important step of quality management process is all measuring gages need to be cali-
brated at regular interval to ensure accuracy of measurement. This includes the comparison of a measurement
instrument of unverified accuracy to a standard instrument of known accuracy to detect any deviation from
the accuracy specification. ERP systems support the complete calibration process, especially the calibration
inspection, in accordance with ISO standards. It supports the generation of equipment calibration orders
on a regular basis, it provides the calibration instruction, it enables results recording, and it can adjust the
status of the equipment depending on the inspection result.
450 Enterprise Resource Planning

Laboratory Information Management Systems (LIMS) These systems facilitate the testing of
samples that routinely pass through an analytical lab and manages the complete routine testing from sample
collection to testing to final reporting as per specific report formats to meet regulatory requirements. Generally
the companies have separate LIMS systems outside ERP to support laboratory processes. There are several
LIMS vendors operating in this space.
Electronic Signature ERP systems have the ability to capture electronic signatures at any point in the
execution of quality workflows. Electronic signatures can be used to capture incoming materials receipt and
inspection data. Once a incoming material is received, the person, who is doing the good receiving, can put
an electronic signature to authenticate that goods are as per quality specification and that can automatically
trigger workflow for next process.

ERP QM Processes for Procurement, Production, Sales and Service

ERP software support quality management processes during all stages as shown in Figure 29.2, i.e. at the
time of goods receipt, during manufacturing and finally during delivery. In this chapter, how ERP supports
these different stages are discussed in detail.

Fig. 29.2 Quality Management during Different Stages

QM During Procurement and Goods Receipt from Vendor Following quality management
processes are relevant while procuring and receiving materials from vendors
Quality inspection at goods receipt
Quality certificate at goods receipt
Vendor evaluation
Blocking of invoices/vendors based on quality inspection
 Quality Management 451

Appraisal cost calculation

QM standard reports
Quality Inspection at Goods Receipt Based on the settings in the quality management view of the
material master, ERP system creates an inspection lot at goods receipt and this specifies how a material is
to be inspected. An inspection lot can be created automatically or manually. After the inspection, results
recording is done and based on this usage decision (i.e. whether to accept the material or not) is taken. For
a certified vendor, there is no need of inspection lot during goods receipt.
Quality Certificate at Goods Receipt If a quality certificate is needed from the vendor for a particular
material, ERP system allows usage of the material only when the receipt of the certificate is confirmed.
Certificates can be received electronically using EDI (Electronic Data Interchange) or physically.
Vendor Evaluation Based on the usage decision of the material (i.e. whether the material is accepted
or rejected), a vendor’s quality score can be calculated. As shown in Figure 29.3, this quality score along
with other criteria like vendor’s price performance, delivery performance and service performance makes
up vendor’s overall score. Weightage is given to each criteria, criteria to be used and sub-criteria under that
can differ by company. However, quality, price, delivery and service are the most common criteria used
across industry.

Fig. 29.3 Vendor Evaluation

Blocking of Invoices/Vendors Based on Quality Inspection A vendor’s invoice can be blocked because
of a quality inspection as an inspection lot has been rejected. If there is continuous rejection from the same
vendor, the vendor itself can be blocked.
Appraisal Cost Calculation ERP systems can calculate the costs of quality inspection through creation
of quality orders where labour cost of inspection of raw materials is updated and calculated
QM Standard Reports ERP systems can provide lot of standard reports on defects, inspection lots,
inspection results, etc. either from the vendor view or from the material view.
452 Enterprise Resource Planning

When a raw material did not pass inspection, ERP systems can also configure a workflow to automati-
cally alert their supplier of the non-conformance. Suppliers can also view the status of their supplies through
supplier portals, an out of box add on for most ERP systems.
QM in Sales and Service Following quality management processes are relevant for sales and ser-
vice
Delivering material as per customer’s quality specification
Quality certificates
Batch tracking
Batch determination
Quality inspection for delivery
Return and complain handling
Delivering Material as per Customer’s Quality Specification This means in “make to order” (MTO)
cases, the characteristics required by the customer are specified in the sales order and these characteristics
need to be inspected during production. When goods are shipped, a certificate can be included to document
that the goods comply with the customer specification. In “make to stock” (MTS) cases as the products are
manufactured and inspected according to company’s own specifications and kept ready before the customer
order comes. When the actual customer order comes, the batch determination procedure tries to find out which
available batch meets customer requirement. Say, the customer had asked for a steel plate with 5% carbon,
a search is made among all available plates that which one has 5% carbon, and the available selected plate
is assigned to customer order. An additional inspection can be performed for the delivery. When goods are
shipped, a certificate can be included to document that the goods comply with the customer specification.
Quality Certificate ERP systems helps in creating quality certificate as requested by customer based on
customer information (who has to receive the certificate), inspection lot for which the certificate is created,
inspection results and data on customer defined characteristic. Certificate creation usually takes place when
the goods are shipped and can be triggered automatically. The data relating to individual characteristics,
which has been defined in the certificate profile is copied into the certificate.
Batch Tracking ERP systems provide a “Batch where-used list” that helps to identify which batches were
actually used in the production process. The where-used list tracks the batch. In addition, links between
batches across all manufacturing levels through to the sales order are logged, i.e. batch tracking can relate
sales order, the corresponding production order together with the material documents. If this is a customer
complaint, the batch tracking can identify on which day, from what raw material it is produced.
Batch Determination At batch determination, a batch can be found corresponding to the criteria speci-
fied. If someone tries to find a suitable batch with particular characteristics, the system searches the entire
batch master record with the same characteristic values and if the characteristics match, the system compares
the ‘actual values’ for the batch with the ‘target values’. For example, in the earlier MTS example, as the
customer is looking for a steel plate with 5% carbon, the system searches all the steel plate batches, and if
there is a match, the system identify that batch. This functionality of ERP is useful for checking availability
of material as per customer requirement.
Quality Inspection for Delivery Quality inspections are done before goods are issued for delivery to
customer. The quality inspection for a delivery is necessary to check the quality of a material or product
before it leaves the premises of the manufacturer or vendor to ensure that the goods are in perfect condition
before they are sent to the customer. Based on the settings in the ERP system, there can be an automatic
 Quality Management 453

generation of inspection lot for the delivery items relevant for inspection. The inspection lot is a request to
the quality assurance department to inspect the goods. If the goods are damaged, defect records can be cre-
ated. The inspected goods are accepted for use, or rejected. After successful inspection completion, goods
issue can be posted in ERP system and goods can be despatched.
Returns and Complaint Handling ERP systems handle this through creation of quality notification
for the customer complaint. A notification is created with detailed description of the customer problem.
Sometime tasks against notification is created to give immediate help to the customer (for example, issue
a credit memo, trigger a substitute delivery etc.) or if the customer wants to return the delivered goods, a
repair order is created for the returned goods. A detailed defect analysis is performed on the returned goods
to enter the defects in the notification and the result of the defect analysis is used to decide which corrective
tasks are required. If goods are returned, an inspection can be performed at their receipt. Different follow-up
functions can take place, depending on the result of the inspection.
QM in Production Following quality management processes are relevant for production:
Inspection during production
Statistical process control
Test equipment calibration
Inspection During Production When an order is released in shop floor, an inspection lot can be created
automatically in the ERP system based on system setting for an inspection during production. Any defects
can be recorded. Inspections can be time-based (Characteristic 10 is to be inspected every hour) or quantity
based (Characteristic 10 is to be inspected after every 50 pieces that are manufactured).
Statistical Process Control (SPC) This allows monitoring, controlling and improving processes. The
most important statistical methods are: Control chart, process capability analyses (such as, Cp and Cpk)
and sample evaluations (such as run-chart). ERP systems help in creating such control charts during pro-
duction.
Test Equipment Calibration ERP systems help in calibration planning and processing.

Quality Management Master Data

ERP systems need a set of master data for functioning. Some of the important ones are:
Inspection method: An inspection method describes how the inspection is to be carried out for an
inspection characteristic.
Material specification: The material specification defines the characteristics of the material and can
be used for quality inspection.
Master inspection characteristic: This is an inspection characteristic that is to be evaluated for all
inspection plans. Master inspection characteristics improve and standardise inspection planning.
Catalogues: These are used to define, manage, and standardise information (for example defect
types) consistently. This helps in recording and evaluating qualitative data and describes objects. In a
catalogue, information is assigned a unique alphanumeric code and an explanatory text. For example,
in a catalogue there can be defect code for each type of quality issue of a material, say damaged item
has a code of 01, cracked item has 02, etc.
Sampling procedure and sample scheme: This defines how sampling will be done for a material.
There can be different ways of sampling: Manually, percentage (of the whole lot), with reference to
a statistical sampling plan, etc.
454 Enterprise Resource Planning

Summary
In this chapter we discussed the principles of quality management and how ERP systems can help in that.
Quality management is important from three perspectives: To ensure right raw materials are procured, i.e.
during incoming material quality inspection stage, to ensure that products are produced to right specification,
i.e. during manufacturing stage and to ensure that right products are despatched, i.e. during sales and service
stage.
Some of the quality management concepts discussed in this chapter are: Material specification, inspection
plan, sampling procedure, statistical process control, control charts, quality certificates, quality notification,
quality manual, ISO 9000, batch management, quality audits, quality costs, calibration, laboratory informa-
tion management system and digital signature.
During incoming material quality inspection, ERP systems support quality inspection at goods receipt, vendor
evaluation, blocking of invoices/vendors based on quality inspection, appraisal cost calculation, etc.
During manufacturing, ERP systems support: Inspection during production, statistical process control and
test equipment calibration.
Finally during sales and delivery, ERP systems support: Quality certificate creation, batch tracking, quality
inspection for delivery, and return and complain handling.
Important master data for quality management module in ERP systems are: Inspection method, material
specification, master inspection characteristic, catalogues, sampling procedure and sample scheme.

Exercise
I. Objective Type Questions
1. What are the three processes important from quality management perspective?
2. What is meant by material specification?
3. How inspection plans can be defined?
4. What is sampling procedure?
5. How statistical process control can be defined? How does ERP help in this?
6. What is quality certificate?
7. Define quality notification.
8. What is quality audit?
9. What are the different elements of quality cost?
10. What is calibration?
11. What is quality certificate?
12. What is meant by appraisal cost calculation?
13. What is batch tracking?
14. How batch determination is done?
15. How return and complain handling is facilitated by ERP?
16. What are the different master data in ERP quality management?
17. What are catalogues?

II. Descriptive Type Questions

1. Explain different quality management processes. How does ERP support these different quality processes?
 Quality Management 455

2. What is the typical procurement and goods receipt processes that need quality management solutions from
ERP? How does ERP help in quality inspection during goods receipt, quality certificate and vendor evalu-
ation?
3. What are the areas of quality management in sales and service? How does ERP help in sales and service?
What is batch tracking and batch determination? How does ERP support that? How return and complaint
handling is handled in ERP?
4. What are the areas of quality management during production? How does ERP help in process inspection,
statistical process control and test equipment calibration?
5. What are the quality relevant master data? Explain different QM master data like material specification,
master inspection characteristics, catalogues and sample procedure?

III. Assignments
Study in details the quality management modules of two leading ERP solutions, i.e. SAP and Oracle. Note down
all their modules and sub-modules. What capabilities do they offer? Draw similarities and differences of their
capabilities.
 Maintenance
Management and
Enterprise Asset
Management
30
Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Maintenance Management
Maintenance management basics
How ERP systems help in maintenance management
Master data needed for maintenance management in ERP system
Emerging Area—Enterprise Asset Management
Enterprise asset management
Difference between ERP and EAM

MAINTENANCE MANAGEMENT
Maintenance Management Basics
Maintaining equipment in order and keeping their uptime high is a need for all manufacturing and asset-
intensive companies (like airlines, transport companies, utility companies, etc.). ERP systems are used
extensively these days for managing maintenance.
Maintenance can be simply defined as: “All activities that maintain facilities and equipment in good
working order so that a system can perform as intended”.
Benefits of having good systems and processes for maintenance is obvious and are as follows:
Avoid production disruptions
No additions to production costs
Avoid missed delivery dates and better customer satisfaction
Better employee safety
Breakdown of a machine can have several impacts to an organisation like:
Production capacity is reduced and orders are delayed
No production, so overhead continues and cost per unit increases
Quality issues and product may be damaged
Safety issues–Injury to employees, injury to customers
 Maintenance Management and Enterprise Asset Management 457

Typically maintenance activities are divided into two main types:

Breakdown maintenance: This is a reactive approach, i.e. dealing with breakdowns or problems when
they occur. Breakdowns and malfunctions typically occur when equipment is in use so this obviously
results in loss of productive time of the machine.
Preventive maintenance: This is a proactive approach, i.e. reducing breakdowns through a programme
of lubrication, adjustment, cleaning, inspection, and replacement of worn parts. In this case, inspections
are performed at regular schedule and before equipment fails. Typically maintenance is also performed
during idle periods. Here, the goal is to reduce the incidence of breakdowns or failures of equipment
to avoid the associated costs. Preventive maintenance is generally periodic and performed:
As a result of planned inspections
According to defined calendar
After predetermined number of hours
Figure 30.1 explains three types of preventive maintenance:
Time-based: Preventive maintenance work is due at specific intervals (for example, in every sixth
months, a part need to be lubricated).
Performance-based: Preventive maintenance work is due when a specific performance level has been
reached (for example, an aircraft part need to be replaced after every 50000 km of flying).
Condition-based: Preventive maintenance work is due when a condition is outside of a specific value
range (for example, cooling of a part is needed when temperature reaches 85° C).

Fig. 30.1 Types of Preventive Maintenance

There can be several variations of preventive maintenance like:

Predictive maintenance and condition monitoring: Here, the condition of the equipment is monitored
on continuous basis and whenever the equipment shows behaviour of particular parameter beyond
the limits (say, high vibration of particular part of a pump), it plans a preventive maintenance for the
equipment. Thus, condition monitoring attempts to determine when it is best to perform preventive
maintenance activities.
458 Enterprise Resource Planning

Total productive maintenance (TPM): This is a just in time approach of preventive maintenance
where workers perform preventive maintenance of the machines they operate. This can range from
maintaining a scheduled checklist of items to all round maintenance.
Optimum Level of Maintenance Though preventive maintenance can reduce the cases of breakdown,
it will be never become zero as even with best preventive maintenance there will be cases of breakdown. It
is important to find that what level of maintenance is optimum as beyond that level, preventive maintenance
may not provide return. It is important to find that optimum level of preventive maintenance. Figure 30.2
explains the concept of optimum level of preventive maintenance.

Fig. 30.2 Optimum Level of Preventive Maintenance

More preventive maintenance = Higher costs for preventive maintenance

Less preventive maintenance = Lower costs for repairs
There is an optimum level W0, at which the total cost of maintenance is minimised (in economic terms,
the total cost minimum). This curve applies to each maintenance plan, i.e. companies need to look for this
optimal point while designing maintenance plan, as beyond this too much maintenance may not provide
adequate return.
How ERP Systems Helps in Maintenance Management
ERP systems provide following functionalities for effective managing of maintenance functions for an or-
ganisation as shown in Figure 30.3. These are discussed below.
Managing preventive and predictive maintenance: ERP enables companies to plan preventive and
predictive maintenance activities, based on time, counter, condition, or risk.
Maintenance planning and scheduling: It lets the organisation schedule individual maintenance
tasks and allocates required resources, tools, and materials, and plan shutdowns for large-scale main-
 Maintenance Management and Enterprise Asset Management 459

Fig. 30.3 ERP Maintenance Management Functionalities

tenance projects. This also involves managing task lists, supporting different preventive maintenance
planning strategies (like time-based, performance-based, etc.). Sometimes, scheduling and execution
of maintenance tasks may involve material availability check, getting necessary permit for doing a
specialised type of maintenance activity, etc.
Maintenance catalogues: ERP systems help to build a detailed catalogue of reasons of failure for
every equipment. Every failure can have a particular code like for a pump, it can be failure of bear-
ing (Code: 01), failure of shaft (Code: 02), failure due to corrosion (Code: 03). These failures can be
later grouped to code groups like all mechanical failures are under mechanical failure code group (say,
Code Group: A), all electrical failures can be under electrical failure code group (say, Code Group:
B). Several such code groups can make a catalogue. The advantage of such a coding system is the
reason for any failure can be analysed later and this reduces the chance of errors.
Catalogue: Combination of code groups, grouped together according to content (for example,
damage and cause of damage).
Code groups: Combination of code groups, grouped together according to content (for example,
damage to vehicles, pumps, motors) or mechanical damage and electrical damage.
Codes: Description of damage and activity.
Maintenance order management: For any maintenance need, either preventive or breakdown, a
maintenance order need to be created. If maintenance activity needs specific spare parts or consum-
460 Enterprise Resource Planning

ables, these need to be issued against this work order. This order need be assigned to a technician
who will perform the maintenance activity. Finally when the maintenance task is over, the order need
to be closed with details like which materials got consumed in the maintenance activity (material
consumption) and how many hours of technician’s hour got consumer for this (labour consumption)
and based on these inputs the order need to be costed.
Managing maintenance task list: Maintenance task lists describe a series of individual maintenance
activities. This can be used to standardise recurring activities, plan them more effectively, and save
time when creating maintenance orders and maintenance plans. In the plant maintenance system,
maintenance task lists can be used for routine and preventive maintenance work. Task lists also specify
which spare parts and tools are required for operations and the time needed to perform the work. If
maintenance task list is created, maintenance orders and maintenance plans can be created very easily,
since it refer to the operations and processes already entered in the maintenance task list. Maintenance
task lists contains:
A list of operations that need to be performed in particular sequence for the scheduled preventive
maintenance
Material components needed for the preventive maintenance activity
What tools are needed to carry out the scheduled maintenance
Maintenance cost planning/budgeting and budget tracking: ERP enables companies in yearly
maintenance budgeting exercise, i.e. how much a company should budget in financial terms towards
maintenance expenses for the next year. ERP systems also help in tracking the budget, i.e. how much is
spent as on date against the yearly budget. This process can track planned and unplanned maintenance
activities.
Refurbishment: Refurbishment of equipment is a common requirement in which a set of maintenance
activities are performed on an equipment to bring it to nearly new condition. Any refurbishment activity
performed can influence the overall stock value of the equipment. Most of the leading ERPs support
refurbishment.
Managing work permits: There are some particular types of maintenance activities that can be done
by trained and certified people. For example, someone doing boiler maintenance needs special per-
mission and permit from few certified bodies. ERP systems ensure a permit-to-work system to ensure
that only certified staff is allocated to do particular type of maintenance.
Managing warranties: A warranty is a binding commitment to the customer to provide services, partly
or fully without cost, for a specified period of time, or for the specific life of an individual device.
There can be warranty on any number of pieces of the equipment. For example, for a fork lift trolley,
there can be separate warranty for its batteries, for its wheels and for other parts. ERP systems help
in managing warranties. Each part and equipment can have different warranty period within which
things can be replaced. In case of a company dealing with hundreds of equipment and thousands of
parts, it is almost impossible to keep a manual tracking. An ERP system helps in keeping this tracking
so that the company unnecessarily does not pay for a part, if it is already covered under warranty.
Interfacing maintenance systems to GIS (geographical information system): Leading ERPs today
provide interfaces with GIS system. This helps in locating the geographical position of equipment. This
can be really helpful a company supplying power in a large city and to locate the equipment which is
faulty and then guiding maintenance staff to reach there to repair it.
Interfacing maintenance systems to SCADA (supervisory control and data acquisition) systems:
Leading ERPs today provide interfaces with shop floor process control systems or SCADA (supervisory
control and data acquisition) systems that sends continuous data on the condition of the equipment
and can help in condition monitoring.
 Maintenance Management and Enterprise Asset Management 461

Reports and KPI support for Plant maintenance: Plant maintenance supports different maintenance
related analytics and key performance indicators like meantime to repair (MTTR), meantime between
failure (MTBF), meantime between repair (MTBR), etc. This also provides various failure analytics
like reasons for failures with cause codes, etc.
Maintenance manager’s dashboards: ERPs these days provide such dashboards that display all key
performance indicators in one screen to examine at a glance any maintenance related problem area
and from there the manager can drill down to detail, if needed.
Serial number tracking and tracing: Machines can have huge number of components and each
identified by serial numbers. Serial numbers are important in case the machines are dismantled, to put
it back and for reasons like tracking of parts during its life cycle, when parts are repaired, refurbished
or changed. ERP software can keep this tracking.
Maintaining an asset registry and repair parts database: Its important to keep a database of equip-
ment/assets and parts/spares that a company is holding at any point of time. This is important from
accounting perspective for asset valuation and to do a quick where used check, i.e. which part is used
in which machine. This is typically a master data in ERP system.

Master Data Needed for Maintenance Management in an ERP System

ERP systems need a set of maintenance specific mater data for managing maintenance operations. These
are shown in Figure 30.4 and detailed below:

Fig. 30.4 ERP Maintenance Module Master Data

Equipment Master These are the list of machines with all specific details like make, year of instal-
lation, supplier, rated capacity, operating capacity, etc. Sometimes, this master is also called asset master.
This is the most basic master in ERP maintenance management module.
Spare Master Master of spares can run into thousands of items depending on the size of manufacturing
operations of a company. This can contain details like spare specification, possible source of supply, supply
lead time, approximate prices, etc. These are very critical information and, especially for imported equipment
spares and spares that can only be sourced from particular OEM (Original equipment manufacturer).
462 Enterprise Resource Planning

Documents and Technical Drawings This helps the maintenance engineer to quickly understand
the machine components and refer the drawing while repairing a failure. Drawings are stored in separate
document management system of ERP.
Address/Partner This provides the details of who supplied the equipment and its parts. This can be
helpful while ordering a spare part for the equipment in case of failure.
Permits Whether the equipment needs a permit to repair. As discussed earlier, some equipment like boiler
may need a permit or operator license from particular authority to maintain. This is also a master data element
and typically an area of integration between maintenance management and ERP human resource module.
Measuring Points/Counters Measuring points are physical and/or logical locations at which a par-
ticular condition is described. For example, the number of rotations per minute of the rotary blades of a
rotating equipment of a power station. Counters are resources that enable to represent the wear and tear of
an object or the consumption or reduction in its useful life. For example, the mileage indicator of a motor
vehicle. Measurement or counter readings can be entered for each object to be maintained. This is helpful
for cases like a roller need to be replaced after every 50000 rotations. These details need to be maintained
in the equipment.

Enterprise Asset Management

Enterprise Asset Management systems (EAM) are the applications that take plant maintenance to the next
level and support managing the entire life cycle of assets instead of just maintenance. These solutions are
popular for capital-intensive industries like mining, oil and gas, defence, utilities, transport, etc. For sup-
porting the entire life cycle of assets (from purchasing to retirement), EAM applications also have other
modules beyond plant maintenance. Figure 30.5 shows the modules of EAM application. The Gartner Group
defines EAM as follows:
“EAM consists of asset management, materials management, HRMS and financials”

Fig. 30.5 Enterprise Asset Management Areas

For lot of asset-intensive companies, EAM product alone meets their requirement and they need not buy
another ERP application. That’s why EAM products also include some of the conventional ERP modules
like HR and Material management.
Figure 30.6 explains different types of asset intensive industries and different stages of an asset manage-
ment life cycle.
Asset Management Life Cycel
Fig. 30.6
Maintenance Management and Enterprise Asset Management 463
464 Enterprise Resource Planning

An EAM system goes beyond ERP Maintenance management module and has advanced functions that sup-
port critical areas affecting asset management. For example:
Mobile asset management: A machine can break down at any point and this need to be informed
immediately to the concerned technician wherever he is. Leading ERP solution vendors today provide
mobile integration in maintenance management area through which a message can be sent to concerned
technician’s mobile immediately, the detailed maintenance work order or instruction can be sent to
technician’s PDA so that he can start his work immediately. Once his work is over, the operator can
update time and material consumption in his mobile device, which later can be synchronised with
backend ERP system.
Asset tracking with RFID: Expensive equipment and assets need to be tracked during their entire life
cycle. ERP vendors are building capabilities in this area of late with technologies like RFID. This is
common in container industry today where companies wants to track where the containers are lying,
in port or in transit. If it is on transit, then on which ships, etc.
Asset compliance: This process helps companies comply with statutory regulations and company
standards for their materials and products regarding health, safety, and the environment. There can
be specific compliance standards for particular assets like a chimney should not do carbon emission
beyond a particular limit, or a furnace can produce ash only within a limit.
Asset life-cycle costing: This process enables a company to track all asset-related costs over the entire
life-cycle from installation to operation through all major and minor repairs and finally up to retire-
ment.
Reliability engineering and reliability centred maintenance (RCM): This process used to determine
the maintenance requirements of any physical asset in its operating context. Therefore, it is important
to know, what the functions are associated with performance standards of the asset in its present
operating condition and in what ways does it fail to fulfill its functions. What causes each functional
failure, what happens when each failure occurs, what can be done to predict or prevent each failure?
EAM systems support reliability centred maintenance functionalities, a typical gap area for ERP
maintenance management module, a route cause analysis of each failure.
Workforce and human capital management: Typically offered as part of standalone EAM software
as EAM is an area which need interface with human resource module for several areas like updating
skill of the employee (to do a particular maintenance job), to allocate a maintenance work to an em-
ployee, costing of maintenance order (labour costing part), etc. Most of the standalone EAM vendors
like Maximo and Mincom offer a full-fledged HR module as part of their offering.
Inventory management for assets, spares, etc.: Again a module for standalone EAM software to do
all inventory management transactions (issue and receipt of spares, inventory accounting) and inven-
tory valuation.

Difference of ERP-based Maintenance System and EAM

Table 30.1 shows how ERP and EAM vendors differ in terms of asset management capability.
 Maintenance Management and Enterprise Asset Management 465

Table 30.1 Asset Management Capability of ERP and EAM

Functions and Features ERP-based Maintenance Enterprise Asset

Management System Management
Database structure and hierarchy
Repair parts availability checking
Technician availability planning
Purchase requisition for spares
Preventive maintenance scheduling
Maintenance cost tracking
Inception recording and tracking
Standard and exception reporting
Maintenance administration
Predictive maintenance analysis
Whole life asset care
Physical asset risk management
Reliability-centred maintenance
Root cause analysis
Asset life cycle costing
Strategic planning for asset management
Mobile asset management
Asset tracking with RFID

It is evident from the table that EAM vendors have better asset management capability when compared to
ERP vendors. However, ERP vendors may score better in several other areas (like sales and distribution,
production management, etc.). For several asset-intensive companies where asset management is the major
focus, they go for EAM solution as these are smaller products compared to ERP, so easy to handle and meet
their deep asset management capability requirements.
However, of late, leading ERP vendors like SAP is adding deep asset management functionalities in its
portfolio and closing the functionality gap with EAM vendors. SAP currently renamed their plant mainte-
nance module of ERP to Enterprise Asset Management and incorporated best of breed EAM functionalities
in the same.
Major EAM Vendors As per Gartner’s “Magic Quadrant for Enterprise Asset Management, 2007”,
leading EAM vendors are:
IBM’s Maximo Solution
Mincom
IFS
Infor
IBM’s Maximo is the undisputed market leader in EAM space for several years and having several
implementations in asset-intensive industries. Some of the EAM solutions like Mincom started as a mining
industry-specific ERP and then grown into a full blown EAM application.
466 Enterprise Resource Planning

Summary
In this chapter the importance of maintenance management and the kind of functionalities ERP solutions need to
have to support effective maintenance management requirement.
ERP Maintenance management module offer functionalities like maintenance planning and scheduling,
catalogue, maintenance order management, maintenance costing/budgeting, refurbishment, work permits,
warranty management, serial number tracking, etc.
EAM, a class of application specialising for advanced maintenance requirements and asset management is
also discussed in this chapter with their differences with ERP applications.
EAM offers specialised functionalities like mobile asset tracking, asset tracking, asset compliance, reliability
management, asset life cycle costing, etc.
Increasingly, the difference between ERP and EAM applications are blurring as leading ERP vendors are
building advanced asset management capabilities to close the gap and making them more relevant for asset-
intensive industries.

Exercise
I. Objective Type Questions
1. What are the two types of maintenance?
2. What is preventive maintenance?
3. What is breakdown maintenance?
4. What are the three types of preventive maintenance?
5. What is predictive maintenance?
6. What is TPM?
7. What are maintenance catalogue? How does it help?
8. What is maintenance order?
9. What is refurbishment?
10. What is SCADA?
11. What can be the typical KPIs for a maintenance manager?
12. What is serial number tracing and tracking? How is it helpful?
13. What is repair parts database?
14. What is equipment master and spare master?
15. What is permits?
16. What is measuring points/counters?
17. What is EAM?
18. What is RCM?
19. What is mobile asset management?
20. What is asset tracking and asset compliance?
21. Who are the major EAM vendors?

II. Descriptive Type Questions

1. Why maintenance management is important for an organisation? Explain the concept of preventive and
breakdown maintenance. Explain different types of preventive maintenance. Explain the concept of condi-
tion monitoring and TPM.
 Maintenance Management and Enterprise Asset Management 467

2. Explain the concept of optimum level of maintenance and how is it determined?

3. How ERP systems help in maintenance management? Explain different capabilities of ERP maintenance
management module in brief.
4. How do ERP systems help in planning and scheduling maintenance? What is maintenance catalogues and
how does it help in analysing reasons for failure?
5. What is the function of maintenance order in ERP systems? How do ERP systems help in managing dif-
ferent maintenance task lists? How can maintenance budgets be managed in ERP systems?
6. What is refurbishment? How do ERP systems help here? How do ERP systems help in managing warranties
and work permits?
7. How can businesses benefits by interfacing ERP system with GIS and SCADA?
8. What are the typical reports and KPIs provided by maintenance management module of ERP systems?
9. What are the typical master data a company needs to maintain for implementing ERP Maintenance manage-
ment?
10. What is enterprise asset management? What are the capabilities of EAM? How does EAM support mobile
asset management and asset tracking?
11. What is the difference between EAM and enterprise-based maintenance systems?

III. Fill in the Blanks

1. Preventive maintenance can be of three types: __________ based, ____________ based and _________
based.
2. TPM stands for _______________ _____________ _______________.
3. RCM stands for _______________ _____________ _______________.
4. Maintenance catalogue is a combination of _______ ______.
5. SCADA stands for _____ _______ ________ ______ _________.
6. MTBF stands for ________ ________ __________ _________.
7. MTBR stands for ________ ________ __________ _________.
8. MTTR stands for ________ ________ __________ _________.
9. EAM stands for _______________ _____________ _______________.
10. __________ is a common technology for asset tracking

IV. Assignments
Study in details the maintenance management modules of two leading ERP solutions (i.e. SAP and Oracle) and
enterprise asset management solution from leading EAM vendor Maximo. Note down all their modules and sub-
modules. What capabilities do they offer? Draw similarities and differences of their capabilities.
 31
Product Lifecycle
Management Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
Why Product Lifecycle Management – Business Drivers and Value Proposition
Different Phases of Product Life Cycle – Information and Application for Different Phases
Difference of PLM with ERP
PLM Functionalities – Core and Advanced Functionalities
Product Safety and Environmental Compliance – An Emerging Area of PLM
PLM Vendors

INTRODUCTION
Product lifecycle management (PLM) is a new set of enterprise application that manages all data and informa-
tion about a product from its initial conception to retirement. Product lifecycle includes conceptualisation of
the product, design, manufacturing, ensuring quality of the product throughout its lifecycle, ensuring product
safety during its manufacturing, distribution and usage and finally service from concept to development
to till the product retires from service. There can be product of extremely short lifecycle of few days like
Christmas card (and lot of food products like milk) and products of or long lifecycles (like airplanes) for
several years. PLM manages creation, storage, change, version, and configuration of all the data, informa-
tion, and relationships required to build, maintain, and support the product.
So, PLM is designed to create, manage, and use product data through its lifecycle across the enterprise.
It also enables its movement through the lifecycle by supporting collaboration and process automation.

PLM is a Cross Functional Process

As a process, PLM processes are cross-functional, needing participation from several disciplines like R&D,
engineering, manufacturing, marketing and service, etc, where engineering and R&D design the product,
manufacturing makes it, marketing sell the product and give inputs on it and finally service department
provides all after sales service of the product throughout its life including all complains handling about the
product.
 Product Lifecycle Management 469

WHAT IS PRODUCT LIFECYCLE MANAGEMENT—BUSINESS

DRIVERS AND VALUE PROPOSITION
Business Drivers for PLM
Today’s business is facing increased challenge on product front. Improved management of product informa-
tion is increasingly becoming important for reasons as shown in Figure 31.1 and these are:
Shorter new product cycle times/New product development and introduction: Over the last few
decades, companies are increasingly getting more competitive pressure to reduce their product devel-
opment cycle time, i.e. new products need to hit market more quickly. What used to take months or
years earlier, now need to happen in weeks or months.
Reduced engineering resources: While product development cycle time is coming down, companies
also have pressure to reduce size of their engineering and R&D department. It is not uncommon these
days for companies to outsource a part of their product development process to a third party or in a
low-cost country. This need closer management of product information between company and third
party.
Cost reduction pressure throughout lifecycle: The PLM system supports this through ready access
to design and purchased part information during design engineering, component engineering, and
manufacturing planning. This, in turn, leads to greater part and intellectual property reuse and facilitates
designing to cost.
More product variants and growing product lines due to acquisitions: The next challenge is
increasing product configurations through complexity and acquisition. A company’s growth is often
constrained by its ability to manage product complexity. By managing this complexity within a single
environment and by offering product configurator tools, the PLM system reduces that complexity,
thereby eliminating that constraint to growth. The single environment also eliminates added potential
for error in data entry.

Fig. 31.1 Business Drivers for PLM

470 Enterprise Resource Planning

Increasing global product development/collaborative distributed teams: A globally deployed PLM

system provides a single environment, which functions across multiple countries and is integrated with
multiple CAD, CRM and ERP systems. Global data sharing and collaboration meets the objective of
design anywhere. Increasingly companies are outsourcing part of their product development process
to low-cost countries. PLM solutions help in this transformation.
Process consolidation across development teams and supply chain: Tighter integration of the supply
chain, manufacturing and R&D is the need of the day. A PLM system can maintain a master parts
catalogue to enable the selection of manufacturer equivalent parts and also pass on the engineering
BOM from R&D to manufacturing as manufacturing BOM to multiple manufacturing locations.
Increasing regulatory compliance: Regulatory compliance has increased manifold in last decades.
A PLM system can provide a sophisticated material substance tracking system, which is linked to
environmental compliance standards to assure that these standards are met to the satisfaction of
regulatory bodies. It can also handle the audit and traceability requirements for an FDA process (medical
devices, pharmaceuticals, food, and so on). Global quality and compliance standards are evolving on
regular basis (e.g., ISO 9001, WEEE ELV, RoHS, etc.).
Increased focus on innovation (products, processes and business)
Intellectual asset management, leveraging digital assets

Value Proposition of PLM solution

PLM addresses the key business needs as shown in Figure 31.2 and these are:
Drives, facilitates, and captures innovation—Facilitates innovation through process enablement and
reduction in non-value-added activities
Manages complete product lifecycle—Captures and maintains corporate intellectual assets, establishes
product collaborative teams across the enterprise and throughout supply chains, establishes a common
integrated product definition and change management environment – “single version of the truth” and
integrates with value applications and enterprise systems

Fig. 31.2 Value Drivers of PLM

 Product Lifecycle Management 471

Accelerates new product introduction (NPI) process

Brings together information, processes, and people
Plan, manage, and execute programmes and resources more efficiently and effectively
Faster time to market through eliminating non-value-added tasks and automating processes
Higher engineering productivity by giving instant, but controlled access to the right product
information
Reuse of proven parts by providing selection tools that access a common parts database
Environmental compliance by adding regulatory standards and communications management with
suppliers and regulatory bodies
PLM solution’s main value proposition is around eliminating manual and disconnected processes and
bringing speed, quality, and efficiency in the product development process.
More speed results in faster time to market and this speed is accomplished by eliminating non-value-added
tasks through the replacement of disconnected systems and the end-to-end integration of the remaining ones.
PLM systems also replace manual or semi-automatic change and approval processes with an automated
process, which acts directly on the data being changed and approved.
Being early in the market is increasingly becoming a competitive differentiator for companies as this
gives the product manufacturer (or the company offering a new service) a window of opportunity, where
the company can charge a higher price. The faster the competition meets the design and look or features,
the ‘first to market’ advantage will diminish and the product will become a commodity.
Better quality is accomplished by making data, change, and configuration accessible and controllable by
all authorised users. PLM collaboration enhances such engineering collaborating and the sharing of design
know-how. PLM solutions also help in improving quality to cost ratio by more effective part selection and
BOM cost analysis. Quality also reduces recalls, and recalls cost big dollars to the company. Quality products
increase customer satisfaction and customer loyalty.
PLM systems have a direct impact on improving manufacturing efficiency when they manage the
manufacturing change process and provide tight integration and traceability between engineering BOM and
manufacturing BOM. This helps in quick ramp up and time to volume. Getting a product released to the
market is one measurement but ramping up to full volume quickly requires a tight linkage between design
and manufacturing process. PLM systems help in this integration.

DIFFERENT PHASES OF PRODUCT LIFECYCLE—INFORMATION

AND APPLICATION FOR DIFFERENT PHASES
Different Phases of Product Lifecycle
Product lifecycle can be broadly divided into six phases as shown in Figure 31.3 and discussed in detail
below:
Portfolio Planning This is the very first stage of product lifecycle where a company decides what
kind of products they want to manufacture, schedule of release, i.e. when they want the product to hit the
market, etc. A car company at this stage may decide that they want to concentrate on a small car in the next
few years and they want their new model to hit the market in the next 18 months. This proposal/portfolio
of small car may have multiple projects or product plans under it, i.e. the car may have a diesel version
and a petrol version or a basic model and an advanced model with better features and priced little higher.
All these products can have different performance specifications. At this stage, it is common to work with
many new ideas for these new models and the idea management is critical.
472 Enterprise Resource Planning

Fig. 31.3 PLM: Data Management

Concept Development In this stage, the product ideas/concepts are further developed. Innovation is
the key here and strong collaboration is needed between different departments of a company like R&D,
engineering, marketing, manufacturing, etc and all these departments give different perspectives to concept
development process. High level specifications of the product is developed here, i.e. what problem the
product is going to solve and specification of manufacturing process to make the product is also developed.
Different design options (CAD drawings) are identified.
Design In this stage, part design and bill of materials get finalised with the help of computer aided design
or CAD software. Design is an iterative process where several changes are expected, i.e. going forward as
initial design get tested and several stakeholders continuously give inputs on this and design keeps on get-
ting modified. PLM system is expected to manage this change process and track these changes. During this
stage, the design of parts and the overall design of the whole products, its configuration and bill of material
gets finalised. A company will not manufacture all the parts and some of it will be purchased from suppliers.
Requirements for these parts need to be identified, corresponding suppliers need to be selected, specification
of these parts need to be given to suppliers, sample from them need to be tested, approved and purchased.
This is also part of overall design process.
Production At this stage the product is released to factory shop floor for manufacturing. The product
needs to have a manufacturing bill of material (MBOM) at this stage, which will be sent to the ERP system
for final planning and execution. PLM systems are expected to manage product packaging instructions.
Managing quality of supplier’s product on regular/ongoing basis is important at this stage.
Maintenance and Support This phase involves supporting the product in field throughout its lifecycle.
Maintenance instructions, effective management of spare parts, etc become important here. In some cases,
companies enter into annual maintenance contract (AMC) with customers for maintaining the product.
Retirement and Disposal The final stage of the product’s lifecycle when the product is no longer in
use. The product becomes obsolete and needs to be recycled.
 Product Lifecycle Management 473

Different Phases of Product Lifecycle Need Different Types of Information/

Data
In different phases of product lifecycle different information gets created, changed, and released. The man-
agement of this product information is the fundamental goal of PLM systems. For example, a car company
is bringing a new car into the marketplace. This starts with an idea during product planning and becomes
a set of requirements (weight, functions, usage, cost, and so on) during the conceptual development and
design. All the technical work is done, including the engine design, component design, and body design
resulting in CAD models and drawings, and an engineering bill of material (BOM). When this information
gets to the manufacturing area, a manufacturing BOM specific to how that car will be made is created. After
shipping the car, the customer may complain a defect of a car component that get replaced and this input
(defect of a component) goes back to engineering based on which the component can be redesigned. When
the life of the car is over, it gets recycled.
Information/data important for different stages are shown in Figure 31.3 and these are:
Portfolio planning: Product plans, performance specifications, release schedules
Concept development: Product requirements, CAD files, part and material specifications, process
specifications, etc.
Design: Engineering bill of material, engineering change, part specification
Production: Manufacturing BOM, packaging instructions, supplier’s quality information
Maintenance and support: maintenance instructions, spare parts related data

Different Product Stages Need Different Applications

As it is discussed earlier, different types of information (idea, engineering BOM, manufacturing BOM, etc)
gets generated during different phases of product lifecycle and as the product information moves through
its lifecycle, the application requirements change, i.e. specific type of application is needed during specific
phases of a lifecycle of the product. Figure 31.4 shows these different applications needed in different
product phases.
For example, very early in a product’s lifecycle, a company makes productline and product family deci-
sions. So, portfolio, programme and project management are very important. When the product definition

Fig. 31.4 PLM Applications Need in Different Product Phases

474 Enterprise Resource Planning

begins to mature, new functions are necessary. During mostly unstructured conceptual development, it is
critical to enable cross-discipline innovation and collaboration, which captures and nurtures ideas that lead
to more structured product definition. In addition, this is where a product’s functional and performance re-
quirements are initially identified and linked to product features that will eventually be met through design.
Also, at this stage CAD models are built, which represent product families and different approaches that
might meet the product requirements.
The design phase is where part design and bill of materials get finalised with the help of computer-aided
design or CAD software. PLM systems manage the change process and for parts that are purchased and not
manufactured, the part requirements must be defined and the supplier parts must be identified.
Even when the design is released to manufacturing, the PLM system is not done yet. The system manages
the manufacturing bill of materials or MBOM, which would then be sent to the ERP system.
So PLM applications important for different stages are:
Portfolio planning: Idea management, portfolio management, programme management, project man-
agement, etc
Concept development: Innovation/collaboration management, requirement management, design
software (like CAD), system engineering
Design: Engineering BOM management, change management, configuration management, supplier
part management
Production: Manufacturing BOM management system, supplier parts quality system
Maintenance and Support: MRO (Maintenance, repair and overhaul) application, spare parts ap-
plication

DIFFERENCE OF PLM WITH ERP

PLM and ERP applications meet different business needs. A PLM system basically manages the product
innovation process, i.e. R&D and Engineering processes. While product lifecycle spans from concept of the
product to design to manufacturing to till date the product become obsolete, most of the PLM software helps
in the product development cycle. On the other hand, an ERP system is focused on execution, i.e. ordering
the product, assembling and manufacturing it, storing it in the warehouse, shipping it to the customer and
so on. So, ERP system takes up where PLM ends, i.e. the product design is frozen and its bill of material
and all component specifications are finalised and the product is ready for manufacturing. So, while an
ERP system is transaction-based, PLM does not help much in the enterprise transaction processes and more
focused on product innovation processes. PLM covers the processes of research and engineering in R&D
and engineering department of a company which is generally outside ERP’s territory. Table 31.1 details the
different business processes covered by ERP and PLM Systems.

Table 31.1 Business Processes Covered by ERP and PLM Systems

ERP System PLM System

Typically supports the processes in sales, finance, HR, Typically supports the processes in R&D and engineering
procurement and production departments of a company departments of a company
Supports transaction-oriented processes Supports innovation processes
(Contd)
 Product Lifecycle Management 475

(Contd)
Starts from the point the product and its components has Helps in defining the bill of material and specification for
a defined bill of material and specification the product
ERP systems do not have capabilities to store docu- PLM systems have specific document management solutions
ments of different format (especially design and drawing to store data in different formats
documents).
ERP systems with only one bill of material for items PLM systems can work with several Bill of material (Engi-
(Manufacturing BOM) neering BOMs) and configuration options to come up with
optimum BOM design
ERP systems do not have 2D or 3D visualisation capa- PLM systems offer strong visualisation capability
bilities of product structure.
ERP solutions do not offer out of box integration with PLM solutions offer out of box integration with CAD
CAD software. software
ERP systems do not support system engineering PLM systems support system engineering

PLM–FUNCTIONALITIES
There are several product lifecycle management solutions available in the market offering a variety of func-
tionalities. While each of them can have few unique features, there are few capabilities which are considered
as basic and this form the core of all PLM solutions. Leading PLM solutions are coming up with more and
more advanced functionalities. In this chapter we will discuss some of these functionalities.
In this context, it is important to clarify the difference between two terms that are sometimes used inter-
changeably: PDM and PLM. PDM stands for Product Data Management and most of the PLM solutions had
their origin in PDM, i.e. started as a product data management solution. Over the years they added more and
more functionality to become a full-fledged PLM solution. Figure 31.5 shows the functional capabilities of
PLM and these are discussed in Table 31.2 below.

Table 31.2 PLM Software Capability

PLM Area Capability Capability details

Product data Storing product data in PLM applications help in storing different types of product data (e.g.,
management different formats design images, documents, and other specifications) in different formats.
(PDM) A traditional weak point for ERP.
Managing bill of PLM – PDM systems effectively manage different types of bill of material
material and product (engineering BOM, manufacturing BOM, etc) and all materials that are
structure/product required to manufacture or assemble the final product. It helps in manag-
configurations ing different types of product structure and configurations. ERP systems
do not manage engineering BOM.
Visualisation PLM – PDM application enable product development teams to display
and share complex 2-D and 3-D data. Design engineers can make change
interactively and see the effect immediately in another screen of the PLM
product. This helps in evaluating many design scenarios on real time basis
– something not supported by ERP applications.
(Contd)
476 Enterprise Resource Planning

Fig. 31.5 Product Lifecycle Management Functionalities

(Contd)

Collaboration Product development process need collaboration between lot of depart-

ments within (like R&D, design, manufacturing, marketing, etc) and out-
side (like suppliers) the company. PLM applications support synchronous
and asynchronous collaboration among different stakeholders of product
development process.
Workflows and change During the product development process, changes made by one need to
management be approved and this need automatic triggering of workflows. As several
changes are expected in the product design during the development process,
change requests need to be created, approved and finally tracked for these
changes. PLM applications support strong workflow and change manage-
ment capability to track this.
(Contd)
 Product Lifecycle Management 477

(Contd)

Managing idea/ Product development process is all about innovation. To support this, PLM
innovation applications need to help in generating ideas through internal and external
stakeholders, assessing those ideas, evaluating and ranking those and finally
shortlisting the best ones.
Requirements Managing PLM applications enable product requirements from multiple sources to be
management requirements systematically captured, evaluated, allocated, and documented.

Systems engineering Leading PLM applications support systems engineering, including in-
terdependencies between mechanical, electrical, and software design
components.
Project and Portfolio management At any point a company is working with multiple product development
portfolio man- projects. PLM application supports portfolio management tools to help
agement evaluate, select, and prioritise R&D projects across different business units
of the company.
Project management/ PLM application supports product development projects through planning,
Programme scheduling, budgeting and all other normal project management activities.
management Programme management consists of a number of projects.
Product safety Managing dangerous/ For certain industries, product safety and handling dangerous goods is an
hazardous substances area of concern. This can be things like explosives in mining industry, han-
dling oil tankers or radioactive materials. PLM solutions support handling
of such items in a safe way.
Regulatory and com- Safety is one area where reporting and documentation are made manda-
pliance documentation tory by different government agencies. PLM applications support many
industry-specific regulatory requirements.
Planning manu- PLM applications support manufacturing engineering and production pro-
facturing pro- cess planning and development.
cess
End-of-life PLM application can support the decision that when to retire a product
management through analysis (analysis of cost of supporting the product vs. new revenue
it generates, regulatory or recycling considerations, or other industry-specif-
ic requirements). There can be specific industry requirement from industry
like electronics where recycling is a must in certain countries.
Integration Integration with CAD Leading PLM software need to integrate with CAD tools.
software
ERP integration Leading PLM software need to integrate with ERP tools.

Core PLM Functionalities

Document Management Historically, PLM evolved from document management systems (and CAD
data management systems). Document management is a step above file management. In document man-
agement, the files are managed using the concept of a document object that can then be named, revised,
controlled, and so on. The document object can have attributes, revisions, versions, lifecycle states, approv-
als, controlled access, check-in, check- out, view, print, stamp, mark-up, and so on. Document management
capabilities can be used for any document format including PDFs, office formats, JPEG, CAD and so on.
478 Enterprise Resource Planning

CAD Management/Integration PLM solutions offer out of box integration with CAD software, i.e.
users can access PLM functions through the CAD application interface. Some of the functions supported
include
Common parts libraries
Check-in and check-out
Revision and version control
Change and release management
BOM management
Search Capability One of the primary goals of PLM is to allow for reuse of information and that is
why PLM solutions provide sophisticated search capabilities. While designing a new car, you may look for
parts which you can reuse from existing models and that meet particular specification. PLM solutions can
offer different types of search capabilities as discussed below to meet such requirements.
The first is Basic searching: It would be a quick search on basic attributes found (say, in the part
master list).
The second is more advanced and is called Parametric searching. This would display all the attributes
related to an object type, where one can perform more sophisticated search including boolean, ranges,
pick lists, and so on.
The third is the ability to search along relationships. Examples would include a “where-used” to find
all the assemblies where a component is used.
Full-text search is an unstructured search within the documents checked into the PLM system. It is
typically an add-on capability for some PLM solutions.
Change Management Change management is another key function of PLM products. Change manage-
ment is the process of creating a change request (can be a new functionality change or patch upgrade, etc),
submitting to relevant authority for approval, getting it approved, doing the change, testing it and finally
transmitting the change to production system.
Change Request or CR: Another common term for CR is engineering change request or ECR. A CR is
used to ask, ‘May I make a change?’. A user would identify objects that need to be revised and attach them
to a change request. Example of this can be a new part that is replacing parts in an assembly, which would
cause that assembly to revise. Usually, when a part needs to be replaced in an assembly, the impact could
affect multiple assemblies where that part is used and this could be found through impact analysis. The CR
form would identify the request type and reason, as well as the cost and business case for the change. A
typical lifecycle of a CR can be:
In create state, the CR is numbered, the form is completed, and affected objects are attached.
In submit state, the CR is sent to the change coordinator for checking and assignment to a responsible
engineer. This state is especially important in organisations where anyone can initiate a CR.
In evaluate state, the responsible engineer evaluates the CR, does an impact analysis and business
case, and may attach other affected parts.
In review state, typically a change control board would determine whether the change should be per-
formed or not.
If approved, the CR is promoted to the plan change state, where it will wait for the creation of one or
more change orders.
If rejected, the CR would be promoted to the rejected state.
Manufacturer Part Management This is mainly for managing purchased parts. A manufacturer part
number does not appear in company’s Bill of Material (as against manufacturer’s part number the company
 Product Lifecycle Management 479

purchasing the parts will always have their own material number in their own ERP system). Say, a part
which is named as SK0016 by supplier may have a material code number of 000156. This linking is some-
times required to quickly order a supplier a particular part and to avoid collisions when two manufacturers
coincidentally use the same number for two different parts.
Bill of Material Management BOM Management capability includes building BOM structures, add-
ing or removing parts, comparing BOMs, and managing BOM changes and transformation through their
lifecycle. PLM systems help in transformation of a CADBOM to EBOM (Engineering BOM) to MBOM
(Manufacturing BOM). PLM systems must also be able to manage complex BOMs through their lifecycle
and configuration changes. PLM systems also have the ability to manage configurable options within a BOM.
There can be rules defined that, in turn, drive a product configurator. PLM systems also support BOM cost
management through different BOM comparison.
ERP Integration When thinking of the relationship between PLM and ERP systems, it is helpful to
think of PLM managing the product innovation process and then ERP managing the execution process. PLM
builds the product definition, while ERP builds the physical part. For any business to run successfully, PLM
systems need to be integrated with ERP systems for sourcing the components for new product, for costing
the product and finally manufacturing it.

Advanced PLM Functionalities

Product Visualisation Product visualisation provides a dynamic view of the product’s 3D CAD model
with a bi-directional link to the product structure. So the visualisation and the structure are shown through
side-by-side windows. As you select and manipulate information in one window, whether it’s graphical,
textual, or structured, it simultaneously gets reflected in the other. For example, an automobile engineer
is designing a new car interior. If he changes say one of the parameter like leg space, he can visualise the
effect immediately in a separate screen, the effect on design and other parts. This helps in designing in an
interactive mode where he can play with lot of parameters and can always see the effect immediately.
Requirements Management A new product always starts with a set of requirements. An academic
definition of a requirement is a singular documented need that a particular product should do. Functional
requirements describe product behaviour. Non-functional requirements describe how well this behaviour
should perform. A PLM system can manage requirements like any other object type, linking many-to-many
to each other and to other requirements. So, a requirement can have sub-requirements that go into more
detail. A part can have multiple requirements and a requirement can be associated with multiple parts. Re-
quirements can lead to products feature. A requirement is what is desired, and a feature is what the product
will do. Requirements should be always under revision control and change management.
Program and Project Management Product goes from idea to market through one or more projects
and that’s why PLM systems need to have added capabilities around project management. A programme
is basically a collection of projects so there can be a programme at a product level or a product family
level that has multiple projects underneath. The programme is used for grouping and reporting purposes. A
project contains tasks in a work breakdown structure, with associated resources, durations, deliverables, and
workflows. PLM project management supports integration with third-party project management tools, such
as MS-Project. Sometimes programme management is also referred as Portfolio Management. To support
programme and project management capabilities, a PLM system needs to add additional object types like
480 Enterprise Resource Planning

programme, project, task, work breakdown structure, resource, calendars (based on location, user, and so
on). PLM’s another powerful capability is the integration of these tasks in a project with workflow. Finally,
project templates can be established and reused to help with project management standardisation.
New Product Development: An organisation’s new product development (NPD) or new product introduc-
tion (NPI) process can be managed through the programne/project management function. Typical phases of
a new product development cycle are: market research, idea generation, concept feasibility, concept devel-
opment and project planning, design and development, ramp up, launch and production start up, production
and phase out/retirement.

PRODUCT SAFETY AND ENVIRONMENTAL COMPLIANCE—

AN EMERGING AREA OF PLM
More than ever before, companies are accepting corporate social responsibility (CSR) and tackling the
challenges involved in protecting and improving the environment. In addition to accepting environmental
compliance standards, Every company today are required to observe a multitude of national and international
laws and regulations dealing with health and environmental protection, restriction of hazardous substances,
health and safety at work and globally harmonised system for classification and labelling. This has given
rise to a new class of application called Environment Health and Safety application (also known as EHS).
All leading ERP vendors (like SAP and Oracle) offer EHS as part of their product lifecycle management
(PLM) application besides nitch vendors who are specialised only in EHS. These applications fall into fol-
lowing major categories:

Chemicals Safety Management/Hazardous Materials Tracking

The European Union’s REACH initiative mandates that organisations track inventory and usage of over
12,000 different chemicals. Organisations need to track and understand chemical usage not only within
their facilities, but also their transportation through the supply network, not to mention end-of-life disposal.
PLM EHS software manages chemical inventory systems and track chemical storage (e.g., inventory), use,
and transportation throughout the supply network and end-of-life disposal. Any company that produces and
distributes hazardous substances or transports dangerous goods, find these software useful. This solution
ensures that the company meets regulatory requirements relating to product safety and to the management and
labelling of dangerous goods, while at the same time protecting employees and the environment. PLM EHS
supports dangerous goods management by enabling companies to store and manage regulatory data, classify
dangerous goods, perform checks during transport, and compile and update dangerous goods documentation.
This data can be automatically transferred and used for packing lists. For any transportation channels (road,
rail, sea, or air), PLM EHS ensure that shipments comply with regulations before leaving the premises, and
manage dangerous goods storage, transportation, movement, delivery, compliance and reporting.

Product Safety/Material Safety Data Sheet (MSDS)/Labelling Management

For any company involved in developing, manufacturing, or distributing products, they have to comply
with various product-related environmental regulations (for example, directives such as integrated product
policy that restricts the use of certain hazardous substances in electrical and electronic equipment). PLM
EHS solution lets the company collect and process product compliance data automatically, enables to docu-
ment product content and regulatory or sector-specific substance lists and integrates compliance checks and
analyses. For businesses that produce and sell hazardous substances, PLM EHS supports management of
business specifications and phases for products manufacturing. A specification management database allows
to centrally managing substance information (including product composition).
 Product Lifecycle Management 481

A global label management function supports management of many different types of labels that can be
printed directly from various business processes (for example, from outbound delivery).
A material safety data sheet (MSDS) documents proper procedures for handling of hazardous materials
for workers. PLM EHS software support the generation and storage of MSDS information, such as physical
data, toxicity levels, health effects/risks, remedy requirements for spills or accidents, and storage guidelines.
PLM systems make this information readily available to workers and downstream consumers that are exposed
to these materials.

Regulatory Reporting
Companies today need to provide regulatory reporting as per different standards like environmental manage-
ment, health and safety management standards, social accountability standards, risk management standards,
information security standards, water and waste management standards and sustainability reporting standards.
PLM EHS compliance reporting applications support the full range of activities needed to generate a report,
including data collection and task management.

Environmental Compliance
Environmental compliance allows an organisation to capture the materials that are used in their products and
track compliance against internal and external standards. Environmental compliance capabilities maintain
several types of information like:
What is inside a part that could be a substance of concern for environmental regulatory purposes? The
view must include both on purchased parts and also about where the final product is sold.
What are the compliance standards (for example, WEEE, RoHS, REACH) that are in effect that the
part may need to comply with?
Whether the part actually meets appropriate compliance standards or not.
PLM products support compliance process in variety of ways like:
Making sure that the latest standards are known.
Managing the process and correspondence with the part suppliers on their material content for each
part.
Performing BOM analysis to check compliance at the product level.
Tracking the countries where products are sold.
Communicating the compliance status to suppliers, customers and regulatory bodies.

PLM VENDORS
PLM vendors had come from variety of origin. Some of the CAD/CAM vendors got into this space due to
their already established presence in engineering domain. PTC, Dassault Systems, Agile Software, etc. fall
into this category. Leading ERP solution vendors are getting into this space as they already have established
presence in sourcing, manufacturing, costing processes and need to pick up some design capabilities and
R&D process knowledge to get into this segment. SAP and Oracle are the two leading ERP vendors who
are building strong capability in this area and currently SAP PLM is seeing a lot of market interest. Many
companies do not want to go to another vendor (beyond ERP vendor) just to fill in a few gaps in engineering
and design space. SAP PLM and Oracle PLM are their preferred choice. Finally, there are SRM or sourcing
vendors who also want to get into this space, based on their deep knowledge in component development
and sourcing process.
482 Enterprise Resource Planning

Some of the leading vendors in PLM space are listed below:

CAD (computer aided design)/CAM (computer aided manufacturing)/CAE (computer aided engineer-
ing)/document management vendors moving into PLM space:
PTC
UGS
Dassault Systéms/IBM (IBM recently acquired Dassault Systems and another PLM vendor, Matrix-
One)
Agile Software
Leading ERP vendors building PLM solution
SAP
Oracle
IFS

Summary
Product lifecycle management (PLM) applications help in product development process mainly to R&D and
engineering team.
PLM is a cross-functional process involving people from R&D, engineering, manufacturing and market-
ing.
PLM is increasingly becoming important for companies for the need of shorter product development cycle
time, proliferation of new products, globalisation and more collaboration requirements in product develop-
ment process, compliance requirements, etc.
PLM solution’s value proposition is around reducing development cycle time, more productivity of product
development team, reuse of components, meeting environmental compliance, etc.
Product development cycle has mainly five phases: Portfolio planning, concept development, design, produc-
tion, maintenance and support and finally retirement and disposal.
Information/data need for each of these phases differ.
There are different PLM applications to support each phase.
The major difference of PLM application with that of ERP is that while ERP supports all transaction processes
of a company, PLM applications mainly focus just on the product development process optimisation.
Core functionalities of PDM (product data management) are: product data management in different formats,
design collaboration, managing bill of material, product configurations, workflow, data visualisation etc.
PDM is a subset of PLM.
Product lifecycle management also helps in idea management, project and portfolio management, end of life
management and finally integration with different CAD and ERP software.
Product safety and environmental compliance is an emerging area of PLM focusing on dangerous and hazard-
ous goods movements and tracking, material safety, regulatory reporting and environmental compliance.
PLM vendors come from different origin, i.e. CAD – CAM software providers, ERP vendors and SRM
solutions are getting into this space. PTC, UGS, Dassault Systems and Agile Software are the leading CAD/
CAM vendors offering PLM solutions. Leading ERP vendors like SAP and Oracle also have strong PLM
offerings.
 Product Lifecycle Management 483

Exercise
I. Objective Type Questions
1. What is PLM?
2. Why is PLM a cross-functional process?
3. What is portfolio planning?
4. What are the five different stages of product lifecycle?
5. What is PDM?
6. What is the visualisation capability of PDM software?
7. How PDM applications help in product structure design and product configurations?
8. How does PLM application help in idea management?
9. What are the core PLM functionalities?
10. What are the advanced PLM functionalities?
11. What is document management?
12. Who are the leading PLM vendors?

II. Descriptive Type Questions

1. What is PLM? Why is product lifecycle management cross-functional? What are the business drivers for a
PLM application?
2. What are the value propositions of a PLM solution?
3. What are the different phases of a typical product life cycle? How do these different phases need different
types of information and application?
4. What are the differences of a PLM application from an ERP application?
5. What are the typical capabilities of PLM application?
6. What is product data management? What are the typical capabilities of PDM software?
7. How do PLM applications help in managing requirement, product safety and project portfolio manage-
ment?
8. Explain the core and advanced PLM functionalities in detail.
9. How do PLM applications help in change management?
10. Explain the way PLM applications help in managing bill of material and manufacturing part number.
11. How do PLM applications help in project and portfolio management? Explain the function of PLM applica-
tions in managing requirement and new product development?
12. What are the different environmental safety and product compliance areas? How do PLM applications help
there? What is chemical safety and hazardous material management and how do PLM applications help in
this?
13. How do PLM applications help in environmental compliance and different types of regulatory reporting?
Give some examples of compliance issues and regulatory reports.
14. What is master safety data sheet? How does it help?
15. Define the PLM market space. Who are the leading vendors and what are the leading products?

III. Fill in the Blanks

1. PLM stands for _______________ _____________ _______________.
2. CAD stands for _______________ _____________ _______________.
3. CAM stands for _______________ _____________ _______________.
4. PDM stands for _______________ _____________ _______________.
484 Enterprise Resource Planning

5. CSR stands for _______________ _____________ _______________.

6. MSDS stands for ___________ __________ __________ __________.

IV. State Whether the Following Statements are True or False

1. PLM supports transaction functionality.
2. ERP systems can work with several bill of materials for single product.
3. PLM offers out of box integration with CAD.
4. MSDS documents proper procedures for handling of hazardous materials for workers.
5. Product visualisation provides a dynamic view of the product’s 2D model.

V. Assignments
Study in details the PLM applications from leading PLM vendors, i.e. SAP (PLM Product: SAP PLM), PTC
(PLM Product: Windchill). Note down all their modules and sub-modules. What capabilities do they offer? Draw
similarities and differences of their capabilities.
 Section

Technology Areas of
ERP and Enterprise
Applications
 SECTION INTRODUCTION

ENTERPRISE APPLICATIONS—EMERGING TECHNOLOGIES

In Section 3 we discussed different ERP functional modules, i.e. how ERP meets the requirements of different departments
of a typical organisation. In this section the focus is to understand ERP technologies, i.e. the technology components that
are the building blocks of enterprise applications. These building blocks are independent of particular functional area or
particular industry and needed for any business process or industry. So, sometimes these are also referred to as cross-
enterprise applications. For example, any business process need to store data (for which data warehousing application is
needed) and need reports (Type of reports needed by purchase department or financial department may differ, but both
of them need reports). Figure S-4.1 explains the evolution of technologies for enterprise applications.
In the first generation of ERP solutions technology used to be the same as the programming language and the
ERP system administration. ERP consulting, communities used to be divided into two distinct groups, i.e. functional
and technical consultants, where technical consultants used to have skills in specific ERP programming language. For
example, SAP ERP technical consultants used to have skill in ABAP (SAP programming language) or BASIS (SAP
system administration skill). In the same way, Oracle technical consultants used to have skill PL/SQL (Oracle ERP
programming language).
However, as time progressed and ERPs became more advanced ERP technologies were not limited to just program-
ming and system administration, but several new things got added up. The first of that ERP systems started generating
huge amount of data that can be effectively analysed to provide lot of insights to corporate. However, storing such huge
data became a challenge for ERP systems – that now need huge servers to store such data, started making ERP system’s
performance slow and most importantly ERPs were never designed for data storing. This made implementation of data
warehousing solution a must for large ERP implementations. Data warehousing was initially catered by specific nitch
vendors who specialised in this market, but quickly ERP vendors spotted this as a new area of opportunity and most of
the leading ERP vendors like SAP and Oracle started coming with their own data warehousing solutions. For example,
SAP came with their BW (business warehouse) solution for this need. The natural progression of this was ERP vendors
also came up with data analysis, reporting and analytics tools again a segment which used to be catered by specialised
analytics/reporting vendors like Business Object or Cognos. This also resulted in ERP vendors taking over specialised
business intelligence/analytics vendors to make their portfolio stronger. For example, ERP market leader SAP had taken
over business intelligence/analytics market leader Cognos. Today most of the ERP solutions come with very basic level
of reporting capability and most of the advanced reporting is moved into their business intelligence/analytic component.
This is something discussed in detail in Chapter 33.
The second major technology drive in this space is to make the ERP and other systems simple to use for end users.
Over the years, ERP vendors had come up with specific solutions for customer management (CRM), supplier manage-
ment (SRM), product development (PLM), etc. and all this increasingly made the solution complex for end users. Just
think about a company’s R&D staff who needs to access PLM system for doing a product’s design, need to access
CRM system for getting inputs from field staff on the newly launched product and to an ERP system to do ordering
for a new part and this means logging on to different systems, accessing different transactions and getting exposed to
different look and feel of different screens in different systems. That’s not easy for a naive user and, especially if he
is a shop floor worker or sales guy who does not want to spend much time as his main priority is manufacturing or
sales. Portal made all this simple by bringing only relevant transactions from different systems in one screen based on
employee’s role. Thus, portal helps in employee’s productivity. The concept of portal and its benefits are discussed in
detail in Chapter 32.
In the next wave of technology maturity ERP and enterprise application vendors started building capabilities around
content management that can take out information from all unstructured sources like e-mail and Internet. This unstruc-
tured knowledge base coupled with structured knowledge stored in ERP or CRM systems can be stored in one single
Fig. S-4.1 Evolution of Emerging Technologies for Enterprise Application
Section Introduction
487
488 Enterprise Resource Planning

corporate knowledge portal which can easily accessed by any employee in the organisation. This knowledge management
capability made the ERP and enterprise applications more powerful as now they are no longer only transaction systems.
Concept of knowledge management is also discussed in Chapter 32.
In the last decade, technology made it possible to come up with lots of revolutionary models for deploying ERP
solution where a company no longer needs to buy ERP software licence or hardware to run its business on particular
ERP application. The model of SaaS or Hosted ERP made ERP licence on rent/on demand possible and cloud computing
made hardware on rent/on demand a feasible idea. These were big technology enablers mainly for small companies for
whom cost was always the major bottleneck for going for a solution like ERP. Chapter 34 discusses these revolutionary
deployment models.
Chapter 34 also discusses three promising technologies of tomorrow and they are enterprise application integra-
tion, mobile business and RFID. While ERPs have replaced a lot of legacy applications of modern enterprise, there will
be always some applications that remain untouched in every project and their can be valid reasons for keeping them
alive. Enterprise application integration (EAI) product suits help in this area. RFID is another revolutionary innovation
of last decade that helps track and trace of an item in the supply chain. Increasingly as product tracking is becoming a
requirement of modern enterprises, ERP applications are building RFID capability. Finally, mobile devices like mobile
phones, PDAs and laptops are making a lot of difference in our everyday life these days and ERP applications are no
exception. Necessary ERP transactions need to be mobile enabled and today’s ERPs need to talk with these devices
as a lot of business information exchange today is happening over these devices. These are discussed in detail in this
chapter.
Finally, Chapter 34 mentions the concept of ERP II, i.e. how ERPs can become more powerful with Internet by
extending its operations beyond the organisational boundary to its suppliers and customers.
 32
Portal, Content
Management and Chapter
Knowledge Management

Learning Objectives
In this chapter we will discuss the following concepts:
Different types of portals
Portal benefits
Portal features
Managing content – The heart of Portal
Knowledge Management

INTRODUCTION
In this chapter an emerging technology, called Portal, is discussed. Portal is increasingly becoming the com-
mon front-end for all enterprise solutions, i.e. through a single portal a business user can log on to multiple
enterprise systems (like ERP, SCM, CRM, PLM, etc) and a user can view all reports and other information
relevant for running his daily business operations. Portal is role-based. For example, within a company’s
marketing department, there can be different people performing different roles like a sales person need
access to customer database in an ERP system, opportunity/leads information from CRM system, his leave
information from an HR system and few reports from business intelligence (BI) system. Portal brings all
these information from different systems or back-end systems in a single screen from where he can view
and access all these information and if needed, all the back-end applications as well. In the same marketing
department, a marketing manager may need information on brand performance (from data warehousing sys-
tem), advertising expenditure (from CRM system), order fulfillment (from CRM system), new product launch
information (from PLM system) and the portal will have a different role for him. It will bring all these dif-
ferent information from different systems in one place. Thus, the portal helps in employee’s productivity.
Portal is not only about productivity. The biggest advantage of Portal is its capability to work with un-
structured content. ERP, CRM or most of the other applications have a database at its back and can provide
information as long as data is entered in a structured format (i.e. if purchase orders are created using ERP,
then ERP can provide all possible information related to this like purchase price history, vendor performance,
etc). The challenge is, if information is not stored in any structured database and stored in different places
490 Enterprise Resource Planning

like other websites, e-mail, audio and video files, photographic images, etc. It’s difficult to make sense out
of it. Portal’s content management capability becomes very useful here as it can create information and
knowledge out of this.
Finally, knowledge portals are used as knowledge management platform for companies these days as any
type of knowledge (customer related information, project information, learning documents, external analyst
reports, etc.) in any form (word document, PPT, video files, audio files, CAD files, etc.) can be stored in
the portal which can be accessed based on particular employee’s role in the organisation. These documents
can be structured in a way so that these can be quickly searched by an employee and can be archived at
regular interval when it is no longer useful. Thus, portals and content management technologies make it
possible to make a company’s ultimate differentiator in today’s economy, i.e. its knowledge (can be about
its customers, industry, products or competitors).

PORTAL
The term “portal” means different things to different people. To many, a simple website aimed at employees
is a portal. Gartner defines a portal as an “access to and interaction with relevant information, applications
and business processes, by select targeted audiences, in a highly personalised manner.”

Different Types of Portals

Portals can be broadly classified into different categories as shown in Figure 32.1. These are discussed
below:

Fig. 32.1 Different Types of Portal

Public Portals These are also called “Internet” portals. These days almost everyone knows Yahoo or
Google. Public portals generally do not support online transactions, i.e. buying or selling online and gener-
ally for information purpose. These portals can be broadly classified under two categories:
 Portal, Content Management and Knowledge Management 491

General public portals: Examples of these are: Yahoo, Google, AOL, MSN, etc. In India Rediff or
Yahoo will fall into this category. These sites provide lots of services to members of the public (like
mail service, search, etc.) and help surf the web. These portals can also be personalised to a limited
extent.
Vertical portals: These focus on specific narrow audiences or communities such as online recruit-
ment portals (example: naukri.com), online matrimonial portals (example: shaadi.com), travel portals
(example: makemytrip.com), investment portals etc. These can be also based on specialised industries
like consumer goods, computers, retail, banking, insurance, etc.
e-Business Portals These portals support business transactions (i.e. buying, selling, order booking,
payments, etc.) online. These can be classified into three categories:
B2C Portals This extends the enterprise to its customers for the purpose of ordering, billing, customer
service, self-service, etc. Some of the successful B2C portals are: Amazon, eBay, Dell, etc. where people
browse products, buy, order and pay online. Indian Rail site (IRCTC) is one of the successful B2C site in
India where thousands of people book train tickets and pay online daily. B2C portals are quite popular for
airline ticket booking, hotel booking, etc. The basic idea of such portals is to attract and keep the attention
of buyers as well as to collect information about buyers that can be used to enhance and personalise the
customer relationship and thus, drive future sales. More personalised relationships can result in increased
customer loyalty.
B2B Portals This extends the enterprise to its suppliers and partners. This helps to build better rela-
tionships between the company and its suppliers, customers and partners (via extranets) and this improved
relationship can lead to increased trading partner loyalty. Generally these portals are made by individual
companies for their own suppliers and customers. These portals can be further classified as customer portals
and supplier portals.
Customer community portal is directed to improve a company’s ability to acquire, serve, and retain
customers. Companies are competing for access to customers and building loyalty and long-term re-
lationships. With a secure and scalable portal, customers can view products and prices, track orders,
check inventory and view delivery. The level of customer information and self-service will improve
customer relationships and retention. The main focus of such portals is in activities like marketing,
sales, field service, relationship management, ordering, customer service and support.
Supplier Community Portals are directed toward improving the company’s ability to identify, main-
tain, and manage suppliers. These portals help in: Ordering and Fulfillment, Procurement, Planning,
Inventory Control and Logistics and Distribution.
e-Marketplace Portals This is a specialised B2B portal, the only difference with earlier is that these
portals are made by third party providers and not restricted to a specific company’s buyers or customers and
can involve multiple suppliers and customers. In India a good example of this is M Junction which does
metal-related trading between multiple companies.
Employee Portal (B2E) These are also called business to employees (B2E) portals. The target audi-
ences for these portals are company employees. These portals help the employees have corporate information
regarding company policies, raise their different expense statements, leave applications, medical benefit
claims, etc. and give them access to different company applications. Thus, B2E Portals help the companies
in different self-services. A B2E Portal can have different segments like:
Corporate Communication Portal: Portal is an easy way to communicate all employees in the or-
ganisation. A video message from the CEO or the company’s last quarter financial performance can
492 Enterprise Resource Planning

be posted in the portal and can be seen by thousands of employees. It can also serve as a place for
employees to post news items from their department, without cluttering company e-mail boxes.
Human Resource Portal: An employee can submit his annual appraisal in HR portal and the portal
can also generate alerts and remind the managers to arrange the appraisal meeting. Employees can
submit their travel expenses, medical claims, leave applications, etc. in HR portal also. The portal
automatically notifies employees when expenses are approved.
Knowledge portals: This is another specialised type of B2E portal available over corporate intranet
with the objective of improving reuse of intellectual capital within the organisation. This portal also
helps in connecting people to right people in the organisation who is master in particular subject. For
example, a knowledge portal in a consulting organisation may store all details of project works done
by the industry so that this can be reused for any customer project in the same industry.

Portal Benefits
Portals can bring benefits in a number of areas as shown in Figure 32.2. These benefits are discussed
below:
Cost reduction
Productivity improvement
Reduced administration overhead
Increased revenue
Better customer support and customer loyalty
Better support for sales and marketing
Reduced IT cost
Expert locator

Fig. 32.2 Portal Benefits

 Portal, Content Management and Knowledge Management 493

Can act like an executive information system

Unify the enterprise
Cost Reduction—Reduction of Corporate Communication Costs The employee portal helps
to post a lot of documents in the portal which are relevant for all employees (like organisation structure,
HR policies and changes in it, messages, training materials, organisational announcements, etc.) and this
can be viewed by the employees at their convenience. This reduces cost of taking paper-based printouts and
distributing to employees or managing multiple versions of the same policy which if distributed through
e-mail and the employees do not remember which one is the latest one. Instead, they know that they need
to visit one site and they will always have the latest version and these sites become the one-stop-shop. No
more newsletters or fat training binders, all the information is now available online.
Productivity Improvement – Reduction of Time for Employees to Search Documents
Needed to do their Work through Personalisation Without portal, employees can spend a
large part of their day looking for information to help them make decisions. Portal is a one-stop destination
for employees to access quickly documents, e-mails, spreadsheets, research notes, etc. needed to do their
work or make decision. Techniques like categorisation, taxonomy creation, indexing, etc. helps in quick
search for electronic documents and content. This is also a part of knowledge management initiatives taken
by corporate these days. Just imagine if a company has 50000 employees and they can save 10 minutes
per employee per day in terms of quick search of information – this will justify ROI from an employee
portal. Generally, it is seen that an organisation always have enough information – the challenge is always
to convert this information to action points for its employees. Timely and accurate information also help
employees to make more informed decisions. Employee portals improve knowledge workers’ productivity
by bringing together information from disparate systems across the enterprise, other employees and even
external content sources such as business news. Corporate messages can be transmitted to employees based
on employee profile characteristics such as location, role, tenure and responsibility in a timely manner,
regardless of geographical location.
Portal supports personalisation that delivers and presents information tailored to each user’s precise
needs. Personalisation capabilities of employee portals vary widely. A simple portal may only allow users
to configure the look and feel of a web page. A sophisticated enterprise portal, allow organisations to target
specialised information based on role, personal preferences, past usage and behaviour, expressed interest,
time and location, etc. A portal provides the framework for users to store the settings and tailor the content
that they are interested in seeing. Some portals provide subscription options that allow users to receive, on
their portal home page, or in their e-mail, relevant pieces of content. Thus, portal can be used as a “manage-
ment by exception” tool, where business users can monitor certain business or content relevant for them on
regular basis.
Reduced Administration Overhead through Employee Self-service Portals give tools to em-
ployees to solve their own needs and problems. An employee can do his travel booking himself using the
portal and that is how he saves time for corporate travel desk team. There can be a leaner travel desk team.
Employees are not left at travel clerk’s mercy. This kind of self-services also improves employee experience
because they are available from anywhere, at any time, and employees can initiate those services at their
convenience. At the same time it helps in reducing people in support functions like HR, travel, etc. Some
of the typical self-service areas are:
HR self-service like maintaining contact information, applying leave, checking leave balances, etc. by
employees themselves.
494 Enterprise Resource Planning

Benefit of self-services like enrolling to company’s health insurance plan or employee stock options
plan.
Travel related services like making business travel arrangements, submitting expense reports, enabling
direct online booking of flights and accommodations and by supporting compliance with policies
through automated travel request and authorisation procedures.
Finding information about the company policies on travel, benefits, etc.
Ordering office supplies through e-Procurement portal
Enrolling to a company training programme and availing of the training content online or joining an
e-Learning programme
Increased Revenue through Bringing new Products Quickly to Market Employee portals
helps teams to collaborate wherever they are (irrespective of physical location) and at whatever time they
want. This helps in quick product development for engineers along with suppliers and with inputs from
marketing team, new product launch that needs collaboration across several teams, etc. A portal can be a
powerful collaborative tool having functionalities like instant messaging system, document management, team
workspace, discussion forum features, etc. that helps product development process. Portals help engineering
departments in communication and collaboration, document and resource control, and project management.
Engineers can share files through a portal and the portal provides the means of centralising, consolidating,
publishing and updating project information that changes frequently. This results in a dramatic reduction in
paper-based communication and facilitates accurate version control.
Better Customer Service and Customer Loyalty Portals can offer online self-service options
for customers and partners. For example, if a customer is logging on to DHL or DTDC site, he can track
the status of his shipment. Dell allows its customers to configure the product online. Some companies
allow their customers to change the order online. HP saved several million dollars after it rolled out its
@hp portal through which it supported the hardware and software for several thousand sites. This improves
customer service and their loyalty towards the company. Customer service through the portal can be of
different forms like:
Providing patches online for software products
Providing FAQ support and other form of interactive online support for customers in case of malfunc-
tioning of the product
Providing online detailed documentation about the products – features, how to use, etc.
Better Support for Sales and Marketing Sales and marketing groups can take advantage of cen-
tralised information to enhance communication and collaboration with each other as well as with external
resources. The centralised publishing of product, service, sales and marketing information provides quick and
secure access to relevant company databases that contain product availability, pricing, historical proposals,
sales forecasts, performance figures and customer information. As a result, marketing and sales personnel can
collaborate more effectively and ensure that field sales staff, outside contractors, channel partners, distribu-
tors and dealers have immediate access to the information that they need. The result is higher productivity,
increased sales and reduced costs.
Reduced IT Costs by Consolidation of Several Websites to Selected Few Many companies
find that they have too many websites hosted by their departments, business units or different acquisitions
they had over the years. Cost savings come from the elimination of redundant hardware, software and
headcount for employees or contractors who perform maintenance and content update as well as support-
ing end users.
 Portal, Content Management and Knowledge Management 495

Portals can be an Expert Locator In addition to helping users locate information that is important
to them, a portal can be very useful in finding “experts” within the organisation on a particular topic.
Portals’ Role as an Executive Information System Portals have the ability to query multiple
databases and pull out relevant reports and enables the user, on his or her home page, an updated list of
reports that are important to them. Each user can have his own personalised reports. This makes the portal
to play the role of an executive information system that can be used by all managers.
Portal unifies the Enterprise An employee portal enables a global enterprise to communicate through-
out the world. Such communication is virtually impossible when using multiple regional and departmental
intranets. By providing a virtual electronic workplace, an employee portal unifies the enterprise’s workforce
by bridging geographical and functional differences, allowing employees to work together and share knowl-
edge by building communities, exchanging messages and documents and interacting with colleagues.

SOME OF THE PUBLISHED BENEFITS OF USING THE PORTAL

Bay Networks (Nortel) spent $3 million building a state-of-the-art intranet (IMDS) and claims a
savings of $10 million per year because employees spend less time looking for information.
Hewitt Associates is saving $8 million annually and providing responses to client requests for
benefits information that are 75 percent faster after implementing an enterprise portal.

Portal Features
The first generation portal had its beginning with capabilities like preliminary content management, search,
security, etc. However, over the years it matured and today’s portals are having a variety of features like
strong integration capability, analytics, workflow, single sign on, collaboration, etc. Portal features are shown
in Figure 32.3 and are discussed in detail below:
Content Management: Content is the reading material, links, etc. that one gets while accessing it.
This is the most important part of a portal as people visit the site for this information. This is discussed
in detail later in this chapter.
Document Management: This is similar to content management, although it typically refers to the
control and management of an enterprise’s documents (other than web pages) stored in electronic files,
including scanned images or paper documents. Enterprise portal frameworks need the ability to orga-

Fig. 32.3 Portal Features

496 Enterprise Resource Planning

nise and collaborate on documents of many types and formats. Document management functionality
consists of the following:
Library services, such as check-in and checkout
Version control
Search and retrieval
Document security
Document imaging
Document-centric collaboration and document sharing among teams
Document capture and imaging
Records management for legal or regulatory purposes, long-term archiving, etc.
Taxonomy: This can be defined as the content directory for an enterprise’s unstructured information.
Classification trees and hierarchies are other terms used to describe taxonomy structures. Taxonomy
organises the content of the portal into folders and sub-folders, topics and sub-topics, categories and
sub-categories, etc. and this helps in easy browsing for the portal user.
Integration: Portals must provide a wide set of options for integrating to legacy systems and other
applications and thus, makes it easy for end users. Portlets (also known as mini apps or views) are a
component of portal that enable users to get quick and easy access to databases, applications, other
websites and external data feeds such as stock quotes and news.
Browse, Navigation and Search: A fundamental strength of portal is its search capability, which
allows users to browse and retrieve content, based on selection criteria from different sources. The
portal can search across all organisational structured (databases) and unstructured (documents, records,
e-mails, video and audio files, etc.) and other information sources.
Security Administration - Identity Management – Managing Authorisation: Security is vital as
the portal need to deliver confidential and sensitive information customised for thousands of users.
Security needs to be based on company policies, guidelines, and procedures. Security administration
may include things like username/password management, single sign-on, mapping of roles, etc.
Single Sign-On: A critical benefit that portals can provide to the business user community is the
ability to log in to the system just once to access and interact with all kinds of information and data,
regardless of source. The ability to see information from multiple systems, in multiple formats, all
presented on a single page view is one of the largest benefits to a portal’s user community. This results
in significant reduction in employee orientation and training as well as time-saving for the users.
Collaboration and Community: An EIP solution can be a very powerful collaborative tool. Col-
laboration functions enable a group of users to work together to share ideas and complete work as a
team. Collaborative functions range from conferencing and communications to advanced application
sharing/virtual workspaces, document sharing, discussion forums, etc.
Business Intelligence: Portals can act as a universal front-end to different types of BI reports includ-
ing ad hoc reporting, OLAP and multidimensional analysis, exception reporting, etc.
Alerts: Portals can provide alerts or any exceptions through e-mail or wireless device to users based
on individual user preferences like delivery mechanism, format, alert frequency, etc.
Personalisation. Personalisation can be defined as the dynamic creation of a web page based on who
the user is, what he or she is doing or what he or she saw, bought or saved. Personalisation improves
employee productivity by presenting the right information to the right person at the right time. This
portal reacts in real time based on what the user is doing and what he or she is expressing interest
in. A portal helps users to store user-specific settings and tailor the content that they are interested in
seeing.
 Portal, Content Management and Knowledge Management 497

Managing Content—The Heart of Portal

A fundamental part of a portal is that it allows users to search, browse, categorise and manage different
types of content or unstructured data. Content consists of anything from a memo to a spreadsheet to items
contained within a Lotus Notes database to a web page that users monitor on a regular basis. What makes
the portal unique is that it organises this information into a “logical” set of categories.
Content management is the process of authoring, contributing, reviewing, approving, publishing, deliver-
ing and maintaining content integrated that can be accessed from a portal. Content management facilities
ensure that the content of the portal is appropriate, categorised, targeted to the right individuals and approved.
Publishing content in a portal can be a controlled process in which content goes through a review process
and is versioned, tracked and managed at every step. Syndicated content from other information sources can
also be aggregated and made available to portal users. Content management technologies provide a means
to create/capture, manage/secure, store/retain/destroy, publish/distribute, search, personalise, and present/
view/print any digital content (i.e. pictures/images, text, reports, video, audio, transactional data, catalogue,
and code).
Today, there are a variety of sources from where organisations can get content relevant for their busi-
ness and they are: Word processing documents, spreadsheets, e-mail, database records, news articles, audio
files, video files, photographic images, animations, graphics, ERP, CRM and other applications, customer
information, etc.
Managing information which is unstructured, i.e. does not reside in a structured database, is always a
huge organisational challenge as in most cases organisations does not even know the quantum of this and
is spread out across hundreds or thousands of local hard drives, file servers or e-mail systems and consists
of memos, reports, letters, white papers, marketing material, research, presentations, etc. Examples of un-
structured information within a company can include things like:
Intranet sites
e-mail messages: Numerous e-mails within employees, from customers, suppliers and partners can
contain key pieces of information
Groupware applications, such as Lotus Notes or Microsoft Exchange Public Folders
Public websites: Company’s public websites that keep information like press releases, news, product
information, etc.
Word processing documents, spreadsheets and presentations: Desktop files such as Microsoft Office
documents that gets produced by almost every employee in all parts of the organisation. These docu-
ments usually reside on individual hard drives or on shared file servers.
Multimedia files and objects: This can be things like graphics, videos, audio files, brochures, scanned
images of documents, training materials that exist as multimedia objects on file servers or in media
databases.
Challenges of Organising Unstructured Information There are a number of problems that
organisations face in fully leveraging their unstructured assets and these reasons are:
The information is in different physical locations and stored in different physical and logical formats:
Unstructured content within a company can reside on tens of thousands of different machines like file
servers, e-mail servers, individual desktops, laptop machines, intranet web servers as well as outside
the corporation. Furthermore, the content is usually in a number of different formats, making it dif-
ficult to easily consolidate.
The lack of structure makes it difficult to organise content. By their very nature, unstructured docu-
ments are hard to categorise as they often don’t have effective metadata associated with them.
498 Enterprise Resource Planning

Sometimes information is sitting in people’s heads and not available in electronic format.
It needs lots of time and manpower to categorise the information.
Content Management Functions Managing content in the portal means different set of activities
as discussed below:
Content conversion: Content management system can automatically convert files, such as word
processing documents, spreadsheets and graphics, to different other formats suitable for web such as
PDF, XML, WML and HTML so that these documents can be accessed and utilised by any web-based
application.
Content delivery, distribution and integration: A content management system aggregate and distrib-
ute all types of content within an organisation, regardless of location or file format. For this content
management software offer out of the box integrations with ERP, CRM and other e-business applica-
tions.
Content archiving: This includes capabilities like document archiving and retention capability. It is
important to define a process for such archiving, i.e. what to do with old content, how to determine
when content has out-lived its usefulness and should be retired from the portal, etc.
Content access control: This consider things like: who can deposit, read and delete documents in the
portal, who can create additional folders and otherwise modify taxonomy, who can add notification
alerts, which users should have the capability to save personal searches in the portal, etc.
Contribution and approval process: This is the process of how a new member can contribute content
in the portal or website, how this content get approved, etc.

Knowledge Management
Knowledge management is a subject that is increasingly getting discussed in corporate boardrooms as organi-
sations have identified this as one of the most challenging initiatives in corporate future. Before discussing
it further, let’s first define ‘what knowledge management” is.
Knowledge management (KM) can be defined in different ways like:
KM is the process of capturing, organising, and storing information and experiences of workers and
groups within an organisation and making it available to others.
KM is an organisational process for converting information into knowledge and making that knowledge
accessible to everyone in the organisation.
KM comprises a range of practices used in an organisation to identify, create, represent, distribute and
enable adoption of insights and experiences.
KM is a discipline within an organisation that ensures that the intellectual capabilities of an organisa-
tion are shared, maintained and institutionalised.
Need for Knowledge Management Need for knowledge management is obvious for so many rea-
sons:
The organisation do not want to loose the knowledge as people leave organisation and the knowledge
which is in their head and was never documented anywhere leaves with them
No one wants to reinvent the wheels, i.e. doing it once again from scratch when it was already done
in some other part of the organisation
Minimising the cost and chaos of dealing with the flood of information
Gaining the full value of the knowledge embedded in lots of documents in different formats
To increase collaboration and knowledge sharing by connecting people to each other, and to key
expertise
 Portal, Content Management and Knowledge Management 499

Employees generally spend a lot of time trying to track down the right piece of information, may be after
referring to multiple online sources, contacting one or more people and possibly after accessing multiple
business applications. This results in lost employee productivity and higher costs. Faced with not being able
to find the right information, employees will often reproduce the same information that have already been
created in another part of the company, i.e. reinvents the wheel. This can cost significantly to organisations.
This cost can be saved with a simple knowledge management tool like knowledge portal.
Another great benefit of knowledge management is that every time an employee leaves, their associated
knowledge and expertise, which companies have invested significant money into, leaves with the employee.
An effective knowledge capture mechanism can help other employees leverage the knowledge that the former
employee has accumulated and can be used by new employees to shorten their ramp-up time.
Though importance of KM is well understood, organisations have often seen several challenges in
implementing KM initiatives and several surveys had shown that some of the top-listed challenges are as
follows:
Lack of understanding of KM and its benefits
Lack of encouragement in the current company culture for sharing knowledge
Lack of incentives/rewards to share
Lack of funding for KM initiatives
Lack of appropriate technology to capture technology
Lack of commitment from senior management
Knowledge Management Technologies Knowledge management is not just a software and imple-
menting knowledge management in an organisation necessitates new sets of processes, new organisational
roles and new technologies. However, in this chapter the focus is on the third dimension, i.e. knowledge
management technologies. There are several technologies used for knowledge management. The most com-
mon ones are:
Enterprise portal
Document management application
Content management application
Search engines
Messaging/e-mail
Data warehousing and data mining applications to analyse information in the knowledge repository
Groupware
e-Learning tools
We discussed some of these technologies (like portal, document management applications, content
management applications, search engines, etc.) earlier in this chapter. Corporate e-mail is one of the most
common modes of interaction in all large organisations today. Data warehousing and data mining tools are
discussed in detail in Chapter 33.

Summary
Portal is the one common user interface for number of business applications that a user may need for doing
his daily job.
Portals can be divided into different categories like public portal, employee portal and e-Business portal.
e-Business portal can be further classified as B2B and B2C portal and B2B portal can be further classified into
500 Enterprise Resource Planning

customer portal, supplier portal and e-marketplace portal. Employee portal can be grouped into knowledge
portal, HR portal and corporate communication portal.
Portal provides a number of benefits in terms of cost reduction, productivity improvement, reduced admin
cost, increased revenue, locating experts, better customer support, self-service, etc.
A portal is as good as the content inside it. Better content management capacity helps in extracting information
knowledge from different unstructured information sources. Content management software helps in content
creation, conversion, authorisation and archiving process.
Need of knowledge management for today’s enterprise does not need separate justification. Knowledge portals
are important tools for knowledge management process.

Exercise
I. Objective Type Questions
1. What is a Portal?
2. What are the two types of Public Portals?
3. What are different types of B2B portals?
4. What are e-Marketplace portals?
5. What are three different types of B2E Portals?
6. What is employee self service?
7. What is content management?
8. What is document management? Explain the different features of document management?
9. What is Taxonomy?
10. What is meant by Single sign on?
11. What is meant by Personalisation?
12. Name some sources of unstructured information.
13. What is meant by content conversion?
14. What is knowledge management?
15. What are the different technologies for knowledge management?

II. Descriptive Type Questions

1. What is a portal? How does it help the organisations? How can a portal work with unstructured content?
How can a portal be used as a knowledge management platform?
2. What are the different types of portals? Explain each one of them.
3. What are the different types of e-Business Portals? Explain different types of B2B, B2C and B2E portals.
4. What are the benefits of a portal? Explain each one of them. How do portals help in reducing cost and
improving productivity? How do portals provide better customer service and speedy product introduction?
What is employee self-service and how do portals help in that?
5. What are the different portal features? Explain each one of them. How do portals help in integration, col-
laboration and personalisation?
6. What is content management? Why is it important for an organisation? What are the challenges of managing
unstructured information? What are the different content management functions?
7. Define knowledge management. What is the need for knowledge management? Discuss top few challenges
of knowledge management in an organisation. What are the different technology options for knowledge
management.
 Portal, Content Management and Knowledge Management 501

III. Fill in the Blanks

1. B2B stands for _______________ _____________ _______________.
2. B2C stands for _______________ _____________ _______________.
3. B2E stands for _______________ _____________ _______________.
4. KM stands for _______________ _____________.
5. Taxonomy can be defined as the _________ ___________ for an enterprise’s ___________ __________.
6. Personalisation can be defined as the ___________ creation of a ____ _____ based on who the user is.
7. Groupware is a _________ __________ tool.
8. Lotus Note is a ___________ application.
9. Single-sign On is a _________ feature.
10. e-mail is an example of __________ content.

IV. State Whether the following Statements are True or False

1. Knowledge portal is a type of B2B portal.
2. e-Marketplace is a type of B2E portal.
3. An enterprise portal solution can be a very powerful collaborative tool.
4. Search engine is a knowledge management tool.
5. Public website is an example of structured content.
 33
Data Warehousing, Data
Mining, Business Chapter
Intelligence and Analytics

Learning Objectives
In this chapter we will discuss the following concepts:
Data Warehousing
Data Extraction, Transformation, Cleaning and Data Loading
OLAP and OLTP
Data Mining Technologies
Analytics
Business Intelligence

INTRODUCTION
One of the main drivers for companies implementing enterprise systems like ERP or CRM is to have right
information at right time. All business transactions (like purchase order creation, sales order entry, invoice
creation, etc.) happen in ERP or CRM systems and these are the source systems for all business data. While
these systems provide online reports, over the time the corporate sector has discovered that these may not
be the best tools for reporting, the reason being the volume of data. If the company wants to see purchase
order price trend for an item for the last ten years, the company needs to store transaction entries for that
period. These huge volumes of data is bound to make the system slow. So a new generation application,
called data warehousing application, has been emerged that helps in extracting data from transaction systems
(like ERP or CRM), cleaning it and storing.
Storing data alone is not enough if it can not provide the required information. Business Intelligence
(BI) and OLAP applications help to analyse the data in multiple dimensions and provide reports in differ-
ent formats. While BI and OLAP applications help in any kind of reporting, analytic applications specialise
reporting on particular functional areas like finance, sales, etc.
Finally, data mining applications help in finding trends in data which are not so obvious. These applica-
tions take help of a set of mathematical tools to find such trends.
In this chapter data warehousing, business intelligence, data mining and analytics applications are dis-
cussed. Understanding these topics is important to cover three important stages of data, i.e. data, information
and knowledge.
 Data Warehousing, Data Mining, Business Intelligence and Analytics 503

DATA WAREHOUSING
Data warehouse sources data from various operational systems, oraganises and stores it in a form that is
standardised, structured, consistent, clean and integrated. This is structured in a way to specifically address
the reporting and analytic requirements. So, data warehouse has tools to extract, transform and load data.
Data can come from various sources, like ERP, CRM, legacy applications and external data sources, data
can be stored in a diversified database, in different formats and structures and then data can be accessed by
a business intelligence system (BI), a decision support systems (DSS) or an executive information systems
(EIS).

Four Important Characteristics of Data Warehouse

Subject-oriented: Data warehouse is organised around subjects such as sales, product and customer.
It focuses on modelling and analysis of data for decision makers related to a particular area.
Integrated: Data warehouse is constructed by integrating multiple heterogeneous sources like OLTP,
ERP, CRM, legacy applications, etc.
Time-variant: Provides information from historical perspective, e.g. past 5-10 years
Nonvolatile: Data once recorded cannot be updated, i.e. can not be changed until the next refresh.

Advantages and Disadvantages of Data Warehousing

Advantages and disadvantages of data warehosuing tool is explained in Figure 33.1

Fig. 33.1 Advantages and Disadvantages of Data Warehousing

Advantages
Common data model: Data warehousing provides a common single data model for all data of inter-
est regardless of its source. This makes it easier to report and analyse information than it would be if
multiple data models are used to retrieve information.
Clean data: Data warehousing ensures that the data in the data warehouse is clean and consistent.
Prior to loading data into the data warehouse, inconsistencies are identified and resolved. This greatly
simplifies reporting and analysis.
504 Enterprise Resource Planning

Can store data for longer time and operational system’s performance do not get hampered: Data
warehouse can store data for long time. If huge volume of data is kept in transactional systems (like
ERP or CRM), this may impact the performance of those systems. Therefore, it is recommended to
keep the data in the warehouse and the same may be deleted or archived from source systems. This
information can be stored safely in data warehouse system for extended periods of time and may be
used for regulatory purposes (regulatory bodies may need financial transaction data for last ten years),
or trend analysis (sales trend for last 15 years). If such huge volume of data resides in ERP or CRM
system, these systems would become very slow. As data warehousing is separate from operational
systems, data warehouses provide retrieval of data without slowing down operational systems.
Facilitate BI, EIS, MIS, DSS and Analytics systems by providing right data: Data warehouses
facilitate different business intelligence (BI), executive information system (EIS), management in-
formation system (MIS), decision support system (DSS) and analytic applications by providing data.
Based on the data available in the data warehouse, these systems can produce different trend reports
(e.g. sales trend for a particular product for the last ten years), exception reports, and reports that show
actual performance versus goals, etc.
Disadvantages
Latency factor: As data must be extracted, transformed and loaded into the warehouse, there is an
element of latency in data warehouse data, i.e. there will be always a delay between when data becomes
available in transaction system and when it is available in the warehouse.
Storing unstructured data: Data that is unstructured (i.e. mail files, video files, audio files, etc.) is
difficult to store in the data warehouse.

Data Warehouse Components

Star Schema, Fact and Dimension Tables, Attributes Multi-dimensional data models are needed
for the creation of data warehousing or OLAP applications. The classic star schema, as illustrated in the
Figure 33.2 is the frequently-used multi-dimensional model for relational databases. This database schema
classifies two groups of data: facts (sales or quantity, for example) and dimension attributes (customer, mate-
rial, time, for example). Star schema uses fact (facts or measures in the business) and dimension (establishes
the context of the facts) tables and is composed of a single fact table and for each dimension one-dimension
table. Fact tables are related to each dimension table in a many to one relationship (Primary/Foreign Key
Relationships). The dimension tables are linked relationally with the central fact table by way of foreign or
primary key relationships. Star schema is optimised for OLAP.
Facts These are numeric measurements (values) that represent a specific business aspect or activity. These
are stored in a fact table at the centre of the star schema and contain facts that are linked through their dimen-
sions. Typical example of fact table is individual sales records. Table 33.1 is an example of a fact table.

Table 33.1 A Fact Table

Day_ID Customer_ID Material_ID Sales Value Quantity

03.01.2002 K100 M1001 2000 500
04.01.2002 K101 M1002 2500 250
05.01.2002 K102 M1003 4000 800
 Data Warehousing, Data Mining, Business Intelligence and Analytics 505

Fig. 33.2 Star Schema Example

Dimension These are qualifying characteristics that provide additional perspectives to a given fact. Dimen-
sions are normally stored in dimension tables. These are joined to fact table by a foreign key. Typical example
of dimensions are: time periods, geographic region (markets, cities), products, customers, salesperson, etc.
Tables 33.2 and 33.3 are examples of Dimension Table.

Table 33.2 Customer Dimension Table

Customer_ID Customer_Name City Region

K100 Mr. A Delhi North
K101 Mr. B Bangalore South
K102 Mr. C Mumbai West

Table 33.3 Material Dimension Table

Material ID Material Name Material Group

M1001 Pump Hardware
M1002 Machine Equipment
M1003 Bulb Electrical
506 Enterprise Resource Planning

Attributes Attributes provide additional information for a dimension. For example, customer name, city
and region can be attribute for the dimension customer.
Advantages of Star Schema Storing data in the form of the classic star schema is optimised for report-
ing. It allows the user to view facts from a variety of perspectives (dimensions). For example, a user can
get quick answer to the questions like Whom have we sold to? (customers), what have we sold? (products),
how much have we sold? (quantity), when did we sell it? (time), etc from the fact table mentioned in Table
33.1. From this request, the system generates a three-dimensional results structure which can be depicted
graphically as a three-dimensional (data) cube.
Data Mart This is a subset of a data warehouse that supports the requirements of particular department
or business function. The characteristics that differentiate data marts and data warehouses include: a data
mart focuses on only the requirements of users associated with one department or business function. Data
marts do not normally contain detailed operational data, unlike data warehouse. As data marts contain less
data compared with data warehouses, data marts can be more easily navigated. Figure 33.3 explains the
difference between data mart and data warehouse. Characteristics of a data mart are:
Small
Flexible
Lightly summarised
Departmentally structured

Fig. 33.3 Data Warehouse and Data Marts

Advantages of Data Mart:

To give users access to the data they need to analyse most often
To provide data in a form that matches need of users in a department or business function
To improve end-user response time due to the reduction in the volume of data to be accessed
Normally use less data so tasks such as data cleansing, loading, transformation, and integration are
far easier and hence implementing and setting up a data mart is simpler than establishing a corporate
data warehouse
The cost of implementing data marts is normally less than that required to establish a data ware-
house
 Data Warehousing, Data Mining, Business Intelligence and Analytics 507

Figure 33.4 explains how a data warehouse can source data from different data store and can be a source
of data for multiple datamarts.

Fig. 33.4 Data Warehouse: Sourcing Data from Different Data Sources and Becoming a Source of Data for
Several Datamarts

Operational Data Store (ODS) An operational data store (ODS) consolidates data from multiple
source systems and provides a near real time integrated view of current data. Its purpose is to provide in-
tegrated data for operational purpose and it has add, change or delete functionality. Like data warehouse,
its sources also include legacy systems and it contains current or near term data, but in contrast to a data
warehouse, an ODS may contain 30 to 60 days of information, while a data warehouse typically contains
years of data. Like data warehouse an ODS object is used to store consolidated and cleansed data (transac-
tion data or master data for example) on a document level (atomic level).
Advantages of ODS
Overwrite function—This is the greatest advantage of ODS
Save data at a document level
Consolidated or overwritten
ODS can be used for reporting and drilldown
An ODS is designed to quickly perform relatively simple queries on small amounts of data (such as finding
the status of a customer order). An ODS is similar to short term memory in that it stores only very recent
information; in comparison, the data warehouse is more like long-term memory in that it stores relatively
permanent information. In contrast to a multi-dimensional data stores, data in ODS objects is stored in flat,
transparent database tables. Fact and dimension tables are not created.

Data Warehousing Tool Capabilities

A data warehousing tool need to have multiple capabilities as follows:
Data storage capabilities
Database integration capabilities: Capabilities of integrating with different database management
systems
Supporting different data types like: structured (e.g. relational tables), semi-structured (e.g. flat files,
XML docs, PDF docs), unstructured data, etc.
508 Enterprise Resource Planning

Application and middleware integration capabilities: Capabilities with integrating with different
middleware and applications like: Business intelligence (BI), enterprise resource planning (ERP), on-
line analytical processing (OLAP); enterprise application integration (EAI), master data management
(MDM), etc.
Software platform integration capabilities: Integration capabilities with different software platforms
such as different operating systems (e.g. Linux, UNIX, Windows), application development environ-
ments (e.g. Java, NET), etc.
Scalability and performance
Security features like authentication, authorisation, access control, permission management, data en-
cryption, security monitoring, alerting, auditing, etc.
High availability and reliability features like redundancy, fault tolerance, data protection; data replica-
tion and mirroring; and data backup, recovery, protection, disaster recovery, etc.
Supporting different industry standards like SQL, SOA (web services, XML), etc.
Administration features like system monitoring and control, diagnostics and troubleshooting, job
scheduling and control, etc.
Capabilities like Metadata management, data modelling, hierarchy management, etc.

Data Warehousing Architecture

Figure 33.5 shows a simplified Data warehousing architecture. There are multiple external sources and
operational databases from where data is extracted. These external sources can be ERP or CRM systems,
different SQL or DB/2 Databases, etc. This data is extracted, transformed, cleaned and loaded in a data
warehouse. One data warehouse can be source of data for multiple data marts. From data warehouse, the
data is brought to OLAP servers of data analysis tools as per different reporting requirements. Finally dif-
ferent data analysis tools (OLAP tools, Query/Reporting tools, Data mining tools etc) helps in different
sorts of analysis of data.

Fig. 33.5 Data Warehouse Architecture

 Data Warehousing, Data Mining, Business Intelligence and Analytics 509

So Data warehousing applications follow a three-tier architecture, i.e. data source layer, data warehous-
ing layer and data analysis layer. Figure 33.6 explains this three-tier architecture of data warehouse. Data
source layer are the applications where data actually gets generated, data is extracted from here and stored
in data warehousing layer. Finally there is data analysis layer where data is analysed for reporting.

Fig. 33.6 Three-tier Data Warehouse Architecture

Storing Data in Warehouse—Some Related Topics

Data Granularity—At which Level to Store Data in Warehouse This is always a trade-off
decision, i.e. whether to store data at the most detailed level or to store it at the summarised level. Both
have their own advantages or disadvantages.
Data stored at summarised level has advantages like: Reduced storage costs and reduced CPU usage,
increased performance since smaller number of records are processed, better performance in reporting, etc.
But summarised level data can not answer transaction level questions like whether Mr. A had called Mr. B
last month (for a telecom company). This is not possible to answer, if total duration of calls by Mr. A over
a month is only maintained and individual call details are not maintained.
Advantages of storing data at detailed level, i.e. storing each transaction, is obtaining details of every
transaction. However, the problem of storing at this level is the huge volume of data.
Data Refreshing—At What Frequency to Refresh Data in Warehouse There can be different
options of refreshing data in data warehouse like:
Periodically (e.g., every night, every week)
After every significant event, say after each month-end financial closing
On every update, i.e. as soon as there is a change in data – Generally not warranted unless warehouse
data requires the most current data (say, up to the minute stock quotes, up to the minute accurate stock
information, etc.)
There can be different refreshing policies for different sources. For example, from the ERP source system,
stock information need to be refreshed in data warehouse every two hours, but from CRM source system
new customer information can be refreshed once every day.
510 Enterprise Resource Planning

There can be different refresh techniques like:

Full refresh from base tables: This reads entire source table. It is expensive and time-consuming
and typically done when the data warehousing project goes live for the first time. It is not done on
regular basis.
Incremental or Delta refresh: It detect changes on base table and refreshes only the delta records
(i.e. changes from last refresh).
Data Partitioning This means breaking data into several physical units that can be handled separately.
Typically data can be partitioned by date, line of business, geography, organisational unit or any combina-
tion of the above. Partitioning provides flexibility in managing data and allows:
Easy restructuring
Free indexing
Easy reorganisation
Easy recovery
Easy monitoring

DATA EXTRACTION, TRANSFORMATION—CLEANING AND

DATA LOADING
Clean Data/Quality Data
Clean/Quality data means different things to different people. Some of the critical attributes of this data are
as follows:
Accuracy: Data must be consistent with the intended goal. There may not be anything wrong appar-
ently with a phone number of 7 digits for one place and 8 digits for another place, but as goal of data
warehousing is standardisation, the 7-digit data may be added with a suffix to ensure that all phone
numbers follow a standard nomenclature of 8 digits.
Completeness: Missing and invalid data can lead to problems. For example, if the social security
number in a US employee’s personnel record is null or has more or fewer than nine characters, the
data should be considered incomplete or invalid.
Integrity: Integrity means expected relationships between multiple data sets. For example, a telecom
provider may have separate schemes for “Residential” and “Corporate customers”. If a customer which
is identified as “Residential” account has purchased services intended for a “Corporate customer”,
then there is data integrity issue.
Timeliness: It is important that data reaches the intended user on time. The morning newspaper, if
it comes one day late with best possible news it does not sell. A weekly refresh of an enterprise data
warehouse won’t meet the needs of a sales analyst who requires nightly data feeds from source ap-
plications to meet daily reporting requirements.
Consistency and standardisation: If data does not conform to the defined formats and standards
then it can lead to issues. For example several retailers run EDI applications between their stores and
distribution centres. EDI can accept data only as per defined standards. If data does not come as per
that standard, then it will lead to chaos.
Accuracy of hierarchal relationship: Customers and suppliers may have different hierarchical re-
lationship like customer A can be a subsidiary company of customer B or supplier C can be a group
company of supplier D. It is important to have these relationships accurate in the data so that reporting
is correct.
 Data Warehousing, Data Mining, Business Intelligence and Analytics 511

Uniqueness: Ideally one customer or one material or one vendor should have only one record in the
company’s database. Mostly it does not happen as the same customer is sold through different chan-
nels and each channel create a separate customer record or there are separate records as customer or
supplier’s name or address is spelt differently. Data cleansing software supports complex matching
rules to ensure that these instances represent the same unique customer record and data warehousing
and analysis tools provide a comprehensive view of customer’s purchase history.
Data enrichments by third parties: Sometimes data is appended with third-party information. For
example, before extending credit to a business client, credit management team may like to add a credit
rating score from Dun & Bradstreet.

Data Cleansing Tools

Leading ERP vendors like SAP (with its Business) and Oracle (with its Oracle Data Quality for Oracle Data
Integrator - ODQODI) provides some data cleansing capabilities. But in most cases, third-party data cleans-
ing products are most popular. Leading IT companies are also looking at this market. IBM’s acquisition of
Ascential Software in 2005 had given them a strong ETL and data cleansing tool.

Extraction, Transformation and Loading (ETL) Tools:

ETL stands for extract transform and load. These processes enable companies to extract data from multiple
sources (extract), reformat and cleanse it (transform), and load (load) it into another database, a data mart
or a data warehouse for analysis. Thus, ETL technology has capabilities of:
Extract: Batch extraction of high volumes of data from one or more sources (source can be: a main-
frame application, an ERP application, a CRM tool, a flat file, an Excel spreadsheet, a DBMS). There
is a variety of tools for extracting data like by writing programmes, by creating flat files, by Java or
Microsoft-based tools.
Transform: After extraction, the data need to be transformed or modified depending on specific
business logic involved so that it can be sent to the target repository. There are a variety of ways to
perform the transformation and in most cases data need cleansing, i.e. removing duplicates and enforce
consistency. An ETL tool has the ability to run complex transformations on the data. This includes
cleansing, standardisation, based on a set of business rules. This is the most time consuming part of
ETL.
Load: Loading of data to specified target systems (data warehouse, data Mart, operational data store,
another application, etc). ETL can also be used for non-warehousing applications, such as database
consolidations, database migrations, data synchronisation across systems, etc.
Areas of Usage for ETL Tools ETL Tools today are used for a variety of purpose:
Data migrations: Legacy data migration is a challenge for any enterprise solution (like: ERP, CRM)
implementation where huge volume of data need to move from age-old systems to the new solution.
In earlier days, custom code was getting used for this purpose whereas today ETL tools are becoming
popular. As discussed earlier, common data migration examples include the implementation of a new
ERP application from one or more legacy applications, an upgrade to the latest version of an enterprise
application, or the integration of data from a merger or acquisition.
512 Enterprise Resource Planning

Master data management: ETL tools are the building block of MDM ecosystem.
Data warehousing and reporting: ETL tools help in extracting data from different sources, flat files,
etc. for data warehousing and reporting purposes.
Compliance: Sarbanes-Oxley, Basel II and other regulatory laws require organisations, most notably
the financial services, to improve their ability to track and audit the movement of sensitive data from
capture through consumption.
ETL Vendors ETL vendors come from variety of backgrounds like:
Pure-play ETL vendors like Ascential Software (Ascential Data Stage), Informatica (Informatica
PowerCenter), etc.
Database vendors like IBM, Microsoft (Microsoft, Pervasive), Oracle (Oracle Warehouse Builder
- OWB), etc
Business intelligence (BI) vendors like Business Objects, Cognos, Hummingbird, SAS, etc.

ONLINE TRANSACTION PROCESSING (OLTP) AND ONLINE

ANALYTICAL PROCESSING (OLAP)
Online Transaction Processing (OLTP)
OLTP refers to a class of systems that facilitate and manage transaction-oriented applications, typically for data
entry and retrieval transaction processing. OLTP data is always on-line, and is fast and efficient for querying.
It facilitates and manages transaction-oriented applications. Some of the characteristics of OLTP are:
Operational data that is the ongoing transactional data related to business operations like production
data, sales data, etc.
OLTP is the source of the data origin. Every data of the business is stored in the OLTP system.
OLTP database design is highly normalised in nature.
Follows entity relationship diagram and uses data modelling.
Involves relational database management system (RDBMS).
Tables form relations between each other.
The data reveals a typical snapshot of the ongoing business activity.

Online Analytical Processing (OLAP)

OLAP or online analytical processing enables a user to easily and selectively extract and view data from
different points of view. OLAP data is stored in a multi-dimensional database, provide rapid access to data
for analysis and quickly answer multi-dimensional analytical queries. OLAP is part of the broader category
of business intelligence and data mining tools. The typical applications of OLAP are in business reporting
for sales, marketing, management reporting, budgeting and forecasting, financial reporting and similar areas.
Some of the characteristics of OLAP are:
Data is consolidated for a period of time.
OLAP database is formed from various databases which are OLTP in nature.
OLAP provides decision-making information, build analysis, problem-solving activities over the busi-
ness data.
Database design is typically de-normalised with limited tables.
 Data Warehousing, Data Mining, Business Intelligence and Analytics 513

Follows star schema with a single fact and multiple dimensional tables Example: Sales Fact table with
customer dimension, sales dimension, location dimension and time dimension.
The data reveals multi dimensional views of various kinds of business activities.
Types of Analysis Possible in OLAP There are different types of analysis possible in OLAP for
example:
Aggregation: Total sales, percent-to-total
Comparison: Budget vs. actual, sales for each product line YTD this year vs. last year, sales of a
product line to new vs. existing customers.
Ranking: Top 10, Bottom 5, Top 5 product contributors to margin.
Find the customers that have had negative sales growth
OLAP functionalities:
Roll up and roll down (drill up and drill down): Roll up or drill up summarise data by climbing
up hierarchy, i.e. sales of each sales office can be rolled up to city, which can be further rolled up to
state, region and country. Roll down or drill down is reverse of roll up, i.e. from higher level sum-
mary – getting into lower level summary or detailed data, e.g. given summarised sales of the country,
find break-up of sales by city within each region, city or individual sales office. Figure 33.7 explains
this. For roll up and roll down, it is important to maintain the dimension hierarchy within the data
warehouse. Figure 33.8 explains such a hierarchy.
Slice and dice: This helps in viewing data that is lying in data warehouse in different ways. Figure
33.9 explains the concept of “slicing and dicing” for a consumer goods company. Someone wants to
see only food sales data across different regions and across different sales channel can run a quick
OLAP query to get the information.
Multi-dimensional data cube: In an OLAP, the data is stored in the form of a multi dimensional data
cube as shown in Figure 33.10. This helps in quick slice and dice of data.
Pivot: OLAP data can be converted to a pivot chart.
Sort: OLAP helps in sorting of data.

Fig. 33.7 Roll Up/Drill Up and Roll Down/Drill Down

514 Enterprise Resource Planning

Fig. 33.8 Dimension Hierarchy: Location

Fig. 33.9 Slicing and Dicing Data for a CPG Company

Strengths of an OLAP Tool

It is a powerful visualisation tool
It provides fast, interactive response times
It is good for analysing time series
It can be useful to find some clusters and outliners
Three Types of OLAP
ROLAP (Relational Online Analytical Processing): This uses an RDBMS to implement and OLAP
environment and typically involves a star schema to provide the multi-dimensional capabilities. This
supports very large databases and reduces the number of joins a query has to process. Figure 33.11
gives an example of ROLAP.
 Data Warehousing, Data Mining, Business Intelligence and Analytics 515

Fig. 33.10 Multi-Dimensional Data Cube

Fig. 33.11 An Example of Relational OLAP

MOLAP (Multi-dimension Online Analytical Processing): Uses a multidimensional OLAP and an

MDDBS (Multi-dimensional database) to store and access data. Usually it requires data access tools.
Provide exceptionally fast response times. Here facts stored in multi-dimensional arrays and dimen-
sions used to index array. This is an array-based storage structure and there can be direct access to
array data structures.
HOLAP (Hybrid Online Analytical Processing): Stores detailed data in RDBMS. Stores aggregated
data in MDBMS. User access via MOLAP tools

Difference of OLTP and OLAP

OLTP System OLAP System
Holds current data Holds historical data
Stores detailed data Can store both detailed and highly summarised data
Data is dynamic, i.e. changes with every transaction Data is largly static
(Contd)
516 Enterprise Resource Planning

(Contd)
Transaction driven Analysis driven
Supports day to day transactions/decisions Supports strategic decisions
A large number of operations users uses the system Low number of managerial users uses the system
High number of transactions in the system Medium to low level of transactions

In short OLTP systems are used to “run” a business whereas OLAP with data warehouse helps to
“optimise” the business.

DATA MINING
Data mining is the process of extracting patterns from data. Today there is abundance of data from all
directions like supermarket scanners/POS data, credit card transactions, direct mail response, call centre
records, ATM machine transactions, demographic data, etc. A thoughtful analysis of the same can reveal
lots of useful trends and information. It is impossible to manually analyse such huge volume of data and
need automated approaches. Today’s data mining takes help of discoveries in computer science and modern
mathematics like Bayes' theorem, regression analysis, neural networks, clustering, genetic algorithms, deci-
sion trees, etc. Data mining today is used in a wide range of uses such as marketing, surveillance, fraud
detection and scientific discovery.
It is told that data warehousing provides the enterprise with a memory and data mining provides the
enterprise with intelligence. Data mining can discover valid, novel, potentially useful, and ultimately un-
derstandable patterns in data. These parameters are described as follows:
Valid: The pattern identified based on sample analysis, is valid (i.e. holds true) for the entire data-
set.
Novel: Non-obvious to the system. This pattern was not known beforehand.
Useful: Should be possible to act on the item. We can devise actions from the patterns. If there is a
pattern discovered, but nothing can be done with that, then it is not of much use.
Understandable: The pattern should be interpretable.

Uses and Applications of Data Mining

Uses in Customer Relationship Management
Customer analysis: Identify the customers who are likely to leave for a competitor and the ones which
are likely to be the most loyal.
Targeted marketing: Identify likely responders to promotions. Rather than randomly contacting a
prospect or customer through a call centre or sending mail, a company can concentrate its efforts on
prospects that are predicted to have much likelihood of responding to an offer. It is even possible
to optimise resources across campaigns so that one may predict which channel and which offer an
individual is most likely to respond across all the potential offers.
Cross-selling: Based on earlier buying trend of a customer, the tool can recommend what other prod-
ucts they may be interested in and trying to sell them those.
Segmenting or grouping customers: Data clustering can also be used to automatically discover the
segments or groups within a customer data set.
Uses in Market Basket Analysis Market basket analysis uses data mining in retail sales. If a clothing
store records the purchases of customers, a data-mining system can identify those customers who favour
 Data Warehousing, Data Mining, Business Intelligence and Analytics 517

jeans over cotton. Market basket analysis has also been used to identify the purchase patterns of the early
adopters for a product. These consumers are people that play a key role in connecting with the concept
behind a product, then adopting that product, and finally validating it for the rest of society. Analysing the
data collected on these types of users has allowed companies to predict future buying trends and forecast
supply demands. Market basket analysis tries to answer the questions like:
Who makes purchases?
What do customers buy together?
In what order do customers purchase items?
Other Uses of Data Mining
Banking: Predict good customers based on old transactions
Credit rating: Given a database of 100,000 names, which persons are the least likely to default on
their credit cards
Fraud detection: From an online stream of event, identify fraudulent events. Which types of trans-
actions are likely to be fraudulent, given the demographics and transactional history of a particular
customer?
Medicine/Disease outcome: Analyse patient disease history. Find relationship between diseases

Data Mining Steps

Data Preparation Identify the main data sets to be used by the data mining operation (usually the data
warehouse). A target data set must be assembled. As data mining can only uncover patterns already present
in the data, the target dataset must be large enough to contain these patterns while remaining concise enough
to be mined in an acceptable time-frame. A common source for data is a datamart or data warehouse.
The next step is that the target dataset need to be cleaned. Cleaning removes the observations with noise
and missing data. Cleaning process removes noise and outliners, transform data and create common units.
Data is typically divided into two sets, the "training set" and the "test set". The training set is used to "train"
the data mining algorithm(s), while the test set is used to verify the accuracy of any patterns found.
Data mining model construction A data mining model is a description of a specific aspect of a
dataset. It produces output values for an assigned set of input values. Data mining typically involves four
classes of models:
Classification arranges the data into pre-defined groups. For example, an e-mail programme might
attempt to classify an e-mail as legitimate or spam. Common algorithms include decision tree learning,
naive bayesian classification, neural network, etc. Detailed discussion of the algorithms is beyond the
scope of the book.
Clustering is like classification, but the groups are not pre-defined, so the algorithm will try to group
similar items together.
Regression attempts to find a function which models the data with least error.
Association rule learning searches for relationships between variables. For example, a supermarket
might gather data on customer purchasing habits. Using association rule learning, the supermarket
can determine which products are frequently bought together and use this information for marketing
purposes. This is also referred to as "market basket analysis" as described earlier.
Results Validation The final step of knowledge discovery from data is to verify the patterns produced
by the data mining algorithms occur in the wider dataset. Not all patterns found by the data mining algo-
rithms are necessarily valid. It is common for the data mining algorithms to find patterns in the training set
which are not present in the general data set, this is called overfitting. To overcome this, the evaluation
518 Enterprise Resource Planning

uses a test set of data which the data mining algorithm was not trained on. The learnt patterns are applied
to this test set and the resulting output is compared to the desired output. If the learnt patterns do not meet
the desired standards, then it is necessary to reevaluate. If the learnt patterns do meet the desired standards
then the final step is to interpret the learnt patterns and turn them into knowledge.

Data Mining Cautions

Pattern True for Sample may not be True for Whole Dataset While data mining can be used
to uncover patterns in data samples, it is important to be aware that the use of non-representative samples of
data may produce results that are not indicative of the domain. Similarly, data mining will not find patterns
that may be present in the domain, if those patterns are not present in the sample being "mined".

Privacy Concerns and Ethics The ways in which data mining result can be used to raise questions
regarding privacy, legality, and ethics as data mining can uncover information or patterns which may com-
promise confidentiality and privacy obligations. The threat to an individual's privacy comes into play when
the data, once compiled, cause the data miner, or anyone who has access to the newly-compiled data set, to
be able to identify specific individuals (credit card number, account number, etc). A common way to pre-
vent this is through data aggregation. Data aggregation is when the data are accrued, possibly from various
sources, and put together so that they can be analysed. It is recommended that an individual is made aware
of the following before data are collected:
The purpose of the data collection and any data mining projects
How the data will be used
Who will be able to mine the data and use them
The security surrounding access to the data

Data Mining Vendors There are variety of vendors catering to this market.
Major players: Clementine, IBM’s Intelligent Miner, SGI’s MineSet, SAS’s Enterprise Miner
Other Data Mining Products are: DataMind (NeurOagent), Information Discovery (IDIS), SAS Institute
(SAS/Neuronets)

ANALYTICS
The definition of the term analytic applications includes business applications that analyse data for specific
business subjects (like supply chain, customer relationship management, human resource, finance, etc.) that
span industries or that are specific to industries (like retail analytics, oil and gas analytics, etc.).

BI Versus Analytics
Business intelligence is sometimes called analytics though there are distinctions between them. BI is a full
set of technologies and programmes whereas analytics comprise all specialised programmings that analyse
data about a particular field, like marketing, sales, human resource, etc. Presently, there are many analytics
available in the market such as CRM analytics, supply chain analytics, sales analytics, customer analytics,
product and service analytics, finance analytics, etc.
Analytics can be divided to two major categories such as: Descriptive analytics that focuses on history
(say, historical customer patterns) and Prescriptive analytics that focuses on trends to predict (say, customer’s
future behaviour).
 Data Warehousing, Data Mining, Business Intelligence and Analytics 519

Different Analytics Segments

Analytics can be divided into different segments as follows:
Financial and Business Performance Management (BPM) Analytic Applications These
analytic applications are designed to measure and optimise financial performance and/or establish and
evaluate an enterprise business strategy. These analytic applications are designed to measure and optimise
financial performance and/or establish and evaluate an enterprise business strategy. The major categories
are as follows:
Financial analytics: This category includes applications for financial consolidation, budgeting and
planning, activity-based costing, etc.
Business Performance Management (BPM): This category includes applications that evaluate and
measure the success of an enterprise business strategy. Examples include balanced scorecard applica-
tions and BPM that spans multiple functions.
Customer Relationship Management (CRM) Analytics These analytic applications are designed
to measure and optimise customer relationships. CRM analytics can be either industry specific (for verticals
such as financial services, telecommunications, retail, etc) or cross-industry CRM analytics (like marketing
or multi-channel CRM analytics)
Operations and Production Analytic Applications These analytic applications are designed to
measure and optimise the production and delivery of products and services. There can be different categories
of applications under this as follows:
Financial services, which include operations improvement applications aimed at banking, insurance,
and other financial services such as risk analysis, portfolio analysis, and fraud detection
Human resource management and payroll, which includes applications such as workforce planning
and optimisation
Materials management/logistics, which includes applications such as demand planning and procure-
ment optimisation
Manufacturing, which includes applications aimed at manufacturers, such as defect and quality analysis
and supply chain trend analysis
Retail, which includes operations and production-optimisation applications aimed at retailers, such as
merchandising planning and analysis and store location analysis

BUSINESS INTELLIGENCE
Business intelligence tools mainly help in reporting as per the end user requirement. OLAP, analytics, data
mining, etc. described earlier is a part of business intelligence suite. Beyond these BI tools also provide
following functionalities:
Alerts: BI solutions can provide alerts capabilities, i.e. whenever there is a difference between planned
and actual performance and the difference crosses beyond a limit, BI solutions can provide automatic
alerts. These alerts can spin off an automatic workflow.
Scorecards: BI solutions can display metrics displayed in a dashboard and align key performance
indicators to a strategic objective. Scorecard metrics are linked to related reports and information in
order to do further analysis.
Dashboards: These BI dashboards indicate the state of the performance metrics, compared with a
goal or target value.
520 Enterprise Resource Planning

Ad hoc query: This is known as self-service reporting, enables users to ask their own questions of
the data, without relying on IT to create a report.
Workflow: BI application can have strong workflow capability so that reports and alerts can be trig-
gered and sent to right user.
Data delivery: BI tools can provide multi-channel delivery capabilities, i.e. BI functionality be delivered
embedded in operational applications such as ERP or CRM or via mobile devices, such as iPhone. It
is important that the BI product to be integrated with office products.
Customisation of reports based on user profile: BI products can customise reports, queries, or
dashboards based on user profile.
Predictive modelling and data mining using advanced mathematical techniques.
Visualisation: BI tools can provide strong data visualisation capabilities, i.e. data analysis in the form
of different charts and interactive pictures.
Slice and dice of data: As discussed earlier, BI tools have multi-dimensional data analysis capabilities
in the form of drill down, drill across (slice and dice), ability to drill from one dimension to another,
etc.

Leading Business Intelligence Vendors

Business intelligence market has seen a lot of action in recent times. Earlier, this market used to be domi-
nated by specialised nitch vendors like Brio, Business objects, etc. Of late, ERP vendors started building
strong capabilities around this leading to some large-scale takeovers. SAP’s take over of business object is
the one most discussed. Today this market is dominated by following vendors:
Business Objects (taken over by SAP recently)
Cognos (taken over by IBM recently)
SAP (SAP Business Intelligence is SAP’s flagship product)
Brio
Oracle
SAS Institute
Hyperion

Summary
Data warehousing tools help in storing large volume data for future analysis.
Four important characteristics of data warehouse are: Subject-oriented, integrated, time-variant and non-
volatile.
Advantages of data warehousing are: Common data model, clean data, storage of data for longer period,
facilitating reporting. Disadvantages of data warehousing are: Latency factor and no capability of storing
unstructured data.
Star schema is the heart of data warehouse and it is composed of facts and dimensions. Attributes provide
further information about the data.
Datamart is a subset of data warehouse that handles small volume of data and offer better flexibility and
response time for users.
Operational data store (ODS) stores data at most detailed level for a brief period of time and where data can
be overwritten.
 Data Warehousing, Data Mining, Business Intelligence and Analytics 521

ETL tools helps in extracting data from source systems, transformation and cleaning of data and finally load-
ing to target systems.
The main difference between OLTP and OLAP application is that while the former is used to run the business
transactions, the latter focuses on analysis and optimisation.
Data mining tools help in understanding the pattern in data and can be useful for customer analysis, market
basket analysis, credit rating, fraud detection, etc.
Analytics focuses on particular business functions like HR, marketing, etc. and do all sorts of analysis of
business data related to that function.
While business intelligence tools provide all the capabilities of OLAP and data mining, it also provides ad-
ditional capabilities in terms of dashboard, workflow, scorecards, alerts, predictive modelling, etc.

Exercise
I. Objective Type Questions
1. What is a data warehouse?
2. What are the four important characteristics of a data warehouse?
3. What is meant by “Latency Factor”?
4. How does data warehouse help in improving performance of operational systems?
5. What is a Star Schema?
6. What is meant by ‘Fact Table” and “Dimension Table”?
7. What are “Attributes”?
8. What is a data mart?
9. What is an ODS?
10. What are the three tiers of data warehousing architecture? What each of the tier does?
11. What are the three options of refreshing data in a data warehouse?
12. What is delta refresh?
13. What is data partitioning?
14. What is meant by uniqueness of data?
15. What does ETL stand for?
16. Who are the leading ETL vendors?
17. What is OLAP?
18. What is OLTP?
19. What are the three possible analysis tools in OLAP?
20. What is slice and dice?
21. What is meant by drill up and drill down?
22. What is a dimension hierarchy?
23. What is a multi-dimensional data cube?
24. What is ROLAP, MOLAP and HOLAP?
25. What are the four properties of patterns identified by data mining?
26. What is market basket analysis?
27. What are the four uses of data mining in customer relationship management?
28. Tell four other uses of data mining tools.
29. Who are the major data mining vendors?
30. What are the four classes of data mining models?
31. What is “association rule learning”?
522 Enterprise Resource Planning

32. What is analytics?

33. What are two different types of analytics?
34. What are the three different segments of analytics applications?
35. What is business intelligence?
36. What is meant by dashboard and scorecard?
37. Who are the leading business intelligence vendors?

II. Descriptive Type Questions

1. Define a data warehouse. What are its characteristics? Discuss the advantages and disadvantages of a data
warehouse.
2. Explain a star schema. Define fact and dimension table. What are the advantages of a star schema?
3. What is a data mart? What are its characteristics? What are the advantages of a data mart? How a
data mart is different from data warehouse?
4. What is an ODS? What are its advantages? What are the similarities and differences between a data
warehouse and an ODS?
5. What are the typical capabilities of a data warehousing tool?
6. Explain the three-tier architecture of a data warehousing tool.
7. What are the advantages and disadvantages of storing data at summarised level or at most detailed level?
8. What are the properties of cleaned data/quality data?
9. What are ETL tools? How does it help in extracting, transforming and loading data? What are the areas of
usage for ETL tools? How does ETL tools help in data migration?
10. Explain OLAP and OLTP processing. What are the characteristics of each type of processing? How are
they different?
11. What are the possible analysis options in OLAP? What are the OLAP functionalities? What are the strengths
of an OLAP tool? What are the three types of OLAP?
12. What is data mining? What are the properties of the pattern identified by data mining? What are the uses
of data mining? How is data mining useful for customer relationship management?
13. Explain the steps of data mining. What cautions are needed to be taken while mining data.
14. What is analytics? How is it different from business intelligence? What are the different segments of analyt-
ics? Explain each of them.
15. What are the typical capabilities of a business intelligence tool?

III. Fill in the Blanks

1. BI stands for _______________ _____________.
2. OLAP stands for ________ ________ _________ ___________
3. OLTP stands for ________ ________ _________ ___________.
4. DSS stands for ________ ________ _________ .
5. EIS stands for ________ ________ _________.
6. MIS stands for ________ ________ _________.
7. ODS stands for ________ ________ _________.
8. ETL stands for ________ ________ _________.
9. Star schema is ___________ for reporting.
10. Two options of refreshing data in data warehouse are __________ refresh and ___________ refresh.
11. ROLAP stands for ________ ________ _________ ___________.
12. Classification means arranging data into _________ groups.
 Data Warehousing, Data Mining, Business Intelligence and Analytics 523

IV. State Whether the following Statements are True or False

1. A data warehouse is time-variant means it provides historical information.
2. A data warehouse is non-volatile means data once recorded can be updated.
3. Data warehouse provides a common single data model.
4. Star schema is made up of one dimension table and multiple fact tables.
5. Data mart contains more data than data warehouse and is difficult to navigate.
6. Data marts do not contain detailed operational data like data warehouse.
7. ODS stores data in flat tables and stores most recent information.
8. Integrity means expected relationships between multiple data sets.
9. OLAP systems hold current data.
10. OLTP systems hold static data.
11. Clustering tries to group similar items together.
 34
ERP and Enterprise
Applications—Emerging Chapter
Trends

Learning Objectives
In this chapter we will discuss the following concepts:
New Models of Deploying ERP
SaaS (Software as a Service)
Cloud Computing
Hosted ERP
SOA (Service Oriented Architecture)
New Technologies that Made ERPs more Effective:
RFID
Mobile Business or M-Commerce
EAI (Enterprise Application Integration)
ERP II – ERP with the Power of Internet

NEW MODELS OF DEPLOYING ERP AND ENTERPRISE

APPLICATIONS
The biggest bottleneck for companies implementing ERP or any other enterprise applications (like CRM,
PLM, etc.) is the huge upfront cost for buying hardware, software licences and implementation. This may
run into several crores and not an easy task, especially for SMB (small and medium business) segment. ERP
vendors and consulting companies implementing ERP solutions are trying to find an answer to this issue for
a long time. SaaS and Cloud Computing are two possible technologies to address this. While SaaS promises
to reduce the upfront software licence cost, cloud computing promises to reduce the upfront cost in hardware
for implementation. Hosting ERP is another option that also can be considered which may work out to be
a bit costlier then SaaS option, but gives companies additional benefits of customising the solution as per
their requirement. Finally, service-oriented architecture is a new model of building applications for tomorrow
using reusable and modular services that can be exposed from different applications and can be combined
together to build a new application with minimum programming and integration hassles.
 ERP and Enterprise Applications—Emerging Trends 525

Software as a Service (Saas)

Software as a service (popularly known as SaaS) is a concept gaining popularity in the last few years among
package application vendors. This model of software deployment over the internet is also knows as “software
on demand” and in some cases as “Hosted application”. With SaaS, a service provider licences an applica-
tion to customers for use as a service on demand through time subscription or “pay-as-you-use” model. This
model allows vendors to develop, host and operate software for customer use. Rather than purchasing the
hardware and software to run an application, customers need only a computer or a server to download the
application and internet access to run the software. SaaS software vendors can adopt different approaches
for giving its customer access to the application, i.e. they may host the application on their own web serv-
ers, upload the application to the consumer device and disabling it after the contract expires i.e. when the
customer stops making payment for it.
While SaaS had become a reality in the last decade, this was a long desire for companies – why they should
invest in the software upfront? Can it not be used the same way power or gas companies supply electricity
or cooking gas, i.e. you use it when you need and just pay for the number of units consumed. Extending the
same concept to the ERP world, a company will need an ERP application while raising a purchase order or
while creating a goods receipt or creating an invoice or doing some planning. The company will pay to the
ERP vendor for doing this service, i.e. running these transactions on vendor’s package, each time he uses
it. ERP vendor or service provider takes care of everything else, i.e. maintaining the software, upgrading
and applying patches as and when required, securing company’s data, etc. This is a much simpler model
for customer as there is no fixed cost and the entire cost of operating the software becomes variable and the
point software is no longer required, the customer can stop paying.
While SaaS was widely deployed initially for sales force automation and customer relationship man-
agement (CRM), gradually it became popular for applications like computerised billing, invoicing, human
resource management, service desk management, sales pipeline management, etc.
SaaS Characteristics
Network based access to a business software, i.e. software is not installed in user’s machine. Custom-
ers can access applications remotely via the web.
Activities (like maintenance) are managed from a central location rather than at each customer's site.
This means end users need to download patches and upgrades.
SaaS application delivery follows a one-to-many model (i.e. single instance of software delivered to
multiple tenants than to a one-to-one model).
Generally SaaS vendors price applications on a per-user basis mostly with a minimum number of us-
ers and with additional fees for extra bandwidth and storage. SaaS revenue streams to the vendor are
thus, lower initially than traditional software licence fees, but are also recurring, and, therefore, more
predictable.
SasS Benefits The argument for SaaS is compelling. Enterprises are spared investment in hardware and
infrastructure, not to mention the ongoing costs of installing and maintaining their solutions. Resources are
freed up for other areas and staff can prioritise more business-critical operations. This is particularly attrac-
tive for small and medium enterprises (SMEs) that lack the IT staff or expertise to deploy and manage their
applications in-house. The pay-as-you-go subscription model also allows enterprises to operate on a fixed
budget, while leaving room to scale up as business demands.
Save money for customers as the entire cost is variable and there is not fixed cost or upfront invest-
ment. Easy to calculate ROI.
526 Enterprise Resource Planning

Multi-tenant efficiency as the software is used by multiple companies and chances are that the softwatre
is never idle and is always used by someone
Faster releases of new features since the entire community of users benefits from new functionality
Flexibility and scalability
SaaS Drivers SaaS concept had grown a lost in the last few years and had become much more accept-
able in the industry for the following reasons:
Growth of adoption of package applications/ERPs by SMBs: Upfront licence cost is the major
driver here. While SMBs use to take advantage of applications like ERP or CRM to make their busi-
ness processes more efficient, they do not want to invest in huge licence cost upfront.
Computing has become a commodity: Increasingly, companies have understood that what differenti-
ates one company from others is its business processes, data, customer records, pricing information,
etc. and not the computing power, i.e. so long as these things are protected it does not matter where
the application is running. This was a big change in mind share which made adoption of SaaS a
reality.
SaaS had become more popular for applications that are more standardised and processes do
not vary much across the industries. For example, a human resource management application where
recruitment process is not very different between companies.
More matured software evolution: Increasingly softwares are coming where a new requiremenmt
can be addressed by changing configurations/parameterisation and do not need a programme change.
Earlier, this was a challenge as any change means changing the code, but today a single software
can be customised/parameterised in hundred different ways to suit requirements for several different
companies/industries.
Software hosting capability had matured over years: Hosting had opened up a global opportunity
for software vendors as now anyone can target global market, if he has the right product. A company
that used to make accounting software only for dairy firms and had a hard time to sell its applications,
but today if he hosts the application, he can instantly reach the entire market.
Network, Bandwidth and Security is becoming more reliable: Despite sporadic outages and slow-
downs, most people are willing to use the public internet, the TCP/IP portocol to deliver business
functions to end users. Security today is sufficiently well trusted and transparent. Bandwidth of wide-
area networks has grown drastically and is about to reach slow local networks bandwidths. This has
driven people and companies to trustfully access remote locations and applications with low latencies
and acceptable speeds.
ERP as SaaS While SaaS is becoming popular in most business application categories, enterprise ap-
plications like ERP or CRM are no exception. ERP software as a service means the complete offering of the
application on a hosted environment including ongoing bug and release maintenance and backup/recovery.
SaaS is the software that is provided literally “as a service”. As opposed to the traditional ERP model where
enterprises purchase software licences and deploys applications in-house, SaaS applications are delivered
and managed remotely via a secure internet connection and a standard web browser. Access is charged on
a subscription basis at a fixed price per user, usually on a monthly basis.
With SaaS, the same ERP software version serves different customers – with one code base for all. The
model operates primarily on a “multi-tenant” architecture, providing one operating environment for multiple
customers. Applications are shared across customers on a common database, but data is managed securely in
separate clients. The key premise is investment of the service provider in technology, hardware, and ongoing
support services as opposed to the customer.
 ERP and Enterprise Applications—Emerging Trends 527

The major issues for customers for putting a mission critical application like ERP on SaaS are:
Security of customer-specific data. Many enterprises shy away from the idea of storing their data on
a third-party system and surrendering control of their information. In reality, even though companies
converge on one database, the multi-tenant concept separates customer data across different clients.
Maintaining a high level of availability and performance of the system as it is difficult to afford
a downtime on system like ERP which is heart of company’s business operations. As under SaaS,
the system is not under the direct control of the user and it puts higher responsibility on the service
provider who is offering SaaS as a service. Enterprises with a low downtime tolerance will not fare
well on this model as for some maintenance may come at a critical time for their business like during
financial closing.
Another limitation is the requirement to stick to a standard solution. Separate hosted systems with
customer-specific customisation are possible, but this waters down the benefits of the SaaS model.
Even though most SaaS solutions provide standard open interfaces to other applications, costs quickly
add up on integration into a complex landscape. Another drawback of a homogeneous solution is the
lack of competitive edge as using the application offers an individual enterprise.
So offering ERP under SaaS need special capabilities for service providers in terms of:
A very thorough understanding of how the software is being used by client base.
The ability to maintain and upgrade the software remotely. Oracle offers something called CEMLIs
(configurations, extensions, modifications, localisations and integrations) for their softwares which
are offered under SaaS.
Ensuring high system availability, i.e. virtually no downtime is acceptable.
The difference of ERP/CRM application with other commercial software is that it need customer-
specific configuration and the standard software out of the box may not suit the requirements of
customer. Success of ERP/CRM software as SaaS will depend on offering the industry best-practice
configurations as well as the ability for the customer to do further configuration. The ERP vendors
that can not offer industry-specific and customer-specific configuration will find themselves serving
a very small market.
ERP SaaS vendors are increasingly able to provide applications configured to an enterprise’s needs. The
whole model is based on using standard solutions and customer-specific adaptations, with interfaces kept
to the minimum. Users access everything they need over the Internet and employees use the same version
of the software regardless of their location. An implicit benefit of this level of standardisation is simplicity,
and hence high usability.
There are two popular pricing models for ERP software as a service and these are:
Month to month: This kind of service will involve an upfront configuration/set-up fee and a by-month
per-user fee.
Contracted period of time: This kind of service will be priced for a fixed number of users over a fixed
period of time. This kind of service also allow for more users to be added on the basis of require-
ment.

SAP Business ByDesign is SAP’s answer to SaaS. Delivered as a service and fully managed by SAP,
customers can deploy the complete solution or add modules as per their need. With built-in ser-
vice and support, SAP Business ByDesign aims to simplify IT for midsize companies and reduce
cost of ownership.
528 Enterprise Resource Planning

However, SaaS has changed the game for the software industry and traditional ERP vendors are feeling
the pressure as customers are no more interested in expensive licences and lengthy implementations, and
turn to on-demand software. ERP vendors that have recognised the opportunity and made the move towards
SaaS need to adjust to new revenue models, with a steady stream of subscription-based income replacing
the big bang of upfront licence sales.

SAAS SUCCESS STORIES FROM INDIA

HRMantra launched SaaS-based products in India in June, 2006 and started by offering HRM payroll
software. Today, it offers numerous modules which are focused on diverse areas of HR manage-
ment, such as module for leave, performance management modules to name a few. HRMantra
has done significantly well with a customer base of more than 70, where the smallest client has a
headcount of 6 and the largest 1800. On-demand HRM includes the following modules:
Induction: Company induction policies, holiday calendars, etc.
HRIS: Employee information management
Attendance: Employee attendance management
Leave: Employee leave management
Claim: Claim and re-imbursement management
Payroll: Employee salary and income tax management
Appraisal: Employee performance management
Training: Employee training management
Staffing: Candidate recruitment management
Project: Project team management and time-sheet tracking
Funds: PF trust management
Administration: Asset and travel management
Impel: PK4 Software Technologies Pvt. Ltd. is a Bangalore-based software company and Impel
is its flagship On-demand CRM product. Currently, Impel has more than 800 customers with its
smallest customer having a revenue of Rs. 5 crore and largest having revenue of Rs. 500 crore. It
offers 3 editions of its on-demand CRM package, i.e. Team edition, Corporate edition, Enterprise
edition. The major features of Impel include:
Sales force automation
Marketing automation
Customer support
Email and collaboration
Product management
Quotes and order management
Inventory management
Report management

Cloud Computing
SaaS solves the first part of the problem, i.e. a company need not invest upfront of the ERP licence and can
pay on use basis. Cloud computing addresses the next part, i.e. a company need not invest on the hardware
also upfront for deploying a business application like ERP and can pay for it based on usage, i.e. computing
 ERP and Enterprise Applications—Emerging Trends 529

infrastructure is available on demand. Thus, cloud computing is a way of computing, via the Internet, that
broadly shares computer resources instead of using software or storage on a local PC.
The term "cloud" had its origin in telecommunication industry, who earlier used to offer dedicated
point-to-point data circuits and in the late 90s started offering virtual private network (VPN) services with
comparable quality of service, but at a much lower cost. In 2007-2008, some of the large IT organisations
like Google and IBM started large scale cloud computing research project to make this idea a commercial
success.
Cloud computing customers do not own the physical infrastructure, thus, aoiding capital expenditure (on
hardware, software, and services) by renting usage from a third-party provider and pay the provider only
for what they use. They consume resources as a service and pay only for resources that they use. Thus,
this model is close to utility computing model, the way traditional utility services (such as electricity) are
consumed, where consumers are billed on a subscription basis. As computing power gets shared among
multiple tenants can improve utilisation rates, as servers are not unnecessarily left idle. Other benefits of
this time-sharing-style approach are low barriers to entry, shared infrastructure and costs, low management
overhead, users can terminate the contract at any time and the services are often covered by service level
agreements (SLAs) with financial penalties. Today’s high-speed network bandwidth has made it possible
to receive the same response times from a centralised infrastructure as it is from a local site. Figure 34.1
explains the concept of cloud.

Fig. 34.1 Cloud Concept

Critics against cloud theory remarks that although companies might be able to save on upfront capital
expenditures, they might not save much and might actually pay more for operating expenses. So, in situa-
tions where the capital expense is relatively small, the cloud model may not make great financial sense.
Advantages of Cloud Computing
Cost reduction: There is no upfront investment and capital expenditure is converted to operational
expenditure as infrastrucure investment, maintenance everything is provided by a third-party.
530 Enterprise Resource Planning

Improvement in efficiency and utilisation: Multi-tenancy enables sharing of resources and costs
across a large pool of users, thus, allowing better utilisation of servers.
Centralisation of infrastructure: As one data centre can now serve multiple customers, along with
hardware cost it also reduces associate cost like real estate for putiing the centre, running cost (refrig-
eration, etc).
Individual companies need not design the hardware based on peak load: In case companies
decide to have the hardware at their own premises, hardware sizing is always done based on peak load
assumption, thus, resulting in hardware not used during most part of the day. In case of cloud
computing, this problem does not arise as someone’s peak load may be balanced by another customer’s
lull demand.
Scalability: Resource requirement can be increased or decreased instantly as payment is on usage
basis. Such ramp up and ramp down is difficult with own hardware.
Easier maintenance: Maintenance is easier since patches need not be be installed on each user's
computer, any changes are done centrally and reach clients immediately.
Better reliability : A cloud computing infrastructure can afford multiple redundant sites, thus, offer-
ing better business continuity and disaster recovery. Maintaining such multiple DR (disaster recovery)
sites is very costly for an individual company.
Measuring resource usage: This is measurable on hourly or daily basis as all the costs are variable,
but that is difficult, if the infrastructure is totally owned by the company.
Infrastructure is available anytime anywhere: Users can access systems using a web browser regard-
less of their location or what device they are using (e.g. PC, mobile), infrastructure can be accessed
via Internet and users can connect from anywhere.
Areas of Cloud Computing
Database as a service
Desktop as a service
Disaster recovery as a service
Infrastructure as a service
Integration as a service
Platform as a service
Storage as a service

Hosted ERP
Sometimes this is confused with SaaS. While Hosted ERP and SaaS conceptually comes very close, there are
differences between these two. ERP hosting is typically done for a particular customer, i.e. it does not follow
multi-tenant architecture. The application is hosted in a service provider’s data centre. While under SaaS
model, the same standard software need to be used by all the tenants and no modification in custom code or
configuration is possible, in case of hosted ERP, as the application is hosted for a particular customer, code
modification or customisation is possible as per the customer’s requirement. Unlike SaaS where the customer
pays a monthly subscription fee (and they do not own the licence), in case of hosting, customers need to
pay licence fee (and they own the licence). In case of SaaS, software vendor decides when to upgarde, but
in case of hosting, the customer takes the decision on upgarde timing and whether to upgrade at all.
The difference between SaaS and Hosted ERP is discussed in Table 34.1
 ERP and Enterprise Applications—Emerging Trends 531

Table 34.1 Difference between SaaS and Hosted ERP

Criteria SaaS Hosted ERP

Architecture Multi-tenant Single Tenant
Fee structure Subscription-based Licence
Licence ownership ERP vendor Customer
Software customisation/code modification No Yes
possible
Application hosting–Who does? ERP vendor’s data centre Service provider’s data centre
Application upgrade–Who does? ERP vendor Customer
Application and infrastructure maintenance ERP vendor/software publisher Service provider
–Who does?

Hosting ERP is becoming popular among customers looking for outsourcing their existing ERP implemen-
tations to avoid capital outlays associated with significant hardware or software upgrades and customers
lacking access to knowledgable ERP staff. Leading ERPs like SAP and Oracle are looking at hosting as
a possible source of new revenue stream for managed services (beyond their traditional licence revenue).
Oracle announced its On-demand programme sometime back to support hosting services for Oracle, J D
Edwards and Peoplesoft application. SAP still provide hosting service through its partners.

Service-oriented Architecture (SOA)

Constant change is the reality of every buisness today. Organisations who thought that they have completed
their ERP implementation need to go through this coninuous change process as new businesses are acquired,
new product lines get launched and all these need new processes. The TO BE processes which was configured
and developed during ERP implementation now need a re-look as some of them got changed and some of
them need to be integrated with new legacy applications (of a new business which the company has recently
acquired). In the earlier days this meant developing a new application from ground up or building a new
interface from scratch. However, in the last decade all these had changed with emergence of a new concept
called “Service-oriented Architecture,” popularly known as SOA. However, before talking about SOA, let’s
explain another related concept called “Enterprise Service Architecture”.
Enterprise services architecture tells us how to build software that will meet our needs now and in
the future. Enterprise services architecture is not a product that can be bought from market or a design
guideline for one particular system (say, ERP or CRM). It is a style of developing software, based on a set
of services.
What is Service? Services refer to the building blocks, the containers in which the data and programmes
from ERP, CRM, and so on, are collected for use in creating new systems. These building blocks that can
be understood both by business executives and IT staff (and thus, bridges the gap between them) because
each of these services is actually a business function like creating invoices or raising purchase orders.
Figure 34.2 shows a set of services for a business process.
Reusability The greatest advantage of this service concept its reusability and integration with services
from other application. For example a purchase order process for an organisation can be broken to a set
of services like creating purchase requisition, pricing, tax calculation, workflow for approval and creation
532 Enterprise Resource Planning

Fig. 34.2 Set of Services for a Business Process

of purchase order. Now a set of these services like pricing, tax calculation or workflow approval can be
reused across many business processes like pricing is important for sales order process, service ordering,
contract management etc. Workflow approval can be reused for leave approval in human resource manage-
ment, incentive approval for sales staff, etc. So, these services works like independent components of the
application that can be used across several business processes.
Easy Integration The second advantage of service concept is easy integration and loose coupling. This
means the service from one application can be quickly integrated with service from another application to
build a new application. For example, a customer wants to design a sales order management process where
sales order entry will happen in SAP CRM application, pricing of this order will happen in Oracle ERP
and credit check against this will happen in a legacy application. In the older days this would have been
a very difficult exercise involving lot of programming. In SOA world this is a pretty simple task where a
service of order entry from SAP CRM, a service of pricing from Oracle ERP and a service of credit check
from legacy application can be quickly integrated to build a new business process that run across several
applications. This is easy to integrate as any service which is exposed as a web service follow the same set
of standards and it does not matter in what programming language they are written or on which platform
they are. They can be integrated very easily.
These web services are building block for service-oriented architecture. These services are functional
building-blocks accessible over standard Internet protocols independent of platforms and programming
languages.
Presently, all leading ERP vendors have started building a repository of enterprise services for differ-
ent business processes/functionalities they offer as part of their ERP or enterprise solution. SAP had first
published its enterprise services inventory in 2005. From 2006, SAP’s Business Suite had come with ready-
made enterprise services that reside in an enterprise services repository, a part of SAP NetWeaver which has
 ERP and Enterprise Applications—Emerging Trends 533

more than 10,000 services in its repository. A single purchase order process can be broken down to several
services like purchase order requisition, purchase order confirmation, purchase order change request, and
so on. Oracle Application Server 10g also has a number of such services. IBM WebSphere, BEA Systems’
WebLogic are few non-ERP leading platforms for developing web service-based application.
What is SOA? SOA is a flexible set of design principles that is used during system development and
integration. SOA relies on a mesh of software services described earlier which are loosely coupled and can be
combined to build any business process application (sometimes these are known as composite applications).
SOA defines how to integrate widely disparate applications for a world that is web-based and can use multiple
platforms from different vendors like SAP (NetWeaver), Oracle, IBM (Websphere) or Microsoft (.Net). SOA
helps in building large applications from existing software services reducing the need of programming and
testing to bare minimum as these web services from different applications are already tested.
So fundamental principles of SOA are:
Reusability: Logic is divided into services with the intention of promoting reuse.
Modularity: Ecah service is modular and independent – can perform a business function indepen-
dently.
Composability: Collections of services can be coordinated and assembled to form composite ser-
vices
Componentisation
Interoperability
Loose coupling
Standards-compliance
SOA Benefits
SOA can help businesses respond more quickly and cost-effectively to changing market-conditions.
This style of architecture promotes reuse and, thus, what has been already developed can be reused
saving time and cost.
Dramatically simplified testing as services are independently fully tested by the vendor who publishes
it with full documentation of interfaces.
Application integration savings: Today, applications are typically custom-integrated point-to-point,
and each integration requires development and testing. Having a service-oriented interface to each
application can save 30% to 40% on each integration point. Rather than point-to-point integration,
SOA has a hub-and-spoke configuration, reducing integration points substantially.
Because interfaces are platform-independent, a client from any device using any operating system
(OS) in any coding language can supposedly access or use the service.
SOA also opens up opportunities for thousands of small nitch vendors who have specialised knowledge
in a particular business process – now they can build application which can be quickly integrated with
SAP or Oracle prividing them larger market opportunity. It is win-win for SAP and Oracle as well as
it increases their breadth of offering.

NEW TECHNOLOGIES THAT MADE MODELS OF DEPLOYING

ERP MORE EFFECTIVE
In this part few emerging technologies like RFID, EAI, M-Commerce and ERP II are discussed that helped
to make ERPs of today more powerful.
534 Enterprise Resource Planning

RFID
RFID is the most talked about technology in modern time. RFID was originally developed to identify
friendly aircraft during World War II for radio frequency identification. A typical RFID system uses RFID
tags attached to objects, which identify themselves when detecting a signal from an RFID reader by emit-
ting radio waves/signals transmission. An RFID tag has an EPC code which contains an array of product
information and this can uniquely identify the individual item whether it is an item, case, pallet or anything
else. The tags contain RFID antennas that communicate the EPC numbers to the EPC readers within the
EPC global network. RFID uses radio waves to read the data from products or pallets or any other object.
Unlike bar codes, where the person has to go to the item to read it, RFID-enabled items transmit the item
code automatically when they detect reader signal. The reader is just like bar code scanner, which has a
radio module that transmits radio signals to read the data from RFID tags. Standards are key to proliferation
of RFID technology.
Technology
Figure 34.3 shows the main components of RFID and these are:
Tags: Data is embedded on tags and consist of an integrated circuit (IC) and antenna. There are
different types of tags and depending on application, cost varies. Active tag can transmit over a longer
range, i.e. 100 ft or more, tracks expensive items and equipped with battery and cost is high (around
Rs. 800-1000). Passive tags can not be kept far from the reader as it receives power from reader. Cost
of passive tags are less, i.e. Rs. 20 to Rs. 50. It can be used for different applications like checkout
counter in retail, inventory control in store, tracking of items in supply chain, etc. RFID tags support
electronic product code (EPC) formats.

Fig. 34.3 RFID Technology Components

 ERP and Enterprise Applications—Emerging Trends 535

Readers: Readers can talk with tag via RF, the antenna on tag and reader allows RF waves to connect.
Reader’s cost can vary from few dollars to something very expensive depending on the application it
is built for and the type of tag it is communicating with.
Advantages of RFID over Traditional Bar Code RFID is often compared with traditional bar code
software, but this technology offers many advantages compared to traditional bar codes and these are:
RFID’s most talked about advantage is that it does not require a line of sight seeing between reader
and tag. In case of bar code, each item must be presented to scanner in a particular orientation and
need to be bought sufficiently close to the scanner so that a person can scan each item with the laser
beam.
RFID tags can hold lots of data up to hundreds of characters whereas bar codes can store only 12-15
digits. RFID tags can be rewritten thousands of times whereas bar codes can be printed only once
on a product label. On an RFID tag at different nodes of supply chain, i.e. factory, warehouse, etc.
data can be continuously added which is not possible for bar code. Once the bar code is printed, it is
frozen.
Manual labour associated with reading bar-code data is reduced because the RFID scanning device
can gather data automatically from the items kept deep inside boxes.
Disadvantages
Bar codes are there for sometime now and had reached high level of maturity whereas RFID needs
to stabilise on standards.
The main barrier of RFID technology is the cost of the tag. Even the low cost RFID tags costs 50 times
that of a label printing by bar codes. Added to this, there is cost of RFID readers. Most of the companies
who already had invested in bar code readers installed and there is a change over cost to RFID. High
cost of RFID tags force companies to do carton or pallet level tracking instead of item level tracking.
Item level tracking for RFID is only applicable for costly items like jewellery, furniture, etc.
ERP and RFID Technology Together can bring Numerous Benefits to Organisation
ERP with RFID technology can bring lot of benefits to the organisation. Figure 34.4 explains some of these
benefits and these are detailed below:

Fig. 34.4 Several Benefits that RFID Provides in the Supply Chain
536 Enterprise Resource Planning

Tracking of items: There can be different definitions of tracking. However, in simple terms what it
means is the capability of locating a particular SKU throughout the supply chain. As an RFID tag can
contain lots of information like manufacturing date, time spent in transit, location of the place hold-
ing the item, item value, expiration date, warranty period, etc. This provides the ability to locate or
track a product through the supply chain. This is important for today’s supply chain as due to global
sourcing, products today cover multiple borders, chances for tampering and counterfeiting is high here
and returns need to be tracked. So their can be different benefits of proper tracking like reduction of
out of stock, tracking and validating returns, reduction in labour costs etc. Some limited amount of
tracking is possible in ERP software as well through functionality like batch management, but ERP
along with RFID technology can provide much advanced tracking capability.
Inventory management: RFID improves inventory management in several ways like it increases
visibility of inventory throughout the supply chain and reduces the need for safety stock, out-of-stock
and theft. It also helps in automatic counts of inventory instead of manual shelf count.
More efficiency in good receipt: RFID can optimise the goods receipt process by error free receipt
and brings more speed in the receipt process.
Reducing shrinkage: RFID can reduce shrinkage of costly items (like jewellery, electronics items,
high-end fashion garments, etc.) in the supply chain as can be tagged and tracked. This not only re-
duces theft but also ensures that the products are not missed out in the supply chain.
RFID tag reading in distribution centres can work as proof of delivery and no separate POD is re-
quired.
Some Examples of RFID Implementation in India

DHL is using RFID in tracking shipments between aircraft and from airport to truck to improve
operational savings and improved security.
Nokia has placed RFID on cases of ten packs cell phones for anti-theft and tracking purposes.
Best Buy started case and pallet tracking and tagging by suppliers.
Marks and Spencer tagging men’s suits in stores and mandating suppliers tag products.
Metro in Germany started case and pallet tracking and tagging by suppliers.
Target started case and pallet tracking and tagging by suppliers.
Wal-Mart started case and pallet tracking and tagging by suppliers – live in most of the stores,
distribution centres, Sam’s club and key suppliers.
Tesco had started item level tagging of high-value/high-margin items like DVDs.
RFID in India: Pantaloon Retail (India) has piloted an RFID project at one of its central warehouses
in Tarapur and in future planning to extend it to branch offices or retail outlets. The retailer se-
lected a few lines of apparel, primarily shirts and trousers—John Miller formals and casuals—for
its RFID pilot. The RFID application covers all the processes from factory outward to warehouse
inward and from the warehouse outward with the aim of capturing real-time data. The applica-
tion is integrated with Oracle database. At the factory outlet, RFID tags were attached to the
merchandise and the data written to them. When the RFID-tagged merchandise comes through
the inward gate, all related information such as purchase and delivery orders will be fed into the
inward terminals in real-time. Once the RFID-tagged goods are passed through the outward
terminal, the tags are removed.
 ERP and Enterprise Applications—Emerging Trends 537

How ERP Vendors are Adopting RFID RFID is getting popular for certain business processes like
inventory management, managing warehouse operations, tracking material movements, etc. and for certain
industries like pharma and electronics where unit value of the items is high and chances of spurious mate-
rial entering the supply chain is much higher. Every leading ERP vendor today has come up with an RFID
roadmap for their application and made some of their modules like warehouse management and inventory
management compatible with RFID.
For example, leading ERP vendor SAP had come up with an Auto Id Infrastructure (AII) strategy long
back in the year 2005. SAP had also made number of its ERP modules compatible with AII standards. Oracle
and other leading ERPs also support RFID today.

Mobile Business and M Commerce

Mobile applications are the next generation of technology enablement that leading ERP vendors are looking
at for bringing efficiency in supply chain and customer service process. Mobile and wireless applications
are used for variety of usage today. Figure 34.5 is an example from retail industry and it shows the different
kinds of retail usage for which mobile applications can be used. For example, store personnel can perform
mobile, real-time inquiries through handheld devices like if a store manager sees that a particular item’s
stock is below minimum stock level on a particular day, he can check instantly using the item tag whether
the product is in stock in another store, if the item is located he can and even place an order remaining in
the store with the delivery instruction of directly shipping to customer.

Fig. 34.5 Typical M-Business Transactions

Advantages of Mobile Technology Mobile devices along with backend ERP applications may pro-
vide lot of benefits to company’s employees. This is a new channel for field staff to access the ERP system
anytime anywhere to provide better service and to increase their productivity. Some of the obvious benefits
are listed below:
It is very useful for sales staff or service/maintenance staff who most of the time remains in the field
and for whom it is difficult to come to office for doing transactions in ERP or enterprise applica-
tions.
Sales associates can provide quick real-time service to their customers using mobile device. For ex-
ample, a sales staff visiting a customer got an enquiry for a new item, he can quickly take down the
enquiry details, goes to a close internet centre where he synchronise the data in the mobile device
with backend ERP application and check that whether the item is in stock. If it is in stock, he can get
538 Enterprise Resource Planning

the price information and immediately gives a price quotation to the customer. Things can be done in
minutes instead of days.
Mobile devices increases sales people’s productivity as while visiting a customer they can quickly get
access to all information related to the customer like its past transactions, what products he bought at
what price, any past complaints from him, etc. They can quickly create quotation or pricing calcula-
tion from their mobile device which can be quickly synchronised with back-end ERP. This increases
their productivity a lot.
Mobile devices also make life simple for field staff like maintenance crew. A large electric utility
company having hundreds of staff maintaining different high tension lines across the city can instruct
their staff on their mobile device that which maintenance order need to be executed next, location of
the next assignment. Actual maintenance order is created in back-end ERP system which is sent to
technician’s mobile device. Once the order is executed, the staff can enter details like how much time
taken, any machine consumed, etc. against the order and close it in his mobile device. This automati-
cally trigger action in the back-end ERP system where the order is closed and costed with inputs like
labour rate, time taken and cost of spare consumed.
Mobile devices can be used effectively to provide extra high level of service for a company’s special
customers for whom service is a clear differentiator
Usage of Mobile Business While mobile commerce, i.e. doing actual buying and selling on mobile
device is still in its infancy, mobile devices are mostly used today for sales promotion, to help sales em-
ployees in easy ordering, price checking or availability checking and guiding service and maintenance staff.
Any business transaction you do in a bank today, almost immediately you get a message of the last transac-
tion (like money deposited, withdrawn, fixed deposit opened, etc.). In this case the banking ERP system
integrated with mobile device automatically generate these alerts on mobile to provide better security on all
your banking transactions. This mobile business integrated with back-end ERP solution has lots of business
potential for future. Today most common usage of wireless mobile devices (like handheld) are:
To check product availability/inventory look-up
Product ordering
Price check
Getting more information about product/product details
Guided selling and to up-sell and cross-sell offers, based on past purchases of a particular customer.
Such kind of sales promotion messages to individual customer’s mobile device have almost become
a part of our life these days
Ability to order products from other locations to fulfill customer request
Payment via a mobile phone (not very popular till date)
Most popular M-commerce transactions are purchases of things for the phone itself (for example, ring
tones and music)
Mobile commerce is somewhat similar to e-Commerce where instead of internet mobile phones, PDAs or
other wireless devices are used either to purchase an item/service directly or for accessing shopping infor-
mation. Similar to e-Commerce in case of mobile commerce as discussed earlier, the exact sales transaction
may not occur over the mobile device. However, the mobile device can help in a lot of ways to facilitate
the sales transaction.
Almost all leading CRM solutions of today provide functionalities for mobile sales and mobile service
where selected transactions of CRM solution can be run on a mobile device. Once the data is entered through
mobile device, the same can be synchronised back to back-end system and in the similar way, mobile de-
vice can pull data from back-end application when required. ERP solutions also have selected transactions
 ERP and Enterprise Applications—Emerging Trends 539

that can run on a mobile device. As any mobile device has a display space constraint, this need designing
separate user interface suitable for the particular device. This may call for designing special screens where
minimum amount of mandatory information only should be entered. For example, to create a sales order in
a normal ERP screen, there may be twenty fields where data need to be entered, but if the same ordering is
done through a mobile device, perhaps only the sales guy need to enter the bare minimum information (like
product code, customer code, product quantity and delivery date) while accepting the order and all other
values are defaulted from the back-end ERP system.

Enterprise Application Integration (EAI)

One of the biggest challenges for today’s organisations is numerous systems that is operational at any point
of time. There are separate systems for order management, sales, product development, R&D, production,
accounts, materials, etc. While ERP promised to replace all of them by a single application and database,
often that is far from the truth. Sometimes due to shortcoming in the ERP application itself, it can not ad-
dress few specialised business process requirements and that is why some nitch application catering to that
business requirement are required to continue. In some cases, users make strong protest against replacing
some application for reasons relating to user-friendliness, better functionality than ERP, etc. The net result
is that it is common to see more than hundred live applications in some company’s application landscape
and this is, especially true for large organisations.
Point-to-Point Connection Once a company has so many applications, its challenge is how these
applications talk to each other. The lack of communication between applications can lead to inefficiencies,
wherein identical data are stored in multiple locations causing islands of information silos and processes
can not be automated. Enterprise application integration is an integration framework composed of a collec-
tion of technologies and services that form a middleware to enable integration of systems and applications
across the enterprise. EAI need to link various applications that reside on different operating systems, use
different database solutions and different computer languages. Before the concept of EAI and structured
application integration came, every time there is a new system in the application landscape which needs to
communicate some data to another application, people used to build point-to-point connections and thus,
such connections used to grow across the organisation over the time. After several years, this type of appli-
cation landscape used to become a mess that is difficult to maintain. Theoretically, if n applications needed
to be connected point-to-point, it needs n × (n-1)/2 connections, i.e. for twenty applications to be integrated
point-to-point it needs 20 × (20-1)/2 i.e. 190 point-to-point connections. It is common to have more than
hundred applications today in the application landscape for large organisations and that means unmanage-
able number of such connections.
EAI Hub Model EAI application can replace such point-to-point connections through hub-and-spoke
model. In the hub-and-spoke model, the EAI system is at the centre (the hub), and interacts with the applica-
tions via the spokes. The hub connects to individual application through a set of adapters (also referred to
as connectors). Adapters/connectors are a set of programmes provided by EAI products out of the box that
know how to interact with an underlying business application. They can perform a two-way communication,
i.e. communicate between hub and the application and also notify the hub when there is any change/event
in the connected application (For example, a new master record created in the application, a transaction
completed, etc.). Figure 34.6 explains this comparison between point-to-point and hub model.
Enterprise Information Integration (EII) EAI can be used both for data and process integration.
While process or application integration is discussed earlier, EAI can also share data between multiple
540 Enterprise Resource Planning

Fig. 34.6 Point-to-Point Connection vs. EAI

systems to ensure that information in multiple systems is kept consistent. This is known as EII (enterprise
information integration). As different applications can keep data in multiple formats, to avoid every adapter
having to convert data to/from every other application formats, EAI systems usually stipulate an applica-
tion-independent (or common) data format. The EAI software usually provides a data transformation service
to convert data between application-specific and common formats.
Leading Vendors and EII Products The EII market is dominated by palyers from different origin.
There are pure play EII vendors like Tibco and Sterling commerce, ERP vendors like SAP and Oracle and
large IT vendors like Microsoft and Oracle who are present in this market. ERP vendors like SAP and Oracle
have an advantage if a large percentage of company’s application landscape is dominated by a particular
ERP. However, specialised EAI vendor like Tibco scores better, if a company has really complex landscape
in terms of number of ERP and non-ERP vendors on different platforms and legacy applications dominates
the landscape.
Leading vendors and products in this space are:
IBM (WebSphere Business Integration)
Microsoft (BizTalk Server)
SAP (Netweaver Process Integration - PI)
Oracle (Fusion Middleware)
Sterling Commerce
Tibco Software

ERP II–ERP with Power of Internet

In the first generation of ERP applications, these softwares were traditionally concentrating on bringing
process efficiency and automation typically for company’s back office functions like accounting, inventory
management, order management, etc. These applications’ boundaries were limited within the company and
to access these applications, a user physically needs to be within the four-wall of any of the company’s
premises (i.e. at its factory or sales office or distribution centre, etc.). However, these two assumptions (i.e.
ERPs are limited within the organisation’s boundary and ERPs need to be accessed from any of the com-
pany premises) were challenged over the time by the two greatest inventions of last century, i.e. Internet
and mobile commerce.
ERPs are Extending Outside the Organisation ERPs now can be accessed by the company’s
suppliers and customers: Today’s ERPs can be accessed both by company’s suppliers and customers and
this helps the organisation to collaborate with these two important stakeholders. For today’s organisation
collaboration is extremely important for several key processes like forecasting, inventory management,
 ERP and Enterprise Applications—Emerging Trends 541

product development, etc. as discussed in Chapter 25. Incraesingly, organisations have understood today that
old theory that “Strength of a chain is as strong as its weakest link”. Suppliers today can access company’s
ERP systems to get information on their next delivery schedule, to know the quality status of their last
shipments (i.e. whether it got accepted or rejected), to know their payment status, to collaborate on product
development process, etc. Customers as well can accesss company’s ERP system for providing inputs on
their next month’s requirement, provide inputs on customer service, etc.
Today’s organisation can be connected to all its suppliers who make parts for them and instead of storing
and maintaining a database that stores the parts’ lists and estimated inventory of all suppliers, the company
can simply does a direct query on the suppliers’ systems to locate the part. This action is done directly over
the internet, and in the process checks are made on availability of inventory. If the part is not available,
it simply returns this information back to the customer with additional information giving the lead-time it
takes to obtain the part. Thus, internet made today’s ERP systems much more powerful.
Applications like suppier relationship management and supplier portals, customer relationship manage-
ment and customer portals are extending ERPs today beyond the organisational boundaries and all these
technologies use internet as their backbone.
ERPs Now can be Accessed from Anywhere, Anytime Accessing ERP remaining within company
premises is not feasible for all types of ERP users today. Just think about sales guys who most of the time
remains in the field. It is not expected that they need to come back to office for updating their opportunity
list or order status in ERP system leaving their actual job of selling. Just think of about a utility or electricity
company, its maintenance staffs are mostly outside the office maintaining utility lines at homes or streets.
They are not expected to be in the office to run transactions in the ERP system. Today’s ERP systems can
reach out to these user groups through internet or mobile devices.
Multi-channel access for ERP systems is also increasingly becoming important for ERP systems today. Just
think about retail industry today. A customer can buy a product from an online store and take the delivery (or
return the product) from physical store of the same retailer. It’s important for ERP systems to keep track of
customer orders, customer information and inventory status across channels. An ERP for bank today needs
to give the customer the option for opening a fixed deposit account through multiple channels like visiting
the bank, through Internet, through ATM, etc. All these different channels send data into the back-end ERP
system. This is explained in Figure 34.7.
ERP Now can be Integrated with Best of Breed Vendors Seamlessly with one
Interface Over the years, ERP vendors have understood that it is almost impossible to address every
business need of all the industries with one ERP solution. There will be always nitch vendors who are the
best in doing certain business processes. What is important for ERP solutions is to seamelessly integrate
with such best-of-breed applications, keeping the user interface same. Technologies like EAI (enterprise
application integration), SOA (service-oriented architecture) and portal made it possible today. Portal can
bring transactions from ERP and different applications together in one place for the end user, i.e. he can
access ERP and different best-of-breed applications from single screen seamlessly.
Thus, the most important change from ERP to ERP II is a change in focus from one that is totally enter-
prise-centric and focused with internal resource optimisation and transactional processing to a new focus on
process integration and external collaboration. Collaborative commerce with suppliers and customers is the
heart of ERP II. ERP II also showed the strength of Internet which is no longer a tool just to send e-mail,
but something that can be put in serious business with the power of ERP. Applications like SRM, CRM
and PLM today depends much on Internet for most of its functionalities.
542 Enterprise Resource Planning

Fig. 34.7 Access to ERPs from Different Channels

Summary
High cost of ERP licence and infrastructure had forced companies to think new ERP deployment models
like: SaaS, Hosting and Cloud Computing.
In the SaaS model, users can pay on subscription basis without any upfront investment in the licence.
However, they do not have any option of changing the software code as per their requirement and need to
use the same software.
In cloud computing, users can pay for the hardware infrastructure on subscription basis and need not make
any upfront investment.
Hosted ERP gives the user advantage of modifying the software as per their need, but in this case customers
need to buy the licence. However, hosted licence cost is much lower then normal ERP licence.
SOA (service-oriented architecture) is a new model of building applications by using enterprise services that
is reusable and can quickly integrated across applications.
RFID technology helps in better track and trace, inventory management and warehouse management. Leading
ERPs today are making their material movement related modules RFID compliant.
Mobile commerce applications help ERPs to reach more efficiently to sales people and field sales staff who
can now run ERP transactions while on move. This need specialised user interface design for ERP applica-
tions for mobile device.
 ERP and Enterprise Applications—Emerging Trends 543

Enterprise application integartion software help in integrating diverse applications and data using technoilogy
like hub and spoke model.
ERP II had increased the strength of traditional ERP application using the power of Internet where ERP
can be extended beyond the enterprise to its suplliers and customers, ERPs can be accessed from anywhere,
anytime and it can be integrated with other applications seamlessly using technoilogy like EAI.

Exercise
I. Objective Type Questions
1. What is SaaS?
2. What are the types of applications for which SaaS is popular?
3. What are the two popular pricing models for ERP software as a service?
4. What is cloud computing?
5. What are the typical areas of cloud computing?
6. What is hosted ERP?
7. What is SOA?
8. What is enterprise service architecture?
9. What is RFID?
10. What are the functions of RFID tags and readers?
11. What is M-commerce?
12. What is EAI?
13. Who are the leading EAI vendors?
14. What is ERPII?

II. Descriptive Type Questions

1. What are the emerging models of deploying ERP software and enterprise applications? How do they benefit
the user?
2. Explain software as a service. What are its characteristics? What are the benefits of SaaS? What are the
drivers of SaaS?
3. How is SaaS becoming popular for ERP deployment? What are the major issues in putting an application
like ERP on SaaS? What are the special capabilities needed from a service provider to put an application
like ERP on SaaS?
4. Explain cloud computing. What are its advantages?
5. How is hosted ERP different from SaaS? For which type of customers hosted ERP is a good option?
6. Define SOA. What is a service? What are the properties of a service? What are the fundamental principles
of SOA? What are the benefits of SOA?
7. What is RFID? What are the advantages and disadvantages of RFID over bar code? What are the technol-
ogy components of RFID?
8. What are the benefits of RFID technology? How are ERP vendors adopting RFID?
9. What are the advantages of mobile technology? Explain some of the common usage of mobile com-
merce.
10. How EAI applications benefit business? How is EAI hub model better than point-to-point connection?
11. How ERPII technology make ERPs more powerful?
544 Enterprise Resource Planning

III. Fill in the Blanks

1. SaaS stands for ________ ____ ____ __________.
2. SaaS model of software deployment is known as “software ____ _______” _____________
_______________.
3. Cloud computing uses storage ______ _____ _________.
4. Hosted ERP has a __________ tenant architecture.
5. Application upgrade is done by ___________ in case of SaaS.
6. SOA stands for __________ __________ ___________.
7. Loose coupling is a fundamental principle of __________.
8. RFID stands for __________ __________ ___________.
9. Tracking of items is facilitated by _________ technology.
10. EAI stands for __________ __________ ___________.
11. Tibco software is a leading ________ vendor.

IV. State Whether the following Statements are True or False

1. SaaS uses a subscription model of “Pay as you use”.
2. SaaS is more popular for applications that varies according to the industry.
3. Platform as a service is a SaaS technology.
4. Licence is owned by the ERP vendor in case of a hosted ERP.
5. Reusability and modularity are principles of SOA.
6. Sterling commerce is an RFID technology vendor.
7. ERPs can be accessed from anywhere and can be extended outside the organisation – ERPII made it
possible.
 Section

ERP for Industries

 SECTION INTRODUCTION

ERPs FOR INDUSTRIES

ERPs started their journey as “One Solution that Fits Every Industry”.

WHERE INDUSTRIES ARE SAME

This is true for certain processes which do not differ much across industries. For example, the way recruitment process
happens in one company is not very different from the way it happens in another – the skill requirement for the new
vacancy is analysed, CVs of probable candidates are collected through advertising or through recruitment agency, these
are screened and few of them are shortlisted, interview happens and finally the candidate is selected. This process is
not very different the way it happens in an automotive company or an oil and gas company except few minor varia-
tions. There can be numerous such processes across organisation which happens exactly the same way. Some of these
are as follows:
Human resource management processes like recruitment, payroll processing, talent management, etc.
Corporate services like travel management
Maintenance management
Corporate governance

WHERE INDUSTRIES ARE DIFFERENT

However there are cases where the processes are not same across companies. These processes can fall into three dif-
ferent categories:
Country-specific processes: These are typically regulatory processes in the areas of customs, excise,
import and export, direct and indirect tax, value-added tax, payroll, safety standards, etc. where every
country has separate set of rules. This needs specific country versions for ERP solutions. Increasingly,
ERPs are coming up with country-specific versions to meet such requirements. For example, world’s
leading ERP vendor SAP has come up with a country-specific module for India. This is popularly
known as SAP CIN (SAP country India).
Common processes that can vary across industry: Every manufacturing company does produc-
tion, but this process can be entirely different the way an automobile company does manufacturing
of a new car to the way a steel maker makes steel and the way a food processing company produces
its finished goods. In the same way procurement process for a dairy company which procures milk
everyday from thousands of small vendors can be very different from a power plan which procures
coal through auction. As the process and process steps are entirely different across companies here,
one ERP does not fit everyone. The processes which have such wide variations across industries are:
Production management, sales and distribution management, procurement and materials management,
etc. ERPs need to come out with separate versions for each industry for such processes. For example,
all leading ERP vendors like SAP and Oracle have different versions of manufacturing process for
discrete industries, repetitive manufacturing industries, process industries, etc.
Industry exclusive processes: These are processes which are needed by one industry and not needed
by others. For example, an oil and gas company need capabilities around oil exploration for finding
new oil reserves but that is not something important for a consumer goods company. In the similar way,
 Section Introduction 547

a product promotion is an important feature for a consumer goods company to boost sales. However,
that may not make any sense for a petroleum company where prices in most countries is dictated by the
respective governments. ERPs need to come up with specific industry solutions for every industry to
meet these requirements. For example, SAP has industry solutions for twenty seven such industries.

EMERGENCE OF INDUSTRY-SPECIFIC ERPs

As some of the industries has industry exclusive processes, in the last three decades several small vendors had come up
with ERP solutions targeted for one particular industry and they created nitch market for them. Some of the examples
here are:
Retek for retail industry (now taken over by Oracle)
Aspentech for oil and gas
Mincom for mining
These ERPs are typically very good fit for the targeted industry as they were built on years of research of that industry.
However, their major problem was dependence on industry and that in most cases made them a very small vendor, not
financially very stable and vulnerable for take over by large ERP vendors. Another risk is if the particular industry in
which they are operating is not doing well in a particular year (for example, in year 2008–2009 there was a crisis in
financial and real estate segment world over), this may become a death sentence for them.

EMERGENCE OF INDUSTRY-SPECIFIC SOLUTIONS FROM LARGE

ERP VENDORS
Large ERP vendors like SAP and Oracle quickly spotted this opportunity and started building industry-specific func-
tionalities in their application. As shown in Figure S-5.1, SAP today has specific industry solutions for most of the
industries. In the similar line Oracle also has industry-specific solutions and some of it was built by taking over nitch
industry-specific ERPs. For example, Oracle had bought over Retek, a retail industry-specific ERP a few years back to
build its retail-specific functionalities. Figure S-5.2 shows how today’s ERPs segregate their market for every industry
and targeting to build solutions for each of them.

ERPs FOR INDUSTRIES—WHERE THE MARKET IS MOVING

There are two clear emerging trends

ERPs are Getting into Micro Verticals

Increasingly, large ERP solution vendors are entering into more specialised nitch segments within the industry. For
example, F.M.C.G. can have several sub-verticals like:
Dairy
Beverage
Tobacco
Food
Apparel
Personal care and home care products.
Electronics industry can have several segments like:
Semiconductor manufacturers
Consumer electronics companies
Network equipment providers
548 Enterprise Resource Planning

Fig. S-5.1 SAP Industry Solutions

Fig. S-5.2 Today ERPs have Industry Solutions for Every Segments

Office equipment makers

Industrial automation companies
It is not enough just to have an ERP solution today for consumer goods or electronics industry. ERP vendors are
increasingly getting into each of these sub-verticals to build specific solution that cater to their needs.

Industry Boundaries are Blurring and Industry-specific ERPs are Finding it

Difficult to Survive
This is something happening across industries. For example, manufacturers are getting into retailing (Arvind Mills
leading Indian apparel manufacturer opened Raymond retail stores across the country), metal and power companies
started owning mines to ensure their raw material supply, electronics manufacturers have their own retail stores today
(for example, Sony has Sony stores in all major cities) and auto manufacturers are getting into auto financing. This
 Section Introduction 549

means that lines between manufacturing, service, retailing and financing is blurring. So, if a manufacturing company
buys an industry-specific ERP solution from a nitch vendor today, tomorrow while expanding to its service business,
it needs to look for another ERP from another vendor and start his ERP journey all over again. Compared to that it is
much easier to go for an ERP vendor which offers solution for many industries and keep on implementing relevant
industry-specific modules as the company ventures to new industry segments. This also made survival for industry-
specific ERPs difficult in these days.
 35
ERPs for Different
Manufacturing Industries Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
ERPs for Oil and Gas
ERPs for Auto
ERPs for Pharma
ERPs for Consumer goods
ERPs for Mining

INTRODUCTION
In the earlier sections, we discussed different features and functions of ERP solutions. There are some ERP
capabilities which are needed across industries. Some of the examples are as follows:
Financial accounting
Management accounting
Corporate governance
Human resource management processes like recruitment, payroll processing, talent management etc.
Corporate services like travel management
Quality management
Processes of global trade like import procedure, documentation, customs etc.
Managing some of the logistics functions like warehouse and transport management.
However,there are specific capabilities which are needed by a particular industry and not by others. For ex-
ample, an oil and gas company needs capabilities around oil exploration for finding new oil reserves but this
is something not important for a consumer goods company. In the similar way, the promotion of a product is
an important feature for a consumer goods company to boost sales; however, this may not make any sense
for a petroleum company where prices in countries like India are mostly dictated by the government.
552 Enterprise Resource Planning

In this Chapter, some of these unique requirements from few manufacturing industries are discussed and
how ERPs address that is explained. There are a lot of industry-specific ERPs (like Mincom for Mining,
Aspentech for Oil and Gas) i.e. ERPs that cater the need of a particular industry only. Some of these are
also discussed in this chapter.
The length of the book does not allow discussing ERPs for all types of manufacturing industries and in
this chapter the focus is on five different industries. The rationale behind picking up these are that they are
large industries and can have several sub-industries and that they are very different in nature. In the next
chapter, few service industries are picked up for discussion.

ERPs FOR PETROLEUM, OIL AND GAS COMPANIES

This industry can be divided into three major segments as shown in Figure 35.1.
Upstream: Upstream industry includes processes related to exploration, development, and production
of crude petroleum. This is also referred as E&P (exploration and production) sector.
Midstream: Midstream industry processes, stores, markets and transports commodities including
crude oil and natural gas. Transportation of oil and gas is generally through pipeline and as these are
explosive materials, their transport and storage need to be under controlled condition.
Downstream: Downstream industry includes oil refineries, petrochemical plants, petroleum products
distributors, retail outlets and natural gas distribution companies. Today’s oil service stations are be-
coming full-fledged retail outlets with convenience store.

Fig. 35.1 Oil and Gas Industry Value Chain

Figure 35.2 shows major supply chain activities at different nodes of this industry value chain. This industry
has lot of unique requirements as shown in Table 35.1
 ERPs for Different Manufacturing Industries 553

Fig. 35.2 Oil and Gas Industry Integrated Supply Chain

Table 35.1 Industry requirements from ERP Solutions (Petroleum, Oil and Gas)

Industry Requirements Expectation from ERP Solutions

Exploration Exploration means finding and developing a new oil/gas reserve. ERP solutions need
to support the exploration cycle and related activities like managing surveys, drilling,
exploration data analysis etc.
Developing petroleum Processes related to establishing size of the field, identifying most efficient production
fields method etc.
Managing refinery This involve processes related to procuring crude oil, managing inventory, planning and
operations scheduling production, blending different semi-finished products to produce final refined
output and finally delivering products to the distribution network.
Lubes manufacturing This involves processes related to planning and forecasting demand of lubes products,
operations sourcing base oils and additives, blending the product, managing packaging plant opera-
tions for packing lubes and finally delivering products to the distribution network.
Oil and gas commodity Working with the most heavily traded commodities in the world, one can capture deals,
trading manage contracts, monitor positions and integrate trading into the bulk supply chain.
Because trade volumes are very large, companies can use bulk transport methods, such
as marine vessels and pipelines, to achieve delivery.
Managing bulk transport of Transportation of oil and gas is generally done through pipelines or tankers and as these
inflammable materials and are explosive materials, their transport and storage need to be under controlled condition.
hydrocarbon products ERPs for this industry need to have capability for monitoring such hazardous material
transports. During transport evaporation is common for such products, so actual quanti-
ties delivered need to be compared against scheduled quantities.
(Contd)
554 Enterprise Resource Planning

(Contd)
Managing terminals This involves processes like monitoring stock levels in terminal tanks, taking orders and
management managing tank stocks and shipments.
Managing service This involves processes like point-of-sale (POS) integration for fuel sales quantities,
station operations/fuel reconciling meter readings with physical dip readings, analysing and adjusting of fuel
management pricing etc.
Convenience retailing Today’s oil pumps have full-scale retail operations with convenience stores, food outlets
etc. This involves supporting all retail-specific functionalities for ERP like managing
pricing and promotions, merchandising, accounting, POS integration, loyalty manage-
ment etc.

Leading ERP Solutions for Petroleum, Oil and Gas Industry

While both SAP and Oracle have specific industry solutions (IS) for this industry, SAP IS is the clear market
leader. Most of the Fortune 500 oil and gas companies had selected SAP IS solution for their enterprise.
Figure 35.3 shows SAP’s solution map for this industry.
Another leading enterprise solution for this industry is AspenTech. AspenTech started as an ERP for petro-
leum industry and is used widely by lot of oil and gas companies. It has solutions span across engineering,
manufacturing and supply chain as shown in Figure 35.4. AspenONE® V7 is its flagship product and this
has modules in following process areas:
Process Engineering: Aspen Basic Engineering, Aspen Economic Evaluation, Aspen Exchanger Design
& Rating
Supply and Distribution: Aspen Retail, Aspen Inventory Management and Operations Scheduling,
Aspen Petroleum Supply Chain Planner
Advanced Process Control: Aspen DMCplus
Planning and Scheduling: Aspen Collaborative Demand Manager, Aspen Petroleum Scheduler, Aspen
PIMS, Aspen Plant Scheduler, Aspen Supply Chain Planner
Production Management and Execution: Aspen InfoPlus

ERPs FOR AUTO INDUSTRY

Auto industry is one of the largest industries globally. This industry has lot of unique requirements as shown
in Table 35.2

Table 35.2 Industry Requirements from ERP Solutions (Auto)

Industry Requirements Expectation from ERP solution

Kanban Kanban process for controlling production and material flow had its origin in automo-
tive industry and is widely popular among auto manufacturers till date. In this process
replenishment is triggered only when production actually requires the material. Kanban
system can drastically reduce inventory in the supply chain. An ERP for automotive
industry need to have advanced capability in this area.
(Contd)
SAP Oil and Gas Solution Map
Fig. 35.3
ERPs for Different Manufacturing Industries 555
556 Enterprise Resource Planning

(Contd)

Planning/scheduling for The same auto assembly line can produce multiple car models during the same day
multiple models at the same or same production shift. Auto companies need the ERP solution that can suggest
time in assembly line optimised schedule with minimum changeover and minimum loss of production.
Warranty management Warranty claim management is a complex process as full finished products (e.g. car)
can have separate warranty from its parts (e.g. tyre, battery). Warranty claims from
customers can be entered at dealer’s end, checked against contractual data, accepted or
rejected and if the claim is accepted then it triggers subsequent processes i.e. payment
or service operations. Auto manufacturers want to automate this process to the extent
possible so that it is possible to deal with a large number of claims comfortably and,
as far as possible, automatically.
Just-in-sequence deliveries It is a common practice for auto suppliers to deliver material directly to assembly line
by suppliers directly to based on the assembly line production sequence. This is known as just-in-sequence
assembly line deliveries of components and may need capabilities like receiving and forwarding
just-in-sequence messages/calls from external systems i.e. supplier’s systems to au-
tomotive manufacturers.
(Contd)

Fig. 35.4 Aspen Tech Solutions

 ERPs for Different Manufacturing Industries 557

(Contd)

Managing vehicle information Managing vehicle information is becoming a huge challenge for auto manufacturers
and vehicle lifecycle as every year few million vehicles are getting added and today every car manufacturer
works with hundreds of active models and vehicle configurations. It’s important to
keep and track these information (i.e. which customer bought which model, on which
date, which parts are on warranty etc.) to not only provide service throughout the
vehicle’s life cycle but also to support any eventualities like product recall (which is
becoming common these days for faulty parts).
Managing dealer business Auto value chain is not only made up of OEMs (Original Equipment Manufacturers i.e.
car makers) but also of dealers who sell and service vehicles. Dealers need capabilities
to manage every function of a dealer’s operation, including customer management,
vehicle sales and administration, vehicles service and parts management and integra-
tion with systems of OEMs, and thus make the process easier for customers to buy
vehicles, acquire needed services, parts or accessories. ERP systems need to support
these processes for dealers.
Car leasing ERPs for auto industry need to support vehicle finance and leasing capabilities.

Leading ERP Solutions for Auto Industry

Both SAP and Oracle have specific industry solutions (IS) for this industry. SAP IS Auto solution is used
by lot of global car makers like General Motors, Mitsubishi etc.

ERPs FOR PHARMA

Pharma industry is one of the largest industries globally. This industry has lot of unique requirements as
shown in Table 35.3.

Table 35.3 Industry Requirements from ERP Solutions (Pharma)

Industry Requirements Expectation from ERP Solutions

Patent management Patent of new drugs is key to pharma company’s survival. Managing patent is a
complex process often associated with the R&D function that begins as an idea and
ultimately becomes a registered patent. Managing patents is an important need of
pharma companies from ERP solutions.
Managing intellectual Proactive management of Intellectual Property (IP) is important for pharma companies
property and this may include processes like IP and rights management, rights/license sales
and royalty statement.
Clinical trial management New product development is critical for pharma companies and clinical trial is an
important element of the product development process where the product is tried and
tested in a controlled environment and results are recorded. It involves study design,
initiation, training for investigators, auditing sites and monitoring the study process.
Managing planning, scheduling and tracking of clinical activities involves things like
managing clinical trial projects, managing costs and internal and external resources
for such trial etc. Often this process is outsourced and need collaboration between
sponsor and clinical research organisations (CROs) to exchange trial documents etc.
Besides pure trial management, data management also needs to be considered as patient
(Contd)
558 Enterprise Resource Planning

(Contd)
data is collected electronically and will undergo vigorous quality checks, before it is
statistically analysed and used as a basis of the regulatory submission. This is a basic
requirement for any pharma company looking for an ERP solution.
Laboratory information LIMS systems automate work processes and administrative functions of a laboratory.
management systems (LIMS) LIMS manages the complete testing process including sample log-in, testing, creat-
ing of final reports, sample management, inspection plan, test equipment calibration
etc. While LIMS helps in lab management and testing process, it also helps in work
scheduling in R&D and quick product release. LIMS is a basic requirement of phar-
maceutical companies as most of them have large laboratory and R&D function. ERP
systems offering solutions for pharma companies need to have LIMS capability.
Secure tracing and tracking/ Entry of spurious drug in the supply chain is one of the biggest problems for pharma
e-pedigree companies these days—it is dangerous both for patient’s health and company’s good-
will. The goal of drug tracking and tracing is to prevent unsafe product from entering
the supply chain by establishing a secure electronic pedigree so that every unit of
medication is authenticated. The use of Electronic Product Code (EPC) technology
allows individual product units to be tracked, traced and monitored using radio fre-
quency identification (RFID). ERPs operating in this space need to support this.
Product/patient safety This is of paramount importance for every pharma company and several regulatory
agencies in pharma/life sciences industry (like FDA in US) are putting strict guidelines
for assuring safety of medical products at all stages in the product lifecycle—manu-
facturing, distribution and consumption or usage. In most countries a pharma com-
pany by rule needs to track all customer complaints, needs to have visibility on the
progress of investigations for such complaints and ensures quick issue resolution.
ERP systems for this industry need to support these requirements, anticipate potential
product safety issues, need to provide early warning signals so that corrective actions
can be taken on time etc.
Regulatory compliance Every country has their own regulatory agencies and specific reporting requirements
submission to ensure product safety and quality of drugs. ERP systems for this industry need to
support such reporting requirements out of the box that matches the structure and
content of electronic reporting submission requirements of different countries.
Secrecy of formulation While it is common for companies in other industries to define their bill of material
of products in ERP systems (i.e. to define the finish product’s composition of raw
materials), lot of pharma companies want to keep this information secret i.e. do not
define the active ingredients of the formulations for different drugs. ERPs catering to
this industry had made special provisions to meet this requirement.

Leading ERP Solutions for Pharma

Both SAP and Oracle have specific industry solutions (IS) for this industry in the form of SAP IS Life
Science Solution and Oracle Life Science/Pharma solution. Again, SAP is the undisputed market leader in
this industry. Table 35.4 is an extract from a pharma industry report which shows SAP’s dominance in this
industry.
 ERPs for Different Manufacturing Industries 559

Table 35.4 Top 10 Pharmaceutical Companies

S.No Company 2007 pharma sales in billions USD ERP system used
1. Pfizer 23.5 SAP
2. GlaxoSmithKline 20.1 SAP
3. Merck 17.6 SAP
4. Johnson & Johnson 16.3 SAP
5. AstraZeneca 15.5 SAP SCM/Oracle HR
6. Amgen 14.3 SAP
7. Novartis/Sandoz 13.9 SAP
8. Hoffman-La Roche 12.3 SAP
9. Sanofi-Aventis 10.9 SAP
10. Lilly 10.3 SAP
Source: Healthcare–Pharmaceuticals Industry Report (S&P NetAdvantage, 24 Apr 2008).

While SAP dominates the overall ERP space in this industry, there are lot of successful niche softwares
which meet specific pharma industry process requirements like clinical trial, track and trace etc. OpenClinica,
Clinaxys etc. are leading softwares which support just the clinical trial process.

ERPs FOR CONSUMER PRODUCT GOODS (CPG)

Consumer goods industry is not one industry and has several segments under this like:
Food and Beverage
Apparel/Textile
Footwear
Non-food FMCG products
Consumer electronics
Again each of these segments can be divided into several sub-segments, each having their own specific
requirements from an ERP solution. For example, ‘Food and Beverage’ segment can have several sub-seg-
ments like
Fresh foods
Beverage
Dairy
Packaged foods
Table 35.5 gives a list of requirements from ERP solutions for this industry.

Table 35.5 Industry Requirements from ERP Solutions (Consumer Product Goods–CPG)

Industry Requirements Expectation from ERP Solutions

Strong distribution planning Distribution strength is a make or break for CPG companies and distribution in this
capability industry can follow a multi-tier network composed of wholesalers, distributors, retailers
etc. CPG companies look for sophisticated distribution capabilities in ERP solutions in
terms of DRP (Distribution Requirement Planning), planning safety stock at different
distribution nodes, distribution optimisation etc.
(Contd)
560 Enterprise Resource Planning

(Contd)
Promotion planning/trade CPG companies depend heavily on promotions for sales uplift. Sometime these
promotions promotions are partly funded by manufacturers (trade promotion) and partly by
retailers. Every CPG company looks for strong promotion planning capability in the
ERP solution so that their promotion budget is most optimally used and its ROI can
be tracked.
Brand management CPG company’s sales is dependent on powerful brands. Companies in this sector
build brands and continuously invest in this and look for an ERP solution which can
support this process.
Managing large number of Unlike petroleum or auto companies, any CPG company today handles a huge number
SKUs of SKUs. SKUs are added regularly, and promotion SKUs are launched for a brief
period. Capability of handling large number of SKUs is a prerequisite for ERPs for
this industry.
Manufacturing outsourcing/ Most of the CPG manufacturers outsource their core manufacturing activities and
contract manufacturing concentrate more on distribution and brand building. This need strong collaboration
between CPG companies and their contract manufacturers—this is the reason why
CPG companies look for stronger collaboration with its suppliers.
Collaboration with retailers CPG companies need strong collaboration with front end of their supply chain i.e.
retailers. In the past decade ERP vendors had come up with capabilities like VMI
(Vendor Managed Inventory) or CPFR (Collaborative Planning Forecasting and Re-
plenishment) to meet these needs.
Route management Managing routes of delivery is important for CPG companies as a truck from a ware-
house can deliver goods to multiple retailers on a particular day—this truck needs to
follow the most optimum route so that all deliveries are completed within shortest
time and covering minimum distance. Route optimisation is a requirement of CPG
companies from ERP solutions.
Direct store delivery (DSD) Several CPG companies need to deliver products directly to the store and not following
traditional distribution channel of warehouses, distributors etc. This is important for
certain category of items like fresh food, dairy items, beverages, ice creams etc. due
to short shelf life of such items. DSD is a need from ERP solutions.
Food safety Food safety is becoming paramount importance for food companies and they need
to meet stringent compliance standards of authorities of different countries. ERPs for
this industry need to support such compliance standards.
Managing cold chain Some food products (like vegetables, dairy, beverages etc.) need to be necessarily
(mainly for fresh foods) transported and stored under controlled condition. ERPs and related technologies like
RFID need to support the cold chain management.
Managing empties and returns For beverage companies return of empty cans and crates is a regular business process
(mainly for beverages) which needs to be refilled and reused. Supporting the reverse logistics/return process
for such items and accounting for them is a requirement from the ERP solution for
beverage companies.
Markdowns (mainly for Regular markdowns is a common feature for most of the apparel companies to clear
apparel industry) stock. ERPs for such industry need to have markdown capability in their pricing
engine.
Managing fashion, style, Apparel companies need to come up with new fashion/style/design every sea-
design (mainly for apparel son. This need strong design capabilities and this is an expectation from the ERP
industry) solution.
 ERPs for Different Manufacturing Industries 561

Leading ERP Solutions for CPG

Both SAP and Oracle have specific industry solutions (IS) for this industry. Increasingly, these vendors are
targeting more micro verticals in this industry like solution for dairy, solution for fresh foods, solution for
beverage, solution for textile etc. SAP has two specific IS for two sub-verticals of CPG industry:
SAP Apparel Footwear Solution (AFS)
SAP IS Beverage Solution
Beyond these leading ERPs there are niche solutions for specific needs. Vendors like Applied Data Com-
munications (ADC), Invatron Systems, Park City Group etc. have focused solutions for fresh item manage-
ment. Invensys has a solution for dairy industry. As more micro verticals are emerging within CPG industry,
small players prefer to focus on one of them and build deep industry capability to differentiate themselves
from others and survive.

ERPs FOR MINING INDUSTRY

Mining is considered one of the basic industries. There can be several segments in this industry depending
on type of mine (like underground mine, surface mine, deep sea mine etc.) or type of products produced
(like coal mine, iron ore mine, copper mine etc.). This industry has lot of unique requirements as shown
in Table 35.6.

Table 35.6 Industry Requirements from ERP Solutions (Mining)

Industry Requirements Expectation from ERP solutions

Safety Employee’s safety is a primary concern for miners today especially for underground
miners. ERP vendors are coming with specific EHS (Employee Health and Safety)
solutions to cater to this need.
Handling hazardous materials Explosives are needed to support blasting operations in mines. These items need to
(explosives) be handled, stored and transported in a safe manner—again a regular need of mining
companies from ERP vendors.
Managing logistics at remote Mines are generally located at remote locations. Managing logistics at such remote
locations locations is a challenge. ERP vendors had come up with specialised modules (for
example, SAP IS Mine has a module on Remote Logistics Management—RLM) to
cater to this need.
Transport optimisation Transport cost is the major component of cost for most of the mining companies.
For items like coal or iron ore, it can be 50% of the product cost and in some cases
more than the product cost. Mining companies look for strong transport optimisation
capabilities from ERP solutions so that the cost can be reduced.
Washing/beneficiation These processes increase mineral percentage in the finished products i.e. coal or
iron ore washing is used to increase ore percentage in raw mineral. ERPs for these
industries need to support these processes.
Blending Ores of different qualities are mixed to get desired properties in the finished product
and the process is known as blending; for example, coal with 10% ash can be mixed
with coal of 6% ash to get a blended coal with 8% ash. ERPs support such blending
process.
(Contd)
562 Enterprise Resource Planning

(Contd)

Commodity pricing Mining products are commodity items where prices fluctuate widely. This need spe-
cialised strategy like hedging or forward buying for companies to manage risk, and
this is a requirement of mining companies.
Commodity auctions Auction is a preferred method of selling commodities. Large mining companies (for
example, Coal India in India) use auctions extensively. ERPs for this industry need
to support such auction processes.
Corporate social While CSR is a requirement for other industries as well, it is more important for min-
responsibility (CSR) ing companies as mines are located at remote places; doing all-round development
in mining area is a responsibility of the miner as well. As mining may need massive
deforestation in the beginning while setting up, forestation, employment of local people
and proper filling at the end of mine’s lifecycle are important activities for miners.
Several miners look at ERP’s CSR capability to meet such requirements.

Leading ERP Solutions for Mining Industry

While leading ERPs like SAP have specific industry solutions (IS) for this industry in the form of IS mining,
there are a few mining industry specific ERP vendors. Gemcom, Mincom and Datamine are three such lead-
ing vendors in this space. Globally, large mining companies like BHP (Australia based), Rio Tinto (Brazil
based), Anglo American etc. extensively used the ERP solution for running their mining operations.
An extract from an article which describes the evolution of mining ERP and mining software market in
India is given as follows:

The evolution of computer software related to the mining industries started towards the late 70's
across the world with the need clearly apparent for the operative gold mines. The sustenance
of the gold mines depended on accurate prediction of the nature of the deposit along with the
grade estimation. This was crucial to avoid any wasteful mining leading to barren faces. The con-
cept of using computers for exploration, geological modelling and mine planning started in India
towards the later half of the 80s. Mining companies started realising the need for such software
for a more accurate and faster prediction of the deposit. These companies also realised that with
such software, it was possible to estimate reserves as well as grades with variable cutoffs much
faster and accurately as compared to manual methods. Thus the race to capture the Indian mining
market had started with international brands like SURPAC, DATAMINE making their presence felt
by appointing distributors for India.
Source: “Evolution of Mining Software market in India”, an article by Sandeep Ray, Country
Manager, Datamine International Ltd.

Summary
Each Industry has few unique requirements from ERP solutions. For example:
ERPs for oil and gas need capabilities around oil exploration, terminal management, managing bulk supply
chain, convenience retailing, managing service stations etc.
 ERPs for Different Manufacturing Industries 563

ERPs for auto need capabilities around Kanban, managing dealer’s business, just-in-sequence delivery by
suppliers, warranty management, managing vehicle data etc.
ERPs for pharma have requirements around product/patient safety, patent management, intellectual property
management, clinical trial, e-pedigree etc.
ERPs for CPG need capabilities around distribution management, promotion planning, brand management,
retailer collaboration, route management etc.
ERPs for food need to have capabilities around food safety, cold chain management whereas ERPs for bever-
age need capabilities to manage rentals and empties.
Finally, ERPs for mining need to have capabilities around employee’s safety, hazardous materials manage-
ment, remote logistics management, blending, auctions and commodity pricing.
 36
ERPs for Different
Service Industries Chapter

Learning Objectives
In this chapter we will discuss the following concepts:
ERPs for Retail
ERPs for Healthcare
ERPs for Higher Education
ERPs for Telecom
ERPs for Banking
ERPs for Insurance
ERPs for Utility

INTRODUCTION
ERPs first evolved for traditional manufacturing industries that use MRP or MRP II philosophies. However,
over time most of the large ERPs built functionalities to meet the requirements of service industries which
are very different from that of manufacturing. In this chapter, we discuss seven such service industries, their
unique requirements and how ERP solutions address those.

ERPs FOR RETAIL

Retail ERPs are different from traditional ERP systems developed for manufacturers based on MRP concepts.
Retail ERP requires specific functionalities for retail industry and this include things like:
Category management
Merchandise budgeting and planning
Assortment management
Space management
Advanced promotion planning functionality and planning markdowns
Store clustering
Specialised retail replenishment functionalities like continuous replenishment, cross-docking etc.
 ERPs for Different Service Industries 565

Point of sales solutions

Cross channel order fulfillment
Store operations
Traditional requirements of retail ERP solutions are met by some specialised retail vendors like Retailix,
Retek, JDA etc. and a list of best-of-breed vendors for
POS solutions (NCR, IBM, Triversity etc.)
Price and promotion solutions (Khimetric, SAS, i2, Retail Pro etc.)
Assortment and Space management (SAS, Galleria etc.)
Of late leading ERP solution providers SAP and Oracle had acquired lot of these best of breed vendors.
These vendors helped two strongest players of ERP market SAP and Oracle to have retail specific function-
alities in their portfolio.
Today a number of large Indian retailers like Shopper’s stop, Pantaloon, Madura Garments, Arvind
Mills etc. are going for ERP implementation and the choice of a particular ERP solution differed based
on a particular retailer’s business needs. For example, while Shopper’s stop had chosen JDA as their ERP
solution, Pantaloon had gone for SAP Retail solutions and Arvind Mills had chosen Oracle Retek as their
ERP solution provider.

Pantaloon had Gone for Retail Solution from SAP

More than eight years after it forayed into the retail business, Pantaloon Retail decided to implement SAP to
keep itself competitive in the rapidly growing Indian retail market. Pantaloon was regularly opening stores
in the metros and there was an urgent need for a reliable enterprise-wide application to help run its business
effectively—the basic need was to have a robust transaction management system and an enterprise-wide
platform to run the operations. The implementation was done by the SAP team with the help of Novasoft
Singapore and the implementation had taken around six months. The project was flagged off on 15th June
2005 and took about six months to finish. It went live at the head office on 1st January 2006. The stores went
live on SAP from 1st January 2006 to 30th June 2006. This application is currently being used by around
1,200 employees across the organisation. For maintaining this implementation and its related applications,
Pantaloon has an in-house team. They are also in the process of setting up an SAP Competency Centre. The
system runs on an HP Superdome server on HP UNIX 11i and the database is from Oracle.
Pantaloon had implemented a variety of processes of SAP solution including product development, which
includes ideation, trend analysis, and collaboration with partners in the supply chain; sourcing and procure-
ment, which involves working with manufacturers to fulfil orders according to strategic merchandising
plans and optimise cost, quality, and speed, buying plans, and market demand patterns change; managing
the supply chain, which involves handling the logistics of moving finished goods from the source into stores
and overseeing global trade and procurement requirements; selling goods across a variety of channels to
customers, which requires marketing and brand management; managing mark-downs and capturing customer
reactions, analysing data, and using it to optimise the next phase of the design process.
The project was divided into three phases. The first phase involved blueprinting existing processes and
mapping them to the desired state. In this phase, the entire project team worked on current processes within
the structure of the organisation, analysed and drafted them. This blueprint was later used in the formation of
new states of the solution. In the second phase, the SAP platform was developed with the help of Novasoft’s
template which was predefined by SAP after evaluation of Pantaloon’s needs and expertise in retail solu-
tions. The last phase in this project was for stores to switch over to the new system and for current data to
be ported. Before the SAP implementation, all the data was unorganised. This data had to be migrated to
the new SAP application.
566 Enterprise Resource Planning

Pantaloon uses MAP (Merchandise Assortment Planning), Auto-Replenishment and Purchase Orders quite
extensively and hope to use these systems to optimise inventory and cut it by about two to four weeks.

Arvind Mills had Gone for Oracle Retek Retail ERP Solution
Arvind Mills’ retail venture Megamart has selected Oracle Retail to provide the software support for their
growing retail business. Oracle would support Arvind by giving a platform to manage its retail processes
from supply chain to stores. The implementation of the solution, which comprises five modules—merchan-
dise management module, pricing module, inventory module, in-store module and planning module—will
be carried out in three phases spanning 24 months. Arvind is expecting to increase its inventory turns and
improve its forecast accuracy with this implementation.

Components of a Retail ERP System

Today’s retail ERP systems are quiet complex with several modules and sub-modules to address different
functionality requirements of a retailer. The main components of a retail ERP solution are:
Master data
Merchandise planning, procurement and replenishment
Supply chain execution
Managing pricing and promotions
Point-of-sale integration
Reports/KPIs/exception alerts
Store operations
Retail Planning
Specialised segment requirements
A. Master Data This is one of the fundamental building blocks for any retail ERP system. A typical
retail ERP will need the following masters:
Article Article is the lowest saleable item for a retailer. A retail ERP system need various details about
an article like:
Unit of measure: An article may have a sales unit, a separate ordering unit and a third unit, delivery
unit. For example, soft drinks may be ordered in pallets for better discount (ordering unit), delivery
to a store or distribution centre can happen in crates and sales in the store happens in bottles. There
need to be conversions defined for different unit of measures.
Article type: A retailer can classify the article in various ways like food and non-food. Non-food can be
further classified into apparel and white goods etc. Depending on article type several controls can be
exercised by the retailer. For example if the article type is perishable fresh fruits, the retailer may have
a daily procurement policy and adopt a safety stock policy of having no safety stock inventory.
Purchasing information about the article: This may be things like vendor, discounts, purchasing condi-
tions etc.
Basic information: This can be things like Article Number, shelf life, item groupings etc. Item’s size,
weight etc. are also part of it.
Planning information: This can be things like parameters for forecasting, requirement planning etc.
Sales data: Information like pricing conditions, minimum margin, planned mark-up can be part of
this.
Different article variants in color and size
 ERPs for Different Service Industries 567

Gift set or pre-packs: These are made of several different articles, the components and quantities of
which need to be entered in bill of material of gift set/pre-pack. These can be made up of different
articles like a Johnson’s kids gift set may be made up of baby soap, a baby shampoo, baby powder
and baby oil. This can also be made up of different variants of the same article i.e. a pre pack of white
shirts is made up of 3 XL, 4 L and 3 XXL shirts.
Additional: This is an article that is assigned to a sales article to create an effective presentation of
sales (sew in label, price label, security tag, packaging, hanger etc.).
Article master also need to flag new articles or articles to be discontinued.
Customer Master A retailer needs to maintain varieties of information like address, bank details, contact
information, insurance data, orders, shipping, invoicing information etc. For a retail store the customer is an
individual shopper and depending on the type of items the retailer sells—the customer master is maintained.
For a grocery retailer or a value retailer for apparels, customer’s information is limited to the shoppers who
has a loyalty card and do shopping using that. However for high-value purchases (like jewellery, durables,
furniture or auto), it is common to have details of every customer and not only of those who hold a loyalty
card.
Vendor Master A retailer needs to maintain varieties of information for its suppliers like address, bank
details, contact information, accounting information, payment terms, minimum purchase order value, lead
time, incoterms etc.
Site Master A retailers’ site can be typically a distribution centre or a store. A lot of master data need to
be maintained for a site like which departments are in which floor of the store depending on merchandise
category (kid’s department in ground floor), unloading points of the distribution centre/store where the
transport carrier unload material and from there it is taken to different departments, receiving points and
storage locations of the site, corresponding supplying sites i.e. a store may always get all non-perishable
items from a particular distribution centre and perishable supply from few selected suppliers.
Replenishment Master Data This includes things like target stock, reorder point, safety stock, minimum
and maximum target stock, forecast parameters etc.
Merchandise Category and Hierarchy The merchandise category and hierarchy need to be clearly
defined i.e. group, sub-group, product line, article, individual variant etc.
Layout Planning Master A retailer needs to have a master layout plan based on his store shelf space,
department arrangements of merchandise, assortment plan, and size and shape of the merchandise.
B. Merchandise Planning, Procurement and Replenishment
Retail ERPs support different types of merchandise procurements like procurement of regular mer-
chandise, procurement of perishables, investment procurement etc. Procurement planning can vary
depending on types of merchandise like for some items forecasting is required, for some reorder-based
planning is used and till for some others time-phased planning is done. Investment buying needs proper
ROI calculation between the cost of carrying extra inventory and the extra price that need to be paid
if there is a price increase. ERP software can support this type of ROI calculation and recommend
optimum purchase quantity. Perishable planning also need to consider daily assortment plan of an
individual store based on space availability.
568 Enterprise Resource Planning

Allocation table helps in distributing purchased quantity to an individual store. The allocation process
of ERP needs to support different business rules like quota and other complex business rules.
Replenishment planning is also an important part of ERP solution and most of the retail ERPs support
vendor-managed inventory or continuous replenishments which are commonly used for replenishing
stock between the store and distribution centre or the store and supplier.
For ordering to vendors retail ERP needs to support normal purchase order process, managing differ-
ent types of contracts like quantity contract, value contract etc., subcontracting scenarios as typically
private labels manufacturing is subcontracted. Retail purchase orders need to consider rounding profiles
and logistics constraints for load building before recommending a purchase order quantity.
Financial settlement of vendors
Vendor evaluation based on different criteria
C. Supply Chain Execution Any retail ERP needs to support typical retail supply chain execution
processes like goods receipt, goods issues, inventory management and processes for merchandise distribu-
tion like warehouse and transport management. Each of this can have several sub-processes like goods issue
can be further divided into creating outbound delivery, pick, pack and final goods issue. Creating outbound
delivery can be further subdivided into vehicle scheduling, route determination, staging area and picking
location determination and planning for proof of delivery. Posting of goods receipt can be further divided
into posting goods receipt, quality check, invoice verification, final settlement etc. There can be several
variants to merchandise distribution processes like cross-docking, flow through etc. ERP software supports
real-time tracking of inventory transactions, automated cycle counting, different inventory accounting and
costing techniques and integration to handheld devices.
D. Managing Pricing and Promotions With thousands of articles and with changes in competitors
and wholesale price almost everyday, managing price is a complex challenge that every retailer faces. On
top of it every article goes through several promotions and end-of-life markdowns during its life cycle. ERP
software supports maintenance of pricing conditions and rules, item specific promotions, mass maintenance
capabilities of pricing rules applicable for thousands of articles, complex approval workflows for pricing
where prices fixed by a store manager can go through several approvals before being implemented, main-
taining different effective dates of different pricing schemes, store-specific price maintenance etc. Some of
the leading retail ERPs also support sophisticated price simulation and modelling capability, system-gener-
ated alerts in case there is any exception in pricing rules and ability to do an impact analysis of different
pricing strategy.
E. Point-of-Sale Integration Retail ERP software provides integration with point-of-sale solutions.
Several leading retailers use ERP solutions like SAP or Oracle mainly for their head office and central dis-
tribution centre for financial book-keeping, master data maintenance and merchandise planning–procurement
i.e. releasing purchase orders to vendors. However, at store level, these ERP solutions are not used, instead
some of the leading points of sales solutions from vendors like IBM, NCR and Retailix are used. This calls
for high level of integration between ERP and POS solution as master data (like article master, vendors etc.)
created in ERP need to be available at POS solution or purchase orders created in the ERP system need to
be available in POS for taking delivery of materials at store level. Any price changes or promotion created
in central ERP need to be available in local POS. On the other hand, daily sales information and store stock
need to flow from local POS to the retail ERP system for replenishment planning.
F. Store Operations Retail ERPs support different store operations like point-of-sale (POS) systems,
store inventory management, store ordering and replenishment, store receiving, loss prevention, cross-chan-
nel order fulfillment, workforce and task management etc.
 ERPs for Different Service Industries 569

G. Retail Planning Retail ERPs support different retail planning activities like demand forecasting,
merchandise budgeting and planning, assortment planning, category planning, promotion planning, mark-
down planning etc.
H. Specialised Industry Requirements Retail is not one industry and the requirements of an ap-
parel retailer are very different from that of a grocery or pharma retailer. Retail ERPs need to meet these
different segment requirements, for example:
For an apparel retailer the capabilities which are most important are design capability, new product
development, global sourcing, assortment planning, markdown decisions etc.
For a grocery and food retailer, inventory management, replenishment planning, food safety, cold chain
management may be most important
For a white goods retailer, warranty management, service and managing return may be most impor-
tant
A retailer needs to understand these different business drivers for each segment and meet these require-
ments of specialised retailers. However, for some retail formats, these differences are blurring these days.
Today’s hyper markets and supermarkets like Big Bazaar sell almost everything i.e. they will like to have
all of those mentioned earlier.

Retailers Prefer Roll-out Approach in Implementing ERP than Big Bang

Most of the retail ERP projects are not big bang and retailers prefer to follow a roll-out approach. Typical
retail ERP implementation starts at head office to streamline the basic high-volume transactions in financial,
purchasing and inventory area. Post these, things like pricing and store replenishments are looked at. A roll-
out approach is followed for stores where the implementation starts with few pilot stores and later rolled out
to others. Generally, planning functionalities like forecasting, assortment planning etc. are targeted at the
end as these things take time to stabilise. However these priorities may differ based on type of retailer—for
an apparel manufacturer, one may choose to implement a PDM or PLM application in first phase itself to
bring their product development process under control.

Two Leading Retail ERPs

A. Oracle Retail Solution Oracle had a series of acquisitions for building its retail suite: Profit Logic
for store operations, 360 Commerce for point-of-sale (POS), TempoSoft for workforce management func-
tionality, Siebel for customer loyalty functions and Retek for overall retail solutions. Today, Oracle’s retail
suite mainly has the following building blocks:
Merchandise operations
Merchandise planning and optimisation, built on Profit Logic assets. New functionality in planning
and optimisation includes the next version of Advanced Inventory Planning (AIP) and new systems
for regular price optimisation and assortment planning
Store operations, a combination of the Retek and 360 Commerce point-of-sale (POS) and store inven-
tory management assets
Oracle’s retail suite is integrated with PeopleSoft financials, workforce management functionality from
TempoSoft and customer loyalty functions from Siebel.
Oracle has lot of global clients in retail space like Tesco, Carrefour, Benetton etc. In India Oracle retail
solutions are getting implemented at Arvind Mills and few other retailers like Raheja-owned Globus, Piramal
group’s Piramyd retail etc.
Figures 36.1 and 36.2 give a high-level overview of different modules of Oracle retek retail solution.
Fig. 36.1 Oracle Retek Retail Application
570
Enterprise Resource Planning
 ERPs for Different Service Industries 571

Fig. 36.2 Oracle Retek Retail Solutions and Products

B. SAP Retail Solution SAP, the world’s largest ERP software company had done several acquisitions
in last few years to build their retail suite and some of them are: Triversity (POS solution), Khimetric
(Price, Promotion and Markdown solution), Applied data communications (Fresh item management grocery
solution) etc. This had helped SAP to have retail-specific functionalities in their portfolio. Figure 36.3 gives
a high-level overview of different modules of SAP retail solution.
In India the RPG group, Pantaloon, Madura Garments, Welspun and Delhi-based Vishal Mega Mart have
already implemented SAP. The country’s most ambitious retail venture Reliance Retail has also opted for
SAP for its retail stores. Tata’s Trent, which owns the Westside brand of stores, has also opted for SAP. SAP
had opened retail centre of excellence in Mumbai to showcase scenarios for different retail verticals (like
apparel, grocery, drug etc.), conduct audits for ongoing SAP retail implementations and provide inputs to
retail design team for India localisation needs in SAP solution. Some of the retailers who went live with
SAP in India in year 2008 include Nilgiris Dairy Farm, India Bulls, Subhiksha, etc. and SAP for retail has
further strengthened its presence with successful wins such as DLF Retail.

ERPs FOR HEALTHCARE

Healthcare globally is one of the largest industries that affect almost every people around the globe. There
are different players in the healthcare ecosystem starting with patient, healthcare providers (i.e. hospitals,
nursing homes etc.) and payers for healthcare services (in most cases these are healthcare insurance agen-
cies, organisations like Mediclaim etc.).
Figure 36.4 shows typical processes/resources and information that a healthcare provider (for example,
a hospital) need to manage. ERPs of late had come up with specific versions of their solution to meet such
needs. Table 36.1 shows a list of unique requirements for such industry that ERP vendors need to address.
572 Enterprise Resource Planning

Fig. 36.3 SAP Retail Solution Modules

Fig. 36.4 Processes for a Healthcare Provider

 ERPs for Different Service Industries 573

Table 36.1 Industry Requirements from ERP Solutions (Healthcare)

Industry Requirements Expectation from ERP Solutions

For Healthcare Providers
Managing medical records Complete record and documentation of a patient’s case—diagnosis, treatment, medication
etc.—is becoming a must in western countries. This had given rise to booming medical
transcription business in countries like India. Any ERP for this industry need to support
managing such records (documents in different formats) throughout a patient’s treatment
cycle. This also is the basis for getting payments from payers as the medical insurance
company can clear the payment based on these documents. This record management
also need to ensure quick retrieval of information.
Scheduling appointments An ERP for a hospital needs to plan and schedule appointment for outpatients and
inpatients. Actually this schedule needs to drive registration process for patients to the
hospital as no one want to just get appointed in the hospital without an appointment.
While doing this availability of doctors / nursing staff needs to be checked along with
that of the patients.
Planning for beds Leading ERPs come with a specialised module in this area that can automatically search
for free beds, allocate beds to patients, and plan and monitor bed occupancy for health-
care provider institutions. Every hospital wants to optimise their utilisation ratio as this
increases cost-effectiveness for the hospital.
Managing operation Can be a complex thing with lot of challenges in terms of increasing the utilisation
theatre ratio, ensuring availability of doctors depending on their specialisation on a particular
date, providing priority for emergency cases etc. Some ERPs come up with specific
functionalities to conduct advance bookings for patients and to generate operation theatre
schedules and to monitor them.
Tracking of inpatient and This tracking has become important these days as more and more healthcare institutions
outpatients see patients as consumers. Some hospitals had gone to the extent of generating automatic
e-mail/mobile messages to be sent to their patients to remind them of next scheduled
check-up. ERP and CRM systems can do a great value add here.
Managing waiting lists of There can be waiting lists at every section of a hospital: at outdoor, at operation theatre,
patients at radiology department, at pathology section etc. No patients likes waiting and too much
of it can result in loss of revenue. Handling waiting lists efficiently helps to optimise
resource usage and to reduce waiting times in healthcare provider institutions.
Patient help desk and man- Increasingly, hospitals and healthcare centres are showing interest in building closer
aging patient queries relationship with their patients. They are putting up patient help desk or call centres
to answer all usual queries like cost for treatment, length of stay and current waiting
lists etc.
Providing information and To improve patient compliance and satisfaction, patients need to have reliable and com-
education to patients prehensive information about their diseases, possible preventions, healthy lifestyle etc.
This information need to be automatically adjusted to the needs and health circumstances
of the specific patient. ERP systems are coming with specific health portals where such
information can be loaded.
Online diagnostic reporting/ All diagnostic reports are made available on the website of the hospital.
image reports
(Contd)
574 Enterprise Resource Planning

(Contd)

For Healthcare Payers

Claims handling Payers (like healthcare insurance agencies) need to initiate, track and monitor claims and
these claims need be processed fast while legitimacy of the claim need to be thoroughly
checked. ERP systems need to support this process.
Payer relationship This supports the healthcare provider institution to capture, monitor, store and track
management all information related to the billing and payment processes. This information includes
detailed payer profiles, payment activities and behaviour. ERP and CRM systems can
support these requirements.
Payer communication An open communication between healthcare provider institutions and payers is important
during the billing process to provide complete documentation to the payer and for quick
response in case of missing data. Again this is an area where an online portal from an
ERP vendor can come handy as sometimes, months are passed and payments do not get
settled for missing documents, missing approvals etc. and patients suffer.

While these are unique requirements for healthcare industry, this industry also has all traditional require-
ments from the ERP solution like financial accounting, payroll for employees, managing hospital stores,
procuring medicines, medical equipments, consumables etc.
While leading ERP solution providers like SAP and Oracle both have separate industry solutions for
healthcare industry, there are numerous small ERPs which are traditionally sold as Hospital Management
Information systems. Microsoft Amalga is such a leading Hospital Information System. An ERP for health-
care industry can have modules as shown in Figure 36.5 and these are:
Patient registration and appointement scheduling
Outpatient management
Patient billing
Indoor patient management
Hospital store inventory management
Payroll
Pharmacy management
Resource scheduling (planning and scheduling for beds, operation theatre)
Financial accounting

ERPs FOR EDUCATIONAL INSTITUTIONS

Educational institutes off late had started looking at ERP solutions for operational efficiency. Here is a
recent news item.

IIM-SHILLONG COUNTRY’S FIRST CENTRAL INSTITUTE TO FULLY IMPLEMENT ERP SOLUTION

Indian Institute of Management (IIM) Shillong or Rajiv Gandhi Indian Institute of Management has
claimed to have become the first among India’s centrally funded technical institutions and universi-
ties to complete implementation of a comprehensive enterprise resource planning (ERP) solution.
The institute has implemented various modules from Oracle’s PeopleSoft Campus Solutions and
Oracle Applications with the help of Citagus India Private Ltd, a leading IT solutions and services
 ERPs for Different Service Industries 575

Fig. 36.5 ERP Modules for a Hospital

company. Prof Ashoke Dutta, director IIM Shillong in a statement said, “In today’s fast changing and
highly competitive environment, we are determined to provide quality education to our students.
IIM Shillong has taken a big step to implement a comprehensive IT solution with the help of Oracle
and Citagus. We have sought to reduce manual processes as much as possible, and provide access
to real-time information for students and the college management and faculty.” IIM Shillong’s IT
implementation has automated all its backend processes. This has improved time management,
data accounting and the efficient management of human resources and staff/student feedback.
The net result has been to free up more time and resources, and provide better information for
management and faculty to enhance their core mission of delivering education programmes to
the institute’s post-graduate students.
Source: A news item by Bikash Singh, ET, Guwahati, 8th Aug 2009.

As discussed in the above news article, educational institutes of today can benefit a lot from ERP systems
in terms of managing numerous courses, programmes and student records. Areas where ERP solutions can
help are as follows:
576 Enterprise Resource Planning

Managing Student Life Cycle

Student master data: Students’ data and personal information maintenance
Registration/Admission of students to different study programmes/specialisations according to
institute’s rules and course prerequisites
Handling different examinations: Managing exam schedules, creating task lists for different stake-
holders
Managing student’s performance and grading: Keeping record of different course results by an
individual student, and managing course credits and grades are facilitated by ERP systems. These can
be kept for future use.
Managing students’ degrees: Student’s performance need to be compared against degree requirements
and once the degree is awarded, the system need to maintain this record—in most cases on permanent
basis.
Managing students’ financials: Institute needs to ensure that regular payments (tuition fees and
others) are received from every student for each course on time—each student’s account need to be
maintained. Some students in each institution is given financial aid in different form—this need to be
tracked and a particular student’s tuition fees need to be calculated accordingly. It is also important
to provide transparent information to agencies that are sponsoring such grants.
Online services to students: These include things like online registration/booking to a course/
programme, online payment of tuition fees etc. Again this is an area where Portal solution from ERP
vendors can help.

Managing Education Campuses

This include managing different facilities of a university/college campus and can include things like student’s
hostel and housing, health centres, student’s club, hospitals, parking, security etc. An ERP system can track
expenses and accounts for such facilities, procurements needed for running these, maintenance etc.

Managing Libraries
There are specialised software for managing libraries known as library management information system
(LMIS) which keeps track of thousands of titles available in a student library, authors, prices, which book
is issued to which students on which date etc. These systems can send automatic mail/message reminders
to students who had not returned a particular book on the due date. The system can reserve a book for the
library member when not in stock so that the book can be issued to him as soon as someone returns it. LMIS
systems generally have online book catalogues. While some ERP systems offer LMIS as part of it, some
others (like SAP ERP) do not offer LMIS as part of it but can be integrated easily with an LMIS solution.

Managing Different Academic Services

An ERP system can also help educational institutions in terms of:
Planning courses and curriculum: ERP systems helps in planning for new courses, development
and maintenance of curriculum.
Developing course content: This include activities like content planning, content production, content
publishing and distribution, and finally licensing the content to maintain its IP rights. ERP system’s
content management solutions can help in this area.
Scheduling class/exam and publishing schedule: ERP systems can help in scheduling class looking
at resource (in this case teachers and classrooms) availability, prerequisites for each class, inter-class
 ERPs for Different Service Industries 577

dependencies, number of students registered in a class, facility requirements etc. The system can also
help in scheduling exams. Course catalogues and schedules of events can be published in various
forms such as printed and online.
Planning capacities: This includes planning space for each programme and session. ERP systems can
consider prerequisites for admission and skill of instructors while planning capacity.
Evaluation of different programmes: It is important to get student’s evaluation on content and use-
fulness of every programme so that the same can be used to further improve the course content.
Figure 36.6 gives a high-level overview of different modules of SAP ERP for educational institutions.

Fig. 36.6 Different Modules of an ERP Solution for Educational Institutions

ERPs FOR TELECOM

Telecom sector is one of the largest spenders of IT applications globally and most of the large telecom
companies globally have one or the other ERP solution in place. While telecom companies are not very dif-
ferent from other industries in terms of normal accounting or procurement practices, “customer billing” is
one of the complex areas for telecom operators because of customer volume, different tariff rate and billing
plan for an individual customer, there can be several calls a day and depending on the time of the call, the
rates may differ (late night calls may be at very different rate than calls at office hours) etc. Long before
578 Enterprise Resource Planning

ERPs become fashionable in this industry, Telecom billing software, which used to cater to this particular
need, was very popular. These applications can receive and collect usage data from the network systems
and group and aggregate the event detail records (for example, according to criteria like local, regional and
national calls) to create the billing document and can include recurring and one-off charges into the billing
document. Pricing of each single event (i.e. a particular call) can be based on service and/or customer-
specific tariffs (considering parameters such as duration of events, time zones, distances and volumes).
These applications can also help in managing billing related disputes and customer complaints which are
very common in this industry.
Another area where ERP vendors are coming up with specific offering for telecom industry is managing
dealers. Most of the telecom service providers depend heavily on dealers for selling their services and ef-
fective collaboration with them can be a win–win for both parties.
CRM is widely used for telecom industry for reasons like higher service requirement, mobile sales and
regular need of cross-selling/up-selling.
Finally, this industry is going through a major shift now where a good percentage of telecom company’s
billings come not only from voice or messaging services but also by offering additional services like ringtone.
For example in India the company which makes maximum money from music business is no longer HMV
or RPG group – but this is a telecom company – Bharti Airtel. This imposes additional business complexity
like revenue sharing with music companies. Today’s ERP solutions started supporting these processes.

ERPs FOR BANKS

Banks are matured users of IT. Today, every bank had implemented some software application to automate
their transactions, almost every bank offer ATMs, most of the large banks offer multi-channel transactions
i.e. one can transact with the bank by physically visiting its branch, through internet, through mobile device,
through ATM etc. There are different ways banks are classified today—by type of ownership (like private
or government bank), by type of operation (like retail bank, investment bank, microfinance organisation
etc.).
A typical bank’s activities can be as follows:
Supporting transactions and maintaining data for savings account and card: Maintain data for
pass book (savings a/c), maintain data for cards, which are sometime linked to the savings account
Fixed-term deposit: Maintaining different term deposits, and interest calculation for the same
Dealing with share, bonds, investment funds, derivatives etc: Trading shares and bonds, buying
and selling investment funds, trading derivatives
Offering different brokerage services: Buying and selling shares, mutual funds etc. on behalf of the
customer
Card management: Card sales, card issuing, card authorisation–utilisation, card transaction process-
ing, settlement/acquiring

Different Types of Financing Services

Different types of financial services are as follows:
Offering loans to the customer: house loan, car loan, personnel loans etc.
Project financing: financing for different projects
Trade financing/letter of credit (LOC) services: Issuing LOC for import and export
Leasing
 ERPs for Different Service Industries 579

Treasury Management
Banks can offer different types of treasury management services like:
Interest rate management
Foreign exchange management/trading currencies
Credit risk management

Leading ERP Solutions for Banks

Unlike most of the other industry sectors, this is one industry where SAP and Oracle are not market leaders.
As per Forrester Wave – Global Banking Platform – Q1’2009, Infosys’s Finacle Banking Solution is the
market leader here. While SAP and Oracle have their banking industry specific ERP solutions, TCS also
has a leading product here in the form of TCS BaNCS Banking Solutions. Some of the leading Banking
ERP solutions are given in Table 36.2.

Table 36.2 Leading ERP Solutions for Banks

Banking ERP Vendor Banking ERP Solution Banking ERP Modules

Infosys Finacle Finacle Core Banking Solution
Finacle Consumer e-banking Solution
Finacle Corporate e-banking Solution
Finacle CRM Solution
Finacle Treasury Solution
Finacle Wealth Management Solution
Finacle Mobile Banking Solution
Finacle Web-based Cash
Oracle FLEXCUBE Oracle FLEXCUBE Core Banking
Oracle FLEXCUBE Private Banking
Oracle FLEXCUBE Universal Banking
Oracle FLEXCUBE Microfinance
Oracle FLEXCUBE Direct Banking
Siebel Branch Sales and Service
Siebel Branch Teller
Oracle FLEXCUBE Lending and Leasing
Siebel CRM on Demand Financial Services Edition
Oracle Mantas Anti-Money Laundering
Oracle Mantas Trade Compliance
Oracle Investor Servicing
Oracle Financial Services Accounting Hub
Oracle Banking Solutions
Oracle Trade
SAP IS Banking SAP Deposits
SAP Collateral Management
SAP Loans Management
SAP Deposits Management
SAP Loans Management
SAP Collateral Management
(Contd)
580 Enterprise Resource Planning

(Contd)

SAP Bank Analyzer as a product platform for:

SAP Limit Manager
SAP Basel II
SAP Accounting for Financial Instruments
SAP Profitability Analysis and Management Accounting

TCS BaNCS TCS BaNCS Core Banking

TCS BaNCS Channels
TCS BaNCS Trade Finance
TCS BaNCS Wealth Management
TCS BaNCS CRM, Sales, Contact, and Lead Management
TCS BaNCS Compliance
TCS BaNCS Payments
TCS BaNCS Treasury
TCS BaNCS Cards
TCS BaNCS Securities Trading
TCS BaNCS Asset Liability Management

These days CRM applications are also becoming popular with banks for reasons like:
Every bank today has a call centre
Provide loyalty points for using bank cards (loyalty management)
Need to provide better service to their customers
Need to send customised information/message to their target customers
Customers can interact with bank through multiple channels i.e. a customer can open a fixed deposit
by visiting the bank, through ATM, by internet or even through their mobile phone by sending a
message to the bank

ERPs FOR INSURANCE COMPANIES

Insurance companies have lot of processes which are very typical to this industry and ERP solutions for
this industry need to address those.

Policy Management
This module of an ERP for an insurance company can have functionalities like:
Registering new policy applications: New policies are lifeblood of insurance companies. While
enrolling new application, special care must be paid to capture the premiums and benefits requested
by the customer. It is important to verify the completeness and consistency of data. A new application
may involve building new relationship not only just with a new customer but also with a set of people
like policyholder, insured person, commission recipient, premium payer and so on.
Risk assessment: It is important for insurance companies to do a risk check for the new policy holder
and to ensure that risk is insurable. The risk check (like doing a health check for policy applicant) is
usually performed on the basis of information provided to the insurance company by the policyholder
before the policy agreement becomes valid. ERP systems need to keep such risk check records and
do a quantitative risk assessment based on a set of criteria.
 ERPs for Different Service Industries 581

Maintaining policy database: ERP systems helps is maintaining policy database from where a policy
can be accessed via primary identification key (in most cases it is policy number) or secondary key
(such as policy holder’s name).
Managing policy updates: The life of an insurance policy can be long say 25-30 years and there can
be several updates during its lifecycle like loan against policy, premature etc. ERP systems need to
maintain all such updates.

Claim Management
There can be two types of claims for an insurance company i.e. normal claims on maturity and pre-mature
claims. A pre-mature claim can be made to an insurance company for different reasons like sudden death
of a policy holder (in case of life insurance) or a road accident (in case of an auto insurance). Insurance
companies need to evaluate such claims in details to perform a validation and then to determine whether the
insurer is obliged to pay compensation. On the basis of this claim evaluation, they decide whether this is
a valid claim (i.e. the insurer need to pay for it) or the claim can be rejected. Finally, insurance companies
settle claims by making payouts to the policyholder or other claimants. There can be litigation i.e. insurance
companies have to handle claims in which the involved parties disagree on the settlement. An insurance
company’s ERP module claim management can have functionalities like:
Claim registration
Claim evaluation
Settlement
Litigation

Reinsurance
It is a common practice among insurance companies to share a risk among several insurers. The contribution
of an individual insurer can be governed either by a participation quota or by a fixed sum. The participat-
ing insurers can share the premium and loss payouts in the same proportions they take the risk. Insurance
companies need to analyse and determine which reinsurance coverage to buy to structure their portfolios
based on the risk identified. Finally, insurance companies need to invite offers from different reinsurers to
provide such coverage at a price to ensure that they carry only a percentage of the risk. ERP solutions need
to support the reinsurance process.
While both the leading ERP solution providers like SAP and Oracle provide specialised solutions for
insurance companies, there are also hundreds of small ERP vendors who specialise in ERPs only for insur-
ance companies. Figure 36.7 shows the modules of such a niche ERP vendor’s solution for an insurance
company.

ERPs FOR UTILITY COMPANIES

Utility companies are the companies that produce power (thermal, water, wind or nuclear power), supply
water or gas and they touch the life of every consumer. While these companies have usual requirement
of supporting their processes like plant maintenance, workforce management, procurement, inventory
management etc., these companies have few unique requirements from an ERP solution. Some of these are
discussed as follows:
582 Enterprise Resource Planning

Fig. 36.7 ERP Solution for Insurance Companies

Managing Meters
Installation and inspection of meters: Utility companies take responsibility of installing meters/
devices at customer locations. Such meters need to be inspected at regular interval sometime follow-
ing a sampling procedure. Sometime these meters need to be replaced periodically. In certain cases,
individual meters are certified by the utility company. ERPs for this industry need to support such
processes.
Reading meters and consumption determination: Meter readings need to be done periodically for
periodic billing (say monthly) or on non-periodic basis (this may be at the time of device replace-
ment, removal, or disconnection). Meter reading results need to be converted into actual consumption
values.

Energy Trading
This is a process widely used by energy companies as it is difficult for an individual company always to
meet the peak demand for all its customers; the company gets into agreement with others to meet such
demands. This means entering into business agreements/contracts with trading partners. ERPs for utility
companies provide options for hedging such future risks in the form of options, forwards, swaps, derivatives,
position management (i.e. long/short positions) etc. Sometime ERPs can be integrated to trading exchanges
to facilitate such transactions.
 ERPs for Different Service Industries 583

Billing
Like telecom companies, billing is also a complex process for utility companies as individual bills need to
be created and sent to thousands of customers—most of which can be individual houses. Thousands of tariff
plans/rate contracts/billing rules need to be maintained for individual customers based on appropriate bill-
ing master data (rates, billing schemas etc) and this is one area where ERP systems can come handy. ERP
systems term this as budget billing plans where a utility company normally bills for its services at the end
of a supply period (i.e. a month). For commercial and industrial customers, billing can be a much complex
process involving wholesale tariffs, several types of discounts and local government policies. ERP billing
engine needs to integrate with energy data meters to calculate bill amounts.

Managing Waste and Emission

Power plants are known for high pollution level due to its emission and huge amount of solid waste and ash
it generates. Some of the leading ERPs like SAP had come up with specialised modules for waste manage-
ment and emission management that helps in measuring such wastes and taking corrective action so that it
never crosses the threshold level.
Utility is a large industry sector—both SAP and Oracle have specialised industry solution for this industry.
While SAP’s IS Utility solution had been implemented by several utility companies across the world, Oracle
had seen strong presence with some of the large utility companies mainly in North America.

Summary
ERPs for retail industry need specific functionalities around category management, merchandise budgeting
and planning, assortment management, space management, advanced promotion planning, replenishment,
point-of-sales solutions and store operations. SAP IS Retail and Oracle Retek are leading solutions in this
space.
ERPs for healthcare industry need to make the requirements of both the healthcare provider (i.e. hospitals)
and healthcare payer. Hospital ERPs can have specific modules around managing medical records, schedul-
ing appointments and bed, tracking inpatients and outpatients, patient help desk, online diagnostic reporting
etc.
ERPs for educational institution can have functionalities around student registration, admission to course
designs, managing different financial aid, grading and progression for students, graduation for students and
finally managing alumini relations.
ERPs for telecom industry need specific functionality around customer billing and customer service manage-
ment.
ERPs for banks need functionalities around managing bank accounts, fixed-term deposit, offering different
brokerage services, card management, loans, project financing, trade financing, treasury management etc.
Infosys’s Finacle is a leading ERP in this space.
ERPs for insurance companies need functionalities around policy management, claim management, reinsur-
ance etc.
ERPs for utility companies need functionalities around managing meters, energy tading, blling, managing
waste etc.
 Section

Case Studies
 Cases of ERP and
Enterprise Application

Learning Objectives
In this chapter we will discuss the following concepts:
mySAP Business Solution implementation at ITC
Nestle GLOBE project—A successful example of global rollout
Oracle ERP implementation at Maruti Suzuki
Siebel CRM implementation at Bharti Airtel
i2 Supply Chain Solution Implementation at Asian Paints

In this chapter some real-life examples of ERP and Enterprise Solution implementation in some leading
companies in India and across the globe are discussed. Case studies are chosen selectively from different
types of Enterprise solution (ERP, CRM, Supply Chain Application etc.) implementations and from differ-
ent industries.
The first case is on how India’s largest consumer goods company ITC had implemented multiple enterprise
applications mainly from the SAP platform to increase the efficiency of their supply chain. This case study
discusses how enterprise solutions had helped ITC’s business processes, which were mainly built around
tobacco industry specific processes to one which is distribution-driven and a best in class supply chain for
any consumer goods company.
The next case study is on Nestle—the world’s largest food company. Nestlé’s Enterprise Application
implementation programme GLOBE is an interesting example of how a complex enterprise application
implementation programme of global scale involving thousands of end-users, multiple countries, multiple
languages and various businesses can be managed effectively. Nestlé is a trend-setter for many such enter-
prise applications roll-outs which several multi-national organisations had done in last few years.
While the first two case studies mainly focuses on implementation of SAP application, the third one is an
example of Oracle solution implementation for India’s largest car maker. The fourth case study goes beyond
ERP and talks about implementation of CRM solution for India’s largest telecom company. The fifth and
final case study talks about implementation of the specialised supply chain solution for India’s largest paint
maker.
588 Enterprise Resource Planning

mySAP BUSINESS SUITE IMPLEMENTATION AT ITC

Company Background
ITC is one of the leading consumer goods company in India having diversified business interest in tobacco,
food, hospitality and export. Its turnover in year 2009 was around Rs. 20,000 crore making it India’s larg-
est consumer goods company ahead of Hindustan Unilever Limited. The company is an undisputed market
leader of the Indian Tobacco market for last fifty years and ventured into food segment a few years back
having lot of successful brands today like Sunfeast, Aashirbad, Candyman etc. Recently, ITC entered into
personnel care products like soap and shampoo.
ITC’s biggest strength is its distribution capability, what ITC defines as its distribution highway. It reaches
close to 1.6 million retail outlets and even the smallest panwala in a village keep its products—thus giving
it a reach just next to Indian postal service. ITC today owns close to 40 fully or partially owned factories,
60 warehouses and more than thousand distribution centres. Its distribution highway gives it the strength of
taking virtually any product to its customers.

Journey with ERP and Enterprise Applications

ITC had decided to go for an integrated ERP solution long back it became a fashion with Indian corporate. It
had implemented an SAP R/3 solution way back in 1999 with Price Waterhouse Cooper mainly for its tobacco
business. In 2004-2005, ITC decided to go for another re-implementation of SAP ERP solution and other
mySAP business suite products (like APO, SRM, BW etc.) for their different lines of businesses like tobacco,
food, matches, agarbatti and FMCG products. The second implementation was done by SAP consulting.
While the entire sales and distribution channel (i.e. sales offices, warehouses, hubs, distribution centres etc.)
and ITC’s own manufacturing units were under the project scope, the subcontracted manufacturing locations
(most of the food factories were subcontracted operations) had done a light SAP implementation.

Reasons for Implementing ERP/Enterprise Solutions

The major drive for ITC for implementing the enterprise solution was to drive its supply chain efficiency.
Historically, ITC was in the business of making and selling tobacco, where the company was the market
leader and had virtual monopoly—with very little competition. In last two decades, ITC intentionally tried
to grow its non-tobacco business (because of serious restrictions imposed on tobacco manufacturers around
the world in the form of higher tax etc.) and entered into new segments like food, personnel care etc. In
these segments, competition was intense and ITC’s traditional supply chain designed for selling cigarettes
was not enough to meet the demands of new business. Food and FMCG supply chain is driven by frequent
promotion, price changes, regular new product introduction, higher advertising budget etc. which were not
important for tobacco supply chain. ITC wanted to redesign its supply chain with measures like
Identifying new measures and KPIs for supply chain i.e. what supply chain performance indicators
they should look at;
Scientific forecasting method that will provide higher forecasting accuracy;
Scientific calculation of inventory at each supply chain node i.e. how much finished goods stock they
need to carry at distributor’s end, at warehouses and at factory;
Optimised production plan for their factories;
Scientific calculation of delivery order quantity for their distributors i.e. how much stock they should
send to their distributors so that they do not carry excess inventory and at the same time do not face
a stock-out situation
 Cases of ERP and Enterprise Application 589

Project Highlights
This was a mammoth implementation in Indian standard covering several factories, warehouses and dis-
tributors from almost every Tier 1 and Tier 2 cities of the country. The project continued for around 18
months from January 2006 to July 2007 and the project head office was ITC centre, Kolkata. The project
was delivered by SAP India along with ITC Infotech. There were other partners also involved in the proj-
ect like IBM India and Siemens Information Systems Limited for delivery of specific parts. Multiple SAP
modules were implemented like SAP ERP, SAP SRM, SAP APO, SAP BW, SAP PI etc. ITC was also the
first company to implement few SAP modules in the country. SAP APO TPVS (Transportation Planning and
Vehicle Scheduling) was one such module which the company had implemented for transport optimisation
first time in India. This was also the largest SAP APO Demand planning module implementation in the
country where more than 800 sales people around the country log on to the system in the month beginning
and input their demand estimates for different SKUs concurrently.

NESTLÉ GLOBE PROJECT—A SUCCESSFUL EXAMPLE OF

GLOBAL ROLLOUT
Company Background
Nestlé is the largest food and beverage company in the world with sales of USD $71 billion in 2005. It
is the world’s largest coffee maker (Nescafe) and water bottler (Perrier, Vittel). Its major brands include
Nestea, Nescafe, Maggi, Purina, Kikat etc. It sells and manufactures at over 500 facilities in 70 countries.
Its products are available in nearly every country around the world. With more than 250,000 employees,
Nestlé is Switzerland's largest industrial company, and ranks in the Global 500. The headquarter is in Vevey,
Switzerland. Nestlé also owns Alcon, the U.S. eye-care firm, and 26.3% of L'Oréal, the French cosmetics
group.

Journey with ERP and Enterprise Applications

In year 2001, Nestlé had started its most ambitious ERP and Enterprise implementation programme GLOBE
(Global Business Excellence). This is the largest project Nestlé has ever initiated, and it is the largest ever
SAP implementation project in the world. By the middle of 2006, Globe covered over half of Nestle’s Food
and Beverage Business with overall coverage of 90,000 users, 300 factories and 350 distribution centres.
GLOBE seeks to improve the performance and operational efficiency of its businesses, worldwide. In the
process, GLOBE revisited all aspects of business practices with the goal to run Nestlé's business in different
ways for the future. The objectives of the programme included a fully documented, standardised group-wide
business process architecture and master data with the help of mySAP business suite. The programme was
based on a dedicated methodology called GLOBE Roadmap which is a blend of the SAPs’ ASAP and PwC’s
ascendant methodology.

Project’s Mission
GLOBE had the mission to unlock Nestlé's potential by:
1. Leveraging its size as a strength in a rapidly changing environment;
2. Uniting and aligning Nestlé internally to be more globally competitive;
3. Enabling Nestlé to manage complexity with operational efficiency.
590 Enterprise Resource Planning

Project Objectives
GLOBE had the following objectives:
1. Implementation of harmonised Nestlé Business Excellence Best Practices;
2. Implementation of Data Standards and Data Management—“Managing Data as a Corporate Asset”;
3. Implementation of standardised information systems and technology.

Project Highlights
The programme began with a high-level strategy phase. Then began the development of the GLOBE Tem-
plate in February, 2001, with over 200 specialists and managers from 40 Nestlé markets around the world;
150 IBM consultants from Asia, the Americas and Europe as well as 50 consultants from SAP AG, who
worked in Vevey, Switzerland, in what is now known as the GLOBE Business Technology Center (BTC).
Their mission was to map and translate Nestlé’s needs into detailed processes within the GLOBE Template
and thus develop a Nestlé solution on the SAP platform. This template was then successively implemented
in all significant Nestlé markets supported by regional GLOBE centers in Frankfurt, Sao Paolo/Toronto,
and Sydney. Worldwide, the global and regional GLOBE centres and local GLOBE organisations include
3000+ people.

Project Scope
The scope of GLOBE is across the complete Nestlé organisation including its all organisational entities. It
covers most process areas of Nestlé including:
Supply (procure-to-pay, materials handling, demand and supply planning, transportation and customer
service)
Finance and controlling
Demand (marketing and sales)
Technical and production (manufacturing, quality, PLM, plant maintenance)
Human resource including payroll
GLOBE had multiple SAP modules in scope including the following:
SAP ERP modules including: Human Resource (HR), Finance (FI), Materials Management (MM),
Sales and Distribution (SD), Warehouse Management (WM), Production Planning – Process Industries
(PP-PI), Quality Management (QM), Project Systems (PS), Environment, Health and Safety (EH&S),
Plant Maintenance (PM), Purchasing, Payroll etc.
SAP Supply chain management solution known as Advanced Planner and Optimizer (APO)
SAP Customer Relationship Management (CRM) solution
SAP Supplier Relationship Management (SRM) solution
SAP Business Warehouse
SAP Enterprise Portal

Implementation Approach
GLOBE is one of the most successful examples of global template building and roll-out approach. The
global template was completed in 2003 and subsequent functional additions are performed as increments
to the template.
The global template contained data standards, common processes, associated systems settings and
documentation. This also had selected standard interfaces, conversions, reports, project documenta-
tion and training material. The global template is designed and constructed centrally and contains
 Cases of ERP and Enterprise Application 591

approximately 80% of common Nestlé business requirements. This global template is continuously
enhanced to support continuous improvement.
Before rolling out of the template to each country, a fit-gap analysis is done against the template pro-
cess tree to identify which processes are fits (the country can adopt the template) or which are gaps
(missing functionality in the template, legal and critical business requirements). As each country has
different legal, regulatory, tax and excise requirements and can have a few unique processes, there
will always be some gaps.
Region-based deployment teams manage deployment to markets/sites using the GLOBE template as
a base.
Any requirements for new processes are coordinated by the GLOBE template team.
Approved processes/initiatives are implemented, either globally or regionally, based on instruction
from the GLOBE template team.
Market/site customisation is made as appropriate by the regional deployment teams.
The entire project was managed by GLOBE Business Technology Center (known as BTC), which is glob-
ally responsible for business excellence, data standards, change management, the design and maintenance of
the GLOBE template and Global IS/IT. It manages the increments to the GLOBE template and the required
additions/enhancements from the markets, businesses and regions.
There were three Regional Support Centres which are logical extensions of the GLOBE Business Tech-
nology Center and provide support to a set of locations. These centres provided both deployment support
and ongoing application support to ‘live’ sites. They were located in Frankfurt (Europe), Toronto/Sao Paulo
(Americas) and Sydney (Aisa, Oceania, Africa). Various other IT support services is operated on a “Follow-
the-Sun” approach i.e. the next centre automatically takes up the support of the application when the office
hours of the first site is over.

Benefits Delivered
Globe enabled Nestlé to become a company that is well integrated globally yet flexible, united and aligned
on the inside and competitive on the outside, presenting one face to the customer. The new framework and
process models allow improved growth in overall sales through more category-focused management, con-
sumer and customer management applications, improved customer service and improved new product/service
innovation processes and applications allowing better speed to the market. They also present significant
reductions in cost through optimised demand and supply planning, an optimised supply strategy, global
purchasing, business integration, shared services, simplified processes and elimination of duplication. By
2006 when implementation completed in most of the major markets, it is estimated that the total benefits
of the overall programme is in the region of CHF 3.0 billion p.a.

ORACLE ERP IMPLEMENTATION AT MARUTI SUZUKI

Company Background
Maruti Suzuki India Limited is India’s top car maker for last two decades. It was established in 1981 as a
subsidiary of Suzuki Motor Corporation, Japan—Maruti now sources almost all its components indigenously.
While its principal activity is the manufacture and sale of motor vehicles, it also sells spare parts of its car.
Maruti has a 300-strong dealer network and is present almost in every Tier 1 and Tier 2 city in India. Its
annual revenue is in excess of US$4 billion and it employs more than 5,000 people.
592 Enterprise Resource Planning

Journey with ERP and Enterprise Applications

Maruti did not have any ERP system for long time and used a number of home-grown legacy systems to
manage its operations. Very typical to these applications, these disparate systems could not talk to each
other, requiring data entry multiple times and consolidating information to generate reports. Finally, the
company decided to implement Oracle E-Business Suite replacing its existing legacy financial, purchasing,
and human resources systems with Oracle Financials, Oracle Procurement, Oracle Human Resources and
Oracle Self service HR applications. Oracle Consulting was selected as the implementation partner for the
complete implementation.
This project has a key challenge in terms of interfacing the Oracle ERP with Maruti’s numerous legacy
systems for direct item procurement, dispatch systems, the time card system for attendance etc.

Benefits Delivered
With Oracle Financials, Maruti was able to standardise on a single financial management platform,
tighter control over accounts payable and accounts receivable, and quick month-end closing.
Maruti implemented Oracle Purchasing to manage procurement of capital goods, services and indi-
rect consumables. Prior to implementing Oracle Purchasing, Maruti mostly relied on spreadsheets to
manage the process and this made it difficult to have control over capital and services purchasing,
leading to increased costs and excess inventory. With Oracle ERP, Maruti has an end-to-end control
on the procurement process with quick creation of all purchasing documents (PR, PO etc.), automated
workflow that ensures all purchases are approved beforehand, and the accounts payable department is
always informed. Oracle ERP had actually helped in lowering unit procurement costs by streamlining
purchasing.
Maruti had a huge workforce spread across India, and Oracle HR system provided it a single, integrated
system to manage its employees and all HR related activities like recruitment, payroll, compensation
management, leave management, competency assessments, staff development etc. Each employee’s all
personnel records, which used to be spread across numerous excel files, are now stored into a single
database which employees themselves can maintain and it can be accessed by the HR staff at any time
to fill up a new position.
Oracle Self-service HR helped the employees of Maruti to maintain all their data themselves, to man-
age their leave records and to have online access to their all payment information. This freed the HR
staff from doing loads of non-value adding activities like changing staff address, answering employee’s
queries about payment details etc.

SIEBEL CRM IMPLEMENTATION AT BHARTI AIRTEL

Company Background
Bharti Tele is India's largest private sector telecom operators. Its cellular business, Airtel, is a leading mobile
telephony brand.

Journey with ERP and Enterprise Applications

For any player in telecom business, volumes are very large as there are millions of customers making number
of calls and thus resulting in millions of records everyday. These customers need to be billed correctly and
every month the bills have to be sent physically or soft copies have to be uploaded in company’s internet site.
There can be thousands of queries or complaints from customers everyday. Bharti had earlier implemented
 Cases of ERP and Enterprise Application 593

Oracle Financial, Oracle HRMS ERP applications and Data warehousing application to manage such huge
volume. Beyond ERP, it also runs specialised application for billing, fraud management etc.
Bharti’s drive for going for CRM solution was to resolve its customer issues quickly. Before CRM system
the entire customer management process was manual and only 40 percent of its customer issues used to get
resolved on time which had gone up to 90 percent after implementation of CRM system. This helped to
improve customer loyalty. Bharti intends to provide Airtel services anywhere and at any time and a customer
should get the same quality of service no matter which of their call centres he or she contacts.
Bharti had done a detailed evaluation of all leading CRM tools available in the market and finally opted
for Oracle Siebel CRM for its better workflow automation capability, facilitation of knowledge sharing and
integration with the billing system.
Bharti today runs the CRM tool in most of the circles they operate.

Benefits Delivered
The CRM strategy at Airtel revolves around two aspects: operational CRM and analytical CRM. The
first helps their call centres in their day-to-day activities. The second provides required information of
customers; this is used for business development activities. Together, they help Bharti provide better
services to its customers.
In telecom business it is important to understand and segregate customer needs depending on the prod-
uct and services they are buying. CRM solutions helped the company in segmentation of customers
and thus gave company’s customers more value for money. With the help of CRM, Airtel today can
provide different schemes and services to the customers depending on airtime usage. If the customer is
a heavy user then they have some specific schemes; for normal users they have other schemes. CRM
made such tailor-made scheme a reality.

i2 SUPPLY CHAIN SOLUTION IMPLEMENTATION AT

ASIAN PAINTS
Company Background
Asian Paints is India's largest paint company and is ranked among the top 10 decorative coatings companies
in the world. The company has products in decorative segment for home improvement, in industrial segment
and for automotive painting. It sells its products close to 26,000 local retailers, and also directly to original
equipment manufacturers (OEM) and car makers. It produces more than 1,500 standard paint product SKUs
(known as shades) and many made-to-order products against a specific customer requirement. It has close
to 80 sales offices, five manufacturing locations and lot of contract manufacturers who make special grades
typically of low volume.

Journey with Supply Chain Applications

Asian Paints was looking for a supply chain solution that will help them to deliver products efficiently to
the customers without holding a large amount of inventory and will help them to manage their cash cycle.
After a detailed evaluation they selected a supply chain solution from i2 for supply chain master planning,
materials and distribution planning, shop floor production scheduling, sales forecasting and master produc-
tion planning. i2 Master planning module helps in deciding which products should be produced at which
factory optimising on multiple factors like manufacturing cost for producing at a particular factory, volume,
available capacity, transportation costs and service level. i2 shop floor scheduling and factory planning
module helped Asian Paints to schedule production plan on their factory machines in the most optimum
594 Enterprise Resource Planning

way so that they are not idle, there is minimum production loss and at the same time there is no unwanted
inventory in the supply chain. i2’s demand planning module helped the company to make better forecast
with high forecast accuracy.
It was a tough journey for Asian Paints to move from a home-grown solution that they traditionally used
for planning to a state-of-the-art supply chain solution like i2 that uses sophisticated operation research
algorithms for production and distribution optimisation and complex statistical models for forecasting. It
means not just implementing the software, but maturing the users of the application as well—who now need
to be much more disciplined to operate it and analyse the result with an analytical outlook.

Benefits Delivered
i2 supply chain application had delivered multiple benefits to Asian Paints, which are as follows:
Reduction of finished goods inventory and improvement in cash flow: In 1999, the company
operated with an average of 56 days of finished goods inventory. During the initial implementation
phase, the company reduced that to an average of 40 days and later on further reduced this to 30 days.
Reduced inventory increased company’s cash flow.
Increase in service level: i2 solutions helped Asian Paints to improve order fulfilment and its service
level improved to 90% on SKU basis at location level (i.e. order placed from any location is fulfilled
on time for 90% of cases).
Better materials planning: As Asian Paints was coming up with more and more sheds every year
needing more complex calculation of bill of material items, i2 solution helped them to create sophis-
ticated formulations and to select the best vendor (based on a variety of factors like quality, delivery
performance, price, available capacity etc.) and manufacturing method.
Improved distribution planning: i2 solution helped Asian Paints to plan their distribution more
effectively from the factory to warehouses to distribution centres ensuring proper safety stock at
each node of the supply chain. This ensured minimum inventory in the distribution chain with lesser
stock-outs.

Summary
In this chapter some of the real-life implementations of enterprise solutions are discussed. The idea is to understand
the drivers for such implementations, implementation challenges and what kind of business benefits are achieved.
While almost every large organisation today had gone for one or the other enterprise solution implementation,
very few of them are really using these applications to their true potential. The companies mentioned above are
few of those which had done it right and achieved early benefits.
 Index

ABC Classification, 324 Batch Tracking, 452

ABC Slotting, 419-420 Benchmarking, 142
Accounting Payable, 299 Benchmarking Approach for Process Selection, 134
Accounting Receivables, 299 Benefits and Payroll, 286
Activity Based Costing, 304 Benefits of ERP Implementation, 59-62
Alerts, 519 Best Practices, 10, 144
Analytics, 518-519 Bidding, 341
Analytics Segments, 519 Public Bidding, 341
APQC Process Classification, 151 Restricted Bidding, 341
APS, 8 Big Bang, 51, 52
Ariba SRM, 347-348 Billing, 403
AS IS Model, 36 Blanket Purchase Order, 314
AS IS Modeling, 151 BOM, 8
ASAP, 45 BPR, 126
Ascendant, 46 Breakdown Maintenance, 457
Asset Compliance, 464 Budgeting, 299, 303
Asset Life Cycle Costing, 464 Bullwhip Effect, 394
Asset Management Life Cycle, 463 Business Analysis Question Sets, 123
Asset Registry, 461 Business Blueprinting, 34-36
Asset Tracking, 464 Business Case, 31
Association Rule Tracking, 517 Business Engineering, 140-141
Attributes, 506 Business Intelligence, 519-520
Auction, 316 Business Intelligence Vendors, 520
Authorizations, 185 Business Modeling, 158
Activity Based Authorization, 185 Business Performance Management, 304
Role Based Authorization, 186 Business Plan, 351-352
Authorization Plan, 36 Business Process, 126
Available to Promise, 355, 401 Business Process Definition standards, 152-154
Business Process Hierarchy, 151-152
B2B Portal, 491 Business Process Modeling, 149
B2C Portal, 491 Business Process Modeling Standards, 154 – 155
Backflushing, 373-374 BPMN, 155
Backward Scheduling, 359-360 EPC, 155
Baseline Configuration, 172 UML, 155
Batch Determination, 452 Business Process Principles, 127
Batch Management, 372, 449 Business Process Workshops, 122
596 Index

CAD, 478 Core Team, 88, 93

Calibration, 449, 453 Corporate Performance Management, 304
Call Centre, 438 Costing, 299
Campaign Management, 440 CPFR, 395-396
Capable To Promise, 390, 401 CPFR-Nine Steps, 396
Capacity Planning, 363-364 CRM, 8
Case Managers, 137, 138 CRM Analytics, 441
Catalogue Management, 342-343 CRM Application Areas, 436
Catalogues, 453 CRM Benefits, 435
Centre of Excellence, 95 CRM Products, 441
Change Cycle, 247 Cross Docking, 327, 423-424
Change Management, 245 Cross Selling, 434, 438
Change Management During Project Lifecycle, 223-224 CSR, 480
Change Management Methodology, 224 Customer Community Portal, 491
Change Management Process Roles, 246 Customer Master, 405, 406
Change management Roles, 222-223 Customer Relationship Management, 276, 434
Change Team, 222 Customer Service, 414-415
Classification, 517 Customs Management, 411
Closed Loop MRP, 8, 9, 362-363 Cutover, 200
Cloud Computing, 528-530 Cut Over Planning, 39
Clustering, 517 Cycle Counting, 323
Coaches, 137
Collaboration Process Standards, 154 Dashboards, 519
Collaborative Forecasting, 386, 391 Data Cleaning, 510-511
Collaborative Planning Solutions, 391 Data Cleansing, 194,195, 196,197
Collaborative Product Development, 392 Data Extraction, 195
Collaborative Replenishment, 391-392 Data Loading, 195
Collection Management, 299 Data Loading Sequence, 196
Commodity Procurement, 316 Data Manager, 89, 91
Common Data Model, 503 Data Mapping, 194
Compensation Management, 285 Data Mart, 506
Competency Management, 288 Data Masking, 187
Condition Based Maintenance, 457 Data Masking Algorithms, 187
Condition Master, 407 Data Masking Tools, 188
Condition Monitoring, 457 Data Migration Challenges, 191
Configuration Document, 172 Data Migration Strategy, 37
Configuration, 37, 171 Data Mining, 516-518
Consensus Forecasting, 386 Data Mining Model, 517
Consistent Planning, 384-385 Data Mining Steps, 517-518
Consolidation, 300, 303 Data Mining Vendors, 518
Consumption Based Planning, 356-357 Data Modeling, 160
Contact Management, 437 Data Partitioning, 510
Content Management, 343, 495, 497-498 Data Preparation, 517
Contract, 312 Data Security, 185, 187
Central Contract, 312 Data Transformation, 195
Plant specific contract, 312 Data Warehousing, 503
Quantity Contract, 312 Data Warehousing Architecture, 508-509
Value Contract, 312 DCS, 103
Control Chart, 448 Demand Planning, 384-387
Core process, 224-225 Demand Planning in ERP and Supply Chain, 387
 Index 597

Demand Planning Tools, 386 ERP Package Market, 85

Department, 4 ERP Selection-Two step process, 75
Different Types of Authorization, 186 ETL, 511-512
Dimension Table, 504-505 ETL Tool, 197-198
Direct Costs of ERP Implementation, 56-58 Evaluated Receipt Settlement, 311-312
Distribution Requirement Planning, 365-366, 367 Evolution of SRM, 333
Document Management, 477, 495 Extended Team Member, 89, 93
Drill Up and Drill Down, 384
Face to Face Training, 212
E Business Portal, 491 Fact Table, 504-505
E Commerce, 438 Fast Forward Implementation, 51
E Marketing, 438 Field Service Applications, 437
E Marketplace Portal, 491 Final Configuration, 172
E Procurement, 316, 335-337 Final Preparation, 38
EAI Hub Model, 539 Financial Accounting, 301-302
EAM, 8 Financial Application Categories, 299
EAM Vendors, 465 Financial Modules, 300-301
EAM vs ERP-Difference, 465 Financial Supply Chain, 412-414
Early Watch, 261 Financial Supply Chain Management, 301, 302-303
ECR, 154 Forecasting Models, 385
EDI, 345 Forms of Supplier Collaboration, 344
EHS, 480 Forward Auction, 341
Electronic Kanban Card, 374 Function, 5
Electronic Shopping Cart, 337-338 Functional Specification, 37, 168-169
Electronic Signature, 450 Functional Testing, 174
Embargo Check, 411 Integration Testing, 174, 179
Emerging Trends, 17-18 Regression Testing, 174
Emnterprise Asset Management, 462-465 Unit Testing, 174
Employee (B2E) Portal, 491-492 User Acceptance Testing, 174
Employee Health Safety, 294
Employee Relationship Management, 290 Gap Development Options, 168
Employee Self Service, 290 Custom Developments, 168
End of Life Management, 477 Customizing, 168
End User Support, 246 Enhancements, 168
End User Training, 37 Modifications, 168
Enterprise, 3 Gap Document, 36, 166-167
Enterprise Application Functionalities, 275 Global Available To Promise, 389
Enterprise Application Integration (EAI), 539 Global Elements, 50
Enterprise Asset Management, 276 Global Rollout, 49
Enterprise Incentive Management, 286 Global Trade, 409-414
Enterprise Information Integration, 539-540 Global Trade Challenges, 413
Enterprise Marketing Management, 440 Go Live Audit, 39, 204
Enterprise Performance Management, 304 Go Live Checklist, 202
Enterprise Service Architecture, 531 Go Live Preparation, 201
Environmental Compliance, 481 Goods Receipt, 418-419
Equipment Master, 461 Granularity of Requirement, 120
ERP and Supply Chain Planning-Difference, 380-381 Gross Requirement Calculation, 358-359
ERP Challenges, 13-17
ERP II, 540-542 Harmonization / Consolidation, 49
ERP Life Cycle, 27 Hazardous Material Tracking, 480
598 Index

Hedging, 316 Local Elements, 50

Help Desk Support, 39 Logistics Execution, 417
Hosted ERP, 530-531 Long Term Planning, 366-368
Human Capital Analytics, 290 Lot Sizing Procedure, 359-360
Low Level Code, 357-358
Identity Management, 496 Loyalty Marketing, 440
Implementation Strategies, 51
Import and Export, 411-412 Maintenance Budgeting, 460
In House Implementation, 70 Maintenance Catalogue, 459
Indirect Costs of ERP Implementation, 58 Maintenance Master, 461
Industrial Hygeine and Safety, 294 Maintenance Planning and Scheduling, 458
Industry Process Standards, 154 Maintenance Task List, 460
Information Silo, 5 Management Accounting, 302
Inspection Method, 453 Manual Blocking, 311
Inspection Plan, 448 Manufacturer Part Management, 478-479
Integration Manager, 89, 91 Market Basket Analysis, 516-517
Integration Testing, 37 Marketing Planning, 440
Inventory Control, 321 Master Data for Production Planning, 368-372
Inventory Management Pyramid, 321 Bill Of Material, 369-371
Inventory Planning, 322, 324 Material Master, 369-370
Inventory Transactions, 322 Routing, 371, 373
Invoice Blocking, 311 Work Centre, 371-372
ISO 9000, 449 Master Data, 317
IT for Transport Mgmt, 430 Material Master, 317-318
IT for Warehouse Mgmt, 426 Service Master Record, 319
Terms and Conditions Master, 319
Kanban, 374 Vendor Master, 319
Kitting, 422 Master Inspection Characteristics, 453
Knowledge Management, 247, 498-499 Master Production Schedule, 352, 355
Knowledge Management Technologies, 499 Material Master, 406-407
Knowledge Management Tools, 258 Material Requirement Plan, 352, 355-362
Knowledge Portal, 492 Material Safety Data Sheet, 480-481
Knowledge Transfer, 40 Material Specification, 447, 453
KPI, 5 Measures for Warehouse Management, 426-427
KPI for Inventory Mgmt, 328 Measures of Transport Management, 431
KPIs for Procurement, 319 Measuring ERP Performance, 268
Measuring Points, 462
Labeling Management, 480-481 MES, 103
Labor Forecasting, 280 Methodology, 44
Lead Management, 437, 440 Miantenance Management, 456-462
Lean Inventory, 327 Miantenance Order Management, 459-460
Learning Management, 288-289 Migration, 49
Level 1 Helpdesk, 252-253 Min Max Model, 326
Level 2 Support, 253 Mobile Asset Management, 464
Level 3 Support, 253 Mobile Business, 537-539
Levels of Process Redesign, 138-139 Models of Training Delivery Method, 212-213
Levels of Support, 252 MOLAP, 515
Light Picking, 420 MRP, 8
LIMS, 450 MRP Exception Messages, 361
 Index 599

MRP for Service, 361-362 Partner Functions, 405-406

MRP II, 8, 9, 351 Partner Relationship Management, 439
MRP Limitations, 362 Partner Selection, 66
MRP Output, 361 Payment, 404
MRP Procedures, 357 Perfect Order, 407-409
MTBF, 461 Perfect Order Measures, 409
MTTR, 461 Performance Based Maintenance, 457
Multi Dimension Data Cube, 513, 515 Performance Management, 287
Multiple Dimensions of Process Models, 156 Performance Optimization, 261
Performance Testing, 175
Net Requirement Calculation, 358-359 Load Testing, 175
Network Design, 383-384 Stress Testing, 175
Network Security, 184 Permits, 462
New Product Development, 480 Personalization, 438, 496
Nine Levers, 98 Personnel Management, 289
Application Scope, 101 Phase Out, 386
Business Scope, 100 Phases in Configuration, 172
Data Migration Scope, 99, 104 Physical Inventory, 323
Interface Scope, 99, 102 Physical Supply Chain, 412-413
Location Scope, 99 Picking, 420
Process Scope, 100 PIMBOK, 97
Report Scope, 99, 103 Planning, 3
Technology Scope, 106 Planning Horizon, 357
User Scope, 105 PLC, 103
Notes Database, 259 PLM, 8
PLM and ERP-Differences, 474-475
Occupational Health, 295 PLM Business Drivers, 469-470
ODS, 507 PLM Functionalities, 475-477
Offshore, 72 PLM Value Proposition, 470-471
Offshore Testing, 180-181 PLM Vendors, 481-482
OLAP, 512-513 Point To Point Connection, 539
OLAP and OLTP-Difference, 515-516 Portal, 345, 489-499
OLTP, 512 Portal Benefits, 492-495
Ongoing KPI Management, 248 Portal Features, 495-496
Opeartional HR Processe, 294 Portal Types, 490
Operational Planning, 378-379 Portfolio Planning, 471
Optimum Maintenance, 458 POS, 103
Oracle HR Solution, 292 Pre Configured Template, 51
Oracle Siebel CRM, 443 Pre Implementation, 28, 30, 31
Order Management, 441 Predictive Miantenance, 457
Order Promising, 401 Predictive Modeling, 520
Organizational Change Management, 245 Preference Processing, 411
Organizational Design, 221-222 Preventive Maintenance, 457
Process, 5
P Model, 325 Process Centered Organization, 137, 138
P1, P2, P3 and P4 Issues, 254 Process Design vs TQM, 139-140
Package Screening Criteria, 77-81 Process Diagnosis, 134-135
Package Selection, 81-83 Process Industry, 372-373
Package Shortlisting, 81 Process Instruction (PI) Sheet, 373
600 Index

Process Modeling Maturity, 155-156 Q&A Dadabase, 46

Process Modeling Software, 156 QM during Procurement, 450-451
IDS Sheer ARIS, 157 QM in Production, 453
Visio, 157 QM in Sales and Service, 452
Process Owner, 89, 90 QM Master Data, 453
Process Redesign, 135 Quality Audit, 449
Process to Migrate Data, 192 Quality Certificate, 448, 451
Electronic Data Migration, 192-193 Quality Cost, 449
Manual Data Migration, 192-193 Quality Inspection, 451
Procurement Card, 339-340 Quality Mnaagement, 446-453
Procurement Cycle, 308 Quality Mnaual, 449
Procurement Maturity Model, 316-317 Quality Notification, 448
Product Classification, 411 Quote Arrangement, 313
Product Configuration, 441
Product Data Management, 475 Realization, 36-38
Product Lifecycle Management, 276, 468-482 Reasons for Success and Failure of BPR, 129
Product Lifecycle Phases, 471-472 Recruitment Cycle, 281
Product Safety, 477 Recruitment Management, 280
Product Track and Trace, 231 Reengineering Phase, 130
Profitable To Promise, 401 Reengineering Principles, 136-137
Project and Portfolio Management, 477, 479 Reengineering, 127
Project Charter, 113 Refurbishment, 460
Project Kickoff, 114 Reliability Centred Miantenance,
Project Plan, 107, 110 Reliability Engineering, 464
Project Preparation, 31, 33-35 Repetitive Manufacturing, 373-374
Project Risk Management, 115 Requirement Definition Document, 120
Periodic Risk Assessment, 117 Requirement Gathering Process, 122
Risk Assessment Tool, 116 Requirement Prioritization, 236
Risk Mgmt-Five Steps, 116 Revenue and Pricing Management, 440
Risk Worshop, 117 Resource, 3
Project Sponsor, 89, 90 Resource Plan, 108
Project Standards, 111 Reverse Auction, 341-342
Authorization, 112 Reverse Logistics, 421
Change Management , 111 RFID, 534-537
Communication , 111 RICEF, 167
Development Strategy, 112 Roadmap, 46
Documentation, 112 ROI Justification, 230
Issue Management , 111 ROLAP, 514, 515
Monitoring and Status Reporting, 112 Roll Up and Roll Down, 513
System Configuration, 112 Rollout, 51, 53
Testing, 112 Rough Cut Capacity Planning, 365
Project Vision and Mission, 114 Route Master, 407
Pros and Cons of BPR, 129 Route Optimization, 390
Prototyping, 138 Rule Based Availability, 390
Public Portal, 490 Rules for Process Modeling, 150
Public Sector Procurement, 316 Run SAP, 266
Purpose of Testing, 173-174
Putaway, 419 SaaS, 525-528
Safeguarding, 261
Q Model, 325 Sales and Distribution Master Data, 405
 Index 601

Sales and Operations Plan, 352, 353-354 Strategy to Handle Change, 219
Sales Force Automation, 436 Stress Testing, 38
Sales Order Cycle, 400 Succession Planning, 288
Sales Order Processing, 402 Supplier Collaboration, 343-344
Sampling Procedure, 448, 453 Demand Collaboration, 343
Sanctioned Party List Screening, 411 Inventory Collaboration, 344
SAP CRM, 442-443 Logistics Collaboration, 344
SAP HR Solution, 291 Payment Collaboration, 344
SAP Q&A DB, 123, 124 Supplier Community Portal, 491
SAP SRM, 346 Supplier Relationship Management, 276, 332
SCADA, 460 Supply Chain Management, 276
Scheduling Workforce, 437 Supply Chain Planning and Execution-Difference, 379-
SCM, 8 380
SCOR, 153-154 Supply Chain Planning Modules, 383
Scorecards, 519 Supply Network Planning, 387
Selection of Reengineering Process, 133 Support Activities, 244-245
Self Paced Learning, 213 Support Cycle, 241, 242
Sequence Optimization, 389 Hypercare, 241
Serial Number Tracking, 461 Steady State, 241, 244
Service Contract, 253 Support Planning, 241
Service Desk, 256-257 Transition, 241, 242-244
Service Desk Representative, 265 Upgrade, 241
Service Level Agreement (SLA), 253 Support Methodology, 266
Service Level Reporting, 255 Support Models, 262
Service Request Management, 258 In house Support, 262
Set Up Optimization, 389 Offshore Model, 263
Shadowing, 95 Onsite Model, 263
Shipping, 402-403 Onsite Offshore Model, 263
Simulation, 157, 388 Support Outsourcing, 263, 264
Simultaneous Planning, 388 Support Outsourcing-Pros and Cons, 264
Single Sign On, 496 Support Package, 259
SLA, 40 Support Phase, 39-40
Slice and Dice, 513-514 Support Roles, 265-266
Slotting, 419-420 Supporting Process, 226
Slotting Optimization, 420 System Access Security, 184-185
SME, 89
SOA, 531-533 Tactical Planning, 378-379
SOA Benefits, 533 Talent Management, 286-287
Solution Manager, 260, 261, 262 Targeted Marketing, 516
Source List, 313 Tax Planning, 300
SOX Compliance, 231 Taxonomy, 496
Spare Master, 461 Technical Specification, 37, 169-170
SRM, 8 Technologies for Supplier Collaboration, 345
SRM Vendor’s origin , 333-334 Technology Maturity, 80
Star Schema, 504-506 Test Case, 176
Statistical Process Control, 448, 453 Test Catalog, 176
Steering Committee, 89, 90 Test Management Steps, 177
Strategic Enterprise Management, 304 Test Object, 176
Strategic HR Processe, 293 Test Package, 176
Strategic Planning, 378-379 Test Plan, 37, 176
602 Index

Test Report, 176 Functionality Gaps, 164

Test Status, 176 Interface Gaps, 165
Test Strategy, 37 Report Gaps, 166
Testing Approaches, 175 User Experience Gaps, 166
Automated Testing, 176, 179 Types of Requirement, 121
Manual Testing, 176 Business Requirement, 121
Testing at different Phases, 175 Functional Requirement, 121
Testing, 173 Legal Requirement, 121
Three Way Matching, 311
Miantainability Requirement, 121
Date Variance, 311
User Requirement, 121
Price Variance, 311
Types of Security, 184
Quantity Variance, 311
Time Based Maintenance, 457 Types of Testing, 174
Time Fence, 361 Types of Upgrade, 250
TO BE Modeling, 151 Functional Upgarde, 251
TO BE Process, 36 Technical Upgrade, 250
Traceability, 449
Track and Trace, 426 Unit Testing, 37
Trade Promotion, 441 Unstructured Information, 497-498
Training Content, 209, 213 Up Selling, 434, 438
Training Delivery, 212 Upgrade, 40
Training Environment, 209, 211 Upgrade-Advantages and Disadvantages, 249-250
Training Evaluation, 214 Upgrade Phase, 248
Training Objectives, 207 User Acceptance Testing, 38
Training Roles, 214-215
Training Strategy, 208 VA, NVA and Waste, 136
Transition Activities, 243 Value Added Services, 422
Human Resource Transition, 243 Vendor Evaluation, 451
Issue Transition, 244 Vendor Managed Inventory, 392-395
Knowledge Transition, 243 Vertical Compression, 137
Project Documentation Transition, 243 Vertical Portal, 491
Transport Constraints, 391 VICS, 154, 395
Transport Management, 427-431 Visualization, 475, 479
Transport Planning and Optimization, 390
Voice Picking, 421
Transportation Cycle, 428-429
Volume Testing, 38
Treasury, 300, 303
Truck Load Building, 390
Warehouse Functions, 418
Two Bin Model, 326
Warehouse Process Maturity Model, 425
Types of Benchmarking, 142
Warranty, 414, 460
Financial, 142
Functional, 142 Wave Picking, 420
Performance, 142 Work Permits, 460
Process, 142 Workforce Planning, 280
Product, 142 Workforce Scheduling, 283-284
Types of Gaps, 163
Conversion Gaps, 166 Zone Picking, 420