Pharma Focus Asia


How you and your teams can digitally innovate successfully in the Pharma ecosystem

Fausto Artico, Global R&D Tech Head and Director of Innovation and Data Science, GSK

Kevin Harrigan, Director of Innovation and Engineering, GSK

Digital innovation provides Pharma companies with unique opportunities for creating long-term, competitive, sustainable advantage. However, Pharma companies aren’t tech companies; they are often not structured in ways that foster innovation, and their culture is very different from that of more agile and risk-taking BioTech companies. In this article, we will, therefore, cover some of the most important challenges you will face when you try to introduce and integrate digital innovation into the fabric of the Pharma ecosystem, as well as provide suggestions for solutions. – Fausto Artico: Global R&D Tech Head and Director of Innovation and Data Science, GSK.

Data is the new oil, or so they say. However, your ability to extract the oil and to ensure its quality are only two of the elements you need to create digitally innovative solutions. There are important technical activities that are also required in order to create a solid and reliable foundation for your digital innovation journey. And lastly, there are aspects related to the organisational structure and the pervasive culture that characterises Pharma companies that must be addressed. These two additional aspects (i.e., organisational structure and culture) are critical to the success or failure of your digital innovation efforts and so your capacity to create new digital solutions and have them adopted inside and outside your organisation.


Your existing systems determine the next phase of your digital innovation process. Where are you today in your journey?

You need to build on strong foundations, and that requires the ability to correctly self-assess what infrastructure you, your teams and your organisation have. To start, are you sure you and your teams have the skills to correctly evaluate the reliability and quality of your company’s existing systems or do you need outside help? The reason I am asking is because I often see non-technical people who are very enthusiastic about what they and their teams have accomplished in the past three to five years or have available as existing systems, yet all too often the architectures and software components of the systems are not reliable. In fact, many times the architectures are the result of no more than activities executed to make many different legacy systems and vendors’ products able to “speak with each other.”  In other cases, where new systems are created from scratch, all too frequently such systems are standalone and not really integrated and able to seamlessly communicate with existing ones, and so the value they generate is only a small fraction of what it could be. Correctly assessing your systems necessitates multiple teams (internal and external) to obtain a more reliable snapshot of the real situation and must be executed before starting or continuing your digital innovation initiatives.

Try not to take steps longer than the length of your legs (i.e., your capabilities). Often people rush forward and try to create and put into production Artificial intelligence (AI) and machine learning (ML) solutions that cannot succeed because they are designed incorrectly. This isn’t due to missing data, poor data quality and/or the lack of some system components that are foundational for the  solutions but is due to a lack of capabilities. Asking for help to understand which capabilities you need to build or acquire for the different phases of your journey is money and time well invested and will avoid many headaches when you have to design, implement and productionalise multi-year transformational projects. Such projects are complex but can be de-risked in smart ways especially if you modularise them, deliver incremental value, and design their architectures in ways that will hyper-automate activities. Remember also to embed security principles from day one. De-couple software components enough to avoid vendor lock-in. Enhance plug-and-play capabilities as much as possible so that you can swap architectural components as necessary if some technologies become mature much more quickly than others. Finally, to correctly scope and decide on future architectural choices, you will probably need to hire the right people (e.g., computer scientists) with the right skills from outside your company.

Don’t consider just some architectural aspects to the detriment of others during the creation of your solutions. Many times, solutions fail to be put into production  because somebody overlooked some regulatory aspects, or the final systems aren’t secure, or some technologies cannot be validated for the production systems because they simply cannot be integrated with other production components that have already been approved for commercialising a drug. Creating new solutions requires much more than just the creation of new digital models (e.g., AI/ML). Pharma is complex and the number of components that need to be considered to create new solutions goes well beyond the creation of such new models and their ability to correctly predict outcomes or generate new insights. Involve many teams as you design or acquire new solutions; you do not have all the pieces of the puzzle, and getting expert feedback greatly helps to de-risk the process.

Remember, you must at least have an accurate, ten-thousand-foot view of what is going on under the hood of your overarching system; you must correctly assess your capabilities; and you must make sure there aren’t overlooked aspects. Otherwise, the risk is that independently of how many skilled software engineers you have in your team and organisation, you will take decisions that are destined to fail (and some could consume years of work and a lot of money).

Prioritise your opportunities and focus on the ones on which you can already deliver today. They are easy to discover if you execute the previous activities. As you deliver on low-risk, but valuable, low-hanging fruits, continue in parallel to develop new capabilities for opportunities that are out of your reach now but tomorrow will become easy to deliver, thanks to the additional work you and you team are doing.

Organisational Structure

Pharma can be very conservative and risk averse. This is because patients’ lives are important, and over the last 200 years, regulations to approve and commercialise drugs have become more and more complex. Getting a new blockbuster drug approved can easily require more than 10 years. It can, therefore, be difficult to take risks, try new things or bet on new innovative technologies not yet regulated and approved. In addition, the binary nature of clinical trials (i.e., success or failure) makes it difficult for executives to approve the use of such emerging technologies in some verticals of the organisation (e.g., clinical development compared to earlystage discovery).

It is much easier for a Pharma company to acquire other companiesthan to create new ones. This is especially true after a new digital technology has been proven to be mature or a BioTech company has successfully completed the phase III of a clinical trial and therefore its drug can be commercialised. Pharma is often even willing to pay a premium for waiting so long (e.g., 7 to 10 years in the case of drug approval) just to de-risk the process. Pharma venture capital branches would be well advised to be more willing to use a fraction of the money they have to help digital companies in their early stages to survive. Furthermore, they should drive their product roadmaps, at least for the digital products that are not directly connected to critical and highly regulated aspects of drug approval but that can help to greatly accelerate  other phases of the Pharma pipelines. This would allow Pharma companies to leverage external expertise to create new systems in ways impossible to accomplish using only their internal capabilities. It would also allow Pharma companies to create much more flexible digital ecosystems that are today impossible to deliver in any reasonable time by big vendors since big vendors are often forced to standardise their products and use cookie-cutter approaches because of the support they must provide to their many clients.

While Pharma executives may understand the importance of innovating, they are often unaware of the fact that the existing organisational structure threatens the efficacy of innovation teams and/or is setting them up for failure. For example, many of the non-technical challenges  innovation teams face are mainly due to how they are funded, and this is directly connected to how the organisation is structured. Funding is typically provided by other teams that often impose many constraints. Instead, Pharma should create and set up innovation teams as independent units (i.e., independent companies, really). The innovation teams should receive enough money to execute twoto- three years of work and be tasked with delivering multiple projects and initiatives. This does not require a lot of money (just from a few million to a max of 10 million dollars). This amount of money is nothing compared to how much is usually invested in other large-scale initiatives and paid to big vendors (i.e., from tens to many hundreds of millions of dollars). The innovation teams should also be set free to design and implement whatever they deem necessary to prove their value and maximise the return on investment. They should set up their own systems and ways of doing things, independently from the existing IT systems and other teams’ ways of working (although, of course, co-development and collaborations need to be supported and incen incentivised). This freedom might be scary for some executives to accept, but it would allow innovation teams to prove their value. Furthermore, freeing up innovation teams from as many constraints as possible provides them with the ability to turbocharge the transformational changes that senior executives need developed and deployed into the organisation in very short time frames (e.g., from 1-2 quarters to a max of 2-3 years).


Existing teams may unfortunately think of digital innovators as servants to their most pressing needs. Because of this, innovation teams often are told what to do instead of being free to explore. In addition, many members of existing Pharma teams do not have the technical background necessary to understand how to drive architectural choices and so create and inadvertently deliver digital transformation plans that generate only partial success, lots of frustration for tech people and make it difficult for an innovation team to prove its value. In addition, because the team members of an innovation team are usually very skilled, they are liable to be asked to put their critical long-term projects on hold again and again as they are continuously reassigned on demand to different teams to fix urgent problems that are affecting the day-to-day production system operations. Under such conditions, it is practically impossible for an innovation team to deliver on its projects

Overlaps and competition. Digital innovation is chic. If several innovation teams are created in different parts of an organisation to satisfy the requests of several high-level stakeholders, they may well find themselves competing against each other. This is a cultural alignment problem that can be solved only from the top layers of the organisation. In addition, some teams that are powerful enough could decide to create inside themselves an innovation team from scratch. I understand that existing teams might want to transition some of their people to do digital innovation work, but is this really a feasible option? Pharma people are usually biologists, statisticians, etc., and don’t come from a computer science background. Many times, what could seem easy to them to accomplish in the digital field is full of technical traps visible only to the eyes of a computer scientist. Furthermore, Pharma people usually don’t know programming, and Pharma, like Finance, is a heavily regulated sector full of legacy systems and complex interdependencies among many software components. Would it not be better to have innovation teams and existing teams co-develop solutions together? Each could add value through its domain of expertise and skillset (programming and architectural choices for computer scientists, drug discovery for biologists, etc.). Each should be considered a peer, with the equal possibility of proposing new solutions. Each should decide how to implement the parts of the solutions that fall inside its domain of expertise. Senior executives need to avoid competitive dynamics and generate as much alignment as possible. If this is impossible, they should at least make sure that in each vertical (e.g., early-stage drug discovery, clinical development, manufacturing, supply chain, etc.) there is no more than one innovation team working on each objective per geographical area / site and that it is considered a peer department, appropriately funded, to the others that exist in the vertical.

Finally, for executives, it is difficult to justify the creation of independent and peer-like innovation teams. They seem like big, ‘risky’ bets. But this is not true, especially if other initiatives can be used as comparison. However, such comparisons can be difficult to make because failures tend to be brushed under the carpet and/or presented and reframed as at least partial successes that were necessary to execute anyway. But without funding innovation teams appropriately, what kind of future can we create? Patients need our help, and so innovating is important. It cannot be dismissed or deprioritised. While people understand this, it is also important for executives to continue to educate their companies and C-level stakeholders that innovation initiatives need to be sufficiently funded, and that innovation teams need to be independent and considered peers by other teams and departments.


We have discussed how technical aspects are only some of the important components that are necessary to consider to successfully design, implement and deliver digital innovation. Organisational structure and culture are two other critical aspects that will determine the failure or success of your digital initiatives. With the information in this article, you are better equipped to successfully start or continue your digital innovation journey.

Without digital innovation, your company will fall too far behind competitors and disappear. This may take a long time, but it will be inevitable if you do not successfully innovate in the digital field. Some people might argue that the Pharma sector is characterised by incredibly high barriers to entry, but 3D printing with other emerging technologies could destroy or at least lower considerably all such barriers in the next 5 to 10 years. It isn’t difficult to image a future where people can buy a 3D printer, install it at home as a plug-andplay device and automatically program it in a hyper-automated, push-button fashion and download recipes from Blockchain networks in a way that could be completely unregulated and/ or difficult to monitor for governments.

Being open-minded, creating partnership ecosystems and digitally innovating are some of the best means of continuing to create useful, life-saving products for people, align companies with great environmental and social goals, as well as personalize experiences in ways that will transform patients into even more confident consumers and expand opportunities to positively impact larger and emerging markets.

--Issue 50--

Author Bio

Fausto Artico

Fausto has two PhDs. As a Physicist, Mathematician, Engineer, Computer Scientist, and High-Performance Computing (HPC) and Data Science expert, Fausto has worked on key projects at European and American government institutions and with key individuals, like Nobel Prize winner Michael J. Prather. After his time at NVIDIA corporation in Silicon Valley, Fausto worked at the IBM T J Watson Center in New York on Exascale Supercomputing Systems for the US government (e.g., Livermore and Oak Ridge Labs).

Kevin Harrigan

Kevin graduated with a BSAE in aerospace engineering from Pennsylvania State University. During his collegiate career he gained experience in a co-opposition with Capital One Financial as a Data Analyst at in Richmond, Virginia. It was this experience that afforded him the opportunity to find passion in data munging, applied statistics, and programming. Following graduation, he accepted a full time offer in their newly formed Digital Enterprise Organization, expanding his technical and analytical knowledge in areas such as distributed computing, clickstream analytics, multivariate testing, anomaly detection, and propensity modeling

magazine-slider-imageHexagon - Expert Insights WebinarMFA + MMA 20244th Annual Cleaning Validation 20242nd Annual Pharma Impurity Conclave 2024CPHI Korea 2024CHEMICAL INDONESIA 2024World Orphan Drug Congress Europe 2024INALAB 2024Thermo Fisher - Drug Discovery and the impact of mAbsAdvanced Therapies USA 2024ISPE Singapore Affiliate Conference & Exhibition 20242024 PDA Aseptic Manufacturing Excellence Conference2024 PDA Aseptic Processing of Biopharmaceuticals Conference