In diesem Dokument werden kurz die Konzepte und Begriffe von S.mon erläutert. Anhand von Grafiken werden die wichtigsten Objekte und deren Beziehungen vorgestellt. Das Zeichen "*" bei den Grafiken besagt, daß ein Element 0, 1 oder mehrere Male vorkommen kann.
Im S.mon werden die Probleme immer für ein Produkt (product)
gemeldet. Der Name "Produkt" muß aber hier nicht unbedingt
mit einer Ware identisch sein. Es kann genauso ein Projekt oder
eine Service-Leistung sein. Im S.mon ist es egal, was
ein Produkt ist. Es ist egal, ob es sich um eine Software, Hardware oder
Sonstiges handelt.
Die obige Grafik zeigt die Übersicht über Produktdaten. Es ist ersichtlich, daß ein Produkt mehrere Systeme und mehrere Komponenten beinhalten kann. Für S.mon ist es wieder egal, was ein System oder eine Komponente sind. Die Daten dienen lediglich zur Strukturierung (Unterteilung), wobei ein System die erste Stufe und eine Komponente die zweite Struktur-Stufe darstellt.
Ein Produkt kann von mehreren Personen (Admin) administriert werden. Es handelt sich hier um sog. Produkt-Administratoren. Wurden keine Produkt-Administratoren definiert, so wird ein Produkt durch einen System-Administrator verwaltet.
Jedes Produkt wird durch ein sog. Access Control List (ACL) geschützt. In einem ACL werden die Rechte für die Benutzer vergeben. Es wird hier entschieden, wer was machen darf.
Zu jedem Produkt gibt es ein Team. Es handelt sich hier um die Bearbeiter, die für die Problembearbeitung zuständig sind. Es sind Personen, die das nötige Know-How besitzen, um eine Problemlösung anzubieten.
Wie schon oben erwähnt, Probleme werden immer zu einem Produkt gemeldet. Man kann beliebig viele Probleme melden.
Wie man oben sieht, sollte ein Problem immer einen Titel und eine detailierte Beschreibung haben. Über die Priorität wird die Dringlichkeit definiert. Ein Problem wird durch eine eindeutige Nummer identifiziert, die vom System vergeben wird. Ein Problem befindet sich immer in einem bestimten Zustand, welcher durch ein vordefiniertes Workflow (siehe auch Features) bestimmt ist. Ein Problem besitzt noch viele andere Felder, die entweder von einem Benutzer ausgefüllt oder vom System vergeben werden. Die Details kann man dem Datenbank-Modell entnehmen.
Zu einem Problem kann man beliebig viele Beilagen abspeichern. Es könnten z.B. Konfigurations- oder Log-Dateien sein.
Zu einem Problem kann man beliebig viele Memo-Texte mitspeichern. Die Memo-Texte dienen zur internen Kommunikation und sind nicht sichtbar für die Kunden.
Tauscht man Mails mit dem Kunden aus, so können auch diese Mails zu dem Problem abgespeichert werden.
Die Lösung (Solution) eines Problem kann aus vielen einzelnen Aktionen (Tätigkeiten) bestehen. Dabei wird jede einzelne Aktion genau dokumentiert.
Jedes Problem läuft ein definiertes Workflow durch. Es ändern sich die Zustände, die Bearbeiter, es werden neue Aktionen gemacht. Wir sagen, daß ein Problem eine Geschichte (History) hat. Hier wird mitprotokolliert, wer wann und was gemacht hat?
Da ein Problem beliebig oft weitergeleitet werden kann, wird diese spezielle History-Information in sog. Routing-Tabelle gespeichert.
Die obige Grafik zeigt, wie die Kundedaten organisiert werden. Zu jedem Kunden kann man im S.mon Kunden-Benutzer anlegen. Diese Benutzer können dann die auftretenden Probleme melden.
Die Kundendaten werden von sog. Kunden-Administratoren verwaltet. Man kann mehere solche Administratoren definieren. Gibt es keinen Kunden-Administrator, dann werden diese Daten durch einen System-Administrator verwaltet.
Zu jedem Kunden kann man optional eine Kontroll-Liste (Check list) abspeichern, welche bei der Problemlösung zu berücksichtigen ist.
Für jeden Kunden können beliebig viele Aufstellungsorte (Büro, Office, Site, Location, ..) definiert werden. Diese Daten können bei einer Problemmeldung ausgewählt werden.
Mit einem Kunden kann man mehrere Verträge abschliessen. Mindestens ein Vertrag (contract) ist aber notwendig. Auch wenn kein Vertrag mit einem Kunden unterschrieben wurde, muß man im S.mon einen erstellen. In dem Vertrag steht, für welche Produkte dieser gelten soll und welche Prioritäten (die Bedeutung wird auch hier definiert) zur Verfügung stehen.
