EP1609088A2 - Verfahren und vorrichtung zur computerimplementierten generierung und verwaltung von verträgen - Google Patents

Verfahren und vorrichtung zur computerimplementierten generierung und verwaltung von verträgen

Info

Publication number
EP1609088A2
EP1609088A2 EP02791689A EP02791689A EP1609088A2 EP 1609088 A2 EP1609088 A2 EP 1609088A2 EP 02791689 A EP02791689 A EP 02791689A EP 02791689 A EP02791689 A EP 02791689A EP 1609088 A2 EP1609088 A2 EP 1609088A2
Authority
EP
European Patent Office
Prior art keywords
contract
data
product
modules
core data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02791689A
Other languages
English (en)
French (fr)
Inventor
Roger Gutbrod
Gerhard Hafner
Hans-Dieter Scheuermann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SAP SE filed Critical SAP SE
Publication of EP1609088A2 publication Critical patent/EP1609088A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/174—Form filling; Merging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/186—Templates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/40—Processing or translation of natural language
    • G06F40/55—Rule-based translation
    • G06F40/56—Natural language generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Definitions

  • the present invention relates to a method and a device for the computer-implemented management of financial processes and in particular for the generation and management of contracts, preferably contracts in connection with financial services.
  • contracts between a provider and one or more customers are generated and managed using a computer.
  • the contracts to be generated and managed consist of core data for a contractual product and consist of one or more contract components, the core data being stored in a first storage unit and the contract components being stored in a second storage unit.
  • a selection of core data is made and a selection of contract modules is made, and the contract is generated electronically on the basis of the selection made by automatic generation and storage of electronic references (links; so-called pointers) to the selected core data and contract modules.
  • a so-called contract framework is provided, which helps to minimize the amount of data to be managed.
  • GUID Global Unified ID
  • I- dentification a contract with all the ingredients, that can be clearly linked to external data, whereby the external data can then also change without a link or link being lost. Coupled with a deposit of several, preferably three, holiday calendars, this results in a system that can be linked worldwide, in which domestic and foreign bookings can be made in particular by means of only one system.
  • Procedural limits can be set by the bank itself.
  • the basis of the error concept according to the invention is a uniform representation of the errors originating from individual contract modules.
  • a selection of the core data and a subsequent selection of the contract modules is carried out, with the basis of the selected core data, which contains information and rules relating to the contractual product, automatically checking the admissibility of the selection of individual contract modules.
  • This measure according to the invention makes it possible to automatically check the admissibility of the composition of individual contract modules when the contract is being designed. In order for the In ⁇ entfallt wall to the further testing of a landscaped contract.
  • the procedure according to the invention enables information and rules relating to the subject matter of the contract products, to carry out a central product configuration.
  • changes to the core data and / or the contract modules are carried out in the respective central storage unit.
  • This measure according to the invention minimizes the maintenance outlay, since changes in individual contract modules (for example, changes due to changes in the law) do not have to be carried out in every individual contract of existence, but can take place centrally.
  • a change in the core data and thus the properties of the contractual products can also be changed centrally with effect for all existing and future contracts.
  • the centrally made changes to the core data and / or the contract modules are assigned time and / or date details which indicate when a change should become valid. In this way, upcoming changes (e.g. changes to the law from the following year) can be made in advance and will be implemented automatically from the defined later point in time.
  • changes in the core data and / or contract modules are recorded over time and stored by means of links. This measure allows changes to be tracked and a contract history to be created.
  • a so-called contract framework is thus provided, with which the interaction between the outside world, the contract to be concluded and the contractual product is made possible on the basis of so-called core data and contract components. Any contracts between contracting parties can be mapped.
  • the invention is used in the field of finance, ie the provider is preferably a financial service provider such as a bank, and the contractual products are financial products such as checking accounts, savings accounts, credit cards, check cards etc.
  • An essential aspect of the invention is not to differentiate between different (product) sectors (such as giro, savings, credit etc.), but to allow a flexible structure through the central product configuration in the core data, which in particular also allows mixed forms, which is not possible with the current state of the art.
  • central functions are created by the contract framework for all contract modules and specializations (in the core data), such as time dependency, approval, change documents, direct input, control of the contract, jumps, product changes, copying contracts, central field modifications, authorization, blocking ,
  • the contract is clearly identified with an identification, in particular an identification number.
  • an identification in particular an identification number.
  • This is preferably a globally unique identification (GUID, Global Unified ID).
  • the contract which in the end consists of a link or link table, controls the "communication" with the product and ensures that all contract elements receive the properties defined in the product (i.e. in core data).
  • the contract receives the central attributes
  • three holiday calendars can be stored, which is particularly advantageous when calculating the value date of a booking.
  • a (booking) day is considered a public holiday if it is stored as a public holiday in one of the calendars.
  • the preferably three holiday calendars are the calendars, which are valid in the area of the organizational unit that manages the contract, the contracting party and the contract maintenance.
  • the contract module checks after contract generation whether the data taken over from the contractual product has been changed or not, and causes a link from product to contract module to be saved in a contract link table which contains the link between contract and contract module, if none Change was made, or a saving of the change as a new entry in a contract module table is prompted if a change has been made.
  • the invention extends of course to computer programs comprising program code means that are adapted pointed toward the computer program on a computer erfindungsgeterrorismes method and germedien computer readable tragermedien with stored thereon inventive computer programs and computer program products with such computer-readable ⁇ . Further advantages and refinements of the invention result from the description and the accompanying drawing.
  • FIG. 1 shows a target application landscape according to the invention in a schematic block diagram.
  • Figure 2 also shows a schematic block diagram of the components of the account management according to the invention.
  • FIG. 3 shows a schematic block diagram of the interaction of the components according to the invention within sales processing (where DispoOffice stands for Posting Control Office, DispoRules for Posting Control Rules, Posting Events for Posting Control Events or Posting Locks and DispoEvent Handler for Posting Lock Manager).
  • FIG. 4 shows a schematic block diagram of the structure of the posting lock office according to the invention.
  • FIG. 5 shows a schematic block diagram of an overview of the structure of the core application account management.
  • FIG. 6 illustrates in a schematic block diagram the embedding of the contract framework according to the invention in a usage environment.
  • FIG. 7 illustrates in a schematic block diagram the structural structure of the contractual framework according to the invention.
  • Figure 8 illustrates in a schematic block diagram the interaction of the components product, contract and contract module.
  • Figure 9 is an illustration of the mapping structures.
  • FIG. 10 shows a data model according to the invention.
  • FIG. 11 shows a development workbench for developing the business data tool according to the invention in a schematic representation.
  • FIG. 12 illustrates the dialog flow in the business data tool according to the invention.
  • Figure 13 illustrates the direct entry process
  • FIG. 14 illustrates the structure according to the invention oriented towards a contract module.
  • FIG. 15 shows a sequence sequence according to the invention when creating a contract.
  • Applications are information systems that solve a business primary task and are operational on their own. They hold the data and functions for solving the primary task, i.e. they are closely related activities.
  • An application communicates via defined interfaces.
  • An application is usually a buyable solution. Examples are the products Account Management, Profit Analyzer and Risk Analyzer.
  • Core applications are the formative applications of the application landscape. Accessory applications are supplementary applications that expand the functional scope of core applications (also several). They perform special tasks (examples are limit determination and scoring models) and have their own investment cycle independent of the core applications. This will create a larger xibility guaranteed in the adaptation to changing business policy goals.
  • the “technical architecture” describes the link between applications using middleware.
  • the “application architecture” describes the business content of individual applications and the logical interplay of individual application building systems. The blocks are called “components”.
  • the SAP applications are based on a shell model: At the core is the solution for the international use of the software, in addition, country-specific solutions are offered. Customer-specific additions can be connected in a further shell based on BTEs (Business Transaction Events) or BADIs (Business Add-Ins) or use of BAPIs (Business Application Programming Interfaces).
  • BTEs Business Transaction Events
  • BADIs Business Add-Ins
  • BAPIs Business Application Programming Interfaces
  • the individual applications are interchangeable and expandable. In particular, individual applications must not be too extensive. In an integrated SAP system landscape, individual applications must be deactivated and third-party applications can be integrated.
  • the bank decides on the desired range of standard functions by selecting the applications.
  • Each application must be expandable in such a way that it can be integrated into customer-specific application landscapes.
  • Applications communicate via public interfaces. Direct access to applications is not permitted. This ensures that data can be exchanged transparently between applications. A consistent database is guaranteed within an application. Unexpected risks due to unknown links and access can be minimized.
  • This communication structure enables direct data exchange between applications via public interfaces or indirect data exchange via public interfaces and business middleware.
  • the Posting Control Office can communicate with Account Management via public interfaces; the data exchange can also take place via middleware with its own business intelligence.
  • the middleware is a central element for realizing an application landscape. The middleware can perform two tasks:
  • the business management of business events requires a set of rules. This is defined as a business rule.
  • Cross-application process knowledge is required to define the business rules.
  • Elements of the business rules are process objects that initiate the call of business objects in the individual applications.
  • Example "contract creation” Here, for example, the business objects business partner, contract, card product are addressed.
  • the depiction of front ends and back ends with the help of middleware is a common practice Therefore a clear conception of the process control is necessary for reinvestments in these areas.
  • This construction also allows a gradual migration with successive activation of new applications.
  • the structure of the target application landscape shows "key functional areas" with which the banking management solution fields can be mapped. Within such an “area” there can be several applications. Not shown is the area that contains applications that banks need for the processing of their secondary processes, such as human resources management, asset accounting, material management, etc.
  • the basis for this structure is the goal of defining application areas at a high level, which serves a specific main purpose. This allows applications to be derived and clear responsibilities to be defined. Redundant applications and functions can be avoided.
  • the landscape is characterized by the following main tasks:
  • FIG. 1 shows a schematic diagram of a block diagram which represents a target application landscape for an account management according to the invention.
  • CRM stores data relating to the customer
  • operational data is data for existing customers
  • analytical data is data for new customer acquisition.
  • the bank control is located in the lowest fourth level.
  • Personalized one-way communication self-service terminals, Internet, telephone.
  • a party acts through data entry and receives a system-generated result.
  • the bank is not represented by employees, but by the system reaction.
  • CRM Customer Relationship Management
  • Sales processes are focused on the acquisition of new business deals, on the one hand from the customer base, and on the other hand through the acquisition of new customers.
  • product payments transaction / asset or liability business or commission business
  • customer group this process is complex, risky and profitable.
  • Service processes include customer support during the contract life cycle. Key points include: blocking requests for cards, address changes, complaints.
  • the contract management supports the creation of applications and offers as well as the conclusion of the contract including correspondence and electronic files.
  • the contract management shows customer-centered the contractual agreements between the bank and the customer.
  • the contracts can be of any complexity. An example is a loan agreement with repayment by life insurance and a guarantee from a castle. If the contract data is called up, it contains a selection of processing-related information that is supplemented by sales and service-oriented data. These contracts can be processed via several applications, i.e. the relationships between individual contracts or partial contracts are documented over the entire term. Customer-centered sales and service processes have their "anchor" in the contracts of contract management.
  • Activities and contact management make it possible to record, monitor and control activities with the customer. Furthermore, all contacts with the customer are documented and can be evaluated according to various characteristics.
  • the bank receives a "virtual" customer advisor who is available to all sales channels. For example, a complaint through the call center is also visible to the branch employees Information level guaranteed for all employees who are in contact with the customer. Customer activities via the Internet must be integrated accordingly in contact management.
  • the application area "Analytical CRM” comprises the analysis processes for exploiting business and customer potential and their transfer into operational implementation (e.g. marketing measures).
  • Analysis processes form an essential aspect of efficient customer relationship management. This includes processes such as cost information for controlling service, marketing and sales campaigns, customer-specific key figures for determining further customer potential, information about competitor products, etc.
  • Primary tasks of analytical CRM are:
  • CRM is of strategic importance in order to be able to offer complete solution competence.
  • the Transaction Banking application area contains the main components of payment transactions, account management (processing and inventory management), securities settlement and custody account management (processing and inventory management).
  • Account management is responsible for processing the legal portfolio in the sense of of money flows, i.e. it provides information about the bank's claims and liabilities to third parties.
  • the inventory management of the account management is the source for account statements and Saidenmitigaen.
  • the balances and sales items are kept in currency, i.e. kept unrated.
  • the inventory is the basis for external accounting, i.e. that the contract and sales data held here form the database for preparing the balance sheet.
  • Partial contracts are processed in Account Management. Partial contracts because a customer contract can be distributed across several processing applications due to its complexity. For example.
  • a product can consist of a "salary account with credit card and travel insurance". While the salary account is managed in account management, the card is processed by a provider and travel insurance at a partner.
  • the processing functionality means that automated prolongations or contract settlements take place. For operational CRM, this means that the current contract status must be known from the processing inventory.
  • Payment systems are traditionally country-specific solutions.
  • the payment transaction system takes over the formal checking and, if necessary, the consolidation and distribution of sales within the routes and formats used by the bank (internal and external routing).
  • Payment systems traditionally work in the so-called batch process.
  • dialog entry of payment orders is necessary, which can trigger immediate real-time booking in Account Management (additional application in payment transactions).
  • Highly perfor- mance-based communication must be ensured between payment systems and account management.
  • the administration and execution of standing orders is an additional application in payment transactions (payment order and standing order are within the account management).
  • payments order and standing order are within the account management.
  • this is also conceivable to do this as a supplementary component within Account Management (e.g. rebooking within Account Management).
  • the Transaction Banking application area contains, in addition to the solutions described above for the money side, solutions for securities transactions and derivative financial transactions. It can therefore be assumed that in As a rule, several inventory management systems are located in this application area.
  • the peculiarity of stucco management is that in the area of customer business it is an inventory management that does not affect the balance sheet.
  • the business partner solution is a central application for storing and managing all customer information. This solution is very closely linked to the solutions for operational and analytical CRM. Due to the process link, the business partner is maintained as part of these processes.
  • the business partner data represent an essential intangible asset for ede Bank, the value of which is determined by the quality of the data.
  • the business partner application merges the customer data of a bank across all applications. The most important data are:
  • the application area "Central Services” contains solutions that support the banking business of the other areas.
  • Collateral management is of particular importance due to the Basel decisions on credit risk coverage. By differentiating collateral, a bank can optimize the capital backing and thus reduce borrowing costs. Furthermore, knowledge of the collateral and its value date is a source for the acquisition of new creations. Collateral is usually recorded when the contract is initiated and concluded and is initiated from operational CRM. Collateral is released as part of the contract processing.
  • the management of collateral comprises firstly Safe ⁇ units that takes the bank and on the other collateral that the Bank itself. There is currently hardly any solution on the market for this second aspect. But need a bank's activities in the field of derivatives also the documentation and control of self-provided collateral.
  • the output management / outgoing correspondence application is a solution for optimal communication with the customer.
  • Different media such as mail, fax or email are required. There may be dependencies between the media. Furthermore, legal information deadlines must be observed (e.g. written account closure).
  • the invention supports the correspondence-oriented data selection and preparation. Further processing in a printing and shipping line is carried out by special providers.
  • the input management is located as a central service in the operational CRM.
  • the "Administrative Services" services are used for the proper organization of banking operations.
  • the existing system landscapes have historically grown at most banks.
  • the operative systems play a central role here and often supply downstream systems with pre-calculated results. This often results in different results and a complicated reconciliation and coordination process. The timely basis for decision-making can no longer be created.
  • bank management requirements for bank management are therefore single source of the database and method consistency across all evaluation methods.
  • the systems of a bank have to be organized differently than before.
  • the data required by the operational systems is made available at a data interface.
  • the Basic Main tenance Interface is a surface for processing individual functions.
  • This surface allows manual interventions in the otherwise largely automated processing. All functions in this area thus have a surface. An approval process ensures revision-compliant processing. A release tool that is integrated in the system in the individual applications is suitable for this.
  • This surface is provided by default and the authorization profiles for these workplaces can be defined by the user as roles, so that each user has a menu that exactly corresponds to his system requirements. These surfaces do not take into account customer organizational processes and processing optimizations.
  • the processing office ensures the process-controlled, i.e. workflow-supported processing of business incidents. There are various role-based forms within the office.
  • the control is supported by customer-specific settings of the SAP workflow and the associated release procedure (4 to 8 eyes principle). In comparison to the Basic Maintenance Interface, these offices have their own data storage (e.g. disposition orders). Crucial for an office integration is cross-application access to functions and data for the processing of business incidents. Furthermore, the results of the offline activities are to be transmitted to the central contact management so that a fully customer-centered view is possible across the bank.
  • the master for the partial contracts that are to be processed lies in account management, i.e. the valid contract dates and conditions are stored there.
  • product configuration is a central topic of a modern, future-oriented solution.
  • the product configuration takes place under three different aspects:
  • a product compared to the market can be divided into several sub-products for processing. • The configuration of products for bank management. These products generally have a different granularity than the settlement products. The data budget is also geared to the evaluation needs and not to the processing requirements.
  • connection to the processing (part) product is established by the product ID.
  • SAP provides the financial conditions of the account management via BAPIs to all other applications.
  • FIG. 2 uses a block diagram to illustrate the components of "Account Management".
  • Account Management has a structure that is neutral to the product lines. The development initially focuses on payment transaction products and services as well as passive and active products in retail banking.
  • the contract component is designed as a framework. It is therefore conceivable to use it as a central service for all applications in the target application landscape.
  • the contract manages all transaction-relevant master data in the account management via contract modules. Contracts use products as a template. The contract is aimed at extremely high-performance processing in bulk business.
  • Released contracts are usually passed on from the feeder systems to contract management via an interface (BAPI). During the contract period, however, it can be expected that directly from the trans saction Banking accessed the contract and changed data. Special contracts such as contracts for one-time accounts are created directly in Account Management. The contract knows the released and not released condition.
  • BAPI interface
  • the essential value creation of account management lies in the mapping and processing of transaction data.
  • the solution must be high-performing and incur low costs. Further requirements for the solution are real-time processing and 7 x 24 hour availability.
  • the sales management posts the individual sales in real time and controls a flexible balance update. The movements are shown on the account. Individual sales are payment items (half-sales), the basis of which are payment orders on the one hand and internal settlements on the other (e.g. interest charges). In addition, cash flows can be calculated and processed. Account management has an interface for accepting payment items (BAPI).
  • BAPI payment items
  • Sales management has no open item management with corresponding line item clearing.
  • Balance-based payment monitoring is conceivable, e.g. controls the receipt of funds in the course of a time deposit or the payment in installments for loans.
  • Incoming payment items are checked for blocks and limits as part of material planning.
  • a set of rules (Posting Control Rules) flexibly controls the reaction of the system based on specified parameters. For example, customer-specific, it can be determined whether sales should be scheduled or rejected directly.
  • the individual turnover is also the basis for the general ledger handover.
  • the data is also used to create a bank statement.
  • the sales update is true and without valuations.
  • Orders describe the actions that the account management should carry out immediately or in the future. This means that orders can be monitored in an appointment file. These orders can change one or more objects.
  • Account management processes orders. Examples are “contract cancellation” and “set block”. These orders are initiated from the outside via interfaces or internally by the application itself (e.g. term monitoring for renewal cards).
  • central applications such as the management of orders and payment orders, are provided as additional functions (cf. previous versions).
  • the card solution uses the same components of product configurator, contract and financial terms as account management.
  • account management uses the same components of product configurator, contract and financial terms as account management.
  • the administration of cards is a specialization of the general contract.
  • the integration of card management into account management is necessary because there are close links between cards and accounts (e.g. EC card, debit card).
  • SAP wants to keep the option open to process credit card accounts on the revenue side in the medium term.
  • the card administration must be a solution that can be used optionally by the customer, ie the card management must be switched off within the account management. Furthermore, the card management should be expandable in the medium term so that it can be used as a standalone solution if there is a corresponding need on the market. According to today's experience, there is a need for an account management system, including and exclusive of one Card administration. There are no requests for card administration alone.
  • the account management has a central financial statement administration for periodic work (eg end-of-day processing).
  • periodic work eg end-of-day processing
  • the bank is given the greatest possible flexibility when planning jobs.
  • Periodic work summarizes the functions that have to be carried out repeatedly on a certain date. These include the closing work cash concentration, account closing, interest compensation, account statement, the processing of orders, the daily closing including the updating of the bookers and reporting. Before the final work is carried out, the booking cut is made. Then all bookings are made with the following current date.
  • the Posting Lock Manager is responsible for temporary booking locks, i.e. he sets locks that are triggered by business incidents (posting lock events) and removes them after the underlying event has expired. Locks that are defined a priori on the product are not part of this component.
  • Figure 3 shows a block diagram to illustrate the interaction within the sales processing with the participation of the so-called "Posting Lock Manager”
  • Figure 4 shows a schematic block diagram of the structure of the so-called "Posting Control Office”.
  • the Posting Lock Manager accepts and determines Posting Lock Events from various input channels (back office, call center or counter systems and credit agencies) - according to its rules - the response of the system.
  • the solution runs in operational operations (receiving and processing events) largely without manual intervention.
  • possible forms of blocking procedures are the contract blocking (the contract as a whole and the blocking of partial functions), the blocking of cards in the portfolio as well as checks and other payment transaction forms.
  • the central business partner block which extends across all customer accounts, can be set on the business partner.
  • the Posting Lock Manager distributes the corresponding locks. So this rule can e.g. lead to an overdraft and direct debit block on all accounts and a block on all cards of the business partner concerned. This set of rules can be expanded to meet customer requirements.
  • Accessory applications for account management from the perspective of the application landscape are:
  • accessory applications complement or support the function or task of one or more core applications.
  • the Posting Control Office is an additional application for account management that is used to dispose of payment items for which a block or an unauthorized overdraft was found when an attempt was made to post.
  • Posting Control Rules Payment items that encounter booking obstacles (blocks) and accounts in which an unauthorized overdraft occurs are scheduled according to a set of rules (Posting Control Rules). This customer-specific, adjustable set of rules is managed in Account Management. If necessary, information about payment items that are not explicitly rejected in response to the Posting Control Rules is sent to the Posting Control Office by means of a posting control order, where their further processing (disposition) takes place either automatically or manually. Automatic disposition (repetitor) includes the automatic resubmission of payment items for posting to Account Management. Payment items for which there are only temporary obstacles to posting (e.g. limit problems) can be scheduled using the repetitor without manual intervention.
  • the duration and frequency of the resubmission as well as the final reaction (e.g. rejection) in the event of unresolved or newly emerging booking obstacles can be set.
  • Dynamic limit determination is a solution that is particularly necessary in automated mass business. This is an accessory application for account management that enables the individual bank to automatically set limits for the customer based on defined rules and input parameters.
  • the dynamic limit determination is programmed by the customer or in customer projects according to individual needs.
  • the limit determination communicates with inventory management, the business partner and the operational CRM.
  • This accessory application is responsible for extrajudicial dunning processes.
  • FIG. 5 shows a summary of the structure of the core application Account Management using a schematic block diagram.
  • the link table stores the assignment between the contract and the contract modules. Any number of assignments and the function of the assignment can be saved between the contract and the contract modules.
  • the assignments are time-dependent. Release and change documents are also saved here.
  • Various attributes are key fields for the link identification and time stamp, the contract identification, the name of the Contract module, identification for the module table etc.
  • contract module is to be understood as the sum of the code of a contract module, that is to say the coding which the contract module data and its process logic represent, for example, in dialog or store in the contract module table.
  • the contract module table is / are the database table (s) of the contract module (naturally does not apply to contract modules without their own database table).
  • Contract building data is the data of a contract module that is assigned to a contract. The data is normally stored in one row of the contract module table but also contract modules in which the data takes up several lines, and other contract modules do not have a contract module table at all, but contract module data do.
  • Each contract component is in turn encapsulated in its own development class, which leads to decoupling.
  • the contract modules in account management can be used across product types, so that fields that belong to a common (business) topic are grouped into a contract module.
  • generic contract modules and product type-specific contract modules (account contract modules, card contract modules, card community contract modules, account pool contract modules, etc.).
  • properties are of a general nature, such as the connection of the business partner, the contract conditions, limits, payment details, notice periods, correspondence requirements, related contracts, contract purpose, contract name and the like. included, while attributes such as bank statement, account closure, general ledger update, posting blocks, debit orders, balance confirmation, basic account data, alias names etc. are stored for the product type-specific contract modules.
  • Link product module or in short “product link” (cf. FIG. 10).
  • This entity belongs to the “contract” package and not to the separate product configurator 10.
  • the function of the product link is to create an assignment between a product (or a product version) and contract modules and to enable contract modules that do not make changes to the specifications of the product to not have to make any additional entries in the associated contract module table.
  • pointers to the contract module data belonging to a product version are stored (i.e. a link between the product and an associated contract module and its attributes).
  • pointers are transferred to the contract module so that they can be saved in the contract module link table.
  • the contract then points to the same contract module data as the product. There are thus product links between the product and the contract modules and contract links between the contract and the contract modules.
  • the invention enables the creation of "contracts via contracts", ie joint contracts such as card associations and the like can be managed as one contract.
  • Contracts and contract modules are application data (in contrast to the products and product attributes, which are so-called customization data) that cannot be transported.
  • the table of links between the product and the contract module data is therefore an application table, since no contract module data can be created when you create or configure a product, and therefore no link can be created between the product and the contract module data.
  • the product when a contract is created by a contract module, the product is not called directly, but instead the product link is called up and the contract module is linked to contract module data.
  • the contract module checks whether the data transferred from the product has been changed. If this is the case, the changed data is saved as a new entry in the contract module table. If the data has not been changed, however, only the link (product to contract module data) is saved in the contract link table (contract to contract module data), with the note that the contract is not the "owner" of the contract module data.
  • the contract module table remains unchanged.
  • the product link table is still empty. If the product link notices that it has not yet saved any links to this product or to this product version, it asks the contract modules concerned to get their "default values" from the associated product, to save them and to return a link to the stored data
  • the links or links to the entries - the product link remembers in its own lmktable .. Then, upon request, it gives the links to the individual contract modules as described.
  • Changing a contract is an individual change, i.e. Contract module data will be changed with a new entry in the corresponding contract structure table and a new link in the contract link table.
  • the contract When creating a contract (cf. FIG. 15), the contract calls the product link with "with". If the product link determines that it still has no links to this product version, it calls the relevant contract modules with "SetDefault”. The contract modules then get their default values from the product with "GetDefault”, save them and give them the link back to the product link. In the further course, the individual contract modules get their links with "Get” from the product link. This means that the "SetDefault” and "GetDefault” processes shown in bold in FIG. 15 only appear when a contract is first created for a specific product or a certain product version.
  • ISDST distribute data to participating application
  • DSAVB collect data when the application is owned
  • the “easy” product (version 1) is created and tested in the customer's customizing system.
  • the first contract (No. 1) for the product "easy” is created The contract tells the product link that it should prepare for the product "easy” (call the Init API)
  • the product link determines that there are no links to the "easy” product. It now calls up all contract modules with set_defaults-API, including the general ledger data. The general ledger data now fetches its default values from the "easy” product, save them and generate a key for this (HB_1). They return the key to the product link.
  • the product link stores all links between the "easy” product and the contract modules.
  • the contract modules call up the product link in order to get a link to their data.
  • the "General ledger data” contract module calls up the product link with Get_API and receives the HB_1 key.
  • the "General ledger data" contract module transfers its key HB_1 to the contract link table and tells it that it is not the contract (but the product) that is the owner of the data.
  • the product link gets the links of this product in its buffer
  • the contract modules call up the product link in order to get a link to their data.
  • the "General ledger data” contract module therefore calls up the product link with Get API and receives the HB 1 key.
  • the product link gets the links of this product in its buffer
  • the contract modules call up the product link in order to get a link to their data.
  • the "General ledger data” contract module calls up the product link with Get_API and receives the HB_1 key.
  • the "General ledger data” contract module saves the changed data under a new key (HB_2) and informs the contract link table of the new key and tells it that the contract is the individual owner of this data

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Human Resources & Organizations (AREA)
  • Artificial Intelligence (AREA)
  • General Engineering & Computer Science (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Technology Law (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Primary Health Care (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Facsimiles In General (AREA)
  • Telephonic Communication Services (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Electrotherapy Devices (AREA)
  • Steroid Compounds (AREA)

Description

Verfahren und Vorrichtung zur computeπmplementierten Generierung und Verwaltung von Vertragen
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zur computerimplementierten Verwaltung von Finanzprozessen und insbesondere zur Generierung und Verwaltung von Vertragen, vorzugsweise von Vertragen im Zusammenhang mit Finanzdienstleistungen.
Erfindungsgemaß werden ein Verfahren mit den Merkmalen des Anspruchs 1 und eine Vorrichtung mit den Merkmalen des Anspruchs 11 vorgeschlagen.
Demnach werden Vertrage zwischen einem Anbieter und einem oder mehreren Kunden computergestutzt generiert und verwaltet. Die zu erzeugenden und verwaltenden Vertrage bestehen aus Kerndaten zu einem vertragsgegenstandlichen Produkt und aus einem oder mehreren Vertragsbausteinen besteht, wobei die Kerndaten in einer ersten Speichereinheit abgespeichert sind und die Vertragsbausteine in einer zweiten Speichereinheit abgespeichert sind. Zur Gestaltung eines Vertrags wird eine Auswahl von Kerndaten vorgenommen und eine Auswahl von Vertragsbausteinen vorgenommen, und der Vertrag wird auf der Grundlage der vorgenommenen Auswahl elektronisch durch automatische Erzeugung und Hinterlegung von elektronischen Verweisen (Verknüpfungen; sogenannte Pointer) auf die ausgewählten Kerndaten und Vertragsbausteine generiert . Somit wird erfindungsgemaß ein sogenanntes Vertragsframework bereitgestellt, das dazu beitragt den zu verwaltenden Datenaufwand zu minimieren.
Wird zwischen einer Bank und einem Partner (Kunde, andere Bank) zu einem bestimmten Produkt (Konto, Kreditkarte etc.) ein Vertrag geschlossen, so erfolgt dies auf der Grundlage eines hinterlegten Vertragsmusters zu dem bestehenden Produkt mit einer selektiven Uberschreibmoglichkeit für Indi- vidualvereinbarungen. Im Rahmen des Vertragsframeworks erfolgt eine produktubergreifende Produkterzeugung und Produktverwaltung. Kerndaten des Vertrags wie Identifikationsnummer, vertragsgegenstandliches Produkt usw. sowie Vertragsbausteine für eine zentrale Datenverwaltung und Zuordnung werden bei der Einrichtung des Systems erzeugt und zugeordnet. Die Vertragsbausteine bilden die Grundlage für mögliche Vertrage, die aus Kerndaten und Vertragsbausteinen über die eingegebene Zuordnung zusammengestellt werden. Diese Zuordnung stellt sozusagen eine Produktdefinition dar. Bei allgemeinen Änderungen der Rahmenbedingungen, wie beispielsweise bei gesetzlichen Änderungen, erfolgt eine entsprechende Anpassung lediglich an einer Stelle und wird dann zentral in alle bestehenden und/oder zukunftigen Vertrage über die gegebene Zuordnung aufgenommen. Eine Bank kann somit relativ einfach weitere Vertragsbausteine kreieren und der Wartungsaufwand für bestehende Vertrage ist minimiert. Eine Rekonstruktionsmoglichkeit ist gegeben durch eine zeitliche Verlinkung von vorgenommenen Änderungen. Zukunftige Änderungen können auch unabhängig von Vertragsbausteinen vorgenommen werden. Es erfolgt eine Vorerfassung von Änderungen für das gesamte System.
Durch Benutzung eines weltweit eindeutigen Identifikations¬ systems (GUID = Global Unified ID) erfolgt eine interne I- dentifikation eines Vertrags mit sämtlichen Bestandteilen, die mit externen Daten eindeutig verlinkt werden kann, wobei sich die externen Daten dann auch andern können, ohne daß eine Verlinkung bzw. Verknüpfung verloren geht. Gekoppelt mit einer Hinterlegung von mehreren, vorzugsweise drei Feiertagskalendern ergibt dies ein weltweit verknupfbares System, bei dem insbesondere mittels lediglich eines Systems in- und auslandische Buchungen vorgenommen werden können .
Verfahrenslimite können von der Bank selbst eingestellt werden .
Bei einem Release-Wechsel wird aufgrund der definierten Schnittstellen eine gegebenenfalls vorhandene kundenspezifische Erweiterung beibehalten. Hierzu wird eine Erweiterung beim Prüfen abgerufen.
Grundlage des erfindungsgemaßen Fehlerkonzepts ist eine einheitliche Darstellung der von einzelnen Vertragsbausteinen stammenden Fehlern.
In vorteilhafter Ausgestaltung der Erfindung wird zunächst eine Auswahl der Kerndaten und anschließenden Auswahl der Vertragsbausteine vorgenommen, wobei auf der Grundlage der ausgewählten Kerndaten, die Informationen und Regeln zu dem vertragsgegenständlichen Produkt enthalten, automatisiert eine Überprüfung der Zulässigkeit der Auswahl einzelner Vertragsbausteine erfolgt. Diese erfindungsgemaße Maßnahme gestattet es, bereits bei der Gestaltung des Vertrags die Zulässigkeit der Zusammensetzung einzelner Vertragsbausteine automatisiert zu kontrollieren. Damit entfallt der Auf¬ wand einer zusätzlichen Prüfung eines gestalteten Vertrags. Zudem ermöglicht das erfindungsgemaße Vorgehen, in den Kerndaten Informationen und Regeln zu vertragsgegenstandli- chen Produkten zu hinterlegen, eine zentrale Produktkonfiguration vorzunehmen.
In besonders vorteilhafter Ausgestaltung der Erfindung werden ubertragsubergreifenden Änderungen der Kerndaten und/oder der Vertragsbausteine in der jeweiligen zentralen Speichereinheit vorgenommen. Durch diese erfindungsgemaße Maßnahme wird der Wartungsaufwand minimiert, da bei Änderungen in einzelnen Vertragsbausteinen (bspw. durch Geset- zesanderungen bedingte Änderungen) nicht in jedem einzelnen Existenzvertrag vorgenommen werden müssen, sondern zentral erfolgen können. Auch eine Änderung der Kerndaten und somit Eigenschaften der vertragsgegenstandlichen Produkte lassen sich auf diese Weise zentral mit Auswirkung für samtliche bestehenden und auch zukunftigen Vertrage andern. Vorteilhafterweise werden die zentral vorgenommenen Änderungen der Kerndaten und/oder der Vertragsbausteine Zeit- und oder Datumsangaben zugeordnet, die angeben, ab wann eine Änderung Gültigkeit erhalten soll. So lassen sich bevorstehende Änderungen (bspw. Gesetzesanderungen ab dem Folgejahr) bereits im vorhinein durchfuhren und werden ab dem definierten spateren Zeitpunkt automatisch umgesetzt.
In weiterer vorteilhafter Ausgestaltung der Erfindung werden Änderungen in den Kerndaten und/oder Vertragsbausteinen zeitlich erfaßt und durch Verknüpfungen hinterlegt. Diese Maßnahme gestattet eine Ruckverfolgung von Änderungen und die Erzeugung einer Vertragshistorie.
Erfindungsgemaß wird somit ein sogenanntes Vertragsframework bereitgestellt, mit dem das Zusammenspiel zwischen der Außenwelt, dem zu schließenden Vertrag und dem vertragsgegenstandlichen Produkt anhand von sogenannten Kerndaten und Vertragsbausteinen ermöglicht wird. Es können beliebige Vertroge zwischen Vertragspartnern abgebildet werden. Vor- zugsweise findet die Erfindung Anwendung im Bereich des Finanzwesens, d.h. bei dem Anbieter handelt es sich vorzugsweise um einen Finanzdienstleister wie eine Bank, und die vertragsgegenstandlichen Produkte sind Finanzprodukte wie Girokonto, Sparkonto, Kreditkarte, Scheckkarte etc. Ein wesentlicher Aspekt der Erfindung besteht darin, nicht zwischen verschiedenen (Produkt-) sparten (wie Giro, Spar, Kredit etc.) zu unterscheiden, sondern durch die zentrale Produktkonfiguration in den Kerndaten einen flexiblen Aufbau zu gestatten, der insbesondere auch Mischformen zulaßt, was beim derzeitigen Stand der Technik nicht möglich ist.
Erfmdungsgemaß werden zentrale Funktionen von dem Vertragsframework für alle Vertragsbausteine und Spezialisierungen (in den Kerndaten) erstellt, wie bspw. Zeitabhangig- keit, Freigabe, Anderungsbelege, Directinput, Steuerung des Vertrags, Absprunge, Produktwechsel, Kopieren von Vertragen, zentrale Feldmodifikationen, Berechtigung, Sperren.
Erfmdungsgemaß wird der Vertrag eindeutig mit einer Identifikation, insbesondere einer Identifikationsnummer, identifiziert. Dabei handelt es sich vor vorzugsweise um eine weltweit eindeutige Identifikation (GUID, Global Unified ID) .
Der Vertrag, der im Endeffekt aus einer Link- bzw. Verknup- fungstabelle besteht, steuert die „Kommunikation" mit dem Produkt, und sorgt dafür, daß alle Vertragsbausteine, die in Produkt (d.h. in Kerndaten) definierten Eigenschaften erhalten.
Insbesondere erhalt der Vertrag die zentralen Attribute
Produkttyp ProduktInversion Wahrung
Status
Feiertagskalender .
In vorteilhafter Ausgestaltung der Erfindung sind drei Feiertagskalender hinterlegbar, was insbesondere bei der Berechnung des Valuta-Datums einer Buchung von Vorteil ist. Ein (Buchungs-) tag gilt dann als ein Feiertag, wenn der in einem der Kalender als Feiertag hinterlegt ist. Die vorzugsweise drei Feiertagskalender sind die Kalender, die jeweils in dem Bereich der Organisationseinheit, die der Vertrag verwaltet, der Vertragspartner und der Vertragswahrung gültig sind.
In weiterer vorteilhafter Ausgestaltung der Erfindung prüft der Vertragsbaustein nach Vertragsgenerierung, ob die von dem vertragsgegenstandlichen Produkt übernommenen Daten geändert wurden oder nicht, und ein Abspeichern einer Verknüpfung von Produkt zu Vertragsbaustein in einer Vertragslinktabelle, die die Verknüpfung zwischen Vertrag und Vertragsbaustein enthalt, veranlaßt falls keine Änderung vorgenommen wurde, oder ein Abspeichern der Änderung als neuen Eintrag in eine Vertragsbausteintabelle veranlaßt falls eine Änderung vorgenommen wurde.
Die Erfindung erstreckt sich selbstverständlich auch auf Computerprogramme mit Programmcodemitteln, die dazu geeignet sind, bei Ablauf des Computerprogramms auf einem Computer ein erfindungsgemaßes Verfahren auszufuhren, sowie auf computerlesbare Datentragermedien mit darauf abgespeicherten erfindungsgemaßen Computerprogrammen und auf Computerprogrammprodukte mit derartigen computerlesbaren Datentra¬ germedien . Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, daß die vorstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand eines Ausfuhrungsbeispieles in der Zeichnung schematisch dargestellt und wird im folgenden unter Bezugnahme auf die Zeichnung ausfuhrlich beschrieben.
Figur 1 zeigt in schematischer Blockdarstellung eine er- findungsgemaße Ziel-Applikationslandschaft .
Figur 2 zeigt ebenfalls in schematischer Blockdarstellung die Komponenten des erfindungsgemaßen Account Managements .
Figur 3 zeigt in schematischer Blockdarstellung das Zusammenspiel der erfindungsgemaßen Komponenten innerhalb der Umsatzverarbeitung (wobei DispoOffice für Posting Control Office, DispoRules für Posting Control Rules, Dispo Events für Posting Control Events bzw. Posting Locks und DispoEvent Handler für Posting Lock Manager steht) .
Figur 4 zeigt in schematischer Blockdarstellung den Aufbau des erfindungsgemaßen Posting Lock Office.
Figur 5 zeigt in schematischer Blockdarstellung eine U- bersicht über die Struktur der Kernapplikation Account Management. Figur 6 veranschaulicht in schematischer Blockdarstellung die Einbettung des erfindungsgemaßen Vertragsframeworks in eine Nutzungsumgebung.
Figur 7 veranschaulicht in schematischer Blockdarstellung den strukturellen Aufbau des erfldungsgemaßen Vertragsframeworks .
Figur 8 veranschaulicht in schematischer Blockdarstellung das Zusammenspiel der Komponenten Produkt, Vertrag und Vertragsbaustein.
Figur 9 ist eine Darstellung der Zuordungsstrukturen.
Figur 10 zeigt ein erfindungsgemaßes Datenmodell.
Figur 11 zeigt in schematischer Darstellung eine Development Workbench zur Entwicklung des erfindungsgemaßen Business Data Tools.
Figur 12 veranschaulicht den Dialogablauf in dem erfmdungsgemaßen Business Data Tool.
Figur 13 veranschaulicht den Direkteingabeablauf.
Figur 14 veranschaulicht die auf einen Vertragsbaustein ausgerichtete erfindungsgemaße Struktur.
Figur 15 zeigt einen erfmdungsgemaßen Sequenzablauf beim Anlegen eines Vertrags.
Zunächst wird im folgenden das technische Umfeld der Erfindung beschrieben. Die Anmelderin der vorliegenden Patentanmeldung hat in Zusammenarbeit mit internationalen Banken und Beratungshau- sern eingehende Markt- und Wettbewerbsanalysen durchgeführt, deren Ergebnisse sich in den heutigen Softwarelosungen der Anmelderin und in den Weiterentwicklungsprojekten widerspiegeln. Auf Grundlage dieser Zusammenarbeit wurde in den letzten Jahren eine Ziel-Applikationslandschaft für Banken entwickelt, die sich an den Bedurfnissen der internationalen Finanzmarkte orientiert. Die einzelnen Applikationen dieser Softwarearchitektur stellen Losungen und integrale Losungsbestandteile der sogenannten e-busmess so- lution mySAP Banking dar. Im wesentlichen laßt sich mySAP Banking in die Bereiche Core Banking, SEM für Banken und CRM für Banken unterteilen.
Applikationen sind Informationssysteme, die eine betriebswirtschaftliche Primaraufgäbe losen und für sich allein einsatzfahig sind. Sie halten die Daten und Funktionen zur Losung der Primaraufgabe, d.h. sie bundein in einem engen fachlichen Zusammenhang stehende Aktivitäten. Eine Applikation kommuniziert über definierte Schnittstellen. In der Regel stellt eine Applikation eine kaufbare Losung dar. Beispiele sind die Produkte Account Management, Profit Ana- lyzer und Risk Analyzer.
In den folgenden Ausfuhrungen werden Applikationen in Kernapplikationen und Zubehorapplikationen gegliedert:
Kernapplikationen sind die pragenden Applikationen der Applikationslandschaft. Zubehorapplikationen sind ergänzende Applikationen, die den Funktionsumfang von Kernapplikationen (auch mehreren) erweitern. Sie erfüllen Spezialaufgaben (Beispiele sind die Limitermittlung und Scoringmodelle) und verfugen über einen eigenen Investitionszyklus unabhängig von den Kernapplikationen. Hierdurch wird eine größere Fle- xibilitat in der Anpassung an sich verändernde geschaftspo- litische Ziele gewährleistet.
Die Applikationslandschaft der e-busmess solution mySAP Banking beschreibt die wesentlichen Applikationen, die für das Betreiben des Bankgeschäftes notwendig sind. Die Applikationen stehen in einem betriebswirtschaftlich-logischen Zusammenhang .
Die "Technische Architektur" beschreibt die Verknüpfung zwischen Applikationen durch eine Middleware. Die "Applika- tionsarchitektur" beschreibt den betriebswirtschaftlichen Inhalt einzelner Applikationen und das logische Zusammen- spiel einzelner Applikationsbausteme . Die Bausteine werden als "Komponenten" bezeichnet.
Die Applikationen der SAP sind nach einem Schalenmodell aufgebaut: Im Kern befindet sich die Losung für den internationalen Einsatz der Software, ergänzend hierzu werden landerspezifische Losungen angeboten. Kundenmdividuelle Ergänzungen können in einer weiteren Schale auf Basis von BTEs (Business Transaction Events) bzw. BADIs (Business Add-Ins) oder Nutzung von BAPIs (Business Application Programming Interfaces) angeschlossen werden.
Folgende Anforderungen werden seitens Finanzinstituten und Banken an Applikationen gestellt:
• Kundenzentrierte und vertriebswegeneutrale Unterstützung der Sales-/Servιce-Prozesse .
• Schnelle Reaktionsmoglichkeit bei Systemanforderungen für die Abbildung von neuen Produkten.
• Integrationsmoglichkeit neuer Geschaftsprozesse .
• Produktspartenneutrale Abwicklung von Vertragen sowie einheitliche Bestandsführung. • Integration und Konsistenz von interner und externer Rechnungslegung.
Folgende Anforderungen werden an die Applikationslandschaft gestellt
• Flexible Modernisierung der Applikationslandschaft über Jahre hinweg (in Abhängigkeit vom Investitionszyklus der Applikationen) .
• Schnelle Reaktionsmoglichkeiten auf sich ändernde Ge- schaftsmodelle (z.B. Outsourcing, Insourcing) .
• Kundenindividuelle Erweiterungsfahigkeit ohne Modifikation der Standardlosung.
• Unterstützung von unterschiedlichen Migrationsszenarien.
• Flexible Integration in bestehende Applikationslandschaften bei Banken.
• Reduzierung der Schnittstellenkomplexitat durch integrierte Verarbeitung innerhalb der SAP-Applikationslandschaft .
Daraus folgt für die angestrebte Applikationslandschaft:
• Die einzelnen Applikationen sind austauschbar und erweiterbar. Insbesondere dürfen einzelne Applikationen nicht zu umfangreich sein. In einer integrierten Systemlandschaft der SAP müssen einzelne Applikationen deaktiviert und fremde Applikationen integriert werden können.
• Die Bank entscheidet durch die Auswahl der Applikationen über den gewünschten Umfang an Standardfunktionen.
• Jede Applikation muß so erweiterbar sein, daß eine Integration in kundenindividuelle Applikationslandschaf- ten durch die SAP, von zertifizierten Partnern oder auch vom Kunden selbst entwickelt werden kann.
Eindeutige Zuständigkeit von Applikationen
Betrachtet man zentrale Bankprozesse, so lassen sich hieraus verschiedene Aufgaben und Informationsbedurfnisse ableiten. Diese unterschiedlichen Anforderungen stehen teilweise in Widerspruch zueinander und verhindern die optimale Ausgestaltung einzelner Losungen. So ist eine kundenzentrierte Prozeßbearbeitung die Anforderung der Vertriebs- und Service-Organisation an eine Losung. Die kostensenkende Abwicklung von Vertragen und Konten erfolgt hingegen vertragsorientiert. Die interne und externe Rechnungslegung richtet die Prozesse wiederum an rechtlichen und organisatorischen Bedingungen aus.
Applikationen kommunizieren über öffentliche Schnittstellen (Public Interfaces). Direkte Zugriffe auf Applikationen sind nicht zulassig. Hierdurch ist gewahrleistet, daß der Datenaustausch zwischen Applikationen transparent erfolgen kann. Innerhalb einer Applikation ist eine konsistente Datenbasis gewahrleistet. Unerwartete Risiken aufgrund unbekannter Verknüpfungen und Zugriffe können minimiert werden. Durch diese Kommunikationsstruktur ist ein unmittelbarer Datenaustausch zwischen Applikationen über öffentliche Schnittstellen oder ein mittelbarer Datenaustausch über öffentliche Schnittstellen und eine betriebswirtschaftliche Middleware möglich. Beispielsweise kann das Posting Control Office über öffentliche Schnittstellen mit dem Account Management kommunizieren; der Datenaustausch kann aber auch über eine Middleware mit eigener Business-Intelligenz erfolgen . Die Middleware ist ein zentrales Element zur Verwirklichung einer Applikationslandschaft. Die Middleware kann zwei Aufgaben erfüllen:
• Technische Kommunikation (Services)
• Betriebswirtschaftliche Steuerung (Business Rules)
Für die technische Kommunikation gibt es verschiedene Losungen im Markt. Sie ermöglichen den Informationsaustausch zwischen verschiedenen Datenbanken in unterschiedlichen Formaten.
Die betriebswirtschaftliche Steuerung von Geschaftsvorfal- len erfordert ein Regelwerk. Dieses wird als Business Rule definiert. Zur Ausprägung der Business Rules ist applikati- onsubergreifendes Prozeßwissen erforderlich.
Elemente der Business Rules sind Prozeßobiekte, die den Aufruf von Businessobjekten in den Emzelapplikationen initiieren. Beispiel „Vertragsanlage": Hier werden z.B. die Businessobjekte Geschäftspartner, Vertrag, Kartenprodukt angesprochen. Die Abbildung von Frontends und Backends mit Hilfe von Middleware ist eine weitgehend gangige Praxis. Aber die Unterstützung von Backend-Prozessen zwischen Applikationen ist hier ebenfalls notwendig und noch wenig ausgeprägt. Deshalb ist bei Reinvestitionen in diesen Bereichen eine klare Konzeption der Prozeßsteuerung erforderlich.
Diese Konstruktion erlaubt auch eine stufenweise Migration mit sukzessiver Aufschaltung neuer Applikationen.
Für SAP hat das Zusammenspiel von Applikationen und Middleware eine strategische Bedeutung und wird derzeit aktiv ge- fordert. Im Rahmen der Analyse der technischen Machbarkeit spielt die Frage der Performance eine wichtige Rolle.
Die Struktur der Ziel-Applikationslandschaft zeigt „key functional areas", mit denen die bankbetriebswirtschaftlichen Losungsfelder abgebildet werden können. Innerhalb einer solchen „area" können mehrere Applikationen liegen. Nicht dargestellt ist jener Bereich, der Applikationen enthält, die Banken für die Abwicklung ihrer Sekundarprozesse benotigen, wie beispielsweise Personalwirtschaft, Anlagenbuchhaltung, Materialverwaltung etc.
Grundlage für diese Struktur ist das Ziel, Applikationsbereiche (areas) auf einer hohen Ebene zu definieren, die einem bestimmten Hauptzweck dient. Hierdurch lassen sich Applikationen ableiten und klare Zuständigkeiten definieren. Redundante Applikationen und Funktionen können vermieden werden. Geprägt ist die Landschaft von folgenden Hauptaufgaben :
• Applikationen zur kundenzentrierten Durchfuhrung von Sales- und Serviceprozessen.
• Applikationen zur Durchfuhrung und Kontrolle von Handelsprozessen.
• Applikationen zur vertragszentrierten hochperformanten Abwicklung.
• Applikationen zur rechtlich und organisatorisch induzierten Datenkalkulation und -aufbereitung für die Banksteuerung.
• Applikationen zur zentralen Bereitstellung von Daten, die die anderen Bereiche optimal unterstutzen, ohne dort redundant gefuhrt zu werden. Figur 1 zeigt in schematischer Darstellung ein Blockdiagramm, das eine Ziel-Applikationslandschaft für eine erfin- dungsgemaße Kontoverwaltung darstellt.
In der obersten Ebene des Blockdiagramms der Figur 1 befindet sich bei dem Feld „Point of Sales & Services" die Kundenschnittstelle zu der Verkaufs- und Servicestelle der Bank, wie beispielsweise dem Callcenter bei Telefonbanking oder einem Filialschalter.
In der darunter liegenden zweiten Ebene des Blockdiagramms werden unter „CRM" den Kunden betreffende Daten gespeichert, operative Daten sind dabei Daten zu bestehenden Kunden, analytische Daten sind Daten zur Neukundenaquise .
In der dritten Ebene des Blockdiagramms schließlich werden unter „Transaction Banking" Vertrage mit Kunden geschlossen. Diese Verträge betreffen Konten, Darlehen, Sicherheiten, Zahlungsverkehr, Depots usw.
In der untersten vierten Ebene befindet sich die Banksteuerung.
Jede Bank kommuniziert mit den Markten und benotigt hierfür Schnittstellen. Aus dieser Schnittstelle werden in der Regel wertschopfende Geschäfte und Geschaftsvorfalle generiert. Sie sind von zentraler Bedeutung für eine Bank, da sie auch das Erscheinungsbild repräsentieren. Selbstverständlich sind diese Schnittstellen vielfaltig. Als wesentliche Schnittstellen können genannt werden:
• Die personalisierte Zwei-Wege-Kommunikation:
Filialen, Callcenter, Abwicklungs-Office und Handels- raume. An dieser Schnittstelle ist eine Dokumentation und in der Regel die Bestätigung der Kommunikationser- gebnisse notwendig. Diese Form der Kommunikation ist in der Regel sehr personal- und kostenintensiv.
• Die personalisierte Em-Weg-Kommunikation : SB-Terminals, Internet, Telefon. Hier agiert eine Partei durch Dateneingabe und erhalt ein systemerzeugtes Ergebnis. In diesem Falle ist die Bank nicht durch Mitarbeiter repräsentiert, sondern durch die Systemreaktion .
• Systemgetriebene Zwei-Wege-Kommunikation: elektronische Handelssysteme, Clearingsysteme, Zahlungsverkehrs-systeme, Marktdatenemspielung, Datenaustausch mit Auskunfteien, Meldungen an Aufsichtsbehörden. Hier erfolgt ein manueller Eingriff durch Bankmitarbeiter nur bei Störungen.
Wahrend im Zahlungsverkehr schon in den letzten Jahrzehnten kontinuierlich an einem systemgetriebenen Datenaustausch gearbeitet wurde, hat für die Kundenbetreuung erst mit den Direktbanken ein innovativer Umbruch begonnen. Durch das Internet wurde der Umbruch beschleunigt und erfaßt nach dem Retailgeschaft (Online-Banking) nun auch das Wholesalege- schaft (z.B. Akkreditivabwicklung) und den Handel (z.B. Versteigerung von Emissionen; Zunahme elektronischer Handelsplatze) .
Diese neuen Schnittstellen müssen in die bestehende IT- Landschaft einer Bank integriert werden. Deshalb ist es sinnvoll, die Vertriebskanale so zu entkoppeln und zu kapseln, daß eine Anpassung an die sich schnell wandelnden Trends zeitnah möglich ist. Diese schnelle Reaktionszeit ist nur erreichbar, wenn möglichst wenig betriebswirtschaftliche Logik in den Frontends enthalten ist und in einem „vertriebswegeneutralen" Applikationsbereich liegt. In den Frontends sollten samtliche kundeninitiierten Ge- schaftsvorfalle erfaßt werden. Nur so sind Synergien und Prozeßoptimierungen einer modernen Softwarelosung nutzbar. Ferner ist die organisatorische Entscheidung, die Erfassung bestimmter Geschaftsvorfalle direkt durch den Kunden zuzulassen, leichter realisierbar (z.B. die inzwischen übliche Erfassung von Zahlungsauftragen am SB-Terminal oder über Internet bzw. Handy, die Bestellung von Reisezahlungsmitteln etc.).
Zwischen den Kommunikationsformen besteht eine Vernetzung. So können beispielsweise Telefonnutzer bei Problemen der Dateneingabe über einen Klick zu einem Callcenter weiterverbunden werden. Vor diesem Hintergrund wird es um so wichtiger, die Daten über alle Vertriebswege hinweg auf einem einheitlichen Stand zu halten, so daß alle Mitarbeiter über die Aktivitäten und die Historie des Kunden informiert sind.
Customer Relationship Management (CRM) umfaßt die gesamte Breite an Analysen, Aktivitäten und Dokumentationen im Rahmen von Kundenkontakten. Somit sind nicht nur Verkaufsprozesse und die zugehörige Marktbearbeitung relevant, sondern auch Services wahrend der Vertragsdauer. CRM ist für SAP mehr als eine Datenbank mit Marketingdaten. Es umfaßt operative Prozesse mit entsprechender Datenhaltung. Viele Funktionen sind in derzeitigen Marktlosungen redundant für jeden „Channel" vorhanden. Eine unmittelbare, vertriebska- nalunabhangige Verfügbarkeit von Geschäfts- und Vertriebsfunktionen ist das Ziel der SAP im Rahmen der CRM- Applikationen.
Im operativen CRM können folgende Prozesse definiert werden : Vertriebsprozesse (Salesprozesse) sind fokussiert auf die Akquisition neuer Geschäftsabschlüsse, zum einen aus dem Kundenbestand heraus, zum anderen durch Gewinnung neuer Kunden. Je nach Geschaftsfeld (Retail-/Wholessale) , Produkt (Zahlungsverkehr/Aktiv- oder Passivgeschaft bzw. Provisi- onsgeschaft) oder Kundengruppe ist dieser Prozeß unterschiedlich komplex, risiko- und ertragreich.
Serviceprozesse beinhalten die Kundenbetreuung wahrend des Vertragslebenszyklusses . Stichpunkte sind u.a.: Sperrwunsche von Karten, Adreßanderungen, Reklamationen.
Zur Abbildung der voranstehend benannten Prozesse sind folgende kundenzentrierte und vertriebswegeneutrale Losungen in diesem Applikationsbereich notwendig:
Das Vertragsmanagement unterstutzt die Antrags- und Angebotserstellung sowie den Vertragsabschluß inkl. Korrespondenz und elektronischer Akte. Das Vertragsmanagement zeigt kundenzentriert die vertraglichen Vereinbarungen zwischen Bank und Kunde auf. Die Vertrage können eine beliebige Komplexität erhalten. Als Beispiel sei hier ein Kreditvertrag mit Tilgung durch eine Lebensversicherung und Sicherstellung durch eine Burgschaft genannt. Werden die Vertragsdaten aufgerufen, so enthalten sie eine Auswahl abwicklungs- relvanter Informationen, die um Vertriebs- und serviceorientierte Daten ergänzt sind. Die Abwicklung dieser Vertrage kann über mehrere Applikationen erfolgen, d.h. die Beziehungen zwischen einzelnen Vertragen oder Teilvertragen werden über die gesamte Laufzeit dokumentiert. Kundenzentrierte Sales- und Serviceprozesse haben ihren „Anker" in den Vertragen des Vertragsmanagements.
Wichtige Prozesse: • Abschluß und Dokumentation der vertraglichen und vor- vertraglichen Kundenvereinbarungen .
• Inhaltliche und zeitliche Überwachung von vertraglichen und vorvertraglichen Bedingungen und Ereignissen (z.B. Auszahlungsvoraussetzungen; fehlende Legitimation; Prolongationstermine) .
Im Produktmanagement erfolgt die marktbezogene Konfiguration von Produkten. Dieser Prozeß erfolgt in Abstimmung mit dem Abwicklungsbereich einer Bank. Die Darstellung von Produkten in diesem Applikationsbereich konzentriert sich auf die Marktprasentation dieser Produkte, d.h. auf die variablen Ausprägungen, die ein Kunde wählen kann. Das Produkt muß im Retailgeschaft das Massengeschaft unterstutzen und ein einheitliches Produktportfolio und damit Vertragsportfolio gewahrleisten. Die Freiheitsgrade einzelner Produkte sind in der Regel begrenzt (z.B. hat ein Sparbrief in der Regel nur den Nominalbetrag und die Laufzeit als wahlbare Parameter) . Im Gegensatz zum Retailgeschaft ist das Whole- salegeschaft von hohen Freiheitsgraden innerhalb des Produktes geprägt, da die vertraglichen Vereinbarungen sehr individuelle Ausprägungen ermöglichen müssen.
Wichtige Services:
• Konfiguration der Produktparameter
• Produktkalkulation
Das Aktivitäten- und Kontaktmanagement ermöglicht es, Aktivitäten mit dem Kunden zu erfassen, zu überwachen und zu steuern. Ferner werden samtliche Kontakte mit dem Kunden dokumentiert und können nach verschiedenen Merkmalen ausgewertet werden. Die Bank erhalt einen „virtuellen" Kundenbetreuer, der allen Vertriebskanalen zur Verfugung steht. Z.B. ist eine Reklamation durch das Callcenter auch den Filialmitarbeitern sichtbar. Hierdurch ist ein einheitlicher Informationsstand für alle Mitarbeiter, die mit dem Kunden in Kontakt sind, gewahrleistet. Die Kundenaktivitaten über das Internet sind in das Kontaktmanagement entsprechend zu integrieren.
Der Applikationsbereich „Analytisches CRM" umfaßt die Analyseprozesse zur Ausschopfung von Geschäfts- und Kundenpotentialen und ihre Überführung in die operative Umsetzung (z.B. Marketingmaßnahmen).
Analyseprozesse bilden einen wesentlichen Aspekt eines effizienten Customer Relationship Managements. Dazu gehören Prozesse wie etwa Kosteninformationen zur Steuerung von Service-, Marketing- und Vertriebsaktionen, kundenspezifische Kennzahlen zur Ermittlung weiterer Kundenpotentiale, Informationen zu Wettbewerberprodukten etc. Primaraufgaben des analytischen CRM sind:
• Kundensegmentierung und -profliierung
• Kampagnen-Management
• Database-Marketing
Entsprechende Losungen unterstutzen die Bank bei der Planung und Durchfuhrung von Marketingmaßnahmen, begonnen bei der Segmentierung und Profilierung von Kundenbestanden bis zur Planung, Durchfuhrung und Kontrolle von Marketing- Kampagnen.
Das CRM ist erf dungsgemaß von strategischer Bedeutung, um eine vollständige Losungskompetenz anbieten zu können.
Applikationen zur Unterstützung von Handelsaktivitaten sind durch hohe Produktspezialisierungen gekennzeichnet. Spezielles Know-how und kurze Investitionszyklen prägen diese Losungen. Teilweise bilden die bestehenden Systeme für den Handelsraum Back-Office-Prozesse noch mit ab. Ein klarer Schnitt ermöglicht es, Abwicklungs- und Abrechnungsprozesse kostendegressiv verarbeiten zu können. Handelssysteme besitzen häufige rudimentäre Risikokontrollen. In Banken wird zunehmend die Anforderung gestellt, daß die Steuerungsinstrumente der Gesamtbanksteuerung direkt wertschopfend im Handelsbereich zur Verfugung gestellt werden.
Wichtige Prozesse in diesem Bereich sind:
• Produktkonfiguration für das Handelsgeschäft
• Vertragsmanagement für das Handelsgeschäft
• Limitmanagement für den Handel (Exposuremanagement)
Erfindungsgemaß wird kein Handelssystem bereitgestellt, sondern die Überwachung der Handelsaktivitaten vorgenommen.
Im Bereich "Transaction Banking" liegt folgende Ausgangslage vor: Die Globalisierung des Bankenmarktes bringt u.a. die Intention der Marktteilnehmer nach effizienten Betriebsgroßen zum Ausdruck. Um die angestrebten Skalierungsund Spezialisierungseffekte voll ausnutzen zu können, hat sich in den letzten Jahren eine teils innerbetriebliche, teils aber auch betriebsubergreifende Separation von Ver¬ triebs- und Transaktionsbank herausgebildet. Outsourcing- Losungen sind ein Beispiel dafür, daß die „Transaktionsbank" als eigenständiges Geschaftsmodell Erfolg hat. Doch auch bei einer Beibehaltung der Abwicklung im eigenen Unternehmen wird versucht, über Automatisierung und Zentralisierung die Abwicklung der Kundengeschafte zu optimieren.
Derzeit operieren Banken in ihren Applikationslandschaften mit einer Vielzahl von produkt- bzw. spartenspezifischen Systemen. Die Abwicklungen sind kostenintensiv und nicht skalierbar. Vereinheitlichung von Abwicklungsprozessen und weitgehende Produktspartenneutralitat im Rahmen des Bankgeschäfts sind wesentliche Anforderungen an diesen Applikationsbereich. Die Konfiguration von Abwicklungsprozessen soll durch Produktkonfigurationen beschleunigt und flexibili- siert werden. Die Möglichkeiten der Erweiterbarkeit der Software sind insbesondere unter Berücksichtigung des langen Investitionszyklussees von 15-20 Jahren in diesem Geschäftsbereich von entscheidender Bedeutung.
Für die SAP leistet dieser Applikationsbereich einen wesentlichen strategischen Beitrag zur Prozeßoptimierung in der internationalen Bankenwelt. Der Applikationsbereich Transaction Banking enthalt als wesentliche Bestandteile Zahlungsverkehr, Account Managemen t (Abwickl ung und Bestandsführung) , Wertpapiersettlemen t und Depotverwal tung (Abwickl ung und Bestandsführung) .
Dem Account Management obliegt die Abwicklung des juristischen Bestandes i.S. von Geldstromen, d.h. es gibt Auskunft über die Forderungen und Verbindlichkeiten der Bank gegenüber Dritten. Die Bestandsführung des Account Managements ist die Quelle für Kontoauszuge und Saidenmitteilungen. Die Salden und Umsatzposten werden wahrungsrein, d.h. unbewer- tet gehalten. Der Bestand ist die Grundlage für die externe Rechnungslegung, d.h. daß die hier gehaltenen Vertrags- und Umsatzdaten die Datenbasis für die Bilanzerstellung bilden.
Ferner erfolgt im Account Management die Abwicklung der (Teil-) Vertrage . Teilvertrage deshalb, weil sich ein Kundenvertrag durch seine Komplexität auf mehrere Abwicklungsapplikationen verteilen kann. Bspw. kann im operativen CRM ein Produkt aus einem „Gehaltskonto mit Kreditkarte und Reiseversicherung" bestehen. Wahrend das Gehaltskonto im Account Management verwaltet wird, erfolgt die Kartenabwicklung durch einen Provider und die Reiseversicherung bei einem Partner. Die Abwicklungsfunktionalitat bedeutet, daß automatisierte Prolongationen oder Vertragsabrechungen erfolgen. Das bedeutet für das operative CRM, daß es vom Abwicklungsbestand die aktuellen Vertragsstande erfahren muß.
Im Account Management werden nur rechtsgültige Vertrage gefuhrt, d.h. Simulationsgeschafte, Angebote und Antrage liegen außerhalb im operativen CRM.
Zahlungsverkehrssysteme sind herkommlicherweise landesspezifische Losungen. Das Zahlungsverkehrssystem übernimmt das formale Prüfen und ggf. das Verdichten und Verteilen von Umsätzen innerhalb der von der Bank genutzten Leitwege und Formate (internes und externes Routing) .
Zahlungsverkehrssysteme arbeiten herkommlicherweise im sogenannten Batchverfahren. Ergänzend ist eine Dialogerfassung von Zahlungsauftragen notwendig, die die sofortige Re- al-Time-Buchung im Account Management auslosen kann (Zusatzapplikation im Zahlungsverkehr) . Zwischen Zahlungsverkehrssystemen und Account Management ist eine hoch perfor- mante Kommunikation sicherzustellen.
Grundsatzlich ist im Rahmen der vorliegenden Erfindung die Verwaltung und Ausfuhrung von Dauerauftragen eine Zusatzapplikation im Zahlungsverkehr (Zahlungsauftrag und der Dauerauftrag liegen innerhalb des Account Managements) . Allerdings ist es auch denkbar, dies als eine ergänzende Komponente innerhalb des Account Management auszufuhren (z.B. Umbuchung innerhalb des Account Managements).
Der Applikationsbereich Transaction Banking enthalt neben den voranstehend beschriebenen Losungen für die Geldseite auch Losungen für Wertpapiergeschafte und derivate Finanztransaktionen. Somit kann davon ausgegangen werden, daß in der Regel in diesem Applikationsbereich mehrere Bestands- fuhrungssysteme liegen. Bei der Stuckeverwaltung (Wertpa- piersettle ent / Depotverwaltung) besteht die Besonderheit, daß es sich im Bereich des Kundengeschafts um eine Bestandsführung handelt, die nicht bilanzwirksam ist.
Die Geschaftspartnerlosung ist eine zentrale Applikation zur Speicherung und Verwaltung samtlicher Kundeninformationen. Diese Losung ist sehr eng verknüpft mit den Losungen zum operativen und analytischen CRM. Aufgrund der Prozeß- verknupfung wird der Geschäftspartner im Rahmen dieser Prozesse gepflegt. Die Geschaftspartnerdaten stellen für ede Bank einen wesentlichen immateriellen Vermogenswert dar, dessen Wert durch die Qualität der Daten bestimmt wird.
Die Geschäftspartner-Applikation fuhrt anwendungsubergrei- fend die Kundendaten einer Bank zusammen. Die wichtigsten Daten sind:
• Name und Anschrift des Geschäftspartners
• Ergänzende Daten in Abhängigkeit des Geschäftspartner- Typs (z.B. Geburtsdatum; Rechtsform) für alle Applikationsbereiche (z.B. Branchenschlussel für Marketingselektionen oder Meldewesen)
• Beziehungen (z.B. Kreditnehmereinheit; Konzernstrukturen)
• Rollen
• Legitimationsdaten
• Bonitatsdaten/Daten von Auskunfteien/Scoring-Ergeb- nisse/Marketingcluster
• Daten der Haushaltsrechnung oder Bilanzanalysen
• Gesamtobligo Beziehungen zwischen Geschäftspartnern können vielfaltig miteinander verbunden werden. Für die Bildung von Kreditnehmer- und Risikoeinheiten sind Funktionen vorhanden.
Kunden treten in definierten Rollen gegenüber einer Bank auf (z.B. Kontoinhaber, Kreditnehmer, Bürge). Aus diesem Grund hat die Geschäftspartner-Applikation die Rolle eines Kunden als tragenden Bestandteil.
Der Applikationsbereich "Zentrale Services" enthalt Losungen, die das bankwirtschaftliche Geschäft der anderen Bereiche unterstutzen.
• Sicherheitenverwaltung
• Output- und Inputmanagement/Korrespondenz
• Marktdaten, Wertpapierstammdaten, Info-Dienste
• Administrative Dienste: Berechtigungen, Organisationseinheiten
Die Sicherheitenverwaltung erhalt durch die Basler Beschlüsse zur Kreditrisikounterlegung eine besondere Bedeutung. Durch differenzierte Zurechnung von Sicherheiten kann eine Bank die Eigenkapitalunterlegung optimieren und somit Kreditkosten senken. Ferner ist die Kenntnis über die Sicherheiten und deren Valutierung eine Quelle zur Akquisition von Neugeschaffen. Die Erfassung von Sicherheiten erfolgt in der Regel bei Vertragsanbahnung und -abschluß und wird aus dem operativen CRM initiiert. Die Freigabe von Sicherheiten erfolgt im Rahmen der Vertragsabwicklung.
Die Verwaltung von Sicherheiten umfaßt einerseits Sicher¬ heiten, die die Bank entgegennimmt und andererseits Sicherheiten, die die Bank selbst stellt. Dieser zweite Aspekt ist derzeit in kaum einer Losung am Markt vorhanden. Aber Aktivitäten einer Bank im derivativen Bereich benotigen auch die Dokumentation und Steuerung selbst gestellter Sicherheiten.
Die Sicherheitenverwaltung ist ein wichtiger Bestandteil der Gesamtlosung.
Die Applikation Output-Management/ausgehende Korrespondenz stellt eine Losung für die optimale Kommunikation mit dem Kunden dar. Hierbei sind verschiedene Medien wie Postweg, Fax oder Email gefordert. Zwischen den Medien können Abhängigkeiten bestehen. Ferner sind gesetzliche Informationsfristen zu beachten (z.B. schriftlicher Kontoabschluß).
Neben der Wahl der Output-Medien ist eine hohe Funktionali¬ tat bei der Steuerung und Aufbereitung der papiergebundenen Korrespondenz notwendig. Stichworte sind hier: Zentrale Druckaufbereitung; Formularwesen und Portooptimierung.
Die Erfindung unterstutzt die korrespondenzorientierte Da- tenselektion und -aufbereitung. Die Weiterverarbeitung in einer Druck- und Versandstraße wird von Spezialanbietern durchgeführt .
Zum Input-Management/emgehende Korrespondenz gehört die Funktion „Elektronische Akte", sowie die generelle Verknüpfung von Dokumenten zu den Objekten Vertrag, Geschäftspart¬ ner, etc. Das Input-Management ist als zentraler Service im operativen CRM angesiedelt.
Hier handelt es sich um Losungen, die innerhalb einer Bank Informationen für mehrere Applikationen zur Verfugung stel¬ len .
Die Services "Administrative Dienste" dienen der ordnungsgemäßen Organisation des Bankbetriebes. Die bestehenden Systemlandschaften sind bei den meisten Banken historisch gewachsen. Dabei spielen die operativen Systeme eine zentrale Rolle und beliefern nachgelagerte Systeme oft mit schon vorgerechneten Ergebnissen. Hierdurch entstehen oft unterschiedliche Ergebnisse und ein kompliziertes Uberleitungs- und Abstimmungsverfahren. Die zeitnahe Entscheidungsgrundlage kann nicht mehr erstellt werden.
Anforderung an die Banksteuerung sind deshalb Single Source der Datenbasis und Methodenkonsistenz über alle Auswertungsverfahren. Um das Ziel der Abgestimmtheit von Daten und Methoden zu erreichen, sind die Systeme einer Bank anders zu organisieren als bisher. Insbesondere ist ein klarer Schnitt zwischen den operativen Systemen und den Anwendungen der Gesamtbanksteuerung zu ziehen. Dies entlastet die operativen Systeme von den nachgelagerten Prozessen der Gesamtbanksteuerung und zentralisiert gleichzeitig die Prozesse. Die von den operativen Systemen erforderlichen Daten werden an einer Datenschnittstelle zur Verfügung gestellt.
Die Banksteuerung betrifft nicht nur einzelne Institute, sondern ganze Konzerne. Gerade für die konzernweite Steuerung bringen Einheitlichkeit und Transparenz der Methoden sowie deren Darstellungen einen hohen Nutzen.
Folgende Fachbereiche werden erfindungsgemaß in eine Gesamtbanksteuerung integriert:
• Bilanzierung
• Profitability/Controlling
• Aktiv-/Passivsteuerung
• Risiko Controlling o Marktrisiko/Interne Modelle o Kredit-/Adressausfallrisiko o Kontrahentenrisiko o Landerrisiko
• Meldewesen
• Limitmanagement ( analytisch )
Das Transaction Banking hat folgende zentrale Aufgaben:
• Steuerung des Geld- und Stuckeverkehrs
• Abwicklung des Vertragbestandes
• Umsatzverwaltung und Fuhren des juristischen Bestandes geld- und stuckeseitig)
Der Losungsumfang des Transaction Banking wird im folgenden beschrieben .
Um die Funktionalitat des Transaction Banking in den Ge- samtzusammenhang der Applikationslandschaft einzubetten, wird zunächst auf folgende Aspekte eingegangen:
• Bearbeitungsmoglichkeiten
• Fuhrende Datenhaltung
• Produktkonfiguration und Finanzkonditionen
Bearbeitungsmöglichkeiten
Das Transaction Banking hat als eigener Applikationsbereich die Notwendigkeit, direkt bearbeitet werden zu können. Die Grunde hierfür können sein:
• Disposition und Limitmanagement zur Qualitätssicherung des Bestandes.
• Reklamationsbearbeitung, wie z.B. Gebuhrenkorrektur.
• Bestandsfuhrungsprozesse, wie z.B. Bearbeitung und Ab¬ stimmung von CpD-Konten. • Korrekturmaßnahmen aufgrund falscher oder fehlender Da- teneinspielung (z.B. Valutakorrekturen, Buchungs- Korrekturen) .
Traditionell spricht man von der Kontoführung als Ergänzung zum Kundenbetreuer. Die Erfindung ist derart gestaltet, daß die Implementierung des Kontofuhrers möglich ist. Diese Rolle umfaßt folgende zwei Arbeitsfelder:
Zum einen sind es Aktivitäten, die direkt nach außen zum Kunden wirken (z.B. Limitherabsetzung), und zum anderen Aktivitäten, die sich „ ohne Kundenkontakt,, nur auf den Bestand auswirken (z.B. CpD-Bearbeitung, Datenkorrekturen).
Es werden vorliegend zwei Arten von Bearbeitungsschichten im Transaction Banking unterschieden:
• Basic Maintenance Interface (BMI)
• Abwicklungs-Office (Account Management Office/AMO)
Bei dem Basic Main tenance Interface handel t es sich um eine Oberflache für die Bearbeitung einzelner Funktionen.
Diese Oberflache erlaubt manuelle Eingriffe in die ansonsten weitestgehend automatisierte Abwicklung. Alle Funktionen aus diesem Bereich verfugen damit über eine Oberflache. Ein Freigabeverfahren gewahrleistet eine revisionsgerechte Bearbeitung. Hierfür ist ein Freigabetool geeignet, das sy- stemseitig in die einzelnen Anwendungen eingebunden ist.
Diese Oberflache wird standardmäßig zur Verfugung gestellt und die Berechtigungsprofile für diese Arbeitsplatze können vom Anwender als Rollen definiert werden, so daß jedem Anwender ein Menü zur Verfugung steht, das genau seinen Erfordernissen an das System entspricht. Diese Oberflachen berücksichtigen keine kundenorganisatorischen Prozesse und Abwicklungsoptimierungen.
Das Abwickl ungs-Office (Account Management Office/ AMO) gewahrleistet die prozeßgesteuerte, d.h. workflow-unter- stutzte Bearbeitung von Geschaftsvorfallen. Innerhalb des Office gibt es verschiedene rollenbasierte Ausprägungen.
Die Steuerung wird durch kundenindividuell einstellbare Vorgaben des SAP Workflow und damit verbundene Freigabeverfahren (4- bis 8-Augen-Prinzip) unterstutzt. Diese Offices verfugen im Vergleich zum Basic Maintenance Interface über eine eigene Datenhaltung (z.B. Dispositionsauftrage). Entscheidend für eine Officeeinbindung ist ein applikations- ubergreifender Zugriff auf Funktionen und Daten für die Bearbeitung der Geschaftsvorfalle. Ferner sollen die Ergebnisse der Offlceaktivitaten an das zentrale Kontaktmanagement übermittelt werden, damit eine vollständig kundenzentrierte Sicht bankweit möglich ist.
Heute liegen in der Abwicklung häufig Prozesse, die nicht in diesen Bereich gehören (z.B. Vertragseroffnung auf Postweg) .
Ergänzend zeigen Marktstudien, daß es das Ziel von Banken ist, viele Back-Office-Prozesse um 70-80% alleine dadurch zu verschlanken, daß sie auf den Kunden selbst verlagert werden, wie es bereits im Internet-Banking möglich ist (z.B. Vertragseroffnung) . Denn möglichst effizient wird die Abwicklung erst dann, wenn der Bankkunde selbst Geschaftsvorfalle wie bspw. eine Kartensperre initiieren oder die Zahlungsauftragsdisposition selbst durchfuhren kann.
Führende Datenhaltung In jeder Applikationslandschaft darf es für die Daten nur einen „Master" geben, auf den andere Applikationen direkt zugreifen oder periodische Updates bekommen.
Der Master für die Teilvertrage, die abgewickelt werden sollen, liegt im Account Management, d.h. die gültigen Vertragsdaten und Konditionen sind dort hinterlegt.
Gleiches gilt für die Umsätze und Salden. Deshalb erfolgt auf dieser Basis die Datenbereitstellung für die Kontoauszüge und für ein Data Warehouse.
Inwieweit Applikationen Daten redundant halten müssen, wird stark von den Performance-Anforderungen bestimmt und hangt von der kundenindividuellen Situation ab.
Produktkonfiguration und Finanzkonditionen
Produktkonfiguration
Wie in der Ziel-Applikationslandschaft dargestellt, ist die Produktkonfiguration ein zentrales Thema einer modernen zu- kunftsfahigen Losung. Die Produktkonfiguration erfolgt dabei unter drei unterschiedlichen Aspekten:
• Die Produktkonfiguration im operativen CRM. Hier ist die Produktkonfiguration an den Marketing- und Vertriebsbedürfnissen orientiert.
• Die Abbildung des Abwicklungsproduktes mit allen ab¬ wicklungsrelevanten Steuerungsparametern innerhalb des Transaction Banking/Account Managements.
Ein Produkt gegenüber dem Markt kann hier in mehrere Teilprodukte für die Abwicklung aufgeteilt werden. • Die Konfiguration von Produkten für die Banksteuerung. Diese Produkte haben in der Regel eine andere Granula- ritat als die Abwicklungsprodukte. Auch der Datenhaushalt ist an den Auswertungsbedurfnissen und nicht an den Abwicklungsanforderungen ausgerichtet.
In den drei Hauptprozessen des Bankgeschäftes ist das Produkt unterschiedlich ausgeprägt, mit Ausnahme eines Bereiches: „Die Finanzkonditionen des Produktes". Aus diesem Grund werden die Finanzkonditionen ergänzend dargestellt.
Die Produktkonfiguration erstreckt sich letztlich über alle drei Applikationsbereiche. Es ist eine übergreifende Abstimmung zwischen den Applikationsbereichen im Rahmen einer neuen Produktimplementierung notwendig. Die Pflege der Produkte erfolgt in jedem Bereich für sich:
Im Transaction Banking findet die Produktpflege über das Customizing statt. Berechtigung und Freigabe sind über das Transportverfahren der SAP gesichert.
Die Verbindung zwischen dem Operativen CRM und dem Transaction Banking erfolgt bei der Anlage eines konkreten Vertrages mit einem Kunden über eine öffentliche Schnittstelle (BAPI). In der Schnittstelle werden mitgegeben:
• der Kunde
• die Produkt-ID
• sowie die individuellen Vertragsauspragungen.
Durch die Produkt-ID wird die Verbindung zu dem Ab- wicklungs (teil) produkt hergestellt.
Finanzkonditionen Die Finanzkonditionen sind Grundlage für die Zins- und Gebuhrenberechnungen. Dadurch haben sie eine besondere Bedeutung und müssen in jedem Applikationsbereich zur Verfugung stehen. Performancekritisch ist der Zugriff im Rahmen der Bestandsführung. Um die Einheitlichkeit der Konditionen u- ber die Grenzen einzelner Applikationsbereiche hinaus zu garantieren, stellt SAP die Finanzkonditionen des Account Managements über BAPIs allen anderen Applikationen zur Verfugung .
Figur 2 veranschaulicht anhand eines Blockdiagramms die Komponenten des „Account Managements". Das "Account Management" hat eine produktspartenneutrale Struktur. Im Fokus der Entwicklung liegen zunächst Zahlungsverkehrsprodukte und -Services sowie Passiv- und Aktivprodukte des Retail Banking.
Die Vertragskomponente ist als Framework konzipiert. Daher ist es denkbar, sie als zentralen Service für alle Applikationen der Zielanwendungslandschaft einzusetzen.
Es ist denkbar, daß der Vertrag und sein Framework zukunftig als zentraler Service für alle Applikationen der Zielanwendungslandschaft eingesetzt werden kann.
Der Vertrag verwaltet im Account Management über Vertragsbausteine alle abwicklungsrelevanten Stammdaten. Vertrage nutzen Produkte als Vorlage. Der Vertrag ist auf eine äußerst performante Abwicklung im Massengeschaft ausgerichtet.
Freigegebene Vertrage werden in der Regel aus den Vorsystemen an das Vertragsmanagement über eine Schnittstelle (BAPI) weitergegeben. Wahrend der Vertragslaufzeit kann aber damit gerechnet werden, daß auch direkt aus dem Tran- saction Banking heraus auf den Vertrag zugegriffen und Daten geändert werden. Besondere Vertrage wie z.B. Vertrage für CpD-Konten werden direkt im Account Management angelegt. Der Vertrag kennt den freigegebenen und nicht freigegebenen Zustand.
Für alle Vertragsdaten kann es in einer Applikationslandschaft nur einen „Master" geben. Dieser „Master" liegt für die Abwicklungsdaten im Account Management. Außerdem erfolgt die Abwicklung von Vertragen weitgehend automatisiert. Das heißt hier kennt man die aktuellen Vertragszustande (z.B. nach Prolongationen). Die Vertragsdaten werden an Schnittstellen zur Verfugung gestellt.
Zum Verständnis sei erwähnt, daß es naturlich auch Ver¬ tragsdaten gibt, die in anderen Applikationen verwaltet werden und dort als „Master" gefuhrt werden (z.B. Schufa- Kennzeichen, Verfugungsberechtigung) . Der zentrale Anker zum Zusammenfuhren aller Daten liegt im operativen CRM.
Wichtige Prozesse im Account Management sind:
Anlegen, Andern, Prolongieren, Kundigen, Stornieren und Auflosen von Vertragen. Hierbei werden auch entsprechende Buchungen angestoßen.
Es werden zwei Ausprägungen von Vertragen unterstutzt:
• Kontenvertrage
• Kartenvertrage (s. unten)
Die Unterstützung weiterer Vertragsparteien ist selbstverständlich möglich.
UmsatzVerwaltung In der Abbildung und Abwicklung von Bewegungsdaten liegt die wesentliche Wertschopfung des Account Managements. Die Losung muß hoch performant sein und geringe Kosten verursachen. Weitere Anforderungen an die Losung sind Realtime- Verarbeitung und 7 x 24 Stunden Verfügbarkeit.
Die Umsatzverwaltung bucht in Echtzeit die Einzelumsatze und steuert eine flexible Saldenfortschreibung . Die Abbildung der Bewegungen erfolgt am Konto. Einzelumsatze sind Zahlungsposten (Halbsatze) , deren Grundlage einerseits Zahlungsaufträge und anderseits interne Abrechnungen (z.B. Zinsbelastung) sind. Ergänzend können Cash flows berechnet und weiterverarbeitet werden. Das Account Management hat eine Schnittstelle zur Annahme von Zahlungsposten (BAPI).
Die Umsatzverwaltung kennt keine offene Postenverwaltung mit entsprechendem Einzelpostenausgleich. Es ist eine Zah- lungsuberwachung auf Saldenbasis denkbar, die z.B. den Eingang von Geldern im Zuge einer Festgeldanlage bzw. der Ratenzahlung bei Krediten steuert.
Eingehende Zahlungsposten werden im Rahmen der materiellen Disposition auf Sperren und Limite geprüft. Ein Regelwerk (Posting Control Rules) steuert flexibel die Reaktion des Systems anhand vorgegebener Parameter. So kann z.B. kunden- gruppenspezifisch bestimmt werden, ob ein Umsatz nachdisponiert oder direkt abgewiesen werden soll.
Systemreaktionen sind:
Buchen, Nachdisponieren, Nachbearbeitung, Ruckgabe, Abweisen, CpD-Buchung.
Der Einzelumsatz ist auch Basis für die Hauptbuchubergabe . Ferner dienen die Daten der Kontoauszugserstellung. Die Umsatzfortschreibung ist wahrungsrein und ohne Bewertungen. Auftrage beschreiben die Aktionen, die das Account Management sofort oder zukunftig ausfuhren soll. Das heißt, Auftrage können in einer Termindatei überwacht werden. Diese Auftrage können ein oder mehrere Objekte verandern.
Das Account Management verarbeitet Auftrage. Beispiele sind „Vertragsauflosung" und „Sperren setzen". Initiiert werden diese Auftrage von außen über Schnittstellen oder intern durch die Applikation selbst (z.B. Termmuberwachung für Erneuerungskarte) .
Als Zusatzfunktionen sind außerdem zentrale Anwendungen, wie die Da uera uftrags- und Zahl ungsa uftragsverwal tung, vorgesehen (vgl. voranstehende Ausfuhrungen).
Die Kartenlosung nutzt dieselben Komponenten Produktkonfi- gurator, Vertrag und Finanzkonditionen wie das Account Management. Somit handelt es sich bei der Administration von Karten um eine Spezialisierung des allgemeinen Vertrages. Die Integration der Kartenverwaltung in das Account Management ist notwendig, da es enge Verknüpfungen zwischen Karten und Konten gibt (z.B. EC-Karte, Debit-Card) . Insbesondere will sich SAP die Option offen halten, mittelfristig Kreditkartenkonten auch umsatzseitig abzuwickeln.
Die Kartenadministration muß eine Losung darstellen, die vom Kunden optional eingesetzt werden kann, d.h. die Kartenverwaltung muß innerhalb des Account Managements abschaltbar sein. Ferner sollte die Kartenverwaltung mittelfristig so weit ausbaufähig sein, daß sie als Einzellosung eingesetzt werden kann, wenn entsprechender Bedarf am Markt entsteht. Nach heutigen Erfahrungen besteht Bedarf an einem Account Managementsystem inklusive als auch exklusive einer Kartenadministration. Anfragen für eine alleinige Kartenadministration liegen noch nicht vor.
Das Account Management verfugt über eine zentrale Abschlußverwaltung für periodische Arbeiten (bspw. Tagesendverar- beitung) . Die Bank erhalt bei der Einplanung der Jobs größtmögliche Flexibilität. Unter periodischen Arbeiten sind die Funktionen zusammengefaßt, die zu einem bestimmten Termin wiederkehrend ausgeführt werden müssen. Dazu gehören die Abschlußarbeiten Cash Concentration, Kontenabschluß, Zinskompensation, Kontoauszug, die Abarbeitung von Auftragen, der Tagesabschluß einschließlich der Fortschreibung der Bucher und Reporting. Bevor die Abschlußarbeiten durchgeführt werden, wird der Buchungsschnitt vorgenommen. Danach erfolgen alle Buchungen mit dem folgenden Tagesdatum.
Externe Systeme zur Jobsteuerung können ebenfalls eingebunden werden.
Der Posting Lock Manager (Sperrverwaltung) ist zustandig für temporare Buchungssperren, d.h. er setzt Sperren, die durch Geschaftsvorfalle (Posting Lock Events) ausgelost werden, und hebt diese nach Ablauf des zugrundeliegenden Events wieder auf. Sperren, die a priori am Produkt definiert werden, sind nicht Teil dieser Komponente.
Figur 3 zeigt ein Blockdiagramm zur Veranschaulichung des Zusammenspiels innerhalb der Umsatzverarbeitung unter Beteiligung des sogenannten „Posting Lock Managers", und Figur 4 zeigt in schematischer Blockdarstellung die Struktur des sogenannten „Posting Control Office".
Der Posting Lock Manager nimmt von verschiedenen E gangs- kanalen (Back Office, Callcenter- oder Schaltersystemen und Auskunfteien) Posting Lock Events entgegen und bestimmt - gemäß seinen Regeln - die Reaktion des Systems. Die Losung lauft im operativen Betrieb (Entgegennahme und Verarbeitung von Events) weitgehend ohne manuelle Eingriffe ab. Im Account Management sind mögliche Ausprägungen von Sperrvor- gangen die Vertragssperre (der Vertrag insgesamt sowie die Sperrung von Teilfunktionalitaten) , die Sperre von Karten im Bestand sowie von Schecks und anderen Zahlungsverkehrsvordrucken. Am Geschäftspartner kann die zentrale Geschaftspartnersperre, die sich über alle Konten des Kunden erstreckt, gesetzt werden.
Meldet beispielsweise em Geschäftspartner Vergleich an, so verteilt der Posting Lock Manager entsprechende Sperren. So kann diese Regel z.B. zu einer Uberziehungs- und Last- schriftensperre auf allen Konten und einer Sperre aller Karten des betroffenen Geschäftspartners fuhren. Dieses Regelwerk ist kundenspezifisch erweiterbar.
Bedingt durch die Primaraufgabe des Account Management, den juristischen Bestand zu fuhren, steht em flexibles Repor- ting zur Verfugung. Dazu zahlen zahlreiche Listen, wie z.B. Uberziehungs-, Salden- und Umsatzlisten . Ebenso ist es möglich, Listen für Konto- und Schecksperren zu erstellen und Abstimmsaldenlisten zum Abgleich der Zahlungsverkehrssalden zu erzeugen.
Die Definition von weiteren Reports ist flexibel möglich.
Zubehör-Applikationen zum Account Management aus Sicht der Applikationslandschaft sind:
• Posting Control Office
• Dynamische Limitermittlung
• Mahnen/Verzugszms Wie einleitend bereits erwähnt, erganzen bzw. unterstutzen Zubehor-Applikationen die Funktion bzw. Aufgabe einer oder mehrerer Kernapplikationen .
Das Posting Control Office ist eine Zusatzapplikation zum Account Management, die der Disposition von Zahlungsposten dient, bei denen beim Buchungsversuch eine Sperre oder eine ungenehmigte Überziehung festgestellt wurde.
Zahlungsposten, die im Account Management auf Buchungshindernisse (Sperren) und Konten treffen, bei denen es zu einer ungenehmigten Überziehung kommt, werden gemäß einem Regelwerk (Posting Control Rules) disponiert. Dieses kundenspezifisch einstellbare Regelwerk wird im Account Management verwaltet. Gegebenenfalls werden Informationen zu Zahlungsposten, die als Reaktion auf die Posting Control Rules nicht explizit abgewiesen werden, mittels eines Dispositionsauftrags (Posting Control Order) an das Posting Control Office ausgesteuert, wo ihre weitere Bearbeitung (Disposition) entweder maschinell oder manuell erfolgt. Die maschinelle Disposition (Repetitor) umfaßt die automatische Wiedervorlage von Zahlungsposten zur Buchung an das Account Management. Zahlungsposten, für die nur temporare Buchungs- hmdernisse (z.B. Limitprobleme) vorliegen, können mit Hilfe des Repetitors ohne manuelle Eingriffe disponiert werden.
Dauer und Häufigkeit der Wiedervorlage sowie die Endreaktion (z.B. Abweisen) bei nicht beseitigten oder neu auftretenden Buchungshindernissen sind einstellbar.
Die manuelle Bearbeitung von zu disponierenden Zahlungsposten erfolgt am Posting Control Desktop. In dieser Teillösung ist die rollenbasierte Ausgestaltung und Usability von zentraler Bedeutung. Der Disponent wird durch den Zugriff auf dispositionsrelevante Daten in seiner Entscheidung unterstutzt, Zahlungsposten entweder abschließend zu bearbeiten (Aktionen u.a. buchen, abweisen etc.) oder an die maschinelle Disposition zu übergeben.
Die dynamische Limitermittlung ist eine Losung, die insbesondere im automatisierten Massengeschaft erforderlich ist. Es handelt sich hierbei um eine Zubehorapplikation zum Account Management, die es der einzelnen Bank ermöglicht, automatisch aufgrund von definierten Regeln und Inputparame- tern Limite beim Kunden zu setzen.
Die dynamische Limitermittlung wird vom Kunden bzw. in Kundenprojekten nach individuellem Bedarf ausprogrammiert. Die Limitermittlung kommuniziert mit der Bestandsführung, dem Geschäftspartner sowie dem operativen CRM.
Diese Zubehorapplikation ist zustandig für außergerichtliche Mahnprozesse.
Figur 5 zeigt zusammenfassend im Überblick anhand einer schematischen Blockdarstellung die Struktur der Kernappli- kation Account Management.
Unter Bezugnahme auf die Figuren 6 bis 15 wird nun die Erfindung detaillierter beschrieben.
Die Linktabelle speichert die Zuordnung zwischen Vertrag und Vertragsbausteinen. Zwischen dem Vertrag und den Vertragsbausteinen können beliebig viele Zuordnungen sowie die Funktion der Zuordnung gespeichert werden, wobei die Zuordnungen zeitabhängig sind. Auch Freigabe und Anderungsbelege werden hier abgespeichert. Verschiedene Attribute sind hierbei Schlusselfelder für die Verknüpfungsidentifikation und Zeitstempel, die Vertragsidentifikation, der Name des Vertragsbausteins, eine Identifikation für die Bausteintabelle etc.
Unter dem „Vertragsbaustein" ist in Zusammenhang mit dieser Erfindung die Summe des Codmgs eines Vertragsbausteins zu verstehen, also das Coding, das die Vertragsbausteindaten und deren Prozesslogik bspw. im Dialog darstellen oder sie in der Vertragsbausteintabelle abspeichern. Die Vertrags- baustemtabelle wiederum ist/sind die Datenbanktabelle (n)des Vertragsbausteins (entfallt naturgemäß bei Verags- bausteinen ohne eigene Datenbanktabelle) . Unter Vertrags- baustemdaten sind die Daten eines Vertragsbausteins zu verstehen, die einem Vertrag zugeordnet sind. Die Daten sind normalerweise in einer Zeile der Vertragsbausteintabelle gespeichert. Es gibt aber auch Vertragsbausteine, in denen die Daten mehrere Zeilen einnehmen, wieder andere Vertragsbausteine haben gar keine Vertragsbausteintabelle, wohl aber Vertragsbausteindaten.
Im Gegensatz zum Stand der Technik, bei dem bei der Gestaltung eines Vertrags zu jedem Vertragsbaustein der Inhalt seiner Attribute individuell abgespeichert wird (d.h. in der vorliegenden Terminologie wird zu jedem betroffenen Vertragsbaustein an der zugehörigen Vertragsbausteintabelle ein neuer Datensatz angefugt) , was zu einer großen Menge überflüssiger und redundanter Daten fuhrt, wird erfindungs- gemaß an die Vertragsbausteintabelle kein neuer Datensatz angefugt, sofern ein Vertragsbaustein die Daten des vertragsgegenstandlichen Produkts nicht ändert. Diesem Vorgehen liegt die Erkenntnis zugrunde, daß im taglichen Massengeschaft in der Regel die produktspezifischen Attribute im Vertrag unverändert übernommen werden. Vorteilhafterweise erfolgt eine Pufferung der Datenbanktabelle, da dann der Zugriff deutlich verbessert wird und schneller erfolgt.
Jeder Vertragsbaustein ist wiederum in einer eigenen Entwicklungsklasse gekapselt, was zu einer Entkopplung fuhrt.
Erfindungsgemaß sind die Vertragsbausteine im Accountmana- gement produktypubergreifend verwendbar, so daß Felder, die zu einem gemeinsamen (betriebswirtschaftlichen) Thema gehören, in einen Vertragsbaustein gruppiert werden.
Erfindungsgemaß wird des weiteren zwischen generischen Vertragsbausteinen und produkttypspezifischen Vertragsbausteinen (Konto-Vertragsbausteine, Karten-Vertragsbausteine, Kartengeme schafts-Vertragsbausteine, Kontengemeinschafts- Vertragsbausteine etc.) unterschieden. In den generischen Vertragsbausteinen sind Eigenschaften allgemeiner Natur, wie bspw. die Anbindung des Geschäftspartners, die Vertragskonditionen, Limite, Zahlungsverbindungen, Kündigungsfristen, Korrespondenzanforderungen, verbundene Verträge, Vertragszweck, Vertragsbezeichnung u.dgl. enthalten, wahrend zu den produkttypspezifischen Vertragsbausteinen Attribute wie Kontoauszug, Kontoauflosung, Hauptbuchfortschreibung, Buchungssperren, Abbuchungsauftrage, Saldenbe- statigung, Kontogrunddaten, alias Namen usw. hinterlegt sind.
In der erfindungsgemaßen Applikationsarchitektur gibt es eine Entitat „Link: Produkt-Baustein" oder kurz „Produktlink" (vgl. Figur 10) . Diese Entitat gehört zu dem Paket „Vertrag" und nicht zu dem separaten Produktkonfigurator 10. Die Aufgabe des Produktlinks ist es, eine Zuordnung zwischen einem Produkt (bzw. einer Produktversion) und Vertragsbausteinen herzustellen und so zu ermöglichen, daß Vertragsbausteine, die keine Änderungen an den Vorgaben des Produkts vornehmen, keine zusatzlichen Eintrage in der zugehörigen Vertragsbausteintabelle vornehmen müssen.
In einer eigenen Linktabelle werden Zeiger (Pointer) auf die zu einer Produktversion gehörenden Vertragsbausteindaten gespeichert (also ein Link zwischen dem Produkt und einem zugehörigen Vertragsbaustein und dessen Attribute) . Bei Anlage eines Vertrags werden diese Zeiger an den Vertragsbaustein übergeben, so daß sie in der Vertragsbaustein- Linktabelle gespeichert werden können. Der Vertrag zeigt dann auf dieselben Vertragsbausteindaten wie das Produkt. Es gibt somit Produktlinks zwischen dem Produkt und den Vertragsbausteinen und Vertragslinks zwischen dem Vertrags und den Vertragsbausteinen.
Bei einem Produktversionswechsel werden bestimmte Eigenschaften des Produkts geändert, was sich auf einen oder mehrere Vertragsbausteine auswirken kann. Auswirkungen auf die Vertragsbausteine wiederum wirken sich auf einen oder mehrere Vertrage aus. Die entsprechenden Vertrage, auf die sich die Änderungen im Produkt auswirken, werden über eine Angabe, um welches Produkt es sich handelt, ausgewählt und die zugehörigen Links werden angepaßt.
Erfindungsgemaß ist somit eine Wiederverwendbarkeit der Vertragsbausteine ermöglicht. Des weiteren ermöglicht die Erfindung das Anlegen von „Vertragen über Vertrage", d.h. Gemeinschaftsvertrage wie Kartengemeinschaft u.dgl. können als ein Vertrag gefuhrt werden. Vertrage und Vertragsbausteine sind Anwendungsdaten (im Gegensatz zu den Produkten und Produktattributen, bei denen es sich um sogenannte Customizmg-Daten handelt), die nicht transportiert werden können. Die Tabelle der Verknüpfungen zwischen Produkt und den Vertragsbausteindaten ist daher eine Anwendungstabelle, da beim Anlegen bzw. Konfigurieren eines Produkts noch keine Vertragsbausteindaten angelegt werden können und somit auch keine Verknüpfung zwischen dem Produkt und den Vertragsbausteindaten erzeugt werden kann.
Erfindungsgemaß wird beim Anlegen eines Vertrags durch ein Vertragsbaustein nicht das Produkt direkt, sonder statt dessen die Produktverknupfung aufgerufen und der Vertragsbaustein erhalt eine Verknüpfung auf Vertragsbausteindaten. Bei der Abspeicherung des Vertrags prüft der Vertragsbaustein, ob die vom Produkt übernommenen Daten geändert wurden. Ist dies der Fall, so erfolgt eine Speicherung der geänderten Daten als neuer Eintrag in der Vertragsbausteintabelle. Wurden die Daten hingegen nicht geändert, so wird lediglich die Verknüpfung (Produkt zu Vertragsbausteindaten) m der Vertragslinktabelle (Vertrag zu Vertragsbausteindaten) gespeichert, mit dem Vermerk, daß der Vertrag nicht „Eigentumer" der Vertragsbausteindaten ist. Die Vertragsbausteintabelle bleibt unverändert.
Als Ergebnis dieses erfindungsgemaßen Vorgehens ist, daß in der Vertragsbausteintabelle ein Eintrag existiert, auf dem sowohl die Produktversion als auch sehr viele Vertrage zeigen. Daneben gibt es noch einige weitere Eintrage, auf die jeweils ein Vertag zeigt, nämlich dann, wenn ein Vertrag die Vorgaben des Produkts geändert hat. In der Vertragslinktabelle ist vermerkt, ob der Vertrag „Eigentumer" der Vertragsbausteindaten ist (d.h. die Daten gehören individu¬ ell zum Vertrag) oder nicht (d.h. die Daten gehören zum Produkt, der Vertrag hat sie - über Verknüpfung - lediglich „geerbt" .
Beim ersten Anlegen eines Vertrags zu einem Produkt bzw. einer Produktversion ist die Produktlinktabelle noch leer. Merkt der Produktlink, daß er zu diesem Produkt bzw. zu dieser Produktversion noch gar keine Links abgespeichert hat, dann fordert er die betroffenen Vertragsbausteine auf, sich ihre „Defaultwerte" vom zugehörigen Produkt zu holen, abzuspeichern und ihm einen Link auf die gespeicherten Daten zurückzugeben. Die Links bzw. Verknüpfungen auf die Eintrage - merkt - sich der Produktlink in seiner eigenen Lmktabelle. Anschließend gibt er auf Anfrage die Links wie beschrieben an die einzelnen Vertragsbausteine.
Beim Andern eines Vertrages handelt es sich um eine individuelle Änderung, d.h. es werden Vertragsbausteindaten geändert mit einem neuen Eintrag in der entsprechenden Ver- tragsbaustemtabelle und einer neuen Verknüpfung (Link) in der Vertragslinktabelle.
Beim Archivieren von Vertragen besteht die Besonderheit, daß mit dem Vertrag und dem zu dem Vertrag gehörenden Links diejenigen Vertragsbausteindaten archiviert werden, bei denen der Vertrag „Eigentumer" ist. Diejenigen Vertragsbausteindaten, bei denen er nicht „Eigentumer" ist, werden nicht mitarchiviert, da noch andere Vertrage auf diese Ver- tragsbaustemdaten verknüpft sein können.
Beim Anlegen eines Vertrags (vgl. Figur 15) ruft der Vertrag den Produktlink mit „mit" auf. Stellt der Produktlink fest, daß er zu dieser Produktversion noch keine Links hat, ruft er die betreffenden Vertragsbausteine mit „SetDefault" auf. Die Vertragsbausteine holen sich dann ihre Defaultwer- te mit „GetDefault" vom Produkt, speichern sie und geben den Link an den Produktlink zurück. Im weiteren Verlauf holen sich die einzelnen Vertragsbausteine ihre Links mit „Get" vom Produkt Link. Dies bedeutet, daß die in der Figur 15 fett eingezeichneten Ablaufe „SetDefault" und „GetDe- fault" lediglich beim ersten Anlegen eines Vertrags zu einem bestimmten Produkts bzw. einer bestimmten Produktversion durchgeführt werden.
Die in den Figuren 11 bis 14 verwendeten Abkürzungen haben die folgende Bedeutung:
ISSTA Initialisierung
ISDAT Daten lesen von der DB
ISDST Daten verteilen an partizipierende Anwendung
FCODE Eigenen Funktionscode bearbeiten
XCHNG Prüfung, ob Daten verändert wurden
DCHCK Prüfungen vor dem Sichern
DSAVB Daten sammeln bei besitzender Anwendung
DTAKE Daten merken im Gesamtgedachtnis
DSAVC Daten komplettieren (interne Nummer ziehen)
DSAVE Daten speichern in DB
DLVE1 Aktualgedachtnis initialisieren
DLVE2 Gesamtgedachtnis initialisieren
Anhand eines Ausführungsbeispiels für ein fiktives Produkt namens „easy" und eines Vertragsbausteins „Hauptbuchdaten" wird die Erfindung im folgenden verdeutlich:
Erstellen des Produkts „easy"
Das Produkt „easy" (Version 1) wird im Customizingsystem des Kunden kreiert und ausgetestet.
Schließlich wird es in das Produktivsystem transportiert.
Anlegen des ersten Vertrags
Der erste Vertrag (Nr. 1) zum Produkt „easy" wird angelegt, Der Vertrag teilt dem Produktlink mit, dass es sich auf das Produkt „easy" vorbereiten soll (Aufruf des Init-API)
Der Produktlink stellt fest, dass zum Produkt „easy" noch keine Links existieren. Es ruft nun alle Vertragsbausteine mit set_defaults-API auf, unter anderem auch die Hauptbuchdaten. Die Hauptbuchdaten holen sich nun ihre Defaultwerte vom Produkt „easy", speichern sie ab und erzeugen hierfür einen Schlüssel (HB_1). Den Schlüssel geben sie an den Produktlink zurück. Der Produktlink speichert sich alle Links zwischen dem Produkt „easy" und den Vertragsbausteinen.
Nun rufen der Reihe nach die Vertragsbausteine den Produktlink auf, um sich einen Link auf ihre Daten zu holen. Der Vertragsbaustein „Hauptbuchdaten" ruft also den Produktlink mit Get_API auf und erhalt den Schlüssel HB_1 zurück.
Beim Speichern des Vertrags (unter dem Annahme, dass die Hauptbuchdaten nicht verändert wurden) gibt der Vertragsbaustein „Hauptbuchdaten" seinen Schlüssel HB_1 an die Vertragslinktabelle und sagt ihr, dass nicht der Vertrag (sondern das Produkt) Owner der Daten ist.
Die Datenbanktabellen haben nun folgende Eintrage (vereinfacht) :
Vertra stabelle
Vertragsbaustein Hauptbuchdaten
Hauptbuch- Attrischlussel bute
HB 1
Produktlink
Anlegen von Standard-Verträgen
Jetzt werden die Vertrage 2 bis 4 angelegt. Sie alle andern die vom Produkt vorgegebenen Hauptbuchdaten nicht (Normalfall)
Der Vertrag teilt dem Produktlink mit, dass es sich auf das Produkt „easy" vorbereiten soll (Aufruf des Init-API)
Der Produktlink holt sich die Links dieses Produkts in seinen Puffer
Nun rufen der Reihe nach die Vertragsbausteine den Produktlink auf, um sich einen Link auf ihre Daten zu holen. Der Vertragsbaustein „Hauptbuchdaten" ruft also den Produktlink mit Get API auf und erhalt den Schlüssel HB 1 zurück.
Beim Speichern des Vertrags gibt der Vertragsbaustein „Hauptbuchdaten" seinen Schlüssel HB_1 an die Vertragslinktabelle und sagt ihr, dass nicht der Vertrag sondern das Produkt Owner der Daten ist. Die Datenbanktabellen haben nun folgende Einträge (vereinfacht) :
Vertra slinktabelle
Vertragsbaustein Hauptbuchdaten Hauptbuchschlü Attrib ssel ute
HB 1
Anlegen eines individuellen Vertrags
Der Vertrag 5 wird angelegt. Er ändert individuell die Hauptbuchdaten (Ausnahmefall) Der Vertrag teilt dem Produktlink mit, dass es sich auf das Produkt „easy" vorbereiten soll (Aufruf des Init-API)
Der Produktlink holt sich die Links dieses Produkts in seinen Puffer
Nun rufen der Reihe nach die Vertragsbausteine den Produktlink auf, um sich einen Link auf ihre Daten zu holen. Der Vertragsbaustein „Hauptbuchdaten" ruft also den Produktlink mit Get_API auf und erhalt den Schlüssel HB_1 zurück.
Der User ändert nun die ihm angezeigten Hauptbuchdaten und speichert .
Der Vertragsbaustein „Hauptbuchdaten" speichert die geänderten Daten unter einem neuen Schlüssel (HB_2) und teilt der Vertragslinktabelle den neuen Schlüssel mit und sagt ihr, dass der Vertrag individuell Owner dieser Daten ist
Die Datenbanktabellen haben nun folgende Eintrage (verein¬ facht) :
Vertra s linktabelle
Vertra sbaustein Hau tbuchdaten

Claims

Patentansprüche
1. Verfahren zur computerimplementierten Generierung und Verwaltung von Vertragen zwischen einem Anbieter und einem oder mehreren Kunden, wobei jeder Vertrag aus Kerndaten zu einem vertragsgegenstandlichen Produkt und aus einem oder mehreren Vertragsbausteinen besteht, welche Kerndaten in einer ersten Speichereinheit abgespeichert sind und welche Vertragsbausteine in einer zweiten Speichereinheit abgespeichert sind, und wobei zur Gestaltung eines Vertrags eine Auswahl von Kerndaten vorgenommen wird und eine Auswahl von Vertragsbausteinen vorgenommen wird und der Vertrag auf der Grundlage der vorgenommenen Auswahl elektronisch durch automatische Erzeugung und Hinterlegung von elektronischen Verweisen (Verknüpfungen) auf die ausgewählten Kerndaten und Vertragsbausteine generiert wird.
2. Verfahren nach Anspruch 1, bei dem zunächst eine Auswahl der Kerndaten und anschließend eine Auswahl der Vertragsbausteine vorgenommen wird, wobei auf der Grundlage der ausgewählten Kerndaten, die Informationen und Regeln zu dem vertragsgegenstandlichen Produkt enthalten, automatisiert eine Überprüfung der Zulässigkeit der Auswahl einzelner Vertragsbausteine erfolgt.
3. Verfahren nach Anspruch 1 oder 2, bei dem die erste Speichereinheit und die zweite Speichereinheit identisch sind .
4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem jedem hinterlegten Vertrag eine zentrale Identifikationsnummer zugeordnet wird, die eine Verknüpfung mit systemexternen Daten erlaubt.
5. Verfahren nach Anspruch 5, bei dem die zentrale Identifikationsnummer weltweit eindeutig ist.
6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem vertragsubergreifende Änderungen der Kerndaten und/oder der Vertragsbausteine in der jeweiligen zentralen Speichereinheit vorgenommen werden.
7. Verfahren nach einem der voranstehenden Ansprüche, bei dem Vertragsbausteine vordefiniert sind.
8. Verfahren nach Anspruch 6, bei dem Änderungen in den Kerndaten und/oder Vertragsbausteinen zeitlich erfaßt und durch Verknüpfungen hinterlegt werden.
9. Verfahren nach einem der voranstehenden Ansprüche, bei dem der Anbieter ein Finanzdienstleister ist und die vertragsgegenstandlichen Produkte Finanzprodukte sind.
10. Verfahren nach Anspruch 1, bei dem der Vertragsbaustein nach Vertragsgenerierung prüft, ob die von dem vertragsgegenstandlichen Produkt übernommenen Daten geändert wurden oder nicht, und - falls keine Änderung vorgenommen wurde - em Abspeichern einer Verknüpfung von Produkt zu Vertragsbaustein in einer Vertragslinktabelle, die die Verknüpfung zwischen Vertrag und Vertragsbaustein enthalt, veranlaßt, oder - falls eine Änderung vorgenommen wurde - ein Abspeichern der Änderung als neuen Eintrag in eine Vertragsbausteintabelle veranlaßt.
11. Vorrichtung zur computerimplementierten Generierung und Verwaltung von Vertragen zwischen einem Anbieter und einem oder mehreren Kunden, wobei jeder Vertrag aus Kerndaten zu einem vertragsgegenstandlichen Produkt und aus einem oder mehreren Vertragsbausteinen besteht, mit einer ersten Speichereinheit zum Abspeichern der Kerndaten und einer zweiten Speichereinheit zum Abspeichern der Vertragsbausteine, mit einer Einrichtung zum Auswahlen von Kerndaten und zum Auswahlen von Vertragsbausteinen, um einen Vertrag zu gestalten, und mit einer Generierungseinrichtung zum e- lektronischen Generieren durch automatische Erzeugung und Hinterlegung in einer Verknüpfungstabelle von elektronischen Verweisen (Verknüpfungen) auf die ausgewählten Kerndaten und Vertragsbausteine.
12. Vorrichtung nach Anspruch 11, in der zunächst eine Auswahl der Kerndaten und anschließend eine Auswahl der Vertragsbausteine vorgenommen wird, wobei auf der Grundlage der ausgewählten Kerndaten, die Informationen und Regeln zu dem vertragsgegenstandlichen Produkt enthalten, mittels einer Überprufungseinrichtung automatisiert eine Überprüfung der Zulässigkeit der Auswahl einzelner Vertragsbausteine erfolgt .
13. Vorrichtung nach Anspruch 11 oder 12, in der die erste Speichereinheit und die zweite Speichereinheit identisch sind.
14. Vorrichtung nach einem der Ansprüche 11 bis 13, in der jedem hinterlegten Vertrag eine zentrale Identifikationsnummer zugeordnet wird, die eine Verknüpfung mit systemexternen Daten erlaubt.
15. Vorrichtung nach Anspruch 14, in der die zentrale I- dentifikationsnummer weltweit eindeutig ist.
16. Vorrichtung nach einem der Ansprüche 11 bis 15, in der vertragsubergreifende Änderungen der Kerndaten und/oder der Vertragsbausteine in der jeweiligen zentralen Speichereinheit vorgenommen werden.
17. Vorrichtung nach einem der Ansprüche 11 bis 16, in der Vertragsbausteine vordefiniert sind.
18. Vorrichtung nach Anspruch 16, in der dem Änderungen in den Kerndaten und/oder Vertragsbausteinen zeitlich erfaßt und durch Verknüpfungen hinterlegt werden.
19. Vorrichtung nach einem der Ansprüche 11 bis 17, in der der Anbieter ein Finanzdienstleister ist und die vertragsgegenstandlichen Produkte Finanzprodukte sind.
20. Vorrichtung nach Anspruch 11, in der der Vertragsbaustein beim Speichern eines erzeugten Vertrags prüft, ob die von dem vertragsgegenstandlichen Produkt übernommenen Daten geändert wurden oder nicht, und - falls keine Änderung vorgenommen wurde - ein Abspeichern einer Verknüpfung von Produkt zu Vertragsbaustein in einer Vertragslinktabelle, die die Verknüpfung zwischen Vertrag und Vertragsbaustein enthalt, veranlasst, oder - falls eine Änderung vorgenommen wurde - Abspeicherung der Änderung als neuen Eintrag in eine Vertragsbausteintabelle.
21. Computerprogrammprodukt mit einem computerlesbaren Medium und einem auf dem computerlesbaren Medium gespeicherten Computerprogramm mit Programmcodemitteln, die dazu geeignet sind, bei Ablauf des Computerprogramms auf einem Computer ein Verfahren nach einem der Ansprüche 1 bis 10 auszufuhren .
22. Computerprogramm mit Programmcodemitteln, die dazu geeignet sind, bei Ablauf des Computerprogramms auf einem Computer ein Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
EP02791689A 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten generierung und verwaltung von verträgen Withdrawn EP1609088A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US33147001P 2001-11-16 2001-11-16
US331470P 2001-11-16
PCT/EP2002/012924 WO2003042861A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten generierung und verwaltung von vertr�gen

Publications (1)

Publication Number Publication Date
EP1609088A2 true EP1609088A2 (de) 2005-12-28

Family

ID=23294112

Family Applications (3)

Application Number Title Priority Date Filing Date
EP02783085A Ceased EP1440422A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten verarbeitung von zahlungsposten
EP02791689A Withdrawn EP1609088A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten generierung und verwaltung von verträgen
EP02792774A Expired - Lifetime EP1440423B1 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zum computerimplementierten verarbeiten von elektronischen zahlungsaufträgen

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP02783085A Ceased EP1440422A2 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zur computerimplementierten verarbeitung von zahlungsposten

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP02792774A Expired - Lifetime EP1440423B1 (de) 2001-11-16 2002-11-18 Verfahren und vorrichtung zum computerimplementierten verarbeiten von elektronischen zahlungsaufträgen

Country Status (5)

Country Link
US (1) US20050010512A1 (de)
EP (3) EP1440422A2 (de)
AT (1) ATE557364T1 (de)
AU (2) AU2002346840A1 (de)
WO (3) WO2003042861A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022204489A1 (de) 2022-05-06 2023-11-09 Robert Bosch Gesellschaft mit beschränkter Haftung System und Verfahren zum Erstellen einer Kostenkalkulation

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070055653A1 (en) * 2005-09-02 2007-03-08 Guerra Currie Anne-Marie P System and method of generating automated document analysis tools
US20070055670A1 (en) * 2005-09-02 2007-03-08 Maycotte Higinio O System and method of extracting knowledge from documents
US20070055696A1 (en) * 2005-09-02 2007-03-08 Currie Anne-Marie P G System and method of extracting and managing knowledge from medical documents
EP1798673A1 (de) * 2005-11-23 2007-06-20 Ubs Ag Computer-implementiertes System zur Erzeugung, Bearbeitung und Verwaltung von strukturierten Datensätzen
EP1798672A1 (de) * 2005-11-23 2007-06-20 Ubs Ag Computer-implementiertes System zur Erzeugung, Bearbeitung und Verwaltung von strukturierten Datensätzen
EP1801744A1 (de) * 2005-11-23 2007-06-27 Ubs Ag Computer-implementiertes System zur Erzeugung, Bearbeitung und Verwaltung von strukturierten Datensätzen
US20070265853A1 (en) * 2006-04-03 2007-11-15 Hall David R Database Mechanism
US20090076837A1 (en) * 2007-09-13 2009-03-19 Wayne Collier System and method for product definition
US20180053164A1 (en) * 2008-08-12 2018-02-22 Branch Banking And Trust Company Method for Retail On-Line Account Opening With Early Warning Methodology
US8612339B2 (en) * 2008-08-12 2013-12-17 Branch Banking & Trust Company System and method for business online account opening
WO2012048234A2 (en) 2010-10-07 2012-04-12 Morgan Stanley System and method for risk monitoring of rated legal entities
US11514511B2 (en) * 2020-03-24 2022-11-29 Saudi Arabian Oil Company Autonomous bidder solicitation and selection system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030023539A1 (en) * 2001-07-27 2003-01-30 Wilce Scot D. Systems and methods for facilitating agreement definition via an agreement modeling system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03042861A2 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022204489A1 (de) 2022-05-06 2023-11-09 Robert Bosch Gesellschaft mit beschränkter Haftung System und Verfahren zum Erstellen einer Kostenkalkulation

Also Published As

Publication number Publication date
AU2002358515A1 (en) 2003-05-26
EP1440422A2 (de) 2004-07-28
ATE557364T1 (de) 2012-05-15
WO2003042942A2 (de) 2003-05-22
WO2003042861A8 (de) 2004-12-16
US20050010512A1 (en) 2005-01-13
WO2003042942A8 (de) 2003-11-13
WO2003042941A8 (de) 2003-11-13
WO2003042861A2 (de) 2003-05-22
WO2003042941A2 (de) 2003-05-22
AU2002346840A1 (en) 2003-05-26
EP1440423A2 (de) 2004-07-28
EP1440423B1 (de) 2012-05-09

Similar Documents

Publication Publication Date Title
Khoufi et al. An empirical examination of the determinants of audit report delay in France
Rochmah Ika et al. Audit committee effectiveness and timeliness of reporting: Indonesian evidence
Costa et al. Accountability as a managerial tool in non-profit organizations: Evidence from Italian CSVs
Wickramasinghe et al. A cultural political economy of management accounting controls: a case study of a textile Mill in a traditional Sinhalese village
DE10297684T5 (de) System zur Unterstützung der Verbesserung des Geschäftsgewinns
WO1999067749A1 (de) Anwendungsübergreifendes arbeitszeitblatt
Turnbull Corporate charters with competitive advantages
EP1609088A2 (de) Verfahren und vorrichtung zur computerimplementierten generierung und verwaltung von verträgen
EP1758051A1 (de) System, Verfahren und Computerprogrammprodukt zur arbeitsflussbasierten Datenverarbeitung
Wright et al. Divestment and the control of divisionalised firms
Thuita An investigation of the effect of tax incentives on the FDIs: A case of EPZs in Athi River Kenya
US20050004850A1 (en) Method and apparatus for computer-implemented processing of payment entries
Saleh et al. Co-operative governance and the public interest: Between control and autonomy
Keppo et al. Dynamic Contracting in Asset Management Under the Investor-Partner-Manager Relationship
CN112053126A (zh) 用于装企运营的管理系统和计算机设备
Biondi et al. Accounting for the Chinese context: a comparative analysis of international and Chinese accounting standards focusing on business combinations
Turnbull Why unitary boards are not best practice: A case for compound boards
DE112020006013T5 (de) Ein system zur investitionsförderung und verfahren dafür
DE69911208T2 (de) System zur simulation eines geschäftsprozesses
EP1457909A2 (de) Verfahren zur Ermöglichung eines Unternehmenswechsels
Boskov Tourism strategy: move to an investment-driven strategy and promotion?
Bielefeld Automation and Digitalization in Financial Accounting and Auditing
Kubíčková et al. Family Firms And Financial Literacy
Susanti et al. Implementation Model of Equity Participation in Regional Development Banks in Indonesia
WO2004032006A2 (de) Verfahren und system zur automatischen speicherung von betriebswirtschaftlichen daten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030530

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

PUAK Availability of information related to the publication of the international search report

Free format text: ORIGINAL CODE: 0009015

17Q First examination report despatched

Effective date: 20080428

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SAP SE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160601