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:
- Contract Creation
- Contract Negotiation
- Contract Execution/Signing
- Contract Management/Performance/Amendment
- Contract Extension/Renewal
- Contract Termination/Completion/Expiry
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
- Title of the contract. This will generally reflect the type or
subject matter of the contract, and will be useful for classification
purposes.
- Party names and details. This will make it possible to report on
contracts with particular suppliers, customers or partners.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Obligations and what has been done / not done to meet them.
- Other metadata to aid tracking and retrieval, as is relevant given
internal business processes
- Conditions precedent which trigger the operation of the contract.
- Contract interdependencies linking head and subcontracts.
Summary of Key Benefits to Stakeholders
- Improved compliance
- Reduced costs of creating, negotiating, and managing contracts
- Better risk management
- 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
- Ability to model the structure and content of the full range of
contracts used by corporations and government (including schedules).
- Ability to transform the contract into common output formats, with
styles, numbering and cross-references automatically applied.
- 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)
- 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
- Flexibility to allow specific organisations to mark-up additional
data relevant to its internal operations.
MetaInformation Requirements
- Ability to break the document into clauses, sections, articles and
other "modules" so that the status of specific clauses, etc, can be tracked
- 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
- Ability to identify the changes between different versions of a
clause
- Ability to identify the changes between different versions of a
contract
- Ability to capture the reasons for a change, when made, and by whom
(for audit trail purposes).
Other Requirements
- Ability to break the document into clauses, sections, articles and
other "modules" so that different authors can work on different modules
- Ability to check the actions of the parties to determine whether there
is (or is likely to be) a contract breach
- Ability to analyse history; risk assessment; performance measurement of trading partners
Notes
[Any additional notes]. |