10 Best Practice For Integrating Your Customer Data

1. You say integration, I say integration:
• Shared understanding of what you mean by "integration"assure better integration. Begin by establishing a common lexicon between all members of your team and all of your stakeholders so there is no misunderstanding or misconstrued intent or action along the way. It is never safe to assume that everyone is "on the same page''. 
• Whether you mean combining, sharing, or referring to information, integration must be result in people and the tools they use working better together to achieve common goals.  In the context of a customer data integration project, it is important that every stakeholder and every person involved share a common understanding of the end goal of the integration activity.
2. Have a plan with a measurable outcome:
• It must have a well-developed plan. The saying “A journey of a thousand miles must begin with a single step” has been attributed to Lao-Tzu, the founder of “Tao Te Ching. That planning begins with establishing a clear set of metrics by which to gauge the success of the integration, the fulfillment of the goals of the project. 
• Information aggregation is easier to achieve when you do it in stages, not all at one time. You should break objectives down into smaller phases to bring a higher likehood of success. Each phase seek milestones to measure progress, and to approach each of these more achievable steps in sequence building to the larger goal.
• Establishing, tracking, and achieving very specific metrics is your best strategy for assuring continued management support for your project. If the goals is to reduce the equivalent of Full Time Employees (FTEs) assigned to a task, how many FTEs do we intend to reduce? What actions will cause this reduction to occur? 
3. The real budget
• Know your "all-in'' budget, anticipating as many hidden costs and ''surprises'' as possible. The "price'' signifies the initial investment require to commerce the activity. The ''cost'' refers to ongoing Total Cost of Ownership (TCO). The ongoing cost of operating and owning the resource required to achieve the desire outcome.
• Don't limit cost to funds. Include time, skills, labor and other resources in your budget. Since the budgeting process includes ongoing cost, we must also consider the level of commitment required to sustain the investment and see it through to completion. 
• Consider comparative cost of outsourcing certain functions. 
4. Know the system
• The deeper your understanding of each of the systems involved in your integration project. By definition, the high-level goal of any integration project is to make thing work well together. Integration requires to understand what the customer knowledge and how their dependencies and connections are structured. 
• Remember that reality often varies from the documentation. Anticipate inconsistencies. You need to develop with API provided by each application. API may be match the reality; APIs were originally purpose written for a specific use case and may have been modified or adapted to some extent for general use. As a result, the quality of adoption may not always provide the facility required for your integration. You needs to map fields in one system to their corresponding counterpart in the others. You needs know identifying information, authentication credentials, and specific data elements to each others. It is also critical to develop a clear understanding of vendor limitation that may be imposed by trademark, licensing, and other rules of data. 
• Many integration tasks are on-time events. It may be more cost-effective to bring in an experienced installer for these. You must consider the experience of people who are familiar with the realities of the APIs involved. There are many upgrades, migrations, and installation activities that you have performed once you will likely. You determine the relative value of having an external provider perform these rather than investing the extreme time and training funds that can be consumed when you have your own people learn how to perform these one-tine them.
5. Map twice, integrate one
• You cannot get where you are going unless you are carefully mapped your way there. To do this will require that you sit down with all of the stakeholders and users involved and walk through each process. Get screenshots from each involved system to aid your understanding, and really fill that use case out before you develop your plan of action. When we refer to mapping, we’re not only addressing the mapping of like fields between databases, we’re also focusing on mapping out business processes step-by-step. This process mapping must be accomplished before any tools are purchased or approaches are considered as these decisions will often be deeply informed by the outcome of this all-important set of conversations with the users and stakeholders.
• Involving stakeholders every step of the way always improves mapping processes. Everyone involved must agree on how things are actually done in real life to assure that the systems adapt and support those activities effectively. Map each process specifically and in full detail. To do this will require that you sit down with all of the stakeholders and users involved and walk through each process. Get screenshots from each involved system to aid your understanding, and really fill that use case out before you develop your plan of action.
• Your ability to choose best tools depends upon careful and accurate mapping of information, processes, and people's role. This process mapping must be accomplished before any tools are purchased or approaches are considered as these decisions will often be deeply informed by the outcome of this all-important set of conversations with the users and stakeholders.
6. Garbage in, Garbage out
• Bad data discourages users from adopting new systems, slowing your project to a stop. When you evaluate system initiatives that have failed in the past in an attempt to determine where the project went off track, the likelihood is that the root cause was the failure of users to adopt the new system. 
• “Good” data is good in the context of the system currently using it. Each of the systems involved has a different focus, a different context that the data exists in, and may see specific data entities differently. These variations in context and focus from one system to the next must be considered when integrating data flows between them. Careful review during the integration process can often uncover flawed or less efficient processes that can readily be improved during the integration process. You may also preclude finger-pointing later as you prevent one department from accusing the other of having less-than-accurate data.
• Cleaning data properly almost always requires multiple passes, multiple processes, and painstaking vigilance. The ability of various systems to fully clean up data in any given database improves every year, but there are still going to be situations in which humans must review and cleanse the data, preferably prior to completing any kind of integration of those databases with others. Anticipate stopping your integration processes occasionally to assure that the data is clean and accurate. Include a staging process wherever possible so that data is staged somewhere so it is convenient to review and revise before completing each integration process. It may be more efficient to order the data by geography, or alphabetically by company or contact name, or some other sequence that facilitates rapid review. 
7. Selecting an approach
• Highest efficiencies are achieved when the process you create today can still serve you the next time and the next time. Scalability is always a key issue in any IT planning. Allowing for future growth avoids the need to discard investments and replace them with greater capacity solutions. This presupposes that one solution can and will do it all if it has sufficient capacity or potential capacity. Decisions regarding what approach to take and what tools to use to accomplish customer data integration should not be made based primarily on available technology, but rather on the needs of the business at any given point in time. 
• Break down the project into manageable tasks and prioritize each task prior to execution. Begin by breaking down the larger integration into smaller, more achievable pieces. The first phase should be a comprehensive planning exercise. This will help to set and manage the expectations of all stakeholders while also making it easier to present and obtain approval for your business case. When selecting tools to help accomplish each phase, stay focused on the importance of maintaining agility for the long run. Select tools that will continue to serve you independent of the actions of any of the developers of any of the technologies involved in your environment. 
• Be careful to only make changes that will survive the next vendor upgrade. Stick to the APIs wherever and whenever possible. This was the driving force behind the development of APIs which has helped many to preserve and enhance their agility over time. Remember that users quickly become impatient with anything they perceive as not providing reliability and value. In today’s cloud-based IT market users can easily obtain external solutions by subscribing on a website using their credit card. Make certain that your integration planning benefits from their observations and input. Users are the most important component to integrate tightly into your plans and your approach.
8. Design vs. Performance
• Resist achieving performance increases by going “directly to the data.” The APIs preserve your connection to the solution developer and their upgrades. We mention in the previous section how developers may modify their applications over time. This includes changes to the fundamental structure of databases, to the overall schema of the data employed in each platform. Having to then modify your own customizations and modifications created during integration of systems can be a very expensive proposition in terms of lost productivity, lost time, and repeated expenditures.
• Exercise caution when deciding to replicate data instead of integrating it.  The API exposes the application in a secure way allowing you to interface programmatically with their system. Instead of direct access to the database you are getting access to an application layer. While it is seems it would be faster to go directly to the data, performance can become an issue as each access requires authentication and careful checking to maintain database integrity. 
• When you must replicate, be sure to include an intermediary quality assurance step so you don’t transfer bad data. When replication is definitely required, consider using a three step approach that takes the data from the original source, replicates it to a staging area where it can be quality assured through various verification processes before it is finally passed along to the target environment
9. Setting expectations
• Manage your user’s response to your system first and foremost. It’s valueless unless they use it. Often users will not understand what will happen when, and how it will happen. In many cases, not knowing what is possible, they will want and expect the impossible. This must be managed from the beginning and throughout the integration process. The best way to assure effective user expectation management is to make users a constant part of the process, from consulting them during initial integration planning, to building in frequent User Acceptance Testing (UAT) rounds in your process. Find or create “champions” within the user base to help promote your cause.
• Commitment to specific results is critical, but remember that preserving some agility always helps. Much as technology providers issue a Statement of Work to inform their clients as to what will happen and what will be accomplished during any given project, it always helps to give your user community tangible evidence and clear communication of what can and will be done during the integration of systems and what functionality they can expect as a result. Keeping agility in mind, be sure to constantly remind users that your “statement of work” can and will change over time as a result of their input and other factors. This assures them that they have input into the process, and sets their expectation that nothing is “set in stone.”
10. Customer Involvement
• The real measures of success are the results users get from using your integrated solution. Properly executed, your integration activities will enhance the ways in which users work, increasing their productivity and therefore their job satisfaction. While your intended metrics may focus on number of records transferred, leads input, or hours saved, the real metric will be the adoption and acceptance by the users over time.
• The best way to prevent users’ fears is to keep them involved “hands-on” as much as possible. Part of your goal must be to mitigate these concerns by offering users many opportunities to get “hands-on” with your integration project as often as possible.
• Your project is only successful when your users are successful. Remember that data only gains value when it is in motion, and it only goes into motion when users are actually using the data to accomplish business objectives. Involve the users early in your planning and keep them involved throughout the project.