第二章：项目规划与需求分析
好，咱们正式开始动手了。这一章，说白了就是给整个ERP系统打地基。地基打不牢，后面盖多少层楼都得塌。我见过太多项目，上来就写代码，结果做着做着发现需求没搞清楚，推倒重来。嗯，咱们不干那种傻事。
2.1 如何调研企业需求
调研需求，不是拿着本子去问“你想要什么”。你想想看，业务人员自己都说不清楚想要什么。他们只知道现在哪里不爽。
我个人习惯，调研分三步走：
- 跟岗观察：去业务现场待半天。看他们怎么干活，用什么表格，卡在哪个环节。我记得有一次去仓库调研，发现库管员每天花2小时手工核对出入库单，就这一个点，直接决定了我们要做扫码入库功能。
- 访谈关键用户：找财务、采购、销售、仓库这几个核心岗位的人聊。别问“你需要什么功能”，问“你现在最头疼什么”。
- 收集现有单据：把公司目前在用的所有纸质单据、Excel表格、打印报表全要过来。这些就是最原始的需求原型。
我的小技巧： 调研时带个录音笔。回头整理笔记时你会发现，很多细节当时根本没注意到。
2.2 需求文档的编写
需求文档，很多人把它写成“天书”。几百页，没人看。我写需求文档有个原则：让业务人员看得懂，让开发人员能落地。
一份合格的需求文档，至少包含这几块：
- 项目背景与目标：为什么要做这个系统？解决什么问题？
- 用户角色定义：谁用这个系统？管理员、采购员、财务、仓库...每个角色能干什么？
- 业务流程描述：用文字+流程图，把核心业务串起来。比如采购流程：请购→审批→下单→收货→入库→对账→付款。
- 功能清单：每个模块有哪些功能点。别写太细，但别漏掉。
- 非功能性需求：性能要求、安全性、并发量、数据备份策略等。
避坑指南： 我曾经吃过一次大亏。需求文档里写了“支持批量导入”，但没写清楚导入的格式和校验规则。开发做完了，业务一用发现字段对不上，返工了两周。从那以后，我要求所有涉及数据导入导出的功能，必须附带一份样例文件。
2.3 功能模块划分
ERP系统不是大杂烩。模块划分要遵循高内聚、低耦合的原则。说白了，就是每个模块管好自己的事，别越界。
一个标准的ERP系统，通常包含以下核心模块：
| 模块名称 | 核心功能 | 关键数据表 |
|---|---|---|
| 采购管理 | 供应商管理、采购订单、收货入库 | Supplier, PurchaseOrder, PurchaseItem |
| 销售管理 | 客户管理、销售订单、出库发货 | Customer, SalesOrder, SalesItem |
| 库存管理 | 入库、出库、盘点、库存调拨 | Warehouse, Inventory, StockMovement |
| 财务管理 | 应收应付、总账、财务报表 | Account, Invoice, Payment |
| 生产管理 | BOM管理、工单、生产排程 | BOM, WorkOrder, ProductionPlan |
| 系统管理 | 用户权限、角色管理、日志审计 | User, Role, Permission, AuditLog |
注意，不是所有企业都需要生产管理模块。如果是纯贸易公司，采购→库存→销售→财务，这四块就够了。别贪多，贪多嚼不烂。
2.4 技术选型：Python + Django/Flask + MySQL/PostgreSQL
技术选型这块，我直接给结论：中小型ERP，Python + Django + PostgreSQL 是最稳的组合。为什么？
- Python：开发效率高，生态丰富。ERP涉及大量报表、数据处理，Python的pandas、openpyxl这些库能省很多事。
- Django vs Flask：我个人建议用Django。Django自带ORM、Admin后台、认证系统、表单处理，这些ERP全用得上。Flask太灵活，适合微服务或API服务，但做ERP这种重型应用，Django的开箱即用能少踩很多坑。
- MySQL vs PostgreSQL：选PostgreSQL。ERP涉及复杂的关联查询、事务处理、JSON字段存储（比如存配置、存扩展属性），PostgreSQL在这些方面比MySQL强太多。我经历过一次MySQL做ERP，遇到复杂报表查询慢到怀疑人生，换成PostgreSQL后，同样的SQL快了10倍。
注意： 如果你团队里没人熟悉PostgreSQL，用MySQL也行。但别用SQLite做生产环境，并发一上来就崩。我见过有人图省事用SQLite，结果上线第一天就挂了。
下面是一个简单的Django项目结构示例，咱们后面会一步步搭建：
erp_project/
├── manage.py
├── erp/
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ ├── purchase/ # 采购模块
│ ├── sales/ # 销售模块
│ ├── inventory/ # 库存模块
│ ├── finance/ # 财务模块
│ └── system/ # 系统管理
├── static/
├── templates/
└── requirements.txt每个模块都是一个独立的Django App，这样后期维护、扩展都很方便。比如以后要加个“质检模块”，直接新建一个 quality/ 目录就行，不影响其他模块。
关于版本： 写这本书时，Django最新稳定版是5.x，Python推荐3.10+。别用Python 2.7了，那玩意早就不维护了。我去年还见过有人用Python 2.7写新项目，真是...嗯，不说了。
好了，这一章的内容就到这。需求调研清楚了，文档写明白了，模块划分好了，技术选型定下来了。下一章，咱们就开始动手搭开发环境，真正把代码跑起来。