Taxonomie des organisations et décentralisation 

Critères de décentralisation

La question de la centralisation/décentralisation se pose depuis longtemps pour les États et les entreprises. Plusieurs termes sont parfois associés à la décentralisation : délocalisation, où les opérations sont géographiquement déplacées, mais la structure organisationnelle n’est pas nécessairement décentralisée ; déconcentration, « dispersion des moyens d’action et de contrôle entre un ou plusieurs centres dans lesquels le pouvoir de décision est exercé par des agents et organismes locaux résidant sur place mais soumis à l’autorité centrale » [14] qui se rapproche de la définition de la fédération. Ces 2 propriétés ne sont pas toujours signe de décentralisation : la délocalisation signifie le déplacement géographique de tout ou partie de l’organisation, si une BU/OU se sépare du siège, alors il y a décentralisation partielle, mais si l’ensemble du siège se déplace ou une partie déjà séparée se déplace, il n’y a aucun changement structurel. La déconcentration, dans la définition du CIGREF, n’est qu’une étape parmi 4 autres : la concentration est l’étape où toute l’organisation a concentré ses moyens en un seul et unique endroit sous une direction unique, puis vient la cen tralisation où le pouvoir est en un point mais les moyens de production sont séparés, ensuite vient la déconcentration où le pouvoir devient local aux moyens d’action et de contrôle tout en respectant une ligne directrice donnée par un pouvoir central, et enfin la décentralisation où aucun pouvoir central n’existe et seules les directions locales décident.
On oppose la décentralisation à la centralisation selon plusieurs critères. La distribution du pouvoir de décision au sein de l’organisation est un critère récurrent et évident, d’autres dépendent de la vision choisie pour l’organisation (fonctions/moyens de production, standardisation, …). Ces définitions et critères exprimant la décentralisation sont présentés dans cette partie.

Critères de Luthans

3 facteurs ont été relevés pour exprimer le degré de centralisation/décentralisation par Luthans [13]:
— Concentration/Dispersion géographique des Opérations (« comment faire »/production : chaîne de production) ;
— Concentration/Dispersion géographique des Fonctions (« quoi faire »/but : BU/OU) ;
— Concentration/Dispersion des pouvoirs de prise de décision.

Critères de « Pearlson & Saunders »

3 critères ont été relevés pour exprimer le degré de centralisation :
— allocation des droits de décision (une seule autorité supérieure, ou droits de décisions égaux) ;
— structure des lignes de communication (hiérarchie décide des voies de communication, ou communications informelles orienté équipe) ;
— choix des formes de coordination (coordination verticale : autorité, standards, planning, contrôles,
… ou coordination latérale : meetings, task force, structures en matrices, …).

Étude de cas : Présentation des entreprises

Afin d’exposer les différences entre les cas centralisé et décentralisé, nous allons appliquer la méthode 4EM sur deux entreprises répondant aux critères précédemment exposés. Ces entreprises seront fictives, mais issues d’exemples partiellement réels.
L’entreprise centralisée se compose de 4 BU : Ventes, Production, Marketing, Achats. L’entreprise fonctionne actuellement bien en achetant de la matière première à des partenaires (via les Achats), sur lesquels des processus industriels interviennent pour générer des produits (la Production) qui sont acheminés et vendus à des revendeurs (par les Ventes), et dont le marketing travaille à créer des paquets incitant de nouveaux consommateurs à s’en procurer. Cette entreprise respectera le principe récurrent de la centralisation : la chaîne de décision partant du haut et descendant progressivement jusqu’en bas. Le comité de direction estime qu’il faut toucher un nouveau marché (et de nouvelles cibles commerciales) en proposant un nouveau produit. Une nouvelle chaîne de production devra être construite, de nouveaux partenaires devront être contactés pour l’achat de matières premières, et la revente des produits à un nouveau segment de marché, tout en préparant une campagne de communication pour le lancement. Les fonctions sont plutôt rapprochées, les directeurs et responsables peuvent être facilement rassemblés. Ce type d’entreprise se rapproche d’exemples existants tels que BNP Paribas, Société Générale, L’Oréal, …
L’entreprise décentralisée fictive est basée en grande partie sur l’exemple de Valve Corporation [4] où le flat management est appliqué : les gens sont libres de se regrouper en équipes selon leur envie. Cette organisation s’approche de l’anarchie. La chaîne de décision est inexistante dans ce contexte : chaque personne est responsable de ses choix, et les équipes sont formées sans nécessairement contenir un dirigeant. L’entreprise fictive propose une plateforme de vente et télédistribution de jeux vidéo pour PC (un cloud contenant les jeux et associant à chaque joueur un compte), elle possède également quelques jeux vidéo sur lesquels des DLC (DownLoadable Content) sont vendus. L’entreprise compte entrer sur le marché des consoles de salon en fabricant des manettes de jeux, et en proposant une spécification de machines que des fabricants pourront produire (en échange de royalties), et sur lesquelles la plateforme de télédistribution sera installée permettant aux joueurs d’utiliser leur télévision au lieu du PC. 4 équipes ont été identifiées : la première travaille sur la plateforme cloud et l’application distribuée aux PC permettant la vente de jeux depuis un catalogue en ligne, la deuxième équipe travaille sur les nouvelles manettes, les spécifications de la console de salon et à la refonte de l’interface graphique pour l’adapter aux téléviseurs et manettes, la troisième équipe a développé un jeu vidéo et s’occupe de corriger les bugs, ajouter des DLC, et chercher de nouvelles façons de vendre des DLC, la quatrième équipe est chargée du CDN (Content Delivery Network) qui permet de relier les joueurs du monde entier à la plateforme, et à leur transmettre les fichiers et mises à jours de l’ensemble du catalogue de jeux vidéo.

Enterprise Architecture et Enterprise Modeling : Les Méthodes et Frameworks

Le travail d’Enterprise Architecture regroupe de nombreuses activités liées à la structuration des organisations, et la planification de ces dernières pour permettre au SI de s’adapter plus facilement aux changements de buts. L’Enterprise Modeling est une de ces activités permettant de modéliser une entreprise en l’état, et construire l’état suivant visé [15].

TOGAF : The Open Group Architecture Framework

Le TOGAF, ou The Open Group Architecture Framework, est un framework gratuit dédié à l’EA. Il regroupe 3 aspects :
— Architecture Development Method (ADM) : un ensemble d’activités permettant de gérer le cycle de vie d’une architecture d’entreprise ;
— Architecture Content Framework : une description de l’ADM et de ses produits ;
— Enterprise Continuum : un moyen d’organiser les architectures produites.
Le TOGAF fonctionne surtout avec les méthodes « as-is to-be » pour la représentation des architectures. L’ADM sera détaillé afin d’expliquer les activités de modélisation.

ADM : Architecture Development Method

D’après le TOGAF, l’ADM est : « a method for developing and managing the lifecycle of an enterprise architecture » [16, Ch. 5.1]. Il se découpe en 10 activités liées, et est parfois surnommé la « marguerite » (voir Figure 2). Ces activités se séparent en plusieurs phases : une préparation/mise en place des moyens d’architecture, la création régulière d’une vision à court/long terme, une étude de l’application de cette vision par rapport à l’existant, le découpage sous forme de projets des parties à implémenter, puis le déploiement et la gestion du changement, l’ensemble avec une étude des exigences continue.
La première étape de l’ADM est hors du cycle (Preliminary ), il s’agit de préparer l’organisation au processus continu qui sera mis en place. Pour cela, une structure de gouvernance doit être créée, ainsi qu’une équipe dédiée au processus continu d’EA, et enfin un dépôt pour stocker les informations de l’architecture.
La phase A du cycle consiste à poser les bases de l’existant, et définir des objectifs pour l’organisation. Les acteurs liés à la prise de décision stratégique interviennent dans cette phase et doivent être réunis pour poser les buts souhaités pour l’entreprise. Un accord se fait sur ce que l’entreprise cherche à atteindre au début du projet, et vers quels autres objectifs elle doit se tourner d’ici la fin de la 1 ère itération. Les architectures de haut niveau actuelles et à venir sont ainsi décrites dans des modèles as-is to-be. Des KPI devraient être décidés pour mesurer le changement à la fin du projet.
Les résultats de l’étape Preliminary et de la phase A sont à organiser dans un document « Statement of Architecture Work  » à faire approuver par le sponsor du projet, et qui peut servir de contrat entre l’architecte et le client.

FEA : Federal Enterprise Architecture

Initié par le gouvernement des États-Unis d’Amérique afin de construire une architecture pour l’ensemble de son gouvernement, le framework FEA couvre l’ensemble des composants attendus : une méthode d’EA, une description d’EA, et un moteur d’EA. FEA essaye de laisser le soin à chaque OU/BU de créer sa propre architecture, tout en s’insérant dans un framework global offrant des standards communs d’interopérabilité. FEA est composé de 6 éléments centraux [17] :
— découpage de l’organisation en plusieurs segments sur lesquels une architecture sera aussi conduite
— 5 modèles de référence pour servir de base de réflexion aux éléments importants à représenter (dans la 1 ère version)
— un processus pour créer l’architecture (l’EA) de chaque segment
— un processus de transition pour passer de l’état existant à celui visé pour l’organisation
— une taxonomie pour trier le contenu de l’organisation dans les modèles FEA
— des directives pour mesurer le degré de succès de FEA
Les segments (les principales activités nécessaires au métier) peuvent être de 2 types : core mission (le cœur de métier de l’OU/BU : la santé, le transport, …) ou business service (les services nécessaires pour faire fonctionner un métier : les finances, achats, …). Les segments core-mission sont gérés et décidés en interne de l’OU/BU, tandis que les business services sont sous le contrôle de l’ensemble de l’entreprise. FEA inclut 3 artefacts pour décrire l’architecture des segments initiaux, l’architecture des segments cibles, et la stratégie de transition.
Les 5 modèles de référence de la 1ère version s’occupent : de la performance (choix des critères et mesures), du métier (vue fonctionnelle des lignes métier), des composants de service (comment les services informatiques supportent les fonctions métier), de la technique (choix des technologies et standards pour les composants de service), et des données (description des données pour partage au sein de l’ensemble de l’entreprise). Une 2ème version (FEAF-II Federal Enterprise Architecture Framework ) a modifié ces modèles de référence pour en former 6 : performance, métier, données, application, infrastructure, sécurité.
FEA définie un processus en 4 étapes pour créer l’architecture de chaque segment :
1. Analyse d’architecture : scope du segment, analyse de l’existant, des problèmes, et définition rapide de l’état final voulu
2. Définition de l’architecture : définition détaillée de l’architecture cible, et de la roadmap nécessaire pour l’atteindre, la stratégie de transition et les KPI de réussite
3. Stratégie d’investissement et de financement : comment financer les projets de transition
4. Plan de gestion du programme et projets de mise en œuvre : détail des plans de migration, leurs suivis, et de leurs KPI
Pour maintenir l’architecture à jour, FEA contient également un moteur sous forme d’activité : maintenance de l’architecture des segments (segment architecture maintenance). Cette activité impose de surveiller, lister et prioriser tous les évènements pouvant mener à un changement dans l’architecture.

EM : For Enterprise Modeling

[20] La méthode 4EM est dédiée à créer les éléments qui serviront à représenter l’organisation dans son ensemble. Elle est composée de 3 éléments principaux pour fonctionner : une procédure de modélisation utilisant une notation précise, une mesure de performance d’EM sous forme de projet avec des rôles précis, un processus participatif pour impliquer les parties prenantes de l’entreprise et les experts du domaine. 4EM est un modèle générant plusieurs sous-modèles utilisés dans plusieurs aspects de l’entreprise.
Les 6 sous-modèles de la méthode 4EM seront présentés dans cette partie.

Goals Model

Ce modèle sert à décrire le/les but(s) que l’organisation veut atteindre : toucher une nouvelle cible commerciale, augmenter ses parts de marché, réduire le nombre de clients annulant leur contrat, etc… Il s’agit des questions liées à la direction qu’une entreprise doit prendre pour assurer son développement. Le Goals Model proposé par 4EM inclut 5 composants : Goal, Problem, Cause, Constraint, Opportunity. Ces composants sont reliés par des liens unidirectionnels : supports, hinders, conflicts.
Les buts (Goals) sont à noter dans des cases avec des phrases simples mais claires. Le mieux est de suivre le principe SMART : le but doit être Specific, Measurable, Accepted, Realistic, et Time Framed. Les buts à court et long termes doivent être indiqués, puis discutés pour être priorisés (exactement comme dans les activités de récupération d’exigences). Les buts peuvent être récupérés en plusieurs brainstormings afin de ne rien oublier. Un exemple de but correct serait : augmentation du profit de 15% pour l’année en cours ; un but pas assez explicite serait : faire plus d’argent ; ces deux buts sont similaires, mais l’un respecte beaucoup plus le principe SMART avec une durée fixée « l’année en cours « , et une finalité réaliste et mesurable « augmentation du profit de 15% ».
Les problèmes (Problem) expriment une situation indésirable que l’on risque d’atteindre ou qui est actuellement bloquante. Les problèmes permettent de retrouver des buts cachés qui seraient initialement induits. Si un problème n’empêche pas la réalisation d’un but préalablement décrit, soit les buts sont incomplets, soit le problème n’en est pas un. Les problèmes peuvent parfois être spécifiés en 2 catégories : les faiblesses, des facteurs qui réduisent la possibilité de réaliser un ou des buts et qui peuvent être considérés comme internes au domaine du problème ; et les menaces, des forces impactant négativement la réalisation des buts en provenance de l’extérieur du domaine du problème.
Les causes (Cause) servent à expliquer l’origine des problèmes. Les causes sont des situations ou des états hors de contrôle du projet, des processus et de l’organisation.
Les contraintes (Constraint) sont des règles que le monde extérieur impose à l’organisation. Des règlementations, lois, ou autres politiques liées au métier affectant les composants et liens du modèle de l’entreprise seront des contraintes. Les règles internes seront représentées dans le Business Rules Model 3.4.2.
Les opportunités (Opportunity) sont les ressources permettant d’atteindre plus facilement un état, ou un but, voire de trouver de nouveaux buts pour l’organisation. Par exemple, les avancées dans les technologies de communication permettent d’atteindre des clients internationaux.

Technical Components and Requirements Model

Ce modèle rassemble les composants techniques et les exigences. Il s’agit de comprendre comment et pourquoi ces composants sont présents dans tel processus, et quel(s) but(s) servent ils.
Il s’agit de la partie où le SI technique est confronté aux exigences organisationnelles. Les cartes d’urbanisation avec les architectures métier, fonctionnelle, applicative, et technique correspondent en partie aux modèles qui pourraient être générés : la cartographie de l’existant ne suffit pas, il faut ajouter celle impliquant l’architecture cible répondant aux nouvelles exigences.
Ce modèle s’effectue typiquement en dernier. Les exigences ou buts haut niveau du SI dans sa globalité doivent être développés, pour structurer le SI en plusieurs sous-systèmes ou composants techniques. Pour chaque sous-système, des buts plus spécifiques sont définis ainsi que des exigences. Ces exigences et buts locaux doivent être dérivés en accord avec les sous-modèles précédents. Le modèle contient 4 composants : Information System Goal, Information System Problem, Information System Requirements, Information System Technical Components.

Étude de cas : Application de 4EM aux exemples d’entreprises

Afin d’illustrer 4EM et expliquer les limitations dans le cas décentralisé, les 2 entreprises présentées dans le chapitre précédent vont être modélisées avec cette méthode (voir Etude de cas : Présentation des entreprises 2.5). 4EM sera d’abord utilisé sur l’exemple centralisé, où la méthode fonctionne parfaitement et permet effectivement de prendre en compte les changements de direction et les répercuter jusqu’au SI. Puis, 4EM sera lancé sur l’entreprise fictive décentralisée fonctionnant en flat management, où il sera plus difficile d’appliquer la méthode exacte.

4EM dans le cadre centralisé

L’entreprise centralisée commence donc par établir le but organisationnel majeur via son comité de direction : introduire un nouveau produit sur le marché en visant un nouveau segment. Chaque directeur se raccorde à cette cible et indique les buts qu’il devra atteindre : la production doit ajouter une nouvelle chaîne de transformation permettant de construire le produit, les achats doivent trouver de nouveaux partenaires qui vendent les matières premières nécessaires et maintenir un approvisionnement continu, les ventes doivent établir une nouvelle chaîne d’approvisionnement envers les revendeurs, le marketing doit préparer une campagne de lancement pour cette nouvelle cible commerciale et négocier le placement du produit chez les revendeurs. Les problèmes et menaces sont également identifiés pour chaque but avec l’aide des différentes BU.
On retrouve la structure hiérarchique : la direction générale donne sa vision, et l’ensemble de la structure sous-jacente met en œuvre les moyens nécessaires à la réalisation de cette vision.

Table des matières

1 Introduction
1.1 Contexte
1.2 Problématique
1.3 Questions de recherche
1.4 Limitations
2 Taxonomie des organisations et Décentralisation 
2.1 Structures d’organisations classiques, modernes, post-modernes
2.1.1 Structures d’organisations classiques
2.1.2 Structures d’organisations modernes
2.1.3 Structures d’organisations post-modernes
2.2 6 archétypes de Weill
2.3 Centralisation, Fédération, Décentralisation
2.4 Critères de décentralisation
2.4.1 Critères de Luthans
2.4.2 Critères de « Pearlson & Saunders »
2.5 Étude de cas : Présentation des entreprises
3 Enterprise Architecture et Enterprise Modeling : Les Méthodes et Frameworks 
3.1 TOGAF : The Open Group Architecture Framework
3.2 Zachman
3.3 FEA : Federal Enterprise Architecture
3.4 4EM : For Enterprise Modeling
3.4.1 Goals Model
3.4.2 Business Rules Model
3.4.3 Concepts Model
3.4.4 Business Processes Model
3.4.5 Actors and Resources Model
3.4.6 Technical Components and Requirements Model
3.5 Étude de cas : Application de 4EM aux exemples d’entreprises
3.5.1 4EM dans le cadre centralisé
3.5.2 4EM dans le cadre décentralisé
4 Méthode de recherche 
4.1 Design Science
5 Modification du modèle 4EM pour l’environnement Anarchique/Flat Management 
5.1 1 ère itération : Séparation Local/Global
5.2 2 nde itération : Sous-modèles séparés, et boucle de buts
5.3 3eitération : Relations affinées entre les sous-modèles
6 Validation : Étude de cas appliquée avec la méthode 4EM modifiée 
7 Conclusions et Ouvertures 
Références 
Annexes 

Télécharger le rapport complet