工单是运维工作中的硬通货，多年前我们口口相传，no 工单，no work，但而，在许多公司中，工单管理似乎不够强大，或者有一些差距。
事实上，操作和维护工作也是一种服务，所以对于操作和维护提供的服务，无论您是使用高方法或标准流程还是手工处理，如果高效完成，这对应用程序都是一个很大的赞扬。
事实上，许多公司基本上与两种属性有关，一种属性是部门预算，或工作时间，如处理问题，需要2小时，所以服务可以通过工作时间评估服务结算成本，第二种属性是服务质量，如工作单处理结果满意，是否有一些标准化的操作流程等，这些需要工作单反馈。
工单处理的一个痛点是纸质工单。如果工单采用纸质方法，质量可以基本保证，效率无法控制。
第二种痛点是伪电子工单，即工单是通过前端页面输入的，但工单信息需要大量的附件，附件是真正的需求，如excel,比如word甚至SQL语句。
第三种痛点是模糊需求工单，即工单是电子提交的，但工单的需求是模糊需求。为什么是模糊的？因为工单里有很多文字，需求和目标都不是很清楚。你需要像阅读理解一样分析工单。
第四种痛点是复杂的审批程序。如果一个工单的处理过程需要处理多个人，那么工单将成为一个强有力的审批文件，即工单具有过度的安全属性，而对操作和维护属性的关注不够。 在这种情况下，如果你统计工单的处理效率，结果肯定会有很大的差距。
第五类是工单边界模糊，如申请账户权限，如果业务学生申请数据库账户权限，那么必须打开系统层面的防火墙权限，这是一项连带工作，如果我们要求业务学生打开数据库权限工单，然后打开系统权限工单，双方会更加困惑。从解决问题的角度来看，这种经验很差。
对于工单系统，不同的公司有不同的定位，有些公司被放置OA有些是独立的OMS有些模块被称为模块MIS,有些是独立的工作流模块，本质上与各公司的行业属性有关。
至于工单模块和运维模块的建设，哪一个是第一位的？事实上，这是一个相互促进的过程。早期工单肯定没有自动操作和维护的辅助，因此必须有工单模块，但早期工单模块的建设肯定不完善。基本操作和审批是脱节的，因此需要完成工单的自动化处理。相互促进后，这是一个完美的链。
因此，简单地说，工单系统和操作维护系统需要连接起来。对接后，我们可以相互关注自己的特定业务范围，每个环节都可以控制和评估。
工单系统的对接就像渠道引水。第一步不能太大。例如，不同的平台技术体系、不同的接口规范和不同的认证机制。事实上，在早期阶段会有很多额外的工作和调试成本。如果步骤太大，可能无法达到预期，这将给以后的访问带来一些隐患。
从我的建设理念来看，第一步是申请工单系统的接口权限，即工单的审批仍在现有的工单系统中完成，工单的信息必须有流量编号，这是唯一的ID值，我需要的是根据这个唯一的编号从工单系统中获得一个JSON得到这个数据串后，我来分析一下，把它分成符合业务属性的工单。因此，工作将分为以下步骤：
分析工单信息，根据流水号信息分析工单格式工单，将原工单分为多个业务工单，对应用学生透明。例如，数据库权限打开的工单将自动分为两个工单、数据库权限工单和系统权限工单。这一阶段的意义在于，两个系统开始对接，虽然不是很自然的对接方式，但却打开了一扇窗。
在第二阶段，我们可以更进一步。此时，我们可以打开工单系统的接口，让他们推送数据，而不需要我们拉。这将是一个自动推送过程，可以节省大量的检查和反复确认链接。
这一阶段工作的一个亮点是，我们可以将工单分为业务工单。处理完成后，确认工单完成，使工单系统打开一个写入接口，我们将工单的状态传回过去。这样，业务操作就形成了一个闭环。形成闭环是现阶段最重要的事情。这样，审批注重审批环节，业务操作注重业务操作，各司其职。
第三阶段是一个更大的阶段，例如，我们的工单可以与外部系统连接 ** 然后我们可以开始与其他系统打开这个链接。 这是一个更大更全面的过程，会有更多的事情需要与界面对接。
这一阶段的意义在于，这是一个全链的过程。在这个阶段，我们可以挖掘更多运维数据的价值，如工单处理效率、工单数据统计分析、工单分配、业务工单拆分等 逻辑等。 这些都可以逐步细化和改进。
扫码咨询与免费使用
申请免费使用
