7 Schritte zur Auswahl von Softwareunternehmen
Um was geht es heute? Heute haben wir ein spannendes Thema, und zwar geht es heute darum, wie du in 7 Schritten ein passendes Softwareunternehmen findest, das dir dein individuelles Produkt baut.
Also auf die Modewelt bezogen wäre das die Frage: Wer ist der beste Schneider, um einen Maßanzug zu erstellen? Und nicht: Soll ich jetzt Boss oder Tommy Hilfiger oder Brioni von der Strange nehmen? Obwohl ich weiß gar nicht, ob es Brioni von der Stange gibt, aber das ist eine andere Frage. Das wäre in dieser Analogie eine Softwareevaluation und nicht die Auswahl eines Lieferanten für Individualsoftware.
Und dabei ist es jetzt total egal, ob es sich um ein Softwareunternehmen in Darmstadt oder um ein Nearshorepartner aus Ungarn, Polen oder Rumänien handelt. Das grundsätzliche Vorgehen ist komplett gleich.
Ja, manche Detailfragen unterscheiden sich, aber die 7 Schritte zur Auswahl, die ich gleich vorstelle, sind grundsätzlich identisch.
Warum ist das überhaupt wichtig?
Naja, wir wollen ja einen Lieferanten, der gute Preise hat, der deine App oder Plattform auch erfolgreich bauen kann und später auch warten kann und mit dem du am besten längerfristig partnerschaftlich und vertrauensvoll zusammenarbeiten kannst. Und wie man so einen Lieferanten findet, das stelle ich dir jetzt mal in 7 Schritten kurz vor.
Schritt #1 ist das Product Vision Board.
Bevor man einen Lieferanten sucht, muss man sich erst mal selbst im Klaren darüber sein: Was soll überhaupt gebaut werden? Und das muss man dem Lieferanten ja später auch vermitteln können, deswegen ist meine Empfehlung dazu: Erstelle ein sogenanntes Product Vision Board.
Dadurch wird später abgeleitet, welche fachlichen und welche technischen Skills der Lieferant in seinem Team benötigt. Was beinhaltet dieses Product Vision Board? Das sind 4 Kategorien:
- Zielgruppe
- Bedürfnisse der Zielgruppe
- das Produkt, um diese Bedürfnisse zu befriedigen.
Und dort würde ich noch was hinzufügen, und zwar so ein Mini-Backlog mit 5, 6, 7 Epics, um das MVP zu entwickeln, also das kleinste, fertige Produkt vor Kunde. Und als 4. den
- Nutzen für euer Unternehmen.
Das ist das sogenannte Product Vision Board. Der Name ist von Roman Pichler geprägt und hier kannst Du dies herunterladen: Download Product Vision Board Template.
Darüberhinaus würde ich noch eine Sache ergänzen, und zwar die sogenannten „Deliverables“ aufschreiben, also Liefererzeugnisse, die der Lieferant erzeugen soll. Das kann eine Plattform sein, die gebaut werden soll, das kann eine Mobil-Applikation für Android oder eine iOS-Applikation, eine Webanwendung, ein Betriebskonzept sein. Das alles sind sogenannte „Deliverables“.
Gut, wenn ich das habe, dann komme ich zu
Punkt #2: Die Stakeholder Analyse.
Was ist das? Stakeholder sind Personen, die ein Interesse in dieser Lieferantenauswahl haben und die ich auf jeden Fall mit ins Boot holen sollte. Und jetzt geht es darum, diese Mitarbeiter zu identifizieren, und dieser Punkt ist sehr, sehr wichtig. Den sollte man sehr gewissenhaft machen und nicht mal eben nebenbei, weil wenn ich später vergessen habe, eine Person zu involvieren bei dem kompletten Prozess – sagen wir mal, zum Beispiel den Einkauf. Den muss ich auf jeden Fall immer involvieren, wenn es den gibt – dann bekomme ich Probleme. Dann sind die echt richtig sauer und dann wird es richtig schwierig, eine Freigabe zu erhalten. Ich nutze zur Stakeholder Analyse immer 2 Fragen.
Die 1. Frage ist: Wer muss eingebunden werden, um Freigaben für diese Lieferantenauswahl zu erteilen? Also Compliance, Einkauf, Technikbereich, Fachabteilungen.
Und die 2. Frage: Wer kann etwas dazu beitragen aus fachlicher, technischer und kaufmännischer Sicht und was kommt dann dabei raus?
Dabei raus kommt eine Liste mit Ansprechpartnern, die ich dann abklappern muss und nachfragen muss: Welche Anforderungen hast du an einen Softwarelieferanten? Und „Anforderung“ ist jetzt auch genau das richtige Stichwort. Das bringt mich jetzt zu Punkt #3.
Punkt #3 Anforderungsdokumentation an das Unternehmen.
Was kommt da wieder raus? Mal eben vorweggenommen: Raus kommt da wieder eine Excel-Liste mit Anforderungen, die das Unternehmen erfüllen muss. Und diese habe ich in 3 verschiedene Kategorien eingeteilt:
- Fachliche Anforderungen
- Technische Anforderungen und
- 3.: Organisatorisch, Kultur und Compliance Anforderungen.
Ich gehe jetzt mal kurz in die Bereiche rein.
Fachlich
Ich habe ja eben schon gesagt, diese 5, 6, 7 Epics haben wir definiert. Ja, das ist schon gut. Das ist auch fachlich, nur jetzt ist die Frage: Gibt es noch weitere spezielle Fertigkeiten, die der Lieferant mitbringen muss? Also was ganz Spezifisches, wie zum Beispiel SAP-Wissen oder Domain-Wissen aus dem Bankenbereich. Dann würde ich die auf jeden Fall mit aufnehmen.
Dann kommen wir zu technisch.
Also die Frage: Welche Fertigkeiten werden benötigt, um das Minimal Viable Product umzusetzen? Und hier gibt es eine riesige Bandbreit von: Man gibt alles komplett vor, wie was zu tun ist, also welche Skills, welche Programmiersprache, welche speziellen Frameworks. Bis hin zu: Man sagt nur, welche Rollen benötigt werden im Team, also Entwickler, Scrum Master, Proxy Product Owner und Architekturleitplanken, und überlässt dem späteren Team die komplette Ausgestaltung.
Dann gibt es organisatorisch, Kultur, Compliance.
Organisatorisch
Eine wichtige Frage ist dabei natürlich: Wie viel Zeit und wie viel Kohle habe ich? Und oft steht das schon fest, von daher würde ich das durchaus auch mal berücksichtigen bei der Lieferantenauswahl. Und hier wäre dann auch zu überlegen, ob Nearshore Entwicklung im nahen Ausland eine interessante Option ist, also ein komplettes Entwicklungsteam im Ausland.
Meine Meinung dazu: Es ist definitiv eine sehr interessante Option, da man
- Geld spart,
- kein Problem mit Scheinselbstständigkeit hat, auch nicht über Dauer, und man
- erhält die richtigen Talente.
Egal wo man seinen Firmensitz hat, man bekommen die richtigen Talente!
Bei uns, bei Leobalo, erhältst du ein Rundum-sorglos-Paket für das Thema Nearshoring, bei dem ich persönlich den komplett Prozess begleite – also von Produktvision, wenn du das möchtest, bis hin zum fertigen Produkt.
Wenn du dazu Fragen hast, lasse uns sehr gerne dazu unverbindlich über deine Situation sprechen.
Schreibe mir einfach eine E-Mail dazu unter info@leobalo.de oder mache gerne einen Termin auf unserer Website leobalo.de und ich glaube, da gibt es ganz oft diese Call-to-Action „Jetzt Termin vereinbaren“, und das kommt dann auch bei mir an. Wie gesagt, Kontaktdaten findest du in den Shownotes oder auf leobalo.de.
Kultur
Kulturfragen: Welche Werte und Prinzipien vertritt das Unternehmen? Und passen diese Werte und Prinzipien auch zu unserem Unternehmen? Da kann es durchaus eine große Diskrepanz geben. Speziell zu Kultur fällt mir ein: Ich erinnere mich noch, es gab mal einen Auftrag, der stand kurz vor dem Abschluss und der ist aber nicht zum Abschluss gekommen, und zwar weil eine Softwareanwendung erotischen Inhalt als Content hatte, und das war für das Team in dem kulturellen Kontext nicht vertretbar. Völlig OK. Deswegen ist es auch wichtig, diese kulturellen Dinge zu berücksichtigen und als Anforderung auch zu beschreiben.
Compliance
Vielleicht gibt es irgendwelche Richtlinien, Zertifizierungen oder andere Richtlinien, die das Unternehmen einhalten muss, und deswegen würde ich diese auf jeden Fall auch mit aufnehmen.
Noch mal zusammengefasst: Man erstellt also eine Liste mit 2 Spalten. In der 1. Spalte stehen die Anforderungen. Die können aus der Kategorie fachlich, technisch, organisatorisch, Kultur oder Compliance sein. Und in der 2. Spalte schreibt man rein, wie wichtig einem diese Anforderung ist, also „niedrig“, „mittel“, „hoch“ oder „Show Blocker“. Show Blocker bedeutet: Wenn diese eine Anforderung nicht erfüllt wird, dann können wir den Softwarelieferanten nicht nehmen.
#4: Die Unternehmensrecherche.
Und jetzt kann man auf 2 Arten vorgehen. Man kann natürlich die Internetsuche machen und dort zum Beispiel eine Shortlist erstellen oder man holt sich eine persönliche Referenz. Persönliche Referenz finde ich immer viel besser und erspart enorm Zeit.
Punkt #5: Videoanruf mit dem Softwareunternehmen.
Ich würde auf jeden Fall dazu raten, einen Videoanruf zu machen. Der ist viel persönlicher, als E-Mails zu schreiben. Und wenn man E-Mails schreibt, ist es ein asynchrones Kommunikationsmedium. Man weiß nie, ob und wann man etwas zurückbekommt. U
nd man kann gleichzeitig die Kommunikation, und wenn das ein Nearshore Provider oder Partner ist, auch die Englischkenntnisse prüfen. Dann gibt es natürlich erst mal in dem Anruf die Vorstellung beider Unternehmen. Das ist so ein bisschen zum Beschnuppern. Und im Anschluss daran würde ich die Moderation übernehmen und würde das Product Vision Board vorstellen.
Nach dem Product Vision Board würde ich die Anforderungen von der Anforderungsliste vorstellen, die als Showblocker gekennzeichnet sind. Das sind manchmal nur 3, 4, 5 Stück, aber wenn sich da schon herausstellt im ersten Gespräch, dass das Softwareunternehmen diese nicht erfüllt, dann kann ich es abbrechen. Dann können wir uns beide einfach Zeit sparen.
Gut, wir gehen jetzt mal davon aus, die Showblocker wurden alle als positiv beantwortet, und auch noch ein wichtiger Punkt: Die Chemie passt auch.
Dann würde ich im Nachgang die vollständige Anforderungsliste an den Vendor schicken und ihn bitten, eine sogenannte Selbsteinschätzung durchzuführen. Das heißt, er soll dort per Dropdown-Menü sagen, wie gut er diese Anforderung abdeckt.
Entweder „fully compliant“, „partially compliant“ oder „not compliant“.
Und was noch wichtig ist, als Tipp kann ich dir geben: Er soll hinter jeder Anforderung, auch wenn es fully compliant ist, 1, 2, besser 3 Sätze noch mal ins Freitextfeld reinschreiben als Detail, also einen ausführlichen Kommentar.
Achtung! Bevor du die komplette Anforderungsliste rausschickst, würde ich es noch mal kurz abklären mit der Rechtsabteilung, ob man nicht vorher einen sogenannten NDA schließen muss, also eine Verschwiegenheitserklärung. Gerade bei Großkonzernen ist das wichtig.
Gut, jetzt hat der Lieferant diese Listen bekommen, der hat die Selbsteinschätzung durchgeführt und jetzt kommen wir zum Punkt #6: Lieferant aussuchen.
#6: Lieferant aussuchen.
Jetzt geht es also darum, dass wir die Selbstauskunft vom Lieferanten auswerten, um dann eine Entscheidung herbeizuführen. Oft sind wir es nicht selbst, die Entscheidungen machen, sondern wir müssen die herbeiführen. Und in jedem Fall macht es Sinn, dass man mit dem Lieferanten noch ein weiteres Meeting macht, indem man diese Liste oder spezielle Punkte davon einmal durchgeht.
Tipp von mir: Mache auf jeden Fall auch Strichproben. Also prüfe die Punkte nach, die er als „fully compliant“ markiert hat. Stelle ihm dazu Fragen. Und am besten nicht geschlossene Fragen, dass er mit Ja und Nein antwortet, sondern offene Fragen, das heißt, wie er etwas macht. Wenn der Lieferant dann von dir und deinem Team, von allen Stakeholdern ausgewählt wurde und ihr sagt: „Ja, mit dem wollen wir gerne zusammenarbeiten“, dann ist der nächste Punkt, eine saubere Entscheidungsvorlage zu erstellen und alles da reinzuschreiben, damit die Entscheidungsträger auch die Entscheidung fällen können.
Kommen wir zu Punkt #7: Rahmenvertrag vereinbaren.
Der Rahmenvertrag ist noch nicht der richtige Projektauftrag. Der Rahmenvertrag regelt erst mal nur Rahmenbedingungen. Und dabei gibt es ein paar Dinge, die auf jeden Fall im Vertrag stehen sollte. Ich nenne jetzt nur mal 3 Dinge.
Es muss auf jeden Fall drinstehen, dass alle Dinge, die er erzeugt, dir später gehören.
Also er erstellt ein Bild oder eine Software und du hast alle Rechte davon.
Dann sollte drinstehen die Vertragslaufzeit und auch die bestimmten Konditionen, weil stelle dir vor, da stehen nur die Konditionen drin – ich sage mal einfach, 80€ für einen Senior Developer pro Stunde, aber keine Vertragslaufzeit. Dann könnte er 1 Tag später ankommen – sagen wir, ihr arbeitet 3 Monate zusammen – und am 1. Tag im 4. Monat, wenn dein Team komplett steht und sie sind voll dabei, Gas zu geben, dann sagt er: „Übrigens, der kostet jetzt nicht mehr 80€. Der kostet jetzt 90€.“ Und das umgeht man, indem man auch die Vertragslaufzeit mit aufnimmt.
Um vielleicht noch einen 3. Punkt zu nennen speziell beim Thema Nearshore: Ich würde dort auch darauf achten, dass etwas drinsteht zum technischen Schutz und physischen Schutz. Also es wird VPN eingesetzt, es wird Verschlüsselung eingesetzt, es werden Firewalls eingesetzt zum Schutz.
Und physischer Schutz wäre zum Beispiel ein Wachschutz, der auf die Gebäude aufpasst, und dass die Computer gesperrt werden. Das ist der Rahmenvertrag. Und auf diesen Rahmenvertrag würde man später Projektverträge aufsetzen. Im Englischen werden die auch gerne „Service Description“ genannt. Das war der 7. und letzte Punkt.
Und wenn du jetzt denkst: „Mensch, ich bin gerade auf der Suche nach einem Softwarelieferanten und das mit dem Nearshore, das hört sich schon interessant an, aber ich habe noch ganz viele Fragen“, dann klicke jetzt gern auf
