NextCycle - Der Obsolescence Podcast

(0:00 - 0:19)
Hallo Zehra, freut mich, dass du in meinem Podcast Next Cycle mit dabei bist. Ja, vielleicht zum Start, sag ein paar Sätze zu dir, was soll man zu dir wissen? Ja, vielen Dank erstmal für die Einladung. Ja, ich bin Zehra Anlatan und ich bin die Geschäftsführerin der Peucon GmbH.

(0:19 - 0:37)
Wir machen Embedded Systems oder wie man das auch so schön immer generalisiert. Da entwickeln wir Hardware- und Softwarekomponenten für Großkonzerne. Wir konzentrieren uns speziell auf Hochtechnologieentwicklung.

(0:38 - 1:02)
Das heißt, wir fangen meistens in den Projekten dort an, bevor noch irgendetwas steht. Da steht manchmal sogar kein Lastenheft und dann muss vielleicht eine sehr schnelle Machbarkeit gemacht werden oder ein Proof of Concept oder ein Prototyp oder ein neuer Standard muss erprobt werden auf einer bereits bestehenden Produktebene, ob man sie integrieren kann. Also solche Themen, da beschäftigen wir uns mit.

(1:03 - 1:20)
Und dass für den Kunden natürlich der höchstmögliche IP-Schutz dann auch passiert, aber auch, dass man das in so einem Umfeld macht, dass der Kunde nicht viel zu viel Zeit verliert. Das ist so ein bisschen Balancierart. Ja, auch was ich da raushöre, so eine ganz, ganz hohe Konzeptphase auch schon.

(1:20 - 1:35)
Da auch einfach diesen MVP vielleicht schnell liefern in der Kundes, wenn ich das selber nicht so schnell kann. Ich darf nochmal eine Rückfrage, was sind so Branchen? Wie kann man sich so eure Kunden vorstellen? Unsere Kunden sind Großkunden aus verschiedenen Branchen. Wir haben Großkunden gehabt, die kamen aus dem Konsumerbereich.

(1:38 - 1:59)
Wir haben auch alles von Spielekonsole gemacht bis hin zu E-Bike-Antrieben. Also da haben wir beispielsweise eine ganz, ganz berühmte Konsole mitentwickelt. Oder im Medizintechnikbereich von intramuskulärer Sensorik bis hin zu Messtechnik mittels Radar für Mikronitermessungen.

(1:59 - 2:53)
Da wollte man wissen, ob während einer Pipettierung in einem automatisierten Bereich, ob man da mit einer neuen Messmethodik ran kann oder gewisse Sachen wie Indoor-Lokalisation von Leuten mittels Winkelmessung auf WiFi oder Bluetooth. Also das reicht weit. Wir haben auch E-Mobility gemacht, da haben wir E-Bike-Antriebe, HMIs, Komponenten für E-Mobility entwickelt, Zirkularitätsprojekte fürs Reusen von bereits benutzten Elektroniken oder Qualitätssicherung während Produktion.

(2:58 - 3:03)
Oder Forschungsprojekte für autonome Binnenschifffahrt. Also da ist wirklich ein breites Feld drin. Ein breites Spektrum.

(3:03 - 3:18)
Genau, das Spektrum ist sehr breit und wir lernen aber auch sehr viel. Deswegen machen wir das auch so gerne, dass wir das Spektrum auch weitgehend breit halten, weil die Transferleistung in einem wiederum anderen Bereich ist dann viel höher. Man kann mit einer größeren Kreativität ran.

(3:19 - 3:40)
Wenn man dich jetzt so sieht, glaubt man gar nicht, dass es das Unternehmen schon 35 Jahre weit gibt. Geh da vielleicht mal kurz rein. Wie habt ihr euch da auch so eine Historie entwickelt? Was ist deine Rolle? Wann bist du dazu gestoßen? Also die Peucon GmbH wurde 1991 von Uwe gegründet.

(3:40 - 4:05)
Der ist vom Background her Nachrichtentechniker und Kaufmann und der hat die Firma gegründet und hat in den 90ern die ersten DECT-Telefoniegeräte mitgemacht. Der hat dann ganz viel bei Siemens mitgemacht und gearbeitet. Es fing dann halt tatsächlich auch mit Wireless an.

(4:06 - 4:25)
In den 2000ern gab es dann auch ganz viel in der Richtung Indoor-Lokalisation, Forschungsprojekte auch für diverse Sachen. Das ist wirklich eine Band der Breitweite gewesen. Dann kam natürlich Uwes allerliebstes Projekt.

(4:25 - 4:44)
Da hat er damals an der Xbox mitgearbeitet, also an der Xbox 360. Wir haben Chip-Entwicklung mitgemacht, also ASIC-Entwicklung. Wir haben im Bereich beispielsweise später dann auch E-Antriebe.

(4:46 - 5:24)
Ich glaube, ich habe wirklich alle möglichen Projekte 35 Jahre durchgesichtet. Die Bandbreite ist wirklich amazing. Dann ging es rüber in E-Mobility-Sparte, also wirklich Sachen für Ladetechnik, für Konzepte von autonomer Binnenschifffahrt, wie gesagt, bis hin zu Apps oder auch Anwendungen, die für Logistik, für Gefahren gut gedacht waren.

(5:24 - 5:37)
Die Bandbreite ist wirklich Wahnsinn. Vor allem auch für so ein KMU wie Peucon, dass man da wirklich über die Jahre sich so eine Expertise aufbauen konnte als Unternehmen. Das ist wirklich sehr respektabel.

(5:37 - 5:51)
Da habe ich auch echt großen Respekt vor dem Lebenswerk der Kollegen. Ja klar, und jetzt auch so der Punkt, an dem du stichst, dass du jetzt vor gut einem Jahr das Unternehmen von Uwe als Geschäftsführer übernommen hast. Teil ist noch im Hintergrund aktiv und arbeitet hier auch fleißig noch mit.

(5:51 - 6:19)
Aber auch so dieses Erbe erhalten, aber auch die Schritte nach vorne, ist eine spannende neue Herausforderung. Ja, 2017 bin ich ja damals dazugekommen und da war ich Werkstudentin. Ich bin dazugekommen, habe das Unternehmen kennengelernt, ein paar Jahre hier gearbeitet, habe dann ein paar Jahre bei Siemens Energy gearbeitet und bin dann tatsächlich 24 zurückgekommen.

(6:19 - 6:39)
Auch mit dem Angebot zu schauen, ob wir auch die Übernahme langsam machen. Und ich muss ehrlicherweise gestehen, man lernt echt dazu. Also ich kann beim besten Willen, ich werde glaube ich die nächsten 10, 20 Jahre noch dazu lernen.

(6:43 - 6:57)
Aber es gibt wirklich viel zu tun, es gibt wirklich viel, was man auch lernen kann. Besonders bei den Kollegen, die haben immer fleißig und pfiffige Ideen. Da kommt man wirklich auf seine Kosten, das ist wirklich Wahnsinn.

(6:57 - 7:05)
Das kann ich mir gut vorstellen. Ich sage mal, ihr macht ja Hardware und Software. Ich denke, das ist auch immer eine Herausforderung, die beiden Bereiche gut zu verknüpfen.

(7:08 - 7:14)
Ja, definitiv. Also das ist es. Und zwar folgendes.

(7:14 - 7:32)
Man muss natürlich auch schauen, was es ist. Ich gebe mal ein Beispiel. Wenn wir jetzt beispielsweise Sachen wie Sensorik haben, die dann nachher auch gesammelt werden, Sensorik-Daten sammelt und dann muss man sie natürlich über gewisse Geräte dann weitersenden, sei es ein Gateway, eine Bridge, was auch immer.

(7:33 - 7:58)
Dann müssen natürlich diese Daten später auch da, wo sie ankommen, müssen die auch gut verwertet werden. Ich meine, wir machen ja nicht nur die Platine oder wir designen ja nicht nur die Hardware, die Platine, die Bauteile, sondern die Treiber-Software kommt ja auch noch von uns. Und dann machen wir uns ja auch noch mit dem Kunden die Gedanken beispielsweise, was passiert danach mit den Daten.

(7:59 - 8:13)
Als bestes Beispiel kann ich ja das Radar-Projekt geben, das für die autonomen Bildschirme war. Das war für Infineon gewesen. Und da haben wir Edge-Radarsensoren gehabt.

(8:13 - 8:34)
Das waren 24 Gigahertz-Sensoren im Innenflügel und im Äußeren 60. Da haben wir Probleme gehabt wie Interferenz oder wie die Strecke von Sensorik, also von der Antenne nachher oder vom PC bis hin zum Steuergerät. Da habe ich beispielsweise das Reallabor gehabt.

(8:34 - 9:05)
Da muss man so Sachen beispielsweise beachten wie Latenzen oder so Sachen wie, passen die Daten aufeinander, sind die Daten korrekt, sind die Daten auch das, was wir erwartet haben, werden die Erwartungswerte getroffen. Da haben wir beispielsweise Datensätze gehabt, Geodaten, dann die Daten vom Radar allgemein. Haben die überhaupt Sinn ergeben? Man muss das große Ganze im Blick behalten.

(9:05 - 9:12)
Genau, genau. Und dann gab es dann so Sachen wie beispielsweise Kameradaten. Dann hatten wir noch ein Leader da dran.

(9:15 - 9:32)
Das ist ja nicht nur ein Stream an Daten, sondern mehrere. Da muss man das auch noch synchronisieren. Passen die Clocks aufeinander? Ist alles richtig zusammengekommen? Hat man das alles richtig interpretiert? Ist das Reallabor auch tatsächlich? Man kann auch sagen, der Chronoschluss kann sich wirklich damit was anfangen.

(9:32 - 9:53)
Und dann haben wir beispielsweise die Vorarbeit geleistet mit solchen Projekten und gesagt, dann haben wir das gesichtet, wir haben das Reallabor gemacht. Wir sind auch wirklich in ein Boot mit reingestiegen, sind dann durch das, als natürlich die Hardware und alles da war. Das ist natürlich dann auch ein Feeling, wenn man mal aktiv sieht, was man entwickelt hat und was die Auswirkungen davon aussehen, dass man die Chance immer bekommt.

(9:53 - 10:07)
Genau, das war wirklich ein tolles Projekt. Solche Projekte wünsche ich mir wieder, bin ich ehrlich. Davor beispielsweise, da fuhr man dann durch die Spree mit dieser Barge.

(10:07 - 10:28)
Natürlich, da war dann noch jemand, der diese Barge fahren durfte oder musste, wir durften das ja nicht. Aber dann mussten wir beispielsweise, einer musste auf dem Steg bleiben, da musste einer in die Barge und da mussten wir auch filmen, damit wir auch gucken konnten, später auch auf der Karte beispielsweise, wie das Ding durchgefahren ist. Wir haben dann beispielsweise Protokolle an Protokollen abgegeben.

(10:30 - 10:51)
Wo Messaufbauten beschrieben waren, ob die Messaufbauten und die Messungen korrekt waren, was für Ergebnisse da waren, ob die Daten korrekt waren. Und da mussten diese Daten noch in Formaten angegeben werden, sodass unser Kunde dann seine KI antrainieren konnte, damit ihre KI-Einheit nachher auch diese Barge steuern kann. Das Ding fährt sogar heute durch die Spree.

(10:51 - 11:03)
Also wenn du mal was Gelbes siehst, was durch die Spree fährt, da haben wir mitgewirkt. Das war so ein Projekt, da hatte ich richtig Spaß, bin ich auch bis heute. Ja, man schiebt sich grad drauf an.

(11:03 - 11:14)
Ja, ich bin zu viel am Lachen wahrscheinlich. Aber so was macht Spaß, weil da ist auch, muss man auch ehrlich sein, da ist auch das Potenzial, dass viel schief gehen kann. Aber das ist auch die Herausforderung.

(11:14 - 11:26)
Ja, natürlich, wieso würde ich das denn sonst machen, hallo? Nein, aber ich glaube, wir haben auch sehr viele Projekte, die in der Hinsicht auch herausfordernd sein müssen. Das ist auch gut für Geist. Ja, das kann ich mir vorstellen.

(11:26 - 11:52)
Lass uns da vielleicht so ein bisschen raushummeln und du über die ganzen Projekte schaust. Was sind denn so vielleicht auch Anforderungen, die so der Kunde mitbringt an euch, so grad bei moderner Elektronikentwicklung, aber auch vielleicht Anforderungen, die ihr am Kunden habt zu dieser Zweitperspektive? Unterschiedlich. Manchmal, es gibt einen Kunden beispielsweise, die haben uns elf Versionen einer Spezifikation geliefert.

(11:52 - 12:06)
Okay. Aber das war dann auch im Laufe der Zeit. Und es gab, da kam eine Vorspezifikation, das ist aber für Kunden, die wirklich in hochregulierten Bereichen sind und die bereits wissen, was entwickelt werden soll.

(12:06 - 12:25)
Die kommen dann meistens bereits mit Anforderungen, die definitiv und zwingend erfüllt werden müssen, weil es gesetzlich vorgeschrieben ist. Da kann man jetzt nicht großartig rumdiskutieren und sagen, nee, brauchst du nicht, weil XY, nee, nee, das muss da sein. Es geht in die Richtung, wie ich vielleicht auch das Ganze auslege.

(12:26 - 12:37)
Vielleicht auch Medizintechnik, wo einfach Anforderungen sind. Ich denke auch an Themen wie Beständigkeit gegenüber Wärme, Wasser, Kohlen. Genau, beispielsweise Korrosion.

(12:37 - 12:49)
Das darf auf keinen Fall passieren. Oder auch gewisse Bauteile dürfen gar nicht reinbenutzt werden, weil sie gar nicht dafür vorgesehen sind. Auch wenn sie vielleicht billiger sind.

(12:50 - 13:06)
Aber wenn es nicht für Medizintechnik oder für Leistungselektronik oder was weiß ich, wenn es nicht dafür ausgelegt ist, dann kann man das auch nicht da reinpacken. Also das ist ja unsinnig. Deswegen, es gibt dann Kunden, die sagen dann, okay, das ist das, was wir mindestens brauchen.

(13:07 - 13:16)
Und den Rest, den entwickelt man drumrum. Man weiß ja auch noch nicht, was final dann da ist. Ja, das ist eine grobe Idee, wo es hingehen soll manchmal auch.

(13:16 - 13:28)
Nein, natürlich, wenn der Kunde jetzt sagt, wir brauchen Asic, ihr müsst uns bei der Asic-Entwicklung unterstützen. Das ist ein No-Brainer. Wenn jetzt ein Kunde sagt, ich brauche einen Kochlöffel, kann ich auch keinen Schuh entwickeln für den Kunden.

(13:29 - 13:32)
Ja, was Neues. Ja, klar. Aber ich bin bei dir.

(13:33 - 13:43)
Aber da muss man auch natürlich schauen, was es ist. Im Konsumentenbereich hat man da bessere Freiheiten. Beispielsweise, wenn da jemand sagt, okay, ich möchte jetzt, keine Ahnung, irgendeine Uhr entwickeln.

(13:43 - 13:54)
Oder ich möchte eine gewisse Art von Türschloss entwickeln. Da hat man mehr Freiheiten, weil es ist ein Konsumentenprodukt. Das kann man schnell skalieren.

(13:55 - 14:05)
Die Elektronik kann man weitestgehend, da nimmt man Bauteile, die günstiger sind. Da nimmt man Bauteile, die kleiner sind, macht die Hardware so klein wie möglich. Und dann let's go.

(14:05 - 14:21)
Oder man sagt zum Kunden, ja, okay, du bist in der zweiten Version deines Produktes. Das erste lief gut, lass mir eine Miniaturisierung machen. Oder lass vielleicht ein paar Komponente weg, weil das war Overkill.

(14:21 - 14:46)
Man braucht auch nicht alles in jedem Produkt drin. Und ich glaube, dafür entwickelt man auch mit der Zeit das Gespür dafür. Wenn wir jetzt eure Seite angucken, was fordert ihr von euren Kunden? Dazu muss man sagen, wir haben Großkunden.

(14:46 - 14:54)
Wir haben aber auch Mittelständer. Wir haben aber auch mit Kleinunternehmen gearbeitet. Und was wir mindestens fordern, ist Respekt am Leib und Leben.

(14:54 - 15:12)
Das sagt sich immer so, aber wir arbeiten teilweise in Produkten oder Komponenten zu, die nachher in größeren Systemen integriert werden. Es sind nicht nur immer fertige Produkte, die wir mitentwickeln. Manchmal sind das Komponente eines ganz erhaltlichen Systems.

(15:12 - 15:18)
Das spielt so eine Rolle in dem Gesamtorchester. Genau. Und da müssen gewisse Sachen wie funktionale Sicherheit eingehalten werden.

(15:18 - 15:36)
Beispiel, wir haben ja E-Bike-Motoren mitentwickelt. Da müssen Sachen aber auch richtig sein. Die Brandschutzklassen müssen da sein.

(15:36 - 15:48)
Das muss rüttelschüttelfest sein, wenn da Wasser reinkommt. Oder da darf auch kein Wasser rein eigentlich. Da muss man natürlich auch sehen, wie die Sachen so sind, dass da jetzt nicht jemandem zu Schaden kommt.

(15:48 - 15:56)
Klar, und dann sagt ihr zum Kunde, er würde darauf verzichten. Das wäre einfach so ein Logokriterium, so etwas zu entwickeln. Und er würde auf solche essentiellen Sachen verzichten.

(15:56 - 16:13)
Genau. Es gibt auch Sachen, da muss man auch sagen, wir müssen vielleicht auf Gimmicks verzichten. Gimmicks sind schön.

Ich meine, das macht dem Entwickler ja auch Spaß. Aber am Ende genommen muss man auch betrachten, was braucht nachher der Kunde oder was braucht der User wirklich. Man hält sich immer so ein bisschen was offen.

(16:13 - 16:37)
Aber man darf jetzt auch nicht, ich meine, wenn man jetzt, sagen wir mal Türschloss als Beispiel. Ein Türschloss braucht vielleicht, vielleicht braucht es Bluetooth, wenn es mit dem Handy ist. Oder vielleicht braucht es Wifi, aber der braucht jetzt nicht noch zehn andere Standards oder noch zehn andere Module noch in dieser Hardware oder in dieser Elektronikkomponente.

(16:38 - 16:46)
Man muss die Dinge auch nicht überladen. Und ich glaube, da braucht man auch immer Entwicklungspartner, die das auch im Überblick haben. Die dann auch sagen, ja.

(16:46 - 16:49)
Das gewisse Gespür. Genau. Die dann aber auch so ehrlich zum Kunden sind.

(16:49 - 17:08)
Es gibt ja auch gewisse Sachen oder gewisse Momente, da muss man auch zum Kunden Nein sagen können. Und da muss der Kunde auch einem zuhören. Nicht bei funktionaler Sicherheit, da gibt es keine Diskussion.

(17:08 - 17:16)
Absolut nicht. Oder bei Sachen, die für Zertifizierung notwendig sind. Aber bei Leib und Leben, da gibt es einfach keinen Spaß.

(17:17 - 17:35)
Da kann man keinen Shortcut machen. Dadurch, dass wir halt rückblickend 30, 35 Jahre genau das gemacht haben. Vielleicht auch da ein bisschen tiefer einsteigen oder so ein bisschen zurückblicken für die letzten Jahre.

(17:35 - 17:48)
Was hat sich da so verändert in der Entwicklung? Ist es komplexer eher geworden oder wird es mehr zu beachten? Ist das so eine ganz grobe Einschätzung? Ja. Oh, puh. Ja, klar.

(17:49 - 18:03)
Ich meine, wir reden aktuell über ganz verschiedene Trends. Vor 10, 15 Jahren waren gewisse Sachen, die heutzutage Bass, ich sage mal in Anführungsstrichen Basswurzeln, die wären da gar nicht vorstellbar gewesen. Oder sie waren vorstellbar, aber noch vielleicht in Entwicklung.

(18:05 - 18:13)
Heutzutage erwartet beispielsweise jeder eine gewisse Connectivity. Alles muss schnell gehen. Alles muss sofort da sein.

(18:14 - 18:23)
Alles muss gestern bereits schon entwickelt worden sein. Das muss alles drin haben. Aber ich glaube, da muss man natürlich auch dementsprechend gucken.

(18:23 - 18:29)
Alles muss intelligent sein. Das kommt ja auch noch dazu mit der Vernetzung. Es muss lernen können, Stichpunkt KI und alles.

(18:30 - 18:45)
Und da muss man natürlich auch darauf achten, ob das für gewisse Sachen aber auch Sinn ergibt, die dann weitestgehend … Es ist auch nicht überfrachtet. Ja, es ist überfrachtet. Ergibt das überhaupt Sinn? Wir befinden uns jetzt auch im Konsumentenbereich.

(18:45 - 18:53)
Man guckt ja mal die Telefone beispielsweise an. Wir haben jedes Jahr ein neues Telefon. Wir haben jedes Jahr irgendwie gefühlt einen neuen Laptop.

(18:54 - 19:12)
Ist das ein Mehrwert gegenüber der letzten Generation? Ist das überhaupt ein Mehrwert oder ist das ein scheinbarer Mehrwert? Wir haben halt ganz große Problematiken jetzt in der Elektronik, die wir uns auch kümmern müssen. Ich meine, wir haben auch Begrenzungen an der Physik. Irgendwann ist die Physik auch an einem gewissen Ende angekommen.

(19:12 - 19:17)
Da kann man auch nicht drüber. Da muss man dann natürlich andere, neuere Technologien machen. Ich denke gerade auch an Chipgrößen, die immer kleiner werden.

(19:18 - 19:22)
Aber es gibt da einfach Limits, die irgendwann recht sind. Genau. Jetzt redet man ja über Photonik und sonstige Geschichten.

(19:22 - 19:29)
Auch ein super spannendes Feld. Falls du dich noch nicht damit beschäftigt hast, würde ich dir sehr ans Herz legen. Wirklich sehr spannend zu sehen.

(19:30 - 19:57)
Aber da muss man dazu aber auch sagen, physikalische Limits existieren. Und da muss man auch schauen, was geht. Was ist überhaupt Usability für diesen besonderen Anwendungsfall, den man dann haben möchte? Und da ist es einfach wirklich unbezahlbar, wenn man diesen Blick hat darauf.

(19:58 - 20:09)
Und man kann auch nicht alles überladen. Und es gibt auch gewisse Sachen, die gehen dann nicht so schnell. Beispielsweise beliefern Bereiche die Zertifizierung von Medizintechnik.

(20:09 - 20:25)
Nicht nur, aber Medizintechnik, Automotive, E-Mobility. Das sind alles Sachen, die haben Zyklen von 2 bis 5 bis 7, 8 Jahre. Und Medizin ist wieder länger.

(20:25 - 20:34)
Genau. Aber Pharmazie noch länger. Wenn man an Diagnostikgeräten oder an wirklich Pharmazie arbeitet, die haben ja viel längere Zeiten dann auch.

(20:35 - 20:49)
Da musst du ja durch Trials. Und da gibt es ja zig Etappen, die man da durchgehen muss. Aber auch für Elektroniken, die auch an den Menschen kommen oder wo der Mensch auch damit interagieren muss, da muss eine gewisse Sicherheit gegeben sein.

(20:49 - 21:04)
Und da kann man nicht sagen, wir bringen jedes Jahr eine neue Version eines bestimmten Geräts raus. Das kannst du einfach nicht machen, weil Ressource, du hast nicht endlos viel Ressource, auch nicht als Großunternehmen. Ja klar, du musst dir ja auch da so ein bisschen eine Agenda legen.

(21:04 - 21:27)
Was macht Sinn, welche Produkte überarbeite ich wann? Genau. Und dann, welche Produkte führe ich zu welchem Zeitraum ein? Hat sich die Entwicklung und die Produktionskosten überhaupt amortisiert? Habe ich es wieder reinbekommen? Das ist ja auch eine Frage. Klar.

Das ist halt ganz oft der Step davor. Danach muss der Kunde das Produkt, das dann fertig ist, natürlich auch verkauft bekommen, ganz klar. Weil die Kosten sich in gewisser Weise wieder reinholen, sage ich mal.

(21:27 - 21:35)
Genau. Das muss man aber auch beachten. Auch als Entwicklungsdienstleister oder wir sehen uns mehr als Entwicklungspartner tatsächlich.

(21:36 - 21:54)
Auch wenn wir natürlich per Definition Dienstleister sind. Aber ich denke, es ist so, dann ist das Verhältnis besser. Auf Augenhöhe besucht man das nicht nur, man bekommt einfach das hingeklatscht, sage ich jetzt mal ganz plakativ, sondern man gibt Tipps, man ist auf Augenhöhe und macht das gemeinsam.

(21:54 - 21:59)
Das geht nicht anders. Das geht wirklich nicht anders. Dann kommt man nicht voran, man macht sonst ganz viele Fehler.

(22:00 - 22:23)
Im Konsumentenbereich kann man diese Fehler noch relativ gut ausmerzen, weil da kann man mehrere Versionen fahren, da kann man noch relativ, ich sage relativ nicht immer, aber relativ. Kommt drauf an. Kann man dann noch irgendwie per Softwareupdate oder sonst was, kann man es beheben, aber bei wirklich funktional sicherheitskritischen Sachen oder auch... Da muss der erste Anlauf eigentlich schon fast sitzen.

(22:23 - 22:30)
Genau, da muss der Anlauf sitzen, da muss die Kommunikation mit dem Kunden sitzen. Moment, Entschuldigung. Alles gut.

(22:33 - 23:06)
Zu viel geredet, oh Gott. Da muss die Kommunikation mit dem Kunden sitzen, da muss sitzen, dass die Prozesse an den Kunden angepasst sind. Man muss sich größtmöglich integrieren, man muss die größtmöglichen Hürden von den Teams zueinander beheben, weil manchmal arbeiten die Teams in ganz anderen Ländern oder auch Städten oder Zeitzonen.

(23:07 - 23:19)
Und da muss man natürlich auch zusehen, dass man mit allen auch zurechtkommt, dass man mit denen arbeiten kann. Und da kann man sich nicht einfach darauf verlassen, ja, ich liefere meine Komponente und das wird schon. Vielleicht da auch noch eine tiefe gehende Rückfrage.

(23:20 - 23:37)
Ihr macht ja nicht nur die reine Entwicklung, ihr hilft auch teilweise die Prototypen zu entwickeln oder entwickeln die für eure Kunden. Wo ist da so der Mehrwert auch in diesem ganzen Thema? Prototypen, ein Immenser. Und zwar für Großunternehmen wie folgt.

(23:37 - 24:02)
Die haben wirklich sehr stringente Prozesse, die sich verlaufen müssen. Und es gibt natürlich für gewisse Sachen, besonders wenn sie neu sind, wenn es neue Standards gibt, wenn es neue Technologien gibt oder wenn es bereits etwas gibt, was man angepasst haben möchte, aber was später auch IP geschützt werden muss oder sogar patentisierbar werden muss. Dann muss man natürlich auch schauen, dass man eine gewisse Erprobung macht.

(24:02 - 24:12)
Man muss wissen, ein Proof of Concept. Ich meine, selbst jedes Startup, was irgendwie ein Invest haben möchte, muss mindestens nachweisen können, dass es funktioniert. Im Großunternehmen sieht es auch nicht anders aus.

(24:12 - 24:24)
Die müssen ihrer Business-Einheit nachher erklären können, das warmen wir an. Und wir haben bereits erste Tests gemacht und sie waren erfolgreich. Wir haben technisch das und das und das umsetzen müssen.

(24:25 - 24:54)
Und das schafft dann nochmal einen ganz anderen Mehrwert für das Unternehmen. Man kann das Unternehmen nachher natürlich auch zu Recht dann sagen, wir haben es bereits erprobt, es funktioniert. Und jetzt mal zwischen uns, wenn Research and Development, wenn eine Vorentwicklung, auf gut Deutsch, wenn das nicht gemacht wird, wenn man sich direkt in die Hauptentwicklung reinschmeißt, dann arbeitet man meistens viel, viel, viel, viel länger dran.

(24:54 - 25:10)
Weil diese Grundlagen, nicht Forschung, aber diese Grundlagenarbeit, die muss gemacht werden. Und da muss man natürlich auch ein Gespür dafür haben, was mindestens benötigt wird, um einfach nur den Use Case aufzeigen zu können. Da muss man auch kreativ werden manchmal.

(25:11 - 25:22)
Es gibt manchmal so ganz, es gibt manchmal so Probleme, wo man einfach nicht weiß, auf welche Art löst man das. Und dann versucht man sich durch. Das ist halt wirklich Trial and Error.

(25:22 - 25:32)
Und das kann man in der Hauptentwicklung nicht machen, weil die Hauptentwicklung kostet. Die Produktion kostet danach ja auch. Aber die Hauptentwicklung kostet natürlich genauso viel.

(25:32 - 25:46)
Klar, und wenn du jetzt nochmal eine weitere Partei drin hättest, die sich nur um den Prototypen kümmert und nicht um, ich sage mal, das Konzept, die Basis, dann wird es natürlich auch noch viel komplexer. Ja, das muss ja auch miteinander kommunizieren. Also wir haben den Vorteil, dass wir ganz gut mit unseren Kunden auch kommunizieren können.

(25:46 - 26:00)
Die haben eine Vorstellung, was es auch nachher werden soll. Die sagen uns das dann auch. Und dann ist das meistens dann auch so eine Sache von, wir müssen jetzt in unserem Kopf genauso weiterdenken wie die.

(26:00 - 26:08)
Weil sie kennen ihre Domäne. Wir können jetzt nicht sagen, ja, du kommst aus dem Medizintechnikbereich, aus dem Energy-Bereich. Ich sage dir jetzt, wie es läuft.

(26:08 - 26:18)
Das kannst du nicht machen. Die Kunden wissen, was sie brauchen. Und das sind wahnsinnig gute Ingenieure und Experten oder Projektleitende, die dann da sitzen.

(26:18 - 26:32)
Das sind jetzt nicht irgendwie Leute, die das zum ersten Mal machen. Also da würde ich auch niemals so rangehen und niemandem empfehlen, so ranzugehen. Das ist immer auf Augenhöhe.

(26:33 - 26:44)
Weil wir haben eine gewisse Expertise, die in ihrer Domain stecken. Sie haben eine Expertise. Wir arbeiten dann quasi wie Teammitglieder, wie ein eingegliedertes Team damit.

(26:44 - 26:55)
Und wir sehen dann zu, dass wir dann auch größtmöglich Unterstützung bieten. Und das muss dann auch auf Augenhöhe passieren. Weil ansonsten macht man ganz, ganz grobe Fehler.

(26:55 - 27:00)
Und das passt auch wieder zum Partner. Genau, genau. Also man muss partnerschaftlich arbeiten.

(27:00 - 27:04)
Das geht sonst nicht. Auch in der Entwicklung. Besonders in Projekten, ich gebe dir ein Beispiel.

(27:05 - 27:21)
Besonders in Projekten, wo dann mehrere Firmen, mehrere Unterauftragnehmer, weil wir sind ja beispielsweise für größere Unternehmen, wenn die sich jetzt in so einem Konsortium befinden, mit anderen Firmen, die dann eine gemeinsame Entwicklung machen wollen. Sei es eine Chipentwicklung, sei es eine neue Produktentwicklung, sei es ein Forschungsprojekt. Das kann alles möglicher sein.

(27:23 - 27:31)
Da sitzen ja nicht nur wir als Peucon für unseren Kunden mit am Boot. Da sitzt vielleicht der Unterauftragnehmer von einer anderen Firma. Ja klar, das ist so ein Blumenstrauß.

(27:31 - 27:46)
Genau, und dann sitzt man da plötzlich mit zwölf, dreizehn Firmen in so einem Zusammenschluss. Und so ein Projekt ist in sechs Monaten nicht abgewickelt. Wir haben Projekte, wenn wir ganz, ganz, ganz, ganz, ganz von vorne anfangen, dauern die Projekte zwei bis fünf Jahre.

(27:48 - 28:05)
Natürlich inklusive, das Ding ist natürlich danach noch irgendwie inklusive Produktion, Markteinführung, dauert noch seine Zeit. So klappt es in verschiedenen Phasen. Aber man möchte ja auch nicht, dass es schiefläuft.

(28:05 - 28:29)
Aber man muss natürlich auch dazu sagen, bei so hochkomplexen Projekten, dann sitzt man da eine ganze Weile. Herr Kleerer, lass uns weitermachen. Wenn so ein neues Projekt bei euch startet, was sind so die meisten, was tritt so meistens als Problem bei euch, Machtproblem nicht, als Herausforderung? Was sind die typischen Herausforderungen, die kommen? Unterschiedlich.

(28:30 - 28:43)
Erstmal das Organisatorische. Ich meine, da muss man sich erstmal kurzschließen, weil das ist, ingenieurstechnisch kriegt man, ich sag immer, ingenieurstechnisch kriegt man meistens immer alles gelöst. Ich sage meistens immer, weil wir haben ja gerade eben auch über Physik gesprochen.

(28:44 - 29:01)
Es gibt gewisse Sachen, da kommt man auch nicht über die Physik hinweg. Ja, das stimmt allerdings. Aber die Hauptherausforderung, dann wirklich erstmal das Projekt dann insofern zu starten, dass man schnell reinkommt.

(29:01 - 29:11)
Und das kriegen wir mittlerweile ganz gut hin. Also das haben wir auch als Unternehmen gut gelernt. Was man aber auch machen muss, um ehrlicherweise wirklich komplett ehrlich zu sein, was wir auch bei anderen Firmen sehen.

(29:12 - 29:37)
Sie definieren ihre Scopes meistens nicht korrekt. Ich sage meistens, weil man muss natürlich auch zusehen, dass man weiß nicht, wo die Reise hingeht. Genau, man weiß nicht, wo die Reise hingeht, aber man muss ungefähr abschätzen, was man bereit ist zu tun, was man nicht bereit ist zu tun oder was man tun kann, was man nicht tun sollte.

(29:39 - 29:57)
Das weiß man ja ungefähr. Und dann sollte man die Sachen auch so definieren und dem Kunden auch sagen, hey, wenn es etwas gibt, was im Nachgang nicht wie wir beide geschätzt haben, das läuft, dann müssen wir uns nochmal an den Tisch setzen. Das kann nämlich immer passieren.

(29:57 - 30:04)
Klar, man hat eine Anforderung und es geht dann in eine andere Richtung. Da muss man sagen, okay, dann müssen wir darüber sprechen. Vielleicht auch, wir brauchen mehr Zeit.

(30:05 - 30:18)
Das kann auch ein Aspekt sein. Es gibt sogar gewisse Sachen, wenn man in der Entwicklung noch steckt, dass sich irgendwie Regulierungen ändern. Was machst du dann? Klar, ich muss mich an die neue Regulierung richten, die es für mich bindet, wenn das Produkt dann auf den Markt kommt.

(30:18 - 30:54)
Genau, solche Sachen. Und dann ist das natürlich, da kann weder das Unternehmen, also unser Kunde was, noch wir, aber da muss man sich auch hinsetzen und sagen, okay, wie lösen wir das Problem? Oder gewisse Sachen, da muss man noch Sachen vorher klären, wie Gewährleistung. Was ist in der Gewährleistung drin? Was ist nicht da drin? Wenn beispielsweise so Probleme passieren, es kann ja sein, jetzt Konglomerat wieder als Beispiel, Firma XY von einer anderen Firma oder wir, wir haben Fehler gemacht, was passiert dann? Weil dann ziehen die anderen mit, weil es ist ja ein Produkt, wir beliefern eine Komponente oder die liefern eine Komponente.

(30:54 - 31:13)
Das ist auch schon mal passiert. Wir hatten eine andere Firma beispielsweise, einen gravierenden Fehler gemacht und da mussten alle nachziehen. Das hat, ich glaube, drei Monate hat das gedauert, bis dieser Fehler wieder drin war.

(31:13 - 31:22)
Und das sind dann drei Monate, die man dann an die Entwicklung ranhängt. Drei Monate, wo die Produktion später anfängt. Das leitet perfekt zu meiner nächsten Frage.

(31:23 - 31:49)
Die wäre nämlich, was sind so die Punkte, wo Projekte am meisten Zeit verlieren? Solche Sachen. Solche Sachen? Ja, also wirklich Kommunikation oder es kann ja Fehler passieren, aber da muss man auch dazu stehen und das hilft auch nicht zu kaschieren. Da muss man wirklich sehr, sehr, sehr schnell reagieren und man muss auch in Unternehmen, aber auch in Teams eine Fehlerkultur haben, wo man, wo man direkt testen.

(31:49 - 31:57)
Nicht an der Tischkehre. Ja, das muss man klären. Also auch, man kann auch nicht sagen, oh ja, das ist ein Feature, ist ja mal so ein gängiger Informatikerwitz.

(31:57 - 32:07)
Dass man gewisse Bugs als Features verkauft. Ich halte nichts von der Praxis, bin ich ehrlich. Da sage ich lieber, das ist ein Bug, das ist schief gegangen, geht auf unsere Kappe, tut uns leid.

(32:08 - 32:27)
Auch die Verantwortung übernehmen. Genau, genau, weil das ist ganz wichtig, besonders im Ingenieurstum. Ich meine, wir beliefern, ich glaube, ich habe das heute zehnmal, glaube ich, gesagt, wir beliefern teilweise Komponenten, die wichtig für Leib und Leben sind, funktionale Sicherheit beinhalten, die teilweise mit Echtzeit zu tun haben.

(32:28 - 32:48)
Wir können nicht einfach uns hinstellen und sagen, oh ja, Feature, haha, das geht einfach nicht. Ja, da muss notige Anstafflichkeit da sein. Genau, das muss auch, es hat auch sehr viel mit Respekt gegenüber dem Prozess zu tun, gegenüber auch den Leuten, die daran arbeiten, weil Fehler kann man beheben, sofern die Physik es wieder erlaubt.

(32:48 - 33:09)
Ja. Aber was man nicht wieder hingebogen bekommt, ist das Vertrauen von Leuten. Und das ist immens wichtig in Ingenieursumfelden, dass die Leute miteinander wieder reden können, wieder arbeiten können oder bereit sind überhaupt dann das nächste Projekt oder das Folgeprojekt miteinander zu machen.

(33:09 - 33:20)
Das ist wahnsinnig wichtig. Ich habe ja gerade noch, glaube ich, das war, da hatten wir ein Gespräch davor, bei einem Kunden, seit 92 ist der Kunde bei uns. Ich bin 96 geboren.

(33:20 - 33:25)
Der Kunde ist länger bei Polkonda, als ich überhaupt beim Leben bin. Ja. Und genau wegen solchen Prinzipien.

(33:25 - 33:45)
Und deswegen mag ich das halt auch, hier zu arbeiten oder mit den Kollegen hier zu arbeiten. Es ist, ich habe auch sehr viel als Mensch lernen können, die Fehlerkultur ist immens wichtig. Und wenn die fehlt an einer Stelle, das ist gravierend und massivst, da muss man auch Nein sagen oder sagen, okay, das funktioniert nicht.

(33:46 - 33:53)
Also das ist wirklich wichtig, da scheitert das. Ansonsten kann technisch immer mal was schief gehen. Vielleicht hat man irgendwie vergessen, eine Komponente.

(33:55 - 34:04)
Ja, Qualitätsprobleme, muss gar nicht deine Schuld sein. Ja, oder Qualitäts, genau, genau. Oder irgendwer, vielleicht fällt irgendwo ein Kondensator oder irgendwie ein Lötprofil, es war schief gelaufen.

(34:05 - 34:16)
Kann ja auch immer sein. Ich meine, kommt ja auch vor, dass man vielleicht auf dem Schaltplan irgendwie falsch geguckt hat oder es fehlt ein Testpunkt irgendwo. Oder da kann... Wie wir es hatten, Regulatorikveränderungen.

(34:17 - 34:41)
Regulatorikänderungen, vielleicht kommt mal was vom Produzenten falsch zurück oder vielleicht hat man irgendwie einen Wert falsch interpretiert und das kann alles Mögliche sein. Aber da muss man natürlich auch erst mal die Ursache finden und dann die Ursache auch kommunizieren. Und jetzt für die andere Seite, wie gelingt es einem, wenn man sagt, man will wirklich im kürzesten Zeitrahmen entwickeln? Naja, wie man es auch in der Software machen würde.

(34:42 - 34:47)
Man testet ständig. Also man muss das begleitend machen. Also das geht nicht anders.

(34:48 - 35:05)
Oder vielleicht so, wie man es vielleicht aus der Software entwickelt mit dem Wasserfallmodell, dass man schon mehrere Bereiche gleichzeitig laufen lässt, um Zeit einzusparen. Wenn es vielleicht auch mal kritisch ist, dass es halt schnell ein Update geben muss. Je nachdem, was das ist, ich würde da vielleicht... Das kommt immer auf das Projekt drauf an.

(35:05 - 35:13)
Es gibt Projekte, die muss man agil anfassen. Also man kann nie immer so richtig sagen, ah, ich arbeite nach dem und dem Modell. Das habe ich zumindest gelernt.

(35:17 - 35:40)
Einige Unternehmen oder ich sage mal Kunden, die fangen zwar in einem wirklich sehr stringenten, ich sage mal V-Modell, Wassermodell, wie auch immer, fangen sie an. Aber zu gewissen Zeiten, wenn dann abgekoppelt wird, weil wir arbeiten beispielsweise mit Verkapselung. Den Prototypen kannst du nicht nach einem stringenten Muster entwickeln.

(35:40 - 35:57)
Das muss viel schneller laufen. Du brauchst viel kürzere Entwicklungs- und Testzeiten. Das kann auch mal passieren, dass du, bis die Technik sitzt, dass du vielleicht drei Iterationen an Prototypen erstmal durchmachen musst.

(35:57 - 36:12)
Das kann durchaus vorkommen. Und dann muss man natürlich auch mit dem Kunden eng das machen. Also das macht man nicht, indem man sagt, okay, ich entwickel nach meiner Nase, weil das kannst du einfach nicht machen.

(36:12 - 36:32)
Und da ist man dann natürlich manchmal schneller, manchmal ungewollt langsamer. Aber es ist nichtsdestotrotz schneller, als wenn man wirklich komplett ausrollt und sagt, ja, erstmal Recherche, erstmal das, erstmal jenes. Das dauert dann immer auch seine Zeit an.

(36:32 - 36:50)
Fertig? Nee, noch nicht. Genau, vielleicht da auch nochmal so die Frage, wie gelingt es dir, gerade wenn du so ein bisschen aufs Tempo drückst, trotzdem, dass die Qualität weiter stimmt? Oder euch? Durch kontinuierliches Testing. Ich meine, ich habe ja unsere Testgeräte.

(36:50 - 37:12)
Es gibt so gewisse Testgeräte, die bauen wir für unsere eigene Entwicklung. Wenn es jetzt wirklich ein Groß-Groß-Groß-Projekt ist, dann haben wir auch unsere eigenen Testadapter und unsere eigenen Test-PCBs. Und die Kunden haben immer die Möglichkeit, diese Testumgebung einzukaufen für ihre spätere Produktion, aber auch für die Validierung.

(37:12 - 37:19)
Das bieten wir den Kunden an. Wir sagen auch zum Kunden, hey, das gehört zum Paket. Ihr könnt es nachher haben, wenn ihr es wollt.

(37:19 - 37:27)
Wir schicken euch das dann zu. Und wenn ihr das haben wollt, könnt ihr es. Wenn nicht, dann sei es drum.

(37:27 - 37:34)
Das ist dann teilweise, also wir testen wirklich kontinuierlich. Wir proben kontinuierlich. Wir messen kontinuierlich.

(37:35 - 37:50)
Klar, dann fällt auch der Urhegelmäßigkeit einfach schneller auf. Ja, natürlich. Ich meine, wenn ich wochenlang, stell dir mal vor, ich habe wochenlang entwickelt, Schaltpläne gemacht, irgendwas, ich sage nicht wochenlang, aber sagen wir mal, drei Monate lang entwickelt, ohne richtig zu testen.

(37:50 - 38:02)
Das wäre ein absurder Super-GAU, wenn Ende dieser drei Monate herauskommt, dass dieser Prototyp überhaupt gar nicht standhalten kann. Ja, ich denke da immer an die Entwicklungen, die dann nicht ins Gehäuse gepasst haben. Solche Sachen.

(38:02 - 38:20)
Also ja, das Gehäuse kann man natürlich ein bisschen größer dann nachher bauen. Aber wenn jetzt beispielsweise das PCB doch kleiner werden sollte, da muss man natürlich nochmal Schaltplanen alles drum drehen. Und was weiß ich, vielleicht Bauteile rauskicken, die vielleicht unnötig gewesen sind, Platine kleiner machen, alles zusammenpacken.

(38:21 - 38:30)
Vielleicht fliegt dann auch hier und da ein größeres Bauteil raus. Das muss man natürlich alles schauen. Und dann muss man natürlich auch schauen, wo es nachher reinkommt.

(38:31 - 38:52)
Man muss wirklich immer das Gesamtsystem überblicken. Also man kann nicht immer sagen, ah ja, wir machen genau XY, sondern wie es ein Softwerker machen würde, kontinuierlich testen, aber auch gezielt testen. Das ist keine befriedigende Antwort für viele, aber es ist halt nun mal die Wahrheit.

(38:53 - 39:18)
Ja, das war vielleicht auch ein bisschen stiefmütterlich behandelt, aber es ist unabdingbar. Es ist unabdingbar. Was merken wir aber auch, wenn wir Kunden haben, die sind dann teilweise nicht unsere Großkunden, aber es ist nicht alle, aber es gibt dann manche, die sagen dann beispielsweise so im Mittelstand, wenn die dann ganz wenig Zeit haben, die müssen schnell ran, und dann sagen die, ja, braucht ihr Tester? Also sie sagen, ja, reduzieren wir Teststunden.

(39:20 - 39:41)
Ja, können wir machen. Ja, und braucht man eigentlich so viel Dokumentation? Ich meine, wir werden trotzdem dokumentieren, aber... Ich weiß nicht, ob wir dann übrigens uns eigenes Fleisch schneiden. Ja, na ja, besonders wenn du dann nachher irgendwie dich da verantworten musst, weil ich bin ja nicht der... Ich bring's ja nicht in den Verkehr.

(39:42 - 39:47)
Den Verkehrbringer bist du, mein Kunde. Hallo. Musst du auch sichergehen, dass alles ordentlich funktioniert.

(39:48 - 40:00)
Vielleicht auch gleich hinterher eine ketzerische Frage. Wann macht es denn eigentlich wirklich Sinn, mit einem externen Dienstleister für die Entwicklung zusammenzuarbeiten? Wann macht man es besser selber? Also mit uns macht das immer Sinn. Hallo? Nein.

(40:08 - 40:27)
Es kann grundsätzlich nicht schaden, eine äußerliche Perspektive zu haben, aber wenn man beispielsweise ganz klein ist und bereits sowieso alles selber macht, dann ergibt es keinen Sinn, jetzt so eine Firma wie uns da irgendwie mit an Bord zu holen. Oder wenn man sagt, ja, okay, eigentlich... Oder ich habe gar keine Ahnung in dem Bereich. Ja, genau.

(40:28 - 40:41)
Oder ich habe kein... Es muss auch betriebswirtschaftlich daran gehen. Wenn man das jetzt auch nicht irgendwie stemmen kann, dann muss man auch sagen, okay, das funktioniert in der Sache nicht. Entschuldigung.

(40:42 - 41:17)
Für Großunternehmen oder für... Ich sage mal, nehmen wir mal an, Ressource ist da. Da würde es Sinn ergeben, wenn man beispielsweise ein Team hat, vielleicht nur aus Biochemikern, und man braucht jetzt plötzlich eine technische Komponente oder einen Testaufbau oder einen Versuchsaufbau oder man braucht... Ich meine, diese Firma ist ja im Bereich Connected, also Telekommunikation, RF und allem Möglichen groß geworden. Wenn jetzt solche Geschichten natürlich auftauchen, dann wäre es natürlich nicht schlecht.

(41:17 - 41:40)
Ich meine, Uwe ist beispielsweise eines der Experten in Deutschland auf dem Bereich DECT, der hat einen wahnsinnig guten Wissensstand über Connectivity, Wireless, Wired, auch die Kollegen, die wir haben. Manchmal braucht man schon, glaube ich, auch dieses temporäre Wissen. Das macht nicht Sinn, dafür Mitarbeiter anzustellen.

(41:40 - 41:55)
Ja, genau. Manchmal muss man sich das temporär einkaufen, weil es sind dann Komponenten. Oder wenn man beispielsweise eine gewisse Expertise gar nicht benötigt, man braucht nur die Komponente, wie du sagst, dann ergibt es Sinn, dann jemanden zu haben, der diese auch entwickeln kann.

(41:55 - 42:18)
Oder wenn man bereits sagt, okay, wir haben viel zu wenig Leute, wir brauchen Support, aber wir brauchen Support, der auch schnell geht, in Anführungsstrichen schnell geht. Oder manchmal braucht man auch einfach einen Entwicklungspartner, der auch wirklich mit anpackt. Es gibt Projekte, da weiß man im Vorhinein, das wird schwierig.

(42:18 - 42:27)
Und da braucht man auch Leute, die wirklich schwierig können. Und da ergibt es dann so eine Firma wie Polycon dann auch tatsächlich, um dran zu ziehen. Verstehe.

(42:27 - 42:43)
Gibt es da auch manchmal so das, dass einfach euer Kunde die völlig falsche Erwartung hat, was eure Rolle ist oder was ihr leisten könnt und was nicht? Das sagen wir im Vorhinein. Also wir definieren das auch meistens schriftlich. Dann gibt es nicht dieses Erwachen.

(42:43 - 43:00)
Nein, aber wir lernen unsere Kunden auch während den Projekten kennen. Beispielsweise die Langzeitkunden, die wissen, was wir können, die wissen, was sie uns... Was unsere Kompetenz ist und was nicht. Genau.

(43:00 - 43:13)
So neue Kunden, wenn die das noch nicht wissen, muss man natürlich mit denen erst mal ein paar Runden drehen, ein paar Gesprächsrunden drehen. Man muss dann schauen, Referenzen zeigen, erklären. Die müssen dann auch verstehen, was sie auch von uns erwarten können.

(43:13 - 43:29)
Aber grundsätzlich definieren wir, was auch immer wir definieren, auch schriftlich nieder für den Kunden. Das wollen die natürlich dann auch. Und dann gibt es dann auch eine maximale Dokumentation, die wir dann auch versuchen anzugehen.

(43:29 - 43:41)
Das mögen einige Leute nicht, das kann ich verstehen. Aber dann weiß jeder, wo er oder sie steht. Und das ist dann halt meistens viel bequemer dann zu schauen, wo man... Man hat einen Rahmen geschaffen.

(43:42 - 44:04)
Ja. Ja, vielleicht auch noch so in die Richtung, wenn wir jetzt wieder ein bisschen rausgehen und auf den ganzen Elektronik- und Entwicklungsmarkt zu gucken. Was denkst du, was wird sich die nächsten Jahre verändern? Wenn man sich die Trends anguckt, so KI und Embedded-KI, vor allem aber auch Connectivity.

(44:04 - 44:22)
Im Automotive-Bereich hat man jetzt angefangen, auch Architekturen zu ändern. Man hat auch angefangen, in anderen Bereichen zu sagen, okay, wir wollen viel mehr Machine-to-Machine oder Vehicle-to-Vehicle-Connectivity oder Everything-to-Everything. Da muss man auch immer bedenken, das ist ja nicht nur ein Software-Trend.

(44:22 - 44:33)
Die Hardware muss das ja auch mitstemmen können. Vielleicht ist auch zu viel Fokus auf das Software-Trend in den letzten Jahren gewesen. Hat die Hardware so ein bisschen nix liegen lassen? Das ist auch das Ding, was wir immer intern auch diskutieren.

(44:34 - 44:51)
Software lässt sich gut skalieren, für gewisse Sachen, aber nur so lange, wie es auch Hardware gibt, auf die man die Software auch skalieren kann. Das vergessen einige dann immer. Wir haben manchmal Gespräche, beispielsweise auch im Bereich Ladeinfrastrukturen oder Ähnliches.

(44:53 - 45:05)
Da gibt es beispielsweise oder fragen wir auch, wie skaliert ihr denn? Wenn es jetzt nur Software ist, sagen die, ja, dann sind wir darauf angewiesen, dass es Ladesäulen gibt. Jetzt als Beispiel. Konkretes Beispiel.

(45:06 - 45:16)
Dann müssen diese Hardware, die muss dann auch irgendwo erst mal sein. Die muss verbaut sein, die muss bereits operabel sein. Und aber auch so Trends wie 5G, 6G.

(45:19 - 45:28)
5G haben wir ja schon. Aber 6G oder Standards wie IoT-Standards. Und es wird ja immer komplexer.

(45:28 - 45:35)
Da muss die Hardware ja auch mitmachen können. Und da muss man ja auch natürlich schauen, wie das in die Richtung geht. Oder ganz wildes Beispiel Robotik.

(45:35 - 45:58)
Nicht wild in dem Sinne, aber wir reden mittlerweile über Humanoid Robotics, wo wir bereits nicht nur Sachen haben, wie nur den Roboter. Die können mittlerweile dann auch, die können mittlerweile auch, oh, schieß mich tot. Da gab es dieses eine Video.

(45:58 - 46:01)
Das ist ein Tanzvideo. Dieses Tanzvideo. Wahnsinn, oder? Ja.

(46:02 - 46:11)
Oder da trifft nämlich mehrere Sachen. Da trifft Mechanik auf Elektronik, auf Software, auf Sensorik. Da muss alles miteinander wechselwirken.

(46:12 - 46:26)
Da kann man nicht einfach sagen, ich schmeiß eine Platine und das ist fertig. Da muss man alles Mögliche beachten. Da hat man nicht nur plötzlich, früher war das dann okay, vielleicht hat man ein Telefon entwickelt, dann hat man irgendwie die Platine entwickelt und dann vielleicht noch das RF-Modul und ein bisschen Software dazu.

(46:27 - 46:33)
Es ist heute viel, viel, viel komplexer. Ja, es geht alles Hand in Hand. Die ganzen Schnittstellen müssen passen.

(46:33 - 46:49)
Wir müssen viel, viel mehr interdisziplinärer werden. Und wir sind auch mittlerweile viel interdisziplinärer, auch in dem, was wir tun oder was wir beachten müssen. Deswegen ist es dann auch Ich habe die Herausforderung, da am Ball zu bleiben.

(46:50 - 47:03)
Nicht nur jetzt für dich, so aus der Geschäftsführungsperspektive, sondern auch, dass die Mitarbeiter die neuen Standards kennen, die neuen Protokolle, aber auch einfach ihre Fühle aussprechen. Was kommt da Neues? Und auch offen dafür sein. Ja, das stimmt.

(47:03 - 47:20)
Da muss man aber auch, ehrlicherweise sagen, beispielsweise wenn man jetzt, so eine Firma wie uns, wir haben ja auch unsere Zulieferanten, wie beispielsweise Würth Elektronik. Die sind, ich gebe die als Beispiel, weil ich mag das wirklich, die Würth als Beispiel zu geben. Die sind nämlich wirklich wahnsinnig hinterher.

(47:21 - 47:38)
Die geben dann auch Workshops, auch technische Workshops für Ingenieure oder auch für die Geschäftsleitungen oder auch für Einkaufsmenschen. Die sind dann auch immer weit, weit, weit hinterher, den Leuten auch zu sagen, welche neuen Baukomponenten es gibt. Und das ist auch wichtig zu wissen, was man verarbeiten kann.

(47:39 - 47:45)
Da auch einfach die Fühle in Richtung des Netzwerkes auszustecken. Auch die Lieferanten. Man muss ja nicht immer das Rad selber neu finden.

(47:45 - 47:50)
Vielleicht gibt es auch da mal einen Puls, den man aufnehmen kann. Genau, genau. Deswegen, das ist ja auch so das Ding, da muss man auch gucken, was es gibt.

(47:50 - 48:23)
Gibt es vielleicht ein neues Modul? Gibt es vielleicht einen neuen Chip irgendwo? Gibt es vielleicht irgendwie eine andere Firma als die, die man vielleicht präferiert, die vielleicht ein gewisses Problem besser gelöst hat? Oder ist die Architektur vielleicht sinnvoller für eine gewisse Anwendung? Man muss ja nicht, man hat seine Präferenzen natürlich, aber da muss man auch natürlich sich weiterentwickeln. Und man muss halt immer wirklich um die Sache herum entwickeln. Da kann man jetzt nicht sagen, aber meine Präferenz, weil das funktioniert so nicht.

(48:23 - 48:33)
Genau, auch diesen Blick einfach auf die anderen Subsystemmethoden, die einfach auch Wechsel wirken. Ja, das ist massivst wichtig in solchen Sachen. Sonst kommt man nicht voran.

(48:34 - 48:55)
Aber auch so Sachen wie Wissenstransfer von der Wissenschaft auf Wirtschaft, das ist immens wichtig. Und auch wenn dann vielleicht der eine oder andere Mitarbeiter, ich spreche mal von Obsolescence Management, obsolet wird, der geht in Rente, auch dann das Wissen wieder zu transferieren, im Unternehmen zu behalten, aber auch auf Nachfolge, jüngere Generationen zu übergeben, das ist nicht einfach. Nee, das ist es nicht.

(48:55 - 49:29)
Wir haben aber eines der Privilegien, dass wir Mitarbeitende haben, wir haben teilweise Leute, ich hatte dir das ja auch erzählt, die 20, 30 Jahre mit uns gearbeitet haben, die in Rente gegangen sind, die sind dann immer wieder offen zu sagen, wenn es da irgendwas gibt, ich komme mal vorbei oder ich helfe da mal aus. Ja, vielleicht wenn die Dokumentation zwar klar ist, aber es geht ja noch ein Füßchen schneller, wenn man mal mit demjenigen, der es entwickelt hat, sprechen kann. Genau, aber nee, aber auch für Sachen, wo man vielleicht sogar Expertise benötigt, die vielleicht etwas, ich sage mal, klassischer ist, als das bei Analogkomponenten oder so.

(49:30 - 49:40)
Ja, das wird nicht mehr gang und gäbe. Genau, wenn da jetzt ein Kunde kommt und sagt, ja, wir brauchen eine gewisse Analogkomponente, ich kann das nicht. Ja, es wird halt einfach nicht mehr so stark nachgefragt.

(49:41 - 50:03)
Genau, aber wenn jemals etwas ganz, ganz, ganz Spezielles ist, dann kannst du nur Hallo machen und darauf hoffen, dass da jetzt ein alter Mitarbeiter sagt, ja, ich komme vorbei. Oder du findest jemanden, der sich damit beschäftigt hat oder sonst wie. Aber es zeigt ja auch, wenn du dann zum guten Kontakt auch darüber hinaus noch hast, selbst in die Rente, das ist ja auch ein ganz tolles Signal.

(50:04 - 50:29)
Ja, da sind wir wirklich, ich glaube, da haben wir ein ganz großes Privileg und ein ganz, ganz, ganz großes Vergnügen, dass wir auch solche Kollegen dann haben, die dann auch immer wieder, die rufen auch immer wieder manchmal an und sagen, ja, was macht ihr so? Geht's gut? Können wir, können wir was tun? Ja, die können es dann auch oft, ist ja auch ihre Passion, dann auch nicht ganz links liegen lassen. Ja, das stimmt, das stimmt. Also da muss man auch natürlich auch schauen, wie man dabei ist.

(50:29 - 50:36)
Das tut mir sehr, sehr leid. Nee, vielleicht auch für die Zöger spannend. Wir hatten gerade über Wirt gesprochen, es kam ein Vertreter von Wirt gerade, deswegen eine kurze Pause.

(50:36 - 50:44)
Aber Zehra, ich denke, wir haben es ziemlich. Ja. Hat das Spaß gemacht, da auch tiefer einzu, auf mich reinzugucken.

(50:44 - 50:51)
Mal so, was ist auch bei Entwicklung besonders? Und auch so die Herausforderung fand ich sehr spannend. Danke, dass du da warst. Ja, vielen lieben Dank.

(50:51 - 51:07)
Und bleib dran, auch so in Richtung der Zuschauer, Zuhörer, folgt natürlich auch der Zehra, LinkedIn, wo man dich überall findet, aber auch natürlich Polcom und kommentiert fleißig, wie hat euch die Folge gefallen und bis zum nächsten Mal. Ja, bis zum nächsten Mal. Tschüss.