Modèles de données

Architecture CRM

Le portefeuille CRM est organisé en quatre niveaux.

Architecture qui présente la Now Platform comme la couche inférieure, avec des composants de base CRM, des workflows clients et des workflows sectoriels. — Figure 1. Architecture du produit CRM

À la base, la Now Platform fournit les tables de base, les options d’IA et les moteurs dont chaque produit ServiceNow hérite. Au-delà, la Fondation CRM définit les objets de données partagés (client, organisation, territoire, produit et prix) ainsi que les moteurs partagés et les objets transactionnels (opportunité, devis, commande, base d’installation, contrat, ticket, commande de travaux) utilisés par tous les produits CRM. Le niveau Workflows clients fournit les trois produits CRM de base au même niveau : CRM de ventes, Gestion du service client (CSM) et Gestion des services sur site (FSM). Au sommet, les flux de travail industriels fournissent des solutions préconfigurées pour les secteurs verticaux tels que les télécommunications, la technologie, les services financiers, le secteur public, la santé, la vente au détail et la fabrication.

Sales CRM, CSM et FSM ne sont pas des systèmes distincts qui partagent des données via des intégrations. Il s’agit de trois produits construits sur la même base CRM et le même modèle de données de plateforme. Un enregistrement d’entreprise, un enregistrement de personne, un produit, un contrat, chacun existe une fois dans la CRM Foundation et est utilisé par les trois produits et toutes les solutions industrielles au-dessus d’eux.

Couche 1 : base de la Now Platform

Chaque produit ServiceNow repose sur les mêmes tables principales. Ces objets de base ne sont pas répliqués par produit ; ils sont hérités. Lorsqu’un ticket est créé dans CSM, il étend le même enregistrement de tâche qu’un incident ITSM. Lorsqu’une commande est créée dans Sales CRM ou une commande de travaux dans FSM, les deux étendent le même enregistrement de tâche. Il en va de même pour les enregistrements de personne, les enregistrements d’entreprise et la logique SLA. Cette couche comprend également des options d’IA prédictive et d’IA générative.

Tableau 1. Base de Now Platform
Objet de plateforme	Nom de la table	Ce qu’il fait
Tâche	sn_task	Table principale pour tous les enregistrements transactionnels. Les tickets, les incidents, les commandes de travaux et les commandes étendent tous la tâche, en héritant des champs d’état, de priorité, d’affectation et de SLA.
Utilisateur	sys_user	Enregistrement d’une seule personne partagé entre tous les produits. Les contacts CSM, les responsables CRM des ventes, les agents ITSM et les employés RH font tous référence à cette table. Pas de doublons.
Société	core_company	Enregistrement d’organisation de base. Le compte CSM et le compte CRM des ventes étendent tous deux cette table. Un enregistrement de société utilisé dans tous les modules.
CMDB/CI	cmdb_ci	Base de données de gestion des configurations. Éléments de base d’installation Éléments de configuration (CI) de référence ici, liant les déploiements de produits clients à l’infrastructure informatique.
Moteur SLA	contract_sla	Moteur SLA au niveau de la plateforme partagé par les contrats CSM Entitlements et Sales CRM. Fournit un comportement de SLA cohérent entre les tickets, les commandes et les commandes de travaux.

Couche 2 : Base CRM

La CRM Foundation est la couche de données partagées sur laquelle s’appuient les trois produits Customer Workflow. Il contient les objets de données de base qui définissent les clients, les produits et les engagements de service, ainsi que les objets transactionnels sur lesquels Sales CRM, CSM et FSM fonctionnent. Ces objets sont créés une seule fois et consommés par les trois produits sans doublon.

Tableau 2. Objets de données de base CRM
Objet de base	Nom de la table	Ce qu’il fait
Compte	customer_account	Étend core_company. Concentrateur central pour les contacts, les tickets, les contrats et les opportunités. Partagé entre Sales CRM, CSM et FSM.
Contact	customer_contact	Prolonge sys_user. Représente une personne dans un compte client. Utilisé pour l’acheminement des tickets dans CSM, les contacts d’opportunité dans Sales CRM et les contacts de site dans FSM.
Consommateur	csm_consumer	Prolonge sys_user. Représente un client individuel dans un modèle B2C. Interagit directement via des portails en libre-service ou des canaux de services assistés.
Ménage	csm_household	Regroupe les consommateurs qui partagent une adresse et des produits ou services communs. Assiste un responsable de foyer désigné en lui offrant une visibilité sur les tickets et les informations de compte de tous les membres.
Modèle de produit	cmdb_model	Définit un modèle de produit ou de service. Sales CRM l’étend avec la tarification par le biais d’offres de produits ; CSM le référence pour le contexte du ticket.
Produit vendu	sold_product	Suit un produit ou un service vendu à un compte ou à un consommateur. Créé par Sales CRM sur l’exécution des commandes ; référencé par tickets CSM et commandes de travaux FSM.
Élément de base d'installation	alm_asset	Instance spécifique déployée avec numéro de série. Fait référence à un CI CMDB. Visible par les agents dans CSM et les techniciens dans FSM.
Contrat	ast_contract	Définit le type de prise en charge qu’un client reçoit. Créé pendant le mouvement de vente dans Sales CRM ; vérifiés par le CSM pour chaque ticket afin de confirmer les conditions d’assistance.
Droit	droit	Définit les niveaux de SLA, les heures d’assistance et les canaux couverts. Défini par Sales CRM pendant le mouvement de vente ; Vérifié automatiquement par CSM lorsqu’un agent ouvre un ticket.

Remarque :

Les produits répertoriés dans la colonne « Ce qu’il fait » mettent en évidence les principaux produits de workflow client (Sales CRM, CSM, FSM) qui fonctionnent sur chaque objet de base. Les workflows sectoriels tels que les télécommunications, la technologie, les services financiers, le secteur public, la santé, la vente au détail et la fabrication héritent également de ces mêmes objets de base et les utilisent via les produits de workflow client sur lesquels ils s’appuient.

Tableau 3. Moteurs de base CRM
Moteur/option	Ce qu’il fait
Moteur de configuration du produit	Gère les lots de produits, les règles de compatibilité et les options de configuration. Le consommateur primaire est Sales CRM pendant les devis et les commandes Également utilisé par CSM pendant les flux de modification des produits vendus et par les workflows Industry qui étendent Sales CRM avec une logique de configuration verticale.
Moteur de tarification	Applique des règles de tarification, des remises et des calculs de tarifs aux offres de produits. Le consommateur primaire est Sales CRM pendant le processus de devis et de commande. Également invoqués par les flux de modification CSM et les workflows du secteur qui fixent le prix des devis et des commandes.
Optimisation de la planification	Optimise la planification et la répartition des techniciens dans FSM en fonction de l’emplacement, des compétences, de la disponibilité et des exigences du SLA. Le consommateur primaire est FSM et est également utilisé par les workflows de l’industrie avec des opérations sur le terrain telles que les télécommunications et les soins de santé.

Entités client par business model

Les entités clientes de CRM Foundation sont organisées en deux catégories : les entités organisationnelles qui représentent les entreprises et les regroupements, et les entités individuelles qui représentent les personnes. Les entités utilisées dépendent du business model. Les implémentations B2B utilisent des comptes et des contacts. Les implémentations B2C utilisent les consommateurs et les ménages. Les implémentations B2B2C combinent les deux, en ajoutant des consommateurs de compte pour prendre en charge les clients business qui servent les consommateurs finaux. Un seul déploiement peut prendre en charge les trois modèles simultanément.

Tableau 4. Entités clientes et business models
Type d'entité	Entités B2B	Entités B2C	Entités B2B2C
Entités de l’organisation	Compte (customer_account), Compte partenaire (customer_account)	Ménage (csm_household)	Compte + Ménage
Entités individuelles	Contact (customer_contact), Contact partenaire (customer_contact)	Consommateur (csm_consumer), membre du ménage (csm_consumer)	Contact + compte consommateur (csm_consumer)

Couche 3 : Workflows clients (Sales CRM, CSM et FSM)

La couche Workflows clients contient les trois produits CRM principaux au même niveau : Sales CRM, CSM et FSM. Chaque produit fonctionne sur les objets CRM Foundation partagés et ajoute ses propres objets spécifiques au produit. Un enregistrement créé dans un produit est immédiatement disponible pour les autres.

Gestion du service clientèle (CSM)

CSM répond à trois questions pour chaque interaction de service : Qui est le client ? Que possèdent-ils ? À quoi ont-ils droit ? CSM utilise les objets CRM Foundation partagés pour répondre à ces questions. Le ticket correspond à l’objet spécifique à CSM qui les relie.

Tableau 5. Objets spécifiques à CSM
Objet CSM	Nom de la table	Ce qu’il fait
Ticket	sn_customerservice_case	Prolonge la tâche. Enregistrement central pour chaque interaction de service. Connecte Qui (compte/contact/consommateur) + quoi (produit/ressource) + ce qui est dû (contrat/droit). Prend en charge l’admission omnicanale.

CRM des ventes

Sales CRM ajoute le mouvement de vente complet en plus de la base CRM, de la prospection à l’opportunité, au devis, à la commande et à l’exécution. Une fois l’exécution terminée, les objets CRM Foundation partagés prennent le relais. Les produits, contrats et droits vendus sont immédiatement disponibles pour CSM et FSM, sans transfert requis.

Tableau 6. Objets spécifiques à Sales CRM
Objet Sales CRM	Nom de la table	Ce qu’il fait	Étape
Piste	Piste	Client potentiel. Convertit en opportunité + compte/contact sur qualification.	Prospect
Opportunité	Opportunité	Accord potentiel lié à un compte. Suit l’étape de vente ; un à un avec un devis.	Qualifier
Offre de produits	product_offering	Étend le modèle de produit avec des règles de tarification, des offres groupées et des règles de compatibilité.	Configurer
Devis (CPQ)	devis	Proposition tarifaire générée par le configurateur CPQ. Applique les règles de tarification et les offres groupées en temps réel	Prix
Ordre	sn_order_mgmt_order	Achat confirmé. Étend la tâche de plateforme et déclenche les workflows d’exécution en aval.	Ordre
Tâche d’exécution	sc_task	Étend la tâche de la plateforme. Représente les étapes de travail individuelles exécutées pendant l’exécution de la commande.	Accomplir

Field Service Management (FSM, Gestion des services sur site)

FSM ajoute des fonctionnalités d’opérations sur le terrain en plus de CRM Foundation. La commande de travaux est l’objet spécifique à FSM. FSM utilise des enregistrements partagés de compte, de contact, d’élément de base d’installation, de contrat et de droit, de sorte que les techniciens arrivent avec le même contexte client que les agents et les équipes de vente. Scheduling Optimization from CRM Foundation gère l’acheminement et la répartition des techniciens.

Tableau 7. Objets spécifiques à FSM
Objet FSM	Nom de la table	Ce qu’il fait
Commande de travaux	wm_order	Prolonge la tâche. Représente une tâche de service sur site répartie à un technicien. Fait référence aux mêmes enregistrements de compte, de contact, de base d’installation et d’autorisation de CRM Foundation.

Couche 4 : Workflows du secteur

Le niveau supérieur fournit des solutions préconfigurées pour les télécommunications, la technologie, les services financiers, le secteur public, la santé, la vente au détail et la fabrication. Chaque solution sectorielle étend le modèle de données CRM avec des entités spécifiques à un domaine, telles que les dossiers d’abonnés pour les télécommunications, les dossiers de police pour les services financiers ou les dossiers de patients pour les soins de santé, tout en héritant de chaque objet et moteur partagé des couches inférieures.

Les flux de travail de l’industrie s’appuient sur la base CRM et les flux de travail clients ; ils ne les remplacent pas. Un agent de télécommunications travaille toujours avec les mêmes objets de ticket, de compte, de contact et de droit que tout agent CSM, mais l’espace de travail, les playbooks et les extensions de modèle de données sont préconfigurés pour les workflows de télécommunications. Les organisations peuvent déployer une solution sectorielle comme point de départ et la modifier en fonction de l’évolution des besoins.

Comment les couches se connectent

La connexion entre Sales CRM et CSM est structurelle et non technique. Étant donné que les deux couches partagent les mêmes enregistrements sous-jacents, l’exécution d’une commande dans Sales CRM met immédiatement à jour ce que CSM voit. Il n’y a pas de synchronisation par lots, pas de middleware, pas de délai.

L’exécution des commandes dans SOSales CRMM crée un Produit vendu et un Élément de base d’installation dans la couche CSM, disponibles immédiatement pour la gestion des tickets.
Les contrats et les droits définis pendant le mouvement de vente sont vérifiés automatiquement lorsqu’un agent CSM ouvre un ticket. Pas de recherche manuelle.
Les enregistrements de compte, de contact et de modèle de produit sont écrits une seule fois et lus par les deux couches. Les changements se reflètent partout instantanément.
Les commandes de travaux FSM font référence aux mêmes enregistrements de compte, de contact et de base d’installation, de sorte que les techniciens voient le même contexte client que les agents et les équipes de vente.

Cette connexion structurelle est ce qui rend l’histoire de la vente, de l’exécution et du service cohérente. Il ne s’agit pas d’un workflow entre systèmes, mais d’un modèle de données unique avec plusieurs vues opérationnelles.