Tussen een handvol locaties van een multinational is gestructureerde informatie-uitwisseling nog te regelen via electronic data interchange en met gebruik van interfaces. Business-communicatie in een groot netwerk van bedrijven daarentegen eist een geheel nieuwe manier van logistiek denken, steunend op objectgeoriënteerdheid. ‘De nieuwe, dynamische werkstroom zal zich aanpassen aan de omstandigheden’, aldus prof. Hans Wortmann, ‘chief scientific officer’ bij Baan Institute.
De oude mrp/erp-applicaties (material/enterprise resource planning) zijn gemaakt voor de geïsoleerde onderneming met een inkoopprogramma aan de achterkant, een scheduling-applicatie in het midden, een verkoopapplicatie aan de voorkant, en naar behoefte een kwaliteitsapplicatie en andere programmatuur. Het tijdperk van die bijna altijd geïntegreerde of gekoppelde applicaties is praktisch voorbij. Conceptueel zijn de systemen nog steeds geïntegreerd, maar technisch zijn zij ontkoppeld (component based). Wat er wel verandert, is dat de applicaties niet langer ‘bedrijfs-gecentreerd’ zijn, maar gedistribueerde bedrijfsprocessen ondersteunen in een uitgebreide onderneming. In de logistieke- en IT-wereld zien we momenteel een toenemende belangstelling voor de business tussen ondernemingen en ‘sites’ (locaties). We maken daarom doorsneden van wat er tussen de ondernemingen en sites gebeurt en ontwikkelen functionaliteit voor deze communicatie. Dat proces is vier à vijf jaar geleden begonnen met het op poten zetten van de bedrijfsprocessen. We zijn gaan kijken naar het orderproces met daarvóór het contractproces, en daarna de levering en de facturering. Al die processen moeten op elkaar worden afgestemd. Wanneer je naar de toekomst kijkt, zie je dat de elektronische communicatie tussen de ondernemingen steeds belangrijker wordt."
Aan het woord is professor Hans Wortmann. Hij is hoogleraar aan de Faculteit Technologie Management van de TU Eindhoven en ‘chief scientific officer’ bij Baan Institute.
Dat communicatie steeds aan belang wint, is slechts een kant van de zaak. Twintig jaar geleden begonnen we met de computer-ondersteunde logistieke besturing in de ‘single site’. Later werd die software geschikt gemaakt voor een ‘multi site’. De voor de multi site benodigde erp-software kun je op twee manieren vormgeven; via een centraal- en via een decentraal concept. In het centrale concept stop je de database in een grote server. Om de database heen komt een grote applicatie. Een andere benadering is om iedere site zijn eigen database te geven en die met elkaar te laten praten. Het probleem bij dit tweede concept is dat er met de huidige database-technologie niet makkelijk logisch en gedistribueerd kan worden gewerkt. Er wordt vanuit gegaan dat de gebruikers gesynchroniseerd en met consistente gegevens werken. Binnen een handjevol locaties is dat nog te regelen, maar wanneer je het over honderd locaties of meer hebt, wordt dat steeds lastiger. Het is onmogelijk om grote aantallen locaties tegelijkertijd online te hebben. Daar komt bij dat de huidige erp-systemen bovendien alleen goed functioneren als alle locaties met precies dezelfde erp-versie werken. Ook dat is een onbegonnen zaak.
Communicatieproblemen
De communicatieproblemen nemen toe naarmate de complexiteit van bedrijfsprocessen binnen communicatienetwerken toeneemt. Eenvoudige handelstransacties kan men nog wel afwerken met Edi. Complexere transacties en onderhandelingsprocessen vergen heel veel functionaliteit. Dat geldt binnen de onderneming maar ook – heel sterk – tussen participanten in de leveringsketen. Een eis bij die communicatie in de huidige praktijk is dat interfaces versie-specifiek worden gemaakt. Wanneer één van de twee communicerende participanten van versie verandert, moet ook de interface veranderen. Dat wil zeggen: opnieuw bouwen. Wanneer je zowel aan de voorkant als aan de achterkant van een site te maken krijgt met honderden afnemers en leveranciers die ook nog eens tegelijkertijd willen communiceren, kom je in een onmogelijke situatie.
Er is nog een derde facet. In een fabriek van enkele honderden werknemers waren tot voor kort enkele tientallen gebruikers gelijktijdig op het systeem aangesloten. Dat beeld verandert, want we gaan nu naar een situatie waar iedereen op het informatie- en communicatiesysteem werkt. Verkopers en service-engineers kunnen bijvoorbeeld met hun laptop zowel stand-alone als aangelogd in het netwerk werken. Wanneer iemand stand-alone werkt, heeft hij een deel van de database op de laptop staan. Bij het inloggen op het netwerk wordt de database weer gesynchroniseerd. Deze manier van a-synchroon communiceren heeft verscheidene bij-effecten die door de software moeten worden opgevangen.
Het informatiesysteem wordt ook gebruikt op de productievloer, in de assemblage en door de testafdelingen. Alles communiceert met alles. De testafdeling communiceert met het systeem voor ‘computer aided testing’, maar ook met andere systemen op de werkvloeren. De plaatwerkerij hanteert een eigen, geavanceerde applicatie voor scheduling. Die applicatie is weer gekoppeld aan de besturingssystemen van de stansmachines. Tegelijkertijd werkt de verspanende afdeling nog met stand-alone CNC-besturingen en verkeert deze juist in een overgangssituatie van de oude naar een nieuwe kennisbank met verspaningsgegevens. Al die activiteitengroepen hebben hun eigen applicaties die in toenemende mate met andere applicaties worden geïntegreerd. Het is onhandig wanneer deze applicaties vanaf een centrale database werken. In de praktijk zie je dan ook dat ondernemingen steeds meer toegaan naar een gedecentraliseerd concept, waarbij de gebruikers een eigen hardware-infrastructuur hebben.
Gedecentraliseerde architectuur
In de oude mrp-wereld kon de onderneming of vestiging goed uit de voeten met een stand-alone concept. Dat oude mrp-concept is uitgebreid naar een ‘multi site’ erp-concept. Wanneer je datzelfde concept wilt uitbreiden naar een toeleveringsketen met veel autonome partijen, beland je op een doodlopende weg. Baan koos daarom altijd voor de decentrale oplossing met een client/server-architectuur op basis van een ’thin client’. Dat is de oplossing met een gui en met een klein deel van de applicatie en de data bij de client. Die architectuur maakt het mogelijk om stukken software apart te ontwikkelen en tot applicaties te monteren. Doel is om gebruikers zowel binnen als buiten de onderneming flexibel in multi-user-systemen te kunnen koppelen. Daarbij is te verwachten dat men in de toekomst in hoge mate via het beeldscherm communiceert. Niet iedereen zal constant op het systeem zijn aangelogd. Sommige onderdelen van het systeem zijn wegens onderhoud of installatie van nieuwe versies ook niet altijd operationeel.
De conclusie is dat het homogene platform verleden tijd is. In de toekomst wordt met in stukjes geknipte en vervolgens aan elkaar gekoppelde systemen gewerkt. Zo’n stukje software heet bij Baan een ‘business component’.
De nieuwe systemen van Baan zien er niet meer uit als de klassieke client/server-systemen. Zij krijgen een ander karakter. Dat wil niet zeggen dat de klassieke client/serversystemen verdwijnen; zij blijven wel bestaan. De software wordt echter ingepakt in een ander stukje software waardoor deze zich aan de buitenkant gedraagt alsof hij is opgenomen in een net van ‘semantische interfaces’. Hierdoor kan datgene wat aan een kant van een component binnenkomt, er aan de andere kant weer uitgaan. De componenten regelen hun eigen communicatie.
Onderdeel van de componenten is de bijbehorende logische database met gegevens over de toestand van de componenten. De databases van de verschillende componenten moeten af en toe gesynchroniseerd worden. Catalogusinformatie bijvoorbeeld moet op het moment van gebruik bij de afnemer gelijk zijn aan die van de leverancier. Wanneer de afnemer niet over de juiste catalogus-informatie beschikt is Edi of elke andere vorm van verkoop op basis van catalogus-informatie onmogelijk.
Taaknavigatoren
Naast de ‘semantische’ communicatie is er een ander soort communicatie nodig: ‘werkstroom communicatie’. Iedere component heeft zijn eigen werkstroom. De werkstroomcommunicatie koppelt die werkstromen en maakt deze opdracht specifiek. De nieuwe werkstroom is dynamisch. De informatie loopt door de werkstromen van de verschillende ‘business objects’ heen en neemt op de juiste plaatsen de nodige beslissingen. Die zijn bepalend voor de te nemen route.
Ter verduidelijking een voorbeeld. De verkoop buitendienst kan een order boeken. Voordat definitief wordt geboekt, is eerst de nodige informatie nodig over de gevraagde partij. Verkoop buitendienst plaatst daarom een tijdelijke verkooporder in het ‘verkoopsysteem’. Dat vraagt nu aan diverse productiecentra een opgaaf van prijs en levertijd. Het kan zijn dat een productiecentrum de vraag doorkoppelt naar een productiesysteem van een collega. Het verkoopsysteem houdt in de gaten dat er een antwoord moet binnenkomen, selecteert uit de eventuele meerdere antwoorden het beste en geeft deze weer door aan verkoop buitendienst. Het kan zijn dat er helemaal geen antwoord komt, of dat er beslissingen nodig zijn omdat de ene aanbieder sneller en duurder is dan de ander. Voor het beantwoorden van de vraag zijn ’taaknavigatoren’ nodig. Zij worden via ‘mobile agents’ naar de plaats van bestemming geloodst en stellen daar de vraag. Wanneer er beslissingen moeten worden genomen, is het noodzakelijk om de vereiste intelligentie in deze ‘agents’ in te bouwen.
Ook legacy-systemen kunnen tot objecten worden getransformeerd. Om deze systemen wordt dan een stukje software gebouwd voor het beantwoorden van de vraag, voor zover het systeem dat toelaat. De sturende ‘wat als’-problematiek ontbreekt in deze oude systemen veelal. Het antwoord is recht-toe-recht-aan. In een modern business-systeem wordt doorgevraagd op een voor het object hanteerbare manier. De programmatuur voor het doorvragen is meegenomen door de mobiele ‘agent’. Die neemt ook informatie mee als ‘wie ben ik, waar kom ik vandaan en waar moet ik naar terug’. Daardoor wordt het mogelijk het antwoord op de boodschap naar de juiste plaats terug te brengen.
De ’task navigator’ heeft dus een map bij zich met de opdracht, software en eventueel kennis die het mogelijk maakt om het volgende ‘business object’ aan het werk te zetten. De software is ingepakt in een stukje Java. Aangekomen op de plaats van bestemming moet de software worden uitgepakt en zijn datastructuur blootgeven. Via Corba of Dcom-standaarden is de software toegankelijk te maken voor het ontvangende object. Bij het versturen van de software moet de map ook door allerlei firewalls heen. De doorgang is te regelen via allerlei wachtwoorden. Die oplossing is complex. Er kan ook een virusachtige software worden ontwikkeld die zelf in staat is de boodschap terug te sturen.
Een laatste aspect van business-communicatie. De navigator moet ook kunnen nadenken over de voltooiing van de opdracht. Bij de terugmelding aan de handelsagent kan het best zo zijn, dat diens agentschap een paar dagen gesloten is vanwege een paasweekend. Verder moet de navigator zich afvragen of er meerdere bronnen moeten worden geïnformeerd.
Nieuwe ICT-architectuur
De nieuwe bedrijfsfuncties moeten in een groot aantal nieuwe concepten worden vastgelegd. Het vergt een andere manier van denken, die meer is dan object-oriëntatie. Object-oriëntatie is een manier van software ontwikkelen waarbij de scheiding tussen data en programmatuur veel minder strikt is dan bij de traditionele manier van software-ontwikkeling. Data en programmatuur worden hier zoveel mogelijk bij elkaar gehouden. In de nieuwe bedrijfsprocessen ligt de nadruk op communicatie en autonomie van de werkstroom. Die twee aspecten, gecombineerd met object-oriëntatie leiden tot een compleet nieuwe ICT-architectuur.
Binnen die architectuur moeten nog veel problemen worden opgelost, zoals integratie-mechanismen. Zowel de bedrijfsprocessen als de applicaties en data moeten worden gemodelleerd. Daarbij gaat het niet alleen om de bedrijfsprocessen van Baan, maar ook om die van derden. Verspreide, bij elkaar horende data moeten bij elkaar gebracht kunnen worden en data moeten gesynchroniseerd kunnen worden. Daarvoor zijn standaarden als Corba en Dcom beschikbaar, maar ze voldoen niet. Zij zijn een voorwaarde voor een eerste stap om open werkstroomconcepten te realiseren. Baan zit midden in dat proces.
De eerste versie van tools voor het bouwen van de objecten is gereed. Er is flink geïnvesteerd in gedistribueerde datatechnologie onder Java. Een flink deel van deze technologie is in de ‘sales business objecten’ terecht gekomen. De verwachting is dat er nog ongeveer één jaar nodig is om de eerste volledige objectgeoriënteerde versie onder dit concept te kunnen uitbrengen. Het concept wordt uitgewerkt onder de naam Baan Series. In dit concept gaan de huidige erp-applicaties van Baan niet op de schroothoop. Om deze software worden schillen gebouwd waardoor zij in het nieuwe concept passen. Bestaande software en nieuwe objecten zijn zo te integreren. Ook de tools voor het maken van deze schillen zijn klaar. De applicatieprogrammeur kan dus aan het werk.
Effecten op de goederenstroom
De hamvraag is natuurlijk wat voor effecten deze nieuwe bedrijfsprocessen op de goederenstroom zullen hebben. Ook daarop geeft Wortmann aan de hand van een paar voorbeelden een antwoord. "Stel je voor dat twee zandwagens elkaar tegenkomen. De een brengt zand van a naar b en de andere van ‘bijna b’ naar ‘bijna a’. Bij zo’n transport is er iets mis, maar nu weten we het niet. Zulke situaties zijn in de toekomst makkelijk te herkennen. Dan kan zand worden verplaatst van a naar bijna a en van b naar bijna b omdat beide transporteurs zijn geïnformeerd.
Een ander voorbeeld. Nu bestelt de inkoper 100 artikelen terwijl de leverancier er maar 95 in voorraad heeft. Die leverancier gaat zich vervolgens in allerlei bochten wringen. Als de inkoper had geweten dat er maar 95 in voorraad waren, had hij ook wel met deze hoeveelheid kunnen leven. En wat te denken van die ene component, die nu van de andere kant van de wereld komt terwijl hij misschien 50 km verder op voorraad ligt. In de toekomst kunnen situaties in een flits worden afgetast, waar in het verleden uren of dagen telefoneren en faxen voor nodig waren, of waar we helemaal geen weet van hadden", aldus Wortmann.
Manuele administratieve processen verdwijnen geleidelijk. Administratieve doorlooptijden door geautomatiseerde systemen bestaan nauwelijks meer. Klussen met routine-kennis worden geautomatiseerd opgelost. Alleen voor de echte calamiteiten springt de mens in.
De lol van mrp is een beetje vooruit te kunnen kijken. ‘Windowing in de future’ gebeurt nu via systemen met starre leveringstijden en net zulke starre stuklijsten. In het bedrijfsproces van de toekomst verdwijnt die starheid omdat de werkstroom zich aanpast aan de omstandigheden. In het verleden hadden we iteratieve systemen waarbij de volgende beslissing uit de voorgaande volgde. Door de nieuwe tweeweg-communicatie gaan systemen in de nabije toekomst met elkaar onderhandelen op basis van zwak iteratieve algoritmen. Het wordt handelen in het voorbijgaan, een techniek die we als mens al lang beheersen en die nu ingebouwd wordt in onze bedrijfsprocessen.
Cees van Heijkoop, freelance medewerker Computable
