Cours de SI
Description
A N N E E U N I V E R S I TA I R E 2 0 0 5 / 2 0 0 6COURS DE SYSTÈMESD’INFORMATIONIUT d e T arbes U niversité Pa ul Sab atierLicence ATC Année 2005/2006P A T R IC K F E R R ÉII PARTIE LA MISE E N ŒUVRE D ES SYSTÈMES D’INFORMATION.........................................................................3C HAP ITRE 1: LA TECH NIQUE CL ASSIQUE DE MISE EN ŒUVRE DE S S I.................................................................................. 6Section 1 L’ étude p réalable.............................................................................................................................6Sous section 1 La décomposition en étapes .....................................................................................................6§1 Les différentes é tapes............................................................................................................................................. 6§2 Intérêts et l acunes de la dé composition en étapes................................................................................................... 6§3 La t endance à l’int égration..................................................................................................................................... 7Sous section 2 Les objectifs de l’étude p réalable............................................................................................8§1 Formuler l e problème à résoudre.......................................................... ...
Informations
| Publié par | Chiem |
| Nombre de lectures | 56 |
| Langue | Français |
Extrait
A N N E E U N I V E R S I T A I R E 2 0 0 5 / 2 0 0 6
C O U R S D E S Y S T È M E S D’INFORMATION
IUT de Tarbes Université Paul Sabatier Licence ATC
Année 2005/2006
P A T R I C K F E R R É
II PARTIE LA MISE EN ŒUVRE DES SYSTÈMES D’INFORMATION......................................................................... 3 CHAPITRE1: LA EUIQHNECT SSALCEUQI DE MISE EN EŒUVR DES................................................................6.......... IS........ Section 1 L’étude préalable............................................................................................................................. 6 Sous section 1 La décomposition en étapes..................................................................................................... 6 §1 Les différentes étapes.............................................................................................................................................6 §2 Intérêts et lacunes de la décomposition en étapes................................................................................................... 6 §3 La tendance à l’intégration..................................................................................................................................... 7 Sous section 2 Les objectifs de l’étude préalable............................................................................................ 8 §1 Formuler le problème à résoudre............................................................................................................................ 8 A) La formulation des besoins.....................................................................................................................................8 B) Poser correctement le problème à résoudre............................................................................................................. 8 §2 Définir un avant-projet de solution......................................................................................................................... 8 A) La praticabilité de la solution................................................................................................................................. 8 B) L’opportunité de l’automatisation.......................................................................................................................... 9 Sous section 3 Les techniques de l’étude préalable......................................................................................... 9 §1 L’organisation de l’étude préalable........................................................................................................................ 9 A) La responsabilité de l’étude.................................................................................................................................... 9 B) La planification de l’étude préalable..................................................................................................................... 10 §3 L’analyse de l’existant synonyme de documentation............................................................................................ 10 A) Le recueil des informations..................................................................................................................................11 B) La présentation des observations.......................................................................................................................... 13 §4 Le diagnostic de l’existant....................................................................................................................................14 Section 2: La réalisation de l’avant projet....................................................................................................17 §1 L’élaboration des solutions.......................................................................................................................17 A) Le cadre de solution............................................................................................................................................. 17 B) La construction de l’avant projet.......................................................................................................................... 19 §2 L’évaluation des solutions........................................................................................................................ 20 A) La praticabilité de la solution............................................................................................................................... 20 Section 3 Le dossier d’avant projet et le cahier des charges........................................................................ 22 §1 Le dossier d’avant projet...................................................................................................................................... 22 §2 Le cahier des charges (aspects juridiques)............................................................................................................ 22 §3 La fusion du dossier d’avant projet et du cahier des charges................................................................................ 23 CHAPITRE2 LES UESTECHNIQ DE EGPOTORAPYT ET DE L’TESAURULITI FINAL.....................................................................25 Section 1 La stratégie du prototypage........................................................................................................... 25 §1 Philosophie du prototypage.................................................................................................................................. 25 §2 Les techniques de la stratégie de prototypage....................................................................................................... 27 Section 2 L’informatique de l’utilisateur final...............................................................................................30 Sous section 1 Le contexte de développement de l’I.U.F...............................................................................30 §1 Le développement des outils Bureautique............................................................................................................ 30 §2 L’interrogation simplifiée et le développement des bases de données.................................................................. 31 §3 Le développement des progiciels: Les produits logiciels...................................................................................... 31 §4 Les langages dit de quatrième génération............................................................................................................. 31 §5 L’explosion de la micro-informatique..................................................................................................................32 Sous section 2 Conditions et limites de l’I.U.F..............................................................................................32 §1 L’utilisateur final est un gestionnaire informaticien................................................................................ 32 §2 Les limites de l’I.U.F............................................................................................................................................ 33 Sous section 3 Les principes affectés par le concept d’informatique de l’utilisateur final........................... 34 §1 L’organisation néo-taylorienne des systèmes d'information.................................................................................. 34 §2 La technique plus souple des Computers Personnel de l’I.U.F............................................................................. 35 §3 La modification de la relation agent / poste informatique..................................................................................... 35 §4 La modification des étapes de mise en œuvre....................................................................................................... 35 CHAPITRE3 LA CRISE DESMEDOHSÉT....................................................................................................................... 37 Section 1 Un état des lieux des méthodes traditionnelles..............................................................................37 §1 Des chiffres éloquents.......................................................................................................................................... 37 § 2 Une contradiction................................................................................................................................................ 37 § 3 Un mythe à comprendre et à gérer....................................................................................................................... 38 Section 2 Développer rapidement des solutions........................................................................................... 38 §2 Le développement de composants logiciels à l'aide de RAD.................................................................... 38 Section 3 Les modèles adéquats apparaissent............................................................................................... 39 §1 Des aménagements espérés................................................................................................................................... 39 §2 Des méthodes maintenant mieux adaptées............................................................................................................ 39 EN GUISE DE NOISCONCLU......................................................................................................................................... 40
II Partie La Mise en œuvre des Systèmes d’information
3
Cours de Système d’information (SéRéCom Iut de Tarbes) P. Ferré
4
Au terme de la première partie de ce polycopié ( traité en 2er année SeRéCom), nous disposons des concepts qui dominent l'étude des systèmes d'Information et partant leur mise en œuvre. Ces concepts de base constituent un cadre, utile, mais non « indispensable » s’il sagit de traiter d’une étude limitée aux techniques de Mise En Oeuvre des Systèmes d’information dans les organisations. Chose ce que nous allons maintenant étudier. Pour mieux situer ce que devient notre objet d'étude traitant maintenant plus des aspects "organisationnels" de l'automation dans les organisations, nous pouvons nous inspirer des titres d'ouvrages qui dominent la littérature existante. Ces derniers évoquent les façons diverses les méthodes de l'automatisation. Ainsi selon les ouvrages l'on trouve les titres évocateurs suivants: "La Mise en œuvre des Systèmes d'Information" qui évoque l'approche la plus générale. S'il est question de mettre l'accent sur les technologies de l'automation l'on évoque "La Conduite des projets d’automatisation de traitements". Enfin si l'objet d'étude relève plus particulièrement des aspects organisationnels l'on trouve comme intitulé "la Conception des systèmes d’information". Soit un corps commun d'idées et des gradations mettant en avant les aspects techniques ou ceux relevant de l'organisation de l'entreprise. Notons alors que les différents intitulés avancent toujours l’idée de l’utilisation de méthodes présentées comme nécessaires à l’étude et à la mise en œuvre des systèmes d'Information. Notons aussi que les contenus diffèrent selon l'intérêt, plus ou moins prononcée, porté aux technologies d'automatisation. A) Deux sous-entendus implicites 1°) La complexité: Les traitements et les problèmes liés à l’utilisation de l’information sont des problèmes complexes. Cette caractéristique invite à recourir à des modèles conceptuels auxquels se référer ou dit autrement à des méthodes adaptées. La théorie systémique se proposant de décrire les organisations comme étant des systèmes complexes susceptibles d'être modélisés. Les systèmes doivent donc pourvoir être disséqués pour être compris au plus secret de leur complexité. Ce n'est donc pas une moindre ambition, ni une tentative qui choisirait les chemins de la facilité. 2°) L'automatisation de tâches "intellectuelles": Les traitements étudiés ont pour objet des travaux intellectuels, qui concourent à la prise de décisions, gérées par les organisations. Cette caractéristique de l'objet d'étude est essentielle. Il ne s’agit pas de d'organiser le fonctionnement de machines ou l'automatisation des chaînes de production. Le domaine est plus "sensible" puisqu'il s'agit d’introduire des modifications touchant à la prise de décision. Ce, en confiant à des automates des travaux qui étaient et sont souvent considérés relever de l'intelligence humaine. La prise en compte de ces deux caractéristiques constitue le terrain d'investigations d’écoles qui proposent différentes méthodes. On distinguera pour aborder cette étude deux approches, nées de deux "courants de pensée". L'un qualifié de "classique" et l'autre présenté comme regroupant des techniques ou méthodes qualifiées d'alternatives. Nous notons à ce stade que les méthodes classiques (initiales), ont été élaborées pour des systèmes centralisés et ont du accepter la remise en cause de certains de leurs principes initiaux, dès l'apparition massive dans les bureaux de la micro informatique. B) Deux grands courants (ou écoles) 1°) L'approche classique Longtemps dominante cette dernière est une approche théorique qui se caractérise par un formalisme pointilleux et efficace. Au point que l'on peut dire qu'elle est dominée par une conception des systèmes d'information que l’on peut qualifier de "militaire". Pour une présentation introductive, on retiendra les caractéristiques suivantes. a) Un processus linéaire de mise en œuvre des systèmes d'Information: Des étapes très précises sont suivies et caractérisent l’approche classique. Le processus linéaire qui en découle est le suivant: * L’étude de l’existant: Qui consiste à relever minutieusement la structuration existante du système de traitement de l’information avant que ses traitements ne soient automatisés.
Cours de Système d’information (SéRéCom Iut de Tarbes) P. Ferré
5
* La collecte de l’information, très minutieuse: Elle se doit de localiser chaque flux à chaque poste de travail. Différents catalogues voient alors le jour et présentent de manière ordonnée le résultat de ce travail de type photographique. b) Une formalisation poussée des résultats de l'étape précédente: * Une présentation du système existant et son analyse critique. * Des propositions de solutions et de programmes. * Un cahier des charges prenant la forme d’un document qui a deux objectifs. Il détaille la demande de réalisation concrète à partir de l’analyse de l’existant, et il constitue le cadre juridique de réalisation. Le cahier des charges lie le demandeur et l’entreprise qui va implanter le système automatisé dans son organisation. c) Un processus basé sur des besoins supposés connus et stables: Partant de l’étude minutieuse de l’existant l’approche classique permet de dégager les besoins. C'est ainsi qu'un postulat important domine cette méthode. Les besoins peuvent être déterminés et sont considérés, pour un métier donné, être stables.Or ce relevé précis des besoins est adéquat à un temps t1, au début de l'étude, perd de sa valeur rapidement. Ainsi à un temps t2 les outils d’automatisation des traitements résolvent des besoins mais crée aussi de nouveaux besoins. L’approche classique, très précise dans ces résultats est confrontée à un problème d'évolutivité. Celle des logiciels, mais encore celle des procédures de gestion. 2°) La crise de la méthode classique Les méthodes que l'on peut qualifier d'alternatives, apparaissent au départ sans être vraiment et totalement en rupture d’avec l’approche dite classique. Elles posent cependant des principes et des propositions de modèles novateurs et intéressants. L’une de ces approches va jusqu'à avancer une affirmation assez osée mais qui n’est pas dénuée de fondements. L’affirmation, dans ses grandes lignes se pose en questionnement critique. En déclarant que les besoins sont difficilement connus et ne peuvent l'être, du fait même de la complexité des traitements. Et surtout de l’évolution "naturelle" des systèmes d’informations, qui ne peuvent être saisi en une vue statique. Parce que les organisations sont en perpétuelle transformation, les méthodes sont nécessairement limitées dans leur efficacité. Jusqu'au point d'affirmer que les besoins ne peuvent être recensés parce que trop mouvants. Toute prétention, à fixer comme sur un négatif photo, l'existant et à dégager les besoins, est en conséquence vouée à l’échec. Aussi c'est une pratique de découverte, au fur et à mesure de la réalisation des programmes, qui est proposée. Le bricolage, en lieu et place des méthodes, est même avancé comme étant la plus efficace des méthodes. Or cette affirmation, ne manque pas de bon sens comme nous pourrons le constater plus loin. L’on parle alors de méthodes ou de techniques de prototypage et on évoque le développement rapide d’application (R.A.D), les approches objets, et les systèmes d’information à base de composants(0). Des langages spécialisés permettant le développement de produits non finis, mais qui fonctionnent et que l’on peut adapter au fur et à mesure des besoins. Cependant et malgré la réalité des critiques avancées, la méthode classique conserve de réels avantages. Elle reste pertinente, au moins s'agissant de sa capacité à représenter les flux et les traitements dans une organisation. Aussi ne jetterons-nous pas à la poubelle trop rapidement les préceptes des modèles classiques. Cette seconde partie du cours sera donc consacrée aux méthodes concrètes de mise en œuvre en étudiant la méthode dominante "classique" pour mieux cerner et étudier les prolongements qualifiés "d'alternatifs" dont on essaiera de comprendre les points forts et novateurs.
0L'idée est la suivante, les métiers, y compris touchant à la décision, peuvent être partiellement réduits à des algorithmes plus ou moins complexes. L'on peut utiliser des composants métiers. Ces derniers peuvent être "manipulés", par des personnels qui n'ont pas la connaissance du métier, à condition qu'une machine soit capable de les assister dans la maîtrise ou l’utilisation de cette connaissance. Nous développerons ce point plus loin dans le cadre de cet enseignement.
Cours de Système d’information (SéRéCom Iut de Tarbes) P. Ferré
6
Chapitre 1: La technique classique de mise en œuvre des SI Dominante dans la littérature théorique et chez les praticiens, jusque dans les années 1980-90, l’approche classique utilise les concepts étudiés dans la première partie de ce cours. L’approche est donc systémique. Si d'autres approches se présentent comme plus souple et concurrentes, elles empruntent en fait de nombreuses techniques à l’approche classique. Il convient donc de bien situer le fait, que la méthode classique existe, a existé, et a été l'objet d'améliorations, fusse au prix d'une critique (les critiques qui sont du point de vue des sciences des actes constructifs et n'ont pas le sens que le vocable au sens courant sous-entend). Section 1 L’étude préalable L’étude préalable constitue la première phase et la plus importante de l’approche classique. Au terme de cette étude, un diagnostic est réalisé et une évaluation est mise en œuvre. L’avant projet qui en est issu constitue alors le cadre de conception de la solution informatisée. Pour aboutir à un tel résultat une succession d'étapes est proposée. C'est le respect de cette organisation précise des travaux à réaliser qui constitue sans doute l'une des qualités de l'approche classique. Dès cette décomposition, l'on se trouve être plongé dans la logique intrinsèque de l'approche classique. Sous section 1 La décomposition en étapes C’est la réalisation de la conduite linéaire de l’approche classique qui est évoquée à ce stade de travail et qu'un schéma peut traduire assez opportunément comme celui de la figure 32. §1 Les différentes étapes 1°) L’étude préalable stricto sensu Dans le cours de cette étape est étudiél’opportunité recourir àà une solution automatisée de traitement de l’information. Il s’agit de mesurer les atouts d’une telle automatisation. Lapraticabilité une seconde constitue préoccupation, tentant de répondre à la question: La solution automatisée est-elle réalisable au point de vue technique mais aussi au point de vu organisationnel? Soit à savoir si les techniques existent et si l’organisation supportera les changements induits. 2°) L’analyse fonctionnelle ou conception du projet On analyse l’insertion du projet dans l’organisation en étudiant la logique de la solution ou sa cohérence. Il s’agit d’isoler les travaux à automatiser et les postes de travail concernés. 3°) L’analyse organique ou développement du projet Cette étape est capitale. Il est question maintenant d’organiser les informations. Les fichiers sont liés, structurés, à l'aide de modèle du type "entité association". Ce résultat est la conséquence de l’étude affinée des données. Les traitements dégagés par l’étude préalable sont organisés en tenant compte de leur enchaînement. On tente de déterminer la suite logique des étapes d’un travail (soit les entrées, les traitements qui les affectent, et les sorties...). 4°) L’étape de programmation Les étapes d’analyse et les solutions dégagées sont, après contrôle, programmées pour aboutir à la phase finale et utilisable. Cette phase est supposée résoudre tous les besoins exprimés. En principe, à ce stade aucune surprise n’est possible. Il est en effet dans la logique de l’approche classique de considérer que tous les problèmes ont été localisés dans le cours des étapes précédentes. §2 Intérêts et lacunes de la décomposition en étapes 1°) La précision dans l’étude de l’existant L’approche classique se révèle d’une grande précision dans l’évaluation des besoins tels qu’ils ressortent du système d’information existant. L’étude détaillée des flux, la description minutieuse des travaux dans chaque station de l’organisation permet une vue "photographique" très détaillée. Au terme d’une telle approche l’on connaît très précisément les données, les documents circulants, les traitements. La solution peut alors être mise
Cours de Système d’information (SéRéCom Iut de Tarbes) P. Ferré
7
en œuvre avec un rendement de gestion de l’information très élevé. En particulier les bases de données, finement organisées, constituent l’un des résultats les plus convaincants de cette approche. 2°) Le caractère figé ou statique de l’analyse classique. Cependant, un premier risque apparaît consistant dans la reproduction des lacunes du système d’information existant. A trop se tenir au plus près des flux existants et des traitements réalisés manuellement par le passé, l'on risque de prendre pour argent comptant ce qui était des faiblesses, voir des erreurs de gestion du système. Une phase d’analyse critique est donc nécessaire. Plus risqué encore est le caractère figé des solutions obtenues à l’aide de l’approche classique. Ces dernières résolvent un problème à l’aide d’une solution organisant chaque poste de travail (ou stations) et chaque flux. On note qu'alors toute évolution du système se révèle très difficile à mettre en œuvre. L’évolution des outils logiciels et des phénomènes tels le développement de la micro-informatique exigent des marges de manœuvre plus souples. Il faudra donc intégrer les correctifs possibles. Mais ces derniers se révèlent contradictoires d’avec la logique même de l’approche classique qui ne tolère pas les retours en arrière (ni même le feed-back, dont on connaît maintenant l'intérêt). L’on doit recourir à des approches concurrentes comme celle du prototypage ou de l’informatique dite de l’utilisateur final. Malgré ces faiblesses l’approche classique doit être étudiée parce qu’elle se trouve être, dans le cadre de systèmes d’informations qui restent, à ce jour, très structurés voire centralisés, la meilleure approche descriptive des systèmes. La précision de type "quasi-militaire" des systèmes mis en œuvre à l’aide de l’approche classique présente de véritables avantages. §3 La tendance à l’intégration Il s’agit là d'une importante caractéristique qui illustre la combinaison d'atouts et de faiblesse de l’approche classique. Les stations ou services concourant aux objectifs de l’entreprise, dépendent fortement d’un système centralisé. L’on évoque alors la notion de structure maître / esclave. Où les utilisateurs doivent travailler sur des terminaux strictement configurés. Si les besoins exigent l’accès à des données existantes mais pour lesquelles les postes clients n’ont pas été "préparés", l'utilisateur n'a alors aucune possibilité d'accès. Les postes sont comme l'expression l'évoque des postes de travail esclaves ou client, selon les terminologies. 1°) La notion d’intégration des systèmes d'information Les organisations ayant recouru, de plus en plus, à l’automatisation de leur système d’information. Elles le font avec une conséquence importante consistant à centraliser - physiquement - leurs conteneurs de données. L’accès aux données communes, regroupées dans des bases de données interconnectées, par plusieurs utilisateurs en même temps définit la notion d’intégration. On y remarque une rigueur des procédures d’accès et des contrôles très poussés. Nous pouvons sans grand risque d'erreur considérer que la notion d’intégration est synonyme de centralisation. C’est cette dernière qui va être contestée, pour devenir relative avec l’apparition des grands réseaux, parmi lesquels l’Internet. A l’inverse des réseaux classiques - limités à une organisation particulière -, l’Internet permet, parce qu’il n’est pas centralisé (personne n’en est propriétaire) un accès à des données, variées parfois contradictoires mais ayant l’intérêt de la variété. Hors un tel type de réseau ne rentre pas dans le cadre des modélisations classiques des systèmes d’information. 2°) L’intégration et l’approche classique L’étude du partage de "ressources" informationnelles, par le biais de flux d’informations se révèle tout à fait cohérente d’avec l’approche classique. Mais, un problème apparaît, les stations, qui doivent accéder aux données centralisées dans les conteneurs centraux que sont les bases de données, ont leurs propres besoins. Ces derniers n’ont pas nécessairement été prévus, souvent pour une raison simple, ils n’existaient pas lors de la mise en place du Système d'information.
Cours de Système d’information (SéRéCom Iut de Tarbes) P. Ferré
8
On doit alors relever que l’approche classique, initialement figée et prônant une intégration poussée, tentera divers correctifs. Y compris en empruntant certains techniques aux approches alternatives. Ce, au moins pour prendre en compte l’évolution rapide des outils informatiques, et des possibilités que ces outils font naître. Les stations "slaves" ou esclave ayant une certaine tendance à redevenir maître de leur travail. L'approche classique devra prendre en compte ce fait nouveau. Sous section 2 Les objectifs de l’étude préalable §1 Formuler le problème à résoudre A) La formulation des besoins C’est partant d’un besoin que les applications informatiques sont réalisées. Ce besoin peut cependant être formulé de manière très différente. Il peut consister dans la demande précise d’un utilisateur ou résulter du constat de la nécessité d'accélérer les travaux répétitifs etc. Quelle que soit la cause initiale du recours à une solution automatisé, le besoin est toujours formulé. Ce faisant, il est plus ou moins bien explicité. Il peut être soit incorrectement formulé ou exprimé de manière trop générale ou - à l'inverse - de manière trop restrictive. Cette diversité des lacunes d'expressions des besoins motive la mise en place de technique de recueil des désirata. Chose que propose l'approche classique. Exemple: Le responsable d’un service de gestion évoque le besoin d’améliorer à l’aide d’un traitement automatisé son suivi de relance clients. Après examen l’étude peut révéler que plus que le problème des relances sur impayés, c’est l’ensemble de la gestion de la facturation qui est inadéquate c’est à dire non adapté aux besoins présents de l’organisation. B) Poser correctement le problème à résoudre Les besoins plus ou moins bien formulé, exigent l'intervention d'un agent que l'on qualifiera pour les besoins de la cause d'interprète. En son travail il opérera une traduction des besoins formulés. La traduction des besoins aboutira à une formalisation appelée à rendre accessible à tous les responsables la description la plus précise que possible des besoins de l'organisation. Ceux-ci se répartissent alors en besoins effectivement exprimés ou déduits au terme d'un audit. Rappelons qu'une organisation est constituée d'agents humains qui ne manifesteront pas les mêmes points de vue relativement à l'intérêt de l'automatisation de leur travail quotidien. §2 Définir un avant-projet de solution Une fois dégagée la nature exacte du problème à résoudre et des besoins à satisfaire l’étape suivante a pour but de dégager une orientation générale de solution. Il s'agit au début d'une ébauche, qui devra par la suite être reprise de manière détaillée lors de la conception du projet. Deux points important doivent à ce stage retenir l’attention. Ces points sont deux préalables à la réalisation du projet d’automatisation. A) La praticabilité de la solution On se pose la question de savoir s'il est possible d’utiliser des outils automatisés pour résoudre le problème posé? L’on emploie parfois le terme d’étude de faisabilité pour évoquer ce questionnement essentiel. Cette étude consiste à recenser les possibilités techniques existantes. A ce stade l’on traite le problème des contraintes matérielles et humaines à l’emploi d’outils automatisé. En particulier l’on étudie l’impact de l’automatisation sur l’organisation. La praticabilité met à jour deux "variantes" importantes de cette notion. 1°) La praticabilité technique Elle nécessite l’intervention de techniciens extérieurs qui déterminent si le matériel existant sur le marché permet l’automatisation des traitements envisagés. Concrètement il s’agit d’examiner si les techniques existent. 2°) La praticabilité organisationnelle Combiné au problème précédent le problème de la praticabilité organisationnelle doit prendre en compte plusieurs sous problèmes. Il est alors question de recenser tout ce qui peut relever des aspects organisationnels. L’introduction de nouveaux outils modifie les travaux des agents, leur manière de travailler mais aussi les compétences. Pour ces raisons, c'est un point délicat, source parfois de conflits qu'il faudra résoudre.
Cours de Système d’information (SéRéCom Iut de Tarbes) P. Ferré
9
B) L’opportunité de l’automatisation La praticabilité d’une solution est une chose son opportunité économique en est une autre. L'analyste ici doit s’attacher à apprécier en terme de coûts l’intérêt d’une solution automatisée. Le calcul est en théorie simple et consiste à comparer le rapport coûts/avantages des solutions proposées. En pratique cette évaluation est délicate. La mesure des avantages d’un système automatisé dans un domaine aussi incertain que celui des technologies de l'automation ne permet pas l’appréciation des avantages futurs souvent inconnus et imprévisibles. Le calcul prévisionnel devrait pouvoir intégrer des qualités non chiffrables, d'autant qu'elles ne se manifesteront que plus tard. Sous section 3 Les techniques de l’étude préalable En premier lieu, les techniques classiques de l’étude préalable organisent les étapes de l'étude. Ainsi les équipes de travail sont mises en place, la planification de l’étude dans le temps est fixée, les responsabilités de chaque agent sont déterminées. Il en est de même concernant les tâches à réaliser en commençant par l’étude de l’existant. §1 L’organisation de l’étude préalable L’organisation de l’étude préalable donne une assez bonne image du caractère linéaire et formalisé de l’approche classique. Avant que ne soit étudiée la moindre donnée, le plus petit traitement du système à automatiser la première étape consiste à mettre en place l’équipe de travail, avec ses responsables et un programme de travail très précis. Apparaît ici l’importance révélée par les méthodes systémiques nées autour des grands projets de gestion des structures complexes durant la seconde guerre mondiale. On situe à cette époque le développement des théories systémiques. C’est dire qu’un projet qui touche à l’organisation, à ses règles et habitudes de gestion, implique un rôle des agents de l’organisation fixé très précisément. Parce qu'il s'agit de gérer l'information coproduite par les utilisateurs, l'implication des agents est essentielle. Ces derniers pouvant bloquer tout ou partie de la dynamique mise en place. Cela complique la mécanique hiérarchique d'une organisation; et rappelle qu'on ne peut pas travailler sur l'information comme sur une quelconque ressource. Aussi avant toute chose est mise en place une équipe, c'est la première étape de l’étude préalable. En notant que l'importance d'un groupe de pilotage est inversement proportionnelle à la taille de l’organisation concernée. A) La responsabilité de l’étude La taille de l’organisation est un critère de la détermination du nombre de participants à l’équipe responsable du projet. Mais aussi, dans le cadre de petites unités de travail, la tendance à la participation du maximum d’agents sera très prononcée. Entre autres éléments encourageant de telles pratiques, les techniques de management du personnel de type participatives. Cette participation se révélant, souvent symbolique lorsqu'elle inclut le maximum d’agents y compris les agents de saisie. En pratique une certaine démagogie sociale ne manque pas de régner dans la constitution de l’équipe responsable lorsqu’on interpelle les utilisateurs, souvent conviés à un rôle de simples figurants. En fait sous l’appellation de groupe de pilotage et d’un groupe d’étude sont regroupés un ou plusieurs représentants de la direction générale, les directeurs de fonctions, et un panel d’utilisateurs à différents niveaux hiérarchiques. La participation active des utilisateurs sera considérée comme un plus. 1°) Le groupe de pilotage: Comme son nom l’indique, il dirige l’étude. C’est lui qui définit les grandes orientations et qui tranchera entre les différentes propositions. 2°) Le groupe d’étude: Il a un rôle plus technique d’analyse des problèmes et de proposition de solutions. C’est dans ce groupe que l’on trouve les informaticiens et les utilisateurs qui maîtrisent les travaux non automatisés soumis à l’étude préalable. 3°) Le conseil extérieur (éventuel): Extérieur à l’organisation il intervient dans la plupart des cas en sa qualité de spécialiste. Même si l’organisation possède un service informatique. C’est souvent le conseil extérieur qui sera
© 2010-2024 YouScribe