从微信群和 Excel,到一套真正能跑起来的电力工程系统

这个项目最开始，并不是因为客户单纯想“做一套系统”。

而是随着项目、任务和参与人员越来越多，原来的工作方式开始变得吃力。

任务通过微信群沟通，附件散落在聊天记录和个人电脑里，设计进度需要人工确认，审核和退回依赖人去跟进，月底的个人产值还要重新统计。

很多事情不是做不了。

只是每天都在重复消耗时间。

真正需要解决的，也不是“有没有软件”，而是：

整个电力工程协作过程，能不能被真正串起来。

先理解业务，再开始做系统

电力工程项目并不是简单的“创建任务—完成任务”。

一个设计任务从开始到结束，往往会经历责任分配、设计、附件提交、校审、审核、退回、修改、再次提交、最终完成等多个环节。

不同专业之间也存在明确分工。

一次、二次、土建、设总，不同角色关注的事情并不一样。

如果没有先把这些业务关系理清楚，页面做得再漂亮，也只是把原来的混乱搬到了线上。

所以项目开始后，我们首先做的不是堆页面，而是重新梳理整个业务过程：

• 一个项目如何拆分成具体任务；
• 每个任务由谁负责；
• 当前处于什么状态；
• 哪些角色需要参与审核；
• 退回之后应该回到哪个环节；
• 附件属于哪个任务、哪个阶段；
• 一个任务完成后，如何形成个人产值和考评依据。

先把这些关系说清楚，系统才有可能真正服务业务。

第一件事：让所有人知道“事情现在在哪”

在传统协作方式下，很多时间其实消耗在确认状态上。

“这个任务做到哪里了？”

“现在是谁在处理？”

“已经提交审核了吗？”

“为什么被退回？”

“最新版附件在哪？”

单独看，这些问题都很小。

但当一个团队同时推进多个项目、多个专业和大量任务时，这些确认会不断重复发生。

因此，系统第一阶段最重要的目标，并不是增加多少功能，而是让每一个任务都有明确的状态。

任务有明确的责任关系

任务创建后，可以明确负责人和相关参与人员。

谁负责、谁审核、谁需要继续处理，不再依赖微信群里的某一句话。

责任发生变化时，也能够在系统中留下对应记录。

过程能够被持续追踪

任务从开始到完成，会经过不同阶段。

当前做到哪里、下一步需要谁处理、是否已经提交、是否被退回，都能够直接看到。

不再需要依赖某个人记得所有事情。

附件跟着业务走

过去文件很容易散落在聊天记录、网盘或者个人电脑里。

系统上线后，附件直接和项目、任务以及对应业务过程关联。

找文件不再是一件需要“问人”的事情。

审核和退回真正形成闭环

审核不是简单地点击“通过”或“驳回”。

系统需要知道：

谁提交的。

谁审核的。

什么时候审核的。

为什么退回。

退回以后应该由谁继续处理。

再次提交之后，又应该回到哪里。

当这些关系真正被串起来以后，审核过程才从一次聊天沟通，变成了可以持续追踪的业务记录。

从“任务管理”继续走向“业务管理”

当项目、任务、审核和附件开始真正在线运行以后，另一个变化自然出现了。

很多原来需要人工统计的数据，开始可以直接从业务过程中产生。

这也是整个项目进入下一阶段的基础。

个人产值不再完全依赖月底统计

过去到了月底，往往还需要重新整理每个人完成了哪些任务、参与了哪些项目。

但如果每个任务从创建到完成，本身已经有完整记录，那么很多数据就不需要再次手工整理。

业务发生的同时，统计依据也在产生。

考评开始有了真实过程数据

考评不再只依赖结果或者人工印象。

任务完成情况、审核过程、实际参与记录，都可以成为后续管理的依据。

系统的价值，也开始从“记录工作”向“支撑管理”延伸。

管理者能够看到整体情况

一线员工更关心自己的任务。

管理者关心的则是另一组问题：

哪些项目正在推进？

哪些任务出现异常？

哪些环节积压较多？

哪些工作已经完成？

整个团队目前是什么状态？

因此，在移动端之外，我们也逐步建立了面向管理人员的后台，让项目、任务和业务数据能够从另一个视角被看到。

为什么我们没有一开始就做成“大而全”

电力工程管理可以做得非常复杂。

项目计划、进度、人员、产值、质量、审核、合同、成本、资料、档案……

任何一个方向继续展开，都可以做出大量功能。

但我们并没有试图一次性把所有东西全部塞进系统。

第一阶段，我们只围绕最频繁、最直接、最消耗时间的事情展开：

任务、责任、进度、附件、审核、产值。

原因很简单。

如果最核心的工作流程都还没有跑顺，再增加更多功能，只会让系统变得更重。

企业软件不是功能越多越好。

真正重要的是：

哪些事情值得交给系统，哪些事情暂时没有必要复杂化。

先解决最真实的问题，再随着业务继续演进。

比一开始设计一个庞大的“全能系统”，更接近我们理解的企业信息化。

真正难的，不是把页面做出来

这个项目里，最花时间的部分，并不是某一个按钮或者某一个页面。

真正需要反复推敲的，是业务之间的关系。

比如：

任务责任人发生变化以后，历史记录要不要保留？

一个任务被退回以后，应该回到上一个状态，还是进入新的处理阶段？

同一个任务经过多次提交和审核，如何保证过程仍然清晰？

附件被重新上传以后，之前的版本是否还有价值？

个人产值应该在什么时候形成？

任务“完成”和业务真正“结束”，是不是同一个概念？

这些问题看起来并不复杂，但如果处理不好，系统很快就会在真实使用中出现问题。

企业软件真正的难点，很多时候并不是技术能不能实现。

而是：

系统到底应该怎样理解业务。

移动端负责日常工作，后台负责管理视角

在具体产品形态上，我们最终采用了移动端与管理后台协同的方式。

移动端更接近员工每天真正需要处理的事情。

查看任务、处理待办、上传附件、提交审核、查看进度，都应该尽可能简单直接。

而管理后台承担更多整体视角：

项目情况、规则维护、人员和业务数据，以及管理者需要关注的汇总信息。

我们并不希望把所有能力都堆在一个端里。

不同角色需要看到不同的信息。

让员工看到自己需要做的，让管理者看到自己需要判断的。

这比“所有人都使用同一套复杂界面”更重要。

系统上线之后，变化没有那么戏剧化

我们并不想用“效率提升 80%”这样的数字来描述这个项目。

真实的软件落地，往往没有那么戏剧化。

它带来的变化更具体。

任务有了明确负责人。

进度可以直接查看。

审核过程能够追踪。

退回有原因，也有后续去向。

附件不再完全依赖聊天记录寻找。

个人产值有了业务过程作为依据。

管理者想了解项目情况时，也不必再从不同的人那里重新收集一次信息。

这些改变单独看都不大。

但它们每天都在发生。

而企业里的效率，本来就是由大量这样的小事情组成的。

从“有没有系统”，到“工作能不能更简单”

回过头来看，这个项目真正完成的，并不是把原来的工作全部“数字化”一遍。

而是把原本散落在微信群、Excel、文件夹和人工沟通里的事情，逐步重新串了起来。

让任务有去向。

让过程有记录。

让附件有归属。

让审核有闭环。

让管理有依据。

一套企业软件最终有没有价值，不应该只看它有多少页面、多少功能、用了什么技术。

更应该看：

它有没有让原来的工作少一点麻烦。

这也是莫问云一直在做的事情。

我们不是为了增加一套新的工作方式。

而是希望通过系统，减少那些原本可以避免的重复、确认和等待。

把复杂留给系统，把时间还给人。

企业信息化，简单一点。