Les CEO et les CIO n’ont pas la même perception des coûts IT

A lire sur:  http://www.ictjournal.ch/fr-CH/News/2013/10/16/Les-CEO-et-les-CIO-nont-pas-la-meme-perception-des-cots-IT.aspx

17.10.2013 11:18 (Marion Ronca)

Des perceptions parfois très divergentes en matière de budgets IT peuvent peser sur les relations entre CEO et CIO. (Source: Fotolia)

Les CEO et les CIO ont des représentations différentes des dépenses IT. Tandis que les CIO se basent sur des hypothèses réalistes, les CEO croient les budgets plus élevés, et en attendent du coup trop.

Les budgets IT ne constituent pas un simple cadre des coûts pour les CIO. Comme le montre l’étude récente de Forrester «2013 CIO Budget Priorities», les budgets IT sont la plupart du temps associés à des attentes élevées en matière de rentabilité. Si bien que, lorsque les CEO se trompent dans l’évaluation du montant effectif des dépenses et de la valeur de l’IT pour l’entreprise, les conflits entre CEO et CIO sont courus d’avance.

Une hausse modérée des dépenses attendue

Au cours du dernier trimestre 2012, Forrester a sondé près de 3800 CEO, CIO et collaborateurs IT dans le monde par rapport à leurs estimations quant au développement des dépenses IT de leur entreprise en 2013. En moyenne, les personnes interrogées tablent sur une augmentation d’environ 2%, sachant que les estimations varient fortement selon la situation géographique. Dans une Europe secouée par la crise, 30% des sondés s’attendent à ce que leurs dépenses IT baissent en 2013, contre 25% en Amérique du Nord et seulement 21% en Asie. De même, 39% des sondés européens estiment que leurs dépenses IT augmenteront en 2013, contre 44% en Amérique du Nord et 45% en Asie.
Les résultats de Forrester montrent clairement que les estimations en matière de dépenses IT varient en fonction de la situation conjoncturelle. Ce qui suggère que les budgets IT en temps de crise sont souvent sacrifiés sur l’autel des mesures d’économie, plutôt que d’être considérés comme des investissements visant à soutenir la productivité. Si l’on compare la croissance attendue de 2% des dépenses IT avec les 3,5% de croissance de la production prévus par le FMI pour l’année 2013, on voit que les dépenses IT envisagées sont plus basses à l’échelle mondiale. Selon Forrester, cette situation reflète l’intention des entreprises de réduire leurs coûts informatiques malgré des prévisions d’augmentation de la productivité – signe que les entreprises estiment peu la valeur de l’IT.

previousnext

• 1
• 2
• 3

Project Managers Have Process and People Responsibilities

A lire sur:  Method123

What does it take for the project to be a success? If the project has any kind of complexity you need a good project manager. To be successful, a project manager should have great skills for managing the project management processes, and for managing the people on the project.

The project management processes include:

• Planning, estimating and structuring the work and the project
• Building and managing a schedule to ensure work is identified, assigned and completed on time
• Estimating and managing the project budget
• Identifying, tracking, managing and resolving project issues
• Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management
• Proactively disseminating project information to all stakeholders
• Identifying, managing and mitigating project risk
• Ensuring that the solution is of acceptable quality
• Managing vendors to ensure all third-party work is completed within expectations
• Identifying and engaging project stakeholders

Remember, this does not mean that the project manager physically does all of the work, but he must make sure it happens. If the project has issues or scope creep, or faces risks, or if expectations are not set correctly, the project manager is the person held accountable.

To manage the project management processes, a person should be well-organized, have great follow-up skills, be process-oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager and have good self-discipline.

In addition to process skills, a project manager must have good people management skills. This includes:

• Having the discipline and management skills to make sure that everyone follows the agreed processes and procedures.
• Leading people so that they willingly follow your direction. This includes communicating a vision and getting the team to strive to get there.
• Setting reasonable, challenging and clear expectations for people and holding them accountable for meeting the expectations.
• Team-building skills so that the people work together well, and are motivated to work hard for the sake of the project and their other team members.
• Communicating proactively using good verbal and writing skills, and active-listening skills.

The project manager is responsible for managing the staff on the project. This is usually a shared responsibility with the team member's functional manager.

Ten Steps to Estimate Effort on your Project

A lire sur: Tenstep

Estimating is one of the most important parts of the planning process. Effort hours (man hours) must be estimated first, before duration and cost estimates can be prepared. Use the following ten steps to estimate effort hours.

1. Determine how accurate your estimate needs to be

Typically, the more accurate the estimate, the more detail you need to understand about the project, and perhaps the more time that is needed. If you are asked for a rough order of magnitude (ROM) estimate (-25% - +75%), you might be able to complete the work quickly, at a high level, and with a minimum amount of detail. On the other hand, if you must provide an accurate estimate within 10%, you need to spend more time and understand the work at a lower level of detail.

2. Create the initial estimate of effort hours

Estimate the work of the project using one or more estimating techniques (analogy, prior history, PERT, modeling, etc.). (These techniques will be described in a separate Tips email).

3. (optional) Factor the effort hours based on the resources assigned

Your estimates are probably based on the effort it will take an average resource to do the work (or perhaps the estimates are based on the effort it would take if you did the work). Sometimes you also have knowledge of the exact resource or the type of resource that will be assigned. If you do, you may want to factor the estimate up or down based on that resource.

4. Add specialist resource hours

Make sure you have included hours for part-time and specialty resources. This could include freelance people, training specialists, administrative help, etc. These are people that may not be obvious at first, but you may need them for special activities.  Because they are typically in project support roles, you may have forgotten to include their activities in the original Work Breakdown Structure.

5. (optional) Add rework time

In a perfect world, all project deliverables would be correct the first time. Rework is the result of flaws in your quality management process. It means that a deliverable that you thought was complete turns out to need more work. Some projects add in effort hours for rework, although this should be minimized.

6. Add project management time

Project management takes effort. A rule of thumb is to add 15% of the effort hours for project management. For instance, if a project estimate is 12,000 hours (7 - 8 people), then a full-time project manager (1800 hours) is needed.

7. Add contingency hours

Contingency is used to reflect the uncertainty or risk associated with the estimate. If you are asked to estimate work that is not well defined, you may add 50%, 75% or more to reflect the uncertainty. If the estimate was required on short notice, a large contingency may be required. Even if you have time to create a reasonably accurate estimate, your contingency may still be 10-25%. If you do not add a contingency amount, it would mean that you are 100% confident in your estimate. This may be the case if similar types of projects have been done before.

8. Calculate the total effort

Add up the estimates for all the work components described above.

9. Review and adjust as necessary

Sometimes when you add up all the components, the estimate seems obviously high or low. If your estimate does not look right, go back and make adjustments to your estimating assumptions to better reflect reality.

10. Document all assumptions

You will never know all the details of a project for certain. Therefore, it is important to document all the assumptions you are making along with the estimate.

IT : risques ou opportunités ?

A lire sur:  http://www.informatiquenews.fr/it-risques-opportunites-4805

le 10-10-2013, Par Guy Hervier

 

Si la majorité des entreprises considère la gestion des risques comme un objectif majeur, elles ont modifié leur approche ces trois dernières années, notamment en raison de la diffusion massive des nouvelles technologies.
La grande majorité des décideurs interrogés (81 %) considèrent que la gestion des risques constitue une haute priorité pour leurs entreprises, mais 94 % indiquent avoir changé d’approche ces trois dernières années. C’est ce qu’indique une enquête que vient de réaliser le cabinet Deloitte intitulée Exploring Strategic Risk: A global survey.  Les entreprises intègrent de plus en plus l’analyse des risques dans leur stratégie et leur planification des process. Et puisque la gestion des risques est un problème majeur, elle est prise en compte au plus haut niveau de l’entreprise c’est-à-dire au niveau de la direction générale dans deux cas sur trois. L’étude rappelle que les 4 catégories de risques sont : stratégiques, opérationnels, financiers et réglementaires.
Aujourd’hui, c’est la réputation de l’entreprise qui est considéré comme le risque le plus important (40 %) alors qu’il ne situait qu’en troisième position il y a seulement trois ans, derrière la marque et l’environnement économique. Cette montée rapide est certainement liée à la diffusion rapide des réseaux sociaux qui donne une voix à tout un chacun dont la caisse de résonance que constitue l’Internet et qui peut transformer en quelques heures une simple expression en véritables mouvements d’opinion devant lesquelles les entreprises sont quelque peu désarmés.  Mais cette situation semble transitoire puisqu’en 2016, ce risque rétrogradera en troisième position, les entreprises considèrent sans doute qu’elles reprendront la main.

Ces changements importants aussi rapides sont le résultat de l’explosion des données à laquelle on assiste ces dernières années ce que Tom Friedman du New York Times a baptisé de Great Inflection qui nous a amené dans une monde hyperconnecté où se mêlent diverses technologies : réseaux sociaux, cloud, 4G, haut débit sans fil, SOC (System-on-a-chip), smartphones, tablettes…  qui font désormais partie de notre quotidien. La gestion des risques nécessite plus que d’écouter les retours des clients. L’univers des médias traditionnels a littéralement explosé pour faire entrer les entreprises dans un espace multidimensionnel dans lequel aucune voix ne domine et où toutes les opinions comptent. Mais, si elles semblent démunies aujourd’hui,  elles considèrent qu’elles auront demain les outils à leurs dispositions pour écouter, canaliser et maîtriser ces vagues d’opinions.

Les technologies et le risque

Les technologies constituent-elles des opportunités ? Sans aucun doute, mais elles sont aussi des risques et ce à tous niveaux. Des entreprises peuvent être emportées rapidement par le tourbillon technologique. En quelques années, l’entreprise de location de DVD Blockbuster a été mise en faillite par la montée de la location en ligne. Créée 1997, Netflix avait mis en place un système de location de DVD par correspondance a du faire évoluer son business model à marche forcée pour tirer parti des réseaux haut débits et proposer un service de film en streaming. Ces évolutions liées aux ruptures technologiques ne sont pas nouvelles mais elles sont beaucoup plus rapides. Face à ce danger, l’Europe apparait comme la belle endormie et en prend moins la mesure que l’Asie ou l’Amérique.

Quelles sont les cinq technologies considérées comme un risque potentiel pour les entreprises pouvant menacer leur business model ? Réseaux sociaux, Analytics, applications mobiles, cloud et cybercriminalité sont cités par ordre décroissant. S’il semble étonnant que la cybercriminalité viennent en dernière position, cela n’est pas trop surprenant dans la mesure où elle est clairement identifiée comme un risque car elle n’est que cela alors que les quatre autre domaines sont neutres et peuvent avoir des effets positifs ou négatifs, tout dépend ce qu’en font les entreprises.  Une chose est sûre, l’avancée rapide des technologies entretient un climat d’incertitude dans lequel toute entreprise sait qu’elle peut être dépassée rapidement par un concurrent qui saurait mieux exploiter les innovations.  Le data mining vient en première position aux Etats-Unis dans la mesure où cette technologie est plus largement diffusée et utilisée qu’en Europe ou en Asie.

Six Steps to Create a Project Scorecard

A lire sur:  Method123

Project teams should know if they were successful or not. Sometimes there is a disagreement between the project team and the sponsor. This can always be the case when the criteria are subjective.

A better approach is to create a tactical project scorecard that lays out the metrics that validate project success. Then the discussion can become fact-based and not opinion. The six steps to create the project scorecard are as follows:

1. Identify criteria for success.
   
   Review the objectives and deliverables in the Project Charter, as well as any other existing information that is relevant to the project. Based on this existing documentation, define the information that is needed to show that the project was successful.
    
2. Assign potential metrics.
   
   Identify potential metrics for each success criterion that provide an indication of whether you are on-track for success. These can be direct, quantifiable metrics or indirect metrics that give a sense for success criteria.
    
3. Look for a balance.
   
   The potential list of metrics should be placed into categories to make sure that they provide a balanced view of the project. For instance, you do not want to end up with only a set of financial metrics, even though they might be easiest to obtain. In general, look for metrics that provide information in the areas such as:
    
   • Cost
   • Effort
   • Duration
   • Quality of deliverables
   • Client satisfaction with the deliverables produced
      
4. Prioritize the balanced list of metrics.
   
   Depending on how many metrics you have identified, prioritize the list to include only those that have the least cost to collect and provide the most value to the project.
    
5. Set targets.
   
   The raw metric may be of some interest, but the measure of success comes from comparing your actuals against a predefined target. The target provides the context to know if the current measurement value is good, bad or moving in the right direction.
    
6. Add schedule detail.
   
   For each metric that remains, determine the specific activities necessary to collect and analyze the information. These activities are then added to the project schedule. This information needs to include:
    
   • What specific data is needed for the metrics?
   • Who is responsible for collecting the metric?
   • When will the metric be collected and reported?
   • How will the metrics be reported (status reports, quarterly meetings, metrics reports)?

The project scorecard is updated throughout the project so the team knows how they are tracking against their success criteria. When the project is done you can have a fact-based discussion on project success instead of a discussion based on perception.

Seek Project Approvals from the Right People

A lire sur: Tenstep

Once the project has been defined, the project manager should seek formal approval from the sponsor and appropriate management stakeholders. There are many ways to gain formal project approval. A little bit of planning is the key. For small projects, one signature from the main client or project sponsor is probably sufficient to show approval of the work to begin. This approval could also be via email confirmation. However, it should not be verbal.

For larger projects, ask your manager and the project sponsor to identify who should have explicit approval of the Project Charter, who should have implicit approval and who needs to get a copy for informational purposes only. In general, use the following approach as your starting point:

• Project Sponsor. Get an explicit (proactive) approval. This approval can be a formal signature on a paper copy of the Project Charter. It could also be an email specifically stating approval. You might also have some type of formal workflow approval. The key is that the approval is explicit and that you save a record of the approval. The sponsor should have seen prior draft copies before you circulate the final version. This final approval should be a formality only. You don’t want to be in a position where you are trying to gain final approval and yet the sponsor has further concerns or questions.
• Other key management stakeholders. Get an implicit approval. Implicit means that you assume they approve the Project Charter unless they get back to you otherwise. You would first send them a soft or hard copy of the Project Charter. Let them know you would like them to review the material and provide feedback, especially if they have questions or concerns. Then give them a date for replying and let them know that if you do not hear back from them before the date you will assume they are granting their approval. If they come back to you with concerns, address them or take them to the project sponsor for resolution. It is important that these people have seen a prior draft and have a chance to provide input. When you are sending the Project Charter out for final approval, you want all concerns to have been expressed already. You don’t want to be dealing with problems, concerns or uncertainty while you are trying to gain final approval from the sponsor.
• Other interested parties. Send them a copy of the Project Charter. Let them know that it is for their information only. You should be available to discuss any content so that they can better understand the material, but you are not sending it to them for their approval. This may be the first time that these people have seen the Project Charter. However, you are not in a position to take requests to change the document since you probably already have sponsor approval. If there are any major concerns, the person with the concerns should take them directly to the sponsor.

Identifying these three levels of approval will ensure that the right people review the Charter, the right people approve the Charter, and the others have a copy for their information.

Tenstep N°189: Qu’est ce qu’un projet?

A lire sur:  Tenstep

Avant que vous puissiez être un bon « chef de projet » et appliquer les bonnes techniques de « management de projet », vous devez d’abord être sûr que le travail que vous êtes sur le point d’entreprendre est bel et bien un projet. Certains disent que tout travail est un projet, mais cela n’est pas tout à fait exact. Il existe en réalité de nombreux types de travail : la maintenance, aussi appelée le support, les opérations comptables, la gestion, les projets, etc.

·         Par le travail de maintenance, on maintient les solutions déjà existantes. Pour l’équipe de développement de solutions informatiques, le travail de maintenance consiste à répondre aux questions qui leur sont posées, à assister à des réunions régulièrement planifiées, à résoudre des problèmes dans les systèmes déjà en fonctionnement, etc. Pour le personnel chargé des ventes, cela peut consister à répondre aux questions des clients, modifier les contrats existants, rectifier les factures erronées des clients, etc.

·         Le travail d’opérations comptables est un travail régulier nécessaire au bon fonctionnement des affaires courantes. Pour un comptable, cela pourra consister à vérifier les rapports, équilibrer les comptes, assurer les écritures comptables, etc.

·         Le travail de gestion est requis pour gérer et diriger les personnes et les processus d’affaires.

Ces différentes catégories de travail représentent avant tout une part constante et habituelle de votre quotidien. C’est le travail que vous effectuez aujourd’hui, que vous effectuerez demain et dans un mois.

À l’inverse, les projets, quant à eux, ne sont pas routiniers. Ce qui différencie avant tout les projets des catégories de travail précédemment citées est d’avoir des dates de début et de fin bien définies. Il est un point dans le temps où le travail n’existe pas encore (avant le projet), un autre où il existe (le projet) et, enfin, un dernier où il n’existe plus (après le projet). C’est ce critère qui permet de déterminer si un travail est effectivement un projet ou non. Il existe plusieurs options pour déterminer les évènements marquant le début et la fin d'un projet. Ces évènements ainsi que la définition de la date de début et de fin varient d'une société à une autre.

Les autres caractéristiques d'un projet comprennent:

·         Tous les projets sont uniques. Même si un projet est semblable à un autre, il est tout de même unique en termes de cadre temporaire, de ressources, d'environnement du travail, etc.

·         Les projets aboutissent à la création d'un ou de plusieurs livrables.

·         Les projets disposent de ressources affectées - à plein temps, à temps partiel ou les deux à la fois. Cela est reflété par un budget déterminé ou un budget implicite basé sur les ressources affectées.

·         Les projets disposent d'un contenu de travail défini.

Ceci dit, il faut rester pratique. En théorie, des projets peuvent nécessiter une heure, 100 heures, ou 100.000 heures de travail. Ainsi, vous devez être conscient que bien que la réalisation d’un petit produit livrable soit un projet, celle-ci ne nécessite ni la structure ni la discipline dont on pourrait faire usage quand il s’agit d’un projet de plus grande envergure. Un projet d’une heure, vous le réalisez de la façon la plus simple. La planification, l’analyse et la conception sont élaborées dans votre tête. Pour un projet de vingt heures, vous opérez en général de la même façon. Cependant, vous devriez cette fois planifier un peu, peut-être communiquer un peu, et traiter quelques problèmes. Un projet de cent heures nécessite probablement déjà trop de travail pour ne pas songer à tout planifier et à tout gérer mentalement. Vous devriez, par exemple, commencer à définir le travail et à établir un échéancier du projet simple. Un projet de 5.000 heures nécessite toute une discipline de management de projet. À l’autre extrême, un projet de 100.000 heures nécessite probablement trop de travail pour que vous puissiez tout avoir en tête. Il vous faudra décomposer le grand projet en de plus petits projets ayant des liens entre eux, afin d’effectuer la totalité du travail.

Il y a des critères qui permettent de déterminer si un projet doit être considéré comme petit, moyen ou grand. N’oubliez pas que ce ne sont que des indications qui ont besoin d’être ajustées et validées par votre organisation.

Avant de suivre les différentes étapes de la méthodologie TenStep, assurez-vous que vous avez bien un projet et que vous choisissez la discipline et la rigueur qui seront à sa mesure.

Terminologie de management de projet

Sous-phase. Subdivision d'une phase.

Résultat. Donnée de sortie résultant de l'exécution de processus et d'activités de management du projet. Les résultats comprennent les aboutissements (systèmes intégrés, processus révisés, organisation restructurée, tests, personnel formé, etc.) et les documents (politique interne, plans, études, procédures, spécifications, rapports, etc.). Ne pas confondre avec un Produit. Voir aussi Livrable.

Abréviations courantes

RBS (anglais) : Resource Breakdown Structure

       (français) : Structure de découpage des ressources

Le DSI a du mal à vendre la valeur de l’IT

A lire sur:  http://www.informatiquenews.fr/dsi-du-mal-vendre-valeur-lit-4618

le 07-10-2013

Par Guy Hervier

Le rôle de la DSI dans la stratégie de l’entreprise a évolué mais les DSI n’ont sans doute pas pris toute la mesure de ce changement et continuent à parler informatique.
La vision qu’ont les DSI et les responsables métiers les uns sur les autres n’est pas vraiment conforme à la réalité. Une étude réalisée par le cabinet Forrester Research intitulée The Business Technology Value Scorecard révèle que les DSI ont toujours du mal à communiquer sur la réelle valeur que l’IT apporte au fonctionnement et au développement de l’entreprise. Une des raisons est que, trop souvent, les indicateurs utilisées pour mesurer les performances de l’IT restent trop orientées « transactions » selon le modèle que l’on a connu dans les années 80/90 alors qu’il faudrait adopter un modèle résolument orienté « business », en particulier pour apprécier la capacité de la DSI a répondre, voir anticiper, les changements qui interviennent régulièrement.
Dialogue de sourds ?
Et la remarque triviale « c’est la faute à l’informatique » reste dans les esprits de manière diffuse mais persistante. Les utilisateurs prennent pour argent comptant ce qui fonctionne et ne « voient » l’informatique qu’en cas de dysfonctionnement ou de pannes. Le trait est un peu forcé mais à peine. Selon l’enquête, là où deux DSI sur trois pensent que l’informatique est un accélérateur de business alors que, de leur côté, la moitié des responsables métier considère que l’informatique entrave la réussite de l’entreprise.
Au niveau des coûts, la perception des métiers n’est pas conforme à la réalité. En moyenne, les directions fonctionnelles estiment que les dépenses informatiques représentent 8 % du chiffre d’affaires alors qu’ils n’en consomment en réalité que 5 % (toujours en moyenne).
Cela n’est pas vraiment nouveau, mais semble de perpétuer : les deux-tiers de budgets informatiques sont consacré à l’exploitation et à la maintenance des applications. Ce qui a deux conséquences. D’abord, de maintenir une vision très informatique et « transactionnelle » de leur activité. Et pourtant, selon Forrester, les nouvelles technologies – cloud, SaaS… – leur permettrait de consacrer plus de ressources aux systèmes de gestion de relation clients par exemple ou permettant de mettre en place de nouveau modèle de travail collaboratif. Ensuite, cela a tendance à détourner leur attention des nouveaux projets à mettre en œuvre.

Sur trois grands chapitres, les DSI ne semblent pas remplir leur mission complètement. Les directeurs financiers se désolent qu’ils ne reçoivent que la moitié des informations de la DSI et donc doivent se débrouiller pour les 50 % restants. Confrontés aux réalités quotidiennes, parfois dures et contribuant à remplir leur tâche ingrate, les directions fonctionnelles considèrent que les systèmes existants sont fiables mais qu’ils n’offrent pas la flexibilité qu’ils jugent nécessaires à la conduite de leur activité. A commencer par des choses qui leur paraissent très simples comme la possibilité de pouvoir utiliser le terminal de leur choix. Le phénomène BYOD a du mal s’implanter en France. Le troisième point concerne la difficulté qu’auraient les DSI à prendre en prendre en compte les besoins et les attentes des clients. Le modèle dit three-tiered selon lequel la DSI répond aux besoins des utilisateurs internes qui soutiennent à leur tour les clients a vécu. Maintenant, les nouveaux canaux permettent de construire une relation nouvelle et beaucoup plus directe avec les clients. Ce que les responsables marketing appellent la vision 360° du client.
Face à cette nouvelle réalité, Forrester conseille aux DSI de mettre en place un nouveau modèle d’évaluation de leurs performances incluant des indicateurs plus pertinents organisé en quatre grandes catégories :
- Health : pour mesurer les performances de systèmes existants et leur adéquation avec la stratégie de l’entreprise ;
- Delivery : sans doute la catégorie la plus familière aux DSI, qui correspond à sa capacité à fournir les bonnes applications avec des métriques mesurant le fonctionnement du help, desk, des études, la satisfaction client ;
- Outcome : inclut des indicateurs qui mesure le lien entre les dépenses et les résultats métier ;
- Agility : l’agilité est pour Forrester ce qui garantit le plus la réussite d’une entreprise à long terme.

Les DSI bientôt sous l'autorité des directeurs marketing ?

A lire sur:  http://www.lemondeinformatique.fr/actualites/lire-les-dsi-bientot-sous-l-autorite-des-directeurs-marketing-55278.html

Le 08 Octobre 2013

Avec la révolution numérique en cours dans les entreprises, le rôle traditionnel des DSI - déjà mis à mal par l'externalisation - connait un nouveau coup de boutoir avec la montée en puissance des métiers sur les questions informatique. Le CMO (Chief Marketing Officer) devient aujourd'hui le principal concurrent du CIO et demain peut-être son supérieur hiérarchique et budgétaire.

Dans les années qui viennent, de nombreux DSI vont réaliser qu'ils travaillent pour le directeur du marketing, et leurs services informatiques ne seront guère plus qu'un pôle technologique du département marketing. Tel est le point de vue de Larry Weber, président de la société de services marketing W2 Group, fondateur du cabinet de relations publiques Weber Group, et par ailleurs conférencier et auteur réputé. « Il restera encore toutes les tâches ennuyeuses traditionnelles de l'informatique, si bien que les DSI auront encore du travail », a expliqué Larry Weber. « Mais à long terme, je pense que le DSI aura une fonction moins importante que celle du directeur marketing, quel que soit le titre qu'on donnera plus tard à ce directeur », a-t-il ajouté. Selon lui, la principale tâche du DSI sera d'aider le directeur marketing à sélectionner les meilleurs logiciels et plates-formes d'automatisation marketing et de les intégrer avec d'autres systèmes d'entreprise.

« Virage culturel »

« Ce type de coopération sera sûrement différent du mode de fonctionnement très indépendant qui a dominé par le passé », a-t-il déclaré. « C'est un vrai changement culturel, parce que traditionnellement le département IT est physiquement loin du département marketing, le code vestimentaire des personnels est différent, et il n'y a pas de communication entre les personnels de l'IT et du marketing. Or c'est ainsi que le DSI va devoir évoluer. Il y a entre eux un conflit inhérent qui nécessitera l'arbitrage du PDG. Mais je pense que dans la plupart des cas, celui-ci se rangera du côté du marketing », a-t-il encore ajouté.

Le moteur de ce changement, c'est que la publicité traditionnelle a été remplacée par les médias sociaux, le big data et le décisionnel et que ces outils sont justement ceux que les entreprises utiliseront pour atteindre leurs clients et pour leur offrir la meilleure expérience possible. « Aujourd'hui, le département marketing est tributaire de la technologie et le directeur marketing doit demander de l'aide pour disposer du bon logiciel, sans toutefois s'impliquer dans la technologie et pour juste avoir quelque chose qui fonctionne », poursuit Larry Weber.

DSI-Directeur marketing : vers une extension des compétences

« Mais le DSI ne sera pas le seul à devoir s'adapter », a modéré le PDG de W2 Group. Selon lui, le directeur marketing va également devoir évoluer et se préparer à ce nouveau monde du marketing technologique. « Il faudra à la fois des directeurs marketing avec davantage de compétences techniques et des DSI plus avisés en matière de marketing ». Si bien que d'ici cinq ans, les deux domaines seront moins éloignés l'un de l'autre et les fonctions auront évolué vers des postes de « vice-président technologie data ou VP content », de « vice-président médias sociaux ou VP Social Media » et « vice-président expérience client ou VP customer experience » comme le suggère Larry Weber. Mais même, si comme le prédit le CEO de W2 Group, le rôle du DSI est réduit à celui de conseiller en technologie pour le département marketing, il restera encore beaucoup de « tâches ennuyeuses traditionnelles ». Cela inclut de nombreuses considérations IT, comme la sécurité et la conformité, dont les conséquences sont vitales pour l'entreprise.

DSI-Directeur marketing : un conflit inévitable

Dans cette perspective, les conflits entre le DSI et le directeur marketing sont inévitables. Par exemple, que se passera-t-il si le directeur marketing décide que l'entreprise a besoin de tel logiciel SaaS particulier et que le DSI s'y oppose catégoriquement en invoquant des conséquences très importantes au cas où les questions de sécurité ou de conformité seraient ignorées. « Il y a forcément un conflit inhérent, et c'est là que le PDG devra intervenir », a déclaré Larry Weber ajoutant : « Mais, dans la plupart des cas, je pense que celui-ci se rangera à l'avis des responsables du marketing ». Cependant, une politique qui ne tiendrait pas compte des problèmes de sécurité ou de conformité que sont tenus de résoudre le DSI peut exposer l'entreprise à de graves conséquences juridiques. L'expérience client n'en sera pas améliorée non plus si les données personnelles ne sont pas protégées de manière adéquate.

Pour cette raison, il est peu probable que les directeurs marketing soient encouragés à ignorer complètement les contraintes de la DSI. Cependant, Kathleen Schaub, vice-présidente services et conseils d'IDC, s'accorde à dire comme Larry Weber que dans la plupart des entreprises, le directeur du marketing aura plus de poids auprès du PDG que le DSI. « Le PDG doit reconnaître la relation direction marketing/DSI, mais il donnera plus de poids à la direction marketing dans la stratégie de l'entreprise », a également affirmé Kathleen Schaub.

Le budget IT en question

Un autre domaine potentiel de conflit est la question des budgets informatiques, plus précisément quel département devra payer pour les activités IT du département marketing. Certaines dépenses - comme les produits SaaS dédiés au marketing - peuvent naturellement tomber dans la catégorie des dépenses marketing, mais qu'en sera-t-il des unités de stockage et de calcul nécessaires à l'analyse des big data ? Est-ce que cela dépend de l'IT ou du marketing, et sur quel budget faudra-t-il les imputer ?

Les chiffres d'IDC montrent qu'environ deux tiers des dépenses technologiques des départements marketing sont déjà payés sur le budget marketing et non sur celui de l'IT, et celles-ci augmentent fortement chaque année. « Les dépenses pour l'automatisation du marketing ont augmenté régulièrement depuis les années 1990 pour atteindre aujourd'hui un niveau extrême », a déclaré Kathleen Schaub. Cela laisse entendre que - indépendamment du fait que les dépenses IT ont globalement augmenté - le département marketing aura à l'avenir une plus grande part du budget sous son contrôle.

Réunir les fonctions de DSI et de directeur marketing ?

En dépit de tout ce qui précède, Kathleen Schaub estime que le conflit entre la direction marketing et la DSI peut être évité de différentes manières. « Une approche consiste à essayer de s'assurer qu'il y a une relation forte entre le DSI et le directeur marketing. Certes ce n'est pas toujours possible, et il faut trouver les bonnes personnalités », a-t-elle déclaré. Mais il y a d'autres solutions, comme celle expérimentée avec succès par des entreprises comme Motorola Solutions. « La réponse est peut-être, tout simplement, de faire en sorte que le DSI et le directeur marketing soient une seule et même personne », a-t-elle préconisé.

Article de Paul Rubens CIO/IDG, adaptation Jean Elyan

La souveraineté des données : une priorité de l’agenda des DSI !

A lire sur:  http://www.infodsi.com/articles/143875/souverainete-donnees-priorite-agenda-dsi.html

mardi 8 octobre 2013

Les révélations concernant la surveillance des données par les états, en particulier les Etats-Unis d’Amérique ont mis en haut de l’agenda des DSI la question de la souveraineté des données – c’est-à-dire de connaître la localisation physique des donnés. Pour NTT Communications, Len Padilla, Directeur de la Stratégie Produit en Europe (ci-contre) et Sylvain Defix, Senior Consultant chez NTT Com Security, nous donnent leurs opinions et offrent quelques observations.


Un nombre croissant de DSI et de services informatiques se tournent vers le cloud espérant qu'il les aidera à acquérir un avantage concurrentiel pour leur entreprise, réduire les coûts et faire plus avec moins. Près des trois quarts des DSI interrogés en mai ont convenu qu'ils utilisaient déjà du cloud. Selon l’étude menée par NTT, un des principaux avantages est de fournir un véritable accès universel (de n’importe où, à partir de n’importe quel appareil) aux données de l’entreprises au travers d’applications métiers. C'est en effet le plus grand avantage du cloud par rapport à l'infrastructure informatique maison ; mais c’est aussi sa plus grande faiblesse, comme les événements récents l’ont mis en évidence.

En effet, note NTT, les révélations faites par Edward Snowden sur le programme de surveillance « PRISM » du gouvernement américain, ont incité de nombreuses entreprises à repenser leurs investissements dans le cloud. Parmi toutes ses allégations, Snowden affirme que les entreprises technologiques américaines étaient de connivence avec le gouvernement US pour fournir un accès sur demande aux données détenues dans leurs systèmes. De nombreux fournisseurs l’ont nié, mais le mal a été fait. Ainsi, tout d'un coup, la souveraineté des données – c’est-à-dire le lieu physique où les données sont stockées et la nature des organisations qui les stocke – devient cruciale pour les DSI. Avoir ses données dans des data center d’un pays, où les autorités peuvent y accéder ou les contrôler, sans même un consentement, constitue un risque commercial important. La possibilité de choisir l'endroit où les données se trouvent, et même de les transférer d'un pays à un autre, à volonté, est désormais une préoccupation majeure.

Les décideurs politiques en Europe ont prêté leur voix à cette préoccupation. Ainsi, le ministre allemand de l'Intérieur, Hans -Peter Friedrich, a dit : « Quiconque craint que ses communications ne soient interceptées, doit alors utiliser des services de cloud qui ne passent pas par les serveurs américains. » Fleur Pellerin, Ministre déléguée à l’économie numérique au sein du gouvernement français, prend acte : « Nous prenons aujourd’hui conscience, peut-être un peu tard, de la nécessité à être moins dépendants des infrastructures, des plates-formes ou des points d’accès à Internet autres qu’européens. La nécessité d’avoir un cloud souverain se pose avec une grande acuité. »

Ces propos ont atteint durement les fournisseurs de cloud américains– de 21 à 35 milliards de dollars de pertes prévues, selon la fondation ITIF (selon le rapport d’août 2013). Bien sûr, toute personne, qui externalise des données à un tiers, doit accepter de perdre le contrôle total sur ses données et dans le même temps de faire confiance à l’opérateur choisi. Mais la question ici est de savoir si la confiance accordée au fournisseur doit s’étendre au gouvernement dont il dépend.

Cependant, le seul choix de localisation des données et des applications – dans le cloud ou chez soi – n’est pas la réponse au problème, met en garde NTT. En effet, les plateformes de cloud aident les entreprises à devenir plus agiles et à stimuler l’innovation technologique, mêmes chez les entreprises les plus frileuses. Aussi, les DSI doivent trouver un chemin pour bénéficier des avantages du cloud, tout en protégeant – sans aucun compromis - leur entreprise et ses données.

Tout d’abord, scruter les réseaux internationaux et les data center des fournisseurs de cloud ainsi que les implantations de leurs sièges sociaux est la première étape, cruciale. Puis, la seconde étape, tout aussi importante, est de vérifier s’il est possible pour un client de déplacer les données à sa demande – pour accompagner l’implantation de nouvelles filiales dans un pays, par exemple. Or, ceci est très difficile techniquement, car l'ensemble du réseau, des serveurs et de l'infrastructure de stockage doivent être virtualisés et automatisés. Fournir des services de cloud computing aux entreprises dans le monde entier sans toucher à aucune infrastructure américaine s’avère être encore plus compliqué. L'acheminement des données transitant par Internet est automatisé, il n'y a donc aucun moyen de prédire quel chemin vont prendre les données et de savoir si elles vont traverser les Etats-Unis ?

Alors, comment cela affecte le « CLOUD » ? Fini le temps, où vous pouviez visiter un data center et vous faire pointer du doigt LE serveur, où vos informations étaient stockées. Toutefois, la souplesse du cloud permet aux données d'être placées là où le fournisseur veut les mettre, par exemple, en se limitant à un pays (ou plusieurs) ou à un data center (ou plusieurs) ou même à un ensemble de serveurs dans un data center. Mais là où les données sont stockées, les fournisseurs ne donneront sans doute pas les droits d'auditer par soi-même la sécurité mise en place.

Par conséquent, lorsque vous choisissez un fournisseur de cloud, lorsque vous sélectionnez les applications à déplacer vers le cloud, vous devez sérieusement envisager les questions suivantes:

-Votre fournisseur de cloud est-il assujetti au Patriot Act ?

-Est-ce que votre fournisseur possède de bonnes références en matière de sécurité ?

-La solution de votre fournisseur permet-elle de s’inscrire dans votre stratégie d’entreprise de gestion de risque ?

-Pouvez-vous faire le choix de l’implantation géographique des données avec votre fournisseur ?

-Est-ce que votre fournisseur vous permet de l’auditer ?

-Est-ce que votre fournisseur vous garantit qu’à votre demande les données seront réellement et non pas logiquement détruites ?

-Est-ce que votre fournisseur de cloud a l’expérience de la gestion de données sensibles, telles que les données bancaires ?


L'appel du cloud a été entendu par les DSI, qui ont été séduits par ses promesses de plus grande flexibilité et de meilleure maîtrise des coûts. Bien que le cloud ne soit pas une garantie contre les activités d’espionnage et contre l’interception de communications, il permet une flexibilité et un niveau de sécurité, nécessaires aux entreprises qui font face à une expansion internationale.

Et Len Padilla d'ajouter : « « Quel dommage que ce soient des organisations de sécurité nationale d’un pays qui jettent le discrédit sur le cloud, discrédit dont il faudra se défaire ! Nous espérons que l'affaire PRISM se révèlera être juste un ralentissement temporaire du mouvement d’adoption massif du cloud computing par le marché. Pour l'instant, les DSI doivent mesurer leurs décisions d’aller vers le cloud computing, à l’aune de la souveraineté des données. »

Sylvain Defix précise que l’actualité récente montre qu’il faut bien peser d’un point de vue métier les risques d’introduction du modèle cloud avec les risques de ne pas s’y engager, sur la base d’une gestion du risque éclairée. « Transparence dans la localisation des données et des équipes opérationnelles, clarification des périmètres de certification chez le fournisseur de cloud sont des exigences essentielles, auxquelles j’ajouterai la lisibilité et la flexibilité des services de sécurité associés telle que l’offre de sécurité managée WideAngle MSS, pour laquelle nous avons développé un moteur SIEM de nouvelle génération. »

Source: infoDSI.com

Leçon n° 15 : comprendre la différence entre PCA et PRA

A lire sur:  http://www.solutionitpme.fr/2013/10/04/lecon-n-15-comprendre-la-difference-entre-pca-et-pra-2403

Publié le 04/10/2013 dans Protection de données | 

Rares sont aujourd’hui les entreprises qui peuvent se passer de leur informatique à tel point que dans bien des cas l’inaptitude à faire face à un incident informatique peut leur être fatale. Selon une étude du cabinet de conseil américain Eagle Rock, 40% des entreprises ayant subi un arrêt de 72 heures de leurs moyens informatiques et télécoms ne survivent pas à ce désastre C’est la raison pour laquelle de plus en plus de sociétés, de toutes tailles s’attachent à mettre en place un plan de reprise d’activité ou un plan de continuité d’activité.
Au fil du temps, la signification de ces deux termes a évolué. Historiquement, le plan de continuité s’attachait à analyser l’impact potentiel d’un désastre ou d’une défaillance sur le métier de l’entreprise et à définir les moyens et procédures à mettre en place pour en limiter les conséquences. Le plan de reprise d’activité s’intéressait quant à lui aux aspects informatiques du PCA.
Pour les informaticiens, la terminologie a évolué : de plus en plus le PCA décrit l’ensemble des moyens destinés à assurer la continuité d’activité des applications, c’est-à-dire à garantir la haute disponibilité de ces applications (ce qui implique l’impossibilité d’un arrêt de ces applications même en cas de sinistre sur un site). Le PRA quant à lui décrit l’ensemble des moyens et procédures destiné à assurer une reprise rapide et ordonnée de la production après un arrêt inopiné (lié par exemple à une défaillance technique, ou énergétique, à une erreur humaine ou à un sinistre naturel). La différence entre les deux approches tend donc à se limiter à une différence en matière de temps d’indisponibilité de l’infrastructure et des applications en cas de sinistre.
PCA : objectif haute disponibilité
Dans le cadre d’un PCA, l’entreprise veille à définir les architectures, les moyens et les procédures nécessaires pour assurer une haute disponibilité des infrastructures (datacenter, serveurs, réseau, stockage) supportant l’exécution des applications de l’entreprise. L’objectif est d’assurer que quelle que soit la situation, les infrastructures mises en place garantissent aux utilisateurs un service ininterrompu.
En général, la mise en œuvre d’un PCA suppose la mise en place d’équipements redondés entre plusieurs datacenters et fonctionnant de façon conjointe de telle sorte qu’en cas de défaillance d’un élément sur le site primaire, le relais soit automatiquement pris par le site secondaire.
Typiquement, une telle architecture suppose la mise en place d’un dispositif garantissant la cohérence des données sur les baies de stockage entre le site primaire et le site secondaire, comme la solution VPLEX d’EMC qui assure la réplication transparente des données entre deux sites ainsi que la bascule automatisée des applications d’un datacenter à l’autre en cas de défaillance sur le site primaire.
Il est à noter que toutes les applications de l’entreprise ne sont pas forcément concernées par la mise en œuvre d’un PCA, simplement parce que certaines ne sont pas jugées critiques et peuvent tolérer un arrêt, ou une éventuelle perte de données. Cette criticité est à définir avec les métiers de façon à définir quel sera le périmètre du PCA et quelles applications seront concernées par un « simple PRA ». Il convient aussi de dimensionner convenablement les infrastructures pour que la bascule vers le site secondaire n’affecte pas trop les performances. Dans le cas d’une architecture en mode actif/actif, la production est en effet répartie entre les deux datacenters de l’entreprise, ce qui fait qu’un sinistre sur l’un d’entre eux se traduit mécaniquement par une diminution de moitié de la capacité de traitement disponible, donc potentiellement par une dégradation des performances sur l’infrastructure survivante.
PRA : Assurer le redémarrage ordonné en cas de défaillance
Pour les entreprises qui n’ont pas les moyens ou le besoin d’un PCA, le PRA est la solution pour assurer un redémarrage ordonné et aussi rapide que possible de l’infrastructure informatique de l’entreprise en cas d’incident. Ce redémarrage s’effectue en général sur un site de secours, propriété de l’entreprise ou fourni par un prestataire tiers. Le PRA définit les architectures, les moyens et les procédures nécessaires à mettre en œuvre pour assurer la protection des applications qu’il couvre. Son objectif est de minimiser l’impact d’un sinistre sur l’activité de l’entreprise. On distingue plusieurs modes de redémarrage : le redémarrage à chaud s’appuie sur une copie synchrone ou asynchrone des données du site principal. Il s’agit de s’appuyer sur le dernier état cohérent connu des données comme base pour les serveurs positionnés sur le site de secours. La réplication des données (qui peut être assurée par une technologie comme RecoverPoint chez EMC) assure un redémarrage rapide des serveurs de secours dans un état aussi proche que possible de celui qui a précédé le sinistre. Le RTO (Recovery Time Objective – le temps nécessaire pour remettre l’application en production – est donc minimal et le RPO (Recovery Point Objective – le temps entre le dernier état cohérent des données et le sinistre) réduit à son minimum, souvent quelques minutes.
La situation est un peu différente en cas de secours à froid. Cette situation concerne encore nombre d’entreprises ne disposant pas des moyens financiers et/ou technique pour un PCA ou pour une reprise à chaud. Dans ce cas, le redémarrage après sinistre s’appuie sur les dernières sauvegardes réalisées par l’entreprise. Ces sauvegardes peuvent dans le meilleur des cas être des répliques provenant d’un système de sauvegarde dédupliqué sur disques comme une baie Data Domain ou dans le pire scénario, une simple sauvegarde sur bande.
En cas de sinistre, l’entreprise doit donc activer son site de secours, restaurer ex-nihilo ses données depuis leur support de sauvegarde (disque ou bande) et remettre en service ses applications. Il s’agit là de la solution la plus économique pour mettre en place un PRA, mais elle a un prix en matière de RTO et de RPO. Le RTO est au minimum le temps de restauration des données et de mise en service des serveurs, ce qui pour des environnements complexes peut vouloir dire plusieurs heures voire plusieurs jours. La bonne nouvelle est que la banalisation des solutions de sauvegarde sur disque comme Data Domain a largement permis de réduire le RTO (de 17 heures à 2 heures en moyenne selon une étude IDC de 2012).
Le RPO dépend de la fréquence des sauvegardes. Dans le pire des cas, il peut atteindre un ou plusieurs jours (notamment pour les applications dont les fenêtres de sauvegarde sont longues et qui ne sont sauvegardées qu’une fois par jour, voire moins). Là encore la sauvegarde sur disques dédupliquée a amélioré la situation en réduisant les fenêtres de sauvegarde (de 11 heures avec une librairie de bandes à 3 heures en moyenne avec systèmes comme Avamar ou Data Domain).
Il est à noter que le redémarrage à froid était la règle pour nombre de PME il y a encore 5 ans. Mais la généralisation de la virtualisation et du stockage en réseau a rendu accessible le redémarrage à chaud à un nombre croissant de société. Le PCA n’est pas encore forcément à portée de tous mais il est désormais accessible à nombre de PME de taille intermédiaire. Les progrès accomplis par les baies de stockage, les solutions de sauvegarde sur disque et les technologies de virtualisation devraient le rendre accessible au plus grand nombre au cours des prochaines années.

5 Tips For Faster Project Scheduling

A lire sur:  ProjectManager.com

Producing a project schedule can be a time-consuming and difficult task. However, without a schedule, your project won't be successful. So how can you get started more quickly?

Here are our top 5 tips for producing your project schedule faster.

Tip 1: Use templates
The fastest way to build your project schedule is to use a template. This is a sample, blank project schedule that you can edit to make it suitable for your current project. For example, you can use a template for a web project to get started if you are also managing a web project. This would include several of the key activities such as website design and testing. You could then add any additional tasks that are specific to your project. If you do use a templates, don't forget to delete any tasks that are not relevant to your project.

Your Project Management Office or your software tool may have a range of templates that you can customize for your projects.

Tip 2: Use task lists
If you have to build your project schedule from scratch, the best way to start is with a task list. Use the comprehensive task management tools in ProjectManager.com to list all the tasks for your project. You can even import task lists from other applications, which is useful if you have already started planning your project in a workshop or meeting.

Remember to include all the tasks that you need to do to deliver the project, such as designing, building and testing deliverables as well as the tasks required to run the project, such as team meetings, the work required to produce documents and governance activities.

Tip 3: Allocate resources
Get your team working faster by using your project management tools to allocate tasks to them. You'll avoid the need for lengthy meetings as they can pick up their assignments online, whenever is convenient for them.

If you don't know who should be working on which task, discuss it at a team meeting. Sometimes there will only be one suitable person, and sometimes you may have to ask for a volunteer! In the meantime, you can delegate the rest of the work to the team. Then they can get started on their activities and you won't hold up any other project work.

Tip 4: Structure your schedule
Group similar tasks together to create workstreams. You can also build project phases by looking at where it is logical to split the work into time bound chunks. Add milestones to mark the end of significant elements of work. If your schedule is structured effectively, it will be much easier to use. As a result, you will spend less time producing it in the first place and less time keeping it up to date as the project progresses.

Tip 5: Track it regularly
One of the reasons that project scheduling can be so time-consuming is that project managers let their schedules get out of date. Updating a project schedule that reflects what happened several weeks ago can be a challenge, especially on projects that move quickly. It is much better to put aside some time each week to update your plan. You can keep on top of changes and make sure that your project team always has the correct view of current progress. Other project stakeholders will also find this useful.

Are CIOs Destined to Work for the CMO?

A lire sur:  http://www.cio.com/article/741084/Are_CIOs_Destined_to_Work_for_the_CMO_

As marketing departments become more reliant on technology, a strong relationship with the CMO will be necessary for the survival of CIOs. In fact, don't be surprised to see CIOs playing a supporting role in the enterprise.

By Paul Rubens , Mon, October 07, 2013

inShare148

CIO — Within the next few years many CIOs will find that effectively they work for their chief marketing officer (CMO), and their IT department will have become little more than the technology arm of the marketing department.

That's the view of Larry Weber, chairman and CEO of the W2 Group (a marketing services company), founder of The Weber Group public relations company, and a noted speaker and author.
"There will still be all the traditional boring stuff of IT, so the CIO will still have a job," says Weber. "But ultimately I don't see the CIO long term being as important as the CMO -- or whatever the CMO is called in the future," he adds.
Weber says that one of the CIO's key jobs will be to help the CMO select the best marketing automation platforms and software and integrate them with other corporate systems.

'Cultural Shift' in Tech

CIOs will find this type of co-operation different from the independent way that they have operated in the past, he says.
"This is quite a cultural shift, because traditionally the IT department is physically far from the marketing department, the IT staff dress differently to marketing staff, and there is no communication between technology people and marketing people. But that is how the CIO is going to have to evolve. "

"There is bound to be inherent conflict, and that's where the CEO comes in,. But I think that, in most cases, he will side with the marketing people."

-- Larry Weber, chairman and CEO of the W2 Group

What's driving the change is that instead of traditional advertising, it's social media, big data and analytics that will be the key tools that marketers use to reach customers and give them the best experience possible.
"So now the marketing department is reliant on technology, and the CMO has to say 'help me out here. We need to get together to get the right software. I don't want to learn technology, I just need it to work,'" Weber says.

CIOs Need to Get Marketing Savvy

It's not only the CIO who will have to learn to adapt, Weber says: The CMO will also have to change to prepare for his brave new world of technology driven marketing. "What we will need is more tech savvy CMOs and more marketing savvy CIOs."
That means that within five years the two roles will have blurred and become less distinct and there will be new roles with new titles as well: "Communities Manager," "VP of Content," "VP of Social Media" and "VP of Customer Experience" are a few that Weber suggests.
But despite Weber's prediction that the CIO's role will be reduced to that of technology advisor to the marketing department, there will still be plenty of what he referred to earlier as "the traditional boring stuff." And that includes many IT considerations that have vital consequences for the business, such as security and compliance.

CIO-CMO Conflict Inevitable

That means that there will almost inevitably be conflict between the CIO and the CMO. For example, what will happen when the CMO decides that the business needs to use a particular software as a service (SaaS) product, but the CIO tries to veto it for data security or compliance reasons that could have very significant implications for the business if ignored.

Continue Reading

1 2 next page »

Le DSI peut-il devenir le directeur du numérique ?

A lire sur:  http://www.informatiquenews.fr/dsi-il-devenir-directeur-du-numerique-4571

le 04-10-2013, Par Guy Hervier

 

Les entreprises vivent la révolution du numérique. Les DSI en seront-ils les premiers artisans ou faudra-t-il créer de nouveaux postes ?
En avril dernier, Syntec Numérique officialisait le changement de non des SSII en Entreprise de services numérique. Cette modification n’est pas un simple changement d’appellation mais traduit une évolution de fond. Le numérique a conquis progressivement des pans entiers de la vie économique, et les entreprises de services associées ont profondément modifié leurs structures, leurs business models…
De même, le Cigref a changé de fond en comble son cadre de réflexion pour l’organiser complètement autour du numérique. D’ailleurs, la base line du réseau des grandes entreprises n’est-elle pas de « Promouvoir la culture numérique comme source d’innovation et de performance ». La politique, elle aussi, a pris la mesure du changement en ajoutant le vocable Economie Numérique au descriptif du ministère des PME et de l’innovation. Car le flux des données nés va s’abattre sur les entreprises et celles qui sauront en tirer parti prendront un avantage concurrentiel sur les autres. Selon le cabinet IDC, le volume des données disponibles va être multiplié d’un facteur 300 entre 2005 et 2020. Actuellement, 1 % seulement des données sont exploitées.
Comment les entreprises prennent-elles en compte cette tendance de fond ? Les DSI seront-ils les responsables de l’accompagnement vers le numérique ou faudra-t-il créer un nouveau poste ? Aux Etats-Unis dont on dit couramment qu’ils ont deux ou trois ans d’avance en matière d’IT, les entreprises commencent à embaucher un Chief Data Officer (Directeur du numérique ?), à commencer par la Banque centrale (Federal Reserve) mais aussi de nombreuses agences gouvernementales américaines. Il est vrai que peu d’institutions sont autant dépendantes des données  que la Fed pour prendre une décision apparemment simple mais dont les conséquences sont considérables. La Fed a s’est donné comme objectif de « redesign[ing] data governance and management processes to enhance the board’s data environment » comme l’un des six axes stratégiques d’ici à 2015.
Né dans les années 80, les DSI a été chargé de mettre en place des systèmes informatiques (conceptualisés sous le terme de systèmes d’information). Aujourd’hui, les entreprises créent des postes de CDO pour porter les projets numériques, explique le cabinet de recrutement DHR International dans un livre blanc intitulé Emergence of the Chief Data Officer.  Cette fonction nécessite des compétences très pointues dans de nombreux domaines : statistiques et méthodes mathématiques, informatiques notamment dans les logiciels spécialisés pour le big data et aussi métiers.
Le cabinet DRH se livre à une quasi description de poste. Le CDO devra posséder les qualifications suivantes :
- Expérience dans les solutions de big data incluant Hadoop et HBase ;
- Connaissance dans la collecte des données, leurs classement, leur stockage, l’architecture des solutions de data warehouse, et les très grand bases de données
- Compréhension des techniques de modélisation ;
- familiarité avec le monde des affaires et les méthodes de recherche académiques ;
- Connaissance des solutions existantes de big data et de leur implémentation  dans les langages de programmation et les modèles de conception ;
- Capacité à former des équipes à la résolution de problèmes d’entreprise.

On le comprend, au vu de cette description, rares seront les DSI capables d’assumer pleinement cette nouvelle fonction et le nombre de candidats potentiels n’est sans doute pas considérable. Avant même de créer un poste et d’embaucher, l’entreprise devra répondre à cinq questions, explique le livre blanc :
- Quels sont les objectifs assignés au programme big data ?
- Quelles seront les responsabilités de la fonction de CDO ?
- Quelles compétences et quelle expérience devra posséder le CDO ?
- Où trouve-t-on les data scientists ?
- Comment le CDO crée de la valeur et la transforme en revenu supplémentaire ?
Et sur ce dernier point, la tâche du CDO est plutôt large et couvre quatre grands domaines, explique Partha Saha, Chief Data Architect for Data and Analytics dans la division Online Services chez Microsoft :
- Observer les tendances et les événements et les analyser pour agir avant qu’ils se répètent ;
- Faire le lien entre les données internes et celles disponibles pour créer des modèles complets ;
- Aider les métiers avec des innovations basées sur l’analyse des données pour engager une relation one to one avec les clients selon les différents canaux disponibles ;
- Tirer parti des innovations qui se font jour sur Internet incluant des nouvelles méthodes marketing, des campagnes s’appuyant sur les réseaux sociaux…
Plus généralement, le futur CDO devra donner aux entreprises une culture orientée numérique dont elles sont le plus souvent dépourvues, poursuit Partha Saha. Il définit cette culture par la capacité à poser une question pertinente au regard de l’activité, à développer des hypothèses et à les tester sur les données existantes.  La situation est souvent bien différente : les managers se sont forgé des opinions basées sur leurs propres observations (au doigt mouillé ?) et leur intuition et cherchent les données qui vont pouvoir confirmer ces opinions selon la formule bien connue que l’on fait dire ce qu’on veut aux statistiques.
Par ailleurs, la culture française n’est peut-être pas adaptée à la démarche que requiert le big data. « La numérisation ne se pense pas, elle se fait, expliquait Yves Caseau, directeur technologies, prospectives et innovation de Bouygues Telecom lors de la présentation du baromètre CIO 2013. Il faut essayer et évaluer et laisser de l’autonomie aux acteurs du changement. En France, on a encore une vision tayloriste de l’organisation des entreprises avec, d’un côté, les gens qui pensent et, de l’autre, les gens qui font ».