You are currently browsing the monthly archive for September 2009.

You’ve worked hard developing  your Company Public site and Agency site.  You’ve added all the right features and functionality while utilizing the latest technology.  You’ve been successful — the public is driven to your site to “check you out” and your agents/agencies are trained and using their site.  All the benefits you had hoped for are being measured and realized.  Now you’re in maintenance mode for both sites.  Additional features and functionality are being added to keep the sites aligned with your business.  You’re moving along the maintenance cycle without any obstacles. 

Then it happens!  You get a call from the Executive Vice President of Product Development who happens to have a Universal Life policy with the company.  She asks “Do I use the public site or the agency site to check the cash value on my UL policy?”  You’re stumped, so answer “NEITHER”. She is stumped as well and states “I have an annuity product with AnnuityGeneric Insurance Company and I just went out to their Policyholder site and reviewed my cash value and changed my mailing address – all within a matter of minutes.  Where is our Policyholder site?”

This situation is not unique. I find that a majority of my clients have awesome Public and Agency sites, yet few have Policyholder sites.  Of course I always ask “WHY?”  Why not have a Policyholder site?  Are your Policyholders not as important to you as the general public?

As we know, Consumers today (all of us) are technology savvy.  We use our computers and laptops to shop, communicate, BLOG, read newspapers, etc.   Basically, we use our computers to do almost everything except maybe check our insurance policies.  It’s not that we choose not to, it’s that we don’t have the opportunity because your company does not have the site in place. What a lost opportunity this is for both your customers and, most importantly, your company.  

Over the last 3-5 years larger insurance carriers have started to develop very sophisticated Policyholder sites. Yet I still see many middle tier carriers who have not made the investment.  Again let me ask –

“Are your Policyholders not as important to you as the public or your agents?”

If you’ve answered, “YES they are just as important” – then where is their site?

Prior to starting analysis and design, I sit with my clients and we decide on the functions/services that can be provided via the web that are most important to policyholders.  Figure 1 below depicts some of the common yet most important functions.

Policy holder functions

Figure 1

Some of these functions help to alleviate the number of calls coming into your call centers.  This frees up your Customer Service Reps (“CSR”) to concentrate on the more complex and challenging transactions and calls.  Other benefits as noted:

  • Pay bills online
  • Communicate using email
  • Policy inquiry
  • Claim inquiry
  • Research other products offered
  • Simple quote capability

 As the analysis and design of the site starts, the game plan begins with identifying the most important features and functions for site.  From there, development and deployment is completed in iterations.  This gets the initial site up and running with the most critical features and functionality, while maintaining the ability to add and deploy additional features later.   Figure 2 below depicts this strategic approach (“play”).

Policy holder playFigure 2

What is preventing you from developing that much needed Policyholder site?  Realize one thing – not having one places you behind your competitors.  Jump on board now.  Wait too long and you eventually miss the “Policyholder” game.

CRM systems, in one form or another, have been around for as long as selling has.  And, to tell you the truth, they haven’t changed much over the past decade or so.  Technologies and vendors may come and go, but leads, accounts, contacts, pipelines, and so on are constants.  That’s the way sales works after all.  What this means is that vendors already have their required functions, features and application layout identified.  So they can spend the bulk of their time slickening their technology; figuring out ways of streamlining the sales process for salespeople; and providing relevant information for executives. 

So, if we assume that most vendors have the features, why do so many CRM software selection processes begin with matrices of 1000 matrixor so features, when we all know that a vendor in the running has what we need?  And if something like pie charts vs. bar graphs makes the list as “high”, you’re left with your eye on something other than the ball, the scales are tipped to pet features, and you’re left trying to pry Act! or Excel contact lists (or whatever) out of your sales-peoples’ hands and they say big brother’s cramping their style.  6 months down the road you’re trying to explain why adoption is such a challenge.  Was the wrong software selected?  Many wise analysts then say:

“it’s got nothing to do with the software, it’s…lack of executive support; or poorly defined business processes; or looking back vs. looking forward; or not tying use to compensation”.

Of course, these things have left many a CRM project DOA, but picking the right software does matter.  If you focus on a technical fit for what you’re trying to accomplish as opposed to consensus building with overwhelming weighted matrices, you can get rid of lots of noise and make a good decision.  Here are things to weigh heavily, in order of importance:

Think Vendor Before Software

There are literally thousands of CRM vendors, but in the enterprise space they can be whittled down fast.  (These folks, Gartner,  and others provide lots of insight).  If you’re an SAP or Oracle Applications Shop (that includes Siebel), the playing field is NOT level (see Be Realistic… and Integration… and Data Conversion… below).  Save yourself some time and focus on implementing your CRM module effectively.  Those camps aside, if you go with a small or middle market vendor, or one that’s losing market share, you run risks of:

  • your developers not being able to Google sample code (if you don’t think this is important, ask your developers),
  • poor support,
  • bad/incomplete documentation, or
  • (not least of all) poor perception of quality/or importance of the initiative from your sales force.

Salesforce.com and Microsoft Dynamics CRM are almost always left standing.  It’s hard to justify the exclusion of market leading Salesforce.com (unless you’re in the process of getting rid of it because it’s too expensive), and Microsoft is gaining ground because everyone out there has at least half the Microsoft infrastructure stack in place already (an unfair advantage, but one that shouldn’t really be overlooked).

Selecting an established, top software vendor that tracks with your IT strategy can help your implementation team tremendously and as such reduces your overall risk.

Integration Is Huge

OK, so back to “what you’re trying to accomplish”.  You’ve probably been involved in at least one “360 degrees of the customer” project.  That’s because it’s what everyone needs.  Not least of all sales.  Having the whole picture in one place provides incredible benefits and efficiencies.  So often “integration” is a line item buried in the technical section of a selection matrix that’s covered as an afterthought by techies once the real decision makers have left the room. 

The reality is that the ability to leverage all of the data you have about your customers IS competitive advantage.  And CRM software alone won’t provide that since all the information you need will probably not live in your CRM system.  You won’t regret putting a good amount of early, detailed, thought into how integration could work with each vendor’s solution:

  • What data will not/can not be in CRM
  • do salespeople need it
  •  if so how and where will they see it
  • how much data are we talking about
  • is real-time access required
  • what are performance requirements
  • what changes will be required to my integration architecture to provide this access
  • what programming languages/techniques will we need to know to provide this information

Odds on you’ll spend well over half of your time and money developing and testing integration code when you get into the project even though this will likely represent only a fraction of the functionality.  But those little snippets can make a game-changing difference (e.g. this customer that you’ve called 18 times over the last 5 months and is just about to place a monster order hasn’t paid their bill since last July – they should probably be on another contact list. OR, this customer that has always needed our stuff and was almost broke was just bought by Sun, which was just bought by Oracle and they could probably use about two and a half bajillion of our widgets asap). 

Detailed thinking about how the integration will work with a CRM technology can lead you to the right software and hosting option.

Be Realistic About Your Technology Competency

So maybe you’ve got it down to Salesforce.com and Dynamics CRM.  They’re comparable products, market leaders, they look good, and the sales team could go either way.  But the technologies that can be used to customize and integrate these solutions are quite different.  It’s a good idea to take stock of your technical skills to make sure you understand what development and support will look like.  On the upside, both technologies provide Web service interfaces which provide a good level of interoperability with other systems and a broad range of tools.  From that point forward, however, it’s a good idea to consider your internal development skills. 

Dynamics CRM developers will spend a good amount of time using Microsoft Visual Studio with either C# or VB using a Web service API.  Within the administrative UI, quite a bit of JavaScript is used, iFrames are pervasive, and a good amount of custom code may be implemented with CRM Plug-ins which can be a bit quirky until you get used to them.  The Salesforce (SFDC) model has support for a broad range of programming languages in addition to C# and VB.  Developers have a choice of online or an Eclipse-based tool with which to develop.  SFDC has a relatively mature cloud development model relying on their Apex programming language (similar to C# and Java) which does have an associated learning curve.  Of course, both tools are Web-based and as such require developers to have HTML and JavaScript (JScript) skills. 

So, if you have MS developers and go with MS CRM you’ll have an easier curve and you’ll probably find that your developers are comfortable and productive quicker.  If your developers are a curious bunch that tends to sink their teeth into new things and have a demonstrated ability to produce as they learn, they’ll like SFDC.

In the realm of mature, best of breed CRM packages, it’s impossible to say that one is the best in all situations and for all organizations, but you can pick the one that’s best for you.  Being realistic about your technology competency can drive you in that direction.

Don’t Underestimate Data Conversion

Data conversion effort and approaches seem to consistently get under-sold and under-thought.  If you’ve boiled it down to either MS Dynamics or SFDC, you’ll probably find that the online conversion tools will not work for you in real world scenarios, which will leave you with Scribe on the MS side and the APEX data loader for SFDC, which are comparable products.  Starting early and getting a solid idea of what you’re up against (in terms of complexity and performance) will pay off big, especially if you’re able to do some strawman testing as part of the software selection/evaluation process.  Performance for each of these conversion tools will not come close to approaching performance of loading data with straight SQL– an option that’s only available to the best of my knowledge with the MS on-premise tool.  

So just consider, for example, that if you’ve got 2 million records and early testing on comparable hardware to your production system is indicating .5 seconds per customer record with a tool like Scribe or Apex DL, you’re looking at 12 days for a one time conversion.  Compare that to a similar load using SQL and you’ll see that this can be very significant.  Another thing to remember, you’ll have to load data more than once: you should account for associated entities like opportunities and orders, mistakes, updated/delta data, multiple environments, failures due to inconsistent data, mapping issues, network and hardware failures, lack of disk space, etc.., 

If you give data conversion a good deal of detailed thought early on, you can significantly reduce downstream risks by understanding technology options, planning the project effectively, and synchronizing conversion milestones with other efforts.

Be Creative With The Feature Comparison

Of course, the process of feature comparison is important.  But software can be weak in surprising areas; and limitations can be hard or impossible to uncover when reviewing feature matrices.  A better approach, and one that can help those involved in the selection process visualize strengths and weaknesses, is to create demonstration scenarios that focus on business processes and usage patterns that are unique to your business.  SFDC and MS Dynamics are both very easy to customize and demonstrate, and both offer online versions for demonstration purposes.  Investing a few days early on to identify, configure, and review CRM use cases specific to your business is well worth the effort.

Focusing your efforts on demonstrating software as opposed to creating detailed matrixes can help your users visualize the future state and can underscore software weaknesses that wouldn’t otherwise be obvious.

Narrowing your CRM software search early to top players can save lots of time, keep momentum up, and set you up with technology that you can sink your teeth into.  Whereas going through the motions – that is, letting a weighted matrix make the decision for you – can result in skewed priorities, lack of clear focus, and could result in you and your company struggling with mismatched technology.  Detailed technical thought during the selection process takes time and effort but can ensure that you get on and stay on the right CRM track for your organization.

Some great feedback on my previous post – “Straight Through Processing & Underwriting  -  The Starting Point”.

Many thanks to those who responded with your comments and feedback.

In that post I stated: “STP helps to drive efficiency and consistency” throughout the life cycle of all policies and that insurers need to start with their underwriting process.  Many of you posed the question “What about the new business process as well as workflow processing — why are these not part of the starting point well?”  A+ – Congratulations – THEY ARE!!

Fact: Underwriting is a set of guidelines that determines the eligibility of a client to receive an insurer’s product. New business rules determine if the client meets the product’s prerequisites as defined by the insurer.   One differs from the other, yet both compliment each other in the final decision process.

Fact: New business coming in the door for an insurance carrier starts the business process for new policies.  It only makes sense then that this starting point for building a solid STP business models resides in both underwriting and new business processing.  They support and complement each other hence the need for both to be worked concurrently.  Supporting these two functions is a much needed workflow management process/system.  All three business functions forms the foundation you need to continue to build your STP process.

Working extensively with our clients to forge a path to a full fledged STP business model, we begin building this foundation by reviewing and dissecting both their underwriting and new business processes.  We also begin the much needed workflow analysis and build process.

Underwriting Guideline Review

The focus here is to concentrate on the underwriting guidelines that support each product within a given product portfolio.  We review manual and automation processes.  We determine what guidelines are consistent within the portfolio and what guidelines are unique to a specific product within the portfolio.  Once we have a clear understanding and have the details we DOCUMENT!  Documenting this process is no easy task and is often what prevents insurers from this review process.

New Business Rules Review

As with the underwriting guidelines, the focus here is on the new business rule sets that support each product within the portfolio.  This tends to be more grueling since each product in the portfolio is unique.  We look first for common business rules across all products in the portfolio, then determine what rules are unique by product.   Again once we have a clear understanding and the details we DOCUMENT!

Workflow Review

Often overlooked in the early stage by insurers is the need for a detailed review and possible re-alignment of workflow procedures.  Workflow is what moves your policies through the new business and underwriting process and is critical to the success of your STP initiative.  This step must occur concurrently with the underwriting and new business reviews.

Figure 1 below depicts the business process model that can be followed to develop that solid core foundation needed for your STP.

stp workflow

FIGURE 1

With that stated I hope this helps to address the questions and comments from my previous post.  Now I must end with asking this question – if you have your core foundation what is your next step in the STP process?  From my perspective the next step that I take with my clients is ……. to be continued….

Remember the last time you needed a real person to give you directions?  Some people provided milestones and markers, making it easy to find your way.  Others were a lot more vague and in the end, not very helpful.  How often did you end up completely on the other side of town, nowhere near where you wanted to be, and you had to go back and retrace your steps trying to figure out where you went wrong?  This only resulted in increasing your stress level and causing you to be late.  Such was was life before the wonderful technological advancement of auto GPS systems.

You’ve spent a lot of time selecting a vacation spot on the beach you’ve never been to before.  Your flight has arrived and you’ve picked up your rental car.  Now what?  How do you get to your final destination?  Do you just drive until you hit the coast and start searching?  No – you were also smart enough to plan and have a GPS to help you find your way.  Your final destination has been input and the course plotted.

crazy intersectionWith proper preparation, your IT department  can be like the GPS in your car — planning the best route to your destination, avoiding slowdowns and getting you to the beach by lunch.  However, if IT doesn’t have all the information to plot your company’s course, or is not given the information in a timely manner,  you can end up bogged down in traffic or taking the scenic route instead of the interstate, ruining your trip with frustration and disappointment.

Carrier IT departments need to have a firm understanding of where the business wants to go so they can design their target architecture in order to plan the best route to get there.  As you know from adjusting your car navigation system, the best route to your destination isn’t always the most direct, or the fastest.  Traffic jams of requirements documentation, technology learning ‘S’ curves, and poorly timed stop lights can make the most direct routes take the longest.

Management should not decide to venture into a new line of business, issue a policy, and drop the policy off with IT to enter into a non-existent system.  The result can only be chaos in a poorly planned and hurried repository saturated with wasted money and time. Without proper notification and planning, a carrier’s IT department becomes reactive instead of proactive, definitely limiting their capability to support the business and help the organization grow.  This dramatically increases the difficulty to introduce new lines of business and does not  improve your company’s ease of doing business for your agents and customers, pushing them further away.  Even the most strategic, brilliant, masterful business plan fails if you don’t have the technical infrastructure to support it.

By keeping IT part of the business planning process, they can help plot the best course and work with you to build a platform for the future that can support your growing organization.

Microsoft recently purchased Rosetta Biosoftware from Merck & Co. for its Amalga Life Science platform; with this move, Microsoft is starting to differentiate itself from its competition by offering its integrated information solutions, which include HealthVault, Amalga UIS and Amalga Life Sciences, to both providers and producers. In its crosshairs are huge budgets available from Pharma for infrastructure solutions for drug R&D and clinical trials. Microsoft is posed to attract a whole new audience of customers from Pharma to integrated health systems that have their own research entities. If done correctly, Microsoft’s new strategy could become a model for improving the efficiency of clinical research, by drastically reducing the most costly resource needed for clinical trials, time.

The current Amalga UIS is fundamentally what I like to call a PDA (no not Public Display of Affection, rather a Patient Data Aggregator). There are three core components that include:

  1. Data Aggregation and Distribution Engine (DADE) – sits on top of healthcare provider sources and listens for HL7 messages; then puts them through transformation and parsing scripts in preparation to be stored in Amalga and sends them to a data store;
  2. Data Store – receives the messages from DADE; is a basic core storage engine and is a database with a set of tables specific to segments within the HL7 messages; and
  3. Front End – a web-based presentation layer that was originally designed for patient level data viewing and has plug in capability to provide more appropriate tools for analysis.

The current needs of data integration seem to be met by this solution, and the high degree of customization that can accommodate an implementation makes it even more attractive. Microsoft’s footprint in healthcare is getting bigger; they must understand, though, that this space has many stakeholders. While addressing all their needs is nearly impossible (just ask our hard working politicians’ trying to pass healthcare reform legislation), the last people they want to alienate are those they’ve already convinced that Amalga is the healthcare platform of the future, most notably some high profile integrated health systems across the country.

Integrated health systems (IHS) often provide a combination of services including care delivery, research, education, and even  their own health plan (think KP, John Hopkins, Geisinger, and Sentara). These entities have a unique opportunity to leverage the MS offerings by creating a continuous feedback loop of information from patient to provider to researcher that improves the quality and accuracy of the data throughout the process. Let’s start with the patient:

  • Patient information in HealthVault – As patient’s progress from being baby boomers (less tech-savvy) to Generation X & Yer’s (tech-hungry), clinical information will no longer be in the sole possession of the doctors. Rather, the demand will be for online, mobile, 24×7 access that is shared and can be updated real-time as health data is gathered by both patients and their doctors. Patients, thus, become a stand-alone data quality tool as they become more comfortable verifying, updating, and changing the information in their medical records.
  • Research information in Amalga Life Sciences – Researchers are all too familiar with the tedious, error-prone process of identifying patients with the correct diagnosis and conditions as candidates for clinical trials. As patients become more empowered with their medical records, they make the segmentation of populations a much simpler process.
  • Clinical information in Amalga UIS – Amalga UIS is a mechanism for driving continuous improvement in clinical care by integrating data across the enterprise. One way to improve care is by incorporating best practices identified through clinical research. The information learned from improved research methods are then implemented directly into the standard delivery of patient care offered by provider institutions.

Amalga feedback loop (2)

The Amalga UIS is currently operational in 12 domestic organizations. Because most of these clients are IHS’ and have research entities, they are in the best position to capitalize on the Amalga Life Sciences offering. These will also be the locations where the ROI MS is hoping will be formulated for less prestigious organizations to eventually imitate. It begs the following question, though, that some of the current customers will ask, “How can the existing components of Amalga Unified Intelligence System (UIS) be leveraged in this new offering to make it attractive to the widest audience possible and more importantly, be affordable?” Well, if you can articulate the argument above, and identify the huge benefits that can come from the Microsoft Feedback Loop, your argument might be easier to make than you think. And don’t forget, this feedback mechanism is built on the fundamental principle that all stakeholders must have the collective groups’ best interest in mind; so don’t forget to share what you find with your neighbor.

Why do I need to think about assessing the IT capabilities of an acquisition?

sherlockSo you just acquired a company as part of your growth, diversification, or some other strategy. The new company along with its LOB (line of business) expertise comes with an entire IT infrastructure that was thus far responsible for supporting the acquired company’s information needs only. While a great deal of due diligence goes into understanding the viability of the business and its value the same level of rigor is typically not applied to evaluating its IT infrastructure and support staff. In order for the two companies to work together well it is important to understand the capabilities of the two IT infrastructures and how to best integrate or not integrate them. If a detailed and careful plan is not put together to understand the capabilities and assets of the new acquisition you risk inheriting a vulnerability that can spread throughout the larger organization or risk stifling a capability that really should be promoted to the larger organization.

Why you need an independent perspective?

Sometimes companies use their own internal staff to assess the target or recent acquisition. The problem with this approach is that these assessments can be tainted by hidden agendas, lack of impartiality, and departmental politics. Entrenched interests can also slant information one way or the other as it passes up and down various departmental hierarchies.  I was part of a software company which wanted to acquire another software company with similar technology. Our own internal research and development department was tasked with the assessment of the company’s technology. Quite understandably the leaders in the R&D group thought it was inferior to what was developed in-house even though that was far from the reality. The key decision makers involved in the deal, including the CEO and the board of directors, were getting conflicting accounts of the reality and did not know whose version of truth to trust. This is where an independent perspective from external consultants can come in handy. They often face less resistance when digging around and are able to see beyond the personal bias and the “ugly baby” syndrome. A fresh perspective can also help see the forest from the trees which can sometimes be missed by the people who are working on the trees on daily basis. I came across another post acquisition assessment where the management was told that acquired company’s technology and custom developed software was topnotch. Upon further investigation we discovered that the most of the custom software was developed in a little known RAD development environment and less than a handful of people in the company knew how to maintain it. While this creates tremendous job security for some it creates a significant risk for the company. In another situation credit card numbers and all other consumer related information was stored in a database unencrypted!  Stories like these are all too common and point to the need for an independent perspective.

Is it too late to do an assessment after the deal has been signed?

During my days as a consultant I have primarily come across two types of assessments: pre-acquisition and post-acquisition. Pre-acquisition assessments are important where IT infrastructure is a primary part of the value of the business being acquired (software companies, online businesses, etc.). The focus of a pre-acquisition IT due diligence assessment is primarily on ensuring that the IT assets are as good as they have been portrayed,  that they are capable of supporting the business objectives associated with the acquisition, and that there are no hidden risks that will require significant expense to remedy after the buyer takes ownership. For example can a wildly successful but local online service be introduced in a new geographic region with a new language, currency, tax and privacy laws, etc? Post-acquisition assessments are important when the prime value of the acquisition is derived from the LOB (e.g. selling insurance policies, financial management, etc.). The focus of this type of assessment is typically ensuring that IT infrastructure is solid enough to continue to support the business; there are no vulnerabilities that can jeopardize the combined entity, finding areas of excellence to propagate, finding redundancies, and figuring out an integration plan. It is always good to get an outside assessment done before the deal is inked however, if that doesn’t happen it is still very important to at least get the post-acquisition assessment and planning done.

What kind of acquisitions can benefit from an assessment?

These days even small companies whose business does not directly intersect with information technology rely on some sort of back-office IT infrastructure to run their day to day operations. A back-office infrastructure may contain email servers, phone/fax servers, internet gateways, website servers, database servers, LOB applications, etc. A front-office infrastructure may contain client facing applications, online portals, CRM applications, LOB applications, etc. As the number of servers and employees grow the need for proper management and use of sound practices to manage them become more important. If access to IT infrastructure such as LOB applications, databases, email, website, etc. is essential to the daily operations of your business it is vital to ensure that proper assessment of the potential risks is done and the IT assets are managed properly.

What are some of the key aspects that should be examined during an assessment?

Start with creating an overall blueprint of the IT assets and how they interact with each. You would be surprised to learn how often such a fundamental document does not exist. Look at the hardware/software redundancy needs to provide the needed uptime to the business. Determine what disaster recovery plans exist, when they were last tested, and what kind of situations they can handle. Examine the security risks and ensure that the security practices match or exceed the required level of protection warrant by the business. Does the infrastructure have the capacity meet or exceed the demands placed by the peak loads and growth in the business? Examine the hosting environment for security, redundant power, redundant internet, redundant cooling, proper fire suppression, etc. Ensure that hardware and software assets are not so old that they are longer supported and can’t be upgraded. Is the technology stack compatible with the umbrella company’s technology stack? Are they any strange or esoteric practices or standards that could introduce risk? And never forget to identify practices, technology, and people (centers of excellence) that can benefit the entire organization and should be propagated to the entire company.

Reviewing security policies and procedures is another key aspect of the assessment. The risks associated with a weak security structure are obvious and too numerous to describe here. You need to not only think about electronic and online security (firewalls, virus and spam filters, internet intrusion attacks, etc.) but also about physical security. Most companies tend to neglect one or the other and sometimes both. In today’s environment the physical as well the data security should be considered a top priority for any IT assessment. The risks are high no matter what business it is, including legal consequences and public embarrassment.    At a fortune 500 company where I once had the privilege to work became a victim when half the office noticed that there computers were running slower than usual. Upon further examination it was discovered that each computer was missing half the memory chips that they had. Someone had simply walked in after hours before the lock-down, removed memory, and walked away. At another client site we discovered that they have neatly documented their security policies and key passwords but the passwords for all the accounts were exactly the same!

Depending on the industry you work in you may also have to worry about compliance and regulatory issues. For health care industry you have to worry about HIPAA compliance. All personal information and medical records have to be protected according to the guidelines of the HIPAA act. All publicly traded companies have to be in compliance with Sarbanes-Oxley act (SOX). Even though the SOX act never mentions the word software the audit trails and record keeping required by the act ensures sizeable investment in IT infrastructure and processes to manage it. There are various other acts and standards like the Patriot act, DOD 5015.2, SEC regulations, ISO standards (9000, 15489), etc. that may apply based on the industry and business practices. Sometimes the process may be even more confusing and harder when acquiring companies in different countries or different states where the local laws are not the same. All of this means that you must ensure that your new acquisition does not expose you to compliance issues that you didn’t have to worry about before.

How do we plan for the joint future?

Now that you have good handle on what you just acquired you need to plan how you are going to move forward. You need to think about cost saving opportunities by consolidating sites, hardware, and other resources. You need to think about standardization of software, hardware, and operational practices. You will have to decide how want to handle common branding and identification issues such as email domain names, website, central call-in numbers, etc. You will need to examine what support contracts and license agreements exist and how they need to be modified as part of the larger organization. The integration with the umbrella organization needs to phased in and timing needs to be planned carefully to minimize impact to the business. A combined successful and seamless existence doesn’t happen on its own it needs to be planned and carefully executed. If your company is planning to grow through acquisitions you may want to create a process for assessing and integrating new acquisitions based on your current experience.

If the business you are acquiring is being carved out of a larger parent company, you also need to plan for a migration plan off of the services that the parent company is offering during the transition period.  There are further complications if you intend for your new acquisition to be platform company to which you will add other newly-acquired companies over time.