SNAPSHOT
Customer: BP Refineries (Originally California, currently United States operations)Industry: Global energy operatorRegion: United StatesUse cases: Laboratory Efficiency, Data Automation, Compliance
Background
BP is a global energy company headquartered in London with refining operations spanning nineteen facilities worldwide. The company's US refining operations produce a range of finished products including gasoline, jet fuel, diesel, and propane.
BP's initial BLISS implementation came after a four-year evaluation of available LIMS platforms at a California site. At the scale BP operates, a LIMS selection carries significant operational weight. The evaluation was thorough, and BLISS was selected. That decision has held across two decades of technology evolution, and BP's US refinery operations continue to run BLISS today.
The Problem
Before BLISS, BP's refinery laboratory operations ran off a remote mainframe that struggled under increasing network load. Performance degradation was a consistent problem, and the workaround created its own operational gap: the mainframe was taken offline every night at midnight for a three-hour maintenance window.
For a back-office system, a nightly outage is manageable. For a 24/7 refinery laboratory, it meant a recurring window where lab data was simply unavailable, to lab personnel and to everyone else in the facility who depended on it. There was no clean solution within the existing architecture.
What Changed in the Lab
The transition to BLISS was managed cooperatively between Datacor's (formerly Baytek) implementation consultants and BP personnel. The rollout completed without significant disruption, and user adoption followed quickly. BP saw immediate improvements in reliability, performance, data availability, and database maintenance.
Day-to-day, the refinery uses 80 to 90 percent of BLISS product features in regular operations. Scheduled sample logging, sample label printing, query building, and certificate of analysis completion are among the core functions the platform manages on a continuous basis. The lab gained a system that matched the operational demands of a high-throughput refinery environment.
What Changed Outside the Lab
The more significant operational shift was not what BLISS did inside the laboratory. It was what it made possible beyond it.
Refinery operations depend on a continuous flow of accurate laboratory data to function effectively. Process control groups and console operators need current results throughout every shift. Unit decisions, process adjustments, and product release determinations all have a laboratory data dependency. Before BLISS, getting that data to the right people at the right time required manual effort and introduced lag. After BLISS, it became a structured, reliable data flow.
Process engineers use the BLISS Excel Add-In to pull lab and process data directly into a shared workbook for daily analysis, eliminating the need to manually source and reconcile data from separate systems. Head operators and foremen gained direct access to lab results, supporting faster and better-informed decisions in unit operations. Tasks that previously required lab personnel involvement, such as sample label printing, became accessible to personnel in the field.
The result is a laboratory system that functions as operational infrastructure for the refinery, not a siloed data repository.
Lab Data as a Refinery-Wide Resource
This is the operational reality that defines mature BLISS implementations: the lab is a data source for the entire facility, and the value of a LIMS scales with how effectively that data reaches the people who need it.
At a petroleum refinery, the downstream consumers of laboratory data include process engineers running daily optimization analysis, console operators managing unit performance in real time, quality assurance teams tracking product specifications against release criteria, and compliance personnel maintaining documentation for regulatory reporting. Each of those functions depends on data that originates in the lab. A LIMS that delivers that data accurately, on time, and in a format each group can act on is not a lab tool. It is a facility-wide operational asset.
BLISS is built around that model. The platform's integration capabilities, including instrument connectivity through Instrument Pro, process data exchange, and external system interfaces, are designed to extend laboratory data beyond the lab walls and into the workflows where it drives decisions.
An Industry Leader Built for What Comes Next
BLISS LIMS has supported petroleum refining operations since 1985. Over that period it has adapted to successive shifts in refinery operations and laboratory technology, from networked data systems and automated instrumentation to expanding regulatory requirements under EPA and industry quality standards.
The next shift is already underway. AI-driven process optimization and predictive analytics depend on structured, contextualized operational data accumulated over time. A LIMS with decades of clean, integrated laboratory and process data is not a legacy system in that environment. It is the foundation that makes advanced analytics actionable.
BLISS LIMS is built to grow into that future the same way it has grown through every preceding technology transition: by maintaining a reliable, structured data layer that refinery operations can build on.
BP's experience illustrates what consistently defines BLISS implementations at scale: a platform that starts by solving a lab problem and ends up embedded in how the entire facility operates.
Deployment and Licensing Options
BLISS LIMS is available to refineries at any stage of their modernization path. On-premises deployment is available for organizations managing their own infrastructure, with licensing scaled to the size of the operation. Cloud-hosted deployment is available for organizations prioritizing reduced IT overhead and faster time to value.
Both options are supported by Datacor's implementation team and deliver the same core platform. The path to deployment depends on how your operation is structured, not on what the software can do.
