Generieke software of maatwerk?

Kies je ervoor om een maatwerkapplicatie te maken dan heb je daarvoor wellicht een van de volgende redenen:

  • De beschikbare generieke applicaties zijn niet geschikt voor het beoogde doel.
  • Je wilt zelf controle houden over de innovatie en de gebruikservaring.
  • Het maken van een maatwerkapplicatie is een investering in een onderscheidende marktpropositie.
  • De kosten voor het aanpassen van een bestaande applicatie zijn hoger dan die voor maatwerk.
  • De totalcost of ownership van een eigen applicatie zijn op termijn lager dan de licentiekosten en configuratiekosten van een generieke applicatie.
  • Je wilt voorkomen dat je afhankelijkheid wordt van een derde partij, je wilt geen vendorlock-in

De keuze voor het maken en exploiteren van een maatwerk applicatie is een strategische keuze. Niet alleen vanwege de impact op de bedrijfsvoering maar ook vanwege de hoge investeringskosten. Wat in jouw geval de beste keuze is hangt af van jouw specifieke situatie.

Zelf doen of uitbesteden?

Als het besluit eenmaal is genomen om in eigen beheer een applicatie te ontwikkelen is de vraag wat verstandiger is, zelf doen of uitbesteden. Omdat voor veel bedrijven Software Development geen core-business is wordt al snel gekozen voor uitbesteden. Een belangrijke valkuil bij uitbesteden is dat wordt gefocused op de kosten voor het realiseren van de applicatie, terwijl de costs of ownership worden onderschat. En vanzelfsprekend is het niet direct in het belang van de gespecialiseerde aannemer om de klant daarop te wijzen.

In onze praktijk rekenen wij standaard meteen jaarlijkse reservering van tenminste 15% van de initiële bouwkosten voor applicatiebeheer en doorontwikkeling. Enkel indien de applicatie niet gebruikt wordt is het aannemelijk dat er geen beheerkosten zijn. In alle andere gevallen zal het gebruik van de applicatie leiden tot nieuwe inzichten en behoeften. Als de applicatie zijn nu in de praktijk bewijst zal er ook een bereidheid zijn om deze kosten te maken. Is de applicatie een groot succes dan is het ook aannemelijk dat de kosten van doorontwikkeling hoger zullen liggen dan de genoemde 15%.

Een andere vraag bij uitbesteden is op welke wijze dat gebeurd. Wordt er gekozen voor een ‘fixedprice’ en ‘turn-key’ oplossing aan de hand van nauwkeurige specificaties, of gaan klant en aannemer gezamenlijk het proces in en wordt het project ‘Agile’ uitgevoerd. Er zijn ook nog hybride vormen waarbij Agile wordt gewerkt en toch binnen een vast omlijnd budget, maar deze laten we even buiten beschouwing.

Projectrisico’s

De gekozen projectmethodiek is mede afhankelijk van de perceptie van risico’s. We zetten de belangrijkste risico’s hier op een rij:

  • De technici maken een verkeerde inschatting, in het werk blijkt iets moeilijker te zijn of meer tijd te kosten.
  • De klant en technici hebben elkaar niet goed begrepen. Wat opgeleverd wordt komt niet overeen met de verwachtingen.
  • Gedurende het bouwproces ontstaan er nieuwe inzichten waardoor hetgeen wordt opgeleverd niet meer overeenkomt met wat er nodig is. Het product voldoet daardoor alsnog niet aan de verwachtingen.

Bij een fixedprice project is het eerste risico volledig voor rekening van de aannemer, tenzij de oorzaak ligt buiten de scope van het project. Over het tweede risico zullen verschillen van mening ontstaan en het derde risico komt volledig voor rekening van de opdrachtgever. Bij een Agile project komen alle risico’s in beginsel voor rekening van de opdrachtgever. Daar staat tegenover dat er bij een Agile project gedurende de implementatie kan worden bijgestuurd. Dat kan dat veel moeilijker bij een fixedprice project. Daarbij zijn Agile projectmethodieken veel efficiënter, alleen al daarom is het aan te bevelen om Agile te werken, zeker voor grotere projecten met een langere doorlooptijd.

Afhankelijkheden

De conclusie van bovenstaande is dat, ook bij uitbesteden van het project, een groot deel van het risico bij de opdrachtgever blijft. Tegelijk wordt de opdrachtgever afhankelijk van de aannemer omdat bij deze alle kennis wordt opgebouwd die noodzakelijk is in de exploitatiefase van de software. Zodra het project eenmaal is gestart is het al vrijwel onmogelijk om nog van aanbieder te wisselen zonder dat dit leidt tot hoge kosten en vertraging van het project. De IT-specialisten die de kennis dragers zijn van de applicatie zijn ineens belangrijke assets geworden. Wie de controle heeft over deze assets is een zeer relevante vraag. Zeker als na de oplevering van de applicatie blijkt dat er een groter dan verwachte behoefte is aan capaciteit voor doorontwikkeling. Zeker als de software van strategische waarde is voor de onderneming is het dus van groot belang om zelf de controle te hebben en te houden.

Een eigen software team

In plaats van het project als geheel uit te besteden, kan er ook voor worden gekozen om gedeelten van het project uit te besteden. Het is vergelijkbaar met de bouw van een kantoorpand. In plaats van het uit te besteden aan een projectontwikkelaar, huur je separaat een architect, een bouwmanager en een bouwteam in. Als we dit vertalen naar een software project wordt eerst een productowner aangesteld.

De productowneris bij voorkeur iemand die al langer in het bedrijf aanwezig is, die veel kennis heeft van de toepassingen en klanten waarvoor de app wordt ingezet en die toegang heeft tot het business management. Denk bijvoorbeeld aan een productmanager of iemand die vanuit zijn werk veel interne en klantcontacten heeft. Het is wel essentieel dat deze persoon voldoende wordt vrijgemaakt om de rol van productowner te kunnen uitvoeren. Nadat de applicatie klaar is kan het beheer door iemand anders worden overgenomen waarna de productowner terug gaat naar zijn oude functie. Is zo iemand niet in huis dan is het ook mogelijk om voor de duur van het project een ervaren productowner in te huren.

Een goede analist of architect kan vanuit de eigen organisatie komen of extern worden ingehuurd. De architect is verantwoordelijk voor het technisch ontwerp. Deze zal gedurende het begin van het proces veel tijd moeten besteden en ook nog betrokken blijven tijdens de implementatie. Na de oplevering zal zijn betrokkenheid nog incidenteel nodig zijn.

Ten aanzien van het inhuren van het bouwteam is het belangrijk om een goede inschatting te maken van de capaciteitsbehoefte gedurende het bouwtraject en in de beheerfase. Er kan vervolgens een kernteam worden ingehuurd met aanvullend een flexibele schil die nodig is in bepaalde fasen van de bouw. Een van de teamleden kan vervolgens de rol krijgen van scrummaster.

De productowner, de architect en de scrummaster zorgen samen en in overleg met het team voor een planning en bewaken de voortgang gedurende het project. 

Sourcing

Het samenstellen van een goed team is een belangrijk voorwaarde voor een succesvol project. Om te zorgen dat er een kwalitatief hoogwaardig product wordt gemaakt zijn specialisten nodig die de kennis, het inzicht en de ervaring hebben om dat te kunnen realiseren.

Goede technisch specialisten hebben met elkaar gemeen dat ze een passie hebben voor hun vakgebied, altijd aan het leren zijn en hun vaardigheden steeds proberen te verbeteren. Goede developers lossen problemen op terwijl onbekwame IT’ers problemen creëren.

Goede IT-professionals zijn schaars. Daarom kan de inzet van remote specialisten via outstaffing bedrijven een oplossing bieden. Dat biedt naast lagere kosten ook een grote mate van flexibiliteit. Het werken met een buitenlands team kan echter ook ter koste gaan van de controle, zeker als deze remote specialisten werken voor een externe leverancier. Voor een goed resultaat moet het uitgangspunt de betrokkenheid zijn van de specialisten bij het projectteam en het gezamenlijke bedrijfsdoel. Ook zal er een waarborg moeten zijn die ervoor zorgt dat de controle over de kennisdragers op een goede manier is geborgd.

Wordt aan deze voorwaarden voldaan dan is het zelf ontwikkelen van een maatwerk applicatie een goed alternatief voor uitbesteding.