Met de module Service & incidenten kunnen verschillende soorten taken worden beheerd. Welke typen beschikbaar zijn voor een gebruiker hangt af van zijn rolinstellingen. De belangrijkste typen worden op deze pagina beschreven, maar bijvoorbeeld het schaderapport heeft een speciale pagina.

Een incident of (potentieel) probleem kan worden toegewezen aan iemand in je eigen organisatie of aan een andere organisatie. Als u aan een andere organisatie toewijst, kunt u de gebruiker niet opgeven - dat moet door de toegewezen organisatie worden gedaan (indien gewenst). Zodra een toegewezene is ingevuld en de taak is opgeslagen, ontvangt de toegewezene een e-mail waarin staat dat de taak is aangemaakt en dat er aandacht moet worden besteed aan het verwerken van deze taak.

Incident

Een incident is een enkel probleem in het passieve netwerk dat invloed heeft op meer dan één verbinding. Dit betekent dat één incident impact heeft op N aantal verbindingen. Dit kan een netwerkincident zijn (kabels, distributiepunt) of een PoP-incident. Een PoP-incident dat direct invloed heeft op het passieve netwerk en dus (direct) de service beïnvloedt, is een telco-georiënteerd PoP-incident. Een niet-telco PoP-incident is geen probleem met een van de netwerkcomponenten in de PoP, maar heeft betrekking op alles rond, op of in de PoP dat nodig is om de PoP te laten werken, zoals noodstroom (batterijpack), airconditioning of een brandblusser. Non-telco heeft niet noodzakelijk een directe impact op de netwerkdiensten, maar kan na verloop van tijd wel een impact hebben.

Incident-subtypes en redencodes

Bij het aanmaken van incidenten in Gridsz kan de gebruiker een subtype en redencode toewijzen om de benodigde details te verstrekken. De momenteel beschikbare subtypes zijn:

• Netwerk
  Incident heeft betrekking op het passieve netwerk buiten een PoP. Dit kan een kabel of distributiepunt zijn.
• PoP
  Incident in of op de PoP waar meer details kunnen worden toegevoegd door een redencode toe te wijzen (indien bekend) om aan te geven of dit een telco- of niet-telco-incident is.

Redencodes worden geconfigureerd door de PO en kunnen worden gebruikt om een incident te openen, vast te houden of te sluiten. Om de codes te configureren moet de PO toevoegen waar de code moet worden gebruikt (openen/houden/sluiten), de feitelijke alfanumerieke code (uniek), een beschrijving, taaksoort(en) toewijzen en of de code actief of inactief is. Geconfigureerde codes worden gecommuniceerd via de API's van AO en Contractor.

Relaties met incidenten

Gridsz kan servicetaken met elkaar in verband brengen die causale relaties hebben of met elkaar in verband gebracht moeten worden om deze taken efficiënt in bulk te verwerken. Verbindingsincidenten (1 verbinding), Incidenten (N>1 verbindingen) en Problemen zijn de taken die Gridsz kan koppelen. Als Verbindingsincidenten de oorzaak zijn van een Incident, kunnen die Verbindingsincidenten gekoppeld worden aan het Incident. Zodra het incident is opgelost, kunnen alle gekoppelde verbindingsincidenten indien nodig in bulk worden gesloten. Bij het sluiten van het incident wordt de gebruiker gevraagd of alle gekoppelde verbindingsincidenten ook moeten worden gesloten of de gebruiker kan alle of een subset van verbindingsincidenten die moeten worden gesloten deselecteren. Incidenten die terugkeren en vergelijkbare kenmerken hebben, kunnen worden vastgelegd in een probleem om de hoofdoorzaken te onderzoeken en taken te geven om een probleem en de hoofdoorzaak(en) op te lossen.

Routing van incidenten

Gridsz kan incidenten en problemen routeren naar aannemersorganisaties binnen een PO-cluster. Hierdoor kan de PO of zijn NOC taken naar een specifieke oplossingspartij sturen. Het NOC kan de contractantroutering voor een individueel Incident of Probleem kiezen bij het aanmaken van het Incident of nadat het Incident is aangemaakt. Bij het aanmaken van het Incident is de solution party waarde leeg. Als een contractor buiten je cluster in Gridsz zit, laat de PO/NOC het veld solution party leeg en wordt er geen contractortaak gemaakt. Dit voorkomt dat er onnodige taken worden aangemaakt in Gridsz die niet kunnen worden ontvangen en afgehandeld door de solution party. Het NOC moet communiceren en updates ontvangen van de oplosser per telefoon en/of e-mail en deze invoeren in het incident. Zorgen voor een goede opvolging en afsluiting van de incident(en).

Probleem

Een probleemtaak ontstaat uit twee of meer incidenten die zijn beoordeeld, een oorzakelijk verband delen en nader onderzoek naar de hoofdoorzaak vereisen om een soortgelijk incident in de toekomst te voorkomen. Het NOC kan probleemtickets samenstellen met open of gesloten incidenten. Aangezien problems gericht zijn op het voorkomen van incidenten en het verminderen van hun impact en incidenten realtime worden aangepakt, verwacht je dat problem tickets voornamelijk gekoppelde incidenten bevatten die zijn afgesloten. Door incidenten te kunnen koppelen, kan het probleem worden gevoed met informatie die cruciaal is voor het bepalen van de impact en hoofdoorzaken.

Probleem, status Potentieel

Gridsz kan bepalen of er een potentieel probleem is. Het NOC kan mogelijke problemen verzamelen uit incidenten (of v.v.) en beoordelen of dit daadwerkelijk een probleem is of een enkel/ongerelateerd incident. Potentiële problemen kunnen worden geaccepteerd, zodra ze zijn geaccepteerd krijgen ze de status die is toegewezen volgens de statusovergangsstroom.

Impactmelding (Actieve Operator informeren over de impact op de klant)

Wanneer een incident wordt aangemaakt, zal Gridsz (afhankelijk van de ingevoerde netwerkinformatie) een lijst met zoekcodes en DHid's geven voor elke AO met impact. Om deze potentiële impact aan elke AO te communiceren, creëert Gridsz impact_notificatietaken die via de AO API of e-mail kunnen worden gecommuniceerd. De impactmelding zal de AO informeren over de basisgegevens van het incident, zoals:

• ID
• Type
• Subtype
• Prioriteit
• Reden code
• Verwachte oplossingstijd
• Netwerkinformatie
• Potentieel effect
  • Zoekcodes
  • DHids
• Reacties
• Bijlagen

De potentiële impact wordt gecommuniceerd via de AO API en kan ook worden opgehaald door de bijlage (.csv) op te halen via de AO API of het bestand per e-mail te ontvangen.

Als de netwerkinformatie verandert of wordt bijgewerkt, geeft Gridsz een nieuwe beoordeling van de mogelijk beïnvloede zoekcode en DHid's die vervolgens naar de AO's worden gecommuniceerd via de communicatiemethode van hun voorkeur.

Impact_notificaties zijn alleen leesbaar voor AO's. Er kunnen dus geen wijzigingen worden aangebracht in de informatie-elementen zoals subtype, prioriteit, status, netwerkinformatie, data, enz. De AO mag opmerkingen en/of bijlagen in de impactmelding plaatsen om informatie of communicatie aan de PO NOC te verstrekken.

De impact_notificatie volgt de statussen en informatie van zijn bovenliggende taak - het incident. Als de status van het incident verandert (bijv.: het incident is gesloten), worden de impact_notificatietaken ook gesloten. Als er informatie verandert, bijvoorbeeld: de prioriteit, wordt dit ook bijgewerkt in de impact_notificatie taken.

FTU Verandering

Een FTU-wijziging is een HAS-gerelateerde opdracht, die wijzigingen aan FTU's en hun locatie (verbindingsstatus) toestaat. Hierdoor kunnen actieve operatoren wijzigingen aanvragen die de passieve operator kan toestaan door de FTU Change-taak aan te maken. Afhankelijk van de gewenste wijziging kan het bijbehorende subtype worden gekozen, die hieronder worden uitgelegd. De FTU change is alleen gericht op HAS informatie, wat betekent dat er geen patching aan te pas komt.

FTU Subtypes wijzigen

Bij het aanmaken van een FTU Wijziging in Gridsz kan de gebruiker een subtype toewijzen waardoor de juiste wijzigingen plaatsvinden. De beschikbare subtypes worden hieronder uitgelegd:

• Construeer
  De FTU Verandering - Construeren maakt het mogelijk om een FTU_CONSTRUCT taak aan te maken voor de contractant. Aangezien er geen PATCH_INSTALL wordt uitgegeven, kan dit taaktype typisch worden gebruikt wanneer een PO actief adressen met glasvezel verbindt, maar die verbinding niet wil patchen.
  • De geplande FTU-waarde wordt gebruikt om te bepalen welk FTU-type de aannemer zal plaatsen.
• Verplaats
  De FTU Wijzigen - Verplaatsen kan een FTU_MOVE-taak worden aangemaakt voor de contractant. Als een adres een actieve verbinding heeft, maar de FTU-locatie bijvoorbeeld niet voldoet aan de (technische) eisen van de PO, stelt de FTU_MOVE de PO in staat om een nieuwe locatie voor de FTU in te stellen.
  • Huidige FTU-locatie wordt opgehaald uit Gridsz AC (indien beschikbaar)
  • Bij het aanmaken van de taak kan een nieuwe verbindingsstatus (locatie) worden geselecteerd voor de FTU.
  • Bij het afleveren van de FTU_MOVE kan de aannemer optioneel gevraagd worden om de nieuwe (geplande) aansluitstatus te bevestigen. Of, als om een of andere (technische) reden de aanvankelijk geplande verbindingsstatus niet mogelijk is, om de werkelijke verbindingsstatus van de FTU te selecteren en in te stellen voordat de taak wordt afgeleverd. Deze informatie wordt bijgewerkt naar de bovenliggende taak. (deze informatie wordt momenteel niet bijgewerkt door AC)
• vervangen
  De FTU Wijzigen - Vervangen maakt het mogelijk om een FTU_RECONSTRUCT taak aan te maken voor de contractor. Bijvoorbeeld als de PO de FTU wil upgraden naar een nieuwer model.
  • Het huidige FTU-type wordt opgehaald uit Gridsz AC.
  • Het geplande FTU-type wordt opgehaald uit Gridsz AC (vereist voor FTU_RECONSTRUCT)
• Verwijderen
  Met de FTU Wijziging - Verwijderen kan een FTU_REMOVE taak worden aangemaakt voor de contractor. Als er bijvoorbeeld gebouwen worden gesloopt of gerenoveerd en de FTU moet worden verwijderd en de vezelkabel terug naar de eigendomsgrens moet worden gebracht, kan de PO deze taak gebruiken.