GoldMine Data Analysis

Here’s an overview of CRM Switch’s GoldMine Data Analysis.  Whether an organization is staying with GoldMine, or switching to a new CRM system, this analysis will provide an array of useful insights into the current state of GoldMine data.  The analysis can be used to obtain greater benefit from GoldMine, or for implementing strategies around migrating data to a CRM system such as Salesforce.com.

Use CRM Switch’s analysis to determine:

• Overall trends in GoldMine adoption
• How disciplined users are in scheduling activities
• Whether or not older History records should be deleted
• Where file attachments are stored
• How much of a problem duplicate data is
• What fields are under-utilized or not used at all
• Whether pick lists are getting out of control
• Whether certain data should be normalized in the future

GoldMine Lookups vs. Salesforce Lookups

With a legacy contact manager such as GoldMine®, referencing another contact from within a contact record can sometimes require a very large (and ever expanding) pick list.

In this example, the business use is that contacts are members of a medical plan or HMO.  There is a need to select each member’s Primary Care Physician.  In GoldMine, this field has to be defined as a selection-type field, since GoldMine does not allow for linked relationships among contacts.

The result can be a very large, and user unfriendly pick list.  This type of field is also very one dimensional, as no other linked information about the physician (in this example) such as phone number, can be displayed based on the lookup selection.

In a relational CRM system, such as Salesforce.com, the Primary Care Physician field within in a member contact record can be a filtered lookup on other contact records — filtered for the contact type = “Physician”, in our example.

The Salesforce approach makes for a much better user experience and also is easier to maintain in the long run.  In addition, other information from the linked record can be displayed in the original record as show here:

Migrating CRM Data Isn’t Always as Easy as Point and Click

Data migration software vendors sometimes portray their CRM migration software as a simple, point and click, drag and drop solution.

While a packaged software approach may be fairly smooth for more straightforward cases of CRM data and database structure, the reality is that many data migration situations have complexities that make them difficult to manage using a GUI mapping tool.

For example, there can be a need for transforming data in a non-formulaic way — how data from a specific field is transformed can depend on the data itself.  Also, micro decisions may need to be made throughout the data migration process and these decision points can translate into numerous, iterative data loads.  Next, unanticipated instances of data cleansing may need to be performed part way through the process, which means hitting the brakes in order to take care of data quality issues.

For these and other reasons, certain CRM data migration scenarios may require manual intervention that’s beyond the capabilities of what a packaged tool can deliver.  Sometimes, it just takes good, old fashioned elbow grease to get the job done properly.

Synchronizing CRM vs. Direct Browser Access

A Brief History of CRM Data Synching

The need for remote users to regularly sync their contact manager or CRM data from a locally installed database back to a central database dates back to a time when the Internet was far less ubiquitous than it is today and a time when Web technologies and interfaces were not as advanced.

In the late 90’s and early 2000’s, the norm was for contact manager or CRM users to have a local application plus a local database engine installed on their laptop or desktop.  Users would have to connect to their company’s network and then click a button to push changes that they had made up to a central server and to receive any changes from the server.  In fact, quite a few organizations that started with synchronization between five and fifteen years ago are still running synchronization today.

The Costs of Maintaining Sync

While, for a time, synchronization was the only way to provide remote users with database access, it could be challenging to maintain.  Maintaining synchronization practically became a career for some contact management and CRM consultants.  It was also part of the job description for an in-house CRM administrator position.  The level of soft dollar costs needed to maintain a CRM data synchronization environment are often underestimated.

While long term maintenance of synchronization was normally not a line item on a contact manager or CRM quote, this maintenance could become very expensive in terms of soft dollars — including IT staff time and reduced remote user productivity.

Aside from the soft cost of maintaining synchronization, there’s always been a significant risk of user frustration and overall disenchantment with a system that relies on remote users synching on a regular basis.  The last thing that a sales rep needs when they are paid to produce revenue, is to be spending hours on the phone trying to get their database software to work properly.

Synchronization Workarounds

As a workaround to synchronization coupled with a locally installed application, some companies made the decision to adopt thin client technologies such as Terminal Services or Citrix for remote user access.  While this is workable with the proper infrastructure in place and the proper technical expertise, it creates an extra layer between the user and the application, as it can require the installation and maintenance of a thin client application, as well as a VPN client — which can mean an extra layer of authentication.

A Terminal Services or Citrix type client also creates a wall between the application and the users’ local desktop – a thin client cannot always interact with applications on a users local desktop, such as Outlook, Word and Excel.

Some vendors or third parties provided Web “bolt-ons” as another way to overcome the limitations of client/server application access.  They layering on of Web functionality created a variety of issues, from slow performance to a need for dual customization efforts.

Losing that Synching Feeling

Web development tools have become increasingly flexible and Internet access continues to be more and more ubiquitous.  The fact that you can now access the Internet on many airlines is an indication of just how available the Internet has become.

Eliminating the need to maintain locally installed software, and eliminating the need to support synchronization can represent a significant cost savings to many organizations.  With a browser-based application, users simply need to launch a browser window and securely log into their CRM application.

While CRM and contact manager data synchronization was once the only option for most companies, Web-based CRM technologies have evolved to the point that the synching feeling will soon be a thing of the past.

Contact-Centric Contact Managers vs. Account-Centric CRM

Legacy contact managers, by definition, are contact-centric in their design.  Each contact is a separate record and does not contain a unifying, company ID.  While a contact-centric structure is well suited for B2C sales and service, it can create some limitations in a B2B selling or service environment.

In a B2B selling environment, users often need to track information about multiple people at the same company — and they also need to track information about the company itself.  With a contact-centric application, contacts become placeholders for company information.  However, with no unifying company record, data can quickly become inconsistent — which means that there’s no single source of truth about a company.

In the simplified example below, two contacts from the same company have very different spellings of the company name.  One record identifies the company as a Prospect and the other as a Customer.  The “Prospect” record displays the company’s industry, but the “Customer” record does not.  The company’s fax number is in only one of the records.  Finally, in order to integrate accounting information, one of the Contact records had to be chosen as the record that contains the Accounting ID and is therefore the Contact record that shows sales order history for the company.

With an account-centric application, contact information lives in Contact records and company information lives in Account records.  History from multiple company contacts all roles up to the Account level.  Account level information, such as Company Type and Industry, can be displayed consistently in all related Contact records.  Sales order information from an accounting system can be associated with the company, rather than with a randomly selected contact.  This simplified mockup of a Salesforce.com Account view illustrates a unifying company record:

In a B2B selling and service environment, an account-centric application provides a much more consistent user experience and provides better information to people who’s job it is to serve prospects and customers.

Update – we have created a video on this topic.  For optimal, HD viewing, right click and select “Watch on YouTube”.