Archives du mot-clé Organisation

Manifeste pour du développement de haute-couture

Le développement est une chose trop grave pour être confié à des développeurs. Ce manifeste pour du développement de haute-couture est un appel pour que les entreprises mesurent la nécessité d’un développement maîtrisé et de qualité. enioka Haute-Couture est une maison de développement logiciel qui s’est donné comme mission d’accompagner ses clients dans cette démarche.

La transformation numérique des entreprises révolutionne la façon de travailler dans tous les secteurs, même de ceux à priori éloignés de l’informatique. La plupart des processus métier sont désormais outillés informatiquement, voire ne pourraient exister sans. Cela a une conséquence : la valeur ajoutée d’une entreprise, ce qui la différencie de ses concurrents, est de plus en plus souvent liée à un élément informatique. Tel distributeur aura une chaîne d’approvisionnement plus efficace grâce à des algorithmes de réapprovisionnement innovants, telle banque sera plus rapide sur les ordres à faible latence grâce à des processeurs dédiés, tel constructeur aéronautique pourra éviter de coûteux prototypes grâce à des modélisations plus avancées…

Est-il alors souhaitable de confier les logiciels de l’entreprise, cette pièce critique de la valeur de l’entreprise, à un tiers ? C’est pourtant le mouvement qui a eu lieu depuis les années 90, où les développements ont été massivement externalisés et délocalisés. Et les entreprises ont perdu beaucoup de connaissances sur leurs propres logiciels, y compris les plus critiques d’entre eux.

Notre vision est qu’une entreprise qui innove doit maîtriser ses développements. Pour cela, il lui faut acquérir, ou ré-acquérir, un certain nombre de compétences : techniques évidemment, organisationnelles, méthodologiques, de recrutement…

Cette reprise en main des développements peut se faire progressivement, en commençant par mettre en place organisation, architecture, outillage et équipe de développement pour leur donner les clefs pour créer les solutions nécessaires et répondre aux demandes des clients et utilisateurs.

Le développement logiciel est devenu un enjeu trop important pour qu’une entreprise soit dépendante de ses fournisseurs. Cette indépendance se manifeste à la fois par la propriété intellectuelle sur le code produit, par la capacité à faire évoluer le code source qui doit donc être livré documenté, avec tous les outils nécessaires à le faire vivre (chaîne de compilation, outillage de déploiement, suite de tests, outils de suivi projet) et un transfert des compétences nécessaires assuré. Ces éléments doivent être envisagés dès le lancement d’un projet sous-traité pour s’assurer de la bonne transmission du logiciel.

Si cette mise en place initiale est faite par une équipe tierce, il est alors essentiel qu’elle soit réalisée sur mesure pour les objectifs et contraintes de l’usage par l’équipe finale. Il faut alors, plus encore que d’habitude, insister sur la qualité du développement et de l’outillage instaurés, qui en faciliteront l’utilisation, la reprise et l’extension. La trajectoire permettant de s’assurer que toutes les parties impliquées (utilisateurs, chefs de projet, exploitants, développeurs, architectes, testeurs…) maîtrisent leurs (nouveaux) outils de travail est également essentielle.

Passé ces premières étapes, nos équipes partagent une vision de ce que doit être un projet informatique bien mené. Nous sommes convaincus que les projets informatiques modernes doivent être réalisés en contact direct avec les utilisateurs, sur des cycles de release rapides. Nous apportons en conséquence un savoir-faire pragmatique sur les méthodes agiles : sans les considérer comme sacrées, nous les utilisons comme des boîtes à outils pour en retenir des éléments en fonction du contexte client. Nous voyons l’organisation, les processus, comme une trajectoire menant vers une cible revue régulièrement plutôt que comme une destination fixée trop longtemps à l’avance. On doit se fixer des objectifs à court terme, puis continuer à améliorer de façon continue, et faire en sorte que cela continue de s’améliorer bien après le départ de nos équipes.

Il faut commencer petit pour amorcer un cycle vertueux : une démarche d’internalisation doit commencer petit, et doit faire ses preuves, que ce soit par un petit projet sélectionné ou par un prototype. Nous sommes capables de prendre complètement cette amorce en charge, en la réalisant complètement ou en encadrant les équipes en place.

Ce qu’il faut au bon endroit. Nous sommes également certains qu‘il n’y a pas de technologie miracle, quel que soit le domaine. Ce mythe a fait trop de dégâts par le passé. Les langages, les frameworks, les middlewares… ne sont que des briques dont il faut systématiquement évaluer l’adéquation au contexte.

Nous sommes aussi persuadés que des améliorations sensibles de la qualité des développements sont à la portée de toute organisation qui s’en donne les moyens. En partie grâce au contact métier permanent mentionné plus haut, qui permet d’opérer au plus près du besoin réel. Ensuite, en s’appuyant sur une organisation efficace et adaptée ainsi qu’à un bon outillage des cycles de développement pour assurer la qualité du produit (tests automatiques, processus de revue de code…). Enfin et surtout grâce à des développeurs compétents et responsabilisés sur leurs rôles dans les projets et dans l’entreprise.

C’est pour proposer du développement en accord à ces principes qu’enioka Haute Couture a été créé. Ceci nous permet de proposer à des sociétés, de toute taille et de tout secteur d’activité, de commencer immédiatement à travailler comme si elles avaient internalisé leurs développements tout en progressant vers l’autonomie complète. Tout cela est porté par une équipe désireuse de partager sa vision et son expérience du développement, avec comme objectif d’aider nos clients à (re) devenir maître de leurs développements.

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes entreprises ? (2/5)

Après avoir identifié les questions autour l’organisation du BI et décrit la chaine de valeur du BI classique, l’objectif de ce second article est de répondre à la première de ces questions :

Dans un groupe multi entités, que mettre en commun versus quelle autonomie locale aux entités (branche ou business units) ?

La mutualisation sert des objectifs : réduire des coûts et (éventuellement) tirer des bénéfices plus larges par effets de levier. Quels sont-ils ?

 

Sur l’axe des coûts, quels sont ces coûts et quelles économies y a-t-il à partager ?

Coûts d’infrastructure

En théorie, il y a des gains évident à partager les infrastructures. Mais là les gains ne sont avérés que si la structure d’accueil est compétitive et sait travailler de manière élastique avec les meilleures pratiques. Il reste difficile d’égaler le cloud.

On soulignera tout de même que le brassage de grands volumes de données reste un problème de stockage de données et de performances de ce stockage (dans des ordres de grandeurs qui sont éloignés de ceux des usages classiques du SI). Et donc dans ce domaine, il faut une vraie expertise pour piloter ce stockage. C’est un point de faiblesse des grands du cloud qui se sont surtout développés sur l’axe du très distribué. Et ce modèle ne donne pas toujours de bons résultats, notamment sur un modèle classique de BI à base de « cubes » et de tables de faits.

Coûts de licence

Les gains de coûts à ce niveaux sont essentiellement des enjeux d’achat. Mais a contrario la massification des achats peut avoir des risques de banalisation des coûts et s’avérer à moyen terme un piège. Les vendeurs de licence, notamment pour lutter contre le SaaS ont tendance à abaisser les coûts d’acquisition initiaux pour les masquer par des coûts de fonctionnement totalement distribués (maintenance, audits au bout de 2 ou 3 ans, fonctionnement à l’usage, etc)… Mais sur ce terrain, il y a peu de spécificités, si ce n’est que le modèle de vente adresse structurellement des décideurs et surfent sur l’idée d’une très forte valeur ajoutée métier liée aux outils qui justifient certains excès.

Coûts d’acquisition de données externes

Les coûts d’acquisition de données externes (données de marché, données d’achat, données client ou de zones de chalandise, données géographiques, etc) : là il y a clairement des enjeux de gains et de mutualisation. L’acquisition et la collecte des données externes est un problème, non seulement de coûts purs d’achat, mais également de prise en compte dans le contexte de l’entreprise et de maîtrise de la qualité. Cette fonction mérite d’être mutualisée. La mutualisation permet en outre de donner un accès plus large aux différentes entités qui individuellement n’auraient même pas la connaissance de ces sources de données.

Coûts d’exploitation technique

L’exploitation technique gagne souvent à être mutualisée. Mais c’est surtout vrai s’il y a une cohérence des socles techniques (ie des technologies employées et des manières de les mettre en oeuvre) et une réelle industrialisation de l’exploitation. Un peu comme pour les infrastructures, la mutualisation n’a de sens que si elle s’accompagne d’une réelle maturité, normalisation et automatisation. Sinon on risque d’avoir une structure de coûts peu différente, mais en revanche une lourdeur et une réactivité faibles du fait de la mutualisation.

Coûts d’exploitation applicative

L’exploitation applicative (administration du paramétrage, des référentiels techniques, des outils et applications) est liée au socle technique et à ses normes de mise en oeuvre. Sur des éléments très communs, ou autour de socles ERPs constitués (ex BI autour de SAP), il y a de la valeur à mutualiser autour de bonnes pratiques. Mais les gains sont moindres sur des technologies applicatives encore en plein développement et expérimentation. Là une exploitation partiellement « locale » aux projets concernés par des équipes plus étude fait du sens, même si cela n’est pas une cible pérenne.

Coûts d’administration fonctionnelle

Il s’agit là d’adresser toutes les activités métier de structuration des droits d’accès, des dimensions, des hiérarchies, des indicateurs, voire de la réalisation de certains tableaux de bord ou de restitutions. Celle ci est directement liée à l’organisation métier. Il est souhaitable d’avoir un modèle de proximité fort sur ce volet. Qui peut/doit s’appuyer sur une cellule centrale si la solution est mutualisée.

Coûts de projet

C’est probablement le domaine dans lequel il y a le plus de promesses de gains de mutualisation. Un projet commun semble toujours plus efficace. Et pourtant … Il y a beaucoup d’éléments qui de fait restent spécifiques à l’entité métier, ne serait ce que
l’ensemble des données de base (pour l’essentiel). S’il n’y a pas une volonté commune (plutôt issue des points de gains attendus ci dessous) de mettre en commun certaines données, les bénéfices sont faibles voire sont contre productifs. Quelle valeur y a t il à partager des données ?
S’il y a des bénéfices évidents techniques, cela peut avoir un sens. Par exemple, si plusieurs entités ont des systèmes d’information communs, il y a clairement des économies d’échelle à mutualiser l’extraction des données. Mais si les SI sont hétérogènes, il est très probable que les coûts de convergence seront supérieurs aux gains, avec l’effet néfaste de rendre plus rigide le SI et la solution de BI. En tout cas sur cet
axe, il est dangereux de vouloir partager la solution décisionnelle quand les SI sources sont distincts et hétérogènes et encore plus si l’objectif fonctionnel commun n’est pas fortement sponsorisé au niveau global groupe.

Sur l’axes des bénéfices, quels sont les bénéfices additionnels liés à la mutualisation ?

Cohérence des méthodes et capitalisation des savoir faire

Cela exige qu’une équipe mutualisée fasse justement l’effort de mettre en place ces méthodes et ces savoir faire et de les diffuser. On observe trop souvent des équipes centrales qui ne sont finalement qu’une juxtaposition de compétences personnelles avec des éléments communs peu marqués. Et finalement des gains en comparaison du recours à une équipe d’experts externes assez faibles. Les gains ne peuvent être effectifs que par des formations communes, des méthodologies communes, des outils communs.

Cohérence des données en termes de sémantique

C’est important de partager un vocabulaire commun. Certains indicateurs clés destinés à la comparaison des entités entre elles ou à la mise en commun d’information doivent pouvoir s’appuyer sur des notions communes bien définies.

Fourniture d’éléments de comparaison et de pilotage groupe

Le premier bénéfice d’une équipe mutualisée est bien de porter les éléments mutualisés. Par exemple, dans un groupe avec une structure fortement distribuée comme PPR, les indicateurs de pilotage de chaque activité sont extrêmement normés. Et la solution qui les exploite en central est commune. C’est aux équipes centrales de piloter des indicateurs communs. Et en cela l’organisation BI ne peut que refléter celle métier. J’ai un client qui a mis en place des outils d’analyse des achats groupe, mais sans « vraie » équipe achats groupe. Celle ci ne commence à prendre son intérêt que maintenant que cette structure se met en place et prend de l’épaisseur. Une telle mutualisation peut d’ailleurs tout à fait rester segmentée par domaines fonctionnels en se concentrant ceux où la mutualisation et le benchmarking des entités à une réalité métier de gains. Par exemple les achats, le pilotage financier, le marketing et la relation client à 360….

Levier des données entre business

Les entités entre elles peuvent potentiellement tirer levier de la connaissance d’indicateurs de leurs entités soeurs. Pour se comparer, avoir des éléments d’information connexes, etc..Mais ce partage n’est possible qu’avec le partage de certaines notions et données…

La maîtrise de certains risques

La maîtrise de certains risques (notamment de confidentialité des données) : plus les structures sont distribuées et éparses, moins elles sont sensibilisées aux risques. La mutualisation du pilotage des risques est intéressante. Elle ne s’accompagne pas nécessairement d’une mutualisation technique des solutions et des moyens … Une telle
centralisation en tout cas crée un risque structurellement plus important qui mérite une attention encore plus grande. Par exemple une mutualisation technique des moyens exige une mutualisation de la politique de sécurité.

La valorisation des données à l’extérieur

Cela est un peu nouveau… mais la donnée peut de plus en plus se monétiser à l’extérieur de l’entreprise. Cela peut donner lieu à du troc (information contre information), ou faire partie de la valeur offerte à ses partenaires. Par exemple de la donnée à valeur ajoutée à fournir aux distributeurs sur les profils de clients cibles ou sur les éléments clés de défilement d’un produit… ou vers des partenaires pour du cross selling (ne serait ce qu’en intra groupe).

Les risques à trop mutualiser…

Il y a des risques en revanche à trop mutualiser, ou à mutualiser trop vite sans alignement métier et/ou du reste des SI :

  • Une perte d’agilité et de « time to market »
  • Une promesse de gains de mutualisation pas atteints
  • Une lourdeur et une structure de coût récurrents élevés

Conclusion

En résumé, c’est peut être une tautologie, mais il convient de bien analyser ce qui gagne à être mutualisé versus ce qui apporte peu de gains à l’être.

… et à prendre les options les plus efficaces. Il est dangereux en tout cas d’excessivement centraliser et mutualiser, si on ne prend pas les actions qui permettent de réellement tirer les bénéfices attendus quels qu’ils soient. Une des caractéristiques de la BI moderne c’est qu’elle ne vise plus tant à satisfaire les envies de beaux tableaux de bord de grands managers, mais à donner aux entreprises des possibilités de prises de décisions et d’optimisation du fonctionnement qui peuvent conditionner sa survie. Il vaut mieux une solution sous optimale en termes de coûts informatiques qui donnent des réponses maintenant aux vrais problèmes posés qu’une solution théorique qui répondra demain à des questions qui n’existeront plus…

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes entreprises ? (1/5)

Les activités de Business Intelligence et de Big Data, de part de leur aspect parfois très transverse, posent beaucoup de questions sur l’organisation à mettre en oeuvre pour en assurer la réussite et l’efficience.

Plus spécifiquement, les questions qui se posent sont :

En introduction, l’activité de BI étendu intégrant les nouvelles méthodes et outils d’analyse de données du big data, a beaucoup évolué sur les 20 dernières années.

D’abord une simple consolidation de données en Infocentre, puis les grands programmes dataware house qui espéraient extraire de manière exhaustive toute l’information pour la ranger dans de grands entrepôts de données très structurés, puis les initiatives plus réactives commençant à valoriser cette information de plus en plus en temps réel
sur des niches et avec une décentralisation des sujets par grands pans fonctionnels (marketing, ventes, production, achats, contrôle de gestion).

Plus récemment de nouveaux types de données changent et enrichissent la donne : données issues des objets connectés, de la mobilité, des réseaux sociaux, de l’open data… Les sources de données se multiplient en termes de natures/structures et d’acteurs. Au delà les technologies d’analyse de données se « vulagrisent ». Non pas qu’il y ait vraiment de révolutions, mais plutôt que des technologies d’exploitation des données deviennent de plus en plus praticables à grande échelle : machine learning, modèles de prévision, analyse de graphes, …

Du coup, les questions précédentes prennent un relief particulier… Il n’y a pas un seul modèle de BI, (et donc d’organisation à mettre en place) mais plusieurs et qui seront variables selon les maillons de la chaine de valeur du BI.

La chaine de la valeur classique d’une BI étendue

Acquisition

Aller chercher la donnée dans les systèmes opérationnels doit rester la responsabilité de la DSI. Ponctuellement un quick win peut être obtenu avec des solutions agiles comme QlikView ou Tableau qui s’alimentent directement dans des bases d’applications métier. Cela ne peut pas être une solution pérenne. Et doit être géré par des équipes DSI classiques.

Consolidation & mise en qualité

Cette fonction est probablement celle qui va/doit le plus changer. La vision d’une dataware house urbanisé qui passe par des étapes très structurées ne répond plus aux enjeux de rapidité. Il vaut mieux vivre avec les anomalies que de chercher à les corriger toutes. Il y a un vrai enjeu pour la DSI a essayer de mettre à disposition l’information de manière très efficace et réactive. Sans faire trop d’hypothèses sur les usages qui en seront faits. C’est un élément qui fait du sens à partager, surtout pour les éléments les plus volumineux et critiques. La source du big data interne en quelque sorte.

Structuration

La structuration en tables de faits et/ou cubes. Cela existe et existera toujours. Mais cette dimension structurée et institutionnelle n’est que la partie émergée de l’iceberg. Qui n’est plus nécessairement là où est la plus grande valeur. On structure les problèmes que l’on connaît et que l’on maîtrise. L’objectif aujourd’hui devient de découvrir de nouveaux gisements… Pour la partie structurée en charge de produire des indicateurs de pilotage opérationnels aux différents de l’organisation, une démarche classique DSI est utile pour assurer la qualité des données et leur mise en cohérence. Mais éventuellement à scinder entre ce qui est commun groupe et ce qui est propre à des branches voire BUs.

Pilotage des indicateurs

Cela reste un élément clé de communication. Avec un besoin de qualité sur la sémantique des indicateurs publics. Rien de plus destructeur que des chiffres divergents et incohérents …

Analyse des données

C’est un domaine en pleine explosion, avec des outils, méthodes en grande effervescence. Il faut privilégier de l’agilité. Et permettre les explorations tactiques et agiles sur le stock de données brut consolidé. C’est un des endroits où cela bouge le plus et où les technologies sont les plus complexes et liées aux typologies de problèmes.

Calcul de données opérationnelles  et réinjection dans les systèmes opérationnels

Ces options se développent de plus en plus. Le BI et le Big Data participent du SI. Il ne s’agit plus simplement d’indicateurs passifs, mais de solutions de plus en plus intégrées aux processus opérationnels. Pour piloter les réappros, la production, les stocks, les prix, les ventes, … Ces boucles donnent à ces technologies une criticité tout à fait nouvelle. Qui doit être sécurisée quand elle en vient à piloter l’opérationnel et le mettre en péril. Celles ci sont impérativement à mettre sous le contrôle d’une DSI.

Le prochain article de cette série reprendra les questions posées en introduction et proposera des éléments de réponse.