Innovating Customer Relationship Management Cloud Services at Standard Chartered Bank

Abstract

As we saw in Chap. 7, cloud computing is a rapidly emerging technology with potentially massive impacts. But organizations have been struggling for some time with how best to gain business value whilst addressing the new challenges of yet another disruptive technology. Whilst there is a growing body of research into cloud computing, there have been very few case studies that analyse the business benefits to organizations. This chapter aims to answer the call for research on business issues relating to cloud computing from both a cloud consumer and cloud provider perspective (Venters and Whitley 2012; Yang and Tate 2012), and research investigating business impact empirically (Hoberg et al. 2012). The research builds on extensive outsourcing research, answering the call for more detailed longitudinal case studies (Lacity et al. 2010, 2016).

Introduction

As we saw in Chap. 7, cloud computing is a rapidly emerging technology with potentially massive impacts. But organizations have been struggling for some time with how best to gain business value whilst addressing the new challenges of yet another disruptive technology. Whilst there is a growing body of research into cloud computing, there have been very few case studies that analyse the business benefits to organizations. This chapter aims to answer the call for research on business issues relating to cloud computing from both a cloud consumer and cloud provider perspective (Venters and Whitley 2012; Yang and Tate 2012), and research investigating business impact empirically (Hoberg et al. 2012). The research builds on extensive outsourcing research, answering the call for more detailed longitudinal case studies (Lacity et al. 2010, 2016).

Our research into Cloud Customer Relationship Management (CRM) systems adoption at Standard Chartered Bank (SCB) focused on three key research questions (Appendix details research methodology):

• Identifying emerging value propositions. Innovations create new potential sources of value. What are the new sources of value that SCB achieved? What new sources of value, business models, relationships, and transactions were achieved? How did interdependencies and relationships change between SCB and their service provider?

• Establishing context and capabilities needed. Innovations require the right context. How did SCB and their service provider organize for success? What capabilities were required, and how did they evolve over time? What impact, if any, would there be on future organizations?

• Managing diffusion and change. How did a cloud innovation get introduced in a large organization? How was it accepted and implemented? How was it exploited? What were the impacts on ways of working; internal and inter-organizational changes in relationships, cooperation, and competition? What implications are there for the future cloud-enabled organization and further business innovations?

In what follows, we establish the business context to which software-as-a-service (SaaS) CRM was seen as the solution, summarize the CRM journey undertaken and the outcomes achieved, identify eight emerging challenges and how they were dealt with, and then point to one lesson that frames 11 other lessons relevant to those contemplating a similar journey.

Standard Chartered Bank: The Business Context

SCB with revenues of approximately $20 billion plus per year is a large, diversified financial institution focused on rapidly growing emerging markets in Asia, Africa, and the Middle East. Over 90% of income is from those regions. SCB operates in over 70 countries and territories, in 1700 branches and outlets, with 88,000 staff from 130 nationalities. SCB was first formed in China and India in 1850. SCB’s strategy is to be the ‘world’s best international bank’ focused on Asia, Africa, and the Middle East. SCB aims to ‘bank the people and the companies driving investment, trade and the creation of wealth across Asia, Africa, and the Middle East’.

When the Cloud project commenced in 2008, the bank comprised of a wholesale bank (WB) and a consumer bank (CB). The CB was responsible for small to medium enterprises (SME), private banking, and consumer banking. In 2008, it was decided to adopt a more customer-centric strategy. This would be achieved by simplifying how the bank interacted with its clients and customers by standardizing on processes whilst improving efficiency and consistency through improved systems. The two key issues to be addressed were inconsistent staff systems and inconsistent customer experience.

Inconsistency of staff systems was accentuated by dozens of differing CRM solutions across the CB. Systems were fragmented, stand alone, channel specific, and product specific. There was limited coordination of CRM. Staff had to operate up to 15 different systems to serve customers, whilst in some geographical markets, systems were manual or dependent on spreadsheets and ad hoc databases.

Customer experience was inconsistent. Clients filled out paper forms to open accounts or apply for services that were then processed manually in offshore service centres. Customer service requests were difficult to respond to as there was limited visibility of progress of customer service requests and the client’s overall relationship.

In 2008, work commenced on building an integrated sales and service capability (Customer Experience Management System—CEMS) to support the sales transformation agenda—the ‘SCB Way’. How would success be measured? Success would be measured via metrics that looked at driving customer experience, fixing front-line experience, and assessing CRM impact on operating income, sales productivity, and operating profit.

CRM Cloud Services: Scope and Implementation

Here, we follow the Costello (1996) definition of innovation as ‘managing the cycle of capturing knowledge from organizational activities and learning from that knowledge to change behavior and improve organizational activity’ (see also earlier chapters). We will employ the Costello (1996) framework that embodies this definition to analyse innovation throughout SCB’s cloud journey. A synopsis of that innovation journey appears in Table 8.1.

Table 8.1 Innovation cycle for Standard Chartered Bank CEMS

In the first three years, CEMS was rapidly rolled out to 26 countries and was used by 14,000 active front-line users. By the end of 2012, the number of users had continued to expand and was over 24,000. By 2015, the usage continued at this level. Daily volume was in the order of 72,000 new sales opportunities, 73,000 incoming calls to call centres, 23,000 new service requests, 32,000 sales conversations, and 10,000 new sales closed. The system was processing over 500 transactions per minute (see Fig. 8.1).

Fig. 8.1

CEMS sales and service capabilities

As at 2015, SCB employed CRM On Demand (CRMOD) (SaaS) from a leading vendor, in conjunction with in-house development. The CRMOD component of CEMS was managed as a SaaS private cloud run on SCB hardware in a data centre in Hong Kong.

The CRMOD system supported both the consumer and WBs. Of the 24,000 users, approximately 3500 were in the WB. Each part of the bank has differing requirements for CRM. The CB deals with millions of customers who have multiple specific products such as bank accounts, credit cards, home loans, and so on. The WB has a much smaller number of clients who have complex needs such as cross-border payments, credit, investment loans, and so on. A WB customer could be a large corporate with hundreds of subsidiaries all over the world. A consumer client is likely to be in one country and have a clearly defined business relationship with SCB.

Outcomes

The key outcome of implementing SaaS was that it proved to be a quick and cost-effective means to support development of a more customer-centric culture at SCB. There was now a foundation capability that supported the cultural change aimed for. Outcomes and performance helped to found a service culture at the bank. Likewise, there was now a technical and operational capability that could be built upon to add value:

I think the thing that we have achieved today is to roll out something that does sit on 26,000 desktops. It is really getting some intelligence down those lines. In India and Singapore, I can send real time alerts to my front line that is a reflection of something that has happened in the world of an individual customer that might be an opportunity for us to service, or sell, or both. That once wasn’t possible. The fact that I can do that is a major achievement. The fact that we switched on a complaints management system that was developed in this whole framework. We deployed that to nine countries in a single day. That is the first time in this bank that anything has ever been deployed to more than one country in a day. … Very importantly you had a network of people who were connected who were able to implement it. We didn’t have someone who had to fly around nine countries and say “hello I am from Botswana and am here to help”. We have built a network of competent people who could work together.—CIO Consumer Banking.

In practice, CRMOD has played a significant role in SCB achieving its strategic goals. Meanwhile, key performance indicators have continued to improve over the years as indicated in Table 8.2.

Table 8.2 Key customer metrics

Moreover, performance on other dimensions showed significant improvements, in particular, in the areas of:

Fixing front-line experience:

• SCB Way coverage—countries, call centres, branches, front-line staff usage

• CEMS roll out across geographies and functions

• Per cent STP for service requests

• Front-line staff satisfaction

CRM impact of real performance:

• Sales productivity—conversion of new sales

• Operating income

• Operating profit

Cloud and CRM: Emerging Challenges

Given this level of success, it becomes important—and also useful for other organizations contemplating cloud-based CRM—to analyse the challenges along the way and how they were dealt with. We identified eight major challenges.

Challenge 1: How Can Business Value Be Achieved?

Speaking in 2013, the CIO of Consumer Banking observed:

Five years ago Standard Chartered had deployed Siebel in the branches in Hong Kong and Siebel in the call-centers in Singapore. Standard Chartered also had a team in India developing a CRM system for use in India. The Chinese were developing their own system called “Panda”. We had also gained another two systems when we acquired banks in Korea and Taiwan. The Indian development team had been working for four years, spent a lot of money and deployed nothing. We were about to deploy our seventh CRM system and wanted to deploy something into Malaysia, Thailand, Indonesia and UAE. Clearly this situation was not viable.

At the same time, new bank management was emphasizing a business strategy anchored on improved sales and service, and entitled the ‘SCB Way’. Implementation of the strategy was dependent on building robust CRM capabilities. However, previous implementations of on-premise CRM in some of the larger markets had cost over $50 million:

If you look at the implementations of Siebel in Singapore and Hong Kong, the approach was very much growth focused. The way that the CRM was built out was very specific to their needs without consideration of the needs for the other countries. How is the rest of the world going to be able to afford the same capability? That translates into prohibitively high cost for the rest of the countries. That was a good lesson learnt by us. … Some of the country markets are very small. You cannot ask them to pay $2m up front for a solution when the revenue is not there. Therefore, SaaS actually fits our objectives quite well.—CIO Consumer Banking.

On our analysis, four practices proved critical to achieving implementation and business value.

• 1. The technology strategy was driven by business owners. Thus, by way of illustration, the Head of Technology, SCB said:

  Primarily business champions as opposed to IT champions drove the process. … The business’s primary concerns were about regulatory compliance, client data confidentiality, and data privacy requirements.

• 2. Building buy-in from stakeholders. Neither of the SaaS providers at the time had services hosted in SCB’s preferred location of Singapore. Being able to support SaaS on-premise in SCB’s Hong Kong data centre became the key deciding factor. The business was also concerned about how best to ensure rapid adoption of the system as opposed to spending a lot of time and money building a system only to fail with poor adoption. The top three practices that proved successful in building ‘buy in’ from, and rapid adoption by, stakeholders were:

  • SaaS could be deployed quickly, and for the business stakeholders, time to market was key.

  • The investment upfront was much lower than building a system.

  • The ability to quickly implement a ‘Proof of Concept’ (POC) helped the decision to move moving forward.

• 3. Adopting a ‘pay as you use’ pricing model together with phased implementation. The SaaS ‘pay as you use’ pricing model de-risked what would otherwise have been a significant IT project. The service could be rolled out in phases. As parts of the business reported benefits achieved, the pace of implementation could be adjusted. Likewise, implementing a ‘take it or leave it’ system avoided expending resources on agreeing functional requirements:

  If it didn’t work, or the take up was lower than expected, then there were fewer issues to deal with. … There was less debate about functional requirements and more focus on adoption.—Head of Technology.

  The ability to pilot and implement incrementally supported transition and implementation. However, this was also supported by practices we discuss in more detail below, namely:

  • Clearly defined scope agreed to by both the bank and the service provider. Given that it was SaaS as opposed to customized software the process was simplified.

  • The ability to implement a POC enabled the business to better understand their requirements to deploy the model internally and support it moving forward.

  • The high level of familiarization training was key to the team understanding how best to deploy. An in-house capability was built to drive adoption and deployment.

• 4. Employing a cloud solution in conjunction with in-house development. This enabled a rapid roll out, shorter time to market, overcame many of the problems of diverse geographical markets and language, and provided 24x7 service, for an affordable upfront investment and ongoing operational costs.

  CEMS was critical in enabling the broader SCB cultural change programme to become more customer centric—‘SCB Way’. The system enabled parts of SCB to better understand the advantages of CRM and to develop a CRM culture. In the WB, it allowed relationship managers (RMs) to see the real value of managing contracts, sharing opportunities, and sharing information across the various businesses.

Challenge 2: How to Integrate Cloud CRM Technically with Internal Systems?

Firstly, integration of CRM with other bank systems is where most of the expense and delay were created in traditional CRM implementations. Normally, it is the CRM system that is heavily customized to limit disruption to extant legacy systems. In the case of SaaS, extensive customization is not an option. Consequently, much of that complexity was avoided. However, that does not avoid a dynamic where the customer is trying to avoid changes to their systems by asking the service provider to modify their service or alternatively using some services in ways that they were not designed for. Likewise, the service provider is trying to keep the software as simple and generic as possible to avoid unintended consequences that impact the vast majority of customers. From the service provider’s perspective, it is critical that all customers are running on the same version of the software. This includes releases that apply patches or add new functionality or services. Otherwise, the degree of complexity becomes exponentially challenging. One lesson learned was on the role of enterprise architecture.

Enterprise architecture enabled exploitation of SaaS. SCB implemented a capability-driven architecture to manage the portfolio of services required. Services were integrated via an SCB-developed integration layer. The role of the integration layer was to simplify integration of services from other bank systems. Integration with a heterogeneous legacy architecture can raise significant challenges for an SaaS service. For example, it is difficult, or impossible, to customize how the SaaS service operates internally. This often places integration challenges with either the integration layer or legacy systems. As the CIO of SC Consumer Banking described it:

How are your internal applications going to work with a service that is effectively a ‘black box’? If you don’t understanding how it works then the whole system might not work. You need to have a very clear roadmap how you are going to integrate all this moving forward. If you don’t, then the SaaS and the internal systems could develop divergent paths. The challenge is that you could end up building two different types of software. And then your frontline would have to deal with two different systems.

Secondly, despite a thorough understanding of the product, there are always unforeseen requirements that emerge over the life of the project that place additional demands on the SaaS:

Because we do not understand what CRMOD can or cannot do, we force it to do something that it can’t. Consequently it broke down all the time. This was a good lesson learnt.—CIO Consumer Banking.

SaaS demands very robust architectural practices; ideally, the service should be interacted with exactly as specified. Organizations with strong systems development skills, but less disciplined architecture capabilities, are tempted to try to work around what they see as limitations. The service provider—Oracle—had been operating SaaS for many years and had experienced challenges with non-standard implementations. Despite Oracle strongly recommending standard implementation, many customers are tempted to do otherwise. The result is often unforeseen consequences such as reliability or scalability that could not have been anticipated by an in-house development team. Whilst SCB’s implementation of CRMOD was an early adoption of SaaS, their experience convinced them of the long-term architectural viability of more extensive SaaS models.

Challenge 3: How to Respond to Regulatory Requirements?

In practice, in a highly regulated environment like banking, regulatory requirements need to drive SaaS strategy. Over 40% of SCB’s technology spend is attributable to regulatory compliance. This is accentuated by serving such a diverse geographical region. Each jurisdiction changes requirements regularly. Often these requirements are negotiable, but in general, most jurisdictions would prefer all banking systems to be resident within their borders. Regulators are concerned about the impact on their economies should there be a reduction in banking services. They are also concerned about data security. Most regulators demand that customer data remain within their jurisdictional boundaries. It is then up to SCB and their service providers to convince the jurisdiction that sufficient precautions are in place for that not to be necessary. According to the Head of Technology:

The major risk for CRMOD has been around data confidentiality. We had to get our central compliance teams involved to ensure that the solution we implemented will meet the regulator’s requirements across the markets. That drove the decision to have the service installed on Standard Chartered premises. Even access to the environment by Oracle support people was done through a controlled and audited access method. This allowed Standard Chartered to have control of Oracle’s access to the private Standard Chartered cloud.

Regulators continue to revise their requirements. An ideal solution for SCB would be a localized SaaS operating in each of the major markets. The challenge is managing that level of localization and running the system in multiple countries cost-effectively:

In any service offering whether cloud computing or a managed service from an external vendor that is the biggest thing that we always look at—security and data confidentiality. They are the key drivers for adoption of any service offering—more so than the commercials. Most cloud computing seems to be a good commercial proposition, however the issue for Standard Chartered is how much higher is the operational risk.—Head of Technology.

Challenge 4: How to Sort out Contractual Governance for Cloud CRM?

SCB’s solution here enabled the commercial outcome to reflect the value delivered. Contract pricing was per user. SCB was responsible for hardware investment and data centre costs. Compared with implementing a traditional CRM system, the level of investment was much lower. Especially in comparison with SCB’s previous expenditure implementing CRM in Singapore and Hong Kong, SaaS was significantly more cost-effective.

The Service Level Agreement (SLA) comprised standard Oracle terms and conditions. There were penalties for poor performance which have been imposed. We had some issues with service availability where the penalties have been exercised. (Head of Technology).

Many of the SCB requirements created challenges with meeting SLA stipulations. For example, the preferred SaaS deployment model was for it to be hosted in an Oracle approved data centre. SCB hosted theirs in Hong Kong for regulatory and cost reasons. Likewise, to gain regulatory approval, access to the systems by support technicians was limited to an ineffective and cumbersome terminal access system that made support and maintenance difficult. According to the Oracle director of SaaS Operations:

It is very complex to manage [SaaS] in an @customer model and considering the limitations imposed by Standard Chartered with the implementation of Terminal Server for monitoring, automation, performance qualification, log retrieval, etc… it was quite a challenge.

Contractual governance was managed by SCB legal, Oracle legal, and IT resourcing departments. This was the first such contract for SCB in terms of scale and coverage. The SCB legal team was very heavily involved. Even in 2016, legal was very much involved in monitoring and renewals:

They are very well aware of the terms and conditions. They know the Oracle legal folks! Both legal departments have developed close working relationships. Standard Chartered has now developed a good understanding of SaaS legal requirements.—Head of Technology.

Despite a number of significant challenges over the years, contractual governance was considered to have been successful. SCB has achieved its business goals at a reasonable cost. Evidence of the success was increased volume purchased as well as increased commitment. The CO of Consumer Banking commented:

The commercial side of it has been an output not an input. Not the other way around. We have increased each year the commitment to Oracle. There is a lot more revenue being booked against the system now than could have been anticipated at the outset. It is also a lesson in letting the commercial outcome be a benefit of what is actually valued, rather than selling a lot of stuff that even if you are not using it is just your problem.

The contract was renewed in 2014. SCB subsequently conducted a strategic review of their CRM needs and considered how best to satisfy them. Options included: continuing with the existing SaaS service unchanged, a more integrated solution (where Oracle also takes responsibility for hardware, data centre, and managed services), migrate to the new Oracle sales cloud service, migrate to an alternative SaaS, or build a customized solution.

Challenge 5: What Management Skills and Capabilities are Needed for SaaS?

At the time of the commencement of the contract, neither the bank nor the service provider had significant experience managing long-term SaaS. From the bank’s perspective, SCB had a strong internal IT build capability located in India that was most familiar with building customized systems. They were used to purchasing ‘software’ which they then modified and implemented. They were not accustomed to purchasing a ‘service’ which was very difficult to modify either functionally, technically, operationally, or contractually. CRMOD is a SaaS. From the service provider’s perspective, although Oracle had been delivering SaaS services for many years, the CRMOD offering was relatively new and SCB was one of the first large customers. Compared with many other customers, large banks have very complex and specific needs. There are multiple internal banking systems that the SaaS must interoperate with. Depending on how this was done would impose additional requirements on either the SaaS or the bank’s internal systems.

SaaS offerings have been developed by software companies. Software development is a very different culture and capability to managed services. SaaS is sold by software sales people but run by service people. The challenge for a software company offering SaaS is to seamlessly transition back and forwards between sales and service. This needs to be done in phase with the client who will also transition from buying to consuming the service. According to the CIO of Consumer Banking:

alignment between the two organizations is very important. Putting the customer as the centre of your focus of what we do is very important. Typically you might have an organization that is service orientated just like us. But you might have a partner that is not strong in service. They might be strong in software development but have limited experience in service. That can be reflected in terms of responsiveness, and approaches towards dealing with the problem. It can become quite a challenging process because you have that disparity in terms of service focus. Like any other service that you subscribe to, you grow with that service.

SCB developed capabilities to manage cloud service. The key SaaS capability that SCB developed was ‘making technology work’ (Willcocks and Feeny 2003 ). Why was this? The Head of Technology explained:

what I realised was that the bank itself needs to understand how this model needs to work successfully by understanding the constraints and limitations that the vendor has too. Not everything that you require can be delivered by the vendor always. Within the operating model, Standard Chartered did not have the flexibility to deploy internal resources onto fixing an urgent issue as it could only be done by Oracle in a SaaS model. One of the challenges was working out how the support model works. When are people available? When we were having issues, no one from Oracle was available immediately as the US resources are only available in US time zones. Trying to understand how the system works and technical limitations became crucial.

Development of both the bank’s and the service providers operational capabilities are best summarized by the SCB executive sponsor:

I do think at one stage, nobody moved here until Oracle had demonstrated that it wasn’t their problem. Oracle, on the other hand, was not prepared to move unless it was demonstrated that it was their problem. Now if there is a production issue, everyone is mobilised and everyone is working on a resolution—most of the time, any time of the day.—CIO Consumer Banking.

Success has been enhanced by driving a strong ‘business thinking systems’ capability whilst enhancing ‘architecture’, ‘contract monitoring’, and ‘vendor development’. Specific cloud capabilities such as ‘rapid elasticity’ and ‘ubiquitous access’ proved of less relevance in SCB’s case compared with the findings of research into more generic infrastructure cloud services (Iyer and Henderson 2010).

Challenge 6: How Do We Cope with Dynamic Business and Technical Environments?

In response to highly dynamic business and technical contexts, scope, technical, non-technical, and operational aspects evolved over time. The scope of service got modified. Initially, there were considerable demands placed on the service, but as volumes increased, scalability and reliability issues arose:

When we first started, we were trying to work towards CRMOD being the portal for customer and client experience. However, that has been amended along the journey as we have better understood our requirements and the capabilities of the service. It became quite clear that CRMOD could be more like a module than the portal.—Head of Technology.

The initial objective of SCB was to rapidly deploy basic CRM capability to support the business strategy. As the initiative gathered pace and SCB made more progress towards their ‘SCB Way’ strategy, the expectations of the total CEMS system outgrew the stripped down functionality of the SaaS. Likewise, the SaaS became a critical system that impacted on bank operations if it was unavailable. According to the Head of Technology:

This was due to various limitations of the CRMOD such as volume, scalability, and reliability. It became apparent that CRMOD was becoming a single point of failure for an increasingly critical system. The increasing requirement for CEMS resulted in the initial risk rating of the system increasing from medium to high. As the system rolled out to more geographies and to more parts of the bank such as call-centers, the system became more critical for our day to day business and it became apparent that CRMOD service could not support that higher level of criticality.

CRMOD out of the box could not support those heightened requirements. That was the key turning point and why the SCB CRM strategy changed. The bank and the service provider investigated what was causing reliability issues. One aspect was the way some high-volume processes were being routed through the SaaS:

We looked at the processes and tried to tighten some of the processes involved. We externalised some services so that they would not conflict with critical operations. We externalised the whole reporting capability because the demands could not be supported.—Head of Technology.

Extensive reporting capability came standard, as part of the SaaS functionality. As the bank made the reporting functionality available to the wider community, users were ordering reports during peak periods, thereby impacting on response times for critical activities and eventually impacting on the resilience of the system. Whilst the level of data and process integration was appropriate when the bank was building a CRM capability, as that capability grew, demands increased. When CRMOD started, there was no CRM practice within WB. As the client engagement improved, the demand for more integration provided out of the box by the service increased. For example, requirements for private and public deals have different needs. SCB wanted to increase collaboration between the RMs and the credit teams and other support functions, like compliance. By 2013, CMROD could not support that level of process integration. In response, the technical problems had to be worked through to achieve the requisite level.

Challenge 7: How Do We Evolve the Client-Supplier Relationship?

The client-supplier relationship had to evolve from service provider to strategic partner. According to the Head of Technology:

The relationship has changed as we moved from the initial phase of developing a CRM practice. In the second phase of the relationship, there has been recognition from both Standard Chartered and Oracle that the standard model does not work and that we need a more strategic partnership. Where Oracle has been working closely with us and recognised how they need to change their support model and often for us from the initial model. For example, we have a demand to do two disaster recovery drills per year to meet the regulatory requirements. That is not supported in the standard model. Nor is 24/7 support. Continuous releases being made into production is also a challenge. The ability to access the data from different systems outside of the standard channels is also a requirement. For example sometimes it is necessary to extract high volumes of data out of the system for specific purposes. This requirement has to be satisfied by a different technical approach. There have been specific changes in audit requirements that Oracle has taken into the product development cycle based on the feedback that Standard Chartered has provided.

Moreover, relational governance evolved as the service became more business critical. Initially, the relationship was based on a very rudimentary SaaS model that would have been appropriate for a low value service to a small uncomplicated client. As the system became larger and more critical, it was necessary for the relationship governance to become more sophisticated. By 2015, there was a complex matrix of regular working meetings and executive sponsorship that had evolved over time. A key issue when the system was suffering reliability issues was finding an appropriate sponsor in the service provider:

Standard Chartered has developed relationships with more relevant Oracle executives that had responsibility and authority for the systems rather than just executive status. We have executive sponsorship from both organizations today.—Head of Technology.

To support day-to-day problem resolution, additional staff have been provided by both the bank and the service provider to be available 24x7 as required to solve operational issues:

This is working a lot better now. Initially there was resistance from Oracle to offer anything more than the standard service. Eventually with increased executive relationship management Oracle understood the real issues that Standard Chartered was trying to address when an Oracle executive organised the first customer visit (CVC) in San Francisco.—CIO Consumer Banking.

Ownership by senior executives from both the bank and the service provider was necessary to better align expectations:

We started to encounter some problems very early on in regards to stability of the platform. … We decided it would be a much smarter idea if we could collectively solve the issues.—CIO Consumer Banking.

When problems arose, it was not entirely clear what the most appropriate course of action was. One challenge was to find people in both the bank and the service provider who had the time and technical capability to identify the root cause of the issue. The next challenge was finding executive sponsors at both the bank and the service provider who had the authority and resources to ensure that the issue was resolved. The bank had to deploy two of its most capable technical executives whilst the service provider had to engage product development and technical architecture engineering staff that would not normally be distracted by operational issues. Despite the perception of SaaS being a utility, there was still a need for significant internal-retained IT capabilities such as ‘making technology work’ and ‘leadership’.

This case study supports other cloud sourcing research which found that a key antecedent to cloud-driven innovation is a very strong correlation between the levels of collaboration and resulting innovation within and across organizations (Lacity and Willcocks 2013).

Challenge 8: Can Symbiotic Innovation Be Achieved?

In practice, SCB and the service provider achieved differing yet parallel innovation Table 8.3 compares the lessons learnt from the differing perspectives of SCB and the service provider. This analysis reveals symbiotic innovation. From the perspective of SCB, customer experience capabilities continued to innovate within their business. From the perspective of Oracle, the CRMOD experience enabled innovation of the next generation of cloud services.

Table 8.3 Symbiotic innovations Standard Chartered and Oracle

Lessons for Deploying Cloud SaaS

A fundamental lesson SCB and Oracle learnt was that deploying Cloud Services was quite different from systems integration and more traditional outsourcing approaches to developing and leveraging information and communications technologies corporately. At SCB, these differences emerged over time, as did the different implications the three approaches would seem to have for business and performance. In Table 8.4, we demonstrate the differences as they emerged and got acted upon in the case.

Table 8.4 Comparing systems integration outsourcing and cloud services

Within the frame of this fundamental lesson, in our analysis, the SCB case reveals 11 other learnings. We summarize these as:

• 1. Innovation. Cloud computing can be an agile, low-risk, inexpensive, iterative mechanism to enable a complex change programme. In the case of SCB, a relatively simple, cheap, and quick implementation achieved an organizational transformation that had previously been unimaginable.

• 2. Functional Requirements. There is a strong need to understand business requirements and the trade-offs between a custom solution versus SaaS. There is limited flexibility to add or enhance functionality. Understand the service being offered and how it will work for you. It is difficult for the service provider to balance individual client requirements with the larger pool of users. Think very carefully before trying to make the service do something that it was not designed for.

• 3. Non-Functional Requirements. Scalability, reliability, and availability can become issues as usage grows or the system becomes more mission critical. There may be limited flexibility to enhance due to the way that the SaaS has been engineered.

• 4. Enterprise Architecture. Integration with legacy systems can be technically and commercially complex. Ensure that there is full understanding of the intricacies of how systems will be integrated, change managed, problem resolved, and maintained. Ideally, the enterprise’s architecture should enable a clean interface between the service and internal systems. This could include cloud brokerage and security management.

• 5. Integration—Making technology Work. SaaS forces integration responsibility onto extant internal client systems. This can be technically challenging and may require considerable internal flexible, adaptive advanced skills to make the technologies work together.

• 6. Operating Model. The client and provider need to understand each other’s operating model and expectations of service levels and demands. The concept of cloud servicing is not equivalent to turning on a power switch ‘for the services’.

• 7. Capabilities. Just as outsourcing demands enhancement of traditional core IT capabilities, cloud services demand enhancement of capabilities including ‘business systems thinking’, ‘architecture planning’, and ‘making technology work’.

• 8. Change Management. It is significantly easier to implement organizational change management if the system can be implemented incrementally as user demand grows. System demonstrations and training must be available from day one.

• 9. Regulatory. There is a need to understand the regulatory, security, and data privacy implications. A model that works well in the USA might be inappropriate elsewhere in the world. Likewise, a model appropriate for one industry might be inappropriate for one that requires greater security and privacy such as financial services.

• 10. Governance. Relationship management with a SaaS provider is complicated by the restrictions inherent in the service model. There may be limited flexibility due to the ‘take it or leave it’ nature of SaaS. Both SCB and Oracle were committed to the long-term success of CRMOD. This commitment was reflected in extensive inter-organizational collaboration as well as significant executive sponsorship within each organization.

• 11. Business Value. Within the context of an organizational transformation programme there is potentially significant business value. But at the application level of cloud services, as SCB discovered, significant business change is likely to be necessary to capture potential value.

Conclusion

SCB began implementing CRM as a private cloud software as a service (SaaS) in 2008. Roll out was rapid and adoption impressive. Most banks in Asian markets have struggled to implement CRM systems much less get employees to use them. Reach of the system continued to expand country by country. By 2013, SCB had established a sound international CRM capability on which to build additional functionality and to improve efficiency. By 2015, it was being used in over 60 countries by 24,000 front-line staff. Previously the bank had expended considerable resources to implement CRM via traditional on-premise implementations, but had achieved limited success. Implementing a SaaS CRM solution became a significant achievement, but there were major challenges.

SaaS was, and is, a significant enabler of that success. This case study reveals both the advantages and disadvantages of SaaS. Both the bank and the service provider continued to learn and innovate the service over the years. The relationship went through difficult times as the two organizations struggled with how best to operate. Both have significantly enhanced their SaaS capabilities. The service provider has spent the last nine years developing an entirely new SaaS cloud architecture that overcomes many of the earlier challenges. When the extended SaaS contract expired in 2016, both organizations found themselves at an important stage of the relationship working out how best to build on the capability.

Appendix: Research Methodology

The complexity of the research question lent itself to a research methodology based on ‘Grounded Theory’ (Glaser and Strauss 1967) supported by ‘Intention Analysis’ (Sanders 1982) within ‘Case Studies’ (Galliers 1992; Platt 1988; Yin 1984). Interviews were structured to identify correlated change ‘in which change in the antecedent co-occurs with the change in the outcome’ (Kuhn 1991). There were elements of action research with one of the authors an active participant in events as well as carrying our research in the organizations.

All interviewees had considerable experience as IT professionals. The sample of interviewees reflected a cross section from both SCB and Oracle spanning management to operations in both organizations. Likewise the sample spanned business to technology. Most were interviewed multiple times. Initial interviews followed a formal interview protocol. Subsequent interviews drilled down on specific issues. Interviews were conducted during the period 2012–2014. Where possible, interviews were recorded, transcribed and returned to the interviewee for confirmation. Interviews were triangulated with public documents (Ralph and Murray 2003), internal client and supplier documents, and observation. Methodological rigour was supported by good access and triangulation (Dubé and Paré 2003)

Drafts of the case study were reviewed by key stakeholders to ensure accuracy. A smaller subset of key bank and Oracle stakeholders kindly reviewed research findings to verify practical relevance.

Table 8.5 Appendix: Interviewees

Interviewees: Detailed Roles and Responsibilities

• Standard Chartered Bank

  • CIO Consumer bank. Executive sponsor for CRMOD.

  • Head of Technology Solution Delivery. Senior technology manager responsible for SLA of CRMOD and especially focused on reliability as opposed to functionality.

  • CIO Customer Experience, Consumer Banking. Responsible for CEMS design, implementation and operation.

  • Customer Experience Technology Manager, Consumer Banking. Responsible for technical integration and operations of CEMS.

  • Customer Experience Business Manager, Consumer Banking. Responsible for business case and value realization of initial selection and implementation.

  • CEMS Technology Manager. Responsible for technical integration and enterprise architecture of all CRM related technology. Led team of technical problem solvers.

• Oracle

  • Key account director for SCB. Responsible for overall relationship with SCB as well as new sales. Measured on meeting sales and customer satisfaction metrics.

  • Oracle Global Client Advisor, Co-lead of the SCB account. Focused on driving large scale transformation programmes in the client.

  • Senior Principal Technical Account Manager, Jointly funded by Oracle and SCB to assist with service requests and to support trouble resolution. Manages operational issue resolution between the SCB operational team and the Oracle operational and development team.

  • Director, Software as a Service Hosting Operations. Responsible for architecting software solution and technical platform. Engineering role in resolution of functional and operational matters.

  • Senior Vice President CRMOD Operations. Responsible for delivery of SaaS operations.