Ontwikkelen ERP: welke omgeving?

[Verwijderd]

Hoi tweakers,

Onze organisatie staat aan de voet van de ontwikkeling van een nieuw ERP systeem. Omdat veel maatwerk is vereist, is er voor gekozen geen ERP-systeem aan te schaffen. Intern vloeien veel discussies over de keuze van de ontwikkelomgeving waarin het systeem geschreven zal gaan worden. Wellicht zijn ditsoort discussies eerder op het forum aan bod gekomen. Toch zou ik graag een objectief advies krijgen van een aantal tweakers!

Het systeem zal o.a. voor een verband zorgen tussen verkoop, orders, calculatie, voorraad, inkoop, etc. Een snel en stabiel werkend systeem is een strenge eis binnen onze organisatie. Er zullen veel koppelingen worden gemaakt met software (o.a. boekhoudsoftware), hardware (scanners, printers). Specifieke printers en printerbakken moeten kunnen worden aangestuurd.

Discussies die gaande zijn: Open source vs. Closed Source en vooral Webbased vs. Clientbased. Webbased heeft uiteraard het voordeel dat er op elke PC met een browser kan worden ingelogd. Maar brengt het niet te veel complicaties met zich mee? Is het werken op een andere locatie (zoals thuis) toch goed mogelijk in het geval van een Clientbased applicatie? Natuurlijk is het bouwen van een ERP-systeem voor elke keuze mogelijk. Maar welke is de meest geschikte? Hopelijk kunnen jullie me op weg helpen naar een goede keuze.

Alvast bedankt!

Grard

[mulder]

Tja dan zul je toch in de organisatie moeten gaan kijken, welke kennis hebben we al, welk platform(s) gebruiken we al, waar gaat het gebruikt worden. Er is zo geen eenduidige antwoord te geven.

[Verwijderd]

Als je je daar al druk om maakt, hoef je niet eens te beginnen aan een ERP systeem...

[Verwijderd]

Ontwikkelomgeving is ondergeschikt aan een ERP systeem vind ik. Zolang je maar genoeg beveiliging, etc kunt inbouwen. Daarbij moet ik zeggen dat je niet zomaar een ERP systeem maakt. Ik weet niet hoe groot jullie organisatie is, maar enig verstand van administratieve activiteiten, logistieke activiteiten, AO, audits, functiescheiding etc is wel nodig wil je uberhaupt een opzet maken hiervoor. Zeker als je een organisatie hebt met complexe materiaal, administratieve stromen en complexe informatiestromen. Dit doe je niet zomaar even.

[BCC]

Over wat voor soort bedrijf gaat het?

[whoami]

Alles hangt af van de eisen; wat moet het systeem kunnen, moet het via het web bereikbaar zijn, moet je een rijke UI hebben, kan het met een smartclient, welke kennis is in huis, etc...

Verwacht niet dat je hier een eenduidig antwoord krijgt over hoe en wat je nu precies moet gaan doen. De enige die dat weet, zijn de mensen binnen jouw bedrijf.

[bastv]

een eigen ERP systeem.... poepoe heb je een paar jaar de tijd?
Er zijn genoeg erp pakketten die een goede basis geven en zelf development tools bij leveren zodat je je eigen maatwerk kan maken/koppelingen.
is natuurlijk niet goedkoop maarjah een ERP systeem zelf bouwen kost heel wat tijd en dat is vaak nog duurder.

[Verwijderd]

De overweging tot aanschaf van een pakket bleek geen geschikte keuze te zijn, simpel weg omdat we een organisatie zijn in de ontzettend dynamische wereld van telecommunicatie en teveel maatwerk is vereist.

Het zal absoluut geen systeem worden als bijvoorbeeld SAP, de organisatie telt ongeveer 25 werknemers. Aan verstand van de organisatie en de genoemde activiteiten is geen tekort. Een externe partij verricht tevens hun medewerking, maar zij zijn van een geheel andere mening over de keuze van een ontwikkelomgeving dan onze interne automatiseringsafdeling.

Kennis hebben we in princiepe voldoende in huis. In eerste instantie hoeft het systeem slechts bereikbaar te zijn binnen het bedrijfspand. Wellicht dat in de toekomst wel op locatie gewerkt gaat worden, dat is nu echter nog niet aan de orde. Een rijke user interface is wel een wens.

Smart-based is wellicht een goed alternatief. Is er iemand die ervaringen heeft met het ontwikkelen van een webbased ERP-systeem. Brengt het niet te veel complicaties met zich mee als het maken van koppelingen met andere pakketten en hardware?

[mulder]

Is er iemand die ervaringen heeft met het ontwikkelen van een webbased ERP-systeem. Brengt het niet te veel complicaties met zich mee als het maken van koppelingen met andere pakketten en hardware?

Kort gezegd: net zoveel als een windowapplicatie.

[Grijze Vos]

Verwijderd schreef op vrijdag 17 maart 2006 @ 10:55:
De overweging tot aanschaf van een pakket bleek geen geschikte keuze te zijn, simpel weg omdat we een organisatie zijn in de ontzettend dynamische wereld van telecommunicatie en teveel maatwerk is vereist.

Euhm, ERP paketten als JD Edwards zijn er juist om op maat geconfigureerd te worden.
Als ik me het goed herinner had dit pakket ongeveer 8 miljoen configuratie opties.

[xtra]

Don Facundo schreef op vrijdag 17 maart 2006 @ 11:20:
[...]

Kort gezegd: net zoveel als een windowapplicatie.

Lang gezegd: Bij een beetje multi-tier applicatie heeft de client niet veel meer te doen dan gegevens presenteren en invoer verwerken. Alle logica zit in een andere laag. De client kan een Windows-applicatie zijn of een webapplicatie of beide. Als je met standaardprotocollen communiceert kan zowel een Windows-applicatie als een webapplicatie op afstand worden gebruikt.

Tot nu toe heb ik weinig webapplicaties gezien waarmee je net zo snel kunt werken als met een 'gewone' applicatie. Doordat je vaak met verschillende pagina's werkt kost dezelfde taak meer tijd. Voor mensen die er de hele dag mee moeten werken is dat geen succes.

Het lijkt erop dat jullie de wensen en eisen nog niet volledige op papier hebben. Als je dat hebt kun je dit soort vragen vrij eenvoudig beantwoorden.

[JKVA]

Toch is het goed mogelijk dat er met webapplicaties snel gewerkt kan worden. Op mijn werk hebben we een groothandelsysteem ontwikkeld met als sterkste punt dat het zo snel werkt. Door gebruik te maken van veel JavaScript en CSS open je een complex scherm in nog geen seconde, want die worden gecached zodat de pagina klein blijft. Hiervoor moeten echter ook zaken als database en andere lagen getweaked worden om de pagina's snel te genereren. Met behulp van JavaScript worden zaken als inline autoaanvullen, lookupfuncties en AJAX-based opslaan en zo geregeld.

Over het meningsverschil tussen de externe partij en de automatiseringsafdeling, probeer zo veel mogelijk de mening te volgen van de externe partij (eventueel na oordeel van derden). Mijn ervaring is namelijk dat de automatiseringsafdeling vaak voornamelijk aan zichzelf denkt en niet zit te wachten op een hoop extra (over)werk.

Ps. Niet allemaal gaan flamen. Er zijn ook vast wel goede systeembeheerders, maar mijn ervaring is dat ze meestal nogal terughoudend zijn.

Ps2. Ga niet proberen zelf zoiets te maken. Een ERP systeem maken is heel complex en er komen veel meer dingen bij kijken dan alleen je bedrijfsprocessen. Bijvoorbeeld op het gebied van GUI, security en performance is veel specifieke kennis vereist.

[Verwijderd]

Bedankt voor jullie reacties! Op het Internet zijn weinig concrete praktijk voorbeelden te vinden voor een vergelijkbare situatie. Webbased is een goede optie, zeker gezien het feit dat men eenvoudig vanaf vrijwel elke locatie in kan loggen in je systeem. Er is echter wat vrees voor complicaties bij de koppeling met hardware en software en dat het ten koste zal gaan voor de snelheid.

Een aantal functies die het systeem zou moeten bevatten zijn o.a. orders invoeren, facturen en offertes uitdraaien, uitdraaien van pakbonnen (koppeling met voorraad), scannen van artikelen bij ontvangst, koppeling boekhoudpakket, koppeling met een ander (clientbased) softwarepakket. Het systeem moet snel en stabiel zijn voor een groot aantal (25) gebruikers.

[FragileM64]

Als jullie zelf geen programmatuur schrijven, dan wordt dit toch een harde noot om te kraken. Voor een ERP te schrijven heb je héél wat kennis en tijd en mankracht nodig en dan bedoel ik niet alleen dat je moet kunnen programmeren. Je zou zo'n grote opdracht beter volledig uitbesteden aan een externe firma die ervaring heeft met dit zaken. Anders is er een grote kans dat je applicatie het gegeven tijdsbestek en budget overschrijdt gewoonweg omdat intern de ervaring ontbreekt

Zoals xtra al zei kan je het vrij gemakkelijk uitbreiden naar een webbased applicatie als de protocollen eenduidig zijn ontwikkeld een gedocumenteerd.
Als jullie het toch zelf doen, vergeet niet eerst alles op papier uit te plannen tot in de kleinste details. Niks is belangrijker dan een grondige definitiestudie en een daaropvolgende planning. Dit kost véél tijd maar dan kom je later niet in de miserie

[Verwijderd]

[/quote]
Over het meningsverschil tussen de externe partij en de automatiseringsafdeling, probeer zo veel mogelijk de mening te volgen van de externe partij (eventueel na oordeel van derden). Mijn ervaring is namelijk dat de automatiseringsafdeling vaak voornamelijk aan zichzelf denkt en niet zit te wachten op een hoop extra (over)werk.
[quote]

Helaas krijg ik het gevoel dat de externe partij ons te veel naar díe omgeving toepraat waarvan zij veel kennis in huis hebben. Niet erg objectief naar mijn mening en waarschijnlijk met de bedoeling zoveel mogelijk werk naar zich toe te trekken, omdat ook zij in de ontwikkeling mee gaan werken.

[djluc]

Helaas krijg ik het gevoel dat de externe partij ons te veel naar díe omgeving toepraat waarvan zij veel kennis in huis hebben. Niet erg objectief naar mijn mening en waarschijnlijk met de bedoeling zoveel mogelijk werk naar zich toe te trekken, omdat ook zij in de ontwikkeling mee gaan werken.

Dat gebeurt heel veel inderdaad. Je hebt het over een serieuze situatie, misschien is het een idee om een onafhankelijke partij met kennis van zaken er naar te laten kijken? Denk aan een adviesbureau o.i.d. Die kunnen de verschillende offertes goed vergelijken.

[ Voor 28% gewijzigd door djluc op 17-03-2006 13:15 ]

[The Eagle]

Ola

Ik beheer zelf nu al zo'n 3,5 jaar een PeopleSoft ERP omgeving. Het kost wat, maar dan heb je ook wat. Ik vraag me persoonlijk af of je in de gaten hebt wat ERP feitetlijk inhoudt. Daarom bij deze even een ( (c) collega van me) analogie- voorbeeldje, zodat je het verschil zit tussen een standaardsysteem, een maatwerksysteem en een ERP-systeem:

Systemen zijn net boekenkasten:

Standaardsysteem:
Je loopt een meubelzaak binnen, zoekt een mooie standaard boekenkast uit en deze wordt thuisgebracht en neergezet.

Maatwerksysteem:
Je gaat naar een meubelmaker, geeft aan hoe de kast er uit moet zien, deze wordt gemaakt en krijg je thuisbezorgd. Latere veranderingen moeten door de leverancier gedaan worden, als dat al kan.

ERP-systeem:
Je bestelt het systeem, krijgt het frame thuisbezorgd, evenals een shitload aan planken, spijkers, schroeven en gereedschap. Het frame kun je helemaal zelf inrichten zoals je dat zelf wilt, en als je meer wilt, kun je simpelweg een paar planken en spijkers / schroeven pakken om het er bij danwel aan te bouwen. Ook zagen wil soms wel eens helpen

Dat inrichten gebeurt bij een ERP-systeem op basis van je administratieve organisatie. Oftewel: je standaardiseert het systeem op je bestaande bedrijfsproces. Dat is nl hetgene wat het moet ondersteunen

Nu begrijp ik dat je voor 25 man niet een pakket als PeopleSoft binnen wilt kruien, is wel webbased, maar heeft een prijskaartje met 6 nullen en dat zal iets teveel van het goede zijn . Echter: ook SAP is webbased verkrijgbaar. Ik zou zeker voor webbased gaan, het ontsluit en beveiligt een heel stuk makkelijker doordat je hier bestaande netwerktechnieken voor kunt gebruiken)

Ik weet dat er ook bedrijven zijn die SAP voor het MKB leveren. Met de apart te leveren webbased ontsluiting kun je een hoop.

Het enige nadeel van een ERP-systeem: doordat de kennis zo specifiek is, is deze duur. Uurtarieven van 150 a 180 eur ex btw zijn redelijk normaal. De heb je sowieso nodig voor de inrichting van je systeem - reken daarvoor op een half jaar doorlooptijd. Voor het beheer heb je verder toch wel een mannetje of 2 a 3 nodig, dus die zul je ws willen uitbesteden danwel inhuren.

Ik zou als ik jou was gewoon eens wat gaan zoeken op google op zaken als pakketselectie. Ik denk dat je dan al een hoop wijzer wordt

[xtra]

JKVA schreef op vrijdag 17 maart 2006 @ 12:35:
Toch is het goed mogelijk dat er met webapplicaties snel gewerkt kan worden. Op mijn werk hebben we een groothandelsysteem ontwikkeld met als sterkste punt dat het zo snel werkt. Door gebruik te maken van veel JavaScript en CSS open je een complex scherm in nog geen seconde, want die worden gecached zodat de pagina klein blijft. Hiervoor moeten echter ook zaken als database en andere lagen getweaked worden om de pagina's snel te genereren. Met behulp van JavaScript worden zaken als inline autoaanvullen, lookupfuncties en AJAX-based opslaan en zo geregeld.

(...)

Helemaal waar. Ik weet dat het kan maar zie het nog weinig. Als je zoiets óók nog zelf wilt programmeren moet je ICT-afdeling erg brede kennis hebben. Als die kennis (& tijd) er is kun je het zeker zo doen.

[JKVA]

Dat was ook één van de redenen die ik in mijn post gaf om absoluut niet zelf te gaan klussen. Zelf bouwen kost gegarandeerd meer dan het kopen van een pakket of een maatwerkoplossing bij een willekeurige J2EE of .NET boer om de hoek. Zelfs bij grotere partijen kun je nog voor een normale prijs terecht voor maatwerk mocht je dat willen. Het voordeel daar is dat alles doorgaans efficiënter gebeurt en het doorgaans hogere uurtarief compenseert.

Het kost wat, maar dan heb je ook wat. Zeker als je zorgt dat je de eisen een beetje in de perken houdt, jezelf niet helemaal ergens op vastlegt, maar openstaat voor (gemakkelijkere en dus goedkopere) oplossingen.

Ik zou zeggen, kijk eens een beetje rond.

Ps. Er zijn tegenwoordig belachelijk veel ERP aanbieders. Wat hebben jullie zoal aan aparte eisen waar zij niet aan kunnen voldoen?

[Verwijderd]

We hebben zelf 2 programmeurs in huis. Het voorstel ligt er om die te laten samenwerken met een externe partij die ook 1 of 2 mensen inzet. Momenteel maken we gebruik van wat knutselwerk in Access, wat in princiepe prima werkt, maar het helaas niet meer toelaat om er met meer dan 20 personen tegelijk in te werken.

Onze markt is zo ontzettend dynamisch, dat processen niet jaarlijks, maar maandelijks wijzigen. Zeer regelmatig moet er direct een functie worden ingebouwd om aan eisen van andere partijen te voldoen. Die functie moet er dan niet overmorgen zijn, niet morgen, maar vandaag. Daarom willen we de ontwikkelaars in eigen huis hebben om dit te realiseren.

Uiteraard zijn er veel functie-eisen die een standaard ERP-systeem ook bevat. Die externe partij helpt ons daarbij om die basis op te zetten. Vervolgens kunnen we zelf voor het onderhoud zorgen. Geloof me, er komt ontzettend veel maatwerk bij kijken. Desalniettemin, ik begrijp goed dat de meesten erg huiverig zijn met het zelf ontwikkelen van een ERP-systeem(pje).

Bedankt voor jullie tot zover!

[Grijze Vos]

Mja, pakketten zoals JD Edwards (=Peoplesoft btw) zijn niet gemaakt met 4 programmeurs.

Voor een organisatie van 20 man is zo'n pakket natuurlijk zwaar overkill. An sich zou je met 4 man best een leuk systeem in elkaar kunnen knutselen waarmee je de bedrijfsprocessen ondersteunt, daarvan valt de complexiteit in het niet tegenover "echte" ERP pakketen, natuurlijk.

[zx9r_mario]

Kijk eens naar Compiere. Dit is een ERP/CRM op basis van Java. Of SugarCRM.Op Sourceforge.net kun je van alles vinden met (Open source) code.

[JKVA]

Het feit dat in de toekomst flexibiliteit benodigd is, lijkt me juist een reden om het werk uit te besteden, want iets flexibels programmeren is niet makkelijk. Eventueel kunnen de in-house programmeurs ondersteuning bieden op functioneel niveau. Dat is sowieso beter dan een computerleek, bijvoorbeeld qua communicatie en het opstellen van goede consistente requirements.

Op mijn werk gaan we zelfs zo ver dat medewerkers van klanten les krijgen in bijvoorbeeld Java. (om even het belang van technische kennis bij de klant aan te geven)

Kortom, laat het ontwikkelen en ontwerpen over aan specialisten en zet jullie eigen programmeurs in het ontwikkelteam voor zaken als controle, feedback, functioneel testen, etc.