Le Syntec Numérique appelle les DSI à la résistance

A lire sur:  http://www.cio-online.com/actualites/lmi/lire-le-syntec-numerique-appelle-les-dsi-a-la-resistance-4704.html?utm_source=mail&utm_medium=email&utm_campaign=Newsletter


Edition du 23/11/2012 - par Didier Barathon

Derrière ses chiffres semestriels et ses prévisions 2013, le Syntec Numérique cherche à comprendre la crise et à rebondir. Le Syndicat, en liaison avec ses clients, ne veut plus continuer à subir les baisses de prix et les reports de commandes. Et il cherche un allié dans les DSI.

Le Syntec Numérique avait prévu 1,2% de croissance pour 2012, avec une marge d'erreur de 0,5%. « Nous sommes dans la fourchette basse » observe Guy Mamou-Mani, à 0,7% de croissance moyenne en 2012 pour le secteur des logiciels et services (prévisions établies à partir des chiffres du cabinet IDC).  Comme toujours, les SSII sont en retrait avec 0% (contre une prévision de 1%), les éditeurs à +1,6% (c'était exactement le chiffre prévu), le conseil en technologies à +2% (+1,1% anticipé).
La situation s'est dégradée au deuxième semestre. Selon Guy Mamou-Mani, deux explications ressortent : la baisse des coûts imposée par les entreprises à leurs DSI et le fait que ces DSI soient de plus en plus contournées par les métiers sur les nouveaux projets de type Byod ou MtoM. Comment réagir ? Selon le Président du Syntec Numérique : « nous devons nous rapprocher de plus en plus des DSI dans cette transformation et leur expliquer que ce n'est pas seulement un enjeu de prix mais un enjeu de transformation ». En clair, inciter ces DSI à résister à la pression sur les budgets qui se répercute en pression sur les prix et en report de projets pour les adhérents du Syntec Numérique.
Des baisses de prix rétro-actives
Il y a urgence. Selon l'enquête du Syndicat, 27% des entreprises interrogées constatent une augmentation des exigences unilatérales de leurs clients, c'est-à-dire sans négociation ou contrepartie, 22% observent des demandent de baisses de prix rétro-actives. Et 5% d'entre eux constatent la mise en place de référencements payants.
Pour 2013, les DSI ne se montrent pas forcément inquiètes selon le Syndicat, la situation sera difficile, mais il existerait autant de DSI qui vont augmenter leurs budgets que de DSI qui feront l'inverse.  Pas de panique. D'autant que la pression se fait plus sur les Capex, donc sur les achats de matériels, que sur les métiers, là où le soft est plus à son avantage.  Des directions métiers qui prennent un poids considérable. Aux Etats-Unis, la moitié des budgets informatiques passeront par elles  d'ici 2015, l'Europe devrait suivre.

Page suivante (2/2) >

How to Create a Project Charter

A lire sur:  Method 123

The best way to get a "Go" for a project is to get an approved "Project Charter". So read on to find out...

How to Create a Project Charter

A Project Charter is a document which outlines the purpose of the project, the way the project will be structured and how it will be successfully implemented. There are typically 5 main sections that must be created in a Project Charter.

Section #1: The Executive Summary
The Executive Summary is the first section in the document right behind the Table of Contents. The purpose of the Executive Summary is to sum up each section of the rest of the document by providing a very high level summary of the project. This includes a summary of the definition of the project, the organization and plan, risks and issues, and any assumptions or constraints that may have an affect on the project.

How should you write the Executive Summary? Picture yourself talking to the CEO of your company. You get right to the point and net things out for them. It's the same thing when you are writing the Executive Summary. Write it as if you are writing it for the CEO of your company and keep it brief and to the point.

When should you write the Executive Summary? Even though it's the first section of the document, it makes most sense to write it after you've written all the other sections. This will allow you to incorporate what you have just written for the other sections.

Section #2: Project Definition (What are We Doing?)
The Project Definition section allows for the opportunity to lay out the details a bit more than what is included in the Executive Summary. However, it should still be kept at a relatively high level. This is where you tell the reader what the project is all about. Standard sections and questions that need to be answered are:

• Project Vision - What is the big picture that this project is setting out to accomplish?
• Project Objectives - What are the major business and technology objectives that will be met in order to implement the vision?
• Project Scope - How far reaching will this project be? Will it be limited to just implementing new technology or will it encompass new processes, applications, and even multiple locations?
• Project Deliverables - What are the tangible project results that must be delivered to meet the scope, objectives, and vision of this project?

Defining the project by answering the questions above allows for a logical breakdown of the project and how it will meet the big picture that is needing to be accomplished.

Section #3: Project Organization (Who Will Be Doing It?)
The third section of the Project Charter outlines who is involved in this project and what are their roles and responsibilities. This is an especially important section to spend time on when you are putting the Project Charter together.

First, you need to identify the various customer groups that will be using the finished result of the project. This could be either internal or external customers. You won't need to include the name of every customer, but rather break it down by customer groups and include a representative for each group that can serve as a spokesperson on behalf of that group.

Next, identify other stakeholders that are interested in the success of the project but may not necessarily be the end user. This could include company executives from multiple organizations, outside regulators, along with others that have a vested interested in how the project is progressing. Include a brief note next to their group names as to specifically what interests them about the project.

Finally, identify the roles required to undertake the project. Examples include Sponsor, Review Group, Manager, and Team Member. Specifically outline what they can and can't do when it comes to the part they play on the project along with an authority matrix. This will be especially useful when questions come up later about who can request a change or approve an increase in budget.

Section #4: The Project Plan (How Will It Get Done?)
This is another important section in the Project Charter document. This provides a general idea of how the project will be implemented. Components of this section include the Overall Plan, Project Milestones, Dependencies, Resources, Financial Plan and Quality Plan.

This sounds like a lot to include in a document that is supposed to be high level and provide a general understanding. You can tailor this section to fit your needs. A good rule of thumb to follow is to include each section with whatever known information you have at the time of putting the project charter together. You can include caveats and disclaimers along the way that these are budgetary estimates and plans only. A more refined and accurate project plan will be developed during the Planning phase of the project.

Section #5: Project Considerations (What Could Go Wrong?)
Everyone assumes that their projects are going to go swimmingly well. However, there does need to be a reality check as to what could go wrong. That's what this section is all about. Take time to identify and include any Risks that could negatively impact the project along with their likelihood of occurring, impact on the project, and what is being done to mitigate the risk from occurring. Also, you'll want to include any Issues, Assumptions or Constraints that could make or break the project once it gets off the ground.

Once you've put together your Project Charter document and have it signed by the project sponsor, you've been given the green light to move forward.

What's behind enterprise insourcing of IT?

A lire sur:  http://www.techrepublic.com/blog/tech-manager/whats-behind-enterprise-insourcing-of-it/8055?tag=nl.e106&s_cid=e106

• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  

By Mary Shacklett

November 26, 2012, 5:37 AM PST

Takeaway: Some U.S. companies are making moves towards bringing formerly insourced jobs back in house. What’s behind this decision?

The annual salary of a software developer in the U.S. is $94,000. In India, it is $14,000, and in the Philippines it is $7,521 (Source: http://jobs.aol.com/articles/2012/07/09/gm-vows-to-insource-most-of-its-it-jobs-beginning-of-a-trend/.) Cloud-based tracking software gives companies immediate insights into the productivity of the offshore workers that they contract with-and the ability to provide true “follow the sun” resources for projects and IT support. All of this has made offshore IT markets extremely attractive to U.S. companies.
At the same time, there are U.S. companies that have or are making make countermoves toward insourcing.
One of them is General Motors, which announced in 2012 its plans to insource 90 percent of its IT jobs within three years. The goals are higher productivity from onshore staff, reduced travel, lower management burdens, better cultural fits and most importantly, the ability to directly command technology expertise for new product innovation and speed to market that will drive revenues and to also give the company a competitive edge since technology expertise is now a major defining competitive factor in most industries.
GM is not alone. Ford, Starbucks, Caterpillar, Google and GE all have made or are making insourcing moves. They cite factors like bringing products to market quicker, lower transportation and warehousing costs, better product and service quality, less rework, stronger intellectual property protection and a stronger “goodwill image” among Americans who are still struggling economically.
“A major reason large companies are considering insourcing IT is out of fear that their in-house IT skills bases are eroding with outsourcing and that they no longer have the technology “wherewithal” to support or to innovate with their own technology resources,” confided one IT industry consultant who works with a major corporation  who is  moving to insourcing.
Is excessive outsourcing ultimately a threat to American companies?
Prognosticators like Paul Craig Roberts, who served as Assistant Secretary of the Treasury in the Reagan Administration, say “yes.”  Robert described outsourcing as “fool’s gold for companies.” He went on to say that “Corporate America’s short-term mentality, stemming from bonuses tied to quarterly results, is causing U.S. companies to lose not only their best employees–their human capital–but also the consumers who buy their products. Employees displaced by foreigners and left unemployed or in lower paid work have a reduced presence in the consumer market.”
Not every company looking at insourcing has necessarily connected all of the dots to arrive at Roberts’ conclusions about the consumer market.  But what more companies that are insourcing are concerned about is the steady erosion of intellectual capital within their four walls-and also the ability to protect their product and idea innovations amid loose or nonexistent patent laws abroad. When this happens, you can find yourself investing in and doing all the R&D work-and then losing the market to those who have made off with your ideas and marketed them under their own labels.
It is in this scenario that IT potentially becomes high risk–because so many of the innovations companies are making-not only in products but in speed to market and the ability to capture more revenue while cutting costs-come from technology innovation. This is the area that more companies are starting to churn into their strategic thinking. They are weighing insourcing against the simple mathematics of procuring commodity IT labor at cut-rate prices. Other important areas, like speed and quality of manufacturing and time to market, are also getting consideration.
The debate will continue as we move into a new year. But it’s safe to say that in a majority of cases, we will continue to see a “mix” of outsourcing and insourcing practices, with a number of companies concluding that they have over-outsourced over the past few years to where they are now risking the long-term health of their internal intellectual capital.

Five tips for Agile measurement

A lire sur:  http://www.techrepublic.com/blog/project-management/five-tips-for-agile-measurement/5264?tag=nl.e053&s_cid=e053

By Guest Contributor

November 21, 2012, 10:16 AM PST

Takeaway: Managers and executives need a way to measure Agile development so they can make informed decisions. Now there is finally some good guidance on how to effectively measure Agile development.

Agile is here to stay. Once the radical alternative to Waterfall development methods, these legacy methodologies are being disrupted and replaced by Agile practices that improve time-to-market, reduce development costs, and produce higher quality software that better meets customer expectations. As the world demands more software, development teams — from scrappy startups to big corporations — are meeting the challenge with Agile.
But while Agile software development projects scale across the enterprise, management is still searching for the best way to gain deeper visibility into these projects. Large organizations cannot rely on the subjective anecdotes of those closest to the work; they require quantitative insight upon which to base business decisions.
Here are some quick tips to quantify the impact of the choices you make during and after your Agile transformation.

1. Start with desired outcomes, NOT what’s easy to measure.

Better measurement leads to better insights, which in turn leads to better decisions and eventually better outcomes. Most people start by measuring what’s easy. But measuring what’s easy can drive the wrong behavior. Let’s take a look at this story about two NBA players.
In 2010, Monta Ellis, with the Golden State Warriors, was the 9th highest scorer in the NBA. Carmelo Anthony, with the Denver Nuggets, was the 8th highest scorer. Measuring individual scoring totals is easy. You would assume that because they were prolific scorers, their teams would win.
However, when they were in the game, their teams won less. Scoring is a function of two other measures: 1) the number of shots and 2) the percentage of those shots that go in the basket. It turns out, these two “stars” have low measures for #2, their shooting percentage. The only reason they are high scorers is because they take more shots. They are literally stealing shots from their teammates who might have a better chance of scoring.
So, while the flow of learning goes from measures to outcomes, the way we think about it should start with outcomes. That’s why we call this ODIM.
better OUTCOMES ← better DECISIONS ← better INSIGHTS ← better MEASURES
The NBA players should focus on the outcome of winning more games rather than being high scorer. If they used the overall likelihood of the team scoring under various conditions as feedback, it would help them make better game-time decisions to achieve the ultimate outcome of winning. This brings us to our second tip.

2. Think of measurement as feedback, NOT levers.

Frequent feedback is the primary difference between Waterfall and Agile development. Successful Agile projects incorporate short iterations with fast feedback from customers. The key to effective Agile measurement is to think of measurement in terms of feedback, not as the traditional lever to motivate behavior. This often devolves into keeping score, which is where the dark side of measurement starts — avoid it.
There is a subtle, but important, distinction between “feedback” and “lever.” Feedback is something you seek to improve your own performance. Levers are used to influence others. The difference is more in how you use the measure than the measure itself.
For example, healthy use of a burndown chart tells the team if they are on track with their commitment so they can make adjustments in time. The counterexample is a manager using burndown charts to red-flag projects in trouble. While it may drive improvement, nobody wants the red flag thrown at them, so the tendency is to keep the metric in the green regardless of the reality of the situation.
You can’t make better informed decisions if the metrics you are using to gain insight don’t accurately represent reality (see tip #1). Rather, the manager could provide coaching on tools that the team can use to improve their own performance — a subtle but critical difference.

3. A balanced measurement regime or none at all.

Balance in Agile measurement (Figure A) includes four cornerstones:

1. Do it fast.
2. Do it right.
3. Do it on time.
4. Keep doing it.

Figure A

Without balance of these four elements, it’s easy to focus on just one. For example, if we focus only on increasing productivity this will likely drive down quality and customer satisfaction.

4. Measure specific outcomes for software.

1. Productivity
2. Responsiveness
3. Quality
4. Customer Satisfaction
5. Predictability
6. Employee Engagement

These six outcomes are the elements of the Software Development Performance Index (SDPI), used to quantify insights about development work and provide feedback on how process and technology decisions impact the development team’s performance. Know what to measure and focus on each individual element.

5. Listen to experts.

Agile has caught the attention of leading industry analysts, asserting itself as a key part of application lifecycle management (ALM) evaluations. These evaluations encompass more than just functionality for developers; they assess commitment to the ALM market, ALM product strategy, corporate strategy, and market presence. In fact, independent research firm Forrester Research, Inc. recently evaluated the most significant ALM software providers, treating Agile and Lean as critical tests of an ALM vendor’s offering. The report also found that businesses “can no longer accept historical gulfs between business and application development and delivery teams as, increasingly, firms now expect to manage application development and delivery as a business and treat it as a competency.”

The Agile perspective for software development metrics

In the move to Agile, overall goals are largely the same as before: to delight users with a quality product delivered in a predictable and efficient manner. Even after your Agile transformation, you will largely do the same “types” of things: analyze, design, code, test, release, maintain, and, yes, measure.
It’s the perspective you take when doing these that is different with Agile.

L’UGAP veut simplifier l’achat des prestations intellectuelles informatiques

A lire sur:  http://www.itchannel.info/articles/136745/ugap-veut-simplifier-achat-prestations-intellectuelles-informatiques.html?key=862d53eea2c1d2fe

Mercredi 14 Novembre 2012

Pour répondre aux besoins et à l’usage des directions des systèmes d’information des collectivités et des administrations de l’Etat (et de ses opérateurs), l’UGAP innove et met à disposition des clients publics une offre complète de prestations intellectuelles informatiques : conseil, appui au montage de procédure, maîtrise d’œuvre, sécurité, dématérialisation, informatique décisionnelle et applications mobiles. Pour concevoir cette offre, l’UGAP a attribué les marchés à 19 titulaires, PME et grandes entreprises.

« Nous avons souhaité apporter à nos clients publics une réponse globale au développement de leur système d’information » explique Albert Aloisi, chef du département Prestations Intellectuelles Informatiques de l’UGAP. « Avec l’ensemble de notre offre de produits informatiques et télécommunication et ainsi qu’avec les applicatifs proposés, nos clients peuvent désormais avoir recours à des prestations intellectuelles intégrant du conseil, de la conceptualisation, du développement et du support au monde applicatif ».

Avec cette offre étendue, deux dispositifs sont mis à disposition des clients publics :

- des Unités d’œuvres prédéfinies, forfaitisées : l’UGAP garantit des profils d’expertise adaptés à la complexité des projets. Le processus est simplifié : analyse des besoins par le titulaire, évaluation des unités d’œuvres nécessaires à la réalisation du projet, production et délivrance des livrables.

8 titulaires ont été notifiés dont 5 PME :
• pour le conseil en système d’information : ADMINEXT (PME)
• pour l’appui au montage d’une procédure de marché public : CG2 CONSEIL (PME)
• pour la maîtrise d’œuvre déléguée d’applications : CAPGEMINI
• pour la sécurité des systèmes d’information : SOGETI
• pour l’assistance à la dématérialisation : INOP’S (PME)
• pour le support sur logiciels libres (Open Source) : LINAGORA (PME)
• pour les prestations d’informatique décisionnelle : EXL GROUP (PME)
• pour le développement d’application mobiles : SOGETI

- des projets sur-mesure : l’UGAP permet au client d’obtenir la meilleure solution selon son cahier des charges. Le processus est aussi spécifique : rédaction du cahier de charges par le client, remise en concurrence des titulaires d’accords-cadres, remise du dossier complet pour la notification du marché non-exécuté.

Au total 16 titulaires ont été sélectionnés :
ALTRAN, ATOS, BULL, CAPGEMINI, COLOMBUS, DEVOTEAM, EURIWARE, Exl group / KEY CONSULTING, GFI INFORMATIQUE, INOP’S, LOGICA, NORSYS, SEMANTYS / ASTEK, SOGETI France, SOPRA GROUP, STERIA

Ces entreprises apporteront leurs expertises sur les accords-cadres en terme de :

• Conseil en organisation et ingénierie des processus des Systèmes d’Information
• Etudes d’opportunité et spécifications des projets de Systèmes d’Information
• Paramétrage progiciel, Intégration Systèmes d’Information et maintenance
• Développements spécifiques d’applications informatiques et maintenance
• Assistance au déploiement d’applications informatiques
• Organisation du changement et formation sur logiciel.

N°153: Organisation du projet (partie I)

A lire sur:  Tenstep

La manière dont l’équipe du projet est organisée est directement liée à la manière dont l’organisation toute entière est structurée. Il y a trois structures d’organisation principales pour gérer le travail et les personnes.

Organisation fonctionnelle

Dans une organisation fonctionnelle, l’équipe de projet est formée de personnes d’un même service. Toutes les ressources en personnel de l’équipe de projet viennent de la même organisation fonctionnelle. Par exemple, si le projet relève du domaine financier, le personnel du projet dépend de la division financière. Si vous avez besoin de personnels spécialisés en techno-informatique, en finances et droit, elles sont toutes disponibles dans la division financière.

Un projet dans une organisation fonctionnelle peut être pourvu en personnel d’une deuxième manière, celle qui passe par l’exécution de portions d’un projet dans une organisation fonctionnelle à la fois. Par exemple, disons qu'un grand projet nécessite des ressources, des services, des finances, des achats, de la TI et de la fabrication. Dans une organisation fonctionnelle, le projet sera partagé entre diverses unités organisationnelles et chaque unité s’occupera de sa partie du travail, de manière indépendante. Le service TI s’occupera de sa partie, le service des finances de la sienne. Les services de production et des achats s'occuperont chacun de sa partie. A la fin, toutes les solutions indépendantes seront intégrées dans la solution finale.

Le grand avantage des projets basés sur la fonctionnalité est que l’autorité est clairement définie, puisque les chefs de projet sont généralement aussi les managers fonctionnels. Vous n’avez pas non plus besoin de négocier avec d’autres organisations pour le personnel, puisque tout le personnel que demande votre projet vient de la même organisation fonctionnelle. L’autre avantage que présente ce type d’organisation est que les membres de l’équipe sont habituellement familiers les uns des autres, puisqu’ils travaillent tous dans le même secteur. Les membres de l’équipe ont également tendance à apporter  des connaissances dans le domaine commercial applicables au projet.

Un inconvénient important de l’organisation fonctionnelle est que votre domaine fonctionnel peut ne pas disposer de tous les spécialistes nécessaires pour travailler sur un projet. Dans un projet financier comportant une composante techno informatique, on peut, par exemple, se heurter à des difficultés pour obtenir des spécialistes en TI tels que les administrateurs de bases de données, car les seules personnes disponibles travaillent déjà au sein de leur propre service fonctionnel. Un autre inconvénient est que les membres des équipes du projet ont parfois d’autres responsabilités dans l’organisation fonctionnelle, puisqu’ils n’ont pas toujours à travailler à plein temps sur un projet. Il arrive qu’ils soient assignés à d’autres projets, mais il est plus courant qu’ils aient des responsabilités de soutien qui pourraient affecter leur capacité de respecter les délais du projet.

Terminologie de management de projet

Matériel. Ensemble des éléments utilisés par une organisation dans une de ses activités : équipement, appareils, outils, machines, mécanismes, matériaux et fournitures, etc.

Management des coûts du projet. Le management des coûts du projet comprend les processus relatifs à l'estimation, à l'établissement du budget et à la maîtrise des coûts, de façon que le projet soit achevé en restant dans le cadre du budget approuvé. Aussi appelé Gestion des coûts du projet dans certains pays francophones.

Abréviations courantes

COQ (anglais) : Cost of Quality

        (français) : Coût de la qualité

Liens intéressants

Logiciel: Oracle, Redwood Shores

·   Société: Oracle, Redwood Shores, Californie, États-Unis d'Amérique

·   URL: www.oracle.com

·   Catégorie: Gestion de la gouvernance

·   Fonctionnalités:

o    Offre une plateforme pour la gouvernance, les initiatives de risques et de conformité (GRC).

o    Permet aux utilisateurs de cadrer, d'orchestrer et de suivre les activités de validation interne.

o    Aide les utilisateurs à gérer le risque par l'évaluation fondée sur des critères.

o    Stocke les documents de travail de vérification et les preuves de test.

CIO: Methods for building your network

A lire sur:  http://www.techrepublic.com/blog/tech-manager/cio-methods-for-building-your-network/8038?tag=nl.e106&s_cid=e106

• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  

By Richard Turkel

November 14, 2012, 6:58 AM PST

Takeaway: Most CIOs understand that they can’t do their job in isolation. But many CIOs don’t know what networking looks like or how to do it.

Most IT leadership professionals understand that they can’t do their job in isolation. As Scott Lowe points out, CIOs can’t go it alone anymore. Many CIOs, though, have trouble assessing what this exactly means. There’s a sense that it involves networking, but no underlying conversation of what networking looks like or how to do it.
So that’s the conversation I want to enter today. I’d like to talk about how most people view networking, give my version of what networking is and provide some concrete strategies CIO and other IT leadership professionals can use.
Most people (not just CIOs) view networking as a chore. Others view it as a competition to see who can build the biggest network. And still others view it as a silly practice best left to people who don’t know how to really do their job. But these are usually the opinions of people who have never tried, or those who tried and didn’t do it well. That’s understandable, because those who have never tried it or who didn’t succeed don’t yet understand how helpful and fun networking actually is.
In reality, networking is nothing more than connecting with people. It’s a chance to have fun, and show people that you care.
The root of our misconception about network lies in the term itself. A network is a way to connect devices so that you can exchange information. This is a very transactional view of a network (and it should be when you’re talking about technology). When you transfer it into the business world where real people exist, though, this transactional view becomes dangerous. If you view networking this way, you risk the chance of pushing people away and isolating yourself.
Instead, you should view networking as a chance to create allies. You may have heard the “bank account” metaphor before. It’s a little overdone, but it fits perfectly in this scenario. To build an ally, you must start by making a deposit. You have to give the person something so that when you ask for help or a favor later you’ve already build up some “street cred” in your “bank account.”
When you’ve found out how to do this effectively, you will have a great start to building your network. But how do you begin this process?

Start with influencers

It might seem superficial to focus on the more important people, but the truth is that you only have so many hours in the day. If you have to choose between networking with the CFO and the janitor, choose the CFO if they can provide you more benefits.
Keep in mind, though, that high status within an organization isn’t necessarily an indicator of an influencer. It might be that the janitor turns out to be a better partnership. Think through what a person has to offer you instead of just their job title.

Schedule time in a relaxed, undemanding setting

This might mean that you set up a meeting off-site to talk (see the next strategy for topic ideas). But it might also mean simply having lunch with an influencer in the staff room or after a conference. If you’re scheduling a meeting, make sure that you’re not scheduling it because you want something. State beforehand that you’re scheduling the meeting so you can get to know the person.

Offer your attention and expertise

The first thing you must always do is to offer your genuine attention. Ask some questions. How is the person’s family? How did they get involved in their current field? This allows you to build a solid base upon which your partnership rests.
Second, offer your expertise. What can you do to help them? Take the janitor as an example. You could ask them if your team is doing anything to hinder them doing their job (cables left out, etc.). Maybe you’ll find out that you can’t help the person right now, but you still get points for caring. People will remember it.

Don’t forget your team

Work to build connections with your team, as well. You probably already know the importance of this, so I won’t give an example.
However, since you’re team is closest to you, you should encourage them to build a network. Your team comes in contact with scores of people each week who you probably don’t even know exist. Teach them how to network with these people. This will increase the size of your network by-proxy.

Bringing it together

Of course, building a network isn’t all about giving; it’s also about receiving. Don’t be afraid to ask for help when you need it. For example, most companies now utilize some form of IT service management. The CIO’s job in this is to make sure that these outsourced tasks integrate well with internal processes. Networking in this scenario might mean building a solid relationship with someone at the third-party company and asking them to keep you informed of changes.
Networking takes time and emotional energy. Just remember that it’s all for a purpose. And, on the plus side, you may build some real friendships while also paving the way for any favors or help you’ll need in the future. Trust me; it’s worth it.
Richard Turkel writes about all aspects of business technology, from database management to IT leadership. He currently writes for BMC, a company that offers ITIL change management services.

N°152: Ramener un projet dans les délais convenus (partie II)

A lire sur:  Tenstep

Procédez à des changements de personnel sur le chemin critique
Vous avez vu auparavant que la première chose que vous devriez faire, quand vous commencez à avoir tendance à dépasser l’échéancier, est de déterminer la cause. L’une des causes peut être le fait qu’une personne ou plus, parmi celles que vous employez, n’est pas aussi productive que vous ne l’aviez envisagé. Peut-être ces personnes n’ont-elles pas les compétences requises. Il se peut aussi que ces personnes ne soient pas aussi productives dans ce secteur particulier que dans d’autres secteurs.

Indépendamment de tout, il y a probablement des possibilités de remplacer du personnel. Changer le personnel signifie congédier un membre de l’équipe et mettre une personne extérieure à l’équipe à sa place. (Cela diffère de la réaffectation des membres du personnel à l’intérieur de l’équipe.) Il est probable que lorsque votre projet a commencé, vous avez reçu les meilleures ressources disponibles. Cependant, pendant la progression de votre projet, vous pourriez réaliser que d'autres ressources sont devenues disponibles. Ces gens pourraient mieux convenir pour votre projet.

Vérifiez deux fois toutes les liaisons entre les activités

Les liaisons entre les activités de l’échéancier représentent l’ordre dans lequel ces activités doivent être accomplies. Par exemple, si vous construisez une maison, vous ne pouvez pas commencer à installer le toit tant que les structures n’ont pas été érigées et ne sont pas déjà sèches. Si vous tendez à dépasser votre date limite, ces liaisons devraient être validées à nouveau, puisqu'il est possible que l'échéancier risque d’être prolongé par des liaisons entre des activités qui ne sont pas valides. Les liaisons non valides peuvent amener à croire que des activités doivent être exécutées séquentiellement, alors qu’elles peuvent en réalité être réalisées en parallèle. Parfois, le logiciel de gestion de l’échéancier ajoute accidentellement un type de liaison non voulu en raison d’une erreur lors de la saisie des activités. Parfois, c’est le chef de projet qui ajoute intentionnellement une liaison. Mais il s’avère, après un examen ultérieur, que celle-ci n'existe pas vraiment. Il pourrait être pertinent de faire passer en revue l'échéancier par les membres de l’équipe pour vérifier s'ils trouvent des liaisons entre les activités de l’échéancier que le chef de projet pense être valides mais qui ne le sont pas en réalité.

Les liaisons entre les activités de l’échéancier devraient toutes être vérifiées une deuxième fois pour s'assurer que tous les faits sont corrects, avant de penser à des mesures plus drastiques pour ramener le projet dans les délais.

Vérifiez les activités présentant des contraintes de temps

Les activités présentant des contraintes de temps sont celles qui ont des durées qui ne varient pas en fonction du nombre de personnes affectées à leur réalisation. Par exemple, vous pouvez assigner des membres de l’équipe à une formation de cinq jours. La formation dure cinq jours, peu importe le nombre de personnes présentes. Toutes ces activités présentant des contraintes de temps doivent être vérifiées pour valider l'échéancier. Des hypothèses émises pourraient peut-être être modifiées avec une approche différente. Par exemple, si vous avez fixé un délai de trois jours pour qu'un produit soit livré à un client, peut-être que ce délai pourrait être réduit à un jour, en payant davantage pour que la livraison continue durant la nuit. Si vous devez attendre deux jours pour que le béton sèche, vous pourriez abréger cette durée en louant une machine soufflant de l'air sur le béton.

Comprimez l’échéancier (crashing)

Comprimer l’échéancier signifie que la date limite est tellement critique que vous voulez ajouter du personnel au chemin critique, même si ce personnel supplémentaire n’est pas utilisé aussi efficacement qu’il le devrait. Bien sûr, vous voulez essayer d’être astucieux et de prendre la plus grande avance possible sur l’échéancier pour un accroissement minimum des coûts. Cependant, vous êtes seulement en train d’essayer de réaliser l’avance qu’il vous est possible de prendre.

Par exemple, si une personne a été chargée de réaliser une activité en dix jours, vous voulez savoir si deux personnes peuvent la compléter plus tôt. Cependant, il est possible que la deuxième personne n’ait pas les compétences appropriées, et que si vous l’affectez à plein temps, cela ne vous fera gagner que deux jours sur l’échéancier. Normalement, il n’est pas logique d’affecter une deuxième personne pendant huit jours juste pour terminer le travail deux jours plus tôt. Toutefois, si l’échéancier est si impérieux que vous vous trouvez dans un état de stress important, peut-être accepterez-vous cette solution.

Le personnel complémentaire peut provenir de l’équipe de projet ou, temporairement, de l'extérieur de l’équipe. Un des buts de la compression du programme est de réduire au minimum l’accroissement du coût. Cependant, en échange de la réalisation de quelques travaux en avance par rapport à l’échéancier, le crashing entraîne habituellement un certain accroissement complémentaire des coûts du projet. Si le coût n’est pas aussi important que la date limite, « comprimer » un ensemble d’activités peut être une alternative intéressante.

Terminologie de management de projet

Management de l'intégration du projet. Le management de l'intégration du projet comprend les processus et les activités qui permettent d'identifier, de définir, de combiner, d'unifier et de coordonner les différents processus et activités de management de projet au sein des groupes de processus de management du projet. Aussi appelé Gestion de l’intégration du projet dans certains pays francophones.

Marge totale. Temps maximum dont une activité de l'échéancier peut être retardée par rapport à sa date de début au plus tôt sans retarder la date de fin du projet ni transgresser une contrainte de l'échéancier. Elle se calcule à l'aide de la méthode du chemin critique en déterminant la différence entre la date de fin au plus tôt et la date de fin au plus tard. Voir aussi Marge libre.

Abréviations courantes

BAC (anglais) : Budget at Completion

        (français) : Budget à l’achèvement

Liens intéressants

Logiciel: Mediachase

·   Société: Mediachase, Los Angeles, Californie, États-Unis d'Amérique

·   URL: www.ibnportal.com

·   Catégorie: Gestion de projet et collaboration basé sur le Web

·   Fonctionnalités:

o    Permet aux utilisateurs de créer des équipes de projet en ligne.

o    inclut un portail de collaboration de projet pour créer des tâches, charger des fichiers, partager des agendas et suivre des discussions.

o    Permet aux utilisateurs de créer des portails accessibles personnalisés pour spécifier les membres de l'équipe ou les utilisateurs externes.

Les PME aussi se préparent au pire

A lire sur: http://www.lecho.be/dossier/ticpme/Les_PME_aussi_se_preparent_au_pire.9255728-2893.art

16:48 - 17 octobre 2012 par WV

Incendie, inondations et autres catastrophes : les entreprises se protègent de plus en plus contre le fameux worst case scenario. Les PME aussi se préparent au pire. Soit parce qu’elles ont conscience qu’elles n’ont jamais été aussi dépendantes de leur informatique. Soit contraintes et forcées.

Dans le jargon informatique, il existe un terme pour cette approche : business continument, ou continuité opérationnelle. La question est la suivante : comment faire pour que votre entreprise puisse continuer à tourner en toutes circonstances ? Il s’agit de protéger ordinateurs et bâtiments, de sauvegarder régulièrement vos données (backups), mais aussi d’éviter ou d’apprendre à gérer les catastrophes. Et ce, qu’il s’agisse de catastrophes naturelles ou de " simples " crashs informatiques. La continuité opérationnelle exige une approche à long terme. Pas question d’attendre une catastrophe : à ce moment-là, il sera trop tard. Mieux vaut prévenir que guérir.
Le terme business continuity est souvent prononcé dans la foulée d’une autre expression : disaster recovery ou reprise après sinistre. Souvent, les deux formules sont considérées comme des synonymes, à tort : la reprise après sinistre ne constitue qu’un élément (relativement modeste) de la continuité opérationnelle. Fondamentalement, elle consiste à savoir comment restaurer l’infrastructure de l’entreprise après une catastrophe. Ce cas de figure mobilise aussi toute l’attention d’une PME. Une enquête de l’IT Governance Institute révèle qu’une entreprise moyenne ne peut pas se permettre plus de quatre heures d’arrêt sans subir un impact sérieux sur son fonctionnement.

Reprise

Le sujet est plus actuel que vous pourriez le penser. Selon une enquête belge de la revue Smart Business Strategies, deux entreprises sur trois ont au moins un plan de reprise après sinistre. Pour les organisations qui visent une disponibilité absolue, comme les services d’utilité publique ou les banques, la pression en faveur de la continuité opérationnelle s’est considérablement accrue ces dernières années. C’est par exemple le cas à l’Antwerpse Beroepskrediet (ABK), une banque de petite envergure.
" Nous faisons chaque année un test lors duquel nous simulons une catastrophe pour ensuite revenir à la procédure normale ", explique l’IT Manager Bart Van der Avort. " Il y a 15 ans, il fallait quatre à cinq jours pour que tout rentre dans l’ordre. Aujourd’hui, quelques heures suffisent pour recommencer à fonctionner normalement ", affirme-t-il. " Notre possédons également un double de notre centre de données, ce qui nous permet de basculer d’une version à l’autre en cas de problème. L’opération passe quasiment inobservée chez les clients. " Outre certaines motivations purement économiques, comme la volonté de maintenir la productivité ou d’éviter un manque à gagner et autres retombées néfastes sur son image de marque, l’entreprise est également tenue de se conformer à un nombre croissant de réglementations et de dispositions en tous genres. " Nos obligations sont les mêmes que celles des grandes banques, seule la taille diffère. Finalement, c’est le personnel qui constitue le principal défi en matière de continuité opérationnelle. "
Au départ, le problème résidait dans la concentration des fonctions. "Trop de tâches étaient concentrées auprès de la même personne. C’est un risque. " Mais ce problème va disparaître de luimême. En effet, depuis un peu plus d’un an, la banque a été rachetée par la Banque J. Van Breda. Certes, la transaction n’a pas changé grand-chose au principe de la continuité opérationnelle : ABK continue à fonctionner comme une entité indépendante. " Cependant, la continuité opérationnelle sera désormais coorganisée avec les collègues du département informatique de la Banque J. Van Breda. De quelques informaticiens en charge de la continuité opérationnelle nous passerons à plusieurs dizaines. Les principes fondamentaux de la continuité opérationnelle restent inchangés. En fait, ils sont édictés pour l’ensemble de l’entreprise. Seule les modalités concrètes seront différentes. Les questions sont les mêmes, mais les réponses peuvent différer. "

Assurance

L’essor de la continuité opérationnelle coïncide avec la montée en puissance de l’informatique dans les entreprises. Les employés ont besoin de la technologie pour exécuter leurs tâches quotidiennes. Les services informatiques sont évidents et nécessaires. Tout le monde est d’accord que les e-mails sont essentiels : perdez-les et vous prendrez conscience de leur valeur. " C’est pourquoi le management de notre entreprise voit la continuité opérationnelle comme la garantie que tout continuera à fonctionner. " Comme souvent dans le cas des projets opérationnels et informatiques, le support et l’implication du management revêtent une importance primordiale. Même si cette implication est commune à tous les membres de l’organisation.
" Elle doit exister autant chez les managers que chez la réceptionniste. Chaque membre de l’entreprise dispose chez lui d’une copie de notre plan de reprise après sinistre, pour savoir quoi faire en cas de catastrophe ", explique Van der Avort. Mais, bien entendu, les stratégies de reprises après sinistre les plus efficaces sont celles qui consistent à anticiper les risques pour ne jamais devoir mettre le plan en oeuvre. Tout est aussi question d’arbitrage. " Vous pouvez stipuler dans le contrat conclu avec votre fournisseur informatique que tous les services doivent être opérationnels en un laps de temps minimum. Mais cela vous coûtera très cher. Surtout si vous gérez une petite entreprise. Il est donc important de déterminer les processus cruciaux et ceux qui le sont moins ", conclut Van der Avort.

Conseils en matiere de continuite operationnelle bases sur l’experience d’ABK. 

• Mettez la continuité opérationnelle à votre agenda.
• Suscitez l’implication et l’engagement de la direction.
• Établissez un plan que vous contrôlerez et mettrez régulièrement à jour.
• Impliquez tous les membres du personnel.
• Sensibilisez, notamment au travers de formations.
• Rédigez régulièrement des rapports à l’attention du management et du Conseil d’Administration.
• Soyez prêt à affronter le pire. Dans le cas d’ABK, par exemple, il s’agit de l’explosion de la centrale nucléaire de Doel.

L'Echo

5 Tips for Setting Project Priorities

A lire sur:  Method 123

How many times have you had this conversation with your boss: "There are so many projects going on right now, which ones are the most important?" They reply: "They are all equally as important, they are all high priority and they all need to be done yesterday!" What do you do when you get this type of answer? Simply follow these:

5 Tips for Setting Project Priorities

Use the following questions to help you set your own project priorities:

Question #1 – Does the Project Bring in Revenue?

Companies are in business to make money. That's why everyone goes to great lengths to get as much done as possible with limited resources and short time frames. You can never go wrong with this question if you are struggling with setting project priorities. Choose the project to work on that will bring in revenue to the company if you have a choice to make. For example, there may be one phase of the project that needs to be complete in order to receive the next payment of 25%. Finish this project first before you move on to a new project that may not be as close to bringing cash into the company.

Question #2 – Will Closing this Project Create Client Noise?

Unfortunately, sometimes projects don't go as planned. This is bad enough when the project is an internal project, but it can really cause friction when the project is for a client. Dates may begin to slip or functionality may not work as intended. Clients can become frustrated and may begin getting a bit vocal. This gradual crescendo of discontent can quickly escalate to a full-blown roar if not carefully managed. Payment can start being withheld, VPs start getting involved, and meetings designed to reset expectations are necessary in order to get things back on track. These are the next types of projects you would move up in the queue to work on as you prioritize your projects.

Question #3 – Will Closing this Project Create Internal Noise?

This question is a variation of quieting client noise. Internal noise can be almost as bad as client noise and many times a bit more intense. It sounds like this... "I would be able to finish my deliverable, but I'm waiting on the specification that is running 8 weeks behind!" That particular deliverable is a project that you have been assigned to manage. This deliverable may not be complete for legitimate reasons (for example, limited resources, shifting priorities, changing scope) but it is being used as the poster child for why someone else internally is running behind. These are the next projects you want to tackle and bring to closure.

Question #4 – Is it a Strategic Project?

Now that you have projects that are bringing in revenue and the noise is down to a dull roar, you can focus on those projects that are strategic in nature. These are projects that will be introducing a new product, taking the company in a different direction, or supporting some other strategic initiative the company has defined. These types of projects are typically less crisis-oriented and longer term in nature. These can fit in nicely around paying client projects while these new projects gradually shift the direction of the company.

Question #5 – What's Left?

You are now down to the final question. What projects are left? These projects are typically pet projects from VPs and Executives that they would like to get done. They may not necessarily further the company's big picture, but they will make their department's job easier. Or, these may be projects that fall into the "nice-to-have" category but would not be considered mission critical.

There is one exception to the order of the questions above. Question #4 can quickly move to the top of the list depending upon the current state of the company. The company may be on the verge of going out of business because of offering antiquated or out-of-date products or services. Nothing else matters beyond changing the strategic direction of the company if this is the case. Question #4 will rocket to the top of this list and everything else will become a lower priority.

So the next time you hear they answer "they're all important", use the questions above to help you manage setting project priorities. You will quickly find that this process will become second nature and you will automatically be picking the next best project to work on!

Prioritize your projects by using ProjectManager.com. You can include project priorities that range from "Critical" to "Not Important" and sort your projects accordingly.

Mettre en œuvre une gestion en temps réel de la qualité des données : comment corriger de manière efficace les données erronées

A lire sur:  http://www.decideo.fr/Mettre-en-oeuvre-une-gestion-en-temps-reel-de-la-qualite-des-donnees-comment-corriger-de-maniere-efficace-les-donnees_a5645.html?utm_medium=email&utm_campaign=Decideo+455&utm_content=Decideo+455+CID_f8a34a28bb56a052d61ce090d1f15b2a&utm_source=CampaignMonitor&utm_term=Lire%20la%20suite%20et%20commenter

Stéphane JOUAUX, Information Builders

Jeudi 8 Novembre 2012

Utiliser des données de mauvaise qualité peut s’avérer onéreux. Le Data Warehouse Institute (TDWI) estime que les données erronées coûtent près de 600 millions de dollars par an aux entreprises. L’usage de données incorrectes peut avoir de nombreuses répercussions : service client médiocre, ventes manquées, perte de chiffre d’affaires, définition d’une stratégie peu pertinente.

Stéphane Jouaux, Country Manager, Information Builders France

24
inShare

La gestion en temps réel de la qualité de données est le moyen le plus efficace de minimiser les risques financiers et opérationnels découlant d’informations erronées. Cependant, ce n’est pas la méthode la plus utilisée pour détecter et corriger les problèmes liés aux données en entreprise.

Au commencement était le traitement en mode différé

Le traitement en mode différé est une méthode traditionnelle, fréquemment utilisée pour gérer la qualité des données. L’une des principales raisons de cet état de fait tient à ce que beaucoup d’entreprises utilisent encore des systèmes propriétaires. Dans la plupart des cas, les outils de qualité de données sont directement intégrés aux processus d’extraction, de transformation et de chargement des données (ETL). Les données sont évaluées et nettoyées lorsqu’elles sont déplacées depuis des bases de données ou d’autres systèmes sources vers des entrepôts de données.

Cette technique, bien que largement utilisée, n’est pas idéale car elle engendre une exposition importante aux risques. Supposons que pour la plupart de ces entreprises, le passage des données, depuis les systèmes sources vers les référentiels, se fasse chaque nuit. Les utilisateurs courront alors le risque de prendre des décisions critiques ou de mener des actions essentielles en se basant sur des données qui pourront être incorrectes depuis 24 heures. Les informations incorrectes tendant à se diffuser dans toute l’organisation, de nouveaux problèmes surgiront et iront d’un système et d’une personne à l’autre. La gravité de ces problèmes augmentera probablement à un rythme étonnant, jusqu’à ce que les données en cause soient identifiées et corrigées.

Le quasi temps réel ne résout pas le problème

Certaines entreprises ont tenté de s’attaquer au problème via des méthodes de gestion de la qualité des données en quasi temps réel. Les données sont envoyées à intervalles réguliers vers des outils spéciaux pour évaluer leur qualité et les nettoyer si nécessaire. Ces intervalles sont bien plus rapprochés que pour
le traitement en mode différé (le délai peut atteindre une heure), ce qui représente une réelle évolution.

Mais les risques sont encore trop grands. Dans l’univers de l’entreprise, de nombreux événements peuvent survenir en une heure ! Imaginez un centre d’appels très demandé, qui reçoit des centaines d’appels par heure. Durant ces 60 minutes, quelques données clients erronées peuvent se traduire par une réponse inadaptée à des questions ou à des problèmes, et par la proposition d’un service inapproprié à des dizaines d’appelants. Les informations erronées auront un impact sur les autres métiers de l’entreprise : comptabilité, marketing, etc.

Une seule solution : La gestion en temps réel de la qualité des données

Un problème majeur pouvant survenir dès qu’un enregistrement erroné est réalisé dans une base de données, la gestion de la qualité des données doit être proactive et instantanée. Les données endommagées ou invalides doivent être identifiées et rectifiées au moment même de leur saisie, évitant d’emblée qu’une information inexacte ne soit diffusée dans l’environnement.

Toute stratégie en matière de gestion de la qualité des données, ainsi que les outils utilisés, doivent donc être capables de surveiller et d’évaluer l’ensemble des entrées possibles des données dans l’entreprise qu’elles soient recueillies manuellement ou de manière automatisée.

Appliquer la gestion en temps réel de la qualité des données tout au long du cycle de vie de la donnée.

Dans une entreprise, les données entrent, circulent et ressortent, au gré des activités quotidiennes.
Tout au long de ce cycle, il faut gérer leur intégrité en temps réel.

• En amont : Si une donnée erronée, saisie par un utilisateur interne, recueillie dans le cadre d’un échange B2B avec un partenaire, ou entrée par un client via un portail en self-service, s’introduit dans les systèmes de l’entreprise, les dommages qu’elle peut engendrer sont quasiment illimités. C’est pourquoi les règles automatisées et les normes de qualité de données doivent être appliquées sur le point d’origine. Et le problème se complique encore avec l’apparition de nouveaux canaux d’information et l’augmentation du nombre de points de contacts.

• Au sein d’un processus : Dans le cadre d’échanges commerciaux ou à des fins de reporting et d’analyse, les informations sont diffusées au sein de l’organisation, d’un utilisateur à un autre. Elles sont alors souvent modifiées, enrichies ou associées à d’autres enregistrements. Là encore, elles peuvent être altérées par un utilisateur, ce qui aura un impact négatif sur tous les utilisateurs et les processus. Une mise en place de contrôles et de bilans en temps réel est donc indispensable, afin d’éviter que les informations soient dupliquées, associées à d’autres données de manière inappropriée ou mal placées. Une fois l’erreur introduite au sein de l’infrastructure, il sera difficile de la corriger.

• En aval : Le reporting et l’analyse sont des missions critiques, et ce, quels que soient le secteur d’activité et la taille de l’entreprise. Tout au long de la journée, de manière continue, des informations sont extraites d’une multitude de sources (entrepôts de données, datamarts, cubes multidimensionnels et applications de back-end) pour orienter la stratégie de l’entreprise et mener des missions critiques. Si ces informations sont redondantes, incohérentes, difficiles d’accès ou tout simplement erronées, elles peuvent avoir un impact négatif sur l’efficacité opérationnelle, les performances de l’entreprise et la rentabilité. Et d’autres problèmes peuvent survenir si ces informations sont partagées ou transmises à des tiers tels que des organismes de réglementation, des clients ou des partenaires.

Si l’information erronée est identifiée dès sa création - en amont, en aval ou au sein d’un processus
- il suffit de corriger une erreur unique et non une multitude de données incorrectes. Cela optimise les délais et les coûts liés au traitement de cette erreur, et préserve pleinement l’intégrité des informations. Par conséquent, les processus métier critiques issus de cette information seront bien plus fiables et efficaces.

Mettre en œuvre une gestion en temps réel de la qualité des données.

La gestion en temps réel de la qualité des données doit couvrir l’ensemble de l’infrastructure traitant de l’information. Elle ne peut pas être facultative ou ne concerner que quelques systèmes. Elle doit faire partie intégrante de l’environnement et impliquer chaque composant de l’architecture, utilisateur ou processus automatisé qui crée ou utilise des données. En outre, les processus de qualité des données doivent être intégrés à toutes les bases de données de back-end.

Les problèmes d’intégrité des données ne se limitent jamais à un système unique. Un seul enregistrement erroné aura un impact sur d’autres systèmes au cours de ses mouvements en amont, en aval ou au sein d’un processus interne. Le temps nécessaire pour corriger ce problème sera proportionnel à son étendue. Il faudra alors davantage de temps, d’efforts et d’argent pour corriger l’erreur une fois identifiée et diffusée au sein des différents environnements.

La clé est de concevoir et de mettre en œuvre des services de qualité des données qui soient réutilisables, afin de pouvoir les exposer à tous les systèmes et applications de l’environnement.
Les mêmes règles et outils de qualité des données, tous gouvernés dans le cadre d’un plan unique, doivent être utilisés dans toute l’entreprise, quel que soit le niveau de latence des opérations. Le fait d’arrêter les mauvaises données dès qu’elles se présentent est le seul moyen de garantir la cohérence et l’exactitude de toutes les données, dans toute l’entreprise.

Le rôle du département informatique divise au sein des entreprises

A lire sur:  http://www.atelier.net/trends/articles/role-departement-informatique-divise-sein-entreprises?utm_source=emv&utm_medium=mail&utm_campaign=alerte_emea

Par L'Atelier - Paris 08 novembre 2012

Les professionnels qui travaillent dans le secteur ont une perception de leur métier encore différente de celle qu'ont les autres collaborateurs. Tous se rejoignent par contre sur l'importance à venir du département.

Au sein des sociétés, le rôle du département informatique est différemment perçu, selon que l'on prenne le point de vue des professionnels du secteur et du reste des employés. Une étude menée par InformationWeek auprès d'un peu moins de quatre cents collaborateurs, issus ou non du secteur IT, révèle en effet qu'une majorité des premiers estiment leur secteur comme raisonnablement innovant et efficace, quand les autres auraient une opinion moins enthousiaste. Des disparités qui se traduisent pas des chiffres : 60 % des personnes travaillant dans le département informatique jugent que ce dernier fait partie intégrante du business, quand seulement 43 % des autres collaborateurs le pensent. De même, ces derniers considèrent majoritairement (54 %) le département informatique comme devant fournir des services de maintenance et du support informatique, quand seulement 39% des salariés du secteur IT ont la même opinion.

Facilitateur ou preneur de décisions ?

Dans la même veine, plus de huit collaborateurs sur dix jugent que le département doit être un facilitateur pour l'entreprise, et pas un preneur de décision. Là, la différence est moins marquée entre les deux mondes : près de 70 % des employés IT pensent que leur rôle doit en effet être celui-ci. Côté satisfaction des services apportés, le décalage de perception est le même : les deux tiers des personnes du secteur technologique pensent que les collaborateurs sont de modérément à complètement satisfaits de la qualité, de la rapidité et du coût des projets IT. 50 % de ces mêmes collaborateurs le pensent. Selon ce rapport, cette différence viendrait d’un manque de clarté quant aux statuts et aux fonctions des responsables informatiques à l’intérieur des entreprises.

Plus d'importance à venir

Reste un point d'accroche cependant : à peu près 60 % des deux groupes se rejoignent sur l'importance à venir de l'IT en interne, et pensent que le département deviendra de plus en plus indispensable au succès de l'entreprise d'ici les deux prochaines années. Mais les moyens pour y parvenir risquent aussi de poser des difficultés : 37% des personnes interrogées issues du département IT admettent que le budget consacré aux différents projets innovants varie fréquemment, et 24% d’entre eux avouent devoir convaincre les cadres dirigeants de l’entreprise pour se voir allouer un budget correspondant à l’importance d’un ou plusieurs projets. Des budgets qui seraient parfois validés sans leur participation.

En savoir plus

Les décideurs doivent-ils maîtriser les technologies pour innover ?

InnovationManagement10 septembre 2012

Des entreprises qui boudent le cloud pour les activités critiques

Management13 décembre 2011

Les départements informatique et marketing pas encore assez associés ?

InnovationManagement27 juin 2012

L'humain reste le premier moteur de la productivité

Société & Usages28 mars 2011