Häufig gestellte Fragen

Das erste Treffen ist ein offenes Gespräch. Wir stellen Fragen zum Geschäftskontext, zu aktuellen Problemen und zum erwarteten Ergebnis, Sie erzählen von Ihrer Vision. Am Ende haben beide Seiten ein Verständnis dafür, wie die Aufgabe angegangen werden sollte.

Wir können einen Tech-Stack oder eine Architektur empfehlen, eine Orientierung zu Budget und Zeitrahmen geben und Umsetzungsvarianten vorschlagen. Wenn Ihre Anfrage außerhalb unseres Kompetenzbereichs liegt, sagen wir das immer offen.

Ein Lakehouse verbindet die Prinzipien von Data Lake und Data Warehouse: Es erlaubt die Arbeit mit großen Mengen unterschiedlichster Daten und unterstützt zugleich strukturierte Analytik. Eine universell bessere Variante gibt es allerdings nicht: Die Wahl zwischen Data Lake, Data Warehouse und Data Lakehouse hängt von den Datentypen, den Analyseaufgaben und den Anforderungen an die Architektur ab.

Ja, wir unterzeichnen ein NDA in jeder Phase. Wir gehen respektvoll mit den Informationen unserer Kunden um und schätzen unseren eigenen Ruf. Wir haben eine eigene NDA-Vorlage, aber wenn der Kunde eine andere hat, stimmen wir sie ohne unnötige Komplikationen ab.

In einer vereinfachten Architektur lassen sich vier Hauptblöcke unterscheiden: Datenquellen und Integrationen, Speicher, die Analytik- und BI-Schicht sowie Governance – Regeln für Zugriff, Qualität und Datenverwaltung. In komplexeren Plattformen können auch Datenverarbeitung, Katalogisierung, Monitoring und Sicherheitswerkzeuge eigene Komponenten sein.

Der Support nach dem Release ist ein eigener Arbeitsbereich. Bei Bedarf unterzeichnen wir ein SLA und übernehmen die Verantwortung für Uptime, Fehlerbehebung und Updates. Das Format hängt vom Projekt ab: Mal ist eine Reaktion innerhalb einer Stunde nötig, mal reicht eine wöchentliche Durchsicht der Logs. Auch die Dauer ist flexibel: von einigen Monaten bis zur langfristigen Betreuung.

Schrittweise: zuerst ein Audit der bestehenden Systeme, um zu verstehen, welche Datenquellen kritisch sind. Danach – die Wahl der Architektur passend zur Größe des Unternehmens. Anschließend der Aufbau der ETL/ELT-Pipelines, die die Daten übertragen und transformieren. Und erst am Ende – die Anbindung der BI-Schicht für Dashboards und Berichte. Wird das Audit übersprungen oder gleich mit BI begonnen, steigt das Risiko, dass die Plattform auf widersprüchlichen Daten aufgebaut wird und schon nach dem Start überarbeitet werden muss.

Dem Auftraggeber, in vollem Umfang. Code, Dokumentation und Infrastruktur gehen nach Zahlung und Unterzeichnung der Dokumente an den Kunden über. Wenn im Projekt Drittanbieter-Bibliotheken oder Tools mit eigenen Lizenzbedingungen verwendet werden, wird das zu Beginn besprochen.

RLS beschränkt den Zugriff auf einzelne Zeilen des Datenmodells je nach Rolle des Nutzers. Deshalb kann ein und derselbe Bericht verschiedenen Personen unterschiedliche Daten anzeigen.

Ja, natürlich. Bevor wir ein solches Projekt übernehmen, führen wir ein Audit durch: Wir prüfen Code, Architektur, Zustand der Infrastruktur, Dokumentation und Zugänge. Danach geben wir eine ehrliche Einschätzung, was weiterentwickelt werden kann und was günstiger neu zu schreiben wäre. Wenn die Lösung tragfähig ist, übernehmen wir den Support, beheben die kritischen Stellen und bewegen uns schrittweise vorwärts.

Erstellen Sie eine RLS-Rolle, definieren Sie die Filterregel, testen Sie sie, veröffentlichen Sie das Modell und weisen Sie der Rolle im Power BI Service Nutzer oder Gruppen zu. Prüfen Sie zusätzlich ihre Rechte im Arbeitsbereich und den Zugriff auf den Bericht.

Sicherheit wird vom ersten Tag an in die Architektur eingebaut. Zugriffsmodelle, Rollenkontrolle, Verschlüsselung und Aktionsprotokollierung sind Grundelemente, die selbst in relativ einfachen Projekten vorhanden sind.

In internen Systemen beschränken wir Zugriffe und implementieren mehrstufige Autorisierung. Im BI-Bereich isolieren wir Umgebungen und kontrollieren Berechtigungen bis auf die Ebene einzelner Dashboards. Im E-Commerce — API-Schutz, Zahlungsverschlüsselung, Traffic-Audit. Wir haben mit Banken, Behörden und Kanzleien gearbeitet, wo die Sicherheitsanforderungen besonders streng sind.

Bei statischem RLS ist die Filterregel fest an eine Rolle gebunden. Bei dynamischem RLS kann sie sich je nach Nutzer ändern, zum Beispiel über USERPRINCIPALNAME() und eine Zuordnungstabelle.

Dafür wird RLS Power BI verwendet: die Regeln des Modells legen fest, welche Daten der Nutzer nach der Anmeldung sieht.

Verwenden Sie in Power BI Desktop View as, um den Bericht im Namen einer Rolle zu prüfen. Nach der Veröffentlichung kann die Rolle auch im Power BI Service getestet werden.

Typische Fehler: ein Fehler im DAX-Filter, falsch zugewiesene Rollen im Arbeitsbereich, eine veraltete Zuordnungstabelle und der Versuch, RLS durch gewöhnliche Filter im Bericht zu ersetzen.

Individuelle Entwicklung ist dort sinnvoll, wo es eine einzigartige Logik, spezifische Integrationen oder Anforderungen gibt, die kein fertiges Produkt ohne erhebliche Kompromisse abdecken kann.

Wenn die Aufgabe mit einem vorhandenen Tool gelöst werden kann, das 80% der Anforderungen abdeckt — sagen wir das gleich zu Beginn. Aber wenn das Unternehmen Standardlösungen bereits entwachsen ist oder etwas Außergewöhnliches aufbaut, bietet individuelle Entwicklung volle Kontrolle: Logik, Rollen, Integrationen, Berichte — alles nach Ihren konkreten Anforderungen.

Eine fertige Plattform ist ein schneller Start innerhalb dessen, was sie vorsieht. Solange das Unternehmen in diese Grenzen passt, funktioniert alles. Aber sobald nicht standardmäßige Prozesse, spezifische Logik oder der Bedarf an tiefen Integrationen auftauchen, beginnen Umwege, Plugins und ständige Einschränkungen.

Eine individuelle Lösung wird für Sie gebaut: Sie skaliert mit dem Unternehmen, lässt sich mit beliebigen Services integrieren und ist nicht von den Entscheidungen einer Drittplattform über API- oder Richtlinienänderungen abhängig.

Meist sind das entweder Werkzeuge für die interne Arbeit eines Unternehmens oder Produkte, mit denen Kunden oder Partner interagieren. Zur ersten Gruppe gehören Managementsysteme, Buchhaltungsplattformen und Integrationslösungen zwischen bestehenden Services. Zur zweiten — Web- und Mobile-Apps, Partnerportale, E-Commerce. Oft ist das eine mit dem anderen verflochten: zum Beispiel eine Plattform für Distributoren, die intern mit ERP und Analytik verbunden ist. Der konkrete Umfang hängt immer davon ab, welcher Prozess gelöst werden muss.

Von Komplexität und Umfang. Manchmal lässt sich ein MVP in einem Monat zusammenstellen, ein vollwertiges System in einigen Monaten. Wenn eine tiefe Integration oder die Entwicklung komplexer Analytik von Grund auf erforderlich ist, sind die Fristen länger. Die Entwicklung wird immer in Phasen aufgeteilt, und die ersten Ergebnisse erscheinen, bevor das Projekt vollständig abgeschlossen ist.

Wir beginnen mit der Discovery-Phase. Hier klären wir gemeinsam die eigentliche Aufgabe, die Einschränkungen und die Erfolgskriterien. Das ist der Punkt, an dem wir prüfen, ob die Aufgabe richtig formuliert ist, bevor wir mit ihrer Lösung beginnen.

Danach verläuft die Entwicklung in Iterationen mit einem konkreten Ergebnis in jeder Phase. Sie sehen Berichte, geben Feedback, und die nächste Etappe berücksichtigt Ihre Anmerkungen. So entsteht die Lösung Schritt für Schritt, und Sie haben die Möglichkeit, sie im Prozess zu beeinflussen.