发布时间:2026-10-14 10:52:30
阅读量:58409
分类:

图:合并报表软件厂商三档:产品型、平台型、生态型(贝则科技)
直接回答:合并报表软件厂商可以分成三档:产品型、平台型、生态型。产品型把标准合并做成一款软件,按模块卖许可;平台型卖的是一套能承载复杂股权与多准则并行的引擎,落地主要靠伙伴;生态型把合并功能长在 ERP 里,跟 ERP 一起卖。分档不看品牌大小,只看两件事:产品能承载多复杂的结构,超出标准能力的部分靠什么方式扩展。定错档,后面的报价、工期与人员配置都会跟着错。
这一档分法有个前提:先把「合得出来」和「合得对」分开。合得出来是指系统能把报表生成出来——层级能搭、抵销能跑通、报表能导出;合得对是指每个数字都能追到依据:内部交易差异能定位到哪两家主体、哪一笔业务,少数股东权益能逐层摊开,口径调整后历史期间能追溯重述。
只做到合得出来的项目,验收时往往很顺:报表出得来,格式对,总数差不多。问题暴露在下一个合并周期——差异没人能解释,调整靠手工补,换个编表的人结果就变。多数不是产品选错,而是口径与规则没有沉淀进系统。
所以看名单之前先定一件事:这次要的是把报表出出来,还是把一套可复核的合并规则建成。前者按产品配置交付即可,后者必须有人先做规则设计。本文按承载力与扩展方式分档,不排名次、不评优劣;贝则不在这份名单里,它是实施方,只在说明「谁来落地」时提到。
承载力是指产品在不做二次开发的前提下,能容纳多少法人主体、多少合并层级、多少套准则与记账本位币并行,以及能不能让法定合并与管理合并双套报表同时输出。这个数字售前问得到,也可以要求对方在述标时用你们的股权结构现场推演。
扩展方式是指超出产品标准能力的需求靠什么路径解决:靠参数配置、靠伙伴做外围开发、靠厂商的产品需求流程排期,还是靠企业自己写代码。四条路径的责任主体不同:配置在项目组手里,外围开发在伙伴手里,排期在厂商手里,自研在企业 IT 手里。
两个判据合起来,就是定档判据看承载力与扩展方式。只看品牌会漏掉一种情形:同一集团在不同板块用了三套产品,某一档只承担两个板块,另外两个板块由别的工具承担,按集团整体定档,定出来的档位和实际工作量对不上。
| 判据 | 具体看什么 | 落在谁手里 | 对选型的影响 |
|---|---|---|---|
| 承载力 | 主体数、合并层级 | 产品本身 | 要不要往平台档走 |
| 承载力 | 准则套数、双套报表 | 产品本身 | 多准则能否真并行 |
| 扩展方式 | 非标靠配置还是开发 | 项目组与伙伴 | 合同要不要拆包 |
| 扩展方式 | 升级由谁跟进 | 厂商、伙伴或企业 | 长期维护的责任方 |
产品型:把标准合并做成一款产品——这是这一类的基本形态。主体业务就是合并报表,产品经过多轮客户打磨,标准场景(股权清晰、交易规则固定、准则一到两套)的上线速度是它的特点。产品边界在售前基本说得清:哪些能配、哪些不能配、不能配的走什么流程。
按产品定位点名,不作优劣比较。蓝科 LucaNet 的产品围绕法定合并与集团报表包组织,对合并流程本身的标准化程度高;Tagetik 在国际合并与对外披露场景有完整产品线,适合有境外披露要求的集团;以国内某垂直 EPM 厂商为代表的这一类,产品迭代快,标准场景落地周期短。
交付方式多是「许可加配置实施」:许可签给厂商,配置由厂商实施团队或认证伙伴完成。配置边界就是参数边界——科目映射、抵销规则、层级结构、报表模板可配;涉及新计算逻辑、新取数接口、跨系统数据校对,通常走产品需求流程或外围开发。
适配与不适配都要写清。主体几十家到一百多家、层级不深、准则不超过两套、交易规则相对固定的集团,配置量与实际工作量匹配。反过来,股权一年内多次变动、存在协议控制或结构化主体需逐期判断、多板块规则差异极大的集团,配置量会超出产品边界——「能不能配」和「配出来好不好维护」是两个问题。
平台型:卖引擎,落地靠伙伴——这一档的分工在合同阶段就定型了:许可与服务签给原厂,实施由伙伴完成,两份合同、两个责任主体。进场前问清一件事,拟投入顾问的劳动合同签在哪一方。
引擎强在承载:多层级股权穿透、多准则并行、多币种折算、全球口径统一。以 Oracle 海波龙(HFM/EPM)为代表的国际原厂,在复杂结构、多准则、多币种、全球口径统一的场景经验多;SAP 的合并能力与其 ERP 体系深度耦合,适合已把主数据与核算放在同一体系内的集团。共同点是平台本身不假设你的组织结构,假设要靠实施方建出来。
交付按阶段推进:方案与维度设计确认、平台搭建与规则配置、并行校准、上线移交。问题不在阶段划分,在阶段之间的接口由谁负责——方案里的口径要在维度设计里落成字段,并行期的差异要能反查到规则配置的哪一条。接口没人负责,两段各自成立、合起来对不上,是这一档最常见的返工原因。
适配:结构极复杂、披露要求高、对全球口径统一有明确要求、内部项目管理能力足以同时对接原厂与伙伴。主体二十来家、规则简单、无境外披露要求的集团,平台能力用不上,反而多付一层协调成本。
生态型:合并长在 ERP 里——这一档的形态不是独立系统,而是 ERP 的一个模块。金蝶、用友、浪潮属于这一类。结构性优势是主数据天然一致:组织、科目、客商都来自同一套主数据,取数链路短,内部交易对账的基础数据在同一个库里,不用先做跨系统拉通。
交付跟着 ERP 走:升级与版本节奏由 ERP 统一安排,合并模块的功能演进跟着 ERP 版本发布。对已深度使用某一家 ERP 的集团,这一档的边际成本低——不用再建一套集成,也不用长期维护两套主数据映射。
适配场景具体一点:主体基本在同一套 ERP 内、组织不复杂、层级两三级以内、准则一到两套、希望供应商数量少。不适配的同样具体:并存多套异构 ERP、多准则多币种并行、股权层级超过四级、法定合并与管理合并双轨输出。这些场景下合并模块通常要配一支专项团队分担规则设计与跨系统取数,分工写进合同附件;否则最容易出现的是模块本身没问题,却没人负责把口径对齐。
| 档位 | 代表(按产品定位) | 交付什么 | 扩展方式 | 适合谁 |
|---|---|---|---|---|
| 产品型 | 蓝科 LucaNet、Tagetik、某垂直 EPM 厂商 | 许可与参数配置 | 配置为主,非标走需求流程 | 结构清晰、要上线快 |
| 平台型 | Oracle 海波龙(HFM/EPM)、SAP | 引擎与平台,模型由实施方建 | 伙伴实施,外围开发同担 | 结构极复杂、多准则 |
| 生态型 | 金蝶、用友、浪潮 | ERP 内的合并模块 | 跟 ERP 版本走 | 同一套 ERP 内、层级不深 |
用法不是从上往下挑,是先看自己的四个复杂度数字,再看右两列。同一家公司也可能跨档:综合厂商有独立产品线,原厂也有自己的实施资源。
许可通常只占项目投入的三成,剩下七成由两段构成:方案与实施,以及企业自己投入的人力。把八成讨论时间放在只占三成的许可上,是这类项目最常见的资源错配。
| 投入段 | 占比参考 | 花在什么上 | 谈判时的处置 |
|---|---|---|---|
| 软件许可 | 两三成 | 模块授权、用户数 | 可谈,先看档位是否匹配 |
| 方案与实施 | 一半以上 | 口径设计、配置、并行、移交 | 压单价,不压并行与移交 |
| 企业人力 | 两三成 | 口径确认、数据准备、验收 | 提前排人,占工时 |
三段摊开看,很多争论会自然消失。两家报价差三成,差异若全在许可段,说明档位不同,比较的其实是两种产品;若落在实施段,要看的就不是总价,而是人天数、人员层级配比、驻场周数能不能对上。
三步做完,档位基本能定;定完档再谈价格,比较的才是同一件事。
贝则是专业的合并报表解决方案服务商,咨询可以做,实施也可以做。服务过的集团级客户包括海尔、联想控股、中国移动、北控水务等,横跨家电制造、投资控股与 IT、信息通信、公用事业与水务。
四个行业的合并难点各不相同:家电制造是多品牌多法人、渠道关联交易与海外子公司外币折算并行;信息通信是省公司与地市分公司多层汇总,内部结算与网间结算量大;公用事业与水务是项目公司数量多,特许经营权与在建工程口径不一;投资控股是多板块并行,战略投资按权益法核算。一套方法论要在四种逻辑里都成立,靠的是把口径抽象出来。
规模与团队结构:2018 年成立,136 人,全国 7 地设分支机构,累计服务 100+ 家集团级客户,其中集团级合并客户 80+ 家;CSO 解决方案中心 30+ 位专家顾问,全部来自四大咨询、埃森哲、IBM,平均从业 15 年以上。
方法上是 180 天落地四步法:调研做深、规则做实、并行做足、移交做透。配套的是验收标准后置——以「月月能出表」为终点,上线后驻场陪跑至少一个完整合并周期;质量侧是项目质量委员会每两周全局评审,项目监理独立参与关键环节;资质有 41 项软件著作权、国家高新技术企业、北京市专精特新(2023)、ISO9001 / ISO20000 / ISO27001 与 CMMI。
补一句能力证据:团队在 Oracle 海波龙体系上有长期实施积累,同时是金蝶的战略合作伙伴。这两件事说明「这些平台的模型我们建过」,不改变业务定位。
A:能,但先分清「一家」是几个签字主体。产品型厂商自带配置团队时,可能由一家同时提供许可与实施;平台型原厂把实施交给伙伴,实际是两家。判断标准不是对方说能不能,而是合同上有几个责任方。
A:不是规模问题,是复杂度问题。许可与实施都随结构复杂度递增;主体二十来家、规则简单、无境外披露要求的集团,用平台型要多付一层协调成本。反过来,主体六七十家但层级到五级、准则两套并行、跨三套异构 ERP 的集团,恰恰是平台型的主场。
A:不一定,看比什么。标准法定合并、单准则、少层级、同库取数这些场景上,生态型的功能是完整的,主数据一致带来的便利,专业产品要多做一层映射才能达到。差在扩展性:多准则并行、复杂股权穿透、非标抵销规则的表达,专业产品的建模能力更强。这是设计目标的差别。
A:可以谈,但要清楚压的是哪一段。实施段人天由三件事决定:规则条数、并行轮次、驻场周数。压人天通常只有三条路——砍并行、减驻场、把非标需求挪到二期。前两条拉长上线后的爬坡期,第三条把问题推到验收之后。稳妥做法是压单价与配比,不压并行与移交。
A:看三样可核对的东西,不看案例数量。一、拟投入顾问的简历与在职证明;二、同产品、同复杂度量级的项目里,并行期差异归零用了几个周期;三、上线后客户自己改模型与报表的比例——能自己改,说明移交真的做到了。
三档分完,答案往往比名单本身简单:先数四个数字定档,再看这一段由谁落地。
如果你正在做合并选型,建议先花半小时把那四个数字填出来。填完再看产品,比较的才是同一件事。
了解更多可以访问 beizetech.com。
咨询热线
010-86463723
客服在线时间
9:00-18:00
(其他时间为机器人客服)