• Knowledge management for contracts is increasingly important, but classic management information systems fall short.
• Basic approaches to knowledge management include better management of contract documents and capture of contract “metadata” (ie, structured data about contracts).
• Contract metadata ranges from simple “fill-in-the-blank” information to more complex information about the contract document, such as whether certain types of contract terms appear, and can also include information about the contract that does not appear at all in the contract document.
• Capturing contract metadata — opportunities, challenges and trade-offs: a number of practical issues that contracting professionals should consider when thinking about capturing contract metadata.
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.
•If you don’t have metadata for all of the contracts of the relevant type, the program will produce incomplete (junk) data and unreliable search results. So the program should be mandatory. But there are limits on what you can expect of people before you encounter resistance and its by-product, inaccurate (junk) data. The implication: you can’t go overboard on manual coding or tagging requirements.
•The dreaded legacy problem (how to get existing contracts coded and into the system): Manual coding of existing agreements can take months, cost thousands of dollars and raise questions of quality control. Automated coding strategies are worth considering, even if they produce only partial coding. Depending on the duration of your contracts, you may decide to skip the coding of existing agreements and simply roll into the metadata program with new contracts over time.
•How will the coding or tagging get done on an ongoing basis? In some systems, metadata can be drawn from the automated contract creation process. This works where there is no possible corruption of the datapoints from the automated contract creation process through to contract execution (like in your Amazon book order), and where your own contract documents are used. Document-based tagging, where codes or tags are associated with particular clauses, can work where metadata corresponds to contract document text. But any manual coding or tagging (whether in contract creation or coding after-the-fact) will need to be done by knowledgeable, accountable persons who are motivated to maintain data quality.
•Because contract types are so different, there is a natural limit on how far you can extend a detailed metadata program within the organization. Still, a set of high profitability or high risk parameters (eg, specific contract terms) for a particular group of contracts could be valuable, even if it is not applicable to other types of contracts.
•Developing “enterprise” level strategic contract information, such as aggregated counterparty relationships, geographic or other global risk mapping, flow-through of warranties and indemnities, or matching buy-side with corresponding sell-side contracts, can support scenario planning and other strategic knowledge initiatives. Building out this type of contract information would require enterprise classification schemes and information modeling that will almost surely transcend particular contracting processes. You may have to reconcile competing views about what is relevant and how to define it. Alternatively, perhaps there is something to be said for allowing competing views to co-exist and be considered in parallel; this could create a sort of information system redundancy for validation. (For example, accounting standards, though the most definitive system of record, can hardly be said to be the last word on corporate prospects and risks.)
•Contract metadata schemes will not remain static. Business evolves, laws change. Beyond the fill-in-the-blank metadata, you can’t know for sure what will appear to be relevant in hindsight. But strategic metadata categories by definition may be relatively short term, and there will always be an element of the ad hoc. This is normal and natural in knowledge management, and does not suggest that there was something “wrong” with the original design.
•As in all cases where structured data is being used to simplify and abstract (think about your bank’s customer profile of you), relevant information may be lost. Structured data works by reducing information. In the case of contract, we need to maintain a healthy respect for the actual wording of contract documents as well as for the totality of the contract relationship. Depending on contract type, there are almost certainly limits on how far you can go — or want to go — in “transactionalizing” a contract relationship by reducing your knowledge of it to metadata. (We have all been on the receiving end of this approach in our relationships with our banks and other providers of consumer services.) Indeed, recent research suggests more potential in opening up what I call the “knowledge bandwidth” between you and your contract partners.
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.
Carolyn Paris, Information Systems and Innovation Group, Department of Management, London School of Economics, Email: C.Paris@lse.ac.uk
About the author
Carolyn (Carrie)Paris, a former corporate finance partner at law firm Davis Polk in New York City, has worked in legal knowledge and risk management. She is currently in the Information Systems and Innovation Group, Department of Management, London School of Economics, where she is researching IT support of contract.