I tuned into an informative Webcast yesterday, titled, "Myths, Pitfalls and Realities of Contract Management Software." Hosted by IACCM's Tim Cummins and featuring Dan Ashton of imany, a company that sells contract management software, the broadcast discussed what you need to consider when you're choosing a solution to manage your many contracts. By "many," the number "50,000" was bandied about. Apparently, there are people who spend their days administering contracts for their companies.
Off subject a bit for a site that focuses on IT outsourcing, perhaps, but I tuned in because I wanted to learn a bit more about the IACCM, the International Association for Contract and Commercial Management, and because I thought I'd pick up some useful tidbits about managing contracts.
I'll cut to the chase. You can download a white paper on the topic of this talk here:
When I participate in these things, of course, I have as much difficulty picking through what's real and what's vendor hype. After all, the guest lecturer does have a vested interest in having the listener see the world of contract management from his perspective.
Given that, here's what I culled through and thought you might find useful.
1. Contract management ain't easy. so simple solutions probably aren't complete. Sure, the templatized stuff is straightforward — the paragraphs that your company always includes in every one of its contracts. It's nice to be able to go into the template and modify the text to reflect the current state of the company and know that that will be populated in every new contract written from here on out.
But the fact is that most contracts have a bunch of free-form text, and this isn't so easy to manage because it doesn't fit neatly into the fields of the typical relational database.
And integrating with ERP systems is *really* tough. As Mr. Ashton said, "That's why companies like SAP have been talking for years about contract management, but they haven't really achieved it."
Make sure the solution offers free-form text to accommodate the free-form nature of the content.
2. ROI on contract management solutions reside primarily with transaction compliance. In other words, does the price you're paying for a service or product match up with what's in the contract?
(Now here's where vendor-speak came into play…) According to Mr. Ashton, "You want to be able to look at individual transactions real-time and provide a resolution process. If you're being overcharged, you want to catch that and rectify that before it affects your profitability." His implication was that somehow the user administering the contracts should be able to catch those occurrences through audits.
By my thinking, a complete solution would integrate with your accounting systems so that oversite of overcharges would be automated. These transactions should be flagged automatically, so that the person administering the contract can do further research. To be honest, I don't know that such an integrated solution exists yet.
3. If the system is hard to use, it won't be used, making it shelfware. So make sure the tools that the user touches are ones he or she is already familiar with. I get the sense that in the case of I-many, that tool is Microsoft Word, because that's what Mr. Ashton recommended. Makes sense to me.
4. Make sure the solution accommodates flexibility. If you have to run to the vendor every time you need to make changes, the service fees will pound you. When watching demos of software, have the presenter walk you through such activities as adding a new contract type where tables will have to be modified, deleted, or added. Learn how the tools work — step by step — before you buy.
Along the same vein, if the vendor tells you, "Well, we can configure that," that means you're going to pay for a vendor programmer to write specialized code for you, which will delay implementation of some aspect of the solution you need and cost you more money. (And upgrades in a highly customized solution can be a bear!)
According to Mr. Ashton, the white paper his company published, which I referenced above, includes a chart showing the kinds of functions you should be able to handle as a customer without going the vendor configuration route.
5. Consider solution performance and interface. As Mr. Ashton rightly pointed out, "Every time you click on a tab to go to another contract, in the demo, it might be fast — the database may have only 10 or 20 contracts. If you're touching that same database in your organization, it may have 50,000 in it." That's bound to slow down operations.
Likewise, the pretty demo interface may not be so pretty once all the fields your company cares about is crammed into a single screen.
6. Make sure you've got your IT folks on board, especially during the evaluation phase. With them, there may be implementation details that can be sped up — or that may make or break the decision about going with a particular vendor. ("What? You can't roll this out to 2,000 users without adding some servers or bandwidth?") Without them, there may be technical obstacles you're not aware of, which can drastically increase implementation time and charges.
7. Make sure the vendor you go with has staying power. There's nothing like choosing a product that won't be supported in a year or two, because the developers got bored and went onto something new. To ensure financial stability, if they're a public company, do research on what's been published about them in the past year or so. If they're privately held, request an audited financial statement. Googling for bad news can be fun and entertaining — and informative!
8. Homegrown systems may appear less expensive on the surface, but development work always turns out to be pricier and more time-consuming than you think it's going to be.
A last point: Mr. Ashton makes a plea for going the managed service route — which certainly has its benefits. Among them: Deployment can be sped up, since it doesn't involve touching every user's desktop or IT's servers. Likewise, you may be able to pay as you play vs. a large capital expenditure up front.
Interested in hearing Mr. Ashton for yourself — and having the chance to ask questions? He said his company would be hosting a Webinar on the same topic on March 10, 2005 at 11 a.m. Pacific time. Monitor http://www.imany.com to find out how to register.