L'organisme international de normalisation ISO, après avoir travaillé le texte d'une proposition de norme pour la Continuité d'activité, vient de le soumettre au vote de ses membres.

Une nouvelle norme va donc normalement voir le jour au printemps 2012, date du dépouillement. Son titre : "Sécurité sociétale — Systèmes de management de la continuité — Exigences".

Ce genre de norme est important pour au moins deux raisons :

• son adoption par l'entreprise indique clairement une intention d'amélioration inscrite dans la durée en matière de continuité

• les partenaires de l'entreprise -client ou fournisseurs- savent que des mesures sont en place et que l'entreprise présente un niveau de risque et un degré de préparation face au sinistre meilleurs que d'autres.

Voici nos premières remarques.

Cette norme appartient à une catégorie bien particulière : les "management systems" ou "systèmes de management". Cela signifie qu'elle se concentre sur la manière de se rapprocher d'un état cible.

Autrement dit, elle présente des dispositifs à mettre en place pour permettre d'améliorer la situation en matière de continuité d'activité. Ce type de norme s'appesantit beaucoup plus sur le fait de se rapprocher d'une cible de bonnes pratiques que sur les bonnes pratiques elles-même. Ceux qui y recherchent des "recettes" en seront pour leurs frais.

En ce qui concerne les bonnes pratiques (à chercher à atteindre) il faut se référer à un autre corpus, normé ou pas d'ailleurs.

On peut très bien faire l'analogie avec les normes de sécurité de la famille ISO 27000 ou de qualité ISO 9000 qui possèdent en leur sein une norme "système de management". Ces normes "de management" présentent toutes une même caractéristique : l'engagement nécessaire de la Direction générale.

Elles responsabilisent la Direction générale (DG) : elles ne disent pas "voilà ce qu'il faut faire en matière de continuité" mais "la DG doit choisir ce qu'elle veut en matière de continuité". C'est ce que ces normes appellent le "leadership" du management qui passe par la rédaction et diffusion d'une note de politique de continuité. (On peut remplacer dans ce qui précède 'continuité' par 'sécurité' ou 'qualité', selon la norme.)

Pour réaliser ces choix de niveau stratégique, des recommandations sont faites dans la norme, qui énonce quelques critères. Il est clair cependant qu'un travail de préparation est à faire en amont, en général accompagné et suscité par un responsable (RPCA dans ce cas).

Nous voyons souvent dans nos missions de conseil ce document de politique rédigé quelques mois après la nomination du RPCA et sous l'impulsion de ce dernier. L'analogie avec la qualité et la sécurité demeure.

Conséquence probable de ce qui précède et d'un réalisme tout anglo-saxon, ce type de norme envisage un progrès avec le temps.

Elles s'inscrivent en effet dans un cycle d'amélioration : réalistes, elles considèrent qu'il faut commencer en mettant la barre assez bas puis la monter progressivement. Dit autrement, elles ne sont pas binaires ('bien' / 'mal') mais beaucoup plus dosées ('moyen' / 'mieux l'année prochaine').

C'est le fameux PDCA (Plan Do Check Act):

• P : Plan ou prévoyez ce que vous voulez faire pour la période N°n

• D : Do ou faites-le, passez à l'acte : cela se traduit par des plans d'actions divers qui permettent d'améliorer la situation

• C : Check : faites des essais, des exercices, vérifiez ce qui marche ou pas.

• A : Pour ce qui ne marche pas, ré-agissez par des corrections

Enfin, recommencez en haut de la liste à la lettre P avec n+1.

Nous l'avons vu, il existe des normes de 'bonnes pratiques' et des normes 'système de management'.

Les normes de bonnes pratiques listent un certain nombre de recommandations intéressantes classées logiquement. Le verbe employé en anglais est "should", les quelques traductions en français spécifient "il convient". On peut donc en prendre et en laisser.

Les normes de système de management sont plus exigeantes, elles précisent 'you shall' ou 'il faut'. En particulier elles demandent que la DG choisisse ce qu'elle prend ou laisse dans le corpus de bonnes pratiques. Cela amène à des obligations qui peuvent faire sourire : "la politique est faite pour être appliquée" ou sembler évidentes.

La conséquence directe de cet état de fait est qu'il devient possible de savoir si la norme 'système de management' est suivie ou non. "Il faut faire ceci" stipule la norme : "est-ce fait ?" peut demander l'auditeur "oui" ou "non" sont des réponses possibles. Ce type de norme peut donc faire l'objet d'un certification. Des certifications ISO 22301 pourraient donc apparaître ultérieurement.

Une norme 'système de management' se prête, comme on le voit, à des mécanismes de certification alors qu'une norme 'bonnes pratiques' ne s'y prête pas. L'ISO 22301 mentionne d'ailleurs des possibilités d'auto-évaluation ou d'audit par des tiers intéressantes car ouvrant la porte à des certifications plus souples.

L'exigence première et fondatrice est que la Direction générale doit commencer par dire ce qu'elle veut faire en matière de continuité dans tel ou tel corpus de bonnes pratiques, attribuer des responsabilités dans son organisation et suivre ce qui est fait pour corriger. Elle doit aussi prévoir le nécessaire en matière de support, d'assistance compétente et de traitement des difficultés.

Un document de "politique de continuité" doit exister avant tout. Il doit être largement communiqué dans l'entreprise et auprès de ceux que cela concerne hors entreprise : c'est la première exigence de la norme.

En gros ce qui précède est valable pour toute norme 'système de management' ; qu'est-il donc exigé spécifiquement en matière de continuité d'activité dans cette future norme ISO 22301 ?

Les points détaillés se résument à ce qui suit :

• Il faut cadrer l'approche : définir le périmètre sur lequel le système de gestion va porter ; tout bon chef de projet sait qu'il faut commencer par là...

.

• Il faut mener une analyse de risque et un BIA (Business Impact Analysis) ; il est amusant de voir ces deux analyses rassemblées dans le même paragraphe quand on sait que l'approche britannique met le BIA en premier alors que l'approche US commence par l'analyse de risque. La norme -c'est normal pour un système de gestion- ne dit pas comment faire cela, mais se contente de préciser des points durs comme la nécessité d'avoir des critères d'évaluation et des méthodes pour les risques ou la détermination des activités critiques de l'entreprise ainsi que des délais d'interruption maximum admissibles.

• Il faut déterminer et choisir les options de continuité : les activités prioritaires et les ressources sous-jacentes (humaines, techniques, informatiques, locaux, bureaux, etc.) à prévoir ; quant aux risques, il faut prévoir d'en diminuer les effets et occurrences...

• Il faut mettre en place la réponse appropriée : les procédures et l'organisation qui permettent de redémarrer dans le contexte du sinistre au-delà d'un certain seuil de gravité ; il faut y inclure la communication vers les parties-prenantes. Les missions et responsabilités doivent être décrites.

• Il faut mettre en place des procédures de surveillance, d'alerte en cas de sinistre et de mise en place de la réponse.

• Il faut construire des "Business Continuity Plans" comprenant un certain nombre de points traditionnels de la discipline et penser aussi au retour à la normale quand tout est rentré dans l'ordre.

• Il faut faire des exercices et des tests pour s'assurer que les procédures conviennent et répondent aux objectifs de continuité.

• Il faut prévoir des audits et des revues régulières, la direction générale doit s'assurer de l'efficacité des procédures et plans en place.

• Enfin, PDCA oblige, il faut mettre en place et vérifier les actions correctives face aux anomalies constatées.

Chacun de ces points est traité sur une page ou deux tout au plus, ce qui porte à 15 le nombre de pages spécifiant les exigences propres à la continuité d'activité sur un document comptant 32 pages.

Il est possible de sentir des "redites" dans les phrases de la norme, indiquant des sources multiples (comme le BCI britannique et le DRII nord-américain, entre autres).

L'ensemble de ces exigences est évidemment structurant mais laisse de grands degrés de liberté dans la manière de faire.

L'implémentation concrète n'est pas précisée, ce qui est propre à toute norme 'système de management'.

On notera dans le contexte français -qui privilégie l'approche par les risques et les moyens- que le BIA (approche par les processus) est obligatoire. Il y aura en France du travail à faire !

Cette norme en devenir représente somme toute un compromis intelligent et pragmatique entre les directives vagues et les détails inapplicables. Mais, le rôle des RPCA, chefs de projets et consultants pour la mise en oeuvre sera très important.

La production de services IT d'une entreprise peut être qualifiée d’industrielle lorsqu’elle est mise sous contrôle et autant que possible automatisée.

Or, l’expérience du terrain montre que lorsqu’on se penche sur une production existante, son état est variable, mais il est rarement idéal.

A partir de notre expérience et de nos études, nous proposons ici une synthèse sous forme de sept « règles d'or » pour l'industrialisation de la production de services IT.

Nous distinguons ici deux catégories de règles : d'une part, les règles obligatoires permettant une mise sous contrôle de la production et, d'autre part, celles permettant éventuellement d’améliorer la production en termes de coût, de qualité et de fiabilité.

Dans cette catégorie, on trouve des règles fortes permettant de "reprendre la main". Sans elles, aucun contrôle de la production n'est possible aisément. Le respect de ces règles est obligatoire pour permettre au producteur d’assumer sa responsabilité et indispensable pour mettre en œuvre les règles qui suivent,

Ce périmètre est celui sur lequel le « producteur » exerce ses missions. Il peut varier en surface selon les clients, se limiter à des moyens techniques réduits ou englober un ensemble beaucoup plus large allant jusqu’à la délivrance d’un service complet à haut contenu fonctionnel.

Sur ce périmètre, l’ensemble des éléments qui concourent à la production sont identifiés. Il s’agit de divers matériels et logiciels (systèmes et sous-systèmes avec leurs niveaux de version/release/patch, code source, exécutables, script, outil, fichiers...) mais aussi - et c’est important - de consignes, de procédures sous forme papier ou électronique,...

Sur ce périmètre le « producteur » exerce sa mission de pilotage opérationnel du service. Par construction en effet, une seule entité assure le pilotage opérationnel du service industriel (« un seul pilote dans l’avion ! »).

Les éléments du périmètre doivent être cohérents et complets. Toute incohérence (ex:niveaux de release non conformes entre système et sous-systèmes) ou tout manque (ex:exécutable sans source, procédures inexistantes) doit être l’objet d’un constat et d’une correction autant que possible.

Les éléments du périmètre sont par définition stables entre deux changements. Le changement prendra pour point de départ l’élément de production connu qui sert donc de référence. Lorsque le changement est achevé, l’élément se trouve dans un autre état qui devient la nouvelle référence.

Le contenu du périmètre est délimité, il est clairement séparé de tout autre environnement ne concourant pas à la même production ou servant une autre finalité (test, probatoire,...).

Le périmètre est protégé par les procédures de gestion de changements (voir plus bas) qui permettent au « producteur » de maîtriser les éléments de production et d’assumer dans le temps sa responsabilité de garant de la production industrielle.

Cela se traduit par des droits d’accès et d’administration isolés et protégés par des outils de sécurité.

Cette protection peut aussi se matérialiser par l'emploi d'outils de transfert entre environnements . Les validations et possibilités de retour arrière sur changement seront prévues.

Il n'y a donc pas d'élément sans propriétaire, ni d’élément à propriétaires multiples.

Le propriétaire est une entité de l’organisation (qui peut être chez le producteur mais aussi ailleurs, selon le découpage effectué).

Assez souvent deux types de propriétaires sont identifiés: les divers gestionnaires de service ou responsables applicatifs pour tout ce qui est de nature fonctionnelle et des entités de type « ingénierie » ou « support technique » pour tout ce qui concerne les moyens techniques de type infrastructure.

Dans le cas de recours à des progiciels (exemple : SAP, Oracle Applications,…) un représentant interne à l’organisation est souhaitable pour porter la responsabilité.

Le propriétaire doit définir ses exigences en termes de production opérationnelle : le niveau de service attendu (sécurité, performance,...), les évolutions, donc les changements à prévoir sur ses objets.

Le propriétaire doit fournir au producteur opérationnel un produit fini complet (y compris consignes,...) de manière à ce que cela puisse être pilotable et puisse "marcher sans lui".

Le propriétaire prévoit et communique les ressources nécessaires, et leur évolution.

Il se conforme aux normes et préconisations négociées régissant ses relations avec le producteur opérationnel.

Le producteur opérationnel s’adresse au propriétaire de l’élément pour toute escalade sur incident ou tout changement concernant cet élément.

Le propriétaire doit résoudre les problèmes qui concernent ses éléments et il est l’initiateur des changements sur ses éléments.

Le propriétaire s’adresse lui-même à divers fournisseurs internes ou externes.

On peut ici se référer au vocabulaire de l’ITIL ou autre référentiel. Toutefois, ces référentiels ne disent rien sur les responsabilités qu’il faut donc introduire.

Configuration :

Les éléments de configuration sont les éléments du périmètre de production qui concourent à la production de service et présentent l’une ou l’autre des caractéristiques suivantes:

• ils sont attachés à un coût (amortissement, maintenance,...)

• ils sont susceptibles d’être changés,

• ils sont susceptibles de connaître un incident.

Aucune distinction n’est faite entre des éléments dits techniques et des éléments dits applicatifs. Tous ces éléments concourent ensemble à la production de service. C’est sur les éléments de la configuration que vont porter les changements et les incidents.

Un élément qui n’est pas dans la configuration de la Production ne participe pas à la Production du Service.

Le niveau de finesse de définition des éléments de la configuration peut varier. Normalement l’élément de configuration est la plus petite entité susceptible d’être changée indépendamment des autres.

Un outil de gestion de configuration sera utilisé. La base de données ainsi gérée devra être maintenue. Par expérience c’est difficile. Il existe aussi fort probablement d’autres configurations gérées ailleurs par les « responsables » d’éléments (dans les équipes de type ingénierie par exemple) avec des niveaux de détails et de suivis probablement plus fins. Au besoin, il faudra réaliser des extractions de ces bases vers la base de production. Une entité de type « gestion des changements » peut se voir confier une responsabilité au moins de contrôle de bonne gestion de la base en production.

Incidents :

Tout élément de configuration comporte des spécifications décrivant son comportement attendu « normal ».

Un incident est une occurrence d’écart entre les spécifications d’un élément de configuration et ce qui est constaté. Un incident concerne toujours un élément de la Configuration. Un incident peut ne pas avoir d’effet immédiat sur le service rendu au client, néanmoins l’objectif de la gestion d’incident est de rétablir le service en conformité avec les Conventions de Service.

Le « pilote » de la production doit être capable d’identifier l’incident et de savoir ce qu’il faut faire pour aller vers un rétablissement du service dans un état conforme aux Conventions de Service.

Différent type de workflows sont à prévoir :

• rapide, en recourrant aux solutions connues (ou remèdes connus, ou erreurs connues,…) pour rétablir vite le service au niveau des opérations ou pilotes,

• d’escalade pour action vers les entités « propriétaires » ou autres experts lorsque le pilote n’a pas -ou estime ne pas avoir- les moyens de rétablir le service,

• d’information vers toute entité ayant à savoir ce qui se passe en terme de service au client.

On s’attachera à rendre plus fréquents les flux rapides et plus rares les flux lents. Cela se fait de plusieurs manières (transfert de savoir-faire de l’ingénierie vers la production, documentation d’incidents et de corrections, etc.)

Le flux pour information doit être suffisamment informatif : il ne faut pas perturber l’opérationnel par des questions d’incompréhension.

Changements :

Un changement est un événement prévisible qui, par sa réalisation ou son activation, produit la création, la suppression ou la modification d’un élément de la configuration, ou fait évoluer les relations qui lient des éléments.

L’impact d’un changement s’estime par rapport à la perturbation ou au risque de perturbation qu’il apporte à la production et non par rapport à sa taille (en nombre de programmes ou autres,...) ou à son importance technique.

Un changement est traité par une procédure spécifique qui tient compte des exigences de la production de Service. Cette procédure prévoit des validations.

Les changements se demandent dans un format convenu. Ils sont acceptés, replanifiés ou refusés. Un Comité Changement doit exister et statuer.

L’évaluation d’impact doit être faite avec rigueur. Sur les impacts élevés, une diminution du risque (par prévision du retour arrière par exemple) devra être obligatoirement proposée.

La mise en oeuvre des règles qui suivent permet d’augmenter la rentabilité, la proactivité de la production et de diminuer les risques.

Elle n’est cependant pas systématique car elle nécessite un investissement dont la rentabilité n’est pas forcément obtenue dans le cadre des situations diverses observées.

Il est possible d’y associer le client ou l’utilisateur.

Les éléments de production renseignent sur leur état le pilote opérationnel du service. Celui-ci possède des informations lui permettant de découvrir et de traiter les incidents.

Le pilote opérationnel s'engage à produire un service conforme à ce qui est négocié avec le gestionnaire du service. Concrètement cela signifie que les incidents en exploitation sont traités par le pilote, par application des consignes fournies et l'ouverture procédurée d'incident qui provoque les escalades prévues.

Cela signifie que le pilote a une intelligence du service produit. Intelligence communiquée formellement par le gestionnaire du service.

Face à des éléments non pilotables un effort minimal est à entreprendre pour faire remonter des alertes et définir des consignes. Les actions dans ce domaine sont des projets d’ampleur variable selon le coût, les améliorations attendues et le niveau de risque acceptable. Ces projets font l’objet d’études de retour sur investissement. Il est fortement probable qu’un minimum vital soit à atteindre dans ce domaine.

Il est inconcevable qu’une production puisse être qualifiée d’industrielle et possède encore des éléments non pilotables. L’existence d’éléments non pilotables provoque souvent des dépendances de type astreinte vis - à - vis des propriétaires de ces éléments ou de leur fournisseurs. Cette situation provoque des surcoûts, de la non-qualité et empêche le producteur opérationnel d’assumer sa responsabilité.

Le propriétaire d’un élément doit s’assurer qu’il est pilotable…sans cela il le paie par une escalade du pilotage vers lui avec les charges et astreintes induites.

L’automatisation consiste à pouvoir enchaîner des tâches sans intervention humaine.

En effet, certaines tâches doivent disparaître; il s'agit par exemple des opérations simples répétitives, des opérations qui nécessitent de manière excessive une présence d'opérateur en salle (« message console ») et qui donc sont génératrices de coûts ou encore d’opérations laissant trop de place à l’erreur humaine.

L’obtention d’un bon niveau d’automatisation nécessite souvent un véritable réingéniering de l’exploitation : amélioration des séquences, du parallélisme, suppression d’étapes inutiles, programmation de contrôles...

Les actions dans ce domaine sont des projets d’ampleur variable selon le coût et les améliorations attendues. Ces projets font l’objet d’études de retour sur investissement.

Cette normalisation peut porter sur les choix techniques (type de fichiers ou bases à utiliser, codage de JCL ou de script, paramètres divers, etc...) mais aussi sur les nommages etc...

Chaque cas amène potentiellement sa ou ses normalisations dont certaines sont probablement intéressantes à conserver en l’état.

Les actions dans ce domaine sont des projets d’ampleur variable selon le coût et les améliorations attendues. Ces projets font l’objet d’études de retour sur investissement.

Il conviendra de traiter différemment les situations héritées et les situations pour lesquelles un degré de choix existe (Etude en interne, client en recherche de normes par exemple).

Pour des raisons de diminution de coûts liés par exemple à une mutualisation sur des outils ou des produits connus, il peut être intéressant de faire évoluer tout ou partie d’une exploitation donnée vers telle ou telle cible.

Le passage d’outils « maison » vers des outils standard du marché sera très fortement recommandé.

Il conviendra de traiter différemment les situations héritées et les situations pour lesquelles un degré de choix existe (Etude en interne, client en recherche d’outils par exemple).

Plus que toute autre, les actions dans ce domaine sont des projets d’ampleur variable selon le coût et les améliorations attendues. Ces projets font l’objet d’études de retour sur investissement.

Une production "industrielle" est souvent présentée comme un idéal à atteindre dans le monde de l'informatique qui est soumis à forte turbulence. Il est nécessaire pour cela de se donner des règles strictes et de les respecter.

La prise en compte des responsabilités que ces règles induisent introduit progressivement des cercles vertueux d'amélioration. La délimitation claire des responsabilités permet aussi d'améliorer le professionnalisme de chacun qui voit son métier reconnu dans un contexte apaisé.

Enfin on soulignera l'importance de la rapidité de décision et d'exécution dans le cadre des règles pour rester réactif aux demandes de l'usager.

Depuis une vingtaine d’années, les fournisseurs d’outsourcing, tout d’abord exclusivement américains, sont devenus internationaux. Le choix entre des solutions de « near, middle ou off » shoring est bien plus vaste en 2012.

En informatique, l’outsourcing est maintenant possible pour quasiment toutes les fonctions. Au début, il s’agissait surtout de gestion de centres de production, avec si possible les équipes de développement technique (support d’exploitation ou gestion de la production) et de bureautique.

Ensuite, une deuxième étape est apparue avec la TMA, puis les développements fonctionnels (développement d’applications par nature d’activité métier). En parallèle le développement de progiciels internationaux a connu un fort essor, y compris en Asie.

En même temps, le BPO de fonctions de back office, comme la production des feuilles de paie, la gestion des dossiers RH, la saisie des factures ou le traitement de la comptabilité, a également connu un fort essor, lorsque ces fonctions sont délocalisables dans des pays de main d’œuvre à bas coût.

Au cours des dix dernières années, les Directeurs financiers et les DSI ont expérimentés les « bons » et les « mauvais » aspects de l’outsourcing, suivant la nature des services concernés et le choix de la zone géographique. Ils ont notamment été confrontés aux nombreuses questions qui doivent être abordées avant de s’assurer d’un choix pérenne, notamment dans le cas plus complexe d’une solution off shore. Enfin la maturité de gouvernance des contrats offshore s’est également développée.

Cette série de trois articles a pour objectif de résumer l’expérience acquise auprès des entreprises ayant pratiqué l’offshoring d’outsourcing informatique ou de BPO depuis les années 2000 et de proposer une liste de questions à se poser s’appuyant sur cette expérience, pour faciliter la prise de décision.

Le premier article détaille le contexte des fournisseurs indiens, le deuxième article aborde le potentiel chinois et le dernier propose une dizaine de questions, fondées sur les expériences acquises, à se poser avant de prendre une décision d’offshoring.

Au cours des années 1990, le monopole des grandes SSII était détenu sans conteste par les grands fournisseurs américains. IBM, HP devenu HP-EDS, Accenture et CSC avaient lancé le marché de l’outsourcing et les plus grands groupes internationaux avaient souscrit des contrats les engageant pour au moins 7 ans.

Au début des années 2000, les sociétés de services indiennes fondées sur un modèle de ressources humaines à faible coût, environ 4 fois moindre que celle des grands pays Européens ont commencé à signer des contrats de montants de plus en plus significatifs et ce, pour 7 ans minimum. Le mouvement vers l’est, commençait à apparaître.

Depuis dix ans, les indiens TCS, Wipro, Infosys, et HCL sont devenus des fournisseurs significatifs des grands groupes européens, banques-assurances et industriels. Ils ont vu leur valeur boursière exploser en 10 ans. Le marché indien de l’outsourcing a ainsi connu des taux de croissance de chiffre d’affaires de 20 à 30% par an depuis les années 2000.

Par exemple, Wipro est un fournisseur majeur de plusieurs grandes banques françaises en France. Sa filiale française dirigée par un français comptait mi 2011, 300 personnes, dont 80% de français. TCS a signé plusieurs contrats significatifs en Europe ces trois dernières années : En 2009, c’était la chambre de compensation de Londres qui lançait le développement de son nouveau système d’information à Bangalore et à Chennai. En 2010, c’était l’outsourcing mondial du back office de Deutsche Bank, pour la banque de détail qui était déplacé sur le progiciel Bancs à Bangalore. Après Bank of America, American Express, ou Hawai Airways qui avaient délocalisé leur informatique à Chennai, l’Europe suit depuis 3 ans la même tendance. La filiale française de TCS, dirigée par un indien, comptait 25 personnes fin 2009 et a vu ses effectifs multipliés par 2 en 2 ans.

Cette croissance des SSII Indiennes a été largement due à la disponibilité d’une large population d’informaticiens à des prix attractifs, issus des instituts technologiques du Sud de l’Inde. Le salaire d’un ingénieur débutant est d’environ 25 000 roupies par mois, soit 380 euros. Les SSII indiennes ont également investi en formation spécifique. Par exemple, Infosys a créé, non loin de Bangalore son propre campus de formation capable d’accueillir 27 000 étudiants chaque année (en 2 promotions de 6 mois chacune), pour compléter les formations trop académiques des instituts. TCS a créé son propre centre de formation à Chennai.

Mais les chiffres de croissance du dernier trimestre 2011 montrent quelques signes d’inflexion, en lien avec la crise d’abord américaine, puis européenne. Aucune des quatre SSII n’affiche cette année plus de 5 % de croissance. L’année dernière, le plus mauvais score était de 8,94 %, pour HCL. Pour Wipro, la croissance séquentielle au troisième trimestre 2011 est même négative, à -3,65 %. Côté bénéfice net, la situation n’est guère meilleure : ils reculent de plus de 6 % séquentiellement chez HCL et Wipro. En résumé, les beaux jours semblent terminés pour les SSII indiennes.

Il est important de noter, dans ce contexte, qu’Accenture garde une position mondiale dominante. Une explication pourrait être que c’est le premier fournisseur ayant un profil « global ». Il est capable sur un même projet de contrôler les compétences métier, l’informatique et les process et ce quel que soit le pays d’intervention. Il faut noter aussi que ses équipes en Inde sont en croissance régulière depuis 2005.

De nombreuses sociétés françaises ont investi dans des captives (filiales informatiques localisées en Inde) en Inde ou à Singapour, pour des fonctions non stratégiques, sans toutefois atteindre des volumes significatifs.

En général, un des principes fondamentaux de création d’une captive à l’est est le développement de l’activité de l’entreprise dans le pays. De surcroit, si cela apporte également l’occasion de bénéficier d’un centre informatique international à coût réduit, la captive atteint une taille significative. Dans le secteur bancaire, ces captives ont connu une croissance significative au cours des 5 dernières années. La société Générale possède une captive de 1 200 personnes à Bangalore, en croissance régulière depuis 3 ans, BNPP a également investi à Chennai, Axa, aussi, etc… CACIB a une captive à Singapour, pour le marché APAC. Souvent les prestations informatiques s’accompagnent de BPO de process de back-office.

Il faut noter que les captives ont du mal à recruter, car elles n’ont pas la préférence des meilleurs étudiants qui préfèrent les SSII, plus porteuses d’évolution de carrière rapide. Pour pallier ces carences, de nombreuses captives utilisent beaucoup de sous-traitance auprès des SSII locales, notamment pour bénéficier de profils expérimentés ou du savoir faire (procédures), dont ils manquent en interne. Sinon, ce savoir-faire doit provenir du Siège européen, mais à un coût de salaire européen, ce qui en réduit l’avantage financier.

Est-il possible d’en déduire que c’est une des raisons principales pour lesquelles les captives connaissent une faible croissance ? Le risque pour la société Mère européenne est faible, car en cas d’objectifs non atteints, elles sont revendues aux SSII locales. Par exemple, l’indien Cognizant, a annoncé le rachat en octobre 2009 des activités indiennes de la banque suisse UBS et reprend un effectif de 2 000 personnes.

Néanmoins l’expérience de la sous-traitance auprès des SSII indiennes (ou Captives en Inde) a mis en évidence des difficultés caractéristiques. En effet, il n’est pas toujours facile de travailler à distance avec des cultures différentes.

D’abord, leurs ressources humaines sont « limitées », en termes de quantité ou en termes de profils. En Inde, environ un million d’ingénieurs sont diplômés chaque année et se répartissent dans tous les secteurs, le high tech (salaire annuel de 8000$), l’industrie et les SSII indiennes (en concurrence avec IBM, Accenture et CSC). Il subsiste néanmoins une carence notable en profils expérimentés. Ils préfèrent en effet, partir travailler à l’étranger dès que cela leur est possible, c’est –à-dire lorsqu’ils affichent une expérience suffisante. Il est ainsi « facile » de trouver des développeurs java, mais plus difficile de trouver des chefs de projet expérimentés, des spécialistes Oracle de plus 3 ans d’ancienneté, des experts en automatisation de gestion de réseau, des architectes ou des experts en modèles de données. Dans ce contexte, plusieurs contrats n’ont pu être honorés avec le niveau de qualité négocié dans le contrat initial, par manque de ressources de profils clés.

Le taux de l’inflation en Inde est en croissance régulière. Il était en octobre dernier proche de 10% /an, après une année précédente avoisinant 14%. Depuis mars 2010, la Banque centrale indienne a relevé douze fois ses taux d'intérêt, c’est la plus longue période de resserrement monétaire en Inde depuis plus de dix ans. Cette tendance ne devrait pas s’inverser prochainement.

Le turn over des sociétés de service indiennes est en nette augmentation. Pour augmenter leurs salaires, les jeunes salariés indiens ne peuvent que changer de société en « traversant la rue » notamment à Bangalore, car leurs employeurs bloqués par des contrats à prix contrôlés sur plusieurs années et ne peuvent les augmenter sous peine de voir diminuer leurs marges. La principale conséquence de cette situation est l’impossibilité de respect des clauses du contrat initial, notamment si c’est un chef de projet clé qui quitte la société. Il sera remplacé par un profil de moindre expérience. Le projet connaitra des difficultés de qualité de service, en délais et en budget. Par exemple, Infosys a connu en 2010, un taux de départ de 17% et a recruté 25 000 ingénieurs. TCS également était proche de 18%.

La maîtrise de la langue anglaise (orale et écrite) des ingénieurs formés dans les universités indiennes du Sud est encore imparfaite au sein des populations techniques qui n’ont pas encore voyagé. Leur accent est très fort (r roulés, « s » difficiles à prononcer, etc …. Il est particulièrement difficile de faire travailler des équipes franco indiennes en réunions téléphoniques à cause de ces problèmes de langue. De nombreux centres de support téléphonique de Bangalore, pratiquent des tests avant l’embauche, mais ceux-ci sont insuffisants. Beaucoup de clients européens ont une image de mauvaise qualité de ces centres. L’écrit pose également des difficultés, notamment avec les multiples langues européennes. De nombreuses erreurs de traduction dans un contexte de BPO ont été constatées dans les sociétés, ainsi que dans l’enregistrement des valeurs car les chiffres sont souvent inversés, (ce n’est pas leur mode d’écriture natif). C’est une des raisons pour lesquelles la TMA (spécifications en anglais) est un succès. Le contenu fonctionnel est en général peu complexe et il n’est pas nécessaire d’avoir beaucoup de contacts oraux avec les utilisateurs pour détailler une fonction clé. L’écrit peut suffire pour 80% des échanges.

Les pratiques manageriales sont différentes des nôtres. La culture indienne est à l’opposé de la nôtre qui comporte un organigramme avec des responsabilités claires entre les managers sur plusieurs niveaux et des procédures à respecter, sous contrôle de la direction ad hoc. En Inde, le niveau managerial n-1 n’existe pas. Vu par le manager français du client, tous les problèmes sont reportés sur une seule personne qui n’ayant personne à qui déléguer se retrouve débordée. La polyvalence des tâches ne se pratique pas naturellement, il y a souvent dans une équipe un profil clé. Lorsqu’il est absent, car il ya beaucoup de jours fériés (fêtes religieuses) en Inde, toutes les décisions sont retardées. Des tentatives de mise en place de processus contrôle qualité sont en cours dans la plupart des grandes SSII, mais il subsiste encore de forts potentiels d’amélioration.

La culture religieuse locale influe sur la disponibilité des ressources. Les indiens, notamment dans le sud de l’Inde sont de religion Indu, polythéiste. De nombreuses fêtes religieuses, jours de travail chômés, ont pour conséquence de nombreux vendredis + we, à effectifs réduits. Si cela correspond à un pic d’activité en Europe, le risque de panne et d’augmentation du délai de résolution augmente.

La gouvernance représente un coût en augmentation, souvent non budgété initialement ou non comptabilisé dans les calculs de rentabilité des projets. Ainsi, le coût managerial en Europe pour assurer la planification des besoins et des ressources, le pilotage des projets et la relation avec les utilisateurs européens (réunions, compte rendus) doit être comptabilisé, dans un contexte de 5h30 en moyenne, de décalage horaire. Les coûts de déplacement en Inde 1 à 2 fois par mois des managers européens (en conséquence absent de leur poste et injoignables à cause du décalage horaire et des délais de transport (nombreux retards d’avion en Inde) doivent être ajoutés aux coûts de téléconférences des équipe, ainsi que ceux des outils de communication informatiques et standards communs.

Enfin, le risque géopolitique doit également être pris en compte. L’inde est un pays d’1,3 milliards d’habitants qui parlent 26 langues différents, ont 2 écritures très différentes et d’importantes différences culturelles entre le nord et le sud. Lorsque des manifestations se produisent, comme au printemps dernier, les consignes données aux salariés sont de rester chez eux. Ils n’ont alors que leur téléphone portable comme outil de travail, les nombreuses coupures d’électricité ne justifient pas l’investissement d’un PC au domicile.

En résumé, cette liste de points se traduit par des coûts cachés qu’il faut estimer pour chaque projet et ajouter au montant du contrat facturé, avant de le comparer à une solution concurrente. Egalement, suivant la nature des services concernés, le niveau de qualité attendu versus fourni doit être détaillé exhaustivement avant de s’engager auprès d’un fournisseur pour plusieurs années. Par exemple, les contrats de TMA sont plus faciles à délocaliser en Inde pour des spécifications en anglais, alors que le développement d’une plateforme métier nécessitant des compétences fonctionnelles de haut niveau sera plus risqué.

Face aux difficultés que nous avons évoquées, de nombreux groupes français ont été déçus par l'externalisation offshore avec des fournisseurs indiens. D'autres clients sont, dans l'ensemble, plutôt satisfaits. Incontestablement, l'Inde a encore des atouts importants dans ce marché, mais les clients potentiels ont tout intérêt à dresser un bilan économique très lucide de leur projet avant de s'engager.

Dans la suite de cette série, nous regarderons d'autres "destinations" possibles en offshore, en Asie et nous évoquerons également une tendance au retournement de situation en near shore ou en re-internalisation en France.

Notre expert invité, Marie-France, est une amie de Duquesne Group de longue date. Elle a 35 ans d’expérience professionnelle, principalement acquise selon 3 grands axes :

- En tant que conseil de dirigeants, notamment pour KPMG et Accenture, puis en tant qu’entrepreneur
- En tant que DSI de grands groupes internationaux, au sein de LVMH et du Groupe BIC
- En tant que Directeur Commercial de grands acteurs du service informatique, notamment Hewlett Packard et Tata Consultancy Services.

Cette expérience lui permet de partager avec nos lecteurs - aujourd’hui et dans les quelques semaines qui viennent - une synthèse des acteurs mondiaux de l’outsourcing (notamment en mode « offshore »), marché qu’elle côtoie depuis 20 ans au quotidien.

Toute personne en charge de PCA ou soucieuse de la continuité de ses activités est concernée.

Ce cours développe une approche méthodologique structurée et complète, qui associe rigueur et pragmatisme.

Ce cours concerne

• Les responsables Risque ou Continuité (RSSI, RPCA)

• Les chefs de projets en charge du PCA ou des PRA

• Les managers informatiques (MOA, support, service, système)

• Les responsables métiers en charge de la continuité ou désireux de s'informer

• Les auditeurs NTIC, ITIL ou sécurité

Plus généralement toute personne intéressée par la Continuité d'activité et son actualité trouvera intérêt à ce cours.

Le formateur :
E.Besluau pratique la Continuité d'activité depuis plus de vingt ans dans diverses entreprises.

Il est l'auteur de l'ouvrage "Management de la Continuité d'activité" (Editions Eyrolles 2008 & 2010)

Cette formation associe une base théorique raisonnée illustrée d'exemples afin de :

• Donner aux participants la compréhension des approches et enjeux de la Continuité d’Activité.

• Permettre d’expliquer et d’initialiser correctement une démarche PCA ad-hoc.

• Donner une méthode pour construire la CA en entreprise et aboutir à la réalisation d’un PCA.

En particulier le cours donne une méthode de projet étape par étape pour mener à bien la construction d'un PCA.

Les diverses définitions :

• anglo-saxonnes

• le Journal Officiel

• la jungle des termes couramment employés : PRA, PSI, DRP, BCM, etc.

Comment situer les approches :

• la construction du PCA, à l'aide d'un projet

• le maintien en condition du PCA

• l'exécution du PCA suite à sinistre

Comment s'organiser :

• le comité de pilotage du projet

• le RPCA

• les correspondants

Comment positionner et mettre en place :

• la politique de continuité,

• les contrôles

• les audits.

Enfin un point rapide sur les normes ISO, BSI, DRII, etc. est fait.

Un certain nombre d'études sont à mener pour préparer l'entreprise et son PCA :

L'analyse du risque :

• les étapes obligatoires et comment les aborder

• comment appréhender le risque ?

• en quoi la Continuité d'activité est-elle particulière ?

• exemples pratiques

.
Le Bilan de l’Impact sur les Affaires (BIA business impact analysis) :

• qu’est-ce qui permet de dire que telle activité est critique ?

• comment mener une analyse d'impact efficace et partagée ? qui le fait ?

• quels sont ses processus critiques ? de quoi ont-ils besoin ?

La formulation de la stratégie de continuité :

• que décider de faire en cas de sinistre ?

• quelles options sont ouvertes ?

• lesquelles étudie-t-on ? comment choisir ?

• que faut-il préparer ?

A chaque fois, les concepts sont expliqués et une approche méthodique présentée.

Il faut organiser la réponse au sinistre et pour cela aborder :

Le dispositif de gestion de crise :

• qui compose la cellule de crise ?

• de quels moyens la doter ?

• responsabilités ?

Les groupes d'intervention :

• missions et responsabilités

• listes types

• profils, listes de contacts

Le Plan d'exécution de la réponse au sinistre :

• passage en revue d’un plan complet de reprise

• contenu, travaux, qui fait quoi, communication et escalade

• présentation de listes-types utiles

.

Une fois tout cela réalisé, il reste à le mettre à l'épreuve et le tenir en état de fonctionner.

Les test du Plan de Continuité :

• comment s’assurer que « ça marche »

• quels types de tests faire ? les différences

• comment préparer une campagne de test ?

• quel usage post-mortem des tests ?

• notion de test probant ?

La Maintenance du Plan de continuité :

• que faut-il surveiller ?

• comment mettre à jour son Plan ?

• quels moyens ?

Enfin l'intérêt de formations de sensibilisation des personnels est abordé.

Ces trois aspects sont fondamentaux et opèrent ensemble.

Ils sont abordés dans le cours avec des recommandations issues de l'expérience sur divers mises en oeuvre concrètes.

Le document de politique de continuité :

• comment le construire ?

• quel contenu ?

• qui le signe ?

• quelle actualisation ?

Les contrôles par le management :

• que peut-on contrôler ?

• quelle trace laisser ?

Les audits

• que peut-on auditer ?

• comment se préparer ?

• tableaux de bord

A la fin de la formation, le participant aura acquis :

• une compréhension des enjeux de la continuité en entreprise

• une vision claire et de ce qu’il faut ordonnancer en termes de décisions et de projets

• une méthode de construction du PCA

• les bases d'un outil de gouvernance

Veuillez télécharger le document ci-dessous et suivre la démarche qu'il indique.

A noter : une formation intra-muros peut être organisée sur demande. Veuillez nous laisser un message sur le site dans ce cas.

Despite the morose economic climate, Tech M&A continued to grow in the third quarter of 2011: $56.5 billion according to a November report from Ernst & Young, up 22 percent from a year ago.

According to E&Y, that total value was the highest for any quarter since 2007, with big deals such as Google/Motorola and HP/Autonomy leading the way.

The fourth quarter is showing some serious action too, with the announcement of an all cash $3.4 billion acquisition by SAP of SuccessFactors, a fast growing provider of cloud-based human capital management (HCM) solutions.

On December 03, 2011, SAP and SuccessFactors, Inc. announced a definitive merger agreement under which SAP (America) will offer to acquire all outstanding shares of common stock of SuccessFactors for $40.00/per share in cash, representing an enterprise value of approximately $3.4 billion, with a 52% premium over the market.

Upon completion of the transaction, the CEO of SuccessFactors, Lars Dalgaard, will lead the cloud business of SAP in addition to his responsibility as CEO of SuccessFactors, which will remain a standalone unit.

According to Bill McDermott, SAP Co-CEO: “the cloud is a core of SAP’s future growth, and the combination of SuccessFactors’ leadership team and technology with SAP will create a cloud powerhouse. “ McDermott added: “the acquisition will help us address the top priority for CEOs globally – managing people and talent.”

The transaction is expected to close in the first quarter of 2012

Overall, we see this deal as somewhat “pricey” but arguably justifiable. It certainly shows that SAP, a usually slow moving and traditional company, is finally getting serious about the new world of Software-as-a-Service (SaaS) but will need to address both product and ecosystem questions. A particularly interesting angle is that they are also getting the charismatic Lars Dalgaard as the head of all SAP cloud business.

In today’s volatile market, the 52% premium does not mean much. Valuation multiples are more significant, especially revenue valuation multiples since fast growing software companies often run losses in their early years.

SuccessFactors is projected to do about $330m in sales in 2011, implying a fairly steep multiple of 10 times revenue. That number is roughly twice the multiple that SAP paid in 2010 for Sybase, admittedly a much more mature business.

The obvious comparison is with Oracle’s recent purchase of RightNow Technologies, a provider of tech support and salesforce automation tools, at about 6.6 times sales.

Of course, deals for small but high growth software companies are often done at high revenue multiples, and SuccessFactors’ projected growth of 57% this year is indeed impressive. It also has a strong Board level value proposition: human capital management to improve successful “execution” of business decisions.

Just as important, however, may be the “strategic fit” of SuccessFactors with SAP, as the German software giant comes to grip with the SaaS cloud delivery model.

Like it or not, the big established software companies are having to face the reality that the SaaS delivery model is not going to go away and is only going to get bigger.

SAP has over 176 000 customers worldwide but has had only limited success with its own SaaS offer, the Business by Design software aimed at mid-sized companies. Market acceptance of Business by Design has been underwhelming, and SAP recently reiterated its (very) modest objective of 1,000 customers on Business by Design by year-end.

Many observers have underscored that the German company risked losing ground to its competitors. As noted earlier, US rival Oracle recently announced a $1.5 billion deal to buy cloud computing firm RightNow Technologies. Salesforce.com, the SaaS pioneer, remains the market leader.

SuccessFactors - with 3,500 customers and 15 million users in 168 countries - is widely considered to be the second-biggest pure play SaaS firm, second only to Salesforce.com. With this acquisition, SAP appears to be taking the cloud delivery problem seriously.

It does, however, raise some questions.

The first concerns the positioning and sale of multiple products in more or less the same enterprise market space. SAP already has an on premises HR offering. How will the SAP sales force explain to customers when to use the on premises offering and when to go with the new SaaS solution, especially given the differences in pricing?

The second question concerns the ecosystem. As recently as September 2011 in Bonn, Rainer Zinow, the head of Business By Design, told us that SAP had no medium term intention of continuing to operate SaaS data centers (at least for Business by Design), preferring that cloud delivery be ensured by partners like T-Systems and other operators. We could also mention that SAP and IBM announced a partnership in September of this year to deliver the SAP CRM solution from the IBM cloud. Given SAP’s stated ambition to become a “cloud powerhouse”, what will be the role of its partners in solutions delivery?

A particularly interesting angle is that Lars Dalgaard, Founder and CEO of SuccessFactors, will become the head of all SAP cloud business.

Originally from Scandinavia, Lars Dalgaard has achieved considerable recognition in Silicon Valley as an extraordinarily charismatic and successful entrepreneur. For example, he was chosen as “Best CEO of a large company” in the 2010 San Francisco Business Times Innovation and Technology Awards, and E&Y “Entrepreneur of the year” in 2009.

He is also known for ferocious customer centricity. He has been quoted as saying that “the big software companies don't have a clue, because they stopped listening to their customers a long time ago." They just don’t understand that “the customer must win.”

His proudest claim is that all of the SuccessFactors software was designed and built in close collaboration with customers, an approach that industry luminary Patty Seybold has called “customer co-innovation”.

True to form, he is boundlessly enthusiastic about the deal with SAP, calling it “revolutionary combination” destined to become “legendary”. He has no doubt that the world is ready for enterprise-class cloud applications and that together with SAP, “we can deliver incredible new innovation for global businesses.”

As the future head of SAP cloud business, he will have a big part of the responsibility for keeping those promises.

The acquisition of SuccessFactors is perhaps this year’s single most interesting TECH M&A deal.

SAP paid a fairly stiff price, but the premium is arguably justified by what’s at stake. The German software giant is taking SaaS seriously as an emerging mainstream delivery model, although issues remain around product positioning and ecosystem roles. Lars Dalgaard is an audacious choice to head up the company’s cloud business, but there is no lack of risks.

It’s much to early to predict how all of this will turn out, but we will be following SAP’s big move into SaaS with considerable interest in 2012.