SaaS versus BPO: is this where tech-geeks finally interact with services-nerds?

SaaS-BPO So there was a bit of Phil-bashing going on this week – from SaaS lovers – after my post that discussed some of the potential issues with SaaS delivery versus outsourcing.  I also got several messages of "thanks for nailing this one for us" from services folks.  To clarify my point, I would like to emphasize I am a huge fan of SaaS delivery and strongly believe that SaaS services will enmesh with some areas of BPO to create the genuine business utility models for the future.  BPO provides that level of business-customization for those business processes that are enabled by the SaaS app.  I believe the issues are more about IT folks understanding the basics of business service delivery – and vice-versa.

My concerns with SaaS delivery are how companies govern their business processes that are supported by SaaS application delivery.  It is a serious step


for companies to enter into an outsourcing engagement, with significant change management required to establish governance over those outsourced processes.  With SaaS, companies can sign up, flip a switch, and they're up and running with zero upfront investment.  Does this mean they are going to invest nearly as much attention on governing these processes? 

A well-crafted outsourcing contract stipulates where data resides, how it is protected, who has access, which measures are in place to accommodate political or natural disasters, and how data management complies with regulations. In addition, outsourcing providers are SAS 70 compliant, but not all SaaS providers are. With SaaS, data is being processed in the Cloud. But does the Cloud have parameters? Does a SaaS contract have any reference to where cloud is located?

The answer to many of these questions lies in the service contracts. As with any contract, exits should be considered in the case of poor delivery, security or compliance. The critical issue here is your ability to extract the database of information developed under the SaaS model, and ensuring it is compliant with porting to a different model, another SaaS service provider. For example, I recommend periodic delivery of a copy of the database and then an investigation into the portability of the data. The service contract should specify the data model and rules for how data is represented.

The core benefits for the customer is when the BPO provider takes responsibility for managing the SaaS application.  Then the service provider is taking on the governance headaches that SaaS can bring to the table, while offering a one-to-many process workflow to its clients.  The service provider can also work with its clients to transform its current processes onto the SaaS application model.

Let me reiterate that we're talking about BPO here, where the fundamental delivery is business process-based, and not IT based.  In an ITO context, the service provider is basing its revenue model on developing and supporting an application / suite of applications, hence SaaS can conflict directly in when it is eradicating the need for application customization.  BPO is a different ball-game, where common standards and common processes are the critical ingredient, and SaaS fits the bill beautifully.

Bottom-line, this is exciting.  It is the true coming together of application delivery and BPO, but that also means we are also witnessing the coming-together of the IT and business operations worlds.  Bundled BPO?  SaaS-based BPO?  Call it what you want, but we're finally seeing those barriers come down.

Bookmark the permalink | Leave a trackback: Trackback URL

5 Comments

  1. Stephen Cohen
    Posted April 10, 2009 at 4:21 pm | Permalink

    Phil -

    I tip my hat to you for raising this discussion. SaaS, in concept, is incredible, and BPO can provide the flexibility to make it work effectively for businesses, supported by low-cost resources. You are correct is highlighting that there is a culture clash between technology and operations people in understanding how SaaS can be most effectively deployed. But is should prove to be a great change-agent which we so desperately need,

    Stephen

  2. Posted April 10, 2009 at 5:24 pm | Permalink

    As someone with recent experience both with outsourcer’s approaches & SaaS + Cloud-based models, it’s not yet obvious how the Outsourcers will mesh the “O” with the Cloud, let alone a full move to SaaS. At its essence, a SaaS model is at the opposite end of the software development/maintenance paradigm that outsouring providers are still largely relying upon. However, it makes a lot of sense for them to embrace it more forcefully.
    SaaS and cloud-based apps are two different things, not always together.
    The day when a big Outsourcer buys a Rackspace or likewise will be the day when they start to take the cloud seriously.
    Re: “Does this mean they are going to invest nearly as much attention on governing these processes?”. Both SaaS & Cloud-based approaches do have lower entry costs (from a user’s perspective), but they still require a necessary degree of management, ramp-up and governance.

  3. Posted April 11, 2009 at 8:12 am | Permalink

    Hi Will – very good points.

    I believe it’s the BPO providers who will pioneer SaaS delivery in an O model, while the ITOs ultimately view SaaS as disruptive to their revenue model (unless in niche areas where it makes sense to use a SaaS app),

    Phil

  4. Posted April 12, 2009 at 8:17 am | Permalink

    Phil, I added another POV – why is BPO itself not taking advantage of SaaS

    http://dealarchitect.typepad.com/deal_architect/2009/04/bpos-menace-software.html

  5. Anupam Tantri
    Posted June 3, 2009 at 3:08 pm | Permalink

    SaaS (or bundled BPO) can work and would be more appropriate for mundane, run of the mill non-unique processes such as payroll, travel expense management, run-of-the-mill workflow solutions, simple accounts payable that is not tied to the company’s upstream ERP processes, etc. However, as a consumer of SaaS, I would be very concerned about exit strategy, data recovery, communications security, and internal controls. I would want to make sure that the SaaS provider is SAS70 compliant and finally, I would never put my critical processes (what is critical will vary from company to company) on SaaS.

Post a Comment

Your email is never published nor shared.