Il doit faire une architecture de son temps avec les techniques de son temps
Pour expliquer aux non-initiés l’architecture du SI, on la compare toujours à l’architecture des villes, à l’urbanisation. Une interview récente de Catherine Jacquot (présidente du Conseil national de l’ordre des architectes) montre que les 2 pratiques ont toujours les mêmes points communs. Aussi bien pour montrer l’intérêt qu’elles apportent pour la société tant du point de vue qualitatif que monétaire, que dans l’évolution des pratiques et des outils.
Dans cette interview, les questions du journaliste sont aussi révélatrices que les réponses de l’intéressée. Ce sont les mêmes sujets qui reviennent et que l’on entend dans toutes nos missions : Quelle est votre valeur ajoutée ? N’êtes-vous pas trop cher ? etc.
Quelques phrases sont particulièrement marquantes.
Le phénomène […] empile des strates d’erreurs de différentes époques.
C’est la base même du constat que nous faisons sur les SI de nos entreprises. Toutes ces strates empilées depuis des années et qu’il est très difficile de remettre à plat. Les grands projets de transformation sont difficiles à justifier par les temps qui courent. Il faut être opportuniste et profiter des effets d’aubaine (le digital par exemple) pour proposer des évolutions qui vont dans le sens de la simplification et de la rationalisation et non pas faire que ce soit une couche de plus dans l’empilement.
Ces professionnels sont formés pour mener à bien un projet, y apporter des qualités de construction, d’usage et de confort tout en sachant l’insérer dans l’environnement.
C’est bien là le travail de l’architecte. Proposer des solutions en respectant les normes existantes. Savoir innover quand il le faut. Mettre en avant les usages. Les architectes du SI sont des professionnels et ils doivent faire en sorte d’attirer le respect de leurs clients grâce à la valeur ajoutée apportée par leur travail.
Pour un budget donné, un architecte fera toujours mieux qu’un non-architecte
Cela parait évident, et pourtant, il fait bon le dire ! Oui, l’architecte a un savoir-faire, et les solutions qu’il propose ont de la valeur. Cela ne coûte pas forcément plus cher, car l’architecte sait prendre en compte les contraintes qui s’imposent à lui, et proposer les meilleures solutions.
Son intervention apporte des qualités sans surcoût, « juste avec de la marge en moins pour les constructeurs »
L’architecte saura négocier les aménagements qui optimisent les coûts et les délais tout en respectant au mieux le cahier des charges. Il saura distinguer ce qui est indispensable de ce qui ne l’est pas. Il saura négocier et faire respecter les engagements de coûts et de délais de réalisation du projet. Totalement neutre, l’architecte est indépendant des solutions qu’il préconise : il peut ainsi mettre en concurrence les maîtrises d’œuvre, les challenger et en tirer le meilleur parti. C’est à ce titre que l’architecte saura montrer que sa prestation n’est pas une source de coût mais un gage de qualité.
Il faut faire une architecture de son temps avec les techniques de son temps.
L’architecte doit évoluer avec son temps. D’urbaniste, il est devenu architecte d’entreprise. Les entreprises vont continuer à évoluer, les SI seront de plus en plus inter connectés, de plus en plus complexes. Afin de continuer à apporter les meilleures solutions pour les SI des entreprises, les outils et techniques de l’architectes doivent évoluer. Les architectes sont à même de réfléchir à l’avenir de leur métier pour proposer les solutions les plus adaptées au monde digital, à l’internet des objets, à l’uberisation des entreprises…
L’architecture d’entreprise est un métier jeune et qui évolue rapidement. L’architecte d’entreprise reste le maillon indispensable dans la maîtrise de l’évolution et de la transformation au sein des entreprises. Les entreprises doivent continuer à s’appuyer sur les compétences des architectes d’entreprise et leur donner la place qui leur revient, car l’architecte d’entreprise assure une maîtrise de la transformation vers des SI toujours plus efficaces, évolutifs et économes…
Lire Ecrire Compter Coder est le titre d’un petit livre paru il y a un an aux éditions FYP. Il intéressera tous ceux qui s’intéressent à l’enseignement de l’informatique, mais il va plus loin, il pose aussi la question de la bonne utilisation de la société numérique.
On l’aura noté, le titre est à l’infinitif. La quatrième de couverture, quant à elle, se conjugue au définitif : on peut y lire que l’ouvrage « traite de la nécessité d’apprendre le code pour toutes les générations et explique comment y parvenir ». Faut-il faire comme l’Estonie, qui vient de rendre obligatoire l’enseignement de l’informatique dès l’âge de 7 ans ?
Mais à l’intérieur du livre, le propos est plus nuancé.
Les auteurs expliquent que l’apprentissage du code ne résout pas tout : le code est un moyen et pas une fin en soi. Après tout, beaucoup de personnes savent utiliser une machine à laver ou une voiture, sans pour autant savoir vraiment comment elle fonctionne, et encore moins comment la réparer !
Un des points intéressants de l’ouvrage est de montrer que l’enseignement du code relève de l’apprentissage par l’action. Autrement dit, de l’expérimentation. Tout comme naguère on apprenait la biologie des réflexes en excitant une patte de grenouille, l’apprentissage par la pratique est souvent nettement plus efficace que la théorie, et en tous cas, la renforce.
Le code se découvre par l’expérimentation : ceci ravira les tenants de certaines pédagogies ! Il est bien connu que dans beaucoup de domaines, la technique a précédé la science : en d’autres termes on a découvert l’utilisation pratique du feu bien avant d’en comprendre la chimie… Le parallèle avec la chirurgie est particulièrement éclairant : le chirurgien apprend beaucoup en disséquant puis en opérant, la connaissance théorique du corps ne suffit pas.
Le code apprend l’algorithmique, il apprend à penser et à formaliser une méthode. Et tout cela dans un but concret : il ne s’agit pas de coder pour coder, mais de coder pour résoudre un problème. Tester le code permet immédiatement de vérifier si la méthode fonctionne : lorsqu’on se trompe, on peut recommencer, et il y a souvent plusieurs solutions possibles. Tout comme en Open source, l’apprenant est valorisé par la possibilité d’améliorer le fonctionnement d’un code existant, ou de découvrir de nouvelles méthodes. De plus il est largement possible d’apprendre de manière autonome, le transfert de connaissance ne se fait plus seulement dans le sens professeur => élève. Au contraire, on peut apprendre en groupe de pairs : le parallèle est évident avec les méthodes agiles ! L’apprentissage ne se fait plus en « présentiel » (le professeur face à la classe). Autre avantage : il n’est plus nécessaire d’apprendre la même chose à tout le monde…
L’apprentissage du code peut également être un moyen ludique de faire réfléchir à des règles de société. Un des exemples cités concerne la découverte du code de la route grâce à la programmation des feux de croisement.
Savoir coder est également bien utile pour comprendre le monde qui nous entoure – par exemple, comment les entreprises font usage des technologies pour nous proposer des produits et des services ciblés. Mais aussi, comment les individus peuvent orienter les choix de société : à l’image de l’Open source, tous les citoyens peuvent collaborer et influer sur les lois qui nous gouvernent, ces lois n’étant pour les auteurs que le code qui régit le fonctionnement de la société. Il est donc important de ne pas laisser la production de ces codes dans les mains d’une petite fraction d’intérêts. En la matière, l’avènement de plates-formes comme Change.org, qui permet à des citoyens de pétitionner, montre que le chemin à accomplir est encore très long…
Le dernier tiers de l’ouvrage est consacré aux pistes possibles pour apprendre à coder aux enfants et aux adultes. Les auteurs y présentent de nombreuses expériences de manière factuelle, y compris celles qui ne vont pas dans le sens de leur discours. Une preuve d’objectivité qui les honore.
Lire Ecrire Compter Coder, de Frédéric Bardeau et Nicolas Danet, disponible sur toutes les bonnes plates-formes web.
La modélisation des processus s’est répandue au cours des dernières années. Elle est un exercice délicat, surtout pour des personnes peu préparées. Cette chronique propose 10 règles pratiques et éprouvées pour produire des modèles utiles, et les réaliser rapidement.
L’intérêt de la modélisation des processus n’est plus à démontrer. Du côté des informaticiens, de nombreuses démarches de conception, d’urbanisation, d’»architecture d’entreprise» se fondent sur la modélisation des processus ; ces méthodes commencent à se diffuser du côté des utilisateurs et à attirer l’attention des décideurs. En parallèle, de nombreuses entreprises refondent en permanence leurs processus pour les optimiser et les adapter aux évolutions de leur métier. Toutefois, bien modéliser n’est pas donné à tout le monde. Récemment, j’ai été témoin de l’expérience suivante : dans une grande entreprise, la Direction des Opérations avait demandé à 3 personnes de modéliser le même processus. A l’arrivée, elle a obtenu trois résultats complètement différents ! Imagine-t-on un architecte fournir trois plans différents pour un même bâtiment, ou un constructeur de PC fournir 3 plans différents de la même carte-mère à son fabricant ?
Bien modéliser n’est pas un problème d’outillage, mais de méthode : la véritable difficulté est d’appliquer des règles simples, pour aboutir à un modèle qui soit à la fois fidèle et utile. Il ne suffit pas de maîtriser les notations BPMN ou UML : comme pour la musique, savoir lire une partition ne fait pas de vous un Bach ou un Gainsbourg du jour au lendemain !
Pour remédier à cette situation, il convient d’appliquer les dix règles concrètes de modélisation des processus :
1) Distinguer processus et procédure :
Cette règle bien connue est dans les faits très mal appliquée. Rappelons les définitions de l’AFNOR : un processus est un ‘ensemble d’activités corrélées ou interactives qui transforme des éléments d’entrée en éléments de sortie’ alors qu’une procédure est la ‘manière spécifiée d’accomplir une activité’. Bref, le processus décrit uniquement les invariants, c’est-à-dire les règles universelles applicables à toutes les organisations, indépendamment des moyens utilisés pour son exécution. Les moyens sont à décrire dans les procédures. Par exemple, une entreprise peut décider de mettre en place un processus unique et multi-canal pour traiter les réclamations de ses clients. Ce processus se déclinera ensuite selon différentes procédures, selon que la communication avec le client se fait par courrier, par e-mail, ou par téléphone.
Distinguer processus et procédure est la condition indispensable pour identifier les règles communes que l’entreprise s’impose – ou que le monde extérieur lui impose -, et bien les séparer des contraintes liées aux moyens utilisés.
2) Se contenter de 3 niveaux de description :
On rencontre parfois de superbes « chaînes de valeur » où les processus se décomposent en poupées russes. Il est fréquent de devoir explorer 6 ou 7 niveaux de profondeur. D’autres modélisateurs sont des adeptes de la récursivité : un seul concept est mis en œuvre, par exemple l’activité, et une activité peut contenir des activités, et ainsi de suite… Problème : dans les deux cas, ces modèles s’avèrent très vite inexploitables.Par exemple, il est très difficile au modélisateur de déterminer si l’action « contacter le client » devrait se situer au niveau 4, 5 ou 6. Conséquence : le référentiel des processus de l’entreprise contient de nombreux doublons, alors que chaque tâche et chaque activité ne devraient être décrites qu’une seule fois.
Nous recommandons de n’utiliser que trois éléments pour décrire les processus : au niveau le plus détaillé, la tâche, puis l’activité, et enfin le processus lui-même. Un quatrième niveau de description est utile lorsque l’on veut décrire les procédures : nous recommandons d’introduire la notion d’opération. Chaque tâche est alors décrite comme une suite d’opérations. Par exemple, contrôler l’identité d’une personne se décline en plusieurs opérations selon les pays et les supports (carte d’identité, badge, passeport biométrique…)
3) Définir les tâches par la transformation d’un objet Métier :
Toute tâche doit modifier un objet Métier. Par objet Métier, Rhapsodies Conseil entend un élément manipulé au quotidien par les acteurs de l’Entreprise. Il est assez facile de dresser une liste des principaux objets Métiers. Ce sont souvent les mêmes d’une entreprise à l’autre : des produits, des commandes, des contrats, des matériels…La règle permet alors de déterminer quelles sont les tâches qui sont vraiment nécessaires. En effet, comme on l’entend souvent dire, une tâche doit avoir une valeur ajoutée. Un moyen concret de s’en assurer, est de vérifier que la tâche a effectivement modifié un objet. A l’inverse, toute action qui ne modifie rien n’a pas de valeur ajoutée, il est donc totalement inutile de la décrire. L’action « lire le courrier » par exemple n’a aucune valeur ajoutée : ce qui importe vraiment, c’est de déterminer les tâches à exécuter suite à la réception de ce courrier.
4) Faire porter toutes les règles de gestion par des tâches :
Cette règle découle de la précédente. Soit une tâche T1, qui permet de faire passer un objet O d’un état E1 à un état E2. Pour cela, elle doit obéir à une série de règles de gestion. La tâche suivante aura pour but de traiter tous les objets O qui sont dans l’état E2. A ce niveau de description, il est totalement inutile d’ajouter une règle (ou pire, une tâche, comme on le voit parfois) pour indiquer que lorsque la tâche T1 est terminée, alors il faut exécuter la tâche T2. Ainsi, dès le départ, on isole tout naturellement les règles d’enchaînement, ce qui facilite l’utilisation d’outils d’orchestration de processus (BPM, workflow).
5) Appliquer une démarche ‘bottom-up’ :
C’est-à-dire décrire d’abord le niveau le plus fin, les tâches. Celles-ci seront ensuite regroupées en activités, en fonction de règles précises. Ceci évitera de reproduire l’organisation et les règles existantes : il suffit d’identifier l’objet Métier en jeu, l’état final de cet objet, pour déterminer de proche en proche les étapes nécessaires et les autres objets manipulés. Exemple : pour un processus de recrutement, la dernière tâche peut être exprimée par « confirmer l’adéquation du candidat au poste ». On en déduit les tâches antérieures : contrat signé, poste de travail configuré, recrue formée,… Comme on le voit dans cet exemple, on transcende les frontières de l’organisation, qui le plus souvent confie la formation à une entité, la signature du contrat d’embauche à une autre, la configuration du poste de travail à une troisième.
6) Utiliser les évènements avec parcimonie :
Dans la grande majorité des cas, il est inutile de conserver une trace séparée des évènements. Il suffit d’historiserles états successifs par lesquels l’objet Métier est passé, ce qui revient exactement au même. Par exemple, il est bien évident que la tâche « valider une facture » fait passer la facture à l’état validé ; il ne sert donc à rien d’enregistrer dans le système d’information un évènement ‘facture validée’. Il suffit de mémoriser la date à laquelle la facture a été validée, et ce, seulement si on en a vraiment besoin. Cette approche simplifie la mise en œuvre du pilotage de l’activité (BAM) en se concentrant directement sur les résultats, et non sur les évènements.
Bien entendu, certains évènements doivent figurer dans le modèle de processus. C’est en particulier le cas des évènements indépendants de tous les acteurs : par exemple, la fin du mois, pour déclencher un arrêté comptable.
7) Faire porter les activités sur un objet métier unique :
Une activité est une suite de tâches qui portent sur un même objet, et qui a pour but de faire passer cet objet par des états successifs de son cycle de vie. La raison de ce critère de regroupement est purement économique : dans l’idéal, cette série de tâches devrait pouvoir être confiée à un même agent, de manière à éviter les ruptures de charge, toujours coûteuses.
8) Déterminer les rôles à partir des activités, et non l’inverse :
Un rôle doit être vu comme l’ensemble des privilèges nécessaires à un même agent (personne, système…) pour pouvoir exécuter les tâches qui lui sont confiées. Dans l’idéal, comme on l’a vu précédemment, il est plus économique de faire exécuter une activité de bout en bout par le même agent. Toutefois, ceci n’est pas toujours souhaitable, en particulier pour des raisons de sécurité et de contrôle. L’exemple classique est le traitement des factures Fournisseurs : l’agent qui valide une facture ne peut pas déclencher le règlement de celle-ci. Ceci aboutit à définir deux rôles distincts. Contrairement à l’approche couramment pratiquée, ce ne sont donc pas les rôles qui doivent déterminer les activités, mais bien les activités qui doivent déterminer les rôles. Le titre de « Contrôleur de Gestion » par exemple, ne permet pas de déterminer les différentes activités dont un contrôleur de gestion a la charge : celles-ci varient fortement d’une organisation à l’autre. Par exemple, dans certaines entreprises, le contrôleur de gestion approuve les commandes d’investissement; dans d’autres, il valide les factures.
9) Distinguer les pouvoirs des compétences :
Les compétences nécessaires à l’accomplissement des activités n’ont pas à intervenir lorsqu’il s’agit de décrire un processus. Ces compétences seront à prendre en compte dans un deuxième temps seulement, au moment de définir les moyens nécessaires pour exécuter les tâches, c’est-à-dire lorsque l’on déclinera les procédures. Choisir de spécialiser ou non des agents en fonction de leur compétences est une décision purement économique :dans beaucoup de restaurants, le client va se servir lui-même. Et dans certains restaurants, le client cuit lui-même son repas !
10) Tenir compte des intérêts de toutes les parties prenantes :
Ce sera notre critère principal pour déterminer les bornes d’un processus. Un processus n’est que l’un des chemins possibles parmi toutes les activités qui figurent au « catalogue » de l’entreprise : il ne s’arrête que lorsque les intérêts de toutes les parties prenantes sont satisfaits. Par exemple, il y a quelques années, un opérateur de téléphonie mobile prenait la peine d’appeler ses clients dans les 48 heures suivant leur achat d’un nouveau coffret, de manière à s’assurer qu’ils arrivaient bien à l’utiliser. Par ailleurs, on oublie trop souvent les intérêts de l’État, du partenaire à qui il faut verser une commission,… Bien entendu, il ne s’agit pas de dire que toute l’Entreprise peut se réduire à un seul processus !
En conclusion, ces quelques règles basiques garantissent un référentiel de processus homogène : éviter d’avoir 200 actions pour décrire un processus alors que 15 suffisent, éviter des doublons du type « accorder un prêt » et « octroyer un crédit »… Avantage tout aussi important, elles amènent à se poser les bonnes questions au moment de modéliser un processus : et en particulier, distinguer ce qui est vraiment invariant, de ce qui dépend des moyens utilisés. Un modèle construit avec ces règles permettra à l’organisateur de trouver des leviers d’optimisation, et à l’informaticien, de trouver les fonctions à implémenter dans le système informatique.
Remerciements : Rendons à César ce qui lui appartient : si la majorité de ces règles sont ma modeste contribution, je remercie Praxeme qui dès 2003, avait clairement formulé la règle N°3. Merci également au Club des Pilotes de Processus, dont sont tirés quelques-uns des exemples cités.
