Overzetten ERP systeem

[Gomez12]

Ons bedrijf zit nu in de situatie dat wij zijn overgenomen en dat wij ons huidige erp systeem eruit moeten gooien en op het erp systeem van de koper moeten gaan draaien.

Ik ben sysbeheerder/applicatiebeheerder van het huidige systeem.

Mijn vraag is nu hoe kan ik het het beste aanpakken om over te gaan.

Situatie schets :
Ons erp systeem bevat 670 progs die ik allemaal enigzins ken en via odbc 160 tabellen die ik allemaal bijna uit mijn hoofd ken..
Nieuw erp systeem bevat ongeveer 200 progs en via odbc ongeveer 400 tabellen waarvan 125 gevuld zijn.

De planning is om op 1 januari op het nieuwe systeem te zitten, maar nu is mijn vraag hoe is dit het beste aan te pakken.
Ik zie een aantal mogelijkheden :
1 : Ik pak het als alle users aan en vertel iedereen wat er dreigt te gaan veranderen. ( moeilijk te vertellen als ik niet weet wat er onderhuids gaat veranderen )
2 : Ik pak het als sysbeheerder aan en kijk puur naar wat er aan odbc / onderliggend gedeelte gaat veranderen. ( weinig tijd over want er gaat onderhuids vrij veel veranderen en er is bij ons ook geen medewerker die ik goed genoeg inschat om het hele systeem te kennen om uitleg te geven als in 1 )
3 : Ik klooi maar wat aan en hoop dat het huidige softwarebedrijf en het nieuwe software bedrijf er op de 1 of andere manier uitkomen.

En dan is er nog de overgangsfase :
1 : Ik laat het in 1 big bang doen en aanvaard dat elke gebruiker op 1 jan problemen heeft omdat hij niets meer kan vinden.
2 : Ik doe het stukje bij beetje in ons huidige systeem en aanvaard dat een aantal gebruikers bepaalde gedeeltes van ons assortiment niet meer kunnen vinden.

Voorbeeldje van de problemen : Ons huidige erp systeem heeft 7 losse kenmerken per artikel waarop gezocht kan worden, het nieuwe systeem kent de 4 vaste kenmerken zoeknaam, omschrijving, merk, model ( vast kenmerk betekent hierbij dat als iets in zoeknaam staat het ook alleen maar door het veld zoeknaam gevonden kan worden, terwijl het nu zo is dat iemand 3 kenmerken in willekeurige volgorde kan opgeven en dat het dan ook gevonden wordt ). Dit is gewoon een ten 1e een verandering van hoe de users zoeken en te 2e een verandering van hoe de kenmerken in ons systeem zijn opgeslagen. Want als ik voor optie 2 bij overgang ga dan moet ik van te voren zorgen dat alle merken op kenmerk positie 1 staan en alle zoeknamen op kenmerk positie 2 ( staat het nu niet, want was nooit nodig ).

Ik heb er alle vertrouwen in dat als ik de leveranciers van de erp pakketten lat praten dat het totaal goed komt, alleen de details ( zoals hoe iemand een artikel terugvind ) daar zijn zij niet verantwoordelijk voor ( want de software werkt toch ), maar de users komen wel bij mij z**ken.

En ik weet dat het gebruikelijk is om een grootscheepse inventarisatie te maken, hierbij alles te gaan overleggen en daarna pas iets te gaan doen.Maar door de door directie opgelegde deadline van 1 jan 2006 denk ik door het aantal tabellen, en door het aantal ongebruikte tabellen in het nieuwe systeem ( worden zij bewust niet gebruikt omdat zij onhandig zijn of zijn het gewoon overbodige tabellen in hun erp systeem ) dat het ondoenbaar is om een werkbare current-situation new-situation profile op te zetten.

P.S. De beheerder van het nieuwe bedrijf heeft al toegegeven dat hij niks van hun erp-systeem weet, dus daar krijg ik ook geen info van over ongebruikte delen van het systeem.

P.P.S. Het advies naar de directie dat dit erg prematuur is voor 1 januari 2006 is er ook al uitgegaan, maar directie zegt dat dit MOET!!!

Wat is nu handigste manier om dit aan te pakken???

[Verwijderd]

Is het geen optie om gewoon het oude systeem te laten voor wat het is, en met het nieuwe verder te gaan? Eventuele historische data kan dan in het oude systeem opgezocht worden, en je begint met een schoon en fris nieuw systeem.

Mijn ervaring met conversies zoals jij hier omschrijft, is dat het uiteindelijk net zoveel tijd kost als handmatig opnieuw invoeren en dat er ALTIJD bakken vol gezeik en ergenis uit voort komt.

Als je dan toch voor een conversie kiest, maar niet de tijd hebt om het goed te doen (wat ik uit jouw verhaal opmaak), concentreer je dan op de grote tabellen (bv. artikelen) en doe dit goed. Voer de rest handmatig in.

[Verwijderd]

Bij dit soort conversies zou ik kijken naar wat het nieuwe systeem aanbiedt aan 'opstarttools' (importscripts ed) die ze gebruiken wanneer een nieuwe klant start. Dan exports voorbereiden van de data het oude systeem en imports testen in het nieuwe. Users opleiden in het nieuwe systeem (bij klachten: verwijzen naar directie) en op dag X imports in het nieuwe systeem.

In de praktijk zal het zo vlot wel niet gaan en zal er een del export-import gewoon overtypen zijn..

[Jazzy]

Gomez12 schreef op dinsdag 28 juni 2005 @ 00:38:
Wat is nu handigste manier om dit aan te pakken???

Maak je niet te veel zorgen om de techniek, dat gaat (vast) wel goed komen.

De grote uitdaging zit bij de gebruikers, voor jun zal namelijk hun manier van werken gaan veranderen en dat is zo'n beetje het meest heftige wat er kan gebeuren. Mijn advies is om te werken met een stuurgroepje met een aantal key-users/powerusers uit de verschillende afdelingen. Zorg dat het personeel weet wat er gaat veranderen en dat het door hun gedragen wordt.

Dan nog even over de migratie zelf. Ik raad je aan om 1 partij verantwoordelijk te stellen voor de migratie en het niet aan de beide partijen over te laten. Zo voorkom je kastje muur situaties. Verder moet het voor iedere betrokkene duidelijk zijn (of in deze fase duidelijk worden) wat het eindresultaat moet zijn.

Ik weet niet hoe groot jullie bedrijf is maar misschien is het verstandig om voor deze klus een professional in te schakelen. Kan een hogere manager zijn met gevoel voor IT en processen maar kan ook heel goed een externe adviseur zijn. Nogmaals, de grootste uitdaging zit op het vlak van de mensen. De andere uitdaging is om het niet te veel vanuit de techniek te bekijken. Sterkte.

[Grolsch]

zorg dat je de mensen een kluif voorhoudt ipv ze achterna te zitten met een stok.

Je moet zorgen dat ze enthousiast zijn, en dat gaan niet makkelijk worden.

[BlackLight]

Begrijp ik het goed dat je dit zelf (alleen in je uppie) moet plannen, testen en implementeren? Dan lijkt me 1 januari niet haalbaar.

Ik zou proberen om consultants van de nieuwe software erbij te betrekken, die hebben de meeste ervaring met switchen naar hun pakket, en dan kun jij (als je wil) meer het project bewaken. Enige nadeel is dat hier kosten aan zijn verbonden. Voordeel is dat je hun verantwoordelijk kunt stellen voor eventueel optredende problemen.

Ik wil je niet ongerust maken, maar overgaan van pakket a naar pakket b is (voor een persoon) een klus die zijn weerga niet kent.

[Verwijderd]

Gomez12 schreef op dinsdag 28 juni 2005 @ 00:38:

- Contact opnemen met de leverancier van het doelsysteem om informatie met betrekking tot importeren vanuit andere ERP systemen
- Zorgen voor een testomgeving, identiek aan de produktie omgeving zodat je niet op produktie gaat migreren
- Aangezien het MT vind dat het moet, zou ik op de allereerste plaats een reactie terugsturen met de risico's die het kan opleveren voor de algehele bedrijfsvoering, dat er hoge kosten aan een verkeerde migratie zitten, en dat je daar niet de verantwoordelijkheid voor wilt dragen. Indien ze door willen gaan, prima, maar dan is het MT verantwoordelijk voor een eventuele situatie.
- Rekening houden dat je 50/50 migratietijd en testtijd hebt. Als er blijkt dat na de schijnbaar succesvolle migratie de data integriteit in het systeem naar de klote is heb je misschien een nog groter probleem.
- Opzetten testplannen, hoe testen, wat testen, waar meld ik issues aan, wie lost ze op.
- Migreren van de omgeving naar staging
- Testen, testen, testen, testen.
- Zorgen dat je van de produktieomgeving een spiegel hebt die je bij een verkeerde migratie direct kan terugplaatsen.
- Final migratie

Kortom, er is nog flink wat werk aan de winkel. Gezien je omschrijving, zou ik echt heel dringend gaan kijken naar externe hulp. Als alles vloeiend overgaat is het heel leuk, maar als er maar iets fout gaat ben je zwaar de sigaar, zeker met zoveel informatie.

[ Voor 68% gewijzigd door Verwijderd op 28-06-2005 13:17 ]

[Gomez12]

Sorry voor de late reacties, heb even gezellig de hele dag zitten vergaderen...

Verwijderd schreef op dinsdag 28 juni 2005 @ 00:42:
Is het geen optie om gewoon het oude systeem te laten voor wat het is, en met het nieuwe verder te gaan? Eventuele historische data kan dan in het oude systeem opgezocht worden, en je begint met een schoon en fris nieuw systeem.

Mijn ervaring met conversies zoals jij hier omschrijft, is dat het uiteindelijk net zoveel tijd kost als handmatig opnieuw invoeren en dat er ALTIJD bakken vol gezeik en ergenis uit voort komt.

Als je dan toch voor een conversie kiest, maar niet de tijd hebt om het goed te doen (wat ik uit jouw verhaal opmaak), concentreer je dan op de grote tabellen (bv. artikelen) en doe dit goed. Voer de rest handmatig in.

Geen optie, wij hebben een artikelbestand van 25.000 artikelen en kortingen en prijzen kunnen per klant per artikel verschillen, dit tik je niet zomaar even.

Het technisch overzetten is te doen, ik heb op dit moment al 2 testomgevingen draaien ( van elk systeem 1 ). tijd is bij technisch overzetten ook niet zo'n erg groot probleem ( alleen vervallen enkele wensen van de directie waarschijnlijk ). Het gaat mij meer om het totaal plaatje.

Verwijderd schreef op dinsdag 28 juni 2005 @ 09:24:
Bij dit soort conversies zou ik kijken naar wat het nieuwe systeem aanbiedt aan 'opstarttools' (importscripts ed) die ze gebruiken wanneer een nieuwe klant start. Dan exports voorbereiden van de data het oude systeem en imports testen in het nieuwe. Users opleiden in het nieuwe systeem (bij klachten: verwijzen naar directie) en op dag X imports in het nieuwe systeem.

In de praktijk zal het zo vlot wel niet gaan en zal er een del export-import gewoon overtypen zijn..

importscripts zijn er niet echt ( want het is een schitterend zo goed als maatwerk erp-pakket ). En overtypen is niet echt een optie ( het is niet echt 1 excell sheet waar alles instaat )

Jazzy schreef op dinsdag 28 juni 2005 @ 09:32:
[...]
Maak je niet te veel zorgen om de techniek, dat gaat (vast) wel goed komen.

De grote uitdaging zit bij de gebruikers, voor jun zal namelijk hun manier van werken gaan veranderen en dat is zo'n beetje het meest heftige wat er kan gebeuren. Mijn advies is om te werken met een stuurgroepje met een aantal key-users/powerusers uit de verschillende afdelingen. Zorg dat het personeel weet wat er gaat veranderen en dat het door hun gedragen wordt.

Dit is ook allemaal geregeld, trainingen en testomgeving voor de gebruikers zijn verantwoordelijkheid nieuwe leverancier, hoe en wanneer hij dit doet mag hij zelf weten.

Dan nog even over de migratie zelf. Ik raad je aan om 1 partij verantwoordelijk te stellen voor de migratie en het niet aan de beide partijen over te laten. Zo voorkom je kastje muur situaties. Verder moet het voor iedere betrokkene duidelijk zijn (of in deze fase duidelijk worden) wat het eindresultaat moet zijn.

Ik weet niet hoe groot jullie bedrijf is maar misschien is het verstandig om voor deze klus een professional in te schakelen. Kan een hogere manager zijn met gevoel voor IT en processen maar kan ook heel goed een externe adviseur zijn. Nogmaals, de grootste uitdaging zit op het vlak van de mensen. De andere uitdaging is om het niet te veel vanuit de techniek te bekijken. Sterkte.

Kastje muur situaties zitten allemaal verwerkt in een contract ( in opbouw op dit moment ) waarin alle eisen staan. Zijn we niet zo bang voor. Het inhuren van iemand is misschien wel een verstandig plan ( allebei niet zulke grote bedrijven en erp-pakketten zijn ook allebei redelijk maatwerk die van hun bijna compleet, hier zitten dus ook geen grote partijen achter )
Gaan we voorstellen.

[Gomez12]

Sorry voor de late reacties, heb even gezellig de hele dag zitten vergaderen...

Verwijderd schreef op dinsdag 28 juni 2005 @ 00:42:
Is het geen optie om gewoon het oude systeem te laten voor wat het is, en met het nieuwe verder te gaan? Eventuele historische data kan dan in het oude systeem opgezocht worden, en je begint met een schoon en fris nieuw systeem.

Mijn ervaring met conversies zoals jij hier omschrijft, is dat het uiteindelijk net zoveel tijd kost als handmatig opnieuw invoeren en dat er ALTIJD bakken vol gezeik en ergenis uit voort komt.

Als je dan toch voor een conversie kiest, maar niet de tijd hebt om het goed te doen (wat ik uit jouw verhaal opmaak), concentreer je dan op de grote tabellen (bv. artikelen) en doe dit goed. Voer de rest handmatig in.

Geen optie, wij hebben een artikelbestand van 25.000 artikelen en kortingen en prijzen kunnen per klant per artikel verschillen, dit tik je niet zomaar even.

Het technisch overzetten is te doen, ik heb op dit moment al 2 testomgevingen draaien ( van elk systeem 1 ). tijd is bij technisch overzetten ook niet zo'n erg groot probleem ( alleen vervallen enkele wensen van de directie waarschijnlijk ). Het gaat mij meer om het totaal plaatje.

Verwijderd schreef op dinsdag 28 juni 2005 @ 09:24:
Bij dit soort conversies zou ik kijken naar wat het nieuwe systeem aanbiedt aan 'opstarttools' (importscripts ed) die ze gebruiken wanneer een nieuwe klant start. Dan exports voorbereiden van de data het oude systeem en imports testen in het nieuwe. Users opleiden in het nieuwe systeem (bij klachten: verwijzen naar directie) en op dag X imports in het nieuwe systeem.

In de praktijk zal het zo vlot wel niet gaan en zal er een del export-import gewoon overtypen zijn..

importscripts zijn er niet echt ( want het is een schitterend zo goed als maatwerk erp-pakket ). En overtypen is niet echt een optie ( het is niet echt 1 excell sheet waar alles instaat )

Jazzy schreef op dinsdag 28 juni 2005 @ 09:32:
[...]
Maak je niet te veel zorgen om de techniek, dat gaat (vast) wel goed komen.

De grote uitdaging zit bij de gebruikers, voor jun zal namelijk hun manier van werken gaan veranderen en dat is zo'n beetje het meest heftige wat er kan gebeuren. Mijn advies is om te werken met een stuurgroepje met een aantal key-users/powerusers uit de verschillende afdelingen. Zorg dat het personeel weet wat er gaat veranderen en dat het door hun gedragen wordt.

Dit is ook allemaal geregeld, trainingen en testomgeving voor de gebruikers zijn verantwoordelijkheid nieuwe leverancier, hoe en wanneer hij dit doet mag hij zelf weten.

Dan nog even over de migratie zelf. Ik raad je aan om 1 partij verantwoordelijk te stellen voor de migratie en het niet aan de beide partijen over te laten. Zo voorkom je kastje muur situaties. Verder moet het voor iedere betrokkene duidelijk zijn (of in deze fase duidelijk worden) wat het eindresultaat moet zijn.

Ik weet niet hoe groot jullie bedrijf is maar misschien is het verstandig om voor deze klus een professional in te schakelen. Kan een hogere manager zijn met gevoel voor IT en processen maar kan ook heel goed een externe adviseur zijn. Nogmaals, de grootste uitdaging zit op het vlak van de mensen. De andere uitdaging is om het niet te veel vanuit de techniek te bekijken. Sterkte.

Kastje muur situaties zitten allemaal verwerkt in een contract ( in opbouw op dit moment ) waarin alle eisen staan. Zijn we niet zo bang voor. Het inhuren van iemand is misschien wel een verstandig plan ( allebei niet zulke grote bedrijven en erp-pakketten zijn ook allebei redelijk maatwerk die van hun bijna compleet, hier zitten dus ook geen grote partijen achter )
Gaan we voorstellen.

BlackLight schreef op dinsdag 28 juni 2005 @ 13:05:
Begrijp ik het goed dat je dit zelf (alleen in je uppie) moet plannen, testen en implementeren? Dan lijkt me 1 januari niet haalbaar.

Ik zou proberen om consultants van de nieuwe software erbij te betrekken, die hebben de meeste ervaring met switchen naar hun pakket, en dan kun jij (als je wil) meer het project bewaken. Enige nadeel is dat hier kosten aan zijn verbonden. Voordeel is dat je hun verantwoordelijk kunt stellen voor eventueel optredende problemen.

Niet in mijn uppie, maar ik zie nu al tig excell bestanden over en weer vliegen van verkopers en inkopers die zien dat iets bij het andere bedrijf goedkoper is en dat wij het maar even moeten aanpassen, en op dit moment wordt er een grote onrust in het bedrijf gecreeerd omdat mensen vanalles in ons systeem lukraak aan het aanpassen zijn omdat ze denken dat dit beter is en helpt, maar doe het liever volgens een planning waardoor ik het overzicht behoud wat er al gebeurd is en wat er nog moet gaan gebeuren. Hiervoor heb ik ook gezegd dat mensen moeten stoppen met het lukraak veranderen van dingen, toen werd mij alleen gezegd dat ik dus maar met een werkbaar plan moest komen hoe het aan te pakken... En toen dacht ik misschien dat GoT nog een paar goede ideeen heeft.

Verwijderd schreef op dinsdag 28 juni 2005 @ 13:14:
[...]


- Contact opnemen met de leverancier van het doelsysteem om informatie met betrekking tot importeren vanuit andere ERP systemen

Weinig tot geen, dit is al gebeurd, zij hebben geen standaard import scripts

- Zorgen voor een testomgeving, identiek aan de produktie omgeving zodat je niet op produktie gaat migreren

Heb ik nu van beide systemen, dus dit zit wel goed.

- Aangezien het MT vind dat het moet, zou ik op de allereerste plaats een reactie terugsturen met de risico's die het kan opleveren voor de algehele bedrijfsvoering, dat er hoge kosten aan een verkeerde migratie zitten, en dat je daar niet de verantwoordelijkheid voor wilt dragen. Indien ze door willen gaan, prima, maar dan is het MT verantwoordelijk voor een eventuele situatie.

Is al gestuurd, alleen niet zo letterlijk als jij hier zegt. Misschien nog een 2e brief schrijven.

- Opzetten testplannen, hoe testen, wat testen, waar meld ik issues aan, wie lost ze op.

Document wordt al opgesteld, wordt alleen vrij groot groter dan ik in 1e instantie dacht.

- Migreren van de omgeving naar staging
- Testen, testen, testen, testen.

Alles tot 1 jan vind plaats in testomgeving en op 1 jan vind er een "big bang" plaats, alleen ons huidige productie systeem wordt wel voorbereid op het nieuwe systeem ( vb. huidig systeem heeft 5 zoekmogelijkheden,ongespecificeerd, nieuwe systeem heeft 4 zoekmogelijkheden, gespicificeerd als kleur, model, merk etc dus nu wordt in ons huidige systeem de zoekmogelijkheid 1 stukje bij beetje veranderd naar kleur zodat we straks kunnen zeggen : zoekmogelijkheid 1 = kleur, zoekmogelijkheid 2 = model etc )

- Zorgen dat je van de produktieomgeving een spiegel hebt die je bij een verkeerde migratie direct kan terugplaatsen.

Bedoel je hiermee dat er een x periode schaduwwerken moet plaatsvinden. Want technisch is dit haalbaar om dit onzichtbaar voor de gebruiker te doen, dus zou de gebruiker echt 2x iets moeten invoeren en van gebruikers ben ik liever niet afhankelijk...

Als toevoeging nog : Het is niet dat ik alles zelf moet doen, ik heb ongeveer 20 duur betaalde tikgeiten zitten ( volgens hun functie omschrijving zijn ze andere dingen maar zoiets als dit breekt wet ) die kunnen heel veel werk doen. Maar het was meer een algemene aanpak vraag.

En het idee van een externe adviseur wordt serieus voorgedragen. Want ik zie toch enkele problemen opkomen die imho heel erg lastig te tackelen zijn terwijl iemand met ervaring zegt dat moet je zus of zo doen.

[Verwijderd]

[b]Gomez12 schreef op dinsdag 28 juni 2005 @ 23:05:Geen optie, wij hebben een artikelbestand van 25.000 artikelen en kortingen en prijzen kunnen per klant per artikel verschillen, dit tik je niet zomaar even.

Verkijk je hier niet op. Stel 1 typgeit doet 40 van die dingen op een dag (moet toch kunnen, 5 per uur). Dan doen die 20 typgeiten van jou er 800 op een dag. In totaal zijn ze dan iets meer dan een maand bezig. Zeg dat je dan nog 25.000 'restrecords' hebt (klanten, etc). Dan zit je op iets van 2,5 maand werk.

Met andere woorden: als je ze morgen laat beginnen, ben je medio september klaar. Dit zonder ellenlang vooronderzoek of documentatie, zonder conversieconflicten, zonder externe krachten enz. Daarbij komt dan dat je tikgeiten gelijk bekend zijn met het pakket.

Maar goed.. ik begrijp dat je die optie een no-go vindt.

Op zich kan het verstandig zijn een extern iemand in te huren, echter bedenk je van te voren wat die persoon dan zou moeten doen. Als ik het zo aanhoor ben jij waarsch. beter thuis in de applicaties en databases dan de persoon die je inhuurt.

Wat voor nut zou een extern persoon voor jou kunnen hebben? Wat verwacht je ervan?

Ik waarschuw je alvast.. stel je huurt iemand in bij een grote automatiseerder. Je betaalt dan 90 euro p/u voor de lichtste prutser die ze rond hebben lopen. Daar heb je echt geen ruk aan. Wil je een beter iemand, worden de prijzen ook al anders. Ga dus alleen kijken naar externe personen als je ook daadwerkelijk het budget ervoor hebt.

[ Voor 5% gewijzigd door Verwijderd op 29-06-2005 00:53 ]

[Gomez12]

Verwijderd schreef op dinsdag 28 juni 2005 @ 23:58:
[...]


Verkijk je hier niet op. Stel 1 typgeit doet 40 van die dingen op een dag (moet toch kunnen, 5 per uur). Dan doen die 20 typgeiten van jou er 800 op een dag. In totaal zijn ze dan iets meer dan een maand bezig. Zeg dat je dan nog 25.000 'restrecords' hebt (klanten, etc). Dan zit je op iets van 2,5 maand werk.

Met andere woorden: als je ze morgen laat beginnen, ben je medio september klaar. Dit zonder ellenlang vooronderzoek of documentatie, zonder conversieconflicten, zonder externe krachten enz. Daarbij komt dan dat je tikgeiten gelijk bekend zijn met het pakket.

Maar goed.. ik begrijp dat je die optie een no-go vindt.

Problemen genoeg die moeilijk op te lossen zijn door een tikgeit, en 20 tikgeiten aan je kop hebben praten is nou ook niet echt goed voor je functioneren.Want sommige structuren zijn in ons huidige pakket anders geimplementeerd als in het nieuwe pakket. Simpel voorbeeldje, in ons huidige pakket is een klant prijs te beinvloeden door 12 factoren, in het nieuwe pakket door 8. Wat moet er met de overige 4 gebeuren, dit moet eerst geinventariseerd worden, tijdens deze inventarisatie worden dingen vergeten. Dus ik kan niet simpel een stel "tikgeiten" dingen laten invoeren, want ik heb op dit moment nog geen exact beeld wat ik tegen ga komen...

Op zich kan het verstandig zijn een extern iemand in te huren, echter bedenk je van te voren wat die persoon dan zou moeten doen. Als ik het zo aanhoor ben jij waarsch. beter thuis in de applicaties en databases dan de persoon die je inhuurt.

Wat voor nut zou een extern persoon voor jou kunnen hebben? Wat verwacht je ervan?

Ons huidige pakket ken ik goed, maar het nieuwe pakket schijnt op dit moment niemand te kennen zoals wij het moeten gaan gebruiken ( tenminste het totaalplaatje ). En een extern persoon kan er nuchter naar kijken en uit ervaring met andere overgangen dingen zien waar wij ons compleet op blindstaren omdat wij alleen maar met ons huidige pakket hebben gewerkt en er aan de andere kant niemand staat met een totale blik op het pakket.

Ik waarschuw je alvast.. stel je huurt iemand in bij ... oid. Je betaalt dan 90 euro p/u voor de lichtste prutser die ze rond hebben lopen. Daar heb je echt geen ruk aan. Wil je een beter iemand, worden de prijzen ook al anders. Ga dus alleen kijken naar externe personen als je ook daadwerkelijk het budget ervoor hebt.

Ik bedoelde ook niet echt iemand van 90 euro p/u, dit is gewoon programmeur. Maar meer iemand in de trant van 400 / 500 euro p/u. Het is ook niet mijn idee om hem tot 1 jan 40 uur per week te laten werken, maar gewoon adviseur zijn etc. Wij hebben gewoon nog nooit zoiets aangepakt en zijn bang dat wij ons blindstaren op wat we nu hebben...

[ Voor 5% gewijzigd door Gomez12 op 29-06-2005 08:34 . Reden: Stond er een beetje cru ]

[Verwijderd]

Gomez12 schreef op woensdag 29 juni 2005 @ 00:25:
Dus ik kan niet simpel een stel "tikgeiten" dingen laten invoeren, want ik heb op dit moment nog geen exact beeld wat ik tegen ga komen...

Akkoord.

Ons huidige pakket ken ik goed, maar het nieuwe pakket schijnt op dit moment niemand te kennen zoals wij het moeten gaan gebruiken ( tenminste het totaalplaatje ). En een extern persoon kan er nuchter naar kijken en uit ervaring met andere overgangen dingen zien waar wij ons compleet op blindstaren omdat wij alleen maar met ons huidige pakket hebben gewerkt en er aan de andere kant niemand staat met een totale blik op het pakket.

Het kan nooit kwaad extern advies in te winnen als je niet zeker bent van je zaak, zonder meer. Het is echter niet louter hosanna, het brengt kosten met zich mee en mogelijk vertraging. Maar goed, als het kritische data is en het budget is er voor, ben je natuurlijk gek als je het niet doet, indien je geen zekerheid hebt.

De vraag is; is er reden tot onzekerheid? Als ik lees wat je tot nu toe gedaan hebt en de tijd die je er nog voor hebt, kom je er volgens mij prima zelf uit. Verder lees ik in je post ook dat kennelijk niemand weet hoe je het betreffende ERP in dat bedrijf moet implementeren.

Is er een ontwikkelteam? Of ben jij het ontwikkelteam?

Wat mij betreft bestaat een ontwikkelteam op z'n minst uit een ontwikkelaar, een beheerder, een vertegenwoordiging van eindgebruikers en - als het kan - iemand met de bevoegdheid om beslissingen te nemen (bv. iemand uit het MT). Dit zou je kunnen laten voorzitten door een extern iemand.

Verder hoor ik je zeggen:

dat het ondoenbaar is om een werkbare current-situation new-situation profile op te zetten.

Het klinkt alsof je toch bezig bent dat te doen, wat op zich geen verkeerd plan is uiteraard, maar gezien eht feit dat je aangeeft dat het in deze situatie ondoenbaar is, ontkom je bijna niet aan 'externen'. Gezien je doelstelling lijkt het me dat je dan meer aan een techneut hebt, dan aan een 'adviseur', mits die techneut z'n vak verstaat uiteraard.

Je zou in de testfase kunnen overwedigen een volledige mirror-setup te gaan draaien voor een gelimiteerd aantal producten en/of klanten. Dit houdt in dat je alle handelingen welke normaliter in het proces voorkomen in beide systemen laat uitvoeren. Daarna leg je de resultaten naast elkaar. Eventueel zou je dit zelfs (met bv. 1 of 2 klanten en 1 iemand uit het personeel) heel vroeg in het ontwikkeltraject kunnen starten. Klanten zijn best bereid te helpen bij dit soort projecten (eventueel tegen een korting, wat vaak goedkoper is dan testers inhuren) en op die manier krijg je problemen en/of verschillen snel in kaart.

offtopic:
zou je de naam van het bedrijf wat ik noemde willen weg-editten in je quote? Dat was een onnodige flame van me

[Jazzy]

Verwijderd schreef op woensdag 29 juni 2005 @ 01:38:
Gezien je doelstelling lijkt het me dat je dan meer aan een techneut hebt, dan aan een 'adviseur', mits die techneut z'n vak verstaat uiteraard.

Nee, die techniek is bijzaak en moet je overlaten aan de opdrachtnemer. Je moet iemand hebben die verstand heeft van processen, informatiestromen en bovenal iemand die weet hoe je verandering moet implementeren. Er is al vaker gezegd dat er een grote uitdaging komt voor de mensen die nu een verandering gaan meemaken, daar moet je je op focussen. Zorgen dat het een succes wirdt dus.

[jwpmzijl]

Hmm iets te snel op verzenden geklikt.....

[ Voor 98% gewijzigd door jwpmzijl op 30-06-2005 12:01 ]

[Verwijderd]

Jazzy schreef op woensdag 29 juni 2005 @ 06:35:
Nee, die techniek is bijzaak en moet je overlaten aan de opdrachtnemer. Je moet iemand hebben die verstand heeft van processen, informatiestromen en bovenal iemand die weet hoe je verandering moet implementeren. Er is al vaker gezegd dat er een grote uitdaging komt voor de mensen die nu een verandering gaan meemaken, daar moet je je op focussen. Zorgen dat het een succes wirdt dus.

De techniek is helemaal geen bijzaak, wat een onzin zeg. De techniek is mede hoofdzaak.

Je kunt nog zo goed je zaakjes georganiseerd hebben, als je niet voldoende FTE's hebt om het uit te voeren zal het niet gebeuren.

TS geeft duidelijk aan dat hij nu niet voeldoende FTE's heeft. Daar veranderd geen manager wat aan.

Dus.. iemand inhuren zoals jij omschrijft kan verstandig zijn, echter een techneut inhuren is onvermijdelijk. Tenminste, als je je mooie plan ook op tijd af wilt hebben..