Ook last van Elon zijn thermische mat?

Bij de ontwikkeling van software bij grotere bedrijven is het probleem dat afdelingen elkaar vaak te weinig vinden. Hierbij gaan dezelfde dingen mis als bij een autofabrikant waar afdelingen geïsoleerd van elkaar werken aan onderdelen. Hieronder een anecdote van Elon Musk die duidelijk maakt wat er misgaat, maar ook drie fabricage principes die aan het denken zetten bij de ‘fabricage’ van maatwerk software om uw proces te stroomlijnen.

In het Tesla fabricageproces lukte het niet om een robot een thermische mat op de batterij te laten lijmen. Dit zorgde dat het hele productieproces van de Tesla stokte. Elon probeerde op verschillende manieren om het knelpunt te verlichten. Hij probeerde het proces te versnellen door de robot sneller te laten gaan. Hij liet de robot minder lijm aanbrengen. Uiteindelijk vroeg hij de afdeling die verantwoordelijk was voor brandveiligheid naar de reden voor de thermische mat. Hun antwoord was dat het was om het geluid en de trillingen te verminderen. Toen Elon met het team sprak dat verantwoordelijk was voor geluid en trillingen, zeiden zij dat het voor de brandveiligheid was. Nadat ze de mat verwijderden was er geen merkbaar verschil in geluid en trillingen en het vormde geen bedreiging voor de brandveiligheid.

Stap 1: Zet vraagtekens bij de eisen

Stel altijd vragen bij de eisen, vooral als ze van een slim iemand komen. Soms zijn mensen te slim voor hun eigen bestwil. Als er een zeer kleine kans is dat iets gebeurt, loont het vaak niet er veel tijd en aandacht aan te besteden.

Ook is het belangrijk dat wensen en eisen van een naam zijn voorzien, niet van een afdeling. Op deze manier kunt u direct met een persoon praten over waarom die eis bestaat. Als eisen van afdelingen komen, krijgen we problemen Thermische mat problemen.

Stap 2 – Probeer heel hard om de stap of het proces te schrappen.

“Als je niet af en toe dingen terug toevoegt, dan schrap je niet genoeg” – Elon Musk.

Je hebt vast wel eens het verhaal gehoord over de oven en de lamsschenkel. Het verhaal gaat als volgt:

Een vrouw vroeg haar moeder waarom ze de lamsschenkel altijd doormidden sneed voordat ze hem in de oven zette. Haar moeder antwoordde: “Omdat mijn moeder het altijd zo deed.” De vrouw, nieuwsgierig waarom haar grootmoeder zo kookte, ging naar haar grootmoeder en vroeg haar waarom zij de lamsschenkel altijd in tweeën sneed. De grootmoeder antwoordde: “Omdat onze oven te klein was.”

De les hier is dat het gevaarlijk is om iets te doen alleen maar omdat dat is hoe het altijd gedaan wordt. Stap 2 in Elon Musk’s productieproces helpt hem dit probleem te vermijden. Door regelmatig te testen of een stap kan worden geschrapt, voorkomt hij dat het schenkelprobleem zich voordoet op zijn productielijn.

Stap 3 – Vereenvoudigen in plaats van optimaliseren

Het is de meest voorkomende fout van een slimme ingenieur, iets te optimaliseren dat niet zou moeten bestaan. De oorzaak is logisch, van jongs af aan is ons op school geleerd dat met een hoop feiten een vraagstuk oplossen. In plaats van te vragen “wat is het antwoord op deze vraag?”, moeten we ons afvragen: “zouden we deze vraag moeten beantwoorden?”

Er is een stelregel in SpaceX en Tesla engineering kringen: “Geen onderdeel, is het beste onderdeel. Elon heeft het erover dat slimme ingenieurs iets proberen te optimaliseren dat er helemaal niet hoeft te zijn. Een goed voorbeeld hiervan zijn de rastervinnen op de Super Heavy Boosters. In eerste instantie waren ze bedoeld om tegen de raket aan te vouwen wanneer ze niet werden gebruikt, maar in werkelijkheid zou dit een laag van onnodige complexiteit creëren. Dus, toen de eerste rastervinnen werden bevestigd, vouwden ze niet tegen de raket.

Sommige mensen waren bezorgd dat het niet vouwen van de rastervinnen voor extra weerstand zou zorgen, maar dat was niet het geval. Het opvouwen van de rastervinnen zou complexe mechanische systemen hebben vereist die de raket zwaarder zouden hebben gemaakt. In de raketwereld telt elk pondje.

Terug naar de ontwikkeling van maatwerk software. Vaak is de introductie van een nieuwe applicatie ook een herijking van de bestaande processen. In de praktijk komen wij veel wensen tegen waarvan niemand echt uit kan leggen waarom het moet. De hoofdreden is dan dat het ook in het huidige systeem zit. Een voorbeeld is een veld dat ooit is toegevoegd, omdat er in, let’s say 2012 een keer iets mis is gegaan, 20 mensen vullen het veld nog dagelijks in, maar niemand weet waarom.

Bovenstaande komt natuurlijk in uw bedrijf niet voor, maar mocht u toch eens willen sparren of we met maatwerk software uw processen kunnen verbeteren. Bel dan even met Renzo Lunenberg, 06 2037 6166.

Klik hier voor de bron van het artikel met nog 2 bonustips: