Terug naar blog

.
ERP-systeem of ERP-software of ERP-pakket?

Het zijn namen die veel door elkaar gebruikt worden, maar hetzelfde bedoelen.

Laat ons om te beginnen even gaan kijken naar de definitie van ERP.

ERP is een Engelse term voor Enterprise Resource Planning. En ERP verwijst meestal naar software. Naast heelwat andere doelstellingen is ERP bedrijfssofware die bedoeld is om uw efficiënte te verhogen, processen te stroomlijnen en kosten te verlagen.

ERP is geen nieuw begrip maar kent al een hele historiek (waarover u onderaan ook meer kan lezen).

En ERP bestaat in vele kleuren en geuren bij wijze van spreken.

Essentieel in ERP is dat meerdere afdelingen onder 1 centrale database werken

ERP is een niet zomaar een software, maar specifieke bedrijfssoftware om heel uw bedrijf mee te ontsluiten. ERP is een meestal ook een omvangrijk systeem waarop alle afdelingen van uw bedrijf zich kunnen aansluiten met specifieke modules per afdeling.

Hiermee willen wij nog niet zeggen dat u meteen vanaf dag 1 al uw afdelingen op dit ERP-systeem moet aansluiten, u kan ook gefaseerd, afdeling per afdeling, omschakelen als u wil.

Een essentieel kenmerk van ERP is evenwel wel dat er 1 centrale database is waarop al deze afdelingen zich connecteren, waar ze informatie uit halen en waar ze informatie aan teruggeven. Deze ERP database is dan ook het centrale hart van uw hele bedrijfsinformatie. Eén van de grote voordelen hiervan is dat u bijvoorbeeld nog slechts 1 klanten- en leveranciersbestand in heel uw bedrijf zult hebben en iedereen over dezelfde data beschikt.

Voordelen van ERP

  • ERP zet iedereen in uw bedrijf op 1 lijn
  • Medewerkers moeten minder data ingeven
  • De ERP software zorgt voor informatie bij de juiste man, vrouw en afdelingen
  • Kostenbesparingen
  • Efficiëntiewinst
  • Korter op bal spelen naar klanten, prospecten en leveranciers
  • Snellere leercurve
  • Ruime ondersteuning
  • Minder voorraad- en andere kosten
  • ERP is een instrument om uw bedrijf mee aan te sturen en controleren
  • ERP geeft u betere rapportering over afdelingen heen

Aandachtspunten en tips:

Enkele van de punten die men vaak vermeldt:
  • ERP zou duur zijn wordt vaak gezegd, hoewel tal van studies aantonen dat ERP zichzelf op maximum 3 jaar tijd terugverdient
  • ERP verandert uw organisatie en soms werkwijzes, wat niet iedereen even prettig vindt
  • ERP vereist discipline en structuur: ERP software werkt volgens de wijze waarop uw processen zijn ingericht in de software, wat op zijn beurt van gebruikers ook een zekere gestructureerde, logische discipline en medewerking vraagt
  • ERP vereist commitment van management en medewerkers
  • ERP implementeren vereist een goede aanpak: omdat een ERP-systeem meestal vrij omvangrijk is moet u de implementatie ook goed voorbereiden en aanpakken
  • Investeer zeker in voldoende opleiding voor uw personeel!
  • Laat u begeleiden door ervaren professionals
  • Ga bij voorkeur in zee met partners die bewezen hebben thuis te zien in uw branche, dit verhoogt uw kans op succes en daarvan kan uw bedrijf leren
  • Kijk niet te veel om naar uw oud softwaresysteem, maar laat u vooral inspireren door de nieuwe ERP zelf: u zal nieuwe mogelijkheden ontdekken

Hoe een ERP-systeem selecteren en implementeren?

Iedere leverancier heeft hiervoor zowat zijn eigen methodologie met al dan niet eigen accenten.
Onderstaande zijn daarbij enkele stappen die meestal terugkomen in elk ERP-project:

  • Interne voorbereiding
  • Voorselectie van pakketten en leveranciers
  • Initiële contacten en budgetteringen
  • Selectie van 1 of 2 potentiële levanciers
  • Analyse met 1 of 2 leveranciers
  • Eventueel een pilootproject
  • Verdere detailbudgettering en –planning
  • Implementatie, opleiding, testing
  • Opstart in 1 geheel of in subfases
  • Begeleiding en bijsturing
  • Eventuele volgende fases

Een visueel beeld van onze ERP-software, ons erp-systeem en ons ERP-pakket?


 



Onze klanten aan het woord: Aquacare

Succesvolle ERP implementatie dankzij kristalheldere samenwerking met Offimac

Marktleider in waterbehandeling

Aquacare, gelegen in Herk-de-Stad, werd in 1972 opgericht en is vandaag uitgegroeid tot marktleider in waterbehandeling. De oorspronkelijke - en nog steeds belangrijkste - activiteit van Aquacare is de verkoop, installatie en serviceverlening voor waterontharders - hoofdzakelijk voor de particuliere markt.

Sinds 2004 heeft Aquacare drinkwatersystemen aan het gamma toegevoegd. Deze systemen filteren het water van de kraan en garanderen permanent, gekoeld, plat, lichtbruisend en bruisend water. Met deze activiteit richt Aquacare zich voornamelijk op de de business to business sector; het bedrijf kan dan ook uitpakken met klanten in onder andere de ondernemingswereld, de gezondheidszorg en de overheid.

Meer recent bouwde Aquacare een derde poot uit die zich via een aparte commerciële cel toelegt op de horecasector, met een specifieke focus op de topbedrijven uit de hotel- en restaurantsector. Met 45 werknemers haalt Aquacare een totaalomzet van bijna zeven miljoen euro.


De weg naar een succesvol ERP-systeem

Aquacare was als KMO ongetwijfeld een voorloper wat betreft informatisering. Het bedrijf investeerde al in de vroege jaren ‘80 in bedrijfssoftware en maakte lange tijd gebruik van een boekhoudpakket dat het inzette in combinatie met een op maat geschreven softwaretoepassing.

Het gebrek aan integratie tussen het boekhoudpakket en de maatwerkoplossing bleek na enkele jaren echter een doorn in het oog van het management, terwijl de maatwerktoepassing op zich - ontwikkeld in Visual Basic - door een gebrek aan ondersteuning onvoldoende continuïteit bood naar de toekomst.

Op de beslissing om op zoek te gaan naar een nieuw en geïntegreerd ERP-softwaresysteem volgden al snel intensieve gesprekken met ERP-specialist Offimac uit Hasselt. Offimac was immers al jarenlang kind aan huis bij Aquacare voor de hardware-infrastructuur.

“Offimac kende ons bedrijf en onze businessconcepten zeer goed. Het was voor ons een essentiële voorwaarde dat een IT-partner zich meteen kon inleven in onze vertrouwde manier van werken”, aldus Jean Paul Van Kerkhoven, afgevaardigd bestuurder bij Aquacare.

In 2008 werd de knoop doorgehakt: Offimac bleek met Microsoft Dynamics NAV een krachtig en geïntegreerd ERP-systeem in huis te hebben en het management van Aquacare was na een demonstratie onder de indruk van de aangename gebruikerservaring die het pakket kon bieden.

Optimale service met OffiSERV

Om een optimaal serviceniveau te garanderen beschikt Aquacare over 15 Service Centers over heel België, terwijl een team van 18 technici instaat voor de installatie, het preventief onderhoud en de herstelling van drinkwatersystemen. Het bedrijf verricht jaarlijks al gauw 20.000 technische interventies.

Het beheer van verschillende types service- en huurcontracten bij Aquacare vergt een nauwgezette opvolging: het bedrijf moet immers rekening houden met preventieve onderhoudsbeurten met wisselende intervallen, contractuele vervaldata die moeten gerespecteerd worden en specifieke wensen van de klant.

Het callcenter van Aquacare speelt een cruciale rol als centraal contactpunt met klanten: daar worden immers onder andere de afspraken met klanten ingepland voor controle en preventief onderhoud. Ter ondersteuning van het ERP-systeem wordt een CRM-toepassing ingezet om alle nodige informatie met betrekking tot iedere klant op te vragen en te registreren - van de gedetailleerde beschrijving van het geïnstalleerde systeem tot de openingsuren en de historiek van de uitgevoerde interventies.

Om het ganse proces van technische interventies, beheer van servicecontracten en de daaruit volgende facturatie efficiënt te beheren, maakt Aquacare vandaag dankbaar gebruik van de OffiSERV module van Offimac; deze standaardtoepassing integreert bovendien naadloos met het generieke bedrijfssysteem Microsoft Dynamics NAV waarin onder andere de boekhouding, het aan- en verkoopbeheer gebeuren.

“Offimac heeft medewerkers in huis die de problematiek van servicebedrijven door en door kennen, en dat merk je aan veel details. Dankzij OffiSERV verloopt het beheer van onze servicecontracten voortaan veel vlotter. Het feit dat we meer dan 20.000 service-interventies per jaar met succes uitvoeren en beheren, zegt genoeg. We weten steeds waar elke medewerker zich bevindt en we kunnen veel vlotter nieuwe afspraken inplannen”, stelt Jean Paul Van Kerkhoven.

Vlotte overgang met vertrouwde Windowsomgeving

Jean Paul Van Kerkhoven: “Wat ons bijzonder aansprak, was de vertrouwde Windowsomgeving. Zelfs medewerkers die minder met IT vertrouwd waren, konden in een mum van tijd met de ERP-oplossing werken.”

Om de overgang vlot te laten verlopen hechtte Aquacare veel aandacht aan de opleiding van de gebruikers van het ERP-systeem, die zowel binnen het bedrijf als in de kantoren van Offimac plaatsvond.

Managementinformatie dankzij ERP-systeem cruciaal

Eén van de belangrijkste doelstellingen van een ERP-pakket is volgens Van Kerkhoven om het management een vlotte toegang te bieden tot informatie: “Dankzij de gebruiksvriendelijkheid vinden wij altijd snel de informatie terug die wij nodig hebben. En voor rapporteringen kunnen wij beroep doen op Jet Reports, dat ons toelaat om gegevens op gepersonaliseerde wijze voor te stellen en te analyseren”, aldus Jean Paul Van Kerkhoven.

ERP-pakket is betrouwbaar toekomstplatform

Volgens Aquacare legt het interne ERP-systeem een basis voor nieuwe initiatieven die in de toekomst de kwaliteit en de efficiëntie van de dienstverlening bij Aquacare verder moeten verbeteren. Jean Paul Van Kerkhoven: “We hebben nu een betrouwbare basis om in de komende jaren verder op te bouwen. Ik denk maar aan het ondersteunen van technici op verplaatsing met de module OffiWeb: zo kunnen ze hun activiteiten bij de klant onmiddellijk registreren met een Notebook of PDA. Wij werken al 20 jaar samen met Offimac als informaticapartner: een beter bewijs van continuïteit bestaat er niet.”.

Ontwikkelingen in ERP software:

Mocht u geïnteresseerd zijn om weer te weten over de historiek van ERP, dan vertellen wij u dit ook graag.

In deze paragraaf wordt ingegaan op de ontwikkelingen die in de ERP software hebben plaatsgevonden. Allereerst was er de ontwikkeling van vooral maatwerk naar een toenemend gebruik van standaardpakketten. Vervolgens kenden deze pakketten een verdere doorgroei naar ERP-pakketten.
.

1. Van maatwerksystemen naar standaardpakketten

Korte historie

Administratieve automatisering ontwikkelde zich van de automatisering van het administratieve “bulkwerk”, via het ondersteunen van de bestuurlijke informatievoorziening en het verschaffen van doeltreffend management informatie, tot het “ondernemen met informatietechnologie”. Deze ontwikkeling stelt eisen aan de wijze waarop systemen worden gestructureerd en aan de onderlinge samenhang tussen die systemen in de totale systeemarchitectuur.

Systeemintegratie is daarbij vandaag het sleutelwoord. De bedoeling van systeemintegratie is, dat informatie uit verschillende applicaties op eenvoudige en efficiënte wijze kan worden gecombineerd en tussen verschillende groepen gebruikers kan worden gecommuniceerd. De “eilandautomatisering” uit de tijd van de “automatisering van het administratieve bulkwerk” staat hierbij fors in de weg. Immers, dat zijn veelal oude en inadequate, losstaande applicaties, waartussen gegevensuitwisseling onderling amper mogelijk is. Vaak is dat er de oorzaak van dat het opleveren van adequate managementinformatie problematisch en soms onmogelijk is. Bovendien is het aanpassen van deze systemen aan de eisen van de moderne bedrijfsvoering vaak een (te) moeizame zaak door het “lappendekenstadium” (een door vele aanpassingen ondoorzichtig geworden systeem, waarvan bovendien de documentatie te wensen overlaat) waarin ze terecht zijn gekomen.

Verbeteringen worden gestart

Het voorgaande vormt voor tal van organisaties al een voldoende reden om tot vervanging of vernieuwing van systemen over te gaan: primaire processen in organisaties moeten beter worden ondersteund, managementinformatie moet worden verbeterd, systemen moeten flexibeler worden en zich eenvoudiger kunnen aanpassen aan zich wijzigende informatiebehoeften, en liefst moet het gebruik van informatietechnologie ook nog bijdragen aan het verkrijgen van voorsprong op concurrenten. Daarnaast moeten informatiesystemen zich aanpassen aan gewijzigde organisatorische werkwijzen, zoals bijvoorbeeld decentralisatie van verantwoordelijkheden en bevoegdheden, “afplatten” van organisaties, sturen op afstand, klant- en marktgerichtheid in plaats van productgerichtheid, en dergelijke. Dan is er ook nog de vanzelfsprekende trend dat ook automatiseringskosten omlaag moeten en beter moeten worden beheerst. Dat kan soms door middel van een andere automatiseringstechnische werkwijze. Een voorbeeld hiervan is “downsizing/rightsizing”, waarbij applicaties van grote centrale computers worden gedecentraliseerd naar kleiner computers, al of niet in een netwerkstructuur, hetgeen soms een kostendaling kan opleveren. Een voorlopig resultaat van deze ontwikkeling uit zich in de huidige client/server architectuur van systemen, waarbij de applicaties werkzaam zijn op een combinatie van centrale servers en de PC’s of de “desktop”. Of met deze architectuur beoogde kostenbesparingen zijn behaald is onzeker, daar deze architectuur nogal wat beheerskosten met zich meebrengt. Er is wel sprake van voordelen op het gebied van gebruiksvriendelijkheid, integratie met office systemen en integratie met workflow technieken die de logistieke problematiek in administratieve processen kunnen vereenvoudigen.

Een andere manier om automatiseringskosten lager en beter beheersbaar te krijgen kan worden gevonden in het gebruik van standaard applicatie pakketten. Over standaardpakketten en met name ERP gaan de volgende paragrafen.

Een toenemend gebruik van standaardpakketten

Organisaties raken er zich steeds meer van bewust dat een groot deel van de bedrijfsprocessen en de gegevensverwerkende processen voor veel organisaties min of meer standaard is, en dat de overige processen hetzij branchespecifiek hetzij specifiek voor de organisatie zijn. Het ligt dan ook niet voor de hand om de lijn uit het verleden voort te zetten en op grote schaal maatwerkapplicaties te blijven ontwikkelen. Steeds meer kijken organisaties derhalve voor vervanging of vernieuwing van systemen naar de mogelijkheid om van standaardsoftwarepakketten gebruik te maken, uitgaande van de gedachte, dat met behulp van standaardapplicatiesoftware beproefde oplossingen kunnen worden verkregen, die tegen lagere kosten in kortere tijd en met minder moeite kunnen worden ingevoerd. Deze voordelen kunnen veelal inderdaad worden bereikt. In de praktijk wordt echter de selectie en implementatie van een standaardpakket nogal eens onderschat.

De ontwikkeling in de richting van een toenemend gebruik van standaardpakketten heeft zich in de jaren ’90 versneld en wordt zeker ook gestimuleerd door de ontwikkelingen in de standaardpakketten zelf. Deze pakketten komen in toenemende mate tegemoet aan de eerder in deze paragraaf gestelde eisen, zoals op het gebied van systeemintegratie en flexibiliteit. Op deze ontwikkelingen wordt later in dit hoofdstuk verder ingegaan. Ook verwerking op gedistribueerde systemen is reeds mogelijk, waardoor aan mogelijke downsizing-wensen kan worden voldaan. Voorts worden de pakketten vaak geleverd met vele keuzemogelijkheden en moderne hulpmiddelen, waardoor “bijna-maatwerk” mogelijk wordt.

De term standaardpakket is dus enigszins misleidend. De suggestie wordt licht gewekt, dat het pakket, nadat de technische installatie op de computer heeft plaatsgevonden, direct geschikt zou zijn voor operationeel gebruik. Dit is echter niet het geval. Het merendeel van de pakketten vereist een gedetailleerde vastlegging in het systeem hoe men met het pakket en de door het pakket geboden functionaliteit wil omgaan. Zonder deze aansturing is het pakket in feite onbruikbaar voor een organisatie.

Voorbeelden van te maken aansturingskeuzen zijn:
  • Een activapakket kent een afschrijvingsfunctie. Hoe en wanneer de afschrijving precies moet geschieden, moet in het pakket worden vastgelegd.
  • Een financieel pakket kent een budgetmodule. Hoe de organisatie de budgetten wil beheren en hoe met overschrijdingen moet worden omgegaan, dient te worden vastgelegd in het pakket. 
Voordelen en nadelen van standaardsoftwarepakketten

In beginsel zal met maatwerk systemen altijd een betere “fit” kunnen worden gerealiseerd ten aanzien van de gebruikerseisen en wensen. Bij een standaardpakket zullen bepaalde onderdelen niet 100% aan de wens voldoen en zal de gebruiker zich op onderdelen aan het pakket moeten aanpassen. Echter ook bij maatwerk zal de gebruiker veelal concessies moeten doen ten einde de ontwikkelingskosten in de hand te houden. Standaardpakketten zijn tegenwoordig door hun verdere doorontwikkeling zeer rijk aan functionaliteit, waardoor de gebruiker nogal eens aangenaam verrast kan worden door de geboden ondersteuning.


Maatwerkontwikkeling kent overdrachtspunten tussen gebruikers en IT-specialisten, waardoor er altijd een risico van miscommunicatie en misinterpretatie is, met als gevolg dat opgeleverde programma’s soms niet datgene bieden, wat de gebruiker oorspronkelijk voor ogen had. Bij een standaardpakket wordt het pakket meestal ingericht in nauwe samenwerking tussen gebruikers en IT-specialisten (in het bijzonder pakketdeskundigen). Hierdoor is het risico op miscommunicatie en misinterpretatie veel kleiner, mits de pakketdeskundige zich voldoende kan inleven in de processen aan de gebruikerskant.

Maatwerksystemen leiden meestal tot een relatief hoge kostenpost voor onderhoud. Ook het doorvoeren van uitbreidingen zal steeds weer leiden tot maatwerkontwikkelingstrajecten. Het technische beheer van het standaardpakket wordt uitgevoerd door de leverancier, die verantwoordelijk is voor het oplossen van fouten en problemen. Het pakket zal in nieuwe releases ook vaak nieuwe mogelijkheden kennen, waar de klant via zijn onderhoudscontract veelal gratis gebruik van kan maken.

De functionaliteit van het pakket wordt beïnvloed door de klanten. Bijvoorbeeld door de gebruikersvereniging die veelal mee mag praten over de verdere pakketontwikkeling. En doordat de leverancier inzicht krijgt in hoe zijn verschillende klanten werken, leert hij bij. Het effect hiervan is dat het pakket steeds meer een “best practice”-gedachte ondersteunt en daarmee goede mogelijkheden biedt tot procesoptimalisatie of business process re-engineering.

Doordat een standaardpakket een zeer veelvoudig gebruik kent, zijn de ontwikkelingskosten per gebruiker veel lager, dan in geval van maatwerkontwikkeling door een enkele organisatie.

ERP-pakketten kennen van oorsprong een horizontale benadering; ze ondersteunen processen die bij zeer veel organisaties voorkomen zonder dat grote verschillen noodzakelijk zijn. Steeds meer richten ERP leveranciers zich inmiddels ook op branchespecifieke processen (zogenoemde “industry solutions”). De software verticaliseert dus. Maar ook, daar waar de ERP leveranciers geen geschikte industry solution bieden, kan een standaardpakket een oplossing zijn. Er zijn natuurlijk ook nog de leveranciers die zich juist op specifieke functionaliteit of op een specifieke branche richten (“best of breed” of ook wel “best of class” genoemd). Je komt dan echter al gauw in een situatie terecht, waarin je zelf allerlei interfaces/integratie moet ontwikkelen.
.

2. Ontwikkelingen in ERP-pakketten

Zesde generatie pakketten

Gaandeweg zijn standaardpakketten uitgebreider geworden qua toepassing en zijn de ontwikkelaars, die aanvankelijk veelal automatiseringsafdelingen waren, verzelfstandigd tot echte pakketleveranciers.

Wat de softwaretechniek betreft kan in de ontwikkeling door de jaren heen een aantal stadia worden onderkend. Deze zijn in de figuur “Evolutie van de standaardsoftware” weergegeven.
De eerste generatie echt parametriseerbare pakketten beperkte zich voornamelijk tot de financiële administratie, had een beperkte functionaliteit en was volledig batchgeoriënteerd. Interfaces met andere systemen waren slechts beperkt mogelijk.

De tweede generatie was vooral een krachtigere uitvoering van de eerste, waarbij met name de mogelijkheden voor rapportages en interfaces beter waren. Ook was nu op beperkte schaal online verwerking van gegevens mogelijk.

Met de derde generatie was het, mede door het steeds krachtiger worden van de computers, mogelijk geworden om vrijwel volledig online te werken. Functionaliteit werd steeds uitgebreider. Er waren inmiddels krachtige rapportgeneratoren beschikbaar, en aan het begrip managementinformatie kon enige inhoud worden gegeven.

De vierde generatie pakketten maakt gebruik van geheel nieuwe softwaretechniek. Ze zijn vrijwel zonder uitzondering geschreven in 4e generatie programmeertalen en maken gebruik van modernere database bestandsstructuren. De pakketleveranciers richten zich steeds meer op de applicaties zelf, en steeds minder op de techniek van de software, die dan ook vaak van derden wordt betrokken. De pakketten bieden ook steeds meer functionaliteit, en voor functies die het pakket niet ondersteunt worden vaak standaardinterfaces met producten van derden aangeboden. De meeste pakketten kunnen inmiddels ook via elektronische gegevensuitwisselingsprotocollen (EDI) met systemen van klanten en leveranciers communiceren.

De vijfde generatie kenmerkt zich door client/server architecturen, vergaande gebruiksvriendelijkheid (grafische user interface zoals Windows), verdere “openheid”, vooral qua hardware en databases ( de huidige pakketten draaien veelal op alle of meerdere generieke relationele database systemen). Voorts zijn functionele deelgebieden in de pakketten vergaand met elkaar geïntegreerd.

De huidige generatie richt zich vooral op flexibiliteit. De koper van een pakket krijgt steeds minder een kant-en-klaar product, maar krijgt een verzameling componenten waarmee hij in korte tijd, met behulp van krachtige modelleer-tools zelf zijn applicatie vorm geeft. Hiermee lijkt de kloof tussen maatwerk (perfect passend, maar duur en tijdrovend) en pakketten (goedkoop en snel, maar one-size-fits-all pasvorm) een heel eind gedicht. Een extra dimensie zal nog worden toegevoegd door ‘cross-applications’ features als Workflow Management, Internet- en Intranettoepassingen en integratie met standaard Office producten zoals Word, Excel en Mail en multimedia faciliteiten.
De hedendaagse bedrijfsvoering kan niet zonder het gebruik van computers. Hierbij is de stand-alone PC allang achterhaald door het gebruik van netwerken met daarin één of meer servers en zogenaamde clients. Onderzoeksbureau Gartner heeft dit “client-server” principe in een model gevat dat toepasselijkerwijs het “Gartner model” als naam heeft meegekregen.
Het model is op te splitsen in vijf varianten. Elk van de varianten bestaat uit een client en een server kant. Per variant zijn een aantal karakteristieken aan te duiden met elk hun voor- en nadelen in gebruik. Afhankelijk van de toepassing zijn de varianten wel of niet mogelijk. Naast de varianten wordt ook gesproken over het twee en drie lagen model. Het aantal lagen is afhankelijk van het gebruik van één of meer servers (voor één toepassing/ERPpakket). De term drie lagen is dan een synoniem voor het gebruik van meer dan één server (aparte servers voor applicatie en database). Verdere uitleg hierover staat bij de uitwerking van de vijf varianten. In de context van deze cursus zal per variant alleen worden ingegaan op de karakteristieken die relevant zijn voor een ERP pakket als toepassing.

Gedistribueerde presentatie

Bij de gedistribueerde presentatie is er sprake van één server en één client (twee lagen model). Er is sprake van een “thin client”. Dit wil zeggen dat, omdat er enkel een deel van de presentatie op de client draait, slechts een lichte machine benodigd is. Op de server draait zowel de database, de applicatie (het ERP pakket) als een deel van de presentatie. Een ander woord voor presentatie is user interface.
Het grote voordeel van deze variant is het gebruik van thin clients. Dit kunnen goedkope machines zijn en er hoeft weinig tot geen onderhoud op gepleegd te worden. De client hoeft een minimale harde schijf te hebben en ook het interne geheugen is niet zo belangrijk.

Daarentegen moet de server zeer zwaar zijn omdat het al het werk doet voor alle gebruikers. Het nadeel van het splitsen van de presentatie is dat het netwerk ook sneller moet zijn omdat er veel communicatie tussen de server en client moet plaats vinden over de presentatie.

Een gedistribueerde presentatie komt niet voor bij ERP pakketten. Het is de moderne versie van het vroegere mainframe.

Remote Presentatie

De Remote presentatie is de meest gangbare client-server variant bij het gebruik van de huidige ERP pakketten. Er is sprake van een twee lagen model waarbij de presentatiesoftware (GUI) op de client draait en het ERP en de database op een server. Ook hier kan nog sprake zijn van een thin client. Aangezien naast het ERP pakket vaak ook andere pakketten worden gebruikt en deze meestal op de client worden geïnstalleerd, worden deze clients in de praktijk al snel wat uitgebreider.

Er wordt wel gezegd dat met de komst van Internet en Intranet een nieuwe variant is ontstaan. Het principe van Internet is echter dat er een client is met presentatiesoftware (de Internet Browser) die via een netwerk/modemverbinding met een server gekoppeld is. Dit is dus feitelijk het principe van remote presentatie.

Gedistribueerde applicatie

Bij het gebruik van de gedistribueerde applicatie wordt een deel van de ERP software op de server gezet en een deel draait op de client. Dit wordt vooral gedaan indien het ERP pakket gebruik maakt van zogenaamde front-end toepassingen. Deze toepassingen draaien op de client en kunnen dus, indien er geen netwerkverbinding is, los van het ERP pakket werken. Dit wordt bijvoorbeeld voor verkoopdoeleinden gebruikt, waarbij de verkoper met zijn laptop naar de klant kan gaan en ter plekke een order kan invoeren. Later kan de laptop weer middels het netwerk aan de server worden gekoppeld en de gegevens met het ERP pakket worden gesynchroniseerd. Natuurlijk moet er naast de applicatie ook een beperkte opslagmogelijkheid zijn op de client, maar van een complete database is in dit voorbeeld geen sprake.

Remote Data Management

Bij remote data management draait de applicatiesoftware samen met de GUI op de client. De database staat op de server. Het gevolg is dat voor een goede performance de benodigde client aan hoge eisen moet voldoen. Men spreekt dan ook van een “fat client”.

Deze variant komt in een twee lagen model bij ERP pakketten niet vaak voor. De zwaarte van de fat client maakt het financieel gezien geen gewenste oplossing. Wel komt deze vorm in een drie lagen model voor. In dat geval draait de presentatie op de client en zijn er aparte servers voor de applicatie en de database. De client is gekoppeld aan de applicatieserver die op zijn beurt is gekoppeld aan de database server.

Het gebruik van twee servers heeft als voordeel dat zowel de applicatie als de database volledig gebruik kunnen maken van de capaciteit van de server zonder elkaar daarbij te belemmeren. Het nadeel is dat veel communicatie tussen de twee servers plaatsvindt, zodat een “zware” verbinding noodzakelijk wordt.

Gedistribueerde Database

Net als de eerste variant komt de laatste nooit voor bij ERP pakketten. Door het plaatsen van een deel van de database op de client wordt deze namelijk onbereikbaar voor andere clients. De kans op inconsistente data wordt hierdoor vergroot. Bovendien is het zeer moeilijk te bepalen welke delen van de database waar zouden mogen draaien.

De gedistribueerde database komt wel voor indien er sprake is van combinaties van meerdere databases die bij meerdere toepassingen horen. Zo kan er gedacht worden aan de combinatie van een ERP pakket en een engineering pakket. In het engineering pakket worden tekeningen en stuklijsten gemaakt. De stuklijstgegevens worden vanuit de engineering database naar de database van het ERP pakket overgezet. In principe is er echter geen sprake van een gedistribueerde database, maar een koppeling van databases via een interface.

Naast de hierboven genoemde client-server varianten is er ook nog de stand-alone variant waarbij zowel presentatie, applicatie als database op een client draaien. Dit valt echter uit het server-client verhaal, omdat er geen sprake is van netwerkverbindingen of twee of meer lagen.

De keuze voor een bepaalde client-server oplossing is niet eenduidig aan het ERP pakket op te hangen. Bepalend is ten eerste de mogelijkheden die er door de ERP leveranciers geboden worden. Vrijheid van splitsing van applicatie- en databaseserver is vaak nog wel mogelijk, maar waar de presentatie plaatsvindt is vast. De uiteindelijke keuze wordt daardoor vaak bepaald door andere software (kantoorautomatisering) die naast het ERP pakket gebruikt worden. De (on)mogelijkheden van deze software heeft vaak gevolgen voor de te kiezen client-server configuratie.

Een ander aspect dat een rol speelt is het platform waarvoor gekozen wordt. Indien gebruik wordt gemaakt van UNIX als operating system van de server, is men vaak gedwongen een zwaardere client te nemen, omdat de meeste kantoorautomatiseringspakketten niet op deze omgeving draaien.Hierdoor moet deze software op de client geïnstalleerd worden. Draait men het ERP pakket echter op een Windows NT-server, dan kan hierop ook de kantoorautomatisering geïnstalleerd worden en is er een lichtere client mogelijk.

3. Ontwikkelingen in logistiek en productieplanningssystemen

Van sigarendoos naar ERP

De gedachte dat productieprocessen actief beheerst moeten worden, komt op aan het begin van de 20e eeuw, wanneer de eerste grote massaproductie-industrieën ontstaan. De bewustwording dat kleine verbeteringen op het gebied van efficiency en effectiviteit op die schaal veel geld kunnen schelen doet een nieuwe wetenschap ontstaan, het scientific management, ook wel Taylorism genoemd naar haar grootste grondlegger, Frederick W. Taylor.

Een van de grote kostenposten in een periode waarin menskracht relatief goedkoop was, werd gevormd door de voorraden grondstoffen, halffabrikaten en eindproducten die nodig waren om aan de klantvraag te voldoen en om de productie gaande te houden.

Omdat het feitelijk berekenen van alle voor de productie benodigde materialen al te gauw arbeidsintensief was voor een bedrijf met vele verschillende en complexe eindproducten, werden verschillende methoden ontwikkeld om met een betrekkelijk geringe inspanning toch te kunnen zorgen voor voldoende voorraad. Voorbeelden hiervan zijn het voorraadaanvullingssysteem, waarbij de voorraad van een artikel weer op een vooraf bepaald niveau wordt gebracht zodra er verbruik is geconstateerd, en het bestelpuntsysteem, waarbij voorraadaanvulling geschiedt op basis van aannames over het verbruik en de levertijden van het artikel. Het zijn echter alle benaderingen in de zin dat er geen van alle rekening houden met de werkelijke vraag naar artikelen.
De geschiedenis van ERP begint eigenlijk met de opkomst van de computer na de Tweede Wereldoorlog. Nadat computers aanvankelijk vooral voor wetenschappelijke en militaire doeleinden worden gebruikt, komen ze aan het begin van de jaren 1960 voor het eerst op grotere schaal beschikbaar voor commerciële bedrijven, waar ze onder andere worden opgepakt door mensen die zich bezighouden met het voorraadbeheer, en worden ingezet om materiaalbehoefteberekeningen of “Material Requirements Planning” uit te voeren.

MRP

MRP, zoals Material Requirements Planning wordt genoemd, rekent uit welke halffabrikaten en inkoopartikelen op welk moment nodig zijn in het productieproces om een gegeven productieplan uit te kunnen voeren.

Om dit te kunnen doen zijn gegevens nodig over het productieplan, ook wel Master Production Schedule (MPS) genoemd, de samenstelling van de producten (de Bill Of Material, ofwel BOM), en beschikbare voorraden en de productie- en besteldoorlooptijden. Op basis van de vastgestelde toekomstverwachtingen wordt dan berekend wat de materiaalbehoefte is en worden vanaf de voorzijde van het logistieke proces de materialen het productieproces ingeduwd: vanwege dit kenmerk noemen we MRP een push-systeem.

Hoewel de theorie zeker niet nieuw is, voegt de computer een belangrijk iets toe: iedere keer als het productieplan wijzigt, bijvoorbeeld doordat er een nieuw order wordt geplaatst, kunnen de consequenties voor de materiaalaanvoer opnieuw worden doorberekend. Met de komst van MRP kan eindelijk een eind gemaakt worden aan de starre en onwenselijke verhouding tussen een hoge leverbetrouwbaarheid en hoge voorraden.

MRP II

In de literatuur over MRP wordt al vastgesteld dat de output van het MRP-systeem, waar het gaat om de productieorders, ook gebruikt kan worden als input voor een capaciteitsplanningsysteem. Immers, als bekend is wanneer een artikel wordt geproduceerd, welke capaciteitsbeslag daarmee gepaard gaat, en wat de beschikbare capaciteit in die periode is, dan kan er een capaciteitsplan gemaakt worden. Het lag dan ook voor de hand dat, zodra MRP goed werkte en de computers krachtig genoeg waren, de systemen hiermee werden uitgebreid. Deze volgende generatie wordt MRP II genoemd. Hiermee had tevens de afkorting MRP een andere betekenis gekregen: het stond nu voor Manufacturing Resources Planning, om aan te geven dat het niet alleen meer om materialen gaat. In de meeste MRP II-systemen kom je capaciteitsplanning op twee niveaus tegen. Op het hoogste niveau wordt een grove capaciteitsplanning uitgevoerd met behulp van het productieplan (MPS). Deze Rough Cut Capacity Planning geschiedt door van alle artikelen in het productieplan een capaciteitsprofiel te maken dat laat zien wat het beslag op de belangrijkste productiefactoren is. Deze techniek wordt vooral toegepast om de capaciteitsbehoefte op middellange termijn te bepalen. Daarnaast wordt de techniek van Capacity Requirements Planning toegepast, waarbij voor iedere productieorder in het systeem op het niveau van productiestappen een capaciteitstoets plaatsvindt tegen de werkelijke beschikbare capaciteit van de betreffende werkstations. Deze laatste techniek is vooral voor de dagelijkse planning en voortgangsbewaking relevant. Beide zijn zogenaamd Infinite Capacity Planning-technieken, dat wil zeggen: ze laten het effect van een productieplan zien op de beschikbare capaciteit. Als er sprake is van over- of onderbezetting, is het aan de planner om daar door herplannen van orders, of wijzigen van de capaciteit, wat aan te doen.

Met de opkomst van MRP II wordt de interesse voor dit soort systemen bij de industrie steeds groter. De ontwikkeling van MRP was begonnen bij producenten die discrete producten in serie vervaardigen. Gaandeweg werden zij gevolgd door bedrijven met andere productieprocestypologieën. Hieronder staat een aantal procestypen vermeld die in de loop der jaren, we praten dan over de jaren ’70 en ’80, steeds beter ondersteund werden door MRP II-systemen.

Engineer-to-order. Voor dit type productie, dat meer op enkelstuks en kleine serie is gericht, dienden ontwikkelingswerk, bouw van prototypen, en testwerkzaamheden te worden ondersteund. Daartoe werden aan MRP II-systemen zaken toegevoegd als netwerkplanning en One-Time-Only (OTO) planningsparameters.

Semi-process. Hierbij gaat het om delen van het productieproces die niet discreet zijn. In plaats van stuklijsten worden hier recepten gebruikt, en worden batches aangemaakt in plaats van series. Grote gebruikers van dit type proces kunnen worden gevonden in de voedings- en genotmiddelen en farmaceutische industrie. Dit heeft ertoe geleid dat naast het kunnen werken met recepten, MRP-systemen ook werden uitgerust met lot- en serienummercontrolemogelijkheden, die in deze takken van de industrie van groot belang zijn.

Repetitive productie. In dit type omgeving worden geen discrete orders verwerkt, maar worden producten in grote, vrijwel continue series gemaakt. Denk daarbij aan producenten van auto-onderdelen of bijvoorbeeld broodfabrieken. Om dat type productie te kunnen ondersteunen zijn MRP-systemen uitgerust met ‘eindeloze’ orders waartegen de dagelijkse productie kan worden afgemeld. Middels backflushing wordt op basis van het aantal gerede producten het (theoretisch) verbruik van grondstoffen vastgesteld. Periodiek wordt dan de werkelijke voorraad vergeleken met de voorraad in het systeem.

Assemble-to-order. Hier worden standaardcomponenten naar wens van de klant geconfigureerd tot een bijna uniek eindproduct (Customized Mass Convenience). Voorbeelden hiervan zijn auto’s en personal computers. Deze typologie wordt in de loop van de jaren ’80 en ’90 steeds populairder, en heeft ertoe geleid dat MRP-systemen zijn uitgerust met wat meestal Configure-to-order-modules worden genoemd. Op basis van vooraf vastgestelde formules, die alle mogelijke en onmogelijke combinaties bevatten, kan het eindproduct volledig naar wens van de klant worden samengesteld, en tevens naar de juiste productie-orders worden vertaald.

ERP

MRP en MRP II waren van oudsher sterk in het ondersteunen van productiegerelateerde bedrijfsprocessen. Voor ondersteuning van alle andere processen moesten aanvankelijk nog andere systemen worden gebouwd of gekocht. De MRP II-systemen werden in de loop van de jaren ’80 echter zo populair, dat de inkomsten daarvan de producenten in staat stelden om hun pakketten uit te breiden naar gebieden die niet direct meer met productie te maken hadden, zoals financiën, marketing en personeelszaken. Vanaf die tijd wordt er in het algemeen gesproken van Enterprise Resource Planning (ERP). Deze softwarepakketten zijn uitgebreid met modules voor een complete financiële administratie, die volledig geïntegreerd is met alle andere delen van het systeem, agenderingssysteem voor marketing- en verkoopondersteuning en sytemen voor personeelsbeheer, waarin zaken zijn opgenomen zoals werving en selectie, tijdregistratie en persoonlijke ontwikkeling.

ERP +

De meest recente ontwikkelingen liggen steeds meer op het creëren van controle over processen buiten de eigen bedrijfsvestiging. In met name de auto-industrie wordt integratie van de planning van klanten en toeleveranciers steeds belangrijker (ketenintegratie), en ook willen bedrijven met verschillende vestigingen hun, vaak wereldwijd verspreide, capaciteit steeds meer centraal managen. Dit heeft ertoe geleid dat ERP-leveranciers hun pakketten hebben uitgebreid met functionaliteit op het gebied van Multi Site Management voor de integratie van de planning van eigen vestigingen en Electronic Data Interchange (EDI) voor integratie met bedrijven buiten het eigen concern.

De laatste jaren is ook duidelijk geworden dat het steeds moeilijker wordt om alle wensen in één pakket onder te brengen. Vooral op specifieke deelgebieden zijn specialistische pakketten op de markt gekomen, waarop de “algemene” ERP-pakketleveranciers geen afdoende antwoord hebben. Het antwoord van de ERP-leveranciers hierop is het ontwikkelen van standaard-interfaces, waarmee zogenaamde Third Party Solutions kunnen worden gekoppeld aan het ERP-pakket. Het zou kunnen zijn dat de ERP-leveranciers zich steeds minder als softwarebouwer en steeds meer als software-integrator zullen gaan manifesteren.

4. ERP-pakketten versus “best of breed”

De ontwikkelingen in ERP laten onverlet, dat er ook nichespelers in de markt zijn gebleven: leveranciers die alleen bijvoorbeeld een accounting pakket leveren en in deze soort de beste proberen te zijn (“best of breed”); respectievelijk leveranciers die zich slechts op specifieke branches richten.

ERP

De relevante kenmerken in ERP zijn:

  • Gericht op transactieverwerking
  • Procesgericht
  • Over afdelingen heen

‘Best of Breed’

Nog steeds zijn er leveranciers die zich richten op een beperkt gebied dat ook in de meeste ERP pakketten is terug te vinden, bijvoorbeeld op het gebied van accounting, human resource management. Dit zijn de zogenoemde ‘best of breed’ pakketten. Daarnaast zijn er branchespecifieke pakketten, bijvoorbeeld voor de zakelijke dienstverlening, ziekenhuizen, transportsector, etc. Dit zijn de zogenoemde verticale pakketten. ERP leveranciers zijn ten dele bezig steeds meer verticale software aan het ERP product toe te voegen. Dit noemt men industry solutions.

In het algemeen zou men mogen verwachten, dat ‘best of breed’ leveranciers en leveranciers van verticale software op hun deelgebied betere functionaliteit bieden dan de “allesdoende” ERP leveranciers. Dit hoeft echter niet altijd het geval te zijn.

Er zijn een aantal ERP-leveranciers die ‘best of breed’ en verticale producten opkopen met de bedoeling deze in hun ERP product te integreren; een overigens niet zo eenvoudige zaak.

Andere leveranciers kopen bedrijven op vanwege de daarin aanwezige kennis en vertalen die vervolgens naar hun product. Weer andere leveranciers werken volgens een ‘alliance’ of ‘partnership’ model en zullen dus gezamenlijk met de partners de koppelingen moeten realiseren. Kortom: de ERP leveranciers halen op deelgebieden eventuele functionele achterstand op ‘best of breed’ en verticale leveranciers in.

Voor- en nadelen ERP/geïntegreerd versus ‘best of breed’

ERP kent een in het algemeen vergaande mate van integratie, in de zin van eenmalige vastlegging van gegevens en meervoudig gebruik ervan op vele plaatsen in de organisatie. Bij ‘best of breed’ zal men deze integratie zelf tot stand moeten (laten) brengen en onderhouden. Dat onderhoud kan al gauw gaan spelen, op het moment dat één van de ‘best of breed’ leveranciers een nieuwe release van zijn product uitbrengt.

Bij de aanschaf van de software hoeft men in geval van ERP met slechts één partij te onderhandelen; bovendien zijn door de grotere omvang van de deal veelal investeringsvoordelen te behalen. In geval van problemen in de software, is er duidelijk één leverancier aan te spreken.

Een geïntegreerd pakket heeft als het goed is over modules heen een consistente gebruikers interface. Bij een stelsel van ‘best of breed’ pakketten kunnen er verschillen in die interface bestaan, hetgeen hinderlijk is wanneer je als gebruiker van verschillende componenten gebruik moet maken.

Een geïntegreerd pakket heeft als het goed is één ontwikkelomgeving; een stelsel van ‘best of breed’ pakketten zal doorgaans meerdere ontwikkelomgevingen kennen. Dat betekent dat van meerdere omgevingen kennis moet worden opgebouwd en onderhouden, hetgeen een kostenverhogend effect kan hebben op de beheerorganisatie.

Is daarmee het pleit beslecht in het voordeel van ERP? Niet in alle gevallen. Het is aan u om de afweging te maken tussen de voordelen van een geïntegreerde ERP-oplossing tegenover de voordelen van wellicht een betere functionele fit van de ‘best of breed’ en verticale leveranciers. En ook is het denkbaar dat u een dermate specifieke organisatie hebt (organisatiestructuur, processen, besturing),

Terug naar blog

Iets voor u? Gratis advies? Online Demo? Geef een seintje!

Vul onderstaande in en we nemen zo snel mogelijk contact met u op! Wilt u gratis advies of gratis white papers i.v.m. ERP ontvangen, laat het ons dan ook weten via onderstaande en wij sturen ze u gratis toe!
Naam
*
E-mail
*
Telefoon
U wenst info over:
*
Vraag:

Klanten vertellen

"Of het nu gaat om projectbeheer, productie, documentbeheer of managementrapportering, Offimac is een IT-bedrijf dat onze noden perfect begrijpt en invult."

Quote
Nadia Jansen
CEO
Building Group Jansen

"Voor de prijs van een middenklasse wagen heb ik dankzij Offimac een heel efficiënt bedrijf gekregen. Dit is een investering die me elke dag geld opbrengt."

Quote
Niels Bollen
Directeur
Nibotechnics

"Projecten en techniek zijn de kern van onze business, maar finaal draait het om de centen. Dankzij Offimac weten we op elk moment waar we staan, op elk niveau."

Quote
Erwin Bobbaerts
Bestuurder
Louis Stevens & Co

"Microsoft Dynamics NAV ERP van Offimac is het overkoepelend softwareplatform dat ons toelaat al 10 jaar onafgebroken 30% per jaar te blijven groeien."

Quote
Wido Bourel
General Manager
Rajapack Benelux

"De mensen van Offimac zijn net zoals wij ondernemers. Met hun software sturen wij heel ons bedrijf aan, van order intake naar productie- en capaciteitsplanning, logistiek, transportplanning, facturatie, etc."

Quote
Robert Zegveld
Commercieel directeur
E-MAX Aluminium

"CAD/CAM-gegevens worden automatisch geïmporteerd in ons ERP-systeem, en van daaruit verder gebruikt voor alle productie- en logistieke processen. Dat is efficiënt productiemanagement, zonder dubbel werk of extra administratie."

Quote
Jef Claes
Financieel directeur
ATM

"Omdat we zelf geen IT-afdeling in huis hebben, is het voor ons belangrijk met een IT-partner te kunnen samenwerken met korte communicatielijnen en snelle reactietijden. Offimac is zulk een partner."

Quote
Serge Tremblez
General Manager
Eurorent

"Offimac overtuigde ons met haar sterke software voor de Bouw. Na een succesvolle implementatie hebben wij ook heel onze hardware aan hen toevertrouwd. Alle ICT bij 1 partner: dat is gewoon makkelijk, goedkoop én efficiënt."

Quote
Christophe Suerickx
CEO
Group Suerickx

"Offimac zijn bescheiden Limburgers. Maar hun aanpak, implementatie en support zijn gewoon top."

Quote
Op aanvraag
IT-manager
NAV klant die overstapte naar Offimac

"Dankzij de Microsoft Dynamics NAV-oplossing van Offimac zijn we verder kunnen groeien zonder extra personeel aan te werven. Er staat een pak minder cash vast, binnen het kwartier kan ik een volledige winkel auditen én optimaliseren, doorbestellen gaat supersnel en ik kan zeer snel trends detecteren. Bijzonder efficiënt."

Quote
Luc Schreurs
Algemeen Directeur
Group Schreurs

"Dankzij Microsoft Dynamics NAV van Offimac sparen we massa's tijd uit. Klanten worden sneller en correcter bediend en kunnen tot op het laatste moment wijzigingen doorgeven, waardoor zij heel tevreden zijn over onze service."

Quote
Giovanni Oliveri
General Manager
Louis Widmer Benelux

"Met Offimac-software plannen en leveren wij jaarlijks meer dan 20.000 service- en installatiebeurten doorheen gans België. Met succes."

Quote
Jean Paul Van Kerkhoven
CEO
Aquacare International

"Dankzij Microsoft Dynamics NAV en Offimac konden we 5 man uitsparen in orderverwerking. Dat is een jaarlijkse besparing van 10% in personeelskosten!"

Quote
Luc Schreurs
Algemeen Directeur
Group Schreurs