Bijlagen
Verdieping bij het voorstel. Klik een bijlage open.
A
Must Haves, rollen & open keuzes
Wat al duidelijk is en wat we in de startopdracht bepalen
| Onderwerp | Betrokken perspectieven | Wat al duidelijk is | Wat nog bepaald moet worden |
|---|---|---|---|
| Toegang | Werknemer, werkgever, OOM | Toegang moet laagdrempelig zijn | Accounts, social login/SSO, bestaande identiteit, organisatiekoppeling |
| Persoonlijke omgeving | Primair werknemer | Persoonlijke informatie en voortgang gewenst | Data, bronnen en personalisatie |
| Werkgeversomgeving | Werkgever, werknemer, OOM | Werkgever speelt belangrijke rol | Informatie, acties, rechten en rapportage |
| Centrale hulpvraag | Primair werknemer | Kern van de oplossingsrichting | Routing naar kennis, werkgever, coach, OOM of cursus |
| AI Buddy | Primair werknemer | Slimme ondersteuning gewenst | Doelgroep, bronnen, grenzen, privacy, techniek |
| Leren & ontwikkelen | Alle drie | Aanbod beter bereikbaar maken | Wie ziet/doet wat en waar komt data vandaan |
| Cursusaanvraag | Alle drie | Aanvraag moet eenvoudiger | Initiatie, goedkeuring, financiering, verwerking |
| Opleidingsbudget | Alle drie | Inzicht relevant | Definitie, eigenaarschap, rechten, bronsysteem |
| Communicatie | Meerdere rollen | Laagdrempelige ondersteuning | Wie communiceert met wie en via welke techniek |
| Hulpvraagopvolging | Afhankelijk van vraag | Opvolging en status nodig | Routing, rollen, verantwoordelijkheid |
| Meertaligheid | Primair werknemer | Toegankelijkheid belangrijk | Talen, navigatie, content en AI |
| Eigen regie | Werknemer, werkgever | Minder afhankelijk kunnen starten | Waar werkgever juist wél nodig blijft |
| Beheer | Primair OOM | Beheersbaarheid noodzakelijk | Wat OOM, werkgever en bronsystemen beheren |
| Rapportage | Werkgever, OOM | Inzicht relevant | KPI's, privacy en aggregatieniveau |
| Meten | Alle rollen | Gebruik moet meetbaar worden | Concrete events en KPI's |
B
Product Design, techniek & overdraagbaarheid
Van ontwerp naar product en het voorkomen van onnodige afhankelijkheid
Van ontwerp naar product
We werken vanuit Figma → design system → Storybook → OOM-platform. In Figma werken we met herbruikbare componenten, stijlen en ontwerpregels; development vertaalt deze naar werkende componenten in Storybook. Dit helpt bij consistentie, snelheid, onderhoudbaarheid, QA, inwerken van nieuwe mensen en overdraagbaarheid.
Technische kwaliteit
Code reviews, gescheiden development-, acceptatie- en productieomgevingen, geplande releases, hotfixes waar nodig, geautomatiseerde tests voor kritische processen, technische documentatie, integratiedocumentatie en een gedeelde backlog.
Verwachte technische richting
Op basis van wat nu bekend is:
- Laravel als backend
- Headless React als frontend, tevens beschikbaar als PWA
- n8n voor automation
- Keycloak voor identity management
- API-georiënteerde architectuur
- Kubernetes als hosting-infrastructuur
De definitieve architectuur volgt uit de eerste fases.
Voorkomen van onnodige afhankelijkheid
Ons uitgangspunt: open waar het kan, gespecialiseerd waar het waarde toevoegt. Gangbare frameworks en programmeertalen, API-georiënteerde integraties, geen Hatch-specifieke runtime die nodig blijft om het product te gebruiken, externe SaaS alleen bij voldoende toegevoegde waarde, transparantie over licenties en gebruikskosten en waar zinvol een gedocumenteerd migratiepad.
C
Hosting & infrastructuur
Door Hatch beheerd, in Nederlandse datacenters (ISO 27001 / NEN 7510)
Hatch levert en beheert de hosting van het werknemersplatform. Voor de onderliggende datacenter-infrastructuur werken we samen met een Nederlandse, onafhankelijke partij (Cyso) met bijna 30 jaar ervaring in bedrijfskritische omgevingen, meerdere geografisch gescheiden datacenters en ISO 27001- en NEN 7510-certificering. Voor het OOM-platform verwachten we Managed Kubernetes in te zetten.
Voor OOM verandert dat niets aan de verantwoordelijkheid: Hatch beheert de omgeving, bewaakt de beschikbaarheid en is voor alles het centrale aanspreekpunt. Raakt een probleem meerdere lagen, dan lost Hatch dat achter de schermen met de infrastructuurpartij op.
De infrastructuur is gebaseerd op breed gebruikte Kubernetes-technologie, niet op een gesloten Hatch-specifiek hostingplatform. Het werknemersplatform blijft daardoor ook op infrastructuurniveau overdraagbaar.
Kort samengevat: Hatch bouwt, host en beheert het werknemersplatform, op een gespecialiseerd en gecertificeerd Nederlands fundament. OOM heeft altijd één aanspreekpunt: Hatch.
De definitieve inrichting wordt tijdens het traject bepaald op basis van architectuur, capaciteit, beschikbaarheid, security, datastromen, backups, herstel, monitoring en schaalbaarheid. Hostingkosten worden vóór livegang concreet aangeboden en staan los van Hatch Stability en SLA.
E
Hatch Stability
Het werknemersplatform technisch gezond houden na livegang
Na livegang moet het werknemersplatform niet alleen beschikbaar blijven, maar ook veilig, actueel en onderhoudbaar. Met Hatch Stability bepalen we welke onderdelen Hatch structureel bewaakt en onderhoudt. We richten dit modulair in, zodat OOM het niveau kiest dat past bij het belang en gebruik van het werknemersplatform. Hosting staat hier los van.
Proactieve Stability review: periodiek beoordelen we de technische gezondheid als geheel, van “geen actie nodig” tot “directe aandacht nodig”. Het doel is niet zoveel mogelijk bevindingen produceren, maar tijdig signaleren wat daadwerkelijk relevant is. Voor livegang ontvangt OOM een concrete keuze en prijs voor de gewenste combinatie.
F
SLA, support & incidentafhandeling
Wat gebeurt er als er iets misgaat?
Stability helpt problemen voorkomen en signaleren; de SLA bepaalt hoe en wanneer Hatch reageert wanneer daadwerkelijk iets misgaat. Hatch is het primaire aanspreekpunt: OOM hoeft niet zelf te bepalen of een probleem in de applicatie, de infrastructuur, een integratie of bij een externe leverancier zit. Hatch doet de eerste beoordeling en coördineert.
Prioriteiten
| Prioriteit | Omschrijving |
|---|---|
| P1 · Kritiek | Bedrijfskritisch onderdeel niet beschikbaar of ernstig security-/datarisico zonder workaround. Bijvoorbeeld: platform grotendeels onbereikbaar, vrijwel niemand kan inloggen, essentieel proces volledig stil. |
| P2 · Hoog | Belangrijke functionaliteit werkt niet goed met duidelijke impact, maar het werknemersplatform blijft gedeeltelijk bruikbaar of er is een workaround. |
| P3 · Normaal | Beperkte impact; belangrijkste processen blijven bruikbaar. Wordt regulier ingepland. |
| P4 · Vraag of verbetering | Geen incident: gebruiksvraag, wijziging, optimalisatie of nieuwe wens. Loopt via het reguliere product- en roadmapproces. |
Servicetijden & opvolging
Reguliere servicetijden: werkdagen 08:00-18:00 uur, melden via de Hatch Service Desk, bij urgentie telefonisch escaleren. We onderscheiden responstijd (beoordelen en reageren), tijd tot actie (start onderzoek of herstel) en oplostijd (geen vooraf gegarandeerde tijd; afhankelijk van oorzaak, complexiteit en externe afhankelijkheden).
SLA-keuzes
| Kantooruren | Kritieke bereikbaarheid | Uitgebreide bereikbaarheid | |
|---|---|---|---|
| 08:00-18:00 werkdagen | ✓ | ✓ | ✓ |
| P1 buiten kantooruren | Volgende werkdag | ✓ | ✓ |
| P2 buiten kantooruren | Volgende werkdag | Volgende werkdag | ✓ |
| Telefonische escalatie buiten kantooruren | – | P1 | P1 + P2 |
| Rechtstreeks teamlid gealarmeerd | – | ✓ | ✓ |
| Prijs | |||
24/7-opvolging is geen standaardonderdeel van Stability, maar een bewuste keuze binnen het afgesproken SLA-niveau.