Gestion de la connaissance en entreprise, son organisation et les moyens qui lui sont dédiés dans le domaine des éditeurs de logiciels

Gestion de la connaissance en entreprise, son organisation et les moyens qui lui sont dédiés dans le domaine des éditeurs de logiciels

-

Documents
3 pages
Lire
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres

Description

Gestion de la connaissance en entreprise, son organisation et les moyens qui lui sont dédiés dans le domaine des éditeurs de logiciels

Sujets

Informations

Publié par
Publié le 25 juin 2012
Nombre de visites sur la page 179
Langue Français
Signaler un problème
Gestion de la connaissance en entreprise, son organisation et les moyens qui lui sont dédiés dans le domaine des éditeurs de logiciels Projet UE7- Travail Collectif José ORTEGON Eugenio MAURI Jérôme BARBIER Rappelducetxetno
José ActivitéEdition de progiciels Relation ClientEn contact direct avec le commanditaire (pas forcément l’utilisateur) Taille deEnviron 100 personnes l’entreprise OrganisationOrganisation de l’activité « métieragile »
Démarcheeséliuti
Eugenio Edition de logiciels non personnalisés Pas de contacts avec les clients
Environ 35 personnes en France (600 au total) Organisation de l’activité standardisée
Jérôme Edition de logiciels en boite Pas de contacts avec les clients
Très grande taille > 1000 Découpage en petites structures d’environ 50 personnes
Le formalisme des trois cartes était un peu différent, cependant une première analyse des cartes nous a permis d’identifier des points communs : oAu niveau des acteurs oAu niveau des connaissances oAu niveau des outils A partir de cette première analyse, nous avons réalisé deux formulaires pour classifier ces différents éléments : oUn premier formulaire dans lequel on a attribué un niveau de formalisme (formelle, non-formelle, informelle) pour 19 connaissances identifiées oUn second formulaire dans lequel 17 connaissances sont reliées à un outil et pour lesquelles on a attribué une première note sur le niveau de structuration et une seconde sur le niveau d’utilisation A partir de ces mesures, nous avons essayé de faire émerger des divergences et convergences que l’on a mise en forme de manière graphique.
Degrédeismeformalparogrnasiioatnméerti
Dans les graphiques on remarques les impacts des caractéristiques exposées dans le contexte. Pour José, on retrouve la volonté d’adopter une organisation de l’activité « Agile » qui se traduit par une part plus importante de l’informelle. Pour Eugenio, au contraire l’application standardisé du métiers de l’édition de logicielle tend vers une part plus importante de la connaissance formelle. Enfin pour Jérôme, alors qu’on s’attend à une forte présence de la connaissance formelle, la taille de l’entreprise oblige les acteurs a passer par des connaissances informelles.
Degrédeilmsroamfeparacétivit Nous avons ensuite essayé d’aller plus dans le détail en augmentant la granularité, mais faire ressortir des tendances sur 19 critères avait pour inconvénient de «noyer »les tendances. Aussi dans ce graphique, nous avons essayé de regrouper les 19 connaissances en 4 groupes: oMétiers oEugenio se démarque clairement par une tendance forte vers l’informel. Pour Jérôme, on retrouve le niveau de José, cela est du au découpage en micro-structures indépendantes. oMéthodologiques oOn retrouve le même niveau de informel pour les 3, les méthodes ne sont pas bien formalisées oPilotage oL’organisation « Agile » de José se démarque très nettement dans les connaissances liées au pilotage. oLivrables oD’un côté on retrouve l’organisation « Agile » au niveau de José qui a pour principe de ne pas s’attaché à produire un minimum de livrable, a contrario au niveau de Jérôme, la taille de l’entreprise et le fait de livrer un produit « en boite » induit une forte tendance vers le formelle. Globalement, mais quelques différence on retrouve quand les mêmes tendances sur les 4 regroupement pour les 3.
Distributiondesesncsaisnaonc
Nous avons identifié 17 connaissances «classiques »propres au domaine des éditeurs logiciels (Figure X). Parmi ces 17 connaissances, seulement la connaissance autour desteststraitée de est manière différente dans les trois organisations de notre analyse. Cela montre l’absence d'un consensus sur la façon comme lestestsdoivent être faits et la valeur qu'ils ont dans la production des logiciels dans l'actualité. Cette absence peut venir des nouvelles approches dites « agiles », pour lesquelles la valeurdes spécifications sur le processus de développement de logiciels et notamment sur lestestsest mise en cause fortement.
En suite, on trouve dans le schéma 5 connaissances traitées de la même façon par deux des trois organisations analysées. Il s'agit pour la plupart de connaissances traitées de manière formelle par les deux éditeurs les plus grands en taille (ceux de Jérôme et d'Eugenio) et de manière informelle par le plus petit des trois éditeurs (celui de José).
Finalement, le schéma nous montre 11 connaissances produites, partagées ou exploitées de la même « manière » (par rapport son formalisme) dans les trois organisations de notre analyse. Voici la liste de ces « connaissances communes » : Formelles : Le traitement des bugs Les livraisons faites au client Le support aux utilisateurs Les formations fournies par l'organisation La normalisation dans les codes des logiciels Informelles : Le pilotage effectué sur les développeurs Les formations réalisées à l'intérieur de l'organisation Le paramétrage des logiciels
Le pilotage des projets La gestion des alertes ou exceptions La transmission des bonnes pratiques
Lestilsoudessiancnasesnocmuomsnec
Le schéma Y a été construit à partir des 11 «connaissances communes» (traitées avec le même formalisme dans les trois éditeurs analysés). Il cherche à placer chacun des outils employés pour la production, le partage ou l'exploitation des ces 11 «connaissances communes» dans un plan qui met en évidence le niveau de structuration de l'information traitée et le type de production effectuée (individuelle ou collective). Le nombre des connaissances traitées par l'outil est représenté par la taille du carré sur le plan.
On distingue trois groupes d'outils par le nombre de connaissances traitées : les outils très utilisés, les outils moyennement utilisés et les outils peu utilisés. Dans le premier groupe, on trouve lebug tracker, les outilsbureautiques, lemailet l'outilverbal. À part lebug tracker, il s'agit des outils traitant des informations peu structurées. Le deuxième groupe est constitué par des outils collaboratifs moyennement utilisés: leWIKI, lamessagerie instantanée etl'outil pour le versioning de code source (SVN). Dans le dernier groupe, on trouve des dispositifs et des outils très divers et qui traitent pour la plupart des informations très structurées :SI financier,CQM,agenda, lesystème de release,IDE,planning,intranet & GED,réunion de spécificationet lesCoPils.
A noter également que : - nous utilisons très souvent un BugTracker de façon formelle. Cela est logique, car cet outil est  fortement lié au travail de testeur et il en existe de gratuits sur le marché capable d'offrir des  bonnesprestations. Nous pensons que tout éditeur de logiciel doit se doter de cet outil. - nos entreprises ne mettent pas en pratique une démarche de développement de façon rigoureuse.  Onaurait tendance à penser que les éditeurs logiciels ne suivent pas complètement une méthode. - une présence assez marquée de la composante orale caractérise nos entreprises. Cela semble donc  être une constante et pourrait aussi pallier au manque de rigueur lors du développement.