Office: WissensDatenbank aufbauen

zurück zu deinem begonnen Datenmodell.

Gibt es nur Fehler oder auch ándere Themen.

Willst du auch abspeichern für welche Programmversion dieser Punkt gültig ist und evtl. auch von wann und von wem die Frage oder die Lösung kommt?


Gruß

Frank

 

Dann sollte mal jemand eine Wirtschaftlichkeitsberechnung durchführen.

soll heißen, das dies nicht im erworbenen Umfang beinhaltet ist?
Heißt das Produkt vielleicht Remedy?

Gruß

LL

 

*Smilie Hellseher oder wie.... Ja, leider ist es das

 

Es gibt Fehler, Software oder Fehler40. Es gibt Workarounds, wenn die Behebung bis zum nächsten Werktag dauert. Es gibt Probleme die weitergegeben werden müssen.

Der Weg hin zu den verschiedenen Programmversionen ist ( noch ) nicht in meinem Zielwasser, da dies zur Zeit nicht nötig ist. Wir haben im Unternehmen eine globale Ausstattung für alle, die bei Bedarf durch zusätzliche Software aufgewertet werden kann. Eine Timeline brauche ich auch nicht, aber eventuell einen Zähler, der mir ( nur mir ) zeigt, wie oft eine spezielle Seite benutzt worden ist.

 

Na ja, wie man es sieht *wink.gif*
Remedy bietet entsprechende Schnittstellen per API.
Ich hab vor Jahren mal eine Access-DB für entsprechende Auswertungen gemacht (da war CrystalReports noch nicht soweit*wink.gif*)
Damit hättest Du eine Möglichkeit direkt auf die RemedyDaten zuzugreifen und müßtest keine redundante Datenhaltung betreiben.
Aber ich denke das ist ein paar Nummern zu groß für Dich.
Das Produkt selbst ist ziemlich Leistungsfähig aber sicherlich nicht sehr ergonomisch!
Bevor Du hier tagelange Arbeit reinsteckst, setzt Dich erst mal mit jemand zusammen der Remedy "kennt" (nicht nur bedient*wink.gif*)!
Ansonsten vermute ich mal hat dein Chef keine Ahnung von dem Unterfangen mit welchem er Dich hier beauftragt hat *wink.gif*

@josef

Unter konsequenter Nutzung der verfügbaren Hilfsmittel (API) wäre dies sicherlich sinvoll.
Ein eigenes Datenmodell könnte dann auch auf ein Mindestmaß reduziert werden.
Allerdings sollte schon ein ausgeklügeltes Konzept stehen und das ist IMO der größte Aufwand.
Für "lau" wird dieses Projekt nicht machbar sein!

Gruß

LL

 

Es ist eine Entscheidung etliche Etagen höher, das die Wissens DB vom Remedy NICHT genutzt wird. Der Punkt steht und daran kann nicht gewackelt werden. Wir haben schon alles probiert.

Ich zieh das nun in Acc durch und gut, über das für und wider kann man tagelang diskutieren, aber ich möchte ein zeigbares Ergebnis haben. Das ich mit anderen Mitteln schneller und eventuell eleganter zum Ziel kommen kann ist mir bewusst. Nur Access muß es sein und wird es auch.

Weiter hierüber zu diskutieren bringt nix. Sorry Leute aber so ist es Fakt.

 

Ich glaube da hast Du mich falsch verstanden, siehe Ergänzung "Josef"!
Und mit jemand der Remedy "kennt" meinte ich jemand der schon mal mit den ActiveX-Komponennten bzw. Libraries von Remedy gearbeitet hat.

Gruß

LL

 

Oh, ja das kann sein. Remedy wird/wurde extern angepasst. Daher wird daran nichts mehr geändert. Ich will auch kein Zusammenspiel Remedy / Acc. Ich will Meine Support-/Wissensdatenbank als Arbeitserleichterung. Kundenzufriedenheit steigern, 3rd Level entlasten und Erstlösungsquote steigern sowie einen einheitlichen Arbeitsweg "erschaffen".

 

\@LL:

Vielleicht etwas zum Begriff "Wissensdatenbank": Ich verstehe darunter ein Hilfsmittel, dass dabei hilft aus gespeicherten Daten, Informationen zu filtern damit die Supporter ihren Wissensstand ausbauen können. Eines der wichtigsten Punkte von so einem System ist meiner Ansicht nach eine besonders flexible Suchmöglichkeit. Die Suche nur auf ein paar Begriffe einzuschränken, die bei der Erstellung eines "Informationssatzes" manuell verknüpft werden ist sicher zu wenig.
Ich stelle mir das so vor, dass ich einen Text in ein Feld schreibe und mir dann das System alle damit "verwandten" Einträge auflistet - am besten gewichtet nach "Trefferwahrscheinlichkeit". Das bedeutet dann für mich allerdings, dass es sehr gut durchdachtes Datenmodell notwendig wird. Nur ein paar Tabellen für die Problem/Lösungsbeschreibung werden da sicher nicht ausreichen.
Das ganze gehört meiner Ansicht nach "verstichwortet" und kategorisiert - wobei ich auf jeden Fall mehr als eine Kategorie zu einer Problemlösung erlauben würde.
Die Stichwörter würde ich auch nicht vom Anwender eintippen lassen, sondern so eine Art "Gewichtete Volltextsuche" einbauen. Soll heißen: das System erfasst die Stichwörter automatisiert und der Anwender kann einige Stichwörter mit besonderer Bedeutung bewerten - wobei ich die Bewertung laufend und nicht nur bei der Erstellung zulassen würde. Weiters sollte es auch die Möglichkeit geben, dass ein Anwender nachträglich Stichwörter bzw. Kategorien ergänzt.

Wie man dann die Texte bzw. die Beschreibungsfelder für einen "Informationssatz" gestaltet ist dann eher Geschmackssache. Der schwierigste Punkt ist meiner Ansicht nach die Vernetzung der Daten, damit mit hoher Wahrscheinlichkeit die passenden Treffer bei einer Suche aufgelistet werden.
=> wobei man durchaus auch bedenken sollte, dass vielleicht im Suchfeld kein einziges Wort von der Beschreibung der passenden Problemlösung vor kommt. *wink.gif*


Wenn das aber nur eine Liste von Lösungen für bestimmte Fehler-Codes werden soll, wird das DB-Modell natürlich einfacher, da man dann ja nur nach der Fehlernummer suchen muss, um eine Liste der möglichen Fehlerhebungen für diesen Fehler zu erhalten.

mfg
Josef

 

\@Josef
Das sehe ich ja genauso, Remedy ist ein "irres" Teil!
Es beinhaltet bereits alles was hier angesprochen wurde. Auch die Datenstrukturen und Funktionen sind bereits vorhanden.
Mein Vorschlag war nur dies über die entsprechenden Schnittstellen zu nutzen.
Aber macht mal ruhig weiter *wink.gif*
Ich glaube aber trotzdem das Ihr hier auf das falsche Pferd setzt (nicht Access sondern die Vorgehensweise)!

Gruß

LL

 

Genauso stelle ich mir das auch vor. Das es ein Stück Arbeit ist, leuchtet mir ein. Wie stelle ich in dem von dir beschriebenen Fall am besten die Struktur der Datenbank dar ?

 

Das ist ein gute Frage, die ich dir mangels Informationen über Helpdesk-Anforderungen nicht beantworten kann.
Das größte Problem ist meiner Ansicht nach - wie bereits erwähnt - die Vernetzung der Daten.
Anm.: Ich persönlich würde (falls das keine einfache Fehler-Suche-Lösungen-Anzeigen-Anwendung werden soll) auch ein Access-Backend ausschließen, da Jet keine Volltextsuche eingebaut hat und das alles im Frontend dazu programmiert werden müsste.

Ich kenne Remedy nicht - aber wenn ich Louisleon richtig verstanden habe, würde die Struktur dahinter diese Anforderungen unterstützen.
Darauf per Access zugreifen erscheint mir sinnvoll und kostensparend - denn auch deine Arbeitszeit, die du für die Erstellung und Wartung der Access-Anwendung benötigst kostet etwas. Besonders schlimm wird es dann, wenn du zwar eine für dich brauchbare Anwendung gestaltet hast, aber niemand etwas eingibt, weil sie von den anderen nicht angenommen wird.

Zum Thema "Suche mit Stichwörtern"
Man könnte dafür eine eigene Tabelle für die Stichwörter erstellen, damit man dann mit einer n:m-Tabelle Stichwörter mit ähnlichen Stichwörtern verknüpfen kann, um "verwandete" Beiträge ermitteln zu können. In einer weiteren n:m-Tabelle werden dann noch die Beiträge mit den Stichwörtern verknüpft.
Ein Problem bei der Stichwort-Lösung: irgendwie müssen die Beiträge mit den Stichwörtern verknüpft werden. Damit beginnt aber das Problem bereits: wer macht das? Der Anwender sicher nicht - oder zumindest nicht ausreichen, weil es ihn meistens nicht interessiert, ob andere etwas von seiner Eingabe haben - er ist meist nur daran interessiert, dass seine Aufgabe schnell erledigt ist.
=> Also muss die Anwendung die Verknüpfung durchführen. Aber wie soll das funktionieren? ... alle Wörter aus den Beschreibungen heraussuchen? ... Was ist aber mit jenen Stichwörtern, die zwar perfekt passen, aber im Text nicht vorkommen? Und wer pflegt dann die Verknüpfung der Stichwörter untereinander?

mfg
Josef

 

An Remedy komm ich nicht dran.
Also ums mal einfach zu gestalten und einfach zu halten nehmen wir mal ne andere Version.

- Wahl der Anwendung
- Ausgabe der Fehlerbilder
- Nach Auswahl Fehlerbild, Ausgabe Lösung

Das ist easy, zwar nicht so toll, aber ausbaufähig. Wenn ich erstmal solch eine Version am Laufen habe, habe ich Argumente auch an die APIs von Remedy zu gelangen....

 

??
Du arbeitst doch damit. Bei der Installation des Clients werden entsprechende Komponennten installiert. Damit und dem entsprechenden Account hast Du den Zugriff.
Aber ich sehe schon wieder "den Kampf mit den Windmühlen" *wink.gif*
Ich verabschiede mich jetzt mal aus dem Thread.
Viel Erfolg!

Gruß

LL

 

Hallo,
das ist schon ne Weile her, aber hier trotzdem die Frage (in der Hoffnung, dass es den Thread Ersteller noch gibt): Was ist aus dem Projekt geworden?