Archive | ERP software voor KMO RSS for this section

Gelieve te klagen, aub.

Luisteren naar klanten is een keuze die je als organisatie moet maken. Er zijn genoeg redenen om te doen alsof dat je niks hoort, er zijn er nog meer om je zo te organiseren dat een klacht een zegen wordt.

Je kan besluiten om niet te luisteren en dus ook niet te reageren op klachten omdat je vindt dat dit te duur is. Je kan overtuigd zijn dat klagende klanten pas beginnen te klagen als ze weten dat er naar hen geluisterd wordt. Waarmee je indirect zegt: hoe minder je luistert hoe minder men klaagt ? Of je kan denken dat er maar een minderheid klaagt en dat de inkomsten komen van zij die niet klagen.


Maar als je de keuze maakt om je als organisatie zo in te richten om te luisteren naar de klachten van je klanten, als je je klanten stimuleert om feedback te geven over wat je doet, hoe je het doet en wat je levert, dan kan je als bedrijf groeien, sterker worden en een klacht in een opportuniteit omzetten. Zorg dat een ontevreden klant extra in de watten wordt gelegd, dat er een snelle oplossing komt voor zijn probleem en het wordt een levenslang trouwe klant.

Vergeet niet: van een klant een enthousiaste ambassadeur maken is veel goedkoper dan een negatieve “word-of-mouth”!

Mijn tip: gebruik de juiste tools om klachten te registreren, ze te verdelen, verantwoordelijkheden toe te kennen, op te volgen én er corrigerende maatregelen uit te distilleren. Een beetje erp-pakket heeft vandaag een module om klachten te beheren en daar voordeel uit te halen. En ten slotte: kies en sta achter je keuze. Als je zegt te zullen luisteren, doe dat dan en sta open voor de verzuchtingen van je klanten.

Naar een intelligente organisatie.

Ik had het al eerder over het belang van het goed en deugdelijk verwerken en inputten van informatie in bedrijfsbrede softwaretoepassingen. Ik ben onlangs tijdens een seminarie op een slide gebotst die mijn aandacht heeft getrokken en die een mooi beeld geeft van hoe een organisatie van data naar actie moet kunnen komen. Of: hoe een organisatie informatie kan gebruiken om gefundeerde beslissingen te nemen.

De grafiek zoals we hem hier zien heet de “The Tillman Six Phases of the Intelligence Process Implementation” . Dat lijkt me een veel te dure naam, maar goed.

Alhoewel ik hier een extra onderste laag mis (de laag van de dataverwerking en data-input) geeft het een zeer goed beeld van de verschillende soorten informatie en de verschillende stappen die een organisatie moet nemen om tot actie over te gaan.

Even kort toelichten nog:

1. In eerste instantie heb je ruwe data, meestal ongestructureerd, ongefilterd en in grote hoeveelheden
2. Door structuur in de data te brengen krijg je informatie
3. De informatie wordt geanalyseerd, gedeeld, samengevat en resulteert in kennis over bepaalde deelaspecten van de markt, klanten, producten
4. Door de kennis te toetsen met bestaande andere, historische data en door ze te interpreteren komen we tot intelligentie
5. Deze intelligentie zal een impact hebben op strategische beslissingen en zal de organisatie toelaten gefundeerde beslissingen te nemen en deze in een “plan” te gieten
6. Het plan wordt geïmplementeerd en uitgevoerd

Mijn tip: huur een specialist in of school je bij. Als je ziet welke competenties (de stappen aan de rechterkant van de piramide) je in huis moet hebben om tot een gefundeerde actie te komen, dan blijkt dat je gezien de belangrijkheid, niet veel ruimte hebt om wat te fantaseren.

Je kan natuurlijk ook het boek lezen: “Enterprise intelligence: het creëren van de intelligente en alerte organisatie” door Josèph H.A.M. Rodenberg RM.

Niet kunnen maar willen.

Laatst las ik tijdens mijn veel te korte vakantie een boek waarin werd geschreven over de kunst van het vragen stellen. Ik vond de benadering wel interessant om te delen.

In het boek werd geschreven dat je beter een vraag stelt in de zin van “wil je dit voor me doen”, eerder dan “kan je dit voor me doen”. De tweede manier zou te vrijblijvend zijn, temeer omdat je dan het antwoord kan krijgen dat men het wel kan maar daarom nog niet wil.

Ik vind de benadering wel iets hebben, ook voor de manier waarop je een softwarebedrijf een vraag stelt. Bij The Missing Link is het antwoord steevast: “alles kan”. En dat is ook zo… in principe kan alles via programmatie en code worden gerealiseerd.

De vraag die het softwarehuis zich echter moet stellen is: willen we dit wel? Draagt dit bij aan de algemene functionaliteit van een pakket, past het in de filosofie, is het bruikbaar voor meerdere klanten, is het bedrijfseconomisch verantwoord ?

Mijn tip: de volgende keer dat u een vraag stelt aan een softwarehuis, vraag dan: “willen jullie dit samen met ons ontwikkelen ?” Dit soort vragen stemt tot veel meer tot nadenken.

Soms beter neen zeggen.

Als softwarebedrijf gebeurt het dat je, om een verkoop binnen te halen, nieuwe functies schrijft voor een specifieke klant of project. Dat maakt deel uit van het zaken doen. Maar als je hier een slechte gewoonte van maakt, dan geraak je hier mee in een negatieve spiraal en kan je dit wel eens zuur opbreken. Waarom ?

De verkoop van licenties, de onderhoudscontracten en eventuele kosten voor nieuwe versies vormen voor een softwarebedrijf de grootste bron van inkomsten. Vasthouden aan dit model betekent dus dat je als ontwikkelaar zorgt voor een continue verbetering van het product met functies die voor een breed publiek bestemd zijn. Hoe beter en performanter jouw product wordt, hoe geschikter het wordt voor een groot deel van de klanten en prospecten, waardoor je dus meer zal verkopen en marge gaat genereren.
Als je dus voor een nieuw project specifiek maatwerk gaat inplannen, knabbel je eigenlijk aan de marge die je kan maken door een product met een brede inzetbaarheid verder te ontwikkelen. En dat voor een eenmalige opbrengst, een eenmalige verkoop met een beperkte marge. Het verzwakt bovendien jouw penetratie in de brede markt.


Stel dat je zaken op maat blijft ontwikkelen, dat je steeds langere trajecten af te leggen hebt in de ontwikkeling van functies die slechts door een handvol gebruikers kan worden ingezet. Je hakt hiermee de hand die je marge biedt, radicaal af. Erger, op lange termijn kan je het brede product niet verder ontwikkelen wegens een tekort aan mankracht en resources en lopen de klanten (die voor de marge zorgen) in grote getale weg van het product. Het product veroudert, wordt niet meer bijgewerkt, waardoor mogelijke nieuwe klanten wegblijven, of erger, maatwerk vragen, waardoor je in de negatieve spiraal blijft weggezogen worden.

Slanke bedrijven, handige software

Je kan geen magazine openslaan of seminarie bijwonen of je wordt bestookt met buzz-woorden als “lean” en “agile”. Het leek me geen slecht idee om een aantal van de principes en kenmerken van naderbij te bekijken en ze, waar mogelijk, in het perspectief van de selectie van bedrijfbrede software te plaatsen.

Lean betekent eigenlijk dat je afslankt. Dat je alles wat overbodig is, schrapt of vermijdt. Minder administratie, minder papier, minder afval, minder tijd, minder voorraad. Er werden door James P. Womack en Daniel T. Jones 5 stappen gedefinieerd om te komen tot een slankere organisatie. Ik heb ze vertaald naar bedrijfsbrede software en naar de zaken waarmee je best rekening houdt bij de selectie ervan.

1. Analyseer welke processen waarde hebben voor de eindconsument of voor de klant. Alles waar de klant voor zou willen betalen, is waarde. Alles wat daarbuiten valt moet kritisch worden bekeken. Als je processen wil vertalen naar de software, concentreer je dan vooral op die processen die waarde hebben.

2. Onderzoek hoe je die waarde creëert. Welke stappen zet je? Welke stappen voegen waarde toe, welke niet? Haal de onnodige stappen in een proces weg en kijk of het proces nog beheersbaar is in de software. Vraag je af of het proces overeind blijft bij het schrappen van bepaalde stappen.

3. Reorganiseer de stappen volgens het het flow-principe. Reorganiseer de flow zodanig dat je alleen nog waarde overhoudt. Resultaat: je wint efficiëntie en tijd.

4. Is er geen behoefte, onthoud je van ze te zelf creëren (respecteer het pull-principe). Stel bepaalde processen of methodieken slechts in vraag wanneer de vraag effectief komt. Dit is een heikel punt. Bij de selectie van software en bij het vertalen van processen naar bestaande software-oplossingen heeft men vaak de neiging een vraag te creëren, bijkomende processen te beschrijven omdat de software nieuwe mogelijkheden biedt. Cross that bridge only when you get there.

5. Denk er aan dat je alles zal moeten blijven in vraag stellen. Waar kun je nog meer waarde toevoegen? Hoe kun je je nog efficiënter organiseren? Dit vereist een software-oplossing die extreem flexibel zal moeten zijn in de mate waarin het kan worden aangepast in functie van nieuwe ontwikkelingen en wettelijke vereisten. Zal de software de nieuwe inzichten aankunnen bij een nieuwe afslankronde waarin je opnieuw alles in vraag hebt gesteld ? Kan de software mee evolueren met een slankere én complexere administratie (slank is niet hetzelfde als klein of eenvoudig)

Bij het laatste puntje zien we dat het aspect “Agile” (Engels voor behendig, flexibel) belangrijk is indien we spreken over software. Ik beloof u daaraan nog later een post te wijden. Flexibele en gemakkelijk (en dus tegen verantwoorde kost) aanpasbare software is belangrijk voor een organisatie die zichzelf en haar processen blijft in vraag stellen om te kunnen afslanken.

Tenslotte wil ik je nog een stukje commentaar meegeven van Jeroen Philippi (Unit4-Agresso) op een post over de Company Mass Index:

Het zijn uiteindelijk de gebruikers die in het keuzeproces te weinig aandacht hebben voor het aspect van verwachte en onverwachte veranderingen in de toekomst en leveranciers hierover niet op voorhand om duidelijkheid vragen. Door een oplossing te kiezen die de flexibiliteit heeft om eenvoudig en tegen lage kosten te worden aangepast na de implementatie, kunnen bedrijven voorkomen dat (ongeplande) IT-investeringen een groot deel van het bedrijfsbudget opslokken.

Alleen bedrijven die investeren in een systeem dat flexibiliteit biedt na de implementatie, kunnen zich gemakkelijk aanpassen aan veranderende marktomstandigheden. Daarmee kunnen ze concurrenten voorblijven die zich in hun groei laten tegenhouden door rigide systemen, of een groot deel van hun budget kwijt zijn aan onverwachte uitgaven.

ERP in the cloud, work in progress

Er gaat geen vergadering, event, seminarie voorbij of we zijn weer met ons allen “in” the cloud. De buzz is er en lijkt nu toch wel hardnekkig te blijven. De meningen verdeeld, de misverstanden groot, de kennis beperkt. The cloud heeft echt wel wat te bieden maar een vaart loopt het niet. Als aanbieder van ERP-software is het van belang de klant de keuze te bieden en hem niet in het ene of het andere model te duwen.

Ik vond onderstaande infografiek sprekend en het lijkt me interessant om die eens verder te bestuderen.

Voorraadbeheer: time & the bullwhip

Als je aan voorraadbeheer denkt, denk dan in dagen of weken voorraad. Denk niet altijd in “aantallen in voorraad”. Tijd speelt in voorraadbeheer een cruciale rol. De vraag die men zich in feite bij een goed voorraadbeheer stelt, is: hoelang kan ik voldoen in de behoefte van mijn klant. Dat is meteen één van de bestaansredenen van voorraad: het opvangen van onzekerheden.

Voorraadbeheer kan je visueel voorstellen als een bergrivier die met een groot debiet water aanvoert dat in een meer terechtkomt. De bergrivier is de aanvoer van uw leverancier(s), het meer is uw voorraad, de buffer die wordt aangelegd. Verderop en lagergelegen wordt het water aan een lager debiet en gecontroleerd terug vrijgegeven en stroomt het rustig verder. Het beheer van voorraad is dus bepalen hoeveel water je in het meer wil of kunt houden om de onzekerheid van de aanvoer uit de bergrivier op te vangen. Belangrijk is hier te bepalen wat de ideale hoogte of volume van het reservoir is en wat de aan dit meer verbonden kosten zijn.

Bij de berekening van de optimale voorraad, de bestelgrens en de maximum voorraad wordt rekening gehouden met aantallen maar zal bij de berekening de parameter tijd een bepalende factor zijn. Tijd is cruciaal wanneer we denken aan bijvoorbeeld het inbouwen van een veiligheidsvoorraad of het bepalen van de periodiciteit van de berekeningen. Tijd geeft ons een betere berekening. Een voorbeeld: wanneer je louter op basis van aantallen zou werken dan hou je bijvoorbeeld geen rekening met lead-time: dat is de tijd tussen het effectief beslissen om te bestellen én de verwerking van die bestelling bij de leverancier. In sommige gevallen kan het hier gaan om een paar dagen. Als je verwacht dat er een wekelijkse aanlevering is van goederen dan kan “een paar” dagen gelijk zijn aan de leveringstermijn. Hierdoor kan het dus zijn dat de termijn verdubbelt en je dus geen voorraad voldoende hebt. Het meer komt droog te staan.

Houd in dergelijke situatie eveneens rekening met het bull-whip effect. Het is het effect van een zweep: wanneer het beslissingsproces en/of de keten te lang wordt bij voorraadbeheer, krijg je een pervers effect dat resulteert in uiteindelijk te grote voorraden of ongecontroleerde productie. De grafiek geeft duidelijk aan dat een kleine schommeling bij de retailer tot een serieuze schommeling bij een fabrikant kan leiden. Oorzaak van deze schommelingen is vaak: een te lang en te traag communciatiekanaal tussen bijvoorbeeld retailer en fabrikant.

Het bullwhip effect bij voorraadbeheer

Mijn tip: zorg er voor dat jouw bedrijfsbrede software de mogelijkheid biedt om met tijdsparameters te werken bij de berekening van de verschillende voorraadniveaus. Zorg er tevens voor dat eventuele schommelingen of veranderingen in aankoopgedrag zo snel mogelijk worden gedetecteerd (via sales, inkoop, logistiek) en gecommuniceerd naar de volgende schakels in de keten. Op die manier vermijd je het bullwhip effect.

Op weg naar een geslaagde Supply Chain

Ik wil het met u graag eens hebben over een deelgebied van ERP: Supply Chain Management (SCM). Het is een belangrijk onderdeel van uw bedrijfsbrede software en beslaat de volgende deelgebieden:

* voorraadbeheer
* magazijnbeheer
* productie
* logistiek (transport)

Vele KMO’s worstelen met één of meerdere van de deelgebieden van SCM omdat ook hier met een buikgevoel wordt gewerkt, terwijl er eigenlijk vrij eenvoudige methodes zijn om van een ad hoc benadering tot een berekende en gefundeerde werkwijze te komen.

Als softwareleverancier houden wij bij de implementatie van onze software rekening met het PIP-principe, drie aspecten die, mits goed gemanaged, zullen zorgen voor een geslaagd project.

1. Technisch de juiste keuzes maken (Process): vooraf wordt bepaald welke technische keuzes we willen maken. Het gaat hier over hoe gaan we picken, welke technologie willen we gebruiken in het magazijn voor het aanvullen van de rekken, is er sprake van scanning, … Het is duidelijk dat hier keuzes worden gemaakt in functie van de grootte van het magazijn, het soort producten, de doorlooptijd voor de productie, enz.

2. De juiste informatiestromen beheersen (Information): hier worden de bestaande processen vertaald naar de software en wordt gekeken in welke mate de output aan informatie vanuit de software beantwoordt aan de kwaliteit en hoeveelheid aan informatie die we nodig hebben om bijvoorbeeld een juiste forecast te maken. Soms moeten er ingrijpende beslissingen worden genomen. Soms moet het proces worden veranderd om aan te sluiten bij de hoeveelheid aan informatie uit de software. Een andere keer is het de software die moet worden aangepast.

3. Competentie van het team (People): hoe zit het met de mensen ? Hebben zij voldoende discipline om de processen te volgen en helpt de informatie (software) daarbij ? Hier wordt tevens gekeken hoe robuust het proces wel is, hoe “fool”-proof het is. Vaak brengt een strakkere beschrijving van de processen en afspraken, nieuwe problemen met zich mee. De mate waarin de processen daar in voorzien en een oplossing bieden, is dus één van de barometers voor een geslaagd project. Bewustzijn creëren in de groep is van levensbelang. Het gaat hier om veranderingen en die moeten worden gekaderd. Zonder “people” heb je geen project.

Mijn advies: bekijk en bestudeer de aspecten van elk van deze drie puntjes in detail indien je met een degelijk voorraad- en magazijnbeheer wilt starten. Het is bepalend voor het welslagen van uw project en zorgt er voor dat iedereen mee is, dat iedereen is geraadpleegd. Het rapport van deze studie zal de basis vormen van de briefing aan de medewerkers en uw softwareleverancier.

Wees voorbereid op een schok !

Wanneer je als bedrijfsleider begint aan de selectie en de implementatie van bedrijfsbrede software, wees dan voorbereid op een serieuze shake-up.

Er zullen allerlei verkopers over de vloer komen. Zij zullen zich profileren als consultants, als adviseurs die je blindelings kan vertrouwen. Dat laten ze je geloven. Zij zullen je zeggen hoe je de boel moet draaiende houden en waarom hun software onontbeerlijk is. En jij zal dit moeten ondergaan.

Eens je de keuze hebt gemaakt voor een leverancier, zullen de medewerkers zich beginnen verzetten. Je zal tot de vaststelling komen dat niemand je voortijdig heeft verwittigd dat bij het invoeren van software er een plan moet bestaan om de veranderingen in én door te voeren.

Plots begint iedereen je vragen te stellen. Over hoe je bepaalde zaken aanpakt binnen jouw organisatie, wat de interne afspraken mbt bepaalde procedures zijn. Plots lijkt het alsof alles in vraag wordt gesteld en vraag je jezelf af wat je de laatste 10 jaar eigenlijk hebt gepresteerd. Alsof niks nog goed is.

Bedrijfsbrede software implementeren is een wetenschap met vele facetten. Bereid je goed voor en laat je adviseren. Zoek iemand die dit hele proces voor jou kan faciliteren zodat je mogelijke problemen kan counteren, nog voor ze zich voordoen.

Komaan, ook jij kan het. Honderden bedrijfsleiders zijn je voor gegaan, ook al is slechts 50% er in geslaagd om er een succes van te maken.

Een kleine extra inspanning, grote gevolgen.

Wanneer een bedrijf kiest voor een bedrijfsbrede oplossing moet het rekening houden met de wijze waarop het initiatief en de investering wordt “gedragen” door de werknemers, de verschillende afdelingen en de afdelingschefs. Ik heb voor u 2 tips om tot een, door gemotiveerde medewerkers, aanvaarde oplossing te komen.

Tip 1: vergeet niet dat binnen de organisatie en tijdens de selectiefase van een nieuwe software, de “buzz” een nefaste invloed kan hebben op het hele project. Medewerkers voelen zich al snel uitgesloten, denken dat hun job of althans hun manier van werken in gevaar komt. Ze vrezen voor ander en meer werk, ze denken aan meer controle en minder vrijheid.

Een initiatief dat ik als software-consultant al een aantal keer heb genomen, is het geven van een voorstelling over bedrijfsbrede software. Tijdens een vergadering met de medewerkers wordt dan de nadruk gelegd op wat is het, wat het kan betekenen voor het bedrijf en waarom doen we dit. Merk op dat ik hier bewust over “we’ spreek. De medewerkers moeten het gevoel krijgen dat we samen in een project stappen en moeten weten waarom we straks op een andere manier en met een andere software aan de slag gaan. Informeren en pro-actief zorgen en vragen wegnemen, daar komt het hier op aan. Veelal zie je dan een soort rust terugkomen. Bovendien lijkt het er op alsof het hele project nu echt wordt gedragen door de organisatie.

Tip 2: soms heeft uw software een beetje extra kruiding nodig. Ik spreek hier graag over nice-to-have’s. Het zijn extra functies die meestal als een schil rond uw software hangen maar die voor bepaalde gebruikers voor een plotse, grotere aanvaarding van de software zorgen.

Indien uw softwareleverancier in een model zit waarin men de software kan uitbreiden aan de hand van modules, dan kunt u misschien mits een geringe extra investering, een afdeling of een aantal gebruikers blij maken met nieuwe extra tools zoals: integratie met Isabel, gebruik van de koppeling met de telefooncentrale, een digitaal archief integratie met mail, gebruik van sms-verwittigingen, enz …

(hier alvast een aantal toepassingen: www.smscomfort.com, www.smartdoc.be , www.isabel.eu, www.keylinkcti.com)

Vraag dus eens na bij uw leverancier waar er eventueel nog zaken zouden kunnen worden geoptimaliseerd, weeg de aankoop af tegen de meerwaarde, kijk voor hoeveel gebruikers dit geldt en hoe lang het zal duren eer men er voordeel uit haalt. Je zal zien dat er vandaag tientallen toepassingen in aanmerking komen en die moeten daarom écht geen fortuin kosten.