Comme Directeur chez OCTO Technology, pour le secteur des opérateurs télécoms, je m’intéresse de près aux questions touchant la relation client, d’un point de vue métier comme SI. J’ai donc assisté récemment à une conférence de l’EBG (Electronic Business Group, « club d’affaire de l’économie digitale en France ») sur le comportement client en multicanal. Elle fait écho à l’article de Damien Joguet sur ce même blog et plus largement à des réflexions qu’OCTO mène sur le multicanal et les architectures de SI qui en découlent.

Plutôt qu’un compte-rendu détaillé des excellents échanges auxquels j’ai assistés, je choisis de vous faire un retour subjectif et succinct. S’il amène plus de questions que de réponses, contactez-moi, je serai enchanté!

(Lire la suite…)

J’entends souvent la question suivante : L’architecture d’entreprise (EA) doit-elle être centrée sur la vision Métier ou Technologique ?

On parle aujourd’hui de plus en plus régulièrement d’architecture Business et on réalise facilement l’amalgame avec l’EA.

L’architecture Business n’est qu’un domaine de l’architecture d’entreprise qui, pour reprendre la définition donnée par TOGAF, en comporte quatre (Business, data, application, technology). Elle adresse la stratégie Business, l’organisation, les Business process clés et les interactions entre ces éléments. L’architecture d’entreprise adresse également la couche technologique permettant de supporter l’architecture Business.

La notion de capacité (capability) que l’on retrouve dans TOGAF est ici intéressante :
(Lire la suite…)

Cet article fait partie d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.

• Les systèmes mutualisés : enjeux et risques
• Les systèmes mutualisés : comment réaliser une gouvernance efficace
• Les systèmes mutualisés : démarrer et ne pas se perdre

Evaluer l’opportunité de lancer un projet de mutualisation et définir le périmètre d’un tel système n’est pas simple et doit faire l’objet d’une analyse en amont qui prend en compte plusieurs variables comme la valeur métier/sectorielle, l’homogénéité des processus dans les entités, etc. Dans ce contexte, l’article part de l’hypothèse que l’opportunité de mutualiser les processus de plusieurs entités de l’entreprise a été identifiée et que la décision de construire un système mutualisé est prise.

Pour réussir à mettre en place un système mutualisé, il faut non seulement réfléchir aux contraintes intrinsèques de la solution mutualisé mais aussi à celles liées au contexte de l’entreprise et à son organisation. Ceci dans le but de concevoir une solution unique faisant converger les processus tout en offrant suffisamment de souplesse pour permettre la subsidiarité nécessaire à chaque entité.

La construction d’un tel système représente un vrai challenge et un jeu de forces qui n’est pas simple à gérer. Néanmoins le projet peut être mieux maitrisé si dès le démarrage nous prenons en compte les éléments suivants :

• Définir le modèle de production et développement
• Définir la frontière entre le cœur et le spécifique
• Définir le niveau de mutualisation
• Concevoir un produit adapté pour maitriser la part du spécifique
• Assurer l’intégration dans des environnements divers
• Adopter une démarche itérative et incrémentale

(Lire la suite…)

Introduction

Cet article est le deuxième d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.

(Lire la suite…)

Cet article est le premier d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé et les enjeux d’un tel système, donner nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance.

Les systèmes mutualisés : définition

Un système mutualisé est un système implémentant des processus et des fonctions communes à plusieurs entités. Ainsi, des systèmes multi-entité, multi-pays, multicanal de distribution à destination de populations d’utilisateurs différentes et multi-ligne de marché sont des systèmes mutualisés. Par exemple, les systèmes suivants sont des systèmes mutualisés :

• En assurance : un système multi-ligne de marché de gestion des remboursements santé pour les assurances individuelles et les assurances collectives
• En banque : un système multi-pays de gestion des contrats commun à la France, l’Espagne et la Pologne
• En distribution : un système multi-ligne de marché et multi-pays d’encaissement, commun à des petites, grandes surfaces et magasins discount et installés sur l’ensemble de l’Europe
• En télécommunication : un système multicanal de souscription de contrat utilisé en boutiques, par les conseillers téléphoniques et par les internautes
• En industrie : un portail client multi-ligne de marché et multi-pays, commun à l’ensemble des divisions d’un grand groupe industriel

La problématique des systèmes mutualisés a déjà été abordée par OCTO lors de l’Université du SI : Les SI multi-entité.

(Lire la suite…)

Il y a peu, je participais à une réunion de travail impliquant une trentaine de personnes et j’ai fait une observation qui m’a intrigué. Avez-vous remarqué ce qui se produit lorsqu’un téléphone portable sonne au cours d’une réunion ?

• La personne propriétaire du portable l’éteint rapidement
• Tous ceux qui ne l’avaient pas encore fait vérifient leur portable et activent discrètement le mode silence.

Voilà un exemple de mesure préventive particulièrement efficace! Dans les entreprises où l’on respecte un certain standard de réunion, l’exception que constitue la sonnerie d’un portable ne se produit qu’une seule fois, pas deux. La première “infraction” protège le groupe de toute nouvelle occurrence. Elle agit en quelque sorte comme un “vaccin” sur le fonctionnement du groupe en réunion.

Quelles conditions faut-il réunir afin de créer d’autre vaccins de ce type au sein d’une équipe ? (Lire la suite…)

Le BigData, une nouvelle (r)évolution pour les entreprises?

McKinsey a publié récemment un rapport sur l’avènement du BigData comme nouveau paradigme de compétition entre les entreprises.

L’analyse massive et le développement du capital informationnel (le BigData) deviendrait un nouveau levier pour la productivité, l’innovation et la croissance.

(Lire la suite…)

En 2007 ITIL (IT Infrastructure Library), a lancé sa version V3 en devenant le référentiel le plus répandu de bonnes pratiques pour le management de services informatiques (ITSM). Il se focalise sur le « comment » gérer chaque phase d’un service, en contraste par rapport à des autres référentiels qui se focalisent sur le « quoi », ce qu’on doit gérer.

ITIL v3 élargit le périmètre en donnant une vue “cycle de vie” des services, par rapport à sa deuxième version (v2) qui se focalisait sur les processus pour le Soutien de Services (Service Support) et la Fourniture de Services (Service Delivery)[i],

Cet article vous présente d’une façon globale ITIL à l’égard de la version 3 en montrant son but, les bonnes pratiques proposées pour gérer chaque phase d’un service et ce dont il faut tenir compte pour l’adoption de ce référentiel.

(Lire la suite…)

L’Agile est aujourd’hui un outil puissant d’amélioration de la qualité des produits et de la satisfaction des acteurs, utilisateurs comme artisans du système d’information.

Si la méthode commence à être connue, sa mise en œuvre peut néanmoins se heurter à des difficultés, notamment sur le volet contractuel.

Ainsi, dans les organisations où les pratiques d’achats reposent sur une définition exhaustive des besoins (i.e. cahier des charges) et une obligation de résultat portant sur un périmètre figé et qui ne peut évoluer qu’à l’aide d’avenants, il est souvent difficile voire impossible de concilier ces pratiques avec les principes fondamentaux de l’Agile à savoir : autoriser le changement, affiner et spécifier les fonctionnalités au fil de l’avancement du projet pour répondre mieux aux besoins des utilisateurs.

Alors que faire ? Comment concilier des principes d’achats bien rodés mais a priori antagonistes avec les principes de projet Agile ? Peut-on faire évoluer ces principes ? Chez OCTO, nous avons la conviction qu’il existe des moyens d’y parvenir en respectant les contraintes et les enjeux de votre entreprise.

Nous vous proposons d’échanger avec vous sur ce thème et pourquoi pas vous accompagner dans un travail en profondeur sur vos pratiques d’achats et de contractualisation.

Pour commencer nos échanges, nous offrons 2 séances de travail de 2h gratuites au 3 premières entreprises qui nous contacteront.

Contactez-moi pour cela sur ymartel@octo.com et travaillons ensemble à améliorer un peu plus votre ingénierie informatique!

Nos DSI pensaient avoir passé un cap en mettant en place des infrastructures de site web client, boutique en ligne, support… Ca a été difficile, notamment pour rendre disponible sur des applications Internet des services de coeur de SI, qui n’avaient pas du tout été conçus dans cette logique, mais au moins on espérait en avoir fini avec les remises en cause.

Et bien non: les tablettes tactiles arrivent, iPad, tablettes Android, etc., y compris en B2B, et elles vont changer certains des métiers, dont la vente et la distribution. Et comme les applications Internet, elles vont poser de nouvelles difficultés en nécessitant un accès selon de nouvelles modalités à des services parfois (souvent) profondément enfouis dans nos systèmes d’information.

(Lire la suite…)