Manufacturing minds

Het motief

Laten we eerst ingaan op het motief voor een workshop voor studenten. Het lijkt logisch om iets te doen binnen het onderwijssysteem. Persoonlijk geloof ik ten zeerste dat onze toekomst momenteel in de schoolbanken zit. Maar waarom zijn we gestart met studenten aan de universiteit en dan specifiek Industrieel Ontwerpen? Zou het niet logischer zijn om de workshop te richten op HBO of MBO werktuigbouwkunde studenten? Zeker is dat logischer maar waren we van mening dat er een behoorlijk gehalte aan zelfredzaamheid in de workshop nodig is. Dit wilden we dan ook eerst testen bij studenten die een zeer groot probleemoplossend vermogen hebben.

De workshop in een notendop

De doelstelling van de workshop was om studenten kennis te laten maken met het delen van gegevens en samen uitvoeren van opdrachten. Daarbij hebben we verstorende elementen ingebouwd, die een soepele afwikkeling van een ogenschijnlijk makkelijke opdracht in de weg stonden. Als begeleiders voelde het net als een aflevering “Wie is de mol”.

De studenten waren verdeeld in groepen. Elke groep doorliep een 3-tal rollen: Sales, Engineering en Productie. Elk team kreeg een opdracht toegewezen die ze moesten vertalen in een opdracht (in de vorm van een bericht) voor engineering (vanuit Sales) en een opdracht (bericht) voor productie (vanuit Engineering). Deze berichten konden verstuurd en ontvangen worden met de applicatie. Naast tekst konden de berichten voorzien worden van een bijlage. Tevens konden de teams onderling chatten via een chat functie in de applicatie. Uiteindelijk wilden we dat er in de rol van productie ook echt iets gemaakt zou worden. We hebben dus Lego in de workshop meegenomen als de bouwstenen voor het ontwerp. Dus met de applicatie op zijn plek zijn de berichten verstuurd, de Lego stond klaar…teams, bouwen maar!

Maar zo makkelijk wilden we het niet maken. De verstorende elementen deden goed hun werk. De teams werden telkens weer teruggeworpen in vorige rollen omdat zaken bleven veranderen. Tevens zorgde het gebrek aan de juiste bouwstenen voor behoorlijke frustratie in de Productie. In sommige opzichten net als bij een echt maakbedrijf.

Het lerend effect zat in de verstorende situatie die optrad. We kozen ervoor om in die momenten de verwarring te dempen door een time-out. In deze time-out gaven wij informatie over de situatie, vroegen we om input van de deelnemers, gaven voorbeelden uit de praktijk en gaven een samenvatting van alle belangrijke aspecten van dat moment.

De belangrijkste leerpunten op een rijtje:

Verstoring bij Sales: klantvraag wijziging

• Klant waarmee een goede relatie bestaat krijgt voorkeursbehandeling. Gevolgen van de wijziging worden geaccepteerd vanwege de goede verhouding met de klant.
• Klantwens wordt soms doorgevoerd zonder dat volledige financiële impact bepaald kan worden. Risico komt bij maakbedrijf te liggen.
• Klantwijziging kan niet in automatisch doordringen in andere afdelingen wanneer er een officiëler accorderingsproces aanwezig is.
• Door training en andere middelen (specificaties, pakket van eisen, afbeeldingen) kunnen misvattingen voorkomen worden tijdens het ontstaan van de salesorder.
• Breng Sales en Engineering dichter bij elkaar door het gebruik van standaardisatie en configuratoren (Configure-to-Order). Hiermee is er meer zekerheid dat te realiseren ontwerpen aangeboden worden aan klanten.

Verstoring bij Engineering: klantvraag opnieuw een wijziging

• De strijd om mandaat is begonnen. Mag de engineer snel met een wijziging aan de slag? Is de sales nog wel “in-control” als de klant alweer de opdracht wijzigt? In hoeverre zijn de afdelingen op elkaar afgestemd zodat er snel ingespeeld kan worden op een wijziging? En wanneer is er een punt bereikt dat dit niet meer kan. Leiderschap speelt hierin een grote rol. Engineering heeft vaak snel een beeld van de financiële impact. Het is echter aan sales om te besluiten of deze impact doorbelast gaat worden of niet.
• Wederom zijn er elementen die het risico van wijzigingen kan verminderen. Gebruik Requirements Management om zodoende de opdrachten aan te nemen waarvan je zeker weet dat deze passen binnen het raamwerk van jouw expertise. Gebruik configuratoren om te treden op gebaande paden en geef engineering houvast.
• Wanneer het uitloopt op een wijziging vertrouw er dan op dat het Change Management proces steun zal geven bij het doorvoeren van de wijziging. Immers kan er een mix ontstaan van onderdelen die gereserveerd zijn of besteld zijn of wellicht die een wel of niet vrijgegeven status hebben gekregen. Product Datamanagement systemen (PDM) en Product Lifecycle Management systemen (PLM) kunnen hierbij enorme steun geven. Het is de houvast om adequaat engineeringwijzigingen door te voeren.

Verstoring bij Productie: klantvraag is niet uit te voeren, delen ontbreken

• Wie bepaalt de te varen koers? Er is immers een logistiek probleem en dat zal opgelost moeten worden. De sleutel van de oplossing hoeft niet per se bij sales te liggen. Vaak (met name in de maakindustrie) is de productiemedewerker zeer vindingrijk en die wil graag meedenken over een “quick-fix”. Samenwerken is vaak de oplossing om snel weer terug op koers te geraken.
• Echter een onvoorziene ingreep in productie zal ook betekenen dat er afgeweken wordt van het engineering plan. Er is dan sprake van een “As-built”. Die as-built-situatie zal wel ergens geborgd moeten worden. Immers, een niet gedocumenteerde wijziging is hét recept voor een zeer slecht lopende service afspraak. Bedenkt dus goed wat de werkelijke implicaties zijn van een “quick-fix”.
• In de praktijk zien we dat wijzigingen op verschillende plekken geborgd worden. Met een PLM is het goed mogelijk om een wijziging te borgen. Echter is het belangrijk dat dit systeem toegankelijk is voor meerdere betrokkenen. Dit geldt vaak niet voor het Enterprise Resources Planning-pakket (ERP). Hier is de toegankelijkheid meestal wel goed. Echter zijn ERP-pakketten soms minder geschikt om productdefinities te wijzigen. Denk hier vooraf goed over na.

Het ontwikkelen van de app

Enginia is een partner van Siemens en wij zijn volop bezig met de transformatie van de maakindustrie met name gericht op digitalisering. De visie die wij delen met Siemens is dat digitalisering en de toekomstige ontwikkelingen van data en AI positief beïnvloed worden door de mate van digitalisering. Eén van de pittige opgaven waar de maakindustrie voor staat is het combineren van bedrijfsprocessen en het laten aansluiten van digitale oplossingen. Vanuit het verleden wordt er met name gebruik gemaakt van beschikbare software-interfaces (API) waardoor afzonderlijke applicaties met elkaar kunnen communiceren. Dit is het domein van de programmeur en dus niet voor iedereen weggelegd. Daarnaast zijn niet voor alle applicaties API’s beschikbaar of ze sluiten niet goed aan bij de razend snelle ontwikkelingen van vandaag.

Het gevolg is dat verdere digitalisering soms moeilijk lijkt, omdat niet de gehele keten in de maakindustrie gebruik kan gaan maken van de nieuwe digitale mogelijkheden. Tenminste…dit wás het verhaal voor de introductie van Low-Code programming.

Gebruik van Low-Code

Low-Code programming is een techniek waarbij een platform veel aspecten van het coderen overneemt. Een van die Low-Code platvormen is Mendix (onderdeel van Siemens). Het voordeel van Mendix is dat er geen specialistisch personeel meer vereist is om een programma te schrijven. Het traditioneel schrijven van lijnen code is niet nodig. Hierdoor is de snelheid waarmee vervolgens een applicatie gebouwd kan worden is vele male groter. Tevens zijn de applicaties in staat om verschillende data bronnen aan elkaar te knopen. Hiermee wordt het bereik enorm groot.

Functioneel ontwerp in minder dan een dag

Ter illustratie, de applicatie die wij voor de workshop gebouwd hebben stond als functioneel concept online in minder dan een dag. De gehele applicatie was enkele dagen daarna klaar. Volledig getest en voorzien van een aantrekkelijke look and feel. Natuurlijk speelt de expertise van de programmeur een rol, dat begrijpen we goed. Echter de snelheid waarmee een functionele webapplicatie gerealiseerd kon worden was indrukwekkend.

Om een applicatie te bouwen doorloop je doorgaans een aantal stappen. Mocht je zelf nu aan de slag willen bedenk dan dat je proces er ongeveer als volgt uit zal zien:

• Beschrijf de doelstelling van de applicatie. Hiermee heeft het ontwikkelteam zicht op het einddoel.
• Beschrijf in verhalende vorm (User stories of Epics) de handelingen van de gebruikers. Dit is belangrijk omdat het ontwikkelteam hieruit functionele elementen destilleren voor de applicatie.
• Maak in Mendix een Domainmodel. Hierin worden de basis elementen aangemaakt en de relaties hiertussen bepaald.
• Via een template kan er gekozen worden hoe de gegevens getoond worden in een browser.
• Daarna volgt er “Mendix magie” die de elementen omzet naar functionele elementen geschikt voor online gebruik.

Hierna zullen een deel van bovenstaande stappen verder herhaald worden. Dit past geheel in het iteratieve karakter van het ontwikkelen van een applicatie.

Inzet in de maakindustrie

Voor bedrijven zien we legio mogelijkheden. Dat blijkt ook wel door de populariteit voor Mendix onder banken en verzekeraars. Mendix wordt met name ingezet om nieuwe processen te toetsen. De wereld van de financiële dienstverleners is sterk gedigitaliseerd in de laatste decennia. Niet alleen voor zware toepassing, maar ook vooral voor snelle concepten waarbij er een beroep gedaan wordt op de kracht van ons digitaal tijdperk, is Mendix een ware uitkomst. Gebruikersonderzoek doen op afstand, servicegegevens delen met monteurs in het veld, klanten hun asset management laten uitvoeren met mobiele telefoons, eenvoudige shopflooractiviteiten via gedeeld netwerk…Om maar eens een paar voorbeelden te noemen. De enige beperking is als het ware je eigen fantasie.