Gestione TLC - torvergatabook

UNIVERSITÀ DEGLI STUDI DI ROMA
TOR VERGATA
CORSO DI LAUREA IN INGEGNERIA DELLE TELECOMUNICAZIONI
GESTIONE di SISTEMI & SERVIZI
di TELECOMUNICAZIONE
(Parte I)
Pietro de Santis
LEG - REG
ST&E
BUSINESS
SOCIAL
Anno Accademico 2008-2009
Commento:
2
FUNDAMENTALS
of
TLC MANAGEMENT
Pietro de Santis
3
A Francesco Valdoni, che non ha fatto a tempo a vedere queste
mie note……….
Business in ICMT Engineering Education
“Preparing Engineers for a digital economy”
ICMT
BUSINESS
ICMT in Business Education
“Preparing Executives to use digital technologies”
Bus Eng Relòation
4
Si presenta qui di seguito il materiale didattico preparato dal Prof.
Pietro de Santis per le lezioni/ esercitazioni del corso di “Gestione Sistemi &
Servizi di Telecomunicazione” (GST) insegnato nel periodo SettembreNovembre 2008 dell’Anno Accademico 2008-2009 presso l’Università di
Roma-Tor Vergata. Parte di questo materiale è stato distribuito agli
studenti sotto forma di “Dispense”. Il corso di “Gestione Sistemi & Servizi
di Telecomunicazione” ha una durata di 2 (ore/giorno) x 3 (giorni/settimana) x
4 (settimane/mese) x 2 mesi = 48 ore di insegnamento. Esso è diviso in due
parti. La prima parte si occupa dei concetti fondamentali che sono alla base
della gestione dei Sistemi e dei Servizi TLC mentre la seconda parte studia in
dettaglio i modelli gestionali standardizzati per reti e elementi di rete TLC e.g.
modelli OSI-SM, TMN, SNMP emessi come standards de jure da enti di
standardizzazione internazionali. Le ampie Appendici al Capitolo 1 riportano
materiale di riferimento utilizzato per approfondimenti e esercitazioni mentre
un Addendum finale contiene materiale “for further reading” (Appendici e
Addendum non fanno parte del programma ufficiale del corso).
PS. Notare che il materiale didattico si riferisce a “Sistemi & Servizi TLC” e
non ai soli “Sistemi TLC” come annunciato nel nome ufficiale del corso. Qui
continueremo ad usare l’acronimo GST ma attribuiremo ad esso il
significato di “Gestione di Sistemi & Servizi TLC”.
5
6
GESTIONE di SISTEMI & SERVIZI
di TELECOMUNICAZIONE
PARTE PRIMA
INTRODUZIONE alla GESTIONE di
SISTEMI & SERVIZI TLC
Durata: 24h (6h/settimana x 4 settimane)
Capitolo 1
Gestione TLC & Interdisciplinarietà (10h)
Capitolo 2
Ambiente Engineering: gestione delle
Tecnologie ICT (6h)
Capitolo 3
Standards gestionali ITU-T: introduzione
(4h)
Capitolo 4
Ambiente Business: gestione dei servizi TLC (4h)
7
CAPITOLO 1
Gestione TLC & Interdisciplinarietà (10 h)
PREMESSA: Definizione del termine “Telecomunicazione”
1.0
Stakeholders, sistemi, servizi e mercati TLC (2h)
1.0.1
1.0.2
1.0.3
1.0.4
1.1
TLC Stakeholders e loro interazioni (mercati TLC)
Sistemi TLC
Servizi & Prodotti TLC
Esercizi
“Gestione TLC”: la gestione integrata di sistemi e servizi TLC per
un “Customer Oriented TLC Business” (2h)
1.1.1 Cosa significa gestire sistemi e servizi TLC? Un modello concettuale
1.1.2 Gestione dinamica e cambiamenti esterni: la gestione “per processi” all’ interno di una
TelCo
1.1.3 Le “dimensioni” della Gestione TLC: tipologie di modelli gestionali
1.1.4 Valenza economica della gestione
1.1.5 Esercizi
1.2
La gestione di sistemi e servizi TLC: concetti generali (3h)
1.2.1 Decomposizione funzionale di un servizio TLC in parte gestionale e parte gestita
(“service core” o “essenza del servizio”)
1.2.2 Funzionalità U&S e funzionalità gestionali all’interno di un servizio TLC
1.2.3 Sistema TLC e gestione di un sistema TLC
1.2.4 Sistemi di Supporto per la gestione di sistemi e servizi TLC
1.2.5 Integrazione dei sistemi di gestione (Rete di Gestione) di una TelCo
1.2.6 Convenzionalità della gestione e dei modelli gestionali: enti di standardizzazione
1.2.7 Modelli standardizzati generici o specifici
1.2.8 Conclusione
1.2.9 Esercizi
1.3
“Gestione TLC” & formazione interdisciplinare (2h)
1.3.1
1.3.2
1.3.3
1.3.4
1.4
Ordinamento gerarchico delle gestioni locali in una TelCo
“Product Development”: interdisciplinarietà Engineering-Business
Il mondo del lavoro post-lauream: teams di lavoro integrati
Elementi di integrazione: extraconoscenza interdisciplinare “Engineering-Business”
La storia della “Gestione TLC” non si ripete: da “bottom up”
(1968) a “top-down” (2008).
1.4.1
1.4.2
1.4.3
1.4.4
La gestione delle tecnologie: reti TLC e loro elementi
La gestione dei servizi TLC
La Gestione con la G maiuscola
Tecnologie gestionali DOC (Distributed Object Computing)
8
1.4.5
1.4.6
1.4.7
1.4.8
La Gestione in un macroambiente sociale e naturale
La gestione di impresa e il ruolo della Responsabilità Sociale di Impresa in una TelCo
Bibliografia Capitolo 1
Esercizi
MATERIALE DIDATTICO AUSILIARIO
Appendice 1.
Il “libero mercato” delle telecomunicazioni: considerazioni storiche
Appendice 2.
Gli oggetti gestiti contenuti nella MIB della Fig.1.3.1
Appendice 3.
La “gestione di impresa” in una TelCo (modello e-TOM del
TeleManagement Forum/ITU-T)
Appendice 4. Interdisciplinarietà “completa” in una TelCo: la metodologia dei Punti di
Vista
Appendice 5. Interdisciplinarietà: “cross-fertilizzazione” di conoscenze con
produzione di extra-conoscenze
Appendice 6. Elementi di “Marketing” per ingegneri TLC: beni, servizi e processi
TLC.
Appendice 7. Elementi di “Organizzazione Aziendale”per ingegneri TLC: la vista
interna di una impresa “Telco”
9
10
CAPITOLO 1
Gestione TLC & Interdisciplinarietà
PREMESSA No.1:
Definizione del termine “telecomunicazione”
In questo corso il termine «telecomunicazione» ha il significato, del tutto generico,
di una comunicazione a distanza nella quale l’informazione, generata e raccolta da
apparecchiature terminali denominate rispettivamente “sorgente” e “destinatario” è
generata, trasferita, trattata, archiviata, e utilizzata sottoforma di segnali elettrici secondo le
seguenti modalità,
1) trasferita tramite mezzi di trasporto elettromagnetici “man made” (“mezzi
elettromagnetici”), cioè tramite campi elettromagnetici creati dall’uomo con lo scopo di
trasportare informazione che si propagano “lungo” mezzi fisici o in spazio libero
(atmosfera, vuoto). I primi sono anche denominati mezzi elettromagnetici “wireline” o
“landline” o “mezzi di propagazione elettromagnetica guidata”. Essi sono supportati da
mezzi fisici come linee elettriche in rame, cavi coassiali, guide d’onda, fibre ottiche etc. I
secondi sono anche denominati mezzi elettromagnetici “wireless” o “mezzi di
propagazione elettromagnetica libera”. Esempi sono: ponti radio, tratte satellitari,
collegamenti radio cellulari terrestri, collegamenti Wi-Fi etc
2) elaborata/immagazzinata da “apparati o apparecchiature di rete” (network
devices) e.g. autocommutatori, multiplexers, routers, hubs, bridges, satelliti, ripetitori
terrestri, database etc. e
3) generata, elaborata/immagazzinata o utilizzata
da “apparecchiature
terminali” e.g. telefoni, fax, computers, apparecchi radio, televisori etc. che interfacciano
da un lato con la rete di accresdso e dall’altro con esseri umani sorgenti/collettori di
informazione (e.g. persone fisiche che fruiscono dei servizi TLC).
In questo corso tecnologie elettroniche o fotoniche per la trasmissione
(transmission), elaborazione (processing) e immagazzinamento (storage) dell’ informazione
digitale nell’ambito delle telecomunicazioni sono denominate Tecnologie ICT (Information
& Communications Technology)
NOTA P.1 SIGNIFICATO DELLA PAROLA “MEDIUM” . La parola “medium“ può significare due
cose diverse: 1) “canale di trasporto dei contenuti” nel senso di “mezzo di trasporto” (vedi A nella
Tavola 4.3.1.1) oppure 2) “contenuto da distribuire per via radio-TV” nel senso di “programma radioTV” (vedi B nella Tavola 4.3.1.1). Ad esempio, si parla di una industria TMT (Tecnologia, Media,
Telecomunicazioni) per indicare le industrie coinvolte nella produzione/fornitura di tecnologie/servizi di
Mobile TV i.e servizi TV su telefonini che funzionano contemporaneamente da computer, televisore
radio e telefono. Si parla anche di tecnologie IMC (IMC = Information, Media, Communication) o
IMCT per indicare tecnologie integrate (qui va di moda la parola “convergenti”!) che abilitano servizi
internet (Information) servizi radio-televisivi (Media) e servizi telefonici (Communications).
11
NOTA P.1
Differenza fra “Comunicazione” e “Telecomunicazione”
I termini “telecomunicazione” e “comunicazione” hanno in comune la lunga sequenza alfabetica “c-o-m-u-n-ic-a-z-i-o-n-e”. Questa ampia condivisione di lettere talvolta induce nell’errore di ritenere che i loro significati
siano anche essi molto simili. Ma questo non è vero. Per noi “telecomunicazione” e “comunicazione” non solo
hanno significati diversi ma rappresentano conoscenze sviluppate e accudite in aree disciplinari/culturali
molto diverse. In particolare in questo corso la “comunicazione”, nel senso di “mettere in comune
informazione”, ha una connotazione del tutto generale con implicazioni socio-economiche (e.g. come nel caso
di “comunicazioni sociali”, “comunicazioni di massa”) mentre la “telecomunicazione” ha una connotazione
più specifica e più tecnica, facendo essa riferimento al trasferimento di informazione con opportune tecnologie
(e.g. come nel caso di telecomunicazione per via radio-televisiva, internet, telefonica). Quindi allorché si
parla di “telecomunicazione” si fa riferimento ad un particolare tipo di comunicazione che richiede sempre
l’utilizzo, seppur parziale, di una portante elettromagnetica man-made cioè un campo elettromagnetico di
una certa frequenza creato dall’uomo tramite opportune apparecchiature e.g. tramite un oscillatore RF +
amplificatore, e successivamente modulato con un segnale che contiene l’informazione che si vuole trasferire
(per diffusione o interconnessione). Quindi in questo corso la “telecomunicazione” esclude: 1) il trasporto di
informazione su portante elettromagnetica generata direttamente da sorgenti naturali e.g. segnali radio emessi
da sorgenti naturali come in astronomia o remote sensing 2) telecomunicazioni basate sull’ uso esclusivo di
mezzi di trasporto dell’informazione non-elettromagnetici come mezzi acustici o sonori (e.g. sistemi sonar per
comunicazioni subacquee), mezzi materiali come libri, riviste giornali, memorie elettroniche (e.g. DVD),
pellicole cinematografiche, trasferiti con mezzi di trasporto aerei o auto-ferroviari. In base a queste
considerazioni si riconosce che la “telecomunicazione” è talvolta visto come un sottoinsieme o, se si vuole,
una specializzazione della “comunicazione”. E, ahimè, purtroppo questo fatto può avere conseguenze nefaste!
Può far sì che alcuni “esperti in comunicazione”, pur privi di una qualsiasi base conoscitiva in tecniche e
tecnologie di telecomunicazione, si improvvisino “telecomunicazionari” e non solo discettino di
“telecomunicazione” ma giochino ruoli dominanti anche in imprese di “telecomunicazione”!
NOTA P.2
Telecomunicazioni ibride
Fanno parte delle telecomunicazioni studiate in questo corso anche le “telecomunicazioni ibride”
realizzate congiuntamente con portante elettromagnetica man-made e mezzi di trasporto non-elettromagnetici
e.g. rete postale. Ad esempio nei servizi di “vendita on-line” (e-commerce) si usano mezzi elettromagnetici
(internet) per consultare cataloghi e ordinare la merce dal sito del venditore desiderato mentre si usano mezzi
meccanici (servizio pacchi postali) per trasportare la merce dal magazzino del fornitore alla sede del
destinatario. Per le telecomunicazioni ibride è necessario che una impresa, in generale non-specifica delle
telecomunicazioni, produttrice di beni materiali e.g. un venditore di libri, collabori con una Telco fornitrice di
servizi TLC (tuttavia questa collaborazione è trasparente agli occhi del Cliente). In tal caso il bene materiale
fornito costituisce il “contenuto” di un “servizio ibrido” nel quale il servizio TLC ha una mera funzionalità
ancillare e.g. piazzamento di un ordine. Per il cliente di un servizio ibrido il “valore” risiede nel “contenuto”
del servizio (e.g. un alto “valore” di un servizio di e-bookstore è legato ad una consegna pronta e accurata del
libro desiderato fornito a un prezzo conveniente). Considerazioni analoghe valgono per scenari in cui il
contenuto del servizio denominato “ibrido” non è un “bene materiale” bensì un “servizio” in generale
nonTLC, fornito tramite una TelCo che fornisce il contenitore/veicolo (“servizio nel servizio TLC”). Ad
esempio nei servizi di tele-medicina o tele-educazione il fornitore del contenuto del servizio ibrido è un
ospedale o una università che collabora con una TelCo. In questo caso i “servizi ibridi” sono denominati “teleservizi” proprio perché sono servizi nonTLC contenuti in servizi TLC (vedi anche Capitolo 4)
12
PREMESSA No.2:
Definizione dei termini “Engineering” e “Business”
In questo corso parleremo di interdisciplinarietà “Engineering-Business” (con la E
e la B maiuscola) e Punti di Vista Engineering e Business facendo riferimento alle aree
conoscitive “Engineerng” e “Business” definite nel par. 1.3. Per capire bene il significato
dei termini “Punto di Vista” e “Interdisciplinarietà” si consiglia la lettura delle Appendici 4
e 5 al Cap.1. Per comodità anticipiamo qui sotto la Tavola 1.3.1.2 che definisce i termini
“Engineering” e “Business”.
“Engineering” (con la E maiuscola) significa “Engineering delle telecomunicazioni”,
telecomunicazioni”, un mix di quattro discipline tradizionali:
“Ingegneria Informatica – Ingegneria gestionale - Ingegneria Elettronica - Ingegneria delle Telecomunicazioni”, le prime tre solo per la parte
direttamente rilevante a sistemi e servizi TLC. Per “ingegneria” noi adottiamo la seguente definizione “ingegneria è la professione in cui la conoscenza
discernimento
nto per
delle scienze matematiche e naturali (e.g. fisica, chimica) acquisita attraverso lo studio, l’esperienza e la pratica, viene applicata con discernime
sviluppare nuovi sistemi che utilizzano economicamente le risorse della natura a beneficio dell’umanità”. Nel “modello interdisciplinare completo” da noi
adottato (Vedi Appendice 4 al Capitolo 1) le conoscenze di “Engineering” in effetti sono solo parte di una più vasta area conoscitiva di natura tecnicotecnicoscientifica identificata come TLC “Science, Engineering & Technology, SE&T” (Vedi Tavola A.4.1).
A.4.1).
“Business” (con la B maiuscola) significa “Business delle telecomunicazioni”,
telecomunicazioni”, un mix di conoscenze
conoscenze derivate dalle quattro discipline
tradizionali di Economia & Commercio, Scienze della Finanza, Marketing e Gestione di impresa, specializzate alle telecomunicazioni, laddove
“economia” a livello microeconomico è “la scienza che studia le modalità di allocazione di risorse limitate tra usi alternativi al fine di massimizzare la
soddisfazione degli utilizzatori” mentre a livello macroeconomico è la disciplina che si occupa di produzione, consumi, occupazione e prezzi nei mercati a
livello nazionale e internazionale;
internazionale; “finanza” è “la disciplina che studia i processi con cui persone fisiche o giuridiche, pubbliche o private, gestiscono i
flussi monetari nel tempo (raccolta, allocazione, usi) e “marketing” è un ramo delle scienze economiche che “si occupa dello studio descrittivo del
mercato e dell’analisi dell’interazione del mercato e degli utilizzatori con l’impresa”. A livello universitario il “Business delle Telecomunicazioni” è una
corsi
specializzazione alle Telecomunicazioni delle materie insegnate nei co
rsi di “Master in Business Administration” (MBA). Durante il corso di GST il
termine “Business” è usato con diversi significati e.g. “rapporto di business “ = rapporto commerciale, “processo di business” = processo aziendale,
“utenza business” = utenza affari.
affari. “obiettivo di business” = obiettivo aziendale. In molti casi useremo direttamente il termine “business” senza tentare
di tradurlo e.g. useremo le espressioni inglesi “business model”, “business plan” etc.
Tavola 1.3.1.2
In un contesto operativo il Punto di Vista “Engineering” è supportato da un team integrato di ingegneri
con competenze professionali nelle quattro componenti dell’area “Engineering” mentre il Punto di Vista
“Business” è supportato da un team integrato di businessmen esperti nelle quattro componenti dell’ area
“Business”. L’approccio interdisciplinare è supportato da un team integrato “Engineering” – “Business” (un
team di teams!) i cui membri condividono un modello informativo (“vocabolario”) comune. Un esempio di
modello informativo condiviso “Engineering” – “Business” è stato recentemente standardizzato dall’ITU-T
(vedi: “ITU-T Recommendation M.3190, “Shared Information & Data Model”, 07/2008”) ed è mostrato nella
Tavola P2.1 In questa tavola i termini individuano concetti utilizzati nei processi di business di una impresa
fornitrice di servizi TLC e sono definiti in maniera implementation-independent e comprensibile sia a
ingegneri che businessmen. A differenza di modelli “multidisciplinari” questo modello contiene
“extraconoscenze” interdisciplinari, create da una cross-fertilizzazione virtuosa di “Engineering” e
“Business”! (vedi Appendice 5 al Cap.1)
1. Market / Sales (7)
Market Strategy & Plan
Market Segment
Marketing Campaign
Contact / Lead / Prospect
Competitor
Sales Statistic
2. Product (6)
Product
Product Specification
Strategic Product
Portfolio Plan
Product Offering
Product Performance
Product Usage Statistic
13
Sales Channel
3. Customer (10)
Customer
Customer Order
Customer Interaction
Customer Statistic
Customer Problem
Applied Customer
Billing Rate
Customer SLA
Customer Bill
Customer Bill Collection
Customer Bill Inquiry
4. Service (9)
Service
Service Applications
Service Specification
Service Configuration
Service Performance
Service Strategy & Plan
Service Usage
Service Trouble
Resource Performance
Resource Strategy & Plan
Service Test
5. Resource (9)
Resource
Resource Specification
Resource Topology
Resource Configuration
Resource Usage
Resource Trouble
Resource Test
6. Supplier / Partner (12)
Supplier/Partner
S/P Plan
7. Enterprise
Under
S/P Interaction
S/P Product
S/P Order
S/P SLA
S/P Performance
S/P Bill
S/P Problem
S/P Bill Inquiry
S/P Statistics
S/P Payment
8. Common Business (5)
Party
Business Interaction
Construction
Location
Policy
Agreement
Tavola P2.1 Modello informativo SID del TMF/ITU-T. Entità di livello 1 in raggruppamenti di livello zero
1.0 TLC stakeholders, sistemi e servizi TLC
Significato dei termini & condivisione di linguaggio nel corso GST
Quale è il modo migliore per iniziare un corso di GST di natura interdisciplinare
Engineering-Business? Il significato di “interdisciplinarietà” è definito nell’ Appendice 5 al
Capitolo 1 mentre i termini “Engineering” e “Business”, con le iniziali maiuscole, sono
definiti nella “Premessa” al corso.
14
Da buoni ingegneri, e seguendo ciò che viene comunemente fatto in testi tecnici
similari, noi riteniamo che il miglior modo per iniziare il nostro corso sia la spiegazione dei
termini principali che useremo nel prosieguo delle lezioni. In un contesto interdisciplinare è
importante introdurre termini ad alto contenuto semantico (i.e. di significato “generico” o
definiti ad un alto “livello di astrazione”) che identificano i “concetti” fondamentali su cui si
basa il corso di GST.
Seguendo i principi enunciati in quella moderna forma di analisi di sistema che va
sotto il nome di “Information Modeling”
A questo proposito si consiglia la lettura dell’ aureo libretto; M.Flavin “Fundamental Concepts of Information
Modeling”, Yourdon Press, 1981 (copie a disposizione degli studenti presso il Prof. De Santis)
e per identificare la portata del nostro compito didattico definiamo subito la parte del mondo
TLC di interesse nel corso di GST cioè definiamo il la realtà che vogliamo studiare (“target
information domain” o “target problem domain”, dominio informativo target). Questo
ci permette anche di identificare le principali entità reali in esso contenute e le loro mutue
relazioni.
L’oggetto di studio del corso di GST! (Target Information
Domain)
Un ambiente socio-economico-commerciale dove persone fisiche e
giuridiche (“TLC stakeholders”) producono, gestiscono e utilizzano
reti e terminali TLC (“sistemi TLC”) per erogare/fruire di “servizi
TLC” in maniera “efficace/efficiente”
Allora appare evidente che inizieremo il nostro corso di GST definendo i termini
qui sottolineati. Essi descrivono entità reali “tangibili” (stakeholder, sistema) e “intangibili”
(servizi). Saranno definizioni comprensibili, condivisibili e quindi utilizzabili da esperti
con competenze professionali sia Business che Engineering. Con un linguaggio un po’ più
sofisticato possiamo anche dire che, in accordo con la Raccomandazione ITU-T M.3190
del 07/2008, il nostro corso si basa su un “modello informativo” che vuole essere “un
ponte fra gruppi di lavoro “business” e gruppi di lavoro “IT” in quanto offre “una
terminologia comprensibile ai primi ma al tempo stesso sufficientemente rigorosa da poter
essere usata dai secondi per sviluppare sistemi informatici per la gestione di sistemi e
servizi TLC”. Allora i termini che spiegheremo nei prossimi paragrafi sono :
1. “TLC Stakeholder” (TelCo,TelCo Partner, ICT Supplier,Content Provider,
Utente)
2. “Sistema TLC” (Risorsa TLC, Tecnologia ICT)
3. “Servizio TLC” (Servizio TLC, Prodotto TLC)
15
Ciò sarà fatto nelle prossime sezioni 1.0.1, 1.0.2 e 1.0.3. Un ultimo concetto che
definiremo nel par.1.1 è “Gestione TLC” (TLC Management). Vedremo che esso si
nasconde nell’espressione “efficace/efficiente” precedentemente introdotta.
In questo nostro sforzo di ricerca di un linguaggio condiviso in un contesto TLC
interdisciplinare ci ispireremo a iniziative recenti intraprese da vari enti di standardizzazione
e, più di ogni altro, dal TeleManagement Forum (TMF) consorzio internazionale non-profit a
cui tutt’oggi partecipano gran parte degli operatori del settore TLC. In particolare l’iniziativa
NGOSS (Next Generation Operations Systems and Software) del TMF mirata allo
sviluppo di software gestionale integrato, nella quale uno dei componenti più importanti della
suite di modelli proposti è il modello “SID Model” (Shared Information & Data Model).
Si tratta di un modello informativo che offre un linguaggio condiviso (“shared”) finalizzato
all’integrazione di applicativi “loosely coupled” in un sistema informatico per la gestione di
reti e servizi TLC (Vedere, ITU-T Recommendation M.3190, “Shared Information & Data
Model”, 07/2008, vedere anche Tavola P2.1).
1.0.1 TLC Stakeholders e loro interazioni (mercati TLC)
1.0.1.1
L’ uomo ha bisogno di comunicare e collaborare in tempo reale con altri uomini
residenti in sedi comunque remote
L’uomo è la misura di tutte le cose. Ogni attività umana é finalizzata al
raggiungimento di un fine e il suo valore è tanto più alto quanto più il fine è atto a soddisfare i
bisogni/desideri dell’uomo e a migliorare la sua qualità di vita. Ci sono bisogni umani
fondamentali strettamente personali come avere un alloggio, nutrirsi, vestirsi (come mostra la
“piramide di Maslow” ben nota ai cultori di marketing). Poi ci sono bisogni di natura sociale
o commerciale non fondamentali ma tuttavia altrettanto importanti. Fra questi c’é il bisogno
di comunicazione e di collaborazione fra persone (umane o giuridiche).
NOTA 1.0.1.1
Per “persona giuridica” intendiamo una organizzazione economica con identità e
titolarietà giuridica che le permette di “stipulare accordi contrattuali e di chiedere il rispetto di tali
accordi di fronte ad un tribunale” laddove una “organizzazione economica” è una “entità astratta
all’interno della quale e attraverso la quale persone interagiscno al fine di raggiungere obiettivi
individuali e collettivi” (P. Milgrom & J.Roberts, “Economia, Organizzazione e Management” Vol.I, il
Mulino, 1994, p.45).
Ogni persona oggi vuole
avere la capacità conoscitiva/abilità fisica
di
trasmettere/ricevere informazione i.e. “comunicare”, sia in tempo reale (e.g. telefonia,
videoconferencing) che in tempo differito (e.g. e-mail, SMS, fax) con altre persone residenti
in sedi comunque remote e/o ricevere informazione di varia natura (notizie, intrattenimento,
educazione etc.) prodotta e distribuita da centri di produzione & distribuzione appositamente
creati e.g. centri di diffusione radio-televisiva, siti internet etc. Inoltre, in un contesto
economico e in una società della conoscenza come quella in cui noi tutti oggi viviamo, ogni
persona opera al meglio allorchè svolge un lavoro specializzato. Tuttavia essa vuole anche
affrontare e risolvere problemi vasti e complessi che richiedono il contributo di più
competenze professioinali. In queste circostanze una persona fisica o giuridica sente anche il
bisogno di “collaborare” sia in tempo reale che in tempo differito, con altre persone
16
specializzate in discipline diverse per ottenere risultati comuni ottimali (e.g. individui
cooperanti in teams di lavoro e imprese relazionate commercialmente in “value networks”).
Oggi esistono vari mezzi di comunicazione e di collaborazione fra persone fisiche e
giuridiche che permettono di soddisfare queste esigenze. Un contributo fondamentale alle
comunicazioni in tempo reale fra persone ubicate in siti diversi comunque remoti viene dato
dal trasferimento di informazione tramite “mezzi elettromagnetici”. In questo definiamo
“telecomunicazione” un tipo particolare di
“comunicazione” effettuata con “mezzi
elettromagnetici” i.e. mezzi di trasporto elettromegnetici man-made.
TLC STAKEHOLDER HIERARCHY (*)
TLC Stakeholder
“is a”
TLC Service Company
“is a”
TLC Service
Retailer
IC Technology Vendor
“is a”
TLS Service
Wholesaler
TLC Service
Intermediary
Customer
“is a”
ICT Retailer
ICT Wholesaler
End Customer
(*) Vedi Appendice 4 al Capitolo 1
Bus Eng Relation
Fig.1.0.1.1 Esempio di specializzazione di un TLC Stakeholder
La specializzazione (aggiunta di caratteristiche) può essere continuata verso
il basso in modo ricorsivo i.e. un elemento di un certo livello è specializzato
in un insieme di elementi situati a un livello gerarchico sottostante.
La coniugazione di “digitalizzazione” (dei contenuti informativi di prodotti
materiali) e “telecomunicazione” hanno poi abilitato anche la “collaborazione” fra attori
remoti. Più precisamente, si tratta di effettuare 1) digitalizzazione (Analog-to-Digital
conversion) di “contenuti informativi” analogici immagazzinati nei supporti fisici dei
prodotti materiali da scambiare/utilizzare nel corso di una “collaborazione” e.g. documenti,
disegni, stampe (di natura privata o pubblica come libri, giornali, riviste), registrazioni
sonore (CD’s, DVD’s, memorie digitali), fotografie, films etc. 2) messa in rete dei dati
binari ottenuti 3) susseguente processo inverso di recupero (resa) del formato analogico
tramite Digital–to-Analog Conversion al momento della ricezione dei dati trasmessi. La
velocità luminosa del mezzo elettromagnetico rende poi possibile una collaborazione
interattiva in tempo reale fra attori remoti, rendendola praticamente indipendente dalla
distanza di separazione (e.g. “remote-working”
in grandi imprese con strutture
organizzative reticolari distribuite su base globale).
17
La capacità conoscitiva/abilità fisica di svolgere “funzioni TLC” è da noi
denominata “funzionalità TLC” (in inglese, “TLC capability”) laddove “funzione TLC”
è un “insieme coerente di attività tese al raggiungimento di uno scopo TLC predeterminato
entro un dato tempo” (vedere Tavola 1.0.3.3.1). Tutti noi desideriamo/abbiamo bisogno di
possedere funzionalità TLC e di poterle attuare (mettere in atto) nello svolgimento di
funzioni TLC allorchè necessario o desiderato, con la saggia consapevolezza che ciò è
possibile sole se certe condizioni di attuazione esterne sono di volta in volta verificate
e.g. tutti noi sappiamo che, sebbene abbonati alla TV satellitare, non possiamo vedere un
programma TV se un temporale blocca il downlink dal satellite alla nostra antenna
parabolica e che, sebbene in possesso di un autoradio, non possiamo utilizzarla se la galleria
in cui stiamo transitando attenua troppo i segnali radio in ricezione (vedi anche 1.0.3.1).
ATTENZIONE AL LESSICO! La parola inglese “Capability”, come “Business”, “Stakeholder” e
“Management”, è intraducibile in Italiano con una sola parola. Ma se si interpreta “Capability” come crasi dei
due termini “Capacity” e “Ability” allora essa è traducibile in Italiano con il binomio “Capacità/Abilità”.
Notare che avviene il contrario con la parola Italiana “Utente” che non è traducibile in Inglese con una sola
parola. Ma se si interpreta il termine “Utente” come crasi di “Utilizzatore” e “Cliente” allora esso è traducibile
in Inglese con il binomio “Customer/User”. Quindi, le traduzioni Inglese-Italiano da noi adottate sono:
Capability Capacità/Abilità
Customer/User
Utente
Customer/End User Utente Finale
Fra poco spiegheremo il significato esatto dei termini Italiani.
1.0.1.2 TLC Stakeholders & Attori TLC
“Stakeholder” è un termine ad alto contenuto semantico. Fino a qualche anno fa era
poco diffuso nell’ ambito della Ingegneria TLC ma ampiamente usato in altre discipline e.g.
Ingegneria Gestionale, Organizzazione Aziendale, Scienze Sociali (e.g. vedi U.Bertelè et al.
“Creare valore con la rete”, Il Sole 24 ORE S.p.a, 2002 oppure S.Frova, “TLC e
Convergenza: Il cammino accidentato della crescita”, ANIE, 2006, pag. 36). Recentemente
ha riacquistato popolarità anche nell’Ingegneria TLC.
NOTA 1.0.1.2 Il termine “stakeholder” nell’Ingegneria TLC fu ampiamente usato negli anni 90 nei
documenti ufficiali del consorzio internazionale TINA, Telecommunications and Information Network
Architecture Consortium, ora disciolto. Per l’uso odierno di questo termine nell’Ingegneria TLC vedi
anche A.4.3 in Appendice 4 al Cap.1, K.G.Strouse, “Customer Centered Telecommunications Service
Marketing”, Artech House, 2004, Cap. 8 e V.Raisanen, “Service Modelling: Principles and
Applications”, Wiley, 2006
Riteniamo molto utile in un contesto interdisciplinare introdurre subito il concetto del
tutto generale di “TLC Stakeholder” per rappresentare persone fisiche o giuridiche reali
dotate anche di funzionalità TLC i.e. dotate anche della capacità conoscitiva/abilità fisica di
svolgere una o più funzioni TLC (i.e. attività nel campo delle TLC di natura engineering,
business, economico-finanziaria, legislativa, regolatoria, legale, sociale etc. vedi Tavola
1.0.3.3.1)
18
Alternativamente possiamo dire che con il termine “TLC Stakeholder” noi vogliamo
caratterizzare una qualsiasi persona fisica o giuridica (Vedi NOTA 1.0.1.1) relazionata alle
TLC in maniera significativa e per un qualsivoglia motivo (personale, imprenditoriale,
commerciale, sociale, istituzionale, professionale, per intrattenimento etc. vedi Tavola
1.0.3.3.1). “Relazionata” significa “in possesso di una capacità conoscitiva/abilità fisica di
svolgere funzioni TLC”
•
TLC Stakeholder e Attore TLC
Spesso il significato di “stakeholder” è indicato in Italiano, in maniera molto
limitativa, come “portatore di interesse”. Noi ampliamo di molto questo significato.
Definiamo “TLC stakeholder” non solo un semplice “portatore di interesse nelle TLC”
bensì un “possessore di funzionalità TLC” il quale al momento opportuno e a sua
discrezione attua (mette in atto) queste funzionalità nello effettivo svolgimento di funzioni
TLC. Un TLC Stakeholder osservato nel corso di svolgimento di una certa funzione TLC è
anche denominato un “Attore TLC”. Noi diciamo che nel mondo delle telecomunicazioni
esiste una popolazione di “TLC Stakeholders” e/o di “Attori TLC” mutuamente relazionati.
La relazione consiste nel fatto che un Attore TLC è un TLC Stakeholder che sta svolgendo
una certa funzione TLC. Ad esempio supponiamo che la Telecom Italia abbia 20 milioni di
abbonati ai servizi di telefonia residenziale privata (TLC Stakeholders) ma ad un certo
istante solo 4 milioni di essi sono Attori TLC cioè caricano le reti telefoniche con un
traffico di 2 milioni di sessioni telefoniche (telefonate), assumendo che due Attori TLC
siano simultaneamente presenti in una sessione telefonica. Quindi ad un dato momento nel
bacino di utenza dei servizi di telefonia residenziale della Telecom Italia il numero di Attori
TLC è sempre una frazione del numero totale degli abbonati (TLC Stakeholders), i.e. non
tutti gli abbonati sono attivi allo stesso momento, e questa frazione varia nel tempo secondo
un “profilo temporale di utenza”.
•
“TLC Stakeholder” e “Enterprise Stakeholder”
Talvolta useremo il termine “stakeholder” anche in una accezione più specializzata e
un contesto più ristretto e lo indicheremo come “Enterprise Stakeholder” (Vedi
Appendice 7 al Cap.1). Per “enterprise stakeholder” noi intendiamo un “portatore di
interesse per una specifica impresa telecom” cioè una persona fisica o giuridica che
partecipa ai rischi associati con il business di una certa impresa telecom e che, in qualche
maniera, ha il potere di influenzare questo business. Gli “Enterprise Stakeholders” si
dividono in “esterni” e “interni”:
1) “stakeholders esterni” come clienti, azionisti, sindacalisti, imprese fornitrici di
beni o servizi, imprese concorrenti etc.
2) “stakeholders interni” come operai, impiegati, quadri intermedi, managers etc.
che operano all’interno dell’impresa (vedere anche Fig.A.7.1)
•
Diversi tipi di TLC Stakeholders: funzionalità, funzioni e ruoli
19
“TLC Stakeholder” e Attore TLC sono concetti definiti ad un alto livello di
astrazione. Tuttavia in realtà esistono diversi tipi di TLC Stakeholders e Attori TLC. Ma
come si specifica un tipo di TLC Stakeholder o di Attore TLC? Ciò può farsi in tre possibili
maniere, in base a 1) “possesso di una funzionalità TLC specifica” 2) “svolgimento di
funzione TLC specifica” 3) “svolgimento di un ruolo specifico”.
In altre parole noi diciamo che un TLC stakeholder è specificato in base a:
1) funzionalità TLC che un TLC Stakeholder possiede (caratteristica obbligatoria
e permanente) i.e. capacità conoscitiva/abilità fisica di svolgere una certa funzione TLC.
Ad esempio il possesso di un “abbonamento” o “sottoscrizione” a un servizio di telefonia è
il possesso di una funzionalità TLC specifica che qualifica una persona fisica o giuridica
reale come “abbonato” o “sottoscrittore” di un servizio di telefonia.
2) funzioni TLC che un Attore TLC svolge (caratteristica opzionale e episodica)
motu proprio o in risposta a sollecitazioni esterne. Ad esempio una persona fisica che
guarda un programma televisivo alla televisione svolge una funzione TLC specifica che la
qualifica come “spettatore TV”. Analogamente una persona fisica che ascolta un
programma radiofonico è un “ascoltatore” della radio. Si parla usualmente di numero di
spettatori o ascoltatori che hanno guardato certi programmi TV o ascoltato programmi
radiofonici (il famigerato “indice di ascolto”!). Ebbene, tutti questi signori sono TLC
stakeholders identificati in base alla particolare funzione TLC che essi svolgono.
3) ruolo che un Attore TLC svolge in certe circostanze e in certi momenti. Spesso
un TLC Stakeholder è specificato in base alla funzione TLC che esso sa svolgere o svolge
come Attore nell’ ambito di una relazione con un altro stakeholder e per una certa durata
di tempo. In tal caso si introduce il concetto di “ruolo”: si dice che un TLC Stakeholder è
caratterizzato in base al ruolo specifico che esso è in grado di svolgere o effettivamente
svolge per una certa durata di tempo e nei confronti di un altro stakeholder. Notare che una
stessa persona fisica o giuridica reale può contemporaneamente avere più relazioni con
persone diverse e giocare ruoli diversi rispetto ad esse. Inoltre essa può svolgere ruoli
diversi in tempi diversi e per durate di tempo diverse (Vedere ESEMPIO 1.0.1.2.2). Ad
esempio vedremo che la Telecom Itala è un TLC Stakeholder che svolge allo stesso tempo
quattro ruoli diversi: fornisce servizi TLC agli Utenti, opera reti TLC, compra contenuti da
fornitori di contenuti e compra tecnologie ICT da fornitori di tecnologie (vedi ESEMPIO
1.0.1.2.1).
•
Ordinamento gerarchico
Ogni tipo di TLC stakeholder può essere specializzato progressivamente in sottotipi
di stakeholders tramite aggiunta di caratteristiche specifiche. Si può così generare una
classificazione multi-livello con ordinamento gerarchico come mostrato in Fig.1.0.1.1.
Ad esempio una impresa TelCo Intermediary è un tipo particolare di Telecommunications
Company “TelCo” che compra capacità all’ingrosso da una TelCo Wholesaler e la vende ad
20
una TelCo Retailer la quale vende servizi TLC al dettaglio direttamente ad Utenti finali (che
utilizzano questi servizi per proprio uso e consumo)
ESEMPIO 1.0.1.2.1 Una stessa impresa telecom (persona giuridica reale) è un TLC Stakeholder che
può giocare quattro ruoli diversi nell’ambito di una rete commerciale (“value network”): fornitore di
servizi TLC al dettaglio, acquirente di servizi TLC all’ingrosso, compratore di tecnologie ICT da una
industria manifatturiera, compratore di contenuti da un fornitore di contenuti.
ESEMPIO 1.0.1.2.2 Un ruolo può essere svolto da uno stakeholder per una certa durata di tempo e poi
essere rimpiazzato da un ruolo diverso. Ad esempio una TelCo fornitrice di servizi TLC (persona
giuridica reale) ad un certo momento può essere un TLC stakeholder che gioca il ruolo di “TelCo
Wholesaler” i.e. fornitore di servizi all’ ingrosso ad altre TelCo, ma nel tempo può espandere il suo
business, acquisire una rete commerciale di distribuzione servizi TLC e trasformarsi in un fornitore di
servizi al dettaglio giocando così il nuovo ruolo di “TelCo Retailer” (vedi par. 1.0.1.4).
ESEMPIO 1.0.1.2.3 Esempi di “Engineering” Stakeholders e “Business” Stakeholders. Fra tutti i “TLC
stakeholders” noi distingueremo quelli che nell’ambito delle TLC hanno la capacità conoscitiva/abilità
fisica (funzionalità) di svolgere ruoli di natura esclusivamente Engineering o Business e li chiameremo
rispettivamente “Engineering Stakeholder” o “Business Stakeholder”. Ad esempio un semplice
rivenditore di servizi TLC (TLC service reseller) con interessi puramente commerciali senza alcuna
competenze tecniche di rilievo è un Business Stakeholder.
A) Produttori di beni e servizi TLC (“Imprese TLC”)
1) Imprese “TelCo” (Telecommunications Company)
Service Developer, Network Operator, Service Provider
2) Imprese “ICTS” (Information & Communications Technology Supplier)
ManTec, ICT Vendor
3) Imprese “ContCo” (Content/Media Company)
Content Producer/Editor, Content Provider
B) Consumatori di beni e servizi TLC (“Utenti TLC”) .
Tavola 1.0.1.1 Gli stakeholders presi in considerazione nel corso di GST (marcati in rosso)
ESEMPIO 1.0.1.2.4 La caratterizzazione di un “attore TLC” è fattuale i.e. fatta in base alla funzione
TLC o al ruolo che egli effettivamente svolge per una certa durata di tempo e in determinate
circostanze. Ad esempio una persona fisica allorchè fruisce di un servizio TLC è un attore TLC che
svolge il ruolo di Utilizzatore del servizio. Un rivenditore di apparecchiature domestiche è un attore
TLC allorchè svolge il ruolo di “rappresentante” dei telefoni cellulari Sony-Ericsson. Un venture
capitalist svolge il ruolo di attore TLC allorchè investe capitali nella creazione di una impresa TelCo.
Un sindacalista è un attore TLC allorchè svolge attività sindacale in difesa degli impiegati della
compagnia telefonica Vodafon.
ESEMPIO 1.0.1.2.5 Varietà di TLC stakeholders. Sono TLC stakeholders una impresa commerciale
fornitrice di servizi TLC all’ingrosso o al dettaglio, una impresa produttrice di tecnologie ICT, un
centro di Ricerca & Sviluppo nel campo delle TLC, un utilizzatore di servizi TLC, un finanziatore di
affari nel campo delle TLC, un azionista di una impresa TLC, un sindacalista che difende gli interessi
21
dei lavoratori del settore TLC (vedi Tavola A.4.3), un parlamento internazionale (e.g. Parlamento
Europeo) nazionale o regionale allorchè legifera in materia di TLC, una agenzia nazionale per la
regolamentazione delle TLC, un avvocato esperto nel diritto delle TLC allorchè derime controversie
giuridiche fra utenti e fornitori di servizi TLC etc. La lunghezza di questo elenco mostra la ricchezza
semantica del termine “Stakeholder” e la sua potenziale utilizzazione in un approccio interdisciplinare
alla TLC. Oltre che nei contesti Engineering e Business il temine “stakeholder” può essere usato in un
contesto legale, legislativo, regolatorio o sociale (vedi Appendice 4 al Capitolo 1)
Come si può notare facilmente, in tutti questi esempi c’è sempre una persona fisica o
una organizzazione commerciale o governativa o istituzionale (persona giuridica) che
possiede la capacità conoscitiva/abilità fisica (funzionalità) di svolgere attività relazionate
alle TLC o che anche effettivamente svolge queste attività (funzione o ruolo). Notare che
una stessa persona fisica può svolgere ruoli TLC e ruoli che non hanno nulla a che vedere
con le TLC.
La grande varietà di stakeholders menzionati ci fa capire come il concetto di
“stakeholder” possa essere utilizzato nelle situazioni più disparate (vedi anche ESEMPIO
1.0.1.2.5). Come già detto, si tratta di un concetto definito ad un alto “livello di astrazione”,
possiede una grande ricchezza semantica e quindi è rilevante e utile in un approccio
interdisciplinare alla GST (i.e. lo stesso concetto è utilizzabile in tutti gli aspetti della GST
considerati in un corso interdisciplinare).
•
Gli stakeholders presi in considerazione nel corso GST (Tavola 1.0.1.1)
Nel mondo TLC reale esiste una grande varietà di Stakeholders mutuamente
relazionati in varie maniere. Ad esempio nel Capitolo 4 la Fig.4.1.1 mostra una tassonomia
di Business Stakeholders in cui i vari tipi di Stakeholders sono classificati in corrispondenza
a livelli gerarchici progressivamente più specializzati muovendosi dall’alto verso il basso.
Ma noi in questo corso non ci occuperemo di tutti. Noi ci limiteremo a considerare quelli
che sono direttamente coinvolti con il business dei servizi TLC e fra questi solo quelli
posizionati ai livelli di astrazione più alti: quelli ritenuti indispensabili per un corso
introduttivo di GST. Si tratta di Stakeholders che intervengono direttamente nella gestione
di sistemi e servizi TLC. I pricipali tipi di TLC stakeholders da noi presi in considerazione
sono mostrati nella Tavola 1.0.1.1. Essi appartengono ai due lati opposti del mercato di
beni e servizi TLC: (A) Produttori e (B) Consumatori
Offriamo qui di seguito una breve descrizione degli stakeholders presentati nella
Tavola 1.0.1.1 trattando prima il lato “Produttori di beni e servizi TLC” e poi il lato
“Consumatori di beni e servizi TLC”. Fra i “beni TLC” includiamo i “contenuti” dei servizi
TLC (vedi dopo). Più dettagli verranno presentati nel Capitolo 4 per gli stakeholders attivi
nell’ Ambiente Business.
1.0.1.3 Impresa “TelCo” (Telecommunications Company)
Il bisogno di telecomunicare manifestato indistintamente da tutti gli uomini, o
perlomeno da tutti i membri della nostra “società civile” (e.g. cittadini di un paese del
gruppo G-8 costituito dalle nazioni economicamente più avanzate) si riflette nella esigenza
di acquisire prima e fruire poi di servizi di telecomunicazione (servizi TLC). I servizi
22
TLC sono prodotti cioè sviluppati/forniti/erogati da imprese commerciali (persone
giuridiche reali) qui denominate brevemente TelCo (Telecommunications Company).
Quindi diciamo anche che una TelCo è una impresa “Produttore” di servizi TLC. Il
termine “TelCo” è ampiamente usato nella letteratura anglosassone ed ha il vantaggio di
essere molto breve. Nella letteratura Italiana specializzata, termini equivalenti a “TelCo”
sono “Società di Esercizio” o “Gestore di Telecomunicazioni” o “Impresa di Servizi TLC”.
In ambito ITU-T una TelCo è un “Public Telecommunication Operator” (PTO) responsabile
di pianificare, fornire, installare, mantenere, operare, amministrare reti e servizi TLC.
Inizialmente, per scopi didattici, adottiamo un modello di impresa TelCo molto
semplificato ignorando il fatto che in realtà negli odierni mercati TLC liberalizzati esiste
una varietà di imprese TelCo che fanno affari approfittando delle diverse opportunità di
business presenti in questi mercati. Si tratta di TelCo con diversi ruoli di business
(business roles). Ad esempio oggi esistono TelCo fornitrici di servizi TLC al dettaglio e
TelCo fornitrici di servizi TLC all’ingrosso mutuamente relazionate da rapporti di business
(business relations) in reti commerciali denominate “reti del valore” (value networks)
(vedi par.1.1.1.5 e Appendice 7 al Capitolo 1). Ci occuperemo di questa varietà di TelCo nel
prossimo paragrafo 1.0.1.4.
Allora preliminarmente facciamo riferimento ad una impresa TelCo factotum
responsabile di pianificare, realizzare, installare, fornire, mantenere, operare, amministrare
sistemi e servizi TLC. In effetti si tratta di una TelCo tipica dell’era monopolistica pre anni
90. Anche se oggi non sia del tutto estinta. Infatti imprese di questo tipo sopravvivono
come “ex-monopolisti” o “incumbents” (vedi l’attuale Telecom Italia, che fornisce servizi
e allo stesso tempo sviluppa e gestisce reti locali e long distance). Qui assumiamo quanto
segue:
i) una TelCo in collaborazione con imprese esterne costruttrici di tecnologie ICT
(software e hardware) sviluppa servizi TLC in una fase di “Product Development”.
Vedremo che questa fase precede la fase di “Service Delivery” (offerta, fornitura,
erogazione, manutenzione e fatturazione) in una sequenza temporale di attività denominata
Ciclo di Vita di un Servizio TLC (“TLC Service Lifecycle”, vedere la Fig.1.0.3.1.1)
ii) una TelCo possiede/gestisce/opera grandi Reti TLC abilitanti i servizi TLC che
essa offre. E’ un tipo di impresa che nella letteratura anglosassone è indicata come
“Facility Based TLC Service Provider” o semplicemente “Carrier” per distinguerla da
imprese che forniscono servizi senza essere proprietarie di reti.
.
iii) una TelCo fornisce servizi TLC a una comunità di Utenti finali (persone fisiche
o giuridiche reali che utilizzano i servizi TLC per proprio uso e consumo). Vedremo fra
poco che una TelCo siffatta si chiama anche TelCo Retailer (Retail = Vendita al dettaglio,
vedi par.1.0.1.4) per distinguerla da imprese che forniscono servizi TLC all’ingrosso.
iv) una TelCo è un TLC Stakeholder (persona giuridica reale) che produce servizi
TLC e come tale esso svolge i ruoli principali di Service Developer (SD), Network
Operator (NO) e Service Provider (SP). All’interno di una TelCo questi tre ruoli sono
23
supportati da unità organizzative diverse (e.g. dipartimenti, sezioni, reparti etc.) dirette da
managers con competenze professionali di tipo diverso. I tre ruoli sono:
1)
“Service Developer”, SD, (o, meglio, “Product Developer”, vedi
par.1.0.3.1) produttore di servizi TLC attraverso sei successive fasi di
sviluppo 1) pianificazione e analisi delle opportunità, 2) definizione e
fattibilità del futuro servizio TLC, 3) progettazione, 4) implementazione
utilizzando opportune tecnologie abilitanti già disponibili sul mercato o
sviluppate ad hoc, 5) integrazione di componenti e creazione di servizio
pilota, seguita da prove e collaudo, 6) lancio commerciale e inclusione del
servizio TLC in un “catalogo prodotti” a disposizione del pubblico.
Quest’ultima operazione segna la fine della fase di “Product
Development” svolta all’ interno della TelCo come collaborazione di
esperti con varie competenze professionali e.g. partecipanti ai ruoli di
Network Operator e Service Provider (vedi qui di seguito) e imprese
esterne manifatturiere/fornitrici di tecnologie ICT (vedi ICTS nel
par.1.0.1.5). Vedere anche il testo di E.Ward, “World Class
Telecommunications Service Development”, Artech House,1998. Qui
supponiamo che la “integrazione”/“istallazione” delle reti abilitanti i
nuovi servizi TLC faccia parte della fase di “Product Development” cioè
supponiamo che la fase del “lancio commerciale del servizio TLC”
avvenga allorchè l’infrastruttura tecnologica di supporto è già pronta per
l’uso ed è disponibile ai Clienti che desiderino acquisire i nuovi servizi. Il
Service Developer (o Product Developer) richiede competenze
professionali di natura interdisciplinare Engineering-Business (vedi
Capitolo 2)
2)
“Network Operator”, NO, proprietario, operatore e gestore di grandi reti
TLC. Esso eroga “tecnoservizi di rete” direttamente a “Utilizzatori
finali”, persone fisiche all’interno di una Utenza (vedi 1.0.1.5).
Il termine “tecnoservizi” sta ad indicare i “servizi” che tutti noi ingegneri TLC abbiamo
imparato a conoscere nei corsi universitari di “Reti di Telecomunicazione” (vi ricordate
“reti e servizi”?) ed è da noi usato proprio per ricordare che si tratta di un servizio fornito
da una tecnologia di rete e non un servizio TLC fornito da una impresa commerciale
TelCo. Vedremo fra poco come questi “tecnoservizi di rete” costituiscano una parte dei
servizi TLC commercialmente disponibili, parte denominata “essenza del servizio”
(service core) o “componente U&S” (Utilizzazione & Segnalazione) di un servizio
TLC.
Nel caso di servizi TLC di interconnessione, e.g. telefonia o internet, il
Network Operator talvolta è denominato anche “Connectivity Provider”
cioè “fornitore di interconnettività”. All’interno di una impresa TelCo lo
svolgimento del ruolo di Network Operator richiede competenze
professionali di tipo Engineering (e.g. ingegneri che operano nel
dipartimento “Operations”) ma richiede anche collaborazione con le unità
organizzative del Service Provider (e.g. dipartimento “Sales &
24
Marketing”) che invece utilizzano competenze professionali di tipo
Business.
Un altro compito del Network Operator è la gestione delle Reti TLC e.g.
supervisione delle prestazioni, manutenzione e riparazioni di rete, misura
dei consumi etc.
3)
“Service Provider”, SP, fornitore di servizi TLC a persone fisiche o
giuridiche che giocano il ruolo di “Cliente” (“Customer”) titolare di una
Utenza (vedi 1.0.1.5). Tranne alcune eccezioni e.g. servizi di
distribuzione radiofonica terrestre per i quali non è necessario
sottoscrivere alcun contratto, la “fornitura” di un servizio TLC avviene
nel momento in cui SP e Cliente sottoscrivono un contratto denominato
“Service Level Agreement”, SLA.
La terminologia adottata è in linea con quella offerta nel glossario del
TeleManagement Forum, disponibile on-line a www.telemanagementforum.org (vedi
anche: TeleMenagement Forum, “Telecom Operations Map”, Report GB910, Version 2.1,
p.8-10, March 2000)
Bulk
Capacity
TelCo B
Wholesaler
(Network
Operations)
TelCo A
Retailer
(Reseller)
Rete commerciale
di distribuzione
Servizi TLC
Access to
TelCo B OSS
End
Customers
Bus Eng Relation
Fig. 1.0.1.2 Esempio di TelCo Wholesaler che vende capacità all’ingrosso a una
TelCo Retailer che non possiede reti TLC (Reseller, rivenditore)
Organizzazioni commerciali o governative o anche privati cittadini (rispettivamente
persone giuridiche o persone fisiche) possono scoprire, scegliere, sottoscrivere e comprare
(complessivamente “acquisire”) un servizio TLC da un Service Provider (SP) e così
divenire ufficialmente Clienti della TelCo (vedi 1.0.1.5). Un SP interagisce direttamente,
25
e.g. tramite collegamento internet, con un Cliente per effettuare la gestione del servizio
TLC. In questo contesto talvolta si dice anche che un SP fornisce “servizi gestionali” al
Cliente (customer services) per soddisfare certe sue esigenze. Esempi di customer services
sono: scelta di un servizio TLC da un catalogo servizi come parte di un processo di vendita,
richiesta di installazione di un servizio TLC (service provisioning), sottoscrizione di un
contratto SLA (Service Level Agreement), segnalazione e riparazione guasti, verifica del
QoS di servizi forniti ai singoli clienti (service assurance), invio/ricezione fatture (service
billing), effettuazione/riscontro pagamenti etc.Tuttavia. attenzione!, questi cosidetti
“customer services” fanno tutti parte di un “servizio TLC” cioè ne costituiscono la parte
gestionale. (Vedi par.1.0.3.1).
NOTA 1.0.1.3 In questo corso noi diciamo che le imprese TelCo possiedono/operano reti TLC e
forniscono/erogano servizi TLC su richiesta degli Utenti (vedi 1.0.1.7) al fine di risolvere i problemi che
insorgono presso quest’ultimi allorché essi decidono di soddisfare certi loro desideri/bisogni di
telecomunicazione. Ritorneremo in seguito sul concetto di servizio TLC come servizio finalizzato alla
“risoluzione di un problema TLC insorto presso un Utente”.
NOTA 1.0.1.4 Ribadiamo la necessità dell’esistenza di imprese TelCo per la produzione di servizi TLC.
La trasformazione di un bisogno individuale di “Funzionalità TLC” in bisogno di acquisire/fruire di
servizi TLC forniti/erogati da imprese TelCo di grossa grandezza deriva proprio dal fatto che le reti
geografiche abilitanti i servizi TLC hanno una complessità tecnologica, una estensione geografica e la
loro realizzazione/esercizio comporta un impegno/rischio economico di dimensioni tali da escludere ogni
iniziativa individuale isolata. Queste caratteristiche non sono uniche dei servizi TLC ma sono tipiche dei
“servizi di pubblica utilità” che richiedono grosse reti di distribuzione (e.g. distribuzione di elettricità,
gas, acqua ai cittadini, in Inglese “public utilities”). Anzi, fino a circa dieci anni fa le imprese TelCo
erano monopoli posseduti/controllati dallo stato. Solo recentemente esse sono state privatizzate e i
mercati dei servizi TLC sono diventati liberi mercati aperti alla concorrenza (“liberalizzazione dei
mercati TLC”, vedi Appendice 1 al Cap.1).
1.0.1.4
Imprese “TelCo Retailer”, “TelCo Wholesaler”(Carrier’s Carrier) e
Intermediary
TelCo
Finora, per motivi didattici, abbiamo parlato di una impresa TelCo factotum che
svolge i ruoli di SD, SP, NO, la quale 1) sviluppa servizi TLC e relative infrastrutture
fisiche di supporto, 2) è dotata, gestisce e opera reti TLC, 3) fornisce servizi TLC a
comunità di Utenti finali, e infine 4) gestisce questi servizi mantenendoli in linea con le
esigenze del mercato e lo sviluppo tecnologico in modo tale da poter sfidare con successo le
imprese concorrenti e mantenere le quote di mercato desiderate (vedi dopo). La
distribuzione di servizi direttamente agli Utenti finali richiede inoltre che questa TelCo
disponga anche di reti commerciali di distribuzione costituite da una molteplicità di
centri di vendita (e.g. presidiati da rappresentanti, agenti della TelCo) dove servizi e
terminali TLC sono venduti ai Clienti. Le reti commerciali di distribuzione come le reti
postali o le reti bancarie , e.g. utilizzate per l’invio agli Utenti delle bollette telefoniche o
per effetuare i reltivi pagamenti, sono considerate parte delle “reti di gestione” abilitanti la
gestione dei servizi TLC.
.
•
La realtà dei mercati liberalizzati: una varietà di TelCo!
Questo tipo di impresa TelCo factotum era caratteristica dei mercati TLC di
vent’anni fa che operavano in condizioni di monopolio (vedi Appendice 1 al Cap.1: “Il
26
libero mercato delle telecomunicazioni: considerazioni storiche”). In realtà vedremo fra
poco come oggi i mercati TLC siano molto diversificati e offrano molteplici opportunità di
business sfruttate da una varietà di TelCo diverse con obiettivi di business diversi. Ad
esempio esistono imprese TelCo che non possiedono le reti abilitanti i servizi TLC cioè non
sono “facility based TelCo’s” e quindi esse stesse non svolgono il ruolo di Network
Operator. In questi casi esse stabiliscono rapporti commerciali molto stretti con imprese di
Network Operators esterni che posseggono/operano e manutengono le reti TLC e che
forniscono loro capacità all’ingrosso “bulk capacity” (e.g. blocchi di canali trasmissivi) in
qualità di Wholesale Network Service Providers, anche denominati “TelCo Wholesalers”
(in Inglese wholesale = ingrosso) o “Carrier’s Carrier”. In tal caso la TelCo Retailer viene
identificata come un semplice Rivenditore di servizi TLC (Reseller). Siamo quindi in
presenza di TelCo’s (proprietarie di reti) che forniscono servizi TLC all’ingrosso ad altre
TelCo (proprietarie di catene di distribuzione di servizi TLC) che a loro volta forniscono
servizi TLC al dettaglio agli Utenti finali. Si stabilisce così a livello commerciale una
“catena di distribuzione” di servizi TLC con un “modello di business (“business model”)
a tre ruoli: TelCo Wholesaler, TelCo Retailer e Utente finale (Fig.1.0.1.2). Una modifica di
questo scenario di business consiste in una TelCo Retailer che possiede/gestisce solo reti
locali di accesso (Local Exchange Carrier, LEC, Operatore Locale) e che intrattiene
relazioni di business con un TelCo Wholesaler che possiede/gestisce reti long distance di
trasporto e che fornisce i relativi servizi di trasporto (Inter-Exchange Carrier, IXC,
Operatore Long Distance, vedi Appendice 1 al Capitolo1).
Esistono infine modelli di business molto complessi e.g. in cui interviene un terzo
tipo di impresa commerciale di intermediazione e.g. fra Telco Wholesalers e TelCo
Retailers (denominata “TLC Service Intermediary”, vedi Fig.1.0.1.4) o con la
partecipazione di imprese ICTS (vedi par.1.0.1.8) manifatturiere e fornitrici di Tecnologie
ICT. In questi scenari le varie imprese sono legate da relazioni di business multiple in una
rete commerciale usualmente denominata anche “value network” o “rete del valore” (vedi
1.1.1.5).
Questi argomenti verranno trattati più dettagliatamente nel Cap.4 (par.4.1.2)
NOTA 1.0.1.5 L’eredità storica e la storia passata delle TelCo è molto importante se si vuol capire lo
status 2008 dei mercati delle TLC e si invitano gli studenti a leggere l’Appendice 1 al Cap.1. Maggiori
dettagli si trovano in due ottimi libri: I. Walden, J. Angel: “ Telecommuincations Law and Regulation”,
Oxford University Press, 2005 e P.Brezzi, “Economia e Politica delle Telecomunicazioni”, Franco
Angeli, 2004
1.0.1.5
Impresa “ICTS” (Information & Communications Technology Supplier)
Un insieme di reti TLC e terminali ad esse connessi costituiscono un sistema TLC,
infrastruttura fisico-logico-energetica abilitante i servizi TLC. Si tratta di due tipi di
tecnologie prodotti da industrie manifatturiere specializzate. Alcune industrie effettuano
produzione di massa dei terminali, altre producono componenti di reti TLC (equipment
suppliers), altri li integrano in grandi sistemi di telecomunicazione (“system integrators”),
altre imprese sono software houses che producono solo sistemi software (software
suppliers). In questo corso in uno sforzo di semplificazione noi diremo che tutti questi tipi
di imprese sono fornitori di Tecnologie ICT appartenenti ad un'unica classe denominata
27
“ICT Supplier” o “ICTS” (Fornitore di Tecnologie ICT) che produce e vende tecnologie
ICT alle TelCo e agli Utenti i.e. le tratteremo in maniera unificata ad un alto livello di
astrazione ignorando i dettagli delle loro strutture organizzativo-commerciali e il tipo di
Tecnologia ICT prodotto. Ricordiamo che le Tecnologie ICT (Information &
Communications Technology) sono tecnologie per la trasmissione (transmission),
elaborazione (processing) e immagazzinamento (storage) dell’ informazione digitale su
tutto lo spettro elettromagnetico, dalla banda base alle frequenze ottiche.
Il nome di ICT Supplier o ICTS deriva dal fatto che, rispetto ad una TelCo, una
ICTS gioca il ruolo di fornitore (supplier) di tecnologie ICT (assieme ad eventuali servizi
post vendita di manutenzione e riparazione dei prodotti venduti). Una Telco ha relazioni
commerciali molto strette con gli ICTS, fornitori delle tecnologie abilitanti i suoi servizi
TLC.
Analogamente a quanto fatto per una impresa TelCo diremo che una impresa ICTS è
una entità reale che gioca due ruoli, uno di natura tecnica e uno squisitamente commerciale:
1) il ruolo di Manufacturer of ICT, ManTec per la produzione di tecnologie ICT in un
Ambiente Engineering dove sono attivi Attori Engineering (e.g. ingegneri, personale
tecnico, operai) e 2) il ruolo di “ICT Vendor” per la commercializzazione e vendita di
tecnologie ICT alle TelCo e agli Utenti in un Ambiente Business dove sono attivi Attori
Business (e.g. operatori “Sales & Marketing”).
NOTA 1.0.1.6 “TELECOMUNICAZIONI IBRIDE” & TELE-SERVIZI
Per comodità dello studente riportiamo qui di seguito quanto già detto nella
“PREMESSA”
Fanno parte delle telecomunicazioni studiate in questo corso anche le
“telecomunicazioni ibride” realizzate congiuntamente da portante
elettromagnetica man-made e mezzi di trasporto non-elettromagnetici. Ad
esempio nei servizi di “vendita on-line” (e-commerce) si usano mezzi
elettromagnetici (servizi TLC come servizi telefonici o internet) per consultare
cataloghi e ordinare la merce mentre si usano mezzi di trasporo meccanici
(servizio pacchi postali) per trasportare la merce dal magazzino del fornitore
alla sede del destinatario. Per le telecomunicazioni ibride è necessario che una
impresa in generale non-specifica delle telecomunicazioni produttrice di beni
materiali e.g. un venditore di libri, collabori con una Telco fornitrice di servizi
TLC. In tal caso il bene materiale fornito costituisce il “contenuto” di un
“servizio ibrido” nel quale il servizio TLC ha una mera funzionalità ancillare.
Per il cliente il “valore” di un servizio ibrido risiede nel suo contenuto (e.g. un
alto “valore” di un servizio di e-bookstore è legato ad una consegna pronta e
accurata del libro desiderato). Considerazioni analoghe valgono per scenari in
cui il contenuto del “servizio ibrido” non è un “bene materiale” bensì è un
“servizio” in generale non TLC nel quale un fornitore fornisce “informazione”
(talvolta in maniera interattiva) di varia natura e.g. notizie, intrattenimento,
educazione, consulenza professionale. In tal caso i “servizi ibridi” sono
denominati “tele-servizi”, o “e-servizi” se forniti via internet, proprio perché
sono servizi nonTLC contenuti in servizi TLC (vedi anche Capitolo 4). Ad
esempio nei servizi di tele-medicina o tele-educazione i fornitori dei contenuti
informativi dei tele-servizi sono rispettivamente un ospedale che fornisce servizi
di assistenza medica o una università che fornisce servizi di istruzione
pubblica. In entrambi i casi l’ospedale e l’università collaborano con una
TelCo che fornisce il servizio TLC “contenitore” che trasporta a destinazione il
contenuto informativo.
28
NOTA BENE. Una relazione commerciale on-line TelCo - ICTS (talvolta indicata in letteratura come
“Carrier-Vendor relation”) è del tipo B2B (Business-to-Business).
Nel Capitolo 4 vedremo che nella realtà dei fatti la situazione è molto più articolata e i due
ruoli di ManTec e ICT Vendor sono separati. Infatti esistono imprese ManTec il cui core
business è produzione e vendita all’ingrosso di tecnologie ICT e imprese ICT Vendor che
non hanno capacità produttive e il cui core business è la rivendita al dettaglio delle
tecnologie ICT. Inoltre esiste una serie di imprese che svolgono attività di intermediazione
fra i due estremi di ManTec (produttori) e ICT Vendors (venditori al dettaglio). Come pure
esiste una varietà di imprese ManTec e.g. quelle che producono tecnologie ICT partendo
dalle materie prime e quelle che invece integrano componenti prodotti da queste.
1.0.1.6 Imprese “ContCo” (Content Company) & “MediaCo” (Media Company)
(FACOLTATIVO-SOLO LETTURA)
•
Il servizio TLC come trasporto di “contenuti” (content)
Oggi tutti amano ricevere certi beni & servizi creati/forniti dai migliori
produttori/fornitori anche se ubicati in siti remoti.
Ad esempio uno studente
dell’università Roma2-Tor Vergata desidera comprare un libro “XYZ” disponibile negli
USA. Oggi tutto ciò è possibile trasformando i beni e/o i servizi desiderati in “contenuti”
di servizi TLC. In tal caso i servizi TLC vengono a svolgere una funzione di “trasporto di
contenuti” o di “contenitore di beni o servizi”. Nel caso di trasferimento di beni materiali
i servizi TLC intervengono in due possibili scenari:
1) SCENARIO No.1 I servizi TLC effettuano il trasferimento di un certo bene
materiale con forte contenuto informativo (scritti, registrazioni o immagini, non patate o
frigotiferi!) in maniera esclusiva tramite i) processi di estrazione, digitalizzazione e messa
in rete dei contenuti (“dematerializzazione” del bene) ii) trasporto in rete dei dati, iii)
processi inversi in sede di ricezione dati (“ri-materializzazione” dei contenuti)
ESEMPIO. Ricezione e down-loading dei contenuti del libro “XYZ” per via elettronica tramite il
ricevitore/lettore “Spindle” della ditta Amazon.com oppure tramite iPhone, entrambi attualmente disponibile
negli USA e di prossima commercializzazione in Europa. La stessa procedura viene attualmente adottata per la
distribuzione on line dei quotidiani (anche qui la ri-materializzazione dei contenuti avviene su un opportuno
lettore e non su carta).
2) SCENARIO No.2 I servizi TLC effettuano il trasferimento di un certo bene
materiale con forte contenuto informativo in maniera parziale in quanto parte di servizi
ibridi i.e. servizi TLC + servizi pacchi postali (Vedi PREMESSA)
ESEMPIO. Acquisto del libro “XYZ” on line tramite i servizi di e-commerce forniti dalla ditta
Amazon.com. Vedere la NOTA 1.0.1.6.
Il trasporto di contenuti materiali o immateriali può avvenire tramite reti di
distribuzione (tele-educazione) o di interconnessione (invio di una fotografia via internet da
persona a persona). Nel caso di servizi TLC di distribuzione di contenuti informativi
confezionati da ditte specializzate la natura/scopo può essere di vario tipo e.g. sport, notizie
29
(news), educazione (education), intrattenimento (entertainment). In questi casi per il
cliente il “valore del servizio” sta nel “valore del contenuto” del servizio stesso. Ad
esempio in un servizio di tele-educazione su piattaforma TV, il valore del servizio è
misurato dal cliente/studente principalmente in base alla bravura didattica dell’istruttore che
fa lezione e in base all’interesse che il contenuto del corso suscita in lui e molto meno in
base al Livello di Prestazione del canale televisivo (e.g. nitidezza e stabilità delle immagini,
sincronismo suono-immagine, fedeltà dei colori etc.)
Il “contenuto di un servizio TLC” verrà studiato in dettaglio nel Capitolo 4 sezione
4.4.
Qui anticipiamo alcuni concetti generali relativi ai ruoli di un impresa
produttrice/fornitrice di contenuti “Content Company” e alla sua struttura interna.
•
Le imprese ContCo fornitrici di contenuti specifici
Oltre alle imprese TelCo che possiedono/gestiscono reti TLC e forniscono servizi
TLC (per il trasporto dell’informazione) e alle imprese manifatturiere ICTS che producono
e vendono tecnologie ICT abilitanti, oggi esistono imprese ContCo (Content Company)
che creano/trasformano/forniscono contenuti specifici per certi tele-servizi. Come già visto
per le imprese ICTS anche una impresa ContCo può essere un produttore originale di
contenuti o una impresa che modifica/integra prodotti pre-esistenti e poi li immette sul
mercato
1) TLC Content Producer e.g.
Generatori di informazione e.g. film studios, graphic designers
Retailers che approntano siti internet (“soft goods”) per e-commerce
Advertisers che producono spot pubblicitari
2) TLC Content Provider e.g.
Content Packager, che aggiunge valore all’ informazione originale (raw
information) tramite processi di filtraggio, aggregazione e confezionamento rendendola
utizzabile come “contenuto” di un certo servizio TLC e poi la vende
Distributore di contenuti, che trasferisce contenuti multimediali fra aziende
Addetto al reformatting (repurposing) di contenuti e.g. trasforma films analogici
in MPEG video
Infine esistono ConCo che forniscono strumenti per la produzione di contenuti, e.g.
Silicon Graphics produce sistemi di computers per la creazione di effetti grafici speciali
Un caso particolare di ContCo è una MediaCo che produce contenuti specifici da
diffondere tramite reti TLC di distribuzione e.g. programmi radio televisivi. L’integrazione
di una impresa MediaCo produttrice di contenuti TV con una TelCo fornitrice di servizi di
30
distribuzione e proprietaria delle relative reti di distribuzione e.g. sistema satellitare di
broadcasting dà luogo a un impresa denominata Broadcaster.
1.0.1.7
Cliente, Utilizzatore, Utenza
Passiamo ora al lato “Consumatori di beni e servizi TLC” facendo riferimento alle
persone fisiche e giuridiche reali che utilizzano beni e servizi TLC per proprio uso e
consumo (Utenti finali)
•
Cliente (Customer)
Facciamo riferimento ad una organizzazione commerciale o ad un ente governativo
(persona giuridica) nel ruolo di Cliente di una TelCo. Una persona fisica o giuridica reale
che ha desiderio/bisogno di telecomunicare sceglie un determinato servizio TLC fra una
serie di servizi disponibili sul mercato (in un libero mercato per uno stesso tipo di servizio
infatti si hanno a disposizione diversi fornitori, prezzi, qualità, condizioni di pagamento
etc.) e diventa un Cliente di una certa TelCo allorchè acquisisce da essa un servizio TLC, in
generale sottoscrivendo un contratto denominato contratto SLA (Service Level
Agreement) nel quale sono specificati i termini e le condizioni (terms & conditions) relativi
alla fornitura/erogazione del servizio TLC prescelto. Talvolta il termine “Cliente” è
sostituito dal termine equivalente di “Sottoscrittore” (“Subscriber”). Il termine Italiano
“Abbonato” invece non è del tutto equivalente a “Cliente” se per “Abbonato” si intende
una persona fisica o giuridica che acquisisce un servizio TLC e fa pagamenti mensili fissi
(cioè paga un abbonamento mensile fisso a fronte di un consumo illimitato).
LAN 1
LAN 3
UTENZA
AFFARI o
GOVERNATIVA
LAN 2
Terminali di
Utilizzazione
(Usage
Terminals)
Gestione del
primo ordine
T
T
ISM
Equipment
T
INTERFACCE
UOMO-MACCHINA
(CONFINE del
SISTEMA TLC)
Addetti ISM
(ISM Supervisors)
Utlizzatori Finali
(End Users)
Bus Eng Relation
Fig. 1.0.1.3 Il confine del “sistema TLC” all’interno di una Utenza è costituito
dalle intefacce uomo-macchina dei terminali e dei sistemi ISM
31
•
Cliente titolare di una Utenza
Una persona reale nel ruolo di Cliente di una TelCo è anche titolare di un
“Utenza”. Nel caso in cui questa persona reale sia una organizzazione commerciale o un
ente governativo l’Utenza è denominata rispettivamente Utenza Affari (o Utenza Business)
o Utenza Governativa. Nel caso in cui la persona reale sia un privato cittadino che non
utilizza i servizi TLC per scopi di business ma esclusivamente per suoi scopi personali
l’Utenza è denominata Utenza Consumer. In generale le Utenze possono essere classificate
in base a criteri diversi e.g. numero di Utilizzatori di servizi TLC all’interno dell’Utenza,
posizione geografica, caratteristiche demografiche degli utilizzatori (età, sesso, professione
etc).
•
Utenza: Vista interna con Utilizzatori finali (End Users)
Una Utenza è una entità caratterizzata da una “vista interna” ed una “vista esterna” a
seconda che un osservatore metta a fuoco le sue caratteristiche interne o esterne e ignori
tutto il resto. Nel caso di una Utenza Affari o Governativa la vista interna (in Inglese,
Customer Premise) mostra una struttura organizzativa con diverse unità organizzative che
esplicano attività amministrative legate al ruolo di Cliente (e.g. uffici, sezioni, dipartimenti
in varie “funzioni aziendali” e.g. finanze, acquisti, marketing, relazioni esterne etc). Queste
unità organizzative possono risiedere in edifici geograficamente separati ma essere
interconnesse da opportune reti di telecomunicazione interne (“corporate networks”) con
topologie dipendenti dalla particolare struttura organizzativa dell’azienda (e.g. VPN, Virtual
Path Networks, in imprese commerciali o anelli di interconnessione LAN in fibra ottica
FDDI, Fiber Distributed Data Interface, come nei campus universitari USA)
La vista interna di un Utenza Affari o Governativa mostra anche un insieme di
risorse tecnologiche abilitanti la fruizione dei servizi acquisiti (Customer Premise
Equipment, CPE) e.g. telefoni, computers, stampanti, wireline o wireless Local Area
Networks, LAN, reti di interconnessione di LAN etc.
Le tecnologie CPE sono utilizzate da persone fisiche autorizzate/abilitate a fruire
dei servizi TLC all’interno dell’Utenza e.g. i professori dell’Università Roma-Tor Vergata
sono autorizzati/abilitati a fare telefonate dai telefoni installati nei loro uffici.. Queste
persone fisiche quando fruiscono dei servizi TLC sono Attori TLC che svolgono il ruolo di
“Utilizzatore finale” (End-User) poichè usano i servizi per proprio uso e consumo senza
trasferirli ad una terza parte. L’insieme delle tecnologie CPE e i relativi impianti di
supporto sono sotto il controllo degli uffici amministrativi, già evidenziati nella vista interna
dell’ Utenza, e assieme ad essi costituiscono un dominio amministrativo che fa capo ad un
certo CLiente (“business administrative domain”. Vedi anche: ITU-T Recommendation
G.803, 03/2000, pag.2). Noi diciamo che una Utenza è il dominio amministrativo del
Cliente di una certa TelCo.
Quindi, ripetiamo, il ruolo di Utilizzatore finale viene svolto allorchè una persona
fisica all’interno di una Utenza chiede e ottiene accesso e poi fruisce dell’ “essenza” di un
32
servizio TLC (i.e. il “tecnoservizio di rete” erogato dal Network Operator) esclusivamente
per proprio uso e consumo.
ATTENZIONE ALLA TERMINOLOGIA!! Il ruolo di Utilizzatore finale viene svolto all’interno di una
Utenza da una persona fisica (Attore TLC) durante una “sessione di servizio” (“service session”).
L’Utilizzatore richiede ed ottiene una specifica capacità di rete di cui egli ha desiderio/bisogno, e.g. una
connessione circuitale con certe caratteristiche ad un determinato terminale. Questo avviene durante una
“sessione di accesso” (“access session”). Poi egli fruisce/utilizza questa capacità in una “sessione di fruizione
o utilizzazione” (“usage session”) e infine restituisce la capacità in una “sessione di recesso” (“recess
session”). Le attività di accesso e recesso sono attività di “segnalazione” (“signaling”). Si dice anche che
durante una “service session” l’Utilizzatore fruisce dell’ “essenza di un servizio TLC” (“TLC service core”)
o della “componente U&S di un servizio TLC” (“U&S component of a TLC service”) laddove U&S
significa “Utilizzazione & Segnalazione (Usage &. Signaling”). L’argomento verrà ripreso nel par.1.2.2.
In una Utenza Affari o Governativa gli Utilizzatori finali si limitano ad usare
l’equipaggiamento CPE a loro disposizione per telecomunicare senza occuparsi della sua
gestione. Tale compito infatti spetta a personale specializzato che fa parte di una unità
organizzativa interna all’Utenza denominata “Information System Management, ISM”. Il
personale ISM (“tecnici ISM”) utilizza terminali ad hoc ubicati in postazioni di lavoro
interne alla unità organizzativa ISM per svolgere i propri compiti di “gestione manuale” del
CPE ed è coadiuvato da sistemi informatici “LAN Management Systems” nella gestione
delle reti LAN e delle loro reti di interconnessione (“gestione automatizzata”). Nel
prossimo paragrafo vedremo che i sistemi ISM poiché effettuano una gestione diretta dell’
equipaggiamento CPE (gestione del primo ordine) fanno parte del “sistema TLC”. (vedi
Fig.1.0.1.3)
Contrariamente al Cliente, un Utilizzatore finale non sceglie il servizio, in generale
non paga direttamente la TelCo per i relativi consumi (a meno che non esistano telefoni a
pagamento a scheda o a gettone all’interno dell’Utenza) e nel caso di guasto non contatta
direttamente la TelCo fornitrice bensì si rivolge all’ ufficio ISM interno all’ Utenza.
L’ufficio ISM è responsabile della gestione tecnica (attività di natura Engineering) del CPE
e ad esso vengono demandati i contatti diretti col Network Operator per derimere eventuali
problemi tecnici legati a malfunzionamenti della rete TLC e.g. segnalazione guasti e/o
richiesta di riparazioni in rete (e.g. “help desk di assistenza tecnica per utenze business”
parte dell’ ufficio “Assistenza Clienti” della TelCo).
•
Utenza: vista esterna
Una TelCo ignora cosa accade all’interno di una Utenza ed ha di essa solo una vista
esterna. Infatti una TelCo visualizza una Utenza come un dominio elementare di
utilizzazione dei suoi prodotti TLC il quale ha un certo “track record” di utilizzazione dei
servizi e dei pagamenti. Una Utenza è anche una unità costitutiva del “Bacino di Utenza”
della TelCo stessa. Più precisamente, nella sua vista esterna, una Utenza è caratterizzata da
1) Numero di Utenza 2) Nome, cognome e dati identificativi del Cliente titolare
dell’Utenza, 3) Contratto SLA con la specifica dei “Terms & Conditions, T&C” del
prodotto TLC acquisito, 4) Dati statistici relativi al profilo di utilizzazione del prodotto
acquisito e 4) Stato attuale e storia dei pagamenti effettuati dall’inizio delle fornitura del
prodotto.
33
•
Utenza: relazioni commerciali TelCo-Cliente
Il concetto di “Utenza” è importante nelle relazioni commerciali TelCo-Cliente. Ad
esempio consideriamo una attività gestionale tipica di una TelCo: la attività di
“fatturazione” (billing) per i servizi erogati in un certo periodo di tempo. Una TelCo
prepara una certa fattura per una certa “Utenza”. Nella fattura è indicato 1) Numero di
Utenza (assegnato al Cliente al momento della fornitura del prodotto TLC = mix di servizi
TLC + eventuali tecnologie e.g. terminali, ADSL etc.) 2) nome, cognome, indirizzo del
Cliente titolare, 3) importo da pagare calcolato in base a certe tariffe e ai consumi relativi al
periodo di fatturazione e.g. bimestre, 4) stato dei pagamenti pregressi 5) eventuali addebiti
extra per pagamenti dovuti e non effettuati (morosità).
ATTENZIONE! Ribadiamo che nel corso di GST è importante fare molta attenzione alla differenza fra
il ruolo di “Cliente di una TelCo” (titolare dell’Utenza e collaboratore con l’SP nella gestione dei servizi
TLC) svolto da una persona fisica o giuridica reale e il ruolo di “Utilizzatore di un servizio TLC” svolto
dai membri di una comunità di persone fisiche all’interno di una Utenza. Un Utilizzatore è un fruitore
dei “servizi di rete” (network services) durante la fase di “erogazione/fruizione” di un servizio TLC. I
servizi di rete costituiscono l’ “essenza” di un servizio TLC (TLC service core).
1.0.1.8 Utenze “Consumer”
Finora abbiamo fatto riferimento ad una organizzazione commerciale o ad un ente
governativo (perrsone reali giuridiche). Facciamo ora riferimento ad un privato cittadino
Cliente di una TelCo per un servizio di telefonia vocale mobile e.g. cellulare. In tal caso lo
scenario precedente si specializza ad una unica persona fisica che gioca i ruoli di Cliente,
Utilizzatore e Gestore delle tecnologie ICT necessarie a fruire del servizio TLC acquisito
e.g. telefono cellulare (Customer Equipment,CE). Infatti in questo caso chi sottoscrive il
servizio e effettua i pagamenti (Cliente) e ricarica la batteria quando è scarica (Gestore) è
anche colui che fa le telefonate (Utilizzatore finale). Una Utenza Consumer è una Utenza il
cui titolare è una persona fisica che non svolge attività di Business e.g. Utenza Residenziale
Privata o Utenza Mobile Privata.
1.0.1.9 Utente
Il termine “Utente” viene usato in diversi contesti con diversi significati. Ma per noi
chi è un “Utente”? In questo corso il termine Utente si riferisce ad un TLC Stakeholder,
persona fisica o giuridica reale, capace di svolgere i ruoli di Cliente di una TelCo e di
Utilizzatore dei relativi servizi TLC. Noi useremo il termine “Utente” ogniqualvolta non ci
interessa distinguere fra questi due ruoli oppure quando le nostre considerazioni sono
ugualmente valide per entrambi. Mnemonicamente può essere utile ricordare “Utente =
Utilizzatore + Cliente” tenendo tuttavia presente che l’ Utente è una persona fisica o
giuridica reale mentre Utilizzatore e Cliente sono due ruoli che esso può svolgere. Inoltre un
Utente Affari o Governativo gioca anche il ruolo aggiuntivo di Information System
Manager per la gestione delle tecnologie CPE all’interno del suo dominio amministrativo.
Come già indicato in precedenza, in Inglese non esiste un unico termine corrispondente al
34
termine Italiano “Utente” e quindi il termine “Utente” viene generalmente tradotto col
binomio “Customer/User”.
Notare bene che parlare di “Utente” in effetti significa parlare contemporaneamente
dei suoi due ruoli di Utilizzatore e Cliente. Ad esempio il “soddisfacimento dell’ Utente”
indica il soddisfacimento sia delle persone fisiche nel ruolo di “Utilizzatore” sia di quelle
nel ruolo di “Cliente” cioè indica che l’Utente è soddisfatto sia da un punto di vista
gestionale (Cliente) che dal punto di vista di chi effettivamente fruisce di un servizio TLC
(Utilizzatore). Ad esempio dire che un Utente è soddisfatto significa dire che e.g. egli
percepisce gli addetti al call-center come gentili, pronti e competenti (aspetto gestionale) e,
al tempo stesso, percepisce la qualità delle telefonate effettuate come ottima e perfettamente
in linea con le sue esigenze (aspetto di utilizzazione).
ATTENZIONE. Pericolo di confusione! Spesso in letteratura, nel caso di utenza business, si trova indicato
come ruolo “Utente” quello che per noi è un ruolo di “Utilizzatore finale”. Infatti si legge spesso che
all’interno di una Utenza si trovano “Cliente e Utente”. Inoltre spesso si indica con “Utenza” l’insieme di tutti
gli Utenti accuditi da una certa TelCo, cioè si chiama “Utenza” quello che noi invece chiamiamo “Bacino di
Utenza” (insieme delle viste esterne di una comunità di Utenze facente capo ad una TelCo)
1.0.1.10
Relazioni fra TLC stakeholders
I vari stakeholders sinora presi in considerazione non operano indipendentemente
ma interagiscono attraverso la compravendita (trading) di prodotti TLC i.e. tecnologie
ICT (Information & Communications Technology) o servizi TLC o contenuti di servizi
TLC. Più precisamente i singoli stakeholders si comportano in base a scelte/decisioni di
natura economico-commerciale prese su base individuale ma rese mutuamente compatibili
da meccanismi di mercato (market mechanisms) che regolano la compravendita dei
prodotti (vedi M.Parkin. “Microeconomics”, Addison-Wesley, 1990, pag.14). Lo scenario
di interazione fra i vari TLC stakeholders da noi preso in considerazione è mostrato in
Fig.1.0.1.4. La Fig.1.0.1.4 mostra come i servizi TLC siano forniti da TelCo a Utenti finali,
siano abilitati da Tecnologie ICT prodotte da ICTS e fornite a TelCo o a Utenti e i loro
“contenuti” siano prodotti da imprese ContCo produttrici/fornitrici di servizi non-TLC.
Notare come talvolta più di una TelCo sia necessaria a fornire uno stesso servizio (Fornitori
partner) e come più di una ICTS sia necessaria a produrre una stessa tecnologia ICT. In
Fig.1.0.1.4 non è mostrato il caso in cui i contenuti sono forniti dagli Utenti stessi come
avviene in molti servizi internet. La Fig.1.0.1.5 mostra i vari ruoli di business ordinati
secondo una “value chain” (catena del valore) nella quale il valore economico per l’Utente
finale (Customer + end User) aumenta spostandosi da sinistra a destra .
35
ContCo
Nel Corso GST ci
occuperemo
solo di questa parte
Content
Market
Contents
$
Service Market
ICT Market
TelCo
$
Ntwk Equip . (SD+SP+NO)
TLC Service
$
ICT Market
Terminal Equip .
Utente
ICTS
Customer+End User
$
PdS Bus Eng Relation
Fig.1.0.1.4 Lo “scenario di riferimento” semplificato adottato in questo corso e i relativi mercati (tecnologie,
servizi, contenuti). Gli Utenti sono utenti finali i.e. svolgono i ruoli di clienti + utilizzatori finali. In questa
figura si suppone che la TelCo sia un' unica impresa che svolge i tre ruoli di SD, NO e SP. In un mercato
liberalizzato i tre ruoli possono essere svolti da tre imprese diverse (vedi Fig.1.0.1.5)
36
R
A
W
M
A
T
E
R
I
A
L
S
CONTENT
ManTec
TelCo
Wholesaler
ICT Vendor,
TelCo
Intermediary
Content
Provider
TelCo
Retailer
End
Customer/
User
F
I
N
A
L
P
R
O
D
U
C
T
ContCo
Value chain
Fig.1.0.1.5 Rappresentazione di ICTS, TelCo e
economico dei prodotti aumenta da sinistra a destra.
ContCo nella “Value chain”. Per l’Utente il valore
37
Fig.1.0.1.11.1 For sure Cat Lovers and Veterinary Surgeons see cats differently!
Esempio di rappresentazioni astratte diverse di una stessa entità reale.
(da G.Booch “Object Oriented Analysis and Design” Addison-Wesley, 1994. p. 42)
1.0.1.11 Relazioni fra TLC stakeholders: sdoppiamento “Engineering – Business”
In generale in uno stesso TLC Stakeholder albergano competenze/interessi e vengono
svolte attività di natura sia Engineering che Business (vedi la “Premessa” a queste dispense).
Da un punto di vista didattico il nostro approccio interdisciplinare allo studio di GST richiede
che entrambi aspetti vengano considerati contestualmente con particolare attenzione alle “zone
di frontiera” fra le due aree conoscitive (aspetti interdisciplinari. Vedere Appendice 5 al
Capitolo 1). Per poter fare tutto questo quale procedura dobbiamo seguire? Vediamo.
La Fig. 1.0.1.11.1 mostra come osservatori diversi che operano contemporaneamente
possono selettivamente mettere a fuoco certe caratteristiche di una stessa entità reale alla luce
dei loro “interessi” (competenze professionali e/o interessi personali) attraverso processi
concettuali detti “processi di astrazione”. Allora ci poniamo la seguente domanda: “Cosa
mettono a fuoco due osservatori con interessi Engineering o Business, allorchè essi osservano
38
uno stesso TLC Stakeholder?” La risposta è: “Di questo TLC Stakeholder vengono messe
separatamente a fuoco le caratteristiche rilevanti ai ruoli che esso svolge sulla base delle sue
funzionalità Engineering o Business”. Ad esempio, in una TelCo un osservatore Engineering
mette a fuoco la parte di impresa (persone, tecnologie, processi) rilevante al ruolo di Network
Operator (NO) mentre un osservatore Business mette a fuoco la parte rilevante al ruolo di
Service Provider (SP). Noi diciamo anche che il ruolo di Network Operator è un ruolo
Engineering mentre un ruolo Service Provider è un ruolo Business (vedi Fig.1.0.1.11.2) per
indicare che essi richiedono personale con conoscenze e competenze professionali
rispettivamente Engineering e Business. Vedremo come all’interno della TelCo i due ruoli
interagiscano sia in fase di “Product Development” che di “Service Delivery” secondo
politiche/regole stabilite dal management dell’impresa. Vedremo inoltre come in fase di
“Product Development” la loro interazione è così stretta da richiedere il supporto di teams di
lavoro interdisciplinari.
ESEMPIO. Un ingegnere TLC che visita la Telecom Italia è interessato a conoscere e quindi “mette a fuoco” le
metodologie adottate per la manutenzioni degli impianti di autocommutazione (ruolo NO di natura Engineering).
Un businessman che visita la Telecom Italia è interessato e quindi mette a fuoco le politiche adottate per la
promozione dei nuovi servizi mobili a larga banda (ruolo SP di natura Business). Una squadra di visitatori con
ingegneri TLC e businessmen visualizza entrambi aspetti.
39
Customer/User
TelCo Retailer
Third Party SP
Not-TLC Service
ContCo
TelcCo B
Customer
Service Provider
TLC
Service
User
ISM
Service Provider
TLC
Service
Network Operator
Network Operator
Network Operator
Product Developer
Product Developer
ICT
ICT
ICT Vendor
Ruoli Business
ICT
ManTec
Ruoli Engineering
Stalkeholder
ICT Supplier
Bus Eng Relation. PdS 26/10/2007
Fig.1.0.1.11.2 Relazioni fra Stakeholders e Ruoli (Engineering e Business). Relazioni amminstrative
interne (Frecce rosse). Relazioni di business interaziendali (frecce nere).
Ruolo “Cliente”
(Business Environment)
(Inter-domain Relationship)
40
TOP DOWN
CUSTOMER
Customer Interface Management Processes
Customer Interface Management Processes
Service Fulfillment
Service Assurance
Service Billing
Customer Care Management
Sales
Sales
Order Handling
Order Handling
Problem
Problem
Handling
Handling
Customer QoS
Customer QoS
Management
Management
Invoicing &
Invoicing &
Collections
Collections
Service
ServiceQuality
Quality
Management
Management
Rating
Rating&&
Discounting
Discounting
Service Development & Operations Management
Service
Service
Planning
Planning
&&Development
Development
Service
Service
Configuration
Configuration
Service
ServiceProblem
Problem
Management
Management
Network & Systems Management
Network
Network
Planning
Planning
&&Development
Development
Network
Network
Provisioning
Provisioning
Network
Inventory
Management
Network
Network
Maintenance
Maintenance
&&Restoration
Restoration
Network Data
Management
S
y
s
t
e
m
s
M
n
g
m
t
P
r
o
c
e
s
s
e
s
Network
NetworkElement
ElementManagement
ManagementProcesses
Processes
BOTTOM UP
I
n
f
o
r
m
a
i
o
n
Physical Network / Information Technology
Ruolo
“Service Provider”
(Business
Environment)
INTERDISCIPLINARY
E-B COUPLING
(Intra-domain
Relationship)
Ruolo
“Network
Operator”
(Engineering
Environment)
Persona TLC
Fig. 1.0.1.11.3 Viste Engineering e Business all’interno di un TLC Stakeholder “TelCo”
La Fig. 1.0.1.11.3 mostra le attività rilevanti ai ruoli di NO e SP in una TelCo. In questa figura
Network Operator e Service Provider sono trattate come due persone astratte separate ma
interagenti. La Tavola 1.0.1.11.1 mostra i ruoli Business e Engineering svolti da alcuni TLC
Stakeholders.
DISCUSSIONE 1.0.1.11.1 Perché il ruolo “Utilizzatore” è un ruolo Engineering?
Si potrebbe osservare che mentre il carattere Engineering di attori TLC nel ruolo Network Operator (NO) non si
discute (e.g. chi opera le reti deve avere competenze Engineering!) altrettanto non si può dire per l’ Utilizzatore di
un servizio TLC. Infatti si potrebbe pensare che chi telefona in effetti operi in un ambiente neutro che non ha
nulla a che vedere con Ambienti Business o Engineering e che, in generale, il ruolo di Utilizzatore di un servizio
TLC è svolto utilizzando direttamente terminali U&S e, indirettamente, reti U&S come risorse (attuazione di
abilità fisica) senza necessità di alcuna capacità conoscitiva né di natura Engineering (come appropriato per NO e
ISM) né di natura Business (come appropriato per SP e Cliente). Ma in effetti non è così! L’Utilizzatore finale di
un servizio TLC, per raggiungere lo scopo desiderato, oltre a fruire dei tecnoservizi di interconnessione o
distribuzione deve operare il terminale, generare, ricevere e interpretare l’informazione cioè deve sapar manipolare
i contenuti informativi del servizio TLC. Seppur in minima parte l’Utilizzatore deve saper operare il terminale a
sua disposizione cioè egli deve possedere una capacità conoscitiva di natura Engineering (che può essere acquisita
dalle “Istruzioni per l’uso” del terminale). Molto spesso i terminali sono così complicati da operare i.e. sono così
poco user friendly, che l’Utilizzatore arriva a possedere solo un know how operativo parziale. causando così un
discriminazione a livello sociale nei confronti di certe categorie di persone meno dotate e.g. anziani (“social & age
discrimination”). In conclusione in questo corso noi riteniamo che una persona fisica “Utilizzatore finale” non solo
41
fruisca di un tecnoservizio di natura Engineering (vedi par.2.5) ma seppur su scala molto ridotta operi essa stessa
in un Ambiente Engineering cioè in effetti svolga un “ruolo Engineering”.
TelCo A
(Retailer)
Service Provider
Customer
TelCo B
(Third Party SP)
Network Operator
ICT Supplier
Bus Eng Relation. PdS 26/10/2007
Fig.1.0.1.11.4 Vista Business di Fig.1.0.1.1.11.3 (Semplificata). Il corso di GST è basato su questo
Modello di riferimento
1.0.2 Sistemi TLC
42
Riassunto: I sistemi TLC sono infrastrutture reali fisico-logico-energetiche reali atte ad abilitare i servizi TLC.
Un sistema TLC, come tutti i sistemi complessi, è costituito da una molteplicità di componenti mutuamente
interconnessi e cooperanti al fine di raggiungere uno scopo comune. I componenti di un sistema TLC sono
classificati in base a due dimensioni: 1) “funzionalità” (funzionalità di rete o terminale) e 2) “tecnologie
implementative” (componenti ICT e componenti ausiliari nonICT) (Tavola 1.0.2.1). I componenti ICT delle reti
e terminali TLC sono ulteriormente classificati in componenti U&S (Utilizzazione & Segnalazione) e
componenti gestionali (par.1.0.2.3) in base alla natura dell’informazione che essi elaborano/trasportano/
immagazzinano. Applicando la “Metodologia dei Punti di Vista” dell’ITU-T (Addendum No.6 in “GST
Addendum”) i componenti del sistema possono essere “descritti/specificati”(Tavola 1.0.2.1) da un Punto di
Vista “Engineering” (o “Build”) come contenitori di Tecnologie ICT con caratteristiche tecniche (Tavola
1.0.2.2) e da un Punto di Vista “Business” (o “Buy”) come insiemi di Risorse TLC con caratteristiche
economico-commerciali (Tavola 1.0.2.3). Le due “Viste” esse sono gestite da persone diverse in modi diversi.
1.0.2.1
•
Introduzione ai sistemi TLC
Definizione
Un sistema TLC è una infrastruttura fisico-logico-energetica reale costituita da reti e da
apparecchiature terminali (“terminali”) ad esse interconnesse, atta ad abilitare servizi TLC. I
termini “infrastruttura logica” e “infrastruttura energetica” fanno riferimento rispettivamente
alle componenti software del sistema TLC e alle fonti di energia necessarie alle operazioni del
sistema.
In certi casi uno stesso sistema TLC può abilitare servizi TLC diversi. In altri casi è
necessario avere uno specifico sistema TLC per abilitare uno specifico servizio TLC e.g. un
servizio di TV satellitare richiede un sistema TLC costituito da satelliti broadcasting in un
orbita geostazionaria e trasmettitori/ricevitori TV opportunamente posizionati e orientati.
Diciamo subito che per noi il termine “rete TLC” assume un significato del tutto
generale che va ben oltre ciò che comunemente si intende per “rete di telecomunicazione” i.e.
un ordito di linee di trasmissione che interconnettono switches o routers ubicati nei suoi nodi.
Ad esempio, vedremo fra poco che una rete TLC include una parte gestionale costituita da reti
informatiche per la gestione dei servizi TLC.
•
Utilizzazione: Risorse materiali e risorse umane
Agli occhi di una TelCo un sistema TLC è certamente una risorsa abilitante i servizi TLC
ma ovviamente non è la sola. Un sistema TLC opera congiuntamente con risorse umane
denominate “Addetti alla Gestione TLC”, persone fisiche reali addette sia alla gestione dei
servizi TLC che alla gestione del sistema stesso. Essi implementano la cosidetta “gestione
manuale” di sistemi e servizi TLC. Tuttavia in questo corso noi ci occuperemo della gestione
di sistemi e servizi TLC ottenuta tramite tecnologie ICT sia hardware che software, e pur
riconoscendone l’importanza, ci occuperemo di gestione manuale solo marginalmente (Vedere
Tavola 1.0.2.1).
43
Noi ci occupiamo di Reti Gestionali Informatiche
visualizzate come insiemi di Tecnologie ICT
(OS, NSS, OSS, BSS)
ABILITAZIONE dei SERVIZI TLC
(TLC Service Enablers)
ADDETTI alla
GESTIONE TLC
(Persone fisiche)
COMPONENTI del
SISTEMA TLC
Funzionalità/
Utilizzazione
“Punto di
Vista”
(Osservatore)
Rete
Terminale
(Interconnessione,
Distribuzione)
(Intermediazione.
Accesso)
Non-ICT
(Componenti
Ausiliari)
(1. ICT Supplier,
2. Service Provider
3. Customer)
ICT
Scopo/Format
dell’Informazione
U&S
TLC
Strutture
meccaniche,
Fonti energ.
Impianti,
Edifici etc.
X
(e.g. rete
postale)
Rete autoferroviaria
Trasporto
aereo
Sistema
informatico
rete postale
Rete
U&S
Gestione
TLC
(e.g. sistema di
accesso alla
rete postale)
Struttura
Meccanica
Terminale
TLC
Struttura
meccanica
sportello
o cassetta
postale
X
Sistema
informatico
sportello
postale
“Vista”
Risorse
RisorseTLC
TLC
(man-made)
(man-made)
(1. Oggetto di compra-vendita
2. Risorsa per fornire/acquisire
servizi TLC)
Terminale
U&S
Rete di Gestione
(1. Manufactur of ICT,
2. Network Operator)
nonTLC
nonTLC
Tecnologie
implementative
Business
Engineering
SISTEMA TLC
(Infrastruttura
fisico-logica-energetica)
Terminale
di Gestione
Generica
Generico
Rete Gestionale
Informatica
Specifico
Tecnologie
TecnologieICT
ICT
(1. Prodotto risultato di attività
di progettazione/costruzione
2. Oggetto di gestione)
Bus Eng relation
Tavola 1.0.2.1 Il significato dei termini “Tecnologie ICT” e “Risorse TLC”. Il sistema TLC reale è di colore giallo
mentre le sue Viste Engineering e Business appartengono ad uno strato superiore (strato di rappresentazione,
representation layer) di colore celeste. Le componenti ICT di reti e terminali TLC sono visualizzate come
Tecnologie ICT se osservate da un Punto di Vista Engineering mentre tutti i componenti del sistema TLC sono
visualizzati come “Risorse TLC (man-made)” se osservate da un Punto di Vista Business. Una impresa TelCo nel
ruolo di Service Provider opera in un Ambiente Business e vede il sistema postale (che utilizza per inviare ai
Clienti fatture, documenti, pubblicità etc.) come un insieme di risorse necessarie per le proprie attività di business
(Risorsa TLC). Le caratteristiche di una Tecnologia ICT sono mostrate nella Tavola 1.0.2.2 mentre quelle di una
Risorsa TLC sono mostrate nella Tavola 1.0.2.3. I terminali U&S e di gestione sono connessi rispettivamente a
reti U&S e reti di gestione. In questo corso noi ci limiteremo a considerare Reti Gestionali Informatiche
visualizzate come Tecnologie ICT (con i sistemi di supporto OS, NSS, OSS, BSS) con la consapevolezza che
esistono aspetti Business altrettanto importanti (e.g. in fase di Product Development)
•
Dimensioni e confini dei sistemi TLC
44
Quanto è grande un sistema TLC e quali sono i suoi confini?
I sistemi TLC presi in considerazione in questo corso sono costituiti da reti TLC che si
estendono su zone geografiche di dimensioni variabili da alcuni metri (“reti locali”) a migliaia
di chilometri (“reti geografiche”). Quindi noi non specifichiamo una misura fisica delle
dimensioni geometriche di un sistema TLC espressa in metri o chilometri. Tuttavia ne
possiamo identificare i confini. Infatti poiché un sistema TLC, così come da noi definito,
include le apparecchiature terminali interconnesse alle reti in modalità wireline o wireless,
esso è in ogni caso delimitato da un confine che si identifica con le interfacce uomo –
macchina dei singoli terminali.
Local Area
Networks
(LAN)
LAN 1
LAN 3
LAN 2
Management
System
User Network
Interface (UNI)
ISM
Support System
Network
Usage &
Signaling
Terminals
BUSINESS or
GOVERNMENT
TLC
CUSTOMER/
USER
ENVIRONMENT
TLC SYSTEM
EXTERNAL TLC
NETWORK
T
Administration
(Customer)
T
T
T
ISM Terminal
Equipment
T
ISM Engineering
Work Force
End Users
Supervisors & Managers
(CFO)
Supervisors & Managers
(CIO)
(CEO, COO)
First Order
Automated
Management
Man-Machine
Interface
(TLC System
Boundary)
First Order
Manual
Management
“Chain of Command”
in a business enterprise
or government institution
Bus Eng Relation
Fig.1.0.2.2 I componenti ICT di un sistema TLC all’interno di una utenza affari o governativa
I terminali fanno parte del sistema TLC. La relazione Terminale (T) – End User è del tipo n:m i.e.
più utilizzatori posson far capo ad uno stesso terminale e più terminali ad uno stesso utilizzatore. .
Quindi nel caso di servizi TLC fissi si tratta di un confine che si snoda all’interno delle
singole Utenze laddove sono ubicati i terminali (vedi Fig.1.0.2.1). Allo stesso tempo notare
come in questo corso le tradizionali interfacce UNI (User-Network Interface) fra terminali e
rete non costituiscano il confine del sistema TLC bensì siano considerate interne ad esso.
45
Questo punto è importante poiché significa che, indipendentemente dalle dimensioni
geometriche delle reti, in questo corso la gestione di un sistema TLC include la gestione dei
terminali assieme alle loro reti locali di interconnessione, Local Area Networks, LAN e
quindi il software gestionale del sistema TLC che noi vogliamo sviluppare includerà
funzionalità di terminale. Come indicato nel par.1.0.1.7 la gestione di terminali e LAN
all’interno di Utenze Affari o Governative avviene ad opera di personale specializzato e
tecnologie ISM (Information System Management) .
•
Sistemi TLC e TLC stakeholders: domini amministrativi
Un sistema TLC è una infrastruttura fisico-logica-energetica reale abilitante i servizi
TLC che coinvolgono stakeholders, i.e. persone fisiche e giuridiche, di diverso tipo: TelCo
(Retailers, Wholesalers, Intermediaries) e Utenti. Quale relazione esiste fra un sistema TLC e
gli stakeholders coinvolti nei servizi TLC? Ovviamente una prima risposta è che questi
stakeholders operano in un contesto economico-commerciale e svolgono attività di compravendita di servizi TLC e, quindi, il sistema TLC è una risorsa da loro utilizzata per svolgere
queste loro attività. Una seconda risposta evidenzia il fatto che in effetti esiste una molteplicità
di stakeholders mutuamente interagenti e che un certo stakeholder gestisce una certa porzione
del sistema TLC. Allora in maniera del tutto generale noi diciamo che una tale porzione di
sistema TLC è un “Dominio Amministrativo (Administrative Domain)” gestita da un certo
stakeholder (autorità gestionale). Ad esempio noi diciamo che un sistema TLC internazionale è
costituito dai domini amministrativi ognuno gestito da un operatore pubblico nazionale (TelCo).
Poiché uno stesso TLC Stakeholder può svolgere più ruoli gestionali, in generale un Dominio
Amministrativo contiene tecnologie abilitanti diversi ruoli. Ad esempio un TLC Stakeholder
“TelCo”, persona giuridica reale, svolge i ruoli di Service Provider e Network Operator e
possiede/gestisce un Dominio Amministrativo con le tecnologie OSS (Operation Support
Systems) e NSS (Network Support Systems).
Allora un sistema TLC è costituito da domini amministrativi separati ma cooperanti
attraverso una molteplicità di Inter Domain Reference Points (IDRP). Una standardizzazione
delle caratteristiche di questi punti e il rispetto di questi standards da parte delle tecnologie
contenute in ciascun dominio (e.g. software applicativo) garantisce la loro interoperabilità e,
conseguentemente, il funzionamento dell’intero sistema TLC. Allora diciamo che
NOTA 1.0.2.1.1 Un “Punto di Riferimento Inter-Domain” (Inter-Domain Reference Point, IDRP)
è la specifica dei requisiti di interoperabilità fra Domini Amministrativi. Se tutti i punti IDRP di
un sistema TLC soddisfano lo standard XYZ si dice che il sistema TLC soddisfa le condizioni di
conformità con lo standard XYZ o è conforma con lo standard XYZ
46
Customer/User
(Utente)
TelCo A
(Retailer)
TelCo B
(Third Party SP)
Customer
Service Provider
Service Provider
User
Network Operator
Network Operator
DOMINIO
AMMINISTRATIVO
d’Utente
IDRP
DOMINIO
AMMINISTRATIVO
di TelCo A
IDRP
DOMINIO
AMMINISTRATIVO
di TelCo B
SISTEMA TLC
Bus Eng Relation. PdS 26/10/2007
Fig.1.0.2.1 Stakeholders, Ruoli e Domini Ammistrativi. Un “dominio amministrativo” è una porzione del
sistema TLC sotto il controllo di una stessa autorità gestionale (stakeholder). I domini amministrativi
cooperano attraverso Inter-Domain Reference Points (IDRP). Nella standardizzazione del software
applicativo i punti IDRP son interfaccie standardizzate i.e. sono i punti dove si verifica la conformità con lo
standard del software prodotto.
1.0.2.2 I componenti di un sistema TLC: funzionalità e tecnologie implementative
Un sistema TLC è un sistema complesso costituito da componenti di vario tipo
interconnessi e cooperanti. Nel Capitolo 2 vedremo come essi possano essere classificati in
varie maniere secondo criteri diversi con vari tipi di tassonomie (rappresentazioni con
architetture gerarchiche). Per il momento è sufficiente classificare questi componenti in base a
due dimensioni perpendicolari come mostrato nella Tavola.1.0.2.1: 1) funzionalità i.e.
capacità logica/abilità fisica di svolgere certe funzioni TLC (funzionalità di rete e di terminale)
e 2) tecnologie implementative (componenti ICT e componenti nonICT)
1). Tecnologie implementative. All’interno di un sistema TLC esistono componenti ICT
realizzati principalmente con tecnologie elettroniche digitali atte a elaborare, immagazzinare o
trasmettere informazione digitale (Tecnologie ICT) e componenti ausiliari nonICT che non
impiegano Tecnologie ICT, o le impiegano in minima parte, ma che tuttavia sono utilizzati per
47
scopi TLC in quanto svolgono un ruolo ancillare di supporto rispetto ai componenti ICT e.g.
strutture meccaniche di supporto o complemento ai componenti ICT, fonti di energia, impianti,
sistemi di condizionamento ambientale, strutture murarie e viarie, edifici e alloggiamenti per
uffici, suppellettili varie etc. (Vedere anche par. 2.1.1 e Fig.1.0.2.2)
2) Funzionalità. Un sistema TLC possiede tutte le funzionalità necessarie ad abilitare i servizi
TLC. Tradizionalmente (ricordate la “pila OSI”?) si distinguono “funzionalità residenti nella
rete” e “funzionalità residenti nei terminali”. Esse sono molto diverse ma entrambe
assolutamente necessarie per telecomunicare. Ad esempio fra le “funzionalità di rete” in una
rete telefonica o rete internet riconosciamo le “funzionalità di interconnessione” fra terminali
TLC remoti mentre in un rete radio-TV riconosciamo “funzionalità di distribuzione”
dell’informazione da una stazione trasmittente a una molteplicità di stazioni riceventi. Fra le
“funzionalità di terminale” riconosciamo le “funzionalità di intermediazione” fra utilizzatore
e rete (“receive-transmit” o “receive only” o “transmit only”) e le “funzionalità di accesso” alla
rete TLC (richiesta di accesso, autenticazione, autorizzazione all’accesso). Tuttavia in questo
corso è importante notare come nella gestione dei servizi TLC vengano ancor oggi usate anche
Reti nonTLC (e.g. rete postale per il trasporto della bolletta del telefono) con i relativi
terminali di accesso (e.g. cassetta postale) cioè reti e terminali non specifici delle TLC ma
utilizzati per svolgere funzioni TLC di natura gestionale. In particolare la Tavola 1.0.2.1
mostra:
i) Reti TLC di interconnessione fra terminali con funzionalità “receive/transmit” o reti di
distribuzione fra centri di produzione & trasmissione di contenuti e terminali con funzionalità
“receive only” e Reti non-TLC che effettuano il trasporto di informazione gestionale relativa ai
servizi TLC su supporto meccanico per via auto-ferroviaria o aerea (e.g. rete postale per l’invioricezione di documenti informativi di natura amministrativa, statistica, pubblicitaria o fatture
relativi ai servizi TLC)
ii) Terminali TLC interconnessi a Reti TLC (e.g. telefono, televisore, computer) e Terminali
non-TLC interconnessi con reti nonTLC e.g. cassetta postale (“buca delle lettere”)
1.0.2.3
•
Componenti ICT di Reti TLC
I flussi informativi dei servizi TLC sono costituiti dall’ informazione elaborata/
immagazzinata/trasmessa da componenti ICT
Qui anticipiamo brevemente e in maniera del tutto preliminare alcuni concetti che tratteremo in dettaglio nel par.
1.2 e nel Capitolo 2 dove studieremo come l’informazione scambiata fra TelCo e Utente possa essere di due tipi in
base al suo format (e.g. protocollo comunicativo) e/o allo scopo per cui essa viene elaborata/
trasmessa/immagazzinata:
I componenti ICT da un punto di vista funzionale, come elementi del sistema TLC,
fanno parte di una infrastruttura abilitante i servizi TLC mentre da un punto dio vista
tecnologico
sono
realizzati
con
Tecnologie
ICT
cioè
tecnologie
che
elaborano/trasportano/immagazzinano informazione digitale. L’informazione processata dai
componenti ICT è la stessa che fluisce nei flussi informativi dei servizi TLC e che noi
classifichiamo in (vedi par.1.2)
48
1) Informazione di Utilizzazione e Segnalazione (U&S) che fluisce durante la fase di
accesso/fruizione e erogazione di un servizio TLC e.g. durante la digitazione di un numero
telefonico e nel corso di una telefonata.
2) Informazione di Gestione che fluisce nelle altre fasi del ciclo di vita di un servizio TLC e,
in particolare durante i processi di gestione delle Reti U&S o dei servizi TLC e.g. quando un
Network Operator effettua la manutenzione di una Rete U&S (gestione di rete) o un Cliente
richiede al Service Provider la installazione di un servizio TLC (gestione servizi).
Le corrispondenti componenti ICT sono classificate in Reti U&S/Terminali U&S e
Reti di Gestione/Terminali di Gestione (Vedi Tavola 1.0.2.1)
1. Reti U&S. Le reti TLC in cui fluisce informazione U&S sono dette “reti U&S”. In generale
la Rete di Signaling è fisicamente separata ma integrata con la Rete di Utilizzazione (vedere
Fig.2.3.1.6). L’insieme integrato di Rete di Utilizzazione + Rete di Signaling costituisce la Rete
U&S. Una Rete U&S è oggetto di gestione da parte delle Reti di Gestione cioè è una “rete
gestite” (vedere Fig.2.3.1.6). Come è noto dai corsi universitari di “Reti per
Telecomunicazioni” le Reti U&S hanno varie topologie anche legate alle tecnologie
implementative scelte (e.g. wireline o wireless) e alle funzionalità che esse devono possedere
e.g. funzionalità di interconnessione (rete telefonica) o funzionalità di distribuzione (rete TV).
Nel caso più generale, le reti di interconnessione, e.g. la rete telefonica, sono suddivise in reti
di accesso (dalla singola postazione di Utente al nodo di accesso alla periferia della rete di
trasporto) e reti di trasporto condivise da tutti gli Utenti. Come già detto, nel caso di Utenze
Affari le reti di accesso sono spesso complementate da reti locali interne alle Utenze e.g. LAN
(Local Area Networks) per l’ interconnessione di CPE (Customer Premise Equipment).
Tradizionalmente in un contesto GST una rete U&S è costituita da vari componenti denominati
Elementi di Rete (Network Elements, NE) i quali devono essere gestiti individualmente,
ognuno con un suo elemento di gestione (OS, Operations System, Sistema di Esercizio) fornito
dal costruttore.
2. Reti di Gestione. La parte di rete TLC in cui fluisce informazione gestionale è denominata
“Rete gestionale o Rete di Gestione”. Le Reti di Gestione possono essere fisicamente separate
o fisicamente coincidenti con le Reti U&S (cioè le Reti U&S possono essere utilizzate ache per
scopi gestionali).
i)
Reti di Gestione specifiche (Reti gestionali informatiche), fisicamente separate dalle
Reti U&S e dedicate alla
trasmissione/elaborazione/immagazzinamento di
informazione/dati di natura gestionale. Si tratta di reti dati che interconnettono
elaboratori digitali (“Sistemi di Supporto”) di vario tipo e.g. OS (Operations Systems),
NSS (Network Support Systems) OSS (Operations Support Systems) e BSS (Business
Support Systems). Nella tradizione della GST, usando una terminologia ITU-T, queste
reti venivano universalmente chiamate Telecommunications Management Networks,
TMN. Lo scopo principale di questo corso è studiare i fondamenti (concetti, principi e
regole) delle Reti Gestionali Informatiche applicando tecniche di Distributed Object
Computing.
49
ii)
1.0.2.4
Reti gestionali generiche, fisicamente coincidenti con le Reti U&S i.e. costituite dalle
stesse Reti U&S ma utilizzate anche per scopi gestionali. Esse
trasmettono
informazione gestionale, la quale può avere o meno lo stesso format (e.g. protocolli
comunicativi) dell’informazione U&S. Ad esempio la rete telefonica pubblica
nazionale PSTN puo fungere da rete U&S o rete gestionale a seconda che venga
utilizzata per una telefonata all’ amico Giorgio per fare due chiacchere (scopo U&S) o
per telefonare al Call Center della Telecom Italia per verificare l’accuratezza di una
bolletta telefonica (scopo gestionale). Nei due casi il format dell’informazione trasferita
è lo stesso ma lo scopo è diverso. Un inconveniente delle Reti Gestionali Generiche è
evidente nella gestione degli elementi di rete U&S: un guasto di un elemento causa
anche un guasto nella rete gestionale!.
Componenti ICT di Terminali TLC
Ragionamenti analoghi valgono per i componenti dei terminali. Come le reti TLC anche i
Terminali TLC sono suddivisi in Terminali U&S, che elaborano/immagazzinano l’
informazione U&S relativa all’essenza dei servizi TLC e sono connessi alle reti U&S e
Terminali gestionali che elaborano/immagazzinano informazione gestionale e sono connessi
alle reti di gestione.
Come le Reti di Gestione anche i terminali gestionali sono suddivisi in
i) “Terminali gestionali generici” i.e. si tratta deli stessi terminali U&S ma utilizzati per
scopi gestionali. Essi sono connessi a reti gestionali generiche e, nella gestione dei servizi
TLC, sono dotati di interfaccia con i Clienti dei Servizi TLC.
Qui notare bene l’uso del termine “Cliente” e non del termine “Utilizzatore”, in quanto è il Cliente che è coinvolto
nella gestione di un servizio TLC e non l’Utilizzatore (l’Utilizzatore “utilizza” solo non “gestisce”)!
ii) “Terminali gestionali specifici” e.g. postazioni di lavoro connesse alle Reti Gestionali
Informatiche e dotate di interfacce con gli Addetti alla Gestione. Nella tradizione della GST,
usando la terminologia ITU-T/TMN, questa interfaccia fisica era standardizzata e veniva
denominata “interfaccia G”
Ad esempio uno stesso telefono puo fungere da terminale U&S o terminale gestionale a
seconda che venga utilizzato per una telefonata all’amico Giorgio o per fare una telefonata al
Call Center della Telecom Italia (nei due casi il format dell’informazione trasferita è lo stesso
ma lo scopo è diverso). In un servizio internet/e-mail il computer è un terminale di utilizzazione
(non c’è “segnalazione”) mentre il telefono per contattare il Call Center dell’Internet Service
Provider è un terminale gestionale generico.
ATTENZIONE ALLA TERMINOLOGIA! Noi usiamo il termine “sistema” in due contesti diversi:
“Sistema TLC” per indicare un sistema costituito dal complesso di grandi reti TLC e dai terminali TLC ad
esse connessi direttamente o tramite reti locali i.e. per indicare la “infrastruttura fisico-logico-energetica”
abilitante i servizi TLC. Usiamo poi il termine “Sistemi di Supporto” per indicare gli elaboratori digitali
specializzati alla gestione delle reti TLC (e.g. NSS, Network Support Systems) o alla gestione dei servizi
50
TLC( e.g. Operation/Business Support Systems, O/BSS). I Sistemi di Supporto fanno parte dei sistemi
informatici gestionali (a loro volta contenute nei sistemi TLC).
1.0.2.5
Lo sdoppiamento Engineering-Business: Tecnologie ICT e Risorse TLC
Un sistema TLC è un sistema reale molto esteso e complesso. In questo corso (contesto
interdisciplinare) come si “descrive” un sistema TLC già esistente o come si “specifica” un
sistema TLC futuro? (Vedi ESEMPIO 1.0.1.2.3 nel par.1.0.1.2). A differenza di quanto
accadrebbe se noi operassimo in un contesto monodisciplinare limitato all’ Ingegneria TLC, in
un contesto intedisciplinare la risposta a questa domanda è: “Dipende dal Punto di Vista
adottato”! Questa risposta può erroneamente apparire evasiva. In vero non è affatto evasiva,
anzi è molto precisa. Essa vuole semplicemente significare che, come gia fatto per i TLC
stakeholders, esistono due risposte diverse a seconda che venga adottato un Punto di Vista
Engineering o un Punto di Vista Business per osservare un sistema TLC reale.
CARATTERISTICHE “BUILD/OPERATE”dei COMPONENTI ICT
di un SISTEMA TLC
1.
specifiche tecniche di funzionamento (*)
2.
creazione & analisi del modello
scelta tecnologie implementative (**)
specifiche strutturali e di sistema (**)
tecniche di progettazione/progettazione (**)
specifiche di costruzione
costruzione prototipi
collaudo prototipi
costruzione e integrazione componenti
costruzione prodotto finale e collaudo
industrializzazione prodotto
3.
4.
5.
6.
7.
8.
9.
10.
11.
Modalità di:
12.
installazione & attivazione
13.
esercizio (prestazioni)
14.
manutenzione
15.
riparazione
16.
sostituzione
17.
disinstallazione
Product Developer
(Ruolo Engineering)
ManTec
Ntwk Operator
(*) Inclusa parte gestionale
(**) Tiene conto della normativa vigente e, se necessario,
di standards tecnici
Tavola 1.0.2.2 Caratteristiche tecniche di produzione e gestione di una Tecnologia ICT messe a fuoco
nella Vista Engineering di un componente ICT.
51
1)
Punto di Vista Engineering
Punto di Vista adottato da un team di ingegneri
progettisti/costruttori che opera all’interno di una impresa manifatturiera di
Tecnologie ICT (Manufacturer of ICT Technology, ManTec) in collaborazione
con una TelCo in fase di “Product Development” di un servizio TLC o adottato
dal “Network Operator” in una TelCo in fase di “Service Delivery”. Da un
Punto di Vista Engineering il sistema TLC è visualizzato
come un contenitore di Tecnologie ICT
Un osservatore “Engineering” (ricordiamo che si tratta “Engineering delle Telecomunicazioni”!)
ha la consapevolezza dell’esistenza e riconosce l’importanza dei componenti nonICT di un
sistema TLC ma non li “mette a fuoco” cioè non ha né interesse né competenze sufficienti per
riconoscerne i dettagli realizzativi, strutturali o gestionali (competenze invece possedute da suoi
collaboratori esperti in ingegneria meccanica. edile, civile etc.). Al contrario un osservatore
“Business” (Vedi Tavola 1.0.2.1), è interessato e mette a fuoco le caratteristiche economicocommerciali di tutte le componenti del sistema ICT ed è meno interessato ai loro dettagli
tecnologici. L’argomento verrà ripreso nel Cap. 2
CARATTERISTICHE “BUY” dei COMPONENTI ICT
di un SISTEMA TLC
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
22)
23)
24)
banda di frequenza, reconfigurability & tunability (funzionanamento)
caratteristiche di memoria & processing power
consumo energetico
RF power handling capability (ingresso/uscita)
end-to-end latency (ritardo di segnale)
jitter (variazione ritardo di segnale)
RAS (Reliability, Availability, Survivability)
massa
dimensioni e forma geometrica
resistenza a vibrazioni
livello di radiation hardening (*)
livello di innovazione tecnologica (generazione tecnologica)
disponibilità di fornitori Off-The-Shelf alternativi (**)
disponibilità di fornitori costruttori alternativi (**)
limitazioni su trasferimenti di tecnologia avanzata dal paese d’origine
caratteristiche del fornitore scelto e.g. nome, indirizzo etc.
tempo di inizio e durata del contratto di produzione
tempi di consegna del prodotto
costo totale del prodotto
piano dei pagamenti
piano di finanziamento
costo e facilità di installazione, manutenzione, disinstallazione
disponibilità/qualità di assistenza tecnica post vendita
amichevolezza di utilizzazione e originalità del design (terminali)
(*) Per applicazioni spaziali
(**) Fornitori alternativi in “multi-source procurement”
Tavola 1.0.2.3 Esempio di caratteristiche di una Risorsa TLC, Vista Business di
52
un componente ICT. La parte in corsivo è condivisa con la Vista Engineering. La parte
barrata non è oggetto di studio in questo corso
2)
Punto di Vista Business Punto di Vista adottato da un team di operatori nelle
unità organizzative “Finance”, “Procurement”, “Sales & Marketing” in una
TelCo o adottato da un Fornitore di tecnologie ICT (ICT Supplier) o da un
qualsiasi Cliente di servizi TLC. Da un Punto di Vista Business un
sistema TLC è visualizzato come un insieme di “Risorse
TLC (man-made)” abilitanti i servizi TLC
NOTA IMPORTANTE. Le “Risorse TLC man-made” (letteralmente: “manufatti”) sono così denominate
per distinguerle dalle “Risorse TLC Umane” che sono la Vista Business delle persone reali “Addetti alla Gestione
TLC” (Vedi Tavola 1.0.2.1). Tuttavia poiché in questo corso noi non ci occuperemo di Risorse TLC Umane, d’ora
innanzi chiameremo le “Risorse TLC man-made” semplicemente “Risorse TLC” senza pericolo di ambiguità.
Quindi ricordare: in questo corso le “Risorse TLC” sono “Risorse TLC man-made” che non comprendono le
“Risorse TLC Umane”!
Possiamo anche dire che le Tecnologie ICT sono la Vista Engineering dei componenti ICT di
un sistema TLC mentre le Risorse TLC sono la Vista Business dei componenti di un sistema
TLC. Allora ci chiediamo: come sono caratterizzati i componenti di un sistema TLC nella due
Viste cioè come sono caratterizzate le Tecnologie ICT e le Risorse TLC?
SPACECRAFT
BUS
COM. PAYLOAD
TRANSPONDERS
PROPULSION
SYSTEM
RECEIVERS
ELECTRIC POWER
(Solar panels, Batteries)
LNA
MIXER
LO
POST
AMP
TRANSMITTERS
BBOBP
SATELLITE
CONTROL
MODEM
SWITCH
ANTENNAS
TELEMETRY& COMMAND
TELEM. UNIT
COMMAND UNIT
TELEM. TRANSMITTER
COMMAND RCVR
FEEDS
REFLECTORS
TELEM. ANTENNA
COMMAND ANTENNA
Mondo TLC
Fig.1.0.2.2 Rappresentazione di un satellite geostazionario per TLC: Componenti ICT
(bordo nero) e componenti ausiliari nonICT (senza bordo). In questo corso noi ci occuperemo
della gestione dei componenti ICT. I componenti ICT possono essere “osservati” da un Punto
di Vista Engineering e in tal modo evidenziarne le caratterisiche tecnologiche oppure da un
Punto di Vista Business e in tal modo evidenziarne le caratteristiche economico-commerciali
53
Le Tecnologie ICT sono caratterizzate da caratteristiche tecniche di produzione e gestione
(Tavola 1.0.2.2). Queste caratteristiche contengono informazione e dati utilizzati nella fasi di
“Product Development” (collaborazione TelCo-ManTec) e “Network Operations” (TelCo). Le
Risorse TLC sono caratterizzate da caratteristiche economico-commerciali (Tavola 1.0.2.3).
Queste caratteristiche contengono informazione e dati utilizzati nei processi di compra-vendita
delle risorse stesse (e.g. in una Telco processi di valutazione di potenziali fornitori o di gestione
del rapporto coi fornitori prescelti (vedi ESEMPIO 1.0.2.1). Parte di queste caratteristiche sono
di natura tecnica (parte in corsivo). In questo corso non ci occuperemo delle caratteristiche
economico-commerciali delle Risorse TLC (parte barrata)
ESEMPIO 1.0.2.1. All’ interno di una TelCo esempi di processi “Buy” sono i processi di “Supply Chain
Capability Delivery” e di “Supplier Requisition Management” mostrati nella Fig. A.3.4 (ITU-T Recom.
M.3050.3 “Enhanced Telecommunications Opeeration Map”, 2004).
1.0.2.6 Esercizi relativi al par.1.0.2 (“Sistemi TLC”)
1.
Cosa è un sistema TLC e quale è il suo confine fisico all’interno di una Utenza?
2.
Il personale addetto alla gestione di sistemi e servizi TLC fa parte di un sistema TLC?
3.
Nello studio interdisciplinare di un sistema TLC si applica inizialmente una filosofia “divide et impera”
separando i vari aspetti “monodisciplinari”. Ma d’altra parte si devono anche poter studiare questi vari
aspetti congiuntamente e con mutuo beneficio. Tutto ciò è possibile aggregando le “Viste” del sistema reale
osservato da vari “Punti di Vista” e applicando la “Metodologia dei Punti di Vista” dell’ITU-T
4.
i)
Quali sono i Punti di Vista adottati in questo corso da cui si osserva un sistema TLC reale e, in
un contesto operativo, chi sono gli osservatori?
ii)
Se si osserva un sistema TLC reale da un Punto di Vista Engineering quali componenti si
visualizzano e perché essi vengono “messi a fuoco”? Perché certe altre componenti non vengono
visualizzate? (Altrimenti detto: Quale è la “Vista Engineering di un sistema TLC?)
iii)
Questo è un corso di “Gestione di Sistemi e Servizi TLC” e quindi esso sarà dedicato solo una
parte della Vista Engineering di un sistema TLC. Quale è questa parte?
iv)
Se si osserva un sistema TLC reale da un Punto di Vista Business quali componenti si
visualizzano (cioè “si mettono a fuoco”)? Fare un esempio di tre componenti visualizzati da un
Punto di Vista Business ma ignorati da un Punto di Vista Engineering. (Suggerimento: Pensare ai
“componenti ausiliari nonICT”)
v)
Cosa si intende per Punti di Vista “Build” o “Buy” (Suggerimento: pensare al significato dei
termini inglesi “build” e “buy”)
Le Tecnologie ICT e le Risorse TLC hanno poche caratteristiche comuni ma molte caratteristiche diverse
i)
Menzionare alcune caratteristiche specifiche di una Tecnologia ICT
ii)
Menzionare alcune caratteristiche specifiche di una Risorsa TLC
(Suggerimento: osservare le Tavole 1.0.2.2 e 1.0.2.3)
5.
Quale è la relazione che lega Tecnologie ICT e Risorse TLC? (Facoltativo: fare una schematizzazione grafica
di questa relazione. Vedi Fig.1.0.2.3).
54
6.
Quale è la differenza fra funzionalità di rete e funzionalità di terminale?
7.
Perché nel corso di GST noi siamo interessati anche a Reti nonTLC e Terminali nonTLC?
8.
Fare l’esempio di componenti nonICT di un sistema TLC e spiegare perché esse non sono visualizzate
allorchè osservate da un Punto di Vista Engineering (Suggerimento: Verificare le definizioni di “Engineering”
e di “ICT”)
9.
Fare un esempio di componenenti nonICT di un Terminale TLC e di un satellite geostazionario per
telecomunicazioni.
10. Come sono classificate le componenti ICT
elaborano/trasportano/immagazzinano?
in base alla natura dell’informaziomne che esse
11. La separazione “Tecnologia ICT-Risorsa TLC” è il risultato di osservazioni effettuate dai Punti di Vista
Engineering e Business. La separazione di una rete TLC in rete U&S e rete gestionale invece è basata su su un
criterio diverso. Quale è questo criterio?
12. Un telefono è un terminale U&S o un terminale gestionale?
Relazione fra Tecnologia ICT e Risorsa TLC
(Diagrammi E-R)
Attività di Sviluppo
& Fornitura
TelCo
Servizio TLC
Specifica
Risorsa
TLC TLC
Risorsa
AMBIENTE BUSINESS
PdV Business
Acquisizione &
Utilizzazione
Componente ICT
reale
PdV Engineering
ManTec
Attività di
Produzione
Tecnologia ICT
Risorsa Engineering
AMBIENTE ENGINEERING
Bus Eng Relation
Fig. 1.0.2.3 Relazione fra Tecnologia ICT e Risorsa TLC
55
1.0.3
Servizi & Prodotti TLC
1.0.3.1
Servizi TLC
Un termine importante che vogliamo definire subito è “servizio TLC”. Tutto il
Capitolo 4 sarà dedicato ai servizi TLC. Qui vogliamo semplicemente introdurre una sua
definizione in maniera del tutto preliminare. La prima cosa da fare è rivisitare i concetti di
funzionalità TLC e funzione TLC o meglio di “possesso di funzionalità TLC” e
“svolgimento di funzione TLC” da parte di un TLC stakeholder o di una tecnologia ICT. Sono
concetti importanti. Infatti è proprio grazie ad essi che noi possiamo riconoscere le relazioni fra
eventi separati come la firma di un contratto per la “fornitura/acquisizione di un servizio TLC”
e la effettuazione di una sessione di “erogazione/fruizione di un servizio TLC”. Inoltre i
concetti di “funzionalità” e “funzione” ci permetteranno di parlare di gestione di sistemi TLC e
servizi TLC in maniera unificata (molto efficace da un punto di vista didattico) e di capire bene
la differenza fra un servizio TLC fornito da una TelCo in un Ambiente Business e un servizio
fornito da una tecnologia ICT in un ambiente Engineering (da noi denominato “tecnoservizio”).
•
Funzioni TLC
Qui riportiamo le seguenti definizioni già introdotte in precedenza (studiate ulteriormente nel
Capitolo 4)
i)
“funzione” è un insieme coerente di “attività” svolto (da una tecnologia o una
persona fisica) per una certa durata di tempo al termine della quale si raggiunge
uno scopo prefissato. Questo scopo può essere raggiunto più o meno bene a
seconda delle effettive condizioni del momento. La “qualità” con cui viene
svolta una funzione è proprio un indicatore del livello di accuratezza con cui
questo scopo viene raggiunto. Oggi, nell’era dell’informazione digitale, al
concetto di “funzione” si associa il concetto di “dati di ingresso” (input data)
che vengono trasformati da una funzione in “dati di uscita” (output data)
laddove per “dati” si intende informazione digitale binaria (segnali elettrici “zero
e uno”). Ad esempio si possono leggere dati da una base dati A, immetterli in un
elaboratore digitale che li elabora, raccogliere all’uscita i dati risultanti e
immagazzinarli in una base dati B. In questo caso svolgere una “funzione”
significa anche effettuare una “operazione” su dati di ingresso per ottenere dati
di uscita e trasferire dati da una base dati ad un altra. Ad una operazione di
elaborazione/trasferimento dati si associa un “flusso di dati” (data flow).
ii)
“insieme coerente” è un insieme di attività mutuamente relazionate secondo una
logica temporale prestabilita. In questa definizione le “attività” sono componenti
elementari di una “funzione”. Tuttavia talvolta le “attività” non sono componenti
atomiche ma sono entità composite a loro volta costituite da “azioni”
mutuamente relazionate da una loro logica prestabilita.
Per una funzione TLC lo “scopo predeterminato” è uno scopo relazionato alle
telecomunicazioni e.g. in una TelCo lo svolgimento di una funzione TLC è finalizzato alla
56
fornitura di un servizio TLC, in una Utenza lo svolgimento di una funzione TLC è finalizzato al
soddisfacimento dei desideri/bisogni di telecomunicazione degli Utilizzatori. La Tavola
1.0.3.3.1 mostra esempi di funzioni TLC e dei relativi scopi da raggiungere
Fra poco, nel par.1.0.3.3, vedremo che le funzioni TLC svolte in una impresa e.g. TelCo
sono svolte secondo modalità predefinite, documentate, supervisionate e controllate al fine di
generare risultati misurabili e ripetibili entro una cornice prestabilita di costi e tempi. In queste
circostanze non di parla più di “funzioni” bensì di “processi” e poiché questi processi sono
finalizzati al conseguimento degli obiettivi di business dell’impresa essi sono denominati
“processi di business” (business processes).
CICLO di VITA di un SERVIZIO TLC
Analisi
di Mercato
Product
Development
Processes
PRODUCT
DEVELOPMENT
Lancio
Commerciale
Network Service (*)
Service
Delivery
Management
Processes
ent
em
g
a
n
Ma
ice
v
r
Se
SERVICE
DELIVERY
Ritiro
(*) Essenza del Servizio (Fase di Utilizzazione & Segnalazione)
Tempo
Bus Eng relation
Fig.1.0.3.1.1 Macrostruttura temporale del ciclo di vita di un servizio TLC
•
Funzionalità TLC e relazione “Funzionalità-Funzione”
Una “funzionalità TLC” è una potenzialità definita come “capacità
conoscitiva/abilità fisica” di svolgere una funzione TLC (vedi par. 1.0.1.1). Ricordare la
metafora “la mente e il braccio” e il termine Inglese “capability”, crasi dei termini “capacity” e
57
“ability”. “Funzionalità TLC” e “ funzione TLC” sono relazionate attraverso un processo di
“attuazione” o di “messa in atto” come segue:
“Lo svolgimento di funzioni TLC da parte di TLC stakeholders (e.g. TelCo o Utente) o
tecnologie ICT è la attuazione (messa in atto) di corrispondenti funzionalità TLC specifiche
da loro possedute” ( Relazione “funzionalità-funzione”).
Come già detto, questa “messa in atto” è poi praticamente possibile e avviene con vari
livelli di qualità in base a certe condizioni di attuazione e.g. posso telefonare se il numero
telefonico chiamato non è occupato e se la persona chiamata vuole rispondere, posso telefonare
“bene” se non ci sono interferenze di crosstalk, posso vedere un programma TV solo se un
temporale non blocca il downlink dal satellite all’ antenna TV installata sul tetto di casa, etc.
•
“Ciclo di vita” di un servizio TLC: macrostruttura temporale (Fig.1.0.3.1.1)
Uno dei concetti più importanti che vogliamo acquisire in questo corso e che è di grande
rilevanza nello studio di GST è il seguente. Quando si parla di “servizio TLC” non si fa
riferimento ad un episodio isolato di breve durata fra un Fornitore e un Utente che si verifica ad
un certo istante di tempo e poi scompare. Si fa invece riferimento a una aggregazione di
funzionalità/funzioni che viene dapprima creata a livello industriale con la partecipazione di
molteplici TLC stakeholders (e.g. imprese manifatturiere, imprese TelCo su richiesta di vaste
comunità di Utenti) e poi si dipana nel tempo lungo un intervallo dell’ordine degli anni,
secondo “fasi di un ciclo di vita”.
L’uso dell’espressione “ciclo di vita di un servizio TLC” (“TLC service lifecycle”)
piuttosto che semplicemente “tempo di vita di un servizio TLC” (“TLC service lifetime”) allude
al fatto che un certo servizio TLC non solo ha una durata limitata che va dal momento della sua
definizione al momento del suo ritiro (service retirement), ma fa anche parte di una successione
temporale di generazioni di servizi TLC sempre più innovative (e.g. con
prestazioni/qualità/prezzo sempre migliori), ognuna delle quali ha un suo ciclo di vita. Quando
i tempi sono maturi, una TelCo ritira un servizio di vecchia generazione (legacy service) e lo
sostituisce con un servizio di nuova generazione (new generation service) con caratteristiche
innovative iniziando così un nuovo ciclo di vita. Quindi è importante ricordare che come un
sistema TLC estende le sue reti su certe regioni geografiche più o meno vaste così un servizio
TLC si sviluppa lungo un “ciclo di vita” che si estende per un periodo di tempo più o meno
lungo e che altresì si inserisce in una successione temporale di generazioni di servizi in un
processo di innovazione continua (“innovazione dei servizi TLC” vedi Addendun No.5 in
“GST Addendum”).
All’interno di una TelCo il ciclo di vita di un servizio TLC si articola in in una
molteplicità di fasi (strisce orizzontali in Fig. 1.0.3.1.1) all’interno delle quali vengono svolti
certi processi. Fasi e processi vengono classificati come segue (Vedi E.Ward “World Class
Telecommunications Service Development”, Artechhouse, 1998)
1) Si introduce un macroprocesso di “Product Development” (Sviluppo di Prodotto)
che inizia con una fase di “Ricerca di Mercato” e finisce con una fase di “Lancio commerciale
58
del servizio TLC”. In questo caso il “Prodotto” è il “Servizio TLC” . Questo macroprocesso è
seguito da un macroprocesso di “Service Delivery” (Fornitura) che termina con la
disinstallazione (Retirement) del servizio TLC
2) All’interno del macroprocesso di Service Delivery si riconosce una fase di
Utilizzazione & Segnalazione (U&S) durante la quale si svolge l’ accesso/fruizione e
erogazione dell’ essenza del servizio TLC (TLC service core) usualmente denominata
“Tecnoservizio di Rete” (“Network Service”) mentre tutte le rimanenti fasi sono fasi
gestionali durante le quali avviene la gestione del servizio TLC. Nelle fasi gestionali si
svolgono i Processi gestionali di Service Delivery.
Allora, in definitiva, da questo schema di ciclo di vita abbiamo appreso quanto segue: 1)
una TelCo produce un servizio TLC con un macroprocesso di Product Development. 2) Il
servizio TLC si articola in una “essenza del servizio” (“tecnoservizio di rete”) erogata/fruita
in una fase di Utilizzazione e Segnalazione e una “gestione del servizio” effettuata nelle
rimanenti fasi del macroprocesso Service Delivery.
OFFERTA - RICHIESTA
TelCo
Utente
Offre
(Classe)
TIPO di SERVIZIO TLC
Richiede
(Istanza)
A. Richiesta da Catalogo Prodotti
R. Accettazione Richiesta
FORNITURA - ACQUISIZIONE
Cliente
Cliente
Service
ServiceProvider
Provider
Fornisce
ISTANZA di SERVIZIO TLC
Acquisisce
A. Trasferimento di Funzionalità
R. Condivisione di Funzionalità
EROGAZIONE - FRUIZIONE
SESSIONE di SERVIZIO TLC
Concede
Network
NetworkOperator
Operator
Eroga
A. Richiesta Accesso/Autoriz.
R. Concessione Accesso/Autoriz.
A. Svolgimento di Funzione (*)
R. Trasferimento di Informazione
Tempo
del
(*) Attuazione di Funzionalità, A = Attività. R. = Risultato
Ciclo di Vita
Richiede
Fruisce
Utilizzatore
Utilizzatore
Bus Eng relation
Fig.1.0.3.1.2 Offerta-Richiesta, Fornitura-Acquisizione e Erogazione-Fruizione di servizi TLC
59
•
Funzinalità/funzioni durante la “Service Delivery” (Fig.1.0.3.1.2)
Il macroprocesso di “Service Delivery” è di nostro particolare interesse in quanto le
corrispondenti attività vengono svolte da TelCo e Utente, i due TLC stakeholders che noi
vogliamo studiare con maggiore attenzione in questo corso in quanto dotati di caratteristiche
specifiche delle TLC. Durante la “Service Delivery” (vedi Fig.1.3.1.2) cioè dopo il lancio
commerciale del servizio e offerta pubblica di un Catalogo Prodotti (e.g. servizi ed eventuali
tecnologie di terminale), è molto importante distinguere fra fase di Fornitura/Acquisizione di
un Servizio TLC come fornitura/acquisizione di un insieme coerente di funzionalità effettuata
dalla coppia Service Provider/Cliente e la fase di Erogazione/Fruizione (dell’essenza) di un
Servizio TLC come effettivo svolgimento delle corrispondenti funzioni da parte della coppia
Network Operator/Utilizzatore allorché se ne presenta la necessità. In entrambi i casi le entità
reali che intervengono sono la TelCo e l’Utente.
NOTA BENE Ricordare che Service Provider e Network Operator sono ruoli svolti dalla entità reale “TelCo”
mentre Cliente e Utilizzatore sono ruoli svolti dalla entità reale “Utente”. TelCo e Utente sono TLC stakeholders
reali
La “Fornitura/Acquisizione” e la “Erogazione/Fruizione” di un servizio TLC sono due
fasi diverse del ciclo di vita di un servizio TLC separate e intrinsecamente diverse che
coinvolgono ruoli diversi di TelCo e Utente, avvengono in luoghi e tempi diversi con
conseguenze pratiche molto diverse. Esse sono tuttavia mutuamente relazionati dalla relazione
“funzionalità – funzione” i.e. lo svolgimento di una funzione TLC (telefonata) è la attuazione
nel momento del bisogno delle corrispondenti funzionalità acquisite nel momento in cui il
servizio telefonico è stato sottoscritto (firma del contratto SLA, Service Level Agreement).
La relazione “funzionalità-funzione” ha conseguenze pratiche importanti sulle relazioni
Cliente-Utilizzatore particolarmente nelle Utenze Affari o Governative dove Cliente e
Utilizzatore sono persone fisicamente separate all’interno di una stessa Utenza. In queste
circostanze dapprima il Cliente (persona giuridica amministrativa) acquisisce un servizio TLC
da un Service Provider e diventa titolare dell’Utenza. In un secondo tempo egli abilita &
autorizza gli Utilizzatori (persone fisiche) all’interno della sua Utenza a fruire del servizio
acquisito ogni qualvolta essi ne hanno desiderio/bisogno. Infine, se gli Utilizzatori sono “ospiti
a pagamento” dell’ Utenza (e.g. nel caso di alberghi, ristoranti, ospedali etc.) il Cliente
supervisiona/misura i loro consumi per preparare i relativi addebiti/fatture.
•
Fornitura/acquisizione di un servizio TLC (Fig.1.0.3.1.2)
La “fornitura di un servizio TLC” è la “fornitura di un insieme coerente di
funzionalità TLC da una TelCo (ruolo: Service Provider, SP) a un Utente (ruolo: Cliente), atte a
risolvere problemi che insorgono (o insorgeranno) presso l’Utente nel momento in cui egli
decide (o deciderà) di soddisfare certi suoi desideri/bisogni di telecomunicazione”.
Analogamente la “acquisizione di un servizio TLC” è la “acquisizione di un insieme coerente
di funzionalità TLC da parte di un Utente (ruolo: Cliente) per risolvere certi suoi problemi
insorti (o che insorgeranno) a causa di desideri/bisogni di telecomunicazione da soddisfare”. La
fornitura/acquisizione di un servizio TLC avviene formalmente con un atto di compra-vendita
60
fra SP e Cliente e con la sottoscrizione da parte di quest’ ultimo di un contratto SLA (Service
Level Agreement).
Attività: trasferimento di funzionalità.
Risultato: Condivisione di funzionalità.
•
Erogazione/fruizione di un servizio TLC (Fig.1.0.3.1.2)
La “erogazione di un servizio TLC” è lo “svolgimento di un insieme coerente di
funzioni specifiche di un servizio TLC (attuazione di un insieme coerente di funzionalità
specifiche) da parte di una TelCo (ruolo: Network Operator) su richiesta di un Utente (ruolo:
Utilizzatore) con lo scopo di risolvere problemi insorti presso quest’ultimo allorché egli decide
di soddisfare certi suoi desideri/bisogni di telecomunicazione”. La “fruizione di un servizio
TLC” o “utilizzazione di un servizio TLC” o “consumo di un servizio TLC” è la “la
attuazione di un insieme coerente di funzionalità TLC possedute da un Utilizzatore (e a lui
cedute dal Cliente titolare dell’Utenza), con lo scopo di risolvere problemi insorti allorché egli
decide di soddisfare certi suoi desideri/bisogni di telecomunicazione”. Erogazione e
fruizione/utilizzazione di un servizio TLC avvengono contestualmente e sono inseparabili: si ha
effettiva erogazione di un servizio TLC soltanto là dove esiste effettiva fruizione/utilizzazione.
Attività: Svolgimento di funzione (specifica di quel particolare servizio)
.
Risultato: trasferimento di informazione fra due utilizzatori.
NOTA FACOLTATIVA 1.0.3.1 Una variante del processo di “attuazione” di una funzionalità specifica: la
“attualizzazione” di una funzionalità generica.
Una funzionalità TLC ha un carattere di “potenzialità”. In generale, se la funzionalità TLC acquisita è
specifica di una certa funzione TLC da svolgere essa può essere direttamente attuata nello svolgimento di
questa funzione con una qualità “QoS erogata” dipendente da certe “condizioni di attuazione”. Invece se la
funzionalità TLC acquisita è generica (i.e. non è specifica della funzione TLC da svolgere) essa va prima
specializzata o “resa attuale” e solo dopo può essere attuata nello svolgimento di una funzione TLC
specifica. Noi useremo il termine “attualizzare” per significare “Rendere attuale” + “”Attuare”. Facciamo
un esempio: 1) il possesso delle Pagine Bianche di un servizio telefonico fisso è un possesso di capacità
conoscitiva generica, 2) acquisire dalle Pagine Bianche un numero telefonico desiderato significa “rendere
attuale” questa capacità generica ed entrare in possesso di una capacità specifica della funzione che
intendiamo svolgere 3) digitare sulla tastiera del telefono il numero telefonico trovato significa “attuare”
questa capacità specifica nello svolgimento della funzione desiderata 4) combinando i punti 2) e 3) diciamo
che la capacità conoscitiva generica iniziale (possesso delle Pagine Bianche) viene “attualizzata” nello
svolgimento di un funzione specifica: la digitazione di un numero telefonico sulla tastiera del telefono.
Questi argomenti verranno ripresi nel Capitolo 4.
•
“Prodotti TLC” e “Servizi TLC”.
In precedenza abbiamo detto che nel ciclo di vita di un servizio TLC si riconosce un
periodo iniziale denominato “Product Development” durante il quale un servizio TLC viene
sviluppato. Perché usiamo il termine “Product” cioè “Prodotto” invece di “Service” cioè
“Servizio”? Essenzialmente per due motivi:
61
1) Il termine “Prodotto TLC” ha un significato più generico di “Servizio TLC” cioè, come
caso particolare, un Prodotto TLC può essere un singolo Servizio TLC. Infatti il termine
“Prodotto” indica qualsiasi offerta tangibile o intangibile che una TelCo può fare agli Utenti
e.g. un mix di tecnologie ICT (e.g. telefoni di diverso tipo) o un mix di tecnologie ICT e servizi
TLC (e.g. telefoni e servizi telefonici di diverso tipo) un mix di servizi diversi (servizi telefonici
di base e servizi a valore aggiunto). Noi diremo che le offerte fatte da una TelCo agli Utenti
sono contenute in un “Catalogo Prodotti” e che un Cliente fa le sue scelte basandosi su un
“Catalogo Prodotti”
.
2) “Product Developmant” fa riferimento ad un processo di produzione di prodotti tangibili
o intangibili ed è un termine largamente accettato, e quindi comprensibile, sia alle industrie
manifatturiere che alle imprese fornitrici di servizi. In particolare, dire che un servizio TLC è
sviluppato in una fase di Product Development del suo ciclo di vita vuole enfatizzare il fatto che
esso viene sviluppato con processi di produzione ben noti a tutti gli operatori coinvolti (vedi
par.1.0.1.3) i.e. sia al fornitore di servizi TLC che alla manifatturiera di tecnologie ICT (la
collaborazione TelCo – ManTec è essenziale in questa fase, vedi par.1.0.1.3). Vedere “Product
Development Orientation” Capitolo 3 in E.Ward “World Class Telecommunications Service
Development”, Artech House, 1998.
Ad esempio, il TeleManagement Forum, TMF adotta le seguenti definizioni:
Offerta di Prodotti (Product Offering): Beni tangibili e intangibili e servizi resi disponibili
ad un certo prezzo in un certo mercato sottoforma di “catalogo prodotti” (product catalog)
Prodotto (Product): Istanza di una “Offerta di Prodotti” sottoscritta da un Cliente, specificata
in termini di un nome e di un produttore (nome, indirizzo geografico, numero telefonico,
indirizzo internet etc.) e di un prezzo assieme a condizioni di vendita e di assistenza postvendita.
Ripetiamo che il concetto di “Prodotto” è più generale del concetto di “Servizio”: un
particolare servizio TLC può essere una parte di un Prodotto TLC offerto da una TelCo
(mentre non è vero il contrario). Molto spesso un Cliente acquisisce da uno stesso SP un
“package” (in Italiano “confezione”) personalizzato di diversi servizi TLC (e.g. servizio di base
+ selezione di servizi a valore aggiunto) assieme ad apparecchiature terminali a diverse
condizioni di vendita (e.g. prese in affitto o leasing). In tal caso si dice che il Cliente acquisisce
un “prodotto TLC” (TLC product) personalizzato o customizzato e non un semplice “servizio
TLC”. Quindi in un contesto Marketing di offerta servizi TLC alcuni autori (in particolare il
TeleManagement Forum) preferiscono usare il termine “prodotto TLC” invece del termine
“servizio TLC”. Essi dicono anche che una “Utenza” utilizza un particolare “Prodotto TLC”
(i.e. uno o più servizi e terminali TLC offerti da una certa TelCo).
ATTENZIONE. Pericolo di confusione! Spesso in letteratura si trova usato il termine “prodotto” nel senso di
“bene tangibile” o “bene materiale” in opposizione a un “servizio” che è immateriale e intangibile. Quindi talvolta
si legge che vengono forniti “prodotti e servizi” per indicare “beni materiali e servizi immateriali”.
62
1.0.3.2 Caratteristiche di un servizio TLC
Tutti coloro che hanno bisogno/desiderio di telecomunicare sono pronti a pagare per certi
servizi TLC e relative tecnologie abilitanti cioè gli Utenti alimentano una “domanda” e un
mercato dei servizi TLC (vedi “Service Market” e “Terminal Equipment Market” in
Fig.1.0.1.4). In corrispondenza ad una domanda per servizi TLC esiste una “offerta” di servizi
TLC da parte di imprese TelCo e una offerta di tecnologie ICT da parte di imprese ICTS
fornitrici di tecnologie. Per “mercato” noi intendiamo proprio l’ambiente, anche non fisico, in
cui avviene l’incontro fra “domanda” e “offerta” i.e. dove avviene lo “scambio” di beni e/o
servizi TLC. (laddove per “scambio” si intende la fornitura di alcunchè a fronte di un
pagamento). Ora la erogazione/fruizione dei servizi TLC e la utilizzazione di reti e terminali da
parte rispettivamente di TelCo e Utenti hanno tre tipi di caratteristiche di diversa natura:
1. caratteristiche generiche comuni con tutti gli altri servizi (vedi Fig.4.4.1 nel Cap.4).
Infatti avvengono in un “contesto relazionale” caratterizzato dalle coppie domanda-offerta,
fornitura-acquisizione, erogazione-fruizione, sono caratterizzati da una certa “Quality of
Service” (QoS), hanno un “contenuto” o “parte essenziale” finalizzata al soddisfacimento delle
specifiche necessità/aspettative dell’Utente e una parte “gestionale” di natura ancillare rispetto
alla prima
2. caratteristiche dei servizi di utilità pubblica (public utilities) come la distribuzione
di acqua, gas, energia elettrica (e.g. servizi 24/7, regolamentazione, servizio universale,
monopolio naturale etc.) e infine
3. caratteristiche specifiche dei servizi TLC (Vedi anche la “Premessa” al Capitolo 1 a
pag.4). Forniamo qui di seguito un elenco di caratteristiche possedute dai servizi TLC.
i)
MODALITA’ di FORNITURA. Dipende dalla natura del servizio. Almeno i servizi
definiti “di base” (e.g. telefonia, internet, radio-TV) devono essere disponibili agli utenti
a tutte le ore tutti i giorni della settimana (cioè si tratta di servizi cosiddetti “24/7”)
ii)
MODALITA’ di TRASFERIMENTO dell’INFORMAZIONE. All’interno di un
servizio TLC l’informazione è sempre trasferita per via elettromagnetica su portante
man-made ma con diverse modalità: in modalità unidirezionale i.e. trasmessa da un
centro di produzine a tutti o a una comunità prestabilita di Utenti (Utenti “receive only”)
o in modalità bidirezionale i.e. prodotta/ricevuta da Utenti dotati di funzionalità di
trasmissione/ricezione. In modalità bidirezionale l’ informazione può essere scambiata
fra Utenti in tempo reale o in tempo differito a seconda dei tempi di risposta (ritardo
praticamente zero o indeterminato). Nel primo caso useremo anche l’espressione
“scambio interattivo” o, nel caso di informazione audio, “modalità conversazionale”
(e.g. telefonia vocale).
iii)
NATURA dell’INFORMAZIONE. La natura dell’informazione alla sorgente o
trasmessa lungo una linea di trasmissione di una rete TLC può essere di varia natura e.g.
voce, testo, dati, immagini statiche, immagini in movimento (video). Nel caso in cui
flussi di informazione di natura diversa fluiscano in maniera “integrata” all’interno di
uno stesso servizio TLC e su una stessa linea trasmissiva noi useremo il termine
“servizio multimediale” (e.g. teleconferenza multimediale).
63
iv)
DISTRIBUZIONE GEOGRAFICA. I servizi TLC in generale hanno una
distribuzione geografica dipendente da vari fattori: natura del servizio, tipo di tecnologia
abilitante (e.g. wireline o wireless), criteri economici (i.e. capacità installata dipendente
dalla distribuzione geografica della domanda), criteri politici. Alcuni servizi “di base”
(e.g. telefonia locale) sono garantiti dallo stato a tutti i cittadini indipendentemente dalla
loro ubicazione geografica (vedi anche “Servizio Universale” qui sotto)
v)
TARIFFE. Le tariffe per servizi definiti “di base”, e.g. telefonia locale, devono essere
tali da rendere questi servizi accessibili e soddisfacenti per tutti i cittadini (“servizio
universale”). In generale esistono tariffe diverse per servizi e profili di utilizzazione
diversi: A) canone mensile fisso e consumo illimitato, B) pagamento a consumo C)
canone mensile fisso e consumo illimitato per certi servizi (e.g. telefonia locale) +
pagamento a consumo (durata o volume) per altri servizi (e,g, telefonia long distance).
vi)
COSTO del SERVIZIO.
Una Utenza comporta un “costo fisso” di
connessione/accesso alla rete indipendente dalla durata (minuti) o dal volume di
informazione (bytes) scambiata durante le sessioni di servizio e un “costo variabile”
rappresentativo dell’effettivo uso della rete TLC (e.g. tempo o volume d’informazione
relativo alle sessioni effettuate in un bimestre). Talvolta la tariffa applicata per un
particolare servizio rispecchia questa struttura di costo ed ha una componente fissa
(“accesso” alla rete, ottenuto in fase di fornitura/acquisizione del servizio TLC) e una
componente variabile (“uso” della rete, effettuato durante la erogazione/fruizione del
servizio TLC). Una tariffa a due componenti ha implicazioni significative sul
posizionamento competitivo di una TelCo in un libero mercato. Infatti, in termini di
tariffe/prezzi di un servizio TLC, “accesso” alla rete e “uso” della rete sono
interdipendenti: 1) se il prezzo di accesso diminuisce, aumenta il numero di Utenti e
quindi molto probabilmente aumenta l’uso della rete, 2) se il prezzo pagato dall’Utente
per l’uso della rete aumenta in modo tale da rendergli il rapporto benefici/costo totale
poco attraente, diminuisce la domanda d’accesso alla rete e quindi nel tempo diminuisce
il numero di Utenti (vedi I.Walden, “Telecommunications Law and Regulation” Second
Edition, Oxford University Press, 2005, pag.32).
vii)
REGOLAMENTAZIONE. I servizi TLC sono stati forniti per un secolo in condizione
di monopolio statale e solo da circa dieci anni esiste un libero mercato dei servizi TLC
aperto alla concorrenza (Vedi Appendice 1 al Cap.1). Oggi in questo mercato operano
ex-monopolisti (incumbents) che gradualmente sono costretti a lasciare le loro posizioni
di predominio e offrire a nuove imprese concorrenti (new entrants) “uguali opportunità
di business” (il cosidetto “leveled playing field”). Il regime concorrenziale di pari
opportunità nei mercati TLC è sottoposto/controllato a/da una “regolamentazione delle
TLC” che viene legiferata dai governi nazionali e messa a punto da National Regulatory
Authorities (NRA) che ne vigilano il rispetto con potere sanzionatorio. Ma dopo dieci
64
e-TOM model of TeleManagement Forum
Zero Level View
2. Gestione Operazioni
1. Gestione SIP
(Strategie, Infrastrutture
Prodotti)
(*)
Mappa TOM
(Telecommunications
Operation Map)
3. Gestione Impresa
(*) Gestione della “readiness” dei sistemi di supporto
etom1
Fig.1.0.3.3.1 Classifica di alto livello dei processi di business all’interno di una TelCo proposta dal Tele
Management Forum (modello e-TOM). I Sistemi di Supporto di questi processi sono: NSS/OS (Network
Support Systems/Operations Systems) per reti e loro elementi, OSS (Operations Support System) per i
processi operativi di gestione servizi e BSS (Business Support Systems) per la gestione delle relazioni di
business con stakeholders esterni (Clienti, TelCo partners, ICTS suppliers). La mappa e-TOM è una
estensione standardizzata della mappa TOM del TMF.
65
1. attività di assessment & benchmarking, produzione (pianificazione, analisi, specifica, progettazione, costruzione,
collaudo, lancio commerciale) gestione tecnica (installazione, configurazione, operazione, manutenzione,
amministrazione, sicurezza) di sistemi TLC o loro componenti (TLC equipment) o elementi (TLC devices), Vedi
“Codice delle comunicazioni elettroniche” e “Testo unico della Radiotelevisione”
2. attività di ricerca di base (ER & S, Exploratory Research & Studies) e/o applicata (R & D, Research & Development)
relative a sistemi TLC o loro componenti o elementi o servizi TLC,
3. attività di assessment dello stato dell’arte tecnologico o di innovazione e sviluppo tecnologico nel campo delle
telecomunicazioni,
4. attività didattica di insegnamento/apprendimento relativa ai punti 1-3.
5. attività di produzione (pianificazione, specifica, progettazione, sviluppo, lancio commerciale) e gestione di servizi
TLC (*)
6. attività di compra/vendita di servizi TLC e/o compra/vendita di sistemi TLC e loro elementi,
7. attività di raccolta d’informazione, ordinazione, acquisizione, utilizzazione, gestione di servizi TLC
8. attività di fornitura di contenuti a broadcasters (streaming media) o a internet cyberspaces (*)
9. attività di broadcaster
10. attività di gestione (interne o in outsourcing) di business processes in imprese telecom
11. attività di fornitura in outsourcing di servizi TLC a imprese generiche
12. attività di finanziamento di imprese telecom
13. attività didattica di insegnamento/apprendimento di conoscenze relative ai punti 5-12
14. attività di produzione (definizione, formulazione, erogazione) di leggi e regolamentazione di servizi o sistemi TLC
15. attività di applicazione di regolamentazione (regulatory compliance) di servizi o sistemi TLC
16. attività relativa alla produzione o applicazione di normativa giuridica (Diritto TLC) relativa al comportamento
sociale di “persone TLC”
17. attività di standardizzazione o applicazione di standards relativi a servizi o sistemi TLC su piano nazionale,
regionale o internazionale
18. attività di insegnamento/apprendimento di conoscenze relative ai punti 14-17
19. definizione di strategie CSR (Corporate Social Responsability) & definizione/implementazione di politiche CSR,
incluso stakeholder management, nell’ambito di imprese telecom
20. monitoraggio, assessment, rating e reporting delle attività CSR nell’ambito di imprese telecom
21. attività svolte da stakeholders (e.g. rendere pubbliche opinioni, prendere decisioni, mostrare atteggiamenti, avere
comportamenti) tali da influenzare in maniera significativa la performance socio-economico-ambientale di imprese
telecom,
22. produzione di principi, linee guida o standards CSR per imprese telecom
23. promozione di attività CSR per imprese telecom
24. insegnamento/apprendimento di conoscenze relative ai punti 19-23
Tavola 1.0.3.3.1 Esempi di attività rilevanti alle TLC (funzioni TLC)
visualizzate dai Punti di Vista ST&E, Business, Leg-Reg e Social
66
1.0.3.3
•
“Funzioni TLC” e “Processi TLC”
Funzioni TLC
Noi usiamo il termine “funzione TLC” per indicare un insieme coerente di attività
finalizzate al raggiungimento di uno scopo TLC prestabilito entro un dato tempo. La Tavola
1.0.3.3.1 mostra esempi di attività/funzioni TLC classificate in raggruppamenti corrispondenti
ai Punti di Vista SE&T (Science, Engineering & Technology), Business, Leg-Reg (LegislativeRegulatory) e Social definiti nell’ Appendice 4 al Capitolo 1. “Coerente” significa che le
attività vengono eseguite secondo una logica prestabilita.
A queste attività possono partecipare più persone fisiche o giuridiche e/o tecnologie e.g. nel
caso della funzione “fornitura/acquisizione di un servizio TLC” si tratta di collaborazione fra
una TelCo (persona giuridica nel ruolo di Service Provider) e un Utente (persona fisica per
Utenze Consumer o persona giuridica per Utenze Affari entrambe nel ruolo di Cliente).
L’esistenza di un “fine predeterminato” (scopo/durata) che può essere conseguito più o meno
accuratamente permette anche di associare ad una funzione una “qualità” indicativa del livello
di accuratezza raggiunto.
Il concetto di “funzione” fa riferimento ad attività svolte in un contesto del tutto generale.
Storicamente in campo GST esse sono state introdotte dall’ITU-T come “System Management
Functions” che costituivano i building blocks (cioè le componenti elementari) dei “TMN
Management Services” (TMN = Telecommunications Management Network), servizi offerti
dalle reti gestionali ai gestori di reti TLC (e.g. un Network Operator in una TelCo).
•
Processi TLC
Cosa diversa è un contesto aziendale, e.g. in una TelCo, dove le attività sono
tipicamente incentrate sul business e sulle relazioni con i Clienti cioè sono “business e customer
centric”.In un contesto aziendale le attività vengono svolte in maniera altamente prescritta i.e. le
attività sono predefinite, documentate, supervisionate e controllate, generano risultati
misurabili e ripetibili entro una cornice prestabilita di costi e tempi. Ma non solo. In una
impresa le attività sono anche finalizzate al conseguimento degli “obiettivi di business” dell’
impresa stessa, definiti dal senior management in fase di pianificazione strategica.
DEFINIZINE 1.0.3.3.1 In un contesto aziendale, un processo di business è un
insieme di attività fra loro interrelate, finalizzate alla realizzazione di un risultato
definito e misurabile (bene/servizio interno o esterno) che contribuisce al
raggiungimento della missione dell’organizzazione e che trasferisce valore al
ricevitore del bene/fruitore del servizio.
(C.Batini, Sistemi Informativi”, Volume 1, Franco Angeli, pag.15)
Quando tutto ciò avviene in una TelCo per gestire sistemi e servizi TLC noi diciamo che si
svolgono “processi gestionali” (management procressses) i quali sono anche “processi di
business” (business processes). Quindi in effetti si parla di “processi di business gestionali”.
67
Poiché in questo corso noi ci occupiamo solo di GST, laddove non sorgano ambiguità di
interpretazione, per semplicità noi useremo il termine “processo di business” o semplicemente
”processo” per indicare un “processo di business gestionale”. In questo caso i dettagli delle
modalità operative (tempi e metodi), degli agenti partecipanti (risorse umane e/o tecnologie
abilitanti) e la natura dei singoli processi e le loro mutue relazioni nel dominio del tempo
(workflow architecture), sono indicati nella “specifica” o “mappatura” dei processi e dei
flussi di processi. Nel prossimo paragrafo vedremo che oggi all’interno di una TelCo, per
ragioni di efficienza/efficacia e in presenza di mercati TLC rapidamente evolutivi e competitivi,
il numero e la discrezionalità degli agenti umani addetti ai processi sono ridotti al minimo
indispensabile mentre un numero crescente di processi è automatizzato con software
gestionale installato in processori digitali (e.g. processi gestionali per le relazioni con i clienti e
con imprese partners e suppliers). Le problematiche della automazione dei processi di business
all’interno di una TelCo verranno ampiamente e dettagliatamente affrontate durante la prima
parte di questo corso (e.g. vedi par.1.2.6.2)
La Fig. 1.0.3.3.1 mostra una classifica di alto livello dei processi di business all’interno
di una TelCo specificata dal TeleManagement Forum a da noi adottata in questo corso. In una
TelCo esistono tre classi di processi di business (processi aziendali) rilevanti alla gestione di
sistemi e servizi TLC:
1) Processi SIP (Gestione delle Strategie e dei cicli di vita di Infrsatruttura e Prodotti)
2) Processi per la gestione delle Operazioni (Processi operativi)
3) Processi per la gestione di impresa
•
Riassumendo….
Ricapitoliamo. In questo corso useremo il termine “funzione” allorché vogliamo
indicare quali attività sono svolte e per quali scopi (i.e. non ci interessa conoscere la logica con
cui si dipanano le varie attività nel dominio del tempo) mentre useremo il termine “processo”
quando facciamo riferimento a come (i.e. le modalità con cui) sono svolte le attività gestionali
nel contesto aziendale di una TelCo e vogliamo evidenziarne i dettagli operativi nel dominio
del tempo. Sia per una “funzione” che per un “processo ” si tratta di attività finalizzate al
raggiungimento di scopi prefissati, svolte “mettendo in atto” certe “funzionalità” acquisite a
priori dagli agenti partecipanti (uomini e/o macchine).
In definitiva, come le “funzioni” anche i “processi” all’interno di una impresa sono tesi al
raggiungimento di certi “scopi” prefissati dall’impresa stessa. Ma, gli scopi dei processi
all’interno di una impresa sono rigorosamente finalizzati al conseguimento di “obiettivi di
business” prefissati. Si tratta quindi di “processi di business” (“business processes”). Se
l’impresa è una TelCo gestore di reti e servizi TLC si stabilisce quindi un legame fra requisiti
del sistema gestionale e obiettivi di business della TelCo. Per il momento quindi si ricordi
che :
1) la gestione di reti e servizi TLC viene effettuata da un gestore TelCo. Una TelCo è una
impresa commerciale che opera in un libero mercato ed è finalizzata a compiere una certa
68
“missione” e a conseguire certi “obiettivi di business”. Quindi gli “scopi della gestione” e i
“requisiti del sistema gestionale” sono allineati con gli “obiettivi di business” della TelCo.
“Integrated TLC Management Solutions
are in fact TelCo Business Solutions ”
(G.Chen, Q.Kong: Integrated TLC Management Solutions”, IEEE Press,2000)
2) la implementazione delle attività gestionali avviene all’interno della TelCo sottoforma di
“processi” e quindi i modelli gestionali da sviluppare e che saranno poi utilizzati dal gestore
TelCo è bene che siano espressi nella stessa “lingua” cioè siano strutturati come “modelli
processuali”. Vedremo che i modelli gestionali più recenti sono modelli processuali.
NOTA 1.0.3.3.1 Qui il termine “modello” è inteso come una rappresentazione astratta di un “sistema reale target”
effettuata da un modellatore in base ai propri interessi/conoscenze tenendo conto delle esigenze degli utilizzatori finali
del modello quindi utilizzando un linguaggio e un livello di astrazione di loro gradimento. Quindi un “modello”, oltre
all’esistenza di un sistema target da modellare, implica l’esistenza di almeno due attori: un “modellatore” (modeler)
che osserva/analizza/modella un sistema reale target adottando un “punto di vista” che riflette i suoi interessi e un
insieme di “utilizzatori del modello” (model users) che lo utilizzeranno per soddisfare certe loro esigenze. Nel caso
di modello gestionale il modellatore osserva l’ “oggetto” reale da gestire (sistema reale target materiale o immateriale
e.g. reti o servizi) da un punto di vista gestionale e gli utilizzatori del modello sono i gestori dell’ “oggetto” stesso.
1.0.4 Esercizi
1.
Quale è l’elemento che fa distinguere fra “comunicazione” e “telecomunicazione” come da noi definite?
(Suggerimento: pensare alla differenza che tutti noi facciamo quando parliamo di “mezzi di comunicazione di
massa” o “mezzi di telecomunicazione”allorchè ci riferiamo rispettivamente a radio/TV, libri, giornali, riviste o a
telefono e internet)
2.
A differenza della “telecomunicazione”, la “collaborazione” fra persone richiede, oltre allo scambio di
informazione, anche lo scambio o l’utilizzo congiunto di beni materiali e.g. pubblicazioni, documenti, registrazioni
audio-video etc. In che modo le “telecomunicazioni” facilitano la “collaborazione” fra stakeholders remoti?
(Suggerimento: pensare ai processi di dematerializzazione, digitalizzazione e messa in rete di una fotografia
oggetto di collaborazione a distanza)
3. Cosa è un “TLC stakeholder” e come si relaziona a sistemi e servizi TLC? (Suggerimento: Pensare al “gestore”
o all’utilizzatore di un sistema TLC)
4. Perché in un approccio interdisciplinare alla “Gestione dei Sistemi TLC” è importante introdurre un concetto
semanticamente molto ricco come quello di “TLC stakeholder”? (Suggerimento: pensare a vari tipi di TLC
stakeholders e notare i rispettivi campi di attività rilevanti alla gestione di sitemi e servizi TLC)
5.
Quale è la differenza fra “TLC stakeholder” e “Attore TLC”? Può una persona fisica essere un Attore TLC
senza essere contemporaneamente un TLC Stakeholder?
6.
Quali sono i TLC stakeholders che abbiamo menzionato ma che, al contrario delle TelCo e degli Utenti,
NON verranno studiati in dettaglio questo corso. (Suggerimento: osservare la Fig.1.0.1.4)
7.
Una persona giuridica reale può giocare contemporaneamente un ruolo Engineering e un ruolo Business. Fare
un esempio di un TLC stakeholder che gioca entrambi i ruoli.
8.
In questo corso si fa riferimento a servizi TLC abilitati da una infrastruttura logico-fisico-energetica
(“sistema TLC”) realizzata, fra l’altro, con tecnologie ICT.
69
i)
In Europa la Commissione Europea nel 2002 ha abolito la terminologia “servizio TLC”, ma noi
continuiamo ad usarla. Cosa intendiamo per “servizio TLC” e perché continuiamo ad usare questo termine?
ii)
Quale è la relazione fra “sistema TLC”, “Tecnologia ICT” (Information & Communication
Technology) e Risorsa TLC? Un sistema TLC è una Tecnologia ICT o una Risorsa TLC?
iii)
Quali sono le Tecnologie ICT nel lato Utente di un sistema TLC? (Suggerimento: Pensare al
Customer Premise Equipment contenuto in una Utenza)
iv)
Data che l’equipaggiamento CPE (software e hardware) fa parte del sistema TLC, quale è il confine
che separa un sistema TLC dall’ambiente esterno?
v)
L’interfaccia UNI (User Network Interface) è interna o esterna al sistema TLC?
9.
L’ uomo ha bisogno di telecomunicare in varie maniere con i suoi simili e con centri di distribuzione di
informazione anche situati in siti remoti.
i)
Come si passa dal bisogno di telecomunicazione avvertito dal singolo individuo alla necessità di
acquisire/fruire di servizi TLC forniti/erogati da imprese TelCo a tutti i cittadini? Non potrebbe il singolo
individuo possedere lui le risorse per telecomunicare con gli altri? (Suggerimento: Pensare al fatto che il
problema è comune a tutti i servizi di pubblica utilità che necessitano di grandi reti di distribuzione)
ii)
Abbiamo definito una TelCo come una impresa commerciale che svolge almeno tre ruoli importanti
che richiedono competenze professionali diverse. Quali sono questi tre ruoli e quali sono le relative
competenze professionali degli Attori TLC coinvolti?
iii) Dei tre ruoli discussi al punto ii) precedente quale è quello che richiede competenze interdisciplinari
i.e. appartenenti alle aree conoscitive Engineering e Business (definite in Tav. 1.3.1.2) ?
10. Esistono diversi tipi di mercati TLC dove vengono forniti beni e servizi in cambio di opportuni
pagamenti,
i)
Quali sono i mercati TLC menzionati in questo corso e quali sono le loro mutue relazioni?
ii)
Quale è il mercato TLC che verrà studiato in dettaglio in questo corso? (Suggerimento:
comprendere e memorizzare la Fig.1.0.1.4 e, senza poi guardarla, rispondere alla domanda)
11. Un servizio TLC di telefonia cellulare è reso disponibile su base 24/7/365 in una certa zona geografica
(“cella”) ad un certo numero di sottoscrittori (numero di sottoscrittori = numero di SIM cards vendute).
Tuttavia ad un certo istante di tempo il servizio è effettivamente utilizzato solo da una certa percentuale di
questi sottoscrittori (numero di attori, N(t)). Il numero di attori N(t) è distribuito durante la giornata e durante
la settimana secondo un profilo di traffico diurno o settimanale con un massimo nella “busy hour” del
“busy day” della settimana. Per questo servizio esistono diverse tariffe. Infatti si può scegliere fra varie
“condizioni di sottoscrizione” ognuna con una certa modalità di consumo/pagamento e.g. 30 ore al mese di
telefonata locale mobile-mobile o mobile-fisso per 10 Euro.
i)
Identificare almeno due modalità di consumo/pagamento (indicate con le lettere A e B). Quando
conviene A e quando B?
ii)
Una analisi di mercato prevede un aumento della domanda in quella cella per il 2012 e fornisce i
relativi dati di intensità/profili di traffico e sviluppo socio-economico. In risposta ad un aumento
della domanda la TelCo fornitrice del servizio vuole aumentare per il 2012 la capacità
attualmente disponibile nella cella e.g. numero di canali telefonici disponibili con la stessa QoS
odierna e.g. stessa probabilità di blocco all’ accesso. Domanda: Il calcolo dell’aumento di
70
capacità (numero di canali aggiuntivi da installare per il 2012) si deve basare sul massimo
numero di sottoscrittori previsto o sul massimo numero di attori che effettivamente utilizzeranno
la rete o su una certa percentuale di questi numeri in funzione della probabilità di blocco
all’accesso o su tutti questi fattori?
12.
Il termine “Utente” indica una entità capace di svolgere i ruoli di Cliente e Utilizzatore cioè
capace di svolgere rispettivamente funzioni gestionali e di U&S.
i)
Cosa significa dire “ nel caso di utenza Business l’Utente è una persona giuridica”?
ii)
Nel caso di utenza Consumer l’ Utente è una persona reale: chi è il Cliente e chi
l’Utilizzatore?
13. Una Telco “factotum” (il nostro modello di TelCo!) è anche responsabile della gestione di servizi TLC e
delle relative reti abilitanti. All’uopo al suo interno vengono eseguiti in modalità manuale o automatizzata una
serie di processi aziendali (business processes) finalizzati al conseguimento di certi obiettivi di business
(business objectives) prefissati dalla TelCo stessa in fase di pianificazione strategica. Tuttavia spesso noi non
parliamo di “esecuzione di processi di business” bensì di “svolgimento di funzioni gestionali (management
functions)” e di modelli funzionali e.g. il modello FCAPS dell’ITU-T. Allora,
i)
Cosa intendiamo noi per “svolgimento di funzione TLC”?
ii)
Quale è la differenza fra “svolgimento di funzione” e “esecuzione di processo”?
iii)
I processi aziendali all’interno di una TelCo sono classificati in tre “classi di processo” o “tipi di
processo”. Quali sono queste tre classi e quale è il criterio di classificazione adottato?
(Suggerimento: pensare al livello zero del modello e-TOM)
iv)
Quali sono le “tecnolgie di supporto” (Support Systems”) che abilitano i vari tipi di processi?
14.
I processi aziendali all’interno di una TelCo finalizzati alla gestione di sistemi e servizi TLC sono
stati standardizzati dall’ITU-T in un modello processuale denominato “e-TOM, enhancedTeledcommunications Operations Map”.
i)
Definire un processo aziendale (Suggerimento: partire dalla definizione di “funzione TLC”)
ii)
Cosa significa standardizzare un processo aziendale di una TelCo? Cosa è che viene
effettivamente standardizzato? (Suggerimento: pensare alla definizione di processo
standardizzato nelle mappe processuali del consorzio TMF)
iii)
Perché è importante standardizzare i processi aziendali di una TelCo? (Suggerimento: pensare a
una “value network”)
71
1.1 “Gestione TLC”: la gestione integrata di sistemi e
servizi TLC per un “Customer Oriented
Business”
TLC MANAGEMENT
Impresa
(Vedi Fig.A.3.2 e Fig.A.3.3 nell’Appendice 3 al Cap. 1)
Relazioni
Clienti
Servizi
Reti
Elementi Rete
Fornitori Part.
Suppliers
“TIPI di
OGGETTO”
da gestire
“AREE FUNZIONALI” (Attività di Gestione)
Pianificazione
Installazione
Fornitura
Mantenimento
Operazioni
Amministrazione
Ciclo di Vita
Fig.1.1.1 Per le telecomunicazioni è possibile creare un “modello gestionale generico” di alto livello i.e. un
modello indipendente dai particolari scenari di servizio e dalle particolari tecnologie abilitanti i servizi, se si
opera ad un livello di astrazione sufficientemente elevato. La figura mostra una rappresentazione a matrice
rettangolare basata sul modello funzionale OAM&P dell’ ANSI (strisce verticali gialle) ampliato poi dall’ITUT (strisce verticali celesti). Gli “Strati orizzontali” sono presi dal modello “e-TOM” del TMF e sono una
generalizzazione del modello “TMN stratificato” dell’ITU-T.(rettangoli verdi). I rettangoli bianchi
rappresentano “domini gestionali” i.e. aree di attività gestionale mirate a certi tipi di oggetti da gestire e certe
aree funzionali. Stesso tipo di rappresentazione si ottiene usando per le strisce verticali i modelli funzionali
generici FCAPS dell’ITU-T o FAB del TMF (vedi testo). Esempi di attività nei domini gestionali si trovano in
Fig. 3.5.5.1
72
1.1.1
Cosa significa “gestire” sistemi
concettuale
1.1.1.0
Introduzione: lo scenario di partenza
e servizi TLC? Un modello
Cominciamo rifacendo un quadro della situazione di partenza. Supponiamo di
trovarci in un “Ambiente Business” in cui una moltitudine di imprese TelCo (service
wholesalers, service retailers, intermediari, brokers, network operators) di diverse dimensioni
(grosse imprese incumbents ex-monopoliste, piccole e medie imprese new-entry) forniscono
una varietà di servizi TLC (telefonia locale e long distance, internet, radio-televisione etc.) su
base fissa o mobile, con il supporto di infrastrutture tecnologiche costituite da reti TLC (reti
terrestri wireline o wireless, satellitari) a cui è connessa una varietà di terminali (telefoni,
computers, radio, televisori, fax machines etc.) installati presso gli Utenti. Inoltre supponiamo
che le TelCo svolgano un business “orientato al cliente” operando in un libero mercato in
presenza di imprese concorrenti secondo criteri di razionalità economica i.e. in maniera
efficace/efficiente (vedi par.1.1.4) e in modo “sostenibile” rispettando i dettami di una
Responsabilità Sociale di Impresa (Corporate Social Responsability, vedi par.1.3.6). Ciò
equivale a dire che le TelCo “gestiscono” servizi TLC e reti TLC abilitanti in modo tale che
l’esercizio delle prime avvenga a costo minimo e la erogazione dei secondi avvenga con la
massima soddisfazione degli Utenti. Supponiamo che anche gli Utenti giochino un ruolo
importante: essi collaborano con le TelCo nelle attività di marketing, acquisiscono e fruiscono
dei servizi TLC, cooperano con le TelCo nelle attività di gestione dei servizi TLC e, nel
contempo, gestiscono essi stessi i terminali installati nelle loro Utenze. (Customer Premise
Equipment).
ATTENZIONE! Ricordiamo che noi abbiamo definito “sistema TLC” l’infrastruttura fisico-logico-energetica
abilitante i servizi TLC comprensiva di reti TLC (lato TelCo i.e. lato “produzione servizi TLC”) e di terminali
TLC (lato Utente i.e. lato “consumo servizi TLC”). Notare l’inclusione dei terminali (Customer Premise
Equipment, CPE) nel sistema TLC. Conseguenze importanti di questa scelta sono 1) il software che gira sul CPE
fa parte del software del sistema TLC e 2) il sistema TLC è delimitato dalle interfacce Uomo-Terminale e non
dall’interfaccia Terminale-Rete (e.g. User Network Interface, UNI). Questi argomenti sono stati studiati in
dettaglio nel par. 1.0.2 (vedi Fig.1.0.2.1)
1.1.1.1
•
Nel settore TLC è possibile parlare di “una” gestione?
La ”Ipotesi di Lavoro 1.1.1.1” (Working Hypothesis No.1.1.1.1)
Finora abbiamo usato il verbo “gestire” facendo appello al senso comune ma senza
specificarne il significato in modo preciso. Lo facciamo adesso! All’uopo facciamo una ipotesi
di lavoro estremamente semplificativa tenendo conto del fatto che i nostri studenti frequentano
l’ultimo anno di una facoltà universitaria tecnica e che presto saranno ingegneri attivi nel
mondo del lavoro. Adottando un linguaggio consono con la loro preparazione tecnica e quindi
per essi facilmente comprensibile, supponiamo preliminarmente che
1)
“gestire un sistema TLC” significhi svolgere tutte le funzioni necessarie a garantire
che esso sia sviluppato e funzioni come preliminarmente specificato in maniera
efficace/efficiente i.e. a costo minimo e soddisfazione massima per l’utilizzatore
73
2)
“gestire un servizio TLC” significhi svolgere tutte le funzioni necessarie a garantire
che un servizio TLC sia sviluppato e fornito come preliminarmente specificato in maniera
efficace/efficiente i.e. costo minimo e soddisfazione massima per l’Utente.
CITAZIONE 1.1.1.1 Riportiamo qui di seguito il testo presentato in ITU-T Recommendation M.3010
“Principles for a Telecommunications Management Network”, 02/2000 rilevante alla Ipotesi di Lavoro
1.1.1.1 “Within the context of a Telecommunications Management Network, mangement refers to a set of
capabilities to allow for the exchange and processing of management information to assist PTOs in
conducting their business efficiently” (PTO = Public Telecommunications Operator)
•
La domanda
A questo punto appare legittima una domanda: “A fronte di una grande varietà di servizi
TLC e relative tecnologie abilitanti, pur accettando l’Ipotesi di Lavoro 1.1.1.1 formulata in
maniera estremamente semplice, cosa esattamente significa gestire sistemi o servizi TLC
senza di volta in volta specificarne la natura”? O, domanda ancora più fondamentale: “Ha
significato parlare di “una gestione” dei sistemi o dei servizi TLC o piuttosto si deve parlare di
una “molteplicità di gestioni” ognuna valida per i singoli casi presi in considerazione”? A
prima vista la risposta a queste domande non appare né semplice né immediata. Infatti a
ragione si può ritenere che come esiste una grande varietà di servizi TLC e relativi sistemi TLC
abilitanti da gestire così esiste una grande varietà di gestioni diverse appropriate ai singoli casi
particolari. Gestioni diverse che richiedono tecnologie gestionali diverse e criteri gestionali
diversi (proprietari o standardizzati) i quali di volta in volta vengono scelti dai gestori. Inoltre
c’è un altro fattore importante che complica le cose: il fattore “tempo”. Cioè l’impatto sulla
gestione di sistemi e servizi TLC dei cambiamenti politici, economici, sociali, tecnologici,
ambientali e regolatori che si verificano nel macroambiente circostante il gestore TelCo col
passare del tempo (vedi par.1.1.1.5). Allora con scenari gestionali mutevoli nel tempo se anche
si parlasse di “una sola gestione” si dovrebbe in ogni caso parlare di una gestione che
comunque varia nel tempo cioè è riconfigurabile, flessibile, scalabile e adattabile in risposta
ai cambiamenti.
•
La risposta….di Socrate!
Socrate (469-399 a.C)
E invece una risposta, seppur parziale, alle domande poste non solo esiste ma è stata già
data qualche tempo fà! E’ stata data da circa venti anni e in maniera ufficiale da parte di enti di
standardizzazione nazionali e internazionali grazie ad una facoltà propria dell’uomo: la facoltà
di creare modelli concettuali partendo dalla frammentarietà ed eterogeneità della realtà che ci
circonda attraverso processi di astrazione. Ricordate il “concetto socratico” di “albero”
studiato al liceo che ci permetteva di parlare di “albero” non ostante l’esistenza in natura non di
un “albero” bensì di una varietà di pini, magnolie, platani, pioppi e cipressi molto diversi l’un
dall’altro? Ebbene il concetto di albero che noi riteniamo nelle nostre menti e che ci permette di
identificare ciò che è “albero” e ciò che non è “albero”, è il risultato di un processo mentale
denominato “processo di astrazione” e lo stesso tipo di processo può portarci a definire cosa sia
la gestione di sistemi e servizi TLC sebbene si tratti di entità che nella realtà dei fatti sono
diversificate in una miriade di casi specifici. Quindi attraverso un processo di astrazione,
partendo dalla realtà multiforme dei sistemi e servizi TLC, noi possiamo creare un modello
74
concettuale di gestione. Ma attenzione, si deve agire con cautela. C’è un prezzo da pagare!
Vediamo di cosa si tratta.
•
La creazione del “modello gestionale concettuale”
Supponiamo, come in effetti avviene in pratica, che un vasto gruppo di operatori del
settore TLC provenienti da tutto il mondo si coalizzino in un “forum industriale
internazionale” con lo scopo di promuovere i propri prodotti e difendere i propri interessi
commerciali. Supponiamo che essi decidano di “osservare” il mondo reale delle TLC (“sistema
target”) con lo scopo di creare, in base alle loro osservazioni, una unica rappresentazione
unitaria e completa delle attività di gestione relative ai sistemi e servizi TLC esistenti in
esso (rispettivamente “oggetti” tangibili e intangibili da gestire) adottando l’Ipotesi di Lavoro
1.1.1.1 e condividendo un linguaggio di rappresentazione opportunamente scelto. Supponiamo
cioè che essi vogliano creare un “modello concettuale gestionale” per i sistemi e servizi del
mondo TLC. Una volta sviluppato questo modello gestionale poi il forum degli operatori TLC
dichiarerà ufficialmente che è “gestione” ciò che tutti loro si sono accordati di includere nel
modello gestionale.
Ma come si crea un modello gestionale? In questo corso studieremo con grande
attenzione come creare “modelli generici” e “modelli specifici”. Più precisamente, studieremo
come sviluppare un modello gestionale generico di sistemi TLC o servizi TLC, valido per una
molteplicità di tecnologie implementative e scenari di servizio e modelli gestionali specifici
validi solo per singole tecnologie ICT e singoli servizi TLC. Per creare modelli gestionali
generici esistono diverse metodologie di modellazione. Per il momento supponiamo che il
modellatore cioè il forum internazionale degli operatori TLC voglia creare il modello generico
applicando una metodologia di modellazione “dal particolare al generale” (vedi Capitolo 3
par.3.5.1 e Fig.3.5.1) altrimenti detta “bottom-up”, basata su un processo di generalizzazione
di modelli gestionali specifici sviluppati in precedenza. In base a questa metodologia essi
“osservano” le attività gestionali svolte da o effettuate su singole tecnologie ICT e servizi TLC
in una molteplicità di casi pratici che si verificano nelle nazioni economicamente e
tecnologicamente più avanzate del mondo e.g. paesi del gruppo G.8 (dove si può osservare lo
“stato dell’arte” del settore TLC). Ad esempio supponiamo che essi per prima cosa, tramite
interviste e discussioni con personale specializzato TelCo, “osservino” le modalità/tecnolgie
relative a fornitura/acquisizione, erogazione/fruizione e fatturazione/ pagamento nei servizi
telefonici fissi sia per utenze consumer che per utenze “affari” assieme alle relative tecnologie
abilitanti. Poi fanno lo stesso con altre imprese TelCo per servizi di telefonia cellulare, per
servizi di e-mail, per servizi TV fissi e mobili e così via per un numero “n” di scenari pratici di
servizi TLC supportati da una varietà di tecnologie abilitanti.
Per ogni particolare servizio TLC il forum degli operatori TLC riconosce 1) una parte
“essenziale” relativa alla “essenza” o “ragion d’essere” del servizio TLC (“service core”)
osservata allorchè esso viene erogato/fruito con il supporto di opportune tecnologie 2) una parte
ancillare, denominata parte “gestionale”, associata alla prima. La aggregazione “parte
essenziale + parte gestionale” è tale da rendere la erogazione/fruizione del servizio TLC
efficace/efficiente cioè effettuata con massima soddisfazione degli Utenti e minimo costo per l’
impresa fornitrice del servizio (Vedi par.1.1.2 “Valenza economica della gestione”). Ad
75
esempio il forum degli operatori TLC riconosce che la parte essenziale di un servizio telefonico
è la effettuazione di telefonate e che questa attività è abilitata da telefoni + reti telefoniche
mentre le attività di riparazione di un guasto in rete o l’invio/pagamento di una bolletta
telefonica sono parti gestionali di natura ancillare rispetto alla prima. Un corretto svolgimento
della aggregazione “telefonata + riparazione guasto + pagamento fattura” rende poi la
fornitura/erogazione del servizio telefonico efficace/efficiente con la massima soddisfazione per
tutti gli stakeholders partecipanti.
Completate queste osservazioni di partenza ed esaminati i dati raccolti, gli operatori
TLC riconoscono che le caratteristiche “essenziali” sono specifiche dei singoli casi esaminati
mentre certe caratteristiche “gestionali” in effetti sono caratteristiche condivise da tutti i casi
esaminati e inoltre sono sempre presenti in qualsiasi tipo di attività gestionale
indipendentemente dal fatto che l’ “oggetto” gestito sia una tecnologia abilitante (e.g.
riparazione di un elemento di rete) o un servizio TLC (e.g. invio/pagamento della bolletta
telefonica). Allora essi selezionano e identificano queste caratteristiche gestionali condivise, le
analizzano attentamente, le classificano secondo opportuni criteri, ne rappresentano
graficamente e/o testualmente le loro mutue relazioni e infine le raccolgono in un modello
gestionale concettuale valido per tutte le tecnologie abilitanti e per tutti gli scenari di servizio
osservati (“modello funzionale generico”). L’attributo “funzionale” deriva dal fatto che la
attenzione dei modellatori è focalizzata su “attività” gestionali (anche denominate “funzioni”
gestionali, vedi 1.0.1.1). L’attributo “generico” (contrario di “specifico”) si riferisce al fatto
che il modello funzionale è valido per un qualsiasi “tipo di oggetto” gestito sia esso un bene
tangibile come una rete o un elemento di rete o un servizio intangibile come un servizio TLC ed
inoltre è indipendente dalla particolare tecnologia implementativa o dal particolare scenario di
servizio. (Fare bene attenzione a quest’ultimo punto!). Come si vede facilmente si tratta
proprio di rifare quello che Socrate aveva già fatto duemila e cinquecento anni fa per creare il
“concetto socratico di albero”: un “albero” è una entità caratterizzata da radici, tronco, rami e
foglie, attributi condivisi da tutti gli alberi reali esistenti in natura. Ma come è fatto un
“modello funzionale generico”? Vediamo.
ESEMPIO 1.1.1.1 “Esempio di caratteristiche gestionali comuni condivise da diverse tecnologie ICT e
servizi TLC”.
Basta pensare ad una attività di gestione relativa alla supervisione da parte di un gestore dello “stato” in cui
si trova un elemento di rete e.g. “stato di allarme” (debole, forte, critico) o “stato amministrativo”
(bloccato, sbloccato, sotto prova) o “stato operazionale” (inattivo, stand-by, attivo, occupato). Si tratta di
caratteristiche generiche valide per una qualsiasi tecnologia ICT in una rete TLC. Analogamente un
qualsiasi servizio TLC viene “sviluppato”, “offerto”, “richiesto”, “fornito”, “acquisito”, “erogato”, “fruito”,
“monitorato”, “riparato”, “fatturato”, “pagato” etc. Le corrispondenti attività sono attività gestionali
condivise da tutti i servizi TLC indipendentemente dalle specificità della loro “essenza”.
1.1.1.2
“Modelli funzionali” generici: ANSI, ITU-T, TMF (Tavola 1.1.1)
L’esercizio or ora effettuato dal forum degli operatori TLC è esattamente ciò che, su
scala molto più vasta, alcuni enti di standardizzazione/consorzi industriali di operatori TLC in
USA e in Europa hanno fatto alcuni anni fà allorchè, con la collaborazione delle maggiori
TelCo, hanno sviluppato standards gestionali denominati “modelli funzionali generici per
76
reti e servizi TLC”. L’uso del termine ”rete TLC” invece del termine “sistema TLC” è
giustificato dal fatto che questi modelli si applicano ad attività gestionali svolte dalle TelCo. Gli
enti di standardizzazione/consorzi industriali di operatori TLC a cui noi siamo interessati sono i
seguenti:
1) l’American National Standards Institute (ANSI) ha pubblicato le sue
raccomandazioni nell’ ANSI Report T1.210 nel 1993 (modello funzionale OAM&P) e queste
raccomandazioni sono state poi ampliate dall’ITU-T nella Raccomandazione M.3010
(02/2000)
2) l’ ITU-T ha pubblicato le sue raccomandazioni nel 2000 nel documento ITU-T
Recommendation M.3400 (modello funzionale FCAPS)
3) il forum internazionale TeleManagement Forum (TMF) ha pubblicato nel 2000,
dopo numerose revisioni, le sue raccomandazioni nella Raccomandazione G.921, version 2.1
“Telecom Operations Map”, March 2000 (modello funzionale FAB). Il titolo originale era
“Service Management Business Process Model” cioè “ Modello (di Riferimento) dei Processi
Operativi di Gestione dei Servizi TLC”.
AREE FUNZIONALI
ANSI
ITU-T
TMF (*)
Operations
Fault
Fulfillment
Administration
Configuration
Assurance
Maintenance
Accounting
Billing
Provisioning
Performance
Security
(*) Raggruppamenti di Processi
Tavola 1.1.1 Corrispondenze fra aree funzionali
CITAZIONE 1.1.1.2.1 Nella Racc. 3010 (02/2000) dell’ITU-T si legge: “This Recommendation presents the
general architectural requirements for a Telecommunications Management Network (TMN) to support the
management requirements of PTOs (Public Telecommunications Operators) to plan, provision, install,
maintain, operate and administer telecommunications networks and services. (Some considerations of
design, planning, installation and operating a TMN and examples of use are presented in Recommendation
M.3013).
77
Nota Bene: La frase in corsivo si riferiasce alla gestione della rete di gestione TMN (fra poco vedremo
trattarsi di “gestione del secondo ordine” cioè “the guardian’s guardian”, “il guardiano del guardiano”!)
In base al modello OAM&P dell’ANSI le attività di gestione dei sistemi e servizi TLC
possono ricondursi ad attività appartenenti a quattro aree funzionali, le cui iniziali Inglesi
costituiscono l’ acronimo OAM&P: 1. Operazioni (Operations), 2. Amministrazione
(Administration), 3. Mantenimento (Maintenance) & Fornitura, (Provisioning). A queste
l’ITU-T ha aggiunto le aree funzionali di 5. Pianificazione (Planning) e 6. Installazione
(Installation).
In base al modello FCAPS dell’ITU-T, riconducibile al modello OAM&P, (vedi
D.K.Udupa, “TMN, Telecommunications Management Network”, Mc Graw Hill, 19999, p.37)
le attività di gestione di reti e servizi TLC appartengono a cinque aree funzionali, le cui iniziali
definiscono l’acronimo FCAPS: 1. Fault (Guasti), 2. Configuration (Configurazione), 3.
Administration (Amministrazione), 4. Performance (Prestazioni) e 5. Security (Sicurezza).
In base al modello FAB del TMF, le attività gestionali di una TelCo possono
classificarsi entro confini precisi e chiari i.e. appartengono a tre Aree funzionali qui chiamate
“raggruppamenti di processi” (process groupings) indicati con le lettere maiuscole F, A e B,
ognuno corrispondente ad un particolere obiettivo di business (business objective) del gestore
TelCo:
i. Service Fulfillment, (fornitura pronta e accurata di ciò che il Cliente ordina i.e.
“soddisfacimento” delle richieste del Cliente),
ii. Service Assurance, (risposta e risoluzione pronta e accurata dei problemi insorti
presso il Cliente e miglioramento delle prestazioni erogate al Cliente i.e. “assicurazione” che il
valore dei servizi forniti all’Utente uguagli o superi gli impegni contrattuali),
iii. Service Billing (“fatturazione” pronta e accurata dei servizi forniti al Cliente).
Come si vede il modello del TMF, a differenza degli altri, è un modello incentrato sul
Cliente (Customer-oriented). A tutt’oggi la classifica delle attività gestionali in “aree
funzionali” (o “raggruppamenti di processi” per il modello FAB) costituisce una classifica
fondamentale su cui si basano i modelli gestionali più popolari fra quelli adottati dagli operatori
del settore.
1.1.1.3
I “tipi di oggetto” da gestire: modelli informativi
Finora abbiamo parlato di attività gestionali come appartenenti ad “aree funzionali”
definite da certi “modelli funzionali”. Queste attività vengono svolte da personale
specializzato (“addetti alla gestione”) e/o sistemi informatici gestionali (“sistemi di supporto”).
Inizialmente abbiamo detto che le attività gestionali riguardano due “Tipi di Oggetto” da
gestire: reti e servizi TLC. Si tratta di “Tipi di Oggetto” rispettivamente tangibili e intangibili.
Ogni “Tipo di oggetto”, seppur ad un alto livello di astrazione (notare che stiamo parlando di
“Tipi di oggetto” e non di “Oggetti”) va caratterizzato da un punto di vista gestionale tramite
opportuna “informazione gestionale” contenuta in “modelli informativi”. Un modello
78
informativo specifica l’informazione acquisita, elaborata, e generata dalle attività gestionali e.g.
acquisizione/elaborazione/generazione e immagazzinamento di informazione gestionale relativa
alla gestione di una rete TLC oppure relativa a “richiesta/ installazione di un servizio” durante
la gestione di un servizio TLC.
•
Quanti sono i “Tipi di oggetto” da gestire?
Quanti sono i “Tipi di oggetto” da gestire? In effetti, come anche mostrato nella
Fig.1.1.1, il numero dei “Tipi di oggetto” da gestire è stato sempre identificato come superiore
a due e, in effetti, è cresciuto nel tempo con lo sviluppo delle TLC.
Negli anni 80 l’ ITU-T ha introdotto un modello “TMN stratificato” (TMN =
Telecommunications Management Network, vedi Fig.1.4.1.2.3.) in cui il modello informativo è
spalmato su quattro strati dedicati a quattro “Tipi di Oggetto” da gestire: 1) Impresa, 2)
Servizi, 3) Reti e 4) Elementi di Rete. Questo modello, studiato in dettaglio in questo corso,
nella storia della GST ha costituito la base di quasi tutti i modelli informativi proposti. Anche
in Fig.1.1.1 esso costituisce il nucleo centrale del modello (rettangoli verdi).
Esistono varie motivazioni che hanno portato e portano a distinguere fra “Tipi di
oggetto” da gestire e a introdurne dei nuovi. Ad esempio, vedremo nel par.1.3.3 che la
motivazione dello sdoppiamento della gestione degli oggetti tangibili in “gestione Elementi di
Rete” e “gestione Reti” è duplice: non solo i modelli informativi di reti e elementi di rete sono
diversi (e.g. molto più granulare il primo) ma anche la implementazione tecnologica dei modelli
(i.e. sistemi OS, Operations Systems, e NSS, Network Support Systems) nei due casi è molto
diversa (rispettivamente, minicalcolatori attestati sugli elementi di rete e grossi elaboratori
digitali su cui girano applicazioni gestionali).
Nel tempo i “Tipi di Oggetto” del modello “TMN stratificato” sono aumentati. Infatti
alcuni di essi sono stati ulteriormente specializzati ad opera di vari enti di standardizzazione
(principalmente ITU-T, ETSI e TeleManagement Forum), senza tuttavia alterare i precedenti
modelli funzionali.
Ad esempio, facendo riferimento ad una impresa TelCo, in essa la gestione servizi TLC
è stata successivamente sdoppiata dal TMF in “gestione Servizi TLC” e “gestione Relazioni
Clienti (Customer Relation Management, CRM)” e questo sdoppiamento è stato dettato da
cambiamenti verificatisi nei mercati TLC, come mostrato nella NOTA 1.1.3.1.
NOTA 1.1.3.1 La importanza di una CRM distinta dalla gestione Servizi e personalizzata al singolo cliente (che
può accedere elettronicamente a certi processi gestionali della TelCo su base 24/7/365), è emersa a metà anni 90 e
segna il passaggio da una organizzazione aziendale “service provider-centric” (incentrata sul fornitore di servizi) a
una “customer-centric” (incentrata sul cliente) , laddove per “customer” ora si deve intendere il singolo cliente e
non un cliente generico (mercato di massa). Infatti proprio a quel tempo i mercati TLC cominciavano a passare da
una condizione di monopolio a una condizione di liberi mercati concorrenziali nei quali i clienti giocavano un
ruolo di primo piano (cioè la loro “domanda” costituiva il business driver per le TelCo) e l’ attività di marketing
dei prodotti/servizi TLC prendeva il sopravvento sulla semplice attività di vendita di prodotti preconfezionati dal
fornitore.
79
Ma anche in questo caso esistono differenze importanti a livello operativo. Infatti da un
punto di vista operativo la motivazione della differenziazione Gestione Sevizi – CRM è la
seguente:
1) la gestione Servizi è implementata dalla TelCo tramite processi di business interni
(i.e. senza la partecipazione di attori extra-TelCo. Vedere par.4.6.3.1) attraverso operazioni di
natura “operazionale” (vedi zona verde in Fig.1.0.3.3.1). Questi processi sono dedicati alla
gestione di “classi di servizio” (i.e. non gestiscono le singole “istanze di servizio” relative ai
singoli clienti).
2) la CRM è implementata da processi esterni cioè processi con la partecipazione
diretta dei singoli Clienti attraverso interazioni di natura transazionale relative a singole
“istanze di servizio” (una “istanza di servizio” è associata a un singolo Cliente)
NOTA 1.1.3.2 In questo corso una “transazione” è definita come un particolare processo di business per il
quale è assicurato il perfetto completamento o, in caso contrario, la ripetizione del processo ex-novo o il
rigetto totale, evitando di lasciare il sistema processuale in stati intermedi inconsistenti.
La CRM è molto più dinamica della “Gestione Servizi” ed è caratterizzata da un numero di
transazioni nell’unità di tempo molto elevato. Infatti una singola transazione è dedicata al
singolo Cliente e il numero di Clienti in un normale bacino di utenza è molto elevato e.g.
milioni di Clienti. (Vedi par.4.6.3.1 e “GST Addendum” No.4).
In tempi più recenti sono state aggiunte ulteriori “strati gestionali” e.g. dedicati alla
“gestione delle relazioni con TelCo Partner & ICTS” (e-business) e alla “gestione di
Impresa (TelCo)”. Ritorneremo su questo argomento nel prosieguo del corso (Vedi NOTA
1.1.3.3).
NOTA 1.1.3.3 L’inclusione formale di alcuni processi delle “gestione di impresa” nei modelli gestionali di
sistemi e servizi TLC è più recente. Infatti risale alla prima metà del 2000 ed è dovuta all’attività normativa
del consorzio internazionale TeleManagement Forum che, con la collaborazione dell’ITU-T, nel 2004 ha
emanato lo standard “e-TOM”, enhanced-Telecommunications Operations Map, suddiviso in 1. gestione
SIP (i.e. gestione delle Strategie e dei cicli di vita di Infrastrutture e Prodotti), 2. gestione operativa e 3.
gestione di impresa. Vedi anche Fig.1.0.3.3.1). Vedremo con più dettaglio questi aspetti nel corso delle
lezioni.
1.1.1.4
Un modello concettuale bidimensionale: aree funzionali (strisce verticali)
– “tipi di oggetto” da gestire (strati orizzontali)
La Fig.1.1.1 mostra come, ad eccezione dello strato “gestione di impresa” che viene
trattato in maniera diversa da autori diversi in testi diversi, la ortogonalità fra “aree
funzionali” (strisce verticali) e “tipi di oggetto” da gestire (strati orizzontali) porti alla
creazione di modelli gestionali bidimensionali con una classica rappresentazione a matrice.
Questa “ortogonalità” fra strisce verticali e strati orizzontali (proprietà grafica) nasce dal fatto,
già precedentemente menzionato, che il modello funzionale è valido per un qualsiasi “Tipo di
oggetto” da gestire sia esso di natura tangibile come una rete o un elemento di rete TLC o di
natura intangibile come un servizio TLC o una relazione commerciale con uno stakeholder
esterno. Il vantaggio di una rappresentazione grafica a matrice come quella di Fig.1.1.1 risale ad
80
una caratteristica tipica delle matrici rettangolari: esse “offrono” in uno spazio bidimensionale
più di quanto viene loro “fornito” singolarmente lungo le dimensioni orizzontale e verticale. In
Fig. 1.1.1. ci sono 30 intersezioni fra 6 strisce verticali e 5 strati orizzontali che definiscono 30
domini gestionali (rettangoli bianchi) entro i quali “certe” attività gestionali vengono svolte per
gestire “certi” tipi di oggetto e raggiungere “certi” scopi. Noi parliamo di “gestione locale”
quando facciamo riferimento ad attività gestionale svolta nell’ambito di un dominio gestionale e
di “gestione settoriale” . allorché facciamo riferimento alla gestione all’interno degli strati
orizzontali. Esempi di gestioni locali sono facili da identificare nella matrice di Fig.1.1.1 e.g. la
“pianificazione di una rete”, la “installazione di un servizio”, la “manutenzione di un elemento
di rete”, la “amministrazione delle relazioni con TelCo partner e ICTS fornitori di tecnologie
ICT (suppliers)” etc.
A questo punto possiamo stabilire quanto segue: quando noi parliamo di “gestione di
sistemi e servizi TLC” in effetti parliamo del contenuto della matrice di Fig. 1.1.1 (o di
schieramenti rettangolari con gli stessi strati orizzontali ma con strisce verticali rappresentative
dei modelli funzionali FCAPS o FAB). Si tratta di una rappresentazione semplice e compatta
indipendente dalle particolari tecnologie implementative dei sistemi gestionali e indipendente
dal particolare scenario di servizio a cui ci si vuol riferire. E questo è un gran bel risultato!
1.1.1.5
L’ordinamento degli strati orizzontali e delle strisce verticali nel modello a matrice
di Fig.1.1.1
Un ultima considerazione prima di lasciare il modello gestionale concettuale. Uno
studente attento e diligente che osservasse il modello a matrice bidimensionale di Fig.1.1.1 non
potrebbe fare a meno di porsi le seguenti domande “Gli strati orizzontali e le strisce verticali del
modello di Fig.1.1.1 appaiono giustapposti rispettivamente in una direzione verticale e in una
direzione orizzontale: è il posizionamento di strati e strisce lungo le due direzioni arbitrario e
quindi modificabile a piacimento o rispetta un ordinamento dettato da un criterio prescritto?
Esiste una relazione fra le attività gestionali pertinenti ai singoli strati orizzontali (gestioni
settoriali) o alle singole strisce verticali? In altre parole, “La rappresentazione grafica di
Fig.1.1.1 nasconde altra informazione, oltre a quella già menzionata, che è stata utilizzata dal
modellatore e che pur non immediatamente evidente all’utilizzatore del modello è tuttavia
rilevante a una caratterizzazione completa della Gestione TLC?
Gli Inglesi direbbero: Good question! E la risposta è: sì! In effetti nella Fig.1.1.1 c’è
informazione non immediatamente evidente ma che vale la pena di scoprire!
In effetti nel modello di Fig.1.1.1 esiste un ordinamento gerarchico nella direzione verticale
(ordinamento verticale) per i quattro strati gestionali di impresa, relazioni clienti, servizi, reti
e elementi di rete, stabilito (ad eccezione dello strato CRM) dal modello ITU-T “TMN
stratificato”. Esiste poi un ordinamento temporale (“ciclo di vita”) per le strisce funzionali,
spostandosi da sinistra a destra nella direzione orizzontale (ordinamento orizzontale) . In tutti
i testi pubblicati sull’argomento, strati e strisce sono ordinati nelle sequenze mostrate in
Fig.1.1.1. Entrambi ordinamenti verranno studiati in dettaglio nel corso delle lezioni. Qui è
sufficiente riconoscere quanto segue.
81
Ordinamento gerarchico verticale (Vedi par.3.4.2 e 3.4.3). Nella realtà dei fatti le gestioni
settoriali dei “Tipi di oggetto” mostrati nella Fig.1.1.1 sono mutuamente relazionate secondo
criteri prestabiliti. Esiste un criterio gerarchico (criterio di astrazione) in base al quale la
informazione gestionale è trasferita da uno strato inferiore ad uno strato superiore
immediatamente sovrastante. Ad esempio parte dell’informazione gestionale degli elementi di
rete viene trasferita allo strato superiore “gestione servizi”, parte della informazione gestionale
della gestione servizi viene fornita allo strato superiore “gestione di impresa”. Notare tuttavia
che .
Ordinamento temporale orizzontale (“ciclo di vita”) (Vedi par.2.5.6 per le tecnologie e par.
4.4.3.1 per i servizi). Le aree funzionali possono essere visualizzate nel dominio del tempo
come “fasi” successive attraversate da attività gestionali di natura diversa le quali nel loro
complesso descrivono una traiettoria denominata “ciclo di vita” (life-cycle). In questo scenario
un ciclo di vita “nasce” con la fase di “Pianificazione” e termina con una operazione di
“disinstallazione” del “Tipo di oggetto” al termine della fasi di “Manutenzione e
“Amministrazione”. Partendo dal lato sinistro del modello di Fig.1.1.1 e spostandosi da sinistra
verso destra si può riconoscere un ordinamento delle strisce verticali basato su un criterio di
propedeuticità. “Propedeuticità” significa che una fase deve essere completata e i suoi risultati
forniti alla fase posizionata immediatamente alla sua destra prima che questa possa essere a sua
volta completata. Ad esempio le attività nella fase di “pianificazione” sono propedeutiche alle
attività di “fornitura” e queste lo sono rispetto alle attività di “installazione” e queste lo sono
rispetto alle attività di “operazione” e così via.
1.1.2
Gestione dinamica e cambiamenti esterni: la gestione “per processi”
all’ interno di una TelCo
NOTA BENE. Per tutti gli studenti che non hanno familiarità con il concetto di “processo” si consiglia la
lettura delleAppendici 6 e 7 al Capitolo 1 (durante il corso vengono dedicati solo 30 minuti a questi
argomenti)
1.1.2.1
Utilità del modello concettuale di Fig.1.1.1
Nel par.1.1.1.1 abbiamo detto che è possibile parlare di “una gestione” grazie a quel
buon uomo di Socrate che viene in nostro soccorso con i suoi affascinanti “concetti socratici”
capaci di “tirar fuori” (astrarre) il “generale” dalle situazioni “particolari” che si incontrano
nella realtà che ci circonda. Più precisamente stiamo parlando dei concetti socratici di “area
funzionale” e “tipo di oggetto”. Ma abbiamo anche detto che questa visione olistica di una
realtà che in effetti è frantumata in mille casi particolari si ottiene ad un prezzo! Quale prezzo?
Ecco! Il prezzo da pagare è che il modello gestionale concettuale da noi ottenuto è di modesta
utilità pratica o meglio è utile fino ad un certo punto! Infatti l’utilità pratica di un modello
concettuale come quello di Fig.1.1.1 è molto apprezzabile in un contesto accademico-formativo
per ordinare e sistematizzare le conoscenze dei cultori della materia (“mondo della
conoscenza”, come quello nostro qui all’università) o, addirittura, per far comprendere cosa si
intenda per “gestione di sisteme e servizi TLC” anche ai non addetti ai lavori (e.g. nei corsi di
riqualificazione per personale non tecnico) ma invece è certamente modesta in un contesto
operativo i.e. all’interno di una TelCo (“mondo del lavoro”) dove si è interessati a conoscere
le modalità delle attività gestionali, l’informazione che viene elaborata, trasmessa e
82
immagazzinata nel corso di queste attività, le architetture dei sistemi di elaborazione a
supporto della parte automatizzata di queste attività, le loro reti di interconnessione e le loro
tecnologie implementative (hardware, software di base e software applicativo).
Ciò che è accaduto con la creazione di un modello concettuale è molto semplice e
costituisce un fatto ben noto a tutti coloro che hanno una minima conoscenza di software
engineering e si occupano del modelling di sistemi reali complessi. Modellizzando la realtà
delle telecomunicazioni ad un livello molto elevato (livello concettuale) se ne ottiene una “vista
unitaria di insieme” (summary view) di natura essenzialmente “statica” cioè si ottiene un
modello sufficientemente semplice che abbraccia tutti i vari aspetti della gestione ma si discosta
anche molto dalla realtà e perde di vista le caratteristiche dinamiche della gestione che
emergono a livelli di astrazione più bassi (o a livelli di “specializzazione” più alta o di
“dettaglio” più spinto) e.g. ai “livelli operativi”. Altrimenti detto, creando modelli molto
astratti delle attività gestionali di sistemi e servizi TLC ( “modelli concettuali”) si guadagna in
termini di “ampiezza” del modello ma si perde in termini di dettaglio: dettaglio di “come” la
gestione di reti e servizi TLC si svolge nel dominio del tempo ad opera di “addetti alla
gestione” e di “sistemi informatici gestionali” all’interno della TelCo. Per visualizzare questi
dettagli, cioè per creare modelli gestionali più dettagliati e più utili da un punto di vista
operativo, ci si deve riavvicinare alla realtà dei fatti attraverso un processo di specializzazione
del modello di Fig. 1.1.1
1.1.2.2 La specializzazione del “modello gestionale concettuale” (ITU-T Recommendations
M.3100 e M.3400)
E ciò è proprio quello che hanno fatto un certo numero di enti di standardizzazione
creando modelli informativi generici e modelli funzionali generici ma ad un livello di
specializzazione più alto di quello di Fig.1.1.1. più consono con i desideri/bisogni del gestore
Ad esempio l’ITU-T ha specializzato sia i “tipi di oggetti gestiti” in un modello informativo
(ITU-T Recommendation M.3100) dettagliato dedicato a reti ed elementi di rete sia le “aree
funzionali” in un modello funzionale usualmente denominato “modello FCAPS” (ITU-T
Recommendation M.3400) con una struttura gerarchica a tre livelli costituita da Gruppi di
Insiemi di Funzioni, Insiemi di Funzioni e Funzioni gestionali atomiche cioè non ulteriormente
divisibili (“System Management Funcions”). Nel Capitolo 3 e nella seconda parte del corso
studieremo in dettaglio questi modelli.
1.1.2.3
La TelCo come utilizzatore di modelli gestionali
Qui stiamo dicendo che il nostro modello concettuale di Fig.1.1.1 ci ha allontanato dalla
realtà del “mondo del lavoro” ma che un riavvicinamento è possibile se il modellatore lo
specializza in modo appropriato. Ma prima ci vogliamo occupare di un altro problema
importante che non è stato finora menzionato. Nella creazione di un qualsiasi modello di un
sistema complesso reale che sia effettivamente “utile” il modellatore deve sempre tener conto
dei bisogni/desideri dell’utilizzatore del modello. Questo significa che la scelta del sistema
target da modellare, i livello di dettaglio i.e. “granularità” del modello e il linguaggio di
rappresentazione adottato devono essere tali da soddisfare le richieste dell’ utilizzatore (che
spesso è anche il committente dello sviluppo del modello). Un utilizzatore può usare un
83
modello per una serie di motivi diversi. Fra questi i più importanti sono 1) la descrizione di un
sistema reale già esistente o 2) la specifica di un sistema reale futuro (definizione delle
specifiche di sistema) come base di partenza per una sua costruzione. Allora ci si pone la
seguente domanda: “Nel nostro caso chi è l’utilizzatore del modello e cosa desidera?” Risposta:
“Nel nostro caso l’ utilizzatore del modello gestionale è la TelCo, cioè una impresa
commerciale for profit che vende servizi TLC a una comunità di Clienti”.
•
Utilizzazione dei modelli gestionali da parte della TelCo
La Tavola 1.2.3.1 mostra come una TelCo possa utilizzare i modelli gestionali di reti e
servizi TLC per una molteplicità di scopi diversi e per vari scenari. Fra questi, i più importanti
sono 1) la rappresentazione dei processi gestionali legacy (processi già esistenti in azienda)
e.g. per individuare nuove possibilità di automazione di processi che al momento sono eseguiti
manualmente e 2) la specifica di processi e del relativo software applicativo per un nuovo
sistema informatico gestionale (Rete di Gestione). Fra poco vedremo che in una TelCo questi
scenari di utilizzazione si verificano nell’ambito di iniziative di “continuous improvement” o di
“business process re-engineering” rese necessarie dai continui cambiamenti socio-economicotecnologici del macroambiente in cui la TelCo è immersa (vedi anche Punto 3 nella Tavola
1.2.3.1)
TAVOLA 1.2.3.1 SCENARI di UTILIZZAZIONE dei MODELLI GESTIONALI
1) Semplificazione nelle comunicazioni interne (intra-TelCo) ed esterne (e.g. fra TelCo
partners e con suppliers di tecnologie ICT)
2) Accertamento dei livelli di produttività e qualità nella fornitura/erogazione dei servizi
TLC
3) Verifica delle opportunità di automazione dei processi gestionali e integrazione dei
sistemi di supporto (e.g. programmi di Continuous Improvement o Business Process Reengineering)
4) Supporto alle decisisioni relative agli investimenti da effettuare nella acquisizione dei
sistemi di supporto.
5) Accelerazione del processo di training (addestramento professionale) del personale
con meno esperienza
Allora, alla luce di quanto detto, valgono le seguenti considerazioni riassuntive.
i)
Il legame “Requisiti del sistema informatico gestionale”-“Obiettivi di business”
Le attività di gestione di reti e servizi TLC sono svolte da una TelCo, con la collaborazione
degli Utenti, in un contesto commerciale. Gli scopi della gestione e quindi i requisiti delle
risorse di supporto (manuali e automatizzate) devono allinearsi con gli obiettivi di business
della TelCo stessa. In particolare il legame fra i requisiti del sistema informatico gestionale e
84
gli obiettivi di business di una TelCo è un punto centrale da tener presente nello sviluppo dei
modelli gestionali. Ricordiamo ancora una volta (e lo vedremo con maggior dettaglio in seguto)
che i modelli gestionali (funzionale e informativo) costituiscono la base di partenza per creare il
software applicativo del sistema informatico gestionale, e.g. vedi Fig.1.1.4.1.
ii) “Obiettivi di business” di una TelCo
Ma quali sono gli obiettivi di business di una TelCo? Una discussione generale sulla natura
degli obiettivi di business di una TelCo è presentata nell’ Appendice 7 al Capitolo 1 e se ne
consiglia la lettura. In generale gli obiettivi di business variano con la missione di una impresa
e quindi nel caso nostro variano da TelCo a TelCo. In una TelCo essi sono formulati per vari
orizzonti temporali e a vari livelli di dettaglio fino ad arrivare alla specifica e assegnazione di
compiti alle singole unità organizzative da completare entro periodi di qualche anno. Per il
momento è sufficiente ricordare che fra gli obiettivi di business di alto livello più importanti ci
sono quelli nelle aree di “marketing” e “innovazione”: i primi mirati alla creazione di valore per
il Cliente e i secondi mirati ad evitare forme di obsolescenza rispetto alla concorrenza (vedi
Tavola A.7.1). La creazione di valore per il Cliente a sua volta implica il soddisfacimento dei
bisogni del Cliente stesso e.g. sposando il paradigma “faster service introduction, improved
quality of service at a lower cost” (in Italiano: “prima, meglio e a meno”). Questo, come
vedremo nel par.1.1.2.5, può ottenersi anche in presenza di condizioni di mercato mutevoli
attraverso l’implementazione di politiche di “continuous improvement” dei processi aziendali
basate sulla automazione dei processi con sistemi di supporto facilmente integrabili (e.g. del
tipo “Off-The-Shelf” cioè commercialmente disponibili e con interfacce standardizzate)
NOTA BENE Ricordiamo che una tecnologia ICT “off-the-shelf” (letteralmente: “presa dallo scaffale di un
negozio”) è una tecnologia commercialmente disponibile su larga scala ed è il contrario di una tecnologia
“customizzata” cioè una tecnologia che di volta in volta deve essere realizzata ad hoc per un certo
“customer” (cliente) e per una certa applicazione. In generale una tecnologia off-the-shelf è una tecnologia
standardizzata de facto o de jure (vedi Cap.3) capace di inter-operare (interwork) con altre tecnologie
commercializzate da vendors diversi
iii) Modelli gestionali in una TelCo
I modelli funzionali è bene che rappresentino le attività gestionali utilizzando lo stesso
“linguaggio” della TelCo e si posizionino ad un livello di specializzazione tale da offrire il
massimo beneficio ai loro utilizzatori i.e. devono essere modelli processuali che identificano i
processi di business ad un livello tale da essere utile per la progettazione dei sistemi di supporto.
I modelli informativi devono rappresentare l’informazione processata, trasferita e immagazzinata
nei processi di business con un linguaggio comprensibile a tutti (businessmen e ingegneri ICT)
e.g. linguaggio UML, Universal Modeling Language come quello usato nel modello SID (Shared
Information & Data model) del TMF. (ITU-T Recommendation M.3190, “Shared Information &
Data Model”, 07/2008).
NOTA BENE. 1) Il posizionamento dei processi di business all’interno di una TelCo è discusso
nell’Appendice 7 al Capitolo 1 (Vedere in particolare la Fig.A.7.4 per comodità riportata in
Fig.1.1.2.3.1) 2) Per gli studenti interessati a saperne di più sul linguaggio UML si consiglia:
C.Batini et al. “Sistemi informativi” Volume II, Modelli e Progettazione, Capitolo 2.
85
PROPRIETA’
Finanziatori
(Azionisti)
$
$
B
TELCO
AMMINISTRAZIONE
CdA, Am. Deleg., CEO
TOP MANAGEMENT
(COO + Vice-Presidenti)
MIDDLE MANAGEMENT
C
Gruppi
Funzionali
F1
DIPENDENTI
(Impiegati, tecnici,
operai)
F2
F3
F4
F5 …………. Fn
$
P1
P2
Utenti
PROCESSI di BUSINNESS
P3
A
Fornitori
PRODOTTI TLC
RISORSE MATERIALI
SERVIZI
(Sistema TLC)
$
$
Tecnologie
Vendors
Fig. 1.1.2.3.1
iv)
D
Interno TelCo
Struttura organizzativa interna di una Telco . E’ stata ignorata la concorrenza
Il quadro completo
A questo punto riconosciamo che è successo qualcosa di importante! Inizialmente per
soddisfare la nostra curiosità conoscitiva di studiosi della GST abbiamo sviluppato un modello
gestionale concettuale ma poi è inesorabilmente comparso al nostro orizzonte un utilizzatore
del modello che valuterà la bontà del nostro lavoro di modellatori e noi, da buoni ingegneri
pragmatici, ci siamo chiesti “Quanto è utile il nostro modello concettuale a questo nuovo
utilizzatore?” A questo punto abbiamo riconosciuto che il nostro modello oltre ad avere un
valore epistemologico in un contesto accademico doveva anche essere di pratica utilità per una
TelCo e ciò poteva esser fatto tramite specializzazione con l’aggiunta di modelli operativi
dinamici. Per essere più precisi, abbiamo riconosciuto che la portata dei modelli gestionali è
molto più vasta se si tiene conto del fatto che essi sono utilizzati in pratica dal gestore TelCo e
che quet’ultimo opera in un libero mercato altamente competitivo in un business
necessariamente “orientato al Cliente”.
L’importanza del Cliente e di un accudimento particolarmente attento delle relazioni TelCo-Cliente derivano dal
fatto che in un libero mercato concorrenziale il Cliente non solo è la fonte principale di entrate per la TelCo ma
egli non ha nessun obbligo di acquisire i prodotti di cui ha bisogno da una TelCo predeterminata. Infatti il Cliente
86
può scegliere i prodotti che vuole dalla TelCo che vuole in base a una sua libera scelta, basata sulla
massimizzazione del loro “valore” (rapporto beneficio/costo come percepito dal Cliente).
Ci si rende allora conto del fatto che in pratica la effettiva utilizzabilità di un modello
gestionale in ambito TelCo si basa sulla sua capacità di permettere lo sviluppo di sistemi
informatici gestionali tesi alla creazione di valore per lo stesso gestore TelCo in un modus
operandi “orientato al Cliente” i.e. in un contesto aziendale tipico di una impresa che opera in
un libero mercato delle TLC su base globale e in presenza di imprese concorrenti.
Nello sviluppo di un nuovo modello gestionale “più utile” del modello concettuale di
Fig.1.1.1 si tratta quindi non solo di specializzare le attività e l’informazione gestionale bensì si
tratta anche di effettuare un cambiamento drastico di approccio alla gestione di reti e servizi
TLC (quello che in letteratura è stato definito un “paradigm shift” i.e. un “cambio di modo di
pensare”) passando da un contesto gestionale “generico” ad un contesto aziendale che tiene
conto delle specificità di una odierna impresa commerciale fornitrice di servizi TLC (TelCo)
dove le attività gestionali si svolgono con modalità dettate da esigenze di un “customer
oriented business”, con un format processuale altamente prescritto (al limite
standardizzato) adatto a livelli di automazione & integrazione elevati e, negli ultimi tempi,
con un ruolo crescente della “Rete” (internet…ovviamente!) per le relazioni di e-business
esterne e.g. CRM, B2B.
La “customer orientation”, cioè l’orientamento al cliente del business dei servizi TLC,
assieme alla liberalizzazione e globalizzazione dei mercati e all’insorgere della concorrenza e
quindi alla crescita di iniziative di marketing e innovazione (innovazione di prodotto, processo
o innovazione “sociale”) sono caratteristiche maturate a metà anni 90 e tuttora della massima
attualità. Per più dettagli si vedano i par.4.6.2.4 e 4.6.2.5 del Capitolo 4 (Parte I) e Appendice
6 al Capitolo1.
Quindi ricordare che, come indicato nel par.1.0.3.3, all’interno di una TelCo che opera
in un libero mercato le attività gestionali si svolgono sotto forma di processi di business
finalizzati sia al raggiungimento degli scopi della gestione sia al conseguimento degli obiettivi
di business (business objectives) dell’impresa TelCo e, poiché il business è “customer
oriented”, tesi in maniera prioritaria alla creazione di valore per il Cliente. (Vedi Appendici 6
e 7 al Capitolo1). Qui di seguito e nel par. 1.4 vedremo che è proprio la caratteristica dell’
“orientamento al cliente” che determina la necessità da parte della TelCo di collegare vari
processi di business in “flussi operativi end-to-end”. Vedremo che la pianificazione/
progettazione dei sistemi di supporto dei flussi operativi end-to-end richiede conoscenze
interdisciplinari e competenze professionali trasversali Engineering – Business in fase di
“Product Development”. (vedi Tavola 1.3.1.2 per la definizione delle aree conoscitive
“Engineering” e “Business”)
1.1.2.4
Il macro-ambiente in cui opera la TelCo: cambiamenti PESTER nel settore TLC
Ma non basta! Finora, partendo da un modello gestionale concettuale, abbiamo
riconosciuto la necessità di specializzarlo a livelli operativi per renderlo più utile nell’ambito di
una impresa commerciale TelCo, ma abbiamo ignorato un altro problema importante: la
dinamica dei cambiamenti nel macroambiente TLC circostante la TelCo e il loro impatto
87
sulle attività gestionali svolte al suo interno. Una caratteristica specifica del business TLC è un
“cambiamento” evolutivo ma profondo e di vasta portata, causato da forze di natura diversa
e.g. 1) nuove esigenze da parte dei clienti con richieste di nuovi servizi TLC, 2) nuova
regolamentazione del settore TLC, 3) nuovi modelli di business con nuove reti di relazioni
commerciali fra TLC Stakeholders e.g. TelCo di vario tipo e ICTS, 4) mutamenti politici e
socio-economici, 5) aumento del numero di competitors e di competitività fra TelCo, 6)
progresso tecnologico nel campo delle tecnologie ICT etc. Questi cambiamenti si intrecciano ed
evolvono nel tempo in maniera complessa e talvolta difficilmente prevedibile. In un tentativo di
semplificazione, essi sono stati indicati complessivamente col nome di “cambiamenti
PESTER”, iniziali di Politics, Economy, Society, Technology, Environment, Regulation,
termini indicativi dei settori dove i cambiamenti si verificano. Noi adotteremo questa
terminologia. Alcuni cambiamenti PESTER avvengono con tempi caratteristici relativamente
brevi (il “ciclo di vita” di una tecnologia ICT, specialmente il settore Consumer Electronics dei
terminali TLC, è di alcuni anni) e sebbene avvengano nel macroambiente esterno alla TelCo
purtuttavia essi hanno un impatto importante 1) sui processi di business interni alla TelCo e.g.
gestione di reti e servizi TLC o 2) sui processi di business interni ad una “rete del valore”
(“value network”) di cui la TelCo può far parte e sui relativi “modelli di e-business” che la
governano.
NOTA BENE. Per “e-business” noi adottiamo la definizione dell’ITU-T “e-business is understood as the
interaction among business partners with the help of information technologies” riportata nella
raccomandazione ITU-T, Recom. M.3050.1 “Enhanced Telecom Operations Map (eTOM) – The business
process framework”, 06/2004, pag. 34).
SPIEGAZIONE 1.1.1.5.1 Una “rete del valore” è un rete commerciale di imprese legate da relazioni di
business finalizzata alla creazione di valore nella produzione/vendita di un certo prodotto a certe classi di
Clienti e.g. imprese ICT Supplier, Network Operator, Wholesale Service Provider, Intermediary Service
Provider e Retail Service Provider, quest’ultimo per la fornitura di servizi TLC ad una comunità di Clienti
finali (Per la definizione di “valore” e “Rete del Valore” vedi DEFINIZIONE 2.2.3.1 nel Capitolo 2 e le
Appendici 6 e 7 al Capitolo 1). Una rete del valore è la implementazione di un “modello di business”
(“business model”) che specifica le relazioni di business fra i vari partecipanti (vedi Appendice 7 al Capitolo
1 e Fig.A.7.8).
1.1.2.5
Flessibilià, prontezza e adattabilità del modello gestionale: automazione e
integrazione di sistemi e processi
A fronte di questa dinamicità nel macroambiente esterno, la TelCo deve offrire una
risposta adeguata. Più precisamente una TelCo deve svolgere una attività gestionale non solo
orientata al Cliente ma anche sostenibile nel tempo i.e. capace di far fronte ai cambiamenti
PESTER. Questo è possibile se la attività gestionale e i relativi sistemi di supporto come
minimo sono dotati delle seguenti caratteristiche: flessibilità (capacità di modificarsi),
prontezza (tempi di risposta brevi) adattabilità (natura della risposta in linea con la natura del
combiamento esterno) e scalabilità (capacità di espandersi per sopperire a carichi
computazionali crescenti senza cambiamento di paradigma). Da un punto di vista operativo
queste esigenze si trasferiscono nella necessità di supervisionare e controllare i flussi
informativi aziendali e quindi i processi di business all’interno della TelCo o all’interno della
“value network” di cui la TelCo può far parte, in maniera flessibile, pronta, adattabile e
scalabile in modo tale da conseguire gli obiettivi di business anche in presenza di
condizionamenti esterni mutevoli. Tutto questo è possibile automatizzando i processi di
88
business (per quanto possibile) tramite tecnologie computazionali digitali (i cosiddetti “sistemi
di supporto”) che sono specializzate/ottimizzate per i vari tipi di gestione locale (e.g. OS,
Operations Systems, OSS/BSS, Operation/Business Support Systems, Sistemi di Supporto alle
Operatività/Business) e che sono poi integrate in un unico sistema informatico. Sistema
informatico, se necessario, distribuito su tutta la value network attraverso interfacce
possibilmente standardizzate in modo da rendere possibile l’utilizzo di componenti Off-TheShelf (per una definizione di “integrazione” vedere NOTA 1.1.2.9.1)
Una struttura processuale supportata da un alto numero di componenti automatizzati
commercialmente disponibili “Off-The-Shelf” e poi integrati in maniera “loosely coupled”
attraverso interfacce standardizzate si presta bene a fornire una risposta pronta ed accurata
(ricordare queste due parole!) alle sfide poste dai cambiementi PESTER e, al tempo stesso, è
modificabile nell’ambito di iniziative di miglioramento continuo (“continuous improvement”)
o riprogettazione (“business process redesign”) di natura più o meno radicale (e.g. “business
process re-engineering”), iniziative che la TelCo avrà cura di portare avanti consistentemente
e diligentemente nel tempo…….se vuole sopravvivere e prosperare in un libero mercato
altamente competitivo come quello delle TLC 2008!
Si tratta quindi di una gestione condotta su base “processi di business” soggetta non
solo a ridisegno/ miglioramento dei processi di business esistenti (business process
redesign/improvement) ma anche a eventuali modifiche/espansioni di questi processi effettuate
in house o delegandone la responsabilità ad imprese esterne (outsourcing). Nei due casi si
parla anche di politiche dell’ innovazione aziendale “centripete” o “centrifughe”. (vedi
G.Bruno, “Ideare e progettare l’operatività nelle TLC”, CSELT, 2000, p. 26): [A questo punto si
consiglia la lettura di A.7.1 relativa a “Marketing” e “Innovazione” in una TelCo nella Appendice 7 al
Capitolo 1]
1.1.2.6
Il modello concettuale di Fig.1.1.1 come infrastruttura bidimensionale di
riferimento per i processi di business di una TelCo
Allora si ritorna alla domanda: “Nella realtà evolutiva e dinamica in cui opera una
TelCo in presenza di continui miglioramenti/riprogettazioni dei processi di business e/o dei
modelli di business in risposta a poderosi cambiamenti PESTER, quali sono i limiti di validità e
di utilità di un modello gestionale statico come quello di Fig.1.1.1”? La risposta è a questo
punto facile: il modello concettuale di Fig.1.1.1 va modificato/ampliato/ specializzato con
l’inclusione di processi gestionali (processi di business) vieppiù dettagliati capaci di offrire ai
suoi utilizzatori l’informazione di cui essi abbisognano per svolgere le loro attività di gestione
in maniera efficace/efficiente e al tempo stesso adatti ad essere modificati nel tempo attraverso
processi di “continuous improvement” o “Business Process Re-engineering”. A questo
proposito vedere par.4.6.2.6 “I nuovi modelli gestionali basati sulla filosofia BPR”. Per
soddisfare queste esigenze l’osservatore/modellatore che vuol creare un nuovo modello
gestionale (più “utile” del precedente) mette a fuoco e aggiunge progressivamente dettagli
processuali nei vari domini gestionali individuati dal modello di Fig.1.1.1. (Fig.1.1.2.7.1A e B)
Il modello concettuale viene così a costituire una grande infrastruttura bidimensionale
di riferimento (bidimensional reference framework) entro la quale il modellatore
89
progressivamente aggiunge/evidenzia i dettagli della dinamica processuale della gestione.
Così, col modello concettuale (statico) si può apprezzare “scope and breadth” cioè
l’”ampiezza e la portata” della gestione mentre con la struttura gerarchica dei processi
gestionali sempre più specializzati in esso contenuti si può apprezzare la “depth” della gestione
cioè analizzare la gestione a profondità sempre più spinte evidenziandone gli aspetti dinamici
con dettaglio crescente.
1.1.2.7
Modelli processuali: le mappe processuali TOM e e-TOM del TeleManagement
Forum/ITU-T
La espansione di un modello gestionale concettale in un modello che pur ritenendo le
caratteristiche statiche della gestione è capace di descriverne le caratteristiche processuali
dinamiche è proprio quello che il consorzio internazionale TeleManagemnt Forum ha fatto nel
2000 con la “specifica tecnica pubblica” modello TOM (Telecom Operations Map) di
Fig.1.1.2.7.1A e poi con una sua modifica/espansione denominata modello e-TOM (enhancedTelecom Operations Map) mostrata nella Fig.1.1.1.6.1B (vedi anche Appendice 3 al Cap.1).
Questo modello è stato standardizzato nel 2004 dall’ITU-T. Entrambi modelli, nati come
“specifiche tecniche pubbliche” (vedi Capitolo 3), sono modelli processuali, inseriti in una
infrastruttura bidimensionale di riferimento, sviluppati con il contributo delle principali TelCo
in un contesto di collaborazione internazionale. Essi non solo sono ancora modelli “generici”
cioè tecnologicamente neutri e indipendenti da particolari scenari di servizio ma sono anche
validi indipendentemente dalla struttura organizzativa delle singole TelCo e dal ruolo di
business che esse possono svolgere in i eventuali “reti del valore” e.g. wholesale connectivity
provider (wholesaler), third party service provider (TelCo partner), intermediary, TelCo retailer
(Vedi Fig.1.1.2.8.1).
L’inserimento dei modelli processuali (dinamici) nei modelli di riferimento (statici)
avviene graficamente sottoforma di “rettangoli annidati” (nested boxes) come mostrato nelle
Fig. 1.1.2.7.1A,B e nelle Fig.A3.2 e A3.3 nell’ Appendice 3 al Capitolo 1. Nel modello e-TOM
la infrastruttura statica di riferimento si sviluppa su due livelli: il livello zero (massima
generalizzazione, mostrato anche in Fig.1.0.3.3.1) e il livello 1 (Fig.A3.2). All’interno di questa
infrastruttura statica sono poi inseriti due strati di processi (modelli processuali dinamici):
“processi” situati al livello 2 (Fig.1.1.2.7.1.1B) e “sotto-processi” situati al livello 3 (vedi
Fig.1.1.2.7.1C)
Il modello e-TOM del TMF è stato ufficialmente riconosciuto nel 2004 come standard
de jure ITU-T (“standard e-TOM”) e pubblicato in una serie di Raccomandazioni M.3050
riportate nella NOTA BIBLIOGRAFICA 1.1.2.7.1 (qui sotto)
NOTA BIBLIOGRAFICA 1.1.2.7.1. Elenco delle Raccomandazioni ITU-T relative allo standard e-TOM (enhanced
Telecommunications Operations Map).
Fra parentesi sono indicati i corrispondenti Rapporti Tecnici del
TeleManagement Forum.
M.3050.0: eTOM – Introduction.
M.3050.1: eTOM – The business process framework. (TMF GB921 v4.0.)
M.3050.2: eTOM – Process decompositions and descriptions. (TMF GB921 v4.0
Addendum D.)
M.3050.3: eTOM – Representative process flow. (TMF GB921 v4.0 Addendum F.)
90
M.3050.4: eTOM – B2B integration: Using B2B inter-enterprise integration with the
eTOM. (TMF GB921 v4.0 Addendum B.)
M.3050 Supplement 1: eTOM – ITIL application note. (TMF GB921 v4.0 Addendum L.)
M.3050 Supplement 2: eTOM – Public B2B Business Operations Map (BOM). (GB921
Addendum C.)
M.3050 Supplement 3: eTOM to M.3400 mapping.
Il modello statico di Fig.1.1.1 può allora essere metaforicamente visto come un grande
palcoscenico suddiviso in un insieme di compartimenti (domini gestionali) all’interno dei quali
sono allocati processi di business standardizzati che tutte le TelCo possono utilizzare nella
gestione di reti e servizi TLC come elementi di “flussi operativi end-to-end”. Questi processi
sono abilitati da tecnologie ad hoc denominate Sistemi di Supporto (Support Systems, SS) per
la parte automatizzata e da attori umani (addetti alla gestione) per la parte
manuale. Quindi, attenzione! Si prevede che questi processi standardizzati siano utilizzati dalle
TelCo come building blocks da integrare in flussi di processi operativi (vedi Fig.1.1.2.7.2)
finalizzati a conseguire i loro obiettivi di business. Primi fra tutti quelli di Customer Care
Management tesi al soddisfacimento diretto delle esigenze dei Clienti (customer oriented
business). La conoscenza di “chi-fa-che-cosa” utilizzando la stessa library di processi operativi
ovviamente facilita la cooperazione fra TelCo e la collaborazione fra unità organizzative
all’interno di una stessa TelCo.
SPIEGAZIONE 1.1.2.7.1 Ma cosa significa standardizzare un processo operativo? La mappa processuale e-TOM
specifica i processi con grande precisione in termini di tre caratteristiche (vedi Fig.4.6.9.2):
1. “stimoli di ingresso” (input triggers),
2. “stimoli in uscita” (ingressi per altri processi) & “risultati in uscita” (output results)
3. “funzioni gestionali da svolgere”
Quindi il contenuto di ogni processo è descritto in termini di “funzioni gestionali” da
svolgere. Esse sono “units of processing” specificate nel modello funzionale FCAPS descritto
nella ITU-T Recommendation M.3400. Si stabilisce così una relazione fra il modello
processuale e-TOM e il modello funzionale FCAPS (vedi ITU-T Recommendation :M.3050.
Supplement 3. Vedi anche Fig.4.6.9.2 e Fig.4.6.10.1 nel Cap.4).
I flussi di processi, di cui
parleremo con grande dettaglio fra poco, sono poi modificabili in risposta ai cambiamenti
PESTER che agiscono sulla TelCo (innovazione tecnologica, spinte sociali, politica, economia,
concorrenza etc.) nell’ambito di iniziative di “Continuous Improvement”, “Process Re-design”
o “Process Re-engineering” (Vedi 1.1.2.1).
91
RAPPRESENTAZIONE AD “ALBERO” E A “SCATOLE ANNIDATE” DI UNA
DECOMPOSIZIONE FUNZIONALE GERARCHICA
HYERARCHICAL DECOMPOSITION (Graphical Representations)
Level 1
Level 2
Level 3
Level 4
SPECIALIZATION
(Moving horizontaly
to the right)
Bidimensional
“Tree”
Architecture
TREE
ROOT
BOX
BOTTOM
SPECIALIZATION
(Moving vertically out of the paper)
2
1
4
3
Tridimensional
“Nested Box”
Architecture
Struttura MIRT
FUNCTIONAL AREA
O
B
J
E
C
T
MANAGEMENT
DOMAIN
NESTED BOX
SPECIALIZATION
T
Y
P
E
Struttura MIRT
92
PROCESSI OPERATIVI (Modello TOM del TMF)
TOP DOWN
CUSTOMER
Customer Interface Management Processes
Customer Interface Management Processes
Service Fulfillment
Service Assurance
Service Billing
Customer Care Management
Sales
Sales
Order Handling
Order Handling
Problem
Problem
Handling
Handling
Customer
CustomerQoS
QoS
Management
Management
Invoicing
Invoicing&&
Collections
Collections
Service
ServiceQuality
Quality
Management
Management
Rating
Rating&&
Discounting
Discounting
Service Development & Operations Management
Service
Service
Planning
Planning
& Development
& Development
Service
Service
Configuration
Configuration
Service
ServiceProblem
Problem
Management
Management
Network & Systems Management
Network
Network
Planning
Planning
&&Development
Development
Network
Network
Provisioning
Provisioning
Network
Inventory
Management
Network
Network
Maintenance
Maintenance
&&Restoration
Restoration
Network Data
Management
S
y
s
t
e
m
s
M
n
g
m
t
P
r
o
c
e
s
s
e
s
Network Element Management Processes
Network Element Management Processes
BOTTOM UP
I
n
f
o
r
m
a
i
o
n
Physical Network / Information Technology
Persona TLC
Fig.1.1.2.7.1 A
Modello TOM “Telecom Operations Map” del TMF. I processi per la gestione delle
operazioni (processi operativi) sono inseriti in un framework statico di riferimento simile a quello di
Fig.1.1.1 I processi possono essere ulteriormente specializzati in sotto-processi e questi in sotto-sotto
processi e così via, creando così una struttura gerarchica (Rappresentazione a “rettangoli annidati” o
“nested boxes”). I tre colori celeste, rosa e verde individuano i tre raggruppamenti Fulfillment, Assurance e
Billing come definiti nel par. 1.1.1 (modello FAB). I processi “Information Systems Management” sono
eseguita dal “Gestore del Gestore” (Gestione del secondo ordine)
93
PROCESSI OPERATIVI (Modello e-TOM dell’ITU-T)
Customer Interface Management
CRM
BSS
1. CRM Op.
Support &
Process
Mngmt
2. CRM
Operations
Readiness
3. Sales & Channel
Management
1. Marketing
Fulfillment
Response
2. Order
Handling
1. Problem Handling
3. Selling
Retention & Loyalty
Service Management & Operations (SM&O)
1. SM&O Support
& Process Mngmt
OSS
2. SM&O Readiness
1.Service
Problem
Management
1. Service
Configuration
& Activation
OS
NSS
2. Resource Mngmt &
Operations
1.Resource Trouble
Mngmt
2. Resource
Perf. Mngmt.
1. Resource
Provisionig
Resource Data Collection & Processing
Supplier/Partner Relationship Mngmt
BSS
1. SPRM Oper. Support
& Process Mngmt
2. SPRM Operations
Readiness
Oper. Supp. & Readiness
1. Service &
Specific Instance
Rating
2. QoS Analysis.
Action & Reporting
Resource Management & Operations (RM&O)
1. RM&O Support &
Process Mngmt
1. Billing &
Collections
Management
2. Customer
QoS/SLA
Management
1. S/P Problem
Reporting & Mngmt
1. S/P
Requisition
Mngmt
2. S/P Performance
Mngmt
1. S/P
Settlements
& Billing Mngmt
. Supplier/Partner Interface Management
Fulfillment
Assurance
Billing
Fig.1.1.2.7.1B Processi gestionali al livello 2 (primo livello dinamico) del modello standard “e-TOM”
del TMF/ITU-T e tipologie dei sistemi di supporto. Notare l’aggiunta del raggruppamento “Operations
Support & Readiness” al modello operativo Fulfillment-Assurance-Billing (FAB). I processi in rettangoli
gialli fanno parte del flusso operativo end-to-end di Fig.1.3.3.4. Lo strato RM&O corrisponde agli strati
di gestione Reti e Elementi di Rete nella mappa TOM. Da: ITU-T Rec. M.3050.2 (06/2004)
94
Resource Provisioning
(Secondo Livello)
Dettaglio minimo per una
rappresentazione dinamica
della gestione
Terzo livello
Allocate &
Deliver
Resource
Configure &
Activate
Resource
Test
Resource
Collect,
Update & Report
Resource
Configuration
Data
Fig.1.1.2.7.1C Decomposizione funzionale del processo “Resource Provisionig” (secondo
livello) di Fig. 1.1.2.7.1B in quattro sottoprocessi del terzo livello (modello e-TOM
del TMF/ITU-T).
1.1.2.8
•
Gestione TLC, con la “G” maiuscola: sistema informatico integrato per abilitare i
flussi operativi end-to-end
Brutte notizie?
A questo punto si potrebbe legittimamente osservare che i processi gestionali da inserire
nel modello statico di Fig.1.1.1 sono in effetti molteplici e specializzati lungo due
“dimensioni”: 1) “oggetti” materiali o immateriali da gestire (e.g. reti, servizi, customer care
etc.) e 2) aree funzionali o raggruppamenti di processi gestionali da eseguire. Si tratta quindi di
processi che implementano una molteplicità di gestioni di natura diversa (per comodità indicate
come gestioni locali, ognuna dedicata a certi “oggetti” da gestire e certe funzioni gestionali).
Quindi il nostro tentativo di definire “una” gestione di sistemi e servizi TLC sembrerebbe
miseramente fallito! Il prezzo che abbiamo pagato nel passaggio da livello concettuale a
livello operativo nel nome di una maggiore “utilizzazione” del modello è stato molto alto in
termini di frammentarietà/complessità del modello gestionale!
Infatti, pur nell’ambito di un unico modello gestionale indipendente da Tecnologie ICT
e da particolari scenari di servizio TLC sembrerebbe emergere di nuovo una serie di modelli
gestionali locali frantumati in una molteplicità di processi gestionali perdippiù definiti a vari
livelli di specializzazione.
95
CUSTOMER
1
2
(Access)
Sales
Order Handling
(Order)
Service
Request
4
Check
Complete
20
Order Status &
Completion
19
Service
Complete
Service
Configuration
(Install)
12
Order
(Inquiry)
WorkForce
Mngmt
Security
3
(Configure)
11
Ntwk
Access
Check
8
7
Install
Complete
Install
Request
Assign.
Request
6
5
18
Assign.
Complete
Ntwk Config. Request
Ntwk Configuration & Routing
Ntwk Provisioning
(Configure)
Ntwk Config. Complete
(Assign/Activate)
17
Test Request
13
16
Test Complete
Ntwk
17’’ Inventory
17’ Mngmt
Update
9
Element
Config.
10
Test
Mngmt
Config.
Complete
Perform Test
14
15
Test Data
Fulfillment
Processes
Ntwk Elem. Mngmt
Ntwk Elements
Assurance
& Billing
Processes
Persona TLC
Fig.1.1.2.7.2 Flusso operativo “Richiesta e installazione di una istanza di servizio” (Service
Provisioning) realizzato con processi operativi standard presi dalla mappa TOM di Fig.1.1.2.7.1A
(Rapporto GB910 del TMF, Aprile 1999, pag.20). Il flusso mostrato si svolge all’interno del
raggruppamento processuale “Fulfillment”. Notare le frecce orizzontali tratteggiate rappresentative
degli accoppiamenti con processi operativi appartenenti ai raggruppamenti “Assurance” e “Billing”.
Le frecce a due punte indicano collegamenti con TelCo partners I rettangoli tratteggiati
rappresentano sottoprocessi del processo “Network Provisioning” non rappresentati nella mappa
TOM ma mostarti in Fig.4.6.10.2
96
Accept Offer (*)
Service Order (**)
(*) Offerta effettuata
dal SP durante un
processo “Pre-order”.
Già esiste un SLA.
(**) Ordine piazzato
dal cliente dopo
consultazione di un
catalogo servizi
Check customer details
Create SLA
SLA
Mngr
Confirm Order Request
Order
SLA
Sub-order
Peer SP
Develop Order Plan
Service Configuration
EXIT
Release resource
Change plan or reject
order
Service, SLA
Peer SP
Service activation
Notify
customer
Service
Notify billing, performance
and SLA mngmt
END
Fig.1.1.2.7.3 Flusso operativo di “Service Provisioning” secondo Chen & Kong.
Notare la creazione di “oggetti” (cerchi verdi).
97
•
No! Customer oriented business……..über alles!
Ma invece non è così….o, perlomeno, è così ma non è tutto! La ragione è semplice.
Oggi in un libero mercato il gestore TelCo conduce un “customer oriented business” cioè un
“business orientato al Cliente” i.e. un business che, seppur mirato al conseguimento degli
Richiesta dal Cliente
Notifica al Cliente
Customer Interface Management
Customer
Relation
Management
(BSS)
Service
Management
(OSS)
Strati gestionali
Resource
Management
(NSS)
Partner/
Supplier
Management
(BSS)
F
A
B
Prova
Partner SP
F1
F2
F3
.
.
.
.
FN
Struttura
Organizzativa
della TelCo
“per Funzioni”
Fig.1.1.2.8.1 Flusso operativo end-to-end per la fornitura di un customer service
sovrapposto al modello statico di Fig.1.1.1. Le strisce verticali appartengono
al modello funzionale FAB (Fulfilment, Assurance, Billing) del TMF.
In basso è mostrata la struttura organizzativa della TelCo. Un flusso operativo
end-to-end coinvolge sempre processi dello strato CRM.
obiettivi di business della TelCo, è finalizzato prima di tutto al soddisfacimento di certe
richieste del Cliente che, si noti bene, avvengono in mercati altamente competitivi (quindi da
trattare con la dovuta considerazione!). A sua volta, ciascuna richiesta è soddisfatta in
maniera efficace/efficiente solo se per essa la TelCo porta a termine con successo un “insieme
coerente e completo di attività gestionali ottimizzate su base locale e poi integrate” (Vedi
NOTA 1.1.2.9.1). Vedremo fra poco che questo insieme di attività, quando espresso in termini
di processi aziendali, si chiama “flusso di processi operativi end-to-end”. Nel caso di
98
gestione non-automatizzata, avremmo espresso lo stesso concetto dicendo che “una richiesta del
Cliente è completamente soddisfatta solo grazie alla cooperazione di molteplici addetti alla
gestione dotati di competenze professionali diverse ottimizzate settore per settore”. A questo
proposito, si guardi bene l’esempio di Fig. A.6.2. Quindi la frammentarietà/ complessità dei
modelli gestionali, cioè l’ identificazione dei singoli elementi processuali e delle loro
relazioni (linkages), causa della nostra precedente disperazione, in effetti appare come un fase
intermedia necessaria per ottenere poi soluzioni ottimali integrate laddove, come vedremo fra
poco, per “integrazione” si intende la cooperazione “seamless” fra componenti software
“loosely coupled” (meglio se componenti COTS, Commercial Off The Shelf”). Vedi anche
NOTA 1.1.2.9.1. Se non si avesse un modello processuale dettagliato questo tipo di
integrazione (economicamente molto attrattiva) non sarebbe possibile!
Ad esempio, quando il singolo Cliente, nell’ambito di un servizio TLC, richiede alla
TelCo un qualsiasi servizio gestionale (“customer care service” o semplicemente “customer
service”), e.g. un servizio di “service provisioning”, (“richiesta di installazione di una istanza di
servizio TLC” vedi Fig.1.1.2.7.2 ) la TelCo deve eseguire un insieme di processi operativi
integrati in un certo flusso di lavoro. Al Cliente non interessa affatto conoscere le singole
attività gestionali locali o, meglio, i singoli processi operativi che compongono il flusso di
lavoro e nel loro complesso implementano il servizio stesso (vedi anche Fig.1.1.2.7.1A,B). Al
Cliente interessa che il “service provisioning” richiesto avvenga presto e bene e in linea con le
sue aspettative cioè egli è soddisfatto se il risultato finale risponde in maniera soddisfacente
alla sua richiesta iniziale. E questo è vero per un qualsiasi richiesta di customer service
effettuata dal Cliente e per la fornitura del corrispondente servizio da parte della TelCo
(Fig.1.1.2.8.1)
In un “customer oriented business” come quello dettato dalle esigenze di un libero
mercato queste richieste di customer service da parte del Cliente sono di primaria importanza e
sono soddisfatte in maniera efficace/efficiente (prontezza nelle risposte, abbattimento dei tempi
morti, eliminazione delle duplicazioni/ridondanze, riduzione dei costi etc.) se i processi
operativi componenti del customer service sono integrati in un unico flusso operativo
opportunamente automatizzato (end-to-end flow through). Ma vediamo meglio.
•
Flussi operativi end-to-end (“process flows that deliver value for the enterprise”!)
Come spiegato nell’Appendice 6 al Capitolo 1 la aggregazione nel dominio del
tempo, secondo una logica prestabilita, di certi processi operativi (logica e processi
opportunemente scelti per conseguire un certo risultato finale in risposta a una certa richiesta
iniziale), si chiama process flow o flusso di processi operativi o semplicemente flusso
operativo. Esempi di processi operativi ad un alto livello di astrazione sono mostrati nelle
mappe TOM e e-TOM di Fig.1.1.1.5.2A,B. Allorchè un flusso operativo contiene tutti i
processi necessari e sufficienti a processare una richiesta iniziale effettuata dal Cliente e
ottenere il risultato finale richiesto (fornitura completa del customer service richiesto), il flusso
operativo è definito un “flusso operativo end-to-end”. Esempi di flussi operativi end-to-end
sono mostrati nelle Fig.1.1.2.7.2 e 1.1.2.8.1. La Fig.1.1.2.7.2 si riferisce a una richiesta di
“service provisioning” (vedi anche G.Bruno, “Ideare e progettare l’operatività nelle TLC”
CSELT, 2000, pag. 50). Notare come questo flusso operativo richieda la integrazione nel
99
dominio del tempo di dieci processi di cui 6 sono presi dalla mappa TOM di Fig.1.1.1.5.2A e 4
sono sotto - processi del processo “Network Provisioning” (non mostrati nella mappa TOM).
Ora notare che:
1) Un flusso operativo end-to-end contiene processi operativi (chiamiamoli
“elementari”) presi da una library di processi operativi standardizzati, e.g. presi dalla mappa eTOM, la maggior parte automatizzata tramite impiego di Sistemi di Supporto ad hoc del tipo
OS, NSS, OSS, BSS i quali a loro volta sono integrati in grossi sitemi informatici per ragioni
di efficacia/efficienza (vedi NOTA 1.1.2.9.1)
2) Un flusso operativo end-to-end è tipico di un “customer oriented business”. Esso
coinvolge sempre processi dello strato “Customer Relation Management” cioè inizia e/o finisce
sempre dal Cliente e utilizza processi operativi provenienti da varie zone delle mappe TOM o eTOM (vedi Fig.1.1.2.8.1) attraversando strati orizzontali e strisce verticali diverse. Esso è
quindi implementato da Sistemi di Supporto ottimizzati localmente i.e. realizzati con tecnologie
applicative diverse a seconda del dominio gestionale in cui operano (e.g. Java, CORBA, CMIP,
SNMP vedi par.1.4)
3) Un flusso operativo end-to-end può in pratica essere “spalmato” su più imprese
con ruoli di business complementari inserite in una “rete del valore” o “value network” (vedi
DEFINIZIONE 2.2.3.1) che realizza un certo “business model” con la partecipazione di
imprese diverse legate da relazioni commerciali. La Fig.1.1.1.7.2 mostra la “spalmatura” dei
processi TOM sulle imprese partecipi di una “value network”
NOTA 1.1.2.8.1 Ricordiamo che una “rete del valore o value network” è una federazione di imprese che
stabiliscono fra loro certe relazioni di business al fine di produrre/vendere certi prodotti finali nella maniera
più efficace/efficiente possibile (vedi anche DEFINIZIONE 2.2.3.1)
NOTA 1.1.1.7.2 Nel suo rapporto GB910 del Marzo 2000 a pag. 26 il TeleManagement Forum dice: “The
most critical process work is the design and definition of the end-to-end process flows for providing services
to customers”
NOTA 1.1.2.9.1 “Integrazione” non significa la scomparsa di specifiche applicazioni gestionali
specializzate per certi tipi di gestione (i.e. l’abbandono della filosofia “best solution for each
management problem”) come, ad esempio, applicazioni per richiesta/installazione servizi (service
provisioning), controllo della qualità dei servizi (service assurance), fatturazione (billing), in un
unicum monolitico perfettamente omogeneo privo di interfacce interne bensì significa “seamless
interoperability” fra applicazioni gestionali diverse distribuite in una rete di comunicazione dati,
ognuna con interfacce logiche esplicite. Questo significa che in un “sistema informatico
integrato” i vari componenti applicativi fanno parte di un sistema informatico unico all’interno del
quale essi sono naturalmente interconnessi e cooperanti e nel quale i flussi informativi si svolgono
senza soluzione di continuità (seamless). Queste esigenze vanno tenute in debita considerazione
dalla TelCo sin dalla fase di Product Development adottando tecnologie software ad hoc (e.g.
strutture tecnologiche sin dall’inizio tipo “plug & play” per applicazioni “loosely coupled”, vedi
anche capoverso 1.1.5 e Fig.1.1.4) e opportuni sistemi di “workflow control” per lo scheduling dei
flussi di processo.
100
Sales
Order Handling
Rating &
Discounting
Broker
Sales
Problem
Handling
Order Handling
Customer QoS
Management
Invoicing &
Collections
Retailer
Service
Planning
& Development
Service Problem
Management
Service
Configuration
Service
Planning
& Development
Service Quality
Management
Service
Configuration
Service Problem
Management
Network
Provisioning
Network
Inventory
Management
Customer
Customer
Rating &
Discounting
Service Quality
Management
Rating &
Discounting
Network Data
Management
3°Party SP
Network
Planning
& Development
Network
Provisioning
Network
Inventory
Management
Network
Maintenance
& Restoration
Network Data
Management
Connectivity Provider
Fig. 1.1.2.9.2 Un flusso operativo end-to-end è costituito da processi operativi presi dal modello
TOM (vedi Fig.1.1.2A) e da sottoprocressi (non mostrati in figura). Questi processi possono essere
“spalmati” su business stakeholders che svolgono diversi ruoli di business e sono legati da relazioni di
business in una “value network”. (Vedi Fig.A.7.7) La figura mostra cinque ruoli di business, le possibili
relazioni di business e i processi operativi del modello TOM rilevanti a ciascun ruolo. (Consorzio
internazionale TINA-C)
101
1.1.2.9
Integrazione dei Sistemi di Supporto
L’insieme dei processi che compaiono nei flussi operativi end-to-end costituisce un
sistema informativo interno alla TelCo (o distribuito su una “value network” di cui la TelCo fa
parte) e come tale ha seguito in passato e segue oggi l’evoluzione dei sistemi informativi
aziendali da manuali a automatizzati/integrati (vedi C.Batini et al. “Sistemi Informativi”,
Volume 1, “Organizzazione e Reingegnerizzazione”, Franco Angeli, 2001, p.22). Infatti in un
passato ormai lontano si effettuavano prevalentemente processi manuali, poi alcuni di questi
processi sono stati automatizzati con il supporto di “stand alone support systems”, e oggi, i vari
tipi di sistemi di supporto NSS, OSS e BSS (computers più applicazioni) sono integrati in
flussi operativi end-to-end a loro volta integrati in un unico sistema informatico distribuito.
1.1.2.10
Conclusione: la Gestione TLC, con la G maiuscola !
La gestione supportata dal sistema informatico della TelCo (o della value network di cui
la TelCo fa parte) che integra le tecnologie OS, NSS, OSS, BSS abilitanti l’insieme dei flussi
operativi end-to-end è da noi denominata “Gestione TLC”, con la G maiuscola! I flussi
operativi end-to-end permettono di raggiungere gli scopi prestabiliti per la gestione di reti e
servizi TLC (TLC system & service management goals) e al tempo stesso conseguire
obiettivi di business (business objectives) prefissati dal senior management della TelCo in fase
di pianificazione strategica come parte di un business plan aziendale. E’ proprio in base alla
“qualità” dei flussi operativi end-to-end (cioè la capacità di conseguire gli obiettivi di business
prestabiliti in maniera sostenibile) che i clienti e la concorrenza “misurano” la TelCo. Ad
esempio è proprio in base alla prontezza/accuratezza di esecuzione da parte della TelCo delle
sue richieste che il Cliente valuta la bontà (il valore) di un servizio TLC e che lo rende
“efficace” ai suoi occhi o meglio “più efficace” dei servizi TLC offerti dalla concorrenza.
Quindi quando parliamo di “Gestione TLC” facciamo proprio riferimento al fatto che
per ragioni di efficacia/efficienza i vari tipi di gestione locale supportati dalle tecnologie OS,
NSS, OSS, BSS sono individualmente ottimizzati su base locale e.g. con l’uso di tecnologie
software specializzate (e.g. Java, CORBA, CMIP, SNMP) ma sono poi integrati (meglio se
“loosely coupled”) in un sistema informatico unico abilitante l’insieme dei flussi operativi endto-end.
Vedremo nel par.1.3 che l’integrazione di diversi modelli gestionali locali e relative
tecnologie richiede lo sviluppo di “mappature” da un modello gestionale all’altro e la messa a
punto di “integratori tecnologici” per passare da una tecnologia all’altra in maniera “seamless”
(e.g. tecnologia CORBA-tecnologia OSI).
102
NOTA 1.1.2.10.1 A proposito dell’integrazione dei sistemi OSS “sin dall’inizio” riportiamo un
passo del libro di N.V. Jones, “Telecommunications Management”, Virtualbookworm. com, 2004,
p.80 che riteniamo rilevante all’argomento.
“When considering OSS integration strategy many people tend to take the approach of “think
big” but start small. Unfortunately this encourages piecemeal integration implementations and
pretty soon redundancy shows its ugly head. My recommendation would be to think big when it
comes to an “integration” infrastructure. How are these applications going to be integrated? Will
a shared message bus, database, file structure, etc. be used? In other words how will these
systems communicate with each other? Once this has been determined, work hard to get the
infrastructure in place. Then you can break the integration tasks into piecemeal implementations
which can reliably share a common communication infrastructure. Remember to consider
standards such as messaging formats, interfaces between application services, etc.”
1.1.3
Le “dimensioni” della Gestione TLC: tipologie di modelli gestionali
In 1.1.1 abbiamo detto: Parlare di “gestione” significa parlare del “modello gestionale”
bidimensionale di Fig.1.1.1 opportunamente ampliato/specializzato con l’aggiunta dei processi
di business che si svolgono all’interno del gestore TelCo o della value network di cui esso fa
parte.
Infatti abbiamo visto come operando ad un livello di astrazione molto alto (modello
gestionale concettuale) si può comprendere in maniera olistica cosa si intende per “gestione di
sistemi e servizi TLC” indipendentemente dalle specificità di quest’ultimi, ma si perde di vista
la dinamicità di una gestione “per processi” imposta dal modus operandi interno della
impresa commerciale TelCo (modello gestionale operativo o modello processuale). Abbiamo
anche detto che il vantaggio di disporre di un modello concettuale è rappresentato dal fatto che
esso offre una “bird’s eye view” cioè visione complessiva di insieme di ciò che ci interessa.
Lo svantaggio è rappresentato dal fatto che esso è lontano dai dettagli di una realtà di impresa
immersa in un macroambiente in contnua evoluzione ed è essenzialmente di natura statica
cioè incapace di rappresentare i dettagli dei processi gestionali e dei flussi di processi gestionali
legati alla realizzazione degli obiettivi di business della TelCo (processi di business). Se ci si
vuole avvicinare alla realtà dei fatti e agli imprescindibili aspetti “business” della attività
gestionali e capire con maggior precisione e dettaglio cosa si intenda per Gestione TLC, con la
G maiuscola, si devono creare modelli gestionali processuali relativi a “certe” attività
gestionali svolta all’interno di una TelCo dotati di sufficiente dettaglio. Cioè se si parte da un
modello gestionale concettuale e lo si specializza progressivamente per fasi successive, la
dinamicità della gestione emerge solo ad un certo livello di specializzazione e.g. livello 2 del
modello “e-TOM” del TMF/ITU-T (vedi Fig.1.1.2.7.1B)
103
AUTOMAZIONE di “BUS. PROCESS”
TLC Operations Map (TOM)
ANALIZE BUS. PROCESS
(Process Architecture)
Central Information Facility
(Object Model, Data Dictionary)
ANALIZE REQUIREMENTS
Technology Integration Map (TIM)
DESIGN LOGICAL SYSTEM
Application Components
Direction Statement
DEFINE CONTRACTS
Technology Direction
Statement
SPECIFY TECHNOLOGIES
BUILD or BUY DECISION
Procurement Guide
Buy Building
Block
Buy Tools
OOAD
Persona TLC
Fig.1.1.4.1 Automazione di un processo di business preso dalla mappa
TOM del TMF e relativi documenti prodotti dal consorzio TMF
NOTA 1.1.4.1 Automazione di un Business Process (Fig.1.1.4.1)
[TMF Guide Book GB 909 v.3 “Technology Integration Map”, 2001]
La Fig.1.1.4.1 mostra le prime iniziative intraprese dal consorzio TMF e i relativi documenti prodotti
relativamente allo sviluppo di software gestionale OSS/BSS partendo da modelli processuali (Process
Architecture) e informativi (Object Model). Questi modelli sono stati sostituiti più recentemente dal modello
processuale “e-TOM” (vedi par.1.1.2.7) e dal modello informativo “SID” (vedi: “ITU-T Recommendation
M.3190, “Shared Information & Data Model”, 07/2008”).
Si parte da modelli rappresentativi delle caratteristiche statiche e dinamiche del business di una TelCo e in base a
queste si identificano i requisiti del software da sviluppare. Si prosegue con una prima valutazione delle
funzionalità del software e come queste possano essere distribuite in un sistema gestionale distribuito in “software
units of reasonable granularity”. La terza fase è il progetto del “sistema logico” (“logico” significa
“indipendente dalla particolare tecnologia implementativa”). In questa fase si identificano i “componenti” del
sistema logico i.e. i “building blocks” del sistema definiti come “deployable units of interoperating software”.
La interoperabilità dei componenti nel “sistema logico” avviene attraverso un “bus logico”. Si dice anche che la
interoperabilità fra componenti avviene in base a “servizi” richiesti-forniti dai componenti (in tal caso si parla
anche di architettura SOA, Service Oriented Architecture) e che ogni componente pubblica sulla sua interfaccia
l’insieme di servizi che esso può fornire (in tal caso il servizio elementare viene anche detto “contract”). Questi
argomenti verranno trattati di nuovo nel par.1.4.4. La fase successiva è la scelta delle tecnologie software e
hardware implementative dei componenti e del bus logico (hardware platform, operating system, programming
language) assime al “middleware” (vedi par.1.3). L’ultima fase è la decisione di comprare o costruire in proprio il
sistema informatico gestionale specificato nelle fasi precedenti.
104
Gestione TLC quadridimensionale
Modello
architetturale
Modello
computazionale
Distributed infrastructure
to support applications
(Engineering Model)
Logical partitioning
of distributed applications
(Computational Model)
Modello
informativo
Modello
tecnologico
Modello
processuale
(Enterprise Model,
Information Model)
Technology Procurement
and Installation
(Technology Model)
Persona TLC
Fig.1.1.4.2 Rappresentazione multidimensionale della Gestione TLC
adatta allo sviluppo di un sistema gestionale “fortemente” distribuito.
I modelli.fra parentesi sono modelli OD-RM (Open Distributed ProcessingReference Model) dell’ITU-T
Ma c’è di più. Anche la natura e struttura dell’informazione e dei dati trasportati dai
processi gestionali devono avere un dettaglio sufficiente per risultare poi utili sia agli addetti
alla gestione che per progettare/costruire i Sistemi di Supporto in fase di Product Development.
In altre parole stiamo dicendo che il modello funzionale processuale deve essere accompagnato
da un modello informativo capace di rappresentare con sufficiente dettaglio l’informazione e i
dati che fluiscono nei processi o che di volta in volta vengono immagazzinati nelle relative basi
dati. Ma il modello dei processi di business e il modello informativo seppur con i dettagli
desiderati sono sufficienti per ottenere una rappresentazione/specifica completa dei Sistemi di
Supporto che implementano la Gestione TLC? La risposta è NO! Ma allora: quali altri modelli
sono necessari per specificare e quindi per essere in grado di effettuare le scelte e gli
investimenti relativi ai Sistemi di Supporto, possibilmente OTS, necessari a realizzare gli
obiettivi di business della TelCo (Gestione TLC)?
•
La altre dimensioni: computazionale, architetturale e tecnologica
La terza dimensione della Gestione TLC si può individuare visualizzando con la nostra mente
lo sviluppo delle tecnologie abilitanti i processi di business i.e. del sistema informatico
gestionale (Fig.1.1.4.1 e NOTA 1.1.4.1) . A questo punto appare evidente che la terza e la
quarta dimensione della Gestione TLC sono proprio un modello computazionale che
105
rappresenta la distribuzioinec delle funzionalità computazionali nel sistema gestionale.
(creazione di “building blocks” e un modello architetturale che rappresenta la infrastruttura
comunicativa abilitante le comunicazioni fra vari componenti. Infine un modello tecnologico
rappresenta le tecnologie adatte a realizzare concretamente i vari componenti del sistema.
1
MODELLO PROCESSUALE (Modello “Enterprise” nel linguaggio ODP) descrive i
processi di business all’interno di una TelCo necessari a conseguire gli obiettivi di
business prefissati
2. MODELLO INFORMATIVO: descrive la natura e struttura dell’informazione contenuta
nei processi gesrtionali (Fig.1.1.4.3)
3. MODELLO COMPUTAZIONALE: descrive la distribuzione delle funzionalità gestionali
(logic partioning) nel sistema informatico gestionale
4. MODELLO ARCHITETTURALE (Modello “Engineering” nel linguaggio ODP) descrive
l’infrastruttura comuniucativa abilitante le comunicazioni fra i vari componenti
(“building blocks”o “application components”) del sistema gestionale.
5. MODELLO TECNOLOGICO riguarda il procurement e l’installazione delle tecnologie.
Usato per giustificare piuttosto che descrivere le tecnologie software scelte. In particolare
esso serve al vendor per fornire una dichiarazione che le tecnologie scelte supereranno i
test di accettazione previsti (Implementation eXtra Information for Testing, IXIT)
106
Market / Sales (7)
Market Strategy & Plan
Marketing Campaign
Market Segment
Contact / Lead / Prospect
Competitor
Sales Statistic
Sales Channel
2. Product (6)
Strategic Product
Portfolio Plan
Product
Product Specification
Product Performance
Product Offering
Product Usage Statistic
3. Customer (10)
Customer
Customer Order
Customer Interaction
Customer Statistic
Customer Problem
Applied Customer
Billing Rate
Customer SLA
Customer Bill
Customer Bill Collection
Customer Bill Inquiry
4. Service (9)
Service
Service Applications
Service Specification
Service Configuration
Service Performance
Service Strategy & Plan
Service Usage
Service Trouble
Resource Performance
Resource Strategy & Plan
Service Test
5. Resource (9)
Resource
Resource Topology
Resource Specification
Resource Configuration
Resource Usage
Resource Trouble
Resource Test
6. Supplier / Partner (12)
Supplier/Partner
S/P Plan
7. Enterprise
Under
S/P Interaction
S/P Product
S/P Order
S/P SLA
S/P Performance
S/P Bill
S/P Problem
S/P Bill Inquiry
S/P Statistics
S/P Payment
8. Common Business (5)
Party
Business Interaction
Construction
Location
Policy
107
Agreement
Tavola P2.1 Modello informativo SID del TMF/ITU-T. Entità di livello 1 in raggruppamenti di livello zero
1.1.4 Valenza economica della gestione
Anche se poco rappresentativo dello stato delle relazioni fra imprese TLC nell’anno
2008, per scopi didattici noi assumiamo uno scenario gestionale bilaterale molto semplificato.
Lo scenario è il seguente: la gestione di sistemi e servizi TLC viene effettuata, da un lato, da
una impresa TelCo (comprensiva di un Fornitore di Servizi SP che gestisce i servizi TLC e un
Operatore di Rete NO che gestisce le reti abilitanti i servizi TLC ed eroga “servizi di rete”) e,
dall’altro lato, da una comunità di Utenti finali. Nel caso di Utenze Business partecipano alla
gestione anche unità organizzative ISM (Information System Manager) che gestiscono le
tecnologie ICT interne alle singole Utenze (e.g. gestione del Customer Premise Equipment).
Una TelCo trasforma la erogazione/gestione di servizi TLC a una comunità di Utenti
finali in una attività commerciale “orientata al Cliente” (“customer oriented business”) tesa
al raggiungimento di certi “obiettivi di business” (“business objectives”) con un certo profitto e
in maniera sostenibile (i.e. nel rispetto dei dettami di una Responsabilità Socilae di Impresa).
Quindi gli obiettivi della gestione di sistemi e servizi TLC (TLC System and Service
Management Goals) sono anche obiettivi di business per la TelCo. In queste condizioni, poiché
le risorse disponibili a una TelCo sono sempre limitate, le attività di fornitura/erogazione dei
servizi TLC e di acquisizione/utilizzo delle relative tecnologie ICT di supporto devono
soddisfare criteri di economia cioè devono essere effettuate in maniera efficace/efficiente i.e.
con massimo soddisfacimento delle necessità/aspettative degli Utenti (maximum quality to the
Customer) e con minimizzazione dei costi affrontati dalla TelCo (maximum operational
productivity). Questo richiede che la TelCo effettui la Gestione TLC in maniera
efficace/efficiente tramite opportune “Reti di Gestione” (sistemi informatici gestionali costituiti
da Sistemi di Supporto interconnessi da reti dati gestionali) e che queste ultime siano gestite
esse stesse in maniera efficace/efficiente (gestione del secondo ordine).
1.1.4.1
Misura dell’ “Efficacia/Efficienza” con cui una TelCo gestisce il suo business
Come si misura la efficacia/efficienza con cui una TelCo produce, eroga e gestisce
servizi TLC? Un metodo per misurare l’ “efficacia” con cui una TelCo produce, eroga e
gestisce servizi TLC è quello di verificare come essa riesca a soddisfare le necessità/aspettative
dei Clienti (verifica del livello di “quality to the customer”) i.e. sia capace di fornire “servizi
TLC giusti, al tempo giusto, nel luogo giusto, al prezzo giusto” mentre un metodo per
misurarne l’ “efficienza” è quello di verificare che la TelCo impieghi le sue risorse riducendo
gli sprechi (risorse fisiche, logiche o umane disponibili ma inutilizzate), le duplicazioni (unità
organizzative che eseguono gli stessi compiti) e gli eventuali tempi morti nella esecuzione dei
processi aziendali (verifica del livello di “operational productivity”) (e.g. vedi Fig. A.6.2
nell’Appendice 6 al Capitolo 1).
Una TelCo deve soddisfare queste esigenze continuamente per tutta la durata del ciclo
di vita di ogni servizio TLC i.e. dal suo concepimento (analisi delle opportunità di mercato)
attraverso il suo lancio commerciale fino alla sua dismissione e in maniera sostenibile in
presenza di cambiamenti di varia natura e.g. mercati, condizioni socio-economiche e politiche
variabili, innovazione tecnologica, sfide competitive etc.
108
L’ ITU-T nella Raccomandazione M.3200, facendo riferimento alla GST
in una TelCo, dice: “Da un punto di vista Business, l’obiettivo della
gestione TLC è il miglioramento continuo della qualità di servizio
erogata al cliente (NdR: efficacia) e della produttività operazionale (NdR:
efficienza)” laddove per “produttività operazionale” qui si intende il
valore economico delle prestazioni del sistema TLC rapportato al suo
costo totale i.e. costo di acquisizione + esercizio (Vedi G.Iazeolla,
“Impianti Reti Sistemi Informatici”, Franco Angeli, 2004, p. 23). La
Raccomandazione M.3200 continua affermando che: “Una misura del
“miglioramento continuo” può effettuarsi verificando che:
ii)
La risposta alla domanda di servizi TLC sia più rapida
iii)
L’eliminazione delle cause alla base della diminuzione di
produttività sia più rapida
iv)
La accuratezza delle fatture migliora e i tempi di ricezione siano
più brevi.
Tavola 1.1.4.1
Infatti, ripetiamo ancora una volta, l’obiettivo strategico (di lungo termine) che una
impresa commerciale come la TelCo si prefigge di raggiungere è una certa performance
economica sostenibile nel tempo cioè mirata al conseguimento di profitti in maniera
eticamente e socialmente responsabile pur in presenza di condizioni PESTER mutevoli.
“Performance sostenibile “ significa che la TelCo vende certi servizi TLC in certi mercati
producendo ricavi superiori ai costi di esercizio e di acquisizione delle risorse (i.e. con
“profitto”) e al tempo stesso implementa diligentemente politiche di Responsabilità Sociale di
Impresa (vedi dopo).
Come già detto, questo in pratica può richiedere da parte della TelCo modifiche di varia
natura alla conduzione del business e.g. modifiche graduali e progressive di “continuo
miglioramento” (“continual improvement”) o modifiche di riprogettazione dei processi
gestionali (“business process re-design”) o modifiche molto drastiche di “reingegnerizzazione
dei processi di business (“business process re-engineering”).
NOTA 1.1.4..1 Per il “Business Process Re-engineering” vedere anche: C.Batini et al. “Sistemi Informativi.
Volume 1, Organizzazione e reingegnerizzazione” Franco Angeli, 2001. G.Bruno, “Ideare e progettare
l’operatività nelle telecomunicazioni”, CSELT, 2000, pag. 67. Vedi anche par.4.6.2 nel Capitolo 4
Il “miglioramento continuo” è finalizzato a conseguire a livello operativo una serie di
obiettivi fra cui quelli che forniscono maggior valore aggiunto sia alla TelCo che al Cliente
sono (vedi anche Tavola 1.1.2.1) 1. risposte più rapide alle domande dei clienti 2. eliminazione
delle cause di riduzione di produttività, 3. fatturazione più accurata e addebiti più veloci
Il conseguimento di ciascuno di questi obiettivi richiede da parte di una TelCo
l’approntamento/esecuzione di flussi di processi operativi che coinvolgono la gestione di
risorse-servizi-clienti ( “flussi operativi end-to-end”, cioè flussi di processi che abbracciano
tutto l’arco cliente-risorse di rete attraversando domini gestionali di natura diversa, vedi
par.1.4.4).
109
SERVIZIO TLC
FUNZIONALITA’/
FUNZIONE
GESTIONALE
+
FUNZIONALITA’/
FUNZIONE
U&S
SISTEMA
INFORMATICO
GESTIONALE
TECNOLOGIE U&S
OSS/BSS
Tecnologie
ISM
“Gestore del
Gestore”
NSS
Reti TLC
OS
El.Rete
Parte Gestionale
Parte Gestita
SISTEMA TLC
Fig.1.2.1.1 La gestione di sistemi e servizi TLC all’interno di una TelCo.
OSS/BSS (Operations/Business Support Systems), NSS (Network Support
Systems) e OS (Operations Systems) sono tecnologie gestionali. La parte
gestita U&S (rettangolo rosa) assume caratteristiche specifiche per specifici
scenari di servizio e tecnologici. Invece la parte gestionale (rettangolo giallo)
può essere modellata ad un livello di astrazione sufficientemente alto
(processo di generalizzazione) da reare “modelli gestionali generici” i.e.
validi per diversi scenari di servizio o tecnologie fornite da vendors
diversi. ISM, Information System Manager, è il “Gestore della rete
informatica di gestione” interno alla TelCo e implementa la gestione del
secondo ordine, parte del sistema TLC. I sistemi OS possono avere interfacce
proprietarie mentre i sistemi di supporto sono realizzati con tecnologie DOC
(Distributed Object Computing) standardizzate .
110
etom1
1.2
“Separazioni” nella rappresentazione/specifica
di sistemi e servizi TLC
1.2.1
Le risposte a sei domande fondamentali
Inizialmente abbiamo riconosciuto che un sistema TLC reale è rappresentabile come una
“medaglia” a due facce, una parte gestore e una parte gestita, e che quest’ultima è necessaria
per rendere efficace/efficiente il funzionamento complessivo del sistema. Questa separazione,
fatta sulla base del format e scopo dell’informazione trasmessa/elaborata/ immagazzinata, è
generalmente facile per i sistemi TLC (specialmente quando le tecnologie implementative delle
due parti sono nettamente diverse e.g. tecnologie ICT analogiche per la parte gestita e
tecnologie ICT digitali per la parte gestore) ma è generalmente difficile per i servizi TLC.
Come si definisce la gestione di un servizio TLC e quale è la differenza fra servizio e gestione
di servizio? Quello su cui tutti siamo d’accordo è che un servizio TLC reale è costituito da una
aggregazione temporale di funzionalità/funzioni tutte ugualmente importanti e indispensabili,
condivise da SP (Service Provider) e Utente, e svolte per soddisfare i desideri/bisogni di
quest’ultimo. Come si fa a stabilire quali sono le funzionalità/funzioni “gestionali” e quali sono
“gestite”? Chi decide? Se si prendono più decisioni diverse quale decisione deve essere
accettata?
ESEMPIO. Separazione “parte gestore –parte gestita” in un sistema reale.
Anche in un sistema meccanico può essere difficile riconoscere parti “gestore” e “gestita” se non esiste una netta
distinzione fra le relative tecnologie implementative. Ad esempio se si vuole, si può rappresentare/specificare
una automobile come un insieme di caratteristiche classificate in due raggruppamenti denominati “parte
essenziale” e “parte gestore”: una parte “essenziale” (motore, ruote, chassis) la quale è gestita da una parte
“gestore” (freno, acceleratore, marce, sterzo). Tuttavia, tutti dobbiamo riconoscere che in effetti una automobile è
un sistema meccanico unico costituito da componenti, tutti ugualmente importanti e indispensabili, i quali sono
mutuamente accoppiati e cooperanti al fine di renderne il funzionamento complessivo efficace/efficiente (i.e. a
costo minimo e con massima soddisfazine dell’automobilista).
•
Raffinamento dell’ “Ipotesi di Lavoro 1.1.1”
Abbiamo iniziato il paragrafo 1.1.1 con la “Ipotesi di Lavoro 1.1.1.1” che diceva
1) “gestire un sistema TLC” significa svolgere tutte le funzioni necessarie a garantire che
esso sia sviluppato e funzioni come preliminarmente specificato
in maniera
efficace/efficiente i.e. a costo minimo e soddisfazione massima per l’utilizzatore
2) “gestire un servizio TLC” significa svolgere tutte le funzioni necessarie a garantire che un
servizio TLC sia sviluppato e fornito come preliminarmente specificato in maniera
efficace/efficiente i.e. costo minimo e soddisfazione massima per l’Utente.
Ora vogliamo riformulare questa “Ipotesi di lavoro 1.1.1.1” in dichiarazioni e domande:
111
DICHIARAZIONI
1) Ogni sistema TLC è una infrastruttura fisico-logico-energetica abilitante i servizi TLC
nella quale si riconoscono due parti inseparabili e interdipendenti: una “parte gestita” che
tende a funzionare a specifica e al massino livello di efficacia/efficienza grazie all’ ausilio e in
cooperazione con una “parte gestionale” (la parte rimanente del sistema TLC). Questo
concetto si può incapsulare nella frase ad effetto: “La gestione di un sistema TLC è nel sistema
TLC”
2) Ogni servizio TLC è una aggregazione temporale (fasi del “ciclo di vita”) di
funzionalità/funzioni sviluppate/possedute e svolte da TelCo e Utenti, atte a soddisfare i
desideri/bisogni di quest’ultimi, costituita da due parti inseparabili e interdipendenti: una
“parte gestita” svolta durante la fase “accesso/erogazione/fruizione” e una “parte gestionale”
svolta nelle altre fasi. Il concetto si può incapsulare nella frase ad effetto: “La gestione di un
servizio TLC è nel servizio TLC” (Il segno + in Fig.1.2.1.1 significa “aggregazione”)
3) Il principale gestore responsabile della gestione di reti e servizi TLC è una impresa
TelCo. Tuttavia la gestione dell’equipaggiamento CPE all’interno delle Utenze (e.g. terminali)
cade sotto la responsabilità dell’ Utente, nel ruolo di ISM (Information System Manager).
Inoltre l’Utente, nel ruolo di Cliente, collabora con la TelCo per la gestione dei servizi TLC.
DOMANDE
1. Si è parlato di sistemi e servizi TLC reali come entità unitarie e indivisibile e loro
rappresentazioni/specifiche suddivise in due “parti inseparabili e interdipendenti”. Quali
sono i criteri necessari e sufficienti a identificare queste due parti e quali sono le loro mutue
relazioni? In pratica quali sono i criteri di separazione e interazione fra parte gestita e parte
gestore? Quale è l’ utilità pratica di questa separazione? (Vedi par.1.2.2. e 1.2.3)
2. E’ possibile trovare un criterio di separazione valido per tutti i servizi TLC oppure, caso
per caso, si devono stabilire criteri diversi per i diversi servizi TLC o per gruppi di servizi TLC?
(Problema della creazione di modelli gestionali “generici” e della scelta del livello di
“genericità” o, meglio, “livello di astrazione”. Vedi par.1.2.7)
3. Potrebbe ogni operatore TLC fare di testa sua e adottare i criteri gestionali che ritiene più
opportuni o si deve affidare a enti ad hoc preposti alla standardizzatione della gestione?
(Separazione “gestione proprietaria - gestione standardizzata”. Vedi par. 1.2.6.3,4)
4. Su che base enti regionali, nazionali o internazionali stabiliscono una normativa
standardizzata e su che base gli operatori TLC devono accettare le loro scelte? (Problema della
“guerra degli standards” e della popolarità degli standards)
5. La parte gestore ha a sua volta bisogno di un gestore? (Problema del “Guardian’s
Guardian” o delle gestione del secondo ordine. Vedi par.1.2.6.2)
6. Se, come in effetti accade all’interno di una TelCo, i compiti gestionali non possono
essere completamente assolti da tecnologie (gestione automatizzata) ed è necessario un
112
contributo umano (gestione manuale) cioè se si è in presenza di una gestione mista effettuata
congiuntamente da uomini e macchine, è possibile e che significato ha studiare separatamente
i due tipi di gestione? (Separazione “gestione automatizzata- gestione manuale”. Vedi
par.1.2.6.2)
1.2.2
•
La separazione “Servizi TLC - Gestione servizi TLC”
Funzionalità e funzioni TLC
Per trovare una risposta a queste domande dobbiamo vivisezionare un sistema o servizio
TLC, riconoscerne gli elementi costitutivi e stabilire “chi-fa-che-cosa”. In questo ci aiutano
molto i concetti di “funzionalità” e “funzione” introdotti all’inizio del corso. Infatti, nel
par.1.0.3.1 abbiamo già definito un “servizio TLC” come aggregazione nel tempo di
funzionalità/funzioni TLC mentre per un sistema TLC si è parlato di “componenti tecnologici”
che “posseggono funzionalità” e “svolgono funzioni” (vedi tavola 1.0.2.1)
Vediamo prima i servizi TLC. Abbiamo visto che un servizio TLC ha un suo “ciclo di
vita” suddiviso in “Product Development” e “Service Delivery”. Facciamo riferimento a un
servizio TLC in fase di “Service Delivery” (vedi Fig.1.3.1.2) cioè consideriamo un servizio
TLC dopo il suo lancio commerciale i.e. dal momento in cui esso comincia ad essere offerto al
pubblico. Inoltre cominciamo introducendo concetti il più possibile elementari… ….quindi
operando a livelli di astrazione elevati (ricordate i concetti socratici del par.1.1.1?) In queste
condizioni diciamo che:
DEFINIZIONE 1.2.1.1 La gestione di un servizio TLC è lo svolgimento di un insieme
coerente di funzioni gestionali opportunamente definite da un gestore o da un ente ad
hoc riconosciuto dal gestore. Nel ciclo di vita di un servizio TLC essa si accompagna
allo svolgimento di funzioni di Utilizzazione che costituisce la erogazione/fruizione
dell’ “essenza del servizio TLC” (“TLC service core”) e allo svolgimento di funzioni di
Segnalazione che costituisce l’ “accesso al servizio TLC” (“TLC Service Access”).
•
Natura e scopo dei flussi di informazione nello svolgimento delle funzioni TLC
Ma quali sono i criteri in base ai quali le funzioni svolte nel corso di un servizio TLC
vengono separate in funzioni gestionali, funzioni di Utilizzazione e funzioni di Segnalazione
(criteri di separazione)?
Stabiliamo che la separazione fra questi tre tipi di funzioni sia fatta in base al format (e.g.
protocolli comunicativi) e scopo dei flussi di informazione coinvolti nello svolgimento delle
funzioni stesse. Allora noi diciamo che una funzione di Utilizzazione è una funzione TLC il cui
svolgimento implica flussi informativi di Utilizzazione all’interno del sistema TLC, una
funzione di Segnalazione è una funzione TLC il cui svolgimento implica flussi informativi di
Segnalazione all’interno del sistema TLC e, infine, una funzione gestionale è una funzione TLC
il cui svolgimento implica flussi informativi di natura gestionale all’interno del sistema TLC.
Quindi la precedente domanda si sposta nella domanda seguente: quale criterio si deve
adottare per stabilire la natura dei flussi di informazione in un sistema TLC?
113
Nel prossimo paragrafo, spiegheremo meglio quali sono i criteri di distinzione fra flussi
informativi gestionali, di Utilizzazione e di Segnalazione nei più comuni servizi TLC.
Tuttavia un esempio può aiutare a chiarire subito il concetto.
Una conversazione telefonica avviene tramite flussi informativi scambiati fra utenti
corrispondenti. Questa è l’ “essenza” del servizio di telefonia cioè un servizio telefonico è
stato creato prorio per questo scopo specifico, tutto il resto gioca un ruolo ausiliario.
Questi flussi sono denominati “flussi informativi di Utilizzazione (Usage)”.
I flussi informativi associati alla digitazione sulla tastiera del telefono di un numero
telefonico sono preliminari e propedeutici ai flussi di Utilizzazione e sono denominati “flussi
informativi di Segnalazione (Signaling)”.
Una telefonata da parte di un Cliente a un Call Center per notificare e far correggere un
errore in una bolletta telefonica serve a soddisfare le esigenze del Cliente e a migliorare la
qualità del servizio cioè a rendere il servizio telefonico più “efficace”. I flussi informativi
relativi a questa telefonata sono considerati di natura ancillare rispetto ai precedenti flussi e
sono denominati “flussi informativi gestionali” (Management).
Uno studio molto più dettagliato sull’ argomento verrà effettuato a più riprese durante tutto
il corso delle lezioni (vedi Capitoli 2 e 4). Chi è impaziente può saltare subito al par. 1.2.2 e alla
Fig.1.2.2.1! Per il momento è sufficiente riconoscere che:
1) in un servizio TLC i tre tipi di funzioni summenzionati sono distinguibili non solo perché
sono svolti per scopi diversi ma anche perché durante il ciclo di vita del servizio essi sono
svolti in tempi diversi (i.e. in “fasi” diverse del ciclo di vita) talvolta da persone diverse (e.g.
in una Utenza affari o governativa la telefonata al Call Center per segnalare un guasto la fa il
Cliente cioè l’ Ufficio amministrativo e non l’Utilizzatore) e talvolta con format diversi cioè
protocolli comunicativi diversi (protocolli di signaling diversi da quelli di utilizzazione). Infine
tra poco mostreremo (vedi Fig.1.2.2.1) che, a differenza delle altre funzioni, le funzioni di
utilizzazione sono specifiche di un particolare tipi di servizio e.g. in un “servizio di telefonia
vocale” la funzione di utilizzazione specifica è uno “scambio interattivo in tempo reale di
segnali vocali”, in un servizio TV la funzione di utilizzazione è l’osservazione di un programma
TV etc..
2) tuttavia tutte queste funzioni fanno parte di uno stesso servizio TLC e sono necessarie
perché esso sia erogato/fruito in maniera efficace/efficiente secondo criteri di razionalità
economica.
114
Riportiamo qui di seguito alcune considerazioni relative ai
servizi TLC pubblicate dal consorzio industriale TINA-C
(Telecommunications Information Networking Architecture
- Consortium) nel rapporto: TINA: “Overall Concepts and
Principles of TINA” Version 1, 17/02/1995. “When a
service is placed into a network a number of considerations
must be made with respect to functionality and to what
data/information is required. It is important that all aspects
of a service are incorporated into a design and deployed at
the same time. Four areas should be covered: access to the
service, the service core (service logic), management of the
service and the resources (and their management) required
to run the service.” Le quattro aree a cui qui si fa
riferimento corrispondono alla nostra “segnalazione”,
“utilizzazione”, “gestione” e “sistemi TLC” (infrastruttura
costituita da reti TLC e terminali). Noi poi abbiamo
aggregato
“segnalazione” e “utilizzazione” nella parte
gestita (U&S) del servizio. Il modello generico di servizo
adottato da TINA è stato originariamente sviluppato nel
1992 nel progetto ROSA (“RACE Open Service
Architecture” dove RACE, “R&D for the Advancement
of Communications in Europe” è una iniziativa del
Consiglio d’Europa) sponsorizzato dall’IBM (Vedi:
A.Oshisanwo et al. “The RACE Open System
Architecture Project”, IBM System Journal, vol.91. no.4.
pp. 691-710, 1992)
Non tutte le quattro aree considerate sono ugualmente
rilevanti agli stakeholders che partecipano a un servizio
TLC. Ad esempio un Cliente e un SP (Service Provider)
sono coinvolti in attività di gestione ma non nelle attività
U&S svolte dagli Utilizzatori e dal NO (Network Operator).
Tavola 1.2.1.1
115
Per un Utente, la acquisizione di un servizio di [….] significa acquisire la funzionalità di
effettuare
ottenere
fruire di assistenza in
Conversazione
telefonica
Collegamento
internet
Videoconferenza
Collegamento LAN
Scambio di SMS
etc.
Programmi radio
Programmi TV
Video-on-demand
Pay-per-view
Newsletters-on-line
etc.
Tele-medicina
Tele-educazione
Tele-consulenza
Tele-lavoro
etc.
con altri utenti dello
stesso servizio
funzionalità tecnologicamente neutra
attuata su richiesta
Funzionalità di segnalazione
Funzionalità di gestione (FCAPS)
nel momento del bisogno dietro
pagamento e alle condizioni/qualità/
prezzi specificati in un contratto SLA
stipulato col SP
Configurazione
Prestazioni
Guasti
Fatturazione
Sicurezza
Tavola PdS
Fig.1.2.2.1 Un servizio TLC comprende funzionalità di utilizzazione (rettangoli gialli) specifiche
del servizio stesso (“essenza del servizio”), funzionalità di segnalazione (rettangolo rosa) e funzionalità di
gestione (rettangolo mattone). La presenza delle funzionalità di gestione garantisce
la
erogazione/fruizione di un servizio TLC in maniera efficace/efficiente (dal lancio commerciale alla
cessazione del servizio). Molti servizi TLC diversi richiedono le stesse funzionalità di gestione cioè
hanno caratteristiche gestionali comuni. Ciò permette di creare “modelli gestionali generici” indipendenti
dal particolare scenario di servizio generalizzando modelli gestionali specifici sviluppati per i singoli
servizi (la generalizzazione si realizza ritenendo solo le caratteristiche condivise dai vari modelli
specifici). Le ultime tecniche computazionali rese disponibili dai progressi fatti nel campo del sofware
engineering permettono poi, se così si vuole, di effettuare il processo inverso: specializzare i modelli
generici in modelli specifici. La figura riporta il modello funzionale generico FCAPS dell’ITU-T. Il
termine “funzionalità” significa “capacità conoscitiva/abilità fisica di svolgere una funzione” laddove una
“funzione” è un “insieme coerente di attività svolte per il raggiungimento di uno scopo comune
predeterminato”
116
•
Modelli servizi integrati
La definizione 1.2.1.1 di gestione di un servizio TLC da noi proposta è molto
semplice ma non banale. Essa si ispira a principi/concetti introdotti in molti modelli servizi
TLC, cosidetti “modelli integrati”, che hanno cominciato a svilupparsi dall’inizio degli anni
90. Prominenti fra tutti sono i modelli messi a punto presso l’ Università di Monaco in
Germania dal gruppo di lavoro MNM, Munich Network Management, agli inizi del 2000 (vedi
la seguente NOTA BIBLIOGRAFICA e par.4.5.1 nel Cap.4) e nell’ambito dell’iniziativa
Europea RACE, “R&D for the Advancement of Communications in Europe” a cominciare dal
1992 (vedi anche Tavola 1.0.3.2)
NOTA BIBLIOGRAFICA relativa al modello MNM (Munich Network Management)
1) M.Garschhammer et al., “Towards Generic Service Management Concepts. A Service Model
Based Approach” Proceedings of 7-th International Symp. on Integrated Management (IM2001)
Seattle, Wa.,USA,May 2001, IEEE Publishing.
2) M.Garshhammer et a., “The MNM Service Model-Refined Views on Generic Service
Management”, Journal of Communications & Networks, 3(4),Dec.2001
3) M.Garshhammer et al. “ A case driven Methodology for Applying the MNM Model”,
Proceedings of of the 2002 8-th International Symp. on Network Operations and Management,
Florence, Italy, April 2002, IEEE Publishing
•
“Conglobamento U&S”: la convenzione di conglobare “funzioni di Utilizzazione” e
“funzioni di Segnalazione” in “funzioni U&S” (“parte gestita” di un servizio TLC)
Nella Definizione 1.2.1.1 si parla separatamente di funzioni gestionali, funzioni di
Utilizzazione e funzioni di Segnalazione. Tuttavia in un corso di GST come il nostro noi
riteniamo sia opportuno introdurre la convenzione di conglobare le funzionalità/funzioni di
Utilizzazione con la funzionalità/funzioni di Segnalazione in un unico tipo di
funzionalità/funzioni denominato funzionalità/funzioni U&S (i.e. Utilizzazione &
Segnalazione) che costituisce la “parte gestita” di un servizio TLC.
In tal modo nel ciclo di vita di un servizio TLC si riconoscono due parti distinte e
separate: una parte gestita (funzionalità/funzioni U&S) durante la fase di
accesso/erogazione/fruizione del servizio e una parte gestore costituita da funzionalità/funzioni
gestionali svolte durante le rimanenti fasi del ciclo di vita. Questo schema classificativo,
basato sul ciclo di vita di un servizio TLC, ci permette di stabilire facilmente, seppur in
maniera convenzionale, cosa sia “gestione di un servizio TLC” e quale sia la sua relazione
con un “servizio TLC”.
Ci sono varie ragioni che giustificano la scelta del “conglobamento U&S”. A differenza
delle funzioni gestionali, le funzioni di Segnalazione (o di “Accesso”) sono strettamente
relazionate alle funzioni di Utilizzazione. Infatti esse sono propedeutiche e preliminari
rispetto alle funzioni di Utilizzazione e il loro svolgimento avviene durante una “sessione di
accesso” (“access session”) che immediatamente precede la “sessione di fruizione” (“usage
session”) di un servizio TLC. Le sessioni di accesso e di fruizione, seppur si susseguano in
117
tempi diversi e siano di natura diversa (e.g. protocolli comunicativi e tecnologie di rete diverse)
sono entrambe iniziate dallo stesso Utilizzatore. Le funzioni di Segnalazione svolte durante la
fase di accesso stabiliscono un contesto amministrativo e circuitale necessario per realizzare la
susseguente fase di fruizione (propedeuticità della prima rispetto alla seconda). Infatti durante
una sessione di accesso, dopo una richiesta di accesso in rete per una particolare istanza di
servizio da parte dell’Utilizzatore, la rete automaticamente effettua 1. la autenticazione
dell’Utilizzatore richiedente e 2. ne autorizza l’accesso per il particolare servizio richiesto, e 3.
se necessario (e.g. per “connection oriented services”) crea una connessione circuitale
(“sessione circuitale”, “circuit session”) fra terminali corrispondenti dotata di caratteristiche
comunicative appropriate alla classe di servizio a cui appartiene la istanza di servizio richiesta
e.g. larghezza di banda, tempo di ritardo e sue variazioni (jitter), tasso di errore (BER, Bit Error
Rate), probabilità di perdita di un pacchetto di dati etc.
Tuttavia, come già detto, la nostra scelta di adottare il conglobamento U&S nello studio
dei servizi TLC ha un carattere convenzionale (cioè è una convenzione da noi accettata) e
non è necessariamente condivisa da tutti gli studiosi di GST. Infatti al riguardo esistono diverse
scuole di pensiero.
Ad esempio taluni ritengono che le funzionalità di Segnalazione giochino anch’esse un
ruolo gestionale e quindi le conglobano con le funzioni gestionali specificando “funzioni di
Management & Control” separate dalle funzioni di Utilizzazione (vedi Capitolo 2). Altri, e.g.
il consorzio internazionale TINA-C (Telecommunications Information Network ArchitectureConsortium, vedi par.3.2.9) raccomandano di separare un servizio TLC in funzionalità di
Accesso e funzionalità di Utilizzazione e poi suddividere queste ultime in “funzionalità di
Utilizzazione Primarie” (service core o essenza del servizio) e “funzionalità di Utilizzazione
Ancillari” (funzionalità gestionali).
•
Le differenze fra funzionalità di Utilizzazione (specifiche) e funzionalità gestionali
(generiche) e la creazione di “modelli gestionali generici” (Fig.1.2.2.1)
A questo punto vogliamo evidenziare, anche graficamente, alcune differenze
fondamentali fra funzionalità/funzioni di Utilizzazione e funzionalità/funzioni gestionali. La
Fig.1.2.2.1 è un grafo orientato che mostra come le prime siano specifiche di un particolare
scenario di servizio TLC, cioè variano da tipo di servizio a tipo di servizio, mentre le seconde
possiedono caratteristiche comuni a una molteplicità di tipi di servizio diversi. Quindi le
seconde si prestano ad essere rappresentate con modelli gestionali validi per una molteplicità di
scenari di servizio TLC, (modelli gestionali generici, vedi par.1.2.7).
Il grafo di Fig.1.2.2.1 sarà analizzato in dettaglio nel Cap.4. Esso va letto partendo
dall’angolo “in alto a sinistra” e spostandosi poi progressivamente verso l’ angolo “in basso a
destra”. Lo svolgimento delle funzioni di Utilizzazione (rettangoli gialli) è l’ attuazione
(messa in atto) di corrispondenti funzionalità di utilizzazione e, se necessario, viene effettuato
dopo il soddisfacimento di una richiesta realizzata svolgendo funzioni di Segnalazione
(rettangolo rosa). Esso costituisce la erogazione/fruizione dell’ “essenza” di un servizio TLC
(“TLC service core” o “network service”, in Inglese) e, allo stesso tempo, il raggiungimento
dell’ obiettivo primario del servizio. Ad esempio la funzione di utilizzazione “scambio di SMS”
118
viene svolta per raggiungere l’ obiettivo primario “scambio di SMS”. Le funzioni di
Utilizzazione variano da tipo di servizio a tipo di servizio.
Lo svolgimento di funzioni gestionali (rettangolo color mattone) in una TelCo avviene,
come già visto, sotto forma di processi gestionali che sono anche processi finalizzati a
conseguire gli obiettivi di business della TelCo (processi di business). Molte di queste
funzionlità gestionali sono condivise dai vari scenari di servizio e sono definite in modelli
funzionali generici (indipendenti dal particolare scenario di servizio) e.g. promulgati da enti di
standardizzazione internazionali (ITU-T, ETSI) i quali possono poi essere specializzati ai vari
casi tramite aggiunta di caratteristiche specifiche dei singoli servizi.
1.2.3 La separazione “Sistema TLC - gestione di un sistema TLC”
Principi/concetti analoghi a quelli presentati sinora per i servizi TLC valgono anche per
i sistemi TLC e per le tecnologie ICT in essi contenute. Abbiamo visto che un sistema TLC è
una infrastruttura tecnologica abilitante i servizi TLC. Essa comprende reti TLC e Customer
Premise Equipment e.g. terminali e reti locali di terminali assieme ai relativi sistemi di gestione
interni all’Utenza. Limitandoci anche qui alla fase operativa diciamo che per gestione di un
sistema TLC si intende la supervisione, controllo e manutenzione delle tecnologie U&S
tramite l’impiego di altre tecnologie ICT di natura ancillare (tecnologie gestionali per la
gestione di reti e elementi di rete). Entrambe tecnologie fanno parte del sistema TLC. Le
tecnologie U&S sono le tecnologie necessarie per attuare le funzionalità U&S mentre le
tecnologie gestionali sono le tecnologie necessarie per attuare le funzionalità gestionali relative
alla gestione delle tecnologie U&S. Fra le tecnologie gestionali noi distinguiamo tecnologie
OS (Operations Systems) per la gestione degli elementi di rete e tecnologie NSS (Network
Support Systems) per la gestione end-to-end delle reti (cioè “da terminale a terminale”).
1.2.4
Sistema informatico gestionale (rete di Gestione) all’ interno di un
sistema TLC
Ad esempio, in un sistema telefonico gli autocommutatori, le linee di trasmissione di
interconnessione, i terminali telefonici sono tecnologie U&S, mentre sono tecnologie gestionali
gli OS attestati sui vari elementi di rete e i grossi elaboratori digitali NSS per la gestione end-toend delle reti.
ATTENZIONE. Per comodità didattica qui includiamo i sistemi di esercizio OS nei Sistemi di Supporto.
Ricordare che sono tecnologie diverse!
Ma OS e NSS non sono le uniche tecnologie gestionali in un sistema TLC. Fanno parte di
un sistema TLC anche altre tecnologie gestionali, quelle relative alla gestione dei servizi e delle
relazioni clienti! Come mostrato in Fig.1.2.4.2 oltre alle tecnologie OS e NSS fanno parte di un
sistema TLC anche le tecnologie Operations Support Systems, OSS, che abilitano lo
svolgimento della maggior parte delle funzioni gestionali relative ai servizi TLC e le
tecnologie BSS (Business Support Systems) che abilitano i processi di Customer Relation
Management (CRM) e di gestione delle relazioni con TelCo partners e ICTS suppliers (fornitori
di tecnologie).
119
La natura delle tecnologie OSS e BSS è simile a quella delle NSS ma con la differenza che
le loro applicazioni sono finalizzate alla gestione dei servizi TLC e alla gestione delle relazioni
con stakeholders esterni (vedi Fig.1.2.1.1). Entrambe le tecnologie NSS e OSS/BSS sono
Sistemi di Supporto gestionali ognuno con specifiche applicazioni gestionali. In particolare
sono denominati Sistemi di Supporto di Processo gli elaboratori digitali su cui girano pacchi
di software applicativo (applicativi). Essi scambiano dati gestionali con database (anche
denominati Sistemi di Supporto di Strato Dati) tramite reti di comunicazione dati
(Management Data Communication Networks). Inoltre sono collegati con postazioni di lavoro
dove risiedono gli addetti alla gestione che presidiano terminali gestionali. Gli applicativi
gestionali sono in generale contenuti in pacchi software a struttura modulare con moduli spesso
commercialmente disponibili (vedere i rettangoli in Fig.1.2.4.2). “Sviluppare un sistema di
supporto” significa sviluppare il relativo applicativo gestionale (e.g. vedi: G. Fantauzzi, “I
sistemi software per le reti e i servizi di telecomunicazione”, Franco Angeli, 2000).
NOTA 1.2.4.1 Non tutte le funzioni gestionali di servizi TLC sono automatizzate e supportate da OSS.
Particolarmente evidente è il caso delle funzioni di “Fatturazione” (Billing). Ad esempio in Italia la TelCo
invia ai Clienti le fatture per posta e i Clienti effettuano i pagamenti tramite contocorrente all’ufficio
postale. In tal caso il sistema postale funge da “infrastrutura tecnologica di supporto” e lo sportello
all’ufficio postale funge da “terminale di gestione”. Analoghe considerazioni valgono per i casi in cui reti
U&S sono utilizzate per scopi gestionali. Ad esempio, un Utente di servizi internet che telefona al call center
del Internet Service Provider utilizza la rete telefonica pubblica PSTN per scopi gestionali. In tal caso la rete
PSTN costituisce la “infrastruttura tecnologica di supporto” di una funzione gestionale (e.g. segnalazione di
un guasto o richiesta di informazioni) e il telefono è in questo caso un “terminale di gestione”.
120
SISTEMA TLC
OS
OS
TMN
OS
OS
OS
OS
RETE COMUNICAZIONE DATI
(DCN)
RETE DI TELECOMUNICAZIONE (U&S)
& TERMINALI
OS
SISTEMA d' ESERCIZIO
ELEMENTO DI RETE (NE)
Tavola
Fig.1.2.4.1 La gestione di un sistema TLC è nel sistema! (adattamento della corrispondente figura
pubblicata nella Raccomandazione M-3010 dell’ITU-T)
121
PROCESSI OPERATIVI (Modello e-TOM dell’ITU-T)
Customer Interface Management
CRM
BSS
1. CRM Op.
Support &
Process
Mngmt
2. CRM
Operations
Readiness
3. Sales & Channel
Management
1. Marketing
Fulfillment
Response
2. Order
Handling
1. Problem Handling
3. Selling
Retention & Loyalty
Service Management & Operations (SM&O)
1. SM&O Support
& Process Mngmt
OSS
2. SM&O Readiness
1.Service
Problem
Management
1. Service
Configuration
& Activation
OS
NSS
2. Resource Mngmt &
Operations
1.Resource Trouble
Mngmt
2. Resource
Perf. Mngmt.
1. Resource
Provisionig
Resource Data Collection & Processing
Supplier/Partner Relationship Mngmt
BSS
1. SPRM Oper. Support
& Process Mngmt
2. SPRM Operations
Readiness
Oper. Supp. & Readiness
1. Service &
Specific Instance
Rating
2. QoS Analysis.
Action & Reporting
Resource Management & Operations (RM&O)
1. RM&O Support &
Process Mngmt
1. Billing &
Collections
Management
2. Customer
QoS/SLA
Management
1. S/P Problem
Reporting & Mngmt
1. S/P
Requisition
Mngmt
2. S/P Performance
Mngmt
1. S/P
Settlements
& Billing Mngmt
. Supplier/Partner Interface Management
Fulfillment
Assurance
Billing
Fig.1.2.4.2 Processi gestionali al livello 2 del modello e-TOM del TMF e tipologie di sistemi di
supporto. Notare l’aggiunta del raggruppamento “Operations Support & Readiness” al modello classico
Fulfillment-Assurance-Billing (FAB). I processi in rettangoli gialli fanno parte del flusso operativo endto-end di Fig.1.4.3.4
NOTA 1.2.4.2 Attenzione alla terminologia! Spesso la terminologia NSS, OSS e BSS adottata per i
sistemi di supporto è ambigua e può indurre in errore. Ad esempio l’ ITU-T nei suoi documenti relativi allo
122
standard TMN non usa nessuno di questi termini ma usa solo il termine “OS”. Altri testi ignorano BSS e
usano solo NSS e OSS, mentre altri testi usano solo OSS. Nella stragrande maggioranza della letteratura
anglosassone 1) il termine NSS non è usato affatto, 2) il termine OSS viene usato per i processi operativi di
gestione reti, servizi e relazioni clienti. Per quanto riguarda i sistemi BSS la letteratura anglosassone offre
una pletora di significati diversi e.g. “processes that plan, develop and manage the delivery and
enhancement of infrastructures and services to the end-user”, Racc. ITU-T M.3050.0, 7/2004) oppure fanno
riferimento ai soli processi operativi di Customer Care oppure fanno riferimento ai sistemi di integrazione
degli OSS (e.g. workflow controller). Per quanto poi riguarda i sistemi d’esercizio OS (Operations Systems)
per la gestione degli elementi di rete, essi sono spesso considerati a parte in quanto costruiti con tecnologie
proprietarie e commercializzati da imprese ICTS come parte integrante degli stessi elementi di rete. Come
mostrato in Fig.1.2.4.2 noi indichiamo con NSS e OSS i sistemi abilitanti i “processi operativi interni”
rispettivamente relativi alla gestione di reti (network facing operations processes) e servizi TLC mentre i
sistemi BSS abilitano i “processi operativi esterni” di customer care (customer facing operations processes)
e di relazioni con TelCo partners e ICTS suppliers. Quindi nel nostro corso la Gestione integrata “retiservizi-customer care-partners/suppliers” in fase operayiva richiede una integrazione NSS/OSS/ BSS. (Nella
letteratura anglosassone si trova solo OSS/BSS o BOSS). Inoltre noi useremo la notazione BSS per i sistemi
di supporto dei processi di business non operativi (e.g. nel modello e-TOM di Fig. 1.0.3.3.1 “gestione di
impresa” e “gestione SIP”, Strategy-Infrastructure-Product)
1.2.5
Integrazione dei Sistemi di Supporto in un Sistema Informatico
Gestionale (“Rete di Gestione”)
In tempi recenti la tendenza è quella di creare all’interno di una TelCo sistemi
informatici gestionali con architetture software distribuite che integrano applicazioni NSS, OSS
e BSS su un unica piattaforma. Come già indicato, “Integrare” non significa progettare e
costruire il software di un sistema informatico come un blocco monolitico privo di interfacce
fra componenti bensì significa creare architetture software con componenti logicamente e
fisicamente separati ma interoperanti in maniera “seamless” attraverso interfacce esplicite
possibilmente standardizzate sotto il controllo di opportuni “workflow controllers” i.e.
controllori dei flussi di lavoro. Quindi quando si parla di “Integrazione” i termini chiave da
ricordare sono “application components” (cioè componenti applicativi o semplicemente
“applicativi”) “seamless interoperability” (cioè interoperabilità senza soluzioni di continuità)
e “workflow controllers” (cioè i controllori dei flussi operativi)
Per una TelCo che deve sviluppare un nuovo servizio TLC si tratta quindi di creare ab
initio (cioè a cominciare dalla fase di “Product Development”, vedi Fig.1.4.2) componenti
software “integrabili” in architetture “aperte” capaci di minimizzare le loro interdipendenze
senza tuttavia compromettere la loro integrabilità cioè la loro capacità di operare in maniera
“seamless” (e.g. al limite architetture “loosely coupled” con componenti “Plug & Play” cioè
componenti da installare nel sistema informatico e attivare subito senza necessità di adattamenti
ad hoc). Gli sforzi dell’ITU-T nello sviluppo degli standards TMN già a metà anni 90 erano
finalizzati proprio al conseguimento di questi obiettivi. Considerazioni analoghe valgono per le
più recenti iniziative di standardizzazione (e.g. iniziativa NGOSS del TeleManagement Forum
supportata da standards ITU-T) con tecnologie DOC (Distributed Object Computing).
Torneremo sull’argomento fra poco.
A questo punto possiamo mettere assieme le considerazioni fatte sin qui per servizi e
sistemi TLC e trarne un' unica conclusione: in un qualsiasi scenario di servizio TLC e relativo
sistema TLC abilitante si riconoscono una “parte gestionale” di natura ancillare costituita da
123
tecnologie e funzionalità/funzioni gestionali e una “parte gestita” di natura essenziale
costituita da tecnologie e funzionalità/funzioni U&S (Vedi Fig.1.2.11). La parte gestionale è
parte integrante del sistema o servizio TLC ed è decomposta in accordo con i vari tipi di
gestione locale e.g. reti, servizi e customer care.
A loro volta i vari tipi di gestione locale sono integrati in una “Gestione TLC” con la G
maiuscola, complessiva. Scopo della Gestione TLC è far sì che la fornitura dei servizi TLC,
nel suo complesso “parte gestionale + parte gestita”, avvenga con i livelli di efficacia/efficienza
prestabiliti e che la TelCo consegua certi obiettivi di business prefissati dal Senior Management
in fase di pianificazione strategica e, complessivamente, raggiunga una performance di impresa
soddisfacente e sostenibile nel tempo (i.e. rispettosa di una Responsabilità Sociale di Impresa)
anche in presenza di cambiamenti esterni dovuti alla dinamica dei mercati, alle condizioni
politico-socio-economiche e alla innovazione ICT.
1.2.6
Convenzionalità della gestione e dei modelli gestionali: enti di
standardizzazione
In base a queste considerazioni si vede fin da ora che noi definiamo la “gestione di un
servizio TLC” considerando il servizio nella sua integrità, fornito/acquisito come un insieme
coerente di funzionalità TLC (attuate al momento opportuno come insieme coerente di funzioni
o processi) e poi riconoscendo in esso due parti distinte: una parte essenziale (parte gestita)
costituita dall’insieme delle funzionalità U&S e una parte ancillare (parte gestionale)
costituita dall’insieme delle funzionaltà gestionali.
Stesse considerazioni valgono per i sistemi TLC. Con la differenza che ora gli elemnti
costitutivi del sistema non sono le funzionalità TLC bensì le tecnologie ICT. Questo approccio
unitario applicato sia a servizi che sistemi TLC cerca in qualche maniera di recuperare la
realtà dei fatti. Infatti la realtà dei fatti è che esistono “sistemi TLC gestiti” e “servizi TLC
gestiti”, entità organiche ognuna composta da una molteplicità di “elementi” (materiali o
immateriali i.e. tecnologie o funzionalità). Se poi qualcuno vuole soddisfare certe sue esigenze
e vuole classificare questi elementi come appartenenti a una parte gestita e ad una parte
gestionale esso può legittimamente farlo applicando a suo piacimento opportuni criteri di
classificazione o di normazione, ma non è detto che questi criteri siano poi universalmente
condivisi da tutti gli operatori del settore TLC. Ad esempio nelle relazioni di business crossaziendali fra più TelCo partner o fra ICTS e TelCo è importante che le imprese abbiano una
conoscenza condivisa delle singole funzionalità gestionali contenute in un certo servizio TLC e
poi, sulla base di questa, stabiliscano in maniera contrattualmente vincolante “chi fa che cosa”.
Vedere la Fig.1.1.1.7.2 che mostra la “spalmatura” dei processi operativi fra varie imprese
federate in una value network. Discorso analogo vale all’interno di una TelCo per il
personale dei dipartimenti “Sales & Marketing” (operatori commerciali responsabili della
gestione servizi) e “Network Operations” (operatori tecnici responsabili della erogazione dei
servizi e della gestione delle reti). Anche in questo caso è importante conoscere
funzionalità/processi gestionali per poter poi stabilire “chi fa che cosa”. L’importante è che le
parti interessate raggiungano un accordo e che poi esse rispettino quest’ accordo in fase
operazionale. La verità è che la definizione della parte gestionale ovvero la distinzione fra parte
essenziale e parte gestionale in un sistema TLC o in un servizio TLC complesso spesso è
124
immediata e netta (e.g. sistema TLC con tecnologie gestite e tecnologie gestionali di natura
nettamente diversa, come nel caso in cui le prime sono linee di trasmissione elettromagnetiche
mentre le seconde sono processori digitali) mentre talvolta è nebulosa e difficile da riconoscere
(e.g. servizi TLC multimediali multiparty con un numero variabile di partecipanti e intervento
di media e contenuti diversi nel corso di una stessa sessione).
In effetti si deve riconoscere che, specialmente per i servizi TLC, esiste una certa
convenzionalità e/o discrezionalità da parte di coloro che devono decidere, in maniera rigorosa,
quale sia la “parte gestionale” e quale sia la “parte gestita”. “Convenzionalità” significa che le
decisioni vengono prese di comune accodo da una molteplicità di rappresentanti delle parti
interessate e.g. operatori del settore TLC come TelCo, ICTS (i quali “convengono” di prendere
certe decisioni) mentre “Discrezionalità” significa che chi decide ha l’autorità di prendere
certe decisioni in completa autonomia e in base a certe sue valutazioni fatte al momento (i.e.
decisione presa in base alla situazione del momento, decisione “non-strutturata”).
1.2.6.1
•
Gerarchie gestionali: automazione e manualità
Gestione ISM del secondo ordine…..e del terzo?
Il tentativo di porre fine alla diatriba “cosa è gestione” e “cosa non è gestione” si
complica. Infatti la gestione di reti e servizi TLC è effettuata da risorse umane (personale
addetto ai processi gestionali) e da un sistema informatico gestionale (Rete di Gestione)
realizzato aggregando componenenti ICT e componenti ausiliari nonICT (gestione del primo
ordine). Supponiamo preliminarmente che questo primo livello di gestione sia in ogni caso
altamente automatizzato (“molte macchine e pochi uomini”) in maniera da poter ignorare la
gestione manuale e poi occupiamoci della sua parte ICT. Si tratta di un sistema informatico
complesso realizzato integrando componenti OS, NSS, OSS, BSS. Questo sistema informatico
fa parte del grande sistema TLC abilitante i servizi TLC. All’interno di una TelCo esso è a sua
volta gestito (gestione del secondo ordine) da risorse umane e sistemi gestionali ISM
(Information System Management, vedi Fig. 1.2.1.1). Cioè come si dice in Inglese esiste un
“guardian’s guardian” i.e. “un guardiano del secondo ordine controlla un guardiano del primo
ordine”. Ma allora le risorse umane e il sistema informatico ISM dedicati alla gestione del
secondo ordine fanno parte anch’essi del sistema TLC o no? Noi in accordo al TMF diciamo
che il sistema informatico ISM fa parte del sistema TLC ma certamente tutto ciò sembra
avere profumo di “convenzione” cioè “è gestione quello che tutti noi d’accordo con gli enti di
standardizzazione, cioè convenzionalmente, decidiamo essere gestione”
Ma non è finita! Il sistema ISM ha una complessità tecnologica tale da giustificare una
ulteriore gestione del terzo ordine? Se sì, è la gestione del terzo ordine automatizzata cioè
esiste un sistema informatico gestionale del terzp rodine o si tratta solo di gestione manuale? Se
esiste un sistema informatico gestionale del terzo ordine fa anch’ esso parte del sistema TLC?
•
E la gestione manuale?
problematiche.
“None of our business”! Solo consapevolezza delle
125
E’ indubbio che la stretta collaborazione uomo-macchina necessaria nei processi di
gestione crea dei problemi allorchè si cerca di definire e valutare il sistema gestionale solo su
base tecnologica. Infatti dobbiamo riconoscere che certi processi gestionali non sono
automatizzabili o, perlomeno non sono completamente automatizzabili, e.g. attività di
pianificazione e marketing, attività di progettazione, installazione di servizi TLC, riparazioni in
the fields, personale nei call centers etc, Tuttavia è anche vero che in presenza di risorse umane
nei processi gestionali il problema di “chi fa che cosa” e della qualità con cui quel “qualcosa”
viene fatto diventa un problema di “gestione del personale” che esula dai nostri interessi. E
questo è particolarmente vero man mano che si sale verso livelli gerarchici più elevati
all’interno di una TelCo. Ad esempio si può visualizzare una gestione del personale addetto
alla gestione di sistemi e servizi TLC strutturata gerarchicamente a piramide con livelli
successivi di supervisori e managers con responsabilità e autorità crescente e numerosità
decrescente man mano che ci si avvicina al vertice della piramide organizzativa dove risiede
probabilmente un Information Systems Manager (o addirittura un Chief Information Officer,
CIO, a livello di vice-presidente) (vedi R.Saracco, “La gestione della rete TLC”, CSELT, 1993,
pag. 273 e C.Batini et al. “Sistemi Informativi”, Volume 1, “Organizzazione e
Reingegnerizzazione”, Franco Angeli, 2001, p.25).).
In definitiva diciamo che noi in questo corso ignoreremo la componente manuale della
gestione di sistemi e servizi TLC ma che tuttavia abbiamo la consapevolezza dell’esistenza di
numerose problematiche che rappresentiamo qui di seguito sotto forma di domande
1) Noi abbiamo definito il sistema informatico gestionale come una tecnologia
(macchina) ma spesso esiste e opera congiuntamente con esso una gestione manuale (uomini);
allora quale è l’impatto della gestione manuale e della sua discrezionalità sui risultati finali
dell’attività gestionale?
2) Come si può tener conto della gestione manuale nella definizione di un sistema
gestionale e nella valutazione delle sue prestazioni? Le signorine che rispondono in un callcenter fanno parte del sistema gestionale e, se sì, quale è l’impatto del loro comportamento “on
the job” sulla performance del sistema?
3) Se la gestione manuale nella realtà dei fatti fa parte del sistema gestionale e la
gestione manuale è strutturata gerarchicamente, come in effetti spesso accade all’interno di una
TelCo, quanti sono i livelli gerarchici da prendere in considerazione?
Ovviamente le risposte variano da TelCo a TelCo (dimensioni di impresa, livello di
automazione, management span ai vari livelli etc.). Probabilmente per rispondere a queste
domande si devono effettuare dei “case studies”ma…….fortunatamente questo non fa parte
del nostro corso!
1.2.6.2
Enti di standardizzazione
Dove si trova una risposta a tutte queste domande? A parte la situazione ovvia in cui un
operatore TLC può gestire privatamente ciò che vuole come vuole, la risposta a queste
domande si trova riconoscendo che in pratica ci si deve rimettere ad una o più autorità esterne
126
competenti, credibili e ufficialmente riconosciute che, con la collaborazione dei maggiori
operatori TLC/ICT, possano decidere quali siano le funzionalità gestionali contenute in un
servizio TLC e quali siano le relative tecnologie gestionali abilitanti. Tutte queste informazioni
vengono raccolte nei “modelli gestionali” emanati dalle suddette autorità e vengono poi messi
a disposizione degli operatori del settore. Ogni autorità che propone un particolare modello
gestionale auspica che il suo modello venga poi adottato da un gran numero di operatori cioè
acquisti la massima popolarità…..cosa che non sempre avviene! (gli interessi industriali e
commerciali sono enormi! Vedi Cap.3). Il successo del consorzio internazionale
TeleManagement Forum in questo campo è proprio dovuto al fatto che esso conta centinaia di
membri i quali poi adottano le specifiche tecniche pubbliche che essi stessi hanno promosso
tramite propri rappresentanti.
. Quindi, come già indicato, quando si parla di “gestione” in effetti si parla di “modelli
gestionali” (architetturali e di processo) i quali come minimo specificano i contenuti informativi
(struttura dell’informazione e dei dati), le modalità di processo delle funzionalità gestionali e
relativi sistemi di supporto. “E’ “gestione” quello che i modelli gestionali condivisi e adottati
stabiliscono essere gestione”
ESEMPIO. Ci eravamo posti la domanda se la gestione del secondo ordine faceva parte della gestione di un
sistema TLC. Una risposta affermativa viene data dagli enti di standardizzazione: la gestione del secondo ordine
fa parte della gestione di sistemi e servizi TLC. Ad esempio la ITU-T nel modello TMN (Racc. M.3200 del
04/97) introduce un servizio gestionale di “Work Force Management” laddove la “Work Force” sono gli addetti
alla gestione del primo ordine. Inoltre fra le tecnologie da gestire introduce la TMN stessa (rete di gestione del
primo ordine).
1.2.6.3
Standards gestionali
Ora esistono più categorie di modelli gestionali: modelli proprietari o standardizzati
“de facto”, modelli standardizzati “de jure”, specifiche tecniche pubbliche (vedi Cap.3). I
primi sono formulati a completa discrezionalità del gestore e/o del costruttore di tecnologie
mentre i secondi, emessi da enti di standardizzazione nazionali o internazionali, specificano
rigorosamente quali siano le funzionalità e le tecnologie gestionali. Nel caso dei modelli
gestionali standardizzati tutti coloro che li adottano sanno esattamente cosa sia la “gestione” di
sistemi e servizi TLC. Ma c’è di più. La standardizzazione permette ad una impresa
manifatturiera (ICTS) di creare tecnologie gestionali “aperte” capaci di interoperare con
tecnologie prodotte da altre imprese ICTS (interoperabilità eterogenea) e questo può esser fatto
senza soffocare iniziative proprietarie di innovazione tecnologica (vedi Cap.3). In questo corso
noi ci occuperemo esclusivamente di modelli gestionali standardizzati “de jure” emessi da
enti internazionali di standardizzazione e.g. ITU-T, ETSI o di “specifiche tecniche
pubbliche” emesse da consorzi internazionali di grosse dimensioni e.g. TeleManagement
Forum.
1.2.7
Modelli standardizzati generici o specifici
Ma i modelli standardizzati possono anche essere classificati in altra maniera. Nei
modelli gestionali standardizzati “de jure” la suddivisione tecnologica o funzionale di un
sistema o servizio TLC in una “parte gestita” e una “parte gestionale” è definita formalmente e
127
ufficialmente da enti di standardizzazione le cui decisioni sono condivise da un gran numero
di imprese ICTS e TelCo (shared standards). Il processo di standardizzazione può generare
modelli gestionali specifici o generici. I modelli gestionali specifici sono creati per certe
tecnologie ICT (sistemi TLC o loro elementi) o certi scenari di servizio TLC di interesse pratico
da organizzazioni specializzate e.g. Internet Engineering Task Force, IETF per le reti/protocolli
internet.
Tuttavia le gestioni relative a sistemi o servizi TLC specifici, come già detto in 1.1.1,
spesso hanno in comune un certo numero di caratteristiche. Allora è possibile creare “modelli
gestionali generici per servizi TLC” e “modelli gestionali generici per sistemi TLC” che
ritengono solo queste caratteristiche comuni ignorando le caratteristiche specifiche non
condivise (processo “bottom-up” di creazione di modelli generici).
Quindi un modello gestionale generico definisce una gestione di servizi o sistemi TLC
indipendentemente dal particolare scenario di servizio o dal particolare tipo di tecnologia
ICT.abilitante (modelli gestionali multi-vendor e modelli technology neutral). In maniera più
rigorosa noi diremo che un possibile modo per ottenere un modello gestionale generico è quello
di effettuare un processo di astrazione (generalizzazione) operando su una molteplicità di
modelli gestionali specifici creati a priori. Diremo anche che un modello gestionale generico è
un modello ad un livello di astrazione più elevato rispetto al livello di astrazione dei singoli
modelli gestionali specifici da cui esso è stato derivato. Parleremo anche di processi di
specializzazione che operano in senso inverso ai processi di generalizzazione (i.e. in direzione
“top-down”): un modello gestionale specifico è la specializzazione tramite aggiunta di
caratteristiche specifiche di un modello generico ottenuto preliminarmente.
A questo punto sorge spontanea una domanda: quale è il livello di astrazione ottimale
per un modello gestionale generico? Diamo qui di seguito una risposta preliminare.
L’argomento verrà discusso più in dettaglio nel Cap.3. Per il momento diciamo che un modello
gestionale generico per essere utile e acquistare popolarità deve realizzare un delicato
compromesso fra due situazioni estreme: esso deve essere sufficientemente generico da
essere semplice (facilmente implementabile) e applicabile a un numero significativo di diverse
Tecnologie ICT o scenari di servizio TLC ma al tempo stesso non deve essere troppo generico
da creare ambiguità e indecisione nella implementazione e dar luogo a una gestione polivalente
incapace di garantire i livelli di efficacia/efficienza desiderati per i singoli casi specifici (i.e.
non si vuole che i modelli gestionali abbiano ampia validità ma poi la loro applicazione non
permetta di raggiungere la performance economica desiderata per i singoli casi specifici).
In conclusione, una volta tanto la realtà del mondo TLC e i progressi del software
engineering (e.g. tecniche/tecnologie di “orientamento agli oggetti” e “computazione
distribuita”) ci semplificano la vita: molti servizi TLC seppur diversi nelle loro “essenze”
possono beneficiare dello stesso tipo di gestione tanto da poter condividere uno stesso modello
gestionale (per questo denominato “generico”). Stesso discorso vale per sistemi TLC e
Tecnologie ICT. Tecnologie ICT realizzate da diverse manifatturiere ICTS con tecnologie
implementative diverse possono essere gestite alla stessa maniera applicando modelli gestionali
sufficientemente generici tali da garantire interoperabilità eterogenea e, al tempo stesso, non
soffocare iniziative di innovatività tecnologica da parte delle singole imprese manifatturiere
“Standards don’t eliminate innovation…They allow you to focus on where the real value lies,
128
which is usually everything you can add above and around the standard”. (modelli gestionali
minimalisti, vedi Cap.3). Aggiungendo caratteristiche specifiche ai modelli generici si possono
poi ottenere modelli specifici per tecnologie o servizi specifici. Avremo tempo di occuparci di
questi argomenti nel corso delle lezioni!
1.2.8 Conclusione
Quanto detto in questo paragrafo lo riassumiamo dicendo che per noi “La gestione
del sistema TLC è nel sistema” e “La gestione di un servizio TLC è nel servizio”.
Sembrano frasi banali ma invece, specialmente per i servizi TLC, esprimono concetti che
derimono lunghe controversie del passato (“cosa è la gestione di un servizio TLC”?) e sono
indicative di una filosofia GST ormai consolidata. La riassumiamo come segue: “Un sistema o
servizio TLC va considerato nella sua integrità. In esso si riconosce una molteplicità di
elementi costitutivi (rispettivamente tecnologie e funzionalità/funzioni). Fra questi si
identificano elementi essenziali che realizzano la “ragion d’essere”del sistema o servizio TLC
(i.e. necessari per ottenere il risultato/prodotto desiderato) e elementi gestionali di natura
ancillare rispetto ai primi necessari perché il risultato complessivo sia ottenuto in maniera
efficace/efficiente (valenza economica della gestione)”.Nel caso di servizi complessi (e.g. con
molteplicità di partecipanti, media e contenuti) decidere fra elementi essenziali e gestionali
talvolta non è facile, (abbiamo accennato ai servizi multiparty multimediali di ultima
generazione). La decisione è demandata ad autorità esterne ufficialmente riconosciute dagli
operatori del settore. Gli enti di standardizzazione “de jure” sono autorità esterne che emanano
standards gestionali in cui specificano le tecnologie e le funzionalità gestionali con diversi
livelli di dettaglio (o, se si vuole, diversi livelli di astrazione). Tutti coloro che adottano gli
standards sanno cosa significa gestire un sistema TLC o un servizio TLC (carattere
convenzionale della gestione). I modelli gestionali di sistemi e servizi TLC, oltre alla loro
importanza epistemologica tipica di tutti i modelli (“creation of order out of caos in an
information domain!”), hanno una importanza pratica. La condivisione di modelli gestionali
standardizzati facilita l’interazione fra gruppi di lavoro all’interno di una stessa impresa TelCo
o nell’ambito di relazioni cross-aziendali del tipo TelCo - ICTS o TelCo –TelCo partner. Tutto
questo accade grazie all’uso di terminologie comuni, alla condivisione delle conoscenze
relative a funzionalità/tecnologie gestionali e funzionalità/tecnologie gestite e ad un accordo
sulla suddivisione dei compiti gestionali da svolgere i.e. “chi fa che cosa” (e.g. flussi di processi
operativi cross-aziendali).
1.2.9 Esercizi
1.
In una automobile si vuole riconoscere una parte essenziale (gestita) e una parte gestionale.
i)
Quale è il criterio di scelta? (Suggerimento: Cominciare col definire cosa sia la “ragion d’essere” o la
“funzionalità core” di un automobile)
ii)
Quali componenti appartengono a una o all’altra parte?
iii)
Facendo riferimento alle tecnologie impiegate in una automobile perché è difficile distinguere in modo
netto le tecnologie gestionali dalle tecnologie gestite?
129
iv)
Nel caso di un automobile è utile identificare tecnologie gestionali e tecnologie gestite?
v)
Nel caso di un servizio TLC fornito con la partecipazione di più TelCo partners perché è importante
identificare processi essenziali (service core) e processi gestionali?
2. Quale è il significato delle frasi “La gestione del sistema TLC è nel sistema” e “La gestione di un servizio TLC
è nel servizio”?
3. Un servizio di teleconferencing interattivo multimediale con più partecipanti (e.g. on line document editing)
viene fornito alle condizioni definite in un contratto SLA (Service Level Agreement) stipulato da un SP e un
Cliente Principale. Il contratto prevede durante una sessione di servizio un numero di Session Participants variabile
da 2 a 10, residenti in altrettante postazioni di lavoro remote con terminali dotati di GUI (Graphic User Interface) e
con una associazione terminale-terminale di natura selezionabile fra voce, testo, immagine fissa, o video. Quali
sono la parte gestionale e la parte gestita (U&S) del servizio? (Discutere l’argomento in un gruppo di almeno tre
studenti)
4. Chi stabilisce quale è la parte gestita e la parte gestionale di un sistema o servizio TLC? Posso decidere
personalmente su base individuale o mi devo rimettere ad una autorità esterna? Chi sceglie l’autorità esterna?
5. Perché la gestione delle tecnologie ICT contenute in un sistema TLC viene fatta con un “modello gestionale del
sistema TLC”? Cosa è un modello gestionale e perché si usa il termine “modello”? Quale è la differenza fra
“rappresentazione” e “modello”?
6. Quali sono i vantaggi e gli svantaggi associati all’adozione di un “modello gestionale generico”? Quali sono le
tecniche computazionali che permettono di creare un modello gestionale specifico semplicemente aggiungendo
ulteriori caratteristiche specifiche ad un precedente modello gestionale generico (ri-uso del modello gestionale
generico)
Gestione di impresa
Gestione relazioni clienti (CRM)
Business
Gestione servizi
Gestione relazioni imprese partner e suppliers
Gestione reti
Engineering
Gestione elementi rete
Tavola 1.3.1.1
130
Engineering
Info
Systems
Finance
M&S
Engineering
General
Counsel
& ER
Accounting
Operations
Procurement
Senior
Management
Review
Board
(VP’s)
Information
Systems
Finance
Procurement
Team Leader
Marketing
& Sales
Operations
Accounting
General
Counsel
& ER
Service
Development
Integrated
Team
Fig.1.3.1.1 Esempio di team integrato di esperti provenienti da varie unità organizzative all’interno di una
TelCo. E’ importante il ruolo di un Team Leader dotato di competenze professionali trasversali e il
supporto attivo del Senior Management per superare le interfacce dipartimentali. Compito del team è lo
sviluppo di nuovi servizi TLC (“Product Development”) mettendo in conto sin dall’inizio anche la
risoluzione di problematiche relative alla gestione integrata di sistemi e servizi TLC (Gestione TLC) . Le
tecnologie abilitanti sono sviluppate da imprese ICTS (Technology Manufacturer) esterne alla TelCo ma con
le quali la TelCo deve stabilire rapporti di business molto stretti. Possono far parte del team integrato anche
esperti in tedcnologie ICT provenienti da una ICTS. ER = External Relations
131
1.3 “Gestione TLC” & formazione interdisciplinare
PREMESSA. Prima di iniziare la sezione 1.3 si consiglia di leggere l’Appendice 5 al Cap.1
“Interdisciplinarietà: cross-fertilizzazione di conoscenze con produzione di extra-conoscenze”. Aiuta a
capire bene la differenza fra “multidisciplinarietà” e “interdisciplinarietà” e la ragione per cui lo studio
della Gestione TLC è bene sia fatto su base “interdisciplinare”. Se si è particolarmente interessati al
soggetto della “interdisciplinarietà” si consigliano gli ottimi libri di J.Thompson Klein: “Interdisciplinarity:
History, Theory and Practice” (1990), “Crossing Boundaries: Knowledge, Disciplinarieties, and
Interdisciplinarieties” (1996), “Transdisciplinariety: Joint Problem Solving among Science, Technology and
Society” (2001)
1.3.1
Interdisciplinarietà: integrazione Engineering - Business nella
Gestione TLC
In questa sezione vogliamo mostrare come l’insegnamento di un corso universitario
per futuri ingegneri dedicato alla Gestione TLC, con la G maiuscola (“gestione integrata di
sistemi e servizi TLC”) richieda un approccio interdisciplinare.
INSERTO 1.3.1.1 Il requisito di interdisciplinarietà a livello formativo
(e.g. nell’ ambiente accademico in cui si svolge questo corso) è una
conseguenza della richiesta di competenze professionali interdisciplinari
a livello lavorativo (mondo del lavoro post laurea in cui si troveranno i
nostri laureati) la quale a sua volta è una conseguenza della natura
intrinsecamente interdisciplinare delle problematiche da affrontare e
risolvere nella realtà delle imprese TelCo specialmente nella fase di
“Product Development” (sviluppo di sistemi informatici abilitanti i
“flussi operativi end-to-end” nella Gestione TLC). Infatti la Gestione
TLC, con la G maiuscola, si basa su flussi operativi end-to-end abilitati
da tecnologie informatiche integrate (e.g. OS, NSS, OSS e BSS) i quali
abbracciano tutto l’arco delle gestioni locali, dalla Gestione Relazioni
Clienti alla gestione di reti e elementi di rete (vedi Fig.1.3.3.2). La
pianificazione, analisi e progettazione di queste tecnologie richiede
all’interno di una TelCo un complesso di competenze professionali
trasverali “Engineering” - “Business” realizzate attraverso teams
integrati cross-funzionali (Vedi Appendice 7 al Capitolo 1 e Fig.A7.3).
In particolare gli studenti di Ingegneria TLC devono riconoscere
l’importanza di avere conoscenze interdisciplinari e acquisire
competenze professionali trasversali se vogliono essere preparati a
lavorare anche in gruppi di lavoro crossfunzionali una volta laureati (e,
quindi, avere un vantaggio competitivo rispetto ad altri neolaureati privi
di queste conoscenze in fase di ricerca di un posto di lavoro).
132
INTERDISCIPLINARIETA’
NELLE TELECOMUNICAZIONI
Engineering
Procurement
Finance
Team Leader
Marketing
& Sales
Operations
Information Systems
SD
Strategic
Processes
1.1.
2.2.
3.3.
4.4.
5.5.
6.6.
ANALISI
’’
ANALISIdelle
delleOPPORTUNITA
OPPORTUNITA
DEFINIZIONE
’’
DEFINIZIONE&&FATTIBILITA
FATTIBILITA
PROGETTAZIONE
&
VERIFICHE
PROGETTAZIONE & VERIFICHE
SVILUPPO
SVILUPPO(Rete
(Rete+OSS)
+OSS)
IMPLEMENTAZIONE
IMPLEMENTAZIONE&&PROVE
PROVE
LANCIO
COMMERCIALE
LANCIO COMMERCIALE
1.1.NEGOTIATION
NEGOTIATION
Offerte/Vendite
Offerte/Vendite
Piazzamento/Esecuzione
Ordinaz.
Piazzamento/Esecuzione
Ordinaz.
Definizione e Firma Contratto SLA
Definizione e Firma Contratto SLA
SP +
NO
SIX PHASE
PRODUCT
DEVELOPMENT
ManTec
TEAM INTERDISCIPLINARE
“PRODUCT DEVELOPMENT”
SERVICE DELIVERY
Persona
+ SP
(Customized Service)
2.2.PROVISIONING
PROVISIONING
Installazione/Attivazione
Installazione/Attivazione
(Fornitura/Acquisizione)
(Fornitura/Acquisizione)
3.3.USAGE
USAGE
Operational
Processes
(Transactional)
Persone
(Potenziali
Utenti) + SD
Utente =
Utilizzatore +
Cliente)
Utilizzazione
Utilizzazione&&Segnalazione
Segnalazione
(Erogazione/Fruizione)
(Erogazione/Fruizione)
Addebiti & fatturazione
Addebiti & fatturazione
Riscossione pagamenti
Riscossione pagamenti
Manutenzione/Riparazioni
Manutenzione/Riparazioni
Assistenza TecnicaPost-vendita
Assistenza TecnicaPost-vendita
Servizio
ServiziodidiCall
CallCenter
Center
4.4.TERMINATION
TERMINATION
Cessazione
Cessazione&&Disinstallazione
Disinstallazione
Cliente
+ SP + NO
Utilizzatore
1.1.Segnale
Segnalevia
vialibera
libera
2.2.Digitazione
DigitazioneIndirizzo
Indirizzo
3.3.Segnale
chiamata
Segnale chiamata
4.4.Inizio
Iniziosessione
sessione
5.5.Fine
Finesessione
sessione
NTWK TECHNO-SERVICE
(Service Session)
PdS Ciclo di Vita
RAPPRESENTAZIONE
DI UNA TELCO PER
PROCESSI
Prova
Fig.1.3.1.2
Zona di attività di un team di lavoro interdisciplinare nell’ambito del “Product
Development” di una TelCo. I membri del team sono “architects, designers, implementers” di servizi
TLC e sistemi TLC. L’attività interdisciplinare si deve svolgere ab initio in fase di “Product
Development” (i.e. “sviluppo servizi”) in quanto la Gestione TLC è una parte integrante sia dei
sistemi TLC che dei servizi TLC cioè le tecnologie gestionali non sono “add-on packages” da
progettare e installare all’ultimo momento.
In generale, possesso di “conoscenze interdisciplinari” significa possesso, da parte
di un unico soggetto (persona fisica o team integrato di persone), di aree conoscitive
integrate (integrated knowledge fields) risultanti dalla integrazione di conoscenze
monodisciplinari appartenenti a diverse discipline tradizionali. Una caratteristica di una
conoscenza interdisciplinare è la presenza di “extra-conoscenze” risultato di una
crossfertilizzazione virtuosa fra discipline tradizionali. Tra poco vedremo
133
Orientativamente gli studenti del corso di GST possono fare riferimento alle
seguenti definizioni delle aree conoscitive “Engineering” e “Business”:
“Engineering” (con la E maiuscola) significa “Engineering delle telecomu
telecomu-nicazioni”,
nicazioni”, un mix di quattro
discipline tradizionali: “Ingegneria Informatica – Ingegneria gestionale - Ingegneria Elettronica - Ingegneria delle
Telecomunicazioni”, le prime tre solo per la parte direttamente rilevante
rilevante a sistemi e servizi TLC. Per “ingegneria”
“ingegneria” noi
adottiamo la seguente definizione “ingegneria è la professione in cui la conoscenza delle scienze matematiche e naturali
(e.g. fisica, chimica) acquisita attraverso lo studio,
studio, l’esperienza e la pratica,
pratica, viene applicata con discernimento per
sviluppare nuovi sistemi che utilizzano economicamente le risorse della natura a beneficio dell’umanità”. Nel “modello
interdisciplinare completo” da noi adottato (Vedi Appendice 4 al Capitolo 1) le
le conoscenze di “Engineering” in effetti sono
solo parte
parte di
di una più vasta area conoscitiva identificata come TLC “Science, Engineering & Technology, SE&T”.
“Business” (con la B maiuscola) significa “Business delle telecomunicazioni”,
telecomunicazioni”, un mix di conoscenze
derivate dalle
dalle quattro discipline tradizionali di Economia
Economia & Commercio,
Commercio, Scienze della Finanza, Marketing e Gestione di
impresa, specializzate alle telecomunicazioni, laddove “economia” a livello microeconomico è “la scienza che studia le
modalità di allocazione di risorse limitate tra usi alternativi al fine
fine di massimizzare la soddisfazione degli utilizzatori”
mentre a livello macroeconomico è la disciplina che si occupa di produzione, consumi, occupazione e prezzi nei mercati a
processi
cessi con cui persone fisiche o giuridiche,
livello nazionale e internazionale; “finanza” è “la disciplina che studia i pro
pubbliche o private, gestiscono i flussi monetari nel tempo (raccolta, allocazione, usi) e “marketing” è un ramo delle
scienze economiche che “si occupa dello studio descrittivo del mercato e dell’analisi dell’interazione
dell’interazione del mercato e degli
utilizzatori con l’impresa”. A livello universitario il “Business delle Telecomunicazioni” è una specializzazione alle
Telecomunicazioni delle materie insegnate nei corsi di “Master in Business Administration” (MBA). Durante il corso di
GST il termine “Business” è usato con diversi significati e.g. “rapporto di business “ = rapporto commerciale, “processo di
business” = processo aziendale, “utenza business” = utenza affari. “obiettivo di business” = obiettivo aziendale. In
molti
molti casi useremo direttamente il termine “business” senza tentare di tradurlo e.g. useremo le espressioni inglesi “business
model”,
model”, “business plan”
plan” etc.
Tavola 1.3.1.2
che in questo corso queste discipline tradizionali sono state raggruppate in due sole aree
conoscitive da noi denominate “Engineering” e “Business”, con E e B maiuscole (vedi
Tavola 1.3.1.2). Inoltre, fra poco vedremo che è proprio la disponibilità di extraconoscenze
interdisciplinari (generate da competenze professionali trasversali) che permette ad una
TelCo in fase di Product Development di pianificare/specificare/ progettare l’integrazione
fra la gestione di reti e elementi di reti TLC sviluppata in Ambiente Engineering e la
gestione di servizi e customer care sviluppata in Ambiente Business (i numeri qui sotto
corrispondono ai numeri di Fig.1.3.1.4)
1. integrazione “gestione customer care”- “gestione servizi” (Competenze Business per
creare i modelli gestionali + competenze Engineering per implementazione tecnologica.
Integrazione tecnologica e.g. Web/Java-CORBA.)
2. integrazione “gestione servizi - gestione reti” (Mappatura Modello Rete Generico –
(Generic Network Model, GNM) – Modello Servizi (Service Interaction Model, SIM) +
Specializzazione GNM – Modelli Rete Specifici accompagnata da integrazione
134
tecnologica). Competenze interdisciplinari anche per creazione/mappatura dei modelli,
vedi Fig.1.3.1.3)
3. integrazione “gestione reti” – “gestione elementi di rete” (Integrazione tecnologica
e.g. CORBA-OSI. Competenze Engineering per creare i modelli gestionali e loro
implementazione tecnologica).
4. integrazione “gestione servizi SP1” – “gestione servizi SP2” (Interworking fra
applicazioni di SP partners. Competenze Business per creare una interfaccia applicativa
comunne e competenze Engineering per implementazione tecnologica)
Competenze professionali (Skills) & Aree Conoscitive
Mondo della Conoscenza
Modelli
Gestionali
Rete TLC (A)
Esperti TLC
Engineering
Integrazione
Team Leader
Modelli
Gestionali
Servizi TLC (B)
Esperti TLC
Business
Team di lavoro integrato (supportato dal Senior Management)
Mondo del Lavoro
Presentation 1
Fig.1.3.1.3 Superamento della zona di frontiera Engineering-Business
all’interno di una TelCo nello sviluppo di integratori “gestione
servizi-gestione reti” ad opera di un team integrato di esperti monodidsciplinari supportato dal Senior Management.
Quindi in particolare per la mappatura “gestione reti”-“gestione servizi” (corrisondenza
biunivoca fra “oggetti” nei due modelli gestionali) sono necessarie conoscenze
interdisciplinari Engineering-Business. Infatti già quando si cominciano a sviluppare i
modelli gestionali “reti” si deve tener presente che essi devono supportare i modelli
gestionali “servizi” e.g. l’installazione di un servizio TLC (modello gestionale generico
“servizi”) richiede allocazione di risorse di rete TLC (modello gestionale generico “rete”) .
Vedremo fra poco come questa mappatura si traduca in pratica a stabilire una
relazione logica, un “ponte”, fra “oggetti” corrispondenti situati nei due modelli gestionali.
(Fig.1.3.3.5). Il testo di G.Chen & Q.Kong “Integrated Telecommunications Management
Solutions”, IEEE Press, 2000 è completamente dedicato a questo argomento e noi faremo
spesso riferimento ad esso (purtroppo scritto in un Inglese terribile!). Le Raccomandazioni
ITU-T relative allo standard e-TOM sono anche esse importanti in questo contesto.
NOTA 1.3.1.1
Significato del termine “Integrazione” (di aree conoscitive)
135
Abbiamo visto come all’interno di una impresa TelCo impegnata in un business “customer oriented”,
le gestioni locali di reti TLC e loro elementi, servizi TLC e relazioni clienti facciano parte di sistemi integrati
con livelli di integrazione/automatizzazione tecnologica sempre più spinti al fine di raggiungere certi
“management goals” (scopi gestionali) e conseguire certi “business objectives” (obiettivi di business)
della TelCo in maniera efficace/efficiente e in definitiva ottenere una performance d’impresa soddisfacente e
sostenibile nel tempo (i.e. rispettosa anche delle esigenze socio – ambientali del macroambiente circostante).
In fase di “Product Development” tutto questo comporta dapprima sviluppo di modelli gestionali ottimizzati
per i vari tipi di gestione, “mappatura” da un modello all’altro e infine “integrazione” delle rispettive
tecnologie implementative (diversi modelli in genere sono implementati da tecnologie diverse). A livello
tecnologico si parla di una integrazione OS-NSS-OSS-BSS (OSS-BSS o BOSS nella letteratura
anglosassone) e di una Gestione TLC, con la G maiuscola. Ma in un contesto di conoscenze
interdisciplinari, noi usiamo il termine “Integrazione” anche con un significato diverso. Con il termine
“integrazione” (di aree conoscitive) qui si vuole indicare non solo una stretta aggregazione e
contestualizzazione di conoscenze appartenenti a discipline tradizionali diverse in un unico corpus
conoscitivo memorizzato/utilizzato da un' unica entità (attore singolo o team integrato di attori) ma si allude
anche al “valore aggiunto” (i.e. creazione di nuove conoscenze, denominate anche extraconoscenze
interdisciplinari) risultante da processi virtuosi di crossfertilizazzione o di mappatura fra elementi
conoscitivi appartenenti alle singole discipline.
136
Commento:
Clienti
Interfaccia Accesso Clienti
Applicazioni
Gestione
Servizi
Appl.
Gestione
Reti
1
GESTIONE CUSTOMER CARE
(JAVA/WEB)
Strato Accesso Servizi
GESTIONE SERVIZI (CORBA)
Processi GS
2
Tecnologie GS
Dati GS
S
P
/
S
P
Strato Integrazione Gestione Servizi – Gestione Reti
GESTIONE RETE (OSI)
Processi GR
Tecnologie GR
Dati GR
3
Gestione Elementi Rete
Fig.1.3.1.4 La Gestione TLC richiede “mappature” di modelli gestionali e integrazioni di
tecnologie.
137
4
Fig.1.3.2.1 Il TMF agli inizi del 2000 ha istituito una Service Framework Team che ha prodotto il “Service
Management Framework” mostrato in questa figura. (Service Model Framework, Release 4.5, TMF,
Nov.2004.) Si tratta di un diagramma che mostra le competenze professionali degli stakeholders interni ed
esterni a una TelCo partecipanti alla gestione dei servizi TLC nel corso di un ciclo di vita di un servizio. La
fase di lancio commerciale (Launch) separa il “Product Development” dalla fase di “Service Delivery”.
138
1.3.2
“Product Development” in una TelCo: interdisciplinarietà
“Engineering-Business”.
1.3.2.1 Aree conoscitive “Engineering” e “Business”: mix di discipline tradizionali
All’interno di una TelCo i vari tipi di gestione locale sono implementati da processi
gestionali ad hoc supportati da specifici modelli gestionali. Come già indicato questi
modelli sono sviluppati ab initio già nella fase di “Product Development” in forma integrata
congiuntamente con lo sviluppo delle relative tecnologie di supporto e.g. OS, NSS, OSS,
BSS. In linea con la terminologia ITU-T qui usiamo il termine “Product Development”
invece di “Service Development” per ricordarci che la TelCo produce servizi TLC che poi,
in un contesto “Marketing”, fanno parte di un “offerta” di prodotti TLC al Cliente (vedi
par.1.0.3.1).
Il “Product Development” in ambito TelCo è una attività aziendale molto
complessa che richiede il contributo di competenze professionali diverse supportate da
conoscenze/esperienze appartenenti a diversi settori delle TLC. Il TMF prevede
(Fig.1.3.2.1) che in una TelCo un nuovo servizio TLC richieda almeno dodici tipi di
competenze professionali diverse corrispondenti ad una varietà di settori disciplinari
diversi. Negli enti di standardizzazione che producono standardards per sistemi e servizi
TLC si verifica una situazione molto simile (e.g. vedi il programma NGOSS, Next
Generation Operations Systems and Software del consorzio internazionale TeleManagement Forum).
In questo corso per semplificare la trattazione e rispettare i vincoli didattici previsti
per l’anno accademico 2008-2009 noi faremo riferimento non a dodici competenze
professionali diverse bensì a competenze professionali supportate da due sole aree
conoscitive, “Engineering” e “Business” (con le iniziali maiuscole), ognuna delle quali è
infatti un mix di quattro discipline tradizionali specializzate alle TLC come mostrato nella
di Tav. 1.3.1.2. Da un punto di vista operativo e alla luce delle attuali specializzazioni
professionali si ritiene che l’ area conoscitiva Engineering possa essere “coperta” con un
team integrato di almeno quattro tipi di ingegneri (Ingegneria TLC, Ingegneria Informatica,
Ingegneria Gestionale e Ingegneria Elettronica) mentre l’ area conoscitiva Business può
esser coperta da un team integrato di esperti con diploma MBA (Master in Business
Administration) e/o lauree in Economia & Commercio, Scienza delle Finanze, Scienza del
Marketing e Gestione di Impresa tutte con specializzazione in TLC. La Tavola 1.3.1.1
mostra i tipi di gestione (domini gestionali) all’interno di una TelCo e le corrispondenti aree
conoscitive di supporto.
Quando parliamo di “area conoscitiva di supporto a un certo modello gestionale
architetturale o di processo” facciamo riferimento alle conoscenze teorico-pratiche
/competenze professionali richieste nella fase di sviluppo (analisi/progetto) del modello. Il
modello gestionale viene poi implementato con opportune tecnologie abilitanti
(“implementazione” del processo gestionale)e integrato in un “sistema informatico”
finale testato poi in fase di pre-esercizio.
139
La Fig.1.3.1.1 mostra la composizione di un team integrato interdisciplinare
costituito all’interno di una TelCo per lo sviluppo di nuovi prodotti TLC. Notare come a
rigore il solo binomio “Engineering-Business” non copra tutte le aree conoscitive necessarie
allo sviluppo dei servizi TLC. Altre aree conoscitive dovrebbero essere prese in
considerazione per uno studio completo della Gestione i.e. le aree “Legal, LegislativeRegulatory” (General Counsel) e “Social” (External Relations). L’argomento verrà trattato
nell’ Appendice 4 al Cap.1 (non incluso nel programma 2008-2009).
1.3.2.1 Il mondo del lavoro post – laurea: teams di lavoro integrati
Nelle imprese TelCo la tendenza attuale è quella di sviluppare sin dalla fase di
“Product Development” modelli/tecnologie gestionali progettate/realizzate integrando
modelli/tecnologie ottimizzate su base locale. Ciò viene fatto con l’ impiego di esperti in
discipline diverse integrati in gruppi di lavoro interdisciplinari (cross-funzionali). Questi
gruppi di lavoro sono creati attaverso un lavoro preparatorio lungo, minuzioso e paziente
da parte di uno o più team leaders con “conoscenze interdisciplinari” e “competenze
professionali trasversali” e con il supporto diretto (commitment) del Senior Management
della TelCo (Vedi Fig.1.3.1.1 e 1.3.1.2). Quest’ultimo punto è di fondamentale importanza
se si vuole che all’interno di una TelCo un progetto interdisciplinare industriale abbia buone
probabilità di successo superando le varie interfacce organizzative che inevitabilmente si
presentano allorchè si crea un team crossfunzionale all’interno di una impresa attraversando
interfacce fra unità organizzative diverse (vedi Appendice 5 al Cap.1). Da un punto di vista
operativo, la creazione di teams di lavoro integrati oggi è facilitata dai servizi di
teleconferenza e telelavoro via internet i.e. dalla creazione in rete di “ambienti
collaborativi” molto coesi che permettono la collaborazione in tempo reale di gruppi di
lavoro paralleli residenti in postazioni geograficamente remote (importante per TelCo
multinazionali).
Se le esigenze del mondo del lavoro nelle TelCo e negli Enti di Standardizzazione
e di Regolamentazione spingono nella direzione di “creazione di gruppi di lavoro integrati
di natura interdisciplinare” allora è bene che i nostri studenti prendano coscienza e si
preparino a condividere questa realtà post laurea e che un corso di GST sia un corso
interdisciplinare comprendente (almeno) le aree conoscitive di Engineering e Business.
Alla luce di tutto ciò, questo corso, che si rivolge a studenti con un background tecnico, si
prefigge il compito di creare ingegneri TLC con competenze professionali poi utilizzabili
in gruppi di lavoro interdisciplinari capaci di sviluppare modelli e tecnologie gestionali
integrate per la gestione di sistemi e servizi TLC (i.e. creazione a livello universitario di
“team working capability”!).
NOTA 1.3.3.1 Notare come all’interno di una impresa TelCo ma al di fuori del
“Product Developmente” esistono ambienti di lavoro che richiedono solo competenze
professionali Engineering o solo competenze professionali Business. Ad esempio le
attività di Network Operator sono espletate principalmente da Attori Engineering
mentre quelle di “Marketing & Sales” da Attori Business.
140
Richiesta dal Cliente
Notifica al Cliente
Customer Interface Management
Customer
Relation
Management
(BSS)
Service
Management
(OSS)
Strati gestionali
Resource
Management
(NSS)
Partner/
Supplier
Management
(BSS)
F
A
B
Prova
Partner SP
F1
F2
F3
.
.
.
.
FN
Fig.1.3.3.2 Rappresentazione “swim-lane” di un flusso operativo end-to-end Si tratta di un
flusso di processi che comprende tutti i processi necessari a fornire un customer service e.g.
“accettazione ordinazioni servizi e emissione di fatture”e attraversa strati gestionali e
raggruppamenti processuali (FAB) diversi In ogni strato gestionale i processi
sono supportati da modelli gestionali (sviluppati in fase di analisi/progettazione )
e tecnologie gestionali standardizzate (sviluppate in fase di realizzazione del software)
specifiche di quel particolare strato. Il flusso di processi è implementato da uno o più
stakeholders legati da relazioni di business. Per semplicità in figura si suppone che
tutti i processi siano implementati all’interno di una TelCo ed è di natura cross-funzionale
(vedi in basso la struttura organizzativa della TelCo).Architects, designers, implementers
di macroprocessi end-to-end sono integrati in teams di lavoro interdisciplinari.
141
Struttura
Organizzativa
della TelCo
“per Funzioni”
1.3.3 Perché modelli e tecnologie diverse per diverse gestioni locali?
Vediamo ora perché i vari tipi di gestione locale (elementi di rete, rete, servizi e
relazioni clienti) hanno esigenze diverse, devono soddisfare requisiti diversi e quindi
richiedono modelli e tecnologie abilitanti diverse. Infatti
1. La gestione degli elementi di rete (Network Element, NE) richiede modelli
gestionali molto dettagliati (i.e. in una architettura ad “oggetti” richiede modelli con un
grande numero do “oggetti gestiti”, come vedremo nella Parte II del corso) modelli capaci
di rappresentare le caratteristiche gestionali dei singoli elementi di rete (e.g.
autocommutatori, istradatori, linee di trasmissione etc.) Tuttavia questi elementi, come pure
le loro mutue relazioni ( topologie di rete) , hanno caratteristiche gestionali che non variano
rapidamente nel tempo (i.e. gli “oggetti gestiti” non devono essere modificati spesso e per
questo sono anche detti “statici”). In genere si tratta di modelli gestionali proprietari del
costruttore, implementati con sistemi OS (Operations Systems = Sistemi di Esercizio)
attestati direttamente sull’elemento di rete.
2. La gestione delle reti ha caratteritiche simili alla gestione elementi di rete
(entrambe sono supportate da competenze professionali “Engineering”) ma richiede un
modello più astratto, meno dettagliato. Ad esempio, informazione dettagliata è necessaria
per operare uno switch ma solo una parte di essa è necessaria per operare una rete TLC e.g.
se lo switch è guasto o è sano o è attivato o disattivato. E’ proprio questa parte che viene
“astratta” dal modello gestionale degli elementi di rete ed è trasferita nel modello gestionale
di rete. In effetti in un modello gestionale di rete è prioritario modellare le caratteristiche
complessive di un insieme di apparati interconnessi da linee di trsmissione e.g. le
caratteristiche delle connessioni circuitali end-to-end da una terminazione di rete all’altra.
3. La gestione dei servizi è più dinamica. Essa deve gestire una molteplicità di
processi gestionali spesso innescati dai clienti con variazioni temporali su base day-by-day
o hour-by-hour e geograficamente distribuiti e.g. accettazione/processing delle richieste di
installazione servizi presentate dai clienti, monitoraggio e controllo della qualità dei servizi,
preparazione di tariffe e sconti, fatturazione/raccolta pagamenti etc, talvolta su base globale.
Considerando il numero di Utenti si può capire la vastità del problema. In queste
circostanze è opportuno sviluppare modelli di gestione servizi estremamente flessibili e
facili da adottare alle esigenze di una varietà di mercati , ma soprattutto, indipendenti da
domini tecnologici e amministrativi i.e. i modelli gestionali dei servizi devono ignorare la
eterogeneità delle tecnologie implementative di apparati e reti provenienti da costruttori
diversi (domini tecnologici diversi) come pure devono ignorare la etereogeneità delle
procedure gestionali dovuta a gestori locali residenti in sedi remote spesso distribuiti su
base multinazionale (domini amministarativi diversi). Infatti, dal punto di vista della
fornitura/acquisizione di un servizio TLC non fa alcuna differenza se il servizio è abilitato
da una rete terrestre wireline o wireless, con tecnologia ATM o tecnologia SONET o via
satellite purchè queste tecnologie siano “equivalenti” (vedi Cap.4). Quello che conta è che
le risorse allocate in rete siano capaci di soddisfare i requisiti del servizio stesso e.g.
disponibilità delle linee, qualità della trasmissione, tempi di ritardo etc.
142
4. Nella gestione delle relazioni clienti (Customer Relation Manaagement,
CRM) effettuata separatamente ma non indipendentemente dalla gestione servizi, si devono
gestire in modo efficiente una molteplicità di transazioni con coinvolgimento diretto del
singolo cliente e con tempi caratteritici dell’ordine dei minuti (eventi CRM, Customer
Relation Management) e.g. invio al Cliente di informazioni sui servizi erogati e sulle loro
caratteristiche, accesso dettagliato da parte dei clienti ai records delle
fatturazioni/pagamenti, notifica proattiva di malfunzionamenti e conseguenti degradazioni
della QoS, soddisfacimento dei reclami in modo rapido con riparazioni accurate etc.
utilizzando tecnologie periferiche facilmente disponibili ai Clienti possibilmente attraverso
terminali di gestione facilmente accessibili e.g. telefono, internet, fax .
NOTA 1.3.4.2.3. Attenzione a “modelli”, “implementazione di modelli” e
“tecnologie”!
In generale i modelli gestionali a cui ci riferiamo sono modelli “reti” e
modelli “servizi” generici rispettivamente indipendenti dalle particolari
implementazioni tecnologiche e dai particolari scenari di servizio
considerati. Esempi di questi modelli sono i modelli a oggetti GNM
(Generic Network Model) e SIM (Service Interaction Model). Tuttavia
quando consideriamo un sistema informatico reale noi ci riferiamo ad un
pacco software che contiene una applicazione gestionale realizzata
secondo una tecnologia specifica.
Ad esempio i modelli GNM e SIM
possono implementarsi con una tecnologia IT denominata CORBA.
Tuttavia nel caso di OSI-SM esiste un “modello gestionale OSI-SM”
(specializzazione al caso gestionale del modello di riferimenti OSI)
implementato con “tecnologia software OSI-SM” o semplicemente
“tecnologia OSI”. Quando una “tecnologia OSI” sviluppata per gestire
elementi di rete specifici deve interagire con una tecnologia CORBA (e.g.
imoplementativa del modello GNM) la due tecnologie usano linguaggi
degli “oggetti gestiti” e protocolli comunicativi diversi, noi diciamo che ciò
avviene attraverso un “integratore tecnologico CORBA-OSI”.
Si tratta quindi di soddisfare per i quattro tipi di gestione requisiti diversi nel modo
migliore possibile, utilizzando per ciascun tipo modelli gestionali e tecnologie software
abilitanti ottimali e aggregando poi le soluzioni parziali in un' unica soluzione integrata
(possibilmente con componenti applicativi “loosely coupled”, vedi par.1.3 )
Ad esempio, si possono adottare le seguenti tecnologie gestionali,
1) tecnologia OSI per la gestione delle reti e degli elementi di rete utilizzando un
paradigma Manager-Agent
2) tecnologia CORBA per la gestione dei servizi usando un paradigma ClientServer
3) tecnologie Java/Web per gestire l’interfaccia cliente utilizzando la rete internet.
143
Queste tecnologie devono poi cooperare in un sistema gestionale organico i.e. vanno
poi integrate in un unico sistema gestionale integrato. Il livello di integrazione fra
modelli gestionali diversi può essere più o meno spinto: da una semplice conversione di
linguaggio e di protocollo comunicativo fino ad effettuare una mappatura fra modelli
informativi (object models) diversi e.g. modello gestionale servizi e modello gestionale reti
(integrazione R-S).
1.3.4
La sfida: la mappatura RE-SB fra modelli gestionali di Reti
(Engineering) e Servizi (Business) e gli “integratori tecnologici” fra
tecnologie software diverse
Ora vogliamo identificare le problematiche interdisciplinari reali che si sono
incontrate nel campo della “gestione integrata” di reti e servizi (Gestione TLC) in una
TelCo o un ente di standardizzazione e che richidono “competenze professionali
trasversali” posizionate alla frontiera Engineering-Business.
Abbiamo visto che in una TelCo queste problematiche nascono in fase di “Product
Development” cioè in fase di pianificazione/analisi/progettazione di futuri servizi TLC. Ma
in dettaglio di cosa si tratta? Come nascono e come sono risolte le “problematiche
interdisciplinari?
1.3.4.1
Riepilogo: flussi operativi end-to-end all’interno di una TelCo (Fig. 1.3.3.2 e
Fig. 1.3.3.4)
Abbiamo visto come i processi operativi in una TelCo “customer oriented” vengano
poi inseriti in flussi di processi (vedi Appendice 6 al Capitolo 1) che contengono tutti i
processi operativi necessari e sufficienti per fornire i “customer services” richiesti dai
Clienti e, al tempo stesso, per conseguire gli obiettivi di business prefissati in fase di
pianificazione strategica (flussi operativi end-to-end). Gli obiettivi di business fanno parte
di un business plan prestabilito. Da un punto di vista tecnologico un flusso di processi
gestionali è abilitato da un insieme di Support Systems (e.g. OS, NSS, OSS, BSS) dedicati
ad applicazioni specifiche, integrati da piattaforme di integrazione e controllati da sistemi
di workflow management (sistemi per la gestione dei “flussi operativi”). Per questo
diciamo anche che un flusso operativo end-to-end è supportato da tecnologie
OS/NSS/OSS/BSS. (Vedi N. V. Jones, “Telecommunications Management”,
Virtualbookworm. com, 2004, p.78).
Una caratteristica di un flusso operativo end-to-end è che esso è il risultato della
integrazione di processi gestionali finalizzati a gestire “tipi di oggetti” diversi con modalità
diverse. Diciamo anche che un flusso operativo end-to-end attraversa strati gestionali
diversi (Fig.1.3.3.2 e 1.3.3.3). Ad esempio, esso si svolge lungo tutto l’arco della Gestione
TLC i.e. un arco che va dai processi esterni di “gestione clienti” (Customer Relation
Manegement, CRM) e attraverso processi interni di “gestione servizi” arriva fino a processi
di “gestione reti” e “gestione elementi di rete” (gestione delle risorse). Questo tipo di flusso
operativo usa il termine “end-to-end” per due motivi 1) perché in un modello gestionale
stratificato come in Fig.1.4.3.2 si sposta verticalmente “da un estremo all’altro” i.e. dalla
144
gestione clienti (in alto) alla gestione tecnologie di rete (in basso) e 2) perché contiene tutti i
processi operativi necessari a processare una richiesta iniziale formulara da un Cliente in
una risposta finale fornita al Cliente (vedi Fig.1..4.3.2). Usando una terminologia ITU-T si
può dire che come un Servizio di Gestione (Management Service) è la aggregazione di un
insieme di Funzioni di Gestione (Management Functions) standardizzate (funzioni definite
nel modello FCAPS, vedi par.3.3.3 al Capitolo 3) così un flusso operativo end-to-end è un
flusso di processi risultante dalla aggregazione di processi operativi standardizzati (processi
definiti nel modello e-TOM, vedi Appendice 3 al Capitolo 1). La differenza consiste nel
fatto che un Servizio di Gestione fornito da una Rete di Gestione fa parte di una vecchia
visione “resource centric” o “SP centric” (“dal basso in alto”, bottom-up) mentre un “flusso
operativo end-to-end” fa parte di una nuova visione “business centric” o “customer centric”
(“dall’alto in basso”, top-down).
I flussi operativi end-to-end sono estremamente importanti per imprese TelCo
customer oriented che operano in un libero mercato. Infatti i flussi operativi end-to-end
sono finalizzati al conseguimento degli obiettivi di business della TelCo ed è poi sulla base
della efficienza/efficacia dei flussi operativi end-to-end messi in atto da una TelCo che essa
viene poi “misurata” dai suoi clienti e dalla concorrenza. E questa efficienza/efficacia
richiede il supporto di una automazione/integrazione tecnologica molto spinta. Cosa non
facile! Infatti il flusso è supportato da un mix di modelli gestionali (architetturali e di
processo) ottimizzati singolarmente per i vari domini gestionali attraversati (filosofia della
“right technology for the right domain” condivisa da quasi tutti gli operatori del settore).
Notare l’espressione “automazione molto spinta” ma, ovviamente, non totale: si tratta di un
avvertimento teso ad evitare i facili entusismi dei softweristi ad oltranza e a ricordare che
esseri umani sono sempre presenti nei flussi operativi, infatti “persone non macchine
negoziano con i clienti, eseguono progetti, installano servizi, riparano guasti….”
(G.Fantauzzi, “I sistemi software per le reti ed i servizi di telecomunicazione”, Franco
Angeli, 2000, pag.372)
145
Customer Interface Management
CRM
BSS
CRM Op.
Support &
Process
Mngmt
CRM
Operations
Readiness
Sales & Channel
Management
Marketing
Fulfillment
Response
Order
Handling
Problem Handling
Customer
QoS/SLA
Management
Selling
Retention & Loyalty
Service Management & Operations (SM&O)
SM&O Support
& Process Mngmt
OSS
Service
Problem
Management
Service
Configuration
& Activation
Resource Management & Operations (RM&O)
OS
NSS
Resource Trouble
Mngmt
Resource
Perf. Mngmt.
Resource
Provisionig
Resource Mngmt &
Operations
Resource Data Collection & Processing
Supplier/Partner Relationship Mngmt
BSS
SPRM Oper. Support
& Process Mngmt
S/P Problem
Reporting & Mngmt
S/P
Requisition
Mngmt
SPRM Operations
Readiness
Oper. Supp. & Readiness
Service &
Specific Instance
Rating
QoS Analysis
Action & Reporting
SM&O Readiness
RM&O Support &
Process Mngmt
Billing &
Collections
Management
S/P Performance
Mngmt
S/P
Settlements
& Billing Mngmt
. Supplier/Partner Interface Management
Fulfillment
Assurance
Billing
Fig.1.3.3.3
I processi operativi del modello e-TOM. I processi rappresentati dai rettangoli gialli sono
utilizzati nel flusso operativo end-to-end di Fig.1.3.3.4 (raggruppamento “Fulfillment”)
1.3.4.2 Mappatura ER-SB e integratori tecnologici
ATTENZIONE! Si consiglia agli studenti volenterosi di leggere gli ADDENDA No. 1,
.2 e 3. Riportiamo qui di seguito alcuni concetti sulla Computazione a Oggetti
146
Distribuiti (Distributed Object Computing) : il minimo indispensabile per capire la
integrazione di gestioni locali diverse.
•
Tecnologie gestionali DOC (Distributed Object Computing)
La tendenza verso una integrazione sempre più spinta sia a livello di
analisi/progettazione di sistema che a livello di implementazione tecnologica è stata
incentivata e ancor oggi supportata dal progresso tecnologico nel campo delle tecnologie
informatiche distribuite DOC (Distributed Object Computing). Infatti è grazie a queste
tecnologie che è possibile costruire sistemi informatici gestionali integrati con componenti
applicativi eterogenei loosely coupled o in modalità “plug & play” (vedi par.1.4.2.1)
NOTA 1.3.4.2.1 Nozioni generali su Distributed Object Computing = Distributed
Computing + Object Orientation (DOC = DC + OO)
1. “DISTRIBUTED COMPUTING”.
In questo corso noi definiamo un sistema
“fortemente” distribuito come un sistema costituito da componenti applicativi autonomi,
residenti in nodi elaborativi remoti interconnessi da una rete di comunicazione dati, che
cooperano in un contesto di elaborazione virtualmente unitario cioè come se fosse “non
distribuito”(Vedi ADDENDUM No.1 e par.3.6 del Capitolo 3). Ciò avviene perché il sistema
computazionale si fa esso stesso carico dei problemi della distribuzione (e.g. indirizzo,
sincronismo, linguaggio dei componenti) tramite un sofware denominato “middleware” perché
interposte fra software applicativo e l’ hardware del processore, vedi Fig. 3.3.4.2 nel Cap.3. In
particolare l’utilizzo di tecnologie “middleware” permette la realizzazione di sistemi gestionali
“fortemente” distribuiti secondo i principi enunciati dall’ITU-T nel modello di riferimento
ODP-RM (Open Distributed Processing–Reference Model) (vedi anche “Reference Model
for Open Distributed Processing”, ITU-T Recommendation X.901, 1997). Più precisamente il
modello di riferimento ODP-RM applicato a scenari gestionali distribuiti ha poi generato il
modello gestionale ODMA (Open Distributed Management Architecture) proprio come il
modello di riferimento OSI-RM (Open Systems Interconnection-Reference Model, la pila a
sette strati!) ha dato luogo al modello gestionale OSI-SM (System Management). L’architettura
ODMA, come specializzazione dell’ODP-RM, é descritta nella raccomandazione ITU-T X.703
(Ottobre 1997).
2. “OBJECT ORIENTATION” L’Orientamento agli Oggetti è non solo un paradigma di
analisi di sistema (system analysis) ma anche una tecnica di modellazione di sistema (sistem
design) nella quale il sistema viene “visto” e modellato come una molteplicità di ”oggetti”
interagenti. Un “oggetto” è la rappresentazione di una entità reale esistente nel sistema reale da
modellare. “An object is an entity that exhibits some well defined behaviour: objects do things
and we ask them to perform what they do by sending them messages” [G.Booch, “Object
Oriented Analysis and Design” Addison-Wesley, 1994]
•
Tecnologia CORBA e tecnologia gestionale CORBA/ODMA (Fig.1.3.4.2.1)
In questo corso noi faremo riferimento a due esempi concreti di tecnologie IT: : la
tecnologia CORBA (Common Object Request Broker Architecture) come esempio di
DOC-IT per la gestione dei servizi TLC e la tecnologia OSI come esempio di tecnologia
147
gestionale per reti e elementi di rete TLC. . (vedere dettagli nella Addendum No.2 per
CORBA e Addendum No.4 per la programmazione a oggetti).
Nella tecnologia CORBA i vari componenti comunicano fra loro secondo un
paradigma “Client-Server” tramite un comune bus logico di comunicazione denominato
ORB (Object Request Broker) (Fig.1.3.4.2.1). Ad esempio un oggetto Client attraverso
ORB richiede ad un oggetto Server di effettuare certe operazioni (fra quelle pubblicate in
lingua IDL all’interfaccia del Server stesso , IDL = Interface Definition Language),
l’oggetto Server effettua le operazioni richieste ed invia attraverso ORB i risultati
all’oggetto Client che li aveva richiesti. Le operazioni all’interno dell’oggetto server
possono adottare un linguaggio di programmazione locale e.g. C++. Un esempio di sistema
computazionale “fortemente” distribuito è mostrato in Fig.1.4.4.1. La tecnologia CORBA
utilizzata per l’implementazione del modello ODMA da luogo alla tecnologia gestionale
ODMA/CORBA.
DETTAGLIO 1.3.4.2.2 La relazione Client –Server nell’architettura CORBA
In una architettura CORBA, un oggetto Client che richiede un servizio a un oggetto
Server non si deve affatto preoccupare di conoscerne i dettagli e.g. la sua locazione in
rete e il suo ambiente locale oppure i dettagli del protocollo di comunicazione adottato
in rete. dall’ORB. Il Client deve solo 1) conoscere il nome simbolico dell’operazione da
invocare e 2) ottenere dall’ORB il «riferimento all’oggetto» o IOR (Interoperable
Object Reference) cioè l’indirizzo in rete dell’oggetto su cui deve essere eseguita
l’operazione. Da parte sua il Server non conosce affatto i dettagli implementativi del
Client. Quello che il Server deve fare é effettuare l’operazione invocata cioè fornire il
servizio pubblicato sulla sua interfaccia e rinviare al Client il risultato dell’operazione.
Quindi, dal punto di vista del Client un oggetto Server é caratterizzato da : 1) IOR
che ne identifica l’ indirizzo in rete in modo univoco, 2) operazioni pubblicate sulla
sua interfaccia. In altre parole, il Client “vede” solo l’interfaccia del Server e il suo
IOR mentre l’ “implementazione dell’oggetto”, cioè i dati e il metodo necessari
all’esecuzione dell’operazione invocata espressi in linguaggio di programmazione
locale, non é a lui visibile. É la separazione fra interfaccia e implementazione
dell’oggetto Server cioé l’incapsulamento della implementazione dell’ oggetto Server,
reso possibile dalla metodologia orientata agli oggetti, l’essenza di CORBA.
Fintantoché l’interfaccia del Server non cambia, il Client può sempre ottenere i servizi
stipulati dal contratto Client-Server anche se il Server cambia il suo ambiente locale
e.g. linguaggio di programmazione. Del cambio di linguaggio di programmazione se ne
occupa la piattaforma CORBA non il Client.
•
Tecnologia OSI-SM
Open Systems Interconnection – System Management per la gestione reti-elementi di
rete (rettangoli gialli). Questo modello verà studiato nella parte II del corso. E’ una
specializzazione del modello di riferimento OSI-RM con applicazioni gesrtiuonali al
148
settimo livello della pila OSI. Il protocollo comunicativo è denominato CMIP e il
linguaggio degli oggetti gestiti è GDMO/ASN.1
•
Mappatura (Mapping) “RE – SB” (Reti/Engineering – Servizi/Business)
Ripetiamo: la interdisciplinarietà della Gestione TLC dipende dal fatto che i
Clienti richiedono l’esecuzione di flussi operativi end-to-end costituiti da una serie di
processi gestionali di natura diversa che implicano un accoppiamento fra gestione
servizi e gestione reti o viceversa. Questo accoppiamento richiede la mappatura,
mappatura RE (Reti/Engineering) – SB (Servizi/Business).fra un modello gestionale
generico per Reti TLC sviluppato in Ambiente Engineering (qui denominato Generic
Network Model, GNM, vedi Appendice 1 al Capitolo 2) e un modello gestionale per
Servizi TLC sviluppati in Ambiente Business (qui denominato Service Interaction
Model., SIM) . In fase di Product Development i modelli e la loro mappatura sono
sviluppati da un team di lavoro integrato con conoscenze interdisciplinari/competenze
professionali trasversali posizionate alla “zona di frontiera” Engineering-Business.
Oggetti CORBA
SERVICE DETAIL
RECORD MNGR
Modello Generico
Gestione Reti
(GNM)
Modello
Gestione
Servizi
(SIM)
SERVICE
ANALYSER
Connection
Detail Record
Billing
SERVICE
PROVIDER
Network
Resource
Provisionig
LoP
Service
Configuration
QoS
FAULT
MNGR
Network
Alarm
Fault
Report
Relationship Service
ORB
palla
Fig.1.3.4.2.1 RE-SB Mappers realizzati con tecnologia CORBA. Le applicazioni gestionali sono oggetti
CORBA relazionati dai servizi “Relationship Services” forniti dalla piattaforma CORBA. Le caratteristiche
gestionali della Rete TLC (rettangoli gialli) sono rappresentate nel Modello Generico Reti (GNM)
tecnologicamente neutro che interfaccia col Modello Servizi (Service Interction Model, SIM) dove sono
rappresentate le caratteristiche gestionali dei servizi TLC (rettangoli rossi). NOTA BENE. Per la gestione
servizi non sono necessarie informazioni specifiche delle tecnologie di rete (Vedi Appendice 1 al
Capitolo2)
149
La Fig.1.3.4.2.1 mostra esempi di mappatori RE-SB in un sistema gestionale
“fortemente distribuito implementato con tecniche DOC adottando la tecnologia
CORBA come piattaforma di integrazione. Supponiamo che i servizi TLC siano forniti
da una grande Rete costituta da una molteplicità di sottoreti mutuamente interconnesse.
rappresentata da un modello di rete generico GNM (Appendice 1 al Capitolo 2). Le
applicazioni RE/GNM contengono oggetti computazionali CORBA. Le applicazioni
SB/SIM contengono altri oggetti computazionali CORBA. Gli oggetti GNM e gli oggetti
SIM sono mutuamente relazionati dai servizi “Relationship Services” forniti dalla
piattaforma CORBA. Ad esempio in un customer service di “Service Provisionig” in cui
un Cliente richiede la installazione di una istanza di servizio TLC l’accoppiamento fra gli
applicativi “Service Configuration” e “Network Resource Provisionig” avviene attraverso
l’interazione fra oggetti CORBA GNM e SIM (Vedre Fig.1.3.4.2.2)
Ma non è tutto perché il modello di rete generico (tecnologi neutral) deve essere
specializzato in una serie di modelli specifici rappresentativi delle sotto reti reali
Mappatura
modelli
SIM e GNM
Oggetti CORBA
( GNM)
INTEGRATORE
TECNOLOGICO
Oggetti CORBA
(SIM)
Specializzazione
Manager OSI
(C++)
API
Pila OSI
Modello Rete Generico
CMIP
Pila OSI
Agente OSI
Modello ReteSpecifico
Fig. 1.3.4.2.2 Integratore tecnologico CORBA-OSI
150
•
Integratori tecnologici
La Fig.1.3.4.2.2 mostra un integratore tecnologico CORBA-OSI
La integrazione tecnologica “CORBA-OSI” è effettuata da integratori tecnologici
i.e. oggetti dedicati alla integrazione di tecnologie software diverse. Essi sono i ponti
di passaggio fra un ambiente gestionale CORBA e un ambiente gestionale OSI. Gli
integratori tecnologici sono oggetti CORBA sui quali possono essere invocate
operazioni di Manager OSI. Quindi un integratore ha due interfacce: un Manager OSI
al suo interno usa dal lato sud una interfaccia GDMO/ASN.1 (servizi CMIS e protocollo
CMIP) per comunicare con gli Agenti OSI che operano sulle MIB (base dati di oggetti
gestiti che modellizzano le risorse delle reti specifiche) mentre dal lato nord usa una
interfaccia IDL per comunicare con oggetti CORBA GNM che modellizzano una
gestione generica di rete. “Comunicare” significa che poiché un integratore ha una
interfaccia IDL, i suoi metodi (operazioni) possono essere invocati dagli altri oggetti
CORBA GNM secondo un paradigma Client-Server.
L’implementazione dell’integratore come “Manager OSI” usa un linguaggio di
programmazione opportuno (ad esempio C++) scelto dal programmatore e coinvolge i
seguenti passaggi:
1)
Mappatura di una operazione GNM (e.g. stabilire una connessione di
Super rete) in una serie di operazioni OSI su oggetti GDMO (Processo di
specializzazione) in accordo con le regole di astrazione usate nel processo
inverso di creazione del modello generico GNM a partire dai modelli
specifici.
2)
Utilizzazione dei servizi CMIS e del protocollo CMIP attraverso la pila
OSI per emettere richieste e ricevere risposte da agenti OSI. L’accesso alla
pila OSI viene effettuato attraverso una interfaccia di conversione API
(Application Programming Interface) e.g. del tipo C++/ASN.1. Per avere
più’ dettagli sull’API vedere “API architectures for netrwork management
applications” nel libro “Telecomunications Network Management” di
Haojin Wang, pag. 490 publicato da Mc Graw Hill, 1999.
Quindi gli integratori permettono di realizzare le funzioni di Manager OSI senza
farlo vedere all’ambiente CORBA cioé funzionano come “CORBA wrappers”
(“involucri CORBA”) che incapsulano l’ambiente OSI. Ovviamente la stessa tecnica
puo essere utilizzata per incapsulare anche altre tecnologie di gestione reti e.g. SNMP.
Inoltre la funzionalità del manager OSI é fatta su misura della tecnologia di rete che si
deve gestire. Quindi ci saranno integratori tecnologici fra CORBA e OSI per ATM, SDH,
Frame relay etc.
151
1.3.4.3 Esempio di mappatura QoS-LoP
L’ “attraversamento” da un tipo di gestione all’altro e.g. gestione servizi e gestione
reti, è realizzato in pratica tramite elementi di integrazione che effettuano una
mappatura fra i relativi modelli gestionali locali
Un esempio di mappatura fra modelli gestionali diversi è la mappatura fra i
parametri di servizio contenuti nel QoS di un servizio TLC (Quality of Service, in
Ambiente Business) e parametri prestazionali contenuti nel LoP delle reti abilitanti
(Level of Performance, in Ambiente Engineering). La mappatura avviene durante la fase
di “Performance Management” di un servizio TLC, in un integratore R-S denominato
Service Analizer in Fig.1.3.4.2.1) e può esprimersi analiticamente come segue:
Extraconoscenza Interdisciplinare
Sj = Fj (Pj1, Pj2, Pj3…..PjN)
Ambiente Engineering
Ambiente Business
Qui un parametro di servizio “Sj” (j=1, 2, 3…..M) è una funzione Fj di una molteplicità
di parametri prestazionali di rete “Pji” (i=1,2….N) (mappatura 1:N).(vedi anche:
L.Lewis. “Service Level Management for Enterprise Networks”, Artech House, 1999, p.
186 e G.Chen & Q.Kong, “Integrat Telecommunications Management Solutions”, IEEE
Press, 2000, Cap.10]. L’argomento della mappatura QoS-LoP verrà ripreso nel Capitolo 2
par.2.7.5.
1.3.4.4
Esempi di “RE-SB Mappers” (Fig.1.3.3.5)
Esempi di “mappatoro RE-SB” che maapano una operazione a livello servizi in
una a livello rete generica sono riportati nella la Fig.1.3.3.5, adattata da “G. Chen &
Q.Kong, “Integrated Telecommunications Management Solutions”, IEEE Press, 2000”.
Il testo di G.Chen e Q,Kong è uno dei pochi testi dove questi argomenti vengono trattati
in grande dettaglio.
•
Modelli gestionali locali
La Fig.1.3.3.5 mostra la natura dell’ integrazione fra tre modelli gestionali locali
rispettivamente relativi a servizi, reti e elementi di rete, SIM (Service Interaction
Model), GNM (Generic Network Model). OSI-SM (Open Systems InterconnectionSystem Management) rispettivamente indicati con rettangoli di colore bianco, nocciola,
giallo. I primi due sono modelli proposti da G.Chen e Q.Kong mentre il terzo è uno
standard ITU-T già descritto. I modelli locali adottati sono
152
Fig.1.3.3.4 Flusso operativo end-to-end “Service Order” (Modello e-TOM). Notare il riuso di sette building
blocks corrispondenti ai processi operativi di Fig.1.4.3.3 (rettangoli gialli). Le frecce verdi che puntano verso
destra indicano dati in entrata e le frecce rosse che puntano verso dati in uscita. Notare l’attraversamento di
quattro strati gestionali (“swimlane representation”). I singoli processi si articolano a loro volta in una serie di
sottoprocessi ed è al loro interno che si nascondono gli elementi di integrazione (e.g. vedi Fig.1.4.3.6 per il
processo “Service Configuration”)
mmmmmmmmmmmmmmmmmmmmmm
153
1. modello SIM, Service Interaction Model, per la gestione servizi, (rettangoli bianchi)
Rappresenta le gestione servizi come una rete di processi operativi mutuamente
interagenti (a loro volta suddivisi in sottoprocessi non mostrati in Fig.1.3.3.5) da
utilizzare in flussi operativi end – to - end. I processi individuati da Chen & Kong sono
classificati diversamente da quelli del modello e-TOM e sono indicati come PHM
(Problem Handling Manager) per la gestione reclami, PM (Performance Manager) per la
gestione della Quality of Service (QoS), SM (Service Manager) per la gestione delle
configurazioni/ riconfigurazioni servizi, B (Billing Manager) per la gestione della
fatturazione e SLAM (Service Level Agreement Manager) per la gestione dei Service
Level Agreements. Ogni processo si articola poi in una serie di sottoprocessi. Questo
modello è implementato con una tecnologia CORBA
2. modello GNM, Generic Network Model per la gestione reti (rettangoli nocciola) ma
adatto a integrarsi con il modello servizi SIM. Infatti fornisce una rappresentazione
esterna end-to-end di una rete TLC al Fornitore Servizi (strato superiore) “nascondendo”
(information hiding) ad esso i dettagli interni della rete (che non lo interessano). Questo
modello è descritto nella Appendice 1 al Capitolo 2. Adotta l’architettura
ODMA/CORBA. Il linguaggio descrittivo degli oggetti è IDL e il protocollo
comunicativo nell’ORB è denominato IOOP
I rettangoli a due colori rappresentano gli elementi di integrazione dove avviene la
mappatura fra modelli gestionali.
In questo caso i processi operativi appartengono a quattro aree funzionali indicate
con le lettere F (Fault, Guasti) , C (Configuration, Configurazione), P (Performance,
Prestazioni), A (Administration, Amministrazione) corrispondenti alle aree funzionali
Fault, Performance, Configuration. Accounting dello standard “FCAPS” dell ITU-T
(Vedi dopo).
Il significato degli acronimi usati per gli altri processi è il seguente: NFM =
Network Fault Manager, NA = Network Analizer, SA = Service Analizer, NC = Network
Configuration, SC = Service Configuration, CDR = Connection Detail Record, SDR =
Service Detail Record, SLAM = Service Level Agreement Manager.
•
Elementi di integrazione R-S (rettangoli bianchi e rosa in Fig.1.3.3.5)
Gli integratori R-S fra General Network Model (GNM) e Service Interaction Model
(SIM) sono,
1. FM (Fault Manager), mappa un “allarme” generato da un guasto in una rete
tecnologicamente specifica come un “Event Report” (OSI) in un oggetto SIM “Rapporto
Guasti” (CORBA) grazie a un integratore tecnologico OSI-CORBA (NFM in figura)
Viceversa mappa una “segnalazione guasto” effettuata dall’ Utente a livello servizi
(modello SIM) e proveniente dal livello Customer Relation Management (CRM) nella
“localizzazione/diagnosi guasti” a livello rete generica (modello GNM) e poi a livello
rete specifica/elemento di rete (modello OSI-SM). É quindi un integratore GNM/SIM.
154
Notare come un guasto (fault) / malfunzionamento (trouble) denunciato da un Utente
attraverso CRM (contesto Business) non può essere riparato se il guasto a livello
rete/elemento di rete non viene identificato/ localizzato/riparato (contesto Engineering).
Come pure, in senso inverso, la fornitura all’Utente di una allerta di malfunzionamento
(contesto Business) causata dall’ emissione di un segnale di allarme da parte di un
elemento di rete (contesto Engineering), non è possibile se non esiste un integratore
GNM-SIM. La “mappatura” fra oggetti GNM e oggetti SIM avviene tramite un
“Relationship Service” fornito dalla piattaforma di integrazione (e.g. CORBA) come
mostrato in Fig.1.3.4.2.1
NOTA BENE. Ricordare che un “allarme” è la rappresentazione di un malfunzionamento/ guasto
incipiente secondo un format prestabilito)
2. SA (Service Analyser, Analizzatore Servizi), riceve i dati misurati dall’Analizzatore
di Rete (Network Analyser, NA) relativi ai “parametri prestazionali di rete” (il cui
insieme determina il Level of Performance, LoP, della rete) e ne effettua la mappatura
nei dati relativi ai “parametri di servizio” che definiscono la QoS (Quality of Service)
erogata. E’ qui che avviene la mappatura LoP-QoS studiata nel Capitolo 2. É quindi un
integratore GNM-SIM. Nell’ ambito della gestione della performance di sistemi e servizi
TLC, la gestione della QoS i.e. la supervisione/misura/controllo di “parametri di servizio”
specificati nei contratti SLA (gestione servizi) necessita la gestione congiunta del LoP
della rete i.e. supervisione/misura/controllo di “parametri prestazionali di rete” (gestione
rete) la quale a sua volta richiede la gestione dei singoli elementi di rete tramite gli
Operations Systems, OS (Sistemi di Esercizio) attestati sui singoli elementi.
3. SC (Service Configuration), mappa le richieste di installazione servizi TLC
provenienti dal Service Manager in richieste di connessioni a livello rete. É quindi un
integratore SIM-GNM.
4. SDR (Service data record), mappa i dati CDR (Connection Detail Record) relativi ai
consumi misurati nei “Data Collection Points” in dati relativi all’utilizzazione dei servizi.
É un quindi integratore GNM/SIM.
Nell’ambito della contabilità (accounting) dei servizi TLC, la fatturazione (billing) &
raccolta/riscontro pagamenti (payment collection) di un servizio TLC è possibile solo
se sono disponibili
i)
i dati dei consumi misurati in rete sottoforma di CDR, Connection Detail
Records (gestione rete),
ii)
le tariffe, sconti e promozioni specificati nell’ambito di una “strategia dei
prezzi” definita a livello di Top Management (gestione d’impresa) e
iii)
le modalità di addebito stipulate in contratti SLA, Service Level
Agreement, con i singoli clienti (Customer Relation Management, CRM)
iv)
canali di raccolta pagamenti
155
Service Provider A
Service Provider B
Service Management Environment
Service Management Environment
Service Access Interface
F*
P
H
M
P*
C*
A*
SM
B
Service Access Interface
B
SM
PM
PM
SLAM
FM
NFM
SLAM
SA
SC
SDR
SDR
SC
SA
NA
NC
CDR
CDR
CDR
NC
NC
NA
Network Management Environment
SIM
GNM
P
H
M
OSI
FM
NFM
Network Management Environment
P. interazione
P. mappatura
Fig.1.3.3.5 Architettura integrata gestione servizi-gestione rete (Service Interaction Model, SIM). (*) Dal modello FCAPS.
156
P. cooperazione
ESERCIZIO. La specifica/progettazione/standardizzazione di un processo gestionale end-to-end
(i.e. dalla gestione “Elemento di Rete” fino alla gestione “Relazioni Clienti”) richiede competenze
professionali trasversali (e.g. team di lavoro integrato di esperti Engineerng e Business)
1.4
i)
Spiegare cosa sono i processi gestionali end-to-end nell’ambito dei processi aziendali
(business processes) di una TelCo
ii)
Scegliere un processo gestionale end-to-end e dimostrare che esso è di natura
interdisciplinare (e.g. descrivendo il corrispondente integratore BusinessEngineering)
La storia della “Gestione TLC” non si ripete:
da “bottom up” (1968) a “top-down” (2008).
Per capire meglio la natura interdisciplinare del corso introduciamo una nota
storica che evidenzia l’evoluzione progressiva delle attività gestionali nel campo delle TLC
che dopo quaranta anni è risultata nel 2008 in una completa inversione di tendenza: dalla
gestione di elementi di rete e reti (“bottom-up” o “resource centric”) alla gestione integrata
“Gestione TLC”, con la G maiuscola, atta a soddisfare gli obiettivi di business di una TelCo
(“top-down” o “customer centric”) (Vedi Fig.1.1.2.7.1A).
1.4.1
La gestione delle risorse tecnologiche: rete TLC e suoi elementi
1.4.1.1
Gli inizi: telemetria proprietaria
A metà novecento la gestione delle reti TLC è iniziata come una forma di
telemetria in cui i singoli elementi di una rete TLC , dotati di scarsa “intelligenza”
gestionale (i.e. scarsa abilità computazionale di processo e modesta capacità di
memorizzazione dati), inviavano/ricevevano un flusso continuo di dati gestionali a/da una
postazione centrale di supervisione (“dati in”) e controllo (“dati out”). In questa postazione
risiedevano gli addetti alla gestione (gestore centrale). Solo vent’anni dopo, cioè negli anni
70, l’ “intelligenza” gestionale cominciò a migrare dal gestore centrale verso la periferia
della rete telemetrica dove si trovavano gli elementi gestiti, i quali gradualmente divennero
più intelligenti grazie allo sviluppo delle tecnologie IT commercialmente disponibili e alla
riduzione dei loro costi. Uno studio sistematico della migrazione della “gestione intelligente”
verso la periferia degli elementi di reti TLC cominciò all’inizio anni sessanta. (vedi:
R.Saracco, “La Gestione della Rete di Telecomunicazione”)
Inizialmente il contributo manuale cioè la partecipazione diretta dell’uomo alla
gestione delle apparecchiature/equipaggiamento di rete in fase operativa (e.g. supervisione e
controllo del funzionamento) era notevole. Corrispondentemente il livello di automazione
cioè il contributo delle tecnologie digitali era molto modesto. La creazione di standards
tecnici relativi alle tecnologie gestionali era in una fase iniziale di sviluppo e le tecnologie
gestionali erano prodotte su iniziativa di industrie manifatturiere specializzate su base
“proprietaria” creando così problemi di compatibilità/interoperabilità fra tecnologie
gestionali prodotte da industrie manifatturiere diverse ma installate in uno stesso sistema
157
TLC.
Questi problemi di interoperabilità eterogenea stimolarono iniziative di
standardizzazione da parte di enti nazionali e internazionali (standardizzazione “de jure”).
L’introduzione dei primi standards gestionali de jure OSI-SM (Open Systems
Interconnection – System Management) da parte dell’ITU-T, specializzazione del modello
di riferimento OSI-RM (Open Systems Interconnection – Reference Model) alla gestione di
reti TLC e loro elementi, rappresentò un notevole passo avanti nella “gestione aperta” delle
reti TLC (Vedi Parte 2 del corso).
1.4.1.2
Paradigma “Gestore-Agente” e primi standards gestionali dell’ ITU-T
I primi standard gestionali OSI-SM dell’ITU-T e, per le reti internet, gli standards
SNMP v.1 (Simple Network Management Protocol versione 1) operavano secondo un
paradigma “Gestore-Agente” (Manager-Agent). (Vedi Fig.1.4.1.2.1 e Fig.1.4.1.2.2) Le
tecnologie gestionali degli elementi di rete (denominate OS, Operations Systems, Sistemi di
Esercizio), erano caratterizzate da applicazioni gestionali (System Management Application
Entities, SMAE) “Agenti” (Agent) attestate sugli elementi stessi le quali scambiavano dati
gestionali con applicazioni SMAE “Gestore” (Manager) centralizzate, tramite una rete dati
(Data Communication Network).
Fig.1.4.1.2.1 Il paradigma “Gestore-Agente”
SISTEMA DI GESTIONE (OSI-SM)
Sistema Gestore
S
A
M
E
G
E
S
T
O
R
E
PROTOCOLLO
CMIP
Sistema Gestito
MIB
S
A
M
E
S
I
S
T
E
M
A
OPER.
OPER.
NOTIFICA
EVENTO
A
G
E
N
T
E
NOTIF.
Astrazione
OGGETTI
GESTITI
T
L
C
RISORSE
GESTITE
PdS
158
SIMPLE SWITCH
(switchId)
RS
CENTRAL
PROCESSING
CARD (HW)
(cardId)
RS
1. Rete di
Utilizzazione
COMPUTING
MODULE (SW)
(computingModule Id)
Back-up Unit
CENTRAL
PROCESSING
CARD (HW)
(cardId)
2. Rete di
Segnalazione
M
A
N
A
G
E
R
Unità
Controllo
3. Rete Dati
Gestionali
COMPUTING
MODULE (SW)
(computingModule Id)
Unità
Controllo
MIB
AGENT
Mondo TLC
Fig.1.4.1.2.2 Le aree gialle rappresentano un sistema gestionale attestato su un commutatore
(Switch) 1:3 realizzato assemblando moduli software (Unità di Controllo, Computing
Module) e hardware (Matrice di Commutazione, Central Processing Card) e Switch
di Ridondanza (RS). Se l’unità principale (sopra) si guasta l’unità di back-up (sotto)
la rimpiazza tramite attivazione degli switch di ridondanza. MIB (Management Information
Base) = Base Dati che contiene le rappresentazioni gestionali (Oggetti Gestiti) delle tecnologie
da gestire. Per la rappresentazione degli Oggetti Gestiti nella MIB vedere Appendice 2 al Cap.1
Gli aspetti architetturali delle reti di gestione basate sul paradigma Gestore-Agente
furono poi standardizzati negli standards TMN (Telecommunications Management
Network) suddivisi in quattro architetture: fisica, logica, funzionale e a “strati logici” (logic
layers). Il modello TMN “a strati logici” o Layered TMN Model, è considerato il
progenitore di tutti i susseguenti modelli gestionali. (Vedi Fig.1.4.1.2.3) Gli strati logici
corrispondevano alla gestione di elementi di rete, reti, servizi e impresa (business). La
struttura gerarchica degli strati è discussa in dettaglio nel Capitolo 3 della Parte 1 e nella
seconda parte del corso.
1.4.1.3
Decentralizzazione del Gestore: distribuzione debole
Nonostante la graduale migrazione dell’intelligenza gestionale verso la periferia della
rete di gestione (TMN), a fine anni 60 il costo dell’ elaborazione e memorizzazione
dell’informazione era ancora molto elevato e questo giustificava la scelta di un gran numero
di “dumb Agents” a livello locale cioé “agenti poco intelligenti” collegati ad un
“Manager” centrale nel quale era ancora concentrata gran parte dell’intelligenza di tutto il
159
sistema gestionale. Negli anni settanta le cose cominciarona a cambiare e le architetture
gestionali ad assumere una nuova fisionomia. Infatti con la espansione delle reti TLC e la
proliferazione dei nodi di rete da gestire e l’aumento delle tipologie di servizi offerti, cioè
con l’aumentare della complessità di reti e servizi TLC da gestire, assieme alla riduzione dei
costi delle tecnologie digitali, la funzione di “Manager” venne gradualmente decentralizzata
e (“debolmente”) distribuita in una molteplicità di “componenti gestore” ubicati nei nodi di
reti gestionali meshate con architetture multi-gestore multi-ruolo di natura gerarchica (i.e.
“Manager of Managers”) o di natura cooperativa peer-to-peer (cooperazione fra menagers
con uno stesso livello di responsabilità gestionale). Diverse applicazioni gestore, mutuamente
interconnesse, erano dedicate a domini tecnologici e/o amministrativi diversi. Questo portò
ad un notevole miglioramento della scalabilità e affidabilità (reliability) del sistema
gestionale (NOTA BENE: Noi useremo “Rete di Gestione” e “Sistema Gestionale”
interscambiabilmente).
AMMINISTRAZIONE
GUASTI
PRESTAZIONI
CONFIGURAZIONE
Modello funzionale
SICUREZZA
FCAPS
Modello
logico
stratificato
GESTIONE BUSINESS
GESTIONE SERVIZI
GESTIONE RETI
Modello organizzativo
A. GERARCHICA
GESTIONE ELEMENTI RETE
A. COOPERATIVA
ELEMENTI RETE
A. CENTRALIZZATA
Fig.1.4.1.2.3. Modello TMN stratificato (strati orizzontali) combinato col modello funzionale FCAPS (strisce
verticali), entrambi dell’ITU-T (Vedi capitolo 3)
NOTA BENE: L’argomento della distribuzione “debole” e “forte” dei sistemi gestionali verrà
ampiamente discusso nel corso delle lezioni. Vedere anche par. 3.6 nel Cap.3 e Appendice 1 alla Parte 1.
160
A fine anni settanta la funzione di gestione si andava estendendo dalla “supervisione e
controllo” del singolo elemento di rete (effettuata con un sistema OS fornito dall’industria
manifatturiera assieme all’elemento di rete) al funzionamento end-to-end della rete (cioè da
terminale a terminale). A differenza dei sistemi OS preconfezionati da imprese ICTS con
tecnologie spesso proprietarie, l’implementazione della gestione della rete cominciava ad
essere responsabilità della TelCo (cioè del Fornitore di Servizi TLC) e aveva talvolta un
carattere “technology neutral” (e quindi “future proof”) cioé la gestione era tesa a garantire
una certa prestazione di rete indipendentemente dalle particolari tecnologie abilitanti
(adozione di modelli gestionali di rete “generici”). [Vedi: L.G.Raman, “Fundamentals of
Telecommunications Network Management”, IEEE Press, 1999]. La gestione delle reti, con
dati di ingresso provenienti dalla gestione degli elementi di rete, veniva effettuata con grossi
elaboratori digitali e opportune applicazioni gestionali assieme a database per
immagazzinamento dei dati (NSS di processo e NSS dati) laddove NSS = Network Support
Systems. Per avere un idea di cosa fossero le funzioni gestionali svolte dai sistemi NSS basta
pensare alle seguenti attività: “approvigionamento/allocazione delle risorse di rete”,
“risoluzione di problemi di malfunzionamento e riparazione guasti in rete, “raccolta dati
relativi ai consumi da inviare ai processi di fatturazione” etc.
1.4.2 La gestione dei servizi TLC
Mentre la gestione di rete cominciò con dati telemetrici inviati autonomamente dagli
elementi di rete a un gestore centrale, la gestione servizi fu condotta dal gestore/fornitore di
servizi sin dall’inizio. Infatti iniziò nel momento in cui la TelCo cominciò ad
offrire/fornire/erogare servizi TLC a comunità di Utenti. Inizialmente le TelCo erano
monopolisti ai quali lo stato affidava in esclusiva per un certo territorio la fornitura dei
servizi TLC, i prezzi erano fissi e la concorrenza fra imprese TelCo non esisteva. I servizi
erano prodotti preconfezionati che le TelCo offrivano in attività di vendita e che gli Utenti
potevano scegliere da catalogo. E’ solo all’inizio anni ottanta che le prime forme di
liberalizzazione dei mercati cominciarono a prendere forma (la fine del monopolio ATT negli
USA è del 1984, vedi Appendice 1 al Capitolo 1) i prezzi cominciarono ad essere determinati
dal mercato e gli Utenti cominciarono ad assumere un ruolo sempre più attivo nell’ambito di
attività di marketing svolte dalle TelCo (Vedi Appendice 7 al Capitolo 1).
SPIEGAZIONE (nozioni da portare all’esame) Il “marketing” è una attività svolta
in maniera proattiva dalla TelCo ed è tipica di un mercato libero dove più fornitori
forniscono servizi equivalenti e competono per la conquista degli stessi Clienti. In un
mercato monopolista il Cliente prende “quello che passa il convento” ad un prezzo
prefissato indipendentemente dal fatto che il servizio acquisito soddisfi più o meno bene
le sue esigenze cioè se il servizio costituisca per lui un “valore”. Quindi il marketing ha
un significato solo se si è in presenza di una economia libera di mercato e il risultato del
“marketing” è la creazione di Clienti tramite l’offerta di servizi TLC sviluppati partendo
dai desideri/bisogni dei Clienti stessi e in modo tale da vincere la concorrenza. In altre
parole il “marketing” può considerarsi una attività opposta alla “vendita” nel senso che il
marketing parte da una risposta alla domanda “Il Cliente cosa vuole comprare”?
piuttosto che alla domanda “Cosa vogliamo vendere al cliente?” Assieme alle attività di
marketing, le attività di “innovazione” sono essenziali perché una impresa possa battere
la concorrenza e prosperare in un libero mercato. (Ulteriori dettagli in Appendice 7 al
Capitolo 1).
161
Con il progressivo sviluppo delle attività di marketing e col contributo crescente degli
Utenti nella gestione dei servizi TLC, la gestione servizi all’interno della TelCo si sdoppiò in
attività relative allo sviluppo/operazioni di classi di servizi (processi interni di Gestione
Servizi, Service Management) e attività relative alla gestione delle Relazioni Clienti
Customer Relation Management (processi esterni con la partecipazione dei singoli
Clienti).
Dal punto di vista tecnologico le TelCo cominciarono ad automatizzare i relativi
processi di business con elaboratori gestionali (elaboratori digitali su cui giravano
applicazioni gestionali) e database gestionali dedicati ai vari processi (OSS di processo e
OSS dati, OSS = Operation Support Systems, Sistemi di Supporto alle Operatività).
Tuttavia sin dall’inizio si riconobbe che i servizi non potevano essere gestiti
indipendentemente dalle reti e che quindi era importante stabilire una relazione, anche a
livello tecnologico, fra questi due tipi di gestione.
1.4.2.1
I modelli gestionali processuali: integrazione gestione reti-servizi, relazioni
clienti e relazioni con altre imprese partners e suppliers
All’inizio anni 90 le TelCo e, come al solito con grande ritardo, gli enti di
standardizzazione cominciarono a riconoscere che per motivi di efficacia/efficienza
sostenibile nel tempo e in presenza di mercati TLC evolutivi era necessario passare a modelli
gestionali processuali, cosidetti “top-down”, che partendo dagli obiettivi di business dei
gestori TelCo specificassero i processi di business necessari a raggiungerli. E questo veniva
fatto compatibilmente (non in contrasto) con i precedenti modelli gestionali, cosidetti
“bottom-up”, che partendo dalle reti e loro elementi avevano specificato funzioni & servizi
gestionali (Management Functions & Services) necessari a fornire/erogare i servizi TLC
desiderati (e.g. sottomodello funzionale FCAPS parte del modello “TMN” dell’ITU-T, vedi
Racc. M.3400 e M.3010 dell’ITU-T). Inoltre le stesse esigenze di business in presenza di
mercati TLC e tecnologie ICT in rapida evoluzione imponevano sempre più la automazione
& integrazione dei “processi interni” di gestione reti e servizi con 1) “processi esterni”
relativi alla gestione personalizzata e partecipativa dei singoli Clienti (Customer Relation
Management, CRM) e 2) “processi esterni” relativi alla gestione delle relazioni con TelCo
partner e fornitori di tecnologie ICT (“suppliers”, vedi Fig.1.4.2.1.1)
La necessità di integrare i vari tipi di gestione al fine di soddisfare certe esigenze dei
Clienti e conseguire certi obiettivi di business delle TelCo favorì lo sviluppo delle
corrispondenti tecnologie gestionali integrate finalizzate a realizzare flussi operativi end-toend (vedi par.1.1). Un flusso operativo end-to –end è un flusso di processi operativi che
abbraccia tutto l’arco delle gestioni “Cliente-Servizi-Tecnologie” attraverso aree gestionali
diverse e che implementa gli obiettivi di business o loro parti e.g. ordinazione di un servizio
TLC (“Service Ordering”), segnalazione anomalie/riparazione guasti (“Problem Handling”),
monitoraggio QoS di un servizio TLC, tariffazione/addebiti/fatturazione/ riscontro pagamenti
di un servizio TLC (“Billing”) etc.
162
e - TOM: Level 1 views
GESTIONE OPERAZIONI
GESTIONE SIP
k=1
k=2
Strategie
Gestione
CdV
Infrastrutture
k=3
k= 1
Supporto
Operaz . &
Readiness
Gestione
CdV
Prodotti
k=2
k=3
Fullfilment
j =1 Gestione Relazioni Clienti (CRM)
j = 2 Sviluppo Servizi
j = 2 Gestione & Operazioni Servizi
j = 3 Sviluppo Risorse
j = 3 Gestione & Operazioni Risorse
Supply Chain
k=1
j = 4 Gestione Relazioni Fornitori e
Partners
k= 3
k=4
k= 2
Enterprtise
Effectiveness
Mngmt
j=1
Strategic & Enterprise
Planning
Enterprise Risk
Mngmt
j=2
Financial & Asset
Management
Stakeholder &
Ext . Relation Mngmt
Fatturaz
.
j = 1 Gestione Marketing
j = 4 Sviluppo
k=4
Assurance
Human Resources
Mngmt
Knowledge &
Research Mngmt
GESTIONE
IMPRESA
Fig.1.4.2.1.1 Gruppi di processi all’interno di una impresa TelCo (Livello 1 modello “e-TOM”, TeleManagement Forum). I processi emergono al livello successivo (livello 2) come mostrato in Appendice 3
al Cap.1.
163
Process Flow
Process Definition
Tool
Process Models
BAC
BAC
BAC
BAC
Communications Technology Services
Process Flow
Engine
FSC
FSC
NGOSS Framework
FSC
FSC
Repository
BAC = Business Aware Component
FSC = Framework Service Component
schema
Fig.1.4.4.1 Architettura NGOSS (Next Generation Operation Systems and Software) del
TeleManagement Forum. Il bus logico di comunicazione (ORB nella terminologia CORBA)
su cui si affacciano tutti gli applicativi gestionali permette di interconnetterli (attraverso una
richiesta servizi-fornitura dei risultati) con un unica interfaccia per componente. Ogni applicazione
gestionale registra il suo nome e i suoi servizi con il “Repository” che fornisce servizi di “pagine
gialle” agli applicativi che ne fanno richiesta (in inglese si dice che svolge “Trading functions”)
La piattaforma offre servizi di integrazione e.g. transazionalità, autenticazione, logging
(funzionalità offerte dal sistema di cui il progettista utilizzatore non si deve fare carico) tramite i
componenti FSC (Framework Service Component)
Abbiamo visto che è proprio la natura interdisciplinare dei flussi operativi end-to-end
che determina in fase di “sviluppo di prodotto”,
1) la necessità di conoscenze e competenze professionali interdisciplinari
2) la necessità, a livello operativo, di creare all’interno delle TelCo o degli enti di
standardizzazione, teams di lavoro di natura interdisciplinare (almeno BusinessEngineering).
In entrambi i casi si tratta di far cooperare ingegneri e esperti nel business TLC cioè si
tratta di integrare professionisti con concezioni diverse di “gestione” delle TLC. Un esempio
tipico di attività interdisciplinare Business-Engineering da parte di un ente di
164
standardizzazione è la iniziativa NGOSS (Next Generation Operation Systems and Software)
del consorzio internazionale TeleManagement Forum.
1.4.3
La Gestione con la G maiuscola
La tendenza delle TelCo di integrare modelli/tecnologie gestionali diverse in strutture
altamente automatizzate è continuata nel tempo. A livello tecnologico si è sviluppata una
integrazione ottenuta aggregando applicativi gestionali standardizzati e facilmente reperibili
sul mercato (software COTS, Commercial Off The Shelf software), in maniera da ridurre i
costi e i tempi legati al numero di interventi manuali. A fine anni 90 - inizio 2000 la base di
integrazione si è estesa fino a comprendere tutti i domini gestionali all’interno dell’ impresa
TelCo, includendo parte dei processi di “gestione di impresa” [Vedi G.Chen & Q.Kong,
“Integrated Telecommunications Management Solutions”, IEEE Press, 2000, Capitoli 10 e
11] ma ad esclusione dei processi di competenza del Senior Management (non si può
automatizzare il CEO di un impresa! gli si possono solo fornire tecnologie di supporto in fase
decisionale). L’integrazione fra gestioni locali diverse al fine di ottenere una performance
socio-economica-ambientale sostenibile per la TelCo ha portato a parlare di una attività di
gestione unica all’interno di una TelCo denominata “Gestione TLC” con la G maiuscola
(vedi par.1.1.1.7). Da un punto di vista processuale la Gestione TLC viene implementata
integrando i vari processi in flussi di processi operativi end-to-end che utilizzano
componenti standardizzati (Vedere anche Appendice 3 al Cap.1). Ma vediamo in dettaglio
quest’ultimo punto!
1.4.4 Tecnologie gestionali DOC (Distributed Object Computing)
La tendenza verso una integrazione sempre più spinta sia a livello di
analisi/progettazione di sistema che a livello di implementazione tecnologica è stata
incentivata e ancor oggi supportata dal progresso nel campo delle tecnologie informatiche
distribuite DOC (Distributed Object Computing).
NOTA 1.4.4.1 “SISTEMA GESTIONALE DISTRIBUITO”. Un sistema gestionale distribuito é un
sistema costituito da componenti applicativi autonomi, residenti in nodi elaborativi remoti interconnessi
da una rete di comunicazione dati, che cooperano in un contesto di elaborazione virtualmente unitario.
(Vedi Appendice 1 alla Parte 1 e par.3.6 del Capitolo 3))
Un esempio di queste tecnologie (denominate anche “middleware” perché interposte
fra software applicativo e l’ hardware del processore, vedi Fig. 3.3.4.2 nel Cap.3) è la
tecnologia CORBA (Common Object Request Broker Architecture) sviluppata dal consorzio
OMG (Object Management Group) creato nel 1989 con lo scopo di sviluppare standards per
promuovere lo sviluppo di applicazioni a oggetti “fortemente” distribuiti (vedi dettagli nella
Addendum No.2 per CORBA e Addendum No.4 per la programmazione a oggetti). Le
tecnologie informatiche “middleware” permettono la realizzazione di sistemi gestionali
“fortemente” distribuiti, secondo i principi enunciati dall’ITU-T nel modello di riferimento
ODP-RM (Open Distributed Processing – Reference Model). (vedi anche “Reference
Model for Open Distributed Processing”, ITU-T Recommendation X.901, 1997).
165
Si può riconoscere un parallelismo fra il binomio “modello di riferimento OSI-RM e
sistemi gestionali OSI-SM” e il binomio “modello di riferimento ODP-RM e sistemi
gestionali fortemente distribuiti”.
In base alla precedente NOTA 1.4.4.1 riconosciamo che in un sistema gestionale
“fortemente” distribuito il middleware si fa carico di risolvere i numerosi problemi di
distribuzione in modo tale che il programmatore o l’utilizzatore del sistema possa operare in
un contesto virtualmente unitario (i.e. non-distribuito). In particolare in un sistema
fortemente distribuito un comune bus logico di comunicazione (ORB nella tecnologia
CORBA) e servizi di registrazione (servizi di pagine gialle) permettono rispettivamente di
ottenere due risultati importanti
1) ridurre il numero di interfacce fra applicativi gestionali diversi (i.e. ogni componente
presenta una sola interfaccia verso il bus logico) (vedi nota 1.4.4.2 qui sotto)
2) integrare i vari applicativi gestionali in modalità “loosely coupled” aprendo così la
strada a sistemi gestionali tipo “Plug & Play” con componenti applicativi COTS
commercialmente disponibili.
NOTA 1.4.4.2 INTERFACCE COSTOSE!
E’ dimostrato che lo sviluppo/manutenzione delle interfacce fra componenti software sia responsabile di
una grossa parte del costo di acquisizione e esercizio di un sistema gestionale distribuito. Senza un
middleware con un comune bus logico di comunicazione (i.e. ORB nel linguaggio CORBA), un sistema
gestionale con “n” componenti mutuamente interconnessi richiede “n(n-1)” interconnessioni, cioè il
numero di interconnessioni è proporzionale al quadrato del numero dei componenti.
Riportiamo qui di seguito un esempio pratico che dovrebbe chiarire quanto detto sinora.
ESEMPIO 1.4.4.1 Tecnologie gestionali distribuite: il framework NGOSS del Tele Management Forum
(Fig.1.4.4.1)
La Fig. 1.4.4.1 mostra la architettura di alto livello “technology neutral”
(Technology Neutral Architecture, TNA) di un sistema gestionale distribuito
sviluppato negli ultimi anni dal TeleManagement Forum e denominato “NGOSS
Framework”
(“piattaforma NGOSS”, pronunciato “en-goss”) sviluppato
nell’ambito della iniziativa di standardizzazione denominata NGOSS (Next
Generation Operations Systems and Software). In essa si nota una tecnologia di
comunicazione comune tipo bus logico (in figura indicata come fornitrice di
Communications Technology Services) su cui si affacciano, con una interfaccia tipo
API per componente (“contract interface”), i vari componenti applicativi da
integrare, denominati Business Aware Components (BAC). Ogni componente BAC
esegue un flusso operativo end-to-end finalizzato al conseguimento di un customer
service teso alla implementazione di certi obiettivi di business prefissati (e.g.
“service provisioning” i.e. installazione e assegnazione di un servizio TLC
conseguente ad una richiesta di un Cliente, SLA/QoS Monitoring, Problem
Handling, Service Billing etc. vedi anche par. 1.1.1). Il nome “Business Aware
Component” deriva proprio dal fatto che ogni componente BAC abilita la
realizzazione di uno specifico obiettivo di business fissato dalla TelCo in fase di
pianificazione strategica. Come già detto, “end-to-end” significa che il flusso di
processi comprende tutti i processi necessari e sufficienti affinchè il flusso
166
raggiunga pienamente il suo scopo programmato e.g. realizzazione completa di un
customer service.
Le attività dei vari componenti BAC sono schedulate e registrate da un
controllore di workflow (“Process Flow Engine”) programmabile grazie a un
“Process Definition Tool”. Quando un componente BAC ha completato la sua
esecuzione il controllo è restituito al controllore che lo passa al componente
successivo secondo una logica stabilita a priori in base al Business Plan della TelCo.
In questo modo anche se le componenti applicative sono distribuite nel sistema,
esiste sempre un controllo centralizzato da cui si può conoscere in tempo reale quale
di esse è in fase di esecuzione.
Nella Fig. 1.4.4.1 si nota anche un Repository, dove i vari componenti BAC
appena installati nel sistema registrano il proprio indirizzo e i servizi da loro offerti.
Si tratta di un elemento che offre un “servizio di registrazione” del tipo “pagine
gialle”. Ogni BAC bisognoso di un servizio non è necessario conosca direttamente il
componente applicativo che può eseguirlo, basta che si rivolga al Repository: il
Repository stesso si fa carico di trovare il componente “server” in grado di fornire il
servizio richiesto e poi fornire le relative informazione al richiedente. L’ applicativo
richiedente così può collegarsi (“bind”) con il server indicato e invocare il servizio
desiderato (processo di “find-bind-execute”). Quindi i vari componenti non sono
accoppiati rigidamente l’un l’altro ma indirettamente attraverso il Repository e
interagiscono attraverso un meccanismo di richiesta/fornitura remota di servizi
(Service Oriented Architecture, SOA) (Vedi ITU-T Recom. ITU-T 3060/Y.2401,
“Principles for the Management of Next Generation Networks”, 03/2006, pag.15). Si
stabilisce così un loose coupling (basso accoppiamento) fra applicativi richiedenti e
applicativi fornitori di servizi. “Loose coupling” significa che un applicativo può
essere modificato senza che questa modifica influenzi gli altri applicativi nel sistema.
La filsofia della distribuzione “Loose coupling” apre la porta a sistemi gestionali
distribuiti tipo “Plug & Play” con componenti commercialmente disponibili i.e.
componenti COTS (Commercial Off The Shelf) nei quali non solo la modifica di un
componente non influenza gli altri ma addirittura un componente può essere
rimpiazzato da un componente equivalente e.g. di marca diversa, senza che gli altri
componenti ne siano influenzati.
Infine l’integrazione di componenti applicativi diversi richiede che fra loro
possano scambiarsi informazione e dati e questo a sua volta richiede che essi
condividano uno stesso modello informativo relativo alla semantica e alla struttura
dell’informazione e al format dei dati. Senza un modello informativo condiviso i dati
che transitano da un componente applicativo all’altro dovrebero subire opportune
trasformazioni i.e. si dovrebbe effettuare una integrazione ad hoc ad ogni interfaccia
di attraversamento. Ad esempio un applicativo “Service Provisioning”
(raggruppamento “Fulfilment” nel modello FAB) che riceve da un cliente un ordine
con un indirizzo dotato di un certo data format può essere integrato con una
applicazione “Invoicing” (raggruppamento “Billing” nel modello FAB) solo se anche
quest’ultima adotta lo stesso data format per le fatture da inviare ai clienti dopo aver
installato il servizio. Nel NGOSS tutti gli elementi della piattaforma condividono un
modello informativo per il data format e la semantica/struttura dell’informazione
(modello informativo SID, Shared Information/Data Model). Quindi il modello
processuale che identifica i vari processi di business (e.g. e-TOM) e il modello
informativo che specifica la natura e il format dell’informazione e dei dati che
fluiscono nei processi (e.g. SID) sono entrambi necessari alla TelCo per poter poi
sviluppare il software gestionale desiderato
167
NOTA BIBLIOGRAFICA: Y.Grigoreva, “Open Source NGOSS Applications: Evaluation of the
feasibility and applicability of open source NGOSS applications to support the product life cycle and
operations of TLC companies”, VDM Verlag, May 2008
1.4.5 La Gestione in un macroambiente sociale e naturale
In tempi recenti, più sensibili alle problematiche dei diritti dell’uomo e della
preservazione dell’ ambiente naturale, la gestione complessiva di un impresa TelCo ha fatto
sorgere ulteriori problemi non specifici delle TLC: la gestione non poteva più limitarsi al
business TLC, seppur nel rispetto di vincoli leg-reg (legal , legislative, regulatory) ma doveva
tener conto del macroambiente naturale-sociale circostante in cui l’impresa era immersa.
In altre parole la performance complessiva di una impresa TelCo doveva tener conto delle
mutue interazioni fra impresa e ambiente naturale e sociale circostante attraverso
l’implementazione di politiche di Responsabilità Sociale di Impresa (RSI). Per questo nella
gestione di impresa odierna sono previsti processi gestionali “Stakeholder & External
Relation Management” (Vedi Appendice 3 al Cap.1, Fig.A.3.3). Di cosa si tratta? Vediamo
brevemente.
1.4.6
La gestione di impresa e il ruolo della “Responsabilità Sociale di
Impresa” in una TelCo del 2008
Abbiamo visto come nel campo delle telecomunicazioni le prime forme di gestione di
sistemi TLC (siamo negli anni sessanta) erano concentrate sui singoli elementi di rete e
implementate da tecnologie OS (Sistemi di Esercizio) realizzati con tecnologie “vendor
specific” cioè tecnologie proprietarie dei costruttori specializzate al particolare elemento di
rete da gestire. Oggi più che mai si ritiene che il modo migliore per affrontare e risolvere i
problemi che insorgono in una TelCo durante le attività di pianificazione/specifica/
progettazione dei sistemi gestionali per future reti e servizi TLC (i.e. sviluppo di processi
gestionali [*] e relative tecnologie abilitanti) o durante le attività di standardizzazione
presso enti di standardizzazione nazionali o internazionali, sia quello di riconoscere ab initio
che le gestioni di rete e servizi TLC non solo sono mutuamente correlate da un punto di vista
operativo ma si devono svolgere nel rispetto delle normative vigenti nel settore TLC e
nell’ambito di una “gestione di impresa”complessiva.
[*] In questo corso parleremo spesso di “processi gestionali” o di “modelli di processi gestionali” laddove un processo è
uninsieme coerente di attività finalizzate a un certo scopo comune prestabilito, svolta da certi agenti (uomini o macchine)
secondo procedure prestabilite e controllate e che produce risultati misurabili e ripetibili. Queste caratteristiche fanno si che
un processo, contrariamente ad attività svolte da attori umani con alti livelli di discrezionalità, si presti bene ad essere
automatizzato. L’automazione di processi aziendali centrati sul cliente (Customer Relation Management, CRM) é una linea
di tendenza iniziata negli anni 80 con il Business Process Re-engineering e poi seguta da tutte le imprese telecom. Un
modello processuale e’ una rappresentazione astratta della logica di un processo e puo’ comprendere diversi livelli di
astrazione.
Questa “gestione di impresa” a sua volta non deve essere mirata alla sola
massimizzazione dei profitti. Essa deve infatti implementare politiche di Corporate Social
Responsability, CSR (i.e. Responsabilità Sociale di Impresa) che, come minimo,
garantiscano il rispetto dei diritti dell’uomo e dei lavoratori e del benessere dei cittadini e la
preservazione dell’ambiente naturale in modo tale da far si che tutta l’impresa nel suo
168
complesso offra una performace economico-sociale-ambientale soddisfacente per tutti i
suoi stakeholders e sia quindi sostenibile nel tempo.
Tutte queste considerazioni vengono talvolta sintetizzate semplicemente sostituendo il
termine “profitti” con il termine “profitti sostenibili”. Purtroppo molto spesso la performance
economica di una TelCo prende il sopravvento sulle altre (e.g. si possono fare profitti
avvelenando l’ambiente o affamando i lavoratori) e, ancora peggio, può diventare una
performance puramente finanziaria che soddisfa gli interessi dei principali azionisti
(“shareholders”) e.g. aumentando il valore delle azioni in loro possesso, ma ignorando gli
interessi legittimi degli altri stakeholders. (Vedi. L. Gallino, “L’impresa irresponsabile”,
Einaudi, 2005). Inoltre la performance socio-ambientale spesso viene promossa in maniera
semplicemente formale e non sostanziale sulla base di codici etico-deontologici da rispettare
in maniera opzionale (i.e. senza imposizione di sanzioni nel caso di mancata osservanza) e
una sua misura quantitativa può presentare serie difficoltà specialmente per imprese
multinazionali che operano su mercati internazionali (e.g. chi controlla la eticità di
comportamento degli impiegati nella succursale di Singapore?). E senza una misura
quantitativa la gestione diventa difficile!
ADDENDUM Senza entrare nei dettagli di queste tematiche ci limitiamo a ricordare che non
tutti gli stakeholders sono ugualmente importanti per una certa impresa TelCo. In generale
l’importanza di uno stakeholder per una certa impresa si valuta sulla base della sua capacità
di condizionarne il business e sul potere che esso ha di attuare effettivamente questo
condizionamento. Ma fra tutti gli stakeholders, i clienti (customers), gli azionisti
(shareholders) e le risorse umane impiegate dall’impresa (human resources) occupano
certamente una posizione di preminanza (stakeholders principali) in quanto i primi sono la
principale sorgente di entrate per l’impresa, i secondi sono coloro che investono il capitale
necessario per realizzare e operare l’impresa e i terzi sono la forza lavoro dell’impresa. Altri
stakeholders importanti sono gli uffici delle imposte dirette (la tassazione ha un impatto
importante sui profitti), le associazioni dei consumatori, i mass media (una campagna
mediatica avversa può distruggere il business), i sindacati di categoria (uno sciopero può
ridurre i profitti) e le imprese concorrenti le quali tuttavia hanno interessi opposti a quelli
degli stakeholders principali. (Vedi K.G. Strouse, “Customer centered telecommunicatins
services marketing” Artech House, 2004, Cap.8).
1.4.7 Esercizi
ESERCIZIO. La storia della gestione di sistemi e servizi TLC inizia con la gestione “elementi di rete” e
giunge ai nostri giorni come gestione integrata “reti-servizi-impresa (TelCo)”
ii)
Quali erano le caratteristiche della gestione degli elementi di rete?
iii)
Quale è oggi lo scopo strategico (lungo termine) della gestione integrata di una impresa TelCo
se si tiene conto dell’impatto che essa ha sul macroambiente sociale e naturale circostante?
ESERCIZIO. La gestione di elementi di rete e reti TLC e la gestione dei servizi TLC sono attività
profondamente diverse che usano tecnologie gestionali diverse. Tuttavia, nella realtà dei fatti, se si
osservano un sistema TLC e la fornitura/acquisizione di un servizio TLC si può applicare la stessa
procedura concettuale per identificarne la parte “gestita” e la parte “gestionale”.
169
i)
Quale è la procedura concettuale che ci permette di identificare parte gestita e parte gestionale
di un sistem TLC o di un servizio TLC? (Suggerimento: Fare riferimento alla natura dei flussi
di informazione)
ii)
Fare un esempio che dimostri la differenza fra i modelli relativi alla gestione “Elementi di
Rete” e gestione “Servizi” e.g. considerare la gestione di un commutatore (switch) in una rete
TLC usando il paradigma Gestore-Agente e un processo gestionale “Service Order” parte di
in un servizio TLC.
1.4.8
Bibliografia Capitolo 1
1) Divakara K. Udupa, “TMN: Telecommunication Management Networks”,
McGraw Hill, Jan.1999.
2) J.Lee, “Implementing Telecommunication Management Networks”, McGraw
Hill Education Group, Sept.2000.
3) Graham Chen, Quinzhung Kong, “Integrated Telecommunication
Management Solutions”, Wiley-IEEE Press, Nov.1999.
4) Lakshmi G. Raman, “Fundamentals of Telecommunication Network
Management”, IEEE Communication Society, Wiley-IEEE Press, Feb.1999.
5) H.Wang, “Telecomunications Network Management”, McGraw-Hill, 1999
6) H.G. Hegering, S.Abeck, “ Integrated Network and System Management”,
Addison-Wesley, 1995
7) H.G. Hegering, S.Abeck, B, Neumair, “Integrated Management of Networked
Systems”, Morgan Kaufmann Publishers, 1998
8) G.Booch, “ Object-oriented Analysis and Design” (Second Edition), AddisonWesley, 1994
9) M.Garschhammer et al., “Towards Generic Service Management Concepts. A
Service Model Based Approach” Proceedings of 7-th International Symp. on
Integrated Management (IM2001) Seattle, Wa.,USA,May 2001, IEEE
Publishing.
10) M.Garshhammer et a., “The MNM Service Model-Refined Views on Generic
Service Management”, Journal of Communications & Networks,
3(4),Dec.2001
11) M.Garshhammer et al. “ A case driven Methodology for Applying the MNM
Model”, Proceedings of of the 2002 8-th International Symp. on Network
Operations and Management, Florence, Italy, April 2002, IEEE Publishing
12) E. Ward, “World-class Telecomunication Service Development”, Artech
House, 1998
13) A.Pras, “Network Management Architectures”, Tesi di dottorato, Twente
University, Olanda, Feb.1995
14) L. Lewis, “Service Level Management for Enterprise Networks”, Artech
House,1999
Bibliografia TLC non-engineerig
1. P. Brezzi, “Economia e Politica delle TLC”, Franco Angeli, 2004
170
2. M. Gambaro e C.A. Ricciardi, “Economia dell’informazione e della comunicazione”,
Laterza, Bari, 1997
3. U. Martini, “Il marketing per l’impresa di telecomunicazioni”, CEDAM, Padova,
1993
4. C.A. Pratesi, “Il marketing dei servizi ad alta tecnologia. Il successo di TIM, Telecom
Italia Mobile”, Sperling & Kupfer, Milano, 1996
5. K.G. Strouse, “Marketing telecommunications services”, Artech House, 1999
6. K.G. Strouse, Customer centered telecommunications services marketing”, Artech
House, 2004
7. F. Castelli, “Il servizio universale nelle TLC.Valutazione dei costi e finanziamento,
Franco Angeli, Milano, 1997
8. S. Frova, “TLC e Convergenza:il cammino accidentato della crescita”, ANIE, 2006
9. F. Chiappetta, “Legislazione delle TLC e telematica”, Giuffrè, Milano, 1990
10. E. Pontarollo, “ Apertura dei mercati e regolamentazione. Il caso delle TLC”,
SEAT, Roma,1993
11. V. Zeno Zencovich, “Il diritto delle TLC”, Laterza, Roma-Bari, 1997
12. M.Quadrelli, “ Manuale di diritto delle TLC”, Nyberg, Milano, 2004
13. Telecom Italia, Bilancio 2006, Sezione di sostenibilità
171
APPENDICI AL
CAPITOLO 1 (*)
(Non fanno parte del programma d’esame 2008-2009)
(*)
Materiale didattico per approfondimenti e esercitazioni
172
173
Appendice 1 al Cap.1
Il “libero mercato” delle telecomunicazioni:
considerazioni storiche
L’esistenza di un libero mercato delle telecomunicazioni con prezzi determinati
dalla libera concorrenza rimarrebbe un sogno di difficile realizzazione e di scarsa
importanza pratica se non esistessero delle “agenzie di controllo delle
telecomunicazioni” super partes, almeno sulla carta lontane da pressioni politiche e da
interessi privati, capaci di garantire che tutti i concorrenti godano delle stesse
opportunità di business e che, inoltre, essi pratichino procedure di business
concorrenziali corrette e in linea con i dettami di una normativa prestabilita.
La necessità e la natura di una agenzia di controllo specifica per le
telecomunicazioni si comprendono più facilmente se si tiene presente che al giorno
d’oggi in quasi tutte le economie avanzate i cosidetti “liberi mercati delle
telecomunicazioni” godono di una caratteristica comune: essi sono figli di mercati
monopolistici regolamentati dai rispettivi governi nazionali per almeno un centinaio
di anni. Un mercato “monopolistico regolamentato” è un mercato in cui 1) esiste un
unico fornitore di servizi (monopolio) e 2) i prezzi dei servizi TLC sono fissati dal
monopolista (regolamentazione dei prezzi) e non determinati di volta in volta dal
mercato stesso.
Le telecomunicazioni hanno circa 200 anni: dal telegrafo ottico Parigi –Lille ai
tempi di Napoleone ai telefonini dell’era moderna. Tuttavia solo a fine 800 i vari governi
cominciarono a ricononoscere l’importanza del ruolo delle telecomunicazioni nella
società e a quel punto si affrettarono a gestirle in proprio e in esclusiva, creando un
“gestore pubblico unico” e, di fatto, instaurando un regime di monopolio pubblico delle
telecomunicazioni. Questo anche per assicurare che tutti i cittadini, senza distinzioni di
sorta, potessero in ogni caso soddisfare il naturale bisogno/desiderio di comunicare
tramite accesso ad una rete telefonica pubblica almeno su base locale e a prezzi
accessibili a tutti (“servizio universale”).
Il regime di monopolio pubblico è durato per circa cento anni fino verso la fine
del 900 quando i servizi di telecomunicazione nelle varie nazioni hanno cominciato a
diversificarsi e a moltiplicarsi grazie a processi di deregolamentazione (“deregulation”)
e privatizzazione (“privatization”) delle telecomunicazioni cioè si è aperta la possibilità
a investitori/operatori privati (“new entrants”) di possedere e operare sistemi TLC e
offrire servizi TLC in una libera economia di mercato.
Negli USA il monopolio incontrastato di AT&T sia a livello “long distance” che
“local loop” (mercato locale) nel 1974 fu attaccato legalmente dalla compagnia di
telecomunicazioni MCI e dal Ministero della Giustizia. La battaglia legale culminò dieci
anni dopo, nel 1984, con la frantumazione di “AT&T local loop” in sette compagnie
174
regionali separate (le famose “sette sorelle” Regional Bell Operating Companies, RBOC)
mentre “AT&T long distance” rimaneva indivisa. Questo evento di importanza storica in
quanto fine di un monopolio centenario, in letteratura va sotto il nome di “AT&T
divestiture”. La “divestiture” (disinvestimento) è la creazione di società separate a cui
vengono cedute parte delle attività dell’impresa originaria e le cui azioni sono distribuite
agli azionisti della società iniziale. Le sette compagnie separate, a livello locale si
impegnavano a permettere la concorrenza di “new entrants”
--------------Le compagnie regionali RBOC dopo la “AT&T divestiture” dell’ 84 e la loro
ricombinazione
1. Pacific Bell
2. Ameritech
3. Southwestern Bell
1. SBC
4. US West
5. Bell South
2. Qwest
3. Bell South
6. Nynex
7. Bell Atlantic + GTE = 4. Verizon
-----------------Ma il passo definitivo sulla strada della liberalizzazione dei mercati long-distance
e locale avvenne nel 1996 con un altro evento di importanza storica: l’approvazione da
parte del parlamento USA del “Telecommunications Act”. Questa legge aboliva ogni
barriera al libero intervento nei mercati TLC intra-stato e inter-stato (long-distance),
apriva la strada alla possibilità per le RBOC di operare fuori-regione e liberalizzava la
scelta dei prezzi da parte delle compagnie di TV via cavo (servizi di entertainment
domestico).
Oggi negli USA esistono numerose compagnie di telecomunicazione classificate
in operatori long-distance (chiamati Inter-Exchange Carrier, IXC) e a operatori locali
(chiamati Local Exchange Carrier, LEC). Ricordiamo che “exchange” in inglese
significa “commutatore” mentre il “carrier” è il fornitore di servizi TlC proprietario
dell’infrastruttura di trasporto. A livello locale i LEC sono ulteriormente suddivisi in
ILEC (Incumbent LEC) i.e. le pre-esistenti RBOC e CLEC (Competitive LEC) cioe’ i
new entrants ultimi arrivati. Tuttavia oggi con il termine CLEC si indicano anche
compagnie telecom non proprietarie di infrastrutture di rete locale. Si tratta di rivenditori
di servizi TLC che prendono in affitto o in leasing capacita’ dagli ILEC oppure che
semplicemente acquistano servizi TLC locali all’ingrosso a prezzi scontati e li rivendono
al dettaglio agli utenti finali a prezzi maggiorati.
In Europa, la liberalizzazione delle telecomunicazioni concepita dalla Comunità
Europea negli anni 80 si è gradualmente materializzata negli anni 90. In Italia la
telefonia fissa è stata liberalizzata ufficialmente a partire dall’ 1/1/98. Quindi, in Italia,
175
come in molte altre nazioni, l’odierno mercato libero delle telecomunicazioni deriva da
un precedente mercato di monopolio detenuto da una impresa “monopolista” , agenzia
esclusiva del governo italiano: la “TELECOM-ITALIA”. Oggi la TELECOM –
ITALIA (“ex-monopolista” o operatore “incumbent”) possiede ancora una infrastruttura
capillare di reti di accesso in rame (“ultimo miglio cablato”) capaci di fornire servizi di
telecomunicazione di base e.g. telefonia fissa, a milioni di utenti finali (dell’ordine di 25
milioni). Tutti i nuovi operatori desiderosi di fornire servizi TLC agli utenti finali per via
wireline sono quindi bloccati dalla presenza di questa infrastruttura senza poterla
bypassare (“asset non-replicabile”). Ovviamente la tecnologia wireless, offrendo un
canale di accesso alternativo all’utente finale ha in tempi recenti cambiato i termini del
problema.
La presenza di un gestore TLC dominante in una libera economia di mercato
ovviamente comporta una serie di problematiche relative alla necessità di evitare
potenziali abusi di posizione dominante e alla necessità di garantire pari opportunità
(“leveled playing field” in inglese) a tutti i “new entrants” (“operatori alternativi”) cioè le
nuove imprese che vogliono e hanno la capacità di partecipare al business offerto da un
particolare mercato.
Sono proprio queste problematiche che sono affrontate e, si spera, risolte dalle
agenzie garanti della libera concorrenza nelle telecomunicazioni, normalmente
identificate con il termine inglese di “Authority delle telecomunicazioni”.. In Italia questa
agenzia è chiamata «Autorità per la Garanzia nelle Comunicazioni, AGCOM». Essa
è stata creata con la Legge dello Stato Italiano 249 del 31/7/1997 ed è strutturata con un
Consiglio e due Commissioni: una per le infrastrutture e le reti e un' altra per prodotti e
servizi. Ad esempio uno dei compiti dell’Authority italiana è quello di garantire che la
TELECOM-ITALIA offra a tutti gli operatori alternativi la possibilità di utilizzare le sue
reti di accesso in rame cioè offra un servizio di “accesso disaggregato alla rete locale”
(“Local Loop Unbundling”, LLU, in inglese) in modo non discriminatorio e a prezzi equi
(definiti in un listino emesso dalla Authority per i servizi di telefonia fissa). Quindi il
“LLU” è un processo in base al quale canali local loop dell’operatore dominante sono
fisicamente disconnessi dalla sua rete e connessi con la rete dell’ operatore alternativo.
Dal 2001 gli operatori alternativi possono affittare i rilegamenti d’utente dalla
TELECOM ITALIA (operatore dominante) a prezzi stabiliti dalla Authority (e.g. 8 Euro
per linea al mese).
Quest’ultimo aspetto, cioè la formulazione di prezzi equi, è molto importante.
Infatti basterebbe che l’ incumbent violasse questa condizione cioè imponesse dei prezzi
esosi per mettere fuori mercato tutti gli operatori alternativi ancorchè offrendo loro i
rilegamenti necessari all’accesso degli utenti finali.
In conclusione, il mercato delle telecomunicazioni, figlio di un mercato
monopolistico regolamentato dai governi nazionali per un centinaio di anni, è ormai,
almeno sulla carta, liberalizzato in tutte le nazioni della cosidetta “civiltà occidentale”.
Tuttavia la liberalizzazione dei mercati non ha prodotto subito e dapertutto un mercato
libero e competitivo bensì ha solamente iniziato un lento processo di trasformazione
176
tuttora in atto con maggiore o minore successo nelle varie nazioni. Oggi, nonostante la
presenza delle Authorities nazionali garanti delle comunicazioni, i fantasmi del passato
monopolista sono vivi e vegeti e il mercato delle telecomunicazioni, anche a livello
nazionale, si presenta come un guazzabuglio di segmenti di mercato alcuni dei quali
sono abbastanza liberi mentre altri non lo sono affatto.
Ad esempio i mercati locali wireline, cioè quelli supportati dall’ ”ultimo miglio”
di cablatura fra centrali locali (“local exchange” in USA) e utenti finali, si presentano
come mercati dove gli “incumbents” cercano di matenere le loro posizioni dominanti e i
“new entrants” cercano di sfruttare i diritti acquisiti con la liberalizzazione dei mercati
nell’intento di trarne un profitto economico. Nel 2007 negli USA il mercato locale di
telefonia fissa era costituito da 188 milioni di linee d’utente di cui solo il 13%, cioè 25
milioni, erano fornite da “new entrants” CLEC mentre l’87% era fornito dalle vecchie
ILEC. Ma fra i “new entrants” solo il 26% avevano costruito nuovi impianti di cui erano
rimasti proprietari mentre il restante 74% erano rivenditori (“resellers”) di servizi di
telefonia i quali compravano capacità dagli “incubents” a prezzi calmierati e la
rivendevano agli utenti finali a prezzi maggiorati. Se si pensa che solo il proprietario di
impianti di telecomunicazione (“facility-based service provider”) gode della completa
libertà di competere liberamente, si capisce che il processo di liberalizzazione dei mercati
locali USA ha ancora un lungo cammino da percorrere per arrivare alla meta desiderata di
un mercato completamente libero.
Inoltre negli USA oggi si sta verificando un processo di riaggregazione di Telco
attraverso “fusioni” (mergers) in cui una Telco compra un’altra Telco per creare una
compagnia più grossa capace di competere più’ efficacemente nel libero mercato
telecom. E’ tipico il caso di Telco locali, e.g. ILEC (Incumbent Local Exchange Carrier),
che dispongono di capitale sufficiente per comprare Telco long distance e costituire
grosse compagnie capaci di fornire servizi TLC a livello nazionale. Ovviamente questo
avviene nel rispetto delle leggi del Telecommunication Act del 1996, previa
autorizzazione dell’Authority USA (la Federal Communication Commission, FCC) e
della divisione antitrust del Department of Justice (Ministero di Grazia e Giustizia).
Infatti le leggi vigenti permettono alle Telco locali di espandersi sul mercato long
distance solo dopo aver garantito l’esistenza di concorrenza sul mercato locale di loro
competenza e.g. attraverso la “divestiture” di parte delle loro infrastrutture se esse sono
Telco locali esclusive. Recenti esempi di fusioni (fine Ottobre 2005) sono quelli in cui la
compagnia SouthernBell Company, SBC (Pacific Bell + SouthwesternBell + Ameritec)
ha comprato per 16 miliardi di dollari la “ATT long distance” e la “Verizon”
(BellAtlantic + Nynex + GTE) ha comprato per 8.5 miliardi di dollari la compagnia long
distance MCI (Vedi Tavola A.1.3.1). Che fine hanno fatto le le Baby Bells?
NOTA BENE. Un buon testo italiano sugli aspetti legislativi-giuridici e regolatorii delle
telecomunicazioni è: Marco Quadrelli, “Manuale di diritto delle telecomunicazioni”, Nyberg, 2004
177
Appendice 2 al Cap.1
Gli oggetti gestiti contenuti nella MIB della Fig.1.3.1
QUESTA APPENDICE E’ STATA
ELIMINATA PER RIDURRE
LE DIMENSIONI DEL FILE
178
Appendice 3 al Cap.1
Modello e-TOM (TeleManagement Forum & ITU-T)
e - TOM model of TeleManagement
Zero Level View
Forum
Gestione Operazioni
Gestione
(*)
Strategie, Infrastruttura
Mappa TOM
Prodotti
Gestione Impresa
(*) Gestione della
“ readiness ” dei sistemi di supporto
etom1
Fig.A3.1 Il posizionamento dei processi di gestione di impresa nell’ambito della gestione integrata di
una TelCo secondo il modello e-TOM del Tele-Management Forum (Livello zero).
179
e-TOM: Level 0 & 1 views
OPERAZIONI
STRATEGIE & SVILUPPO
Strategie
Gestione
CdV
Infrastrutture
Supporto
Operaz. &
Readiness
Gestione
CdV
Prodotti
Fullfilment
Assurance
.
Gestione Marketing
Gestione Relazioni Clienti (CRM)
Sviluppo Servizi
Gestione & Operazioni Servizi
Sviluppo Risorse
Gestione & Operazioni Risorse
Sviluppo Supply Chain
Gestione Relazioni Fornitori e Partners
Enterprtise
Effectiveness
Mngmt
Strategic & Enterprise
Planning
Enterprise Risk
Mngmt
Financial & Asset
Management
Stakeholder &
Ext. Relation Mngmt
Human Resources
Mngmt
Fig. A3.2 Livello 1 del modello e-TOM del TMF (modello statico a “nested boxes”)
180
Fatturaz
Knowledge &
Research Mngmt
GESTIONE
IMPRESA
1.1 Strategic &
Enterprise Planning
l=1. Strategic
Business Planning
l=2. Business
Development
1.2 Enterprise Risk
Mngmt
1.3 Enterprise
Effectiveness Mngmt
1. Process
Mngmt & Support
1. Business
Continuity Mngmt
2. Enterprise
Quality Mngmt
3. Program &
Project Mngmt
4. Audit Mngmt
4. Enterprise
Performance Asses.
l=4. Group Enterprise
Mngmt.
5. Insurance Mngmt
5. Facilities Mngmt
& Support
2.1 Financial &
Asset Mngmt
2.2 Stakeholder &
Ex. Rel. Mngmt
2.3 Human Resources
Mngmt
1. Corporate Comms.
& Image Mngmt
1. HR Policies &
Practices
1. Financial
Management
2. Corporate Relations
Mngmt
2. Organization
Development
3. Shareholder
Relations Mngmt
2. Asset
Management
3. Workforce
Strategy
4. Regulatory Mngmt
2. Research
Management
3. Technology
Scanning
ENTERPRISE
MANAGEMENT
Level 2 view
BA.423 // 0. 3. j . K . l
4. Workforce Dvlpmnt
5. Legal Mngmt
3. Procurement
Management
1. Knowledge
Management
2. Security Mngmt
3. Fraud Mngmt
l=3. Enterprise
Architecture Mngmt
1.4 Knowlwdge &
Research Mngmt
6. Board & Shares/
Securities Mngmt
5. Employee & Labour
Relations Mngmt
Fig.A.3.3 Processi all’interno del raggruppamento “Gestione di impresa” (Livello 2 del modello
e-TOM). I processi del gruppo 2.2 appartengono alle aree conoscitive Leg-reg e Social (vedi
Appendice 4 al Capitolo1)
181
Marketing & Offer
Management
Marketing
Strategy &
Policy
Product &
Offer
Business
Planning &
Commitment
Product & Offer Portfolio
Strategy Policy & Planning
. Product & Offer
Portfolio
Capability
Delivery
Marketing
Capability
Delivery
CRM
Capability
Delivery
Service Development
& Management
S
I
P
Service
Strategy
& Planning
Marketing
Communications
& Promotions
Sales &
Channel
DEvopment
Product,
Marketing &
Customer
Performance
Service
Development
Service
Capability
Delivery
Resource Development
& Management
Resource
Strategy
& Planning
Product
Development
& Retirement
Service
Performance Assessment
& Retirement
Resource Development
Resource
Capability
Delivery
Resource
Performance Assessment
& Retirement
Supply Chain Development
& Management
Supply Chain
Strategy & Policy
Supply
Chain
Capability
Availability
Supply Chain Planning &
Commitment
Strategy
Infrastructure
Supply Chain Development
& Change Management
Supply Chain Performance
Assessment
Product
Fig. A.3.4 Processi all’interno del raggruppamento SIP, “Strategie, Infrastruttura, Prodotti”
(Livello 2 del modello e-TOM).
182
Fig.A.3.5 Processi operativi (Livello 2 del modello e-TOM).
Customer Interface Management
CRM
BSS
CRM Op.
Support &
Process
Mngmt
CRM
Operations
Readiness
Sales & Channel
Management
Marketing
Fulfillment
Response
Order
Handling
Problem Handling
Customer
QoS/SLA
Management
Selling
Retention & Loyalty
Service Management & Operations (SM&O)
SM&O Support
& Process Mngmt
OSS
Service
Problem
Management
Service
Configuration
& Activation
Resource Management & Operations (RM&O)
OS
NSS
Resource Trouble
Mngmt
Resource
Perf. Mngmt.
Resource
Provisionig
Resource Mngmt &
Operations
Resource Data Collection & Processing
Supplier/Partner Relationship Mngmt
BSS
SPRM Oper. Support
& Process Mngmt
S/P Problem
Reporting & Mngmt
S/P
Requisition
Mngmt
SPRM Operations
Readiness
Oper. Supp. & Readiness
Service &
Specific Instance
Rating
QoS Analysis
Action & Reporting
SM&O Readiness
RM&O Support &
Process Mngmt
Billing &
Collections
Management
S/P Performance
Mngmt
S/P
Settlements
& Billing Mngmt
. Supplier/Partner Interface Management
Fulfillment
Assurance
183
Billing
Appendice 4 al Capitolo 1
Interdisciplinarietà “completa” in una TelCo: la
metodologia dei Punti di Vista
A.4.1 Le basi per uno studio interdisciplinare “completo” della Gestione TLC
Nel Cap.1 abbiamo parlato di interdisciplinarietà “bidimensionale” facendo
riferimento alle due aree conoscitive Engineering-Business definite nella Tavola 1.3.1.2,
ognuna costituita da nozioni appartenenti a quattro discipline tradizionali (specializzate
alle TLC). Questa interdisciplinarietà a livello conoscitivo è utile nel mondo del lavoro a
livello operativo (competenze professionali trasversali) specialmente in fase di Product
Development in una TelCo o in fase di preparazione di standard/regolamentazione negli
enti preposti alla standardizzazione/regolamentazione delle TLC. Nel Capitolo 1 abbiamo
fatto riferimento al business di una TelCo “orientato al Cliente”. Le relazioni di business
della TelCo con altre imprese TelCo partner o con imprese ICTS produttrici/venditrici di
tecnologie ICT (“suppliers”) e, talvolta, con imprese ContCo fornitrici di contenuti sono
da noi prese in considerazione solo marginalmente. (vedi Fig.1.0.1.4).
Abbiamo visto come una impresa TelCo sia il gestore di reti e servizi TLC e
come i processi gestionali siano in effetti processi di business tesi al conseguimento di
certi “business objectives”. Fra gli obiettivi di business c’è il soddisfacimento delle
esigenze dei Clienti (e.g. service provisioning, segnalazione/riparazione guasti, gestione
della qualità dei servizi, tariffazione/addibiti/fatturazione etc.) in maniera
efficace/efficiente. Il raggiungimento degli obiettivi di business di una TelCo avviene
portando a termine una serie di flussi di processi operativi end-to-end di natura
interdisciplinare che abbracciano tutto l’arco “clienti-servizi-reti”
Come già detto, per rispettare i limiti imposti dal programma didattico 2008-2009
in questo corso ci siamo limitati a considerare una interdisciplinarietà bidimensionale
costituita da conoscenze/competenze professionali in “Engineering” (sottoinsieme
dell’area conoscitiva SE&T della Tavola A.4.1) e “Business (area conoscitiva nella
Tavola A.4.1) definite nella Tavola 1.3.1.2 e ritenute necessarie e sufficienti a supportare
i flussi operativi end-to-end. Tuttavia si deve essere consapevoli del fatto che anche altri
stakeholders esterni con competenze professionali non appartenenti alle aree
conoscitive Business o Engineering come da noi definite, e.g. centri di ricerca, centri di
produzione di innovazione tecnologica, istituzioni governative, TLC law makers, enti di
regolamentazione e standardizzazione, stakeholders sociali nel macroambiente sociale
circostante la TelCo etc. possono condizionare pesantemente i processi aziendali della
TelCo. In generale una TelCo si relaziona in varie maniere con questi stakeholders
esterni attraverso interfacce interne (stakeholders interni) e processi aziendali e.g.
Research Management, Technology Scanning, Stakeholder & External Relations
Management, Corporate communications and Image Management, Community &
184
Shareholder Relations Management, Regulatory & Legal Management etc. vedi
Fig.A.3.3 e Fig.A.4.1. Questi processi sono relazionati e influenzano i processi gestionali
di natura Engineering e Business e fanno parte a tutto diritto di quella che noi abbiamo
chiamato la Gestione, con la G maiuscola.
“LEG-REG”
VISTA
Natura degli Stakeholders
interni a una TelCo
“ST&E”
VISTA
“BUSINESS”
VISTA
“SOCIAL”
VISTA
CEO
Punti di Vista
COO
General
Counsel
VP
Public
Relations
CTO/CIO
CFO
VP
Sales &
Marketing
HRD
ST&E
LEG-REG
SOCIAL
BUSINESS
Persona decomp/PdS
Fig.A.4.1 Vista di alcuni stakeholders interni ad una TelCo
Allora gli studenti che desiderano avere una rappresentazione/comprensione
completa della natura interdisciplinare di tutti i processi gestionali in una TelCo è bene
prendano in considerazione una “interdisciplinarietà completa” i.e. uno scenario
interdisciplinare più vasto di quello considerato sinora, uno scenario che comprenda
stakeholders dotati di conoscenze/competenze professionali appartenenti alle seguenti
aree conoscitive,
1. Science, Engineering
& Technology (SE&T),
2. Business,
3. Legislative, Legal-Regulatory (Leg-Reg)
4. Social.
185
riportate nella Tavola A.4.1. All’interno della TelCo ogni area conoscitiva è di supporto a
certi modelli gestionali e ai reletivi processi/tecnologie. Ad esempio le aree conoscitive
Leg-Reg e Social sono di supporto ai processi gestionali del gruppo “Stakeholder &
External Relation Management” in Fig.A.3.3 (Appendice 3 al Cap.1)
Un approccio interdisciplinare completo allo studio dei processi gestionali di una
TelCo è didatticamente efficace se parte ab ovo da una rappresentazione completa e
complessiva delle telecomunicazioni reali (modello di riferimento interdisciplinare
delle TLC) con una visione completa di tutti gli stakeholders di una TelCo.
CONOSCENZE nella SOCIETA’ di RIFERIMENTO (paesi del gruppo G8)
(Knowledge Society)
CORPUS CONOSCITIVO delle TLC
(strutturato in quattro “aree conoscitive”)
1. SE&T (TLC Science, Engineering, Technology),
2. Business (TLC Economy, Finance,
Marketing & part of Enterprise Management)
CONOSCENZE nonTLC
(strutturate in discipline nonTLC)
3. Leg-reg (TLC Jurisprudence, Legislation,
Regulation, Standardization),
4. Social (TLC Ecology, Sociology).
Tavola A.4.1 Struttura delle conoscenze TLC. Aree conoscitive possedute da esperti integrati in teams
di lavoro per lo sviluppo di servizi TLC e relative tecnologie ICT abilitanti. Le frecce indicano possibili
approcci interdisciplinari. In questo corso prendiamo in considerazione solo la interdisciplinarietà
Engineering-Business (freccia verticale).
Qui di seguito si presenta la genesi di un possibile modello interdisciplinare di
riferimento delle TLC (qui denominato modello “Mondo TLC”) sviluppato dallo
scrivente preso l’International Telecommunications Satellite Organization (INTELSAT)
negli USA. Il modello “Mondo TLC” è suddiviso in quattro Ambienti (sottomodelli)
ottenuti come “viste” del mondo reale delle TLC osservato da quattro Punti di Vista
locali supportati dalle quattro aree conoscitive di Tavola A.4.1. Come già detto, ciò viene
fatto in maniera formale applicando la metodologia dei Punti di Vista (“Point of View
Methodology”) già utilizzato dall’ ISO/ITU-T nello standard RM-ODP, Reference
Model for Open Distributed Processing (vedi “Reference Model for Open Distributed
Processing”, ITU-T Recommendation X.901, 1997).
186
% Pop.
Utenti
Internet
% Pop.
Abbon.
Broad
Band
% Abbon.
Fissi con
Abbon.
Mobile
Numero
Abbon.
Mobili per
100 Abit.
1. ITALIA
49.63
14.86
74
135
2. GERMANIA
46.67
18.3
61
103
3. FRANCIA
49.57
20.93
60
85
4. REGNO UNITO
56
21
67
116
5. USA
69
19.31
57.5
77
67.9
23.6
45
52
68
20.62
64.8
79
18.02
2.03
75
PAESI del G8
(Dati ITU 2006)
6. CANADA
7. GIAPPONE
8. RUSSIA
Product Develop.
Tavola A.4.2 Dati ITU/2006 relativi alla società di riferimento (paesi del G8)
NOTA A.4,1 Il modello Mondo TLC è un “data base model” del tipo “Entity-Relationship (E-R)
Model” (vedi, P.P. Chen “The Entity-Relationship model-Toward a unified view of data” ACM
Transactions on Database Systems, Vol.1, No.1, March 1976, pp.9-36) creato utilizzando la
metodologia dei “Punti di Vista” Nel modello i sistemi e servizi TLC sono rappresentati come
“entità” e “relazioni fra entità”.
A.4.2 Il modello interdisciplinare “Mondo TLC”
Un “modello” di un sistema reale prescelto come oggetto da modellare (sistema
target) è una rappresentazione astratta del sistema reale i.e risultato di un processo di
modellazione in cui vengono ritenuti solo gli elementi di interesse dell’osservatore/
modellatore/utilizzatore e vengono ignorati tutti gli altri. Un modello è realizzato da un
osservatore/modellatore che lo osserva da un certo Punto di Vista e tiene conto delle
esigenze dei futuri utilizzatori (e.g. scelta di livello di astrazione, format e linguaggi del
modello). Nel nostro caso il sistema target da modellare è una società civile in cui, nell’
anno 2008, si svolgono attività di telecomunicazione di ultima generazione (“società
reale di riferimento”) che definiremo fra poco.
Allora un “modello TLC” e.g. denominato “Mondo TLC”, è la rappresentazione
astratta di una “società reale di riferimento” osservata da un “Punto di Vista TLC”
che tiene conto di tutti gli “aspetti” delle telecomunicazioni e si articola nei quattro Punti
di Vista locali supportati dalle quattro aree conoscitive.. Definiamo ora la “società reale
di riferimento” da modellare
187
Il sistema target, spazio da osservare e oggetto del nostro processo di
modellazione, è la società civile nei paesi più industrializzati del mondo e.g. i paesi del
gruppo G8. (Italia, Francia, Germania, Inghilterra. USA, Canada, Giappone, Russia, vedi
Tavola A.4.2) le cui economie rappresentano complessivamente il 65% dell’economia
mondiale. I paesi economicamente più avanzati sono anche quelli dove le
telecomunicazioni si trovano ai livelli più avanzati e sono ben monitorate e documentate
da agenzie governative e da organizzazioni private.
Quindi la società civile nei paesi del gruppo G-8 rappresenta un contenitore
ideale dove “osservare” le telecomunicazioni di ultima generazione. Questa società
costituisce la “società reale di riferimento” dove noi “osserviamo” lo stato dell’arte
2008 delle TLC.
[NOTA: per più dettagli sul rapporto sinergico fra sviluppo economico e sviluppo delle
telecomunicazioni su base nazionale vedere anche: R.J. Saunders, J,J, Warford and B.Wellenius,
“Telecommunications and Economic Development”, John Hopkins University Press, Baltimore, 1983].
A.4.3 La metodologia dei “Punti di Vista” e i quattro Ambienti (sottomodelli) del
Mondo TLC
A.4.3.1 La “società reale di riferimento”: sistema reale target da modellare
Osserviamo la “società reale di riferimento” dai quattro Punti di Vista
precedentemente definiti mettendone a fuoco in quattro “Viste” tutti gli aspetti rilevanti
alle TLC (stakeholders e tecnologie).
Notiamo subito che certe entità che popolano il Mondo TLC possono essere
facilmente individuate. Si tratta delle tecnologie ICT necessarie per fruire dei servizi
TLC. Esse sono particolarmente evidenti e prepotentemente sotto gli occhi di tutti noi.
Per le strade di una delle nostre città vediamo cabine telefoniche con o senza occupanti
che parlano al telefono, antenne televisive o antenne di telefonia cellulare installate sui
tetti delle case, antenne radio sulle automobili, viandanti gesticolanti che parlano al
telefono cellulare, negozi che vendono telefoni, televisori o computers, pattuglie della
polizia in contatto radio con la loro centrale operativa etc.etc. Nelle nostre case esistono
apparecchiature terminali di telecomunicazione di ogni tipo e.g. telefoni fissi o mobili,
computers, macchine fax connessi alla rete telefonica fissa via DECT (cordless) o Wi-Fi,
televisori o apparecchi radio sintonizzabili su trasmittenti radio-televisive terrestri o
satellitari via decoders.
Ci sono poi aspetti TLC della società di riferimento meno appariscenti ma tuttavia
facilmente riconoscibili. Tutti noi, che apparteniamo a questa società, quando ci
abboniamo ad un servizio telefonico o un servizio di e-mail entriamo a far parte del
Mondo TLC e cominciamo a svolgere il ruolo di “abbonato” o “utente” di servizi di
telecomunicazione (servizi TLC) che possono essere attualizzati quando vogliamo sette
giorni alla settimana, ventiquattro ore al giorno (servizi 24/7). Proprio come i servizi di
distribuzione di energia elettrica, gas o acqua (“Utilities” in inglese). Si tratta di servizi
che soddisfano il bisogno di comunicare con i nostri simili.
188
EUROPA
COMMISSIONE
CE
CONSIGLIO
CORTE GIUSTIZIA
STATO
(Parlamento
Ministeri,
Regioni
Province,
Comuni)
ENTE
REGOLAM.
TECNICA
AUTHORITIES
ANTITRUST
TELCO
AGCOM
UTENTE
GARANTE
PRIVACY
GIUDICE ORDINARIO
ORGANI GIUDIZIARI
GIUDICE AMMINISTR.
TAR LAZIO
Fig. A.4.2 Attori leg-reg (adattato da: “Manuale di diritto delle telecomunicazioni”
M. Quadrelli, Nyberg, 2004)
Ma possiamo entrare nel Mondo TLC anche per vie alternative forse meno
“necessarie” ma, nel lungo termine, piu’ lucrative. Ad esempio possiamo iniziare una
attività imprenditoriale nel campo TLC come impresa fornitrice di servizi TLC “Telco”
(Telecommunication Company = TLC Service Provider + Network Operator) o come
impresa manifatturiera di tecnologie ICT “ICTS” (Manufacturer of Technology =
Designer/Bilder + ICT Vendor ) o come una impresa fornitrice di contenuti per servizi
TLC “ContCo” (notizie, educazione, intrattenimento, pubblicità). Altrimenti possiamo
semplicemente comprare azioni di un impresa telecom quotata in borsa o, se siamo ricchi,
possiamo investire i nostri capitali partecipando direttamente a finanziare una impresa
telecom. In questo caso entriamo a far parte del Mondo TLC attraverso lo svolgimento
del ruolo di finanziatori (“Investors”) del business di una impresa telecom.
Esiste poi una parte del Mondo TLC che forse è poco visibile agli occhi del
cittadino medio ma non all’esperto di telecomunicazioni. Vogliamo riferirci alla
legislazione, alla normativa regolatorio-giuridica e agli standard che regolano
l’esercizio delle telecomunicazioni, la installazione degli impianti e la costruzione delle
apparecchiature di telecomunicazione. Si tratta di un insieme di regole che legislatori,
regolatori a livello locale, regionale, nazionale o internazionale (e.g. Agenzie Nazionali
di Regolamentazione, National Regulatory Agencies) e enti di standardizzazione (e.g.
189
International Telecommunication Union, ITU) erogano. Le imprese telecom
relazioni di lavoro con questi stakeholders come mostrato in Fig.A.4.1
“Diritto delle telecomunicazioni” e attività legali nel contesto
delle telecomunicazioni (Attori leg.)
Gli attori di business TLC, come cittadini di uno stato e
membri di una società civile devono comportarsi nel rispetto
delle leggi vigenti e delle normative giuridiche specifiche del
campo di attività da essi svolte (Diritto civile, diritto
industriale, diritto del lavoro, diritto tributario etc.). Ma
esiste anche una normativa giuridica specifica delle
telecomunicazioni (Diritto delle Telecomunicazioni) che
regola il comportamento di attori di business (Persone TLC
giuriche e fisiche) allorchè essi svolgono attività specifiche
del business TLC. Questa normativa ad esempio si applica
allorchè uno o più attori svolgono attività rilevanti sotto un
profilo legale nel contesto specifico delle telecomunicazioni.
Alcuni esempi di controversie legali specifiche delle
telecomunicazioni di competenza di un “Giudice ordinario”
(Vedi Fig.1.2.4.1) sono i seguenti: controversia legale insorta
relativamente alle clausole di un contratto di utenza mobile,
controversia relativa ad una violazione dei diritti di un
utente alla prestazione o a essere indenizzato nel caso di
violazione del contratto da parte dell’esercente, violazione
dei termini di contratto tra fornitori partner di servizi TLC
Un esempio di controversia legale di competenza del
Tribunale Amministrativo Regionale, TAR, del Lazio (Vedi
Fig.1.2.4.1).è il seguente: ricorso avverso ai provvedimenti
dell’Agcom con richiesta di sospensione dei provvedimenti
stessi. Ricordiamo che le controversie fra privati sono di
competenza del giudice ordinario mentre quelle fra privato e
enti pubblici competono al giudice amministrativo.
190
hanno
Codice Etico
Impatto ambientale e/o
socio-economico
dell’implementazione
delle politiche aziendali
di una impresa telecom
RSI
OSSERVA
IMPRESA
TELECOM
TELCO
SOCIAL
STAKEHOLDER
MANAGEMENT
MANTEC
STAKEHOLDER
UTENTE
Attori business
Impatto attività dei
social stakeholders
su attori business
Social sthdr/ PdS
Fig.A.4.3 Relazione fra imprese TLC e social stakeholders
Infine il business di una TelCo è influenzato da e influenza il macroambiente
sociale e naturale circostante. (Vedi Fig.A.4.3).
La Responsabilità Sociale di Impresa (Corporate Social Responsabilità, CSR)
implementata da una TelCo si riferisce proprio all’impatto delle attività TLC sul
Macroambiente nonTLC (ambiente naturale, società).
Come il comportamento di una Telco può influenzare l’ambiente naturale e
sociale circostante così i social stakeholders, in base alla loro percezione del
comportamento di una Telco, possono prendere iniziative tali da influenzarne il business
in maniera più o meno determinante a seconda del loro “interesse” nel comportamento
della Telco e il loro “potere” di influenzarlo.
Quindi nella società civile in cui è immersa una Telco esistono social
stakeholders, i.e portatori di interesse attivi nel sociale, che non hanno relazioni di
business con le Telco ma che tuttavia possono svolgere attività capaci di influenzarne il
business in maniera importante. L’insieme dei social stakeholders relativi ad una certa
Telco ne costituisce quello che si chiama “ambiente sociale”. Una Telco può essere
osservata da un Punto di Vista “Social” e così si può generare una vista che ne mette a
191
fuoco il suo comportamento etico e le conseguenze socio-ambientali delle sue attività di
impresa.
Ad esempio, certi mass-media come i giornali o la radio/televisione possono
pesantemente influenzare l’opinione pubblica e, conseguentemente, le scelte dei
consumatori creando un immagine favorevole o sfavorevole di una particolare Telco
sulla base di un analisi imparziale, si spera!, delle politiche di RSI implementate dalla
Telco. Le scelte dei consumatori hanno a loro volta un impatto determinante sul business
dell’impresa. Lo stesso discorso vale per altri social stakeholders. Ad esempio, al giorno
d’oggi, una Telco irrispettosa delle norme relative ad un uso corretto delle risorse naturali
cioè una Telco che inquinasse l’ambiente naturale con antenne che emettono radiazioni
elettromagnetiche pericolose per la salute della popolazione sarebbe subito “scoperta” da
organizzazioni ambientaliste, essere oggetto di una campagna mediatica negativa.
I ruoli di social stakeholder identificati da Telecom Italia
1.
2.
3.
4.
5.
6.
Clienti. Disponibilità di CRM avanzato con indagini sulla soddisfazione dei clienti
e ascolto di segnalazioni pervenute a Call Centers
Fornitori. Programma “Vendor Rating” per valutare i fornitori in base al loro rispetto
dei diritti umani e la protezione dell’ambiente.
Concorrenti, Stato, Istituzioni. TI ha continui contatti con queste entità.
Comunità. TI svolge attività filantropiche supportando attività culturali, sportive e
umanitarie
Risorse Umane. Programma “Foto di Gruppo” per accertare il livello di soddisfazione
delle risorse umane su base annuale.
Azionisti. TI conduce “perception studies” e organizza “investor days” dedicati agli azionisti.
TAVOLA A.4.3
A.4.3.2 La metodologia dei “Punti di Vista”
A questo punto si capisce che ci si trova in presenza di un sistema estremamente
complesso. Per far sì che il modello sia di facile utilizzabilità e al tempo stesso non
tralasci aspetti importanti della realtà è opportuno che esso sia realizzato tramite una
molteplicità di sottomodelli secondo una filosofia “divide et impera” tipica
dell’ingegneria del software.
Questi sottomodelli sono ottenuto osservando la realtà da quattro Punti di Vista
locali il cui insieme costituisce il Punto di Vista TLC (Vedi Fig. A.4.4). Ogni
sottomodello rappresenta una vista locale delle TLC.
192
Punto di Vista TLC
SE&T
Business
Leg-Reg
Social
Punti di Vista
settoriali
SOCIETA’ REALE di RIFERIMENTO
Sottomodelli
(“Ambienti”)
SE&T
Business
Leg-Reg
Social
Mondo TLC
Persona decomp
Fig. A.4.4 Decomposizione del Punto di Vista TLC in quattro Punti di Vista Locali
Il modello “Mondo TLC” da noi adottato modellizza gli aspetti TLC della società
di riferimento “osservandola” da un “Punto di Vista TLC” articolato in quattro Punti di
Vista locali corrispondenti alle quattro “aree conoscitive” nella Tavola A.4.1 che
costituiscono la struttura disciplinare delle conoscenze TLC possedute dalla società reale
di riferimento.
A.4.3.3 Contenuti del modello “Mondo TLC”
Il modello “Mondo TLC” è costituito da quattro sottomodelli denominati
“Ambienti” (Environments”) mutuamente relazionati,
1. Ambiente SE&T(TLC Science, Engineering & Technology)
2. Ambiente Business (TLC Economy, Finance, Marketing & part of Enterprise Management)
3. Ambiente Leg-reg (TLC Legislation, Regulation, Jurisprudence, Standardization)
4. Ambiente Social (TLC Ecology, Sociology).
e ogni Ambiente è popolato da certe “Entità” legate da “Relazioni” (Entity-Relationship
Model di P.P.Chen) come mostrato in Fig.A.4.5. Più precisamente ogni Ambiente è
popolato da Stakeholders/Attori (rettangoli gialli) che svolgono certe Funzioni
(diamanti celesti) e producono/utilizzano Prodotti usando opportune Risorse (rettangoli
bianchi)
193
Facciamo alcuni esempi.
Una impresa reale ICTS allorché osservata da un Punto di Vista Engineering
(parte del Punto di Vista SE&T) è rappresentata da un Attore Engineering “Progettista/
Costruttore” che opera in un Ambiente Engineering per produrre Tecnologie ICT
componenti ICT dei Sistemi TLC (Prodotto Engineering),
Una impresa ICTS osservata da un Punto di Vista Business è un Attore Business
“Vendor” che effettua la “Vendita di Merce ICT” (Prodotto Business),
Una impresa TelCo osservata da un Punto di Vista Engineering è un Attore
Engineering “Network Operator” che effettua la “Gestione/Esercizio di reti TLC”
(Prodotto Engineering) in un Ambiente Engineering
Una impresa TelCo osservata da un Punto di Vista Business è un Attore Business
“Service Provider” che fornisce/eroga Servizi TLC (Prodotti Business) in un
Ambiente Business
LR1- RESOURCE (Ex)
LR1 – ACTOR
LR1
TLC system lobbyst
LR2- RESOURCE (Ex)
Authorization/
Licence to build
T1-Product
E1=manufactures
E2=develops
B1=sells
B2=provides
B3=communicates
LR1=lobbies
LR2,3=grants
T1- RESOURCE (Int)
LR2,3
LR3- PRODUCT
(Authoriz., Licence)
B1- RESOURCE (Int)
LR2 - ACTOR
Authorization / Licence to
develop / provide B2-product
B2- RESOURCE (Int)
Sale
contract
TLC regulator (e.g.NRA)
(TLC regulation
producer)
LR12- PRODUCT (Regulation)
B3
B3 - ACTOR
B3 - ACTOR
End-user
End-user
B1
B1 – ACTOR
TLC system seller
(VENDOR)
T1- ACTOR
B2
B2 - ACTOR
TLC service producer /
provider & system buyer
(TELCO)
T1
B2 - PRODUCT
B3-RESOURCE (Int)
B1- RESOURCE (Int)
T1-RESOURCE (Int)
T1- PRODUCT
T2 - PRODUCT
TLC system producer
TLC system
PdS Persona TLC
T1-RESOURCE (Ex)
TLC technology
B2-RESOURCE (Ex)
TLC service
T2
T2 - ACTOR
TLC Technology
producer
T2-RESOURCE (Ex)
Fig. A.4.5 Modello Entity-Relationship (ER) del modello “Mondo TLC” (primo livello di astrazione) su
tre aree funzionali: SE&T (verde), Business (marrone), Leg-Reg (rosa). T1+B1 Actor = ICTS, T2 Actor=
R&D + Technology Producer, B2 Actor = TelCo (NO+SP), B3 Actor =End-user, LR2 Actor =NRA, LR1
Actor =TelCo Reg. Officer. Le risorse nelle strisce bianche sono risorse nonICT prodotte al di fuori del
Mondo TLC
194
Le Authorities Nazionali di Regolamentazione sono Attori Leg-reg che operano
in un Ambiente Leg-reg e producono Regolamentazione TLC specifica delle TLC
(Prodotto Leg-reg),
Le imprese TelCo o ICTS in quanto aziende che implementano politiche di
“Responsabilità Sociale d’ Impresa” sono Attori Sociali che operano in un Ambiente
Sociale.
A.4.4 Il corso GST utilizza solo una parte del Mondo TL: Ambiente Engineering e
Ambiente Business
Il modello “Mondo TLC” è stato creato principalmente per corsi di formazione
propfessionale on line (intranet aziendale) mirati a forme di “apprendimento
personalizzato”. Nel corso di GST noi lo utilizzeremo solo in parte. Infatti ci
limiteremo a considerare solo l’ Ambiente Engineering (parte dell’Ambiente SE&T) e
l’Ambiente Business rispettivamente popolati da Stakeholder/Attori Engineering o
Business che svolgono certe Funzioni Engineering o Business e producono/utilizzano
Prodotti Engineering o Business usando opportune Risorse Engineering o Business. La
nostra scelta corrisponde alla scelta tradizionale di studiare le telecomunicazioni in
termini di “Reti TLC” e “Servizi TLC”. Tuttavia c’è una grande differenza! Qui si opera
nell’ambito di uno scenario interdisciplinare molto più vasto che si articola nei quattro
Ambienti SE&T, Business, Leg-reg e Social, mutuamente relazionati.
195
Appendice 5 al Cap.1
Interdisciplinarietà: “cross-fertilizzazione” di
conoscenze con produzione di extra-conoscenze
Il carattere interdisciplinare della Gestione, con la G maiuscola, in ambito TelCo
e l’importanza del lavoro di team assieme ai progressi fatti nel campo della
“interdisciplinarietà” come soggetto di studio a se stante, giustifica una piccola
digressione di carattere generale sull’argomento [*]. Nel nostro corso è importante
distinguere fra “Interdisciplinarietà” e “Multidisciplinarietà”!
La conoscenza umana tradizionalmente è stata ed è ancora suddivisa in domini
conoscitivi, denominati “discipline”, ognuno dei quali contiene elementi conoscitivi
(soggetti, argomenti, tematiche etc.) atti a spiegare una “classe di fenomeni” o a
risolvere una “classe di problemi”. Una “classe” di fenomeni/problemi è un insieme di
fenomeni/problemi con caratteristiche comuni tipiche e caratterizzanti la classe stessa.
Corrispondentemente alla struttura disciplinare della conoscenza, nel mondo del lavoro la
capacità lavorativa è strutturata in “competenze professionali” mentre nel mondo della
formazione professionale l’insegnamento è classificato per “materie di insegnamento”
(vedi “facoltà o corsi universitari”). Esiste una corrispondenza uno-a-uno fra “discipline”,
“competenze professionali” e “gruppi di materie di insegnamento”
Ad esempio, alla disciplina “Ingegneria” corrisponde la competenza
professionale “Ingegnere” e la facoltà di “Ingegneria” all’Università. In generale,
possesso di “conoscenze interdisciplinari” significa possesso, da parte di un unico
soggetto (persona fisica o team integrato di persone), di aree conoscitive integrate
(integrated knowledge fields) risultanti dalla integrazione di conoscenze
monodisciplinari appartenenti a diverse discipline tradizionali. Qui con il termine
“integrazione” si vuole indicare non solo una stretta aggregazione e
contestualizzazione di conoscenze appartenenti a discipline tradizionali diverse in un
unico corpus conoscitivo memorizzato/utilizzato da un' unica entità (attore singolo o
team integrato di attori diretto da un team leader) ma si allude anche al “valore aggiunto”
(i.e. creazione di nuove conoscenze, denominate anche extraconoscenze
interdisciplinari) risultante da processi virtuosi di crossfertilizazzione o di mappatura
fra elementi conoscitivi appartenenti alle singole discipline [**] e.g. per virtù di una
attività R&S (Ricerca & Studi)
[*] Sull’argomento vedere anche i libri di J.Thompson Klein: “Interdisciplinarity: History, Theory and Practice”
(1990), “Crossing Boundaries: Knowledge, Disciplinarieties, and Interdisciplinarieties” (1996), “Transdisciplinariety:
Joint Problem Solving among Science, Technology and Society” (2001)
[**] “Crossfertilizzazione” in questo contesto fa proprio riferimento all’incrocio di due o piu elementi conoscitivi preesistenti che genera uno o piu nuovi elementi diversi dai precedenti e.g. la definizione del livello massimo di
esposizione a radiazioni elettromagnetiche a microonde per gli esseri umani nasce dalla crossfertilizzazione di nozioni
di elettromagnetismo e biologia (Vedi G.Franceschetti et al. “Esposizione ai campi elettromagnetici”, Bollati
Boringhieri, 2000). “Mappatura” si riferisce alla definizione formale di una “legge di corrispondenza” che lega
elementi di discipline diverse
196
E’ proprio l’ extraconoscenza risultante dai processi di integrazione di elementi
monodisciplinari che segna la differenza fra inter-disciplinarietà e multidisciplinarietà e che, in molti casi, rende un approccio interdisciplinare alla soluzione
dei problemi gestionali complessi più potente e completo di un approccio
multidisciplinare. Tuttavia in pratica l’approccio interdisciplinare alla soluzione di
problemi complessi può risultare più laborioso e costoso di quello multidisciplinare
specialmente nelle sue fasi iniziali, poiché richiede “competenze professionali
trasversali” che vanno opportunamente create e.g. attraverso la creazione di un team
integrato di esperti monodisciplinari sotto la guida di un team leader con capacità
gestionali di progetto (project management) e, esso stesso, con competenze trasversali
(vedi Fig. A5.1). Tutto questo può richiedere il superamento di rivalità fra “centri di
potere” disciplinari protettivi di privilegi acquisiti nel tempo e.g. rivalità fra facoltà
all’interno di una università o fra unità organizzative all’interno di un azienda………
“Chi è il leader del team interdisciplinare integrato?”, “Chi lo finanzia?” “Chi godrà della
gloria in caso di successo o verrà vituperato in caso di fallimento della iniziativa
interdisciplinare?”.
Per “multidisciplinarietà” invece si intende la semplice giustapposizione di
conoscenze monodisciplinari senza creazione di extraconoscenze interdisciplinari e. da
un punto di vista operativo, senza creazione di teams integrati di lavoro. Una
enciclopedia è un testo multidisciplinare, non interdisciplinare. Un corso di formazione
professionale con due insegnanti che insegnano materi diverse se pur complementari è un
corso multidisciplinare.
Introducendo per una “disciplina” una metafora geometrica che la assimila ad
un dominio esteso nello spazio della “conoscenza” (i.e. identificando una disciplina con
un “dominio conoscitivo”, vedi Fig.A5.1), popolato da un certo numero di “elementi
conoscitivi” (e.g. soggetti, classi di soggetti, argomenti, tematiche etc.) atti a spiegare
una classe di fenomeni o a risolvere una classe di problemi, possiamo anche dire che le
conoscenze interdisciplinari più nuove e interessanti risiedono nelle cosidette “overlap
zones” o “zone di sovrapposizione” o “zone di intersezione” fra domini conoscitivi
diversi (piu spesso indicate in letteratura come “boundary zones” o “zone di frontiera”)
dove si trovano elementi conoscitivi che appartengono a discipline tradizionali diverse
ma che in effetti sono rilevanti ad uno stessa classe di fenomeni/problemi reali. Ad
esempio in Fig.A5.1 si vedono elementi conoscitivi appartenenti alle discipline
tradizionali di Ingegneria TLC e Radiologia ma che sono rilevanti ai fenomeni/problemi
reali di Tele-radiologia, dove esami radiologici sono effettuati in zone rurali remote e
sono interpretati a distanza da esperti radiologhi residenti in centri medici di eccellenza.
Stesso discorso vale per la per la TeleMedicina o la Tele-educazione o, in generale, per
una varietà di Servizi di Tele-Assistenza in cui reti e servizi TLC abilitano Servizi di
Tele-Assistenza erogati ad utenti situati in postazione remota rispetto alla sede del
fornitore del contenuto del servizio. Molto spesso la realizzazione di questi servizi
richiede extraconoscenza interdisciplinare, spesso generata da teams integrati di esperti
monodisciplinari diretti da team leaders con competenze trasversali. Ad esempio nel
caso della teleradiologia, costituisce extraconoscenza interdisciplinare la conoscenza
197
delle prestazione di rete TLC atte a garantire la risoluzione radiografica richiesta da un
certo tipo di diagnosi radiologica e.g. neoplasie del seno.
Spazio della Conoscenza
Elementi conoscitivi
di supporto ad
attività di Teleradiologia
Dominio Conoscitivo A
Elementi conoscitivi
di Radiologia di supporto
ad attività di Radiologia
Dominio Conoscitivo B
Zona di Frontiera fra
discipline A e B
Elementi conoscitivi
di Ingegneria TLC di
supporto ad attività di
Ingegneria TLC
Elemento conoscitivo di Radiologia
Elemento conoscitivo di Ingegneria TLC
Extraconoscenza di Teleradiologia
interdis
Fig.A.5.1 Gli elementi di una certa disciplina (che, in una metafora geometrica, occupano un dominio nello
spazio della conoscenza) caratterizzano/spiegano una certa “classe di fenomeni reali” o sono il know how
necessario per svolgere una certa “classe di attività” o sono alla base di competenze professionali per risolvere
una “classe di problemi”. In figura i grandi ellissi orizzontali rappresentano i domini contenitori di elementi
conoscitivi appartenenti alle discipline A e B. Ad esempio gli elementi conoscitivi di “Radiologia” nel
Dominio A supportano attività di Radiologia (cerchi pieni) svolte da radiologi, elementi conoscitivi di
“Ingegneria TLC” contenuti nel Dominio B supportano attività di Ingegneria TLC (cerchi vuoti) svolte da
ingegneri TLC. Si tratta di due “classi di attività” diverse, descritte da discipline diverse e svolte da due classi di
esperti con competeze professionali diverse. Tuttavia esistono “attività interdisciplinari” e.g. Teleradiologia, che
sono supportate da elementi conoscitivi di radiologia e ingegneria TLC assieme a elementi integrati
appartenenti a entrambe le discipline (“extraconoscenze interdisciplinari”). Si tratta di nuove conoscenze
generate dalla cross-fertilizzazione di certe conoscenze monodisciplinari pre-esistenti e.g. per virtù di una
attività di R&S condotta da un team integrato di ricercatori e sono contenute nella zona di sovrapposisizione dei
Domini A e B denominata “zona di frontiera” o “boundary zone”. Un esempio di extraconoscenza
interdisciplinare in Teleradiologia è la specifica dei valori minimi di Larghezza di Banda (Bit Rate) e rapporto
S/N (Bit Error Rate) di un canale satellitare corrispondenti alla risoluzione/fedeltà ottimale di mammografie
(immagini radiografiche del seno) generate in campagne di screening diagnostico condotte in zone rurali di
paesi sottosviluppati.
Nell’ambito della metafora geometrica la creazione di extraconoscenza
interdisciplinare nelle zone di frontiera si manifesta allora come un processo di
“boundary crossing” cioè un “superamento della zona di frontiera fra discipline
diverse” (Vedi Fig.A5.1). Tornando alle TLC oggi sono proprio le zone di frontiera fra
discipline o aree disciplinari diverse, e.g. Business e Engineering, che costituiscono un
terreno fertile dove si generano extraconoscenze interdisciplinari atte a innovare i
processi gestionali in ambito TLC. Si potrebbero fare molti esempi, basta pensare agli
aspetti economici, ecologici e sociali di una qualsisi tecnologia ICT per riconoscere
198
“zone di frontiera” all’intersezione fra le discipline tradizionali Ingegneria TLC-BiologiaSociologia. (“I telefoni cellulari causano danni al cervello dei cittadini e modificano il
loro stile di vita?”). In linea di massima si può parlare di interdisciplinarietà “esterna” fra
le TLC e discipline non-TLC e interdisciplinarietà “interna” fra aree conoscitive
all’interno delle TLC e.g. TLC Engineering e TLC Business. Un questo corso ci
occuperemo esclusivamente del secondo tipo di interdisciplinarietà, ma solo dopo aver
fatto un esempio della prima:
Esempio di interdisciplinarietà esterna (TLC-nonTLC). Consideriamo la tematica
“Effetti sulla salute dei cittadini delle radiazioni elettromagnetiche emesse da antenne
TV”. Si tratta di un soggetto di studio interdisciplinare in cui conoscenze tradizionali di
1) ingegneria TLC/elettromagnetismo e le conoscenze nonTLC di 2) ecologia, 3)
biologia, 4) sociologia sono utilizzate sinergicamente in un unico contesto per risolvere
un problema reale la cui soluzione richiede conoscenze situate nella boundary zone fra
quattro discipline tradizionali e che porta alla creazione di extraconoscenze
interdisciplinari e.g. il concetto di “livello di radiazione sostenibile” da un sistema
biologico (e.g. uomo)
199
Appendice 6 al Capitolo 1 (*)
Elementi di “Marketing” per ingegneri TLC: beni,
servizi e processi TLC.
A.6.1 Il punto di vista «Marketing»: beni & servizi in un contesto TLC
Per poter parlare di gestione dei servizi TLC, riconoscendo che si opera in un
contesto business, è necessario acquisire alcuni concetti di base che appartengono alla
disciplina del «Marketing» o meglio, è importante correggere alcuni concezioni
sbagliate sul «Marketing», talvolta possedute dagli ingegneri TLC, a partire da «cosa è il
Marketing» .
Esistono varie definizioni di «Marketing». L’American Marketing Association
offre la seguente definizione di « Marketing »
DEFINIZIONE A.6.1 Il Marketing è il processo di pianificazione e attuazione della
concezione, definizione dei prezzi, promozione e distribuzione di idee, beni e servizi,
al fine di creare scambi fra individui o organizzazioni tesi al conseguimento dei loro
obiettivi.
Questa definizione può specializzarsi al nostro caso semplicemente sostituendo
«idee, beni e servizi» con «servizi TLC». Ciò che manca in questa definizione è l’enfasi
sul cliente che vive in un mercato competitivo cioè si tratta di una definizione che tratta
fornitori e clienti in modo simmetrico ma non enfasizza il fatto che il marketing non parte
dal fornitore come processo di vendita o promozione di vendite di prodotti già
confezionati ma è un processo che parte dai bisogni del cliente il quale ha la possibilità di
scegliere fra diversi prodotti. In questo contesto il marketing riesce a catturare il cliente
solo se offre al cliente un prodotto che egli percepisce di valore superiore ai prodotti
competitivi.
.
__________________________________
(*) Il contenuto di questa appendice non fa parte delle lezioni impartite nel corso di “Gestione di
Sistemi & Servizi di Telecomunicazioei” presso la Facoltà di Ingegneria delle Telecomunicazioni,
Università Tor Vergata, Roma. Si ritiene possa essere di interesse per quegli studenti che hanno la
curiosità e la voglia di andare un “extra mile” sulle strada della conoscenza interdisciplinare delle
telecomunicazioni
200
In generale, tutto ciò che viene offerto da un fornitore ad un cliente per risolvere i
problemi di quest’ultimo, insorti in conseguenza di desideri/bisogni da soddisfare, viene
chiamato «prodotto». Nel nostro corso, il fornitore di prodotti è un Fornitore di servizi
TLC denominato TelCo e i prodotti sono i servizi TLC. Quindi, per noi il concetto
generale di Marketing si specializza alla concezione/definizione dei prezzi/
promozione/ distribuzione di servizi TLC a una comunità di Utenti da parte di un
Fornitore di servizi TLC (Service Provider, SP).
Il testo classico di Philip Kotler «Marketing Management», Prentice Hall, 2000
identifica dieci tipologie diverse di prodotti fra cui, beni fisici tangibili (e.g. nel nostro
caso, le risorse materiali contenute in un sistema TLC), informazione (e.g. nel nostro
caso, informazione di utilizzazione cioè programma radio-TV, contenuto di una
telefonata o di un e-mail etc.), idee, eventi, luoghi, servizi intangibili (e.g. servizi TLC).
Quindi in un sistema TLC, le tecnologie ICT che supportano i servizi TLC sono
beni materiali tangibili mentre i servizi TLC forniti in un ambiente di business sono
prodotti intangibili. In un contesto Marketing un servizio viene definito come segue
(P.Kotler)
DEFINIZIONE A.6.2 Un servizio è una attività o prestazione che una parte offre ad
un’altra senza che ne risulti proprietà di alcunchè e la cui natura è essenzialmente
intangibile.
Noi lo definiremo in maniera diversa utilizzando il concetto di “funzionalità
TLC” (Vedi Capitolo 4, Parte1). Nel caso dei servizi TLC la attività consiste nel
trasferire/utilizzare informazione con mezzi elettromagnetici e apparecchiature
elettroniche. Ricordiamo che una «prestazione» è una attività rapportata ad una attività di
riferimento (e.g. attività «a specifica »). Beni (i.e. le tecnologie ICT) e servizi (i.e. i
servizi TLC) hanno caratteristiche diverse. Nel corso dimostriamo come la loro differente
natura comporti differenze a livello di gestione.
In questo corso, diremo che i «servizi» sono «prodotti» offerti da un Fornitore di
servizi a un Utente per risolvere i problemi di quest’ultimo. In particolare nel nostro
corso useremo una definizione di servizio TLC in un contesto Business (vedi Tavola
1.2.1.2) e diremo che i servizi TLC sono «prodotti intangibili» forniti da Fornitori di
Servizi TLC ad altri Fornitori di servizi TLC o a Utenti finali, supportati da
tecnologie ICT che da un Punto di Vista Business sono visualizzate come risorse
TLC , «beni materiali tangibili». Più dettagliatamente, utilizzando esplicitamente
alcuni concetti di marketing, possiamo dire quanto segue:
A). Le tecnologie ICT sono beni materiali tangibili e quindi godono delle
seguenti caratteristiche:
1. tangibilità (i.e. sono dotati di caratteristiche verificabili con uno dei nostri
sensi),
201
2. separabilità fra industria (manifatturiera di hardware o sviluppatrice di
software) che li produce e utilizzatore che li utilizza,
3. possibilità di immagazzinamento in attesa di vendita o utilizzazione,
4. disponibilità limitata a certi luoghi di vendita e a certe ore/giorni,
5. divengono proprietà del compratore dopo l’acquisto.
B). I servizi TLC sono prodotti intangibili e quindi godono delle seguenti proprieta’:
1. intangibilità cioè non-tangibilità (definita in precedenza),
2. impossibilità di verifica prima dell’acquisizione del prodotto ma solo
osservazione di una «dimostrazione» del prodotto effettuata dal fornitore,
3. inseparabilità fra Fornitore e Utente che devono coesistere durante la
acquisizione/attualizzazione del servizio (e.g. l’Utente non può effettuare una sessione
telefonica senza che contemporaneamente la società telefonica instauri e mantenga una
connessione circuitale),
4. disponibilità del tipo «7/24/365» (cioè sette giorni alla settimana, ventiquattro
ore al giorno),
5. assenza di proprietà dopo l’ acquisizione/attualizzazione e.g. dopo aver
acquisito un servizio telefonico o effettuato una telefonata non si possiede piu’di quanto
si possedeva prima della telefonata. I servizi si qualificano per il “valore aggiunto”
apportato al cliente piuttosto che per uu trasferimento di proprietà.
6. utilizzabilità limitata alla durata del contratto di abbonamento,
7. facile personalizzazione.
I seguenti esempi mostrano la relazione fra servizi TLC, come soluzione ai
problemi insorti presso un Utente in conseguenza di desideri/bisogni da soddisfare, e i
beni fisici necessari alla pratica realizzazione/utilizzazione dei servizi stessi.
ESEMPIO No.1
i)
Bisogno che uno stakeholder TLC (A) vuole soddisfare:
Comunicare in tempo reale con un altro stakeholder TLC (B)
residente in una località remota.
ii)
Problema da risolvere:
202
Come puo’ lo stakeholder TLC A comunicare con lo stakeholder
TLC B?
iii)
Soluzione del problema e soddisfacimento del bisogno:
A e B acquisiscono un servizio da un fornitore di servizi telefonici
(servizio intangibile) e due terminali d’utente (telefoni, beni fisici
tangibili) da fornitori di apparati telefonici. Connettono i due
telefoni alla stessa rete telefonica (Bene fisico tangibile)
ESEMPIO No.2
i)
Bisogno che uno stakeholder TLC vuole soddisfare:
Il Sig. XYZ ha bisogno di ricevere notizie su ciò che accade nel
mondo nel modo più rapido ed efficace possibile.
ii)
Problema da risolvere:
Come si puù soddisfare il bisogno del Sig. XYZ?
iii)
Soluzione del problema:
Il Sig. XYZ si abbona ad un servizio di telegiornale via satellite
(sevizio intangibile) dalla compagnia SAT-TV e compra un
ricevitore TV satellitare (bene fisico tangibile) dallo stesso
fornitore o da un fornitore di apparati. Connette il ricevitore TV
con la rete di distribuzione (bene fisico tangibile) puntando
l’antenna sul satellite desiderato e si sintonizza sul canale
desiderato (e.g. CNN).
A.6.2 Il «servizio» in un contesto aziendale: processi di business
Nel nostro corso noi parliamo di fornitura di un servizio ad un utilizzatore come
fornitura di una capacità conoscitiva/abilità fisica a svolgere certe funzioni,
(funzionalità) ogni qualvolta l’utilizzatore lo ritenga opportuno, al fine di soddisfarne
certi suoi desideri/bisogni. Parliamo poi di un “Tecnoservizio” in un contesto
Engineering, quando il servizio è fornito da una tecnologia ICT autonoma e intelligente a
un generico utilizzatore esterno e di “Servizio TLC” in un contesto Business quando il
fornitore è una Telco e l’utilizzatore è un Utente (Utilizzatore + Cliente). I due tipi di
servizi sono relazionati dal fatto che una Telco nel ruolo di Network Operator con le sue
reti TLC produce Tecnoservizi che la TelCo stessa nel ruolo di Service Provider
“impacchetta” come servizi TLC e poi fornisce (vende) agli Utenti. “Impacchetta”
significa che la TelCo aggiunge “valore” ai Tecnoservizi (funzionalità di rete U&S)
tramite aggiunta di funzionalità gestionali.
203
In generale possiamo dire che per un generico servizio esistono almeno tre
modalità di descrizione (tutte utilizzate in questo corso):
1)
DECOMPOSIZIONE FUNZIONALE PROGRESSIVA. Viene
effettuata una decomposizione (breakdown) progressiva del servizio in
attività sempre più specializzate fino a raggiungere attività atomiche
non ulteriormente decomponibili («Work Breakdown Structure»). Ad
esempio, vedremo che questo è il caso dei “Servizi di gestione TMN”,
(TMN = Telecommunication Management Network) introdotti
dall’ITU-T nel modello FCAPS i quali sono successivamente
decomposti in tre livelli gerarchici: Gruppi di Insiemi di Funzioni
TMN, Insiemi di Funzioni TMN e Funzioni TMN (atomiche cioè non
ulteriormente decomponibili).
2)
CICLO DI VITA. Il servizio è rappresentato come una sequenza
temporale di «fasi di attività» relazionate in maniera lineare e
ordinate temporalmente in ordine propedeutico cioè il completamento
di una fase è necessario per poter iniziare la fase seguente che ne
utilizza i risultati.
3)
MODELLO DI IMPRESA PER PROCESSI. La componente
gestionale dei servizi TLC forniti dalle Telco sono costituiti da un
insieme di processi rappresentati da un grafo orientato bidimensionale
(diagramma di “workflow”) costituito da una sequenza temporale di
processi (rettangoli interconnessi da frecce). I processi sono
rappresentati a vari livelli di astrazione. Ad esempio si può partire dai
processi al massimo livello di astrazione e poi progressivamente
decomporli in modo iterativo in sotto-processi vieppiù specializzati
(e.g. implementati con procedure automatizzate sempre più specifiche)
fino a raggiungere singole attività e compiti atomici (decomposizione
gerarchica). Questo modello è adottato dal Tele-Management Forum
nel modello “e-TOM” (vedi Appendice 3 al Capitolo 1)
NOTA A.6.2.1 PROCESSI di BUSINESS. I flussi di attività all’interno di una
TelCo sono chiamati “processi” quando si svolgono secondo modalità prefissate
(talvolta standardizzate), accuratamente documentate, strettamente supervisionate
e controllate, utilizzando predeterminate risorse in tempi prestabiliti da parte di
addetti specializzati con compiti/responsabilità predefinite o con tecnologie
specifiche. Nell’ambito di una TelCo lo scopo di questi processi è il raggiungimento di
certi obbiettivi di business specificati nel piano di business (business plan) dell’
impresa definito dal senior management in fase di pianificazione strategica. Per questo
essi sono anche chiamati processi di business (business processes).
Ora ricordiamo ancora una volta che in un servizio TLC esiste una parte “core” e
una parte gestionale. La fornitura della parte gestionale viene effettuata da personale
specializzato o in forma automatizzata all’interno di una TelCo in un “contesto
204
aziendale”. Qui le operazioni avvengono in condizioni altamente supervisionate e
controllate, con procedure prestabilite e documentate, con risorse (uomini e tecnologie)
predefinite e in tempi prefissati e con risultati misurabili i.e. come “processi aziendali” o
“processi di business” . La razionalizzazione/ formalizzazione delle attività all’interno
di una Telco in termini di processi di business apre la porta ad una possibilità (oggi, una
necessità!): l’automazione della gestione dei servizi TLC. Durante il corso spiegheremo
come la gestione di un servizio TLC sia decomposta in due tipi di processi : “processi di
gestione servizi” dedicati a “classi di servizi” e “classi di Clienti” (processi interni) e
“processi di Customer Care” che coinvolgono il sigolo Cliente (processi esterni).
Allocate resources
from existing
resources
3
Inform
customer
4
1
Customer
request
2
Collect
customer
details
Install new
resources
5
6
7
Activate service
& billing
Update
directory
1,2 compiti sequenziali
3,5 compiti paralleli
3,4 compiti alternativi
Fig. A.6.1 Flusso di lavoro nella installazione/attivazione di un servizio TLC (service provisioning).
Nella gestione dei servizi TLC si può riconoscere una moltitudine di partecipanti
specializzati a svolgere compiti specifici (uomini o macchine) che esplicano attività
diverse e cooperano eseguendo “flussi di processi” (prendono decisioni, eseguono
compiti, elaborano/trasferiscono dati, archiviano/ recuparano dati etc.) secondo procedure
prestabilite. Qui si parla di “flusso di processi” (process flow) e non semplicemente di
“processi” poichè si vuole evidenziare il fatto che si tratta di una aggregazione nel
dominio del tempo di processi specifici (i.e. ogni processo ha sue caratteristiche
specifiche ed è svolto da persone o tecnologie specializzate) realizzata secondo una
logica di work flow prestabilita e controllata. Si tratta di processi svolti
contemporaneamente in parallelo, in alternativa o sequenzialmente uno dopo l’altro (vedi
Fig.A6.1)
205
Operatore
Commerciale
Cliente
Richiesta
installazione/
attivazione
servizio
Progettista
Rete
Tecnico
Installatore
NETWORK OPERATOR
Dati
commerciali
Verifica
commerciale
Operatore
Tecnico
Ordinativo
commerciale
Segnalazione
servizio
attivato
Richiesta di
intervento
Verifica
fattibilità
tecnica
Dati
tecnici
Attivazione
(1)
Avviso avvenuta attivazione
Avviso
avvenuta
installazione
SERVICE
PROVIDER
Installazione
(1) Aggiornamento dati tecnici
Persona TLC
Fig.A.6.2a Rappresentazione semplificata di un flusso di processi manuale di “fornitura di servizio”
(service provisioning) come flusso di attività elementari. Ogni attività elementare è preposta
all’espletamento di un compito specifico ed ha una certa durata (tempo di lavoro). Gli intervalli di tempo
che separano le varie attività sono tempi morti. Il Cliente percepisce il tempo complessivo impiegato dal
ciclo processuale e una sua riduzione migliora la qualità del servizio. Se i tempi morti sono dominanti una
riduzione dei tempi di lavoro tramite una semplice automazione delle attività elementari contribuisce poco
a migliorare la qualità del servizio. Se la attività non sono elementari ma sono esse stesse processi la figura
può essere considerata come rappresentativa di un flusso di processi. Per una rappresentazione più
dettagliata del processo di “service ordering” vedere Fig. A.6.2b)
.
206
CUSTOMER
1
2
Sales
Order Handling
(Order)
Service
Request
(Access)
4
Check
Complete
19
Order Status &
Completion
Service
Complete
Service
Configuration
(Install)
12
20
Order
(Inquiry)
WorkForce
Mngmt
Security
3
(Configure)
11
Ntwk
Access
Check
8
7
Install
Complete
Install
Request
Assign.
Request
6
5
18
Assign.
Complete
Ntwk Config. Request
Ntwk Configuration & Routing
Ntwk Provisioning
(Configure)
Ntwk Config. Complete
(Assign/Activate)
17’’
17
Test Request
13
16
17’
Test Complete
Ntwk
Inventory
Mngmt
Update
9
Element
Config.
10
Test
Mngmt
Config.
Complete
Perform Test
14
15
Test Data
Fulfillment
Processes
Ntwk Elem. Mngmt
Ntwk Elements
Assurance
& Billing
Processes
Persona TLC
Fig.A6.2b Flusso di procressi TOM (rettangoli celesti) nel raggruppamento “Fulfillment” relativo a
“Richiesta/Installazione di servizio TLC” . Gli altri rettangoli rappresentano sottoprocessi del processo
“Network Provisionig”. Le frecce rosse tratteggiate rappresentano collegamenti con i processi dei
raggruppamenti “Assurance” e “Billing”. Le frecce bilaterali gialle indicano collegamenti con SP partners.
Notare la corrispondenza con gli attori presenti nella Fig. A6.2a
Notare come la precedente definizione di processo di business sia del tutto
generale e includa anche processi tesi alla produzione di beni tangibili (ICTS) e.g.
207
reti/elementi di rete TLC. Questo tipo di attività non verrà presa in considerazione in
questo corso.
NOTA A.6.2.2 DEFINIZINE ALTERNATIVA di PROCESSO di BUSINESS
In un contesto di organizzazione aziendale la definizione di processo di business
che tradizionalmente si trova nei testi specializzati è la seguente (vedi C.Batini,
Sistemi Informativi”, Volume 1, Franco Angeli, pag.15)
Un processo di business è un insieme di attività fra loro interrelate, finalizzate
alla realizzazione di un risultato definito e misurabile (bene/servizio interno o
esterno)
che
contribuisce
al
raggiungimento
della
missione
dell’organizzazione e che trasferisce valore al ricevitore del bene/fruitore del
servizio.
Struttura Processuale & Struttura Organizzativa
Processo di business sovrapposto ad una struttura organizzativa con due gerarchie
funzionali (Vedi Fig. A7.3) L’esecuzione del processo richiede una distribuzione
cross-funzionale di compiti e responsabilità codificata in procedure prestabilite.
PROCESSO
Fig. A.6.3 Processo di business (o flusso di processi) con il coinvolgimento di dieci unità organizzative
NOTA A6.2.3 Terminologia TMF per “Process flow” e “End-to-end process flow”
2
Flusso operativo (operation process flow)
208
Il TMF ha sviluppato un modello gestionale rappresentato dalla mappa Telecom Operation Map (TOM)
(“Mappa di riferimento dei processi operativi di gestione dei servizi TLC”, vedi Cap.1) popolata da
processi operativi contenuti in vari domini gestionali (i.e domini collocati all’ intersezione di strati
gestionali orizzontali e strisce verticali FAB, vedi Fig.1.1.1 e Capitolo 4). La mappa TOM risulta quindi
essere una library di 15 processi operativi (da noi denominati “processi TOM”), i.e. cinque processi su tre
strati gestionali, ognuno rigorosamente specificato da ingressi, funzioni e uscite (vedi A.6.3) e se necessario
articolato in una serie di sottoprocessi. La aggregazione di “processi TOM”nel dominio del tempo secondo
una logica prestabilita, logica e processi opportunemente scelti per soddisfare una certa esigenza del
cliente (fornitura di “customer service”), si chiama operation process flow o flusso di processi operativi
o flusso operativo.
Ad esempio un flusso operativo “Richiesta & Installazione di un servizio TLC” è un ordito nel dominio del
tempo di processi TOM come mostrato in Fig.A6.1 (e.g. la TelCo riceve in ingresso una richiesta di
servizio da parte di un Cliente, la esamina, soddisfa questa richiesta con l’installazione in rete del circuito
desiderato e in uscita comunica al Cliente l’avvenuta installazione).
3
Flusso operativo end-to-end (End-to-end process flow)
In un libero mercato delle TLC i singoli “processi TOM” possono essere eseguiti da diversi stakeholders,
facenti parte di una “value network” finalizzata alla fornitura di certi prodotti TLC (beni o servizi TLC),
ognuno per la parte di sua competenza. Ad esempio, la value netork può essere costituita da imprese
relazionate da accordi commerciali (secondo un certo “business model”) ed essere finalizzata alla fornitura
di servizi internet a clienti finali. Ogni impresa partecipante svolge i processi TOM di sui competenza.
Facciamo un esempio, considerando uno scenario di “one stop shopping” di un servizio internet. Uun
Cliente richiede a un Internet Service Provider, ISP, un certo “customer service” e.g. Richiesta/
Installazione di un servizio internet. Supponiamo che il Cliente tratti con una singolo ISP ma il customer
service in effetti sia fornito da una rete commerciale di imprese partner (“value network”) e che ogni
impresa svolga i processi TOM di sua competenza e.g. il Network Operator gestisce le reti e il Retailer le
relazioni clienti. La catena di processi svolta dalla “value network” di imprese per fornire il customer
service richiesto si chiama end-to-end process flow o “flusso operativo end-to-end”.
Anzi il TMF offre due possibili definizioni di flusso operativo end-to-end (TeleManagement Forum
“Telecom Operations Map”, Report GB910, Evaluation Version 1.1, April 1999, pagine 4 e 15).
1) DEFINIZIONE GENERALE (Definizione No.1): un flusso operativo end-to-end
è un flusso operativo che contiene tutti i processi TOM necessari ad eseguire in
modo completo un certo compito a partire da un certo ingresso e finendo con una
certa uscita (risultato previsto).
2) DEFINIZIONE RISTRETTA (Definizione No.2): un flusso operativo end-to-end
è un flusso operativo come nella Definizione No.1 ma specializzato al caso in cui il
compito da eseguire è la erogazione al Cliente di uno specifico customer service da
lui richiesto (creazione di valore per il cliente) o è il conseguimento di uno specifico
obiettivo di business di una TelCo (creazione di valore per l’impresa). Il flusso
operativo preso or ora in considerazione è anche un flusso operativo end-to-end
poiché contiene tutti i processi necessari ad eseguire in maniera completa il compito
richiesto. Nel caso di “customer service” e facendo riferimento alla mappa TOM
descritta nel Capitolo 4, i processi TOM nel flusso operativo end-to-end sono scelti
fra tutti i processi della mappa i.e da sinistra (Fulfillment) a destra (Billing) e
dall’alto (Cliente) in basso (Elemento di Rete), pur ricordando che i processi nella
mappa TOM sono poi implementati da una singola Telco factotum (come ai tempi
del monopolio) o da una molteplicità di stakeholders in una value network (come in
un libero mercato e.g. Telco Retailer e Network Provider & Service Wholesaler).
209
A.6.3 Rappresentazione dei processi nel dominio del tempo: i diagrammi dei flussi
di lavoro (workflow)
Come si rappresenta un processo di business? Lo svolgimento temporale dei
processi di business si rappresenta graficamente con diagrammi detti diagrammi di
workflow. La Fig. A.6.1 mostra un esempio molto semplice di un diagramma di
workflow per un processo di business relativo alla richiesta di installazione/attivazione di
un servizio TLC. In questo diagramma l’asse dei tempi è orizzontale da sinistra a destra e
i cerchi rappresentano compiti che devono essere espletati dai partecipanti al processo
e.g. persone, per processi manuali, o tecnologie ICT , per processi automatizzati. In
Fig.A.6.2 il flusso di lavoro (struttura processuale) è mostrato sullo sfondo di una
struttura organizzativa suddivisa in due strutture gerarchiche corrispondenti a due
funzioni di impresa diverse e.g. dipartimento “Engineering” e dipartimento “Marketing”
(processo operativo cross-funzionale svolto da un team interdisciplinare con competenze
professionali provenienti dai vari dipartimenti). I rettangoli bianchi rappresentano le unità
organizzative che contribuiscono esperti al team crossfunzionale responsabile del
procresso. In un processo di business si riconoscono varii elementi. Essi sono:
1. Stimolo d’ingresso (Input trigger)
2. Uscita (Output)
3. Attività/Compiti (Activities/Tasks) collegate fra di loro per fornire un certo
risultato in uscita in risposta ad un certo stimolo di ingresso. Una attività in un processo
può essere elementare o essere a sua volta costituita da sottoprocessi.
4. Risorse, i mezzi necessari per svolgere le attività del processo e.g Persone
(Risorse Umane) , Sistemi & Reti (Hardware), Applicazioni (Software),
I diagrammi di flusso possono rappresentarsi in varie maniere e.g. 1. “Data Flow
Diagrams”, DFD, 2. ), “Workflows on an Intelligent and Distributed Database
Environment”, WIDE o “Action Workflow” rispettivamente basate su dati, attività o
comunicazione. I processi vanno opportunamente gestiti (supervisionati e controllati) con
tecnologie ad hoc e.g. tecnologie di gestione di processo o tecnologie WFMS (Work
Flow Management System). Quindi, tutti i processi vanno opportunamente gestiti, sia i
processi relativi alla parte di utilizzazione dei servizi TLC che quelli relativi alla parte
gestionale. Si tenga infine presente che all’interno di una Telco oltre ai processi di
business relativi alla gestione dei servizi TLC (“processi operativi”) sono presenti
processi di business di altri tipi e.g. processi strategici e processi relativi alla “gestione di
impresa” i.e. gestione del personale, gestione dei sistemi informatici, gestione e sicurezza
degli impianti, gestione acquisto materiali etc. etc. Questi processi sono implementati con
sistemi di gestione d’impresa (EMS, Enterprise Management Systems) che, tuttavia, non
sono oggetto di studio in questo corso.
Appendice 7 al Capitolo 1 (*)
210
Elementi di “Organizzazione Aziendale”per Ingegneri
TLC: la vista interna di una impresa “Telco”
A.7.1 Concetti preliminari rilevanti a una “business enterprise”: cliente,
marketing, innovazione e profitto
Per comodità degli studenti di Ingegneria TLC riportiamo alcuni concetti di
organizzazione aziendale relativi alle imprese TelCo. Prima di esaminare
l’organizzazione interna di una impresa Telco che sviluppa/fornisce servizi TLC,
introduciamo alcuni concetti classici rilevanti alle imprese business (“business
enterprise”, vedi [1],[2],[3] in A7.6)
A.7.1.1
Creazione del “cliente” attraverso la creazione del “valore per il cliente”
Contrariamente a quanto comunemente noi ingegneri TLC siamo portati a credere
una TelCo, organizzazione economico-commerciale basata sulla compra-vendita di beni e
servizi TLC (prodotti TLC) e tesa a soddisfare le esigenze dei suoi stakeholders (interni
ed esterni), è una impresa che necessita dell’ esistenza di Clienti che essa stessa crea [1].
Quindi i Clienti non sono entità a se stanti preesistenti la TelCo cioè “il cliente
(customer) non esiste indipendentemente dall’impresa ma è da essa creato”. In [1]
Peter Drucker insegna: Il primo e fondamentale compito per una “business enterpise” è
creare clienti. Quindi, in base a questa filosofia, è la TelCo che trasforma una persona
fisica o giuridica bisognosa o desiderosa di telecomunicare, in un “Cliente” il quale è
disposto a pagare per un servizio TLC che sia la soluzione dei suoi problemi di
telecomunicazione! Un Cliente che compra un servizio TLC, fornito a certe condizioni di
qualità – prezzo specificate dapprima in una offerta e poi sottoscritte in un Service Level
Agreement, lo considera come apportatore di un beneficio tale da giustificare il
pagamento di un certo prezzo. Il rapporto beneficio/prezzo si chiama anche “valore”.
Quindi, si può anche dire che
1) un cliente sceglie e compra un servizio TLC, cioè sceglie e paga per quel
servizio TLC che egli ritiene costituisca un “valore” ottimale capace di soddisfare al
meglio i propri desideri/bisogni (esigenze) di telecomunicazione. “Soddisfazione” per il
cliente significa allineamento di ciò che è da lui “percepito” (percezione) con ciò che
egli si attende di ricevere (aspettativa).
__________________
(*) Il contenuto di questa appendice non fa parte delle lezioni impartite nel corso di “Gestione di
Sistemi & Servizi di Telecomunicazioni” presso la Facoltà di Ingegneria delle Telecomunicazioni,
Università TorVergata, Roma.. Si ritiene possa essere di interesse per quegli studenti che hanno la
curiosità e la voglia di andare un “extra mile” sulle strada della conoscenza interdisciplinare delle
telecomunicazioni
2) un Cliente si crea “creando valore” per il Cliente stesso
211
Finora abbiamo considerato il rapporto Fornitore-Cliente senza tener conto che in
un mercato libero, cioè un mercato aperto alla concorrenza e con prezzi determinati dal
mercato stesso, un Cliente può ottenere servizi equivalenti da una molteplicità di
Fornitori concorrenti e a prezzi/condizioni diverse. Se vogliamo tener conto della
concorrenza dobbiamo aggiungere a quanto detto sinora che l’acquisizione e il
mantenimento del Cliente da parte di una TelCo avviene solo se la TelCo mette in atto
una strategia capace di procurargli un vantaggio competitivo nel mercato target
prescelto cioè gli permetta di offrire al Cliente non solo “valore” ma un “valore
superiore” ai valori offerti dalla concorrenza. Quindi diciamo che una TelCo deve creare
“valore” per il Cliente, cioè deve cercare la “soddisfazione” del Cliente, superando la
concorrenza. Questo deve esser fatto tenendo conto delle risorse umane e materiali
disponibili e nel rispetto di una Responsabilità Sociale di Impresa.
Ma come fa una TelCo a creare “valore” per il Cliente? Peter Drucker in [1]
insegna che ciò avviene attraverso lo svolgimento di due funzioni fondamentali:
“marketing” e “innovazione”.
CREA CLIENTI CON IL
“MARKETING” & BATTI LA
CONCORRENZA CON
L’ “INNOVAZIONE”
A.7.1.2
Marketing: “Il Cliente cosa vuole comprare”?
Il “marketing” è una attività svolta in maniera proattiva dalla TelCo ed è tipica di
un mercato libero dove più fornitori forniscono servizi equivalenti e competono per la
conquista degli stessi Clienti. In un mercato monopolista il Cliente prende “quello che
passa il convento” ad un prezzo prefissato indipendentemente dal fatto che il servizio
acquisito soddisfi più o meno bene le sue esigenze. Quindi il marketing ha un significato
solo se si è in presenza di una economia libera di mercato e il risultato del “marketing” è
la creazione di Clienti tramite l’offerta di servizi TLC sviluppati partendo dai
desideri/bisogni dei Clienti stessi e in modo tale da vincere la concorrenza. In altre parole
il “marketing” può considerarsi una attività opposta alla “vendita” nel senso che il
marketing parte da una risposta alla domanda “Il Cliente cosa vuole comprare”?
piuttosto che alla domanda “Cosa vogliamo vendere al cliente?” .
Nel primo caso (azione di marketing) si parte dai bisogni/desideri del cliente e si
ritorna al Cliente con ciò che egli vuole offrendo condizioni vantaggiose (prezzo-qualità)
rispetto alla concorrenza. Nel secondo caso (azione di vendita) si parte da un prodotto già
sviluppato e si opera per convincere il potenziale Cliente a comprarlo.
212
A.7.1.3
Innovazione
Con il termine generico “innovazione” si intende uno dei tre possibili tipi di
attività:
1) innovazione dei prodotti e.g immissione sul mercato di nuovi servizi TLC da
parte della TelCo,
2) innovazione sociale i.e. innovazione nel comportamento/valori del Cliente e.g.
nuovi piani di finanziamento degli acquisti, vendita a rate, facilitazioni nei pagamenti etc.
3) innovazione manageriale i.e. innovazione nelle competenze/attività
processuali all’interno dell’impresa per lo sviluppo/fornitura/erogazione/mantenimento
dei prodotti
L’ “innovazione” offre una risposta alla domanda “Quale dovrebbe essere il
business futuro dell’impresa?”. L’innovazione è la creazione di un nuovo “valore” per
il Cliente o, anche, la creazione di un nuovo tipo di soddisfacimento dei bisogni del
Cliente (non necessariamente “invenzione” cioè creazione di una nuova tecnologia).
L’innovazione è necessaria per non divenire obsoleti rispetto alla concorrenza. Il
“marketing” riguarda la creazione di clienti partendo dai loro bisogni mentre l’
“innovazione” riguarda il mantenimento di un vantaggio competitivo rispetto alla
concorrenza offrendo a potenziali clienti nuove sorgenti di valore.
A.7.1.4
Profitto
(Condizione necessaria ma non sufficiente perché l’impresa prosperi in maniera
sostenibile in una economia di mercato).
Alla luce di quanto detto, contrariamente a filosofie economiche abbastanza
diffuse le quali predicano che la “massimizzazione dei profitti” debba essere lo scopo per
il quale un impresa opera, si deve invece riconoscere che il profitto è un requisito
indispensabile perchè gli obiettivi di business dell’impresa possano essere raggiunti.
Il “profitto” è la eccedenza dei “ricavi” risultanti dalla attività di business della
TelCo (nel nostro caso, entrate relative alle vendite dei servizi TLC) rispetto ai “costi”
(relativi alla erogazione/gestione dei servizi TLC), in un dato periodo di tempo. Sebbene
il profitto non sia lo scopo per il quale l’impresa opera, tuttavia la capacità di un impresa
di ottenere profitti consistentemente nel tempo (profittabilità) è una prova della validità
delle sue operazioni ed è una condizione necessaria per il suo successo.
Tutti gli obiettivi di business fissati per l’impresa implicano il rischio di non
essere conseguiti o di essere conseguiti solo parzialmente e quindi richiedono la
creazione di profitti per coprire potenziali perdite. Il profitto è un “indicatore della
performance complessiva dell’impresa” e quindi della bontà del suo Management e, al
213
tempo stesso, una ricompensa per gli stakeholders (non solo gli shareholders cioè gli
azionisti) come compenso per aver preso il rischio di partecipare al business della TelCo
cioè il rischio di subire delle perdite economiche. Se questa ricompensa è equa o esosa e
chi/come debba beneficiare di questa ricompensa sono aspetti molto importanti che, fra
l’altro, coinvolgono la “responsabilità sociale di impresa”. Tuttavia essi esulano dallo
scopo di questo corso. Ad esempio si comprende facilmente che un impresa può ottenere
profitti senza rispettare i dettami della sua responsabilità sociale avvelenando l’ambiente
o affamando i dependenti o non garantendo loro i più elementari diritti dei lavoratori e.g.
cassa malattia, assicurazione infortuni, pensione vecchiaia.
A.7.1.5 I “business objectives” di una “business enterprise”: riassunto in otto punti
Una TelCo è una “business enterprise” incentrata sul cliente che deve conseguire
certi obiettivi di business. Essa ha le seguenti caratteristiche:
“Un impresa di business crea il cliente attraverso
la creazione del valore per il cliente superando la
concorrenza, devono essere quindi soddisfatti certi
obiettivi di marketing (1)
l’impresa deve innovare altrimenti è destinata
all’obsolescenza rispetto alla concorrenza, devono
quindi essere soddisfatti certi obiettivi di
innovazione (2);
tutto ciò avviene utilizzando le risorse umane (3),
finanziarie (4) e materiali (5) disponibili, che
devono essere gestite con la massima produttività
(6) minimizzando inefficienze e sprechi;
ma tutto questo ha costi ed è possibile solo se i
costi sono assorbiti da profitti (7) tali da
compensare il rishio di eventuali perdite, nel
rispetto dei dettami di una Responsbilità Sociale di
Impresa”(8).
Tavola A.7.1
La Tavola A.7.1 offre una caratterizzazione molto semplificata degli obiettivi di
una business enterprise ma si ritiene, sufficiente per i nostri scopi didattici. Essa
identifica 8 aree per gli obiettivi di business (objective areas) (Vedi rif.[1] Cap.8):
214
Business Objective Areas
1.
2.
3.
4.
5.
6.
7.
8.
Marketing
Innovation
Human Resources
Financial Resources
Physical Resources
Productivity
Profit Requirements
Social Responsability
Tavola A.7.2
In ogni area gli obiettivi specifici da raggiungere dependono dalla “strategia”
adottata da ciascun impresa. Gli obiettivi di business ovviamente variano da impresa a
impresa ma in generale sono definiti come segue (Vedi rif.[1] pag.99-100):
DEFINIZIONE A.7.3
“(Business Objectives are): Action commitments through
which the mission of a business is to be carried out and are
the standards against which performance has to be
measured……They must be capable of being converted
into specific targets and specific assignments and become
the basis as well as the motivation for work and
achievements”
Tavola A.7.3
E’ importante avere la consapevolezza che il conseguimento degli obiettivi di
business innesca problematiche non sempre facili da risolvere che richiedono decisioni
strategiche da parte del Management con notevoli dosi di rischio. Ad esempio,
investendo maggiormente nell’innovazione dei servizi TLC e.g. sviluppando nuovi
servizi TLC si possono acquisire quote di mercato (market share) più vaste, ma
1) nel breve termine, maggiori quote di mercato si possono ottenere anche con un
rafforzamento della funzione di marketing. Quindi la decisione di investire in
innovazione piuttosto che in un rafforzamento della funzione marketing significa farsi
carico del lungo termine piuttosto che del breve termine e questa è una scelta molto
importante di natura strategica che deve fare l’impresa. Inoltre
2) una innovazione, che introduca servizi basati su nuove tecnologie, può
richiedere l’investimento iniziale di grossi capitali e, quindi, presentare rischi elevati che
215
vanno confrontati con il rischio di non-innovare affatto. Ad esempio il sistema satellitare
Iridium per la fornitura di nuovi servizi personali di telefonia mobile su base globale,
basato sulla tecnologia LEO (Low Earth Orbiting) particolarmente innovativa, ha
bruciato un investimento iniziale di 5 miliardi di dollari e poi è miseramente fallito.
EXTERNAL
STAKEHOLDERS
PARTNERS
TLC SERVICES
(in)
SHAREHOLDERS, FINANCING
TELCO
ORGANIZATION
(Structure, Politics,
Corporate Culture)
INTERNAL
STAKEHOLDERS
(BoD, Managers,
Employees)
SUPPLIERS
(FORNITORI)
BUSINESS PROCESSES
(cross-functional teams)
RESOURCE
SUPPLY
NON-TLC RESOURCES
OUTSOURCING
SERVICES
(*) Proprietà o noleggio
INTERMEDIARIES
(e.g. shared public
services)
CUSTOMERS
(CLIENTI **)
TLC SERVICES
(out)
(*)
TLC SYSTEM
(TLC RESOURCES)
(**) Altre imprese TLC o Utenti finali
Fig.A.7.1 Il modello di impresa formulato dalla compagnia di consulenza aziendale
“Arthur D. Little” (1992) (Modello ADL) adattatto ad una Telco di elevate prestazioni.
Ogni impresa si struttura e si organizza secondo una propria “missione” e secondo certi
“obiettivi di business”
A.7.2 Il modello di impresa ADL (”high performance enterprise”) della
compagnia “Arthur D. Little” e suo adattamento alla Telco (Fig. A.7.1)
Nel 1992 la comapagnia di consulenza aziendale “Arthur D. Little”, sulla base di
una analisi delle imprese di maggiore successo, formulò un modello di impresa
216
(“Modello ADL”) che identificava i principali elementi costitutivi di un “impresa di
elevate prestazioni” o, in Inglese, “high performance enterprise” (vedi [2] pag.79). Il
modello, da noi specializzato alla TelCo è mostrato in Fig.A.7.1. Gli elementi chiave
individuati nel modello sono quattro e sono mutuamente relazionati come segue: “Una
impresa di elevate prestazioni attua una strategia per la soddisfazione di tutti gli
“stakeholders” (1) e non dei soli azionisti, ottimizza i “processi” (2) di business critici
per la produzione/fornitura di servizi TLC, utilizzando le “risorse” (3) necessarie e
facendo particolare attenzione alla creazione/mantenimento di una opportuna
“organizzazione” (4).
Allora i quattro elementi chiave del modello ADL sono Organizzazione,
Processi di business, Risorse e Stakeholders (interni ed esterni). Una
“organizzazione” a sua volta è caratterizzata da “struttura organizzativa”, “politiche” e
“cultura aziendale”. Gli elementi sono mutuamente relazionati come segue: gli
“stakeholders” svolgono insiemi coerenti di attività (funzioni) di business strutturati
come “processi di business” all’interno di un “organizzazione” al fine di compiere una
propria missione che si articola nel conseguimento di certi obiettivi di business
(business objectives) utilizzando opportune “risorse” (sia materiali che immateriali). Gli
obiettivi si articolano in obiettivi generali di lungo periodo e obiettivi più specifici di
breve o medio periodo ma entrambi hanno una notevole influenza su come
l’organizzazione si struttura. Per una TelCo fornitrice di servizi TLC gli obiettivi di lungo
periodo sono la fornitura/erogazione di servizi TLC alle migliori condizioni possibili di
qualità per il Cliente e di costo per la TelCo (i.e. massima efficacia/efficienza). Vediamo
come tutto ciò possa rappresentarsi graficamente.
In Fig.A.7.1 abbiamo genericamente rappresentato stakeholders, processi e risorse
all’interno di un rettangolo rappresentativo della “organizzazione”. Questo grafico si
giustifica con il fatto che il termine “organizzazione” è anche interpretato come
“organizzazione economica” che sta ad indicare una entità astratta all’interno della
quale e attraverso la quale persone interagiscno al fine di raggiungere obiettivi
individuali e collettivi. (P. Milgrom & J.Roberts, “Economia, Organizzazione e
Management” Vol.I, il Mulino, 1994, p.45). Inoltre è importante riconoscere che,
sebbene entità astratta, una organizzazione ha una identità di persona giuridica o meglio
ha una sua titolarietà giuridica che le permette di “stipulare accordi contrattuali e di
chiedere il rispetto di tali accordi di fronte ad un tribunale” (vedi riferimento precedente,
pag. 46) .
Questo significa che una Telco come organizzazione economica può stipulare
contratti di assunzione di personale (risorse umane) o acquisire risorse tecnologiche (e.g.
tecnologie ICT) tramite acquisto, affitto o leasing delle medesime, con il diritto di gestirle
e, nel caso di proprietà, utilizzarle come vuole (nel caso di affitto o leasing l’utilizzazione
delle risorse può richiedere il rispetto di vincoli come specificato nei relativi contratti).
Noi useremo espressioni del tipo: “l’organizzazione, persona giuridica proprietaria o
affittuaria delle risorse, utilizza le tecnologie ICT contenute nel sistema TLC come
risorse TLC”
217
ORGANIZZAZIONE
(Persona giuridica)
demanda a
forniscono
servizi
gestione
VP HR
Ufficio del Personale
(risorse gestionali)
Dipendenti
(risorse di
utilizzazione)
Risorse umane
PdS
.
A.7.2 Un esperto in gestione del personale può applicare il criterio
della “segregazione delle risorse” dall’organizzazione (persona giuridica)
per evidenziare le varie interfacce che intervengono nei processi di
gestione/utilizzo delle risorse stesse.
Nel tentativo di creare un modello tecno-centrico, nella figura A.7.1 abbiamo
volutamente disaggregato le risorse TLC (i.e. le risorse “viste” da un Ingegnere TLC)
dall’organizzazione che le utilizza. Questo artificio ci permette di creare uno “spazio”
“Risorsa-Utilizzatore” atto ad evidenziare le mutue relazioni risorsa TLC-utilizzatore e.g.
sottoforma di fornitura di tecnoservizi (vedi 2.5 nel Capitolo 2) all’organizzazione da
parte delle risorse stesse. La Fig. A.7.2 mostra come analoga procedura (“segregazione di
risorse”) si potrebbe applicare per altri tipi di risorse qualora l’ interesse fosse quello di
un esperto di relazioni col personale per evidenziare l’interazione fra organizzazione e
risorse umane (personale)
La relazione fra organizzazione (persona giuridica) e risorse può articolarsi in
varie maniere come segue.
1) L’ organizzazione (persona giuridica) detiene la proprietà delle risorse o può,
dietro pagamento, usufruire di qualche forma di affitto o leasing delle medesime in base
alla quale essa utilizza/gestisce le risorse senza possederle.
2) Alternativamente l’ organizzazione può scegliere di utilizzare le risorse
possedute/gestite da soggetti terzi esterni alla Telco, sotto forma di servizi (in
outsourcing) di vario tipo a seconda delle risorse utilizzate (freccia tratteggiata in
218
Fig.A.7.1). In questo caso si stabilisce un regolare rapporto di business fra TelCo e il
fornitore di servizi in outsourcing (azienda esterna).
3) Infine l’ organizzazione può scegliere una forma intermedia fra le due
precedentemente menzionate dove parte delle risorse sono di proprietà, parte sono in
affitto/leasing e parte appartengono a terzi e sono utilizzate sottoforma di servizi in
outsourcing.
CEO
COO
General
Counsel
LEG-REG &
LEGAL
VP
Public
Relations
CTO
CFO
ENGINEERING
VP
Sales &
Marketing
VP
HR
BUSINESS
TEAM
Fig.A.7.3 Il Senior (o Top) Management di una TelCo: sei Vice-Presidenti e un Chief Operating
Officer riportano al President & Chief Executive Officer (CEO). Il Chief Technical Officer
(CTO), il Chief Financial Officer (CFO) e il General Counsel hanno lo stesso livello di
responsabilità dei Vice Presidenti. I Vice-Presidenti gestiscono gruppi omogenei di funzioni
organizzative attraverso Middle Managers (Fig.A.7.4)
A.7.3
Struttura organizzativa di una TelCo: stakeholders interni (Fig.A.7.1 e
Fig. A.7.3)
Le Telco considerate in questo corso sono imprese commerciali fornitrici di
servizi TLC con stakeholders interni mutuamente relazionati da relazioni di lavoro
secondo una struttura organizzativa (organizational structure). Una “struttura
organizzativa” è costituita da raggruppamenti di stakeholders (unità organizzative) di
vario tipo e.g. dipartimenti, divisioni, sezioni, reparti, gruppi di lavoro etc. a loro volta
219
appartenenti a gruppi funzionali ognuno specializzato a una funzione organizzativa
(organizational function).
PROPRIETA’
Finanziatori
(Azionisti)
$
$
B
TELCO
AMMINISTRAZIONE
CdA, Am. Deleg., CEO
TOP MANAGEMENT
(COO + Vice-Presidenti)
MIDDLE MANAGEMENT
C
Gruppi
Funzionali
F1
DIPENDENTI
(Impiegati, tecnici,
operai)
F2 F3 F4
F5 …………. Fn
$
P1
P2
Utenti
PROCESSI di BUSINNESS
P3
A
Fornitori
PRODOTTI TLC
RISORSE MATERIALI
SERVIZI
(Sistema TLC)
$
$
Tecnologie
D
Vendors
Fig.A.7.4 Struttura organizzativa interna di una Telco .
NOTA BENE: E’ stata ignorata la concorrenza
Gli “stakeholders” svolgono insiemi coerenti
di attività (funzioni) di business strutturati
come “processi di business” all’interno di un
“organizzazione” al fine di raggiungere certi
obiettivi di business utilizzando opportune
“risorse”.
220
Interno TelCo
I gruppi funzionali sono gestiti da Middle Managers che fanno capo ai VicePresidenti della TelCo membri del Senior (o Top) Management (Fig.A.7.3 e Fig.A.7.4).
Un Vice-Presidente ha la responsabilità di gestire gruppi funzionali con caratteristiche
simili. All’interno di ogni gruppo funzionale c’è una struttura organizzativa gerarchica.
La Fig. A.7.4 mostra gruppi funzionali (silos verticali) dedicati a varie funzioni
organizzative F1……Fn ognuno gestitito da un Middle Manager che ruiporta ad un
Vice-Presidente. Essi cooperano per la realizzazione degli obiettivi di business
dell’organizzazione. La Fig. A.7.4 mostra un modello di TelCo che rappresenta
“stakeholders” interni assieme alle risorse hardware e software necessarie per
svolgere le loro attività di business e.g sistemi TLC di supporto alla fornitura di beni e
servizi (prodotti) TLC.
Il modello di Fig.A.7.4 mostra che l’impresa è posseduta da una PROPRIETA’
esterna alla TelCo costituita da Azionisti (i.e. “shareholders esterni”, detentori di
“azioni” i.e. titoli che rappresentano il diritto alla proprietà dell’impresa), che si
riuniscono periodicamente in una “assemblea degli azionisti” la quale ha la facoltà di
eleggere un “Consiglio di Amministarzione, CdA” (in inglese, Board of Directors,
BoD….da non confondersi con Bandwidth on Demand!).
All’interno dell’impresa si notano tre livelli di stakeholders supportati da risorse
materiali di vario tipo. I livelli sono:
1) AMMINISTRAZIONE. Consiglio di Amministrazione, CdA ( in USA,
Board of Directors) e Amministratore delegato (in USA, President & Chief
Executive Officer, CEO) i cui membri sono nominati (o demossi!) dagli azionisti riuniti
in assemblea. Il CdA nomina i membri del Top-Management e supervisiona le loro
attività/decisioni
2) MANAGEMENT. La responsabilità della “gestione di impresa” ricade sui
Managers dell’impresa che nel loro complesso costituiscono il “Management” della
TelCo. Esistono più livelli di Managers (il cui numero dipende dalla particolare struttura
organizzativa dell’impresa e.g. “verticale” o “piatta”). Qui consideriamo due livelli: Top
Management e Middle Management.
i) Managers operativi membri del “Top-Management” o “SeniorManagement”, nominati dal Consiglio di Amministarzione, che detengono la
responsabilità della performace economica complessiva dell’impresa e nominano i
Managers dello strato sottostante. In USA si tratta dello strato dei Vice-Presidenti + il
Chief Operating Officer (COO) che tipicamente per una TelCo sono classificati come
segue (Vedi Fig.A.7.3):
1. General Counsel & Vice-president of legislative, legal, regulatory affairs,
responsabile degli affari legali e delle iniziative di regolamentazione in
genere portate avanti in agenzie governative e/o internazionali
221
2. Vice-president of Public Relations, responsabile dell’ìmmagine pubblica
della compagnia e delle relazioni esterne con “social stakeholders” (Vedi
Fig.A.4.2).
3. Chief Technical Officer (CTO), responsabile dei gruppi funzionali di
pianificazione tecnologica, progettazione di rete, contratti con vendors,
operazioni
4. Chief Financial Officer (CFO), responsabile della definizione/
implementazione delle politiche finanziarie e fiscali della compagnia
5. Vice-president of Sales and Marketing
6. Chief Operating Officer (COO), gioca un ruolo di supporto al CEO
specialmente nell’implementazione delle politiche di customer care e
tariffazione
7. Vice-president of Human Resources & Administration
ii) Managers appartenenti al “Middle Management” con compiti/responsabilità
gestionali specifiche relative a un ventaglio di “funzioni organizzative” specifiche (F1,
F2, F3…..) che l’impresa deve svolgere (e.g. contabilità, pianificazione, produzione,
fatturazione, operazioni, marketing e vendite, relazioni clienti, gestione del personale,
affari legali e regolamentazione, etc.). Per ogni Senior Manager esistono più Middle
Managers, in generale fino ad un massimo di otto (management span). La “struttura
funzionale di impresa” a “silos verticali” rappresentati in Fig. A.7.3 dai rettangoli
verticali tratteggiati fu introdotta come “sistema di business” da McKinsey & Co. nel
1980 e ancor oggi costituisce una struttura di base di una TelCo.
3) DIPENDENTI. Sotto l’ ultimo livello di management operano i “dipendenti”
talvolta sfortunatamrente anche chiamati o “risorse umane” o “personale” dell’impresa
(“labor” o “human resources” in inglese) cioè gli impiegati, i tecnici e gli operai che,
sebbene stakeholders indispensabili al successo dell’impresa, tuttavia non hanno una
responsabilità diretta sulla performance economica dell’impresa, ma solo una
responsabilità delegata dal Management sovrastante: responsabilità di svolgere
“funzioni” specifiche nel mglior modo possibile. Ad esempio la responsabilità della
gestione di rete o degli elementi di rete viene delegata a ingegneri e tecnici dell’unità
organizzativa “Gestione Reti” facente parte del dipartimento “Engineering” mentre la
gestione dei servizi TLC è responsabilità di esperti dell’unità organizzativa “Marketing”
facente parte del dipartimento “Marketing & Sales”.
Nel corso di GST vedremo come un futuro ingegnere TLC che lavora in una
TelCo è molto probabile sia chiamato a lavorare in teams crossfunzionali. Notare che è
compito “amministrativo” del Management gestire il personale in maniera da
massimizzare le loro prestazioni (i.e. ottenere da essi alta “produttività”) e, al tempo
stesso, soddisfare le loro aspettative in maniera da avere dipendenti soddisfatti.
222
Ovviamente le due cose vanno assieme: è difficile ottenere prestazioni ottimali da un
personale insoddisfatto!
Infine, gli stakeholders interni all’impresa di business svolgono le loro attività di
business utilizzando
4) RISORSE FISICHE e LOGICHE (physical and logical resources) che
l’impresa 1) possiede e.g. tramite acquisto da fornitori esterni o fatte costruire in proprio
2) prende in affitto, 3) prende in leasing. L’impresa utilizza risorse ICT e non-ICT
contenute in un sistema TLC dedicate alla erogazione di servizi TLC e alla gestione di
reti e servizi TLC, cercando di ottenere da esse Livelli di Prestazione (Level of
Performance, LoP) il più possibile vicini ad un optimum predeterminato che garantisca la
massima soddisfazione dell’utilizzatore (alta efficacia i.e. massima qualità) e cercando
di evitare inefficienze e sprechi in modo da rispettare limiti di costo stabiliti a priori (alta
efficienza i.e. minimo costo).
In definitiva una TelCo, e.g. un impresa di business fornitrice di servizi TLC può
rappresentarsi con il modello di Fig. A.7.3. Il modello mostra una struttura stratificata di
stakeholders interni (Amministrazione, Management, Dipendenti). Si tratta di persone
fisiche che operano con lo scopo di trasformare servizi provenienti da fornitori esterni in
servizi TLC a valore aggiunto da fornire a utenti esterni , utilizzando opportune risorse
fisiche e logiche contenute in un sistema TLC. Una Telco possiede e gli stakeholders
gestiscono e utilizzano parti del sistema TLC. Ricordiamo che qualunque sia il livello di
automazione dei processi di business all’interno dell’impresa, gli utilizzatori ultimi
delle risorse sono sempre delle persone fisiche che hanno la autorità di effettuare
operazioni e sulle quali ricade la responsabilità delle operazioni stesse. I fornitori
esterni che forniscono all’impresa servizi di ingresso (interfaccia “A”), gli azionisti che
detengono azioni della società, i finanziatori, e.g. banche, che hanno inizialmente
finanziato l’impresa (interfaccia “B”), gli utenti (utilizzatori/clienti) che fruiscono dei
servizi TLC in uscita (interfaccia “C”), i Vendors fornitori di risorse (interfaccia “D”)
fanno tutti parte del business e partecipano ai rischi economici ad esso connessi: essi sono
quindi considerati stakeholders esterni. Notare come a differenza degli stakeholder
interni, gli stakeholders esterni possono essere persone fisiche o giuridiche. I
corrispondenti flussi di denaro in entrata e in uscita sono anche indicati in Fig.A.7.4.
ATTENZIONE! All’interno di una TelCo una risorsa logica particolare che in essa viene trasferita,
elaborata, immagazzinata è l’ “informazione”. L’insieme delle informazioni gestite (generate,
utilizzate,elaborate) dai processi di business costituisce il sistema informativo della TelCo. Quella
parte del sistema informativo nella quale le informazioni sono raccolte, elaborate, archiviate,
scambiate mediante l’uso di tecnologie ICT costituisce il sistema informatico.(C.Batini et al. “sistemi
informativi”, Franco Angeli, 2001, pag.18-20)
NOTA BIBLIOGRAFICA. Una buona descrizione della struttura organizzativa di imprese TelCo e
ICTS si trova in P.J.Louis, “Telecom Management Crash Course”, Mc Graw-Hill, 2002, Cap.3
A.7.4 La “catena del valore” di M.E. Porter (Fig.A.7.5)
223
In un mercato ipercompetitivo come quello che spesso si incontra nelle
telecomunicazioni è importante per una TelCo individuare nel suo interno il livello di
produttività delle sorgenti responsabili della creazione del valore per il cliente. Infatti l’
individuazione di queste sorgenti permette la loro ottimizzazione (e.g. riduzione dei
costi) e, da questa, la creazione di un vantaggio competitivo nei confronti della
concorrenza. Il Prof. Michael E. Porter dell’Università di Harvard nel lontano 1985
pubblicò un libro, rimasto famoso, “Competitive Advantage Creation and Sustaining
Superior Performance”, (Free Press) nel quale presentò un modello di impresa da
utilizzare come strumento per identificare all’interno dell’ impresa “le attività sorgenti di
valore” (dal testo inglese, “physically and technologically distinct value activities”). In
questo contesto il “valore” è il valore per il fornitore del prodotto ed è definito da Porter
come segue (traduciamo dal testo inglese) “l’ammontare che il compratore è disposto a
pagare per ciò che l’impresa gli fornisce”. Inoltre Porter prosegue “ Il valore è misurato
dalle entrate totali (total revenue)….L’impresa è profittevole se il valore che essa genera
eccede i costi associati alla creazione del prodotto….Il valore piuttosto che il costo deve
essere usato per analizzare la posizione competitiva (dell’impresa)”. Notare la differenza
fra questa definizione di “valore” e quella precedentemente introdotta legata al
soddisfacimento di un bisogno del cliente.
Il modello, mostrato in Fig. A.7.5 fu poi denominato “Catena del Valore” poiché
mostra il valore totale generato dalla “catena” di attività che, partendo dalla acquisizione
portano alla creazione di un prodotto acquistato dal compratore. Il “margine” (M)
mostrato nelle figura è la differenza fra il valore totale (perimetro esterno) e il costo
complessivo associato allo svolgimento delle attività (perimetro interno). In questo
modello le attività sono suddivise in nove categorie “distinte strategicamente e
tecnologicamente” e raggruppate in due gruppi .
Il primo gruppo è costituito da “attività primarie” tese alla progettazione, produzione,
marketing, fornitura e supporto del prodotto specifico dell’impresa cioè il prodotto (bene
o servizio) per il quale l’impresa stessa è stata creata. Questo gruppo si articola in cinque
categorie: 1. introduzione nell’impresa degli elementi (“materiali” nel modello di Porter
e interpretati da noi nel senso più generale di “beni e/o servizi”) necessari alla
produzione (logistica di ingresso), 2. conversione di questi in prodotto finito (attività
produttive/operative), 3. spedizione del prodotto finito ai mercati target (logistica di
uscita), 4. commercializzazione del prodotto (marketing e vendita), servizi di supporto al
prodotto venduto. Il secondo gruppo “attività di supporto” ha un
224
” di M.E.Porter
La “CATENA del VALORE
Infrastrutturadell’impresa
Gestione delle risorse umane
Attività
di
supporto
Sviluppo della tecnologia
M
Acquisizionerisorse
Logistica
di
entrata
Attività
operative
Marketing Servizi
supporto
&
postvendite
vendite
Logistica
di
uscita
M
Attività primarie
.
Fig.A.7.5 La “catena del valore” cpme originariamente concepita da M.E Porter
carattere generico in supporto alle attività primarie ed è costituita da quattro
categorie che si svolgono durante tutta la sequenza temporale dei macroprocessi primari,
seppure con modalità diverse da un macroprocesso all’altro (linee tratteggiate). Le attività
infrastrutturali sono di varia natura e.g. direzione generale, pianificazione, finanza,
contabilità, servizi legali, relazioni esterne. Seguono poi le attività di gestione delle
risorse umane, sviluppo della tecnologia e acquisizione delle risorse. Non riteniamo
opportuno entrare nei dettagli delle attività di supporto poiché esulano dall’agenda da noi
fissata per questo corso.
L’utilizzazione del modello consiste nell’identificare i risultati/costi di ogni
attività e paragonarli con i corrispondenti risultati/costi della concorrenza, presi come
standard di riferimento (benchmarks). Inoltre si deve tener conto del coordinamento fra le
varie attività. In particolare se le attività sono realizzate da unità organizzative e.g.
divisioni organizzate “per funzioni” esiste il problema che ogni unità è interessata al suo
profitto a scapito del profitto complessivo dell’impresa e inoltre esistono inefficienze
legate alle difficoltà di superamento delle interfacce inter-divisionali. Nella misura in cui
l’impresa riesce a fare meglio della concorrenza essa ha buone possibilità di acquisire un
225
vantaggio competitivo. Per questo nelle imprese moderne le attività sono organizzate “per
processi” e non “per funzioni” laddove ogni processo ha un carattere interfunzionale o
interdivisionale ed è teso al raggiungimento di un obiettivo di business specifico..
VENDOR
M
A
T
E
R
I
E
P
R
I
M
E
Manifatturiera
Componenti
Manifatturiera
Sottosistemi
Rivenditore
Tecnologie
Integratore
Sistema
OEM
TELCO
Fornitore
Contenuti
Operatore
di rete
Venditore
Servizi
Ingrosso
Intermediario
Venditore
Servizi
Dettaglio
Utente
Finale
DATI
Operatore Sistema
Fig. A.7.6 Catena di distribuzione del valore (value chain) per servizi TLC
A.7.5 Il sistema di distribuzione del valore per servizi TLC (Fig.A.7.6)
Un impresa telecom non deve solo occuparsi di come si crea valore al suo interno
ma deve anche creare, attraverso opportune relazioni di business, un sistema di imprese
cooperanti con lo scopo di fornire un prodotto competitivo al cliente finale cioè un
prodotto dotato di un valore per il cliente finale superiore al prodotto fornito dalla
concorrenza. Ogni impresa TLC è specializzata in un certo “settore di attività” i.e. a
seconda dei propri interessi di business, copre un insieme di attività di business facenti
parte di una “filiera di distribuzione del valore”
La Fig.A.7.6 mostra un sistema di distribuzione del valore (filiera di
distribuzione) nella produzione/vendita di beni e servizi TLC. Spostandosi da sinistra a
destra imprese diverse con competenze di base (core competences) complementari
contribuiscono alla creazione del valore di beni e servizi TLC destinati ad un Utente
finale. Le varie imprese sono relazionate da relazioni di business e ogni impresa
acquisisce un prodotto (lato sinistro) e ne produce un altro aumentato di valore (lato
destro). Talvolta le relazioni di business fra le varie imprese che partecipano alla
creazione del valore non avvengono sequenzialmente come nella “catena del valore” ma
avvengono in una “rete del valore” (Fig. A.7.7 e DEFINIZIONE 2.3.3.1) in cui ogni
impresa ha più relazioni di business con
226
una molteplicità di altre imprese. Le relazioni di business fra i partecipanti ad una rete del
valore sono specificate in un “Business Model”. Altri elementi, parte del Business model
sono mostarti in Fig.A.7.8. La Fig.A7.9 mostra come i processi operativi possano essere
“spalmati” sulle imprese partecipanti ad una “rete del valore”
3Pty
Bkr
3-rd
PARTY
SERVICE PROVIDER
TCon
Bkr
3Pty
RtR
Bkr
INTERMEDIARIO/
BROKER
Bkr
ConS
ConS
LNFed
OPERATORE
di RETE
(CONNECTIVITY
PROVIDER)
FORNITORE
SERVIZI al
DETTAGLIO
(RETAILER)
Tcon
Ret
Bkr
CSLN
Tcon
UTENTE FINALE
Fig. A.7.7 Relazioni di business fra stakeholders in una “rete dell valore” (consorzio TINA-C) 1) Bkr =
Broker, 2) ConS = Connectivity service, 3) CSLN = Client-Server Layer Network, 4) LNFed = Layer
Network Federation, 5) Ret = Retailer, 6) RtR = Retailer to Retailer, 7) Tcon = Terminal connection, 8)
3Pty = Third Party. (vedi: TINA-C Deliverable, “TINA Business Model and Reference Points”, Version 4,
May 22, 1997, disponibile on-line)
227
Fig.A.7.8 I componenti di un business Model
A.7.6
Bibliografia e riferimenti
1) “Management: Tasks, responsabilities, practices” Peter F. Drucker, Harper &
Row, 1975, p. 61 e100, o l’edizione italiana “Manuale del Management” Peter F.
Drucker, Etas Libri, Milano, 1986).
2) “Marketing Management” Philip Kotler, Prentice Hall, 2000, o l’edizione
italiana “Marketing Management” P. Kotler (11-ma edizione a cura di Walter G. Scott)
Pearson/Prentice Hall, 2004
3) “Competitive Advantage Creation and Sustaining Superior Performance”,
Michael Porter, Free Press, 1985
4) “Telecommunications Management” Nolan Vincent Jones,
Virtualbookworm.com Publishing, Inc. 2004
5) “Telecom Management Crash Course”, P.J. Louis, McGraw Hill, 2002
6) “Economia, organizzazione e management”, P.Milgrom, J.Roberts, il Mulino,
1992
228
Sales
Order Handling
Rating &
Discounting
Broker
Sales
Order Handling
Problem
Handling
Customer QoS
Management
Invoicing &
Collections
Service
Planning
& Development
Service
Configuration
Service Problem
Management
Service Quality
Management
Rating &
Discounting
Retailer
Service
Planning
& Development
Service
Configuration
Service Problem
Management
Network
Provisioning
Network
Inventory
Management
Customer
Customer
Service Quality
Management
Rating &
Discounting
Network Data
Management
3°Party SP
Network
Planning
& Development
Network
Provisioning
Network
Inventory
Management
Network
Maintenance
& Restoration
Network Data
Management
Connectivity Provider
Fig.A.7.9 Un flusso operativo end-to-end è costituito da processi operativi presi dal modello
TOM (vedi Fig.1.1.2). Questi processi possono essere “spalmati” su business stakeholders
che svolgono diversi ruoli di business e sono legati da relazioni di business in una “value network”.
(Vedi Fig.A.7.7) La figura mostra cinque ruoli di business, le possibili relazioni di business e i processi
operativi del modello TOM rilevanti a ciascun ruolo. (Consorzio internazionale TINA-C)
229
CAPITOLO 2
Ambiente Engineering: gestione delle
tecnologie ICT in un sistema TLC (6h)
2.1
Tecnologie ICT: Punti di Vista “System Architect” e “Network
Operator”
2.2
Struttura tecnologica di un sistema TLC: “Gerarchia di Contenimento”
2.3
Tipologia di Tecnologie ICT in un sistema TLC: gerarchia di ereditarietà
(tassonomia)
2.4
Gli “stati” di una tecnologia ICT: funzionalità primarie, funzioni
primarie e condizioni di funzionamento.
2.5
“Tecnoservizi” forniti dalle Tecnologie ICT
2.6
“Livello di Prestazione” di una Tecnologia ICT e sua relazione con la
“Qualità di Servizio” di un servizio TLC
Appendice 1 al Capitolo 2
Modello Generico di Rete (Generic Network Model, GNM) di Chen & Kong
230
CAPITOLO 2
Ambiente Engineering: gestione delle
Tecnologie ICT in un sistema TLC
SOMMARIO
Un sistema TLC reale è una infrastruttura di risorse fisiche, logiche, energetiche abilitante i
servizi TLC. Esso è costituito da componenti ICT e da componenti ausiliari nonICT contenuti in reti
TLC e terminali ad esse connessi (Fig.2.1.1). Modelli gestionali di componenti ICT, possono essere
sviluppati adottando vari Punti di Vista. In questo capitolo scegliamo il Punto di Vista Engineering
(punto di vista di un team integrato di esperti in ingegneria TLC, ingegneria informatica, ingegneria
elettronica e ingegneria gestionale). Da un Punto di Vista Engineering i componenti ICT di un sistema
TLC sono visualizzati come Tecnologie ICT : tecnologie U&S e tecnologie gestionali OS (gestione
elementi di rete), NSS (gestione reti), OSS (gestione servizi), BSS (gestione CRM). In questo capitolo
ci limiteremo alle prime due. Un Punto di Vista Engineering può a sua volta essere decomposto in un
insieme di Punti di Vista parziali adottati dal personale tecnico di imprese TelCo (fornitori di servizi) o
ICTS (manifatturiere fornitori di tecnologie) alla luce delle loro competenze professionali. In una
TelCo noi visualizziamo le Tecnologie ICT contenute in un sistema TLC reale con gli occhi di un
System Analyst & Architect (specifiche di sistema di Tecnologie ICT future) e di un Network
Operator (utilizzatore/gestore di Tecnologie ICT già oggi commercialmente disponibili). L’enfasi sarà
sulle caratteristiche gestionali delle Tecnologie ICT.
Nei par. 2.2. e 2.3 ci occupiamo delle “strutture gerarchiche” delle Tecnologie ICT
all’interno di un sistema TLC. Gli “stati” in cui possono trovarsi le Tecnologie ICT sono studiati nel
par.2.4. Poi trattiamo dei “tecnoservizi” forniti da Tecnologie ICT ad utilizzatori esterni (par. 2.5).
Infine introduciamo il concetto di “Livello di Prestazione (Level of Performance, LoP)” di una
Tecnologia ICT e lo mettiamo in relazione col concetto di “Qualità di Servizio (Quality of Service,
QoS)” di un servizio TLC (par.2.6).
ATTENZIONE ai Punti di Vista! Ribadiamo ancora una volta che una stessa
entità reale, uomo o macchina, può essere visualizzata e quindi gestita in
maniera diversa se osservata da Punti di Vista diversi. Da un Punto di Vista
Engineering una rete TLC reale è visualizzata come un ordito di “Tecnologie
ICT” mentre da un Punto di Vista Business essa è visualizzata come un insieme
di “Risorse TLC” necessarie a supportare le attività del business TLC di una
TelCo e.g. fornitura/erogazione di servizi TLC. Un telefono cellulare, oggetto
oggi indispensabile, agli occhi di un ingegnere TLC (Punto di Vista
Engineering) rivela le meraviglie delle tecnologie digitali e delle
telecomunicazioni wireless (tecnologia ICT) mentre agli occhi di un qualsiasi
Utente di un Servizio TLC (Punto di Vista Business) è semplicemente una
risorsa materiale che serve a fruire dei servizi di telefonia cellulare (risorsa
TLC). La applicazione formale della Metodologia dei Punti di Vista (Appendice
4 al Capitolo 1) ci permette di trattare le varie “Viste” di uno stesso “oggetto” in
maniera unificata e di evidenziare di volta in volta le cose che ci interessano
ignorando tutto il resto. Essa si adatta pefettamente ad un approccio
interdisciplinare alla GST.
231
ABILITAZIONE dei SERVIZI TLC
ADDETTI alla
GESTIONE TLC
(Persone fisiche reali)
SISTEMA TLC
(Infrastruttura reale)
Funzionalità
Punto di
Vista
Business
Engineering
Interconnessione,
Distribuzione
Intermediazione.
Accesso
(Reti)
(Terminali)
TLC
Tecnologie
implementative
(e.g. rete
postale)
Componenti
ausiliari nonICT
Strutture
meccaniche,
Fonti energ.
Impianti,
Edifici etc.
Componenti ICT
X
Rete autoferroviaria
Trasporto
aereo
Sistema
informatico
rete postale
Reti
U&S
Reti di
Gestione
(Sistema
Informatico
Gestionale)
Vista
nonTLC
nonTLC
TLC
(e.g.sistema di
accesso alla
rete postale)
Struttura
Meccanica
Terminale
TLC
Struttura
meccanica
sportello
o cassetta
postale
X
Sistema
informatico
sportello
postale
Risorse
RisorseTLC
TLC
man-made
man-made
(Risorse
(RisorseTLC)
TLC)
“mezzo” per svolgere
attività di Business e.g.
oggetto di compra-vendita
fra TelCo e ICTS
Terminali
U&S
Terminali
di Gestione
Tecnologie
TecnologieICT
ICT
“prodotto” risultato di attività di
Engineering e.g. progettazione/
costruzione.
Bus Eng relation
Fig.2.1.1 Schema illustrativo della relazione fra “sistemi TLC” e “Tecnologie ICT”
232
CAPITOLO 2
Ambiente Engineering: Gestione delle
Tecnologie ICT in un sistema TLC
2.1 Tecnologie ICT: Punti di Vista “System Analyst
& Architect” e “Network Operator”
La Fig.2.1.1 mostra come in questo corso noi adottiamo i Punti di Vista
Engineering e Business per ottenere Viste Engineering e Business dei sistemi TLC.
(anche denominate “Ambiente” Engineering e Business). Da questi due Punti di
Vista si visualizzano i componenti ICT come “Risorse TLC” utilizzate da Business
Stakeholders in un Ambiente Business per supportare i servizi TLC o come
“Tecnologie ICT” prodotte/gestite da Engineering Stakeholders in un Ambiente
Engineering. Quindi per Tecnologie ICT si intendono i componenti ICT di un
sistema TLC reale messi a fuoco da un Punto di Vista Engineering. Esempi di
caratteristiche di una Tecnologia ICT sono mostrati nella Tavola 2.1.1. Se avessino
osservato un componente ICT di un sistema TLC da un Punto di Vista Business ne
avremmo evidenziato caratteristiche diverse di natura commerciale (e.g. vedi Tavola
4.1.1 del Capitolo 4). Il sistema informatico gestionale (rettangolo in basso a sinistra
in Fig.2.1.1) è costituito da sistemi OS (Operations Systems), NSS, (Network Support
Systems), OSS (Operations Support Systems) e BSS (Business Support Systems) che
supportano diversi tipi di gestione come mostrato in Fig.1.2.4.2. In questo capitolo
noi ci occuperemo di Reti e Terminali U&S e dei loro sistemi di gestione OS e NSS.
•
La specializzazione del Punto di Vista Engineering nei Punti di Vista di
“System Analyst & Architect” e “Network Operator” (Fig 2.1.2)
Una caratteristica della Metodologia dei Punti di Vista da noi adottata è la
possibilità di utilizzare una procedura di “refinement” e suddividere il singolo Punto
di Vista in più “sotto”- Punti di Vista che mettono a fuoco i dettagli di sottoinsiemi
della Vista originale. Applicando questa procedura, il Punto di Vista Engineering
può specializzarsi nei Punti di Vista degli attori Engineering (ingegneri, tecnici,
operai) all’interno di imprese TelCo o ICTS (Fig.2.1.2):
1)
Pianificatore (di nuove Reti e/o Terminali TLC)
2)
Analista & Architetto di Sistema,
233
3)
Esperto di Tecnologie ICT, Progettista di Tecnologie ICT
4)
Costruttore di Tecnologie ICT
5)
Operatore di Rete (Network Operator)
VISTA “BUILD” dei COMPONENTI ICT
di un SISTEMA TLC
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
specifiche tecniche di funzionamento (*)
creazione & analisi del modello
scelta tecnologie implementative (**)
specifiche strutturali e di sistema (**)
tecniche di progettazione/progettazione (**)
specifiche di costruzione
prototipazione del prodotto
procedure collaudo prototipi
assemblaggio e/o integrazione componenti
costruzione prodotto finale e collaudo
industrializzazione
installazione
esercizio
manutenzione
riparazione
sostituzione
disinstallazione
(*) Inclusa parte gestionale
(**) Tiene conto della normativa vigente e, se necessario, di standards tecnici
Tavola 2.1.1 Esempio di caratteristiche di una Tecnologia ICT, Vista Engineering
di un componente ICT. Diversi Engineering Stakeholders e.g. System Analyst,
System Architect, Network Operator “visualizzano” caratteristiche diverse.
234
Punto di Vista Engineering
Planner
System
Analyst &
Architect
Technologist
Designer
Manufacturer
Ntwk
Operator
Punti di Vista
Parziali fra
Osservatori
Engineering
Reti e Terminali U&S
OS,NSS
Plannnig
System
Model &
Spec.
Design
Finished
Engineering
Product
Ntwk Installetion
Operation
Maintenance &
Repair.
Viste
Engineering
parziali
Punti di Vista parziali adottati nel Capitolo 2
della Parte 1
Persona decomp
Fig.2.1.2 Le reti e Terminali U&S e relativi sistemi gestionali possono essere osservate da un Punto di
Vista Engineering. Il punto di Vista Engineering può essere specializzato in Punti di Vista (parziali),
supportati dalle competenze professionali di cinque gruppi di esperti in imprese TelCo e ICTS. Ogni
gruppo rappresenta anche una opportunità di lavoro per futuri Ingegneri TLC. Il Capitolo 2 si riferisce
alle Viste di System Analyst & Architect e Network Operator.
Osservando Reti e Terminali U&S e relativi sistemi di gestione da questi
(sotto) Punti di Vista se ne mettono a fuoco le seguenti caratteristiche:
1)
Pianificazione,
2)
Analisi e specifica di sistema
3)
Progettazione
4)
Costruzione
5)
Istallazione, controllo delle prestazioni, manutenzione, riparazione
delle Tecnologie ICT
235
Allora ci chiediamo: Quali sono le Viste che vogliamo prendere in
considerazione in questo capitolo? Per rispondere osserviamo che noi siamo ingegneri
TLC interessati a sistemi OS e NSS finalizzati alla gestione presente e futura delle Reti
U&S e Terminali U&S e che ciò può farsi svolgendo due ruoli: 1) come “Network
Operator” che utilizza sistemi gestionali già esistenti oppure 2) come “System Analyst
& Architect” che specifica futuri sistemi gestionali. Allora in questo Capitolo noi
studieremo la gestione di Reti U&S (e relativi “Elementi di Rete”) e Terminali U&S
adottando i Punti di Vista parziali “System Analyst & Architect” e “Network
Operator”.
2.1.1
Alcune definizioni di “sistema TLC” (vedi Tavola 1.0.2.1)
In questo paragrafo cominiciamo col definire nel modo più generale possibile
cosa sia un “sistema TLC reale” in termini della sua struttura interna (i.e. architettura
delle Tecnologie ICT).
Una definizione del tutto generica di sistema TLC reale (all’interno della società
di riferimento nell’anno 2008) è la seguente: un “sistema TLC reale” è una
infrastruttura fisica, logica, energetica abilitante i servizi TLC, costituita da reti
TLC e da terminali connessi ad esse.
RETI di COMUNICAZIONE ELETTRONICA (RCE)
“ Sistemi di trasmissione e, se del caso, apparecchiature di commutazione o di
istradamento e altre risorse che consentono la trasmissione di segnali via cavo, via radio, a
mezzo di fibre ottiche o con altri mezzi elettromagnetici, comprese reti satellitari, reti
terrestri fisse o mobili (a commutazione di circuito o pacchetto, compresa internet) sistemi per
il trasporto di corrente elettrica, nella misura in cui siano utilizzati per trasmettere segnali
elettrici, reti usate per la diffusione circolare di programmi radio o televisivi, reti per televisione
via cavo, indipendentemente dal tipo di informazione trasportata”
TAVOLA 2.1.1 Nel 2002 la Comunità Europea ha cambiato il termine
“Telecomunicazione” in “Comunicazione Elettronica” ed ha fornito nuove definizioni
di reti e servizi. Questa è la definizione di rete TLC contenuta nella direttiva 2002/21/CE
del Parlamento Europeo (07/03/2002) e utilizzata sia nel Codice della Privacy
(D.lgs.196/2003) che nel Codice delle Comunicazioni Elettriche (D.lgs.259/2003)
Una seconda definizione un poco più dettagliata è la seguente: un sistema TLC
reale è un insieme di componenti ICT e “componenti ausiliari nonICT”
interconnessi e cooperanti. I componenti ICT sono : “equipaggiamento di rete
U&S e di rete di gestione” (e.g. linee di trasmissione elettromagnetiche, switches,
routers, multiplexers, ripetitori etc. sistemi gestionali e.g. OS, NSS, OSS,
BSS),“terminali U&S o di gestione”(e.g. telefoni, computers, televisori, radio, fax
machines , etc.) atti ad elaborare e/o trasportare informazione, al fine di produrre/
236
fornire/acquisire/utilizzare servizi TLC nel rispetto di normative erogate da
istituzioni/governi locali, nazionali o internazionali (e.g. Comunità Europea), di
cui una parte è identificata come normativa specifica delle TLC (“legislazione e
regolamentazione TLC”).
Questa nostra definizione può essere utilmente paragonata alla definizione di
rete TLC riportatata nella Tavola 2.1.1 (denominata “Rete di Comunicazione
Elettronica”) fornita dalla Comunità Europea nel 2002.
Per “equipaggiamento di rete” qui si intendono sia le apparecchiature di
elaborazione/immagazzinamento dati, residenti nei nodi di una rete TLC sia le
relative linee di trasmissione che interconnettono i siti nodali. Esse sono anche
denominate “componenti” o “ elementi”della rete TLC. Una rete TLC comprende una
parte interna (rete di trasporto) inclusa in una parte esterna (rete di accesso)
Per “terminale U&S” (“user terminal”) o “apparecchio terminale”
(terminal equipment) o “terminale” qui si intende una apparecchiatura elettronica
esterna alla rete TLC ma ad essa direttamente o indirettamente connessa e.g. via
LAN, che permette a persone fisiche di fruire dei servizi TLC abilitati dalla rete
stessa e che interfaccia direttamente con esse (e.g. telefono, computer, apparecchio
radio, televisore, macchina fax etc.). Quindi un terminale è una apparecchiatura di
intermediazione rete-uomo delimitata da due interfacce: una interna verso la rete
(User-Network Interface, UNI) e una esterna verso l’ utilizzatore (interfaccia
“Uomo-macchina” e.g. Graphic User Interface)
Per “componenti ausiliari nonICT” qui si intendono tutte gli elementi di un
sistema TLC non specifici delle TLC ma che sono tuttavia necessari alla
realizzazione/funzionamento del sistema stesso. Si tratta di componenti del sistema
TLC realizzati senza tecnologie ICT con e.g. strutture meccaniche di supporto alle
tecnologie ICT, sbancamenti per alloggiare cavi, strutture murarie degli impianti,
edifici, impianti di produzione di energia elettrica, impianti di condizionamento
ambientale nelle sedi delle apparecchiature di rete etc. Quindi un sistema TLC reale è
costituito da “tecnologie specifiche delle TLC” (Tecnologie ICT, manufatte da
imprese ICTS ) e “componenti nonICT ma utilizzate per scopi TLC” (prodotte in
ambienti e con competenze professionali nonTLC).
237
“Aree Tecnologiche Gestite”
Terminologia nella
Raccomandazione M.3200
dell’ITU-T (04/97)
Nostra terminologia
per le Tecnologie ICT (*)
Equipaggiamento di rete &
Terminali
5.11 Access & Terminal
Equipment Network
Equipaggiamento rete
trasporto
5.12 Transport Network
Componente di Supporto
5.13 Infrastructure
(*) U&S + gestionali
Rac.3200
Tavola 2.1.1.1 Nostra terminologia e terminologia dell’ITU-T
NOTA 2.1.1.1 Da un punto di vista gestionale la ITU-T usa la terminologia mostrata nella
Tavola 2.1.1.1
2.2
Struttura tecnologica di un sistema TLC:
“Gerarchia di Contenimento”
Ricapitoliamo quanto detto finora in questo Capitolo. Abbiamo visto che un
sistema TLC reale è costituito da reti TLC (suddivise in reti U&S gestite e reti di
gestione in base alla natura dei flussi informativi che esse trasportano) alle quali sono
connessi terminali TLC (suddivisi in terminali U&S connessi con le reti U&S e
terminali di gestione connessi con le reti di gestione). Abbiamo anche visto che un
sistema TLC reale in effetti contiene componenti ICT (equipaggiamento di rete e
terminali TLC) e componenti ausiliari nonICT (strutture meccaniche, viarie,
murarie, fonti di energia, impianti idraulici e di condizionamento ambientale etc.).
Ovviamente noi, nel corso di GST, non siamo affatto interessati nei
componenti ausiliari nonICT. Siamo invece molto interessati a studiare le
caratteristiche Engineering (struttura e funzionamento) dei componenenti ICT
(particolarmente quelli gestionali). Più precisamente noi studiamo Reti e Terminali
U&S e relativi sistemi gestionali come Tecnologie ICT. Ciò significa anche che in
questo capitolo ne ignoriamo gli aspetti commerciali (e.g. prezzi, disponibilità sul
mercato etc.)
238
Lo studio della gestione di Reti e Terminali U&S e relativi sistemi gestionali è
molto vasto. Nel rispetto di vincoli amministrativo-didattici, noi in questo corso
ignoreremo le problematiche relative alla scelta delle tecnologie implementative e alla
progettazione e costruzione di OS e NSS. Ci limiteremo a considerare due Punti di
Vista parziali basati sugli interessi/conoscenze/ competenze di un System Analyst &
Architect (creazione di modelli gestionali per future tecnologie) o di un Network
Operator (utilizzazione di OS/NSS già oggi commercialmente disponibili).
SPACECRAFT
BUS
COM. PAYLOAD
PROPULSION
SYSTEM
ELECTRIC POWER
(Solar panels, Batteries)
TRANSPONDERS
RECEIVERS
LNA
MIXER
LO
POST
AMP
TRANSMITTERS
BBOBP
SATELLITE
CONTROL
MODEM
SWITCH
ANTENNAS
TELEMETRY& COMMAND
TELEM. UNIT
TELEM. TRANSMITTER
COMMAND UNIT
FEEDS
COMMAND RCVR
REFLECTORS
TELEM. ANTENNA
COMMAND ANTENNA
Mondo TLC
Fig. 2.2.1A Tecnologie ICT (contorni neri) e “componenti ausiliari nonICT” (senza contorno)
in un satellite geostazionario per TLC. Se noi ingegneri TLC nel ruolo di Network Operator
osserviamo il satellite dal Punto di Vista Engineering “visualizziamo” nei minimi dettagli le
Tecnologie ICT (i.e. Communication payload e T&C). Notare la “gerarchia di contenimento”
fra i vari componenti del satellite e l’integrazione fra Tecnologie ICT e nonICT. Se si osserva
il satellite da un Punto di Vista Business (e.g. Punto di Vista del CEO di Telecom Italia) lo si
vede non come un insieme di tecnologie ICT bensì come un insieme di Risorse necessarie per
svolgere attività di business TLC . La rappresentazione è a “scatole annidate” (bambole
russe). Una rappresentazione ad “albero” è mostrata in Fig.2.2.1B
Gerarchia di contenimento delle tecnologie (Livelli Tecnologici):
Livello quattro: viola
Livello tre: giallo
Livello due: blue
Livello uno: marrone
Livello zero: verde
239
SPACECRAFT
COMMUNICATION
PAYLOAD
BUS
TELEMETRY
&
COMMAND
TLMT
Unit
SATELLITE
CONTROL
TLMT
Transmitter
TLMT
Antenna
ELECTRIC
POWER
CMND
Antenna
PROPULSION
SYSTEM
ANTENNAS
TRANSPONDERS
Feed
Array
CMND
Receiver
CMND
Unit
Receiver
Transmitter
On Board
Processor
DISPOSITIVI
LNA
Mixer
LO
Post
Amplifier
Modem
BBSwitch
Fig.1.2.2.1B Rappresentazione ad albero della.1.2
gerarchia
.2.1A di Fig
Fig.2.2.1B Rappresentazione ad albero della gerarchia di Fig.2.2.1A. I livelli gerarchici sono
codificati con gli stessi colori di Fig.2.2.1°
2.2.1
Strutture gerarchiche all’interno di sistemi complessi
Consideriamo i componenti ICT di una Rete U&S e concentriamoci su
quelle caratteristiche che sono rilevanti alla loro gestione. Facciamo in particolare
riferimento alla Vista di un Network Operator cioè il gestore della rete. Una sua
osservazione, certamente accurata e informata, rivela subito che questi componenti
fanno parte di una struttura con una architettura gerarchica. Più precisamente si
tratta di una gerarchia di “contenimento”. Di cosa si tratta? Vediamo
240
Reflectors
Nell’ ingegneria TLC quando si parla di ordinamento gerarchici la prima cosa
che viene alla mente sono i procolli di comunicazione e la “pila OSI” a sette strati
sovrapposti in un ordinamento che va dallo strato fisico (livello uno) allo strato
applicativo (livello sette). In seconda istanza vengono in mente le reti TLC che a loro
volta contengono sottoreti TLC che a loro volta contengono sotto-sotto-reti TLC fino
ad arrivare a reti locali che si sviluppano all’interno delle singole utenze. In entrambi
i casi si riconoscono componenti opportunamente ordinati secondo certi criteri che
noi denominiamo “criteri gerarchici”: uno strato inferiore sta sotto uno strato
superiore, una sotto rete è contenuta in una rete e una rete è a sua volta contenuta in
una super rete.
Torniamo ora alla nostra rete U&S e occupiamoci degli ordinamenti
gerarchici che caratterizzano la sua struttura tecnologica interna proprio come si fa
nell’analisi di un qualsiasi sistema complesso. Facciamo questo per due motivi: 1)
perché è proprio sugli ordinamenti gerarchici delle strutture tecnologiche di un
sistema TLC che si basano i modelli gestionali che studieremo nella seconda parte del
corso. 2) perché le gerarchia tecnologica ha un impatto sulla gestione del sistema: non
si può gestire un livello superiore se prima non si è gestito il livello inferiore (non
posso gestire un ricevitore se non ho prima gestito LNA, mixer, oscillatore locale,
post-amplificatore).
•
Complessità di sistema e gerarchie
Un sistema TLC è un sistema reale complesso. La complessità è doppia:
complessità hardware e software. Un sistema TLC ha infatti una “architettura
fisica” complessa ed opera secondo una “logica” complessa. G.Booch a pag. 12 del
suo prezioso libro sull’orientamento agli oggetti “Object Oriented Analysis and
Design”, Addison Wesley, 1999, insegna che in ogni sistema complesso naturale o
manufatto dall’uomo e.g. sistemi biologici, industriali, commerciali, sociali, si
possono riconoscere almeno due gerarchie fondamentali: una gerarchia di
ereditarietà, anche denominata gerarchia “is a”, che determina una “Struttura a
Classi” del sistema e una gerarchia di contenimento, anche denominata gerarchia
“is part of”, che determina una “Struttura a Oggetti” del sistema. G.Booch poi
indica che entrambe gerarchie vanno tenute in considerazione se si vuole ottenere una
rappresentazione cosiddetta “canonica” del sistema.
Nel corso di GST noi siamo interessati alla gestione delle Tecnologie ICT
contenute in un sistema TLC. Il riconoscere che un sistema tecnologico complesso sia
strutturato secondo criteri gerarchici significa poter creare modelli gestionali
modulari particolarmente efficaci/efficienti e.g. senza ridondanze e con ri-uso dei
moduli (proprietà di “ereditarietà”). Come?
Vedremo nella Parte 2 del corso che il padre di tutti gli standard gestionali,
lo standard gestionale OSI-SM (Open Systems Intercoinnection- System
Management) dell’ITU-T si basa su software con costrutti linguistici denominati
“maschere di classe” (il cosidetto linguaggio GDMO, Guidelines for the Definition of
241
Managed Objects) basate su una gerarchia di ereditarietà e adotta tecniche di
denominazione degli “oggetti gestiti” basate su “alberi di contenimento” che
incarnano gerarchie di contenimento (vedi anche par.2.2.5). Quindi riconoscere una
struttura gerarchica nel sistema TLC reale significa poi utilizzare questa proprietà di
sistema nella costruzione di modelli gestionali particolarmente efficaci/efficienti.
In effetti la struttura gerarchica delle Tecnologie ICT ha conseguenze
importanti non solo nello sviluppo di modelli gestionali ma anche in un Ambiente
Business e.g. sulla struttura organizzativa interna delle industrie ICTS e sulla
morfologia dei mercati delle Tecnologie ICT (vedi anche Fig.1.0.1.1) e, in
definitiva, con conseguenze importanti sulla gestione non solo delle Tecnologie ICT
ma anche dei servizi TLC
Ora vogliamo studiare la “gerarchia di contenimento” visualizzata da un
System Analyst & Architect o da un Network Operator di un sistema TLC. Una
“gerarchia di contenimento” delle tecnologie ICT è evidente a tutti i livelli: sia in un
sistema TLC reale sia nei suoi componenti (“sottosistemi” del sistema TLC). Si faccia
riferimento alle Figure 2.2.1A e 2.2.1B. Rappresentano un satellite geostazionario per
telecomunicazioni (Telecommunication spacecraft) cioè un componente ICT di un
sistema satellitare di telecomunicazione.
In esso si possono osservare strutture realizzate a mò di scatole cinesi (o, se si
vuole, bambole russe!). Ad esempio in un sistema di comunicazioni satellitari
costituito da un segmento spaziale geostazionario e da un segmento terrestre si
osservano satelliti e stazioni di terra (terminale d’utente, hub o gateway) riconosciuti
come “sottosistemi” del sistema satellitare. All’interno di un sottosistema si notano
una serie di componenti (“sotto-sottosistemi”) che a loro volta contengono altri
componenti. Spesso i termini “sotto-sistema” o “sotto-sotto-sistema”, laddove non si
generi ambiguità, sono rimpiazzati dal termine “sistema” per cui si usa dire: “un
grande sistema tecnologico contiene altri sistemi che a loro volta contengono sistemi
più piccoli fino ad arrivare a sistemi che l’osservatore decide di non suddividere
ulteriormente (sistemi elementari o primitivi)”.
Lo stesso concetto si esprime anche dicendo che i componenti del sistema
fanno parte di una architettura “annidata” (nested structure) cioè sono contenuti gli
uni negli altri o fanno parte di una architettura con una “gerarchia di contenimento”
i.e. una architettura con livelli tecnologici ordinati in ordine gerarchico secondo il
criterio per cui un elemento di un livello inferiore “è parte di” (“is part of”) un
elemento del livello superiore. Per questo una gerarchia di contenimento è detta
anche gerarchia “is part of”.
2.2.2
Strutture gerarchiche delle Tecnologie ICT in un “geostationary
telecommunication spacecraft”
La Fig. 2.2.1A mostra la struttura tecnologica di un satellite geostazionario
visto come sottosistema di un sistema di comunicazioni satellitari. Si tratta di una
242
rappresentazione grafica a “scatole annidate” (nested boxes) alternativa ed
equivalente alla rappresentazione ad albero mostrata in Fig.2.2.1B. In essa si notano
Tecnologie ICT e Tecnologie nonICT integrate, contenute in un contenitore più
grande (Spacecraft).
Il Punto di Vista Engineering/Network Operator mette a fuoco solo le
Tecnologie ICT mentre le tecnologie nonICT sono sfocate (per mancanza di
interesse/conoscenze). I componenti di livello superiore sono creati assemblando/
integrando componenti del livello inferiore. Ad esempio un “Communication
Payload” a livello gerarchico 3 è costruito assemblando Transponditori e Antenne a
livello 2, i quali sono a loro volta costituiti rispettivamente da Ricevitori,
Trasmettitori, Processori di bordo e da Feed Array e Riflettori a livello 1.
2.2.3 Conseguenze in Ambiente Business: morfologia dei mercati e logiche di
produzione (parte facoltativa)
Come già detto, l’esistenza di una gerarchia di contenimento nella architettura
dei componenti di un sistema TLC implica anche una propedeuticità nelle fasi di
approvvigionamento/assemblaggio/integrazione dei vari componenti all’ interno di
una impresa ICTS. Ad esempio per costruire un ricevitore devo prima avere degli
amplificatori, per costruire gli amplificatori devo prima avere dei Circuiti Integrati a
Microonde (MIC) e per avere i circuiti MIC devo prima avere i Field Effect
Transistors, FET. Questa propedeuticità a sua volta ha un impatto determinante su
1) morfologia dei mercati delle Tecnologie ICT, tecnologie viste come
merce di compra-vendita. In un Ambiente Business esistono ICT Vendors che
operano in reti del valore (“value network”, vedi sotto e anche, C.M Christensen,
“The innovator’s dilemma”, Collins, 2006) in cui un Vendor vende componenti ad un
altro Vendor che opera ad un livello di integrazione tecnologica superiore fino a
raggiungere un Vendor al massimo livello di integrazione che vende sistemi completi
a clienti finali (“Venditore/integratore di sistema”).
DEFINIZIONE 2.2.3.1 Una “rete del valore” è un sistema di partnership o alleanze che
una impresa stabilisce per fornire, ampliare e distribuire la propria offerta (P. Kotler,
“Marketing Management”, Edizione Italiana, 11-ma Edizione, Pearson-Prentice Hall, 2003, pag.
612)
243
Network
1
contains
n
Managed Element
(managedElement R1)
1
contains
n
1
Equipment
(equpment Holder, circuitPack)
contains
n
1
contains
n
1
Software
(software R1)
contains
n
Mondo TLC
Fig. 2.2.2 Diagramma E-R (Entity-Relationship) delle classi di oggetti gestiti
(Managed Object Classes) definite nella Raccomandazione M.3100 dell’ITU-T.
Notare come la gerarchia di contenimento a livello tecnologico si rifletta nel
modello gestionale, prima, e nella struttura della MIB (Management Information
Base) i.e. rappresentazione GDMO degli oggetti gestiti (vedi testo)
2) struttura organizzativa e tipo di impresa ICTS. In un Ambiente
Engineering esistono tre tipi attività di progettazione/costruzione svolte in altrettanti
tipi di industrie ICTS e.g. livello 0, Original Device Manufacturer, livello 1,
Integratore di Equipaggiamento e livello 2, Integratore di Sistema.
3) gestione di una tecnologia ICT da parte di Network Operator (non si
può gestire un livello tecnologico superiore senza aver prima gestito i componenti al
livello inferiore)
Molto spesso la struttura interna di un qualsiasi sistema TLC è suddivisa in
livelli tecnologici ordinati secondo una gerarchia di contenimento a tre livelli,
0. dispositivi (devices), costruiti partendo da materie prime
1. equipaggiamento (equipment), costruito integrando dispositivi
2. sottosistema/sistema (subsystem/system) costruito assemblando/
integrando equipaggiamento di livello 2
244
(Vedi anche “Organizzazione dei calcolatori” in G.M.Schneider e J.L.Gersting,
“Corso di Informatica”, pag.176, Jackson Libri, 2001).
2.2.4 Modelli gestionali e gerarchia di contenimento (Fig.2.2.2)
La struttura gerarchica delle Tecnologie ICT all’interno di un sistema TLC si
riflette nella struttura dei modelli gestionali standardizzati introdotti dall’ITU-T.
Abbiamo visto che tramite processi di generalizzazione si possono creare modelli
gestionali generici partendo da modelli gestionali specifici delle varie tecnologie
(vedi par.1.2.7). I modelli generici ritengono una caratteristica condivisa dai modelli
specifici: la struttura gerarchica di contenimento. La Fig.2.2.2 mostra un diagramma
E-R (Entity-Reltionship Diagram) nella Raccomandazione M.3100, “Generic
Network Information Model”, 07/1995 dell’ITU-T.
Communications Payload
Transponders (1,2,3,4)
RCVR
TX
OBP
Antennas
Feed
Array
Classe
Com.Payld
Managed
Object
NEId
AlfaNum
Transp.1
equipHolder
EquipmentId
TRS1
Transp.2
equipHolder
EquipmentId
TRS2
Transp.3
equipHolder
EquipmentId
TRS3
Transp.4
equipHolder
EquipmentId
TRS4
Receiver
equipHolder
EquipmentId RCVR+int
LNoiseAmp circuitPack
Reflectors
Naming
Attribute
Data
Type/
Value
Elemento
Fisico
EquipmentId
LNA
Loc.Osc
circuitPack
EquipmentId
LO
Mixer
circuitPack
EquipmentId
MX
PostAmp
circuitPack
EquipmentId
PA
EquipmentId
TX+int
Transmitter equipHolder
equipHolder
EquipmentId
OBP
Demod
circuitPack
EquipmentId
DMD
BBSW
circuitPack
EquipmentId
SW
Mod
circuitPack
EquipmentId
MD
OBP
Mondo TLC
Fig.2.2.3 Gestione di un “Communication Payload” a bordo di un satellite geostazionario,
Tecniche di denominazione degli oggetti gestiti utilizzando la gerarchia di contenimento. La parte
tratteggiata non è gestita. (Parte trattata durante le esercitazioni)
245
NETWORK ELEMENT (SWITCH)
Shelf
Software
Card
ICT
Component
Switch
Managed
Object
Class
managedElement
Shelf
equipmentHolder
Card
circuitPack
Software
softwareR1
Mondo TLC
Fig.2.2.4 Gestione di un commutatore (Switch). Struttura gerarchica con quattro livelli
tecnologici
2.2.5 Tecniche di denominazione degli oggetti gestiti basate sulla gerarchia di
contenimento (Fig.2.2.3 e Fig.2.2.4)
Una delle applicazioni più interessanti della gerarchia di contenimento delle
Tecnologie ICT in un sistema TLC è la creazione del “nome” di un oggetto gestito
immagazzinato in una base dati MIB (Management Information Base). La creazione
del nome è infatti il primo passo per poter individuare un oggetto all’interno della
MIB e poterlo poi gestire (e.g. leggere e scrivere i valori dei suoi parametri
gestionali). La gerarchia di contenimento è usata per definire un nome globalmente
univoco (Distinguished Name) concatenando i nomi dei vari oggetti contenitori
dell’oggetto target: è una generalizzazione del concetto che si applica usualmente per
formulare un nome globalmente univoco per tutti noi: il nostro nome (Pietro
DeSantis) è la concatenazione di nome (Pietro) e cognome (DeSantis), dove il
cognome è il nome della nostra famiglia cioè il nostro “contenitore”. Ad esempio
l’albero gerarchico della Raccomandazione M.3100 nella Fig.2.2.2 può utilizzarsi per
costruire un Distinguished Name per un pacco software all’interno dello switch
(commutatore) mostrato in Fig.2.2.4. I suoi contenitori sono “card”, “shelf”, “switch”
e le corrispondenti “classi di oggetti gestiti” sono “circuitPack”, “equipmentHolder” e
“managedElement”. Tutto questo verrà studiato in dettaglio nella Parte 2 del corso.
La Fig.2.2.3 mostra l’applicazione di queste tecniche di denominazione al
Communication Payload di Fig.2.2.1A (spiegato a lezione)
246
INSERTO 2.3.1
La varietà delle tecnologie ICT è enorme. Per avere una visione d’insieme del loro complesso
è necessario classificarle in qualche maniera. Nel tempo, le tecnologie ICT sono state
opportunamente classificate in varie maniere applicando diversi criteri di classificazione.
Una operazione di classificazione delle tecnologie ICT può farsi applicando gli stessi metodi
adottati per classificare un qualsiasi “insieme di elementi” nel quale i singoli elementi
vengono dapprima analizzati e poi raggruppati in “gruppi” ognuno dei quali raccoglie
elementi con caratteristiche comuni (“classe”). Applicando la stessa metodologia in maniera
iterativa su scala locale, ogni classe può a sua volta essere suddivisa in sotto-classi e ogni
sotto-classe in sotto-sotto-classi secondo un processo regolato da opportuni criteri (e.g.
criterio della “specializzazione” crescente secondo il quale tecnologie appartenenti alla serie
iterativa delle sottoclassi hanno applicazioni sempre più specializzate). Applicando questa
metodologia di classificazione alle tecnologie ICT si può così costruire una classificazione
gerarchica delle tecnologie ICT in cui certe tecnologie appartenenti a classi superiori sono
tecnologie generiche (i.e. ognuna ha un ventaglio di possibilità applicative) mentre altre
tecnologie appartenenti alle sotto-classi inferiori vengono utilizzate per applicazioni sempre
più specifiche. Una rappresentazione multi-livello di questo tipo con livelli ordinati secondo
questo tipo di criterio gerarchico qui si chiama una “tassonomia”.
NOTA BENE: Nella teoria generale dei sistemi, dire che in un sistema esiste una gerarchia
di elementi significa dire che gli elementi del sistema sono ordinati secondo un criterio per
cui alcuni elementi “precedono” e altri che “seguono” oppure alcuni elementi sono posizionati
ad un livello “inferiore” ed altri ad un livello “superiore”.
2.3 Tipologia delle Tecnologie ICT: gerarchia di
ereditarietà (tassonomia)
Volgiamo ora la nostra attenzione a un sistema TLC reale e osserviamolo da
un Punto di Vista Engineering/Network Operator. Supponiamo che il Network
Operator, proprietario di reti TLC, voglia acquisire Tecnologie ICT e all’uopo voglia
avere un quadro completo delle Tecnologie ICT disponibili sul mercato che egli poi
dovrà gestire. In questo scenario è importante che egli abbia a disposizione una
classifica delle tecnologie ICT cioè una tassonomia delle Tecnologie ICT (Vedi
Inserto 2.3.1 per considerazioni sulla classifica/tassonomia delle Tecnologie ICT)
Abbiamo già visto in precedenza che un sistema TLC reale in effetti contiene
componenti ICT e componenti ausiliari nonICT e che le componenti ICT “osservate”
da un Punto di Vista Engineering/Network Operator evidenziano le loro caratteristiche
di “Tecnologie ICT”. In questo corso è importante distinguere fra Tecnologie ICT
gestionali e Tecnologie ICT gestite o U&S. Questa distinzione si può fare in base alla
natura dei flussi di informazione da esse elaborati/utilizzati. Allora in un sistema
TLC noi distigueremo : informazione di utilizzazione (U), informazione di
segnalazione (S) e informazione di gestione. Corrispondentemente le Tecnologie ICT
sono classificate in tecnologie non-gestionali (tecnologie U & S) e tecnologie
gestionali. Quindi in una tassonomia delle Tecnologie ICT compare la differenziazione
247
“Tecnologie U&S” e Tecnologie gestionali”. Esaminiamo ora la natura dei flussi di
informazione in un sistema TLC tramite alcuni esempi.
2.3.1
I tre tipi di informazione che fluiscono in un sistema TLC: informazione
di utilizzazione, segnalazione e gestione
Supponiamo di trovarci ospiti in un albergo. Dalla nostra stanza siamo
collegati con il mondo esterno tramite servizi di telecomunicazione messi a sua
disposizione dall’albergo. Riconosciamo che effettivamente tutti questi servizi sono
basati sul trasferimento di informazione con mezzi elettromagnetici (vedi Premessa
al Cap.1)
Il trasferimento di informazione effettuato dai mezzi elettromagnetici si
accompagna all’utilizzazione dell’informazione da parte nostra tramite vari tipi di
terminali: un telefono, per i servizi telefonici, una maccina fax, per i servizi fax, un
computer collegato con varie periferiche (microfoni, altoparlanti, webcams,
stampanti), per i servizi audio e video internet, un televisore collegato a un decoder,
per i servizi TV (e.g. satellitari) e una radio per i servizi radiofonici. Grazie al fatto
che questi terminali siano collegati a reti di telecomunicazione operative 24 ore su 24
e 7 giorni su 7, noi abbiamo la «capacità conoscitiva/ abilità fisica di telecomunicare»
con l’esterno ogniqualvolta lo desideriamo. E’ proprio questa «capacità
conoscitiva/abilitàfisica di svolgere le funzioni necessarie a soddisfare le sue
esigenze di telecomunicazione» che rende un ospite dell’albergo un utilizzatore
finale di un servizio TLC «al dettaglio». L’aggettivo «finale» sta a indicare che
l’utilizzatore usa il servizio per proprio uso e consumo e non lo trasferisce ad altri
utilizzatori fungendo da intermediario.
2.3.1.1 Informazione di utilizzazione
In ogni momento della giornata e ogniqualvolta se ne presenti il bisogno, un
ospite dell’albergo può utilizzare i servizi di telecomunicazione a sua disposizione. In
ogni caso egli può effettivamente «telecomunicare» con il soggetto esterno desiderato
o ricevere informazione dalla sorgente esterna desiderata. L’informazione scambiata
nel corso di una conversazione telefonica tramite un telefono o contenuta in un
messaggio e-mail inviato tramite un computer o ricevuta in un programma radiotelevisivo sullo schermo di un televisore viene da noi qualificata come «informazione
di utilizzazione» (“usage information”). Quindi gli ospiti dell’albergo allorchè
utilizzano i servizi di telecomunicazione sono sorgenti e/o collettori di informazione
di utilizzazione che fluisce e viene elaborata in una rete di telecomunicazione
chiamata «rete di utilizzazione» e in un “terminale di utilizzatore” ad essa
connesso. L’ informazione di utilizzazione rappresenta l’ informazione primaria
scambiata fra utilizzatori di un particolare servizio di telecomunicazione interattiva
(e.g. l’informazione contenuta in una telefonata scambiata fra Utenti di un servizio
telefonico) o distribuita da una trasmittente radio-TV a una comunità di Utenti. Lo
scambio o distribuzione dell’informazione di utilizzazione rappresenta proprio la
essenza o ragion d’essere del servizio TLC.
248
Altre nazioni
Nazione
GW
GW
SGT
SGT
Area di numerazione
SGT
SGT
SGU
SGU
Area di
commutazione
SL
SGU
SL
SL
Area di
centrale
UCR
SL
Fig.2.3.1.1 Vista “engineering” della rete di telefonia nazionale italiana gestita dalla Telecom
Italia (Piano Regolatore Nazionale delle Telecomunicazioni, 1990). UCR = Unità di
Concentrazione Remota, SL = Stadio di Linea, SGU = Stadio di Gruppo Urbano, SGT = Stadio
di Gruppo di Transito, GW = Gateway internazionale. Le centrali digitali PCM/TDM e
l’intruzione della rete di segnalazione CCSS7 permettono un routing dinamico del traffico in rete
(Adattato da A.Biocca, “Reti digitali” U.Hoepli, Milano, 2002,pag.191)
249
BSS
BSC
OMSS
Interfaccia Q3
HLR
VLR
MSC
ISDN
RTN
SMSS
Fig.2.3.1.2 Architettura della rete radiomobile digitale GSM ( Global System for Mobile
communications) introdotto in Italia nel 1994.
BSSS = Base Station Sub-System, SMSS = Switching and Management Sub-System,
OMSS = Operation and Management Sub-System, BSC = Base Station Controller, MSC =
Mobile service Switching Center, HLR = Home Location Register, VLR = Visitor Location
Register.
250
RETE B
Sottorete A3
Sottorete A1
Connessioni strati
OSI 1 e 2
RETE A
Sottorete A2
Fig.2.3.1.3 Schema di sistema internet
Satellite
Geostazionario
DBS (36,000 Km)
Terminali
Utente
Feeder link
Stazione
Trasmittente
TV
TU
Fig.2.3.1.4A Sistema di televisione satellitare
251
3G/UMTS
MOBILE BASED ONLY
Multicast/Broadcast with MBMS
Evolution with WiMax
DVB-H in S-band
DVB-H in UHF
TERRESTRIAL BROADCAST BASED
Overlay network in broadcast band
(DVB-H or T-DMB)
HYBRID SATELLITE/TERRESTRIAL
Reuse of terrestria cellular for
compensating insufficient indoor
satellite TV coverage
(experimental)
Fig. 2.3.1.4B Mobile TV. Televisione su 3 piattaforme per terminali mobili e.g. telefoni cellulari. MBMS
= Multimedia Broadcast Multicast Service. DVB-H = Digital Video Broadcasting–Handheld (modifica
della TV digitale terrestre DVB-T per terminali mobili handheld). T-DMB=Terrestrial-Digital Multimedia
Broadcasting
,
252
•
Le grandi reti di utilizzazione
Le Fig. 2.1.2, 3, 4A, 4B, 5 (spiegate a lezione) mostrano esempi di grandi reti
geografiche di utilizzazione. Rispettivamente, rete telefonica nazionale Italiana, rete
radiomobile, rete internet, rete di comunicazioni satellitari.
ESEMPIO. Sistema misto satellitare terrestre. Una TelCo “Wholesaler” di servizi di
telecomunicazione satellitari su base globale, e.g. l’INTELSAT (INternational
TELecommunication SATellite organization), possiede/gestisce una rete di satelliti
geostazionari e vende servizi di connettività all’ingrosso end-to-end su base globale a una
molteplicità di Fornitori di servizi regionali/nazionali, i quali a loro volta vendono servizi
TLC al dettaglio a Utenti finali dotati di piccole stazioni di terra (TU, Terminale di
Utilizzatore). Ad esempio l’INTELSAT (wholesaler) fornisce alla Telecom Italia
(retailer) la capacità di un transpoder da 36 MHz a bordo di un satellite geostazionario
con copertura italiana per servizi on-demand tipo VSAT (Very Small Aperture Terminal)
sul territorio nazionale. La Telecom Italia gestisce in proprio i servizi VSAT. L’
INTELSAT possiede il sistema TLC di Utilizzazione e Segnalazione mostrato in
Fig.2.3.1.5, dove,
Satelliti
geostazionari
Gestore/Proprietario
di Rete
Utenti
A
SOC
TU
NOC
H/SMS-SP
Altri Gestori/Proprietari di rete
GTWY
Reti Terrestri
Coda
NAP
Fig. 2.3.1.5 Sistema misto satellitare-terrestre. I ervizi di connettività all’ingrosso forniti da un Operatore di
rete satellitare. SOC = Stazione Controllo Satellite NOC=Stazione Gestione Servizi . SP=Fornitore di Servizio,
H/SMS-SP = Hub Stazione Gestione Servizi-Fornitore Servizi TU=Terminale Utente, GTWY=Terminale
Gateway, NAP = Network Access Point.
253
1. stazioni controllo satelliti (SOC, Satellite Operation Center),
2. stazioni gestione servizi TLC all’ingrosso (NOC, Network Operation Center)
offerti dall’Operatore di rete ad altri Fornitori di servizi: Ad esempio in questa
sede si effettua la fornitura/fatturazione della capacità all’ingrosso fornita ai
Fornitori di Servizio (SP) regionali.
3. satelliti geostazionari
Inoltre per permettere agli utenti del sistema satellitare di connettersi oltre che fra
di loro anche con gli utenti di reti terrestri (e.g. telefonica, internet) l’INTELSAT
stabilisce relazioni di business con altri Operatori di sistemi terrestri che posseggono
4. stazioni di accesso al segmento terrestre (GTWY)
5. connessioni d’accesso (“code” in fibra ottica) alle reti pubbliche terrestri
6. capacità su reti terrestri (e.g. blocco di canali d’utente)
Infine la Telecom Italia (SP, Service provider) possiede
7. hub e stazione gestione servizi (H/SMS-SP) che usa come hub per i servizi
VSAT sul territorio italiano e come centro di gestione servizi
L’interconnettività ottenuta tramite partnership fra vari Operatori di rete viene
venduta da INTELSAT sottoforma di servizi di connettività alla Telecom Italia che
tramite le Hub/Stazioni di Gestione Servizi (H/SMS-SP) soddisfa le richieste di capacità
(linee tratteggiate) provenienti dagli utenti. Le stazioni H/SMS-SP effettuano
l’assegnazione/fatturazione della capacità al dettaglio. In particolare nel caso di traffico
pacchettizzato tipo ATM la stazione regionale NMS-SP svolge sia la funzione di
signaling (Connection Admission Control, CAC) per l’instaurazione di circuiti tipo SVC,
Switched Virtual Circuit, su domanda (on-demand) del singolo utente sia la funzione
gestionale di rete di allocazione di capacità su prenotazione per servizi PVC (Permanent
Virtual Circuit).
2.3.1.2 Informazione di segnalazione (Fig.2.3.1.6)
Nel caso di servizi TLC interattivi, come telefonia o teleconferenza, l’ospite
dell’albergo deve richiedere, «su chiamata» (in inglese, on-demand), l’instaurazione
di una connessione circuitale con un destinatario desiderato. Ciò avviene prima di
poter scambiare informazione di utilizzazione. A tal fine l’ospite dell’albergo digita
sull’apparecchio terminale (e.g. telefono), un numero identificativo dell’indirizzo in
rete del destinatario (e.g. numero telefonico). In queste circostanze il telefono è
sorgente/collettore di un tipo di informazione denominata «informazione di
segnalazione» (signaling information) o talvolta, «informazione di controllo». Più
precisamente, l’ informazione di segnalazione, e.g. i segnali di via libera o di
occupato (dial tone) o di chiamata (ringing tone) nell’ apparecchio telefonico oppure
254
i segnali emessi allorchè viene digitato un numero sulla tastiera , hanno una struttura
temporale standardizzata e diversa da quella dell’ informazione di utilizzazione.
Rete di
Segnalazione
CCSS 7
Base Dati
Servizi
Supplementari
SP
STP
Centrale di Esercizio
e Manutenzione (CEM)
Commutazione
a pacchetto della
segnalazione
Rete di
Gestione
(TMN)
UC
UC
MC
MC
OS
SL
SP
UC
MC
Rete di
utilizzazione
(PSTN)
MC
UC
Fig. 2.3.1.6 Rete di segnalazione a canale comune (CCSS.7, Common Channel Signaling System
No.7) standardizzata dall’ ITU-T. UC = Unità di controllo, MC = Matrice di Commutazione (di
circuito a 64 Kbit/s), SP = Signaling Point, STP = Signaling Transfer Point (commutazione a
pacchetto), SL = Signaling Link.
Negli anni 70 sia l’informazione di utililizzazione che l’ informazione di
segnalazione fluivano negli stessi canali (“in-band signaling”). Nel 1980 l’ITU,
allora CCITT (Consultative Committe on International Telegraphy and Telephony),
standardizzò una rete di segnalazione fisicamente separata dalla PSTN che venne
chiamata rete CCSS7, Common Channel Signaling System No.7 o “rete di
segnalazione a canale comune”. Questo tipo di segnalazione, anche chiamato “outof-band signaling” per distinguerlo dal precedente “in-band signaling” è stato
gradualmente introdotto in tutte le principali reti PSTN negli anni 90. Un esempio di
rete di segnalazione CCSS7 è mostrata in Fig. 2.3.1.6
255
La presenza di una rete dati aggiuntiva, separata dalla PSTN e dotata di
ulteriori risorse di trasmissione/elaborazione/immagazzinamento d’informazione non
solo ha migliorato la qualità dei servizi telefonici di base (e.g. instaurazione ondemand più rapida) ma ha permesso di arricchire l’offerta di servizi con la creazione
di nuovi servizi telefonici a valore aggiunto e.g. “servizi supplementari” come
servizi di “identificazione del numero chiamante”, “trasferimento automatico di
chiamata”,”effettuazione di chiamata gratis (numero verde)”etc. Si tratta di servizi
basati sul recupero di informazione immagazzinata in basi dati collegate con le Unità
di Controllo (UC) degli autocommutatori PSTN. Si riconosce facilmente che allorchè
questo immagazzianmento/recupero dati si specializza a dati di localizzazione
dell’utente e avviene in forma dinamica si aprono le porte alla creazione di servizi
radiomobili.
Tipicamente l’informazione di segnalazione è strutturata secondo opportuni
protocolli a strati simili alla “pila OSI” e viene scambiata fra
1) apparecchiature terminali e rete di utilizzazione (segnalazione d’utente)
2) apparecchiature di rete PSTN (segnalazione inter-centrale) al fine di
permettere il corretto svolgimento delle funzioni necessarie al trasferimento/
elaborazione/utilizzazione dell’informazione di utilizzazione secondo modalità
specifiche del servizio prescelto
3) apparecchiature di rete PSTN e database di rete CCSS7 per la creazione di
nuovi servizi a valore aggiunto (segnalazione centrale-database).
Nei servizi TLC on-demand l’informazione di segnalazione d’utente, fluisce
allorchè si vuole stabilire in rete una connessione circuitale temporanea su richiesta
d’utente, al fine di realizzare un canale trasmissivo bidirezionale.
L’instaurazione/abbattimento del canale segnano l’inizio/fine del flusso di
informazione di utilizzazione trasmessa/ricevuta dall’utente. Quindi l’informazione
di segnalazione fluisce subito prima o subito dopo o durante lo scambio di
informazione di utilizzazione che si verifica in una “sessione” di telecomunicazione
cioè l’informazione di segnalazione si accompagna dinamicamente all’informazione
di utilizzazione. Questa caratteristica, assieme ai protocolli di comunicazione, la
diversifica dall’informazione di gestione. Infatti, a differenza dell’informazione di
segnalazione, l’informazione di gestione può fluire a tempi totalmente indipendenti
dai tempi in cui i flussi di informazione di utilizzazione vengono attivati nella rete
TLC. Ad esempio l’operazione gestionale di creazione da parte di un gestore di una
connessione circuitale permanente in una rete TLC (configurazione circuitale o
riconfigurazione di rete) dedicata ad uno specifico utente può essere effettuata molto
prima che il circuito stesso sia utilizzato dall’utente e l’informazione di utilizzazione
cominci a fluire in esso. E’ questo il caso di un Permanent Virtual Connection (PVC)
in una rete ATM (Vedi dopo)
Vediamo alcuni esempi di informazione e/o reti di segnalazione.
256
1. La Fig. 2.3.1.6 mostra una struttura stratificata costituita da tre reti
opportunamente interconnesse: una rete di utilizzazione PSTN e una rete di
segnalazione CCSS7, entrambe reti non-gestionali, assieme ad una rete di gestione
TMN di cui parleremo al prossimo capoverso. Nella figura è mostrato come gli
autocommutatori o centrali di commutazione di una rete telefonica PSTN (rettangoli
bianchi), in effetti siano costituite da una Matrice di Commutazione (MC) e da una
Unità di Controllo (UC), la prima appartenente alla rete di utilizzaziione PSTN e la
seconda alla rete di segnalazione CCSS7, una rete dati a commutazione di
pacchetto riservata ai messaggi di segnalazione. La Matrice di Commutazione
commuta circuiti telefonici digitali (PCM, Pulse Code Modulation con 8 bits ogni
125 microsec cioè a velocità media di 64 Kbit/s) sotto il controllo delle Unità di
Controllo. Le Unità di Controllo ricevono/trasmettono ed elaborano il traffico di
segnalazione scambiato con gli apparecchi terminali e con gli altri nodi e.g. attraverso
centrali di commutazione a pacchetto (STP, Signaling Transfer Point) della rete di
segnalazione CCSS7. Inoltre esse controllano le configurazioni della matrice di
commutazione. In Fig. 2.3.1.6 SP = Signaling Point è una unità funzionale capace di
ricevere e trasmettere messaggi di segnalazione.
Quindi sia nelle apparecchiature terminali (telefono) che nelle apparecchiature
di rete (centrali di commutazione) troviamo informazione di segnalazione e
informazione di utilizzazione.
Notare che nel caso dei servizi TLC distributivi privi di chiamata preventiva,
e.g. servizi radio-televisivi non-interattivi, o dei servizi TLC non-commutati
caratterizzati da connessioni permenenti fra utilizzatori, e.g. servizi a pacchetti
ATM/PVC (Asynchronous Transfer Mode/Permanent Virtual Circuit), non esiste
informazione di segnalazione poichè non si deve stabilire una connessione circuitale
preventiva prima dell’ invio o scambio di informazione di utilizzazione fra sorgenti e
collettori di informazione.
2. Il servizio di telefonia cellulare GSM (Global System for Mobile communication)
opera con un sistema di accesso FDMA/TDMA (Frequency/Time Domain Multiple
Access) nel quale la portante del FDMA utilizzata dal terminale (telefono cellulare +
carta SIM) varia da canale (con banda di 200 KHz) a canale con la periodicità di
trama del TDMA (“frequency hopping”). Ciò viene fatto per utilizzare sempre una
portante con il migliore rapporto segnale/rumore. Questo è possibile tramite un
continuo trasferimento di informazione di segnalazione fra terminale e BSC/MSC,
Base Station Controller / Mobile service Switching Center. Altra informazione di
segnalazione fluisce quando il terminale viene acceso e trasmette alla stazione base
della sua cella la propria identità in modo che il sistema possa autenticarlo.
3.
In una rete internet un router deve di volta in volta decidere su quale tratta
inviare un datagramma in arrivo per farlo pervenire alla sua destinazione finale nel
miglior modo possibile. Per far ciò ha bisogno di tavole di instradamento
continuamente aggiornate che gli permettano di conoscere in tempo reale lo stato di
257
traffico nei routers limitrofi. A tal fine i vari routers di una rete internet sono in
continua mutua comunicazione tramite flussi di informazione di segnalazione
scambiati con secondo protocolli standardizzati.
2.3.1.3 Informazione di gestione (gestione servizi TLC)
Gli ospiti di un albergo possono usufruire dei servizi TLC poichè l’albergo,
tramite
un
suo
ufficio
amministrativo/commerciale
(qui
chiamato
«amministrazione»), ha in precedenza stipulato contratti («Service Level
Agreements» o SLA) con i singoli fornitori di servizi TLC. Nei contratti sono state
specificate, con valore di impegno contrattuale, le condizioni di fornitura dei servizi
e.g. i valori pattuiti di prezzi e Qualità di Servizio (parametri di servizio). Notare
subito come a questo punto siano stati introdotti alcuni cocetti e.g. contratti, prezzi,
qualità di servizio etc. la cui natura non è ingegneristica ma tipica del marketing e del
business delle telecomunicazioni. Quindi notare come appena si parla di gestione dei
servizi TLC si parla anche di un ambiente business.
Oltre a stipulare contratti, la amministrazione dell’albergo interagisce coi
Fornitori, svolgendo varie attività di gestione dei servizi TLC e.g. ricevere/pagare le
fatture relative ai servizi fruiti, ottenere informazioni sui consumi relativi ai servizi
resi e/o su futuri servizi, notificare malfunzionamenti segnalati dagli Utilizzatori,
modificare i servizi esistenti e/o aggiungere altri servizi supplementari, controllare
che il livello di sicurezza delle comunicazioni sia quello pattuito etc. Notare che tutte
queste attività implicano uno scambio di informazione fra Cliente e Fornitori di
servizi utilizzando “canali” talvolta diversi dai canali di natura elettromagnetica usati
dagli ospiti dell’albergo nel corso della fruizione dei servizi TLC. Ad esempio l’invio
e il pagamento delle fatture telefoniche può farsi attraverso posta o attraverso banca.
Notare come, con l’avvento di internet, la partecipazione del Cliente alla gestione dei
servizi divenga sempre piu’ attiva e gli permetta di interagire sempre più intimamente
e profondamente con i processi gestionali interni al Fornitore di servizi. Si allude qui
a nuove tecniche di relazioni Clienti Personalizzate che vanno sotto il nome di
Customer Relation Management (CRM) basate sull’utilizzazione di servizi on-line,
di cui ci occuperemo verso la fine di questo corso.
Tutto questo si riassume dicendo che un utenza business, nella Persona TLC
del suo ufficio amministrativo (“amministrazione”), è un Cliente (customer) dei
Fornitori di servizi TLC e collabora con essi nella gestione dei servizi per far sì che
le condizioni definite nei contratti SLA, relative ai prezzi della fornitura e la qualita’
dei servizi resi, siano soddisfatte. L’ informazione scambiata nell’ambito della
attività di gestione dei servizi è denominata «informazione di gestione servizi».
Essa fluisce in due reti gestionali separate di cui una, interna alla TelCo, supporta
processi interni di gestione servizi e l’altra, esterna alla TelCo , supporta processi
esterni di gestione relazioni clienti che implicano il coinvolgimento del Cliente
(processi «Customer Care» o processi di «gestione relazioni clienti, CRM»). Questi
ultimi spesso usufruiscono di risorse pubbliche condivise e.g. rete pubblica telefonica,
internet, bancaria, postale etc.
258
C entro di
L avoro
Sistem i
di esercizio
T erm inali di
O peratore
OS
OS
OS
OS
R E T E C O M U N IC A ZIO N E D A T I
(D C N )
R ET E D I
G E ST IO NE
T erm inale
di G estione
E lem ento
di R ete
RETE U & S
Fig. 2.3.1.7 Dettaglio di una rete TMN per la gestione di elementi di rete
Una volta acquisiti i servizi dai vari Fornitori, l’amministrazione (i.e. il
Cliente) abilita/autorizza gli ospiti dell’utenza business (i.e. gli Utilizzatori), a
usufruire dei servizi. All’interno dell’utenza business in generale esiste anche un
“Gestore dei Sistemi Informativi” (e.g. dipartimento di Management of Information
Systems, MIS) che si occupa della gestione dei sistemi informatici locali (e.g. PBX,
LAN, terminali etc). Ad esempio, l’MIS si occupa della manutenzione dei terminali e,
al tempo stesso, fornisce all’amministrazione dati sulla durata e destinazione delle
telefonate internazionali effettuate dagli ospiti per addebitarne loro i costi.
Alla luce di quanto detto, riconosciamo che l’ ufficio amministratvo, gli ospiti
e gli impiegati del dipartimento MIS sono stakeholders che operano all’interno
dell’Utente finale e giocano i ruoli di Cliente finale, Gestore MIS e Utilizzatore
finale. I primi due ruoli sono relazionati al terzo ruolo tramite processi di
abilitazione, autorizzazione e assistenza.
259
Il Cliente assieme ai singoli Fornitori di servizi TLC, è responsabile della
gestione dei servizi e comunica coi diversi Fornitori attraverso apparecchiature
terminali di gestione e canali di gestione che possono differire dai terminali e dai
canali di utilizzazione usati dagli Utilizzatori. Tutto ciò è vero in generale per tutte le
cosidette «utenze business». Per le utenze residenziali private, chiamate anche
«utenze consumer», esiste un unica entità fisica, l’Utente, la quale gioca
simultaneamente il ruolo di Utilizzatore e Cliente.
2.3.1.4 Informazione di gestione (gestione delle tecnologie ICT in un sistema
TLC)
L’informazione di gestione esiste anche nel caso di gestione di una rete e dei
suoi elementi (vedi dopo). Ad esempio in Fig. 2.3.1.6 è mostrata le gestione degli
autocommutatori attraverso una rete facente capo a Centrali di Esercizio e
Manutenzione, CEM (nel linguaggio ITU indicati anche come OS, Operations
Systems o Sistemi di esercizio). Infatti secondo il modello gestionale ITU l’entità
gestita è una rete U&S e l’informazione di gestione fluisce in una rete dati
gestionali (DCN, Data Communication Network, vedi Fig.2.3.1.7) facente parte di
una Telecommunication Management Network (TMN) separata dalla rete U&S .
2.3.2
Classificazione delle tecnologie ICT in un sistema TLC
Un sistema TLC osservato da un Punto di Vista Engineering rivela l’esistenza
di Tecnologie ICT. Notare che eventuali componenti ausiliari nonICT (e.g.
infrastrutture meccaniche di supporto, centrali di produzine di energia elettrica,
strutture murarie) non sono “visualizzate” da un Punto di Vista Engineering
Se poi le Tecnologie ICT sono osservate da un Punto di Vista più specializzato e.g.
Punto di Vista Engineering/Network Operator se ne possono mettere in evidenza
anche le caratteristiche di interesse al Network Operator, proprietario, gestore e
operatore delle tecnologie stesse (caratteristiche relative ad acquisizione,
installazione, attivazione, controllo delle prestazioni, raccolta dati di consumo etc.)
Le Tecnologie ICT sono abilitatori tecnologici dei servizi TLC e sono
classificate in base alla natura (format e scopo) dei relativi flussi di informazione
Quindi, come già indicato, le Tecnologie ICT sono classificate come segue :
1) tecnologie di utilizzazione, che elaborano/trasferiscono/immagazzinano
l’informazione di utilizzazione scambiata durante la fase di erogazione/fruizione
dei servizi TLC (TLC service core). In una grossa rete di utilizzazione è sempre
possibile riconoscere le seguenti sezioni:
i) una sezione interna (rete di trasporto) dove sono situati gli elementi di
rete necessari al trasferimento a distanza dell’informazione i.e. apparecchi o
dispositivi di rete (nodi di transito) e mezzi di trasmissione elettromagnetici,
condivisi da tutte le Postazioni di Utente (PU) dove risiedono gli Utilizzatori della
rete, e
260
Sezione di Accesso
RETE
Sezione
Interna
NA/AL
TR
PU
AT
Interfaccia
Utente Rete
U
Fig. 2.3.2.1
ii) una sezione di accesso («ultimo miglio», last mile o rete di accesso) che
contiene gli elementi di rete necessari a connettere una o alcune PU alla sezione
interna, connessione effettuata nei nodi di accesso (NA) alla sezione interna. Lo
Stadio di Linea in Fig.2.3.1.1 è un nodo di accesso ed è anche denominato Centrale
Locale. Quindi un nodo di accesso, da un lato interfaccia con un nodo di transito
mentre da un altro lato interfaccia con una postazione di utente. Nel caso di PSTN
nel nodo di accesso risiede un «autocommutatore locale, AL» («local exchange» o
«central office switch» in USA).
Un Utilizzatore della rete (e.g. Persona fisica) accede ad essa tramite un
«apparecchio terminale» (AT) (Terminal Equipment) che interfaccia la rete in una
«terminazione di rete» (TR). La interfaccia di separazione AT-TR viene chiamata l’
Interfaccia Utente - Rete (User Network Interface, UNI) e si trova all’interno della
PU. Una connessione circuitale fra interfacce UNI remote si chiama «connessione
end-to-end». Nel caso di una rete dati (o rete di computers) AT e TR si chiamano
rispettivamente DTE (Digital Terminal Equipment) e DCE (Data Circuit-terminating
Equipment), che nel caso di linea telefonica è un modem. Una PU è connessa alla
sezione interna della rete tramite un «allacciamento d’utente» che nel caso più
semplice è una «linea d’utente».
2) tecnologie di segnalazione che processano/trasferiscono informazione di
segnalazione da una località all’altra e.g. reti di segnalazione come Common
Channel Signaling System No.7, CCSS No.7 e equipaggiamento SP (Signaling
Points) dove origina e termina l’informazione di segnalazione.
261
Le tecnologie di utilizzazione e di segnalazione possono conglobarsi in un
unico gruppo denominatoi tecnologie U&S che può essere specializzato in tecnologie
dedicate a specifiche attività come mostrato nell’albero gerarchico di Fig. 2.3.2.3
/2.3.2.4
3) tecnologie di gestione e.g. elaboratori digitali che processano
informazione di gestione e.g. Sistemi di Esercizio (OS), Sistemi di Supporto (NSS;
OSS, BSS), reti di trasporto dati gestionali e postazioni di lavoro residenti in centri di
gestione. L’ITU- T usa l’unico termine “OS” (Operation Systems) per indicare un
qualsiasi sistema gestionale e chiama «Rete di Gestione delle Telecomunicazioni» o,
in inglese Telecomunication Management Networks, TMN il complesso di OS,
postazioni di lavoro e reti dati gestionali.
La gestione degli elementi di rete è effettuasta con i sistemi di esercizio OS
(Operations Systems). C’è poi la gestione di rete con NSS (Network Support
Systems), la gestione servizi TLC con tecnologie OSS (Operation Support Systems) e
la gestione delle relazioni di business con Clienti, altre TelCo e fornitori di tecnologie
ICT (Suppliers) con tecnologie BSS (Business Support System). Notare come le
denominazioni NSS, OSS e BSS sia una terminologia non-ITU.
La suddivisione delle tecnologie gestionali in OS, NSS, OSS e BSS è mostrata
negli alberi gerarchici di Fig. 2.3.2.3/2.3.2.4. A differenza della “Gerarchia di
Contenimento” esposta in precedenza dove gli elementi di un livello gerarchico sono
legati agli elementi del livello superiore dalla relazione “is part of”, gli alberi
gerarchici nelle Fig. 2.3.2.3/2.3.2.4 sono “Gerarchie di Ereditarietà” nella quale gli
elementi di un livello gerarchico sono legati agli elementi del livello superiore dalla
relazione “is a” (“è una”). Ad esempio una tecnologia gestionale servizi “is a” (è
una) tecnologia gestionale che a sua volta “is a” (è una) tecnologia ICT. Quindi le
Tecnologie ICT componenti di un sistema TLC ( come del resto gli elementi di un
qualsiasi sistema complesso) posso essere classificate con classificazioni gerarchiche
tipo “Contenimento” o “Ereditarietà”. Questi concetti saranno frequentemente usati
nella seconda parte del corso quando si parlerà degli “oggetti gestiti”
•
OS e DCN
Ogni ICTS produttrice di Reti e Elementi di Rete da installare in un sistema TLC
costruisce e fornisce anche le tecnologie necessarie alla sua gestione, e.g. supervisione e
controllo a distanza del suo funzionamento (i.e. lettura dati di funzionamento e ricezione
dati di controllo). Queste tecnologie vanno sotto il nome di “sistemi di esercizio” (in
inglese OS, Operations Systems). Esse, da una parte sono collegati agli elementi di rete
gestiti tramite dispositivi terminali di gestione direttamente o via dispositivi di
mediazione, mentre dall’altra parte fanno capo ad un certo numero di postazioni di
lavoro (workstations) locali o remotizzate, dove risiedono gli addetti alla gestione. Le
postazioni di lavoro, gli OS, i dispositivi terminali e di mediazione sono interconnessi da
reti di comunicazione dati gestionali (Data Communication Network, DCN) Una
standardizzazione vendor independent basata su modelli gestionali generici permette la
262
utilizzazione di uno stesso tipo di OS per elementi di rete realizzati con tecnologie
implementative diverse. (Vedi G.Fantauzzi, “I sistemi software per le reti e i servizi
TLC” Franco Angeli, 2000, pag.21).
•
NSS
Poiché gli elementi di rete non sono isolati ma sono interconnessi e funzionano
all’interno di reti TLC, un sistema TLC contiene anche “sistemi di supporto alle
operatività di rete” (NSS, Network Support Systems) dedicati alla gestione della rete
TLC considerata nel suo complesso (“end-to-end performance” della rete). Si distinguono
“NSS dati” e “NSS di processo” a seconda che il loro compito sia l’archiviazione dei dati
o la loro elaborazione (vedi par.1.0.3.2). A differenza degli OS, realizzati con
minielaboratori attestati sui singoli elementi di rete, gli NSS di processo sono costituiti
da pacchi di software applicativo che girano su elaboratori di grosse dimensioni. Gli OS
possono essere tecnologie proprietarie a se stanti o esser integrati con gli NSS. Gli OS e
gli NSS costituiscono le risorse gestionali necessarie ad una TelCo per effettuare la
gestione della sua infrastruttura tecnologica abilitante i servizi TLC
•
OSS
Un sistema TLC contiene anche “sistemi di supporto alle operativita’ (OSS,
Operations Support Systems) dedicati alla gestione dei servizi TLC e.g. gestione
ordini, prestazioni, reclami,.fatturazione, etc. Anche gli OSS sono classificabili in OSS di
strato dati e OSS di processo. Gli OSS di processo sono pacchi di software applicativo
che girano su eleboratori di grosse dimensioni mentre gli OSS dati sono specializzati alla
archiviazione dati gestionali. Entrambi sono finalizzati all gestione dei “Servizi”. Questo
significa che gli OSS sono specializzati ai processi relativi alla gestione dei servizi TLC
su base “classe di servizio” e sono “interni” alla Telco senza coinvolgimento dei singoli
Clienti esterni. Abbiamo già visto come i vari OSS e NSS siano costituiti da applicazioni
gestionali che pur specializzate per tipi diversi di gestione in effetti sono integrate in
modalità “loosely coupled” su una piattaforma comune e le loro esecuzioni sono
schedulate da work flow controllers.
•
BSS
I processi di business relativi alla gestione delle Relazioni Clienti (Customer
Care) con coinvolgimento diretto dei singoli Clienti e delle relazioni con altre imprese
“partner” (con cui si collabora per fornire servizi TLC) o “suppliers” (da cui si comprano
tecnologie necessarie alla fornitura dei servizi TLC) sono accuditi da sistemi di supporto
chiamati “Sistemi di Supporto del Business” (BSS, Business Support Systems). In
questo corso noi assumiamo che tecnologie BSS siano dedicate a processi operativi In
sistemi gestionali recenti la tendenza è quella di sviluppare sempre più soluzioni
integrate del tipo BSS/OSS.
In definitiva, riconosciamo che la gestione complessiva di una TelCo è supportata
dai seguenti “sistemi di supporto”: OS, NSS, OSS, BSS integrati sia a livello processi
263
che a livello tecnologico in un unico sistema informatico (Gestione TLC, con la G
maiuscola, Vedi Capitolo 1) Una buona performance complessiva di impresa sostenibile
nel tempo in una economia di mercato è il risultato finale che il management dell’impresa
si propone di raggiungere attraverso la integrazione di processi gestionali relativi alle
gestioni di reti, servizi, relazioni clienti e relazioni con partners e suppliers. I vari tipi di
gestione vanno proprio visti nel contesto di una gestione complessiva di impresa
finalizzata al raggiungimento di una performance economica, sociale, ambientale
ottimale.
OSS
Dati
Canoni
Tariffe
Sconti
Servizi
Prodotti
OSS Processi
OSS Processi
(Service Ordering
& Negotiation)
(Performance Monitoring &
Problem Handling)
Realizzazione impianti utente
Gestione
Impresa
NSS Processi
Gestori
partner
•
•
•
•
Archivi
Clienti
Contratti
Assegnazione risorse alle utenze
Pianificazione e progettazione reti
Modifiche reti
Misura consumi
Sincronizzazione Basi Informative
OS
Fatture
Pagamenti
OSS Processi
(Billing)
Analisi impianti utente
Dati
Consumi
NSS Dati
Equipaggiamento
esistente e in
approntamento
Impianti Utenze
In Rete
Analisi
Rete
Attivazione / Disattivazione
OS
OS
OS
OS
Rete TLC (U&S)
gestieconomia
Fig.2.3.2.2 Relazione fra tecnologie gestionali (vedi G.Fantauzzi op.citata p.355)
264
Sistemi
Esercizio
•
Funzioni svolte e tecnoservizi offerti dalle tecnologie gestionali (Management
Functions & Services)
In un sistema TLC lo scopo del complesso delle tecnologie gestionali (Rete di
Gestione o Rete TMN, Telecommunications Management Network) è supportare la
gestione sia delle tecnologie U&S contenute nel sistema (OS, NSS) sia dei servizi TLC
abilitati dal sistema stesso (OSS/BSS). Questa situazione è rappresentata
schematicamente in Fig. 3.1.1 (vedi anche Fig.1.2.1.1). I primi processi di
standardizzazione (ITU-T Recom. M.3200 e M.3400) caratterizzavano una Rete di
Gestione come una rete che svolgeva funzioni gestionali (Management Functions) e
offriva tecnoservizi gestionali (Management Services) al gestore e.g. il Network
Operator di una TelCo, proprietario della rete.
NOTA 3.1.2.1 Tuttavia come indicato in 1.3.2.1 la caratterizzazione (bottom-up) in termini di
“Management Functions & Services” incentrata sulle Reti di Gestione è stata poi sostituita da una
caratterizzazione (top-down) in termini di “Business Objectives & Processes” incentrata sul business
della TelCo.
Elemento di Sistema TLC
TECNOLOGIA ICT
TECNOLOGIA di
UTILIZZAZIONE
MANUFATTO non-ICT
TECNOLOGIA di
SEGNALAZIONE
TECNOLOGIA di
GESTIONE
TECNOLOGIA U & S
TECNOLOGIA per la
GESTIONE di
RETI & ELEMENTI
di RETE (OS, NSS)
TECNOLOGIA per la
TECNOLOGIA per la
GESTIONE dei
GESTIONE delle
SERVIZI TLC (OSS)
RELAZIONI di
BUSINESS (BSS)
Fig. 2.3,2.3
Classif ica1
265
TECNOLOGIE di
UTILIZZAZIONE
TECNOLOGIE di
SEGNALAZIONE
TECNOLOGIE U & S
ELEMENTO di RETE
RETE
RETE di
ACCESSO
APPARECCHIATURA
di RETE
APPARECCHIATURA
TERMINALE
Fig. 2.3.2.4
RETE di
TRASPORTO
LINEA di
GIUNZIONE
Classifica2
2.3.3 Tassonomia delle Tecnologie ICT prodotta dall’ANIE (Solo lettura. Non
fa parte del programma 2008-2009)
L’ Osservatorio ICT-ANIE (Associazione Nazionale Industrie Elettroniche) ha
recentemente prodotto una tassonomia delle tecnologie ICT. Più precisamente si tratta di
uno studio della morfologia (segmentazione) dei mercati dei prodotti e servizi TLC sia
dal lato dell’offerta che della domanda (E.Pontarollo, “Reti e servizi per il XXI secolo: il
ruolo dei fornitori di tecnologie”, ANIE, 2007). Una tassonomia del genere è anche utile
ad effettuare studi statistici (raccolta dati econometrici) sulla natura e investimenti di
Ricerca & Sviluppo nel settore delle TLC (e.g. attività svolta dall’organizzazione
internazionale OCSE).
Noi abbiamo rappresentato i dati ANIE nella struttura gerarchica ad albero
mostrata in Fig.2.3.2.1,2 con le istruzioni per la lettura fornite in Fig.2.3.2.3. Le tavole
lette da sinistra a destra indicano apparecchiature sempre più specializzate secondo
criteri di diversa natura. Prove di lettura verranno effettuate durante le esercitazioni. Ad
esempio un “Edge Router di Rete Fissa” (P.512) è un Apparato U&S (P.31) per il
Networking di Rete (P.42) in una Rete TLC Fissa (P.21) parte di una Infrastruttura di
Rete (P.11). Notare come la classifica dei sistemi OSS di supporto alle operatività (P.410P.412) sia fatta seguendo il modello FAB (Fullfilmement, Assurance, Billing) del
consorzio TMF (TeleManagement Forum)
266
Fig.2.3.3.1
1. Mercato di
appartenenza
TLC Product Classification
2. Tipo di Rete
3. Categoria di
Prodotto [1]
Model (Osservatorio ICT
4. Funzione di Apparato
( Usage & Signaling , Mngmnt )
P .41 Controllo chiamata
& Gateway
X = P .11
Infrastruttura TLC
(Rete TLC)
P .21
Rete TLC Fissa
P .31
Apparati
( Usage &
Signaling )
[2]
P .22
Rete TLC Mobile
P .42 Networking
di rete
P .43 Trasmissione
Rete Fissa
P .51 HW Centrale
Commutaz . TDM
P .52 Softswitches
P .53 Media Gateway
IP - PSTN
P .54 Session
Controller IP - IP
P .510 ATM Switch
P .511 IP Core Router
P .512 Edge Router
P .513 Content
Delivery Server
P .44 Accesso
2. Tipo di Sistema /
Terminale TLC
P .12
Sistemi &
Terminali TLC
generici
(Consumer,
Aziende)
P .23
Sistemi di
Accesso
To TABLE 2
P .24
Terminali fissi
P .25
Terminali mobili
2. Tipo di prodotto ICT
per Aziende ( pA )
P .13
Prodotti ICT
per Aziende
(pA )
P .32
OSS
(Manage ment)
P .34
Servizi
P .530 DSLAM (ATM/IP)
P .531 Access Gateway
P .420 Intelligent Ntwk
P .421 Profile Database *
P .422 Voice application servers *
P .423 Media servers *
P .424 QoS servers *
P .425 Video servers
P .426 User Management
P .427 Application support srvr
P .428 Services delivery platform
P .429 Content mngmt ,
Digital right mngmt
P .4210 Middleware *
P .4211 User Agent * *
267
Rete Mobile
P .61 MSC 2G
P .62 MSC 3G
P .63 Gateway
P .610 IP Switch
P .520 Apparati
SDH/SONET
P .521 Next Gen. P .520 ,
Apparati DWDM
4. Piattaforma SW e/o HW
P .33
Applica tions
& VAS
P .25
Apparato ICT
pA
P .26
Sistema ICT pA
To TABLE 2
P .27
Servizio ICT pA
P .410 Billing &
Revenue Mngmt
P .411 Service
Assurance
& Network Mngmt
P .412 Service
Fullfilment
P .413 Access Ntwk
Mngmt System *
- ANIE)
5/6 Tipo di apparato
P .620 BSS 2G
P .621 BSS 3G
P .622 Ponti
Radio
4. Tipo di servizio
P .430 Cablaggio*
P .431 Supporto,
manutenzione, riparaz .
P .432 Managed
services /
Outsourcing (OS)
P .433 Business
Consulting (BC)
services
P .434 Formazione
P .435 Prepar . Siti * *
5. Tipo serv .
OS/BC
P .540
Network OS
P .541
Security OS
P .550
Business
Process OS
P .551
Consulting
P .552
Design serv .
Fig.2.3.3.2
1. Mercato di
appartenenza
From
TABLE !
P .12
Sistemi &
Terminali
TLC generici
Product
Classification
2. Tipo di
Sistema/Terminale
Residential
Gateway
Modem xDSL
Set Top Box (dati)
IAD Triple Play (video, dati, voce)
WLL/ WiFi access point
P .25
Terminale mobile
2. Tipo di Prodotto ICT
per Aziende (
pA )
P .330
P .331
P .332
P .333
Telefono GSM
Telefono GPRS
Telefono UMTS
Smart Phone / PDA
3. Tipo di Apparato
4. Apparato
P .340 Centralino
P .440 PBX
P .441 PBX ibrido / IP
P .341 Networking
P .342 Server
P .343 PC
P .450 LAN Switch
P .451 Storage Area Network
P .452 Security Equipment
3. Tipo di Sistema
P .27
Servizi ICT
Decoder satellitare
Parabola satellitare
PMP
CATV
4. Sistema
P .350 BSS
P .460 CRM
P .461 Business Intelligence
P .462 ERP
P .351 Web
P .470 Intranet
P .471 Internet / Extranet
pA
pA
268
4. Tipo di
servizio
OS / BC
3. Tipo di servizio
P .360 Implementa
zione
pA
P .13
Prodotti ICT
per Aziende
( pA )
P .26
Sistemi ICT
P .315
P .316
P .317
P .318
P .320 Telefono POTS
P .321 Telefono IP, Video Telefono
P .322 Telefono Bluetooth
/ WiFi / DECT
P .323 Apparati video (
video sorveglianza,
web cam )
P .323 PC
P .24
Terminale fisso
P .25
Apparati ICT
3. Sistema / Terminale
P .310
P .311
P .312
P .313
P .314
P .23
Sistema di
Accesso
Model (Osservatorio ICT ANIE)
P .361 Supporto &
Manutenzione
P .362 Managed
Services / Out sourcing
(OS)
P .363 Business
Consulting
(BC)
P .364 Formazione
-
P .480 Corp.
Ntwk OS
P .481 Corp.
Security OS
P .482
Desktop/
Data Cntr OS
P .483
Web Hosting
P .490
Business
Proc . OS
P .491
Consulting
P .492
Design Serv .
Fig. 2.3.3.3
LEGENDA
= Replace next neighbour
entity of lower specialization
= Add to next neighbour
entity of lower specialization
( * ) Solo rete fissa
(* *) Solo rete mobile
ACRONIMI
BSS = Base station Sub - System
CRM = Customer Relation Management
DSLAM = Digital Subcriber Line Access Multiplexer
DWDM = Dense Wavelength Division Multiplexing
GPRS = General Packet Radio Services
GSM = Global Standard for Mobile Communications
IAD = Integrated Access Device
MSC = Mobile service Switching Center
OSS = Operational Support System
UMTS = Universal Mobile Telecommunication System
VAS = Value Added Service
WLL = Wireless Local Loop
REFERENCES
(1)
(2)
Prodotto = Bene e/o servizio
Un “ Apparato ” è denominato “ Prodotto in senso stretto
” nel modello ANIE
ESEMPI di LETTURA delle TAVOLE (Uso delle parentesi graffe e def
P.21
Rete TLC Fissa
P.22
Rete TLC Mobile
P.31
Apparati
P.32
OSS
P.33
Applications & VAS
P.34
Servizi
inizione di “Traiettoria ”)
P.41
Controllo chiamata
& Gateway
P.42
Ntwkng di rete
P.43 Trasmissione
P.44 Accesso
269
I prodotti P .22.31.44
sono “Apparati di acesso
a reti mobili ” (specializzati nei prodotti P .620 – P.622)
2.4 Gli “stati” di una tecnologia ICT: funzionalità
primarie, funzioni primarie e condizioni di
funzionamento.
Da un punto di vista gestionale è importante supervisionare e controllare la
“condizione” in cui si trova un elemento di rete TLC ad un certo istante di tempo.
(area funzionale “Configuration Management” nel modello funzionale FCAPS
dell’ITU-T). Questo equivale a dire che è importante conoscere i valori istantanei di
certi parametri che caratterizzano la condizione di un certo elemento di rete. Se
l’elemento di rete reale da gestire è rappresentato da un “oggetto gestito”
immagazzinato in una base dati, venire a conoscenza della sua condizione istantanea
equivale a leggere i valori di certi “attributi” dell’oggetto stesso (“attributi di stato”)
(Vedi Parte 2 del corso). Uno stesso elemento di rete ha diversi attributi di stato:
alcuni sono specifici dell’elemento stesso mentre altri sono comuni a tutti gli elementi
che si possono anche trovare in reti tecnolgicamente diverse. La ITU-T nella
Raccomandazione CCIT X.731 “OSI-SM Part 1, State Management Function” (1992)
ha identificato gli “attributi di stato” comuni a tutti gli elementi di rete e li ha inseriti
nel suo modello gestionale generico “Generic Network Information Model”
pubblicato nella Raccomandazione M.3100. Più precisamente la ITU-T caratterizza
le condizioni di un elemento di rete con “attributi di stato” e “attributi di status” il
cui valore specifica più dettagliatamente le condizioni già specificate dall’attributo di
stato. In questo paragrafo studiamo gli “attributi di stato” di una Tecnologia ICT
come definiti dalla ITU-T e poi li interpretiamo in termini di “possesso di
funzionalità” e “svolgimento di funzione”
2.4.1 Gli “stati” di una tecnologia ICT
L’ITU-T suggerisce che lo “stato” in cui si trova una qualsiasi tecnologia ICT
gestita possa essere “osservato” da uno di tre possibili Punti di Vista:
1. Amministrazione (i.e. se esiste o meno l’ autorizzazione
all’uso della tecnologia da parte del gestore)
2. Operabilità (i.e. se la tecnologia è in condizioni di funzionare
o meno)
3. Utilizzazione (i.e. se la tecnologia è utilizzata parzialmente o
completamente oppure non è utilizzata affatto)
e, conseguentemente, esiste uno stato di operabilità, uno stato di utilizzazione e uno
stato amministrativo. Da un punto di vista gestionale lo “stato” di una tecnologia ICT
può essere identificato con un indice numerico come indicato nella Fig. 2.4.1. Ad
esempio uno stato di utilizzazione “4.3” indica che la tecnologia ICT è “occupata”
(busy)
270
Lo stato amministrativo ha tre valori :
1.1 bloccata (locked), (tecnologia con divieto amministrativo di fornire
sevizi agli utilizzatori)
1.2 sbloccata (unlocked) (tecnologia con permesso amministrativo di fornire
servizi agli utilizzatori)
1.3 “in chiusura” (shutting down). (il funzionamento della tecnologia è
permesso per l’utilizzatore in corso ma è vietato per futuri utilizzatori)
2.2 ENABLED
2.1 DISABLED
3.1 IDLE
3.2 ACTIVE
3.3 BUSY
1.1 LOCKED
1.2 UNLOCKED
1.3 SHUTTING DOWN
Stato
Fig.2.4.1 Rappresentazione “nested box” degli “stati” di una tecnologia ICT evidenziati dai
Punti di Vista amministrazione (rosa), operabilità (verde) e utilizzazione (arancio). Certe
condizioni di funzionamento influenzano il funzionamento della tecnologia e.g. possono
impedirlo o farlo avvenire a diversi livelli di prestazione (livello 1, celeste). Lo stato reale della
tecnologia si vede “drilling down” nella figura.
Lo stato di operabilità ha due valori
2.1
Disabilitato, Disabled (la tecnologia è completamente inattiva e incapace di
fornire servizi agli utilizzatori e.g. a causa di guasti.
2.2
Abilitato, Enabled (la tecnologia è completamente o parzialmente
operabile)
Lo stato di utilizzazione ha tre valori :
271
3.1 Inattivo o quiescente, Idle (la tecnologia al momento non è in uso)
3.2 Attivo, Active (la tecnologia al momento è in uso e dispone di ulteriore
capacità per poter accettare altri utilizzatori)
3.3 Occupato, Busy (la tecnologia al momento è in uso ma non dispone di
ulteriore capacità per poter accettare altri utilizzatori)
Ma attenzione anche alle condizioni esterne! Per una singola tecnologia ICT esistono
anche “condizioni esterne di funzionamento” o “condizioni esterne di utilizzazione”
che la possono influenzare in varie maniere nel momento in cui essa deve funzionare o
nel corso del suo funzionamento. A seconda di “come” queste condizioni sono
soddisfatte oppure “se” queste condizioni non sono soddisfatte, la tecnologia può essere
attiva e offrire vari livelli di prestazione (prestazione ottima, buona, media, pessima)
oppure non funzionare affatto. Ogni tecnologia ICT, dal punto di vista dell’utilizzatore è
una risorsa logica e fisica con certe limitazioni funzionali i.e. opera su certe larghezze di
banda, certi livelli di potenza, una certa capacità di processing e di memoria limitate.
L’influeza dell’ambiente circostante sulla tecnologia deve rispettare questi limiti i.e. le
condizioni esterne in cui una tecnologia opera devono essere compatibili con quelle
definite dai valori specificati nella “specifica di funzionamento” della tecnologia stessa.
Ad esempio una tecnologia con un certo numero di canali trasmissivi funziona
correttamente se in ognuno di essi i livelli di rumore (N) e di interferenza (I) sono
modesti rispetto ai livelli di segnale utile (S) cioè essa funziona correttamente se i valori
effettivi dei rapporti S/N e S/I nei singoli canali sono superiori o uguali a quelli di
specifica. Se in un sistema TLC wireless l’attenuazione di tratta aumenta a causa di
fenomeni atmosferici avversi e la potenza in uscita del trasmettitore non può essere
congruamente aumentata, il sistema può funzionare male cioè con bassa qualità o non
funzionare affatto. Nel caso di accesso multiplo (risorsa condivisa) il numero di
utilizzatori non può superare quello indicato nelle specifiche di funzionamento cioè le
condizioni di funzionamento sono soddisfatte per un numero limitato di utilizzatori. In
presenza di temperature ambientali superiori a quelle di specifica una tecnologia ICT può
non funzionare affatto.
Tutto questo avviene indipendentemente dalle condizioni di operabilità della
tecnologia stessa e dallo stato di autorizzazione deciso dal gestore. Una tecnologia ICT
può essere perfettamente “abilitata” e “sbloccata” (cioè operabile e autorizzata
amministrativamente ad operare) ma trovarsi nella condizione di non poter funzionare
perché certe condizioni esterne di utilizzazione non sono soddisfatte Durante lo stato
attivo una tecnologia ICT può presentare diversi livelli di prestazione a seconda delle
condizioni di utilizzazione prevalenti in quel momento.
272
2.4.2
Funzionalità primarie, funzioni primarie e condizioni di
funzionamento di una tecnologia ICT
Abbiamo visto che una Tecnologia ICT, durante il suo ciclo di vita, può trovarsi
in diversi “stati” e.g. messi a fuoco osservando la tecnologia dal punto di vista della sua
operabilità, utilizzazione, stato amministrativo. Tutti questi stati possono essere
intrerpretati in maniera unitaria (e quindi didatticamente efficace) applicando alle
tecnologie ICT il paradigma “funzionalità-funzione” o meglio studiando il
comportamento di una tecnologia ICT in termini di “possesso di funzionalità” e
“svolgimento di funzione”. (rispettivamente indicate con pF e sf nella Tavola 2.4.1) e
riconoscendo che il secondo è la attuazione (messa in atto) del primo compatibilmente
con il soddisfacimento di certe “condizioni di utilizzazione” esterne prevalenti al
momento. Tutto questo è importante perché è propedeutico al concetto di
“tecnoservizio” erogato da una Tecnologia ICT ad un suo utilizzatore esterno (vedi
par.2.5). I servizi internet o di telefonia vocale che noi ingegneri studiamo nei nostri corsi
universitari di “Reti per Telecomunicazioni” sono “tecnoservizi” erogati da reti internet o
di telefonia e costituiscono l’ “essenza” dei servizi internet o di telefonia vocale
commercialmente disponibili i.e. offerti in un Ambiente Business (vedi Cap.4).
Nel par.1.0.1 abbiamo introdotto il paradigma funzionalità-funzione per i TLC
stakeholders. E’ utile applicare il paradigma “funzionalità-funzione” anche alle
Tecnologie ICT. Una Tecnologia ICT è un prodotto manufatto/ commercializzato da un
impresa ICTS per essere utilizzato da imprese TelCo e Utenti per erogare e fruire di
servizi TLC. Una Tecnologia ICT è un prodotto che possiede la capacità logica/abilità
tecnologica i.e. possiede le risorse logiche (software) e fisiche (hardware, energia), per
svolgere una o più funzioni primarie (la “raison d’etre” per cui è stato costruito) cioè
possiede un insieme di funzionalità primarie specifiche da vengono attuate al momento
opportuno e.g. su richiesta di un utilizzatore esterno, supposta che certe condizioni di
utilizzazione esterne siano soddisfatte. Lo svolgimento delle funzioni primarie da parte
di una Tecnologia ICT avviene con diversi livelli di qualità denominati “Livelli di
Prestazione”(vedi par.2.6).
Anche per una Tecnologia ICT il paradigma “funzionalità-funzione”, permette di
studiarne in maniera unitaria il “ciclo di vita” cioè il percorso dal momento del suo
lancio commerciale alla sua dismissione, attraversando i vari “stati” di attività o
quiescenza. Infatti il paradigma “funzionalità-funzione” detta che lo svolgimento di
funzioni primarie durante lo stato attivo di una Tecnologia ICT è la attuazione (messa in
atto) di funzionalità primarie possedute dalla tecnologia stessa nello stato quiescente quo
ante ed avviene su richiesta di un utilizzatore esterno. Ad esempio basta applicare ad una
Tecnologia ICT dotata di funzionalità primarie, i.e. in uno stato “operabile” (vedi Fig.
2.4.1), un segnale di ingresso e/o un comando “power on” e/o “switch on” perché la
tecnologia svolga le funzioni primarie richieste (e.g. del tipo trasmissione, elaborazione,
immagazzinamento di informazione) cioè essa passi da uno stato quiescente (idle) ad uno
stato attivo “active” (vedi Fig. 2.4.1) come richiesto. In queste condizioni noi diciamo
anche che una tecnologia ICT complessa e.g. una rete TLC, eroga un “tecnoservizio” al
273
suo utilizzatore esterno che ne fa richiesta (e.g. una rete TLC eroga un “tecnoservizio di
rete”, vedi par.2.5).
Allora, noi diciamo che in una Tecnologia ICT
1) funzionalità primaria, posseduta da una tecnologia ICT è la capacità
logica (software) /abilità tecnologica (hardware) di svolgere una funzione primaria
(“raison d’etre” di una Tecnologia ICT).
2) funzione primaria, è un insieme coerente di attività svolte da una
Tecnologia ICT per raggiungere il suo scopo primario pecificato nelle “specifiche di
funzionamento”, “osservabile” da un utilizzatore esterno. Essa, su richiesta di un
utilizzatore esterno, attua la corrispondente funzionalità primaria in suo possesso in
tanto in quanto certe “condizioni di funzionamento” sono soddisfatte al momento
della attuazione (e.g. condizioni ambientali avverse o poco compatitibili con le
specifiche di funzionamento della tecnologia e.g. intervallo di temperatura, frequenza
e intensità di vibrazioni meccaniche, intensità di radiazioni ionizzanti, attenuazione di
tratta in collegamenti wireless etc.). Lo svolgimento delle funzioni primarie da parte
di una tecnologia ICT avviene con un livello di prestazione (e.g. insieme di valori
misurati di parametri prestazionali normalizzati ai corrispondenti valori nominali di
specifica) che dipende anche dalle condizioni di funzionamento.
2.4.2.1
“Funzione primaria” di una tecnologia ICT
Una Tecnologia ICT svolge varie attività, alcune completamente interne e non
“osservabili” dall’esterno e altre, “osservabili” dall’esterno. Fra queste ultime,
identifichiamo una o più funzioni primarie svolte al fine di raggiungere direttamente
lo scopo principale (identificato nelle specifiche di funzionamento) per il quale la
tecnologia stessa é stata costruita, in ossequio ai desideri/bisogni degli utilizzatori.
“Funzione” significa “insieme coerente di attività tesa al raggiungimento di uno
scopo predeterminato osservabile dall’esterno” i.e. una funzione può essere attivata
dall’esterno e i suoi risultati sono disponibili all’esterno della tecnologia.
Alla luce di quanto detto definiamo la funzione primaria di una Tecnologia
ICT come segue:
“La funzione primaria di una tecnologia ICT è un insieme coerente di attività
tese al raggiungimento dello scopo principale per il quale la tecnologia e’ stata
realizzata ed è osservabile/utilizzabile dall’esterno”.
Una funzione primaria di una Tecnologia ICT è il risultato osservabile/
utilizzabile dall’esterno di un insieme di funzioni interne generalmente ignorate da
un utilizzatore esterno (componenti funzionali interne) eseguite seguendo certe
regole procedurali prestabilite (logica interna della funzione primaria) tramite
elementi fisici strutturati secondo una architettura fisica della tecnologia.
274
2.4.2.2 “Funzionalità primaria” di una tecnologia ICT
In corrispondenza del concetto di “svolgimento di funzione primaria ”, è
importante introdurre il concetto di “possesso di funzionalità primaria” da parte di
una tecnologia ICT, come “possesso della capacità logica/abilità tecnologica di
svolgere una funzione primaria” tipica della risorsa. Adottiamo quindi la seguente
definizione:
”La funzionalità primaria, posseduta da una tecnologia ICT, è la capacità logica
/ abilità tecnologica di svolgere una funzione primaria”
Una funzionalità primaria, come caratteristica intrinseca e permanente di
una tecnologia priva di guasti costituisce la “ragion d’essere” della tecnologia stessa
cioè rappresenta il vero scopo per il quale essa è stata costruita. Noi diciamo anche
che una funzionalità primaria è inscritta in una tecnologia ICT.
STATO della TECNOLOGIA
OPERABILITA’
pF
sf
NO
NO
SI
NO
(*)
SI
SI
3. Attivo (**)
SI
SI
UTILIZZAZIONE
1. Disabilitato
1. Inattivo
2. Abilitato
(*) pF = sf
,
2. Occupato
(**) pF > sf
Tavola 2.4.1
Lo svolgimento di una funzione primaria è la attuazione (messa in atto) di una
funzionalità primaria specifica posseduta a priori dalla tecnologia ed avviene su
richiesta di un utilizzatore esterno o motu proprio da parte della tecnologia (in tal
caso la attivazione della funzionalità primaria è già inscritta nella logica). Il processo
di attuazione avviene con una qualità che dipende fra l’altro dalle condizioni in cui si
trova la tecnologia al momento dell’attuazione. Si parla di “qualità erogata” inferiore
alla qualità pianificata e installata originariamente e di un Livello di Prestazione della
tecnologia in fase di utilizzazione (Level of Performance, LoP)
275
2.4.2.3
Gli “stati” di funzionamento di una tecnologia ICT interpretati in termini
di “possesso di funzionalità TLC” e “svolgimento di funzioni TLC”
La Tavola 2.4.1 mostra come il possesso di una funzionalità primaria (pF) da
parte di una tecnologia ICT coincida con uno stato di operabilità. Si tratta di una
caratteristica intrinseca e permanente di una tecnologia ICT non-guasta. Lo
svolgimento delle funzioni primarie puo’ verificarsi o meno a seconda dello “stato di
utilizzazione” on “stato di funzionamento” in cui si trova la tecnologia stessa.
Lo stato di utilizzazione invece coincide con lo svolgimento di funzioni
primarie (sf). Notare che la terminologia “stato di utilizzazione” si riferisce ad una
tecnologia generica cioè U & S o di gestione. Ovviamente una tecnologia si può
trovare in uno stato di utilizzazione solo se essa è “abilitata” e “sbloccata”.
276
2.5 “Tecnoservizi” forniti dalle Tecnologie ICT
Tutti noi ingegneri TLC nei nostri corsi universitari abbiamo imparato che le reti
TLC forniscono “servizi di telecomunicazione” ai loro utilizzatori. Per questo questi
servizi sono stati anche chiamati “servizi di rete” (network services). Ora vogliamo
riconoscere che questi servizi sono in effetti solo una parte dei “servizi TLC” oggi
commercialmente disponibili (telefonia, internet, radio, TV etc.), servizi che noi tutti
sottoscriviamo, che utilizziamo quotidianamente e per i quali paghiamo la bolletta a fine
mese. Proprio per distinguerli dai servizi TLC e per ricordarci che sono forniti da
tecnologie ICT direttamente ai loro utilizzatori noi diremo che i “servizi di rete” sono
“Tecnoservizi”. Questo termine lo abbiamo coniato ispirandoci all’equivalente termine
Inglese “Technical Services”. I servizi di rete costituiscono la parte di “Utilizzazione e
Segnalazione” (U&S) di un servizio TLC fornito/acquisito in un Ambiente Business da
Service Providers e Clienti e poi sono erogati e fruiti rispettivamente da Network
Operators e Utilizzatori. Noi diciamo anche che essi costituiscono l’ “essenza” di un
servizio TLC (“TLC service core”).
Una definizione di tecnoservizio
“A service is a meaningful set of
capabilities provided by an existing or
intended network to all who utilize it: end
users, network providers and service
providers” (A.O. Oshisanwo et al.,” IBM
Systems Journal, vol.31, no.4,
1992)
Tavola 2.5.1
Distinguere fra tecnoservizi forniti da una rete TLC a una TelCo che ne ha la
disponibilità e servizi TLC forniti da una TelCo ad una comunità di Utenti sottoscrittori è
molto importante specialmante per noi che ci occupiamo di “qualità” e “gestione” dei
servizi.
Infatti la qualità di un tecnoservizio è il Livello di Prestazione (Level of
Performance, LoP) della tecnologia ICT che lo fornisce (rigorosamente misurabile in
Ambiente Engineering, vedi par.2.5.7) mentre la qualità di un servizio TLC (Qualità di
Servizio, Quality of Service, QoS) dipende anche dalla percezione del soggetto
“Utente” che opera in un Ambiente Business.
Infine la “gestione” di un tecnoservizio semplicemente….non esiste! Infatti
diciamo che la gestione di un tecnoservizio è la gestione della Tecnologia ICT che lo
fornisce. Uno degli argomenti più interessanti che studieremo in questo corso è proprio la
mappatura “QoS-LoP” fra Qualità di Servizio definita in un Ambiente Business e Livello
di Prestazione definito in un Ambiente Engineering (vedi dopo)
277
2.5.1
Trasferimento di funzionalità primarie fra tecnologia ICT e utilizzatore
esterno.
In questa sezione vogliamo studiare i tecnoservizi avvantaggiandoci del fatto che
noi abbiamo già introdotto nel par.2.4 i concetti di funzionalità/funzioni rispettivamente
possedute/svolte da una tecnologia ICT.
Oggi le tecnologie ICT sono sistemi hardware & software dotati di una
complessità fisica e logica, intelligenza (i,e, capacità di trasmissione/processing/
memorizzazione dati) e autonomia (capacità di funzionamento senza interventi
dall’esterno, ad eccezione di eventuale fornitura di energia e.g. dalla rete di distribuzione
dell’ energia elettrica). Le grandi reti TLC intelligenti (Intelligent Networks, IN) sono
un esempio classico di tecnologie ICT complesse, intelligenti ed autonome. In questa
sezione usiamo il termine “Tecnologie ICT” per indicare proprio tecnologie ICT
complesse, intelligenti e autonome, capaci di eseguire compiti per conto di utilizzatori
esterni (persone fisiche o giuridiche) che ne fanno legittimamente richiesta.
Nel par.2.4 abbiamo mostrato come una tecnologia ICT svolga una o più funzioni
primarie per conto di un utilizzatore esterno al fine di risolvere problemi insorti nel
momento in cui egli ha deciso di soddisfare certe sue esigenze. Lo svolgimento delle
funzioni primarie rappresenta la “raison d’etre” della tecnologia stessa cioè la ragione per
la quale essa è stata costruita. Le funzioni primarie di una tecnologia ICT sono
osservabili e utilizzabili dall’esterno, grazie al supporto di certe componenti funzionali
interne. Qui assumiamo che un utilizzatore esterno sia una persona fisica o giuridica e
che la tecnologia ICT, dal momento del suo lancio commerciale disponga di capacità
logica (disponibilità di software e.g. applicazioni, middleware, sistemi operativi) e abilità
fisica (disponibilità di hardware e fonti di energia e.g. rete elettrica, batterie, celle solari
etc. ) cioè disponga di una o più funzionalità primarie tali da poter eseguire operazioni
intelligenti ed autonome come prestabilito e richiesto dai suoi costruttori e utilizzatori.
Questo è particolarmente vero per le reti TLC.
Il possesso di funzionalità primaria da parte di una Tecnologia ICT è
propedeutico allo svolgimento delle corrispondenti funzioni primarie, svolgimento
possibile solo se sono soddisfatte certe condizioni di funzionamento o di utilizzazione
esterne alla Tecnologia ICT stessa. Lo svolgimento delle funzioni primarie può avvenire
con diversi livelli di qualità (Livello di Prestazione) che dipendono sia da queste
“condizioni di utilizzazione” sia da come la tecnologia è stata manutenuta nel tempo. E’
probabile che una tecnologia che ha avuto una scarsa manutenzione funzioni con livelli di
prestazione piuttosto bassi. In generale esiste un divario (execution gap) fra il livello di
prestazione predetto e il livello di prestazione effettivamente erogato e misurabile a
posteriori (vedi par.2.6).
Nel momento in cui l’utilizzatore effettivamente comincia a disporre di una
Tecnologia ICT dotata di certe funzionalità primarie (e.g. nel momento in cui egli ne
diventa il proprietario o la prende in affitto o in leasing o in prestito o in accomodato
d’uso, vedi par.2.5.6) egli comincia a condividerne le funzionalità primarie cioè anche
278
egli diventa capace/abile a svolgere certe funzioni in caso di desiderio/bisogno, supposto
che opportune condizioni di utilizzazione siano soddisfatte. In queste circostanze noi
diciamo che l’utilizzatore acquisisce un “tecnoservizio” fornito dalla tecnologia. E’
proprio la capacità logica (software) / abilità fisica (hardware + fonti di energia) delle
tecnologie ICT di risolvere autonomamente i problemi dei loro utilizzatori che le rende
“fornitrici di servizi”. Ma vediamo meglio.
2.5.2
Tecnoservizi: servizi forniti/erogati da una tecnologia ICT
Ricordiamo la definizione di “servizio” da noi adottata in questo corso. In
maniera del tutto generale noi definiamo “fornitura di un servizio” da parte di un
fornitore (persona o tecnologia) il trasferimento di un insieme coerente di funzionalità
dal fornitore a un utilizzatore (persona o tecnologia), al fine di risolvere i problemi
insorti o che insorgeranno presso quest’ultimo allorché esso decide o deciderà di
soddisfare certe sue esigenze (desideri/bisogni nel caso di persona). In tal caso diciamo
che l’utilizzatore “acquisisce” il servizio fornito dal fornitore. Analogamente definiamo
“erogazione di un servizio” da parte di un fornitore (persona o tecnologia) e, allo stesso
tempo, “fruizione di un servizio” da parte di un utilizzatore lo svolgimento di un
insieme coerente di funzioni, attuazione di corrispondenti funzionalità acquisite a priori
nella fase di “fornitura/acquisizione” del servizio. Talvolta i termini “erogazione/
fruizione” sono sostituiti dai termini “produzione/ consumo”.
Nostra definizione di “Fornitura di Servizio”
La “fornitura di un servizio” da parte di un fornitore (persona o tecnologia)
è il trasferimento di un insieme coerente di funzionalità dal fornitore a un
utilizzatore (persona o tecnologia), al fine di risolvere i problemi insorti o che
insorgeranno presso quest’ultimo allorché esso decide o deciderà di
soddisfare certe sue esigenze (desideri/bisogni nel caso di persona)
FORNITORE
Fornitura di un servizio
Erogazione di un servizio
UTILIZZATORE
(Trasferimento di Funzionalità)
(Svolgimento di Funzione)
Acquisizione di un servizio
Fruizione di un servizio
Tavola 2.5.2
Alla luce di questa definizione possiamo anche dire quanto segue: “allorché un
utilizzatore acquisiace la disponibilità di una tecnologia ICT (e.g. via possesso, affitto,
leasing, prestito etc. ) in effetti egli “acquisisce un tecnoservizio fornito dalla
tecnologia”. Invece quando l’utilizzatore effettivamente utilizza la tecnologia di cui egli
dispone noi diciamo che egli “fruisce di un tecnoservizio erogato dalla tecnologia”.
279
Infatti, una volta acquisita la disponibilità della tecnologia ICT, è sufficiente che
al momento opportuno l’utilizzatore attivi la tecnologia a sua disposizione (supposto che
sia stata già “inizializzata” cioè pronta per l’uso) i.e. dia il via allo svolgimento delle
funzioni primarie direttamente o indirettamente e.g. chiudendo un interruttore “power on”
attestato sulla tecnologia ICT oppure semplicemente applicando alla tecnologia ICT un
segnale di ingresso. In questa situazione una tecnologia ICT complessa, intelligente ed
autonoma non è un semplice strumento per risolvere certi problemi insorti presso il
suo l’utilizzatore (e.g. come un trapano è uno strumento per risolvere il problema di fare
un buco nel legno) bensì la tecnologia stessa eroga all’utilizzatore un tecnoservizio, al
fine di risolvere i problemi insorti presso quest’ultimo (e.g. come un falegname facendo
un buco nel legno per nostro conto eroga un servizio finalizzato a risolvere i nostri
problemi). Allora notare la differenza (ben nota in campo “marketing”!). fra “strumento
per risolvere un problema” (trapano) e “risoluzione del problema” (effettuazione del
buco).
Ad esempio se consideriamo una TelCo proprietaria di una rete TLC e il problema è collegare attraverso la
rete un terminale A con un terminale B su richiesta di un Utente, la erogazione del tecnoservizio di
interconnessione da parte della rete (trasferimento di informazione da un terminale all’altro) è finalizzata
alla risoluzione del problema e l’Utente, su autorizzazione della TelCo, fruisce di questo tecnoservizio.
DUE POSSIBILI RAPPRESENTAZIONI
dell’ INTERAZIONE TECNOLOGIA ICT-UTILIZZATORE
ATTIVITA’
UTILIZZATORE
Un Utilizzatore
utilizza una
Tecnologia ICT
come risorsa
per svolgere
certe sue attività
(rappresentazione
uso-centrica o
top-down)
INTERAZIONE
Una Tecnologia ICT
eroga
un tecnoservizio
ad un Utilizzatore
per soddisfare certe
sue esigenze
(rappresentazione
tecno-centrica o
bottom-up)
TECNOLOGIA ICT
Persona-macchina
Fig. 2.5.1 Relazione Utilizzatore-Tecnologia ICT in fase operativa
Quindi fare attenzione alle due possibili fasi nella relazione tecnologia ICTutilizzatore:
1. “fornitura-acquisizione” di un tecnoservizio, allorché l’utilizzatore
acquisisce la funzionalità (capacità logica/abilità tecnologica) di una tecnologia ICT per
280
risolvere certi suoi problemi e.g. attraverso acquisto, presa in affitto o in leasing etc. o in
accomodato d’uso etc.
2. “erogazione-fruizione” di un tecnoservizio, allorché l’utilizzatore
effettivamente utilizza una tecnologia ICT. Avviene in un Ambiente Engineering
Servizio TLC
UTENTE
(Utilizzatore)
TELCO
(Utilizzatore)
Servizio TLC
UTENTE
(Utilizzatore)
utilizza
la risorsa
Tecnoservizio di rete
utilizza
la risorsa
per fruire del
tecnoservizio
di rete
Local
loop
LE
CPE
TE
per fruire del
tecnoservizio
di rete
Local
Loop
Trunk
TE
LE
NAP
CPE
NAP
RETE
SAP
Rappresentazione
usocentrica
SAP
Rappresentazione tecnocentica
(Le prestazioni della rete sono……)
Rappresentazione
usocentrica
Persona TLC
Fig. 2.5.2 Un Utilizzatore fruisce di un tecnoservizio di rete tramite apparecchiature di
intermediazione CPE (Customer Premise Equipment). LE = Local Exchange, TE = Trunk
Exchange. NAP = Network Access Point, SAP = Service Access Point.
2.5.3 Tecnoservizi: caratterizzazione tecnocentrica della relazione tecnologia ICTutilizzatore (Ambiente Engineering)
Allorché noi diciamo “una rete internet fornisce/eroga servizi internet ai suoi
utilizzatori” facciamo riferimento al fatto che “una tecnologia ICT fornisce/eroga
tecnoservizi ai suoi utilizzatori” ed effettuiamo una caratterizzazione tecnocentrica
della relazione tecnologia-utilizzatore cioè di questa relazione mettiamo a fuoco le
caratteristiche di funzionamento della tecnologia. In senso opposto cioè in una
caratterizzazione usocentrica incentrata sull’utilizzatore noi diciamo che “un
utilizzatore possiede/utilizza una tecnologia ICT come risorsa per poter svolgere certe
sue attività”. In questo caso mettiamo a fuoco le caratteristiche di comportamento
dell’utilizzatore ignorando i dettagli relativi al funzionamento della tecnologia abilitante.
(Vedi Fig. 2.5.1 ). Quindi, ad esempio:
i)
una rete TLC in fase operazionale i.e. allorché trasferisce segnali elettrici
da una sua porta di ingresso (Network Access Point A) ad una sua porta di
uscita (Network Access Point B) per conto di una TelCo sua proprietaria
281
in effetti eroga un tecnoservizio alla TelCo (caratterizzazione tecnocentrica della relazione tecnologia-utilizzatore, che mette a fuoco le
caratteristiche funzionali della rete, tipica di un ambiente Engineering) Un
utente/utilizzatore di un servizio TLC ha bisogno di equipaggiamento
CPE (Customer Premise Equpment) come risorsa per fruire del
tecnoservizio erogato dalla rete. (Fig.2.5.2)
ii)
una Telco utilizza una rete TLC come risorsa per erogare servizi TLC ai
suoi utenti. (caratterizzazione uso-centrica o top-down della relazione
tecnologia-utilizzatore, che mette a fuoco le attività della TelCo come
fornitrice di servizi TLC in un ambiente Business)
GESTORE
TECNOLOGIA U&S
UTILIZZATORE
TECNOLOGIA U&S
Tecnoservizio
di gestione
TECNOLOGIA
GESTIONALE
utilizza
Tecnoservizio
U&S
TECNOLOGIA U&S
gestisce
Interfaccia
gestionale
Tecnologia U&S gestita
Perona tlc
Fig. 2.5.3 Tecnoservizi U&S e tecnoservizi di gestione. Il Gestore di tecnologie U&S, e.g. gestore
di rete U&S, è un utilizzatore di tecnologie gestionali (NSS,OS). I parametri prestazionali di rete
(LoP della rete U&S) sono misurati nella rete gestita (Tecnologia U&S gestita). La nuvola indica
disinteresse per il comportamento delle persone in essa contenute.
2.5.4 Tecnoservizio U&S e Tecnoservizio di gestione
I tecnoservizi mettono a fuoco i dettagli del funzionamento di una tecnologia ICT
nella sua relazione con gli utilizzatori esterni (“persona” la cui “percezione” di qualità
tuttavia non influenza affatto la qualità del tecnoservizio cioè un tecnoservizio ha una
“qualità” espressa da un Livello di Prestazione perfettamente quantificabile e misurabile
sperimentalmente come avviene sempre in un Ambiente Engineering indipendente dal
comportamento del suo utilizzatore). In un tecnoservizio la tecnologia ICT è il fornitore
del servizio, e il tecnoservizio prende il nome del suo fornitore (e.g. ad esempio una rete
ATM fornisce un tecnoservizio ATM). Così come ci sono tecnologie U&S e tecnologie
di gestione così ci sono i relativi tecnoservizi U&S e tecnoservizi di gestione. La Fig.
282
2.5.3 mostra questi due tipi di tecnoservizi e i relativi utilizzatori. Notare come il Gestore
di una tecnologia U&S sia un Utilizzatore di tecnoservizi forniti dalle tecnologie
gestionali OS/NSS.
2.5.5 Importanza didattica dei tecnoservizi nel corso di GST (contesto
interdisciplinare)
Perchè è importante l’introduzione del concetto “tecnoservizio” nel nostro corso?
Lo abbiamo in parte già detto. Noi abbiamo volutamente introdotto il concetto di
“tecnoservizio” in un corso di insegnamento interdisciplinare per studenti di Ingegneria
TLC. Infatti attribuiamo ad esso grande importanza didattica, per due motivi:
1) per ricordarci che i tecnoservizi sono servizi forniti da una tecnologia ICT
complessa, intelligente ed autonoma ad un utilizzatore esterno in un contesto
Engineering proprio come si insegna nell’Ingegneria TLC (e.g. una tecnologia di rete
internet fornisce tecnoservizi internet a utilizzatori esterni) e quindi gli studenti di
Ingegneria TLC che frequentano questo corso ritrovano nel concetto di ”tecnoservizio”
ciò che hanno già studiato nei corsi precedenti di “Reti per telecomunicazioni” (ricordate
“reti e servizi TLC”?). E’ molto confortevole ritrovare vecchi concetti in un nuovo
contesto come quello da noi adottato in questo corso. Da un punto di vista mnemonico è
utile ricordare che grossomodo un tecnoservizio è un servizio fornito da una tecnologia
ICT di grande complessità, intelligenza e autonomia al suo proprietario (o affittuario) e.g.
una rete TLC fornisce un tecnoservizio di rete ad una TelCo sua proprietaria. Noi non
parliamo di qualità di un tecnoservizio bensì di prestazioni della tecnologia che lo
eroga (parametri prestazionali oggettivi rigorosamente misurabili). La prestazione della
tecnologia è un fatto puramente tecnologico senza alcun contributo dell’utilizzatore
esterno come persona fisica o giuridica che potrebbe iniettarvi elementi soggettivi di più
difficile misurabilità.
Anche per questo noi diciamo che i “servizi di rete” sono tecnoservizi che
vengono erogati/fruiti in un Ambiente Engineering e che, quindi i corrispondenti ruoli
di Network Operator e Utilizzatore sono ruoli svolti rispettivamente da TelCo e Utente in
un Ambiente Engineering o sono “ruoli Engineering”.
Ricordare che,
Non esiste la gestione di un tecnoservizio U&S;
esiste la gestione della tecnologia U&S che lo eroga
Non esiste la gestione di un tecnoservizio;
esiste un tecnoservizio di gestione (e.g. Management
Services forniti da una rete TMN, vedi Cap.3)
Non esiste la QoS di un tecnoservizio;
esiste l’ LoP della tecnologia che lo eroga.
2) per distinguere nettamente i tecnoservizi dai servizi TLC commercialmente disponibili
forniti da un SP a un Cliente TLC in un contesto Business (i.e. quei servizi che tutti noi
283
riconosciamo quando andiamo a pagare la bolletta del telefono a fine mese!). In
particolare vedremo come in realtà i tecnoservizi forniti da una rete TLC ad una TelCo
siano servizi di rete i quali vengono poi aumentati di valore e impacchettati nei servizi
TLC forniti dalla TelCo ai suoi Clienti. Una TelCo aggiunge valore ai tecnoservizi di rete
(funzionalità di natura U&S) aggiungendo ad essi funzionalità di natura gestionale. Le
funzionalità dei tecnoservizi di rete assieme alle funzionalità gestionali vengono poi
venduti come “servizio TLC” ai Clienti al momento della fornitura. Se si osservano i vari
processi che si svolgono durante il ciclo di vita di un servizio TLC si vede che i
tecnoservizi sono servizi che vengono attivati solo nell’ ambito di un rapporto NO
erogatore/Utilizzatore fruitore del servizio TLC (e.g. nello svolgimento di una telefonata)
ma non hanno nulla a che vedere con le altre funzionalità/funzioni di gestione contenute
in un servizio TLC (e.g. funzionalità/funzioni relative alle aree Fault, Configuration,
Administration, Performance, Security del modello FCAPS.
284
SD
Strategic
Processes
1.1.
2.2.
3.3.
4.4.
5.5.
6.6.
ANALISI
ANALISIdelle
delleOPPORTUNITA’
OPPORTUNITA’
DEFINIZIONE
&
DEFINIZIONE &FATTIBILITA’
FATTIBILITA’
PROGETTAZIONE
PROGETTAZIONE&&VERIFICHE
VERIFICHE
SVILUPPO
(Rete
+OSS)
SVILUPPO (Rete +OSS)
IMPLEMENTAZIONE
IMPLEMENTAZIONE&&PROVE
PROVE
LANCIO
COMMERCIALE
LANCIO COMMERCIALE
Offerte/Vendite
Offerte/Vendite
Piazzamento/Esecuzione Ordinaz.
Piazzamento/Esecuzione Ordinaz.
Definizione
DefinizioneeeFirma
FirmaContratto
ContrattoSLA
SLA
Persona
+ SP
2.2.PROVISIONING
PROVISIONING
Installazione/Attivazione
Installazione/Attivazione
(Fornitura/Acquisizione)
(Fornitura/Acquisizione)
Utente =
Utilizzatore +
Cliente
3.3.USAGE
USAGE
Operational
Processes
(Transactional)
SIX PHASE
SERVICE
DEVELOPMENT
ManTec
SERVICE DELIVERY
1.1.NEGOTIATION
NEGOTIATION
SP +
NO
Persone
(Potenziali
Utenti) + SD
Utilizzazione & Segnalazione
Utilizzazione & Segnalazione
(Erogazione/Fruizione)
(Erogazione/Fruizione)
Addebiti & fatturazione
Addebiti & fatturazione
Riscossione
Riscossionepagamenti
pagamenti
Manutenzione/Riparazioni
Manutenzione/Riparazioni
Assistenza Tecnica Post-vendita
Assistenza Tecnica Post-vendita
Servizio di Call Center
Servizio di Call Center
Cliente
+ SP + NO
(Customized Service)
Utilizzatore
Attore
1.1.Segnale
Segnalevia
vialibera
libera
2.2.Digitazione
Indirizzo
Digitazione Indirizzo
3.3.Segnale
Segnalechiamata
chiamata
4.4.Inizio
sessione
Inizio sessione
5.5.Fine
Finesessione
sessione
NTWK TECHNO-SERVICE
4.4.TERMINATION
TERMINATION
(Service Session)
Cessazione & Disinstallazione
Cessazione & Disinstallazione
PdS Ciclo di Vita
Fig.2.5.4 I tecnoservizi di rete nel contesto dei processi di business di una TelCo. Il “ciclo di vita” di un
servizio TLC (il tempo scorre dall’alto verso il basso). Il Fornitore è sempre presente, il Cliente appare all’
orizzonte del Fornitore allorchè si informa sui servizi offerti (vendite), l’Utilizzatore appare all’orizzonte del
Cliente allorchè il suo terminale viene attivato. Il servizio cessa di esistere allorchè la sua infrastruttura
tecnologica di supporto viene disabilitata o addirittura disinstallata.
285
Dominio di responsabilità TelCo (persona giuridica reale)
BSS
utilizza
AMBIENTE
BUSINESS
Enterprise
Manager
(Business
Resource)
Dominio di Utenza
SERVIZIO TLC
Utente
Service Provider (SP)
SAP
FINAL PRODUCT
(Ntwk Service +
Service Delivery)
Tecnoservizio
U&S
RETI
U&S
utilizza
Funzionalità U&S
(Network Service)
fornisce
possiede
acquisisce
Comunità di
utilizzatori
Cliente
Ufficio legale
Ammistrazione Finanza
CRMAP utilizza
Tecnoservizio
Gestione
Servizi
OSS
Funzionalità di Gestione
(Service Delivery)
stipula
SLA
TC
stipula
gestisce
interconnette
(FCAPS)
2
LAN
3
opera
gestisce
Utilizzatore
TU
Integrazione
OSS-NSS-OS
NSS/OS
(FCAPS)
gestisce
Ntwk
Operator
(NO)
1
utilizza
MIS
AMBIENTE
ENGINEERING
Mondo TLC
Fig. 2.5.5 I tecnoservizi di rete nel contesto di una “Fornitura/Acquisizione di un servizio TLC”: Il modello
“Mondo TLC” rappresenta la fornitura di un servizio TLC come trasferimento di due tipi di funzionalità:
Funzionalità U & S e Funzionalità di Gestione. Questo permette di affermare che: Come un sistema TLC
osservato da un Punto di Vista SP/Utente mostra “risorse U&S” e “risorse di gestione”, le seconde con un
ruolo di supporto rispetto alle prime, così un servizio TLC fornito da un SP a un Utente contiene
“funzionalità U&S” e “funzionalità di gestione”, le seconde con ruolo di supporto rispetto alle prime.
Metaforicamente il modello assume che la funzionalità U&S sia “impacchettata” (“Packaging process”)
all’interno di un “Delivery package” costituito dalle funzionalità gestionali. Per attività di “Gestione di un
servizio TLC” si intende lo svolgimento delle Funzioni di Gestione i.e. l’ attualizzazione delle Funzionalità di
Gestione condivise da Fornitore e Cliente e supportate dalle tecnologie OSS. Le frecce verticali puntate verso
l’alto che attraversano il confine Ambiente Engineering-Ambiente Business rappresentano Tecnoservizi
forniti da tecnologie ICT. La QoS percepita dall’ Utente del servizio TLC, e quindi il suo livello di
soddisfazione, dipende in gran parte da come la funzionalità U&S viene “impacchettata” e “consegnata” cioè
dipende molto dalle funzionalità di gestione e.g. modalità di pagamento, competenza degli addetti al Call
Center, prontezza nella riparazioni, accuratezza delle bollette mensili etc. Le Reti U&S e gli OSS sono
Tecnologie ICT fornitrici di Tecnoservizi nel dominio amministrativo della TelCo. SAP=Service Access
Point, CRMAP=Customer Relation Management Access Point. TU = Terminale di Utilizzatore, TC =
Terminale di Cliente.
286
2.5.6 Acquisizione di Tecnologie ICT: comprare, costruire o affittare
La acquisizione di una Tecnologia ICT da parte di un aspirante utilizzatore si può
articolare in una varietà di scenari pratici. Una TelCo può acquisire la proprietà
(attraverso costruzione ad hoc o acquisto di prodotto pre-fabbricato), oppure affittare,
acquisire in leasing le tecnologie abilitanti i servizi TLC (nel caso di TelCo non “facility
based” come fatto sinora essa può usufruire dei servizi offerti da un'altra TelCo
proprietario/gestore di risorse attraverso opportuna relazione di business, e.g.
outsourcing). La scelta fra queste varie possibilità dipende molto dal suo business plan
i.e. la disponibilità che la TelCo ha di capitali da investire e di come e quando questi
capitali sono disponibili e dai costi associati alle varie opzioni.
2.5.6.1
La Telco può comprare (“buy”) o costruire (“build”) le tecnologie ICT
Una TelCo che volesse divenire proprietaria di una Tecnologia ICT e.g. rete o
elemnto di rete può seguire due approcci: Comprare (buy) una tecnologia prefabbricata
o costruire (build) essa stessa la tecnologia desiderata
i). Approccio “build” (Fig.2.5.6)
Una Telco decide di diventare proprietaria delle Tecnologie ICT di cui
abbisogna costruendole in proprio o facendole costruire da un industria
manifatturiera di harware e/o da uno sviluppatore di software (ICTS).
La Fig.2.5.6 illustra come nell’approccio “build” il processo “creazione/
utilizzazione” di una tecnologia ICT attraversi la zona di frontiera EngineeringBusiness fra Telco e ICTS. Tale processo inizia con la formulazione di un “bisogno”
da parte della Telco e si completa allorchè la tecnologia viene accettata dalla Telco
stessa (dopo aver effettuato e superato “prove di accettazione”). Se si segue la
sequenza delle varie attività nell’ambito del processo si riconosce il seguente anello
logico che inizia con la formulazione dei “bisogni della TelCo ” e finisce con loro
soddisfacimento:
287
HD
Analisi di mercato,
Pianificazione
reti e servizi,
Procurement
IMPRESA TelCo
(NO + SP)
Servizi TLC)
Processi
Operativi
(OSS)
Tecnoservizi di
Gestione
Tecnoservizi
di Rete
Utilizzatori
di Tecnologie
PROPRIETA’
$
TECNOLOGIE
GESTIONE
SERVIZI +CRM
(OSS/BSS)
Dati
specifica
sistema
TECNOLOGIE
U&S
+ OS, NSS
Supporto
tecnico
Scelta Tecnologica
Progettazione,
Costruzione,
Testing,
INDUSTRIA
Messa in opera
MANIFATTURIERA
TECNOLOGIE ICT
(ICTS)
SISTEMA
TLC
Produttori
di Tecnologie
Fig.2.5.6
1. Pianificazione. Formulazione “bisogni” della TelCo attraverso analisi di
mercato
2. Selezione del Costruttore (ICTS)
3. Selezione dei materiali/tecnologie implementative (e.g. componenti
necessari alla costruzione della tecnologia ICT desiderata)
4. Formulazione delle specifiche di funzionamento
5. Formulazione delle specifiche di costruzione
6. Progettazione
7. Costruzione/Testing (tecnologia U&S più tecnologie di gestione)
8. Produzione della tecnologia
288
9. Installazione, inserimento in rete (inizializzazione ) & collaudo della
tecnologia ICT nel sistema TLC da parte di personale specializzato (e.g.
prove di certificazione del software presso un test plant seguite da prove “in
campo” sulla tecnologia)
10. Esercizio e manutenzione, tecnoservizi forniti dalla tecnologia ICT ad
un utilizzatore esterno con Livelli di Prestazione compatibili con quelli
definiti nelle specifiche.
11. Verifica del soddisfacimento bisogni della TelCo.
In Fig.2.5.6 supponiamo che la Telco svolga il ruolo di “Network Operator,
NO” che eroga tecnoservizi di Rete agli Utilizzatori dei servizi TLC. Il Network
Operator ha bisogno di opportune reti di trasporto e accesso, per svolgere le proprie
attività. Questo bisogno viene identificato attraverso analisi di mercato/pianificazione
e notificato a un industria manifatturiera di hardware/sviluppatrice di software (ICTS)
opportunamente selezionata su base “gara” (competitive procurement) o
individuata/scelta a priori su base “sole source” (sole source procurement) senza
effettuare alcuna gara. Sulla base delle richieste ricevute la ICTS formula, in
collaborazione con la TelCo le specifiche di costruzione/funzionamento delle
tecnologie richieste, sceglie le tecnologie implementative e progetta/costruisce/
effettua prove e se contrattualmente richiesto installa le Tecnologie ICT prodotte in
rete (“processo di produzione” delle Tecnologie ICT).
Se il processo di produzione è eseguito correttamente, le Tecnologie ICT
funzionano con un “Livello di Prestazione” in linea con le specifiche di costruzione/
funzionamento e sono prodotte entro limiti di costo e tempo prefissati. La TelCo
paga per le tecnologie ricevute e diviene felice “proprietaria” di esse. A questo
punto le tecnologie ICT richieste sono pronte a funzionare su richiesta e per conto
dell’Utilizzatore (Network Operator). Il funzionamento della Tecnologia ICT per
conto del Network Operator è razionalizzato come “fornitura di tecnoservizi”. Se le
Tecnologie ICT sono reti U&S la corretta fornitura di questi tecnoservizi avviene per
tutto il ciclo di vita delle reti, cioè dalla “nascita” (messa in opera) alla “morte”
(disinstallazione), grazie anche all’intervento del Network Operator nel ruolo di
“Gestore di rete” che, tramite le risorse di gestione rete ed elementi di rete (OS,
Operations Systems e NSS, Network Support System) contenute nella rete stessa,
supervisiona e controlla il Livello di Prestazione delle risorse U & S riparandone
eventuali guasti ed effettuando con regolarità la manutenzione prevista.
Ovviamente la TelCo è un impresa commerciale che ha bisogno di altre
risorse di gestione e.g. per la gestione dei servizi TLC (OSS, Operation Support
Systems e BSS, Business Support Systems). Nella Fig. 2.5.6 è anche indicato un
Help Desk (HD) per il supporto di assistenza tecnica post-vendita.
ii) Approccio “buy”
289
Fin qui abbiamo esaminato l’approccio “build” all’acquisizione delle
Tecnologie ICT da parte di una TelCo. L’altro approccio è l’approccio “buy”. In
questo caso la Telco (o un Utente finale per i terminali) non fa costruire in proprio le
Tecnologie ICT di cui ha bisogno ma le compra da ICTS nel ruolo di venditori di
tecnologia (ICT technology vendors). In questo caso si dice anche che il venditore
di tecnologia è un “abilitatore tecnologico” per le attività di business svolte dalla
Telco. Notare che l’approccio “buy” è tipico di chi ha bisogno di risorse non
personalizzate facilmente reperibili sul mercato (e.g. uno switch o un telefono).
2.5.6.2
La Telco utilizza le tecnologie ICT senza esserne proprietario (“Affitto o
Leasing”)
In questo caso esistono due possibilità 1) la Telco o l’Utilizzatore finale
prende in affitto o in leasing le risorse necessarie a fornire/acquisire servizi TLC
oppure 2) acquista solo la funzionalità primaria della risorsa (non la risorsa!) da un
proprietario/gestore della risorsa attraverso un opportuna relazione di business siglata
da un contratto. Questa relazione di business autorizza l’ accesso alla risorsa e sua
utilizzazione i.e. esecuzione delle funzioni primarie su richiesta dell’utilizzatore In
tal caso il proprietario/gestore della risorsa è anche fornitore di servizio ed è sempre
presente ogniqualvolta il servizio viene attualizzato. Questo approccio è tipico di una
Telco nel ruolo di Retailer non “facility based” (Reseller) i.e. fornitrice di servizi
TLC al dettaglio senza possedere la infrastruttura tecnologica. Il Reseller possiede
una poderosa rete di distribuzione commerciale di servizi TLC e.g. punti di vendita in
negozi, catene di negozi, supermercati ed ha certamente bisogno anche delle risorse
di rete per il suo business. Tuttavia il suo business plan (piano di finanziamento) non
prevede l’impiego dei capitali necessari per acquisire queste risorse. Allora egli ne
acquisisce la disponibilità comprando servizi TLC da un Network Operator esterno
che possiede e gestisce le reti. (vedi par. 4.2.3)
2.5.7
Esempio di Tecnoservizi: “Servizi ATM” forniti da una “Rete ATM”
Facciamo un esempio pratico di tecnoservizi che bene rappresentano l’Ambiente
Engineering: i servizi ATM forniti dalle reti ATM (Asynchronous Transfer Mode). Si
tratta di servizi “connection-oriented” che in passato hanno goduto di grande popolarità e
che sono adatti a traffici multimediali con una garanzia di “Qualità di Servizio”. Per
introdurre bene questi servizi è utile rifare brevemente la storia dei servizi forniti da una
Rete Numerica Integrata nei Servizi (ISDN, Integrated Services Digital Network).
Prima degli anni 80 esistava una varietà di reti di telecomunicazione, ognuna
dedicata ad un servizio specifico: reti telefoniche, reti telex, reti dati a commutazione di
pacchetto etc. L’accesso a ognuna di queste reti richiedeva un particolare terminale
d’utente: un telefono, una Risorsa TLC fax, un computer etc. All’inizio anni 80 l’ITU-T
(allora CCITT) cominciò a studiare la possibilità di fornire agli utenti un unico accesso
per traffici di natura diversa e.g. fonia, dati e video. Come risultato di questi studi
l’accesso alle reti telefoniche digitali (reti PCM/TDM a commutazione di circuito) venne
opportunamente modificato e così nacquero i servizi NB-ISDN o servizi ISDN a banda
stretta (Narrow Band ISDN). Ad esempio, un servizio NB-ISDN offriva due canali
290
fonici (B) da 64 Kbit/sec, usati per l’informazione di utilizzazione, più un canale dati (D)
da 16 Kbit/sec per il trasporto di informazione di segnalazione. Questo servizio NBISDN si chiamava opportunamente “servizio 2B+D” per complessivi 144 Kbit/sec.
Sebbene i servizi NB-ISDN offrissero il vantaggio di uno stesso accesso per
traffici di natura diversa tuttavia essi presentavano tutte le limitazioni inerenti alla
commutazione di circuito presente all’interno della rete. Queste limitazioni erano
particolarmente onerose per traffici dati impulsivi come quelli tipici della multimedialità.
Per questo vennero introdotti e standardizzati i nuovi servizi B-ISDN a banda larga
(Broad band ISDN) che utilizzavano una nuova tecnologia: la tecnologia ATM
(Asynchronous Transfer Mode) a commutazione di pacchetto. La tecnologia di rete
ATM utilizza pacchetti di lunghezza costante (“celle”) di 53 bytes (5 bytes di intestazione
e 48 bytes di carico utile). I servizi B-ISDN sono anche chiamati direttamente servizi
ATM proprio perché forniti da una rete ATM. Caratteristica importante di questi servizi
è che sono “connection oriented” cioè prima dell’invio delle celle, la rete stabilisce
tramite ATM-switches un circuito sorgente-destinatario (“virtual circuit”) con
determinate caratteristiche trasmissive in modo da poter garantire una certa Qualità di
Servizio (QoS). Questa modalità trasmissiva a pacchetto differisce da quella
“connectionless” (e.g. servizio internet) dove ogni datagramma segue di volta in volta
un percorso diverso definito da routers, dipendente delle condizioni di traffico in rete. In
tal caso non esiste una QoS prestabilita e il servizio è definito del tipo “best effort” o
“first come first serve”.
I Tecno - servizi ATM forniti dalle reti ATM sono specificati come indicato nella
Tavola 2.5.7.1 (prima colonna a sinistra) da parametri che caratterizzano 1) le sorgenti di
traffico (descrittori di traffico) e 2) le prestazioni delle connessioni di rete (Parametri di
Qualità di Servizio,QoS, o Grado di Servizio, GoS).
Vengono utilizzati i seguenti acronimi:
1) SERVIZI. CBR, real time VBR, non real time VBR, ABR, UBR e GFR (dove
le lettere hanno il significato seguente: C=Constant, B=Bit, R=Rate, V=Variable,
A=Available, U=Unspecified, G=Guaranteed, F=Frame),
2) DESCRITTORI di TRAFFICO. PCR (Peak Cell Rate), SCR (Sustainable
Cell Rate), MCR (Minimum Cell Rate), MBS (Maximum Burst Size) e MFS (Maximum
Frame Size).
3) QoS. Max CTD (Maximum Cell Transfer Delay), CDV (Cell Delay Variation)
e CLR (Cell Loss Ratio)..
291
QoS
Descrittori di traffico
Max
CDV CLR PCR MCR SCR MBS MFS
CTD
CBR
rt
VBR
nrt
VBR
x
x
x
x
x
x
x
x
x
x
x
x
x
x
UBR
x
ABR
x
x
GFR
x
x
x
x
Tav. 2.5.7.1 I servizi ATM forniti da una rete ATM
Notare come quella che nel linguaggio “Engineering” è chiamata Qualità di
Servizio in effetti è una caratteristica definita in termini di parametri misurabili a livello
292
rete. Si tratta, quindi, di parametri appartenenti alla categoria da noi precedentemente
definita dei “parametri prestazionali di rete”.
2.5.8 Esecizi relativi al par. 2.5.
1) I “Tecnoservizi” di rete sono ben noti a tutti gli studenti di ingegneria TLC. Si prenda un testo di “Reti
di telecomunicazione” e si individuino i tecnoservizi. Ad esepio si faccia riferimento ai seguenti testi,
A. Biocca, “Reti digitali”, Hoepli Informatica, 2002
R. Adinolfi, “Reti di computer”, McGraw-Hill, 1999
A. Pattavina, “Reti di telecomunicazioni”, McGraw-Hill, 2003
O. Bertazioli, “Telecomunicazioni”, Zanichelli, Vol.I & II, 2004
2) Nessuno si sognerebbe mai di dire che un condensatore o doppino telefonico forniscono un servizio ad
un loro utilizzatore, pochi direbbero che un autocommutatore offre un servizio a un suo utilizzatore, quasi
tutti parlano di servizi internet forniti da una rete internet. Come mai? Eppure sono tutte tecnologie ICT.
(Suggerimento: pensare all’intelligenza delle varie tecnologie e alla loro autonomia e indipendenza
operativa rispetto all’utilizzatore)
3) Si può usare l’espressione tecnocentrica “Una tecnologia ICT offre un tecnoservizio ad un suo
utilizzatore” oppure l’espressione usocentrica “un utilizzatore utilizza una tecnologia ICT come risorsa”
per descrivere la relazione tecnologia ICT-Utilizzatore. A seconda del tipo di tecnologia ICT (e.g. capacità
di processing/memoria), in alcuni casi è più appropriato usare la prima espressione mentre in altri casi è più
appropriato usare la seconda. Quale è il criterio di scelta? Scegliendo due tecnologie ICT diverse, illustrare
dapprima uno scenario A nel quale è più appropriato usare la prima espressione poi illustrare uno scenario
B nel quale è appropriato usare la seconda espressione.
4) Spiegare quale è il momento in cui un utilizzatore esterno “acquisisce” un tecnoservizio da una
tecnologia ICT cioè quando una tecnologia ICT “fornisce” (non “eroga”!) un tecnoservizio all’ utilizzatore
esterno. (Suggerimento: pensare alla differenza fra un processo di “fornitura/acquisizione” di un servizio e
un processo di “erogazione/fruizione” di un servizio)
5) Si supponga di operare in un ambiente Business. Quando voi acquisite un servizio TLC da un fornitore
di servizi e.g. firmate un contratto di servizio SLA (Service Level Agreement) con un fornitore, in effetti
che cosa acquisite? Certamente acquisite delle potenzialità. Ma di cosa si tratta? Acquisite solo certi
tecnoservizi e.g. servizi di telefonia forniti da reti telefoniche, oppure acquisite tecnoservizi più
qualcos’altro?
6) Quale è la differenza fra il concetto di funzionalità posseduta da una tecnologia ICT introdotto per i
tecnoservizi e il concetto di funzionalità posseduta da una persona TLC? (Suggerimento: Pensare al
significato del binomio capacità/abilità nei due casi)
7) Che cosa si intende in questo corso per “qualità” di un tecnoservizio? Confrontare la risposta con le
definizioni di “qualità di servizio” fornite nell’Esempio sottostante. Se siete confusi parlatene con il
professore.
8) Perché un tecnoservizio è definito in un ambiente Engineerig e un servizio TLC è definito in un
ambiente Business? (Suggerimento: Pensare alle “reti & servizi” studiati nel corso di “Reti di
telecomunicazione”)
9) Spiegare la frase “Non esiste la gestione di un tecnoservizio ma esiste un tecnoservizio di gestione”
293
11) Una rete TLC è costituita da reti di utilizzazione, reti di segnalazione che permettono la riallocazione
dinamica del traffico nelle prime e reti di gestione che supervisionano e controllano le prime e le seconde.
Tutti e tre i tipi di rete sono costituite da elaboratori digitali interconnessi da linee di trasmissione e
residenti nei nodi della rete. Quale è la differenza fra le applicazioni residenti in questi eleboratori?
Fare riferimento alle Fig.2.3.1 e 2.3.2.
2.5.9 APPENDICE ai Par. 2.4 e 2.5
ESEMPIO No.1. Ogni Tecnologia ICT possiede funzionalità primarie e le attua nello svolgimeto
di funzioni primarie.
1) Quali sono le funzioni primarie svolte da una rete U&S?
2) Quali sono le funzioni primarie svolte da un apparecchiatura terminale ad essa connessa.
[Una rete di utilizzazione (trasporto più accesso) svolge una funzione primaria di
trasferimento il cui scopo è trasferire informazione U&S fra terminazioni di rete remote (e.g. fra
UNI). Questa funzione primaria è il risultato dello svolgimento dei seguenti componenti funzionali
interni alla rete:
1) multiplazione di canale / commutazione / controllo di flussi di informazione tramite
apparati di rete residenti nei nodi della rete
2) trasferimento di informazione sui mezzi elettromagnetici che interconnettono gli apparati.
Apparati di rete e mezzi elettromagnetici sono opportunamente interconnessi secondo una
architettura funzionale della rete e operano in maniera coordinata secondo una logica prestabilita.
Una apparecchiatura terminale (e.g. DTE, Digital Terminal Equipment nel caso di una rete
dati) connessa alla rete svolge una funzione primaria di intermediazione/utilizzazione il cui scopo è
generare o raccogliere ma, soprattutto, utilizzare informazione di utilizzazione. Questa funzione è il
risultato dello svolgimento di componenti funzionali interni al terminale come 1) codifica/decodifica
dell’informazione secondo una sintassi comune, 2) interpretazione della informazione ricevuta
(riconoscimento semantico)].
ESEMPIO No. 2 Funzionalità primaria di un commutatore.
La funzionalità primaria posseduta da un commutatore è la “capacità/abilità funzionale di
commutare segnali” mentre la funzione primaria effettivamente svolta da un commutatore su richiesta
di un utilizzatore esterno è “commutare segnali”. Le modalità con cui si svolge la funzione di
commutazione dipendono dalla particolare tecnologia adottata dal costruttore. Nel caso in cui
l’ambiente esterno al commutatore sia caratterizzato da una assenza di segnale di ingresso al
commutatore e/o assenza di segnale di comando di commutazione, il commutatore non svolge alcuna
funzione primaria tuttavia continua a possedere la sua funzionalità primaria cioe’ la capacità funzionale
di commutare segnali permane ed è una caratteristica intrinseca di un commutatore in buone condizioni
di funzionamento.
Invece nel caso di guasto, il commutatore perde la capacità funzionale di commutare segnali
cioè la sua funzionalità primaria è nulla, fintantochè non ne venga completata la riparazione. Quindi
“riparare” il commutatore significa ristabilire la sua “funzionalità primaria”.
294
RISORSA
SERVIZIO
Servizi stampa,
immagazzinamento
e elaborazione dati
Server di
Stampa
File Server
UTILIZZATORE
Servizi di accesso
e applicazioni
Servizi di
interconnessione
RETE
TLC
(LAN)
Server di
Elaborazione
HC
U
HC
U
HC
U
HC
U
Fig. 2.5.9.1
ESEMPIO No.3 Attuazione di funzionalità in un commutatore
Una rete TLC possiede la caratteristica interna di commutare il traffico da un ramo all’altro
della rete stessa. Ciò è possibile perchè essa contiene commutatori ubicati nei suoi nodi e ogni
commutatore possiede la funzionalità di commutazione. Quando un commutatore commuta il traffico
da una sua porta d’uscita all’altra (cioe’svolge la sua funzione primaria) esso si aggiorna allo stato
“attuale” della rete e poi mette in atto questa funzionalita’ (cioè “attualizza la sia funzionalità”).
ESEMPIO No.4 Estensione di funzionalità tramite rete LAN
Facciamo riferimento alla Fig. 2.5.9.1 In una grande azienda privata ogni impiegato possiede
un personal comnputer connesso con una rete locale LAN, Local Area Network (“Host Computer”,
HC). La rete LAN è, a sua volta, connessa con una molteplicità di servers “centri di servizio” di vario
tipo condivisi da tutti gli impiegati. Il primo utilizzatore (U) in alto a destra richiede/ottiene la stampa
di un suo documento a/da una stampante (server di stampa). La connessione LAN estende a questo
utilizzatore la funzionalità di stampa posseduta dalla stampante. Allorché, su richiesta di un impiegato,
la stampante stampa un documento (i.e. svolge la sua funzione primaria) essa attualizza la sua
funzionalita’ primaria di stampare.
ESEMPIO No. 5 Lo “stato operazionale” e lo “stato di utilizzazione di uno switch
Una unità di commutazione ha ridondanza “2 per 1” cioè è costituita da uno switch principale
e uno switch di back up, entrambi in uno stato operazionale “abilitato”. Lo switch di back up si trova in
uno stato “inattivo” cioè possiede la capacità di commutare ma non commuta alcun segnale
295
fintantochè lo switch principale, normalmente in uno stato “occupato” o “attivo” a seconda se è
completamente o parzialmente utilizzato, non si guasta e debba essere rimpiazzato.
ESEMPIO No. 6 Gli stati di un amplificatore
Un amplificatore ha una banda passante totale di 10 canali telefonici si trova in uno stato
operazionale “abilitato”: in uno stato “occupato”, amplifica tutti i 10 canali di traffico telefonico (pF =
sf) mentre in uno stato “attivo” amplifica 5 canali di traffico telefonico (pF >sf) lasciando 5 canali
vuoti utilizzabili da altri utilizzatori.
ESEMPIO No.7 Telco fornitrice di servizi multimediali costruisce in proprio una rete MAN in
fibra ottica (approccio “build” alla proprietà della risorsa).
Una azienda Fornitore di servizi TLC multimediali interattivi (e.g. videoconferencing, tele-assistenza)
prevede di operare in una piccola area metropolitana. A tal fine ottiene le necessarie autorizzazioni
dalle autorità locali competenti e costruisce in proprio una rete MAN (Metropolitan Area Network) a
cavi ottici come infrastruttura tecnologica per supportare i suoi servizi. Fa questo con l’aiuto di un
Costruttore di tecnologie specialista in reti in fibra ottica il quale ha la completa responsabilità della
“produzione” della rete. (progettazione, costruzione, installazione, testing e messa in opera). La rete
MAN così costruita è una rete di ultima generazione che porta il cavo ottico fino alla residenza del
singolo Utente (“Fiber to the curb”) e quindi offre ad utenze consumer un accesso a larga banda adatto
ad applicazioni multimediali.
Diciamo che la rete possiede la capacità funzionale di interconnettere terminali multimediali remoti
ubicati presso le residenze degli Utenti (funzionalità primaria). In questo caso l’azienda è proprietaria
e gestisce in proprio la rete MAN (tecnologia abilitante) ed inoltre gestisce i servizi di
videoconferencing e tele-assistenza. Tramite il possesso della rete MAN l’azienda possiede anche la
funzionalità primaria della risorsa cioè ha la capacità funzionale di interconnettere terminali remoti.
ESEMPIO No 8 Una Azienda multinazionale compra il software necessario per cooperazione
intra-aziendale (approccio “buy” alla proprietà della risorsa)
Una azienda multinazionale è un Utente internet ed ha bisogno di un software applicativo (risorsa) per
permettere ai suoi impiegati di co-operare su un intranet aziendale. Quindi l’azienda compra il
software da un venditore di tecnologia internet, un Internet Software Vendor (ISV) e gestisce
questo software in proprio. Essa acquisisce la funzionalita’ primaria del software diventandone il
proprietario mediante acquisto. Il venditore di software ISV e’ un abilitatore tecnologico e il software
acquistato è una tecnologia abilitante.
ESEMPIO No. 9 Un Utente compra un telefono (approccio “buy” alla proprietà della risorsa)
Un telefono possiede la funzionalità primaria di inviare/ricevere informazione di segnalazione e
informazione di utilizzazione. Questa funzionalita’ si attualizza nello svolgimento di una telefonata
(funzione primaria) ogniqualvolta l’utilizzatore lo ritenga opportuno. La funzionalità primaria è
acquisita da un utilizzatore tramite acquisto della risorsa e.g. compre il telefono in un negozio di
apparecchiature telefoniche. Il telefono e’ una tecnologia abilitante, il venditore di telefoni e’ un
abilitatore tecnologico.
ESEMPIO No.10 Una azienda TLC fornitrice di servizi internet ha bisogno di accedere alla rete
internet. Essa (utilizzatore) ha bisogno dei servizi offerti da una rete di accesso (risorsa). Essa non
compra la rete di accesso alla rete internet bensì sottoscrive ai “servizi di accesso” forniti da un
Internet Service Provider (ISP) proprietario della rete di accesso. .
ESEMPIO No.11 Una Impresa TLC multinazionale ha bisogno di un software applicativo per un
servizio internet di progettazione cooperativa in rete. In effetti l’impresa non ha bisogno del
“software” come “bene materiale” ma piuttosto della funzionalità posseduta dal software. L’impresa
296
decide che questo software non è di importanza strategica, quindi non ritiene opportuno acquistarlo
direttamente ma ne ottiene la funzionalità tramite outsourcing (vedi qui di seguito) da un Application
Service Provider (ASP). L’ASP, a sua volta, può essere il diretto proprietario del software oppure
può acquisire una “licenza d’uso” pagando royalties a uno sviluppatore di software. L’ASP fornisce
servizi (utilizzazione, gestione, aggiornamento del software) all’Impresa TLC che accede al suo sito,
dietro pagamenti periodici fissi (“flat rate billing”) o indicizzati a un parametro rappresentativo
dell’utilizzo del software stesso (“usage based billig”).
297
2.6
“Livello di Prestazione” di una Tecnologia ICT e
“Qualità di Servizio” di un servizio TLC
2.6.1 “LoP” (Level of performance) di una rete TLC e “QoS” (Quality of Service)
di un servizio TLC
In questo paragrafo continuiamo con il nostro approccio interdisciplinare
Engineering-Business alla gestione di sistemi e servizi TLC. Studiamo la qualità di
funzionamento delle Tecnologie U&S in Ambiente Engineering (e.g. erogazione di
tecnoservizi a Network Operator e Utilizzatori del “service core” dei servizi TLC)
assieme alla qualità della gestione di servizi TLC da parte di SP/Utenti in un Ambiente
Business (e.g. fornitura/ acquisizione di servizi TLC, segnalzione guasti/riparazioni,
fatturazioni/ pagamenti). Ricordiamo ancora una volta la distinzione fra
fornitura/acquisizione e erogazione/fruizione di un servizio TLC:
1) la fornitura/acquisizione di un servizio TLC (compra-vendita, in un
contesto commerciale) avviene una tantum nel momento in cui l’ “aspirante Utente” che
ne ha fatto domanda entra in possesso delle relative “funzionalità TLC” (U&S e
gestionali) e diventa ufficialmente Utente di un servizio TLC e Cliente della TelCo
fornitrice i.e. dopo che egli ha sottoscritto (firmato) un contratto SLA e il suo terminale è
stato allacciato alla rete TLC (Ambiente Business).
Impresa reale
TelCo
PdV
Engineering
PdV
Business
Service
Provider
Network
Operator
Specifica / Richiede
Tecnologie ICT
Pagamenti
$
Vende
Tecnologie ICT
$
ICT
Supplier
ICT
Vendor
ManTec
Interfaccia
interna fra
unità
organizzative
gestieconomia
Fig. 2.6.1.1 Le Tecnologie ICT sono “Prodotti Engineerig” creati da Architects/Designers/
Builders in imprese ICTS (fasi di analisi/specifica/scelta tecnologica/progettazione/
costruzione/collaudo) o gestiti/eserciti da Network Operators in imprese TelCo (fase operativa i.e.
durante la erogazione del “service core” dei servizi TLC). Le zone bianche rappresentano le Viste
Business delle imprese reali ICTS e TelCo.
298
2) la erogazione/ fruizione di un servizio TLC avviene in maniera episodica su
richiesta di un Utilizzatore di un servizio TLC durante una “sessione” di un servizio TLC.
In una sessione di servizio TLC il Network Operator eroga il “service core” di un servizio
TLC e l’ Utilizzatore ne fruisce. La erogazione del “service core” è anche denominata
“fornitura di un tecnoservizio di rete” (network service). Network Operator e
Utilizzatore svolgono le componenti funzionali U&S del servizio TLC fornito (“funzioni
U&S”), attuando le corrispondenti “funzionalità U&S” acquisite nel precedente processo
di fornitura/acquisizione del servizio TLC (vedi Capitolo 4).
Come già indicato in precedenza, la “Qualità di Servizio, OoS, Quality of Service” di
un servizio TLC è un indicatore del “livello di soddisfacimento delle esigenze dell’ Utente
del servizio TLC” (“desideri/bisogni” nel caso l’Utente sia una persona fisica). Ma, come
mostrato in Fig.2.5.5, un servizio TLC ha due componenti funzionali: funzionalità/funzioni
U&S (tecnoservizi di rete) e funzionalità/funzioni gestionali ( processi di “service delivery”).
Ora, mentre la erogazione di un tecnoservizio da parte di rete U&S/Network Operator
avviene in un Ambiente Engineering ed ha una qualità obiettiva indipendente dalla
percezione dell’ Utilizzatore, la erogazione di un servizio TLC avviene in un Ambiente
Business ed ha una qualità dipendente dalla percezione del servizio provata dall’ Utente
(variabile nel tempo e influenzata da fattori soggettivi e sociali e.g. tecniche di
commercializzazione dei prodotti adottate dal SP in Ambiente Business).
Questa differenza giustifica la nostra scelta (Vedi anche ITU-T Recommendation
I.350, General aspects of quality of service and network performance in digital networks,
03/1993) di distinguere due tipi di “qualità”: Livello di Prestazione (Level of
Performance, LoP) e Qualità di Servizio (Quality of Service, QoS). La prima relativa
alle tecnologie abilitanti e ai tecnoservizi da esse erogati e la seconda relativa a un
servizio TLC nel suo complesso.
Quindi QoS e LoP sono mutuamente relazionati poiché la qualità della
erogazione/fruizione di un servizio TLC nel suo complesso “service core + parte
gestionale” dipende anche dalla qualità di funzionamento delle tecnologie ICT abilitanti
Infatti per avere un servizio TLC con una buona QoS è necessario che anche la relativa
LoP sia buona (non è possibile che un servizio TLC sia di buona qualità se la tecnologia
abilitante funziona male cioè funziona con scarsa qualità). Tuttavia una buona LoP non è
sufficiente a garantire che anche la QoS sia buona. Infatti, come già detto, nella
definizione di QoS oltre a fattori tecnologici (fattori oggettivi) intervengono fattori
umani legati al comportamento/percezione dell’ Utente del servizio TLC, fattori
soggettivi di natura aleatoria più difficili da predire/misurare. Ma vediamo i dettagli di
tutto questo qui di seguito.
2.6.2
Livello di Prestazione (LoP) di una Tecnologia gestita (Ambiente
Engineering)
Il Livello di Prestazione (LoP) di una tecnologia ICT è espresso da una
molteplicità di parametri prestazionali utilizzati in varie fasi del ciclo di vita della
tecnologia stessa e.g. specifica/progettazione/costruzione (vedi Designer/Builder in Fig.
299
2.6.1.1). operazione/manutenzione (vedi Network Operator, Fig.2.6.1.1). Quindi questi
parametri sono scelti/utilizzati da persone con competenze professionali Engineering (e.g.
ingegneri TLC o informatici) ma potrebbero essere incomprensibili per una comunità di
Utenti di servizi TLC che operano in Ambiente Business.
Ora facciamo riferimento alla fase operativa di una tecnologia ICT e.g. rete o
elemento di rete in un sistema TLC gestito da un Network Operator e vogliamo studiare il
Livello di Prestazione LoP come indicatore della bontà di funzionamento della
tecnologia.
Quando si parla di operazione di una Tecnologia ICT in effetti si parla del
funzionamento di tutto il “complesso” tecnologia U&S + tecnologie gestionali e.g. OS,
per gli elementi di rete e OS+NSS per le reti. Per brevità chiamiamo “complesso”
l’insieme di 1) tecnologia U & S da gestire, 2) tecnologie ICT gestionali, 3) altre risorse
di supporto nonICT. Questo “complesso” è qui indicato come “Tecnologia gestita”
1
F3
LoP
F3m
F2
F2m
1
F1m
F1
1
2
2
2
LoP = √ [ F1 + F2 + F3 ]
LoP
Fig.2.6.2.1 Il Livello di Prestazione è un vettore LoP le cui componenti
hanno valori superiori a certi valori di soglia Fim (i = 1,2,3)
La qualità di funzionamento di una Tecnologia gestita (e.g. rete o elemento di rete
TLC), anche denominata “Prestazione” (Performance), è espressa in funzione di una
molteplicità di Parametri Prestazionali (Pi, i=1,2,3….) dimensionali (dimensioni
specificate dal progettista) o da Fattori Prestazionali (Fi, i =1,2,3,4…) adimensionali.
Un fattore prestazionale Fi è definito come il rapporto Pi/Ps,max fra il valore misurato di
un Parametro Prestazionale Pi e il suo “valore massimo di specifica” Ps,max espresso
300
nelle stesse unità di misura. Quindi un fattore prestazionale può assumere valori numerici
compresi fra un minimo e 1 (Fig.2.6.2.1), laddove il valore 1 rappresenta la massima
qualità di funzionamento.
La natura dei parametri prestazionali che entrano nelle specifiche di
funzionamento di una tecnologia e che devono essere monitorati/controllati in fase
operativa variano a seconda del tipo di tecnologia (e.g. tecnologie ICT a radio frequenza,
o tecnologie in banda base come quelle degli elaboratori digitali) e del tipo di
applicazione (e.g. reti digitali terrestri wireline o wireless, reti satellitari, elemento di rete
etc.).
Ad esempio per canali di TV satellitare parametri prestazionali possono essere la
probabilità di errore Bit Error Rate (BER) associata alla trasmissione TV, il tempo di
ritardo dei canali televisivi, la potenza RF in uscita dei TWTA installati a bordo del
satellite etc. Un elaboratore digitale può essere caratterizzato da tempi di attesa, tempi di
risposta, lunghezza di coda, spazio di memoria, throughput, tempo di utilizzazione etc.
Nel caso la tecnologia sia una rete TLC un parametro prestazionale può essere il numero
di connessioni circuitali eseguite o abortite (successful or failed connection
establishment) a seguito di una richiesta di chiamata (call request) in intervalli di tempo
prestabiliti, tempi di ritardo nell’instaurazione della connessione, qualità della
connessione (opportunamente definita), numero di guasti o malfunzionamenti della rete,
e.g. cell loss ratio in una rete ATM, accuratezza nel mantenimento di una
documentazione storica degli “stati” della rete etc.
In fase operativa le misurazioni possono avvenire su base periodica (periodicità
stabilita dal gestore) o episodica allorché si verifica l’attraversamento di un valore di
soglia (valore di soglia stabilito dal gestore). L’invio di dati prestazionali al gestore può
implicare l’invio diretto di dati misurati (raw data) o l’invio dei risultati di una
elaborazione locale dei dati misurati applicando certi algoritmi prefissati (e.g. attraverso
un processo di “summarization”, vedi dopo).
Un certo insieme di valori dei parametri/fattori prestazionali (opportunamente
definito a priori) definisce il Livello di Prestazione (Level of Performance, LoP) della
Tecnologia ICT gestita. L’ LoP può rappresentarsi come una molteplicità di fattori
prestazionali mutuamente indipendenti (e.g. sottoforma di matrice o tabella) oppure
come una funzione dei fattori prestazionali definita in base a certi algoritmi prestabiliti
i.e. LoP = f (F1, F2, F3….FN) dove la funzione f( ) specifica l’algoritmo adottato.
Nel caso più generale i fattori prestazionali sono mutuamente indipendenti e
l’LoP è rappresentato dai valori di una n-pla di fattori opportunamente definita a priori
da misurare e inviare al gestore.
Tuttavia esistono situazioni reali in cui i fattori prestazionali sono
interdipendenti e.g. in una n-pla di fattori prestazionali l’aumento/diminuzione del
valore di uno può essere compensato dalla diminuzione/aumento degli altri i.e. si può
effettuare un trade-off fra i valori dei vari fattori ottenendo lo stesso valore di LoP. In tal
301
caso si può ridurre la quantità di dati inviata al gestore calcolando localmente la funzione
rappresentativa della interdipendenza dei fattori prestazionali. (Vedi Giuseppe Iazeolla,
“Impianti, reti, sistemi informatici”, Franco Angeli, 2004, pag. 22-23).
Un esempio estremamente semplice è mostrato nella Fig.2.6.2.1. Qui LoP è
rappresentato come un vettore le cui componenti sono i valori misurati dei fattori
prestazionali (F1, F2, F3) compresi in un intervallo di specifica i.e. inferiori ad 1 e
superiori a certi valori minimi di specifica (F1m, F2m, F3m) al di sotto dei quali le
tecnologia funziona “fuori specifica” (zona di malfunzionamento). In questo caso il
valore del LoP è uguale alla radice quadrata della somma dei quadrati dei fattori
prestazionali ed ha lo stesso valore per tutte le terne di fattori che definiscono punti sulla
superficie di una sfera con centro nell’origine delle coordinate e raggio LoP (definita
nello spazio coordinato F1,F2,F3 da LoP=cost).
Nel caso di una rete PSTN i parametri prestazionali possono scegliersi in varie
maniere. In generale sono scelti per caratterizzare almeno le seguenti aree dove possibili
malfunzionamenti possono verificarsi:
1) Transmission Performance. Prestazione dei sistemi di trasmissione
(e.g. sistemi di trasporto dell’informazione)
2) Call Processing Performance. Prestazione degli autocommutatori e
dei sistemi di signaling (e.g. instaurazione di una connessione fra
utente chiamante e utente chiamato)
3) Availability. Disponibilità della rete (i.e. percentuale del tempo
durante la quale la rete funziona a specifica)
Altri esempi di parametri prestazionali di rete (e.g. rete ISDN con “bearer
services” i.e. da terminazione di rete a terminazione di rete con esclusione dei terminali)
sono: ritardo/errore/negazione nella instaurazione di una connessione, velocità di
trasferimento/ritardo nel trasferimento dell’informazione d’utilizzazione, probabilità
d’errore o di perdita dell’informazione di utilizzazione, ritardo/errore/negazione nel
rilascio di una connessione etc. (Raccomandazione ITU-T I.350, 3/1993)
2.6.2.1
Efficienza economica /efficacia di una Tecnologia ICT in fase operativa.
(parte facoltativa)
Una volta definito il livello LoP di una certa Tecnologia ICT attraverso la misura
dei suoi parametri/fattori prestazionali, i dati possono essere utilizzati per calcolare i
corrispondenti valori di “efficienza economica ” e “efficacia economica” cioè si può
verificare se il funzionamento della “Tecnologia gestita” (come precedentemente
definita) avviene in maniera economicamente soddisfacente.
302
L’efficienza (efficiency) economica di una “Tecnologia gestita” è una misura del
rapporto prestazione/costo del “complesso” tecnologia da gestire + risorse gestionali.
Essa può definirsi/calcolarsi in varie maniere. Una possibile definizione è la seguente:
Efficienza economica = VE (LoP) / costo
dove VE (LoP) = valore economico (LoP) è una funzione dell’LoP indicativa
del valore economico beneficiato dall’utilizzatore della Tecnologia gestita e il “costo” è
il costo totale affrontato dall’utilizzatore stesso. Il valore economico è la valutazione del
beneficio tratto dall’utilizzatore in corrispondenza a un certo valore dell’LoP, espressa in
termini di un mezzo di scambio e.g. denaro. Il costo totale è il costo complessivo di
acquisizione e di esercizio dei vari componenti del “complesso” preso in considerazione.
Più precisamente il costo totale è il costo di acquisizione più il costo unitario del
personale addetto alla gestione (e.g. entrambi in $/anno).
Nel nostro caso il valore economico associato al funzionamento di una particolare
tecnologia non è facile da calcolare perché la tecnologia fa parte di una infrastruttura
abilitante i servizi TLC forniti da una TelCo e i benefici sono spesso evidenziati a livello
servizi. Per far questo bisogna conoscere l’impatto del LoP sul QoS di un certo servizio
fornito e poi l’impatto del QoS sulle entrate generate dalla fornitura del servizio cioè si
deve risalire la catena “gestione elementi di rete”-“gestione reti”-“gestione servizi” –
“gestione relazioni clienti”.
ATTENZIONE! Per noi qui è sufficiente capire la natura del problema in termini
molto semplici . Ad esempio l’efficienza economica di una nuova Tecnologia ICT
può valutarsi rispondendo alle seguenti domande: se sono “Mister TelCo” e voglio
rimpiazzare una vecchia Tecnologia ICT legacy attualmente in uso in una delle mie
reti TLC con una Tecnologia ICT di nuova generazione più performante
(erogazione dello stesso servizio ma con costi operativi minori e.g. minor consumo
energetico, minor manutenzione e impatto ambientale) quanto mi viene a costare la
sostituzione (disinstallazione della vecchia tecnologia, acquisto e installazione della
nuova tecnologia, perdita di traffico durante il rimpiazzo) e quanto risparmio in
termini di costi operativi nei prossimi cinque anni? Oppure se la nuova tecnologia
sostitutiva migliora gli attuali servizi a parità di costi operativi quale aumento posso
introdurre nelle tariffe dei nuovi servizi aumentando così le entrate?
In conclusione il funzionamento di una Tecnologia gestita è tanto più
economicamente efficiente
1) quanto più è alto il livello di prestazione per un certo costo del “complesso”
tecnologia da gestire+risorse gestionali. Ad esempio l’efficienza, a parità di
costi, può essere migliorata con tecnologie U&S e/o gestionali più performanti
di nuova generazione.
2) quanto più basso è il costo totale del “complesso” per un certo livello di
prestazione prefissato. Ad esempio l’efficienza può migliorarsi riducendo i
costi delle risorse gestionali umane tramite aumento del livello di
automatizzazione del “complesso”.
303
Molto spesso si sceglie questa seconda accezione e l’efficienza economica di una
tecnologia ICT è presa come un «indice di costo» inversamente proporzionale al costo
stesso.
L’ efficacia (effectiveness) di funzionamento di una “Tecnologia gestita” è una
misura di quanto il funzionamento di una tecnologia ICT gestita sia in linea con la
domanda dei suoi utilizzatori. Per un certo costo, l’efficacia del “complesso” è definita
come il rapporto fra il Livello di Prestazione e un Livello di Prestazione richiesto da
utilizzatori esterni (LoP^) definito in modo analogo all’LoP i.e.
Efficacia = LoP / LoP^
L’efficacia si può migliorare soddisfacendo meglio o anticipando la domanda,
presente o futura degli utilizzatori e.g. riducendo i tempi di processing, migliorando la
flessibilità operativa etc.
ATTENZIONE! Il Livello di Prestazione LoP^ richiesto dagli utilizzatori
della tecnologia può coincidere con un livello LoP* fisso. In questo caso si
parla di efficacia di natura statica. Si tratta di una situazione in cui i valori
dei parametri prestazionali che definiscono l’ LoP* specificato nelle
specifiche di funzionamento della tecnologia vengono “meccanizzati” in essa
e restano inalterati fino alla fine del suo ciclo di vita. Se invece la tecnologia
è riconfigurabile con un LoP* adattabile nel tempo alla domanda d’utenza
(e.g. rete multiservizio con valori diversi di tempo di ritardo o jitter o tasso
di errore in termini di pacchetti persi etc. ) allora si parla di efficacia di
natura adattiva.
2.6.2.3
Cosa accade se una tecnologia ICT non è gestita ?
Se un sistema TLC viene reso più automatizzato a costo inalterato, i tempi e la
qualità dei processi supportati possono essere migliorati e possono soddisfare meglio la
domanda d’ utilizzatore. In questo caso l‘efficacia del sistema è aumentata. Se la richiesta
di un utilizzatore esterno cambia nel tempo e un sistema non si adegua ad essa il sistema
può continuare ad essere efficiente (stessa prestazione e stessi costi) ma perde di efficacia
poichè il suo funzionamento non è più in linea con le richieste degli utilizzatori.
Queste considerazioni di natura economico-commerciale divengono
particolarmente importanti se si cerca una risposta alla seguente domanda, molto spesso
posta dagli studenti di questo corso: «Cosa accadrebbe se una tecnologia ICT non fosse
gestita?». La risposta è facile se si è capita la valenza economica della gestione di una
tecnologia cioè se ci si muove in un territorio interdisciplinare che integra aspetti
Engineering e Business. La risposta è: senza gestione una tecnologia potrebbe, in linea
di principio, anche funzionare ma non in maniera economica cioè, in pratica,
funzionerebbe con bassa efficienza e/o bassa efficacia. Infatti una tecnologia ideale
priva di gestione si troverebbe in una delle due seguenti situazioni,
1)
Situazione di BASSA EFFICIENZA: la tecnologia è realizzata con una
complessità relizzativa cosi’ elevata e/o tecnologie speciali talmente perfette
304
(supposto che esistano) da non aver bisogno di gestione per funzionare a specifica
in ogni condizione possibile, ma è talmente costosa da rendere il suo
funzionamento economicamente svantaggioso e quindi non accettabile per chi
deve sostenere i costi di questo funzionamento e.g. business management e/o da
investitori/finanziatori (bassa efficienza),
2) Situazione di BASSA EFFICACIA: la tecnologia senza gestione opera con un
livello di complessità tecnologica accettabile e/o adotta tecnologie facilmente
reperibili sul mercato con costi accettabili ma offre prestazioni infime e.g. con
LoP molto lontano dai valori di specifica. Quindi la sua prestazione non è in
linea con le esigenze degli utilizzatori (bassa efficacia)
2.6.3
“Qualità di Servizio” dei servizi TLC in Ambiente Business.
Finora abbiamo fatto riferimento ad un Ambiente Engineering e abbiamo
parlato di Livello di Prestazione di una Tecnologia ICT gestita, misurato durante la sua
fase di funzionamento. Ora ci spostiamo in un Ambiente Business e parliamo della
Qualità di Servizio dei Servizi TLC forniti da una TelCo a Utenti finali. Qui, come già
detto, l’ Utente finale dei servizi TLC gioca un ruolo estremamente importante non solo
perchè effettua i pagamenti per i servizi fruiti e quindi è la principale sorgente di entrate
per la Telco ma anche perchè egli decide se il servizio soddisfa le sua aspettative
(soddisfazione dell’utente) o meno (insoddisfazione dell’utente) cioè egli stabilisce se
il servizio ha rispettivamente una buona QoS o una cattiva QoS (QoS = Quality of
Service). Se il servizio è percepito dall’Utente di cattiva qualità, egli è insoddisfatto e
prima o poi si allontana da quel fornitore, con conseguenze economiche disastrose per
quest’ultimo.
2.6.3.1
Qualità di Servizio: il modello PZB
In generale la qualità di un servizio è legato al concetto di soddisfacimento delle
aspettative dell’ Utente. L’American Society for Quality Control fornisce la seguente
definizione di «qualità» di un prodotto (bene o servizio):
“La qualità di un prodotto è la totalità delle caratteristiche (generiche e specifiche)
di un prodotto che ne definiscono la capacità di soddisfare le esigenze esplicite o
implicite di un utilizzatore”.
Nella definizione data le «esigenze esplicite» sono esigenze esplicitamente
indicate dall’utilizzatore. (e.g. una persona ha bisogno di effettuare telefonate interurbane
e si abbona ad un servizio telefonico). Esigenze implicite sono invece esigenze imposte
dallo stato dell’utilizzatore o necessarie per il completamento di esigenze esplicite (e.g.
una persona con l’esigenza esplicita di abbonarsi ad un servizio TLC fare telefonate ha
anche l’esigenza implicita di avere a sua disposizione un telefono).
Tutto ciò equivale a dire che in un Ambiente Business un servizio TLC è «di
qualità» quando uguaglia o supera le aspettative dell’Utente che lo acquisisce. Le
305
aspettative dell’Utente sono influenzate da una serie di fattori come: bisogni,
informazioni ottenute da altri (« passa-parola ») e/o dal Fornitore di servizio, esperienze
precedenti, pubblicità etc. Tutto ciò è riassunto in un «modello della qualità di
servizio» sviluppato da Parasuraman, Zeithaml e Berry (modello PZB) mostrato in Fig.
2.6.3.1 (Vedi P.Kotler, “Marketing Management”, Prentice Hall, 2000, pag.439). Notare
come in un Ambiente Business la QoS e quindi la soddisfazione del cliente, siano sempre
strettamente legate alla correlazione fra percezione (“QoS percepita” dipendente da
fattori psicologici al momento dell’utilizzazione del servizio) e aspettativa (“QoS
attesa”) del servizio effettuata dal cliente. (freccia rossa verticale a due punte).
Nel modello PZB l’SP (Marketing & Sales) sviluppa il servizio basandosi sul
suo assesment (accertamento) delle aspettative del cliente, traducendolo poi in
“specifiche della Qualità di Servizio” (QoS), sottoforma di parametri di servizio o gruppi
di parametri di servizio da includere di volta in volta nei contratti SLA (Service Level
Agreement) stipulati con i singoli Utenti. Questi parametri di servizio vengono
sottoscritti dall’Utente al momento della Fornitura/Acquisizione del servizio TLC e i loro
valori fanno parte della QoS attesa dall’Utente.
Comunicazioni
passa-parola
Esperienze
precedenti
Bisogni
QoS attesa
(Aspettative)
QoS percepita
Cliente
SP (Marketing
&Sales)
Fornitura servizio
(compresi contatti pree post-vendita)
Comunicazioni esterne
con i Clienti (e.g pubblicità)
Traduzione dell’ assesment
in specifiche di QoS
Assesment delle aspettative
del Cliente da parte di SP
Fig. 2.6.3.1 Modello PZB della Qualità di Servizio
306
2.6.3.2
Aspetti soggettivi e oggettivi della qualità di un servizio TLC
Finora abbiamo parlato di QoS in generale e abbiamo detto che esso è legato alla
soddisfazione o insoddisfazione dell’Utente. Ma come esattamente si genera la
soddisfazione o insoddisfazione dell’Utente di un servizio TLC? O meglio, cosa è il
“livello di soddisfazione” dell’Utente e come è relazionato al QoS di un servizio TLC?
Il problema è molto complesso essenzialmente perché in esso si intrecciano
aspetti soggettivi più difficili da misurare e legati al comportamento/percezione di un
soggetto umano e aspetti oggettivi più facilmente misurabili. Il modo migliore di
procedere è di prendere in considerazione diversi tipi di QoS e di relezionarli poi l’un
l’altro.
Facciamo un esempio concreto riferendoci a un servizio di TV satellitare. Per
semplicità supponiamo che il fornitore dei servizi TV satellitari in effetti sia un fornitore
di un “prodotto” completo costituito da servizi TV e apparecchiature TV e.g. antenna
parabolica e decoders.
L’ Utente, durante la fase di utilizzazione dei servizi televisivi, percepisce come
elementi della QoS il livello di nitidezza, la qualità del colore e la stabilità delle
immagini che appaiono sul teleschermo, la fedeltà di riproduzione dei suoni trasmessi
dagli altoparlanti installati nel televisore, il sincronismo suoni-movimenti di immagine,
la durate dei tempi fuoriservizio (outages) subiti dalle trasmissioni televisive.
Ad esempio, se il movimento delle labbra dei personaggi sul teleschermo e le
parole da loro emesse non sono sincronizzati l’ utente percepisce una qualità di immagine
pessima ed è insoddisfatto. Ma questo non è tutto. Altri elementi della QoS sono percepiti
dall’Utente al di fuori della fase di utilizzazione del servizio TV e.g. la prontezza/
gentilezza/ competenza con cui gli addetti al servizio assistenza tecnica rispondono alle
sue richieste di informazione o intervengono per riparare guasti, la chiarezza/
accuratezza delle fatture mensili che gli vengono periodicamente inviate, etc. etc.
Il livello di nitidezza delle immagini, la fedeltà di riproduzione dei suoni e la
prontezza/accuratezza di risposta degli addetti all’assistenza tecnica sono esempi di
elementi che determinano la Qualità di Servizio nel seguente modo: gli elementi
vengono percepiti dall’ utente, paragonati alle aspettative che egli ha di essi e, come
risultato di questo paragone, determinano il soddisfacimento delle esigenze dell’
Utente. L’ Utente soddisfatto sancisce il servizio come servizio di buona qualità, l’
Utente insoddisfatto decide che il servizio fornito è di cattiva qualità e potrebbe cercare
altrove servizi più soddisfacenti.
Tuttavia si tratta di elementi di natura diversa. Infatti alcuni sono “network
related” e sono quantificabili e misurabili (e.g. la qualità o la stabilità delle immagini
televisive) mentre altri sono “non network related” e sono più difficili da quantificare
poiché dipendono dal comportamento di esseri umani (e.g. know-how e gentilezza degli
addetti al call center o fattori soggettivi nelle aspettative dell’utente). Molto spesso è
307
difficile separare gli elementi quantificabili e misurabili da quelli che non lo sono e che
dipendono dal comportamento/ percezione di esseri umani. Ad esempio la buona o
cattiva qualità di un call center dipende dalla buona o cattiva professionalità degli addetti
o dal buono o cattivo funzionanamento dei sistemi informatici di supporto?
Probabilmente da entrambi. Un addetto al call-center può essere piu’ o meno gentile a
seconda di vicissitudini personali difficilmente prevedibili e.g. esistenza di problemi
familiari.
PUNTO di VISTA BUSINESS
(AMBIENTE BUSINESS)
QoS
“Fornita”
VALORI di
RIFERIMENTO dei
PARAMETRI di SERVIZIO
dal SP
(pre-fornitura)
Non Network
Related
Network
Related
(Execution Gap)
QoS
“Erogata”
dal SP
SERVIZIO TLC
(Funzionalità U &S, G)
Tecnoservizi
(post-fornitura)
Valori MISURATI dei
PARAMETRI di SERVIZIO
mappatura
abilitato da
SISTEMA TLC
Non-ICT
VALORI PREDETTI
dei PARAMETRI
PRESTAZIONALI
(LoP)
ICT
PUNTO di VISTA
ENGINEERING
Ambiente Engineering
Fig. 2.7.3.2 Rilevante alla definizione di QoS quantificabile e misurabile
Il QoS atteso e il QoS percepito dall’Utente non sono rappresentati.
Il problema non è specifico dei servizi di telecomunicazione ma sorge ogni
qualvolta si cerca di definire e valutare la QoS di un qualsiasi servizio. Esistono intere
biblioteche che trattano l’argomento.
In accordo con ITU-T Recommendation I.350, 03/2003, in questo corso noi ci
limiteremo a considerare le caratteristiche oggettivamente misurabili (in maniera
308
quantitativa tramite valori numerici o qualitativa tramite i livelli di opportuni indicatori)
della QoS di un servizio TLC mentre ignoreremo tutte le caratteristiche dipendenti dalle
azioni e dalle opinioni soggettive degli Utenti che determinano la “QoS percepita” e
parte della “QoS attesa” dall’Utente
2.6.3.3
QoS fornita (specificata nel contratto SLA) e Qos erogata (misurata a
posteriori)
Supponiamo che le caratteristiche del QoS di un servizio TLC quantificabili e
misurabili nel Punto di Accesso al Servizio (Service Access Point, SAP) siano esprimibili
tramite indicatori misurabili chiamati “parametri di servizio”. I loro valori sono
prestabiliti e inclusi in un contratto formale stipulato fra SP e Utente denominato Service
Level Agreement, SLA. Esempi di parametri di servizio misurabili possono essere
1. Tempo massimo per identificare la causa di
un malfunzionamento riportato da un utente
2. Tempo massimo per riparare un malfunzionamento
3. Tempo massimo di fornitura di un nuovo servizio
4. Altri parametri prestazionali di rete (vedi par.2.6.2) specifici di un
certo servizio e.g. cell delay o jitter per servizi ATM, BER per servizi
tipo “leased line” etc.
5. Disponibilità del servizio (Service Availability)
Alcuni di questi sono “network related” altri dipendono dalla operatività del SP
e sono “non network related”. I parametri di servizio network related sono relezionati in
maniera più o meno complessa con i parametri prestazionali di rete (predetti). La ITU-T
ha raccomandato la matrice di Fig. 2.6.3.3 per facilitare la ricercadi parametri di servizio.
I valori (o gli intervalli di valori) dei parametri di servizio specificati in un contratto
SLA sono chiamati valori di riferimento e il loro insieme costituisce la QoS
pianificata/fornita (dalla TelCo). Essi sono anche definiti come i requisiti del servizio
e costituiscono ciò che l’ Utente leggittimamente si attende di ricevere dal SP e sono in
parte responsabili della costituzione delle aspettative dell’Utente (QoS attesa). (non
mostrata in Fig.2.6.3.2). Quindi, ripetiamo, l’insieme dei valori di riferimento
specificati nel contratto SLA definisce la QoS pianificata/fornita (Vedi Fig. 2.6.3.2).
Alcuni di questi parametri misurabili hanno una natura deterministica, altri una natura
statistica (e.g. disponibilità del servizio o massimo numero di minuti fuori-servizio in un
anno). D’altro canto la misura a posteriori dei valori dei parametri relativi ai servizi
effettivamente erogati produce un insieme di valori misurati dal SP che, per definizione,
costituisce la QoS “erogata” all’Utente.(Vedi Fig.2.6.3.2).
A questo punto abbiamo definito una QoS pianificata/fornita e una QoS erogata,
misurata a posteriori dal SP. Il divario fra le due viene identificato come “Execution
Gap”. E più in là non vogliamo spingerci per non sconfinare in campi lontani dalla GST.
. Tuttavia sappiamo che esiston altre due QoS: la QoS percepita e la QoS attesa
(completa) che non sono rappresentate in figura perché contengono elementi soggettivi
309
Criterio di Qualità
1. Velocità
2. Accuratezza
3. Disponibilità
4. Affidabilità
5. Sicurezza
6. Semplicità
7. Flessibilità
Funzioni TLC
1. Vendite & attività
pre-contratto
Gestione Servizio
2. Approvvigionamento
3. Alterazioni
4. Supporto
5. Riparazioni
Qualità
Connessione
6. Cessazione
ra
Pa
7. Instaurazione
Connessione
8. Trasferimento
Informazione
m
e
Q
di
i
tr
à
lit
a
u
X
9. Rilascio
Connessione
10. Fatturazione
11. Gestione rete/servizio
da parte del Cliente
Persona TLC
Fig.2.6.3.3 La matrice “Criterio di Qualità” – “Funzione TLC” per facilitare la definizione dei “Parametri
di Qualità” (ITU-T Report G.1000 11/2001) relativi a servizi TLC (“parametri di servizio”). La zona gialla
indicata qui come “Qualità Connessione” contiene le funzioni di “Utilizzazione e Segnalazione” svolte
nella fase da noi denominata di “Erogazione/Fruizione di un servizio TLC”. Tutte le altre funzioni sono di
natura gestionale e fanno parte della “service delivery”. La zona verde qui indicata come
“Approvvigionamento” contiene la funzione gestionale, da noi indicata come “Fornitura/Acquisizione di
servizio TLC”. In figura un servizio TLC è decomposto funzionalmente in un insieme coerente di 11
funzioni TLC e ad ogni funzione TLC corrisponde una specifica funzionalità TLC. (infatti il paradigma
Funzionalità-Funzione richiede che l’ effettivo svolgimento di una funzione sia la attuazione di una
corrispondente funzionalità posseduta a priori dall’attore). Ogni funzione TLC è un insieme coerente di
attività tese al raggiungimento di uno scopo comune (“scopo TLC”). Nella figura ogni funzione TLC è
identificata tramite il suo scopo TLC. Ad esempio, la funzione “Cessazione” va intesa come “un insieme
coerente di attività finalizzate ad effettuare la cessazione di un servizio TLC”, la funzione “Supporto” va
intesa come “un insieme coerente di attività finalizzate ad effettuare il supporto di un servizio TLC”
[“A.Oodan et al. “Telecommunications Quality of Service Management”, IEE Publications, 2003, p.54])
310
dipendenti dai comportamenti degli uttenti.. La QoS percepita è la QoS erogata dal SP
deformata da fattori temporalmente e geograficamente variabili legati alla persona
dell’utente: condizioni fisiche e psicologiche, esperienze passate, ambiente familiare e
sociale, impatto della pubblicità (giornali, televisione) sull’utente, sensibilità dell’utente a
influenze esterne etc. Il divario fra QoS percepita e QoS erogata si chiama
“Perception gap”. La QoS attesa è la QoS che l’Utente crea in se stesso prima della
fruizione del servizio ed è costituita dalla QoS fornita dal SP (sottoscritta dall’utente nel
SLA) con l’aggiunta di fattori soggettivi come esperienze pregressa, bisogni, pubblicità
etc.
Sappiamo inoltre che il QoS complessivo di un servizio TLC dipende dal “livello
di soddisfazione” dell’Utente e questo “livello di soddisfazione” è proprio il risultato del
paragone che egli effettua nel suo interno fra QoS percepita e QoS attesa.
In conclusione, il contratto SLA è un contratto con valore legale che specifica in
modo misurabile e contrattualmente vincolante i valori dei parametri di servizio
sottoscritti dall’ utente (che quindi riflettono parte delle sue aspettative, essendo le altre
componenti indicate in Fig.2.7.3.1). Se l’Utente ottiene la QoS attesa egli è in grado di
risolvere i suoi problemi (insorti in conseguenza di desideri/bisogni da soddisfare), e se il
paragone della QoS attesa con la QoS percepita è per lui soddisfacente la QoS del
servizio è da lui ritenuta ottima.
2.6.4 “Livello di Prestazione” (LoP) delle tecnologie ICT (Ambiente
“Engineering” )
Ciò che abbiamo sin qui descritto rappresenta la QoS di un servizio TLC come
definita dall’Utente in un Ambiente Business. D’altra parte la Qualità di Servizio così
definita dipende anche dalle caratteristiche di funzionamento (Livello di prestazione,
LoP) delle tecnologie ICT abilitanti evidenziate quando si guarda il funzionamento del
sistema TLC in un Ambiente Engineering
Come già detto, un sistema TLC contiene tecnologie ICT (e.g. reti e apparati
realizzati con tecnologie ICT) e componenti di supporto indicate come tecnologie non
ICT (uffici, impianti, energia, acqua etc.). Le tecnologie ICT sono suddivise in
tecnologie U&S gestite e tecnologie gestionali. Il funzionamento del complesso
“tecnologie U&S gestite + tecnologie gestionali” è caratterizzato da indicatori
quantificabili e misurabili, chiamati parametri prestazionali (e.g. la probabilità di errore
Bit Error Rate (BER) associata alla trasmissione TV, la larghezza di banda e il tempo di
ritardo dei canali utilizzati per trasmettere i segnali televisivi, la potenza dei TWTA
installata a bordo di un satellite televisivo etc.)
L’insieme dei parametri prestazionali normalizzati ai valori di specifica (fattori
prestazionali) relativi a una rete TLC (e.g. matrice 3x3 con 9 parametri, vedi ITU-T
Recommendation I.350, pag.7) definisce una Prestazione di Rete (Network
Performance) mentre l’insieme dei corrispondenti valori misurati definisce il Livello di
Prestazione (LoP, Level of Performance) della rete.
311
L’LoP della rete è supervisionato e controllato continuamente. I suoi valori
devono essere compatibili con i valori di riferimento dei parametri di servizio specificati
nel contratto SLA. Un buon servizio TLC è supportato da una buona rete TLC. Più
precisamente esiste una corrispondenza fra valori dei parametri prestazionali di rete
(LoP) e i parametri di servizio del servizio TLC abilitato da quella rete (QoS fornita/QoS
erogata). Questa corrispondenza è anche denominata “mappatura LoP-QoS” fra fattori
prestazionali e parametri di servizio. E’ proprio questa mappatura che rappresenta il
punto cruciale della gestione integrata reti-servizi.
In un sistema TLC ci sono anche elementi di supporto i.e. risorse non-ICT (e.g.
uffici, impianti, generatori di energia, etc) indispensabili al funzionamento del sistema
stesso. Le loro caratteristiche di funzionamento devono essere compatibili sia con i
valori dei parametri di servizio che con i valori dei parametri prestazionali delle
tecnologie ICT e la loro gestione avviene nell’ambito della gestione complessiva
d’impresa (Enterprise Management o Business Management). Queste risorse non sono
oggetto di studio in questo corso. Tuttavia è importante che gli Ingegneri TLC abbiano
consapevolezza della loro esistenza e della loro importanza.
2.6.5 La mappatura LoP-QoS
Finora abbiamo parlato di un Ambiente Business nell’ambito del quale abbiamo
descritto un servizio TLC fornito da una TelCo a Utenti finali , in termini di
1) QoS con alcune caratteristiche oggettive misurabili e altre più difficili da
quantificare (ma altrettanto importanti) legate al comportamento soggettivo sia
dell’utente che di altri partecipanti alla fornitura del servizio TLC e.g.
comportamento degli addetti a un call center,
2) “parametri di servizio” caratteristici della parte misurabile del QoS e misurati
nei Service Access Points
3) “valori di riferimento” dei parametri di servizio da inserire in un contratto
SLA stipulato fra Telco e Utente (QoS fornita) .
Poi abbiamo parlato di un Ambiente Engineering dove sono messe a fuoco le
tecnologie ICT abilitanti i servizi TLC e il loro funzionamento.
Le tecnologie ICT hanno un funzionamento caratterizzato da “fattori
prestazionali”(i.e. parametri prestazionali normalizzati ai valori di specifica). L’insieme
dei valori misurati dei fattori prestazionali costituisce un Livello di Prestazione (LoP)
delle tecnologie ICT. I fattori prestazionali di LoP, definiti/misurati in Ambiente
Engineering, sono strettamente relazionati ai parametri di servizio di QoS,
definiti/misurati in Ambiente Business, secondo una relazione denominata “Mappatura
LoP-QoS”
312
Ma negli Ambienti Engineering e Business coloro che definiscono/misurano LoP
e QoS spesso provengono da filono culturali completamente diversi. Basti pensare a
operatori di marketing (specializzati in relazioni con i clienti) e ingegneri TLC
specialisti in tecnologie ICT. Questi personaggi spesso usano linguaggi diversi e
posseggono mentalità diverse. Si crea così una discrasia semantica che può essere
superata solo attraverso un lavoro di integrazione e collaborazione fra professionisti con
culture diverse e.g. creando teams crossfunzionali. (Vedi: L.Lewis, “Service Level
Management for Enterprise Networks”, Artech House, 1999, pag. 190).
Nella “Mappatura LoP-QoS” esistono due casi limite: essa può effettuarsi
partendo dai parametri prestazionali (approccio engineering) o dai parametri di servizio
(approccio business). In un approccio engineering viene effettuata a priori la scelta dei
parametri prestazionali e dei loro valori e si accettano i valori dei parametri di servizio
che ne derivano e la mappatura è del tipo molti-a-uno, cioè i valori misurati di una
molteplicità di parametri prestazionali di rete danno luogo ad un singolo valore di un
determinato parametro di servizio. In un approccio business è vero il contrario. In pratica
è molto probabile che ci si trovi ad operare in un contesto “customer centric” nel quale i
parametri di servizio e i loro valori sono fissati a priori, poi vengono fissate le tecnologie
ICT abilitanti e infine vengano specificat i parametri prestazionali.
2.6.6
Pubblicazioni ITU-T relative alla mappatura LoP-QoS
Per quanto riguarda la relazione fra Prestazione di rete (Network Performance,
NP) e la parte misurabile della Qualità di Servizio (Quality of Service, QoS), la ITU ha
affrontato il problema in due raccomandazioni (scaricabili dal sito «ITU»),
1)
ITU-T Recommendation I.350, General aspects of quality of service
and network performance in digital networks, 03/1993
2)
ITU-T Recommendation X.641, Quality of service framework, 1997
Vedere anche: Antony Oodan et al. “Telecommunications Quality of Service
Management”, IEE (UK), 2003.
313
Appendice 1 al Capitolo 2
Modello Generico di Rete (Generic Network Model,
GNM) di Chen & Kong
A.1.1
Creazione del modello generico di rete “Super-rete”
In letteratura esistono diversi modelli di rete tecnologicamente neutri (modelli
generici) sviluppati per diversi scopi: vedi gli standards de jure descritti nei rispettivi
documenti/raccomandazioni: ITU-T M.3100 e G.805, ATMF M4, ETSI 300 653 etc. o il
modello proprietario GNM (Generic Network Model) sviluppato da G.Chen e Q.Kong
nel Cap.1 (p.159) del testo già citato. In generale un modello (rappresentazione astratta)
di un oggetto reale, tangibile o intangibile, per essere veramente utile e popolare e non
essere dimenticato in un cassetto deve contenere informazioni rilevanti all’uso che i
suoi utilizzatori prevedono di farne, adottare un linguaggio comprensibile agli
utilizzatori ed essere sufficientemente semplice da non richiedere troppo tempo e denaro
in fase di utilizzazione. Nel nostro caso noi vogliamo sviluppare un modello di rete TLC
da utilizzare per due scopi specifici:
1) costituire un modello astratto tecnologicamente neutro (i.e. indipendente dalle
tecnologie implementative della rete) per permettere ad un unico gestore di
gestire reti tecnologicamente eterogenee costituite da sottoreti realizzate con
diverse tecnologie. Questo tipo di gestione si chiama “integrated cross-domain
network management”, laddove il termine “domain” si riferisce ad un dominio
tecnologico
2) creare un modello che offra una base per l’integrazione gestione reti-gestione
servizi (e.g. utilizzando una tecnologia DOC, Distributed Object Computing
tipo CORBA, Common Object Request Broker Architecture, mappatura fra
oggetti gestione rete e oggetti gestione servizi)
Consideramo una grande rete TLC reale (denominata “Rete”) realizzata come
interconnessione di una molteplicità eterogenea di sotto-reti. Ogni sotto-rete è
tecnologicamente omogenea cioè realizzata con un' unica tecnologia implementativa
(“rete specifica”) ed ha un insieme di nodi di accesso chiamati terminazioni. Parte delle
terminazioni di una sotto-rete sono “visibili” dall’esterno della Rete. Le terminazioni
“visibili” sono denominate “terminazioni esterne”. Questo significa che le terminazioni
esterne sono i soli punti di accesso che un utilizzatore della Rete può utilizzare (Network
Access Points, NAP’s). Supponiamo che la Rete offra tecnoservizi di interconnessione
fra terminali ad essa connessi nei NAP. Allora le teminazioni esterne NAP sono anche i
Service Access Points (SAP) ai tecnoservizi di interconnessione offerti dalla Rete.
314
MODELLO GNM
T1
Rete Astratta
Generica
(Tecnologicamente
neutra)
Supernet
T2
T7
T3
SPECIALIZZAZIONE
ASTRAZIONE
N5
Rete Reale
Specifica
(Tecnologia XYZ)
N1 N4
N7
N2
N3
N6
MODELLO RETE SPECIFICO
Fig.A.1.1 Rappresentazione astratta di una rete reale a sette nodi e quattro
terminazioni esterne, realizzata con tecnologia XYZ, generalizzata in una Supernet
astratta tecnologicamente neutra con quattro terminazioni. Le linee tratteggiate
rappresentano trasferimento alla Supernet di un certo numero di caratteristiche
generiche (tecnology-neutral) possedute dalle terminazioni esterne N1, N2, N3, N7
(processo di astrazione).
315
La rete A è realizzata con una
tecnologia specifica XYZ e gestita
da un gestore A che adotta il
modello OSI-SM. La Supernet è
una rete astratta, “oggetto” di un
modello GNM sul quale si possono
effettuare certe operazioni. Una
richiesta di creazione della
connessione T2-T7 nella Supernet
viene mappata in un insieme di
richieste CMIP (secondo regole di
specializzazione) per le
connessioni N2-N4, N4-N5, N5N7. Viceversa un guasto nella
connessione N4-N5 influenza i
servizi sulle connessioni T2-T7 e
T1-T7 nella Supernet (secondo
regole di astrazione).
Tutte le reti di cui abbiamo parlato sinora sono reti reali. Adesso vogliamo creare un
modello astratto tecnologicamente neutro della Rete reale (denominato “Modello
Generico di Rete”, MGR, in inglese Generic Network Model, NGM) e lo chiamiamo
“Super-rete”. Quindi la Super-rete è un MGR di una Rete reale costituita da un ordito di
sotto-reti reali (talvolta in forma abbreviata si dice anche che è una “rete generica”). Per
creare un MGR supponiamo di applicare il criterio di modellazione “bottom-up” descritto
nel Capitolo 1. All’uopo, certe caratteristiche delle terminazioni esterne ritenute
importanti agli occhi del gestore servizi e condivise da tutte le sotto-reti sono trasferite
(mappate direttamente) nelle caratteristiche delle terminazioni della Super-rete (processo
di astrazione denominato “mappatura sotto-rete : super–rete”). Una mappatura sottorete/super-rete nasconde (o effettua l’incapsulamento di ) tutti i dettagli specifici della
tecnologia implementativa di sotto-rete. I tecnoservizi di interconnessione offerti dalla
Super-rete sono una astrazione dei tecnoservizi di interconnessione offerti dalla Rete
reale: i primi ritengono solo le caratteristiche “service-relevant” dei secondi. I
tecnoservizi offerti dalla Super-rete possono essere rappresentati tramite “oggetti
CORBA” (i.e. “oggetti” descritti con linguaggio descrittico IDL di una architettura
CORBA) mentre i vari tecnoservizi offerti dalle sotto-reti possono essere rappresentati
tranite “oggetti OSI-SM” (i.e. “oggetti” descritti col linguaggio GDMO/ASN.1, vedi
Parte II del corso).
A.1.2
La vista esterna tecnologicamente neutra di una Super-rete
La Fig. A.1.1 mostra tre sotto-reti reali A, B e C tecnologicamente diverse
interconnesse da due links (collegamenti fra sotto-reti). Le loro terminazioni esterne
possano essere mappate nelle terminazioni di una Super-rete tecnologicamente neutra. L’
insieme delle terminazioni di una Super-rete ne costituisce la “vista esterna” messa a
disposizione dei suoi utilizzatori (gestori servizi). Una Super-rete ha una “vista esterna”
disponibile ai suoi utilizzatori costituita da tutte le terminazioni che sono state mappate
dalle terminazioni esterne delle sotto-reti contenute al suo interno assieme ad una “vista
interna” che specifica le sotto-reti tramite modelli di gestione rete tecnologicamente
specifici e i links che le interconnettono e la topologia dei links. In figura si vede anche
come alcune terminazioni di sotto-rete non vengano mappate nella super-rete ma siano
invece utilizzate nei “links” fra sotto-reti.
A.1.3
I sottomodelli del Modello GNM
Il modello GNM si articola in due “sottomodelli a oggetti”: un modello
topologico (statico) e un modello connettivo (dinamico).
Sottomodello topologico (Oggetti topologici e operazioni su di essi).
Il modello GNM topologico è descritto in termini di oggetti (topologici),
operazioni che essi supportano e regole di comportamento. Questi oggetti rappresentano
le carattertistiche statiche di una rete e modellizzano gli elementi che costituiscono la
topologia di una Super-rete: 1) reti, 2) terminazioni (punti di accesso a una rete), 3)
links (interconnessioni fra reti).
316
Esiste una relazione fra gli oggetti “reti”, “terminazioni” e “links” (Vedi Fig.
A.1.2) e una relazione gerarchica di contenimento fra gli oggetti rete (Vedi Fig.A.1.3)
i.e. reti più grosse contengono reti più piccole (sotto-reti). In Fig. A.1.3 le tre reti
atomiche (i.e. senza sottoreti) No. 2, 4 e 5 sono contenute nella rete No.1. Abbiamo visto
che le terminazioni in una Super-rete sono una mappatura diretta delle terminazioni
esterne delle sotto-reti. Ad esempio la rete No.1 “vede” (attraverso un processo di
mappatura diretta) le terminazioni esterne T21, T22 e T23 della sotto-rete No.2. Esempi
di operazioni sugli oggetti “Network” sono: “create network”, “delete network”
Sottomodello connettivo (Oggetti connettivi e operazioni su di essi).
Gli oggetti connettivi sono “connection objects” e “connectionLink objects”. Un
“connection object” (anche “connection service object”) è la rappresentazione di un
canale di comunicazione che trasporta informazione in modo trasparente fra certe
terminazioni di Super-rete (siamo nel MGR) ed è creato per realizzare una connessione
end-to-end in rete in risposta ad una richiesta di servizio di interconnessione da parte di
un Cliente. Questi oggetti sono rappresentativi degli aspetti dinamici della rete
(cambiamenti molto più rapidi dei cambiamenti di topologia) cioé rappresentano
connessioni che possono attivarsi/disattivarsi in modo rapido (“Connection service
objects”). Oltre che per le loro caratteristiche dinamiche, gli oggetti connettivi
differiscono dagli oggetti topologici per il fatto che, benché oggetti di rete, essi
portano con sé informazione rilevante ai servizi e.g. specifiche dei parametri
rappresentativi del canale di comunicazione abilitante i servizi richiesti. E’ questa una
caratteristica del modello GNM previsto specificatamente per l’integrazione gestione
servizi-gestione reti. Ad esempio le loro specifiche contengono parametri prestazionali
relativi a
protocolli di comunicazione (ATM, Frame Relay, ADSL. SDH etc.),
larghezza di banda, LoP (Level of Performance),
tipo di connessione: unidirezionele, bidirezionale, simmetrica, asimmetrica.
Le relazioni fra oggetti connettivi e topologici sono mostrate in Fig. A.1.3. Le
operazioni sono del tipo “create connection”, “add/delete connection”, etc. Il modello
connettivo inoltre contiene un insieme di regole che specificano il comportamento degli
oggetti cioé la semantica degli oggetti . Si tratta del comportamento di un oggetto
rispetto al comportamento di un altro oggetto cioé delle relazioni fra oggetti. Ad esempio
regole che individuano le relazioni di contenimento fra sotto-reti oppure che specificano
le relazioni fra oggetti topologici e connettivi.
317
A.1.4 Relazione fra oggetti GNM (Generic Network Model) e oggetti SIM (Service
Interaction Model)
Al gestore “servizi TLC” (Service Provider, SP) non interessa affatto conoscere i
dettagli della gestione “reti TLC” (effettuata da un Network Operator, NO). E questo è
vero fintantochè l’SP ottiene le informazioni di cui ha bisogno per gestire i servizi e,
viceversa, le sue richieste sono esaudite dal NO. Supponiamo ora che SP adotti un
modello gestione servizi denominato Service Interaction Model (SIM) e NO adotti un
modello gestione reti tecnologicamente neutro denominato Generic Network Model
(GNM) ma, modello che egli può specializzare in una serie di modelli gestionali
tecnologicamente specifici adatti a gestire i singoli elementi delle reti specifiche
contenute in un sistema TLC. Allora possiamo dire che a livello informatico, le
informazioni gestionali di rete di cui SP ha bisogno sono contenute negli oggetti GNM e
le richieste di SP a NO sono trasferite via relazioni oggetti SIM-oggetti GNM (e.g.
Relationship service di CORBA).
318
Rete No.1
T11
T12
T22
T24
T21
Rete No.2
T31
Rete No.3
Link
T23
T13
T16
T34
T32
T15
T33
T14
Rete No. 3
T42
T34
MODELLO GNM
T41
T51
Rete No.5
Rete No.4
T54
T31
T52
T32
T53
T33
T21
T24
T22
Rete No.2
T42
Rete No.4
T23
MODELLI
RETE
SPECIFICI
T51
T41
Rete A
Tecnologia A
Rete B
Tecnologia B
T53
Rete C
Tecnologia C
Fig. A.1.2 Rappresentazione di tre reti specifiche in una super-rete tecnologicamente neutra.
319
T52
Rete No.5
T54
based on
contains
contains
Connection
based on
contains
between
Link-connection
Network
links
between
Termination
over
Oggetti connettivi
contains
Oggetti topologici
Fig. A.1.3 Tipologia di oggetti nel modello GNM
320
Link
Rete No.1
T11
T12
T16
T24
T21
T22
Rete No.2
T32
T15
T33
T14
contiene
contiene
T21
Rete No. 3 T51 T31
T42
Rete No.5 T52
T41 Rete No.4
T32
T54
T53
T33
T24 T34
T22
T31
Rete No.3
Link
T23
T13
T34
Rete No.2
Link
T23
contiene
Rete No.1 = Rete No.2 + Rete No.3
contiene
T51
T42
T41
Rete No.4
Rete No.5
T54
Rete No.3 = Rete No.4 + Rete No.5
Fig.A.1.4 Esempio di struttura gerarchica (contenimento) di reti secondo il modello GNM.
321
T52
T53
OGGETTI CORBA IDL (CORBA Server)
Mappatura
GNM-SIM
Modello
Rete
Generico
(GNM)
(oggetti
rete generici)
(oggetti servizi)
ASTRAZIONE
Modello
Interattivo
Servizi
(SIM)
Modello Rete Generico
(REGOLE DI
ASTRAZIONE)
ATM
SDH
Modelli
Rete
Specifici
ATM
ADSL
SDH
ADSL
OGGETTI OSI GDMO
Modelli Rete Specifici
Terminazione
Connessione
Link
Fig. A.1.5 La “mappatura sotto-rete/super-rete” crea oggetti GNM che si relazionanano con oggetti SIM attraverso una infrastruttura CORBA
322
CAPITOLO 3
Standards gestionali ITU-T: introduzione
(4h)
3.1
Introduzione
3.2
Gli standards gestionali: generalità
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.2.7
3.2.8
3.2.9
Procedure gestionali, processi gestionali e automazione
Tecnologie proprietarie e interoperabilità
Standards e tipologie di standards
Standards gestionali «de jure» e modelli gestionali.
Normativa «minimalista» tecnologicamente neutra per salvaguardare l’innovazione
tecnologica e la competitività fra industrie manifatturiere.
Condizioni aggiuntive (oltre la verifica di conformità) per garantire una buona
interoperabilità fra sistemi eterogenei.
Gli standards nel dominio del tempo
Introduzione di standard in assenza o presenza di sistemi legacy.
Enti di standardizzazione
3.3
Paradigma “Gestore-Agente” nello standard OSI-SM dell’ITU-T:
architetture manuali e automatizzate
3.4
Il modello “TMN stratificato” dell’ ITU-T
3.5
Il modello funzionale FCAPS dell’ITU-T
323
CAPITOLO 3
Standards gestionali ITU-T: introduzione
3.1 Introduzione
Abbiamo già indicato in precedenza come un sistema TLC reale allorchè
osservato da un Punto di Vista Engineering appaia come un ordito di Tecnologie ICT da
noi classificate in “tecnologie U&S gestite” e.g. switch, router, multiplexer, mezzi di
trasmissione elettromagnetica etc. e “tecnologie gestionali” e.g. OS, NSS, OSS, BSS.
Negli anni 60 queste tecnologie erano di natura proprietaria, prodotte da una
moltitudine di imprese ICTS. Proprio perché i vari vendors vendevano tecnologie
proprietarie eterogenee, l’operazione congiunta di tecnologie provenienti da vendors
diversi sin dall’inizio divenne problematica i.e. mostrò problemi di interoperabilità
eterogenea.
Nel tentativo di risolvere questi problemi vari enti nazionali e internazionali
intrapresero iniziative di standardizzazione dei processi gestionali e delle relative
tecnologie abilitanti ed emanarono una varietà standards gestionali. In questo capitolo ci
occuperemo dei primi standards gestionali de jure sviluppati dall’ITU-T (anni-80/90).
L’ITU-T è uno degli enti di standardizzazione più importanti nel settore GST
3.2 Gli standards gestionali: generalità
3.2.1
Procedure gestionali, processi gestionali e automazione
All’inizio degli anni settanta la gestione dei sistemi TLC consisteva in una gestione
servizi, reti e elementi di rete, con una forte componente manuale (i.e. intervento diretto
di “addetti alla gestione” sulle apparecchiature da gestire) secondo “procedure gestionali”
prestabilite. Come indicato nel Capitolo 1, gradualmente nel tempo le TelCo hanno
trasformato le “procedure gestionali” in “processi di business gestionali”.
Susseguentemente si è verificata una automazione (sostituizione del personale addetto
alla gestione con tecnologie gestionali) e integrazione di questi processi in modo da
rendere i servizi TLC forniti più efficienti/efficaci (i.e. con costi di esercizio più bassi,
tempi più brevi e migliore QoS per gli utenti finali). L’automazione/integrazione ha
comportato una digitalizzazione e messa in rete dei processi di gestione creando così
una “gestione distribuita”. La gestione distribuita ha richiesto l’impiego congiunto di
tecnologie informatiche IT (Information Tecnologies) e tecnologie di telecomunicazione
TLC e, più tardi, l’uso di tecnologie integrate ICT, Information - Communication
Technologies.
324
3.2.2
Tecnologie proprietarie e interoperabilità
Inizialmente le tecnologie gestionali erano tecnologie gestionali proprietarie
definite come segue:
DEFINIZIONE di «TECNOLOGIA PROPRIETARIA»: “Tecnologie
proprietarie” sono tecnologie realizzate indipendentemente da varie industrie
manifatturiere con criteri progettuali /realizzativi propri, su richieste specifiche di
varii enti e.g. integratori / operatori di sistema, fornitori di servizi, etc.
La crescente utilizzazione di una molteplicità di diverse tecniche/tecnologie
gestionali proprietarie (etereogeneità di tecniche/tecnologie gestionali) ha reso difficile
la loro interoperatività cioe’ ha generato problemi di interoperabilità . Basti pensare
alla difficoltà di far interagire una tecnologia proprietaria «gestore» realizzata da un
certo costruttore con tecnologie proprietarie «agente» realizzate da costruttori diversi.
In tempi piu’ recenti i problemi di interoperabilità fra tecnologie eterogenee
(interoperabilità eterogenea) sono diventati particolarmente acuti a causa di processi di
globalizzazione, deregolamentazione e “merging” industriale che hanno coinvolto una
varietà di fornitori di servizi e operatori di reti con conseguente utilizzazione di
tecnologie (hardware e software) diverse.
3.2.3
Standards e tipologie di standards
Quindi, all’inizio anni ottanta, i problemi principali che si sono dovuti risolvere
nell’ambito della gestione dei sistemi TLC sono stati problemi di interoperabilita’
eterogenea. La soluzione di questi problemi ha reso necessario lo sviluppo e l’uso di
standards.
DEFINIZIONE di « STANDARD »: Uno standard è un insieme di specifiche
accettato/adottato da una vasta comunità di utilizzatori (e.g. costruttori di apparati,
fornitori di servizi, operatori di sistema etc.) e/o promulgato da un ente di
standardizzazione nazionale o internazionale.
Nel caso in cui le specifiche siano relative ai servizi di gestione offerti dalle
risorse di gestione e.g. sistemi di supporto (Tecnoservizi di gestione) l’insieme delle
specifiche deve essere soddisfatto in toto dalla risorsa perche’ quest’ultima possa essere
dichiarata standardizzata.
Le specifiche costitutive di uno standard hanno un carattere normativo cioè sono
norme in conformità delle quali un sistema gestionale standardizzato deve funzionare.
Un sistema standardizzato il cui funzionamento avviene in conformita’ con uno standard
XYZ si dice anche «sistema a norma XYZ».
Uno standard gestionale è uno standard che deve essere rispettato dalle
prestazioni di un sistema gestionale standardizzato (e.g. OS, NSS). Ad esempio
325
parleremo di «standard gestionale OSI-SM» in conformita’ del quale un «sistema di
gestione OSI-SM» deve funzionare per implementare una «gestione OSI-SM».
In questo corso tratteremo di tre tipologie di standards:
1. standards “de jure” costituiti da una collezione di specifiche promulgate da enti
internazionali/nazionali di standardizzazione creati da governi nazionali, se
necessario, con accordi internazionali. Una volta emessi, questi standards possono poi
godere di vasta o scarsa popolarità fra i potenziali utilizzatori e,g.
operatori/costruttori/integratori di reti, fornitori di servizi etc. Fra poco vedremo che
standards «de jure» si basano su modelli (intesi come collezioni di specifiche per la
progettazione/realizzazione di un sistema futuro) sviluppati da Working Groups
all’interno degli enti di standardizzazione.
2. standards “de facto” costituiti da specifiche relative a tecnologie proprietarie
ad altissima diffusione sviluppate da imprese che controllano grosse fette di mercato.
(e.g. il sistema operativo WINDOWS NT sviluppato dalla MICROSOFT). Quindi questa
tipologia di standards, al contrario della precedente, si basa proprio sull’esistenza di una
tecnologia proprietaria adottata, sua sponte, da una vasta comunità di utilizzatori (e non
sullo sviluppo di un modello da parte di un ente di standardizzazione).
3. «specifiche tecniche pubbliche» sono raccomandazioni preparate e distribuite da
organizzazioni nazionali/internazionali (del tipo «consorzio industriale» o «industrial
forum») create «ad hoc» per difendere gli interessi commerciali di comunità di
costruttori di tecnologie (industrie manifatturiere), operatori di sistema, fornitori di
servizi. I membri del «forum» cooperano per creare, in tempi brevi o, almeno, in tempi
piu’ brevi di quelli impiegati per emettere uno standard «de jure», tecnologie comuni
capaci di interoperare. Quello che non può fare il singolo privato o la burocrazia di un
ente di standardizzazione può essere fatto da un gruppo di privati! Questi «forum» non
operano a scopo di lucro cioè sono organizzazioni «non-profit». In generale le
raccomandazioni prodotte sono adottate da tutti i membri dell’organizzazione e, se i
membri sono numerosi, queste raccomandazioni divengono popolari e….. «de facto»
standards!
L’organizzazione Tele-Management Forum (TMF), i cui modelli gestionali
verranno studiati nel Capitolo 4, è un esempio di foro industriale nato per lo sviluppo di
prodotti gestionali altamente automatizzati e interoperabili. Un altro esempio di foro
industriale, con il mandato di facilitare lo sviluppo di software gestionale rete/servizi per
telecomunicazioni multimediali, è stato il TINA-C (Telecommunication Information
Networking Architecture – Consortium).
Altri esempi di specifiche tecniche pubbliche (utilizzate nel par.1.3 per i sistemi
gestionali fortemente distribuiti) sono le specifiche tecniche del middleware CORBA,
(Common Object Request Broker Architecture) emesse dal foro industriale OMG,
Object Management Group negli USA e le specifiche del middleware DCE (Distributed
326
Computin Environment) emesse dal gruppo Open Group, nato dalla unione, avvenuta
nel 1996, dei gruppi Open Software Foundation (OSF) e X/Open
In conclusione, le «specifiche tecniche pubbliche» possono riguardarsi come una
quasi-normativa sufficientemente generica da accomodare le tecnologie proprietarie dei
membri dell’organizzazione, intermedia fra « standards de-jure » e « standards de-facto ».
In base a quanto detto si puo’ facilmente capire come talvolta queste specifiche tecniche
pubbliche possano essere concorrenziali con gli altri due tipi di standards dando luogo a
quella che talvolta viene chiamata la «guerra degli standards».
3.2.4
Standards gestionali «de jure» e modelli gestionali.
In questo corso ci occuperemo principalmente di standards gestionali «de jure»
sviluppati da enti di standardizzazione e/o specifiche tecniche pubbliche. Ma quale è la
relazione fra un modello gestionale e uno standard gestionale «de jure»?
Un sistema di gestione di un sistema TLC si dichiara standardizzato (o « a norma
XXX ») dopo verifica che esso soddisfi le specifiche contenute nello standard XXX
emesso da un ente di standardizzazione In generale, un insieme di specifiche tecniche di
un sistema da progettare viene definito uno «standard» quando le specifiche sono
sviluppate e pubblicate da un ente di standardizzazione con procedure formali accettate
su base internazionale (o nazionale se l’ente è un ente di standardizzazine nazionale). In
questo caso il modello standardizzato riflette i punti di vista (e quindi gli interessi!) dei
membri dell’ente di standardizzazione e.g. industrie manifatturiere (hardware e software),
fornitori di servizi, operatori di sistema etc. Ogni membro ha suoi rappresentanti
tecnici/legali/commerciali in seno all’ente di standardizzazione, i quali partecipano ai
Gruppi di Lavoro dedicati alla definizione delle specifiche costitutive di uno standard.
Ad esempio lo standard TMN (Telecomunication Management Network) dell’ISO/ITUT, che verrà studiato in questo corso, è una collezione di specifiche che riflette gli
interessi dei membri dell’ISO/ITU-T.
3.2.5
Normativa «minimalista» tecnologicamente neutra per salvaguardare
l’innovazione tecnologica e la competitività fra industrie manifatturiere.
Ma come hanno potuto i vari standards risolvere i problemi di interoperatività
fra tecnologie eterogenee? In generale si può dire che, «in linea di principio»,
componenti eterogenei (i.e. apparecchiature realizzate con tecnologie diverse)
possono interoperare se costruiti in conformità allo stesso standard.
Questa affermazione è comprensibile se si pensa a sistemi gestionali che utilizzano le
stesse strutture di dati, la stessa semantica e usano gli stessi protocolli comunicativi in
accordo con le norme contenute in uno stesso standard. Ovviamente questi sistemi
possono mutuamente cooperare.
Tuttavia ci vuole cautela. La implementazione di uno standard da parte di una
comunita’ di utilizzatori (e.g. industrie manifatturiere) non va interpretata nel senso che
327
gli standards stabiliscano regolamentazioni stringenti al di fuori delle quali gli utilizzatori
non possono avventurarsi. Se ciò si verificasse sarebbe la fine di ogni iniziativa
proprietaria, il soffocamento della competizione a causa della distruzione dei
differenziatori competitivi (i.e. «se tutti fanno la stessa cosa non possono più
competere »! ) e, in definitiva la morte della creatività’ e dell’innovazione tecnologica.
In effetti, vedremo che molte, e forse le più popolari, normative de-jure per sistemi
TLC emesse da organismi internazionali di standardizzazione sono normative
«minimaliste» tecnologicamente neutre nel senso che definiscono il minimo numero
di norme che devono essere soddisfatte per garantire che
cooperazione o
interoperabilita’ fra tecnologie eterogenee avvengano in modo efficace ed efficiente,
senza peraltro soffocare la creatività e l’innovazione tecnologica. In queste circostanze
chi adotta uno standard rimane libero di utilizzare la sua innovazione tecnologica per
sviluppare differenziatori competititivi che gli permettano di vincere la concorrenza.
Ad esempio, nel caso di interoperabilità eterogenea, è bene che un sistema gestionale
standardizzato soddisfi una «verifica di conformità» in opportuni punti di interfaccia
fra i componenti del sistema, lasciando al gestore la libertà di scegliere le tecnologie
implementative dei componenti stessi. In questo senso la standardizzazione si può dire
«minimalista». Una standardizzazione non «minimalista» del sistema di gestione presenta
il rischio di eliminare i differenziatori competitivi e creare una situazione di «commodity
market» cioè un mercato in cui i servizi TLC o le tecnologie ICT abilitanti
diventerebbero prodotti difficilmente differenziabili, immessi sul mercato da una vasta
molteplicità di fornitori a un prezzo sostanzilmente controllato dal mercato stesso (cioè
indipendenti dal «marchio» distintivo del singolo fornitore). Tutto ciò, probabilmente,
sarebbe poco gradito dai fornitori di servizi o operatori di rete
Quindi nei processi di standardizzazione è importante trovare il giusto equilibrio fra
due esigenze opposte: la normativa deve essere sufficientemente stringente da garantire
interoperabilità ma, allo stesso tempo, essere sufficientemente lasca da non eliminare i
differenziatori competitivi sviluppati dalle singole imprese. Mettere in pratica tutto
questo è compito dei Gruppi di Lavoro degli enti di standardizzazione, preposti allo
sviluppo degli standards.
3.2.6
Condizioni aggiuntive (oltre la verifica di conformità) per garantire una
buona interoperabilità fra sistemi eterogenei.
A questo punto è chiaro che, sebbene uno standard de-jure imponga il
soddisfacimento di specifiche ben precise, esiste pur sempre il pericolo che diversi
produttori di componenti di sistemi gestionali possano, nell’ambito di uno stesso
standard, usare soluzioni tecnologiche (hardware o software) proprietarie le quali
risultano poi solo parzialmente compatibili (e.g. due tecnologie standardizzate secondo
lo stesso standard ma provenienti da due costruttori diversi interoperano ma interoperano
male!). Quindi, per avere una maggiore sicurezza circa una buona interoperabilità di
tecnologie gestionali eterogenee, è opportuno
328
1) se si deve assemblare un sistema gestionale assicurarsi che i componenti del
sistema (e.g. sistemi di esercizio, postazioni di lavoro, equipaggiamento gestionale di
vario tipo) siano non solo “a norma” ma soddisfino condizioni aggiuntive e.g. dettate da
accordi bilaterali fra i produttori dei componenti stessi
2) effettuare il testing dei componenti in laboratori attrezzati, prima dell’
assemblaggio e messa in opera dei componenti stessi.
Ovviamente il soddisfacimento del primo requisito (stipula di accodi bilaterali al di là
della normativa di standardizzazione) apre la porta alla possibilità che le condizioni
effettive e finali soddisfatte dal sistemagestionmale, cosidetto a norma XYZ,
appartengano non solo allo standard de-jure XYZ ma in parte anche ad uno standard defacto imposto nel corso degli accordi bilaterali da grossi produttori con posizioni di
preminenza (posizioni dominanti) nel mercato.
3.2.7 Gli standards nel dominio del tempo
Uno dei problemi più grossi da affrontare quando si adotta uno standard è la sua
validità/utilità nel tempo. Infatti, da una parte, gli standard non devono essere
immutabili nel tempo cioè non devono congelare le tecnologie ICT standardizzate per
tempi molto lunghi rendendole così incapaci di rispondere a nuove esigenze di mercato,
d’altra parte non devono variare molto rapidamente rendendo obsolete in tempi
inaccettabilmente brevi le soluzioni adottate.
In effetti, la formulazione degli standard deve essere effettuata in modo tale da
renderli modificabili al passo con l’evoluzione delle richieste di mercato e/o lo
sviluppo tecnologico. Tuttavia queste modifiche devono potersi effettuare senza
cambiamenti drastici di tutta la struttura dello standard cioè devono comportare
modifiche limitate ad alcune sue parti (« refinements », in inglese) e non coinvolgere una
drastica ristrutturazione dello standard nel suo insieme. Per questo un buon standard
deve essere ri-usabile (almeno in parte) e estendibile. Ad esempio uno standard con
struttura modulare permette la modifica di una parte lasciando inalterato il resto o
l’estensione dello standard stesso senza necessità di effettuare grossi cambiamenti.
Vedremo che il soddisfacimento di queste esigenze si sposa bene con l’uso di modelli
gestionali basati sull’ «orientamento agli oggetti».
Abbiamo detto che, idealmente, uno standard dovrebbe essere modificabile di pari
passo con l’evoluzione dei mercati e delle tecnologie. Purtroppo ciò è difficile da
ottenersi. Infatti tipicamente le procedure di standardizzazione «de jure» sono molto
elaborate e quindi molto lente. Questa è una delle principali ragioni per cui talvolta gli
standards «de jure» non sono molto popolari e sono soppiantati da standard «de facto»
promossi in modo aggressivo da grossi gruppi industriali.
329
3.2.8
Introduzione di standard in assenza o presenza di sistemi legacy.
La adozione di standards in sistemi gestionali presenta problematiche diverse a
seconda se esiste o meno un sistema pre-esistente di prima generazione (sistema
«legacy»).
Nel caso di progettazione ex novo di nuovi sistemi gestionali senza riutilizzazione di
tecnologie di prima generazione pre-esistenti (tecnologie legacy), assumendo che
l’impresa in questione non abbia essa stessa le dimensioni sufficienti per imporre al
mercato uno standard de facto, il problema non é l’introduzione di uno standard ma é
l’adozione di quale standard. Infatti, negli ultimi vent’anni sono stati sviluppati
standards diversi per la gestione di uno stesso sistema TLC. Standard diversi sono
sviluppati da enti di standardizzazione diversi (e.g. enti nazionali o internazionali) e/o
consorzi industriali supportati da potenti gruppi industriali interessati alla diffusione delle
proprie tecnologie proprietarie (Vedi “specifiche tecniche pubbliche” in 4.1.1).
Quindi adottare uno standard in effetti significa scegliere uno standard in una
molteplicità di standard disponibili e questo non é cosa semplice: come minimo si deve
valutare attentamente quale é la probabilità che lo standard prescelto è stato o sarà
adottato su larga scala (cioè se risulterà vincente o, perlomeno, contenuto nella rosa dei
vincitori nella cosidetta « guerra degli standard ») e quale é la durata del suo probabile
ciclo di vita (i.e. dalla sua nascita alla sua morte, quando viene rimpiazzato da uno
standard più moderno). Entrambe valutazioni di difficile effettuazione.
Nel caso di introduzione di uno standard in presenza di tecnologie legacy pre-esistenti
esistono difficoltà aggiuntive. Queste difficoltà sono dovute alla necessità non solo di
parzialmente rimpiazzare ma anche integrare (o perlomeno adattare) le nuove
tecnologie standardizzate con le vecchie tecnologie proprietarie o normate secondo
standard obsoleti. Quindi, in questo caso, la scelta di uno standard è anche influenzata
dal tipo di tecnologia legacy pre-esistente. L’integrazione delle nuove tecnologie
standardizzate con le tecnologie legacy é un grosso problema che, se possibile, va
affrontato in fase di progettazione del nuovo sistema gestionale. Per questo
l’introduzione di nuovi standard in sistemi legacy é stata, in passato, sempre effettuata
con grande prudenza e gradualità e il più presto possibile in fase di progettazione .
3.2.9
Enti di standardizzazione
Ci sono vari organismi nazionali (e.g. negli USA) e intarnazionali il cui scopo è
la definizione di normative e “modelli di riferimento” per le telecomunicazioni, in
genenerale, e per la gestione dei sistemi di telecomunicazione, in particolare. Fra gli enti
che svolgono attività normativa nel campo della gestione sistemi TLC dobbiamo
ricordare:
1-
ITU (Internatioanal Telecommunication Union)
2-
ISO (International Standards Organization)
330
3-
ETSI (European Telecommunications Standard Institute)
4-
ATMF (Asynchronous Transfer Mode Forum)
5-
IETF (Internet Engineering Task Force)
6-
TMF (Telecommunications Management Forum)
7-
OMG (Object Management Group)
8-
TINA-C (Telecommunication Information Network Architecture-Consortium)
L’ITU (International Telecomunication Union) è una agenzia delle
Nazioni Unite con sede a Ginevra, specializzata nel campo delle telecomunicazioni. Il
settore di standardizzazione delle telecomunicazioni ITU-T è un organo permanente
dell’ITU.
L’ITU-T è responsabile degli studi relativi a “Questioni” tecniche, operative e
tariffarie nel campo delle telecomunicazioni. I risultati di questi studi sono raccolti in
“Raccomandazioni” che hanno lo scopo di produrre standards su base globale. Le
“Questioni” sono definite nell’ambito di una conferenza con scadenza quadriennale
(World Telecomunication Standardization Conference) e sono studiate da Gruppi di
Studio (SG) numerati a seconda della natura della questioni loro affidate. Ad esempio il
gruppo di studio numero quattro (SG-4) studia questioni relative alla manutenzione delle
reti. Le raccomandazioni dell’ITU-T sono pubblicate in venticinque serie individuate
dalle lettere dell’alfabeto. Ad esempio la serie X è relativa a “Reti dati e comunicazioni in
sistemi aperti”. Nel campo della gestione reti e servizi la serie piu’ importante è la serie
M. È importante ricordare che tutte le Raccomandazioni sono documenti soggetti a
continua revisione e quindi è importante che gli utilizzatori consultino sempre le versioni
piu’ recenti.
Il TeleMangement Forum (TMF) è un organizzazione internazionale nonprofit al servizio delle industrie TLC (Telecommunications) e IT (Information
Technology). La sede è situata nel New Jersey (USA). La missione del TMF è quella di
aiutare i fornitori di servizi, gli operatori di rete ed i venditori di tecnologie (sia hardware
che software) ad automatizzare i loro processi di business in modo efficiente, tramite
l’introduzione di modelli di riferimento.
Il nostro interesse nel TMF è dovuto al fatto che questa organizzazione, verso la
fine degli anni novanta, ha messo a punto un modello di riferimento per la gestione reti e
servizi (Telecom Operations Map, TOM) molto popolare e complementare al modello
TMN prodotto dalla ITU-T. La TOM identifica con grande dettaglio i processi di
business che intercorrono fra fornitori di servizi, clienti e venditori di tecnologie, con
particolare enfasi all’ interfaccia fornitori di servizi-clienti secondo i principi della
filosofia BPR, «re-ingegnerizzazione dei processi di business». (Vedi Cap.9). Quindi,
331
contrariamente al modello ITU-T /TMN che riflette il punto di vista del fornitore di
servizi, il modello TMF é un modello che parte dal punto di vista del cliente per
identificare i requisiti di un sistema di gestione capace di raggiungere gli obiettivi di
business fissati dall’impresa.
L’ ATM Forum è un organizzazione internazionale non-profit con sede negli
USA, fondata nel 1991 da un gruppo di compagnie interessate nell’avanzamento delle
tecnologie ATM. Una delle funzioni principali dell’ ATM Forum è la preparazione di
Specifiche di Interoperabilità, basate su standards preparati dalle organizzazioni di
standardizzazione e.g. ITU-T. Quindi l’ATM Forum produce specifiche che NON sono
standards ma che sono complementari agli standards nell’intento di facilitare
l’interoperabilità di tecnologie ATM prodotte da diverse industrie manifatturiere.
L’Internet Engineering Task Force (IETF) è una grossa comunità
internazionale di progettisti, ricercatori, operatori, costruttori interessati alla utilizzazione
ed evoluzione dell’architettura internet. La sede è a Reston in Virginia (USA). Il lavoro
tecnico di questa Task Force è suddiviso in gruppi di lavoro specializzati in vari
argomenti e.g. trasporto, instradamento, commutazione, sicurezza del traffico internet,
ogni gruppo di lavoro con un Responsabile di Area. Uno dei compiti principali della
IEFT è la definizione di standards per i protocolli di comunicazione e le procedure di
funzionamento delle reti internet. Il processo di standardizzazione è molto semplice: si
sviluppano specifiche che vengono ampiamente discusse fra tutti i membri del Forum
emendate, approvate e pubblicate come standards IETF (o come proposte di standards se
pubblicati come drafts) in documenti classificati con la sigla RFC (Request For
Comment) seguita da un numero. Fra i documenti RFC esistono due sottoserie indicate
rispettivamente con le sigle FYI (For Your Information) e STD (Standard). La sottoserie
FYI comprende documenti di carattere introduttivo mentre la sottoserie STD comprende
documenti che costituiscono dei veri e propri standards. Se un documento STD subisce
delle revisioni il suo numero RFC cambia mentre il suo numero STD rimane lo stesso. I
documanti RFC possono essere downloaded gratis dal sito http://www.rfc-editor.org.
L’Istituto Europeo per gli Standards TLC (ETSI) è un organizzazione
internazinale a livello Europeo la cui missione è la definizione di standards TLC per il
mercato Europeo (ma non esclusivamente). La sede dell’ETSI è ubicata in Franncia a
Sophia Antipolis. L’organizazzine comprende quasi novecento membri fra università,
industrie, centri di ricerca privati e governativi. fornitori di servizi e operatori di reti TLC
provenienti da sessantaquattro nazioni. Gli enti membri dell’organizzazione solleICTano
la definizione di standards nell’ambito delle TLC, partecipano ai lavori e alla definizione
degli standards stessi. I documenti ETSI possono essere downloaded gratis dal sito
internet http://www.etsi.org.
L’Object Management Group (OMG) é un gruppo non-profit fondato nel 1989
il cui mandato é la formulazione di specifiche tecniche pubbliche per software gestionali
indipendenti dalle tecnologie proprietarie dei vari venditori basati sulle tecniche “ObjectOriented”. Il contributo più significativo di questa organizzazione é stata la definizione
332
del software CORBA (Common Object Request Broker Architecture) per sistemi
distribuiti.
Il Telecommunication Information Network Architecture-Consortium
(TINA-C) é stato un foro industriale, fondato negli USA nel 1992, costituito inizialmente
da 40 membri fra cui operatori TLC, venditori di apparati TLC, fornitori di computer
hardware/software. Il mandato dell’organizzazione é stato quello di definire modelli di
riferimento e specificare una architettura aperta per reti/servizi TLC. I risultati vengono
poi proposti a enti di standardizzazione per la definizione di standards. Dettagli possono
trovarsi al sito internet : http://www.tinac.com. Il contributo più significativo
dell’organizzazione é stato la definizione di una piattaforma computazionale distribuita
(Distributed Processing Environment, DPE) che specializza la piattaforma CORBA al
caso di sistemi TLC. L’organizzazione TINA-C è stata sciolta nel 2002.
3.3 Paradigma “Gestore-Agente” nello standard OSISM dell’ITU-T: architetture manuali e
automatizzate
Il genitore più vecchio e più nobile di tutti gli standards gestionali emanati
dall’ente internazionale di standardizzazione ITU-T (International Telecommunications Union – Telecommunications) è lo standard OSI-SM, Open System
Interconnection – System Management, figlio dell’archimandrita OSI-RM, Open
System Interconnection - Reference Model, e frutto delle nozze di quest’ ultimo con
la Sig.ra “Gestione di Rete e Elementi di Rete TLC”. Lo standard OSI-SM si basa su
un paradigma gestionale denominato “Gestore- Agente” che vogliamo studiare in questo
paragrafo.
Vediamo di cosa si tratta!
Abbiamo visto che quando si parla di gestione di reti ed elementi di rete TLC in
effetti significa specificare chi gestisce (i.e. chi è il gestore), cosa è gestito (i.e. quali
sono le caratterisiche gestionali degli oggetti reali da gestire) e come è gestito (i.e. quali
sono le “funzioni di gestione” da svolgere). Infine, poiché il gestore in genere risiede in
siti remoti rispetto all’ubicazione degli oggetti reali da gestire si devono specificare le
modalità di comunicazione fra il gestore e gli oggetti reali da gestire.
Stabilito che per il momento gli oggetti reali della gestione sono reti e elementi di
rete TLC, in questo paragrafo ci occuperemo di “chi” effettua la gestione cioè del
sistema gestore e della evoluzione temporale della sua natura/architettura. Poi nei
paragrafi successivi parleremo di “come” il gestore vuole gestire gli oggetti gestiti cioè
parleremo delle “funzioni di gestione”. Qui vogliamo rispondere a due domande:
333
i)
DOMANDA No.1: “Natura del Gestore”.
La gestione di un sistema TLC é effettuata da personale specializzato (“gestione
manuale”) oppure da uno o più elaboratori numerici mutuamente interconnessi da una
rete di comunicazione dati gestionali (“gestione automatizzata ”)?
ii)
DOMANDA No.2: “Architettura del Sistema Gestionale”.
Le funzioni di gestione sono svolte da un gestore distribuito su una molteplicità di nodi
di elaborazione mutuamente interconnessi da una rete di comunicazione oppure
vengono svolte in un unico gestore residente in un unico centro gestionale (gestore
centralizzato)?
Oppure, formulando la domanda in maniera alternativa:
La funzionalità del Gestore é centralizzata in un unico centro di gestione oppure è
distribuita su rete?
3.3.1 Natura della gestione: manuale o automatizzata
Relativamente alla prima domanda si può dire subito che, come già visto, la
gestione manuale basata su un intervento massiccio di personale specializzato («addetti»
alla gestione) storicamente è stata la prima ad essere realizzata dalle TelCo. In
particolare, negli anni sessanta , essa offriva i vantaggi di 1. essere disponibile a poco
costo (a quei tempi il costo della mano d’opera era basso), 2. offrire un sistema gestionale
estremamente flessibile (l’uomo è capace di rispondere in maniera flessibile alle
situazioni più disparate) e 3. associarsi bene con una architettura gestionale centralizzata
dotata di un unico centro di gestione (personale residente in un unico centro).
•
Limitazioni della gestione manuale
In tempi più recenti la gestione manuale ha evidenziato notevoli limitazioni su
vari fronti. In particolare,
1) un alto costo del personale specializzato,
2) lunghi tempi di risposta, i.e. modeste quantità di traffico gestionale
processato nell’unità di tempo,
3) scarsa affidabilità e,
4) inadeguatezza a gestire sistemi TLC distribuiti
Per ovviare a questi inconvenienti si è gradualmente sviluppata una tendenza a
rimpiazzare la gestione manuale con una gestione automatizzata/standardizzata,
implementata secondo standards di vario tipo. L’accoppiamento della automatizzazione
334
(o automazione) con la standardizzazione è stato motivato dalla necessità di abbattere i
costi delle apparecchiature automatizzate tramite produzione di massa e, allo stesso
tempo, per facilitare l’interoperabilità di apparati eterogenei forniti da venditori diversi.
3.3.2
L’automazione dei processi è sempre parziale
Si potrebbe allora pensare che, con il progresso delle tecnologie e l’avvento della
automazione dei processi gestionali a metà anni novanta, i problemi associati alla
gestione manuale potessero considerarsi risolti: la gestione automatizzata rimpiazza la
gestione manuale (cioè le macchine rimpiazzano gli uomini) e tutti i sistemi di gestione
sono automatizzati! Purtroppo non è così. Infatti, si è rapidamente presa coscienza del
fatto che le Tecnologie ICT necessarie alla gestione automatizzata, non potranno mai
sostituire completamente le risorse umane e, quindi, ci sarà sempre bisogno
dell’intervento umano nella gestione dei sistemi TLC. Basti pensare alle seguenti
attività gestionali che richiedono necessariamente l’intervento umano
1) invio di tecnici specializzati per riparare i guasti in loco,
2) attività del Personale addetto alla assistenza clienti e.g. ai call centers per la
negoziazione dei contratti con i clienti o la fornitura di informazioni relative al catalogo
prodotti e servizi (un potenziale cliente preferisce sempre parlare con un altro essere
umano piuttosto che con una Risorsa TLC!),
3) pianificazione/progettazione di servizi TLC in genere effettuate da teams
crossfunzionali di personale specializzato proveniente dalle varie unità organizzative di
una Telco.
4) attività gestionale svolta ai più alti livelli del management aziendale e.g.
gestione d’impresa integrata con la gestione servizi (Non si può rimpiazzare un direttore
generale con un computer!)
In pratica, quindi, in un sistema gestionale reale ci sarà sempre un misto di
gestione manuale e gestione automatizzata con un impiego di personale specializzato
dettato talvolta da criteri/condizioni di natura locale e.g. dimensioni del sistema
TLC da gestire, criteri economico-finanziari (volume e tempistica degli investimenti)
, condizioni del mercato etc. Ad esempio è intuitivamente ovvio che un piccolo sistema
TLC con un volume di dati gestionali modesto e.g. rete LAN, può essere gestito con
gestione manuale mentre per un grosso sistema TLC, e.g. rete geografica, ciò non è più
vero. Quindi il vero problema non è se la gestione è manuale o automatizzata ma quali
sono le relative proporzioni fra gestione manuale e gestione automatizzata in
relazione alle caratteristiche del sistema TLC gestito e alle politiche aziendali che si
vogliono realizzare (obiettivi di business da conseguire).
Il problema «gestione manuale verso gestione automatizzata » va risolto di volta
in volta dal gestore. Diversi gestori adottano livelli diversi di automazione e uno stesso
gestore può scegliere livelli diversi di automazione per servizi/mercati in areee
335
geografiche diverse. Tuttavia vedremo in seguito che oggi la forte concorrenza esistente
fra Telco, la necessità di stabilire margini di competitività per vincere questa
concorrenza, lo sviluppo impetuoso di tecnologie ICT e la riduzione dei loro costi,
spingono verso livelli di automazione/integrazione sempre più elevati.
Operatore
Commerciale
Cliente
Richiesta
installazione/
attivazione
servizio
Progettista
Rete
Tecnico
Installatore
NETWORK OPERATOR
Dati
commerciali
Verifica
commerciale
Operatore
Tecnico
Ordinativo
commerciale
Segnalazione
servizio
attivato
Richiesta di
intervento
Verifica
fattibilità
tecnica
Dati
tecnici
Attivazione
(1)
Avviso avvenuta attivazione
Avviso
avvenuta
installazione
SERVICE
PROVIDER
Installazione
(1) Aggiornamento dati tecnici
Persona TLC
Fig.3.3.3. 1 Rappresentazione semplificata di procedura manuale di “fornitura di servizio” (service
provisioning) come flusso di attività elementari. Ogni attività elementare è preposta all’espletamento di un
compito specifico ed ha una certa durata (tempo di lavoro). Gli intervalli di tempo che separano le varie
attività sono tempi morti. Il Cliente percepisce il tempo complessivo impiegato dal ciclo processuale e una
sua riduzione migliora la qualità del servizio. Se i tempi morti sono dominanti una riduzione dei tempi di
lavoro tramite una semplice automazione delle attività elementari contribuisce poco a migliorare la qualità
del servizio. Se la attività non sono elementari ma sono esse stesse processi la figura può essere considerata
come rappresentativa di un flusso di processi. Per una rappresentazione più dettagliata del processo di
“service ordering” vedere Fig. 1.2.3.3)
.
336
3.3.3
Come si effettua la automazione dei processi gestionali
Abbiamo già fornito una definizione esatta di «processo» o meglio di «processo di
business» in un contesto aziendale. Qui ricordiamo che un processo, e in particolare un
processo di business all’interno di una Telco, è un flusso temporale di funzioni che si
svolgono in condizioni prefissate altamente controllate cioè secondo procedure
prestabilite (o, additittura standardizzate) accuratamente documentate, utilizzando risorse
prefissate e da parte di addetti con compiti/responsabilità precise. Ci poniamo allora le
seguenti domande: In pratica come si effettua la automazione dei processi gestionali? Il
rimpiazzo tecnologia-uomo è semplice o complicato?
Supponiamo che inizialmente gli agenti del processo siano rappresentati da
personale specializzato (gestione manuale) e che esista una gestione manuale
comprensiva di varie competenze professionali (Fig.3.3.3.1). In queste circostanze il
processo di automazione richiede che i componenti della gestione manuale vengano
modellizzati in processi gestionali utilizzando schemi formali sufficientemente rigorosi
e dettagliati da poter essere convertiti in applicazioni gestionali (e.g. software gestionale
scritto con opportuni linguaggi). Poi i vari processi/applicazioni gestionali devono essere
aggregati in flussi di processi (process flow) capaci di produrre in uscita risultati uguali
o migliori dei risultati ottenuti manualmente in precedenza. Come già indicato nel
Capitolo 1 il coordinamento/controllo nel dominio temporale dei vari processi secondo
una logica prestabilita viene poi effettuata con sistemi informatici dedicati alla gestione
dei flussi di lavoro (Work-Flow Management) oggi commercialmente disponibili e di
largo uso.
In queste circostanze il problema da risolvere è duplice: 1) è possibile fare tutto
ciò ? 2) anche se possibile, con quale precisione ? Infatti la gestione manuale, sebbene
svolta attraverso processi con modalità prescritte e controllate lascia sempre spazi
discrezionali entro i quali l’addetto alla gestione può esercitare il proprio (buon!)
giudizio a seconda delle circostanze. Questo aspetto della attività del gestore umano, se
avviene entro limiti prefissati, introduce un prezioso elemento di flessibilità (i.e.
possibilità di adattamento a una varietà di situazioni diverse anche inaspettate),
adattamento che è difficile da modellizzare e, quindi, rimpiazzare con software
gestionale. Come già detto in 3.3.2 la automazione non è possibile per tutti i processi.
Quindi, come già precedentemente indicato, la conclusione è che, l’automazione
di un processo gestionale manuale (sostituzione macchina-uomo) va effettuata dal gestore
laddove possibile con molta cautela valutando caso per caso accuratamente non solo
quanto si guadagna (si spera molto!) ma anche quanto si perde (si spera poco!) e questo si
fa bene sulla base di modelli processuali del tipo e-TM del TMF.
337
3.3.4 Paradigma Gestore-Agente: architetture centralizzate o distribuite
(Une versione più estesa che non fa parte del programma 2008-2009 è disponibile
nella Appendice 1 alla Parte 1)
3.3.4.1
Le architetture gestionali centralizzate e il paradigma gestore-agente
Prima di spiegare cosa è una architettura gestionale centralizzata vogliamo
brevemente ricordare il concetto di gestione basata sul paradigma «Gestore-Agente»,
secondo il quale un sistema gestionale è costituito da due sottosistemi che si
scambiano messaggi gestionali: un sistema che gioca il ruolo di gestore (sistema gestore
o semplicemente «gestore») e un sistema che gioca il ruolo di agente (sistema gestito o
semplicemente «agente») connesso direttamente con le risorse gestite. In particolare:
1) Sistemi che emettono richieste di operazioni gestionali sulle risorse
reali gestite e ricevono notifiche dei risultati delle operazioni effettuate
sono sistemi che giocano il ruolo di gestore.
2) Sistemi che hanno un ruolo duale del precedente cioè emettono
notifiche dei risultati e ricevono richieste di operazioni sulle risorse
gestite sono sistemi che giocano il ruolo di agente.
Consideriamo ora il caso più semplice di gestione di una rete TLC ed il primo ad
essere adottato (anni 70-80): la gestione con architettura centralizzata o gestione
mono-gestore . Una architettura gestionale centralizzata o mono-gestore (Fig. 3.3.4.1 a) è
caratterizzata dal fatto che in essa esiste un unico gestore (G) residente in una stazione
di gestione (Network Management Station, NMS) ospitata in un nodo elaborativo di una
rete di comunicazione di dati gestionali (Data Communicatioin Network, DCN). Il
gestore, attraverso la rete dati, gestisce tutte le risorse fisiche del sistema (e.g. elementi di
rete) tramite agenti (A), ognuno dei quali resiede in (o in prossimità di) una risorsa
gestita (RG).
L’ «intelligenza» del sistema di gestione i.e. la
capacità di
memorizzare/elaborare/trasformare dati gestionali e la responsabilità della gestione sono
concentrate nel gestore centralizzato nella NMS.
Ogni agente ha un ruolo di minore responsabilità/intelligenza rispetto al gestore
(e.g. accettazione/rigetto degli ordini ricevuti dal gestore relativamente ad un singolo
apparato dopo verifica della eseguibilità degli ordini stessi, esecuzione ordini ricevuti dal
gestore tramite manipolazione di oggetti gestiti contenuti in MIB, rinvio di risultati delle
operazioni gestionali e/o invio spontaneo al gestore di notifiche guasti avvenuti nel
singolo apparato, etc.).
Infatti, in letteratura talvolta si legge anche che in una architettura gestionale
centralizzata esiste un unico gestore «intelligente» (smart, in inglese) che «supervisiona
e controlla» tutto il sistema da gestire e una molteplicità di agenti «poco intelligenti»
(dumb, in inglese) ognuno dei quali collabora con il gestore, relativamente al suo
apparato da gestire. Storicamente, architetture gestionali centralizzate sono state
338
caratterizzate da scambi di informazione gestionale fra gestore e agente strutturati
secondo protocolli standard molto semplici e.g. SNMP.v1 (Simple Network Management
Protocol versione 1)
3.3.4.2
Architetture gestionali multi-gestore «debolmente distribuite» (Fig.3.3.4.1
b,c).
La filosofia della gestione centralizzata, prevalente negli anni 70 e 80 è stata
motivata dall' esigenza di concentrare l’intelligenza del sistema di gestione in un unico
centro che a sua volta fosse facilmente gestibile e.g. utilizzando personale specializzato
(gestione manuale) concentrato in un unica sede. Inoltre la concentrazione di intelligenza
in un unico centro di gestione permetteva di avere un gran numero di elementi di rete che
incorporavano agenti «poco intelligenti» (dumb agents) con limitate capacità
computazionali e di memoria e quindi poco costosi. A quei tempi il costo delle
tecnologie di elaborazione dell’informazione/dati era ancora molto alto. Tuttavia, negli
anni 90 la situazione è cambiata grazie allo sviluppo e alla riduzione del costo delle
tecnologie IT (mini/micro calcolatori) e TLC (reti locali LAN e internet) e alla crescente
consapevolezza che una architettura gestionale centralizzata è molto poco adatta a grossi
sistemi TLC.
Lo sviluppo delle tecnologie ICT e l’espansione dei sistemi/servizi TLC, sia su
base geografica (TelCo multi-nazionali) che in termini di offerta di tipologie di servizio
(TelCo multi-corporation o “value network” di imprese partner), hanno fatto sì che l’
architettura gestionale centralizzata mono-gestore si sia gradualmente evoluta verso
forme decentralizzate multi-gestore cioè si è passati da un gestore unico a una
molteplicità di gestori (chiamati «elementi gestore» o «componenti gestore») interconessi
e cooperanti, residenti in nodi elaborativi remoti di una rete di comunicazione dati.
Si sono così sviluppate architetture gestionali che spesso vengono denominate
“distribuite” ma che in questo corso chiameremo “debolmente distribuite”.
Terminologia usata per distinguere queste architetture da architetture “fortemente
distribuite” dotate di una intelligenza capace di risolvere i “problemi della distribuzione”
che saranno esaminati fra poco.
NOTA 3.3.4.2.1 Quindi, in questo corso, le architetture mono-gestore realizzate secondo il paradigma
gestore-agente sebbene dotate di una molteplicità di agenti residenti in nodi remoti di una rete dati, sono
chiamate « centralizzate » e non « distribuite ». Solo le architetture multi-gestore, con elementi gestore
residenti in nodi remoti di una rete dati, sono chiamate «distribuite». Quindi il concetto di distribuzione si
riferisce alla architettura del gestore e non a quella degli agenti!
3.3.4.3
Architetture di cooperazione e architetture gerarchiche
Le architetture gestionali «debolmente distribuite» possono essere di due tipi:
architetture di cooperazione o architetture gerarchiche.
Le architetture gestionali di cooperazione (Fig.3.3.4.1b) sono architetture
caratterizzate da gestori con relazioni di cooperazione pari-a-pari («peer-to-peer» in
inglese) con altri gestori, interconnessi in una rete dati. Queste relazioni sono identificate
339
da frecce orizzontali in Fig. 3.3.4.1b («interazioni orizzontali»). In questa figura sono
mostrati due gestori che operano in domini amministrativi diversi e.g. Telecom Italia
gestisce reti/elementi di rete italiani e British Telecomo gestisce reti/elementi di rete
inglesi. I due gestori si scambiano informazione gestionale.
Le architetture di cooperazione sono rilevanti anche ad altri scenari gestionali. Ad
esempio i diversi elementi gestori si differenziano e sono individualmente ottimizzati
sulla base di funzioni gestionali diverse (e.g. uno gestisce i guasti, uno l’accounting e
un’altro la sicurezza) e operano allo stesso livello di gestione in una struttura gerarchica
TMN
La Fig. 3.3.4.1b mostra come in una architettura di cooperazione quello che
abbiamo chiamato un sistema gestore in effetti svolga una attività multi-ruolo cioè nella
relazione pari-a-pari (peer-to-peer) con un altro sistema operante allo stesso livello possa
giocare il ruolo di gestore e/o agente e allo stesso tempo giochi il ruolo di gestore rispetto
all’ agente del livello inferiore. Quindi, in questo caso, il cosidetto «sistema gestore»
dovrebbe più correttamente chiamarsi «una applicazione gestionale che può giocare,
anche simultaneamente ruoli gestore o agente ».
Differentemente dalle architetture di cooperazione che permettono solo
interazioni orizzontali fra elementi gestore le architetture gerarchiche (Fig.3.3.4.1c)
mostrano anche «interazioni verticali» fra elementi gestore operanti a livelli gestionali
diversi. Si pensi ad esempio ai livelli gestionali di una struttura stratificata TMN.
In una architettura gestionale gerarchica i gestori di un livello superiore delegano
parte delle loro responsabilita’ di gestione a gestori di un livello inferiore e questa delega
si rinnova di livello in livello fino a raggiungere i gestori del livello più basso i quali
gestiscono «agenti» che operano direttamente sulle risorse gestite. Queste architetture si
chiamano anche architetture MoM (Manager of Managers) per ovvi motivi. Per
queste architetture sono stati sviluppati protocolli standard più complessi del SNMP.v1,
ad esempio i protocolli CMIP (Common Management Information Protocol) e SNMP.v2.
3.3.4.4
Vantaggi e svantaggi delle architetture gestionali “debolmente” distribuite
I vantaggi presentati da architetture debolmente distribuite multi-gestore rispetto
alle architetture centralizzate mono-gestore sono molteplici. Ad esempio esse possono
1)
suddividere il carico computazionale gestionale («carico») fra più
gestori, con funzionalità identiche o diverse, rendendo il sistema
gestionale più scalabile (e.g. capace di rispondere a un incremento di
carico semplicemente aggiungendo nuovi gestori senza, tuttavia,
cambiare l’architettura del sistema stesso) e più robusto (cioè più
resistente ai malfunzionamenti o guasti del sistema di gestione tramite
rimpiazzo di un gestore guasto con un gestore equivalente di riserva).
340
2)
permettere l’ottimizzazione dei vari gestori componenti su base
geografica locale (e.g. un gestore nazionale gestisce l’Italia, un gestore
nazionale gestisce la Francia etc.) o funzionale (e.g. un gestore gestisce
i guasti, un’altro gestisce l’amministrazione e un’altro ancora gestisce
la sicurezza)
3)
rendere la struttura del sistema di gestione decentralizzata e quindi
molto più simile alla struttura dell’organizzazione aziendale dei sistemi
TLC moderni che tendono a divenire sempre più decentralizzati (e.g.
aziende multinazionali con uffici/impianti sparsi in tutto il mondo).
Lo svantaggio principale di un sistema debolmente distribuito rispetto ad un
sistema centralizzato è la necessità di dover poi gestire la molteplicità degli elementi
gestore con ulteriori sistemi di gestione (il gestore del gestore!) talvolta molto complessi
e la necessita’ di risolvere i problemi di interoperabilità fra elementi gestore molto spesso
eterogenei. Infatti l’ottimizzazione su base funzionale o geografica di sistemi gestionali
estesi su una base geografica internazionale può facilmente portare al coinvolgimento di
una molteplicità di tecnologie diverse l’una dall’altra e mutuamente incompatibili (e.g.
diversità di hardware, sistemi operativi, linguaggi di programmazione e/o politiche
gestionali adottate in dominii amministrativi diversi). Le architetture gestionali
debolmente distribuite assieme alle architetture centralizzate sono tipiche della gestione
«tradizionale» che verrà trattata nella seconda parte del corso.
3.3.4.5
Architetture gestionali «fortemente distribuite».
Man mano che in un sistema gestionale debolmente distribuito aumenta il numero
dei componenti gestore interconnessi in rete, aumenta anche la difficoltà di risolvere le
problematiche della loro distribuzione (eterogeneità, localizzazione e sincronizzazione
dei componenti, fenomeni di propagazione dei guasti etc.). A questo punto si deve
passare da un sistema gestionale debolmente distribuito ad un un sistema gestionale
fortemente distribuito. Infatti in un sistema gestionale fortemente distribuito queste
problematiche vengono affrontate e risolte dal sistema gestionale stesso senza che se ne
debbano occupare i programmatori o gli utilizzatori del sistema. Come?
NOTA 3.3.4.5.1 (dall’ADDENDUM No.2)
DEFINIZIONE di SISTEMA GESTIONALE «DISTRIBUITO». Un sistema
gestionale distribuito é un sistema costituito da componenti applicativi autonomi,
residenti in nodi elaborativi remoti interconnessi da una rete di comunicazione dati,
che cooperano in un contesto di elaborazione virtualmente unitario.
DEFINIZIONE di ELABORAZIONE DISTRIBUITA a OGGETTI (Distributed
Object Computing, DOC): L’elaborazione distribuita a oggetti é un tipo di
elaborazione distribuita che adotta la filosofia dell’orientamento agli oggetti e
fornisce un contesto virtualmente unitario di elaborazione in cui i processi
eleborativi cooperano come se risiedessero su un unica macchina.
341
Le architetture multi-gestore debolmente distribuite possono riguardarsi come un
primo passo verso architetture gestionali fortemente distribuite in cui il gestore non solo
è suddiviso in un insieme di gestori elementari residenti nei nodi remoti di una rete dati
gestionali ma le applicazioni gestore fanno uso esplicito di tecniche/tecnologie
computazionali a oggetti distribuiti del tipo Distributed Object Computing (e.g.
CORBA, Common Object Request Broker Architecture) (Vedi NOTA 3.3.4.5.1 e
Addendum No.2) capaci di risolvere le problematiche della distribuzione o, più
precisamente, di mascherare gli effetti della distribuzione agli occhi dei
programmatori/utilizzatori e creare un contesto computazionale virtualmente unitario
dove i programmatori/ utilizzatori del sistema gestionale distribuito operano come se
operassero su base locale cioè come se i componenti distribuiti risiedessero in un unico
nodo.
G1
G
A
A
RG
RG
A
G
A
G2
A
A
G
G2
a. Gestione Centralizzata
A
A
G
G
A
A
G
Dominio
A
A
c. Gestione Gerarchica
G
A
A
A
A
A = Agente
G = Gestore
RG = Ris. Gestita
b. Gestione di Cooperazione
Relazione G-A
Fig. 3.3.4.1 Architetture gestionali
342
IU
IU
IU
A
A
A
MIDDLEWARE
SO
SO
SO
HW
HW
HW
RETE
Fig.3.3.4.2
Vedremo che il mascheramento degli effetti della distribuzione degli elementi
gestore (o, altrimenti detto, la creazione di «trasparenze» nella distribuzione) è possibile
utilizzando una infrastruttura computazionale chiamata «middleware», (Vedi Fig.3.3.4.2)
interposta fra il livello «applicativo» e il livello di «sistema operativo». La tecnologia
CORBA è un esempio di « middleware ». Quindi ripetiamo, in un sistema fortemente
distribuito, si ottiene «the best of both worlds!»: un sistema gestionale distribuito che agli
occhi dello sviluppatore/utilizzatore è, a tutti gli effetti, ….non distribuito (ODMA, Open
Distributed Management Architecture dell’ITU-T, modello TINA-C).
3.4
Il modello “TMN stratificato” dell’ITU-T
3.4.1
La gestione dei sistemi TLC (sistema, servizi, impresa)
Come già detto i primi modelli/standards gestionali hanno riguardato la gestione
delle tecnologie U&S contenute in un sistema TLC, cioè hanno specificato quali
proprietà/parametri di funzionamento era opportuno scegliere per caratterizzare le reti e/o
i loro elementi da un punto di vista gestionale. Questo fu fatto perchè la gestione di un
“oggetto materiale” come un elemento di una rete TLC è particolarmente facile da
modellizzare.
Ora vogliamo presentare un modello gestionale preparato dall’ITU-T per
“oggetti” materiali e immateriali, cioè in pratica per reti e servizi. L’ITU-T classifica le
funzionalità/funzioni gestionali in quattro raggruppamenti relativi a: 1) impresa, 2)
servizi, 3) reti e 4) elementi di rete. Il corrispondente modello si chiama “Modello TMN
343
stratificato” in quanto è rappresentato con quattro strati sovrapposti come mostrato in
Fig.3.4.1.
Per ogni strato possiamo sviluppare un sottomodello gestionale. Si ottengono
così quattro sottomodelli gestionali relativi alle quattro ggestioni: gestione impresa,
gestione servizi, gestione reti e gestione elementi di rete. In base a questo modello la
gestione complessiva di un sistema TLC è definita come l’aggregazione delle attività
svolte ai seguenti «livelli»: gestione impresa, gestione servizi, gestione reti e gestione
elementi di rete. (Fig. 3.4.1). Per ogni livello l’ attività gestionale va intesa nel senso
FCAPS cioè come insieme di attività appartenenti alle cinque aree funzionali FCAPS.
Usando una rappresentazione geometrica simbolica nella quale la totalità delle
risorse gestionali è rappresentatata da un cubo, la precedente definizione può
rappresentarsi graficamente suddividendo il cubo in cinque strati orizzontali. I quattro
strati superiori rappresentano risorse relative ad attività gestionali inerenti a quattro
diverse responsabilità di gestione. (Vedi Fig.3.4.1). La strato più basso «elementi di
rete» rappresenta le risorse elementari U&S “oggetto” di gestione da parte dello strato
superiore. Esso partecipa alla gestione ma non ha responsabilità di gestione, nel senso
che non decide quali attività gestionali devono essere svolte. Per questo è stato indicato
semplicemente con la dicitura «Elementi di rete». Tuttavia in esso risiede un software
gestionale “Agente” che esegue gli ordini ricevuti dallo strato superiore dove risiede un
software gestionale “Gestore” secondo il paradigma Gestore-Agente. Fra poco nel
par.3.5 vedremo di cosa si tratta. Diciamo subito che nel modello TMN stratificato, la
sequenza degli strati dal basso verso l’alto non è arbitraria o modificabile a piacimento
ma segue un ben preciso ordinamento gerarchico. Ad esempio i gestori attivi in uno
strato superiore delegano ai gestori in uno strato inferiore la responsabilità di svolgere
certe attività gestionali (e.g. i gestori nello strato «gestione reti» delegano ai gestori nello
strato «gestione elementi di rete» la responsabilità di gestire questi ultimi).
3.4.2 Propedeuticità delle attività di gestione nel modello TMN.
Ma in effetti i criteri gerarchici che governano la struttura del modello TMN
stratificato sono più di uno. La Fig. 3.4.2 mostra come l’ordinamento degli strati nel
modello TMN stratificato sia stata scelto in modo da rispettare non solo un ordinamento
gerarchico di delega di responsabilità gestionali ma anche una sequenzialità temporale
(propedeuticità) dei vari tipi di gestione: le attività gestionali in un certo strato non
possono svolgersi senza previo svolgimento e completamento delle attività in “tutti” gli
strati sottostanti.
Ad esempio la gestione servizi richiede che vengano effettuate preventivamente
sia la gestione elementi di rete e che la gestione reti e che i dati gestionali relativi a queste
gestioni vengano resi noti al gestore servizi. Analogamente la gestione del business
richiede che venga effettuata preventivamente la gestione dei servizi e che i dati relativi a
questa gestione vengano forniti al gestore del business.
344
AMMINISTRAZIONE
GUASTI
Modello funzionale
PRESTAZIONI
CONFIGURAZIONE
SICUREZZA
FCAPS
Modello
logico
stratificato
GESTIONE BUSINESS
GESTIONE SERVIZI
GESTIONE RETI
Modello organizzativo
GESTIONE ELEMENTI RETE
A. GERARCHICA
A. COOPERATIVA
ELEMENTI RETE
A. CENTRALIZZATA
FIG. 3.4.1.
345
Deleghe di
responsabilità
per svolgimento
attività di
gestione
Tempi di
completamento
delle attività
GESTIONE IMPRESA
di gestione
GESTIONE SERVIZI
GESTIONE RETI
GESTIONE ELEM. RETE
Fig. 3.4.2 Ordinamento gerarchico degli strati nel modello TMN stratificato
3.4.3
L’informazione gestionale è fornita da uno strato inferiore a quello
superiore secondo un processo di astrazione
Oltre alla delega di responsabilità gestionali (dall’alto verso il basso) e alla
propedeuticità (sequenza temporale) delle attività di gestione (dal basso verso l’alto) c’è
un terzo aspetto importante, intrinseco nell’ordinamento degli strati: la fornitura di dati
gestionali da uno strato gestionale all’altro. Ogni strato fornisce informazione gestionale
allo strato superiore cioé offre elementi gestionali di supporto alla gestione nello strato
superiore. Ad esempio si vede subito come sia necessario che il gestore di rete, oltre a
gestire una rete, passi allo strato superiore solo quelle informazioni rilevanti alla gestione
dei servizi, cioè offra al gestore servizi una vista astratta della gestione di rete. A sua
volta il gestore servizi offre informazione in supporto della gestione dell’impresa e.g.
notificando alla gestione d’impresa l’ammontare delle entrate relative ai pagamenti
effettuati dai clienti a fronte dei servizi fruiti: il senior management della TelCo non può
gestire l’impresa se non conosce l’ammontare delle entrate derivanti dalla fornitura dei
servizi!
Quindi, si noti bene che non tutta l’informazione gestionale disponibile in uno
strato deve essere trasferita allo strato superiore ma solo quella parte necessaria per la
gestione nello strato superiore (i.e. si deve trasferire solo una “vista astratta” della
gestione dello strato inferiore. Ricordare che “astrarre” significa “tirare fuori”).
ESEMPIO 3.4.3.1 Il gestore di una grande rete TLC aggregazione di sottoreti eterogenee certamente
deve conoscere e gestire le varie tecnologie di sottorete che intervengono in una connessione end-toend e.g. sotto-reti ADSL, ATM, Frame Relay etc. ma non ne deve specificare i dettagli al gestore
servizi dello strato superiore. Infatti quest’ultimo ha solo bisogno di una vista astratta tecnologyneutral della grande rete. Fintantochè le tecnologie di rete garantiscono un traffico con le prestazioni
346
desiderate e ai costi previsti, il gestore servizi non è affatto interessato a conoscerne i dettagli
tecnologici delle sottoreti.
Un ragionamento simile può farsi per gli strati «gestione elementi di rete» e
«gestione reti». Infatti per gestire una rete non è necessario conoscere tutti i dettagli dello
stato/funzionamento di ogni singolo elemento di rete. E’ sufficiente che lo strato
«gestione elementi di rete» offra allo allo strato superiore una vista astratta «vendor independent» cioè depurata dei dettagli delle tecnologie proprietarie impiegate nei vari
elementi.
Ricapitoliamo quanto detto sinora. L’invio di informazione gestionale da parte di
uno strato inferiore ad uno strato superiore avviene astraendo (cioè «tirando fuori»)
dall’informazione gestionale dello strato inferiore solo la parte rilevante alle attività di
gestione nello strato superiore. Per questo si dice anche che gli strati gestionali sono
“strati logici” (logic layers) ordinati dal basso verso l’alto per livelli di astrazione
(abstraction levels) crescenti
3.4.4
Il modello TMN stratificato: cenni storici
La suddivisione della gestione di un sistema TLC in quattro strati gestionali
ordinati per livelli di astrazione crescenti come mostrato in Fig.3.4.1 fu introdotta dall’
ITU-T all’inizio degli anni ottanta e fu chiamata «modello TMN (Telecommunication
Management Network) a strati logici» o « Modello TMN stratificato ». La ragione di
questa denominazione é ovvia se si guarda ai quattro strati in Fig. 3.4.1. Il modello ebbe
sin dall’inizio grande successo anche perché rifletteva abbastanza fedelmente la
suddivisione di responsabilità a livello organizzativo effettivamente esistenti all’interno
di una TelCo ( e.g. il dipartimento “gestione business” demandava al dipartimento
“gestione reti” la responsabilità di gestire le reti e così via scendendo verso il basso).
Tuttavia i dettagli della gestione in ogni singolo strato furono sviluppati solo per i
due strati inferiori e il modello TMN stratificato è risultato sempre carente a livello
gestione servizi e gestione impresa.
347
Aree Funzionali
Gruppi di Insiemi di Funzioni
1. RAS Quality Assurance (6)
2. Alarm Surveillance (10)
3. Fault Localization (5)
FAULT
4. Fault Correction (5)
5. Testing (11)
(44)
6. Trouble Administration (7)
7. Network Planning & Engineering (11)
8. Installation (12)
CONFIGURA- 9. Service Planning & Negotiation (10)
TION
10. Provisioning (29)
11. Status & Control (8)
(70)
12. Usage Measurement (17)
ACCOUN13. Tariffing/Pricing (8)
TING
14. Collection & Finance (21)
15. Enterprise Control (11)
(57)
16. Performance Quality Assurance (7)
17. Performance Monitoring (10)
PERFORMANCE
18. Performance Management Control (6)
19. Performance Analysis (11)
(34)
20. Prevention (5)
21. Detection (10)
SECURITY
22. Containement and Recovery (16)
23. Security Administration (24)
(55)
Tavola 3.5.1 Aree Funzionali di Gestione (5) e Gruppi di Insiemi di Funzioni di Gestione (23) secondo la
Raccomandazione ITU-T M.3400 del 2/2000. I numeri fra parentesi indicano il numero di “Insiemi di
Funzioni” contenuti nei vari gruppi.
348
3.5 Il modello funzionale FCAPS dell’ITU-T
3.5.1 Cattere generico e convenzionale dei modelli gestionali .
Notare che mentre le funzioni/funzionalità primarie sono sempre specifiche del tipo di
tecnologia U&S di volta in volta presa in considerazione (e.g. l’ amplificatore amplifica,
il commutatore commuta, l’istradatore istrada, la stampante stampa etc.), le
funzioni/funzionalità gestionali possono essere di due tipi: specifiche del tipo di
tecnologia in questione (e.g. supervisionare e controllare che la potenza RF in uscita di un
amplificatore superi un valore di soglia prefissato) oppure possono essere generiche, cioè
valide per una molteplicità di tecnologie diverse (e.g. supervisionare e controllare il
tempo di funzionamento di un quasiasi apparato di rete a partire dalla sua ultima
attivazione). Altri esempi di funzioni/funzionalità gestionali generiche sono la
supervisione & controllo dello stato in cui ad un certo momento si trova un elemento di
rete qualsiasi e.g. “stato di allarme” (debole, forte, critico) o “stato amministrativo”
(bloccato, sbloccato, sotto prova) o “stato operazionale” (inattivo, stand-by, attivo,
occupato).
P R IN C IP I G E N E R A L I
M ODELLO
C O N C E T T U A LE
A P P R O C C IO
T O P -D O W N
(S p e c ia li z z a zio n e )
M O D E L L O G E N E R IC O
M 1
M 2
M 3
M 4
M 5
M 6
A P P R O C C IO
B O T T O M -U P
(G e n e r a li z za z io n e )
M O D E L L I SP E C IF I C I
T1
T2
T3
T4
T5
T6
T E C N O L O G IE
Fig.3.5.1 Un modello gestionale generico situato ad un certo livello di
astrazione può ottenersi in due maniere: partendo dal basso (procedura
“bottom up”) generalizzando modelli specifici e.g. relativi a singole
tecnologie, oppure partendo dall’ alto (procedura “top-down”) specializzando
modelli gestionali concettuali derivati da principi generali.
Queste considerazioni aprono la porta alla possibilità di creare un “modello
gestionale generico” applicabile a sistemi tecnologicamente eterogenei.
Un modello gestionale generico offre il vantaggio di evitare la frammentazione
della gestione di “oggetti” (materiali o immateriali) diversi in una pletora di gestioni
specifiche diverse, ognuna dedicata ad un certo “oggetto”, con pericolo di intrurre
ridondanze, sovrapposizioni e, in definitiva, complessità ingiustificata. Tuttavia può
presentare lo svantaggio di offrire una gestione meno dettagliata, e.g. supervisione e
349
controllo meno stringenti, di quello offerto da modelli gestionali specifici. Ovviamente
esiste una possibilità intermedia: introduzione/adozione di un “modello gestionale
generico modulare” specializzabile a casi specifici tramite rimpiazzo/aggiunta di
opportuni moduli.
ITU-T Recommendation M.3400 (02/2000)
SERVIZIO di GESTIONE
Un Servizio di Gestione
è realizzato con SMF
appartenenti a
Cinque aree funzionali
(5) AREE FUNZIONALI
(SMFA)
(23) GRUPPI di INSIEMI di SMF
Ogni SMFA è suddivisa
In Gruppi di Insiemi di SMF
Ogni Gruppo di Insiemi
di SMF è suddiviso in
Insiemi di SMF
(260) INSIEMI di SMF
FUNZIONI di GESTIONE (SMF)
Ogni Insieme di
SMF contiene SMF
Presentazione 11
Tavola 3.5.2
Ma anche se si stabilisce l’utilità e il desiderio di adottare un modello gestionale
generico modulare specializzabile di volta in volta a casi specifici tramite
aggiunta/sostituzione di opportuni moduli rimane un problema: quale ente di
standardizzazione nazionale o internazionale crea il modello/standard de jure? Quale
modello gestionale si deve adottare? Purtroppo esistono vari enti di standardizzazione
nazionali e internazionali preposti alla definizione di modelli gestionali i quali per uno
stesso “oggetto” da gestire sviluppano modelli gestionali diversi. Questo significa che
spesso la “gestione” assume un carattere convenzionale cioè è gestione quello che singoli
gestori o certi enti di standardizzazione definiscono essere gestione e.g. tramite emissione
di loro modelli gestionali.
Diciamo quindi che, mentre la funzionalità primaria posseduta da una certa
tecnologia U&S è sempre specifica e ben nota a tutti gli interessati sin dall’ inizio, la
funzionalità di gestione, di natura ancillare rispetto alla funzionalità primaria, può avere
un carattere generico e convenzionale dipendente dal particolare modello gestionale
350
scelto dal gestore.. In pratica quando si parla di gestione, di volta in volta, è necessario
specificare a quale modello gestionale ci si riferisce.
3.5.2
Necessità di modelli funzionali (possibilmente standardizzati) per definire le
funzioni di gestione per sistemi TLC
Finora abbiamo detto che le attività di gestione delle tecnologie U&S tramite
tecnologie gestionali possono classificarsi come supervisione e controllo della loro
configurazione, prestazione, guasti, amministrazione e sicurezza. In modo analogo
abbiamo detto che nei servizi TLC le funzionalità di gestione sono utilizzate per gestire
le funzionalità U&S i.e. l’aggregazione di funzionalità di gestione e funzionalità U&S fa
sì che un servizio TLC nel suo complesso venga fornito/erogato in maniera
efficace/efficiente (criterio di economicità). Ora vogliamo ribadire il fatto che tutto ciò è
molto generico e certamente insufficiente per una Telco che debba svolgere in pratica
specifiche funzioni di gestione affinchè gli obiettivi della gestione possano essere
raggiunti. Ricordiamo che per una TelCo l’ obiettivo principale della Gestione TLC è il
conseguimento in maniera sostenibile degli obiettivi di business associati con la fornitura
dei servizi TLC e, preminente fra gli obiettivi di business, il soddisfacimento delle
esigenze dei Clienti (customer oriented business).
In pratica una definizione di gestione di un sistema TLC è sufficientemente
accurata e dettegliata solo se può basarsi su modelli gestionali funzionali che
specificano le singole funzioni gestionali necessarie a raggiungere gli obiettivi di
business prefissati. Ovviamente questi modelli devono essere modelli accettati se non
proprio universalmente almeno da un gran numero di imprese telecom in modo da
raggiungere un accordo fra gestori il più vasto possibile. E’ quindi importante, come già
fatto per gli elementi di rete, ribadire il carattere convenzionale di cosa effettivamente
costituisca «gestione» di un sistema TLC: è «gestione» quello che opportuni enti
internazionali di standardizzazione dichiarano essere «gestione» (tramite
pubblicazione ufficilale di opportuni documenti) e che tutti i gestori d’accordo
accettano come «gestione». Raggiungere un accordo su vasta scala su cosa costituisca
«gestione di sistemi e servizi TLC» è importante sia all’interno di una stessa TelCo sia
nel caso di collaborazione fra Telco semplicemente per il fatto che è necessario che tutti
gli interlocutori parlino lo stesso linguaggio e sappiano “chi fa che cosa”.
Tuttavia a questo punto sorge un problema: nel tempo sono stati promulgati dagli
enti di standardizzazione (nazionali o internazionali) più modelli gestionali funzionali e,
conseguentemente, oggi si possono formulare più definizioni di «gestione di un sistema
TLC», ognuna basata su un modello diverso. Quindi, se vogliamo formulare un’ unica
definizione di «gestione di sistemi e servizi TLC» dobbiamo selezionare uno di questi
modelli e fare riferimento ad esso.
Per motivi di importanza storica, qui di seguito presentiamo uno dei primi modelli
funzionali standardizzati, estremamente popolare verso la fine degli anni ottanta,
chiamato modello FCAPS, (iniziali delle parole Fault, Configuration, Accounting,
Provisioning, Security) sviluppato dall’ International Standardization Organization
351
(ISO)/International Telecomunication Union-Telecommunications (ITU-T) nell’ambito
del modello OSI-SM (Open Systems Interconnection-System Management). Su questo
modello sono stati basati molti modelli successivi. Tuttavia si tenga sempre in mente che
questo è uno dei tanti possibili modelli gestionali: in altre sedi e in tempi più recenti si
sono adottati modelli diversi (anche modelli proprietari non standardizzati)
3.5.3 Modelli gestionali funzionali: il modello FCAPS dell’ ISO/ITU-T.
Il modello gestionale funzionale FCAPS, è stato introdotto con lo scopo di
specificare le funzioni gestionali (System Management Functions, SMF) necessarie a
gestire sistemi e servizi TLC. La sua struttura è mostrata nella Tavola 3.5.1. Come
mostrato nella Tavola 3.5.1 il modello prevede cinque aree funzionali (System
Management Functional Areas, SMFA) corrispondenti alle gestioni di Fault (Guasti),
Configuratione (Configurazione), Accounting (Amministrazione), Performance
(Prestazioni) e Security (Sicurezza). In dettaglio, le attività gestionali sono:
1. Gestione Configurazione. Adattare la configurazione delle risorse (rete, software
e hardware) ai bisogni/richieste dei clienti sia in fase di pianificazione/progetto di
una «classe di servizi» e.g. sulla base di analisi di mercato (gestione strategica) sia in
fase di fornitura di un servizio specifico ad un cliente che ne fa richiesta, servizio
customizzato all’Utente. (gestione customer care e operativa).
2. Gestione Prestazioni. Supervisionare e controllare le prestazioni del sistema
TLC affinché esse siano in accordo con la Qualita’ di Servizio (QoS, Quality of
Service) specificata in un contratto SLA stipulato da un cliente con il fornitore di
servizi,
3. Gestione Guasti. Supervisionare, identificare, generare gli allarmi e riparare i
guasti o malfunzionamenti che si verificano durante la fornitura dei servizi.
4. Gestione Amministrazione. Accudire gli aspetti amministrativi del sistema. Ad
esempio, misurare e contabilizzare l’utilizzo dei servizi, preparare e distribuire
le fatture (fatturazione) raccogliere i pagamenti relativi ai servizi forniti, registrare i
pagamenti e notificarne lo stato al servizio relazioni clienti e alla gestione business.
5. Gestione Sicurezza. Garantire la sicurezza delle comunicazioni supportate dal
sistema. Ad esempio impedire l’accesso al sistema a entità non autorizzate. Include
le procedure di autenticazione e autorizazzione
La Tavola 3.5.1 mostra come l’insieme delle attività gestionali sia strutturato
dall’ ITU-T in maniera gerarchica i.e. suddiviso in cinque aree funzionali SMFA e queste
a loro volta ulteriormente suddivise in ventitré gruppi di insiemi di funzioni gestionali,
(Management function set groups) laddove ogni gruppo comprendente un certo numero
di insiemi di funzioni (Management function set) per un totale di 260 insiemi. A sua
volta ogni insieme é suddiviso in funzioni di gestione atomiche cioé non ulteriormente
suddivisibili (System Management Functions, SMF). Quindi le funzioni di gestione,
352
SMF che nascono dopo aver suddiviso le aree funzionali in “gruppi di insiemi” e,
successivamente, in “insiemi”, sono al fondo della scala gerarchica e costituiscono i
building-blocks cioè i mattoni offerti dal modello FCAPS per effettuare la “costruzione”
di attività gestionali comunque complesse. (Vedi Parte II). In base a quanto detto, d’ora
innanzi parleremo di funzioni SMF contenute nelle cinque aree funzionali SMFA
(“modello FCAPS”).
3.5.4
I tecnoservizi di gestione (Management Services) forniti da una rete TMN
(Telecommunications Management Network)
Nel modello FCAPS dell’ITU-T le funzioni di gestione sono abilitate da “Reti di
Gestione” (e.g. rete TMN, Telecommunications Management Network) che operano
in parallelo alle reti U&S da gestire. Altrimenti detto: “le Reti di Gestione vengono
utilizzate dal Gestore per svolgere funzioni SMF per la gestione di sistemi e servizi TLC”
oppure, in una visione tecnocentrica, “ le Reti di Gestione forniscono tecnoservizi di
gestione (Management Services) al Gestore affinchè egli possa gestire sistemi e servizi
TLC”. Notare l’uso del termine “tecnoservizi” per evidenziare il fatto che i Management
Services sono forniti da Reti di Gestione cioè da tecnologie.
Un Management Service è un insieme coerente di funzionalità che una Rete di
Gestione (e.g. rete TMN) offre ai suoi utilizzatori (e.g. gestori di una rete U&S) per
soddisfare certi loro bisogni/esigenze di gestione. Un tecnoservizio di gestione si articola
in una molteplicità di funzioni SMF appartenenti a cinque aree SMFA. Ad esempio il
tecnoservizio di gestione “Gestione del Traffico” è supportato dalle funzioni SMF (o
loro aggregazioni in insiemi e gruppi di insiemi) mostrate in Fig.3.5.3 (spiegato in
dettaglio a lezione). La relazione fra Management Services e funzioni SMF o loro insiemi
è discussa in dettaglio nell’Appendice 1 della ITU-T Recommendation M-3400
353
Performance
Mngmt
Control
Performance
Monitoring
CONFIGURATION
Status & Control (SMFSG)
Network Traffic Management
Policy (*)
- Transport network status
10
CONFIGURATION
Provisioning (SMFSG)
1
- Inter-exchange circuit design
9
Traffic Control (4SMF)
8
3
4
6
Network fault event analysis
including correlation & filtering
- Traffic performance
monitoring (12SMF)
-Traffic status (9SMF)
Traffic Administration
(5SMF)
5
Execution of Traffic Control (*)
FAULT
Alarm Surveillance (SMFSG)
2
7
SEGNALAZIONE DI SOVRACCARICO
Detection, counting,
storage & reporting (*)
Fig. 3.5.3 Potenziale scenario per “Controllo Traffico di Rete” (parte di un Servizio di Gestione
“Gestione di Traffico”). Aree Funzionali: Performance (Bordo continuo), Fault e Configuration
(Bordo tratteggiato). Gruppi di insiemi: Performance Management Control (giallo), Performance
Monitoring (verde). L’asterisco indica assenza di MF in ITU-T Recom M.3400.
354
3.5.5
Il modello FCAPS rappresentato graficamente come suddivisioni verticali
che attraversano tutti gli strati orizzontali del cubo TMN (Fig.3.5.5.1)
Il modello di gestione FCAPS é indipendente dal modello TMN stratificato
precedentemente rappresentato in Fig. 3.4.1 con una serie di strati orizzontali. Infatti il
modello FCAPS si riferisce al « come » si deve effettuare la gestione di un sistema TLC
mentre il modello TMN stratificato si riferisce al « cosa » deve essere gestito.
Ogni area funzionale comprende funzioni di gestione applicabili in ogni livello
del modello TMN stratificato. Quindi, simbolicamente, le cinque aree funzionali FCAPS
possono essere rappresentati come mostrato in Fig. 3.4.1 come cinque ripartizioni o
suddivisioni verticali nello stesso cubo. Notare che riserviamo la terminologia «strato»
per le suddivisioni orizzontali.
Nella figura 3.4.1 é importante notare come una ripartizione verticale attraversi
tutti gli strati orizzontali cioé, come già detto, una singola area gestionale FCAPS
implichi attività ai vari livelli di astrazione: livello elemento di rete, rete, servizi e
business. Ad esempio, l’attività relativa all’area gestionale “amministrazione” non si
svolge solo a livello di gestione di rete ma implica :
1)
A livello rete: raccolta dei dati gestionali in punti specifici della rete
(Data Collection Points) e la tabulazione di questi dati in Connection
Data Records (CDR) che costituiscono la base per addebitare ai vari
clienti costi commensurati con l’utilizzazione dei servizi,
2)
A livello servizi: i) fatturazione (Billing) formulata sulla base dei CDR
inviati dal livello rete e delle tariffe inviate dal livello business, ii)
distribuzione delle fatture, raccolta/registrazione dei pagamenti
effettuati dagli utenti.
3)
A livello impresa: formulazione delle tariffe (da utilizzare nel processo
di billing a livello servizi) effettuata in base alle politiche/strategie
aziendali, alle condizioni di mercato e alla luce della concorrenza
presentata da sistemi TLC competitivi. Questa parte non sara’ oggetto
di studio in questo corso di lezioni.
355
Fault
• Alarm policy
Configuration
• Material mngmt. policy
• Repair process mngmt. • Provisionig policy
• Test policy
B
M • Trouble report policy
L
• Service test
• Trouble reporting to
customer
S
M
L
• Trouble information
query
N
M
L
• Priority service policy
• Arrangement of
installation with
customer
• Customer need
identification
• Ntwk installation
administration
• Ntwk fault localization
• Access circuit
design
• NE alarm reporting
• Alarm summary
• Alarm indication
mngmt.
• Investigation
change
• Performance minitoring • Security
policy
• Feature pricing
• Totaling usage charge
• Service usage
correlation
• Customer performance
reporting
• Customer traffic
performance summary
• Usage validation
• Ntwk fault event
correlation & filtering
• Circuit selection
for test
Performance
• Ntwk performance
goal setting
• Exception threshold
policy
• Customer service
feature definition
• Trouble ticket
administration
E
M
L
• Procurement guidelines • Pricing strategy
• Trouble ticket
notification
• Test suite selection
Accounting
• Usage measurement
process mngmt.
• Usage data storage
• Ntwk connection
mngmt.
• NE installation
administration
• NE fault localization
• Loading program for
service features
• Log control
• NE database mngmt.
• NE test circuit
configuration
• Generate NE status
& control
• Customer
administration
• Data aggregation
& trending
• Internal
pattern
• Traffic control
• Ntwk
• Traffic capacity analysis • Severing
connection
• Ntwk performance
• Leased circuit design
• Loading NE software
• Customer
pattern
• Service
recovery
• Usage aggregation
• Ntwk usage correlation
• Customer
characterization
• Ntwk
• Ntwk
mngmt
• Usage data collection
• NE trend analysis
• NE usage data
validation
• NE traffic performance
analysis
• Usage accumulation
• NE performance control
• NE
mngmt
• NE
• NE performance
analysis
• NE traffic capacity
analysis
• NE fault correction
Fig.3.5.5.1 Sovrapposizione del modello FCAPS e del modello TMN stratificato. Vedi H.Wang, “Telecommunications
Mc-Graw Hill, 1999, pag. 235
356
Network Management”,
CAPITOLO 4
Gestione dei servizi TLC (4h)
4.1 Ambiente Business: Stakeholders e Risorse
4.2 Business Stakeholders
4.3 I contenuti dei servizi TLC
4.4 I servizi TLC
4.5 Modelli di servizi TLC: Modello MNM per funzioni
4.6 Modelli di servizi TLC: Modello processuale TMF
357
CAPITOLO 4
Ambiente Business: Gestione dei servizi TLC
4.1
Ambiente Business: Stakeholders e Risorse
4.1.1
Una tassonomia dei Business Stakeholders (Fig.4.1.1.2) e loro relazioni di
business (Fig.4.1.1.4)
In questo Capitolo ci occuperemo dei servizi TLC, già definiti nel par. 1.0.3 del
Cap.1, servizi forniti/acquisiti e erogati/fruiti da certi Business Stakeholders in un
Ambiente Business. (laddove il termine “Business” è stato definito nella Tavola 1.3.1.2
e l’ “Ambiente Business” è la vista del mondo TLC allorché osservato da un Punto di
Vista Business). Tuttavia queste non sono le sole attività che si svolgono in un Ambiente
Business. Ad esempio, come mostrato in Fig, 1.0.1.4, esistono i mercati di compravendita delle Tecnologie ICT o dei contenuti dei servizi TLC. Allora prima di tutto
vogliamo completare il quadro e vedere come in un Ambiente Business i servizi TLC si
posizionano rispetto a tutte le altre attività svolte da Business Stakeholders.
•
Stakeholders in Ambiente Business
Riprendiamo le fila dall’inizio. Allorchè si osserva la società reale di riferimento
da un Punto di Vista TLC (vedi Appendice 4 al Capitolo 1) si visualizzano TLC
stakeholders in possesso di funzionalità TLC e attori TLC che attuano queste
funzionalità nello svolgimento di funzioni TLC. Se il Punto di Vista TLC si specializza
al settore Business (Tavola 1.3.1.2) si evidenziano le caratteristiche di Business
Stakeholders che svolgono funzioni di Business utilizazando opportune Risorse TLC.
(vedi Fig.4.1.1.1).
Ad esempio, supponiamo di osservare una impresa reale TelCo, proprietariooperatore di reti TLC e fornitore di servizi TLC a una comunità di Utenti finali (la TelCo
factotum descritta nel Cap.1!). Si tratta di una persona giuridica reale Allorché osservata
da un Punto di Vista Business essa viene messa a fuoco come un “TLC Service Provider
(SP)”. Alternativamente noi diciamo che un SP è la Vista Business di una TelCo reale.
Analogamente diciamo che un Cliente è la Vista Business di un Utente reale.
358
RISORSE e TECNOLOGIE abilitanti i servizi TLC
Risorse TLC fisiche
logiche e energetiche
Tecnologie ICT
(SISTEMA TLC)
Risorse umane
Persone fisiche
(e.g. Addetti ai
processi gestionali
manuali in una TelCo)
Funzionalità
Punto di
Vista
Interconnessione,
Distribuzione
Intermediazione.
Accesso
(Reti)
(Terminali)
nonTLC
nonTLC
TLC
Tecnologie
implementative
Business
Engineering
Componenti
ausiliari nonICT
Sorgenti
energia,
Impianti,
Air-cond,
etc.
Componenti ICT
X
Reti
U&S
Reti di
Gestione
(Sistema
Informatico
Gestionale)
(e.g. rete
postale)
TLC
(e.g. sportello
postale o
bancario)
Rete autoferroviaria
Trasporto
aereo
Struttura
Meccanica
Terminale
TLC
Struttura
meccanica
sportello
postale o
bancario
Sistema
informatico
rete postale
X
Sistema
informatico
sportello
postale
Risorse
RisorseTLC
TLC
Terminali
U&S
Terminali
di Gestione
Tecnologie
TecnologieICT
ICT
Bus Eng relation
Fig.4.1.1.1 I componenti ICT osservati da un Punto di Vista Business sono visualizzati come
Risorse TLC
Analogamente, consideriamo una impresa reale ICTS che effettua progettocostruzione e commercializzazione-vendita di Tecnologie ICT. Anche in questo caso si
tratta di una persona giuridica reale. Allorché osservata da un Punto di Vista Business
essa viene messa a fuoco come un Venditore di Tecnologie ICT (ICT Vendor).
Alternativamente noi diciamo che un ICT Vendor è la Vista Business di una ICTS reale.
NOTA 4.1.1 Le stesse imprese reali osservate da altri Punti di Vista e.g. un Punto di Vista
Engineering, sarebbero riconosciute rispettivamente come un Operatore di Rete, Network Operator
(NO) e un Progettista-Costruttore di Tecnologie ICT (ICT Designer & Builder o ManTec,
Manufacturer of ICT Technology). Quindi applicando la metodologia dei Punti di Vista e adottando i
Punti di Vista Engineering e Business, noi diciamo che una impresa reale TelCo è rappresentata con
due Viste i.e. SP e NO. Se, come suggerito in Appendice 4 al Cap.1, continuassimo il processo di
osservazione/rappresentazione della TelCo adottando ulteriori Punti di Vista (e.g. aggiungendo i
Punti di Vista “Leg-reg” o “Social”) otterremmo rappresentazioni della TelCo con un numero
crescente di Viste, rappresentazioni forse più complete ma anche più complicate.
359
Business
Environment
( Partial )
Hierarchies
BUSINESS
BUSINESS STAKEHOLDER
STAKEHOLDER
BA .00
SPECIALIZATION
“ is a ”
TLC R&D and Tech .
TLC R&D Actor
and Tech
Innovation
(*) .
Innovation
Actor
( Administrator
) (*)
( Administrator )
ICT Vendor
Vendor
( ICT
ICTS*
)
( ManTec* )
BA .11
ICT Assesment &
ICT
Assesment &
Forecasting
Forecasting
Actor (*)
Actor (*) )
( Administrator
( Administrator )
BA .15
TLC Service Provider
TLC Service
( TelCo* )Provider
( TelCo* )
BA .12
1
BA .17
TLC
TLC /
Investor
Investor /
Funder
Funder
End - Customer
End -Customer
BA .16
Content Provider
Content Provider
BA .14
BA .13
Government
Government
/
Institution
/
Institution
Agency
(*)
Agency (*)
BA .18
Manuf .
Manuf .
Facility
Facility
Based
Based
Reseller
Reseller
Interme Interme
diary
diary
Retailer
Retailer
Sells to
Retailer
OEM
OEM
Sells to
EU
Integrator
Integrator
Equipment
Equipment
IDM ( ° )
IDM ( ° )
Foundry
(“Foundry
Fab ” )
( “ Fab ” )
Device
Device
“ Fabless ” Co.
“ Fabless ” Co.
(chip
design)
(chip design)
OEM = Original Equipment
Wholesaler
Wholesaler
(Facility
( Facility
)
Based
Based )
Strategic
Strategic
Basic
Basic
Research
Research
Applied
Applied
R&D
R&D
New
New /
Process
Process /
Product
Product
Dvlpmnt
Dvlpmnt
Sells to : Integrator
Intermediary ,
Retailer ,
End User (EU)
System
System
Pure
Pure
Basic
Basic
Research
Research
IP Con IP Con sumer
sumer
Retailer
Retailer
Intermediary
Intermediary
Reseller
Reseller
Broker
Broker
Consu Consu
mer
mer
MediaCo (*)
MediaCo (*)
nonTLC Profes .
nonTLC
Profes(*).
Service
Provider
Service Provider (*)
Rep.
Rep.
Ntwk
Ntwk
Operator
Operator
Ntwk Facility
Ntwk
Facility
Based
Based
News &
News &
Education
Education
Reseller
Reseller
(
Device Manufacturer
Internat . Org .
Internat . Org .
SME
SME
Service C
C
(e.g. Service
radio/TV)
(e.g. radio/TV)
Mobile
Mobile
° )IDM = Integrated
Private
Private
SOHO
LE
LE
Service B
B
(e.g.Service
internet)
(e.g. internet)
Public
Public
2
National
National
Digital
Digital
Services
Services
Service A
A
(e.g. Service
telephone )
(e.g. telephone )
(*) External Business Vista
Govern Govern ment
ment
Enter Enter tainment
tainment
Wholesale
Wholesale
Service
Service
Provider
Provider
Central
Central
Bank
Bank
Sec. & Exch .
Sec.
& Exch .
Com.
Com.
Private
- profit
NonPrivate
-.
Non
Orgprofit
Org .
Busi Busi ness
ness
Agent
Agent
Wireline
Wireline
Manufacturer
Finance
Finance
Dept .
Dept .
Corporate
Corporate
Capital
Investor
Capital Investor
Equity Owner
Equity Owner
Lender
Lender
Shareholder
Shareholder
Bus Eng Relation PdS 25/10/2007
Fig.4.1.1.2 Tassonomia di Business Stakeholders. In questo corso ci occuperemo solo di alcuni Stakeholders residenti nei primi due livelli di
specializzazione (zone blù e gialla). Le relazioni di business che intercorrono fra questi Stakeholders sono mostrate in Fig.4.1.2
360
3
Bank
Bank
4
5
TLC MARKETS BUSINESS RELATIONSHIPS (First Level)
MM
Content
Content
Provider(*)
Provider(*)
MC
IM
BA.14
BA.14
MT
SERVIZI TLC
CC
TT
TelCo
TelCo
End-Customer
End-Customer(*)
(*)
BA.16
BA.16
TC
TelCo
TelCo(*)
(*)
Transport/Access
Transport/Access
Service
ServiceProvider
Provider
AFT
RTIT
TLC
TLCR&D
R&Dand
and
Tech.
Tech.Innovation
Innovation
Actor
Actor
VT
BA.15
BA.15
AFV
VC
TLC
TLCInvestor
Investor
BA.18
BA.18
BA.13
BA.13
ICT
ICTAssesment
Assesment
&&Forecasting
Forecasting
Actor
Actor
II
IT
BA.12
BA.12
RTIV
ICT
ICTVendor
Vendor(*)
(*)
( (IC
ICTechnology
Technology
Supplier)
Supplier)
BA.11
BA.11
IV
VV
Bus Eng Relation. PdS 26/10/2007
Fig.4.1.1.3 Relazioni di business fra alcuni Stakeholders del primo livello mostrati in Fig.4.1.1 e
potenziali mercati TLC.
Queste considerazioni possono estendersi a tutti i Business Stakeholders che
esistono nella società reale di riferimento: “chi” sono e quali sono le relazioni di Business
che li legano mutuamente? La Fig. 4.1.1.2 mostra i primi 5 livelli di specializzazione di
una possibile tassonomia di Business Stakeholders residenti nell’Ambiente Business (i
vari alberi gerarchici sono spiegati in dettaglio a lezione, vedere anche par.4.2). Nel
primo livello (massima astrazione e minima specializzazione) si riconoscono nove tipi di
Business Stakeholders. In Fig.4.1.1.3 sono mostrate le possibili relazioni di business
(opportunità di Business) fra Stakeholders a vari livelli. Come si posizionano questi vari
tipi di Business Stakeholders rispetto al sistema TLC? Cioè come visualizzano essi un
sistema TLC? La risposta è che ogni Business Stakeholder visualizza il sistema TLC e i
suoi componenti da un suo Punto di Vista parziale alla luce delle sue conoscenze/interessi
e ne crea una sua propria Vista.
La Fig. 4.1.1.4 mostra come il Punto di Vista Business possa essere decomposto
in un certo numero di Punti di Vista parziali (come già fatto per il Punto di Vista
Engineering nel Capitolo 2) e così si possano creare una varietà di Viste parziali.
361
Punto di Vista Business
SP/
Customer
ICT Vendor/
Buyer
ContCo/
Buyer
Investor
Punti di Vista
Parziali
dei Business
Stakeholders
SISTEMA TLC & SUOI COMPONENTI
TLC
Resource
Trading
Product
Container
Investment
Opportunity
Punto di Vista adottato
nel Capitolo 4
Viste
parziali
Persona decomp
Fig. 4.1.1.4 In un Ambiente Business il sistema TLC reale e i suoi componenti sono viste in varie
maniere a seconda del Punto di Vista parziale adottato. Ma i componenti ora non sono distinti in
componenti TLC (Tecnologie ICT) e componenti nonTLC perché gli osservatori Business sono privi
delle necessarie conoscenze/interessi tecnici. Qui i Punti di Vista parziali sono i Punti di Vista di
quattro gruppi di Business Stakeholders scelti dal livello 1 della Fig.4.1.1.2
•
Vista Business del sistema TLC e suoi componenti
Studieremo noi tutti questi casi? Certamente no! In questo Capitolo noi
adotteremo il Punto di Vista Business/SP-Cliente. Quindi qui per noi il sistema TLC e i
suoi componenti sono Risorse TLC (o Risorse Business) atte a supportare servizi TLC.
Ad esempio per la coppia SP-Cliente un telefono cellulare è una Risorsa TLC necessaria
per telefonare in mobilità. Tuttavia essi adottano un Punto di Vista Business e quindi per
mancanza di conoscenze/interessi non distinguono una parte ICT e.g. rice-trasmettitore e
una parte nonICT e.g. involucro di metallo e plastica, batteria etc. Se ne guardano bene!
Quello che interessa loro non sono caratteristiche tecnologiche. Sono altre caratteristiche
che li interessano e.g. prezzo, peso, ingombro, disponibilità sul mercato, disponibilità di
servizi di assistenza tecnica post vendita etc (vedi Tavola 4.1.1). Per gli altri Punti di
Vista parziali ci limitiamo ad osservare quanto segue:
Punto di Vista “ICT Vendor-Buyer”
Un ICT Vendor o un Compratore (Buyer) “visualizzano” un sistema TLC
reale o un suo componente come Merce ICT o Prodotti ICT oggetto di compravendita in un mercato delle tecnologie ICT. Anche questa Merce si classifica in
Merce ICT e Merce nonICT di natura generica ma da utilizzarsi per scopi TLC. Ad
esempio se un Vendor di tecnologie spaziali osserva un Communication Payload di
362
un satellite geostazionario “vede” ricevitori, trasmettitori e antenne che sono oggetto
di compra-vendita in certi mercati, ad un certo prezzo, con certi tempi di produzione/
consegna, da costruire “custom made” o disponibili “off-the-shelf” e certi limiti di
esportazione a paesi terzi (e.g. apparecchiature di interesse militare). Sono tutte
caratteristiche rilevanti a processi di compra-vendita e quindi importanti in un
contesto commerciale (vedi Tavola 4.1.1).
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
18)
19)
20)
21)
22)
banda di frequenza di funzionanamento
capacità di memoria
consumo energetico
RF power handling capability (ingresso/uscita)
end-to-end latency (ritardo di segnale)
jitter (variazione ritardo di segnale)
RAS (Reliability, Availability, Survivability)
peso
volume (dimensioni)
livello di radiation hardening (*)
disponibilità Off-The-Shelf (soluzione “buy”) (**)
disponibilità ManTec (soluzione “build”) (**)
limitazioni su trasferimenti di tecnologia dal paese d’origine
nome e località del fornitore scelto
tempo di inizio e durata del contratto (soluzione “build”)
tempi di consegna
costo totale del prodotto finito
profilo temporale dei pagamenti
piano di finanziamento
costo di installazione, manutenzione, disinstallazione
disponibilità di assistenza tecnica post vendita
amichevolezza di utilizzazione (e.g.terminali)
(*) Per applicazioni spaziali
(**) Fornitori alternativi in “multi-source procurement”
Tavola 4.1.1 Esempio di caratteristiche di un componente ICT di un sistema TLC
osservato da un Punto di Vista Business (Risorsa TLC). Un SP (Buyer)
o un ICT Vendor sono interessati a queste caratteristiche.
Punto di Vista “ContCo-Buyer”
Per una ContCo, impresa fornitrice di contenuti per servizi TLC, un sistema
TLC reale (specialmente una rete TLC di distribuzione) è un contenitore/veicolo di
informazione (e.g. notizie, intrattenimento, pubblicità) fornita a una comunità di
milioni di spettatori e, quindi, utilizzabile come palcoscenico pubblicitario aperto su
milioni di potenziali clienti. Talvolta la ContCo è una MediaCo che fornisce
(ovviamente a pagamento) sia i contenuti che il “contenitore/veicolo” e.g. canali
televisivi (e.g. Mediaset).
Punto di Vista “Investor”
363
Un finanziatore di sistemi TLC o suoi componenti (“Investor”) è interessato a
finanziare il loro acquisto e li visualizza come “opportunità di investimento” dal quale
ottenere ritorni soddisfacenti commensurati ai relativi rischi economici. Il
finanziamento può assumere la forma di acquisto di azioni nel caso la impresa
telecom sia quotata in borsa (in tal caso il finanziatore diviene “azionista”,
shareholder)
4.2 Business Stakeholders
In questo paragrafo facciamo riferimento ai due alberi di Fig.4.1.1 le cui radici
sono “TLC Service Provider” (BA.13) e “End Customer”(BA.16)
PRODUTTORI/FORNITORI di TECNOLOGIE ICT
4.2.1
ICT Wholesale Vendor (ManTec)
Questo stakeholder è una impresa ManTec, Manufacturer of ICT Technology
che effettua manifattura e vendita all’ingrosso di componenti di sistema TLC realizzati
principalmente con Tecnologie ICT sia hardware che software (“Sviluppatori di
software”). Sono industrie che effettuano la specifica, progettazione, costruzione, testing
(in breve, la “produzione”) e vendita di componenti ICT sulla base della domanda di
potenziali utilizzatori (TelCo e utenti finali). Queste industrie manifatturiere non hanno
una rete commerciale di distribuzione al dettaglio per vendere i loro prodotti
(specialmente quando questi prodotti sono il risultato di produzione di massa o grande
serie e.g. produzione di terminali come telefoni o computers). Questa attività viene
invece svolta dai “Rivenditori” (Resellers) che svolgono attività di compra-vendita
prettamente commerciali e interfacciano direttamente con gli utilizzatori finali (Vedi qui
sotto). A sua volta una impresa ManTec può costruire Tecnologie ICT partendo dalle
materie prime (Original Equipment Manufacturer, OEM) oppure può essere un
Integratore che assembla i componenti acquistati da un OEM per produrre nuovi
componenti ad un più alto livello di integrazione.
4.2.2
ICT Retail Vendor (ManTec o Reseller).
Un venditore di Tecnologie ICT al dettaglio può essere esso stesso una industria
manifatturiera di tecnologie ICT che possiede una rete di distribuzione commerciale
oppure può essere una impresa esclusivamente di carattere commerciale che compra
tecnologie ICT all’ingrosso e le rivende agli utilizzatori finalli. (Reseller).
PRODUTTORI/UTILIZZATORI di SERVIZI TLC
4.2.3 Wholesale Service Provider (TelCo Wholesaler)
Nel mondo TLC reale una TelCo Wholesaler (letteralmente “TelCo grossista”
in italiano) è un TLC stakeholder che possiede/gestisce le reti TLC e fornisce servizi TLC
all’ ingrosso ad altre Telco in un “canale di distribuzione” che, passando attraverso
364
varie TelCo si estende fino alla comunità di Utenti finali che utilizzano i servizi TLC per
proprio uso e consumo.
Il ruolo “Wholesaler” è svolto da una TelCo che offre le funzionalità delle sue
reti TLC a clienti esterni sottoforma di fornitura di servizi TLC all’ingrosso (wholesale
TLC services) senza tuttavia occuparsi di attività di marketing e accudimento dei singoli
Clienti finali (“Customer Care” o “Customer Relation Management, CRM”) che
rimangono target dei Rivenditori al dettaglio (TelCo Retailers).
Nei servizi TLC all’ingrosso vengono forniti “blocchi” di capacità (“bulk
capacity”) e.g. blocchi (bundles) di canali d’utente che vengono poi disassemblati e
opportunamente “confezionati” prima di essere venduti ai singoli utenti finali dalle
TelCo Retailer. In tal caso la TelCo Wholesaler non solo fa prezzi scontati ai suoi clienti
(la vendita all’ingrosso diminuisce il rischio di rimanere con capacità invenduta e non
richiede particolari risorse di marketing essendo il numero dei clienti limitato) ma,
essendo essa di fatto l’esperto delle tecnologie di rete, può fornire alle sue Telco clienti
anche tutte le informazioni sulla gestione di rete di cui esse hanno bisogno e.g. attraverso
un accesso diretto ai suoi sistemi gestionali di supporto OSS. Questo significa che la
nostra TelCo Wholesaler non solo possiede le tecnologie di rete e un grosso know how
tecnologico relativo alla loro gestione, ma al tempo stesso dispone di sistemi di supporto
OSS molto sofisticati capaci di soddisfare le richieste di TelCo clienti molto esigenti
esperte in telecomunicazioni (molto diverse dagli Utenti finali del tipo consumer, che
generalmente sono ignoranti di telecomunicazioni e infatti non amano conoscere le
problematiche di natura tecnologica interne dei gestori di rete).
NOTA 4.2.3.1 E’ importante notare la differenza fra un wholesaler di servizi TLC, come definito in questo
corso, e un grossista di beni materiali. Infatti quest’ultimo compra all’ingrosso beni materiali (i.e. grosse
quantità di beni per volta) da un produttore di beni, li immagazzina opportunamente, poi li suddivide in
piccoli lotti che rivende ai dettaglianti,i quali a loro volta vendono i singoli beni agli utilizzatori finali.
Questo sdoppiamento produttore-grossista è assente in molti casi di TelCo wholesaler, che, invece gioca
egli stesso anche il ruolo di produttore di servizi TLC possedendo e gestendo l’infrastruttura tecnologica
necessaria alla loro fornitura. Questa infrastruttura, e.g. reti TLC + OSS in generale richiede un grosso
investimento di capitale iniziale.
Le TelCo clienti esterne di una TelCo Wholesaler possono essere o TelCo
Retailers oppure TelCo Intermediary che forniscono esse stesse servizi TLC a Telco
Retailers. Questa parte del sistema di distribuzione del valore relativa ai servizi TLC
viene anche chiamata “catena o canale di distribuzione dei servizi TLC”.
Un canale di distribuzione dei servizi TLC è una catena produttore-consumatore
costituita da Telco mutuamente relazionate da relazioni di business di vario tipo. Esso
inizia dal Wholesaler che è proprietario di grosse quantità di risorse TLC e finisce con
l’Utente finale che utilizza i servizi TLC fornitigli da un dettagliante (TelCo Retailer)
che, ripetiamo, a differenza della TelCo Wholesater, possiede grosse risorse di marketing
adatte alle vendite al dettaglio. Quindi in generale il canale di ditribuzione fra TelCo
Wholesaler e TelCo Retailer è popolato da una moltitudine di Telco intermediari che
mutuamente si forniscono/acquisiscono servizi TLC.
365
Un canale di distribuzione costituito da diverse Telco relazionate da relazioni di
business viene anche chiamato un “canale indiretto” (“indirect channel”) per
distinguerlo da un “canale diretto” dove non esistono intermediarii e un' unica Telco
effettua sia la produzione/vendita che la distribuzione al dettaglio di servizi TLC. Il
canale di distribuzione diretto è tipico di un mercato regolamentato monopolista (dove
un'unica impresa fa tutto!).
ESEMPIO 4.2.3.1 “Blocco di capacità”(bulk capacity) nelle TLC satellitari.
Nelle telecomunicazioni satellitari un esempio di “blocco di capacità” è costituito da un
“trasponditore” (“transponder”). Ad esempio un fornitore di servizi TV al dettaglio (e.g. Sky TV)
può acquisire un intero transponditore dal proprietario/gestore/operatore del sistema satellitare (e.g.
EutelSat). Un “trasponditore” corrisponde a valori predeterminati di “capacità” caratterizzata da
una certa larghezza di banda (e.g. 27 MHz) e una certa potenza RF di downlink (e.g. 40-50 dBW).
La potenza di downlink è misurata come EIRP di downlink, laddove EIRP = Equivalent Isotropic
Radiated Power è dato dalla potenza di entrata all’antenna di bordo trasmittente aumentata dal
guadagno di antenna. L’EIRP è quello che poi determina le dimensioni delle antenne TV sui tetti
delle nostre case. Con le odierne tecniche di compressione di canali digitali un transponditore può
accomodare ad una molteplicità di canali TV.
4..2.4
Intermediari: brokers o agenti.
Esempi di Telco intermediarie presenti in una catena di distribuzione di servizi
TLC sono i “facility-based intermediaries”, i “brokers” e gli “agenti”. Ogni intermediario,
da un lato acquisisce servizi TLC mentre da un altro lato fornisce servizi TLC a Telco.
Gli intermediari si distinguono a seconda se sono proprietari di risorse di
telecomunicazione o meno.
1) Qualche intermediario (“facility-based intermediary”) possiede risorse di
telecomunicazione aggiuntive rispetto al wholesaler (e.g. possiede reti di accesso mentre
il wholesaler possiede solo reti di trasporto) le cui funzionalità egli aggiunge a quelle
possedute dai servizi acquisiti. Dal punto di vista dell’Utente finale si può anche dire che
egli fornisce nuovi servizi ottenuti “aggiungendo valore” ai servizi TLC acquisiti dal
wholesaler.
2) Altri intermediarii sono “brokers” o “agenti”. Si tratta di semplici rivenditori
di servizi (“resale intermediary” o “reseller”) che comprano servizi TLC all’ingrosso
(a prezzi scontati per il volume) e li rivendono al dettaglio.
Più precisamente i “brokers” facilitano transazioni di business fra parti senza
tuttavia assumersi responsabilità di alcun tipo. Gli “Agenti” sono rappresentanti di un
fornitore di servizi, con o senza esclusività, e possono svolgere funzioni di aggiunta di
valore ai servizi TLC forniti loro dal wholesaler senza tuttavia possedere alcuna risorsa di
telecomunicazione, e.g. gestione di accounting, supporto clienti etc.
4.2.5 Retail Service Provider (TelCo Retailer)
Una impresa TelCo Retailer interfaccia direttamente con vaste comunità (milioni
nel caso di utenze consumer) di Clienti finali cioè clienti che fruiscono di servizi TLC
366
per proprio esclusivo uso senza rivenderli ad altri utilizzatori e che, nel caso di utenti
consumer, sono piuttosto ignoranti delle tecnologie TLC. Al contrario della TelCo
Wholesaler la TelCo Retailer svolge attività di business con una forte enfasi sull’
accudimento degli utenti (customer care) e sul marketing dei servizi. Le TelCo Retailer
sono caratterizzate da:
i) una fitta rete di punti di vendita dispersi sul territorio dove aspiranti
sottocrittori di servizi TLC possono recarsi per ottenere abbonamenti ai servizi TLC al
dettaglio e/o acquistare apparecchiature terminali per usufruire di questi servizi e.g. i
punti di vendita di servizi/apparecchiature terminali per telefonia fissa o cellulare o di
televisione via satellite. Spesso la TelCo Retailer non è proprietaria dei punti di vendita
ma si avvale a sua volta di dettaglianti generici molto diffusi sul territorio (supermercati,
catene di negozi, negozi etc.)
ii) esecuzione degli allacciamenti degli utenti alla rete TLC e.g.
installazione/puntamento di antenne satellitari o allacciamento alla rete PSTN per servizi
di telefonia fissa,
iii) gestione delle relazioni con i clienti (Customer Care o Customer Relation
Management, CRM) e.g. effettuare la fatturazione degli addebiti e la raccolta dei
pagamenti relativi ai servizi fruiti, fornire su richiesta dati statistici di funzionamento
relativi ai servizi erogati, fornire servizi post-vendita come assistenza tecnica tramite call
centers e/o invio di Personale specializzato nei siti di utenza per riparazioni guasti, etc.
4.2.6 Cliente, Utilizzatore, Utenza
•
Cliente (Customer)
Facciamo riferimento ad una organizzazione commerciale o ad un ente
governativo (persona giuridica) nel ruolo di Cliente di una TelCo e.g. consideriamo
l’Università di Roma-Tor Vergata come Cliente di Telecom Italia per servizi fissi di
telefonia vocale & internet. Una persona fisica o giuridica reale che ha desiderio/bisogno
di telecomunicare sceglie un determinato servizio TLC fra una serie di servizi disponibili
sul mercato (in un libero mercato per uno stesso tipo di servizio esistono infatti diversi
fornitori, prezzi, qualità, condizioni di pagamento etc.) e diventa un Cliente di una certa
TelCo allorchè acquisisce da essa un servizio TLC, in generale sottoscrivendo un
contratto denominato contratto SLA (Service Level Agreement) nel quale sono
specificati i termini e le condizioni (terms & conditions) relativi alla fornitura/erogazione
del servizio TLC prescelto. Talvolta il termine “Cliente” è sostituito dal termine
equivalente di “Sottoscrittore” (“Subscriber”). Il termine Italiano “Abbonato” invece
non è del tutto equivalente a “Cliente” se per “Abbonato” si intende una persona fisica o
giuridica che acquisisce un servizio TLC e fa pagamenti mensili fissi (cioè paga un
abbonamento mensile fisso a fronte di un consumo illimitato).
367
•
Cliente titolare di una Utenza
Una persona reale nel ruolo di Cliente di una TelCo è anche titolare di un
“Utenza”. Nel caso in cui questa persona reale sia una organizzazione commerciale o un
ente governativo l’Utenza è denominata rispettivamente Utenza Affari (o Utenza
Business) o Utenza Governativa. Nel caso in cui la persona reale sia un privato cittadino
che non utilizza i servizi TLC per scopi di business ma per altri suoi scopi personali
l’Utenza è denominata Utenza Consumer. In generale le Utenze possono essere
classificate in base a criteri diversi e.g. numero di Utilizzatori di servizi TLC all’interno
dell’Utenza, posizione geografica, caratteristiche demografiche degli utilizzatori (età,
sesso, professione etc).
•
Utenza: Vista interna con Utilizzatori
Una Utenza è caratterizzata da una “vista” interna ed una vista esterna a seconda
che un osservatore metta a fuoco le sue caratteristiche interne o esterne. Nel caso di una
Utenza Affari o Governativa la vista interna (in Inglese, Customer Premise) mostra una
struttura organizzativa con diverse unità che esplicano attività amministrative legate al
ruolo di Cliente (e.g. uffici, sezioni, dipartimenti in varie “funzioni aziendali” e.g.
finanze, acquisti, marketing, relazioni esterne etc). Queste unità organizzative possono
risiedere in edifici geograficamente separati ma essere interconnesse da opportune reti di
telecomunicazione interne con topologie dipendenti dalla particolare struttura
organizzativa (e.g. VPN “corporate networks” in imprese commerciali o anelli di
interconnessione LAN in fibra ottica FDDI, Fiber Distributed Data Interface, in campus
universitari USA)
La vista interna di un Utenza mostra anche un insieme di risorse tecnologiche
abilitanti la fruizione dei servizi acquisiti (Customer Premise Equipment, CPE) e.g.
telefoni, computers, stampanti, wireline o wireless Local Area Networks, LAN, reti di
interconnessione di LAN, etc. Le tecnologie CPE interne alle Utenze, come pure le
tecnologie di rete U&S (Utilizzazione & Segnalazione) possedute/gestite dalla TelCo,
costituiscono la parte “gestita” del sistema TLC (vedi 1.0.3.6)
Le tecnologie CPE sono utilizzate da persone fisiche autorizzate/abilitate a
fruire dei servizi TLC all’interno dell’Utenza e.g. i professori dell’Università Roma-Tor
Vergata sono autorizzati/abilitati a fare telefonate dai telefoni installati nei loro uffici.
Queste persone fisiche quando fruiscono dei servizi TLC svolgono il ruolo di
“Utilizzatore finale” (End-User). L’insieme delle tecnologie CPE sotto il controllo
degli uffici amministrativi è anche denominato un dominio amministrativo (Vedi anche:
ITU-T Recommendation G.803, 03/2000, pag.2).
In generale il ruolo di Utilizzatore finale viene svolto allorchè una persona fisica
utilizza un servizio TLC nella sua “essenza” (“servizio di rete” erogato dal Network
Operator) esclusivamente per proprio uso e consumo senza trasferirlo ad una terza
parte. Gli Utilizzatori finali si limitano ad usare l’equipaggiamento CPE a loro
368
disposizione per telecomunicare senza occuparsi della sua gestione. Infatti
l’equipaggiamento CPE è costituito da tecnologie ICT gestite da personale specializzato
(addetti alla gestione) con il supporto di sistemi gestionali ad hoc (e.g. LAN Management
System). Gli addetti alla gestione fanno capo ad una unità organizzativa interna
all’Utenza (e.g. Dipartimento o Sezione) denominata “Information System
Management, ISM”. Il sistema informatico ISM che essi utilizzano è interno all’Utenza
(e.g. proprietà del Cliente) e noi, in questo corso, lo consideriamo sistema di supporto alla
gestione delle tecnologie CPE e parte dello stesso sistema TLC (gestione del primo
ordine, vedi 1.0.1.11). In generale in questo corso noi assumiamo che i sistemi
informatici gestionali (“sistemi di supporto”) abilitanti la gestione del primo ordine dei
sistemi gestiti U&S (Utilizzazione e Segnalazione) sia dal lato TelCo che dal lato Utente
facciano parte del sistema TLC stesso (vedi 1.0.3.6)
Contrariamente al Cliente, un Utilizzatore finale non sceglie il servizio, in
generale non paga per i relativi consumi (a meno che non esistano telefoni a pagamento a
scheda o a gettone all’interno dell’Utenza) e nel caso di guasto non contatta direttamente
la TelCo fornitrice bensì si rivolge all’ ufficio ISM interno all’ Utenza. L’ufficio ISM è
responsabile della gestione tecnica di tutte le risorse ICT interne all’Utenza e ad esso
vengono demandati i contatti diretti col Network Operator per derimere eventuali
problemi tecnici legati a malfunzionamenti della rete TLC e.g. segnalazione guasti e/o
richiesta di riparazioni in rete (e.g. “help desk di assistenza tecnica per utenze business”
parte dell’ ufficio “Assistenza Clienti” della TelCo).
•
Utenza: vista esterna
Una TelCo ignora cosa accade all’interno di una Utenza ed ha di essa solo una
vista esterna. Infatti una TelCo visualizza una Utenza come un dominio elementare di
utilizzazione dei suoi prodotti il quale ha un certo “track record” di utilizzazione e
pagamenti. Esso è una unità costitutiva del “Bacino di Utenza” della TelCo stessa. Più
precisamente nella sua vista esterna una Utenza è caratterizzata da 1) Numero di Utenza
2) Nome, cognome e dati identificativi del Cliente titolare dell’Utenza, 3) Contratto SLA
con la specifica dei “Terms & Conditions, T&C” del prodotto TLC acquisito, 4) Dati
statistici relativi al profilo di utilizzazione del prodotto acquisito e 4) Stato attuale e storia
dei pagamenti effettuati dall’inizio delle fornitura del prodotto.
•
Utenza: relazioni commerciali TelCo-Cliente
Il concetto di “Utenza” è importante nelle relazioni commerciali TelCo-Cliente.
Ad esempio consideriamo una attività gestionale tipica di una TelCo: la attività di
“fatturazione” (billing). Una TelCo prepara una certa fattura per una certa “Utenza”.
Nella fattura è indicato un Numero di Utenza (assegnato al Cliente al momento della
fornitura del prodotto TLC) assieme a nome, cognome, indirizzo del Cliente titolare,
importo da pagare in base ai consumi relativi al periodo di fatturazione e.g. bimestre e a
tariffe prestabilite, stato dei pagamenti ed eventuali addebiti extra per pagamenti
pregressi non effettuati (morosità).
369
ATTENZIONE! Ribadiamo che nel corso di GST è importante fare molta attenzione alla differenza
fra il ruolo di “Cliente di una TelCo” (titolare dell’Utenza e collaboratore con l’SP nella gestione dei
servizi TLC) svolto da una persona fisica o giuridica reale e il ruolo di “Utilizzatore di un servizio
TLC” svolto dai membri di una comunità di persone fisiche all’interno di una Utenza. Un
Utilizzatore è
un fruitore dei “servizi di rete” (network services) durante la fase di
“erogazione/fruizione” di un servizio TLC. I servizi di rete costituiscono l’ “essenza” di un servizio
TLC (TLC service core).
4.2.7 Utenze “Consumer”
Finora abbiamo fatto riferimento ad una organizzazione commerciale o ad un ente
governativo (perrsone reali giuridiche). Facciamo ora riferimento ad un privato cittadino
Cliente di una TelCo per un servizio di telefonia vocale mobile e.g. cellulare. In tal caso
lo scenario precedente si specializza ad una unica persona fisica che gioca i ruoli di
Cliente, Utilizzatore e Gestore delle tecnologie ICT necessarie a fruire del servizio TLC
acquisito e.g. telefono cellulare (Customer Equipment,CE). Infatti in questo caso chi
sottoscrive il servizio e effettua i pagamenti (Cliente) e ricarica la batteria quando è
scarica (Gestore) è anche colui che fa le telefonate (Utilizzatore). Una Utenza Consumer
è una Utenza il cui titolare è una persona fisica che non svolge attività di Business e.g.
Utenza Residenziale Privata.
4.2.8
Utente
Il termine “Utente” viene usato in diversi contesti con diversi significati. Ma per
noi chi è un “Utente”? In questo corso il ruolo di Utente si riferisce ad uno stakeholder
capace di svolgere entrambi i ruoli di Cliente di una TelCo e di Utilizzatore dei relativi
servizi TLC. Noi useremo il termine “Utente” ogniqualvolta non ci interessa distinguere
fra i due ruoli distinti di Utilizzatore e Cliente oppure quando le nostre considerazioni
sono ugualmente valide per entrambi. Mnemonicamente può essere utile ricordare
“Utente = Utilizzatore + Cliente”. Come già indicato in precedenza, in Inglese non
esiste un unico termine corrispondente al termine Italiano “Utente” e quindi il termine
“Utente” viene tradotto col binomio “Customer/User”.
Come già fatto in precedenza e indicato nella nota 1.0.1.3 noi useremo il termine
“Utente” non solo per indicare la coppia di ruoli “Utilizzatore + Cliente” ma anche
per indicare uno stakeholder (persona fisica o giuridica reale) che gioca i ruoli di
Utilizzatore e Cliente. Ad esempio il “soddisfacimento dell’ Utente” indica il
soddisfacimento sia delle persone fisiche nel ruolo di “Utilizzatore” sia di quelle nel
ruolo di “Cliente” cioè indica che l’Utente è soddisfatto sia da un punto di vista
gestionale che dal punto di vista di chi effettivamente fruisce di un servizio TLC
all’interno dell’Utenza. Ad esempio dire che un Utente è soddisfatto significa dire che
e.g. egli percepisce gli addetti al call-center come gentili, pronti e competenti (aspetto
gestionale) e, al tempo stesso, percepisce la qualità delle telefonate effettuate come ottima
e perfettamente in linea con le sue esigenze (aspetto di utilizzazione).
ATTENZIONE. Pericolo di confusione! Spesso in letteratura, nel caso di utenza business, si trova
indicato come ruolo “Utente” quello che per noi è un ruolo di “Utilizzatore finale”. Infatti si legge spesso
che all’interno di una Utenza si trovano “Cliente e Utente”. Inoltre spesso si indica con “Utenza” l’insieme
370
degli Utenti di una certa TelCo, cioè si chiama “Utenza” quello che noi invece chiamiamo “Bacino di
Utenza” (insieme delle viste esterne di una comunità di Utenze facente capo ad una TelCo)
4.3 I contenuti dei servizi TLC
4.3.1 “Contenuto” di un servizio TLC: definizione
Si dice che un servizio ha almeno tre “dimensioni”. Infatti, finora abbiamo
parlato della “dimensione” relazionale di un servizio cioè delle “coppie” SP-Cliente e
NO-Utilizzatore a cui compete rispettivamente la fornitura/acquisizione e la
erogazione/fruizione di servizi TLC. Poi abbiamo parlato della “dimensione” qualità del
servizio, (QoS) legata al livello di prestazione della infrastruttura tecnologica e alla
soddisfazione dell’Utente (attenzione: presenza di fattori soggettivi!). Ora vogliamo
parlare della “dimensione” contenutistica dei servizi TLC cioè vogliamo parlare dei
loro “contenuti informativi”.(lasciando da parte servizi ibridi con contenuti materiali e.g.
e-commerce)
Ma cosa è il “contenuto” di un servizio TLC? Come spesso accade, anche in
questo caso una stessa parola o frase “means different things to different people”!
Partiamo da tre esempi:
1. Il “contenuto” di un servizio telefonico è l’informazione audio scambiata in
maniera interattiva nelle telefonate fra Utente chiamante e Utente chiamato.
2. Il “contenuto” di un un servizio internet i-Tube è costituito dalle registrazioni
video fornite al “cyber-world” dagli Utenti stessi.
3. Il “contenuto” di un servizio TV sono i programmi TV diffusi via trasmettitore
TV da un produttore/fornitore di programmi ad una comunità di spettatori televisivi.
Quindi quando noi parliamo di “contenuto” di un servizio noi facciamo
riferimento a due fattori:
1) tipo di informazione trasferita durante l’utilizzazione del servizio (i.e.
contenuta nel “service core” o “essenza del servizio”) e.g. testo, audio, video
2) alle modalità del suo trasferimento e.g. wireline o wireless.
Ripetiamo. Il contenuto di un servizio di telefonia si riconosce facendo
riferimento al suo “service core” i.e. osservando cosa accade durante una sessione
telefonica: il tipo di informazione sono segnali audio (parole della conversazione
fornite/acquisite alternativamente dagli Utenti dialoganti) e la modalità di scambio
dell’informazione è “interattiva in tempo reale”. Analogamente in un servizio TV si deve
far riferimento al “service core” cioè a cosa avviene quando lo spettatore guarda la TV
sullo schermo del televisore (“erogazione di un programma TV”): il tipo di
informazione sono immagini in movimento sincronizzate con segnali audio e la
371
modalità di trasferimento dell’informazione è “streaming unidirezionale da un
trasmettitore a una comunità di Utenti con terminali RO (Receive Only)”.
Una persona giuridica (organizzazione commerciale) che produce programmi di
intrattenimento, educazione, notizie etc. e li fornisce ad una TelCo per farli poi trasferire
a Utenti finali è un Fornitore di Contenuti o una Content Company (ContCo). In
effetti un Fornitore di Contenuti può creare i suoi prodotti con diversi format in modo da
poterli poi affidare a TelCo che li trasportano con “media” di varia natura e.g. programmi
cinematografici/spot publicitari supportati da diverse “piattaforme” tecnologiche come
rete internet/computer, rete di distribuzione TV/televisore, rete di telefonia cellulare
3G/telefonino o “piattaforme” non-elettromagnetiche come libri, giornali, riviste, CD,
DVD etc. In tal caso il “medium” è la piattaforma tecnologica adottata per il trasporto
dell’informazione. Quindi per noi la creazione/produzione di contenuti (ContCo) e la
raccolta/trasporto/consegna di contenuti (TelCo) sono due fatti spazialmente e
temporalmente separati (il primo propedeutico al secondo) ma effettuati da persone
giuridiche relazionate da un punto di vista funzionale. E’ la TelCo che possiede/gestisce
il mezzo (la piattaforma) di telecomunicazione (medium) mentre è la ContCo che
crea/produce i contenuti. Tuttavia entrambe contribuiscono alla implementazione del
servizio.
NOTA 4.3.1.1
SIGNIFICATO DELLA PAROLA “MEDIUM” . La parola “medium“ può
significare due cose diverse: 1) “canale di trasporto dei contenuti” (vedi A nella Tavola 4.3.1.1)
oppure 2) “contenuto da distribuire per via radio-TV” (vedi B nella Tavola 4.3.1.1). Ad esempio, si
parla di una industria TMT (Tecnologia, Media, Telecomunicazioni) per indicare le industrie
coinvolte nella produzione/fornitura di tecnologie/servizi di Mobile TV i.e servizi TV su telefonini che
funzionano contemporaneamente da computer, televisore radio e telefono. Si parla anche di
tecnologie IMC (IMC = Information, Media, Communication) o IMCT per indicare tecnologie
integrate (qui va di moda la parola “convergenti”!) che abilitano servizi internet (Information)
servizi radio-televisivi (Media) e servizi telefonici (Communications).
Noi ci occuparemo in particolare del caso in cui l’impresa ContCo fornisce
contenuti informativi all’ impresa TelCo. Talvolta una impresa ContCo fornisce contenuti
a TelCo specializzata nella distribuzione di servizi radio-TV (TelCo-TV). In tal caso la
impresa ContCo fornitrice di contenuti è una Media Company. Ora “media” ha un
significato diverso, significa “contenuto da distribuire per via radio-TV”.
Talvolta una Media Company e la TelCo/TV sono integrate in un'unica
compagnia denominata “Broadcaster” che produce e distribuisce i suoi contenuti
autoprodotti e.g. programmi televisivi, attraverso un sistema TV di sua proprietà (e.g.
Mediaset, Sky, RAI sono broadcasters produttori e distributori di films).
372
fornisce contenuti a
A) ContCo
TelCo (possiede/gestisce il “medium”, infrastruttura
di trasporto dei contenuti)
fornisce “Media”a
B) MediaCo
TelCo/TV (possiede/gestisce una rete TV)
MediaCo + TelCo/TV = Broadcaster (Mediaset, RAI, SkyTV etc.)
Tavola 4.3.1.1
In campo internet un Application Service Provider fornisce ai suoi utenti
l’accesso a specifiche applicazioni che sviluppa in proprio o ottiene da una terza parte
(sviluppatore di software). In quest’ultimo caso lo sviluppatore di software è un Fornitore
di Contenuti in un servizio ASP.
Telephony
Internet
Radio
TV
Fixed
Wireline
Wireless
DECT
Wi-Fi
Wi-Max
Satellite (VSAT T/R)
Satellite (VSAT RO)
Mobile
Wideband Cellular (Terrestrial)
Wideband Cellular (Satellite)
Tassonomia
Fig. 4.3.1 Una possibile classifica dei servizi TLC in base a due criteri ortogonali: contenuti
del servizio e tecnologie di accesso alla rete. Un servizio TLC è rappresentato da un punto
all’interno del diagramma a “scatole annidate (“nested box diagram”) e le sue caratteristiche
sono individuate dal nome delle scatole sovrapposte in quel punto. Ad esempio la stella
rappresenta servizi internet con terminale satellitare fisso del tipo VSAT T/R (Very Small
Aperture Terminal Transmit/Receive).
373
4.3.2
I contenuti come criterio di classificazione
Un criterio di classificazione dei servizi TLC può basarsi proprio sui contenuti
cioè sul tipo di informazione trasportata nel service core e sulle modalità del suo trasporto
Ad esempio, prendiamo i servizi TLC più popolari
1. Servizi Telefonici (tipo di informazione: audio interattiva o vedi Tavola
4.3.1)
2. Servizi di radiodiffusione (tipo
unidirezionali e.g. voce, musica)
di
informazione:
segnali
audio
3. Servizi TV (tipo di informazione: immagini in movimento sincronizzate
con segnali audio)
1. Servizio telefonico
2. Servizio ISDN (due linee telefoniche simultanee)
3. Servizi Telefonici Evoluti
3.1 Memotel (Segreteria Telefonica)
3.2 Conversazione a tre
3.3 Avviso Chiamata (Call Waiting)
3.4 Trasferimento Chiamata
3.5 Autodisabilitazione
3.6 Chi è (Caller ID)
3.7 Servizio 4197
3.8 Richiamata su Occupato
4. Servizi Informazione
4.1 Servizio 12.54
4.2 Servizio 412 (Fornitura di vasta gamma di informazioni)
4.2.1 Opzione 1
4.2.2 Opzione 2
4.2.3 Servizio 892.412
5.
Altri Servizi
5.1 Servizio 4161 (Ora Esatta)
5.2 Servizio 4114 (Sveglia)
6.
Servizi Internazionali
6.1 Servizio Abbonati Esteri
6.2 Servizio 170 (Collegamento via Operatore)
6.3 Servizio “Italy Direct”
6.4 Servizio “Collect Entrante”
Tavola 4.3.1 Presa dalla Carta dei Servizi di TelecomItalia. Par.9
374
SERVIZI di COMUNICAZIONE ELETTRONICA (SCE)
“Servizio, normalmente fornito a pagamento, che consiste esclusivamente o prevalentemente
nella trasmissione di segnali su reti di comunicazione elettronica compresi servizi di
telecomunicazione e servizi di trasmissione in reti di diffusione circolare radiotelevisiva ma ad
esclusione di servizi che forniscono o effettuano controllo editoriale di contenuti trasmessi
usando reti di comunicazione elettronica; sono inoltre esclusi servizi della “società
dell’informazione” come definiti nell’articolo 1 della direttiva 98/34/EC che
non consistano interamente o prevalentemente nella trasmissione di segnali su reti di
comunicazione elettronica.
TAVOLA 4.3.2 Nel 2002 la Comunità Europea ha cambiato il termine “Telecomunicazione”
in “Comunicazione Elettronica” ed ha fornito nuove definizioni di reti e servizi. Questa è la
definizione di servizio TLC contenuta nella direttiva 2002/21/CE del Parlamento Europeo
(07/03/2002) e utilizzata sia nel Codice della Privacy (D.lgs.196/2003) che nel Codice delle
Comunicazioni Elettriche (D.lgs.259/2003)
4. Servizi Internet (tipo di informazione: dati trasferiti via e-mail, web
browsing, file transfer, music/video downloading etc.)
Questi servizi TLC possono anche classificarsi in base alle modalità di trasporto e.g. in
base alla piattaforma tecnologica di accesso alla rete come mostrato in Fig. 4.3.1. La
Tavola 4.3.2 a scopo di paragone, mostra una definizione di servizio TLC
indipendente dal contenuto del servizio come fornita dalla Comunità Europea.
4.4 I servizi TLC
4.4.1
Introduzione ai servizi TLC: possesso di funzionalità TLC (acquisizione) e
svolgimento di funzioni TLC (fruizione)
Per una impresa TelCo proprietaria/gestore/operatore di reti e fornitore di servizi
TLC a Utenti finali, la fornitura/erogazione di servizi TLC e i relativi pagamenti da parte
degli Utenti costituiscono il cuore delle attività di business. Infatti i ricavi di una TelCo
sono basati sulla raccolta dei pagamenti effettuati dai Clienti per acquisire gli
abbonamenti e per fruire dei servizi TLC. Tutti le altre relazioni di business con attori
esterni all’impresa e.g. imprese partner nella fornitura di servizi TLC o fornitori di
tecnologie, comportano esborsi di denaro. Ma in che cosa esattamente consiste la
“fornitura di un servizio TLC” ? E’ stato già detto più volte. Ma lo ripetia,o perché è
importante saperlo.
NOTA 4.4.1 Qui non si fa riferimento a servizi internet ai quali gli Utenti finali hanno accesso
gratuito e le cui entrate per gli SP sono rappresentate dai pagamenti effettuati dagli inserzionisti di
messaggi pubblicitari.
375
4.4.1.1 Fornitura/Acquisizione di Servizi TLC
Nel Cap.1 abbiamo visto che un sistema TLC è una infrastruttura fisico-logicoenergetica abilitante i servizi TLC costituita da componenti ICT e da componenti ausiliari
nonICT. In questo capitolo noi ci occuperemo di sistemi TLC e loro componenti
visualizzati da SP-Cliente come “Risorse Business” atte a supportare le loro attività di
business.
Come indicato nel Capitolo 1, la “fornitura di un servizio TLC” è la “fornitura
di un insieme coerente di funzionalità da un Fornitore a un Utente, atte a risolvere
problemi che insorgono (o insorgeranno) presso l’Utente nel momento in cui egli decide
(o deciderà) di soddisfare certi suoi desideri/bisogni di telecomunicazione”.
Analogamente la “acquisizione di un servizio TLC” è la “acquisizione di un insieme
coerente di funzionalità da parte di un Utente per risolvere certi suoi problemi insorti o
che insorgeranno a causa di desideri/bisogni di telecomunicazione da soddisfare”.
Queste funzionalità hanno un carattere di specifiche “potenzialità” attuate nelle
effettivo svolgimento di funzioni TLC con una “QoS erogata” dipendente da certe
“condizioni di utilizzazione”. Ma attenzione! Se la funzionalità TLC acquisita non è
specifica della funzione TLC da svolgere essa va prima specializzata o “resa attuale” e
poi può essere attuata nello svolgimento di una funzione TLC specifica. Definiamo
questo processo complessivo di specializzazione + attuazione un processo di
“attualizzazione”.
ESEMPIO 4.4.1. “Attualizzazione”
La funzionalità (capacità conoscitiva) acquisita con il possesso di un elenco telefonico “pagine
Bianche” va “specializzata” con la scelta del numero telefonico desiderato prima di poter essere
“attuata” nella digitazione del numero sulla tastiera del telefono.
ESEMPIO 4.4.2 “Condizioni di utilizzazione”
Le “condizioni di utilizzazione” di un servizio TLC possono essere dettate da sorgenti interne o
esterne al sistema TLC. Ad esempio la “QoS erogata” di un servizio TLC di TV satellitare dipende
dalle condizioni atmosferiche prevalenti sul sito di ricezione mentre la qualità di trasmissione end-toend di un segnale in rete dipende dai livelli di rumore e di interferenza esistenti in quel momento in
quel canale.
2
Funzionalità “tecnologicamente neutre”
L’ insieme coerente di funzionalità di rete (U&S e gestionali) acquisito dall’Utente
al momento della firma del contratto SLA è costituito da funzionalità
«tecnologicamente neutre» cioè indipendenti dalle particolare tecnologie di rete
adottate dal Fornitore. Infatti al momento della firma di un contratto SLA fra Fornitore
e Cliente il contratto non specifica le tecnologie di rete adottate ora e in futuro dal
Fornitore. La funzionalità acquisita è denominata “tecnologicamente neutra” perché può
essere abilitata da una qualsiasi tecnologia appartenente ad una classe di Tecnologie
Abilitanti Equivalenti scelta a discrezione del Fornitore.
NOTA 4.4.2 Una “funzionalità TLC tecnologicamente neutra” è una funzionalità TLC supportata da
una qualsiasi tecnologia scelta da una classe di “Tecnologie Abilitanti Equivalenti” (classe TAE). Un
Utente di un servizio TLC acquisisce una funzionalità di rete tecnologicamente neutra che
376
ovviamente non può attuare nello svolgimento di una specifica funzione di interconnessione o di
distribuzione. Tuttavia, in questo caso, l’Utente richiede al Fornitore di servizio TLC depositario di
una funzionalità specifica (istanza della “classe TAE”), di svolgere la funzione per suo conto (i.e. il
Fornitore eroga un servizio all’ Utente che ne fruisce). Ad esempio quando, acquisisco servizi di
telefonia internazionale dalla Telecom Italia acquisisco funzionalità di rete tecnologicamente neutre
che ovviamente non posso attuare personalmente ma posso richiedere alla Telecom Italia in quel
momento proprietaria di certe funzionalità tecnologicamente specifiche, di attuarle per mio conto
(i.e. richiedo alla Telecom Italia di erogarmi un servizio di telefonia internazionale). Per quanto mi
riguarda la Telecom Italia può adottare le opportune tecnologie di rete come meglio crede, purchè
non violi gli accordi contrattuali!
Le funzionalità tecnologicamente neutre (U&S e gestionali) sono una
generalizzazione di funzionalità di rete specifiche possedute dal Fornitore
(Funzionalità installata) al momento della firma del SLA. La “funzionalità di rete
specifica” si riferisce alla disponibilità di una tecnologia di rete specifica e relativo know
how operativo.
In generale le funzionalità pianificate/installate dalla TelCo sono in risposta alla
domanda effettuata da “classi” di aspiranti o potenziali Utenti accertata attraverso
precedenti analisi di mercato (ad eccezione di alcuni casi particolari nei quali una
specifica funzionalità di rete viene configurata ad hoc per in singolo Utente di grosse
dimensioni). Una volta acquisito un servizio TLC l’Utente non attua in proprio le
corrispondenti funzionalità tecnologicamente neutre acquisite ma, al momento del
bisogno, chiede al SP di attuare le funzionalità specifiche di cui egli dispone in quel
momento. (e.g. se la richiesta viene effettuata nel Dicembre 2010 l’SP utilizza le
tecnologia a sua disposizione nel Dicembre 2010!). Vedere gli Inserti 4.4.1, 2 e 3
Il fatto che le funzionalità fornite/acquisite siano tecnologicamente neutre e’
molto importante e ha due conseguenze altrettanto importanti:
4.4.1.2
1)
Tecnologie implementative del sistema TLC diverse ma equivalenti dal
punto di vista delle condizioni/qualità/prezzo del servizio sono perfettamente
accettabili per l’Utente, anzi in generale l’utente non solo tollera tecnologie
implementative diverse ma ignora completamente la loro natura,
2)
Il Fornitore è libero di adottare o cambiare la tecnologia implementativa nel
modo che egli ritiene più opportuno e conveniente senza notificare
all’Utente questa sua scelta.
Erogazione/fruizione di servizi TLC
In un evento di erogazione/fruizione di un servizio TLC si parla di “svolgimento
di funzioni TLC” invece di “trasferimento di funzionalità TLC”.
La “erogazione di un servizio TLC” è lo “svolgimento di un insieme coerente di
funzioni U&S specifiche di un servizio TLC (attuazione di un insieme coerente di
funzionalità specifiche) da parte di una TelCo (nella persona di un Network Operator
fornitore di Servizi di Rete) su richiesta di un Utilizzatore con lo scopo di risolvere
377
problemi insorti presso quiest’ultimo allorché egli decide di soddisfare certi suoi
desideri/bisogni di telecomunicazione”.
La “fruizione di un servizio TLC” è la “la attuazione di un insieme coerente di
funzionalità U&S possedute da un Utilizzatore (e a lui cedute dal Cliente titolare
dell’Utenza), con lo scopo di risolvere problemi insorti presso di lui allorché egli decide
di soddisfare certi suoi desideri/bisogni di telecomunicazione”.
INSERTO 4.4.1
LA DOMANDA SBAGLIATA
FREQUENTLY ASKED QUESTION: Se un abbonato a un servizio
TLC con l’abbonamento acquisisce una funzionalità tecnologicamente
neutra” (i.e. il contratto SLA mette a sua disposizione una “classe di
tecnologie abilitanti equivalenti” e non tecnologie specifiche) come
può egli al momento del bisogno attuarla nello svolgimento di una
funzione specifica?
La risposta è immediata se si riconosce che la domanda è formulata in
maniera sbagliata. Lo sbaglio è contenuto nell’espressione “come può
egli attuarla” riferita all’Utente. Infatti l’Utente con un processo di
“Fornitura/Acquisizione di servizio TLC” viene in possesso di un
insieme coerente di
funzionalità tecnologicamente neutre ma
personalmente non le attua (non può attuarle perché ignora i dettagli
operativi delle tecnologie abilitanti!). Ma la situazione è asim-metrica.
Infatti le funzionalità in possesso dell’ Utente (“Funzionalità acquisita”)
sono per l’Utente tecnolo-gicamente neutre mentre le corrispondenti
funzionalità possedute dalla TelCo (“Funzionalità offerta”) sono per l’
SP funzionalità “specifiche”. Infatti, al contrario dell’ Utente, l’SP (e.g.
l’ ufficio commerciale di una TelCo) al momento della stipula del
contratto dispone di una ben specifica tecnologia di rete e relativo know
how operativo (tramite NO) cioè l’SP dispone (tramite NO) di una conoscenza operativa e una abilità tecnologica entrambe “specifiche” che egli
può far attuare quando vuole (in particolare su richiesta dell’ Utente).
Quindi, grazie alla firma di un contratto SLA col SP, l’ Utente possiede
una “Funzionalità acquisita” (U&S e gestionale) tecnologicamente
neutra che tuttavia egli non può attuare nello svolgimento di specifiche
funzioni. Infatti l’Utente, allorché necessario, richiede al SP di attuare
la “Funzionalità offerta” tecnologicamente specifica a lui disponibile in
quel momento: è una richiesta che sarà certamente soddisfatta dal SP/NO
e permetterà all’Utente sia di fruire di un servizio TLC (e.g. telefonare)
che di svolgere funzioni gestionali di supporto (e.g. segnalare/far riparare
guasti), se egli da parte sua collaborerà attuando prontamente e
correttamente le opportune funzionalità specifiche di terminale (U&S e
gestionale, rispettivamente TU e TC in Fig. 1.2.2.2)
378
INSERTO 4.4.2
FORNITURA/ACQUISIZIONE di un
SERVIZIO TLC: “Dissimetria fra “funzionalità
acquisita”da un Utente finale e “funzionalità offerta” da
un SP
La dissimetria che si stabilisce al termine di un processo
di ”Fornitura/Aacquisizione di un servizio TLC” fra
“funzionalità acquisita” (tecnologicamente neutra) da un
Utente e “funzionalità offerta” (specifica) da un SP ha le
seguenti conseguenze:
1). Tecnologie di rete diverse da quelle possedute dal SP
al momento della stipula del Contratto SLA (tecnologie
“legacy”) ma ad esse equivalenti dal punto di vista delle
condizioni/qualita’/prezzo del servizio TLC fornito, sono
perfettamente accettabili ad un Utente (finale). Anzi in
generale l’ Utente di un servizio TLC residenziale privato
non solo accetta tecnologie di rete diverse dalle tecnologie
legacy ma anzi preferisce ignorare la natura delle
tecnologie di rete in possesso del Fornitore non essendo
egli un esperto del settore e cercando di utilizzare la
materia grigia del suo cervello per scopi per lui più
intressanti. Ad un Utente residenziale che telefona da
Roma a New York non interessa affatto conoscere se la
sua voce viaggia via cavo sottomarino o via satellite o se
il cavo sottomarino è di un tipo piuttosto di un altro
fintantochè, a parità di prezzo, la qualità audio della
conversazione è uguale o migliore di quella pattuita nel
Contratto SLA da lui firmato.
2) Una conseguenza del No.1 è la seguente: fintantochè le
caratteristiche tecniche ed economiche del servizio TLC
rimangono le stesse o sono migliori di quelle pattuite, l’
NO che collabora col SP all’interno della TelCo e’ libero
di modificare/aggiornare le sue tecnologie di rete nel
modo che egli ritiene piu’ opportuno (e.g. economicamente conveniente) senza dover necessariamente notificare a tutti gli Utenti del servizio questa sua scelta. Ad
esempio egli può aggiornare le sue tecnologie di rete
esistenti e mantenerle al passo con il progresso
tecnologico e.g. acquisire tecnologie di nuova generazione più performanti o operativamente meno costose
delle tecnologie legacy in suo possesso. Inoltre in caso di
guasto di una tecnologia di rete essa può essere
rimpiazzata con una tecnologia abilitante equivalente non
necessariamente uguale a quella scartata, a discrezione
dell’operatore di rete e secondo convenienza.
379
INSERTO 4.4.3
ESEMPI DI FUNZIONALITA’ TECNOLOGICAMENTE
NEUTRA IN SCENARI non-TLC
Notare come il paradigma “funzionalità-funzione” da noi applicato ai casi
di “fornitura/acquisizione di servizio TLC” e “erogazione/fruizione di
servizio TLC” sia di validità del tutto generale e anche il concetto di
“funzionalità tecnologicamente neutra” sia anch’esso del tutto generale e
applicabile ad una varietà di servizi. Ad esempio, una situazione di
“funzionalità tecnologicamente neutra” si incontra nel caso di un servizio
di autonoleggio con autista (“Rental Car with Driver”). In questo
caso il Cliente firma un contratto con una “QoS offerta” specificata da
parametri di qualità accompagnati da certi valori numerici (e.g.
disponibilità del servizio: max. 10 minuti dal tempo di chiamata su base
24/7) e un certo prezzo (e.g. tariffa: “200 € al giorno”). Tuttavia egli
acquisisce la “disponibilità” di una qualsiasi autovettura appartenente ad
una certa categoria (e.g. classe “medium size”, classe di tecnologie
abilitanti equivalenti) e non una specifica autovettura. Inoltre l’Utilizzatore del servizio (non necessariamente il Cliente che ha firmato il
contratto) non è necessario possegga una patente di guida automobilistica (assenza di conoscenza operativa delle tecnologie abilitanti).
L’Utente del servizio quindi ignora la tecnologia specifica abilitante e
relativo know how operativo: egli acquisisce una “funzionalità
tecnologi-camente neutra”.
Al cliente non interessa affatto la
marca/colore dell’auto o le modalità d’uso o il nome del conducente che
gli sono stati assegnati purchè la qualità del servizio (criteri di qualità:
disponibilità, prontezza, sicurezza, flessibilità etc.)
sia di sua
soddisfazione e il prezzo pagato sia quello pattuito.
Dal lato Fornitore la situazione è diversa: l’autovettura e il conducente
sono scelti dal fornitore 24 ore prima del loro utilizzo. Effettuata la scelta,
il Fornitore possiede una funzionalità specifica che egli attua nell’
effettivo svolgimento della funzione “Autonoleggio con autista” (erogazione del sevizio).
Situazione analoga si incontra nell’acquisto di un abbonamento
ferroviario. Anche in questo caso l’abbonato acquisisce una funzionalità
tecnologicamente neutra basata sulla disponibilità di una “classe di
tecnologie abilitanti equivalenti” (treni e reti ferroviarie) e ovviamente
senza disporre di una conoscenza operativa delle risorse impiegate dalle
Ferrovie dello Stato.
380
4.4.2 Ulteriore classifica dei servizi TLC (argomento già trattato nel Capitolo 1)
•
Introduzione ad un modello generico e unificato per i servizi TLC
Tipicamente i servizi di telecomunicazione sono classificati secondo la
tassonomia della ITU-T presentata nella Raccomandazione I-211 (1993). Secondo questa
classifica i servizi sono suddivisi in due gruppi: interattivi e distributivi. I primi sono
ulteriormente suddivisi in tre categorie : conversazione, messaggistica e consultazione.
I secondi sono ulteriormente suddivisi in servizi distributivi con o senza controllo della
presentazione.
In un contesto GST abbiamo presentato nel Capitolo 1 una tassonomia diversa,
particolarmente adatta alla creazione di modelli gestionali generici cioè indipendenti dal
particolare scenario di servizio. Mettendo in evidenza la natura della sua utilizzazione,
classifichiamo un servizio come appartenente a una di tre diverse categorie come
mostrato in Fig.4.4.2.1
1)
servizi di interconnessione in cui uno o più Utenti scambiano informazione in
tempo reale o differito con uno o piu’ Utenti residenti in siti remoti tramite un
Fornitore di servizi e.g. i servizi telefonici pubblici, e-mail etc.
2)
servizi di distribuzione in cui un Fornitore invia lo stesso tipo di informazione ad
una comunità di Utenti paganti e.g. servizi di distribuzione rdio-TV
3)
servizi di assistenza nei quali il Fornitore interagisce direttamente con il singolo
Utente inviando contenuti. In questi servizi i Fornitori svolgono da sede remota
tutte quelle attività che i singoli Utenti non possono (perchè non hanno il tempo
disponibile o perchè sono privi di know-how) o non vogliono effettuare su base
individuale e.g. servizi di tele-medicina, tele-educazione, tele-consulenza etc.
Questa schematizzazione dei servizi in tre categorie è stata graficamente
rappresentata in Fig.4.4.2.1. Al fine di poter poi creare un modello servizi generico e
unificato indipendenti dal particolare scenario di servizio, la descrizione delle funzioni
abilitate da un servizio è effettuata tramite un grafo orientato nel quale le
caratteristiche comuni del servizio sono separate e specificate nelle strisce orizzontali
(gialle) ubicate sopra e sotto tre rettangoli centrali, all’interno dei quali è speficata la
natura del servizio in fase di utilizzazione o fruizione (“essenza” del servizio). Le
funzioni specifiche corrispondono ai desideri/bisogni dell’Utente che sono soddisfatti da
ciascun servizio. In questa figura la descrizione di un servizio deve essere letta partendo
dall’alto a sinistra e spostandosi poi verso il basso e verso destra seguendo le frecce. Un
singolo servizio e’ caratterizzato da un unica funzionalità/funzione specifica, cioe’ il
servizio soddisfa un singolo desiderio/bisogno. Ad esempio la descrizione del servizio di
telefonia si ottiene leggendo il grafo come segue: “Acquisire un servizio di telefonia
significa acquisire la capacita’ conoscitiva/abilità fisica (funzionalità) di conversare in
tempo reale con gli altri utenti dello stesso servizio, funzionalità tecnologicamente neutra
381
acquisita a pagamento da un Utente e fornita da un Fornitore a condizioni/qualita’
/prezzo specificati in un contratto SLA (Service Level Agreement)”.
In figura è anche messo in evidenza il fatto che la funzionalità acquisita dall’Utente
e’ «tecnologicamente neutra» cioè indipendente dalla particolare tecnologia
implementativa adottata dal Fornitore. Questo punto ha due conseguenze altrettanto
importanti:
2)
Tecnologie implementative diverse ma equivalenti dal punto di vista delle
condizioni/qualità/prezzo del servizio sono perfettamente accettabili per
l’Utente, anzi in generale l’utente non solo tollera tecnologie
implementative diverse ma ignora completamente la loro natura,
3)
Il Fornitore è libero di adottare o cambiare la tecnologia implementativa nel
modo che egli ritiene più opportuno e conveniente senza notificare
all’Utente questa sua scelta.
La figura 4.4.2.1 riporta esempi di servizi TLC tra i più comuni. Ovviamente non ci
aspettiamo che le tre liste presentate in figura esauriscano tutti i possibili servizi TLC che
si possono trovare nella odierna societa’ e, per questo, abbiamo incluso la notazione
«etc.» a pie’ di ogni lista. Questi servizi, sebbene percepiti dall’Utente come funzionalità
tecnologicamente neutre, sono supportati da sistemi reali e.g. la rete telefonica, la rete
internet, etc i quali richiedono l’impiego di opportune tecnologie. Come già più volte
indicato, i servizi TLC sono caratterizzati dal fatto che utilizzano un sistema TLC per il
trasporto di informazione. Esaminiamo ora le tre categorie di servizi.
•
Servizi di interconnessione (zona blue a tratteggio orizzontale in Fig. 4.4.2.1)
I servizi telefonici/internet e i servizi postali sono entrambi esempi di servizi di
comunicazione a distanza. Notare che, come precedentemente osservato a proposito
della definizione del termine «telecomunicazione», la specifica di «comunicazione a
distanza» va interpretata nel senso che i partecipanti alla comunicazione sono fisicamente
separati con distanze che vanno dalle decine di metri (reti LAN) a migliaia di chilometri
(reti WAN, reti telefoniche pubbliche, reti di distribuzione radio-televisiva).
Esiste anche un terzo tipo di servizi di comunicazione a distanza, che chiameremo
servizi misti, i quali utilizzano come mezzo di trasporto sia quello elettromagnetico che
quello meccanico. Si pensi ad esempio ai servizi di vendita on-line dove prodotti di ogni
genere vengono ordinati via internet e consegnati fisicamente a domicilio per posta. In
questo corso di lezioni ci occuperemo di tutti quei servizi che almeno in parte utilizzano
il mezzo elettromagnetico come mezzo di trasporto dell’informazione e.g. servizi misti,
ignorando i servizi che utilizzano mezzi trasmissivi esclusivamente meccanici o acustici.
382
•
Servizi di distribuzione (zona gialla a tratteggio verticale in Fig. 4.4.2.1)
Ci sono poi altri tipi di servizi chiamati servizi di distribuzione, nei quali un
Fornitore non fornisce all’Utente la capacita’ di comunicare con un altro utente bensi’ la
capacita’ di ottenere prodotti distribuiti ad una comunita’ di Utenti paganti e.g. energia
elettrica, gas o acqua oppure informazione sotto forma di radio, televisione (servizi di
broadcasting o multicasing), internet (e.g. newsletters on-line i.e. distribuzione on-line di
bollettini informativi), abbonamento a giornali etc. secondo modalità/qualità/prezzi
talvolta stipulati in un contratto fra Fornitore e Cliente chiamato Service Level
Agreement (SLA) cioè «Accordo a Livello Servizi». In un servizio di distribuzione
l’Utente interagisce direttamente con il Fornitore del prodotto senza coinvolgimento di un
altro Utente come nel caso di servizi telefonici dove coppie di Utenti interagiscono in
tempo reale (trascurando il tempo di ritardo associato alla propagazione
elettromagnetica).
Nella fase di utilizzazione del servizio, il prodotto distribuito, e.g. programma
radio-televisivo, e’ generalmente fornito in modo unidirezionale dal Fornitore all’Utente.
Ditribuzione interattiva e Persona TLClizzata esiste negli USA. Esistono infatti servizi
di distribuzione «on-demand» nei quali il prodotto viene fornito solo agli Utenti che ne
abbiano fatto previa richiesta. Fanno parte di questa categoria due tipi di servizi TLC: 1)
i servizi di «Video-on-Demand» (VoD) nei quali, ad una data ora, un film viene
mandato sul televisore di un utente che ne ha fatto richiesta e 2) i servizi « Pay-perView » (PpV) nei quali un utente, su richiesta, puo’ vedere «live» sul suo televisore un
evento particolare e.g. una manifestazione sportiva o uno spettacolo teatrale di particolare
importanza.
I servizi di distribuzione on-demand prevedono l’uso del telefono o dell’internet o
del fax per effettuare l’ordinazione del prodotto desiderato, mentre il prodotto desiderato
(film o ripresa televisiva) viene inviato al richiedente via canale televisivo. In questo
corso ci occuperemo solo di quei servizi di distribuzione che utilizzano, almeno in parte,
il mezzo elettromagnetico i.e. radio, televisione, VoD, PpV, newsletters on-line etc.
•
Servizi di assistenza (zona rosa a tratteggio reticolato in Fig.4.4.2.1)
Esistono anche servizi di assistenza nei quali Persona TLCle specializzato assiste
l’Utente nelle forme piu’ disparate, effettuando operazioni di cui l’utente ha bisogno e.g.
asportando (portando) dalle (alle) residenze degli utenti prodotti, offrendo assistenza
medica (e.g. servizi medico-sociali) o effettuando la tele-manutenzione di apparati e/o
impianti (e.g. servizio di manutenzione delle apparecchiature in un laboratorio) o
fornendo corsi di tele-educazione.
In questo corso faremo riferimento solo a quei servizi di tele-assistenza che
usano, almeno in parte, il mezzo elettromegnetico come mezzo di trasporto
dell’informazione Ad esempio servizi di commercio elettronico appartengono a questa
categoria (Fig.4.4.2.2). .
383
Infatti, finora abbiamo parlato di servizi su mezzo completamente
elettromagnetico ma esiste anche un tipo di servizi di comunicazione a distanza, che
chiameremo servizi misti o ibridi, (vedi Fig.4.4.2.3) i quali utilizzano come mezzo di
trasporto sia quello elettromagnetico che quello meccanico. Si pensi ad esempio ai servizi
di vendita on-line dove prodotti di ogni genere vengono ordinati via internet e
consegnati fisicamente a domicilio per posta. In questo corso di lezioni ci occuperemo di
tutti quei servizi che almeno in parte utilizzano il mezzo elettromagnetico come mezzo
di trasporto dell’informazione e.g. servizi misti, ignorando i servizi che utilizzano mezzi
trasmissivi esclusivamente meccanici o acustici. Ovviamente per questi servizi quello che
conta è il “contenuto” del servizio TLC che serve solo come “mezzo di trasporto” del
contenuto stesso
4.4.3
Funzionalità U&S e funzionalità di gestione nei servizi di telefonia
•
Funzionalità U&S
Consideriamo una Telco Retailer che offra un servizio TLC “on demand”
interattivo in tempo reale con scambio di informazione fra Utenti finali. La Telco offre a
tutti gli Utenti finali un insieme di funzionalità per svolgere una o più funzioni tipiche del
servizio. In precedenza abbiamo parlato di funzioni TLC come componenti funzionali di
un servizio TLC. Se certe “condizioni di attualizazzione” sono soddisfatte queste
funzionalità possono poi essere attualizzate nello scambio di informazione U & S e di
gestione fra TelCo e Utente e, quindi, attraverso la TelCo fra Utente e Utente.
Ad esempio nel caso di un servizio telefonico, il possesso di funzionalità U & S
è il possesso di capacità conoscitiva/abilità fisica da parte dell’Utente (nel ruolo di
utilizzatore) di svolgere le funzioni “essenziali” di cui egli ha bisogno i.e. «richiedere
ed effettuare lo scambio di informazione audio fra Utenti in tempo reale e in modo
interattivo e continuo (conversazione)». Qui supponiamo che l’Utente, oltre ad aver
acquisito un servizio TLC, già abbia a sua disposizione una apparecchiatura terminale
che egli sa operare.
384
Per un Utente, acquisire un SERVIZIO di […] significa acquisire la
funzionalità di
effettuare:
ottenere:
una conversazione
telefonica con
un collegamento
internet con
una videoconferenza
con
un collegamento
LAN con
etc.
Fig.4.2.2.1
programmi radio
programmi TV
video-on-demand
newsletters online
pay-per-view
etc.
usufruire delle competenze
professionali di personale
specializzato in:
tele-educazione
tele-medicina
tele-consulenza
etc.
altri utenti dello stesso
servizio
funzionalità tecnologicamente neutra acquisita a PAGAMENTO e attuata allorchè richiesto a
condizioni/qualita’/prezzi prestabiliti e specificati in un CONTRATTO SLA.
385
Fornitore di Teleservizi o “e-servizi”
Contenuti
SCUOLA
Risorse Interne
U
Teleeducazione
mento
U
AT
F
U
Consulenza
Legale
AT
F
U
Servizio
di Rete
RETE
TLC
UTENTI
FINALI
Telemedicina
Assistenza
Medica
STUDIO
LEGALE
AT
F
Insegna -
OSPEDALE
Servizi TLC
Teleassistenza
Fig .1.5 .1.2.3
Fig.4.4.2.2 Architettura di servizi TLC di assistenza (tele-servizi). Notare sul
lato sinistro la presenza di fornitori di contenuti non specifici delle TLC
386
Utente residenziale privato
Terminali
POSTA
utilizzatore
utente
ISP
utente
di EBS
Electronic Bookstore Service (EBS)
fornitore
Fornitore Servizi internet (ISP)
INTERNET
Fornitore
EBS
Stock
room
Venditore di Libri (Catalogo)
cliente
utilizzatore
Servizio Pacchi Postali (SPP)
fornitore
fornitore
Ufficio Postale
Fig. 4.4.2.3 Servizio di libreria on-line.
Questa funzione U&S è una funzione relativa al «servizio telefonico di base» (in
letteratura spesso chiamato POTS, Plain Old Telephone Service).
Essa può
accompagnarsi opzionalmente con una varietà di altre funzioni U&S (non gestionali!)
relative a servizi supplementari a «valore aggiunto», («added-value services»)
contenuti in un catalogo servizi, come ad esempio:
1.
identificazione del numero chiamante (servizio «Caller ID»),
2. segnalazione, tramite segnale acustico, durante una sessione telefonica della
presenza di un terzo numero chiamante (servizio «Call Waiting»),
387
3. presenza simultanea di piu’ partecipanti alla sessione telefonica (servizio
«Conference Call» o «Closed User Group»),
4. in caso di assenza di risposta a una chiamata, emissione di un messaggio
preregistrato, successiva registrazione del contenuto della chiamata e segnalazione
dell’esistenza di un messaggio in memoria tramite segnale luminoso sul terminale
(servizio «voice-mail» o di segreteria telefonica),
5. blocco di telefonate indesiderate provenienti da numeri telefonici predeterminati,
6. trasferimento automatico di chiamata ad un nuovo numero telefonico
7. servizio di faxsimile, etc.
Un Utente di un servizio telefonico residenziale può ottenere con un unico
contratto da una Telco un «pacco» servizi personalizzato (prodotto personalizzato)
costituito dal servizio di base più un numero di servizi a valore aggiunto scelti a piacere
da un catalogo. Infatti, vedremo fra poco che, a differenza di altri servizi e.g. un servizio
postale, la acquisizione di un servizio telefonico da parte di un Utente non avviene in una
forma impersonale ma avviene in forma «customizzata» o personalizzata cioè ad
personam.
•
Funzionalità di gestione
Oltre alle funzionalità U&S ci sono anche funzionalità di natura ancillare rispetto
alle precedenti: le funzionalità di gestione. Con le funzionalità di gestione l’Utente (nel
ruolo di cliente) partecipa allo svolgimento delle seguenti funzioni
1. offerta servizi
2. piazzamento/esecuzione ordini,
3. definizione e firma contratti SLA
4. installazione servizi
5. addebiti e fatturazione/riscontro pagamenti
6. segnalazione/riparazione guasti
7. assistenza tenica post-vendita
8. terminazione contratto e.g. per morosità
9. disinstallazione servizi
388
Nello svolgimento di queste funzioni egli scambia informazione e beni materiali
con la Telco (e.g. denaro relativo ai pagamenti, ricezione/pagamento di fatture per via
postale o bancaria) e utilizza risorse di gestione (e.g. reti/terminali di gestione) che
includono canali internet e/o canali postali e bancari per il pagamento delle fatture.
Alla luce di quanto detto si vede subito che le funzionalità U & S costituiscono la
«raison d’etre» del servizio e, al tempo stesso, la risoluzione dei problemi insorti presso
l’Utilizzatore allorché egli decide di soddisfare certi suoi desideri bisogni mentre le
funzionalità di gestione hanno un ruolo ancillare e sono fornite al Cliente con il fine di
svolgere le funzioni U&S con la Qualità di Servizio (QoS) stipulata in un contratto SLA.
4.4.3.1
Il “ciclo di vita” completo di un servizio TLC
Finora abbiamo enfatizzato l’importanza delle fasi di fornitura/acquisizione e di
erogazione /fruizione di un servizio TLC. Tuttavia in generale un servizio TLC evoluisce
nel tempo secondo un “ciclo di vita” (life cycle) che inizia molto prima della fase di
fornitura/acquisizione. La Fig.4.4.3.1 mostra dall’alto verso il basso la sequenza di
attività effettuate da attori TelCo (Service Developer, Service Provider, Network
Operator), ICTS, Cliente (Customer) e Utilizzatore (User) durante il ciclo di vita di un
servizio TLC interattivo on-demand. Esaminiamo con attenzione questa figura.
Si notano tre gruppi di funzionalità/funzioni mutuamente interrelate
1. Product Development (Produzione Servizi, azzurro)
2. Service Delivery (Fornitura Servizi, rosa)
3. Service Session (Sessione di Servizio, giallo)
rispettivamente corrispondenti alle attività dei seguenti attori
1. SD + ICTS
2. SP+NO+Cliente
3. SP+Cliente + Utilizzatore.
Le aree funzionali sono mutuamente relazionate. Fra le relazioni più importanti
dobbiamo menzionare il fatto che le attività di “Product Development” devono tener
conto delle future attività di “Service Delivery” e che quindi i due gruppi possono
389
SD
Strategic
Processes
1.1.
2.2.
3.3.
4.4.
5.5.
6.6.
ANALISI
ANALISIdelle
delleOPPORTUNITA’
OPPORTUNITA’
DEFINIZIONE
&
DEFINIZIONE &FATTIBILITA’
FATTIBILITA’
PROGETTAZIONE
PROGETTAZIONE&&VERIFICHE
VERIFICHE
SVILUPPO
(Rete
+OSS)
SVILUPPO (Rete +OSS)
IMPLEMENTAZIONE
IMPLEMENTAZIONE&&PROVE
PROVE
LANCIO
COMMERCIALE
LANCIO COMMERCIALE
Offerte/Vendite
Offerte/Vendite
Piazzamento/Esecuzione Ordinaz.
Piazzamento/Esecuzione Ordinaz.
Definizione
DefinizioneeeFirma
FirmaContratto
ContrattoSLA
SLA
Persona
+ SP
2.2.PROVISIONING
PROVISIONING
Installazione/Attivazione
Installazione/Attivazione
(Fornitura/Acquisizione)
(Fornitura/Acquisizione)
Utente =
Utilizzatore +
Cliente
3.3.USAGE
USAGE
Operational
Processes
(Transactional)
SIX PHASE
PRODUCT
DEVELOPMENT
ManTec
SERVICE DELIVERY
1.1.NEGOTIATION
NEGOTIATION
SP +
NO
Persone
(Potenziali
Utenti) + SD
Utilizzazione & Segnalazione
Utilizzazione & Segnalazione
(Erogazione/Fruizione)
(Erogazione/Fruizione)
Addebiti & fatturazione
Addebiti & fatturazione
Riscossione pagamenti
Riscossione pagamenti
Manutenzione/Riparazioni
Manutenzione/Riparazioni
Assistenza
AssistenzaTecnica
TecnicaPost-vendita
Post-vendita
Servizio di Call Center
Servizio di Call Center
4.4.RETIREMENT
RETIREMENT
Cliente
+ SP + NO
(Customized Service)
Utilizzatore
Attore
1.1.Segnale
Segnalevia
vialibera
libera
2.2.Digitazione
Indirizzo
Digitazione Indirizzo
3.3.Segnale
Segnalechiamata
chiamata
4.4.Inizio
utilizzo
Inizio utilizzo
5.5.Fine
Fineutilizzo
utilizzo
6.6.Rilascio
Rilascio
NTWK TECHNO-SERVICE
CCessazione
& Disinstallazione
essazione & Disinstallazione
(Service Session)
PdS Ciclo di Vita
Fig.4.4.3.1 Il “ciclo di vita” di un servizio TLC (il tempo scorre dall’alto verso il basso). Il Fornitore è sempre
presente, il Cliente appare all’ orizzonte del Fornitore allorchè si informa sui servizi offerti (vendite),
l’Utilizzatore appare all’orizzonte del Cliente allorchè il suo terminale viene attivato. Il servizio cessa di
esistere allorchè la sua infrastruttura tecnologica di supporto viene disabilitata o addirittura disinstallata.
svilupparsi in modo iterativo e non come una semplice sequenza temporale lineare(Vedi
dopo).
390
4.4.3.2
Specificità dei servizi TLC
Notare come abbiamo indicato con “Product Development” ciò che in effetti è
uno “Sviluppo Servizi”. Questo è stato fatto essenzialmente per evidenziare il fatto che
lo sviluppo dei servizi TLC può effettuarsi utilizzando metodologie industriali generiche
di “Product Development” adottate da industrie fornitrici di servizi e specializzandole ai
servizi TLC. La specializzazione si rende necessaria a causa di specificità dei servizi
TLC rispetto ad altri servizi pubblici (e.g. servizi bancari o servizi di trasporto aereo). Fra
le specificità più importanti menzioniamo il fatto che la fornitura dei servizi TLC
avviene
ii)
in mercati con particolari caratteristiche e origini storiche (e.g. monopolii e
conseguente regolamentazione dei mercati TLC liberalizzati da parte di
Authorities)
iii)
da un punto di vista operativo, con procedure di fornitura 24/7 (service
delivery)
molto complesse.
iii)
con caratteristiche di interoperabilità fra servizi e.g. supportati da reti
diverse in domini amministrativi diversi e, quindi, con un ruolo importante
giocato dai processi di standardizzazione dei servizi.
iv)
in presenza di regolamentazione ad hoc.
4.4.3.3
Una caratteristica dei servizi TLC: la produzione di una «Classe di Servizi»
da parte della TelCo come risultato del “Product Development”
Nal Capitolo 1 abbiamo evidenziato il fatto che una Telco, con una quota di
mercato stabile in un certo mercato di servizi TLC, (Telco di tipo “main stream”) deve
innovarsi costantemente nel tempo per far fronte ai cambiamenti PESTER, battere la
concorrenza e soddisfare le esigenze mutevoli degli Utenti. A tal fine essa sviluppa nuovi
servizi sulla base di studi di pianificazione che individuano le future esigenze di mercato
tramite una analisi dei mercati esistenti e dei loro trend di sviluppo e sulla base delle
proiezioni della domanda (intesa come identificazione di un bisogno più relativa capacità
di pagamento da parte di potenziali utenti). Si tratta di sviluppare nuovi servizi che
utilizzano tecnologie esistenti o tecnologie che richiedono lo sviluppo di tecnologie
innovative di natura incrementale e.g. tecnologie con miglioramento delle prestazioni
esistenti. (vedi Appendice 5 alla Parte 1)
Qui non viene preso in considerazione lo sviluppo di nuovi servizi basati su
“disruptive technologies” completamente nuove che presentano cambiamenti radicali
rispetto allo stato dell’arte e che prevedono la creazione di nuovi mercati completamente
diversi da quelli esistenti (Telco di tipo “start-up”). (Vedi Appendice 5 alla Parte 1)
La Fig.4.4.3.1 mostra come in una Telco tipo “main-stream” l’insieme di attività
di pianificazione e sviluppo di nuovi servizi possa rappresentarsi come un ciclo di
391
“Product Development” a sei fasi. (Vedi E.Ward, “World Class Telecommunications
Service Development”, Artech House, 1998, pag.42) durante il quale vengono
gradualmente e cautamente selezionati e sviluppati nuovi servizi. Esso inizia con una
“Analisi delle opportunità” dove, partendo da un insieme di “product concepts” iniziali,
si effettua una selezione preliminare (“Product funnel”) in base almeno ai seguenti criteri
1. “Market fit” within existing regulatory constraints, (è il prodotto adatto a
soddisfare i potenziali mercati individuati come mercati target pur nel rispetto della
normativa vigente?)
2. “Internal capabilities”, (esistono risorse interne sufficienti per supportare i
servizi proposti? è lo stato dell’arte tecnologico sufficiente o si devono sviluppare nuove
nuove tecnologie con prestazioni migliorate? è l’organizzazione nel suo stato attuale
pronta a fornire i servizi proposti o deve essere ri-ingegnerizzata? )
3. “Projected profitability” with due consideration of Corporate Social
Responsability (quale è l’ordine di grandezza del profitto previsto e i tempi dei ritorni
sugli investimenti necessari per i servizi proposti, tenendo sempre presente la
Responsabilità Sociale di Impresa?)
La fase 2 “Definizione e fattibilità” prosegue con una più esatta definizione dei
prodotti selezionati (creazione di blue prints) assieme ad una analisi di fattibilità dei
medesimi. E’ in questa fase che viene anche fatta un analisi di mercato dettagliata per i
servizi selezionati. La terza fase “Progettazione & Verifiche” prevede la progettazione
delle infrastrutture di supporto ai servizi selezionati e completa la parte di “thinking”
prima che inizi la parte di “doing” del Product Development. La quarta fase “Sviluppo”
prevede lo sviluppo dell’ infrastruttura di rete, gli OSS e l’approntamento della
“organizational preparedness” cioè l’approntamento all’interno della Telco delle risorse a
livello organizzativo per la transizione “product development team”-“service support
group” (i.e. il passaggio di responsabilità dal gruppo “Product Developmant” al gruppo di
assistenza tecnica post-vendita gestito dal dipartimento “Marketing&Sales”). La quinta
fase “Implementazione e prove” riguarda l’ “implementation into the market” del
servizio con le relative prove “alfa trials” in ambiente controllato e beta trials in
ambiente reale. Il tutto termina con il lancio commerciale del nuovo servizio.
Tranne alcune eccezioni, un nuovo servizio prodotto da una Telco non si riferisce
alle esigenze del singolo Utente bensì è mirato alle esigenze di una comunità di Utenti
caratterizzata da certe condizioni socio-economiche e una certa copertura geografica
(mercato target). Un nuovo servizio così ottenuto sarà in effetti un nuovo tipo di
servizio TLC mirato ad una certa classe di potenziali Utenti situati in un certo mercato
target e verrà incluso in un catalogo servizi offerto dalla Telco. Poichè è dedicato ad una
classe di Utenti, esso è anche denominato “Classe di Servizi” (Service Class). Ad
esempio una Classe di Servizi di tele-educazione può contenere corsi universitari di
diversi tipi e può essere mirata a cittadini italiani che, impegnati nelle ore diurne in un
lavoro, desiderano la sera aggiornare/espandere le proprie conoscenze professionali.
392
4.4.3.4
Fornitura del servizio all’Utente sotto forma «customizzata» (istanza di
servizio)
Dopo il lancio commerciale, una Telco mette a disposizione degli Utenti in un
catalogo servizi una Classi di Servizi (servizi di base e supplementari), specificandone le
caratteristiche tecniche e di fornitura, l’area geografica di disponibilità (« copertura » nel
caso di servizi via satellite o cellulari) e i prezzi (tariffe). Le caratteristiche tecniche e di
fornitura assieme ai prezzi costituiscono il valori di riferimento della Qualità di Servizio
fornita che verrà specificata/stipulata in un Service Level Agreement SLA .
Dal catalogo servizi il singolo Utente può scegliere il suo servizio
«customizzato». Il termine «customizzato » è un anglicismo che significa
«personalizzato all’Utente» (Customer). In questo corso useremo questo termine in
maniera del tutto generale cioè diremo che un servizio è customizzato quando la Telco :
1) deve possedere dati personali dell’Utente prima che il servizio venga erogato
e.g. nome, cognome, indirizzo residenziale, codice fiscale etc. e
2) caratterizza la fornitura del servizio tramite un “codice utente” e un indirizzo
in rete specifici dell’Utente e.g. numero telefonico, URL, etc.
3) specializza il «pacco» dei servizi offerti all’Utente ad personam includendo
solo quei servizi supplementari richiesti dall’Utente specificandone le caratteristiche e le
condizioni di fornitura in un contratto SLA. .
In altre sedi l’uso del termine «customizzato» è limitato a quei casi in cui il
servizio non è preso da catalogo bensì è strutturato di volta in volta, sulla base di
specifiche emesse dall’Utente. Noi caratterizzeremo questo tipo di servizio con
l’aggettivo inglese «custom-made».
In questo corso diremo che tutti i servizi telefonici forniti ai singoli Utenti sono
customizzati (perchè sono Personalizzati all’Utente) ma esistono casi speciali in cui i
servizi sono custom-made cioè non sono presi da un catalogo-servizi bensì sono realizzati
sulla base di speciche fornite dall’Utente. I servizi radiofonici forniti dalla RAI sono un
esempio di servizi TLC non customizzati. I servizi della televisione satellitare SKY fanno
parte di un «pacco» di servizi customizzati.
Quindi ogni Utente, quando si abbona ad un servizio TLC acquisisce una forma
customizzata di una «Classe di Servizi» precedentemente «prodotta» da un Fornitore
per una classe di potenziali Utenti (mercato target). Questo è vero per molti servizi TLC.
Per questi servizi è quindi importante distinguere concettualmente fra «servizio
customizzato» fornito dalla Telco al singolo Utente e «Classe di servizi»
precedentemente «prodotta» dalla Telco all’interno dell’impresa, mirata ad un certo
mercato target e descritta in un catalogo servizi a disposizione degli Utenti.
393
4.4.3.5
La “Service Delivery” di un servizio TLC
Dopo il lancio commerciale di una Classe di Servizi, che avviane alla fine della
fase di “Product Development”, inizia la fase di “Service Delivery” alla quale partecipa
inizialmente solo il Cliente e poi anche l’Utilizzatore.
L’ inizio della “Service Delivery” di un servizio TLC e’il momento in cui
iniziano le interazioni SP-Cliente cioè il momento in cui il Fornitore e il Cliente si
contattano per la prima volta. Notare che qui si parla di contatto Fornitore-Cliente e non
Fornitore-Utilizzatore. Infatti l’ Utilizzatore appare all’orizzonte solo dopo l’avvenuta
acquisizione del servizio da parte del Cliente. Più precisamente in una utenza business il
Fornitore conosce solo il Cliente e ignora completamente l’identità degli utilizzatori
interni all’utenza.
Per quanto riguarda la «fine della “service delivery” di un servizio TLC diciamo
che essa avviene allorché le risorse allocate per il servizio vengono rimosse e allocate
altrove. Ciò, a parte casi di morosità, avviene a seguito di una richiesta di cessazione del
servizio da parte del Cliente.
Nella fase di “Service Delivery” si riconoscono quattro fasi
1) NEGOTIATION Fase di negoziazione
Durante questa fase si svolgono le seguenti attivita’
1. Attivita’ di vendita (sales), durante la quale il Fornitore offre Classi di
Servizi tramite Catalogo
2. Attivita’ di pre-ordinazione (pre-ordering), durante la quale il
Fornitore offre ad un potenziale Cliente un servizio TLC custom made
sulla base di specifiche emesse dal Cliente
3. Il fornitore riceve dall’utente un ordinativo di servizio (o
ordinazione) per un servizio (service order), basato sull’informazione
ottenuta come risultato delle attivita’ di vendita o di pre-ordinazione,
4. Il fornitore risponde con un’ offerta (service offer) per uno o piu’
servizi e negozia le condizioni/qualita’/prezzi del servizio.
5. Se alla fine della negoziazione si raggiunge un accordo, entrambe le
parti sottoscrivono un contratto SLA (Service Level Agreement) in
cui sono specificate le caratteristche, condizioni, QoS, prezzi e termini
di pagamento relativi al servizio.
Quindi la fase di negoziazione inizia con il primo contatto utente-fornitore e
termina con la firma di un contratto SLA.
394
2) PROVISIONING Fase di approvigionamento
Questa fase contiene le interazioni Fornitore-Cliente necessarie all’installazione
del servizio definito nel contratto SLA, stipulato alla fine della fase precedente. In
questa fase il Fornitore deve implementare, configurare e testare il servizio. Alla fine
di questa fase, e in particolare dopo aver testato il servizio, se necessario si revisiona il
contratto SLA sulla base dei risultati ottenuti. La fase termina con una dichiarazione di
accettazione (Statement of Acceptance) del servizio da parte del Cliente
3) USAGE Fase di utilizzazione/fatturazione/manutenzione
In questa fase si verifica la effettiva utilizzazione/fruizione del servizio da parte
dell’Utilizzatore, il quale opera nell’ambito del contratto stipulato dal Cliente. .
L’utilizzazione del servizio e’ accompagnata da una serie di attivita’ gestionali atte a
garantire che l’utilizzazione del servizio possa avvenire con una “QoS fornita”,
specificata nel contratto SLA. Un esempio di queste attivita’ e’ la segnalazione di un
malfunzionamento da parte del Cliente e la risposta da parte del Fornitore che sono stati
presi provvedimenti per ovviare all’inconveniente assieme alla notifica del tempo
previsto per la riparazione del guasto.
4) TERMINATION Fase di cessazione (servizi) e disinstallazione (risorse)
Il servizio termina su richiesta del cliente o per iniziativa del fornitore in accordo
con le condizioni stipulate nel contratto con la cessazione del servizio e rimozione delle
risorse allocate al servizio
4.4.3.6
Attualizzazione di un servizio telefonico da parte dell’Utilizzatore:
«istanza di servizio» sottoforma di sessione di utilizzazione
La effettiva utilizzazione o fruizione di una istanza di servizio TLC da parte
di un Utilizzatore, avviene nella precedente Fase 3 (Fase di Utilizzazione) i.e. dopo la
fornitura del servizio al Cliente da parte della Telco e successiva
abilitazione/autorizzazione fornita dal Cliente all’Utilizzatore. Nel caso di una utenza
consumer i due ruoli di Cliente e Utilizzatore coincidono nella stessa persona fisica. La
attualizzazione di un servizio interattivo su base «chiamata», da parte di un singolo
Utilizzatore, si realizza come una sequenza temporale aperiodica di «sessioni di
utilizzazione» durante le quali
operano simultaneamente sia gli Utilizzatori
corrispondenti (almeno due) che l’Operatore di Rete (la Telco). Ad esempio nel caso di
una telefonata una sessione di utilizzazione comincia quando l’Utilizzatore spinge il
tasto «verde» sul telefono (una volta si diceva «alza il microfono»!), ascolta il segnale di
linea libera e digita un numero e finisce quando egli spinge il tasto «rosso» (una volta si
diceva «riattacca il microfono»!); quindi una sessione comprende le fasi di «richiesta»,
«conversazione» i.e. trasferimento di informazione di utilizzazione e «chiusura». In
questo corso ogni tipo di informazione che origina o viene raccolta da un Utilizzatore e
attraversa le reti TLC di utilizzazione/segnalazione viene classificata come nongestionale. Mentre gli Utilizzatori utilizzano un telefono (apparecchiatura terminale di
395
utilizzazione) per attualizzare un servizio, l’Operatore di Rete attualizza il servizio
trasportando/elaborando in tempo reale la «informazione di utilizzazione» eseguendo una
serie di processi interni supportati dalla rete telefonica. Più precisamente un Operatore di
Rete deve realizzare in tempo reale una «connessione circuitale» all’interno della rete
TLC che connetta i telefoni dei due Utilizzatori corrispondenti. A questo punto è bene
notare come una «sessione di utilizzazione» svolta a livello servizi sia possibile solo dopo
che sia stata realizzata una “connessione circuitale” a livello rete.
4.4.4
Conclusione: le tre dimensioni di un servizio TLC
Alla luce di quanto detto, in un servizio TLC, considerato come un prodotto
commerciale disponibile sul mercato, possiamo riconoscere tre «dimensioni» ortogonali:
una dimensione relazionale, una dimensione contenutistica e una dimensione di
qualità. (Vedi Fig.4.4.3).
La “dimensione relazionale”, come il nome suggerisce, è legata alle relazioni
SP-Cliente e NO–Utilizzatore. La prima relazione indica fornitura/acquisizione di una
capacita’/abilità (funzionalità) di svolgere una o più funzioni specifiche del servizio
stesso in modo efficace ed efficiente. Le funzionalità dei servizi sono dapprima
“prodotte” da una Telco per una classe di potenziali Utenti (mercato) e poi fornite,
sottoforma customizzata, ad un particolare Cliente che le acquisisce dopo aver firmato un
contratto (Service Level Agreement, SLA). Quindi nell’ambito dei servizi TLC si deve
distinguere fra
1) «Classe di servizi» prodotta da una TelCo per una classe di potenziali Utenti
in un certo mercato target e presentata in un Catalogo Servizi,
2) «Servizio customizzato all’ Utente» o istanza di servizio in genere prelevato
dalla Classe di servizi contenuta in un catalogo servizi, fornito da una TelCo a un Utente
in forma personalizzata e
3) «Sessione di servizio» quando l’Utilizzatore effettivamente attualizza il
servizio sottoforma di una serie temporale di “sessioni di telecomunicazione” di varia
durata.
La dimensione relazionale include fatturazione dei servizi forniti (da SP
all’Utente) e pagamento per i servizi fruiti (dall’Utente al SP)
La “dimensione contenutistica” di un servizio è, come il nome suggerisce, legata
al contenuto del servizio (Vedi par.4.3) laddove il servizio costituisce la specifica
«risoluzione di problemi» insorti presso l’Utente in conseguenza di desideri/bisogni di
telecomunicazione da soddisfare». Il “contenuto” di un servizio telefonico è l’
informazione audio scambiata fra Utenti corrispondenti. Il “contenuto” di un servizio TV
è un programma TV trasmesso da un trasmettitore TV a un televisore. In un servizio
internet i-Tube il “contenuto” del servizio è il programma video fornito al “cyber-world”
dall’Utente stesso.
396
In generale il contenuto del servizio deve essere fornito con una “Qualità di
Servizio” specificata in un contratto SLA sottoforma di “valori di rifermento” di certi
“parametri di servizio”. L’SP è contrattualmente impegnato a fornire un servizio che
rispetti i valori di riferimento pattuiti. Nel caso questi non vengano raggiunti vengono
applicate sanzioni/sconti secondo modalità specificato nel contratto SLA
Ricordiamo che un servizio TLC si svolge in un Ambiente Business ed è
“supportato” dalle risorse Business contenute in un sistema TLC prodotto in un ambiente
Engineering. Ricordiamo inoltre che, nel caso di Telco proprietaria di reti TLC esse
orniscono alla Telco tecnoservizi di rete. La Telco acquisisce un tecnoservizio di rete
dalle reti TLC aggiunge ad esso “valore”, e lo fornisce come servizio TLC all’Utente
finale. Ricordiamo, infine, che la funzionalità di utilizzazione di un servizio viene resa
attuale (attualizzazione del servizio) su richiesta dell’Utilizzatore finale attraverso l’
effettivo svolgimento delle funzioni tipiche del servizio stesso durante una sessione di
servizio.
RELAZIONE
“Funzionalità” fornite
da un Fornitore a un
Utente
ESSENZA
Risoluzione di un problema
insorto presso un Utilizzatore
in conseguenza di
desideri/bisogni di
telecomunicazione
da soddisfare
QoS
Fig..4.4.1 Le tre “dimensioni” di un servizio TLC
397
4.5 Modelli di servizi TLC: Modelli per funzioni
I servizi TLC, nelle loro componenti “essenziale” e “gestionale”, sono stati modellati
con modelli funzionali in termini di funzionalità/funzioni possedute/svolte
congiuntamente da TelCo e Utenti.
Allo stesso tempo si è riconosciuto che una TelCo è il gestore principale dei servizi
TLC e l’ utilizzatore dei relativi modelli gestionali. Si è quindi riconosciuto che la parte
gestionale di un servizio TLC si svolge all’interno di una TelCo ( o di una value network
di TelCo) sottoforma di processi gestionali che sono anche i processi di business della
TelCo stessa.
Conseguentemente, sono stati sviluppati modelli rappresentativi di funzioni
gestionali svolte in un contesto aziendale dotati di una struttura “per processi”, modelli
processuali. I modelli processuali offrono una rappresentazione di alto livello non solo
dei singoli processi di business ma anche di loro aggregazioni temporali (flussi operativi
end-to-end) finalizzate al conseguimento degli obiettivi di business di una TelCo e a
soddisfare le esigenze dei Clienti. Nel par. 4.5.1 parleremo dei modelli funzionali (MNM)
mentre nel par.4.6 parleremo dei modelli processuali (TMF).
4.5.1 Modello MNM (Munich Network Management) per la fornitura servizi:
modello generico e unificato per la “Service Delivery”
Abbiamo visto come esistano diversi servizi TLC ognuno con certe funzionalità
U&S che, su domanda, possono essere attualizzate nello svolgimento di funzioni atte a
risolvere i problemi degli Utenti che insorgono allorché essi decidono di soddisfare certi
desideri/bisogni di telecomunicazione. Affinchè ciò avvenga in modo efficiente/
efficace sia per il Fornitore (soddisfacimento di esigenze economiche e di mercato) che
per l’Utente (soddisfacimento di desideri/bisogni di telecomunicazione), è necessario
gestire queste funzionalità “essenziali” aggiungendo opportune funzionalità gestionali.
In linea di principio si potrebbe definire un modello gestionale specifico per
ogni scenario di servizio. Ad esempio, potremmo identificare modelli per la gestione
dei servizi telefonici pubblici PSTN, altri per la gestione dei servizi multimediali di
videoconferenza, altri per la gestione dei servizi internet, dei servizi VPN (Virtual
Private Network) etc. Ma questa molteplicità di gestioni diverse comporterebbe
l’inconveniente di dover adottare una moltitudine di modelli eterogenei, con duplicazioni
e, in definitiva, con scarsa cost-effettività complessiva. A fronte di queste difficoltà, nel
tempo si sono sviluppati modelli di gestione dei servizi TLC, per quanto possibile,
«generici» cioè indipendenti dal particolare scenario di servizio, e «modulari» in
maniera da facilitare eventuali specializzazioni (aggiunta moduli) e offrire
possibilità di riutilizzo (uso di stesso modulo in modelli diversi).
Nel tempo sono stati sviluppati modelli che offrono una rappresentazione
unificata delle funzionalità U&S e delle funzionalità di gestione e modelli che
rappresentano le sole funzionalità gestionali. Ad esempio il modello MNM (Munich
398
Network Management team dell’Università di Monaco, Germania) o il modello TINA del
consorzio TINA-C, sono modelli unificati mentre il modello gestionale TOM (Telecom
Operation Map) del TeleManagement Forum è un modello processuale che tratta delle
sole funzionalità/funzioni gestionali.
4.5.2 Il modello MNM a due ruoli: fornitore e utente (Fig. 4.5.2.1)
Supponiamo di voler creare un modello generico per la fornitura servizi TLC
utilizzando i concetti di Fornitore, Utente e contratto SLA stipulato da entrambi
Mettendo in evidenza l’ aspetto relazionale del servizio stesso
Il modello MNM rappresentato in Fig.4.5.2.1 non adotta nessun particolare
linguaggio rappresentativo standardizzato (sebbene esistano in letteratura vari linguaggi
adatti a questo scopo e.g. UML, Unified Modelling Language) ma usa un formato
rappresentativo informale che include la spiegazione testuale delle interazioni fra gli
elementi del modello (vedi FIg.4.4.2.1). Riteniamo questo formato poco rigoroso ma
particolarmente efficace da un punto di vista didattico.
acquisisce
Fornitore
realizza
fornisce
Implem.
Servizio
Utente
Servizio
fornisce
TU
SAP
accede a
specifica
condizioni,
qualita’ prezzi
stipula
Contratto
SLA
Dominio di responsabilita’del
Fornitore
stipula
PdS
Fig. 1.5.4.2 Modello generico di servizio. L’implementazione del servizio e’ separata
dal servizio, fa parte delle responsabilita’ del fornitore ed e’ “technology specific”.
Fig.4.5.2.1 Il modello MNM
399
Il modello servizi MNM mostra come i due ruoli fornitore e utente abbiano una
conoscenza condivisa (shared knowlwdge, in inglese) di un “Servizio” cioè quando si
parla di “servizio” entrambi sanno di cosa si parla. Tuttavia, essi «osservano» un servizio
da due punti di vista diversi che riflettono le loro diverse responsabilta’/interessi cioe’
essi hanno due «viste» diverse di un servizio.
Infatti, il FORNITORE deve rendere un servizio TLC disponibile all’ Utente nel
punto di accesso al servizio (Service Access Point), ed è ritenuto responsabile della
implementazione del servizio (realizzata con l’impiego di know-how, risorse umane,
piu’ hardware e software del sistema TLC di supporto) cioè egli vede il servizio come
fornitura di una capacità «tecnologicamente specifica». Al contrario l’ UTENTE vede
il servizio come acquisizione di una funzionalità che lo abilita allo svolgimento di una
certa funzione specifica del servizio in modo «tecnologicamente neutro», dietro
pagamento di una somma fissa mensile e/o di somme proporzionali ai consumi.
La fornitura/acquisizione di un servizio avviene spesso (ma non sempre) con la
stipula di un CONTRATTO, anche chiamato contratto SLA (Service Level
Agreement), nel quale vengono specificate le condizioni/qualita’/prezzo del servizio
concordate da fornitore e utente.
Abbiamo detto che un servizio viene percepito da un Utente come una
funzionalita’ tecnologicamente neutra che egli acquisisce da un Fornitore dietro
pagamento per i servizi fruiti sulla base di un contratto SLA. L’Utente, in linea di
massima, ignora le tecnologie implementative del servizio stesso. Infatti all’Utente non
interessa affatto conoscere la particolare soluzione tecnologica adottata per
l’implementazione di un particolare servizio. Tuttavia l’Utente, sebbene acquisisca con il
servizio una funzionalità tecnologicamente neutra, deve poter accedere al servizio
tramite apparecchiature tecnologicamente specifiche chiamate « Terminali d’Utente,
TU » (e.g. computer, telefono, fax, videocamera + monitor per videoconferenze etc.)
Per quanto riguarda il Fornitore servizi TLC il modello MNM assume, per
semplicità, che egli sia responsabile della implementazione del servizio utilizzando una
rete TLC di utilizzazione e della esportazione del servizio attraverso una interfaccia
specifica chiamata Service Access Point (SAP) (e.g. server, call center, etc.) utilizzando
un protocollo comunicativo specifico. Tutto cio’ e’ mostrato in Fig.4.5.2.1
4.5.3 Il modello MNM a tre ruoli: 1) fornitore, 2) cliente e 3) utilizzatore.
(Fig.4 3.5.3.1)
•
Lo sdoppiamento UTENTE = UTILIZZATORE + CLIENTE
Finora abbiamo considerato un modello MNM a due ruoli (2R), cioèun modello
semplificato contenente il minimo numero di ruoli perchè possa verificarsi una mutua
interazione. Tuttavia il modello 2R non è in grado di evidenziare la differenza che esiste
dal lato Utente fra «utilizzazione di un servizio» e «gestione di un servizio» cioe’ ignora
il fatto che il ruolo utente in pratica è costituito da due ruoli ben distinti, utilizzatore e
400
cliente giocati rispettivamente da chi utilizza e chi gestisce il servizio. Un modello a tre
ruoli (3R) e’ mostrato in Fig. 4.5.3.1 e si ottiene dal modello a due ruoli sdoppiando l’
utente in due ruoli distinti e complementari, cliente e utilizzatore. Gli aspetti gestionali
di cui si occupa il Cliente sono già stati trattati in precedenza.
•
Lo sdoppiamento : SERVIZIO = FUNZIONALITA’ di UTILIZZAZIONE +
FUNZIONALITA’ CUSTOMER CARE.
Il modello a 3 ruoli di Fig. 4.5.3.1 mostra che oltre alla suddivisione dell’Utente
in Cliente-Utilizzatori , anche l’insieme di interazioni relative alla fornitura del servizio S
è suddiviso in un gruppo di funzionalità gestionali qui denominate Funzionalità
Customer Care (FCC) e un gruppo di funzionalità U&S qui denominate Funzionalità
di Utilizzazione (FU), entrambe fornite dal Fornitore con un QoS in linea con quello
specificato nel contratto SLA. Qui assumiamo, per semplicità’, che il cliente acquisisca
uno stesso servizio con certi parametri QoS per tutti gli utilizzatori nella sua comunità e
che questi parametri siano specificati in un unico contratto SLA. Il diamante in Fig.
4.5.3.1 è un simbolo grafico indicativo di «aggregazione».
In Fig. 4.5.3.1 il Fornitore servizi TLC non è stato esplicitamente sdoppiato in due
ruoli separati come fatto per il lato Utente ma è stato semplicemente indicato come
Fornitore/Gestore per ricordare che in questo modello egli fornisce la FU agli Utilizzatori
(e.g. fornitura servizio telefonico) e funzionalità FCC al Cliente (e.g. invio/pagamento
fatture, domande/risposte relative a reclami etc.).
•
Implementazione Utilizzazione Servizi (IUS)
Il modello a tre ruoli di Fig. 4.5.3.1 mostra come anche l’implementazione
tecnologica dei servizi sia sdoppiata in implementazione utilizzazione servizi (IUS) e
implementazione gestione servizi (IGS) .
Fanno parte delle risorse IUS e.g. rete U&S anche le tecnologie dell’interfaccia
SAP (Service Access Point). Ad esempio nel caso di un servizio internet il SAP coincide
col PoP (Point of Presence) del Fornitore ISP (Internet Service Provider) ubicato nella
stessa area urbana dell’Utente. Notare la differenza fra il punto di accesso al servizio SAP
e il punto di accesso alla rete NAP (Network Access Point) che nella fattispecie coincide
con l’interfaccia UNI (User Network Interface) fra computer (apparecchiatura terminale)
e modem (terminale di rete). In un PoP moderno collegato ad una dorsale in fibbra ottica
tramite un edge router appaiono unità funzionali del tipo softswitch e gateway.
401
CRM.AP
accede a
TC
controlla
fornisce
IGS
utilizza
FCC
realizza
Fornitore
&
Gestore
gestisce
osserva
Cliente
Par
QoS
realizza
fornisce
Utilizzatore
FU
IUS
fornisce
specifica
accede a
SAP
stipula
1:n
S
Contratto
(SLA)
Dominio di responsabilita’ F/G
utilizza
TU
stipula
Dominio di responsabilita’ C/U
Fig. 4.5.3.1 Modello MNM a tre ruoli.
402
•
Implementazione Gestione Servizi (IGS)
Anche la implementazione della funzionalità di gestione (IGS) i.e. le
tenologie OSS è responsabilità del Fornitore servizi TLC. La IGS permette la
realizzazione dei processi relativi alla funzionalità FCC ma allo stesso tempo si occupa
della gestione delle risorse U & S (cioè contiene anche tecnologie NSS). Inoltre
implementa la interfaccia CRM.AP (Punto di Accesso per la Gestione Relazioni Clienti)
con il Cliente. L’osservazione dei parametri QoS è indicata in Fig. 4.5.3.1 con linee
tratteggiate per indicare che non coinvolge interazioni fornitore-cliente/utilizzatore come
per le altre funzionalità. Tuttavia, come le altre funzionalità, i parametri QoS sono
indipendenti dalle particolari tecnologie implementative adottate in IS e IGS: essi sono
tecnologicamente neutri.
•
Lo sdoppiamento dell’interfaccia fornitore-utente : SAP = SAP + CRM.AP
Anche il punto di accesso SAP è sdoppiato in due punti di accesso, SAP (Service
Access Point) e CRM.AP (Customer Relation Management Access Point). Attraverso il
CRM.AP il cliente ha accesso (limitato!) alla funzionalita’ di gestione realizzata dalla
IGS (e.g. gestione guasti). Attraverso il SAP l’utilizzatore ha accesso alla funzionalita’
FU del servizio fornito. Il cliente e l’utilizzatore (utente) accedono al CRM,AP e SAP
tramite il Terminale Cliente (TC) e il Terminale Utilizzatore (TU). Ovviamente le
tecnologie dei terminali di accesso e dei punti di accesso devono essere compatibili. Ad
esempio, in un servizio internet e-commerce, TU è un computer e il SAP è un server. Il
CRM.AP può essere un call-center accessibile da un cliente per via telefonica (cioè TC è
un telefono).
La Fig.4.5.3.2 è una modifica della Fi.4.5.3.1 che evidenzia la composizione di
un servizio TLC in funzionalità U&S (tecnoservizi di rete) attuate in funzioni U&S da un
Utilizzatore tramite terminali di utilizzazione e funzionalità di gestione attuate da un
Cliente in giunzioni di gestione tramite terminali di gestione (non necessariamente ICT,
e.g. ufficio postale o sportello bancario)
403
à TelCo(persona giuridica reale)
Dominio di responsabilit
BSS
utilizza
(Business
)
Resource
Dominio di Utenza
AMBIENTE
BUSINESS
Enterprise
Manager
SERVIZIO TLC
Utente
ServiceProvider(SP)
SAP
FINAL PRODUCT
(NtwkService+
ServiceDelivery)
Tecnoservizio
U&S
RETI
U&S
utilizza
Funzionalità U&S
(NetworkService)
fornisce
possiede
Tecnoservizio
Gestione
Servizi
OSS
Funzionalità di Gestione
(ServiceDelivery)
stipula
SLA
acquisisce
Comunità di
utilizzatori
Cliente
Ufficio legale
Ammistrazio
ne Finanza
CRMAP utilizza
TC
stipula
gestisce
interconnette
(FCAPS)
2
LAN
3
opera
gestisce
Utilizzatore
TU
Integrazione
OSS-NSS-OS
NSS/OS
(FCAPS)
gestisce
Ntwk
Operator
(NO)
1
utilizza
ISM
AMBIENTE
ENGINEERING
Mondo TLC
Fig. 4.5.3.2 I tecnoservizi di rete nel contesto di una “Fornitura/Acquisizione di un servizio TLC”: Il modello
“Mondo TLC” rappresenta la fornitura di un servizio TLC come trasferimento di due tipi di funzionalità:
Funzionalità U & S e Funzionalità di Gestione. Questo permette di affermare che: Come un sistema TLC
osservato da un Punto di Vista SP/Utente mostra “risorse U&S” e “risorse di gestione”, le seconde con un
ruolo di supporto rispetto alle prime, così un servizio TLC fornito da un SP a un Utente contiene
“funzionalità U&S” e “funzionalità di gestione”, le seconde con ruolo di supporto rispetto alle prime.
Metaforicamente il modello assume che la funzionalità U&S sia “impacchettata” (“Packaging process”)
all’interno di un “Delivery package” costituito dalle funzionalità gestionali. Per attività di “Gestione di un
servizio TLC” si intende lo svolgimento delle Funzioni di Gestione i.e. l’ attualizzazione delle Funzionalità di
Gestione condivise da Fornitore e Cliente e supportate dalle tecnologie OSS. Le frecce verticali puntate verso
l’alto che attraversano il confine Ambiente Engineering-Ambiente Business rappresentano Tecnoservizi
forniti da tecnologie ICT. La QoS percepita dall’ Utente del servizio TLC, e quindi il suo livello di
soddisfazione, dipende in gran parte da come la funzionalità U&S viene “impacchettata” e “consegnata” cioè
dipende molto dalle funzionalità di gestione e.g. modalità di pagamento, competenza degli addetti al Call
Center, prontezza nella riparazioni, accuratezza delle bollette mensili etc. Le Reti U&S e gli OSS sono
Tecnologie ICT fornitrici di Tecnoservizi nel dominio amministrativo della TelCo. SAP=Service Access
Point, CRMAP=Customer Relation Management Access Point. TU = Terminale di Utilizzatore, TC =
Terminale di Cliente.
404
4.6
4.6.1
Modelli di servizi TLC: il modello processuale
TOM (Telecommunication Operations Map) del
TMF (TeleManagement Forum)
Limitazioni degli standards TMN.
Nel Capitolo 3 abbiamo descritto un modello gestionale standardizzato del ITU-T
(Rec. M.3010) denominato modello TMN stratificato (Logical Layered Architecture)
suddiviso in quattro strati orizzontali relativi alle gestioni di elementi di rete, reti, servizi
e impresa. I contenuti funzionali di questo modello (servizi/funzioni gestionali) sono
stati poi rappresentati nel modello FCAPS anch’esso dell’ITU-T (Rec.M.3400)
strutturato nelle cinque ripartizioni verticali Fault, Configuration, Administration,
Performance, Security (da cui il nome FCAPS). La sovrapposizione dei due modelli ha
dato luogo al cubo di Rubik mostrato in Fig.3.4.1. Studieremo con più dettaglio entrambi
i modelli nella seconda parte del corso come applicazione dello standard gestionale OSISM (Open Systems Interconnection-System Management) anch’esso dell’ITU-T.
Qui vogliamo anticipare il fatto che questi modelli gestionali furono sviluppati
venti anni fà principalmente per dare la possibilità a gestori di reti TLC di gestire
tecnologie di rete diverse con uno stesso standard gestionale e quindi, sotto molti punti di
vista, risultarono subito inadeguati a modellizzare la “Gestione TLC” (con la G
maiuscola) intesa in senso moderno come gestione integrata di elementi di rete, reti,
servizi e impresa in ambito TelCo. Ma esaminiamo con più attenzione quest’ultimo
punto.
4.6.1.1
Il modello TMN è “resource-centric” e riflette gli interessi dei gestori di reti
pubbliche (PTT) degli anni ottanta.
Il modello TMN fu creato negli anni 70 per offrire ai gestori di reti pubbliche
(PTT) la possibilità di gestire reti TLC eterogenee con uno stesso sistema di gestione.
Una delle critiche più severe al modello TMN è che esso è un sistema rigido
costituito da una normativa standardizzata estremamente dettagliata, per la maggior parte
relativa alla gestione delle tecnologie ICT abilitanti cioè reti e elementi di rete. Infatti, il
modello TMN stratificato, fiore all’occhiello della filosofia TMN, non è capace di
modellare in modo soddisfacente i due strati più alti cioé lo strato relativo alla gestione di
impresa e quello relativo alla gestione servizi. Questa mancanza appare oggi intollerabile.
In letteratura si legge che il modello TMN é “resource centric” cioé focalizzato sulle
risorse fisiche (i due strati più bassi nel modello stratificato TMN) piuttosto che
“customer centric” cioé focalizzato sulla gestione dei servizi e delle relazioni clienti
(CRM, Customer Relations Management).
405
4.6.1.2
Il modello TMN non è adatto alla gestione integrata reti-servizi
Inoltre lo standard TMN non modellizza in maniera soddisfacente le interazioni
fra strati, in particolare fra lo strato gestione di rete e lo strato gestione servizi. E’ proprio
una buona modellazione di queste interazioni che è necessaria per realizzare la “Gestione
TLC” in senso moderno.
Più specificatamente, nello standard TMN non sono modellati i meccanismi di
accoppiamento gestione reti-gestione servizi per le varie aree funzionali FCAPS. Ad
esempio per l’area funzionale “Guasti” (Fault), un guasto a livello elemento di rete causa
una degradazione della qualità di servizio (QoS) a livello servizi. A sua volta questa
degradazione del QoS potrebbe innescare in tempo reale una notifica di guasto agli Utenti
interessati o al fornitore partner interessato (segnalazione di guasto proattiva). Tutto ciò
non è modellato da TMN. Un altro esempio: nell’area funzionale FCAPS “Accounting”
non è modellata l’interazione fra funzioni di “raccolta dati relativi ai consumi” a livello
elemento di rete e le funzioni di fatturazione (“billing”) a livello servizi.
Il dettaglio del modello/standard TMN sembra quindi fortemente sbilanciato a
favore della gestione reti, a scapito della gestione servizi e relativa integrazione gestione
reti- gestione servizi.
Ma il problema é molto più complesso che la semplice inadeguatezza degli
standards ad una Gestione che includa le interazioni fra vari strati TMN. Infatti in tempi
più recenti è emersa la necessità di creare un nuovo modello di gestione di sistemi/servizi
TLC che vada oltre il modello “resource centric” (bottom-up) e che invece sia “customer
centric” (top-down). Per far ciò bisogna dapprima rivedere gli sviluppi più recenti nel
settore TLC cioè dove si trovano le entità da gestire. In particolare vogliamo rivedere i
cambiamenti dei sistemi TLC in risposta ai cambiamenti PESTER a cavallo degli anni
80-90 in particolare i cambiamenti verificatisi nei mercati TLC e nelle tecnologie ICT
(Vedi Tav.4.6.1). Qui di seguito adotteremo il termine “mercato” nel senso di una
comunità di compratori e venditori di servizi TLC che interagiscono mutuamente.
4.6.2
4.6.2.1
I nuovi mercati TLC e la re-ingegnerizzazione dei processi di business
(Business Process Re-engineering, BPR)
I mercati TLC negli anni ottanta
Come già visto negli anni ottanta il mercato TLC era un mercato “fortemente
regolamentato” in cui le Telco erano autorizzate ad operare nel rispetto di regolamenti
molto stringenti, stabiliti da enti governativi a livello nazionale, come la Federal
Communication Commission (FCC) negli USA, oppure a livello internazionale, come la
International Telecommunication Union (ITU). Notare che un “regolmento” contiene
una serie di norme relative alla natura e le caratteristiche tecniche dei vari servizi e,
prima di poter fornire un servizio, una TelCo deve ottenere una autorizzazione (licenza)
rilasciata dalle autorità (nazionali o internazionali) competenti.
406
CAMBIAMENTI nei MERCATI
TLC
ANNI ‘80
ANNI ‘90
Regolamentazione
Nazionalizzazione
Mono/Oligo-polio
Centralizzazzione
1.
2.
3.
4.
5.
6.
7.
CARATTERISTICHE MERCATO TLC ANNI 90
Globalizzazione
Diversificazione
Deregol./Privatizazione
Decentralizzazione
Alleanze Strategiche
Nuovi imprenditori
Innovazione tecnologica
BPR
CUSTOMER CARE
Ambiente Multi-vendor, Multi-provider
Economia di Mercato
Alta competitività
INTEGRAZIONE
PROCESSI BUSINESS
AUTOMAZIONE
PROCESSI BUSINESS
Tavola 4.6.1
407
Negli anni ottanta molte TelCo erano nazionalizzate (cioe’ con
partecipazione maggioritaria dei rispettivi governi nazionali), operavano in un regime
di monopolio o oligopolio (cioe’ “uno solo” o “pochi” di essi controllavano tutto un
mercato nazionale) e adottavano strutture aziendali fortemente centralizzate.
4.6.2.2 I mercati TLC negli anni novanta
Negli anni novanta, i mercati TLC e, conseguentemente, le TelCo che
operavano in questi mercati, subiscono mutamenti profondi, caratterizzati da :
1) globalizzazione (e.g. espansione del mercato target di una TelCo su scala
globale),
2) diversificazione su base geografica (i.e. una TelCo accudisce un insieme
di mercati in diverse parti del mondo, con caratteristiche diverse a seconda del livello
di sviluppo socio-economico locale).
3) deregolamentazione/privatizzazione (e.g. le TelCo possono operare sulla
base di regolamenti meno restrittivi cioè usufruire di una liberalizazzione
dell’accesso ai mercati e/o essere privatizzate cioè essere il risultato di un processo di
privatizzazione di organizzazioni precedentemente controllate da governi nazionali),
4) formazione di alleanze strategiche TelCo-TelCo e TelCo-ICTS con o
senza expertise complementare (e.g. fusione di piccole industrie in grosse industrie
e/o di industrie nazionali in industrie muti-nazionali sulla base di mergers, joint
ventures, parterships etc.),
5) inserimento di nuovi imprenditori (new entrants) con business dedicati a
mercati di nicchia (mercati relativi a prodotti/servizi molto specializzati),
6) decentralizzazione della struttura organizzativa della TelCo per rispondere
in modo più rapido ed efficiente alle richeste di un mercato diversificato su base
geografica nazionale, continentale, globale
7) innovazione tecnologica IT (Information Technology) con sviluppo
vertiginoso e drastica riduzione dei costi delle tecnolgie informatiche distribuite
(hardware, software, rete) di supporto ai sistemi TLC.
In definitiva, tutti questi fenomeni contribuirono ad ampliare e diversificare il
mercato TLC creando un ecosistema multi-vendor, multi-SP (cioé con molteplicità di
venditori di apparati e fornitori di servizi) nel quale i vari partecipanti operavano in
un regime di economia di mercato caratterizzato da alta competitività.
408
4.6.2.3
I cambiamenti dei mercati TLC inducono cambiamenti nei processi di
business all’interno di una Telco: la filosofia BPR.
Negli anni 90 i mutamenti del mercato TLC indussero cambiamenti
importanti sui processi di business delle TelCo sia all’interno che verso l’esterno.
Infatti l’avvento di una economia di mercato ad altissima competitività porta
inizialmente ad una espansione della offerta servizi con l’ introduzione di nuovi
servizi a valore aggiunto, poi, quando i servizi a valore aggiunto diventano così
popolari da perdere la loro caratteristica di differenziatore competitivo, porta ad un
rafforzamento della funzione “Assistenza Clienti” (Customer Relation
Management, CRM) in termini di accuratezza, dettaglio dei servizi offerti (e.g.
servizio cataloghi prodotti/servizi), profondità di inserimento del cliente nella
struttura informatica dell’azienda e.g. aumento di visibilità da parte del cliente dei
processi di fatturazione, rapidità di risposta e personalizzazione (o «customizzazione») della risposta.
L’aumento di complessità della CRM effettuata in modo cost-effettivo e il
simultaneo progresso/riduzione dei costi delle tecnologie informatiche portò
inevitabilmente ad un graduale inserimento dell’automazione nei processi aziendali.
L’espansione/automatizzazione della CRM comportò una revisione
significativa dei modelli di business tradizionali, da resource centric a customer
centric, con ristrutturazione e automazione dei relativi processi di business. Questo
processo di revisione è una filosofia aziendale che va sotto il nome di Reingegnerizzazione dei Processi di Business, Business Process Reengineering o BPR
(anche chiamato Ri-organizzazione dei Processi Aziendali). Notare che quando si
parla di BPR in generale si fa riferimento a grossi cambiamenti rispetto ai processi di
business tradizionali cioé si tratta di uno di quei cambiamenti che la letteratura
inglese definisce “paradigm shift” cioé “un cambio di paradigma”.
Vedremo in questo capitolo come la ristrutturazione/automazione dei processi
aziendali effettuata secondo la filosofia BPR ha avuto un notevole impatto
sull’architettura dei modelli realtivi a una gestione integrata reti/servizi/
clienti/impresa.
4.6.2.4 L’importanza dell’utente e la «customizzazione» dei servizi
Vogliamo ribadire il concetto che in un modello di impresa customer centric,
cioé incentrata sul cliente, una TelCo non solo prende coscienza dell’importanza delle
richieste del cliente ma la comunità dei clienti é il motore primo che regola il rapporto
cliente-fornitore di servizi cioé nell’ambito di questo rapporto l’utente giuoca un
ruolo prioritario. La comunità degli utenti ha una forte influenza su «dove, quando,
come» si devono fornire i servizi. In definitiva, é la natura/volume della domanda
formulata da comunità di clienti il fattore che determina le politiche dei fornitori di
servizio, la natura delle loro offerte di servizi e la scelta delle tecnologie e/o di
eventuali alleanze strategiche con altri fornitori partner. Inoltre le relazioni con i
409
clienti, per costituire un margine competitivo devono essere molto specializzate o, al
limite, personalizzate (custom-made).
Ad esempio, una gestione clienti
specializzata per le categorie di clienti “dettaglio”, “ingrosso” e “affari”, é una
gestione che tiene conto dei seguenti fattori, :
I clienti al dettaglio vogliono un vasto ventaglio di servizi, a basso prezzo e
qualità “accettabile” (e.g. servizi internet dove il cliente è pronto a tollerare qualità di
servizio assolutamente scadenti!) ma con una assistenza tenico-commerciale facile da
ottenere, pronta e accurata. Quindi servizi con grande enfasi sui prezzi e sulle
relazioni clienti.
I clienti all’ingrosso vogliono acquistare “blocchi di servizi” a prezzi
“all’ingrosso” (“bulk prices”) ma con un accesso diretto all’infrastruttura gestionale
molto più profondo e diversificato di quello disponibile in passato. Tutto ciò per
poter incrementere le loro capacità gestionali e lucrare su di esse aumentando il
valore dei servizi forniti ai loro clienti.
I clienti affari (grosse aziende, banche, enti governativi) vogliono piu’ servizi
a valore aggiunto anche con costi medio/alti ma con caratteristiche spinte di qualità di
servizio e sicurezza. L’enfasi in questo caso é sulla qualità e sicurezza dei servizi
talvolta pagate ….. profumatamente!
4.6.2.5
La BPR richiede integrazione e automazione dei processi di business.
L’obbiettivo principale del BPR fu il raggiungimento del successo economico
dell’impresa (qui non si parla di performance socio-economica-ambientale!) e
l’acquisizione di quote di mercato crescenti in un mercato TLC caratterizzato da alta
competitività, eterogeneità di tecnologie e dove la CRM gioca un ruolo prioritario.
Secondo la filosofia BPR, i margini di competitività e la differenziazione
dei servizi necessari a
1) vincere la concorrenza,
2) ampliare le quote di mercato i.e. incrementare la percentuale del mercato
acquisita e
3) mantenere/migliorare la “fidelizzazione” del cliente i.e. assicurarsi che un
cliente rimanga un cliente “soddisfatto” per lunghi periodi di tempo.
vanno ottenuti tramite una integrazione dei processi di business basata su nuove
tecnologie automatizzate e dove la gestione dell’ interfaccia cliente ha un carattere
prioritario.
410
i)
Integrazione
In particolare, la gestione integrata é basata sulle integrazioni “gestione
clienti-gestione servizi”, “gestione servizi-gestione reti” e sull’integrazione con le
gestioni effettuate da altri fornitori partecipanti nella fornitura dello stesso servizio
(gestori corrispondenti o partner).
ii)
Automazione
La automazione dei processi di business èottenuta tramite attivazione di due
abilitatori tecnologici:
1) digitalizzazione (elaborazione numerica) dei processi aziendali
2) messa in rete dei processi.
Ovviamente, al giorno d’oggi, “rete” significa essenzialmente “rete internet”,
sia essa di prima o di seconda generazione.
L’automazione dei processi aziendali in presenza di una struttura
organizzativa d’impresa decentralizzata e la necessità di integrare tecnologie
eterogenee in modo costeffettivo richiedono l’uso di tecnologie DOC (Distributed
Object Computing) cioè l’adozione di una architettura gestionale che abbiamo
precedentemente chiamato “fortemente distribuita” (Vedi Cap.3).
4.6.2.6
I nuovi modelli gestionali basati sulla filosofia BPR.
In definitiva, la re-ingegnerizzazione dei processi di business nelle aziende
TLC effettuata applicandom la filosofia BPR richiede che i nuovi modelli gestionali
tengano conto delle seguenti considerazioni:
1)
la gestione di rete é necessaria ma non sufficiente a vincere la
competizione e acquisire una quota di mercato TLC che porti a
valori soddisfacenti dei rapporti ritorni/investimenti (ovviamente
aggiustati per il rischio). La gestione di rete, gloria del passato, é
in generale effettuata con tecnologie legacy (e.g. OSI-SM).
2)
la gestione di rete va integrata con la gestione servizi in una
architettura gestionale scalabile, flessibile e sicura. Le varie
componenti della gestione servizi (processi gestionali servizi)
vanno a loro volta integrate fra loro in modo da presentare un unica
interfaccia servizi al cliente. La gestione servizi deve tener conto
della struttura organizzativa decentralizzata tipica di una moderna
azienda TLC
e della eterogeneità delle tecnologie gestionali
impiegate. All’uopo si possono usare le nuove tecnologie
computazionali a oggetti distribuiti (DOC, Distributed Object
411
Computing) integrate con i sistemi di gestione flussi di lavoro
(WFMS, Work Flow Management Systems).
3)
la gestione servizi va integrata con la gestione assistenza clienti
(CRM) partendo dalle esigenze del cliente, sulla base di un
modello di gestione customer centric.
4)
la gestione effettuata da un fornitore di servizi va integrata con
quella di altri fornitori partner in modo da offrire un servizio «one
stop shopping» al cliente cioe’ un servizio in cui il cliente paga un
unica fattura che tiene conto di tutti i vari fornitori di servizi che
intervengono nella fornitura di un servizio.
5)
la gestione integrata rete-servizi va automatizzata, per quanto
ragionevole e costeffettivo, con tecnologie informatiche digitali
(digitalizzata) utilizzando reti di comunicazione dati (e.g. internet)
in modo da poter sfruttare al massimo i recenti sviluppi nel campo
delle tecnologie IT. In particolare é importante utilizzare le piu’
recenti tecnologie computazionali a oggetti distribuiti e.g.
Distributed Object Computing (DOC).
6)
le nuove tecnologie gestionali devono essere compatibili con
l’esistenza di tecnologie legacy e devono essere tali da non
diventare a loro volta tecnologie legacy che richiedono nuove
BPR nel giro di pochi anni. Poiché le TelCo non possono
permettersi il lusso di re-ingegnerizzare il prorio business ogni
cinque o sei anni, é necessario che, mentre l’innovazione
tecnologica IT è molto dinamica con cicli di vita tendenzialmente
sempre piu’ brevi, le nuove applicazioni gestionali dei processi di
business (« soluzioni di business ») siano stabili nel tempo con
cicli di vita piuttosto lunghi. Questo significa che le soluzioni di
business e gli standards adottati devono essere per quanto possibile
technology neutral (cioé la stessa soluzione può essere realizzata
con tecnologie diverse) e essere sviluppate in base agli
obiettivi/requisiti di business di medio/lungo termine e non in
base alle tecnologie disponibili. Quest’ultimo punto é importante.
Ad esempio si deve evitare che progetti R&D di sviluppo di
software gestionale in risposta al BPR si riducano a progetti privi di
utilità, già obsoleti prima del loro completamento. Quindi il punto
di partenza di ogni progetto BPR é la determinazione esatta di
specifici obiettivi di business di medio/lungo termine. La
soluzione di business va poi trovata sulla base di questi requisiti.
7)
Infine un concetto che in qualche modo é legato al precedente.
L’implementazione della BPR é basata sull’utilizzazione di
tecnologie “fortemente distribuite”. Tuttavia, ci vuole cautela:
412
prima di adottare queste tecnologie é necessario determinare con
esattezza i requisiti di business che richiedono il loro uso e poi
essere consapevoli e tener conto delle complessità e difficoltà
associate con l’uso di queste tecnologie.
4.6.3
Il modello “Telecommunications Operations Map, TOM” del TMF (TeleManagement Forum)
Come indicato nel Capitolo 1 un modello processuale per la gestione “retiservizi-customer care” (Gestione TLC) da utilizzare nei flussi operativi end-to-end di una
TelCo é stato introdotto dal consorzio internazionale Tele-Management Forum (TMF).
Un primo passo nella direzione della automazione dei processi di Gestione TLC é
la creazione di un modello di riferimento che specifichi/standardizzi i processi di
business da integrare nei flussi di processi operativi end-to-end (vedi Capitolo 1)
necessari per soffisfare le richieste dei clienti (fornitura di “customer services”) in
maniera efficace/efficiente. La difficoltà principale che si incontra nella creazione di un
modello di riferimento generico é rappresentata dal fatto che TelCo diverse adottano
diversi processi di business. Come indicato nel Capitolo 1 il Tele-Management Forum
(TMF), organizzazione internazionale con una vasta base industriale, con la cooperazione
di tutti i suoi membri, ha superato queste difficoltà ed ha prodotto la Telecom Operation
Map, TOM, mostrata in Fig.4.6.3.1 (Vedi: “Telecom Operations Map, TOM” TMF Doc.
No.GB910, Approved Version 2.1, March 2000). Questa mappa fu introdotta
inizialmente nel 1995 ed è basata sul “modello di business” mostrato in Fig.4.6.3.2.
Illustreremo il modello di business in questa sezione e la TOM nella sezione seguente.
Il modello processuale TOM è valido per tutte le TelCo che partecipano ad un
modello di business del tipo mostrato in Fig.4.8.3.2
1. Utenti ,
2. TelCo Retailers o Wholesalers
3. ICT Vendors
Il modello di business di Fig. 4.6.3.2
identifica tre interfacce:
é un modello molto semplificato che
1) cliente servizi (finale)- fornitore servizi (al dettaglio)
2) fornitore servizi – venditore ICT
3) fornitore servizi – altri fornitore servizi (partners o wholesalers)
L’interfaccia cliente finale - fornitore servizi al dettaglio é rilevante alla gestione
delle relazioni clienti (Customer Relation Management, CRM). L’interfaccia fornitore
servizi - fornitore servizi caratterizza l’infrastruttura per alleanze strategiche fra diversi
fornitori, come dettato da un mercato dominato da concorrenza/collaborazione.
413
CLIENTE
Processi Gestione Interfaccia Cliente
Vendite
Ordini
Reclami
Gest. QoS
Cliente
Fatture. &
Incassi
Processi “Customer Care”
Gestione
Servizi
Pian. &
Sviluppo
Servizi
Configur.
Servizi
Trattam.
Guasti
Gest. QoS
Serv.
Tariffe/
Sconti
Processi Sviluppo/Manutenzione Servizi
Gestione
Reti
Pian. &
Sviluppo
Reti
Approvvigionam.
Rete
Gest.
Inventario
Rete
Manut. &
Rest. Rete
Gestione
Dati Rete
Processi Gestione Reti e Sistemi
Modello FAB
FULFILLMENT
ASSURANCE
GESTIONE ELEMENTI RETE
Fig.4.6.3.1 Telecom Operations Map
ELEMENTI RETE
414
BILLING
CLIENTE
FORNITORE
(Retailer)
ICT VENDORS
(di tecnologie
SW & HW)
Altri FORNITORI
(Wholesalers e Partners)
Altri ICT VENDORS
(Third Party)
Fig.4.6.3.2 “Modello di Business” TMF a tre interfacce. Le frecce indicano
relazioni di business.
415
CATENA DEL VALORE (VALUE CHAIN)
TELCO WHOLESALER
RISORSE
(Tecnologie ICT)
ICT VENDOR
OPERATORE
RETE
FORNITORE
SERVIZI
(INGROSSO)
FORNITORE
SERVIZI
(RETAILER)
Fig.4.6.3.3 La creazione del valore: dalle tecnologie ICT al cliente.
416
CLIENTE
La Fig. 4.6.3.3 mostra una rappresentazione alternativa delle relazioni che intercorrono
fra elementi di business, ordinata, da sinistra a destra, in base al «valore crescente per il
cliente» dei prodotti/servizi generati da ciascun elemento, partendo dalle risorse e
arrivando al cliente finale fruitore dei servizi. In questa figura viene utilizzata una
rappresentazione più dettagliata degli elementi di business, infatti i fornitori sono divisi
in fornitori all’ingrosso e al dettaglio mentre i venditori sono sdoppiati in venditori di
apparati e operatori di rete. Questo tipo di rappresentazione si chiama «value chain»
(Vedi Appendice 7 alCapitolo 1).
4.6.3.1 Flussi di Processi (Process flows) interni e esterni
In una TelCo i flussi di processi di business per la Gestione TLC sono classificati
in esterni e interni . I primi coinvolgono il Cliente (Customer Relations Management,
CRM) e sono di natura transazionale (minute by minute transactions) mentre i secondi
sono svolti entro i confini dell’impresa TLC senza coinvolgimento del Cliente (gestione
servizi) e sono di natura operazionale (day by day operations).
NOTA 4.6.3.1 A differenza dello standard e-TOM, emanato in un secondo tempo, lo standard TOM
annovera fra i flussi di processi esterni solo processi CRM. Invece il modello e-TOM include anche
flussi di processi esterni relativi alle relazioni con TelCo partners e ICTS suppliers di tecnologie ICT.
NOTA 4.6.3.2 Un processo di natura “transazionale” ha certe caratteristiche particolari descritte
nel “GST Addendum” No.4 (par.A4.4)
Processi (interni). Si tratta di processi che implementano l’operatività dei servizi su
base “day-by-day” e che comprende tutti i processi di supporto ai processi esterni
“Customer care”, ma che tuttavia non implicano un coinvolgimento dei singoli Clienti
(processi gestionali interni). Il Tele-Management Forum identifica i seguenti processi
operativi (Fig.4.3.6.1)
1) “Pianificazione e Sviluppo Servizi” (Service Planning & Development):
pianificazione/progetto/attivazione delle varie classi di servizi,
2) “Configurazione Servizi”(Service Configiration):
installazione/configurazione delle risorse per ogni particolare classe di servizio
3) “Trattamento Guasti” (Service Problem Resolution): identificazione
delle cause di un guasto e il coordinamento delle attivita’ necessarie a riparare il
guasto stesso,
4) “Gestione del QoS” (Service Quality Management): SP supervisiona/
documenta/controlla i parametri QoS prefissati su base “classe di servizio” (o “tipo di
servizio”) Su ‘base cliente’ viene fatto a livello Customer Care Management. In
particolare verifica che gli obiettivi di qualità e di costo prstabiliti per la
fornitura/erogazione di un particolare tipo di servizio siano consistentemente
raggiunti o se devono prendersi specifiche iniziative per raggiungerli
417
5) “Tariffe e Sconti”(Rating & Discounting): applicazione della tariffe e
sconti ai consumi ricevuti dal livello gestione di rete per preparare le fatture.
Se si aggiunge un sesto processo “cessazione/cambio”, si può riguardare la
sequenza temporale dei sei processi come un ciclo di vita: in questo caso “Service
Development Life Cycle”. Si tratta di un ciclo di vita relativo a servizi (o meglio
“classi” di servizi) con una durata molto piu’ lunga dei singoli Customer Care Life
Cycles.
Processi (esterni) Customer Relation Management (CRM) L’informazione che qui
viene processata è di natura gestionale su base del singolo “Cliente”. Poichè in generale
ci sono molti Clienti, numerosi servizi e molte aggiunte, cancellazioni, modifiche di
servizi già esistenti, si prevede che i processi Customer Care debbano essere molto
dinamici cioè caratterizzati da un numero elevato di transazioni nell’unità di tempo
(high transaction rates). La natura transazionale di questi processi porta naturalmente
ad adottare per essi livelli elevati di automazione (o bassi livelli di gestione manuale).
L’informazione di gestione processata nei processi CRM è variegata e molto
diversa da quella dell’ informazione di utilizzazione che fluisce nella rete di utilizzazione
(e.g. informazione di natura «streaming» audio, video o multimediale come nei servizi di
videoconferenza).
I relativi canali di gestione possono non essere canali di
telecomunicazione nè far parte di una rete di telecomunicazione come definita in questo
corso. Infatti possono utilizzare e.g. servizi postali (processi di billing) o servizi di banca
o contatti personali fra impiegati del Fornitore e potenziali Clienti (Processi di
vendita/ordinazione servizi svolti presso sportelli di vendita).
Se in Fig.4.6.3.1 ci si sposta da sinistra a destra lungo lo strato “Processi
Customer Care”, si nota che i processi sono ordinati in un ordine temporalmente
sequenziale in accordo con ciò che normalmente avviene in pratica:
1) “Vendite” (Sales): il Fornitore di Servizi SP riceve la richiesta di
servizio formulata dal Cliente e gli invia le relative informazioni o invia informazioni
al singolo Cliente in modo pro-attivo senza ricevere alcuna richiesta,
2) “Ordini” (Order Handling): SP accetta la ordinativa di servizio
presentata dal Cliente e ne supervisiona il progresso fatto nel relativo processo di
accettazione, notifica al Cliente il risultato del processo di accettazione,
3) “Reclami” (Problem Handling): SP processa/ripara malfunzionamenti
segnalati dal Cliente e invia le relative notifiche al Cliente.
4) “Gestione QoS Cliente” (Customer QoS Management): SP
supervisiona e documenta il livello di accuratezza con cui sono stati mantenuti gli
impegni pattuiti con il Cliente (specificati nel SLA). SP invia al Cliente i risultati di
queste operazioni (gestione del QoS Cliente) relativo al particolare servizio
erogato/fruitoi.
418
5) “Fatturazione e incassi” (Invoicing/Collections): SP invia fatture al
Cliente, riceve e registra i relativi pagamenti.
Se si aggiunge un sesto processo “cambio/cessazione” (relativo al
cambio/cessazione di una istanza di servizio relativa ad un particolare Cliente),
l’insieme dei sei processi può anche riguardarsi come un “Service Delivery Life
Cycle” a sei fasi che viene “vissuto” per ogni istanza di servizio relativa ad un
particolare Cliente.
4.6.3.2
Differenze fra funzioni U&S e processi gestionali: una teleconferenza
multimediale
Qui vogliamo enfasizzare ancora una volta la differenza fra funzioni U&S e
processi gestionali. In molti casi è facile vedere che essi si differenziano per natura e/o
per tempi di svolgimento. Un altri casi appare più difficile distinguere fra parte gestionale
e parte U&S di un servizio.
Consideriamo un Servizio di Teleconferenza Multimediale (Multi - Media
Teleconferencing Service), che permette a più partecipanti residenti in siti remoti di
collaborare su uno stesso documento multimediale (telelavoro).
La funzionalità U&S acquisita a priori dal Cliente (assieme a funzionalità
gestionali) in fase di fornitura/acquisizione del servizio è attuata dagli Utilizzatori (senza
ulteriore intervento del Cliente) tramite terminali multimediali (e.g. telefono + computer
+ modem + equipaggiamento di accesso a larga banda e.g. ADSL + videocamera +
altoparlanti + stampante) connessi ad una rete TLC con canali a larga banda. Supponiamo
che in questi ultimi l’informazione di utilizzazione (voce, dati, immagini fisse o in
movimento) sia trasportata come un flusso continuo di dati (“data streaming”) da
interconnessioni circuitali tipo m:m (“m” partecipanti alla teleconferenza completamente
interconnessi a mesh).
Le funzionalità di gestione sono attuate dalla coppia Cliente-SP via processi
gestionali (e.g. ordinazione/installazione del servizio, invio reclami, fatturazione,
pagamenti etc.) e sono svolti con procedure scelte dal Cliente di tipo specifico (e.g.
proprietarie) o generiche (e.g. standardizzate). In questi processi fluisce informazione
gestionale (i.e. scambio di dati gestionali fra Cliente e SP) utilizzando canali di gestione
che possono essere canali pubblici PSTN (e.g. telefono, internet, fax etc.) oppure di tipo
postale, bancario, tramite contatti personali uno sportello clienti (terminale di gestione)
etc.
Alcune funzioni/processi svolti dall’Utilizzatore nel corso di una sessione di
teleconferenza possono essere più difficili da identificare come “U&S” o “gestionali”. Ad
esempio supponiamo di trovarci in una Utenza Affari (e.g. Università Tor Vergata) e che
un Utilizzatore del servizio di teleconferenza cambi in tempo reale la natura dell’ attuale
canale trasmissivo fra lui e un altro Utlizzatore e.g. da canale voce a canale video.
Allora, la domanda è: il cambio di canale è una funzione U&S o gestionale?
419
Convenzionalmente si può rispondere come segue: se il cambio di canale avviene
autonomamente da parte dell’Utilizzatore dal suo terminale senza intervento del Cliente
(Ufficio amministrativo dell’Università) allora significa che l’ effettuazione del
cambiamento era già stata privista/autorizzata in prcedenza e quindi non richiede alcun
intervento di natura gestionale e la corrispondente funzione è quindi una funzione U&S.
Infatti significa che il cambio di canale direttamente da parte dell’Utilizzatore fa parte del
servizio specificato nel contratto SLA e quindi il cambio di canale è una “fruizione del
servizio fornito”. Se invece il cambio canale non può esser fatto direttamente
dall’Utilizzatore e richiede l’intervento di Cliente/SP, allora la funzione di cambio canale
è di natura gestionale.
Nel dominio del tempo le funzioni U&S e i processi gestionali possono svolgersi
in tempi diversi o allo stesso tempo. Ad esempio i processi CRM e.g. «segnalazione
malfunzionamenti» possono effettuarsi durante la utilizzazione del servizio
multimediale. Invece le attività gestionali relative alla ordinazione/ negoziazione di un
servizio precedono l’erogazione/fruizione del servizio stesso mentre le attività gestionali
relative alla fase di disinstallazione delle risorse di rete sono posteriori alla cessazione
di un servizio.
Si vede quindi, ancora una volta, che per effettuare uno studio completo della
Service Delivery e distinguere al suo interno i processi U & S dai processi gestionali di
customer care, è necessario effettuare un analisi nel dominio del tempo ed estendenderla
a periodi precedenti e seguenti la fase di erogazione/fruizione del servizio.
PROCESSI GESTIONALI
Processi “Customer Care”
(Transazionali/Esterni, Servizio Customizzato)
Vendite
Ordini
Configurazione
Servizi
Reclami
Trattamento
Guasti
Gestione
QoS Cliente
Fatturazione
Incassi
Gestione
QoS
Tariffe
Sconti
Processi “Service Operations”
(Interni, Classe di Servizi)
Proc. Gestionali
Fig.4.6.3.4 I processi interni “Service Operations” relativi a classi di servizi e di clienti sono di
supporto ai processi esterni “Customer Care” relativi a singoli servizi e clienti.
420
4.6.3.3 Relazione fra funzionalità e processi
Riepiloghiamo quanto già detto sin ora. L’attualizzazione di un servizio TLC
avviene tramite processi esterni (cioè processi che coinvolgono sia l’SP che il Cliente) e
processi interni (cioè processi che sono interni alla Telco senza coinvolgere direttamente i
Clienti).
Una «funzionalità U&S» viene attuata con la collaborazione di un Network
Operator da un Utilizzatore all’interno di una Utenza allorché esso fruisce della parte
essenziale del servizio (e.g. conversazione telefonica, osservazione di un programma TV,
trasmissione/ricezione di una e-mail etc.) e, se necessario, dopo aver svolto funzioni di
segnalazione (e.g. effettuazione di chiamata telefonica con digitazione del numero
chiamato). L’informazione che fluisce in queste circostanze nelle reti U&S si chiama
«informazione U&S»
La «funzionalità di gestione» è attuata da un Cliente che ha firmato un contratto
SPA con un Service Provider. Essa si attua tramite due tipi di processi di business: 1)
processi esterni chiamati processi CRM (Customer Relation Management) supportati
da opportuni canali/reti di gestione, non necessariamente elettromagnetici (e.g. postali o
bancari), e 2) processi interni di « produzione servizi» (Product Development) e
« opearazione servizi ».
L’informazione che fluisce in questi processi si chiama
«informazione di gestione».
Esempi di relazioni fra i processi esterni «Customer care» e i corrispondenti
processi interni appartenenti al gruppo «Operazione servizi» sono (Vedi Fig.4.6.3.4):
«Fatturazione e pagamenti» - «Tariffe (Rating) e sconti»,
«Gestione QoS Cliente» - «Gestione QoS»,
«Trattamento Reclami» - «Soluzione Reclami».
421
4.6.4 La Telecom Operations Map (TOM): il punto di vista del cliente.
4.6.4.1 La Telecom Operation Map è una mappa dei processi di business che
intervengono nella gestione dei servizi e sistemi TLC
Le attività svolte da una TelCo per il raggiungimento di obbiettivi di business
prefissati sono razionalizzate in «processi aziendali» (o “processi di business”) I
processi rilevanti alla gestione reti/servizi/clienti come mostrato nella mappa TOM
(Telecom Operation Map) (Vedi Fig.4.6.3.1) che fu sviluppata inizialmente nel
1995 come Service Management Business Process Model (Modello dei Processi
Aziendali per la Gestione Servizi, nome che ci sembra più adatto a rapprentare il
contenuto della mappa!).
4.6.4.2
Utilità della mappa TOM
La mappa TOM fu sviluppata dal TMF in riconoscimento del fatto che per le
TelCo fornitrici di servizi TLC è strategicamente molto importante automatizzare /
integrare i processi di business in risposta alle mutevoli forze provenienti dal
macroambiente PEST (Politica, Economia, Società, Tecnologia) circostante. Per fare
ciò, è necessario, prima di ogni altra cosa, avere una mappatura completa di tutti i
processi di business relativi alla gestione servizi/clienti/reti e delle loro mutue
relazioni. La TOM risponde a questa esigenza. Infatti la TOM è mappa di
riferimento dei processi operativi di gestione dei servizi TLC applicabile a tutti gli
stakeholders che intervengono nel modello di business di Fig.4.6.3.2 tenendo in conto
non solo le esigenze economico-commerciali delle TelCo ma anche e soprattutto delle
esigenze dei Clienti.
Infatti, per le TelCo, la mappa TOM offre una infrastruttura di riferimento
technolgy-neutral estremamente utile sia nel caso di re-engineering dei processi di
business interni alla TelCo sia nel caso di partnerships fra TelCo. Per le industrie
manifatturiere ICTS i.e. gli sviluppatori/venditori delle tecnologie
software/hardware necessarie all’automazione dei processi, la TOM identifica i
processi da cui trarre i requisiti che devono poi essere soddisfatti dai vari prodotti
(harware e software)
4.6.4.3
La suddivisione dello strato «servizi» TMN in due strati: Customer Care
e Service Development & Operations
I processi di business identificati dal TMF come maggiormente
rappresentativi delle attività di gestione all’interno di aziende fornitrici di servizi TLC
sono stati disposti nella mappa TOM come mostrato in Fig.4.3.6.1. Come substrato e’
stata utilizzata la struttura TMN stratificata opportunemente modificata. Infatti la
TOM suddivide lo strato gestione servizi della architettura TMN stratificata in due
strati separati: lo strato dei processi transazionali “Customer Care” (Assistenza o
422
Relazioni Clienti) e lo strato dei processi operativi “Service/Product Development
and Maintenance” relativo allo sviluppo/manutenzione dei servizi.
Questa separazione di processi é di importanza critica ed è tipica di una
gestione “customer centric”cioè incentrata sul Cliente. Essa riflette la necessità di
distinguere fra processi “Customer Care” dettati dalla necessità di interfacciare
direttamente con i singoli clienti e accudire in tempo reale alle loro richieste/
segnalazioni e i processi generici Service/Product Development & Maintenance
relativi allo sviluppo/fornitura/manutenzione di servizi da fornirsi a categorie o classi
di clienti.
4.6.5
L’interfaccia cliente
Dalla totalità dei processi “Customer Care” il TMF ha enucleato i processi
relativi alla gestione del contatto diretto con i singoli clienti ed ha chiamato questi
processi Processi di Gestione dell’ “Interfaccia Cliente”. L’ ”interfaccia cliente” è il
primo punto di contatto con i clienti ed è suo compito rispondere direttamente ai
clienti e indirizzare le loro richieste/segnalazioni a specifici processi di Customer
Care sottostanti. I processi di Customer Care a loro volta possono innescare processi
al livello sottostante di “Service Development & Maintenance”.
Esempi di attività gestionali relative all’ interfaccia cliente sono le attività
svolte dai Call Centers (Voice Response Units) e dai Web Interface Support
Centers che offrono assistenza post-vendita via internet.
Come già detto in precedenza é bene ricordare che, quando tutti i fornitori di
servizi offrono servizi a valore aggiunto in modo estrememente efficace cioé con
buona qualità di servizio e basso prezzo, é proprio una buona gestione
dell’interfaccia cliente e dello strato «Customer Care » che può offrire quei
margini di competitività necessari a vincere la concorrenza (differenziatore
competitivo).
4.6.6
Il modello FAB (Fullfilment, Assurance, Billing)
Come il modello TMN stratificato dell’ITU-T era suddiviso in strisce
verticali rappresentative delle cinque aree funzionali FCAPS così la mappa TOM è
ripartita verticalmente secondo tre raggruppamenti di processi (end-to-end process
groupings) come mostrato in Fig.4.6.3.1, laddove end-to-end significa “dall’inizio
alla fine di una striscia verticale i.e. dal Cliente agli Elementi di Rete”. Più
specificatamente, i tre raggruppamenti sono denominati “raggruppamento di Service
Fullfilment, Service Assurance, Service Billing” cioè Soddisfacimento, Garanzia e
Fatturazione del Servizio. Nel loro insieme essi costituiscono il modello “FAB”,
dalle iniziali dei nomi dei tre raggruppamenti. Ogni raggruppamento contiene i
processi che si devono implementare se si vogliono soddisfare le varie esigenze dei
Clienti e.g. piazzamento ordini e approvigionamento servizi, richiesta informazioni
sulle prestazioni del servizio e reclamim richieste di natura amministrativa, ricezione
423
e pagamento delle fatture etc. Piu’ precisamente il modello FAB della TMF indica
che in un servizio TLC i seguenti requisiti devono essere soddisfatti:
1) Soddisfacimento delle richieste di installazione servizi TLC presentate dai
clienti (requisito di Service Fulfillment). Pronta esecuzione degli ordini di
servizio e relativa erogazione.
2) Garanzia che i servizi vengano forniti con le caratteristiche stipulate in un
contratto SLA (requisito di Service Assurance), cioè, per tutto il periodo di
fornitura del servizio, garantire che il servizio possegga tutte le caratteristiche
stipulate nel contratto SLA (verifica delle prestazioni e reclami).
3) Effettuazione delle pratiche amministrative e.g. richieste di informazione di
natura amministrativa , pagamenti per i servizi forniti (requisito di Billing for
the Service). Corrisponde all’area funzionale FCAPS “Accounting”.
Questi tre requisiti sono soddisfatti se si eseguono correttamente i processi
contenuti nei tre raggruppamenti come indicato in Fig. 4.6.3.1. Le gestioni “inventario
rete” e “dati rete” sono state separate per evendenziare i doppi ruoli che ciascuna di esse
gioca rispettivamente nelle due aree Fulfillment + Assurance e Assurance + Billing. Ad
esempio la gestione inventario, che include attività d’implementazione apparati per
riparazione guasti/ripristino servizi é importante sia per i processi di Fulfillment che per
quelli di Assurance.
4.6.7 Una metodologia TMF per creare la mappa TOM? (non esiste!)
La mappa TOM è una mappa di riferimento dei processi operativi di gestione dei
servizi TLC tecnologicamente neutra e valida per un qualsiasi stakeholder nel business
model di Fig.4.6.3.2 (e.g. wholesalers, retailers, intermediari etc.). Si tratta di una library
che offre una lista completa di processi operativi formulati ad un alto livello di astrazione
estremamente utile sia nelle relazioni commerciali fra vari stakeholders (relazioni interaziendali) sia nelle relazioni fra unità organizzative di una stessa TelCo (relazioni intraaziendali) per stabilire/conoscere “chi fa che cosa”.
Essa è stata ottenuta generalizzando l’informazione ottenuta tramite discussioni,
interviste, surveys con il personale delle aziende affiliate al consorzio. Tuttavia la TMF
non ha specificato come si è passato dalle informazioni specifiche raccolte sul campo
(talvolta di natura proprietaria e quindi rilasciate sotto condizione di anonimità) ad un
modello generico valido per tutti. Cioè la TMF non ha indicato una metodologia per la
creazione del modello gestionale generico partendo da modelli gestionali specifici cioè
come creare processi di business tecnologicamente e commercialmente neutri
partendo da informazioni relative a specifiche tecnologie/processi/aziende.
A questo punto é bene tener presente che, poiché a metà anni 90 la maggioranza
dei membri del consorzio TMF erano aziende USA, lo schema TOM rifletteva
prevalentemente procedure gestionali dettate da modelli di business tipici di ambienti di
424
lavoro USA. Singoli fornitori di servizi in altre parti del mondo avrebbero potuto attuare
modelli e processi di business leggermente diversi e quindi portare alla definizione di
modelli gestionali generici leggermente diversi dalla TOM. Inoltre i vari processi di
business e le loro aggregazioni nel dominio del tempo (flussi di processi) non sono
immutabili nel tempo ma sono soggetti a continue revisioni e aggiornamenti per cui
anche la TOM é stata riguardata fin dall’inizio come un «work in progress» cioè un
lavoro soggetto a continue revisioni.
4.6.8
Il quadro completo: la Tecnology Integration Map (TIM) come
implementazione della TOM.
Dopo aver formulato il modello TOM per i processi di business rilevanti a un
generico servizio TLC, il TMF iniziò lo sviluppo di software gestionale per reti e
servizi con lo scopo dichiarato di facilitare la automazione dei processi di business per gli
SP. Questa iniziativa fu denominata Technology Integration Map (TIM) cioé Mappa
Integrazione Tecnologie.
La TIM ricava dalla TOM i requisiti che il software gestionale deve soddisfare e
poi sviluppa questo software offrendo, quindi, uno sbocco implementativo alla TOM
stessa. La TIM é suddivisa in tre parti:
1)
Application Components Direction Statements (ACDS) identifica
i “criteri di progettazione” delle applicazioni gestionali (componenti
del sistema informatico gestionale),
2)
Technolgy Direction Statement (TDS) identifica le tecnologie
implementative necessarie all’implementazione dei progetti
3)
Procurement Guide (PG) identifica i componenti commercialmente
disponibili (componenti COTS, Commercial Off The Shelf)
Più dettagliatamente, la progettazione e sviluppo del software gestionale da
parte di un SP, si puo suddividere in una serie di attività e tutte queste attività sono
coperte dai due modelli TOM e TIM. Le attività e i modelli TMF corrispondenti sono,
1. identificazione dei processi di business,
TOM
2. analisi dei requisiti da soddisfare,
3. identificazione delle funzionalità
da incorporare nel software,
TIM: ACDS
4. progettazione di un “sistema logico”
(logical system design) concepito come
un insieme di building blocks cooperanti,
5. scelta delle tecnologie (sistema operativo, linguaggi
425
di programmazione, piattaforme di distribuzione come
CORBA, COM+, RMI, piattaforme hardware, etc.)
per costruire i componenti (blocchi fisici costitutivi)
del sistema informatico gestionale,
TIM: TDS
6. decisione più difficile: “build or buy” (cioé
fai da te o fai fare a uno specialista esterno).
TIM: PG
4.6.9 Diagrammi di Processo (Fig.4.6.9.1 e Fig. 4.6.9.2)
I processi di business della TOM non sono isolati ma fanno parte di flussi di
processi (flussi operativi end-to-end). Ogni processo è definito da una serie di stimoli
(triggers) di ingrsso e risultati in uscita, rispettivamente provenienti da e afferenti a
altri processi della mappa TOM e da una serie di funzioni da svolgere (contenuto del
processo). Ad esempio le Fig.4.6.9.1 e 4.6.9.2 illustrano il processo
“Approvvigionamento Rete; Network Provisioning” appartenente allo strato “Gestione
Reti” e mostrano come questo processo si posizioni rispetto ai processi dello strato
superiore (Gestione Servizi), dello strato inferiore (Gestione Elementi di Rete) e del suo
stesso strato (rappresentati in giallo). Un processo può far parte di diversi flussi operativi
e nell’ambito di uno stesso flusso può essere riutilizzato più volte (e.g. vedi il flusso di
Fig. 1.3.3.4). Le “funzioni“ descrittive del processo sono scelte dal modello funzionale
FCAPS e quindi appaiono come elementi processuali (“processing units”) già
standardizzati dall’ITU-T (Vedi Fig.4.6.10.1)
4.6.10 Relazioni fra processi di business e funzioni di gestione (Fig.4.6.10.1)
Nella mappa processuale TOM (come nella più recente mappa e-TOM) un
processo di business è una rappresentazione ad un alto livello di astrazione (High-level
Process) di un insieme coerente di attività, e ogni attività implementa una “funzione
gestionale” definita come un Gruppo di Insiemi di Funzioni di Gestione (Function
Set Group, FSG) nel Modello FCAPS (ITU-T Recommendation M.3400). Quindi nei
modelli processuali del TMF una “funzione gestionale” del modello funzionale FCAPS è
una “unit of processing” che opera su dati di ingresso e genera dati in uscita. (Vedi Fig.
4.6.10.1). In questo, una “funzione” differisce da un processo che invece è attivato da uno
“stimolo” (trigger) di ingresso e genera un risultato in uscita da riutilizzarsi, se
necessario, come stimolo di ingresso per un processo successivo. Notare che i processi
possono suddividersi in sottoprocessi (vedi esempio di Fig.4.6.10.2) corrispondenti agli
Insiemi di Funzioni di Gestione (Function Sets, FS) del modello FCAPS.
4.6.11 Esercizi
1)
Cosa è il Business Process Re-engineering e quale è stato il suo impatto sul
mondo delle Telecomunicazioni?
2)
Come si definisce un processo di business?
426
3)
Cosa è la Telecom Operation Map (TOM) del Modello TMF (Tele Management
Forum)?
3)
Cosa è il modello FAB (Fullfilment, Assurance, Billing)?
4)
Che relazione c’è fra la mappa TOM e il Modello TMN stratificato?
5)
Quali sono i processi di business relativi allo strato Relazioni Clienti?
6)
Quale è la differenza fra i processi dello strato Relazioni Clienti e lo strato
Sviluppo Servizi & Operazioni?
7)
Che relazione c’è fra i processi di business del Modello TMF e le funzioni di
gestione del Modello funzionale FCAPS?
427
CLIENTE
Processi Gestione Interfaccia Cliente
Vendite
Reclami
Gest. QoS
Cliente
Fattur. &
Incassi
Processi “Customer Care”
Gestione
Servizi
Pian. &
Sviluppo
Servizi
Gestione
Reti
Ordini
Pian. &
Sviluppo
Reti
Configurazione Servizi
Trattamento
Guasti
Gest. QoS
Serv.
Tariffe/
Sconti
Approvvigionam.
Rete
Gest.
Inventario
Rete
Manut. &
Rest. Rete
Gestione
Dati Rete
GESTIONE ELEMENTI RETE
Fig. 4.6.9.1 Interazione fra processi
ELEMENTI RETE
428
Processo di Network Provisioning
ENTRATE
Configurazione dei
servizi
USCITE
Capacità Disponibile,
Risposta alle Richieste
Richiesta di
(Ri)configurazione
e Prove.
Pianificazione e
Sviluppo di Rete
Manutenzione e
Restaurazione di Rete
Gestione Inventario
di Rete
Requisiti
Riconfigurazione
Network
Provisioning
Configurazione dei
servizi
Richiesta Capacità, Capacità
+ Config. Attuale
Pianificazione e
Sviluppo di Rete
-configurare la rete: instal
Richiesta
Riconfigurazione
Capacità Disponibile,
Add. / Sottr.
Gestione Elemento
di Rete
Conferma Comandi ricev.
Notifica Variazioni
Risultati delle prove
lare la config. iniziale o
riconfigurare per problemi
di capacità.
(Provisioning, C)
-Preparare logica di rete
Start/Stop
Monitoraggio
affinchè sia pronta per il
servizio. (Provisioning, C)
-Gestire le interconnessioni di rete. (Status &
Control, C)
-Provare la rete.
(Testing, F)
Richiesta Feasibility,
Ordini di Lavoro
Gestione
Dati di Rete
Gestione Inventario
di Rete
Comandi Riconfigurazione e Prove, Start/Stop
Attività, Dati di Funzionamento
Gestione Elemento
di Rete
Fig.4.6.9.2 Processo di “Network Provisioning” specificato in termini di ingressi, uscite e funzioni da svolgere. C e F rappresentano le aree
funzionali “Configuration” e “Fault” del modello funzionale FCAPS. Da interpretare alla luce della Fig. 4.6.9.1
429
M.3050 Supplement 3 “e-TOM to M.3400 mapping”
RELAZIONE fra PROCESSI di BUSINESS e FUNZIONI di GESTIONE.
Business
Processes
BP1
RESULT 2
RESULT 1
Y
RESULT 1
TRIGGER 1
RESULT 3
TRIGGER 2
Step 1
FCAPS
Function Set
Groups
Step 2
Step 3
FSG1
Step 1
FSG2
BP2
FSG3
N
Step 2
FSG4
Create, Read, Update, Delete
Fig. 4.6.9.2:
DataEsempio di diagramma di processo per una riconfigurazione di rete (Vedi Fig.9.5.1)
Areas
DA1
DA2
DA3
DA4
DA5
Fig.4.6.10.1 I processi operativi TOM sono utilizzati in flussi operativi end-to-end finalizzati al conseguimento degli obiettivi di
business della TelCo. Sono attivati da o generano stimoli (triggers). I processi sono di “alto livello” e i loro contenuti
corrispondono ai Function Set Groups, FSG (Gruppi di Insiemi di Funzioni) del Modello FCAPS dell’ITU-T. Una FSG è
definita dal TMF come una “unità di processo” (unit of processing) che opera su dati di ingresso e genera dati in uscita.
430
13 SOTTOPROCESSI dello STRATO “NETWORK MANAGEMENT”
Network
Planning
& Development
1. Network
Capacity/
Trunk Planning
2
Network
Provisioning
3
4
5
2. Software &
Data Build
Management
Network
Inventory
Management
6
7
Network
Maintenance
& Restoration
8
6. Security
Management
9
10
4. Logistics
Management
5. Workflow
Management
11
10. Ntwk Config.
& Routing
7. Problem
Analysis &
Resolution
3. Scheduling
Management
Network Data
Management
11. Ntwk Test
Management
8. Ntwk Perform.
Monitoring&
Analysis
12. Ntwl
&
Correlation
9- Ntwk Traffic
Monitoring&
Analysis
Persona TLC
Fig.4.6.10.2 Decomposizione dei processi dello strato “Network Management” in 13 sottoprocessi.
431