[NAV] programmeervoorbeelden

[107mb]

Situatie:
- fabriek met discrete productie: bijna elk product is uniek.
- eigen ontwikkeld erp pakket met productie aansturing
- erp pakket wordt vervangen door Dynamics NAV

Door het eigen ontwikkeld erp pakket, wat zijn nukken en eigenaardigheden heeft, is directie en MT allergisch geworden voor maatwerk en programmering. Men is er hier van overtuigd dat NAV geïmplementeerd kan worden zonder code toe te voegen. Parametertje aanpassen en klaar is Kees.

Als IT-er zijnde weet ik wel beter. Er moeten bijvoorbeeld schermen gebouwd worden waar hele specifieke bewerkingen ingevoerd kunnen worden. Ook een scherm met barcodes en scanpunten. Het punt is dat ik geen idee heb hoe die onderliggende code eruit komt te zien. Waar wordt meer code gebruikt? Ik ben gewoon benieuwd, ook om meer licht in onze bedrijfsduisternis te schaffen . Internet helpt mij niet echt verder, misschien hier wel iemand?

[NMe]

MSDN: Extending Any Microsoft Dynamics NAV Client Using Control Add-ins

[farlane]

Als je proces maatwerk nodig heeft, gaat een 'standaard' pakket dat ook niet oplossen. Daarnaast heeft elk pakket zijn nukken, maatwerk of niet.

[NMe]

farlane schreef op woensdag 01 juli 2015 @ 20:53:
Als je proces maatwerk nodig heeft, gaat een 'standaard' pakket dat ook niet oplossen.

Dat ze nu maatwerk hebben wil natuurlijk niet zeggen dat het ook echt nodig was of dat er in de tussentijd geen betere standaardsoftware op de markt is gekomen.

[farlane]

NMe schreef op woensdag 01 juli 2015 @ 20:56:
[...]

Dat ze nu maatwerk hebben wil natuurlijk niet zeggen dat het ook echt nodig was of dat er in de tussentijd geen betere standaardsoftware op de markt is gekomen.

Dat zou kunnen maar het blijft standaard software. En als je zoals in je link daar compleet custom dingen in gaat maken, wordt het alsnog min of meer maatwerk.

[The Eagle]

Als ERP'er met 13 jaar ervaring, zowel functioneel als technisch en met procesoptimalisatiekennis (3x woordwaarde ):

- iedereen gaat roepen dat het oude pakket beter was, want daar konden ze dingen veel makkelijker. Is een kwestie van gewenning

- jij denkt ook nog steeds in termen van het huidige pakket. Aparte schermen bouwen voor aansturing etc. Aansturing zal ongetijfeld anders zijn als je nu hebt. Anders <> maatwerk en is niet noodzakelijk slechter (maar ook niet beter). Het werkt gewoon anders. Val alsjeblieft niet in de valkuil om in oude termen te denken, maar laat de implementatiepartner het werk doen en sta open voor alles. Et wordt anders. Kijk hoe je dat "anders" zo goed mogelijk kunt toepassen en voor je kunt laten werken. Want idd, niks zo makkelijk als configuratie.

- configuratie is in de loop der jaren steeds beter geworden. Ik zie echt een trend dat alles configureerbaar is. En das maar goed ook, want dan kan een functioneel persoon gewoon dingen werkend maken zonder dat ie daar een techneut voor nodig heeft

- je huidige codekloppers zullen in oude termen blijven denken. Die ga je uit de wind willen houden, en niet ofnauwelijks bij het project willen betrekken anders dan voor hete specifieke zaken. Op termijn neem je er afscheid van

- vroeger was er een trend om een pakket op de business aan te passen. Tegenwoordig is het andersom.

- aan maatwerk ontkom je nooit. Maar een streven van minder dan 5% maatwerk is heel realistisch. Bedenk je even hoeveel code er in een dergelijk pakket zit en hoeveel 5% daarvan is

- als je voor een cloudproduct gaat moet je wel out of the box draaien. Want maatwerk daar kan alleen de leverancier voor je fixen. Kostentechnisch meestal niet interessant.

- je zegt unieke producten. Best. Maar ongetwijfeld geen unieke grondstoffen. En uiteindelijk geldt altijd dat grondstof + bewerkingen = eindproduct. Als je die een beetje in volgorde kunt configgen ben je al een heel eind. Dat is je productieproces. Maar voor de andere bedrijsprocessen (procure to pay, logistics, order to cash, record to report, etc) geldt exact het zelfde. Je zult moeten standaardiseren op je processen, daar ontkom je niet aan. Als je slim bent ga je voor best practises.


Kortom: er gaat een hoop veranderen. Je bedrijf neemt geen stapje, maar een flinke sprong de toekomst in. Zelfbouw ERP stamt uit de jaren 80 ofzo. Das 30 jaar terug. Welkom in het heden, is even wennen maar you'll like it

[PolarBear]

The Eagle schreef op woensdag 01 juli 2015 @ 21:24:

- als je voor een cloudproduct gaat moet je wel out of the box draaien. Want maatwerk daar kan alleen de leverancier voor je fixen. Kostentechnisch meestal niet interessant.

Grotendeels oneens, een cloudproduct die geen goede API's biedt (en waarmee je dus data kan ophalen en manipuleren wat voor 80% van het maatwerk het belangrijkst is) zo ik mijden als de pest.

[NMe]

Daar heb je niks aan als de clouddienst zélf een interface aanbiedt. Dan kun je wel een API hebben maar dan loop je alsnog met losse tooltjes te kloten.

[The Eagle]

Exact dat idd.
Bovendien is data ophalen en afleveren een stukje interfacing, en niet perse maatwerk, zeker niet in het systeem zelf. Hooguit er omheen

Sowieso zou ik voor fysieke productieprocessen geen cloudproduct aanraden. Als je internetlijn er uit knalt ligt je hele bedrijf op zijn reet en die schade kun je echt nergens claimen
En daarnaast zul je ook regelmatig penetration tests uit moeten voeren om te weten dat je verbinding nog safe is enzo.

[farlane]

The Eagle schreef op woensdag 01 juli 2015 @ 21:24:
- vroeger was er een trend om een pakket op de business aan te passen. Tegenwoordig is het andersom.

Verlies je hier het doel niet een kleinigheid uit het oog?

[NMe]

farlane schreef op woensdag 01 juli 2015 @ 22:29:
[...]

Verlies je hier het doel niet een kleinigheid uit het oog?

Je bedrijfsprocessen aanpassen naar een meer gestandaardiseerde manier heeft natuurlijk meer voordelen dan dat je dit stukje ERP-software kan gebruiken. Als je processen lijken op die van andere bedrijven is het bijvoorbeeld ook makkelijker om werknemers op te leiden.

[The_Vice]

farlane schreef op woensdag 01 juli 2015 @ 22:29:
[...]Verlies je hier het doel niet een kleinigheid uit het oog?

welk doel dan?
ik ben vooral benieuwd naar doel:

• "directie en MT allergisch geworden voor maatwerk en programmering"

Ervaring leert dat dat ook niet zonder gerede twijfel aan kennis en kunde van hoger management klakkeloos moet worden aangenomen. Hoewel ze in hun positie alle recht van blonde naïviteit hebben uiteraard.

[farlane]

NMe schreef op woensdag 01 juli 2015 @ 22:34:
[...]

Je bedrijfsprocessen aanpassen naar een meer gestandaardiseerde manier heeft natuurlijk meer voordelen dan dat je dit stukje ERP-software kan gebruiken. Als je processen lijken op die van andere bedrijven is het bijvoorbeeld ook makkelijker om werknemers op te leiden.

Tuurlijk, maar in feite pas je je proces dan niet aan aan de software, maar aan een andere 'standaard' ( als dat al bestaat ).

The_Vice schreef op woensdag 01 juli 2015 @ 22:37:
[...]

welk doel dan?
ik ben vooral benieuwd naar doel:

• "directie en MT allergisch geworden voor maatwerk en programmering"

Het doel is geld verdienen. Dat wat jij noemt is geen doel, eerder een obstakel.

[NMe]

farlane schreef op woensdag 01 juli 2015 @ 22:49:
[...]

Tuurlijk, maar in feite pas je je proces dan niet aan aan de software, maar aan een andere 'standaard' ( als dat al bestaat ).

True. Maar ik neem aan dat The Eagle dat ook bedoelde.

[107mb]

Maatwerk is nu in access gebouwd. Op salarisadministratie na zit alles in het pakket. Boekhouding, BI, kalender, productie aansturing, voorraadbeheer, inkoop,alles. Door een man geschreven.

Onlangs gebeurt: een functie verwijdert CrLf uit een string. Dit moet, cnc strings voor machine-aansturing mogen geen stuurcodes bevatten. Vanuit verkoop kwam de wens om enters te kunnen gebruiken in memovelden. Programmeur willigt die wens in. Past dus die ene generieke functie aan: gevolg:productie plat.

Bout m8 heeft artikelnr x. Bout m8 rvs heeft ook artikelnr x. Alleen door de toevoeging RvS in de omschrijving is er een verschil. In de hele applicatie wordt dus de string doorlopen en op de term RVS gezocht. Hard gecodeerd.

Zo kan ik door gaan. Ik begrijp de directie dus wel wat betreft maatwerk allergie.

Ik ben onlangs als tweede programmeur aangenomen, en juich de nieuwe ontwikkelingen toe, ondanks de naïviteit en onkunde van diverse collega's, zoAls het niet geloven dat er maatwerk nodig is.

De partner gaat de inrichting doen, wij beginnen binnenkort met de processen te beschrijven. Die zijn onlogisch, en zullen aangepast worden.

[ Voor 7% gewijzigd door 107mb op 01-07-2015 23:03 ]

[farlane]

107mb schreef op woensdag 01 juli 2015 @ 22:57:
Zo kan ik door gaan. Ik begrijp de directie dus wel wat betreft maatwerk allergie.

Begrijpelijk, maar men verwart 'broddelwerk' met 'maatwerk' ( Het een sluit het ander niet uit trouwens )

Ik ben onlangs als tweede programmeur aangenomen

Sterkte!

[ Voor 12% gewijzigd door farlane op 01-07-2015 23:55 ]

[Jogai]

Iets dat in access is gemaakt kun je meestal niet vergelijken met een (maatwerk)software pakket dat voor je branche/bedrijf geschreven is. Vaak is dan iemand aan het klussen geweest die handig is met office en vba, en die verstand had van de business. Dat levert iets op dat wel voldoet voor een tijd, maar kan meestal niet meegroeien met een bedrijf.

Je voorbeeld met CrLf geeft duielijk aan dat de maker geen echte ontwikkelaar is.

[The Eagle]

107mb schreef op woensdag 01 juli 2015 @ 22:57:
Maatwerk is nu in access gebouwd. Op salarisadministratie na zit alles in het pakket. Boekhouding, BI, kalender, productie aansturing, voorraadbeheer, inkoop,alles. Door een man geschreven.

Access KAN geen ERP zijn. Heck, het is zelfs niet eens een DBMS. Heel snel naar MS NAV gaan

Onlangs gebeurt: een functie verwijdert CrLf uit een string. Dit moet, cnc strings voor machine-aansturing mogen geen stuurcodes bevatten. Vanuit verkoop kwam de wens om enters te kunnen gebruiken in memovelden. Programmeur willigt die wens in. Past dus die ene generieke functie aan: gevolg:productie plat.

Dan moet je die programmeur EN de business eens goed achter hun vet zitten wegens niet fatsoenlijk testen. Dit had gewoon voorkomen kunnen worden.

Bout m8 heeft artikelnr x. Bout m8 rvs heeft ook artikelnr x. Alleen door de toevoeging RvS in de omschrijving is er een verschil. In de hele applicatie wordt dus de string doorlopen en op de term RVS gezocht. Hard gecodeerd.

Typisch gevalletje van masterdata dat niet goed zit. Heeft niks met je systeem an sic te maken maar alles met de procedures en personen die betrokken zijn bij het beheer van stamgegevens. / masterdata.

Zo kan ik door gaan. Ik begrijp de directie dus wel wat betreft maatwerk allergie.

Jouw direct is niet allergisch voor maatwerk. Jouw directie is allergisch voor de mogelijke impact die het kan hebben.

Ik ben onlangs als tweede programmeur aangenomen, en juich de nieuwe ontwikkelingen toe, ondanks de naïviteit en onkunde van diverse collega's, zoAls het niet geloven dat er maatwerk nodig is.

De partner gaat de inrichting doen, wij beginnen binnenkort met de processen te beschrijven. Die zijn onlogisch, en zullen aangepast worden.

Processen tegelijk aanpassen met de invoering van een ERP systeem is link, want een aanpassing kan twee kanten op: de systeemkant of de procedurele kant. Aangezien je directi geen maatwerk wil, wordt dat dus de procedurele kant. Dan moet je dus je processen reengineeren. Ik heb zelf vorig naar aan iets dergelijks meegewerkt voor EU HR voor een fortune 500 klant. Dat was 15 man volcontinue aan het proces modelleren voor een week of 8. Nou zijn jullie (helaas? ) ongetwijfeld geen fortune 500, maar het geeft wel een indicatie.
Protip: ga gelaagd door je processen heen. Pak eerst de processen op hoofdlijnen, en ga die vervolgens verder uitdiepen. beginnen op level 1 en dan langzamerhand door naar level 4 of zelfs 5. Bij de laagste levels ga je ook je systeemintegrator nodig hebben.

Vwb het aanpassen van systeem op processen en vv: hoe meer je een systeem aanpast, hoe duurder het wordt. Klanten willen zeker na de crisis van 2008 zo weinig mogelijk uitgeven, dus dan worden de processen aangepast. Bij cloudproducten die out of the box geleverd worden zie je dit nog veel sterker. Pre 2008 was ERP simpelweg het congifureren van het pakket naar de bedrijfsprocessen, incl een shitload aan maatwerk. Maar die tijden zijn voorbij.

[farlane]

The Eagle schreef op donderdag 02 juli 2015 @ 12:55:
Heel snel naar MS NAV gaan

Of een ander pakket dat geschikter is dan Access.

[The Eagle]

Heel eerlijk: als je bij willekeurig wel automatiseringebedrijf aanklopt en je geeft aan dat er in Access iets geprogrammeerd is, dan wordt dat over het algemeen geclassificeerd als "handmatig, er is niks".

Het voordeel is dan wel: het kan alleen maar beter worden

Hoeveel machines worden er eigenlijk met die Access meuk aangestuurd?

[107mb]

een stuk of 15. dat werkt trouwens wel geavanceerd. 5 daarvan worden door Access aangestuurd, en de rest werkt wel geavanceerd. een C++ applicatie scant een barcode, haalt de bijbehorende gegevens op uit de database, en creeert zelf een CNC programma.

[The Eagle]

Dan kan ik je nu al voorspellen dat die C++ applicatie gaat blijven. Hij zal alleen koppelen naar een andere DB - die van NAV - om zijn gegevens op te halen. Alternatief is die aansturing in de MS NAV taal om te zetten (.net ofzo ). Ik weet niet of je die richting in wilt. Maar voor 15 machines is dat wel te doen. Of MS NAV moet die aansturing out of the box hebben. Dat vermoed ik niet.

Access stuurt helemaal niks aan in deze.

[107mb]

klopt. Die C++ applicatie is prachtig opgezet. Modulair: een deel verzorgt de koppeling met de DB. Deze module wordt herschreven voor SQL Server. Tweede module is de kern die de CNC code schrijft, en de derde module is de koppeling met de CNC machine.

Het probleem nu is het helder krijgen van de processen (maken van de blueprint). Wat is een normale gang van zaken? Wie maakt deze blueprint? Projectteam? Afdelingsmanagers? Key-users? De afdelingsmanagers staan verder van het proces dan gebruikers, maar hebben (iig bij ons) meer capaciteiten om breder te kijken. Ik zie gebruikers bij ons vaak focussen op zaken die ze nu niet kunnen, en daar dan erg gedetailleerd op in gaan.

We krijgen uiteraard begeleiding (lees: leiding) van de consultant, maar heb vooraf ook graag eigen ideeen

[ Voor 8% gewijzigd door 107mb op 02-07-2015 22:02 ]

[Evilbee]

The Eagle schreef op donderdag 02 juli 2015 @ 17:29:
Dan kan ik je nu al voorspellen dat die C++ applicatie gaat blijven. Hij zal alleen koppelen naar een andere DB - die van NAV - om zijn gegevens op te halen. Alternatief is die aansturing in de MS NAV taal om te zetten (.net ofzo ). Ik weet niet of je die richting in wilt. Maar voor 15 machines is dat wel te doen. Of MS NAV moet die aansturing out of the box hebben. Dat vermoed ik niet.

Access stuurt helemaal niks aan in deze.

Een beter alternatief is om te kijken naar een MES oplossing die juist voor aansturing van je fabrieksvloer is bedoeld. Een ERP pakket is niet bedoeld om realtime gegevens (milliseconden/seconden) van een fabrieksvloer te verwerken.

[Jogai]

The Eagle schreef op donderdag 02 juli 2015 @ 15:49:
Heel eerlijk: als je bij willekeurig wel automatiseringebedrijf aanklopt en je geeft aan dat er in Access iets geprogrammeerd is, dan wordt dat over het algemeen geclassificeerd als "handmatig, er is niks".

Het voordeel is dan wel: het kan alleen maar beter worden

Hoeveel machines worden er eigenlijk met die Access meuk aangestuurd?

@1e alinea: Dan wordt je dus niet serieus genomen. Hoe brak access ook is, als iemand daarin iets heeft gefrobeld is het wel zo dat daar de huidige business logica inzit. Dat je het niet kan vinden als je de beerput opentrekt is wat anders.

[farlane]

The Eagle schreef op donderdag 02 juli 2015 @ 15:49:
Heel eerlijk: als je bij willekeurig wel automatiseringebedrijf aanklopt en je geeft aan dat er in Access iets geprogrammeerd is, dan wordt dat over het algemeen geclassificeerd als "handmatig, er is niks".

Vergeet niet dat het tot nu toe blijkbaar voldoende goed heeft gefunctioneerd om een business aan de gang te houden.

[107mb]

om even de access discussie af te sluiten: onze applicatie is enorm uitgebreid, en heeft verbazingwekkend veel functionaliteit. Onder de motorkap ziet het er wat minder fraai uit. Heel veel generieke functies die, omdat ze vanuit de gehele applicatie aangeroepen kunnen worden, enorm veel logica bevatten en dus complex zijn. De vorige programmeur heeft hier voor gekozen, en dit is niet zo snel aan te passen.
Voor de gebruiker an sich werkt het goed. Al jaren wordt er een hele fabriek mee aangestuurd.

Wat betreft de opmerking van the Eagle: "handmatig, er is niks", heeft onze ERP leverancier het tegenovergestelde: "alles is er, en qua functionaliteit moet alles over..."

De keuze is gemaakt voor NAV. Ik ben er blij mee, omdat het duidelijkheid gaat bieden, en er een grote mate van professionaliteit ingevoerd gaat worden. Daarnaast gaan alle processen bekeken en eventueel herschreven gaan worden. Dit gaat een optimalisatie opleveren. Een MES gaat er niet komen, er hoeft geen realtime info van ERP naar de machines. Een scanner geeft aan welk product er bij een machine is aangekomen, en de bewerking wordt naar de machine gestuurd.

Naast de vele vragen die ik heb over blueprints, proces-optimalisatie, team-samenstelling ben ik ook erg benieuwd naar hoe, waar en waarom er aanpassingen binnen NAV gerealiseerd worden. Wat is nu eigenlijk maatwerk. Zal er geprogrammeerd binnen NAV moeten worden?

[Ryur]

--- laat maar

[ Voor 172% gewijzigd door Ryur op 04-07-2015 22:37 ]

[The Eagle]

farlane schreef op vrijdag 03 juli 2015 @ 08:35:
[...]

Vergeet niet dat het tot nu toe blijkbaar voldoende goed heeft gefunctioneerd om een business aan de gang te houden.

Ik zeg ook niet dat dat "er is niks" rechstreeks tegen de klant wordt gezegd. Maar ze denken het wel
NAV of willekeurig ander ERP systeem biedt veel meer dan access ooit kan bieden. Dus vrij makkelijk om te zeggen dat alle functionaliteit er is en over moet
Kan zijn dat er een klein stukje zo specifiek is dat NAV het niet ondersteunt. Maar dat zou dan die 5% maatwerk zijn waar ik het in het begin over had

Vwb dat blueprinten: dat doe je met een relatief kleine groep. Ik denk dat een man of 5 bij jullie full fime voor een week of 6 genoeg zou moeten zijn. Idealiter met externe mensen die wel proceskennis hebben, maar geen organisatiekennis. Dat klinkt gek, maar zonder organisatiekennis kun je echt denken aan best practises zonder een "maar dat kan hier helemaal niet wat directeur zus of detail zo".
Doe je het met een interne ckub, dan veel interne proceskennis, maar wel bovenstaande mentaliteit. Alles kan, screw het huidige inclusief directie.

[alienfruit]

Tja, daar heb je de business analyst voor

[The Eagle]

Externe business analyst dan. Kan met niet voorstellen dat je een interne aan de slag kunt houden als de hele meuk op access draait en je devvers zomaar code door laat zetten. Die BA's zijn slimme jongens, die kijken dat even aan en dan zijn ze pleitos naar een andere baan. Can't blame 'em

[Tribits]

107mb schreef op woensdag 01 juli 2015 @ 20:21:
Men is er hier van overtuigd dat NAV geïmplementeerd kan worden zonder code toe te voegen. Parametertje aanpassen en klaar is Kees.

107mb schreef op vrijdag 03 juli 2015 @ 10:01:
Wat betreft de opmerking van the Eagle: "handmatig, er is niks", heeft onze ERP leverancier het tegenovergestelde: "alles is er, en qua functionaliteit moet alles over..."

Misschien mis ik iets, maar dit klinkt mij tegenstrijdig. Ik heb wel enige wat ervaring met het koppelen van ERP systemen aan productiesystemen. Praktisch gezien komt het er doorgaans op neer dat je het ERP systeem van bepaalde klantspecifieke functionaliteit voorziet of gebruik maakt van de standaard functionaliteit en interfaces die het ERP systeem biedt. In het laatste zal je doorgaans een MES systeem, of een zelfgeschreven systeem dat in de ontbrekende functionaliteit voorziet tussen het ERP systeem en de productiesystemen plaatsen.

Wat ik in de praktijk helaas ook nog wel eens tegen ben gekomen is dat iedereen (ERP leverancier, management, ontwikkelaars, leveranciers machinebesturing) langs elkaar heen praat en er op de een of andere manier van uit gaat dat het allemaal samen gaat werken.

Beide benaderingen hebben overigens zo hun voor en nadelen. Maatwerk in een ERP pakket is doorgaans behoorlijk prijzig maar zorgt er wel voor dat je niet met een wildgroei aan zelfgeschreven applicaties en koppelingen zit. Hoe dan ook is het belangrijk om te bepalen welke taken er straks in het ERP systeem uit worden gevoerd, in welke functionaliteit extern voorzien wordt en hoe de koppeling tussen die systemen gaat. Zelfs als er geen directe koppeling tussen de systemen is doe je er goed aan vast te leggen welke functionaliteit van het huidige systeem in de toekomst niet meer gebruikt zal worden en die te verwijderen. Al is het maar om de onderhoudbaarheid te verbeteren en verwarring bij de gebruikers te voorkomen.

[107mb]

het is ook tegenstrijdig. Het huidige -zelfgeschreven- pakket is zeer uitgebreid. DIt ziet de leverancier ook.
Directie heeft weinig verstand van de ict-techniek, en gaat er van uit dat NAV zo uitgebreid is dat er geen maatwerk nodig is. Natuurlijk helpt het ook niet dat men door het huidige pakket huiverig is voor programmeren in het algemeen.

[Tribits]

Als ik het hele verhaal zo lees ben je op de een of andere manier wel stakeholder, maar word je op dit moment eigenlijk op geen enkele manier bij de migratie betrokken. Ik denk dat je voor jezelf op een rijtje moet zetten welke gevolgen dat heeft en wat je er eventueel aan kan doen. Wordt je straks geconfronteerd met ontevreden gebruikers/productiemedewerkers? Bestaat bijvoorbeeld het risico dat je veel overuren moet maken om alles weer werkend te krijgen? Word je verantwoordelijk gehouden voor productieproblemen of kwaliteitsproblemen?

Als je dat op een rijtje hebt hoe groot je belangen zijn kan je zoeken naar mogelijkheden om dat aan te kaarten bij de juiste persoon/afdeling die invloed uit kunnen oefenen op het verloop van de migratie. Punt is dat je daarvoor dus wel initiatief moet nemen en dat brengt ook een zeker risico mee. Het kan goed uitpakken, maar ook verkeerd omdat anderen van mening zijn dat je je onnodig/ongewenst bemoeit met hun werkzaamheden.

Alternatief is niets doen en afwachten hoe het loopt. Risico is dan wel dat je uiteindelijk alsnog verantwoordelijk wordt gehouden als er zaken zijn die niet goed lopen en bovendien extra inspanning moet leveren om de problemen op te lossen.

[bulle bas]

Hoe is dit traject afgelopen @107mb ?

[The Eagle]

Ben ik eerlijk gezegd ook wel nieuwsgierig naar. Ik ben zelf september 2015 de echte ERP uit gegaan (focus nu meer op big data en DB's) maar die wereld nooit uit het oog verloren en mijn kennis niet kwijt
Ik ben wel benieuwd hoe het er mee staat en of idd alles vanilla kan / kon, al dan niet door interne processen aan te passen ipv het systeem.

[Sandor_Clegane]

Dat wordt maatwerk in NAV als je je processen niet aanpast.

Doe je dat niet dan ben je onder de streep net zover, je kan je afvragen of je dan niet beter het huidige kan houden.

Komt nog eens bij dat mensen best slecht tegen veranderingen kunnen, ga je op meerdere vlakken alles aanpassen dan kun je ook nog wel eens te de nodige organisatorische weerstand lopen.

[107mb]

Leuk, een door mij gestart topic weer in lezen geblazen.

We hebben dus voor NAV gekozen. Er is getracht om zoveel mogelijk standaard NAV te gebruiken, door processen volgens NAV te laten verlopen. Daar waar niet anders kan wordt maatwerk toegepast, zoals maatwerktabellen om de product-specificaties vast te kunnen leggen.

Aan de voorkant is een productconfigurator geplaatst, die door het bedrijfsbureau ingericht is.

Ons hele machinepark is aan het oude ERP-systeem gekoppeld. Denk hierbij aan het genereren van CNC-programma's. Dit oude ERP pakket blijven wij gebruiken voor productie-aansturing. Dit doen we voornamelijk om de gehele livegang beheersbaar te houden.

Alle in NAV ingevoerde orders worden volledig in NAV afgehandeld (invoer, planning, logistiek, facturatie enz.), maar voor de productie worden de orders geconverteerd naar de oude ERP software door middel van een maatwerk converter. In NAV krijgt elke bewerking een uniek artikelnummer. Het oude ERP pakket kent bewerkingsnummers. Via een mappingtabel worden de artikel- en bewerkingsnummers gekoppeld.

Naast deze migratie wordt ons machinepark vernieuwd. Elke nieuwe machine wordt op NAV aangesloten, zodat de converter uiteindelijk komt te vervallen. Livegang NAV Q2 2018...

[ Voor 5% gewijzigd door 107mb op 08-01-2018 13:11 ]