OSS/BSS Order-to-Activate Simulator

En guidad resa i åtta steg som visar hur en kund som beställer en tjänst — fiber eller mobil — får den levererad och fakturerad. Modellen är medvetet förenklad och lyfter fram varför OSS/BSS-stacken är uppdelad som den är.

1. 1

   Kunden beställer något

   BSS

   En kund — privatperson eller företag — väljer en produkt ur produktkatalogen. Kanske Fiber 500 Mbps hem, eller ett mobilabonnemang. Ordern fångas i CRM och Order Management och kopplas till kund, produkt och avtal.

   Varför spelar det roll? Kunden köper en kommersiell produkt, inte teknik. Det är därför BSS äger kundrelationen — språket som sälj, support och fakturering pratar är ett annat än näten pratar.

   Centrala begrepp: iCustomer Order iCRM iOrder Management
2. 2

   Produkten översätts till en tjänst

   BSS ↔ OSS

   En produkt är inte samma sak som den tekniska tjänsten den ger. Fiber 500 Mbps är ett kommersiellt löfte; den underliggande tjänsten är en internetaccess med viss bandbredd. Customer Order bryts ner till en Service Order — den första bryggan mellan BSS och OSS.

   Varför spelar det roll? Samma kommersiella produkt kan ofta levereras med olika tekniker (fiber, koppar, radiolänk). Att skilja produkt från tjänst gör det möjligt att byta teknik utan att röra säljkatalogen.

   Centrala begrepp: iService Order iService Inventory
3. 3

   Tjänsten bryts ner till resurser

   OSS

   Service Order delas upp i en uppsättning resource orders — de fysiska och logiska byggstenarna. För fiber: en accesspunkt, en port på en switch, en CPE/router, en konfigurationsprofil. För mobil: ett MSISDN-nummer, en SIM eller eSIM, ett IMSI och en subscription profile.

   Varför spelar det roll? Här syns det tydligt att olika produkter dekomponeras helt olika på OSS-sidan, även när BSS-flödet ser likadant ut. Det är ett av skälen till att OSS behöver byggas produktagnostiskt och parametriseras via produktkatalogen.

   Centrala begrepp: iResource Order iMSISDN iSIM/eSIM
4. 4

   Inventory kontrolleras

   OSS

   Innan resurserna kan tilldelas behöver vi veta vad som faktiskt finns och vad som är ledigt. Service Inventory håller reda på vilka tjänster som existerar. Resource Inventory håller reda på fysiska och logiska resurser — porttillgång, IP-pooler, nummerplaner, SIM-pooler.

   Varför spelar det roll? Inventory-data är sällan 100 % korrekt mot verkligheten. Inventory drift — när data säger att en port är ledig fast den används — är en av branschens vanligaste rotorsaker till fall-out och manuella ärenden.

   Centrala begrepp: iService Inventory iResource Inventory
5. 5

   Provisionering och aktivering sker

   OSS

   När resurserna är reserverade konfigurerar provisioning-systemet de tekniska elementen — OLT:er och switchar för fiber, RSP/HSS för mobil. Reservation är att markera en resurs som upptagen; activation är att faktiskt sätta tjänsten i drift.

   Varför spelar det roll? Skillnaden mellan reservation och activation är inte semantik utan timing. Reservera tidigt, aktivera när allt annat är på plats — annars riskerar man partial activation där konfigen finns delvis i nätet och tjänsten är halvtänd.

   Centrala begrepp: iProvisioning / Activation
6. 6

   Tjänsten verifieras

   OSS

   "Aktiverad" borde inte bara betyda att ett kommando skickades. Det borde betyda att tjänsten faktiskt fungerar — att en testkommunikation går igenom, att bandbredden mäts, att SIM:et registreras mot HSS.

   Varför spelar det roll? Utan verifiering döljer flödet sina egna fel. Kunden ringer in, supporten ser "service active" i systemen, assurance ser inga element-larm — och felet kan ta dagar att lokalisera.

   Centrala begrepp: iVerifiering
7. 7

   Fakturering kan starta

   BSS ↔ OSS

   När tjänsten är verifierat aktiv skickas BillingStartRequested tillbaka till BSS. Billing-systemet börjar räkna debitering från det datumet. Triggern är densamma oavsett om produkten är fiber, mobil eller något annat.

   Varför spelar det roll? Triggas billing för tidigt — på orderstatus istället för verifierad leverans — får kunder fakturor för tjänster som inte fungerar. Det är dyrt i credits, support och förtroende.

   Centrala begrepp: iBilling
8. 8

   Assurance tar vid om något går fel

   OSS ↔ BSS

   Efter aktivering byter ansvar från fulfillment till assurance. Assurance bevakar tjänster och resurser med larm, korrelerar fel mot kundpåverkan och driver felavhjälpning. Customer Service möter samma incidenter från kundens sida.

   Varför spelar det roll? Fel som slipper genom fulfillment skapar ofta arbete i assurance flera dagar senare. Partial activation från steg 5–6 dyker upp som "tjänsten fungerar inte" från kund. Bra fulfillment minskar belastning i assurance.

   Centrala begrepp: iAssurance

Telekomdrift har två stora delar som ofta blandas ihop. Fulfillment ser till att tjänsten levereras till kund. Assurance ser till att tjänsten fortsätter fungera efter leverans. De äger ofta samma resurser och samma kunder — men har olika ansvar, olika metrics, och olika system. Och de hänger ihop på sätt som inte alltid är uppenbara: fulfillment-fel skapar typiskt assurance-arbete långt senare.

1. Fulfillment
2. →
3. Activation
4. →
5. Monitoring
6. →
7. Incident
8. →
9. Restoration

Fulfillment lämnar över till assurance vid aktivering. När något går fel i drift startar assurance-loopen: monitoring upptäcker, incident skapas, restoration löser — och tjänsten är tillbaka i normal drift.

Vad gör de?

Vad händer när fulfillment misslyckas?

Många assurance-incidenter har sin rot långt tidigare — i fulfillment. Här är ett typiskt cascade:

1. Provisioning misslyckas delvis. Konfigurationen accepteras av OLT men inte av CPE-adaptern. Service inventory uppdateras ändå till "active".
2. Verifiering saknas eller hoppas över. Plattformen triggar billing direkt på ServiceActivated, utan ett post-activation-test som hade fångat problemet.
3. Billing startar för tidigt. Kunden får faktura för en tjänst som inte fungerar.
4. Kunden ringer in. Customer Service ser "active" i systemen — det är inte uppenbart att något är fel. Felet är osynligt från BSS-sidan.
5. Assurance-flödet startar. En incident skapas, koordineras med nätoperation, root cause spåras till slut — och hamnar i ett fulfillment-flöde dagar tidigare.

Sensmoral: en mogen verifieringsdisciplin i fulfillment (post-activation-tester, billing-trigger på verifierad leverans) är ofta det mest direkta sättet att sänka assurance-belastningen.

Var i simulatorn kan du se det här?

• Operativ påverkan-panelen översätter fulfillment-fel till uppskattat antal manuella undersökningar, supportsamtal och försenade fakturor — det är assurance- och customer service-arbete som genereras av fulfillment-flödet.
• Incidents-mätaren i Optimize Process räknar provisioning-fel under en batch. När provisioning-kön växer ökar fail-sannolikheten, och retries kan skapa kaskadeffekter — samma mekanik som driver verkliga incident-spikar.
• ResourceUnavailable och ActivationRejected-scenarierna visar konkret hur ett fulfillment-fel blir arbete någon annanstans: inventory reconciliation, partial activation, ökad supportbelastning.
• Verifieringssteget (ServiceVerified) i happy path är vad som minskar assurance load. Utan det skulle billing trigga på orderstatus istället för på verifierad leverans — och fler partial activations skulle bli kunders problem att hitta.

En kundorder är inte ett enda arbetsobjekt — den dekomponeras till en service order, flera resource orders och en uppsättning aktiveringsuppgifter. Olika produkter dekomponeras olika. Klicka på en nivå för att läsa mer i learning-panelen.