Drupal leverancier

Drupal Expertise en Ervaring

Hoe groter en complexer het project, des te belangrijker het is dat de leverancier aantoonbare ervaring heeft met Drupal en met onderdelen die specifiek relevant zijn voor jouw project. Let daarbij bijvoorbeeld op de volgende aspecten:

• Het aantal jaren ervaring met Drupal
• Of de leverancier zich volledig richt op Drupal (specialist) of ook met andere CMS systemen werkt (generalist)
• Het aantal gerealiseerde Drupal-projecten, en de mate waarin deze vergelijkbaar zijn met jouw project, bijvoorbeeld qua projectgrootte of complexiteit
• Ervaring met meertaligheid, multiregionale opzet, multisite-architecturen of complexe contentstructuren
• Ervaring met Drupal Commerce, als het gaat om een webshop of e-commerceplatform
• Ervaring met specifieke API-koppelingen, middleware of maatwerk-integraties
• Kennis van moderne (front-end) technologieën, zoals React, Headless-architecturen en Twig
• Ervaring met toegankelijkheid volgens de ATAG/WCAG-richtlijnen
• Ervaring met het migreren van content vanuit verschillende bronsystemen

Team & Drupal capaciteit

Een betrouwbare Drupal leverancier beschikt over een stabiel, deskundig en schaalbaar team dat niet alleen jouw project succesvol kan realiseren, maar ook op lange termijn kan ondersteunen. Maar het draait niet alleen om technische expertise of indrukwekkende referenties, minstens zo belangrijk is de klik tussen jouw organisatie en het bureau, qua omvang, cultuur, aanpak en ambities.

De schaal van het bureau moet passen bij de schaal en complexiteit van jouw project. Een te klein team kan overbelast raken bij een groot technisch traject, terwijl een te groot bureau niet altijd de juiste match is voor een compacter project. Denk daarom goed na over onderstaande vragen bij de selectie:

• Is het team groot of klein genoeg voor jouw projecttype en -omvang?
• Is het bureau fullservice? En zo ja, hoe is de capaciteit verdeeld over disciplines zoals development, UX, content en projectmanagement?
• Is er redundantie in het team? Wat gebeurt er bij ziekte of verloop, en hoe wordt kennis intern geborgd?
• Hoe is de verhouding tussen junior, medior en senior Drupal developers?
• Zijn er ervaren Drupal-architecten of lead developers betrokken bij jouw project?
• Kan het team opschalen indien nodig? Bijvoorbeeld via een flexibele schil met vaste externe partners of Drupal freelancers?
• Is er een apart supportteam aanwezig? Of blijft het originele ontwikkelteam verantwoordelijk voor onderhoud en doorontwikkeling?

Dienstenaanbod, full service of Drupal specialist

Het standaard dienstenaanbod van een Drupal leverancier bestaat uit development, hosting, support, onderhoud en technisch beheer. Afhankelijk van de behoefte kan dit worden aangevuld met diensten zoals digitale strategie, UX- en UI-ontwerp, conversie optimalisatie (CRO), SEO, content creatie, online advertising (zoals Google Ads en social media campagnes) en marketing ondersteuning.

Wanneer een partij een volledig dienstenaanbod levert en opdrachtgevers op alle disciplines wil ontzorgen, spreken we van een fullservice agency. Kies je hiervoor, dan is het belangrijk om de teamgrootte kritisch af te zetten tegen het aantal aangeboden disciplines.

“Van alle markten thuis, maar meester in geen enkele.”

Bij Atom hebben we er bewust voor gekozen om ons volledig te richten op de techniek, daar staan we als Drupal leverancier dan ook om bekend. Voor aanvullende disciplines werken we samen met onze vaste partners of preferred suppliers of het inhouse team van de opdrachtgever.
 

Projectaanpak en werkwijze

Een goede samenwerking vraagt om een aanpak die past bij het project, de opdrachtgever en het team en niet elk project vraagt om dezelfde werkwijze.
 

Dit raakt ook het onderwerp team & capaciteit. Het is belangrijk om bij de leveranciersselectie na te gaan of jouw jaarlijkse bestedingsniveau en de complexiteit van het platform aansluiten bij het klantenbestand en werkwijze van de leverancier.
 

Als een gemiddelde klant van het bureau bijvoorbeeld enkele honderden uren per jaar afneemt en er gewerkt wordt in sprints, dan is een doorontwikkelproject van 8 uur per maand wellicht minder passend. Ook bij een nieuwbouwproject met een aanvankelijk groter budget is het verstandig om direct na te denken over de fase daarna: onderhoud, doorontwikkeling en support.
 

Bij de beoordeling van een leverancier kun je jezelf (of hen) de volgende vragen stellen:

• Werkt het bureau volgens een vaste methodiek? Bijvoorbeeld Scrum, Kanban of een hybride Agile-aanpak.
• Hoe verschilt de werkwijze tussen grotere projecten en doorontwikkeling? Worden deze verschillend ingericht qua team en aanpak?
• Is er een heldere structuur voor communicatie en besluitvorming? Denk aan vaste contactpersonen, geplande overlegmomenten, ticketsystemen of directe lijnen.
• Welke tools worden gebruikt voor projectbeheer en samenwerking? Kan je bellen, mailen of loopt alles uitsluitend via tickets? Hoe worden uren geregistreerd en verantwoord?
• Wordt er gewerkt met een supportteam of gebeurt dit vanuit het oorspronkelijke ontwikkelteam?
• Hoe flexibel en schaalbaar is de leverancier? Kan er snel worden opgeschaald of geschakeld bij spoed of pieken?
• Hoe is de samenwerking tussen afdelingen, disciplines of externe partners geïntegreerd en gewaarborgd in de werkwijze?
• Welke afspraken en beloftes kunnen er gedaan worden rondom beschikbaarheid en responstijden(SLA)? Denk aan noodzaak voor support buiten kantoortijden, proactieve monitoring en foutopsporing en afhandeling. 
   

Security en kwaliteit (ISO 27001)

De keuze voor Drupal vs Wordpress bijvoorbeeld wordt vaak gemaakt omwille van veiligheid. En hoewel dat een goede basis is voor veiligheid moet een Drupal leverancier, zeker wanneer gevoelige gegevens worden verwerkt, kunnen garanderen dat code, data, infrastructuur en werkwijze veilig en beheersbaar zijn ingericht. Daarnaast is het essentieel dat er gewerkt wordt volgens professionele kwaliteitsstandaarden, zowel in de techniek als in het proces.
 

• Hanteert de leverancier beveiligingsstandaarden zoals de internationaal erkende norm voor informatiebeveiliging ISO 27001?
• Worden security-updates actief gemonitord en uitgerold?
• Is er een beleid voor incidentmanagement en datalekken?
• Wordt gebruikgemaakt van veilige ontwikkel praktijken en kwaliteitsstandaarden? Denk aan code reviews, versiebeheer CI/CD Pipelines, Drupal coding standards, best practices, PHP CodeSniffer (PHPCS), PHPStan en eventueel penetratietests.
• Is er aandacht voor kwaliteit en onderhoudbaarheid van code?

Community bijdrage & Open source

Drupal is gratis te downloaden en te gebruiken. Voor een gemiddelde opdrachtgever levert dit een voordeel op van enkele tienduizenden euro’s ten opzichte van het ontwikkelen van een platform volledig op maat, vanaf scratch. Als opdrachtgever maak je gebruik van een systeem dat is opgebouwd en onderhouden door duizenden mensen wereldwijd. Het is dan ook waardevol om te kijken waar je als organisatie iets kunt teruggeven. Als je de Open source filosofie belangrijk vindt kan je een Drupal leverancier vragen naar:

• Of ze bijdragen aan bestaande Drupal-modules en / of patches?
• Of ze eigen modules, kennis of documentatie delen met de community?
• Of ze betrokken zijn bij het organiseren van Drupal evenementen of deze wellicht sponsoren of op andere manier bijdrage

Het gebruik van open source software alleen is helaas geen garantie tegen vendor lock-in, het niet of zeer moeilijk kunnen wisselen van leverancier. Het is daarom ook belangrijk om deze vragen te stellen:

• Wordt er gewerkt met Drupal standaarden, documentatie en overdraagbare code?
• Is het project overdraagbaar aan een andere partij zonder technische barrières en niet overdracht gerelateerde kosten zoals afkoopsommen?
• Worden er aanvullende technieken of frameworks naast Drupal gebruikt dat een eventuele overgang of leverancier selectie complex maakt?
• Wie is eigenaar van de ontwikkelde code(IE-rechten) en mag die code hergebruikt of doorontwikkeld worden door andere partijen? 

Prijs en contractvorm

Prijs is natuurlijk een vast onderdeel van elke leveranciersselectie. In de digitale sector wordt veelal gewerkt op basis van nacalculatie (uurtarief), maar ook fixed price komt nog geregeld voor. Beide modellen hebben voor- en nadelen.

Fixed price

Een fixed price-afspraak lijkt aantrekkelijk vanwege de ogenschijnlijke voorspelbaarheid en zekerheid op kosten, maar in de praktijk leidt dit vaak tot discussie over scope en meerwerk. Als er onduidelijkheid is over wat er precies binnen of buiten het budget valt, ontstaat er frictie. Zonder een goed uitgewerkt functioneel en technisch ontwerp is het bovendien lastig om leveranciers te vergelijken: elke partij maakt eigen aannames. De partij die wint is niet per definitie de partij die tegen de laagste prijs het beste resultaat had kunnen leveren.

Daarom geldt: wil je een serieuze fixed price-aanbieding? Dan is het eerlijk en noodzakelijk dat er een voldoende concreet ontwerp of specificatie ligt. Pas dan kan een leverancier een voorstel doen dat realistisch, toetsbaar én vergelijkbaar is.

Agile & nacalculatie: flexibiliteit met richting

In de praktijk blijkt dat projecten vaak veranderen: inzichten verschuiven, nieuwe wensen ontstaan. Daarom werken veel Drupal leveranciers met een agile aanpak, zoals Scrum. Daarbij wordt meestal gewerkt:

• met vaste sprints qua uren(kosten) waarin een vooraf afgesproken sprintdoel wordt gerealiseerd,
• of op basis van nacalculatie met een vast budgetplafond, gecombineerd met een backlog en roadmap.

In de offerte fase zou idealiter al een backlog beschikbaar zijn of roadmap met mijlpalen om een inschatting in uren of sprints op te baseren. Die inschattingen worden leidend als commitment, terwijl de inhoudelijke keuzes tijdens het traject flexibel kunnen blijven. Z’n backlog is er vaak niet en ook hier moeten leveranciers vaak aannames doen. De prijs uit de offerte is dan vaak het budget op basis waarvan samen wordt gewerkt en de opdrachtgever  in de rol van Product Owner keuzes maakt op basis van prioriteiten.

Elke samenwerking met Atom begint met het opstellen van een backlog. Regelmatig stellen wij ook samen met de opdrachtgever een backlog op als voorbereiding op een offerte-uitvraag en selectie van een Drupal leverancier.
 

De 5 beste Drupal leveranciers van Nederland

De keuze voor een Drupal leverancier hangt sterk af van technische expertise, teamcapaciteit en de projectaanpak die nodig is en past bij jouw project. Heb je een kleiner en minder complex project met weinig risico, heb je dan per se de grootste of ‘beste’ Drupal leverancier van Nederland nodig?

Het mooie aan een open source community en ecosysteem zoals dat van Drupal is juist dat er ruimte is voor verschillende typen bureaus: van gespecialiseerde agencies zoals Atom, tot grote fullservice spelers en kleine, pionierende start-ups. Voor kleinere en soms ook middelgrote opdrachtgevers kan het juist interessant zijn om niet automatisch de vijf bekendste Drupal leveranciers als shortlist te nemen, maar te kiezen voor een partij waar je wél maximale betrokkenheid krijgt, tegen vaak lagere tarieven.

Wil je maximale betrokkenheid, scherpe tarieven en tegelijkertijd ook een Drupal bureau met goede reputatie, hoogwaardige referenties en een plek binnen de Nederlandse top 5 van Drupal bureaus, dan is Atom jouw leverancier!