工程管理系统开发

项目背景

这是一套面向工程服务业务的派单与服务管理平台，把招投标、合同、设计、现场管理、仓库与信用分收在同一套系统里。使用者既有内部管理人员，也有平台上的服务商与现场作业人员，操作入口覆盖管理端、移动端与 PC 前台。平台运行在 3.8.x 版本线上，代码提交历史完整，不是一次性交付后就没人管的那种系统。

客户当时的状态

工程类业务最难的地方在于它天然是碎的：招投标一段、合同一段、设计一段、现场又是另一段，每段各自有台账，段与段之间靠人对齐。一个项目走到哪一步、卡在谁那里、上周那笔变更有没有批，问三个人可能得到三个答案。审批层级还会跟着金额和项目类型变，固定的流程走不通。更麻烦的是角色多、权限交叉，谁能看到哪个项目的数据，长期靠约定而不是靠系统保证。

我们的做法与取舍

第一个取舍是把审批做成配置而不是代码。这件事的代价是前期要多做一层抽象，收益是运营调整流程不用等开发。对工程业务来说，这个收益远大于代价。

第二个取舍是把信用分做成可追溯的规则体系，而不是一个分数。光有一个数字，出了争议没人服气。所以我们把规则定义、变动记录和排名分成三部分，每一次加减分都能追到依据。

第三个取舍是现场作业必须上移动端。如果现场数据还是回到办公室再录，系统就永远和实际差一天。移动端采集与上报和管理端共享同一套业务状态，不做两套数据事后对账。

最后说明技术口径：上层业务逻辑是我们自研的，底层用了成熟开源框架。我们对外统一表述为「基于成熟开源框架自研业务层」，不会把开源框架说成自研——这一点在投标与商务场合尤其要注意。

系统怎么承载这条链路

平台分四层：入口层覆盖管理端、移动端与 PC 前台；业务层承载招投标、合同、设计、现场与仓库各段流程；平台能力层提供可配置审批、角色权限与信用分体系；集成层接入对象存储、短信、人脸识别、OCR、在线支付与消息推送等外部能力。三端共用同一套业务状态，不存在「管理端看一个数、移动端看另一个数」的情况。

交付状态与边界

系统在线运行，版本持续迭代。边界要讲清楚：招投标的法定程序与评标规则不由平台替代，平台承载的是流程与留痕；信用分服务于平台内部的派单与准入，不构成对外信用评级；短信、支付、推送等第三方通道的商务开通与费用由贵方承担，我们按既有资质接入接口。涉及身份核验与图像识别的环节，我们做的是接口对接与结果落库，数据范围按角色隔离、敏感操作留痕。