Dan Townsend

Dan Townsend | Sales Director North Amercia, West

As with most business applications it is generally accepted that the degree in which the system is adopted in an organization is directly related to how easy and intuitive it is to use. Certainly, there are exceptions to this: complex line of business systems which are used by subject matter experts (e.g. financial, engineering, planning, etc.) typically require specialized training and skills to use effectively. However, applications that are cross functional (e.g. sales, procurement, legal, risk, etc.) need to bring a level of simplicity for the masses for them to embrace the technology. Contract Lifecycle Management (CLM) is one such example of an application that is used cross functionally and needs to organically flow with the organization’s culture and lexicon.

With close to twenty years of experience helping organizations move from manual processes of contract management that rely on spreadsheets, network folders, and email notifications, Symfact has always supported the concept of customer-specific configurations.

So, what does this configuration mean? It’s the gathering of the as-is and to-be business process as part of the discovery process and melding this with the core functionality offered by the CLM application to create a best practice within the organization. Not all ‘best practices’ that are touted by software vendors are truly best practices. The standard functionality offered by one vendor or another tend to be marketed as best practices; however, in many cases it is simply functionality that is unique to their specific product that they would like the market to embrace as a best practice.

According to Wikipedia the definition of a best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things. From a CLM perspective, a true best practice may be defined as one that has a common solution—such as the use of a template library—and molds this to suit the needs of the organization. This library might include the use of terminology that describe the type of template so that those requesting or creating a new contract can easily select or start with the most appropriate template from the library.

Another example of a best practice would be the creation of the Contract Record. The need to be very focused on capturing only the relevant meta-data about the contractual relationship is key. While buy-side, sell-side, or non-monetary agreements may have some common meta-data (e.g. parties, dates, contacts, etc.), there are a host of meta-data elements that are unique to each of these contract types. From an adoption—and a reporting perspective—it is critical to configure the screen layouts to the type of contract at hand, and the specific data and taxonomy that an organization requires for a specific contract type. The users that are creating the contracts want to complete their task with the least amount of data entry. To accomplish this, the screens need to only have the relevant data fields for that type of contract. This will help to ensure that the right data is captured quickly without having the wade through a multitude of irrelevant data fields to find the relevant ones. Users should only see that data required for their role and function for a specific type of agreement.

It is easy to overwhelm the user with too much data entry or too much complexity. If the user gets frustrated due to a lack of intuitiveness, they tend to circumvent the process. This will undoubtedly lead to undesirable results.
The design of the CLM system needs to be based on the needs of the organization and this is accomplished using common corporate language used for field labels. Required data needs to be highlighted and presented in an intuitive format. Not only will this require less training, but it will drive a much higher rate of user adoption.

Since 2002, Symfact has embraced the concept of client-specific configurations that leverage our mature CLM functionality as the foundation. We have found that the success of a CLM implementation is based on following what the client needs by configuring their installation (without any changes to the core code of the application) as their processes dictate. Removing the superfluous data fields to ensure a simple, yet effective assembly of the contract data and documents is necessary for success.