Best Practice: Cloud Computing

Red sky at morning, sailor take warning.

Here’s a forecast: clouds are rolling in. Architecting for cloud computing will, very soon, become a conscious best practice.

There are lots of handy objections to Cloud Computing: Regulatory compliance, geographic containment requirements, taxes, liability, vendor lock-ins and lack of standards. Many are brushing off cloud technologies as a result, and maybe rightly so… for about another minute, anyway.

Last year, I was involved in a client’s effort to re-provision an application from an in-house infrastructure to a SaaS vendor. All told, the effort was risky and enormous. The administration of it took a year. It took a team of talented engineers from several different companies over six months to implement the transfer. When it was done, everyone breathed a sigh of relief.

The amazing part was that it wasn’t about changing applications. It was just changing who hosted the application. Simply put, no one had the fore-sight to architect for a transition of this nature, and so the ROI was heavily diluted.

Market fluctuations, re-focused specialization, business units changing hands, economic right-sizing, disaster recovery; there are many reasons agile infrastructures can be useful. Cloud computing technology is evolving quickly and has the very real potential to offer agility at a dramatically lower cost, if you’re prepared to leverage it. You don’t have to go in to the cloud to see what you might gain from it. The important part is preparing for it so you can use it when it makes sense for you. And, you could even go green at the same time.

I won’t try to predict what your organization has to gain by architecting around cloud technology. It’s more about what your organization is at risk of losing if you don’t.

Claims Outsourcing Strategy – Managing a Smooth and Seamless Transition

Part 1

The focus of this three part series is for the reader to gain insight into and knowledge about managing a smooth and seamless transition for outsourcing claims business processes.  Part 1 concentrates on the upfront gathering of current and future requirements, the Request For Information (“RFI”) and Request For Proposal (“RFP”) process, the selection of the “right” vendor, and a brief on contract negotiation.  Part two will focus on  the development, testing, and conversion that takes place between both organizations, and some of the pitfalls to avoid.  Part three will focus on maintaining the long term partnership relationship with your vendor. 

Outsourcing  for many Insurance and Financial Services organizations is viewed as a strategic tool for bringing about a more productive, cost effective, and profitable business.  The key benefit to outsourcing a segment of a business or an entire business unit is to enable the organization to focus on their core competencies and deploy resources with regard to these core competencies. 

When the strategic decision to outsource has been made, there are plans and best practices organizations must follow in order to guarantee a successful, smooth and seamless transition.  Foregoing any of these steps could lead to a potential disaster and often times a long, drawn out process. 

Detailed Business, Functional, and Technical Requirement

All too often I’ve seen organizations fail at one of the most important steps in the process, creating a complete set of claims business and functional requirements, documenting well defined workflows, and detailing technical and infrastructure reviews and requirements.  Organizations need to allocate the right amount of time and resources upfront to gather and document these requirements and workflows.  Unwilling to do so or short-changing the process will lead to a long and expensive outsourcing transition.

You maybe asking yourself, “Why is this step so important?”

The answer — the detailed documentation sets a strong foundation for all activities and processes that follow, both within your organization and eventually with the outsourcing organization you select.   The goal here is to achieve a clear, detailed, and descriptive understanding of your claims business.  As daunting as this may be the benefits of having your claims processes and workflows clearly defined outweighs the many pitfalls you will encounter should you not execute this step.

Selection of the Outsourcing Organization That Fits Your Needs

Finding the right organization to administer your claims business is critical to the success of your outsourcing strategy.  But how does one find which organization is the “RIGHT” fit for their business?  By creating a high level Request For Information (“RFI”) followed by a detailed Request For Proposal (“RFP”).

If your organization takes  the time upfront to detail the business, functional and technical requirements, then your RFI and RFP are nearly complete. Generating the RFI and RFP is a matter of taking the information documented and formatting it apprpriately.  The RFI is then used to narrow your search from a long list of possible outsourcing organizations to a handful of potentially qualified options.  Once you have narrowed your search, the RFP becomes your driver.  It helps to further narrow the selection process to 2 or 3 organizations. 

Figure 1 — RFI / RFP Process

Contract Negotiations

Once the outsourcing organization is selected the contract negotiations begin.  The outcome of this step is to finalize a contract that both organizations can agree to.  The focus here is to define who is responsible for what, and when.  Items that are imperative to the contract are:

• Service Level Agreements (“SLA”)
• Vendor modifications and who pays for them
• Escalation procedures for disputes and interpretation of the contract
• Cost basis per transaction

Contract negotiations are difficult and time consuming.  If done right this will set the stage for a successful transition of business and for a long term arrangement between your company and the organization you selected to handle your business.

 

Figure 2 – Phase 1 Tactical Roadmap

Can Insurance Help People Go Green?

About two months ago, Google released its latest mobile technological advancement – Latitude.  Now everyone with a mobile device (which is just about every living soul over the age of 14) can track, or be tracked, by their friends and family.  On the other hand, in a more malevolent approach, your boss can spy on you; or can you spy on your boss? 

Nevertheless, it is another method where “Big Brother” can keep tabs on where you go, how often you go there, and how long you spend there.  Parents can track their teenagers to make sure they’re in school, they went to the friend’s house they said they were going to, or if they’re at the lack watching the submarine races.  However, other than the boss and employee relationship, does this technology also apply to the business world, or to be more specific the insurance industry. 

Auto insurance carriers, including Progressive, are offering Pay As You Drive (PAYD) programs.  This means that instead of the typical rating methods of garaging and vehicle types, auto policies, both personal and commercial, could be rated based on where you drive, and how often you drive, making your insurance use based, rather than ownership based.  At least one company rates based on the miles you drive, but by inserting a GPS device into the vehicle, using existing technology such as GM’s On Star, or using your cell phone with Google’s Latitude, carriers can track your every trip.  This could potentially be expanded to use based paying in other vehicle industries like car rentals.

Under the typical ownership based rating, insureds pay the same premium whether they drive 5,000 or 50,000 miles per year.  A 2008 Brookings Institution study revealed that if premiums were based on use, driving would decline by 8% nationwide, saving $50 billion to $60 billion each year.  Reduced carbon dioxide emissions would also result.  Everyone wants to offset his or her carbon footprint.  Each time I fly in and out of Cleveland, Continental offers me the option to pay a few dollars more to offset the carbon emissions for the flight.  Most companies are now telling everyone how their packaging is made from recycled materials and how they help the environment.  Like most people, I recycle, and I try to drive less, but that’s more because I’m too cheap to pay for the gas.  Going green is mainly something that people try to do on their own.  However, the Insurance industry is moving toward a new concept that could help push people in that direction.

Cloud Computing Trends: Thinking Ahead (Part 2)

In the first part of this series we discussed the definition of cloud computing and its various flavors. The second part of the three part series focuses on the offerings from three major players: Microsoft, Amazon, and Google.

Amazon (AWS)

AWS is a collection of services offered by Amazon to implement Amazon’s vision of IaaS and to some extent PaaS. Some of the main services of AWS include: EC2 (Elastic Compute Cloud), S3 (Simple Storage Service), & SQS (Simple Queue Service). Amazon differentiates itself from the other two players by providing PaaS and IaaS in an integrated package. You can simply start an instance of a Windows machine or a Linux machine and select either a big machine with lots of memory and CPU or a small one.

Once you have an instance you can interact with it via remote services and install any software you want and configure it. If you had a Java application that used Tomcat and MySQL running on an old server under someone’s desk, you could simply start a desired size machine instance, install Tomcat/MySQL, and start running your application from EC2 without changing any code. However, this flexibility comes at a price. If the needs of your application went past the single largest instance EC2 can provide then you would need to re-architect your application to distribute processing across multiple large instances.

Of course the benefit of this approach is that it allows you to move your application into the cloud without rewriting code as long as your needs don’t outstrip a single instance. There are also no limitations in terms of programming language or software that you use. Your application can be based on J2EE, .Net, Python, Ruby, or anything else that runs on Windows or Linux OS.

Microsoft (Azure)

Microsoft calls Azure  a cloud operating system (PaaS) and as such it abstracts away the regular OS that we are familiar with. You write your application to specifically work with Azure using its storage, queuing, and other services and then simply publish it to run on the Azure’s compute fabric. The good thing is that you use all the tools that you are already familiar with to write an application (e.g. Visual Studio 2008).

After the application is written it can be tested locally and only published to the Azure cloud when satisfied. Once the application is running in Azure you cannot attach a debugger to it and must rely on good old log messages for debugging and gathering state information. Azure supports .Net as the de facto framework and supports assemblies compiled from any CLR-compliant language as long as they comply with Azure’s framework. The obvious drawback of this approach is that an existing application cannot be simply moved to cloud without rewriting its key components and perhaps without a complete redesign. However, the advantages are also obvious and significant; once you have written your application to run on Azure it gives you instant ability to scale by simply reconfiguring the number of instances your application runs on. This can be very powerful if your application’s usage is unpredictable or has a seasonal variation. Another issue with this approach is that it ties your application to the platform and you cannot simply take your application and run it in another cloud.

Google (App Engine)

Google App Engine is a PaaS platform and is a combination of an instance service, a data service, and a queue service. It also hides the OS and hardware from the user/application like Azure. But it limits the application to be written in Python in order to be hosted on Google’s cloud. You have to write the application using the SDK provided by Google and once again you can configure it to run multiple instances and automatically benefit from seamless scalability and redundancy. However, you not only have to rewrite your existing applications you also have to commit to a specific language and platform which may not match the requirements or the skill set of your organization.

Feel Like Your Pants Are Down – Check Your Data

Few things are as embarassing (cool double entendre) as having your pants pulled down in public.  While it is great fun to see it done figuratively to someone else (real world on the grade school playground), it can really cramp both careers and management practice in the corporate world.

Just when you have the fought for budget money to put into some cool analytics or reporting…the project is up and running, you’re day dreaming about keeping your job (maybe a raise!). Then, the project status rolls across your desk: bad data, instant project over-run.  The problem is worst-case scenario; bad data tends to be discovered just as the project goes live with no quiet opportunity to fix it.  The money is gone and everybody is looking (yep, just like second grade, lunch money is gone and…).

Don’t you just love going back to the C-Suite for more  project budget (feel like you’ve just been pantsed?)  Ouch!  This one needs to be avoided at all costs.  How to do it is the tough part.  Does anybody really want to go into the C-Suite and say, “Our corporate data may not be, uh, kosher?”  There is a real career enhancer for any CIO.  So you need to do what any red-blooded CIO would do, bury the cost in another part of the project.  No one wants to champion a project entitled “Fixing Corporate Data Assets”.  How did they get messed-up in the first place?  Guess who gets blamed?

No one wants to hear about legacy code and budget reductions.  There is no wide-eyed fascination regarding aging databases suffering from too many corporate mergers and grafted on must-have emergency applications.  Well, if they don’t want to hear about that, why go through it.  Don’t tell me problems, get me solutions!  Well, here you go, as requested.

Instead, early in an analytics or reporting initative, put in a sub-task to test existing data for proper compliance to the stated information delivery  goals (see that doesn’t feel scary, just numbing).  Overall match to corporate data governance and meta data management standards can be tested at the same time, who could argue with that?  Just a little bit of testing, call it project (career)  insurance.

The next step should be obvious, even to a CIO.  Slide one of these sub-tasks in each project initative (they go togther like “sliders, beer, and baseball”!).  Before you know it the Corporate Data Assets are in tip top shape, without the nasty embarassment of a major budget line item.

Does your Order-to-Cash Process Need a Check-up?

The order-to-cash process is the circulatory system of every business. As with the human circulatory system, there are many ways this process can break down, and seriously erode the overall health of the business.

Diagnosing and fixing order-to-cash symptoms is not easy, because the order-to-cash process is complex from many perspectives. It involves:

• Multiple technology systems or application modules
• Multiple locations
• Multiple departments and job roles
• Multiple stakeholders

Much of the inefficiency we see in this core business process arises from an inappropriate approach to making decisions and changes concerning any of the technology or business processes involved in order-to-cash.

Without strict change control over the processes and technology, some companies are allowing decisions to be made on the fly, resulting in in an order-to-cash process that yields significantly less cash than it should!  Some real world examples from our project teams include:

Symptom: A CPG company that required a return merchandise authorization (RMA)  to match the quantities on a purchase order (PO).  Some of their customers returned products across multiple POs.When a customer service rep could not find these POs, they created a new PO just to process the return against. This workaround skews information inappropriately in any number of reports.

• Diagnosis: It’s not just this process that’s broken. The company needs to devote more effort to process definition, with review of exception handling by all impacted stakeholders.

Symptom: High volume of billing errors, requiring significant effort in reviewing/correcting invoices and handling customer inquiries. Your staff might also be trying to review every order and every invoice because of the historically high rates of errors. You’ll start to see a drag on your Days Sales Outstanding (DSO) metric as well.

• Diagnosis: There are many possible causes here: price lists and promotions being maintained offline, manual re-entry of orders from handwritten order forms, lack of automation in the order approval workflow, undue delays in entering orders, manual handoffs to fulfillment team, to name a few. While there are many causes,it’s easy to see that investments in automation here can have a significant effect on cash flow (especially important in the current economy), because even a small reduction in DSO can have huge returns.

Symptom: High volume of customer inquiries and high volume of customer complaints, coupled with long average call times, as well as repeated or escalated calls to follow up on the same issue.

• Diagnosis: The CSRs may not have real-time access to the right information to address customer inquiries (order status, credit hold status, account balances). Tighter integration and better training can often address this.

Other organizations realize that an ounce of prevention is worth a pound of cure, and proactively monitor key performance indicators (KPIs) across the order-to-cash process. These include:

Contact to sales order: leads (number and cost), qualification (lead conversion ratio), quote (gross margin and average discount) and closing (win/loss ratio and time to close/sales cycle).

Order fulfillment: Order-to-delivery performance data includes metrics related to customer orders (number of new or open orders and number of orders with errors, number of orders delivered on the date promised to the customer

 Invoice to cash: Metrics include number and value of invoices created, sent and disputed as well as cash received or accounts receivable days outstanding.

In summary, to make sure your order-to-cash process is not leaking cash, adopt the following measures:

1. Strict change control over all the processes and technology.
2. Adopt and track key metrics to help you find and address inefficiencies.
3. Take a look at the integrated operating platform between your customer relationship management (CRM), Order Entry, Finance and Supply Chain Management systems.  Too many manual interventions across the lifecycle of an order leave the doors wide open for errors on orders and invoices that could significantly impact your bottom line.

Maximizing BPM Benefit

When faced with the elusive question, “How do I maximize my long-term benefit?”, remember these two key principles:

• BPM should be a continuous learning cycle.
• New process improvement ideas can come from unexpected places.

As part of our recent research study on organizations across a dozen industries who have implemented a BPM solution in the past 3-5 years, the following quote from a Financial Services company representative highlights this point:

“You must know what BPM tools do best. Once you’ve catered your initial processes based on this core functionality, it is essential to then learn what else the tool can do for you. You must constantly be in a learning mode.”

With a BPM suite, by increasing its use, you increase its value. As users become more fluent in the concept of process management and broaden their understanding of the functionality and capabilities of the tool, they uncover more and more opportunities to increase productivity and quality in their daily activities.

Today’s BPM suites have so much functionality that you can actually create unnecessary risk if you try to do too much in the first few processes.  Let the concepts sink in, let the team get used to it. Before you know it, they will be bringing new suggestions on what else to improve/tweak/change.  Consider incentivizing the staff to generate new ideas.

Organizations that use their BPM for one or two processes can realize significant benefits and cost savings.  But the organizations who have realized the most benefit from their BPM implementation have truly embraced the concept of continuous improvement using BPM to improve traceability, visibility, accuracy and speed of their processes.

These days, saving money and improving processes is everyone’s responsibility. Gone are the days of “I-just-work-here”.  Everyone up and down the process chain will play a part in maximizing your organization’s benefit from BPM.  Keep the communication feedback channels (and your ears) open…