resolution du cas dsi normes cigref 1 -...

Copyright Expertizers 2014

RESOLUTION DU CAS DSI SELON LA NORMALISATION DU CIGREF

1. INTRODUCTION

Avant de découvrir la résolution du cas DSI, le lecteur est invité à prendre connaissance du document ‘Analyse_et_benchmarking_des_couts_informatiques_CIGREF_2009.pdf’ disponible sur internet en tapant simplement le nom du document.

A défaut, voici une synthèse introductive qui avec vos connaissances de l’ABC devrait suffire.

La démarche du CIGREF repose sur la valorisation des SERVICES mis à disposition de la DSI au travers d’une démarche ABC, s’appuyant sur un modèle d’activités standardisé.

L’objectif du CIGREF est d’obtenir une SEULE base d’information qui regroupe les différentes vues des coûts de la DSI.

Comme le dit le document du CIGREF en page 11, « certains souhaitent connaître le coût récurrent de l’infrastructure et des applications mises à la disposition de la DSI, ces coûts intégrant les amortissements des matériels, des logiciels et des projets immobilisés. D’autres, souhaiteront connaître les coûts d’investissement relatifs aux projets, ces coûts intégrant les acquisitions de serveurs et de logiciels au-delà des jours hommes et des forfaits de sous-traitance »

C’est ainsi que la base de données à constituer doit fournir deux axes différents d’analyse. « Une vue ‘P&L’ (ou compte de résultat), la quote-part d’amortissement d’un serveur sera affectée à la mise à disposition d’un service alors que dans une vue ‘CASHOUT’ le montant total d’acquisition de ce même serveur sera affecté au projet dans le cadre duquel il a été acheté »

Aussi, pour disposer d’analyses comparatives entre années (vue ‘P&L’) et suivre le coût global de projets programmés sur plusieurs années (vue ‘CASHOUT’), il est indispensable de rassembler les résultats de chaque année traitée dans un environnement infocentre d’historisation.

De ces objectifs et définitions, nous voyons bien à quel point la comptabilité est sollicitée pour fournir par nature et dans un cadre annuel, non seulement les comptes de dotations aux amortissements de fin d’année mais aussi les comptes retraçant toute l’activité d’achat de l’année, immobilisés ou non.

La base du travail fonctionnel au niveau comptable est donc d’inventorier dans le périmètre d’une année comptable, les comptes et leurs mouvements en rapport avec la DSI, qu’ils soient de type ‘P&L’ et / ou ‘CASHOUT’, pour les déverser dans les 39 activités normalisées du CIGREF.

Cela relève d’un travail méthodique propre à chaque organisation considérée. Chaque compte (général ou analytique) doit être clairement classifié de type ‘P&L’ et / ou ‘CASHOUT’ pour que les schémas de déversement restent homogènes, affectant les charges sur les activités en conservant la différenciation ‘P&L’ et / ou ‘CASHOUT’


Ainsi, bien que les tableaux pages 16 et 17 du document du CIGREF rattachent chaque activité aux natures ‘P&L’ et / ou ‘CASHOUT’, nous trouvons judicieux dans le cadre de la mise en œuvre de codifier plus précisément chaque activité ainsi :

CODE_ACTIVITE_PEL activités regroupant des comptes de nature ‘P&L’

CODE_ACTIVITE_CASH activités regroupant des comptes de nature ‘CASHOUT’

CODE_ACTIVITE activités regroupant des comptes communs aux vues ‘P&L’ et ‘CASHOUT’.

Evidemment, cela génère une certaine démultiplication des activités, mais elle se révèle utile dès lors que les charges d’une activité de même nom, mais de vues différentes P&L / CASH, se répartissent sur les SERVICES par des totalisations distinctes de comptes et / ou d’unités d’œuvre.

Un autre point important à préciser, concerne le niveau de développement des données analytiques.

Quand l’organisation dispose d’applications de suivi, notamment de temps et de fréquence, elle peut alimenter la comptabilité analytique de charges affectées directement au niveau du couple ACTIVITE/ SERVICE ; Voir même de critères d’affectation à l’organisation pour simplifier la refacturation. En conséquence, nul besoin de faire passer ces écritures par la moulinette de répartition Compte -> Activité -> Service -> (organisation éventuelle), si c’est déjà fait.

Cela revient donc à dire qu’il doit exister une entrée de données comptables, de type ‘déjà réparties’, distincte de l’entrée des comptes à répartir.

Là aussi nous trouvons judicieux dans le cadre de la mise en œuvre de codifier plus précisément chaque activité ainsi :

CODE_ACTIVITE_PEL_CDR Comptes P&L Déjà Répartis sur le couple ACTIVITE / SERVICE

CODE_ACTIVITE_CASH_CDR Comptes CASH Déjà Répartis sur le couple ACTIVITE / SERVICE

CODE_ACTIVITE_CDR Comptes communs Déjà Répartis sur le couple ACTIVITE / SERVICE

La résultante est certes de démultiplier les activités, mais nous sommes persuadés que la mise en œuvre n’en sera que plus simple et le tout, plus facilement auditable.

Les analyses consolidées ne seront pas plus complexes, si l’environnement d’analyse est complété de critères de regroupement reprenant de façon séparée les différentes concepts de CODE_ACTIVITE, vue P&L, vue CASH à des fins de sélection rapide.


2. DESCRIPTION DE LA MISE EN ŒUVRE AVEC EXPERTIZERS

Comme le souhaite le CIGREF, l’objectif d’EXPERTIZERS est bien de produire une seule matrice de résultats pour une analyse immédiate des coûts de la DSI tant en vision P&L qu’en vision CASHOUT.

La méthodologie EXPERTIZERS dans son existant est en mesure de satisfaire les objectifs du CIGREF, même si pour des raisons de clarté on peut se demander s’il n’est pas préférable de composer deux architectures distinctes, l’une traitant de la vision P&L et l’autre de la vision CASHOUT malgré le recouvrement redondant de certains comptes.

En effet, rien n’empêche ensuite de mêler les deux visions dans une base commune d’infocentre. L’utilisateur ne verra aucune différence.

La question reste donc posée, et à chaque organisation, en fonction de la complexité et de l’importance du domaine informatique couvert, de décider de ce choix.

En dehors de quelques aménagements fonctionnels et de nouvelles fonctions simples développées au contact de situations rencontrées sur le terrain des coûts informatiques, l’architecture standard proposée par EXPERTIZERS reste identique à celle décrite dans les documents de formation et de présentation générale de la méthode. A savoir un modèle comptable de déversement des comptes sur les activités, et un modèle métier dont l’objectif principal reste le traitement et la valorisation des évènements métiers porteurs des SERVICES, des données d’unités d’œuvre et éventuellement de critères organisationnels (objectif secondaire de refacturation des SERVICES).

Mais comme les évènements comptables et les évènements métiers ne sont pas nécessairement porteurs des critères de consommation des SERVICES par les ORGANISATIONS, nous vous décrirons comment concevoir un troisième modèle à cet effet.

Sa vocation sera de traiter et de valoriser un fichier d’évènements détaillé sur des critères organisationnels et porteur d’unités d’œuvre de consommation de SERVICES et non plus d’unités d’œuvre de consommation d’activités. Le coût global de chaque SERVICE étant récupéré par extraction du précédent modèle métier de calcul du coût des SERVICES par ACTIVITE.

2.1 DE QUELQUES AMENAGEMENTS FONCTIONNELS ET TECHNIQUES …

2.1.1 MODELE COMPTABLE (Déversement des COMPTES sur les ACTIVITES)

Le descriptif de base des évènements comptables (comptes de comptabilité générale et analytique) se limite aux cinq variables prédéfinies dans le modèle vierge model_v1_ex1: entity, period, product_code, event_code, quantity_init.


La colonne event_code (50 caractères) est destinée aux comptes (code du compte, ou code + libellé réduit), la colonne quantity_init reçoit la valeur de chaque compte (positive = charge, négative = produit).

Bien que le modèle comptable fonctionne en multi entités, multi périodes, nous raisonnerons dans le cadre des coûts informatiques, sur le principe d’une entité unique (obligatoire) et d’une période unique (laissée à blanc, ou avec l’année reproduite sur toutes les lignes de comptes).

Sachez aussi que la colonne product_code (30 caractères) accepte toute information qui vous serait utile, et est véhiculée dans la matrice (Résultat / Lot par activité + données évènements) des lignes de comptes par activité ACCOUNT_EVENTS_BY_ACTIVITY, de même que vous la retrouverez dans la matrice BUSINESS_EVENTS_BY_ACCOUNT (vue des évènements métier par activités et comptes d’origine) issue de la fusion de la matrice ACCOUNT_EVENTS_BY_ACTIVITY (modèle comptable) et de la matrice BUSINESS_EVENTS_BY_ACTIVITY (modèle métier).

Rien ne vous empêche, d’ajouter d’autres colonnes aux évènements du modèle comptable, à droite de la colonne quantity_init. Les données seront véhiculées dans la matrice de résultats ACCOUNT_EVENTS_BY_ACTIVITY, mais sans être reprises dans l’intégration des coûts dans le modèle métier, dont la seule donnée prise en compte est le coût total par ACTIVITE.

2.1.2 RECALCUL DES RESTES COMPTABLES EN ENTREE D’UN MODELE COMPTABLE

L’expérience engrangée sur l’élaboration des règles de répartition des comptes sur les activités a montré l’intérêt de procéder de façon rigoureuse à la mise en place de l’arborescence des coûts de la DSI, notamment de conserver une vision constante de la masse globale à répartir d’un compte, en offrant la possibilité de subdiviser la position du compte entre éléments fixes et éléments variables.


Ainsi par exemple, si la position du compte de charge ‘681 Amortissements logiciels’ est de 200.000 €, mais qu’une partie du compte est directement affectable à certaines activités, le contrôleur de gestion souhaite s’éviter de calculer le reste à répartir vers d’autres activités.

Figure 1 : Voici des données côté arborescence de répartition des comptes sur les activités:

Figure 2 : Voici des données côté fichier des évènements comptables :

En créant la colonne multi_account_lines dans le descriptif du fichier d’évènements (format varchar de 20 caractères), la phase de chargement du fichier d’évènements comptables se complétera automatiquement de la fonction suivante :

Parmi les lignes contenant une valeur dans la colonne multi_account_lines (ici 681 aurait pu être saisi sur n’importe quelle ligne, y compris sur toutes), recherche au début de la colonne event_code du compte 681, de la ligne au plus fort coût (soit 200.000), totalisation des autres lignes (soit 70.000), puis remplacement sur la ligne au plus fort coût de la valeur restante (soit 130.000). Ainsi sur tous comptes, les données issues de la comptabilité sont automatiquement recalculées en tenant compte des lignes ajoutées qui correspondent à des affectations directes.

NB : 681 est un exemple. Le compte doit former un seul bloc alphanumérique sans blanc, soit 681, 681010, 681_10,…). La seule contrainte est qu’il existe un blanc ou un caractère underscore _ entre le compte et le libellé associé (exemple des lignes des figures 1 et 2)


Figure 3 : Voici la situation du modèle après la création de la variable multi_account_lines, puis le chargement du fichier (figure 1) de l’arborescence de répartition des comptes sur les activités (Menu auto.génération + file loading + Model generation)

Figure 4 : Résultat de la colonne quantity_init recalculée après le chargement (Menu Lot_batch / Charger les évènements / fichier simple) du fichier (figure 2) des évènements comptables

La ligne est passée de 200000 à 130000, soit (200000 – (20000 + 30000 + 20000)


2.1.3 MODELE COMPTABLE. QUELS COMPTES TRAITER DANS CE MODELE ?

La formation à la méthode EXPERTIZERS avec ses études de cas associées insiste sur l’utilisation du modèle comptable comme un puissant répartiteur des charges indirectes sur les activités. La répartition de ces coûts s’appuie généralement sur des unités d’œuvre (%, m2, nombre de,…) plutôt stables donc faciles à réviser en modifiant le fichier externe de génération de l’arborescence des coûts, qui fonctionne sans aucune limite de niveaux, et dont l’algorithme de chargement agence automatiquement les niveaux dans une organisation linéaire pour un traitement séquentiel.

Il faut plutôt voir dans le modèle dit comptable, un générateur générique d’arborescence traitant de coûts de toutes natures, mais pas seulement comme un point d’entrée unique des données comptables.

Ainsi, le traitement des coûts informatiques, lié à leur diversité et à leur application analytique très poussée nous amène à prévoir deux aménagements particuliers.

Un premier aménagement,

Qui est lié à l’existence fréquente dans la gestion des coûts informatique d’une forte organisation analytique déjà en mesure de fournir directement les coûts sur le couple ACTIVITE / (SERVICE ou PRODUIT).

Ce flux de coûts déjà affectés au niveau ACTIVITE / SERVICE n’a donc pas besoin d’être réparti.

En conséquence, nous allons faire une entorse sur la manière de traiter ce flux comptable déjà affecté par ACTIVITE / SERVICE. Nous le considérerons tout simplement comme des lignes d’évènements métiers déjà valorisés, ce qui d’ailleurs n’est pas faux du tout. Les lignes transiteront donc dans le flux des évènements du modèle métier (cf chapitre 2.1.4).

Pour conserver la maîtrise des masses comptables (tant en vision P&L que CASHOUT), le contrôleur de gestion devra s’assurer que la somme des deux flux (à répartir et déjà affectés) reste bien égale au total des données comptables de la DSI.

Un deuxième aménagement,

Qui découle de la diversité de répartition et d’analyse des coûts de prestation sur les activités d’une DSI.

En général les projets de toutes sortes (techniques, applicatifs, évolutifs,…), avec un personnel interne et / ou externe, sont suivis par des comptes rendus d’activité.

La DSI maîtrise les évènements de prestation par le comptage des heures de prestation, dans un découpage très détaillé : CATEGORIE DE PERSONNEL, SERVICE, PROJET ET ACTIVITES. Les activités de prestation sont normalisées par le CIGREF (MAICOR, SUPNI1, PILPRO, DEPPRO,…).


La solution consistera ici à utiliser le modèle comptable pour décrire l’arborescence des multiples comptes de charge du personnel, mais à s’en tenir au niveau de regroupement intermédiaire PERSONNEL INTERNE, PERSONNEL EXTERNE.

Ensuite, par la mise en œuvre d’une nouvelle fonctionnalité, décrite au chapitre 2.1.5, c’est à travers le modèle métier que se produira l’affectation des coûts au niveau des activités terminales normalisées du CIGREF.

2.1.4 INCORPORATION DIRECTE DANS UN MODELE METIER D’EVENEMENTS DEJA VALORISES Ce chapitre est relatif à la mise en œuvre du premier aménagement du chapitre 2.1.3

Figure 5 : Description du fichier d’évènements du modèle métier

Figure 6 : Données du fichier d’évènements (CDR = Comptes déjà répartis)

Figure 7 : Activités et règles d’activité


Figure 8 : Résultat après traitement des évènements (Menu / Lot_batch / Chargement puis process)

NB : La dernière ligne d’évènement (ligne 7 du fichier) n’a pas été traitée. Pourquoi ?

2.1.5 REPARTITION DU COÛT D’UNE ACTIVITE DU MODELE COMPTABLE SUR PLUSIEURS ACTIVITES D’UN MODELE METIER

Ce chapitre est relatif à la mise en œuvre du deuxième aménagement du chapitre 2.1.3

C’est en prenant exemple sur les masses PERSONNEL_INTERNE et PERSONNEL_EXTERNE d’un modèle comptable que la procédure est décrite.

Figures 9 : En illustration, voici les fichiers d’exemple et de résultats du modèle comptable.


Figure 10 : Menu Résultats / ‘Totaux par period,activity’ ou ‘totaux par activity’ + export pour leur future intégration dans le modèle métier.

Figure 11 : Description du fichier d’évènements du modèle métier.

Quelques explications : Nous avons conservé le modèle métier des évènements déjà valorisés, en ajoutant simplement les variables relatives aux projets : nature de prestation et nombre de jours de prestation. Nous avons aussi élargi la nature des évènements à celle de ‘PROJET’ (cf valeurs associées à la variable nature_évènement.. Ainsi le modèle est en mesure de traiter les diverses natures d’évènements rassemblées dans un fichier unique.

Figure 12 : Fichier d’évènements métier incorporant les lignes CDR et PROJET


Figure 13 : Liste des activités après leur création et leurs règles de calcul

NB : Au passage vous noterez sur la gauche que les deux activités ACQPRO_ sont grisées. Nous les avons désactivées (Menu / Utilitaires / Désactivation Réactivation des activités) pour nous focaliser sur le traitement des activités de nature PROJET.

Figure 14 : Résultat après chargement puis traitement du fichier des évènements

L’objectif est maintenant de vous montrer comment vont s’appliquer ‘particulièrement’ le coût des pseudo-activités PERSONNEL_EXTERNE et PERSONNEL_INTERNE exportées avec toutes les autres activités (s’il y en avait) du modèle comptable (cf Figure 10).

L’aménagement de la fonction a consisté à utiliser la quatrième zone de regroupement (prévue pour les analyses d’activités) en établissant un lien entre les pseudo-activités du modèle comptable et les activités du modèle métier réceptrices des coûts au prorata de leur unité d’œuvre (dans notre cas, le nombre de jours de prestation).


Figure 15 : Saisie rapide des données d’analyse d’activités (Menu / Utilitaires / Mise à jour rapide des activités ‘écran + export)

NB : Attention à taper correctement les liens (exemple : PERSONNEL_EXTERNE et non PERSONNEL EXTERNE) car sinon le lien établi ne fonctionnera pas.

C’est ensuite au cours du lancement de la procédure d’intégration des coûts du modèle comptable dans le modèle métier (Menu Lot_Batch / Charger un fichier des coûts / Charger coûts par fichier entité, période, activité OU Charger coûts par fichier ACCOUNTING_EVENTS_BY_ACTIVITY) que la procédure détecte les liens établis et vous informe du traitement particulier mis en œuvre.

Figure 16 : Message de détection d’activités à répartir sur d’autres activités du modèle métier

Figure 17 : En fin de procédure, un message vous informe du résultat de l’intégration de tous les coûts rapportés du modèle comptable. Complété ensuite (fig 18) d’un compte rendu par activité.


Figure 18 : Affichage des résultats d’intégration consolidés par activité. (Retour possible à la liste par Lot_Batch / Charger un fichier des coûts / Lister les coûts par activité)

NB : Nous vous laissons le soin d’analyser les résultats ci-dessus ! Quand des coûts d’activité ne ‘matchent pas’ avec des activités du modèle métier (en dehors des activités liées avec le groupement GP4), la quatrième colonne ‘Match activity’ prend la valeur ‘NOMATCH’, expliquant partiellement ou totalement les écarts d’intégration. Quant à la colonne ‘Cost From rules’, elle est destinée à rappeler les coûts éventuellement calculés par règle dans le modèle métier. Figure 19 : Affichage des lignes d’évènement par activité (Menu résultats / Lot par activité OU Lot par activité + données évènements ‘table BUSINESS_EVENTS_BY_ACTIVITY’)

Remarque finale : De par la nature directe du coût de l’heure de prestation (dès lors qu’elle inclut toutes les charges annexes, intéressement, congés payés,…), nous aurions pu obtenir le même résultat par la saisie directe dans deux variables du coût unitaire (moyen ou standard) de l’heure de prestation. En fait toutes les techniques d’établissement des coûts, et donc de l’architecture de la modélisation, dépendent éminemment du contexte ‘budget’ ou ‘réalisé’ de l’étude menée, et aussi des choix techniques décidés par le contrôleur de gestion.


2.1.6 REPARTITION DE PROJETS SUR D’AUTRES PROJETS

Nous avons été confrontés à des évènements métiers de type ‘PROJET’ dont les coûts de prestation doivent en fait se répercuter par pourcentage sur d’autres projets.

La résolution met en œuvre le fichier des matières dont l’utilisation est très générique.

L’accès au fichier des matières et à ses variables est obtenu par le choix Menu Utilitaires / Activer l’utilisation du fichier des matières.

Pour simplifier la connaissance de son contenu et du colonage des variables, vous disposez dans le répertoire Expertizers/Import du fichier material_list.txt. En ouvrant le fichier à partir d’excel vous récupérez ainsi le bandeau d’entête, vous servant à saisir vos propres données.

Figure 20 : Structure des données du fichier des matières, adaptées au besoin à satisfaire

Compréhension du contenu : Le projet P1854 se déverse sur trois autres projets (mat_code) dans les proportions (mat_qty) 15%, 37%, 48%. L’objectif est donc que toute ligne d’évènement de prestation du projet P1854 s’éclate sur les trois projets, tant en nombre d’heures qu’en coût. La colonne mat_comment référence le service concerné.

Chargement du fichier matières : Menu Lot_Batch / Charger un fichier des matières / Charger (Administrateur). Vous reporter si besoin au document 1 de formation express (chapitre 18).

Pour atteindre l’objectif, l’aménagement a simplement consisté à débrider l’accès au fichier des matières qui jusqu’à présent générait systématiquement une erreur dès lors que la clé d’accès (material_group) ne ‘matchait’ pas (Nomatch) avec la donnée d’évènement mise en lien.

Pour gérer la nouvelle option, tout en conservant l’option par défaut de génération d’erreur, il a suffit d’ajouter un paramètre qui se situe au tout début de la règle de condition d’entrée de l’activité liée au fichier matières.

Ainsi l’expression conditionnelle Entity <> ‘’ (deux simples quotes sans blanc) signifie l’acceptation du cas de ‘nomatch’, avec malgré tout le traitement et l’écriture de la ligne d’activité de l’évènement.

Pour illustrer ce comportement, nous allons d’abord mettre à jour toutes les activités relatives à la nature ‘PROJET’, puis ensuite nous relancerons le traitement du fichier d’évènements pour apprécier le résultat obtenu.


Figure 21 : Ecran d’affichage et de modification d’une activité

Commentaires : La variable en lien avec la clé ‘material group’ du fichier des matières est la variable EVENT_CODE qui contient le code projet de la ligne d’évènement. La zone ‘where condition’ est complétée à son début de entity <> ‘’ , ainsi l’absence de correspondance ne générera pas d’erreur L’absence de correspondance fait que la variable mat_code (projet de réaffectation) reste à blanc, ce qui permet de gérer les deux situations (Match / Nomatch) en testant mat_code = ‘’ Product_code du fichier d’évènements contient la notion de SERVICE, mat_qty contient le % de répartition mat_comment contient le SERVICE associé au projet de réaffectation. L’affectation du lien EVENT_CODE n’est possible que sur l’écran individuel d’affichage d’une activité. En revanche la modification des règles et leur duplication est très rapide en passant par l’option Fullscreen (multi activités) en se plaçant sur le paragraphe Activities de l’arborescence + click droit souris (MàJ plein écran)


Figure 22 : Résultat après chargement et traitement des évènements métier

Chaque ligne d’évènement du projet P1854 a été éclatée selon les données du fichier des matières ; les autres sans correspondance ont tout de même été traitées. Le tout selon les règles établies dans les activités.

Figures 23 : Résultat après chargement et incorporation des coûts issus du modèle comptable.

Les totaux par activité n’ont pas changé par rapport à la figure 18. En revanche, en détail (résultats / Lot par activité) les lignes d’évènements du projet P1854 ont été valorisées au prorata des répartitions sur les projets de réaffectation.

NB : Les PROJETS réaffectés apparaissent dans la colonne Activity_name, et les SERVICES dans la colonne activity_text. Cette dispersion par rapport aux colonnes initiales Product_code (SERVICES) et Event_code (PROJETS) conservées par les autres natures d’évènements impose une réunification des concepts sur une colonne unique (une colonne PROJETS, une colonne SERVICES). Ce besoin est d’ores et déjà satisfait (à partir de la version Expertizers 5.7.151) et sa résolution est exposée dans le document remontee_hotline_003.pdf disponible (courant novembre 2014) dans la section Documentation pdf du site www.expertizers.com

.


2.2 ORCHESTRATION DE LA RESOLUTION DU CAS DSI

Il s’agit bien d’une orchestration puisque nous allons établir, pour ainsi dire, un simple regroupement de la plupart des structures de données décrites au chapitre 2.1. Nous nous contenterons d’ajouter diverses fonctions disponibles depuis l’origine d’Expertizers et dont l’intégration dans le cas DSI nous semble particulièrement utile. A base de copies d’écrans, La résolution du cas DSI consiste à vous donner une vue détaillée du cheminement procédural à suivre pas à pas. Il est identique à la plupart des domaines d’application. 2.2.1 CONTENU ET RESOLUTION DU MODELE COMPTABLE

Figure 24 : Fichier de l’arborescence de répartition des comptes sur les activités

Commentaires : L’arborescence est simple, sans activité intermédiaire. Vous reporter si besoin au chapitre 2.2 du cas Fastfood, beaucoup plus complet sur le sujet. Ici la présence de lignes à blanc est acceptée ; Ce n’est jamais le cas des autres fichiers chargés dans Expertizers. Par rapport aux données du chapitre 2.1 nous avons ajouté une activité ‘frais structure personnel’ dont le coût devra se déverser sur les évènements métier au prorata de leur consommation totale des coûts de personnel interne + externe.


Figure 25 : Fichier des évènements comptables

Processus opératoire: Menu Modèle / Créer / à partir du modèle vide model_v1.ex1 Menu Arborescence : Créer la variable multi_account_lines dans le descriptif du fichier d’évènements derrière la variable quantity_init (correspondant à la colonne E du fichier) Menu Auto.génération / File loading (sélection fichier figure 24 ) puis Model generation.

Figure 26 : Affichage de l’arborescence générée automatiquement.


Processus opératoire : Menu Lot_Batch / Charger les évènements / Charger / Fichier simple Sélection fichier figure 25 Messages de compte-rendu

Le deuxième lié à la présence de la variable multi_account_lines (recalcul des soldes)

Figure 27 : Affichage des évènements chargés

Processus opératoire : Click sur Start process, puis message du compte-rendu de la répartition sur les activités


Figure 28 : Affichage des répartitions Compte / activités (= menu résultats / Lot par activité)

Processus opératoire : Menu Résultats / ‘Totaux par période, activité’ ou ‘Totaux par période’ (choix indifférent) On a beau traiter de coûts, c’est la colonne activity_value qui est utilisée ici. C’est ainsi ! Cliquer sur la ligne Export. Le fichier est placé par défaut dans le répertoire expertizers/export

A ce stade, le traitement du modèle comptable est terminé.


2.2.2 CONTENU ET RESOLUTION DU MODELE METIER

Figure 29 : Fichier des évènements métier

Commentaires : Par rapport aux évènements métier du chapitre 2.1 nous avons ajouté tout un bloc de SERVICES qui consomment des unités d’œuvre techniques. Les lignes sont affectées à la nature distinctive RELEVES. Issues de relevés applicatifs ou estimatifs ( ?), chaque colonne d’unité d’oeuvre sert à l’étalonnage d’une ou plusieurs activités, mais elles ne sont pas toutes utilisées dans le présent cas DSI. La page 23 du document du CIGREF reprend la liste de ses 39 activités avec en regard, pour chacune, l’unité de mesure (= inducteur) appropriée.

Figure 30 : Description du fichier d’évènements du modèle métier


Processus opératoire (référence : document formation express_1): Création du modèle : Menu Modèle / Créer / à partir du modèle vide model_v1.ex1 Création des variables ligne à ligne ou en plein écran (multi-lignes) : Si choix grisé sur click droit souris Insert (sur ligne d’une variable) ou MàJ Plein écran (sur ligne du paragraphe event file description) penser à déverrouiller la mise à jour (Menu Modèle / Verrouiller, déverrouiller la mise à jour de l’arborescence) Création des activités ligne à ligne ou modification en plein écran ou utilisation d’utilitaires.

Figure 31 : Affichage des activités avec leurs règles dans le modèle métier

Faute de place à l’affichage, les trois premières activités ne sont pas visibles. Vous les retrouverez au niveau de la figure 13. Les nouvelles activités démarrent à l’activité FRAIS_STRUCTURE_PERSONNEL. Les activités de nature PROJET (MAICOR, SUPN2F,DEPPRO) ont l’option ‘Memorize YES’. Leurs valeurs calculées activity_value et activity_cost seront donc conservées respectivement dans des variables value_act_ACTIVITY et cost_act_ACTIVITY pour être reprises dans les autres activités en aval au traitement du même évènement. C’est ainsi que la règle activity_value de l’activité FRAIS_STRUCTURE_PERSONNEL est : activity_value = cost_act_DEPPRO_EXT_CASH + cost_act_DEPPRO_INT_CASH + cost_act_MAICOR_EXT_CASH + cost_act_MAICOR_INT_CASH + cost_act_SUPN2F_EXT_CASH + cost_act_SUPN2F_INT_CASH, signifiant que le coût des six activités forment l’unité d’œuvre de répartition du coût de l’activité FRAIS_STRUCTURE_PERSONNEL. Comme aucune des activités n’ont de règle de coût au sein du modèle, c’est au moment de l’incorporation des coûts issus du modèle comptable que tous les calculs de répartition se feront.


Figure 32 : Saisie rapide des données d’analyse d’activités (Menu / Utilitaires / Mise à jour rapide des activités ‘écran + export)

Maintenant le modèle est complet et Les évènements métier prêts au traitement. Nous aurions pu évidemment saisir le nom des activités pour les rendre plus compréhensibles !

Processus opératoire : Menu Lot_Batch / Charger les évènements / Charger / Fichier simple Sélection fichier figure 29 Messages de compte-rendu


Figure 33 : Affichage d’une partie des colonnes des évènements chargés

Processus opératoire : Click sur Start process, puis compte-rendu du traitement. Le message nous informe du coût total (2487653) calculé par règles sur activity_cost. Le coût correspond aux lignes d’évènements de nature CDR qui sont passées dans les activités ACQPRO_CASH_CDR et ACQPRO_PEL_CDR (règles activity_value = montant_de_la_ligne et activity_cost = activity_value)

Figure 34 : Affichage des résultats par ligne d’évènement / activité (= Menu Résultats / lot…)


Processus opératoire : Chargement et traitement des coûts par activité, extraits du modèle comptable (cf 2éme tableau figure 28) Menu Lot_Batch / Charger un fichier des coûts / Charger coûts par entité, période, activité. Autre possibilité activée dans le modèle comptable : Résultats / Lot par activité + données Evènements (table ACCOUNTING_EVENTS_BY_ACTIVITY), Export du fichier, De ce fait chargement possible dans le modèle métier et résultat identique par le deuxième choix Menu Lot_Batch / Charger un fichier des coûts / Charger / Charger coûts par fichier ACCOUNTING_EVENTS_BY_ACTIVITY. Lancement de la procédure. Message préalable ci-dessous. Yes = Choix du fichier (dans répertoire par défaut expertizers/export) et démarrage (chargement + traitement)

La procédure vous informe de la répartition d’activités sur d’autres activités (comportement déjà vu au chapitre 2.1.5 figure 16)

La procédure vous informe qu’elle a détecté une ou plusieurs activités dont le coût sert d’unité de mesure pour répartir le coût d’une autre activité.


Figure 35 : Compte rendu de la fin du traitement d’intégration des coûts

Figure 36 : Affichage des résultats d’intégration consolidés par activité. (Retour possible à la liste par Lot_Batch / Charger un fichier des coûts / Lister les coûts par activité)

Figure 37 : Affichage des lignes d’évènement par activité (Menu résultats / Lot par activité OU Lot par activité + données évènements ‘table BUSINESS_EVENTS_BY_ACTIVITY’)


La production de la matrice BUSINESS_EVENTS_BY_ACTIVITY clos le processus de traitement du cas DSI. Eventuellement, si vous avez chargé les coûts via le fichier BUSINESS_EVENTS_BY_ACTIVITY, vous pouvez alors générer la matrice BUSINESS_EVENTS_BY_ACCOUNT et bénéficier alors d’analyses des évènements métier non seulement par activité mais aussi par compte d’origine. Les deux matrices, qui sont aussi des tables SQL contiennent toutes les données d’évènements que vous avez introduit dans les modèles. Elles sont donc d’une grande richesse et facilement exploitables soit directement par une connexion ODBC avec votre requêteur favori, soit par un export aux formats xls, txt. L’objectif de la réalisation d’un cas sur les coûts informatiques est évidemment de prouver que la solution Expertizers est bien outillée pour y parvenir, mais l’objectif est aussi de démontrer qu’elle est une continuation de l’esprit rigoureux qui doit commander une telle étude. 2.3 REFACTURATION DES SERVICES AUX CLIENTS DE LA DSI

Résolution développée courant novembre 2014 3. SYNTHESE. APPORTS METHODOLOGIQUES DE LA SOLUTION EXPERTIZERS Chapitre développé courant novembre 2014

resolution du cas dsi normes cigref 1 -...

Documents