Sap Crm Functional Implementation Guide

Posted on -

As part of our commitment to data privacy and security, SAP has strengthened its global data-privacy policy. This website uses both functional and required.

This is a follow up to a blog I recently wrote on how to accelerate the delivery and reduce cost and risk of SAP CRM 7.0 projects. It is intended for somebody trying to understand in more detail the business value of SAP Best Practice content and tools. That could typically be a business process owner, an IT project manager or an SAP consultant. Our customer had had their ECC backend and some SAP CRM sales-based processes already running for 5 years. Our project scope included the implementation of two best practice scenarios: Interaction Centre Helpdesk and Service management. A number of changes to the standard scenarios as well as additional functionality were also implemented. Overall the project was implemented in 3.5 months and within a budget normally not achievable for an equivalent functional scope through traditional implementation methods.

I have chosen to list my insights from the perspective of different roles within the project. I will never stress enough that implementing SAP Best Practice is first and foremost a decision taken by the business then implemented by IT. The business unit manager His goal – Obtain business value through cost efficient rapid automation of non core competencies within the organisation and low risk process implementation. Best Practice scenarios are tried and tested scenarios by SAP. They are what I call “commodity” processes for non core competencies within the organisation. They represent the base layer processes within an organisation upon which one can build core competitive or core differentiating processes. Best Practice works best in the context of a green field SAP implementation which is not to say it can’t be used as well with existing customers as we have proven with this project.

The more the customer strays away from Best Practice scenarios the more time you spend on adjusting all content provided by Best Practice. That includes solution design, blueprint document and configuration guides. There is a tipping point beyond which the acceleration and cost benefits from implementing best practice is not valid anymore due to the exponential increase in project complexity.

CRM Best practice with ECC integration assumes you have used ECC Best Practice. As a result, implementing best practice scenarios with many backend integration points can seriously threaten the original promise of Best Practice if you are in a typical situation whereby you are installing these scenarios on top of existing non Best Practice ECC processes. Installing the standard Best Practice scenario during the mini blueprint phase allows the customer to quickly visualise the solution during the blueprint exercise which in turns reduces the risk of missed expectations later during the testing phase. The IT Project Manager His goal – Deliver business value through a quality project within budget and time, handover solution to support. The build phase was accelerated by loading configuration and demo master data using semi automated tools, business configuration sets and eCATT scripts.

The Best Practice configuration guides (see example) provided around 60-70% of our final deliverable which in turn reduced implementation costs. Business process procedure documents (See BPP example) represented very good accelerators and were used for delivering the mini-blueprint document, training documentation and Integrated test scripts. Time was saved as well for knowledge transfer to super users. Standard scenarios were quickly built in order to provide them with early visibility as well as to foster self-sufficiency. Installation effort estimates provided by SAP are fairly accurate for the build phase of Best Practice scenario. The semi-automated Solution Builder tool only saves time compared with manual implementation if a minimum number of scenarios are implemented. Otherwise the number of manual tasks is just too high to justify the initial time investment in setting up the tool.

Best Practice CRM scenarios with multiple integration points with ECC expect the relevant Best practice master data to be present in the ECC backend (organisation, customers, products, equipments.). As a result when implementing CRM Best practice on top of an unknown ECC system, one should plan time to understand master data like in a traditional SAP project. The SAP Consultant His goal – Help customer realise business value through the delivery of a quality solution within time and budget. Provide value-adding knowledge based on past project experiences. The Solution Builder tool provides the implementation consultant with a full chronological list of configuration and data load tasks per scenario. The tool ensures that the right order is followed as the scenario configuration cannot be completed otherwise (unless this control is manually overridden).

Sap Crm Functional Jobs

The Solution Builder tool provides direct links to configuration transactions for manual configuration tasks. This means acceleration as well as the ability to utilise a less skilled consultant. The Best Practice load for master data using eCATT is not compatible with a 2 client strategy with separate configuration and data clients.

Sap Crm Functional Implementation Guide

The Solution Builder tool loads all configuration and demo data in the same client. As a result when in a 2 client situation, you find yourselves having to recreate the demo master data manually which can be time consuming when considering all integration points. I hope these few insights will be useful to your own projects.

No difference. In the older versions, SAP used the term my SAP CRM. Now, the term my SAP is no longer used.

Difference between CRM Enterprise and CRM Mobile. I'm not entirely sure what you mean with 'CRM Enterprise'. However, CRM can be accessed in different ways: 1. CRM: users work directly on the SAP CRM system. Transactions created are directly saved in the CRM database.

CRM Mobile: users work on a mobile device (PDA, laptop, iPhone). Relevant data is synchronized from the CRM server to the mobile device of the user. Difference between transaction type and Customizing Header Level in CRM. No difference. The major difference between CRM & SD is as follows: CRM- It is being customer relationship management, it mainly focuses on pre sales & post sale activities to improve on customer relationship.

CRM Sale, it uses Opportunities management for creation of opportunities available with prospective customers. There is also quotation management & order management available for order creation. But it is optional as it can be created in SD too. CRM Marketing includes Lead creation, Campaign management for publishing material to customers or for lead generation, creation Target group of customers CRM also uses Activity management by creation of customer interaction Activities with customer.

CRM service uses Complaints & returns, Warranty Management, i base management, Service Order management. It also uses Account Management for managing vast data of customers & it is flexible compared to SD customer data. CRM also offers Interaction center capabilities to handle call center activities which is not available with SD.

Also, it offers internet Sales & Service for channel partner management & self service. All these above functionalities are not in SD as SD mainly being logistic module it is mainly used for order & delivery management. For more details visit.