内部请求受理看板 入门|把交给总务与信息系统的请求按受理·处理中·等待确认·完成可视化,减少“那件事怎么样了”的询问

团队与人事

内部请求受理看板 入门|把交给总务与信息系统的请求按受理·处理中·等待确认·完成可视化,减少“那件事怎么样了”的询问

总务与信息系统的负责人,想把口头或聊天工具里收到的内部请求按“受理·处理中·等待确认·完成”四列可视化、减少“那件事怎么样了”这类询问时,可以直接使用这个面向初学者的入门模板。白板共4页:第1页定下受理规则以及各类请求的参考天数和负责人,第2页用四列追踪受理的请求并就停滞不前的请求联系请求者,第3页用重要度×紧急度的矩阵决定处理顺序并统计反复出现的请求,第4页用“为什么”连问五次挖出最多请求的根本原因,再决定靠手册和申请表等机制减少请求,并定下受理值班的轮换方式。任务看板分为受理·处理中·等待确认·完成四列,对应白板4页的4个父任务和各3个子任务已经放好。便利贴由受理请求的人书写,请求的人不需要在看板上写字。密码和个人信息不写在便利贴上,只留下请求编号和要点,这一条也在一开始定好。可以和限定公开团队的成员一起书写,大家轮流做受理值班。第一次尝试建立内部咨询窗口,或者想让请求的进展一目了然的人,也可以直接照着使用。

0 点赞 0 复制 作者: WeProcess
内部请求 总务 信息系统 看板 业务改善
免费注册并使用此模板

免费注册后,即可从模板市场复制并使用此模板

白板预览

预览模式 内部请求受理看板 入门|把交给总务与信息系统的请求按受理·处理中·等待确认·完成可视化,减少“那件事怎么样了”的询问

白板预览

① 受理规则(从这里开始写) ② 各类请求的参考天数与负责人 ③ 受理(把②的参考天数写上再放置) ④ 处理中 ⑤ 等待确认 ⑥ 完成 ⑦ 超过参考天数仍停滞的请求 ⑧ 联系的规则 ⑨ ③受理与④处理中请求的着手顺序(重要度×紧急度) 计划后处理(重要但不紧急) 立即处理(重要且紧急) 不处理(不重要且不紧急) 交给别人(不重要但紧急) ⑩ 反复出现的请求统计表 ⑪ 着手顺序的规则 ⑬ 用机制减少请求的对策 ⑭ 受理值班的轮换方式 内部请求受理看板 使用方法(共4张): ① 定下受理... 完成·做到的事 规则·负责人 停滞·困扰的事 注意到的事·用机制减少的方案 1/4 制定受理规则 Ctrl+F / ⌘F : 2/4... → 2/4 2/4 按列追踪请求 ↙ 3/4 接受请求的地点例:在聊天工具的“总务·信息系统请求”群里留言。口头受理时,负责人也要把内容重新写到这个群里 需要写明的内容例:做什么、何时之前、给谁用。密码和个人信息不写在便利贴上,只留下请求编号和要点 受理时间例:工作日9:00~17:00。17:00之后的请求,下一个工作日再放到受理列 紧急联络例:只有在工作受到阻碍时,才打电话给受理值班人员受理值班:____ 参考天数 负责人 受理时要问的事 账号开通 例:2个工作日 例:信息系统 佐藤 使用者的姓名和开始日期 电脑与外设 例:5个工作日 例:信息系统 佐藤 设备名称与困扰的情况 软件安装 例:3个工作日 例:信息系统 田中 软件名称与使用目的 物品与耗材 例:3个工作日 例:总务 铃木 品名与数量 入职·离职准备 例:10个工作日 例:总务 铃木 入职·离职日期与部门 其他请求 例:视情况决定 负责人:____ 要做什么、何时之前 例:No.15 更换椅子(参考3个工作日) 例:No.16 新人的电脑准备(参考10个工作日) 便利贴只写请求编号和要点 例:No.12 添加共享文件夹权限(负责人是田中) 例:No.13 打印机卡纸(负责人是佐藤) 在便利贴上补充开始处理的人的名字 例:No.10 软件安装(等待请求者确认操作) 例:No.11 添加名片(等待数量的回复) 写明在等待谁的什么 例:No.08 会议室显示器更换(10/06) 例:No.09 账号开通(10/07) 在便利贴上写下完成的日期 当前列 经过/参考(工作日) 停滞的原因 下一次联系 No.10 软件安装 例:⑤ 等待确认 例:6天/3天 例:请求者出差中 例:明天早上在聊天工具里确认 No.11 添加名片 例:⑤ 等待确认 例:5天/3天 例:没有收到数量的回复 例:今天之内打电话 No.12 权限添加 例:④ 处理中 例:4天/2天 例:等待主管审批 例:请主管审批 No.____ ____ ____ ____ ____ 查看看板的时间例:每天早上9:15由受理值班人员重新填写⑦的表 超过参考天数时例:当天就向请求者告知进展情况和下一步安排 等待确认持续时例:没有回复、过了5个工作日后,告知请求者,再把它移到完成列 3/4 确定处理的先后顺序 → 4/4 4/4 用机制减少请求 縦軸: 重要度(上=对工作影响大)... 例:下个月入职人员的电脑准备。定好日期后移到处理中列。拖延就会变成紧急。 例:整个销售部都无法使用邮件。先于其他请求处理,并告知请求者预计时间。 例:不再使用的旧软件整理。与请求者商量,撤回请求或推迟到下个月。 例:明天会议用的插线板。写下步骤,请求者自己或有空的人来做。 本月件数 上月件数 每件的工时 注意到的事 密码重设 例:14件 例:11件 例:15分钟 例:集中在周一早上 共享文件夹权限 例:6件 例:7件 例:20分钟 例:每次调动都会来 打印机故障 例:5件 例:4件 例:30分钟 例:都是同一机型 会议室设备 例:3件 例:2件 例:10分钟 例:不知道怎么连接 处理的顺序例:按⑨的“立即处理”→“计划后处理”→“交给别人”的顺序,每天早上9:15决定 需要延后时例:向请求者说明原因,以及大概什么时候开始处理 统计的日子例:每月最后一个工作日更新⑩的表 ⑫ 用“为什么”连问法深挖⑩中最多... 为什么1 例:忘记密码的人自己无法重设,只能请负责人处理 为什么2 例:因为不知道自己重设的方法 为什么3 例:因为重设的步骤没有写在任何地方 为什么4 例:因为负责人每次都现场处理,没有留下步骤 为什么5 例:因为没有决定由谁、在什么时间编写步骤 根本原因 例:没有可以自行重设的步骤手册,也没有确定由谁来制作 要做的东西 负责人 期限 效果的确认方法 重设步骤手册 例:附有屏幕截图的1页纸 例:信息系统 佐藤 例:10/31 例:⑩的件数是否减半 权限申请表 例:附主管审批栏的表格 例:信息系统 田中 例:11/15 例:退回是否减少 常见问题 例:打印机与会议室的10个问题 例:总务 铃木 例:11/30 例:同样的问题是否减少 第4个方案 ____ 负责人:____ 期限:____ ____ 值班顺序例:佐藤 → 田中 → 铃木,每周轮换一次 休息日的替代例:值班人员休息的日子,由下一位人员接待 下个月重新检视的事例:用⑩的件数确认⑬的对策是否有效 → 2/4 按列追踪请求 ↙ 3/4 确定处理的先后顺序 → 4/4 用机制减少请求
100%

拖动可平移,滚动可缩放

任务看板内容

受理 16 项

制定受理规则
按列追踪请求
确定处理的先后顺序
用机制减少请求
确定受理地点与时间
把请求种类整理成表格
向大家传达受理规则
把收到的请求做成便利贴
找出停滞的请求
联系请求者
把请求分到四个区域
统计反复出现的请求
写下处理顺序的规则
连问五次“为什么”
决定减少请求的对策
决定受理值班的轮换方式

处理中 0 项

等待确认 0 项

完成 0 项

← 返回模板一览