One Non-Profit’s Path to the Cloud
The Global Fund, created from within the UN’s World Health Organization, was formed in 2002 to fight the three major diseases of poverty that are affecting the developing world — AIDS, tuberculosis and malaria.
As a public-private partnership, it raises and invests $4 billion annually in 474 programs operating in over 100 countries. Over the past 10 years, the organization has distributed 600 million mosquito nets, tested and treated 15 million people for tuberculosis and currently keeps 8.6 million people alive by providing antiretroviral therapy for AIDS.
Over the last three years, the organization undertook an initiative to upgrade its technology infrastructure to meet its growing and changing needs. Practically, that meant transitioning infrastructure and applications to the cloud. In a webinar earlier this year, Global Fund CIO Paul Tuxford described that transformation and recommended best practices for other organizations looking to do something similar. Here are some of his thoughts.
When I joined The Global Fund in 2013, it was very much under-invested in IT. We had a collection of systems that had come out of the World Health Organization, or been developed in the absence of clear strategy. Many key applications faced end-of-life issues with software and hardware, or had not scaled with the growing organization.
One of the first things I did was talk to the executive team to ask what they wanted out of IT. In short, they said, "Just make stuff work."
The strategy evolved from there. Firstly, get the basics working. Secondly, enable our core processes on modern technology. Thirdly, start extending some of these capabilities towards our partners in the implementing countries and fourthly, prepare for the future.
Mobility and data analytics were part of the future plan, but we couldn’t get there without a strong foundation, and core data coming from the application levels. There was a lot of boring stuff to be done first.
Rays of hope
Despite the current state, there were some rays of hope: One, there was some interest in the cloud to start with. And the organization was also pondering whether IT should be a core capability. You need executive buy in for a digital transformation on this scale. A lot of times that is a big hurdle, but I was able to leverage that budding interest to gain agreement on a cloud-first strategy.
We also agreed that we had to fill some application gaps. We're actually running a centralized sourcing function that was forecast to reach $2b within 18 months. A strategy to cover application gaps to get better control, efficiency and transparency around procurement, sourcing, and payables was required.
But the first step was stabilization. If IT systems are going down all the time or people question the accuracy and completeness of data, there's no way you can actually focus on delivering core change projects. There's no credibility for the IT organization. So standardizing IT and getting it stable was critical.
That meant strengthening our own processes for basic things — helpdesk services, ticketing, business continuity, security, data governance and the like. That included reorganizing the team into a more customer-facing service-oriented IT department and focusing on business change services aligned with the executive management team.
This meant practically that we needed to align the business around who actually owned applications, which, it sounds simple, but really was not. Throughout the process, we were starting to make decisions about what applications we would want to take to a cloud provider, either for a hosting environment or for a SaaS application. We identified a number of systems and processes that were taking up a disproportionate amount of both people and computing resources. Those, to me, had to go to the cloud.
However, we did have to go through stages where we put things into a managed data center, stabilized them and then move them to the cloud. I come from a BPO background and one of the principles I live by is, you never outsource your problems. In some cases, Coupa for example, where we had nothing previously, we went straight to the cloud for a very quick time to market and a lower risk profile for the change programme.
The second step was actually aligning on what the priorities for the organization were, and which projects we were going to move forward. There's always a long list of projects, but there's only so much capability within the organization. If you don’t have alignment with business and financial leadership and IT capability, you project is not going to go anywhere.
A lot of what we needed to do to execute the transformation was getting those resources in line, to a point where we could move forward with relative surety that the ingredients were in place and a defined team could deliver on that project.
We had everything on premise initially. Over a 3-year timescale we've actually moved to a private/public cloud mix with an emphasis on public cloud.
A hybrid model
For financial apps, the transformation included major restructuring of the financial system, and moving into a managed cloud services with Oracle. It’s a hybrid model with them managing infrastructure, and us managing the applications, which was the conscious decision taken to manage cost, risk, and quality of service.
With the financial applications, we made a very conscious decision not to move everything into full SaaS. As an organization we are not ready yet for that to change to full cloud and the trade-off loss of flexibility and customization that requires.
And we added a new application - Coupa, which filled a gap within our enterprise architecture. Coupa for us is actually an e-marketplace for the products that we provide to the countries--mosquito nets, antiretroviral drugs, lab testing kits, Land Rovers – and the like.
The Coupa platform allows countries to go in and see the negotiated prices that we have with the individual product provider companies and actually allows them to order it. We're not talking about just ordering a few packets of pharmaceuticals, we're talking about container loads of malaria nets or boxes of antiretroviral drugs for HIV going to Africa or Asia principally.
Savings plus transparency
Over time, we're actually expecting to save about 10% of spend. But that's actually the transparency we now have that will make a bigger impact over the long run.
We’re still relatively new at this, but we now know much better what's going on in those countries, more than we have in the past. We’re moving more countries and more catalogs into Coupa to allow that transparency and that ordering process to happen in countries.
Everybody's moving towards the cloud and SaaS. It's very often difficult to get that buy in from legal or procurement or executive management, but you have to do it. There was already interest in that at the Global Fund, and the way I actually positioned it is that there is an inherent risk of the cost of not doing cloud as well.
For example, to keep an Oracle system running in Geneva, we need to be able to source and retain the necessary skills, and then provide backups for holidays, absence or turnover. There are risks to not being able to provide the necessary skills to manage aging infrastructure and do upgrades, and not being able to provide basic services.
Build around the core
As you shift, focus on building around core platforms. For us, the core platforms were identified and agreed as Microsoft 365, Salesforce, ServiceNow and Oracle. But don't be afraid to differentiate when necessary. Coupa is a differentiator for us.
We have 100% turnover in many of our implementer organizations; many people are only with our programmes for short periods. As CIO, if I took Oracle into Bangladesh and had to give people training, it would not work. If we take Coupa out there, I can run a webinar or a seminar and have people up and running and buying things within a couple of days.
As an IT organization, you also have to shift your focus on skills. Cloud and SaaS require different skills than what IT has had in the past. We’re moving away from boxes and wires and writing code. In this model, it's actually more about account management, business analysis and process analysis-type skills, and as a result you will see your mix of people change necessarily.
I look at it as a big BPO exercise. Examine your core capabilities, whether they're technical or process, and consciously decide what you actually want to keep as a core capability, the rest you can probably outsource. There's a risk inherently in choosing to do it yourself. There's a risk inherently with doing it externally. But the biggest risk is doing nothing at all.