Vor der Softwareauswahl: Dokumentieren Sie, wie Entscheidungen im Unternehmen wirklich getroffen werden

Vierzig Funktionen stehen auf der Vergleichsliste für das neue Projektmanagement-Tool, drei Anbieter sind in der engeren Auswahl, die Testzugänge laufen schon. Dann stellt jemand die einfachste Frage des ganzen Projekts: Wer gibt bei uns eigentlich ein Budget über 5.000 Euro frei, und auf welchem Weg? Schweigen im Besprechungsraum. Genau deshalb sollten Sie vor jedem Softwarekauf zuerst Ihre Entscheidungsprozesse dokumentieren - sonst konfiguriert Ihr Team ein Werkzeug für Abläufe, die niemand beschreiben kann.

Dieses Missverhältnis ist der Normalfall: Für die Auswahl der Software existieren Bewertungsbögen, Punktesysteme und Testprotokolle. Für die Frage, wie das eigene Haus zu Entscheidungen kommt, gibt es dagegen selten mehr als Erinnerungen und Flurfunk. Dabei bildet jedes CRM-System, jedes Projektmanagement-Tool und jede Freigabesoftware am Ende ebendiese internen Wege ab - im Guten wie im Schlechten.

Entscheidungsprozesse dokumentieren heißt, schriftlich festzuhalten, wie Entscheidungen in Ihrem Haus tatsächlich zustande kommen: wer sie anstößt, wer mitredet, wer freigibt und wie lange der Weg dauert. Diese Praxis wird auch Entscheidungsdokumentation genannt; ihr zentrales Arbeitsmittel ist das Entscheidungslog, eine fortlaufende Liste realer Entscheidungsfälle. Relevant ist sie vor allem für die Geschäftsführung, IT-Verantwortliche und Projektleiter - insbesondere dann, wenn eine neue Software künftig Budgets, Freigaben oder Aufgaben abbilden soll. So entsteht eine belastbare Grundlage für die Auswahl: konkrete Rollen, Freigabestufen und Schnittstellen statt einer Wunschliste, die an der gelebten Praxis vorbeigeht.

Im weiteren Verlauf finden Sie eine Vorlage mit fünf Feldern, einen Zwei-Wochen-Plan für die Aufnahme im Alltag und den Weg vom ausgefüllten Log zur konkreten Anforderung. Als durchgängiges Beispiel dient eine Agentur mit 45 Beschäftigten, die vor der Einführung einer neuen Projektmanagement-Software steht.

Warum Software-Projekte an unsichtbaren Entscheidungswegen scheitern

Software scheitert selten an fehlenden Funktionen und weit häufiger an falsch abgebildeten Abläufen. Das Tool bildet beim Start genau die Prozesse ab, die jemand bei der Einrichtung beschrieben hat - und wenn niemand die realen Wege vorher beschrieben hat, landet eben eine Vermutung in der Konfiguration.

Ein typisches Beispiel aus Einführungsprojekten zeigt das Muster: Ein mittelständisches Unternehmen richtet den Genehmigungsworkflow für Bestellungen streng nach dem Organigramm ein, mit drei Stufen von der Teamleitung über die Abteilungsleitung bis zur Geschäftsführung. Sechs Wochen nach dem Start läuft die Hälfte der Bestellungen wieder per E-Mail am System vorbei. Der Grund: Die Abteilungsleitung hatte Freigaben unter 1.000 Euro in der Praxis längst an die Teamleitungen delegiert, nur stand diese Delegation nirgends. Das Werkzeug war korrekt konfiguriert - allerdings auf Grundlage einer Ordnung, die es so nie gegeben hat.

Entscheidungswege im Unternehmen sind fast immer älter als jede Prozessbeschreibung. Sie sind mit den Personen gewachsen, haben Ausnahmen, Abkürzungen und stille Mitentscheider. Ein Organigramm beantwortet die Frage, wer wem unterstellt ist; es beantwortet nicht, wessen Einwand ein Projekt tatsächlich stoppt. Wer vor dem Kauf seine Entscheidungsprozesse dokumentieren will, sucht deshalb nicht nach der offiziellen Regel, sondern nach dem wiederkehrenden Muster.

Die Kosten dieser Unkenntnis zeigen sich zeitversetzt. Erst wirkt die neue Software nur ungewohnt, dann entstehen Umgehungen: Freigaben per Messenger, parallele Listen, doppelt gepflegte Daten. Nach einem halben Jahr läuft über das teure System nur noch ein Teil der echten Vorgänge, und die Auswertungen, für die es gekauft wurde, sind lückenhaft. Diese Lücke zwischen Papierlage und Praxis ist kein Betriebsunfall, sondern hat System - und genau deshalb lohnt sich ein genauer Blick darauf.

Offizielle Prozesse und gelebte Praxis: Wo die Lücke entsteht

Zwischen dem beschriebenen und dem gelebten Prozess liegt in fast jedem Unternehmen eine Grauzone. Freigaben passieren im Flur, Vetos kommen per Zuruf, und manche Unterschrift ist reine Formsache, weil die eigentliche Zusage längst gefallen ist.

Typische Beispiele für diese Lücke sehen so aus:

Keine dieser Abweichungen entsteht aus Nachlässigkeit. Informelle Wege sind schlicht schneller als offizielle, und solange das Ergebnis stimmt, fragt niemand nach dem Verfahren. Kritisch wird die Lücke erst, wenn eine Software den offiziellen Weg erzwingt: Dann weichen die Beteiligten aus, etwa auf E-Mail, private Messenger oder schnell gebuchte Cloud-Dienste. Wer Schatten-IT vermeiden will, also den Einsatz nicht freigegebener Software am Regelweg vorbei, muss darum zuerst verstehen, warum die inoffiziellen Wege attraktiv sind, statt sie allein per Systemzwang zu verbieten.

Für die Softwareauswahl ergibt sich daraus eine unbequeme Reihenfolge: erst die Praxis erheben, dann bewerten, welche Abweichungen das neue Tool übernehmen soll und welche es korrigieren darf. Das Werkzeug für diese Erhebung ist bewusst schlicht: eine Tabelle mit fünf Spalten.

Vorlage Entscheidungslandkarte: Echte Genehmigungswege sichtbar machen

Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten

Ich bestätige hiermit, dass ich die Bedingungen der Datenschutzpolitik von Bitrix24 vollständig gelesen und verstanden habe.

Die Entscheidungslog-Vorlage: fünf Felder reichen für den Anfang

Ein Entscheidungslog braucht keine eigene Software und kein Schulungsprogramm; eine geteilte Tabelle genügt. Teams, die zum ersten Mal ihre Entscheidungsprozesse dokumentieren, kommen mit fünf Feldern pro Eintrag aus:

• Anlass: Was hat die Entscheidung ausgelöst - ein Antrag, ein Problem, eine Kundenanfrage?
• Beteiligte: Wer war beteiligt, und in welcher Funktion: Anstoß, Mitsprache, Prüfung oder Freigabe?
• Weg: Über welche Stationen und Kanäle lief die Entscheidung, vom ersten Zuruf bis zur Zusage?
• Dauer: Wie viele Arbeitstage vergingen vom Anstoß bis zum Ergebnis, und wo entstand die Wartezeit?
• Ergebnis: Was wurde entschieden, mit welchen Auflagen oder Bedingungen?

Wie das ausgefüllt aussieht, zeigt ein Fall aus der 45-Personen-Agentur unseres Beispiels. Eine Designerin benötigte eine Einzelplatzlizenz für ein Bildbearbeitungsprogramm:

Schon dieser eine Eintrag widerlegt die offizielle Regel der Agentur, nach der die IT-Leitung Tool-Anschaffungen bis 500 Euro allein genehmigt. Tatsächlich kam die Freigabe von der kaufmännischen Leitung, per Chat und ohne Formular. Sichtbar wird zugleich, wo die Zeit blieb: 6 der 11 Arbeitstage entfielen auf externe Wartezeit, nicht auf interne Abstimmung. Beides wird später zur harten Anforderung an die neue Software - eine zweite Freigabestufe und automatische Erinnerungen bei liegengebliebenen Vorgängen.

Ein einzelner Fall bleibt allerdings eine Anekdote. Sein Wert entsteht durch Wiederholung, und dafür braucht es einen begrenzten, gut vorbereiteten Erhebungszeitraum.

Zwei Wochen mitschreiben: So läuft die Aufnahme im Alltag

Die gute Nachricht: Sie können Entscheidungsprozesse dokumentieren, ohne den laufenden Betrieb zu unterbrechen - wer auf diesem Weg Ist-Prozesse aufnehmen will, also den tatsächlichen statt den vorgesehenen Ablauf erfassen möchte, braucht weder Workshops noch Interviewreihen. Das Log entsteht nebenbei, während das Tagesgeschäft weiterläuft. Damit das klappt, hat sich folgender Ablauf bewährt:

1. Zeitraum festlegen. Zehn Arbeitstage, also zwei gewöhnliche Arbeitswochen, sind ein guter Rahmen. Wählen Sie Wochen ohne Messetermine, Urlaubswellen oder Jahresabschluss, sonst protokollieren Sie Ausnahmen statt Regeln.
2. Verantwortlichkeiten klären. Je Abteilung schreibt eine benannte Person mit und trägt nach, was Kolleginnen und Kollegen melden. Ohne feste Zuständigkeit versandet das Log nach drei Tagen.
3. Schwelle definieren. Notiert wird, was Geld kostet, Personen bindet oder Zusagen an Kunden nach sich zieht. Die Wahl des Besprechungsraums bleibt draußen.
4. Detailtiefe begrenzen. Drei bis fünf Minuten pro Eintrag sind der Richtwert. Wer länger schreibt, dokumentiert zu viel und gibt nach wenigen Tagen auf.
5. Stakeholder einbinden. Informieren Sie Teamleitungen und, wo vorhanden, den Betriebsrat vor dem Start. Die Botschaft: Erhoben werden Abläufe, nicht die Leistung einzelner Personen.
6. Zwischenbilanz nach fünf Arbeitstagen ziehen. Ein kurzer Blick in die Einträge zeigt, ob die Schwelle passt und ob alle Abteilungen liefern. Nachsteuern kostet jetzt wenig, am Ende dagegen den halben Erhebungszeitraum.

Bei der Beispiel-Agentur kamen in den zehn Arbeitstagen 17 Einträge zusammen, im Schnitt also knapp zwei pro Tag: 9 Anschaffungs- und Budgetfragen, 5 Fälle aus der Personaleinsatzplanung und 3 Kundenzusagen. Diese Verteilung ist selbst schon ein Befund, denn sie zeigt, welche Entscheidungstypen die künftige Software am dringendsten abbilden muss.

Nach zwei Wochen liegt damit Rohmaterial vor. Der eigentliche Gewinn steckt im nächsten Schritt: darin, aus den Einträgen Anforderungen zu machen.

"Nach der Einführung von Bitrix24 haben wir die Geschäftsprozesse in unserem Unternehmen maximal vereinfacht."

Geschäftsführer, Alexander Dortmann

DortmannKids

KOSTENFREI STARTEN

Vom Log zur Anforderung: Was das ausgefüllte Log für die Softwareauswahl liefert

Wer nach „Anforderungsanalyse Software“ sucht, findet Kriterienkataloge mit mehr als hundert Zeilen, von denen die meisten für das eigene Haus keine Rolle spielen. Das Log dreht die Richtung um: Es liefert ausschließlich Anforderungen, die aus echten Fällen stammen.

Drei Auswertungsschritte haben sich bewährt.

1. Rollen zuordnen . Das RACI-Modell verteilt vier Funktionen auf jede Entscheidung: Responsible (arbeitet aus), Accountable (verantwortet und gibt frei), Consulted (wird vorher gefragt), Informed (wird nachher informiert). Im Lizenzfall der Agentur war der IT-Leiter Responsible, die kaufmännische Leitung Accountable, die Teamleiterin Consulted und die Designerin Informed. Sobald diese Zuordnung für die häufigsten Entscheidungstypen steht, endet das Rätselraten darüber, wer bei der nächsten Anschaffung gefragt werden muss.
2. Freigabestufen ableiten. Aus den 9 Anschaffungs- und Budgetfragen des Logs leitete die Agentur eine Regel ab, die zur Praxis passt - bis 500 Euro prüft die IT-Leitung fachlich und die kaufmännische Leitung gibt frei, darüber kommt die Geschäftsführung als zweite Stufe hinzu. Ihre Freigabeprozesse stehen damit zum ersten Mal schwarz auf weiß, in einer Form, die sich direkt in einen Workflow übersetzen lässt.
3. Entscheidungsmatrix bauen. Die Matrix ordnet den Entscheidungstypen die jeweiligen Rollen zu: eine Zeile wie „Tool-Anschaffung bis 500 Euro“, daneben Spalten für Prüfung, Freigabe und Information. Die Matrix verdichtet die 17 Einzelfälle zu wenigen Regeln und wird später zur Vorlage für die Konfiguration des neuen Systems.

Am Ende dieses Schrittes besitzt die Agentur eine Anforderungsliste, die kein Katalog liefern kann: zweistufige Freigaben mit Betragsgrenze, Beobachter-Rollen für Consulted- und Informed-Personen, Erinnerungen nach drei Arbeitstagen Stillstand und Vertretungsregeln für Urlaubszeiten. Jede dieser Anforderungen lässt sich auf einen Log-Eintrag zurückführen und damit auch intern begründen, wenn der Anbieter mit der Funktionsliste wedelt.

So nützlich diese Klarheit ist - sie hat Grenzen, und die sollten Sie kennen, bevor aus dem Log ein Dauerprojekt wird.

Wann Dokumentation zur Bremse wird: Die Grenzen des Ansatzes

Entscheidungsprozesse dokumentieren bleibt ein Mittel zum Zweck. Ein Werkzeug, das Klarheit schafft, kann bei Übertreibung das Gegenteil bewirken. Vier Risiken verdienen dabei einen nüchternen Blick: Überdokumentation, veraltete Logs, Misstrauen im Team und ein zu enges Zeitfenster.

Überdokumentation ist das häufigste Risiko. Aus fünf Feldern werden fünfzehn, aus fünf Minuten pro Eintrag werden zwanzig, und nach der zweiten Woche trägt niemand mehr etwas ein. Die Grenze aus dem Erhebungsplan gilt darum dauerhaft: Sobald ein Eintrag mehr als fünf Minuten kostet, ist die Vorlage zu umfangreich geworden und gehört gekürzt.

Veraltete Logs sind das zweite Risiko. Ein Entscheidungslog beschreibt den Zustand eines Zeitraums; wechselt die kaufmännische Leitung oder ändert sich die Betragsgrenze, stimmt der alte Stand nicht mehr. Versehen Sie jedes Log mit Erhebungszeitraum und Standdatum, und archivieren Sie es nach der Softwareeinführung, statt es ungepflegt weiterlaufen zu lassen. Ein zwei Jahre altes Log, das als aktuell gilt, richtet mehr Schaden an als gar keines.

Das dritte Risiko betrifft das Vertrauen im Team. Mitschreiben kann als Überwachung verstanden werden, besonders wenn Namen und Bearbeitungsdauern nebeneinander stehen. Halten Sie die Auswertung deshalb auf der Ebene von Rollen statt Personen, und lassen Sie vertrauliche Personalentscheidungen ganz aus dem Log heraus. Akute Krisenentscheidungen gehören ebenfalls nicht hinein: Wer im Notfall erst das Formular sucht, hat den Zweck missverstanden.

Ein vierter Stolperstein ist das Zeitfenster selbst. Zwei Wochen bilden nur ab, was in diesen zwei Wochen tatsächlich passiert: Fällt die Erhebung in eine ruhige Phase, fehlen die Budgetrunde, die Quartalsplanung oder der Jahresabschluss komplett, und die abgeleiteten Regeln berücksichtigen genau die Entscheidungen nicht, die das meiste Geld bewegen. Prüfen Sie darum vor dem Start, welche Entscheidungstypen im gewählten Zeitraum realistisch vorkommen. Seltene, aber gewichtige Fälle ergänzen Sie nachträglich aus dem Gedächtnis der Beteiligten - im Log deutlich als rekonstruiert markiert, nicht als beobachtet. Eine halbe Stunde mit der kaufmännischen Leitung über die letzten drei Großanschaffungen liefert diese Einträge in einem Termin, und die Freigabestufen aus dem vorigen Abschnitt decken danach auch die Fälle ab, die nur viermal im Jahr anfallen.

Daneben hat der Ansatz auch eine begrenzte Reichweite. Das Log ersetzt keine vollständige Prozesslandkarte, also die Übersicht sämtlicher Geschäftsprozesse eines Unternehmens. Für die Softwareauswahl ist das kein Mangel: Der Ausschnitt aus den realen Entscheidungsfällen reicht dafür aus, und in Unternehmen mit weniger als zehn Beschäftigten genügt mitunter ein einziges gemeinsames Gespräch über die letzten zehn Entscheidungen. Bleibt die Frage, wo das Material am besten liegt und wie es nach dem Kauf weiter genutzt wird.

Entscheidungsprozesse dokumentieren mit Bitrix24: von der Wissensdatenbank bis zum Freigabe-Workflow

Für den Weg von der Erhebung bis zur Umsetzung lässt sich Bitrix24 als durchgängige Arbeitsumgebung nutzen. Die Wissensdatenbank dient dabei als zentraler Ort für die Dokumentation: Die Entscheidungslog-Vorlage und die daraus abgeleiteten Regeln - Betragsgrenzen, Rollen und Entscheidungsmatrix - liegen dort für alle Berechtigten auffindbar an einem Ort.

Aufgaben mit unterschiedlichen Rollen können die RACI-Logik im Alltag annähernd abbilden. Die verantwortliche Person entspricht dem Responsible, Mitwirkende übernehmen die Rolle der Consulted-Personen und Beobachter bleiben als Informed über den Verlauf auf dem Laufenden. Die Accountable-Rolle wird je nach Prozess über die auftraggebende Person, die Aufgabenkontrolle oder eine eigene Freigabestufe abgebildet. Wer eine Entscheidung anstößt, legt eine Aufgabe an - und der Weg, der früher über Zurufe lief, bekommt eine nachvollziehbare Spur mit Datum und Beteiligten.

Workflows, RPA und Automatisierungsregeln übersetzen anschließend die erhobenen Freigabewege in feste Abläufe. Für die Beispiel-Agentur heißt das: Ein Anschaffungsantrag bis 500 Euro kann zunächst eine Prüfaufgabe für die IT-Leitung auslösen und danach zur Freigabe an die kaufmännische Leitung weitergeleitet werden. Überschreitet ein Vorgang eine definierte Frist, kann das System eine Erinnerung oder Benachrichtigung auslösen. Über Zugriffsrechte lässt sich zugleich festlegen, wer die dokumentierten Regeln, Anträge und Entscheidungen sehen oder bearbeiten darf.

Starten können Sie klein: Legen Sie die Entscheidungslog-Vorlage in der Wissensdatenbank an und beginnen Sie mit den zehn Arbeitstagen Erhebung. Sobald die ersten Muster sichtbar sind, lassen sich daraus strukturierte Freigabeprozesse mit den passenden Rollen, Feldern und Automatisierungen aufbauen. Eröffnen Sie jetzt Ihr kostenloses Bitrix24-Konto und schaffen Sie die Grundlage dafür, Ihre Entscheidungsprozesse an einem zentralen Ort zu dokumentieren und später in verbindliche Workflows zu überführen.

FAQ