Warum jedes Projekt eine Grid braucht und warum das nichts mit persönlichem Geschmack zu tun hat
Erst neulich wieder belächelte mich mein Kollege Andi, als ich im Pitch eines neuen Projekts meinte: „Und dann noch eine Grid für die Übersicht aller Aktivitäten.“ – „Du und die Grid, ey!“, sagte er lachend. So ganz will er meine Grid-Liebe nämlich nicht teilen, aber dafür gibt es ja jetzt diesen Blog-Beitrag.
Und vorab:
- Finde ich Grids super? – Klar!
- Ist es persönlicher Geschmack? – Sicher!
- Gibt es Alternativen zur Grid? – No way! (Okay, okay: Vielleicht.)
- Bringe ich auf Biegen und Brechen in jedem Projekt eine Grid unter? – Natürlich! (… tue ich das nicht)
Aber (und das ist der Teil, den ich vollauf ernst meine): Eine Grid erhöht mein Vertrauen in eine Softwarelösung. Und Vertrauen ist in Business-Software keine „weiche“ Kategorie, sondern ein Faktor von bedingungsloser Relevanz.
- Ohne Vertrauen kein Commitment.
- Ohne Commitment keine Performance.
- Und ohne Performance bleibt das Potenzial meiner Business-Anwendung auf der Strecke.
Aber was muss Business-Software im Kern leisten? Sie muss meine Prozesse abbilden und Arbeit beschleunigen. Oder noch weiter aggregiert: Sie muss die richtigen Dinge richtig tun. Keine Ablenkung. Keine Mehrdeutigkeit. Straight-Forward. Das schreit nach dedizierten Workflows und Reports. Nach Oberflächen, die es mir ermöglichen, mich voll auf meinen Anwendungsfall zu konzentrieren. Und für 95% der Fälle funktioniert dieser Happy Path auch ganz ausgezeichnet. Doch Business wäre nicht Business, wenn alles nach Schema F abliefe. Business-Software muss auch die übrigen 5% des Geschäfts abbilden. Das bedeutet nicht, dass jede Sonderlocke durchdekliniert sein muss, die Software darf aber auch kein Roadblocker sein. Das gewählte Schema muss sowohl den Standard-Fall abbilden als auch flexibel genug sein, Sonderfälle gut genug abzubilden. Zusammenfassend: Der Input sollte für 100% der Fälle möglich sein, auch wenn die letzten fünf Prozent nicht idealtypische Eingaben sind. Wichtiger ist es, dass alle Fragen, die die nicht idealtypischen Eingaben aufwerfen, auf einfachem Wege beantwortet werden können. Wichtiger als der Perfect Fit ist meiner Meinung nach also die Nachvollziehbarkeit. Denn nur, wenn ich alle Fälle nachvollziehen kann, mein Business plausibel repräsentiert wird, nur dann funktioniert es mit der Tool-Akzeptanz. Zweifel hingegen torpedieren den erfolgreichen Einsatz der Software-Lösung – Schatten- und handgestrickte Backup-Systeme erhalten Vorschub.
Und natürlich gehören Zweifel zum Alltag. Eine Zahl passt nicht. Ein Report sieht komisch aus. Ein Kunde fragt nach. Ein Teammitglied meldet: „Das stimmt so nicht.“ Dann kommt der Moment, in dem Business-Software ihren Charakter zeigt. Ist sie transparent genug, um die Fehlersuche zu unterstützen? Gibt sie das notwendige Tooling an die Hand, um den Deep-Dive zu machen? Oder brauche ich zur Absicherung dieser Fälle weiterhin meine „Schatten-Excel“. Und diese ist kein böser Wille, sie ist ein Symptom. Sie entsteht, wenn Menschen das Gefühl haben: „Ich sehe nicht, was im System passiert. Ich kann’s nicht prüfen. Ich kann’s nicht plausibilisieren. Ich weiß nicht, ob es wirklich stimmt!”
Und genau in diesen Fällen liebe ich die Grid! Sie stellt (quasi) alle Informationen dar – möglichst nahe an der eigentlichen Datenhaltungsebene. Sie versteckt nichts, sie breitet alles fein säuberlich vor mir aus, um mir die Spurensuche so leicht wie möglich zu machen. Klar muss ich wissen, wo ich die Suche anfange, aber ich kann mir sicher sein, dass die Antwort vor mir liegt.
Statt mehrerer erklärungsbedürftiger Spezialwerkzeuge für dedizierte Detailprüfungen, die sich teils überschneiden und teils Lücken lassen, habe ich mit der Grid ein generisches Tool. Mein Grundgedanke dahinter: Lieber alle Daten ausbreiten und die Antwort offenlegen als dedizierte Spezialauswertungen zu fahren, die vielleicht oder vielleicht auch nicht die Antwort auf meine Frage enthalten.
Was genau meine ich nun eigentlich die ganze Zeit mit „Grid” und wo sehe ich sie, ihre Stärken ausspielen?
Wenn ich „Grid“ sage, meine ich nicht irgendeine beliebige, tabellarische Darstellung. Mit Grid meine ich ungefähr das, was MS Excel mit der Pivot-Funktionalität bereithält, nur dass es nicht so schrecklich klobig und behebig umgesetzt ist. Und hier spielt sie schon ihr erstes Ass aus: Eine Grid in meinem Softwareprojekt liefert mir ein starkes analytisches Tool, sodass ich eine Vielzahl von Problemen mit den gegebenen Funktionen ganz ohne Excel-Export lösen kann.
- Grids eignen sich vorrangig für große Datenmengen – sowohl große Zeilenanzahlen (mehrere 10-Tausend) als auch mehrere Dutzend Spalten.
- Sie stellen Trivial-Funktionalitäten wie Filter & Sortierungen zur Verfügung.
- Darüber hinaus erlauben sie mir, Daten in mehreren Ebenen zu gruppieren und damit Zwischenergebnisse (-Summen, -Mittelwerte, etc.) darzustellen, womit ein Top-Down-Einstieg in komplexe Datenwelten spielend einfach wird.
- Views lassen sich individualisieren und zur Wiederverwendung abspeichern. Das heißt: Spalten bearbeiten (Ein-/Ausblenden, Sortieren, Fixieren) und Standard-Filter-Setzen.
- Grid-Charts visualisieren die aktuelle Ansicht grafisch und erlauben dank Drill-Down-Funktion auch in den Diagrammen eine Interaktivität mit den vorliegenden Daten.
- Grids sind generisch, d.h. statt vordefinierter Standard-Reports lassen sich auch Ausnahmen- und Sonderfälle spielend darstellen.
- Nicht zuletzt liefert mir der Excel-Export eine Schnittstelle, womit ich Datenstände abspeichern kann oder eben doch eine Möglichkeit erhalte, sehr spezifische Auswertungen doch in MS Excel durchzuführen.
Klassische Anwendungsfälle sind folgende Plausibilisierungs-Übungen:
- „Zeig mir alle Artikel ohne Gewicht.“
- „Gruppiere nach Kategorie und zähle.“
- „Sortiere nach Preis absteigend, aber nur für Lieferant X.“
- „Was sind Ausreißer?“
Warum wir bei esveo seit über 10 Jahren so auf Grids pochen
Die Grid begleitet uns von Anfang an. Ich erinnere mich noch gut daran, wie Andi und Conrad, die esveo-Entwickler der ersten Stunde, vor über 10 Jahren in der SLUB saßen und an einer ersten Version tüftelten.
Seitdem ist „unsere Grid” in unterschiedlichsten Projekten gewachsen – nicht, weil wir Tabellen so hübsch finden, sondern weil wir immer wieder gesehen haben, was passiert, wenn dieses Diagnosewerkzeug fehlt. Und auch: Weil wir gesehen haben, wie das Herz unserer Kunden aufgeht, wenn sie im Handumdrehen Datenpflegefehler finden, die sie seit Jahren vermutet haben, aber nie verfolgen, geschweige denn quantifizieren konnten. Und beim Pitch von neulich: Dort brauchte es eine Möglichkeit, eine Vorschau- und eine Druck-Ansicht aller Daten eines Users gruppiert anhand eines bestimmten Kriteriums und chronologisch sortiert anzuzeigen. Die Standardkomponente esveo-Grid ist dafür nicht der Kamm, über den alle Projekte gebürstet werden, sondern der effizienteste Weg, die geforderte Funktionalität ganz pragmatisch abzubilden.
Die Grid hilft:
- wenn etwas nicht passt,
- wenn ich etwas erklären muss,
- wenn ich Verantwortung übernehmen soll,
- wenn ich Zahlen plausibilisieren will,
- wenn ich Schatten-Excels kleinhalten will.
Kurzum: Die Grid ist kein technischer Schnickschnack, der viel Freude bei Konzeption & Entwicklung bereitet, sondern bewährt sich seit jeher in unseren Projekten. Kann ich erfolgreiche Projekte auch ohne Grid umsetzen? - Sicher! Wird ein Projekt allein durch eine Grid erfolgreich? – Sicher nicht! Doch sobald größere Datenmengen im Spiel sind, lässt sich so viel produktiver mit diesen Daten interagieren als ohne, dass ein Verzicht auf eine Grid dem Verzicht auf Effektivität gleichkommt.
)
)
)
)
)
)
)
)
)
)