Usages FileMaker – 6 – Organiser la production

FileMaker en production !

Les premiers usages que je vous ai présentés sont considérés comme assez classiques.
Après tout, prendre un fichier, et passer à la base de données pour gérer ses clients, ce n’est pas l’invention du siècle.

Voyons maintenant des exemples plus « productifs »

1) L’atelier

On voit des ateliers de production « se contenter » de gérer les clients, ou à la rigueur faire les factures, avec FileMaker, mais ne pas imaginer en faire autant pour suivre le cœur du métier. Certains vont même acheter, souvent fort cher, des outils dits de GPAO, « Gestion de Production Assistée par Ordinateur ».

Certes, il y a parfois, pour certains métiers, des outils logiciels déjà existants, bien faits et plus économiques que le développement personnalisé d’une base de données. Mais je connais des entreprises où cela aurait été moins onéreux et plus pratique de faire cela sous FileMaker, surtout quand elles avaient déjà des compétences FileMaker internes.

Imaginons un atelier et un cas volontairement simple, pour illustration.

Robert arrive le matin.
Un tableau FileMaker lui liste la ou les tâches prévues pour lui : la machine 23, pour le dossier 45, avec un planning prévu entre 8H et 9H45.
Il trouve également les paramètres pour la dite machine.
Sur un écran tactile FileMaker, il confirme qu’il prend en charge cette tâche, stockant l’heure de départ.
Une fois la tâche terminée, il clique sur « Fin » et le temps réel (à facturer au client final) est calculé.
Il peut entrer des remarques relatives à la tâche ou à l’état de la machine.

Pendant ce temps-là, Sylvie a passé 1 heure sur la machine 12, pour ce même dossier 45.

À n’importe quel moment, le chef d’atelier, ou le responsable du client ayant commandé le dossier 45, peut connaître le cumul des temps.
En fin de journée, Robert et Sylvie ont le relevé de leur temps.
Le responsable des machines peut voir les comptes-rendu, et même recevoir une alerte si Robert ou Sylvie ont signalé un dysfonctionnement à réparer depuis une liste à cocher.
Il peut savoir depuis combien de temps tourne la machine 12, et si c’est bientôt le temps d’une petite révision technique pour elle.

En fait, on peut imaginer de nombreuses données saisies dans FileMaker et permettant de mieux gérer l’atelier.
Nous avons noté que Sylvie et Robert saisissent des données à l’aide d’un écran tactile. Mais dans certains ateliers, ils utilisent en arrivant leur carte personnelle, passée dans une badgeuse, et reliée au serveur FileMaker.

2) Restauration rapide

Il n’y a pas que des ateliers. Ainsi, nous avons été amenés à développer la gestion de la conception des plats, pour de la restauration rapide.
Chaque plat a sa recette prédéterminée, avec ses ingrédients calibrés. La salade de printemps a tant de gramme de salade verte, de tomates, de concombre,… plus une olive et tant de quantité de sauce vinaigrette. La vinaigrette, qui est ici un ingrédient, est elle même une recette (ou plutôt une sous-recette), car réutilisable pour d’autres plats.

Chaque ingrédient a un prix, en fonction du prix d’achat et du prix éventuel de traitement, ce qui donne le prix du plat, et in fine permet de savoir si on gagne ou on perd de l’argent. Évidemment, on peut gérer le stock, les alertes avant de tomber en panne, et les commandes de réapprovisionnement.

On est loin du simple fichier d’adresses clients…

3) L’hôtellerie

Mais puisque nos deux exemples, qui émanent du domaine de la production, évoquent des notions de traçabilité, allons plus loin avec un exemple hôtelier.
Nous sommes dans un hôtel, le staff est composé de quatre réceptionnistes de jour, un réceptionniste de soirée (night auditor) et un veilleur de nuit.

Monsieur Martin réserve une chambre pour un séjour de quatre jours, mais il a un problème, assez courant dans ce métier : un contrat d’ « allotements » a été signé avec un voyagiste, qui stipule qu’un certain nombre de chambres doit être disponible pour lui, avec une période de rétrocession, sans que personne ne sache si ces chambres vont être effectivement occupées.

L’hôtelier informe donc son client que le séjour est possible, mais qu’il y a un risque qu’il soit « délogé », non seulement d’une chambre à une autre, mais également vers un autre hôtel.
Le client accepte. Les deux premières « nuitées » se passent sans encombre mais il se voit contraint de changer de chambre la troisième, puis de passer la quatrième nuit dans l’hôtel d’en face.

Un réceptionniste du matin, celui qui a eu commande du voyagiste, a procédé au « délogement » du client vers une autre chambre, d’un simple clic sur la fiche du client. Un autre réceptionniste l’a délogé le lendemain après-midi vers l’hôtel d’en face, ayant eu une nouvelle commande du voyagiste prioritaire laissant l’hôtel en « surbooking ». Ce second réceptionniste a immédiatement vu le premier délogement effectué par son collaborateur et adopte un ton particulier pour s’en excuser auprès du client.

La fiche du client contient l’intégralité de l’historique, ce qui est une prérogative importantes des bases de données mais le plus intéressant reste à venir. Le réceptionniste de soirée quitte à 23 heures, relayé par le veilleur de nuit. Ce dernier reçoit un coup de téléphone : quelqu’un veut parler à Monsieur Martin.
Le veilleur de nuit n’est pas habilité à gérer des réservations, il n’a volontairement pas été formé. Il dispose néanmoins d’un planning minimal, qui lui dit instantanément où se trouve Monsieur Martin et comment le contacter.

Il est important de comprendre, dans cette notion, les deux prérogatives essentielles d’une base de données parfaitement structurée :
1 – Monsieur Martin, le pauvre, a été déplacé deux fois d’un simple clic
2 – Monsieur Martin a été trouvé par le veilleur de nuit d’un simple coup d’œil.

Allez, on en reste là pour aujourd’hui, après tout vous avez pu travailler, manger et dormir
en quelques lignes,….
Cela remplit bien la journée 😉

Marie-Charlotte Potton

Premier article / Article précédent / Article suivant

Tags: Production