Versnel interne app-ontwikkeling met low-code- en no-code-platforms

Uitgaande van de premisse dat de beste oplossingen voor problemen vaak vanuit de werkvloer komen, nemen fabrikanten low-code- en no-code-programmeerplatforms in gebruik. Hierdoor kunnen werknemers zelf maatwerk-apps bouwen om hun problemen op te lossen.

De opkomst van deze platforms wordt gedreven door de behoefte aan apps die niet in de standaard app-stores te vinden zijn, gecombineerd met een tekort aan goede programmeurs, overbelaste IT-afdelingen en externe bureaus, de hoge kosten en lange ontwikkeltijd van traditionele applicaties, en de wisselende kwaliteit van de resultaten.

Gartner Inc., een wereldwijd onderzoek- en adviesbureau voor IT en andere sectoren, voorspelde dat low-code-applicatieontwikkeling in 2024 meer dan 65 procent van alle app-ontwikkelactiviteit zal uitmaken.

Populaire DIY-apps in de productie omvatten garantiebeheer, supply-chain-zichtbaarheid, voorraadtracing, rapportage aan regelgevende instanties, logistiek, point-of-sale en projectwerkstromen.

De productiesector is uniek geschikt voor DIY maatwerk-apps vanwege de technische opleiding van de werknemers in ingenieursconcepten en methodologieën. Sommige ingenieurs hebben al geëxperimenteerd met programmeertalen om hun werk te automatiseren of analyses uit te voeren, dus ze zijn niet geheel onbekend met softwareontwikkeling; het is alleen niet hun primaire rol.

“Wat fascinerend is aan deze mensen, is dat ze in dit soort platforms extreem effectief zijn,” zegt Mike Schiraldi, solution architect team lead bij Mendix in Boston. “Ze worden niet tegengehouden door de esoterische syntax van een bepaalde taal en staan uniek in hun schoenen om een zakelijk probleem te begrijpen, een gat in het proces te ontdekken en te weten hoe het op te lossen.” Mendix werd in 2018 overgenomen door Siemens.

Werknemers als ontwikkelaars

Bij Flowserve in Irving, Texas, een fabrikant van vloeistofbeheersoplossingen voor de olie- en gasindustrie, hebben werknemers een low-code-platform van Appian (Tysons, Va.) gebruikt om apps te maken voor diverse doeleinden, waaronder een servicecentrum-portaal voor het pompreparatieproces. Met de app maakt een werknemer een orderaanmelding en gebruikt deze om alle benodigde gerelateerde informatie vast te leggen en te beheren: inspectie, offerte, coördinatie van arbeid en onderdelen, review en goedkeuring, en uiteindelijk verzending van de factuur.

Voor Flowserve is er geen standaardsoftware beschikbaar, aldus Malcolm Ross, deputy CTO en vicepresident productstrategie bij Appian.

“Er is software voor inventarisbeheer en HR-beheer, maar niets dat de twee combineert—de arbeid en de onderdelen—samen,” zegt Ross.

Low-code-platforms stellen zakelijke gebruikers als de werknemers bij Flowserve in staat om maatoplossingen te ontwikkelen die processen helpen automatiseren en organiseren.

“Elke low-code-gebruiker die een maatapplicatie ontwikkelt, heeft intieme kennis van het probleem en proces waar de app op gericht is,” zegt Tejas Gadhia, head evangelist voor platformontwikkeling bij Zoho Corp. in Pleasanton, Californië. “Dit is het kernvoordeel van low-code-platforms: ze houden de ontwikkeling in huis, in plaats dat gebruikers hun behoeften moeten uitleggen aan een IT-team of externe ontwikkelaar.”

Naast het mogelijk maken van app-ontwikkeling, staan de platforms ook toe om updates door te voeren naarmate processen en eisen evolueren op basis van gebruikersfeedback. Leveranciers verschillen in of apps intern in een enterprise-portefeuille of in een commerciële app-store worden opgeslagen, maar updates kunnen via een link in SMS of e-mail worden uitgepushed.

Agile app-ontwikkeling

“Dit blijkt het belangrijkste te zijn als je echt agile en innovatieve app-ontwikkeling wilt doen: zet het in handen van gebruikers, haal hun feedback en producer een iteratie,” zegt Praveen Seshadri, CEO van AppSheet in Seattle. “Echt, het aantal iteraties dat je kunt doen met kwalitatieve feedback is wat je app laat uitgroeien tot iets nuttigs en succesvol voor je gebruikers. De snelheid van iteraties drijft de succes.”

Terwijl het ontwikkelen en gebruiken van een app an zich al waardevol is omdat het de productiviteit drijft, realiseren fabrikanten op een gegeven moment dat er extra waarde zit in het platform door veel apps te bouwen. Zodra ze veel toepassingen bouwen, wordt die inzicht vaak gedreven door het analyseteam dat ziet dat de apps niet alleen productiviteit drijven, maar ook data verzamelen die gebruikt kan worden door ERP-, MES- of PLM-software van een fabriek.

“Dit is als goud,” zegt Seshadri. “Het geeft inzicht in al die dingen waar we eerder geen inzicht in hadden.”

Met die data kunnen fabrieken analyseren welke delen van hun productielijn beter presteren en waar meer problemen zitten. Ze kunnen kansen identificeren.

“Dus het drijft strategisch denken,” zegt hij. “Hoe kan dit ons fundamenteel concurrerender maken?”

Efficiency case study

Elijah Magrane, operations director bij Tutti Gourmet, een fabrikant van gezondere snacks in Hudson, Quebec, Canada, begon ongeveer 16 maanden geleden AppSheet te gebruiken voor voorraadtelling.

De fabriek deed voorraadtelling eerst op basis van fysieke tellingen die handmatig in spreadsheets werden ingevoerd. Fouten waren gang en gae en dingen werden over het hoofd gezien. Met het platform kon Magrane een voorraad-app maken die de formule en berekeningen bevat die gebruikelijk zijn in spreadsheetprogramma's, en sindsdien barcodes en QR-codes toegevoegd, zodat tellingen geautomatiseerd zijn.

“Het implementeren van een barcode-systeem via AppSheet, samen met geautomatiseerde heraanvullmeldingen, heeft onze efficiëntie verhoogd en gewaarborgd dat we altijd in staat zijn orders te vervullen en op capaciteit te produceren,” zegt Magrane.

De apps die Magrane heeft gemaakt—ongeveer 40 in totaal—zijn handig voor dagelijkse operaties zoals het bijhouden van werknemersuren, lijsten met goedgekeurde leveranciers, inspectie-checklisten afwerken, magazijnvoorraad beheren, productdistributie traceren, en meer.

“Eerlijk gezegd, waar ik nu sta heb ik een volledig functionerend ERP met AppSheet,” zegt hij (zie grafiek op pagina 63).

Omdat het platform in de cloud draait, kan Magranes baas voorraad-, projectmanagement- en R&D-apps benaderen als hij op pad is. Bij het bedrijf kan de nieuwe salesmanager zien hoe lang het geleden is dat een winkel een levering heeft ontvangen en zo nodig een verkoopgesprek voeren.

“Low-code is tot code wat een prefabwoning is tot een huis dat vanaf nul wordt gebouwd.”

En wanneer het bedrijf geauditeerd wordt op traceerbaarheid, kan Magrane gemakkelijk informatie opvragen in plaats van door binders te bladeren.

“Ons boekhoudsysteem heeft geen traceerbaarheid voor eindproducten,” zegt Magrane. “Vóór AppSheet noteerden we handmatig in Excel. Dat nam een enorme hoeveelheid tijd in beslag en de foutenmarge was hoog. Sinds we AppSheet gebruiken, is de traceerbaarheidsworkflow met meer dan half ingekort en zijn fouten bijna niet meer aanwezig.”

Updatability is cruciaal

De grootste differentiator onder DIY-app-platforms is of de tech-onderlegde maker eigen code kan toevoegen.

Over het algemeen bieden no-code-oplossingen 100 procent point-and-click-ontwikkeling en richten zich direct op zakelijke gebruikers en mensen zonder tot minimale programmeerkennis. De meeste van deze tools zijn gericht op het vervangen of verbeteren van spreadsheets. AppSheet is een no-code-platform.

Low-code-tools bieden ook voornamelijk point-and-click-configuratie, maar voorzien in geavanceerde mogelijkheden via scripttaal om complexe bedrijfslogica uit te voeren. Deze tools richten zich op gebruikers met iets meer technische kennis, maar nog niet op developerniveau. Appian, Mendix en Zoho Creator zijn low-code-platforms.

“Low-code is tot code wat een prefabwoning is tot een huis dat vanaf nul wordt gebouwd,” zegt Jon Scolamiero, manager architectuur en governance bij Mendix. “No-code is in essentie een gefabriceerde ‘double-wide’.”

No-code en low-code zijn niet de enigste differentiators. Beveiliging verschilt per leverancier.

“Het is altijd een goed idee om de beveiligingspagina van een leverancier te controleren om hun beleid en procedures voor datahantering te zien,” zegt Gadhia.

Evaluators kunnen leveranciers vragen om details over certificeringen zoals ISO 27001, die zich richt op kwaliteit en continue verbetering voor informatiebeveiligingssystemen, en SOC 2 Type II, een standaard voor controles die direct verband houden met beveiliging, beschikbaarheid, verwerkingsintegriteit, vertrouwelijkheid en privacy bij een organisatie die software as a service levert.

Beveiliging is maar één deel—het begrijpen van het privacybeleid van een leverancier is even belangrijk. Klanten moeten ervoor zorgen dat hun applicatie, data en intellectuele eigendom van de app aan hen toebehoren, niet aan de leverancier, aldus Gadhia. Ze moeten ook ervoor zorgen dat hun informatie niet verkocht of gedeeld kan worden met derden.

De kernwaardepropositie van low-code en no-code is niet alleen de samenstelling van de apps, maar ook het lopende onderhoud en upgrades in de levenscycli van het platform als de apps op mobiele apparaten of via het web worden gebruikt, zegt Ross. Dat is waar mensen vaak problemen mee ondervinden bij enterprise-software.

“Het is het idee van: eenmaal gebouwd, is alles prima,” zegt hij. “Maar het feit dat het werkt met een mobiel besturingssysteem vandaag, betekent niet dat het volgend jaar nog werkt als iOS 13, 14 of 15 uitkomt.”

Ross geeft een vergelijkbare waarschuwing voor web-apps. Webstandaarden evolueren dagelijks, en het feit dat een app vandaag werkt met Edge, Safari, Bing of Chrome, garandeert niet dat het morgen nog werkt. Een belangrijk aspect om te verkennen met de leverancier van het low-code-platform is of het de software levert die de onderhoudsvereisten afschermt en toekomstbestendigheid in de platformcapaciteiten heeft ingebouwd.

“Als analogie vraag ik mensen vaak: ‘Welke versie van Google gebruik je?’”, zegt Ross. “Google update hun zoekmenu en webbrowser letterlijk elke dag, maar we denken er niet in termen van versies over, we denken er als een service over. Dat is waar we naartoe willen gaan als het aankomt op hoe we deze platformen als service consumeren.”

Scolamiero zegt dat platformkoppers ook moeten vragen of het platform cloud-native is, wat betekent dat het voldoet aan kernprincipes en architecturen die het niet alleen in één cloud laten bestaan, maar ook processen en procedures in elke cloud en on-premise laten uitvoeren en integreren met al het bovenstaande.

“We hebben een hybride wereld waar software intern draait in zeer veilige systemen zonder internettoegang, maar ook in de bredere cloud en het internet moet uitvoeren,” zegt hij.

Uiteindelijk is de belangrijkste vraag bij het kiezen van een platform of het helpt om zakelijke problemen op te lossen en productiviteit en innovatie ontgrendelen, aldus Seshadri. Elke zakelijke eenheid staat onder druk om te innoveren en te verbeteren, of het nu gaat om inspectie op de werkvloer of voorraadtelling in een magazijn die geautomatiseerd moet worden.

“Stel je bouwt een app om apparatuur op de fabrieksvloer te inspecteren,” zegt Seshadri. “Het haalt data op over welke apparatuur je hebt uit je ERP en vangt inspectiegegevens op. Als er schade is, kun je een foto maken en iemand notificeren om de reparatie uit te voeren. Elke ochtend heeft management een rapport nodig van wat er beschadigd is.”