Ruggedization er ikke en checkbox. Det er en reliability-kontrakt, du betaler for og håndhæver.

Jeg har set alt for mange programmer gennemføre den samme smertefulde dans: Et produkt går igennem qualification i et rent laboratorie, alle fejrer, og så rammer virkeligheden. Enheden installeres i et hårdere miljø, håndteres af en anden tekniker, monteres en anelse anderledes, udsættes for en duty cycle, som ingen fik skrevet ned, og så begynder den at fejle. Postmortem finder næsten altid samme root cause. Ikke “uheld”. Ikke engang “dårlige dele”. Root cause er typisk governance. “Rugged” var et ord – ikke en kontrakt.

Da jeg i flere år havde ansvar for market quality i power electronics, og senere stod i spidsen for R&D og operations for connected devices og industrielle systemer, lærte jeg at behandle reliability som en omkostning. Hvis den ikke er kvantificeret, ejet og håndhævet end-to-end, bliver det teater. Folk optimerer efter et lab-pass, fordi det er dét, systemet belønner. Kunder betaler for oppetid og levetid i felten – ikke for certifikater.

Ruggedization handler ikke om at gøre alting “MIL-spec”. Den tankegang er både dyr og doven. Operatørens opgave er at beslutte, hvor man skal hærde, hvor man skal redesigne, og hvor man kan acceptere risiko – og derefter bevise det med tests, der afspejler den reelle mission profile. Alt andet er et væddemål med en pæn PowerPoint-forside.

1) Start med en mission profile – ikke et adjektiv som krav

“Rugged” er ikke et krav. Det er en placeholder for et sæt belastninger over tid. Hvis du ikke skriver belastningerne ned, vil engineering gætte, test antage, procurement substituere, og manufacturing drive. Alt sammen lokalt rationelt. Globalt katastrofalt.

En mission profile skal være så eksplicit, at to teams på hver sin side af kloden ender med samme design og samme testplan. I praksis vil jeg have den formuleret som miljø plus brug – og derefter oversat til målbare loads:

• Miljø: temperaturområde og ramps, fugt og kondenshændelser, vibrationsspektrum, shock, støv, kemikalier, UV, salt fog, højde, EMC-eksponering.
• Brug: duty cycle, power cycling, switching frequency, antal mekaniske aktiveringer, connector mating cycles, installationsmoment, serviceinterval, hyppighed af firmwareopdateringer.
• Rammer: tilladt nedetid, serviceability, reservedelsstrategi, kalibreringsbehov, acceptabel drift, warranty-horisont.

Dernæst presser jeg på for næste skridt: oversæt profilen til kvantificerede failure modes. Hvad fejler først – og hvorfor – under disse belastninger? Er det solder fatigue fra thermal cycling, connector fretting fra vibration, fugtindtrængning og korrosion, polymer creep, coating-delamination, udtørring af elektrolytkondensatorer – eller en software watchdog, der interagerer med brownouts? Her stopper “ruggedization” med at være en stemning og bliver en engineering- og forretningsbeslutning.

Som tidligere COO med ansvar for engineering, produktion og service inden for elektrificering og energy storage var jeg mindre optaget af etiketten på en komponent og mere af systemets livsmodel. Nogle dele skal uprates. Nogle kræver mekanisk isolation. Nogle kræver redesign af airflow, sealing eller PCB stack-up. Og nogle gange er det rigtige svar at indsnævre operating envelope – og skrive det ind i kontrakten.

2) Placér ansvaret for reliability hos én person – med reel mandat

De fleste feltfejl skyldes ikke mangel på kompetence. De skyldes interfaces uden tydeligt ejerskab: engineering antager, at test fanger det; test antager, at kravene er korrekte; quality antager, at leverandører efterlever; leverandører antager, at substitutioner er acceptable. Ingen enkelt “throat to choke”, så ingen lukker læringsloopet.

Løsningen er enkel og ubehagelig: udpeg en single reliability owner. Ikke en komité. Én ansvarlig leder, der kontrollerer tre ting:

1. Miljøantagelser: mission profile er baselined og versionstyret. Enhver ændring udløser impact review.
2. Test matrix: hvilke stresses, i hvilken sekvens, hvilken sample size-logik, hvilke pass/fail-kriterier, og hvilke marginer.
3. Acceptance rules: hvad der definerer et releasable design, hvilke waivers der findes, og hvad der skal fixes før ramp.

Da jeg genopbyggede og skalerede en R&D-organisation på tværs af embedded software, cloud, elektronik, mekanik og QA, kom den hurtigste reliability-forbedring af klarhed. Ikke flere tests. Tydeligt ejerskab og én fælles definition af “done”. Når reliability fik en ejer, holdt lab-resultater op med at være en slutstation og blev en gate til næste læringscyklus.

Giv den ejer magt over prioriteringer og change control. Ellers beder du vedkommende om at stå på mål for resultater uden at kontrollere input. Det er ikke accountability. Det er teater.

3) Beslut, hvad der skal ruggedizes, hvad der skal redesignes, og hvad der skal operationaliseres

“Make it rugged” bruges ofte til at undgå den sværere beslutning: Hvor bruger vi penge, lægger lead time på og øger kompleksiteten – og hvor ændrer vi systemdesign eller operating model i stedet?

Jeg bruger en enkel beslutningsramme, som bestyrelse og operatører kan anvende i en kvartalsgennemgang. For hver top failure mode vælg én af tre strategier:

• Ruggedize komponenten: uprate dele, skift materialer, tilføj coating, mekanisk fastholdelse, sealing. Det øger enhedsomkostning og ofte lead time, men kan gå hurtigt, hvis arkitekturen understøtter det.
• Redesign systemet: flyt varmekilder, ændr layout for at reducere CTE mismatch, tilføj isolation, re-route creepage og clearance, tilføj redundans, ændr connector-strategi, forbedr dræning og ventilation. Det koster engineering-tid, men kan reducere tilbagevendende omkostninger og forenkle supply risk.
• Operationalisér risikoen: begræns envelope, tilføj installationskrav, kræv serviceintervaller, tilføj monitoring, tilføj stress-screening i produktion, eller ændr emballage og logistik. Det er ofte den billigste vej, hvis kundekonteksten tillader det.

Fejlen er at gøre alle tre ukritisk. Så ender du med et overbygget produkt, der stadig er skrøbeligt, fordi den reelle belastning aldrig blev modelleret. Eller du underbygger og forsøger at lappe det med et warranty-budget.

I connected sensors og building-controls systemer så jeg fx, hvordan “små” installationvariationer bliver en reliability-driver: kabeltræk, kondens bag en væg, vibration fra en nærliggende kompressor eller problemer med power quality. Nogle gange var ruggedization det rigtige valg. Andre gange var den vindende løsning mekanisk redesign og klare installationsregler, håndhævet gennem træning og acceptance checks.

4) Behandl procesopskrifter som kritiske komponenter – for det er de

Teams behandler ofte bill of materials som hellig og processen som fleksibel. For rugged produkter er det omvendt. Coatings, composites, adhesives, potting compounds, curing profiles, surface prep, reflow windows, torque specs og rengøringstrin er ikke “produktionsdetaljer”. Det er reliability-features.

Derfor kan supplier qualification ikke stoppe ved et datasheet. Operatørens playbook er:

• Lås opskriften: specificér material grade, blandingsforhold, overfladeforberedelse, cure time, cure temperature og acceptabelt fugtvindue. Dokumentér det, som du dokumenterer en componentspec.
• Audit linjen: bekræft, at leverandøren kan måle og styre opskriften – ikke kun påstå det. Hvis de ikke kan måle det, kan de ikke styre det.
• Kontrollér sub-tiers: definér, hvad der kræver notifikation, og hvad der kræver re-qualification. Enhver ændring i resinkilde, coating batch, PCB laminate, solder paste eller cleaning chemistry kan ændre levetid i felten.
• Gør afvigelser dyre: ikke i kroner, men i friktion. Afvigelser udløser formel review, ekstra test og forsinket release. Folk følger de regler, der har tænder.

Da jeg stod i spidsen for en international forretningsenhed med produkter leveret på tværs af flere lande, lærte jeg, at ukontrollerede substitutioner er en stille dræber. Procurement belønnes for pris og kontinuitet. Manufacturing belønnes for output. Uden en reliability-kontrakt håndhævet via change control vil begge træffe “fornuftige” beslutninger, der æder dine marginer ude i felten.

5) Luk loopet med feltdata og triggers for stress-screening

Ruggedization er ikke et engangsprojekt. Det er et læringssystem. Hvis du ikke høster field returns og fodrer dem tilbage i designregler, supplier controls og screening, kommer du til at betale for den samme lektie igen og igen.

Jeg foretrækker et stramt loop med tre elementer:

1. Hurtig triage af field returns: kategorisér fejl efter mekanisme – ikke symptom. “Ingen strøm” er et symptom. “Revnet loddesamling på DC link-kondensator pga. thermal cycling” er en mekanisme.
2. Stress-screening triggers: beslut hvilke tidlige signaler, der udløser ekstra screening i produktionen (burn-in, thermal cycling, vibration screening, humidity exposure). Screen ikke for evigt per default. Screen når data begrunder det – og stop, når processen er under kontrol.
3. Design- og procesopdateringer: omsæt læring til opdaterede acceptance criteria og supplier process controls, og håndhæv det via ECO-disciplin.

Her fejler mange organisationer kulturelt. De ser returns som et cost center – ikke som input til reliability-modellen. I mine ventures med SaaS-platforme som Shopeno og IBHQ er feedback loopet åbenlyst, fordi telemetry er kontinuerlig. I hardware skal du bygge loopet bevidst. Men princippet er det samme: Hvis systemet ikke lærer, bliver reliability-udgifter en tilbagevendende skat uden compounding gevinst.

Det jeg ville bede om på næste bestyrelsesmøde

Hvis du vil have en praktisk måde at styre ruggedization på allerede dette kvartal, så bed ledelsen om at tage en én-sides reliability-kontrakt med for hver produktlinje:

• Mission profile: eksplicitte stresses og brugsantagelser, versionstyret.
• Top 5 failure modes: på mekanismeniveau, med aktuelt evidensniveau.
• Valgt strategi pr. failure mode: ruggedize, redesign eller operationalize – med effekt på omkostning og lead time.
• Reliability owner: navngiven person med mandat over test matrix og acceptance.
• Supplier- og proceskontroller: låste opskrifter og change triggers.
• Field learning loop: kadence for return-analyse og screening triggers.

Min vurdering er klar: Ruggedization er hverken en checkbox eller et marketing-claim. Det er en håndhævelig reliability-kontrakt på tværs af engineering, test, leverandører, manufacturing og service. Hvis du ikke driver det som en kontrakt, betaler du for det to gange: først i dyre dele og derefter ude i felten.