Rapport Projet de Fin D'etudes Shabakkat

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels
voix
Rapport de Projet de Fin dEtudes
Shabakkat 2010/2011
Zakaria BOUATAYA, Anass CHIKI

voix
Mise en uvre doutils

dcisionnels pour le contrle de
la tarification des appels voix
Ralis par:
Zakaria
BOUATAYA
2010/2011
Shabakkat 2010/2011

voix
Shabakkat 2010/2011

voix
Table des matires

Rsum.................................................................................................................. 3
Abstract.................................................................................................................. 4
Introduction gnrale............................................................................................. 5
Droulement du stage............................................................................................ 7
Chapitre 1 : Revenu Assurance.............................................................................. 9

I.
Le monde du Revenu Assurance :.........................................................10

1. Dfinitions et diffrentes approches :..............................................10
2. Bnfice du Revenu Assurance :........................................................12
3. Pertes de revenu (Revenue Leakage)...............................................13
II.
Revenu Assurance et tlcommunications :...............................................15

1. Tendances du march des tlcommunications :...........................15
2. Les dfis du RA..................................................................................... 17
3. Concrtisation du RA dans notre projet :.........................................18
Conclusion :....................................................................................................... 18
Chapitre 2 : Les systmes de facturation ou Billing systems................................19

I.
Gnralits :............................................................................................. 20
1. Fonctionnalits..................................................................................... 21
2. Types de facturation :..........................................................................22
3. Tarification :.......................................................................................... 23
II. Mthodes de programmation pour la facturation :...........................28

1. Facturation base sur le code :..........................................................28
2. Facturation base sur les tables (Table-Based Rating) :...............29
3. Facturation base sur des rgles pr-stocks (Rule-Based
Rating) :....................................................................................................... 30
III.
Concrtisation :.................................................................................... 32
1. Pr-tude :............................................................................................ 32
2. Tables utilises :................................................................................... 34
Shabakkat 2010/2011

voix
3. Droulement de notre processus de facturation :..........................35
Conclusion :.................................................................................................... 38
Chapitre 3 : La Business Intelligence....................................................................39

I.
Introduction la Business Intelligence :.............................................40

1. Dfinition de la business Intelligence :...........................................40
2. Etapes du processus BI:......................................................................41
3. Conception de lentrept de donnes (Datawarehouse) :.............44
II. Cube OLAP et analyse multidimensionnelle :.....................................47

1. Vue densemble sur les concepts de base des cubes OLAP:.........47
2. Le modle de donnes des systmes OLAP:...................................49
3.
Construction du cube OLAP :.............................................................53
III.
Gnration des rapports multidimensionnelle :.............................60
1. Cration des mtadonnes OBIEE pour le cube OLAP :................60

2. Interrogation de donnes en utilisant Oracle BI Analytics :.........62
Conclusion :.................................................................................................... 67
Conclusion gnrale............................................................................................. 68
Table des figures :................................................................................................ 69
Shabakkat 2010/2011

voix
Rsum
De nos jours, les oprateurs de tlcommunications sont arrivs un
niveau o la concurrence est son paroxysme, et chaque oprateur essaie
de varier et diversifier ses offres afin daugmenter le nombre de ses
clients. De ce fait, les oprateurs se doivent davoir des plateformes de
tarification la fois robustes et flexibles afin de pouvoir tarifier
correctement leurs clients.
Mais la complexit des offres et le nombre important des clients
deviennent de plus en plus difficiles grer, ce qui induit ce quon
appelle pertes de revenus ou revenue leakage , et pour remdier
ce fait, la notion de Revenu Assurance a vu le jour dans le monde des
tlcommunications, consistant sassurer que les crances dcoulant de
la vente des produits et services sont correctement perues.
Cest dans ce contexte que sinscrit notre Projet de Fin dEtude, qui
avait pour vocation la dtection des erreurs de tarification sur les appels
voix.
Shabakkat 2010/2011

voix
Shabakkat 2010/2011

voix
Introduction gnrale
Le domaine des tlcommunications est le premier mtier au
niveau duquel sest dvelopp le revenue assurance. Mais ce systme de
pilotage
des
s'implanter
revenus,
dans
les
indpendant
branches
du
type
d'activit
d'organisation,
pratiquant
des
pourrait
changes
internationaux, souvent associs des services complexes.

Dans le secteur des tlcommunications, les offres alliant tlphonie
fixe et mobile, internet et tlvision, et la multiplication des oprateurs ont
complexifi les processus, les interconnexions des rseaux et les interfaces
entre les systmes d'information. Et les questions commerciales et juridiques
accroissent encore les difficults techniques et fonctionnelles. Les pertes de
revenus y atteignent parfois 10 % du chiffre d'affaires! La mondialisation des
communications entrane, en effet, l'intervention dun nombre important de
nouvelles structures d'accueil, de transmission, de transit international,
d'change et de vente en gros. Autant de sources d'erreurs, de divergences
entre bases de donnes et de problmes en tout genre pour affecter
correctement tous les flux.
A tous ces problmes il faut ajouter les montages financiers entre
oprateurs (fusions, absorptions), dont il faut suivre l'volution au niveau des
systmes
d'information.
Dans
cet
environnement
technico-commercial
mouvant et difficile matriser, surviennent de plus en plus de fraudes.

Selon la GSM Association, les pertes de revenus dues ce flau se chiffrent
chaque anne entre 35 et 45 milliards de dollars. Mais en croire les tudes
des grands cabinets d'audit, la part des fraudes ne reprsente que 18 % de
ces pertes. Les erreurs dans les enregistrements des communications
expliquent 46 % de ces pertes, 15 % proviennent des impays, 11 %
d'informations incompltes sur les clients, et 10 % d'un tarif inadquat. La
marge d'amlioration de la situation financire de ces entreprises est donc
considrable.
Pour dtecter les fuites de revenu, il convient d'instaurer des contrles
sur les processus traverss par la chane de revenus, et sur les systmes
Shabakkat 2010/2011

voix
d'information soutenant ces processus. Puis y remdier avec des solutions

prennes. C'est l qu'entre en scne le concept de Revenu Assurance.
Concrtement, il s'agit de s'assurer que toutes les crances
dcoulant de la vente de produits et services sont correctement
perues. Cela implique la dtection des fuites tout au long de la chane des
revenus, leur valuation comptable, le recouvrement des sommes
et
surtout, la mise en uvre d'actions palliatives et correctives vitant leur

rptition.
Et cest dans ce cadre que sinscrit notre projet de fin dtude,
pour le compte dun client de Shabakkat Maroc, nous devions raliser un
systme pour pouvoir dtecter les pertes de revenu sur les appels voix, en
comparant les tarifs rellement appliqus sur lIN (Intelligent Network) et
les tarifs thoriques des appels. Pour cela nous tions amens, dans un
premier temps, crer un moteur de tarification pour pouvoir calculer le
cot thorique dun appel, cette tape termine nous avons eu recours
la Business Intelligence pour
pouvoir traiter le nombre important de
donnes, avoir une vue globale et pouvoir dtecter l o il y a le plus de

pertes de revenu.
Ce rapport de Projet de Fin dEtude dtaillera le travail men durant
le stage pour atteindre les objectifs fixs :
Le premier chapitre aura pour vocation de donner une vue
globale sur le Revenu Assurance, son importance et ses
bnfices pour les oprateurs tlcoms.
Le deuxime chapitre fera claircira les diffrentes facettes de
la tarification et sur le comment de la ralisation de notre
propre moteur de tarification.
Le troisime et dernier chapitre
introduira
la
Business
Intelligence, ensuite expliquera les tapes de sa concrtisation

dans le cadre de notre projet.
Shabakkat 2010/2011

voix
Droulement du stage
Notre stage de fin dtudes sest droul au sein de Shabakkat
Maroc qui est une socit de services, filiale du groupe international
Shabakkat implante dans prs de quinze pays dans le monde.
Figure 1-1: Prsence de Shabakkat dans le monde

Shabakkat Maroc est une entreprise unipersonnelle responsabilit
limite (EURL), implante au Maroc depuis plus dune anne. Elle compte
une quinzaine demploys et adopte une structure fonctionnelle comme
lillustre la figure 1.2.
Figure 1-2 : Structure de lorganisation de Shabakkat
Shabakkat 2010/2011
10

voix
Les diffrents services proposs par Shabakkat sont :

OperatorAsset
Contribution
(O.A.C):
ce
service
regroupe
lensemble des mtiers relatifs au gnie civil, soit linfrastructure rseau.

System Delivery Service (S.D.S): ce systme de prestation de
services concerne les activits dinstallation de systme de bout en bout.
DeliveryOperation (D.O): cette unit se charge du service des
prestations des oprations.
End User Service Engineering (E.S.E): il sagit de lingnierie de
service pour lutilisateur final qui couvre tout ce qui est maintenance.
Operation support System (O.S.S): ce service couvre tout ce qui
est optimisation radio, rseau et IP.
Parmi les clients de Shabakkat, nous comptons diffrents oprateurs
tlcom en plus des entreprises qui travaillent sur la partie IP. Comme
perspective de croissance, Shabakkat Maroc compte conqurir ses clients
potentiels : les oprateurs tlcom du Maroc et ceux de lAfrique de
lOuest.
Dans le cadre dun grand projet, pour le compte de lun des clients
de Shabakkat, nous avions pour mission de raliser un systme pour faire
le contrle de la tarification afin de faire du Revenu Assurance sur les
appels voix, pour ce faire, nous avons tout dabord cr un moteur de
tarification se basant sur des donnes de rfrence nous permettant de
calculer le cot thorique de lappel, ensuite , vu la grande volumtrie des
donnes ,nous avons eu recours linformatique dcisionnelle et voici le
diagramme de GANTT montrant les tapes par lesquelles nous sommes
passes pour arriver notre objectif :
Shabakkat 2010/2011
11

voix
Figure 1-3 : Diagramme de GANTT illustrant les tapes de notre projet
Chapitre 1
Revenu Assurance
Introduction
Shabakkat 2010/2011
12

voix
Ce premier chapitre nous permettra dapprhender le monde du

Revenu Assurance, pour ce faire, une premire partie aura pour vocation
de dfinir le Revenu Assurance en se basant sur un cadre thorique.
Durant la deuxime Partie, nous allons dcortiquer la relation troite
qui lie le RA aux tlcommunications et la concrtisation de notre
approche RA pour les appels voix.
I.
Le monde du Revenu Assurance :

1. Dfinitions et diffrentes approches :
Le Revenu Assurance ou Assurance des Revenus (en abrviation RA),
peut avoir plusieurs dfinitions, mais toutes peuvent se rejoindre dans le

fait que ce concept consiste en lexploitation des donnes et des
mthodes damlioration de processus pour augmenter les profits, revenus
et cash flow sans influencer les clients.(ref 14)
En dautres mots le Revenu Assurance est la combinaison dune
structure organisationnelle, de processus et de systmes informatiques
permettant de comprendre et de superviser lintgralit du processus
revenu : la gestion des offres, la gestion commerciale, la gestion des
ventes, la valorisation des consommations et de la facturation et le
recouvrement et la gestion de la fraude, appel aussi fraude management,
ceci dans le but de minimiser les pertes de revenu (ou Revenue Leakage)
que nous allons expliquer aprs. (ref
Dautres dfinitions rsument laction du Revenu Assurance en trois
points : (ref 7)
Shabakkat 2010/2011
13

voix
Oprations daudit.
Crations de mcanismes de dtection.
correction efficace des problmes.
Ceci dans la perspective daugmenter le profit en optimisant les

oprations, en dtectant les pertes de revenus, ou encore en retenant les
clients profitables.
Et pour pouvoir concrtiser ce concept il faut
sassurer de la
ralisation des trois actions suivantes :

1. Sassurer que les risques lis au revenu sont identifis et couverts
tout au long de la chaine de revenu.
2. Accompagner les activits oprationnelles par le dveloppement
de processus et de contrle tout en surveillant limpact potentiel sur les
autres processus.
3. Assurer une supervision globale afin de garantir que la
performance des processus est mesure et communique avec prcision.
Mais ces actions ne peuvent tre mises en uvre en un seul coup,
un systme de Revenu Assurance passe par des tapes de maturits
comme le montre la figure suivante :
Figure 1 : les niveaux de maturit du revenue assurance (ref )

Dans un premier lieu, le Revenu Assurance ntait pas une notion
concrte, on faisait du revenu assurance sans savoir, il tait IMPROVISE :
lorsque lon remarque quil y a des pertes de revenu, on essaie de deviner
Shabakkat 2010/2011
14

voix
les problmes qui auraient pu causer ces pertes, et il est clair que cette
pratique ne donnait pas toujours des rsultats concrets.
Le processus du Revenu Assurance peut tre ITERATIF c'est--dire
reposant sur les individus: chacun essaie dtablir des processus quil croit
tre capables de dtecter les sources de fuites de revenu, et prendre les
mesures ncessaires pour corriger ces erreurs. Dans cette phase le
Revenu Assurance ne fait pas partie de lorganisation de lentreprise,
chaque individu essaie avec sa propre manire dliminer les fuites de
revenu.
Lorsque cette pratique fait partie de lorganisation de lentreprise on
dit quelle est dans ltape DEFINIT, dans cette tape les processus de
Revenu Assurance sont dfinis et de mme pour des processus qualit qui
aident aussi connaitre les sources de fuites.
Quand lentreprise arrive un niveau o les performances de son
systme de Revenu Assurance sont mesures, les erreurs sont dtectes
lavance et les responsabilits sont dcentralises, on dit que le systme
est GERE, dans ce niveau de maturit les performances du systme sont
mesures grce des KPI tablis et des tableaux de bord. Des audits
internes sont effectus rgulirement pour sarrter sur les diffrents
problmes.
Arriv la maturit, OPTIMISE, le systme de Revenu Assurance est
efficace et implmente des processus et mthodes avancs pour dtecter
la plupart des problmes induisant des pertes de revenu.
2. Bnfice du Revenu Assurance :

La mise en place dun processus de contrle efficient de Revenu
Assurance, est dun grand bnfice pour tout entreprise, en effet, les
entreprises ayant mis en place ce genre de processus constatent un
impact immdiat sur leur profitabilit se chiffrant dans certains cas par
une croissance de 10% ; dans la suite nous trouvons les majeurs bnfices
de lapplication du RA dans une structure, en loccurrence les oprateurs :
Une meilleure gestion des risques :
Au-del des gains immdiats, les oprateurs ont besoin, de manire
continue, dune structure didentification des risques lis au revenu.
Shabakkat 2010/2011
15

voix
Le
Revenue
Assurance
doit
tre
intgr
aux
stratgies
de
dveloppement des produits, aux activits et oprations marketing ainsi

qu la facturation et au service client.
Rduire le taux de dsabonnement :
Le Revenu Assurance contribue la surveillance des causes
d'insatisfaction des clients et de les contrler de faon mthodique et trs
efficace afin de les fidliser, non seulement
pour prenniser le revenu
mais aussi pour permettre de cibler une clientle plus large.

Une augmentation rapide des revenus :
Chez un nombre important doprateurs, la perte de revenus est un
fait tabli. En identifiant les pertes et en mettant rapidement en place des
processus de contrle des carts, le Revenu Assurance peut avoir un
impact immdiat sur les revenus et, dans certains cas, rduire les cots
des oprateurs et augmenter leur profitabilit.
3. Pertes de revenu (Revenue Leakage)

Dans le droulement des oprations tlcoms, tant que le systme
et les processus de facturation sont stables, il ny a pas de quoi sinquiter
puisque tout ce qui est vendu est en principe bien factur, mais la
facturation
consiste
en
une
chane
complexe
de
procdures
interdpendantes uvrant pour tarifier les clients comme ils se doivent.

Et la taille de ces processus uvrant pour grer la tarification
augmente en longueur et en complexit avec le temps. Ainsi, le taux
derreurs causant la fuite de revenu augmente sur cette chane.
Et on parle de Revenue Leakage ou fuite de revenu si :
Un service na pas t factur correctement, ou pas du tout factur

mme sil tait dlivr.
Shabakkat 2010/2011
16

voix
Il y a eu un problme dans la collecte de revenus censs tre

gnrs par ce service.
Parfois, les oprateurs dlivrent un certain niveau de service mais

natteignent pas le niveau de revenus quivalent. Lexemple ci-dessous
nous donne une ide sur ce phnomne de fuite de revenu :
Appel
10000
minute
d'appel
Facturati
on
10000 minute* 3
dh= 30000 dh
Payemen
t
25000
DH
Donc on a une perte de revenu de 5 000 Dh

Figure 2 : Figure illustrant la notion de perte de revenu
Les 10 000 minutes vendues nont t factures que de 25000 Dhs

alors quelles devaient en principe gnrer un revenu de 30000 Dhs. Les
5000 Dhs manquants constituent le revenu perdu mentionn plus haut.
Dtecter les fuites de revenu est une tche des plus difficiles,
demandant la fois beaucoup de temps, de patience et un budget solide.
Les sources de fuites de revenu ont constitu lobjet de plusieurs
enqutes, dont les principales conclusions montrent que les ratios
diffrent dun oprateur lautre. Cependant, la majorit des fuites se
rapportent gnralement un certain nombre de problmes rpartis
comme suit :
Shabakkat 2010/2011
17

voix
Accumulation d'erreurs sur le CDR
Facturation incorrecte
Informations incompltes sur le client
Pertes dues aux fraudes
Daprs : RA Hand Book (ref

4)
Figure 3 : Diffrentes causes de perte du revenu
Dfaillances au niveau des informations clients

Des erreurs dans le traitement des CDRs (Call Data Records)
Des problmes de Fraudes
Mauvaises pratiques de tarification (application des plans tarifaires
aux units de trafique consommes)
Dautres enqutes, notamment celles menes par Phillips Group

indiquent que les pertes peuvent tre attribues :
II.
Lchec de cration des CDRs (au niveau du Switch)

Des CDRs endommags
Des CDRs perdus
Des CDRs en retard pour la Mdiation.
Des CDRs en retard pour le Billing
Une fraude
Un Rating erron
Des Informations clients errons
Des Factures impayes, des problmes de crances.
Revenu Assurance et tlcommunications :
1. Tendances du march des tlcommunications :
Dvelopper la convergence et les nouvelles chanes de valeur :
Shabakkat 2010/2011
18

voix
Les volutions technologiques et la mutation des oprateurs vers

des entreprises de communication et de divertissement entranent une
volution de la chane de valeur, de la simple vente de minutes vers la
vente de services valeur ajoute (contenus, offres multiplay, VoIP)
Figure 4 : les motivations la convergence chez les

oprateurs (ref )
Maintenir une stratgie dinvestissement

tout en matrisant les cots :
offensive
Face une concurrence accrue, les oprateurs doivent plus que jamais
assurer une politique dinnovation constante. Paralllement, la pression
sur les prix, rsultant de cette concurrence, limite les capacits financires
des oprateurs qui peuvent vouloir se tourner vers des stratgies
dinvestissement au travers de partenariats avec des quipementiers, des
diteurs de contenus ou des acteurs du secteur des mdias.
Maintenir la base clients sans sacrifier la marge :
Des services et des offres multiples et complexes, allis des politiques de

fidlisation agressives et des stratgies de diversification des canaux de
distribution (internet, partenariat avec la grande distribution, les banques,
la sant, lautomobile...), doivent permettre aux oprateurs de
sauvegarder leur base clients tout en augmentant leur marge.
Sadapter aux volutions rglementaires :
Confronts un march en volution permanente, les oprateurs sont

soumis aux volutions de la rglementation: licences 3G/4G, attribution de
Shabakkat 2010/2011
19

voix
nouvelles frquences, prix des terminaisons dappel, fibre optique et

doivent adapter leurs processus et leurs systmes pour sy conformer.
Figure 5 : Les enjeux du march des

tlcommunications (ref )
2. Les dfis du RA
Le
grand
souci
des
oprateurs
de
tlcommunications
est
dassurer leurs revenus ce qui explique la volont de redonner une nergie

nouvelle la fonction du Revenu Assurance. Il existe de nombreux
facteurs qui reprsentent un dfi au RA pour quil puisse montrer son
impact et ses bnfices
Dveloppement technologique :
Le dveloppement technologique est son apoge. Des centaines

de technologies nouvelles, de nouveaux services et plans tarifaires voient
le jour rgulirement. Le rseau et les systmes de gestion doivent
remodeler et adapter en permanence leurs fonctionnalits de gestion des
revenus.
Laugmentation
du
taux
dinnovation
implique
ainsi
une
augmentation du taux derreurs des systmes dassurance de revenus

classiques, et ncessite une amlioration efficace de ces systmes.
Shabakkat 2010/2011
20

voix
La convergence :
Il sagit de la convergence des deux environnements rseau et

systmes de gestion des revenus (Billing). La migration graduelle vers un
tel environnement augmente la pression sur les systmes pour travailler
un maximum de capacit et de flexibilit, ce qui induit forcment plus
derreurs dans la chane des revenus.
Un march concurrentiel :
Un mauvais traitement des informations peut induire un manque de

10% du revenu total. Une perte aussi grande nest pas tolre dans un
march concurrentiel tel que le march des tlcommunications.
Les fusions-absorptions :
De nos jours, on voit de plus en plus de fusion et dachat

doprateurs de tlcommunications par d'autres ce qui implique que
plusieurs systmes de facturation sont forcs travailler en commun ce
qui conduit ce que les erreurs inhrentes aux processus de gestion des
revenus deviennent de plus en plus frquentes.
3. Concrtisation du RA dans notre projet :

Notre projet de fin dtude avait pour vocation de crer un module
de Revenu Assurance pour les appels voix dun oprateur en se basant
sur un moteur de tarification entirement dvelopp par notre quipe et
un outil daide la dcision bas sur la solution daide la dcision Oracle
OBIEE.
Partie tarification :
La premire phase du projet consistait modliser et implmenter

un moteur de tarification en se basant sur les informations fournies par les
oprateurs et base des informations recueillies partir des CDRs (Call
Detail Record quon va expliquer dans le chapitre suivant). Pour ce faire,
les CDRs sont recueillis sur une base de donnes Oracle 11g et traits par
Shabakkat 2010/2011
21

voix
notre moteur de tarification (qui sera dtaill plus loin) afin de gnrer un
tarif et une dure de tarification thoriques qui seront utiliss par la suite
comme jauge de lexactitude des calculs effectus par lIN ce qui nous
permettra de dtecter les erreurs de tarification .
Partie Dcisionnelle :
Vu le volume important de donnes traiter, tirer de linformation

pertinente qui aide la dcision savre une tche dlicate, pour ce faire,
nous avons cr une plateforme daide la dcision et un cube OLAP qui
nous permettra danalyser la fois une taille importante de donnes
traites et de non seulement dtecter les erreurs mais aussi leurs sources
(par IN, par rgion) avec une aisance et une facilit qui ne ncessite
pas de bagage technique, ce qui permettra aux managers de dtecter les
erreurs de tarification sur leurs systmes et en remdier pour ainsi faire du
Revenu Assurance.
Conclusion :
Ce chapitre nous a permis davoir une vue globale du Revenu
Assurance, ses bnfices ainsi que les facteurs ayant favoris son
mergence.
Dans la suite on verra comment nous avons concrtis la partie
consistant dtecter les fuites du revenu dans notre projet en comparant
les tarifs thoriques, calculs laide dun moteur de tarification dont les
tapes de dveloppement sont dtaills dans la deuxime partie, aux
tarifs pratiques facturs au niveau de la plateforme de tarification quon
rcupre partir du Datawarehouse.
Shabakkat 2010/2011
22

voix
Chapitre 2
Les systmes de facturation ou Billing systems.
Introduction
Vu que la question de tarification est une partie consistante de notre
projet, il est dune importance primordiale dintroduire ces systmes qui
ne cessent dvoluer au fil du temps et qui doivent tre aussi puissants
que flexibles.
Et donc pour pouvoir nous familiariser avec ce jargon, nous allons
dabord introduire de faon gnrique le monde de la facturation, puis
expliquer les diffrentes mthodes de programmation possibles pour un
moteur de tarification avant dentamer sa concrtisation dans le cadre de
notre projet.
I.
Gnralits :
Lenvoi de la voix, donnes, images et fax dun point un autre en

utilisant des moyens lectroniques est appel tlcommunications,
Shabakkat 2010/2011
23

voix
tlcoms en abrg. Les exemples comprennent tlphone, radio,

tlvision et Internet, les moyens de transmission comprennent le cble
(cuivre), Fibre Optique, Ether (sans fil), des pylnes radio, micro-ondes,
Satellite.
Les oprateurs de tlcoms offrent une trs grande varit de services
leurs clients dont on pourrait citer pour exemple :
Les appels voix.

Fax.
Connexion internet.
Confrences vido.
Voix sur IP.
Et la liste reste longue

Les oprateurs de tlcommunication facturent leurs clients pour ces
services de plusieurs manires, mais il y a deux paramtres utiliss
principalement pour exiger d'un client:
Frais de location: ce sont les charges exiges dun client tous

les mois pour un service fournit, par exemple une charge de
150 Dh que lon paye pour le service internet peu importe
quon lutilise ou pas.
Frais d'utilisation: Ce sont les charges exiges dun client

bases sur l'utilisation des services. Par exemple, on est factur
pour tous les appels faits ou les donnes tlcharges l'aide
de son tlphone.
Dabord, il est ncessaire de dfinir deux des termes les plus utiliss
dans le jargon de la tarification, savoir : un produit, et un service.
Un produit : Un produit est une entit logique ou physique qui peut
tre vendue un client par les oprateurs, Cela pourrait tre un tlphone
portable, une connexion Internet, la Vido la demande etc.
Un produit peut avoir sa propre charge dexploitation quon appelle
charge priodique, aussi, un produit peut gnrer un revenu sur utilisation
ou pas, par exemple : chaque fois que lon fait un appel voix, on est
factur pour la dure dappel, donc pour chaque utilisation on paye un
montant donn, alors que pour une connexion internet on est amen
Shabakkat 2010/2011
24

voix
payer un montant mensuel mme sans avoir utilis cette connexion, ces
deux cas expliquent les deux notions de frais de location ,et frais
d'utilisation vues plus haut.
Un service : gnralement un oprateur utilise ses produits pour

fournir des services ses clients. Par exemple un appel international peu
tre considr comme un service fournit laide dune connexion voix, le
renvoi dappel peu aussi tre considr comme un service.
Si on parle des ces deux notions, produit et service, dun point de
vue marketing il ny a pratiquement pas de diffrence vu que les experts
marketing utilisent ces deux mots de faon interchangeable, et de mme
dans la suite de ce document, nous nallons pas diffrencier ces deux
notions puisque, dun point de vu tarification, ils peuvent tre considr
comme une entit gnrant du revenu.
Devant la complexit et la multitude des services, les entreprises de
tlcommunications ont
besoin d'un systme de facturation
prcis et
efficace pour tre en mesure d'assurer leurs revenus. Le processus de

facturation consiste recevoir les dossiers de facturation des diffrents
rseaux, la dtermination du taux de facturation associs chaque
dossier, le calcul du cot pour chaque enregistrement de facturation,
d'agrger ces dossiers rgulirement pour produire des factures, l'envoi
des factures aux clients et la collecte des paiements reus par la clientle.
Les comptes de facturation sont souvent considrs comme des
comptes dbiteurs que le systme de facturation aide collecter. Les
comptes de facturation font galement partie des comptes payer (pour
les tablissements inter-transporteurs) parce que les clients utilisent
souvent
les
services
d'autres
socits
telles
que
l'itinrance
et
l'achvement d'appel par le biais d'autres rseaux (Roaming).

1. Fonctionnalits
Les systmes de facturation sont des logiciels haut de gamme,
fiables et expansifs, ils fournissent des fonctionnalits diverses. Voici une
liste non exhaustive des diffrentes fonctionnalits de ces systmes :
Shabakkat 2010/2011
25

voix
Facturation: Cela implique de facturer lutilisation

services et la production mensuelle de factures.
Traitement des paiements: Il s'agit denregistrer les paiements des

clients dans leur comptes respectifs.
Contrle du crdit et des collections: Cela implique la poursuite des

impays et de la prise d'actions appropries pour obtenir les
paiements.
Les diffrends et les ajustements: Il s'agit de l'enregistrement de tout

litige client contre sa facture et les ajustements pour rembourser le
montant en litige afin de rgler les diffrends.
Service prpays et post-pays : Il s'agit de soutenir la fois la base de

clients prpays et post-pays.
Multilingues et de multiples devises: multilingue et support de plusieurs

monnaies est ncessaire si l'entreprise est rpartie sur plusieurs
pays et ayant des clients multinationaux.
Produits et services: Il s'agit de fournir une manire flexible de

maintenir divers produits et services, et de les vendre
individuellement ou en paquets.
Promotions: Cela consiste dfinir des formules de rductions

diffrentes, afin de rduire le cot pour attirer et accrotre la base
clients.
des produits ou
2. Types de facturation :
Il existe diffrents types de facturation, dont on pourrait citer (ref 16):
Prpay (Pre-payBilling) : Un mcanisme de facturation o le client paie

l'avance (avant de commencer utiliser le service).
Habituellement, les clients prpays ne reoivent pas de facture et
ils sont chargs en temps rel par lIN(les rseaux intelligents).
Post-pay (Post-payBilling) : Il s'agit de la facturation classique qui date

de plusieurs annes. Ici les clients achtent les produits et services
et les utilisent tout au long du mois, et en fin de mois les factures
sont gnres par le service, et envoys aux clients pour faire leurs
paiements dus.
Shabakkat 2010/2011
26

voix
Roaming : Quand un client passe de la zone de couverture d'un

oprateur la zone de couverture d'un autre oprateur, le premier
oprateur paierait les frais marginaux au second oprateur qui
fournit des services son client. Ce type de taxes est liquid par les
dplacements dans la facturation. Ce rglement est effectu selon le
protocole TAP3.
Convergent Billing: est l'intgration de tous les frais de service sur une
facture client unique.
3. Tarification :
Le
dpartement
marketing
dans
un
oprateur
de
tlcommunications travaille dur pour dfinir les frais de location et

d'utilisation des diffrents produits et services. Ces charges sont dfinies
conformment aux autres
concurrents
et rglementations
Il pourrait y avoir diffrents types de charges appliquer pour un produit

et services associs.
Pour un produit donn, un oprateur peut dfinir une ou plusieurs
des charges suivantes en plus dautres ventuels types de charges selon
le pays, l'emplacement et le contexte dutilisation :
Frais dinitiation: Ce sont des charges non-rcurrentes qui peuvent

tre prises par le client dans le cadre de l'installation et d'activation
des services.
Frais priodiques: Ce sont les charges qui peuvent tre appliques sur
une base mensuelle ou bimensuelle pour la location d'un produit et
du service fourni.
Frais de rsiliation du produit: Ce sont les charges qui peuvent tre

appliques en cas de cessation du produit et de service.
Charges de Suspension de Produit : Ceux-ci sont les charges qui peuvent

tre appliques si un produit est suspendu cause d'une certaine
raison, par exemple le non-paiement.
Charges de Ractivation de Produit : quand un produit a t suspendu

pour une certaine raison et quil doit dsormais tre activ, un
oprateur peut appliquer des charges de ractivation pour ce service
Shabakkat 2010/2011
27

voix
Frais d'utilisation du produit: Ceci est le plus important type de charge

et qui est applique sur la base de l'utilisation du service. Pour
appeler par exemple par minute, ou par seconde, tlcharger des
donnes par MB etc
Et pour tarifier un client plusieurs paramtres peuvent tre pris en

compte :
Lheure de lappel : gnralement les oprateurs divise la journe en

deux tranches, une tranche gnralement appel ONPEAK
correspondant aux heures de pointes qui sont tarifi plus cher, et
une tranche appel OFFPEAK qui est le reste de la journe.
Destination : Si on appelle un client du mme rseau, ce qui est

gnralement nomm un appel On-net, ce client est tarifi moins
cher que sil appelait un client Off-net.
Journe de lappel : Les appels pendant les Week-end et jours fris

sont facturs moins cher.
Numro spciaux : Lappel vers des numros spciaux pour tre gratuit
ou factur par un montant spcial.
Les systmes de facturation offrent une grande souplesse afin de

dfinir diffrentes rgles pour facturer la voix, les donnes et tout autre
service quun oprateur peut offrir.
Capture dvnements et CDR (Descripteurs dtaill dappel):
Un client commence utiliser le rseau aussitt qu'il commence
utiliser les produits et les services vendus par l'oprateur. Un lment de
rseau est une combinaison de logiciel et matriel et il est responsable du
contrle complet du service et des vnements de mesure pour n'importe
quel type de ce dernier.
Un vnement est une occurrence unique facturable de l'utilisation
dun produit ou dun service, gnralement capture lectroniquement par
un rseau. Par exemple, quand un utilisateur de tlphone mobile fait un
appel
tlphonique,
un
vnement
est
gnr
qui
contient
des
informations sur cet appel, comme la dure de l'appel, l'heure de la

journe , le numro qui a t appel etc
Un vnement avec tous ses attributs est appel descripteur dtaill
dappel (ou CDR Call Detail Record) un collecteur de donnes dans le
Shabakkat 2010/2011
28

voix
commutateur de rseau capte l'utilisation sous forme de Call Detail Record

(CDR). Ces CDRs sont leur tour convertis par le systme de mdiation
dans un format comprhensible par le moteur de facturation.
Il pourrait y avoir diffrents lments du rseau pour faire le contrle
des services
et de produire par la suite diffrents types de CDRs, par
exemple, pour la tlphonie GSM:
Les appels vocaux sont capturs par le MSC (Mobile Switching

Centre)
Le trafic SMS est captur par le SMSC.
Le trafic de donnes est captur par le GGSN
Le trafic MMS est captur par le MMSC
CDRs Roaming sont capturs par l'itinrance lment de
commutation partenaire.
Le diagramme suivant montre les lments du rseau qui capturent

les donnes d'utilisation puis l'envoi des CDRs ou UDRs (Usage Detail
Record) vers le systme de mdiation et enfin le systme de facturation:
Figure 6 : Diagramme illustrant les captures de donnes et traitements

des CDRs
Les attributs dun CDR :
Comme mentionn ci-dessus, un CDR conserve les informations sur
l'appel ainsi que dautres informations utiles. Voici les caractristiques les
plus importantes d'un CDR:
Lappelant (le numro A).

Lappel (le numro B)
Dbut de l'appel (date et heure).
La dure (dure).
Type d'appel (voix, SMS, donnes)
Shabakkat 2010/2011
29

voix
Un numro de squence d'identification (ID)
En outre, un CDR peut galement enregistrer d'autres informations telles

que:
L'identificateur de l'change tlphonique.

Le rsultat de l'appel (si elle a rpondu ou occup).
Cause de coupure dappel.
Options utiliss lors de lappel comme le renvoi dappel.
Le Traitement des CDR :
Le systme de mdiation recueille les CDRs des diffrents lments
du rseau dans des formats diffrents. Quelques
lments du rseau
gnrent les CDRs au format ASN.1 et dautres lments peuvent avoir

leur propre format propritaire.
Le systme de mdiation traite tous les CDRs et les convertit en un
format compatible avec le systme en aval qui est habituellement un
systme de facturation.
Une fois que les CDRs collectes sont traites, le systme de
mdiation pousse tous les CDRs au systme de facturation via FTP parce
que
gnralement
les
systmes
de
mdiation
et
de
facturation
fonctionnent sur des machines diffrentes.

Processus de facturation :
Le tarif est la charge ou le prix de la survenance d'un vnement.
Le taux est la charge pour la dure de l'appel tlphonique par exemple:
3,6 Dhs INR par tranche de 1 minute ou une quantit spcifique, par
exemple: 10,00 Dhs 1 Mo de tlchargement ou il peut tre charg par
rapport la qualit du service.
Nous avons dj expliqu quun vnement est une occurrence
unique d'utilisation dun produit ou un service et que les vnements sont
capturs par les lments du rseau sous la forme de CDR transmis au
systme de facturation pour la facturation.
La facturation (ou Rating en Anglais) est le processus de
dtermination de la charge ou prix des utilisations individuelles. Par
exemple, le prix pour 2 minutes d'appels est de 7.2 Dhs avec un taux de
3.6 Dhs par minute.
Shabakkat 2010/2011
30

voix
Le moteur de tarification (Rating Engine) qui fait partie du systme de

facturation (Billing system) est lentit responsable de la facturation.
Le moteur de tarification reoit les donnes sous forme de descripteur
dtaill dappel CDRs ( Call Detail Records) ou UDR (Usage Detail Records)
qui donnent, comme expliqu auparavant, une description dtaille dun
vnement
un CDR est une chane de donnes qui contient des
informations d'appel tels que la date et l'heure d'appel, dure d'appel, la

partie
appelante,
l'appel
qui
sont
utiliss
pour
facturer
les
vnements.
Les tapes dun processus de facturation sont comme suit :
Accepter les CDRs partir du systme de mdiation ou d'autres

prestataires ou partenaires de Roaming dans le cas du Roaming.
Validation des CDRs et liminer les doublons. Ces vnements en

double sont stocks dans une table de base de donnes pour
vrification ultrieure.
Pour dterminer le compte du client qui doit tre factur pour

l'vnement. Une fonction ramasse la source d'vnement (numro
de mobile ou l'adresse IP, etc) et vrifie la base de donnes pour
vrifier si cette source d'vnements est associe un compte. Cette
fonction est appele en Anglais Event Guidance.
Si l'vnement ne peut tre guid, alors cet vnement sera rejet et

ne peut tre mis dans la catgorie suspense. Ces vnements sont
stocks dans une table de base de donnes pour vrification
ultrieure.
Calculer le prix de l'vnement, selon le plan de tarification (appele

dans notre base de donnes RATE PLAN).
Enregistrer l'vnement not dans la base de donnes pour des fins

de facturation ou l'envoyer vers le systme externe de la facturation.
Et voici ci-aprs un diagramme qui illustre ce processus standard de
facturation qui peut, bien sur, changer dpendant des besoins des
oprateurs :
Shabakkat 2010/2011
31

voix
Figure 7 : le processus standard de la facturation (rf 16)
II.
Mthodes de programmation pour la facturation :
Lors de notre documentation autour des mthodes possibles pour

raliser un moteur de tarification, nous avons fait ltude comparative de
trois mthodes: (rf 21)
Facturation base sur le code (Program code based rating) : ici

toutes les informations ncessaires la tarification sont incorpores
dans le code.
Shabakkat 2010/2011
32

voix
Facturation base sur les tables (Table-driven Rating) : dans cette

mthode la logique de la facturation est stocke dans diffrentes tables
qui contiennent les diffrents cas possibles ainsi que les prix.
Facturation base sur des rgles pr-stockes ( Rule-based Rating

) : Le processus de facturation des transactions o les informations sur
la faon de calculer la charge sont stockes comme des rgles qui sont
traites par le code de facturation.
1. Facturation base sur le code :
La facturation base sur le code (Program code based rating) : est la
mthode utilise pour les premiers logiciels de facturation qui ont t mis
en uvre. Il ya des entreprises qui utilisent toujours ce type de logiciel
depuis plus de 20 ans ; il faut savoir que ce type de facturation est rapide
pour la production car il na pas besoin dun grand flux d'E / S et le code
est compil plutt quinterprt. Voici par exemple un tronon de code
crit en COBOL qui illustre les aspects cits prcdemment :
IF RATE-PLAN EQUALS "MEGABYTE CHARGING"

THEN MULTIPLY MEGABYTES-TRANSFERRED BY 0.023 GIVING CHARGEAMOUNT
Le problme dans ce type de programmation est quil est totalement

correspondant au style du programmeur, ne permettant pas davoir un
code standard, lisible et comprhensif par tous.
Mais la ralit du dveloppement logiciel consiste en ce que de
nouveaux programmeurs reprennent souvent le dveloppement et la
maintenance des programmeurs originaux, et donc ils trouvent, souvent,
beaucoup de problmes comprendre et maintenir le code, et vu que,
dans le monde des tlcommunications, la diversit et les nouvelles offres
narrtent
pas
programmeurs
de
sont
se
multiplier
toujours
sous
jour
aprs
pression
jour,
afin
les
de
nouveaux
raliser
les
modifications demandes dans les plus brefs dlais et ceci induit ce

quils ajoutent des morceaux de code incohrents avec le code initial.
Shabakkat 2010/2011
33

voix
Ce problme est vrai pour toutes les parties dun traitement de

donnes, mais le cot de la mauvaise comprhension dans la facturation
est norme par comparaison d'autres parties de n'importe quel
programme. Ce code traite des millions de transactions d'argent, et les
erreurs, bien quelles soient minimes, se transforment en des sommes
significatives quand multiplies par des millions.
Et donc pour rsumer, cette mthode de programmation, base
totalement sur le code, aide optimiser les ressources matrielles puisque
son code est compil, mais ce code mme peut devenir trs incohrent et
lourd si plusieurs programmeurs prennent le relais sur le projet cause de
la mauvaise comprhension du code initial.
2. Facturation base sur les tables (Table-Based Rating) :

Durant les 20 dernires annes, plusieurs oprateurs ont vu quil
tait plus facile de faire face la complexit que prsente la facturation en
encodant leurs algorithmes dans des tables.
Cest une mthode o lon utilise plusieurs tables de donnes qui
contiennent les diffrents les montants utiliser pour chaque cas de
facturation possible.
Le code du programme existe toujours, mais sa signification
fonctionnelle est plus clairement dfinie et il est plus facile comprendre
et entretenir, et si on a besoin d'ajouter un nouveau plan tarifaire, la
plupart du temps, on peut l'encoder dans la table. Cela signifie quon
change le code du programme, mais moins frquemment.
Des changements en moins signifient que le code reste cohrent
plus longtemps et allonge la dure de vie du code de tarification.
Et voici ci-aprs un exemple et du code qui pourrait tre utilis dans
ce type de programmation :
Shabakkat 2010/2011
34

voix
Figure
8:
Schma
montrant le code et le type de table utilis dans le Table Based Rating
Chaque colonne dans la table reprsente un lment de donnes

dont on a besoin pour le processus de facturation, chaque ligne de table
reprsente un cas de facturation susceptible dexister.
Comme le dpartement marketing lutte sans arrt pour trouver des
formules et des offres adaptes chaque catgorie de clients il est dune
importance primordiale que le moteur de tarification soit flexible et puisse
sadapter rapidement ces nouveaux changements, malheureusement ce
type de programmation bas sur les tables savre tre un peu rigide, il
est plutt utile lorsquon ne change pas beaucoup les critres de
tarification puisqu chaque fois quun critre est ajout on doit
automatiquement ajouter une colonne dans une table et remplir ce
champs pour les autres cas, ce qui devient lourd avec temps.
Et donc le problme qui surgit avec ces algorithmes est la taille
statique et la forme des tables. Ils deviennent un problme quand il sagit
de sadapter aux changements ininterrompus des plans de tarification.
3. Facturation base sur des rgles pr-stocks (Rule-Based
Rating) :
Cest la mthode o les informations sur la faon de calculer le prix
sont stockes en tant que rgles qui sont traites par le code de
facturation (rating code). Les rgles sont gnralement stockes sous
forme de table, mais ces tables
contiennent aussi
les tapes du
processus de facturation (l'algorithme), en plus de la dfinition des cas de

facturations et les montants utiliser dans le calcul.
Et voici un
exemple de ce type de programmation :
Shabakkat 2010/2011
35

voix
Figure 9 : Exemple de programmation base sur les rgles pr-stockes

La mthode base sur les rgles pr-stockes requiert une plus
grande puissance des machines que la mthode base sur le code, ceci
parce que le code de la deuxime est compil alors que celui de la
premire est interprt. Ainsi, en crant ce type de moteur de tarification
on bnficie dune grande flexibilit pour sadapter aux ventuels
changements possibles du plan de tarification, mais en plus, cela devient
possible que des Analystes de facturation (dont la vision est plutt
oriente business) mettent en uvre les plans de tarifications sans laide
des programmeurs (dont la vocation est de faire des programmes
optimiss et facile comprendre).
On voit donc quavec cette mthode on peut conomiser sur le coup
des formations ncessaires pour maintenir et manager les processus de
facturation, et en plus de cela on peut rsoudre des problmes dordre
organisationnel.
Faisant maintenant un tableau comparatif de ces trois types de
programmation : (rf 21)
Les points positifs
Les points ngatifs
Le
programm
e bas sur
le code
-Le temps d'excution plus rapide.

-Exige seulement un effort de
programmation pour mettre en
uvre le plan de tarification.
-Exige que les programmeurs

tudient le code totalement avant
que n'importe quels changements ne
puissent tre faits.
-peut devenir incohrent si plusieurs
programmeurs le modifient.
Le
programm
e bas sur
les tables
Si l'algorithme et les types

dentres de l'algorithme restent
les mmes, des analystes
d'affaires peuvent changer des
plans de tarifications sans un
programmeur.
La structure de la table limite la

flexibilit. Si on doit traiter les
donnes diffremment ou inclure de
nouvelles sortes d'informations
.
Shabakkat 2010/2011
36

voix
Le
programm
e bas sur
les rgles
prstockes
III.
-Le maintien et la modification des

plans de tarification peuvent tre
garantis par des analystes de
tarification (plus besoin de
dveloppeur pour le faire)
-facilite la mise en uvre des
plans de tarification bien quils
soient compliqus.
-Un temps dexcution plus long.

-Implique un investissement majeur
dans la programmation parce quon
cre un langage pour la description
et la mise en uvre de plans de
tarification.
Concrtisation :
Dans le cadre des objectifs de notre stage, nous avons t amens

raliser un moteur de tarification pour nous permettre de calculer le cot
thorique dun appel tlphonique de loprateur.
Bien videmment vu la grande difficult de concevoir un moteur de
tarification complet, nous allons essay dans un premier temps de faire
une conception gnrale, mais nous allons nous rduire dans la mise en
uvre aux appels voix des prpays dont le taux frle les 95%. Et pour ce
faire, nous devions tout dabord comprendre le droulement des appels
voix et les rgles imposs par lANRT pour facturer les consommateurs.
1. Pr-tude :
Avant de commencer il fallait dabord connaitre les tapes par
lesquelles passe un appel tlphonique, et dun point de vue de
tarification un appel passe par trois tapes :
Dure
d'tablissement de
connexion
Dure de
communicat
ion effective
dure de
libration de
connection
Figure 10 : Les tapes par lesquelles passe un appel tlphonique

(Source : laboration personelle)
Et ici au Maroc le rglement appliqu par lANRT exige que seule la
dure de communication effective soit facture par loprateur.
En plus de cette information importante, nous avons dgag
dautres donnes qui nous seront ncessaires dans le dveloppement de
notre moteur. Aprs une tude approfondie de la tarification de loprateur
Shabakkat 2010/2011
37

voix
nous avons remarqu quil existe neuf blocks de destinations

pour un client prpay :
Mobile ONNET
Fixe ONNET
Mobile OFFNET
Fixe AMR
Fixe SMR
Zone1 Fixe
numro 1.
Zone1 Mobile
numro 1.
Zone2
Zone3
possibles
: mobile du mme oprateur.

: fixe du mme oprateur.
: mobile dun autre oprateur.
: fixe avec mobilit restreinte.
: fixe sans mobilit restreinte.
: tlphones fixes de la zone internationale
: tlphones mobiles de la zone internationale
: zone internationale numro 2.
: zone internationale numro 3.
Un block de destination veut dire que les entits qui appartiennent

ce groupe sont traites de la mme manire dun point de vue de
tarification.
Autre conclusion importante prendre en considration lors de la
conception, lexistence de trois paliers de taxation :
Minute indivisible.
1re minute indivisible puis paliers de 20s.
1re minute indivisible puis par seconds.
Enfin la notion de tarif-rduit et tarif-plein qui ne change pas pour

toutes les offres, tarif plein de 8h00 du matin jusqu 20h00 du soir (quon
appelle gnralement tarif ONPEAK) et tarif rduit dans ce qui reste de la
journe, week-ends et jours fris (quon appel gnralement tarif
OFFPEAK).
Aprs avoir recueillit ces informations ncessaires la russite de
notre moteur de tarification nous avons pu commencer la phase de
conception de notre moteur que lon peut dcrire de faon simple comme
suit :
le
profil de
de
le profil
l'appelant
la
dure de
de
la dure
conversati
on
on
l'heure
de
l'heure de
la
la journe
journe
Shabakkat 2010/2011
la
la
destination
destination
Tarif thorique
de lappel
traiteme
nt
Promotion
Promotion
Compteur
Compteur
utilis
utilis
38

voix
Figure 11 : Les lments intervenant dans le calcul du cot dun appel.

( Source : laboration personnelle)
A partir de la table remplie depuis lIN par les CDR (un CDR est,
comme expliqu auparavant, une ligne de la table contenant les
informations dtaills dun appel), nous devions rcuprer les informations
suivantes :
La dure de conversation.
Lheure de la journe.
Le profil de lappelant.
La destination.
Promotion
Le compteur utilis
On fait ensuite les traitements ncessaires pour avoir enfin en sortie

le tarif thorique de lappel.
2. Tables utilises :
Dans un premier lieu nous allons exposer quelques tables dont on va
expliquer lutilisation fur et mesure quon expliquera le fonctionnement
de notre processus de tarification.
Nous avons cr une table contenant les diffrents paliers de
taxation utiliss par loprateur, quon va appeler par la suite ref_step,
dont voici la forme :
Le champ Firststep contient la premire tranche des paliers, et le

champ nextstep contient les tranches suivantes, par exemple le deuxime
palier de taxation (firststep = 60, nextstep = 20) veut dire que la premire
tranche est une minute indivisible et les secondes tranches sont des
paliers de 20s et donc si on a un appel de 1min 30s, la dure facture sera
de 1min 40s.
Nous avons aussi cr une table contenant les diffrents tarifs
possible que ce soit pour le compteur montaire ou le compteur temporel,
quon va appeler par la suite ref_tariff, dont voici la forme:
Shabakkat 2010/2011
39

voix
Cette table contient deux tarifs : un tarif montaire et un facteur

temporel, le tarif montaire est utilis de manire classique, cest le pris
de la minute en centime, et le facteur temporel est utilis pour les forfaits
puisquon doit retrancher une dure de leur crdit.
En plus de ces deux tables, nous avons aussi cr une table
centrale, cette table est une matrice multidimensionnelle dont les
dimensions sont : le profil et la destination ; et pour chaque combinaison
de ces dimensions on rcupre deux informations : le palier de taxation
utilis et le tarif appliqu qui sont, comme mentionn au dbut, des cls
trangres vers les tables ref_tariff et ref_step , nous avons nomm cette
table ref_tariff par la suite , et la voici pour un seul type de profil:
3. Droulement de notre processus de facturation :

Dans un premier temps, nous avons calcul la dure facturer dun
appel (charged_duration) partir de la dure de conversation qui est
Shabakkat 2010/2011
40

voix
comme expliqu auparavant la dure de communication effective

(convers_duration).
Promotion
(Subscripti
on)
Destinati
on
Profil
Date/He
ure
Dure
facture
Dure
Figure 12 : Les lments entrant dans le calcul de

la dure
Dans ce traitement le profil et la destination nous renseigne sur le
palier de taxation utilis, ceci laide de la matrice, cette matrice qui est
en jointure avec la table des paliers de taxation nous permet donc de
connaitre la premire tranche ( first_step)
(next_step) utilise pour lappel ;
et la deuxime tranche
connaissant ces deux lments et la
dure effective de communication on peut calculer donc la dure facture.
Puis nous calculons le facteur qui est un vecteur contenant le

facteur en Dh/min et le facteur en min/min :
Shabakkat 2010/2011
41

voix
Promotion
(Subscriptio
n)
Destinati
on
Profil
Date/Heu
re
Facteur
ONPEA
K
OFFPE
Dure
Figure 13 : les lments entrant dans le calcul du tarif standard de
lappel
Sachant la destination et le profil ainsi que la priode de taxation,
on peut, en utilisant la matrice ref_tariff, connaitre la taxation utilis pour
le type dappel en question
Et pour la priode de taxation, nous avons ralis une fonction avec
PL/SQL qui reoit en entre un champ qui est gal trunc (timestamp /
1800) , timestamp tant le nombre de secondes coules depuis
01/01/1970 00 :00 :00 GMT, et donc ce champ sincrmente toutes les
demi-heures depuis cette date ,
et nous revoie si la valeur du champ
tombe sur un OFFPEAK ou un ONPEAK , ceci en faisant en premier lieu une

comparaison avec les jours fris et weekends et puis avec lhoraire en
utilisant la fonction To_char() en PL/SQL qui peut changer la forme de la
date selon notre besoin.
Shabakkat 2010/2011
42

voix
Enfin on rcupre, depuis le CDR, le type de compteur utilis

pour le type dappel en question et qui dpend des facteurs
suivants :
Promotion
Crdi
t
(Subscriptio
n)
Destinati
on
Compte
ur
Profil
Date/Heu
re
Dure
Figure 14 : les lments dont dpend le compteur

utilis
Aprs avoir rcupr ces informations un traitement final est appliqu :
Promotion
(Subscriptio
n)
Destinati
on
Profil
Shabakkat 2010/2011
Crdi
t
Compte
ur
Tarificatio
n
Traiteme

43
nt Final

voix
Date/Heu
re
ONPEA
K
OFFPE
Dure
Dure
facture
Tarif
Figure 15 : les lments entrant dans le calcul
final du cot
Dans ce traitement final nous vrifions la promotion afin de faire les

modifications ncessaires au tarif appliqu lappel, ceci en suivant les
tapes ci-dessous :
Tout dabord nous faisons une slection par profil, ensuite pour le
profil donn, nous testons la promotion (subscription), puis nous vrifions
le compteur utilis et enfin pour chaque type de compteur utilis nous
calculons le cot de lappel en multipliant la dure facture en faisant, la
cas chant , le changement ncessaire sur le tarif appliqu si la
promotion ( subscription) est diffrente de 0 ( c'est--dire pas de
promotion).
Conclusion :
Ceci tant une conception gnrique, nous nous sommes limits
sa ralisation aux clients prpays et deux autres profils dont le nombre
frle les 95% des clients de loprateur en question.
Et dans la mise en uvre, nous avons utilis un mix entre les
deux mthodes de programmations, Table-Based Rating et Code Based
Rating expliques dans la deuxime partie de ce chapitre, ceci vu que
nous avons stock plusieurs cas dans la matrice ref_tariff et que pour
traiter les promotions (subscriptions), la logique a t instaure dans le
code vu que si nous faisons intervenir les promotions comme dimension
dans la matrice nous aurons un trs grand nombre de lignes , et donc la
matrice sera moins lisible et plus difficile maintenir.
Shabakkat 2010/2011
44

voix
Chapitre 3
La Business Intelligence
Introduction
Aide la dcision, Informatique Dcisionnelle, intranet dcisionnel,
Datawarehouse, datamart, OLAP, analyse des donnes le jargon relatifs
aux systmes de Business Intelligence est aujourd'hui particulirement
riche.
Shabakkat 2010/2011
45

voix
Le prsent chapitre prsentera la Business Intelligence, ses

diffrentes fonctionnalits et son application dans le cadre de notre projet.
I.
Introduction la Business Intelligence :

1. Dfinition de la business Intelligence :
Toute entreprise utilise gnralement un panel dapplications

distinctes. Chacune de ces applications permet de stocker, restituer,
modifier les donnes dun service oprationnel particulier de lentreprise
(production, marketing, facturation comptabilit, etc.). Chaque service
peut mme ventuellement utiliser plusieurs applications dont les
donnes sont structures et codifies de manire diffrente aux autres
services. Ainsi les tableaux de bords et rapports utiliss se composent
gnralement dindicateurs (par exemple un chiffre daffaire pour une
clientle donne) mesurs diffremment selon le service, en utilisant des
faons de faire, des rgles et un primtre diffrent. Ces diffrences
rendent lanalyse globale des donnes difficile.
Pour pouvoir obtenir une vision synthtique de chaque service ou de
lensemble de lentreprise, il est donc ncessaire de filtrer, de croiser et de
reclasser ces donnes dans un entrept de donnes central (ou
datawarehouse). Cet entrept de donnes va permettre aux responsables
de lentreprise et aux analystes de prendre connaissance des donnes
un niveau global et ainsi prendre des dcisions plus pertinentes, do le
nom dinformatique dcisionnelle.
Linformatique
dcisionnelle
(Management
du
systme
d'information, ou BI pour Business Intelligence) dsigne les moyens, les

outils et les mthodes qui permettent de collecter, consolider, modliser
Shabakkat 2010/2011
46

voix
et restituer les donnes, matrielles ou immatrielles, d'une entreprise en

vue d'offrir une aide la dcision et de permettre aux responsables de la
stratgie d'entreprise davoir une vue densemble de lactivit traite.
Ce type dapplication utilise en rgle gnrale un entrept de donnes
(Datawarehouse) pour stocker des donnes transverses provenant de
plusieurs sources htrognes et fait appel des traitements par lots pour
la collecte de ces informations.
De nos jours, les donnes applicatives mtier sont stockes dans une (ou
plusieurs) base(s) de donnes relationnelles ou non relationnelles. Ces
donnes sont extraites, transformes et charges dans un entrept de
donnes gnralement par un outil de type ETL (Extract-Transform-Load :
Extraction-Transformation-Chargement).
Un entrept de donnes peut prendre la forme dun datawarehouse
ou dun datamart. En rgle gnrale, le datawarehouse globalise toutes les
donnes
applicatives
de
lentreprise,
tandis
que
les
datamarts
(gnralement aliments depuis les donnes du datawarehouse) sont des

sous-ensembles dinformations concernant un mtier particulier de
lentreprise.
Le reporting est vraisemblablement l'application la plus utilise aujourd'hui
de linformatique dcisionnelle, il permet aux gestionnaires de:
Slectionner des donnes relatives telle priode, telle production,

tel secteur de clientle, etc.
Trier, regrouper ou rpartir ces donnes selon des critres de leur

choix.
Raliser divers calculs (totaux, moyennes, carts, comparatif,...)
Prsenter les rsultats dune manire synthtique ou dtaille, le

plus souvent graphique selon leurs besoins ou les attentes des
dirigeants de lentreprise.
Les datamarts et/ou les datawarehouses peuvent ainsi permettre une

analyse trs approfondie de lactivit de lentreprise, grce des
statistiques
recoupant
des
informations
relatives
des
activits
apparemment trs diffrentes ou trs loignes les unes des autres, mais
dont
ltude
fait
souvent
apparatre
des
disfonctionnements,
des
corrlations ou des possibilits damliorations trs sensibles.
Shabakkat 2010/2011
47

voix
2. Etapes du processus BI:

Voici un schma reprsentant les tapes du processus BI :
Figure 16 : Les tapes du processus Business
Dans un processus BI on passe par les tapes suivantes :
Collecte des donnes :
La collecte (ou le datapumping) est l'ensemble des tches consistant

dtecter, slectionner, extraire et
filtrer les donnes brutes issues des
environnements pertinents.
Le systme d'information de l'entreprise ne se construit pas en un temps
unique. La majorit des
systmes d'information d'entreprise sont de
nature htrogne.
Bien que la standardisation des changes entre les divers outils
informatiques avance grands pas, la disparit des formats des donnes
en circulation est toujours une ralit, c'est le principal obstacle
technologique aux changes tendus d'informations.
Avant d'tre utilisables, les donnes seront formates, nettoyes et
consolides,
les
outils
d'ETL
(Extract
Transform
Load)
permettent
d'automatiser ces traitements et de grer les flux de donnes alimentant

les bases de stockage : Datawarehouse ou Datamart.
Dans notre projet, nous avons rcupr les donnes et le Datawarehouse
DWHIN grce loutil Datapump , qui permet de faire lextraction et
Shabakkat 2010/2011
48

voix
limportation des donnes plus rapidement quun export normal .La base
de donnes source DWHIN contient toutes les informations sur les appels
(CDR) ainsi que les tables ref_xxxx qui nous donnent les informations sur
les compteurs, les profils, les destinations, les promotions..
Intgration
Cette deuxime tape est lintgration des donnes. Une fois les
donnes centralises par un outil dETL, celles-ci doivent tre structures
au sein dun entrept de donnes.
Cette tape est toujours faite par un ETL grce un connecteur
permettant lcriture dans le datawarehouse qui est, gnralement, un
modle toile autour de la table de fait.
Lors de cette tape les donnes sont transformes et filtres en vue du
maintien de la cohrence d'ensemble (les valeurs acceptes par les filtres
de loutil ETL qui peuvent introduire des incohrences dans les donnes
centralises
sont
soit
rejetes,
soit
intgres
aprs
une
phase
dadaptation).
Diffusion
Cette tape de diffusion met les donnes la disposition des

utilisateurs, elle permet la gestion de droits daccs et respecte donc des
schmas correspondant au profil ou au mtier de chacun. Ainsi l'accs
direct l'entrept de donnes nest pas autoris grce sa politique de
scurit, en effet ce genre de pratiques ne correspond gnralement pas
aux besoins des dcideurs ou analystes. L'objectif principal de ltape de
diffusion est de segmenter les donnes collectes en contextes qui soient
cohrents, simples utiliser et qui correspondent une activit
dcisionnelle particulire (par exemple aux besoins du dpartement
marketing). En comparaison avec lentrept de donnes qui
peut
hberger de nombreuses variables ou indicateurs, un contexte de diffusion

n'en prsente que quelques dizaines pour rester simple dexploitation.
Chaque contexte peut correspondre un datamart, bien que le
stockage
physique
ne
soit
pas
sujet
des
rgles
particulires.
Gnralement un contexte de diffusion est multidimensionnel : il est

modlisable sous la forme d'un hypercube et peut donc tre mis
disposition via un outil OLAP.
Shabakkat 2010/2011
49

voix
Enfin les diffrents contextes d'un mme SID n'ont pas forcement tous
besoin du mme niveau de dtail selon la cible vise. En effet de
nombreux agrgats n'intressent que certaines applications et ne sont
donc pas considrs comme des agrgats communs. Ces cumuls ne sont
donc pas grs par la fonction d'intgration mais par la diffusion. Ils
peuvent tre soit calculs dynamiquement soit stocks de manire
persistante.
La restitution:
Cette dernire tape, galement appele reporting, se charge de

prsenter les informations valeur ajoute de telle sorte qu'elles
apparaissent de la faon la plus lisible possible. Les donnes sont
principalement modlises par des reprsentations base de requtes
afin de constituer des tableaux de bord ou des rapports via des outils
d'analyse dcisionnelle.
Cette quatrime fonction, la plus visible pour l'utilisateur, assure le
fonctionnement du poste de travail, le contrle d'accs aux rapports, la
prise en charge des requtes et la visualisation des rsultats.
Le reporting est l'application la plus utilise dans linformatique
dcisionnelle, il permet aux dcideurs :
de slectionner des donnes par axe danalyse

de trier, regrouper ou rpartir ces donnes selon des critres de
choix,
de raliser des calculs (totaux, moyennes, sommes, pourcentages,
carts)
de prsenter les rsultats de manire synthtique ou dtaille,
gnralement sous forme de graphiques.
Les programmes utiliss pour le reporting permettent de faire varier

certains critres pour affiner lanalyse, des instruments de type tableau de
bord quips de fonctions d'analyses multidimensionnelles sont aussi
utiliss pour cette dernire tape de BI.
3. Conception
de
lentrept
de
donnes
(Datawarehouse) :
Shabakkat 2010/2011
50

voix
Nous commencerons par introduire les concepts fondamentaux du

Datawarehousing
(ncessaires
pour
la
comprhension
du
projet),
continuerons par l'explication des mthodes de conception d'entrept de

donnes, et terminerons
par
une prsentation de notre entrept de
donnes utilises dans le projet.
Figure 17 : Figure illustrant le concept de
Un entrept de donnes, ou datawarehouse, est une vision

centralise et universelle de toutes les informations de l'entreprise. C'est
une structure (comme une base de donnes) qui a pour but, contrairement
aux bases de donnes, de regrouper les donnes de l'entreprise pour des
fins analytiques et pour aider la dcision stratgique, la dcision
stratgique tant une action entreprise par les dcideurs et qui vise
amliorer, quantitativement ou qualitativement, la
performance de
l'entreprise, en gros, c'est un gigantesque tas d'informations pures,

organises et provenant de plusieurs sources de donnes, servant aux
analyses et l'aide la dcision.
En effet, l'entrept de donnes est le meilleur moyen que les
professionnels ont trouv pour modliser de l'information pour des fins
d'analyse, et il ne serait pas tonnant que d'ici quelques annes un
nouveau
concept
apparaisse
pour
rvolutionner
l'informatique
dcisionnelle voici alors une dmystification des concepts principaux lis

aux Datawarehousing.
Shabakkat 2010/2011
51

voix
Datamart : Les DataWarehouses tant, en gnral, trs volumineux

et trs complexes concevoir, on a dcid de les diviser en
bouches plus faciles crer et entretenir, ce sont les Datamarts.
On peut faire des divisions par fonction (un datamart pour les
ventes, pour les commandes, pour les ressources humaines).
Dimension : Lorsqu'on fait un schma de BD pour un systme

d'information classique, on parle en termes de tables et de relations,
une table tant une reprsentation d'une entit et une relation, une
technique pour lier ces entits.
En BI, on parle en termes de Dimension et de Faits, on entend par
dimensions les axes avec lesquels on veut faire l'analyse. Il peut y
avoir une dimension client, une dimension produit, une dimension
gographie (pour faire des analyses par secteur gographique), etc.
Une dimension est tout ce qu'on utilisera pour faire nos
analyses.
Fait : Les faits, en complment aux dimensions, sont ce sur quoi va

porter l'analyse. Ce sont des tables qui contiennent des informations
oprationnelles et qui relatent la vie de l'entreprise. Voici pour
exemple une table de fait pour les ventes (chiffre d'affaire net,
quantits et montants commands, quantits factures, quantits
retournes, volumes des ventes).
Un fait est tout ce qu'on voudra analyser.
Etoile : Une toile est une faon de mettre en relation les

dimensions et les faits dans un entrept de donnes. le principe est
que
les
dimensions
sont
directement
relies
un
fait
(schmatiquement, a fait comme une toile).
Figure 18 : Figure illustrant la modlisation en

toile.
Shabakkat 2010/2011
52

voix
Flocon : Un autre modle de mise en relation des dimensions et des faits

dans un entrept de donnes. Le principe tant qu'il peut exister des
hirarchies de dimensions et qu'elles sont relies aux faits, a fait comme
un flocon.
Nous nous intressons au schma en toile qui sera utilis lors de
notre projet .
En effet, notre Datamart est constitu de la table de fait
RA_FACT_CALLS qui est lie aux dimensions qui ont t choisies pour
notre projet selon notre besoin danalyse du revenu.
Nos dimensions sont :
DIM_DATETIME
: Contient les informations sur la date et
lheure de lappel.
DIM_PROFILE
: Contient les informations sur le profil de
lappelant
DIM_SUBSCRIPTION : Contient les informations sur la promotion
de lappelant.
DIM_B_BLOCK
: Contient les informations sur la destination
(OFFNET,ONNET)
DIM_ACCOUNT : Contient les informations sur le compteur utilis.
DIM_RATE
: Contient le tarif utilis.
Notre table de fait est la suivante :
Elle contient en plus des cls primaires les mesures suivantes :
TOTAL_CHARGEABLE
lappel.
TOTAL_CHARGED
Shabakkat 2010/2011
: La dure de la conversation de
: La dure facture.
53

voix
TOTAL_AMOUNT
: Le cout de lappel
THEORITICAL_CHARGED : La dure facture par notre moteur de
tarification.
THEORITICAL_AMOUNT
: Le cout de lappel calcul grce
notre moteur de tarification.
Voici le schma de notre Datamart.
Figure 19 : Figure montrant le modle de notre

Datamart
Notre datamart sous Oracle 11g a t cr via un script SQL.

Et pour remplir notre table de fait, nous avons utilis une procdure cr
avec du PL/SQL dans laquelle nous avons agrg les donnes avec la
fonction SUM et cest en remplissant cette table que nous avons eu
recours aux fonctions de la tarification que nous avons cr auparavant,
ceci
pour
remplir
les
deux
champs
THEORITICAL_CHARGED
et
THEORITICAL_AMOUNT.
II.
Cube OLAP etanalyse multidimensionnelle :
Shabakkat 2010/2011
54

voix
1. Vue densemble sur les concepts de base des

cubes OLAP:
Nous commenons par la question la plus vidente et aussi qui tait
source de dbat entre les experts du business Intelligence : Cest quoi
OLAP ?
Technique d'analyse, labore en 1993 par E.F. Codd, un des
crateurs des bases de donnes relationnelles, la demande de la firme
Arbor Software (devenue aujourdhui Hyperion).
Aujourd'hui, OLAP permet aux dcideurs, en entreprise, d'avoir accs
rapidement et de manire interactive une information pertinente
prsente sous des angles divers et multiples, selon leurs besoins
particuliers.
Trs
utiliss
dans
les
secteurs
de
la
banque,
des
tlcommunications et de la grande distribution, les serveurs OLAP sont

des outils oprationnels, qui permettent de valider une stratgie mise en
uvre ou de vrifier des tendances. Ainsi, on pourra souhaiter examiner
lvolution des ventes dun produit donn, dans une rgion gographique
prcise, au cours dune saison donne. Il suffira de prciser ces trois
dimensions danalyse au moteur OLAP. Les valeurs trouves dans la base
pourront tre reprsentes sous la forme dun cube. Si lon avait souhait
examiner plus de trois critres ou dimensions, on parlerait alors
dhypercube. Exemple : on mesurera l'volution sur trois ans (axe 1) du
chiffre d'affaires (axe 2) li aux ventes d'une gamme de produits (axe 3)
ralises en direction d'un profil client particulier (axe 4) sur une zone
gographique prcise (axe 5).
Aussi, pour mieux cerner et comprendre les cubes OLAP nous
dfinissons les mots Online et Analytical processing:
Online : Bien que la plupart des outils OLAP et les applications de

permettre
le
dveloppement
de
rapports
qui
peuvent
tre
sauvegards et imprims lorsqu'ils ne sont pas connects aux

donnes, OLAP met l'accent sur l'accs direct des donnes plutt
que de rapports statiques. Les requtes analytiques sont prsentes
partir de la base de donnes en temps rel, et les rsultats sont
retourns en temps rel.
Analytical
processing :
Cest
le
concept
cl
dOLAP.
Les
utilisateurs finaux peuvent :
Shabakkat 2010/2011
55

voix
Naviguez
facilement
sur
les
des
donnes
multidimensionnelles pour effectuer des requtes ad hoc et

afficher les rsultats dans une varit de dispositions
intressantes
Grer de manire transparente les rgles de gestion des
dimensions et des cubes.

Percer les niveaux de dtails pour
dcouvrir des aspects
importants de donnes
Obtenir dune faon rapide et efficace
des rsultats de
calcul de donnes sophistiqus et de slection travers les

multiples dimensions des donnes.
Un rapport standard transactionnel ou une requte peut demander:
Quand lordre 84305 a t transport?" Cette requte reflte les
mcanismes de base de faire une requte OLTP. Il s'agit de simple
slection des donnes et peu ou pas de traitement de calcul. On peut y
rpondre directement depuis le systme transactionnel, probablement
sans affecter les autres oprations. Toute organisation a besoin de ce
niveau de base de l'information.
En revanche, les systmes OLAP sont gnralement dploys pour
tendre et renforcer la capacit d'une organisation pour rpondre un
ventail beaucoup plus large de questions d'affaires sur les donnes qu'ils
recueillent dans leurs systmes transactionnels:
Comment
sont les ventes de
notre top 10 produits
rentables
travers l'Europe pour ce trimestre compar avec les ventes dil y a
un an?
Quels sont les produits qui composent 40% de notre bnfice pour
chaque rgion au fil du temps?
Ces questions sont plus analytiques et plus complexes, et la rponse

une question en entrane souvent immdiatement une autre question
que l'utilisateur suit un train de la pense dans la recherche d'un problme
ou une opportunit d'affaires.
OLAP est conu pour rendre plus facile pour les utilisateurs finaux de
demander ces types de questions analytiques sans exiger:
Lassistance du dpartement IT
Des comptences en programmation
Shabakkat 2010/2011
56

voix
Des connaissances techniques sur l'organisation de la base de

donnes
Les rsultats de requtes doivent galement tre rapides afin que le train
de l'analyste de la pense ne soit pas interrompu et la valeur de l'analyse
ne soit pas diminue.
2. Le modle de donnes des systmes OLAP:

Les systmes OLAP sont optimiss pour une rcupration rapide des
donnes pour l'analyse dimensionnelle.
Nous allons maintenant examiner le modle multidimensionnel
logique, qui sert de base pour les systmes OLAP.
La cl des modles OLAP cest que la plupart des modles de donnes
OLAP sont construits autour de deux concepts cls : les mesures et les
dimensions.
Les mesures :
Les Mesures reprsentent les donnes factuelles, elles sont parfois
appeles faits Des exemples typiques de mesures sont les ventes, les
cots, le bnfice et la marge. Les mesures sont organises par une ou
plusieurs dimensions. Beaucoup de gens visualisent, les mesures comme
tant une forme simple de cube, dans laquelle les bords de la forme sont
les dimensions et le contenu de la forme sont les valeurs de mesure.
L'image ci-dessous montre un gnrique simple en trois dimensions.
Shabakkat 2010/2011
57

voix
Bien videmment, Les mesures ne sont pas limites trois

dimensions. Une mesure peut avoir autant de dimensions pour grer avec
prcision les donnes associes cette mesure.
En option supplmentaire, Oracle OLAP permet de concevoir et grer de
multiples cubes, chacun avec diffrentes dimension.
Les mesures peuvent tre divises en deux catgories:
Mesures stockes
Mesures calcules
Mesures stockes sont chargs, regroups et stocks directement dans la

base de donnes. Alternativement, elles peuvent tre drives partir des
rsultats des calculs qui sont stocks. Par exemple une prvision pourrait
tre drive d'une autre mesure stocke telles que les recettes et les
rsultats du calcul des prvisions stockes dans les mesures de la base de
donnes. Par contre, Les mesures calcules sont des mesures dont les
valeurs sont calcules dynamiquement au moment de la requte. Seule la
rgle de calcul est stocke dans la base de donnes.
Dimensions :
Les dimensions identifient et classent les donnes dans nos mesures en
formant les bords de ces mesures. Des exemples de dimensions sont
produits, la gographie, l'heure et le canal de distribution.
Les dimensions ont trois lments cls :
Hirarchies
Niveaux
Shabakkat 2010/2011
58

voix
Attributs
Hirarchies :
Les hirarchies des dimensions sont facultatives, mais sont communs
dans les systmes OLAP. Une hirarchie est une structure logique qui
regroupe les membres d'une dimension pour des fins analytique.
Chaque dimension peut avoir plusieurs hirarchies, si ncessaire. Par
exemple, la dimension temps peut avoir une hirarchie qui reprsente le
calendrier julien et une autre hirarchie qui reprsente un calendrier fiscal.
Figure 20 : la hirarchie dans les dimensions
La structure dune dimension est organise de faon hirarchique base

sur les relations parent-enfant. Ces relations permettent:
La navigation entre les niveaux: les Hirarchies des dimensions
permettent le forage (Drill down) des niveaux infrieurs ou la navigation
(roll up) des niveaux plus levs. Ces types de relations rendent facile
pour les utilisateurs de naviguer de gros volumes de donnes
multidimensionnelles.
L'agrgation des valeurs des enfants aux valeurs des parents: Les
parents reprsente l'agrgation de ses enfants. Les valeurs de donnes
des niveaux plus bas sont agrges dans les valeurs de donnes des
niveaux suprieurs. Les dimensions sont structures hirarchiquement afin
que les donnes diffrents niveaux d'agrgation puissent tre
manipules ensemble de manire efficace pour l'analyse et l'affichage.
Allocation des valeurs des parents des valeurs des enfants:
L'inverse d'agrgation est l'attribution et elle est largement utilise pour la
Shabakkat 2010/2011
59

voix
planification, la budgtisation, et autres applications similaires.
Figure 21 : Notion dagrgation et de navigation dans les donnes
Niveaux :
Figure 22 : Les niveaux dagrgation
Chaque niveau reprsente une position dans la hirarchie. Le niveau

au-dessus du niveau de base contient les valeurs d'agrgation pour les
niveaux infrieurs. Une hirarchie contient gnralement plusieurs
niveaux, et un seul niveau peut tre inclus dans plus d'une hirarchie.
Attribut :
Les attributs fournissent des informations descriptives sur les membres
dune dimension et sont galement utiles lorsque vous slectionnez les
membres de dimension pour l'analyse:
* Slectionnez les produits dont la couleur (attribut) est "Blue".
* Slectionner l'ensemble des priodes dont la description contient
"Janvier."
3. Construction du cube OLAP :
Shabakkat 2010/2011
60

voix
Dans cette partie, nous montrons comment nous avons utilis loutil
AnalyticWorkspace Manager (AWM) pour la conjonction avec Oracle 11g
et pour construire des objets de base de donnes multidimensionnelles, en
loccurrence notre cube OLAP.
Alors, quelle est la diffrence entre AWM et OWB? AWM devrait tre
considr comme un "EL", il ne contient pas les outils de transformation
(en AWM 11g des transformations simples sont possibles), pour le
renforcement des espaces de travail analytique. Le public cible de AWM
sont les utilisateurs professionnels et les dveloppeurs utilisant dj un
autre outil ETL (qui tait pour notre cas une procdure PL/SQL dans
laquelle nous avons fait les transformations requises) qui ne fournit pas
de support pour la modlisation de donnes OLAP.
AWM 11g est un outil pour crer, dvelopper et grer des donnes
multidimensionnelles dans un entrept de donnes Oracle 11g. Grce
cet outil, nous avons cr le conteneur de donnes OLAP, un espace de
travail analytique (Analytic Workspace), puis ajout nos dimensions ainsi
que notre cube OLAP.
Figure 23 :Loutil analytic Workspace Manager

Dans Oracle OLAP, un Cube offre un moyen pratique de recueillir des
mesures avec des caractristiques similaires, y compris la dimension, les
rgles d'agrgation, et ainsi de suite. Un AW particulier peut contenir plus
d'un cube, et chaque cube peut dcrire une forme diffrente dimensions.
Les multiples cubes dans le mme AW peuvent partager une ou plusieurs
Shabakkat 2010/2011
61

voix
dimensions. Par consquent, un cube est tout simplement un objet logique

qui permet un administrateur de construire et maintenir des donnes
dans un AW.
Notre source de donnes est le schma en toile contenu dans
Oracle 11g qui contient toutes les informations sur les appels. Le schma
en toile contient les dimensions, qui dcrivent les relations dans les
donnes, et la table de fait, qui contient les paramtres utiliss pour
mesurer la performance.
Aprs avoir identifi nos dimensions, nous avons identifi les
niveaux de synthse au sein de chaque dimension. Exigences d'analyse
rvlent que:
ACCOUNT
BNUMBER
DATEETIME
DT_YEAR
PROFILE
SUBSCRIPTION
: ALL, Account
: NM_ALL, NM_BLOCK, NM_code, NM_SHORT
: DT_ALL, DT_DAY, DT_HOUR, DT_MIN, DT_MIN, DT_MONTH,
: PF_ALL, PF_class, PF_PROFILE, PF_SUBPROFILE
: SB_ALL, SB_SUBS
Notons que pour chaque dimension, un niveau ALL
est toujours
ajoute pour permettre aux utilisateurs de faire des analyses globales.
Dans notre projet, nous avons cr notre cube, REVENU_ASSURANCE

contenant nos mesures. Ce sont des mesures permettant de comparer les
dures et les couts facturs par lIN avec celles issues de notre moteur de
tarification et qui sont stocks dans notre table de fait. Le cube contient:
Dimensions: DATETIME, PROFILE, SUBSCRIPTION, B_BLOCK, ACCOUNT,
RATE.
Mesures: TOTAL_CHARGEABLE, TOTAL_CHARGED, TOTAL_AMOUNT,
THEORITICAL_CHARGED, THEORITICAL_AMOUNT
Les donnes de ces mesures, et les dimensions qui organisent les
mesures, sont fournies par des vues dans le base DWHIN, comme nous le
verrons par la suite.
Nous allons maintenant parcourir les tapes pour une configuration
entire dAWM :
Shabakkat 2010/2011
62

voix
ETAPE 1 : Connexion la base de donnes :

La premire tape est de crer un nouvel utilisateur notre propre espace
de travail analytique. Pour cela nous avons cr un utilisateur appel
OLAPIN et cet utilisateur aura besoin d'avoir un rle particulier afin de lui
permettre de crer et grer des espaces de travail analytique. Ce rle est
OLAP_USER.
Cet utilisateur aura besoin des privilges SELECT sur les tables source qui
sera utilise pour remplir les dimensions et les cubes.
Lorsque nous dmarrons AWM pour la premire fois, il faut dfinir
une nouvelle connexion notre instance de base de donnes.
Figure 23 -1: Ajout de la base de donnes sous
AWM
Figure 23-2 : La connexion la base de donnes sous AWM

ETAPE 2 : Cration de notre espace analytique :
Shabakkat 2010/2011
63

voix
Afin de crer notre espace de travail analytique, nous avons besoin de

lui attribuer un schma qui est DWHIN. Eventuellement, nous pouvons
choisir un tablespace o cette AW est stocke. Par dfaut, le tablespace du
schma est utilis. Ceci est mis en place par l'administrateur de base de
donnes(DBA) lorsque le schma est cr.
Une fois notre AW est cr nous avons dfini manuellement nos
dimensions et notre cube.
Figure24 : Cration dun espace analytique sous AWM
ETAPE 3 : Cration des dimensions et des hirarchies

Les dimensions sont lensemble de valeurs uniques qui permettent
d'identifier et de catgoriser les donnes. Ils forment les bords des
mesures (les faits). Les dimensions sont une structure qui aide la
navigation dans Les donnes. Cette structure comprend les niveaux, les
hirarchies et les attributs dans le modle logique. Nous avons dfini ces
objets manuellement, en plus de la dimension elle-mme, afin d'avoir des
dimensions entirement fonctionnelles.
Shabakkat 2010/2011
64

voix
Figure 25 : Cration des dimensions et des hirarchies

Par exemple pour la dimension DATETIME on a cr les niveaux et les
hirarchies comme le montre la figure suivante.
Figure 26 : Les niveaux de la dimension DATETIME

Puis on devait faire la correspondance avec les donnes que va contenir
chaque niveau, pour cela on a construit des vues qui ont comme lignes
exactement les niveaux de la dimension. Pour le cas de cette dimension
DATETIME nous avons pris la table ref_Unixhh du datawarehouse qui
contient les colonnes suivantes :
Shabakkat 2010/2011
65

voix
Figure 27 : La table de rfrence du temps

Le premier champ est gal trunc (timestamp / 1800) ,timestamp
tant le nombre de secondes coules depuis 01/01/1970 00 :00 :00
GMT , et donc cest un champ qui sincrmente toutes les demi-heures
depuis cette date , et le deuxime champ TS qui est la traduction de
UNIXHH en une date prcise.
En utilisant la fonction TO_CHAR de PL/SQL nous avons cr une vue
pour extraire lanne, le mois, le jour, lheure et la minute afin de faire le
mapping pour remplir notre dimension.
Figure 28 : La correspondance entre les vues et les hirarchies des

dimensions
Shabakkat 2010/2011
66

voix
ETAPE 4 : Cration et remplissage du cube

Dans Oracle OLAP, un Cube offre un moyen pratique de recueillir des
mesures des mmes dimensions. Par consquent, un cube est simplement
un objet qui permet un administrateur de construire et de maintenir un
AW.-Les artes d'un cube sont dfinies par ses dimensions. Si plusieurs
mesures ont la mme dimension, il est probable qu'ils seront dfinis dans
le mme cube.
Les donnes sur les appels et leurs cots peuvent tre organises
dans le cube REVENU-ASSURANCE, dont les bords contiennent des valeurs
du profil, la destination, la promotion, le compteur et les dimensions du
temps et dont le corps contient des mesures qui pourraient inclure
la
dure facture, le cot de lappel ainsi que le cot et la dure thorique

calcul par notre moteur de tarification.
Une fois le cube cr, on lui attribue les dimensions et les mesures
correspondants.
Figure 29 : La cration du cube sous AWM

Aprs cette tape il faut faire la correspondance avec notre table de
fait dj cre et remplie dans notre Datawarehouse.
Shabakkat 2010/2011
67

voix
Une fois toutes ces tapes ralises, notre cube est charg et donc
on doit le relier avec OBIEE par loutil de ladministration Oracle pour
pouvoir faire des analyses et gnrer les rapports.
III.
Gnration des rapports multidimensionnelle :

1. Cration des mtadonnes OBIEE pour
le cube
OLAP :
Ce chapitre couvre la cration des mtadonnes pour Oracle
Business Intelligence Enterprise Edition (OBIEE) pour l'accs Oracle
Database 11g en utilisant Oracle 11g OLAP Analytic Workspace Manager
Plug-in pour OBIEE.
Nous commenons par un aperu sur loutil Oracle OLAP 11g :
Oracle OLAP est un composant intgr de base de donnes Oracle 11g
qui nous permettra dobtenir facilement un aperu sur les bases de
donnes ORACLE. Il propose:
Rapidit
performance
Grande capacit danalyse
Modle utilisateur simple, qui reflte l'usage des entreprises
Libre accs tous les outils SQL
de requte, du calcul et de prparation des donnes de
Les objets multidimensionnels dans la base de donnes Oracle sont

fournis par ORACLE OLAP, donc pour accder notre
cube OLAP et
exploiter le moteur de calcul OLAP, un outil SQL - tels que OBIEE - utilise
l'interface intgre SQL OLAP. Les donnes sur notre cube sont
directement accessibles par des requtes SQL via un ensemble de vues.
Ces vues reprsentent un cube OLAP comme un schma en toile avec les
caractristiques suivantes:
Une vue du cube reprsente la table de fait
Des vues de dimensions jouent le rle des tables de dimensions.
Shabakkat 2010/2011
68

voix
Chaque outil BI dpend de sa couche de mtadonnes alors un

rfrentiel dcrivant la construction des requtes pour extraire des
donnes relationnelles doit tre cr et cela se fait grce ORACLE BI
ADMINISTRATION.
Un rfrentiel de mtadonnes contient trois couches dinformations :
Couche physique : Dfinit les sources de donnes laquelle

Oracle BI Server soumet les requtes.
Couche de gestion et de correspondance : Spcifie les

correspondances entre le modle de gestion et les schmas de la
couche physique. Son principal but est de capter comment le
dcideur pense en utilisant son propre vocabulaire
Couche de prsentation : ajoute un niveau d'abstraction par

rapport la couche de gestion. elle reprsente la vue sur les
donnes des utilisateurs finaux, client et les applications, telles
quOracle BI Analytics.
Notre rfrentiel
de donnes a
fourni lors de notre stage
DWHIN_BI001 par notre encadrant :
Shabakkat 2010/2011
69

voix
Figure 30 : Rcupration du rfrentiel de donnes

Lequel nous avons modifi en
ajoutant nos tables de faits et nos
dimensions pour avoir le modle ci-dessous :
Figure 31 : Rfrentiel de donnes aprs modification
2. de donnes en utilisant Oracle BI Analytics :

Aprs avoir utilis l'outil d'administration Oracle BI pour crer un
rfrentiel qui contient les mtadonnes ncessaires pour dcrire les
donnes du notre cube OLAP.
Shabakkat 2010/2011
70

voix
Dans cette partie, nous allons interroger les donnes en utilisant ORACLE
BI Analytics qui nous permettra de slectionner, afficher et naviguer dans
nos donnes OLAP.
Figure 32 : Ecran daccueil dOracle Business Intelligence

Oracle BI analytics fait partie de la suite OBIEE Oracle Business
Intelligence Suite Enterprise Edition qui est une suite complte de
solutions BI offrant une gamme complte danalyses et de reporting.
OBIEE est une architecture BI moderne unifie et hautement volutive
(ETL, Entrept de donnes, Serveur danalyse OLAP et Tableaux de Bords).
Ces avantages sont :
Une architecture BI sintgrant toutes les sources de donnes
grce ses ETL prconstruits pour lextraction et le chargement
multi-sources de donnes oprationnelles (ETL, application, web,
base de donnes, fichiers plats, donnes XML et donnes non
structures) ce qui permet de sappuyer sur diffrentes sources de
donnes et applications rparties dans lentreprise.
Un entrept de donnes avec des modles de donnes prconstruits
(schmas en toiles) conus pour lanalyse et le reporting.
Une organisation de linformation prconstruite incluant les calculs,
les agrgations, les rpartitions et les indicateurs destins aux
dcideurs et aux utilisateurs de lapplication.
Shabakkat 2010/2011
71

voix
Une restitution de donnes riche avec une librairie dindicateurs, de

tableaux de bords interactifs, un systme de requtes et analyses et
des systmes dalertes destination des utilisateurs.
Une plateforme robuste, OBIEE prend en charge de gros volumes de
donnes et offre la possibilit de travailler en mode dconnect.
Nous avons utilis Oracle BI Analytics pour gnrer les rapports
concrtisant notre tude de Revenu Assurances partir de notre modle
de prsentation introduit dans loutil dadministration BI, en se basant sur
nos mesures :
Figure 33 : cran principale de notre univers
Shabakkat 2010/2011
72

voix
Nous aboutissons au recueil du fruit de notre travail qui est la

concrtisation de notre projet de revenu assurance par des rapports, des
graphes et des analyses qui feront la comparaison entre les mesures
faites par notre moteur de tarification et celles fournies par le rseaux
intelligent selon plusieurs critres dont voici quelques exemples :
Commenant tout dabord avec un rapport simple :
Figure 34 : Rapport comparatif entre Theoretical Amount et Total Amount

Ce rapport nous montre le tarif appliqu par les prpays pour les
diffrents blocs de destination, on remarque bien quil y a des diffrences
(bien que minimes) entre le tarif thorique et le tarif pratique appliqu au
niveau de lIN.
On a omit le ONNET qui constitue le plus grand chiffre daffaire pour

pouvoir avoir une plus nette visibilit dans le graphe suivant :
Shabakkat 2010/2011
73

voix
Figure 35 : Graphique en barreau
Qui montre le tarif thorique en bleu et le tarif pratique e, rouge pour

chaque bloc.
Le deuxime rapport montre une comparaison entre le cot

thorique des appels avec le cot pratique sur le compteur
montaire pour les prpays vers 5 pays :
Figure 36 : Comparaison entre Theoretical Amount et Total Amount pour

les prpays
Shabakkat 2010/2011
74

voix
Comme le montre le rapport le cot thorique et pratiques vers ces pays

est trs proche ce qui signifie quil ny a pas un grand problme dans le
systme de facturation.
Et on remarque que ces deux secteurs sont presque identiques.

Et pour conclure ce rapport voici un autre diagramme en barres qui illustre
la petite diffrence entre les deux tarifs :
Un troisime et dernier rapport pour finir et qui va faire intervenir

deux autres forfait en plus des clients prpays, mais aussi il va faire
intervenir la dure thorique facturer en comparaison avec la
dure facturer dans lIN :
Shabakkat 2010/2011
75

voix
Conclusion :
A la fin de cette partie qui met fin notre projet, on a pu manipuler
un grand nombre de donnes et faire les agrgations ncessaire grce au
cube OLAP quon avait cre et loutil de reporting dOracle BI ANALYTICS,
et enfin gnrer des rapports qui pourrait dtecter lexistence dun
ventuel problme dans la plateforme de tarification.
Shabakkat 2010/2011
76

voix
Conclusion gnrale
Ce projet avait pour vocation de faire du revenu assurance sur les

appels voix du client de Shabakkat, ceci en dtectant les carts entre les
tarifs pratiques appliqus au niveau de la plateforme de tarification et les
tarifs thoriques que lon devait calculer grce un moteur de tarification
que nous devions crer.
Pour cela il fallait de prime abord comprendre le Revenu Assurance,
nous familiariser avec son jargon et comprendre les diffrentes notions
autour de cette pratique,
plus particulirement la notion de fuite de
revenu ou revenu leakage qui est de faon simple, dans le cadre de

notre projet, la soustraction du montant pratique et thorique des appels.
Le Revenu Assurance compris, nous avons
eu pour mission de
concevoir le moteur de tarification qui nous permettra de calculer le cot

thorique des appels, pour cela nous devions dans un premier temps faire
une tude globale sur la tarification, prsente dans le deuxime chapitre,
avant de se lancer dans la conception et finalement la mise en uvre du
moteur pour les particuliers dont le pourcentage frle 95% des clients.
Le cot thorique calcul, nous avons fait appel la solution BI
dOracle OBIEE (Oracle Business Intelligence Entreprise Edition) pour
traiter le nombre important de donnes de faon plus fluide,
plus
prsentable et surtout plus efficace.

A ce stade nous avons commenc recueillir les fruits des efforts
fournis pour la russite de ce projet puisque nous avons pu faire des
comparaisons entre les deux tarifs dj mentionns. Sachant que la
plateforme de tarification du client de Shabakkat
tarifie presque
100 000 000 de tickets par jour, une erreur, aussi minime quelle soit, peut
engendrer des consquences fcheuses sur les revenus, et le systme que
nous avons cr sera un bon atout pour dtecter rapidement lincohrence
des tarifs et prendre les mesures ncessaires pour minimiser les fuites de
revenus.
Shabakkat 2010/2011
77

voix
Comme perspectives pour notre projet, nous comptons dlargir

notre moteur de tarification en intgrant la Data et les SMS et MMS et puis
faire un tableau de bord pour le suivi avec des alerteurs pertinents.
Table des figures :
Figure 1-3: Prsence de Shabakkat dans le monde

Figure 1-4 : Structure de lorganisation de Shabakkat
Figure 1-3 : Diagramme de GANTT illustrant les tapes de notre projet
Figure 1 : les degrs de maturit du revenu assurance
Figure 2 : Figure illustrant la notion de perte de revenu
Figure 3 : Diagramme illustrant les causes de perte de revenu
Figure4 : Figure illustrant les causes de la convergence des oprateurs
Figure 5 :
Figure 6 : Diagramme illustrant les captures de donnes et traitements des CDRs
Figure 7 : Schma illustrant un processus de facturation standard
Figure 8 : Schma montrant le type de table utilis dans le Table BasedRating
Figure 9 : Exemple de programmation bas dur les rgles pr-stockes
Figure 10 : Figure illustrant les tapes par lesquelles passe un appel tlphonique
Figure 11 : Les lments intervenant dans le calcul du cot dun appel.
Figure 12 : Les lments entrant dans le calcul de la dure facture
Figure 13 : les lments entrant dans le calcul du tarif standard de lappel
Figure 14 : les lments dont dpend le compteur utilis
Figure 15 : les lments entrant dans le calcul final du cot
Figure 16 : Les tapes du processus Business Intelligence
Figure 17 : Figure illustrant le concept de Datawarehousing
Figure 18 : Figure illustrant la modlisation en toile.
Figure 19 : Figure montrant le modle de notre Datamart
Figure 20 : Figure illustrant le concept de hirarchie dans les dimensions
Shabakkat 2010/2011
78

voix
Figure 21 : figure illustrant la notion dagrgation et de navigation dans les
donnes
Figure 22 : Figure illustrant la notion de niveaux dagrgation
Figure 23-2 : La connexion la base de donnes sous AWM
Figure 23 -1: La connexion la base de donnes sous AWM
Figure 24 : Cration dun nouvel espace analytique sur AWM
Figure 25 : Cration des dimensions et des hirarchies
Figure 26 : Figure illustrant les niveaux de la dimension DATETIME
Figure 27 : La table de rfrence du temps
Figure 28 : Figure illustrant la correspondance entre les vues et les dimensions
Figure 29 : Figure illustrant la cration du cube sous AWM
Figure 30 : Rcupration du rfrentiel de donnes
Figure 31 : Rfrentiel de donnes aprs modification
Figure 32 : Ecran daccueil dOracle Business Intelligence
Figure 33 : cran principale de notre espace danalyse
Shabakkat 2010/2011
79

voix
Glossaire :
AWM :AnalyticWorkspace Manager

AW :AnalyticWorkspace
BI : Business Intelligence
CDR :CallDetail Record
CRM : Customer Relationship Management
D.O: DeliveryOperation
ETL : Extract - Transform Load
E.S.E: End User Service Engineering
IN : Intelligent network
Shabakkat 2010/2011
80

voix
IT : Information Technologie
OLAP : Online Analytical Processing
OBIEE : Oracle Business Intelligence Enterprise Edition

ONNET : On Network
OFFNET : Off Network
OWB : Oracle WarehouseBuilder
O.A.C: OperatorAsset Contribution
O.S.S: Operation support System
RA : Revenue Assurance
SID :SystemIdentificator
S.D.S : System Delivery Service
TS : TimeStamp
MBR : Mobilit restreinte
Shabakkat 2010/2011
81

voix
Annexe:
Oracle Database 11 g
Oracle Database 11g est un produit parmi dautres formant la suite
Oracle 11g (Oracle Database, Oracle Application Server, Oracle Developer
Suite, Oracle Entreprise Manager Grid Control ).
Oracle Database 11g est le systme de gestion de bases de donnes
Oracle permettant plusieurs utilisateurs daccder simultanment aux
donnes tout en garantissant une disponibilit et des mcanismes de
rcupration aprs incident.
Sachez bien que Oracle Database dsigne le logiciel Oracle en entier,
tandis que base de donnes a une signification bien prcise dans
l'architecture oracle.
Pour garantir un niveau de performance lev, Oracle maintient la base de
donnes grce des structures mmoires (en mmoire vive : la RAM) et
des structures physiques (sur disque dur) et utilise des processus pour le
stockage des donnes en mmoire ou sur disque.
Lcriture sur disque nest effectue quen cas de ncessit et sous
conditions tandis que La mmoire est utilise autant que possible tant
donn que laccs mmoire est plus rapide que laccs disque (gain en
performances).
En cas de coupure lectrique, par exemple, Oracle saura bien faire la
rcupration si des donnes en mmoire, au moment de lincident, ne sont
Shabakkat 2010/2011
82

voix
pas crites sur disque. Cest la rcupration de linstance gre par le

processus SMON discut plus loin dans l'architecture Oracle.
Un chec dinstance ncessite une rcupration tandis quune dfaillance
physique (crash disque par exemple) ncessite une restauration suivie
dune rcupration.
Restauration et rcupration sont deux termes diffrents qui doivent tre
bien distingus. La restauration est faite partir de fichiers de sauvegarde
et la rcupration permet de rappliquer aux fichiers de donnes
restaurs, les modifications dj faites sur la base pour retrouver ltat
cohrent de la base de donnes avant incident.
Dans lexemple de la figure, la rcupration linstant t2, ncessite la

restauration de la dernire sauvegarde S1 disponible et la rimplmentation des modifications survenues dans lintervalle t1-t2.
Architecture Oracle 11g

Serveur de base de donnes
Pour intragir avec la base de donnes, les utilisateurs ont besoin de
comptes utilisateur et dune connexion rseau pour y accder. Ils doivent
galement disposer d'une capacit de stockage suffisante pour linsertion
de donnes.
Cest le schma courant de connexion une base de donnes Oracle en

mode client/serveur. Pour une connexion en mode 3-tiers, voici le
schma de connexion :
Shabakkat 2010/2011
83

voix
Composants du serveur Oracle

Le schma suivant prsente les principaux composants dun serveur
Oracle :
Ce schma peut paratre, premire vue, complexe. Toutefois, il n'est pas

du tout compliqu. Pour une parfaite comprhension, on va faire un zoom
progressif dans les sections qui suivent pour dcrire plus en dtail chacun
de ses composants.
Shabakkat 2010/2011
84

voix
Chaque nouveau terme introduit prmaturment dans une section du fait

de la forte corrlation des composants, sera trait plus en dtail dans les
sections qui suivent.
Connexion utilisateur la base de donnes

Deux processus permettent un utilisateur d'interagir avec l'instance et
finalement, avec la base de donnes : le processus utilisateur et le
processus serveur.
Chaque fois qu'un utilisateur excute une application, telle quune

application de gestion de ressources humaines, de gestion financire, ou
tout simplement une commande SQL , la machine client lance, au
pralable, un processus utilisateur pour tablir une connexion de
l'utilisateur l'instance Oracle.
Le processus dcoute Oracle Listener

Le processus dcoute Oracle listener est le principal composant Oracle
cot serveur qui permet d'tablir la connexion entre les ordinateurs clients
et une base de donnes Oracle. Le listener peut tre considr comme
une grande oreille qui coute les demandes de connexion aux services
Oracle.
Thoriquement, une machine serveur peut hberger plusieurs bases de
donnes Oracle et un listener et un seul pour permettre la connexion dun
client linstance Oracle de son choix. Le nom de linstance est soumis par
le client lors du processus de connexion (tape 1).
Deux cas sont possibles :
Shabakkat 2010/2011
85

voix
1. Un processus dcoute (Listener) peut servir plusieurs bases de

donnes configures sur une mme machine serveur,
2. Plusieurs listener peuvent tre configurs sur une mme machine (
des fins de basculement ou d'quilibre de charge pour supporter des
charges importantes de demandes de connexion).
Dans une configuration de serveur ddi, le Listener lance pour chaque
client un nouveau processus serveur et lui cde le contrle de la session
du client. Chaque connexion client est servie par son propre processus
serveur.
Le schma ci-dessus correspond une configuration serveur ddi et pour
une application client/serveur.
Le processus de connexion passe par les tapes suivantes :
1. Le client contacte le listenerOracle en choisissant linstance laquelle il
souhaite se connecter (demande dun nom de service).
2. Le listener dmarre un processus ddi appel processus serveur
3. Le listener envoie un accus de rception au client avec l'adresse du
processus serveur ddi
4. Le client tablit une connexion avec le processus serveur ddi
5. Le processus serveur se connecte l'instance Oracle pour le compte du
processus utilisateur (cration dune session utilisateur)
Cest le processu serveur qui se connecte l'instance Oracle pour servir le

processus utilisateur durant toute la session du client.
Le processus utilisateur n'entre pas directement en interaction avec le
serveur Oracle. C'est plutt, le processus serveur qui interagit avec le
serveur Oracle, rpond aux demandes de lutilisateur et lui renvoie les
rsultats.
Langage PL/SQL
PL/SQL est un langage procdural propre Oracle qui constitue une
extension au langage SQL (langage non procdural).
Shabakkat 2010/2011
86

voix
Des commandes SQL peuvent tre incorpores au sein dun code PL/SQL.
Ces commandes sont dites des Commandes SQL incorpores.
Le code PL/SQL peut tre utilis dans des units de programme stockes
dans la base de donnes tels que les procdures, fonctions, et packages
(groupes de procdures et fonctions). Ces units de programmes sont
dites stockes.
Si ces procdures ne sont pas stockes dans la base mais incorpores
dans une application (outils de dveloppement tel quOracle FORMS
DEVELOPER et Oracle REPORT DEVELOPER), elles sont dites des
procdures applicatives.
Le code PL/SQL incorpor dans une unit de programme applicative ou
stocke mais qui nest pas nomme est appel bloc anonyme. Un bloc
anonyme ne portant pas de nom, ne peut de ce fait tre stock dans la
base de donnes.
Lavantage dune unit de programmes stockes cest quelle peut tre
appele par son nom depuis votre code dapplication et Oracle stocke le
rsultat de lanalyse parse de lunit dans la base de donnes (stockage
persistant sur disque). Des gains considrables en termes de
performances sont gnrs du fait que le rsultat du parse est rendu
disponible et persistant pour les prochaines rutilisations du code de
lunit.
Larchitecture OBIEE Une plateforme unifie et complte

OBIEE Oracle Business Intelligence Suite Enterprise Edition - est une
suite complte de solutions BI qui offre une gamme complte danalyses
et de reporting.
OBIEE est une architecture BI moderne unifie et hautement
volutive (ETL, Entrept de donnes, Serveur danalyse OLAP et Tableaux
de Bords). Les avantages :
Une architecture BI sintgrant toutes les sources de donnes
grce ses ETL prconstruits pour lextraction et le chargement multisources de donnes oprationnelles (ETL, application, web, base de
donnes, fichiers plats, donnes XML et donnes non structures) ce qui
Shabakkat 2010/2011
87

voix
permet de sappuyer sur diffrentes sources de donnes et applications

rparties dans lentreprise.
Un entrept de donnes avec des modles de donnes
prconstruits (schmas en toiles) conus pour lanalyse et le reporting.
Une organisation de linformation prconstruite incluant les
calculs, les agrgations, les rpartitions et les indicateurs destins aux
dcideurs et aux utilisateurs de lapplication.
Une restitution de donnes riche avec une librairie dindicateurs, de
tableaux de bords interactifs, un systme de requtes et analyses et des
systmes dalertes destination des utilisateurs.
La Business Intelligence pour tous, car OBIEE et sa restitution de
donnes sadresse chacun dans lentreprise en donnant un aperu
pertinent chacun. Tous les niveaux de lorganisation de lentreprise
peuvent consulter les informations optimises pour elles. Lintgration
avec MS Office rend son utilisation encore plus performante.
Une plateforme robuste, OBIEE prend en charge de gros volumes de
donnes et offre la possibilit de travailler en mode dconnect.
OBIEE concentre au sein de son architecture les mtadonnes de
lentreprise, du back-office jusquau front-office. En choisissant une
application de la suite Oracle Business Intelligence Applications - OBI
Apps vous bnficiez d'une solution de BI pr-paramtre cible pour les
diffrents mtiers de lentreprise.
Architecture et composanntde OBIEE :
Shabakkat 2010/2011
88

voix
Les composants de ORACLE BI FOUNDATION sont :
Oracle Interactive Dashboards
Oracle Answers
Oracle BI Reporting and Publishing
Oracle DisconnectedAnalytics
Oracle Office Plug-in
Oracle BI Server
Oracle Business Indicators (iTunes)
Shabakkat 2010/2011
89

voix
Les applications de OBIEE :
Oracle Financial Analytics

Oracle HumanResourcesAnalytics
Oracle LoyaltyAnalytics
Oracle Price Analytics
Oracle Project Analytics
Oracle Procurement and SpendAnalytics
Oracle Sales Analytics
Oracle Service Analytics
Oracle Supply Chain and Order Management Analytics
Oracle Contact Center Analytics
Oracle Marketing Analytics
Oracle US Federal Financial Analytics
Shabakkat 2010/2011
90

voix
BIBLIOGRAPHIE :
(1) Revenue Assurance: A competitive edge : TATA Consultancy
services ,2009
(2) Revenue Assurance Tlcommunications : cultiver la
croissance de vos revenus : Deloitte
(3) Revenue Assurance: Whose Responsibility Is It? : ACCENTURE,
2011
(4) The Telco Revenue Assurance Handbook: R. Mattisson : XiT Press,
Oakwood Hills,2005.
(5) Etude de larchitecture Revenus Assurance et choix de
solutions adaptes Meditel : INPT
(6) Documentation Officielle ORACLE 11g : ORACLE, 2011
(7) DITTBERNER Associates, Inc. Revenue Assurance & Cost
Management Market;
Dittberner; Juin 2005
(8) De-Mystifying OBIEE / Oracle Business Intelligent
Applications : Shyam Varan Nath : IBM
(9) Cours de BUSINESS INTELLIGENCE : Pr. OUBRICH Mourad, INPT,
2011
(10) Business Intelligence avec Oracle 11g: Claire Noirault, Ellipse
(11) SQL pour ORACLE :Chistian SOUTOU,Eyrolls
(12) Logic for programming, artificial intelligence : Andrei Voronkov
, Springer , 2005
(13) Oracle Bi Enterprise Edition Dashboard & Report Best
Practices : Amy Mayer, Kevin McGinley, Bi Consulting Group
Shabakkat 2010/2011
91

voix
WEBOGRAPHIE :
(14) TM Forum:
http://www.tmforum.org/browse.aspx
(15) BILLING: Revenue Leakage:

(16)Telecom Biling tutorial:
billing/
http://voicendata.ciol.com
http://www.tutorialspoint.com/telecom-
(17) Site de luniversit de Marne-la-Valle :

mlv.fr/~dr/xall.php
http://igm.univ-
(18) Le portail francophone du pilotage de la performance :

http://www.piloter.org
(19) Tutoriel ANALYTICAL WORKSPACE MANAGER:
http://download.oracle.com/docs/
(20) Tutoriel OBIEE : http://st-curriculum.oracle.com/obe
(21) Service Level Corporation:
http://www.servicelevel.net/rating_matters/matterslist.htm
(31)Site officiel de loprateur
Shabakkat 2010/2011
92

Rapport Projet de Fin D'etudes Shabakkat

Transféré par

Droits d'auteur :

Formats disponibles

Rapport Projet de Fin D'etudes Shabakkat

Transféré par

Informations du document

Description originale:

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

Rapport Projet de Fin D'etudes Shabakkat

Transféré par

Droits d'auteur :

Formats disponibles

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Mise en uvre doutils

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Table des matires

Chapitre 1 : Revenu Assurance.............................................................................. 9

Le monde du Revenu Assurance :.........................................................10

Revenu Assurance et tlcommunications :...............................................15

Chapitre 2 : Les systmes de facturation ou Billing systems................................19

II. Mthodes de programmation pour la facturation :...........................28

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Chapitre 3 : La Business Intelligence....................................................................39

Introduction la Business Intelligence :.............................................40

II. Cube OLAP et analyse multidimensionnelle :.....................................47

Construction du cube OLAP :.............................................................53

Gnration des rapports multidimensionnelle :.............................60

1. Cration des mtadonnes OBIEE pour le cube OLAP :................60

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

internationaux, souvent associs des services complexes.

mouvant et difficile matriser, surviennent de plus en plus de fraudes.

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

d'information soutenant ces processus. Puis y remdier avec des solutions

surtout, la mise en uvre d'actions palliatives et correctives vitant leur

pouvoir traiter le nombre important de

donnes, avoir une vue globale et pouvoir dtecter l o il y a le plus de

Intelligence, ensuite expliquera les tapes de sa concrtisation

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Figure 1-1: Prsence de Shabakkat dans le monde

Figure 1-2 : Structure de lorganisation de Shabakkat

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Les diffrents services proposs par Shabakkat sont :

lensemble des mtiers relatifs au gnie civil, soit linfrastructure rseau.

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Figure 1-3 : Diagramme de GANTT illustrant les tapes de notre projet

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Ce premier chapitre nous permettra dapprhender le monde du

Le monde du Revenu Assurance :

peut avoir plusieurs dfinitions, mais toutes peuvent se rejoindre dans le

Zakaria BOUATAYA, Anass CHIKI

Mise en uvre doutils dcisionnels pour le contrle de la tarification des appels

Ceci dans la perspective daugmenter le profit en optimisant les

ralisation des trois actions suivantes :

Figure 1 : les niveaux de maturit du revenue assurance (ref )