Hamza CharifBatch coating optimisationCV

ProjetsBatch coating optimisation

Batch coating optimisation

Combining process calculations, operator observation and production-flow redesign

Written August 2026 · Last updated 2 August 2026

At a glance
ContextIndividual project within an industrial organisation
PeriodCompleted April 2026
RoleSole analyst, supervised by the production director
DomainBatch coating · process and operations improvement
MethodsOperator shadowing and SOP review · Mass and energy balances · Solvent and occupational-safety research · Production-flow redesign
StackProcess calculations · Operational analysis · Technical reporting
StatusRecommendations delivered; implementation not independently confirmed
Contents
  1. 1. The initial problem
  2. 2. Why the balances were not the lever
  3. 3. Grounding the analysis in the shop floor
  4. 4. Process-engineering analysis
  5. 5. Operational redesign
  6. 6. Building a defensible recommendation
  7. 7. Outcome and implementation status
  8. 8. Limitations and next steps
  9. 9. What this project taught me

The initial problem

The project started with a conventional process-engineering question: how could a batch-coating operation be made faster and more efficient without ignoring drying performance or operator safety?

The first instinct in this type of task is to focus on the unit operation and its balances. Those calculations mattered, but they did not explain the whole cycle. The process seen in an SOP and the process experienced by operators were not the same object: preparation, charging, movement, waiting, manual records and coordination around the equipment also shaped the elapsed time.

That observation changed the scope. The project became an end-to-end study of both the physical transformation and the production system around it.

Why the balances were not the lever

Measured in time rather than in efficiency, the gains available from the operational changes dwarfed the gains available from the mass and energy balances. The unit operation was the part I had been sent to optimise and the part least able to move the number. That is the uncomfortable shape of this kind of assignment: the tool you are trained to reach for is aimed at the smaller share of the problem, and no amount of rigour applied to it will recover what is being lost between operations.

The second difficulty was not finding the changes but getting them adopted. In a regulated manufacturing environment a proposal is assessed first against the procedural cost of altering a validated procedure, and only afterwards against its engineering merit. That inverts the usual order of argument, and it is the reason the largest savings identified here were also the hardest to move.

Grounding the analysis in the shop floor

I shadowed the operators to understand how the cycle was actually executed, then compared that sequence with the written procedures. Questioning an SOP did not mean assuming it was wrong. It meant identifying which steps protected quality or safety, which reflected the current equipment layout, and which had become routine without an explicit technical reason.

The clearest example was also the simplest. An operator would stand at the coating drum and watch it turn, waiting for the batch to finish before starting to prepare the solvent mix for the next one. Nothing about the process requires that ordering: the mix can be made while the drum runs. The wait existed because the written procedure sequenced it that way, so it was not an operator habit to be corrected but a designed step to be revised. That distinction mattered for how the finding could be raised at all.

This produced two complementary views:

  • a process view, covering material quantities, solvent composition, heating and drying duties;
  • an operations view, covering sequence, parallel work, charging, manual information flows and avoidable delays.

Keeping both views was essential. A faster solvent system is of little value if it increases exposure in the dryer room; a better production sequence is not acceptable if it violates a quality-critical dependency.

Process-engineering analysis

I completed mass and energy balances for the operation and compared the solvent fractions used in the SOP with alternative fractions. The calculations showed substantial room for improvement relative to the documented operating choice.

I also researched the solvents from an occupational-safety perspective because operators remained in the dryer room. The purpose was to ensure that a proposed process improvement did not transfer cost or risk from the equipment to the people operating it.

The solvent analysis was therefore not treated as an isolated optimisation. Candidate fractions had to be considered together with drying demand, handling conditions and operator exposure.

Operational redesign

The shop-floor study identified opportunities outside the core unit operation. The final proposal included:

  • preparing the next batch’s solvent mix during coating, instead of after it;
  • digitalisation of selected records and information flows;
  • removal or restructuring of avoidable sequential work;
  • clearer coordination between preparation, charging, coating and drying;
  • revision candidates for SOP steps whose purpose or timing required review.
Two dependency graphs. As the procedure sequenced it, preparing the next solvent mix waits for the drum to finish coating the current batch. What the process requires is only that the mix be ready and the drum free, so the mix can be prepared while the drum is still running.

The single link worth most on this page. Preparing the next mix waited on the drum because the procedure said so, not because anything in the process required it. Dependency graph, not a schedule: no box here represents a duration.

These changes moved the project into operations research and industrial engineering. The objective was no longer merely to improve one rate or one balance, but to reduce the total completion time subject to process, safety and organisational constraints.

Building a defensible recommendation

Each proposed change was evaluated with a before-and-after calculation. The effects were then compounded in sequence rather than simply added as unrelated percentages. This matters because one improvement changes the baseline on which the next one acts.

Across the full package, the deterministic analysis indicated an approximate 60% reduction in the elapsed time between consecutive coating batches, with inter-operation intervals included. The report presented the contribution of the different levers so the production team could separate changes that were immediately operational from those requiring an SOP revision, further safety review or additional validation.

Outcome and implementation status

I delivered an end-to-end report covering the technical calculations, operational diagnosis, digitalisation proposal and recommended changes. The production director verbally indicated that the findings would be implemented.

I did not have access to the later implementation data. For that reason, the responsible claim is that the study demonstrated a projected compound reduction of about 60% in batch-to-batch elapsed time, including inter-operation intervals, under its stated assumptions. It is not evidence that the site achieved the same reduction in routine production.

Limitations and next steps

The 60 % is a calculated figure, not a measured one, and the standing note at the top of this page says so. That is the limitation a reader will look for first. It is not the one that would actually decide the outcome.

The binding constraint here is procedural rather than technical. Several of the strongest proposals require revising a procedure that was written and validated long before the study existed, and revalidation can refuse a change whose engineering and economic case is exceptional. A study that ranks changes only by the time they save will therefore overstate what is available in practice, because it prices the engineering and ignores the paperwork that governs whether the engineering is allowed to happen. I regard that as the honest criticism of my own report.

Two next steps follow from it. The first is to make procedural cost a primary axis rather than a footnote: the report already separates changes that are immediately operational from those needing an SOP revision, further safety review or additional validation, and that separation deserves to drive the sequencing, so the site can bank the unblocked savings while the harder cases work through approval. The second is to instrument the line and measure a real baseline, so that any change which does clear the procedural bar can be assessed against observed elapsed time rather than against a calculation of it.

What this project taught me

The key lesson was about problem boundaries. A task labelled “process optimisation” can be dominated by scheduling, information flow or work design. The right response is not to force every cause into a process model, but to combine the appropriate tools: observation for the real workflow, balances for the physical limits, safety research for acceptable choices and operational analysis for the sequence.

That broader frame turned a local calculation into a set of decisions the production team could evaluate and act on.

The second lesson was about how proposals die, and it only became clear by comparison. In the water production study my best idea was rejected because a senior engineer knew something about scaling that I did not, an argument I could follow, learn from and concede. Here the limiting factor was rarely whether a change was right. It was what revalidating a long-standing procedure would cost. Both are legitimate constraints and an engineer has to work inside both. But they teach very different things, and I would rather spend my time where a proposal has to survive the first kind of scrutiny.

Questions about this work? [email protected]