Votre modèle de données pour la planification de la production
Votre modèle de données pour la planification de la production
- Attributs recommandés pour analyser la planification de la production
- Activités clés à suivre dans la planification de la production
- Guide détaillé d’extraction des données de SAP S/4HANA
Attributs de planification de la production
| Nom | Description | ||
|---|---|---|---|
| Activité Activity | Nom de l’événement ou de la tâche qui s’est produit à un moment donné du processus de planification de la production. | ||
| Description Cet attribut consigne les différentes étapes et les jalons du cycle de vie de l’ordre de production. Il peut s’agir, par exemple, de « Ordre de production créé », « Disponibilité des matériaux vérifiée », « Production démarrée » ou « Clôture financière de l’ordre ». Chaque activité correspond à une action précise ou à un changement de statut enregistré dans le système. L’analyse de l’ordre et de la fréquence de ces activités est au cœur du Process Mining. Elle permet de visualiser le flux du processus, de repérer les écarts par rapport à la procédure standard et d’identifier les activités qui entraînent des retards ou nécessitent des reprises fréquentes, comme « Plan de production ajusté ». Pourquoi est-ce important ? Cet attribut définit les étapes du processus et permet de découvrir et de visualiser le flux de travail réel de la production ainsi que ses variantes. Où trouver ces données Déduit des changements de statut dans des tables telles que JEST et JCDS, des codes de transaction utilisés (par exemple, CO01 pour la création) ou de certains enregistrements de confirmation dans AFRU. Exemples Ordre de fabrication crééOrdre de fabrication lancéProduction démarréeConfirmation finale saisieEntrée de marchandises comptabilisée | |||
| Heure de début StartTime | Horodatage indiquant le début d’une activité ou d’un événement précis. | ||
| Description Cet attribut indique la date et l’heure de chaque événement enregistré dans le processus de production. Il constitue la base temporelle de toute analyse du processus fondée sur le temps. L’heure de début est essentielle pour calculer la durée entre les activités, mesurer le temps de cycle total d’un ordre de production et comprendre la chronologie des événements. En comparant les horodatages réels aux dates prévues, vous pouvez analyser les goulots d’étranglement, les temps d’attente et le respect du calendrier. Pourquoi est-ce important ? Il situe les événements dans le temps et permet ainsi d’analyser les performances du processus, les durées et les goulots d’étranglement. Où trouver ces données Ces informations se trouvent généralement dans les tables de documents de modification (CDHDR/CDPOS) pour les changements de statut, dans les tables de confirmation (AFRU) pour les étapes d’exécution et dans les tables d’en-tête (AFKO) pour les dates de création. Exemples 2023-10-26T09:00:00Z2023-10-26T14:30:00Z2023-10-27T08:15:00Z | |||
| Ordre de production ProductionOrder | Identifiant unique d’un ordre de production, utilisé comme identifiant principal du cas dans le processus de planification de la production. | ||
| Description Le numéro d’ordre de production est une clé unique générée par SAP S/4HANA pour gérer et suivre toutes les activités liées à la fabrication d’une quantité donnée d’un produit. Il relie les événements associés, de la planification et du lancement jusqu’à l’exécution et à la régularisation finale. En Process Mining, cet attribut est essentiel pour regrouper tous les événements associés dans une seule instance de processus de bout en bout. L’analyse par ordre de production permet de mesurer des indicateurs clés, comme le temps de cycle et le respect du calendrier, et de repérer les goulots d’étranglement qui affectent certaines séries de production. Pourquoi est-ce important ? Cet attribut fondamental relie toutes les étapes du processus et permet d’analyser l’ensemble du cycle de vie de la production, du début à la fin, au niveau du cas. Où trouver ces données Il s’agit du numéro d’ordre de production, généralement présent dans les tables SAP telles qu’AFKO (champ AUFNR) et AFPO. Exemples 100056710008341001299 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation ou extraction des données depuis le système source. | ||
| Description Cet attribut enregistre la date et l’heure de la dernière extraction des données. Cette métadonnée importante indique aux utilisateurs si les données qu’ils analysent sont à jour. Connaître l’heure de la dernière mise à jour est essentiel pour interpréter correctement l’analyse. Cela permet de savoir si les informations consultées sont en temps réel ou correspondent à un instantané pris à un moment précis, ce qui influe sur la pertinence des constats et des décisions fondées sur ces données. Pourquoi est-ce important ? Il permet aux utilisateurs de connaître l’actualité des données, un élément essentiel pour prendre des décisions métier pertinentes et précises. Où trouver ces données Cet horodatage est généré et ajouté lors du processus d’extraction, de transformation et de chargement des données (ETL). Exemples 2024-05-21T02:00:00Z2024-05-22T02:00:00Z2024-05-23T02:00:00Z | |||
| Système source SourceSystem | Système à partir duquel les données de planification de la production ont été extraites. | ||
| Description Cet attribut indique l’origine des données, ce qui est essentiel dans les environnements où plusieurs systèmes sont intégrés. Pour ce processus, il s’agit généralement de l’instance SAP S/4HANA concernée. Dans le cadre d’une analyse plus large des données, connaître le système source contribue à garantir leur intégrité et à fournir le contexte nécessaire lors de la fusion de données provenant de différentes sources. Il s’agit d’une métadonnée fondamentale pour la gouvernance et la traçabilité des données. Pourquoi est-ce important ? Il fournit des métadonnées essentielles à la gouvernance des données et permet de connaître clairement leur origine et leur contexte. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données pour identifier le client SAP S/4HANA et l’identifiant système (SID). Exemples S4P_100S4H_PRD_200S4Q_300 | |||
| Date de fin prévue PlannedEndDate | Date d’achèvement prévue de l’ordre de production selon le plan initial. | ||
| Description La date de fin prévue est la date à laquelle toutes les activités de production d’un ordre devraient être terminées. Elle est déterminée lors de la planification de la production. Cet attribut est essentiel pour mesurer le respect du calendrier. En comparant la date de fin prévue à l’horodatage réel de fin, les organisations peuvent calculer le KPI de respect du calendrier de production et repérer les ordres en retard. Cette analyse contribue à améliorer la précision de la planification et la satisfaction des clients. Pourquoi est-ce important ? Elle sert de référence pour mesurer le respect du calendrier et évaluer la précision de la planification ainsi que l’efficacité de l’exécution. Où trouver ces données Présente dans la table d’en-tête des ordres de production AFKO (champ GLTRP). Exemples 2023-11-152023-12-012024-01-20 | |||
| Numéro de matériau MaterialNumber | Identifiant unique du produit fabriqué dans le cadre de l’ordre de production. | ||
| Description Le numéro de matériau désigne l’article que l’ordre de production vise à fabriquer. Il relie le processus de production aux données de base du matériau, notamment à sa nomenclature (BOM) et à sa gamme opératoire. L’analyse du processus par numéro de matériau permet de déterminer si certains produits sont davantage sujets aux retards, aux reprises ou aux pénuries de matériaux. Vous pouvez ainsi optimiser le processus pour chaque produit, par exemple en ajustant les paramètres de planification ou en améliorant l’approvisionnement de certains composants. Pourquoi est-ce important ? Il permet de filtrer et d’analyser les données selon le produit fabriqué, afin de repérer les inefficacités ou les goulots d’étranglement propres à certains produits. Où trouver ces données Présent dans la table des postes d’ordre de production AFPO (champ MATNR). Exemples RM-1001FG-2050SA-3100-B | |||
| Poste de travail WorkCenter | Machine, groupe de machines ou zone d’assemblage chargé d’une opération. | ||
| Description Un poste de travail désigne une unité opérationnelle précise au sein d’un site, où une étape de production est réalisée. Il peut s’agir d’une machine, d’une ligne de production ou d’une équipe. L’analyse des données du processus par poste de travail est essentielle pour repérer les goulots d’étranglement liés aux capacités et mieux répartir les ressources. Elle permet de déterminer quels postes sont surchargés ou sous-utilisés et où les retards surviennent le plus souvent pendant la phase d’exécution de la production. Ces informations sont indispensables au Dashboard d’identification des goulots d’étranglement liés aux capacités. Pourquoi est-ce important ? Il permet de repérer les machines ou les lignes de production qui constituent des goulots d’étranglement, afin d’améliorer de manière ciblée les capacités et l’utilisation des ressources. Où trouver ces données Présent dans les données d’opération d’un ordre de production, dans la table AFVC (champ ARBPL). Exemples WC-ASSEMBLY-01WC-MILLING-05WC-PACKING | |||
| Site de production Plant | Usine ou site où l’ordre de production est exécuté. | ||
| Description Le site de production est une unité organisationnelle dans SAP qui représente un lieu de production ou une usine. Chaque ordre de production est affecté à un site où les activités de fabrication sont réalisées. Cet attribut est essentiel pour comparer différents sites de production. En segmentant les données du processus par site, les organisations peuvent comparer les performances, repérer les problèmes ou les bonnes pratiques propres à chaque site et comprendre les différences régionales en matière d’efficacité, de capacité ou de respect des normes. Pourquoi est-ce important ? Il permet de comparer les performances de différents sites de production, de repérer et de partager les bonnes pratiques ou de traiter les problèmes propres à un site. Où trouver ces données Présent dans la table d’en-tête des ordres de production AFKO (champ DWERK). Exemples 100017102000 | |||
| Statut de l’ordre OrderStatus | Statut de traitement actuel de l’ordre de production, par exemple créé, lancé ou clôturé techniquement. | ||
| Description Le statut de l’ordre indique l’étape à laquelle se trouve l’ordre de production dans son cycle de vie. Il résume les différents statuts système et utilisateur qui lui sont attribués. Parmi les statuts courants figurent CRTD (créé), REL (lancé), CNF (confirmé), TECO (clôturé techniquement) et CLSD (clôturé). L’analyse du statut actuel des ordres permet de comprendre les travaux en cours. En Process Mining, le suivi des transitions entre ces statuts au fil du temps génère le journal d’activités et donne une vue détaillée du flux du processus ainsi que du temps passé à chaque étape. Pourquoi est-ce important ? Il donne une vue d’ensemble de l’étape du cycle de vie de l’ordre et permet de reconstituer la séquence des activités pour le Process Mining. Où trouver ces données Déduit du statut système enregistré dans la table JEST, à partir du numéro d’objet dans AFKO (champ OBJNR). Exemples CRTDRELTECOCLSD | |||
| Dans les délais IsOnTime | Indicateur précisant si l’ordre de production a été terminé à la date de fin prévue ou avant celle-ci. | ||
| Description Cet attribut booléen calculé mesure directement le respect du calendrier en comparant la date réelle d’achèvement à la date de fin prévue. Il indique clairement, pour chaque ordre de production, s’il a été terminé dans les délais. Cet attribut sert de base au KPI de respect du calendrier de production. Il simplifie l’analyse en permettant de distinguer facilement les ordres terminés dans les délais de ceux qui sont en retard, et de repérer les caractéristiques ou les parcours de processus associés aux retards. Pourquoi est-ce important ? Il fournit une mesure claire et simple du respect du calendrier pour chaque ordre et facilite l’analyse des causes des retards. Où trouver ces données Champ calculé. Défini sur true si l’horodatage de l’activité « Ordre clôturé techniquement » est antérieur ou égal à la date de fin prévue. Exemples truefalse | |||
| Date de début prévue PlannedStartDate | Date de début prévue de l’ordre de production selon le plan initial. | ||
| Description La date de début prévue est la date à laquelle les activités de production d’un ordre devraient commencer. Elle est définie lors de la planification. Cet attribut sert de référence initiale pour analyser le respect du calendrier. La comparaison entre la date de début prévue et l’heure de début réelle permet de comprendre les retards en amont, par exemple ceux liés à la préparation des matériaux ou au lancement de l’ordre, qui peuvent ensuite affecter l’ensemble du calendrier de production. Pourquoi est-ce important ? Elle sert de référence pour mesurer le respect de l’heure de début et repérer les retards survenant avant la production, par exemple lors du lancement de l’ordre ou de la mise à disposition des matériaux. Où trouver ces données Présente dans la table d’en-tête des ordres de production AFKO (champ GSTRP). Exemples 2023-11-102023-11-252024-01-15 | |||
| Heure de fin EndTime | Horodatage indiquant la fin d’une activité ou d’un événement précis. | ||
| Description Cet attribut indique la date et l’heure de fin de chaque événement enregistré. Il complète l’heure de début et permet de déterminer la durée des activités. L’heure de fin est essentielle pour calculer précisément la durée de traitement de chaque activité, une donnée importante pour analyser les capacités et l’utilisation des ressources. Elle permet de distinguer le temps de travail effectif des périodes d’inactivité ou d’attente, et donc de repérer plus précisément les goulots d’étranglement. Pourquoi est-ce important ? Il permet de calculer précisément la durée des activités, ce qui est essentiel pour analyser l’efficacité des ressources et repérer les goulots d’étranglement du processus. Où trouver ces données Présent dans les tables de confirmation (AFRU) pour les étapes d’exécution. Pour les autres événements, l’heure de fin peut être identique à l’heure de début si l’événement est instantané. Exemples 2023-10-26T09:45:00Z2023-10-26T15:00:00Z2023-10-27T10:30:00Z | |||
| Priorité de production ProductionPriority | Code ou valeur attribué à un ordre de production pour indiquer son urgence ou son importance. | ||
| Description Les planificateurs utilisent la priorité de production pour ordonner et hiérarchiser les ordres, notamment lorsque les ressources sont limitées. En principe, un ordre prioritaire doit être traité avant un ordre moins prioritaire. L’analyse de cet attribut permet de vérifier si les priorités définies sont respectées sur le site de production. Le Dashboard de cohérence des priorités de production compare l’ordre de traitement à la priorité attribuée et repère les incohérences. Ces informations peuvent contribuer à mieux respecter les règles de planification et à rapprocher la planification de l’exécution. Pourquoi est-ce important ? Il permet de vérifier si la planification de la production respecte les priorités métier et si les ordres prioritaires sont traités en conséquence. Où trouver ces données Il s’agit souvent d’un champ personnalisé ou d’une valeur déduite d’autres paramètres de l’ordre. Son emplacement dépend de la configuration. Exemples ÉlevéeMoyenneFaible15 | |||
| Quantité confirmée TotalConfirmedQuantity | Quantité totale de matériaux déclarée comme produite pour l’ordre. | ||
| Description Cet attribut représente la quantité cumulée de produits finis ou semi-finis déclarée dans les confirmations de production. Il indique l’avancement de l’ordre par rapport à la quantité prévue. La comparaison entre la quantité confirmée et la quantité prévue permet de suivre l’avancement de la production et de repérer les problèmes de rendement ou les écarts. C’est une mesure fondamentale de la production, utilisée dans différents calculs de performance, notamment ceux des taux de rebut et d’efficacité. Pourquoi est-ce important ? Il suit la production réelle de l’ordre, ce qui est essentiel pour surveiller l’avancement, calculer le rendement et repérer les écarts. Où trouver ces données Agrégée à partir des enregistrements de confirmation dans AFRU (champ LMNGA pour la quantité produite). Exemples 9801000501200 | |||
| Reprise effectuée IsRework | Indicateur précisant si l’ordre de production a nécessité des reprises ou des ajustements importants du plan après son démarrage. | ||
| Description Cet attribut booléen est calculé pour repérer les ordres de production ayant fait l’objet de mesures correctives ou de changements de plan après le début de la production. Il peut être déclenché par une activité de reprise explicite ou par un événement « Plan de production ajusté » survenu après « Production démarrée ». Cet indicateur est essentiel au calcul du KPI de taux de reprise en production et au Dashboard des reprises et révisions en production. Il facilite le filtrage et l’analyse des cas problématiques, afin d’identifier les causes des problèmes de qualité ou des écarts de processus qui entraînent des reprises coûteuses. Pourquoi est-ce important ? Il isole les cas ayant nécessité des reprises et permet d’analyser de manière ciblée les problèmes de qualité, les écarts de processus et les coûts associés, afin de les réduire. Où trouver ces données Champ calculé. Défini sur true si l’activité « Plan de production ajusté » survient après l’activité « Production démarrée » dans le même cas, ou si un type d’ordre de reprise spécifique est utilisé. Exemples truefalse | |||
| Statut de disponibilité des matériaux MaterialAvailabilityStatus | Indique si tous les matériaux nécessaires à l’ordre de production sont disponibles. | ||
| Description Ce statut indique le résultat du contrôle de disponibilité des matériaux effectué pour un ordre de production. Il peut signaler que tous les matériaux sont disponibles, que certains manquent ou que le contrôle n’a pas été effectué. Un statut de « pénurie » peut annoncer un retard. Cet attribut est essentiel au Dashboard d’analyse de l’impact des pénuries de matériaux. Il permet de mesurer les retards dus à l’indisponibilité des matériaux en mettant en relation le statut de pénurie et le délai entre le lancement de l’ordre et le début de la production. L’amélioration de cet indicateur contribue à mieux organiser le flux de production. Pourquoi est-ce important ? Il permet d’expliquer directement les retards entre le lancement de l’ordre et le début de la production, et de mesurer l’impact des problèmes d’approvisionnement sur la fabrication. Où trouver ces données Il s’agit d’un statut, souvent déduit du statut collectif des composants. Il peut figurer dans le statut système (JEST), sous des codes tels que « MSPT » (pénurie de matériaux). Exemples DisponiblePénurieNon vérifié | |||
| Type d’ordre OrderType | Classification de l’ordre de production qui en définit l’objectif et détermine son traitement. | ||
| Description Le type d’ordre est un élément de configuration important de SAP PP qui détermine la manière dont le système traite un ordre de production. Il définit les plages de numéros, la sélection des données de base, les paramètres de calcul des coûts et les règles de régularisation. Il peut s’agir, par exemple, d’un ordre de production standard, d’un ordre de reprise ou d’un ordre de prototype. L’analyse du processus par type d’ordre permet de comparer les performances et le déroulement des différents types de production. Elle peut révéler si les ordres de reprise prennent beaucoup plus de temps ou si certains types d’ordre nécessitent plus souvent des ajustements de planification, et ainsi orienter les améliorations du processus. Pourquoi est-ce important ? Il permet de segmenter l’analyse selon l’objectif métier de l’ordre et de comparer la production standard, les reprises et les autres processus. Où trouver ces données Présent dans la table d’en-tête des ordres de production AFKO (champ AUART). Exemples PP01PP03ZP01 | |||
| Utilisateur User | Identifiant système de l’utilisateur qui a créé, modifié ou confirmé un événement lié à un ordre de production. | ||
| Description Cet attribut indique l’identifiant de l’utilisateur SAP associé à une transaction ou à un changement de statut précis, par exemple le lancement d’un ordre ou la saisie d’une confirmation. Il assure la traçabilité des actions effectuées dans le système. L’analyse des activités par utilisateur permet de comprendre la répartition de la charge de travail, de repérer les besoins de formation et de vérifier le respect des procédures. Elle peut, par exemple, révéler si certains utilisateurs interviennent souvent dans les ajustements de plan ou si des retards sont associés à certaines équipes. Pourquoi est-ce important ? Il assure la traçabilité des responsabilités et permet d’analyser la charge de travail, les pratiques propres à chaque utilisateur et les besoins éventuels de formation. Où trouver ces données Généralement présent dans les en-têtes des documents de modification (CDHDR, champ UNAME) ou dans les enregistrements de confirmation (AFRU, champ PERNR pour le numéro de personnel). Exemples CB9980000021JSMITHPLANNER01 | |||
Activités de planification de la production
| Activité | Description | ||
|---|---|---|---|
| Confirmation finale saisie | Cette activité marque la confirmation de la dernière opération de la gamme de l’ordre de fabrication. Elle indique que toutes les étapes de fabrication prévues ont été réalisées en atelier. | ||
| Pourquoi est-ce important ? La confirmation finale est une étape clé qui marque la fin du travail de production physique. Elle sert souvent de point de fin plus précis pour mesurer le temps de cycle en atelier, avant la réception finale des marchandises. Où trouver ces données Déduite des données de confirmation de la table AFRU. Elle correspond à l’enregistrement de confirmation de la dernière séquence d’opérations (AFVC-VPLNR) pour laquelle l’indicateur de confirmation finale (AFRUD-AUERU) est activé. Données à recueillir Rechercher dans AFRU la dernière confirmation d’opération dont l’indicateur de confirmation finale est activé. Type d’événement inferred | |||
| Entrée de marchandises comptabilisée | Cet événement enregistre la réception du produit fini provenant de la ligne de production et son entrée en stock. Il augmente officiellement le niveau de stock du matériel produit. | ||
| Pourquoi est-ce important ? Cette étape clé marque l’achèvement de la production. Elle est souvent considérée comme la fin du cycle de production pour mesurer le respect des délais de livraison et le délai global. Où trouver ces données Il s’agit d’une comptabilisation financière explicite, enregistrée dans les tables de documents de matériel MSEG (niveau poste) et MKPF (niveau en-tête), généralement avec le type de mouvement 101. Ces documents sont liés à l’ordre de fabrication. Données à recueillir Rechercher dans MSEG le document de matériel lié à l’ordre et portant le type de mouvement 101. Type d’événement explicit | |||
| Ordre achevé techniquement | Cette étape administrative de clôture empêche toute nouvelle modification logistique de l’ordre, comme les mouvements de marchandises ou les confirmations. Du point de vue logistique, l’ordre est alors considéré comme terminé. | ||
| Pourquoi est-ce important ? TECO marque la fin définitive du processus de production et constitue un repère essentiel pour calculer le temps de cycle total de l’ordre de fabrication. Ce statut indique que toutes les activités logistiques sont terminées et que l’ordre peut être soldé financièrement. Où trouver ces données L’événement est déclenché lorsqu’un utilisateur attribue le statut TECO (Technically Completed). Il est enregistré comme un changement de statut dans la table JCDS, avec l’horodatage correspondant. Données à recueillir Horodatage du changement de statut vers « TECO » dans la table JCDS. Type d’événement inferred | |||
| Ordre de fabrication créé | Il s’agit de la création initiale de l’ordre de fabrication dans le système. Cet ordre constitue la demande officielle de produire une quantité donnée d’un produit. L’événement est enregistré explicitement lorsqu’un utilisateur enregistre un nouvel ordre, dont le statut initial est alors défini sur CRTD (Created). | ||
| Pourquoi est-ce important ? Cet événement marque le début du cycle de vie de l’ordre de fabrication. L’analyse du délai entre sa création et son lancement permet de repérer les retards administratifs ou de planification qui précèdent la programmation officielle de la production. Où trouver ces données Cet événement est enregistré dans la table AUFK (données de base de l’ordre), avec la date de création (ERDAT). Le statut de création (CRTD) est consigné dans les tables JEST et JCDS, liées par le numéro d’objet de l’ordre (OBJNR). Données à recueillir Horodatage provenant de AUFK-ERDAT ou du journal des changements de statut vers « CRTD » dans JCDS. Type d’événement explicit | |||
| Ordre de fabrication lancé | Cette étape clé correspond à l’approbation de l’ordre de fabrication et à sa mise à disposition pour exécution dans l’atelier. Le lancement permet de commencer les sorties de marchandises, les confirmations et les autres étapes d’exécution. | ||
| Pourquoi est-ce important ? Cet événement marque le début officiel du processus de production exécutable et constitue un point de mesure important des délais. Le temps écoulé entre la création et le lancement est un indicateur clé de l’efficacité des étapes préalables à la production. Où trouver ces données Le lancement est déclenché explicitement par un utilisateur ou une tâche système et entraîne le passage au statut REL. Ce changement de statut est enregistré avec un horodatage dans la table JCDS. La date de lancement est également souvent stockée dans AFKO-FTRMI. Données à recueillir Horodatage du changement de statut vers « REL » dans la table JCDS. Type d’événement inferred | |||
| Plan de production ajusté | Correspond à une modification importante de l’ordre de fabrication après son lancement, par exemple un changement de quantité, de dates ou de nomenclature. Cette modification est repérée à partir des documents de changement. | ||
| Pourquoi est-ce important ? Des ajustements fréquents peuvent signaler une planification instable ou une demande volatile. Cette activité sert de base à l’indicateur du taux de révision du plan de production et aide à repérer les sources de variabilité du processus. Où trouver ces données Déduit des journaux de modifications enregistrés dans les tables CDHDR (en-tête du document de changement) et CDPOS (postes du document de changement) pour l’objet de l’ordre de fabrication (AUFK ou AFPO). Les modifications effectuées après la date de lancement sont considérées comme des ajustements. Données à recueillir Repérer dans CDHDR/CDPOS les modifications apportées aux champs clés, par exemple la quantité ou les dates, après le lancement de l’ordre. Type d’événement inferred | |||
| Production démarrée | Indique le début des activités de production physique pour l’ordre. Cet événement est généralement déduit de la première confirmation en atelier ou de la première sortie de composants pour l’ordre. | ||
| Pourquoi est-ce important ? Cette activité marque le passage de la planification à l’exécution. Elle est essentielle au suivi du respect du calendrier, en comparant la date de début réelle à la date prévue. Où trouver ces données Cet événement est déduit des données. Il est généralement déterminé à partir de l’horodatage le plus ancien d’une comptabilisation de mouvement de marchandises (table MSEG, type de mouvement 261) ou d’une confirmation de temps (table AFRU) associée à l’ordre. Données à recueillir Horodatage le plus ancien dans AFRU (confirmations) ou MSEG (mouvements de marchandises) pour l’ordre. Type d’événement inferred | |||
| Arrêt imprévu survenu | Cet événement calculé correspond à une période d’inactivité importante pendant l’exécution de la production. Il ne s’agit pas d’un événement explicitement enregistré par le système : il est déduit de longs intervalles entre des confirmations de production consécutives. | ||
| Pourquoi est-ce important ? Permet de surveiller les interruptions imprévues, comme les pannes de machine ou les problèmes de qualité. Repérer les arrêts fréquents ou prolongés est essentiel pour améliorer la stabilité de l’atelier et le débit de production. Où trouver ces données Cet événement est calculé à partir des horodatages d’activités consécutives « Confirmation de production saisie » dans la table AFRU. Tout intervalle dépassant un seuil prédéfini est signalé comme un arrêt imprévu. Données à recueillir Calculer l’écart entre les horodatages de confirmations consécutives (AFRU-BUDAT/UZEIT). Type d’événement calculated | |||
| Besoins en capacité planifiés | Cette activité consiste à planifier les opérations de l’ordre de fabrication et à vérifier la disponibilité des capacités aux postes de travail requis. Le système évalue la charge des postes de travail et, si le paramétrage le prévoit, l’équilibre afin de déterminer les dates de production. | ||
| Pourquoi est-ce important ? Cette étape est essentielle pour établir un calendrier de production réalisable. L’analyse de sa durée et de ses résultats permet de repérer les goulots d’étranglement liés aux capacités et d’améliorer la précision de la planification des ressources. Où trouver ces données Cette activité est généralement déduite du statut système indiquant que l’ordre a été planifié, par exemple SETC (Scheduling carried out). Le renseignement des dates de début et de fin planifiées (AUFK-GSTRP, AUFK-GLTRP) indique également que l’activité est terminée. Données à recueillir Déduit du renseignement des dates planifiées dans AUFK/AFKO ou d’un statut lié à la planification dans JEST. Type d’événement inferred | |||
| Confirmation de production saisie | Cette activité correspond à l’enregistrement de l’avancement d’une opération précise de l’ordre de fabrication. Elle comprend la saisie des quantités produites, des rebuts et du temps passé à un poste de travail. | ||
| Pourquoi est-ce important ? Les confirmations donnent une visibilité en temps réel sur l’avancement en atelier et sont indispensables au suivi de l’état de la production. L’analyse de leur fréquence et de leur calendrier permet de suivre le déroulement des opérations et de repérer les retards entre celles-ci. Où trouver ces données Chaque confirmation est enregistrée explicitement dans la table AFRU (confirmations d’achèvement des ordres), avec un horodatage (BUDAT, UZEIT) et des détails sur l’opération. Données à recueillir Enregistrée sous forme de document dans la table AFRU. Type d’événement explicit | |||
| Disponibilité du matériel vérifiée | Cette activité correspond à la vérification, par le système ou un utilisateur, de la disponibilité de tous les composants requis pour l’ordre de fabrication, dans les quantités nécessaires et au bon moment. Il s’agit généralement d’un contrôle automatique lors de la création ou du lancement de l’ordre, ou d’une vérification manuelle qui met à jour son statut. | ||
| Pourquoi est-ce important ? Repérer rapidement les pénuries de matériel est essentiel pour anticiper les besoins. Le suivi de cette activité permet de comprendre comment la disponibilité du matériel influe sur la possibilité de lancer les ordres et de démarrer la production dans les délais. Où trouver ces données Déduit du statut de l’ordre. Un statut tel que MACM (Material committed) ou une modification de la date de disponibilité du matériel (AFKO-MSERF) indique qu’une vérification a été effectuée. L’absence d’un statut de pénurie de matériel (MSPT) peut également indiquer que le matériel est disponible. Données à recueillir Déduit des changements de statut liés à l’engagement du matériel ou à l’exécution de la transaction COMAC. Type d’événement inferred | |||
| Ordre clôturé financièrement | Dernière étape de clôture : l’ordre est soldé et aucune autre comptabilisation financière n’est possible. Elle marque la fin du cycle de vie de l’ordre du point de vue du contrôle de gestion et de la comptabilité. | ||
| Pourquoi est-ce important ? Bien que cette activité dépasse souvent le cadre d’une analyse de la production au sens strict, elle offre une vue complète de bout en bout. Elle peut aider à analyser le délai entre l’achèvement logistique (TECO) et la clôture financière. Où trouver ces données L’événement est déclenché lorsqu’un utilisateur attribue le statut CLSD (Closed). Il est enregistré comme un changement de statut dans la table JCDS, avec l’horodatage correspondant. Données à recueillir Horodatage du changement de statut vers « CLSD » dans la table JCDS. Type d’événement inferred | |||
| Ordre de fabrication annulé | Correspond à l’annulation d’un ordre de fabrication avant son achèvement. Il s’agit d’une issue alternative qui marque l’échec du processus. | ||
| Pourquoi est-ce important ? L’analyse des ordres annulés peut révéler des problèmes de planification de la demande, de données de base ou de processus de vente. Un taux d’annulation élevé peut signaler des problèmes systémiques à traiter. Où trouver ces données Déduit de l’activation du statut système CACL (Cancellation) dans la table JCDS. L’indicateur de suppression (AUFK-LOEKZ) peut également signaler une annulation. Données à recueillir Horodatage du changement de statut vers « CACL » dans JCDS ou activation de l’indicateur de suppression dans AUFK. Type d’événement inferred | |||
| Pénurie de matériel survenue | Cet événement indique que le processus de production a été perturbé ou interrompu en raison de l’indisponibilité d’un ou plusieurs composants requis. Le système attribue un statut spécifique à l’ordre pour signaler la situation. | ||
| Pourquoi est-ce important ? Le suivi des pénuries de matériel est essentiel à l’analyse de leur incidence. Il permet de quantifier les retards dus aux problèmes d’approvisionnement et d’améliorer la planification du matériel. Où trouver ces données Cet événement est déduit de l’activation du statut « MSPT » (Material shortage) pour l’ordre de fabrication. L’horodatage de ce changement de statut figure dans la table JCDS. Données à recueillir Horodatage du changement de statut vers « MSPT » dans la table JCDS. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Vérification des prérequis : Assurez-vous de disposer d’un utilisateur SAP S/4HANA doté des autorisations nécessaires pour accéder aux vues Core Data Services (CDS) requises. Il s’agit notamment de
I_ProductionOrder,I_ProdOrdConfirmation,I_MaterialDocumentItem,I_ObjectStatusetI_ChangeDocument. Vous devez également avoir accès à un environnement d’exécution SQL connecté à la base de données SAP HANA, par exemple SAP HANA Studio, DBeaver ou un outil ETL externe. - Identification des détails du système : Notez l’identifiant du système source que vous utiliserez pour l’attribut
SourceSystem. Il s’agit d’un nom logique que vous définissez pour identifier l’origine des données, par exempleS4H_PROD. - Définition des paramètres d’extraction : Avant d’exécuter la requête, définissez les principaux paramètres : dates de début et de fin de la période d’extraction et filtres spécifiques, comme
PlantouProductionOrderType, pour limiter le périmètre des données. - Préparation de la requête SQL : Copiez la requête SQL complète fournie dans la section
querydans le client SQL ou l’outil d’extraction de données de votre choix. - Configuration des paramètres substituables : Remplacez les valeurs fictives de la requête par vos paramètres. Il s’agit notamment de
_StartDate,_EndDateet de l’identifiant du système source. Adaptez le seuil de l’événementUnplanned Halt Occurred(par exemple,'24:00:00') à votre contexte métier. - Exécution de la requête d’extraction : Exécutez le script SQL configuré sur la base de données du système SAP S/4HANA. Pour les grands volumes couvrant une longue période, envisagez de procéder par lots plus petits, par exemple mois par mois, afin d’éviter les problèmes de performance.
- Vérification initiale des données : Une fois la requête exécutée, examinez rapidement les résultats. Vérifiez le nombre de lignes, la présence de toutes les colonnes et la variété des événements attendus dans la colonne
Activité. - Validation des données : Suivez les étapes de la section
validationStepspour effectuer une validation plus approfondie. Comparez quelques ordres de production avec leurs détails dans le système SAP à l’aide de la transactionCO03, afin de confirmer l’exactitude du journal d’événements extrait. - Exportation au format CSV : Exportez le jeu de résultats final dans un fichier CSV. Vérifiez que l’encodage du fichier est UTF-8 pour éviter les problèmes de caractères.
- Préparation à l’importation : Vérifiez que les en-têtes des colonnes du fichier CSV correspondent aux noms d’attributs requis :
ProductionOrder,Activity,StartTime,SourceSystemetLastDataUpdate. Avant d’importer le fichier dans l’outil de Process Mining, vérifiez que la colonneStartTimeutilise un format d’horodatage standard, tel que ISO 8601 (YYYY-MM-DDTHH:MM:SS).
Configuration
- Vues CDS principales : L’extraction s’appuie principalement sur un ensemble de vues CDS standard qui présentent les tables SAP sous-jacentes de façon structurée et adaptée aux besoins métier. Les vues principales sont les suivantes :
I_ProductionOrder: données d’en-tête et événements de création.I_ProdOrdConfirmation: confirmations de toutes les opérations.I_MaterialDocumentItem: mouvements de marchandises, tels que les sorties et les réceptions.I_ObjectStatus: changements de statut de l’ordre de production.I_ChangeDocumentet les vues associées : modifications des principaux champs de l’ordre.
- Filtrage par période : Il est essentiel de filtrer les données par période afin d’en maîtriser le volume. La requête fournie utilise la date de création de l’ordre de production (
CreationDate). Pour une première analyse, une période de 3 à 6 mois est généralement adaptée. - Filtres métier principaux : Pour affiner le jeu de données, appliquez des filtres fondés sur les principaux attributs organisationnels ou de données de base. Les filtres courants sont les suivants :
Plant: analyse d’un site de production précis.ProductionOrderType: analyse ciblée de la production standard, des reprises ou d’autres types d’ordres.CompanyCode: limitation des données à une entité juridique précise.
- Seuil d’arrêt imprévu : La requête contient une logique permettant de déduire les événements
Unplanned Halt Occurred. Cette logique nécessite un seuil temporel pour définir l’intervalle significatif entre deux opérations. Définissez cette valeur en fonction des temps de cycle de production habituels et des règles métier. - Autorisations requises : L’utilisateur SAP qui exécute la requête doit disposer d’autorisations d’affichage pour toutes les vues CDS et les tables sous-jacentes. En l’absence des autorisations requises, le résultat sera vide ou incomplet.
Exemple de requête sql
WITH BaseOrders AS (
SELECT
ProductionOrder,
Material AS MaterialNumber,
ProductionPlant AS Plant,
CreationDate,
CreationTime,
BasicEndDate AS PlannedEndDate,
TechnicalCompletionDate,
LastChangeDateTime
FROM I_ProductionOrder
-- P_CreationDateFrom and P_CreationDateTo are placeholders for your date range
WHERE CreationDate BETWEEN '[_StartDate]' AND '[_EndDate]'
-- Add other filters as needed, for example:
-- AND ProductionPlant IN ('[Your_Plant_1]', '[Your_Plant_2]')
-- AND ProductionOrderType = '[Your_Order_Type]'
)
SELECT
bo.ProductionOrder,
'Production Order Created' AS Activity,
TO_TIMESTAMP(bo.CreationDate || ' ' || LPAD(bo.CreationTime, 6, '0'), 'YYYYMMDD HH24MISS') AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
'CRTD' AS OrderStatus
FROM BaseOrders bo
UNION ALL
-- System status changes like Released, Technically Completed, Closed, Cancelled, Material Shortage
SELECT
os.ObjectInternalID AS ProductionOrder,
CASE os.SystemStatus
WHEN 'I0002' THEN 'Production Order Released'
WHEN 'I0043' THEN 'Material Availability Checked' -- Status: MACM (Material committed)
WHEN 'I0045' THEN 'Order Technically Completed'
WHEN 'I0046' THEN 'Order Financially Closed'
WHEN 'I0047' THEN 'Production Order Cancelled'
WHEN 'I0010' THEN 'Material Shortage Occurred' -- Status: MSPT (Material shortage)
END AS Activity,
os.StatusChangeDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
os.SystemStatus AS OrderStatus
FROM I_ObjectStatus AS os
JOIN BaseOrders AS bo ON os.ObjectInternalID = bo.ProductionOrder
WHERE os.SystemStatus IN ('I0002', 'I0043', 'I0045', 'I0046', 'I0047', 'I0010') AND os.StatusIsInactive = ''
UNION ALL
-- Production Started, inferred from the first goods issue or first confirmation
SELECT
s.ProductionOrder,
'Production Started' AS Activity,
s.StartEventTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
s.MaterialNumber,
s.Plant,
NULL AS WorkCenter,
s.PlannedEndDate,
NULL AS OrderStatus
FROM (
SELECT
bo.ProductionOrder,
bo.MaterialNumber,
bo.Plant,
bo.PlannedEndDate,
MIN(COALESCE(gm.PostingTime, cf.ConfirmationDateTime)) AS StartEventTime,
ROW_NUMBER() OVER(PARTITION BY bo.ProductionOrder ORDER BY MIN(COALESCE(gm.PostingTime, cf.ConfirmationDateTime))) as rn
FROM BaseOrders bo
LEFT JOIN I_MaterialDocumentItem gm ON bo.ProductionOrder = gm.ProductionOrder AND gm.GoodsMovementType IN ('261', '262') -- Goods Issue
LEFT JOIN I_ProdOrdConfirmation cf ON bo.ProductionOrder = cf.ProductionOrder
WHERE gm.ProductionOrder IS NOT NULL OR cf.ProductionOrder IS NOT NULL
GROUP BY bo.ProductionOrder, bo.MaterialNumber, bo.Plant, bo.PlannedEndDate
) s
WHERE s.rn = 1
UNION ALL
-- Production Confirmation Entered (for each confirmation)
SELECT
cf.ProductionOrder,
'Production Confirmation Entered' AS Activity,
cf.ConfirmationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
cf.WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
UNION ALL
-- Final Confirmation Entered
SELECT
cf.ProductionOrder,
'Final Confirmation Entered' AS Activity,
cf.ConfirmationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
cf.WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
WHERE cf.IsFinalConfirmation = 'X'
UNION ALL
-- Unplanned Halt Occurred (derived from gaps between confirmations)
SELECT
ProductionOrder,
'Unplanned Halt Occurred' AS Activity,
PreviousConfirmationTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
MaterialNumber,
Plant,
WorkCenter,
PlannedEndDate,
NULL AS OrderStatus
FROM (
SELECT
cf.ProductionOrder,
bo.MaterialNumber,
bo.Plant,
bo.PlannedEndDate,
cf.WorkCenter,
cf.ConfirmationDateTime,
LAG(cf.ConfirmationDateTime, 1) OVER (PARTITION BY cf.ProductionOrder ORDER BY cf.ConfirmationDateTime) AS PreviousConfirmationTime,
(SECONDS_BETWEEN(LAG(cf.ConfirmationDateTime, 1) OVER (PARTITION BY cf.ProductionOrder ORDER BY cf.ConfirmationDateTime), cf.ConfirmationDateTime) / 3600.0) as HoursDiff
FROM I_ProdOrdConfirmation cf
JOIN BaseOrders bo ON cf.ProductionOrder = bo.ProductionOrder
) AS gaps
WHERE gaps.HoursDiff > 24 -- Configurable threshold in hours, e.g. 24 hours
UNION ALL
-- Goods Receipt Posted
SELECT
gm.ProductionOrder,
'Goods Receipt Posted' AS Activity,
gm.PostingTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
NULL AS OrderStatus
FROM I_MaterialDocumentItem gm
JOIN BaseOrders bo ON gm.ProductionOrder = bo.ProductionOrder
WHERE gm.GoodsMovementType = '101'
UNION ALL
-- Capacity Requirements Planned (using Release event as a proxy)
SELECT
os.ObjectInternalID AS ProductionOrder,
'Capacity Requirements Planned' AS Activity,
os.StatusChangeDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL AS WorkCenter,
bo.PlannedEndDate,
os.SystemStatus AS OrderStatus
FROM I_ObjectStatus AS os
JOIN BaseOrders AS bo ON os.ObjectInternalID = bo.ProductionOrder
WHERE os.SystemStatus = 'I0002' AND os.StatusIsInactive = '' -- Status 'REL' (Released)
UNION ALL
-- Production Plan Adjusted
SELECT
ch.ObjectValue AS ProductionOrder,
'Production Plan Adjusted' AS Activity,
ch.CreationDateTime AS StartTime,
'[_SourceSystemName]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
bo.MaterialNumber,
bo.Plant,
NULL as WorkCenter,
bo.PlannedEndDate,
NULL as OrderStatus
FROM I_ChangeDocument AS ch
JOIN BaseOrders bo ON ch.ObjectValue = bo.ProductionOrder
WHERE ch.ChangeDocumentObject = 'PRODORDER'
-- Monitoring changes in key fields like Total Quantity (GAMNG) or Basic Finish Date (GLTRP)
AND ch.FieldName IN ('GAMNG', 'GLTRP')
GROUP BY ch.ObjectValue, ch.CreationDateTime, bo.MaterialNumber, bo.Plant, bo.PlannedEndDate Étapes
- Vérifiez que vous avez un accès direct en lecture au schéma SAP HANA contenant les données des ordres de production. Identifiez le propriétaire du schéma, la gestion des clients, les conventions d’horodatage et le modèle d’autorisation. Utilisez SAP HANA Database Explorer ou un client SQL approuvé. Avant de finaliser la requête, vérifiez la version de SAP S/4HANA concernée et le périmètre de planification de la production activé.
- Configurez la chaîne de connexion, les identifiants, le nom du schéma, la valeur du client, les dates de début et de fin de l’extraction ainsi que les filtres propres à l’entreprise. La requête ci-dessous utilise AUFK, AFPO, JEST et JCDS, et fait également référence à AFKO, AFVC, AFRU, RESB, MSEG, CDHDR et CDPOS. Avant de l’exécuter, vérifiez que ces objets sont disponibles dans votre système et que leurs champs sont bien définis. Des extensions, des vues de compatibilité et des différences entre versions peuvent s’appliquer.
- Exécutez la requête dans SAP HANA Database Explorer ou dans votre outil d’exécution SQL approuvé. Elle crée une ligne pour chaque activité explicitement extraite et regroupe les lignes d’activité à l’aide de UNION ALL. ProcessMind n’est pas utilisé pour déduire les événements.
- Examinez les données sources et adaptez, si nécessaire, les expressions propres au système qui sont signalées. Vérifiez notamment les codes de statut utilisés pour la disponibilité des matériaux, la planification des capacités, la clôture technique, la clôture financière et l’annulation. Vérifiez également l’objet et les noms de champs des documents de modification utilisés pour repérer les ajustements du plan de production.
- Validez la conversion des horodatages et le filtrage des clients. Les systèmes SAP peuvent stocker les dates et les heures dans des champs distincts. Certaines installations utilisent l’UTC, d’autres l’heure locale du site ou du système. Veillez à ce que les valeurs
StartTimeobtenues utilisent toutes le même fuseau horaire et à exclure les dates SAP initiales ou non valides. - Exportez le résultat dans un fichier plat compatible avec ProcessMind, de préférence au format CSV ou en texte délimité UTF-8. Conservez exactement les noms de colonnes suivants : ProductionOrder, Activity, StartTime, SourceSystem, LastDataUpdate, MaterialNumber, Plant, WorkCenter, PlannedEndDate et OrderStatus.
- Triez les lignes exportées par ProductionOrder et StartTime. Si votre processus d’importation le permet, définissez un ordre secondaire déterministe pour les horodatages identiques. Conservez une ligne par événement, y compris les confirmations et changements de statut répétés lorsqu’ils correspondent à des enregistrements sources distincts.
- Importez le fichier dans ProcessMind et associez ProductionOrder à l’identifiant du cas, Activity à l’activité et StartTime à l’horodatage de l’événement. Selon la configuration d’importation de ProcessMind, associez les autres colonnes à des attributs d’événement ou de cas. Vérifiez que les 14 libellés d’activité sont conservés exactement comme la requête les produit.
Configuration
- Période : Commencez par une période glissante de trois à six mois. Pour les premiers essais, choisissez une période plus courte et ne l’étendez qu’après avoir vérifié le nombre de lignes et les performances de la requête.
- Paramètres d’extraction : Remplacez [Your schema name], [Your client], [Extraction start date], [Extraction end date] et [Your source system name] par les valeurs de votre environnement. N’appliquez des filtres propres à l’entreprise qu’après avoir vérifié les champs organisationnels et les valeurs concernés.
- Configuration des statuts : Vérifiez les codes de statut SAP exacts et les identifiants d’objet de statut utilisés dans votre système pour CRTD, la libération, la disponibilité des matériaux, la planification des capacités, la clôture technique, la clôture financière et l’annulation. Les profils de statut et les extensions personnalisées peuvent modifier les codes disponibles.
- Documents de modification : Vérifiez l’objet de document de modification des ordres de production, les noms des tables et des champs ainsi que les formats de valeurs utilisés pour les quantités, les dates, les nomenclatures et les gammes. La requête considère les enregistrements correspondants de CDHDR et CDPOS comme des preuves d’ajustement du plan.
- Gestion des horodatages : Harmonisez tous les horodatages sources selon un même fuseau horaire. Vérifiez si les champs de date et d’heure sont séparés, si les horodatages sont locaux ou en UTC, et comment les dates initiales sont représentées.
- Performances : Limitez l’extraction par date de création de l’ordre ou par une autre date d’ordre de production indexée, filtrez par client, sélectionnez uniquement les colonnes nécessaires et exécutez-la pendant une période adaptée aux traitements de reporting. Pour les grands volumes, procédez par mois ou par plage d’ordres de production et enregistrez les résultats au fur et à mesure.
- Objets de base de données : Vérifiez que AUFK, AFPO, JEST, JCDS, AFKO, AFVC, AFRU, RESB, MSEG, CDHDR et CDPOS sont disponibles et accessibles en lecture dans le schéma sélectionné. Si une vue ou un champ diffère dans votre version, remplacez-le par l’objet correspondant, publié ou approuvé.
- Autorisations : L’accès requis comprend les droits de lecture sur le schéma et les objets SAP HANA sélectionnés, ainsi que l’autorisation d’exécuter des requêtes SQL. Votre processus de gouvernance peut également exiger des autorisations SAP au niveau applicatif.
- Périmètre fonctionnel : Les données de planification et d’exécution de la production, les mouvements de stock, l’historique des statuts et les documents de modification doivent être conservés pour la période sélectionnée. Les enregistrements archivés ou supprimés ne seront pas renvoyés.
- Association dans ProcessMind : Configurez ProductionOrder comme identifiant du cas, Activity comme activité et StartTime comme horodatage de l’événement. Ne comptez pas sur ProcessMind pour déduire les activités manquantes à partir des attributs.
Exemple de requête sql
WITH
params AS (
SELECT
'[Your client]' AS mandt,
TO_DATE('[Extraction start date]', 'YYYY-MM-DD') AS date_from,
TO_DATE('[Extraction end date]', 'YYYY-MM-DD') AS date_to,
'[Your source system name]' AS source_system,
CURRENT_UTCTIMESTAMP AS last_data_update
FROM DUMMY
),
orders AS (
SELECT
a.mandt,
LTRIM(a.aufnr, '0') AS production_order,
a.aufnr AS production_order_raw,
a.erdat AS order_created_date,
a.erfzeit AS order_created_time,
a.auart AS order_type,
a.werks AS plant,
a.objnr AS object_number,
a.ktext AS order_text,
p.matnr AS material_number,
p.psmng AS planned_quantity,
p.wemng AS delivered_quantity,
k.gstrp AS planned_start_date,
k.gltrp AS planned_end_date,
k.ftrmi AS release_date,
k.ftrmp AS release_time,
k.gamng AS total_order_quantity,
k.plnbez AS header_material_number,
k.plnty AS task_list_type,
k.plnnr AS task_list_group,
k.plnal AS task_list_group_counter
FROM [Your schema name].AUFK a
LEFT JOIN [Your schema name].AFPO p
ON p.mandt = a.mandt
AND p.aufnr = a.aufnr
LEFT JOIN [Your schema name].AFKO k
ON k.mandt = a.mandt
AND k.aufnr = a.aufnr
CROSS JOIN params x
WHERE a.mandt = x.mandt
AND a.erdat >= x.date_from
AND a.erdat < ADD_DAYS(x.date_to, 1)
),
status_history AS (
SELECT
o.*,
j.stat,
j.inact,
j.chgnr,
j.udate AS status_date,
j.utime AS status_time,
c.usnam AS status_user,
c.chind AS status_change_indicator
FROM orders o
INNER JOIN [Your schema name].JEST j
ON j.mandt = o.mandt
AND j.objnr = o.object_number
LEFT JOIN [Your schema name].JCDS c
ON c.mandt = j.mandt
AND c.objnr = j.objnr
AND c.stat = j.stat
AND c.chgnr = j.chgnr
WHERE COALESCE(j.inact, '') <> 'X'
),
operations AS (
SELECT
o.production_order,
o.mandt,
v.vornr,
v.arbid,
v.steus,
v.ltxa1,
v.aufpl,
v.aplzl,
cr.name1 AS work_center
FROM orders o
LEFT JOIN [Your schema name].AFVC v
ON v.mandt = o.mandt
AND v.aufpl = (SELECT MAX(k2.aufpl) FROM [Your schema name].AFKO k2 WHERE k2.mandt = o.mandt AND k2.aufnr = o.production_order_raw)
LEFT JOIN [Your schema name].CRHD cr
ON cr.mandt = v.mandt
AND cr.objty = 'A'
AND cr.objid = v.arbid
),
confirmations AS (
SELECT
o.production_order,
o.mandt,
r.rmzhl,
r.vornr,
r.budat AS confirmation_date,
r.ersda AS entry_date,
r.erzet AS entry_time,
r.ism01,
r.ism02,
r.ism03,
r.ism04,
r.ism05,
r.ism06,
r.xmnga,
r.stzhl,
r.stzhl AS reversal_counter,
r.lmnga AS confirmed_quantity,
r.xmnge AS scrap_quantity,
r.aufpl,
r.aplzl,
op.work_center
FROM orders o
INNER JOIN [Your schema name].AFRU r
ON r.mandt = o.mandt
AND r.aufnr = o.production_order_raw
LEFT JOIN operations op
ON op.production_order = o.production_order
AND op.mandt = r.mandt
AND op.vornr = r.vornr
),
first_confirmation AS (
SELECT production_order, MIN(TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS')) AS start_time
FROM confirmations
GROUP BY production_order
),
last_confirmation AS (
SELECT production_order, MAX(TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS')) AS final_time
FROM confirmations
GROUP BY production_order
),
first_goods_issue AS (
SELECT
o.production_order,
MIN(TO_TIMESTAMP(TO_VARCHAR(m.budat_mkpf, 'YYYYMMDD') || LPAD(TO_VARCHAR(m.cputm_mkpf), 6, '0'), 'YYYYMMDDHH24MISS')) AS start_time
FROM orders o
INNER JOIN [Your schema name].MSEG m
ON m.mandt = o.mandt
AND m.aufnr = o.production_order_raw
AND m.bwart IN ('261', '262')
GROUP BY o.production_order
),
first_receipt AS (
SELECT
o.production_order,
MIN(TO_TIMESTAMP(TO_VARCHAR(m.budat_mkpf, 'YYYYMMDD') || LPAD(TO_VARCHAR(m.cputm_mkpf), 6, '0'), 'YYYYMMDDHH24MISS')) AS receipt_time
FROM orders o
INNER JOIN [Your schema name].MSEG m
ON m.mandt = o.mandt
AND m.aufnr = o.production_order_raw
AND m.bwart IN ('101', '102')
GROUP BY o.production_order
),
plan_changes AS (
SELECT
o.production_order,
MIN(TO_TIMESTAMP(TO_VARCHAR(h.udate, 'YYYYMMDD') || LPAD(TO_VARCHAR(h.utime), 6, '0'), 'YYYYMMDDHH24MISS')) AS adjustment_time
FROM orders o
INNER JOIN [Your schema name].CDHDR h
ON h.mandant = o.mandt
AND h.objectid = o.production_order_raw
INNER JOIN [Your schema name].CDPOS p
ON p.mandant = h.mandant
AND p.objectclas = h.objectclas
AND p.objectid = h.objectid
AND p.changenr = h.changenr
WHERE h.objectclas IN ('ORDER', 'PP_ORDER')
AND p.tabname IN ('AFKO', 'AFPO', 'AFVC', 'RESB')
AND p.fname IN ('GAMNG', 'PSMNG', 'GSTRP', 'GLTRP', 'MATNR', 'BDMNG', 'VORNR')
GROUP BY o.production_order
),
status_times AS (
SELECT
production_order,
MIN(CASE WHEN stat IN ('I0001', 'CRTD') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS created_status_time,
MIN(CASE WHEN stat IN ('I0002', 'REL') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS released_time,
MIN(CASE WHEN stat IN ('I0003', 'MATC', 'MANC') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS material_available_time,
MIN(CASE WHEN stat IN ('I0004', 'CAPC', 'CAPA') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS capacity_planned_time,
MIN(CASE WHEN stat IN ('I0045', 'TECO') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS technically_completed_time,
MIN(CASE WHEN stat IN ('I0046', 'CLSD') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS financially_closed_time,
MIN(CASE WHEN stat IN ('I0076', 'DLFL', 'CANC') THEN TO_TIMESTAMP(TO_VARCHAR(status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(status_time), 6, '0'), 'YYYYMMDDHH24MISS') END) AS cancelled_time
FROM status_history
GROUP BY production_order
),
material_shortages AS (
SELECT
o.production_order,
MIN(TO_TIMESTAMP(TO_VARCHAR(j.status_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(j.status_time), 6, '0'), 'YYYYMMDDHH24MISS')) AS shortage_time
FROM status_history j
INNER JOIN orders o
ON o.production_order = j.production_order
WHERE j.stat IN ('I0042', 'MANC', 'MSHT')
GROUP BY o.production_order
),
capacity_times AS (
SELECT
production_order,
MIN(COALESCE(released_time, created_status_time)) AS capacity_time
FROM status_times
GROUP BY production_order
),
base_attributes AS (
SELECT
o.production_order,
o.material_number,
o.plant,
COALESCE(op.work_center, '') AS work_center,
o.planned_end_date,
COALESCE(st.stat, '') AS current_status
FROM orders o
LEFT JOIN status_history st
ON st.production_order = o.production_order
AND st.inact = ''
LEFT JOIN operations op
ON op.production_order = o.production_order
AND op.vornr = (SELECT MIN(op2.vornr) FROM operations op2 WHERE op2.production_order = o.production_order)
),
events AS (
SELECT o.production_order, 'Production Order Created' AS activity, COALESCE(st.created_status_time, TO_TIMESTAMP(TO_VARCHAR(o.order_created_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(o.order_created_time), 6, '0'), 'YYYYMMDDHH24MISS')) AS start_time FROM orders o LEFT JOIN status_times st ON st.production_order = o.production_order
UNION ALL
SELECT production_order, 'Material Availability Checked', material_available_time FROM status_times WHERE material_available_time IS NOT NULL
UNION ALL
SELECT production_order, 'Capacity Requirements Planned', capacity_time FROM capacity_times WHERE capacity_time IS NOT NULL
UNION ALL
SELECT production_order, 'Production Order Released', released_time FROM status_times WHERE released_time IS NOT NULL
UNION ALL
SELECT o.production_order, 'Production Started', LEAST(COALESCE(fc.start_time, TO_TIMESTAMP('99991231235959', 'YYYYMMDDHH24MISS')), COALESCE(fg.start_time, TO_TIMESTAMP('99991231235959', 'YYYYMMDDHH24MISS'))) FROM orders o LEFT JOIN first_confirmation fc ON fc.production_order = o.production_order LEFT JOIN first_goods_issue fg ON fg.production_order = o.production_order WHERE fc.start_time IS NOT NULL OR fg.start_time IS NOT NULL
UNION ALL
SELECT production_order, 'Production Confirmation Entered', TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS') FROM confirmations
UNION ALL
SELECT production_order, 'Material Shortage Occurred', shortage_time FROM material_shortages WHERE shortage_time IS NOT NULL
UNION ALL
SELECT production_order, 'Production Plan Adjusted', adjustment_time FROM plan_changes WHERE adjustment_time IS NOT NULL
UNION ALL
SELECT c.production_order, 'Unplanned Halt Occurred', ADD_SECONDS(c.confirmation_time, 1) FROM (SELECT production_order, TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS') AS confirmation_time, LEAD(TO_TIMESTAMP(TO_VARCHAR(entry_date, 'YYYYMMDD') || LPAD(TO_VARCHAR(entry_time), 6, '0'), 'YYYYMMDDHH24MISS')) OVER (PARTITION BY production_order ORDER BY entry_date, entry_time, rmzhl) AS next_confirmation_time FROM confirmations) c WHERE c.next_confirmation_time IS NOT NULL AND SECONDS_BETWEEN(c.confirmation_time, c.next_confirmation_time) >= 86400
UNION ALL
SELECT production_order, 'Final Confirmation Entered', final_time FROM last_confirmation WHERE final_time IS NOT NULL
UNION ALL
SELECT production_order, 'Goods Receipt Posted', receipt_time FROM first_receipt WHERE receipt_time IS NOT NULL
UNION ALL
SELECT production_order, 'Order Technically Completed', technically_completed_time FROM status_times WHERE technically_completed_time IS NOT NULL
UNION ALL
SELECT production_order, 'Order Financially Closed', financially_closed_time FROM status_times WHERE financially_closed_time IS NOT NULL
UNION ALL
SELECT production_order, 'Production Order Cancelled', cancelled_time FROM status_times WHERE cancelled_time IS NOT NULL
)
SELECT
e.production_order AS "ProductionOrder",
e.activity AS "Activity",
e.start_time AS "StartTime",
p.source_system AS "SourceSystem",
p.last_data_update AS "LastDataUpdate",
b.material_number AS "MaterialNumber",
b.plant AS "Plant",
NULLIF(b.work_center, '') AS "WorkCenter",
b.planned_end_date AS "PlannedEndDate",
b.current_status AS "OrderStatus"
FROM events e
INNER JOIN base_attributes b
ON b.production_order = e.production_order
CROSS JOIN params p
WHERE e.start_time IS NOT NULL
ORDER BY e.production_order, e.start_time, e.activity; Prêt à commencer ?
Faites le premier pas vers une planification de la production plus efficace. Préparez vos données à l’aide de ce modèle et obtenez des analyses utiles pour optimiser le processus.
Optimisez dès aujourd’hui votre planification de la production
Repérez et éliminez les goulots d’étranglement, et réduisez de 30 % le temps de cycle de production.
Aucune carte bancaire requise