Booking Monitor Supportforum

In diesem Artikel beschreibe ich alle Anforderungen, die an das Buchungssystem gestellt werden. Dabei soll es zunächst nicht um die technischen Feinheiten gehen, sondern eher um die Anforderungen, welche die Kunden an das Programm stellen würden. Außerdem handelt es sich bei diesem Beitrag um eine vorläufige Liste, die ich am 01.06.2009 erstellt habe, die noch weitergehend überarbeitet und dadurch erweitert wurde. Die neue Liste mit zusätzlichen Anforderungen wird als neuer Artikel erscheinen. Wer es eilig hat, kann diesen Artikel überspringen.

Zur Erinnerung möchte ich nochmals erwähnen, dass es sich primär um die Entwicklung eines Buchungssystems für Ferienobjekte handelt. Ich werde jedoch ebenso den Einsatz des Systems in den Bereichen Sporthallenvermietung sowie Vermietung allgemein mit in Betracht ziehen.

Ich hatte früher ein kleines Verständnisproblem, wenn es um Kunden und deren Kunden ging. Deswegen habe ich angefangen, die zweite Gruppe als „Gäste“ zu bezeichnen. Das Ganze wurde noch schlimmer, als mich ein Kunde anrief und fragte: “…Kann ich Ihr System auf mehreren Seiten von meinen Kunden einsetzen?”. In nur wenigen Gesprächsminuten musste ich zwischen…

1. meinem Kunden, der anrief;
2. seinen Kunden, die bei Ihm Homepages bestellt hatten;
3. und den Endkunden (Gästen)

…unterscheiden.
Ganz schön schwierig, wenn man nicht sofort die Kunden auf Reseller, Kunden und Gäste unterteilt. (Das war ein kleiner Exkurs vom eigentlichen Artikelthema. Es geht nun weiter mit den Anforderungen.)
Man kann 3 Hauptkomponenten hervorheben, welche die Grundlage des Systems bilden:

1. Objekte, die vermietet werden.
2. Gäste, die die Objekte mieten.
3. Buchungen und Reservierungen.

Alle anderen Komponenten können als Zusatzmodule betrachtet werden.

• Installer - der Kunde soll das System installieren können. Es werden im Installationsprozess die Datenbankzugangsdaten eingegeben, so wie ein Administratorname und ein Administratorpasswort. Daraufhin soll der Installer die notwendigen Installationsroutinen durchführen. Es ist ebenfalls die Aufgabe des Installers, vor der Installation zu prüfen, ob alle notwendigen Ordnerrechte gesetzt sind.
• ACL (Access Control List, Zugriffssteuerungsliste) – der Kunde soll mehrere „Bearbeiter“ anlegen können. Bearbeiter sind zum Beispiel Vermieter, Agenten etc. Ich nenne sie Bearbeiter, weil es auch Mitarbeiter der Kundenfirma sein können. Ein Bearbeiter soll in der Lage sein, ein oder mehrere Objekte zu verwalten, Buchungen zu bestätigen, anzulegen, zu bearbeiten oder zu löschen bzw. zu stornieren. Außerdem soll der Bearbeiter – nach Administratorwunsch – auch E-Mails an einen Gast versenden und bestimmte Operationen mit den Rechnungen durchführen können. Auf einzelne Rechte der Bearbeiter werde ich noch eingehen.
• Objekte – ein Objekt kann eine beliebige Immobilie sein. Die Nutzer von früheren Versionen haben es geschafft, das Produkt als Elektrowarenvermietungssoftware oder Bootsvermietungssoftware einzusetzen. Ich werde dies bei diesem Produkt berücksichtigen, werde jedoch hauptsächlich bestimmte immobilienspezifische Daten verwenden. Objekte sollen in einer Liste verwaltet werden. Jedes Objekt wird mit bestimmten Eigenschaften versehen. Gegebenenfalls sollen benutzerdefinierte Objekteigenschaften erstellbar werden.
• Objektgruppen – eine Gruppe soll mehrere Objekte beinhalten können. Zum Beispiel kann es eine Gruppe mit Ferienwohnungen oder eine mit Ferienhäusern geben – oder eine Gruppe für Immobilien in den Alpen oder auf der Insel Rügen. Die Definition der Gruppen bleibt dem Kunden überlassen. Die Gruppen sollen sich verschachteln.
  
• Buchungen – bzw. Reservierungen. Wenn ein Gast plant, ein Objekt zu bewohnen bzw. zu besetzen, dann muss dieses Objekt für den gewünschten Zeitraum reserviert (vorläufig vorgemerkt) oder gebucht (fest reserviert) sein. Auf diese Weise kann das System die freien Zeiträume ermitteln und anzeigen. Eine Buchung soll auf zwei Arten durchführbar sein: entweder durch einen Bearbeiter (ggf. Vermieter) oder durch den Mieter. Der Bearbeiter kann dabei gleich wählen, ob er eine Buchung oder Reservierung eingibt. Der Gast kann (je nach Einstellung des Administrators) nur eine Reservierung tätigen. Für die Buchung durch einen Gast sind einige Sicherheitsmechanismen notwendig, damit ein Gast nicht gleich alle Objekte für alle Zeiträume bucht (spammt). Der Administrator soll festlegen können, ob der Kunde seine Buchung per E-Mail-Link bestätigen soll.
• Buchungsformular – Gäste bzw. Mieter, die auf die Kundenhomepage gehen und sich für ein Objekt sowie einen Zeitraum entscheiden, können das gewählte Objekt buchen bzw. reservieren. Dazu wird ein Formular erstellt. Dieses Formular wird bestimmte (darauf wird folgend noch eingegangen) Daten vom Kunden sammeln und im System speichern. Gleichzeitig wird, je nach Administratoreinstellungen, eine Buchung oder Reservierung erstellt und die notwendige E-Mail versendet.
• Rechnungen – das System soll für jede Buchung zu einem festgelegten Zeitpunkt eine Rechnung erstellen können. Die Rechnungen werden im PDF-Format ausgegeben und je nach Administratoreinstellungen per E-Mail an einen Mieter, Bearbeiter und/oder Administrator verschickt. Der Administrator soll einstellen können, dass die Rechnung in Teilen zu bezahlen ist: Zum Beispiel eine erste und eine zweite Anzahlung plus die restliche Bezahlung in Prozent. Die Rechnungen sollen jederzeit zum Drucken oder zum erneuten Versenden per E-Mail zur Verfügung stehen.
• Belegungsplan – Mieter, die auf die Kundenhomepage kommen bzw. die Kunden selbst sollen in Form eines Belegungsplans eine bessere Übersicht der Belegung des Objekts bekommen. Durch eine Liste zu stöbern, um herauszufinden, ob ein Objekt im bestimmten Zeitraum noch frei ist, erscheint äußerst unbequem und zeitaufwändig. Aus diesem Grund ist ein grafischer Belegungsplan unbedingt notwendig. Ein Belegungsplan ist eine HTML-Tabelle, in der die Tage horizontal und die Objekte oder Monate vertikal dargestellt werden. Dabei bildet ein Feld (TD-Element) einen Tag ab. Die Felder werden unterschiedlich gefärbt und mit Bildern versehen, um jedem einzelnen Tag einen aussagekräftigen und leicht (intuitiv) verständlichen Zustand zu verleihen. Die Vergangenheit hat gezeigt, dass viele Kunden nicht nur tageweise, sondern auch stundenweise vermieten. Aus diesem Grund wird zusätzlich ein zeitlich verfeinerter Belegungsplan erstellt. Jedes Feld in diesem Belegungsplan wird 15 Minuten abbilden. Der Plan wird später z.B. per Klick abrufbar sein. Anmerkung: Die Phrase „auf einen Tag klicken“ gehört wahrscheinlich zur Programmierer-Sprache.
• Mehrsprachigkeit – das ganze System soll in mehreren Sprachen zur Verfügung gestellt werden. Dafür wird ein Sprachmodul notwendig. Das Sprachmodul wird sich einerseits um die Bearbeitung der Sprachen kümmern, andererseits die gewählten Sprachen im System ausgeben.
• Lokalisierung – der Kunde soll in der Lage sein, mehrere Länder, Regionen und Städte einzutragen, in denen sich seine Objekte befinden. Die Objekte können einem Ort zugewiesen werden. Die Orte werden im Buchungsformular bzw. auf der Kundenhomepage zur Auswahl gestellt.
• Suchformular – sowohl die Gäste als auch die Nutzer des Buchungssystems müssen in der Lage sein, freie Mietobjekte zu bestimmten Zeiträumen möglichst schnell und einfach zu finden. Das Suchformular soll Felder beinhalten, wie das Anreise- sowie Abreisedatum, der Ort bzw. die Region oder die Anzahl der Personen. Die Felder für das Suchformular können erst dann festgelegt werden, wenn ich über eine Liste der Objekteigenschaften verfüge. Dazu folgt später noch mehr.

Ich habe oben die wichtigsten Anforderungen an das System beschrieben. Ich weise nochmals darauf hin, dass es sich um eine grobe und vorläufige Liste gehandelt hat.