Get best of the week

Modélisation des processus métiers dans le cadre d'un projet d'implémentation d'un système ERP

Avant de lancer un autre projet pour mettre en œuvre un système d'information couvrant la plupart des domaines de fonctionnement de l'entreprise, j'ai décidé d'écrire une série d'articles avec mes réflexions sur la raison pour laquelle les grandes entreprises industrielles, en particulier celles qui fonctionnent depuis des décennies, ont plus de la moitié des projets ERP " ils ne décollent pas. " J'écrirai ces articles plus pour moi-même comme une «sclérose» pour former des conversations avec les cadres supérieurs de l'entreprise et structurer les considérations que j'ai faites en fonction de mon expérience.

Ces articles ne sont pas destinés à dire au monde à quel point je suis cool ou ce que je sais le mieux sur la façon de mettre en œuvre de tels projets. Si vous dites que c'est «un autre article d'un perdant qui, eh bien, comprend mal tout», ce sera une valeur pour moi aussi, car je m'attends à ce que quelqu'un partage ses réflexions dans les commentaires.

La mise en œuvre de tels systèmes pose de nombreux problèmes. Si vous construisez correctement une liste de contrôle des risques du projet de mise en œuvre du système ERP, cela prendra plus de cent lignes et deviendra probablement une assez bonne justification pour expliquer pourquoi la mise en œuvre du système ERP ne peut jamais commencer dans la vie. Néanmoins, des projets réussis existent, la nécessité de l'introduction de tels systèmes est également confirmée à plusieurs reprises, ce qui signifie que l'introduction de tels systèmes n'est pas une tâche impossible.

Pour ma part, je divise tous les problèmes qui entravent la réussite de la mise en œuvre du projet en trois catégories:

  1. Politique, causée par l'inadéquation des objectifs déclarés du projet avec les attentes internes des participants au projet
  2. Fonctionnel, causé par le manque de compétences des participants au projet
  3. Technologique, causée par la sous-estimation des ressources nécessaires, du temps

C'est assez grand et arbitraire, mais cela m'aide personnellement lors du classement des risques pour évaluer la probabilité d'une mise en œuvre réussie du système.

Je n'ai aucune expérience dans la mise en œuvre de grands systèmes de production utilisant Agile ou toute autre méthodologie autre que la «cascade» standard, qui comprend les principales étapes suivantes:

  1. Une enquête sur l'entreprise, une description des processus commerciaux "tels quels", "tels qu'ils seront".
  2. Création d'un modèle de système d'information.
  3. Développement et mise en œuvre des savoirs traditionnels.
  4. Test de fonctionnement.
  5. Opération pilote.

Par conséquent, la description des tâches et des risques que je souhaite structurer dans ma tête est liée à la méthodologie de la cascade et peut ne pas être entièrement applicable aux technologies permettant d'obtenir des résultats rapides.

Il serait probablement plus opportun de commencer par une description des tâches qui doivent être accomplies avant le lancement du projet, telles que l'identification d'un client fonctionnel, la réunion des équipes de projet, la formation et l'évaluation des critères de réussite du projet.

Mais jusqu'à présent, je n'ai pas structuré ces considérations et les ai mises dans une boîte séparée.
Par conséquent, pour lire l'article suivant, nous le prendrons «pour acquis»: le besoin de mise en œuvre est fixé, un client fonctionnel est trouvé et est en feu avec le projet, le budget est trouvé, les équipes de projet sont correctement assemblées, les ressources pour la mise en œuvre sont identifiées.

Dans le premier article, je voudrais fixer les tâches et les risques du projet de modélisation des processus métier. C'est loin d'être le problème le plus critique qui était disponible au stade initial du projet, mais comme le stade de l'inspection d'entreprise commence par la modélisation des processus commerciaux «tels quels» et «comme il se doit», j'ai décidé de commencer par cela.

Je vais donc commencer

Il est difficile d'imaginer que l'un des propriétaires ou des cadres supérieurs d'une grande entreprise industrielle ait acquis un système ERP pour la mode. D'une manière ou d'une autre, si vous avez commencé à parler d'acquérir un système, la haute direction n'est pas satisfaite des analystes existants pour prendre des décisions, des processus commerciaux existants, de la rapidité et de la qualité des changements qui y sont apportés (nous ne prenons pas en compte l'acquisition d'un système ERP pour le blanchiment d'argent ou politique, fins d'image).

Les processus métier existent toujours dans une entreprise et peu importe qu'ils soient documentés ou non. De plus, dans une grande entreprise industrielle, il est probable que les processus commerciaux réels dans une partie substantielle ou ne coïncident pas complètement avec les processus commerciaux documentés. D'une manière ou d'une autre, la demande d'expédition parvient toujours à l'entrepôt, les économistes calculent toujours les besoins de production et le maître génère toujours une tâche journalière dans un système, en utilisant un crayon sur une carte perforée ou un «edra de la mère» verbal.

Une autre question est que ces processus métier établis ne sont pas optimaux, redondants, et parfois ils manquent également de valeur à la fois pour l'entreprise et pour le participant au processus métier. À titre d'exemple, il s'agit de la formation d'une sorte de rapport de gestion, dont tout le monde a déjà oublié la nomination, personne n'en analyse le contenu et la nécessité de créer ce rapport est argumentée au niveau de «Maria Ivanovna demande toujours de le faire, mais pourquoi, Dieu sait, lui demander sa. "

Bien sûr, personne ne veut faire glisser ces processus commerciaux non optimaux dans un système ERP. En théorie, au stade de la conception du système, la direction déclare des objectifs d'optimisation des processus métier et de leur régulation. Et souscrit même à la thèse de «maximiser le modèle des processus commerciaux existants de l'entreprise sous la fonctionnalité typique du système mis en œuvre».

En pratique, tout semble beaucoup plus déplorable. Les artistes ordinaires ne sont pas prêts à changer les processus métier, même les plus élémentaires. Peut-être que c'est personnellement ma pratique infructueuse de travailler au bal. entreprises, c'est peut-être une vraie tendance, mais ne vous attendez pas à ce que la phrase "maintenant vous n'avez pas besoin de porter un ordre de dépenses pour approbation à pied sur 3 kilomètres, mais peut être fait automatiquement dans le système en 3 secondes", vous recevrez un plaisir en réponse. Un artiste ordinaire, dont le travail consistait en 60% du temps avec des documents, décide immédiatement qu'il sera licencié, il se verra attribuer des emplois auxquels il ne pense pas ou réduira son salaire. La logique dans ses considérations n'est pas toujours présente, mais l'employé ordinaire peut très clairement résister aux changements. De plus, comme au stade de la collecte des exigences du système,quand il prouvera la valeur de simplement courir avec des papiers («Et MikhalKuzmich du département du budget de l'organisation principale a dit qu'ils n'acceptaient que la numérisation d'un document avec toutes les signatures de notre part»), et au stade du fonctionnement du système, quand il imprime simplement les commandes de l'ancien système et portez-les avec vos pieds ("mais personne ne m'a dit que le nouveau système fonctionne déjà", "oh, oui, c'est plus rapide avec mes pieds", "mais je les ai envoyés vers ce système et personne n'a répondu là-bas", etc.)«Je l'ai envoyé à ce système, et personne n'y a répondu», etc.).«Je l'ai envoyé à ce système, et personne n'y a répondu», etc.).

Loin d'être toujours prêt pour des changements dans les processus d'affaires et les cadres intermédiaires et même les cadres supérieurs. L'évolution des processus opérationnels entraîne une modification des fonctions du personnel subalterne et est en mesure d'identifier à la fois une pénurie de personnel qualifié et la libération de personnel en raison d'une réduction des coûts de main-d'œuvre pour l'exécution de certaines fonctions. Il s'agit d'un facteur politique caché qui peut grandement influencer la prise de décision sur l'évolution des processus métier. Au stade initial de la conception du système, il peut être perçu comme insignifiant et résolu sur le plan organisationnel au niveau du propriétaire du processus. Mais au stade d'une opération industrielle de test ou pilote avec un manque de potentiel managérial, la mise en œuvre du processus métier peut même conduire à saboter le travail de projet par les cadres intermédiaires.Le manque de ressources peut être détecté déjà pendant l'OPE et affecter directement le cours des opérations, et la sous-disponibilité ou l'indisponibilité de qualification du personnel sera cachée par le gestionnaire sous prétexte de la complexité de faire fonctionner «this your system» et entraîner des exigences pour changer le nouveau système en processus métier existants.

Même les propriétaires de processus et la haute direction peuvent ne pas être prêts pour des changements dans les processus métier. Les sorties clés d'un processus métier sont des entrées vers un autre processus métier. Et cette banale règle de modélisation des processus métiers tient bien sur le papier, mais rencontre une forte résistance dans la pratique. Les raisons de l'incohérence des processus opérationnels dans ce cas sont de nature politique et la solution à ces incohérences est plutôt douloureuse.

Une situation de manuel lorsqu'un plan de vente est approuvé dans l'entreprise indépendamment du plan de production. Et lors de l'élaboration d'un plan d'approvisionnement, ni un plan de vente ni un plan de production ne sont pris en compte. Au stade du flux de travail papier, ces lacunes dans les processus métier ne sont pas visibles si clairement, ou plutôt, elles sont visibles, mais les propriétaires de processus ont appris à les traiter au niveau opérationnel. Chacun des dirigeants se rend chez le directeur pour signer seul son plan. Et il fait une analyse des faits de plan exclusivement en fonction de son plan. Dans le même temps, l'intégrité de l'image de vie de l'entreprise est perdue, les ruptures d'analystes sont reconnues comme pratiquement inévitables, la gestion des cadres supérieurs est effectuée manuellement sur la base de données non pertinentes et incomplètes.

Il est nécessaire d'identifier ces contradictions et lacunes dans les processus commerciaux le plus tôt possible et de prendre leur décision au plus haut niveau. La carte stratégique élargie des processus opérationnels «comment le sera» devrait être perçue et soutenue par les propriétaires de processus comme une constitution. Le système ERP introduit ne résoudra pas automatiquement ces contradictions et incohérences des processus métier, ne les enterrera pas, mais les ramènera à la surface et résoudra ces problèmes pendant la phase d'exploitation sera beaucoup plus cher. Et la fixation tardive des lacunes des processus métier conduit très souvent soit à la suspension du projet avec toutes les conséquences, soit à l'automatisation par morceaux et à la déviation des objectifs du projet.

Que peut-on faire pour le changement le plus productif des processus métier?


  1. - « » -, -. , , . , 8 , . - , . 10 .

    , - . , - - . - -. ( « , , »), , .
  2. - . - . , , . , , .
  3. - . -, . , -, . , . , -, , , « » . . , . , 10 - , , , .
  4. . ERP-, -. . - - . - , , .
  5. , ERP-, « ». , .
  6. KPI -. KPI , ..

Résumé: Je pense qu'un projet de mise en œuvre d'un système ERP aura beaucoup plus de chances de réussir si tous les participants au projet de la part du client partagent la thèse que le système d'information sert à automatiser les processus métier EXISTANTS, est prêt à les structurer, à mettre des informations sur les étagères, préparer l'analyse, mais elle ne remplace pas le cerveau des artistes interprètes et ne sera pas une bouée de sauvetage si la direction de l'entreprise elle-même n'est pas prête à faire face au chaos existant.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles