The Astrix Blog

Expert news and insights for scientific & technology professionals.

The Life Science Industry Blog for R&D Professionals

The Astrix Approach: Business Process Analysis

Posted on LIMS Implementation. February 17, 2018

As Intel’s CIO, Kim Stevenson, recently commented, “There are no IT projects, only business projects”. Given the increasing pressure that modern scientific organizations are facing to improve operational efficiency, reduce costs, enhance innovation and reduce compliance risk, it is critical for companies to ensure that laboratory informatics projects help to fulfill these important business goals.

Unfortunately, companies often fail to do the strategic planning necessary to ensure the success of laboratory informatics projects. Many organizations try to select and implement a system without first performing the due diligence required to align laboratory functional needs with the strategic needs of the business—an error that is magnified if more than one site is involved. Towards this end, the first step in any laboratory informatics project should always be a thorough workflow and business analysis.

Randy Hice, Managing Director at Astrix Technology Group, recently gave a webinar entitled “Ensuring the Success of Your Informatics Projects with Business Process Analysis.” In this blog, we will summarize the important points from this webinar, and expand on how your organization can align business processes, business goals, and technology to ensure your laboratory informatics project maximizes business value.

Astrix Business Process Analysis Overview

At Astrix, we apply Business Process Analysis (BPA) as the first step in our comprehensive and proven methodology (The Astrix Approach™) to ensure the success of laboratory informatics projects. A rigorous approach to Business Process Analysis has three main objectives:

Objective 1: Accurately capture current state environment – warts and all. Current state workflow diagrams reflect a snapshot of current reality, and will highlight exactly where the problems are occurring in current workflows.
Objective 2: Design future state with user buy-in to leverage the latest technology and functionality. Future state workflows reflect best-in-class technology and functionality and are designed to deliver process improvements. Users buy-in to the future state because they are consulted during the process and help to shape the To-Be workflows. This collaborative approach is critical to user adoption of the new system.
Objective 3: Extract precise requirements that reflect agreed upon improvements and focus vendor evaluations on those requirements. These future state requirements are utilized to drive vendor evaluations, vendor demo scripts, actual project plans, etc.

The Current State

Before setting foot onsite, Astrix BPA experts communicate with the customer’s management team to determine project scope, sites involved, customer project personnel and skill levels, management dedication/commitment, available budget, current systems and infrastructure, number of users, work groups and a precise site interview agenda.

Once onsite, our Business Analysts discuss the project at a high level with the customer’s management team to understand the goals, aspirations and objectives of the desired future state (i.e., strategic needs). This is followed up with interviews with bench-level analysts and supervisory personnel in different laboratory groups (e.g., incoming materials, in-process testing, final release, QC/QA, etc.) that ultimately lead to the production of current state (As-Is) Visio workflow diagrams.

When Astrix begins working with a customer, we will often be provided with workflow diagrams that lack the necessary detail. A good current state diagram will get into the details of the workflow – how samples are identified, how tests are associated with samples, how notifications work, etc. The As-Is workflow diagrams that are produced by the Astrix Team are at a level of detail to allow for process improvement analysis and meaningful requirements development.

Once complete, the current state (As-Is) process maps are utilized to identify workflow inefficiencies and wait states, and serve as the underpinnings of the future (To-Be) state and eventual system design. One example of a current state workflow that leads to process inefficiencies is what we call “ambush samples.” In this scenario, a sample is dropped onto a technician’s desk first thing in the morning with no advance notice. The technician is then forced to engage in all the activities required to process that sample – label the sample, glassware prep, equilibrate instruments, prepare mobile phases or reagents, etc. A good way to improve on this process is to design future state workflows so the users have advance warning of the work that is coming to them, so they can complete preparatory work ahead of time, and then hit the ground running in terms of analyzing the sample when it arrives, thus eliminating dead time.

The Future State

With the current state documented, and process inefficiencies identified, the Astrix Team goes to work creating the optimized future state (To-Be) workflows. By drawing on our experience working on hundreds of different implementation projects, and a comprehensive understanding of how today’s complex software systems have been deployed to great success, our expert professionals design the future state model for your company based on agreed-upon business needs. This design work is conducted off-site.

Future state models are then reviewed on-site with the customer team. Key customer personnel vet and affirm future state workflows to confirm that they reflect a viable design that addresses the problems that have been identified. Gone are the days when vendors deployed a system and expected a customer to conform to it. With Astrix’s unique methodology, only functionality with proven business benefits for you company is implemented.

In addition, Astrix’s methodology for BPA ensures that users buy-in to the future state. This is because users get to participate with management in a collaborative process resulting in an agreement that “this is how we are going to work.” Both users and management are engaged to make sure that the future state workflows lead to real process improvements, and that these new workflows support business goals. User buy-in helps to avoid the disaster scenario of a company spending the time and money to implement a new system that no one ends up using.

Future State Requirements

The collaborative agreement between users and management on the To-be workflows results in the creation of very specific requirements utilizing the Astrix Laboratory Requirements Database™. These requirements are tailored to the customer’s unique operating environment to a high degree of specificity and defined at a level that can be addressed through the new software.

System requirements become vendor requirements and are constrained to business/process improvements that stakeholders have already bought into. The requirements are precise enough to require any technology vendor to provide very specific answers in response to a Request for Proposal (RFP), as opposed to a cut and paste boilerplate responses. This process helps to prevent the customer from choosing a software product for the wrong reasons (i.e., bells and whistles). The BPA process also serves to tighten down the project budget – money is only spent on items that all stakeholders have agreed bring business benefit.

With an approved future state model in hand, project plan development time is greatly reduced, and prioritization of functionality rollout is laser-targeted. The continuum from initial As-Is analysis through system design is an approach unique to Astrix, and is designed to enhance the success of our customers.

Ensuring the Success of Your Project with BPA

One of the biggest mistakes that companies make during a laboratory informatics project is to skip Business Process Analysis (BPA) altogether and simply connect developers with users to configure current workflows into the new system. In this scenario, a huge opportunity to optimize work processes during the project is lost. If the main focus of your implementation methodology is to simply speed up inefficient work processes with a fancy new informatics system, then you just end up with faster bad work processes.

Vendor support teams also often neglect to perform a rigorous BPA and place much of the responsibility for the design and implementation of the system on the customer. Given that the customer usually is not aware of all the available functionality of the software, this approach can lead to improperly configured requirements while vendor developers churn through project development dollars.

The reality is that, with the complex workflows and technologies utilized in labs and the many different aspects of the enterprise that laboratory systems touch, success in laboratory informatics projects can be very difficult to achieve. In general, the bigger the project, the more problems can occur. Some of the common roadblocks to success in laboratory informatics projects that a rigorous process of business analysis can help to mitigate include:

Requirements not captured at the proper level – System requirements should be of assistance in system selection. If your requirements are of no use in differentiating one product from another, they have been developed at the wrong level.
Improperly configured requirements – The project team must contain developers who fully understand the capabilities of the system, along with company employees (users and management) who participate in the collaborative effort to generate system requirements at the right level. Agreed upon requirements that produce business value can then be communicated to the project managers, who design the implementation, and the developers who configure them into the system.
Faulty process for vendor selection – Companies often choose a system based on the flashiest demo or which system has the most bells and whistles. The ability to accurately capture system requirements is the only metric by which software applications and/or platforms should be judged. Additionally, a good system for evaluating vendor demos must be in place.
Targets not defined – Although very few organizations bother, companies should establish a baseline by precisely capturing the current state environment in terms of process time, sample turnaround, completed tests, released results, etc. This allows an accurate measurement of ROI for a project. From these captured metrics, the success of the future state can properly determined.
Overall business objectives are not understood or are too nebulous – Business objectives and goals must be clear and measurable in order to be able to validate project ROI and develop proper requirements.
Lack of management buy-in – When management has not bought into the project, you may hear comments like: “Why are we talking about implementing a LIMS? We’ve got this great ERP system already in place that our vendor claims can handle these kinds of things for the lab. If the ERP can satisfy the requirements, then great! We don’t have to buy another system.”
Internal resource (personnel) requirements underestimated – Both the necessary skill sets and an appropriate amount of resource hours must be made available for the project to be successful. Projects are rarely successful if project tasks are just added to existing workloads.
Insufficient financial resources devoted to the project – Laboratory informatics projects require a significant financial investment. Management buy-in must be sufficient to have earmarked an appropriate amount of funds for the project.
Unrealistic timelines – Companies often have unrealistic expectations about the timeframe for project completion. Often, vendors may promise aggressive time lines to win the business, and then manage missed expectations later.
Internal political issues – Unfortunately, NIH (Not Invented Here) syndrome is somewhat common in our experience. A neutral party that can apply an effective business process methodology is essential for project success. It is common that organizational political barriers are often greater than technical challenges. In many cases, an independent arbiter is essential to bridging organizational gaps.
Lack of user adoption – A major source of project failures is the lack of utilization of new systems in favor of reverting to pre-deployment systems and methodologies. This is a common artifact when users are not engaged in the project or requirements process.

These potential problems can be avoided by applying a comprehensive Business Process Analysis methodology that will result in a project with precise scope and cost.

Why Astrix

Since 1995, Astrix professionals have successfully applied best practices in the evaluation of work processes, functional and technical requirements, laboratory processes and informatics solution options for hundreds of clients and tens of thousands of scientists in a wide range of industries. Our professionals stay current on a wide range of informatics platforms and applications through vendor conferences and trainings, and by working on many different client projects.

Many companies have highly skilled business analysis, project managers and systems analysts, yet they still run into problems in informatics projects due to lack of familiarity with the full range of capacities that modern systems bring to the table. Our exposure to hundreds of customer initiatives and expertise with many different systems allows for an enhanced understanding of what might be possible.

Our experience and expertise allow us to work with a high degree of focus, efficiency and accuracy as we apply our BPA methodology to your project. For example, the future state models developed by Astrix Business Analysts off-site are typically require very little modification upon review – we usually see less than 10% changes to the future state models during the review process.

Other advantages that an external consultant can offer include:

Many of our consultants are globally recognized as the best in the industry, and are perceived as being unbiased by company employees, and are thus able to get honest answers in stakeholder interviews.
Our team offers a fresh and neutral perspective that can help to see problems more clearly and develop consensus amongst stakeholders about how best to move forward in terms of future state workflows. The most common feedback that we receive from BPA projects is, “We never knew we could do that.”
Because we are not involved in the day to day operations of a specific site, it is a little easier for us to develop the broad, big picture understanding of the organization that is necessary to harmonize workflows across a multi-site enterprise.

Conclusion

The benefits of Business Process Analysis include:

Saves project dollars
Focuses requirements on business needs
Engages users and leadership in the use of new systems
Serves as the underpinning for project design and planning

Whether you hire an external consultant or utilize internal resources, we encourage you to follow the process described in this article to identify technology requirements and select the technology platform(s) that you will implement. An effective Business Process Analysis conducted at the beginning of your project ensures that your laboratory workflows are optimized and that the technology that is implemented will bring business value to your organization.

About the Author

Randy Hice is recognized worldwide as a leading authority in laboratory informatics, specifically focused on complex, large-scale customers implementing Laboratory Information Management Systems (LIMS), Laboratory Information Systems (LIS), ELN, and sophisticated Cloud architectures.