Lessons from Digital Transformation and the Cloud

“Digital transformation provides an opportunity for companies to work with business innovators and business subject matter experts (SME’s) to leverage new technologies and develop new insights that can increase efficiency for business operational excellence.” The aim is to fulfill a company’s roadmap and transform a business allowing it to get closer to its digital goals.

Cloud applications (e.g., Vertical Market Software, VMS) are now being served by software providers no matter their size (i.e., life sciences warehouses, clinical standards and various other mission specific applications etc.) In an effort to reduce costs, very little “coding” is done in-house, and the trend seems to have shifted to the allowance of third parties to create various intra/interdependent integrations. However, from a client’s overall systems management perspective, this leads to managing more “black box” software components and further adding complexity.

Below are some experiences, challenges and advantages of implementing VMS business cloud applications in the Life Sciences space. Just as in the past, we face some of the same challenges that plagued the commercial off-the-shelf (COTS) software:

• Gaps in the target software are not communicated early enough, if even at all. Lack of clear communication leads to difficulties in the navigation from vision to implementation to operational stability for this type of software.
• Each client is burdened with performing their own intensive functional business fit for use due diligence costing time, budget & resources across multiple functions.
• Version releases come with a surplus of bugs requiring mitigation at the patch level & workarounds that include some showstoppers. Validated (GxP) & non GxP software share some similar characteristics in this regard.
• Interdependent systems (i.e. multi-system integration etc.) carry the burden of some vendors blaming each other for faulty software integrations with intra/interdependent systems (i.e. interface response time, optimization, scalability issues & speed of execution of these intra/interdependent interfaces etc.) There is an apparent deficiency in not using end-to-end service level agreements (SLAs) operationally. There is a need to eliminate domain silos and enable end-to-end operational SLAs. For instance, if three interdependent providers each give you a 5-day resolution per the standard SLA. This gives you a total of 15 business days to complete an end-to-end resolution as per the SLA. However, you may be given a business timeline for changes to production of two weeks. This equates to a one-week delay for the deliverable. One quick solution is to develop end-to-end SLAs, but this is done at the expense of an increase in price and complexity.
• For GxP systems, regression testing or backwards compatibility performed by providers can sometimes raise issues. The size of the provider does not seem to matter. Internal provider testing of product release versions/patches often time lacks quality. The question is, how do we work with vendor partners to provide that better quality?
• As best as possible, some of the pitfalls with VMS cloud applications should be avoided or mitigated earlier in the process. Currently, each client learns for themselves the functional, performance gaps and other shortcomings of the target software spending countless resources, time and budget remediating the identified gaps. Sometimes in large system implementation the gaps are only realized late in the implementation phase adding significantly to the cost. 
• Established provider contracts offer little to no relief from these issues. SLAs are usually not created as end-to-end for the various intra/interdependencies of systems. Request for information (RFI) early in the project engagement does not always work in uncovering the gaps. The same can be said for request for proposals (RFPs). Rarely, if ever, do providers list a section where all the gaps and mitigation measures are listed. Each client is left to figure the gaps & mitigations out independently.

 Some Possible Solutions/Advantages:

• Cloud hosted applications, in this context, appear to be supreme to what in-house teams can deliver. In cloud vendor hosted applications, new version releases and patches are the responsibility of the provider. Note the exception of (GxP) UAT, some regression testing and GxP documentation that follows a risk-based approach. This allows the software version critical changes to be tested as per the client’s business needs.
• There has been a push to use client “coalitions” with some cloud applications. This is not seen as a disadvantage but at times being able to discuss a particular business use with others seems to assist a business in making better decisions for their unique software implementation. These outcomes are generally viewed as a positive advantage and considered a good way forward. However, with coalitions the communication is not as thorough as when there is direct dealing with the client and software vendor. The software vendor loses the direct voice with the client. This direct line of communication to the software provider is essential especially when it comes to complex systems. Also, at times providers tend to not increase their staff to meet the needs of the clients in terms of response times.
• It would be beneficial to have the ability to speak with other clients using such coalitions who have already implemented the target software and noted the gaps that they had found with their corresponding resolutions. This would greatly help in identifying such issues and help mitigate them quickly and successfully. This would be done using the understanding that on large implementations each client may have their own specific business needs on how the software is used or configured.
• There seems to be a need to extend the early due diligence phase in order to properly assess the shortcomings of the target software as early as possible and where experience with the target systems needs to be gained quickly & efficiently.
• One strategy for dealing with version upgrades or patches released with bugs where the specific functions are deemed important by the business but are not working is to not stress, refuse the version release until the provider comes around with the corrected release and until its of acceptable quality. You trust that the vendor partner will come around and correct the business-critical identified bugs in a version/patch release in a timely fashion.

 Endnotes:

1. Vertical market software. (2019, January 21). Retrieved September 16, 2020, from https://en.wikipedia.org/wiki/Vertical_market_software
2. GxP. (2019, December 16). Retrieved September 16, 2020, from https://en.wikipedia.org/wiki/GxP
3. Digital Transformation of Pharma and Biotech. (2019, February 27). Retrieved September 16, 2020, from https://www.arcweb.com/blog/digital-transformation-pharma-biotech
4. Bayer, Pharmaceutics company. (n.d.). Retrieved September 16, 2020, from https://english.lokmat.com/topics/bayer/
5. Upgrade. (2020, May 29). Retrieved September 16, 2020, from https://en.wikipedia.org/wiki/Upgrade

 Appendix I:

Vertical Market Software is aimed at addressing the needs of any given business within a discernible vertical market (specific industry or market). While horizontal market software can be useful to a wide array of industries (such as word processors or spreadsheet programs), vertical market software is developed for and customized to a specific industry's needs.

Vertical market software is readily identifiable by the application specific graphical user interface which defines it.

GxP is a general abbreviation for the "good practice" quality guidelines and regulations. The 'x' stands for the particular field, whether that's manufacturing (GMP), distribution (GDP), laboratory (GLP), and so on.

Purpose:

The purpose of the GxP quality guidelines is to ensure a product is safe and meets its intended use. GxP guides quality manufacture in regulated industries including food, drugs, medical devices and cosmetics.

Definitions: SME – Subject Matter Expert; SLA – Service Level Agreement - SLA is a living agreement between client and provider; RFI – Request for Information; RFP – Request for Proposal; COTS Software – Commercial-of-the-Shelf Software; UAT – User Acceptance Testing

Version Upgrade - Upgrading is the process of replacing a product with a newer version of the same product.

Patches - A patch is a set of changes to a computer program or its supporting data designed to update, fix bugs or improve it.

Gaps - A scenario in which the system does NOT Fit a specific business requirement is known as a GAP.

 --

I would like to especially thank the following individuals who assisted me with ideas and feedback and more importantly moral support in in the creation of this article: Julius Kusserow (DE), Bjoern Wigger (DE), Jonathan Taylor (US), Patty Hegarty (US) and Chaten Patel (US)  

Aderito Campos has held various roles such as North America Head R&D IT Development, Solutions Manager and Senior Project/Program Manager at Bayer AG, a multinational pharmaceutical and life sciences company and one of the largest pharmaceutical companies in the world. He has over 21 years of experience in Information Technology within the following industries: Pharmaceutical & Hospital, Clinical Research Organization (CRO), Banking, Insurance, News & Publishing and NYC Government.