Case study 05
From fragmented handoffs to a controlled operational workflow.
Expired, damaged and other stock-removal cases can involve physical stock, supplier communication, compensation evidence, financial verification, management approval and final system adjustments. Handled through disconnected messages, sheets and verbal follow-up, it becomes hard to see what has been verified, what is still waiting, and what has to happen next. I redesigned the process into a role-based workflow connecting request, verification, approval, system execution and closure.
Workflow DesignGovernanceOperational Control
The difficulty was never recording that an item had expired. It was everything that has to happen around that fact, across four functions, before the case can honestly be called closed.
A single case can require identifying the stock, contacting the supplier, establishing whether compensation applies, documenting goods or credit-note compensation, financial verification, management approval where applicable, a physical instruction for the stock itself, a system quantity and action instruction, the system posting, the resulting document reference, and a confirmation that the case is genuinely complete.
Pharmacy identifies the stock, accounts handles the financial side, management approves where required, and IT performs the system action. Each step is straightforward on its own; the coordination between them is where the work actually lives.
Whether a case had been verified, approved or executed was often reconstructed from messages, separate sheets and documents rather than read from one record.
Compensation documentation, supplier correspondence and the eventual system reference could each live somewhere different from the case they belonged to.
A credit-note case, a compensation-goods case and a non-compensatable case need different information. A single fixed form either asks everyone for everything or asks nobody for enough.
Approval can feel like the end of a case, but the stock has not moved and the system has not been adjusted. Without a defined closure step, a case could be treated as finished while operational work remained.
Stock removal sits at the point where physical inventory, supplier money and the system record all have to agree.
A case should not disappear between departments — and approval is not the same as completion.
Physical stock and system stock have to stay aligned. A removal that happens on the shelf but not in the system leaves a discrepancy that surfaces later as an unexplained variance.
Supplier compensation — whether a credit note or replacement goods — needs verification before it is treated as received. An expected credit is not a received credit.
A case that passes between four functions can stall in the gap between any two of them, and the gap is exactly where nobody owns it.
Evidence, approvals and the resulting system action need to remain attached to the same case, so that what was decided and what was done can be read together rather than assembled afterwards.
Teams need to know whether a case is awaiting verification, awaiting approval, awaiting execution or genuinely closed — without asking somebody.
I mapped the operational process across pharmacy, accounts, management and IT; identified the decisions and evidence required at each stage; simplified the handoffs; designed the case structure and role-specific workflows; built the working solution; and validated the process against real operational scenarios.
Worked through how removal cases were actually being handled across the four functions, and where a case tended to stall, duplicate itself or lose the evidence attached to it.
Mapped the end-to-end path — identification, supplier position, compensation route, financial verification, approval, physical instruction, system action, closure — including the branches that only appear on particular kinds of case.
Removed handoffs that existed only because information had to be carried by hand, and settled which function owns each decision so that the same question was not being answered twice in two places.
Defined what a case is: the information it must carry, the evidence each route requires, and the states it can legitimately be in.
Designed the role-based workflow itself — what each of the four roles sees, decides and hands on — and the conditional logic that adapts the information required to the case in hand.
Built the working solution behind that design, so the process could be operated rather than only documented.
Tested the workflow against real operational scenarios — including the awkward ones — and adjusted the design where the process and the tool disagreed.
Put the redesigned process into operational use across the roles it spans, rather than leaving it as a recommendation.
Different cases cannot be forced down the same information path. What a case needs depends on the supplier position, and that decision belongs to the requestor at the start rather than to accounts later.
Does supplier compensation apply to this case, and in what form?
A fourth path exists for compensation received in advance of a specific case. It is handled separately, and is described further down.
Four roles, one case, and a defined point at which it is finished. The workflow structures responsibility, evidence and handoffs; the verification, the approval and the system posting stay with the people who should be doing them.
Creates the case, identifies the affected items, records the supplier position and compensation route, and provides the relevant evidence.
Hands on a case with its route already determined.Verifies the financial or compensation information relevant to the selected route. Accounts verifies; it does not make the supplier decision.
Hands on a case whose financial position has been checked.Reviews cases that require approval, once the information the decision depends on is complete.
where required Hands on an approved case — or returns it for correction.Receives the final operational instructions, posts the required system adjustments, records the resulting system document references and closes the case.
The closure point of the operational workflow.The workflow adapts to the case rather than forcing every case through the same form.
A form that asks every case for everything trains people to leave fields blank, and a blank field tells you nothing about whether the answer was unavailable, irrelevant or forgotten.
The requestor determines the supplier position and the compensation route at the point the case is raised. Accounts verifies against that route rather than re-deciding it.
A credit-note case requires the relevant credit-note details and their verification. A compensation-goods case follows a different evidence path. The two are not variations of one field set.
A case with no supplier compensation is not routed through compensation fields that do not apply to it.
Evidence fields can be marked as not applicable, so an intentionally empty field is distinguishable from an unanswered one.
An invoice reference can be optional because goods can be received, or stock identified for removal, without the original invoice being to hand. Requiring it would stall legitimate cases.
Accounts sees the fields relevant to the selected route where applicable, rather than the whole case surface.
Role-based entry is where the design becomes visible: each function opens the workflow at its own point rather than into a shared document everyone has to interpret.
The roles are not four separate tools. They are four views of the same case, each opening at the stage that role is responsible for.
Each entry point names what that role does — create, verify, approve or return, execute and close — so the division of responsibility is explicit before anyone starts work.
The requestor entry covers both normal and advance supplier compensation, which is the second path described below.
A case has a small number of legitimate states, and one of them is conditional.
Raised with its route and evidence.
Financial or compensation position checked.
Where the case requires it.
conditionalSystem adjustment posted, reference recorded.
Operational and system action both complete.
Approval is a stage, not a guarantee: a case can be returned for correction rather than moving forward.
Supplier compensation does not always arrive after one specific claim.
Goods or credit value may already have been received before the case they will eventually settle exists. Treating that receipt as though it belonged to no case at all leaves it undocumented; forcing it onto the wrong case misstates both.
The workflow therefore includes an advance-compensation path: the receipt can be recorded and verified when it arrives, and later applied against subsequent cases while the original verification trail stays attached to it.
It is the same principle as the rest of the workflow — verify once, at the point the information exists, and keep the verification with the thing it verifies.
The workflow does not stop at approval. It carries the case through to the actual operational action, and records the reference needed to show that the system step was completed.
Financial and compensation position checked.
What happens to the stock itself.
What the system record requires.
IT performs the system posting.
The resulting system reference is recorded.
The case reaches its defined end.
IT performs the final system action and enters the system document references. The workflow carries the instruction and holds the record; it does not post stock into the operational system on its own.
What changed is that a case now has one path, one place to read its status, and a definition of finished.
The redesigned workflow created one connected path from stock identification through supplier handling, financial verification, approval and final system execution. Instead of reconstructing the status of a case from separate messages and files, each role can work from the information relevant to its stage while the case progresses toward a defined closure point.
Clearer handoffs — each role can see what it needs to do, and where the case came from.
Structured verification — financial and compensation information is checked before the final action, by the function responsible for it.
Conditional workflow — different case routes do not force people through information that does not apply.
Traceable completion — the process continues past approval, through system execution, to closure.
A reusable operating process — the structure supports expired, damaged and related controlled stock-removal scenarios rather than one case type.
These outcomes are qualitative. No time saving, cost saving, error reduction or compliance improvement is claimed, because none has been measured.
This was not primarily a form-building problem. It was a process-control problem.
The value came from understanding how physical stock, supplier decisions, financial verification, management approval and system execution interact — and then turning those dependencies into one practical workflow.
The design question was never which fields to put on a screen. It was who decides what, on what evidence, before which step, and how anyone can tell afterwards that the step actually happened.
Process Responsibility Evidence Control
A workflow of this kind earns its place by being narrower than the people using it, not wider: it holds the shape of the process and the record of what was done, and leaves the judgement where it belongs.
This case study describes a process, not an organisation. No organisation, customer, supplier, invoice reference, credit-note reference, case number, item code, batch number, quantity or compensation value appears here. The role-based entry view is a reconstruction of the implemented workflow using representative information, not a literal screen capture; the route, workflow, lifecycle and execution diagrams are editorial explanations of the process logic rather than depictions of an interface.
Contact
If work that crosses functions loses its status somewhere in the middle — and nobody can say whether it was verified, approved or actually done — describe how it runs now. I'll tell you where I'd look first.