Mein Weg zum ISV (Independent Software Vendor) – Teil 1

Unser Mitglied Roland Haibl hat einen Erfahrungsbericht geschrieben, in dem er seinen Weg zum ISV (Independent Software Vendor) beschreibt. Damit will er zeigen, wie es beinahe jedem Entwickler möglich ist, seine selbst entwickelte Software zu verkaufen. Da der Bericht recht lang geraten ist, haben wir uns entschlossen, ihn in zwei Teilen zu veröffentlichen. Hier der erste Teil mit der Einleitung zum Thema und ein paar notwendigen Voraussetzungen.

Ein kurzer Ausflug in meine „Vorgeschichte“

Bevor ich mich selbständig machte, war ich viele Jahre als Software-Entwickler in einem großen, weltweit agierenden Unternehmen tätig. Seit 2010 bin ich nun als freiberuflicher IT Consultant auf dem Markt und kann dabei die Software, an der ich zuvor maßgeblich mitentwickelt habe, im Kundenumfeld einsetzen und deren Nutzung optimal gestalten.

Es ist eine tolle Erfahrung, ein Produkt, das man selbst mitentwickelt hat, im Praxiseinsatz zu sehen und dessen Nutzung voranzutreiben. Die tiefen Kenntnisse der internen Abläufe in der Software helfen dabei natürlich sehr.

Ich empfinde meine jetzigen Aufgaben im Bereich IT-Consulting als sehr befriedigend und ich möchte diese Arbeit keinesfalls missen, dennoch bin ich im Herzen immer ein Software-Entwickler geblieben.

Wie entsteht neue Software?

Ein neues Produkt entsteht nicht einfach dadurch, dass man sich ein Szenario vorstellt und dann beginnt dafür Programmcodes zu entwickeln. Am Anfang neuer Software stehen ein oder mehrere Probleme und das Bedürfnis des Kunden diese so effizient wie möglich zu lösen.

So ist auch meine Software entstanden. Eigentlich hatte ich gar nicht das Ziel, ein neues Produkt auf den Markt zu bringen, sondern ich wollte einfach nur meine Aufgaben zielgerichtet bewältigen und dabei eine hohe Qualität abliefern.

Ich war beim Kunden in ein sehr umfangreiches Projekt eingebunden, bei dem es darum ging, die Automation im Großrechnerumfeld komplett neu aufzubauen. Im Rahmen dieses Projektes gab es viele verschiedene und teils sehr komplexe Aufgaben.

Um mir die Arbeit zu erleichtern begann ich damit, mir in der Freizeit Hilfsmittel zu schaffen. Diese setzte ich dann beim Kunden für meine tägliche Arbeit ein. Diese Hilfsmittel gestatteten es mir, sehr effizient zu arbeiten, und es wurden auch Mitarbeiter des Kunden darauf aufmerksam.

Schon bald begannen auch diese Mitarbeiter die ersten Ansätze meiner ‚Tools‘ zu nutzen, wodurch immer neue Ideen für Erweiterungen entstanden und schrittweise durch mich implementiert wurden. Dadurch entstand eine immer größere Ansammlung an Funktionen, welche laufend verbessert und verfeinert wurden. – Die Funktionen verfestigten sich und ‚reiften‘ im Laufe der Zeit.

Möglichst viel vereinfachen

Meine Strategie war und ist es, die bestehenden Standard Software Produkte und deren Komponenten maximal auszunutzen und zum Einsatz zu bringen. So war ich nie darauf aus in irgendeiner Form eine Konkurrenz zu einem bestehenden Produkt darzustellen. Ich habe mich ausschließlich darauf konzentriert fehlende Funktionen zur Verfügung zu stellen und dabei die im Kundenumfeld bestehenden Produkte zu ergänzen. In vielen Fällen habe ich deren Funktionen auch mit in meine Software eingebunden, und somit deren Nutzung effizienter gestaltet, als das bisher möglich war.

Einen sehr hohen Stellenwert nahm auch die Vereinfachung komplexer Abläufe ein. Sich wiederholende Tätigkeiten wurden standardisiert und manuelle Eingriffe minimiert. Auf diese Weise konnte ich viele Fehlerquellen ausschließen und umfangreiche Arbeiten in kürzester Zeit mit höchster Zuverlässigkeit erledigen.

Gerade bei der Vereinfachung komplexer Abläufe begannen sich meine erstellten Hilfsmittel zu ergänzen und ineinanderzugreifen.
Es war dann schlussendlich ein logischer nächster Schritt, die Ansammlung der Hilfsmittel mit einer intuitiven Benutzeroberfläche zu versehen und die benötigte Dokumentation dazu zu erstellen.

Dadurch wurden diese ‚Tools‘ aber noch lange nicht zu einem eigenen Produkt!

Voraussetzungen

Programmier-Disziplin

Jeder Programmierer hat seine eigene ‚Handschrift‘ und seinen eigenen Stil. – Das ist auch gut so!

Es ist immer möglich, dass Fehler auftreten, sei es durch tatsächliche Programmfehler oder durch unvorhergesehene Konstellationen im Einsatz und in der Anwendung der Software.

Wenn man Software im produktiven Umfeld einsetzen möchte, so muss man gewisse Regeln einhalten und dabei auch eine konsequente Disziplin wahren. Damit können die Auswirkungen eventueller Fehler so gering wie möglich gehalten werden.

So müssen beispielsweise alle eventuell auftretenden Fehler abgefangen und dabei möglichst viele Informationen für die Behebung des Fehlers eingesammelt werden. Diese Disziplin wird auch häufig mit „First Failure Data Capture“ bezeichnet.

Es ist sehr unangenehm für den Kunden, wie auch für den Software-Entwickler, wenn zur Fehleranalyse das Problem reproduziert werden muss.

In keinem Fall dürfen bei einem Fehler Daten verloren gehen und/oder verändert werden!

Trennung von Programmcode und Daten

Durch meine jahrelange Tätigkeit in der Software-Entwicklung ist es für mich selbstverständlich, dass die Daten strikt getrennt vom Programmcode gehalten werden. Dies ist eine absolut unablässige Basis, um eine Software in verschiedenen Umgebungen einsetzen zu können.

Dies ist nicht nur notwendig um die Software bei verschiedenen Kunden anzubieten, sondern auch um die gleichen Komponenten für verschiedene Abteilungen und Anforderungen innerhalb einer Kundenumgebung zu nutzen.

Wenn Code und Daten nicht streng voneinander getrennt gehalten sind, dann muss man die Nutzung in unterschiedlichen Umgebungen von Grund auf verwerfen!

Die eigentlichen Schwierigkeiten

Akzeptanz

Als Freiberufler ist man in der Regel ein ‚Einzelkämpfer‘.

Um bei größeren Kunden überhaupt einen Auftrag zu bekommen muss man dort als Lieferant gelistet sein. Im IT-Bereich kann man Lieferant für Dienstleistungen, Hard- und Software sein.

Diese Voraussetzung erfüllen nur äußerst wenige Freiberufler!

Ohne einen zuverlässigen Partner geht also nichts!

Ich hatte das Glück, mit der Empalis Consulting GmbH einen Partner zu haben, mit dem ich schon seit vielen Jahren zusammenarbeite und der bei vielen Großkunden als Lieferant gelistet ist und entsprechende Referenzen aufweisen kann.

Organisation

Nicht nur für die Möglichkeit, ein Produkt überhaupt anbieten zu können benötigt man einen Partner. Es müssen Abkommen und Verträge ausgearbeitet werden, ggf. Werbung für das Produkt gemacht und der Vertrieb gestaltet werden.

Einen sehr komplexen Teil nimmt die Gestaltung von Kauf-, und in der Folge, von Wartungsverträgen ein. Hierfür ist auch juristische Unterstützung notwendig. Auch hier wurde ich durch die Empalis Consulting GmbH intensiv unterstützt.

Bei der Gestaltung von Wartungsverträgen müssen die möglichen Fehlerszenarien klassifiziert und für jede Klasse die Reaktions- und Fehlerbehebungszeiten festgelegt werden.
Neben den Verträgen mit den eigentlichen Kunden, also den Nutzern der neuen Software, mussten auch Verträge zwischen mir (dem Entwickler) und dem Anbieter (Empalis Consulting GmbH) etabliert werden.

Technisches Umfeld

Sobald die vertragliche Basis geschaffen ist, muss natürlich auch der technische Support gestaltet werden.

Die Systeme, auf denen ich die Software entwickelt und getestet hatte, waren bereits eine gute Basis für die Wartungsarbeiten. Natürlich mussten noch die Prozesse zur Versionierung und das Release-Management aufgebaut werden.

Je länger das Produkt auf dem Markt ist, desto größer wird die Wahrscheinlichkeit, verschiedene Versionen der Software warten zu müssen. Auch hierfür müssen Vorkehrungen getroffen werden.

Es versteht sich natürlich von selbst, dass die Entwicklungs- und Testsysteme immer auf einem aktuellen Wartungsstand gehalten werden. Anders kann man gegenüber den Kunden nicht glaubwürdig auftreten und sicherstellen, dass die neue Software auch in einem geänderten Umfeld optimal arbeitet.

Der Zugriff auf diese Systeme muss streng kontrolliert und überwacht werden. Einerseits muss der Zugriff auf die entwickelte Software geschützt werden und andererseits könnten sich zu Test- und Fehlerkorrekturzwecken auch Daten von Kunden auf den Systemen befinden.

Personelles Umfeld

Eine Software zu entwickeln ist eine Sache, die Wartung dafür zu gewährleisten eine andere!

Selbstverständlich stehe ich für das von mir entwickelte „Baby“ gerade, aber auch ich gehe gerne mal in Urlaub. Hier stößt man als ‚Einzelkämpfer‘ definitiv an seine Grenzen! Man braucht also technische Partner, die den notwendigen Skill aufweisen und gewillt sind, sich in den Dienst der Software zu stellen.

Ein gutes Netzwerk ist hierfür die absolute Voraussetzung. Die Empalis Consulting GmbH konnte in diesem Bereich wiederum unterstützen, aber auch meine persönlichen Kontakte wurden voll ausgeschöpft.

Es ist unumgänglich, das Netzwerk und somit die Kontakte laufend zu erweitern. Nur so kann sichergestellt werden, dass immer genügend Skill vorhanden ist und auch aufgebaut werden kann, um das langfristige Weiterbestehen der Software zu garantieren.

An dieser Stelle bekommt der DBITS eine wichtige Rolle. Im DBITS finden sich viele selbständige IT Fachleute mit unterschiedlichstem Wissen und Erfahrungen. Eine gewaltige Quelle an leistungsfähigen Top-Leuten.

Mit diesem Hintergrund kann man ein breites Spektrum an Skill abdecken, ohne Heerscharen von Angestellten haben zu müssen, mit denen man nicht mehr in der Lage wäre, eine Software zu einem akzeptablen Preis anzubieten.

Weiter geht es mit dem zweiten und abschließenden Teil: https://www.dbits.it/mein-weg-zum-isv-independent-software-vendor-teil-2/

---