Technology · Jewellery manufacturing · SEEPZ, Mumbai
We fixed the middle first. Turnaround fell 20%.
The short version
Fine has manufactured diamond jewellery from SEEPZ since 1987 and exports more than 200,000 pieces a year to some of the largest brands in the UK and Europe. Growth had put the directors back inside daily operations. We worked through every function, found the constraint in product definition, and automated that first — then extended backwards into design brief management and forwards into quality control with a barcode-driven mobile application. Turnaround time came down20%on the same team.
Where to start when everything needs fixing
A manufacturer that has grown quickly has problems in every function, and every head of department will tell you theirs is the urgent one. They are all telling the truth. The question is not which problem is worst, it is which one is holding the others in place.
We went function by function — design, product defining, brief management, production, quality check, sales — walking the process and analysing what data existed for each. What came out was that product definition sat at the centre of everything. Design fed into it. Production, costing and quality all waited on what it produced. A delay there did not stay there; it propagated in both directions, and it was invisible because nobody was measuring the step itself.
Most digitisation starts at the edges, because the edges are where the software vendors are — order capture at one end, dashboards at the other. Starting at the constraint is harder to sell and it is the only sequence where the second phase is easier than the first.
So the order was: automate product definition, then reach backwards to the design brief that feeds it, then forwards into quality. Each new piece connected to something already working rather than to a plan.
The middle, then outwards
| Backwards — brief and design | Design brief raised, designs submitted against it, internal feedback loop, then a customer feedback loop on the same pattern.Once the customer approves, a design is marked for definition and passes into the module below. |
| The middle — product definition | Designer requests and shares technical details, merchandiser adds cataloguing, product defining team completes the design details in the ERP.Automated end to end. This was built first. |
| Forwards — quality control | A mobile application capturing quality checks at each stage, integrated at data level with the ERP.Built simultaneously, connected into the same spine. |
The design flow is worth noting for a specific reason: the customer feedback loop is built on the same mechanism as the internal one. A brand in London reviewing a design is doing the same thing a merchandiser in Mumbai does, and modelling it once means the approval history of a design is complete rather than split between a system and an email thread.
The quality application
Quality control in jewellery manufacturing happens repeatedly, on physical batches, by people standing at a bench. Any system that requires them to go to a computer and type will be completed at the end of the shift from memory, which is the same as not having it.
So the QC application runs on a mobile device. A team member scans the barcode on a production bag to identify it and captures the quality detail against that bag, at the stage, at the time.
| 01 | Barcode scanning to identify the production bag, so the record attaches to the physical thing rather than to a typed reference somebody might mistype. |
| 02 | Quality data captured at each stage rather than at the end, so a problem is located rather than merely detected. |
| 03 | Data-level integration with the ERP for tracking and monitoring delays. |
| 04 | Full historical retrieval for any bag, including whether repairs were carried out. |
Item four is what a brand customer actually asks for when something goes wrong. Being able to retrieve the complete quality history of a specific batch, years later, is not a reporting feature. In an export business supplying major brands it is the difference between an answer and an apology.
Reports that arrive rather than reports you fetch
Both applications carry live dashboards for department heads, summarised for a quick read rather than exhaustive.
The more useful half is the exception reporting. Where something deviates from the standard or the process, the relevant person is notified. They do not have to be looking at a dashboard, and they do not have to know to check.
That distinction runs through most of what we build. A dashboard tells someone who is already asking. An exception report tells someone who is not.
What changed, and what we can evidence
The reported outcome is a20%reduction in turnaround time, achieved without adding people. It came about the way these things usually do: the automation produced data, the data made the delays in the defining process visible, and the team then removed them.
What we can and cannot tell you
The 20% is the client’s figure. We built the systems that measure it, and the number was reported to us rather than audited by us. We have not been given the baseline turnaround time or the measurement window, so the page states the improvement without the absolute figures behind it.
The software did not do it. Automation made the delay visible; the team removed it. That distinction matters because the second part is the harder one and it belongs to Fine, not to us.
Fine has grown substantially in recent years. That growth predates and surrounds this engagement, and its causes are the business, its products and its customer relationships. We make no claim on it.
This is one of two engagements. Debox has worked with Fine across strategy, people and process alongside this digitisation programme. This page covers the technology work only.
Constraints that shaped the work
Starting at the constraint rather than the edges means the first visible output arrives late. For several months the work is process walkthroughs, data assessment and one automated function that most of the company does not touch. A management team that wants early proof will find this uncomfortable, and the ones who hold their nerve get a second phase that connects to something real instead of to a specification.
We also did not baseline turnaround time before starting, which is why the result on this page is a percentage without the numbers underneath it. In a programme whose entire purpose was making performance measurable, that is an omission we notice.
In their words
“They are a young business consulting firm — much more than just an HR consulting firm — who have helped us in various areas such as process improvements, digitisation and visioning exercises. I believe all businesses can engage with them and they can add value to varying extent. Our overall experience with them has been very good.”
Jignesh Hemani — Chief Financial Officer, Fine Jewellery Manufacturing
If every department needs digitising
They do not all need it at once, and the order is not a matter of preference. Find the function that other functions wait on — usually a step in the middle that nobody owns and nobody measures — and start there.
Starting at intake or at reporting feels safer because the outputs are visible sooner. It also means every subsequent phase connects to a plan rather than to something that already works, which is why so many of these programmes stall at phase two.
Read another
Every figure sourced from the client’s own systems, with the basis stated and the exclusions named.Bawarchi Atlanta
Smile Loft Dental
Sanpeggio’s Pizza
Measurement note. Scope, applications and process design are from our own project records. The turnaround time reduction is a figure reported to us by the client, produced by the systems built during this engagement, and was not independently audited by us; no baseline turnaround time or measurement window was provided to us. Export volume is the client’s own published description of its operation.
