📖 Hybride Finanzierung: Was die Lunes-App anders macht

Interview mit Daniel Kehne, Ehrenamtlicher Geschäftsführer der Tür an Tür - Digitalfabrik gGmbH

Lunes ist eine Open-Source-Anwendung mit der sich berufsbezogenes Fachvokabular erlernen lässt. Die Vokabeln sind bebildert, es gibt eine Vorlesefunktion und zahlreiche Übungen, um den Wortschatz zu verfestigen.

Euer Ziel ist es, dass die App sich selbst finanziert. Welche Aspekte müssen in einem Geschäftsplan aufgenommen werden (z. B. Personalkosten, Hosting, Material, Fahrtkosten,...) und gibt es Learnings, die ihr mit anderen teilen könnt in Bezug auf die Erstellung eines Geschäftsplans?

Es ist wichtig, sich am Anfang Gedanken zu machen, von welchem System die Lösung Teil ist und welche Akteur:innen in diesem System unterwegs sind. Alternativ bietet sich auch eine Stakeholder-Map an also – im Idealfall visualisiert – alle Akteur:innen aufzuzeichnen, die wahlweise von der Lösung profitieren, diese nutzen, ein Interesse an der Verbreitung/keiner Verbreitung haben oder sich im gleichen Themenfeld tummeln.

Die Konzept- und Fleißarbeit ist es dann, in diesem System zu überlegen, wer welches Interesse daran haben könnte, dass es eure Lösung gibt und dass eure Lösung wächst. Miteinfließen sollte auch bereits K.O-Kriterien, wie z. B. bei uns, dass keine Nutzer:innen der vulnerablen Gruppen (d. h. bei uns Schüler:innen und Azubis mit Deutsch als Zweitsprache) mit Geld oder Daten für die Nutzung zahlen sollen. Bei anderen Projekten haben wir teils noch restriktivere Vorgaben, z. B. dass kein Geld von gewinnorientierten Unternehmen und/oder Closed-Source-Partnern angenommen wird. Umso restriktiver man die Annahmen festlegt, umso schwieriger und mehr Zeit muss in die Konzeptarbeit für ein gutes Umsatzmodell gesteckt werden.

Dabei helfen kann im nächsten/gleichen Schritt auch der Business Modell Navigator der Universität St. Gallen: ein 18-seitiges PDF mit 55 Geschäftsmodellen, die sich zum Teil mehr zum Teil weniger mit den eigenen Idealen verbinden lassen. Diese lassen sich gut kombinieren, z. B. „Open Source & Robin Hood“. Meist lassen sich über die Stakeholder-Analyse und den Blick auf den Business Modell Navigator erste Ideen für ein Umsatzmodell skizzieren.

Wir sprechen bei uns auch bewusst konservativ von Umsatzmodell und nicht von Geschäftsmodell, weil unser Ziel in keinem Fall eine Gewinnmaximierung, sondern in unseren Projekten immer nur eine Kostendeckung ist. Eigene Umsatzmodelle haben den Vorteil, dass man zu einem fairen und nachhaltigen Arbeitgeber werden kann. Unbefristete Arbeitsverträge, ein sicherer Arbeitsplatz für ein Projekt und Themen, die man liebt – all das geht fast nur, wenn die Finanzierung und die dahinterliegende Struktur möglichst sicher und breit gestreut sind Wir betiteln das als hybrides Finanzierungsmodell bzw. diversifizierte Finanzierung. Unser eigener Anspruch ist es, nach den ersten 3 Jahren alle Fixkosten (dazu zählt auch Personal) des Projekts ausschließlich aus eigenen Umsätzen zu erwirtschaften. In den ersten 3 Jahren sind wir auf Fördermittel, Spenden und Programme wie den Prototype Fund angewiesen, um den Prototypen zu schaffen und Zeit zu gewinnen, um das Umsatzmodell zu entwickeln, zu testen und zu etablieren.

Das Umsatzmodell ist dabei der Schlüssel, um die Einnahmenseite des Projekts nachhaltig aufzustellen. Ohne Umsatzmodell kann ein Projekt natürlich auch existieren, ist aber abhängig von Förderungen und Spenden. Das kann zum einen dazu führen, dass man Gelder nicht so wirkungsorientiert nutzen kann, wie es das Projekt erfordern würde, andererseits sind vor allem Fördermittel immer mit viel Bürokratie verbunden, die bei einem Umsatzmodell entfallen. Im Falle eines Umsatzmodells mit privaten Kund:innen lässt sich der nötige Papierkram (Bestellung, Rechnung) oft einfach automatisieren (gerade für IT-affinere Teams), bei nicht-privaten Kund:innen sind die Summen meist so groß, dass dort in der Regel nur einige überschaubare Rechnungen geschrieben und verschickt werden müssen.

Auf der zweiten Seite eines Geschäftsplans finden sich immer die Ausgaben. Als Open- Source-Projekt, meist aus dem Home-Office heraus, sind 90% der Kosten, zumindest bei uns, Personalkosten. Hier sollte man bei Kalkulationen von angestelltem Personal nicht vergessen, dass der Arbeitgeber zusätzlich Abgaben zu zahlen hat. Wir kalkulieren das Bruttogehalt immer mit dem Faktor 1,23, um die tatsächlichen Ausgaben zu schätzen. Für einen Vollzeitentwickler mit 3.000€ brutto Monatsgehalt (=~1980€ netto), muss der Arbeitgeber also pro Jahr 44.280€ einplanen. Durch die hohe Abgabenlast (23.760€, die beim Mitarbeitenden ankommen, 44.280€, die der Arbeitgeber zahlt), macht es aus unserer Sicht Sinn auch mal Teilzeit- oder Minijob-Konstrukte ins Auge zu fassen. Bei einem Minijob (Grenze bis 30.09.2022 bei 450€; ab 01.10.2022 bei 520€) kommen nur ca. 100€ Abgaben oben drauf. Außerdem kann der:die Arbeitnehmer:in die Einnahmen mit 2% pauschalversteuern lassen, sodass 95% des Bruttogehalts als Nettogehalt ankommen. Das ist vor allem dann sinnvoll, wenn Open-Source-Projekte nebenher entwickelt werden und man in seinem Hauptjob erst einmal auf eine 4-Tage-Woche oder 32/35 Stunden verkürzt.

Die restlichen Kosten bestehen dann meist aus Server-, Hardware- und ggf. auch Reise- oder Bürokosten. Softwarelizenzkosten fallen in wenigen Open-Source-Projekten an, weil viele auch Open-Source-Tools nutzen. Mit steigenden Einnahmen würden wir immer empfehlen, einen gewissen Teil des Umsatzes (z. B. 1%) an die Open-Source-Projekte zu spenden, die bei einem selbst stark genutzt oder im Einsatz sind.

Hättet ihr ein Template für einen solchen Plan, den ihr mit anderen Open-Source-Projekten teilen könnt?

Ein direktes Template nicht, aber den Link zum St. Gallen Business Modell Navigator: https://wackwork.de/wp-content/uploads/2017/11/St-Gallen-Business-Model-Innovation-Paper.pdf

Ihr habt verschiedene Finanzierungsmodelle. Auf der Webseite wird zum Einen ein Software-as-a-Service Modell angeboten. Wie habt ihr dieses konzipiert, welche Überlegungen stecken dahinter, z. B. in Bezug auf den Angebotsumfang und die Kosten?

Wir haben zunächst Interviews mit potenziellen Kund:innen durchgeführt (also Lehrkräften), um herauszufinden, ob es bestimmte finanzielle Grenzen gibt, ab deren der „Vergabeprozess“ schwerer wird (z. B. weil die Schulleitung das absegnen muss). Wir haben dadurch herausgefunden, dass es gerade bei vierstelligen Jahresbeiträgen eigentlich immer kompliziert ist, entsprechend haben wir uns für ein Pricing entschieden, was jährlich bei 600€ landet. Einige Schulen haben auch von 700 bzw. 800€ Grenzen berichtet für zusätzliche Freigaben.

Generell können sich die Schulen – wie auch bei anderen Open-Source-Anwendungen – vom IT-Aufwand, den sie sonst im Eigenbetrieb damit hätten, „freikaufen“ und gleichzeitig das Projekt damit unterstützen. In einem Vorprojekt haben wir mal überlegt, Spendenoptionen bzw. Mitgliedschaften in einem Förderverein anzubieten, die zusätzlich zur kostenfreien Nutzung unserer Anwendung abgeschlossen werden können. Das Problem ist hier oft die interne Argumentationsproblematik. Lehrkräfte und auch kommunale Akteur:innen bekommen dafür intern oftmals nicht die Gelder, da es wie eine freiwillige und nicht notwendige Leistung wirkt und wir immer noch in einer Welt leben, in der niemand unnötig viel Geld ausgeben will. Entsprechend haben wir mit unseren SaaS-Modell einen Weg gefunden, der die Fixkosten des Open-Source-Projekts auf möglichst viele Schultern verteilt und man im Gegenzug vertraglich zugesicherte Leistungen erhält, die man zwar auch ohne Vertrag erhalten würde, sich dafür aber dann meist IT-technisch „strecken“ muss.

Zum Anderen schließt ihr Kooperationsverträge mit Kommunen und Organisationen z. B. aus der Integrationshilfe, die Kontakt zu eurer Zielgruppe haben. Diese Akteur*innen können sich bei der strategischen Entwicklung der App einbringen und beteiligen sich im Gegenzug an den Kosten. Was sind die Vorteile, die sich aus diesem Finanzierungsmodell für euch und die beteiligten Akteur*innen ergeben?

Die Kooperationsverträge beziehen sich ausschließlich auf unsere andere große Open-Source-Lösung, die App Integreat. Integreat ist eine mehrsprachige Informations-App, die von Städten und Landkreisen befüllt werden kann, um migrantische Zielgruppen in ihrer Muttersprache zu informieren. Der größte Vorteil ist – neben der gesicherten Finanzierung – sicherlich die hohe Skalierbarkeit, dadurch dass wir in jeder 5. deutschen Stadt eine hauptamtliche Person sitzen haben, die mit Integreat vertraut ist und die Lösung nutzt. So können wir uns viel um „Train the Trainer“-Modelle kümmern, indem wir Webinare anbieten wie z. B. Vermarktung oder Wirkungsmessung kommunal gut funktioniert. Meist lassen wir 1-3 Städte auch berichten bei denen wir besonders großen Erfolg in dem jeweiligen Bereich feststellen konnten. So müssen wir uns meist nur darum kümmern, den Rahmen für solche Veranstaltungen zu gestalten. Wir haben aktuell 3 ganz konkrete Beteiligungsformate, die neben Webinaren und dem persönlichen Kontakt stattfinden:

• Regionale Netzwerktreffen im Sommer, die wir physisch durchführen in jedem Bundesland mit mindestens 5 Partnerkommunen. Hier geben wir einen Einblick in die Entwicklungsplanung bis Jahresende und geben Raum für Austausch und Netzwerk bzw. landestypische Fragestellungen (oftmals Förderthemen).
• Ein bundesweites Dialogforum in digitaler Form, bei dem wir mehrere kommunale Partner den Input gestalten lassen, nachdem wir selbst ebenfalls zu Beginn einen Input in die Planungen zu den Entwicklungen des kommenden Jahres gegeben haben.
• Eine jährliche Umfrage bei allen Städten und Landkreisen, die aktuell eine Beteiligungsquote von >50% hat. Hier können Städte und Landkreise u. a. geplante Entwicklungen priorisieren und so selbst mitbestimmen auf welche Features unser Team den Fokus legt.

Das Einbinden    der Städte und Landkreise in unser Integreat-Ökosystem hat außerdem den großen Vorteil, dass wir uns nahezu gar nicht um Marketing und Akquise kümmern müssen. Wir geben den Städten und Landkreisen Vorlagen für Pressemitteilungen, aber auch für digitales und analoges Marketingmaterial an die Hand. In 70% unserer Städte wurden Pressemitteilungen in den Lokalzeitungen veröffentlicht, die oftmals dazu führen, dass Nachbarlandkreise oder -Städte von Integreat erfahren und sich bei uns melden. So übernehmen die Partnerkommunen indirekt die Vertriebsarbeit von Integreat.

Was gibt es bei der Erstellung eines solchen Kooperationsvertrags zu beachten? Habt ihr ein Template, das ihr mit anderen teilen möchtet?

In unseren Augen gibt es vor der Überlegung zum passenden Vertrag noch eine Mindset-Frage zu klären: Seht ihr euch als IT-Dienstleister oder nicht? Sobald ihr euch als IT-Dienstleister definiert, werden euch eure (kommunalen) Kunden früher oder später auch mit den sogenannten EVB-IT-Verträgen um die Ecke kommen in denen ihr Reaktions- und Ausfallzeiten sowie Service-Level ebenso wie viele weitere formale Punkte ausformulieren müsst. Wir halten das für Open-Source-Projekte wie unsere nicht für sinnvoll, weil viele der dortigen Punkte nur mit einer großen Professionalisierung wirklich wahrheitsgemäß und mit gutem Gewissen real eingeschätzt werden können. Entsprechend sehen wir uns von vornherein als Kooperationspartner und bieten Kooperationsverträge an. In den ersten Jahren haben wir uns auch um das Wort „Vertrag“ gedrückt und von „Servicevereinbarungen“ gesprochen. Da auch das am Ende des Tages formal ein Vertrag ist, haben wir das Wording irgendwann mal übernommen und in dem Zuge auch „Service“ durch „Kooperation“ ersetzt.

Ein Kooperationsvertrag sollte aus unserer Sicht zur so lang wie nötig sein. Es sollten Rechte- und Pflichten der beiden Kooperationspartner enthalten sein, sowie Kosten und Laufzeit, Kündigungsfristen und Haftungsbestimmungen. Wir haben oft noch eine Präambel vorgeschaltet, um nicht-vertragliche Absichtserklärungen einzubringen. Ein Beispielvertrag haben wir angehängt. [Download über linke Seitenspalte]

In eurem Wiki veröffentlicht ihr zudem viele Informationen zum administrativen Überbau der App (eine GmbH). Habt ihr hierzu Erfahrungen und Best-Practice-Beispiele, was es bei der (Finanz-)Verwaltung einer Open-Source-Anwendung zu beachten gibt?

Es schadet nie, jemanden im Team zu haben, der sich generell etwas mit Buchhaltung und den einzelnen Rechten und Pflichten verschiedener Rechtsformen auskennt. Ansonsten hilft hier auch immer ein Steuerbüro. Die Kosten sind meist nicht so utopisch hoch wie man zunächst annimmt. Die Verwaltung einer GmbH oder UG über ein Steuerbüro beispielsweise kostet zwischen 1000-2000€ pro Jahr. Hier kann die lokale IHK oder Gründungsberatung oftmals auch helfen. Eine Rechtsform zu gründen, ist dann notwendig, wenn ich genau diese vertraglichen Konstrukte wie oben eingehen möchte. Natürlich kann man auch zunächst mit einer GbR starten, wie das viele im Prototype Fund gemacht haben und diese beibehalten bis sich wiederkehrende Zahlungsflüsse eingestellt haben und die oben skizzierten Verwaltungskosten nur noch <5% des Gesamtumsatzes ausmachen würden. Eine UG zu gründen und dann später in einen GmbH umzuwandeln braucht i. d. R. kein Stammkapital und ist aus unserer Sicht sinnvoller als der Start mit einer GbR, wenn man sich schon sicher ist, dass man das ein paar Jahre nebenher macht.

Ansonsten können wir nur empfehlen, sich möglichst früh möglichst viel aufzuschreiben und zu dokumentieren – auch und vor allem die nicht-technischen Prozesse.