One of my favorite quotes is from Peter Senge of MIT's Sloan School of Management. Senge says, "The only sustainable competitive advantage is an organization's ability to learn faster than the competition." When it comes to technology, we often measure our performance on the suite of products we implement.
However, in the Life Sciences space, companies largely share the same set of business requirements and pick from the same small software solutions pool.
We like to talk about innovation and creativity, but our enterprise architectures are ultimately more similar than different. We should be judged on our ability to make smart decisions, quickly respond to shifting business conditions, and the ability to execute. As IT professionals, our sustainable competitive advantage is how we communicate, plan, and execute.
We are fortunate to live in a time when access to enterprise technology is a phone call away. It wasn't always that way. Before 'Software as a Service' matured and became a viable business alternative, implementing software was a slow, costly and arduous process includingVendor visits for software demonstrations
- Purchasing and commissioning of hardware
* In duplicate for high availability/failover - Vendor onsite installation, configuration, and training
- Setup of backups
- Installation of client software on desktop
- Annual disaster recovery testing
- Periodic patching and application upgrades
- End of life operating systems
- Hardware replacement
Too often, back then, the process of software implementation was largely a technical exercise with insufficient engagement of the end-users or regard for their business requirements.
Today, however, the pendulum has swung in the other direction. Each morning, software vendors fill our inboxes with offers, calls to action, and cautionary tales:
- Are bad bots wreaking havoc on your websites?
- Gain Control of Your GxP Documents
- Get the world's most powerful LIMS up and running in 30 days...
- Send Invoices Instantly. Start Getting Paid.
No wonder I hit the snooze button. A click, a phone call, and a credit card later, and you are off to the races. I'd bet you'll be entitled to a special discount if you sign before quarter-end. And if you play your cards right, you might even gain access to several optional modules that you'll never need, for 50 cents on the dollar!
Poof, you are now the proud owner of a brand new hosted software system. Yes, we have unprecedented access to fantastic technology in record time, but it's a double-edged sword.
The most successful technology projects are those with adequate representation from the end-users, IT, and all the supporting stakeholders along the way like quality, compliance, finance, legal, and procurement.
Unfortunately, particularly for young, emerging companies, these capabilities may not yet be in place. Business units do the best they can without the experience and expertise of these supporting teams.
Without this broader perspective, there is a singular focus on functionality and inadequate consideration of:
- Protection of data
- Compliance with regulatory requirements
- Business continuity - does the application support high availability
- Support - how does the vendor support the application?
- Scalability - will the system scale with evolving requirements and more users
- Integration - Does the system require or supply data to another system?
- Have we negotiated favorable financial terms?
- Do our contracts protect the company and its information assets?
- Do we have procedures for creating and removing accounts?
- Have we applied the principle of least permission?
When software is allowed to grow without regard for the larger picture, we assume business risk, compliance risk, inefficiencies, and frustration. I am often called in to restore some order to the technology environment.
When I step into a situation like this, the priority is to establish the 'as-is,' giving form and function to the previously murky and diffuse web of technologies.
There is no shortage of processes, frameworks, and standards focused on various dimensions of information technology, enterprise architecture, security, project management, compliance, IT service, and DevOps, to mention a few.
I try to capture the minimal set of high-value data to understand the current environment and look for high-risk gaps requiring immediate attention.
In the rest of this post, I am going to walk you through the process I follow.
Pass One – Define the As-Is
Communication
This activity is an unfamiliar one to much of the organization. Reactions to this initiative are varied. Some see the value and are excited, others are suspicious and may feel threatened, and some are ambivalent and see this as another bureaucratic exercise. Communication and setting expectations can set you up for success.
Typically, the project sponsor sends out a high-level communication to department heads kicking off the project, describing the objectives and granting authority to the project team.
Next, I send out more detailed communication to individuals in advance of our meeting. This communication reinforces the objectives and is intended to get them thinking and prepared for the meeting.
How to best proceed from here really requires you to use your 'spidey sense.' Everyone is different. Try to cultivate the environment that best suits the particular user group; make them feel comfortable and be flexible. Some teams forward you a spreadsheet, providing information in excruciating detail. Others need an extended meeting to walk through each process, system, and risk painstakingly.
I find with some that they appreciate a short initial discussion with a series of longer follows the meeting, each time including members of sub-functions. You've got to fish where the fish are, so listen carefully and follow where the users take you.
Identify the Stakeholders
It may seem simple enough, but it can be tricky, especially for small and emerging companies. Org charts are like flashlights; you could have sworn there was one around, but no one can seem to find it during a power outage. Sometimes you have to get creative.
Start with the CEO's direct reports and work your way down into the organization. Look at Outlook in the global address book (or the non-Microsoft equivalent), where perhaps an enterprising IT technician will add reporting structures information. Other resources to help you piece together an org chart may be office managers, operations team, purchasing, or support staff.
Startups and emerging companies may use service providers, consultants, and temporary staff to support business processes that do not demand full-time resources. These folks are not onboarded traditionally and aren't always as culturally connected as permanent staff to require some digging. I see this most commonly in general and administrative functions, like HR, finance, legal, and IT. But it may also exist for business needs on the horizon, like regulatory, quality, and commercial.
List the Key Business Functions
Cast a wide net. Particularly for emerging companies, individuals are very busy building out their respective functions and may have little awareness of the functions and systems. When I begin, I may start with eight or nine individuals, but it is not uncommon to surface additional business functions and processes that require conversations.
Lead with the business processes. When I first started doing this, the left-most column in my spreadsheet was 'System.' Spoken like a true IT professional! This is a problem. First, it leads to blind spots.
Suppose I were to ask for a list of systems. In that case, I am not going to hear about the performance reviews or training matrix stored in a network drive or the hazardous waste inventory kept in Microsoft Word or the Production Planning tracked in Excel. Leading with the process will highlight the opportunities for automation and integration as the company grows.
Over the lifecycle of a business, business functions' details will evolve, and new ones emerge, but the functions themselves are relatively constant. The underlying systems: those will almost certainly change. Take, for instance, the accounting function.
A common progression is:
System transitions are triggered by changing business objectives, growing headcount, new opportunities, threats, or regulatory requirements. The business function remains constant, but the underlying systems are variable.
As you lay the groundwork for a roadmap, it's best to lead with the business process. Always remember, the technology follows the process, not the other way around. There may be instances where that is not the case, but that is a subject for another post.
Note the Technology and Supporting Tools
Now that you have a list of the key business processes capture the tools used to execute those business processes. Sometimes it is a sophisticated piece of software, but it may be a spreadsheet or even paper.
When companies are just starting, perhaps their SOPs are on paper with wet signatures, and training records are tracked in a spreadsheet. It is important that this data be captured, as it helps identify risks and opportunities, and it drives the beginnings of a technology roadmap.
It's also important to consider the life cycle of data. Think broadly. We tend to focus on the processing steps but be sure to consider how the data is stored before, during, and after processing.
For instance, lab data, sample data may start in an electronic lab notebook, get processed in an instrument, and analysis may be output to a file repository or warehouse.
Consider how data is transformed as it makes its way through the organization. In the world of process improvement, there is the concept of SIPOC:
Supplier -> Input -> Process -> Output->Customer
The idea is that all processes rely on suppliers who provide input (e.g., information, requests, materials, instructions, resources) and turn those inputs into outputs (e.g., samples, analysis, reagents, invoices, product, a service) for their customers. I like to apply that mental model to information and technology that flows through the organization. Consider an assay development group.
Their inputs may include:
- Work request from manufacturing
- Reagents and materials from lab operations
- Testing material from manufacturing
- SOPs from QA
Their outputs may include:
- Records for QC to review
- Data for manufacturing
- Material for testing for analytical lab
A simplified example, but you get the concept.
Account for Data Sensitivity
A priority for business leaders today is cybersecurity, compliance, and protection of intellectual property. Understanding what data resides where is an important step in establishing a data protection program.
Once you have established the location and sensitivity of corporate data, you can determine if appropriate protections and controls are in place. Certainly, the identification of relevant regulatory requirements is critical.
Depending on the type, location, and activities of your business, they may include:
- 21 CFR Part 11
- cGxPs
- HIPAA
- Sarbanes Oxley
- Sunshine Act
- GDPR
- CCPA
- 201 CMR 17
As an organization grows, a logical next step would be a formal data classification framework. Data classification is a way to organize data based on the level of sensitivity. It creates guidelines for how data, at each level, is treated at rest, in transit, while being processed, in paper and/or electronic form.
Map Out Access and Permissions
Small companies without central IT departments have distributed administration of systems. This results in inconsistent practices around granting and revoking user access. Failure to promptly terminate the account of a departed employee or contractor is a common audit finding. It represents a security risk as an individual who may have moved onto a new competing company continues to access proprietary data.
Stale accounts may also be a takeover target for malicious actors. From a financial perspective, we don't want to pay for accounts we no longer need. With centralized administration, there tends to be a more rigorous approach and more consistent practices.
During this pass, I like to understand:
- Who can add and remove users?
- Who can make changes to the system configuration?
- Who is granted access?
- Everyone?
- Employees only?
- Consultants and contractors?
- Members of a particular department?
- Is access periodically audited?
Investigate Business Continuity
For hosted applications, we often make assumptions about business continuity. I like to capture:
- Does the system support high availability?
- Will the application withstand a regional disaster?
- How frequently is the data backed up?
- Is the backup stored offsite?
- How long are they retained?
Plan for Regulatory Compliance
Just because we do not operate or maintain a hosted system, we are still accountable for compliance with regulatory requirements.
For hosted applications, this is achieved through the audit as well as inclusion of contractual provisions. This should be noted, particularly for systems that house sensitive data.This is a good starting point and helps to prioritize efforts to ensure security and compliance.
Pass Two – Find the Problems
The objective of the second pass is twofold:
- Identify high-risk gaps that require immediate attention
- Surface immediate and short-term opportunities to improve quality, efficiency, or productivity
Now that you have a good picture of them as-is, ask the question: where are the problems?
Taiichi Ohno, the father of Toyota Production System once said, "Having no problems is the biggest problem of all." Given the time it takes to identify, procure, and implement technology, it will almost always lag current business needs. I do not expect you'll find a shortage of problems, particularly with the rate at which startup and emerging companies grow.
I look for problems or, euphemistically, opportunities in the context of the buckets outlined in pass one:
Technology and Supporting Tools
- Does the technology meet the business need?
- Are there opportunities to improve?
- Does the system comply with relevant regulatory requirements?
- Is the technology reliable?
- How is the vendor relationship?
- Are there opportunities to integrate?
- Are there opportunities to expand system use outside the department?
- Does the technology overlap with other technologies within the organization?
Sensitivity of Data
- What are the relevant regulatory requirements?
- Is the data treated appropriately?
- At rest?
- In transit?
- In paper?
- Backup?
- Retention policies?
Access and Permission
- Do the appropriate individuals have access to the system?
- Do individuals only have access to data/functions required to perform their job?
- Is access approved by a system owner?
- Is access periodically reviewed?
- Is user access promptly removed when an individual changes role or leaves the company?
These are just a sampling of questions to start the conversation. Who knows where the discussion will lead? Turn over every stone and question everything. The answers will form the basis of a set of opportunities.
Will these opportunities be approved for execution? That is a decision for the organization to make. It is their responsibility to evaluate the risk, cost, and value. Your job is to raise the opportunities and provide data to aid in their decision.
Pass Three – Build the Roadmap
Now it's time to look to the future. What will the business look like in one year, three years, five years! How will the business evolve, and when?
Start with your current set of business functions and associated supporting tools and technologies. I then add columns to represent the approaching three to five years, broken into quarters or six-month increments.
Challenge the team to consider when they outgrow their current solution and the triggering event? When small companies are in 'build mode' functional units tend to focus inward and on immediate needs.
Consider business functions that do not yet exist. The picture here may not be so clear, but it's good to begin penciling in these capabilities.
All of the new or evolving business functions are triggered by some event.
The list of triggering events might include:
- Commercialization of a product
- Major regulatory submission
- Commissioning of a new site
- Growing headcount
- New compliance requirement
I list out each new system on the roadmap and associate it with a triggering event. That way, as these events inevitably move on the schedule, the associated projects move with them. I also map the required 'go live' date and account for system selection and implementation.
Imagine the business requires a system for product complaints, and it needs to up and running to support a product scheduled to be launched in 24 months. Stick a milestone, "Product Complaint System Live" on your roadmap for 24 months from now.
Now start counting backward:
So while the application doesn't need to go live for two years, you'll want to get started in about six months to be ready.
Final Thoughts
This is what has worked for me. Frameworks are a great starting point, but use your experience and instincts to shape them. Focus on the high-value, high-risk areas. The purpose of the exercise is to create actionable intelligence to mitigate risks and pursue activities.
It's always fun to compare the initial description of the technology to the final inventory. It's always far more complicated than anyone expected. But, if it opens some eyes and makes the whole exercise worth it.
About Gene Lichtman
Gene Lichtman is a technology executive with over 2 decades of experience in the life science space, planning, designing, and implementing IT solutions targeted at achieving business objectives. Gene has served in IT leadership roles at Millennium Pharmaceuticals, Dyax, Harvard Clinical Research Institute/Baim Institute for Clinical Research, and Synlogic. Gene is currently a Principal Consultant at Village and Court, an IT consulting firm providing fractional CIO services to startup and emerging companies.