出差的高铁上系统报错，你在群里问了一句，等到次日坐回工位才有人回；周末在家想催一个变更进度，也不知该找谁。这类事很难归咎于某个人不负责，更像是服务在设计时默认了一个前提：大家都在位、都在同一时间段。智能运维里有相当一部分工作，就是把这个前提拆掉。

一、请求没有"卡住"，只是默认在等

先澄清一点：这类问题通常不是流程出错，也不是没人处理，而是请求被静置了——它停在某个需要人在特定位置才能推进的环节。

提问题的人在等，能处理的人可能根本不知道这件事发生了，链条在中间空转。这种空转不会被常规指标捕捉到：工单最终还是按时关闭，只是从提出到真正开始处理之间，隔了一段无人感知的时间。

二、移动办公打破了运维的时间假设

过去的服务体系建立在"同步在场"之上：用户上班时段提问题，运维人员上班时段处理，双方节奏基本对齐。移动办公打破了这个对齐：需求可能出现在通勤路上、客户现场，或夜间。

智能运维要面对的正是这种不对齐。用友智能服务管理器YonISM 把移动化列为四个建设方向之一：不是加一个手机入口，而是让服务不再依赖"人在位"这个前提。

具体来说，移动化运维要解决三件事。其一，请求能否随时随地发起——若提一个问题需要先找流程说明、判断进哪个群、再找管这事的人，一半用户会在此放弃。其二，发起之后能否被看见——请求是否被受理、由谁处理、到哪一步，必须对提出者透明；看不见状态的等待，体验上等同于没被受理。其三，处理方能否不在工位也推进——审批、分派、答复若只能在电脑上完成，即便用户侧移动了，链条仍会断在处理人这里。

三、移动端和 WEB 端不是两套服务

实施中有一个反复出现的偏差：把移动端当成 WEB 端之外的另一个版本，两边分别演化，界面不同、流程不同、数据也不同步，用户不得不再学一遍"手机上该怎么提"。

较稳妥的思路是把两端当作同一条服务链的不同入口：无论电脑还是手机发起，后续都走同一套受理、分流与闭环逻辑，状态互见。用友智能服务管理器YonISM 以友空间为统一服务入口实现移动端与 WEB 端融合，正是为避免服务被劈成两套。移动化运维的价值，恰在两端是"一条链"而非"两个版本"。

四、判断标准：链条有没有因为人离场而断

移动化运维最终要落到一个可衡量的改变上：原本必须等到下一个工作日才能流转的事情，在被提出时即进入处理流程，等待被压缩，故障处理周期缩短，业务连续性更有保障。

这也是判断移动化运维是否做实的标准：看一个请求从发起到受理，能否不因任何人不在工位而中断。