System house seeks contract management software for a service provider

As a system house, we are looking for contract management and contract controlling software for a service provider.

We have the following requirements for the software:

• 1. Range of functions: All contracts must be able to be recorded, processed, and evaluated quickly, easily, (audit-)securely, and completely.
  • 1.1. Contract types
    • 1.1.1. It must be possible to map various contract types. Contracts include service contracts (e.g., maintenance contracts, architect contracts, software programming, etc.), insurance contracts, license agreements, service contracts (all types of continuing obligations), rental agreements (especially leasing contracts, rental and tenancy agreements, etc.), purchase agreements, etc.
    • 1.1.2. It must also be possible to configure and map new contract types and designs in the future. There must be a general concept for mapping all types of contracts.
    • 1.1.3. It must be possible to implement contract templates, which can then be designed by users from the specialist departments to a predefined extent.
  • 1.2. Contract lifecycle: All phases of a contract's lifecycle must be mappable.
    • 1.2.1. Contract initiation with inquiry, tender, offer, offer comparison, and approval procedures, as well as related agreements in the contract initiation phase (e.g., letters of intent, confidentiality agreements, etc.). All temporal and financial risks should already be recorded in the digital contract process during the offer comparison phase
    • 1.2.2. Contract conclusion should include functionalities for scheduling and financial planning over the entire contract period.
    • 1.2.3. Contract execution with task management, budgeting, automatic invoicing, automatic invoice verification, etc.
    • 1.2.4. Contract amendments, history management, extensions, and shortening, each with automatic recalculation of the associated planned values.
    • 1.2.5. Workflows for contract creation, review, extension, and termination.
    • 1.2.6. Contracts must be manageable in their various contract stages (e.g., calculation, plan, target, actual, etc.). In particular, it should be possible to “simulate” the conclusion of a contract or contract changes, e.g., with regard to costs.
  • 1.3. Contract data and business processes: All of the following contract data should be recordable and/or calculable.
    • 1.3.1. Contract structures (in particular business partners, objects, scope of services, cost centers, etc.)
    • 1.3.2. Relationships (between individual or multiple business partners, contract objects, and contracts -> interdependence analysis)
    • 1.3.3. Contract rules (time effects, financial effects, and/or other definable triggering events)
    • 1.3.4. Contract effects (plan, target, actual, prices, values (past, present, future)
  • 1.4. Business partners: The software must be able to manage the following business partner data.
    • 1.4.1. Master data
    • 1.4.2. Address data
    • 1.4.3. Contact persons (e.g., data protection officer, managing director, internal audit, etc.)
    • 1.4.4. Bank details
    • 1.4.5. Certifications
    • 1.4.6. Business partner relationships (meaning group structures, affiliated companies, cooperations, etc.)
    • 1.4.7. Credit ratings
    • 1.4.8. Additional data
  • 1.5. Subcontractor data
    • 1.5.1. Subcontractor relationships with business partners (outsourcing chain)
    • 1.5.2. Subcontractor relationships with specific contracts and contract objects
    • 1.5.3. Complete subcontractor data as in 1.4.
  • 1.6. Contract objects: Contract object data must be manageable with the software.
    • 1.6.1. Master data
    • 1.6.2. Object relationships
    • 1.6.3. Requirements derived from business processes, e.g.:
    • 1.6.4. Business partner roles in objects
    • 1.6.5. Additional data
    • 1.6.6. Contract objects relevant to criticality?
  • 1.7. Contract master data: Contract master data must be manageable in the software.
    • 1.7.1. Contract
    • 1.7.2. Contractual partners (multi-party capability)
    • 1.7.3. Master data
    • 1.7.4. Contract term
    • 1.7.5. Relationships (contractual relationships, contact person roles in contracts, revision, etc.)
    • 1.7.6. Contract clauses: The software must be able to manage documents, notes, emails, correspondence, etc., in particular:
    • 1.7.7. Emails
    • 1.7.8. Letters (as scans)
    • 1.7.9. Notes
    • 1.7.10. Contract dates (with log function if necessary)
  • 1.8. Scope of services
    • 1.8.1. It must be possible to manage all possible data relating to the scope of services (e.g., service items, service specifications, requirements specifications, etc.) in the software.
    • 1.8.2. It must be possible to manage various types of services (cost types).
    • 1.8.3. In principle, it should be possible to manage a separate service period for each type of service.
    • 1.8.4. The service must be assignable to one or more service items (budgeting) so that, for example, the costs can be allocated accordingly or follow-up costs of investments can be determined.
    • 1.8.5. It must be possible to assign the costs to the respective cost units, cost centers, and, if necessary, other evaluable elements.
    • 1.8.6. It must be possible to calculate the quantities, prices, and other possible values for all possible services as planned values for the entire service period.
  • 1.9. Measurement
    • 1.9.1. It must be possible to document and evaluate the variable utilization of contractual services by means of a measurement system.
    • 1.9.2. This measurement system must be designed in such a way that it can be individually adapted to the respective contract by contract management or the specialist department.
    • 1.9.3. If necessary, it should also be possible to carry out automatic invoice checks.
  • 1.10. Change log
    • 1.10.1. All changes and documentation must be traceable in an audit-proof manner. It must be possible to determine at any time when a change or documentation was made.
    • 1.10.2. For this purpose, an audit-proof change log must be kept for all contract data.
• 2. Deadline management
  • 2.1. The system must be able to manage different deadlines (notice periods, warranty periods, payment deadlines, manual deadlines, etc.) for each contract.
  • 2.2. It must be possible to automatically calculate deadlines from the respective termination clauses with to-do workflows for individual departments.
  • 2.3. Deadline management must allow automatic appointment calendars to be maintained for contract management and departmental managers.
  • 2.4. It must be possible to manage important regular deadlines, important unscheduled deadlines, important triggering events, important findings, etc.
  • 2.5. For example, it should be possible to manage deadlines and related tasks for guarantees, warranties, liability issues, complaints about defects, etc.
  • 2.6. Automatic deadline monitoring must be available.
  • 2.7. It must be possible to maintain automatic calendars organized by department, contract, contract clause, and, if necessary, other criteria.
• 3. Document management
  • 3.1. Composer function
    • 3.1.1. The software must have a function that can “assemble” contracts from a central clause repository in collaboration with one or more departments, external lawyers, and suppliers/service providers and generate a contract text from this with the intervention of contract management.
    • 3.1.2. The data from this composer function should be automatically transferred to the contract database and the contract.
    • 3.1.3. Contract entry should be further facilitated by means of specific/predefined contract and clause templates, which are simply filled in by the person processing the contract (e.g., contract management, department, etc.).
  • 3.2. Archiving
    • 3.2.1. The software must have an audit-proof document management system.
    • 3.2.2. It must be possible to create contract files (and project files, if applicable).
    • 3.2.3. Individual documents must also be assignable to different contract files.
  • 3.3. Document search
    • 3.3.1. Documents stored in the contract management system must be searchable using both keywords and OCR full-text search, and the relevant documents must be found.
    • 3.3.2. The search function should also be multilingual if necessary, i.e., it should also be able to find English terms.
    • 3.3.3. It should be possible to search for framework agreements, individual contracts, call-offs, and receipts.
  • 3.4. Document comparison
    • 3.4.1. Automated document comparison should be possible (e.g., contract version 2 versus version 1).
    • 3.4.2. Automatic document comparison should also be possible if the documents are not in the same format (Word vs. PDF).
• 4. Cross-functional use
  • 4.1. The contract management system should be usable across companies or for higher-level institutions.
  • 4.2. The software should be multi-client capable with regard to different partners for whom contracts are concluded.
  • 4.3. Different permissions must be definable.
• 5. Information system
  • 5.1. Available data
    • 5.1.1. All planned values, actual values, and historical data relating to the duration, quantity, and value of the contract must be available for the entire term of the contract.
    • 5.1.2. It must be possible to uniformly allow and answer all business-related questions, even on an ad hoc basis, across all contract types.
  • 5.2. Currencies
    • 5.2.1. The contract software must be able to display all currencies.
    • 5.2.2. Automatically convert all financial data (e.g., exchange rates).
• 6. Standard and individuality
  • 6.1. Scope of the standard modules
    • 6.1.1. It must be clarified to what extent ready-made modules exist for the contract software to cover the requirements and which parts must be programmed individually.
    • 6.1.2. With regard to individual programming, the effort required for initial and future programming must be taken into account.
  • 6.2. Contract-specific masks
    • 6.2.1. The personal masks of the respective users of the individual contracts should be individually customizable so that contract management can determine which information should be included in each contract without programming.
    • 6.2.2. Personal screens and business processes must be able to be set by contract management on a group, role, and person-specific basis without programming.
  • 6.3. Control of business processes and calculations
    • 6.3.1. The processing of all contracts should be fully controllable by parameters.
    • 6.3.2. The user (with the appropriate authorization) and contract management (as administrator) should be able to maintain all parameters without programming.
  • 6.4. Contract mathematics and rules
    • 6.4.1. Every user should be able to use the contract mathematics functions without programming to describe the economic agreements in a structured manner, calculate their financial effects over the entire period, and calculate contract comparisons across different currencies (with fluctuation tendencies).
    • 6.4.2. All rules should then be stored in a set of rules that can be used by contract management and the specialist department without IT specialists or programming.
  • 6.5. A high degree of configurability of the application is required
• 7. Security
  • 7.1. Authorization concept
    • 7.1.1. The authorization concept must allow a distinction to be made between the authorization to retrieve the contract, the authorization to amend the contract, and the authorization to amend the entries relating to the contract in the contract management system.
    • 7.1.2. It must be possible to define different roles.
    • 7.1.3. It must be possible to assign these different roles to different users or positions.
    • 7.1.4. It must also be possible to assign different roles to individual users.
    • 7.1.5. Deputy functions with flexible authorizations should be set up.
    • 7.1.6. There should also be status-dependent editing rights.
    • 7.1.7. The role authorization system of the contract software should be automatically synchronized with the company's central role authorization system.
  • 7.2. Audit compliance
    • 7.2.1. An audit principle dependent on the subject matter of the contract must be implemented for contract processing.
      • 7.2.1.1. Outsourcing/external procurement -> review by outsourcing management
      • 7.2.1.2. Order processing for the information of the data protection officer
      • 7.2.1.3. Contracts involving employee interests -> Review by the works council
    • 7.2.2. A multi-level review principle (4-/6-/8-eyes principle) dependent on the (annual) order volume must be implemented for contract activation.
      • 7.2.2.1. < 50,000.00 -> Department (FB) + Contract Management (VTM) = 4-eyes principle
      • 7.2.2.2. < 100,000.00 -> FB + VTM + Director = 6-eyes principle
      • 7.2.2.3. > 100,000.00 -> FB + VTM + Director + Executive Board = 8-eyes principle
    • 7.2.3. Previous points, 7.2.1. and 7.2.2. also apply to contract amendments
    • 7.2.4. Fully transparent access options for internal auditing of all processes
  • 7.3. Workflows
    • 7.3.1. It must be possible to set up workflows.
    • 7.3.2. These workflows must be able to control a wide variety of work processes with different conditions.
    • 7.3.3. To this end, it must be possible to control the work processes flexibly according to status.
    • 7.3.4. It should be possible to control/initialize the work processes from any contract data.
    • 7.3.5. This should be done, if possible, by users who can define personal workflows in addition to standard workflow functions.
    • 7.3.6. Various decision options should be available within the workflows (e.g., if-then, yes/no, above x/below x, etc.).
    • 7.3.7. Pending tasks (own/delegated) should be displayed in a to-do list.
    • 7.3.8. Questionnaires with controls and references (e.g., questionnaires on data protection, outsourcing issues, etc.).
    • 7.3.9. Digital checklists.
    • 7.3.10. Deadline violations should be displayed automatically.
• 8. Interfaces
• 8.1. ERP connection
  • 8.1.1. All data from the contract management system should be stored in the ERP system and additional data should be available from the ERP system.
  • 8.1.2. Existing data that should be available from the ERP system could be used for a make-or-buy decision, e.g., the cost of an IT workstation.
  • 8.1.3. Verified invoices and paid invoices should be automatically transferred from the ERP system.
  • 8.1.4. Obligation data (e.g., contract services still outstanding at the end of the contract) should be automatically transferred to the ERP system.
  • 8.1.5. Data exported to the ERP system should be automatically posted to cost centers, cost types, and contract objects.
• 8.2. Office connection
  • 8.2.1. The contract management system must be connected to Office and mailing systems in an audit-proof manner or implement these.
  • 8.2.2. No document (e.g., emails, receipts, minutes, specifications, etc.) should be re-entered manually in the contract management system, but should be recorded directly from the system itself.
  • 8.2.3. Service specifications should be able to be recorded directly for each contract object by the specialist department via the system before tendering.
  • 8.2.4. It should be possible to send emails directly from the contract management system.
• 8.3. Individual interfaces
  • 8.3.1. It should be possible to generate individual interfaces to other systems using an interface generator; if possible, this should be operable by the user.
  • 8.3.2. At least general interfaces (e.g., standard XML format) should be available.
  • 8.3.3. If possible, web services should be able to be integrated into the system.
• 8.4. Audit-proof transfer protocols
  • 8.4.1. Detailed transfer protocols must be available in which all results of the export and import interfaces (e.g., import from scanner) are documented.
• 9. Web capability Approximately 30 software workstations are planned.
  • 9.1. The system should be web-based, accessible via a browser, and implementable on the intranet.
  • 9.2. It should be possible to implement software modules according to the modular principle.

  Approximately 30 software workstations are planned.