面向私营火箭公司的发射放行 OS，把测试、供应商和装配数据拧成更快进入任务就绪状态的发射流程。

1. 新增资本正被投向制造扩张和发射节奏，这让预算开始流向运营工具，而不再只投研发。
2. 既然目标在 6 月入轨，发射团队就不可能等多年 ERP 项目落地后再来收紧放行纪律。
3. 把目标定在 72 小时装配到发射，意味着手工签核链和基于表格的构型跟踪已经不可持续。
4. 印度首家私营航天独角兽既拉出了一个锚定客户群，也说明私营发射正在变成真正的工业品类，而不再只是科学项目。

催化因素。 Skyroot 一边扩制造、一边冲 6 月轨道发射，还在追 72 小时装配到发射能力，这让提高发射可重复性的运营软件一下子变得很急。

产品贴在现有 PLM、ERP、测试系统和基于表格的质量流程旁边，为每一枚运载器拉出一条面向具体任务的数字化放行线程。它把资格测试结果、供应商文件、装配记录和后期工程变更接进来，再映射到受影响的具体级段、发动机、航电批次和任务。团队拿到的是自动化偏差影响分析、发射准备检查清单，以及一份能同时服务内部放行/否决评审和客户准备度更新的统一放行包。最初这套切口很轻，可以先从 CSV 和文档库起步，而不是一上来替掉整套 MES；但时间一长，它会慢慢长成发射放行决策的系统记录。

差异化。 传统航空航天软件管的是工程记录或工厂执行，靶场软件管的是发射当天本身。这家公司盯住的是中间那层最折磨人的流程：创业型发射团队得先把供应商偏差、测试证据和最终飞行器构型对齐，才敢做放行决策。它若从印度私营航天运营商切入，就能把大型航空航天套件视作边角料的新航天工作流和供应商现实编码进去。

待完成任务

flowchart LR
  Buyer[任务保障负责人] --> Pain[分散的资质与装配证据]
  Pain --> Product[发射放行控制塔]
  Product --> Outcome[更快且可审计的放行/否决决策]

高管要点

• 印度私营航天这条线已经成形，而且还在往上走；但眼下能打进去的发射放行软件滩头市场仍然很窄。KPMG 估算行业当前规模约为 $8.4B，到 2033 年可到 $44B；Skyroot 和 Agnikul 则说明赛道正在从资格验证项目切到商业化发射运营 [3][1][14]。
• 真正扎手的痛点不是火箭 CAD，而是放行纪律怎么落地。Skyroot 正把新资金砸向 Vikram-1 节奏和制造扩张，还要冲 72 小时装配到发射，这会把分散的测试、供应商和偏差记录放大成更贵的问题 [2]。
• 现有厂商已经把底层工作流需求坐实了——质量、变更、追溯和数字线程控制都有人卖——但 Siemens、PTC、Dassault 和 Tulip 卖的是宽平台，不是首批商业发射最缺的那座任务保障控制塔 [60][62][69][76]。
• 自下而上的测算说明，印度优先的发射与航天硬件切口，本质上只是一个低个位数百万美元的软件市场。要把它讲成风投故事，必须从发射放行往卫星、国防和航空航天硬件项目扩 [3][8][9]。
• 最靠谱的 GTM 不是做“大拆大建”的 MES，而是贴着现有 PLM/QMS/文档栈，由创始人高触达推进；因为无论标准机构还是现有厂商，都在强调正式基线、变更控制和可追溯性 [64][60][81][87]。

市场定义

这是一个面向私营发射与航天硬件运营商、以印度优先的任务放行与偏差控制软件市场。核心工作，是把资格证据、供应商历史、不合格项和最终飞行器构型拧成一份针对具体任务的可审计放行/否决包。纳入的相邻场景包括发射准备、变更控制、质量/合规、谱系追踪和跨系统证据汇总；排除项则包括发射当天的靶场软件、单独的通用 PLM，以及完整替换 MES 的项目 [2][8][60][64][77][81]。

用户与买方

ICP 是那些正从资格验证走向可重复商业运营的印度私营发射、推进、卫星或任务服务公司。日常使用者会是任务保障、制造、质量和发射运营负责人；预算通常握在 COO、制造副总裁或任务保障负责人手里，因为这套产品直接碰发射节奏、供应商风险和放行责任 [1][2][8][14][43][45]。

购买触发点

• 首次商业发射任务，或试飞后的节奏爬坡，让人工准备评审变得过慢。 [1][2][14]
• 新的制造设施、产线或拿到资金后的扩张，会同时放大供应商数量和偏差量。 [2][15][16][43][17]
• 授权获批、服务上线或出口推进，会抬高对更干净审计链路和正式放行记录的需求。 [5][45][85][86]

支付意愿

抓到的现有厂商页面几乎清一色是演示驱动、面向企业：Siemens、PTC、Dassault 和 Tulip 都在讲能力，但没人挂公开自助价。这说明早期合同更适合按 ROI 来卖——每个活跃项目的年合同额大致落在高五位数到低六位数之间；不过在买方访谈真正确认预算权之前，准确 ACV 仍然只能算估值区间 [60][63][69][72]。 [60][63][69][72]

品类动态

增长信号 以印度航天经济从 2022 年 $8.4B 增至 2033 年 $44B 推算，年复合增长率代理值为 16.2%

验证信号

• Skyroot 已明确把资金投向发射节奏与制造扩张，其中就包括 72 小时装配到发射的目标。
• Agnikul 已经完成了一次民营自建火箭发射里程碑，证明印度发射创业公司正在进入运营阶段。
• Bellatrix 在拿下首个印度以外的大型商业客户后融资，以提升推进系统产能。
• Dhruva 把新增资本绑定在全栈扩张和航天器制造设施建设上。
• Pixxel 仍在持续融资以部署运营中的星座，这说明相邻的私营航天工作流复杂度在上升，而不是在下降。

监管与技术约束

• 印度私营航天活动凡是需要授权的，都必须提供结构化证据，并满足 IN-SPACe 条件。
• 正式的构型管理纪律，是航天系统工程和产品保障里的标准做法。
• 一旦扩展到盟友发射市场，就会继承类似 FAA 的许可与文档负担。
• 技术上能否成功，取决于先与现有的质量、PLM 和追溯栈集成，而不是立刻替换它们。

竞争基本分成四路。Siemens 和 Dassault 卖的是最重型的航空航天数字线程与质量套件 [60][61][68][70]。如果客户要把需求、变更和航天系统工程从设计一路串到制造，PTC 最强 [62][63][64]。Tulip 则是最近的现代运营层替代品，能覆盖不合格项、谱系追踪和一线工作流采集，但它的重心仍在工厂现场，不在任务放行 [72][76][77]。而真正的默认替代方案，依旧是内部表格、汇报材料，以及东拼西凑的 PLM/QMS/文档导出文件——因为早期买方群体既小又专业 [2][83][64]。

为什么现有厂商不会默认胜出

• PLM 与数字线程套件. Siemens、PTC 和 Dassault 已经证明追溯、质量和工程变更控制确实有需求，但它们通常是以宽泛的转型平台形态落地，而不是一个能迅速切进去的发射放行切口。
• 车间层 QMS 与 MES 平台. Tulip 能采集不合格项、谱系和作业指导数据，但这些能力不会自动长成一份跨测试、供应商和飞行器构型的任务专属准备包。
• ALM 与需求管理工具. Windchill 和 Codebeamer 这类工具适合管需求和正式变更，但买方在临近发射时，仍然需要一座更窄的控制塔来接住偏差和放行决策。
• 内部工作流栈. 内部自建看上去可能更便宜，但节奏一旦拉高、授权要求一旦变严，临时拼证据这套做法会越来越扛不住。

Skyroot 的融资、6 月轨道发射目标和 72 小时装配到发射目标，把一个很具体的软件切口推到了台前：把分散的资质、供应商和装配数据收成一份可审计的发射放行包。首个客户最该瞄准印度私营发射公司里、正从资格飞行迈向首批 3–10 次商业发射的任务保障或制造负责人，因为在企业级大改造预算出现之前，最先被节奏压到喘不过气的就是这支团队。产品起步应该是一层贴在 PLM、ERP、测试系统和共享盘旁边的轻量放行控制层，而不是去替换 MES 或发射当天的靶场软件。GTM 也该由创始人亲自带，围绕资格成功、第一份商业发射合同或产能扩张这些触发点推进；先在一个活跃飞行器项目上做付费试点，再转成年化按项目收费。这个切口有吸引力，是因为现有厂商已经把追溯和质量控制需求教育得很充分，但它们的套件更宽、更慢，也不适合处理创业公司那种凌乱又高压的发射准备工作流。不过，印度优先的滩头市场还是太小：研究给出的 SAM 约为 $1.5M，第 3 年 SOM 约为 $0.4M，所以要把故事讲成风投故事，必须尽快往卫星、推进、国防和盟友市场的硬件放行工作流扩。眼下最大的未知数，是准备度评审到底吃掉多少人工、预算权到底握在谁手里，以及买方会不会在更大规模的 PLM 或 MES 项目之前，先为一层聚焦的放行控制层买单。所以，第一个年度真正要做的，不是宣告自己开辟了一个大品类，而是先跑出 1 个生产部署、证明时间真的省下来了，并沉淀出可复用的连接器和合规打法。

问题

• 准备首批商业任务的发射团队，仍在从表格、PLM 导出文件、测试日志、供应商文件和聊天记录里拼装放行/否决材料，因此每次放行评审都慢且容易出错。
• 当节奏目标压缩到以天计算时，只要有一项偏差未闭环、缺一条供应商批次记录，或飞行器构型信息过期，就足以拖延发射，让管理层同时暴露在审计、客户和任务风险下。
• 现有替代方案要么是内部手工流程，要么是宽而重的 PLM 与质量套件，都不足以为创业公司发射项目快速打包那些临门一脚的任务准备决策。

解决方案

• 交付一套发射放行控制塔，从现有系统接入资格证据、供应商记录、不合格项和装配状态，为单个飞行器项目组装出面向具体任务的数字化放行线程。
• 先从基于 CSV、文档库和导出文件的导入能力开始，让客户能贴着现有工具部署；之后再加上偏差影响分析、受控签核工作流，以及供内部和面向客户的准备评审使用的可审计放行包。

为什么我们会赢

• 这个切口卡在工程系统和发射当天执行之间那段最痛的运营空档里：现有厂商证明了追溯需求存在，却没人卖一套真正快的任务放行工作流。
• 相比替换 MES 或 PLM，轻量叠加式部署的采用摩擦更低，也更贴近早期私营航天团队今天真实的干活方式。
• 面向发射的专用放行模板、供应商追溯映射，以及哪些因素拖慢或放行任务的结果数据，都会慢慢沉淀成能守住的工作流 IP。

里程碑

flowchart LR
  Wedge[发射放行试点] --> MVP[导入优先的放行控制塔]
  MVP --> Proof[更快且可审计的放行/否决决策]
  Proof --> Expansion[相邻航天硬件放行工作流]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少有 2 家首批发射或航天硬件运营商，会在承诺更大规模的 PLM 或 MES 改造之前，先为付费试点买单。
• MVP 能在真实项目里把放行包准备时间至少压缩 30%，同时保持完整的签核与证据追溯。
• 真正的经济买方能稳定落在 COO、制造副总裁或任务保障负责人，而不是没有预算的创新团队。
• 生产合同的价格能落在研究所示的约 ~$100k ACV 区间，而不是沦为服务占比过高的定制项目。
• 至少有 3 个相邻的航天器、推进或国防硬件潜在客户证明，这套工作流在产品改动有限的前提下可以迁移到发射之外。

待尽调问题

• 当前一套发射准备包，究竟吃掉了任务保障、制造和质量团队多少人时？
• 前 5 个目标账户里，究竟哪些源系统主导了这条工作流？它们的导出格式有多标准化？
• 在更大规模的数字线程项目获得预算前，买方会批准一个付费叠加式试点吗？
• 为什么 Siemens、PTC、Dassault、Tulip 或内部看板，满足不了首个客户眼前的工作流需求？
• 未来 24 个月里，印度优先买方群体中到底有多少个近期活跃项目？

模型合理性

• 收入引擎. 基准情景下，第 3 年收入来自 4 个活跃项目、每个项目 ACV 约 $96K，这和研究里的 SOM 以及商业计划里的里程碑节奏是一致的。
• 必须跑通的条件. 首个付费项目必须在 M7 前拿下，还得足够快沉淀出可复用连接器模式，才能在不加完整销售团队的前提下，于 Q4Y2 前跑到 3 个生产项目。
• 模型失效条件. 如果 ACV 滑向 $72K，或者第 4 个项目拖到第 3 年以后，现金就会收缩到接近下行情景，印度优先切口也撑不起原定建设计划。
• 下一轮融资证明点. 只有当 4 个活跃生产项目、低于 6 周的部署时长，以及 1 个相邻航天器或推进工作流一起证明这套切口能扩到印度发射运营之外时，下一轮融资才站得住脚。

情景

敏感性

flowchart LR
  Triggers[资格成功 / 产能爬坡] --> Pilots[付费试点]
  Pilots --> Programs[活跃项目]
  Programs --> Revenue[项目收入]
  Revenue --> GrossProfit[70% 毛利润]
  GrossProfit --> Cash[支撑相邻验证的现金跑道]

警示项: 印度优先滩头市场的 SAM 只有约 $1.5M，因此模型必须依赖相邻的航天器与推进工作流，才能讲出风险投资级的后续故事。 · 到第 3 年为止，收入效率依然偏弱，因为团队是刻意按跑在“小型纯发射市场”前面的规模来配的。 · 第 3 年的 Rule of 40 依然为负；这是一份验证市场的 pre-seed 计划，不是一份追求效率的模型。 · 即便融资 $2.2M，现金低点仍出现在 Q4Y3；所以如果首个试点更慢，或者部署更定制化，下一轮融资大概率会被提前。

• 初始客户基数太小. 印度私营发射服务商数量就那么多，单靠这个滩头市场，未必撑得起一家独立的风投级公司。 缓解措施: 从第一天起就按卫星、国防和航空航天硬件这些相邻场景来设计产品，同时把发射当成最先验证的战场。
• 企业集成推进缓慢. 如果上新系统等于要在项目中途拆掉现有 PLM 或 MES，发射团队大概率会本能抗拒。 缓解措施: 先从能吃进现有导出文件和文档的轻量放行包层开始，等真把时间省下来之后，再逐步把集成做深。
• 现有厂商或自研替代压力. 客户很可能先试着把现有 PLM 工作流往外撑，或者在内部自己搭一个准备度看板。 缓解措施: 把重点钉在发射专属的偏差逻辑、任务级放行产物和跨职能签核工作流上——这些东西不是通用系统能很快抄出来的。