BCS, du chiffrage de projet à la facturation

Flexus est présente sur le marché depuis 1995. Nous avons commencé comme société de conseil avec trois collaborateurs. En 2001, Flexus est devenue une société anonyme, comptant alors environ 20 collaborateurs. À partir de 2009, nous avons davantage orienté notre activité vers des add-ons SAP standardisés. Aujourd’hui, nous comptons plus de 100 collaborateurs.

Nous nous considérons comme une entreprise familiale, un éditeur de produits, un vendeur de licences et une société de conseil spécialisée dans l’intralogistique SAP. Notre domaine couvre l’ensemble du flux de matériaux — de l’inbound à l’outbound : yard management, gestion de cour, livraison, réception des marchandises, stockage, logistique de production, préparation des commandes, chargement et expédition.

Nos clients proviennent de secteurs et de tailles d’entreprise très variés — des grandes entreprises industrielles aux clients de plus petite taille. Ils ont en commun des défis logistiques que nous résolvons grâce au conseil, au pilotage, à la mobilité et à l’automatisation.

Pour nous, cette activité signifie que nos processus internes sont très diversifiés. Nous ne disposons pas d’un seul modèle de projet, mais de nombreuses formes différentes de prestations, de contrats et de facturation. Il était donc essentiel pour nous d’introduire un système capable de représenter toute cette diversité.

Paysage applicatif évolutif, exigences croissantes

Nous conseillons de grandes entreprises dans le domaine SAP. SAP est très performant dans de nombreux domaines, notamment dans la gestion des matériaux, la gestion des stocks et comme base de données centrale. Toutefois, des outils spécialisés sont nécessaires pour piloter une activité de services orientée projet avec chiffrage de projets, saisie des temps, planification des ressources, contrôle de gestion et facturation.

Notre paysage applicatif interne s’était développé au fil de nombreuses années. Nous avions développé nos propres solutions, notamment FlexHub pour la saisie des temps et d’autres processus internes. Nous utilisions en outre des systèmes et espaces de stockage tels que SharePoint, Teams, Outlook, des modèles Word, OneNote, Planner, Zammad, Jira, Git, HubSpot et DATEV.

Ces solutions remplissaient chacune leur fonction. Dans le même temps, des ruptures de médias sont apparues entre les ventes, la gestion de projet, la prestation de services et la facturation. À cela s’ajoutait le fait que chaque développement interne mobilise des capacités internes. Le temps de développement consacré aux outils internes n’est pas disponible pour les projets clients ni pour le développement de produits.

C’est pourquoi nous avons défini une prémisse claire pour l’introduction de BCS : ne plus créer de nouveaux développements spécifiques pour les processus internes. Lorsque cela est pertinent, nous adaptons nos processus au standard BCS au lieu de développer à nouveau des solutions individuelles sur mesure.

Premièrement, nous avons des nouveaux projets en régie. Ceux-ci sont facturés de manière classique en fonction du temps passé et des ressources utilisées. Pour cela, nous avons besoin d’une saisie des temps fiable, de taux horaires clairs et d’une affectation précise des prestations au projet.

Deuxièmement, nous avons des nouveaux projets à prix fixe avec jalons. Les grands clients, en particulier, demandent souvent des prix fixes. En interne, nous devons néanmoins savoir exactement quels temps et quels efforts sont réellement engagés afin de pouvoir évaluer la rentabilité.

Troisièmement, nous traitons des change requests pour des clients existants. Il s’agit souvent de demandes plus petites et rapides. Dans ce cas, nous devons être en mesure d’établir des offres rapidement — parfois dans un délai de 24 à 48 heures.

Quatrièmement, nous avons le support et la maintenance. Cela peut sembler simple au premier abord, mais c’est complexe dans la pratique : les contrats évoluent, les durées doivent être prises en compte et les prestations doivent être facturées en temps voulu.

Cinquièmement, nous avons les abonnements et les modèles par abonnement. Auparavant, nous vendions davantage de licences. Aujourd’hui, il existe des modèles de facturation mensuels et annuels, différents modèles de paiement, des périodes gratuites et des durées contractuelles variables. Cela crée de nombreuses éventualités que nous devons piloter proprement.

Sixièmement, il y a notre développement interne. Nous développons nos propres produits, sur lesquels des équipes travaillent en continu. Un exemple est notre système de gestion du transport, qui permet de déplacer chaque année des millions de palettes. Ces projets nécessitent eux aussi de la planification, du chiffrage, de la gestion des ressources et du contrôle de gestion.

Septièmement, il existe des projets d’organisation interne. En interne également, nous avons des projets de changement, de pilotage et de structuration. Ceux-ci ne doivent pas être gérés accessoirement par e-mails, listes ou outils isolés, mais de manière traçable.

Pour nous, il était donc clair que nous avions besoin d’un système capable de représenter les projets en régie, les prix fixes, les jalons, les change requests, le support, la maintenance, les abonnements, le développement produit et l’organisation interne dans une structure commune.

Premièrement : des limites claires. Nous ne développons pas BCS nous-mêmes. Les demandes de modification sont transmises à Projektron sous forme de change requests. Nos propres développeurs doivent travailler sur nos produits et nos projets clients, et non sur des solutions spécifiques internes pour BCS.

Deuxièmement : la discipline. Dans un premier temps, nous nous adaptons à la solution et sommes prêts à ajuster nos méthodes de travail aux conditions du système dans une mesure raisonnable. Au premier trimestre, nous ne voulions pas mettre en œuvre de change requests, mais les documenter, les comprendre et acquérir de l’expérience.

Troisièmement, nous misons sur la gouvernance. Une équipe de key users, avec un porte-parole, pilote les évolutions et rend compte directement à la direction. Nous travaillons également avec des budgets fixes par semestre. Ainsi, le développement reste contrôlé et ciblé.

La structure de projet est actuellement l’élément central de notre utilisation de BCS. Nous avons environ 180 groupes d’entreprises et clients actifs, 580 groupes de projets ainsi qu’environ 3 400 projets et 300 sous-projets dans BCS. Mettre en place cette structure de manière propre lors de la migration des données a été exigeant. Au final, nous avons toutefois réussi à créer une base solide.

Nous avons créé des modèles dans BCS pour nos différents types de projets. Il est alors apparu clairement que l’introduction d’un tel système constitue également un processus d’apprentissage organisationnel.

Nos premiers modèles étaient très détaillés. Dans l’utilisation pratique, il s’est toutefois avéré qu’un trop grand nombre de prescriptions pouvait limiter la flexibilité. C’est pourquoi les modèles deviennent aujourd’hui plus légers, plus flexibles et davantage orientés vers les besoins réels.

Dans le chiffrage, nous pouvons prendre en compte les plans de structure, les plannings, les plans de charge et les taux d’occupation. Cela permet d’évaluer plus tôt quelles ressources seront nécessaires et comment un projet est susceptible d’évoluer.

Dans le même temps, une chose est claire : la qualité du chiffrage, du pilotage de projet et du contrôle de gestion dépend fortement de la gestion des données. BCS fournit la base, mais les données doivent être maintenues de manière cohérente et rigoureuse.

Saisie des temps, frais et pilotage de projet

Nous saisissons et gérons dans BCS les temps, les congés, les absences maladie et les frais. Auparavant, nous utilisions pour cela nos propres outils. Ceux-ci étaient fortement adaptés à nos exigences, mais devaient être maintenus et développés en interne.

BCS est plus standardisé à certains égards, mais nous offre l’avantage de pouvoir être utilisé de manière universelle pour de nombreux processus et par l’ensemble des collaborateurs. Les frais à l’étranger peuvent également être saisis sans nécessiter de développements spécifiques.

La saisie des temps constitue également la base du contrôle de projets et de la facturation. Pour les projets en régie, elle est directement intégrée à la facturation. Pour les projets à prix fixe, elle sert au contrôle interne afin d’évaluer la rentabilité et l’utilisation des ressources.

Dans le pilotage de projet, nous utilisons différents plans et vues, par exemple le plan de structure, le plan d’équipe, le plan de charge et le plan de commande. Au début, cela a nécessité une phase d’orientation et de prise en main. Depuis, les équipes ont défini leurs propres filtres, vues et configurations de colonnes, adaptés à leur manière de travailler. Les vues peuvent être enregistrées et partagées.

Plus de 20 000 tâches sont créées dans BCS, dont environ 1 300 sont ouvertes. Cela montre l’importance que BCS occupe désormais dans l’activité opérationnelle quotidienne.

La facturation a été l’une des principales raisons de l’introduction de BCS.

Nous facturons différents types de prestations : services en régie, projets à prix fixe avec jalons, licences, abonnements, maintenance, forfaits de support, tickets, frais de déplacement, temps d’astreinte et suppléments.

Dans BCS, les données comptables, les données clients, les modèles de facture, les taux de fonction, les projets, les saisies et les offres acceptées sont réunis. Les coûts totaux, les coûts matériels et les coûts de personnel peuvent ainsi être présentés plus clairement.

La facturation devient plus transparente et mieux préparée. Même de petites unités, par exemple des demi-heures, peuvent être facturées proprement. En même temps, les rôles et responsabilités dans le processus deviennent plus clairs : les chefs de projet contrôlent les saisies sur le projet, les responsables de business unit vérifient les frais et les temps de déplacement, puis le service de facturation travaille sur une base de données préparée.

Les prestations récurrentes constituent un domaine particulièrement exigeant. Outre les modèles de licences classiques, les abonnements mensuels et annuels, les forfaits de maintenance et de support ainsi que d’autres modèles récurrents gagnent en importance. Cela crée de nombreuses variantes : modèles de paiement, périodes gratuites, durées contractuelles, délais de résiliation, dates de début et périodes de facturation. À long terme, ces sujets ne peuvent pas être pilotés de manière fiable à partir de connaissances individuelles, de rappels ou de listes isolées.

BCS nous aide à standardiser davantage ces exigences commerciales. Les échéances, les articles, les périodes de facturation et les rappels peuvent être représentés de manière plus structurée. Dans le même temps, nous voyons encore un potentiel d’optimisation dans ce domaine.

La comptabilité continue d’être effectuée dans DATEV. BCS prépare les données pertinentes et les transfère vers DATEV.

BCS dans notre paysage applicatif

BCS n’est pas le seul système que nous utilisons. HubSpot reste notre CRM. Jira et Git sont établis pour le développement logiciel et la planification produit. Nous utilisons Zammad pour le support. À cela s’ajoutent un wiki, un helpdesk, Planner, OneNote, Teams, Outlook et DATEV.

Notre approche consiste à faire évoluer progressivement le paysage applicatif, en fonction des bénéfices attendus. Toutes les fonctions ne doivent pas nécessairement être représentées dans BCS à court terme. En parallèle, nous examinons quels processus pourront être intégrés à BCS ou transférés vers BCS de manière pertinente à long terme.

L’important est que chaque intégration et chaque remplacement apporte un bénéfice clair. Nous voulons consolider le paysage applicatif sans créer de nouvelle complexité.

Prochaines étapes

Parmi les prochaines étapes, nous examinons plusieurs sujets : l’intégration de Zammad, le remplacement du helpdesk interne par BCS, le rôle à long terme de Jira, de meilleures analyses pour la direction et les équipes ainsi que l’analyse de données assistée par l’IA.

Les analyses sont particulièrement importantes pour nous. Nous voulons mieux identifier l’état d’avancement des projets, les prestations facturables, l’évolution des taux d’occupation et les points nécessitant une action.

Évaluation et conclusion

Du point de vue de la direction, l’introduction de BCS a été une étape importante. Nous n’avons pas seulement introduit un nouvel outil, nous avons restructuré une partie essentielle de notre création de valeur interne.

Auparavant, nous disposions de plusieurs solutions fonctionnelles, mais réparties. Aujourd’hui, nous rapprochons davantage les données de base, les projets, les chiffrages, les offres, les commandes, les temps, les frais et les informations de facturation. Cela réduit les efforts de coordination, améliore la traçabilité et crée une base plus homogène pour les décisions opérationnelles et commerciales.

Dans le même temps, l’introduction a été — et reste — un processus d’apprentissage. Nous avons dû nettoyer les données, créer des structures de projet, adapter les modèles, clarifier les rôles et établir de nouvelles méthodes de travail. BCS déploie toute sa valeur lorsque les processus sont appliqués avec discipline et que les données sont tenues à jour de manière cohérente.

Cette voie nous convient, car nous avons délibérément choisi de ne plus développer de nouvelles solutions internes spécifiques. Nous voulons concentrer davantage notre énergie sur les projets clients et le développement de produits. BCS nous offre pour cela une plateforme standard suffisamment large pour représenter notre activité quotidienne.

Avec BCS, nous avons nettement standardisé et regroupé nos processus de projet, de prestations et de facturation. BCS est ainsi bien plus qu’un outil de gestion de projet : c’est un système ERP pour notre activité de services orientée projet et un élément important pour associer croissance, transparence et pilotage commercial.