SAP-Quest, le forum SAP en français

Dans le cadre strict du périmètre du projet gestion des immobilisations, l’utilisation de l’Ordre Interne(CO) ou de l’OTP (PS) ne présente pas de différences notables, tant qu’il n’existe pas de hiérarchie entre les lots.

On notera cependant que :
- Les codifications des définitions de projets ainsi que des éléments d’OTP peuvent être modifiés (même s’ils portent des flux) si des codes déjà utilisés dans SAP devenaient nécessaires pour d’autres projets lors du déploiement de PS dans l’avenir. Le système applique en réalité une numérotation interne qui n’est pas apparente pour l’utilisateur. Cette « re-codification » n’est pas envisageable dans le cas de l’utilisation des ordres internes d’investissements
- La définition de projet est une donnée en tant que telle dans SAP alors que le groupe d’ordre interne n’est qu’un lien « virtuel ». Elle peut donc porter plus d’informations que ce dernier.
- La création de la définition de projet précède forcément la création du premier élément d’OTP. En revanche, il n’est pas nécessaire de créer un groupe d’ordre avant de créer un ordre interne d’investissement. Il existe dans CO le risque de voir apparaître des ordres d’investissement (donc des « Lots ») qui n’ont pas été rattachés à des groupes d’ordre (donc à des projets au sens Fiche projet). Egalement un groupe d’ordre peut être trop facilement modifié (quant au ordres internes qu’il contient) voire supprimé (en déplaçant les ordres internes qu’il porte) La définition de projet ainsi que les éléments d’OTP doivent eux suivre des statuts bien définis pour être modifié ou supprimés
- La volumétrie du système ne souffrirait pas du choix des projets d’investissements dans IM puisque qu’on n’utilise de PS que des éléments d’OTP unidimensionnels qui ne portent ni graphes, ni réseaux…
- D’un point de vue ergonomique, l’utilisation de « project builder » (CJ20N) donne une meilleure lisibilité du projet dans son découpage par lot. Cette application permet également d’éviter certains allers et retours dans les menus utilisateurs. Dans l’éventualité d’une volumétrie forte (comme c’est le cas sur le projet immobilisations) l’ergonomie peut être considérée comme un point différenciateur déterminant. Enfin, il semble, paradoxalement, plus simple de manipuler « project builder » dans des fonctionnalités puissantes que son équivalent CO « order manager » dont les possibilités sont plus limitées.

L’analyse comparative effectuée, entre ordres internes et OTP pour la mise en place du module IM, nous a permis de valider qu’il n’existe pas :

- De risques de charge de paramétrage : 80% des menus de l’IMG du module de gestion des investissements (IM) sont partagés par les projets d’investissements et les ordres d’investissements ;
- De risques d’apports fonctionnels : les deux objets remplissent les besoins nécessaires au fonctionnement des processus de la gestion des immobilisations. Egalement, les utilisateurs ne pourront pas utiliser de manière précoce des fonctions de la gestion de projet tant que les habilitations et le paramétrage ne le permettront pas ;
- De risques en terme de restitutions : les deux objets portent les données nécessaires en terme de restitutions aux utilisateurs de la gestion des immobilisations ;
- De risques en terme de choix structurants en cas de mise en place de PS : si 80 % du paramétrage est commun entre ordres d’investissements et projets d’investissements, les 20% restants ne compromettent pas la mise en place de PS quels que soient les choix qui seront alors pris. Il s’agit essentiellement du profil de projet : il contient des valeurs par défaut (société, le périmètre analytique, profil d’investissement…) copiées dans la définition de projet ou dans les éléments d'OTP lors de la création d'un projet et pouvant être écrasées à l'écran. Rien n’empêchera à terme de modifier le profil crée pour la gestion des immobilisations, de le renommer, d’en créer un nouveau plus adapté aux nouveaux projets.