Change management

Wat we doen

Twee sporen: software/infra-wijzigingen en organisatorische wijzigingen. Wijzigingen lopen via Git (pull requests) en Jira; er is geen apart wijzigingsregister.

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 en Jira-referentie, review door een collega
  5. Na goedkeuring: merge en deploy via GitHub Actions (ook mobiele apps naar de stores)

Organisatorische wijzigingen

Wijzigingen in rollen, tooling, leveranciers of processen worden als ticket in Jira-project ISMS vastgelegd en in het directieoverleg behandeld (overlegstructuur: zie 7.4). Per wijziging: impact op beschikbaarheid, integriteit en vertrouwelijkheid, maatregelen en controle op uitvoering.

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

Gaps

• De overgang van alfa naar beta/productie is niet formeel gedefinieerd.
• Patching van OS en infrastructuur is periodiek handmatig; geen geautomatiseerd patch management.
• Organisatorische wijzigingen worden niet consequent als Jira-ticket vastgelegd; het directieoverleg met IB op de agenda wordt hervat (zie 7.4, 9.3).

Bewijs

• Jira: tickets per wijziging (projectboards en project ISMS)
• GitHub: branch- en commithistorie, pull requests met reviews
• GitHub Actions: deployment-runs per repository