SAP CRM

CRM manages interactions across the customer lifecycle: marketing campaigns, sales activities and opportunities, and customer service. It centralises customer information and interaction history so the business can market, sell and serve consistently.

• Marketing: campaigns and segmentation.
• Sales: leads, opportunities, quotations.
• Service: service requests, contracts, complaints.
• Interaction Center for contact handling.

This is the first thing to establish, because "SAP CRM" refers to at least three different things and they share very little.

SAP CRM, the on-premise product. The classic ABAP-based system, tightly coupled to the ERP core, with its own web client. Still running in a number of long-established landscapes and no longer where new implementations go.

SAP Customer Experience, the cloud suite. The current direction, assembled largely from acquisitions: Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud and Customer Data Cloud. These are separate products with their own interfaces and release cycles, and knowing one does not qualify you on the others.

Customer functionality inside S/4HANA. Sales in the ERP core covers orders, contracts and billing, and there is service functionality alongside it. For a business that mostly needs order taking rather than opportunity management, that can be enough on its own.

So when a role mentions CRM, the useful question is which product and which module of it. See SAP CS for the service side inside the core and SAP modules for how this fits the wider map.

The value of CRM is only visible end to end, so this is the flow worth tracing in whichever product is in front of you.

1. A lead is captured, from a campaign, an event or the website. It is a name and an interest, not yet a commitment.
2. Qualification turns it into an opportunity, with a value, a probability and a stage. This is what the sales pipeline is made of.
3. A quotation is produced, and this is the point where CRM must know real pricing and real availability, which usually means calling the ERP core.
4. Acceptance creates a sales order. In most landscapes that order lives in the ERP system, because that is where inventory, delivery and billing are.
5. Fulfilment and invoicing happen in the core, and the result flows back so the account team can see it.

Step three and four are where integration effort concentrates, and they are why a CRM project is rarely only a CRM project.

CRM integrates with the ERP core (orders, customers, billing) so front-office activity connects to back-office fulfilment. Modern deployments favour SAP CX (cloud) for sales, service and commerce, integrated with S/4HANA, while some run classic CRM or S/4HANA’s embedded customer-management capabilities.

The master data question decides the architecture. Customers exist in both systems, and something must be the source of truth. Usually the ERP core owns the sold-to party because that is where credit, billing and tax live, while CRM owns the contacts and the interaction history. Getting that division wrong produces two customer lists that diverge within months. See Ariba for the equivalent question on the supplier side.

One consequence worth planning for: reporting spans both systems. Pipeline lives in CRM, revenue lives in the ERP core, and the question everybody asks is how much of the pipeline converted. Answering it needs data from both, which is usually why a warehouse or an analytics layer ends up in the architecture whether or not it was in the original scope.

Every CRM implementation eventually becomes a master data project, so it is worth understanding the shape of the problem before meeting it.

The same customer exists in both systems and they hold different things about them. The ERP core holds what is needed to transact: legal name, tax number, credit limit, payment terms, delivery addresses, reconciliation account. CRM holds what is needed to sell: contacts, interaction history, opportunities, segmentation attributes, marketing consent.

Which system creates a customer is the first decision. Creating in CRM suits a sales-led process where prospects exist before they buy, and it means the record must reach the core before an order can be taken. Creating in the core suits businesses where customers arrive through contracts or existing relationships.

Which fields are mastered where is the second. A field that both systems can change will diverge, so each needs a single owner and the other side must be read-only for it.

How they are matched is the third. A shared identifier is straightforward, and matching on name and address is not, particularly across countries.

Where Business Partner is used in S/4HANA, the core already unifies customer and supplier, which simplifies one half of this. It does not solve the CRM boundary, which is a separate replication with its own rules. See SAP TM and warehousing for other modules that consume the same customer data downstream.

Learn CRM through its core processes, its master data and configuration, and its integration with the rest of the SAP landscape. Hands-on practice cements it.

More CRM implementations fail on adoption than on function, and the reasons are predictable enough to plan around.

Data entry burden. Every field a salesperson must complete is time not spent selling. If the system asks for twenty fields to log a call, calls stop being logged, and the pipeline data becomes fiction. The discipline is asking what each field will actually be used for, and removing the ones with no answer.

No return to the user. If the system only takes information and gives nothing back, it is a reporting tool for management wearing a sales tool's clothes. Account history, previous orders, open service calls and outstanding invoices visible in one place is what makes it worth opening.

Mobile reality. Field sales work from phones between meetings. A CRM usable only at a desk is used at the end of the week from memory, which is when data quality dies.

Management use. If leadership runs the pipeline review from a spreadsheet rather than the system, everyone learns which one matters.

None of these are configuration problems, which is why a technically successful CRM project can still fail, and why the people running it need to care about the sales process rather than only the software.

• Learning features, not the end-to-end process.
• Ignoring integration with finance and neighbouring areas.
• Skipping master data/configuration the process depends on.

• Answering "do you know SAP CRM" without asking which one. The products differ enough that the wrong answer is quickly exposed.
• Underestimating the integration. Pricing, availability and order creation all cross the boundary, and each is a real interface.
• Rolling out to a sales team that sees no benefit. CRM adoption fails on data entry burden more often than on function. See SAP BPC for the planning side that consumes the resulting pipeline.

• Building the pipeline reporting before fixing the data entry. Reports over data nobody maintains are worse than no reports, because they get believed.

Understanding the landscape is the start, and configuring one product's process end to end with its ERP integration is the part you do in the course.

The first question to ask whenever CRM comes up is which product somebody means. The on-premise system, the cloud suite and the sales functionality inside S/4HANA share a name and very little else, and the answer changes what the job is.