“The Trouble with the Future…

fortune_teller…Is that it arrives before we are ready for it.”  A bit of plainspoken wisdom from American humorist Arnold H. Glasow. Thanks to the miracle of google, it becomes our intro quote for today’s topic of acquisition integration readiness.

In an earlier post, we talked about data integration readiness, but that’s only one task on a list of things you should be doing now if you plan to acquire a company in 09. Readiness is the word of the day, and the best way to sum it up is you have to have a documented platform to integrate with across the board, or you will lose time during your integration period. Lost time means revenue drag–you won’t hit your projections.

So, let’s make a list.

1. Data integration readiness, already covered in detail here.

2. Process readiness – are your procedures for key business areas up to date? You will need to walk through them with business team leads on the acquisition side to rapidly understand the gaps between the way they do business and the way you do business. Can you rapidly train the influx of people you will be onboarding with the acquisition? An effective training plan is a solid way to minimize post-close chaos.

3. Collaboration readiness – don’t underestimate the amount of time those new employees will take up with endless “How do I?” questions. Hopefully, you have a corporate knowledge portal in place already and you can give them access and a navigation walkthrough on Day 1. Make sure it includes discussion groups, so that the answers to their common questions can be searchable and institutionalized. There was a great post on this recently describing how IBM is using collaboration tools to help with acquisitions, and Edgewater’s Ori Fishler and Peter Mularien have posted extensively on Web 2.0 tools for corporate collaboration.

While we are on the subject of collaboration tools, let me tip you off to an important secondary benefit. The people that use them and participate actively in discussions are your change agents, the people that can help lead the rest of the acquired workforce through the integration. The people that don’t participate, well, they are your change resistors. They need to be watched, because they may have emotionally detached from this whole acquisition thing. If they are key employees, you want to make sure they don’t have one foot out the door.

4. System integration readiness – It’s oh-so-much-more-challenging (meaning time consuming and costly) to integrate into an undocumented or underdocumented architecture. Get your data flow diagrams and infrastructure diagrams, as well as your hardware and software inventories up to date before you close.

That first quarter after you close will still be a wild ride, but you can be sure you’ve cut the stress level down significantly if you make these readiness tasks a priority before closing day.

E-Billing Expose – Part One

Designed correctly, E-Bills are a great use for the web, allowing insurance companies to communicate critical financial and census data to their customers in a controlled fashion while increasing efficiency and accuracy for the customer and themselves.

Unfortunately, it has been my experience that there’s a lot of misleading information about E-Billing “products” and “systems” on the Internet. In my upcoming posts, I’m going to wade through this morass of information and detail the approach that works – both from the company and customer standpoint.

The bill I’m speaking of is for group insurance. In the paper world, it’s that complicated, multi-page, already incorrect when it’s mailed, document that details what the insurance company believes the customer owes them. In the group insurance world (especially worksite marketing), where products may be voluntary and usually involve payroll deductions, I contend the bill is always wrong when received by customer due to the nature of the beast. By the time the bill arrives, the customer has employees who have joined the company, left the company, added dependents, etc. The poor customer then moves to try to reconcile said manual bill at a “point in time” that has nothing to do with the insurance company’s computer system used to generate the bill. The customer remits the reconciled (from their standpoint) bill, and it starts all over at the company end. There, it’s a reverse reconciliation as the company tries to figure out the entries the customer made on their end. It’s not unusual to see bills arrive at an insurance company with lines marked out, additions written in the margins, incorrect calculations, etc. How can it be right? The customer doesn’t know the insurance company’s business rules.

A statement about E-Billing products – based on the complexity of insurance billing systems (especially legacy systems), the inherent dynamic nature of the customer’s census and the integration needed to design posting for a true E-Billing System (Presentment, Reconciliation and Payment) back to the billing system after a bill is finalized, products haven’t met the mark.  I have yet to see a product that meets the needs of an insurance company requiring true branding, specific process flow, true self-service automation, and SOA compliant integration.

Contributing to this state of confusion, I’ve seen three completely different levels of E-Billing as requested by clients. All are referred to as E-Billing and in many cases, in previous engagements, the client visualized more and received a lot less.

Stay tuned for a discussion of (1) E-Bill Presentment, (2) E-Bill Presentment and Payment and (3) E-Bill Presentment, Reconciliation and Payment (true E-Billing).

Image appears courtesy of graphicalwonder.com