Implementatiepartners spelen een grote rol bij het slagen of mislukken van SAP-implementaties. Dat zeggen Computable-experts in reactie op de uitspraak van de directeur van SAP-Nederland. Zij zei eerder dat klanten vaak zelf verantwoordelijk zijn voor het mislukken van SAP-implementaties.
De directeur van SAP-Nederland Angelique de Vries zei in een interview met Computable dat het mislukken van SAP-implementaties vaak te wijten is aan de klant zelf. Drie Computable-experts buigen zich over die uitspraak. Daarnaast stelde zij dat bedrijven vaak onvoldoende realiseren dat een implementatie gevolgen heeft voor de bedrijfsvoering. De experts kijken ook naar het programma voor waarborging van de kwaliteit van de Duitse leverancier en bespreken het beeld dat SAP-projecten vaak mislukken.
"Dat het mislukken van SAP-implementaties vaak te wijten is aan de klant zelf, is te kort door de bocht en moet worden genuanceerd", vindt directeur en managing consultant Dynamics
Riccardo Arnst van TMC Dynamics Professionals. Hij benadrukt dat er altijd twee partijen verantwoordelijk zijn voor het slagen of mislukken van projecten. Freelance SAP-consultant Erwin Dekker: "Je kan de schuld niet op één partij afschuiven. Dat verschilt per situatie. Implementatiepartners spelen ook een cruciale rol in het slagen of mislukken van een project", aldus de oprichter en voorzitter van MySapply, de stichting die de belangen van ruim 230 freelance SAP-consultants behartigt.
Arnst vindt dat er ook een kern van waarheid in de stelling van de SAP-directeur zit: "Klanten nemen soms beslissingen die tegen het advies van de implementatiepartner ingaan. Als het project vervolgens misloopt, ligt het volgens de klant ineens aan de software en de adviseurs van het project. Dat is niet terecht." Managing consultant Aart van Berk Atos Origin: "De implementatiepartner speelt een belangrijke rol om mislukkingen te voorkomen. Hij moet onhaalbare voorstellen van klanten durven te weigeren en het financiële belang dat hij heeft buitenspel kunnen zetten."
Ingrijpend
Volgens de Nederlandse SAP-directeur realiseren bedrijven zich onvoldoende wat het effect van een implementatie is op hun bedrijfsvoering. In het interview stelt ze: "Iedere implementatie van bijvoorbeeld een erp-systeem is ingrijpend voor de gebruikers. Dat geldt net zo goed voor ons als voor onze concurrenten." De experts herkennen dat beeld.
Aart van Berk: "Bedrijven stappen vaak over van een verouderde maatapplicatie naar een standaardapplicatie van SAP. Ze denken: ‘wat in het oude programma kon, kan ook in het nieuwe uitgebreide pakket. Die vasthoudendheid werkt niet bij een standaard pakket. Soms moet de organisatie veranderen om in het pakket te passen." Van Berk benadrukt dat maatwerk goed mogelijk is maar dat het dan wel extra geld en inspanning kost.
Arnst ziet dat vooral bedrijven die voor het eerste een grote implementatie doorlopen de gevolgen voor de bedrijfsvoering onderschatten. "Een van de eerste vragen die wij onze klanten stellen is: ‘Realiseert u de impact van de implementatie voor de dagelijkse werkzaamheden. Bent u ervan bewust dat u zelf een inspanning moet leveren om de implementatie tot een succes te maken?'."
Monitoren
Om te voorkomen dat implementatietrajecten mislopen is SAP gestart met het Quality Insurance Programma. Door projecten continu in de gaten te houden worden eventuele problemen in de kiem gesmoord.
Aart van Berk merkt dat de betrokkenheid van de leverancier de laatste jaren groter is geworden. Steeds vaker wordt ook bij contracten met middelgrote en kleine bedrijven gekeken of de implementatie wel op de goede weg zit. Riccardo Arnst vraagt zich af of het zogenoemde Quality Insurance programma wel de oplossing is. Volgens hem zou een onafhankelijke derde partij meer kunnen aantonen dan de peilstok van de leverancier. Hij vindt de controles van SAP een zinvolle aanvulling maar vindt dat door goed projectmanagement en een volwassen houding van de stuurgroep de vorderingen van een implementatie in kaart gebracht kunnen worden.
Erwin Dekker "Het is belangrijk om implementaties op te delen in blokken. Door de implementatie gefaseerd door te voeren is er voor de klant meer overzicht en de implementatie komt vaak beter overeen met de verwachtingen van de klant.
Imagoprobleem
Door een mislukte SAP-implementatie bij Free Record Shop en de provincie Noord-Holland heeft SAP het imago van dure en moeilijk te implementeren software. De Vries zegt dat het lijkt alsof projecten van de Duitse softwareleverancier relatief vaak mislukken omdat er in de media te weinig aandacht is voor de succesverhalen. De experts kennen de vooroordelen van klanten over de bedrijfssoftwarereus.
Dekker: "De gebruiksvriendelijkheid kan nog steeds beter. Het programma heeft veel complexe schermen . Het is voor gebruikers niet altijd duidelijk wat de stap of het proces is in het grotere geheel. Menu's zijn erg uitgebreid en standaard koppelingen zijn voor een gebruiker vaak niet te begrijpen. Dat lijkt de arrogantie te zijn van de grootste leverancier. Het is machtsmisbruik."
Dekker merkt dat er bij klanten vaak het vooroordeel bestaat dat paketten van de Duitse leverancier duur zijn en een lange implementatietijd vergen. "Maar er zijn juist paketten speciaal voor middelgrote en kleine bedrijven. Die software kan binnen enkele weken geïmplementeerd worden en biedt alleen een selectie van de functionaliteiten." Riccardo Arnst heeft voor kleine bedrijven die minder functionaliteiten willen een pakket van een concurrerende leverancier in het productaanbod.
De “bijdrage” van Jan van Leeuwen was mij ook al opgevallen. Hij probeert “argumenten” op te voeren tegen SAP welke geen hout snijden. Iedere voorstander van SAP is een tegenstander voor van Leeuwen. Dat is wel duidelijk uit zijn reakties.
“Dat hadden we al jaren geleden en iedere automatiseerder die een basiscursus doet leert dat juist dat de verkeerde weg is. Past de software niet bij de organisatie moet je andere software kiezen.”
Waar is deze basiscursus gevolgd? Werkt u zelf alleen maar met software die bij u past? Wel eens gehoord van een kosten baten analyse? Waar is de realiteitszin?
Ook lijkt het de praktijk van dhr van Leeuwen om het financiele belang van zijn organisatie boven het klantbelang te stellen. Dat is blijkbaar zijn realiteit. Het advies om dit niet te doen doet hij af als niet getuigen van realiteitszin.
“Ja hebben we dan niets geleerd? Geen SDM 1 of 2 of hoe het vandaag de dag mag heten? IEDERE implemantatie moet gefaseerd doorgevoerd worden, als je een groot softwarepakket plotseling in een organisatie plempt, dan richt je schade aan. Die “implementatoren” die dat doen zouden voor de schade moeten opkomen.”
Heer van Leeuwen weet niet hoe dit vandaag de dag mag heten (in ieder geval geen implemantatie als we het toch over taalgebruik hebben). Lees nog eens goed de mening van Erwin Dekker. Hij heeft het m.i. over iets anders dan wat Jan denkt te lezen. Bepaalde functionaliteit van SAP wordt geimplementeerd in ??n brok volgens een projectplanning (bij SAP is dat veelal Prince 2 in combinatie met de ASAP methodiek), vervolgens kan je een volgend functioneel brok implementeren. Dat vind ik een verstandig advies. De meeste klanten willen in ??n keer veel te veel en dat is veelal onverstandig.
“Na dit tweede artikel moet een klant zich toch ernstige zorgen maken over de “expertise” van deze mensen. Iedere zichzelf respecterende automatiseerder moet toch een minimum talent hebben op gebied van projektplanningen anders moet je een ander beroep zoeken en zo voorkomen dat je klanten in de ellende stort.”
De projecten zijn niet fout gelopen door een foute projectplanning.
@Bram en @Jacco,
Zo… Ik was een paar dagen niet op deze site en het duurde dan ook even om door jullie zeer inhoudelijke discussie heen te komen. Het concept dat Jacco verwoordt kan ik tot op zekere hoogte begrijpen. Echter niet voldoende om daar een goed oordeel over te kunnen vormen. Als ik ergens terecht kan voor een uitgebreidere beschrijving, houd ik me daarvoor aanbevolen.
Ik begrijp Bram ook, die de abstracte utopische weerspiegelingen van Jacco graag geconcretiseerd ziet. Om eerlijk te zijn worstel ik daar ook wel mee.
Ieder systeem heeft tot doel bepaalde processen te ondersteunen of zelfs uit te voeren. Om dat te kunnen, werken we met modellen. Deze modellen representeren deze processen in hun meest abstracte vorm en bieden ruimte tot een eigen invulling van dergelijke processen. Ik noem dat invullen voor het gemak maar even configureren. Daarmee wordt de grootste gemene deler van alle processen (het model) vertaald in een concrete representatie. Ik heb het hier nog niet over techniek. Techniek is echter nodig om gegevens daadwerkelijk te kunnen opslaan, verplaatsen, verwijderen, presenteren etc. Die technische oplossingen KUN je ook vangen in een model. Daartoe moet je technologieen vertalen naar modellen en moet je diezelfde technologieen kunnen laten luisteren naar die modellen zodat bij de invulling van het model, zich als het ware automatisch een technische implementatievorm uitvouwt. Dat is mogelijk en wordt (in een weliswaar zeer starre vorm) ook toegepast.
Wat ik bij deze wil bestrijden is dat een object georienteerd model al onze processen kan omvatten. Objectorientatie is een hierarchische aanpak die zeer krachtig is. Onze wereld zit echter objectgeorienteerd EN relationeel in elkaar. Daar kun je niets aan veranderen. Natuurlijk streven we er zoveel mogelijk naar om onze werkelijkheid hierarchisch te presenteren omdat dat dat ons de mogelijkheid tot generaliseren biedt en op dat concept zijn onze hersenen nu eenmaal gebouwd. Voor ik helemaal afdwaal: mijn visie is dat modellen het fundament van een systeem vormen en dat er daarbinnen een hierarchie noodzakelijk is die gebaseerd is op abstractie. Het bestaan van modellen maakt het voor ons mogelijk om met elkaar te communiceren. Modellen zorgen dus voor een gemeenschappelijk “wereldbeeld”. Dat laatste mis ik in het verhaal van Jacco. Wie onderhoudt dit model? Je uitleg roept bij mij het gevoel op van een netwerk van samenwerkende cellen/processen, waarbij modellen in expliciete vorm niet meer terug te vinden zijn en ownership t.a.v. deelmodellen en de controle daarop niet meer mogelijk is. Dat is een situatie die niet wenselijk en niet te verkopen is.
Het gedrag van het systeem moet te allen tijde zijn gebaseerd op modellen waarop een vorm van ownership en release control van toepassing is. Daar is wat mij betreft een rol weggelegd voor IT-professionals (intern dan wel extern). De modellen die bekende processen beschrijven zijn al in grote mate geevolueerd en daarom al jaren vrij statisch.
Aan de andere kant is er de technologie en de daaraan gekoppelde modellen die deze technologie moeten ondersteunen. Daar zit een grotere mate van dynamiek, hoewel veel principes niet nieuw zijn. Op dat vlak is mijns inziens de grootste IT-rol weggelegd.
De eerste categorie aan modellen (de modellen van de kernprocessen) vormen het erfgoed dat decennia lang mee kan gaan. Kleine wijzigingen vormen het evolutieproces.
De tweede categorie aan modellen ondersteunt de technische implementatievormen waarvoor gekozen wordt. De dynamiek daarin is groter. Hierin kom je datawarehousing, BI, web technology, OPC, XML etc. tegen.
10 jaar geleden zijn we deze weg ingeslagen. We passen op bijna dagelijkse basis hotswaps toe, maar dat is blijft zeker een uitdaging: testen onder diverse omstandigheden blijft altijd noodzakelijk en gebruikers willen ook niet verrast worden met “zomaar” iets nieuws.
Maar… Ik ben een grote voorstander van de scheiding van model en techniek. Koester het model van de kernprocessen. Onderhoud en bewaak dat met je leven! Dat bepaalt de levensduur van een systeem. Een technologische oplossing kun je daar tegenaan modelleren. Laat deze 2 modellen zich NOOIT vermengen. Dat is het begin van het einde.
We draaien sinds 1999 24/7 (= full time) en laten de omvang van de kernprocessen geleidelijk groeien. Daarbij beperken we ons echter tot de processen waarvoor wij ownership hebben.
Het betoog van Jacco gelezen hebbende, denk ik dat onze ideeen in grote mate bij elkaar aansluiten. De kanttekeningen die Bram plaatst, zijn zeker niet alleen ?het nog niet snappen?. Die kanttekeningen zijn re?el en worden denk ik ook al wel onderkend door Jacco in de vorm van ?uitdagingen?.
De laatste reactie van Jan van Leeuwen vond ik overigens niet erg gepast. Je voert een discussie op inhoud en niet op syntax. Dat laatste doe je pas als de inhoudskaarten op zijn. We zijn tenslotte wel mensen en geen computers?
@Bram,
Ik weet niet of dit de plek is om er heel diep (technisch) op in te gaan, maar ik doe een poging het zo niet-technisch mogelijk te houden en per item te reageren.
* Het stukje “maintenance”: dit is uiteraard in (bepaalde gevallen) noodzakelijk. De grootste beveiligingsrisico’s / problemen ontstaan immers vaak door niet (tijdig) patchen. Alleen de vraag is: moeten gebruikers daar “last” van hebben. Of anders: hoe doe je dat met zo min mogelijk overlast voor de gebruikers. En waar wordt de noodzaak door ingegeven: technisch (oplossen van problemen) of omdat de leverancier (zo nodig) nieuwe features moet bieden, waarbij het de vraag is of de klant er echt om zit te springen (ik kan prima een briefje tikken in Word 97, daar heb ik geen Word 2007 voor nodig). Nu is dat vaak een package deal. Je krijgt een nieuwe release met opgeloste problemen en nieuwe features tegelijk, je kunt niet kiezen en je moet mee op straffe van het verliezen van support. Gedwongen winkelnering dunkt me. Ik moet de aannemer nog tegenkomen die het lukt om met het repareren van de badafvoer, meteen een nieuwe badkamer mee te verkopen, op straffe van dat het anders niet gerepareerd wordt.
En ik blijf erop hameren: technische zaken als performance, en laten we daar bugs e.a. problemen ook even onder scharen voor het gemak, staan los van en moeten los staan van de pure functionaliteit. Doordat techniek en functionaliteit nu vaak aan elkaar geklonken zitten, krijg je inderdaad het fenomeen, dat als je technisch problemen in de applicatie aanpakt, dat invloed heeft op de performance en andersom als je het niet doet.
Ik suggereer niet dat bedrijven risico’s willen of moeten nemen: juist niet. Door de geschetste modulaire aanpak loop je veel minder risico’s! Ga maar na: doordat techniek en functionaliteit zowel gescheiden van elkaar zijn, als verspreidt over verschillende componenten die onafhankelijk (!) van elkaar opereren, blijven problemen meestal “regionaal” beperkt tot 1 of enkele componenten. En dus ook de upgrades. Daarbij heb je dus geen grote monoliete systemen, die in 1 keer ge?pgrade moeten worden en dus down moeten. De gebruiker heeft er geen (zo min mogelijk) last van.
Met de geschetste modulaire aanpak heb je geen downtime nodig (voor de gebruiker). Als je bijvoorbeeld een grote database gebruikt voor allerlei belangrijke gegevens, dan voer je die (uiteraard) redundant uit. Tijdens de upgrade van de ene, is die dus niet beschikbaar voor componenten die erom vragen, maar de andere wel. De “oude” met de “nieuwe” synchroniseren (als het goed is zijn ze voor de upgrade synchroon) en dan de andere upgraden. Heb je bijv. datamodel verschillen, dan gebruik je coercion componenten, met “tussentabellen”, die even tijdelijk de lacunes van het “oude” datamodel opvangen tijdens de synchronisatie. Als de “oude” database is ge?pgrade en (ook) het nieuwe datamodel bevat, voltooi je de synchronisatie. Ondertussen heeft de gebruiker niets gemerkt. Heb je “maar ” 1database (server), dan kun je het onderstaande scenario voor een OS gebruiken.
Hetzelfde geldt bijv. voor een OS. Als je “maar” 1 server hebt, zet je er tijdelijk (gehuurd?) een andere (ge?pgrade) naast. Je kopieert je hele “componenten wolk” naar die andere nieuwe server. Zet die applicatie op de nieuwe server in “slave mode” en laat de hele productie daar ook door lopen. De testers kunnen dan testen of alles het nog goed doet met het nieuwe OS. Ondertussen draait de productie gewoon door op de oude server in “master mode”. (Het verschil tussen master en slave mode is dat de output / “impact” bij de slave “niet naar buiten gaat”. Verder zijn de omstandigheden hetzelfde: de ideale test situatie!). Als de situatie op de nieuwe server goed is bevonden switch je de master – slave verhouding om. De productie loopt door op de nieuwe server in master mode terwijl de oude ge?pgrade wordt. Is de nieuwe situatie op de oude server goed bevonden switch je de master – slave verhouding om, et voila, de productie draait op een ge?pgrade server. De tijdelijke server kan terug. Heb je 2 of meer servers, dan kun je hier heel creatief mee omgaan. Bij 2 servers gaat de performance wel om laag als je tijdelijk van 2 servers 1 maakt. Is dit een probleem, schakel je een extra (gehuurde) server bij. Hoe meer servers je hebt, hoe minder dit een probleem hoeft te vormen.
Al met al is het leven van een IT-er zo heel interessant en bevredigend, om uit te dokteren hoe hij achter de schermen alles soepeltjes kan laten verlopen, patchen, migreren, upgraden etc., zonder dat de gebruiker er “last” van heeft of niet kan werken.
* Het stukje “grens functionaliteit en architectuur”: dit is een heel interessante. Sommige componenten fungeren (inderdaad) als een soort proxies: de component biedt zich aan als zijnde iets te kunnen, maar is eigenlijk “leeg” en geeft alleen maar iets door van “iets anders”. Wat heb je daar nou aan zul je wellicht denken. Dit is uiterst krachtig, want ga maar na: terwijl je aan de “voorkant” iets aanbiedt, kun je er aan de “achterkant” van alles achter zetten, zonder dat iemand er iets van merkt. Zo kan die “proxy” component fungeren als een soort schakelaar (bruikbaar bij bijv. master – slave zoals eerder geschetst). De ene keer schakelt hij naar de ene situatie om de gevraagde functionaliteit te leveren, de andere keer naar de andere situatie. Of ze kunnen fungeren als een soort “hoofdaannemer” component die, om zijn functionaliteit te kunnen leveren, allerlei andere functionaliteit aanvraagt. In wezen gebeurt er in die ” hoofdaannemer” component niet zo heel veel. Vooral een stukje co?rdinatie, de rest gebeurt in de andere componenten die zich aanbieden. Die op zichzelf ook weer proxy componenten kunnen zijn. Zo componeer je een hele applicatie, waarbij het “echte werk” zo “laat mogelijk” en dichtbij de technologie gebeurt. Heel krachtig, snel en effici?nt. Immers hoe dichter op de hardware / technologie hoe sneller programma’s lopen.
Let hierbij nog even goed op: componenten roepen niet andere componenten op! Dit zou immers betekenen dat ze van hun bestaan zouden moeten afweten. Nee, ze vragen om functionaliteit (functionele interface) en krijgen die aangeboden. Het is dus meer dan een semantisch trucje. Daarbij: code kun je naar mijn idee niet ergens onder scharen: functionaliteit of architectuur of techniek. Met de code bouw je zowel de techniek (OS, communicatie, database etc.), als de pure functionaliteit. Vergelijkbaar met steen, hout, metaal, enz. Die zijn zo fundamenteel, zonder dat bouw je niks. Het hoort overal of nergens bij.
* Het stukje “attribuut kwaliteit”: uiteraard veranderen hier de componenten. Alleen moet je heel goed opletten (maar eigenlijk gaat dat “vanzelf”, zoals je gewaar zult worden in deze alinea). Je weet immers niet welke componenten nog meer van de bestel en leverancier componenten gebruik maken! Dat is juist de kracht van het systeem! Je hoeft je niet druk te maken over (verborgen) relaties, je houdt je alleen bezig met die relaties die voor jou van belang zijn (tussen de bestel en de leverancier component in dit geval). Maar dat doe je op dusdanige wijze dat andere componenten, die om de bestel of leverancier functionaliteit vragen, het niet merken. Anders krijg je te maken met verborgen relaties (je weet immers niet welke componenten hier nog meer gebruik van maken), en dat is nou juist de pest van veel software: die verborgen relaties! Dus je doet het volgende: je behoudt de oude interface (zonder het nieuwe “attribuut kwaliteit”). Daarnaast maak je op dezelfde component een nieuwe interface die identiek is aan de oude, maar dan wel met het nieuwe “attribuut kwaliteit”. De code van het component pas je aan zodat hij ook het nieuwe “attribuut kwaliteit” kan verwerken, naast het oude. Dit werkt zo door in alle componenten die voor jou proces van belang zijn. Zolang componenten (inclusief “jou” bestelcomponent) vragen om een leverancierscomponent die de oude set gegevens kan leveren, antwoord de leveranciercomponent met de oude interface. Op het moment dat “jou” bestelcomponent vraagt: wie kan mij artikel gegevens leveren (met het nieuwe “attribuut kwaliteit”), antwoord de leveranciercomponent met de nieuwe interface. Jou nieuwe situatie werkt naar behoren, maar ook alle andere situatie waar jij geen weet van hebt en ook niet van hoeft te hebben!
Heerlijk toch, voor zowel projectmanagers, architecten, programmeurs, testers als “outsourcers”? Je kunt je concentreren op dat stukje functionaliteit ge?mplementeerd in een componenten set, wat voor jou van belang is (projectmanagers, architecten en testers) of dat component dat jij onderhanden moet nemen (programmeur). De rest is volstrekt niet van belang en werkt als voorheen. Geen afstemmingsoverleg anders dan over de onderhavige functionaliteit, geen uren bestuderen van de documentatie en / of broncode van hoe het ook alweer in elkaar zat (ik heb me laten vertellen dat daar soms wel meer dan de helft van de tijd in gaat zitten). Zeker een probleem als de oorspronkelijke programmeurs niet meer beschikbaar zijn.
* Het stukje “implementatie”: je kunt nu bovenstaande extrapoleren. Uiteraard werkt dit alleen als een applicatie is opgebouwd als beschreven (optimaal flexibel)! Je hebt de oude bestel component in geheugen. Je doet de nieuwe bestelcomponent ook in geheugen (en alle andere bijbehorende ivm. de “attribuut” wijziging). De bestel component staat aan de top van die keten. Op het moment dat iemand om bestel functionaliteit vraagt, zet je er een proxy bestel component tussen, of die “vrager” fungeert zelf al als proxy. Nu heb je een switch, die kan schakelen tussen de oude en de nieuwe situatie. Elke keer als een instantie “los” laat van de “oude” component, laat je bij een nieuwe vraag alleen de nieuwe situatie reageren. Samen met de boven beschreven coercion kun je zo een smooth migration organiseren, zonder dat het systeem plat moet. Dit is natuurlijk een ideale situatie. In de praktijk kan het wel eens voorkomen dat bepaalde instanties te lang duren, waardoor zaken uit sync. kunnen raken die je ook met de boven beschreven coercion niet meer kunt oplossen / overbruggen. Het systeem is zich bewust van die instanties en je kunt daar op ingrijpen. Je kunt de gebruiker bijv. (eventueel van te voren) een bericht sturen dat hij voor een bepaalde tijd even uit die bepaalde functionaliteit moet om een upgrade te kunnen doen. Hij hoeft niet uit de hele applicatie, maar alleen uit een stukje. Of je doet een geforceerde upgrade op die instantie die te lang duurt. Er zijn situaties waarin de software hotswap toch wat kost (voor niets gaat de zon op). Maar je kunt de implementatie en upgrade impact zo enorm terug brengen.
En nog een interessante feature: onderhoud op functionaliteit, niet op code (ook bij legacy). Stel: in de loop der tijd is je IT systeem gegroeid. Stukken zijn 20 jaar oud, stukken zijn nieuwer. Van alle componenten is bekend wat er van verwacht wordt (functionele interface, zou ik altijd goed beschrijven). Hoe die functionaliteit uiteindelijk in code tot uitdrukking is gekomen is niet van belang (wel handig, want dan kun je sneller aanpassen als je mensen in huis hebt die de gebruikte programmeertaal beheersen). Sterker nog, je hoeft niet eens over de broncode te beschikken (wederom wel handig, want ?). Stel dat je op een bepaalt moment besluit dat een component moet worden aangepast of je ontdekt een fout die moet worden opgelost en je verkeert in 1 of meer van de volgende omstandigheden:
– je beschikt niet (meer) over de broncode, je hebt alleen een runt-time / gecompileerde versie o.i.d.,
– je beschikt wel over de broncode, maar die is (te) slecht gedocumenteerd, of je mag er niet aanzitten (intellectueel eigendom),
– je beschikt wel over de broncode, maar niet (tijdig) over de programmeurs die de programmeertaal (voldoende) beheersen of die zijn (te) duur, of de programmeertaal is “domweg” te oud en niet meer in gebruik.
Omdat je wel beschikt over de beschrijving over wat die component moet doen (functioneel), bouw je die component “gewoon” opnieuw in de programmeertaal die jou het beste schikt op dat moment. En dat kost niet zoveel (tijd, geld). Want als je je applicatie een beetje slim hebt opgebouwd, bevatten componenten niet al teveel code (koste je immers weer flexibiliteit). Heb je toch “toevallig” componenten die bestaan uit bijv. honderduizend(en) regels code, kun je die altijd nog opdelen in kleinere componenten. Maar dan moet je nog wel enigszins begrijpen wat er in de code gebeurt, om dat component zinvol op te kunnen delen. Dat opdelen gebeurt dan overigens zonder dat je een stukje code hoeft aan te passen! Dus je moet begrijpen wat er in de code gebeurt, je hoeft niet in die programmeertaal te kunnen programmeren. Dit allemaal is heel handig als je je legacy applicaties wilt moderniseren en die zijn niet (goed) gedocumenteerd of je beschikt niet meer over programmeurs die de gebruikte taal beheersen. Of je IT systeem zit vol met (ongedocumenteerde) interfaces en verborgen relaties. Je kunt je systeem zo ontwarren zonder dat je systeem als mikado in elkaar stort als je ergens aanzit.
P.S. ik had gedacht deze bijdrage kort te houden, maar het lijkt wel of ze steeds langer worden 😉
P.S. 2 op Johan reageer ik graag op een ander moment.
Jacco Hiemstra
http://www.produrion.nl
@Jacco
#
Definitie functionaliteit
Ik heb mijn standpunt over de scheiding tussen functionaliteit en implementatie toch wat scherper bijgesteld. Ik definieer functionaliteit als iets wat de gebruiker ervaart, een set diensten die geleverd wordt door de IT-architectuur die dan weer bestaat uit een hardware laag en diverse software lagen.
In die zin betekent een verandering in de IT-architectuur, hoe miniem ook, ook ALTIJD een verandering in de functionaliteit. Of de gebruiker iets van die verandering in functionaliteit ervaart, is eigenlijk irrelevant. Het zou hier bijvoorbeeld kunnen gaan om een verbeterd encryptie-algoritme, dat de gebruiker niet zelf ervaart, maar wel een verandering in functionaliteit betekent.
Met betrekking tot die verandering in functionaliteit, is het ook niet relevant dat de softwarecomponenten hoog in de aanroep-hierarchie (bijvoorbeeld de “bestelcomponent”) iets van die verandering merkt, in de zin dat ze wel of niet moeten worden aangepast. Het gaat hier om het geheel, de som van de hard en software componenten waaruit de IT architectuur bestaat. Het is het geheel dat de functionaliteit levert aan de gebruikers.
Funcionaliteit en de implementatie ervan zijn niet los te koppelen van elkaar, net zoals de betekenis van een
boek ervaren wordt door een lezer. Dat boek bestaat uit een organisatie van hoofdstukken die elk weer bestaan uit alinea’s, zinnen, woorden en letters. Naarmate je je op een lager niveau afdaalt, verlies je het verband met de betekenis voor de lezer.
# Objectorientatie is slechts een methode om software te organiseren
De manier waarop je software organiseert, procedureel of objectgeorienteerd, heeft alleen invloed op de hoeveelheid werk die zo’n verandering met zich meebrengt. Het is waar, een objectgeorienteerde organisatie van software is wat efficienter te onderhouden dan een procedurele brei spaghetticode.
Maar ook objectorientatie kent zijn nadelen. In een SAP systeem met zijn vele duizenden classes, interfaces en methoden is het vaak flink zoeken naar de component die verantwoordelijk is voor een bepaald stukje functionaliteit. In zulke gevallen wordt vaak het wiel uitgevonden en ontstaan er vrijwel identieke componenten omdat de programmeur niet beseft dat er al iets bestaat dat hij kan (her)gebruiken.
Verder zijn er andere wijzigingen denkbaar, bijvoorbeeld in het onderliggende datamodel, die een grote invloed kunnen hebben op vele componenenten, bijvoorbeeld de lengte van een veld dat een bedrag geld moet opslaan kan invloed hebben op alle componenten die ermee rekenkundige bewerkingen plegen.
# Verdere optimalisatie van software
Kijk eens naar het MVC (Model View Controller) concept dat weer een andere manier heeft om software te organiseren. Wikipedia heeft er een duidelijk uitleg van. Ook SAP kent dit concept en streeft ernaar om de procedurele broncode te vervangen door object-georienteerde (webdynpro)componenten die het MVC cocept implementeren ( google: “SAp MVC” ). In het MVC concept is het ontwerp van complexe toepassingen opgedeelt in drie eenheden met verschillende verantwoordelijkheden: datamodel (model), datapresentatie (view) en applicatielogica (controller). Het scheiden van deze verantwoordelijkheden bevordert de leesbaarheid en herbruikbaarheid van code.
Het is dus niet de scheiding van functionaliteit en IT-architectuur die je als programmeur kan nastreven
, want dat zijn 2 fundamenteel verschillende zaken. (zie mijn “definitie” hierboven). Je applicatie is direct verantwoordelijk voor die functionaliteit en je kan er hooguit voor zorgen dat die applicatie ten aanzien van het noodzakelijke onderhoud zo efficient mogelijk is georganiseerd, door bijvoorbeeld het MVC concept te hanteren.
# Implementatie van veranderingen
Het “injecteren” van software veranderingen in een draaiend systeem is in principe mogelijk. In een SAP systeem kan je gewoon software transporten “inspelen” terwijl de gebruikers actief zijn. In een druk systeem zijn er dan vaak dumps waar te nemen die worden veroorzaakt omdat software op schijf verschilt van de runtime versies ervan. Je zou er ook voor kunnen kiezen om die software op een rustiger tijdstip te kunnen vervangen.
Het gebruik maken van een shadow database in het geval van conversies of upgrades is een techniek die in de SAP wereld al een tijdje voorkomt. In feite maak je hierbij gebruik van redundantie, net als het geval is bij een reloceerbare service, een cluster etc., om het gebruikersongemak te beperken.
Redundantie heeft echter zijn prijs. Een verbouwing in een huis zal ook met het nodige ongemak gepaart gaan. Een tijdelijk onderkomen kan daarbij uitkomst bieden, maar kost ook het een en ander.
Verder kent het faciliteren van oudere versies van componenten zijn grens. Als de nieuwere componenten aanroepen van oudere interfaces moeten blijven aankunnen, dan wordt de software trager en ook duurder om te onderhouden. op een gegeven moment zal je de band met het verleden moeten doorknippen. Ook jij zal die grens ergens moeten trekken.
# functionaliteit van software en huis vergelijken
Wanneer je de functionaliteit van software en die van een huis vergelijkt zul je zien dat de functionaliteit van een huis weining varieert in de tijd, ja zelfs in het geheel niet veranderd.
Software daarentegen
moet continu veranderen om tegemoet te komen aan de eisen van de (zakelijke) context waarin zij wordt gebruikt.
Het zijn juist die continue veranderlijke eisen ten aanzien van de functionaliteit die tot veranderingen in de software leiden en niet andersom, zoals jij dit toch een beetje doet voorkomen. Je kunt die veranderlijke eisen een beetje vergelijken met een krankzinnig stedebouwkundig beleid dat bijvoorbeeld bepaald dat huizen iedere week een andere kleur moeten hebben.
@Johan
Je schets van “een netwerk van samenwerkende cellen/processen, waarbij modellen in expliciete vorm niet meer terug te vinden zijn”, herkende ik ook en voelde er mij ook niet gemakkelijk bij. In een SAP applicatie is elke gebuikersactie transactiegeorienteerd. Voor elke transactie bestaat een vaste volgorde van schermen, als het ware een dialoog die het systeem aangaat met de gebruiker.
Ouderwets wellicht, maar het zorgt wel voor een bepaalde structuur en indeling van de software, waarin een nieuwe programmeur rdelijk gemakkelijk zijn weg kan vinden. Omdat ik wel eens programmeer in een SAP systeem, vind ik persoonlijk dat programma’s die objectgeorienteerd zijn, lastiger te debuggen als procedureel geschreven code, maar dat zal wel aan mijzelf liggen !
Dit artikel beschrijft op hoofdlijnen de verantwoordelijkheden van de verschillende partijen bij een SAP implementatie. De klant realiseert zich onvoldoende wat de impact van een ERP implementatie op zijn organisatie is en laat zich lastig ‘managen’ door implementatiepartner en SAP. Ook is er aandacht voor de rol die de implementatiepartner zou moeten hebben om mislukkingen te voorkomen. ‘Hij moet onhaalbare voorstellen van klanten durven te weigeren en het financi?le belang dat hij heeft buitenspel kunnen zetten.’ De directeur van SAP Nederland en de drie Computable-experts zijn het er op grote lijnen over eens dat de verantwoordelijkheid voor een geslaagde SAP implementatie bij zowel de implementatiepartner als de klant ligt. En natuurlijk is dat zo!
Wat ik mis in het artikel is een verdere uitwerking van de terloops genoemde ‘onafhankelijke derde partij’. Is een andere ‘waarheid’ immers niet dat de waarde van een ‘Quality Insurance’ valt of staat bij objectiviteit, onafhankelijkheid en feiten? Daarom is het opmerkelijk dat deze toezichthoudende rol in een SAP omgeving vaak ofwel door SAP ofwel door de implementatiepartner wordt uitgevoerd. De klant doet er echter goed aan om voor de ‘Quality Insurance’ de eerder genoemde ‘onafhankelijke derde partij’ in de arm te nemen. Een partij die noch SAP licenties noch SAP consultants verkoopt. Een partij die maar ??n doel heeft: op objectieve gestructureerde en feitelijke wijze toezicht houden op de kwaliteit van de onderhavige SAP implementatie. Niet meer en niet minder. Deze peilstok lijkt mij voor de klant uiteindelijk zinvoller dan die van SAP of zijn implementatiepartner.
Marischa van Zantvoort
@Marischa Een onafhankelijke kwaliteitscontrole door een derde partij biedt geen meerwaarde want :
– wie garandeert de kwaliteit van de kwaliteitscontrole?
– de controlerende partij moet de beschikking hebben over SAP-consultants. Wie zou de controle anders moeten uitvoeren?
– SAP voert al een goede controle uit door de zogeheten GoLive-sessies. Ook kan een Early Watch-sessie worden aangevraagd.