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.