Office: WissensDatenbank aufbauen

Hallo Forum,

ich habe die ehrenvolle Aufgabe, eine Wissensdatenbank aufzubauen. Wir sind ein Team über mehrere Standorte verteilt von ca. 50 Personen, die First und Secondlevelsupport von Anwendern im Unternehmen leisten.

Diese Wissensdatenbank soll die lose Blattsammlung eines jeden in einer DB zusammenführen, das während eines Gespräches die Lösung eines Problemes präsentiert wird.

Was soll diese Datenbank können / bereitstellen ?

- Sie muß Multiuserfähig sein, da max. 50 Personen Zugriff drauf haben können
- Sie sollte nur einem beschränkten Personenkreis erlauben, Änderungen vorzunehmen. Alle anderen dürfen nur lesen.
- Sie sollte wenn möglich dem Anwender ein grafisches Frontend zeigen und die eigentliche DB liegt auf einem Fileserver

Ich habe nur Acc2002 ( 10.6501.6626 ) SP3 zur Verfügung.

Leider ist meine letzte Begegnung mit Acc aus dem Jahre 1998 bei der Bundeswehr *frown.gif* Daher muß ich ganz von vorne anfangen, also bitte habt ein wenig Mitleid mit mir *wink.gif*

Die Treffer, die ich hier im Forum gelandet habe, waren noch nicht erleuchtend genug, daher mein neuer Thread.

Wie schaffe ich es, das die DB meine Wünsche auch erfüllen kann ?

Wie kriege ich eine Datenbank Multiuserfähig und so intelligent, das sie anhand des eingeloggten Users die Rechte "freischaltet" oder nicht ?

So, genug Tobac erstmal.

Bei Fragen bitte fragen

// EDIT

Ich habe ein wenig gegrübelt :

Mein Primärschlüssel soll der Name der Anwendung sein
Eine Anwendung kann N Fehlerbilder haben, teilweise kann ein Fehlerbild aber auch von N Anwendungen verursacht werden.

Wie baue ich meine Tabellen am besten auf ?

Ich dachte an :

tbl_Anwendung [Name der Anwendung]
tbl_FehlerderAnwendung [AuflistungderFehler]
tbl_FehlerBehebung [FehlerBehebung]

Irgendwie fehlen mir logische Gedanken, welche Felder ich in die jeweiligen Tabellen einbringen soll

:)

 

Hi,

bei einer über mehrere Standorte verteilten Datenbank ist Access für die Datenhaltung nicht das ideale Werkzeug. Die Oberfläche kannst du gerne mit Access machen, aber die Daten sollten eher auf einem Datenbankserver (mysql, SQL Server o.ä.) liegen. Ausnahme: die Standorte sind über eine Netzwerkverbindung erreichbar (als ob ihr alle im selben Raum/Gebäude säßet).

Wenn das geklärt ist, geht es ans Datenmodell. Das ist die grundsätzliche Basis aller Fundamente. *Smilie

Ihr habt ja bisher eine Loseblattsammlung. Nimm mal ein paar solcher Blätter zur Hand, und versuche, die dort gesammelten Infos in "Haufen" zu gliedern. Ich bin ja nicht in eurer Firma, aber ich könnte mir sowas vorstellen wie

• welches Ding (Gerät/Softwareprodukt/...) ist betroffen? -> Haufen "Fehlerobjekte"
• welche Schäden werden immer mal wieder bemängelt? -> Haufen "Fehlerarten"
• welches Infos werden für die einzelne Schadensmeldung übermittelt (Gerät, User, Datum/Uhrzeit, Aufnehmender Supportmitarbeiter) -> Haufen "Tickets"
• welche Lösungen werden auf welches Ticket gegeben? -> Haufen "Lösungen"

Die "Haufen" sind provisorische Tabellen. Sie werden ggf. später noch überarbeitet.

Der Gedanke ist dabei: die Lösungen sind bei der ersten Verwendung "freiformuliert" und werden dabei als Lösung angelegt. Bei späterer Verwendung ist das dann "nur noch" ein Abruf der angelegten Lösung.

Vielleicht bringt dich auch die Suche nach Ticket, Ticketsystem etc im Forum etwas weiter.

Näheres nach weiteren Details deinerseits.

Wenn das Datenmodell steht, kann man grobe Skizzen der Formulare und Berichte angehen.

 

Hi,

Wie motiviert bist du?
Es gehört schon einiges dazu so was aufzubauen, a) von der Programmierseite und b) von der Seite, die Text so zu hinterlegen, dass auch der Wille zur Nutzung der DB von den Useren vorhanden ist. Ich habe das mal wärend des Studiums gemacht und meine ungefähr den Aufwand einschätzen zu können.

Wieviel Zeit hast du bekommen, bzw. welches Budget?

Die Aufgabe wird in 99% so unterschätzt, dass i.d.R. ein Abbruch wärende des Projektes eingeleitet wird.

Die Sachen mit Multiuser, 50 Personen, Recht sind relativ einfach zu lösen, sollst du auch noch die Dokumente übernehmen, verschlagworten, Frage bilden .... ?

Wie soll der Zugriff auf die Back-End-DB von statten gehen?
(via Internet, Intranet ....)

Die eigentlichen Anforderungen an eine Supportdatenbank (Wissensdatenbank wird nicht) stellst du ja noch nicht. Soll dem Anrufer eine Frage gestellt werden worauf hin sich wieder Fragen vorgeschlagen werden und so nach und nach ein Problem eingegrenzt werden? Sollen lediglich nach Stichworten gesucht werden? Soll nur ein Pfad auf die Dokumente verweisen oder sollen die Texte übernommen werden? Soll dokumentiert werden was gefragt worden ist und welche Lösung den Anrufer zum erfolg verholfen hat? usw. usw.

Beschreibet für euch erstmal die Anforderungen eurer Mitarbeiter/Kunden die zu einer effizienten und kundenfreundlichen Supportbearbeitung führen (Prozess der Bearbeitung -SOLL-).

Viel Spaß erstmal

 

Ja ich weiß das Acc nicht unbedingt das Mittel zur Wahl ist, aber SQL Zugriffe etc. belasten dann widerum die Kostenstelle und alles was Kosten sparen kann ist im Moment Gold Wert .... Wir alle die Zugriff erhalten sollen, greifen auf ein gemeinsames Netzlaufwerk zu, anders ist es kostensparend nicht zu realisieren.

Es geht mir auch nicht so unbedingt um die Formulierung der Lösung, eher darum, das alle den gleichen Wissensstand haben, der dann in der DB manifestiert wird, damit jeder Kunde bei einem Anruf auch den gleichen Service bekommt. Aktuell ist es so, das der Anrufer bei Mitarbeiter A das Problem in 30 Sekunden behoben bekommt und bei Mitarbeiter B und C dauert die Behebung 5 Minuten, weil ein völlig umständlicher Lösungsweg beschritten wird oder aber das problem an den 3rd Level weitergegeben wird, weil Fragen ja weh tut *frown.gif*

Ein Ticketsystem zur Erfassung der Calls ist schon vorhanden und wird genutzt, diese DB soll dann als Ergänzung und Arbeitshilfe dienen.

Dein Ansatz mit den "Häufchen" ist sehr gut, den werd ich mal weiter verfolgen und dann etwas draus bauen.

 

Zeit kann ich mir während meiner täglichen Arbeitszeit soviel nehmen wie möglich. Motivation ist sehr weit oben denn solch eine Arbeit macht mir Spaß.

Das ich niemanden "zwingen" kann das dann zu nutzen ist mir klar, aber im Nachgang kann man dann den Kollegen sagen, das die Lösung in der Datenbank mit detaillierten Vorgehen beschrieben ist.

Die Datenbank soll auf einem Netzlaufwerk liegen und wie ich den Zugriff auf diese in einer akzeptablen Geschwindigkeit realisiere, das frag ich mich dann, wenn die DB steht ( Für Anregungen bin ich immer offen .

Der Anrufer meldet sich und sagt : " WORD zeigt keine eingebetteten Grafiken mehr an" {extremes Beispiel }. Schlagwort "WORD" und "eingebettete Grafik" tippt der Mitarbeiter in ein Suchfenster und bekommt dann als Ergebnis den Weg aufgezeigt, wie er dem Kunden helfen kann/muß. Als Zugabe gibt es dann noch einen Verweis auf eine Seite im WWW [ wenn vorhanden ] wo die Fehlerbehebung auch nochmals erläutert wird.

Oder aber wenn der Anrufer sagt, das er beim Anmelden einen Hinweis auf eine defekte AOM.LNK bekommt, das man dann AOM.LNK als Suchbegriff eingibt und die DB die Lösung hierfür ausgibt.

War das alles verständlich ??

 

\@ Martin

Darf ich mir den Satz bitte in Stein meißeln? Ich werde den Stein dann mit 12er Dübeln über dem Eingang des Forums anschrauben.

 

Ist eine Access-Anwendung für dieses Vorhaben überhaupt sinnvoll?
Wäre es nicht besser, wenn diese Informationen z. B. übers Intranet mittels Webbrowser zur Verfügung gestellt werden können?
Dann könnte man darauf auch die Technik einer Suchmaschine anwenden, wenn nach einem Begriff gesucht wird. Bei Access ist eine Volltextsuche eher schwierig durchzuführen.

Nur mal so als Idee: Was wäre, wenn du ein Wiki verwendest und dessen Funktionalität auf die Support-Bedürfnisse erweitert. ... vielleicht gibt es sogar schon fertige Vorlagen für dein Vorhaben.
Auch die Kombination Wiki + Forum könnte interessant sein. Nach dem Prinzip: im Forum wird eine Frage formuliert und diskutiert. Die Erfahrung aus so einem Forum-Thread wird dann im Wiki aufbereitet (ergänzen von Querverweisen, Kategorien usw.).
Jedes (mir bekannte) Wiki hat im Hintergrund eine Datenbank laufen. Damit wäre es auch möglich individuelle Auswertungen zu ergänzen.

Anm. Ich spielte mich vor einiger Zeit etwas mit MediaWiki und war begeistert, wie viele Erweiterungen es dafür gibt.

mfg
Josef

 

Da bin ich auch völlig deiner Meinung aber im Zuge des Kostensparen im Unternehmen MUSS ich leider mit dem klarkommen, was Standard ist und nicht weitere Kosten verursacht. Also bleibt nur Access als Software übrig.
Alles andere verursacht Kosten und der Weg ne kleine DB im Oracleumfeld von den DB Admins zu bekommen gleicht dem Weg zum Mond mit dem Bus...

Noch Fragen *frown.gif*

 

Eine Access-Anwendung verursacht keine Kosten?
Ich behaupte einfach einmal, dass diese Variante sogar teurer wird, als der Einsatz eines Wiki. Wobei ich allerdings davon ausgehe, das im Intranet auch ein Webserver (Apache oder IIS) läuft. Mit der http-Technik wäre zumindest die Zugriffsmöglichkeit von mehreren Standardorten und einer beliebig große Anzahl an Usern auf jeden Fall gegeben. Eine Access-Anwendung mit einem Access-BE wirst du ziemlich optimiert erstellen müssen, damit es über mehrere Standorte stabil läuft. Die Anzahl der User ist das geringere Problem, das lässt sich relativ einfach in den Griff bekommen.

Falls die "Wissensdatenbank" aber nichts anders als eine etwas größere "Excel-Liste" sein soll, dann reicht natürlich eine einfachen DB auch aus.
Ich gehe bei solchen Anforderungen aber davon aus, dass man den Usern die Möglichkeit geben muss, die Inhalte frei zu erstellen, zu formatieren und vor allem frei zu strukturieren. Außerdem kann es praktisch sein, wenn man Bilder mitten im Text einzufügen kann.

Und falls im eigenen Unternehmen so etwas nicht zu bekommen ist:
Um 3 Euro (oder weniger) im Monat einen Webspace anmieten und dort das Wiki aufsetzen. *Smilie

mfg
Josef

 

Nein, denn Access ist in den monatlichen Kosten drin und ein Speicherort auch. Thema Webspace, wär ja nicht wild, aber das wäre dann wieder Unternehmenswissen nach draußen tragen, ergo doof *frown.gif*
Ich habs seit Monaten gedreht und gewendet, gebettelt etc, mir bleibt nur Access. Prinzipiell so in Art Exceltabelle, aber eben einfach zu bedienen mit Eingabefeldern etc. Ich bastele grade ne grobe Struktur, die poste ich dann mal wenn ich soweit bin zur allgemeinen "Durchsicht"

 

So, habe mal ne Struktur gebastelt, wenngleich diese mir etwas mager vorkommt.....

Fehlerobjekte beherbergt alle Anwendungen die wir haben, Ein Objekt kann N Fehler haben.

Ein Fehler kann u.U. von N Anwendungen erzeugt werden.

Reicht diese Struktur oder hab ich da völlig was vergessen ??

 

Ich denke in so eine "Wissens"-Datenbank werden nicht nur Fehler sondern auch "Fragen zur Bedienung" und andere Wissenspuntke kommen.

Oder sind Eure Produkte so fehlerbehaftet?

Gruß

Frank

 

Und du erstellt und wartest die Access-Anwendung kostenlos - also in deiner Freizeit? .. dann nehme ich natürlich alles zurück und behaupte das Gegenteil. *Smilie

Warum? Du kannst das so absichern, dass niemand auf die Website zugreifen kann, der keine Zugangskennung hat.
BTW: Ich weiß, dass bei größeren Unternehmen die IT oft ziemlich teuer ist. Aber diskutiere einmal das Argument mit dem externen Webspace mit einem Kostenverantwortlichen ... vielleicht wird dann auch das interne Angebot der eigenen IT etwas billiger - sonst muss man halt "Outsourcen". *Smilie

Läuft bei euch ein SharePoint-Server? Fall ja, wäre das vielleicht auch eine Option.

Anm.: Bitte nicht falsch verstehen: Ich will dich nicht von Access weg bringen. Ich bin sogar ein großer Fan von Access - aber auch ein große Fan vom Einsatz eines passenden Werkzeugs für spezielle Aufgabenstellungen. Und eine "Wissensdatenbank" - die meiner Ansicht nach nicht mit einem "Excel-Sheet-Layout" bedienbar ist - würde ich nicht mit Access erstellen, weil mir das zu unflexibel wäre.

Ziele deines Vorhabens ist doch, dass du schnell die Lösung eines Problems findest, oder soll das nur ein Protokoll werden, welche Probleme im Support angefallen sind - egal ob es bereits ähnliche Einträge gibt.

mfg
Josef

 

Und das bietet keine Wissensdatenbank?
Dann erfindet das Rad nicht neu, sondern sucht euch am besten ein neues Ticketsystem mit integrierter KB.
Eine schöne OpenSource Lösung wäre z.B. Liberum Helpdesk, ASP-basiert mit AccDB als Backend.
Eine Auswahl an weiteren OpenSource HelpDesk-Tools findest Du hier!


Gruß

LL

 

\@Josef : Nein nicht während meiner Freizeit, während der Arbeitszeit, aber es muß so gehen. "Politische" Dinge sind dort ausschlaggebend, die mich nicht erfreuen, aber ich muß damit leben.
Weiterhin hat nicht jeder INET Zugang der damit arbeitet, frage nicht wieso, is eben so gewachsen.
@Louisleon : Doch, es bietet eine WissensDB, nur das die genutzt wird, verursacht auch wieder Kosten die keiner zahlen will.

Ich kann es drehen und wenden wie ich will, mir wird nur Acc bleiben