# ITSM ServiceNow et capacity planning DSI : deux jobs, deux systèmes de référence > ServiceNow garde incidents, changes et CMDB. Workload est le SoR allocations, PVA et pack comité. Pas un connecteur ServiceNow, pas un remplacement SPM. - HTML: https://www.simpleworkload.com/fr/blog/itsm-servicenow-et-capacity-planning-dsi - Markdown: https://www.simpleworkload.com/fr/blog/itsm-servicenow-et-capacity-planning-dsi.md ## ITSM ServiceNow et capacity planning : quelle différence ? L’ITSM ServiceNow est le SoR incidents, changes et CMDB. Le capacity planning est le SoR allocations, planifié vs réel et comité. Workload complète ServiceNow : pas de connecteur ServiceNow, pas un remplacement SPM Resource Management. Timesheet natif = Jira Tempo, Azure DevOps, Toggl, Clockify, CSV. Guide : /blog/itsm-servicenow-et-capacity-planning-dsi. Landing : /servicenow-itsm-capacity. Essai 14 jours. ## 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é](/servicenow-itsm-capacity). 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](/workload-vs-ppm) 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](/capacity-planning-dsi) et [capacity vs resource planning](/blog/capacity-planning-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](/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 - **Toute la semaine** — incidents et changes dans ServiceNow. Le CMDB reste la vérité du parc. - **En continu** — allocations Hard / Soft / Tentative dans Workload. Conflits visibles avant le comité. - **Timesheet** — Tempo, Azure DevOps, Toggl, Clockify ou CSV alimentent le réel. Pas les tickets SN. - **Lundi** — pack /ops (cap 7). PMO ou admin Approuve, Éditer, Pas cette semaine, ou Ne plus proposer. - **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](/comparaison-sciforma) / Planview : on complète, on ne remplace pas l’ITSM. Détail : [Gardez ServiceNow. Mettez la capacité dans Workload.](/servicenow-itsm-capacity) ## Comment relier ITSM et capacité au quotidien - Le projet ou le change est validé dans ServiceNow — il y reste. - L’allocation nommée (Hard / Soft / Tentative) se planifie dans Workload. - Le réel timesheet (Tempo, Azure, Toggl, Clockify, CSV) confronte le plan. - Le pack /ops propose les écarts au comité (max 7). Un humain Approuve. - 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é](/servicenow-itsm-capacity). 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](/register). Après connexion, le pack capacité est sur [/dashboard/ops](/dashboard/ops). SoR = allocations Workload. Run = ServiceNow. ## Sitemap - [Markdown sitemap](https://www.simpleworkload.com/sitemap.md) - [XML sitemap](https://www.simpleworkload.com/sitemap.xml) - [llms.txt](https://www.simpleworkload.com/llms.txt) - [llms-full.txt](https://www.simpleworkload.com/llms-full.txt)