It’s an exciting time in your organization.  You’ve completed your analysis to select the system you need, be it PSA, CRM, ERP, etc.  You’ve just gotten approval on the contract terms.  You’ve gotten your system in house and are ready to sit down and make the magic happen.  You were smart in engaging a services contract from the vendor so you can get help in setting things up - no one knows how to configure a system right after they purchase it!  Now you’re tackling your first topic - let’s say it’s defining a customer.  You know what ‘customer’ means to your organization.  The Vendor consultant knows how the term ‘customer’ is defined in their system.  How do you know if you are saying the same thing?

Here’s the scenario between You and Bob the Consultant:

You: “I need to enter my customers into the system”
Bob: “OK, here are the fields that define what a customer is. Just let me know the values.”
You: “Where is my customer id number located?”
Bob: “We can setup a special field for that - how do you set it”
You: “We create one for each person in the account”
Bob: “So are they different customers?”
You: “No, they all work for the same company but they are different invoiceable entities by our company”
Bob: “So they are different customers”
You: “No, they are the same customer with different customer ids for contacts”
Bob: “Ok, so it’s a contact id”
You: “No, it’s a customer id that’s at the contact level”
Bob: “Ok, we’ll setup separate customers”

What happened in this innocent exchange of information?  Did you get what you needed?  You don’t understand or know the terminology of the system nor do you know the data model.  Bob doesn’t understand the business terminology used today by your team so he’s trying his best to figure out how you’ll need to access the data.  It’s the classic ‘But I thought you said...’ situation between business owner and system vendor. 

There are really two ways to handle this challenge:

1) find someone in your organization that has technical experience and can bridge that communication gap or

2) bring in a business consultant with experience in the vendor tools that can learn your business model quickly and do the interpretation.

The decision is one that actually needs to be considered back during selection of the system - does someone in your organization have a skillset already so you can incorporate the soft costs of using internal resources?  Do you need to plan an outside consultant which will be direct costs to the budget but provide deliverables that are amenable to the business model you follow.  Keep in mind the ‘soft costs’ of using an internal resource means you may actually be creating an FTE dedicated to the system which was not in the annual planning budget.

What is the most cost effective thing to do?  This really depends on your organization, the type of system you are deploying, and who you have available.

Some things to consider:

1. How similar is your business model to the vendor system terminology right now?  Consider this as part of your system analysis.  It may not make a difference in the weighted decision of features, but it will factor into your deployment budget.
2. How many users will be interacting with the system?  If it’s only a couple, then handling unique terminology of a vendor system would only impact a couple of people.  If it’s an entire company, you are facing either changing your business model terminology/process or answering lots of questions to help adoption and system use.
3. Do you have a skilled person internally to use?  If so, can you give them up to be a system administrator and backfill whatever job they currently have?
4. Have you budgeted for a system administrator or plan to have ad-hoc help?  Internal resources who are attempted to be used as ad-hoc will most likely fall into the ‘full time’ trap at least early on in deployment
5. Does the vendor have consultants that used to work for your company or a similar company?  This is a bonus!  Now you can save deployment budget by not having to bring someone up to speed on your business model.

As in any project lifecycle, the more time you spend up front in analysis, the better end product you will end up deploying.