做系统之前，
先把这些问题想清楚

没有专职开发团队，也可以从边界清楚的业务场景起步，但要先安排懂业务的维护人。无代码主要通过表单、数据关系和流程配置搭建应用；低代码以可视化搭建为主，再用少量代码处理扩展需求，两者都要核对平台能力与限制。

AI 编程是让 AI 辅助生成或修改代码，能减少部分编写工作，却仍需要代码审查、测试、部署、安全更新和故障处理等工程维护。它不会自动承担上线责任；如果团队无法理解和维护生成的代码，应先评估外部技术支持与交接安排。

选型时一起比较使用门槛、改动成本和灵活度：业务多久变化一次，特殊算法、设备连接或界面要求能否被工具覆盖，后续修改由谁完成。先做可人工兜底的小范围试用，上线前约定数据、权限、备份、验收和问题响应责任，再决定是否扩展。

数据对不上，常见原因是同一名称代表不同含义：订单金额是否含税，库存是否包含待检品，收入按发货还是开票统计。先确认口径、编码、单位和统计时间，再判断是源数据错误、录入重复，还是同步延迟。直接增加接口可能把差异传播得更快。

对客户、物料、订单等对象，应指定权威数据源和维护责任人，并明确哪些字段从哪里流向哪里。一次性换系统可考虑迁移；每天核对即可的报表可评估定时同步；延迟会影响发货或可用库存的场景，再评估实时同步的必要性和成本。

同步方案还应包含失败告警、人工核对与补偿处理，避免只有正常路径。日志保留定位问题所需的必要字段，并约定保存期限与访问权限。先拿一小批真实业务记录核对新增、修改、撤销和重复发送，再扩大范围。

判断时先看路线由谁决定。触发条件、步骤和分支都能提前写清的工作，适合用工作流执行，例如到期提醒、按条件派单和状态更新。流程里即使调用了 AI，也可能仍由人定义路线，不能仅凭使用模型就认为它能自主处理完整业务。

文档理解、描述归纳或非结构化信息提取，可评估让 AI 辅助；如果要让 AI 判断下一步，应限定可选动作、可访问数据和停止条件。付款、质量放行、关键参数变更等高错误代价动作，需要明确的规则校验或人工确认，不能只依赖模型回答。

试点从可复核、可撤回的小任务开始，按最小权限开放工具，记录输入来源、处理过程、输出与人工修正。用实际样本比较准确性、漏判、处理时间和调用成本，再决定是否扩展。是否适用与如何实施，需要按具体场景评估。

SaaS 通常由服务商运行平台，企业按约定使用；私有化强调部署环境与管理边界由企业控制。本地机房只是私有化的一种方式，符合产品支持条件的企业可控云环境也可作为选择。先核实具体产品支持范围，再讨论部署位置。

选型应从真实约束出发：数据是否有明确存放要求，设备和旧系统是否仅能内网访问，企业是否有人负责监控、升级、安全和故障处理。私有化不自动等于更安全，SaaS 也不等于不用管理账号与数据；双方责任需要写进方案与合同。

比较成本时，应把许可、服务器、存储、网络、备份、升级和人员投入一起计算。还要提前验证数据能导出什么、退出服务如何迁移，以及备份能否实际恢复。用业务可接受的停机时间和数据损失范围，确定恢复安排并组织演练。

能否连接，需要先确认现有软件是否开放受支持的 API、所用版本是否包含接口权限，以及网络和供应商授权是否允许调用。有接口也不代表所有业务都能读写；应拿到文档，核对字段、操作范围、认证方式、调用限制与版本兼容要求。

实现方式可按条件选择：新应用定时拉取数据，旧系统在变化时主动推送，或通过中间件转换与转发。中间件能减少部分连接工作，但不能代替业务口径确认，也需要有人负责运行、监控与升级。同步方向和冲突处理应在开发前约定。

先挑一条业务链做验证，覆盖成功、超时、失败重试、重复请求与撤销。写入时需设计幂等机制，防止重试生成重复单据，并保留必要日志与告警。确认真实环境限制后，再约定实施范围、验收、双方责任及接口或服务费用。

账号管理应先建立权威身份源，明确人员、部门、岗位和在职状态由谁维护。人事信息确认后，入职创建账号、调岗调整角色、离职停用并回收权限，才能形成完整链路。各应用是否支持自动同步，需要分别检查产品能力与授权条件。

在身份信息和同步规则清楚后，再评估单点登录，也就是一次身份认证后访问受支持的应用。登录方便不等于权限一致，应用内部仍要按岗位配置可见数据与可执行动作；调岗应回收旧权限，离职还要检查有效会话、令牌和其他访问入口。

对管理员和敏感操作，应评估多因素认证与额外确认，定期复核长期未用账号和过大权限。应急账号需限定保管人、使用记录和复查方式，避免成为长期绕行入口。可先选少量应用验证入转离流程，再确定同步范围和故障时的人工处理办法。

多租户、高可用和容灾回答的是不同问题。多租户是在一套平台中服务多个组织，需要核对数据隔离与资源管理；高可用通过冗余和切换减少中断；容灾则关注严重故障后如何恢复业务。部署在云端或采用私有化，都不能单凭名称判断这些能力。

看到可用性百分比，应先问统计范围、周期及是否排除计划维护。按全年连续运行粗算，99.9% 约对应 8.76 小时不可用，99.99% 约为 52.6 分钟，但这不是单次故障时长。还要核对 RTO（恢复时间目标）和 RPO（恢复点目标），分别对应计划多久恢复、最多接受回退多长时间的数据。

备份是恢复的基础之一，不等于业务已经具备容灾能力。先按停机对发货、生产和人工补录的影响确定要求，再向供应商核对备份范围、隔离位置、恢复步骤、演练记录和责任边界；方案中的指标还需在具体环境中验证，不能仅凭宣传材料视为保证。

先看业务需求，不必把购买与搭建当作只能二选一。通用、标准化程度高的环节，可优先评估成品 ERP 的成熟模块；企业特有且经常变化的流程，可评估用场景应用补充。购买仍需配置、实施和培训，搭建则要持续承担业务设计、测试与维护。

组装式应用，是把适合不同场景的业务模块连接起来。财务等通用模块可使用合适的成品软件，车间差异流程再评估补充应用。前提是接口开放、核心数据来源统一、账号权限统一管理；还要明确各方维护责任，并在具体产品和网络环境中验证。

比较时把实施、授权、接口、改动、升级和长期维护成本一起计算。让供应商说明哪些需求能直接满足、哪些需要定制，以及数据如何导出。先选一条业务链验证，检查是否双重录入、数据口径是否一致、升级后接口由谁维护，再确定采购与搭建边界。

选择前，先把现有流程画清楚：从哪里开始、需要什么数据、由谁处理、什么条件进入下一步，以及异常如何处理。流程尚不清楚时直接上工具，容易把重复和绕行一并固化。应先梳理业务规则，并让关键数据能够被系统记录和使用。

工作流是在系统里按既定规则自动执行一串动作，例如分派任务、更新状态和发送提醒，审批只是其中一种节点。BPM 是流程管理的方法，关注流程如何设计、运行、衡量和改善；具体落地时，可以组合工作流、系统集成和 RPA，再选择合适的工具。

RPA 可在没有合适接口的地方，替人完成界面上的重复操作，但要核对软件授权、页面稳定性、账号权限和异常处理。选型可先区分：需要重新梳理流程，还是执行明确规则，或补上界面操作环节。先用小范围验证判断适用性，再确定实施工具与责任边界。

业务建模，是把业务事实与运行规则整理成可以讨论、验证的结构。先识别客户、订单、物料等业务对象，明确各自记录什么数据、对象之间如何关联；再梳理流程有哪些状态、什么条件下可以流转，以及各角色能看什么、修改什么、批准什么。

表单提供录入和查看信息的界面，业务模型还要回答：同一物料如何识别，一张订单能否分批交付，取消后相关记录如何处理。数据库、接口和服务器等技术架构，则涉及这些规则如何实现。若直接照搬原有 Excel，重复录入和口径不一也可能一起进入新系统。

可以先挑一个边界清楚的场景，拿几张真实单据，请实际经办人一起走通正常、退回、变更和撤销，再用小应用试跑、修正规则。先约定本轮解决的问题和验收方式，保留暂不处理的事项；通过咨询梳理、应用搭建、人员培训和运行陪跑逐步完善，避免一开始过度设计。