Change management

Wat we doen

Twee sporen: software/infra-wijzigingen en organisatorische wijzigingen.

Software en infrastructuur

Onderscheid tussen alfa en beta/productie:

• Alfa fase — vrij ontwikkelen, geen change management procedures. Snel itereren staat voorop.
• Beta/productie (vanaf eerste testversie) — volledige traceerbaarheid:
  1. Elke wijziging begint als Jira ticket (met aanleiding)
  2. Developer werkt in een branch die het Jira ticket refereert (tweezijdige referentie)
  3. Commit messages bevatten het waarom van de change
  4. Pull Request met beschrijving + Jira referentie, review door collega
  5. Na goedkeuring: merge en deploy

Organisatorische wijzigingen

Behandeld in het managementoverleg. Per wijziging:

• Impactanalyse op informatiebeveiliging (beschikbaarheid, integriteit, vertrouwelijkheid)
• Maatregelen bepalen en goedkeuren in directieoverleg
• Controle op uitvoering vastleggen

Verantwoordelijkheden

• Developers / DevOps — wijzigingen doorvoeren conform het change proces
• Projectmanager — Jira tickets aanmaken, change proces bewaken
• DevOps Lead — eigenaar change management proces
• Directie — organisatorische wijzigingen goedkeuren in managementoverleg

Gaps

• Het alfa/beta onderscheid is bewust, maar de overgang is niet formeel gedefinieerd — wanneer precies gaat een project over naar beta/productie?
• Patching OS/infra is periodiek handmatig, niet geautomatiseerd. Geen geautomatiseerd patch management voor servers.
• Organisatorische wijzigingen worden besproken maar niet altijd formeel vastgelegd in het wijzigingsregister.

Bewijs

• Jira change tickets
• Git repositories met branch- en commithistorie (GitHub)
• Pull Request reviews en goedkeuringen (GitHub)
• Notulen managementoverleg (Google Drive)
• Wijzigingsregister (registers/wijzigingen.yaml)