SAP Implementation in

TISCO (Tata Iron and Steel Company)

Page | 1

About TISCO : Established in 1907, Tata Steel is among the top ten global steel companies with an annual crude steel capacity of over 28 million tons per annum (MTPA). It is now one of the world's most geographically-diversified steel producers, with operations in 26 countries and a commercial presence in over 50 countries.

The Tata Steel Group, with a turnover of US$ 22.8 billion in FY '10, has over 80,000 employees across five continents and is a Fortune 500 company.

Tata Steel’s vision is to be the world’s steel industry benchmark through the excellence of its people, its innovative approach and overall conduct. Underpinning this vision is a performance culture committed to aspiration targets, safety and social responsibility, continuous improvement, openness and transparency.

  Tata Steel’s larger production facilities include those in India, the UK, the Netherlands, Thailand, Singapore, China and Australia.  Operating companies within the Group include Tata Steel Limited (India), Tata Steel Europe Limited (formerly Corus), NatSteel, and Tata Steel Thailand (formerly Millennium Steel).

Page | 2

SAP R/3SAP R/3 is the former name of the main ERP (Enterprise Resource Planning) produced by SAP AG. It is an enterprise-wide information system designed to coordinate all the resources, information, and activities needed to complete business processes such as order fulfillment or billing.

History of SAP R/3

The first version of SAP's flagship enterprise software was a financial Accounting system named R/1 called as YSR. This was replaced by R/2 at the end of the 1970s. SAP R/2 was in a mainframe based business application software suite that was very successful in the 1980s and early 1990s. It was particularly popular with large multinational European companies who required soft-real-time business applications, with multi-currency and multi-language capabilities built in. With the advent of distributed client–server computing SAP AG brought out a client–server version of the software called SAP R/3 (The "R" was for "Real-time data processing" and 3 was for 3-tier). This new architecture is compatible with multiple platforms and operating systems, such as Microsoft Windows or UNIX. This opened up SAP to a whole new customer base.

SAP R/3 was officially launched on 6 July 1992. It was renamed SAP ERP and later again renamed ECC (ERP Central Component). SAP came to dominate the large business applications market over the next 10 years. SAP ECC 5.0 ERP is the successor of SAP R/3 4.70. The newest version of the suite is SAP ERP 6.0 – the path to SAP Business Suite 7

Releases

SAP R/3 Release 1.0A Release Date 6 July 1992 SAP R/3 Release 2.0 / 2.1 Released 1993 SAP R/3 Release 3.0 / 3.1 Released 1995 SAP R/3 Release 4.0B Release Date June 1998 SAP R/3 Release 4.5B Release Date March 1999 SAP R/3 Release 4.6A Release Date 1999 SAP R/3 Release 4.6B Release Date Dec 1999 SAP R/3 Release 4.6C Release Date April 2001 SAP R/3 Enterprise Release 4.70 Release Date March- Dec 2003 SAP R/3 Enterprise Edition 4.7

Page | 3

SAP R/3 Enterprise Central Component 5.0 SAP R/3 Enterprise Central Component 6.0

Organization

SAP R/3 was arranged into distinct functional modules, covering the typical functions in place in an organization. The most widely used modules were:

Finance/Accounting

General ledger, payables, cash management, fixed assets, receivables, budgeting, consolidation.

Human Resources 

Payroll, training, benefits, 401K, recruiting, diversity management

Manufacturing 

Engineering, bill of materials, work orders, scheduling, capacity, workflow management, quality control, cost management, manufacturing process, manufacturing projects, manufacturing flow, activity based costing, product lifecycle management

Supply chain management 

Order to cash, inventory, order entry, purchasing, product configurator, supply chain planning, supplier scheduling, inspection of goods, claim processing, commissions

Project management Costing, billing, time and expense, performance units, activity management

Customer relationship management Sales and marketing, commissions, service, customer contact, call center support

Data services. Various "self–service" interfaces for customers, suppliers and/or employees

Access control Management of user privileges for various processes.

Page | 4

Each module handled specific business tasks on its own, but was linked to the others where applicable. For instance, an invoice from the billing transaction of Sales & Distribution would pass through to accounting, where it will appear in accounts receivable and cost of goods sold.

SAP typically focused on best practice methodologies for driving its software processes, but more recently expanded into vertical markets. In these situations, SAP produced specialized modules (referred to as IS or Industry Specific) geared toward a particular market segment, such as utilities or retail.

Technology

SAP based the architecture of R/3 on a three-tier client/server

1. Application Server2. Database Server3. Security

Page | 5

SAP allows the IT supported processing of a multitude of tasks, accruing in a typical company or bank. SAP ERP is differing from R/3 mainly because it is based on SAP NetWeaver: core components can be implemented in ABAP and in Java and new functional areas are mostly no longer created as part of the previous ERP system, with closely interconnected constituents, but as self-contained components or even systems.

Application Server

An application server is a collection of executable s that collectively interpret the ABAP/4 (Advanced Business Application Programming / 4th Generation) programs and manage the input and output for them. When an application server is started, these executables all start at the same time. When an application server is stopped, they all shut down together. The number of processes that start up when you bring up the application server is defined in a single configuration file called the application server profile. Each application server has a profile that specifies its characteristics when it starts up and while it is running. For example, an application server profile specifies:

Number of processes and their types Amount of memory each process may use Length of time a user is inactive before being automatically logged off.

The Application layer consists of one or more application servers and a message server. Each application server contains a set of services used to run the R/3 system. Not practical, only one application server is needed to run an R/3 system. But in practice, the services are distributed across more than one application server. This means that not all application servers will provide the full range of services. The message server is responsible for communication between the application servers. It passes requests from one application server to another within the system. It also contains information about application server groups and the current load balancing within them. It uses this information to choose an appropriate server when a user logs onto the system.

The application server exists to interpret ABAP/4 programs, and they only run there-the programs do not run on the presentation server. An ABAP/4 program can start an executable on the presentation server, but an ABAP/4 program cannot execute there. If your ABAP/4 program requests information from the database, the application server will format the request and send it to the database server.cvb.

Page | 6

Database Server

The database server handles the user's request for addition, retrieval and modifications in the data. Most of the organization uses ORACLE for Database. Database Server handles all the Master Database in SAP.

Security

Server-to-server communications can be encrypted with the SAP cryptographic library.

However, the SAP cryptographic library does not cover client-to-server encrypted communications; an external technology covering Secure Network Communications and Secure Socket Layer would have to be provided.

Applications of SAP

SAP's scope usually implies significant changes to staff work processes and practices. Generally, three types of services are available to help implement such changes—consulting, customization, and support. Implementation time depends on business size, number of modules, customization, the scope of process changes, and the readiness of the customer to take ownership for the project. Modular SAP systems can be implemented in stages. The typical project for a large entSAPrise consumes about 14 months and requires around 150 consultants. Small projects can require months; multinational and other large implementations can take years. Customization can substantially increase implementation times.

Process preparation

Implementing SAP typically requires changing existing business processes. Poor understanding of needed process changes prior to starting implementation is a main reason for project failure. It is therefore crucial that organizations thoroughly analyze business processes before implementation. This analysis can identify opportunities for process modernization. It also enables an assessment of the alignment of current processes with those provided by the SAP system. Research indicates that the risk of business process mismatch is decreased by:

linking current processes to the organization's strategy; analyzing the effectiveness of each process; understanding existing automated solutions.

Page | 7

SAP implementation is considerably more difficult (and politically charged) in decentralized organizations, because they often have different processes, business rules, data semantics,

authorization hierarchies and decision centers. This may require migrating some business units before others, delaying implementation to work through the necessary changes for each unit, possibly reducing integration (e.g. linking via Master data management) or customizing the system to meet specific needs.

A potential disadvantage is that adopting "standard" processes can lead to a loss of competitive advantage. While this has happened, losses in one area often offset by gains in other areas, increasing overall competitive advantage.

Configuration

Configuring an SAP system is largely a matter of balancing the way the customer wants the system to work with the way it was designed to work. SAP systems typically build many changeable parameters that modify system operation. For example, an organization can select the type of inventory accounting— FIFO or LIFO—to employ, whether to recognize revenue by geographical unit, product line, or distribution channel and whether to pay for shipping costs when a customer returns a purchase.

Customization

SAP systems are theoretically based on industry best practices and are intended to be deployed "as is". SAP vendors do offer customers configuration options that allow organizations to incorporate their own business rules but there are often functionality gaps remaining even after the configuration is complete. SAP customers have several options to reconcile functionality gaps, each with their own pros/cons. Technical solutions include rewriting part of the delivered functionality, writing a homegrown bolt-on/add-on module within the SAP system, or interfacing to an external system. All three of these options are varying degrees of system customization, with the first being the most invasive and costly to maintain. Alternatively, there are non-technical options such as changing business practices and/or organizational policies to better match the delivered SAP functionality.

Key differences between customization and configuration include:

Customization is always optional, whereas the software must always be configured before use (e.g., setting up cost/profit center structures, organisational trees, purchase approval rules, etc.)

Page | 8

The software was designed to handle various configurations, and behaves predictably in any allowed configuration.

The effect of configuration changes on system behavior and performance is predictable and is the responsibility of the SAP vendor. The effect of customization is less predictable, is the customer's responsibility and increases testing activities.

Configuration changes survive upgrades to new software versions. Some customizations (e.g. code that uses pre–defined "hooks" that are called before/after displaying data screens) survive upgrades, though they require retesting. Other customizations (e.g. those involving changes to fundamental data structures) are overwritten during upgrades and must be reimplemented .

Customization Advantages:

Improves user acceptance. Offers the potential to obtain competitive advantage vis-à-vis companies using only

standard features.

Customization Disadvantages:

Increases time and resources required to both implement and maintain . Inhibits seamless communication between suppliers and customers who use the

same SAP system uncustomized.

Extensions

SAP systems can be extended with third–party software. SAP vendors typically provide access to data and functionality through published interfaces. Extensions offer features such as:

archiving, reporting and republishing; capturing transactional data, e.g. using scanners, tills or RFID. access to specialized data/capabilities, such as syndicated marketing data and

associated trend analytics.

Data migration

Data migration is the process of moving/copying and restructuring data from an existing system to the SAP system. Migration is critical to implementation success and requires significant planning. Unfortunately, since migration is one of the final activities before the

Page | 9

production phase, it often receives insufficient attention. The following steps can structure migration planning:

Identify the data to be migrated Determine migration timing Generate the data templates Freeze the toolset Decide on migration-related setups Define data archiving policies and procedures.

The 'Top' Program

In the early 1990s, TISCO appointed McKinsey and Booz-Allen & Hamilton to study its operations and suggest ways to cut costs. Irani explained the rationale, "Cost-cutting measures are more important in the present situation where one can no longer control steel prices which are dictated by international markets." The consultants suggested TISCO to focus on various components affecting the cost of steel, which included cost of raw materials, cost of conversion, fuel rate in the blast furnace and mining of coal. TISCO was advised to use the most modern technologies to cut costs further.

In the second half of 1998, in association with McKinsey, TISCO implemented TOP program at its G blast furnace. TOP was widely regarded, as a program, which would have a maximum positive impact to the bottomline, with minimum investment, required in minimum time (See Exhibit IV). It aimed achieving large improvements in throughput, quality and cost in the short term. In the long run, TOP was expected to enable the TISCO to achieve high rates of performance improvement.

Since TISCO's scale of operations was quite large, the whole organization was divided into manageable 'units' to facilitate the implementation of TOP. A unit team was formed comprising a unit leader and two facilitators. Initially, McKinsey provided the facilitators. The unit leader was responsible for the performance of that particular unit. The team worked full time on the TOP program for a period of 12 weeks. Around eight units were addressed simultaneously during the 12 weeks, and this was also known as 'Wave.' The entire Wave was divided into five phases.

The unit team's objective was to explore ideas to reduce the cost or delays made by the unit by about 40%. In the process, the team was expected to identify and understand how each cost element could be reduced. The team had to establish relationships between key

Page | 10

performance indicators and the elements that had an impact on them. Each team was asked to set itself a target based on the TOP norms; develop ideas to improve from the present level of performance to the target level; and implement those ideas.

The Phase I of a Wave was two weeks long. During this phase, the cost base was examined and the items that had a maximum impact on the bottomline were identified. Individual components of the larger cost elements were identified by drawing cost trees. The cost elements, which could be reduced were highlighted and the reduction targets were set. In the Phase II of the Wave, ideas were explored to reach the set targets. At the G blast furnace, throughput and fuel costs were identified as the key performance indicators in the Phase II. Among the different individual components of fuel costs, coke and coal were the largest cost elements. They accounted for about 50% of the total costs. A reduction target was set to bring costs down to 570 kgs per thm from 610 kgs per thm. In the Phase III of the Wave, ideas were generated to achieve the target output of 3800 tons per day. Considering the techno-economic feasibility, 36 ideas were short-listed. The ideas were then grouped based on the capital expenditure required for implementing each idea. The Phase IV of the Wave started with the implementation of these ideas. Simultaneously, the G blast furnace also implemented 185 ideas, which did not require any capital investment.

By March 1999, the G blast furnace achieved a savings of Rs 87 million against the targeted savings of Rs 40 million. TISCO set up a potential savings target for its G blast furnace at about Rs 300 million per annum, accounting for more than 10% of its profits in the fiscal 1999. By late 1999, TOP was in Phase V of the Wave

In 2000, similar Waves were also adopted in TISCO's shop floors. The TOP program had helped TISCO to shift its focus from just producing volumes to costs and quality. Moreover, TOP enabled TISCO to improve customer satisfaction and loyalty.

Implementing Best Practices

In 1999-2001, TISCO took measures to reduce costs further by adopting innovative strategies and other cost-cutting exercises. For example, TISCO stopped using manganese, an expensive metal used to increase the strength and flexibility of steel. The company made efforts to reduce its product delivery time from 3-4 weeks in 1998 to 2 weeks in 2000. The company aimed to further reduce the time to one week.

Page | 11

TISCO also took steps to reduce its manpower costs. Between 1996 and 2000, TISCO reduced its workforce from 78,000 to 40,000 employees. Analysts opined that cutting its workforce by 38,000 employees was not an easy job and the company was able to do it with a lot of communication with employees.

TISCO had adopted Performance Ethic Programme (PEP), under which, it planned to promote hardworking young people to higher positions depending on their performance, rather than following the convention of seniority. This exercise was expected to cut the management staff from 4000 to 3000.

PEP had two core elements. Firstly, it proposed a new organizational structure, which was expected to foster growth businesses, introduce more decision-making flexibility, clear accountability, and encourage teamwork among the managers and the workforce. Secondly, PEP proposed to introduce a Performance Management System (PMS). It would identify and reward strong performers, and also offer development opportunities for each employee. PMS would also ensure that every employee's job profile was clearly defined. By introducing PMS, TISCO wanted to make performance appraisals transparent and fair and reward the good performers. The company also planned to introduce a new compensation package based on performance from November 2001. Muthuraman explained the benefits of PEP, "Youngsters are getting higher salary than some of the seniors, and after the restructuring, the average age of the managers has fallen by 10 years. Through PEP, TISCO also reduced the hierarchical levels from 13 to 5."

In a bid to reduce costs further, TISCO used IT as a strategic tool. In 1999, the company formed a small cross-functional in-house team consisting of consultants from Arthur D Little and IBM Global Services. The team was responsible for re-designing two core business processes - order generation and fulfillment and marketing development. The program began with a study on cost-competitiveness. The aim of the program was to enhance customer focus enabling better credit control and reduction of stocks, thereby reducing the costs. After considering several packages, the team decided to use SAP R/3. TISCO wanted the team - also known as ASSET (Achieve Success through SAP Enabled Transformation) - to integrate SAP into the existing information system and make it compatible with future SAP implementations. After SAP solutions were introduced in TISCO, the business processes became more efficient. It also improved customer service and productivity, and reduced costs. The introduction of SAP also decreased manpower cost from more than US $ 200 per ton in 1998 to about US $ 140 per ton in 2000. There was a significant reduction in inventory the carrying cost, from Rs 190 per ton in 1999 to Rs 155 per ton by 2000. There were also significant cost savings through efficient management of resources.

The Future (After SAP R/3 Implementation)

Page | 12

Analysts felt that TISCO's modernization program was very successful. The Steel Authority of India Ltd. (SAIL) adopted a similar program with an investment of Rs 70 billion. However, the program was not successful. In contrast, in spite of the depressed market and lower margins, the decrease in the production costs enabled TISCO to achieve a profit after tax of Rs 5.53 billion in 2000-2001, and Rs 4.22 billion in 1999-2000 compared to Rs 2.82 billion during 1998-99

TISCO planned to enter new areas including setting up of a 0.1 million-ton ferro chrome export oriented project. The project was planned in Australia because of the lower power costs. TISCO was to get power at a tariff of 1.8 cents for about 15 years that is about one-fifth of the tariffs in India. Power accounted for 60% of the cost of ferro chrome manufacturing.

TISCO was also planning to enter titanium mining through alliances with major global companies. To provide employment to the employees opting for VRS at over-manned units, TISCO planned to enter the call center business in Jamshedpur. To develop this business, TISCO entered into a marketing alliance with Tata International, the trading arm of Tata Group. TISCO also planned to exit from some of its non-core activities.

Critics felt that TISCO might face problems due to the decrease in demand for steel in the global and local markets and increasing competition from cheap imports, and anti-dumping duties imposed on the domestic steel manufacturers by the US. They felt that it was doubtful whether steel, even at the lowest cost, would deliver returns higher than the cost of capital in India. However, some analysts remarked that in the long run, TISCO's strategy to export to Jordan, Iraq and the Southeast Asian countries might reduce dependence on the US markets thus helping the company. They said that its entry into value-added products was expected to safeguard the company from the fluctuations in the steel prices.

Page | 13

SCREENSHOTS

Page | 14

Page | 15

Page | 16

Page | 17

Page | 18

Page | 19

References:

www.icmrindia.org www.google.com en.wikipedia.org www.tatasteel.com www.tatasteelindia.com www.sap.com

Page | 20