Partie 1 : Gouvernance des systèmes d'information

Partie 1 : Gouvernance des systèmes d’information

1.1 Manager des systèmes d’information

Le système d’information a été conçu par un courant de pensée épistémologique : le constructivisme, qui a crée la systémique. La systémique est un nouveau paradigme, c’et-à-dire un nouveau modèle de représentation du monde, à travers un nouveau discours de la méthode. Ou, on tient plus en compte du contexte pour identifier le comportement. En partant du principe que tout comportement a un but.

Pour bien comprendre un système d’information, on va essayer de le modéliser. Dans cette modélisation du monde de l’entreprise ou de l’entité, cette modélisation doit-être comprise comme dynamique et non pas statique. On parle de systémique car tous les parties doivent être prises en compte et dans chacune, il y a un sous-système formant son propre système qui se joint aux autres.

On peut dire qu’un système est un objet qui est dans un environnement composée d’autres objets, et l’objet a un but, qu’il poursuit à travers ses activités. L’objet possède une structure sur laquelle repose le déroulement de ses activités. En omettant pas que l’objet évolue.

Ce système a pour but de modéliser un monde dit complexe. La modélisation, « est une action d’élaboration et de construction intentionnelle, par composition de symboles, de modèles susceptibles de rendre intelligible un phénomène perçu comme complexe et d’amplifier le raisonnement de l’acteur projetant une intervention délibérée au sein du phénomène ; raisonnement visant notamment à anticiper les conséquences de ces projets d’actions possibles, à travers des simulations. »

Dans un modèle, il y a un environnement et une organisation. Rappelons que l’organisation est un processus en interaction dans un système global. Le processus est un enchaînement de tâches menant à un objectif et déclenché par un événement extérieur. On parle aussi de structure pour désigner l’organisation. Dans cette structure, on a les modules pilotes, un système d’information et les modules opérationnels. Le système d’information est l’interface entre les modules pilotes et les modules opérationnels, l’un des rôles essentiels aussi du système d’information, est de mesurer l’entropie dans le déroulement de croissance de l’organisation. L’entropie est définie comme la mesure du degré de désordre d’une organisation. Le système d’information doit-être dynamique aussi, car l’environnement influe sur l’organisation et l’organisation influe sur l’environnement. De plus, le couplage entre modules opérationnels et modules pilotes, ne peut-être satisfait que si le système d’information possède une complexité suffisante à représenter la structure et s’il possède une mobilité suffisante, c’est-à-dire une capacité d’évolution aussi rapide que l’exigent les conditions de l’environnement. Les flux entrants de l’environnement passent par les Modules Opérationnelles, et ceux-ci sont traités par eux, pour ressortir toujours par les Modules opérationnels.

Les modules opérationnelles :

Les modules opérationnelles doivent avoir une interaction avec l’environnement, avec des flux entrants et des flux sortants. Ils doivent acquérir des informations sur les conditions de l’environnement, puisqu’il est opérationnelle, il va donc passer à l’action en transformant les flux entrants.

Les modules pilotes et la décentralisation de la prise de décision :

Les modules pilotes définissent la finalité et conduisent vers l’objectif, c’est les dirigeants qui ont ce rôle. Attention, on va voir que la prise de décision n’est pas synonyme à un niveau hiérarchique.

Il y a différent modes de décisions, adaptés aux situations variées, qui nécessitent une prise de décision. Pour chaque type, il faut disposer d’un module pilote adéquat. Pour informer les modules pilotes des conditions de l’environnement, il faut leurs communiquer des informations captées par les modules opérationnels.

C’est le rôle du système d’information de permettre le couplage entre les modules opérationnels et pilotes afin de maintenir l’intégrité de l’organisation, son développement et la poursuite de ces objectifs. On peut constater que les modules pilotes sont structurés de manière à prendre les décisions de façon la plus efficace possible. On pourra parler d’une gestion à géométrie variable, qui part du plus près de l’activité, représenté par l’ouvrier jusqu’au dirigeant.

a) Premier niveau de prise de décision : les décisions réflexes

Il faut chercher à définir des « réflexes organisationnels » et donc à déléguer la prise de décision dans ces domaines aux acteurs directement concernés. Si on ne le fait pas, les échelons supérieurs de la hiérarchie s’apercevront des problèmes trop tard, lorsque les conséquences en seront dommageables.

Pour cela, il faut identifier les situations, qui peuvent être traitées de cette manière, définir le rôle des acteurs et mettre en place la circulation des informations qui permettra leur mise en œuvre. Puisque lorsqu’une décision doit être prise rapidement, dans la mesure où elle ne présente pas de difficulté de choix, c’est un centre de décision décentralisé qui est chargé de la prendre, car ce qui importe c’est la rapidité de réaction, fondamentale pour maintenir l’intégrité du système.

Les décisions de type « réflexes » sont binaires. Elles doivent être prises le plus vite possible, donc le plus près de la source d’information. Cela rend nécessaire que le système d’information soit structuré de telle sorte que le décideur, qui est, en principe, le module opérationnelle en charge du sous-processus, soit informé sans délai, décide et déclenche immédiatement l’action adéquate. L’implémentation des décisions réflexes constitue un premier axe fonctionnel du système d’information.

b) Deuxième niveau de prise de décision : la gestion de processus automatisés ou gestion par exception

Tant que les indicateurs qui mesurent les mécanismes de l’organisation sont au vert, c’est-à-dire que les activités de l’organisation respectent les objectifs, tout va bien. Par contre, lorsqu’il y a un disfonctionnement, le module supérieur doit mettre en œuvre les décisions correctives. On appelle cela, la gestion par exception.

Pour prendre des décisions, il faut que le module pilote soit informé. Etre informé signifie disposer, d’une part, de variables d’état permettant au module pilote de connaître le niveau de performance du fonctionnement du système et, d’autre part, de variables d’alertes permettant de signaler au module pilote des dysfonctionnements. C’est donc le rôle des cadres moyens, échelons intermédiaires dans la hiérarchie. Ils disposent d’une responsabilité complète sur un processus, avec un objectif à atteindre, caractérisé par une intervalle de valeurs admises pour un ou plusieurs indicateurs. Il y a donc une décentralisation de la prise de décision et une délégation de responsabilité concernant le processus, qui est donnée par la direction générale, à l’organe de contrôle, son subalterne. Celui-ci contrôle cependant un processus vital qui demande une attention permanente ; mais si la direction générale devait gérer ces processus, elle n’aurait plus la possibilité de se consacrer à ses propres tâches, qui sont liées à la capacité de créer des solutions nouvelles à des problèmes inconnus par la pratique du raisonnement analogique. Or, la prise en compte de ces tâches est essentielle pour l’avenir de l’organisation, considéré dans sa globalité. C’est ce qui va permettre de se développer à long terme et de s’adapter à l’évolution de son environnement.

c) Troisième niveau de prise de décision : la prise de décision stratégique

Elle est le fait de la direction générale et engage l’avenir à long terme de l’organisation. Ces décisions demandent de prendre en compte de nombreux paramètres, de peser le pour et le contre.

Afin de faire reculer l’incertitude qui entoure la prise de décision, il sera nécessaire de s’informer. Il serait dangereux de décider d’entreprendre des activités qui n’ont aucunes débouchées. Plus pernicieux encore est de s’engager aujourd’hui dans une activité qui semble porteuse de bénéfices et qui se révélera, à plus long terme, totalement bouchée. La prise de décision stratégique nécessite donc de disposer d’informations synthétiques, basées sur de nombreuses données de départ, qui auront été compilées (traitées) par le système d’information pour le moment T, mais on voit aussi qu’une stratégie de projection ne peut être réellement mise en place par le système d’information, ce qui lui apporte une certaine limite dans le décisionnel.

d) Application des prises de décisions, par les modules opérationnels

Les décisions pour être transformées en action, doivent être expliquées, voire justifiées auprès des modules opérationnels. Il faut prendre en considération le fait que la nature sociale de l’organisation rend permanente la nécessité de gérer les conflits d’objectifs et de finalités, entre l’organisation et ses éléments constitutifs. L’organisation sociale évolue dans un environnement complexe et mouvant. Car la phase de croissance d’une entreprise peut s’arrêter momentanément, puis reprendre au cas où arrive une nouvelle équipe dirigeante plus dynamique, cause interne, ou à l’apparition de nouvelles opportunités de l’environnement ou d’un contexte économique beaucoup plus favorable, causes externes. Néanmoins, l’être social qu’est l’organisation obéit aux mêmes lois du vivant qu’un être biologique. Dès qu’elle n’est plus impliquée dans un processus de croissance, elle commence à régresser. Autrement dit, pour éviter de décliner puis de disparaître, l’organisation est « condamnée » à la croissance. Mais ce processus de développement va entraîner l’augmentation de la complexité et son corollaire, le développement de l’entropie. De manière dialectique, le processus de croissance contient sa propre négation, car l’entropie non maîtrisée va inverser l’évolution de la croissance vers le déclin. Le seul remède au développement de l’entropie sera l’évolution cohérente du système d’information par rapport au développement de l’organisation, afin d’assurer la maîtrise de la complexité.

Structure de l’organisation en tant que système :

L’organisation comme tous les systèmes complexes, possède les caractéristiques suivantes :

§ le système, que constitue l’organisation, peut-être délimité et identifié, par rapport à l’ensemble des autres systèmes qui l’environnent ;

§ l’organisation agit à travers ses modules opérationnels ;

§ l’organisation doit posséder une structure, qui définisse le rôle de chacun ;

§ l’organisation doit être informée et apprenante ;

§ elle est douée de créativité ;

§ elle a une finalité ;

§ elle s’inscrit dans la dynamique.

Le système d’information a une fonction de mémoire de l’organisation qui nécessite le stockage de l’information et également leur mise à disposition en cas de besoin, selon le format désiré par le destinataire. La relation complexe entre information et organisation apparaît donc fondée sur un rapport dialectique.

La complexité d’un système d’information (SI) se mesure par le nombre d’interactions entre les éléments que le système intègre et doit gérer. Par exemple, le SI doit savoir gérer la gestion de règlements de plusieurs factures ou une multiplicité de règlements pour une facture. Le système d’information doit pouvoir évoluer à savoir, avoir la faculté de lui ajouter des modules ou de lui en retirer, pour voir les conséquences sur le modèle et son environnement. Par conséquent ; le SI doit pouvoir évoluer parallèlement à l’évolution de l’entreprise et au même rythme. Pour ce faire, il lui faut posséder certaines caractéristiques qui permettent cette évolutivité. Dans la mesure où l’entreprise est un système ouvert, dans un environnement mouvant et incertain, l’ensemble des chemins que peut prendre l’évolution est infini. Dans ces conditions, construire un SI évolutif consiste essentiellement à éliminer les éléments de rigidité, notamment les facteurs constants, pour les remplacer par des paramètres susceptibles de changer la valeur et de nombre de variantes offertes, par la création de variables modifiables et pas fixes, mais aussi à pouvoir réintégrer de nouveaux modules ou en retirer.

Limites du système d’information :

Le SI ne peut faire circuler, stocker et traiter toutes les natures d’information existant dans l’organisation. Car toutes les informations de l’entreprise ne concerne pas le SI. Puisque certaines informations ne peuvent pas être automatisée, on parlera d’un sous-système automatisable qui basé sur les informations ne pouvant entrer dans le SI car informelles par exemple. De ce fait, le SI est composé d’un sous-système automatisé et d’un sous-système automatisable (pour l’informel).

1.2 La structure du système d’information

1.2.1 La typologie de l’entité

Selon la typologie de l’entreprise ou de l’entité, on aura un système d’information spécifique, car ce n’est pas l’entité qui doit s’adapter au système d’information, mais l’inverse. La finalité est de rappeler que le métier de l’entreprise influe sur les variables essentielles à prendre en compte pour la décision, la structure des données pertinentes et les règles de gestion à définir. Le fait d’avoir une activité sur internet ou traditionnelle pour une entreprise qui vend des jouets par exemple, ne produira pas le même système d’information.

Les différents modes de commercialisation auront donc une influence sur le système d’information :

· Grande distribution,

· E-commerce,

· Commerce entre entreprises.

Mais aussi, les différents types d’industrie :

· Industrie de montage,

· Industrie de fabrication ou appelée aussi de processus.

Et enfin, les différents modes de gestion dans la vente d’un produit, aura son influence sur le système d’information :

· Gestion par affaires, ici on recherche à analyser un résultat par affaire. Une affaire, c’est un contrat de vente. Mais ce qui le rend atypique aux autres contrats de vente, c’est son caractère unique. Cela entraîne l’obligation pour le client d’exprimer formellement son besoin sous la forme d’un cahier des charges et, pour le fournisseur, d’exprimer son offre sous forme d’un devis ou d’une réponse à une appel d’offres. Certaine gestion d’affaires peuvent se faire sur plusieurs années, comme la construction, un progiciel informatique…

· Gestion par produit, c’est le cas général,

· Gestion mixte, pour les entreprises qui font les 2 à la fois.

1.2.2 L’impact du choix de la méthode de management

Les méthodes traditionnelles de management se basent sur des flux de l’amont vers l’aval. Aujourd’hui, dans un contexte de crise économique, on tient plus compte des flux tendus et de ce fait, on utilise naturellement le management à la japonaise, ou les méthodes dites de gestion et de contrôle pour développer les nouveaux facteurs clés de succès.

1.2.2.1 Méthode dites à la japonaise

· Le juste à temps, a pour but de diriger l’activité en fonction de la demande, sans stock et sans délai. Ici, en prend à contrario, la méthode de management traditionnel, où cette fois on tient compte des flux de l’aval vers l’amont. Et de ce fait, le système d’information doit évoluer dans ce sens. L’idée de base des flux tendus est de ne pas anticiper la demande et de ne produire que ce qui est commandé par les clients, ce qui a pour conséquence une réduction importante du besoin en fonds de roulement due à un stock à valoriser réduit. Mais cela implique une fabrication en séries plus courtes, en fonction du portefeuille de commandes. Le problème, ici, est de produire sans augmenter le coût de production unitaire qui serait dû à une baisse de l’économie d’échelle. Pour remédier à cela, il existe deux solutions : une meilleure utilisation du système d’information et la méthode SMED qu’on verra plus bas.

· Le principe des 5 zéros et la politique de la qualité totale : zéro stock, zéro panne (maintenance préventive), zéro défaut, zéro délai et zéro papier. On rajoute un sixième principe le zéro mépris des décideurs car il faut obtenir des comportements orientés vers la qualité de chaque individu de l’organisation, en le motivant par exemple, par une récompense financière. L’intégration de ces principes devra se faire par la création d’un groupe pluridisciplinaires pour résoudre les problèmes qui apparaissent au sein de l’organisation. L’essentiel est la recherche de la qualité totale, et ceci à tous les niveaux de l’organisation. Cela implique que la gestion qualité soit intégrée dans les applications elles-mêmes à travers des études statistiques et des critères identifiés par le cercle de qualité.

· Le recours à la méthode SMED (Single Minute Exchange of Dies) qui est le changement d’outil en une seule minute, a pour intérêt de répondre à une réduction des quantités des séries sans augmenter leur coût unitaire. Pour cela, on n’arrêtera les machines que lorsque tous les éléments nécessaires au changement d’outils sont regroupés au pied de la machine, on facilitera le montage et démontage par des systèmes de fixation plus rapides à manipuler et ron emplacera des mises au point machine arrêtée par des mises au point réalisables machines en route.

Il faut renoncer à une vision analytique et statique des problèmes pour prendre en compte une vision synthétique et dynamique.

1.2.2.2 Influence des nouvelles méthodes de gestion et de contôle

a. La méthode ABC (Activity Based Costing)

Il s’agit d’une perception plus tournée vers la vision systémique et dynamique des organisations que la méthode des coûts complets traditionnelle.

b. La méthode ABM (Activity Based Management)

Cette méthode de gestion basée sur les activités est la plus à même à répondre à la gestion par projet, car elle s’appuie sur une vision transversale et pluridisciplinaire de l’organisation. La méthode ABM propose de construire différents indicateurs d’efficacité et d’efficience. L’efficacité est la mesure du degré d’atteinte des objectifs et l’efficience est la rentabilisation des ressources employés. Ces indicateurs font partie du tableau de bord de la partie décisionnelle du système d’information.

c. Le design et le redisign to cost

Le « redesign to cost » invite à repenser le coût d’un produit au cours des étapes de son cycle de vie. Dans sa phase de maturité, le produit va connaître beaucoup de concurrence et de ce fait, on pourra à ce moment repenser son coût qui aura déjà été amorti précédemment, à travers une analyse nouvelle de sa valeur.

1.2.3 Les éléments constitutifs d’un système d’information

Un système d’information se compose d’applications opérationnelles et d’applications décisionnelles.

1.2.3.1 Les applications opérationnelles

Une application opérationnelle permet de traiter les informations liées aux flux entrants et sortants. Cela constitue l’activité de l’entité pour atteindre les objectifs de l’entité. Ici, les informations sont volumineux mais répétitives. Les applications opérationnelles qu’on retrouve le plus, sont :

· Gestion commerciale ou suivi des clients,

· Gestion des achats ou des approvisionnements,

· Gestion de production,

· Gestion de la maintenance et des garanties,

· Paie et la gestion des ressources humaines,

· Comptabilité et la gestion financière.

L’appellation d’application opérationnelle remplace celle d’application fonctionnelle. Car l’application fonctionnelle représentait une fonction de l’entité, qui est représentée dans l’organigramme de l’entreprise. Depuis les entités ont évolué pour s’adapter de plus en plus à leur marché, en se basant sur les processus d’activité de l’entité. Donc une application opérationnelle gère un processus qui se déroule le plus souvent de manière transversale par rapport aux services de l’entité. On peut remarquer qu’ici on a inversé la modélisation traditionnelle, où avant la fonction d’une entité suivait plusieurs processus, maintenant c’est le contraire le processus suivi par plusieurs fonctions de l'entité. Car c’est les processus qui créent la valeur ajoutée et non pas les fonctions.

 

Présentation des types d’applications opérationnelles usuelles, selon le modèle d’Ivar Jacobson :

C’est en s’appuyant sur cette notion de transversalité et de processus qu’on a eu besoin d’application informatique globale. L'application doit recouvrir le plus possible le système d’information de l’entité.

C’est pourquoi, les Progiciels de Gestion Intégrée (PGI) sont privilégiés.

Pour comprendre comment fonctionne une application qui doit permettre la gestion d’un processus, il faut envisager ces 2 aspects : modélisation du processus (les traitements) et la structuration des données qui va avec.

1.2.3.2 Les applications décisionnelles

Les applications décisionnelles ou appelées encore : Systèmes Interactifs d’Aide à la Décision (SIAD), font partie de l'entité, vue comme un système global qui est composé :

§ de modules pilotes, qui doivent avoir des informations pertinentes pour pouvoir prendre des décisions ;

§ des informations, qui sont obtenues par le système d’information, dans le processus de transformation des flux entrants en flux sortants, par les modules opérationnels.

On dit souvent des applications décisionnelles qu’elles sont subjectives. Cela signifie que les informations pour être pertinentes, doivent respecter principalement le point de vue du destinataire et son niveau de responsabilité au sein de la hiérarchie.

Cette exigence correspond a un effet de loupe par rapport au réel, car plus on va monter dans la hiérarchie, plus l’angle de vue sur le réel est grand, mais plus on voit le réel de loin, moins on perçoit les détails. 

Le système des tableaux de bord est un bon outil pour l’aide à la décision, mais il devra contenir deux principes importants, qui sont :

· permettre la possibilité de pratiquer un effet de zoom et offrir une fonction d’accès au détail, condition de la mise en place de la gestion par exception.

· et la personnalisation du tableau de bord pour respecter les angles de vues de chaque destinataire même si la source provient de la même base de données.

Plusieurs structures de données sont proposées pour les applications décisionnelles. On parle d’infocentre, de datamart et de datawarehouse.

L’infocentre fait référence à une banque de données, partagée en réseau, où les données n’ont pas été modifiées, sur le plan structurel, par rapport aux bases de données opérationnelles.

Le datawarehouse (entrepôt de données) est comme une collection de données orientées sujet, intégrées, non volatiles et historiées, organisées pour le support d’un processus d’aide à la décision. La notion de datawarehouse implique un certain nombre de transformations, par rapport aux sources des données opérationnelles. Les opérations de transformation sont le nettoyage de données, l’historisation automatique de certaines donnée (cela permet de voir leur évolution dans le temps qui représente un facteur explicatif) et la synthèse des données.

Principe de fonctionnement du datawarehouse (selon WIKIPEDIA)

« Dans les faits, les données alimentant l'Entrepôt de données sont hétérogènes, issues de différentes applications de production, voire de fichiers dits "plats" (fichiers Excel, fichiers texte, XML...). Il s’agit alors de les intégrer, de les homogénéiser et de leur donner un sens unique compréhensible par tous les utilisateurs. La transversalité recherchée sera d’autant plus efficace que le système d’information sera réellement intégré dans sa globalité. Cette intégration nécessite notamment :

§ une forte activité de normalisation et de rationalisation, orientée vers la qualité ;

§ une bonne gestion des référentiels, incluant une vérification constante de leur intégrité ;

§ une parfaite maîtrise de la sémantique et des règles de gestion des métadonnées manipulées.

La problématique de l'intégration repose sur la standardisation de données internes à l'entreprise, mais aussi des données externes (provenant par exemple de clients ou de fournisseurs).

Ce n’est qu’au prix d’une intégration poussée que l’on peut offrir une vision homogène et véritablement transversale de l’entreprise. Ceci suppose que le système d’information de l’entreprise en amont soit bien structuré, bien maîtrisé, et bénéficie déjà d’un niveau d’intégration suffisant. Si tel n'est pas le cas, la mauvaise qualité des données peut empêcher la mise en œuvre de l'entrepôt de données. »

Un datamart est un magasin de données spécialisé. Il concerne un sous-ensemble de données particulier et homogène, par exemple les données commerciales clients. La mise en œuvre d’un datawarehouse étant complexe, notamment lorsque les sources de données sont hétérogènes il est plus facile de construire un ensemble de datamarts.

« Un datamart est un sous-ensemble d’un datawarehouse destiné à fournir des données aux utilisateurs, et souvent spécialisé vers un groupe ou un type d'affaire.

Le datamart est un ensemble de données ciblées, organisées, regroupées et agrégées pour répondre à un besoin spécifique à un métier ou un domaine donné. Il est donc destiné à être interrogé sur un panel de données restreint à son domaine fonctionnel, selon des paramètres qui auront été définis à l’avance lors de sa conception.

De façon plus technique, le datamart peut être considéré de deux manières différentes, attribuées aux deux principaux théoriciens de l’informatique décisionnelle, Bill Inmon et Ralph Kimball :

§ Définition d'Inmon : Le datamart est issu d’un flux de données provenant du datawarehouse. Contrairement à ce dernier qui présente le détail des données pour toute l’entreprise, il a vocation à présenter la donnée de manière spécialisée, agrégée et regroupée fonctionnellement.

§ Définition de Kimball : Le Datamart est un sous-ensemble du Datawarehouse, constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de restituer tout le spectre d’une activité métier. L’ensemble des Datamarts de l’entreprise constitue le Datawarehouse.

Considérant le contexte auquel elle se rapporte, on peut privilégier suivant les entreprises l’une ou l’autre de ces définitions ». (définition wikipédia)

Néanmoins, pour pouvoir disposer d’un véritable SIAD, la construction d’un datawarehouse est impérative. Il faut se méfier de la tendance, dans les organisations, à baptiser datawarehouse des structures de données qui n’en sont pas car elles ne respectent aucune des règles qui le définissent.

De plus, seule une structure de type datawarehouse permet de croiser de manière automatique les données émanant des différents processus de l’organisation.

L’OLTP (On Line Transactionnal Processing) est utilisé pour le traitement de l’information des applications opérationnelles, c’est un protocole qui se base sur un temps de réponse court et la non-redondance des données.

Tandis que les applications décisionnelles s’appuient-elles sur l’OLAP (On Line Analytical Processing) qui caractérise l’architecture de la mise en place d’un système d’information décisionnel. Celle-ci représente une structure de données multidimensionnelle et qui nécessite des calculs intermédiaires, dont les résultats seront enregistrés dans la base de données.

Des transformations sont à opérer pour passer des bases de données opérationnelles aux bases de données décisionnelles. On utilise un ETL (Extract Tranform Load) pour effectuer les transformations. L’extraction est facilitée dans le cadre des bases de données relationnelles, notamment lorsqu’elles sont homogènes pour les différentes applications opérationnelles. On possède alors un modèle de base représentant les relations entre les tables et conformes à certains critères de sélections. En règle générale, les applications qui utilisent ces structures de données s’efforcent d’en maintenir l’intégrité, dans la mesure où cette tache peut être dévolue au moteur de base de données. Il est donc possible, grâce à des requêtes, d’alimenter une base de donnés décisionnelle qui respectera de nouveaux critères propres à ses objectifs. La phase Load permet de créer des enregistrements dans la base de données décisionnelle.

Les types de résultats que l’on peut obtenir des applications décisionnelles :

Types

Utilisations

Rapports (reporting)

Mise en place d’un système de tableaux de bord, produits de manière périodique et récurrente.

Hypercubes

Constitution d’une structure de tableaux croisés multidimensionnelle, correspondant aux points de vue des décideurs, permettant l’interrogation libre des données. Ici, l’information n’est pas remise à jour régulièrement.

Data Mining

Modélisations exploratoires des données, s’appuyant sur différents algorithmes du domaine probabiliste ou de la gestion de l’incertain.

Démarche pour construire un SIAD au sein de l’organisation

Souvent les décideurs sont déçus de leurs applications décisionnelles car complexes et ne répondant pas à leurs attentes. Les deux explications de base sont les suivantes :

· absence de réflexion sur les besoins du décideur car le problème qui lui est soumis, est posé uniquement en termes de choix d’outils à acquérir,

· construction des outils d’aide à la décision sur les bases opérationnelles. Devant la difficulté de construire un datawarehouse, on renonce à s’engager dans cette démarche.

Pour éviter ces problèmes, l’organisation doit mettre en place une démarche de réflexion et de construction qui part, des décideurs. Ceux-ci proposeront les indicateurs pertinents pour mesurer leurs performances et disposer de signaux d’alertes par rapport à leurs différents objectifs. Ils peuvent ainsi définir les tableaux de bord et dimensionner l’analyse qui leurs seraient utiles. Attention, on parle ici, d’un préalable qui est la réflexion de la part des décideurs. Car la tentation est grande de ne pas accorder suffisamment d’intérêt à la réflexion. Souvent, on part  du principe que les décideurs connaissent a priori les indicateurs dont ils ont besoin et qui sont expert dans leur domaine de responsabilité. Pour modéliser les besoins de ces décideurs ont peu utiliser le diagramme Ishikawa.

Le diagramme d’Ishikawa, ci-dessous :

Il permet de mettre en valeur l’objectif et les sous-objectifs pour y aboutir.

Organisation d'une application décisionnelle:

1.3   Structuration des systèmes d’information

 

               1.3.1 Position de la fonction informatique au sein de l’organisation

 

On peut envisager cette question d’un double point de vue :

·        quelles sont les structures dans l’organisation qui gèrent les problèmes relatifs à l’informatique ? Ici, la taille de l’organisation aura un impact important sur la réponse ;

·        qui gèrent les problèmes relatifs au système d’information, qu’on a vu précédemment. Ici aussi, la taille aura son importance mais l’histoire  et le type d’organisation seront tout aussi déterminant.

 

 

Il y a une tendance à l’externalisation des services informatiques. Cela permet une meilleure maîtrise des coûts et du niveau de services rendus. On se retrouve en effet dans un cadre contractuel qui permet beaucoup mieux de prévoir les coûts et d’exiger le niveau de qualité des services.

 

Les grandes organisations utilisent l’infogérence (ou outsourcing) pour externaliser la gestion de certains de leurs services informatiques. Néanmoins, il faut se méfier de na pas exagérer le recours à l’externalisation des services informatiques. Le système d’information étant le système nerveux de l’organisation, il y a un risque à en perdre la maîtrise et à déléguer à l’extérieur le contrôle, y compris sur des outils techniques mais qui conditionnent la régulation du service et l’adéquation permanente de ceux-ci aux besoins.

 

 

               1.3.2  Stratégie informatique

 

Toute décision stratégique va entrainer un besoin d’évolution du système d’information. Si ce besoin n’est pas pris en compte, au lieu d’être un facteur clé de succès dans la mise en œuvre de la stratégie, le système d’information deviendra un facteur d’échec. Il est à noter aussi, que souvent le cadre de la prise de décision stratégique n’est pas assez clair. Si l’analyse de la décision stratégique est biaisée, l’analyse des conséquences sur le système d’information le sera également.

 

Pour réaliser les opérations nécessaire à la mutation du système d’information, on devra :

·        définir les directions des évolutions et les objectifs à atteindre ;

·        planifier les évolutions afin qu’elles existent au bon moment.

 

Tout cela sera réalisé dans le cadre de ce qu’on a l’habitude d’appeler le schéma directeur.

 

Notion de schéma directeur informatique et son utilisation au sein de l’organisation :

 

Le schéma directeur aura pour objectif de définir les axes d’évolution du système d’information nécessaire à la cohérence avec la stratégie. Il mettra en perspective les évolutions à réaliser sur une durée de un à trois ans. Il permettra de définir les priorités et de lister les projets à réaliser pour atteindre les objectifs. Il permettra d’expliquer les priorités et de lister les projets des réalisations pour qu’elles soient synchronisées avec la satisfaction des besoins de la stratégie.

 

 

               1.3.3  Urbanisation des systèmes d’information

 

Urbaniser les systèmes d’information consiste à appliquer une évolution qui doit être permanente, au service de l’utilisateur, suivre une politique définie, ne pas être une révolution et prendre en compte l’aspect technique et tout cela fera le plan d’urbanisme qui représentera les différents objectifs de l’évolution du système d’information.

 

L’urbanisation du système d’information implique la solution de deux problèmes :

·        l’intégration d’application hétérogènes, la solution de cette problématique réside dans ce qu’on appelle l’EAI ou bus applicatif, qui permet aux modules applicatifs de se connecter sur une épine dorsale assurant la communication entre eux. Il existe des techniques offrant des solutions de ce type, notamment des métadonnées permettant d’avoir des embryons de référentiels communs, adoptés par tous les applicatifs, pour les objets essentiels du système.

·        la communication avec les système extérieurs, qui doit devenir naturelle et permanente dans un souci de sécurisation du système de l’organisation (interopérabilité).

 

Akim ZERAIBI