Who Owns What
A vision project passes through process engineering, quality, maintenance, production, IT and purchasing, plus an outside supplier. The technical problems generally have known answers. What stalls the project is a gap in accountability — something that everybody assumed somebody else was handling, until a point arrives where a person has to decide or sign and it turns out nobody can. The three that recur are ownership of the criteria, control of the parameters, and signature on acceptance.
Key takeaways
- Ownership of the criteria belongs to process or quality, never to the supplier.
- Once parameters are controlled, individuals cannot change them at will.
- Acceptance criteria and the accepting role are fixed before work starts, not at the end.
- Three recurring gaps: criteria ownership, parameter control, exception handling.
The departments involved care about different things and none of them are in conflict. Process engineering cares whether the criteria are right. Quality cares whether the system can be traced and audited. Maintenance cares whether the mechanical and electrical parts connect and can be kept running. Production cares about cycle time and unwanted stoppages. IT cares about networks and integration. Purchasing cares about the contract. The project goes wrong when nobody connects these, and the symptoms are recognisable: the scheme is revised repeatedly, acceptance criteria stay undefined, and a working system sits waiting for somebody willing to sign for it.
Roles and responsibilities
| Role | Accountable for | Must be involved at |
|---|---|---|
| Process | Defining acceptable and unacceptable; supplying defect types and severity grades | Before the criteria are frozen; at every revision |
| Quality | Acceptance criteria and sample requirements; records and traceability; customer audits | Setting acceptance; signing off; audit preparation |
| Maintenance | Mechanical and electrical provision; installation, fixtures, cabling, guarding; upkeep | Scheme review; installation; ongoing maintenance |
| Production | Cycle time and operating conditions; reporting false calls and usability problems | Cycle confirmation; trial running; everyday operation |
| IT | Networks, accounts, data storage and security; interfaces to MES and similar | Interface review; integration testing |
| Purchasing | Contract, payment, supplier management; commercial handling of changes | Contract award; when changes arise |
| Supplier | Algorithm and system implementation, commissioning, training, support | Throughout, with the boundary written into the contract |
The three gaps
Confirm each one explicitly
- Who owns the criteria
Whether a particular scratch is a reject can only be answered by process or quality, because they are accountable to the product function and the customer requirement. The common failure is leaving it to the supplier, who will draw a line based on what they can see — a line that looks reasonable and may have no relationship to what the customer actually needs. Once that ownership is given away, every later acceptance argument loses its reference point.
- Who controls the parameters
After commissioning, who owns exposure, gain, thresholds and lighting? A vague answer means whoever is standing at the station, and the consequence follows: somebody removes a false call by nudging a threshold, the escape rate rises, and no record exists that anything was changed. Parameters need to be treated as controlled items, with changes going through a route that leaves a record. This has to be settled before the system goes live, not after.
- Who handles an exception
When the system alarms, misjudges or stops, who is called first? Without an answer, every incident involves a discussion, the response takes longer than it should, and the response differs each time. A workable answer is a defined ladder: what an operator may do, what a team leader may do, when an engineer must be called, and when the line must stop. Write it down and train it, or it will not be followed under pressure.
Making it work in practice
Writing the responsibilities down is the easy part. Three things make them operate. A named project lead whose job is to drive rather than to execute, so that cross-departmental items have somebody pushing them. A regular review cadence, held before every significant milestone, whose output is decisions rather than status updates. And a written decision record — what was decided, by whom, effective when — circulated afterwards. The third looks the most bureaucratic and pays back the most: when a dispute arises late in the project, reading the original decision is far faster than re-arguing it.
Common questions about project roles
Which department should lead?
Usually whichever cares most about the outcome, which is often process or quality, though maintenance sometimes leads. What matters is not the department of origin but whether the person has the authority to move other departments and the time to spend, and appointing somebody already overloaded is the most common and least effective arrangement.
Where does the supplier's responsibility end?
Draw it along the line of who can control the variable. Algorithm performance, system stability and commissioning quality belong to the supplier; part-to-part variation, environmental conditions and fixture accuracy belong to the user. The grey areas cause the arguments — "is it not detecting because of the algorithm or because the lighting is poor" — so the contract should specify how such a question is decided, commonly by a jointly agreed sample set.
What if production will not cooperate?
There are usually two reasons: trial running costs them output, and they expect the system to create work for them. The first is a scheduling problem — put commissioning in a changeover window or a planned stop. The second is solved by involving them early, which is the subject of operator resistance. An operator who helped shape the scheme in the design phase is far easier to bring on side than one who first sees it on the day it goes live.
Where is your project stuck?
Tell us the state of the project and the step it has stalled at. We will say which responsibility is missing and which decision needs making.
Related articles
-
Alarm Fatigue: Why the Floor Turns the System Off
Many visual SOP systems are not beaten by technical problems — they are muted by…
Read more → -
Visual SOP Camera Selection and Mounting
Camera selection for visual SOP is not the same as for product inspection. The s…
Read more → -
Vision Monitoring at the Semiconductor Die Bonder
Semiconductor packaging stations are characterised by high precision, fast cycle…
Read more → -
Wrong-Assembly Alarms Without the False Alarms
The most common reason a visual SOP project fails is not poor recognition — it i…
Read more →
Need specific advice for your production line?
Our engineers can share practical approaches to process error prevention and SOP compliance inspection for your scenario.
Request a free trial plan