八百客的 PaaS，中型制造要不要自己配
低代码和 PaaS 平台这几年很热，销售话术也好听：业务人员拖拖拽拽就能搭出自己要的系统。中型制造企业的老板听完容易心动，觉得省了买成品的钱。实际落地的时候，问题往往出在"配得出来"和"配得对"之间。
八百客这类老牌 PaaS 的优势在于灵活，字段、表单、流程都能改。劣势也在灵活：改得越多，维护越重；搭出来的东西对不对，取决于搭的人懂不懂业务。判断要不要自己配，看四个条件。
条件一：有没有人能长期维护
搭一套系统需要一个人，维护一套系统需要一个岗位。中型制造企业常见的配置是 IT 部门两三个人，管着网络、ERP、办公系统。再压一套自建 CRM 的维护上去，这个人就成了瓶颈。他休假，系统出问题就没人管。
判断标准很具体：这个人离职，系统还能不能转。如果不能，自建就是个风险点。
条件二：需求变化的速度
自建的价值在变化快的时候体现。报价规则一个月改一次、审批链经常调整、报表口径每季度换，这种情况自建确实灵活。反过来，如果业务模式稳定，一年改不了几次，买成品更省事。
条件三：行业特有的单据能不能承载
制造业的销售单据有几个特点：多产品行、分段收款、质保金、按项目归集。这些在通用平台上要用自定义对象拼，拼得出来但结构复杂。成品系统里这些是内置的，比如订单的「分阶段收款」、订单详情里的优惠金额和收款方式，拿来就用。
条件四：数据能不能被别人接手
自建系统的数据结构是自己设计的，换系统的时候迁移成本高。这一点在初期感受不到，三年后想换就很痛。成品系统的数据模型是标准的，迁移路径清楚一些。
八百客的具体功能和报价，以官网最新报价为准。判断自建还是买现成，本质上是在灵活和维护之间做选择，没有唯一答案。装备类企业的销售场景复杂度，装备制造CRM那页列得比较全，可以拿来对照自己需要配多少东西；项目制的单据结构，项目型CRM里有参考。
配出来的系统，三个月后开始变形
自建系统有个规律：上线第一个月很顺，第三个月开始有人提改动，第六个月字段已经翻了一倍，第九个月没人说得清哪个字段是干什么的。原因不复杂，改动没有门槛，谁提都能加，加了不删。
成品系统也会有这个问题，但它有边界：字段数量、对象结构、审批层级是产品设计时定好的，改动要走版本。自建平台把这些边界拆掉了，灵活是真的，失控也是真的。
能控住的前提是有一个人对结构负责。这个人要能说"这个字段不加"，并且这个决定被尊重。中型制造企业里，这个角色往往是老板或者销售总监，但他们没时间管字段。
三个具体的失控点
一是多产品行。自建平台上的订单对象，通常一开始只支持一个产品，后来要支持多个，就加子表。子表一加，报表全要重做。成品系统的订单天生是多行的，这个坑绕得过去。
二是分段收款。制造业的收款按节点，节点数和金额都不固定。自建要设计一套子对象来存阶段，配置麻烦，用起来也别扭。成品系统里这是内置字段，填几段就是几段。
三是质保金。质保金的特点是时间跨度长，两年后才到期。自建系统如果没有提醒机制，这笔钱就永远躺在表里没人管。成品系统里用收款阶段加日程提醒，能兜住。
一个折中的路径
不必二选一。核心的销售单据用成品，边缘的、变化快的表单用低代码平台搭，两边通过导入导出对齐。比如客户满意度调查、展会名片收集、内部工具申请，这些用低代码很合适；客户、订单、回款这些主干，用成品更稳。
判断哪边放哪边的标准只有一个：这个数据要不要跟钱对得上。对得上的，放成品；对不上的，随便放。
这四个条件里，只要有一条明显不满足，就该优先考虑成品。自建不是能力的证明，是成本结构的取舍。
如果决定自建，先从一条线开始，别一上来就搭全套。选一条最痛的线，比如报价或者回款，跑三个月，再决定要不要扩。
