740041d034
- Interview map v2.1 → v2.2: Add Office version, workstation, and network questions - Project retrospective v1 → v2: Document two-round discussion, add version tracking, reorganize pending items - Planning document v1.4 → v1.5: Add frontend deployment strategy, early demo, and client cooperation items Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
360 lines
16 KiB
Markdown
360 lines
16 KiB
Markdown
# 项目规划文档
|
||
|
||
**项目名称：** 调节阀工厂信息化管理系统建设
|
||
**项目性质：** 定制化轻量信息化系统
|
||
**实施团队：** 内部两人团队（领导 + 技术实施）
|
||
**文档用途：** 内部规划参考，指导项目全周期落地
|
||
**文档版本：** v1.5
|
||
|
||
---
|
||
|
||
## 一、项目背景与目标
|
||
|
||
### 背景
|
||
|
||
目标客户为一家中小型调节阀制造企业，年产值约1亿元，当前信息化基础几乎为零，主要依靠 Excel 表格和口头传达进行生产管理。企业领导希望引入一套信息化管理系统，提升生产效率，但明确不希望使用复杂的大型通用系统（如 ERP），而是寻求一套小巧、灵活、高度贴合自身现状的定制化解决方案。
|
||
|
||
### 项目目标
|
||
|
||
- 为客户搭建一套覆盖核心业务环节的轻量信息化管理系统
|
||
- 系统需高度定制，贴合客户实际生产流程
|
||
- 研发成本和信息化改造成本控制在合理范围内
|
||
- 系统易于使用，员工无需专业培训即可上手
|
||
|
||
### 可行性判断
|
||
|
||
本团队当前已有在相近场景下搭建信息化系统的实践经验，技术路线成熟，且在 AI 辅助开发工具的加持下，开发效率可显著提升。项目需求与团队能力匹配度高，整体可行性良好。
|
||
|
||
---
|
||
|
||
## 二、技术选型
|
||
|
||
### 主要技术栈
|
||
|
||
| 技术 | 用途 | 说明 |
|
||
|------|------|------|
|
||
| Microsoft Excel + VBA | 界面与业务逻辑 | 无需额外环境，部署简单，客户熟悉度高 |
|
||
| Microsoft Access | 数据存储与应用界面（可选方案A） | 与 Office 生态集成，兼具数据库和界面开发能力，部署简单，但存在并发和稳定性局限 |
|
||
| SQL Server Express | 数据存储（可选方案B） | 微软出品，免费，稳定性和并发能力显著优于 Access，但部署复杂度更高 |
|
||
| Python | 辅助脚本与自动化 | 用于 VBA 难以处理的复杂逻辑，按需引入 |
|
||
|
||
### 数据库方案对比
|
||
|
||
数据库的选择是本项目技术层面最关键的决策之一，直接影响系统的稳定性、部署方式和后期维护成本。以下是两个方案的详细对比，供内部讨论决策。
|
||
|
||
**方案A：Microsoft Access**
|
||
|
||
适用场景：单机使用，或并发用户数极少（1～2人）的情况。
|
||
|
||
优点：
|
||
- 无需额外安装数据库服务，部署极为简单
|
||
- 自带窗体和报表设计器，可作为应用界面直接使用，减少开发工作量
|
||
- 与 Excel、VBA 集成度高，开发门槛低
|
||
- 客户已有 Office 环境即可运行，无额外软件成本
|
||
|
||
局限性：
|
||
- 文件型数据库，多人并发写入时存在文件损坏风险，数据一旦损坏难以恢复
|
||
- 并发性能较弱，不适合多人同时操作的场景
|
||
- 数据量增大后性能下降明显，长期扩展性有限
|
||
|
||
**方案B：SQL Server Express（推荐）**
|
||
|
||
适用场景：多人共享访问，对数据稳定性有要求的生产环境。
|
||
|
||
优点：
|
||
- 微软官方出品，Express 版本免费，功能满足本项目体量
|
||
- 真正的服务型数据库，支持多人并发访问，稳定性高
|
||
- 数据存储在服务器端，不依赖单个文件，安全性和可靠性远优于 Access
|
||
- 后期若系统规模扩大，可平滑升级至 SQL Server 完整版，无需重构
|
||
|
||
局限性：
|
||
- 需要在服务器上安装和配置数据库服务，部署复杂度高于 Access
|
||
- 需要服务器支撑（操作系统建议使用 Windows Server，普通 Windows 系统对局域网并发连接数有约20个的上限限制）
|
||
- 界面部分仍需通过 Excel + VBA 开发，无法像 Access 一样直接利用内置界面工具
|
||
|
||
### 选型原则
|
||
|
||
- **优先使用 VBA**：无需搭建运行环境，客户机器上只要有 Office 即可运行，部署成本极低
|
||
- **Python 按需补充**：当 VBA 实现成本过高时，以 Python 脚本的形式补充，不强求统一
|
||
- **本地部署**：系统部署在客户本地机器或服务器上，数据不出厂，安全可控
|
||
- **不追求技术先进性**：以稳定、可维护、易交付为第一优先级
|
||
|
||
### 前端部署与版本管理策略
|
||
|
||
系统前端基于 Excel + VBA 开发，部署和版本管理需要提前规划，避免在多人使用时出现文件冲突或版本混乱。
|
||
|
||
**核心设计原则：一人一份应用文件，避免多人同时操作同一文件。**
|
||
|
||
每个使用系统的员工在自己的电脑上运行独立的 Excel 应用文件，所有数据的读写通过后端数据库完成，前端文件本身不存储业务数据。这样既避免了多人同时打开同一 Excel 文件带来的锁定和冲突问题，也使得应用更新时只需替换各工作站上的文件即可。
|
||
|
||
**Office 版本统一要求：**
|
||
|
||
由于 VBA 在不同 Office 版本间存在兼容性差异（如控件行为、函数支持、界面渲染等），需要在项目启动前确认客户各工作站的 Office 版本情况。建议推动客户将所有工作站的 Office 统一到同一版本，以降低开发和测试的复杂度，避免出现"在一台电脑上能用、在另一台上出问题"的情况。
|
||
|
||
**应用更新与分发：**
|
||
|
||
当系统功能迭代或修复 Bug 时，需要将新版本的 Excel 应用文件分发到各工作站。具体的分发机制（如通过共享文件夹统一存放最新版本，或由我方远程协助更新）需结合客户的 IT 环境在实施阶段确定。设计应用文件时应考虑版本标识，便于确认各工作站是否运行的是最新版本。
|
||
|
||
### 部署方式
|
||
|
||
部署方式取决于数据库方案的选择：
|
||
|
||
- **方案A（Access）**：数据库文件存放在共享网络路径，各工作站直接访问，无需服务器，部署简单；适合初期试用或并发用户极少的情况
|
||
- **方案B（SQL Server）**：数据库服务安装在服务器上，各工作站通过局域网连接访问；服务器操作系统建议使用 Windows Server，以避免普通 Windows 系统的并发连接上限问题；如客户当前没有服务器，需在项目启动前提前规划采购
|
||
|
||
---
|
||
|
||
## 三、模块规划
|
||
|
||
系统按业务流程划分为以下核心模块，各模块之间存在数据依赖关系，需按顺序建设。
|
||
|
||
### 模块依赖关系
|
||
|
||
> **说明：** 下图表示的是**系统建设顺序与数据依赖方向**，不是业务流程图。箭头含义为"被依赖方 → 依赖方"，即上游模块的数据是下游模块运行的前提。
|
||
|
||
```mermaid
|
||
graph TD
|
||
A["物料编码 & BOM<br/>（地基模块）"]
|
||
B["库存管理"]
|
||
C["采购管理"]
|
||
D["订单管理"]
|
||
E["生产管理"]
|
||
F["发货管理"]
|
||
|
||
A -->|物料与BOM数据支撑| B
|
||
A -->|物料数据支撑| C
|
||
A -->|物料与BOM数据支撑| D
|
||
C -->|到货入库联动| B
|
||
D -->|订单驱动生产| E
|
||
B -->|领料出库联动| E
|
||
D -->|发货与订单状态联动| F
|
||
B -->|出库确认联动| F
|
||
|
||
style A fill:#f9f0e0,stroke:#c8a84e,stroke-width:2px
|
||
```
|
||
|
||
### 各模块说明
|
||
|
||
**模块一：物料编码与BOM管理**（地基模块）
|
||
|
||
- 建立统一的物料编码体系，每条物料有唯一编码
|
||
- 物料主数据字段：编码、名称、规格、材质、单位、物料类型等
|
||
- 支持多层级 BOM 结构：产品 → 子组件 → 零件
|
||
- 这是整个系统的数据地基，所有后续模块的数据均基于此建立
|
||
|
||
**模块二：库存管理**
|
||
|
||
- 入库、出库记录
|
||
- 实时库存数量查询
|
||
- 库存预警（低库存提示）
|
||
- 基于物料编码与 BOM 模块的数据运作
|
||
|
||
**模块三：采购管理**
|
||
|
||
- 采购需求发起与记录
|
||
- 供应商信息维护
|
||
- 采购单开具与跟踪
|
||
- 到货确认与入库联动
|
||
|
||
**模块四：订单管理**
|
||
|
||
- 客户订单录入与查询
|
||
- 订单状态跟踪（接单 → 生产中 → 完工 → 已发货）
|
||
- 交货期管理与提醒
|
||
- 订单变更记录：客户提出变更（规格、数量、交货期等）时，在系统中发起变更申请，记录变更内容、变更时间和变更原因，保留完整的变更历史，确保每一次改动可追溯
|
||
- 变更状态管理：变更申请需经确认后方可生效，生效后自动通知生产侧响应，避免变更信息在口头传递中丢失或延误
|
||
|
||
**模块五：生产管理**
|
||
|
||
- 生产工单开具与下达
|
||
- 生产进度记录
|
||
- 生产异常记录
|
||
- 与库存联动（领料出库）
|
||
- 订单变更响应：当上游订单发生变更时，系统提示相关生产工单需要处理；根据生产进度的不同，支持对工单执行暂停、修改或作废重开等操作，并记录变更原因，确保生产执行与订单要求始终保持一致
|
||
|
||
**模块六：发货管理**
|
||
|
||
- 出库确认与发货单开具
|
||
- 发货记录查询
|
||
- 与订单状态联动（发货后订单标记完成）
|
||
|
||
---
|
||
|
||
## 四、分阶段实施计划
|
||
|
||
项目总周期约 **5个月**，共分为5个阶段，每个阶段有明确产出物。
|
||
|
||
---
|
||
|
||
### 第一阶段：调研与需求确认
|
||
**时间：第1～3周（约3周）**
|
||
|
||
**工作内容**
|
||
- 与客户开展调研访谈，覆盖全部业务模块
|
||
- 记录客户当前各环节的操作方式和痛点
|
||
- 确认各模块的具体需求和优先级
|
||
- 摸底客户现有数据状况：盘点现有 Excel 及其他载体中的物料数据、BOM 数据、订单数据等的规模、格式和质量，评估数据整理与迁移的工作量
|
||
- 确认客户 IT 基础条件：并发用户数、是否已有服务器、是否需要移动端访问、各工作站 Office 版本及操作系统等，为数据库选型、部署方案和前端兼容性提供决策依据
|
||
- 输出需求确认文档，作为后续开发的依据
|
||
|
||
**产出物**
|
||
- 客户现状调研记录
|
||
- 系统需求确认文档（各模块字段、流程、规则）
|
||
- 物料编码规则草案
|
||
- 客户现有数据摸底报告（数据源清单、数据规模、质量评估、迁移难度判断）
|
||
|
||
**阶段目标**
|
||
- 双方对系统要做什么达成一致
|
||
- 物料编码体系的设计方向确定，可进入开发阶段
|
||
- 对客户现有数据的规模和质量有清晰认知，为第二阶段的数据整理工作做好预判
|
||
|
||
---
|
||
|
||
### 第二阶段：基础数据层建设
|
||
**时间：第4～8周（约5周）**
|
||
|
||
**工作内容**
|
||
- 设计并确认物料编码规则
|
||
- 搭建物料主数据管理模块（录入界面 + 数据库）
|
||
- 设计 BOM 数据结构，搭建 BOM 管理模块
|
||
- 协助客户完成存量物料数据的整理与录入
|
||
- 在基础数据初步录入后，尽早搭建一个可演示的小型功能点（如物料查询界面），供客户实际体验，建立对系统的直观感知和信心
|
||
|
||
**产出物**
|
||
- 物料编码规则文档
|
||
- 可用的物料主数据管理模块
|
||
- 可用的 BOM 管理模块
|
||
- 初始物料数据库（含客户现有物料数据）
|
||
- 可演示的早期 Demo（如物料查询功能）
|
||
|
||
**阶段目标**
|
||
- 物料编码体系落地，数据库中有真实可用的物料数据
|
||
- 为后续所有模块提供数据基础
|
||
- 客户能够通过早期 Demo 看到实际成果，对项目方向建立信心
|
||
|
||
---
|
||
|
||
### 第三阶段：库存与采购模块
|
||
**时间：第9～12周（约4周）**
|
||
|
||
**工作内容**
|
||
- 搭建库存管理模块（入库、出库、库存查询、预警）
|
||
- 搭建采购管理模块（采购单、供应商、到货确认）
|
||
- 实现库存与采购的数据联动
|
||
- 与客户对接，验证流程是否符合实际操作习惯
|
||
|
||
**产出物**
|
||
- 可用的库存管理模块
|
||
- 可用的采购管理模块
|
||
- 两模块的操作说明文档
|
||
|
||
**阶段目标**
|
||
- 客户可以通过系统管理日常的入库、出库、采购操作
|
||
- 库存数据可实时查询，告别依靠记忆和人工盘点
|
||
|
||
---
|
||
|
||
### 第四阶段：订单与生产模块
|
||
**时间：第13～17周（约5周）**
|
||
|
||
**工作内容**
|
||
- 搭建订单管理模块（订单录入、状态跟踪、交货期）
|
||
- 搭建生产管理模块（工单、进度、领料）
|
||
- 实现订单 → 生产 → 库存的数据联动
|
||
- 测试完整业务流程的数据流转是否顺畅
|
||
|
||
**产出物**
|
||
- 可用的订单管理模块
|
||
- 可用的生产管理模块
|
||
- 完整业务流程的数据流转测试记录
|
||
|
||
**阶段目标**
|
||
- 系统可以覆盖从接单到生产完成的完整流程
|
||
- 各环节数据可以贯通，不再孤立
|
||
|
||
---
|
||
|
||
### 第五阶段：发货模块与系统整合交付
|
||
**时间：第18～20周（约3周）**
|
||
|
||
**工作内容**
|
||
- 搭建发货管理模块（出库确认、发货单、发货记录）
|
||
- 全系统整合测试，修复问题
|
||
- 数据迁移协助（将客户现有 Excel 数据导入系统）
|
||
- 客户使用培训
|
||
- 交付系统及相关文档
|
||
|
||
**产出物**
|
||
- 可用的发货管理模块
|
||
- 完整可交付的信息化管理系统
|
||
- 用户操作手册
|
||
- 系统维护说明文档
|
||
|
||
**阶段目标**
|
||
- 系统全流程打通，覆盖接单到发货的完整业务链
|
||
- 客户可以独立使用系统，完成日常业务操作
|
||
|
||
---
|
||
|
||
## 五、时间节点总览
|
||
|
||
| 阶段 | 主要内容 | 时间区间 | 关键产出 |
|
||
|------|---------|---------|---------|
|
||
| 第一阶段 | 调研与需求确认 | 第1～3周 | 需求确认文档、数据摸底报告 |
|
||
| 第二阶段 | 物料编码 + BOM | 第4～8周 | 物料与BOM模块上线、早期Demo |
|
||
| 第三阶段 | 库存 + 采购 | 第9～12周 | 库存采购模块上线 |
|
||
| 第四阶段 | 订单 + 生产 | 第13～17周 | 订单生产模块上线 |
|
||
| 第五阶段 | 发货 + 整合交付 | 第18～20周 | 完整系统交付 |
|
||
|
||
**总周期：约20周（5个月）**
|
||
|
||
---
|
||
|
||
## 六、风险识别与应对
|
||
|
||
| 风险 | 说明 | 应对方式 |
|
||
|------|------|---------|
|
||
| 需求变更 | 调研不充分导致开发中途改需求 | 第一阶段重点投入，确保需求文档经双方确认后再开发 |
|
||
| 数据录入量大 | 存量物料数据录入可能耗时超预期 | 第一阶段完成数据摸底，提前评估工作量；协助客户设计数据整理模板，分批录入，不影响开发进度 |
|
||
| 客户使用习惯 | 员工不习惯新系统，使用率低 | 界面设计贴近 Excel 操作习惯，降低学习成本，上线前做培训；尽早提供可体验的 Demo，让客户逐步适应 |
|
||
| 并发访问限制 | 普通 Windows 系统对局域网并发连接数有上限，多人同时使用时可能出现连接被拒的情况 | 服务器操作系统必须使用 Windows Server，在项目启动前与客户确认并推动采购落实 |
|
||
| 数据库稳定性 | Access 文件型数据库在多人并发写入时存在文件损坏的风险，一旦损坏数据难以恢复 | 采用 SQL Server Express 替代 Access 作为数据库，从根本上规避此风险 |
|
||
| 开发时间有限 | 技术实施以业余时间为主 | 借助 AI 辅助开发提升效率，各阶段设置缓冲时间，优先保证核心模块 |
|
||
| Office 版本不一致 | 不同工作站 Office 版本不同，可能导致 VBA 程序出现兼容性问题 | 调研阶段摸清各工作站 Office 版本，推动客户在项目启动前统一 Office 版本 |
|
||
| 应用分发与更新 | 系统迭代后需将新版本分发到各工作站，若缺乏机制可能导致版本混乱 | 采用一人一份应用文件的设计，应用内置版本标识；结合客户 IT 环境确定分发机制（如共享文件夹存放最新版） |
|
||
|
||
---
|
||
|
||
## 七、客户侧配合事项
|
||
|
||
> **说明：** 以下事项需要客户方配合完成，建议在项目启动前或调研阶段与客户明确沟通，形成书面备忘，避免后期因预期不对齐产生分歧。
|
||
|
||
**项目启动前需客户配合确认的事项：**
|
||
- 是否同意将各工作站 Office 统一到同一版本（我方指定），并在项目开发启动前完成
|
||
- 是否已有服务器或是否愿意采购服务器（若选择 SQL Server 方案）
|
||
- 指定一名内部对接人，负责协调访谈安排、数据收集和日常沟通
|
||
|
||
**项目实施过程中需客户配合的事项：**
|
||
- 安排相关岗位人员参与调研访谈
|
||
- 配合整理现有物料、BOM 等存量数据，按模板格式提供
|
||
- 每个阶段交付时安排人员进行试用和反馈
|
||
- 系统上线前安排员工参与使用培训
|
||
|
||
**建议形成书面备忘的事项：**
|
||
- 系统包含哪些模块、不包含哪些（明确项目边界）
|
||
- 交付后的维护和修改如何处理（响应方式、是否收费）
|
||
- 客户方需承担的配合责任（数据整理、硬件采购、版本统一等）
|
||
|
||
---
|
||
|
||
## 八、项目成功标准
|
||
|
||
- 系统覆盖从接单到发货的完整业务流程
|
||
- 客户可以独立完成日常操作，无需长期依赖技术支持
|
||
- 物料编码体系落地，库存数据准确可查
|
||
- 系统在客户现有设备上稳定运行，无重大性能问题
|
||
- 客户对系统的使用满意度达到预期
|
||
|
||
---
|
||
|
||
*内部工作文件 · v1.5 · 可根据调研结果和项目进展持续更新* |