系统边界不是“哪个部门使用哪个系统”的简单划分，而是对业务责任、数据权威和流程控制点的明确约束。边界划分失当，通常会出现两种结果：一个系统不断吸收其他领域需求，最终变成难以维护的“大平台”；多个系统分别承载同一项业务，员工则依靠表格、邮件或人工沟通完成衔接。前者造成职责膨胀，后者造成数据和责任分裂。
先按业务能力划边界
系统边界应围绕相对稳定的业务能力确定，而不是围绕组织架构或现有软件名称确定。判断一个能力是否应由某系统负责，可以连续追问三个问题：它是否拥有清晰的业务目标？是否产生相对独立的业务结果？是否能够由明确的责任人持续维护规则和数据？
例如，订单执行与财务核算存在关联，但二者的业务目标、控制规则和责任主体并不相同。系统之间可以传递必要信息，却不应因为需要协同，就把所有功能堆进同一平台。边界的核心不是隔离，而是确定“谁负责什么”。
用三条线确定交界面
第一条是流程线。每个系统应明确接收什么输入、输出什么结果，流程在哪个节点交给下一个系统。若两个系统都在审批同一事项，或都维护同一流程状态，边界大概率存在重叠。
第二条是数据线。关键数据必须有唯一的权威来源。其他系统可以读取、引用或加工，但不应各自维护一套相互冲突的主数据。发生异常时，还要明确由谁修正，而不是让技术人员在多个系统之间反复比对。
第三条是责任线。流程负责人对业务规则和结果负责，数据负责人对定义与质量负责，系统负责人对功能、运行和集成负责。三类责任不能因为系统交接而被稀释，否则接口虽然打通，问题仍会在部门之间转移。
用变更机制守住边界
边界划定后，新增需求必须先判断其性质：是现有能力的合理扩展，还是引入了新的业务能力；是数据共享需求，还是数据归属变化；是流程协同，还是职责迁移。对于跨系统需求，应先确定主系统、数据维护方、异常处理方和接口责任人，再讨论开发方式。
真正成熟的治理，不是追求系统越少越好，而是让每个系统都有清晰职责、明确权威和可追溯的交接。只要业务能力、数据来源和责任主体能够一一对应，系统数量即使较多，也不必然形成“系统烟囱”。