← 全部项目
现场运维 · 数字化

电梯安装追踪系统

角色
独立完成
状态
已部署,现场日常使用中
技术
Next.js · Prisma · Postgres · Telegram Bot
为一家新加坡电梯安装公司做的现场数字化:把散在 WhatsApp 群里的工地进度,收成一块老板一眼看懂的看板;工人用 Telegram 机器人现场上报。

一家跑在 WhatsApp 上的公司

一家新加坡的电梯安装公司:老板兼销售、一个总工、一个行政、一个业务,加三四十个工人。公司没有任何 OA 系统,几乎全靠行政一个人用 Office 软件撑着,进度活在几个 WhatsApp 群里。老板每天除了跑工地、打电话,剩下时间都在群里翻消息找进度——群一乱,进度就抓不准。

这不是套模板的活。我和老板、总工把真实的安装流程一步步过了一遍,照着他们的做法建模。

老板终于能看见进度

第一件事,是让老板不用再翻群。一块看板:几个工地、多少台电梯、整体到了百分之几、最近发生了什么,一眼看完。现在查进度,他先看看板。

老板的单屏视图:工地、电梯、整体进度、动态——不用再翻 WhatsApp。
老板的单屏视图:工地、电梯、整体进度、动态——不用再翻 WhatsApp。

工地上报,从群消息变成记录

工人不用装 App——就在他们本来就熟的聊天工具里,用一个 Telegram 机器人上报:注册、上下班打卡、报节点、传照片。原本发在群里就散掉的消息,现在一条条落进数据库,带时间、带人、带照片。

工人在工地用 Telegram 上报:工序、人手、照片——直接落库。
工人在工地用 Telegram 上报:工序、人手、照片——直接落库。

每台电梯、每个节点、每张照片

每台电梯按真实安装工序拆成一个个节点,一个节点一条记录,现场拍照即留痕。节点并不统一——有的只需文字加照片,有的要一层层楼往上做、按楼层逐层追踪,有的必须走完质检清单才能标记完成。这套差异不是拍脑袋定的,是跟着他们的实际工序建出来的。

每台电梯、每个节点一条记录;有的节点要走完质检清单才能完成。
每台电梯、每个节点一条记录;有的节点要走完质检清单才能完成。
真实的安装工序,从工地上报:选一个工序、发一张现场照片,就落成一条记录——完成到第几层、附了几张照片。
真实的安装工序,从工地上报:选一个工序、发一张现场照片,就落成一条记录——完成到第几层、附了几张照片。

打卡必须在工地

打卡走的是同一个机器人——但必须人在工地。工人分享定位,机器人算出到最近工地的距离,不在范围内直接拒绝。到了后台,每一班都落进同一本考勤账;异常的那几笔——不在工地签退、工时超长——会被标记待复核,而不是被悄悄记下。谁改了考勤,系统都留下前后值、改的人和理由。

签到、签退都按定位核验:机器人算出与工地的距离,不在范围内直接拒绝——中英双语,就在工人本来就用的 App 里。
签到、签退都按定位核验:机器人算出与工地的距离,不在范围内直接拒绝——中英双语,就在工人本来就用的 App 里。
每一班都在同一本账里;不在工地或工时超长的那几笔会被标记“待复核”,而不是被悄悄记下。
每一班都在同一本账里;不在工地或工时超长的那几笔会被标记“待复核”,而不是被悄悄记下。

一个正经的业务系统

进度、考勤、照片,都要对得上账、经得起查。更多细节,欢迎当面交流探讨。