Principes en Lessons Learned

Artikelen t.a.v. de ontwikkeling en inzet van software, ook van bedrijfssoftware, zijn meestal nogal technisch georiënteerd (en lang). Als tegenwicht tegen deze overvloed volgt hieronder een meer toepassingsgericht artikel; de meeste principes die hierin worden genoemd zijn feitelijk “lessons learned” die zich in de praktijk al hebben bewezen.

  1. De bedrijfsvoering is leidend, software is immers een bedrijfsmiddel. Beoordeel technologie daarom eerst en vooral vanuit het perspectief van het bedrijf. Dit is ook de beste insteek om investeerders te overtuigen. Zij hebben immers gekozen voor het bedrijf (en niet voor de software).
  2. Maak niet alleen de meerwaarde voor het bedrijf duidelijk maar ook de gevolgen die de inzet van software heeft voor de betrokken medewerkers. Hierbij kan gedacht worden aan gevolgen voor taken, verantwoordelijkheden, bevoegdheden, werkomstandigheden (technisch, sociaal), opleiding en training en, last but not least, beloning en loopbaanperspectief.
  3. Software is een bedrijfsmiddel maar zorg ook voor voldoende draagvlak. Dit hoeft elkaar niet te bijten. Behandel software-gerelateerde zaken als onderdeel van het reguliere overleg. Dit geeft niet alleen de nodige bedrijfsfocus en -context maar voorkomt ook misalignment / techtalk. Dit kan bijvoorbeeld door het op de agenda te zetten. Het handigst is het als degenen die verantwoordelijk zijn voor de software ook aan tafel zitten. Eventuele software gerelateerde zaken kunnen dan nl. meteen worden afgehandeld.
  4. Overleg ook regelmatig met externe ketenpartners (bijvoorbeeld leveranciers) en gebruik zoveel mogelijk dezelfde standaarden. Vergeet ook de klanten niet en de eigen medewerkers (BYOD).
  5. Geef alle medewerkers een stem. Ook al kun je niet alle wensen honoreren, c.q. alle bezwaren wegnemen, de mogelijkheid om deze te bespreken c.q. te prioriteren (MoSCoW) kan medewerking faciliteren dan wel weerstanden wegnemen.
  6. Weten wat er al in huis is, is niet alleen belangrijk om de uitgangspositie te bepalen maar ook om er achter te komen wat er met de reeds beschikbare middelen eventueel aan meerwaarde kan worden gerealiseerd. Misschien volstaat een reorganisatie. Kortom: weet wat er al is.
  7. Zet meerdere alternatieven (die zijn er altijd) naast elkaar, inclusief de zgn. nul optie, d.w.z. niets doen (alle waarde is immers relatief / is meerwaarde).
  8. Een ander goed uitgangspunt is niets te ontwikkelen dat er al is. Er is al heel veel (maar je moet w l weten wat er te koop is). Verder: kopen (en een beetje aanpassen) is meestal goedkoper dan ontwikkelen. Als je koopt, gebruik dan alleen bewezen technologie (geen kinderziektes) en wees geen early adopter (een bedrijf is geen proeftuin).
  9. Als er toch wordt gekozen voor ontwikkelen doe dit dan stapsgewijs (incrementeel ontwikkelen). Zorg eerst voor een werkende basisfunctionaliteit (de “happy flow”) en bouw deze uit (de “exceptions”). Plan in ieder geval haalbare stappen. Door kleinere stappen te zetten kan hun effect nl. beter worden bijgehouden, en kunnen veranderingen die negatieve gevolgen hebben, worden bijgestuurd of teruggedraaid. Zorg wel dat er voldoende expertise en capaciteit is (intern dan wel extern) om eventuele tegenvallers op te vangen c.q. meevallers te benutten.
  10. Plan voldoende evaluatiemomenten in. Evaluaties zijn niet alleen een manier om goede ideeën op te doen (soms is er ook sprake van voortschrijdend inzicht), en te versnellen, maar kunnen ook mogelijkheden bieden om met weerstand om te gaan.
  11. Hanteer een levensduurbenadering. Dus niet blind staren op de aanschafkosten maar ook kijken naar de kosten van beheer en onderhoud, upgrades e.d. Deze kosten zijn vaak een veelvoud van de initiële kosten.
  12. Voer een risicoanalyse uit. Het gebruik van software kan leiden tot meer afhankelijkheden. Het is ook geen overbodige luxe eventuele kwetsbaarheden vooraf in kaart te brengen; bijvoorbeeld door het laten uitvoeren van een zgn. penetratie-test (pen-test). Geen enkele beveiliging is waterdicht en het kan helpen van tevoren te bedenken hoe om te gaan met lekken. Het is ook verstandig dergelijke tests regelmatig uit te voeren (ontwikkelingen staan immers niet stil). Tenslotte: alles kan uitvallen; een back-up is essentieel.

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *