SAP Records Management can assist document business processes and manage electronic files. This innovative solution focuses on customer-specific processes. The service provider framework plays a prominent role in the system architecture.

The name SAP Records Management indicates only one aspect of the solution. In fact, SAP Records Management manages digital documents and structures them with an orientation toward business processes. But SAP Records Management also helps record business processes. After all, files in an SAP solution not only contain scanned documents or documents edited directly in the SAP solution; they also contain references to documents or other business objects that are created in the context of transactional applications. Such objects include postings in financial accounting, orders, opportunities and many more.

From the technical viewpoint of IT, these objects are the data records of a database. However, the information contained in a business object, such as a financial accounting documents, is not simply stored in a database record. As a rule, business objects are complex, and the information they contain is distributed across several database tables. Only the use of the SAP solution creates the context. Therefore, SAP Records Management manages not only documents, but also complex data records that complement the information in a file. In SAP terminology, these data records are called "business objects."

Application Programming and Modelling

If all the information - both the documents and the business objects - are collected structurally in a file, the file would document the flow of a business process. Workflow solutions, such as business workflow and records management, complement the information. The workflow solution helps direct and automate business processes. The processes modelled with the workflow solution can access files.

And, in the reverse direction, processes can be traced and logged from the files. This dual function of managing data and documents, and of controlling processes actively, is the decisive, competitive advantage of SAP Records Management.

What's Needed?

A Sustainable Infrastructure. Before development on SAP Records Management began, some basic questions had to be answered. What exactly is the necessary functional scope needed to manage electronic files? What are the contents of those files? How is their content structured and summarised? A dilemma appeared with these questions. Every definition of a specific functional scope or a specific record of objects remained unsatisfactory. It was impossible to predict which SAP objects would play an important role in records management or which objects in customer projects have to be considered. Accordingly, the first task was to develop a sustainable infrastructure for SAP Records Management - an infrastructure that would link almost any information object to another and then to link them to a uniform software solution.

.and Intuitive Operation

An additional trend also emerged. In a modern application, transactional applications and digitised documents quite properly exist next to each other. Dealing with digitised documents is usually much more intuitive. Processes can be improved, and tasks that users find unnecessary can be automated. For example, users want to fill out familiar forms directly on screen, and they want to write business letters and store them in a file without having to manually transfer the address data in the software solution to the letter. And companies want a workflow solution that can actively pass the corresponding work throughout an organisation. Many of these examples are already available as technical components in various SAP solutions, such as output control and print formatting (Smart Forms) for forms or in business workflow. Accordingly, SAP did not need to redevelop these kinds of elements for SAP Records Management. Naturally, the solution could be a success only if it were able to integrate existing components. These considerations outlined the context for SAP Records Management and gave birth to the idea of the service provider framework

The Service Provider Framework

The term "framework" is quite often used without any precision. Many applications that support some openness to customer modifications or modifications to higher levels of software already use the term "framework" for these abilities. Such techniques - user, customer, or application exits - are also found in SAP solutions as Business Add-Ins (BAdIs). However, the service provider framework encompasses significantly more than a record of published interfaces that can be used for customer-specific modifications. Consider the following example.

The programs for posting an order in SAP Sales & Distribution (SAP SD) and the programs for posting a vendor invoice in SAP Financials (SAP FI) use many of the same elements. These elements include checking for the existence of the company code entered by the user. But the programs exist only for themselves. That means that an SAP SD order per se cannot be related to a vendor document, but that the vendor document, for example, can appear as an explanatory appendix to the order. The tasks are treated differently in electronic file management. With electronic files, a concrete instance of order files must provide concrete visibility of orders, vendor invoices, or digitised documents in a common structure. Framework technology does more than just help solve integration questions in SAP Records Management. It also helps in other application contexts. For example, it can record disagreements and complaints in the context of financial accounting and document the process of creating quarterly and balance sheet processes. .

It is helpful to compare framework technology with the operating system of a computer. Various programs are installed on a computer; each has an entry in the system registry. For example, if a user clicks on a file in Windows Explorer, the operating system - on its own - finds the correct program to open the file, starts the program, passes the file on to another application, and closes it when the user finishes work. The operating system maintains control of the concrete program at all times. It can minimise it, end it, or place it into the foreground. The service provider framework works in a similar way. Programs (service providers) register themselves in the framework. To build upon the previous example, compare these service providers with the programs used to post SAP SD orders or vendor invoices. In some sense, service providers handle existing objects or objects from non-SAP applications. Concrete configuration variants can be performed on service providers in the application registry. For example, here users can define which concrete workflow definition is used for a process that can be started from a file for a concrete file type, such as an application procedure as part of a personnel file. New service providers - new programs - are also entered into the registry. At runtime, the service provider framework acts as a broker between the various programs involved in an SAP solution. In the case of SAP Records Management, files and the documents they contain communicate over the framework just as they do with vendor invoices or orders. In the process, files, orders, invoices, and documents must be considered as independent objects that exhibit an independent implementation.

Customising or enhancement by implementation?

Well-known companies such as the Deutsche Postbank,
KarstadtQuelle or the Westdeutsche Immobilien Bank already count on SAP Records Management. All these customers required that non-SAP components supplement SAP Records Management. For example, groupware systems or special systems to appraise property were linked to the file management solution. The strength of the framework approach is apparent here: The non-SAP programs simply had to be entered into the registry as services so that they could interact with existing objects. The solution is consistently open so it guarantees freedom to make modifications. The ability to enhance an application without customer-specific modifications is an additional advantage. Framework technology often proves superior to designs that offer extremely complex customising or multiple configuration options that cut standard software down to fit concrete customer needs. Often, it’s much simpler to implement enhancements for a specific customer situation with framework technology. The goals of a customer-specific implementation generally correspond to real customer needs much more strongly because the enhancements are created in collaboration with end users. The disadvantage? Enhancements that arise through implementation demand much more specific knowledge on the part of those involved in the project – much more than simple system configuration through customising. A decision about which approach better leads to the goal can be made only when dealing with real-world situation.

Additional applications based upon the service provider framework

Other SAP solutions take advantage of the service provider framework developed for SAP Records Management. For example, mySAP Financials processes disputes, such as complaints about invoices, and logs all the documents that arise during the dispute management process in a procedure file. mySAP Financials can also document the creation of a balance sheet and quarterly reports in a form that meets the requirements of the Sarbanes-Oxley Act, the new U.S. law requiring greater transparency in reporting. mySAP Customer Relationship Management also contains procedure management for processing service requests. And mySAP Public Sector provides a records management solution for official files. SAP is delivering more and more solutions that place objects in relation to each other with the service provider framework and that contain the preconfigured functionality of SAP Records Management. These solutions display added value of SAP Records Management that is based upon the framework design. The solution's openness does more than guarantee the creation of tailor-made customer solutions. Reuse of the framework and the objects realised in it in various SAP applications particularly profits customers who now encounter uniform architecture and uniform interfaces in various applications.