De Toekomst van Industry 4.0 en de Unified Namespace met Denis Gontcharov
Luke: Hallo en welkom terug
bij de Metaal Connect podcast.
Mijn naam is Luke van Enkhuizen en
in deze show gaan we in op ontwerpen
en realiseren van slimme fabrieken
voor de metaalverwerkende industrie.
Vandaag is Denis Gontcharov bij ons te
gast om met ons te praten over de toekomst
van Industry 4.0, de Unified Namespace
en nog veel meer interessante topics die
wij graag met jullie willen bespreken.
Allereerst een warm welkom
naar Denis, welkom bij de show.
Denis: Dag Luke, hartelijk dank
voor de uitnodiging in Wenen.
Luke: Ja, super.
Ja inderdaad, voor het eerst zijn
we nu live in dezelfde kamer.
We gaan eens proberen met de podcast ook
wat meer in persoon te ontmoeten daarbij.
En voor de luisteraars die je nog niet
kennen, kun jij misschien jezelf even
kort voorstellen wat je doet, wat je
zelf aanwezig bent in je dagelijks leven?
Denis: Ja, natuurlijk.
Dus mijn naam is Denis Goncharov.
In het dagelijks leven ben ik bezig
als zelfstandige system integrator,
voornamelijk voor de aluminiumindustrie.
Luke: Ja, super.
Voor de mensen die niet precies begrijpen
wat System Integrator inhoudt, kan
je dat misschien wat het inhoudt?
Denis: Mijn dagelijkse activiteiten
bestaan voornamelijk uit het Aan elkaar
koppelen van verschillende systemen.
Dat gaat voornamelijk van de MES
tot SCADA, van sensoren tot de ERP.
De uitdaging is om een systeemarchitectuur
te ontwikkelen waarin alle individuele
systemen ...mooi met elkaar communiceren.
Luke: Dus ja, een van de onderwerpen
voor vandaag is de Unified Namespace.
De bekende Walker Reynolds op
YouTube praat er regelmatig over.
Kun je misschien de luisteraars uitleggen
hoe jij bent gekomen in je huidige rol...
...en hoe je daarmee in
aanraking bent gekomen?
Wat je ervaringen daarmee zijn tot nu toe?
Denis: Inderdaad, hoewel ik
eigenlijk nu vooral in IT werk,
was het niet mijn vertrekpunt.
Ik heb namelijk een diploma als
buurtelijk ingenieur in de materiaalkunde.
Dit wil zeggen dat ik altijd heel
erg aan de chemie-slash-fysica kant
van de metaalkunde heb gewerkt.
Het is pas na mijn eerste practicum
dat ik in heel dat IT en vooral
datengebeuren ben verzeild geraakt.
Uiteindelijk over de loop van mijn
carrière, Heb ik altijd een tweesplitsing
gevolgd tussen langs de ene kant data
en de andere kant de metaalkunnen
die ik nooit echt heb losgelaten.
En ik vind dat in de huidige tijd,
zeker met de opkomst van de UNS, er
zich heel mooie mogelijkheden voordoen
voor het combineren van die twee velden.
Luke: Ja, super.
Super interessant.
Dus laten we even dan
beginnen met de basisuitleg.
Wat is het verschil tussen wat
traditioneel wordt gedaan in de industrie
en wat is dan de Unified Namespace
voor wie dit concept nog niet kennen?
Denis: Ja, dus voor de uitleg van de
UNS zal ik graag vertrekken van het
probleem dat we eigenlijk oplossen.
Met andere woorden, de vraag van
Waarom is een UNS überhaupt nodig?
Als we kijken naar data-analyse willen
we vaak een totaalbeeld van onze fabriek.
We willen weten wat de data is
van de sensoren van de machine,
temperatuur en vibraties.
En deze willen we graag
koppelen aan producten.
Ik werk nu aan dit onderdeel.
Nu de uitdaging is dat dit
eigenlijk twee datastromen zijn.
Van heel verschillende niveaus.
En het was historisch altijd een
hele uitdaging om die verschillende
stromen aan elkaar te kunnen koppelen.
En dit is precies waar de
UNS in het plaatje komt.
De UNS wordt vrij vertaald je unieke bron
van real-time data voor heel je business.
Luke: Een
Denis: bron voor real-time
data van de hele business.
Klopt.
Dus we gaan niet enkel kijken
naar data van je plant floor,
dus van je fabrieksvloer.
We gaan ook kijken naar data
rond HR of zelfs finance.
Het idee is effectief dat alle systemen
met elkaar gaan communiceren via dat
centraal onderdeel dat men de UNS noemt.
Luke: Right, oké, maar historisch
gezien is dit misschien geen
nieuwe wens of eis van de meeste
fabrieken in de metaalindustrie.
Ze willen natuurlijk altijd
die informatie al zien.
Een veel toegepaste techniek is natuurlijk
het kiezen van een nieuw ERP systeem.
Wordt vaak beloofd of er worden diverse
integraties gemaakt tussen al die systemen
om dan één bron van waarheid te creëren.
Al dan niet in een ERP of in een
dashboard die ze genereren met een
of andere business intelligence tool.
Maar waarom?
Is dat niet de oplossing,
Denis: volgens jou?
Ja, dat is een hele terechte
opmerking, inderdaad.
Het idee om één centraal punt
te hebben is zeker niet nieuw.
Dus je kan effectief gaan argumenteren,
waarom niet gewoon de ERP?
Nu, de uitdaging is dat, stel
als we dat wel zouden doen,
dan zouden alle data-stromen in
de ERP moeten kunnen vloeien.
In de praktijk is dit heel moeilijk, want
dan ga je eigenlijk via de weg van de
zogenoemde point-to-point integrations.
Dat wil zeggen dat als je je automation
stack, dus je piramide voorstelt,
ga je van helemaal beneden, je
sensoren, je HMIs, de data eigenlijk
naar boven via SCADA, via MES,
naar de ERP moeten doorsluizen.
Dit wil zeggen dat je data een
hele lange, moeilijke weg aflegt.
Door elk systeem van je bedrijf.
En het is vanuit die problematiek
dat we hebben gezien dat deze
weg gewoon te moeilijk is.
We moeten de data uit elk systeem
halen naar een ander extern systeem.
En vandaar dat we zijn
gaan werken met een UNS.
Luke: Right.
Ja, ik denk dat het ook een belangrijk
bijkomende uitdaging is voor veel
fabrieken, vooral als je meerdere locaties
hebt, dat je een diversiteit hebt aan
systemen en aan merken van systemen.
Je hebt misschien verschillende
ERP-systemen, ook verschillende
productie-uitvoerende systemen.
Wat ik bij de metaalindustrie,
waar ik in actief ben, veel zie,
is dat ze bijvoorbeeld ook voor
de shop for control voor echt het
assembleren van eindproducten...
...aparte apps hebben, eigen software.
Dus je krijgt inderdaad heel
veel verschillende databronnen.
Maar wat is dan echt
het probleem erachter...
...waarom je niet gewoon die dingen
met elkaar allemaal kunt verbinden?
Is dat vooral een kostenprobleem
of een tijdsprobleem...
...of een technische uitdaging of is
er gewoon tekortkoming informatie?
Wat zijn de redenen dat je niet zomaar...
...al die apps gewoon
kunt verbinden met elkaar?
Denis: Het is een combinatie
van al deze dingen...
Langs de ene kant heb je inderdaad het
probleem dat het gewoon te moeilijk is.
Je hebt, zoals je zelf zegt,
heel veel verschillende systemen.
Als je die met elkaar zou kunnen
verbinden, dat is technisch mogelijk.
Maar je hebt voor elke
verbinding een expert nodig.
Die expert heeft tijd nodig.
Die tijd kost geld.
Langs de andere kant heb je ook de
opmerking gemaakt over controle.
De systemen die wij vandaag hebben, zijn
ontwikkeld voor het Sturen van je proces.
Dat is iets wat we zeker
niet willen aantasten.
Dus het idee dat we een hele
nieuwe fabriek gaan bouwen
vanaf nul is niet realistisch.
Het idee, de filosofie van de UNS was
van kijk, we hebben de automation stack
van de ERP tot de sensoren, die doen
hun werk goed, namelijk procescontrole.
Voor het volgende deel van het verhaal,
dus echt de analytics, de data-analyse,
zijn die steeds echter niet voldoende.
En daarom zijn we gaan kijken
naar een nieuwe oplossing.
Nu, de oplossing was het verzamelen van
data en het vinden van, het combineren van
die verschillende wegen was te tijdrovend.
Dat hebben we in de praktijk gemerkt dat
bij elk project dat we hebben gedaan,
het point-to-point integreren van die
verschillende systemen naar de MES of
naar de ERP was gewoonweg te moeilijk.
Het was niet financieel rendabel.
Luke: Ja, oké.
Ik denk dat ik uit mijn ervaring ook
wel herken inderdaad dat er zeker
te kokkoming zit aan point-to-point.
Ik geloof ook dat dat eindig is.
Maar dan blijft nog steeds natuurlijk
het argument van waarom niet
gewoon een ERP die zeg maar...
Het centrale bron is van deze informatie.
Er zijn natuurlijk verschillende
discussies over veel ERP bedrijven en
vooral platform ERP aanbieders die meer
dan alleen ERP hebben die zeggen van neem
gewoon een best-of suite, neem alles van
één en dan heb je het hele probleem niet.
Hoe zou jij daarop
reageren in die discussie?
Denis: Ik zou vooral kijken naar
de data op een heel laag niveau.
De vraag is, ik kijk naar data van de ERP.
Dat zijn vooral productieorders neem
ik aan, bestellingen van klanten.
Dus dat is data die zeg maar
goed Geaard is voor een databank,
een normale rationele databank.
Maar als je op een dieper niveau
kijkt naar de MES of vooral SCADA
en sensordata, daar werk je echt
met tijdrijden, tijdreeksen.
En vaak met enorme hoeveelheden data,
die met een heel hoge frequentie.
Het is namelijk zo, hoe dieper je
afdaalt naar de machines, hoe dichter je
bij de machines komt, hoe meer data je
hebt en hoe snel deze data binnenkomt.
En dan is mijn vraag aan de
ontwikkelaar van de NLP-systeem.
Zijn jouw systemen wel daarop voorzien
om met zulke volumes te werken?
Luke: Right, dus de volumes
en de frequentie van data.
Ik herken het eigenlijk wel, want
als je bijvoorbeeld kijkt naar
een fabriek waar ik veel actief in
ben, dat zijn lasersnijbedrijven,
die maken eindproducten, ook soms
toelevering, soms één, maar soms
ook tientallen lasermachines en
inderdaad al die machines die zijn
continu Genereren data op de seconde
eigenlijk, met alle meldingen en zo.
En ik denk dat het grote verschil
is dat als je het hebt over
punt-na-punt integraties, dat
je alleen maar de samenvattingen
krijgt denk ik, over het algemeen.
Of dit is de order, dit is de transactie.
Maar wat we volgens mij hier nu bespreken
is eigenlijk echt alle data te nemen.
Niet discrimineren op wat
voor data het is, toch?
Is dat het grote verschil?
Denis: Dat klopt, dus niet
enkel data volume moet ook.
Een andere kant van de medaille, van
het probleem, is dat enerzijds het
verzamelen van data is het eerste werk.
De vraag die er nog bijkomt is hoe je
je data gaat organiseren in je bron.
Het moet namelijk niet enkel daar
zijn, het moet ook leesbaar zijn
voor een mens en een machine.
Mensen moeten begrijpen hoe je
die data kunt interpreteren.
En de vraag is of een ERP wel
daarvoor de geschikte databank is.
Een ERP heeft zijn taak, het
organiseren van je werkorders en
het betalen van je werkorders naar
productieorders, van klantorders.
Dat doet hij goed.
Maar waarom zou je dit systeem met een
extra enorme uitgave van dataverzameling,
maar ook dataorganisatie, opzadelen?
Luke: Ja, oké, dus als ik het even kan
resumeren wat we nu besproken hebben,
dus de Unified Namespace is dus een
manier hoe jij de data van je hele
organisatie en alle structuren samenvat,
daarmee, nou ja niet samenvat, je slaat
het op, maar hoe werkt dat opslaan dan?
Waar slaat de UNS zijn data in op?
Wat kun je dat uitleggen?
Wat moeten ze daarbij voorstellen?
Denis: Klopt, ik zou de UNS het
beste zien als een Een soort van
spin centraal in je spinnenweb.
Een bijkomend voordeel van deze
architectuur, dat ook wel eens de
event-driven architecture wordt genoemd,
is dat alle systemen onafhankelijk zijn.
Wat wil ik hiermee zeggen?
Daarmee bedoel ik, van stel als je
een point-to-point integratie hebt,
leg je data een hele weg af door de
verschillende systemen en moeten ook
alle systemen weten dat die weg bestaat.
Bij een spin-wrap model van
de UNS is dat echter anders.
Daar moeten de onafhankelijke systemen,
of het nu een sensor is, of een MES
of een ERP, zij moeten niet weten
wat er nog bestaat in het netwerk.
De enigste subject met welke ze
moeten communiceren is de UNS.
En dat versimpelt je netwerk enorm.
Stel, als je later een nieuwe ERP of
een tweede MES zou willen integreren
of een nieuwe machine, Moet je
enkel één nieuwe verbinding maken
van dat nieuwe systeem met je UNS,
in plaats van terug een hele weg te
programmeren door die automation stack.
Dat is nog een derde punt die ik wil
aanhalen over de noodzaak van een UNS.
Luke: Oké.
Bij de UNS wordt ook het woord historian
wel genoemd in de vakterminologie.
En wat is een historian?
En wat is de rol daarbij in de UNS?
Denis: Klopt, dus daarmee krijg
ik weer druk op je vraag, Impeki,
die ik een beetje heb ontweken.
Van waar slaat de data, waar wordt
data nu opgeslagen in je UNS?
Dat is een heel terechte opmerking.
In feite, je UNS slaat
aan zich geen data op.
Je UNS is een real-time beeld,
snapshot, van je hele fabriek.
Dat wil zeggen dat je in principe, bij
wijze van spreken, Enkel de laatste
seconde hebt van alle data van je fabriek.
Dus stel als je een systeem hebt dat die
real-time data nodig hebt, verbind je met
de UNS en heb je die data in echt tijd.
Nu, wat met de historische data?
En daarom haal je waarschijnlijk
het punt historieën naar boven.
Gaat de historieën verdwijnen?
Nee.
De rol van de historieën wordt de
opslag van de real-time data van de UNS.
Om het te vereenvoudigen, de data
van alle systemen komt binnen in de
spin van je spinweb, de UNS, leeft
daar voor een seconde, real time,
en wordt dan meteen weggeschreven in
de historian voor long-term storage.
Nu, de historian kan voor jou
oftewel enkel in je fabriek leven,
maar kan evengoed een data lake of
data warehouse zijn in de cloud.
Luke: Oké, twee nieuwe termen
hier, data warehouse en data
lake, wat zijn de verschillen?
Denis: Klopt, nu deze twee termen
zijn echt ontstaan uit de wereld
van data engineering en big data.
Om het heel simpel te houden,
het zijn gewoon databanken.
Zowel de historian als een data
lake als een data warehouse zijn
voor onze discussie drie databanken.
Ze zijn op een andere
manier gestructureerd.
Dat heeft te maken met hoe je data wilt
opslaggen en hoe je data wilt lezen.
Maar wij kunnen hen gewoon
beschouwen als drie databanken.
Luke: Oké, en waarom wil je dan
per se de Unified Namespace of
een UNS hebben in plaats van
een Data Warehouse of Data Lake?
Denis: Wel, klassiek zijn Data
Lakes en Data Warehouses niet
lokaal, maar lopen in de cloud.
Je hebt eigenlijk, het probleem is,
omdat data heel verschillend is,
heb je een soort van poort nodig
waardoor alle data binnenstroomt.
Vaak is de plaats waar de data wordt
opgeslagen niet de ideale plaats om
alle data netjes binnen te halen.
Dus de UNS wil die twee taken van, aan de
ene kant data integratie, Het makkelijk
verbinden met systemen, loskoppelen
van de uitdaging van dataopslag.
Luke: Oké, dus als ik het even
kan resumeren voor de luisteraars
die nog niet zo heel bekend
zijn met deze technologieën.
Veel van de luisteraars zullen
op verschillende punten staan
in hun digitale transformatie.
Ik denk dat veel bedrijven een slag
aan het maken slaan van een industrie
3.0 organisatie Denk aan een klassieke
organisatie waar de fabriekvloer
nog deels papier is met werkbonnen.
Er is wel een ERP systeem.
ERP is van midden jaren
2000, misschien 2010.
Er is misschien ook software voor
beide machines die er gebruikt
om te programmeren wordt.
En nu willen zij een echte
industrie 4.0 fabriek worden.
Nu hebben we dus een paar concepten
doorgesproken, een beetje uitgelegd
wat de UNS is en hoe het belangrijk
is van een structuur in historie.
Nu kunnen we misschien even een
praktisch maken voor de luisteraars.
... de Unified Namespace interessant wordt?
Op welk moment wil je bijvoorbeeld
eerst de Unified Namespace hebben...
...of eerst je fabrieksvloer
papierloos maken?
En wat kan het allemaal wel en wat kan het
eigenlijk allemaal niet voor ze betekenen?
Laten we daar ook even over praten.
Zullen we beginnen met het eerste,
van wanneer is de UNS interessant?
Ja,
Denis: in mijn ervaring
wordt de UNS relevant...
... vanaf het punt dat je vragen stelt...
Over je productie die je niet met
data van één systeem kan beantwoorden.
Ik geef een voorbeeld.
Stel je wil je klant informatie geven
over de CO2-afdruk van een bepaald
product, een batch dat je produceert.
Dan heb je informatie
nodig over de productie.
Dus de MES en de ERP van de
machine produceert op dat ogenblik
deze batch met dat onderdeel.
Die informatie zegt eigenlijk
nog niks over je CO2-afdruk.
Die informatie moet je echt gaan zoeken
in je SCADA-systeem of zelfs je sensoren,
want je wilt weten hoeveel energie
je verbruikt, wat de temperatuur was,
hoeveel energie er is gebruikt geweest.
Luke: Ja, zelfs toegevoegd gas
bijvoorbeeld ook, bij laser
snijden, gas gebruiken, gasuitstoot.
Denis: Precies.
Dus daar heb je data uit, langs
de ene kant je historieën, je
SCADA systeem en ook je ERP.
En die zou je graag aan
elkaar willen koppelen.
En dat is iets wat de UNS
voor jou uitstekend kan doen.
Luke: Right.
Dus het zou niet zozeer bedoeld zijn
om in de eerste plaats, dat we de
eerste business case nemen, het zou
niet zo zijn dat je wil de werkorders
vanuit de EIP naar de productievloer
te sturen, te zeggen van oké, de
werkvloer shopvlogcontrole heeft
een tablet, op de tablet zouden de
werkers een stukje krijgen wat de
volgende backstory zou moeten werken.
In het pushen van die informatie naar
de werkvloer zou misschien niet de
eerste use case zijn, Maar wel later
toegevoegd kunnen worden, of hoe
staan we in die volwassenheid ermee?
Dat is wel een brainstorm.
Denis: Wel, de UNS werd initieel vooral
gedacht voor het aspect data-analyse.
We gaan eigenlijk vermijden dat we
controle gaan aansturen via de UNS.
Dus dat willen we nog steeds
doen via de klassieke weg,
namelijk de automation pyramid.
Het gaat daarom in de eerste zin
wel degelijk om leren uit data.
Luke: Right.
Dus als we de vraag kunnen
invullen die ik stel van je bent
een industrie 3.0 bedrijf, je
hebt nog steeds papieren flows.
Het is niet de verwachting dat je
dus de complete integraties weg
doet als het gaat om je operationele
activiteit, het aansturen van de fabriek.
Dat is minstens niet de eerste
use case die je daarmee maakt.
Maar de use case is
vooral wel bedoeld voor...
Het analyseren van de hele fabriek.
Dus dat data-analyse en voorspellen en
machine learning te kunnen toepassen
en eigenlijk hele complexe, specifieke
vragen te kunnen antwoorden over wat
er precies gebeurt in de tijd en het
inzage te krijgen van de fabriek.
Klopt,
Denis: volledig.
In essentie wat we zien is dat de
huidige controlesystemen voldoen
niet aan de vereisten die we
hebben van moderne data-analyse.
Nu, we hebben ook gemerkt dat het
volledig opnieuw Herinstalleren,
herontwerpen van deze systemen is
onrealistisch, is ook niet nodig.
We gaan in plaats daarvan een
systeem parallel naast de bestaande
systemen implementeren, dat gewoon
enkel data uit deze systemen leest.
Luke: Right, oké.
Dus een grote misconceptie misschien
om Trend UNS is dat het alles vervangt.
Dat is zeker niet de bedoeling,
het is een aanvulling op en het kan
op ieder systeem worden toegepast.
Zeg ik dat zo goed?
Denis: Zo is het exact bedacht.
Want we weten dat de stap van
industrie is al heel groot.
En daarom is de UNS eigenlijk een
technologie die een geleidelijke
transformatie mogelijk maakt.
Dat je niet je hele fabriek van
dag 1 op 2 helemaal moet ombouwen.
Maar je eigenlijk stap voor stap,
stapsgewijs, kunt beginnen opbouwen
richting die industrie 4.0.
Luke: Oké, oké.
En wat is volgens jou, in jouw
ervaring, dan echt het einddoel
van een succesvolle transformatie?
In de eeuwige tijd woord industrie
4.0, daar naartoe groeien.
Wat is volgens jou een van de beste
eindsessions die je er nu hebt gezien?
Misschien een voorbeeld daarvan.
Denis: Veel goede voorbeelden
zijn er nog niet, buiten de
echte grote spelers als in Tesla.
Waar vaak wordt gezegd dat de
uiteindelijke droom, zoals ik
het zie, is dat Data een van je
belangrijkste producten wordt.
We gaan niet enkel plaatwerk of aluminium
produceren, nee, we gaan effectief ook
onze productiedata beschouwen als een
waardevolle bijproduct van ons systeem,
omdat deze data ons mogelijk maakt om
onze business decisions te automatiseren.
Wat is NMVD?
Wat is Industrie 4.0?
Het is de automatisatie
van business decisions.
Luke: Ja, oké, dit is
een hele mooie uitkomst.
Ik zie het ook inderdaad zo, is dat in
een gegeven moment je voorspellend kunt
gaan analyseren van wat er gaat gebeuren.
Dus je weet al een beetje wat
er gaat gebeuren in de toekomst.
Je hebt ook wel een heel belangrijk
onderwerp nu in het tussendoor
genoemd wat betreft de CO2-uitstoot.
Ik denk dat ieder bedrijf in de
toekomst zich ook wel bezig moet
gaan houden met hun footprint.
En er zijn voor mij ook zelfs nu
wetgevingen in de maak in Europa.
...omtrend deze metingen daarvan.
Het is natuurlijk een
enorm belangrijk thema...
...dat jij als organisatie bewust
wordt van wat jouw uitstoot is...
...en hoe wat je doet
om het te minimaliseren.
Dus dat zou ook een hele mooie
business case kunnen zijn...
...ook dat je dus kunt gaan kijken
naar je organisatie op zich...
...en wat probeer je om
het beter te maken...
...en wat zou bijvoorbeeld een voorbeeld
kan zijn met je energieverbruik...
...als je weet wat je piekenergieverbruik
is op een bepaald moment...
...kun je gaan voorspellen wanneer
je dat beter kunt gebruiken...
...wat voor producten de
meeste energie gebruiken...
...welke momenten en misschien dan...
Planning aanpassen van je productie
zodat je dat op de momenten doet dat
de meeste energie in het net is of wat?
Denis: Klopt, volledig.
Het is eigenlijk al vandaag
de dag een heel groot thema.
Bedrijven in Europa krijgen vandaag de
dag al heel veel funding van overheden.
Natuurlijk moeten ze in plaats daarvoor
wel kunnen bewijzen van kijk, Wij geven
jullie al dat geld voor hernieuwbare
energie, voor een goedere stroom,
voor een verlaging van jullie CO2.
Maar wat doen jullie ermee?
Dus bedrijven voelen wel degelijk de druk
om hun reporting te verbeteren, om te
kunnen bewijzen wat ze allemaal doen voor
een verlaging van hun energieverbruik.
Right.
Luke: Dus dat zijn eigenlijk hele
specifieke topics van data-analyse
die je wilt toepassen, en dan daar ook
op te gaan sturen in je situatie...
Door te zeggen oké dit gaan we
nu anders doen zodat wij kunnen
aantonen dat we ook echt Bereiken.
Dus dat zou een hele goede echte use
case zijn van data engineering, data
analyse, maar specifiek in het model van
de Unified Namespace om dit waar te maken.
Nou dan wil ik toch even op de stoel van
de gebruiker gaan zitten en dan wil ik
je toch over de vraag stellen die van,
oké, ja, dit is belangrijk en vermatigd
om te weten van je organisatie op alle
punten, maar wat als mijn team gewoon
gewend is om het gewoon, Wekelijks
standardiseren met Excel sheets of wat dan
ook, waarom doen ze dat dan niet gewoon?
Wat is daar mis mee volgens jou?
Ik heb er zelf wel mening over,
maar ik wil even jou uitleggen hoor.
Denis: In de eerste plaats heb
ik geen probleem met Excel.
Kijk, Excel is een werktuig.
Je kan je werktuig gebruiken voor de
juiste opgave en dan is alles prima.
Ja.
De vraag is, als je echt wilt gaan
leren van data, kom je op een gegeven
moment met enkel Excel niet toe.
Dat heeft te maken met grote data
volumes, maar ook gewoon met de
moeilijkere vragen waarvoor je
modernere technologie nodig hebt.
En dat vind ik het mooie aan de UNS,
je UNS verplicht je niet tot het
gebruiken van een bepaald werktuig.
De UNS stelt gewoon de data
voor jou ter beschikking.
Je kan daarom perfect met je
Excel verbinden aan de UNS.
En data daarin uitlezen.
Het is juist voor de, laten we zeggen, de
meer geavanceerde gebruikers van de data,
die graag werken met tools zoals code of
met databricks, voor echte big data, dat
zij nu ook met die data kunnen werken.
Luke: Dus eigenlijk zeg je daarmee ook
dat door het toepassen van het systeem,
dat iedere dataspecialist je kan helpen
en dat dat niet alleen dus intern is dan.
Dat
Denis: klopt, ik zou de UNS zien als
een fundering voor je toekomstige,
voor je digitale toekomst.
Je kan die fundering een schuur bouwen,
je kan ook een fontein bouwen, maar
je hebt die rotsvaste fundering.
Luke: Oké, laten we even
dan het praktisch maken.
Stel je voor dat bedrijven dit nu
aanhoren, ze zeggen oké, dit willen we
wel wat meer over weten, jij hebt het
toegepast bij verschillende bedrijven
en we hebben dus een use case hier,
een business case, we willen dus
real time of ...na genoeg real-time
inzage krijgen in de hele organisatie.
Weten waar ieder product is in ieder tijd.
Wat heeft het gedaan?
We willen weten wat
daar precies gebeurd is.
De events daaromheen.
En alle activiteiten.
Dus ook bijvoorbeeld het verbruik
van energie, noem maar op.
Productiviteit heb ik ook gehoord van
mij in eerdere gesprekken met jou.
Het gaat over OEE, dus algemene
efficiency die daar plaatsvindend is.
Nu willen ze starten en ze typen in in
Google, ik wil een Unified Namespace.
En dan komen ze uit bij allerlei
verschillende software systemen daarvoor.
Wat is jouw gepreforeerde software
aanpak daarvoor op dit moment en waarom?
Denis: Klopt, nu als je gaat
kijken op Google zijn er effectief
nu al meerdere aanbieders.
Die al de UNS in hun marketing verweven.
Dan denk ik aan voorbeelden zoals een
HiByte of een Litmus, die dan vanuit de
US naar ons komen, de Verenigde Staten.
Mijn persoonlijke voorkeur, ik ga
deze een beetje dichter bij huis
zoeken, we hebben namelijk in
Europa, in Duitsland, een bedrijf
die als eerste een unified namespace
Aanbieden als open source product.
Wat bedoel ik daarmee?
Hun businessmodel is zeer interessant
voor bedrijven die starten met
deze materie, omdat zij hun
product volledig gratis aanbieden.
Nu, waar is de catch?
Hun product is gratis, ook
volledig gratis, het is geen demo.
Zij verdienen hun brood met het
Administreren van deze software
voor jou, indien je dat wenst.
Maar je bent ook vrij om daar
zelf mee te experimenteren.
Daarom, om jouw vraag te beantwoorden welk
systeem ik zou gebruiken, wel, ik zou echt
kijken naar deze open source toepassing,
omdat ik daarmee het minste risico loop.
Omdat ik dan niet vasthang aan een
bepaald contract voor een lange tijd.
Luke: Oké, maar waarom is dit dan nu een
betere keuze voor het meeste bedrijven?
Je zit er niet vast eraan, maar zijn er
nog meer redenen waarom dit beter is?
Denis: Ja, ik denk de voornaamste
redenen zijn ten eerste dat je
opwille van het open source karakter
niet vasthangt aan de vendor.
En daarmee bedoel ik al, stel als de
vendor blogs zijn prijzen verdubbeld.
Nou, dan ga je gewoon met
hem niet meer verder werken.
Je bezit je systeem volledig zelf.
Dat was mij heel belangrijk.
Het tweede punt is dat een open source
is per definitie een open architectuur.
Dat wil zeggen dat je daar eender
welk systeem mee mag integreren.
Het komt soms voor, en dan vooral bij
historians, de klassieke historians,
dat zij zeggen van, kijk, oké, we
hebben de data, maar je mag de data
enkel lezen met een van onze tools.
Dat probleem ga je dus met een
open source oplossing niet hebben.
En natuurlijk de laatste punt
is, kijk, alles kost geld.
Het feit dat het open source
is, het is een gouden product.
Het is veel eenvoudiger om je
manager te overtuigen om iets te
proberen wat jouw bedrijf niets
gaat kosten in de eerste stappen.
Luke: Ja, zeker.
Je kunt er dus inderdaad gewoon op
starten, proberen en mee naar gang gaan.
Wat zijn de voorwaarden om hiermee te
kunnen beginnen, of wat heb je nodig
aan kennis, ervaring of mensen, of wat
voor team heb je nodig om dit te doen?
Denis: Wel, uit mijn ervaring, als
ik kijk, een ander voorbeeld dat
ik nog niet heb aangehaald van die
open source technologie, Is dat ze
een heel levende community hebben.
Dus een groep van mensen die laaiend
enthousiast zijn over dit product.
Dit wil zeggen dat stel als je het
idee hebt om daarmee te spelen,
kan je relatief eenvoudig hulp
krijgen uit die gemeenschap.
Nu, welke vereisten heb je nodig?
Op vlak van technische requirements
van hardware en software, quasi niks.
Een gewone laptop die je thuis nog
hebt liggen is perfect voldoende
Om in eerste instantie een UNS
te hebben voor jouw fabriek.
Dat is ook wat we zien in de groep.
Mensen die vaak gewoon als ingenieur of
als meer in business werken en met een
beetje tijd hebben op kantoor, dat zij
vaak gewoon de UMH dan downloaden en
gewoon bij hun lokaal in kantoor laten
Luke: draaien.
Ja, ik moet het ook aan de
luisteraar bekennen, dat hebben wij
voor een gesprek over gesproken.
Ik heb nu ook een laptop hier
staan en dat kan ik bevestigen.
Het is echt zeer
gebruikstoegankelijk eigenlijk.
Ik heb misschien een vraag
Denis: omkeer naar jou, Luke.
Hoe vond jij de implementatie van UNS?
Welke kennis had je nodig of welke
dingen vond je echt moeilijk?
Luke: Tja, ik denk dat het bouwen
van de database zelf inderdaad
redelijk gestructureerd is.
Je moet even gaan googlen, hoe
maak ik een Linux PC enzo, hoe
maak je een virtual machine.
Even googlen, dat lukt er wel.
Maar ik vond het...
Het is een stuk wij hebben natuurlijk
een beetje voorkennis in dit verhaal.
En nog steeds, ik denk dat het
installeren van niet de uitdaging was.
Het bepalen van dat het online staat,
oké, dat het actief is, ook niet.
Maar dan, hoe ga je dan beginnen met...
Informatie te verzamelen.
Welke informatie haal je waar vandaan?
Wanneer?
Waar staat alles?
Ik denk dat het ook heel belangrijk
is dat je vanuit metaal gezien ook
wel echt toegang moet krijgen tot je
systemen, tot je machines, tot je data.
En dat je toch even bij je
leveranciers van de machine moet gaan
vragen van hebben we die data wel?
Want heel veel bedrijven hebben dus...
...machines, maar voor mij hebben ze
nog nooit gekeken naar dat er achter die
machine een OPC UA-server staat of dat
er in de ERP een mogelijkheid is om alle
events te publishen naar een historian.
Dat zijn allemaal dingen die,
ja, denk ik niet zo voor de hand
liggend zijn voor de meesten.
Dus ik denk dat de eerste stap zou zijn
toch wel eigenlijk een plan maken van...
Wat wil je meten?
Wat zijn je databronnen?
Waar zit de data?
En dan daarna dat te gaan verbinden
en ermee gaan experimenteren.
Denis: Ik denk dat dat
een heel juist punt is.
Dat is namelijk het belangrijkste.
Wat je echt nodig hebt is kennis
van het probleem of het doel dat
je wil bereiken met die data.
Daarom in mijn ervaring, de mensen
die ik echt zie vertrekken met
die UMH, de open source versie
van de UNS, zijn vaak ingenieurs.
Die de machines kennen, die een
idee hebben van de problematiek en
die zichzelf, een beetje tijdens de
kantooruren, misschien een beetje
thuis, de IT kant die best wel te
overzien is, zichzelf bijbrengen.
Luke: Ja, ik herken dat volledig, dat
is ook hoe ik zelf mijn carrière ben
begonnen en dat is het leukste wat er
is als je zelf aan de machine zit en
je ziet daarna, je denkt van hé wacht
even, het bestuurder van de machine
kan slimmer, het planner kan slimmer,
waarom zou ik dingen invoeren, zo ben ik
begonnen, dat is niet echt de volledige
UNS toepassing, maar dat heb je wel
nodig als fundament en daarna komt dan
de volgende stap, nu wil ik analyseren.
Ik heb toevallig niet zo lang geleden een
project afgerond voor een klant van mij,
waar we process mining hebben gedaan.
Dat zag ik de vorige aflevering van
deze podcast ook, voor de luisteraars.
En daar hebben we dat dus dan gedaan
door middel van Microsoft Datamarts.
Dat heeft ook een systeem, dus dat
is dan een data warehouse eigenlijk.
En dat was best wel bewerkelijk
eigenlijk al, om dat te bewerkstelligen.
En de data was inderdaad ook wel beperkt.
Dus ik zie ook wel dat er ook wel een
enorm voordeel ligt Om dat dan, als je
zoiets wil proberen, beginnen is met het
maken van een dashboard, ga eens een keer
met een ERP business intelligence tool
spelen, dan weet je wat je wilt meten.
En dan kom je eigenlijk snel tot
de conclusie dat je toch ook meer
nodig hebt dan alleen ERP data.
En dat is denk ik waar
de echte struggle zit.
Ik denk dat het ook heel interessant
is dat dit voor bedrijven die
...werk je in een enterprise systeem,
dus hebben we meerdere fabrieken.
Je kent het natuurlijk wel,
je fabriek heeft zijn eigen
software, zijn eigen werkwijze...
...soms ook andere
processen, andere diensten.
En als je dan in het hoofdkantoor
wilt zien wat alle fabrieken doen...
...en je wilt iets meer zien dan
alleen de kwartaalcijfers financieel...
...dan zul je toch ook wel aan de
slag moeten met iets met data-analyse.
En ik denk dat het ook wel heel
interessant is om dat te gaan toepassen.
Denk je dat het ook zo is, of niet?
Denis: Ja, vooral het laatste
punt dat je boven haalt, als je
kijkt naar enterprise fabrieken.
Het feit dat je niet al deze fabrieken
op dezelfde systemen moet gaan ombouwen,
maakt IONES heel aantrekkelijk.
Stel je hebt een fabriek in
Frankrijk die een bepaalde historie
heeft, een bepaalde ERP systeem.
Wel, die kunnen ze
gewoon blijven gebruiken.
Je bouwt gewoon parallel bij
elk van jouw satellietfabrieken.
Een UNS en die dat kan verenigen in
een zeg maar opper-UNS daarboven.
Luke: Ja, oké.
Nou, dit klinkt super verbelovend, ten
omwille van de tijd en deze aflevering.
We zullen denk ik even weg gaan blijven
van de echte gedetailleerde implementatie.
Maar voor de luisteraars die
dit nu heel interessant vinden
en hier meer over willen weten.
Wat zou voor hun de beste stap zijn om
te beginnen, om hier meer over te leren?
Denis: Wel, er zijn meerdere bronnen.
Ik denk...
De UNS-technologie zelf is niet
nieuw, maar werd heel populair gemaakt
door de Amerikaan Walker Reynolds.
Zijn video's zou ik als eerste
instandpunt zeker aanbevelen.
Daarnaast zijn er heel goede
tekstdocumenten over de UNS, maar ook
video's gepubliceerd van die start-up
die ik heb bovengehaald, namelijk de
United Manufacturing Hub in Duitsland.
Ja, die artikelen zijn super, ja.
Luke: Ja,
Denis: die zijn heel technisch heel
hoogwaardig, zou ik zeker aanbevelen.
Ik denk dat je met deze twee
bronnen een heel goed inblik hebt
van de business kant, maar ook
de technische zijde van de UNS.
Luke: Ja, de umh.app volgens mij
is de website, uit mijn hoofd.
Ik zal het in de show notes
zetten voor de zekerheid.
Als je naar beneden scrolt in deze
aflevering, dan zie je de De link
naar deze twee dingen zit erbij staan.
Maar ook als bedrijven actief zijn in de
metaalindustrie, en ze zitten misschien
wat meer in jouw specialisatie, kun je
luisteren of misschien wat meer vertellen
over wat jij doet qua jouw werkzaamheden
en voor wie dat mogelijk geschikt is?
Ja,
Denis: klopt.
Dus ik ben momenteel heel actief met het,
laten we zeggen, het populariseren van het
verhaal van de UMH en de UNS-projecten.
In mijn wereld, namelijk
de aluminium-industrie.
En werk ik ook actief mee aan
het implementeren van een Unified
Namespace in deze fabrieken.
Oké, en
Luke: als bedrijven daar meer
af willen weten, hoe kunnen ze
dan met jou aan de slag gaan?
Wat is de eerste stap?
Denis: Dan zou ik de luisteraar
verwijzen naar mijn website, die
is mijn familienaam, Goncharov.
Luke: Oké, die staat ook in de show
notes en daar kunnen ze dan meer lezen
over wat je doet, hoe je helpt en
specifiek dan voor bedrijven die echt
het willen toepassen op enterprise
niveau neem ik aan, maar ook erbuiten.
Zowel enterprise
Denis: als ook small to medium.
Oké,
Luke: nou super.
Heb ik nog verder nog iets vergeten
te vragen in dit gesprek of iets
wat je nog wilt toevoegen aan onze
eerste samenwerking in deze show hier?
Denis: Nee, ik vond het een
hartelijk fijn gesprek en kijk
uit naar de volgende aflevering.
Luke: Ja, ik ook.
Ik ben natuurlijk nog wel een
vervolg aan gegeven, want er is
maar nog genoeg te bespreken.
En ik ben ook benieuwd
naar jou als luisteraar.
Heb jij hier nog feedback op onze
aflevering, vragen of onderwerpen
die je nog wilt dat wij bespreken of
vragen die ik aan Denis kan stellen of
andere specialisten in deze aflevering?
Laat het me gerust weten.
Je kunt ook mijn contactgegevens
onderaan deze aflevering vinden.
Nou, dan restreert mij niet
meer dan je te bedanken voor je
deelname Denis aan deze show.
En ook luisteraars bedankt
voor het luisteren.
Bedankt voor de uitnodiging
en bedankt voor het luisteren.
Ja, super.
Nou, tot de volgende keer.
Ik wens jullie een fijne dag en tot de
volgende aflevering bij Metaal Connect.
Tot ziens.
