1. Introduction à SIRIAC

SIRIAC est un progiciel conçu et développé par la société française Inférence. Ce progiciel comprend des outils de gestion informatisée des ventes, des stocks et des achats. Seule, la partie "achats" sera considérée dans ce manuel.

SIRIAC signifie :

Système Intégré Relationnel Interactif d'Analyse Commerciale

Dans ce qui suit, nous allons décortiquer progressivement les différents mots du sigle SIRIAC, afin de mieux comprendre le quoi, le pourquoi et le comment de ce logiciel.

1.1. SIRIAC, un SYSTEME...

SIRIAC est un progiciel, c'est-à-dire un logiciel développé par une société de services pour satisfaire de façon "standard" un large éventail de besoins rencontrés par des organisations privées ou/et publiques dans un domaine particulier (en l'occurrence celui des achats). Une telle approche exige donc de la part des utilisateurs la nécessité d'intégrer aux habitudes de leur société :

• à la fois un nouveau vocabulaire, c'est-à-dire un ensemble de concepts (parfois abstraits) destinés à modéliser le domaine de gestion considéré,
• et une philosophie particulière, c'est-à dire un ensemble de règles et de conventions portant sur la manipulation de ces concepts.

Exemple :

La notion de marché dans SIRIAC équivaut à la notion de commande provisionnelle ou commande cadre au CERN. Dans SIRIAC, des commandes pourront être passées dans le cadre d'un marché : ces commandes équivaudront alors à nos actuelles demandes de livraison. Etant donné la présence d'une référence explicite au marché pour une demande de livraison, il ne sera plus nécessaire (et d'ailleurs plus possible) de mentionner le numéro de la commande provisionnelle (marché) dans le numéro de la demande de livraison.

Cela ne signifie pas pour autant qu'un progiciel représente un carcan standard rigide. Au fur et à mesure de son utilisation dans des sociétés différentes, le progiciel incorpore des nouvelles idées qui en améliorent le fonctionnement au bénéfice de la communauté de tous les utilisateurs.

D'autre part, un progiciel est généralement caractérisé par de larges possibilités de paramètrage. Les paramètres permettent d'utiliser les concepts et de les assembler de manière à ce qu'ils représentent le mieux possible la réalité d'une organisation.

Exemple :

Dans SIRIAC, le concept de classe de commande permet de distinguer différentes catégories de commande, sur lesquelles s'appliqueront des règles et des étapes de traitement spécifiques. Au CERN, les demandes de livraison, les commandes normales, les contrats, les demandes d'offre, les ordres de service valant commande... correspondront à différentes classes de commande. Par contre, dans un tout autre environnement tel que celui d'une société de vente par correspondance, la classe de commande permettra de faire la distinction entre les commandes reçues par courrier, par minitel, par téléphone, par un représentant ou directement par un magasin....

1.2. SIRIAC, un Système INTEGRE...

La notion d'intégration est un élément clé de l'architecture des nouvelles applications développées au sein du projet AIS. Cette intégration porte sur différents niveaux :

• intégration des différentes activités de gestion supportées par une même application;
• intégration des applications administratives centrales;
• intégration de ces applications centrales avec les applications périphériques destinées à la communauté des utilisateurs du CERN.

1.2.1. Intégration des fonctions du cycle des achats dans SIRIAC

Dans SIRIAC, la réception d'une demande d'achat interne, l'établissement d'un appel d'offre, l'enregistrement des réponses, la sélection d'un fournisseur, l'établissement d'un contrat ou d'une commande cadre, la création de commandes et demandes de livraison, l'enregistrement et le contrôle des marchandises reçues pour une ou plusieurs commandes, l'enregistrement et le contrôle des factures relatives à des commandes etc correspondent à différentes étapes de la vie d'une commande. Les informations définies dans une étape servent de base de référence aux étapes suivantes.

Ceci implique dès lors, de la part des différents utilisateurs et services, la nécessité d'enregistrer toutes les informations relatives au cycle des achats dès qu'elles existent, de façon à les rendre immédiatement disponibles pour les traitements ultérieurs.

Exemples:

Lors de la création d'une commande, le service d'achats devra mentionner explicitement (et non plus sous forme de texte libre) les conditions commerciales (incoterms) s'appliquant à la commande. Il indiquera également pour chaque ligne de la commande si cette ligne porte sur des biens devant faire l'objet d'une réception (par la réception des marchandises) ou sur des services. En outre, le service d'achats précisera si la commande pourra être acceptée par le bureau des factures sur la seule base des réceptions constatées, ou nécessitera une approbation préalable des utilisateurs.

La réception des marchandises devra enregistrer de façon explicite tout retour de marchandises (retour temporaire ou définitif), pour autant que la commande n'ait pas fait l'objet d'une facturation.

Moyennant accord préalable des utilisateurs et des acheteurs, le bureau des factures pourra accepter une facture portant sur des montants différents de la commande, sans que les services d'achat ne doivent procéder à une modification de la commande.

Lorsqu'une commande fera l'objet de multiples termes de paiement (facturation), le service d'achats devra indiquer explicitement cette situation dès la création de la commande. Les services financiers pourront, par la suite, distribuer et réviser les engagements relatifs à ces différents termes de paiement.

1.2.2. Intégration des applications administratives centrales

L'intégration des différentes activités composant le cycle des achats n'est pas suffisante. Il faut encore que l'application des achats soit elle-même intégrée aux autres applications administratives centrales; en l'occurrence (et dans une première phase):

• l'application comptable et budgétaire (ORIAC),
• et l'application responsable de la gestion des données de référence: personnes, organisations en rapport avec le CERN, adresses internes et externes... (FOUNDATION ).

Cette intégration repose sur un double postulat.

D'une part, les informations sont créées, contrôlées et modifiées exclusivement par la seule application qui est responsable de leur gestion, mais elles peuvent être utilisées par toutes les autres applications.

Exemple :

L'application FOUNDATION renferme l'ensemble des unités organisationnelles internes (secteurs, divisions, groupes, sections...) et externes (firmes, instituts de physique, états membres...) liées au CERN, ainsi que leurs adresses. La modification des données relatives à ces unités organisationnelles se fera dans le cadre de transactions spécifiques à l'application FOUNDATION .

Par contre, il sera possible dans SIRIAC d'assigner à certaines de ces unités organisationnelles le rôle de fournisseur, et de leur associer un certain nombre de caractéristiques commerciales (telles que code taxe, conditions de paiement, rabais habituels, appréciation commerciale...).

Par ailleurs, l'application financière ORIAC pourra associer des caractéristiques financières complémentaires à ces mêmes fournisseurs (délais et modes de paiement, domiciliations bancaires...).

D'autre part, il sera possible à une application de transférer des informations destinées à une autre application, pour autant que ces informations transitent par des interfaces contrôlées par l'application destinataire.

Exemple :

Tout au long des différentes étapes de la vie d'une commande (dans SIRIAC), des écritures devront être passées en comptabilité (dans ORIAC ) pour refléter l'évolution des montants engagés et facturés pour la commande. Les données comptables (comptes généraux, comptes budgétaires...) définies dans ORIAC devront être rattachées aux commandes et factures de SIRIAC. A la suite de quoi, l'application SIRIAC construira des écritures comptables destinées à ORIAC . Avant d'être prises en compte par ORIAC , ces écritures passeront nécessairement par des étapes de validation comptable, comparables à celles utilisées pour le contrôle des écritures introduites manuellement par les services comptables.

1.2.3. Intégration des applications périphériques

Les applications centrales ne vivent pas en vase clos. Elles ont pour objectif, en définitive, de supporter l'ensemble des activités administratives engendrées en réponse à des demandes et événements issus de la communauté des utilisateurs du CERN. Ces utilisateurs auront recours à des applications périphériques plus appropriées à leurs besoins.

Dans le domaine des achats, les demandes d'achat internes seront créées, routées et approuvées dans le cadre d'un outil de traitement électronique de documents (EDH ). Cet outil veillera bien entendu à ce que les informations introduites dans la demande d'achat soient compatibles avec les données définies dans les applications centrales (codes d'activité, adresses internes...). Les demandes pourront alors être transférées vers SIRIAC, via une interface de contrôle.

Des outils d'interrogation permettront ensuite aux utilisateurs de connaître l'évolution de leurs demandes dans le cycle des achats (commandes, réceptions, factures) (en partie EDH ) et de connaître les répercussions financières de ces demandes (notamment, à travers l'outil budgétaire BHT).

1.2.4. L'intégration en pratique

D'un point de vue technique, l'intégration repose sur la présence d'une base de données centrale (de type relationnel), servant de plate-forme commune d'information aux différentes applications (voir point suivant 1.3).

Pour les utilisateurs, l'intégration entre les applications administratives centrales se traduira par un environnement de travail unique pour les applications SIRIAC, ORIAC et FOUNDATION (voir le point 1.4).

1.3. SIRIAC, un Système Intégré RELATIONNEL...

Les informations gérées par SIRIAC sont conservées dans une base de données relationnelles ORACLE. Cette base de données est partagée avec les autres applications.

Par rapport aux générations précédentes de bases de données, les bases de données relationnelles reposent sur un modèle logique de gestion des données à la fois simple (tables à deux dimensions), souple (algèbre relationnelle) et normalisé (SQL est le langage standard de gestion des bases de données relationnelles).

1.4. SIRIAC, un Système Intégré Relationnel INTERACTIF...

Les logiciels SIRIAC, ORIAC et FOUNDATION sont accessibles à travers un environnement de travail unique pour tous les utilisateurs. Cet environnement s'appelle MORIAC: il gère les transactions accessibles aux utilisateurs dans les différentes applications à travers un même menu général, en fonction des droits qui leur sont attribués. MORIAC offre en outre des outils permettant aux utilisateurs de contrôler les traitements et rapports qu'ils ont déclenchés.

Pour l'utilisateur, les principes d'interactions avec les applications informatiques seront donc tout à fait identiques, quelle que soit l'application considérée : mêmes touches de fonction, menu général intégrant les transactions des différentes applications, même présentation des transactions (en-tête et pied de pages), conventions identiques pour interroger ou modifier des données.

Outre la présence d'un environnement uniforme convivial, un certain nombre de facilités d'interactions méritent encore d'être soulignées :

• possibilités étendues d'interrogation de la base de données, sur des critères variés (par exemple, il est très simple de rechercher les commandes d'une classe donnée qui ont été créées à telle date par tel utilisateur à destination de tel fournisseur);

• concept de saisie assistée : un grand nombre de zones affichées sur un écran font référence à des informations paramètrées; une touche permet d'obtenir systématiquement l'ensemble des valeurs possibles pour la zone en question (par exemple, en se positionnant sur la zone adresse du fournisseur dans une commande, on pourra obtenir la liste des adresses associées au fournisseur de la commande, et sélectionner directement l'adresse qui convient);

• possibilité de lancer des travaux et de listes directement dans le même environnement de travail (par exemple, l'utilisateur pourra lancer et faire imprimer la liste des fournisseurs pour un code d'activité donné ou un pays donné directement à partir d'une option du menu de SIRIAC); de plus, les caractéristiques (paramètres) de ces travaux et listes pourront être sauvegardées pour être réutilisées ultérieurement;

• et bien d'autres facilités: transactions multi-pages, copie rapide d'enregistrements, plusieurs sessions de travail simultanées, documentation on-line...

1.5. SIRIAC, un Système Intégré Relationnel Interactif d'ANALYSE COMMERCIALE

La partie achats de SIRIAC s'articule sur une architecture fournisseur, une architecture article et une architecture de la vie de la commande.

1.5.1. Architecture fournisseur

Un fournisseur est défini pour un tiers (unité organisationnelle) et pour un établissement. Le fournisseur incorpore les renseignements supplémentaires permettant de gérer la chaîne des achats : conditions commerciales, délais de paiement, devises de référence, types de taxe applicables aux commandes, appréciations par les services d'achats etc.

Les fournisseurs peuvent être regroupés en familles, éventuellement dans des hiérarchies différentes. La création d'un fournisseur générera automatiquement la définition d'une famille associée.

1.5.2. Architecture article

Chaque article est référencé globalement pour tous les établissements. Il est ensuite défini comme achetable, stockable et vendable par établissement.

Les articles achetés sont d'abord définis de manière globale, indépendamment du fournisseur, avec des modes d'achat, des modes de contrôle, des niveaux de taxation et des règles de comptabilisation appropriés. Ils peuvent être regroupés en familles de la même façon que les fournisseurs.

Dans notre cas, les articles correspondront soit à des articles standards magasin (SCEM), soit à des codes d'activité de base; ces articles seront rassemblés dans des familles correspondant aux différents niveaux de codes d'activité.

Les articles achetés (en l'occurrence, les articles standards) peuvent ensuite être référencés par rapport aux fournisseurs pour permettre la gestion des prix, de la référence de l'article chez le fournisseur, du délai de livraison, de la quantité habituelle de commande...

Il est encore possible de définir des marchés (équivalent de nos commandes provisionnelles) où sont précisées des estimations d'achats globales (en montant et/ou quantité) relatives à certaines familles d'articles chez un fournisseur donné.

1.5.3. Architecture de la vie de la commande

Dans SIRIAC, les commandes sont réparties en classes. Chaque commande, en fonction de la classe qui lui aura été attribuée, va passer depuis sa création jusqu'à son aboutissement, à travers un certain nombre d'étapes, obligatoires ou facultatives, qui permettront le déclenchement de traitements spécifiques (édition, envoi au fournisseur, transfert des engagements en comptabilité, confirmation, réception, etc). Le nombre d'étapes et leurs fonctions sont entièrement paramétrables.