要给管理系统的开发下个定义不难：以……为目标，通过……方式提供服务。但定义没什么用，用处在于它解决什么。

上线和推广

• 不到现场看一遍，做出来的东西大概率是想象的。
• 试点先行是个稳妥办法。先在三个部门跑起来，改顺了再推广。这块别偷懒。
• 界面越简单越好，用的人不会为了好看去多学一套操作。
• 数据迁移是最容易低估的工作量。老系统的数据往往乱得很，清洗很费时间。我觉得值这个功夫。
• 上线前的培训一定要做，最好配上简单的操作手册。
• 跟已有系统的对接要早点确认，卡在这上面的项目不少。
• 二次开发的可能性要提前考虑。业务会变，系统得留点余地。
• 项目周期一般三个月起，太赶的话质量很难保证，这个得提前说清楚。具体还得看情况。
• 别以为数字化了就不用打印，很多场景下纸质单据还是刚需。
• 新旧系统并行一段时间会稳当些，一下子全切风险太大。
• 验收的时候别只看功能有没有，要让人实际操作一遍走通业务流程。
• 首页展示的数据贵在少而准，放太多反而不知道看哪儿。
• 做这类项目，我最大的体会是：技术是其次，把人的习惯改过来才是最难的。
• 反馈渠道要留。用户用着不顺手，得有个地方说，不然问题一直埋着。
• 操作记录要留着，出了争议能查得到，这个功能平时不起眼，关键时候靠它。
• 搜索和筛选是用得最多的功能，这块做得顺手，整体评价会高不少。
• 批量的导入导出看着不起眼，实际能省下很多人力和怨气。
• 改动幅度要考虑老习惯，一下子全变，推行阻力会很大。
• 做这类项目久了，我发现最管用的判断标准很简单：一线员工是不是真的愿意用。
• 统计口径要统一。同一个数字，不同部门算法不一样，最后会吵起来。
• 审批流程别设计得太长，环节一多，大家就开始绕开系统走线下。
• 别追求一步到位。分阶段上，每期解决几个痛点，效果反而更好。这块别偷懒。
• 后期维护的响应速度，直接决定系统能不能长期用下去。
• 需求方内部要先达成一致。我遇到过项目做到一半，两个部门的说法打架，开发只能干等。
• 涉及人员信息的系统，安全和合规这块不能含糊。
• 现场的网络和设备条件先摸清楚，不然上线了才发现跑不动。

以上算是把这个概念梳理了一遍，细节还得看具体情况。

• 权限体系一开始就要定好，返工的代价很大。

这里不多展开。