Australian Red Cross Blood Service
Contract information in the networked economy
Contract relationships are becoming ever more essential to business, non-profit and governmental organizations. Operations formerly thought of as “core”, such as HR or distribution, are rationalized for outsourcing. Information technology has shifted from “build” to “buy”. Purchasers of complex goods and services are often looking to shift whole domains of risk to providers, and providers in turn seek to limit their obligations. Dependencies and risk exposures can extend to counterparties’ contracting partners and beyond (eg, supply chain risk). For many organizations, contract management is a core competency — and one that cannot be contracted away. Management techniques, including information and control structures, that used to reside within an organization have moved outward and become the subject of contract.
In this environment, organizations need better knowledge management for contracting. Beyond contract and legal compliance, there are risk management and strategic information needs, relating to (for example) valuation, counterparty relationships, supply chain risk, trends and patterns, market share or league table information, and mergers and acquisitions. More generally, contracting represents not only the organization’s principal economic exchange, but also its information exchange with the outside world. So contracting not only requires good knowledge management, but should also be a contributor to it.
Management information systems typically focus on transactions and financial accounting, developed to serve a different, vertically integrated business model. Enterprise resource planning (ERP) systems incorporate more and more of an organization’s internal operations into a structured database version of the enterprise. Neither seems to offer an ideal knowledge management platform for contracting in the networked economy. If anything, contracting is sometimes driven by these schemes (who is not familiar with the pressure to meet quarter-end targets?). A better place to start is with contract document management and the capture of contract metadata.
Contract documents versus contract metadata
Managing contract documents is fundamental to any knowledge management platform for contract. Organizations need to be able to locate the definitive, legally binding contract documents, even in those many cases where the contract document does not provide a complete and accurate picture of how the contracting parties are actually working together. Contracts, like other important corporate documents and records, need to be stored, preserved from tampering or inadvertent alteration, associated with other relevant documents and records, made available to those who need to see them, and protected from improper access. Searching for a contract document is not a question of “relevance ranking” — identification and retrieval need to be precise and exact.
Contract metadata means structured data about a contract
Structured data is information that has been organized under a classification scheme, so that it can be put into a spreadsheet or database. With structured data you can search, aggregate, calculate, test, report out and so forth — the information becomes more powerful in an operational sense than when it was locked up in documents.
Contract metadata is associated with the relevant contract through coding or tagging — for example, by identifying a contract by counterparty name, or attaching a product code to a sales contract for the product. Sometimes the contract metadata (eg, the name of the book that you buy from Amazon) associates to the contract automatically when the contract is made; in other cases, coding is a separate, manual process.
Contract management software, also called contract lifecycle management (CLM) software, typically incorporates (and integrates) contract documents and contract metadata as part of the product offering. However, a well-organized file cabinet of paper contracts indexed to a corresponding spreadsheet of key contract terms would also qualify as a basic contract document management system with associated metadata.
Types of contract metadata
Storing contract documents for precise and exact retrieval requires the most basic contract metadata: name or type of contract, party names and the date of the contract. These are the unique identifiers of the contract under a custom that goes back long before modern information technology. (Note that a standard document management system profile will instead focus on the electronic history of the particular electronic file: author, date created, edit history, access history.)
Depending on the type of contract, it might be easy to define additional “fill-in-the-blank” metadata: price, volume, discounts, delivery dates, payment dates, termination date, renewal date. These translate directly into compliance or alerts systems (or into an ERP system), and the advantage over manual processes is obvious.
Beyond fill-in-the-blank metadata, metadata tagging can support precise and exact retrieval of contract documents for further analysis where wording (eg, of change of control clauses) can vary, and text-based searching is not reliable. But other key contract metadata may not correspond to wording in the contract document at all — for example, counterparty credit risk, corporate group affiliation of the counterparty, or how the contract is categorized under various regulatory or accounting classification schemes. Coding of this more complex metadata can require analysis and judgment. Addressing some of the risk management and strategic issues (eg, extended interdependencies, geographic or political risk) to identify high profitability or high risk contracting may mean going beyond contract document wording to develop a more comprehensive but strategically defined profile of the contract, including contract outcomes.
Contracts vary significantly as to what I call their “data discreteness” — how much of their content can easily be captured in structured datapoints. A “click to accept” software license agreement is highly “data discrete”. The contract terms, like the background governing law, have become a standardized frame for the particular transaction, and the contract document has been reduced to an electronic record of counterparty agreement. Highly data discrete standard contracts can be managed in volume, including through strategies such as clause level management (contract documents are treated and managed as assemblies of clauses) or “management by exception” (contracts are standard unless otherwise indicated).
What contract metadata to capture and how: opportunities, challenges and tradeoffs
Deciding what contract metadata is important for your organization is not a technology issue, it is a business and strategy issue. Contract metadata can support the skills and knowledge base of contracting professionals, but it can also provide value to financial, legal and compliance, and risk management functions, as well as to the business units and senior management.
You don’t need to limit your thinking to data derived from contract documents or from the contracting process. In particular, if you have, or are planning, a CLM project, but even if you are not, and regardless of your technology platform, there is a potential opportunity to create and offer value with strategic contract metadata. Some of this metadata might (also) be the subject of risk management, so-called “business intelligence” or “client relationship management” initiatives, but it is still at the core of contracting competency.
You might start out with an ideal, comprehensive set of metadata that you think would be useful to capture. The following considerations may help you both scale back and reorient this vision.
Process- and document-defined approaches to contract metadata are unnecessarily limited; instead, targeted capture of contract metadata toward strategic knowledge presents upside potential for organizations and contracting professionals.
Capturing contract metadata is a matter of tradeoffs, and your expectations should not run ahead of what realistically can be achieved. But even partial, temporary and imperfect capture of metadata may be valuable if it is strategically selected and executed, not set in stone, and properly understood as potentially information-reducing.
If you have thoughts or experiences on this subject to share (on a confidential basis), I would like to hear from you, at C.Paris@lse.ac.uk.
About the author