Wenn Sie ein Abonnement des Magazins 'Access im Unternehmen' besitzen, können Sie sich anmelden und den kompletten Artikel lesen.
Anderenfalls können Sie das Abonnement hier im Shop erwerben.
Kanban mit Outlook und Access
Haben Sie auch manchmal den Eindruck, dass Sie zu viele Projekte gleichzeitig beackern und den Überblick verlieren könnten? Mir passierte das regelmäßig. Bis ich über Kanban gestolpert bin und Teile des Konzepts in meine eigenen Abläufe eingebaut habe. Kanban soll durch eine Visualisierung der aktuellen Projekte und ihres Fortschritts eine bessere Übersicht bieten und vor allem die Anzahl der gleichzeitig begonnenen Projekte begrenzen. Dies baue ich in meine langjährige Praxis zur Zeiterfassung mit Outlook und Access ein. Wie das gelingt, zeigt der vorliegende Beitrag.
Eines der Probleme der heutigen Zeit ist, dass wir immer mehr unter zeitlichem Druck stehen und scheinbar immer mehr Aufgaben zu bewältigen haben. In der Tat sieht man in vielen Bereichen des Lebens, dass Aufgaben viel lieber aufgeschoben als erledigt werden. Ich muss selbst gestehen, dass ich manche unklare Leseranfrage lieber mit einer Gegenfrage beantworte, um diese erstmal vom Tisch zu haben. Tatsache ist: Die Frage kommt wieder zurück, und irgendwann muss ich mich ohnehin darum kümmern.
Die Anzahl der Aufgaben steigt allerdings kontinuierlich, solange man diese immer wieder in eine Warteschlange schiebt, statt sich abschließend um die Bearbeitung zu kümmern und die Aufgabe endlich von der Liste verschwinden lässt.
Die Lösung aus Outlook, Access und Kanban, die dieser Beitrag präsentiert, zeigt, wie ich zuletzt meine Projekte bearbeitet habe. Sie setzt auf einer Projektzeiterfassung auf, die ich bereits seit einigen Jahren nutze, um meine Arbeitszeiten zu protokollieren (die Basis dazu finden Sie im Beitrag Projektzeiterfassung mit Outlook und Access, www.access-im-unternehmen.de/1016). Dabei verwende ich Outlook, um Aufgabenordner synonym zu Projekten, Aufgaben zu Aufgaben und Termine zu Tätigkeiten einzutragen. Die Daten werden im Hintergrund in einer Access-Datenbank gespeichert. Was hat das mit Kanban zu tun, beziehungsweise mit der hier verwendeten Interpretation dieser Vorgehensweise?
Wir wollen den Kanban-Ansatz insoweit nutzen, als dass wir für unsere Aufgaben verschiedenen Status definieren, die diese dann durchlaufen (ja, Status ist der Plural von Status – ich war selbst anfangs überrascht ...).
Kanban-Kategorien
Die bisherige Vorgehensweise bei der einfachen Variante der Projektzeiterfassung sieht wie in Bild 1 aus. Hier haben Sie unter dem Ordner Projekte neue Projekte angelegt (zum Beispiel Beispielprojekt 1), darin Aufgaben erstellt (Beispielaufgabe 1) und diese als Tätigkeiten in den Kalender gezogen.
Nun wollen wir in die Liste mit den Aufgaben auf der rechten Seite noch Kategorien einfügen. Das gelingt über die Benutzeroberfläche ganz einfach, indem Sie den Aufgaben jeweils eine neue Kategorie hinzufügen. Dazu wählen Sie aus dem Kontextmenü einer der Aufgaben den Eintrag Kategorisieren und die jeweilige Kategorie aus (s. Bild 2).
Mit einem Klick auf den Eintrag Alle Kategorien öffnen Sie den Dialog aus Bild 3. Hier legen Sie mit einem Mausklick auf die Schaltfläche Neu weitere, benutzerdefinierte Kategorien an.
Nachdem Sie die gewünschten Kategorien angelegt und diese den Aufgaben zugewiesen haben, erhalten Sie das Bild aus Bild 4. Dies reicht uns allerdings noch nicht: Die Aufgaben sollen ja auch noch nach Kategorien gruppiert und möglichst mit der Kategorie als Gruppenüberschrift dargestellt werden. Um dies zu erreichen, ist allerdings nur noch ein kleiner Schritt nötig.
Dazu klicken Sie im Ribbon einfach auf den Eintrag Aufgabenliste|Anordnung|Kategorien. Dies blendet die Kategorien als Überschriften ein (s. Bild 5). Nun wollen wir die Kategorien natürlich nicht von Hand anlegen, sondern in einer Tabelle unserer Datenbank zur Projektzeiterfassung speichern und diese beim Start von Outlook dynamisch einlesen und anzeigen.
Speichern der Kategorien
Dazu wollen wir zunächst eine entsprechende Tabelle anlegen. Diese heißt tblKategorien und sieht im Entwurf wie in Bild 6 aus. Das Feld Kategorie ist mit einem eindeutigen Index versehen, damit jeder Kategoriename nur einmal eingegeben werden kann. Die Kategorienummer soll gegebenenfalls dem Kategorienamen vorangestellt werden können, damit die gewünschte Sortierung der Kategorien in der Aufgabenliste möglich ist.
Das Feld MaximaleElementzahl nimmt die Anzahl der maximal in einer Kategorie enthaltenen Elemente aus. Dies ist einer der Kanban-Grundsätze: Für bestimmte Bearbeitungsschritte soll man nur eine begrenzte Anzahl von Elementen vorsehen können. Damit verhindere ich beispielsweise, dass ich mehr als zwei Artikel gleichzeitig schreibe – oder an der Programmierung der Beispieldatenbanken von mehr als zwei Artikeln arbeite. Wenn man in Outlook mehr als die vorgebenene Anzahl Elemente zu einer Kategorie hinzufügt, soll dies eine entsprechende Meldung auslösen.
Das Feld Farbe legt den Index der Farbe für die Kategorie fest. Das Feld Standard legt fest, welche Kategorie einer neu erstellten Aufgabe zugeordnet werden soll. Das gleich vorgestellte Formular zur Bearbeitung der Kategorien soll sicherstellen, dass nur eine Kategorie gleichzeitig als Standard einstellt werden kann.
Verwalten der Kategorien
Für die Verwaltung der Kategorien erstellen wir ein kleines Access-Formular in der Datenbank zur Projektzeiterfassung. Dieses verwendet die Tabelle tblKategorien als Datenherkunft. Mit einem Listenfeld namens lstKategorien sollen die vorhandenen Einträge ausgewählt werden können (s. Bild 8).
Bild 7: Dialog zum Verwalten der Kategorien in der Entwurfsansicht
Das Listenfeld verwendet die Abfrage aus Bild 7 als Datensatzherkunft. Diese liefert in eckigen Klammern die Nummer der Kategorie plus den Kategorienamen, also etwa so: [00] ToDo. Zusätzlich sortiert sie die Datensätze nach dem Wert des Feldes Kategorienummer.
Damit das Listenfeld nicht die gebundene Spalte mit dem Feld KategorieID, sondern nur das Feld Kategoriename der Abfrage anzeigt, stellen wir die Eigenschaft Spaltenanzahl auf den Wert 2 und Spaltenbreiten auf 0 ein.
Das Formular zeigt, wie üblich, standardmäßig den ersten Datensatz der Datenherkunft an. Damit das Listenfeld den gleichen Eintrag markiert, legen Sie für das Ereignis Beim Laden des Formulars die folgende Ereignisprozedur an:
Private Sub Form_Load()
Me!lstKategorien = Me!KategorieID
End Sub
Andersherum soll das Formular immer den aktuell im Listenfeld ausgewählten Eintrag anzeigen. Dazu verwenden wir eine weitere Ereignisprozedur, die durch das Ereignis Nach Aktualisierung des Listenfeldes ausgelöst wird. Diese enthält nur einen einzigen Befehl, der das Recordset des Formulars auf den Datensatz mit dem Wert im Feld KategorieID sucht, der gerade im Listenfeld markiert ist:
Private Sub lstKategorien_AfterUpdate()
Me.Recordset.FindFirst "KategorieID = " _
& Me!lstKategorien
End Sub
Nun soll der Benutzer natürlich auch neue Kategorien anlegen können. Dies erledigen wir über eine Schaltfläche namens cmdNeu, die folgende Ereignisprozedur auslöst und so den Datensatzzeiger des Formulars auf einen neuen, leeren Datensatz verschiebt:
Private Sub cmdNeu_Click()
DoCmd.GoToRecord Record:=acNewRec
End Sub
Damit der Benutzer nicht über das Formular von Datensatz zu Datensatz wechseln kann, sondern nur über die Auswahl eines Eintrags im Listenfeld, stellen Sie die Eigenschaft Zyklus des Formulars auf Aktueller Datensatz ein. Deshalb benötigen wir auch eine eigene Schaltfläche, damit der Benutzer einen neu hinzugefügten Datensatz speichern kann, ohne anderweitig zu einem anderen Datensatz zu wechseln. Diese löst die folgende Prozedur aus:
Private Sub cmdSpeichern_Click()
RunCommand acCmdSaveRecord
End Sub
Nun kann der Speichervorgang natürlich auch durch andere Aktionen ausgelöst werden, beispielsweise durch das Wechseln des Datensatzes über die Auswahl eines anderen Eintrags im Listenfeld oder auch durch das Schließen des Formulars. Dies fangen wir mit dem Ereignis Nach Aktualisierung ab, das wir wie folgt implementieren:
Private Sub Form_AfterUpdate()
Me!lstKategorien.Requery
Me!lstKategorien = Me!KategorieID
End Sub
Die Prozedur aktualisiert die Datensatzherkunft des Listenfeldes und stellt dieses auf den aktuell im Formular ausgewählten Datensatz ein. Schließlich wollen wir auch noch Datensätze löschen können, was wir mit der Schaltfläche cmdLoeschen realisieren. Diese löst folgende Prozedur aus:
Private Sub cmdLoeschen_Click()
If IsNull(DLookup("AufgabeID", "tblAufgaben", _ "KategorieID = " & Me!KategorieID)) Then
RunCommand acCmdDeleteRecord
Me!lstKategorien.Requery
Me!lstKategorien = Me!KategorieID
Else
MsgBox "Die Kategorie kann nicht gelöscht werden, da sie bereits Einträge enthält."
End If
End Sub
Die Prozedur prüft, ob die zu löschende Kategorie bereits einer Aufgabe zugewiesen ist. Ist dies der Fall, wird der Löschvorgang nicht durchgeführt, sondern es erscheint eine entsprechende Meldung. Anderenfalls löscht die Prozedur den aktuellen Datensatz, aktualisiert die Datensatzherkunft des Listenfeldes und markiert dort den aktuell im Formular angezeigten Datensatz. Das Formular sieht schließlich wie in Bild 9 aus.
Initialisieren der Kategorieansicht
Nun wollen wir dafür sorgen, dass alle in der Tabelle gespeicherten Tabellen in Outlook vorhanden sind und mit den entsprechenden Farben angezeigt werden. Dazu benötigen wir eine Prozedur, die beim Starten von Outlook aufgerufen wird. Im Beitrag Projektzeiterfassung mit Outlook und Access haben Sie ja bereits die Ereignisprozedur Application_Startup kennen gelernt, die beim Start von Outlook automatisch ausgelöst wird. Dieser fügen wir den Aufruf unserer kleinen Routine zum Kontrollieren und Hinzufügen der Kategorien hinzu:
Public Sub Application_Startup()
...
KategorienKontrollieren
...
End Sub
Die Prozedur KategorienKontrollieren selbst finden Sie im Modul mdlKanban (s. Listing 1). Die Prozedur verwendet ein Recordset-Objekt namens rst, um alle Datensätze der Tabelle tblKategorien zu durchlaufen. Die Property Get-Prozedur CurrentDBC aus dem Modul mdlGlobal liefert einen Verweis auf das Database-Objekt der Datenbank Projektzeiterfassung.accdb, deren Name in einer Konstanten im gleichen Modul verankert ist. Weiterhin füllt die Prozedur das Objekt objCategories mit einer Liste der Kategorien des aktuellen Namespace-Objekts von Outlook, das die Funktion GetMAPINamespace liefert. Jede Kategorie wird in Outlook nämlich in einem eigenen Category-Objekt vorgehalten. Nun durchläuft die Prozedur in einer äußeren Do While-Schleife alle Datensätze der Tabelle tblKategorien, also alle Kategorien, die eigentlich in Outlook sichtbar sein sollten. Dabei stellt sie die Variablen bolKategorie und lngFarbe auf die Werte False und 0 ein, um diese für den aktuellen Schleifendurchlauf zu initialisieren. Innerhalb der Schleife durchläuft sie dann alle Category-Objekte der Auflistung in objCategories und referenziert das aktuelle Objekt in der Variablen objCategory. Sollte der Name der Kategorie aus objCategory.Name mit dem aus den Feldern Kategorienummer und Kategorie zusammengesetzten Kategorienamen (etwa 01_Todo) des aktuellen Datensatzes übereinstimmen, ist die Kategorie bereits vorhanden. Die Prozedur stellt dann bolKategorie auf True ein und verlässt die For-Schleife.
Public Sub KategorienKontrollieren()
Dim rst As DAO.Recordset
Dim objCategory As Outlook.Category
Dim objCategories As Outlook.Categories
Dim bolKategorie As Boolean
Dim lngFarbe As Long
Set rst = CurrentDBC.OpenRecordset("SELECT * FROM tblKategorien", dbOpenDynaset) Set objCategories = GetMAPINamespace.Categories
Do While Not rst.EOF
bolKategorie = False
lngFarbe = 0
For Each objCategory In objCategories
If objCategory.Name = rst!Kategorienummer & "_" & rst!Kategorie Then
bolKategorie = True
Exit For
End If
Next objCategory
If bolKategorie = True Then
If IsNull(rst!Farbe) Then
rst.Edit
Dies war die Leseprobe dieses Artikels.
Melden Sie sich an, um auf den vollständigen Artikel zuzugreifen.