Une étude sur la mise en oeuvre des ERP (progiciels de gestion de type SAP).
Elle montre, en particulier, que si cette mise en oeuvre conduit la plupart du temps à des échecs, c'est du fait d'un petit nombre d'erreurs.
Une étude sur la mise en oeuvre des ERP (progiciels de gestion de type SAP).
Elle montre, en particulier, que si cette mise en oeuvre conduit la plupart du temps à des échecs, c'est du fait d'un petit nombre d'erreurs.
Gestion de la banque - 8e éd. (Coussergues, Sylvie de Bourdeaux, Gautier) (z...Jeyo52529B
Acteurs de référence du financement de l'économie, les banques sont constamment confrontées à la prise de décision en avenir risqué. Elles présentent des spécificités qui nécessitent et justifient l'existence d'outils d'analyse et de gestion qui leur sont propres.
Clair et pédagogique, ce manuel de référence présente :
l'environnement de la banque dans le contexte de la mondialisation ;
les différents aspects de la gestion bancaire : diagnostic financier, contrôle de gestion, gestion des risques de contrepartie et de marché, marketing et stratégie.
Cette 8e édition, entièrement mise à jour, intègre le nouveau cadre européen lié à l'union bancaire, le contexte actuel de taux d'intérêts négatifs, la règlementation prudentielle en évolution et l'impact des nouvelles technologies avec la concurrence des "fintech" et la digitalisation de la banque.
Rapport zones de risques liées à l'Impôt sur les Sociétés. Cas du Marocbouchra elabbadi
Partant du fait que la fiscalité est une matière dense et complexe, nécessitant à la fois une mise à jour permanente et une intégration profonde par rapport aux réalités de l’entreprise et de son environnement immédiat et futur, il est aisé de constater que les responsables des entreprises sont rarement des fiscalistes et que pris dans le feu de l’activité. Ils peuvent commettre volontairement ou/et involontairement des infractions susceptibles d’engendrer des coûts financiers plus ou moins importants et subir éventuellement des sanctions judiciaires.
L’entreprise marocaine se trouve de plus en plus en situation de risque permanent lui imposant de surveiller son environnement fiscal. D’où la nécessité de l’audit fiscal qui devient de plus en plus un des volets incontournables de la vie de l’entreprise.
Et donc, une démarche d'audit fiscal rigoureuse, menée à partir de l'analyse des principaux postes de la liasse fiscale (états financiers, détermination du résultat fiscal, états d'intégration), met en lumière les points clés à examiner et de déceler les risques majeurs de la gestion fiscale de l’entreprise. Nous traitons ainsi, dans ce chapitre les zones de risques de l’impôt sur les Sociétés (IS).
De prime abord, nous nous intéressons aux généralités sur l’IS en rappelant les dispositifs généraux de l’impôt en question, ensuite l’étude des Zones de risque liées à l’IS fera l’objet du deuxième point. Nous traitons l’Audit des charges et réintégrations tout en signalons les dispositions légales et réglementaire des charges ainsi que le Contrôle des opérations fiscales relatives aux charges.
Avant de conclure par une synthèse générale, nous étudions dans le troisième point l’Audit des produits et déductions, avec un rappel sur les produits imposables, puis l’audit des comptes de produits et finalement le contrôle par le questionnaire avec une étude de cas.
Rapport mini-projet Gestion Commerciale D’un SupermarchéMouad Lousimi
Le projet soumis à notre réflexion est intitulé réalisation d'un programme pour la gestion commerciale d’un supermarché réalisé à l'aide de Microsoft Visual Basic et MySQL.
Connaître la réforme de Bâle II - Bâle III dans son ensemble , Maîtriser les différentes approches introduites par la réforme de Bâle II , Savoir appréhender les impacts de la réforme
Bâle III et ses implications
Objectifs et enjeux
Historique des objectifs et de la mise en place de Bâle II
Les raisons de l’évolution Bâle III
3 piliers de Bâle II, vers Bâle III…
Pilier 1 : les exigences de solvabilité et de liquidité face aux risques
Evolution des ratios réglementaires
Zoom sur les différents ratios
Calendrier de mise en place
Pilier 2 : la procédure de surveillance et le contrôle des risques
Exigences et implications pour les banques
Pilier 3 : la discipline de marché et la transparence
Renforcement des Fonds propres
Contrôle des risques (crédit, opérationnels)
Renforcement du reporting réglementaire (SURFI)
Impacts de la réforme
Sur l’organisation interne
Sur les opérations clientèle et les stratégies de la banque
Sur les marchés financiers
Le projet Solvency 2 pour les Compagnies d’Assurance
Après Bâle III, les travaux en cours du Comité de Bâle
Voir notre formation Réforme de Bâle II et ses implications, vers Bale III:
http://formation.actions-finance.com/reforme-de-bale-ii-et-ses-implications-vers-bale-iii/
Plus d'infos sur:
http://www.actions-finance.com/
twitter.com/Actions_finance
Pour tout renseignement, contactez nous au
+ 33 (0)1 47 20 37 30
Industrialisation des développements CRM 2011Microsoft
Homogénéisez vos développements CRM 2011 en définissant : • Un ensemble de normes et bonnes pratiques de configuration et développement des composants d'une application CRM • Un macro-processus de développement inspiré de Sure Step et articulé autour des trois phases de cadrage, réalisation et livraison d'une solution CRM • Un processus de livraison de solution CRM de livraison adapté aux trois principaux scénarios que représentent la livraison d'une version majeure, mineure ou le support d'une version d'application CRM • Une instrumentation de l'environnement de développement permettant le contrôle de code source et l'automatisation des processus de génération et livraison de solution CRM
Gestion de la banque - 8e éd. (Coussergues, Sylvie de Bourdeaux, Gautier) (z...Jeyo52529B
Acteurs de référence du financement de l'économie, les banques sont constamment confrontées à la prise de décision en avenir risqué. Elles présentent des spécificités qui nécessitent et justifient l'existence d'outils d'analyse et de gestion qui leur sont propres.
Clair et pédagogique, ce manuel de référence présente :
l'environnement de la banque dans le contexte de la mondialisation ;
les différents aspects de la gestion bancaire : diagnostic financier, contrôle de gestion, gestion des risques de contrepartie et de marché, marketing et stratégie.
Cette 8e édition, entièrement mise à jour, intègre le nouveau cadre européen lié à l'union bancaire, le contexte actuel de taux d'intérêts négatifs, la règlementation prudentielle en évolution et l'impact des nouvelles technologies avec la concurrence des "fintech" et la digitalisation de la banque.
Rapport zones de risques liées à l'Impôt sur les Sociétés. Cas du Marocbouchra elabbadi
Partant du fait que la fiscalité est une matière dense et complexe, nécessitant à la fois une mise à jour permanente et une intégration profonde par rapport aux réalités de l’entreprise et de son environnement immédiat et futur, il est aisé de constater que les responsables des entreprises sont rarement des fiscalistes et que pris dans le feu de l’activité. Ils peuvent commettre volontairement ou/et involontairement des infractions susceptibles d’engendrer des coûts financiers plus ou moins importants et subir éventuellement des sanctions judiciaires.
L’entreprise marocaine se trouve de plus en plus en situation de risque permanent lui imposant de surveiller son environnement fiscal. D’où la nécessité de l’audit fiscal qui devient de plus en plus un des volets incontournables de la vie de l’entreprise.
Et donc, une démarche d'audit fiscal rigoureuse, menée à partir de l'analyse des principaux postes de la liasse fiscale (états financiers, détermination du résultat fiscal, états d'intégration), met en lumière les points clés à examiner et de déceler les risques majeurs de la gestion fiscale de l’entreprise. Nous traitons ainsi, dans ce chapitre les zones de risques de l’impôt sur les Sociétés (IS).
De prime abord, nous nous intéressons aux généralités sur l’IS en rappelant les dispositifs généraux de l’impôt en question, ensuite l’étude des Zones de risque liées à l’IS fera l’objet du deuxième point. Nous traitons l’Audit des charges et réintégrations tout en signalons les dispositions légales et réglementaire des charges ainsi que le Contrôle des opérations fiscales relatives aux charges.
Avant de conclure par une synthèse générale, nous étudions dans le troisième point l’Audit des produits et déductions, avec un rappel sur les produits imposables, puis l’audit des comptes de produits et finalement le contrôle par le questionnaire avec une étude de cas.
Rapport mini-projet Gestion Commerciale D’un SupermarchéMouad Lousimi
Le projet soumis à notre réflexion est intitulé réalisation d'un programme pour la gestion commerciale d’un supermarché réalisé à l'aide de Microsoft Visual Basic et MySQL.
Connaître la réforme de Bâle II - Bâle III dans son ensemble , Maîtriser les différentes approches introduites par la réforme de Bâle II , Savoir appréhender les impacts de la réforme
Bâle III et ses implications
Objectifs et enjeux
Historique des objectifs et de la mise en place de Bâle II
Les raisons de l’évolution Bâle III
3 piliers de Bâle II, vers Bâle III…
Pilier 1 : les exigences de solvabilité et de liquidité face aux risques
Evolution des ratios réglementaires
Zoom sur les différents ratios
Calendrier de mise en place
Pilier 2 : la procédure de surveillance et le contrôle des risques
Exigences et implications pour les banques
Pilier 3 : la discipline de marché et la transparence
Renforcement des Fonds propres
Contrôle des risques (crédit, opérationnels)
Renforcement du reporting réglementaire (SURFI)
Impacts de la réforme
Sur l’organisation interne
Sur les opérations clientèle et les stratégies de la banque
Sur les marchés financiers
Le projet Solvency 2 pour les Compagnies d’Assurance
Après Bâle III, les travaux en cours du Comité de Bâle
Voir notre formation Réforme de Bâle II et ses implications, vers Bale III:
http://formation.actions-finance.com/reforme-de-bale-ii-et-ses-implications-vers-bale-iii/
Plus d'infos sur:
http://www.actions-finance.com/
twitter.com/Actions_finance
Pour tout renseignement, contactez nous au
+ 33 (0)1 47 20 37 30
Industrialisation des développements CRM 2011Microsoft
Homogénéisez vos développements CRM 2011 en définissant : • Un ensemble de normes et bonnes pratiques de configuration et développement des composants d'une application CRM • Un macro-processus de développement inspiré de Sure Step et articulé autour des trois phases de cadrage, réalisation et livraison d'une solution CRM • Un processus de livraison de solution CRM de livraison adapté aux trois principaux scénarios que représentent la livraison d'une version majeure, mineure ou le support d'une version d'application CRM • Une instrumentation de l'environnement de développement permettant le contrôle de code source et l'automatisation des processus de génération et livraison de solution CRM
Adopter une méthodologie pour développer un système est indéniable au risque de vous planter, cette présentation étale sur ses slides la méthodologie 2TUP, qui fait partie de la famille des Processus unifiés basés sur UML
2. Présentations
• Intervenant : Pascal Roques
• Formateur et consultant senior chez Valtech Training
• Responsable de l’offre formation autour d’UML
• Auteur de 3 ouvrages sur UML parus chez Eyrolles :
UML 2 en action UML 2 par la pratique
De l'analyse des besoins Études de cas et
UML
à la conception J2EE Modéliser un site e-commerce
exercices corrigés
3. Notre programme
• 1. La problématique de la modélisation métier
• 2. Comment modéliser les processus métier ?
• 3. Comment modéliser les objets métier ?
• 4. Le passage aux spécifications logicielles
• Les diagrammes de la présentation ont
été réalisés avec l’outil Together®
5. Business Modeling (BM)
• La modélisation du niveau métier consiste à
représenter l’entreprise : ses processus, ses
ressources et son organisation
Modèle
d’organisation
Modèle des
Modèle des
ressources
processus
Entreprise
6. Les objectifs du BM
• Le BM peut avoir des objectifs très différents suivant
le contexte
• Principaux buts :
• Réorganiser le S.I.
• Préciser les besoins d’une application
• Optimiser les systèmes informatiques existants
• Préparer la mise en place d’un ERP
• …
7. Préciser les besoins d’un logiciel
• Pallier au manque de définition du contexte métier
lors du démarrage d’un projet informatique
• Cahier des charges incomplet
• Objectifs stratégiques de l’entreprise perdus de vue
• Gérer les risques de mauvais ciblage du projet
• Différence entre besoins réels et besoins exprimés
• Manque de visibilité globale sur l’activité des
utilisateurs
• Tentation d’automatiser les pratiques en cours, sans
profiter du potentiel de changement lié aux
nouvelles technologies
• Cette tâche amont est trop souvent négligée !
• Elle n’est en général pas budgétisée
• Les experts métier sont peu disponibles
8. BM orienté objet avec UML ?
• UML est un standard de modélisation
• Langage commun pour communiquer et capitaliser
• Puissance de modélisation applicable à de multiples
niveaux d’abstraction
• Extensibilité intégrée au langage
• UML est utilisé sur les projets informatiques
• Couverture complète de tout le cycle de développement
• En phase avec les nouvelles technologies
• Continuité des concepts de bout en bout
9. Les diagrammes d’UML
• UML 1.5 propose 9 types de diagrammes :
• Diagramme de cas d’utilisation
Fonctionnel
• Diagramme de classes
• (Diagramme d’objets) DIAGRAMME DE CAS
D'UTILISATION
• Diagramme de séquence
• (Diagramme de collaboration) Statique Dynamique
• Diagramme d’activités DIAGRAMME DE CLASSES DIAGRAMME D'ÉTATS
DIAGRAMME D'OBJETS DIAGRAMME D'ACTIVITÉ
Diagramme d’états
DIAGRAMME DE COMPOSANTS DIAGRAMME DE SÉQUENCE
• DIAGRAMME DE DÉPLOIEMENT DIAGRAMME DE COLLABORATION
• (Diagramme de composants)
• (Diagramme de déploiement)
10. UML pour le BM (1/2)
• Nous privilégions 2 types de diagrammes :
• Diagramme de classes Diagramme d’activités
Client
Chef d'atelier
De man d e De R e p ar at ion
concerne Demande reparation
date
description Verifier la demande
[NOK]
1
V oit u r e 1
[OK]
Prendre un RV
modele
Etablir un devis
immatriculation donne lieu a Mecanicien
kilometrage devis refuse devis accepte
0..1 Effectuer la reparation
1 1 De vis
Verifier le vehicule
1 1 montant
dateValidite
Cle Cart e G r ise [OK] [NOK]
numero immatriculation
Payer la facture
Livrer le vehicule
11. UML pour le BM (2/2)
• Nous utilisons 3 autres types de diagrammes :
• Diagramme de cas d’utilisation
• Diagramme de séquence
Diagramme d’états
12. La démarche de BM avec UML
Identifier les acteurs et les
processus métier
De man d e De R e p ar at ion
concerne
date
description
1
V oit u r e 1
modele
immatriculation donne lieu a
kilometrage
0..1
Décrire les Identifier et décrire les 1 1 De vis
processus métier entités métier 1 1 montant
dateValidite
Client Cle Cart e G r ise
Chef d'atelier numero immatriculation
Demande reparation Client
Verifier la demande Chef d'atelier
Demande reparation
[NOK] <<entity>>
:De man d e De R e p ar at ion
[OK] Verifier la demande
Prendre un RV
Etablir un devis
Mecanicien [NOK]
Prendre un RV Mecanicien
devis refuse devis accepte [OK]
Etablir un devis
<<entity>>
Effectuer la reparation :V oit u r e
<<entity>> [a reparer]
:De vis
devis refuse devis accepte
Verifier le vehicule
[OK] [NOK] Consolider <<entity>>
Effectuer la reparation
Verifier le vehicule :V oit u r e
<<entity>> [reparee]
:Fac tu re
[NOK]
Payer la facture
[OK]
Livrer le vehicule Payer la facture
<<entity>>
:V oit u r e
[a livrer]
Livrer le vehicule
14. Processus métier
• Un processus métier modélise un service
rendu par une organisation
• On parle aussi de cas d'utilisation métier
(“business use case”)
Garage
<<processus métier>>
Réparer une voiture
Client
15. Types d’acteurs métier
• Un acteur métier modélise une
personne ou un rôle qui participe
à au moins un processus métier
• On peut distinguer :
• Business Actor
• Extérieur à l’entreprise : client,
fournisseur…
• Business Worker
• Rôle interne à l’entreprise :
mécanicien, chef d’atelier…
• Case worker, internal worker
16. Diagramme de cas d’utilisation
• Le diagramme de cas d’utilisation UML
permet de mettre en relation les acteurs et
les processus métier
• Très simple, synthétique
Garage
<<internal worker>>
<<processus métier>>
Mecanicien
Reparer une voiture
Client
<<case worker>>
Chef d'atelier
17. Exemple plus complet
<<processus support>>
Acheter des pieces detachees
Fournisseur
<<case worker>> Fournisseur
Chef d'atelier
<<processus métier>>
Reparer une voiture
<<internal worker>>
Mecanicien
<<processus métier>>
Vendre une voiture
Client
<<case worker>>
Commercial
<<processus métier>>
Racheter une voiture d'occasion
18. Plan type détaillé
• Permet de décrire chaque processus métier dans
ses moindres détails
• Plan-type (Template) à définir par entreprise
• Exemple :
• Titre
• Objectif
• Précondition
• Scénario nominal
• Extensions
• Postconditions
• Risques
• Etc.
19. Exemple
Titre : Réparer une voiture
Pré-condition : L'atelier est en état de fonctionnement normal couvrant 80% de ses capacités de réparation avec son personnel présent
et ses pièces détachées.
Scénario nominal
Le processus commence quand un client déclare vouloir faire réparer sa voiture à l'atelier.
1. Le client est accueilli par le chef d'atelier qui vérifie le rendez-vous déjà pris, ou bien planifie un rendez-vous (extension « Prendre
rendez-vous »).
2. Le chef d'atelier demande les clés et la carte grise du véhicule au client. Il donne au client un temps approximatif nécessaire pour
effectuer la réparation et lui soumet un devis.
3. Le client accepte le devis (Erreur 1 : le client refuse le devis).
4. Le chef d'atelier affecte un mécanicien (Alternative 1 : aucun mécanicien disponible).
5. Le mécanicien procède à la réparation (Alternative 2 : il manque une pièce).
6. Lorsque le véhicule est prêt, le chef d'atelier contrôle l'état du véhicule.
7. Si le véhicule est présentable, et lorsque le client est physiquement présent, il procède à la remise de la facture.
8. Le client va payer auprès du service comptabilité et présente la facture payée au chef d'atelier (Alternative 3 : défaut de paiement).
9. Le chef d’atelier livre la voiture au client qui récupère les clefs et la carte grise du véhicule.
…
Alternative 2 : S’il manque une pièce, le mécanicien informe le chef d’atelier qui passe une commande à un fournisseur référencé
(extension : acheter des pièces détachées).
…
Post-condition : La facture est payée, le véhicule est rendu réparé et propre au client.
20. Diagramme d’activités
• Les briques de base
• Activités
• Transitions
• Décisions
• Début et fin(s)
• Compléments
• Fork/join
• Swimlanes
• Signaux
21. Exemple
Client
Chef d'atelier
Demande reparation
Verifier la demande
[NOK]
[OK]
Prendre un RV
Etablir un devis
Mecanicien
devis refuse devis accepte
Effectuer la reparation
Verifier le vehicule
[OK] [NOK]
Payer la facture
Livrer le vehicule
22. Diagramme de séquence
• Définition
• Le diagramme de séquence représente les éléments
intervenant dans un scénario ainsi que les messages
dans leur ordre chronologique
• Notation (très simple !)
Temps
23. Exemple
• Pour la
modélisation des
processus métier,
les participants
sont des acteurs
ou des workers
25. Modèle objet « métier »
• La 2è partie du modèle métier est
constituée par le modèle objet
• Business Object Model (BOM)
• Alors que le modèle des processus
décrit le « quoi », le modèle objet
décrit le « comment »
• Comment les business workers et les
business entities sont reliés et
collaborent pour réaliser les processus
• Sous forme de diag. de classes UML
• élémentaires
• ou plus détaillés (planche suivante)
26. Exemple de modèle objet métier
<<organization unit>>
B OM.Co mp t ab ilit e
+Facture
De man d e De R e p ar at io n
concerne
date
description
1 <<organization unit>>
V o it u r e 1 B OM.At e lie r
+Voiture
modele +DemandeDeReparation
immatriculation donne lieu a +Devis
kilometrage +Cle
+CarteGrise
0..1
1 1 De vis
1
1 1 montant
dateValidite
Cle Cart e G r ise
0..1
numero immatriculation
B O M.Co mp t ab ilit e .Fac tu re
date
montant
description
27. Diagramme d’activité - compléments
• Object Flow
• Une entité métier peut être en sortie
d’une activité (produite)
• ou en entrée d’une activité (utilisée)
• Peut inclure l’état de l’objet entre
crochets, si celui-ci évolue au fil du
processus
• Permet de faire le lien entre le
modèle des processus et le modèle
objet !
28. Exemple consolidé
Client
Chef d'atelier
Demande reparation
<<entity>>
:De man d e De R e p ar at ion
Verifier la demande
[NOK]
Prendre un RV Mecanicien
[OK]
Etablir un devis
<<entity>>
:V oit u r e
<<entity>> [a reparer]
:De vis
devis refuse devis accepte
Effectuer la reparation
<<entity>>
Verifier le vehicule :V oit u r e
<<entity>> [reparee]
:Fac tu re
[NOK]
[OK]
Payer la facture
<<entity>>
:V oit u r e
[a livrer]
Livrer le vehicule
29. Diagramme d’états
• Le diagramme d’états est une représentation du
cycle de vie auquel doivent se conformer toutes les
instances d’une classe donnée
• C’est un diagramme très puissant, qui permet d’aller
très loin dans la précision et la complétude de la
description du comportement
• Un diagramme d’états est forcément associé à une
classe, mais toutes les classes n’en ont pas besoin
32. Liens avec les disciplines en aval…
Business Modeling
Business Rules, Business Use Case Model
Business Object Model
Requirements
Analysis (& Design)
Use Case Model
Analysis Model
33. Liens entre disciplines : détail
• BPM (Business Process Model)
• Les activités à informatiser des processus métier
sont des cas d’utilisation candidats
• Les acteurs (ou workers) métier concernés par ces
activités deviennent naturellement des acteurs du
système informatique
• BOM (Business Object Model)
• Les entités métier manipulées par les activités à
informatiser deviennent des classes d’analyse
(entités)
34. Lien avec Requirements : exemple
Client
Chef d'atelier
Demande reparation
Verifier la demande
Activités à
[NOK]
informatiser
[OK]
Prendre un RV
Etablir un devis
Mecanicien
devis refuse devis accepte
Effectuer la reparation
Verifier le vehicule
[OK] [NOK]
Poste de travail du chef d'atelier
Payer la facture
Gerer un RV client
Livrer le vehicule
<<case worker>>
Chef d’atelier Etablir un devis
Chef d'atelier
35. Lien avec l’analyse : exemple
De man d e De R e p ar at io n
concerne
date Ajouter
description
« Client » !
1
V o it u r e 1
modele Entités métier
immatriculation donne lieu a
kilometrage à informatiser
0..1
1 1 De vis
1
1 1 montant
dateValidite
Cle Cart e G r ise
0..1
numero immatriculation
B O M.Co mp t ab ilit e .Fac tu re
date
montant
description
36. Pourquoi utiliser UML pour le BM ?
• UML fournit un langage commun pour les analystes
métier et les concepteurs
• UML est visuel
• UML décrit les processus métier à la fois
structurellement et dynamiquement
• UML vous aide à dériver de meilleures exigences
système
• UML est orienté objet
38. Les diagrammes d’UML 2
• UML 2.0 propose 13 types de diagrammes :
• Diagramme de cas d’utilisation
• Diagramme de classes
• Diagramme d’objets
• Package diagram New !
• Composite structure diagram New !
• Interaction overview diagram New !
• Diagramme de séquence Modified !
• Diagramme de communication
• Timing diagram New !
• Diagramme d’activité Modified !
• Diagramme d’états
• Diagramme de composants Modified !
• Diagramme de déploiement
39. Diagramme d’activité UML 2.0
• Le diagramme d’activité(s) a été notablement modifié
• Voir la présentation sur UML 2.0 aujourd’hui !
• L’alignement avec d’autres formalismes de
modélisation de processus devrait être plus facile …
• Cf. www.bpmi.org
• BPML : Business Process Modeling Language