Geschäftsprozesse digitalisieren: Offerten und Projekte als Knackpunkt

Phase eins: die harten Zahlen

Buchhaltung, Lohnverarbeitung, Debitoren, Kreditoren, Banksynchronisation – das sind die Themen, mit denen einige Migrationen beginnen. Und das aus gutem Grund: Sie sind anspruchsvoll, aber sie sind klar definiert. Soll und Haben müssen stimmen. Mehrwertsteuer-Codes folgen festen Regeln. Eine Eröffnungsbilanz ist eine Eröffnungsbilanz, in jedem System.

Migrationen in diesem Bereich sind Handwerk. Anspruchsvoll, aber endlich. Wer sauber arbeitet, kommt am Ende immer ans Ziel.

Phase zwei: die weichen, aber relevanten Prozesse

Sobald es um Offertstellung, Projektmanagement, Helpdesk oder die interne Dokumentation geht, ändert sich das Spiel. Diese Prozesse sind in keinem Unternehmen identisch. Sie sind über Jahre gewachsen, oft unbewusst, geprägt von einzelnen Personen, von Branche, von Unternehmenskultur. Und sie sind in den seltensten Fällen sauber dokumentiert.

Genau hier wird es interessant – und schwierig.

Beispiel Offertstellung

Wie eine Offerte bei euch im Unternehmen entsteht, ist auf den ersten Blick eine triviale Frage. Auf den zweiten Blick steckt darin eine ganze Reihe von Entscheidungen, die jede Firma anders trifft:

• Wird nach Aufwand offeriert oder mit Pauschalen gearbeitet?
• Gibt es eine standardisierte Rabattlogik – oder verhandelt jede:r Kundenberater:in individuell?
• Welche Standardtexte gehören in jede Offerte, welche sind situativ?
• Wer hat welche Freigabekompetenz, ab welchem Betrag braucht es eine zweite Unterschrift?
• Wie wird aus einer Offerte ein Auftrag, und was passiert dann automatisch?

In den meisten KMU sind die Antworten auf diese Fragen nicht aufgeschrieben. Sie leben in den Köpfen einzelner Personen. Sobald man sie in einem System abbilden muss, wird klar: Es gibt nicht eine Offertstellung, sondern oft mehrere parallel existierende Versionen davon.

Beispiel Projektmanagement

Hier prallen Methodiken und persönliche Vorlieben aufeinander. Kanban oder klassisches Wasserfall-Modell? Stunden direkt am Task buchen oder in einer separaten Erfassung? Wie wird ein Projektbudget überwacht – pro Phase, pro Aufgabe, pro Team? Und vor allem: Wann eskaliert ein Projekt, und an wen?

Die Antworten variieren nicht nur von Firma zu Firma, sondern oft auch zwischen Abteilungen oder einzelnen Projektleitenden. Eine Software wie Odoo lässt sich für viele dieser Varianten konfigurieren – aber sie kann nicht entscheiden, welche Variante euer Unternehmen will. Diese Entscheidung muss vor der Konfiguration fallen.

Beispiel Helpdesk

Ab wann ist ein Ticket eigentlich eskaliert? Welche SLAs gelten für welche Kunden – und wie werden sie technisch durchgesetzt? Wie ist die interne Wissensbasis angebunden, damit Tickets nicht zum hundertsten Mal von Hand beantwortet werden müssen? Was passiert, wenn eine Kundin gleichzeitig mehrere offene Probleme hat?

In vielen Unternehmen werden diese Fragen pragmatisch und ad-hoc beantwortet. Das funktioniert, solange das Team klein ist und alle dieselbe Vorstellung im Kopf haben. Sobald aber ein System dahintersteht, muss alles explizit gemacht werden.

Die unbequeme Wahrheit – und die Chance dahinter

Eine Migration zwingt einen, die eigenen Prozesse offenzulegen. Manchmal ist das schmerzhaft. Manchmal merkt man dabei zum ersten Mal, dass es eigentlich keinen einheitlichen Prozess gibt – sondern dass das Unternehmen in den letzten Jahren auf einer Mischung aus Routine, Abstimmung und Improvisation funktioniert hat.

Genau das ist aber auch die grosse Chance. Eine Migration ist die beste Gelegenheit, gewachsene Strukturen einmal kritisch zu hinterfragen. Was funktioniert wirklich? Was machen wir nur, weil wir es schon immer so gemacht haben? Wo verlieren wir Zeit, weil unser Prozess nie richtig durchdacht wurde?

Die Software ist dabei nicht das Hindernis, sondern der Auslöser für eine Reflexion, die sonst nie stattfindet.

Was das für die Planung bedeutet

Wer sich auf eine Migration zu Odoo (oder einem vergleichbaren System) einlässt, sollte zwei Dinge nicht unterschätzen:

Erstens: Die zweite Phase – die weichen Prozesse – braucht mehr Zeit als die erste. Nicht für die technische Umsetzung, sondern für die Klärung der Fragen, die das System einem stellt.

Zweitens: Die Klärung dieser Fragen ist nicht das Problem, sondern der eigentliche Wert. Wer aus einer Migration nur ein neues Tool herauszieht, hat die Hälfte des möglichen Nutzens verschenkt. Wer dabei seine Prozesse versteht und klärt, hat ein Unternehmen, das auf einer deutlich solideren Basis arbeitet als vorher.

Das ist letztlich der Grund, warum es sich lohnt, sich auf den Aufwand einzulassen.