本文是「汽修 SaaS 开发连载」第 1 篇。我们是一个做中小企业定制软件的团队今年在开发一套面向连锁汽修厂的管理系统。这个系列记录开发过程中的需求分析、架构设计和踩坑全部来自真实项目。缘起去年接了一个单店汽修厂的管理系统需求做完之后老板介绍来了第二个客户是一家有三家门店的连锁汽修。写方案的时候我们发现前一套系统几乎要重写。单店系统和连锁系统不是多几个门店选项的区别。连锁意味着会员卡要在 A 店充值 B 店消费配件要从总部仓调到分店总部老板想在手机上看每家店昨天赚了多少钱。这些问题在单店版里根本不存在。所以这次立项我们决定按单店起步、连锁扩张的路线来设计从第一行代码就为多门店留好位置。调研三家汽修厂的真实流程写需求之前我们跑了三家店一家快修连锁的分店、一家社区修理厂、一家做钣喷的。把接待到交车的流程完整跟了两天记了几个有意思的细节纸质工单是主角。前台开单写一张纸技师修完在纸上划勾结算时收银员再把纸上的项目录进一个单机版收银软件。中间任何一环字迹潦草配件费就算错。查历史记录靠翻本子。一位车主来问去年三月是不是在你们这换过刹车片前台翻了十几分钟登记本没找到最后是老师傅凭记忆确认的。车主最关心的是记录老板最关心的是钱。车主想要我这台车每次做了什么、换了什么件老板想要这台车在我店里总共赚了多少。这两件事在大部分现有软件里是分开的。第三个细节直接影响了我们的架构。后面会专门写一篇讲这个需求怎么把我们的表结构逼着重构了一次。核心决策以一车一档为主数据市面上不少汽修软件以客户为中心建档案。我们调研后发现这不合适家庭用车场景下一辆车可能来过三个不同的人丈夫、妻子、儿子而一个人也可能有两三台车。如果档案挂在客户上车辆的维修历史就散了。所以我们把车辆作为主数据客户通过关系表挂到车辆上。车辆档案的锚点用 VIN 码车架号而不是车牌——车牌会变过户、换牌、拍新号VIN 一辈子不变。同一台车换牌之后历史记录必须还能追回来这是汽修行业和别的行业不太一样的地方。车辆档案下挂六类数据数据类型内容来源工单记录历次接车、维修、质检、结算维修工单模块保养项目机油机滤、刹车油等含里程工单明细配件更换件号、批次、原厂/副厂、费用配件领料影像资料维修前后照片、视频、预检单技师端上传费用流水工时费、配件费、折扣、支付方式结算引擎责任技师谁接的车、谁修的、谁质检的派工记录这套结构落地的效果是前台输个车牌或手机号两秒调出这台车的全部历史。车主扫码也能在小程序里看到自己车的记录包括每一项花了多少钱。有个店老板看完 demo 说了句话我们记到现在“这个记录拿给车主看比我说十句都管用。”总体架构9 大模块 车主端┌────────────── 车主端小程序──────────────┐ │ 车辆绑定 · 维保记录 · 维修进度 · 预约 · 提醒 │ └────────────────────┬───────────────────────┘ │ ┌────────────────────┴───────────────────────┐ │ 商家管理后台SaaS │ │ PC 后台 / 技师 App / 口袋小程序 │ ├─────────────────────────────────────────────┤ │ ① 组织权限 ② 客户车辆档案 ③ 维修工单 │ │ ④ 配件进销存 ⑤ 预约与车间 ⑥ 会员营销 │ │ ⑦ 财务业财 ⑧ 连锁总部管控 ⑨ 报表 BI │ └─────────────────────────────────────────────┘模块之间不是平行的。维修工单是心脏领料挂在工单上工时挂在工单上质检照片挂在工单上财务凭证由工单生成。别的模块都是在给工单供数据或者消费工单的数据。分四个阶段做每个阶段都是能上线的产品一开始我们想一口气把连锁功能全做出来评估完工作量大概是大版本 v1 的三倍就放弃了。改成四个阶段P1 · 单店可用档案 工单 基础进销存 基础报表。目标只有一个完整记录谁的车、做了什么、换了什么件、花了多少钱。P2 · 效率提升预约排班、车间看板、保养到期提醒、车主小程序、基础财务。P3 · 连锁扩张总部管控、中央库存调拨、跨店消费结算、集团报表。P4 · 生态对接维修电子健康档案上报、4S 店 DMS 对接、保险理赔、开放 API。这样做有个额外好处P1 的客户也能立刻用起来不用等整个连锁体系完工。写在最后这个系列接下来的安排会边写边调序号主题02维修工单状态机设计9 个状态怎么流转03一车一档数据模型车牌做主键踩的坑04一个单车利润需求让我们的表结构推倒重来如果你们也在做汽修或类似的多门店管理系统欢迎在评论区交流尤其想听听多租户数据隔离和跨店结算方面的经验。「汽修 SaaS 开发连载」· 01 / 记录一个软件团队的真实开发过程
