Einführung
Quantum-Software umfasst Programmiersprachen, Compiler, Schaltkreisoptimierung, Fehlerminderung, Steuerungssysteme, Simulatoren, Workflow-Orchestrierung, Anwendungsbibliotheken, Ressourcenschätzung und Domänenlösungen. Einige Produkte sitzen in der Nähe eines Quantenprozessors. Andere koordinieren Quanten- und klassische Berechnungen, verwalten Experimente oder bündeln wissenschaftliche Methoden für Chemie, Finanzen, Optimierung und maschinelles Lernen. Der Transaktionsperimeter kann daher Code, Daten, Patente, Geschäftsgeheimnisse, Mitarbeiter, Kundenverträge, Cloud-Beziehungen und zukünftige Zugriffe auf Hardware enthalten.
Die zentrale Frage des Käufers ist, ob das Ziel über eine dauerhafte Fähigkeit oder eine temporäre Implementierung verfügt, die auf ein bestimmtes Gerät abgestimmt ist. Eine Schaltung, die auf zwei Plattformen ausgeführt wird, kann unterschiedliche Genauigkeit, Tiefe, Kosten und Latenz erzeugen. Ein Compiler kann Gates in einer Topologie reduzieren und gleichzeitig den Routing-Overhead in einer anderen erhöhen. Eine Anwendung kann auf den proprietären Impulszugriff, den Fehlerminderungsdienst oder die Warteschlangenpriorität eines Anbieters angewiesen sein. Ein Kundenvertrag kann eher die Forschung als ein wiederholbares Produkt finanzieren.
Die Bewertung wird schwierig, wenn die Portabilität als Ja-oder-Nein-Attribut behandelt wird. Software kann auf Quellebene portierbar und auf Leistungsebene abhängig sein. Es kann zu einer gemeinsamen Darstellung kompiliert werden und erfordert dennoch eine zielspezifische Absenkung. Es kann ein mathematisches Ergebnis reproduzieren und dabei die Geschwindigkeit, Kosten oder Genauigkeit verlieren, die den kommerziellen Anspruch stützten. Es kann auf alternativer Hardware laufen, während die Kundenbeziehung weiterhin an einen bevorzugten Anbieter gebunden bleibt.
Dieses Papier ersetzt den weit gefassten Anspruch der Hardware-Unabhängigkeit durch eine Evidenzhierarchie. Es wird gefragt, was umzieht, was umgebaut werden muss, was leistet, wer zahlt und welche Rechte übertragen werden. Das Ergebnis ist ein Transaktionsrahmen für Unternehmensentwicklungsteams, Investoren, Gründer und Berater, die den Erwerb, Zusammenschluss und strategische Investitionen von Quantensoftware bewerten.
1 Definieren Sie die Erwerbsthese
Der Transaktionsausschuss sollte darlegen, warum Eigentum erforderlich ist. Ein Käufer sucht möglicherweise nach einem Algorithmenportfolio, einem Compiler oder einer Kontrollschicht, einem Anwendungsteam, Kundenzugang, proprietären Daten, Patenten, einer Entwicklergemeinschaft oder einem Weg zur Integration von Hardware und Software. Jede These erfordert unterschiedliche Sorgfalt und erzeugt eine andere Bewertungsbrücke.
Ein Hardwarekäufer schätzt Software möglicherweise, weil sie die Auslastung verbessert, Gerätefunktionen offenlegt und Arbeitslasten anzieht. Ein Cloud- oder Plattformkäufer legt möglicherweise Wert auf Abstraktion, Orchestrierung und Verteilung. Ein industrieller Einkäufer schätzt möglicherweise einen Domänenworkflow und die Wissenschaftler, die ihn verstehen. Ein Finanzinvestor legt möglicherweise Wert auf die Möglichkeit, zwischen mehreren Hardwareanbietern zu wählen. Der Ausschuss sollte die Umsatz-, Kosten-, Zeit- oder strategischen Abhängigkeiten ermitteln, die sich durch die Akquisition ändern.
Die These sollte auch das Kontrafaktische darlegen. Zu den Alternativen können Lizenzierung, Partnerschaft, interner Aufbau, Open-Source-Einführung, Acqui-Hiring oder Warten gehören. Austauschzeit und Ausführungsrisiko sind oft wichtiger als die bisherigen Entwicklungsausgaben. Eine Akquisitionsprämie ist schwer zu rechtfertigen, wenn eine glaubwürdige Alternative das gleiche Kundenergebnis erzielt, bevor Quantenhardware kommerziell relevant wird.
Im Vorstandspapier sollten das Bewertungsdatum, die Sicherheit, die Gegenleistung, die voraussichtliche Finanzierung und das Integrationsbudget angegeben werden. Es sollte ermitteln, welcher Wert zum Zeitpunkt des Abschlusses vorhanden ist und welcher von technischen, Kunden- oder Hardware-Meilensteinen abhängt. Durch diese Trennung können Preis und Schutz den Beweisen folgen.
2 Zerlegen Sie die Hardware-Unabhängigkeit
Quellportabilität bedeutet, dass Code oder ein High-Level-Algorithmus verschoben oder übersetzt werden kann. Semantische Portabilität bedeutet, dass die beabsichtigte mathematische Operation gleichwertig bleibt. Kompilierungsportabilität bedeutet, dass das Programm auf eine akzeptierte Zwischendarstellung und einen akzeptierten Zielbefehlssatz reduziert werden kann. Ausführbare Portabilität bedeutet, dass der gesamte Workflow auf einem Ziel unter unterstützten Bedingungen ausgeführt wird.
Leistungsportabilität erhöht die Lösungsqualität, den Ressourcenverbrauch, die Latenz, den Durchsatz und die Kosten. Kommerzielle Portabilität stellt die Frage, ob der Kunde die Ausgabe akzeptiert, das Supportmodell tragfähig bleibt und die Wirtschaftlichkeit bestehen bleibt. Diese Schichten sollten separat getestet werden. Das Übergeben einer früheren Ebene begründet nicht die nächste.
Eine Zwischendarstellung kann die Sprach- und Compilerkopplung reduzieren. Microsoft beschreibt Quantum Intermediate Representation als sprach- und hardwareunabhängig und nutzt die LLVM-Infrastruktur als gemeinsame Schnittstelle. Die Zielumgebung bestimmt weiterhin die verfügbaren Gates, Kontrollfluss-, Mess-, Timing- und Laufzeitdienste. Azure Quantum-Zielprofile dokumentieren verschiedene Funktionen für bedingte Verzweigungen, Arithmetik und Schleifen. Der Käufer sollte das für jeden wertvollen Workflow erforderliche Profil testen.
OpenQASM 3 bietet ebenfalls eine umfassende Sprache für Quantenprogramme und klassische Echtzeitsteuerung. Seine Spezifikation ermöglicht es Implementierungen, die Laufzeitverarbeitung auf Vorgänge zu beschränken, die von der Hardware effizient ausgeführt werden können. Amazon Braket dokumentiert unterstützte Anweisungen, Vorgänge und Gerätefunktionen. Das Vorhandensein eines Standards verbessert daher die Interoperabilität, während wesentliche Unterschiede bei der Implementierung bestehen bleiben.
3 Erstellen Sie die Algorithmus-Beweisleiter
Die erste Ebene ist eine mathematische Spezifikation mit einem definierten Problem, Eingaben, Ausgaben und Korrektheitskriterium. Die zweite ist eine reproduzierbare klassische Simulation. Die dritte ist die Kompilierung für ein benanntes Ziel. Die vierte ist die Ausführung auf Hardware mit vollständigen Ressourcen- und Fehleraufzeichnungen. Die fünfte ist die wiederholte Leistung über Daten, Geräte und Probleminstanzen hinweg. Das sechste ist ein vom Kunden akzeptiertes Ergebnis.
Für jede Ebene sollte ein eingefrorenes Beweispaket vorhanden sein. Es sollte Quellcode, Abhängigkeiten, Umgebungsdateien, Testfälle, Daten, Seeds, Compiler-Einstellungen, Zielkennungen, Kalibrierungsaufzeichnungen, Warteschlangenzeit, Ausführungszeit, Schüsse, Nachbearbeitung, Kosten und Ergebnisqualitätsmessungen enthalten. Der Erwerber sollte in der Lage sein, die beanspruchte Ausgabe aus einer sauberen Umgebung zu reproduzieren.
Algorithmische Neuheit schafft nicht automatisch kommerziellen Wert. Eine Methode kann wissenschaftlich interessant sein, während klassische Alternativen schneller, billiger oder genauer bleiben. Eine wertvolle Anwendung sollte die verbesserte Entscheidung, die relevanten Grundlagen und die Bedingungen definieren, unter denen Quanten- oder quanteninspirierte Berechnungen die Wirtschaft verändern.
Die Leiter sollte die höchste erreichte Evidenzstufe für jedes Produkt angeben. Ein Portfolio kann ausgereifte Fehlerdiagnosesoftware, experimentelle Optimierungsroutinen und nicht finanzierte Forschung enthalten. Die Anwendung eines Umsatzmultiplikators auf alle drei verbirgt den Unterschied. Bei der Bewertung sind der erreichte Wert und der bedingte Optionswert getrennt zuzuordnen.
4 Messen Sie die Benchmark-Qualität
Benchmarks sollten eine Transaktionsfrage beantworten. Die anwendungsorientierten QED-C-Benchmarks bewerten die Ergebnistreue, die Ausführungszeit und den Ressourcenverbrauch über Algorithmen und Problemgrößen hinweg. Sie sind nützlich, weil sie über eine einzelne Hardware-Metrik hinausgehen. Der Käufer sollte dennoch prüfen, ob der Benchmark die Kunden-Workloads des Ziels widerspiegelt und ob die Implementierungsentscheidungen eine Plattform begünstigen.
Der Benchmark-Plan sollte zurückgehaltene Instanzen, klassische Baselines und mehrere Zielkonfigurationen umfassen. Es sollte Kompilierungszeit, Schaltungsbreite und -tiefe, Zwei-Qubit-Operationen, Schüsse, Warteschlangenzeit, Ausführungszeit, klassische Nachbearbeitung, Wiederholungsversuche und Gesamtkosten aufzeichnen. Die Lösungsqualität sollte definiert werden, bevor Ergebnisse bekannt sind.
Hardware- und Compilerversionen sind wichtig. Ein Ergebnis kann durch Kalibrierung, Transpilation oder Fehlerminderung und nicht durch den proprietären Algorithmus des Ziels verbessert werden. Der Käufer sollte eine Basisimplementierung über denselben Stack erneut ausführen und den Beitrag des Ziels durch Ablation testen. Der proprietäre Wert wird unterstützt, wenn die Verbesserung nach der Zugriffs- und Konfigurationskontrolle bestehen bleibt.
Die Benchmark-Governance soll eine selektive Berichterstattung verhindern. Alle versuchten Instanzen, Ausschlüsse und fehlgeschlagenen Ausführungen sollten beibehalten werden. Das Diligence-Team sollte die Parameteroptimierung verstehen und wissen, ob Kundenbereitstellungen ähnliche Fachinterventionen erfordern. Ein Ergebnis, das von manueller Optimierung durch den Gründer abhängt, kann eher einen Service- oder Talentwert darstellen als ein skalierbares Softwareprodukt.
5 Kartencompiler und Zwischendarstellungsabhängigkeit
Die Quantenkompilierung umfasst Zerlegung, Zuordnung, Routing, Planung, Optimierung, Impulsreduzierung und Laufzeitintegration. Eine Anwendung kann eine High-Level-Bibliothek aufrufen, während die wertsteigernde Leistung in Drittanbieter-Pässen oder Anbieterdiensten steckt. Der Käufer sollte jede Transformation von der Quelle bis zur ausgeführten Arbeit verfolgen.
Das Abhängigkeitsdiagramm sollte Sprachen, Bibliotheken, Zwischendarstellungen, Compiler, Plugins, Ziel-Backends, Simulatoren, Cloud-APIs und klassische Dienste identifizieren. Für jede Komponente sollten Eigentum, Lizenz, Version, Wartung, Austauschaufwand und betriebliche Bedeutung erfasst werden. Die Verfügbarkeit von Open-Source verringert ein gewisses Erwerbsrisiko und schafft gleichzeitig Governance- und Kompatibilitätspflichten.
Die Compilerleistung sollte vom Ziel getestet werden. Ein Durchgang, der die Tiefe eines Konnektivitätsdiagramms verringert, kann an anderer Stelle nur begrenzte Vorteile bieten. Dynamische Schaltkreise, Mittelschaltungsmessung, Reset, Impulszugriff und Fehlerminderungsfunktionen können den verfügbaren Algorithmus ändern. QIR-Zielprofile und Anbieterdokumentation sollten mit den tatsächlichen Anforderungen des Ziels abgeglichen werden.
Der Erwerber sollte einen sauberen Build ohne Gründeranmeldeinformationen, lokale Dateien oder nicht offengelegte Dienste reproduzieren. Es sollte Zwischenartefakte regenerieren und einen vereinbarten Benchmark ausführen. Die Reproduzierbarkeit des Builds unterstützt die Übertragbarkeit. Es allein schafft keine Handlungsfreiheit, keine Skalierung oder keinen Kundennutzen.
6 Testen Sie die Portabilität über Hardwaremodalitäten hinweg
Hardware-Modalitäten unterscheiden sich in Konnektivität, nativen Operationen, Messung, Reset, Kohärenz, Gate-Dauer, Steuerung und Warteschlangenökonomie. Supraleitende Systeme, Systeme mit eingefangenen Ionen, neutralen Atomen, photonischen Systemen und Tempersystemen können unterschiedliche Formulierungen oder Zusammenstellungsoptionen erfordern. Ein Portabilitätsanspruch sollte die unterstützte Problemklasse und das unterstützte Ziel angeben.
Die Testmatrix sollte mindestens ein primäres Ziel, eine glaubwürdige Alternative und einen Simulator oder Emulator umfassen. Derselbe Workload sollte definierte Eingabedaten und Akzeptanzkriterien verwenden. Unterschiede in der Lösungsqualität, Tiefe, Laufzeit, Wiederholungsversuchen und Kosten sollten gemessen werden. Wenn sich der Algorithmus je nach Ziel erheblich ändert, sollte der Käufer jede Implementierung als separates, gewartetes Produkt behandeln.
Der Zugang zum Anbieter kann ein versteckter Vorteil sein. Prioritätswarteschlangen, reservierte Kapazität, Kalibrierungsinformationen, technischer Support und nicht öffentliche Funktionen können zu Ergebnissen führen, die normale Kunden nicht reproduzieren können. Verträge sollten auf Abtretung, Kontrollwechsel, Preise, Daten und Kontinuität überprüft werden. Die Bewertung sollte die Software vom privilegierten Zugriff trennen.
Portabilität kann auch die Differenzierung schwächen. Wenn eine Standarddarstellung es Wettbewerbern ermöglicht, gleichwertige Algorithmen problemlos zu verschieben, liegt der Burggraben möglicherweise bei Daten, Optimierung, Workflow-Integration oder Kundenbeziehungen. Im Sorgfaltsbericht sollte angegeben werden, welche Schicht proprietär bleibt, nachdem das Programm über offene Schnittstellen ausgedrückt wird.
7 Sorgfalt geistiges Eigentum und Open Source
Der Käufer sollte jedem Produkt Patente, Urheberrechte, Geschäftsgeheimnisse, Datenrechte, Lizenzen und Mitwirkendenvereinbarungen zuordnen. Quellrepositorys sollten Urheberschaft, Commit-Verlauf, Komponenten und Releases von Drittanbietern anzeigen. Die Aufgaben von Mitarbeitern und Auftragnehmern sollten vollständig sein. Universitäts- oder staatlich finanzierte Arbeiten können mit zusätzlichen Rechten und Pflichten verbunden sein.
Open-Source-Software kann die Akzeptanz beschleunigen und eine Entwicklergemeinschaft schaffen. Es kann Wettbewerbern auch ermöglichen, Kernkompetenzen zu nutzen. Der Käufer sollte verstehen, welche Repositories geöffnet sind, welche Komponenten proprietär bleiben und ob eine Änderung der Lizenzierung rechtlich und wirtschaftlich sinnvoll ist. Copyleft-, Namensnennungs-, Hinweis-, Patent- und Weiterverbreitungspflichten sollten von einem qualifizierten Anwalt überprüft werden.
Als Material können Trainingsdaten, molekulare Daten, Kundendatensätze und Benchmark-Korpora dienen. Das Ziel sollte Herkunft, Einwilligung, vertragliche Nutzungsrechte, Aufbewahrungs- und Übertragungsrechte nachweisen. Für ein bestimmtes Projekt gewonnene Daten sind nach einer Erfassung möglicherweise nicht wiederverwendbar. Synthetische oder öffentliche Daten können ersetzbar sein und sollten keinen unbegründeten Knappheitswert erhalten.
Geschäftsgeheimnisse erfordern betriebliche Kontrollen. Der Käufer sollte Zugriff, Dokumentation, Verschlüsselung, Offboarding und Wissenskonzentration prüfen. Eine Methode, die nur einem Forscher bekannt ist, sollte mit dem Risiko einer Aufbewahrung und Übertragung bewertet werden. Patente sollten auf das tatsächliche Produkt abgebildet und nicht gezählt werden.
8 Trennen Sie die Produkteinnahmen von der Forschungsfinanzierung
Der Umsatz mit Quantum-Software kann Abonnements, Lizenzen, professionelle Dienstleistungen, staatliche Auszeichnungen, Forschungskooperationen, Meilensteinzahlungen und Cloud-Nutzung umfassen. Diese Kategorien weisen unterschiedliche Wiederholgenauigkeiten und Bruttomargen auf. Der Käufer sollte Verträge, Rechnungen, Annahmen und Kassen nach Kunde und Produkt abgleichen.
Wiederkehrende Einnahmen sollten ein Dauerschuldverhältnis und eine glaubwürdige Verlängerungsbasis erfordern. Ein mehrjähriger Forschungsvertrag kann vertraglich vereinbarte Gelder bereitstellen und gleichzeitig maßgeschneiderte Arbeiten finanzieren. Ein Pilot kann Budget und Engagement demonstrieren, ohne die Eignung für den Produktmarkt nachzuweisen. Zuschüsse können wertvolle Entwicklungen finanzieren, sind aber mit Einschränkungen und einer begrenzten kommerziellen Wiederkehr verbunden.
Die Kundenkohorte sollte Eröffnungsumsätze, Verlängerungen, Expansion, Schrumpfung, Abwanderung, Dienstleistungen, abgegrenzte Umsätze und Bargeldeinzug anzeigen. Darin sollten Hardwareanbieter, Workload, Produktversion und Fachunterstützung aufgeführt sein. Die Konzentration kann hoch sein, da Frühkunden strategische Partner sind. Der Käufer sollte testen, ob diese Beziehungen einen Kontrollwechsel oder eine Änderung der Hardwarestrategie überleben.
Bei Umsatzprognosen sollte nicht davon ausgegangen werden, dass eine breitere Hardwareverfügbarkeit automatisch Nachfrage schafft. Das Modell sollte jedes Kundensegment mit einer definierten Fähigkeit, einem Akzeptanzereignis und Verkaufskosten verknüpfen. Nicht unterstützte Marktprognosen sollten außerhalb der Wertschöpfungsbrücke bleiben.
9 Diligence-Kundenergebnisse
Kundenreferenzen sollten sich auf Entscheidungen und akzeptierte Ergebnisse konzentrieren. Der Käufer sollte fragen, welches Problem angesprochen wurde, welche klassische Baseline existierte, welches Ziel verwendet wurde, wie Ergebnisse validiert wurden, welche Ressourcen verbraucht wurden und ob der Kunde eine betriebliche Entscheidung geändert hat. Eine veröffentlichte Zusammenarbeit kann strategisch sinnvoll sein, ohne einen wiederkehrenden wirtschaftlichen Wert zu schaffen.
Akzeptanzkriterien sollten nach Möglichkeit vertraglicher Natur sein. Chemiesoftware kann anhand der Vorhersagegenauigkeit und experimentellen Validierung beurteilt werden. Die Optimierung kann anhand des objektiven Werts, der Machbarkeit, der Laufzeit und der Wiederholbarkeit beurteilt werden. Die Fehlerdiagnose kann anhand der gemessenen Reduzierung oder der Validierungsqualität beurteilt werden. Die Metrik sollte mit der Nutzung durch den Kunden übereinstimmen.
Die Portabilität sollte kommerziell getestet werden. Kann der Kunde fortfahren, wenn der ursprüngliche Anbieter nicht verfügbar ist oder das Ziel von einem konkurrierenden Hardware-Unternehmen übernommen wird? Der Käufer sollte Kündigungs-, Exklusivitäts-, Daten-, Ausgabeeigentums-, Prüfungs- und Supportpflichten prüfen.
Der stärkste Beweis ist die wiederholte kostenpflichtige Nutzung mit stabiler Lieferökonomie. Am schwächsten ist eine nicht unterschriebene Interessenbekundung. Bei der Bewertung sollte eine Kundenbeweisleiter verwendet werden, anstatt alle Logos in den Pipeline-Wert einzubeziehen.
10 Schätzen Sie Talent und wissenschaftliches Know-how
Quantensoftware-Teams können aus theoretischen Physikern, angewandten Mathematikern, Compiler-Ingenieuren, Fachwissenschaftlern, Software-Ingenieuren, Produktführern und Kundenwissenschaftlern bestehen. Der Käufer sollte jede kritische Fähigkeit Produkten und Meilensteinen zuordnen. Organisationstitel allein lassen keine technische Abhängigkeit erkennen.
Das Ziel kann sich auf Gründer verlassen, wenn es um Algorithmendesign, Kundenglaubwürdigkeit und manuelle Optimierung geht. Schlüsselingenieure können Eigentümer des Compilers oder des Bereitstellungssystems sein. Fachwissenschaftler können Kundenprobleme in lösbare Formulierungen übersetzen. Das Diligence-Team sollte undokumentiertes Wissen und eine realistische Ersatzzeit identifizieren.
Die Aufbewahrung sollte die Arbeit nach dem Abschluss widerspiegeln. Servicebasierte Auszeichnungen können die Kontinuität unterstützen. Meilensteinprämien sollten reproduzierbare Ergebnisse und akzeptierte Kundenergebnisse verwenden. Durch die Vergütung sollten eine lohnende Benchmark-Auswahl oder nicht unterstützte Leistungsansprüche vermieden werden.
Durch die Integration sollten die wissenschaftliche Herausforderung und die Disziplin bei der Softwarebereitstellung erhalten bleiben. Der Käufer sollte den Repository-Zugriff, die Release-Governance, die Sicherheit, die Architekturautorität und den Produkteigentum definieren. Ein Hardware-Erwerber sollte es vermeiden, jede Anwendung auf eine eigene Plattform zu zwingen, bevor Portabilität und Kundennutzen getestet werden.
11 Bewerten Sie das Cybersicherheits- und Software-Lieferkettenrisiko
Quantensoftwareprodukte weisen das klassische Softwarerisiko auf. Der Käufer sollte Identität, privilegierten Zugriff, Geheimnisse, Abhängigkeiten, Build-Pipelines, Paketsignierung, Schwachstellenmanagement, Protokollierung, Reaktion auf Vorfälle und Wiederherstellung überprüfen. Cloud-Tokens und Hardware-Anmeldeinformationen erfordern eine besondere Kontrolle.
Software-Stücklisten sollten Pakete, Versionen, Lizenzen und bekannte Schwachstellen identifizieren. Reproduzierbare Builds und geschützte Release-Pipelines verringern das Risiko, dass das erworbene Produkt nicht rekonstruiert oder vertrauenswürdig ist. Der Käufer sollte beim Abschluss die Backup-Wiederherstellung und die Möglichkeit testen, alle Anmeldeinformationen zu rotieren.
Kunden- und Versuchsdaten können vertraulich sein. Verträge und Architektur sollten zeigen, wo Eingaben, Schaltkreise, Kalibrierungsdaten und Ausgaben gespeichert sind. Grenzüberschreitende Verarbeitung, Exportkontrollen und Branchenanforderungen können die Integration beeinträchtigen. Sicherheitsdarstellungen sollten anhand von Protokollen und Vorfällen getestet werden.
Die Sanierungskosten gehören in den Bewertungs- und Integrationsplan. Ein wertvoller Algorithmus mit schwachen Softwarekontrollen erfordert möglicherweise Repository-, Cloud- und Identitätsarbeit, bevor er für regulierte Kunden bereitgestellt werden kann. Diese Ausgaben sollten nicht in allgemeinen Synergien verborgen bleiben.
12 Kosten für den Modellaustausch und eingesparte Zeit
Die Wiederbeschaffungskosten sollten eine Schätzung des Teams, der Daten, Experimente, der Software und der verstrichenen Zeit sein, die zur Reproduktion der übertragbaren Fähigkeit erforderlich sind. Historische Ausgaben sind Belege, umfassen aber auch fehlgeschlagene Pfade und versunkene Kosten. Der Käufer sollte Wert auf das aktuelle System, die Dokumentation und die Erkenntnisse legen, die eine glaubwürdige Alternative ermöglichen.
Das Modell sollte das Codevolumen vom Schwierigkeitsgrad trennen. Ein kleiner Compiler-Durchlauf kann seltene Fachkenntnisse kodieren. Ein großes Anwendungs-Repository kann austauschbaren Integrationscode enthalten. Experteninterviews, Repository-Historie und Benchmark-Reproduktion helfen dabei, den Engpass zu identifizieren.
Die eingesparte Zeit kann wertvoll sein, wenn eine Hardware- oder Industrie-Roadmap ein festes Zeitfenster hat. Der Erwerber sollte die Kauf- und Integrationszeit mit einem internen Build vergleichen. Der Vorteil sollte gekürzt werden, wenn wichtige Rechte, Kunden oder Mitarbeiter möglicherweise nicht übertragen werden.
Offene Standards und Open-Source-Frameworks können die Austauschkosten senken. Sie können auch den Markt erweitern und den Wert komplementärer proprietärer Schichten steigern. Die Bewertung sollte ermitteln, ob der Burggraben des Ziels mit zunehmender Interoperabilität stärker oder schwächer wird.
13 Erstellen Sie das Einkommensmodell
Ein Einkommensmodell sollte Kundenevidenz anstelle einer entfernten Quantenmarktprognose verwenden. Der Umsatz sollte nach Produkten, Dienstleistungen, Zuschüssen und anderen Quellen segmentiert werden. Die Bruttomarge sollte Cloud-Ausführung, Hardware-Zugriff, Bereitstellung durch Spezialisten, Support und Lizenzen von Drittanbietern umfassen. Die Lohn- und Gehaltsabrechnung für Forschung und Produktentwicklung sollte weiterhin sichtbar bleiben.
Die Prognose sollte Conversion-Ereignisse modellieren. Ein Pilot konvertiert, wenn Akzeptanz, Beschaffung und Budget erfüllt sind. Ein Abonnement verlängert sich, wenn das Produkt über Hardware und Versionen hinweg nützlich bleibt. Ein Dienstleistungsprojekt wird nur dann zum Produktumsatz, wenn die Lieferung mit weniger individuellem Aufwand wiederholbar ist.
Das Modell sollte Hardwareabhängigkeiten umfassen. Wenn ein wertvoller Arbeitsablauf eine in zwei Jahren erwartete Leistungsfähigkeit des Anbieters erfordert, sollte der Umsatz wahrscheinlichkeitsgewichtet und vorsichtig kapitalisiert werden. Wenn das Ziel heute Einnahmen aus Diagnose oder Simulation erzielt, kann dieser erzielte Cashflow die konventionelle Analyse unterstützen.
Der Endwert sollte den technologischen Wandel und den Wettbewerb widerspiegeln. Eine lange Wachstumsphase, die nicht von Kundenkohorten unterstützt wird, führt zu falscher Präzision. Der Transaktionsausschuss sollte den Ertragsansatz mit den Wiederbeschaffungskosten und dem Szenariowert vergleichen.
14 Verwenden Sie eine portabilitätsangepasste Scorecard
Die Scorecard sollte Algorithmennachweise, Portabilität, Benchmark-Qualität, geistiges Eigentum, Daten, Kundenergebnisse, Umsatzqualität, Team, Sicherheit und Start- und Landebahn abdecken. Jede Bewertung sollte mit Beweisen und einer Bewertungsauswirkung verknüpft sein. Eine hohe wissenschaftliche Punktzahl kann fehlendes Eigentum oder eine schwache Kundenakzeptanz nicht beheben.
Die Portabilität sollte separate Unterbewertungen für Quelle, Semantik, Kompilierung, Ausführung, Leistung und kommerzielle Kontinuität erhalten. Der Käufer sollte das in der Erwerbsarbeit geforderte Mindestniveau ermitteln. Ein Hardwarekäufer kann eine Abhängigkeit akzeptieren, die seine Plattform stärkt. Ein neutraler Cloud-Käufer benötigt möglicherweise eine umfassende Leistungsportabilität.
Die Punktekarte sollte Konzentration zeigen. Ein Ziel kann starke Durchschnittsnoten erhalten, obwohl es von einem Anbieter, Wissenschaftler oder Kunden abhängig ist. Angussfehler sollten daher getrennt von den gewichteten Werten gemeldet werden. Der Vorstand sollte wissen, welcher Sachverhalt die Dissertation ungültig machen kann.
Die Ergebnisse sollten sich nach Bestätigungstests ändern. Das Modell sollte die Beweise und Gründe für jede Aktualisierung bewahren. Dies unterstützt die Preisverhandlung und die Verantwortlichkeit nach dem Abschluss.
15 Lernen Sie aus offenbarten Kombinationen
Die Gründung von Quantinuum fusionierte Honeywell Quantum Solutions mit Cambridge Quantum. In öffentlichen Ankündigungen wurde ein integriertes Hardware- und Softwareunternehmen sowie eine langfristige Produktionsunterstützung beschrieben. Die Kombination veranschaulicht eine These der vertikalen Integration, einschließlich der Fähigkeit, Software plattformübergreifend zu entwickeln und gleichzeitig eine Hardware-Roadmap zu steuern.
Durch die Übernahme von Quantum Benchmark durch Keysight wurde ein breiteres Quantenportfolio um Software zur Fehlerdiagnose, Fehlerunterdrückung und Leistungsvalidierung erweitert. Die offengelegte Begründung verdeutlicht den Wert von Software, die Hardware misst und verbessert. Es wird keine eigenständige Algorithmusbewertung offenbart.
Quantum Machines hat QDevil übernommen, um die Quantenkontrollfähigkeit von der Gate-Ebene auf das Qubit zu erweitern. SandboxAQ hat Good Chemistry übernommen, um Computerchemie-Technologie, Kunden und Talente hinzuzufügen. Diese Transaktionen veranschaulichen Thesen zum Kontroll-Stack und zur Domänenanwendung.
Die Beispiele sollten nicht als direkte Vergleichswerte ohne Angleichung von Preis, Umsatz, Rechten und Beweisen betrachtet werden. Sie sind nützlich für die Identifizierung strategischer Wertschöpfungspfade: vertikale Integration, Validierung, Kontrolle, Domänenworkflow, Talent und Kundenzugang. Das Ziel sollte der Route zugeordnet werden, die durch seine Beweise gestützt wird.
16 Konstruieren Sie die hypothetische Bewertung
Das ausgearbeitete Beispiel verwendet ein völlig hypothetisches Quantensoftwareziel. Darin werden USD 18 million der Jahreseinnahmen ausgewiesen: USD 11 million wiederkehrende Produkteinnahmen, USD 4 million Dienstleistungen und USD 3 million Zuschüsse und sonstige Einnahmen. Es verfügt über USD 96 million an uneingeschränktem Bargeld und USD 38 million an jährlicher Bargeldnutzung. Diese Beträge stellen kein beobachtetes Unternehmen dar.
Der zentrale Unternehmenswert ist USD 420 million. Es ordnet USD 105 million validierten Algorithmen und Anwendungen, USD 90 million Compiler- und Orchestrierungsressourcen, USD 60 million Kundenbeziehungen und Verträgen, USD 45 million proprietären Daten und Workflows, USD 70 million Team und Know-how und USD 50 million Roadmap-Optionen zu. Jeder Wert ist eine Managementannahme.
Vier Szenarien testen die Portabilität. Ein eingeschränkter Fall, in dem der Hauptalgorithmus an einen Anbieter gebunden bleibt, hat einen Wert von USD 140 million und eine Wahrscheinlichkeit von 25 Prozent. Ein quellenportabler, aber leistungsvariabler Fall hat einen Wert von USD 360 million und eine Wahrscheinlichkeit von 40 Prozent. Ein leistungsstarkes tragbares Produkt mit Stammkunden hat einen Wert von USD 820 million und eine Wahrscheinlichkeit von 27 Prozent. Eine Kategorieplattform mit breitem Hardwarezugriff hat einen Wert von USD 1.80 billion und eine Wahrscheinlichkeit von 8 Prozent. Der veranschaulichende wahrscheinlichkeitsgewichtete Wert ist USD 508.4 million vor Integration, Finanzierung und Verwässerung.
Der Unterschied zwischen dem zentral zugeordneten Wert und dem wahrscheinlichkeitsgewichteten Szenariowert legt Annahmen offen. Ein Käufer sollte sich auf Integrationskosten, Kundenbindung, Kundeneinwilligung, Hardwareverträge und Finanzierung einstellen. Eine bedingte Gegenleistung kann die Zahlung mit Portabilitätstests und der Kundenbindung in Einklang bringen.
17 Strukturbetrachtung rund um Beweise
Durch eine Vorabzahlung können kontrollierter Code, Rechte, Cashflow und übertragbare Fähigkeiten bezahlt werden. Aufgeschobene Zahlungen können von einem sauberen Build, einem ausgehaltenen Multi-Target-Benchmark, einer Kundenbindung oder einer akzeptierten Produktfreigabe abhängen. Retention Awards sollen Service und Wissenstransfer belohnen.
Meilensteine sollten Ziele, Versionen, Arbeitslasten, Baselines, Metriken und unabhängige Überprüfungen angeben. Die allgemeine Anforderung, dass Software hardwareunabhängig bleiben muss, ist umstritten. Ein besserer Meilenstein besagt, dass definierte Workloads gemäß vereinbarten Zielen zusammengestellt und ausgeführt werden und dabei Lösungsqualitäts-, Zeit- und Kostenschwellenwerte einhalten.
Die Vereinbarung sollte technischen Änderungen Rechnung tragen. Neue Hardware kann ein ursprüngliches Ziel ersetzen. Substitutionsregeln sollten die wirtschaftliche Gleichwertigkeit wahren und verhindern, dass eine der Parteien einen künstlich einfachen oder unmöglichen Test wählt. Qualifizierte Berater sollten sich mit den Auswirkungen auf Buchhaltung, Steuern, Beschäftigung und Wertpapiere befassen.
Der Käufer sollte auch die Daten- und Kundenkontinuität schützen. Einwilligungen, Übergangsdienste, Cloud-Zugriff und Sicherheitsbehebung können Abschlussbedingungen oder Vereinbarungen sein. Ein Treuhandkonto kann identifizierte Rechtelücken schließen. Jeder Schutz sollte einem wertverändernden Risiko zugeordnet werden.
18 Planen Sie die ersten hundert Tage
Die ersten dreißig Tage sollten Repositorys, Anmeldeinformationen, Cloud-Konten, Kundendaten und Release-Pipelines sichern. Der Käufer sollte kritisches Personal bestätigen, Beweisgrundlagen einfrieren und den Zugang des Anbieters aufrechterhalten. Die Kundenkommunikation sollte Kontinuität verdeutlichen, ohne ungestützte Leistungsversprechen abzugeben.
In den Tagen 30 bis 60 sollen Builds reproduziert, wichtige Benchmarks erneut ausgeführt, die Produktarchitektur abgebildet und Kundenverpflichtungen validiert werden. Das Integrationsteam sollte gemeinsame Dienste von geschützter wissenschaftlicher Arbeit trennen. Eine kombinierte Roadmap sollte ermitteln, welche Plattformen weiterhin unterstützt werden und warum.
In den Tagen 60 bis 100 sollten sich überschneidende Tools rationalisiert, die Produkt- und Hardwarematrix genehmigt, die Sicherheit verbessert und der Wissenstransfer getestet werden. Kommerzielle Führungskräfte sollten Preise, Support und Erneuerungspläne überprüfen. Die Finanzabteilung sollte die Integrationsausgaben und Meilensteinfortschritte mit dem Investitionsfall in Einklang bringen.
Der Vorstand soll einen Wertrealisierungsbericht erhalten. Es sollte erzielte Synergien, erhaltene Kunden, Portabilitätsnachweise, Bargeldverwendung, Risiken und nächste Entscheidungen aufzeigen. Technisches Lernen sollte Bewertungsannahmen aktualisieren und nicht nur als Aktivität gemeldet werden.
Abschluss
Der Wert von Quantensoftware wird nicht durch eine hardwareunabhängige Bezeichnung bestimmt. Es hängt davon ab, inwieweit Algorithmen, Compiler, Arbeitsabläufe und Kundenergebnisse eine Änderung in der Ausführungsumgebung überstehen. Quellenübersetzung, erfolgreiche Zusammenstellung und gleichwertige kommerzielle Leistung sind unterschiedliche Beweiszustände.
Ein Erwerber sollte eine Algorithmus-Evidenzleiter, ein Abhängigkeitsdiagramm, eine Portabilitätsmatrix, einen Benchmark-Plan und eine Kundenkohorte erstellen. Es sollte Builds reproduzieren, Anbieterfunktionen kontrollieren, Qualität und Zeit bis zur Lösung messen, Rechte bestätigen und Kundengelder abgleichen. Erreichte Vermögenswerte sollten vom bedingten Roadmap-Wert getrennt werden.
Offene Darstellungen und Standards können die Umstellungskosten senken und gleichzeitig zielspezifische Leistungsgrenzen aufdecken. Strategische Kombinationen zeigen, dass Software durch vertikale Integration, Diagnose, Steuerung und Domänenanwendungen Mehrwert schaffen kann. Der Wert eines bestimmten Ziels erfordert immer noch transaktionsspezifische Beweise.
Vorstände können diesen Rahmen nutzen, um zu entscheiden, ob sie ein Unternehmen erwerben, investieren, lizenzieren, eine Partnerschaft eingehen oder bauen möchten. Jede wesentliche Wertkomponente sollte auf kontrollierte Rechte, reproduzierbare Leistung, akzeptierte Kundenergebnisse oder eine ausdrücklich erklärte Annahme des Managements hinweisen. Wenn sich diese Beweise ändern, sollten Überlegungen angestellt werden.
Anhang A Portabilitätstestprotokoll
Das Protokoll sollte Quelle, Abhängigkeiten, Compilerversionen, Zielprofile, Daten, Seeds und Akzeptanzkriterien einfrieren. Es sollte ein primäres Ziel, eine glaubwürdige Alternative und einen Simulator oder Emulator umfassen. Das Ziel sollte auf einer sauberen Umgebung mit dokumentierten Anmeldeinformationen und Infrastruktur aufbauen.
Jeder Lauf sollte Kompilierungszeit, Schaltungsbreite und -tiefe, native Vorgänge, Schüsse, Warteschlangen- und Ausführungszeit, klassische Nachbearbeitung, Wiederholungsversuche, Gesamtkosten und Lösungsqualität aufzeichnen. Ausschlüsse und fehlgeschlagene Läufe sollten im Protokoll verbleiben. Eine Basisimplementierung sollte denselben Zugriff und dieselbe Konfiguration verwenden.
Der Bericht sollte Quelle, Semantik, Kompilierung, Ausführung, Leistung und kommerzielle Portabilität klassifizieren. Es sollte angegeben werden, welche Änderungen erforderlich waren und ob sie gepflegte Produktzweige bilden. Unabhängige Gutachter sollten ausreichend Zugang haben, um die Schlussfolgerung zu reproduzieren.
Anhang B Kunden- und Umsatznachweise
Der Kundenplan sollte die rechtliche Gegenpartei, das Produkt, die Arbeitslast, den Hardwareanbieter, die Laufzeit, den zugesagten Wert, die Dienstleistungen, die Akzeptanz, die Rechnungsstellung, die Barmittel, die Erneuerung und den Kontrollwechsel angeben. Forschungsgelder und Zuschüsse sollten von wiederkehrenden Produkteinnahmen getrennt werden.
Die Kohortenanalyse sollte den wiederkehrenden Eröffnungsumsatz, die Neukunden, die Expansion, den Rückgang, die Abwanderung und den wiederkehrenden Abschlussumsatz anzeigen. Es sollte mit den Buchhaltungsunterlagen abgeglichen werden. Die Pipeline sollte außerhalb der vertraglich vereinbarten Einnahmen bleiben und Beschaffungs-, technische und Budget-Gates identifizieren.
Kundenreferenzen sollten die unterstützte Entscheidung, die Ausgangslage, die akzeptierten Ergebnisse, den fachlichen Aufwand und die zukünftige Absicht bestätigen. Der Käufer sollte prüfen, ob die Beziehung einen Hardware- oder Eigentümerwechsel übersteht.
Anhang C Bewertungsdatenraum
Der technische Datenraum sollte Repositorys, Build-Anweisungen, Abhängigkeitssperren, Software-Stücklisten, Lizenzen, Mitwirkendenvereinbarungen, Patente, Datenrechte, Benchmarks, Rohausführungsaufzeichnungen, Zielkonfigurationen, Sicherheitsaufzeichnungen und den Vorfallverlauf enthalten. Es sollte negative und fehlgeschlagene Experimente umfassen.
Zu den kommerziellen Aufzeichnungen gehören Verträge, Leistungsbeschreibungen, Zuschüsse, Rechnungen, Kassenbelege, Supportprotokolle und Nutzungsdaten. Finanzunterlagen sollten Umsatzkategorien, Bruttomarge, Forschungsausgaben, Bargeld, Verpflichtungen und monatliche Bargeldverwendung in Einklang bringen.
Im Sorgfaltsbericht sollte angegeben werden, was reproduziert, gesampelt, nicht verfügbar oder umstritten war. Jede ungelöste Lücke sollte in Preis, Struktur, Integrationsbudget oder Genehmigungsbedingungen auftauchen.
Anhang D Integrationswertbuch
Das Integrationswertbuch sollte Umsatz, Kosten, Kapital und strategische Effekte unterscheiden. Zu den Umsatzeffekten können Kundenbindung, Cross-Selling, der Zugang zu neuen Plattformen und eine schnellere Konvertierung durch Pilotprojekte gehören. Zu den Kosteneffekten können die Entfernung doppelter Infrastruktur, die Hebelwirkung bei der Beschaffung und geringere Ausgaben für externe Lizenzen gehören. Zu den Kapitaleffekten gehören die Vermeidung interner Entwicklung und die verkürzte Zeit bis zur nächsten Produktveröffentlichung. Zu den strategischen Auswirkungen gehört die Steuerung eines kritischen Compilers, Workflows, Datenbestands oder einer Kundenschnittstelle.
Für jeden Artikel sollten eine Basislinie, ein verantwortlicher Eigentümer, ein Zeitplan, erforderliche Ausgaben und eine Beweisquelle angegeben sein. Eine grobe Synergieschätzung sollte für Kundenabwanderung, Produktunterbrechungen, Kundenbindungsprämien, Cloud-Migration, Sicherheitsbehebung, doppelte Plattformunterstützung und Steuern reduziert werden. Vorteile, die von zukünftiger Hardware abhängen, sollten wahrscheinlichkeitsgewichtet und getrennt von kurzfristigen Maßnahmen dargestellt werden.
Das Hauptbuch soll Doppelzählungen verhindern. Die Portabilität von Algorithmen kann die Kundenbindung unterstützen und die Wiederherstellungskosten senken, doch ohne einen Abgleich sollte sich in beiden Bereichen nicht derselbe Nutzen ergeben. Der Käufer sollte auch den von einer anderen Geschäftseinheit übertragenen Wert vom für die kombinierte Gruppe geschaffenen Wert unterscheiden. Die Verlagerung von Cloud- oder Engineering-Kosten in ein zentrales Budget schafft an sich noch keinen Unternehmenswert.
Bei der Berichterstattung nach dem Abschluss sollte der realisierte Wert mit dem genehmigten Fall verglichen werden. Technische Kennzahlen sollten mit kommerziellen Ergebnissen verknüpft sein. Ein erfolgreicher Multi-Target-Benchmark hat nur einen begrenzten Transaktionswert, bis er die Supportkosten senkt, einen Kunden bindet, den Vertrieb erweitert oder ein Produkt freischaltet. Eine Kundenverlängerung sollte sorgfältig zugeordnet werden, wenn sie auch vom Umsatz, dem Hardware-Fortschritt oder der Preisgestaltung abhängt.
Der Vorstand sollte das Hauptbuch in festgelegten Abständen überprüfen und den Investitionsfall überarbeiten, wenn sich die Beweise ändern. Ein unerreichter Wert sollte eine Produkt-, Kapital- oder Integrationsentscheidung auslösen. Der Zweck besteht darin, einen nachvollziehbaren Zusammenhang zwischen Erwerbsthese, technischem Beweismaterial, Geld und verantwortlicher Ausführung aufrechtzuerhalten.
Anhang E Entscheidungsabbildungen und -tabellen
Vorgeschlagene Reihenfolge; Jede Stufe erfordert eine reproduzierbare Aufzeichnung und einen definierten Abnahmetest.
Völlig hypothetische Managementannahmen; Der Score kombiniert normalisierte Lösungsqualität, Zeit und Kosten.
Völlig hypothetische Managementannahmen; USD Millionen.
Völlig hypothetische Managementannahmen; USD Millionen.
Völlig hypothetische Managementannahmen; USD Millionen.
| Schicht | Prüfen | Häufiger Fehler | Bewertungsverwendung |
|---|---|---|---|
| Quelle | Code wird in einer gemeinsamen Sprache übersetzt oder ausgedrückt | Syntaxverschiebungen, während Abhängigkeiten bestehen bleiben | Eingeschränkter Nachweis der Übertragbarkeit |
| Semantisch | Die mathematische Absicht bleibt gleichwertig | Zielbeschränkungen ändern die Methode | Algorithmusbeweisanpassung |
| Zusammenstellung | Das Programm wird in den Zielstapel abgesenkt | Nicht unterstützte Steuerungs-, Gate- oder Laufzeitfunktionen | Retargeting-Kosten |
| Ausführung | Der vollständige Workflow wird unter unterstützten Bedingungen ausgeführt | Versteckter Anbieterdienst oder manueller Eingriff | Fähigkeitstest bestanden |
| Leistung | Qualität, Zeit und Kosten bleiben im Rahmen | Eine äquivalente Produktion wird unwirtschaftlich | Produkt- und Optionswert |
| Kommerziell | Der Kunde akzeptiert, zahlt und verlängert | Ein Wechsel der Hardware oder des Eigentümers beeinträchtigt die Akzeptanz | Beziehungs- und Einkommenswert |
Vorgeschlagene Hierarchie; Jede Schicht erfordert ihre eigenen Beweise.
| Bühne | Erforderlicher Datensatz | Unabhängige Prüfung | Bewertungsbehandlung |
|---|---|---|---|
| Mathematischer Anspruch | Problem, Annahmen und Richtigkeitskriterium | Expertenbewertung | Nur Forschungsoption |
| Reproduzierbare Simulation | Code, Daten, Seeds und klassische Baseline | Wiederholung einer sauberen Umgebung | Know-how und Codewert |
| Zielzusammenstellung | Compiler-, Profil-, Schaltkreis- und Ressourcendatensätze | Wiederholen Sie den Aufbau | Bedingter Implementierungswert |
| Hardware-Ausführung | Aufträge, Kalibrierung, Aufnahmen, Zeit, Kosten und Leistung | Ausgehaltener Lauf | Technische Beweise erreicht |
| Zielübergreifende Leistung | Vergleichbare Ziele und Akzeptanzschwellen | Unabhängiger Benchmark | Steigerung der Portabilität |
| Kundenakzeptanz | Vertrag, Lieferung, Rechnung und Barzahlung | Kunden- und Buchhaltungsabstimmung | Kommerzieller Wert |
Vorgeschlagene Transaktions-Diligence-Sequenz.
| Schicht | Beweis | Abhängigkeitsrisiko | Wertimplikation |
|---|---|---|---|
| Sprachen und Bibliotheken | Repositories, Versionen, Lizenzen und Tests | Breaking Changes und nicht im Besitz befindliche Komponenten | Wartungs- und Sanierungskosten |
| Zwischenvertretung | Profile, Transformationen und Validierung | Nicht unterstützte Semantik oder Zielfunktionen | Anpassung der Portabilität |
| Compiler und Pässe | Build, Benchmarks, Eigentum und Dokumentation | Zielspezifische Optimierung | Erzielte Asset- oder Retargeting-Kosten |
| Hardware und Cloud | Verträge, Zugang, Warteschlangen, Preise und Funktionen | Anbieterkonzentration und Kontrollwechsel | Leistungs- und Kundenanpassung |
| Klassischer Arbeitsablauf | Daten, HPC, AI, Nachbearbeitung und Orchestrierung | Der Quantenanspruch hängt von klassischen Vermögenswerten ab | Weisen Sie dem Gesamtsystem Wert zu |
Vorgeschlagene Mindestüberprüfung der Software-Ausführungskette.
| Wertkomponente | Anschaulicher Betrag | Beweistor | Nachteilige Behandlung |
|---|---|---|---|
| Validierte Algorithmen und Anwendungen | USD 105 million | Reproduzierbare Maßstäbe und Rechte | Einschränkung der Portabilität |
| Compiler und Orchestrierung | USD 90 million | Sauberer Aufbau, Zielbeweis und Besitz | Sanierungsreserve |
| Kundenbeziehungen und Verträge | USD 60 million | Annahme, Erneuerung, Bargeld und Zustimmung | Aufbewahrungsanpassung |
| Proprietäre Daten und Arbeitsabläufe | USD 45 million | Provenienz, Übertragungsrechte und Einbringung | Rechteabzug |
| Team und Know-how | USD 70 million | Beibehaltung kritischer Rollen und Wissenstransfer | Servicebasierte Aufbewahrung |
| Roadmap-Optionen | USD 50 million | Geförderte Portabilität und Kundenmeilensteine | Bedingte Gegenleistung |
Völlig hypothetische Managementannahmen; nicht beobachtete Unternehmens- oder Transaktionsdaten.
| Beweis | Was es unterstützt | Einschränkung | Bewertungsverwendung |
|---|---|---|---|
| Forschungskooperation | Zugang und technisches Engagement | Möglicherweise mangelt es an wiederkehrendem Budget oder an Akzeptanz | Beziehungsbeweise |
| Zuschuss oder Auszeichnung | Geförderter Umfang und politische Unterstützung | Eingeschränkte Nutzung und begrenzte Wiederholung | Vertragliches Bargeld mit Bedingungen |
| Bezahlter Pilot | Kundenbudget und definiertes Experiment | Maßgeschneiderte Arbeiten sind möglicherweise nicht skalierbar | Wahrscheinlichkeitsbereinigte Umrechnung |
| Akzeptierte Produktlieferung | Leistung anhand vereinbarter Kriterien | Stellt keine Erneuerung her | Vertrags- und Lieferwert |
| Wiederholte kostenpflichtige Nutzung | Fortlaufende Budget- und Betriebsrelevanz | Kann anbieterabhängig bleiben | Stärkere Einkommensnachweise |
Vorgeschlagene Klassifizierung für die Revenue Diligence.
| Messen | Anschaulicher Betrag | Frage zur Sorgfaltspflicht | Bewertungskonsequenz |
|---|---|---|---|
| Wiederkehrende Produktumsätze | USD 11 million | Erneuerung, Marge und Portabilität | Einkommensunterstützung |
| Einnahmen aus Dienstleistungen | USD 4 million | Gründeraufwand und Wiederholbarkeit | Anpassung der Dienstleistungen |
| Zuschüsse und sonstige Einkünfte | USD 3 million | Einschränkungen und Wiederholung | Getrennt vom Produktmultiplikator |
| Uneingeschränktes Bargeld | USD 96 million | Verfügbarkeit und Verpflichtungen | Eigenkapital-Wert-Überleitung |
| Jährlicher Bargeldverbrauch | USD 38 million | Nächstes Beweistor und Finanzierungsvorlaufzeit | Landebahn- und Verdünnungsanpassung |
Völlig hypothetische Managementannahmen; USD Millionen.
| Entscheidungsbereich | Grüne Beweise | Bernsteinfarbener Zustand | Roter Zustand |
|---|---|---|---|
| Portabilität | Angehaltene Arbeitslasten erfüllen die Qualitäts-, Zeit- und Kostenschwellenwerte im Rahmen der vereinbarten Ziele | Quell- und Ausführungsportabilität mit Leistungsvariation | Marketingaussage ohne reproduzierbare Zielbeweise |
| Rechte | Code, Daten, Lizenzen und Mitwirkendenrechte bestätigt | Begrenzte Sanierung mit Kosten und Termin | Kritische Fähigkeit, die nicht besessen oder nicht übertragbar ist |
| Kunden | Bezahlte Abnahme, Erneuerung und Barabgleich | Pilot- oder geförderte Forschung mit Umstellungsplan | Logos oder Pipeline werden als wiederkehrende Einnahmen behandelt |
| Team und Sicherheit | Kritische Rollen bleiben erhalten; Sauberer Build und Zugriffsübertragung erfolgreich | Dokumentierter Sanierungs- und Aufbewahrungsplan | Anmeldeinformationen des Gründers oder unsichere Lieferkette erforderlich |
| Bewertung | Erzielte Vermögenswerte und bedingte Optionen getrennt | Breiter, aber expliziter Szenariobereich | Marktprognosen ersetzen Beweise |
Vorgeschlagener Entscheidungsrahmen.
Quellen
- Quantum Economic Development Consortium, Anwendungsorientierte Leistungsbenchmarks für Quantencomputing. Lesen Sie die Primärquelle
- Quantum Economic Development Consortium, Erforschung von Quantenalgorithmen mithilfe anwendungsorientierter Leistungsbenchmarks, 2024. Lesen Sie die Primärquelle
- Quantum Economic Development Consortium, Technischer Beratungsausschuss für Standards und Leistungsmetriken. Lesen Sie die Primärquelle
- Microsoft Azure Quantum, Quantum Intermediate Representation. Lesen Sie die Primärquelle
- Microsoft Azure Quantum, QIR-Zielprofile im Quantum Development Kit, 2026. Lesen Sie die Primärquelle
- Microsoft Azure Quantum, Backend-Quantensimulatoren von Quantenanbietern, 2026. Lesen Sie die Primärquelle
- OpenQASM, OpenQASM 3 Live-Spezifikation. Lesen Sie die Primärquelle
- Cross und Mitarbeiter, OpenQASM 3: Eine breitere und tiefere Quantenassemblysprache, ACM Transactions on Quantum Computing, 2022. Lesen Sie die Primärquelle
- Amazon Web Services, Unterstützung für OpenQASM auf verschiedenen Amazon Braket-Geräten. Lesen Sie die Primärquelle
- Amazon Web Services, OpenQASM-Funktionen, die von Amazon Braket unterstützt werden. Lesen Sie die Primärquelle
- IBM Quantum, Qiskit-Transpiler-Dokumentation. Lesen Sie die Primärquelle
- IBM Quantum-, Backend- und Zieldokumentation. Lesen Sie die Primärquelle
- Google Quantum AI, Cirq-Dokumentation. Lesen Sie die Primärquelle
- NVIDIA, CUDA-Q-Dokumentation. Lesen Sie die Primärquelle
- NVIDIA, cuQuantum SDK-Dokumentation, 2026. Lesen Sie die Primärquelle
- Xanadu, PennyLane-Dokumentation. Lesen Sie die Primärquelle
- Linux Foundation, QIR Alliance. Lesen Sie die Primärquelle
- Nationales Institut für Standards und Technologie, Quanteninformationswissenschaft. Lesen Sie die Primärquelle
- ISO, ISO/IEC 4879:2024 Quantentechnologien; Vokabular. Lesen Sie die Primärquelle
- Honeywell, Honeywell Quantum Solutions und Cambridge Quantum schließen Unternehmenszusammenschluss ab, 2021. Lesen Sie die Primärquelle
- Quantinuum, Einführung in Quantinuum, 2021. Lesen Sie die Primärquelle
- Quantinuum, Registrierungserklärung, eingereicht bei der United States Securities and Exchange Commission, 2026. Lesen Sie die Primärquelle
- Keysight Technologies, Keysight Technologies erwirbt Quantum Benchmark, 2021. Lesen Sie die Primärquelle
- Quantum Machines, Quantum Machines übernimmt QDevil, 2022. Lesen Sie die Primärquelle
- SandboxAQ, SandboxAQ erwirbt Good Chemistry, 2024. Lesen Sie die Primärquelle
- IFRS-Stiftung, IFRS 3 Unternehmenszusammenschlüsse. Lesen Sie die Primärquelle
- IFRS Foundation, IFRS 13 Bemessung des beizulegenden Zeitwerts. Lesen Sie die Primärquelle
- IFRS Foundation, IAS 38 Immaterielle Vermögenswerte. Lesen Sie die Primärquelle
- International Valuation Standards Council, Internationale Bewertungsstandards. Lesen Sie die Primärquelle
- United States Securities and Exchange Commission, Handbuch zur Finanzberichterstattung. Lesen Sie die Primärquelle
- National Institute of Standards and Technology, Secure Software Development Framework SP 800-218. Lesen Sie die Primärquelle
- Nationales Institut für Standards und Technologie, Cybersecurity Framework 2.0. Lesen Sie die Primärquelle
