BUSINESS BLUEPRINT FOR MYSAP CRM IMPLEMENTATION @EXIDE –AN INTRODUCTION...5
INTRODUCTION...5
GOALOFTHE BLUEPRINT...5
STRUCTURE...5 OTHER DOCUMENTS...5 1.0 MASTER DATA...6 1.1 BUSINESS PARTNER...6 1.2 ORGANIZATIONAL MANAGEMENT...12 1.3 TERRITORY MANAGEMENT...16 1.4 PRODUCT MASTER...17 1.5 PRICEMASTER...20
1.6 MASTER DATA MANAGEMENT...23
2.0 SERVICE FUNCTIONAL SCENARIOS –FUNCTIONAL SCOPE...25
2.1 INSTALLED BASE...25
2.2 COMPLAINT & WARRANTY...27
2.2.1 FMIB: Complaint handling...28
2.2.2 Railway Complaint...34
2.2.3 Solar complaint handling...34
2.2.5 Catalogs, Code Groups and Codes...35
2.2.6 Reason for Rejection...37
2.2.7 Integration with R/3...38
2.2.8 Warranty...40
2.3 SERVICE PROCESS...44
2.3.1 Service Quotation...44
2.3.2 Service Contract or Annual Maintenance Contract (AMC):...44
2.3.3 Planned services...49
2.4 SERVICE ORDERS...54
2.4.1Installation & Commissioning...55
2.4.2 Repair & Rectification...56
2.4.3 Overhauling of the battery bank...57
2.4.4 Initial Filling & Charging...59
2.5 SERVICE CONFIRMATION...59
2.5.1Service Invoicing and costs in CRM...62
2.6 ASP EVALUATION ACTIVITY...62
2.7 CASE MANAGEMENT...63
2.7.1 8D/Case Management...63
2.8 SOLUTION DATABASE...66
2.9 SERVICE ANALYTICS...67
3.0 SALES FUNCTIONAL SCENARIOS –FUNCTIONAL SCOPE...70
3.1 ACTIVITY MANAGEMENT...70
3.2 OPPORTUNITY MANAGEMENT:...72
3.2.1 Infrastructure - Power & Projects: New Projects...73
3.2.2 Infrastructure - Power & Projects: Replacement...75
3.2.3 Telecom: Supply to Government Customers/ Service Providers (BSNL, MTNL and DOT) through Switch Manufacturers like Nokia, Ericsson...76
3.2.5 Telecom: Supply To Private Service Providers (Tata Tele services, Reliance) through Switch
Manufacturers e.g. Motorola...79
3.2.6 Traction: Replacement – Traction Trade...79
3.2.7 Traction: Replacement – OEM...80
3.2.8 FMIB – Existing UPS OEM...82
3.2.9 FMIB – Existing Dealer...84
3.2.10 FMIB – New Dealer...84
3.2.11 FMIB – New OEM...84
3.2.12 Defence...85
3.2.13 Caplamps...85
3.2.14 Exports: CBSEA: For Cells...86
3.2.15 Exports: CBSEA: Battery Bank...86
3.2.16 Exports: CBSEA: for specific requirement...86
3.2.17 Exports: ESPEX...87
3.2.18 Non-CBSEA/ESPEX: For Cells...87
3.2.19 Non-CBSEA/ESPEX: Battery Bank...87
3.2.20 Non-CBSEA/ESPEX: specific requirement...88
3.3 QUOTATION MANAGEMENT...88
3.3.1 Infrastructure - Power & Projects: New Projects...88
3.3.2 Infrastructure - Power & Projects: Replacement...90
3.3.3 Infrastructure – Railways – Direct Supply...91
3.3.4 Railways: Supply through Contractors and Integrated Power Supply (IPS)...91
3.3.5 Telecom: Direct Supply To Government Customers (BSNL, MTNL, DOT)...92
3.3.6 Telecom: Supply to Government Customers/Service Providers (BSNL, MTNL, DOT) through Switch Manufacturer like Nokia, Ericsson etc...92
3.3.7 Supply To Private Service Providers (Airtel, Hutch, Reliance)...93
3.3.8 Supply To Private Service Providers (Tata Teleservices, Reliance) through Switch Manufacturers (Motorola)...95
Same as Telecom: Supply To Government Customers/Service Providers (BSNL, MTNL, DOT) through Switch Manufacturer like Nokia, Ericsson etc...95
3.3.9 Solar...95
3.3.10 Traction: Replacement (Traction Trade)...95
3.3.11 FMIB: Existing OEM/New OEM/Existing Dealer/New Dealer/NIC/DGS&D...96
3.3.12 Defence...96
3.3.13 CAPLAMPS...96
3.3.14 Exports: CBSEA: For Cells...97
3.3.15 Exports: CBSEA: Battery Bank...97
3.3.16 Exports: CBSEA: for specific requirement...98
3.3.17 Exports: ESPEX...98
3.3.18 Exports: Non-CBSEA/ESPEX: For Cells...98
3.3.19 Exports: Non-CBSEA/ESPEX: For Battery Banks...99
3.3.20 Non-CBSEA/ESPEX: For Specific Requirement...99
3.4 SALES ORDER...99
3.4.1 Infrastructure - Power & Projects: New Projects...100
3.4.2 Infrastructure - Power & Projects: Replacement...101
3.4.3 Infrastructure – Railways – Direct Supply...102
3.4.4 Railways: Supply through Contractors and Integrated Power Supply (IPS)...104
3.4.5 Telecom: Direct Supply to Government Customers (BSNL, MTNL, DOT)...104
3.4.6 Telecom: Supply to Government Customers/ Service Providers (BSNL, MTNL, DOT) through Switch Manufacturers like Nokia, Ericsson etc...106
3.4.8 Supply to Private Service Providers (Tata Teleservices, Reliance) through Switch Manufacturers
(Motorola)...109
Same as Telecom: Supply to Government Customers/ Service Providers (BSNL, MTNL, DOT) through Switch Manufacturers like Nokia, Ericsson etc...109
3.4.9 Solar...109
3.4.10 Traction: Replacement (Traction Trade)...110
3.4.11 Traction: OEM...111
3.4.12 FMIB - Existing OEM...112
3.4.14 FMIB – New OEM...113
3.4.15 FMIB Existing Dealer...114
3.4.16 FMIB New Dealer...115
3.4.17 Defence...116
3.4.18 CAPLAMPS...116
3.4.19 Exports: CBSEA: For Cells...116
3.4.20 Exports: CBSEA: Battery Bank...118
3.4.21 Exports: CBSEA: For Specific Requirement...119
3.4.22 Exports: ESPEX...121
3.4.23 Exports: Non CBSEA/ESPEX For Cells...122
3.4.24 Exports: Non CBSEA/ESPEX For Battery Bank...124
3.4.25 Exports: Non CBSEA/ESPEX For Specific Requirement...125
3.5 SALES PLANNING...128
Purpose...128
3.5.1 Telecom, Power & Project, Traction, FMIB-OEM...129
3.5.2 FMIB Trade...130
4. MARKETING FUNCTIONAL SCENARIOS –FUNCTIONAL SCOPE...131
4.1 BUDGETING & MARKETING PLANNING...131
4.2 CAMPAIGN PREPARATION...134
4.2.1 Segmentation...134
4.2.2 Maintain Attributes and Attribute Sets...138
4.2.3 Target Group creation...138
4.2.4 Creating Campaigns and Campaigns Elements...138
4.2.5 Communication Channel...140
4.2.6 Personalized Mail Form...141
4.2.7 Content Management Templates...141
4.3 CAMPAIGN EXECUTION...142
4.4 MARKETING CALENDAR...143
4.5 EXTERNAL LIST MANAGEMENT...143
4.6 PRODUCT PROPOSAL...144
4.7 LEAD MANAGEMENT...145
4.7.1 Surveys...148
4.8 ACTIVITY MANAGEMENT...149
4.8.1 Standard Activities...150
4.8.2 New Product Development Activity...151
4.8.3 New Product Proposal Activity...153
5.0 REPORTS...155
5.1 SALES...156
5.2 SERVICE...156
5.3 MARKETING...156
5.3.2 Lead analysis...156
6.0 LIST OF INTERFACES & DEVELOPMENT...158
6.1 DEVELOPMENTS –SALES...158 6.2 DEVELOPMENT –SERVICE...158 6.3 ENHANCEMENTS...159 6.4 INTERFACES – SALES...159 6.5 INTERFACES- SERVICE...159 7.0 ADDENDUM...160
Document Management
Name Date Signature
Prepared
By Rakesh KumarAshok Mohanty Syed Aleem Reviewed By Saurabh Dutta Kannan Iyer Jahar Sengupta 27/10/2005 Approved By Rakesh Bhatia 31/10/2005 Version Management
Version No. Changes in Document Date Changed Changed By
Business Blueprint for mySAP CRM Implementation @EXIDE –An Introduction
Introduction
Goal of the Blueprint
This document is the result of various Brown Paper Workshops prepared during Phase I of my SAP CRM Implementation for Exide Batteries, Kolkata by SAP Consulting team. Its goal is to describe the way in which SAP CRM system will support various Sales, Service & Marketing Processes within Exide. This Business Blueprint will be basis for all Customizations and Developments to be done in the Implementation phase.
Structure
This Blueprint document consists of this introduction chapter, a process overview of Sales, Service & Marketing processes and several chapters that detail the processes that are in scope of this project, as well as separate chapters on Master data, reporting and Legacy data conversion. The process chapters contain:
Process description
Description of how the process will be supported by SAP Integration issues with other processes/systems
No. Ranges
Document Types
Internal/External Integrations Inter modular integration issues
Programming issues
Any new field to be created
Any new forms
Any uploading programs
Validations Other Documents
This Blueprint document is based on:
Brown Paper Workshop Summary Document
1.0 Master Data 1.1 Business Partner
Business partners are at the center of the business transaction, and thus center of the business interest. All relevant information about a business must therefore be available in a consolidated form. The customer therefore needs to have a central and comprehensive view of the customer. A business partner can only be created once, regardless of transactions in which it is being used. For example if a company is both a prospect and a customer, the data has to be maintained once. However a business partner can figure in a company in other ways. Depending on the business process in which a business partner participates, the information required about the business partner may vary considerably. For example the business partner participating in delivery process has a different set of data and business partner participating in sales process has a different set of data. A business partner can be in contact with another business partner. These are relationships in CRM and they can be very different in nature. So the business partner concept in CRM is broad as compared to R/3. The business partners in CRM are as per their roles where as there is no concept of roles in R/3. In CRM system, the business partner can be a customer (sold-to party, ship-to party) or Prospect or suspect or employee or contractor or Inspector or coach etc. The role-based concept of CRM allows a business partner’s data to be maintained independently. For example the business partner role employee has a different set of data where as the business partner role prospect has a different set of data.
Additional Business Partner Roles for Exide CRM
Dealer Sub Dealer OEM End User Institution Consultant Specification Provider Inspection Agency Test Laboratory
Govt. Regulatory Body Charger Manufacturer System Integrator Agent
Switch Manufacturer EPC Contractor
Fork Lift Manufacturer Zonal Railways
Manufacturing Unit (Rly.) Depot
Nodal Agency
Exide Business Partner CBSEA Business Partner ESPEX Business Partner Sold To Party
Ship To Party Bill To Party Payer
Employees
Individual End Users
Institutional Contact Person Facilitators Competitors Industry Sector Government Private Overseas Individual Persons Industry segment Power Fertilizer Steel Aluminium Education Cement Mine
Oil & Natural Gas Info tech Telecom Petroleum Aviation Bank Insurance Hotel Others
SAP R/3 and SAP CRM have contrasting data models: The business partner concept in CRM is more flexible than the customer master in SAP R/3. SAP R/3 and SAP CRM have different, independent concepts regarding number range assignment, data display, and data usage.
For this reason, you cannot use the business partner role and business partner grouping for mapping to account groups. To map to account groups, you use the classification.
Business Partner data:
Business Partner data is used in many business transactions. The system proposes business partner master data in the appropriate fields when, for example, you create a sales order in my SAP CRM. A business partner can be created in the CRM enterprise from many sources as below:
Following methods will be adopted for business partner creation.
Initial load from R/3: Business partner data can be imported into the CRM enterprise system from R/3 system using middleware functionality of CRM.
People-Centric CRM: If the role has the Account and Contact Management work set, then the user could maintain a business partner. For example, the Sales Representative role allows the sales representative to maintain his customer accounts. The Sales representative uses the Portal to access the account and maintain the changes. When saved, the account information is transferred to the CRM enterprise.
My SAP CRM Interaction Center: With the Win client Contact Center, an agent can create or change the account information. This data is transferred to the CRM enterprise.
BP Maintenance in CRM Online: The user can create or change the business partner directly through the CRM enterprise through a transaction.
SAP BW (Leads): This allows you to import lists into SAP BW that you can then transfer into the CRM system using the Segment Builder.
External List Management (Marketing): This scenario requires that addresses rented from address providers be deleted from the system after a certain number of contacts or after a certain period if no positive reaction is elicited from the business partner. A positive reaction can be defined as a positive inbound contact. The number of permitted contacts or the period in which the addresses can be used is defined in the contract conditions of the address provider. The logging of all
interactions in External List Management with the rented business partners makes it possible for all participants to view at any time whether an address can be added to the customer master data of the company or whether it must be deleted because the agreed period has elapsed (or because the maximum number of contacts have been made).
Other sources of Business partner master data creation: In Exide scenario, this will not be used.
Internet Self-Registration through Web Portal: With the E-Commerce function (Exide’s Web Portal), a consumer can register himself. The business partner created from the portal will be uploaded to the CRM system through batch upload.
The SAP business partner allows the standardized maintenance of business partners across components.
Application-neutral data, such as name, address, bank details, and payment cards, is mapped. In doing this, the particular requirements for mapping organizations, groups and persons are taken into consideration.
A business partner can be a person, a group of people, or an organization, representing a business interest.
The categorization of a business partner as a person (for example, a private person), a group or an organization (legal person or part of a legal person, for example, department) is known as the business partner category.
The organization represents units such as a company, a division of a company, a club, or an association.
In addition to a legal person, parts of a legal person can be mapped as a business partner. Organization acts as an umbrella term to depict all conceivable occurrences in daily business activities. In this way, a subsidiary or a purchasing department represents only parts of a legal person.
A business partner grouping classifies business partners according to user-defined criteria. The Customizing transaction appears as follows:
Definition of number ranges for business partners
Definition of groupings for business partners and assignment of number ranges When creating a business partner, internal number assignment is the default. Alternatively if you want to use external number assignment, you must choose the relevant grouping and enter the external number.
A business partner can come into contact with an enterprise in various situations. Depending on which business processes the business partner is involved in; completely different information about the business partner may be needed. For example, for the goods delivery transaction, information about the shipping and delivery conditions is required; for the sales order transaction, delivery dates and payment conditions are relevant.
More than one business partner role for one business partner can be created; general information, such as name, address, and bank details, must be entered only once.
Each partner role contains various data sets: General data
CRM-specific data Relationships
A business partner relationship forms a business-relevant connection between two business partners.
Defining screen layout and screen sequences in control tables can enhance business partner relationships. You can also use defined interfaces to install program logic. To show that two business partners have a particular relationship to one another, we assign them a relationship category. It is possible to enhance a relationship category with attributes. The relationship category describes the properties of a relationship and characterizes it with attributes. There is a difference between a one-way business partner relationship category and an undirected business partner relationship category. In a one-way relationship category, the relationship extends from one partner to another, but not vice versa (for example, "is employee of"). Several relationships of this category will be created (for example, "is contact person of"). The business partner relationship categories available depend on the business partner category in question. When a relationship is created, the system will check whether a business partner was created in a particular role (role dependency of a relationship category).
By entering a start and end date, a business partner relationship can be given a time limit.
Adding attributes and new relationship categories via the Business Data Toolset (BDT) can extend existing relationships.
Additional Relationship categories for
Exide-Has a Dealer Has a Sub Dealer Has an OEM
Has an End User Has an Institution Has a Consultant
Has a Specification Provider Has an Inspection Agency Has a Test Laboratory
Has a Govt. Regulatory Body Has a Charger Manufacturer Has a System Integrator Has an Agent
Has a Switch Manufacturer Has an EPC Contractor Has a Fork Lift Manufacturer Has Zonal Railway
Has a Manufacturing Unit (Rly.) Has a Depot
Has a Nodal Agency Is a Dealer Is a Sub Dealer Is an OEM Is an End User Is an Institution Is a Consultant Is a Specification Provider Is a Inspection Agency Is a Test Laboratory
Is a Govt. Regulatory Body Is a Charger Manufacturer Is a System Integrator Is an Agent
Is a Switch Manufacturer Is an EPC Contractor Is a Fork Lift Manufacturer Is a Zonal Railways
Is a Manufacturing Unit (Rly.) Is a Depot
Is a Nodal Agency
TO BE MODIFIED AND MINIMIZED AS PER NEW BP ROLES
Numbering Ranges:
The internal number range within SAP CRM corresponds to an external number assignment in SAP R/3. In this way, a business partner receives the same number in both systems. Generally speaking, an active SAP R/3 system already exists and the number ranges in SAP R/3 are already defined. If an internal number assignment is desired in SAP R/3, no further number ranges are necessary. If external number assignment occurs in SAP R/3 as well, this number range must be maintained.
You define the number ranges in SAP R/3 and assign them to account groups in the Implementation Guide (IMG). SAP R/3 and SAP CRM also have two different concepts regarding the use of business partners in business processes (for example, in an order). In SAP R/3 you can use only a customer with the correct account group (for example, sold-to party). In SAP CRM, you can use each business partner for a specific process independent of its role, as long as the necessary data is maintained (for example, a business partner can be used as a sold-to party only when pricing data is maintained).
A mapping structure exists between business partners in SAP CRM and SAP R/3 customers (in both directions).
In SAP CRM, a business partner is classified in four ways. These classifications are mapped with the account groups. SAP CRM offers these four classifications:
Consumer (an organization or person) Customer
Prospect Competitor
In SAP CRM sold-to party, ship-to party, bill-to party and payer map to the customer and the customer is mapped to one account group.
Mandatory fields must be synchronized between SAP CRM and SAP R/3.
1.2 Organizational Management
Organizational Management can be used to set up the company‘s organizational structure in the CRM environment. You can use this flexible tool to maintain the company structure, including the positions and employees in an application, and assign specific attributes to the organizational units.
Organizational Management allows you to specify organizational data automatically in a business transaction using the organizational structure. It can also be used to
determine business partners, for example, you can find the employee responsible for a business transaction.
For example, a prospect calls an insurance company, the call center agent creates an activity and takes down the name, address and telephone number of the prospect. The system uses the postal code to find the office responsible for this customer.
With this flexible tool, you can change the organizational structure. You can include your own organizational levels and leave levels out. Because this tool is time dependent, you can maintain different organizational structures for different time periods in parallel; that means you can plan changes in future. For example, a new sales office will open on the first day of January next year. You can define this sales office and assign it to your organizational plan already today with the validity date of 1 January next year.
The organizational plan is not static, it is dynamic. With this adaptable and extendable tool, you can maintain and change the organizational plan at any time without making changes in Customizing.
You can use the same organizational structure for different scenarios by activating it (CRM Sales, CRM Service). An organizational unit can be a sales organization and service organization at the same time. Scenario-specific data in the structure is assigned to the organizational units with attributes.
Organizational units can occur as business partners. The system automatically creates a business partner record for an organizational unit with the BP role "Organizational unit."
The organizational model is maintained in the application, not in Customizing. (It can be maintained in Customizing as well.) You can prevent users from making changes to the organizational model by using an authorization check.
The organizational structure in SAP CRM can be different from that in SAP R/3. The structure has no restrictions regarding usable levels.
A matrix structure cannot be mapped.
You can assign one or more scenarios to an organizational unit. This means you can use one organizational unit for different areas, for example, an organizational unit can be a sales organization in the Sales scenario and a service organization in the Service scenario. You can maintain different attributes depending on the assigned scenario.
If sales structures exist in SAP R/3 and are not used in SAP CRM, these structures should not be reflected in the CRM organizational model. The organizational model can be generated by a report, or can be maintained manually.
You can assign scenario-specific attributes to the relevant organizational units for organizational data determination, transaction processing, and partner determination. System users or employees can be assigned to positions, and positions can be assigned to organizational units. Positions play a large role in the context of partner determination.
In SAP CRM, there are two types of determination rule can be used to find responsible organizational units: organizational model and responsibilities.
The organizational data from the document header is copied at item level. There is no separate organizational data determination at item level.
An individual organizational unit is created for sales organizations, distribution channels, sales offices, and sales groups. If a sales group is assigned to several sales offices within SAP R/3, the first assignment is taken when copying. A sales group cannot be assigned to more than one office in SAP CRM. The company code currency of the SAP R/3 sales organization is assigned as an attribute of the corresponding sales organization in SAP CRM.
Distribution channel and division are mapped as attributes of an organizational unit. Multiple Assignments of organizational units will be maintained in CRM, if required e.g. if in SAP R/3, multiple sales groups are assigned to the same sales office it will be possible to maintain these assignments
It will NOT be possible to assign a sales group to more than one sales office in CRM
R/3 Organisation Structure Sales
Organization Distribution Channel Division Description
INDL I1- Railways-MP Exide
I2-Infrastructure Rail-SB SF
I3- Infrastructure Telecom I4- Infrastructure Power I5- Infrastructure Projects I6- Infrastructure Solar Batt I7- Infrastructure Solar System
F2- FMIB Traction Trade F3- FMIB UPS OE (Fld) F4- FMIB UPS Trade (Fld) F5- FMIB Inverter OE F6- FMIB Inverter Trade F7- FMIB UPS OE (SMF) F8- FMIB UPS Trade (SMF) F9- FMIB Deemed Exports IC- Industrial Exports CBSEA IE- Industrial Export Non CBSEA
CL- Caplamp
SV- Industrial Service & AMC
IN – Indl Common Distr Chnnl What about STFR/ST?
Should we go for Territory? Seems to be difficult to handle.
Service Organization
Service Organizations will be created at sales organization level, central service level, and at regional levels. The branch offices will be treated as organization units. Regional Service managers, Regional service heads will be assigned as positions to the service organizations at regional level. Central service Shamnagar and Hosur will be assigned to the central service Org
Unit (Sales Org)
Sales
Orgn Auto Indl EXIDE 1. Director - Industrial 2. Chief- Commercial 3. Marketng Services 4. Manufg Services Org Unit (Regions) Central Espex
CBSEA North East West South
RSMs (N, E, W & S) CBMs / PMs (INFRA-1, INFRA-2, FMIB, CL, EXP, PM -Shm, PM-Hld, PM -Hsr, PM-Gnd & R&D) Org Unit (Sls Office) Sales
Office Jamshedpur Patna Cuttack Guwahati Calcutta 1. Sales Officers (For Regions)2. Brand Heads (For HO)
Org Unit (Sls Group)
Sales
Group Same As Above
Org Unit (Sls Teritory) Jalpaiguri 24 Parganas Birbhum Calcutta
1. Sales Officers (For Regions) 2. Brand Heads (For HO)
1. MSRs (For Regions) 2. Officers (For HO) Proposed
In CRM ExistingIn R/3 Details Of Proposed Structure In CRM Positions Envisaged In CRM Proposed Organization Structure In CRM (SALES AND MARKETING)
Org Unit (Sector)
Domestic
organisation. Service team will be created as an organisation unit and the ASP / SF will be assigned to the Service team. The branch offices will come under the regional service organization level.
Sr. No. Service Org. Description
1 Central Service Central Service
2 North North 3 South South 4 East East 5 West West 6 Export Export 1.3 Territory management
Territory Management enables you to structure and organize your sales market by dividing it into territories according to criteria of your choice (such as size, distance, revenue, products or number of visits). Whereas the organizational model reflects the internal view of your organization, the territory hierarchy reflects the market view. Changes to the territory hierarchy usually occur more frequently than changes to the organizational model. The customer base can increase or decrease
Org Unit (Sales Org)
Sales
Orgn Auto Indl EXIDE 1. Director - Industrial 2. Chief- Commercial 3. Marketing Services 4. Manufg Services Org Unit (Regions) CSS ESPEX
CBSEA North East West South 1. RSMs2. RSHs 2. Service Co-Ord1. Service Head
Org Unit (Srv Office)
Sales
Office Jamshedpur Patna Cuttack Guwahati Calcutta
1. Service Officers (For Branch) 2. Service Vans (For Segments) 3. Service Team for CSS 4. ASPs & 5. MSRs
Org Unit (Srv Group)
Sales
Group Same As Above
1. Service Officers (For Branch) 2. Service Vans (For Segments) 3. Service Team for CSS 4. ASPs & 5. MSRs Proposed
In CRM ExistingIn R/3 Details Of Proposed Structure In CRM Positions Envisaged In CRM Proposed Organization Structure In CRM (Service)
Org Unit
and territories must be resized or reallocated to accommodate this to ensure that a sales representative has the appropriate workload.
Reduce expenses: Running a field sales force is one of the costliest factors faced by a company. A well-defined territory structure with the associated responsibilities can help you reduce these costs.
• In the Business Transaction, the territory can be determined from the employee responsible or from attributes of a business partner (for example, sold-to).
• In Territory Analysis, the sales manager can analyze his territory and employees using different criteria.
Territory Management enables you to structure and organize your sales market by dividing it into territories according to criteria of your choice (such as size, distance, revenue, products, number of visits). These territories are structured in a territory hierarchy.
You can assign employees permanently or for a definite time period. You assign an employee to a territory via the employee's position. This makes it easier to assign another employee to the territory if the first employee is away from the office or has left the company. When you change this information in the organizational model, this information is automatically considered in the territory in CRM Enterprise. You can carry out planning, analyze sales figures, and monitor performance of the territories and the salespeople. You can change the territory hierarchy when territories must be redefined to accommodate the changing sales market.
1.4 Product master
The CRM product master represents products (for example, a hard disk), services (for example, PC warranty, PC maintenance) and financing.
Products can be service packages, bills of material or a combination. Configurable products, such as personal computers, are only given attributes and attribute values when the product is sold.
Warranty information for individual objects is created with reference to product, for example, product registration via e-service.
A separate number range can be maintained for each product type. Other product types are available for industry-specific SAP CRM, for example, IP (Intellectual Property) for the Media industry solution.
The CRM product master is a collection or arrangement of various set types that contain specific data. Set types, which correspond to database tables, are displayed on various views (tab pages). Predefined set types (for example, basic data, short texts, conversion of unit of measure) are delivered with the standard product. You can enhance the product master with user-defined set types.
R3PRODSTYP maps the product types present in the SAP R/3 system. For this reason, it is vital to assign the base hierarchy R3PRODSTYP to make basic data set types available.
R3PRODSTYP is the default base hierarchy. Products loaded from SAP R/3 into SAP CRM must belong to at least this base hierarchy. Assignment to other base hierarchies is optional.
Product categories are used to group products together according to various criteria.
Categories inherit the product category and the set types of all super ordinate categories. For example, the base hierarchy R3PRODSTYP contains the category MAT_. This contains various set types, such as basic product data and conversion of units of measure. The sub-category MAT_HAWA inherits the set types from MAT_ and has additional set types, for example, sales set types. The assignment of a product can be changed or deleted.
• An initial download is performed at the start, when SAP CRM is set up. Existing Customizing data is a prerequisite for a successful initial download. The middleware settings act as a filter to control which data should be loaded. During the initial download, a distinction is made between the object type’s business object, customizing object and condition object.
• The delta download ensures that transaction data and master data are permanently exchanged between the CRM and a back-end system. Customizing changes are not updated via delta download.
• During the initial download, product hierarchies are loaded from SAP R/3 into SAP CRM. The Material group and Product hierarchy fields are compared. • In the Customizing download example, the product hierarchy in SAP R/3: • At present, there must be a suitable numbering scheme in the SAP CRM
A competitive product has a lean product master. This is controlled by the product category. Competitive products can be created on the portal and can be integrated into business processes for Activity Management or Opportunity Management.
Competitive product information is exchanged with the mobile client in both directions.
The following is a standard delivered relationships: Competitor – competitor product
With inconsistent product data, the application log contains serious errors, for example, base unit of measure = XY. In this case, it is not possible to save the product data actively, only inactively. After the errors are corrected, it is then possible to save the inactive product data actively. Only then is the product available in the CRM applications.
Mass maintenance of inactive products is possible. Through collective processing, you can activate and delete several products at a time.
Inactive product data can also be created, if, for example, product data from product catalogs is imported into the CRM system by suppliers. The imported data can be processed subsequently; the data can be activated only after post-processing.
Relationship:
The relationship has accessories plays a large role in the CRM product catalog, which is used in the Internet sales scenario. If a customer adds a product to her shopping cart, additional products can be suggested to the customer via the relationship has accessories.
The following are additional relationship types:
• Components
• Warranty
CRM Product enhancement (downloaded from R/3):
The material master from R/3 will be downloaded as CRM product of type material .In the CRM system the same hierarchy and category will be extended as maintained and required by EIL. Additionally field for “Life of Battery “ will be made available in SAP CRM.
CRM Service Product
Different products used in service process are:
Service product item – describes the service to be performed. Installed base component and products can be assigned to the service item in objects list. Sales product item – sales product item is a spare part.
Expense item – documents an additional invoice paid by the service employee e.g. Hotel expenses
Spare Parts (Materials in R/3), which are configured in SAP R/3 system, will be uploaded to SAP CRM as part of Middleware Set-up activity. The spare parts will be billed in SAP CRM as a part of service revenue and will not be set as billing relevant in R/3.No new spare parts will be created in SAP CRM. Spare part creation will be always in SAP R/3. Whenever a new spare part will be created in SAP R/3 after Go Live, that spare part will be available in SAP CRM (Delta Upload needs to be activated). Service products will be created in SAP CRM and will be billed in CRM. Expenses will be created as service products in SAP CRM. The following service products will be created in CRM:
1. Annual Maintenance Contract (AMC)
2. One time rectification
3. Service charge
4. Services covered under pro-active visit
5. Expenses
6. IFC
7. Installation and Commissioning
8. Health Check
1.5 Price master Sales
All Pricing procedure relevant to Industrial SBU will be downloaded from R/3 for quotation and order. Conditions will continue to be maintained in R/3 and will be downloaded to CRM (both initial and delta).
R/3 PRICE MASTER
FMIB (F3 to F9 Distribution Channel ) Used pricing condition
PR00 (Basic Price with Excise Duty) –for Branch order – Pricing Procedure ZIND4 ZPRI (Basic Price with Excise Duty) – for Factory order - Pricing Procedure ZIND5 ZSTO- Basic Price for Stock transfer order
ZSCP – Basic Price for Scrap Sales
Rock bottom price conditions:
ZRBR – Rock Bottom price for Branch (FSO) ZRBP – Rock Bottom price for RSM
ZRBS – Rock Bottom price for RSM – Special (Post facto approval from HO reqd) Discount Conditions :
K004 – Material Discount (Difference between MRP & Dealer Price) - For Branch Order only.
ID03 – Manual discount condition against Rock Bottom Price ZRBR ID02 – Manual discount condition against Rock Bottom Price ZRBP ID2S – Manual discount condition against Rock Bottom Price ZRBS ID01 - Manual discount condition to come down below ZRBS ID05 - Service Discount applicable for Emergency Lantern only. YV01- Volume discount (Predefined scale) for Battery groups ZCD1 - Dealer Cash discount ( for Cash & Carry Business only) Other Conditions :
ZIEP - Manual condition to increase the Basic Price.
JMAN - Manual condition to Maintain the ED – where Automatic Condition JMOD is missing.
ZRND – Condition for Rounding off
Access Sequence :
1. For UPS/Inverter OE ( Dist. Channel F3,F5 & F7) - Access Squence will be Customer/Material/Dist. Channel for condition PR00, ZPRI, K004, ZRBR, ZRBP, ZRBS (Where Rate Contract with Customer Exists)
2. For UPS/Inverter Trade & Deemed Export ( Dist. Channel F4,F6, F8 & F9) - Access Squence will be Material/Dist. Channel for condition PR00, ZPRI, K004, ZRBR, ZRBP, ZRBS
3. For all Dealer & OE Channel ( F3 to F8) Stock Transfer Price (ZSTO) Access Sequence will be Plant/material level& Material Level (for new Product only)
INFRASTRUCTURE (I1 to I7 Distribution Channel ) Used pricing condition
ZPRI (Basic Price with Excise Duty) – for Factory order- Pricing Procedure ZINDL1 & ZINDL2
ZSTO- Basic Price for Stock transfer order ZSCP – Basic Price for Scrap Sales
Rock bottom price conditions: ZRBP – Rock Bottom price Discount Conditions :
ID01 - Mannual discount condition Against ZRBP Other Conditions :
ZIEP - Mannual condition to increase the Basic Price.
JMAN - Mannual condition to Maintain the ED – where Automatic Condition JMOD is missing.
ZRND – Condition for Rounding off
Access Sequence :
1. For All cases ( Dist. Channel I1 TO I7)
Access Squence will be Material/Dist. Channel for condition PR00, ZPRI, K004, ZRBP
2. For all cases Dist. Channel ( I1 to I7) Stock Transfer Price (ZSTO) Access Sequence will be Plant/material level& Material Level (for new Product only)
Export ( CBSEA & Non CBSEA) - (IC & IE Distribution Channel ) Used pricing condition:
ZEXP (Basic Price ) – for Export Order ZFOB – Export FOB Price
ZEFC – Freight Proportional
Power Electronics & Cap Lamp sales - (PE & CL Distribution Channel )
PR00 (Basic Price with Excise Duty) –for Branch order - Pricing Procedure ZINDL6 for PE & ZGUIND for CL
ZPRI (Basic Price with Excise Duty) – for Factory order - Pricing Procedure ZINDL1 for PE & ZGUIND for CL
ZSTO- Basic Price for Stock transfer order
Note that same price master will be used in quotation also with unique Access Sequence.
Service
Pricing Procedure for service orders, AMC and confirmations will be created in SAP CRM. Pricing Conditions and Condition Types for service processes will be created in SAP CRM as part of customizing Activity. Separate pricing procedures will be created for separate service processes. The pricing master data of all the spare parts will be uploaded through an uploading program using LSMW or BDC. The prices of service products IFC and I & C will be uploaded through an uploading program; Because IFC and I & C charges are different for different kind of batteries. For all other service products the prices will be maintained manually.
1.6 Master Data Management
The master data management strategy for business partner creation in CRM would be:
New Business Partner Creation in SAP CRM – Pros
Business Partner can be created in CRM at Prospecting stage of a Sales Process and can be transferred to R/3 only when the Business Partner is converted to Customer (Business Partner with role Prospect can be created in CRM for Lead Management & Opportunity Management. The role Sold-to-Party can be extended to the Business Partner for Quotation Management. The Classification Customer can be checked to facilitate the replication of this Business Partner data in SAP R/3.)
Only Business Partner with role Customer would need to be reside to SAP R/3
Business Partners can be created locally (Regional level) for Prospecting Stage
Cons
Separate Number Range for Industrial Customers will have to be maintained in R/3 corresponding to CRM number range
New Account Groups will need to be created in SAP R/3
In addition to CRM data, accounting information will have to be maintained in SAP R/3 for these business partners
Same Business Partner will have to updated in several times in CRM to extend roles and also in SAP R/3 for accounting data
New Business Partner Creation in SAP R/3 – Pros
Same Number Ranges as current can be maintained
Same Account Group as current can be maintained
All data for a Business Partner including Accounting data can be maintained
Only one time data maintenance for Business Partner
Cons
Business Partners can only be created centrally as per current policy
CRM functionalities such as Lead Management, Opportunity Management, Quotation Management will have dependency on Business Partner creation by central IT team
All Business Partners created in the SAP R/3 system may not necessarily be Customers
In Service scenarios where end customer data is not created in CRM, the contact center agent will have to send a message to Central IT to create Customer Master in SAP R/3 and only when this is created in SAP R/3 and replicated to CRM will the agent be able create a Service Order
Exide decision awaited on master data management for new business partners
Product Master
Products of type Material will be replicated from SAP R/3 into CRM Products of type Service will be created in SAP CRM and NOT be
replicated to SAP R/3
Product Hierarchies will be maintained in SAP R/3 and will be replicated into CRM
Employee Master
Employee Master will be maintained in SAP HR
CRM relevant data such as qualification will be maintained in SAP HR Since Employee Number Range and Customer Master Number Range
overlap in current R/3, the Marketing, Sales & Service Employees will be manually created in SAP CRM by Central IT
Industrial Business will define a process for Employee Maintenance in CRM
Conditions Master
Conditions Master will be maintained in SAP R/3 and replicated to CRM Condition Type for Service Products will be created in CRM and NOT
replicated to SAP R/3 Installed Base Master
Installed Base Master will be created only in CRM Solution Database Master
Solution Database Master will be created only in CRM
NOTE: Notification to CRM Master Data Maintenance team for some Master Data created in R/3 and vice-versa.
2.0 Service Functional Scenarios –Functional Scope 2.1 Installed Base
The installed bases will be created in CRM system through a> Standard uploading program
b> Custom developed uploading program or c> Manual creation.
The unused installed bases or expired installed bases can be deleted from the system.
The standard uploading program will be used for segments on Infra1 and Infra2.
The custom developed program will be used for all segments for entering survey details, campaigns, mobile service van details etc., The manual creation will be made during complaint handling for all segments.
Installed bases will be created in two ways.
Creation of Installed base 1: This is a virtual Installed base which will have all sold-to-party, ship-to-party data directly from R/3 through standard uploading.
Creation of Installed base2 : This is a realistic Installed base which will have only such information collected based on physical existence of the installations – the data collected through complaints, survey etc., The Ship-to-party will also be maintained in this Installed base.
FMIB: The installed base of the end customers will be captured during OEM complaint logging / dealer service station claims. The existing installed base will be uploaded through process b and c.
Power & Projects: The installed base will be created thru all the processes a,b and c.
Railway: The installed base will be captured thru process b and c. Telecom: Same as Power & Projects
The manufacturing code will be used to identify individual batteries. The warranty will be associated with components/individual objects of the installed base.
Traction: The installed base will be created from the sales order by using a standard SAP Program for direct customers and for other customers it will be captured thru process b and c.
Solar & Defence: Same as Power & Projects. The installed base comprises of the following:
Components (Products)
Individual Objects (to identify the object, unique identification) Text (capture history)
Business Partners like sold-to party, ship-to party, contact person, employee responsible can be attached to the installed base. Warranty will also be attached to the installed base components or individual objects.
In case of OEMs, Dealers or indirect customers, they will be attached as contact person (business partner) to the installed base. The manufacturing code will be used as an individual object. The warranty will be attached to the individual object. In case of direct customers like in Power and Projects, traction, telecom, they will be attached as sold-to party (business partner). The warranty will be attached to the battery bank.
Installed Base management for Lead/Opportunity generation:
Currently, the known Installed base consists of invoicing to direct customers, data collected through Tracmobile visits and data collected through external agencies / summer trainees.
The Installed base from R/3 sales orders (for which invoicing has taken place) will be uploaded to SAP CRM system by a standard SAP program. The installed bases collected through tracmobile or through external agencies will be uploaded to the system by a customized uploading program.
The competitor’s product and make will be created in the CRM system and will be attached to the installed base along with Exide product. The competitor’s name will be captured in the short string field of the installed base.
Leads from installed base: A report called installed base analysis will be available in SAP BW system. The report will contain installed bases and the products inside the installed bases. The manufacturing date of the product will be captured from the installed base. The life of battery will be captured from the product master. In product master a new set type called life will be created and the set type will contain a field called life of battery. Life of all batteries will be captured. In the report, the expiry date of batteries will be calculated from the installation date and life of battery. An alert/notification will go the segment head/sales officers from BW system 3 months/6 months before expiry date. Also there is a requirement for sending service reminders before warranty
expiry date. The process will be similar to the process of installed base life.
2.2 Complaint & Warranty
Complaints and In-House repair are two different transaction types in CRM. Complaints are basically handled at sites. The defect products are not brought to the service station for diagnosis, where as in In-house repair the defect product is brought to service station for
diagnosis. Complaint is used where no diagnosis happens and no loan devices are provided for the defect product. Complaints can handle replacement or substitute delivery, credit memo and debit memo and returns. In house repair supports diagnosis, loan device, scrapping and repair.
In Exide, the complaints are basically handled at the service station level. Whether the complaint is a site complaint or a service station complaint the defected product is brought back to the service station for diagnosis. If the battery is revived at the site, the revived product is sent back to the customer. If the battery cannot be revived and the battery is under warranty, a new battery is issued to the customer. Also loan devices are provided till the battery is revived or a warranty replacement is made.
So CRM transaction type In-House repair will be used for both site complaints and service station claims. The in-house repair is a document that covers all relevant data for the whole in-house repair process. It starts with a repair request and all required follow up (return request, scrapping, diagnosis, loaner management) are managed in the transaction. Although replacement is not a standard follow up process of house repair, it will be configured for the in-house repair transaction.
The process of creating a complaint is as follows:
1> Enter the complaint details in the common complaint entry screen (The compliant number will be immediately generated based on this entry)
2> A follow/up activity will be popped up for creating business partner (if does not exist) with very basic information. The Sold-to-party and Ship-to-party entry will be made. If a complaint is generated from Numeric Jallandhar, for SBI Jallandhar, The Numeric Jallandhar will be sold-to-party and SBI will be created as business partner first and attached as ship-to-party.
Site Complaints:
Interaction
Center Regional Exide office / HO
Letter Fax Phone
CIC agent/ Exide office will create the complaint document. The BFR will be attached to the complaint. The CIC agent will communicate the complaint number to the complainant. An email will also go to the complainant in a pre-defined format. Warranty will be attached to the individual object of the installed base.
Regional Service Central Service Head ASP Segment Head E m a i l
Regional Service / ASP will assign a service
engineer to do a site visit. An email will be sent to the site engineer with all the complaint details. The site engineer comes back with an inspection report. Create Installed base with components, serial no and manufacturing date. The inspection result will be attached to the complaint document. Only one transaction type In-house repair order will be used.
If the battery / battery bank is under warranty, the site engineer will carry loan /replacement batteries to the site. He will replace the standby/loan/new battery with the faulty battery. The warranty will be checked from the manufacturing code of the battery.
If the battery is out of scope of warranty, the claim will be rejected and the complaint will be closed. The reason for rejection will be captured The service engineer will replace the faulty battery
with a standby battery. He carries the faulty battery to the service station for Diagnosis. The diagnosis report will be attached in CRM in-House Repair screen.
If the battery is revived, the revived batteries will be replaced with the standby batteries. The complaint will be closed.
If the battery cannot be revived, an FOC
replacement will be made under warranty
obligation. The complaint will be closed.
An FOC invoice will be generated for replacement battery.
A service confirmation will be created. The expenses incurred by service engineer or ASP will be captured. The service confirmation will be treated as a job confirmation certificate. An Email of the complaint summary in a specified format will go to the complainant A service confirmation will be created. The expenses incurred by service engineer or ASP will be captured. The service confirmation will be treated as a job confirmation certificate.
Print outs of following documents will be generated from CRM: Diagnosis Report CRM complaint document Rejection Memo Revival memo Copy of FOC
Service Confirmation copy BFR
Inspection report Complaint summary
Service Station Claims
Dealer brings the battery to the service station with a sales bill and guarantee card. The regional service/ branch verify the physical document. If the documents are valid, the complaint will be logged.
The regional service / branch will capture the installed base and the business partner (end customer as contact person) from the sales bill of the end customer. The
complaint document will be created in the name of the dealer. A print out of the complaint document will also be generated. The CRN will be attached to the complaint document as an excel sheet. The Regional service will also allocate a service engineer or ASP for the claim. The installed base will be validated against the warranty by the system.
An email will be sent to the dealer after complaint logging. The email will
contain all relevant complaint data including on receipt inspection report.
If no valid documents are found, the complaint will be rejected. Also in case of physical damage the claim will be rejected.
The service engineer will do the diagnosis and will attach the diagnosis report to the complaint document.
If the battery is out of warranty, the claim will be rejected and an email will be sent to the dealer with rejection reason.
The complaint will be closed If the battery is within warranty
If the battery is revived, the revived battery will be sent to the dealer along with diagnosis report.
If the battery cannot be revived, an FOC replacement will be made with the old guarantee card. In CRM no new warranty will be attached to the installed base. Date of installation for the replacement will be the date of The complaint will be closed
and an email will be sent to the dealer and FSO of the region with all the details.
An FOC invoice will be created for the warranty replacement.
A service confirmation will be created and will be treated as a job completion certificate.
Print outs of following
documents will be generated from CRM:
Diagnosis Report
On Claim Receipt Inspection Report CRM complaint document Rejection Memo Revival memo Copy of FOC Service Confirmation Complaint summary
Complaint Handling for Traction, Telecom, Power and Projects (installed base
The complaint is logged at regional service / central service level. The regional service or central service will create the complaint document. A service engineer or ASP will be assigned to handle the complaint.
Central Service Head
ASP / Service Engineer
Regional Service Segment Head E m a il
An email will also be sent to the Complainant with all the complaint details
The system will validate the warranty attached to the installed base
individual object (manufacturing date)
If the battery bank is within warranty, the complaint handling process will be like Site complaint handling
The battery bank is out of warranty
A service quotation will be created. It will contain the details of the spares and services required. An email will be sent to the complainant in a format, which will contain spares and services along with the price.
Status of the quotation is Quotation accepted and payment made
The service engineer will attend the complaint and will perform the repair. For each repair step, a spare part (if required) will be attached as a sub-item. After the repair the complaint will be closed.
A service confirmation will be created.
An email with the complaint and quotation details will be sent to the regional service or central service to assign a service engineer or ASP to perform the repair.
2.2.2 Railway Complaint
The complaint handling process of Railway and Solar will be similar to the site complaint handling of OEMs.
The complaint handling in Railways is both pro-active and reactive. In northern and eastern region the rail care vans do the pro-active visits, where as in Southern and western region the complaint handling is reactive. The Rail care van takes care of VRLA batteries as well as flooded batteries.
During the pro-active visits the service engineer comes across complaints. The process will be similar to the process of FMIB site visits.
Traction complaint handling:
The traction complaint is handled by Tracmobile (van equipped with a service engineer, spare parts and other accessories) in major cities and by service engineer in up country locations, which will be similar to the process of site complaint
handling for OEM.
Customer logs a complaint at regional service level, at branch level or calls the Tracmobile service vans. If the customer is within the Tracmobile zone, the service engineer in a Tracmobile van visits the customer. The scope of warranty is checked. FOC Services and spares are provided if the battery is under warranty. The
Tracmobile engineer does the repairing and replacement and closes the complaint. If the battery is outside warranty services and spare parts are provided on
chargeable basis. A service quotation is raised for the spares and services. After acceptance by the customer and payment the service engineer/Tracmobile engineer visits the customer and performs the repairing/replacement.
2.2.3 Solar complaint handling
The complaint handling in CRM will be similar to dealer service station claims of FMIB sector.
2.2.4 Response or SLA
SLA:
Segment Response time Resolution time
OEM 48 hrs 10 days
Dealer 72 hrs 10 days
Railways (Flooded & VRLA)
48 hrs 10 days
Power & projects 48 hrs 10 days
Solar 48 hrs 10 days
Defence 48 hrs 10 days
2.2.5 Catalogs, Code Groups and Codes
Catalogs can be defined with damage codes, which speed the entry of complaints and enables statistical evaluation. Integration with SAP BW system enables to create statistics for evaluation process (such as how many complaints for a
particular product). The following Catalogs, code groups and codes will be used for complaint analysis.
Catalogs Code Groups Codes
Capacity Failure End of Life End of Life
Mix Batch code battery
bank Mix Batch code battery bank
Battery bank of different
makes Battery bank of different makes
Poor IFC Poor IFC
Delay in Installation between 6 to 9 months
Between 9 to 12
months
More than 1 year
Incorrect UPS setting float voltage less than
13.5 V
Charging current less than 10%
Float Voltage more than 14V Charging current more than 15%
Poor maintenance Batteries running dry
Loose connection Contamination of electrolyte
terminals
All battery specific gravity low
Earth Leakage
Site conditions ambient temperature
more than 350 High power cut site High temperature with high power failure UPS not functioning AC input less than 150V Damage battery in the
battery bank Damage battery in the battery bank Paralleling of battery bank more than 3 banks
Charging current set less than 10%
Batteries bulged in battery
bank all batteries bulgedPartially bulged Lower capacity battery
selection For specific load Lower capacity batteryselection For specific load
Few cells lagging
In the battery bank Short-circuit in the cellTerminal sulphating
Short circuit in the cell Terminal sulphating
Damage of container container damage
Components damage
Vent strip/cap open Lid Damage
Inter cell connector damage
Terminal damage Terminal damage Vent strip/cap open Lid Damage
Inter cell connector damage
Short Supply Short Supply of battery
Short supply of components
Short Supply of battery Short supply of Inter cell connectors
Termoinal nuts and bolts Vent plug
Float & float guides Acid
Spares
Battery stands
Leakage From Negative terminal
From positive terminal From heat sealing area From ven cap / strip Container leakage
From Negative terminal From positive terminal From heat sealing area From ven cap / strip Container leakage
Wrong supply Wrong supply Wrong supply Low OCV before
Installation Low OCV before Installation Low OCV before Installation
2.2.6 Reason for Rejection
Claims will not be accepted for following reasons 1. Battery out of warranty
2. Secondary transit damage
3. Damage battery used in a battery bank 4. Battery bank having mixed batch codes
5. Battery bank having different make of batteries 6. Other make battery bank at site
7. Delay in installation 8. Incorrect UPS settings
9. Battery terminals soldered (for small VRLA)
10. Battery terminals melted
11. All batteries bulged in a battery bank
12. A fully bulged battery (a single cell bulged will be accepted)
13. Battery bank parallel with other make battery bank
14. Original warranty card and sale bill not provided with claim
15. Poor maintenance of flooded batteries (batteries running with low level of electrolyte)
16. More than 3 battery used banks in parallel
17. Any claim brought beyond 14 months of our date of sale
18. Batteries received from dealer after 7 days of the original return from end customer
19. VRLA battery voltage below 10V for a 12V battery and 4V for a 6V battery
20. Soldering of battery terminals
21. Battery overcharge
22. Contamination of electrolyte in flooded battery 23. Flooded battery in fully discharged state
24. Battery Overcharged
Status management in complaints:
Following statuses will be used in Complaints:
1. Responded
2. Standby provided
4. Warranty Accepted but FOC not issued
5. Complaint closed
The user status complaint closed will automatically set the system status as closed. Documents for the complaint in CRM:
Following documents will be attached to the CRM complaint document manually: 1. BFR
2. Site Inspection report 3. Diagnosis report
Following documents will be generated from CRM in the mail form or print out which will be created using smart forms:
1. Copy of complaint document during complaint logging in a format 2. Copy of Rejection memo
3. Copy of revival memo 4. Complaint summary Date types in Complaint:
Complaint responded
Standby provided
Complaint closed
First Response time Complaint closure time
Also print out of the invoice (FOC/chargeable) will be generated from CRM.
2.2.7 Integration with R/3
A dedicated R/3 storage location will be attached to the service organisation, service team and service employee for spare parts, replacement, loan device and scrapping. Three storage locations in R/3 are available
INSB – Standby batteries
INFB - FOC stock (Good battery)
The above three storage locations are present in one plant only. 1. Create send in repairs
SAP R/3 return request will be created for goods receipt processing. 2. Create Repaired goods delivery
A SAP R/3 delivery document will be created and managed in delivery list to return the repaired product to the customer
3. Create temporary replacement (loan device)
A SAP R/3 delivery document will be created and managed in delivery list to send a loan device or standby to the customer.
4. Create temporary replacement (Pick-up loan device)
A SAP R/3 delivery document will be created and managed in delivery list to pick the loan device or standby up from the customer.
5. Warranty Replacement (FOC)
A SAP R/3 delivery document will be created and managed in delivery list to send a replacement battery to the customer.
6. Scrapping
A SAP R/3 delivery document will be created and managed in delivery list to receive the scrapped batteries.
7. ASP cost to be captured in R/3. In R/3 Exide is capturing the cost of ASP. So the cost incurred during service process by ASP has to be transferred to R/3. The controlling set-up for the above configuration has to be done by exide. The CRM configuration will be carried out.
Service process for out of warranty Installed bases:
In case of out of warranty battery banks, a service quotation Containing services and spare parts will be created as a follow up document. After the quotation acceptance and payment receipt from end customer, the service engineer or service team is sent for executing the services. In CRM the same complaint/In-house repair screen will be used and the repair and spare parts action (to perform the required repair steps and spare parts required for the repair steps) will be triggered as a sub-item of diagnosis (Inspection). The CRM system will create two new line items, one for the repair step (for example change of the battery bank container) and the spare part required
for the repair step (for example the container for the battery bank).After saving the in-house repair order, the system creates an SAP R/3 reservation in the in-house repair service plant for the entire spare parts item. A spare part confirmation updates the reservation and the in-house repair stock. The confirmation will be a follow up document of the in-house Repair order. The service engineer will confirm the time spent spare parts Consumed and expenses incurred in the confirmation.
2.2.8 Warranty
Warranty is a product in CRM. Warranty can be customer warranty or vendor warranty. Warranty can be time based, counter based and both time and counter based. Warranty has a start date, reference date and a validity period. The system validates the warranty based on a rule. It takes the starting date, reference date and validity period to validate the warranty. Warranty also covers the Catalogs and services for which the warranty is valid. It can be including or excluding the Catalogs and services. Warranties can be attached to products, individual objects and installed bases. Warranty is validated in service processes like complaint, service orders, and contracts during warranty check against the item data in the process. The warranty start date can be rule based or it can be maintained manually.
Warranty master to be used in Exide will be decided by marketing team. All the available warranties will be created as warranty master data in CRM. The marketing team will create new warranty products.
Goodwill replacement warranty:
In some of the cases, the battery is out of scope of the warranty but keeping future business in mind Exide decides to replace the battery for goodwill. The goodwill replacement will happen for the following cases:
1. Secondary transit damage 2. Out of warranty replacement 3. Abused battery replacement.
4. Customer has 24 months (EP) /extended warranty Warranty assignment:
Warranties will be assigned to the products at product master level. An uploading program will be available and all the products will be attached with their respective warranties. The warranty will be attached to the product in
