In mijn eerste blog wil ik eerst ingaan op de valkuilen die er zijn als men EPLAN heeft aangeschaft en deze wil gaan gebruiken voor het engineeren van schema’s.Valkuil 1: Geen tijd en geld vrijmaken voor implementatie.
Dit is de grootste valkuil. Vrijwel nooit word er tijd uitgetrokken om een juiste standaard op te zetten. Alles moet zogezegd on the job gebeuren. Een verkeerde insteek. Want het is altijd druk, druk, druk.
Tijd om EPLAN eigen te maken en de schema’s die gemaakt zijn te controleren op juistheid, is er niet.
Vaak heeft men wel de toestemming om een dag of een halve dag met de software bezig te gaan, maar dan word je alsnog gestoord voor andere zaken.
Ofwel, als je als bedrijf EPLAN aanschaft en gaat gebruiken, denk dan ook na over de juiste inrichting van EPLAN, en investeer dan ook in de uren om dat te bewerkstelligen.
Anders loop je achter de feiten aan en gebruik je de software als een veredelt tekenpakket, dat wel automatische verbindingen maakt, en lijsten er uit spuugt, maar meer is het ook niet.
Daarbij kom ik op valkuil 2, visie?
Valkuil 2: Gebrek aan visie
Waar wil je als bedrijf staan over bijv. 3 jaar? Kun je dan met 1 druk op de knop de paneelbouwer voorzien van de juiste informatie m.b.t. de projecten dien moet gaan uitvoeren?
Daardoor komt tijd vrij voor een extra project of tijd voor innovatie.
Dus je kunt of efficiëntere produceren, of innoveren.
Valkuil 3: Schema’s worden niet getest
Er worden schema’s gemaakt, over overgenomen vanuit EPLAN 5.7 (nooit doen), of een toeleverancier levert de schema’s, maar meldingenbeheer is nog nooit uitgevoerd.
Ook niet verwerkingen. Klopt de output? Is het zoals gewenst?
Of in 3D bij het routeren van draden, ineens worden draden niet gerouteerd of verkeerd?
En dan moet je fout zoeken en alles weer herstellen.
Valkuil 4: Geen macroproject
Tja macro’s zijn de motor van je engineering. En als iedereen een “on the fly” een macro maakt, dan weet niemand meer welke je nu moet gebruiken.
Of moet je nog steeds schema’s kopiëren en plakken, met alle gevolgen van dien. Fouten die mee gekopieerd gaan worden, verwerkingen die niet getest zijn, talen die ineens niet kloppen.
En de deadline verandert niet, en dan moet het ineens opgeleverd worden. Paniek, overwerk, fouten herstellen, allemaal onnodige uren die voorkomen hadden kunnen worden.
Ofwel beheer de macro’s in een macro project. Mijn voorkeur is per fabrikant, schema macro’s en 3D macro’s gescheiden.
Valkuil 5: Vervuilende artikeldatabase
Tja en dan de artikeldatabase, gewoon gevuld zonder erbij na te denken. Alle artikelen van alle klanten in 1 database. Wat is nog relevant, wat gebruiken we niet meer.
Valkuil 6: Slechte documentatie.
Documentatie van het artikel, maar ook hoe is alles ingericht, bedacht, gemaakt.
Stel jezelf de vraag:
Als ik iemand inleen is het dan mogelijk dat hij bij zonder begeleiding binnen een paar dagen zelfstandig kan werken.
Valkuil 7: Geen tijd voor scholing
Software in het algemeen moet je leren bedienen. Het is daarom noodzakelijk dat bedrijven de ruimte bieden voor aanvullende software.
Wanneer het juiste tijdstip is? Nooit….
Het is altijd druk, de klant verwacht dit, de klant dat…
Resumerend:
Bovenstaande zijn slechts een aantal valkuilen waar men in kan trappen bij de implementatie van EPLAN.
In de blogs die nu gaan volgen zal ik meer vertellen. Soms zal het globaal zijn, soms diepgaand. Maar het is geen rocket science.
- Het is gewoon de juiste visie hebben
- Afspreken hoe gaan we het doen
- Intensief overleg met de andere collega’s
- Testen
- Aanpassen als het niet juist werkt
- Testen
- Live gaan.
OTAP….
Ontwikkelen
Testen
Acceptatie
Productie
Voor velen is dit denk ik, niks nieuws onder de zon…
Een heel belangrijk aspect zijn o.a…wie, wat, waarom, wanneer…
projecten gaan voor want me moeten wel geld verdienen is De reden om geen gehoor te geven aan de valkuilen, maar alleen als de concurrent je voor blijft, maar helaas dan heb je de match al verloren.