记一次WMS的系统改造(3)— 行进中的复盘

行进中的波折

革新总会面对一些阻力和风险,一种新的观念、一种新的模式要来替代既有的产品,从来都不是一件简单的事,在WMS改造这件事上我们一开始就提出两种概念货物驱动任务驱动,并找到一个标杆产品Slack就是为了建立心理上的信任感,并从侧面证明这件事不是一件纯新的模式,提供成功案例来降低阻力,但在实际落地的时候还是没有多么顺利。

惯性的强大力量

有时候大家不支持和反对,并不是真的不支持和反对,而是因为习惯某一种模式和状态,而恰恰新的设计和他熟悉的不同。
习惯就意味着第一时间出现在脑中的就是那个样子,所以很难想象出还有其他的可能性,也没有办法接受其他的可能性,这也就是所谓的想象力比较匮乏吧。
在做这一版WMS的过程中,首先出现的问题是,产品经理的设计拉不齐。说完设计的方向和原则后,大家一块做了一个功能的设计用于对齐设计理念,然分别去做了不同功能的设计,在阶段汇总时立即就发现,绝大多数人的设计都没有做到明显的体验改善。
当时发现这种情况后,大家坐在一起一页一页的复盘每个功能每个点的。里面其实包含了几种情况

  • 思路上不自觉的、很自然的就转回原来的设计思路上
  • 碰见设计样板中没有提供,不能照抄的功能点,不自觉的用原来的模式进行设计,不能领会新的设计的风格要点
  • 遇到苦难的流程,自动切换原来的模式
  • 设计的负责人,面对现实的各种细节困境并不能坚定的执行设计思路
    面对这样的情况,其实我们采用了两种办法
  • 一遍又一遍的高频开设计评审会,让大家高频的对齐设计
  • 打破成本的幻想,绝不接受已经设计成这样了、已经做了这么多了、时间太紧了等理由,不合理的设计必须重新设计

三版设计之后(大致1周多的时间),再看总体的设计就很有眼前一亮的感觉了。不过没想到的是最后给UED人员时还有一次反复,因为他们不理解生产类的软件系统的设计要点,包含的特别放大的部分和特别明确的分区,经过UED人员后反而都弱化了,所以在效果图出来后还要做一轮调整。

除了UI设计的问题,还有业务架构设计的问题。

传统业务系统的三个问题

UI设计进行中的同时我们又复盘了一遍即有系统的所有菜单,结果从中发现了一个具体的问题。
纵观整个WMS,由三个部分功能组成:

  • 业务主流程
  • 操作容错/运营容错
  • 系统容错
    业务主流程,为仓储而设计的主要业务操作节点,业务主流程一般由关键节点和附属节点组成,比如仓储里面有个关键的业务节点叫做“上架”,附属的节点就可能有很多,比如储位推荐、路径推荐、任务分配等等
    操作容错/运营容错,生产辅助的软件是一个强人员属性的软件,软件的基础功能就是指导和记录人员的生产动作。不管操作员如何仔细,人员操作在一个比较长的时间范围和比较多的人数范围内,错误都是不可避免的,操作错误需要由系统来提供补救的功能。
    系统容错,WMS往往使用环境的条件都不会太好,远离IDC,远离闹市,网络条件很差;服务器和终端的硬件条件往往也很差;而且软件开发本身也不能完全避免BUG的产生;但是因为生产辅助软件的特殊性,每一个软硬件、网络环境等等不可预知因素产生的异常,都会影响到具体的货物,所以一般也会提供一些(或很多)业务工具来进行异常后的生产流畅,确保货物生产不会因为软件原因而无法进行。
    即有的系统中,这三部分是混合在一起的,这属于顶层设计问题,新的设计中最开始只考虑了单功能或功能流的使用体验优化,现在就要将重构顶层设计考虑进来了。
    业务主流程是正常的系统节点,系统应该围绕着这部分功能,将附属的节点巧妙的融合进去,然后把绝大部分操作容错系统容错用技术手段处理掉,确实需要人工参与的,需要很慎重的设计一个异常流程,且不能散列放置要让它与正常流程形成闭环。
    最终我们设计的方案是
  • 运营容错,因为涉及一个系统的动与静的问题,所以要单独拎出来,做一个新的技术方案处理。
    ::(系统的动与静会单写一篇)
  • 系统容错,尽量让系统自主处理,如非阻塞不设计人工干预流程。

顶层设计的重要性

开始仅仅是想改善一下仓储人员的使用体验,从UI的优化开始一直推导到设计的规范,再发现运营容错的技术方案系统的动与静,还有系统容错软件自动化处理(可能会从此开端WMS的智能化)。
这里我们有一个体悟,一个软件的顶层设计是极其重要的,点线面从来也不是单独存在。后续我想我们部门每个软件都会有一个业务架构师,这么一个人对整个软件的研发太过重要了,他可能不是专职的但岗位职责一定要明确。
下一篇离题一下,写我们在另一套软件上面的优化成果
『2018年12月24日 广州白云』

posted on 2018-12-24 18:46  水一  阅读(660)  评论(0编辑  收藏  举报

导航