Können meine Leute Daten erfassen, ohne ständig das Programm zu wechseln?
Deine Leute arbeiten den ganzen Tag in Outlook und Teams. Daneben läuft das ERP für die Auftragsbearbeitung. Und dann gibt es noch das kleine Zusatz-Tool für die Prozesse, die das ERP nicht abdeckt: die Reklamationsliste, die Geräte-Übergabe, die Nachverfolgung von Sonderbestellungen. Drei Fenster, ständiges Wechseln, und am Ende landet die Hälfte der Daten gar nicht im System, weil das Extra-Tool eben doch zu umständlich ist.
Das ist kein Disziplinproblem. Ein Programm, das man extra starten muss, wird im Alltag schlicht vergessen. Die Frage ist also nicht, wie Du Deine Leute zur Nutzung erziehst, sondern wie die Erfassung dorthin kommt, wo sie ohnehin sind.
Mein erster Reflex wäre eine Access-Datenbank, und in der Cloud-Welt ist das manchmal der falsche Griff
Für solche Zusatzprozesse neben einem alten, nicht mehr anpassbaren ERP baue ich seit über zwanzig Jahren reflexartig eine Microsoft-Access-Anwendung. Das funktioniert, ist schnell gebaut und kostet pro Arbeitsplatz fast nichts. Solange alle im selben Büro am selben Netz sitzen, ist das oft genau richtig.
Der Reflex bricht an zwei Stellen. Access läuft auf dem Desktop im lokalen Netz. Wer mobil, im Homeoffice oder ganz ohne eigenen Rechner arbeitet, braucht eine Runtime, einen VPN-Zugang und ein bisschen Glück. Und Access ist immer ein eigenes Fenster. Es lebt neben Outlook und Teams, nie darin. Genau das Wechseln, das Du loswerden willst, baut Access strukturell wieder ein.
In einer Welt, in der Deine Leute den Tag in Microsoft 365 verbringen, ist die Erfassung am besten dort eingebettet, wo sie ohnehin hinschauen. Dafür ist Access nicht gebaut. Dafür ist die Power Platform gebaut. Das ist kein Widerspruch zu meiner Linie, sondern ihre konsequente Anwendung: das Werkzeug folgt der Struktur, nicht umgekehrt.
Anzeige und Eingabe sind zwei verschiedene Probleme
Wenn von „Daten direkt in Outlook und Teams“ die Rede ist, stecken zwei Dinge drin, die man sauber trennen muss.
Die Anzeige ist der einfache Teil. Eine Power App, die als Reiter in Teams hängt oder die zur gerade geöffneten Mail die passenden Vorgangsdaten zeigt, liest aus Deiner Datenbank. Lesezugriff, fertig. Daran ist nichts kompliziert.
Die Eingabe zerfällt in zwei völlig verschiedene Fälle. Der Normalfall ist das Schreiben in Deine eigene Datenbank für den Zusatzprozess. Das ist exakt das, wofür Du sonst die Access-Datenbank gebaut hättest, nur dass die Maske jetzt in Teams sitzt statt in einem eigenen Fenster. Der Sonderfall ist das Rückschreiben ins ERP selbst. Das ist und bleibt das alte Schnittstellen-Problem und hat mit der Einbettung nichts zu tun. Ob Du ins ERP zurückschreiben darfst, hängt allein davon ab, ob das ERP eine unterstützte Schreib-Schnittstelle hat, nicht davon, in welchem Fenster die Maske steckt.
Die ehrliche Kernaussage lautet deshalb: Die Einbettung ersetzt das separate Frontend, nicht die ERP-Schnittstelle. Anzeige ist leicht, „Eingabe“ meint im Regelfall Deine eigenen Prozessdaten, nicht das ERP.
So sieht der Aufbau konkret aus
In Microsoft Teams hängst Du eine sogenannte Canvas-App als Reiter in den Kanal, in dem das Team ohnehin arbeitet. Sie öffnet sich neben dem Chat, nicht in einem dritten Fenster. Sie schreibt direkt in Dein bestehendes SQL-Server-Backend. Kein zweites Datenmodell, kein nächtlicher Abgleich, keine doppelte Datenhaltung.
Ein ehrlicher Hinweis dazu: Die früher mögliche Variante mit Model-driven-Apps als Teams-Reiter hat Microsoft zum 1. Mai 2026 abgekündigt. Wer heute in Teams einbettet, nimmt Canvas-Apps. Das ist für schlanke Erfassungsmasken ohnehin der passendere Weg.
In Outlook ist die Lage zurückhaltender. Eine Power App direkt in Outlook einzubetten ist kein sauber dokumentierter Standardweg. Der robuste Weg dort ist ein Office-Add-in, also ein eigener kleiner Bereich neben der Mail, der über eine eigene Schnittstelle mit Deiner Datenbank spricht. Das ist mehr Aufwand als der Teams-Reiter. Wer schnell anfangen will, fängt in Teams an.
Der Punkt, den die Power-Platform-Pitches gern überspringen: was es kostet
Hier kommt der Unterschied, der für die Entscheidung zählt. Eine Access-Runtime kostet nichts. Access selbst steckt bei vielen Mittelständlern bereits in der vorhandenen Microsoft-365- oder Office-Lizenz. Der zusätzliche Aufwand pro Arbeitsplatz für ein internes Access-Frontend ist faktisch null, und es gibt keine laufenden Kosten pro App oder pro Vorgang.
Power Apps mit Zugriff auf Deinen SQL Server ist ein anderes Modell. Der SQL-Server-Connector ist ein Premium-Connector, und ein Premium-Connector ist in der normalen Microsoft-365-Lizenz nicht enthalten. Ein Premium-Connector ist eine Verbindung zu einem System, für die Microsoft eine zusätzliche Power-Apps-Lizenz verlangt. Sobald eine App auch nur einen einzigen Premium-Connector nutzt, gilt die Lizenzpflicht für die ganze App und damit für jeden Nutzer.
Konkret heißt das, Stand Mai 2026: Der Power-Apps-Premium-Tarif kostet rund 20 US-Dollar je Nutzer und Monat. Bei 30 internen Nutzern sind das rund 7.200 US-Dollar im Jahr, und zwar jedes Jahr wieder. Den früher günstigeren Per-App-Tarif für rund fünf US-Dollar hat Microsoft Anfang Januar 2026 für neue Direktkunden geschlossen. Verlässlich planen lässt sich heute nur noch mit dem Premium-Tarif oder mit dem nutzungsbasierten Pay-as-you-go-Modell für rund 10 US-Dollar je aktivem Nutzer, App und Monat über ein Azure-Abonnement.
Du zahlst diesen Aufschlag nicht für „schönere Formulare“. Du zahlst ihn für Reichweite: Cloud, mobil, eingebettet in Teams, ohne VPN. Genau das, was Access strukturell nicht kann. Das ist eine vertretbare Rechnung, aber sie muss bewusst aufgemacht werden, nicht im Pitch verschwinden.
Die Backend-Alternativen, und warum der naheliegende Spartrick nicht funktioniert
Wenn der Premium-Connector der Kostentreiber ist, liegt die Frage nahe: Lässt sich das Backend so wählen, dass der Aufschlag entfällt? Die Antwort ist unbequem. Alle relationalen Datenbank-Connectoren sind Premium. Der Wechsel des Datenbank-Motors spart den Aufschlag nicht.
| Backend | Connector-Stufe | Premium-Lizenz nötig? | Wofür sinnvoll |
|---|---|---|---|
| SQL Server (eigen, vor Ort oder gehostet) | Premium | Ja | Dein vorhandenes Backend, volle relationale Stärke, die „Lösung um das ERP herum“ |
| Azure SQL | Premium | Ja | Wie SQL Server, aber als verwaltete Cloud-Datenbank, plus Azure-Hosting-Kosten |
| Dataverse | Premium | Ja, aber im Premium-Tarif schon enthalten | Wenn Du den Premium-Tarif ohnehin zahlst, mit eingebautem Audit-Trail und Berechtigungen |
| Dataverse for Teams | im M365 enthalten | Nein | Kleine, abgeschlossene Teams-App, aber 2 GB Grenze, eine Umgebung je Team, keine Premium-Connectoren, kein Zugriff außerhalb von Teams |
| SharePoint-Listen / Microsoft Lists | Standard | Nein | Einfache, kleinvolumige Prozessdaten, ohne laufende Power-Apps-Kosten |
| MySQL, etwa bei Hetzner | Premium | Ja | Günstiges Hosting, aber spart den Connector-Aufschlag nicht und kostet Dich die SQL-Server-Werkzeuge, die Du schon beherrschst |
Daraus folgt das eigentliche Sortieren. Den Premium-Aufschlag vermeidest Du nur auf zwei Wegen, und beide kosten Dich etwas anderes. Entweder Du gehst in die Standard-Welt mit SharePoint-Listen oder Microsoft Lists. Die sind im Microsoft 365 enthalten, aber sie sind keine relationale Datenbank: Bei größeren Mengen, komplexen Verknüpfungen oder echten Transaktionen stößt Du schnell an Grenzen. Oder Du bleibst mit Dataverse for Teams im Teams-Käfig. Das ist kostenlos, aber auf 2 GB je Team begrenzt, ohne Premium-Connectoren und ohne Zugriff von außerhalb.
Einen Mittelweg, bei dem Du die relationale Stärke behältst und den Aufschlag los wirst, gibt es nicht. Genau diese Ehrlichkeit ist der Punkt. Du entscheidest zwischen einem echten relationalen Backend mit laufender Lizenz pro Kopf und der Standard-Welt mit ihren Funktionsgrenzen. Kein Anbieter schenkt Dir beides.
Wo der Ansatz an Grenzen stößt
Drei Einschränkungen, die ehrlich dazugehören. Die laufenden Lizenzkosten verschwinden nie, sie wiederholen sich jedes Jahr, anders als die einmalige Entwicklung einer Access-Anwendung. SharePoint-Listen sehen im ersten Moment wie ein kostenloses relationales Backend aus und sind es nicht, das rächt sich erst bei wachsenden Datenmengen. Und das Rückschreiben ins ERP bleibt ein eigenes Projekt mit eigenen Risiken, an dem die schöne Teams-Einbettung nichts ändert.
Was das für Dich bedeutet, wenn Du es nicht selbst baust
Die Entscheidung ist im Kern eine Geschäftsentscheidung, keine technische. Wenn Deine Zusatzprozesse intern bleiben und alle am selben Netz sitzen, ist die einmalig gebaute Access-Anwendung oft weiterhin das Wirtschaftlichste. Wenn Deine Leute mobil, extern oder konsequent in Teams arbeiten und die separate Anwendung deshalb nicht genutzt wird, dann ist die laufende Power-Apps-Lizenz der Preis dafür, dass die Daten überhaupt im System landen. Der spürbare Effekt ist nicht „modernere Software“, sondern: erfasst statt vergessen, am selben Tag im System statt drei Tage später per Zuruf.
Welcher Weg sich für einen konkreten Prozess rechnet, lässt sich in einer Stunde sortieren statt in sechs Monaten Workshops. Die Übersicht, wann Dein Bestand aus Access und SQL Server reicht und wann eine Ergänzung lohnt, steht auf der Seite Access mit SQL Server und Power Platform kombinieren.
Wer einen ersten Prozess durchrechnen lassen möchte, erreicht mich über das kostenlose Erstgespräch. 30 Minuten, in denen wir Deinen konkreten Fall gegen die Tabelle oben halten.
Quellen
- Microsoft Learn: Power Platform Lizenz-Übersicht und Premium-Connectoren — https://learn.microsoft.com/en-us/power-platform/admin/pricing-billing-skus
- Microsoft Licensing: Ende des Per-App-Tarifs für Neukunden, Januar 2026 — https://www.microsoft.com/en-us/licensing/news/power-app-per-app-end-of-sale
- Microsoft Learn: Canvas-App in Teams als Reiter einbetten — https://learn.microsoft.com/en-us/power-apps/teams/embed-teams-app
- Microsoft Learn: Model-driven-Apps in Teams, Abkündigung zum 1. Mai 2026 — https://learn.microsoft.com/en-us/power-apps/teams/embed-model-driven-teams-personal
- Microsoft Learn: Dataverse for Teams, Umfang und Grenzen — https://learn.microsoft.com/en-us/power-platform/admin/about-teams-environment
Über den Autor
Sönke Schäfer berät seit über 25 Jahren KMU im norddeutschen Raum bei Datenbank-Anwendungen mit Microsoft Access und SQL Server. Sein Schwerpunkt liegt darauf, gewachsene Bestände pragmatisch um Komponenten der Microsoft Power Platform zu erweitern, statt sie durch teure ERP-Wechsel zu ersetzen. Büro in Sierksdorf, Ostholstein, erreichbar für Unternehmen in Lübeck, Kiel, Hamburg und im gesamten norddeutschen Raum.
