Krogis conseille les directions d’entreprises et de filiales de groupes étrangers qui ont un projet à mener alors que leur propre service informatique est absorbé par l’exploitation. Choix et déploiement d’un nouvel ERP, traitement des réclamations, CRM orienté processus, circuit des pièces de dépenses adapté au KSeF (le système national polonais de facturation électronique), gestion des contrats, arrivée et départ des collaborateurs : je formalise les exigences avec la direction, j’échange avec votre équipe informatique et avec les fournisseurs, je compare les offres (dans les filiales, au regard des directives d’achat du siège), je conseille sur le suivi de la réalisation et j’aide à préparer le changement dans le travail des équipes, pour qu’après le démarrage elles utilisent vraiment le nouveau système. Un seul entretien, et vous disposez d’un concept en 2 jours environ.

15–20 min
avec la direction — le temps qu’il lui faut pour décrire le problème et l’objectif
~2 jours
jusqu’à un concept ou un prototype abouti, avant tout coût de déploiement
0 réunion
de plus dans l’agenda de la direction, tant qu’aucune vraie décision n’est à prendre
Détail 1pièces sur le bureau d’un ingénieuréchelle 1 : 1photo d’illustrationfeuille 1entreprises

La conduite du changement en entreprise. Des projets typiques et ce qu’ils changent dans le travail des équipes.

En entreprise, le changement est généralement porté par les résultats ou par une décision du siège. Les équipes l’acceptent plus vite lorsqu’elles comprennent ce qu’il signifie pour elles.

Déploiement d’un ERP ou d’un CRM

Ce qui change pour les gens : les ventes, la finance et le service client travaillent sur des données communes plutôt que sur leurs propres tableurs.

La difficulté typique : la pression des résultats rapides et le confort d’Excel : le nouveau système perd face au tableur s’il n’est pas plus pratique dès le premier jour.

Ce à quoi je veille : les chefs de service comme premiers utilisateurs, des indicateurs d’utilisation dès la première semaine et un bilan après le démarrage.

Plateforme de processus et workflow

Ce qui change pour les gens : les demandes, les validations et les réclamations suivent un circuit unique et visible au lieu d’e-mails et d’appels.

La difficulté typique : chaque service a ses exceptions et veut que le système les reproduise toutes.

Ce à quoi je veille : d’abord décrire le processus et s’accorder sur les exceptions avec les responsables, ensuite le système.

Une décision du siège déployée dans la filiale

Ce qui change pour les gens : la filiale adopte un outil ou un processus choisi par le siège.

La difficulté typique : « ce n’est pas notre idée » : l’objectif du siège ne devient pas de lui-même une raison d’agir pour l’équipe locale.

Ce à quoi je veille : traduire l’objectif du siège en bénéfices concrets pour les équipes de la filiale et établir clairement qui porte le changement localement.

Agents IA et automatisation

Ce qui change pour les gens : une partie du travail répétitif est automatisée, et les équipes vérifient les résultats et traitent les exceptions.

La difficulté typique : les craintes pour l’emploi, et l’automatisation d’un processus jamais décrit, qui ne fait qu’accélérer le désordre.

Ce à quoi je veille : d’abord décrire et remettre en ordre le processus, fixer les responsabilités, ensuite automatiser, et parler franchement de ce qui changera dans les rôles.

KSC et NIS 2. Lorsqu’une entreprise fournit des services à des entités couvertes par le KSC, ses clients exigeront d’elle des clauses contractuelles et des preuves. J’aide à préparer les réponses et les documents sans créer de service de sécurité dédié. Le KSC du point de vue de la direction

Ce qu’est la conduite du changement et pourquoi elle est payante

Les questions dont il vaut mieux connaître la réponse.

Je les pose aux membres des directions et aux directeurs financiers, avant le lancement d’un grand déploiement. Si la réponse à l’une d’elles est « nous ne savons pas », c’est précisément là que je peux aider.

  1. Que doit-il changer exactement dans le travail des personnes après la mise en service du nouveau système, et comment le mesurerons-nous ?
  2. Qui, de notre côté, traduit les besoins des utilisateurs en exigences pour le fournisseur ?
  3. Comparons-nous les offres sur un périmètre commun et sur le coût total ?
  4. Comment éviterons-nous que notre service informatique, absorbé par l’exploitation, soit surchargé par le projet ?
  5. Que ferons-nous si le déploiement commence à s’écarter de l’intention de la direction ?

Le coût d’une erreur. Un déploiement d’ERP qui ne répond pas aux besoins des personnes, ce sont des licences, un déploiement et des mois de travail sans effet. Un conseiller coûte généralement moins cher qu’une seule technologie mal choisie, qu’un seul mauvais prestataire ou qu’un seul piège dans un contrat.

Ce que vous y gagnez. Les documents sont un outil, pas une fin en soi.

  • Le temps de la direction15 à 20 minutes d’entretien au lieu de semaines d’ateliers. Des décisions uniquement là où elles sont vraiment nécessaires.
  • Moins d’erreurs dans les projets ERP et autres déploiementsL’objectif et la définition du succès sont arrêtés avant le choix du fournisseur.
  • Un fournisseur tenu à des résultatsDes exigences, des critères de recette et un registre des modifications sur lesquels vous pouvez vous appuyer.
  • Des équipes qui utilisent réellement le systèmeConduite du changement et référents dans chaque service, pour que le déploiement ne reste pas lettre morte.
  • Des dépenses moindresUn outil adapté au problème — et parfois la décision qu’aucun nouveau système n’est nécessaire.
Wojciech Kroczak
Wojciech KroczakConseiller en conduite du changement et transformation numérique. 2017–2026 : une filiale industrielle d’un groupe étranger. 2016–2026 : un holding international — banque, leasing, assurance.

Pour le siège. Krogis est un conseiller indépendant auprès de la direction locale d’une filiale polonaise. D’un entretien de 15 minutes avec la direction, je tire un concept en deux jours, je rédige des exigences exploitables par l’équipe informatique et les fournisseurs, je compare les offres aux règles d’achat du groupe et je représente la direction pendant la mise en œuvre. Aucune vente de logiciels, aucun lien avec des fournisseurs. Une synthèse d’une page en anglais est disponible sur demande.

La direction a une décision à prendre. Personne n’a le temps de la formaliser.

La direction sait exactement quel problème elle veut résoudre et quel risque elle veut écarter — et le formuler prend un quart d’heure, pas une semaine d’ateliers.

Face à une consigne générale, l’informatique interne commence par multiplier les réunions et chercher des solutions toutes faites — avant que quiconque ait écrit noir sur blanc ce dont on a réellement besoin.

Sans concept ni prototype, il est difficile de juger si une idée a seulement un sens économique — la décision oui/non se prend au jugé plutôt que sur du concret.

Une fois le projet lancé, soit la direction se retrouve entraînée dans des réunions de travail pour lesquelles elle n’a pas de temps, soit, à l’inverse, elle ne voit plus si la réalisation reste fidèle à son intention de départ.

Cette offre ne s’adresse pas aux entreprises qui disposent déjà d’un DSI expérimenté siégeant à la direction. Krogis est pertinent là où la direction est très impliquée dans l’activité quotidienne et où le service informatique est petit, composé d’informaticiens plutôt que de managers, et absorbé par la maintenance — comme dans les filiales de grands groupes industriels et financiers, dans les sociétés de services et d’assurance ou dans les caisses coopératives d’épargne et de crédit.

Nous voulons acheter un marteau, parce que… nous devons accrocher un tableau.

Les entreprises ont souvent du mal à formuler ce qu’elles veulent, parce qu’elles ne savent pas ce qu’il est possible de demander. La direction dit : « nous devons acheter un système » ; après une série de questions d’approfondissement — « à quoi ce système doit-il servir, qu’en attendez-vous, que se passera-t-il selon vous après la mise en production ? » — apparaît souvent la définition du problème réel : « nous voulons traiter les réclamations plus vite, produire facilement des rapports, réduire les coûts, respecter les directives du siège, augmenter la rentabilité des ventes dans le canal A ».

Je m’enquiers de l’objectif et de ce qui vaudra succès, puis je mène l’analyse avec méthode jusqu’à atteindre le véritable objectif, souvent caché derrière la première idée de système.

  1. La demande« Nous voulons acheter un système de circuit des factures. »

    Le besoin réel
    • remettre à plat l’ensemble de la politique d’achat,
    • décrire et optimiser les processus, de la demande d’achat à la commande et au contrat, jusqu’aux pièces de dépenses,
    • des règles de gestion des fournisseurs.
  2. La demande« Il nous faut un CRM. »

    Le besoin réel
    • cartographier le cycle de vie des données des tiers : quand et dans quels systèmes un tiers est enregistré, qui en est responsable et quels événements de gestion doivent faire apparaître les données du client dans d’autres systèmes,
    • des procédures structurées et numérisées pour le circuit des offres,
    • une approche par les processus de l’enregistrement, de la mise à jour et de la vérification des données des tiers,
    • des outils qui facilitent la préparation des offres,
    • des moyens d’automatiser le marketing,
    • des moyens d’automatiser l’action commerciale,
    • une analyse du sentiment dans les échanges avec les prospects et les clients existants.

    Un terminal à conteneurs. Il ne s’agissait pas d’un CRM classique et simple, mais d’une amélioration de la relation client fondée sur les processus.

  3. La demande« Avez-vous un module marketing pour le CRM ? »

    Le besoin réel
    • un outil de gestion de la relation avec les parties prenantes (stakeholder relationship management), et non un module commercial de plus.

Je commence par des questions que les entreprises se posent rarement : à quoi ressemble votre avenir idéal, qu’est-ce qui vous pose problème aujourd’hui, pourquoi faisons-nous cela, qu’est-ce qui vaudra achèvement, et selon quels critères jugerons-nous que le projet est un succès. Plutôt que d’aller tout de suite voir un fournisseur qui « a un système pour ça », nous nous accordons d’abord sur l’objectif. Je sais décrire et analyser des processus, mais surtout, je dirige l’analyse et le questionnement : au sein de l’organisation, dans les définitions et dans les échanges avec les fournisseurs. Vous ne perdez pas de temps et vous arrivez plus vite au résultat que vous visez réellement.

Qui fait quoi lorsque vous déployez un système.

Réclamations, circuit des pièces de dépenses, demandes d’intervention : le mécanisme est le même, quel que soit le module.

Direction

Décrit le problème et l’objectif en 15 à 20 minutes. Ne tranche qu’aux étapes qui l’exigent vraiment : le concept, le choix du fournisseur, la recette.

Krogis

Un concept ou un prototype, des exigences et des scénarios de test, des questions aux fournisseurs, une matrice comparative fondée sur les directives d’achat du siège, et la représentation de la direction au sein de l’équipe projet et lors de la recette. Le prototype doit être présenté à la direction le plus tôt possible, pour confirmer les objectifs et les besoins auxquels il doit répondre et les irritants qu’il doit supprimer. Ce n’est qu’une fois sûrs de la bonne direction et de la définition du succès du projet que nous engageons le travail de fond avec les services et que nous commençons à rencontrer les fournisseurs.

Service informatique et fournisseur

Construisent la solution, l’intègrent à l’ERP et la maintiennent, sur la base d’exigences dont on peut exiger le respect. Votre équipe informatique interne reçoit une tâche déjà traduite en quelque chose d’exécutable.

Coupe B–Brépartition des responsabilitéséchelle 1 : directiondessin de principefeuille 2déploiement d’un système

Est-ce votre cas ? Quatre points à connaître avant le premier échange.

Ce qui le trahit souvent

Il arrive fréquemment que votre service informatique ait déjà fort à faire avec l’exploitation, et que le projet attende quelqu’un pour rédiger les exigences. Le fournisseur est parfois celui qui propose lui-même le périmètre et le calendrier. Le siège ou la direction demande un point d’avancement, et la réponse doit être reconstituée à partir de plusieurs sources. La documentation du projet se constitue de façon inégale : on ne sait pas toujours qui en est l’auteur, qui en est le propriétaire, ni si elle est validée.

Ce qui peut se passer si vous attendez

Le périmètre peut s’étendre au fil des modifications demandées en cours de route, le coût et le délai dérivent, et la recette repose sur les déclarations du fournisseur. Les nouveaux collaborateurs informatiques arrivent alors dans le projet sans connaissances structurées.

Qui est généralement le sponsor

Le plus souvent un membre de la direction (le directeur financier ou le directeur des opérations), responsable du résultat métier du déploiement.

Ce que je ne fais pas

Je ne suis pas le chef de projet du fournisseur. Je ne réponds ni du déploiement ni du respect des délais par vos collaborateurs, mais je vous aide à les suivre : je fais ce pour quoi la direction manque souvent de temps, c’est-à-dire que je veille à ce qu’on voie clairement comment le projet avance, qui est responsable de quoi et ce qui exige une décision.

Le plus petit premier pas sans risque : un échange de 30 minutes sans frais. À partir de 15 à 20 minutes d’échange avec la direction, je prépare en 2 jours environ une conception, sans engager de coûts de déploiement.

Plusieurs projets en parallèle, et le siège veut un point d’étape. Qui le rassemble ?

Déploiement de l’ERP, CRM orienté processus, circuit des documents sous KSeF, remise en ordre de la documentation : le service informatique exploite les systèmes, et les projets restent souvent sans coordinateur permanent. La direction dispose alors de peu de temps et d’une vision incomplète.

J’assume le rôle de coordinateur permanent aux côtés de la direction (dans le langage des grandes organisations : le PMO, c’est-à-dire le bureau des projets). Une vue unique des projets, des points d’avancement réguliers et un rapport, y compris en anglais pour le siège.

  • Une liste de projets avec étapes, échéances, responsables, dépendances et points de blocage, assortie d’un statut vert, orange ou rouge.
  • Une réunion d’avancement hebdomadaire ou bimensuelle, un compte rendu, une liste d’actions et des échéances.
  • Des registres des risques, des décisions et de la documentation : qui en est l’auteur, qui en est le responsable et à quel stade de validation elle se trouve.
  • La coordination de l’information entre l’équipe, les responsables des tâches et les fournisseurs, et l’escalade lorsque le dossier est bloqué.
  • La direction reste maîtresse des décisions, du budget et de l’exécution. Je ne prends pas la responsabilité du déploiement, je veille seulement à ce que l’on voie clairement comment il avance.

Périmètre de la coordination et du suivi permanent des projets

Déployer un ERP ou un autre système majeur. Quatre moments où la direction a besoin de quelqu’un à ses côtés.

Votre équipe informatique veille à ce que tout fonctionne au quotidien. Un projet de déploiement est un autre métier : il faut décrire les besoins, choisir un fournisseur, mener les discussions et obtenir le résultat attendu. Je peux intervenir sur l’une de ces étapes ou tenir le cap avec vous du début à la fin.

  1. Préparation et exigences

    Un inventaire des processus, systèmes, données et intégrations que le nouveau système doit reprendre ou remplacer. Un responsable métier mandaté par la direction, des objectifs à vérifier après la mise en service et des exigences rédigées dans la langue de vos processus, plutôt qu’une liste de fonctionnalités tirée de la plaquette d’un fournisseur.

  2. Choix d’un fournisseur ou d’un intégrateur

    Un appel d’offres, des démonstrations sur vos propres scénarios, des offres ramenées à un périmètre commun et comparées dans une matrice : coût total sur plusieurs années, équipe, méthode de travail, conditions de maintenance et de sortie.

  3. Échanges avec l’informatique et supervision de la réalisation

    Je représente la direction dans les réunions avec le fournisseur et avec votre équipe informatique, et je garde la maîtrise du périmètre, du calendrier et des décisions de modification. La direction reçoit de courtes synthèses et ne revient sur le sujet que lorsque sa décision est nécessaire.

  4. Recette et clôture

    Une recette fondée sur des scénarios de test et des critères convenus, une migration des données vérifiée, la documentation et les formations. Un contrat de maintenance qui ne vous rend pas plus dépendant d’un seul fournisseur que nécessaire.

La durée dépend de l’organisation et du projet : du degré de préparation de l’entreprise, de sa culture et du mandat que la direction confie au projet. C’est pourquoi nous fixons le calendrier après le premier entretien, et non sur la base d’une grille tarifaire.

Les questions que l’on me pose avant un déploiement

Comment préparer l’entreprise au déploiement d’un ERP ?

Avant de parler aux fournisseurs, recensez l’existant : les processus, systèmes, données, intégrations et contrats que le nouveau système doit reprendre ou avec lesquels il devra fonctionner. Désignez un responsable métier mandaté par la direction et convenez de la manière dont vous saurez que le déploiement a réussi. Décidez où vous adopterez les processus standard du système et où votre propre processus constitue un avantage concurrentiel à préserver. Des exigences rédigées dans la langue de vos processus permettent de comparer les offres, puis de tenir le fournisseur à ses engagements. Un bon point de départ est un inventaire.

Qui doit piloter le déploiement de notre côté si notre équipe informatique est occupée par la maintenance ?

Il faut deux rôles : un responsable métier qui décide des processus, et une personne côté client qui veille au périmètre, aux délais et aux décisions. L’informatique répond des intégrations, de l’infrastructure et de la maintenance ultérieure, mais ne devrait pas décider seule de la manière dont doivent fonctionner les ventes ou la comptabilité. J’accompagne cette seconde personne en tant que conseiller de la direction : je l’aide à tenir le périmètre et le calendrier, je prépare les décisions et je dialogue avec les fournisseurs, aux côtés de votre équipe informatique, et non à sa place.

Comment choisir un intégrateur et comparer des offres qui diffèrent par leur périmètre et leur prix ?

Commencez par ramener les offres à un périmètre commun : une seule matrice d’exigences, dans laquelle chaque fournisseur répond aux mêmes questions. Comparez le coût total sur plusieurs années (licences, déploiement, maintenance, évolutions), et pas seulement le prix d’entrée. Demandez une démonstration sur vos propres scénarios, et examinez à la fois l’équipe qui travaillera réellement sur le projet et les conditions de fin de contrat.

Comment dialoguer avec un fournisseur quand on n’a pas d’analyste métier ?

Au lieu de demander ce que le système sait faire, présentez des cas réels tirés de la vie de votre entreprise et demandez comment le système les traiterait. Consignez ce qui a été convenu et revenez-y lors des réunions suivantes. Il est précieux d’avoir à vos côtés quelqu’un qui parle à la fois la langue de la direction et celle du fournisseur — c’est le rôle que je joue : je prépare les questions, je mène les échanges et je traduis les réponses en conséquences concrètes pour l’entreprise.

Que faire lorsque le déploiement prend du retard ou que le périmètre s’écarte des besoins réels ?

Marquer une pause pour faire le point avant que le problème ne s’aggrave : ce que prévoit le contrat, ce qui a changé sans décision, et quelles fonctionnalités sont vraiment nécessaires au démarrage. Un registre des modifications et des décisions aide, tout comme un échange avec le fournisseur fondé sur des faits plutôt que sur des impressions. La direction dispose alors d’une évaluation indépendante de l’état du projet et d’options pour la suite.

Comment réceptionner un système livré par un fournisseur, et à quoi faut-il veiller dans un contrat de maintenance ?

La recette doit reposer sur des scénarios de test et des critères convenus à l’avance, et non sur une impression générale. Vérifiez la migration des données, la documentation et la formation de votre équipe. Dans le contrat de maintenance, examinez de près les niveaux de service et les délais d’intervention, le coût des évolutions, l’accès à vos propres données et à la documentation, ainsi que les conditions de fin de contrat.

Une plateforme de processus à côté de l’ERP, pas à sa place.

Les données des tiers n’entrent dans l’ERP qu’au moment d’un événement de gestion — or la correspondance, y compris l’intégration avec e-Doręczenia (le service public polonais de notification électronique), concerne aussi des interlocuteurs qui n’apparaîtront peut-être jamais dans l’ERP. Là où l’ERP seul ne suffit pas, nous concevons une plateforme de processus distincte, intégrée à l’ERP et aux systèmes centraux du client, et adaptée à cet ERP précis comme aux spécificités de l’organisation.

La chaîne achats

Demande d’achat, commande, contrat, gestion de la relation fournisseurs, négociation, circuit des pièces de dépenses, évaluation des fournisseurs — une cartographie de processus unique au lieu de tableurs et d’e-mails épars.

Les processus à côté des achats

Processus RH, sortie d’échantillons du magasin, réclamations internes, externes, clients et fournisseurs — avec les mêmes règles d’intégration et de propriété des données que pour les achats.

Le directeur général voulait rendre le travail du service juridique plus facile à contrôler. Il n’avait pas le temps pour une réunion de 2 heures avec un analyste.

Un module d’assistance juridique dans une entreprise de chauffage urbain. Le directeur général souhaitait que le service juridique déclare son temps de travail et reçoive les demandes selon la logique d’un helpdesk — au lieu de simplement savoir combien de dossiers juridiques l’entreprise comptait et ce qu’ils coûtaient. Son intention : que le service juridique, parfois dispersé entre plusieurs sites, soit aussi contrôlable et redevable que les cabinets d’avocats externes qui lui adressent chaque fin de mois un compte rendu complet — qui a travaillé sur quoi, et combien de temps a été consacré à chaque dossier et à chaque demande. La direction n’avait le temps ni pour des heures de réunion avec un analyste ni pour rédiger des exigences : elle voulait voir un concept abouti.

  1. 1

    Entretien

    15 à 20 minutes avec la direction : ce qu’elle veut suivre, pourquoi, et quel résultat visible elle attend.

  2. 2

    Concept

    En 2 jours environ : un modèle de demandes sur le principe d’un helpdesk, un registre des dossiers et le suivi du temps des juristes.

  3. 3

    Décision

    La direction évalue un concept abouti, et non une idée esquissée sur le papier — la décision de construire ou non se prend sur du concret.

  4. 4

    Déploiement

    Krogis représente la direction au sein de l’équipe projet — la direction n’est sollicitée que pour les vraies décisions.

Résultat : le service juridique de cette même organisation dispose aujourd’hui d’une archive électronique des procédures d’achat et d’un module d’assistance juridique, réalisés sous forme de projets successifs, chacun s’appuyant sur le précédent, selon le même mécanisme : la direction formule son intention, Krogis la traduit en action.

D’un seul entretien à un rôle permanent de représentant de la direction.

Ce même mécanisme a fait ses preuves au fil de longues années de collaboration avec une filiale industrielle et une filiale financière de groupes étrangers : un rôle de traducteur entre le groupe et la direction locale, exercé directement auprès de la direction, du directeur financier et de la cheffe comptable.

  1. 01

    Un concept ou un prototype issu d’un seul entretien

    15–20 min + ~2 jours

    Un entretien avec la direction sur le problème et l’objectif, sans ateliers et sans mobiliser le service informatique au départ. Un concept ou un prototype abouti, versé à l’étude préalable à la décision — avant tout coût de déploiement.

  2. 02

    Spécifications pour la réalisation

    Délai fixé après le premier échange

    Une fois le concept validé : exigences, modèle de données, intégrations et scénarios de test, traduits dans des termes sur lesquels votre service informatique (interne ou prestataire externe) peut agir — et, si nécessaire, une matrice comparative fondée sur les directives d’achat du siège ainsi que la participation aux échanges avec les fournisseurs.

  3. 03

    Le représentant de la direction dans l’équipe projet

    Pour la durée du projet

    Particulièrement utile pour un grand projet imposé par le siège, comme la migration vers un ERP central commun : réunions avec les fournisseurs, discussions sur l’intégration avec les systèmes locaux, et veille à ce que la réalisation reste fidèle à l’intention de départ. La direction, accaparée par ses responsabilités courantes dans ses propres domaines — finances, ventes, marketing —, reçoit des synthèses condensées à l’appui de ses propres décisions et de sa communication avec le siège et le service informatique, au lieu de suivre le projet au jour le jour. Les sujets ne remontent à la direction que lorsque sa décision est nécessaire.

  4. 04

    Conseiller en transformation numérique

    Accompagnement continu

    De nouveaux concepts et projets bâtis sur le même mécanisme, la traduction des exigences du siège du groupe en actions locales, et une vision à jour des cas où des entreprises comparables ont payé trop cher leurs choix technologiques.

  1. 2017–2026Filiale industrielle d’un groupe étranger

    « Neuvième année de développement de la même plateforme dans l’entreprise — en travaillant directement avec la direction, le directeur financier et la cheffe comptable, comme pilote de la conduite du changement et non comme fournisseur de technologie. »

    Circuit des achats et des factures pour un groupe industriel international. Pilotage de la conduite du changement auprès de la direction, du directeur financier et de la cheffe comptable.

  2. 2016–2026Holding international — banque, leasing, assurance

    Déploiement d’une plateforme de gestion des processus métier (BPM), conception et déploiement d’une solution de type procure-to-pay, gestion des déplacements professionnels et intégration avec les applications métier (OCR, KSeF). Adaptation de la solution aux procédures d’achat du groupe.

  3. FinanceCaisses coopératives d’épargne et de crédit (SKOK)

    Déploiements de systèmes et collaboration suivie avec les caisses.

À qui s’adresse cette page.

  • Directeur général, membre de la direction, propriétaire

    Répond du résultat du projet devant le conseil de surveillance, le propriétaire ou le siège — et dispose du moins de temps pour formuler des exigences informatiques. Dans une filiale, il rend des comptes à la fois à la direction locale et au siège.

  • Directeur financier

    Doit concilier les besoins opérationnels locaux avec les directives d’achat et les standards du siège — et a besoin de quelqu’un qui parle les deux langues.

  • Responsable informatique avec une petite équipe

    Un allié, à condition que le concept de la direction lui parvienne déjà traduit en quelque chose d’exécutable — et non comme une énième demande floue du type « faites quelque chose ».

Les questions les plus fréquentes avant de commencer.

En combien de temps l’idée d’une direction peut-elle devenir un concept d’application ?

L’entretien avec la direction dure à lui seul 15 à 20 minutes — le temps de décrire le problème, l’objectif et les contraintes. Un concept ou un prototype abouti suit en deux jours ouvrés environ, avant tout coût de déploiement, comme base de décision plutôt que comme matière à de nouvelles spéculations.

Est-ce compatible avec les directives d’achat du siège ?

Oui. Les directives d’achat du siège sont intégrées à la matrice comparative et aux exigences dès le premier jour, au lieu de surgir comme une condition au moment de la signature. La direction reçoit une comparaison des offres dans un format que le siège comprend, en anglais si nécessaire.

Quelle différence avec le recrutement d’un analyste métier ou d’un product owner ?

Un analyste ou un product owner occupe généralement un poste permanent dans l’organigramme, qu’il vous faut encadrer vous-même et familiariser avec le contexte de l’entreprise. Krogis arrive en sachant déjà travailler au niveau de la direction, intervient en mode projet (d’un concept isolé à une collaboration suivie) et représente aussi la direction à l’extérieur — auprès des fournisseurs et de l’équipe projet, et pas seulement au sein d’un projet donné.

Ce service a-t-il un sens si nous avons déjà un service informatique ?

Oui, tant que le service informatique est petit et composé d’informaticiens plutôt que de managers chargés de la relation avec la direction. Un concept préparé avec la direction parvient à l’informatique déjà traduit en quelque chose d’exécutable, ce qui accélère son travail au lieu de lui faire concurrence. Ce n’est pas adapté là où un DSI expérimenté siège déjà à la direction.

Concrètement, en quoi consiste la représentation de la direction dans l’équipe projet ?

Il s’agit de participer aux réunions de travail courantes au nom de la direction, de veiller à ce que la réalisation ne s’écarte pas de l’intention de départ et de ne faire remonter les sujets à la direction que lorsque sa décision est nécessaire. La direction est tenue informée de l’avancement, sans devoir assister à chaque réunion — elle regagne du temps sans perdre la maîtrise.

Parlez-moi du problème de votre direction. Vous aurez un concept deux jours après notre entretien.

Écrivez à : wojciech.kroczak@krogis.pl Appelez le +48 516 401 658
  • Je réponds dans les 2 jours ouvrés
  • Premier appel : 30 minutes, gratuit
  • L’entretien peut se dérouler en polonais ou en anglais