Sourcing informatique : cinq modèles de base Richard Peynot JEMM Vision Février 2012
JEMM Vision 2012 1
Sourcing informatique : cinq modèles de base L externalisation informatique a connu depuis la dernière décennie quelques vagues et tendances, parfois opposées et simultanées : méga-contrats, consolidation de contrats dispersés, réduction drastique du nombre de fournisseurs, recherche de spécialistes «best-of-breed» (à l inverse de la consolidation), etc. Les clients finaux, mais aussi les offreurs de solutions, ont besoin de structuration et de modèles de réflexion. Nous présentons ici les modèles de base de sourcing, autour desquels chacun peut bâtir sa propre solution. Nous analysons les intérêts, les risques, les tendances et les situations les mieux adaptées pour chacun de ces modèles. Enfin il convient de distinguer les modèles de sourcing et les «types de relation de sourcing», autrement dit les montages possibles pour les mettre en œuvre : certaines confusions existent malheureusement sur le marché. JEMM Vision 2012 2
Table des matières Le sourcing informatique... 4 Les modèles de sourcing... 5 Le besoin de structuration... 5 Les constituants du système d information... 6 Cinq modèles de base... 7 L externalisation globale... 9 L externalisation de l infrastructure... 13 L externalisation des applications... 17 L externalisation verticale : BFO et BPO... 21 Le multi-sourcing sélectif... 23 Ces modèles de base ne s excluent pas... 26 Comment choisir le bon modèle?... 28 Le multi-sourcing maîtrisé... 29 Trop de prestataires de services informatiques est coûteux... 29 Des opérations de rationalisation drastiques ont parfois été trop loin... 29 Rationaliser et optimiser le multi-sourcing... 30 Conclusion : rationalisation et multisourcing convergent... 33 Ne pas confondre modèles de sourcing et «business models»... 35 Le risque de confusion... 36 Quel est l impact du cloud computing dans ces approches?... 38 Nos recommandations... 39 JEMM Vision 2012 3
Le sourcing informatique Sourcing. Voilà un terme anglais bien difficile à traduire. Du coup les francophones reprennent ce vocable en anglais. Disons que le sourcing informatique, ou sourcing IT, est la façon dont une entreprise réalise ou fait réaliser ses activités informatiques 1. On parle d insourcing, ou d internalisation, lorsque le personnel interne à l'entreprise réalise les activités, et d outsourcing ou d externalisation 2 lorsque du personnel externe réalise les activités. Une stratégie de sourcing est un ensemble de règles et d orientations qui conduisent à un découpage en domaines dont les activités sont réalisées en interne ou externalisées. Malheureusement trop de sociétés n ont pas de vraie stratégie de sourcing ou n en ont que des bribes. L externalisation n est évidemment pas une fin en soi, mais une approche qui permet à une DSI de confier à des spécialistes performants : - des activités qu elle assure de moins en moins bien (disparition de compétences due aux départs en retraite, au turn-over et à l évolution des développeurs), - des activités pour des projets techniques trop risqués (migrations techniques, remplacement de parcs applicatifs par une solution unique à base d un progiciel, développements et déploiements lourds liés à des transformations de processus métiers), - des activités devenues trop coûteuses (opérations, maintenance, développement), - et des activités qui absorbent trop de talents qui lui font défaut sur les nouveaux projets (la maintenance accapare durablement des profils souhaités ailleurs). L externalisation judicieuse de ces domaines permet à la DSI de se concentrer sur ses vrais défis : être le partenaire stratégique des métiers, le moteur de la transformation numérique de l entreprise et un promoteur de l innovation. 1 http://dictionary.reference.com/browse/sourcing donne la définition suivante : «the buying of components of a product from an outside supplier,often one located abroad» 2 Dans la suite du document, nous utiliserons indifféremment les termes externalisation ou outsourcing JEMM Vision 2012 4
Les modèles de sourcing Le besoin de structuration De nombreuses entreprises ont été déçues par certaines expériences d externalisation, ou considèrent qu elles n en bénéficient pas pleinement. Parfois la situation est totalement inefficiente et nécessiterait une restructuration complète. On en est arrivé là parce que les entreprises ont manqué de vision stratégique de leur sourcing. Les raisons sont multiples. - Sans clause d évolution, des contrats d externalisation globaux sont devenus trop rigides avec le temps. - Des situations de «poly-sourcing», c est-à-dire de multiples contrats et autant de prestataires, se sont développées au cours du temps. Elles résultent de décisions prises projet par projet. Des entreprises ont 50, 100 et même 200 sociétés de soustraitances présentes dans leurs locaux et qui se partagent de petits lots. Trop de sous-traitants, trop de contrats à gérer et à renouveler, finissent par limiter les marges de négociation et surtout par affecter la cohérence et l efficacité de l ensemble. - Des cas d infogérance «sur-site» mêlent de nombreux prestataires et des ressources internes dans les mêmes équipes. Il en résulte une dilution des responsabilités. Du reste nous ne considérons pas les nombreux informaticiens en régie, dispersés dans les équipes du client, comme une réelle externalisation. Il s agit de renfort des effectifs par apport extérieur («workforce augmentation» disent les Américains). - Le manque de coordination entre équipes et l absence d un réel responsable de la stratégie de sourcing conduisent à des contrats différents dans leurs objectifs et dans leurs termes, à la prolifération des fournisseurs qui sont sélectionnés avec des critères différents. On observe même des situations incongrues où des projets ont été sous-traités par manque de ressources ou de compétences alors qu elles étaient disponibles dans un département voisin. - Certaines sociétés vivent sous le règne des chasseurs de coûts (les «cost-killers») : des personnes mandatées en mission transversale sur l ensemble de la société, ou des responsables des achats. Leur obsession de la réduction des coûts se traduit par la pression sur les prix des fournisseurs. - Les différents niveaux de décision dans l entreprise ont des vues, conceptions et intérêts pas toujours convergents et pas concertés. Directeurs financiers et acheteurs peuvent grouper leurs points de vue pour une simple et forte pression sur les prix. Le directeur des systèmes d information recherche plutôt à remettre de l ordre dans la sélection et la gestion des fournisseurs de service, et voudrait mettre sur pied une stratégie de sourcing basée sur un découpage en domaines. D autres dirigeants, à commencer par la direction générale, se sont laissés parfois intoxiquer par cette idée que l informatique faisait partie des «utilities» ou «commodities» au JEMM Vision 2012 5
même titre que l électricité, l eau et le restaurant d entreprise 3. De cette idée ils pensent qu il est nécessaire et facile d externaliser massivement. - On constate encore un manque de vrai processus de suivi et d évaluation périodique des fournisseurs de services informatiques. Bien souvent ce sont les équipes informatiques qui gèrent elles-mêmes les difficultés, y compris contractuelles, avec les fournisseurs. Tous ces problèmes sont bien visibles et devant ce constat, les entreprises expérimentées ressentent le besoin de mieux structurer l externalisation. Même les entreprises les plus matures, qui ont résolu la plupart des difficultés que nous venons de citer, ressentent le besoin d une meilleure structuration et d une meilleure vision de leur stratégie de sourcing à moyen voire long terme. Élaborer une stratégie de sourcing informatique nécessite de prendre en compte de nombreux paramètres. Les combiner est un exercice complexe qu il convient de mener avec méthode. Les constituants du système d information Pour nous aider à définir des modèles d outsourcing, nous considérons les principales couches du système d information (figure 1) : 1. Les réseaux : LAN, WAN, VoIP, 2. L infrastructure matérielle qui comprend les matériels (serveurs, systèmes mainframes, et postes de travail) avec leurs logiciels d exploitation respectifs, 3. Les moyens de stockage 4, 4. L infrastructure logicielle, c'est-à-dire la couche de logiciels techniques que l on appelle aussi «middleware», 5. L ensemble des applications d entreprise. 3 Voir la note JEMMVision «Utilities et commodities : un vocabulaire inapproprié qui fait oublier la complexité de l infrastructure informatique», http://www.jemmvision.com/l%e2%80%99infrastructureinformatique-deviendrait-une-%c2%ab-commodit%c3%a9-%c2%bb-un-vocabulaire-malheureuxqui-fait-oubli. 4 Il peut paraître étonnant de séparer l infrastructure serveurs de l infrastructure de stockage. Le «stockage as a service» est devenu une tendance forte dans le monde grand public (avec des offres telles que Amazon Simple Storage Service, icloud, Dropbox, Picassa, Google Storage, etc). La question est de savoir si le marché se développe pour les entreprises. On ne le voit pas vraiment aujourd hui pour les grandes entreprises mais certaines TPE et PME s y intéressent. JEMM Vision 2012 6
CRM ecommerce Décisionnel Knowledge management ERP SCM Procurement Finance RH ECM - EDM Automatsation Syst. indiustriels CAD/CAM PLM APPLICATIONS Messagerie Sécurité Annuaires Gestion bases de données et stockage Intégration de données Intégration d applications Portails BPM Monitoring Asset management MIDDLEWARE Unix Linux AS400 OS390 Windows SERVEURS, STOCKAGE ET SYSTEMES D EXPLOITATION RESEAUX Figure 1 : les constituants du système d information Cinq modèles de base Cette représentation du système d information en grands domaines nous permet de reconnaitre plus facilement les situations d outsourcing des entreprises. Après avoir observé le marché, parlé à plus de cent entreprises, et conseillé plus de 50 ou 60 clients sur leur stratégie et leurs contrats d outsourcing, et ce pendant près de dix ans, nous sommes arrivés à la conclusion que l on pouvait classer les scénarios d outsourcing en cinq grandes catégories. On peut couvrir à peu près toutes les situations avec ces modèles. Bien entendu il s agit de modèles de base qui supportent quelques variantes. Nous discutons ces cinq modèles dans les sections qui suivent : 1. L externalisation globale ou «global outsourcing» : externalisation totale ou quasitotale de l ensemble du système d information. 2. Externalisation de l infrastructure : un prestataire unique ou principal gère l ensemble ou une grande partie de l infrastructure (ce peut être la totalité serveurs-stockagemiddleware, ou seulement serveurs-stockage). 3. Externalisation des applications : un ou plusieurs prestataires sont chargés des développements, de la maintenance et parfois de la gestion d une partie des applications. JEMM Vision 2012 7
4. Externalisation verticale : les systèmes de toute une fonction ou de tout un processus de l entreprise sont externalisés. Dans ce cas, matériels, middleware et applications nécessaires au support du processus sont groupés pour constituer un lot cohérent ; 5. Le multi-sourcing sélectif : il consiste à externaliser par lots. Les lots correspondent à des périmètres bien précis dans chacun des grands domaines (applications, infrastructure matérielle, infrastructure middleware, réseaux). JEMM Vision 2012 8
L externalisation globale Un seul prestataire de services prend en charge l ensemble du système d information : - Les développements applicatifs, la maintenance des applications, la gestion des changements et l exploitation au quotidien (maintien en conditions opérationnelles, adaptations mineures, gestion des droits d accès, ajout/retrait d utilisateurs, arrêts/relances, monitoring/contrôle). L ensemble de ces activités est appelé «application management» dans la terminologie anglo-saxonne. - La gestion et l exploitation des logiciels techniques : maintien en conditions opérationnelles, adaptations mineures, gestion des droits d accès, reconfiguration de logiciels d intégration (EAI, ESB, BPM), arrêts/relances, monitoring/contrôle, sauvegardes. - Les opérations liées au bon fonctionnement des matériels, la gestion de la disponibilité et les plans de secours. - La gestion des réseaux. Peu d acteurs de services informatiques sont réellement capables d assurer cette activité. Si elle est incluse dans le contrat global, alors bien souvent cette partie est sous-traitée à un spécialiste réseau. Dans une telle situation, la direction des systèmes d information est réduite à une équipe responsable principalement : - Du suivi et du contrôle de la bonne qualité des services, et de la gestion du ou des contrats avec le prestataire. - Des relations avec les utilisateurs : une cellule d interface maîtrise d ouvrage maîtrise d œuvre reste garante de la définition des applications confiées au prestataire. De tels contrats se traduisent généralement par d importants transferts de personnels du client vers le prestataire. Il s agit là d un modèle général, auquel on peut rattacher quelques variantes (figure 2). En effet l entreprise utilisatrice peut choisir de séparer la gestion purement informatique et la gestion des réseaux, en confiant celle-ci à un spécialiste télécom. Séparer l infogérance bureautique est aussi une pratique courante. JEMM Vision 2012 9
Applications 1) Un seul contrat global, opérations réseaux éventuellement sous-traitées à un opérateur télécom. Serveurs Réseaux Applications Applications Serveurs Réseaux Serveurs Réseau 3) La gestion des postes de travail fait l objet d un contrat séparé, confié à un spécialiste 2) La gestion des réseaux fait l objet d un contrat séparé, avec un opérateur télécom! et la combinaison (2)+(3) Figure 2 : les variantes de l outsourcing global. Vécu et exemples Un tel choix résulte généralement d une stratégie globale d entreprise, qui vise à externaliser le maximum de fonctions dites «non cœur de métier». Peu de DSI choisissent ce modèle d elles-mêmes, il leur est la plupart du temps «suggéré» voire imposé par la direction générale. En France on peut citer l exemple de Schneider Electric qui, en 2005, a externalisé la quasitotalité de son informatique chez Capgemini (à l exception des systèmes de R&D restés en interne avec l appui technique d IBM) dans ce qu on nomme un «mega-deal». Il y a peu d exemples de contrat de taille comparable en France. Certaines PME ont également opté pour ce modèle. Avantages Un seul opérateur global qui assure le fonctionnement et l évolution de l ensemble de votre informatique : certains dirigeants en rêvent. Il faut bien reconnaître que ce modèle peut fonctionner et fournir à l entreprise une très bonne informatique, à condition que la relation client-fournisseur soit un vrai partenariat qui inclut des partages de responsabilités et des partages de gains lors d opérations permettant la réduction des coûts. JEMM Vision 2012 10
Risques Quatre risques majeurs guettent les entreprises qui optent pour cette solution : - Dépendre d un seul fournisseur : cela est critique en cas de défaillance de celui-ci. Le cas de son rachat par un autre prestataire peut poser un problème si l acquéreur est concurrent du client (ou filiale d un groupe concurrent), ou si le nouveau prestataire adopte un comportement différent (renégociation, augmentation des prix, relations purement contractuelle et non plus de partenariat). - Avec le temps, la perte de compétence et la perte de maitrise du système d information. Certaines sociétés se sont ainsi retrouvées, après quelques années, totalement incapables de valider une évolution majeure ou un choix d architecture proposés par le prestataire. - L extrême difficulté à décrire de façon contractuelle l évolution du système d information (rénovation matérielle, évolution applicative, évolution du périmètre et du volume, transformation du SI en particulier l évolution du parc applicatif) et l évolution des services au cours du temps. - Certaines directions générales voient là une simplification à l extrême de sa direction des systèmes d information, réduite à une unité de dialogue et de contrôle, interface entre les métiers et le prestataire de services. Elles peuvent penser que l ensemble des problèmes à gérer et la responsabilité de la bonne fourniture des services sont totalement déportés sur le prestataire, ce qui est une grave erreur : quel que soit le contrat, c est bien la DSI qui reste responsable et garante du système d information vis-à-vis de l entreprise. Tendances Ce type d outsourcing est plutôt en déclin dans les très grands comptes. Ces grandes entreprises utilisatrices tendent à ne pas renouveler ces contrats et cherchent plutôt à les découper en lots c est du multi-sourcing, un modèle étudié plus loin. La rigidité des contrats et les déceptions sur les niveaux de services en sont les raisons principales. Les contrats d outsourcing global donnent parfois lieu à une co-entreprise (le vocabulaire anglais «joint-venture» ou JV est souvent utilisé) entre le client et le prestataire. Cette étape intermédiaire, au terme de laquelle le prestataire devient actionnaire à 100 % de la coentreprise 5, permet de gérer progressivement le transfert des actifs matériels et logiciels, et peut faciliter l acceptation des transferts de personnels. Le succès de ce type de contrat est lié aux progrès que doivent faire les utilisateurs dans la gestion des contrats, le contrôle du prestataire, leur capacité à gérer les changements avec le prestataire. Dans quel cas recommander ce modèle Ce modèle peut convenir aux TPE, PME et grandes PME qui se trouvent confrontées à la complexité technique, au manque de ressources compétentes, aux faibles moyens pour continuer à faire évoluer leur système d information. 5 En principe les co-entreprises ou JV ne sont pas faites pour durer indéfiniment. Cinq ans est la durée la plus courante. JEMM Vision 2012 11
JEMM Vision 2012 12
L externalisation de l infrastructure Certaines sociétés ont choisi de n externaliser que l infrastructure en la confiant à un prestataire unique. Plusieurs variantes de l infrastructure sont rencontrées. Il s agit parfois seulement de l hébergement des matériels et des systèmes d exploitation, l exploitation étant encore réalisée par le client. Plus souvent le contrat inclut toutes les opérations de pilotage et de maintien en conditions opérationnelles des serveurs, mainframes et postes de travail, ainsi que l ensemble des logiciels techniques. Les entreprises optent pour ce modèle dans deux cas de figure qui d ailleurs ne s excluent pas : - C est un premier pas vers l externalisation : la gestion d infrastructure est un domaine très «procéduré», souvent jugé plus facile à isoler et externaliser. - Avec le temps, le pilotage de l infrastructure a pu devenir peu performant : les utilisateurs sont insatisfaits, les coûts, en particulier salariaux, sont élevés, il y a eu peu ou pas d introduction de nouvelles méthodes. Dans un tel contexte, on a souvent vu des directions générales impatientes pousser leur DSI à externaliser les opérations vers un spécialiste censé apporter expertise, méthodes et structuration. Dans ce type de contrat les transferts de personnels du client vers le prestataire sont fréquents. Il s agit là encore d un modèle général supportant quelques variantes, selon que les réseaux et les postes de travail sont dans le contrat principal ou confiés séparément à des spécialistes (figure 3). JEMM Vision 2012 13
Applications 1) Un seul contrat global, opérations réseaux éventuellement sous-traitées à un opérateur télécom. Serveurs Réseaux Applications Applications Serveurs Réseaux Serveurs Réseau 3) La gestion des postes de travail fait l objet d un contrat séparé, confié à un spécialiste 2) La gestion des réseaux fait l objet d un contrat séparé, avec un opérateur télécom! et la combinaison (2)+(3) Figure 3 : les variantes de l externalisation de l infrastructure. Vécu et exemples Au schéma général de la figure 3, il faut mentionner d autres variantes : - L hébergement des serveurs et des moyens de stockage est assuré par un «hébergeur pur» et l exploitation assurée par un prestataire de service. Par exemple Interxion, Global Switch, Colt hébergent des datacenters opérés par Capgemini, Intrinsec, BT, IBM, etc pour le compte de leurs clients. - L infrastructure matérielle (serveurs et stockage) est gérée par un infogérant, les middleware le sont par un autre infogérant, spécialisé. Un grand opérateur télécom avait ainsi confié à Sogeti la supervision de ses équipements, et à Sopra l infogérance de l EAI Axway 6. - C est le modèle choisi par les entreprises qui ne sont pas prêtes à externaliser leurs applications et qui se limitent aux opérations dans un premier temps. - Certaines sociétés veulent mettre fin à une situation dans laquelle il y a une trop grosse part d assistance technique (AT) dans leurs équipes, pouvant dépasser 50%. Une telle masse d AT revient trop chère et demande un effort de gestion 6 Contrat Sopra 2002 prolongé en 2005. Nous n avons pas connaissance de l état de ce contrat aujourd hui. JEMM Vision 2012 14
(renouvellement de nombreux petits contrats, recrutement). De plus en AT le prestataire n a pas d engagement de résultat ni de respect d indicateurs. - C est souvent le seul moyen de faire prendre un virage important dans la structuration et l amélioration du service, et d introduire le cadre ITIL 7. Les contrats de ce type sont nombreux en France où tout ou partie de la gestion l infrastructure est confiée à un prestataire de service qui opère les systèmes depuis ses «command centers», les serveurs étant hébergés chez le client, chez le prestataire luimême s il a ses propres datacenters, ou chez un hébergeur. Les contrats d outsourcing d infrastructure peuvent aussi donner lieu à des co-entreprises entre clients et prestataires. Un exemple connu et réussi en France est la structure BPPI, coentreprise entre BNP-Paribas et IBM 8. Avantages - La plupart des SSII spécialisées dans la gestion d infrastructure atteignent des niveaux de qualité et productivité que les DSI peuvent difficilement atteindre. Les clients profitent de l industrialisation, de l automatisation et de la mutualisation de moyens de SSII. - Les infogérants sont capables de monter et assurer des solutions de redondance de systèmes (dual-room, dual-site 9 ), de PCA/PCS 10 et des PRA 11 pour les systèmes critiques, toutes solutions techniques difficiles à maitriser par une DSI. - On peut pousser le modèle plus loin en transférant la propriété des matériels vers l infogérant qui en facture alors la location au client. Le client s affranchit ainsi des investissements et remplace du CAPEX (en l occurrence dépenses d investissement en matériel) par de l OPEX (en l occurrence dépenses en achat de services). Risques Vouloir externaliser un département qui ne donne pas satisfaction et que l on juge trop difficile à transformer risque d être interprété comme une «externalisation sanction». Le personnel réagit très mal à une telle approche. S il est transféré dans le cadre du contrat, certaines personnes peuvent se montrer très peu coopératives. Il est donc indispensable de préparer l opération et de communiquer avant toute rumeur, et en présentant l intérêt pour le personnel (et pas seulement pour l entreprise) : perspectives de carrière plus variée, volume de formation plus élevé, rémunération, etc. 7 ITIL : Information Technology Infrastructure Library. C est un cadre méthodologique pour la gestion des activités de management des systèmes d information. ITIL a d abord été norme britannique avant d être normalisé au niveau international dans la norme ISO/CEI 20000. La plupart des grandes SSII maitrisent et appliquent ITIL, ce qui est moins vrai dans les DSI. 8 «BNP Paribas et IBM signent une extension de contrat de services informatiques d une durée de 6 ans.» (http://www-03.ibm.com/press/fr/fr/pressrelease/36368.wss). 9 Dual-room : les systèmes critiques ont un «clône» prêt à redémarrer en cas de panne ou accident, dans une salle voisine, sur le même site. Dual-site : les systèmes de secours sont un site distant ; c est une solution plus onéreuse mais qui est de plus haute sécurité vis-à-vis des accidents majeurs (incendie, inondation, panne électrique majeure). 10 PCS : plan de continuité de service. PCA : plan de continuité d activité. 11 PRA : plan de reprise d activité. JEMM Vision 2012 15
A terme l entreprise peut craindre la perte de la maitrise de son architecture. A elle de conserver le périmètre de la conception de son système d information et donc les personnes clés pour cela. Enfin, si l opération se limite à la reprise du personnel par l infogérant et qu il maintient la même équipe, avec les mêmes managers et les mêmes méthodes, on voit mal comment le service sera subitement amélioré ni comment l infogérant pourrait être moins cher en appliquant une marge à des salaires maintenus. Il ne peut y avoir de vrai changement et de vrai progrès que si l infogérant : - forme le personnel transféré sur ses méthodes, ses outils et sur «l esprit service» (qu il n a pas toujours en entreprise), - effectue quelques changements (éventuellement en affectant quelques personnels repris vers d autres missions, pour d autres clients), - impose son management et ses méthodes. Tendances Ce modèle est assez apprécié en ce moment en France. Alors que la Grande-Bretagne et les pays scandinaves externalisent beaucoup plus et depuis plus longtemps que la France, l Allemagne et la France ont une approche assez similaire. Externaliser l infrastructure semble aux DSI plus facile à réaliser et plus facile à faire accepter : en effet bien des entreprises, sous la pression des métiers, veulent encore garder la main sur les applications. Depuis deux ou trois ans les DSI éprouvent l envie d externaliser les opérations pour faire transformer et industrialiser ce métier qui a pu se scléroser avec le temps. Une autre tendance visible sur le marché, et possible grâce à des offres de qualité sur le marché, est d étendre le périmètre des services au-delà du maintien en conditions opérationnelles (MCO) de l infrastructure, en incluant le MCO des applications : leur surveillance, l intervention sur les arrêts-relances, la surveillance et le tuning des bases de données, le dimensionnement des disques, certains actes d administration, voire du support applicatif 12. Dans quel cas recommander ce modèle Ce modèle convient à tout type d entreprise. Il est particulièrement indiqué si l entreprise «sent» ou a fait mesurer, par un benchmarking, que sa performance dans la gestion d infrastructure n atteint pas le niveau des meilleures SSII. Il convient également dans les situations de transformation, migration technique importante, refonte d architecture, fusion de DSI (consécutive à une fusion de sociétés), toutes situations à haut risque pour lesquelles l expérience, les ressources et les moyens d une grande SSII sont supérieures à ceux de l entreprise elle-même. 12 Un prestataire comme Oxya en a fait sa spécialité sur les logiciels SAP. T-Systems, Euriware, Capgemini, Atos, Bull sont ses principaux concurrents sur ce marché porteur. JEMM Vision 2012 16
L externalisation des applications L externalisation des développements est en fait la plus ancienne forme d externalisation tout le monde la pratique depuis les années 70. Mais curieusement on n a jamais vraiment appelé «externalisation» les projets confiés au forfait, ni les agents prestataires dispersés dans les équipes internes dans un mode «assistance technique» (AT) ou «régie» 13. Aujourd hui lorsque l on parle d externalisation applicative, on se réfère au concept anglosaxon «d application management», qui va plus loin que l externalisation de projet, et qui comprend les domaines suivants : - Développement d application et intégration de systèmes. - Maintenance corrective et évolutive, et support technique. - Maintenance préventive. - Opérations de contrôle des applications et maintien de leur disponibilité, gestion des droits d accès, et paramétrage. - Support utilisateurs. Comme nous le montrons dans la figure 4, les DSI externalisent rarement l ensemble de leur domaine applicatif, mais une partie seulement. C est à la stratégie de sourcing de définir quels sont les domaines externalisables et ceux qui ne le sont pas. Figure 4 : externalisation des applications L exemple de la figure 4 comprend l ensemble des services «d application management». Vécu et exemples C est un modèle très répandu, retenu par les sociétés : 13 L achat de prestations en mode régie est un modèle en déclin en raison des diverses difficultés qu il porte. Il peut poser des problèmes de droit du travail (subordination d employé, prêt de personnel, délit de marchandage). Et le manque de définition et délimitation des tâches ouvre la porte aux «régies qui durent indéfiniment» dont le coût devient lourd. Pour cela les services achats organisent les tâches en lots de façon à les «forfaitiser», mais le mode de calcul du prix reste basé sur un volume multiplié par un taux journalier moyen (TJM). Ce n est que de la régie ou AT un peu plus structurée. JEMM Vision 2012 17
- Qui manquent de ressources et de compétences pour faire face à tous leurs développements applicatifs et à la maintenance, - Qui ont des opérations d infrastructure performantes et qui tiennent à les garder ainsi, - Ou dont l infrastructure est difficile à externaliser. Les raisons peuvent être variées : parc dispersé, hétérogène et obsolète, impact social important et dissuasif pour transférer le personnel, confidentialité, etc. A titre d exemple la DSI de PSA Peugeot Citroën est dans les deux premiers cas de figure (Recours à un certain nombre de prestataires pour une bonne part des projets applicatifs et de la maintenance, alors que les data centers de PSA sont maintenus en interne, grâce à un niveau de performance très élevé des équipes d exploitation). l existe des cas d entreprises qui gèrent leur infrastructure et ont confié la totalité ou quasitotalité de leurs développements à des SSII. Une variante consiste à conserver et maitriser la conception et le développement d applications (y compris en recourant à l AT) et à externaliser la totalité des tests (TRA : tierce recette applicative) et la maintenance (TMA : tierce maintenance applicative) (figure 5 ci-dessous). Expression de besoins métier Spécifications système Tests d integration Test techniques : Performance Charge Stress Sécurité Tests utilisateurs Industrialisation Pré-production Production Maintenance Contrat de TMA Spécifications fonctionnelles Contrat de TRA Conception Tests d assemblage Conception technique détaillée Tests unitaires Développement Figure 5 : la place de la TRA et de la TMA JEMM Vision 2012 18
En France les exemples les plus significatifs se trouvent parmi certaines banques qui ont recours à des centres de services pour leurs développements applicatifs, les tests et la maintenance. Avantages - Structuration du sourcing applicatif en créant une séparation claire des domaines devant rester internes (pour des raisons de confidentialité, savoir-faire, stratégie) et de ceux pour lesquels il est bénéfique de les externaliser (accès à des compétences et/ou des ressources manquantes). - En externalisant la maintenance, les tests et certains développements, on libère des ressources internes critiques et expérimentées pour les affecter sur les nouveaux projets stratégiques. - La solution des centres de services applicatifs permet d obtenir un engagement de disponibilité de ressources, de maintien des compétences, de réactivité et de qualité, en échange d un engagement de volume 14. Risques Les risques de perte de compétence sur les applications et de la difficulté du prestataire de services à comprendre les métiers et leurs besoins sont bien réels. Le premier risque présente deux aspects : - Si une application est spécifique à un métier, critique et correspondant au cœur de métier de l entreprise, alors il vaut peut-être mieux ne pas en externaliser le développement. Une TRA et une TMA seront sans doute bénéfiques sans remettre en cause la compétence interne. - Pour des applications moins critiques, le vrai métier de la DSI est de maitriser les besoins métiers, de savoir les spécifier, et de rester capable de valider le choix d une solution. Programmation, tests, intégration et maintenance ne sont plus vitaux. Tendances L externalisation applicative ainsi structurée est encore émergente en France. Les grandes SSII ont commencé à se développer sur ce marché en créant des centres d application management et des centres de services basés sur l expertise et l industrialisation 15. Les DSI sont séduites par ces centres pour des parcs applicatifs de type ERP, applications de gestion, ou supply chain management (SCM). Le principal avantage est de pouvoir grouper chez un même prestataire de services l ensemble du cycle de vie des applications (développement, intégration, test, maintenance) et les activités de support (opérations, support utilisateur). Par ailleurs, les DSI les plus matures et les plus avancées veulent mettre de l ordre dans leur domaine applicatif. Elles veulent mettre fin à la dispersion des personnels extérieurs en régie, et veulent clairement séparer les domaines applicatifs «externalisables» de ceux qui 14 L engagement de volume d affaires de la part du client serait légitime, mais certains clients arrivent à négocier des contrats sans garantie de volume, ou avec un niveau minimum très bas. 15 En France nous pouvons citer, entre autres, les centres de services de Capgemini, Atos, IBM Global Services, Steria, GFI, Logica et Bull, dont la taille est significative. D autres centres d application management sont amenés à se développer. JEMM Vision 2012 19
ne le sont pas. Ainsi l externalisation applicative est souvent une externalisation par lots ou par domaines. Dans les grandes tendances qui prennent de l ampleur, et rapidement, il faut citer l importance grandissante du mode SaaS 16 qui constitue une complète alternative à la fois au développement, la maintenance et l exploitation des applications. Dans quel cas recommander ce modèle Les entreprises recourent à ce modèle dans les cas suivants : - Elles manquent de ressources et/ou de compétences, mais ne veulent pas recourir à l AT, dont les coûts sont difficiles à maitriser et pour laquelle il n y a pas d engagement de résultat. - Elles veulent structurer des lots applicatifs sur lesquels elles demandent un engagement du fournisseur en termes de délai, qualité, expertise. - La DSI considère que le développement d application et le paramétrage de progiciels n est plus sa mission. Elle se concentre sur les architectures et les choix de solutions mais confie la totalité de ses développements à des prestataires. 16 SaaS : Software as a Service. JEMM Vision 2012 20
L externalisation verticale : BFO et BPO L expression «externalisation verticale» nous vient du fait qu il s agit en quelque sorte d isoler une «tranche verticale» du système d information, comprenant, pour un domaine, tous les systèmes et applications nécessaires à son fonctionnement. On parle de «business function outsourcing» (BFO) lorsque l on n externalise que le système d information d une fonction, et de «business process outsourcing» (BPO) lorsque l on externalise en plus le processus lui-même (figure 6). Une solution SaaS de CRM est un exemple de BFO : par exemple en recourant à la solution CRM salesforce.com, une entreprise conserve son processus CRM mais sa solution informatique est totalement externalisée. Comme exemples de BPO fréquents on peut citer la paie, la logistique, le commerce électronique, le SAV, les achats, les campagnes marketing, (emailing, postage, etc), télémarketing : autant d acticités supportées par des applications informatiques. Externalisation des systèmes supportant une fonction Processus et systèmes associés complètement externalisés Applications Serveurs Réseau Figure 6 : externalisation verticale de processus Vécu et exemples Les raisons pour décider d une telle externalisation sont multiples : - Manque des compétences nécessaires et coûts internes élevés pour continuer de supporter certaines fonctions : c est un argument classique pour externaliser la paie, la comptabilité, la gestion des notes de frais, les centres d appels clients. JEMM Vision 2012 21
- Stratégie d entreprise pour optimiser des processus tels que la logistique, la gestion des approvisionnements et la gestion des achats. Il existe des spécialistes de ces métiers qui proposent des performances et des coûts attractifs, difficilement égalables en interne. - Manque de compétences technologiques et domaines risqués : historiquement la plupart des sites de e-commerce ont été externalisés 17. Les entreprises n avaient pas les compétences pour réaliser et maintenir ces nouveaux systèmes complexes, et voulaient se réserver la possibilité d arrêter l activité en cas d échec. - La mise en œuvre d une stratégie de centre de services partagés pour supporter les besoins des différentes entités dans les pays d implantation. Avantages Cette approche permet tout simplement de se libérer de fonctions qui ne sont pas cœur de métier, qui ont peu ou pas de valeur ajoutée, et qui mobilisent des ressources internes qui seraient plus utiles sur d autres activités. De plus les spécialistes ont développé des processus et systèmes d information extrêmement performants qui rendent un service d une qualité difficilement égalable en interne. Risques Le risque le plus évident est la perte totale de compétence sur le domaine. Cela ne pose pas de problème lorsqu il s agit de la paie, de la comptabilité, du traitement des commandes et factures, par exemple. Mais il ne faut raisonnablement pas externaliser de cette façon un «cœur de métier». Tendances Les études montrent que le BPO est bien plus développé au Royaume-Uni, en Scandinavie et au Pays-Pays qu en France et en Allemagne 18. Le BPO croit encore lentement en France mais devrait accélérer dans les dix prochaines années. Les entreprises qui se «recentrent sur leur cœur de métier» externaliseront une grande partie, voire l ensemble des processus en dehors du métier. Ces processus peuvent être stratégiques. Par exemple la logistique d approvisionnement et de distribution est stratégique pour l industrie manufacturière : raison de plus pour les confier à des spécialistes performants. Dans quel cas recommander ce modèle - La volonté de sortir complètement un métier ou une activité pour le confier à un spécialiste. - Il est parfois plus facile de totalement externaliser localement l informatique d une filiale d un pays lointain ou aux règlementations trop différentes. 17 Certains ont été réinternalisés depuis. 18 Les raisons sont principalement culturelles. Les entreprises françaises et allemandes restent encore méfiantes à l exception des industries automobile et aéronautique qui sont allées très loin dans cette approche. JEMM Vision 2012 22
Le multi-sourcing sélectif Le terme multi-sourcing, comme cela arrive souvent avec les néologismes, a plusieurs interprétations. Partageons ici pour multi-sourcing le concept de découpage du système d information en plusieurs domaines, dont une partie distribuée sur plusieurs prestataires 19 nous pourrions dire «multi-outsourcing». Nous ajoutons ici l adjectif «sélectif» pour introduire l idée d expertise ou spécialisation pour l affectation des domaines. Différentes variantes existent, selon que l ensemble des applications ou seulement une partie est externalisé, selon que les opérations sont confiées à un seul prestataire ou plusieurs. Voici quelques exemples de configuration dans les figures ci-après (figures 7 et 8). Applications Applications Serveurs Réseau Serveurs Réseau Applications Serveurs Réseau Figure 7 : multi-sourcing sélectif (1/2) Les découpages peuvent porter sur des domaines restreints, conduisant à de l ordre d une dizaine de prestataires (figure 7). Certaines entreprises préfèrent des lots beaucoup plus importants et un nombre très limité de prestataires (figure 8). 19 Cette définition est d ailleurs conforme au référentiel escm (esourcing Capability Model). JEMM Vision 2012 23
Figure 8 : multi-sourcing sélectif (2/2) Vécu et exemples Certaines entreprises sont tout simplement effrayées par les gros contrats monolithiques de type outsourcing global ou outsourcing de l infrastructure : ce n est pas dans leur culture d entreprise. Elles préfèrent rechercher des partenaires spécialisés par domaines. Meilleur savoir-faire et coûts inférieurs sont les moteurs des décisions d externalisation de ce type d entreprise. Elles auront ainsi tendance à découper les activités de gestion de l infrastructure en périmètres techniques : Unix/Linux, AS400, mainframes, postes de travail. Le domaine applicatif pourra être découpé selon les technologies et/ou les domaines fonctionnels. C est le modèle le plus répandu. Mais on constate quelques écueils : - Des excès dans le nombre de prestataires. - Une gouvernance de l ensemble des contrats encore souvent trop faible, en compétences et en effectifs. Un grand manufacturier français, l un des leaders mondiaux sur son marché, a opté pour le modèle de la figure 8, avec unprestataire principal (IBM) pour la gestion de son infrastructure, et un groupe réduit de prestataires majeurs sur ses parcs applicatifs. Un exemple correspondant à la figure 8, bien connu en France, est Renault qui a confié la gestion de l infrastructure hors postes de travail à CSC, la gestion des postes de travail à HP, la gestion du parc applicatif à Atos et Capgemini 20. Avantages Ce modèle correspond à la structuration en domaines fonctionnels et techniques. Les sociétés de services sont engagées sur des lots de façon exclusives et sont ainsi responsabilisées et mesurées. 20 Atos était titulaire de l ensemble du périmètre applicatif dans le contrat initial de 2005, mais une partie en a été confiée à Capgemini fin 2009. JEMM Vision 2012 24
Risques Bien des entreprises sont tombées dans le piège de vouloir les meilleurs spécialistes partout et ainsi avoir trop de prestataires : - Il y a trop de contrats à gérer et cela mobilise trop de ressources aux achats et à la DSI. - Les échanges entre prestataires sont complexes sur le plan contractuel et souvent conflictuels : les SSII responsables d applications différentes s entendent en général mal sur la gestion des interfaces entre les dites applications. Pour le pilotage du système d information, séparer les différents niveaux de services entre prestataires est encore pire 21. - Les engagements de niveaux de services attendus («service level agreement», ou SLA) sont incohérents d un contrat à l autre. - La multiplication des SSII présentes dans la DSI a parfois conduit à une fourmilière sans vision stratégique. Tendances En France, en dehors des entreprises qui se limitent à l externalisation de l infrastructure, la tendance au multi-sourcing sélectif est très forte. Malheureusement, encore trop nombreuses sont celles qui n ont pas une vision stratégique et cohérente de ce type de découpage et se retrouvent avec les risques et inconvénients cités plus haut. Le multi-sourcing réussi repose sur quelques principes : le nombre de domaines est limité (10 à 12 maximum pour les domaines applicatifs, trois ou quatre pour l infrastructure), les domaines externalisés et ceux qui restent internalisés sont clairement définis et séparés, les prestataires stratégiques pour les domaines fonctionnels sont sélectionnés selon leurs compétences métiers. Nous consacrons une section aux bonnes pratiques du multi-sourcing et comment le concilier avec la tendance des achats à réduire le nombre de fournisseurs de services. Dans quel cas recommander ce modèle Un tel modèle convient aux grandes DSI au parc technique et applicatif complexe et diversifié. Avoir les meilleurs spécialistes pour chaque domaine est évidemment tentant. A condition de bien définir et délimiter ces domaines, bien sélectionner les fournisseurs de services, et bien les mesurer. 21 Les directions des opérations ont l habitude de considérer trois niveaux de support pour assurer le maintien des systèmes en conditions opérationnelles : service desk (traitement des appels et enregistrements des demandes et incidents, qualification des incidents) et premier niveau d assistance, (niveau 1), support applicatif ou technique dit de niveau 2 pour les problèmes et défaillance nécessitant l intervention rapide des équipes de maintenance applicative ou de pilotage de l infrastructure, et support applicatif ou technique dit de niveau 3 lorsque la gravité ou la complexité des défaillances nécessite l implication des fournisseurs de logiciels ou de matériels. JEMM Vision 2012 25
Ces modèles de base ne s excluent pas Nous n avons pas la prétention à vouloir réduire simplement et strictement l outsourcing à ces cinq modèles de base. Nous les estimons utiles pour aider les dirigeants et les managers opérationnels, dans ou en dehors de la DSI, à s y retrouver et à adopter la direction qui conviendra le mieux à leur situation. Comme nous l avons déjà indiqué chaque modèle de base accepte quelques variantes. La figure ci-après résume nos cinq modèles (figure 9). Global outsourcing Infrastructure management Application management BFO - BPO Multi-sourcing! et leurs variantes Figure 9 : résumé des principaux modèles de sourcing Certains modèles peuvent être pratiqués en combinaison avec les autres. Par exemple le modèle d outsourcing vertical coexiste facilement avec les quatre autres modèles, comme on le montre sur l exemple de la figure ci-dessous. On rencontre aussi couramment du multisourcing pour la partie applicative uniquement, ce qui constitue une adaptation des modèles «Application management» et «multisourcing» (figure 10). JEMM Vision 2012 26
Applications Serveurs Réseau Figure 10 : combinaison de modèles BFO-BPO et multi-sourcing sélectif JEMM Vision 2012 27
Comment choisir le bon modèle? Les DSI peuvent être dans deux situations. Ou bien le recours à l externalisation est courant et ancien, avec un résultat assez désordonné ou déficient, et dans ce cas la DSI ressent le besoin de restructurer sa cartographie d externalisation. Ou bien elle n a pas encore externalisé et elle y songe sérieusement, même si c est pour quelques domaines limités dans un premier temps. Dans ces deux cas, les DSI ont besoin de repères : des modèles d externalisation et des bonnes pratiques dans leur mise en œuvre. Choisir un modèle pour démarrer son externalisation ou pour la réorganiser conduit à considérer un nombre considérable de paramètres. Nous croyons essentiel d avoir une démarche structurée, progressive, pour appréhender le nombre et la combinatoire de ces éléments. Les paramètres à prendre en compte sont les suivants : - Le modèle d organisation de la DSI (centralisée, décentralisée, fédérée) ; - La typologie de la DSI (centre de support, fournisseur de technologie, fournisseur de services pour les métiers, partenaire stratégique, cœur de métier) ; - La culture d entreprise (a déjà externalisé ou pas) ; - La maturité de la DSI et sa capacité à piloter une ou plusieurs infogérances ; - L impact sur les compétences ; - L impact sur les personnels ; - Le coût et la valeur ajoutée d une ou plusieurs opérations d outsourcing ; - Les risques. La stratégie consiste à les évaluer et les prioriser pour définir quelques scenarii. JEMM Vision 2012 28
Le multi-sourcing maîtrisé La période 2004 à 2006 a vu le début des actions draconiennes, parfois brutales, de réduction du nombre de prestataires de services, là où ils étaient manifestement en nombre exagéré. Depuis 2006/2007 on assiste à une tendance forte au «multi-sourcing» pour corriger les difficultés apportées par le global sourcing ou les trop gros contrats monolithiques. D aucuns verraient là deux tendances contradictoires. En réalité nous croyons à une orientation vers un multi-sourcing maîtrisé, basé sur l externalisation de certains domaines bien définis, pouvant être vastes, chaque domaine étant confié à un prestataire unique, pour l occasion qualifié de «stratégique». Trop de prestataires de services informatiques est coûteux L inflation du nombre de prestataires de services informatique n a pas cessé entre les années 80 et le début des années 2000. L urgence et le retard des projets, s ajoutant au manque de compétences internes, ont conduit les entreprises à faire appel massivement aux sociétés de services. Mais trop souvent l ont-elles fait au cas par cas, projet par projet. Les prestataires présents chez un client se sont ainsi multipliés. Nous connaissons des directions informatiques qui ont fait appel à plus de 100 ou 200 sociétés de services, et des grands groupes qui ont largement dépassé les 1000 SSII référencées et actives. Ces situations qui résultent d un manque de vision et de coordination révèlent aujourd hui de multiples problèmes : - On voit des plateaux projets embarquant des prestataires originaires de plusieurs SSII concurrentes. Il s ensuit de graves atteintes à la confidentialité 22 ou parfois de la méfiance ou des rivalités. - La gestion des relations et interfaces entre SSII titulaires de lots dans un même domaine ou un même projet est très consommatrice de ressources. En effet les relations entre ces sociétés ne sont pas contractuelles et sont de la responsabilité du client. La plupart des entreprises sous-estiment cette charge et se retrouvent en déficit d effectifs sur ces postes. - La simple gestion des contrats est très coûteuse : le contrôle et les paiements, la gestion des avenants et changements, les renouvellements et remises en concurrence 23. Des opérations de rationalisation drastiques ont parfois été trop loin De nombreuses grandes entreprises ont lancé des opérations de réduction du nombre de prestataires de services. Ce fut même une tendance forte en 2003-2004-2005. Ces campagnes ont parfois été brutales : des grands groupes qui avaient atteint, il faut bien le dire, des niveaux déraisonnables, ont divisé par 10, 50, voire 100 leur nombre de soustraitants. Ils ne conservent qu un groupe restreint de fournisseurs, généralement des leaders 22 Nous avons connu une situation chez un client, où des informaticiens d une dizaine de sociétés de services différentes, travaillant ensemble sur un même plateau depuis des mois, partageaient inprudememnt les informations sur les stratégies commerciales et la politique tarifaire de leurs employeurs respectifs pour ce même client. 23 On a même vu des cas de contrats mal suivis et pour lesquels les dates de renouvellement ont été oubliées et donc les SSII ont fait jouer les clauses de reconduction tacite. JEMM Vision 2012 29
du marché. Et cela sous des délais très courts, et en l accompagnant de pressions très fortes sur les prix. Ces opérations ne sont pas sans créer de nouvelles difficultés : - Les heureux titulaires de marchés importants ou de contrats cadres, n ayant pas les effectifs ni les compétences requises sous des délais aussi courts, doivent tout simplement «re-sous-traiter» aux plus petits acteurs qui ont été écartés. Il s ensuit des cascades de sous-traitance décevantes pour les acteurs de rang deux et plus, et se situant probablement à la limite ou en dehors de la légalité 24. - Les plus petits acteurs qui deviennent sous-traitants des titulaires de contrats voient une trop grande érosion de leurs marges et préfèrent se tourner vers d autres clients 25. - Il existe des cas de disparition de compétences : certains informaticiens très spécialisés, sur une technologie ou sur un métier du client, se voient affectés, ou choisissent d être affectés, à d autres projets chez d autres clients. Pour résoudre ces problèmes inattendus, de nombreux groupes ont dû rappeler d anciens sous-traitants écartés pour les référencer à nouveau et leur confier des lots particuliers. Malgré tout, la tendance à la réduction du parc de sociétés de services référencées continue fortement, plus prudemment, et selon des processus de négociation un peu mieux établis. La rationalisation était nécessaire pour optimiser les coûts de gestion de la sous-traitance, mieux négocier sur de plus gros volumes, mais aussi pour engager les SSII sur un rôle de partenaire stratégique. Rationaliser et optimiser le multi-sourcing Dans le même temps on assiste, sur le marché de l externalisation, à une nouvelle et forte tendance au multi-sourcing, à savoir la constitution un pool de partenaires fournisseurs de services, chaque partenaire étant complètement titulaire d un domaine particulier. Cette tendance a lieu au détriment des gros contrats : «global outsourcing» (l externalisation complète de l informatique), l externalisation de toute l infrastructure, ou encore l externalisation de tout le parc applicatif (développement et maintenance). La signature de ces gros contrats groupes est en nette diminution depuis 2005. On voit même des entreprises qui veulent, à l occasion d une date de renouvellement, découper de gros contrats en plusieurs lots confiés à des prestataires différents. 24 Il est fréquent que les sous-traitances à plusieurs sous-niveaux se traduisent par de la location pure et simple de personnel, sans encadrement ni suivi de l employeur, ce qui risque de mettre à la fois le client et l employeur en situation de délit de marchandage. Le client final ne peut désengager totalement sa responsabilité. 25 Nous connaissons le cas d une petite entreprise de quinze personnes, autrefois bien implantée auprès de quelques banques pour des solutions pointues de simulation financière, et qui a été déréférencée lors d une de ces très dures opérations de réduction du nombre de SSII. Elle a préféré dissoudre son activité plutôt que travailler à marge nulle pour de grosses SSII. Ce n est pas un cas isolé. JEMM Vision 2012 30
Le multi-sourcing offre d évidents avantages - Il permet de créer une émulation entre les prestataires titulaires de lots, constamment mesurés et comparés. - Il sélectionne les meilleures compétences par domaine (compétences sur des technologies et des produits, compétences sur un métier vertical, compétence dite de «couverture géographique»). - Il permet une séparation claire entre domaines restant internes et ceux qui sont externalisés. Il comprend aussi quelques risques A trop vouloir les meilleurs experts, certaines DSI retombent dans la multiplication des périmètres trop restreints et confiés à des prestataires différents, qui redeviennent trop nombreux avec le temps. Encore une fois, le manque de stratégie et de coordination globale peut conduire à connaitre ou retrouver cette situation. Quelques recommandations pour réussir son multi-sourcing Tout le problème est bien le dosage du nombre de domaines identifiés. Pour les grands groupes aux multiples implantations régionales et internationales, aux diversités parfois héritées de fusions et acquisitions, et au passé de prolifération de sous-traitants, la problématique reste complexe. Ils semblent se fixer une cible d une dizaine d acteurs majeurs 26. Vouloir ne retenir que deux ou trois partenaires pour de vastes domaines qui seraient par exemple l ensemble de l infrastructure, l ensemble des applications, et le parc de postes de travail est plus rarement réalisable : en effet trop peu de sociétés de services sont capables de bien couvrir l ensemble du spectre applicatif d une grande entreprise sous les angles métiers et techniques 27. L appréciation du nombre de partenaires, qui du coup deviennent stratégiques, reste un exercice délicat qui devrait résulter d une vraie analyse, partagée au moins par la direction informatique et la direction des achats. Voici quelques règles essentielles : 1. Il faut avoir une vraie correspondance «bijective» entre domaines et prestataires de services. Le «mélange» de prestataires sur un même lot est source de difficultés d ordre contractuel et de dilution des responsabilités. 2. Le cloisonnement entre prestataires doit être rigoureux. La gestion des échanges entre domaines, donc entre prestataires, est de la responsabilité du client. 3. Chaque partenaire est titulaire d un ou plusieurs lots. Rien n interdit d externaliser deux ou trois domaines vers une même société de service. Dans ce cas nous déconseillons la tentation de regrouper les domaines sous un même lot : les clients 26 Un très gros industriel du centre de la France est dans cette logique pour le découpage de son patrimoine applicatif. Cinq ou six acteurs majeurs ont été retenus. 27 Renault a réussi à se limiter à deux acteurs principaux pour l infrastructure (CSC et HP) et deux principaux pour le patrimoine applicatif (Atos et Capgemini). JEMM Vision 2012 31
peuvent garder la souplesse par domaine, pour pouvoir de changer de partenaire un jour, si le besoin s en fait sentir, sur un domaine. 4. Pour chaque domaine, les prestataires envisagés doivent être présélectionnés sur leurs compétences métiers et techniques. Pour les domaines fonctionnels et applicatifs, la vraie connaissance des métiers du client devrait être le critère le plus important. Vient ensuite la maîtrise des technologies et des progiciels utilisés. Pour la gestion des infrastructures et des middleware associés, c est la compétence technologique et la fourniture d outils de pilotage qui primeront. 5. Des profils spécialisés, expérimentés et surtout suffisamment nombreux, doivent être responsables de la gestion des interfaces et relations entre prestataires titulaires de domaines lorsque cela est nécessaire. C est l enjeu de la gouvernance de l outsourcing sur lequel nous reviendrons. La figure 11 donne un exemple de découpage du système d information en grands domaines en l occurrence c est un découpage d architecture, mais c est un guide utilisé pour analyser le sourcing. Pour chaque domaine, l entreprise peut décider de le confier à un prestataire de services unique. L importance du domaine fait du prestataire un partenaire stratégique. Applications R&D Design CAO PLM Applications industrielles Automatisation Supervision ERP - GPAO SCM - Logistique Finance Comptabilité RH Ventes ecommerce CRM Marketing BI Infrastructure Mainframes Mainframes Unix Serveurs Unix Windows Serveurs Windows Communs (annuaires, sécurité) Postes de travail Postes de travail Figure 11 : exemple d un découpage en grands domaines JEMM Vision 2012 32
Les domaines externalisés peuvent être groupés par similarité de technologies et/ou de fonctionnalités, comme le montre l exemple de la figure 12 (un groupe «application R&D et industrielles», un groupe «gestion-erp» et un groupe «commercial-ventes»): R&D Design Applications Applications industrielles Automatisation Supervision CAO PLM ERP - GPAO SCM - Logistique Finance Comptabilité RH Ventes ecommerce CRM Marketing BI Infrastructure Mainframes Mainframes Unix Serveurs Unix Windows Serveurs Windows Communs (annuaires, sécurité) Postes de travail Postes de travail Figure 12 : autre exemple d un découpage en grands domaines Conclusion : rationalisation et multisourcing convergent Mais alors pourrait-on dire, n y a-t il pas contradiction entre une tendance à vouloir réduire le nombre de prestataires de services informatiques, et une autre tendance à vouloir découper l informatique en domaines distribués sur plusieurs prestataires? Ces deux tendances coexistent-elles? L une doit-elle l emporter sur l autre? En réalité nous croyons ces deux mouvements convergents. L écosystème est en train de se stabiliser vers un multisourcing stratégique et maîtrisé. Il y a à cette perspective quelques conditions pour que l externalisation soit gérée de façon optimale et ne redevienne pas un foyer de difficultés et de coûts : 1. Les entreprises ne devraient pas revenir au foisonnement désordonné de prestataires de services informatiques. 2. La sélection d un pool de principaux partenaires est indispensable, selon des critères de compétences métiers et techniques. JEMM Vision 2012 33
3. Cela n exclut pas la sélection de prestataires plus petits et spécialisés pour des besoins pointus. Les directions des achats ne doivent pas être dogmatiques ni rigides à ce sujet. On peut imaginer un second pool de fournisseurs spécialisés (une expression qui nous parait préférable à celle, malheureuse, de «fournisseurs de second rang»). 4. La DSI se donne les moyens de gérer les lots externalisés et les interfaces entre sociétés de services. JEMM Vision 2012 34
Ne pas confondre modèles de sourcing et «business models» Il est important de ne pas confondre les modèles de sourcing, ou modèles d outsourcing, tels que nous venons de les présenter, et les moyens de les mettre en œuvre sous forme de sociétés communes, GIE, etc. Il y a là un amalgame dangereux que l on rencontre pourtant parfois dans les réflexions des entreprises. Nous avons présenté dans les pages précédentes cinq modèles de base, qui sont essentiellement un support, un guide à la réflexion d une stratégie de sourcing qui cherche à identifier les domaines éligibles à l externalisation et pour lesquels l opération présente une valeur ajoutée pour l entreprise. C est seulement lorsqu on a identifié les périmètres, découpé en quelque sorte son système d information en domaines internalisés et domaines externalisés, et pas avant, qu on peut regarder quelles solutions, quels montages, sont envisageables pour réaliser l opération. Effectivement le marché offre différentes approches pour mettre en œuvre l externalisation : - Contracter avec un ou plusieurs prestataires de services, avec diverses variantes : systèmes hébergés chez le client, chez un tiers hébergeur, ou chez le prestataire, système opérés par les ressources du prestataire depuis les locaux du client ou depuis les centres d opérations des prestataires. On note que le prestataire peut être «local» (basé en France), «offshore» ou «nearshore 28» (principalement des sociétés indiennes, marocaines, roumaines), ou encore local mais confiant tout ou partie des services à une filiale offshore. - Certains penchent pour une société commune, «co-entreprise», avec un prestataire. Cette solution est préférée pour faciliter le transfert de personnels 29. - On peut aussi loger certaines activités informatiques dans un GIE, éventuellement en se groupant avec d autres entreprises. - Et enfin on ne peut oublier les filiales nearshore ou offshore dites «captives». Il s agit d un établissement que le client installe à l étranger pour réaliser une partie de ses activités informatiques. Il existe principalement trois variantes : la «captive privée» (exemples : les captives de BNP-Paribas et Société Générale en Inde et au Maroc), la captive virtuelle ou la captive build-operate-transfer (BOT) 30. Il s agit de montages pour limiter les risques, obtenir de meilleurs prix, limiter l impact de transferts de personnels mais sans remettre en cause le choix de sourcing en termes de périmètre. Le cadre escm 31 parle de «types de relation de sourcing 32». 28 Le marché reconnaît la typologie suivante : les sociétés de services nearshore sont à deux ou trois heures d avion de France (Pays du Maghreb et d Europe centrale), au-delà elles sont dites offshore (Europe de l Est, Asie, Amérique du sud, Afrique centrale et du sud). 29 Le personnel transféré dans une co-entreprise conserve son statut et son appartenance d origine. 30 Captives virtuelles et captives BOT sont un phénomène principalement indien. Captive virtuelle : plutôt que de créer une filiale en Inde, on demande à une SSII de bâtir une entité dédiée au client. Il s agit de bâtiments ou d étages et d effectifs exclusivement réservés pour la réalisation de projets d un client. Infosys par exemple réalise de tels montages. Client et SSII peuvent s entendre pour que la captive virtuelle soit intégralement transférée au client au bout d une période de trois ou cinq ans, pour qu elle devienne sa vraie captive on est alors dans le BOT. 31 escm : esoucing Capability Model. Voir www.itsqc.org et www.ae-scm.fr. JEMM Vision 2012 35
Le risque de confusion Ce petit chapitre a son importance car quelques documents malheureux, pourtant issus de cabinets reconnus, circulent sur le Net, et entretiennent voire créent la confusion. Et c est ainsi que lors de mission de conseil on entend des clients vous parler de JV ou d offshore avant même d avoir clarifié leurs objectifs et évalué quelques scenarios sur des périmètres techniques et une liste de services. En ce sens nous trouvons regrettable que Gartner Group ait publié dans son document Toolkit: How to Choose the Right Sourcing Models, Options and Locations, Rev. 1 Gartner, Dec 2007 un amalgame de modèles de sourcing et de relations de sourcing. Nous reproduisons ci-dessous la figure centrale du document créant la confusion. Figure 13 : le mélange de modèles de sourcing et de montage dans la mise en œuvre Dans ce schéma nous pensons que «selective outsoutsing», «full outsourcing», «internal service» et «shared services» sont des modèles de sourcing. JV, best-of-breed consortium, BOT sont des modèles business ou relations de sourcing. Par exemple le Selective outsourcing peut être mis en œuvre aussi bien avec un consortium ou un groupement de spécialistes best-of-breed, avec des centres de services partagés, et/ou avec des partenaires offshore montant des BOT; Le full outsourcing peut être mis en œuvre avec un prestataire prime contractor.. Une JV n est pas un modèle de sourcing, c est un montage financier. On peut y loger les développements, l infrastructure, les postes de travail, la TMA ou tout à la fois. Voilà comment nous dissocions les deux concepts (figures 14 et 15) : 32 Il suffit de se reporter au guide «escm-cl le modèle d aptitude à l esourcing pour les clients», édité en français par l Ae-SCM. JEMM Vision 2012 36
Figure 14 : Modèles de sourcing (rappel) Figure 15 : Différentes relations de sourcing 33 Notons que cette classification ne sert qu à «montrer où se trouvent les services» et qu à la fin du compte il y a toujours une relation contractuelle, un contrat de services, entre le client et le fournisseur, même si celui-ci est un GIE filiale de la maison mère ou une captive privée. 33 SaaS : Software as a service ; IaaS : Infrastructure as a service ; PaaS : Platform as a service. JEMM Vision 2012 37
Quel est l impact du cloud computing dans ces approches? Le Cloud computing n est pas non plus à proprement parler un modèle de sourcing. Le cloud computing est sous-tendu principalement par les technologies de virtualisation et les techniques d automatisation poussée de la production informatique. De plus les concepts de cloud privé, mixte, public se réfèrent respectivement à des situations internes, «mixtes», externes. Et ce sont les grands hébergeurs et infogérants qui maitrisent le mieux aujourd hui des data centers «cloudisés». La réflexion est incontournable parce que c est une façon d aller encore plus loin dans la mise en œuvre d une politique d outsourcing. Mais il faut d abord déterminer sa stratégie de sourcing avant d élaborer une stratégie Cloud. Nous pensons que le concept de cloud computing et la multitude d offres qui voient le jour chez les grands acteurs vont complètement bouleverser le marché de l externalisation : - Les offres SaaS remplaceront les services d application management pour des applications nécessitant peu ou pas d adaptation ou de transformation du progiciel, et peu intégrées à d autres applications (en d autres termes aux interfaces limitées) ; - Les offres d IaaS et de PaaS tentent de plus en plus de clients qui peinent à gérer leurs data centers. JEMM Vision 2012 38
Nos recommandations Nous avons présenté ici les modèles de base, autour desquels chacun peut réfléchir à celui qui convient le mieux à son entreprise. Il aboutira souvent à une combinaison ou une variante de ces modèles. Son élaboration doit être menée, non pas à l emporte-pièce ou sous la pression de sociétés de services, comme cela a pu arriver par le passé, mais de façon réfléchie et méthodique, en appréciant l ensemble des paramètres de l entreprise et de la DSI : - Le modèle d organisation de la DSI (centralisée, décentralisée, fédérée) ; - La typologie de la DSI (centre de support, fournisseur de technologie, fournisseur de services pour les métiers, partenaire stratégique, cœur de métier) ; - La culture d entreprise (a déjà externalisé ou pas) ; - La maturité de la DSI et sa capacité à piloter une ou plusieurs infogérances ; - L impact sur les compétences ; - L impact sur les personnels ; - Le coût et la valeur ajoutée d une ou plusieurs opérations d outsourcing ; - Les risques. Il est important de finaliser sa stratégie de sourcing proprement dite avant de porter la réflexion, qui vient dans un second temps, sur le choix de prestataire(s) et sur les montages possibles. JEMM Vision 2012 39
A propos de JEMM Vision et de l auteur : JEMM Vision est un réseau d analystes indépendants de recherches stratégiques et d analyses opérationnelles dans les technologies de l information. JEMM Vision accompagne les Directeurs des Systèmes d Information des entreprises et des collectivités dans l'optimisation économique, écologique et organisationnelle de leur système d'information. JEMM Vision aide également les fournisseurs informatiques à comprendre et analyser leurs marchés cibles afin de promouvoir leurs offres en maximisant leurs chances de succès. JEMM Vision se distingue par l expertise et la complémentarité de ses membres, l indépendance de ses analyses et de ses conseils. Richard PEYNOT cumule treize années en développement et management de projets informatiques en sociétés de services, et près de six années comme chef de service nouvelles technologies et orientations techniques à la direction des systèmes d information de PSA Peugeot Citroën. Il a ensuite été analyste chez Forrester Research de 2001 à 2007. Il crée son propre cabinet Acseitis en 2008. Il conseille les entreprises sur des problématiques de sourcing informatique, restructuration des DSI, et gestion des compétences informatiques. Il est certifié escm. Il est membre du réseau d analystes Jemm Vision depuis 2011. Richard Peynot est diplômé en Marketing et en Management Général International de l ESSEC, après une formation initiale en Informatique à l Université de Grenoble. Pour en savoir plus, obtenir plus d informations sur le contenu de cette étude et discuter dans le contexte de votre organisation, vous pouvez planifier une session avec nos experts en envoyant un courriel à contact@jemmresearch.com ou en appelant le +33 1 39 16 48 81 ou le +33 6 84 48 74 13. JEMM Vision 2012 40