Information about customer purchases and installations are key data points that organizations need to have access to, so it is essential to be able to maintain and refer to this information for various purposes.

Here is a typical scenario: A company purchases heavy equipment to be deployed across multiple locations—for example, their Plano and Chicago locations. All purchases (known as equipments in the system) across all locations make up the Installed Base (IBase) structure, with each equipment number representing an Individual Object (IObject). Based on the unique needs at each location, the company can create different IBase structures for each shipping location, increasing operational efficiency.

That said, with increased channels for sales and service, it has been a challenge for some organizations to maintain and update their Installed Base (IBase) information. In this article, we highlight various considerations for optimal IBase design. We also reveal the links between sales ordering, delivery, customer support, and customer service processes so you can derive a full view of your customer’s purchases or installations.

Overview of Options for Creating an IBase

There are two different ways to create an IBase: integrated with ECC or standalone.

IBase functionality is best leveraged in an SAP CRM-ECC integrated scenario. After a sales order is created and the delivery document is generated, equipments are generated in ECC. This results in the creation of the IBase structure in SAP CRM, as well as in IObject creation. (Note that this scenario is very generic and applicable to most organizations.)

However, you can also create IBase as a standalone in SAP CRM for use in transactions. For example, this can happen when an end user purchases an item from another organization and then purchases a support or service agreement from your company, which is using SAP CRM for the purchase. Organizations that do not have ECC as their back-up system can create a standalone IBase by manually creating an IBase in SAP CRM or by creating equipments in ECC programmatically that do not have any link to sales orders or deliveries.

IBase Use in SAP CRM

An Interaction Center agent can use IBase when identifying an account in the Interaction Center. First, using IBase details (e.g., the IComponent, serial number, or IObject), the agent can view the customer details in the account identifying screen (Figure 1).

Figure 1

Account identification screen showing a customer with a serial number

During account identification, the system prompts all the relevant IBase and IObjects information to appear based on the customer and contact information. The agent can confirm the IBase by clicking the Confirm button, and it will be the default in subsequent transactions (Figure 2).

Figure 2

Account identification screen with customer’s IBase structure displayed

The agent can click the More Details button to view information about the IBase (Figure 3). Here, the agent can view all the installations at customer sites, as well as subcomponent information. For example, if Laptop1 is an IComponent, an agent could see details such as RAM, version, and software installed for this laptop.

Figure 3

Detailed view of IBase

View Installations or Purchases

You can also see a complete hierarchical view of the IBase by accessing the fact sheet (Figure 4). To do so, click the Fact Sheet Work Center in the navigation bar on the left side of the CRM WebClient UI and then click IBase view to access the detailed view.

Figure 4

Hierarchical view of an IBase

Another option is the IBase search functionality (Figure 5). Users can access this by clicking on Installed Bases link on the home page of the CRM WebClient UI.

Figure 5

Search for IBases

Narrow Down Customer Service Contracts

When agents or users in the Interaction Center identify a customer using the serial number, IBase, or IObject, the system automatically displays the service contract linked to the product issue reported by the customer based on the IBase details (Figure 6). This is useful because the system finds the relevant service contract for the reported issue. Otherwise, the agent or user will have to manually narrow down the relevant service contact from a list of contracts—a time-consuming task that reduces efficiency.

Figure 6

Customer details displayed next to the service contract and issue

IBase Determination in Service Transactions

When a user or agent creates a service order that references the IBase, the IBase details are automatically determined in the relevant service order transactions (Figure 7). Linking IBase details with a service order helps service technicians know all the details of that particular installation (e.g., if the product is software, they can view its version, serial number, patch level, and operating system). This improves technicians’ operational efficiency. Linking the IBase to service transactions also helps agents search for and retrieve all the associated service transactions during repeat customer calls. These linkages are also used in ABAP and BI reports.

Figure 7

A service order with IBase details

Alerts to Interaction Center Agent

Based on IBase, you can develop and configure specific alerts for Interaction Center agents. For example, if there is a problem with one of the components of a product installed at a customer site, the agent could receive alerts based on the IComponents present in the IBase and respond to the customer immediately. This leads to increased call handling speed and customer satisfaction.

IBase and Service Level Agreements

With some development work, you can set Service Level Agreements (SLAs) for service orders, service requests, or incident resolution by tying IBase to SLAs within the service order. For example, if there is an issue reported on a main engine part, the related service order can have an SLA to respond within two hours and expect a resolution or a technician deployment within eight hours.

Service Parts Management

Based on the IBase and IObject determined in the service order, you can default the service parts required for that product in service orders. One option is to set service parts as accessories. If you maintain the spare parts as accessories to products, when the product is selected in service orders, the spare parts will be automatically determined based on the products (Figure 8).

Figure 8

Product proposal view in a service order

You can also set up product proposals, a process that requires partial development. If you build the required spare parts as equipment bill of materials (BOMs), when the user creates the service order, the system automatically displays a pop-up to the technician so that the technician can select the required spare part for the service (Figure 9).

Figure 9

Pop-up screen for spare parts

View IBase in Self-Service Portals

You can also make IBase visible in Internet Customer Self-Service (ICSS) so that your customers can select relevant components on which to report issues (Figure 10). This feature is available as a standard functionality in ICSS. By doing this, your customer service across channels such as ICSS and the Interaction Center is seamlessly integrated.

Figure 10

ICSS homepage showing items that customer can select to report issues

License Key Generation with IBase

Customers (in this case, contact persons of organizations or accounts) have the ability to generate license keys in third-party tools based on customer IBase details in SAP CRM. They can achieve this using Web Services integrated with SAP CRM. Again, this process requires partial development.

Marketing Campaigns with IBase

You can also use IBase for segmentation by triggering marketing campaigns to customers that have specific components. For example, if there is a specific version of software that could leverage a new offering based on IBase, IComponent, and IObject information, you could develop version segments for campaigns. Alternatively, you could, for example, set up a targeted campaign for customers that purchased SUVs with navigation systems. You would set this up based on IObject information within the IBase that would be used to segment customers for this campaign.

IBase Process View

There are various sales channels for customers, and IBase can consolidate purchases across these channels to a single view (Figure 11). You can use this functionality during complex product structures and multiple installations. The sales channels include:

1. Direct sale to a customer when an order is processed by a salesperson
2. Purchase by customer over a business-to-customer (B2C) Web shop
3. Products purchased in bulk by wholesalers and re-sale of products to end users
4. Sales to end customers via channel partners through a business-on-behalf (BOB) Web shop or channel partner management

Figure 11

Process view of IBase

Next, we review different options to consider for IBase update and creation.

Create IBase During a First Purchase

The following scenario is applicable across many industry verticals. Whether you are dealing with a purchase of heavy equipment or software, the creation of an IBase structure is the first step.

When a customer purchases for the first time, a new IBase is created and number ranges for the IBase and for SAP CRM Middleware filter and configuration settings need to be maintained. IBase creation is a standard functionality triggered by the Business Add-In (BAdI) CRM_EQUI_LOAD_STDIMP based on the sold-to party of the equipment replicated from SAP ECC to SAP CRM through standard SAP CRM Middleware. All of the customers’ purchases are created as equipments (i.e., IObjects) and assigned to the IBase (achieved by setting SAP CRM Middleware filters as per your organization’s requirements). You can also trigger IBase based on the creation of equipment in ECC—equipments are created for various scenarios, they are not limited to sales order or delivery document in ECC.

The IBase consists of partner functions such as sold-to party, ship-to party, and address data. The IObject assigned to the IBase consists of ECC data, such as serial number, partner functions, and material number. Note that bi-directional replication of data and data synchronization with ECC happens via IObject, not in an IComponent.

Consider the example scenario we presented at the start of this article. A company purchases heavy equipment to be deployed to their Plano and Chicago locations (Figure 12). All purchases (i.e., equipments) across all locations make up the IBase structure, with each equipment representing an IObject. Based on individual customers’ needs, you can customize to create different IBase structures for each shipping location. In this example, the company could create all equipments shipped to Plano under one IBase and create all equipments shipped to Chicago under a different IBase.

Figure 12

IBase creation variation based on ship-to party

Similarly, if a customer purchases different types of products (e.g., laptops and desktops), you could create these products under a single IBase or create them as separate IBases based on the customer’s requirements (Figure 13). It is important to identify the differentiating feature between the products. In projects we have undertaken, we used product group1, product group2, item category group, or product category to differentiate. This has been helpful in enterprise installations that occur in different locations for varying products. Differentiating helps agents improve service efficiency because they have all of the required information in one place.

Figure 13

IBase creation variation based on product type

This scenario is similar across many industries, from a commercial purchase of laptops to leased and franchised items, such as fountain machines. This first step is always the same. We cover special scenarios, such as a wholesaler purchasing an item (e.g., a laptop) and selling it to the end user, later in this article.

Repeat Purchases

If the customer places a second order, you need to update the IBase to ensure that all support and service processes are in sync. Using the previous example, assume that the customer placed an order for two items to one shipping location and a second order for one item to another shipping location. If you would like to differentiate based on shipping locations, you have to update the first IBase with two items and the second IBase with one item (Figure 14).

Figure 14

IBase update variation based on ship-to party

Additional Licenses, Users, or Upgrades

With products such as software, there are often additional sales of licenses or an increase or decrease in the number of users. In these cases, you should not create new IBases or IObjects; instead, update the existing IObject with the changed information. You can maintain additional licenses or an increase in users as set types within an IObject. Even though there would be a new sales order that triggers new equipment records in ECC, you need to update the existing IObject based on BAdI logic.

Equipment Moving Between Locations

This scenario is applicable when a wholesaler re-sells items to end users. This warrants shifting the IBase from the wholesaler to the end user so that when a user calls in for service, he or she is identified based on serial number (Figure 15). You could manage this manually if the volume is low, or you could automate it using custom changes, Application Programming Interface (API), or upload file programs.

Figure 15

Wholesale re-sell to end user

This situation is common with products such as fountain soft drinks or freezers, or whenever products are franchised and not sold directly to customers. With IBases created for service providers, after installations at customer sites are complete, the installed products are moved to the customer’s IBase from the service provider’s IBases.

Manage the IBase Status

IBase has both user statuses and system statuses, and you can model them based on customer requirements. For example, you can default the initial status of IBase to any customer-specific status, such as “installed” or “at customer site.” If equipment installations are involved, either by internal technicians or third-party consultants, you could change the IBase status to “installed.” If equipment is franchised, you could set the status to “franchised.” The status can also signify whether equipment is with the wholesaler or has been sold to the end user. If equipment is no longer in use, deactivate the relevant IObjects.

What to Watch For with a Conversion

Some situations to watch out for during conversions are:

1. If you are using a legacy CRM system and want to shift to SAP CRM
2. If you are not using any CRM system and are implementing SAP CRM as your first CRM initiative
3. You have had ECC as your back-end system in both of the examples above, and there is no change to ECC during the SAP CRM implementation
4. You are using another legacy ERP system, shifting to ECC, and implementing SAP CRM as well

In all the above scenarios, you need to determine how to transport existing IBase and IObject data into SAP CRM. This is an important step in IBase design. One option is to use the Legacy System Migration Workbench (LSMW) to create equipments in ECC. Once this conversion is done, perform an initial load of equipments from ECC to SAP CRM. After go-live, based on further sales orders and deliveries, you can update the IBase based on your organization’s business rules.

Praveen Peddibhotla

Praveen Peddibhotla is a certified SAP CRM professional with over 14 years of experience. He spent seven years in enterprise application implementations across multiple industries and is currently working with Infosys Management’s consulting services unit as a principal consultant. Praveen’s core expertise is in leading and deploying transformation-based SAP CRM solutions across the retail, consumer products, and healthcare industries. He also has experience in sales in the petro-chemical industry.

You may contact the author at praveen.peddibhotla@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Raghurama Gurrala

Raghurama Gurrala is an SAP CRM professional with more than 16 years of industry experience and eight years of SAP CRM experience. He has worked on various SAP CRM projects, including green field implementations, upgrades, enhancements, and steady state support projects. He has rich process experience across many industry verticals, including retail, high-tech, utilities, and pharmaceuticals. He is currently working with Infosys as Lead Consultant. You may contact Raghurama via email at gurralaraghu@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.