OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [legalxml-econtracts] Scenario - Enterprise Contract Management -Draft 2


Hi all

Pls find attached a second draft of the above scenario.

The requirements have been re-organised into the four categories: 
structural markup / inline / meta information / OTHER.

Also, some extra material has been added as a result of feedback.

cheers,

Jason

-- 

Jason Harrop
CTO, SPEEDLEGAL
jharrop@speedlegal.com

Melbourne
Mob +61 (0)402 02 66 34
Tel +61 (0)3 9670 0141
Fax +61 (0)3 9670 0142
www.speedlegal.com

SmartPrecedent(R) software
The most intelligent way to create documents

OASIS LegalXML eContracts TC Requirements Process

Scenario - Enterprise Contract Management

Name Enterprise Contract Management
Principal Stakeholders Legal and Contracts Professionals in Corporations and Government
Scenario Owner [name and email]
Draft Number 2
Draft Date 11 March, 2003 - Edits to take account of comments on draft 1; re-arranged requirements into new categories;
Contributors
  • Jamie Wodetzki, jw@speedlegal.com

Introduction

This document is a scenario developed as part of the eContracts requirements process.

The purpose of a scenario is to provide a context for a set of requirements important to some group of end-users (in this case, Contracts Managers). A scenario is intended to help members of the working group to understand the drivers behind stated requirements.

To that end, this document contains a Scenario Statement, and a set of Requirements extracted from the Scenario Statement.

As per the requirements process, contributions to this scenario are welcome. Please send your contributions to the Scenario Owner. The Scenario Owner will decide whether to accept your contribution or not. If your contribution is not accepted, you may create your own Scenario. For further details, please refer to the process document

Scenario Statement

Written contracts play an increasingly important part in the regulation of modern business relationships and transactions. This is especially true for corporations and governments using outsourcing and partnering to find more efficient ways to do business. And with a growing focus on regulatory compliance, the number and complexity of written contracts is rising steadily.

Many large enterprises can find themselves managing hundreds, thousands, and sometimes tens of thousands of contracts. These include buy-side contracts with suppliers, sell-side contracts with customers, and various other contracts with business partners, investors, employees, etc.

Contract Management Today

Responsibility for these contracts can be shared between line managers, contracts professionals, lawyers (internal and external) and administrative staff. In a typical scenario, a line manager will agree the key commercial terms of a contract; the lawyers and contracts professionals will settle the final detailed terms and conditions (with or without negotiation); and the line manager/s will manage the performance, renewal and completion of the contract, often with assistance from specialist contracts managers. The lawyers may also be called upon during the life of a contract to assist with reviews, amendments, renewals, disputes, etc.

In general terms, the lifecycle of a contract includes several phases:

  1. Contract Creation
  2. Contract Negotiation
  3. Contract Execution/Signing
  4. Contract Management/Performance/Amendment
  5. Contract Extension/Renewal
  6. Contract Termination/Completion/Expiry
  7. Contract Archiving

To date, most written contracts have been managed through these phases manually, and with little by way of automation. A typical contract is manually created in a word-processor; negotiated by exchanging multiple drafts in printed or electronic form; signed as a paper document; filed and stored somewhere (in hard and/or soft copy); and then managed (or not managed) against key performance milestones, dates and events using some system, which may or may not be electronic and automated.

The management of amendments in long running contracts can itself be a major issue, as some of these amendments can themselves involve long and complex negotiations taking months to possibly even years to negotiate.

As the volume and complexity of contracts gets greater, any problems with this approach are becoming more acute. Many enterprises are looking for improved ways to manage their contracts through each phase of this lifecycle. Key business drivers for the automation of contracts management include the need for cost savings; the need for improved compliance and risk management; and the need for faster more flexible processes in order to remain competitive.

Some of the problems with the current approach to contracts management are set out below:

  1. Too much time is spent proofing, reviewing and signing off each contract. When a contract is drafted using a standard word-processor, there are no constraints on what end users can change in the document. This means that extra care is needed to ensure document integrity - for compliance and risk management purposes. A suitably experienced person must manually read and check each contract to ensure that key clauses are included, pricing is correct, correct party names are used, there are no provisions that contravene applicable laws, regulations and corporate policies, and so on.
  2. Too much time is wasted during negotiations keeping track of multiple versions of a contract, and ensuring that changes are properly marked up on the "right" version. With multiple copies of each draft flying backwards and forwards between the different parties and their advisors, it is difficult to maintain a clear audit trail showing each consecutive draft, the changes made, who made them, when, and why they were made.
  3. Time is often wasted resolving technical problems with inconsistent document formats. Users with different WP software, or different versions of the same software, can spend hours converting and reformatting documents. Users can also waste valuable time cleaning up document styles, numbering, cross-references and the like.
  4. Once the terms of the final contract are settled and the contract is signed, there is no automated way of extracting key dates, milestones and other details from the document. A "real person" has to read the document and manually copy this data across into a contracts management/tracking system. This increases the risk of data error, and adds significantly to the cost of managing each contract.
  5. It can be difficult for finance/account managers to track the revenue which ought to be flowing from individual contracts and the portfolio as a whole, and reconcile actual versus expected.
  6. With contract data trapped inside an unstructured proprietary document format (eg Word's .doc format), it is very difficult to prepare useful reports across a large contract portfolio. If there's no automated way of preparing these reports, management may not have sufficient information to make important business decisions. For example, if management is in negotiations involving an exclusive grant of rights over a particular product, they need to know if any existing contracts grant rights over the same product in a way that conflicts with the proposed exclusivity.
  7. The costs of mis-managing contracts can be extremely high. Without a system for tracking key dates, for example, it is easy to lose the benefit of special rights and options worth thousands or millions of dollars.
  8. Some contracts are required to be retained and archived for many years, yet there is no guarantee that the proprietary document formats in use today will be supported in years to come.

The role of XML in Contracts Management

Creating and managing contracts in a standards-based XML format will help to solve many of these problems.

For example, with XML contracts:

  • it's much easier to develop tools that ease the pain of checking and validating document integrity.
  • it's possible for different users to work on different parts of a contract simultaneously, and for the status of different clauses to be individually tracked over time (eg, not agreed, proposed, agreed).
  • users can exchange and collaborate on contracts using a wide choice of applications, without the document conversion pain associated with the exchange of proprietary formats. Some users will continue to exchange contracts in common output formats such as RTF, PDF, HTML, etc, and it will be often be necessary for XML documents to be transformed into these formats. However, many users will benefit from the exchange of a native XML contract format, using a variety of XML-aware applications.
  • users can focus on getting the content right, without having to waste time on formatting, numbering, etc. Stylesheets can be used to ensure that consistent corporate styles and numbering are applied to the contract in its final, executed form.
  • key contract data can be intelligently marked up, so that the data can be automatically extracted, managed, reported, and shared across a wide variety of enterprise systems. The improvements to enterprise data portability will greatly simplify systems integration, and will deliver substantial cost savings.
  • the document can be archived with much less risk of losing application support over the years to come.

Examples of the types of data that enterprises need to track and manage are set out below:

  1. Title of the contract. This will generally reflect the type or subject matter of the contract, and will be useful for classification purposes.
  2. Party names and details. This will make it possible to report on contracts with particular suppliers, customers or partners.
  3. Dates for signature, commencement, termination, renewals, milestones, and the exercise of special rights. For example, a company may wish to create a report of all active contracts using these dates to include contracts that have commenced but not expired. Or, a company may wish to trigger a reminder of all contracts coming up for renewal 90 days before the relevant renewal date falls due.
  4. Value of a contract. For risk management purposes, contracts over a particular value may need to follow a different workflow/approval process than contracts of lesser value.
  5. Subject matter of the contract. In supply contracts, for example, it will be useful to know the product or service being supplied. Or, in licensing and technology transfer contracts, it will be useful to know the intellectual property asset/s over which rights are granted.
  6. Exclusivity, territory of rights. Contracts involving the grant of rights may be exclusive and may be limited to certain territories. It is important to ensure that exclusive contracts are not granted in conflict with other contracts.
  7. Prices and the items they relate to. Price information often varies across different contracts and customers and without a clear view of the agreed price for a particular customer, there's a greater risk of under/over charging.
  8. Exclusions, limitations, indemnities affecting liability issues. For risk management purposes, companies need to understand their overall exposure to liability across a portfolio of contracts. The ability to identify contracts where liability is not excluded, capped or limited allows a company to identify where its exposure is high, and this the need to manage the risk is greater.
  9. Governing law of the contract. For compliance purposes, a enterprise needs to know that contracts governed by the laws of a particular jurisdiction have been reviewed for compliance with those laws.
  10. Obligations and what has been done / not done to meet them.
  11. Other metadata to aid tracking and retrieval, as is relevant given internal business processes
  12. Conditions precedent which trigger the operation of the contract.
  13. Contract interdependencies linking head and subcontracts.

Summary of Key Benefits to Stakeholders

  1. Improved compliance
  2. Reduced costs of creating, negotiating, and managing contracts
  3. Better risk management
  4. Faster, more flexible business processes

Requirements

The following requirements have been extracted from the Scenario Statement.

Important Note regarding Traceability: Why each requirement is important should be clear from the scenario above. If it isn't, the scenario or the requirements should be amended.

Structural Requirements

  1. Ability to model the structure and content of the full range of contracts used by corporations and government (including schedules).
  2. Ability to transform the contract into common output formats, with styles, numbering and cross-references automatically applied.
  3. Ability to deliver a draft or the final XML eContract in its XML format (ie as a single file which the recipient is able to work with)

Markup of Particular Information (Inline Markup)

  1. Ability to mark-up key contract data which needs to be tracked and managed. Examples of the data set out above:
    • Contract title
    • Parties
    • Dates
    • Exclusivity
    • Territory
    • Exclusions
    • Limitations
    • Indemnities
    • Prices
    • Governining Law
    • Obligations
  2. Flexibility to allow specific organisations to mark-up additional data relevant to its internal operations.

MetaInformation Requirements

  1. Ability to break the document into clauses, sections, articles and other "modules" so that the status of specific clauses, etc, can be tracked
  2. Ability to mark-up key contract data which needs to be tracked and managed. Examples of the data set out above:
    • Contract value
    • Subject matter
    • Conditions precedent
    • Contract interdependencies
  3. Ability to identify the changes between different versions of a clause
  4. Ability to identify the changes between different versions of a contract
  5. Ability to capture the reasons for a change, when made, and by whom (for audit trail purposes).

Other Requirements

  1. Ability to break the document into clauses, sections, articles and other "modules" so that different authors can work on different modules
  2. Ability to check the actions of the parties to determine whether there is (or is likely to be) a contract breach
  3. Ability to analyse history; risk assessment; performance measurement of trading partners

Notes

[Any additional notes].



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]