Download
1 / 54
680 likes | 990 Vues
SAP CRM Architecture Overview. Feb 6, 2009 Collective Elite. Executive Summary.
E N D
SAP CRM Architecture Overview Feb 6, 2009 Collective Elite
Executive Summary • The presentation provides a brief overview of SAP CRM technology required to fulfill the requirements for a CRM implementation. The standard CRM framework approaches provides the flexibility and extensibility to fit the specific business process and business scenarios for every implementation. • The design concept and the implementation summary for the frameworks, including data modeling, data synchronization, business object, business transaction, business process and web-based user interface, are discussed. In additions, based on the referenced implementations, solutions to centrally control the complex business logics and integrate the various devices into SAP are described for further brainstorming.
Content • Overview • SAP CRM Frameworks • Data Modeling • Data Synchronization • Business Object • Business Transaction • Business Process • Web-based User Interface • Solutions for • Complex Business Logic • Flexible Device Integration • Discussion
Overview – SAP CRM CRM supports you with conversion of your service strategy End-to-end, Industry Specialized Process
Overview – SAP CRM Landscape Firewall *Optional Component
Overview - Summary • SAP CRM’s architecture is a framework-based design to provide the flexibility and extensibility from the data modeling layer to the user interface layer. • SAP CRM uses various frameworks to provide the interactions and communications among different business applications within CRM or between CRM and external systems. • SAP CRM Web UI requires data binding among the business logic and the data modeling, and the visualization, known as MVC (Model-View-Controller). • SAP CRM is a SAP system providing web-based UI with a consistent user-oriented design for both look-and-feel and navigation. • SAP CRM uses BI as its standard reporting tool. • Enhancement and development in SAP CRM require strong object oriented backgrounds in both Abap stack and Java stack.
Data Modeling – Requirement • Need a single entry point for data model extension. That means, the extension of data model by adding new fields can be automatically populated into the related data tables, business logic, user interface, and the integration points to the external systems, e.g., BAPI, Middleware, BI, search engine. • Need to consistently adjust the data model extension for the data bindings from database tables to user interfaces, and among various business applications. • Need to automatically adjust the extended data models for different types of CRM user interface technology, e.g., SAP GUI, BSP, PC UI, ICWinClient, ICWebClient, and Web UI with minimal development efforts.
Data Modeling – Implementation • Custom specific data model can be extended to all related master data and the transaction data in SAP CRM. • The extended data model will be automatically adjusted for other dependent structures and database tables. • The extended data model can be accessible and configurable from the visual design tools of CRM’s Web UI. • Development is required to handle the data access, query, persistency, and validity check at the Business Object Layer. • Some developments may be required to consistently handle the enhancement to other integration components, e.g., middleware. • Changes into EEW should be controlled by a selected senior expert to avoid system failures or transport issues.
Data Synchronization – Requirement • Need to support initial data load from ECC or other external systems. • Need to support bi-directional or one-directional data synchronization for the delta changes. • Need to support different technologies for data synchronization between CRM and other external systems. • Need to assure the data consistent and the data integrity between CRM and ECC for the extension of data models.
Data Synchronization – Implementation • The middleware is the SAP standard solution to handle the delta changes for master data and transaction data between ECC and CRM. • Middleware provides functionality for object management, administration, monitoring, and recovery. • Other technologies can also be used for the initial load and the delta synchronization depending on considerations for the sync frequency, the data volume, the security considerations, the existing 3rd party tools and the implementation efforts. • For offline scenarios (Internet not accessible), the Interactive Form and the mobile solution can be used to manage the offline scenario and synchronize with server when connected to Internet.
Business Object – Requirement • Need a representation of business content for the visual presentation . • Needs the flexibility to model objects and relationships among them. • Needs to decouple business objects from the database layer to increase the reusability of the business objects. • Need a design tool to configure and model the business object easily. • Need a tool and a framework for data binding into the database tables and the layout binding to the presentation layer.
Business Object – Implementation • CRM Web UI requires data represented in the form of a business object defined within Business Object Layer (BOL). • The business objects and their relationships follow the concept of Entity-Relationship (ER) diagram. Each entity is then represented by a structure. • Every entity, fields, and relationships have unique identifier to locate the object within Web UI framework. • Navigation from one object to another should be modeled in BOL. • Development is required for the data binding if the data model is extended. • Development efforts are higher for non-standard BO due to the complexity to work with BOL,Genial, and the advanced custom container and controller. • Depending on the use cases and requirements, it is possible to adapt generic BSP applications into Web UI framework.
Business Transaction – Requirement • Need to provide a smooth and simple process for one business transaction to convert into another business transaction with minimal implementation efforts. • Need to provide a configurable business transaction environment that can to fit in various customer specific business scenarios with minimal implementation efforts. • Need to have the same services available and shared for all types of business transactions, including those created during an implementation. • Need to provide the central integration and data synchronization services between CRM and other external systems to assure the data consistency.
Business Transaction – Concept Example
Business Transaction – Implementation • One-order framework is the functional and technical foundation for majority of SAP CRM’s business transaction data. • The framework provides consistent maintenance UI, business logic, Application Programming Interface (API), performance improved index, and basic services such as partner determination, organization determination, status determination, date determination, text determination, output determination, attachment service, archiving, and integration to various engines, e.g., IPC, tax engine, billing engine, search engine, etc. • The framework provides central services for transition from one transaction type to another one, such as copy control and document flow to establish the complete life cycle of a business scenarios cross different transaction types. • The One-order framework provides various BAdI for enhancements.
Business Process – Requirement • Need to provide the interaction and communication cross different business transactions and different business objects. • Need to have generic tools to customize and define the interactions and communications under various conditions, e.g., change status/date, provide alert, email information, etc. • The triggering mechanism must be sufficiently flexible for different triggering conditions, including the supports for both manual and automatic processing. • Business rules may be required to have more complex access control that are not supported by Authorization, e.g., channel management. • Access control must be consistent among standard Authorization, additional business rules and search engines.
Business Process – Implementation • SAP CRM has provided tools for the business process control at different levels. • Workflows for approval based inter-process communication, • Actions for automatically or manually triggered the subsequent processes, and • Events for automatically triggered the subsequence processes for transaction data based on one-order framework. • SAP Access Control Engine provides a development framework to control the transaction access based on custom specific business rules. • SAP Search Engine TREX can manage the information security to synchronize the access control with CRM server. • SAP Web Service can be used as a separate business process integration approach to other SAP or non-SAP applications using standard http or web service.
Web UI Framework – Requirement • Need for a consistent look-and-feel and navigation patterns that can be learned by any user intuitively with minimal training. • Need a visual tool that can simplify the layout design for UI contents and navigation behaviors. • Need to decouple presentation layer, business logic layer and data model layers to improve the reusability of CRM functionality, hence, more flexible and configurable UI. • Need to allow views of multiple business transactions or business objects on the same screen. • Need to provide web-based UI to allow access from any internet enabled machine. • Need to improve personalization capability to improve the usability.
Web UI Framework – Development Process Requirement Tool Software Development
Web UI Framework – Implementation • Web UI provides a visual tool to control the layout content for different roles of users. • Web UI provides tools to access existing Business Objects through configuration. • Navigation and interaction among various UI components can be configured and enhanced within the Web UI framework. • Business roles can be define and configured to control the visibility and accessibility of different CRM functionality. • The data binding among the model, the view and the controller requires a consistent design and creation of the Business Objects. • More personalization functionality is available including drag-and-drop capability for various views. • Views and view sets are reusable components for UI layouts.
Complex Business Logic – Requirement • Complex business rules are identified on the following areas • Complex configuration and pricing rules, • Complex dispatching/routing rules for field technician, • Complex financial rules for asset valuation, rental/lease calculation, and • Complex calculation rules for equipment survey and cost analysis. • Hard coded approach can be used if the business logic do not change over time. There is no easy-to-use tool in CRM that can allow modifications of complex business logic on a daily or weekly base. • Most complex business logics are managed by business users. Currently, there is no standard UI tool to model and control any complex business logic easily.
Complex Business Logic – Implementation • For a business process where the SAP tool is available, the business logic should be modeled using the tool, e.g., content/rule based routing in Email Response Management System, or IPC. • For a business process where the business logic do not change over time, enhancement through hard codes can reduce the implementation efforts. • For a business process where the business logic changes frequently, the approach proposed here may be considered. • The referencee implementations of the solution have go-live for • TMHU (Toyota Material Handling Unit) in US for complex asset valuation and financial rules for leasing, and • LeasePlan in Australia for complex contract restrictions, input validation checks and financial rules.
Flexible Device Integration – Requirement • Need to support a large variety of external integration points among SAP systems, non-SAP systems and devices. • Need to continuously support the integration for existing devices and systems, and the future ones. • Need to support inbound and outbound processes. • Need to support push and pull mechanisms. • Need to support additional business logic to trigger subsequence processes inside SAP (inbound), or cross multiple devices/systems (outbound). • Need to support easy integration of future SAP enhancements and new functionality. • Need to consider performance issues.
