Hello
all,
Great meeting today! Rough draft minutes are below.
Please let me know if you have amendments.
We are on the launch pad .
. . here we go!
Cheers, -
Dan
============================================== | Daniel J.
Greenwood, Esq. | Director, E-Commerce Architecture Program |
MIT School of Architecture and Planning | 77 Massachusetts Avenue, Room
7-231 | Cambridge, MA 02139 | http://ecitizen.mit.edu | or http://www.civics.com | dang@mit.edu ==============================================
------------- EContracts
TC Meeting 2-13-03, 5pm Eastern Time
Present:
Sergio
Maldonado Jim Keane Dave Marvit Barry Hanson Daniel Greenwood,
Chair. Greg Wiley Jason Harrop, Vice Chair Rolly Chambers Dmitry
Radbel John McClure Jamie Clark John Messing
Minutes
Dan
opened, called roll, and set agenda to deal with requirements. First
asked Jim to give quick update on Kavi system.
Jim gave Kavi explanation
and update.
Jason discussed requ process and started looking
at requirements
1. Jason: Law Firm scenario was described.
2.
John McClure: DCN scenario. There should be 7
structural elements. They tried to identify content within
each layer. Things like section, title, etc. - Second area
is known as "terms". Things like substantive areas of legal
terms. This was detailed, and he will send a general higher level
abstract according to the template created by Jason.
Group agreed to
use Jason's template for expressing scenarios as a standard way to
communicate them.
Jason asked that in functional requirements
section, people discuss what proposed requirements are unique as a
particular economic or legal domain.
Jamie indicated that it may not be
all that useful to try to assert the narrow economic/legal domain up front
- it comes out better over time.
Dan indicated it may be best to do it
anyway, because it makes sense to see the context up front
for requirements. Jamie and Rolly agreed.
John Messing said we
should come up with a generic process first, then go into specific types.
Rolly, contracts issue does however suggest looking at each context
as well.
Dan - proposed that we have people give all
their requirements and simply indicate context and special uses, and then
we figure out later what is the core and generic elements. We'll get
full sentences, and it will include unique vocabulary, but we will
distil the underlying grammar.
Jason - our job is quite complex, and
what we are interested in capturing depends on WHY you are interested in
doing it electronically. Probably at end of the day, we'll get a
grammar, like in Court Documents. Understanding the sorts of contracts
we would like to represent will help us understand the context and the
"why" people want to use the information.
People should state which
info model is important and why. Jason agreed to send along another
template more explicit about this. Jason asked if people on the call
would say if they plan to send more requirements.
First, however,
John McClure said he is concerned that if TC gets too far into the process of
creating the contract, rather than the info model of the contract itself,
then we'll create a standard for the application instead of the way to
represent the info in the contract itself! He suggests that this
inquiry be limited to post-executed contracts, not the contract
negotiation process.
Jason said that he figured we'd end up with what
John M said, but it is helpful to discuss earlier process when lawyers are
understanding what we are talking about.
John M said he liked the way
Jason was going. There are many different types of contracts
(adhesion, partially negotiable, tabula rasa, etc).
Dan suggested
knowing the process will be helpful, even if we don't include it in final
spec.
Dave M said that allowing some sort of hooks, or meta data,
dealing with "parameters" will be important for automated
contracts.
Jamie said that parameterization is critical for
auto contracting.
Discussion of what is and is not
negotiable.
John Messing said that it may be useful to indicate what
is and what isn't negotiable.
McClure said that it may be better to
disentangle the negotiation issues from the final contract content.
Perhaps a meta document associated with the contract for negotiating
part.
Marvit - that is consistent with what he is saying, so long as
there is a way to reference it back into the core document.
Messing -
be careful when trying to automate contract.
Dan - me, Marvit, and
Jamie. We'll work on the automated negotiation scenario. Will
invite Grosof. Messing too, if interested.
Sergio - he will provide a
scenario for digital aspects of negotiation process.
Jim - he has done
some ISP contract management and hopes we'll start talking about those
aspects.
Barry H - as a downstream user (his product) needs to deal
with final contract. Needs to know final structure, no what was
negotiable.
Jim - three areas: negotiation, final content, contract
management,
Dan - added final phase: dispute resolution.
Jim and
Barry - could also indicate things like "claims made" etc.
Messing -
Could also have concept of "breach". Are there remedies.
Dan -
we can always later at end of requirements process narrow scope, so for now
let us invite a broad set of requirements.
Jason - when are new
scenarios coming? Dan/Dave autocontracts in a couple of weeks; and
Sergio in two weeks as well. DEADLINE IS TWO WEEKS FROM TODAY
ON ADDITIONAL REQUIREMENTS. Two weeks after that for discussionof
requirements.
3. Dan called a vote, which passed unanimously,
that requirements be finished by close of business Feb 26th, and our next
meeting is March 12th at 5pm Eastern Time and that the TC plan to meet every
two weeks thereafter.
The template to be used
for contributing requirements scenarios and use cases is reproduced
directly below.
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 |
1 |
Draft Date |
February 7, 2003 |
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
- 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.
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.
- 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.
- #
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.
Functional Requirements
- Ability to model the structure and content of the full range of
contracts used by corporations and government.
- Ability to break the document into clauses, sections, articles and
other "modules" so that different authors can work on different
modules and so that the status of specific clauses, etc, can be
tracked
- Ability to identify the changes between different versions of a
clause
- 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)
- Ability to capture the reasons for a change, when made, and by
whom (for audit trail purposes).
- Ability to mark-up key contract data which needs to be tracked and
managed. Examples of the data are set out above.
- Flexibility to allow specific organisations to mark-up additional
data relevant to its internal operations.
Non-Functional Requirements
-
TBC - First requirement...
-
TBC - Second requirement...
-
Etc
Notes
[Any additional
notes]. |
|