Stefan Duvall

Areas of practice

The technology questions I have learnt to make more precise

01

Preserving a record's interpretive context

My starting point is the person who must understand the record after its original system has changed. I ask what that reader needs in addition to the visible result: method version, related material, change history and a usable route through the material. Technical recovery work then has a purpose against which it can be examined. In our fourteen instrument-system exercises, successful backup reports did not establish that all fourteen packages were interpretable after restoration. Three lacked necessary method context. I helped define the dependency and fund the improvement, while quality colleagues assessed the record's suitability for its intended use. This is not a promise that one checklist resolves every kind of record. The questions must follow the actual process and the relevant specialists, and the evidence must remain available when a test exposes a limitation.

02

Changing an application without borrowing quality authority

A pharmaceutical technology programme involves responsibilities that should remain distinguishable even when the team works closely together. I can recommend a configuration, a controlled release sequence or a support arrangement. I cannot make a quality judgement valid by delivering the application that carries it. In an electronic batch-record rehearsal, six records preserved their changes but did not capture adequate reasons. I supported an eight-week delay while the workflow was corrected and quality colleagues determined the further examination required. We did not fill the missing explanations with plausible retrospective text. My expertise is in making the technical condition and the unresolved question explicit, assigning the right owners and presenting the cost of the proposed route. It is also in recognising when a programme's appearance of readiness exceeds the decision authority of the person presenting it.

03

Testing the consequences of a supplier release

Release notes describe what a supplier has changed; they do not fully describe the effect on a manufacturer's configured working environment. I work with users and quality specialists to agree meaningful scenarios before acceptance work begins. In one release review, eighteen of 180 scenarios failed: eleven concerned mapping displays and seven concerned permission boundaries. The failures were found on controlled copies, and we deferred production introduction for six weeks. I would not call the remaining 162 passing scenarios proof that every possible use was safe. They were evidence against an agreed scope. A useful acceptance recommendation keeps that scope, the exceptions and the cost of continued support visible. It also identifies who can decide whether the outstanding conditions have been adequately addressed, instead of leaving the supplier or the technology team to infer collective consent.

04

Treating specialist review as a finite resource

Technology portfolios compete for more than capital and engineering time. A proposed change may need laboratory, manufacturing and quality specialists whose continuing responsibilities do not disappear when a project is funded. I therefore ask sponsors to identify those people, the work they must perform and the decisions that require their attention. Our EUR24 million 2026 change allocation includes instrument-record stewardship, enterprise renewal, access and continuity, and contingency. I deferred a separate EUR4.2 million analytics proposal because the relevant review capacity was unavailable alongside that programme. The decision did not establish that analytics lacked value. It established that the current delivery proposition depended on capacity we could not credibly promise. I can help an investment committee distinguish a desirable idea from an executable proposal while keeping a future route open for the idea itself.

How I lead

A record should remain understandable after the people, software and instruments that produced it have changed.

At scale

The responsibility, in figures

144

Technology employees

Six direct reports; forty-two contractors separately

EUR68m

2026 technology authority

EUR44m operations and EUR24m change

32 years

Manufacturing systems career

Analysis, plant informatics, laboratory and enterprise leadership

In practice

Decisions and their consequences

Case I

Fourteen successful backups, three incomplete restorations of context

In October 2024 we examined restoration capability for fourteen instrument-system test packages. Every relevant backup job had reported success. The programme team initially proposed using that result as evidence that the recovery arrangement was ready. Laboratory colleagues asked a more useful question: could an authorised reviewer understand the restored material with the method version and associated context intact? Eleven packages met the agreed exercise criteria. Three did not supply the necessary method-version context through the restored environment. These were controlled exercises, not reports that production records had been destroyed or that medicines had been affected.

The immediate choice was between closing the exercise on the strength of the backup reports or continuing the work with a narrower account of what had been demonstrated. I recommended the latter. I asked the team to preserve the original sources and document precisely what the three exercises could not reproduce. Quality colleagues retained responsibility for assessing suitability and the further examination required. My responsibility was to provide a technical route, its dependencies and a realistic cost. We agreed a EUR1.4 million capability programme over twelve weeks, including the relevant configuration context and repeat exercises.

That programme cost more than the original completion recommendation implied, and it consumed specialist time already requested elsewhere. I took both consequences to the investment discussion. I also refused to describe the eleven passing packages as evidence about every instrument system. They established a result for those exercises and their agreed conditions. Broader coverage needed its own selection and review.

By the end of the twelve-week work, the three packages could be read with the required method context in the exercise environment, and quality colleagues reviewed that evidence. We retained the exercise record and the original limitation in the programme account. I do not present that as a universal recovery assurance or a regulatory certification. The useful change was that our readiness discussion now distinguished a completed backup job from a demonstrated ability to interpret the recovered material. That distinction has continued to shape the questions I ask before supporting a closure recommendation.

I would ask record users to define a meaningful restoration before the first backup exercise, including the context they need to interpret recovered material without reconstructing its history.

Case II

An eight-week pause for reasons that had not been captured

Our March 2025 electronic batch-record rehearsal covered thirty representative test records before a wider rollout. Twenty-four retained the expected change history and adequate recorded reasons. Six retained the sequence of changes but did not capture sufficient reasons through the proposed workflow. The data had not simply vanished; the weakness was in the explanation available to a later reviewer. Quality colleagues identified the significance of that distinction. I could describe the application behaviour, but I could not decide that the missing explanations were immaterial.

The release calendar created pressure to treat the six as training matters that could be resolved after introduction. I recommended holding the rollout. The alternative would have placed the burden on users and reviewers while leaving the capture mechanism unchanged. We accepted eight additional weeks on the existing arrangement at EUR620,000, including continued support and the planned transition team's extended work. That amount was an actual cost of our chosen delay, not a theoretical loss avoided or a claim about the value of a product batch.

I assigned the technology team to correct the workflow and make its behaviour observable in further rehearsal. Celiane Vaumery's quality organisation determined the examination and acceptance needed for the records and process. We kept the deficient rehearsal examples available. Nobody was asked to invent a plausible explanation for an earlier change simply to make the evidence look complete. Where further clarification was possible, its source and timing needed to remain distinguishable from the original entry.

The subsequent rehearsal supplied adequate reasons through the corrected route against the agreed scenarios, enabling the relevant owners to consider the rollout again. That did not prove that every future user would always make a sufficient entry. Training, oversight and investigation remained continuing responsibilities. My account to directors therefore included the delay, its cost and the remaining operating dependence. I regard this as an example of technology leadership because I took responsibility for a technical weakness without absorbing the quality decision or converting a successful rehearsal into a broader assurance than it could support.

Looking back, I would examine how reasons for changes are captured during initial workflow design, before a later review reveals that a technically complete record cannot explain itself.

Case III

A supplier release held at eighteen failed workflow scenarios

A planned laboratory application release in September 2025 arrived with a supplier schedule that favoured a prompt move to the new version. Before accepting that schedule, our laboratory, technology and quality colleagues agreed 180 workflow scenarios for the configured environment. Tests used controlled copies. Of those scenarios, 162 passed and eighteen failed: eleven showed mapping-display discrepancies and seven exposed permission boundaries that did not match the agreed use. There was no claim that an actual product decision or patient had been affected by these tests.

The supplier offered to proceed with temporary instructions for users while corrections followed. That approach would have transferred part of the burden from a known technical issue to the people conducting and reviewing work. I recommended a six-week deferral and continued support for the current version. Parallel support cost EUR780,000 over that period. I took the cost to the executive discussion rather than describe it as a supplier problem with no consequence for our own budget.

We divided the unresolved work by the decision it required. Technology colleagues reproduced and documented the behaviour; laboratory specialists explained the intended use; quality colleagues determined the evidence needed for acceptance. The eleven display discrepancies and seven permission failures remained separately visible. A correction to the first group could not be used to close the second. I also asked that the 162 passing results stay attached to their scenarios and test conditions, rather than become a general percentage of application safety.

Following the corrections, the eighteen scenarios were repeated, and the relevant surrounding checks were examined before the responsible owners agreed the next release step. The report preserved the original failures and the cost of the changed schedule. We did not infer universal suitability from that exercise or claim a measurable improvement in medicine quality. The decision's value was more specific: the business did not have to accept a supplier timetable as a substitute for its own evidence about the configured environment. I learnt again that commercial support pressure belongs in the decision, but should not quietly determine the acceptance standard.

I would agree the configured workflow scenarios before the supplier’s release window approaches, preserving time to examine failures without the renewal calendar dominating the discussion.

Case IV

Keeping the old reader after an archive sample challenged retirement

In January 2026 a decommissioning proposal included an estimated EUR180,000 annual saving from retiring an older laboratory reader and its support. Before approving it, we examined 1,200 sampled historical packages. A total of 1,056 were fully readable through the proposed replacement route; 144 required the older reader to supply the needed interpretation. The sample was selected to explore different periods and configurations. It was not a statistically representative estimate of the whole archive, and I did not multiply its result into a company-wide failure count.

The immediate choice was whether to retire the older capability on schedule or retain a controlled means of retrieval while developing a better-supported route. I recommended a segregated reader and support arrangement costing EUR430,000 for the defined retention programme. The proposal included access restrictions, named support ownership and periodic retrieval exercises. It was more expensive than the first retirement paper, and it postponed the stated annual saving. That cost was visible to finance and the programme sponsor before the decision.

We kept the original packages unchanged while examining the dependencies behind the 144 cases. Laboratory and quality colleagues determined what material was needed for the intended review. Technology colleagues maintained the ability to retrieve it and documented the reader, configuration and access arrangements. We did not assign an arbitrary universal retention period or argue that an old application should remain indefinitely merely because it had once been useful. The continuing need and the route to eventual retirement required further evidence.

At the review point the 144 sampled packages could still be examined through the retained capability, while work on a replacement interpretation route continued. That was a bounded operating result, not proof that every archived package was covered or that the arrangement met every possible future requirement. I used the case to change the way we discussed retirement: a system can stop accepting new work before the organisation can stop depending on it. A proposal needs to identify which of those events its savings assume, and who has the authority to confirm that the dependency has ended.

I would test representative archived material before including reader retirement in the savings proposal, making continuing interpretation requirements part of the original economic choice.

Case V

Deferring analytics when the missing resource was experienced review

When setting the 2026 technology programme, I had EUR24 million of change authority within the wider EUR68 million technology budget. The agreed allocation was EUR7 million for instrument-record stewardship, EUR9 million for enterprise renewal, EUR5 million for access and continuity, and EUR3 million contingency. A separate EUR4.2 million analytics proposal had an attractive account of how operating colleagues might examine manufacturing information. Its sponsors asked whether additional funding could bring it into the same delivery year.

I asked the team to identify the experienced laboratory, manufacturing and quality colleagues whose participation the proposal required. Their review was not an interchangeable service that could be purchased at the last moment. They already had continuing duties and commitments to the approved programme. The proposed analytics timetable assumed their availability without obtaining it. External technical capacity could help build the application, but could not replace all the internal knowledge or acceptance responsibilities on which the plan depended.

I recommended deferral rather than adding a funded project with an unsupported review schedule. Lucien Mervaul and the operating sponsors challenged the recommendation, appropriately asking whether a smaller initial scope could proceed. We examined that option. The narrowed proposal still depended on the same scarce reviewers at the same time, so it did not resolve the constraint. I preserved the analytics proposition for a later planning decision and asked the sponsors to prepare an explicit capacity requirement instead of treating the delay as a judgement that the idea had no value.

The EUR24 million allocation remained unchanged, including its EUR3 million contingency. We did not call the EUR4.2 million deferred request a realised saving, because it had not been approved expenditure. Nor did we claim that deferral improved product quality or accelerated the other programmes without evidence. The outcome was an investment schedule with fewer unowned assumptions. For me, the leadership test was to describe a constraint that money alone could not immediately remove, while accepting the opportunity cost of postponing a potentially useful capability and leaving a clear basis on which the decision could be revisited.

I would map experienced reviewer capacity before inviting competing analytics proposals, so scarce operating judgement enters the investment sequence before each programme acquires a promised start date.