151217 Logga med undertext

  • Hem
  • Ledningssystem
  • Kvalitet
  • Miljö
  • Brandskydd
  • Arbetsmiljö
  • Samarbete
  • Blogg
  • Bakgrund
  • English
  • Hem
  • Blogg
30 jun2016

En affärsmodell baserad på tur!

Det var en gång ett litet företag som, utan att de riktigt insett det själva, arbetade i projektform. Projekten var uppdelade ungefär i följande faser, om cirka en månad vardera:
1. Beställning och/eller lagerplock av de standardvaror som ingick i leveransen
2. Konstruktion och beställning av de specialbeställningar som krävdes i projektet
3. Slutmontering hos kund, i samverkan med andra entreprenörer, inkl de slutanpassningar som inte kunnat förutses

Affär

I de flesta projekten körde det ihop sig på slutet, och säljaren (som inte riktigt insett att han även var projektledare) undvek till slut kontakt med kunden eftersom kunden mest klagade. Dessutom var det också så att man i ordererkännandet lovat ett färdigdatum inom tre månader, men till kunden muntligen sagt att det nog gick att lösa på 10 veckor. 

Min slutsats av detta är att om man inte är överens med sin kund när man skriver kontraktet, är det omöjligt att få en nöjd kund efter leverans. Detta gäller i alla fall utom ett; om man har tur. Då har man plötsligt skapat en affärsmodell baserad på att man måste ha tur varje gång för att få en nöjd kund! Ibland går det bra, men ganska ofta går det åt skogen.

24 feb2016

Förbättra förbättringarna!

Avvikelsehantering fokuserar oftast på att snabbt återställa ordningen till ett "normalläge". I många fall räcker det naturligtvis, men oftast lönar det sig att utreda orsaken på djupet.

Efter att servicemodulen till Apollo 13 havererat och astronauterna med nöd och näppe lyckats tas sig levande hem, tror ni att NASA nöjde sig med att bygga en likadan till Apollo 14? Nej, de konstruerade om de system som havererat och gjorde vissa system mer oberoende av varandra. Men de förändrade också sitt sätt att konstruera, dvs sitt sätt att tänka när det gäller systemsäkerhet.

Apollo 13 SM skada

Bilden visar den skadade servicemodulen efter att den kopplats loss, med hålet efter explosionen till höger.

Hur kommer det sig att vi så ofta nöjer oss med att en halvbra lösning på ett problem, utan att ordentligt utreda orsaken? Varför är det så jobbigt när kunden kräver en 8D-rapport med analys av 5 Varför?

Även om felet upptäcks på en fysisk produkt, ligger orsakerna ofta i de bakomliggande processerna. När inte den grundläggande orsaken åtgärdats kan vi ju vara ganska säkra på att något liknande kommer att hända igen.

Vad skulle hända om vi varje gång något går fel inte bara återställer läget, utan försöker komma till en nivå som är högre än innan det hände?

(Mer info om Apollo 13: https://sv.wikipedia.org/wiki/Apollo_13)

Senaste inläggen

En affärsmodell baserad på tur!
Förbättra förbättringarna!

 

Kontakt

MH Teknik
Mats Hård
070-289 24 18
Den här e-postadressen skyddas mot spambots. Du måste tillåta JavaScript för att se den.

Blogg

Jag lägger med långa intervall ut korta iakttagelser och reflektioner med koppling till mina områden.

Om du vill få ett mail när bloggen uppdaterats, eller om du vill tas bort från maillistan, skicka ett mail.
Den här e-postadressen skyddas mot spambots. Du måste tillåta JavaScript för att se den.

Copyright © 2016 MH Teknik. Alla rättigheter reserverade.
Webbutveckling av Webino.