Введение
Программное обеспечение Quantum включает в себя языки программирования, компиляторы, оптимизацию схем, устранение ошибок, системы управления, симуляторы, оркестрацию рабочих процессов, библиотеки приложений, оценку ресурсов и предметные решения. Некоторые продукты расположены рядом с квантовым процессором. Другие координируют квантовые и классические вычисления, управляют экспериментами или разрабатывают научные методы для химии, финансов, оптимизации и машинного обучения. Таким образом, периметр транзакции может содержать код, данные, патенты, коммерческую тайну, сотрудников, контракты с клиентами, облачные отношения и будущий доступ к оборудованию.
Главный вопрос покупателя заключается в том, обладает ли цель долговременной возможностью или временной реализацией, настроенной на конкретное устройство. Схема, работающая на двух платформах, может обеспечивать разную точность, глубину, стоимость и задержку. Компилятор может уменьшить количество шлюзов в одной топологии, одновременно увеличивая накладные расходы на маршрутизацию в другой. Приложение может полагаться на собственный импульсный доступ провайдера, службу устранения ошибок или приоритет очереди. Контракт с клиентом может финансировать исследования, а не воспроизводимый продукт.
Оценка становится затруднительной, когда переносимость рассматривается как атрибут «да» или «нет». Программное обеспечение может быть переносимым на уровне исходного кода и зависеть от уровня производительности. Он может скомпилироваться в общее представление и при этом потребовать снижения для конкретной цели. Он может воспроизводить математический результат, теряя при этом скорость, стоимость и точность, которые поддерживают коммерческое заявление. Он может работать на альтернативном оборудовании, при этом отношения с клиентами остаются привязанными к предпочитаемому поставщику.
В этой статье широкое утверждение о независимости оборудования заменяется иерархией доказательств. Он спрашивает, что движется, что необходимо перестроить, что выполняет, кто платит и какие права передаются. Результатом является структура транзакций для групп корпоративных разработчиков, инвесторов, основателей и консультантов, оценивающих приобретения, комбинации и стратегические инвестиции в области квантового программного обеспечения.
1 Определите тезис о приобретении
Комитет по сделке должен указать, почему требуется право собственности. Покупатель может искать портфель алгоритмов, уровень компилятора или управления, команду разработчиков приложений, доступ клиентов, собственные данные, патенты, сообщество разработчиков или путь для интеграции аппаратного и программного обеспечения. Каждая диссертация требует разного усердия и создает разные мосты оценки.
Покупатель оборудования может ценить программное обеспечение, поскольку оно улучшает использование, раскрывает возможности устройства и увеличивает рабочие нагрузки. Покупатель облака или платформы может ценить абстракцию, оркестровку и распространение. Промышленный покупатель может оценить рабочий процесс предметной области и ученых, которые его понимают. Финансовый инвестор может оценить возможность выбора между несколькими поставщиками оборудования. Комитет должен определить доходы, затраты, время или стратегическую зависимость, которую изменяет приобретение.
В тезисе также должно быть указано контрфактическое. Альтернативы могут включать лицензирование, партнерство, внутреннюю сборку, внедрение открытого исходного кода, найм или ожидание. Время замены и риск выполнения часто имеют большее значение, чем исторические затраты на разработку. Премия за приобретение трудно оправдать, когда надежная альтернатива достигает того же результата для клиентов до того, как квантовое оборудование станет коммерчески значимым.
В документе совета директоров должна быть указана дата оценки, обеспечение, вознаграждение, предполагаемое финансирование и бюджет интеграции. Он должен определить, какое значение присутствует при закрытии, а какое зависит от технических, клиентских или аппаратных этапов. Такое разделение позволяет цене и защите следовать за доказательствами.
2 Разложение аппаратной независимости
Переносимость исходного кода означает, что код или алгоритм высокого уровня можно перемещать или транслировать. Семантическая переносимость означает, что предполагаемая математическая операция остается эквивалентной. Переносимость компиляции означает, что программу можно преобразовать в принятое промежуточное представление и целевой набор команд. Переносимость исполнения означает, что весь рабочий процесс выполняется на целевом объекте в поддерживаемых условиях.
Переносимость производительности повышает качество решения, использование ресурсов, задержку, пропускную способность и стоимость. Коммерческая переносимость предполагает, принимает ли клиент результат, остается ли модель поддержки жизнеспособной и сохраняется ли экономика. Эти слои следует тестировать отдельно. Передача более раннего слоя не устанавливает следующий.
Промежуточное представление может уменьшить связь языка и компилятора. Microsoft описывает квантовое промежуточное представление как независимое от языка и оборудования, использующее инфраструктуру LLVM в качестве общего интерфейса. Целевая среда по-прежнему определяет доступные вентили, поток управления, измерения, синхронизацию и службы времени выполнения. Целевые профили Azure Quantum документируют различные возможности условного ветвления, арифметики и циклов. Покупатель должен протестировать профиль, необходимый для каждого ценного рабочего процесса.
OpenQASM 3 также предоставляет широкий язык для квантовых программ и классического управления в реальном времени. Его спецификация позволяет реализациям ограничивать обработку во время выполнения операциями, которые оборудование может выполнять эффективно. Документы Amazon Braket поддерживают операторы, операции и возможности устройств. Таким образом, существование стандарта улучшает совместимость, оставляя при этом существенные различия в реализации.
3. Постройте лестницу доказательств алгоритма
Первый уровень представляет собой математическую спецификацию с определенной задачей, входными данными, выходными данными и критерием правильности. Второй — воспроизводимое классическое моделирование. Третий — компиляция для именованной цели. Четвертый — выполнение на оборудовании с полными записями ресурсов и ошибок. Пятый — повторяющаяся производительность в зависимости от даты, устройства и экземпляра проблемы. Шестое — это принятый клиентом результат.
На каждом уровне должен быть заморожен пакет доказательств. Он должен содержать исходный код, зависимости, файлы среды, тестовые примеры, данные, начальные значения, настройки компилятора, целевые идентификаторы, записи калибровки, время очереди, время выполнения, снимки, постобработку, показатели стоимости и качества результата. Покупатель должен иметь возможность воспроизвести заявленный результат из чистой среды.
Алгоритмическая новизна не создает автоматически коммерческую ценность. Метод может быть интересным с научной точки зрения, в то время как классические альтернативы остаются быстрее, дешевле или точнее. Ценное приложение должно определять улучшенное решение, соответствующую базовую линию и условия, при которых квантовые или квантово-инспирированные вычисления меняют экономику.
Лестница должна определять наивысший уровень доказательности, достигнутый для каждого продукта. Портфолио может содержать зрелое программное обеспечение для диагностики ошибок, экспериментальные процедуры оптимизации и нефинансируемые исследования. Применение одного кратного дохода ко всем трем скрывает разницу. При оценке следует отдельно выделять достигнутую стоимость и стоимость условного опциона.
4. Измерьте эталонное качество
Бенчмарки должны отвечать на вопросы транзакций. Ориентированные на приложения тесты QED-C оценивают точность результатов, время выполнения и потребление ресурсов для разных алгоритмов и размеров задач. Они полезны, поскольку выходят за рамки одной метрики оборудования. Покупатель все равно должен проверить, отражает ли эталонный тест рабочие нагрузки целевого клиента и соответствует ли выбранная реализация платформе.
План тестирования должен включать отложенные экземпляры, классические базовые показатели и несколько целевых конфигураций. Он должен записывать время компиляции, ширину и глубину схемы, двухкубитные операции, снимки, время очереди, время выполнения, классическую постобработку, повторные попытки и общую стоимость. Качество решения должно быть определено до того, как станут известны результаты.
Версии оборудования и компилятора имеют значение. Результат может улучшиться за счет калибровки, транспиляции или устранения ошибок, а не за счет запатентованного алгоритма цели. Покупатель должен повторно запустить базовую реализацию через тот же стек и проверить вклад целевой системы посредством удаления. Собственное значение поддерживается, если улучшение сохраняется после контроля доступа и конфигурации.
Управление контрольными показателями должно предотвращать выборочную отчетность. Все попытки выполнения, исключения и неудачные запуски должны быть сохранены. Группа проверки должна понимать настройку параметров и то, требует ли развертывание клиентов аналогичного вмешательства специалиста. Результат, который зависит от ручной настройки под руководством основателя, может представлять собой ценность услуг или талантов, а не масштабируемый программный продукт.
5 Компилятор карт и зависимость от промежуточного представления
Квантовая компиляция включает в себя декомпозицию, отображение, маршрутизацию, планирование, оптимизацию, снижение импульсов и интеграцию во время выполнения. Приложение может вызывать библиотеку высокого уровня, в то время как производительность, повышающая ценность, находится в сторонних проходах или службах поставщика. Покупатель должен отслеживать каждое преобразование от источника до выполненного задания.
Граф зависимостей должен идентифицировать языки, библиотеки, промежуточные представления, компиляторы, плагины, целевые серверные части, симуляторы, облачные API и классические сервисы. Для каждого компонента при осмотре следует зафиксировать право собственности, лицензию, версию, техническое обслуживание, усилия по замене и эксплуатационную важность. Доступность открытого исходного кода снижает некоторый риск приобретения, одновременно создавая обязательства по управлению и совместимости.
Производительность компилятора должна тестироваться по цели. Проход, уменьшающий глубину одного графа связности, может принести ограниченную пользу в другом месте. Динамические схемы, измерение в середине цепи, сброс, доступ к импульсам и функции устранения ошибок могут изменить доступный алгоритм. Целевые профили QIR и документация поставщика должны быть согласованы с фактическими требованиями цели.
Покупатель должен воспроизвести чистую сборку без учетных данных основателя, локальных файлов или нераскрытых услуг. Он должен восстановить промежуточные артефакты и выполнить согласованный тест. Воспроизводимость сборки поддерживает переносимость. Он сам по себе не обеспечивает свободу действий, масштабирование или ценность для клиентов.
6 Тестирование переносимости между разными аппаратными модальностями
Модальности аппаратного обеспечения различаются возможностями подключения, собственными операциями, измерением, сбросом, когерентностью, длительностью шлюза, управлением и экономикой очередей. Сверхпроводящие системы, системы с захваченными ионами, нейтральными атомами, фотонные системы и системы отжига могут потребовать различных рецептур или выбора компиляции. Заявление о переносимости должно указывать поддерживаемый класс проблем и цель.
Матрица испытаний должна включать по крайней мере одну основную цель, одну надежную альтернативу и один симулятор или эмулятор. Одна и та же рабочая нагрузка должна использовать определенные входные данные и критерии приемки. Следует измерять различия в качестве решения, глубине, времени выполнения, повторных попытках и стоимости. Когда алгоритм существенно меняется в зависимости от цели, покупатель должен рассматривать каждую реализацию как отдельный поддерживаемый продукт.
Доступ провайдера может быть скрытым активом. Очереди приоритетов, зарезервированная емкость, информация о калибровке, инженерная поддержка и закрытые функции могут обеспечивать результаты, которые обычные клиенты не могут воспроизвести. Контракты должны быть проверены на предмет уступки, смены контроля, ценообразования, данных и непрерывности. Оценка должна отделить программное обеспечение от привилегированного доступа.
Мобильность также может ослабить дифференциацию. Если стандартное представление позволяет конкурентам легко перемещать эквивалентные алгоритмы, рвом могут оказаться данные, оптимизация, интеграция рабочих процессов или взаимоотношения с клиентами. В отчете о проверке должно быть указано, какой уровень остается собственностью после того, как программа будет реализована через открытые интерфейсы.
7 Diligence интеллектуальной собственности и открытого исходного кода
Покупатель должен сопоставить патенты, авторские права, коммерческую тайну, права на данные, лицензии и соглашения с партнерами для каждого продукта. В репозиториях исходного кода должно быть указано авторство, история коммитов, сторонние компоненты и выпуски. Задания для сотрудников и подрядчиков должны быть выполнены. Работа, финансируемая университетом или государством, может иметь дополнительные права и обязанности.
Программное обеспечение с открытым исходным кодом может ускорить внедрение и создать сообщество разработчиков. Это также может позволить конкурентам использовать основные возможности. Покупатель должен понимать, какие репозитории открыты, какие компоненты остаются собственностью и является ли изменение лицензирования юридически и коммерчески практичным. Обязательства по авторскому левому праву, атрибуции, уведомлению, патентам и перераспределению должны рассматриваться квалифицированным юристом.
Существенными могут быть данные обучения, молекулярные данные, наборы данных о клиентах и эталонные корпуса. Цель должна продемонстрировать происхождение, согласие, права на использование по договору, права на сохранение и передачу. Данные, полученные для конкретного проекта, не могут быть повторно использованы после приобретения. Синтетические или общедоступные данные могут быть заменяемыми и не должны иметь неподтвержденной ценности дефицита.
Коммерческая тайна требует оперативного контроля. Покупатель должен проверить доступ, документацию, шифрование, отключение и концентрацию знаний. Метод, известный только одному исследователю, должен оцениваться с учетом риска удержания и передачи. Патенты должны быть сопоставлены с реальным продуктом, а не подсчитаны.
8 Отделение дохода от продукта от финансирования исследований
Доходы от квантового программного обеспечения могут включать подписки, лицензии, профессиональные услуги, правительственные награды, сотрудничество в области исследований, поэтапные платежи и использование облака. Эти категории имеют разную повторяемость и валовую прибыль. Покупатель должен сверить договоры, счета-фактуры, приемку и денежные средства по клиентам и продуктам.
Регулярный доход должен требовать постоянных обязательств и надежной основы для продления. Многолетнее исследовательское соглашение может обеспечить контрактные денежные средства при финансировании индивидуальной работы. Пилотный проект может продемонстрировать бюджет и вовлеченность, не доказав соответствие продукта рынку. Гранты могут финансировать ценное развитие, но при этом имеют ограничения и ограниченную коммерческую рентабельность.
В когорте клиентов должны быть показаны начальные доходы, продления, расширение, сокращение, отток, услуги, доходы будущих периодов и сбор денежных средств. В нем должны быть указаны поставщик оборудования, рабочая нагрузка, версия продукта и поддержка специалистов. Концентрация может быть высокой, поскольку первые клиенты являются стратегическими партнерами. Покупатель должен проверить, выдержат ли эти отношения смену контроля или стратегии использования оборудования.
Прогнозы доходов не должны предполагать, что более широкая доступность оборудования автоматически создает спрос. Модель должна связать каждый сегмент клиентов с определенными возможностями, событием внедрения и стоимостью продажи. Неподтвержденные рыночные прогнозы должны оставаться за пределами моста достигнутой стоимости.
9 результатов усердной работы с клиентами
Отзывы клиентов должны быть сосредоточены на решениях и принятых результатах. Покупатель должен спросить, какая проблема была решена, какой классический базовый уровень существовал, какая цель использовалась, как были проверены результаты, какие ресурсы были потреблены и изменил ли клиент эксплуатационное решение. Опубликованное сотрудничество может быть стратегически значимым, не создавая постоянной экономической ценности.
Критерии приемки, где это возможно, должны быть договорными. Программное обеспечение по химии можно оценить по точности прогнозирования и экспериментальной проверке. Оптимизация может оцениваться по объективной ценности, осуществимости, времени выполнения и повторяемости. Диагностика ошибок может оцениваться по измеренному снижению или качеству проверки. Метрика должна соответствовать использованию клиентом.
Портативность должна быть протестирована на коммерческой основе. Если первоначальный поставщик недоступен или целевой объект приобретен конкурирующей компанией по производству оборудования, может ли клиент продолжить работу? Покупатель должен изучить прекращение действия, эксклюзивность, данные, право собственности на продукцию, обязательства по аудиту и поддержке.
Самым убедительным доказательством является неоднократное платное использование со стабильной экономикой доставки. Самым слабым является беззнаковое выражение интереса. При оценке следует использовать лестницу свидетельств клиентов, а не помещать все логотипы в стоимость конвейера.
10 Цените талант и научные ноу-хау
Команды квантового программного обеспечения могут объединять физиков-теоретиков, прикладных математиков, инженеров-компиляторов, ученых-специалистов, инженеров-программистов, руководителей продуктов и ученых-клиентов. Покупатель должен сопоставить каждую критически важную возможность с продуктами и этапами. Сами по себе названия организаций не указывают на техническую зависимость.
Цель может полагаться на основателей в вопросах разработки алгоритмов, доверия клиентов и ручной настройки. Ключевые инженеры могут владеть компилятором или системой развертывания. Ученые в предметной области могут перевести проблемы клиентов в разрешимые формулировки. Группа проверки должна выявить недокументированные знания и реалистичное время замены.
Удержание должно отражать работу после закрытия. Награды за оказанные услуги могут способствовать преемственности. В наградах Milestone должны использоваться воспроизводимые результаты и принятые для клиентов результаты. Компенсация должна избегать вознаграждения за выбор контрольных показателей или необоснованных заявлений о производительности.
Интеграция должна сохранить научную актуальность и дисциплину поставки программного обеспечения. Покупатель должен определить доступ к хранилищу, управление выпуском, безопасность, полномочия по архитектуре и владение продуктом. Приобретателю оборудования следует избегать принудительного размещения каждого приложения на собственной платформе до проверки его переносимости и потребительской ценности.
11 Оценка кибербезопасности и рисков в цепочке поставок программного обеспечения
Программные продукты Quantum наследуют классические программные риски. Покупатель должен проверить личность, привилегированный доступ, секреты, зависимости, конвейеры сборки, подпись пакетов, управление уязвимостями, ведение журналов, реагирование на инциденты и восстановление. Облачные токены и аппаратные учетные данные требуют особого контроля.
В спецификациях программного обеспечения должны быть указаны пакеты, версии, лицензии и известные уязвимости. Воспроизводимые сборки и защищенные конвейеры выпуска снижают риск того, что приобретенный продукт не удастся восстановить или ему нельзя будет доверять. Покупатель должен протестировать восстановление резервной копии и возможность ротации всех учетных данных при закрытии.
Данные клиентов и экспериментальные данные могут быть конфиденциальными. В контрактах и архитектуре должно быть указано, где хранятся входы, схемы, данные калибровки и выходные данные. Трансграничная обработка, экспортный контроль и отраслевые требования могут повлиять на интеграцию. Представления о безопасности следует проверять на основе журналов и инцидентов.
Стоимость восстановления включена в план оценки и интеграции. Ценный алгоритм со слабым программным контролем может потребовать работы с хранилищем, облаком и идентификацией, прежде чем его можно будет развернуть для регулируемых клиентов. Эти расходы не должны скрываться за общей синергией.
12 Стоимость замены модели и экономия времени
Стоимость замены должна оценивать команду, данные, эксперименты, программное обеспечение и время, необходимое для воспроизведения передаваемой возможности. Исторические затраты являются доказательством, но включают в себя неудачные пути и невозвратные затраты. Покупатель должен ценить текущую систему, документацию и обучение, которые сокращают надежную альтернативу.
Модель должна отделять объем кода от сложности. Небольшой проход компилятора может закодировать редкий опыт. Большой репозиторий приложений может содержать заменяемый код интеграции. Интервью с экспертами, история репозитория и воспроизведение эталонных тестов помогают выявить узкое место.
Сэкономленное время может быть ценным, если план развития оборудования или промышленности имеет фиксированное окно. Покупателю следует сравнить время покупки и интеграции с внутренней сборкой. Выгода должна быть уменьшена, если ключевые права, клиенты или сотрудники не могут быть переданы.
Открытые стандарты и платформы с открытым исходным кодом могут снизить стоимость замены. Они также могут расширить рынок и повысить ценность дополнительных запатентованных слоев. Оценка должна определить, усиливается или ослабляется ров цели по мере улучшения совместимости.
13 Постройте модель дохода
Модель дохода должна использовать данные клиентов, а не отдаленный квантовый прогноз рынка. Доходы должны быть сегментированы по продуктам, услугам, грантам и другим источникам. Валовая прибыль должна включать облачное исполнение, доступ к оборудованию, специализированную доставку, поддержку и сторонние лицензии. Зарплата за исследования и разработку продуктов должны оставаться видимыми.
Прогноз должен моделировать события конверсии. Пилотный проект преобразуется, когда приемка, закупки и бюджет удовлетворены. Подписка продлевается, когда продукт остается полезным для любого оборудования и версий. Сервисный проект становится доходом от продукта только тогда, когда доставка повторяется с меньшими усилиями по индивидуальному заказу.
Модель должна включать аппаратные зависимости. Если ценный рабочий процесс требует наличия возможностей поставщика, ожидаемых через два года, доход следует взвешивать по вероятности и осторожно капитализировать. Если цель сегодня получает доход от диагностики или моделирования, достигнутый денежный поток может поддержать традиционный анализ.
Конечная стоимость должна отражать технологические изменения и конкуренцию. Длительный период роста, не поддерживаемый когортами клиентов, создает ложную точность. Комитет по сделке должен сравнить доходный подход с восстановительной стоимостью и сценарной стоимостью.
14. Используйте систему показателей, адаптированную к переносимости
Оценочная карта должна охватывать доказательства алгоритма, переносимость, эталонное качество, интеллектуальную собственность, данные, результаты клиентов, качество доходов, команду, безопасность и взлетно-посадочную полосу. Каждая оценка должна быть связана с доказательствами и последствиями оценки. Высокая научная оценка не может компенсировать отсутствие владения или слабое признание клиентов.
Переносимость должна получать отдельные промежуточные оценки за источник, семантику, компиляцию, исполнение, производительность и коммерческую непрерывность. Покупатель должен определить минимальный уровень, требуемый тезисом о приобретении. Покупатель оборудования может согласиться на зависимость, которая усиливает его платформу. Нейтральному покупателю облака может потребоваться широкая переносимость производительности.
Оценочная карта должна показывать концентрацию. Цель может получить высокие средние оценки, находясь в зависимости от одного поставщика, ученого или клиента. Поэтому о неудачах при проверке следует сообщать отдельно от взвешенных оценок. Совет должен знать, какой вопрос может сделать диссертацию недействительной.
Результаты должны измениться после подтверждающих тестов. Модель должна сохранять доказательства и обоснование каждого обновления. Это поддерживает переговоры о ценах и подотчетность после закрытия сделки.
15 Учитесь на раскрытых комбинациях
Образование Quantinuum объединило Honeywell Quantum Solutions и Cambridge Quantum. В публичных заявлениях говорилось о компании, занимающейся интегрированным оборудованием и программным обеспечением, а также о долгосрочной производственной поддержке. Такое сочетание иллюстрирует тезис о вертикальной интеграции, включая возможность разрабатывать программное обеспечение для разных платформ, одновременно контролируя дорожную карту аппаратного обеспечения.
Приобретение компанией Keysight компании Quantum Benchmark добавило программное обеспечение для диагностики ошибок, подавления ошибок и проверки производительности в более широкий портфель квантовых решений. Раскрытое обоснование иллюстрирует ценность программного обеспечения, которое измеряет и улучшает аппаратное обеспечение. Он не раскрывает оценку отдельного алгоритма.
Компания Quantum Machines приобрела QDevil, чтобы расширить возможности квантового управления от уровня вентиля до кубита. SandboxAQ приобрела Good Chemistry, чтобы добавить в нее технологии вычислительной химии, клиентов и таланты. Эти транзакции иллюстрируют тезисы о стеке управления и предметных приложениях.
Эти примеры не следует рассматривать как прямые сравнения без согласования цен, доходов, прав и доказательств. Они полезны для определения стратегических маршрутов создания ценности: вертикальная интеграция, проверка, контроль, рабочий процесс в домене, таланты и доступ к клиентам. Цель должна быть сопоставлена с маршрутом, подтвержденным ее доказательствами.
16 Постройте гипотетическую оценку
В проработанном примере используется полностью гипотетическая цель квантового программного обеспечения. В нем сообщается годовой доход USD 18 million: регулярный доход от продуктов USD 11 million, услуги USD 4 million, гранты USD 3 million и другие доходы. Он имеет USD 96 million неограниченного использования денежных средств и USD 38 million ежегодного использования денежных средств. Эти суммы не отражают наблюдаемую компанию.
Центральное значение предприятия — USD 420 million. Он присваивает USD 105 million проверенным алгоритмам и приложениям, USD 90 million — активам компилятора и оркестрации, USD 60 million — отношениям с клиентами и контрактам, USD 45 million — собственным данным и рабочим процессам, USD 70 million — команде и ноу-хау, а USD 50 million — вариантам дорожной карты. Каждое значение является допущением руководства.
Четыре сценария проверяют переносимость. Ограниченный случай, в котором основной алгоритм остается привязанным к одному поставщику, имеет значение USD 140 million и вероятность 25 процентов. Случай с переносимым источником, но с переменной производительностью имеет значение USD 360 million и вероятность 40 процентов. Портативный продукт с высокой производительностью для постоянных клиентов имеет значение USD 820 million и вероятность 27 процентов. Категория «Платформа» с широким доступом к оборудованию имеет значение USD 1.80 billion и вероятность 8 процентов. Иллюстративное вероятностно-взвешенное значение составляет USD 508.4 million до интеграции, финансирования и разбавления.
Разница между центральным распределенным значением и значением сценария, взвешенного по вероятности, обнажает предположения. Покупатель должен учитывать стоимость интеграции, удержание, согласие клиента, контракты на оборудование и финансирование. Условное вознаграждение может привести оплату в соответствие с тестами на переносимость и удержанием клиентов.
17 Структурируйте рассмотрение доказательств
Первоначальным взносом можно оплатить контролируемый код, права, денежный поток и передаваемые возможности. Отсроченные платежи могут зависеть от чистой сборки, выдержанного многоцелевого теста, удержания клиентов или принятого выпуска продукта. Вознаграждения за удержание должны вознаграждать за службу и передачу знаний.
Вехи должны указывать цели, версии, рабочие нагрузки, базовые показатели, показатели и независимую проверку. Общее требование, чтобы программное обеспечение оставалось независимым от аппаратного обеспечения, вызывает споры. Более эффективный этап заключается в том, что определенные рабочие нагрузки компилируются и выполняются в соответствии с согласованными целями, соблюдая при этом пороговые значения качества, времени и стоимости решения.
Соглашение должно предусматривать технические изменения. Новое оборудование может заменить исходную цель. Правила замены должны сохранять экономическую эквивалентность и препятствовать тому, чтобы какая-либо из сторон выбрала искусственно простой или невозможный тест. Квалифицированные консультанты должны рассмотреть последствия бухгалтерского учета, налогообложения, занятости и ценных бумаг.
Покупатель также должен защищать данные и непрерывность обслуживания клиентов. Согласия, услуги перехода, доступ к облаку и восстановление безопасности могут быть закрывающими условиями или соглашениями. Эскроу может устранить выявленные пробелы в правах. Каждая защита должна соответствовать риску, связанному с перемещением стоимости.
18 Планируйте первые сто дней
Первые тридцать дней должны обеспечивать безопасность репозиториев, учетных данных, облачных учетных записей, данных клиентов и конвейеров выпуска. Покупатель должен утвердить критически важный персонал, заморозить исходные данные и сохранить доступ поставщиков. Коммуникации с клиентами должны объяснять непрерывность, не давая необоснованных обещаний о производительности.
Дни от тридцати до шестидесяти должны воспроизводить сборки, повторно запускать ключевые тесты, составлять карту архитектуры продукта и проверять обязательства клиентов. Команда интеграции должна отделить общие услуги от защищенной научной работы. Объединенная дорожная карта должна определить, какие платформы продолжают поддерживаться и почему.
Дни с шестидесяти до ста должны рационализировать дублирующиеся инструменты, утвердить матрицу продуктов и оборудования, устранить проблемы безопасности и протестировать передачу знаний. Коммерческим руководителям следует пересмотреть планы ценообразования, поддержки и обновления. Финансовые органы должны согласовать расходы на интеграцию и определить этапы прогресса с инвестиционным обоснованием.
Совет директоров должен получить отчет о реализации ценности. Он должен показать достигнутый синергизм, сохраненных клиентов, доказательства переносимости, использование денежных средств, риски и последующие решения. Техническое обучение должно обновлять оценочные допущения, а не отражаться только как деятельность.
Заключение
Ценность программного обеспечения Quantum не определяется аппаратно-независимым ярлыком. Это зависит от того, в какой степени алгоритмы, компиляторы, рабочие процессы и результаты работы клиентов выдерживают изменение среды выполнения. Перевод исходного текста, успешная компиляция и эквивалентное коммерческое исполнение — это разные состояния доказательства.
Покупатель должен построить лестницу доказательств алгоритма, граф зависимостей, матрицу переносимости, план тестирования и когорту клиентов. Он должен воспроизводить сборки, контролировать функции провайдера, измерять качество и время решения, подтверждать права и выверять денежные средства клиентов. Достигнутые активы должны быть отделены от условной стоимости дорожной карты.
Открытые представления и стандарты могут снизить затраты на переключение, одновременно раскрывая ограничения возможностей для конкретных целей. Стратегические комбинации показывают, что программное обеспечение может создавать ценность за счет вертикальной интеграции, диагностики, управления и предметных приложений. Ценность конкретной цели по-прежнему требует подтверждения конкретной транзакции.
Советы директоров могут использовать эту структуру, чтобы решить, следует ли приобретать, инвестировать, лицензировать, сотрудничать или строить. Каждый компонент материальной ценности должен указывать на контролируемые права, воспроизводимую производительность, приемлемые результаты для клиентов или явно сформулированное предположение руководства. Рассмотрение должно быть продолжено, когда эти доказательства изменятся.
Приложение A Протокол испытаний на переносимость
Протокол должен заморозить исходный код, зависимости, версии компилятора, целевые профили, данные, начальные значения и критерии приемки. Он должен включать в себя основную цель, надежную альтернативу и симулятор или эмулятор. Цель должна быть построена из чистой среды с использованием документированных учетных данных и инфраструктуры.
При каждом запуске должно регистрироваться время компиляции, ширина и глубина схемы, собственные операции, снимки, время очереди и выполнения, классическая постобработка, повторные попытки, общая стоимость и качество решения. Исключения и неудачные прогоны должны оставаться в протоколе. Базовая реализация должна использовать тот же доступ и конфигурацию.
В отчете следует классифицировать источник, семантику, компиляцию, исполнение, производительность и коммерческую переносимость. В нем должно быть указано, какие изменения потребовались и формируют ли они сохраняемые отрасли продуктов. Независимые рецензенты должны иметь достаточный доступ для воспроизведения заключения.
Приложение B. Доказательства клиентов и доходов
В графике клиента должны быть указаны юридический контрагент, продукт, рабочая нагрузка, поставщик оборудования, срок, гарантированная стоимость, услуги, приемка, выставление счетов, денежные средства, продление и смена контроля. Финансирование исследований и гранты должны быть отделены от постоянного дохода от продукции.
Когортный анализ должен показать открытие регулярного дохода, новых клиентов, расширение, сокращение, отток и закрытие повторяющегося дохода. Она должна свериться с бухгалтерскими записями. Трубопровод должен оставаться за пределами контрактных доходов и должен определять закупочные, технические и бюджетные ворота.
Отзывы клиентов должны подтверждать поддерживаемое решение, исходные данные, принятые результаты, усилия специалистов и будущие намерения. Покупатель должен проверить, сохранятся ли отношения при смене оборудования или владельца.
Приложение C. Комната данных оценки.
Комната технических данных должна содержать репозитории, инструкции по сборке, блокировки зависимостей, спецификации программного обеспечения, лицензии, соглашения с участниками, патенты, права на данные, тесты, необработанные записи выполнения, целевые конфигурации, записи безопасности и историю инцидентов. Он должен включать негативные и неудачные эксперименты.
Коммерческие записи должны включать контракты, отчеты о работе, гранты, счета-фактуры, денежные поступления, журналы поддержки и использования. Финансовые отчеты должны согласовывать категории доходов, валовую прибыль, расходы на исследования, денежные средства, обязательства и ежемесячное использование денежных средств.
В отчете о проверке должно быть указано, что было воспроизведено, отобрано, недоступно или оспорено. Каждый нерешенный пробел должен проявиться в цене, структуре, бюджете интеграции или условиях одобрения.
Приложение D. Реестр стоимости интеграции
В реестре стоимости интеграции следует различать доходы, затраты, капитал и стратегические эффекты. Эффекты на доход могут включать удержание клиентов, перекрестные продажи, доступ к новой платформе и более быструю конверсию от пилотных проектов. Экономические последствия могут включать в себя удаление дублированной инфраструктуры, усиление закупок и снижение затрат на внешние лицензии. Эффекты капитала включают отказ от внутренней разработки и сокращение времени до выпуска следующего продукта. Стратегические эффекты включают контроль над критически важным компилятором, рабочим процессом, активом данных или интерфейсом клиента.
У каждого объекта должны быть базовые данные, ответственный владелец, сроки, необходимые расходы и источник доказательств. Валовую оценку синергии следует уменьшить из-за оттока клиентов, выхода из строя продуктов, вознаграждений за удержание, миграции в облако, устранения проблем безопасности, поддержки дублированной платформы и налогов. Выгоды, которые зависят от будущего оборудования, должны быть взвешены по вероятности и показаны отдельно от краткосрочных действий.
Реестр должен предотвращать двойной учет. Переносимость алгоритма может способствовать удержанию клиентов и снижению затрат на восстановление, однако одна и та же выгода не должна проявляться в обеих линиях без согласования. Покупатель также должен отличать стоимость, переданную от другой бизнес-единицы, от стоимости, созданной для объединенной группы. Перемещение затрат на облачные технологии или разработку в центральный бюджет само по себе не создает ценности для предприятия.
Отчеты после закрытия должны сравнивать реализованную стоимость с утвержденным случаем. Технические показатели должны быть связаны с коммерческими результатами. Успешный многоцелевой тест имеет ограниченную транзакционную ценность до тех пор, пока он не снизит затраты на поддержку, не удержит клиента, не расширит распространение или не разблокирует продукт. К обновлению клиентов следует относиться с осторожностью, если оно также зависит от продаж, прогресса в оборудовании или цен.
Совет должен проверять реестр через определенные промежутки времени и пересматривать инвестиционное обоснование при изменении доказательств. Недостигнутая ценность должна стать причиной принятия решения о продукте, капитале или интеграции. Цель состоит в том, чтобы сохранить прослеживаемую связь между тезисом о приобретении, техническими доказательствами, денежными средствами и подотчетным исполнением.
Приложение E. Цифры и таблицы решений
Предлагаемая последовательность; каждый этап требует воспроизводимой записи и определенных приемочных испытаний.
Полностью гипотетические предположения руководства; Оценка сочетает в себе нормализованное качество решения, время и стоимость.
Полностью гипотетические предположения руководства; USD миллионов.
Полностью гипотетические предположения руководства; USD миллионов.
Полностью гипотетические предположения руководства; USD миллионов.
| Слой | Тест | Распространенная ошибка | Использование оценки |
|---|---|---|---|
| Источник | Код переводится или выражается через общий язык. | Синтаксис меняется, а зависимости остаются | Ограниченные доказательства возможности передачи |
| Семантический | Математическое намерение остается эквивалентным | Целевые ограничения меняют метод | Корректировка доказательств алгоритма |
| Сборник | Программа опускается в целевой стек | Неподдерживаемое управление, шлюзы или функции времени выполнения. | Стоимость ретаргетинга |
| Исполнение | Полный рабочий процесс выполняется в поддерживаемых условиях | Скрытая услуга поставщика или ручное вмешательство | Достигнутый тест возможностей |
| Производительность | Качество, время и стоимость остаются в пределах пороговых значений | Эквивалентный выпуск становится нерентабельным | Стоимость продукта и опции |
| Коммерческий | Клиент принимает, платит и продлевает | Смена оборудования или владельца нарушает внедрение | Отношения и величина дохода |
Предлагаемая иерархия; каждый слой требует своих собственных доказательств.
| Этап | Обязательная запись | Независимая проверка | Процедура оценки |
|---|---|---|---|
| Математическое утверждение | Задача, предположения и критерий корректности | Экспертный обзор | Только вариант исследования |
| Воспроизводимое моделирование | Код, данные, начальные значения и классическая базовая версия | Повторный показ чистой окружающей среды | Ноу-хау и ценность кода |
| Целевая компиляция | Компилятор, профиль, схемы и записи ресурсов | Повторить сборку | Условное значение реализации |
| Аппаратное исполнение | Работы, калибровка, снимки, время, стоимость и производительность | Удерживаемый бег | Достигнутые технические доказательства |
| Перекрестная целевая эффективность | Сопоставимые цели и пороги приемлемости | Независимый бенчмарк | Повышение портативности |
| Принятие клиента | Договор, доставка, счет-фактура и наличные | Сверка клиентов и бухгалтерского учета | Коммерческая ценность |
Предлагаемая последовательность проверки транзакции.
| Слой | Доказательство | Риск зависимости | Значение значения |
|---|---|---|---|
| Языки и библиотеки | Репозитории, версии, лицензии и тесты | Критические изменения и бесхозные компоненты | Стоимость обслуживания и ремонта |
| Промежуточное представительство | Профили, преобразования и проверка | Неподдерживаемая семантика или целевые функции. | Регулировка портативности |
| Компилятор и проходы | Сборка, тесты, владение и документация | Целевая оптимизация | Достигнутая стоимость актива или ретаргетинга |
| Аппаратное обеспечение и облако | Контракты, доступ, очереди, цены и возможности | Концентрация поставщиков и смена контроля | Производительность и настройка под клиента |
| Классический рабочий процесс | Данные, HPC, AI, постобработка и оркестровка | Квантовый иск зависит от классических активов | Распределение ценности по всей системе |
Предлагаемый минимальный обзор цепочки выполнения программного обеспечения.
| Компонент стоимости | Примерная сумма | Ворота для доказательств | Обратное лечение |
|---|---|---|---|
| Проверенные алгоритмы и приложения | USD 105 million | Воспроизводимые критерии и права | Сдерживание портативности |
| Компилятор и оркестровка | USD 90 million | Чистая сборка, целевые доказательства и право собственности | Восстановительный резерв |
| Отношения с клиентами и договоры | USD 60 million | Принятие, продление, наличные и согласие | Регулировка удержания |
| Собственные данные и рабочие процессы | USD 45 million | Происхождение, права передачи и вклад | Удержание прав |
| Команда и ноу-хау | USD 70 million | Сохранение критически важных ролей и передача знаний | Удержание на основе услуг |
| Варианты дорожной карты | USD 50 million | Финансируемая переносимость и основные этапы работы с клиентами | Условное вознаграждение |
Полностью гипотетические предположения руководства; не наблюдаются данные о компании или транзакции.
| Доказательство | Что он поддерживает | Ограничение | Использование оценки |
|---|---|---|---|
| Исследовательское сотрудничество | Доступ и техническое участие | Может не хватать регулярного бюджета или принятия | Доказательства родства |
| Грант или награда | Финансируемый объем и политическая поддержка | Ограниченное использование и ограниченное рецидивирование. | Денежные средства по контракту с условиями |
| Платный пилот | Бюджет клиента и заданный эксперимент | Индивидуальная работа может не масштабироваться | Преобразование с поправкой на вероятность |
| Принятая поставка продукции | Производительность в соответствии с согласованными критериями | Не устанавливает продление | Стоимость контракта и доставки |
| Повторное платное использование | Постоянный бюджет и оперативная актуальность | Может оставаться зависимым от поставщика | Более убедительные доказательства дохода |
Предлагаемая классификация проверки доходов.
| Мера | Примерная сумма | Вопрос о усердии | Последствия оценки |
|---|---|---|---|
| Регулярный доход от продукта | USD 11 million | Продление, маржа и переносимость | Поддержка дохода |
| Доход от услуг | USD 4 million | Усилия основателя и повторяемость | Корректировка услуг |
| Гранты и другие доходы | USD 3 million | Ограничения и рецидивы | Отдельно от нескольких продуктов |
| Неограниченные наличные | USD 96 million | Доступность и обязательства | Сверка стоимости акционерного капитала |
| Годовое использование денежных средств | USD 38 million | Следующий этап предоставления доказательств и сроки финансирования | Регулировка взлетно-посадочной полосы и разбавления |
Полностью гипотетические предположения руководства; USD миллионов.
| Область принятия решений | Зеленые доказательства | Янтарное состояние | Красное состояние |
|---|---|---|---|
| Портативность | Отложенные рабочие нагрузки соответствуют пороговым значениям качества, времени и затрат в рамках согласованных целей. | Переносимость исходного кода и исполнения с изменением производительности. | Маркетинговое заявление без воспроизводимых целевых доказательств |
| Права | Код, данные, лицензии и права участников подтверждены | Ограниченное исправление со стоимостью и датой | Критически важные возможности, не принадлежащие владельцу или не подлежащие передаче |
| Клиенты | Платный прием, продление и сверка денежных средств | Пилотное или финансируемое исследование с планом конверсии | Логотипы или конвейер рассматриваются как регулярный доход. |
| Команда и безопасность | Критические роли сохранены; чистая сборка и передача доступа пройдены | Документированный план исправления и сохранения | Требуются учетные данные основателя или небезопасная цепочка поставок |
| Оценка | Достигнутые активы и условные опционы разделены | Широкий, но явный диапазон сценариев | Прогноз рынка заменяет доказательства |
Предлагаемая структура принятия решений.
Источники
- Консорциум квантового экономического развития, Ориентированные на приложения тесты производительности квантовых вычислений. Прочтите первоисточник
- Консорциум квантового экономического развития, Исследование квантовых алгоритмов с использованием тестов производительности, ориентированных на приложения, 2024 г. Прочтите первоисточник
- Консорциум квантового экономического развития, Технический консультативный комитет по стандартам и показателям эффективности. Прочтите первоисточник
- Microsoft Azure Quantum, промежуточное квантовое представление. Прочтите первоисточник
- Microsoft Azure Quantum, целевые профили QIR в пакете разработки Quantum, 2026 г. Прочтите первоисточник
- Microsoft Azure Quantum, серверные квантовые симуляторы от квантовых поставщиков, 2026 г. Прочтите первоисточник
- OpenQASM, действующая спецификация OpenQASM 3. Прочтите первоисточник
- Кросс и его коллеги, OpenQASM 3: более широкий и глубокий язык квантового ассемблера, Транзакции ACM в квантовых вычислениях, 2022 г. Прочтите первоисточник
- Amazon Web Services, поддержка OpenQASM на различных устройствах Amazon Braket. Прочтите первоисточник
- Amazon Web Services, функции OpenQASM, поддерживаемые Amazon Braket. Прочтите первоисточник
- IBM Quantum, документация по транспилятору Qiskit. Прочтите первоисточник
- IBM Quantum, серверная и целевая документация. Прочтите первоисточник
- Google Quantum AI, документация Cirq. Прочтите первоисточник
- Документация NVIDIA, CUDA-Q. Прочтите первоисточник
- NVIDIA, документация cuQuantum SDK, 2026 г. Прочтите первоисточник
- Ксанаду, документация PennyLane. Прочтите первоисточник
- Linux Foundation, Альянс QIR. Прочтите первоисточник
- Национальный институт стандартов и технологий, квантовая информатика. Прочтите первоисточник
- ISO, ISO/IEC 4879:2024 Квантовые технологии; Словарный запас. Прочтите первоисточник
- Полное объединение бизнеса Honeywell, Honeywell Quantum Solutions и Cambridge Quantum, 2021 г. Прочтите первоисточник
- Quantinuum, Представляем Quantinuum, 2021. Прочтите первоисточник
- Quantinuum, заявление о регистрации, поданное в Комиссию по ценным бумагам и биржам США, 2026 г. Прочтите первоисточник
- Keysight Technologies, Keysight Technologies приобретает Quantum Benchmark, 2021 г. Прочтите первоисточник
- Quantum Machines, Quantum Machines приобретает QDevil, 2022. Прочтите первоисточник
- SandboxAQ, SandboxAQ приобретает Good Chemistry, 2024 г. Прочтите первоисточник
- Фонд МСФО, МСФО 3 «Объединения бизнеса». Прочтите первоисточник
- Фонд МСФО, МСФО (IFRS) 13 «Оценка справедливой стоимости». Прочтите первоисточник
- Фонд МСФО, МСФО (IAS) 38 «Нематериальные активы». Прочтите первоисточник
- Совет по международным стандартам оценки, Международные стандарты оценки. Прочтите первоисточник
- Комиссия США по ценным бумагам и биржам, Руководство по финансовой отчетности. Прочтите первоисточник
- Национальный институт стандартов и технологий, платформа безопасной разработки программного обеспечения SP 800-218. Прочтите первоисточник
- Национальный институт стандартов и технологий, Структура кибербезопасности 2.0. Прочтите первоисточник
