Systmes dinformation de gestion pour les IMF : Cadre dvaluation

Andrew Mainhart Development Alternatives, Inc.

Novembre 1999

Ce travail a t financ par lUSAID (Bureau des programmes globaux, Centre pour la croissance conomique et le dveloppement agricole, Bureau du dveloppement des microentreprises) par lintermdiaire dun financement accord au projet Microenterprise Best Practices (MBP) dans le cadre du contrat PCE-C-00-96-90004-00.

Microenterprise Best Practices

Development Alternatives, Inc.

Andrew Mainhart, spcialiste senior du dveloppement, travaille chez Development Alternatives Inc. (DAI) depuis 1998. Il a fourni un appui conseil technique la CARD Bank aux Philippines, la Banque agricole des coopratives en Thalande, et ACLEDA au Cambodge. M. Mainhart a appuy plusieurs projets de lUSAID dans le monde, dont le Programme pour la relance de lconomie en transition en Hati, le projet Newbiznet en Ukraine et le projet TFED en Tanzanie. Il a galement travaill en Indonsie chez Bank Rakyat Indonesia avec lquipe en charge des technologies de linformation pour tudier les systmes dinformation de la banque. M. Mainhart dtient un Bachelor of Science (licence) en management industriel de lUniversit Carnegie Mellon. Avant dentrer dans le domaine de la microfinance, il a travaill comme consultant chez Andersen Consulting, mettant en uvre des projets dinstallation de logiciels grande chelle pour les entreprises du classement Fortune 500 et comme responsable de la division Technologies de linformation chez Bell Atlantic, une grande socit de tlcommunications amricaine.

Microenterprise Best Practices

Development Alternatives, Inc.

i REMERCIEMENTS

Lauteur remercie pour leurs commentaires prcieux Robin Young, Matthew Buzby, Nhu-An Tran, John Magill, et Zan Northrip de Development Alternatives, Inc. ; Anicca Jansen du Bureau de dveloppement des microentreprises de lUSAID ; David Ferrand de DFID (Department for International Development) ; Xavier Reille de Catholic Relief Services ; Brigit Helms du CGAP, et Tony Sheldon, Todd Girvin, Nick Ramsing et Ruth Goodwin. Lauteur souhaite galement remercier pour leur aide tous ceux qui ont particip au sminaire MBP sur les systmes dinformation en microfinance qui sest tenu le 8 mars 1999 Washington. Il exprime sa profonde gratitude tous ceux qui ont offert leur aide par leurs commentaires ou leurs conseils. Ce document ne reflte que le point de vue de lauteur ; toute omission ou erreur ventuelle ne peut tre attribue qu lui seul.

Microenterprise Best Practices

Development Alternatives, Inc.

ii TABLE DES MATIERES

CHAPITRE UN ....................................................................................................................................... 1 INTRODUCTION .................................................................................................................................... 1 CONTEXTE .............................................................................................................................................................1 OBJECTIF ...............................................................................................................................................................1 METHODOLOGIE ....................................................................................................................................................2 UTILISATION ..........................................................................................................................................................2 STRUCTURE DU DOCUMENT ...................................................................................................................................4

CHAPITRE DEUX .................................................................................................................................. 5 LE CADRE ............................................................................................................................................. 5 HIERARCHIE DES CATEGORIES .............................................................................................................................5 MATRICE DE RECHERCHE .....................................................................................................................................6 METHODE DE NOTATION .......................................................................................................................................6

CHAPITRE TROIS ................................................................................................................................. 8 CATGORIE 1 : FONCTIONNALITE ET EXTENSIBILITE................................................................... 8

CHAPITRE QUATRE ........................................................................................................................... 17 CATGORIE 2 : CONDITIONS DUTILISATION ................................................................................ 17

CHAPITRE CINQ ................................................................................................................................. 21 CATGORIE 3 : PRSENTATION DE LINFORMATION FINANCIRE........................................... 21

CHAPITRE SIX..................................................................................................................................... 25 CATGORIE 4 : NORMES ET CONFORMIT ................................................................................... 25

CHAPITRE SEPT ................................................................................................................................. 27 CATGORIE 5 : ADMINISTRATION ET SUPPORT........................................................................... 27

CHAPITRE HUIT .................................................................................................................................. 33 CATGORIE 6 : SPECIFICATIONS ET QUALITE TECHNIQUES .................................................... 33

CHAPITRE NEUF................................................................................................................................. 37 CATGORIE 7 : COT ........................................................................................................................ 37

ANNEXE A

GRILLE DE NOTATION ............................................................................................................1

Microenterprise Best Practices

Development Alternatives, Inc.

CHAPITRE UN INTRODUCTION
CONTEXTE
Au cours des 5 10 dernires annes, les institutions de microfinance (IMF) ont port un intrt croissant aux systmes dinformation, et en particulier aux systmes dinformation de gestion (SIG). Alors quoprateurs et bailleurs de fonds prenaient conscience du besoin pour les institutions financires formelles et informelles de grer de gros volumes de donnes, lincitation amliorer le traitement et la comprhension des donnes sest faite plus forte. Linformation est au cur de la microfinance. Que leur traitement soit manuel ou informatique, les IMF grent un grand nombre de donnes essentielles leur activit, depuis les informations de base sur la clientle jusquaux analyses dtailles des performances du portefeuille. Ces donnes doivent tre stockes, traites et, plus important, prsentes de manire pertinente aux utilisateurs de faon ce quils puissent prendre des dcisions informes. Un bon systme dinformation doit simplement jouer ce rle : agir comme un canal grce auquel des donnes brutes sont transformes en information utile et exploitable. Un bon systme dinformation est un outil ncessaire la bonne gestion dune institution. Cette affirmation soulve toutefois deux questions : Quest-ce quun bon systme dinformation ? Comment dtermine-t-on quun systme est bon ? Il y a une rponse simple ces deux questions : tout systme qui rpond aux besoins dune institution de manire efficiente et permet lorganisation de crotre sans gnrer de problmes ou dinefficacits est un bon systme. A lvidence cette rponse simple nest pas terriblement utile. Cest pour cette raison que le besoin dun cadre dvaluation se fait fortement sentir, notamment si lon considre le relatif manque de connaissances sur les systmes dinformation et le dveloppement de logiciels dans le domaine de la microfinance.

OBJECTIF
Lobjectif premier de ce document est de prsenter un mcanisme danalyse des systmes dinformation, applicable la fois aux logiciels achets cl en main et aux systmes dvelopps en interne. Ce cadre dvaluation des SIG offre au secteur un outil permettant de dterminer la qualit dun systme dinformation. Le cadre est trs souple et peut tre utilis par les IMF, les bailleurs de fonds et les autres acteurs externes, ainsi que par les dveloppeurs de systmes. ! Les IMF peuvent lutiliser pour valuer les systmes disponibles la vente au cours de leur recherche de solution. ! Les IMF peuvent aussi lutiliser pour valuer la qualit de leur systme en place (achet ou dvelopp sur mesure) et les aider identifier les points damlioration. ! Les entits externes peuvent lutiliser pour valuer des systmes commercialiss ou dvelopps en interne pour appuyer une IMF, identifier des alternatives ou dans le cadre dune valuation institutionnelle.

Microenterprise Best Practices

Development Alternatives, Inc.

2
! Les professionnels du dveloppement de logiciel et de la planification des systmes dinformation peuvent lutiliser pour crer de meilleurs systmes.

Pour rpondre aux besoins de diffrents utilisateurs, un certain nombre de gnralits ont t rappeles dans le cadre. En consquence, les facteurs spcifiques une organisation ou un vendeur donn (par exemple, stade de dveloppement, perspectives de croissance, nombre et complexit des produits) devront tre ajouts au cas par cas. Ce cadre est un outil, ce qui signifie que lvaluateur doit comprendre la situation dans laquelle il sinscrit et appliquer le cadre de la faon la plus logique et la plus efficiente.

METHODOLOGIE
Partant des normes du secteur informatique, notamment publies par DataPro, GartnerGroup et Patricia Seybold Group,1 ainsi que de lexprience des professionnels du logiciel, ce document dfinit une srie de catgories qui peuvent, et devraient, tre utilises pour valuer tout systme dinformation utilis en microfinance. Pour sassurer que ce cadre prenait bien compte les spcificits de la microfinance en particulier la diversit des modles institutionnels de microfinance, et les produits et services lauteur sest appuy sur le manuel du CGAP sur les Systmes dinformation de gestion pour les institutions de microfinance et a consult de nombreux professionnels de la microfinance.

UTILISATION
Toute organisation dcidant dutiliser ce cadre pour raliser lvaluation de systmes doit tre avoir lesprit plusieurs facteurs importants : Composition de lquipe. Lquipe dvaluation doit comprendre au moins deux personnes. La taille de lquipe dpendra du niveau de lvaluation ainsi que de lexprience et des comptences des membres de lquipe. Les facteurs prendre en compte lors de la formation de cette quipe sont les suivants :
#

Expertise en technologie de linformation. Ce cadre a t rdig dans une optique de simplification du monde souvent compliqu des systmes informatiques. Cependant, comme pour tout domaine technique, une connaissance de base du sujet est ncessaire. Un membre au moins de lquipe dvaluation doit avoir une connaissance des ordinateurs et des logiciels, en particulier du dveloppement et du support logiciel. Une bonne comprhension du processus standard de dveloppement de logiciel (comme celui dcrit dans le manuel CGAP Systmes dinformation de gestion pour les IMF) et des architectures de linformation est essentielle la performance de ce type dvaluation.

Ces organisations publient des rapports dtaills sur diffrents types de logiciels informatiques, depuis les systmes dexploitation jusquaux logiciels bancaires en passant par les systmes de gestion de bases de donnes. Les spcialistes en technologies de linformation se rfrent habituellement ces sources pour la slection de logiciels appropris un environnement technique et/ou fonctionnel donn. Gnralement, ces rapports fournissent des analyses approfondies qualitatives et quantitatives rpondant une large gamme de normes et spcifications du secteur. Development Alternatives, Inc.

Microenterprise Best Practices

3
#

Expertise en microfinance. Etant donn que ces valuations sont ralises au sein dinstitutions de microfinance, un membre au moins de lquipe dvaluation doit possder une expertise en microfinance. Par ailleurs, une connaissance gnrale des principes comptables et financiers est une condition minimale pour raliser toute valuation dun systme financier.

Expertise institutionnelle. En cas dvaluation dun systme utilis dans une institution donne, lquipe doit comprendre un reprsentant de linstitution. Cette personne doit avoir une bonne connaissance des oprations de lIMF et peut remplacer le membre dquipe apportant une expertise en microfinance. Si linstitution est dote dun responsable systme expriment, lquipe peut ntre compose que de membres de lIMF.

Consultation du personnel cl. Les valuateurs auront besoin de rencontrer la fois les utilisateurs et les dveloppeurs du systme.
#

Dans le cas de lvaluation dun systme dvelopp en interne, les valuateurs doivent disposer de tout le temps ncessaire pour discuter du systme avec la direction et le personnel dappui technique, ainsi quavec les oprateurs de terrain, comme les guichetiers et les agents de crdit. Pour lvaluation de systmes commercialiss, lquipe dvaluation doit rencontrer le vendeur, notamment la direction et lassistance technique. Les visites sur site sont idales pour ce type dvaluation. Lquipe dvaluation doit toujours visiter au moins une organisation utilisant le systme et sentretenir avec les utilisateurs et le personnel technique de cette organisation.

Information dtaille sur lorganisation. Avant dentreprendre ltude des systmes dinformation, lquipe dvaluation doit avoir une bonne comprhension des processus daffaires de lIMF. Cette condition pralable est valable aussi bien pour une IMF ralisant lvaluation de logiciels commerciaux, ou de ses propres systmes, que pour une quipe dvaluation externe travaillant sur le systme interne dune IMF. Lquipe dvaluation (interne ou externe) devra travailler en troite collaboration avec le personnel oprationnel de lIMF pour comprendre les processus et la mthodologie de lIMF, ainsi que les ressources humaines, les zones gographiques dimplantation, et plus important, les objectifs futurs et les plans de croissance. Lquipe dvaluation doit se procurer de la documentation sur linstitution, notamment les organigrammes, le plan stratgique et le plan de dveloppement, les projections de croissance, les structures et procdures oprationnelles, les descriptions de produits et les descriptions de postes. Documentation du systme. Lquipe doit avoir accs tous les manuels (comme les manuels utilisateur et les guides dadministration), rapports, crans (fentres), et chronologie des oprations (versions, sauvegardes, etc.). Information dtaille sur le systme. Lquipe dvaluation aura besoin dinformations supplmentaires qui ne sont habituellement pas disponibles dans la documentation du systme. Ces informations, numres ci-dessous, sont plus techniques et doivent aider les valuateurs approfondir leur niveau de comprhension du systme :
#

Information sur la base de donnes. Lorsque cest possible, les valuateurs doivent obtenir une copie de la structure de la base de donnes (cest--dire sous quelle forme tableaux, colonnes, lignes, etc. les donnes sont stockes) que lon trouve habituellement dans un modle de
Development Alternatives, Inc.

Microenterprise Best Practices

4
donnes. Sil nexiste pas de modle de donnes formel, une impression de la structure de la base de donnes devrait suffire (la diffrence majeure est quun modle de donnes met en vidence les liens entre diffrentes informations, qui sont particulirement importants en terme de performance et de flexibilit).
#

Dmonstration. Lorsque cest possible, lquipe doit se procurer une version de dmonstration du logiciel. Indpendamment de cela, lvaluateur doit toujours avoir accs une version totalement fonctionnelle du systme. Code source. Laccs au code source2 et la base de donnes (ainsi quaux donnes qui y sont stockes) nest pas indispensable mais il est trs recommand, notamment pour qui souhaite approfondir lanalyse. Sachez que de nombreux vendeurs et mme certaines institutions seront trs rticents devant cette demande, donc prparez-vous ce type de raction. Encore une fois, laccs au code source nest pas une obligation mais peut tre trs utile lquipe dvaluation. Test. Pour dterminer si les calculs effectus par le systme sont exacts, il est utile de saisir des donnes relles de lIMF et de comparer les calculs avec les rsultats attendus. Dans ce cas, laccs la base de donnes est essentiel.

Visite sur site. Pour raliser une valuation dtaille, une quipe de deux personnes aura besoin dau moins trois cinq jours sur site, en fonction de la complexit du systme et du niveau dexprience des membres de lquipe. Prvoir un deux jours de plus dans le cas de ltude dun logiciel commercial ncessitant des visites sur site. Bien entendu, lvaluateur aura galement besoin de temps pour rdiger le rapport. Lquipe ayant tudier un gros volume dinformations au cours de lvaluation, le mieux est de demander obtenir la documentation dcrite plus haut lavance. La rapidit et lefficacit avec laquelle ces informations seront fournies aux valuateurs (notamment les informations gnres par le systme ou lies au systme, comme les rapports et les guides utilisateur) peuvent tre un indicateur de la comptence des utilisateurs ou de la qualit du systme.

STRUCTURE DU DOCUMENT
La suite de ce document dcrit le cadre proprement dit. Le cadre a t divis en catgories distinctes. Chaque catgorie a t son tour subdivise en plusieurs thmes, qui sont dfinis dans une matrice de recherche. La matrice de recherche dcrit chaque catgorie et les thmes (et sous-thmes) correspondants laide dune dfinition de la catgorie et du thme, de critres de mesure et dune mthode de notation.
2

Lors de la cration dune application logicielle, les programmateurs informatiques utilisent des instructions spcifiques rdiges en langage informatique pour indiquer lordinateur ce quil doit faire et comment il doit fonctionner. Il existe beaucoup de langages informatiques diffrents sur le march aujourdhui, notamment C, C++, Visual Basic et Delphi. Lensemble des instructions dune application donne est appele code source . Laccs au code source permet lvaluateur danalyser en profondeur la logique et la qualit dune application.

Microenterprise Best Practices

Development Alternatives, Inc.

CHAPITRE DEUX LE CADRE

Une liste hirarchise des catgories du cadre et des thmes et sous-thmes associs est fournie cidessous pour rfrence. Une description complte de chaque catgorie est donne dans la matrice de recherche qui suit, dans laquelle chaque catgorie est dfinie et argumente par des informations approfondies sur chaque thme et sous-thme. La matrice de recherche est loutil oprationnel de base du cadre.
Tableau 1 : Hirarchie des catgories
Fonctionnalit et extensibilit Pertinence, cohrence et intgration fonctionnelles - Comptabilit - Suivi du portefeuille - Suivi des dpts - Systme dinformation clientle Extensibilit et croissance institutionnelle Flexibilit - Centr sur le client / centr sur les comptes - Types dinstitution - Mthodologies de crdit - Type dintrt sur les crdits - Types de comptes dpargne et de dpt - Types dintrts sur les dpts - Types de remboursements - Frquence des remboursements - Multiples agences ou rgions - Langues multiples - Monnaies multiples Conditions dutilisation Facilit dutilisation et convivialit Interface utilisateur Prsentation de linformation financire Rapports Gnration des rapports Normes et conformit Normes et rigueur comptables Conformit aux rglementations du gouvernement et des superviseurs Administration et support Scurit Sauvegarde et rcupration Tolrance aux erreurs et robustesse Traitement des fins de priode Infrastructure du support et maintenance Contrle de version et stratgie de mise niveau Spcifications et qualit techniques Technologie et architecture Performance Traitement des nombres et dates Cot Tarification et cots

! !

! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

Chapitre deux Le cadre

6 MATRICE DE RECHERCHE
La matrice prsente partir du chapitre Trois est organise en catgories. Chaque catgorie correspond un grand domaine dvaluation du systme dinformation. Les catgories sont constitues de groupements logiques de diffrents thmes renvoyant la qualit fondamentale dun systme. Chaque catgorie est prsente ci-dessous ainsi que les thmes et sous-thmes correspondants. A lintrieur dune catgorie, chaque thme est dclin en trois colonnes : thme, dfinition et critres de mesure. Une colonne supplmentaire est prvue pour les commentaires ou notations de lvaluateur : ! Thme (ou sous-thme) : nom du thme ou sous-thme. Un sous-thme est indiqu par une flche # place avant le nom, et le nom du thme apparent est indiqu entre parenthses en dessous du sous-thme. Dfinition : brve dfinition du thme ou sous-thme. La dfinition est de nature descriptive et doit fournir suffisamment dinformations lutilisateur gnral de cette matrice pour comprendre ce quest le thme et quelles questions ou problmes il renvoie. Critres de mesure : types dlments ou de questions tudier lors de lvaluation dun systme sur un thme donn. Les critres de mesure indiqus pour chaque thme ne sont que des suggestions. Des efforts ont t faits pour identifier les critres principaux dvaluation pour un thme donn ; cependant, tant donn la nature diverse des systmes informatiques et des institutions de microfinance, les utilisateurs de cet outil dvaluation devront dterminer partir de leur environnement quel ensemble de critres est le plus adapt. Notation/commentaires : colonne vierge permettant lquipe dvaluation de noter ses commentaires et les notes attribues aux thmes et sous-thmes suivant les instructions donnes ci-dessous. Une feuille de notation est en outre fournie en annexe 1 pour aider lquipe dvaluation dterminer les pondrations et comptabiliser les notes.

METHODE DE NOTATION
Chaque thme ou sous-thme reoit une note allant de 1 5, cinq tant la plus forte. Pour chaque thme ou sous-thme, la note est dtermine en utilisant la dfinition et les critres de mesure correspondants comme repres. Il est important de noter que le cadre donne peu de dtails sur la faon dvaluer chaque point, partant du principe quune quipe dote dune expertise suffisante saura utiliser ses connaissances pour effectuer sa notation. Pour tout thme comportant des sous-thmes, la notation du thme principal doit tre une moyenne des notes attribues aux sous-thmes correspondants. Par exemple, le thme pertinence, cohrence et intgration fonctionnelles comporte quatre sous-thmes. La notation globale de ce thme correspondrait la moyenne de ces quatre notes. Bien entendu, cette notation est trs subjective et les valuateurs pourront souhaiter ajuster la notation globale en scartant de la simple moyenne des notes des sous-thmes.

Chapitre deux Le cadre

7
Dans ce cas, les valuateurs devront apporter un commentaire expliquant la raison de lajustement.3 Les systmes dvelopps sur mesure ncessiteront une technique lgrement diffrente de celle applique aux systmes commerciaux. Par exemple, lvaluation dun systme interne doit prendre en considration la pertinence de ce systme la lumire du stade de dveloppement de linstitution de microfinance, de lorientation stratgique, de lchelle, de la complexit et de la croissance projete. A de nombreux gards, les systmes commerciaux doivent rpondre des normes suprieures parce quils sont censs tre applicables une gamme plus importante dorganisations et denvironnements. Ce cadre tant un outil analytique, cest aux valuateurs que revient la responsabilit de dterminer la meilleure mthode dapplication du cadre une situation donne. Par exemple, certains thmes ne sappliquant pas toutes les IMF (monnaies multiples, langues diffrentes, etc.), il ne sera pas utile de mesurer la performance du logiciel sur ces thmes dans certains cas. Avant de procder la notation, lquipe dvaluation doit classer les critres par ordre de priorit et leur attribuer des pondrations. Par exemple, beaucoup dIMF considrent que laccessibilit et la qualit du support technique sont essentielles. Beaucoup sont tombes dans le pige consistant acheter un systme riche en fonctionnalits mais assorti dun support technique dfaillant ou dpourvu de support technique local. Cette situation peut savrer encore pire que labsence de systme.

Ce cadre ne donne pas de mthode de notation globale dun systme mais une mthode de notation par thme. Lvaluateur peut tenter de dterminer une notation pour chaque catgorie en prenant une moyenne, pondre ou non, des thmes correspondants, mais cela nest pas ncessairement recommand ni indispensable.

Chapitre deux Le cadre

CHAPITRE TROIS CATGORIE 1 : FONCTIONNALITE ET EXTENSIBILITE

Description : Mesure le degr auquel un logiciel rpond aux besoins de diffrents types de programmes de microfinance et dtermine sil a la capacit daccompagner la croissance et lexpansion dune institution de microfinance qui volue et augmente son nombre de fonctions et de clients. A un deuxime niveau, cette catgorie mesure la richesse des fonctionnalits dun programme, notamment par rapport aux types dinstitution et de mthodologie quil peut traiter. Lvaluation de cette catgorie doit prendre en compte la fois les fonctions front-office et back-office. La principale difficult que la microfinance impose au dveloppeur de logiciel est la complexit due sa grande diversit. Les systmes financiers en eux-mmes sont dj difficiles dvelopper. La microfinance ajoute encore cette difficult. A lintrieur du champ de la microfinance, il existe par exemple de nombreuses mthodologies de crdit diffrentes, comme les caisses villageoises, les groupes solidaires et le crdit individuel. Il existe galement beaucoup de modles institutionnels, comme les coopratives de crdit, les organisations non gouvernementales (ONG) et les banques (du plus informel au plus formel et du plus petit au plus grand). En outre, il existe autant de mthodes de calcul des intrts et des remboursements que de produits de prt offerts. Pour compliquer le tout, ces diffrences peuvent coexister au sein de la mme organisation. Bien entendu, toutes ces organisations oprent dans des environnements sociaux, politiques, conomiques, rglementaires et lgaux trs divers de par le monde. Ajoutez cela les monnaies, les langues et les obligations de publication de linformation et vous commencerez avoir une ide des difficults lies la cration dune application de qualit qui rponde aux besoins dune organisation, sans parler de plusieurs. Lquipe dvaluation doit prendre en compte cette complexit au moment de complter cette section du cadre.

Thmes :

Pertinence, cohrence et intgration fonctionnelles ; Extensibilit et croissance institutionnelle ; Flexibilit.

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

Thme Pertinence, cohrence et intgration fonctionnelles

Dfinition Les fonctions du systme rpondent aux besoins de lentreprise de manire adapte. Lintgration renvoie la facilit avec laquelle les diffrentes composantes du systme peuvent communiquer entre elles, permettant ainsi le partage des donnes et rduisant la ncessit de saisies multiples (saisie des mmes donnes dans diffrentes parties du systme). Capacit du logiciel assurer une gamme complte dactivits de comptabilit.

Critres de mesure (* cf. sous-thmes pour plus de dtails) ! Fonctions de comptabilit* ! Capacit de suivi du portefeuille* ! Fonctions de suivi de lpargne/des dpts* ! Fonctions de suivi de linformation clientle* ! Intgration des systmes ! Suivi des activits non financires (impact, services de dveloppement dentreprise, etc.)

Notation/Commentaires

# Progiciel de comptabilit (Pertinence, cohrence )

! !

! ! ! !

Intgr avec le systme de suivi du portefeuille et de lpargne ou autonome4 Niveau dintgration : direct (les changements apports au systme de suivi de lpargne et/ou du portefeuille sont immdiatement rpercuts sur les comptes) ou indirect (progiciel de comptabilit spar, ncessitant une actualisation priodique des donnes comptables) Plan comptable complet, cohrent, souple et adaptable par lutilisateur (nombre de chiffres, niveaux et formats) Suivi de la trsorerie, des produits et des charges par source ou centre de cot/profit (bailleur, compte, agence, produit, etc.) en plus du suivi consolid de linformation. Capacit raliser une analyse cot/rentabilit par produit, agence/rgion, client, etc. Comptabilit de caisse vs. dengagement si c. dengagement, traitement adquat des produits recevoir.

La question de savoir sil est prfrable davoir un systme intgr est largement dbattu dans le secteur de la microfinance. Lquipe dvaluation doit pralablement dterminer si lintgration du systme est importante dans le contexte spcifique de lvaluation.

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

10
Thme Dfinition ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Critres de mesure Dotations aux provisions et provisions pour crances douteuses Grand livre Balances Autorise la saisie de produits ou charges hors portefeuille ou lis aux dpts Gamme complte de rapports financiers standards (bilan, compte de rsultat, tableau de flux de trsorerie, etc.) Suivi et allocation des frais gnraux Fonctions de gestion bilantielle Module de gestion des salaires Module de gestion des immobilisations Fonctions de trsorerie Intgr avec le systme comptable, le systme de suivi des dpts, et/ou le systme dinformation clientle Autorise lajout ou la modification de produits de prt Donnes historiques sur les produits Gestion des dpts obligatoires (lie au suivi des dpts) et capacit bloquer laccs lpargne obligatoire le cas chant Lien de lpargne obligatoire avec les crdits ou ladhsion Suivi des garanties (montaires et non montaires) Suivi des garants et nombre de garants par crdit Identification et suivi des garanties de groupe Information spcifique aux agents de crdit Mcanismes appropris de classement par anciennet du portefeuille Informe les utilisateurs de problmes potentiels (impays, trsorerie, productivit, etc.) Fonctions de gestion des impays Mthodologie de calcul des impays Traitement des remboursements anticips, en retard, partiels, et en excdent Fonctions de scoring Fonctions avances telles que cartes de crdit ou guichet automatique Notation/Commentaires

# Suivi du portefeuille (Pertinence, cohrence )

Capacit du logiciel suivre et grer le portefeuille de crdits.

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

11
Thme # Suivi des dpts (Pertinence, cohrence ) Dfinition Capacit du logiciel grer les comptes de dpt. Critres de mesure Intgr avec le systme de comptabilit, le systme de suivi du portefeuille et/ou le systme dinformation clientle Autorise lajout ou la modification de types de dpts Donnes historiques sur les produits Dpts libres (avec suivi de linformation sur lpargne obligatoire lie au suivi du portefeuille) Autorise diffrents types de comptes Fonctions avances telles que guichet automatique, virements, cartes puce Fonction de retenue des impts la source Traitement des comptes inactifs Identification des bnficiaires en cas de dcs ou de handicap Option pour la gestion des comptes communs Bonnes fonctions de recherche Conserve les informations sur la clientle telles que nom, situation de famille, ge, sexe, adresse (domicile et entreprise) et type dactivit, ainsi que donnes dimpact Suivi des clients diffrents niveaux (individuel, groupe, centre, caisse villageoise, etc.) Capacit conserver des informations sur les groupes et/ou les caisses villageoises Fonctions de suivi du comportement des clients c.--d. situation et historique des crdits et de lpargne (sources externes ou internes) Donnes historiques sur les clients Donnes agrges sur les clients (par rgion, zone, activit conomique, agent de crdit, etc.) Capacit de suivi des clients diffrents stades du processus Suivi des informations sur les non-clients, notamment sur les garants Fonctionnalit autorisant le transfert de comptes (dun compte obligatoire un compte libre ou vice-versa, dun lieu gographique un autre, etc.) Identification des doubls ventuels (c.--d. double saisie des clients) Modules capables de prendre en compte de nouveaux produits et services (par ex. dpt terme, cartes de crdit, crdits Notation/Commentaires

! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

# Systme dinformation clientle (Pertinence, cohrence )

Capacit du logiciel suivre et conserver les informations sur la clientle.

Extensibilit et croissance

Capacit du systme soutenir la croissance

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

12
Thme institutionnelle Dfinition horizontale et verticale de linstitution. Renvoie principalement lextensibilit du systme. Critres de mesure hypothcaires, lignes de crdit et virements, en plus des services de microfinance standards) ! Peut accompagner lorganisation dans un processus de transformation en institution financire formelle (rapports, fonctions de trsorerie, etc.) ! Nombre de terminaux pouvant tre efficacement supports (avec des dlais de rponse raisonnables) ! Nombre de clients pouvant tre traits avec des dlais de rponse raisonnables (* cf. sous-thmes pour plus de dtails) ! Supporte une perspective centre sur le client ou centre sur les comptes* ! Supporte diffrents types dinstitution* ! Supporte plusieurs mthodologies* ! Supporte diffrents calculs des intrts sur les crdits* ! Supporte diffrents calculs des intrts sur les dpts* ! Supporte plusieurs types de remboursement* ! Supporte diffrentes frquences de remboursement* ! Supporte plusieurs agences ou rgions* ! Supporte plusieurs langues* ! Supporte plusieurs monnaies* Notation/Commentaires

Flexibilit

Le logiciel est considr comme flexible lorsquil peut tre facilement modifi pour rpondre un nouveau besoin ou une modification des besoins de lentreprise. La flexibilit renvoie galement ladaptabilit dun systme diffrents types dentreprise ou de structure organisationnelle. Les adaptations ou modifications peuvent tre des changements apports au programme lui-mme (c.--d. au code) ou aux paramtres de configuration du systme dinformation. La flexibilit dun systme renvoie aussi la facilit avec laquelle des lments importants (produits, suivi des informations telles que bailleurs, sexe, type dentreprise, etc.) peuvent tre ajouts, modifis ou supprims. La flexibilit pose fondamentalement la question

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

13
Thme # Centr sur clients / centr sur comptes (Flexibilit) Dfinition du degr dextensibilit et de configurabilit dun systme. Les logiciels de cette nature peuvent tre centrs soit sur les clients, soit sur les comptes. Cette nuance simple peut dterminer le degr de flexibilit car un systme centr sur les clients est habituellement plus flexible quun systme centr sur les comptes. Dans le premier cas, les comptes sont associs un client. Dans le second, les clients sont associs un compte. Types dinstitution pour lesquels le systme a t conu ou quil pourrait supporter avec un minimum de modifications. Critres de mesure ! ! ! Notation/Commentaires

Permet un client de possder plus dun compte et plus dun type de compte (dpt, crdit, etc.) Permet le suivi et la conservation de donnes clientle telles que coordonnes, sexe, situation matrimoniale, activit, etc.) Permet larchivage de donnes dtailles sur chaque compte, comme le type de compte, lemploi des fonds, le montant, etc.

# Types dinstitution (Flexibilit)

! ! ! ! ! ! ! !

Banques multiservices Banques services limits Coopratives dpargne et de crdit Institutions de microfinance SARL Fondations ou trusts Autres Ne traite quune seule mthodologie de crdit ou peut grer plusieurs mthodologies simultanment

# Mthodologies de crdit (Flexibilit)

Types dapproches du microcrdit que le systme peut traiter ou pourrait traiter avec un minimum de modifications.

Les mthodologies de crdit les plus courantes sont : - Crdit des clients individuels - Crdit individuel des groupes solidaires - Crdit de groupe des groupes solidaires - Crdit individuel des caisses villageoises - Crdit de groupe des caisses villageoises - Autre

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

14
Thme # Types dintrts sur les crdits (Flexibilit) Dfinition Types de calcul des intrts que le systme peut traiter ou pourrait traiter avec un minimum de modifications. Critres de mesure Constant Dgressif Dduit du montant du prt Intrt capitalis Taux variable Taux progressif Commissions et frais Pnalits de retard Autres (dfini par utilisateur, etc.) Epargne sur livret (avec ou sans livret) Dpts terme (i.e. certificats de dpt) Epargne de groupe Primes dassurance de groupe Epargne informelle de groupe Dpts vue Compte courant rmunr Comptes courants Du jour du dpt au jour du retrait Solde quotidien minimum Solde mensuel minimum Solde trimestriel minimum Solde quotidien moyen Solde mensuel moyen Autre (dfini par utilisateur, etc.) Prts terme avec remboursements constants Prts terme avec principal constant Remboursements irrguliers Remboursement unique Remboursement in fine Slection des dates de remboursement initiales et suivantes Autre (dfini par utilisateur, etc.) Notation/Commentaires

# Types de comptes dpargne et de dpt (Flexibilit)

Types de comptes dpargne que le systme peut traiter ou pourrait traiter avec un minimum de modifications.

# Types dintrts sur les dpts (Flexibilit)

Types dintrts que le systme peut traiter ou pourrait traiter avec un minimum de modifications.

! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

# Types de remboursement (Flexibilit)

Capacit du logiciel grer diffrents calendriers de remboursement ainsi que les changements ou mises jour des calendriers. La facilit avec laquelle le systme peut tre modifi pour grer de nouveaux types de remboursements doit aussi tre tudie.

Mthodes de remboursement : ! Liquide (en diffrentes monnaies le cas chant) ! Chque

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

15
Thme Dfinition ! ! ! ! Carte de crdit Carte puce Mandat postal Autre Critres de mesure Notation/Commentaires

# Frquence des remboursements (Flexibilit)

Capacit du logiciel traiter des remboursements frquents ainsi que des remboursements standards ; facilit avec laquelle le systme peut tre modifi pour traiter diffrentes frquences de remboursement.

Modification spciale des remboursements : ! Autorise la suspension des pnalits ! Autorise lajournement des remboursements du prt ! Autorise les priodes de grce ! Autorise le refinancement (nouveau calcul des montants de remboursement) du prt Frquence de remboursement traite : ! Quotidienne ! Hebdomadaire ! Bi-hebdomadaire ! Bi-mensuelle ! Toutes les 4 semaines ! Mensuelle ! Autre (dfini par utilisateur, etc.) Nombre de jours (ou semaines) dans lanne : ! 365 ! 360 ! 332 ! 50 semaines ! Autre Remboursements anormaux : ! Pr-remboursements ! Remboursements en retard ! Remboursements infrieurs au montant prvu ! Remboursements suprieurs au montant prvu ! Mcanismes de sparation de linformation par bureau ! Mcanismes permettant dagrger les donnes au niveau du bureau (donnes en ligne ou stockes puis transfres, etc.) ! Prsentation de linformation financire par bureau ou par zone ! Frquence des mises jour au sige ou au bureau de la zone ! Virement bancaire ou transfert de compte (intra- ou inter-)

# Multiples agences ou rgions (Flexibilit)

Capacit du logiciel grer plusieurs bureaux, que ce soit au niveau dune agence ou dune rgion. Rapidit avec laquelle le systme peut tre mis jour pour grer plusieurs

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

16
Thme Dfinition agences ou rgions ou de nouveaux points de distribution. Le logiciel peut-il grer plusieurs langues ou pourrait-il le faire avec un minimum de modifications ? Critres de mesure Notation/Commentaires

# Langues multiples (Flexibilit)

! ! ! ! !

# Monnaies multiples (Flexibilit)

Le logiciel peut-il grer plusieurs monnaies ou pourrait-il le faire avec un minimum de modifications ?

! ! ! !

Traite la langue locale (si langue crite) Peut traiter les langues sur une base utilisateur Plusieurs langues simultanment Tous les messages saffichent dans la langue choisie Toutes les informations portes lcran saffichent dans la langue choisie Le traitement de plusieurs langues ncessite une reprogrammation (instructions dans le code) ou est intrinsque au systme (la langue est paramtre) Traite la monnaie locale et les monnaies trangres Autorise les remboursements et dcaissements en diffrentes monnaies Supporte les fonctions de calcul de la position de change Supporte les fonctions de maintien de la valeur des comptes et dautres fonctions de rduction des risques lis linflation

Chapitre troisCatgorie 1 : Fonctionnalit et extensibilit

17

CHAPITRE QUATRE CATGORIE 2 : CONDITIONS DUTILISATION

Description : Evalue dans quelle mesure linterface utilisateur du logiciel aide les utilisateurs raliser leurs tches de manire efficace et efficiente, en rduisant au maximum les risques derreur. Prend en compte lexistence et le degr dutilit de la documentation utilisateur, des aides la navigation, de laide en ligne et des messages de guidage. Lvaluation doit consister en une check-list des aspects cls concernant linterface utilisateur et une valuation qualitative de la facilit dutilisation. Lun des meilleurs moyens de se faire une ide des conditions dutilisation et de la satisfaction des utilisateurs dun logiciel est de raliser une tude clientle. Une enqute consommateur doit donc tre mene pour dterminer comment les diffrents utilisateurs valuent le logiciel. Une tude clientle est un outil essentiel qui doit permettre de rpondre aux questions suivantes : ! ! ! ! ! ! ! Thmes : Qui est lutilisateur ? (intitul de poste, responsabilit, ge, ducation et formation, depuis quand et quelle frquence utilise-t-il le systme, etc.) Comment le logiciel aide-t-il les utilisateurs faire leur travail ? Quest-ce que les utilisateurs apprcient dans le systme ? Pourquoi ? Les utilisateurs trouvent-ils que le logiciel est facile utiliser ? Pourquoi ? Quest-ce que les utilisateurs napprcient pas dans le systme ? Pourquoi ? Quest-ce que le systme pourrait proposer dautre pour amliorer lefficacit globale et la satisfaction dans le travail ? Evaluation globale du systme par les utilisateurs

Facilit dutilisation et convivialit ; Interface utilisateur

Chapitre quatreCatgorie 2: Conditions dutilisation

19

Thme Facilit dutilisation et convivialit

Dfinition Capacit de lutilisateur raliser facilement et efficacement les tches ncessaires sans erreur. Lun des facteurs essentiels prendre en compte lors de la mise en uvre dun nouveau systme dinformation est la facilit avec laquelle les utilisateurs et le personnel administratif peuvent comprendre le systme et apprendre sen servir. La facilit dutilisation dun systme est dterminante ; elle a un impact sur les besoins en formation, la frquence des erreurs dutilisation et la motivation utiliser le systme. La facilit dutilisation svalue essentiellement travers linterface utilisateur. Linterface utilisateur dsigne les crans et formats par lintermdiaire desquels lutilisateur interagit avec le systme.

! ! ! ! ! !

Critres de mesure Ampleur de la formation requise pour les utilisateurs, qui sen charge ? O et comment les utilisateurs seront-ils forms ? Est-ce pratique ou perturbateur par rapport aux activits courantes de lIMF ? Qualit de la documentation destine aux utilisateurs Utilit de laide en ligne (dtail, approfondissement des sujets, hyperliens, etc.) Simplicit des oprations Facilit de correction des erreurs Rsistance du programme (plantage, panne, etc.) aux erreurs ou fausses manuvres des utilisateurs Messages de guidage pour la correction derreurs

Notation/Commentaires

Interface utilisateur

! ! ! ! ! ! !

Interface utilisateur graphique ou texte (par ex. Windows vs. DOS) Aspect extrieur, organisation et logique des crans et menus Les crans senchanent de faon logique et cohrente Linformation affiche est approprie chaque niveau ou type dutilisateur Mcanisme pour la saisie de donnes en masse Cohrence de la langue et phrasologie dans lensemble du systme Messages derreur comprhensibles par lutilisateur (pas de langage trop technique)

Chapitre cinqCatgorie 3 : Prsentation de linformation financire

20
Thme Dfinition ! ! ! Critres de mesure Utilisation logique et cohrente de la couleur pour aider lutilisateur lorsque cest possible Accs clavier et souris pour toutes les fonctions principales Conformit aux normes gnrales des platesformes (Microsoft pour PCs, etc.) Notation/Commentaires

Chapitre cinqCatgorie 3 : Prsentation de linformation financire

21

CHAPITRE CINQ CATGORIE 3 : PRSENTATION DE LINFORMATION FINANCIRE

Description : Examine dans quelle mesure les rapports gnrs couvrent les besoins de gestion et les besoins oprationnels, et value lexactitude des informations prsentes et lefficacit visuelle de ces rapports. Dtermine si les utilisateurs peuvent modifier les rapports existants ou crer de nouveaux rapports eux-mmes, et si le systme permet linstitution dexporter des donnes vers dautres tableurs pour utilisation ultrieure, ou si les donnes doivent tre ressaisies la main. Lvaluation consiste comparer la liste des rapports disponibles et les facilits de personnalisation des rapports avec une liste standard des principaux rapports, et valuer de manire qualitative lorganisation des rapports et lefficacit de leur prsentation. Rapports ; Gnration des rapports

Thmes :

Chapitre cinqCatgorie 3 : Prsentation de linformation financire

23

Thme Rapports

Dfinition Pertinence et exactitude des rapports standards produits par le systme. Facilit dutilisation des diffrents rapports.

Critres de mesure Gnral : ! Rapports suggrs par le CGAP ! Rapports standards et formats de rapports du Micro-banking Bulletin ! Options de prsentation de linformation financire : consolide et ventile ! Formats de rapports modifiables par lutilisateur ! Rapports adapts au public vis (direction, oprations, superviseurs, etc.) ! Formats de rapports clairs et lisibles ! Options de prsentation de linformation financire : possibilit de comparer budget et rel Rapports de gestion : ! Synthse des rsultats cls ! Projections des flux de trsorerie ! Performance des agences et des agents de crdit Rapports oprationnels : ! Chiffres quotidiens ! Rapports quotidiens sur les impays ! Rapports sur la qualit du portefeuille Rapports financiers : ! Balance ! Rapports quotidiens des livres auxiliaires ! Rapports quotidiens sur les transactions ! Etats financiers mensuels, trimestriels et annuels ! Ratios et tendances ! Calculs clairs et corrects des ratios et indicateurs

Notation/Commentaires

Chapitre cinqCatgorie 3 : Prsentation de linformation financire

24
Thme Dfinition ! ! Critres de mesure Piste de vrification Retraitements au titre de linflation et des subventions Notation/Commentaires

Gnration des rapports

Mcanisme de cration des rapports. Le systme fournit-il des rapports standards ( prenregistrs ) et permetil lutilisateur de gnrer des rapports supplmentaires sans assistance technique de la part du distributeur du logiciel ?

Rapports sur la clientle : ! Etats ! Soldes ! Demandes ! Gnration des rapports par lots ! Gnration des rapports sur demande ! Rapports prenregistrs ! Rapports dfinis par lutilisateur ! Outil de gnration des rapports (Crystal, etc.) ! Les informations contenues dans les rapports peuvent tre transfres dans un fichier excutable par un logiciel standard de traitement de texte ou un tableur. ! Besoins en termes dimprimante et de taille de papier ! Rapports gnrs frquemment et utiles au public vis

Chapitre cinqCatgorie 3 : Prsentation de linformation financire

25

CHAPITRE SIX CATGORIE 4 : NORMES ET CONFORMIT

Description : Etudie dans quelle mesure le logiciel est conforme aux normes et rglementations du secteur, du gouvernement et des instances de supervision. Tout systme dot de fonctions de comptabilit doit tre examin de faon vrifier la conformit aux principes comptables gnralement admis (PCGA) et aux normes internationales de comptabilit (NIC). En outre, tout systme doit satisfaire aux rglementations fixes par les organisations de supervision locales, rgionales et nationales. La croissance du secteur de la microfinance et la tendance linstitutionnalisation des IMF rend le respect des normes rglementaires de plus en plus important. Normes et rigueur comptables ; Conformit aux rglementations du gouvernement et des superviseurs

Thmes :

Chapitre sixCatgorie 4 : Normes et conformit

26

Thme Normes et rigueur comptables

Dfinition Il sagit de vrifier si la partie comptabilit du logiciel est conforme aux normes gnralement admises et traite les comptes dune manire saine et cohrente.

! ! ! ! ! ! ! ! !

Conformit aux rglementations du gouvernement et des superviseurs

Les activits de nombreuses institutions de microfinance sont soumises aux rglementations du gouvernement et des organes de supervision. Lobjectif est ici de dterminer si le logiciel respecte les obligations et rglementations.

! ! ! !

Critres de mesure Le progiciel de comptabilit peut tre modifi pour rpondre aux obligations lgales locales Respect des normes PCGA et/ou NIC et des principes comptables franais Mise jour (en ligne ou par lots) des registres comptables Ecriture automatique en cas de remboursements partiels ou en retard Catgorisation des crdits jour et en retard Comptabilit de caisse /dengagement Gestion des intrts et montants en principal dus mais non reus sparment des produits comptabiliss davance Interruption de la comptabilisation des intrts sur les prts en retard Moment auquel les intrts sur lpargne sont comptabiliss davance, crdits et capitaliss Conformit aux rglementations du gouvernement et des organes de supervision Le systme peut tre facilement modifi pour rpondre aux changements ou ajouts de la rglementation Adapt aux rgles de prsentation de linformation de la banque centrale Intgr au systme de paiement national

Notation/Commentaires

Chapitre sixCatgorie 4 : Normes et conformit

27

CHAPITRE SEPT CATGORIE 5 : ADMINISTRATION ET SUPPORT

Description : Cette catgorie recouvre une large gamme dactivits et de fonctions. Lvaluation de cette catgorie consiste par exemple dterminer la capacit du distributeur de logiciel fournir un service de support et de maintenance lorganisation. Le support comprend linstallation, la conversion, la correction derreurs, les requtes des utilisateurs et les amliorations priodiques du logiciel. Les lments prendre en compte sont le nombre dannes dexistence de la socit, le nombre demploys, la localisation des bureaux, le nombre de systmes installs, lexistence dune documentation du systme et de manuels oprationnels et laccs du matriel et des plans de formation. Cette catgorie recouvre galement la scurit, cest--dire les fonctions destines empcher ou dtecter les saisies non autorises, les dommages accidentels ou intentionnels sur les donnes et la falsification des registres. Dautres facteurs valuer sont la capacit du logiciel rcuprer les donnes aprs une panne (coupure de courant et autres), les fonctions garantissant la fiabilit, la validit et la scurit des donnes, et les mcanismes de sauvegarde et de restauration des donnes. Lvaluation doit aussi consister dresser une check-list des fonctions cls de rcupration et de sauvegarde et valuer la prcision et la performance de ces fonctions. Enfin, cette catgorie examine la capacit du vendeur ou du personnel interne fournir un support initial et continu, notamment la capacit de support et de maintenance. Thmes : Scurit ; Sauvegarde et rcupration ; Tolrance aux erreurs et robustesse ; Traitement des fins de priode ; Infrastructure du support et maintenance ; Contrle de version et stratgie de mise niveau

Chapitre septCatgorie 5 : Administration et support

29

Thme Scurit

Dfinition Fonctions de scurit intgres au systme destines empcher laltration illicite ou accidentelle des fichiers de donnes.

Sauvegarde et rcupration

Mesures de stockage de linformation sur les transactions, soldes et tats financiers et de restauration de cette information. Capacit de rcupration du logiciel suite une fermeture de session accidentelle ou non conforme.

Critres de mesure Vrification des principales procdures de scurit : ! Diffrents niveaux daccs avec fonctions rserves certains niveaux (intgr linterface utilisateur) ! Autorise diffrentes perspectives utilisateurs sur la base des autorisations et des types dutilisateurs ! Mot de passe utilisateur ! Le systme demande-t-il rgulirement aux utilisateurs de changer leur mot de passe ? ! Accs limit certaines activits ! Scurit inhrente la base de donnes et larchitecture du systme, protection du systme contre les attaques directes et attaques par cheval de Troie et isolation de la base de donnes et pare-feu ! Cryptage des bases de donnes et mots de passe ! Notification des violations de fichiers ! Piste de vrification sur les transactions permettant didentifier les utilisateurs ! Liste des violations du systme ! Restriction de laccs certains terminaux ou en fonction de tranches horaires ! Programme dauto-audit ! Stockage des donnes hors site ! Traitement automatique en fin de journe, avec mcanismes de rcupration intgrs ! Dure requise pour la sauvegarde ! Sauvegardes compltes ou incrmentielles ! Le systme prvoit-il (ou ncessite-t-il) des sauvegardes compltes sur une base rgulire (hebdomadaire ou mensuelle par ex.) ! Au redmarrage du systme, mcanisme de reprage permettant dviter toute duplication

Notation/Commentaires

Chapitre septCatgorie 5 : Administration et support

30
Thme Dfinition ! ! ! ! ! ! ! ! ! ! ! ! Critres de mesure des saisies ou perte de donnes Simplicit et dure du processus de rcupration Le systme conserve la trace de la situation courante et de lactivit du processeur central et de chaque utilisateur ? Le systme est-il dot dune fonction darchivage permettant de dcharger la base de donnes des donnes anciennes inutilises ? Dans le cas dun systme en rseau : le systme doit rester en ligne en cas de problme de rseau Notification lutilisateur en cas de transaction non acheve Le systme continue fonctionner normalement malgr des erreurs dans la base de donnes ou le systme dexploitation En cas derreur majeure, le systme fournit aux utilisateurs le temps et les informations ncessaires pour ragir Les intrts sont correctement passs en criture et capitaliss Les commissions et pnalits de retard sont correctement calcules Bonne clture des registres et bonne prparation la gnration de rapports de fin de priode Transfert des transactions du journal au grand livre Dclenchement du cycle de gnration des rapports Notation/Commentaires

Tolrance aux erreurs et robustesse

Capacit du logiciel rcuprer aprs une panne (due au logiciel ou externe) ou rester en ligne lors dun incident de ce type. Linformation tant la premire ressource pour la gestion de toute organisation financire, il est impratif que le logiciel garantisse le maintien de lintgrit des donnes.

Traitement des fins de priode

Dans la plupart des systmes, les actions de fin de priode, telles que le calcul des intrts sur les dpts ou la gnration de rapports requirent une intervention administrative. Il sagit ici dvaluer comment le systme gre les diffrentes procdures de fin de priode.

Dure de la priode : ! jour ! semaine ! mois ! trimestre ! anne ! autre (dfini par utilisateur)

Chapitre septCatgorie 5 : Administration et support

31
Thme Infrastructure du support et maintenance Dfinition Ce thme renvoie toute une srie de questions relatives la qualit du support apport au systme par des ressources internes ou externes. Critres de mesure Support externe : ! nombre dannes dexistence de la socit distributrice du logiciel ! solidit financire de la socit ! nombre, taille et anciennet des systmes installs ! localisation de lantenne de support la plus proche ! niveau des rponses et dlais ! assistance tlphonique 24/24 ! nombre demploys et comptences techniques ! Accs au code source (lorsque cest ncessaire) ! Nature du support une fois le code modifi par linstitution ! Support et calendrier pour la mise jour (antenne rgionale) ! Procdure de demande de changements ! Capacits de support (installation, conversion des donnes, personnalisation, formation, assistance technique quotidienne) ! Documentation systme et matriel de formation Ressources internes : ! Dlai de raction ! Service dassistance interne ! Assistance tlphonique 24/24 ! Comptences techniques du personnel dassistance (nombre et exprience) ! Procdure de demande de changements ! Capacits de support (installation, conversion des donnes, personnalisation, formation, assistance technique quotidienne) ! Documentation systme et matriel de formation ! Maintenance du code source ! Informations sur les versions (le dveloppeur peut dire quelles sont les versions actuellement disponibles et quelles fonctionnalits elles Notation/Commentaires

Contrle de version et stratgie de mise niveau

Le contrle de version renvoie la faon dont un dveloppeur intgre et prsente les fonctionnalits dun produit. Pour russir une bonne

Chapitre septCatgorie 5 : Administration et support

32
Thme Dfinition intgration, le dveloppeur doit grer les codes source et les fichiers lis dune manire cohrente et contrle. Un bon contrle de version rduit les problmes dus au fonctionnement simultan de diffrentes copies du logiciel. Les versions sont habituellement numrotes comme suit 1.0, 1.1, 1.1.1, 2.0, etc. Les nouvelles versions se traduisent habituellement par des mises jour du logiciel pour les utilisateurs. Comme les mises jour induisent parfois des changements majeurs du programme, il est important que le dveloppeur ait tabli un plan clair de mise en uvre de ces mises jour. On parle de stratgie de mise niveau. Critres de mesure proposent) Stratgie claire de mise niveau (le dveloppeur peut expliquer comment passer dune version une autre et quel effort ncessite cette mise jour) Notation/Commentaires

Processus de lancement du nouveau systme ! Big Bang : consistant stopper compltement le systme existant et lancer le nouveau systme en mme temps (dangereux et non recommand mais se pratiquant couramment) ! Parallle : consistant faire fonctionner le systme existant et le nouveau systme simultanment pendant une certaine priode de faon vrifier la validit et la performance du nouveau systme

Chapitre septCatgorie 5 : Administration et support

33

CHAPITRE HUIT CATGORIE 6 : SPECIFICATIONS ET QUALITE TECHNIQUES

Description : Analyse les programmes et le langage de programmation du logiciel, le type de rseau et de matriel requis pour le faire fonctionner et les implications de ces lments pour les performances futures. Doit galement tre value la performance globale du systme en terme de rapidit et de stockage dinformation. Enfin, lvaluation doit dterminer comment le systme gre les grands nombres (montants en devises par exemple) et les dates (par ex. lanne 2000). Technologie et architecture ; Performance ; Traitement des nombres et dates

Thmes :

Chapitre huitCatgorie 6 : Spcifications et qualit techniques

35

Thme Technologie et architecture

Dfinition Lors de lanalyse de systmes informatiss, un lment important considrer est la plate-forme technologique utilise pour faire fonctionner les systmes. La plate-forme consiste en un ensemble de technologies agences en combinaison systmatique ou architecturale. Ce thme renvoie au type de matriel et de logiciel utilis pour crer, excuter et assurer la maintenance du systme. Linfrastructure et lenvironnement de lorganisation doivent porter la technologie et larchitecture technique, la fois aujourdhui et dans le futur. Ce thme consiste dterminer avec quelle rapidit le logiciel excute les tches et avec quelle efficacit il stocke et conserve les donnes. Utiliser si possible une configuration matrielle standard pour tester le systme (pas seulement pour la performance). Configuration minimum suggre : Pentium 133 et 16 mgaoctets de RAM.

Performance

Critres de mesure Les aspects suivants du systme ont-ils t correctement appliqus lenvironnement technique local : ! Architecture (en rseau ou autonome ; client/serveur ; etc.) ! Base de donnes (Dbase, Oracle, Paradox, etc.) ! Matriel (PC, Macintosh, Unix, etc.) ! Configuration minimum du matriel ! Systme dexploitation (DOS, Windows 3.x, Windows 95, Windows NT, UNIX, Macintosh) ! Rseau (Novell, Banyan, TCP/IP, etc.) ! Mthodologie de dveloppement (aucune, traditionnelle, oriente objet, etc.) ! Langage de programmation (Clipper, FoxPro, Delphi, COBOL, C/C++, Java, etc.) ! Infrastructure (lectricit, tlphone, etc.) ! Contrle du code source (aucun, PVCS, SourceSafe, etc.) ! Centr sur client/membre ou centr sur crdit/produit Rapidit : ! Interface utilisateur ( quelle rapidit les donnes clients sont-elles affiches, quelle vitesse les listes longues apparaissent-elles lcran, etc.) ! Gnration des rapports (avec quelle rapidit les rapports quotidiens, hebdomadaires et annuels sont-ils gnrs) ! Utilisateurs multiples (le systme est-il ralenti par la prsence de plusieurs utilisateurs, quel moment la rapidit dexcution commence-telle diminuer, etc.) ! Dgradation significative des performances au fur et mesure de la croissance de la base de donnes

Notation/Commentaires

Chapitre huitCatgorie 6 : Spcifications et qualit techniques

36
Thme Dfinition Critres de mesure Stockage : ! Systme (quel est lespace requis pour linstallation initiale du logiciel, cest--dire avant la saisie des donnes) ! Donnes clients (quel est lespace requis par client ?) ! Donnes produits (quel est lespace requis par produit de prt ou dpargne ?) ! Limites maximum (spcifiques la base de donnes) ! Annes 1999, 2000, 2001 ! Grands nombres (>16 chiffres) Notation/Commentaires

Traitement des nombres et dates

Ce thme renvoie tous les problmes lis aux nombres et dates, lexemple le plus connu tant celui du bug de lan 2000. Cela inclut galement les problmes lis aux grands nombres (monnaies soumises linflation) et certaines annes (1999, 2000 et 2001).

Chapitre huitCatgorie 6 : Spcifications et qualit techniques

37

CHAPITRE NEUF CATGORIE 7 : COT

Description : Considre tous les cots associs lacquisition, linstallation et au fonctionnement du systme. Linformation sur les cots doit comprendre le prix de base du logiciel (ainsi quune valuation de la structure de tarification), les contrats de maintenance, linstallation et la formation, la conversion, les mises jour et le matriel de maintenance. Tarification et cots

Thmes :

Chapitre neufCatgorie 7 : Cot

39

Thme Tarification et cots

Dfinition Considre tous les cots associs lacquisition, linstallation, la modification, la mise jour et au fonctionnement du systme.

! ! ! ! ! ! ! ! ! ! ! ! !

Critres de mesure Prix de base et structure de tarification (politiques de licence, etc.) Cots de personnalisation et/ou de dveloppement Cots supplmentaires pour le matriel informatique et rseau Cots supplmentaires pour le code source Commissions et charges de maintenance et de support technique Charges administratives (support interne) Cots dinstallation et de formation Cots de documentation Cots de conversion (pour passer dun ancien un nouveau systme) Cots des futures mises jour et nouvelles versions Cots globaux par utilisateur et par employ charg du systme dinformation Rapport entre le prix et le niveau/la complexit des fonctionnalits Valeur globale (rapport fonctionnalit / cot)

Notation/Commentaires

Chapitre neufCatgorie 7 : Cot

A-1

ANNEXE A GRILLE DE NOTATION

Chapitre neufCatgorie 7 : Cot

A-3

Fonctionnalit et extensibilit ! Pertinence, cohrence et intgration fonctionnelles - Progiciel de comptabilit - Suivi du portefeuille - Suivi des dpts - Systme dinformation clientle Extensibilit et croissance institutionnelle Flexibilit - Centr sur clients / centr sur comptes - Types dinstitution - Mthodologies de crdit - Types dintrt sur les crdits - Types de comptes dpargne et de dpt - Types dintrts sur les dpts - Types de remboursement - Frquence des remboursements - Multiples agences ou rgions - Langues multiples - Monnaies multiples Conditions dutilisation Facilit dutilisation et convivialit Interface utilisateur Prsentation de linformation financire Rapports Gnration des rapports Normes et conformit Normes et rigueur comptables Conformit aux rglementations du gouvernement et des superviseurs Administration et support Scurit Sauvegarde et rcupration Tolrance aux erreurs et robustesse Traitement des fins de priode Infrastructure du support et maintenance Contrle de version et stratgie de mise niveau Spcifications et qualit techniques Technologie et architecture Performance Traitement des nombres et dates Cot Tarification et cots

Pondration

Notation

! !

! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

A-1