ITSM ServiceNow et capacity planning DSI : deux jobs, deux systèmes de référence

ITSM et capacity planning : ce n’est pas le même job

Beaucoup de DSI 20–500 personnes ont déjà ServiceNow pour l’ITSM : incidents, changes, CMDB, catalogue. Elles n’ont souvent pas acheté ServiceNow Resource Management (module SPM). Le trou qui reste : qui est alloué les 8–12 prochaines semaines, le planifié vs le réel, le comité capacité. Ce n’est pas un second ITSM. C’est un système de référence capacité.

Page canon : ServiceNow ITSM + Workload, SoR capacité. Workload ne remplace pas ServiceNow. Workload n’a pas de connecteur ServiceNow. Les timesheets natives sont Jira Tempo, Azure DevOps, Toggl, Clockify et l’import CSV.

Le mot « vs ServiceNow » attire le mauvais lecteur : un PMO enterprise qui compare SPM Resource Management. L’angle utile est « ITSM + capacité » : vous gardez le run où il est, vous donnez enfin un SoR aux allocations.

Tableau : qui est système de référence

Job DSI	ServiceNow ITSM	Workload
Incidents / changes / CMDB	Système de référence	Hors scope
Run / file d’attente service	Oui	Non — ne pas dupliquer
Allocation nommée 8–12 semaines	Non (sauf SPM RM payé)	Oui — Hard / Soft / Tentative
Planifié vs réel (PVA)	Non	Oui — dashboard et pack /ops
Comité capacité (cap 7)	Non	Oui — une cloche par semaine
SPM Resource Management	Add-on enterprise	Ne pas remplacer — pas requis pour la couche tactique IT

Ce que ServiceNow fait très bien

L’ITSM ServiceNow est le bon endroit pour le run : ticket incident, workflow de change, CMDB, catalogue, SLA. Les équipes connaissent déjà ITIL. Dupliquer cette file dans un outil de capacité crée deux files d’attente et aucun SoR. Le change validé reste dans ServiceNow. L’allocation des personnes se planifie ailleurs.

C’est le même réflexe que pour un PPM lourd : compléter Planview/Sciforma n’est pas le même job que compléter un ITSM. Le PPM garde la gouvernance portfolio. ServiceNow garde le run. Workload garde les allocations.

Le CAB (Change Advisory Board) décide si un change est sûr à mettre en production. Il ne dit pas si l’équipe réseau a encore 12 jours nets dans les six semaines. Confondre les deux réunions produit un « go » ITSM et une surcharge silencieuse. Deux comités, deux questions, deux systèmes de référence.

Ce que le capacity planning doit porter

Le capacity planning DSI répond à « avons-nous assez de capacité nette pour le portefeuille ? ». Il mesure les jours ouvrés moins congés et run, alloue des personnes nommées, détecte les conflits, compare le planifié au réel timesheet. Voir capacity planning DSI et capacity vs resource planning.

Sans cette couche, la DSI arbitre encore dans Excel à côté de ServiceNow. L’ITSM dit que le change est « go ». Excel dit (trop tard) que l’équipe est à 140 %. Le comité reçoit 40 lignes d’alertes. Personne n’a une source de référence unique pour les allocations.

Planifié vs réel (PVA)

Le réel ne vient pas des incidents ServiceNow. Il vient du timesheet : Jira Tempo, Azure DevOps, Toggl, Clockify ou CSV. Workload confronte ce réel au plan. Un écart fort alimente le pack capacité — pas la file d’incidents.

Le pack /ops : l’humain décide

Le pack capacité HITL vit dans /dashboard/ops après connexion. Cap 7 propositions, une cloche par semaine, vote humain. Silence de clôture = reporté, pas rejeté. Aucune action hors pack. Workload n’écrit pas le CMDB et ne crée pas d’incidents. Il n’y a pas d’écriture automatique vers ServiceNow, et pas de MCP write dans ce flux.

Anti-patterns : Excel, incidents-projets, 40 alertes

Le schéma le plus fréquent : ServiceNow pour les tickets, Excel pour « qui est sur quoi ». L’ITSM dit que le change est go. Le classeur, trop tard, dit 140 %. Personne n’est SoR des allocations. Les congés, le run et les projets se recouvrent sans conflit détecté.

Deuxième anti-pattern : transformer chaque incident en projet Workload. L’incident reste un ticket ITSM. Un projet de capacité, c’est un lot de travail planifié (évolution, migration, programme) auquel on alloue des personnes nommées. Mélanger les deux recrée la file d’attente dans le mauvais outil.

Troisième : 40 lignes d’alertes par mail. Le comité capacité vote un pack : au plus 7 propositions, une cloche, un lundi. Ce n’est pas un second flux d’incidents. Voir le rythme ci-dessous.

Rythme hebdomadaire : run SN, pack Workload

1. Toute la semaine — incidents et changes dans ServiceNow. Le CMDB reste la vérité du parc.
2. En continu — allocations Hard / Soft / Tentative dans Workload. Conflits visibles avant le comité.
3. Timesheet — Tempo, Azure DevOps, Toggl, Clockify ou CSV alimentent le réel. Pas les tickets SN.
4. Lundi — pack /ops (cap 7). PMO ou admin Approuve, Éditer, Pas cette semaine, ou Ne plus proposer.
5. Comité — RAG / freeze sur la capacité, pas sur la file ITSM. Silence = reporté, pas rejeté.

Qui vote : PMO et admin. Le DSI voit le pack, vote optionnel. Le manager d’équipe n’a pas la file. Le responsable ITSM n’arbitre pas les allocations dans ServiceNow — et Workload n’arbitre pas les P1.

Pourquoi ce n’est pas ServiceNow Resource Management

SPM Resource Management est un module portfolio enterprise : déploiement lourd, PMO mature, budget SPM. Pour une DSI interne 20–500, la couche tactique (allocations 8–12 semaines, PVA, comité cap 7) se fait sans acheter SPM. Ce n’est pas un duel feature-à-feature. C’est « vous n’en avez pas besoin pour cette couche ».

Même famille de suites que Sciforma / Planview : on complète, on ne remplace pas l’ITSM. Détail : Gardez ServiceNow. Mettez la capacité dans Workload.

Comment relier ITSM et capacité au quotidien

1. Le projet ou le change est validé dans ServiceNow — il y reste.
2. L’allocation nommée (Hard / Soft / Tentative) se planifie dans Workload.
3. Le réel timesheet (Tempo, Azure, Toggl, Clockify, CSV) confronte le plan.
4. Le pack /ops propose les écarts au comité (max 7). Un humain Approuve.
5. Les incidents continuent de vivre dans ServiceNow. Le pack ne les liste pas.

Pont optionnel plus tard : CSV, IntegrationHub ou API REST v1 (membres, allocations, timesheet). Pas un connecteur Marketplace. Pas d’incidents → projets automatiques. Pas de CMDB → équipes automatiques.

Questions fréquentes

Workload remplace-t-il ServiceNow ?

Non. ServiceNow reste l’ITSM. Workload ne crée pas d’incidents et n’écrit pas le CMDB. Run dans ServiceNow, capacité dans Workload.

Faut-il acheter ServiceNow Resource Management ?

Non pour la couche capacité tactique d’une DSI 20–500. SPM RM reste un add-on enterprise. Workload porte allocations, PVA et comité.

Workload a-t-il un connecteur ServiceNow ?

Non. Timesheet natif = Jira Tempo, Azure DevOps, Toggl, Clockify, CSV. Un pont passe par CSV, IntegrationHub ou REST v1 — pas un connecteur Marketplace.

Par où commencer

Lisez la landing ServiceNow ITSM + capacité. Importez équipes et allocations (CSV, ~30 min). Reliez un timesheet (Professional). Le lundi, le pack /ops propose les écarts — l’humain vote.

Essai 14 jours, sans carte : créer un compte Workload. Après connexion, le pack capacité est sur /dashboard/ops. SoR = allocations Workload. Run = ServiceNow.