描述结果,而不是部门
用请求者能理解的语言命名服务,说明将交付的内容、谁有资格、所需信息、预计时间、任何费用或政策,以及例外情况的处理方式。
将重复需求变成易理解的服务项目、信息完整的申请、适度授权、有负责人负责的履行、异常处理,以及由申请人确认的结果。
打开一个包含待授权、已退回信息、已安排工作、逾期操作和已完成请求的履行队列。对于已定义的服务使用此生命周期;当发生意外中断需要恢复时使用事件管理。
最多 5 名用户可免费使用,无需信用卡。
无需编程即可调整字段、工作流和仪表板。 探索 1,000 多个应用模板和业务场景
第一个视图是请求履行队列。它包括已授权、已退回、已安排、逾期和已确认的示例,而不是空表单。
当用户了解他们可以请求的内容并且履行团队收到完整、可决策的数据时,请求变得更容易完成。
用请求者能理解的语言命名服务,说明将交付的内容、谁有资格、所需信息、预计时间、任何费用或政策,以及例外情况的处理方式。
仅当该服务需要时,使用条件字段询问员工、设备、地点、访问级别、业务原因、日期、证据或成本背景。
当一个服务或产品有变动时,同时更新其形式、资格、审批、履行计划、承诺和沟通,以确保公开承诺不偏离实际操作。
一个真正的工作流应返回未完成的请求,保留修改,并在开始履行之前完成授权。
在让经理或服务负责人审批之前,确认请求者、雇佣或客户状态、服务权限、地点、先决条件、资产上下文以及所需证据。
在政策允许的情况下自动批准低风险标准请求,将高风险访问或支出的请求传递给责任角色,并明确授权委托和例外情况。
将交付分解为可控步骤、依赖关系、目标日期、交接和证据。不要因为第一个任务完成就标记父请求为完成。
内部活动很重要,但请求者体验的是结果。
显示请求是否在等待信息、授权、履行、调度或确认,并提供下一个预期动作,而不是不透明的内部状态代码。
保持审核备注、更正值、重新提交和最终决定可见。被返回的请求是工作流程的一部分,而不是重新开始电子邮件的理由。
记录交付证据和请求者确认,然后审查返工、老化、废弃、异常量和需求模式,以改善服务项目。
用户可能从一个门户开始,但运维记录应与任务匹配。
| 用户需求 | 主记录 | 结束条件 |
|---|---|---|
| 已定义的访问、设备、信息或服务 | 服务请求 | 授权并完成的结果 |
| 现有服务意外中断 | 事件 | 已验证的恢复 |
| 需要生产变更 | 关联的变更 | 授权并验证的实施 |
| 服务项目不满足需求 | 异常或需求审查 | 明确的决策和下一步路线 |
围绕特定服务所需的信息、资格、授权、履行步骤、例外情况和接受情况建立请求记录。
结果是一个请求体验,对用户保持简单,同时使操作员能够看到资格、授权、交付和确认。根据服务、角色、地点、访问级别或设备需求有条件地显示字段,以免请求者填写通用表单。
将成本、访问、政策或例外决策发送给合适的审核者,并将不完整的请求退回附上明确的更正说明。
保持任务完成、依赖关系、证据和请求者确认分开,以免一个完成的步骤掩盖未完成的服务。
保持用户请求简单,同时使授权和交付控制与实际服务相匹配。
有条件的接收、资格、人类审批、退回和重新提交、关联的履行任务、异常、证据以及请求者确认。
将账户配置、采购、支付、库存、身份和专业履行事务保留在被授权执行它们的系统中。
成熟的目录、全渠道接入、发现、CMDB、远程支持、供应商内容以及丰富的预构建IT集成比工作流灵活配置能力更重要。
服务请求是对定义的、预期的服务或项目的申请。事件则是报告意外中断或性能下降。它们可能共享接入和服务上下文,但决策和完成证据不同。
不需要。只有在风险、成本、资格、访问、政策或责任需要决策时才使用审批。低风险的标准请求可以按照授权规则处理,而无需增加仪式性的审批步骤。
是的。示例应用使用本地工作流,可以返回带有精确修正的不完整请求,保留历史记录,并将已修正的提交重新路由到授权。
是的。获得授权的配置人员可以在不编写代码的情况下更改相关字段、表单、工作流、权限、自动化和仪表板,同时保持更改受到管理和测试。
是的。Jodoo 的免费计划支持最多五名用户,无需信用卡,因此小团队可以在查看更广泛部署的当前限制之前测试此工作场景。