03 MTI820-Acetates-SpecificationDesBesoins - 1pp

MTI820 −
Entrepôts de données et intelligence d’affaires
Spécification des besoins d’affaires
Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 1

Le cycle de vie d’un projet en BI
• Diagramme de flux de travail:
Conception de Sélection et
l’architecture installation des Croissance
technique produits
Définition
Planification Conception et
des Modélisation Conception
de projet / développement Déploiement
besoins des données physique
programme du système ETL
d’affaires
Conception des Développement

application de des applications Maintenance
BI de BI
Gestion de projet / programme

« La partie la plus difficile de la spécification des besoins n’est
pas de documenter ce que les utilisateurs veulent; il s’agît
plutôt de l’effort pour aider ceux-ci à déterminer ce dont ils
ont besoin qui peut leur être fourni avec succès »
− Steve McConnell (Software Project Survival Guide, Microsoft Press)

Questions
• Quelle est la différence entre les types suivants de
besoins? :
– Besoins d’affaires
– Besoins fonctionnels
– Besoin non-fonctionnels
– Besoins techniques

Spécification des besoins
• Besoins d’affaires:
– Représentent des objectifs haut niveau d’une entreprise qui
justifient la valeur d’entreprendre un certain projet;
– Ex: augmenter le taux de réponse aux campagnes de
marketing ciblées.
• Besoins fonctionnels:
– Dérivent des besoins d’affaires;
– Expriment une action que doit effectuer le système en
réponse à une demande;
– Ex: produire automatiquement un rapport de synthèse des
ventes hebdomadaires.

Spécification des besoins
• Besoins non fonctionnels:
– Décrivent des qualités que le système doit avoir;
– Ex: utilisabilité, performance, disponibilité/fiabilité,
sécurité, etc.
• Besoins techniques:
– Dérivent des besoins fonctionnels et non-fonctionnels
– Ex: Outil de forage de données, portail Web, cube de
données, etc.

Processus d’affaires
• Processus d’affaires (business process / subject area):
– Ensemble de faits observables (métriques) représentant
des activités de l’entreprise
• Ex: vente, facturation, livraison, commande, etc.
– Typiquement supportés par un système opérationnel
• Ex: système de facturation, système CRM, etc.
– Fournissent des indicateurs clés de performance (key
performance indicator - KPI)
• Ex: profits (vente), taux de rétention (CRM), délai moyen de
livraison (livraison), etc.

• Exemples:
Domaine Processus / sujet Faits
• Prix de vente
• Prix suggéré du manufacturier
Ventes • Prix des options
Automobile • Crédits du concessionnaire
• ...
Maintenance …
• Chambres occupées
• Chambres vacantes
• Vacantes non-disponibles
Occupation hôtelière
Tourisme • Nombre d’occupants
• Recettes
• ...
Vols …

Deux niveaux d’analyse des besoins
• Processus d’analyse (Kimball):
Analyse
niveau programme
BP: processus d’affaires (business process)
Besoins d’affaires
regroupés par BP
Sélection du BP
(matrice en bus,
diagramme de
priorisation)
Besoins
BP Analyse fonctionnels, Développement
prioritaire niveau projet non fonctionnels, datamart
techniques

Questions
• Comment la spécification des besoins diffère-t-elle entre

les niveaux programme et projet?
• Comment la spécification des besoins diffère-t-elle entre
le personnel d’affaires et le personnel des TI?

• Niveau programme:
– Comprendre les besoins d’affaires dans une perspective
englobant toute l’entreprise;
– Surtout les besoins de la haute direction;
– Normalement fait une seule fois au début.
• Niveau projet:
– Analyse plus détaillée des besoins, concentrée sur un
projet (sujet) bien défini;
– Surtout les besoins des cadres intermédiaires et des
analystes d’affaires;
– Fait pour chacun des projets.

• Tableau comparatif:
Composante Niveau programme Niveau projet
• Recherche concentrée sur un processus
Préparation • Recherche plus large sur l’entreprise.
d’affaire spécifique.
• Représentation inter-fonctionnelle • Représentation verticale centrée sur le
horizontale; processus d’affaires concerné;
Participants
• Proviennent surtout de la haute • Surtout des cadres intermédiaires et des
direction. analystes d’affaires.
• Compréhension de haut niveau des • Informations et besoins d’analyse plus
Questions principaux objectifs, opportunités et spécifiques et détaillés;
processus d’affaires. • Rapports et analyses existants.
• Évaluation de faisabilité préliminaire de • Profilage préliminaire de 1-2 sources
Audit des données
plusieurs sources potentielles. primaires de données.
• Description des processus d’affaires et

des besoins correspondants; • Description détaillée des besoins portant sur
Documentation le modèle de données, les applications de BI
• Version préliminaire de la matrice de et l’architecture technique.
données en bus.

Personnel d’affaires versus des TI
• Personnel d’affaires:
– ✖: Ne pas demander ce qu’ils veulent avoir dans l’entrepôt
de données;
– ✔: Discuter plutôt des éléments suivants:
• Leur travail au quotidien;
• Leur objectifs;
• Leur défis, etc.
• Personnel des TI:

– Permet de déterminer la disponibilité et la qualité des
données supportant les besoins des utilisateurs d’affaires
(audit des données);
– Permet d’identifier les défis / limitations techniques
potentiels du projet.
Guide d’entrevue (tiré du livre de Ralph Kimball)
Introduction
• Discuter des objectifs du projet d’entrepôt de données et de son statut;
• Discuter des objectifs de l’entrevue;
• Présenter les différents membres de l’équipe;
• Confirmer la durée de l’entrevue;
• Décrire brièvement les étapes qui suivront l’entrevue.
Responsabilités
• Décrivez votre département et votre projet
• Quelles sont vos principales responsabilités?

Objectifs d'affaires et défis (haute direction / niveau programme)
• Quels sont les objectifs de votre organisation? Qu’est ce que l'entreprise tente d'accomplir? Quels sont vos
principaux objectifs d'affaires?
• Comment identifiez-vous les attentes reliées à votre domaine d'affaires? Comment fixez-vous les attentes
de votre entreprise?
• Comment mesurez-vous le succès de l'entreprise? Quelles métriques utilisez-vous? Dans quelle mesure
êtes-vous capable de savoir que vous avez obtenu les résultats escomptés? Que vous allez dans la bonne
direction? A quelle fréquence mesurez-vous votre performance?
• Quels sont les fonctions et départements au sein de votre organisation qui sont primordiaux dans l'atteinte
de vos objectifs? Quels rôles jouent-ils? Comment collaborent-ils pour assurer le succès de l'organisation?
• Quels sont les principaux défis auxquels vous faites présentement face? Selon vous, qu'est ce qui pourrait
vous empêcher de surmonter ces défis et d'atteindre vos objectifs? Quel serait l'impact de ne pas être en
mesure de surmonter ces défis sur l'entreprise?
• Voyez vous présentement ou dans le future de votre organisation des opportunités de profits qui ne sont
pas adressées aujourd'hui?
• Comment vous comparez vous à la compétition au niveau de l'utilisation des technologies de l'information,
sur le plan global et sur le plan décisionnel?
• Êtes-vous en mesure de réagir rapidement aux conditions changeantes du marché?

Objectifs d'affaires et défis (gestionnaires & analystes / niveau projet)
• Comment identifiez-vous les attentes reliées à votre domaine d'affaire? Comment fixez-vous les attentes
de votre entreprise?
• Quels sont les principaux défis auxquels vous faites présentement face? Selon vous, qu'est ce qui pourrait
vous empêcher de surmonter ces défis et d'atteindre vos objectifs? Quel serait l'impact de ne pas être en
mesure de surmonter ces défis sur l'entreprise?
• Comment identifiez-vous les problèmes et les exceptions? Dans quelle mesure êtes-vous capable de dire
que des problèmes pointent à l’horizon?
• Décrivez vos produits? Comment distinguez entre vos différents produits? Comment les catégorisez-vous?
Si nous supposons que le volume de votre catalogue nous empêche de passer en revue l'ensemble de vos
produits lors de la recherche d'un produit spécifique, comment faite vous pour cibler votre recherche
précisément?
• Ces différentes catégories sont-elles stables ou sont-elles appelées à changer fréquemment? Dans la
mesure où elles sont appelées à changer, quel est l’impact de ce changement sur vos processus d’analyse?
• Recommencez l’exercice précédent pour l’ensemble des axes d’analyse important: clients, fournisseurs,
territoires ….

Besoins d'analyse (haute direction / niveau programme)
• Quelle est l'importance qu'occupe l'analyse des données au niveau des décisions que vous et vos
principaux gestionnaires prenez pour gérer les opérations de votre organisation?
• Quelle information est jugée primordiale pour prendre et supporter les décisions au sein de votre
organisation? Comment obtenez-vous cette information aujourd'hui?
• À votre connaissance, y a-t-il de l'information qui ne vous est pas disponible ou qui n'est pas accessible
aujourd'hui mais qui aurait un impact important sur l'atteinte de vos objectifs?
• Quels rapports utilisez-vous aujourd'hui? Quelle est l'information importante sur ces rapports? Comment
utilisez-vous cette information? Si ces rapports étaient dynamiques, que feraient-ils de différent?
• Quelles sont les opportunités qui s'offriraient à vous si vous étiez en mesure de bénéficier d'un meilleur
accès à votre information? Quel en serait l'impact financier? Quel en serait l'impact sur l'organisation?

Besoins d'analyse (gestionnaires & analystes / niveau projet)
• Quelles sont les données utilisées? Comment obtenez-vous présentement ces données? Que faites-vous
avec ces données une fois obtenues? Devez vous les manipuler?
• Quel type d'analyse voudriez-vous être en mesure d'effectuer? Voyez-vous des potentielles améliorations
possibles aux méthodes/processus que vous utilisez actuellement?
• Quel sont les types d'analyse ad-hoc que vous effectuez de façon régulière? Qui sont les membres de votre
équipe qui typiquement effectuent ou demandent ce genre d'analyse? Quel est le but de ces analyses? Quel
est le niveau de satisfaction face au temps requis pour obtenir les résultats de ces analyses? Les membres
de votre équipe ont ils le temps de pousser plus à fond ces analyses?
• En vous basant sur la qualité et sur le niveau de détail des données que vous traiter, quel pourcentage de
temps passez-vous à manipuler les données et quel pourcentage de votre temps passez-vous à les analyser?
• Quels sont les types d’analyses prédéfinies (rapports) que vous effectuez le plus souvent? Quelle est
l'information importante sur ces rapports? Comment utilisez-vous cette information? Si ces rapports étaient
dynamiques, que feraient-ils de différent?
• Devez vous retravailler ces rapports? Quelles informations aimeriez-vous voir ajoutées aux rapports?
Quelles informations sont inutiles et pourrait être retirées?
• Quelles sont les capacités analytiques que vous aimeriez avoir?
• Existe-t-il aujourd’hui des goulots d’étranglement importants qui nuisent à l’accès à l’information?
• Quel horizon de données historiques avez-vous besoin dans le système?

Entrevues avec le personnel des TI
• Audit de données:
– Détermine la faisabilité du projet en termes de la
disponibilité de données de qualité suffisante.
• Entrevue de conformité / sécurité:

– Détermine les directives, standards et mandats
règlementaires de l’entreprise par rapport à l’accès et
l’utilisation des données;
– Ex: politiques de purge/rétention de données, vie privée
(privacy), etc.

Préparation des entrevues
• Recherches préalables:
– Se renseigner sur l’entreprise et le domaine d’affaires ciblé.
• Sélection des personnes à interviewer:
– Impossible de s’entretenir avec tout le monde;
– Choisir les personnes clés: influentes, ouvertes, etc.
– Demander l’avis du ou des sponsors du projet;
– Utiliser l’organigramme;
– Ne pas considérer la disponibilité comme critère de sélection.
• Préparation des questionnaires:
– Doit être faite d’avance;
– Varie selon la fonction et le niveau hiérarchique de la personne
interrogée.

Synthèse des besoins recueillis
• Une fois les entrevues terminées, on regroupe les
besoins par processus d’affaires (approche Kimball).
• Livrables:
1. Rapport d’entrevues;
2. Document de spécification des besoins;
3. Matrice de données en bus;
4. Diagramme de priorisation des processus.

• Rapports d’entrevue:
– Description des responsabilités de la personne interrogée;
– Processus et besoins identifiés lors de l’entrevue:
• Description sommaire des besoins;
• Obstacles analytiques présents;
• Besoins spécifiques en termes d’analyses et de données;
• Impact d’affaires potentiels.
– Critères de succès.

• Document de spécification des besoins:
– Vue d’ensemble de l’entreprise;
– Description détaillée du projet;
– Besoins regroupés par processus d’affaires;
– Évaluation préliminaire de la faisabilité en termes de
données;
– Matrice en bus de données, au niveau de l’entreprise;
– Critères de succès.

Matrice en bus de données
Fournisseur
Vendeur
Magasin
Produit
Région
Client
Date
Processus / dimension
Vente et Marketing X X X X X X
Finance et comptabilité X X X X X X
Approvisionnement X X X X X
Inventaire X X X
Ressources Humaines X X X
• Décrit les dimensions d’analyse requises pour chaque processus d’affaires.

Diagramme de priorisation des processus
BP1
BP6
impact potentiel BP4
BP3
BP2 BP5
faisabilité
• Permet d’identifier les processus d’affaires faisables ayant le

plus grand impact pour l’entreprise.

Question
• Comment fait-on pour évaluer la faisabilité et l’impact
d’un projet centré sur un certain processus d’affaires?

Critères de succès du projet
• À demander à la fin de l’entrevue;
• Permet de mieux comprendre les attitudes et attentes
des utilisateurs;
• Exemple (question):
– « Quelle sont les principales fonctionnalités et caractéristiques
devant se retrouver dans le système afin de pouvoir le
considérer comme un succès? »
• La réponse doit être un critère quantifiable et mesurable;
• Exemple (réponse):
– « Un rapport X avec paramètres Y doit pouvoir être généré sur
demande en moins de Z secondes »

Exemple : Adventure Works Cycles
Tiré de: The Microsoft Data Warehouse Toolkit, 2nd Edition
• Ventes de produits dans quatre catégories: bicyclettes,

pièces, vêtements, accessoires
• Données de juillet 2005 à juin 2008
TotalSales Column Labels

Row Labels 2006 2007 2008 Grand Total
Accessories 36,815 124,433 1,077,065 1,238,313
Bikes 22,090,618 28,179,554 44,350,354 94,620,526
Clothing 66,328 750,716 1,283,474 2,100,517
Components 1,166,765 4,629,101 6,003,210 11,799,077
Grand Total 23,360,526 33,683,805 52,714,103 109,758,434
Total ventes par année fiscale et catégorie de produit

United States 15,535,349 20,563,610 25,963,721 62,062,681
United Kingdom 550,507 5,083,062 6,257,260 11,890,829
Canada 3,591,852 2,763,865 5,147,140 11,502,857
Australia 2,568,701 2,099,585 5,805,290 10,473,577
France 414,245 2,021,672 4,714,497 7,150,415
Germany 513,353 593,247 3,574,747 4,681,348
NA 186,518 558,762 1,251,447 1,996,727
Grand Total 23,360,526 33,683,805 52,714,103 109,758,434
Commandes par pays / région

Internet 7,072,084 5,762,134 16,473,618 29,307,837
Reseller 16,288,442 27,921,671 36,240,485 80,450,597
Grand Total 23,360,526 33,683,805 52,714,103 109,758,434
Commandes par canal de ventes

Organigramme: Ken Sánchez
CEO
(290)
Peter Krebs
James Hamilton Brian Welker Jean Trenary David Bradley
Terry Duffy Laura Norman Production Control
VP Production Mgr VP Sales IS Manager Marketing Mgr
VP Engineering CFO
Production Production Control Sales Info Services Marketing
And Tool Design Finance & HR
Manufacturing Manufacturing Sales & Marketing Exec Gen & Admin Sales & Marketing
R&D Exec Gen & Admin
(8) (201) (18) (10) (9)
(14) (29)
Amy Alberts
[Multiple Managers]
David Liu Gary Altman European
Mfg. Production
Finance Facilities Mgr. Sales Mgr
(178)
(8) Facilities & (4)
Maintenance
(7)
Paula Barreto de
Mattos Pilar Ackerman Syad Abbas
Human Resources Shipping & Receiving Pacific Sales Mgr.
(6) Supervisor (2)
Inventory Mgmt.
(6)
Wendy Kahn
Purchasing Stephen Jiang’
(13) North American
A. Scott Wright
Sales Mgr.
Master Scheduler
Mfg. Production (11)
Control
(5)
Haxem Abolrous
QA Manager
Quality Assurance
(11)

Example Interview Summary
Interviewee: Brian Welker, VP of Sales
Date: 7/25/2009
Interviewer: Joy Mundy
Scribe: Warren Thornthwaite
Additional attendees: Stuart Ozer, Carolyn Chau, Joy Byrd, Dave Wong
Roles and Responsibilities

Brian Welker is head of the sales organization. He’s responsible for sales to Resellers, which was $36.2 million in
2008, or about 68 percent of total sales. He has 17 people who report to him, including 3 regional sales managers.
Brian is excited about his team and eager for them to be successful. They are all “bike freaks” who love to ride bikes
and love to talk about them—perfect bike sales people. Brian is measured on achievement of the total Reseller sales
target for the year.
Information Requirements
Brian is particularly frustrated with how difficult it is to get information out of the company’s systems. When he asks
for a report, it can take days or weeks to get the information. Often he’s told “It can’t be done.” The major analytic
areas that Brian works with are as follows:
Sales planning: Planning for the year begins in the fall of the previous year with the Sales planning process. Sales
territories are based on geography. All new customers are assigned to a sales territory when they place their first
order based on where they are located. Sales planning includes looking at the following:
Growth analysis: Overall market, new products, new geographies, new sales people.
Customer analysis: Who are the top customers, how have they changed over the last year?
Territory analysis: Where are top customers located, what are the current sales territories, and how balanced are
they? How does this map to sales regions?

Information Requirements (suite…)
Brian and Ramesh Meyyappan (the analysts who work in IT) also look at sales by sales regions, which are groupings
of customers based on the state where they’re located. Regions overlap sales territories and are based on seasonal
buying patterns and regional preferences. Being able to group historical sales like this helps the sales team do a
better job of forecasting monthly sales. They usually look at regional sales a lot during the sales planning cycle and
then compare actuals to the forecast during the year. Every year, they change the regions a bit to line up with
changes in buying patterns.
Ramesh does all of this data analysis for the Sales forecasting and quota assignment process in a spreadsheet. The
spreadsheet includes territory growth factors, allocations, and manual adjustments. The planning process is totally
manual and takes a couple of months in the fall, and maybe a week per month to do the reporting during the year.
During the annual planning process, Brian wants to be able to see reseller customer orders by year by customer
territory, regardless of the sales rep assigned to the territory. In previous jobs, Brian would adjust the size of the
territories by moving customers from one territory to another with the goal of making the territories more even. He
has not done this at AWC yet, so all customers are still assigned to their original territory. Sales reps can be
reassigned to different territories, usually when a sales rep leaves.
Sales performance: Once the planning process is done, Brian wants to see sales according to the new territory
assignments, all the way back through history so he can compare with actuals as they come in. At any time, Sales
must be able to re-create historical sales and commission reports based on what happened at the time of the order,
not which territory gets credit today.
Brian also wants to look at orders from a sales rep perspective. The first thing he wants to see at the start of the
week is how his sales reps are doing year to date. If Brian sees a problem in the higher level data, he wants to be
able to drill down to detailed orders for individual reps. Of course, Brian has other reports he would like to see: for
example, top 20 customers and orders by Reseller versus online.

Basic sales reporting: Brian wants to take better advantage of the customer information buried in the orders
transaction system. The sales reps would really appreciate it if they could get a list of the customers in their territory
ranked by orders. Because most sales go to a small percentage of Resellers, the sales reps would concentrate on
making sure those important customers are happy.
Beyond this, Brian knows that 17 percent of 2002 customers did not reorder in 2003. And to date in 2004, he still
has not heard from an additional 17 percent or so. His sales people could use this information to bring the best of
these customers back to the business.
Price lists: The fact that the sales reps are out in the field most of the time makes it difficult for them to keep their
price lists current. The price list changes fairly often, but only a few things on the list change. It would be great to
get a report to the sales reps that flagged changes and special offers, and maybe even highlighted the relevant
customers.
Special offers: The special offers could be a great sales tool. AWC just finished an inventory clearance sale on the
silver Mountain 500s. The color didn’t sell as well as others, resulting in too many in stock at model changeover.
Mary Gibson, the marketing assistant for mountain bikes and David Liu in Finance put their heads together to come
up with ideas to stimulate demand and came up with a 40 percent off offer. This is something the sales people can
work with, but it’s a random process. They’d like a report that shows which of their customers bought a lot of the
product that is on special offer to see if they’re interested in more at a great price.
Brian would like his sales people to start with the biggest potential customers first and keep selling down the list
until they run out. Actually, Brian thinks the business would be better served if they contacted the more profitable
customers about special offers first. Some of the biggest customers are big because they scoop up specials, which
don’t make a lot of money for AWC. That’s another thing: The sales reps need to know when out of stocks occur on
special offers.

Customer satisfaction: Brian would like to create some measures of customer satisfaction and has been trying to get
more information out of the customer care system lately, with limited success. He would love to be able to track
calls by complaint type, product, sales region, and customer to get a sense for customer satisfaction and product
quality. He also thinks comparing order date and ship date in the sales data to identify late orders, and determining
the percentage of returned items might be indicators of customer satisfaction. This would make a great start at a
customer satisfaction scorecard.
International support: The company has been growing internationally, but the transaction systems haven’t kept up.
The systems do take orders in multiple currencies, but none of the descriptions has been translated from English.
This is a problem for the sales people, who have split up the product list and done the translations themselves. This
doesn’t work in the long run because no one knows if they’ve translated the information correctly. All materials
must be bilingual to comply with Canadian law. The product tags and documents are already bilingual, but the sales
materials are not.
Additional Issues
Brian expressed a frustration on the part of his sales force about the difficulty they have using existing reports. It is
our sense that Brian would like an analytic system that provides his sales reps most of the information they need in
a standard format with just a few keystrokes. The time zone differences make it hard for some of them to get live
support from headquarters. If they need to get custom information, he would like it to be easy for them to get it
themselves.
Success Criteria
• Brian would like the system to provide him and his team with:
• Easy access to basic sales data for the whole field organization
• Flexible reporting and analysis tools
• All the data in one place (especially sales and forecast data)

Processus
Thème analytique Analyses demandées Commentaires
d'affaires
- Analyses de l'historique de commandes des
Planificationdes ventes - commandes Par client, par territoire, par région de vente
revendeurs
La prévision est un processus utilisant les
-Prévisions des ventes - commandes
donnéesde vente en entrée
Performance des ventes - Commandes par territoire courrant - commandes

- Commandes par territoire d'origine - commandes
- Rapport de performance des représentants aux - commandes Commandes et prévisions par représentant aux
ventes - prévisions ventes
- Revendeurs classés par le nombre commandes

Rapports de vente - commandes
dans un certain territoire
Client n'ayant fait aucune commande dans les X
- Liste de clients perdus - commandes
derniers mois
Listes de prix - Liste des prix courants - commandes Problème de connectivité
- Clients pertinents par territoire, basé sur

Offres spéciales - commandes
l'historique de commandes
- Status d'inventaire (rupture d'inventaire) - inventaire
Problème de connectivité au niveau

Saisie de commandes - Inventaire courant - inventaire
transactionnel
- Traduction des descriptions de produist dans la - N/A (dimension Problème au niveau des systèmes
Support international
langue courante Produit) transactionnels
Les sondages sont un processus d'affaires, est

Satisfaction client - Sondages de satisfaction - sondages
sont une source de l'entrepôt de données
- Métriques de satisfaction reliés aux commandes - commandes e.g. date due vs date envoi
- Retours par revendeur par raison de retour - retours
Touche à plusieurs processus d'affaires, incluant

- Scorecard de produits
Profitabilité de produits - presque tout marketing, achats, fabrication, inventaire, envois,
- Élagage de lignesde produtction
retours et support à la clientèle

Thème analytique Analyses demandées Processus d'affaires Commentaires
- Scorecard client
Rentabilité des clients - presque tout
- Renégoctiation de contrats client
Prévisions de production - Historique complet de commandes par produit - commandes
Réduction des coûts de fabrication - Coûts reliés aux achats - procuration

et d'inventiaire - Coûts reliés à la fabrication - fabrication
- Coût reliés à l'inventaire - inventaire
- Quantitéscommandées - commandes
- Retours par produits par raison - rendements

Amélioration de la qualité produit - Appel au support à la clientèle par produit par
- assistance client
raison
- Demandes de support client Web par produit par
- assistance client (web)
raison
- Historique complet des commandes par produit

Planification et suivi de produits - commandes
et hiérarchie de produits
- Commandes de produits croisés pour la
- commandes
comparaison de séries temporelles
- Commandes par région publicitaire par - commandes

Publicité (analyse d'impact)
promotion - promotions
- Commandes par canal de vente (analyse de

Affaires Internet - commandes
canibalisation)
- Commandes par distance - commandes Nécessite des données géo-codées
Profils démographiques des - Nombre de clients Internet par profil Nécessite SCD type 2 pour identifier des
- commandes
clients Internet démographique tendances
- Segmentation de clients par profil - Nécessite support à la fouille de données

Profilage de clients et marketing
démographique, habitudes d'achat, région - commandes - Nécessite SCD type 2 pour identifier des
ciblé
démographique tendances
Programme de fidélité clients - Historique de commandes directes de clients - commandes

Matrice en bus de données:
Dimensions
Territoire de vente
Client (revendeur)
Client (Internet)
Canal de vente
Raison d’appel
Installation
Promotion
Monnaie
Employé
Produit
Date
Prévision des ventes X X X X X X X
Commandes X X X X X X X X X
Suivi d’appels X X X X X X X
Retours X X X X X X X X
… …

Diagramme de priorisation:
Haute
Rentabilité Commandes
client
Rentabilité Prévisions
produit commandes
Impact d’affaires
Suivis appels
Coûts Retours
fabrication
Faible
Faible Haute
Faisabilité

Analyse détaillée
• À identifier:
– Indicateurs de performance;
– Dimensions d’analyse et leur hiérarchies;
– Les faits et leur granularité;
– Historique requis de données;
– Qualité requise des données;
– Fréquence de mise à jour des données;
– Accès souhaité aux données.

Analyse détaillée
• Dimensions d’analyse:
– Descripteurs servant à filtrer, grouper et étiqueter un
ensemble de données;
– S’obtiennent des questions formulées par les utilisateurs;
– Exemples:
Fonction Exemple de question
VP marketing Combien de revenus notre nouveau produit génère-t-il par:

mois, division, démographique de clients, bureau de vente,
comparativement au produit précédent, etc. ?
Manager marketing Quelles sont les statistiques de vente par:
produit ou catégorie de produit, semaine ou mois, canal de
distribution ?
Contrôleur financier Quelles sont les dépenses par:
valeurs actuelles vs budget, mois ou trimestre, poste, district ou
division, etc. ?

Analyse détaillée
Catégorie Processus Dimensions
• Temps
• Promotion
Chaîne de supermarché Ventes
• Produit
• Magasin
• Temps
• Envoyé-à
Entreprise manufacturière Livraisons • Envoyé-par
• Produit
• Entente (deal)
• Temps
• Agent
• Type
Compagnie d’assurances Réclamations
• Police
• Statut
• Entité assurée
• Temps
• Client
• Vol
Transporteur aérien Vols
• Aéroport
• Classe de tarif
• Statut

Analyse détaillée
• Hiérarchies dimensionnelles:
– Précisent les différents niveaux de détail de l’analyse le long
d’une certaine dimension;
– Les niveaux sont souvent «emboîtés» les uns dans les autres,
mais pas toujours;
– Les niveaux sont parcourus à l’aide des opérations de drill-
down et roll-up;
– Exemples:
Dimension Hiérarchie
Temps jour < mois < année < …
Région succursale < ville < région < province < pays < …
Ressource employé < équipe < département < division < …
Produit no série < code < marque < catégorie < famille < …

Analyse détaillée
• Navigation dans une hiérarchie:

Analyse détaillée
• Granularité des faits:
– Le niveau de détail le plus fin d’une mesure ou métrique;
– Découle du processus d’affaire;
– A un impact sur la faisabilité du projet.
– Exemple:
• Transaction: (ID client, code produit, date (jour), montant);
Analyses possibles
• Ventes par code /marque/catégorie de produits;
• Ventes par jour/mois/année;
• …
Analyses impossibles
• Ventes par heure/période de la journée;
• Ventes par magasin/région/province;
• …

Analyse détaillée
• Historique des données:
– La période en nombre de jours/mois/années couverte par
les données;
– Le nombre de données (faits) disponibles durant cette
période;
– Certaines analyses requièrent une historique minimale
pour être menée (ex: modèles de prédiction);
– Les systèmes sources doivent être en mesure de fournir
ces données.

Analyse détaillée
• Qualité des données:
– A un impact direct sur la faisabilité et la complexité de la
solution;
– Se détermine à partir des audits de données (personnel en
TI) et du profilage de données;
– À vérifier: données manquantes/invalides, granularité, etc.

Analyse détaillée
• Fréquence des mises à jour:
– Faites en lot, sur demande ou en temps-réel;
– Selon les besoins des utilisateurs;
– A un impact sur l’architecture technique (ex: serveurs,
réseau, etc.).
• Accès aux données:

– L’information doit-elle être accédée de n’importe où ?;
– L’accès aux donné doit-il être sécurisé/contrôlé ?;
– Technologies: plateformes mobiles, portail Web, etc.

Question
• Quels sont les différents types d’utilisateurs d’une
solution de BI?
• Comment fait-on pour les distinguer?

Utilisateurs de BI

Connaître les utilisateurs
• Capacités techniques:
– Perception biaisée de leur niveau d’expertise (environ
10% à 15% des utilisateurs le sont);
– Ne pas leur demander directement. Se baser sur les outils
qu’ils utilisent dans leurs fonctions;
– Détermine la complexité technologique des applications
de BI.
• Temps disponible à l’analyse:

– Varie beaucoup d’un utilisateur à l’autre (ex: VP versus
analyste);
– La plupart des utilisateurs ont peu de temps;
– Détermine la complexité fonctionnelle des applications
de BI;
• Type de questions/analyses:
– État courant de l’entreprise:
• Rapports, tableaux de bord, scorecards.
– Investigation ad hoc:
• Requêtes ad hoc, rapports paramétrables;
– Exploration dynamique et détaillée:
• Drill-down cubes OLAP.
– Découverte de relations/patrons/tendances:
• Forage de données, analyse prédictive.

• Capacité technique versus temps:
Foreurs
(requêtes ad-hoc, forage de données)
Explorateurs
(analyse OLAP, requêtes ad-hoc)
Temps
Cultivateurs
(rapports paramétrables, analyse OLAP)
Opérateurs
(rapports paramétrables, tableaux de bord)
Visiteurs
(rapports, scorecards, tableaux de bord)
Capacité technique

Types d’utilisateurs
• Visiteurs:
– Cadres supérieurs ayant peu de temps à consacrer à
l’utilisation de la solution BI;
– Besoins:
• Connaître le statut des indicateurs de performance à
intervalles réguliers;
• Identifier des items d’intérêt sans difficulté;
• Sélectionner de l’information sans avoir à naviguer
dans l’interface;

• Opérateurs:
– Gestionnaires départementaux, superviseurs, etc.;
– Besoins:
• Obtenir des réponses immédiates basées sur des
données actuelles et fiables;
• Connaître l’état courant des métriques de performance;
• Avoir un accès rapide à de l’information détaillée;
• Interface simple permettant des analyses rapides des
données.

• Cultivateurs:
– Analystes d’affaires en marketing, vente, finance, etc.;
– Besoins:
• Avoir un accès à des données de qualité, intégrées de
diverses sources;
• Définir facilement des requêtes simples à l’entrepôt de
données;
• Comparer les données actuelles avec les données
historiques.

• Explorateurs:
– Chercheurs et analystes techniques avancés;
– Besoins:
• Lancer des requêtes ad hoc et imprévisibles;
• Obtenir de grandes quantités de données servant à des
analyses complexes;
• Longues sessions d’analyse en rafale (i.e., pas à
intervalle régulier).

• Foreurs:
– Analystes spécialisés en forage de données ou
consultants externes;
– Besoins:
• Accès à une très grande quantité de données
historiques couvrant une période de plusieurs années;
• Appliquer des outils de forage de données pour
identifier des corrélations et des patrons utiles à la
prise de décision;
• Pouvoir interpréter les résultats obtenus.

Question
• Comment peut-on s’assurer que notre compréhension
d’un requis correspond bien à ce qui a été formulé par
l’utilisateur?

Validation des besoins
• Incertitudes:
– L’utilisateur ne sait pas toujours ce qu’il veut;
– L’utilisateur ne sait pas toujours communiquer ses besoins;
– L’impact de la solution est difficile à prévoir;
– La qualité des données n’est pas certaine.

Validation des besoins
• Prototypage:
– Philosophie de développement agile;
– Solution rapide et non coûteuse;
– Réduit le risque de ne pas répondre aux besoins;
– Approche itérative;
– L’effort investi sera capitalisé dans les prochaines étapes.

Consignes pour la spécification des besoins
1. Ne pas confondre les besoins d’une solution BI avec
ceux d’un système d’informations transactionnelles:
– Besoins BI sont centrés sur les processus et valeurs
d’affaires, non pas sur les données ou les technologies;
– Besoins BI sont plus complexes et diversifiés.
2. Ne pas confondre les besoins au niveau programme et

au niveau projet:
– Besoins généraux de l’entreprise vs spécifiques à un
processus particulier;
– Les personnes à interroger diffèrent.

3. Bien séparer les besoins d’affaires, fonctionnels et
techniques:
– Les besoins fonctionnels découlent des besoins d’affaires;
– Les besoins techniques découlent des deux précédents.
4. Utiliser l’approche «elicit, specify and test »:

– Elicit: aider l’utilisateur à identifier leurs besoins;
– Specify: documenter les besoins;
– Test: s’assurer que les besoins sont clairs, complets,
cohérents, nécessaires et faisables.

5. Avoir un processus clair pour gérer les besoins:
– Le processus doit comprendre les éléments suivantes:
• Identification ex: code unique;
• Enregistrement ex: patron de description;
• Traçage ex: technique è fonctionnel è d’affaires;
• Changement ex: date et heure de modification;
• Classification ex: affaires vs fonctionnel vs technique;
• Vérification ex: clarté, nécessité, faisabilité, etc.;
• Priorité ex: faible vs moyenne vs élevée.

03 MTI820-Acetates-SpecificationDesBesoins - 1pp

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

03 MTI820-Acetates-SpecificationDesBesoins - 1pp

Transféré par

Droits d'auteur :

Formats disponibles

MTI820 −

Entrepôts de données et intelligence d’affaires

Spécification des besoins d’affaires

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 1

Conception des Développement

Gestion de projet / programme

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 2

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 3

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 4

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 5

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 6

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 7

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 8

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 9

• Comment la spécification des besoins diffère-t-elle entre

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 10

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 11

• Description des processus d’affaires et

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 12

• Personnel des TI:

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 14

• Êtes-vous en mesure de réagir rapidement aux conditions changeantes du marché?

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 15

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 16

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 17

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 18

• Entrevue de conformité / sécurité:

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 19

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 20

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 21

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 22

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 23

• Décrit les dimensions d’analyse requises pour chaque processus d’affaires.

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 24

• Permet d’identifier les processus d’affaires faisables ayant le

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 25

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 26

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 27

• Ventes de produits dans quatre catégories: bicyclettes,

TotalSales Column Labels

Total ventes par année fiscale et catégorie de produit

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 28

Commandes par pays / région

TotalSales Column Labels

Commandes par canal de ventes

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 29

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 30

Roles and Responsibilities

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 31

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 32

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 33

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 34

Performance des ventes - Commandes par territoire courrant - commandes

- Revendeurs classés par le nombre commandes

Listes de prix - Liste des prix courants - commandes Problème de connectivité

- Clients pertinents par territoire, basé sur

Problème de connectivité au niveau

Les sondages sont un processus d'affaires, est

Touche à plusieurs processus d'affaires, incluant

Département de génie logiciel et des TI MTI820 Hiver 2011 – © S. Chafki, C. Desrosiers 35

Prévisions de production - Historique complet de commandes par produit - commandes

Réduction des coûts de fabrication - Coûts reliés aux achats - procuration

- Retours par produits par raison - rendements