Zielgruppen & ICP

🔧 Komponentenhersteller – Zwei verschiedene ICPs
💡 Komponentenhersteller sind nicht gleich. Großkonzern und Mittelstand haben unterschiedliche Trigger, Champions, Entscheidungswege und Hauptschmerzen. Früh erkennen – dann den richtigen Track fahren.
🏢 ICP A – Großkonzern
Viele BUs, viele parallele Edge-Ansätze, kein gemeinsamer Nenner. Champion ist ein Innovation- oder BizDev-Manager. Entscheidung braucht BU-Konsens. Hauptschmerz: Fragmentierung und Maintenance-Last.
Referenz: Endress+Hauser / Franz
🏭 ICP B – Mittelstand
Konkreter Kundenwunsch als Auslöser. Champion an der Schnittstelle Vertrieb + Entwicklung. Direkte GF-Entscheidung. Hauptschmerz: Skalierung ohne Serviceeinsatz – kein Projektgeschäft aufgestellt.
Referenz: Herborner Pumpen / Tim
🏢 ICP A – Großkonzern: Firmografisches Profil
Großkonzern
💡 Referenzprofil: Internationaler Hersteller von Mess-, Sensor- oder Automatisierungskomponenten mit mehreren eigenständigen Business Units. Viele Initiativen parallel, aber kein gemeinsamer Standard. Eigene digitale Infrastruktur existiert in Teilen – ist aber fragmentiert.
Unternehmen
  • 500+ Mitarbeiter, €100M+ Umsatz
  • Mehrere eigenständige Business Units oder Tochtergesellschaften
  • International tätig, DACH/EU-Hauptsitz
  • Bekannter Markenname in der Prozess- oder Automatisierungsindustrie
  • Eigene Entwicklungsabteilungen – aber selten zentral koordiniert
Technisches Profil
  • Mehrere verschiedene Edge- oder IoT-Ansätze parallel im Konzern
  • Eigene Cloud-Plattform oder Connectivity-Lösung vorhanden (aber komplex)
  • Bekannt mit Docker/Containerisierung – aber kein gemeinsamer Standard
  • Margo-Konformität auf dem Radar oder aktiv diskutiert
  • Lange Entwicklungszyklen durch interne Abstimmung und Governance
✅ ICP-Muss-Kriterien
  • Mehrere parallele Edge/IoT-Ansätze im Konzern – kein gemeinsamer Nenner
  • Interner Champion mit Mandat zu „ausprobieren" – auch ohne volle BU-Freigabe
  • Interoperabilität und Ökosystem-Anschluss (Margo) strategisch relevant
  • Maintenance-Last blockiert Feature-Entwicklung – Kapazitätsproblem sichtbar
  • „Klein anfangen, schnell zeigen" passt zur internen Überzeugungsstrategie
😤 Pain Points
  • Bauchladen an Lösungen – jede BU hat ihren eigenen Ansatz, keine Vereinheitlichung möglich
  • Permanent in Security, Updates & Maintenance gefangen – keine Kapazität für neue Features
  • Hardware-Abhängigkeiten erzwingen immer wieder teure Architekturumbauten
  • „Common Edge"-Idee scheitert intern wegen Kosten und fehlender BU-Unterstützung
  • Kein Anschluss an App-Store-Ökosysteme und Interoperabilitätsstandards
  • Integration in Kundensysteme (SAP, ServiceNow) fehlt – App Store allein reicht nicht
👤 Buying Persona Großkonzern – Der Innovation-Champion
Großkonzern
💡 Kein klassischer IT-Leiter, kein reiner R&D-Engineer. Der Einstiegspunkt im Konzern ist oft ein Innovation Manager, Product Owner oder Business Developer – jemand mit strategischem Blick und der Bereitschaft, ohne vollständige Konzernfreigabe etwas auszuprobieren.
Profil
  • Titel: Innovation Manager / Product Owner / Head of Digital / BizDev
  • Background: Oft Marketing- oder Produktnähe, versteht Technik aber ist kein Entwickler
  • Antrieb: Will etwas bewegen – im agilen Spirit: ausprobieren, lernen, zeigen
  • Position: Hat Mandat innerhalb seiner BU, braucht aber Konzern-Unterstützung für Skalierung
  • Kontaktpunkt: Fachkonferenzen, LinkedIn, Innovationsprogramme
Was ihn überzeugt
  • Schnell etwas Greifbares: Demo schlägt Folienschlacht
  • Niedrige Einstiegshürde – FLECSelerator passt zum agilen Spirit
  • Interoperabilität und Margo als strategische Anschlussfähigkeit
  • „Von der Stange kaufen + eigene Kompetenz behalten" – kein Kontrollverlust
  • Sieht FLECS als strategische Partnerschaft, nicht als reines Tool
Interne Entscheidungsstruktur
Champion:Innovation/BizDev Manager – initiiert, probiert aus, sammelt Evidenz für interne Überzeugung
Economic Buyer:BU-Leitung oder Konzern-Board – braucht Business Case + Demo + andere BUs die mitziehen
Bremser:Andere BUs mit eigenen Ansätzen, zentrale IT/Procurement, Konzern-Governance-Prozesse
Schlüssel:Schnelle Demo mit greifbarem Ergebnis → mehr interne Glaubwürdigkeit als jede Präsentation
Trigger Events
Interner „Common Edge"-Versuch scheitert an Budget / BU-Unterstützung · Margo-Standard wird intern relevant · Wettbewerber zeigt App-Store-fähige Lösung auf Messe · CRA macht Lifecycle-Management zu Pflicht
🚫
Disqualifizierer
Keinerlei digitale Infrastruktur oder Cloud-Kompetenz im Konzern · Vollständig auf proprietäre Konzern-Plattform committed ohne Öffnungsstrategie · Kein interner Champion mit Mandat zu experimentieren
🏭 ICP B – Mittelstand: Firmografisches Profil
Mittelstand
💡 Referenzprofil: Spezialisierter Hersteller von Industriekomponenten (Pumpen, Sensoren, Antriebe etc.) mit klarer Nische, eigenem Prozesswissen und konkretem Kundenwunsch als Digitalisierungsauslöser. Will Software skalieren wie Hardware – ohne Projektgeschäft.
Unternehmen
  • 50–300 Mitarbeiter, €10–80M Umsatz
  • Inhabergeführt oder familiengeführt
  • DACH, exportorientiert in Europa
  • Spezialisiertes Produkt mit eigenem Prozesswissen (Nischenführer)
  • Fünfstellige Kundenzahl in Mitteleuropa – breite, unerschlossene Basis
Technisches Profil
  • Hat bereits eine digitale Lösung (IoT-Gerät, App) – aber deployment-seitig nicht skalierbar
  • Will Hardware-Unabhängigkeit: Kunde wählt Gerät, Software läuft trotzdem
  • Klein in Entwicklung (2–5 Entwickler) – will Infrastruktur kaufen, nicht selbst bauen
  • Vertraut mit Containern / Docker als Konzept, aber kein eigenes Deployment-System
  • Ziel: Kunde kauft, installiert und nimmt in Betrieb – ohne Herstellereinsatz
✅ ICP-Muss-Kriterien
  • Hat konkrete digitale Lösung – aber Deployment/Skalierung ist das Problem
  • Mindestens ein realer Kundenwunsch oder Pilot als Auslöser vorhanden
  • Hardware-Unabhängigkeit ist zentrales Requirement (Kunde wählt Hardware)
  • Zu klein für Projektgeschäft – Skalierung muss ohne Personaleinsatz funktionieren
  • GF/technische Leitung offen für konkreten Piloten – kein langer Entscheidungsweg
😤 Pain Points
  • Großkunde will digitalisieren – aber auf eigener Hardware, nicht der des Herstellers
  • Jede Inbetriebnahme braucht jemanden vor Ort – nicht skalierbar bei 100+ Kunden
  • Jede neue Hardware (Beckhoff, RevPi, B&R) erfordert Eigenheiten-Handling – kein echter Standard
  • Subscription-Modell schwierig wegen Kundenprofil (z.B. öffentliche Hand, kein OPEX-Budget)
  • Remote-Updates und Device-Übersicht fehlen komplett – kein Lifecycle-Management
👤 Buying Persona Mittelstand – Der Brückenbauer
Mittelstand
💡 Kein reiner Entwickler, kein reiner Verkäufer. Der Champion im Mittelstand sitzt an der Schnittstelle von Vertrieb und Entwicklung – er trägt Kundenanforderungen in die Technik und übersetzt technische Möglichkeiten zurück in Kundennutzen.
Profil
  • Titel: Produkt-/Projektentwickler, technischer Vertrieb, IoT-Verantwortlicher
  • Background: Ingenieur oder Techniker mit starkem Kundenkontakt
  • Rolle: Trägt Kundenanforderungen intern, skizziert Lösung, holt GF-Mandat
  • Position: Hat FLECS oft schon länger auf dem Radar – wartet auf konkreten Auslöser
  • Kontaktpunkt: Direkte Empfehlung, Fachevents, Messen, LinkedIn
Was ihn überzeugt
  • Konkreter Use Case der dem Kundenauslöser entspricht
  • Hardware-Unabhängigkeit als zentrale Zusage – nicht nur versprechen, beweisen
  • Einfaches Self-Service-Onboarding: Kunde kann selbst installieren
  • Remote-Update und Device-Übersicht – spart Serviceeinsätze
  • FLECSelerator: überschaubar, kein Risiko, schnell sichtbares Ergebnis
Interne Entscheidungsstruktur
Champion:Brückenbauer Vertrieb/Technik – hat Kundenanforderung, skizziert intern die Lösung
Economic Buyer:Technische Leitung oder GF – direkter Weg, entscheidet wenn Use Case klar und Kosten überschaubar
Bremser:Kostendiskussion am Anfang (löst sich auf wenn Pilotnutzen sichtbar); Kundenprofil (öffentliche Hand skeptisch zu laufenden Kosten)
Schlüssel:Pilot mit echtem Kunden – hat der Champion einen konkreten Kunden der mitmacht, ist der Weg zur GF kurz
Trigger Events
Großkunde fordert digitale Integration auf eigener Hardware · Pilot scheitert an Hardware-Diversity · Skalierungsfrage wird intern konkret: „Wie machen wir das bei 100 Kunden?" · Wettbewerber zeigt skalierbare Lösung
🚫
Disqualifizierer
Noch keine digitale Lösung entwickelt und kein konkreter Kundenwunsch · Kunden akzeptieren kein Self-Service-Onboarding · GF will grundsätzlich kein digitales Produktgeschäft aufbauen
🏭 Maschinenbauer / OEM – Firmografisches ICP
Zielunternehmen
💡 Referenzprofil: Mittelständischer Sondermaschinenbauer mit eigener R&D, großer installierter Basis und konkretem Wunsch nach wiederkehrenden Einnahmen. Inhabergeführt oder familiengeführt – technisch affine Entscheider.
Unternehmen
  • 100–500 Mitarbeiter, €20–150M Umsatz
  • Inhabergeführt oder familiengeführt
  • Standort: DACH, exportorientiert
  • Spezialmaschinenbau – keine Commodity-Maschinen
  • 50–200 Maschinen/Jahr, Lebensdauer 10–20 Jahre
Technisches Profil
  • Eigene Software/R&D – mind. 3–10 Entwickler intern
  • Nutzt Docker/Linux auf Maschinen oder hat konkrete Pläne dafür
  • Eigene oder geplante Steuerungsentwicklung (SPS)
  • Noch kein proprietärer Vendor-Plattform-Lock-in
  • Installierte Basis: 200–2.000+ Maschinen im Feld
✅ ICP-Muss-Kriterien
  • Hat eigene Softwareentwicklung oder klaren Plan dafür
  • Große installierte Basis – manuelle Updates nicht mehr skalierbar
  • C-Level will wiederkehrende Einnahmen aus digitalen Services
  • Technisch affine Geschäftsführung – überzeugt durch Produkt + Referenz
  • Vendor Independence ist ein aktives Thema im Unternehmen
😤 Pain Points
  • Jeder Entwickler hat seine eigene Variante – kein Standard, kein reproduzierbarer Prozess
  • Updates manuell, Projekt für Projekt – bei 100+ Maschinen im Feld nicht mehr tragbar
  • Kein Überblick: Welche Maschine läuft welche Softwareversion?
  • Geschäftsmodell für digitale Services intern noch nicht geklärt
  • Viele Abteilungen müssen mitziehen – kein Produktmanagement vorhanden
  • Angst vor Lock-in durch große Plattformanbieter
👤 Buying Persona – Der R&D Champion
Primärkontakt
💡 Nicht der GF und nicht der IT-Leiter. Der typische Einstiegspunkt ist der Leiter R&D oder Head of Engineering – früher selbst Entwickler, heute mit strategischem Blick und GF-Rückendeckung.
Profil
  • Titel: Leiter R&D / Head of Engineering / CTO
  • Background: Früher selbst Entwickler, heute Management
  • Rolle: Champion der Initiative – treibt das Thema intern
  • Rückendeckung: Hat GF/Inhaber hinter sich
  • Kontaktpunkt: Messen (Hannover, SPS, Interpack), LinkedIn, Fachevents
Was ihn antreibt
  • Standardisierung & Entwicklungseffizienz (sofort)
  • Vendor Independence – kein neuer Lock-in
  • Sieht die strategische Notwendigkeit früher als alle anderen
  • Will einen Piloten zeigen, nicht endlos diskutieren
  • Überzeugt durch Technik + konkrete Referenzen
Interne Entscheidungsstruktur
Champion:Leiter R&D / Engineering – treibt, recherchiert, präsentiert intern
Economic Buyer:GF / Inhaber – will wiederkehrende Einnahmen + digitale Produkte, braucht Entscheidungsvorlage
Bremser:Konstruktion, Service, Dokumentation, Einkauf – alle müssen „mitgenommen" werden, keiner will Verantwortung übernehmen
Kein:Formales Produktmanagement – Entscheidungen laufen über Champion → GF → Entscheidungsvorlage
⚡ Trigger Events – Wann sind sie kaufbereit?
💡 Kein Trigger = kein Timing. Diese Ereignisse signalisieren, dass das Thema intern gerade heiß ist – dann ist der Moment für den ersten Kontakt.
🔧
Neue Maschinengeneration / eigene SPS-Entwicklung gestartet
Suchen eine Plattform für die neue Architektur – offenster Moment überhaupt
📈
Installierte Basis wächst – manuelle Updates werden unmöglich
Ab ~100 Maschinen im Feld kippt der Aufwand. Der Schmerz ist konkret und täglich spürbar.
🏛️
CRA taucht intern auf – Konstruktion stellt Fragen zur Update-Strategie
Oft der erste formale Anlass, das Thema aus R&D in die Breite zu tragen
🎪
Messe-Discovery: Hannover Messe, SPS, Interpack
Häufigster erster Kontaktpunkt – R&D Champion entdeckt FLECS, qualifiziert intern vor
⚔️
Wettbewerber startet digitale Services oder Remote-Angebote
Macht das Thema intern politisch dringend – GF fragt plötzlich nach
🚫 Disqualifizierende Kriterien – Wer ist kein ICP?
Finger weg
💡 Früh disqualifizieren spart mehr Zeit als jeder gewonnene Deal. Beckhoff-Hardware ist kein Ausschlusskriterium – Beckhoff hat keine eigene Plattform. Der Disqualifizierer ist ein bereits laufender proprietärer Plattform-Stack eines Großanbieters.
🔴
Committed zu proprietärer Vendor-Plattform (Siemens Industrial Edge, Schneider EcoStruxure)
Wer bereits die Software-Distributionsschicht eines Großkonzerns betreibt, hat den Plattform-Entscheid getroffen. Beckhoff-Hardware ist kein Problem – Beckhoff hat keine eigene Plattform.
🔴
Keine eigene Softwareentwicklung – weder heute noch geplant
Ohne eigene Entwicklungskompetenz fehlt die Basis. Kein Champion, kein Hebel.
🔴
Zu klein – unter 30 Mitarbeiter, kein dedizierter Entwickler
Kein Champion vorhanden, der das Thema intern trägt. ROI-Schwelle nicht erreicht.
🔴
Kein C-Level Support für Digitalisierung
Ohne GF/Inhaber hinter dem Thema stirbt jeder Pilot nach der ersten internen Gegenwehr.
🔴
Commodity-Maschinen mit kurzer Lebensdauer
Kein echter installed-base ROI. Digitale Services als Umsatzträger funktionieren nur bei langen Maschinenzyklen.
🏗️ Fabrik- / Anlagenbetreiber – ICP & Persona
🎯 ICP-Kriterien
  • Betreibt Maschinen verschiedener Hersteller
  • Hat Bedarf an zentralem Software-Management
  • Will herstellerunabhängig betreiben und aktualisieren
😤 Pain Points
  • Verschiedene Update-Mechanismen pro Hersteller
  • Komplexes, teures Lifecycle-Management
  • Sicherheitsrisiken durch fragmentierte Infrastruktur
  • Skalierung über mehrere Standorte schwierig
✓ Gespeichert