Partnerselectie

Logistiek.nl publiceert Software jaarboek 2011

| 25-02-2011

De redactie van Logistiek heeft deze week zijn jaarlijkse bijlage over logistieke software uitgebracht. De bijlage is als E-zine te bekijken op Logistiek.nl maar is ook downloadbaar als PDF.

Keuze voor benutten strategische voordelen zorgt voor gestage adoptie open source software

| 09-02-2011

Uit een onderzoek van Gartner in 11 landen met ruim 500 respondenten waarover Automatiseringgids vandaag bericht blijkt dat open source software (OSS) een steeds belangrijkere rol krijgt in de IT-strategie van bedrijven. De adoptie van OSS neemt hierdoor gestaag toe. De opvallende conclusie van dit onderzoek is dat er steeds meer wordt gekozen voor open source vanwege het kunnen benutten van strategische voordelen. Het gaat bij deze strategische voordelen om kortere ontwikkeltijden, innovatieve oplossingen, beter in staat zijn om intern te ontwikkelen, en last but not least:  de mate waarin IT-verantwoordelijken aangeven dat ze zakelijk succesvoller kunnen zijn met OSS. Waarom zet de adoptie gestaag door, en wat is de wijze waarop OSS naast proprietary software kan worden meegenomen in softwareselectietrajecten?

Overname Compiere: verdere ontwikkeling open source business model of stekker uit project?

| 23-06-2010

Nadat vorige week bekend werd dat Consona Compiere, een van de bekendste open source ERP pakketten overnam, zijn er her en der verhalen opgedoken in blogs over wat er nu gaat gebeuren met dit open source product. De vraag is of deze overname een verdere ontwikkeling en professionalisering van een open source ERP project inhoudt, of dat het juist een stap verder is in de aftakeling van het ‘open source gehalte’ en de tanende populariteit van het softwarepakket.

Hoe implementeer ik succesvol een standaardpakket?

| 23-06-2010

Dit was de titel van de presentatie die Onno Wasser (voorzitter VKL, adviseur Mitopics) en de auteur van deze blogpost hebben gehouden op het KOG beurs 2010.

Het thema van deze vakbeurs was “Sterker met ERP”. In de presentatie “Hoe implementeer ik succesvol eenstandaardpakket? – Van klein tot groot, voor groot en klein!” gingen de sprekers in op hoe standaardpakketten middels een bewezen en resultaatgerichte methodiek succesvol geïmplementeerd kunnen worden.

Na de behandeling hoe een standaardpakket succesvol geimplementeerd kan worden, is ingegaan hoe deze methodiek succesvol heeft gewerkt in vier praktijkcases van diverse organisaties met verschillende ambities en organisatiesituaties. Dit is ondersteund door in te zoomen op specifieke bedrijfskenmerken en de vier cases te vergelijken op basis van kengetallen.

U kunt de presentatie hier downloaden.

Wederopstanding maatwerk op komst door gebruik van open source componenten?

| 18-03-2009

Toevallig zag ik dit bericht waarin van een succesvol project een beschrijving wordt gegeven door softwareontwikkelaar Finalist. Deze leverancier heeft voor Mosadex (farmaceutische groothandel, niet de eerste de beste lijkt het, namelijk de nummer drie van Nederland volgens eigen zeggen) een maatwerk CRM-systeem gerealiseerd. De exacte reden waarom Mosadex deze keuze precies heeft gemaakt is niet bekend. Heeft bijvoorbeeld het beleidsuitgangspunt de doorslag gegeven, of misschien de functionaliteit of het kostenaspect?

Mislukte automatiseringen: wie treft blaam?

| 12-03-2009

Onlangs kopte Computable “Directeur SAP wijt mislukkingen aan klanten”. Dit is natuurlijk een stevige kop, maar het artikel zelf nuanceert nauwelijks. Dit soort geluiden zijn niet helemaal nieuw, in 2007 haalde Ordina de pers met een onderzoek waaruit zou moeten blijken dat ICT-projecten vaak door de eigen schuld van klanten falen.

En het moet gezegd worden, de, helaas toenemende, hoeveelheid geschillen waar onze hulp bij gevraagd worden zijn zelden dusdanig klip en klaar dat de schuldvraag geheel bij de leverancier gelegd kan worden. De wijze waarop het opdrachtgeverschap wordt ingevuld door afnemers vertoont vaak de nodige ruimte voor verbetering.

Het voorgaande neemt evenwel niet weg dat in het merendeel van de gevallen de leverancier bepaald niet vlekkeloos heeft geopereerd. Met betrekking tot de onkunde van afnemers moet opgemerkt worden dat als ze verstand van automatiseren zouden hebben, ze de leverancier niet nodig zouden hebben voor de implementatie van de pakketsoftware. Op de leverancier rust dan ook een zware verantwoordelijkheid in dit opzicht, hij weet vele malen beter wat de invloed van wispelturigheid van afnemerszijde op de doorlooptijden en budgetten van projecten kunnen zijn.

Want SAP heeft op zich wel een punt, veel afnemers realiseren zich onvoldoende dat grote veranderingen in de automatisering veelal grote veranderingen in de bedrijfsprocessen met zich meebrengen. Onwetendheid met betrekking tot de noodzaak om tot dergelijke veranderingen over te gaan brengt vaak veel maatwerk met zich mee en dit maakt het project kostbaar en levert vertraging op voor het project. Leveranciers hebben hier een zware verantwoordelijkheid en kunnen deze nemen door enerzijds eerlijker te communiceren over de impact op de organisatie van afnemers en de flexibiliteit van hun pakketsoftware te vergroten. Anderzijds kunnen leveranciers dit doen door een kritische tegenspeler te zijn bij verzoeken van afnemerszijde tot maatwerkaanpassingen. In het voordeel van de SAP-implementatiepartijen moet worden opgemerkt dat zij zeker niet minder dan gemiddeld deze rol op zich nemen, maar de vraag is of dit voldoende is.

Helaas zijn er voorbeelden te over van projecten waarin ieder wijzigingsverzoek vanaf de werkvloer klakkeloos werd uitgevoerd en in rekening werd gebracht. Met als resultaat een onwerkbare brij die ook nog eens te veel had gekost en dermate lang in ontwikkeling was geweest dat de oorspronkelijke business case allang niet meer aan de orde was. Of erger nog, dat de marktontwikkelingen de oorspronkelijke vraag achterhaald hadden.

Het is dan ook teleurstellend als leveranciers weglopen voor deze verantwoordelijkheid en dat ook nog eens op brancheniveau institutionaliseren in de ICT~Office voorwaarden. Het is ons in de praktijk meerdere malen aan de onderhandelingstafel overkomen dat een leverancier vertelde dat hij niet aan de planning gehouden wenste te worden omdat zijn ervaring met deze afnemer was dat die zich evenmin aan de planning hield. Een aanbod om dan soortgelijke eisen aan de organisatie van afnemer in het contract op te nemen om zo het gevraagde evenwicht te bereiken werd evenwel afgeslagen. Want eigenlijk vindt men het, te vaak, wel best zo. De afnemer doet zijn huiswerk niet, dan hoeven wij het ook niet te doen. En aangezien er nog steeds veelal op basis van nacalculatie wordt gewerkt, is het eigenlijk een wonder dat slechts zes van de tien automatiseringsprojecten in meerdere of mindere mate mislukken.

Implementatiebegeleiding van partijen is dan ook vaak broodnodig. Het is dan ook een verademing om die enkele leverancier te treffen die een dusdanige vaktrots en ambitie heeft dat het wel vanzelfsprekend is om controlemechanismen af te spreken om doorlooptijden en budgetten in de hand te kunnen houden. Het zou de Nederlandse automatiseringssector sieren als het voorbeeld van deze witte raven overgenomen zou worden. In dat opzicht zijn we dan ook benieuwd hoe het door SAP aangekondigde “quality assurance” programma in de praktijk gaat uitpakken.

Wanneer is open source software volwassen?

| 27-01-2009

Het label ‘volwassen’ wordt regelmatig gebruikt om aan te geven dat een softwarepakket gezien de stand van zaken qua functionaliteit bruikbaar is. De vragen die natuurlijk meteen rijzen zijn: wat is nu de definitie is van volwassen software is en in welke mate wegen de eisen van de doelomgeving mee in deze volwassenheidsaanduiding? Daar zijn inmiddels vele verschillende manieren voor ontwikkeld. Ook voor Open Source Software (OSS).

Als het gaat om het hele proces of de aanpak voor succesvol gebruik van OSS voor bedrijfskritieke processen is de relevantie van volwassen software natuurlijk duidelijk aanwezig. Vaak wordt de term ‘enterprise-ready OSS’ als label gebruikt als mensen of organisaties vinden dat een bepaald OSS-project geschikt is voor gebruik in het bedrijfsleven.

In zekere mate zijn er overeenkomsten te vinden in closed source software (CSS) pakketselecties  waarin pakketten worden beoordeeld op Kritieke Software Functies (KSF’s) en naar de geschiktheid van een leverancier wordt gekeken. Bij OSS komt daarnaast ook de volwassenheid van de community kijken. Dit is vaak een vorm van een zelfsturende, open, innovatieve omgeving waarin vrijwilligers (en soms bedrijven) bijdragen aan het ontwikkelen, testen, gebruiken en promoten van de software (of in OSS: het project).

Eén van de risico’s die we vaak zien bij OSS is de continuïteit van de ontwikkeling van een OSS traject en daarom wordt in bepaalde maturity (volwassenheid) modellen juist op dat aspect gefocust. Vorig jaar heb ik mijn BSc thesis onderzoek gedaan naar de verschillende OSS beoordelingsmethodieken. Toentertijd waren er al veel verschillende methodieken te vinden, even zoeken op Google levert nu al weer nieuwe bijdragen op. Eén van de meest opvallende dingen aan deze OSS beoordelingsmethodieken is dat ze vaak in te delen zijn als een whitepaper met enkele aandachtspunten bij het selecteren van OSS. Daarmee bieden ze vaak geen praktische handvatten voor het beoordelen van OSS. 

De OSS methodieken die dat wel doen verschillen qua invalshoek in hun beoordeling van de volwassenheid van software. De één focust meer op betrouwbaarheid, de andere meer op functionaliteit en de andere weer op de grootte en organisatie van de community.  Dieper ingaan op de verschillen tussen deze OSS methodieken en de verschillen tussen OSS en CSS methodieken zou een herkauwing van conclusies zijn uit mijn BSc-thesis. Voor meer informatie en onderbouwing verwijs ik naar dat stuk.

Veel interessanter is de discussie of één van deze modellen goed geschikt zou zijn voor het bepalen van deze volwassenheid en of de uitkomsten van de toepassing van zo’n methodiek ook stroken met de daadwerkelijke ‘volwassenheid’ in de praktijk. Ondanks de ontwikkeling van al die OSS methodieken, sommigen zelfs met subsidie van de EU, is op punt van validatie van de uitkomsten met de werkelijkheid nog geen onderzoek geweest.

Iniatieven die verder onderzoek naar een optimalisatie en validatie van deze OSS methodieken bevorderen zijn dan ook een stap in de goede richting voor het kunnen bepalen of een OSS ‘pakket’ ook echt ‘enterprise-ready’ is. En daar ga ik dit jaar mee bezig!

Regelt IT. Al > 20 jaar!

Stavorenweg 4
Postbus 514
2800 AM Gouda
T 0182 573 211
E info@mitopics.nl

RSS feed
Sitemap
Disclaimer
Cookies

Uitgelichte topics