<\/p>\n
Wir entwickeln Power BI-Writeback-L\u00f6sungen auf Basis von Microsoft Fabric unter Verwendung von Translytical Task Flows \u2013 so kann Ihr Team Pl\u00e4ne bearbeiten, Aufgaben neu planen und Datens\u00e4tze direkt in dem Bericht genehmigen, den es gerade betrachtet. Diese L\u00f6sungen sind nativ in Power BI integriert, werden von Fabric verwaltet und sind darauf ausgelegt, im Produktivbetrieb kontinuierlich zu laufen \u2013 nicht nur in einer Demo.<\/p>\n
Kostenvoranschlag anfordern<\/a><\/p>\n <\/p>\n Power BI ist darauf ausgelegt, Daten zu lesen, nicht zu schreiben. Sobald jemand eine Prognose aktualisieren, eine Aufgabe neu planen oder einen Datensatz genehmigen muss, verl\u00e4sst er den Bericht \u2013 und der Bericht ist nicht mehr die einzige verl\u00e4ssliche Informationsquelle. Translytical Task Flows auf Microsoft Fabric schlie\u00dfen diese L\u00fccke nativ. Die Frage ist, ob die Writeback-Logik gut genug umgesetzt ist, um ihr in der Produktion vertrauen zu k\u00f6nnen.<\/p>\n Eine Zahl wird in einer Tabellenkalkulation aktualisiert, doch im Bericht wird weiterhin der Wert des letzten Monats angezeigt. Jemand muss daran denken, die Daten erneut zu importieren, und solange dies nicht geschieht, basieren alle Entscheidungen, die anhand des Dashboards getroffen werden, auf veralteten Daten.<\/p>\n Eine Aufgabe verschiebt sich um zwei Tage, eine Ressource wird doppelt gebucht, und niemand bemerkt es, bis es eine Woche sp\u00e4ter als Konflikt auftaucht. Der Bericht, der dies eigentlich h\u00e4tte aufdecken sollen, kann lediglich den Plan anzeigen \u2013 er erm\u00f6glicht es niemandem, ihn anzupassen und die Folgewirkungen in Echtzeit zu sehen.<\/p>\n Jemand genehmigt eine Haushaltslinie, indem er auf eine E-Mail antwortet. Im Bericht wird dies jedoch nie erfasst. Wenn der Pr\u00fcfer fragt, wer was wann genehmigt hat, ist die Antwort nicht im System zu finden \u2013 sie befindet sich im Posteingang einer bestimmten Person.<\/p>\n <\/p>\n Wir sind auf Power BI-Writeback auf Microsoft Fabric spezialisiert \u2013 insbesondere auf Translytical Task Flows und Fabric User Data Functions. Das bedeutet, dass der Schreibpfad nativ in die Plattform integriert ist, auf der Ihr Bericht bereits ausgef\u00fchrt wird, und es sich nicht um ein zus\u00e4tzliches Tool mit einem eigenen, separat zu verwaltenden Datenspeicher handelt. Von einem einzelnen bearbeitbaren Feld bis hin zu einer vollst\u00e4ndig interaktiven Visualisierung f\u00fcr die Terminplanung erstellen wir den gesamten Ablauf von Anfang bis Ende: den Ausl\u00f6ser, die Validierungslogik, den Schreibvorgang und die Aktualisierung des Berichts.<\/p>\n Der native Microsoft-Pfad f\u00fcr das Writeback: Ein Steuerelement in Ihrem Bericht l\u00f6st eine Fabric-Benutzerdatenfunktion aus, die die Eingabe validiert und Daten in die Fabric SQL-Datenbank, ein Fabric-Warehouse oder ein Fabric-Lakehouse schreibt. Es muss keine separate Middleware gehostet und kein separates Identit\u00e4tssystem verwaltet werden \u2013 die Funktion l\u00e4uft auf dem Fabric-Mandanten, \u00fcber den Sie bereits verf\u00fcgen. Zu den typischen Abl\u00e4ufen geh\u00f6ren:<\/p>\n Manche Anwendungsf\u00e4lle erfordern mehr als nur eine Schaltfl\u00e4che und ein Textfeld \u2013 sie erfordern eine direkte Bearbeitung. Wir entwickeln ma\u00dfgeschneiderte Power BI-Visualisierungen mit Drag-and-Drop-Funktionalit\u00e4t, die bei jeder \u00c4nderung Fabric-Benutzerdatenfunktionen aufrufen und den Benutzern so Echtzeit-Feedback geben, noch bevor Daten geschrieben werden. Zu den typischen Anwendungen geh\u00f6ren:<\/p>\n Jeder Schreibvorgang durchl\u00e4uft eine serverseitige Validierung innerhalb der Fabric User Data Function \u2013 es handelt sich nicht nur um eine \u00dcberpr\u00fcfung in der Benutzeroberfl\u00e4che, die umgangen werden kann. Die Sicherheit auf Zeilenebene wird gewahrt, jede \u00c4nderung wird mit einem Zeitstempel versehen, und abgelehnte Schreibvorg\u00e4nge geben einen eindeutigen Grund an, anstatt stillschweigend fehlzuschlagen. Zu den g\u00e4ngigen Mustern geh\u00f6ren:<\/p>\n <\/p>\n Bevor wir mit dem Programmieren beginnen, kl\u00e4ren wir ab, welche Funktionen Ihr Fabric-Tenant bereits unterst\u00fctzt, wo die Zieldaten gespeichert werden sollen (Fabric SQL Database, Warehouse oder Lakehouse) und welche Validierungsregeln ber\u00fccksichtigt werden m\u00fcssen. Dies wird vor Beginn der Entwicklung dokumentiert und mit Ihnen abgestimmt. Ein Writeback-Prozess, der auf unklaren Regeln basiert, f\u00fchrt zu unzuverl\u00e4ssigen Daten.<\/p>\n Wir erstellen die Benutzerdatenfunktion, den Trigger auf der Berichtseite und \u2013 falls erforderlich \u2013 das benutzerdefinierte Diagramm und testen diese anschlie\u00dfend anhand realistischer Daten in Ihrer Fabric-Umgebung. Wir testen den Happy Path und die Randf\u00e4lle: gleichzeitige Bearbeitungen desselben Datensatzes, einen Schreibvorgang, der die Validierung nicht besteht, sowie einen Netzwerkausfall w\u00e4hrend des Speichervorgangs. Die meisten Fehler beim Writeback in der Produktion sind genau auf diese Szenarien zur\u00fcckzuf\u00fchren.<\/p>\n Sie testen den Ablauf anhand realer Szenarien aus Ihrem t\u00e4glichen Berichtswesen. Wir beheben etwaige Probleme, dokumentieren bekannte Einschr\u00e4nkungen und stellen sicher, dass die Validierung und das Aktualisierungsverhalten wie vereinbart funktionieren, bevor wir das Projekt abnehmen.<\/p>\n Umfassende \u00dcbergabe einschlie\u00dflich einer schriftlichen Beschreibung der Eingaben, der Validierungslogik und des Schreibziels jeder Funktion \u2013 so verst\u00e4ndlich, dass Ihr Team diese ohne unsere Hilfe verstehen und warten kann. Beinhaltet 3 Monate Fehlerbehebung. Laufender Support ist im Rahmen eines Rahmenvertrags verf\u00fcgbar.<\/p>\n <\/p>\n Ein Planer zieht eine Aufgabe in einer Gantt-Ansicht auf ein neues Datum. W\u00e4hrend des Ziehens werden sich \u00fcberschneidende Buchungen f\u00fcr dieselbe Ressource sofort hervorgehoben. Beim Ablegen \u00fcberpr\u00fcft eine Fabric-Benutzerdatenfunktion den neuen Zeitplan anhand aller anderen Buchungen f\u00fcr diese Ressource und schreibt die \u00c4nderung in die Fabric-SQL-Datenbank. Liegt ein echter Konflikt vor, wird der Schreibvorgang mit einer eindeutigen Begr\u00fcndung abgelehnt, anstatt den Plan stillschweigend zu verf\u00e4lschen.<\/p>\n Ein Finanzverantwortlicher passt einen Prognosewert direkt in einer Power BI-Matrix an. Die \u00c4nderung wird anhand des genehmigten Budgetrahmens \u00fcberpr\u00fcft und in das zugrunde liegende Fabric Warehouse geschrieben. Alle anderen Betrachter des Berichts sehen den aktualisierten Wert bei der n\u00e4chsten Aktualisierung \u2013 ohne Export, ohne erneuten Import und ohne separates Planungstool.<\/p>\n In einem Bericht erscheint eine Anfrage mit den Schaltfl\u00e4chen \u201eGenehmigen\u201c und \u201eAblehnen\u201c. Durch die Genehmigung wird eine Fabric-Benutzerdatenfunktion ausgel\u00f6st, die die Entscheidung, den Genehmiger und einen Zeitstempel in den Datensatz zur\u00fcckschreibt und den Status aktualisiert, der f\u00fcr alle nachgelagerten Benutzer sichtbar ist. Der vollst\u00e4ndige Entscheidungsverlauf wird in derselben Tabelle gespeichert, aus der der Bericht seine Daten bezieht.<\/p>\n Ein Benutzer entdeckt bei der \u00dcberpr\u00fcfung eines Berichts einen falschen Wert und korrigiert diesen sofort, anstatt ein Ticket zu erstellen und darauf zu warten, dass jemand anderes das Problem an der Quelle behebt. Die Korrektur wird validiert und direkt in die von Fabric unterst\u00fctzte Quelltabelle geschrieben.<\/p>\n Ein Pr\u00fcfer f\u00fcgt einem bestimmten Datenpunkt eine Notiz hinzu \u2013 beispielsweise eine Erkl\u00e4rung f\u00fcr eine Abweichung oder einen Hinweis f\u00fcr weitere Ma\u00dfnahmen. Der Kommentar wird mit dem Namen des Benutzers und dem Zeitstempel gespeichert und wird der n\u00e4chsten Person angezeigt, die denselben Bericht \u00f6ffnet.<\/p>\n <\/p>\n Wir arbeiten auf Zeit- und Materialbasis. Sie zahlen f\u00fcr die tats\u00e4chlich geleisteten Tage zu einem festen Tagessatz. Keine Festpreis\u00fcberraschungen, keine Ausweitung des Umfangs ohne Ihre Zustimmung.<\/p>\nIhre Berichte zeigen das Problem auf. Sie erm\u00f6glichen es aber niemandem, es zu beheben.<\/h2>\n
Pl\u00e4ne und Prognosen, die zum Zeitpunkt des letzten Exports eingefroren wurden<\/h3>\n
\u00c4nderungen am Zeitplan erfolgen au\u00dferhalb des Zeitplans<\/h3>\n
Freigaben und Korrekturen werden per E-Mail \u00fcbermittelt, nicht im Datensatz vermerkt<\/h3>\n
Writeback \u2013 das entwickeln wir f\u00fcr unsere Kunden.<\/h2>\n
Translytical-Aufgabenabl\u00e4ufe und Funktionen zur Verarbeitung von Fabric-Benutzerdaten<\/h3>\n
\n
Benutzerdefinierte Visualisierungen f\u00fcr das Zur\u00fcckschreiben<\/h3>\n
\n
Validierung und Governance<\/h3>\n
\n
Wie es funktioniert.<\/h2>\n
1. Architektur und Betriebsbereitschaft der Infrastruktur<\/h3>\n
2. Bauen & Testen<\/h3>\n
3. UAT & Freigabe<\/h3>\n
4. \u00dcbergabe & Dokumentation<\/h3>\n
Was unsere Kunden uns schreiben.<\/h2>\n
Interaktive Aufgaben- und Ressourcenplanung<\/h3>\n
Bearbeitung von Budgets und Prognosen<\/h3>\n
Genehmigungs-Workflows<\/h3>\n
Datenkorrektur an der Quelle<\/h3>\n
Kommentare und Anmerkungen<\/h3>\n
Transparente Preisgestaltung.<\/h2>\n