2. 2
Provisioning usług - podział kompetencji
Odpowiedzialny za:
- Konfigurację usług
abonenta w OSS
- Wysyłanie
poprawnych zleceń
provisioningowych
- Usuwa błędy
wynikające z
niepoprawnej
konfiguracji, braku
provisioningu itp.
OSS LMG IN SMS
HLRProvisioning usług abonenta
Sprzedaż, DOK Dział IT Dział Eksploatacji
Odpowiedzialny za:
- Utrzymanie OSS i LMG
- Konfigurację i utrzymanie
procesów end-to-end
- Usuwa błędy wynikające z
niepoprawnego działania
systemów OSS i LMG
Odpowiedzialny za:
- Utrzymanie NE
- Poprawność konfiguracji
zadań provisioningowych
dla poszczególnych NE
- Usuwa błędy wynikające z
niepoprawnego działania
NE
Właściciel procesu
3. 3
Realizacja procesów provisioningowych
Postpaid Prepaid Pracownicze,
testy, VIP
Testy
techniczne
SurePay provisioning - DOK preprov. – DIT provisioning – BL
(ew. DIT)
Biuro VAS
SMSC provisioning - DOK preprov. – DIT provisioning – BL
(ew. DIT)
Biuro VAS
AAADB provisioning - DOK
blokady – DRiW
preprov. – DIT provisioning – BL
(ew. DIT)
Biuro SIP
HLR
provisioning - DOK
NP – DOK/BCORE
Weryfikacja
terminali – BSA
blokady – DRiW
preprov. – DIT provisioning - BL
(ew. DIT)
Biuro CORE
Procesy obsługiwane przez styki OSS-LMG – utrzymywane przez Dział IT
Procesy obsługiwane przez styki LMG – utrzymywane przez Dział IT
Procesy obsługiwane przez inne styki – utrzymywane przez Dział Eksploatacji
Procesy obsługiwane ręcznie lub quasi-ręcznie (NP)
4. 4
Plany dot. procesów provisioningowych
1. Po wdrożeniu nowych funkcjonalności systemu OSS będą migrowane na
styk OSS – LMG procesy obsługiwane dotychczas przez aplikacje Działu
Eksploatacji:
• Proces obsługi Number Portability
• Proces obsługi blokad windykacyjnych na HLR
2. Planowana jest też automatyzacja kolejnych procesów biznesowych:
• Wypowiedzenie umów SFERIA (voice i data)
• Anulowanie wypowiedzeń SFERIA
3. NE dla których procesy provisioningowe nie zostały zautomatyzowane:
VMSC i MMSC. Może należałoby uruchomić odpowiednie styki (np. w
świetle planów na wprowadzenie rozdzielności MIN i MDN w Warszawie)?
4. Jakie nowe NE są planowane na 2009 rok?
5. 5
Provisioning usług – dane w OSS vs. NE
Każdy wpis w NE z wyjątkiem „technicznych”, musi mieć swój odpowiednik w bazie OSS
zgodnie z poniższymi zasadami:
Jest wpis w NE – „do aktywacji”, „aktywny” , „przeniesiony”
Brak wpisu w NE – „nowy”, „zarezerwowany”, „odłączony”, „anulowany”,
„anulowany konflikt”
Wszystkie „techniczne” wpisy w NE (BTS-y, terminale do testów technicznych) muszą
być oznaczone zgodnie z ustalonymi standardami. Jedyny wyjątek od tej reguły
stanowią abonenci wzorcowi ( na HLR).
nowy
zarezerwowany
do aktywacji aktywny odłączony
przeniesiony
anulowany
Statusy abonentów w OSS
status
status
anulowany konf.
6. 6
Provisioning usług – zmiany w procesach
1. W przypadku wprowadzania nowych usług, bądź zmian w usługach,
wymagających przeprowadzenia testów na terminalach, konieczne jest
przeprowadzenie tych testów z użyciem komercyjnego
provisioningu (via OSS).
2. Obsługa terminali pracowniczych oraz testowych, które wymagają
komercyjnego provisioningu odbywa się za pomocą odpowiednich
schematów i zgłoszeń w OSS. Abonent (1x handset) jest przypisywany do
konkretnego klienta- pracownika.
3. Obsługa terminali VIP odbywa się za pomocą odpowiednich schematów i
zgłoszeń w OSS. Abonent (1x handset DHZ ?) jest przypisywany do klienta
Rezerwa Techniczna 2.
4. Procedura obsługi procesu „Powrotu do sprzedaży terminali/
numerów” musi zostać rozszerzona o krok „czyszczenia starego
provisioningu” (na wypadek błędów DOK).
5. Zaleca się też wprowadzenie testów działania usług dla każdej
zaprovisionowanej partii terminali Prepaid (wystarczy kontrola jednego
z partii) oraz dla nowo otwieranego zakresu numeracji – celem wykrycia
ew. błędów w provisioningu i/lub procesie otwierania numeracji.
7. 7
Weryfikacja spójności baz NE i OSS
1. Nawet przy całkowitej automatyzacji procesów provisioningowych
wymagane będzie okresowe porównywanie baz poszczególnych NE z bazą
OSS (proces DATABASE RECONCILIATION). Celem procesu DATABASE
RECONCILIATION jest wykrywanie systemowych błędów w
procesach i ew. nadużyć.
2. Z uwagi na duże wielkości baz nie można tego procesu przeprowadzać za
każdym razem dla wszystkich abonentów na raz. Proponowana
metodologia:
• Audyt pełny przeprowadzany raz do roku
• Co kilka miesięcy przeprowadzanie audytów „częściowych” (np. wg zakresów
numeracji, rodzaju usług)
• Porównywane są zapisy dla danego zakresu we wszystkich bazach
• Właścicielem procesu powinna być odrębna komórka organizacyjna (spoza
DTiS).
• Rozważyć należy ew. zakup dedykowanego oprogramowania do wspomagania
procesu (i/lub angażowanie zewnętrznego Audytora)
3. Niezależnie od powyższego Biuro OSS prowadzi proces weryfikacji
wewnętrznej spójności baz OSS (np. weryfikacja czy wszyscy abonenci są
fakturowani)
