On sait que les déclarations marketing des vendeurs s'écartent parfois sérieusement de la réalité. Cependant, il est généralement admis que les acteurs du marché dignes de confiance n'ont pas recours à une telle pratique. Cependant, le chef de projet d'implémentation de SAP Business One dans une petite Entreprise russe J'étais convaincu par expérience personnelle que "rien d'humain n'est étranger" aux entreprises respectables.

Bord de survie

Il y a quelques années, presque tous les développeurs mondiaux de systèmes ERP ont commencé à se diriger vers le segment des PME, qui a été déclaré presque le plus prometteur et le plus prioritaire. De nouveaux produits ont été introduits sur le marché, destinés aux petites entreprises avec de petits budgets informatiques. Le marché russe des applications d'entreprise n'a pas fait exception. Des articles convaincants sont parus dans la presse nationale informant les hommes d'affaires russes que face à une concurrence plus rude (y compris l'adhésion à l'OMC), ils ne pourront pas survivre s'ils ne disposent pas d'un système moderne et automatisé comptabilité de gestion, planification et contrôle. Les arguments présentés étaient assez convaincants. En conséquence, la direction de nombreuses petites et moyennes entreprises en Russie réfléchit sérieusement à la transition "vers quelque chose de mieux qu'Excel et 1C". Notre société appartient également au segment des PME et, en raison des facteurs ci-dessus, a accepté l'offre de l'un des partenaires de SAP Corporation d'introduire un nouveau produit pour le marché - SAP Business One (B1).

Comme il ressort des brochures publicitaires, des produits logiciels modernes conformes aux normes mondiales généralement acceptées sont enfin devenus disponibles pour les petites entreprises en Russie. Il s'agissait d'une fonctionnalité étendue, d'un prix abordable et de plusieurs mois de mise en œuvre. Une seule chose a été tue - que les petites entreprises risquent beaucoup plus lorsqu'elles entrent dans le jeu de la "mise en œuvre de logiciels d'entreprise", car, malgré les modestes, par rapport aux projets sensationnels, le budget, l'investissement dans l'informatique pour ne pas grande entreprise- un poste significatif dans ses coûts. Et en termes d'échelle commerciale, l'introduction d'une «belle boîte outre-mer» peut vraiment mettre une entreprise au bord de la survie.

Voici une nouvelle tournure

SAP n'a pas fait exception dans la course mondiale aux PME et a annoncé il y a quelques années "des changements majeurs dans le portefeuille de produits de l'entreprise" et la décision de faire un "virage total vers le marché des PME" et d'inclure dans sa gamme de produits solution axée sur les petites entreprises en croissance. Par ailleurs, il a été annoncé que le marché des solutions SMB est l'une des priorités de SAP. Directeur général SAP CEI Alexeï Chlykov a ensuite commenté cette étape comme suit : "SAP a reconnu le moment où le marché des grandes entreprises, sur lequel se concentraient en premier lieu les applications métier de l'entreprise, était proche de la saturation, et il était temps de chercher les prochains marchés de vente. "

En conséquence, en 2003, une version localisée de SAP Business One a été introduite sur le marché russe - une solution fondamentalement différente de ce que SAP faisait auparavant. Cependant, SAP Business One n'est pas le développement d'une société allemande : le produit a été acheté à des développeurs israéliens. Il est curieux que la sortie de SAP Business One n'ait pas été accompagnée d'un déploiement à grande échelle campagnes publicitaires- tous les efforts de promotion se sont traduits par plusieurs articles informatifs dans la presse et une série de séminaires régionaux, qui pour clients potentiels organisé par les partenaires SAP. Il a également été officiellement annoncé que le coût d'un lieu de travail « clé en main » (licences plus conseil de mise en œuvre) serait de 2 500 € à 3 000 €, et la durée de mise en œuvre ne dépasserait pas 8 semaines. De plus, on savait que le produit présentait un avantage significatif par rapport aux propositions alternatives - il est personnalisable, il n'a pas besoin d'être programmé, contrairement aux solutions 1C, et il contient déjà des processus commerciaux prêts à l'emploi.

En fait, lors de la vente directe de notre société, il a été déclaré: "Dans 2 mois, nous présenterons le produit et vous disposerez d'un système de comptabilité de gestion à part entière." Dans ce informations de commercialisation sur le produit ne correspond pas à sa véritable essence, nous avons été convaincus par notre propre expérience plus tard. Jusqu'à présent, tout a semblé très convaincant. Nous avons également été impressionnés par les vidéos de démonstration de la solution présentées par le partenaire SAP (une entreprise respectée et implantée de longue date dans notre région). De plus, l'argument le plus convaincant a été avancé - "vous êtes sous l'aile d'une marque SAP fiable". Et cela a dissipé tous nos doutes.

dure réalité

Après trois mois de mise en œuvre, il est devenu évident que les fonctionnalités de SAP Business One sont franchement insuffisantes pour gérer même une petite entreprise (70 employés) en Conditions russes. Pourquoi n'avons-nous pas compris cela avant? Un problème compliqué.

Le produit, nous a-t-on dit, est destiné au marché des PME, afin de ne pas impliquer les entreprises dans une longue étape de l'enquête suivie d'une enquête en plusieurs volumes Termes de référence. Du coup, après l'étape de test du produit customisé, nous nous sommes retrouvés face à une liste de "bugs" pour plus de trois fiches, et ceux sans correction dont il est tout simplement inutile de remettre le système en état de marche. Certains d'entre eux concernaient spécifiquement des erreurs dans le fonctionnement du produit, tandis que d'autres concernaient des problèmes de fonctionnalité insuffisante de la solution. Selon la liste que nous avons compilée, la société de mise en œuvre était prête à «terminer» environ 30% des exigences, tandis que le reste ne pouvait pas être modifié sans la participation de SAP, car le code produit était fermé. La mise en œuvre de ces « améliorations » que le partenaire est capable de réaliser lui-même a doublé le coût du projet d'un seul coup. Cela a été motivé par le fait que "le produit doit être finalisé conformément aux spécificités des processus métier". Dans le même temps, des améliorations étaient vraiment nécessaires, mais pas pour nos "spécificités", mais simplement pour implémenter dans le produit, en général, un modèle économique standard. Il n'y avait aucune demande inhabituelle de notre part.

De plus, il s'est avéré que SAP Business One n'est pas un système à trois niveaux, mais repose sur une architecture client-serveur. Dans le même temps, les informations ne sont pas traitées sur le serveur, mais sur le client, ce qui affecte directement les performances. Soit dit en passant, lorsque nous avons lancé le système en mode test, compte tenu des exigences matérielles énoncées dans les brochures officielles décrivant la solution SAP Business One, les capacités de traitement de l'information déclarées du système ne se sont pas concrétisées.

Il faut aussi noter plusieurs graves lacunes de SAP Business One, qui ne sautent pas aux yeux dès les premières présentations, mais "émergent" seulement dans le processus :

• la sémantique du système de base de données n'est pratiquement pas décrite ;
• il n'y a pratiquement pas de procédures stockées ;
• le système est lent et gourmand en ressources ;
• disparu formulaires d'impression correspondant Normes russes comptabilité;
• la fonction de sauvegarde n'est pas implémentée (par exemple, les produits) ;
• la comptabilisation des immobilisations n'a pas été mise en œuvre ;
• la comptabilisation des règlements avec des personnes responsables n'est pas mise en œuvre ;
• comptabilisation des paiements mal mise en œuvre ;
• il n'y a pas de possibilité d'imputer les coûts directs et indirects au coût de production ;
• le support d'entrepôt cellulaire n'est pas mis en œuvre, il est impossible de tenir des registres dans le cadre des envois de marchandises ;
• la possibilité de procéder à l'arrivée de la fête à des prix différents n'est pas mise en œuvre ;
• Le MRP ne fonctionne pas dans le contexte d'un entrepôt.

Dans le même temps, SAP Business One comptabilise les différences de montant uniquement dans la devise nationale, le rapport sur les différences de montant est établi sur la base du taux de change actuel, ce qui entraîne un calcul incorrect des différences de montant dans les paiements.

Les "défauts" répertoriés empêchent généralement de fournir des informations correctes sur les activités de l'entreprise. Dans le même temps, il n'est pas tout à fait clair comment, dans ce cas, SAP Business One peut être positionné comme un système de comptabilité de gestion. Détail, de gros et d'autres entreprises à croissance rapide ne pourront pas travailler avec ce système en raison de ses performances limitées. L'enregistrement d'un document avec 40-50 positions met le système dans un état de stupeur. S'il y a au moins 200 à 300 documents de ce type par jour, tout cesse de fonctionner.

On nous a proposé «d'optimiser» les processus commerciaux de notre entreprise, ce qui, en fait, est une restructuration des moments clés pour nous et ressemble plus à «compresser» une entreprise déjà bien établie dans un cadre de solution rigide. Si nous ne voulons pas reconstruire le système existant dans notre entreprise, on nous a proposé de finaliser la solution. De plus, nous parlons ici d'étendre les fonctionnalités de la solution et nécessite une programmation à l'aide du package dit SDK (Software Development Kit).

D'une conversation avec une société de mise en œuvre, nous avons appris que SAP, de manière générale, oblige les partenaires à affiner indépendamment la fonctionnalité et à écrire des soi-disant add-ons (composants supplémentaires). Ces composants peuvent également être obtenus dans le commerce auprès d'autres partenaires qui ont déjà mis en œuvre cette fonctionnalité. Par exemple, pour comptabiliser les transactions avec des immobilisations, vous devez acheter le module complémentaire approprié, de même si nous voulons suivre les coûts réels et prévus, un autre module séparé est conçu pour interfacer la solution avec le système banque-client . Outre le fait que le coût du projet augmente, il y a un autre aspect : si nous achetons un module complémentaire à une autre société, nous devons soit les impliquer dans la mise en œuvre pour, encore une fois, de l'argent supplémentaire, soit notre partenaire de mise en œuvre s'en occupera par eux-mêmes, mais pas non plus gratuitement. En fait, il s'avère qu'il s'agit d'une sorte de "pyramide", qui se renforce d'autant plus que les fonctionnalités requises par l'entreprise sont étendues.

Vendre et oublier ?

Il est logique de supposer que SAP devrait s'occuper directement de la correction des lacunes techniques et technologiques. Ici, plusieurs points intéressants ont été révélés en communication avec le bureau moscovite de SAP. Je mentionnerai que nous payions le support technique annuel et avions le droit de compter au moins sur une attitude attentive en tant que client et une réponse rapide.

Je dois dire tout de suite qu'aucun des points que nous avons indiqués n'a été corrigé. Au lieu de cela, il y a eu une longue correspondance entre le partenaire et les personnes responsables SAP, que, finalement, notre partenaire nous a même montré. La plupart des réponses (polies, mais brèves avec une pause d'une semaine) se résumaient au fait qu'ils étaient bien conscients de tel ou tel "bug" et y travaillaient activement, puisque nous ne sommes pas les seuls à nous en plaindre ce. Presque tous les points que nous avons demandés auraient été corrigés en nouvelle version SAP Business One. Ce que nous attendons depuis environ un an et demi.

En conséquence, nous sommes d'avis que la démonstration " soutien technique» reflète l'approche globale du fournisseur pour faire affaire avec les PME. SAP en Russie se concentre spécifiquement sur les grands clients, car ils ont la possibilité d'investir une quantité indéfinie de temps et d'argent dans le projet. Mais les PME ne peuvent pas attendre indéfiniment et « nourrir » les consultants SAP pendant tout ce temps également. De plus, à en juger par "l'efficacité" et le "sens" des réponses à nos demandes, il semble que SAP ne s'intéresse qu'à la vente de licences, et rien n'est fait spécifiquement sur le produit. Il convient également de noter que les personnes responsables des clients dans SAP Business One changent souvent dans SAP. Certains d'entre eux, après le démarrage du projet SAP pour les PME, sont passés très rapidement de la résolution de problèmes de promotion de SAP Business One à la création de leur propre carrière au sein de SAP, l'autre partie s'est déplacée vers d'autres entreprises.

Arithmétique marketing

La déclaration "SAP Business One est un système de comptabilité de gestion" donne un charme particulier aux spécialistes du marketing SAP. Je le répète, que peut être la comptabilité si le système n'est pas en mesure de fournir des informations véridiques sur les activités de l'entreprise ? Si le système est « tiré grincheux sur l'entreprise » par des partenaires malheureux qui sont simplement contraints de faire entrer l'entreprise dans le cadre de cette « solution » ?

Dès le début du lancement du produit SAP Business One sur le marché russe, il a été déclaré qu'il s'agissait d'une solution pour les moyennes et petites entreprises. Est ce que c'est vraiment? La société SAP elle-même dans les médias a annoncé le coût d'un poste de travail clé en main (c'est-à-dire licence + mise en œuvre) - environ 2,5 à 3 000 €. De plus, il a été annoncé (comme avantage du produit) que le prix est définitif .

Afin d'automatiser réellement les processus métier clés d'une petite entreprise, disons avec un effectif de 100 à 200 personnes (finances, ventes, entrepôt, approvisionnement), vous devez acheter environ 10 à 15 postes de travail. C'est-à-dire qu'il faut compter sur un montant d'environ 30 à 45 000 €. Comme le montre la pratique, les propriétaires de Russie petites entreprises, qui gagnent chaque centime "par la sueur et le sang", il n'est pas si facile de payer 30 mille euros / dollars pour un "logiciel". De plus, il est impossible de maintenir la comptabilité fiscale et la comptabilité dans le système et, au minimum, "1C : Comptabilité" sera toujours nécessaire. De plus, si vous regardez de plus près les implémentations déjà annoncées, vous pouvez voir que les projets à part entière sont une exception rare et, en règle générale, nous parlons de 3 à 5 licences. Les conclusions s'imposent d'elles-mêmes.

Ainsi, selon notre expérience, SAP Business One peut fonctionner avec pas plus de 10 utilisateurs, dans une entreprise où il n'y a pas d'entrepôt de produits à part entière, alors que pas plus de 2-3 commandes de produits par jour peuvent réellement être traitées. La question se pose : « Une petite entreprise en développement a-t-elle besoin d'un tel système pour plus de deux mille euros par lieu de travail? Pourquoi, si à ce niveau il suffit d'utiliser juste Excel ?

Premièrement, selon les représentants des partenaires SAP, les développeurs de Business One sont situés en Israël et il n'y a pas de programme clair de développement de produits pour Marché russe. Plus précisément, un tel développement à l'échelle mondiale de l'activité SAP a la priorité la plus basse. Et peu importe à quel point les partenaires sont actifs, ils ne peuvent tout simplement pas physiquement faire face à toute cette machine et «éliminer» directement les améliorations de produit nécessaires (et le bureau de représentation de SAP à Moscou, selon des témoins oculaires, est inactif). Cette situation est assez courante dans les affaires, lorsqu'une société qui s'est fait un nom commence à lancer des produits à un prix beaucoup plus bas. La gestion est déjà à une hauteur cosmique inaccessible avec des "pensées cosmiques" divorcées de la réalité.

Si nous parlons spécifiquement de la réalité russe, la raison en est peut-être que depuis 10 ans, SAP existe également ici conditions confortables? Qu'il suffise de rappeler même les montants officiels des investissements en informatique de nos monstres industriels. Et en ce qui concerne l'action réelle, le développement normal et la promotion d'un produit spécifique, peut-être que des compétences et des compétences étaient nécessaires ici qui n'étaient pas nécessaires auparavant ? Et les projets sont devenus plus transparents et il n'est plus aussi facile de faire taire les problèmes que dans les implémentations à grande échelle, où il y a trop d'intérêts en jeu pour exposer les résultats inesthétiques à la publicité.

Il est clair que les objectifs de mise en œuvre d'un système ERP dans un grand entreprise industrielle souvent loin de l'automatisation elle-même (et la question de savoir comment de telles implémentations ont eu un impact positif sur l'industrie russe reste une grande question), mais dans le segment des PME, cette approche ne fonctionnera pas. Je constate que l'avant-vente se fait à un haut niveau professionnel, ce qui n'est pas surprenant compte tenu de la compétence des collaborateurs SAP et des partenaires. Mais est-il éthique de profiter de l'incompétence des managers russes et de la manipuler habilement ? Et nous parlons d'un produit conçu pour "fermer" tous les problèmes clés de la gestion de l'entreprise. La position du fournisseur ici doit être irréprochable.

Soit dit en passant, en plus de cette position de SAP : lors de la table ronde du 15 novembre 2006, de nouvelles approches pour travailler avec des partenaires travaillant avec des PME ont été officiellement annoncées. SAP indique que la mise en œuvre du produit sera entièrement effectuée par des partenaires. Et le vendeur "assurera la gestion générale et la passation des commandes". Eh bien, la position est tout à fait logique, du point de vue de la suppression complète de la responsabilité du résultat du projet. C'est-à-dire, d'une part, pour Dirigeants russes pour prendre la décision d'acheter un logiciel, il y aura un argument sur la solidité de la marque du développeur, en revanche, les clients individuels resteront avec le partenaire. Et ce dernier, à son tour, est "un à un" avec le produit. Si vous avez encore des doutes quant à l'implémentation ou non de SAP Business One, essayez de parler directement avec le propriétaire de l'entreprise dans laquelle cette solution est censée fonctionner. Essayez également de poser au responsable des ventes de la solution SAP Business One au moins certaines des questions soulevées dans cet article.

Vladlen Tatarski

Implémenter SAP à partir de zéro

Mise en œuvre de nouveaux systèmes d'information de gestion ou amélioration des systèmes existants basés sur produits logiciels Les sociétés SAP SE sont portées par SKYRISE sous forme de projets selon les méthodologies éprouvées ASAP, ASAP Focus, PMBOK.

Les projets d'implémentation (développement) de la classe ERP IMS appartiennent à la classe des projets complexes complexes et couvrent non seulement réalisation technique solutions métiers, mais aussi le transfert de compétences pour la mise en place et l'utilisation du système aux collaborateurs du Client.

La nécessaire interaction étroite "client-consultant" à toutes les étapes du travail est mise en œuvre par la création d'un groupe de travail projet. Le développement de solutions et leur mise en œuvre dans le système ont lieu avec la participation directe d'experts et de spécialistes techniques de l'entreprise du client, et les solutions elles-mêmes et les résultats déjà au cours du projet deviennent propriété intellectuelle entreprise cliente.

Un projet organisé systématiquement passe par les étapes suivantes :

• Lancement du projet
• Conception conceptuelle (développement de solutions de conception)
• Mise en œuvre technique des solutions de conception
• Essai
• La formation de l'utilisateur
• Préparatifs du lancement de l'OPE
• Lancement du système en exploitation productive et sa maintenance

SKYRISE prend en charge la gestion de l'étendue des travaux, des calendriers et des délais, des ressources et de la qualité des résultats du projet. Dans le même temps, le Conseil de gestion et les membres de l'équipe de projet de la part du Client ont toujours la possibilité de contrôler et d'être impliqués dans les décisions du projet.

SKYRISE attache une grande importance à l'expérience existante de l'industrie dans la création de systèmes d'information et de modèles de meilleures pratiques de l'industrie (SAP Best Practices) (voir aussi - solutions de l'industrie).

Quand est-il nécessaire d'implémenter SAP à partir de zéro

• L'entreprise fait des affaires en utilisant une solution non-SAP et a rencontré des limitations technologiques.
• L'entreprise est une Startup et réfléchit au choix de la principale plateforme d'information
• L'entreprise produit de grandes changements organisationnels, y compris les fusions et acquisitions, ou un changement coordonné d'activité

Chacun de ces appels a ses propres scénarios de travail. Et pour cela
afin d'offrir une solution appropriée, il est nécessaire de réfléchir en détail aux exigences d'un tel système et de choisir ultérieurement solution technologique en cohérence avec la stratégie de développement de l'entreprise.

Déployer le modèle d'entreprise SAP

Sur la base des besoins d'automatisation développés, une solution déjà développée - Template (Template) peut être utilisée pour l'accélérer.

Un modèle d'entreprise est généralement développé pour une grande holding internationale lorsque cela est nécessaire :
• Unifier l'entreprise
• Tenir compte des exigences locales
• Combiner les données dans un seul espace d'informations

Il est également possible d'utiliser un modèle métier à partir d'un ensemble de solutions métiers (SAP Best Practices).

Extension des fonctionnalités du système de productivité SAP

Extension des fonctionnalités d'un système de production

L'extension des fonctionnalités d'un système de production a ses propres spécificités. Des changements incorrects peuvent perturber un système de production, ce qui peut entraîner un arrêt de la production ou un arrêt de l'expédition, ce qui représente beaucoup de travail pour l'entreprise.

1. Toutes les modifications doivent être apportées sur la base d'une méthodologie vérifiée
2. Tous les changements doivent être planifiés
3. Ayez toujours un plan pour annuler les modifications
4. La fonctionnalité doit être vérifiée à la fois par rapport à la portée fonctionnelle élargie des processus métier clés,
   ainsi qu'en termes de portée organisationnelle élargie

L'extension des fonctionnalités est généralement effectuée à l'aide de la méthodologie d'implémentation ASAP.

Développement de fonctionnalités personnalisées

Le développement de fonctionnalités personnalisées est généralement compris comme le développement de fonctionnalités non standard.
Dans le même temps, il est important de comprendre les principes de gestion des données (ouvrages de référence), des opérations et du développement de rapports lors de la mise en œuvre des fonctionnalités utilisateur.
Des exemples de tels développements sont :

1. Outils de lecture de codes-barres avec appareils mobiles- lien
2. Système de gestion des équipements commerciaux -
   lien
3. Système de gestion de fonds protection personnelle- lien

Migration vers SAP HANA

La transition vers SAP HANA (High-Performance Analytic Appliance) s'effectue selon la méthodologie SAP Activate.
1. Tout d'abord, la liste complète des processus métier utilisés est décrite
2. La liste complète des ouvrages de référence utilisés est décrite
3. La liste complète des interfaces utilisées est décrite
4. Sur l'équipement acheté (dans le cas de la version On Premise), le logiciel SAP HANA est installé.
5. Des améliorations utilisateur sont apportées à la fonctionnalité
6. Les données d'annuaire et d'historique sont migrées de l'ancien système vers le nouveau à l'aide d'outils spéciaux
7. La fonctionnalité est testée dans le nouveau système.
8. Les interfaces sont en cours d'activation
9. La transition vers une nouvelle plateforme est en cours

Représente Système automatisé gestion des principaux processus internes de l'entreprise, y compris la comptabilité, la finance, la production, le commerce, la gestion du personnel, les stocks des entrepôts et de nombreux autres domaines d'activité. Les meilleures pratiques dans les processus commerciaux, la flexibilité, l'évolutivité, l'adaptation au contexte juridique de n'importe quel pays et les besoins individuels d'une entreprise particulière sont les principaux facteurs de succès du système créé par les développeurs de logiciels allemands et qui est devenu l'un des plus utilisés au monde.

L'introduction de SAP est un processus sérieux et en plusieurs étapes de transition d'entreprise vers des formes de gestion fondamentalement différentes. Cela implique la préparation d'un avant-projet et la sélection de solutions optimales tant du point de vue technique que financier.

L'un des problèmes les plus urgents qui intéressent les clients qui ont décidé de mettre en œuvre SAP est le coût du projet. Il est composé de nombreux facteurs, mais pour notre entreprise, sa validité est le critère le plus important pour la réussite de la mise en œuvre du projet. Nos experts proposent décisions rationnelles, dont le volet financier est calculé en tenant compte du rendement pratique maximum pour un client particulier.

L'introduction du système SAP en termes de profondeur des transformations en cours peut être considérée comme l'une des étapes les plus importantes de l'histoire du développement de l'entreprise, dont le succès dépend du travail bien coordonné des développeurs et du personnel de l'entreprise. . Dans le même temps, non seulement les services informatiques, mais également toutes les autres divisions structurelles participent à la mise en œuvre du système.

Résultats de la mise en œuvre de SAP

L'implémentation de SAP dans l'entreprise permet de résoudre diverses tâches de production, de marketing et de gestion qui affectent à la fois les indicateurs de performance en général et dans des domaines d'activité spécifiques.

Les principaux avantages obtenus grâce à la mise en œuvre de SAP incluent :

• réduction du coût des produits manufacturés (travaux, services) ;
• accroître la productivité du travail grâce à un changement qualitatif des approches, des méthodes de gestion et des processus commerciaux existants ;
• renforcer la discipline contractuelle et le respect des délais de livraison ;
• accès à des analyses de haute qualité ;
• améliorer la gestion des processus métier ;
• améliorer la qualité et la rapidité de réception décisions de gestion;
• et à la suite de toutes ces transformations - une augmentation de la compétitivité de l'entreprise sur le marché, une augmentation de la capitalisation et du montant des bénéfices reçus.

Principales étapes de la mise en œuvre de SAP

Le développement et la mise en œuvre réussis de SAP nécessitent l'intégration complète des technologies SAP proposées avec l'architecture d'information existante de l'entreprise. De la part de l'entrepreneur, cela exige, tout d'abord, de sérieuses connaissances techniques, une vaste expérience dans la mise en œuvre de systèmes et de modules SAP, ainsi qu'une compréhension approfondie des spécificités de l'entreprise et activités de production client.

Les principales étapes de la mise en œuvre de SAP sont:

• Préparation du projet (Charte de projet, plan de projet, réglementation en cours de préparation. Une enquête est en cours et l'architecture de la solution est en cours d'élaboration)
• Développement d'un projet d'entreprise conceptuel (Description de "to be" dans la terminologie SAP. Structures organisationnelles ; données de base ; processus d'entreprise ; formulaires de sortie ; rapports ; améliorations. Préparation de scénarios pour les tests fonctionnels)
• Mise en place d'un prototype et FT (Mise en place d'un système prototype et test selon les scénarios préparés. Préparation des données de base par le client (livres de référence). Préparation d'un scénario de test d'intégration)
• Personnalisation du système et de l'informatique (tests d'intégration) (réglage du système en fonction des résultats des tests fonctionnels. Réalisation des tests d'intégration. Finalisation des données de base. Développements nécessaires au cours du projet, qui ne prennent généralement pas plus de 10 à 15 % du montant total de travail)
• Préparation du système pour un démarrage productif (Déploiement des postes de travail. Formation des utilisateurs finaux. Chargement des données de base et variables.)
• Démarrage productif et accompagnement pour un démarrage productif (Chargement supplémentaire des données de base et variables. Support opérationnel aux utilisateurs finaux. Clôture des premières périodes)

Le niveau de formation des spécialistes de notre entreprise, leurs connaissances approfondies procédés de fabrication et les mécanismes de gestion d'entreprise, ainsi que la disponibilité de notre propre méthodologie de mise en œuvre, nous permettent de garantir la mise en œuvre rapide et de haute qualité des systèmes SAP de différents niveaux de complexité.

Pourquoi le projet est-il divisé en phases et quel principe est généralement suivi lors de la division du projet en phases ?

En fait, tout est extrêmement simple, le premier - selon les résultats de la phase, la mise en œuvre du projet est suivie, sa gestion est effectuée, et le second - il convient de lier les termes du contrat aux phases : activation, calendrier de paiement, etc. Il est clair que chaque phase doit se terminer par un certain produit, qui peut être considéré, du point de vue des parties, comme l'objet du contrat ou une partie de celui-ci.

Mise en place d'un bureau de projet

La première et généralement la plus courte phase du projet. Très souvent, son nom introduit le client dans une « stupeur ». Une fois, alors que j'ai eu l'honneur de travailler dans l'équipe interne d'une entreprise métallurgique courageuse, des questions plutôt sarcastiques ont été entendues de la part de la direction: "Quoi, vont-ils organiser des chaises à ce stade?".

En fait, bien sûr, dans ce cas, pas de chaises ni même de tables sont placées. Le produit de cette phase du projet est en fait les principaux documents de gestion de projet : l'ordre de démarrage du projet, la charte de projet, le planning détaillé, le plan de gestion des risques, le plan de communication, etc.

Souvent, le nom de la phase est choisi par un autre, personnellement, j'aime bien celui-ci, car. correspond vraiment au contenu.

Sondage

A cette phase du projet, les consultants de l'entrepreneur se familiarisent avec les processus de l'entreprise qu'ils doivent automatiser, étudient les besoins. La communication entre les consultants et les employés de l'entreprise se déroule le plus souvent sous la forme d'un entretien, après quoi le consultant rédige un rapport sur la réunion. Le rapport doit être signé par tous les participants à la réunion. À l'avenir, tous les rapports sur les entretiens menés seront inclus dans le rapport.

La meilleure pratique consiste à préparer une description des processus métier sous forme de diagrammes dans un produit CASE. Un tel diagramme est appelé As-Is Business Process Diagram (AS-IS). Mais, malheureusement, en raison du coût élevé des produits logiciels, ainsi que de la faible demande du client, cette technologie est très rarement utilisée sur les projets. C'est dommage, car son utilisation vous permet de tirer diverses conclusions analytiques sur l'état des processus métier, d'optimiser et, surtout, à l'avenir, lors de la conception conceptuelle et de la construction du modèle «As It Should Be» (TO-BE), permet de faire une analyse comparative, c'est-à-dire . vous permet de prédire les avantages de la mise en œuvre d'un système ERP. Le résultat de cette phase est aussi souvent un mandat mis à jour.

Conception conceptuelle (Modèle TO-BE)

La phase Conceptual Design devrait en fait inclure le travail effectué dans la phase Survey, mais d'un point de vue de la gestion de projet, et surtout du budget et du timing, je pense qu'il est préférable de les séparer. Le fait est qu'au stade de l'étude, il peut déjà apparaître clairement à l'entrepreneur la nécessité d'un ajustement plan de calendrier et la portée des travaux, la question doit être soulevée pour discussion et des mesures appropriées doivent être prises. Si cela n'est pas fait à ce stade, il est pratiquement impossible de le faire plus tard (bien que dans ce cas, il soit nécessaire de faire des miracles de diplomatie).

La phase de conception conceptuelle, à mon avis, est l'une des phases les plus difficiles d'un projet. Ici, il y a souvent des collisions entre différentes structures de l'entreprise et, par conséquent, l'entrepreneur doit constamment chercher un moyen de sortir de cette situation. En effet, au final, le succès de la mise en œuvre de cette phase particulière donnera une impulsion à l'automatisation réussie des processus métier, en tenant compte des exigences mises en avant par le système. Le document en cours d'élaboration à ce stade du projet, la conception conceptuelle, est la règle selon laquelle non seulement la configuration du système, mais également les processus métier seront construits à l'avenir. Ce n'est pas un secret que Système d'Information- c'est l'outil commercial qui vous permet de prendre des décisions opérationnelles, tactiques et stratégiques, et affecte également le travail des unités impliquées dans la préparation de l'information.

Aussi, une certaine difficulté durant cette phase est la correction de la créativité et de la créativité des membres. projet de groupe. Lorsque vous travaillez sur un projet conceptuel, des consultations supplémentaires avec des experts métier doivent être organisées, des séances de brainstorming doivent être organisées. Tout doit être fait pour que le système soit adapté au maximum aux exigences du client, et c'est là la principale difficulté.

Mise en œuvre

La phase la plus compréhensible et, selon beaucoup (je pense dans une opinion erronée), la plus importante du projet. En effet, avec la construction correcte du modèle conceptuel des processus métier et du système, la phase de mise en place des paramètres et des développements est réduite à travail technique. La complexité et l'importance de cette phase s'expliquent par les événements qui, en règle générale, couronnent la phase - il s'agit d'un test d'intégration et d'un démarrage productif du système.

Un test d'intégration peut avoir lieu selon différents scénarios, mais le sens de cet événement est que l'exécutant doit prouver au client que le système fonctionne, ainsi que son adéquation par rapport aux exigences. Le sujet est tellement compliqué que dans cet article je n'y reviendrai pas, nous en reparlerons plus tard.

Un démarrage productif du système est, en principe, exactement le jalon pour lequel le conseil fonctionne. D'après mon expérience, il y a eu divers démarrages productifs, et c'est aussi un sujet très complexe et vaste. Permettez-moi de dire que si un démarrage productif s'est produit, alors le projet a réussi à 90 %.

Prise en charge initiale

Service de garantie du système, il n'y a rien de spécial à écrire ici. Une phase très difficile pour l'entrepreneur et le client. La mise en route dans n'importe quel système s'accompagne de grandes difficultés et d'une abondance d'erreurs de la part des utilisateurs, et dans le système lui-même, en règle générale, il y a pas mal de bogues. Et la difficulté réside en grande partie dans le fait que tout ce qui précède se produit simultanément dans personnes différentes. Le rejet de la comptabilité parallèle dans le système historique (ancien) est essentiel au succès de cette phase et du projet dans son ensemble. Après le rejet de la comptabilité parallèle et la clôture de la période comptable, couvrant l'ensemble des opérations automatisées, le projet peut être considéré comme réussi et achevé.

Bonjour, collègues, lecteurs, amis!

Dans cet article, je vais essayer de parler de certaines idées fausses auxquelles sont confrontés les consultants et les chefs de projet. Ces idées fausses peuvent surgir de la part de la direction de l'entreprise où le système est mis en place, de la part des employés ordinaires qui devront travailler dans un nouveau Système de comptabilité et même de la plupart des consultants.

Introduction

Je ne dirai pas sans équivoque, mais je pense que presque chaque consultant / chef de projet / change manager qui a suffisamment d'expérience implémentations d'ERP(on ne parle pas forcément ici du système SAP), retrouvez dans cet article ce qu'il a réellement rencontré, et partagez (peut-être partiellement) mon raisonnement. Tout ce que je vais décrire est mon expérience personnelle en matière de conception. Et la classification que je présente ci-dessous n'est rien de plus qu'une convention. Quelqu'un peut le voir et le classer d'une manière complètement différente. Prêt pour la discussion dans les commentaires de l'article.

Le sujet de la matière est né spontanément dans ma tête, lors de la discussion de quelques moments de travail sur le projet. La question dont nous avons discuté concernait le développement et l'automatisation d'une méthodologie de planification de certains indicateurs. Dans le même temps, au cours de la discussion sur la question, il s'est avéré que la méthodologie elle-même n'existait pas encore. La question était à peu près la suivante : nous avons mis en place un système de planification des ressources d'entreprise (ERP). Cela coûte beaucoup de millions d'argent. Il y a un tas d'informations différentes qu'un millier d'utilisateurs finaux y saisissent. Alors pourquoi la direction de l'entreprise ne peut-elle pas obtenir le plan/les prévisions nécessaires à partir de ce système ?

Familier? Et du point de vue des non-initiés, c'est une question assez logique. Peut-être que mes collègues ont entendu les mêmes questions, mais dans un contexte légèrement différent, mais je suis sûr qu'ils l'étaient. Et nous arrivons à la première idée fausse.

Idée reçue n° 1 : le système fonctionne pour vous ou le « syndrome du bouton rouge »

Donc, nous mettons en œuvre un système ERP volumineux et coûteux chez le client (pour simplifier, supposons que nous parlons de la mise en œuvre du système SAP, bien que, comme je l'ai écrit ci-dessus, mes arguments s'appliquent également à d'autres grands systèmes ERP) . La plupart des employés de l'entreprise, même s'ils ne sont pas directement impliqués dans la mise en œuvre, ont entendu quelque chose quelque part. On a entendu parler du coût d'une licence (qu'ils sont prohibitifs), du coût de mise en place, des salaires des consultants, etc. Les employés de l'entreprise du client, qui travaillent directement avec des consultants sur la mise en œuvre, ne comprennent souvent pas non plus jusqu'à la toute fin comment tout cela fonctionnera après un démarrage productif. Mais ils ont aussi une idée du coût de mise en œuvre. Toutes ces personnes ont tout à fait le droit de supposer que la mise en œuvre du système permettra d'effectuer automatiquement de nombreuses opérations manuelles / de routine, c'est-à-dire le système fonctionnera pour vous.

C'est ainsi que naît un stéréotype. Si l'équipe de l'entrepreneur n'a aucune idée de la naissance de ce stéréotype, alors au moment d'un démarrage productif, une situation se produit lorsque les utilisateurs sont tout à fait sincèrement surpris de devoir saisir quotidiennement une si grande quantité d'informations dans le système. Utilisateurs ayant participé aux tests d'intégration. Les utilisateurs qui ont été formés. Ceux. ces personnes qui, en théorie, devraient être prêtes à travailler dans le système, le comprennent et l'acceptent. Leur étonnement et leur incompréhension peuvent se transformer en rejet et rejet des changements, en rébellion pure et simple.

Il y avait un tel cas dans mon expérience. Quand, après avoir acquis une expérience pratique du système, après un début productif, une "coalition d'opposition" s'est formée dans l'entreprise. Ce groupe de personnes a délibérément accumulé toute la négativité, toutes les crevaisons des consultants, toutes les limitations de la fonctionnalité du système (et comme vous le comprenez, les "limitations fonctionnelles" du système SAP, comparées, par exemple, à 1C, peuvent être les impossibilité de supprimer beaucoup de données, impossibilité de "nettoyer les queues") . Eh bien, l'heure « X » est venue, lorsque tout ce bain de boue s'est déversé sur l'équipe de mise en œuvre, et a également été fourni au propriétaire de l'entreprise comme principal argument en faveur du retour à l'ancien système comptable. Au final, tout s'est bien terminé. Et après un certain temps, les personnes qui étaient les opposants les plus ardents au nouveau système, ont compris quels étaient ses avantages, ont changé d'avis. MAIS, si le chef de projet (d'un côté ou de l'autre) avait reconnu le problème à temps et apporté les clarifications nécessaires, de telles protestations et scandales auraient pu être évités.

J'ai mentionné le syndrome du bouton rouge. C'est une sorte de vélo entre collègues consultants. Le propos est le même. Chaque utilisateur, à un degré ou à un autre, souhaite que le nombre d'opérations de routine qu'il effectue chaque jour soit automatiquement exécuté dans le système d'une manière fantastique. Ceux. l'utilisateur se connecte et l'interface système se compose d'un gros bouton rouge. L'utilisateur clique sur le bouton et le système effectue lui-même toutes les opérations nécessaires. Et l'utilisateur à ce moment boit du thé. La consultation du folklore a transformé le bouton rouge en pédale rouge. Pourquoi une pédale ? Ensuite, vous pouvez alors appuyer avec votre pied et les deux mains sont libres. L'un - vous buvez du thé, l'autre - vous jouez au solitaire. J Tout cela est bien sûr une blague, mais de nombreux utilisateurs ne se lassent pas de se demander comment un système mis en place pour un tel argent ne peut pas "penser un peu pour une personne".

Idée reçue n°2 : La mise en place du système va « décharger » les utilisateurs finaux

En fait, le sophisme #2 est un cas particulier (léger) du premier sophisme. Mais je l'ai séparé dans une section distincte, car cette idée fausse se rencontre beaucoup plus souvent. Les "jambes" poussent à partir de là. La comparaison du degré de pente et du coût de l'ancien et du nouveau système comptable donne aux utilisateurs des motifs de réflexions et de conclusions incorrectes et sans lien dans la pratique. Nouveau système me permettra d'automatiser partiellement, ou de transférer comme par magie certaines de mes fonctions à quelqu'un d'autre.

Dans ce cas, nous avons les deux faces de la médaille. Une partie des employés dort et voit comment le système fonctionne pour eux (en tout ou en partie - voir délire n°1). Une autre partie des employés de l'entreprise regarde plus loin et voit cela comme un problème. Après tout, si le système exécute maintenant certaines des fonctions lui-même, le nombre d'employés nécessaires pour effectuer les opérations de routine devrait être réduit. Ce problème peut également entraîner des conséquences désagréables, voire un sabotage de la mise en œuvre par des employés / services individuels de l'entreprise.

Je veux décrire un autre exemple tiré de mon expérience. Je ne sais pas s'il appartient au n°1 ou au n°2. Il (exemple) à des degrés divers, concerne les deux.

Pour une grande entreprise, l'un des principaux cabinets de conseil au monde, une méthodologie de comptabilité analytique distincte a été rédigée. Les exigences de la méthodologie étaient très strictes. L'élaboration des dispositions de la méthodologie et un degré élevé de détail des résultats finaux de la répartition des coûts pour l'entreprise du client étaient très importants. La deuxième étape du processus de développement de la méthodologie a été son automatisation, qui a été réalisée à l'aide du système SAP BW. La méthodologie a été automatisée, les utilisateurs ont été formés et la qualité du travail a été vérifiée par l'entreprise qui a développé la méthodologie. Le client était entièrement satisfait du résultat des travaux. Cependant, pour que la méthodologie fonctionne dans SAP BW, une quantité assez importante d'informations initiales était nécessaire (comme je l'ai déjà écrit, le client a payé grande attention détails de la répartition des coûts). Une partie des données a été chargée depuis SAP ERP. Une partie des données provenant des systèmes d'application. Certains ont été saisis manuellement dans MS Excel et chargés dans BW à l'aide de formats spéciaux. Des personnes spéciales ont même été affectées à ce travail. Tout semblait aller bien. Cependant, après un certain temps, les employés ont commencé à quitter l'entreprise du client, qui étaient les principaux idéologues de l'utilisation de la méthodologie développée, ont participé à son développement et à son acceptation. Ce sont des gens qui, entre autres, ont compris l'importance de préparer le volume nécessaire informations primaires pour obtenir les résultats corrects de la distribution finale. De plus, après un certain temps, le client a reçu des demandes de simplification du niveau de détail des calculs. La principale raison est trop de données initiales qui doivent être préparées. La simplification a été effectuée en plusieurs itérations (encore une fois, au fur et à mesure que les exigences du client arrivent). Et à la fin, il restait une « souche » du modèle analytique détaillé, qui montrait des données généralisées. Il n'était pas nécessaire de parler de l'ancien degré de détail.

Ce que je voulais montrer avec cet exemple. Le fait qu'une incompréhension de la part de l'entreprise du Client de la quantité de travail qui doit être effectuée par ses employés entraîne la perte de la quasi-totalité des résultats de ce travail de grande envergure et plutôt coûteux.

Soit dit en passant, au début de l'article, j'ai mentionné la situation dans laquelle le client doit fournir un modèle (plan, prévision) du système basé sur les données disponibles. C'est aussi une idée fausse très répandue. Mais je ne le distinguerai pas séparément. Cela s'applique également aux erreurs n°1 et n°2 (ou quelque part entre les deux). En fin de compte, la direction de l'entreprise du client ou le propriétaire de l'entreprise ne comprend pas très bien les différences entre l'algorithme et les données initiales. Tout modèle, prévision, technique, enfin, consiste en :

A. Une sorte d'algorithme exprimé dans des formules mathématiques/statistiques claires et compréhensibles ;

B. La liste des informations nécessaires pour remplir le modèle de données, et sur lesquelles la prévision future sera basée.

Les gens, pour une raison quelconque, croient qu'un système rempli de données produira lui-même calculs nécessaires et faire des pronostics. Ce n'est pas vrai.

Comment éviter les problèmes avec ces deux idées fausses (#1 et #2) ? Il est nécessaire d'expliquer systématiquement aux personnes à tous les niveaux de l'entreprise (salariés ordinaires, cadres inférieurs et intermédiaires, top management) que le système n'est pas un robot, pas intelligence artificielle. Elle ne peut pas prendre de décisions par elle-même ou effectuer des opérations qui nécessitent une sorte d'analyse. Le système est un outil qui vous permet de refléter les processus commerciaux, les opérations commerciales et les étapes commerciales de l'entreprise avec différents niveaux de profondeur et de détail. La profondeur et le détail des processus, des opérations et des étapes individuelles seront reflétés dans le système est décidé lors de la mise en œuvre. Quoi qu'il en soit, la plupart des informations analytiques sont saisies dans le système par des personnes. Les rapports sont basés sur ces informations. Et la profondeur d'élaboration des rapports analytiques de gestion (nous lisons, la transparence même de l'entreprise que les entreprises qui mettent en œuvre des systèmes ERP recherchent) dépend de la qualité et du volume des informations saisies.

Une autre point important qui, à mon avis, devrait être communiquée aux utilisateurs finaux à tous les niveaux. Le système n'est pas mis en œuvre pour la commodité des employés ordinaires. Le but de la mise en œuvre du système : Obtenir des informations claires, détaillées et opportunes sur l'état actuel de l'entreprise pour que la direction de l'entreprise puisse prendre des décisions de gestion. Pour atteindre cet objectif, la quantité d'informations saisies par les utilisateurs finaux peut même augmenter par rapport à ce qui était dans l'ancien système comptable.

Idée reçue n°3 : Vous pouvez toujours « plier » le système pour les affaires

• Je ne me souviens plus où j'ai vu ça (quelque part sur Internet), mais je me souviens très bien de la phrase : « …Cela a toujours été fait comme ça et le consultant devrait le répliquer sur SAP », c'est le début d'un gros problème.

"...Cela a toujours fonctionné ainsi, et la tâche du consultant est de dupliquer le processus dans le système SAP" - c'est le début d'un gros problème.

Le propriétaire d'une entreprise, achetant un système et payant pour sa mise en œuvre, veut extraire de ce système tout ce que l'ancien lui a donné, et bien plus encore d'en haut. Du point de vue du principe « je paie, je commande la musique » c'est plus que raisonnable. Encore une fois, étant donné le coût et la pente du système, la fausse impression est créée qu'il peut toujours être plié pour les affaires, «étiré» sur les processus commerciaux existants sans révision / révision