How We Plan Technician Capacity for Release Testing (Using the Binocs API)
Pharmaceutical products need to be analyzed quickly, accurately and in a timely manner before they are released and distributed to the commercial marketplace (= release testing).
Timely is the key word. If releases are slowed down, money is lost. Lab supervisors, responsible for the analyses, want to know whether they will be able to cope with the workload the release testing will bring, so they can to proactively act on capacity problems far before they cause last-minute staffing changes, extra shifts, hiring of interim workers – or worst of all, delivering late. Binocs can help.
For this, Binocs needs the QC samples demanded of each lab team. In other words, we want to translate the commercial forecast into QC samples – of course, whilst avoiding manual input, especially if a part of the input is already in other systems.
So we developed a Binocs Excel add-on, which is used by some of our QC lab clients.
The known input
The ERP system contains production plans for each product indicating the number of batches that will be produced in the coming months. An extract is entered into the Excel add-on.
Most supply-chain plans are expressed in volume units (e.g. doses), and not in lots or batches, so an automatic conversion takes place in the tool. We use two conversion techniques:
- For “runners” (high volume products) we use historical data.
- For “strangers” (ad hoc production, low volumes) we use specific calculation rules.
Inspection plans provide details about what tests need to be performed in order to ensure the quality of the product. The test plans are managed in the Excel add-on.
The quantity coefficient isn’t always a whole number. This is a mechanism to correctly sequence frequency tests.
Some extra info is known about the identifiers, such as the aggregated product name (= product family). This extra info is also kept in the Excel add-on.
The add-on calculates and creates testing demand in Binocs by combining the production plan (in batches) and the inspection plans. The result is that all work created by the release testing is nicely structured in Binocs without manual input. The extra info is also used to structure and tag the created demand in Binocs automatically.
Now analyses can be run on the demand to find out whether potential capacity collisions will occur (= late demand). Because the demand was automatically tagged with the product names, filtering in the reports becomes a piece of cake.
This is only one example of a Binocs add-on, but we’ve built several more. They all make use of our API (application programming interface) which makes it possible to upload and download everything to/from Binocs. The most important take-away: You’ll never have to input data twice if it’s available somewhere else.
We would be happy to explain this in more depth and answer any questions. Please don’t hesitate to contact us!