Ich erinnere mich, dass ich sehr verwirrt war, was ein OEM ist, als ich – leider – in den 1990er Jahren zum ersten Mal mit diesem Begriff in Berührung kam. Falls es Ihnen ebenfalls so geht: Es ist eigentlich ganz einfach: OEM steht für „Original Equipment Manufacturer“ (Originalausrüstungshersteller) und wird üblicherweise verwendet, um Technologie zu bezeichnen, die von einem anderen Unternehmen hergestellt wurde als dem, bei dem Sie das Produkt kaufen. Dies kann auf vielfältige Weise geschehen, aber stellen Sie sich vor, Sie kaufen einen Scanner oder eine Digitalkamera: Möglicherweise erhalten Sie dazu Software, die nicht vom Hersteller des Scanners oder der Kamera stammt, sondern von einem anderen Anbieter. Sie haben ein OEM-Produkt erworben.

Warum sollten Sie das tun?

Warum sollte ein Unternehmen so etwas tun? Ist es nicht besser, alles selbst zu entwickeln? Damit man die volle Kontrolle darüber hat, was die Software (oder Hardware) leistet? Manchmal ist das der Fall, und für manche Unternehmen wird dies zu einer regelrechten Philosophie, die manchmal als „Not Invented Here“-Syndrom bezeichnet wird. Die Möglichkeit, jeden Teil des Produkts selbst zu kontrollieren, bringt zwar Vorteile mit sich und ermöglicht es Ihnen manchmal, ein ausgereifteres Produkt oder eine bessere Benutzererfahrung zu schaffen – denken Sie nur daran, was Apple in seinem Ökosystem leistet. Doch das „Not Invented Here“-Syndrom wird nicht zufällig als Syndrom bezeichnet – es kann auch sehr schädlich sein.

Sie benötigen einen Experten

Schauen wir uns als Beispiel einmal an, was Callas leistet. Das Unternehmen verfügt über fast 30 Jahre Erfahrung mit PDF sowie mit Qualitätskontrolle, Standardisierung und Automatisierung … in diesem Bereich. Das ist seine Aufgabe. Das ist das Einzige, was es tut. Es liegt in seiner DNA.

Stellen Sie sich nun vor, Sie hätten ein Unternehmen, das ein Produkt entwickelt, für das die Implementierung von PDF-basierten Funktionen erforderlich ist. Wie würden Sie dabei vorgehen? Sie könnten natürlich von Grund auf das nötige Know-how zur Unterstützung von PDF aufbauen. Dazu benötigen Sie kompetente Entwickler, die viel Zeit in die Auseinandersetzung mit dem PDF-Standarddokument investieren (die gute Nachricht: Es umfasst heutzutage nur noch etwa 1.000 Seiten) und die die von Ihnen benötigten Funktionen implementieren.

Niemand behauptet, dass dies unmöglich ist. Tatsächlich ist es genau das, was Callas offensichtlich geschafft hat. Nur dass sie 30 Jahre Zeit hatten, ihren Code zu perfektionieren, alle kleinen Besonderheiten des Standards zu implementieren und Unterstützung für die Erstellung von PDF-Dateien hinzuzufügen, die vom Standard abweichen (Was? Nicht alle PDF-Dateien sind perfekt? 😱). Ach ja, und Code für zugrunde liegende Technologien wie Bildverarbeitung, Schriftartunterstützung und Probleme beim Farbmanagement hinzuzufügen …

Kerngeschäft

Die Entwicklung solcher Funktionen wird in Entwicklerjahren gemessen. Wie viele Jahre Würde ein einziger kompetenter Entwickler (nein, keine KI) die Unterstützung für eine Funktion implementieren müssen? Und noch ein kleiner, oft vergessener Punkt: Nein, die Tatsache, dass zehn Entwickler verkürzen die erforderliche Zeit nicht um den Faktor 10. Es ist natürlich von Vorteil, ein größeres Team zu haben – das liegt auf der Hand –, aber der Zusammenhang ist keineswegs linear.

Die entscheidende Frage – und der Grund für die Existenz der OEM-Technologie – lässt sich also wie folgt zusammenfassen: Handelt es sich bei einer Funktion um einen Kernbestandteil, und wie hoch sind die Opportunitätskosten, wenn man sie selbst implementiert, im Vergleich dazu, sie von einem anderen Anbieter als OEM-Lösung zu beziehen?

Opportunitätskosten?

Wenn Sie beschließen, jede Woche drei Stunden damit zu verbringen, Chinesisch zu lernen, geht Ihnen diese Zeit für andere Vorhaben verloren. Vielleicht möchten Sie Chinesisch sprechen können, weil Sie dorthin reisen möchten, aber Sie möchten auch lernen, wie man JavaScript programmiert, da Sie eine Beförderung im Beruf anstreben, für die diese Fähigkeit erforderlich ist. Wenn Ihre Zeit begrenzt ist und Ihnen nur drei Stunden pro Woche als „zusätzliche“ Zeit zur Verfügung stehen, lauten die Opportunitätskosten des Chinesischlernens: kein JavaScript und somit keine Beförderung.

Ja, das ist ein albernes Beispiel, aber es lässt sich sehr gut auf den geschäftlichen Kontext übertragen. Wenn Ihr Unternehmen über ein Workflow-System verfügt, das von Druckereien genutzt wird, und Sie die PDF-Qualitätskontrolle gemäß internationalen Standards wie ISO PDF/X oder den Standards der Ghent Workgroup unterstützen müssen, wie Wie Sie dabei vorgehen, ist entscheidend. Die eigenständige Entwicklung der Funktionalität ist mit Opportunitätskosten verbunden – ein Teil Ihres Entwicklungsteams (sowie Ihres Produktmanagement- und Supportteams – eine oft übersehene Investition!) wird mehrere Entwicklerjahre benötigen, um dies umzusetzen. Würden Sie hingegen OEM-Technologie (natürlich von callas) nutzen, könnten sie diese Zeit für wichtigere Kernfunktionen aufwenden.

Wie hoch sind die Kosten?

Der tatsächliche Zeitaufwand für die Unterstützung bestimmter PDF-Funktionen wird häufig unterschätzt. In einem neuen OEM-Whitepaper, das in Kürze auf der (brandneuen) callas-OEM-Website unter oem.callassoftware.com – ich werde mir das genauer ansehen und einige grundlegende Einschätzungen vornehmen. In diesem Blog genügt es zu sagen, dass selbst etwas relativ Einfaches, wie beispielsweise die Unterstützung der neuesten Spezifikationen der Ghent Workgroup 2022, einen Gesamtaufwand erfordert, der leicht bei etwa 10 bis 15 Entwicklerjahren liegt.

Ein kleiner Einblick in das OEM-Whitepaper: Kapitalrendite durch den Einsatz von callas-Technologie für die PDF-Verarbeitung im Vergleich zur Entwicklung einer PDF-Verarbeitungstechnologie von Grund auf.

Falls Sie einen ersten Blick auf dieses neue OEM-Whitepaper werfen möchten, dann Senden Sie uns eine E-Mail und wir gewähren Ihnen gerne vorzeitigen Zugang. Vielleicht halten Sie meine Einschätzungen für pessimistisch oder eigennützig (ich arbeite ja für callas, und wir bieten schließlich OEM-Technologie an), aber ich bin gerne bereit, sie mit Ihnen zu erörtern, und ich glaube nicht, dass sie zutreffen. Da ich bei den beiden führenden Anbietern von PDF-Preflight-Lösungen tätig war und als Geschäftsführer der Ghent Workgroup fungiere, wo ich 25 Jahre meines Lebens verbracht habe, halte ich meinen Respekt vor der Komplexität einer guten PDF-Unterstützung für durchaus begründet.

Warum habe ich bisher noch nichts von der callas-OEM-Technologie gehört?

Gute Frage. Möglicherweise haben Sie sogar schon damit gearbeitet. Die Technologie ist in Adobe Acrobat Pro (das Preflight-Plug-in) und im Foxit Editor integriert. Diese Technologie ist in Workflow-Systeme wie Kodak Prinergy und Xerox FreeFlow integriert. Sie finden sie auch in MIS-Systemen wie Dataline von MultiPress. callas hat derzeit über 75 aktive OEM-Partner, doch in vielen Fällen bleiben diese Integrationen weitgehend unbemerkt.

Beispiele für OEM-Partner

Manchmal liegt das daran, dass ein OEM-Partner es so belassen möchte. Warum sollte man schließlich preisgeben, wie man die Konkurrenz übertrumpft, nicht wahr? Ich glaube jedoch, dass es zum Teil auch daran liegt, dass callas ein Unternehmen aus PDF-Experten ist, die sehr stolz auf das sind, was sie schaffen, aber nicht das Bedürfnis verspüren, damit zu prahlen.

Aber nun wissen Sie ja Bescheid. Werfen Sie also einen Blick auf die Die neue Callas-OEM-Website. Werden Sie Teil der callas pdfForum und beteiligen Sie sich an den Diskussionen. Oder wenden Sie sich einfach an das OEM-Team bei callas, um ein Gespräch zu führen.

Denken Sie an die Opportunitätskosten. Wir haben diese bereits für Sie übernommen, sodass Sie dies nicht tun müssen.