Kunt u eenvoudig productierapporten opstellen?

Discussieforum Productie Rapportering – 5 maart 2015
Deel uw ervaringen en leer uit die van anderen!

Meer info


ERP Gap Fillers

It looks like many ERP implementations have a lot of holes and do not cover all business processes in an automated way. Indeed, how can one otherwise explain the wide variety of business initiatives and new businesses that offer solutions in supplement to ERP to fill in the gaps?

Yesterday I read a white paper of a medium-sized software vendor offering a solution to automate the processes of accounts receivable (AR) and payable (AP) in organizations that have implemented an ERP system from a major vendor. One could expect that AR and AP are basic business processes that should be incorporated in an ERP system. Nope! There are several reasons why this gap-filling business is booming. Since business growth nowadays is mainly achieved by M&As, large companies are still struggling with implementing one standard ERP-template in all their affiliates. Time is not always on their side. The greatest common divider of their ERP-template is therefore very small leaving a lot of holes that cannot be covered in the system. These organizations do not manage to fully implement an end-to-end solution for their business processes. Processes AR and AP are considered as quite complex and at times very different over geographic locations, so there are left over to the gap-fillers.

Same goes for the accounting and bookkeeping systems in ERP. Nothing is more country specific as a tax system (e.g. VAT system). Several documents and even complete work flows are defined by governments and are sometimes surprisingly well automated by e-government initiatives, but not so well in the major ERP systems. This time it are the ERP-systems that are lagging behind. Again this leaves room for gap fillers. Therefore it is of no surprise that there is still a large number of independent software vendors selling their country specific accounting systems to organizations where large ERP vendors has once promised to cover the complete set of business processes.

Another example where gap fillers see opportunities is in the domain of business intelligence (BI). BI should be the pedal of an ERP system. Was the promise of ERP not to cover all operational processes and bring them onto a tactical level from which they should deliver information to the strategic level of the organization? It is therefore sad to see that precisely for BI there are a lot of separate products, largely based on open software, that must fill in the gaps.

There are in addition some problems related with ERP that gives extra fuel for the gap fillers. A common problem for many ERP implementations is the often poor performance in terms of response times. ERP systems are centralized systems but incorporate a broad spectrum of different software trunks, all having different operational requirements. This constitutes a system with a very heterogeneous nature. For example heavy duty transaction systems like order-entry systems often demand the largest portion of  performance of the system, leaving no room for simultaneous running BI processes. Cloud computing does not always offers a solution here since the variation in demand for immediate performance does not change in a cloud setting. The only solution is therefore sometimes to uncouple the operational data from the centralized system to a separate system. The latter from which BI is operating.

And there is of course the ever present sword of Damocles over the ERP system in the shape of user rejection and resistance to the software. Not all users fully embrace the often complex ERP user interfaces and therefore tend to adopt ‘easier’ solutions.

The discussion inside or outside the ERP is most active in SMEs. Smaller organizations have tighter IT budgets and are therefore sometimes more demanding to ERP systems than large ones and are challenging the selling propositions of ERP vendors. Unfortunately this leads again to lots of IT failures due to unmatched selling promises!



After all these years, ERP implementations still fail…

The last three months I spotted five articles in the business press of failed ERP projects. Names of companies, involved project leaders, CEOs, CIOs and lawsuits are all mentioned without camouflage; this might be the top of an iceberg. It is remarkable but all major ERP suppliers and consultants are involved. It is certainly not a one actor concourse. Off course it is very difficult to reveal the exact causes of these failures, since both parties, customer and consultant (or supplier) are making their points of defense or complaint.  But there are some common components involved as we shall see. Let’s first review in short the five cases.

Case One. The plaintiff (customer) complains about the consultant lying about his skills to manage the project. The consultant will continue to defend his work vigorously. (lawsuit claim = $90 million)

Case Two. An ERP supplier cannot deliver on time making the customer to delay its financial filling. The consultant didn’t respond to  the claim. (lawsuit claim unknown)

Case Three. After a formal selection, the customer discovers that the proposed ERP  is dated and that the users find it hard to change to the ‘new’ system. The consultant was taken away from the project. (lawsuit claim = $33 million)

Case Four. A customer decides to halt the roll-out of an ERP due to massive budgetary over spendings. The consultant didn’t respond to  the claim. (lawsuit claim = $2 billion).

Case Five. A customer was proposed a vanilla implementation of an ERP. However the implementation took massive customizations to make a fit with the organizational needs. The consultant will continue to defend his work vigorously. (lawsuit claim = $102,000)

The customer organizations in all of the former cases are in no way small and medium-sized enterprises (SME), but well staffed organizations with IT capabilities, and the consultants and the suppliers tend to have a proven (?) track record. This raise questions on the approach of such projects. Can we still use the well known techniques of project management if it turns out that we constantly ran out of time and budget? Isn’t it time to rethink our current models of governing these large complex organizational and technical projects?  Is ERP really a solution or is it the problem? Maybe we should start all over again with the implementation of information systems and start to make an organizational architecture from which we can derive a workable system instead of doing the opposite. All too often ERP is proposed as a solution to avoid the difficult and often tedious exercise of making an enterprise architecture. In such a context ERP vendors make sometimes expensive promises to bridge fit-gap analyses and bring themselves in defense positions. Indeed, the most compelling factor in all cases is that the plaintiff is the customer.

jan devos

Vertrouwen: sleutel tot geslaagde IT projecten

KMO-IT Leveranciersevenement – dd 15-03-2012

Keynote presentation:

Vertrouwen: sleutel tot geslaagde IT projecten.


jan devos

SMEs and ERP (Extreme Risky Projects)

We have been building information systems (IS) for more than 50 years now and still have not learned to do it successfully. Business literature as well as academic literature is full of cases reporting and explaining what when wrong. It is reported by the Standish Group that almost 70% of the IT project is not successful, meaning that they went over budget, over time, did not met with the initial requirements or were simply canceled. Although research on the phenomenon of IS failures  has evolved enormously it looks like not a lot has been learned. In the early days of the computer era, most IT failures where noticeable in the development of bespoke applications. Nowadays we see IT failures in ERP implementations.

IT failures can be classified in correspondence, process and interaction failures (Lyytinen et al., 1987). Correspondence failures occur when the outcome of the developed and implemented information systems does not match with the design.  Process failures are errors in the development or implementation process. Examples here are running over time or over budget. Interaction failures occur when the users refuse to use the system for all sort of reasons (resistance, not useful, no ease of use, …). Most IT failures however show a combination of all aforementioned characteristics. The occurrence of these characteristics is in no way logical. One characteristic can provoke another.

The most frequent failure factors found in 2011 for software development projects are: ‘delivery date impacted the implementation/development process’, ‘project was underestimated’, ‘risks were not re-assessed, controlled or managed’ and ‘staff were not rewarded for working long hours’ (Cerpa and Verner, 2011).  We see these factors also in ERP projects. Additional For ERP projects Kim (2011) found that user resistance is also critical for the high failure rate. Kreps and Richardson (2007) state that large-scale IS projects suffer from recognized and well-documented problems including: ‘scope creep’, ‘escalation of costs’, ‘failure to meet the expectations of the stakeholders, who persistently overestimate the capacity of IT to solve operational problems’, ‘failure of the technicians in the project to engage with all stakeholders in the project, resulting in solutions that baffle the end-users and sometimes miss the point completely’.

What can we learn from all these findings?

I think that everything points towards an alternative approach of bringing IT into organizations. Small, discrete projects that are well manageable seems to be of key importance. ERP projects are by definition large projects with long implementation times. Is this really the solution for SMEs? We should adopt a less imperative view of technology and how information systems are socially as well as technically constructed. ERP systems are not born out of our theoretical insights in information systems, but were build by large enterprises and implemented manu military. It should be clear that ERP systems will not install themselves in organizations, nor can its use be taken for granted.

For SMEs, Snider et al (2009) found six critical success factors for successfully implementing ERP: 1) operational process discipline, 2) small teams (less than 5), 3) sufficient project management capabilities (with strong leadership), 4) external end-user training, 5) management support (commitment), and 6) a qualified external consultant.

ERP projects are indeed extremely risky projects and before starting one, an SME should contemplate if the internal organization is really ready to take the challenge. In that process an independent software vendor should be as honest as possible and not hide away the real risks of an ERP project and even be brave enough to advise his SME prospect to waive an ERP project when the risks are not taken seriously.

jan devos

‘Sensemaking’ van ERP in KMO’s

In mijn posting van 26/02/2012 had ik het over management of meaning, een alternatief perspectief op ERP in KMO’s. Ditmaal wil ik het hebben over de ontwrichtende natuur van ERP en hoe we daar kunnen mee omgaan door aan ‘sensemaking’ te doen.

Het implementeren van ERP in een organisatie kan zeer verstorend werken op de organisatorische structuren. Dit is een intrinsieke kracht die zowel in het voordeel van de organisatie kan werken, wanneer veranderingen zich opdringen, als nadelig als de veranderingen niet gewenst zijn. Mensen hebben de gewoonte te denken dat de gebeurtenissen zich altijd coherent in tijd en ruimte voordoen en dat veranderingen zich ordentelijk zullen manifesteren. Niets is minder waar. Een ERP kan een organisatie tot een punt brengen waar men geen enkel idee meer heeft waar men staat en hoe men hieruit geraakt. Op een dergelijk punt gekomen is het belangrijk dat een ERP-project geleid wordt door niet alleen ervaren, maar vooral door competente mensen die weten dat dergelijke situaties zich meer wel dan niet voordoen bij de implementatie van strategische informatiesystemen.

Grote bedrijven hebben de ontwrichtende kracht van ERP vooral gebruikt om hun organisatie te veranderen. De oudere, niet-geïntegreerde informatiesystemen werden vervangen door één centraal systeem dat de meeste bedrijfsprocessen ondersteunde. Dit gaf een positief effect op meerdere terreinen. In eerste instantie werd er orde op zaken gezet in de interne IT-afdeling. Gedaan met eigen ontwikkelingen en de veel te lange lijst van noodzakelijke softwareaanpassingen die er maar niet kwamen. De CEO nam als het ware het bevel van de IT-functie over. Meteen werd er een stukje IT-outsourcing geïntroduceerd en kon men afscheid nemen van verouderde en te dure computersystemen inclusief de bijhorende technische mensen. Een positief effect kon meteen ook gegenereerd worden op de organisatie. ERP liet toe om verschillende afdelingen of vestigingen allemaal te voorzien van dezelfde wijze van werken. Vooral M&A’s deden daar hun voordeel mee. Met de hulp van ERP werd als het ware een organisatorische eenmaking gerealiseerd.

Het zal de lezers die werken in een KMO niet ontgaan zijn dat voormelde voorbeelden weinig van toepassing zijn in de organisatorische context van KMO’s. Informatiesystemen in KMO’s zijn niet altijd zo verouderd en organisatorische problemen met een overname worden daar niet met IT opgelost. Toch gaan vele KMO’s massaal over tot de invoering van ERP.

Sensemaking is managing of meaning

Een wijze om naar organisaties te kijken is deze te bestempelen als structuren waarbinnen er constant beslissingen worden genomen. Het nemen van beslissingen moet zeker bekeken worden in het licht van de context waarbinnen de organisatie zich situeert. Opnieuw komt nu de ‘sensemaking’ of ‘management of meaning’ de kop op steken. De mensen in de organisatie nemen beslissingen die (inter)subjectiviteit verbinden aan een normatieve context. Dit is wat ik denk dat er zich voordoet met ERP voor KMO’s. De normatieve context is deze waarbinnen ERP de eigenschap toegemeten krijgt dat het een voordeel brengt voor (alle) organisaties. Dit komt overgewaaid vanuit de grote bedrijven waar met succes een veranderingsproces mogelijk gemaakt werd door ERP, zoals hoger beschreven. Het imiterende gedrag van KMO’s aan dat wat er in grote bedrijven gebeurt kan verklaren waarom KMO’s uitkijken naar een ERP.  KMO’s rationaliseren het positieve beeld van ERP en geven hierdoor een betekenis aan de beslissingen die ze nemen. De ICT-leverancier helpt, bewust of onbewust mee aan dit proces. Toch kunnen ICT-leveranciers niet doof blijven voor de keerzijde en dat is dat de voordelen die ERP met zich meebrengt niet altijd van toepassing zijn op KMO’s én indien dit zo zou zijn, de weg van de implementatie zeer moeizaam verloopt.

De sensemaking wordt nu echt belangrijk om het positief beeld van ERP staande te houden en is een uitdaging en zelfs een plicht voor zowel de leverancier als de klant. Zeker als de tastbare (en meetbare) effecten van ERP op de organisatie amper meetbaar zijn. In eerste instantie moet de verhouding kosten/baten positief blijven. De moeite dat een KMO zich moet getroosten om een ERP-implementatie van de grond te krijgen (de kosten) moet evenredig zijn met de perceptie van een blijvend positief beeld (de baten). De kosten zullen zeker aanzienlijk zijn, niet louter financieel maar vooral onrechtstreeks door het intensieve werk nodig om een ERP operationeel te krijgen. Dit betekent dat de creatie van een positief beeld idem dito aanzienlijk moet zijn.

Het is in het onvoldoende opbouwen van sensemaking van ERP dat KMO’s het vertrouwen in de ICT-leverancier verliezen. De sensemaking moet door een ervaren projectleider worden ondersteund. Hier laten ICT-leveranciers vaak onbewust een steek vallen door onervaren mensen in te zetten. Op de momenten van verwarring die zich meer dan ooit tijdens de implementatie voordoen moet de projectleider niet alleen het hoofd boven water kunnen houden maar ook de mensen in de KMO-organisatie blijvend met zich mee krijgen. Dit is echter geen exacte wetenschap die enkel door middel van een projectmanagementcertificatie kan worden verworven, hoezeer we een dergelijke aanpak ook toejuichen. Een formele projectmethodologie zal nodig en behulpzaam zijn, maar voldoende is het zeker niet om de sensemaking te realiseren. De ontwrichtende kracht van ERP kan de projectleider hierbij ernstig parten spelen. Mensen zullen de verandering door ERP tegenwerken, indien de verandering hun plaats en positie in de organisatie zal aantasten. Weet de projectleider dit? En zo ja wordt hij daarin geruggensteund door de CEO van de KMO? Dit brengt ons op een andere belangrijke voorwaarde voor de sensemaking en dat is het engagement van de CEO in het project. Dit engagement kan niet enkel contractueel worden afgedwongen en vervolgens gebaseerd zijn op een deelname in een stuurgroep waarbij er enkel naar het budget en de planning wordt gekeken. Sensemaking werkt toch wel anders. De sensemaking moet de verwarring die ontstaat tijdens het project kunnen tegengaan. Klant en leverancier moeten hier samenwerken. Een klassieke gepolariseerde klant-leveranciersrelatie zal hier niet werken. Ook een KMO moet dit willen begrijpen.

jan devos

ERP in KMO’s: Management of Meaning?

Enterprise Resource Planning of kortweg ERP is nog steeds aan de orde, zeker in kleine en middelgrote bedrijven (KMO’s). Over IT in KMO’s heb ik wat onderzoek gedaan en daarbij gevonden dat deze bedrijven toch wel ‘anders’ zijn met betrekking tot het invoeren van ERP. Eén zaak hebben ze zeker gemeen met grote bedrijven, in beide soorten organisaties mislukken vele ERP-projecten. Over het mislukken van ERP-projecten heb ik langere tijd stil gestaan en gegraven naar mogelijke oorzaken.

Wat heb ik gevonden? Vooreerst dat mislukken een relatief begrip is. De mislukkingen die vooral in de kijker lopen zijn de zogenaamde procesmislukkingen waarbij een IT-project meestal ruim over budget en over tijd gaat. Het zijn de hele grote (overheids)projecten die hier de meeste wind vangen. Denk maar aan de automatisering van de rechtbanken in België, de douane, de belastingen, en nog veel meer. Ook in het buitenland zijn er verhalen legio, waarbij de bedragen zo waar nog groter zijn. Is dat relevant voor KMO’s? Niet echt, hoewel er altijd kan geleerd worden hoe het niet moet natuurlijk. Een veel groter aantal ‘mislukte’ projecten zijn deze die verder kabbelen, half operationeel zijn en eigenlijk nooit hun gestelde doelstellingen halen. Hier zitten veel ERP-projecten tussen en ditmaal veel in KMO’s. Men noemt dit geen mislukte projecten omdat ze eigenlijk wel werken. Een succes noemt men ze ook niet omdat ze te veel geld gekost hebben en te weinig resultaat opleveren.  Wel dat laatste is het meest essentiële in de gehele discussie. Wat is het resultaat van een geïmplementeerd ERP-systeem in een KMO? Een eenvoudige vraag waar helaas geen eenvoudig antwoord kan op gegeven worden. Heel veel onderzoekers breken zich hier het hoofd over, maar er ontbreken nog altijd duidelijke antwoorden. Uit mijn eigen onderzoek heb ik geleerd dat vele mislukkingen in KMO’s een oorzaak vinden in deze eenvoudige (naïeve?) vraag naar concreet resultaat.

KMO’s zijn anders heb ik gezegd, wel dat blijkt onder meer uit het feit dat ze in tegenstelling tot grotere bedrijven over weinig IT-kennis beschikken en daardoor intens beroep moeten doen op een ERP-leverancier. Hier beginnen de problemen. Ik wil geenszins goedkoop uithalen naar de ERP-leveranciers, maar het is een feit dat het aanbod van kwaliteit geenszins homogeen is. Dit is een eerste moeilijkheid voor de KMO. Wie moet je kiezen? Uit de principaal-agenttheorie leren we dat de KMO-principaal omwille van zijn onkunde en onwetendheid hier een verkeerde keuze kan maken. Een agent kan zich wel eens beter voorstellen dan wat uit de realiteit blijkt. Uiteraard moeten we ook met de vinger wijzen naar de KMO. Die moet beter zijn huiswerk maken en de selectie van een ERP-leverancier grondiger aanpakken. Maar zelfs na een goede selectie, met behulp van een externe onafhankelijke ICT-consultant, heb ik ERP-projecten de mist zien in gaan. Terug dus naar de vraag: wat moet het ERP-systeem opbrengen? Want hier ligt de knoop gebonden. Ik durf te stellen dat het antwoord op de vraag naar resultaat niet kan beantwoord worden, althans niet met duidelijk meetbare grootheden. Een ERP-systeem zal geen besparingen opleveren, geen extra verkoop genereren of geen nieuwe klanten aanbrengen. Het is te zeggen, ik sluit het niet uit maar ik heb het nog nooit gezien en geloof me vrij ik ben al in veel organisaties geweest en heb al met veel KMO-managers gesproken. Ooit heb ik een verkoper van een ERP-systeem gekend die in zijn drieste moed om toch maar een systeem te kunnen verkopen een kleine berekening van een ROI had gemaakt, om zijn klant (de KMO) te kunnen overtuigen. Op het einde van de rit en dus na de mislukking werd de rekening gepresenteerd en had de advocaat van de klant het kattebelletje waarop de berekening van de ROI genoteerd was als bewijsstuk aangevoerd om toch maar aan te tonen dat het resultaat uitbleef.

ERP-systemen hebben de eigenschap dat ze veranderingen induceren in een organisatie waardoor het meten van de status voor en na quasi onmogelijk is. In KMO’s is meten al een probleem. KMO’s meten niet echt in kwantitatieve grootheden. Een zicht krijgen op de kosten is voor velen al een groot probleem. Een ERP-systeem brengt daar niet echt een verandering in, hoewel het potentieel er natuurlijk wel is, zeker met toegevoegde BI-tools. Bij KMO’s zit het probleem bij de managementbekwaamheden die ontbreken. Men runt een business maar hoe de onderliggende processen werken is vaak van ondergeschikt belang. In een KMO neemt men wel eens de assumptie aan dat de bedrijfsprocessen kunnen geautomatiseerd worden zoals men een productiehall kan automatiseren. Dit is een zeer mechanische visie en een idee dat zeer algemeen gekoesterd wordt en daar zit opnieuw de aanbodzijde in de fout. Het onvoorspelbare veranderingsaspect van een ERP-implementatie wordt onvoldoende in de verf gezet. Dit veranderingstraject verloopt weinig rationeel, concreet en zit vol risico’s. Om één of andere reden denken we dit te lijf moeten gaan met controle. Bijvoorbeeld met een formeel project managementsysteem. Dit is natuurlijk de aanpak in de grote bedrijven, waar de managementtechnieken veel uitgebreider zijn. Dat kan natuurlijk wel de oplossing zijn, maar dan komen we weer bij het beginpunt: waarom lopen zoveel projecten verkeerd af, zelfs met een goede methodologie en vooral ook in grote bedrijven?

Misschien moeten we het wat meer zoeken bij de sociale waarden in een organisatie? Er gebeurt recentelijk nogal wat onderzoek over ‘management of meaning’. Dit is doen en meteen ook communiceren. Het concept bevat echter ook de notie van ‘mysterie’ waarbij er gesteld wordt dat niet alles binnen een communicatieproces kan verklaard worden. Niet alles wat er gebeurt en ervaren wordt kan in een coherent verhaal worden gebracht, hetgeen we moeten accepteren. KMO’s staan mijlenver van dit concept, toch worden ze er dagelijks mee geconfronteerd. Het is helaas niet evident om in een bedrijfscontext, gedomineerd door het controleparadigma hier over te praten zonder compleet belachelijk over te komen.  Een ERP-project is nochtans één groot communicatieproject, dat nieuwe betekenissen geeft aan gebeurtenissen in een organisatie. Een ERP-systeem verandert de arbeidsverhoudingen en de werkomgeving. Dit is voor vele mensen al een serieuze ingreep op hun functioneren. Ook de KMO-manager wordt hierdoor geconfronteerd en zal een leerproces doormaken. Dit proces begeleiden is uiteindelijk de boodschap voor een externe IT-consultant of ERP-leverancier. De vraag is of ze daartoe bereid zijn. Licenties, servers en storage verkopen zijn wat dat betreft heel wat minder risicovol. Wat het ook zij, eerlijkheid schaadt niemand. Ofwel verkoop je IT (letterlijk: informatietechnologie) of wel verkoop je een informatiesysteem (IS). Het lijkt erop dat de kunst om dat laatste te verkopen niet aan iedereen besteed is.

jan devos

%d bloggers like this: