Hitching a horse to your Ferrari: Binocs and the risks of retaining legacy systems

Planning and scheduling without a co-bot management system is hard. Before eventually choosing to update their lab planning software with Binocs, many labs spend months or even years investing in methods to make their existing manual processes more manageable. In this article, former implementation specialist, Adam Lester-George, uses some common examples to illustrate how accommodating a legacy system is often redundant when you’ve already upgraded to a more advanced platform everywhere else.

What is a legacy system?

In computing, a legacy system is a solution (software, hardware, etc.) that relies on outdated technologies but which nevertheless remains critical to day-to-day operations. When such solutions are first implemented, they are typically well-suited to the requirements and limitations of the day; however, as technology progresses and superior systems become available (even ubiquitous), the maintenance of the old approach becomes increasingly difficult to justify.

A common, non-computing example of a legacy application is the horse-drawn carriage. For millennia, horses represented the fastest and most manageable method when looking to convey people and goods overland. Despite the rise of the locomotive in the Nineteenth Century, the global horse population continued to grow until, by the end of WWI, there was one horse for every five humans in the USA. By the late 1920s, however, a new dominant paradigm for transportation had already taken hold, with refinements in the design of the internal combustion engine making automobiles and tractors an increasingly accessible alternative to beasts of burden. Today, the population of horses in America has dropped to 1 for every 35 humans (compared with around 30 motor vehicles per 35 humans).

Backward compatibility

The man heralded as probably the most responsible for this paradigm shift, Henry Ford, is often misquoted as having said, “if I had asked people what they wanted, they would have said faster horses”. While the story is apocryphal, many people were indeed highly skeptical of the utility and durability of the first generation of automobiles. Rather than requesting faster horses, they may simply have asked car designers to make accommodations for horse harnesses so that the vehicles could be driven in the “traditional” manner.

Such a request is an example of “backward compatibility”, a feature of a new technology that allows for interoperability with a legacy system. These features are often required when the new paradigm has yet to reach a state of ubiquity and when user experiences remain rooted in the older ecosystem. We can still see vestiges of this in the anachronistic language adopted for early motor vehicles and which remains in use today: for instance, we still talk about car engines in terms of “horsepower”, people still refer to “riding shotgun”, and motorcycle seats are commonly referred to as “saddles”.

Why are legacy applications still used in pharmaceutical labs?

An industry in which old paradigms are frequently still used is software development.  Developers are often required to implement backward compatibility in their products to accommodate legacy systems that users are otherwise unable or unwilling to relinquish. There are many reasons that this might be the case and, although the following examples are specific to computing, the same general principles apply in other fields:

Downtime anxiety

Many legacy systems are fully embedded in a client’s business model and may be mission-critical. For some, the very idea of replacing such an essential component may simply be inconceivable for fear of the potential damage that could result from any necessary downtime and short-term productivity impacts.

Expertise scarcity

Organizations often lack the technical specifications and expertise to migrate an old system or to create a new system with the required features. Frequently, the person responsible for establishing the legacy technology has moved on, while subsequent modifications and patches have been implemented by various individuals over the system’s lifespan in a piecemeal fashion without comprehensive documentation. This can lead to a scenario in which the technical skills required to oversee a complete system replacement simply do not exist in-house.

Change management

Even when a legacy technology has objectively outlived its utility, it can still be challenging to justify a wholesale replacement to the system’s end-users. They may have dedicated a lot of training time to understand the system architecture, with yet further time invested in learning how to navigate its anachronisms. After being recognized as an expert in the old system, existing users might demonstrate significant resistance to adopting a superior alternative with which they will suddenly find themselves a newbie.

Sunk-cost fallacy

In addition to training users, deploying an IT system is itself an expensive exercise and this investment in an old technology may take years to recoup. Often, however, so much additional time and money have been sunk into patching and maintaining an old system that the historical investment alone becomes the reason to continue using it.

Legacy solutions for laboratory planning and scheduling

Before choosing to implement Binocs, pharmaceutical labs have typically already implemented several methodologies and practices to overcome everyday resource management problems. Such problems commonly arise due to the complexity of planning and scheduling work with increasingly complex methods across multidisciplinary teams and shared resources.

Such solutions make a lot of sense in the context of manual planning and scheduling; however, fast forward to the point when an advanced co-bot solution like Binocs is implemented and an important question must be asked: is there still value in retaining this legacy system when the original rationale for doing so (i.e., manual planning) no longer exists?

Structural reorganization

It is natural for lab planners to seek ways to “chunk” their work into manageable components as the technical responsibilities begin to exceed what one person can realistically deliver manually. For instance, a life sciences lab might opt to restructure their workforce into numerous smaller teams so that the work of organizing staff and tasks can be delegated to multiple planners, each with fewer responsibilities – after all, a problem shared is a problem halved!

Indeed, one of our clients recently encountered this exact scenario. They had invested significant time and effort into reorganizing their lab to accommodate the restrictions of manual planning and, upon first implementing Binocs, were reluctant to reverse this change. The Binocs system is flexible and was readily able to accommodate five different teams in one lab, with staff members and equipment shared between the teams; however, this ultimately reduced efficiency by introducing unnecessary layers of additional complexity to the planner’s list of considerations.

They soon realized that the most effective course of action was to revert to a single-team dynamic with a single planner responsible for the entire lab, supported by the Binocs co-bot. In this way, the workload reduced from five planners each spending 4 hours a week scheduling work manually, to five planners spending 1 hour a week scheduling with Binocs, to just one planner spending 1-2 hours weekly scheduling everything for the entire lab once the legacy system (i.e., the lab reorganization) had been reversed.

Highly Complex Bespoke Excel Spreadsheets

It is common for individual client sites to develop their own in-house solutions to some of their resource management challenges, often created and maintained by a single manager. Initially, these solutions start as a simple data-logging exercise but, before long (and with the addition of increasingly specific rules and formulas), it evolves into a Highly Complex Bespoke Excel Spreadsheet (HCBES).

One example of an HCBES is an Excel-based system that allocates custom ID codes to samples downloaded from a third-party sample management system to facilitate sample grouping for batch testing. Using a host of cascading, advanced formulas, some custom macro programming (VBA), and repeated tinkering, a Capacity Manager might be able to develop a sophisticated workbook that imports a LIMS extract and processes the sample information into plannable batches.

In the absence of a resource management system, this sort of HCBES represents a valuable solution to a complex problem; nevertheless, complications rapidly arise. A sample might be lost or need retesting, or testing materials might fail to be delivered and testing patterns must then be rapidly reorganized. Despite the use of advanced formulas, most of the processing required to dynamically re-campaign samples remains in the planner’s brain, while the solution itself remains specific to the lab/site in question, with limited transferability to other company locations. Furthermore, if the solution owner is absent or leaves the lab entirely, the expertise is immediately lost.

When a Manager is invested in an HCBES, they might request that any Binocs implementation be adapted to work with the outputs of their custom tool. Again, the system is flexible enough to accommodate this, however, with features such as the Campaign Manager and zero-code interfacing already present in the native system and fully integrated with the Scheduling co-bot, the additional time and effort required to make this adaptation quickly become difficult to justify.

Rhythm Wheels – Lean Production Methodology

The Rhythm Wheel is a lean production methodology that was introduced several years ago as a framework to help manage resource planning with a relatively simple premise: assume you have a stable and predictable supply chain and then impose a short term planning cycle upon your workload, segmented by daily tasks for specific roles. Then work backward to adjust your practices into Standard Work that fits this stable pattern in a repeatable sequence.

Because of the short time horizon (5-10 days), Rhythm Wheels permit a more consumption-based model that “pulls” demand based on need, rather than “pushing” it based on resource availability. This can result in greater reliability for both the planner and the customer and reduce inventory requirements and wastage.

While labs have adopted this method, it was originally developed for traditional manufacturing supply chains and, by design, it reduces planning flexibility by imposing a set structure in advance with little-to-no room for deviation. This makes it less-than-ideal for all but the most predictable of lab schedules (for example, environmental monitoring).

When things do run smoothly, the consumption-based “pull” approach risks resource underutilization as it doesn’t include any form of capacity forecasting. In reality, however, the lab environment rarely runs smoothly and minor changes to the conditions can significantly disrupt the entire Rhythm Wheel system. This requires in-house expertise to manually recalibrate, reorganize and reapply the model as exceptions and other unexpected events (such as unplanned leave) interfere with the rigidly-planned schedule. While the recalculations are being performed, the lack of flexibility means that upstream delays can leave staff with assigned roles no work to complete.

Nevertheless, clients do sometimes ask us to adapt elements on the Binocs system to accommodate their legacy Rhythm Wheel solution. The complication with doing so rests in the fact that both approaches have been developed to solve the same problem, except one is significantly more advanced and efficient than the other.

Binocs is a lean solution that comes out of the box fully equipped for Standard Work, with flexibly sequenced activities matched to individual team member competencies (allowing for a responsive approach to work assignments), as well as dynamic scheduling with real-time recalculations. As such, adapting the system to integrate with a Rhythm Wheel approach can feel akin to building a Rube Goldberg machine that is initiated by lighting a candle, only for a series of steps to result in the illumination of an electric light!

Or, to put it another way, it’s a bit like hitching a horse to a Ferrari.

Making compromises

Sometimes, it is actually necessary to implement a temporary system adaptation to integrate with a legacy system.

In the period 1900-18, the island of Nantucket, Massachusetts was the only place in the US to resist the introduction of the automobile. When, in 1913, Clinton S. Folger was awarded the federal contract to deliver the mail across the island, he arrived in a brand new Overland Model 69 Touring car (arguably the Ferrari Purosangue of its day) and was immediately met with legal resistance from the local authorities. Over the next half-decade, he continued to defy the island’s automobile ban and actively campaigned for it to be lifted.

The above photograph features Folger as he demonstrates his innovation, the “Horsemobile”, which he paraded around the small town of Siasconset to the delight of locals and photographers. The image was soon reprinted in newspapers across the USA, leading to a nationwide letter-writing campaign supporting his pro-car stance. Soon thereafter, the island’s voters finally elected to repeal the ban.

At bluecrux, we know that it’s sometimes necessary to make compromises before a new approach can be fully adopted. That’s why our dedicated team of specialists is ready to work with you to identify a native Binocs solution that provides the perfect alternative to your legacy way of working – be it a Rhythm Wheel, team splitting or Highly Complex Bespoke Excel Spreadsheets – while still taking advantage of the full range of benefits that our co-bot system offers.

Why not request a system demo today and discuss commissioning a Proof of Concept to exhibit precisely how Binocs can work for you?

About the Author

Adam Lester-George

Adam has two decades of experience working in clinical trials, biomedical research, public health, and health economics, with a particular interest in the intersection between technology and life sciences. For 7 years before joining Bluecrux in 2019, Adam was the director of healthcare innovation consultancy “LeLan” and brings a wide range of insights to his role as Content Specialist for Binocs.