- Produkt
- Agent Knowledge Base
- Anbieter
- linked-planet
- Geltungsbereich
- Incident-Handling im Infrastrukturbetrieb
- Wissensquelle
- Jira-Störmeldungen
- Dokument
- LP-AKB · 2026-10
Aus gelösten Störungen wird Wissen für die nächste Entscheidung
Kurzfassung
Die Agent Knowledge Base macht dokumentierte Störungserfahrung aus Ihren Jira-Störmeldungen abrufbar. Teams und KI-Agenten erhalten vergleichbare Fälle im Herstellerkontext, mit Verweis auf das Ursprungsticket.
| Treffer | Störungsbild | Dokumentierte Maßnahme | Belegfälle | Relevanz |
|---|---|---|---|---|
| 1 | Steckerverriegelung bleibt nach Kabelzug im Zwischenzustand. |
1 weiterer Lösungsweg dokumentiert | 12 frühere Störmeldungen
| 0,86 |
| 2 | Kabel wird nach Ladeende nicht freigegeben. |
| 4 frühere Störmeldungen
| 0,67 |
| Treffer | Störungsbild | Dokumentierte Maßnahme | Belegfälle | Relevanz |
|---|---|---|---|---|
| 1 | Fahrzeug-Handshake bricht nach der Authentifizierung ab. |
1 weiterer Lösungsweg dokumentiert | 5 frühere Störmeldungen
| 0,78 |
| Treffer | Störungsbild | Dokumentierte Maßnahme | Belegfälle | Relevanz |
|---|---|---|---|---|
Kein ausreichend passender Treffer. Für Hersteller C liegt kein Störungsbild über der Mindestbewertung. Das Team weiß damit, dass der Katalog hier keine belastbare Antwort hat, und klärt den Fall fachlich. | ||||
Relevanz misst die Passung zur Anfrage, nicht die Erfolgsaussicht einer Maßnahme. Mehr zu BelegenMindestbewertung 0,60
Eine Anlage fällt aus. Die Erfahrung dazu liegt verstreut.
Fachkräfte suchen vergleichbare Fälle, klären mögliche Maßnahmen und bereiten den nächsten Einsatz vor. Oft hat jemand im Team das Problem schon einmal gelöst. Die Lösung steckt verborgen in den Herstellerunterlagen, in einem Ticketverlauf, einem Kommentar oder im Kopf einer einzelnen Person. Sie wiederzufinden kostet Zeit, während die Störung weiter Kapazität bindet.
- 1.1Verteilt
- Hinweise liegen in Ticketbeschreibungen, Kommentaren, Herstellerunterlagen und im Wissen einzelner Mitarbeitender.
- 1.2Wiederholt
- Dieselbe Recherche bindet Kapazität im Operations-Team und in der Einsatzvorbereitung.
- 1.3Riskant
- Falsche Maßnahme am falschen Ladesäulenmodell führt zu Fehleinsatz und längerem Ausfall. Gerade in Ladeparks mit vielen Hardware-Varianten sind die richtigen Maßnahmen der kritische Punkt.
- 1.4Doppelt
- Erkenntnisse als Wissensartikel zu schreiben kostet Zeit. Zwischen gelöster Störung und künftiger Anleitung bleibt eine Lücke.
Die Agent Knowledge Base bereitet Störungsbilder und Maßnahmen aus geeigneten Jira-Störmeldungen auf. Jede neue Anfrage erhält vergleichbare Fälle mit dokumentiertem Lösungsweg und Verweis auf das Ursprungsticket, oder die klare Meldung, dass kein ausreichender Treffer vorliegt.
Das Wissen zu neuen Fällen wird automatisch hinzugefügt. Das Ziel: weniger Recherche, besser vorbereitete Entstörung und eine einheitlichere Bearbeitung wiederkehrender Störungsbilder.
Weniger suchen, besser vorbereitet ausrücken
| Bereich | Nutzen | Mögliche Messgröße im Betrieb |
|---|---|---|
| Operations | Dokumentierte Erfahrung steht über Teams und Standorte hinweg bereit. Sie bleibt zugänglich, wenn die Person, die den Fall gelöst hat, nicht erreichbar ist oder das Team verlassen hat. | Rechercheaufwand je Störung |
| Service | Vergleichbare Störungen werden auf derselben Grundlage bearbeitet. Neue Mitarbeitende lernen bekannte Lösungswege. Eskalationen kommen mit Fallbelegen. | Zeit bis zum fachlich akzeptierten Maßnahmenvorschlag |
| Field | Bekannte Störungsbilder, bisherige Maßnahmen und ihre Referenzen bereiten den Einsatz fachlich vor und verbessern die Übergabe an den Außendienst. | Rückfragen und Wiederholungseinsätze |
AnmerkungSupport-Teams nutzen die Ergebnisse für die erste Einordnung und die Übergabe an das Fachteam. Das Fachteam prüft, ob eine Maßnahme auf die konkrete Anlage passt. Welche Vorgehensweise verbindlicher Standard wird, entscheidet der Betrieb.
Von der aktuellen Störmeldung zum begründeten Maßnahmenvorschlag
Ein Ladepunkt startet keinen Ladevorgang. Das Ticket nennt den Hersteller, eine Fehlermeldung und erste Beobachtungen aus dem Support. Im Team fällt die Frage, die jedes Support-Team kennt:
„Welche vergleichbaren Fälle kennen wir, und wie wurden sie behoben?“
Findet die Knowledge Base passende Störungsbilder dieses Herstellers, liefert sie die dokumentierten Behebungsschritte, alternative Lösungswege und die Referenzen auf frühere Tickets. Liegen Hinweise zu herstellerspezifischen Fehlercodes vor, ergänzen sie die Antwort.
Hersteller A zeigt das Störungsbild „Steckerverriegelung bleibt nach Kabelzug im Zwischenzustand.“ Es wurde auf zwei Wegen behoben: Weg 1, Neustart, Aktor prüfen, bei Wiederholung tauschen; Weg 2, Endlagenschalter neu justieren. Die Belegfälle DEMO-1041, DEMO-0977, DEMO-0932, DEMO-0811 und weitere belegen Hersteller, Störungsbild und beide Maßnahmen.
Das Prinzip heißt GraphRAG. Die Suche erkennt ähnlich beschriebene Symptome und nutzt die gespeicherten Beziehungen zwischen Hersteller, Störungsbild, Maßnahme und Belegfall. Die Aufbereitung geschieht vor der Anfrage: Teams lesen verdichtete Einträge statt roher Ticketverläufe.
- 3.1Hersteller
- Grenze jedes Vergleichs. Ein ähnliches Symptom kann bei einem anderen Hersteller eine andere Maßnahme erfordern.
- 3.2Störungsbild
- Verdichtete Beschreibung eines Problems. Unterschiedliche Formulierungen desselben Problems werden zu einem Eintrag.
- 3.3Maßnahme
- Dokumentierte Behebung. Wurde ein Störungsbild auf mehreren Wegen gelöst, bleiben alle Wege sichtbar.
- 3.4Belegfall
- Ursprungsticket eines Eintrags. Jeder Vorschlag lässt sich darauf zurückführen.
Anmerkung 1Fehlt ein ausreichend passender Treffer, meldet die Knowledge Base das, statt eine Antwort zu konstruieren.
Anmerkung 2Anfragen gehen per Jira-Störmeldung oder als frei formulierte Symptombeschreibung mit Herstellerangabe.
Anmerkung 3Ladeinfrastruktur ist ein Anwendungsgebiet. Das Vorgehen passt überall dort, wo Störungen und Behebungen ausreichend dokumentiert sind. Ob eine Maßnahme zu Modell und Betriebssituation passt, prüft das Fachteam.
Gelöste Tickets werden zu Wissen, ohne extra Artikel
Ihre Teams schreiben keine zusätzlichen Wissensartikel. Ein regelmäßig laufender Ablauf übernimmt neue geeignete Tickets.
- 4.1
Auswahl
Ein Jira-Filter legt fest, welche Störmeldungen als Quelle dienen, etwa abgeschlossene Tickets mit dokumentierter Behebung.
- 4.2
Prüfung
PrüfstelleIst der Hersteller eindeutig? Sind Problem und Lösung klar genug beschrieben?
- 4.3
Verdichtung
Störungsbild und Maßnahme werden aus Beschreibung und Kommentaren herausgearbeitet. Eine später korrigierte Vermutung wird nicht als gültige Lösung übernommen.
- 4.4
Zusammenführung
Gleiches wird innerhalb des Herstellers zusammengeführt. Weitere Fälle stärken bestehende Einträge, Neues erweitert den Katalog.
- 4.5
Bereitstellung
Der Eintrag ist mit seinen Referenzen abrufbar, für Menschen und für Agenten.
Nicht übernommen (4.2)
Fehlende oder mehrdeutige Herstellerangabe, unklares Problem, unklare Lösung. Diese Tickets werden als Klärungsbedarf erfasst und zeigen, wo bessere Störungsdokumentation hilft.
Den Ablauf richten wir bei der Integration ein. Bestehende Störmeldungen werden aufgenommen. Bereits übernommene Tickets werden erkannt und übersprungen.
Pflege bleibt eine definierte Aufgabe
Anmerkung 1Spätere Korrekturen an bereits übernommenen Tickets erfordern eine gezielt angestoßene Neuverarbeitung.
Anmerkung 2Widersprüchliche Maßnahmen und überholte Inhalte brauchen eine fachliche Bewertung.
Anmerkung 3Ergänzende Herstellerhinweise, etwa zu Fehlercodes, werden separat gepflegt.
Anmerkung 4Rückmeldungen aus der Anwendung sind später möglich. Hat eine Empfehlung geholfen? Welche Angaben fehlten?
Wie gut ist eine Empfehlung belegt?
Die Grundlagen für finale Maßnahmen-Entscheidungen sind wichtig, um eine Empfehlung zu bewerten. Die Knowledge Base gibt keine Pauschalnote. Sie liefert die Angaben, mit denen das Fachteam die Tauglichkeit der Maßnahmen selbst prüfen kann.
| # | Frage des Fachteams | Angabe der Knowledge Base |
|---|---|---|
| 1 | Wie gut passt das Störungsbild zur Meldung? | Relevanzbewertung je Treffer. Treffer unter einer festgelegten Mindestbewertung werden nicht ausgegeben. |
| 2 | Wie viele frühere Fälle stützen die Maßnahme? | Anzahl der Störmeldungen, die genau diese Kombination aus Problem und Lösung belegen, mit Referenz auf jedes Ticket. |
| 3 | Welche Alternativen sind bekannt? | Weitere dokumentierte Lösungswege zum selben Störungsbild, sichtbar und vergleichbar. |
Relevanz ist keine Erfolgswahrscheinlichkeit.
Ein hoher Relevanzwert beschreibt die Passung zum aktuellen Störungsbild, nicht die gemessene Chance, dass eine Maßnahme hilft. Auch eine häufig dokumentierte Lösung muss zur konkreten Anlage und Betriebssituation passen.
Confidence-Einstufung Möglicher Ausbau
Die vorhandenen Angaben lassen sich zu einer verständlichen Einstufung mit Begründung zusammenführen. Die Kriterien legen wir mit Ihnen fachlich fest und prüfen sie an realen Fällen.
- gut belegt
- eingeschränkt belegt
- unzureichend belegt
Geprüfter Wissenskatalog statt Chat über Tickets
Die Knowledge Base ist kein Chat über einem Ticketexport. Sie baut vorab einen geprüften, verknüpften Wissenskatalog auf und beantwortet Anfragen aus diesem Wissen.
| # | Merkmal | Ausprägung |
|---|---|---|
| 6.1 | Wissensmodell | Graph aus Hersteller, Störungsbild, Maßnahme und Belegfall (GraphRAG). Beziehungen sind gespeichert und werden nicht bei jeder Anfrage neu erraten. |
| 6.2 | Suche | Semantische Vektorsuche findet ähnlich beschriebene Symptome. Ein Reranking-Modell bewertet die Kandidaten neu, eine Mindestbewertung filtert schwache Treffer. |
| 6.3 | Herstellertrennung | Suche, Zusammenführung und Belege bleiben strikt innerhalb eines Herstellers. Ähnlich klingende Störungen verschiedener Hersteller vermischen sich nicht. |
| 6.4 | Zusammenführung | Zweistufig: zuerst exakter Abgleich, dann semantischer Abgleich mit Reranking. Gleiches wird zu einem Eintrag zusammengeführt, Belege summieren sich. |
| 6.5 | Qualitätsprüfung | Tickets ohne eindeutigen Hersteller oder mit unklarer Störungsbild- oder Lösungsbeschreibung werden nicht übernommen, sondern protokolliert. |
| 6.6 | Nachvollziehbarkeit | Jeder Eintrag verweist auf seine Ursprungstickets und hält fest, mit welchem Modell und welcher Prompt-Version er aufbereitet wurde. |
| 6.7 | Modellwahl | Sprach-, Embedding- und Reranking-Modell sind je Aufgabe wählbar, auch über OpenAI-kompatible Schnittstellen, etwa für selbst betriebene Modelle. Ein Modellwechsel läuft über eine kontrollierte Neuberechnung des Katalogs. |
| 6.8 | Betriebssicherheit | Vor jedem Lauf prüft das System seine Voraussetzungen, etwa Modellverfügbarkeit und Suchbereitschaft. Übertragungsfehler werden automatisch wiederholt, bereits übernommene Tickets übersprungen. |
| 6.9 | Agentenzugriff | Lesender Zugriff über MCP (Model Context Protocol). Agenten erhalten Treffer mit Referenzen und verändern den Katalog nicht. |
AnmerkungArchitektur, Datenhaltung und Betriebsmodell stellen wir im Gespräch vor.
Von der Empfehlung zur Automatisierung
Über die einzelnen Störmeldungen hinaus zeigt der Wissenskatalog, wo einheitliche Vorgehensweisen oder bessere Dokumentation lohnen. Auswertungen beantworten Fragen wie diese:
- Welche Störungsthemen eines Herstellers sind besonders häufig dokumentiert?
- Welche Maßnahmen werden wiederholt eingesetzt?
- Wo entstehen Varianten oder Wissenslücken?
- Wo scheitert die Übernahme an unklarer Dokumentation?
| Stufe | Ablauf | Stand | |
|---|---|---|---|
| 1 | Vorschlag zusammenstellen | Passende Maßnahmen und Belege werden automatisch zur Prüfung zusammengestellt. Das Fachteam entscheidet über die Ausführung. | Erster Anwendungsfall |
| 2 | Weitere Bearbeitung entscheiden | Liegen genug passende Belege vor und sind die Angaben vollständig, wird eine festgelegte Prüfliste bereitgestellt. Sonst geht der Fall mit allen verfügbaren Informationen an das Fachteam. | Nach Ihren Kriterien |
| 3 | Freigegebene Routine auslösen | Wenn Wissenslage, Regeln und Handlungsspielraum es erlauben, folgen freigegebene Routineaktionen. Bild 3 zeigt eine mögliche Regel. | Perspektive |
Autonome Agenten brauchen eine belegte Entscheidungsgrundlage Perspektive
Ein KI-Agent, der selbst entscheiden soll, braucht Wissen, dessen Qualität er prüfen kann. Die Knowledge Base liefert Herstellerbezug, Relevanz je Treffer, die Zahl der stützenden Fälle, bekannte Alternativen und die klare Meldung, wenn nichts ausreichend passt. Wann ein Agent allein handeln darf, wird damit zu einer prüfbaren Regel.
Bedingungen, alle erfüllt
- Treffer im Herstellerkontext über der Mindestbewertung
- Mindestanzahl an Belegfällen für die Maßnahme erreicht; den Wert legen Sie fest
- Keine widersprüchlichen Lösungswege zum Störungsbild
- Maßnahme steht auf Ihrer Freigabeliste
- Pflichtangaben im Ticket vollständig
Alle Bedingungen erfüllt
Der Agent löst die freigegebene Routine aus und hält die Belegfälle im Ticket fest.
Eine Bedingung offen
Der Agent übergibt an das Fachteam, mit Treffern, Belegen und den fehlenden Angaben.
Kein ausreichender Treffer
Der Agent entscheidet nicht. Der Fall geht direkt an das Fachteam.
Anmerkung 1Die Knowledge Base ist lesend angebunden und trifft selbst keine Entscheidung. Regeln, Freigaben und Aktionen wie Ticketänderungen oder Einsatzdisposition richten wir im vereinbarten Integrationsumfang ein.
Anmerkung 2Jede autonome Entscheidung bleibt nachvollziehbar, weil sie auf benannte Belegfälle verweist. Wo die Grundlage nicht reicht, bleibt die Entscheidung beim Menschen.
Sie bestimmen den Spielraum
Sie legen fest, welche Angaben erforderlich sind, welche Aktionen zulässig sind und wann ein Mensch entscheidet. Ticketänderungen, Einsatzdisposition oder Eingriffe an Anlagen brauchen zusätzliche Anbindungen.
Wirkung wird im Betrieb gemessen
Rechercheaufwand, Zeit bis zum akzeptierten Maßnahmenvorschlag und der Anteil hilfreicher Empfehlungen zeigen den Effekt. Verfügbarkeit, Entstörungsdauer und Bearbeitungskosten bleiben die Betriebsziele.
Anbindung an Agenten und Anwendungen
Die Knowledge Base lässt sich an KI-Agenten und Anwendungen anbinden. Das Wissen erreicht Ihre Teams bei Einordnung, Maßnahmenprüfung und Einsatzvorbereitung. Weitere Assistenten nutzen denselben Bestand, ohne dass die Erfahrung erneut aufbereitet wird.
| Zugang | Beschreibung |
|---|---|
| MCP | Standardisierte Anbindung für bestehende KI-Agenten über das Model Context Protocol. |
| Eigener Assistent | Entwicklung eines Agenten oder einer Anwendung, zugeschnitten auf Ihre Abläufe. |
| Atlassian Rovooptional | Wo Teams Rovo bereits nutzen, kann ein eingerichteter Rovo-Agent dieselbe Knowledge Base befragen. |
Beispielhafte Agentenaufgaben
- Triage
- Zieht ähnliche Störungsbilder heran, bereitet die erste Einordnung vor und benennt fehlende Angaben.
- Entstörung
- Erläutert dokumentierte Maßnahmen mit ihren Belegfällen und zeigt dem Fachteam Alternativen.
- Einsatzvorbereitung
- Formuliert aus den Treffern einen strukturierten Übergabevorschlag für den Außendienst.
AnmerkungDie Knowledge Base liefert Informationen, der Agent verbindet sie mit seiner Aufgabe. Welche Aufgaben ein Agent übernimmt, stimmen wir auf Ihre Abläufe ab. Atlassian: Werkzeuge für Rovo-Agenten
Klein anfangen mit einem Hersteller und Ihren Tickets
- 9.1
Aufbereitung
linked-planet überführt geeignete Jira-Störmeldungen Ihres Betriebs in wiederverwendbares Störungswissen: Verdichtung, herstellerbezogene Zusammenführung, Fallbelege und laufende Aufnahme neuer Fälle.
- 9.2
Integration
Anbindung über MCP für bestehende Agenten oder über einen eigenen Assistenten. Gemeinsam legen wir Aufgaben, Wissensquellen und Erweiterungen fest. Verantwortung für Betrieb und Pflege regelt das konkrete Angebot.
- 9.3
Einstieg
Ein Hersteller oder Infrastruktursegment mit wiederkehrenden, gut dokumentierten Störungen. Dazu ein klarer Nutzungspfad, etwa fachliche Klärung oder Einsatzvorbereitung, und der angestrebte Automatisierungsgrad.
VoraussetzungStörungen und Behebungen sind in Jira ausreichend dokumentiert, der Herstellerbezug ist erkennbar. Die Wissensgewinnung basiert heute auf Jira-Störmeldungen. Weitere Quellsysteme vereinbaren wir bei Bedarf als Erweiterung.
PerspektiveWeitere Anlagen- und Betriebsdaten könnten eine feinere Einordnung ermöglichen. Ausfallprognosen oder Ersatzteilplanung erfordern zusätzliche Daten und eine eigene fachliche Validierung.
Bringen Sie einen wiederkehrenden Störungsfall mit.
Sprechen Sie mit uns über Probleme in der Störungsbearbeitung, die Ihren Betrieb immer wieder binden.
Im Gespräch klären wir
- Welches Wissen steckt bereits in Ihren Tickets?
- Wer braucht es: Support-Team, Fachteam, Außendienst?
- Wie kommt es in den Arbeitsablauf, per Agent oder Anwendung?
- Welcher Umfang und welche nächsten Schritte passen?
- info@linked-planet.com