JT Pedersen » BPO

Don’t Forget the USERS!

JT — Thu, 09 Sep 2010 20:11:31 +0000

The other day I happened across a discussion asking the question: “What are the most important things to consider before moving…to a cloud-based solution?”

Darned good question. The opening—very valid—questions included things like:

TCO (total cost of ownership);
Data security;
SLA (service level agreements);
ROI (Return on Investment);
Data backups, Disaster Recovery, & Business Continuity Planning (BCP)

These are very typical things to find in Requests For Information (RFI), Request for Proposal (RFP). They are very representative of what (CxO) executive management will want to know—particularly before signing off on expensive, far-reaching, solutions.

But! Do not forget the Users!

Put yourself in their shoes, or better yet, get users’ input directly. Perhaps the #1 question is, "Will they use it?"

I have seen more than one solution deployment fail and turn into a huge waste of capital, simply because no one would use it! Sometimes its as simple as the user interface is appalling. More often, it is because the new solution does not map well against their day-to-day processes.

Another component to consider is, "Who will own it?" Restated, Who will own the relationship with the vendor? Who will bear day-to-day responsibility for execution? Will these lay with ‘someone in IT’, with the CIO or another exec, or…? All too often an exec or other manager has a great idea and makes an assumption that ‘IT’ will take care of it. Quite often, that’s a poor assumption that leads to additional heartache downstream.

So, perhaps 6. should be, Have all the stakeholders been identified and provided(ing) input?

What other key items have you seen neglected in the race to adopt something new?

(photo credit: Sigurd Decroos)

Possibly Related

SaaS Cost & Pricing for Existing Businesses

JT — Thu, 31 Dec 2009 20:33:14 +0000

Back in the late 90s, as we were enjoying the glow of the dot.com boom, Andy Grove, CEO of Intel, predicted, “…all businesses will be internet businesses, or they won’t survive.” Instead, companies adapted to having an internet component to their business.

Now, in the late 00’s and heading into the ‘10s, Software as a Service (SaaS) has become credible, taking its rightful place as a mature business concern. Increasingly, traditional software vendors (and others) are realizing their product offerings can continue in conventional form (here’s CD/DVD, you install, and maintain) or as a service completely delivered via the web (SaaS).

I think the path of SaaS will be parallel to what we found after Andy Grove made his original prediction for the internet. I do not feel, ‘all software companies will be SaaS companies, or they won’t survive.’ Instead, many will develop a SaaS component of their business.

Business Process Outsource (BPO) providers are ‘non-software’ example. Consider a company that outsources it’s Accounts Payable function to a BPO. The BPO provider will go ahead and print and mail checks, invoices, and other documentation as usual. In the past, digital copies of all the documents printed might be burned to a CD (either as TIFF or PDF) and returned to the customer for their records.

Now, consider the option SaaS offers that BPO. Instead of burning the content to DVD, likely never seeing light of day again, why not host it on a server and provide a web interface for the documents? All of a sudden, you now have created a new service (SaaS) enabling help desk look-up services via a browser. Or, your customers can log in to verify that, Yes, a check has already been mailed out, and, there’s an image of the check for them to look at.

Yes, this is just a simple example of what SaaS/BPO providers are already doing. My focus is more for those considering adding a new or additional SaaS service to their existing business.

Depending on what your SaaS service may be, determining costs and, by extension, pricing can be a challenge.

While this is an issue of past experience, today’s post was triggered today after reading Andy Mulholland’s CTO Blog. Capgemini recently conducted a survey of CIOs and how they view the role of IT in their company:

Three common profiles of the CIOs surveyed:
Technology Utility (24%)
- IT is managed as a pure utility
Service Centre (39%)
- IT assets are packaged to provide specific services
Business Technology (37%)
- IT is a key asset in the leadership of the business

In every company today, there is an IT layer required simply to keep the business in operation. This layer can consist of your PCs, servers, network, telecom, ERP systems, software, and so on. There are various ways of doing the accounting, charging-backs to different business units, and the like. In the end, the expense almost invariably boils down to being overhead absorbed by the organization.

The challenge with in introducing a new SaaS offering, is that there is an ‘aspect’ of IT involved.

The parent organization may view the SaaS offering as a loss-leader, a give-away, or simply as a component of a more strategic offering. Think: tire iron and your car. All this is quite simple if your SaaS offering is simply a fully burdened expense that never shows up on a customer invoice.

However, if your offering is a direct-to-customer offering, you need to have a very clear understanding of where the line in the sand is drawn, between your share of corporate’s shared IT resources, and your own.

For instance, more servers, more staff with laptops, development software, and so on. Many of these expenses can be directly attributed, and costed to, the specific business unit.

At the same time, your SaaS offering almost certainly will need to make use of shared corporate resources, like firewalls, network security staff attention, telecom/bandwidth, and storage space.

So, how do you price your offering? How do you determine your true costs?

Identifying the true cost of operation for your SaaS offering may be a major challenge, pragmatically and politically. The direct costs of your staff and their dedicated equipment is straight-forward. However determining shared costs may not be easily done.

One very real cause is how the accounting in an organization is done…accounting systems simply may not be able to give you the level of granularity required. A second cause, also very real, is politics. Other managers may be unwilling to share their cost models with you. You may also simply find that senior management has arbitrarily dictated business unit charge-backs.

However you do it, understanding true cost of your business is critical. To do so you need a complete understanding of all the functional (cost) components of your business along with practical arguments justifying how shared IT costs should be accounted for. In doing so, you will need to shape your justifications so they take into account how your senior-most IT managers (i.e. CFO and CIO) view IT. Does SaaS = IT = SaaS, or no?

(photo credit: Donald Cook)

Possibly Related

You’re SaaS Dependent and the Internet Goes Down

JT — Thu, 08 Oct 2009 19:40:15 +0000

A common starting point

The internet’s ubiquitous nature has made possible so much. If it were not for the internet (like the utilitarian ‘phone,’ it’s time to stop capitalizing ‘internet’) the notion of Software as a Service (SaaS) wouldn’t even exist. Yet while incredibly empowering, the internet can be incredibly devastating when it fails.

Saying, ‘…the internet is down…’ is often akin to using the ever popular, ‘they.’ From a user perspective, the internet being down often simply means a transaction between Point A and Point B is failing. It does little to identify whether the failure is at A or B, or somewhere in-between.

As the consumer of SaaS, you need to consciously plan for service disruptions. Can you protect yourself if the failure occurs locally, or at the service provider’s end? What about outages of various durations?

Wikipedia and other sources will describe SaaS as effectively being ‘rented software,’ either thick or thin client (e.g. web-based or locally installed). Others, such as The Connect Web’s Phil Wainewright more correctly (in my experience) view SaaS as primarily web-hosted, commenting, “SaaS vendors, of course, spare their customers the burden of installing the software at all…” In its most popular delivery model, Software as a Service assumes a near-zero size client-side foot print relying on nothing more than a web browser for access to the service.

The preceding comment is important. In my experience, most SaaS consumers are using browser-based client access to their service. This means there’s also a near-zero ability to work in an ‘off line’ mode should connectivity to the SaaS provider be lost. The options are often pretty simple: Sit on your hands and wait, or, send staff home for the day. In most cases the latter extreme is very rare, but it does happen.

Protecting yourself

How you protect yourself against SaaS service disruption largely depends on two things: your operating budget, and, service provider selection. Your budget not only dictates how you design your environment, but also nature of the Service Level Agreement (SLA) agreed to by your service provider (see my article on choosing a vendor).

The SLA can describe everything from penalties due to service failures they are responsible for. It can also specifically identify the level/type of redundancy they have, how often backups are done, and responses to catastrophic failures.

An example may include requiring the vendor to: at all times maintain 2 internet connections, neither exceeding 50% capacity; maintain a remote data center they will seamlessly switch over to in the event of a failure, switching over after ‘X’ period of time; and minor details like average browser page render times (e.g. 1-10 seconds). The more you demand, the higher the cost, hence the tie to your budget.

Focusing on your end

Successful SaaS delivery is subject to the notion of the weakest link. Your service provider may have excellent redundancies but if your sole link is a dial-up connection (yep, even these days), you have a good idea where the weakest link may lie.

The level of sophistication you employ is going to be budget and priority driven. If the service is non-core and delays can be tolerated, little or no redundancy might be necessary. Odds are, you’re relying on the service you’re paying for, so, here are some details worth considering:

Multiple internet connections
Have alternate connections through different providers (e.g. AT&T/Sprint/Comcast/etc). Helpful if a major national backbone goes down. Helpful too in event of billing snafus and one wants to (sometimes mistakenly) shut you off.
Multiple points of entry to your building(s)
Have one connection enter the back of your building(s), another from the front. Even the Fortune 100 forget this occasionally and have entire facilities shutdown because of ‘Bob, and his backhoe,’ or the tractor-trailer that was higher than the cable across the parking lot.
Manage network bandwidth
Never let your available bandwidth become saturated. Buy more bandwidth if you start to exceed “pick your %” utilization. Check your actual consumption regularly (hint: annually, at contract renewal, isn’t sufficient).
Negotiate with your carriers to accommodate bandwidth spikes, peak hour surges, and similar
Create contingencies
- What will you do if your connection(s) fail?
  When does it become an issue? In certain high-demand applications a 2 minute disruption can be killer at the right time (e.g. end of month/quarter reporting for 20,000 dealers).
- What happens if there’s a failure for 2 hours, 2 weeks, 2 months (think truck hitting telephone pole; mudslides; regional power outages; Katrina).
- When is it time to send staff home for that shift, for that day?
Practice the Five Whys. Though you might substitute ‘what’ for ‘why’ in this case. For instance, start with why might my SaaS service fail? Why would my internet connection fail? What are my options? What don’t I have answers for? What keeps me (IT/Ops Mgr) awake at night?

You can have tremendous luck making use of SaaS offerings. But how well your luck holds depends on the ground work you’ve already done.

Possibly Related

Is Your SaaS Provider’s Focus Skewed?

JT — Thu, 02 Jul 2009 18:54:09 +0000

Generally considered Universally True: It costs more to get a new customer than to keep an old one. Whether we’re specifically talking about SaaS providers, or not, this seems to be lost on so many businesses. How much more profitable might a wireless carrier be, for instance, if they focused on keeping existing customers, rather than incessantly focusing on new?

Listening to the likes of quarterly reports from Verizon, T-Mobile, AT&T, for instance show companies focused on gaining more new customers than the number of old ones they lose. How much more profitable might they be if they simply changed their focus?

Depending on the provider, my experience is the longer the implementation takes, the more likely the provider is to lose interest and want to ‘just get it into production.’ Once the (closed last quarter) customer is up and running, it’s off to the races to find the next new customer (to close next quarter).

In a prior role, my team tried to get the CxO’s approval (with Sales’ backing) for specific features aimed at keeping an existing customer. As contract renewal time approached, paraphrasing, the customer said, ‘…the new kids on the block have all this new whiz-bang stuff. You haven’t done anything significantly new for us in [years].’ The CxO’s perspective, I kid you not, ‘…hey, they’re paying us, I’m not spending another dollar on them…’

It always amazes me how hard it is for some people to put themselves in the mindset of the customer, consumer, or client. After all, we ‘all’ play that role ourselves, daily. We tend to stay with a provider (e.g. your car repair shop) until they’ve made too many mistakes, or let us feel neglected or 2nd class, that our tolerance is consumed. Often all it takes is a ‘little’ attentiveness. Simply accepting responsibility for a recent problem, saying, “I’m sorry,” can get you a year’s forgiveness. When was the last time, in a B2B context, someone told you they were ‘sorry?’

There is another side to this as well. And I wrote about it not too long ago. As a consumer of SaaS services you are also responsible for following through on ensuring you’re getting what you’ve paid for. If you neglect quarterly measurables, skip annual inspections you fought to get into the SLA, you’re allowing the SaaS provider relationship to atrophy. You–let–them neglect you. Yes, SaaS providers need to pay attention to you, but you also need to remind them of your importance.

Possibly Related

Selecting a Vendor – Things to Consider

JT — Wed, 10 Jun 2009 22:44:11 +0000

Along the path I have followed, there are a few things I’ve discovered when selecting a vendor (or business partner). A few of the ‘popular’ ones I’ve discussed below. To help lend credence to my comments, you may appreciate my roles have included being a P&L head, product manager for a SaaS/BPO unit, global technical account manager, and doing joint-venture assessments involving some multi-$B concerns.

References
Requests for references create love/hate feelings, depending on whether you’re the one receiving the request. If you are making a major decision, such as outsourcing a key business process, you will be keenly interested in talking to others about their experiences with the given vendor. Any experienced vendor

with an established service will almost certainly be able to provide you with 2 or 3 contacts you can talk to.

Not everyone ‘can’ give you the references you ask for. Many customers (particularly the very large) view their choice of vendor (or even the fact they outsource at all) as a strategic/competitive issue. In other situations, particularly with an oligopoly, the customer may not allow employees to serve as points of reference. They may fear unanticipated impacts on their reputation by acknowledging their relationships. And, in some industries (e.g. automotive), to endorse a particular vendor may be seen as an unintended mandate that their supply chains adopt that supplier’s tools as well.

In most cases though, references should be available within a day or two. They either have them, or they don’t. If references are not forthcoming you need to ask yourself (and the vendor) why. Is it a new service (e.g. < 1 year old) where references might not be realistically expected? Or, are you considering an established vendor/solution where a lack of referenceable customers is a legitimate concern?

Financial Strength
Do not be afraid, perhaps feeling you’re being ‘indelicate’, to ask your vendor (particularly a BPO provider) for a set of financial statements describing their financial health. While a very small number of customers might actually make such a request, for a vendor that may process hundreds of RFPs in a year, it is not an uncommon request regardless of what you may be told. If you are going to outsource a chunk of your business to another entity, you must be reasonably certain they can do two basic things: (1) Have the wherewithal to build, implement, and maintain the services you’ve contracted for; and, (2) the legs, the longevity, to be there for you as long as you plan to need them.

Training & Materials
This is right up there with the request for references. You need to decide what your training requirements will be. Do you want the vendor to train your key people, so they can conduct internal training? Or, do you want the vendor to do it all? What do their training materials look like? Is training part of the service or an extra cost (and specified in your MSA)? Do they do it by webinar, in-person, or a mix, and who covers expenses? Can they provide materials for you to review? Their answers should give you a warm, fuzzy feeling inside. If not, you need to ask why. You certainly do not wish to roll out a new solution for 5, 50., or 500 users to use on Monday, and end up requiring heroic efforts in order to survive the day.

Make Sure the SLA Is COMPLETED
No kidding. Sounds like common sense, you negotiate a Master Services Agreement (MSA), then (or in parallel) you work out a Service Level Agreement (SLA) both organizations will abide by. In simplest terms: We deliver ‘X’ to you by 7a, daily. You will do ‘Y’ & ‘Z’ same day. And, by the way, if either of us fails to do so, here are the allowances we agree to as a result…

But you would be amazed how often a simple little thing like actually ‘finalizing’ the SLA can be—everyone wants to rush off to get started, without knowing the end game. Do yourself a favor, do the work to know what is important to you; make sure it is included in the SLA; and, the parties on both sides sign on the line. Having ‘Draft 6′ of a document, with annotations turned on, in a file somewhere is not going to help you when debating why services aren’t being delivered as expected.

No one can do it all anymore. To be successful personally, as a business, or as a community, we have to rely on others to help us along the way. Outsourcing, purchasing products and services, and the like will increasingly be the norm. Don’t fight it, prepare for it, be smart about it, and enjoy the benefits.

A couple parting thoughts:

If the references are not provided in a day or two, or you have to chase the vendor, it’s a clear sign they don’t have any in hand to give you.
No one wants to explain to the CEO why their business is about to fail—because the vendor your selected failed. It happens—even if their marketing collateral looks all nice and shiny.
Training is often given even less priority than a company’s Support organization. Quality and completeness of training materials can be a very good indicator of your overall experience with the vendor.
The SLA, in relationship to your MSA, is like your homeowner’s policy in relation to your home and the mortgage. You’re far more likely to need to look at your insurance policy from time-to-time than you ever will your mortgage or title documents.

Possibly Related

So, You’re Considering a Move to Cloud Computing

JT — Fri, 05 Jun 2009 20:41:15 +0000

Who Goes First?

A lot has been said already regarding BPO (Business Process Outsourcing), SaaS (Software as a Service), and ‘Cloud’ computing. The ‘cloud‘ remains somewhat dubious for folks because it is a term whose definition continues to evolve. Most of what is written seems to talk to those ‘in the know’ or from a perspective of ‘everyone’ already doing it. But what about those of you who have yet to take the plunge? Who have yet to outsource their first application and/or business process?

The odds are, if your business has been around a while and reached a certain size (ambiguous definition, case dependent) you are ready to at least consider the value of outsourcing some of your processes. Outsourcing has a almost nefarious meaning at times, full of a lot of charged baggage. Stripping the baggage away, all you’re looking to do is find a way to do something less expensively that you are now, with the same or better quality of service. If that means paying someone outside your organization to do it, then so be it.

So, where do you start? Some of the best candidates are those supporting your standard business processes. These are the well-defined highly repeatable parts of your business. For instance, in a prior life, I was the SaaS product manager for a BPO (business process outsource) provider. We provided a web-based repository as well as business process workflow systems.

The web-based repository housed billions of documents. Stored content came from various sources, such as organizations wanting to get rid of paper documents (condense warehouses of paper down to a few GBs of data), and/or, wanting multi-site access to common data (engineering, product support, health, HR records, etc). A large scale, ‘cloud’, provider can often provide such services at price points you cannot touch yourself. Plus, provide remote backup data centers, higher levels of security (physical and logical), and similar.

Workflow systems are the automated processes used to do something. For instance, most companies have a defined process for getting purchase orders created, approved, and executed; same thing with expense reports. With workflow systems, we could either provide only the software component (we hosted it for you) or, we could do it all: including staffing, for things like Accounts Payable, Receivable, and so on.

A classic reason to look at using a SaaS provider for your business process workflow is very similar to why organizations use salesforce.com instead of implementing ‘yet another expensive self-hosted CRM solution.’ Someone else maintains it, upgrades it, and pays for the infrastructure capitalization.

As you begin evaluating which, if any solutions to move to the cloud, you’ll want to consider (not all inclusive):

a) Costs

a. Maintenance

b. Operate

c. Upgrade

b) Equate to a cost/transaction, cost/KB, cost/Mbit

a. Evaluate SaaS/BPO costs (most should be able to help you with ballpark type discussions)

b. Volume of transactions

c) Reporting, Security, Compliance concerns

d) Enterprise systems interoperability

a. Do target processes require access to lookup dbases in other systems?
-something that can be readily dealt with, not likely what you want for your ‘first’ move though.

b. Volume of content to store, duration

e) Budget

a. Can you continue carrying what you have, including planned growth

b. Budget will drive ability, internally or external, to store content, up-scale transaction (or whatever your equivalent activity is) capacity, and the like.

For some additional thoughts on BPOs and SLAs, you can read a prior post, “Getting the Services You Paid For?”

Possibly Related

Appending to:Learnings from Lee Coulter

JT — Sun, 17 May 2009 15:30:17 +0000

Phil Fersht, a recognized BPO analyst, shares with us a discussion with Lee Coulter. Coulter, SVP of Kraft Foods Global Shared Services Group, highlighted some high-level thoughts on BPO, where it’s successful, where it has yet to perform. There are two areas I want to append to the discussion:

1) Behavior is a key player behind success. Lee is right, behavior of both client and provider are the more likely determiners of long-term success. The MSA (master service agreement) is something often toiled over for months, sometimes it’s never even truly completed. Eventually it gets stuck on a shelf and simply gathers dust. Once the process has matured (e.g. after 90 days), it’s typically looked at very infrequently.

As a result, ‘behavior’ of the two parties is precisely the governing factor. The client neglects their responsibility in many cases to execute review processes stipulated in the MSA. At the same time, the provider’s initial sharp focus on that client’s service dulls. The drive to get new clients and their projects into production are always front-of-mind; steady-state projects get sidelined; and, management focuses more on getting the ‘next’ client than on improving the ones they already have invested heavily in. In the end it comes down to: do we like each other, and, are we both happy about the value underlying our relationship? If yes, renew contract. If no, see below.

2) 2nd Generation
Another key issue not discussed very often, is the ’2nd generation’ engagement. This is a customer who has previously outsourced services, such as AP, and is changing providers. This obviously results from a change in the relationship, and perceived value.

The problem with second generation BPO, is that the client will have outsourced the business process for so long (3-5 years or more), they no longer possess the knowledge to execute, themselves. And, of course, the outgoing provider’s highly motivated to share with you what you need to know;). The result here is that getting to execution with the new provider will demand greater attention to detail, take longer, and likely be more fraught with frustration as a result of knowledge gaps.