Machine Translated by Google http://ccs.mit.edu/papers/CCSWP191/CCSWP191.html Un modèle de changement improvisé Management : le cas du groupware Les technologies Wanda J. Orlikowski et J. Debra Hofman Massachusetts Institute of Technology École de gestion Sloan 50, promenade commémorative Cambridge MA 02142­1347 À paraître dans Sloan Management Review, hiver 1997 Table des matières Remerciements Résumé Introduction Un modèle d'improvisation pour gérer le changement Exemple de cas : Zeta Résumé de l'affaire Zeta Conditions d'activation Alignement des cotes de changement de clé Consacrer des ressources pour un soutien continu conclusion Notes de bas de page Références Les figures REMERCIEMENTS Machine Translated by Google Nous tenons à remercier l'éditeur et les relecteurs pour leurs commentaires utiles sur une version antérieure de ce manuscrit. Nous apprécions avec gratitude le soutien à la recherche du Center for Coordination Science et du Center for Information Systems Research du MIT. Un modèle d'improvisation de la gestion du changement : le cas des technologies de groupware Résumé Dans cet article, nous présentons une manière alternative de penser le changement technologique dans les organisations. Cette approche alternative est motivée par la reconnaissance que les modèles traditionnels de gestion du changement technologique ­ dans lesquels les principales étapes du changement sont définies à l'avance et l'organisation s'efforce ensuite de mettre en œuvre ces changements comme prévu dans un délai spécifié ­ ne sont pas particulièrement utiles étant donné les situations organisationnelles plus turbulentes, flexibles et incertaines auxquelles de nombreuses entreprises sont confrontées aujourd'hui. Les modèles traditionnels ne sont pas non plus particulièrement utiles pour aider à la mise en œuvre de technologies telles que les logiciels de groupe dont la nature sans précédent, évolutive et spécifique au contexte rend difficile la prédéfinition des changements exacts à réaliser et la prédiction de leur impact organisationnel probable. Nous suggérons un modèle alternatif de gestion du changement technologique, qui reflète la nature dynamique et variable des organisations et des technologies contemporaines, et qui s'adapte à l'expérimentation, à l'utilisation et à l'apprentissage itératifs au fil du temps. Nous étiquetons un tel modèle de gestion du changement technologique "d'improvisation" et suggérons qu'il peut permettre aux organisations de tirer parti des capacités en évolution, des pratiques émergentes et des résultats imprévus qui accompagnent l'utilisation des nouvelles technologies dans les organisations contemporaines. Introduction Dans la préface de sa discussion sur la conception technologique, Suchman (1987 : vii) fait référence à deux approches différentes de la navigation en haute mer ­ l'européen et le trukese : Le navigateur européen commence par un plan ­ une route ­ qu'il a tracé selon certains principes universels, et il exécute son voyage en rapportant chacun de ses mouvements à ce plan. Tout au long de son voyage, ses efforts visent à rester « sur la bonne voie ». Si des événements inattendus se produisent, il doit d'abord modifier le plan, puis réagir en conséquence. Le navigateur Trukese commence par un objectif plutôt qu'un plan. Il se dirige vers l'objectif et répond aux conditions au fur et à mesure qu'elles se présentent de manière ad hoc. Il utilise les informations fournies par le vent, les vagues, la marée et le courant, la faune, les étoiles, les nuages, le bruit de l'eau sur le côté du bateau, et il barre en conséquence. Son effort vise à faire tout ce qui est nécessaire pour atteindre l'objectif. (Berreman 1966, p.347) Comme Suchman, nous trouvons nous aussi ce contraste d'approches instructif et nous l'utiliserons ici pour motiver notre discussion sur la gestion du changement technologique. En particulier, nous suggérons que la façon dont les gens envisagent la gestion du changement dans les organisations ressemble le plus souvent à l'approche européenne de la navigation. Autrement dit, ils croient qu'ils doivent commencer par un plan de changement, établi selon certains principes organisationnels généraux, et qu'ils doivent lier leurs actions à ce plan, en s'assurant tout au long que le changement reste sur la bonne voie. Cependant, lorsque nous examinons comment le changement se produit réellement dans la pratique, nous constatons qu'il est beaucoup plus Machine Translated by Google ressemble beaucoup au voyage du Trukese. Autrement dit, les gens finissent par répondre aux conditions au fur et à mesure qu'elles surviennent, souvent de manière ad hoc, en faisant tout ce qui est nécessaire pour mettre en œuvre le changement. D'une manière similaire à celle d' Argyris et Schon (1978) contraste entre les théories adoptées et les théories en usage, nous suggérons qu'il existe un écart entre la façon dont les gens pensent au changement technologique et la façon dont ils le font. De plus, nous suggérons que cet écart contribue de manière significative aux difficultés et aux défis auxquels les organisations contemporaines sont confrontées lorsqu'elles tentent d'introduire et de mettre en œuvre efficacement des changements basés sur la technologie. Les façons traditionnelles de penser le changement technologique trouvent leurs racines dans l'ouvrage de Lewin (1952) modèle de changement en trois étapes de «dégel», «changement» et «regel» (Kwon et Zmud, 1987). Selon ce modèle, l'organisation se prépare au changement, met en œuvre le changement, puis s'efforce de retrouver la stabilité dès que possible. Un tel modèle, qui traite le changement comme un événement à gérer pendant une période déterminée (Pettigrew, 1985), peut avoir été approprié pour des organisations relativement stables, délimitées et dont la fonctionnalité était suffisamment fixe pour permettre une spécification détaillée. Aujourd'hui cependant, étant donné des conditions organisationnelles et environnementales plus turbulentes, flexibles et incertaines, un tel modèle devient moins approprié ; d'où l'écart. Cet écart est particulièrement prononcé lorsque la technologie mise en œuvre est évolutive et personnalisable, comme dans le cas des nouvelles technologies de l'information connues sous le nom de groupware.[1] Les technologies de groupware fournissent des réseaux électroniques qui prennent en charge la communication, la coordination et la collaboration par le biais d'installations telles que l'échange d'informations, les référentiels partagés, les forums de discussion et la messagerie. Ces technologies sont généralement conçues avec une architecture ouverte adaptable par les utilisateurs finaux, leur permettant de personnaliser les fonctionnalités existantes et de créer de nouvelles applications (DeJean et DeJean, 1991 ; Malone et al., 1992). Plutôt que d'automatiser une séquence prédéfinie d'opérations et de transactions, ces technologies ont tendance à être des outils à usage général qui sont utilisés de différentes manières dans diverses activités et contextes organisationnels. Les organisations ont besoin d'expérience dans l'utilisation des technologies collaboratives de manière particulière et dans des contextes particuliers pour mieux comprendre comment elles peuvent être les plus utiles dans la pratique. Dans un tel contexte technologique, le modèle de changement traditionnel est donc particulièrement décalé. L'écart est également évident lorsque les organisations utilisent les technologies de l'information pour tenter des changements sans précédent et complexes tels que l'intégration mondiale ou la gestion distribuée des connaissances. L'un des principaux exemples en est la tentative actuelle de nombreuses entreprises de redéfinir et d'intégrer les activités de la chaîne de valeur mondiale qui étaient auparavant gérées de manière indépendante. Bien qu'il y ait généralement une certaine compréhension à l'avance de l'ampleur d'un tel changement, la profondeur et la complexité des interactions entre ces activités ne sont pleinement comprises que lorsque les changements sont mis en œuvre. Pour de nombreuses organisations, de telles initiatives représentent un nouveau jeu de balle, non seulement parce qu'elles n'ont jamais joué au jeu auparavant, mais parce que la plupart des règles évoluent encore. Dans un monde aux règles incertaines, le modèle traditionnel de conception et d'exécution d'un plan de match est très difficile à mettre en place. Et comme l'ont suggéré des recherches récentes sur la stratégie (Mintzberg, 1994; McGrath et McMillan, 1995), la planification dans de telles circonstances est plus efficace en tant qu'effort continu, reflétant les environnements changeants et en évolution avec lesquels les organisations interagissent. Dans de nombreuses situations, il n'est donc pas possible de prédéfinir les changements technologiques à mettre en œuvre et de prédire avec précision leur impact organisationnel. Par conséquent, les modèles de changement planifié qui informent souvent la mise en œuvre de nouvelles technologies sont moins qu'efficaces. Nous suggérons que ce qui serait plus approprié est une façon de penser au changement qui reflète la nature sans précédent, incertaine, ouverte, complexe et flexible des technologies et des initiatives organisationnelles impliquées. Un tel modèle permettrait aux organisations d'absorber, de réagir et même d'exploiter systématiquement les événements inattendus, les capacités technologiques en évolution, les pratiques émergentes et les résultats imprévus. Un tel modèle de gestion du changement permettrait ­ en fait, encouragerait ­ l'expérimentation, l'utilisation et l'apprentissage continus et itératifs. Un tel modèle considère la gestion du changement plus comme une improvisation continue que comme une mise en scène. Dans cet article, nous proposons un tel modèle alternatif. Après avoir présenté le modèle, nous décrivons une étude de cas d'implémentation de groupware dans une organisation de support client pour illustrer la valeur de ce Machine Translated by Google modèle alternatif dans la pratique. Nous concluons en discutant des conditions dans lesquelles un tel modèle d'improvisation peut être un puissant moyen de gérer la mise en œuvre et l'utilisation des technologies de pointe. Un modèle d'improvisation pour gérer le changement Le modèle d'improvisation pour gérer le changement technologique est basé sur les recherches que nous avons effectuées sur la mise en œuvre et l'utilisation des technologies de l'information ouvertes. Le modèle repose sur deux hypothèses majeures qui le différencient des modèles de changement traditionnels : premièrement, que les changements associés aux implémentations technologiques constituent un processus continu plutôt qu'un événement avec un point final après lequel l'organisation peut s'attendre à revenir à un état raisonnablement stable. ; d'autre part, que les différentes évolutions technologiques et organisationnelles opérées au cours du processus en cours ne peuvent, par définition, toutes être anticipées. Compte tenu de ces hypothèses, notre modèle de changement d'improvisation reconnaît trois types de changement différents : anticipé, émergent et basé sur les opportunités. Ces types de changement sont des élaborations sur Mintzberg (1987) distinction entre stratégies délibérées et émergentes. Ici, nous distinguons les changements anticipés ­ les changements qui sont planifiés à l'avance et se produisent comme prévu ­ et les changements émergents ­ les changements qui surviennent spontanément de l'innovation locale et qui ne sont pas initialement prévus ou prévus. Un exemple d'un changement prévu serait la mise en œuvre d'un logiciel de courrier électronique qui accomplit son objectif de faciliter une communication accrue et plus rapide entre les membres de l'organisation. Un exemple de changement émergent serait l'utilisation du réseau de courrier électronique comme une vigne informelle diffusant des rumeurs dans toute une organisation. Cette utilisation du courrier électronique n'est généralement pas planifiée ou anticipée lors de la mise en place du réseau, mais émerge souvent tacitement au fil du temps dans des contextes organisationnels particuliers. Nous différencions en outre ces deux types de changements des changements basés sur les opportunités ­ des changements qui ne sont pas anticipés à l'avance mais qui sont introduits délibérément et intentionnellement pendant le processus de changement en réponse à une opportunité, un événement ou une panne inattendus. Par exemple, à mesure que les entreprises acquièrent de l'expérience avec le World Wide Web, elles trouvent des opportunités d'appliquer et d'exploiter ses capacités d'une manière qui n'était pas prévue ou planifiée avant l'introduction du Web. Les changements anticipés et basés sur les opportunités impliquent une action délibérée, contrairement aux changements émergents qui surviennent spontanément et généralement tacitement des pratiques des gens avec la technologie au fil du temps (Orlikowski, 1996). Ces trois types de changement s'appuient les uns sur les autres au fil du temps de manière itérative (voir la figure 1). Bien qu'il n'y ait pas de séquence prédéfinie dans laquelle les différents types de changement se produisent, le déploiement d'une nouvelle technologie implique souvent un changement organisationnel initial anticipé associé à l'installation du nouveau matériel/logiciel. Au fil du temps, cependant, l'utilisation de la nouvelle technologie impliquera généralement une série de changements basés sur les opportunités, émergents et anticipés, dont l'ordre ne peut pas être déterminé à l'avance car les changements interagissent les uns avec les autres en réponse aux résultats, événements, et les conditions découlant de l'expérimentation et de l'utilisation. Une façon de penser à ce modèle de changement est de considérer, par analogie, un groupe de jazz. Alors que les membres d'un groupe de jazz, contrairement aux membres d'un orchestre symphonique, ne décident pas à l'avance exactement quelles notes chacun va jouer, ils décident à l'avance quelle composition musicale formera la base de leur performance. Une fois la représentation commencée, chaque interprète est libre d'explorer et d'innover, en partant de la composition originale. Pourtant, la performance fonctionne parce que tous les membres jouent dans la même structure rythmique et ont une compréhension commune des règles de ce genre musical. Ce qu'ils font, c'est improviser ­­ adopter une série continue d'innovations locales qui embellissent la structure d'origine, répondent aux départs spontanés et aux opportunités inattendues, et se répètent et s'appuient les unes sur les autres au fil du temps. En utilisant notre terminologie antérieure, les musiciens de jazz s'engagent dans une action anticipée, basée sur les opportunités et émergente au cours de leur performance pour créer une réponse efficace et créative aux conditions locales. Machine Translated by Google De même, un modèle d'improvisation pour gérer le changement technologique dans les organisations n'est pas un programme de changement prédéfini tracé par la direction à l'avance. Elle reconnaît plutôt que le changement technologique est une série itérative de changements différents, dont beaucoup sont imprévisibles au départ, qui découlent d'une expérience pratique avec les nouvelles technologies. L'utilisation d'un tel modèle pour gérer le changement nécessite un ensemble de processus et de mécanismes pour reconnaître les différents types de changement au fur et à mesure qu'ils se produisent et pour y répondre efficacement. Le cas illustratif présenté ci­ dessous suggère que lorsqu'une organisation est ouverte aux capacités offertes par une nouvelle plate­forme technologique et prête à adopter un modèle de changement d'improvisation, des changements organisationnels innovants peuvent être réalisés. Exemple de cas : Zeta Zeta est l'une des 50 premières sociétés de logiciels aux États­Unis, avec un chiffre d'affaires de 100 millions de dollars et environ 1 000 employés. Elle produit et vend une gamme de produits logiciels puissants offrant des fonctionnalités telles que l'aide à la décision, l'information des dirigeants et l'analyse marketing. Zeta a son siège social dans le Midwest, avec des bureaux de vente et de service client dans le monde entier. Les spécialistes du service client (CSD) de Zeta fournissent une assistance technique par téléphone aux clients, consultants, revendeurs à valeur ajoutée, représentants du service client Zeta sur le terrain et autres employés Zeta qui utilisent les produits. Ce support technique peut être assez complexe. Les spécialistes consacrent généralement plusieurs heures de recherche à chaque problème, recherchant souvent des documents de référence, tentant de reproduire le problème et/ou examinant le code source du programme. Certains incidents nécessitent une interaction avec des membres d'autres services tels que l'assurance qualité, la documentation et le développement de produits. Le CSD emploie une cinquantaine de spécialistes et est dirigé par un directeur et deux gérants. En 1992, le CSD a acheté la technologie de groupware Lotus Notes dans laquelle ils ont développé un nouveau système de support de suivi des incidents (ITSS) pour les aider à enregistrer les appels des clients et à conserver un historique des progrès vers la résolution des problèmes des clients. À la suite d'un projet pilote réussi du nouveau système, le CSD a décidé de s'engager sur la plate­forme Notes et de déployer l'ITSS dans l'ensemble de son département. L'acquisition d'une nouvelle technologie pour faciliter le suivi des appels des clients a été motivée par un certain nombre de facteurs. Le système de suivi existant était un système maison qui avait été développé lorsque le département était beaucoup plus petit et le portefeuille de produits de Zeta beaucoup plus étroit. Le système n'était pas en temps réel, la saisie des appels était aléatoire, l'exactitude des informations était un problème et les performances étaient lentes et peu fiables. Il n'apportait que peu d'aide à la réutilisation des solutions antérieures et aucun appui à la gestion des ressources du service. Le volume et la complexité des appels au CSD ont augmenté ces dernières années en raison de l'introduction de nouveaux produits, de la sophistication accrue des produits existants et de la gamme étendue de plates­formes d'exploitation prises en charge. Ces changements avaient fait du remplacement du système de suivi une priorité, car les responsables du CSD étaient particulièrement préoccupés par le fait que le système interne ne permettait pas de suivre les appels, d'interroger l'état d'appels particuliers, d'appréhender la charge de travail, d'équilibrer les ressources, d'identifier les enjeux et les problèmes avant ils sont devenus des crises, et obtiennent une documentation à jour et précise sur les travaux en cours et les travaux achevés. De plus, les appels étaient parfois perdus, car les bouts de papier sur lesquels ils étaient enregistrés étaient égarés ou jetés par inadvertance. L'introduction initiale du nouveau système ITSS s'est accompagnée de changements prévus dans la nature du travail des spécialistes et des gestionnaires. Contrairement au système précédent, qui avait été conçu pour ne capturer qu'une brève description du problème et sa résolution finale, l'ITSS a été conçu pour permettre aux spécialistes de documenter chaque étape qu'ils ont prise dans leur processus de résolution d'un incident particulier. Autrement dit, il a été conçu pour permettre la capture d'un historique complet des incidents. Au fur et à mesure que les spécialistes ont commencé à utiliser les SSTI de cette manière, l'accent de leur travail s'est déplacé de la recherche principale ­ la résolution de problèmes ­ vers la recherche et la documentation ­ la résolution de problèmes et la documentation des travaux en cours. La base de données ITSS a rapidement commencé à s'étoffer à mesure que chaque spécialiste documentait en détail son processus de résolution. Si la documentation des appels prenait du temps, elle permettait également de gagner du temps en fournissant une riche base de données d'informations pouvant être recherchées pour des résolutions potentielles. De plus, cette nouvelle base de données de riches Machine Translated by Google l'information a servi de mécanisme d'apprentissage inattendu et informel en offrant aux spécialistes une exposition à un large éventail de problèmes et de solutions. Comme l'a fait remarquer un spécialiste : « Si c'est calme, je vérifierai auprès de mes collègues pour voir quel... type d'appels ils reçoivent, afin que je puisse apprendre quelque chose d'eux... juste au cas où quelque chose pourrait sonner une cloche quand quelqu'un d'autre appelle." Dans le même temps, cependant, l'utilisation de la base de données ITSS comme seule source d'informations présentait un certain risque, car il n'y avait aucune garantie quant à l'exactitude des informations. Pour minimiser ce risque, les spécialistes ont tacitement développé un ensemble d'indicateurs de qualité informels pour les aider à faire la distinction entre les données fiables et non fiables. Par exemple, les résolutions documentées de manière exhaustive, documentées par certaines personnes ou vérifiées par le client étaient considérées comme des sources d'informations plus fiables. En plus de ces changements dans le travail des spécialistes, l'utilisation du nouveau système par les gestionnaires du CSD a amélioré leur capacité de contrôle des ressources du service. L'utilisation par les spécialistes de l'ITSS pour documenter les appels a fourni aux gestionnaires des informations détaillées sur la charge de travail, qui ont été utilisées pour justifier l'augmentation des effectifs et ajuster les horaires de travail et les affectations de quarts de manière dynamique et selon les besoins. ITSS a également fourni aux gestionnaires des informations plus précises sur le processus de travail des spécialistes, par exemple, les étapes particulières suivies pour rechercher et résoudre un problème, les domaines dans lesquels les spécialistes ont demandé conseil ou ont été bloqués et la qualité de leurs résolutions. Lorsque les gestionnaires ont commencé à se fier aux données du SSTI pour évaluer le rendement des spécialistes, ils ont élargi les critères qu'ils utilisaient pour faire cette évaluation. Par exemple, la qualité de la documentation des travaux en cours a été incluse comme critère d'évaluation explicite et les compétences en documentation sont devenues un facteur dans le processus d'embauche. Au fur et à mesure que le CSD acquérait de l'expérience et comprenait mieux les capacités de la technologie du logiciel de groupe, les responsables ont introduit de manière opportuniste un changement dans la structure du département pour tirer davantage parti de ces capacités. Ce changement n'avait pas été prévu avant la mise en œuvre de l'ITSS, mais le recours croissant à l'ITSS et une appréciation des capacités de la technologie collaborative ont créé une opportunité pour le CSD de redistribuer les charges d'appels. En particulier, des niveaux de soutien "première ligne" et "deuxième ligne" ont été établis, des spécialistes juniors étant affectés à la première ligne et des spécialistes seniors à la deuxième ligne. Des partenariats ont été créés entre les spécialistes juniors moins expérimentés et les spécialistes seniors plus expérimentés. Les spécialistes de première ligne prenaient désormais tous les appels entrants, en résolvaient autant qu'ils le pouvaient, puis transféraient électroniquement les appels à leurs partenaires de deuxième ligne lorsqu'ils étaient surchargés ou avaient des appels particulièrement difficiles. En plus de traiter les appels qui leur étaient transférés, les spécialistes principaux devaient surveiller de manière proactive les progrès des appels de leurs partenaires de première ligne et fournir de l'aide au besoin. Alors que cette idée de partenariat était conceptuellement valable, elle s'est régulièrement effondrée dans la pratique. Les spécialistes débutants étaient souvent réticents à passer les appels, craignant que de tels transferts ne reflètent mal leur compétence ou qu'ils ne surchargent leurs partenaires plus expérimentés. Les spécialistes seniors, quant à eux, étaient généralement trop occupés à résoudre des incidents complexes pour passer beaucoup de temps à surveiller le statut ou les progrès des appels de leurs partenaires juniors. En réponse à cette rupture imprévue de l'idée de partenariat, les responsables de CSD ont introduit un autre changement structurel basé sur les opportunités. Ils ont créé un nouveau rôle, celui d'intermédiaire, qui a été rempli par un spécialiste senior dont le travail consistait à faire la médiation entre les première et deuxième lignes, en surveillant régulièrement les charges d'appels et les travaux en cours des spécialistes juniors, et en réattribuant dynamiquement les appels le cas échéant. Le nouveau rôle d'intermédiaire a servi de tampon entre les spécialistes juniors et seniors, facilitant le transfert des appels et soulageant les spécialistes seniors de la responsabilité de surveiller constamment leurs partenaires de première ligne. Avec ces changements structurels, ITSS a en fait changé la division du travail indifférenciée et fixe au sein du département en une distribution dynamique du travail reflétant différents niveaux d'expérience, divers domaines d'expertise et des charges de travail changeantes. En réponse à la nouvelle répartition du travail, les gestionnaires ont ajusté leurs critères d'évaluation pour refléter l'évolution des responsabilités et des rôles au sein de la DSC. Un autre changement qui a émergé au fil du temps a été un changement dans la nature de la collaboration au sein de la DSC, passant d'un mode de collaboration principalement réactif à un mode plus proactif. Puisque tous les spécialistes avaient maintenant accès à la base de données des appels en cours dans le service, ils ont commencé à Machine Translated by Google parcourez les appels des uns et des autres pour voir ceux sur lesquels ils pourraient fournir de l'aide. Plutôt que d'attendre qu'on leur demande s'ils avaient une solution à un problème particulier (c'est ainsi qu'ils avaient sollicité et reçu de l'aide dans le passé), les spécialistes parcouraient activement la base de données des appels à la recherche de problèmes pour lesquels ils pouvaient offrir de l'aide. Ce passage de l'assistance sollicitée à l'assistance non sollicitée a été facilité par les capacités de la technologie collaborative, la nature complexe du travail, les critères d'évaluation existants qui mettaient l'accent sur le travail d'équipe et la culture coopérative et collégiale de longue date au sein de la DSC. Considérez les commentaires des spécialistes suivants : "Tout le monde se rend compte que nous avons tous une certaine pièce du puzzle... J'ai peut­être un élément critique, et Jenny peut en avoir un autre. ... Et si nous travaillons tous séparément, nous n'arriverons jamais à résoudre le puzzle. Mais en travaillant tous ensemble, nous avons tout le puzzle" ; "Ici, je me fiche de qui s'attribue le mérite de mon travail... ce service d'assistance fonctionne bien parce que nous sommes une équipe, pas parce que nous sommes tous des individus" (Orlikowski, 1995). Les gestionnaires ont répondu à ce changement de pratiques de travail en ajustant les critères d'évaluation des spécialistes pour tenir compte spécifiquement de l'aide non sollicitée. Comme l'a expliqué un responsable : "Lorsque j'examine les incidents, je vois quelle aide les autres ont apportée, et cela me donne une autre indication de la qualité de leur travail d'équipe." Après environ un an d'utilisation de l'ITSS, le CSD a mis en œuvre deux autres changements organisationnels autour de la technologie du collecticiel. Ces deux éléments avaient été prévus dans la planification initiale de l'ITSS, bien que le moment exact de leur mise en œuvre n'ait pas été précisé. Tout d'abord, l'application ITSS a été installée dans trois bureaux d'assistance à l'étranger, avec des copies de toutes les bases de données ITSS répliquées régulièrement sur les quatre sites d'assistance (États­Unis, Royaume­Uni, Australie et Europe). Cela a fourni à tous les spécialistes du support une base de connaissances plus étendue sur laquelle rechercher des résolutions éventuellement utiles. L'utilisation d'ITSS dans tous les bureaux d'assistance a en outre permis aux spécialistes de transférer les appels entre les bureaux, créant essentiellement un service d'assistance mondial au sein de Zeta. Deuxièmement, le CSD a initié et financé le développement d'un certain nombre de systèmes de suivi des bogues qui ont été implémentés dans le groupware et déployés dans les départements de développement de produits, de gestion de produits et d'assurance qualité de Zeta. Ces applications de suivi des bogues, qui étaient calquées sur l'application ITSS, étaient reliées à ITSS et permettaient aux spécialistes de saisir tout bogue qu'ils avaient découvert dans leurs activités de résolution de problèmes directement dans le système de suivi des bogues du produit concerné. Auparavant, le signalement des bogues par le CSD aux autres départements se faisait manuellement, prenait plusieurs semaines et impliquait un minimum de communication. Avec les nouvelles applications de suivi des bogues et les liens vers ITSS, les spécialistes pouvaient également interroger directement l'état de bogues particuliers, et même modifier leur priorité si les appels des clients indiquaient qu'une telle escalade était nécessaire. Les spécialistes en particulier ont trouvé ce changement très précieux. Pour les autres départements, le lien avec ITSS a permis aux utilisateurs tels que les chefs de produits et les développeurs d'accéder aux enregistrements ITSS et de retracer les incidents particuliers qui avaient révélé certains bugs ou découvert certains problèmes d'utilisation. Seuls les développeurs avaient des réserves quant à l'introduction de l'application de suivi des bogues, réserves qui étaient associées aux contraintes de temps sévères dans lesquelles ils travaillaient pour produire de nouvelles versions des produits Zeta. En plus de l'amélioration de la coordination et de l'intégration réalisées avec d'autres départements et bureaux, le CSD a également réalisé d'autres innovations basées sur les opportunités et des changements émergents au sein de ses propres pratiques. Par exemple, à mesure que le nombre d'incidents dans le SSTI augmentait, certains des spécialistes principaux ont commencé à se rendre compte que l'information contenue dans le système pouvait être utilisée pour aider à former les nouveaux arrivants. En extrayant certains enregistrements de la base de données ITSS, ces spécialistes ont créé de manière opportuniste une base de données de formation d'échantillons de problèmes avec laquelle les spécialistes nouvellement embauchés pourraient travailler. En utilisant les capacités de communication de la technologie du logiciel de groupe, ces spécialistes seniors pourraient suivre les progrès de leurs stagiaires à travers la base de données d'échantillons et intervenir pour les éduquer si nécessaire. Comme l'a fait remarquer un spécialiste principal : « Nous pouvons donc en quelque sorte nous tenir au courant de leurs progrès. ... S'ils sont sur la mauvaise piste, nous pouvons les intercepter et leur dire : "Va vérifier ceci, regarde cela." Mais ce n'est pas comme si nous devions vraiment nous asseoir avec eux et revoir les choses. C'est en quelque sorte une chose interactive en ligne. » Grâce à ce nouveau mécanisme de formation, le temps nécessaire aux nouveaux spécialistes pour commencer à prendre les appels des clients est passé de huit semaines à environ cinq semaines. Un changement émergent réalisé pendant cette période concernait le contrôle d'accès. Un problème récurrent pour le Machine Translated by Google CSD était qui (le cas échéant) en dehors du CSD devrait avoir accès à la base de données ITSS avec ses informations d'appel client et la documentation des travaux en cours des spécialistes. Ce problème n'était pas prévu avant l'acquisition de la technologie. Alors que les responsables s'inquiétaient de savoir comment répondre à la demande croissante d'accès à ITSS à mesure que la base de données devenait plus précieuse et que son contenu se répandait dans toute l'entreprise, ils ont continué à traiter chaque demande d'accès au fur et à mesure qu'elle se présentait. Au fil du temps, ils avaient utilisé une variété de mécanismes de contrôle allant de l'octroi d'un accès limité à certaines personnes "de confiance", à la génération de rapports récapitulatifs d'informations ITSS sélectionnées pour d'autres et au refus de tout accès à d'autres encore. Comme l'a expliqué l'un des responsables, ce n'est qu'après un certain temps qu'ils se sont rendu compte que leurs diverses réponses ad hoc aux différentes demandes d'accès constituaient essentiellement un ensemble de règles et de procédures sur le contrôle d'accès. En répondant localement à une variété de demandes et de situations au fil du temps, une politique de contrôle d'accès implicite pour l'utilisation des ITSS avait évolué et émergé. Résumé de l'affaire Zeta Figure 2 représente le modèle de changement autour de la technologie collaborative suivi par Zeta dans son CSD. Parallèlement à l'introduction de la nouvelle technologie et au développement de l'application ITSS, le CSD a d'abord mis en œuvre certains changements organisationnels planifiés, élargissant le travail des spécialistes pour inclure la documentation des travaux en cours et ajustant le travail des gestionnaires pour tirer parti du réel ­Accès ponctuel aux informations sur la charge de travail. Ces changements ont été anticipés avant l'introduction de la nouvelle technologie. Alors que les spécialistes et les gestionnaires ont commencé à travailler de nouvelles façons avec la technologie, un certain nombre de changements sont apparus dans la pratique, tels que les spécialistes développant des normes pour déterminer la qualité et la valeur des résolutions antérieures, et les gestionnaires prêtant attention aux compétences de documentation dans les décisions d'embauche et d'évaluation. . S'appuyant sur ces changements anticipés et émergents, le CSD a introduit un ensemble de changements basés sur les opportunités, créant des partenariats de spécialistes junior­senior pour tirer parti de la base de données partagée et des capacités de communication de la technologie, puis ajoutant le nouveau rôle d'intermédiaire en réponse à les problèmes inattendus qui ont surgi autour du partenariat et de la réaffectation du travail. Ces changements n'étaient pas anticipés au départ, et ils n'ont pas simplement émergé spontanément en travaillant avec la nouvelle technologie. Au contraire, ils ont été conçus et mis en œuvre in situ et en réponse aux opportunités et aux problèmes qui se sont présentés au fur et à mesure que la CDD acquérait de l'expérience et développait une compréhension plus profonde de la nouvelle technologie et de son utilisation particulière. Ce processus de changement autour de la technologie du collecticiel s'est poursuivi tout au long de la deuxième année chez Zeta, lorsque certains changements organisationnels anticipés ont été suivis par des changements émergents et basés sur des opportunités associés à des événements en cours et à l'apprentissage et à l'expérience acquis en utilisant la nouvelle technologie dans la pratique. Dans l'ensemble, ce que nous voyons ici est une série itérative et continue de changements anticipés, émergents et basés sur les opportunités qui ont permis à Zeta d'apprendre de l'expérience pratique, de répondre aux résultats et capacités inattendus et d'adapter à la fois la technologie et l'organisation selon les besoins. En effet, le modèle de changement de Zeta passe par des changements organisationnels anticipés, émergents et basés sur les opportunités au fil du temps. C'est un modèle de changement qui reconnaît explicitement le caractère inévitable, la légitimité et la valeur de l'apprentissage continu et du changement dans la pratique. Conditions d'activation De toute évidence, certains aspects de la CSD et de l'organisation Zeta lui ont permis d'adopter efficacement un modèle de changement d'improvisation pour mettre en œuvre et utiliser la technologie du collecticiel. Nos recherches chez Zeta et d'autres entreprises suggèrent qu'au moins deux ensembles de conditions favorables sont essentiels : aligner les dimensions clés du processus de changement et consacrer des ressources pour fournir un soutien continu au processus de changement en cours. Nous examinerons chacun à son tour. Alignement des cotes de changement de clé Une influence importante sur l'efficacité de tout processus de changement est la relation d'interdépendance entre trois dimensions : la technologie, le contexte organisationnel (y compris la culture, Machine Translated by Google structure, rôles et responsabilités) et le modèle de changement utilisé pour gérer le changement (voir Figure 3). Idéalement, l'interaction entre ces trois dimensions est compatible ou, au minimum, non opposée. Premièrement, considérez la relation entre le modèle de changement et la technologie mise en œuvre. Lorsque la technologie a été conçue pour fonctionner comme une "boîte noire", permettant peu d'adaptation par les utilisateurs, une approche d'improvisation peut ne pas être plus efficace que l'approche traditionnelle de la mise en œuvre de la technologie. De même, lorsque la technologie est bien établie et que ses impacts sont raisonnablement bien compris, une approche traditionnelle de changement planifié peut être efficace. Cependant, lorsque la technologie mise en œuvre est nouvelle et sans précédent, et a en outre une nature évolutive et personnalisable, un modèle d'improvisation offrant aux organisations la flexibilité de s'adapter et d'apprendre par l'utilisation devient plus approprié. Tel est le cas, selon nous, avec les technologies collaboratives disponibles aujourd'hui. Deuxièmement, la relation entre le modèle de changement et le contexte organisationnel est également pertinente. Un modèle de changement flexible, bien que susceptible d'être problématique dans une culture rigide, axée sur le contrôle ou bureaucratique, est bien adapté à une culture plus informelle et coopérative telle que celle qui caractérise la SDC. Dans une autre étude (Gallivan et al., 1994), nous avons examiné l'adoption et la mise en œuvre réussies par l'organisation MidCo des outils CASE (Computer­Aided Software Engineering) au sein de son organisation SI. Alors que MidCo, une multinationale de produits chimiques dont le chiffre d'affaires s'élevait à plus de 1,5 milliard de dollars, était une organisation relativement traditionnelle à bien des égards, des aspects clés de sa culture ­ un engagement envers la gestion de la qualité totale, l'accent mis sur l'apprentissage organisationnel et l'autonomisation des employés, ainsi que ainsi qu'une orientation temporelle à long terme ­ étaient particulièrement compatibles avec le modèle d'improvisation utilisé pour gérer les changements organisationnels en cours autour de la nouvelle technologie de développement de logiciels. Enfin, il y a la relation importante entre la technologie et le contexte organisationnel. Chez Zeta, la culture coopérative et axée sur l'équipe du CSD était compatible avec la nature collaborative de la nouvelle technologie collaborative. En effet, la culture existante de CSD lui a permis de profiter de l'opportunité d'une meilleure collaboration offerte par la technologie collaborative. De plus, lorsque les rôles, les responsabilités et les critères d'évaluation existants sont devenus moins saillants, les gestionnaires de la DSC les ont élargis ou ajustés pour refléter les nouvelles utilisations de la technologie. Comparez ces efforts de changement à ceux d'Alpha, une entreprise de services professionnels qui a introduit la technologie de groupware Notes pour tirer parti du partage des connaissances et pour coordonner les activités distribuées (Orlikowski, 1992). Alors que le déploiement physique du groupware s'est développé très rapidement, les bénéfices attendus se sont réalisés beaucoup plus lentement. La clé de la réticence à utiliser les logiciels de groupe pour le partage des connaissances était une incompatibilité perçue entre la nature collaborative de la technologie et la nature individualiste et compétitive de l'organisation. Comme dans de nombreuses entreprises de services professionnels, Alpha a récompensé la performance individuelle plutôt que celle de l'équipe et a promu les employés via un ensemble de critères d'évaluation «up or out». Dans un tel environnement, le partage des connaissances via un réseau mondial de notes était considéré comme une menace pour le statut, la compétence distinctive et le pouvoir. Contrairement à Zeta, les responsables d'Alpha n'ont pas ajusté les politiques, les rôles, les incitations et les critères d'évaluation pour mieux aligner leur organisation sur l'utilisation prévue et les capacités de la technologie dans laquelle ils avaient investi. Consacrer des ressources pour un soutien continu Un processus de changement continu nécessite un soutien dédié au fil du temps pour adapter à la fois l'organisation et la technologie à l'évolution des conditions organisationnelles, des pratiques d'utilisation et des capacités technologiques. Le changement basé sur les opportunités, en particulier, dépend de la capacité de l'organisation à remarquer et à reconnaître les opportunités, les problèmes, les pannes et les résultats inattendus à mesure qu'ils surviennent. Cela nécessite une attention de la part des personnes appropriées de l'organisation pour suivre l'utilisation de la technologie au fil du temps et pour mettre en œuvre ou initier des ajustements organisationnels et/ou technologiques qui atténueront ou tireront parti des problèmes ou opportunités identifiés. Chez Zeta, ce sont les managers et les technologues qui ont principalement joué ce rôle, en l'intégrant à leurs autres responsabilités. Ainsi, par exemple, les managers ont adapté la structure de leur service en introduisant d'abord Machine Translated by Google partenariats ligne/deuxième ligne pour faciliter une division dynamique du travail, puis a procédé à de nouvelles adaptations en introduisant un rôle d'intermédiaire pour surmonter certaines difficultés imprévues associées au changement initial. De même, les technologues travaillant avec le CSD ont apporté des améliorations au système ITSS à mesure qu'ils réalisaient des moyens d'améliorer la facilité d'utilisation et le temps d'accès. L'engagement du CSD à remarquer les changements et à y répondre le cas échéant ne s'est pas arrêté après la mise en œuvre de la technologie. Les managers ont clairement compris que le processus de changement dans lequel ils s'étaient engagés avec l'utilisation du groupware était un processus continu, comme l'a noté un manager : "Nous avons ITSS depuis Je pense que c'est parce deux ans. Je suis surpris que l'enthousiasme ne soit pas parti. ... qu'il a été changé régulièrement... Savoir que [les changements vont être mis en œuvre vous donne envie d'y réfléchir et de continuer." Les changements continus autour de l'utilisation de la technologie collaborative nécessitent également des ajustements continus de la technologie elle­même à mesure que les utilisateurs apprennent et acquièrent de l'expérience avec les capacités de la nouvelle technologie et leurs utilisations au fil du temps. Sans un soutien technologique dédié pour mettre en œuvre ces adaptations et innovations, l'expérimentation et l'apprentissage continus en cours d'utilisation, essentiels à un modèle de changement improvisé, peuvent être bloqués ou contrecarrés. Chez Zeta, l'utilisation du groupware et de l'ITSS par le CSD était soutenue par un groupe technologique dédié. Initialement composé d'un développeur, ce groupe s'est développé au fil du temps à mesure que l'utilisation de la technologie se développait. Après deux ans d'utilisation de la technologie, le groupe comprenait quatre technologues à temps plein qui ont fourni un support technologique pour les différents systèmes qui avaient été déployés au sein de Zeta via la plate­forme Notes. Le groupe a également maintenu des liens forts avec tous ses utilisateurs grâce à des réunions et des échanges réguliers avec eux. Ce support technique dédié et continu garantissait que la technologie continuerait d'être mise à jour, ajustée et étendue, le cas échéant. La valeur d'un soutien continu pour permettre un changement organisationnel et technologique continu était tout aussi importante dans une autre organisation que nous avons étudiée, la division R&D d'une grande entreprise de fabrication japonaise (Orlikowski et al., 1995). Une équipe de développement de produits nouvellement formée au sein de la division R&D a installé sa propre technologie de logiciel de groupe, le système de nouvelles Usenet (un système de conférence informatique). Semblable à Zeta, l'utilisation par l'équipe de cette nouvelle technologie a également itéré parmi les changements anticipés, émergents et basés sur les opportunités au fil du temps. Ici, un petit groupe d'utilisateurs qui avaient déjà utilisé la technologie de collecticiel a pris la responsabilité de gérer et de soutenir son utilisation continue pour eux­ mêmes et leurs collègues. Ils ont suivi l'utilisation de la technologie et les événements du projet au fur et à mesure qu'ils se déroulaient, ont réagi de manière appropriée en ajustant les politiques de communication et les fonctionnalités technologiques, et ont apporté de manière proactive des modifications à l'utilisation du système de conférence par l'équipe pour tirer parti des opportunités au fur et à mesure qu'elles se présentaient. conclusion Mondial, réactif, en équipe, en réseau ­ tels sont les mots d'ordre des organisations des années 90. Alors que les managers repensent et réinventent les organisations avec une nouvelle image, beaucoup se tournent vers les technologies de l'information pour permettre des processus plus flexibles, un meilleur partage des connaissances et une intégration mondiale. Dans le même temps, mettre en œuvre efficacement les changements organisationnels associés à ces technologies reste difficile dans un environnement turbulent, complexe et incertain. Nous croyons qu'un facteur important contribuant à ces défis est l'écart croissant entre la façon dont les gens pensent au changement technologique et la façon dont ils le font réellement. Nous avons proposé ici que les hypothèses des gens sur le changement technologique et la façon dont il est censé se produire sont basées sur des modèles qui ne sont plus appropriés. Les modèles traditionnels de gestion du changement basé sur la technologie traitent le changement comme une série séquentielle d'étapes prédéfinies qui sont délimitées dans une période de temps spécifiée. Avec ces modèles comme guide, il est logique ­ comme le fait le navigateur européen ­ de définir un plan d'action en amont du changement et de suivre les événements par rapport au plan, en s'efforçant tout au long du changement de rester sur la bonne voie. Les déviations par rapport au cours prévu ­ le prévu par rapport au réel ­ nécessitent alors une explication, l'implication subtile (et parfois pas si subtile) étant qu'il y a eu un échec, une insuffisance dans la planification, qui a conduit à cette déviation. En effet, de nombreux mécanismes organisationnels tels que la budgétisation et la gestion des ressources Machine Translated by Google planification sont basées sur ces notions. Le problème est que le changement tel qu'il se produit réellement aujourd'hui ressemble davantage au voyage du navigateur Trukese, et les modèles et mécanismes les plus couramment utilisés pour penser et gérer le changement ne soutiennent pas efficacement l'expérience du changement dans la pratique. Dans cet article, nous avons proposé un modèle de changement d'improvisation comme une façon différente de penser à la gestion de l'introduction et de l'utilisation continue des technologies de l'information pour soutenir les structures et les processus plus flexibles, complexes et intégrés exigés par les organisations aujourd'hui. Contrairement aux modèles traditionnels de changement technologique, ce modèle d'improvisation reconnaît que le changement est généralement un processus continu composé d'opportunités et de défis qui ne sont pas nécessairement prévisibles au départ. Il définit un processus qui itère parmi trois types de changement ­ anticipé, émergent et basé sur les opportunités ­ et qui permet à l'organisation d'expérimenter et d'apprendre à mesure qu'elle utilise la technologie au fil du temps. Plus important encore, il offre une approche systématique permettant de comprendre et de mieux gérer les réalités du changement technologique dans les organisations d'aujourd'hui. Parce qu'un tel modèle nécessite un environnement flexible et réactif, son adoption implique que les managers renoncent à ce qui est souvent un paradigme implicite de "commande et contrôle" (Zuboff, 1995). Un modèle d'improvisation, cependant, n'est pas de l'anarchie et il ne s'agit pas non plus de « se débrouiller ». Nous n'insinuons pas que la planification est une activité inutile ou qui devrait être abandonnée. Nous suggérons plutôt qu'un plan est un guide plutôt qu'un plan directeur (Suchman, 1987), et que les écarts par rapport au plan, plutôt que d'être considérés comme un symptôme d'échec, doivent être attendus et activement gérés. Plutôt que de prédéfinir chaque étape à franchir puis de contrôler les événements en fonction du plan, l'idée est de créer un environnement qui facilite l'improvisation. Dans un tel environnement, la direction fournit, soutient et nourrit un ensemble d'attentes, de normes et de ressources qui guident le processus de changement en cours. Malone (1996) fait référence à un tel style de gestion en tant que "culture". Considérez à nouveau le groupe de jazz. Alors que chaque membre du groupe est libre d'improviser pendant la représentation, le résultat n'est généralement pas discordant. Elle est plutôt harmonieuse parce que chaque acteur opère dans un cadre global, se conforme à un ensemble partagé de valeurs et de normes, et a accès à un répertoire connu de règles et de ressources. De même, bien que de nombreux changements au CSD de Zeta n'aient pas été planifiés à l'avance, ils étaient compatibles avec les objectifs et les intentions généraux des membres du département, leurs normes communes et l'orientation de l'équipe, ainsi que les conceptions et les capacités de la technologie à portée de main. L'exécution efficace d'un modèle de changement improvisé nécessite également d'aligner la technologie et le contexte organisationnel sur le modèle de changement. Un tel alignement ne se produit pas automatiquement. Cela nécessite un examen et un ajustement explicites et continus, où et quand cela est nécessaire, de la technologie et de l'organisation. À ce titre, les mécanismes et les ressources alloués au soutien continu du processus de changement sont essentiels. Suivre et remarquer les événements et les problèmes au fur et à mesure qu'ils se déroulent est une responsabilité qui doit être détenue par les membres appropriés de l'organisation. Outre la responsabilité, ces membres de l'organisation ont besoin de l'autorité, de la crédibilité, de l'influence et des ressources nécessaires pour mettre en œuvre les changements en cours. La création de l'environnement, l'alignement de la technologie, du contexte et du modèle de changement, et la répartition des responsabilités et des ressources appropriées sont d'une importance cruciale pour l'utilisation efficace d'un modèle d'improvisation, d'autant plus qu'elles représentent un écart important (et donc difficile) par rapport à la pratique standard dans effet dans de nombreuses organisations aujourd'hui. Il est important de garder à l'esprit, cependant, qu'un modèle de changement improvisé ne s'appliquera pas à toutes les situations. Comme nous l'avons noté, il est plus approprié pour les technologies évolutives et personnalisables ou pour des changements complexes et sans précédent. De plus, comme l'a noté l'un de nos critiques, "le jazz n'est pas la 'tasse de thé' de tout le monde... certaines personnes sont incapables de jouer du jazz et encore moins capables d'écouter ce qu'elles considèrent comme du 'bruit'". Nous avons noté ci­dessus que certaines cultures ne soutiennent pas l'expérimentation et l'apprentissage. De ce fait, ils ne sont probablement pas réceptifs à un modèle d'improvisation, et sont moins Machine Translated by Google susceptible d'y réussir. Cependant, alors que ces organisations tentent de mettre en œuvre de nouvelles formes d'organisation, elles aussi peuvent trouver un modèle d'improvisation comme une approche particulièrement précieuse pour gérer le changement technologique au 21e siècle. Références Argyris, C. et Schon, DA Apprentissage organisationnel, Reading, MA : Addison Wesley, 1978. DeJean, D. et DeJean, SB Lotus Notes at Work, New York : Lotus Books : 1991. Gallivan, MJ, Hofman, JD et Orlikowski, WJ "Implementing Radical Change: Gradual Versus Rapid Pace", Actes de la quinzième Conférence internationale sur les systèmes d'information, Vancouver, Colombie­Britannique, Canada, 14­17 décembre 1994 : 325­339 . Kwon, TK et Zmud, RW « Unifying the Fragmented Models of Information Systems Implementation », dans RJ Boland Jr. et RA Hirschheim (Eds.) Critical Issues in Information Systems Research, New York : John Wiley and Sons, 1987 : 227­251 . Lewin, K. «Décision de groupe et changement social», dans Newcombe, E. et Harley, R. (Eds.) Lectures en psychologie sociale, New York: Henry Holt, 1952 : 459­473. Malone, TW, Lai, KY et Fry, C. "Experiments with OVAL : A Radically Tailorable Tool for Cooperative Work, Actes de la troisième conférence sur le travail coopératif assisté par ordinateur, Toronto, Canada, novembre 1992 : 289­297. Malone, TW Communication privée. 1996. McGrath, RG et MacMillan, IC « Planification axée sur la découverte », Harvard Business Review, 72, 1, 1995 : 44­54. Mintzberg, H. "La chute et l'essor de la planification stratégique", Harvard Business Review, 72, 1, 1994 : 107­114. Orlikowski, WJ "Apprendre à partir des notes : problèmes organisationnels dans la mise en œuvre du groupware" Actes de la troisième conférence sur le travail coopératif assisté par ordinateur, Toronto, novembre 1992 : 362­369. Orlikowski, WJ « Évoluer avec les notes : changement organisationnel autour de la technologie des logiciels de groupe », Sloan School of Management Working Paper #3823, MIT, Cambridge, MA, 1995. Orlikowski, WJ « Improviser la transformation organisationnelle au fil du temps : une perspective de changement situé », Recherche sur les systèmes d'information, 7, 1, 1996 : 63­92. Orlikowski WJ, Yates, J., Okamura, K. et Fujimoto, M. « Façonner la communication électronique : la métastructuration de la technologie utilisée », Organization Science, 6, 1995 : 423­444. Pettigrew, AM Le géant de l'éveil. Oxford, Royaume­Uni : Blackwell Publishers, 1985. Suchman, L. Plans et actions situées : le problème de la communication homme­machine. Cambridge, Royaume­Uni : Cambridge University Press, 1987. Zuboff, S. À l'ère de la machine intelligente, New York: Basic Books, 1988 Notes de bas de page [1] Toutes les technologies de logiciels de groupe ne sont pas flexibles et personnalisables (par exemple, les systèmes de messagerie électronique à fonction fixe). Nous ne nous intéressons ici qu'à ceux qui le sont (par exemple, Lotus Notes). Machine Translated by Google Les figures Figure 1 Figure 2 Machine Translated by Google Figure 3
