A l’aide
-
Je reviens sur ma liste de produit, j’ai renseigné le champs “date de mouvement” parce que je suppose que par moment tu peux enreigistrer l’entrée d’une nouvelle ref via cet ecran, donc forcement important de renseigner la date d enreigistrement. Dites moi si cela est necessaire
Merci,
-
Ok… Evidemment, il faudrait que je comprenne tous les tenants et aboutissants du fonctionnement et du mouvement de vos pièces de rechange pour bien cerner l’objectif…
-
Bonjour, j’espère que vous allez bien,
Pas de souci, n’hésitez pas à me poser toutes les questions nécessaires pour mieux comprendre.
Pour faire simple, nous avons actuellement un magasin de pièces de rechange, et l’objectif est de mettre en place une application Power Apps pour gérer les mouvements de stock. L’idée est d’attribuer un QR code à chaque référence. Lors de nos opérations, il suffira de scanner une référence pour naviguer automatiquement vers un écran Power Apps, où le type de mouvement souhaité (entrée/sortie) pourra être effectué.
-
C’est ouf comme on a tous le réflexe de vouloir décrire un problème en y intégrant directement la solution… (moi le premier) 😅
- Sans me parler de Power Apps, de listes, de QR code, de scanner, etc. raconte-moi une histoire : parle-moi de ces pièces de rechanges, comment elles arrivent là, comment elles sont stockées, comment elles sont réutilisées, qu’est-ce que ça veut dire un mouvement, où va la pièce, quels sont les différents acteurs qui manipulent les pièces, le magasinier, le manipulateur du transpalette, le client qui veut acheter la pièce, etc. -> ça c’est la description de l’existant (dans la vie réelle).
- Ensuite, explique-moi ce que tu veux faire : je veux une application qui permette de tracer et d’historiser les entrées et les sorties des pièces afin de…, qui va utiliser l’application, comment tu voudrais idéalement que ce traçage se fasse (là tu peux parler de scanner et de qr code), qui a le droit de faire quoi dans l’application (pour identifier les rôles), il faut qu’un administrateur puisse faire ça et ci et ça, etc. -> ça c’est la description du besoin
Une fois que ça c’est bien clair alors tu peux commencer à réfléchir à l’architecture de ta solution dans l’ordre suivant :
- Conception du modèle de données (imaginer les listes, les colonnes, les relations, etc.) pour que ça réponde à ton besoin
- Schématiser le parcours de l’utilisateur dans l’application en précisant ce qu’il est possible de faire :
- Il fait un choix entre la consultation de l’historique des mouvements, la création d’un mouvement ou la gestion des pièces
- S’il choisit l’historique d’un mouvement, il peut modifier un mouvement ou en créer un nouveau et revenir ensuite au départ
- S’il choisit la création d’un mouvement (à partir du départ ou à partir de l’historique) il arrive sur l’écran de création de mouvement
- S’il choisit la gestion des pièces, il arrive sur un écran dédié où il peut : éditer les pièces existantes, ajouter de nouvelles pièces
- Faire des maquettes de tes écrans (maquettes grossières tout d’abord)
- Présenter ta solution aux utilisateurs finaux pour avoir leur sentiment (hyper important de faire ça AVANT de créer ton application passke sinon tu va être confronté au problème de “l’effet tunnel” : tu fais tout dans ton coin et puis tu le files aux utilisateurs qui finissent par te dire que ton machin est pas pratique du tout et qu’ils rechignent à l’utiliser)
- Réajuster ta solution en fonction des retours des utilisateurs
- Dessiner tes écrans au propre (couleurs, positions, dimensions, etc.)
- ET LA TU PEUX COMMENCER A CODER 😅
Ca c’est l’idéal. Après, souvent on saute un peu des étapes pour aller plus vite (à ses risques et périls) mais globalement faut quand même respecter cette logique. Et surtout que procéder méthodiquement comme ça va au final te faire gagner du temps par rapport à : je me lance direct dans le codage et je réfléchis après -> ça ne marche que pour ceux qui ont déjà 20 ans d’expérience dans la création d’applications 😉.
Et autre point très important aussi : le choix des mots -> appelle un chat un chat. Retour sur tes captures d’écrans plus haut :
- Produit ou Pièce ? Si ton application gère des pièces de rechange alors c’est le mot “Pièce” qu’il faut voir partout
- Type de mouvement ou Mouvement ? C’est pas la même chose : le 1er est plutôt une caractéristique du 2è -> si ton application gère des mouvements alors ça s’appelle “Mouvement“
Ah et aussi : part d’une page blanche plutôt que d’un modèle d’application existant (beaucoup trop galère selon moi).
-
Hello,
Totalement d’accord avec vous, on a toujours tendance d’expliquer une problematique avec des axes de solutions.😁
Je mets le contexte et la problematique actuelle.
Contexte
Fives Maintenance est une entreprise de prestation de service dans la maintenance industrielle assurant cette activité sur le site de Volvo Trucks France basé à Lyon. Dans le cadre des activités de maintenance, la gestion des pièces des rechanges est une étape primordiale dans le management du quotidien de la maintenance. Actuellement au sein de notre service, nous avons aucune maitrise sur nos pièces des rechanges, notamment un manque de connaissance des pièces disponible, une absence de traçabilité digitalisée des mouvements de stock.
Problématique
Le processus actuel de gestions des pièces détachées chez Renault Truck n’est pas suffisamment robuste, occasionnant de nombreuses ruptures de stocks des pièces, de nombreux retards dans la maintenance, et donc des temps d’indisponibilité des équipements plus long et une insatisfaction grandissante chez notre client.
-
Ah ouais, c’est pas juste une p’tite appli pour une p’tite boîte… 😅
Vous voulez pas que je vous accompagne sur le projet ? Je suis dispo en ce moment… 😁 On pourrait le faire en mode “mentoring” : c’est toi qui fait l’application avec moi en background qui te fait monter en compétence… 😋
Connectez-vous pour répondre.