1. 别把ITSM做成工单流转先把场景想清楚这两年帮几家中大型企业做ITSMIT服务管理平台选型评审有个感受特别明显很多企业嘴上说“要上一套ITSM”实际上只想要一个“工单系统”。需求文档翻来覆去就是报障、派单、流转、闭环、SLA统计真到上线后才发现流程确实跑起来了但该救火的还是救火服务台该被吐槽的还是被吐槽。现在技术环境完全不一样了AI大模型、AIOps、智能体这些词已经进入大多数IT团队的日常讨论再加上国产化替代、自主可控这类硬约束ITSM早就不是一张工单能撑住的场景了。这篇文章基于我最近参与的一个中大型企业ITSM选型评估项目聊聊怎么从单纯工单流转的误区里走出来面向AI和信创做一套靠谱的技术评估框架。项目背景是一家集团型制造企业IT服务团队分布在三个城市对接的业务系统超过四十个内部用户接近五千人原有的老平台用了将近八年流程改不动、数据导不出、厂商基本停更选型已经拖了两年。我们这次不急着看界面好不好看、按钮顺不顺手而是先把评估维度搭起来再一家家厂商做POC。下面这些经验准备选型或正在选型的同行可以直接拿来参考。1.1 服务台在变ITSM的定位必须跟着变传统的ITSM本质上是“记录型系统”用户打电话或者发邮件报障服务台建一张工单客服按技能组派单工程师接单处理处理完填个解决方案用户确认关闭最后月底拉一批SLA报表。这套模式在业务系统少、流程相对固定的年代是够用的但放到中大型企业里问题很快就冒出来了。首先是工单量太大人工处理跟不上海量请求。五千人的组织只要核心业务系统有一次明显卡顿服务台一天能涌进来二三百张重复报障单客服和一线工程师大部分时间都花在“拆解问题、复制粘贴、转给二线”这类机械动作上处理效率极其低下。其次是信息断层严重工单里的描述经常是碎片化的比如“系统很慢”“打不开页面上传失败”没有关联到具体的配置项、版本和变更记录二线工程师接手后还要重新问一遍背景。再有就是流程和知识脱节处理完的问题沉淀不到知识库下一次同类问题还是走一遍老路。在AI和信创这两个变量出现之前这些问题还能靠人力和流程制度硬扛。但现在不行了一方面AI能给ITSM带来的是自动分类、智能路由、知识推荐、自动化处置这些实打实的能力传统工单系统根本没有这些技术底座另一方面信创的要求意味着整个技术栈要重新适配数据库、中间件、操作系统、浏览器全部换一遍旧平台往往连装都装不上。所以选型的第一个动作不是比功能清单而是先把ITSM在你们组织里的定位重新定义了它到底只是一个工单记录系统还是一个承载智能服务、自动化流程、资产配置和审计合规的数字化服务运营平台这个问题不先想清楚后面全是踩坑的节奏。1.2 面向AI的ITSM从流程引擎到智能协作我见过不少IT负责人一聊AI就说“我们以后也要有智能助手”但真要问“智能助手解决什么具体问题、数据从哪来、准确率怎么评估、错了谁负责”基本都答不上来。这是因为AI在ITSM里的价值根本不在于“有个能聊天的机器人”而在于它能不能真正介入到服务流程的每一个环节。用一张图来理解AI在ITSM里的分布入口侧是自然语言提单用户不用懂“事件”“请求”“变更”这些专业术语直接说“我的ERP账号登不上去了”系统能自动识别这是一条服务请求关联到账号管理这个服务目录自动校验权限和状态处理侧是智能分类和自动路由AI根据工单标题、描述、历史同类工单的解决记录自动判断归属团队和紧急程度并把可能的解决方案推荐给工程师管理层则是AI辅助决策比如评估变更的影响范围、预测SLA可能超时、识别高频重复问题。这些能力叠加在流程引擎之上工单该走审批还是走审批该留痕还是留痕AI只是让每个环节更“聪明”不是替代码替流程。还要注意一个方向就是AI Agent。现在很多厂商在推“智能体执行操作”比如通过对话直接触发密码重置、账号解锁、服务器重启这类标准化操作。这个方向对中大型企业很有价值因为服务台里大量请求其实都是重复性操作。但也正因为它是“能动手”的权限隔离、操作审计、失败回滚这些机制就必须提前评估清楚否则上线之后用户满意度和安全合规会同时出问题。2. 选型前先建立一套技术评估框架很多企业的选型问题是出在“没有明确的评估维度”结果就是各部门各看各的IT看技术业务看界面采购看价格最后拍板基本靠感觉和厂商的关系。我们这次的做法是在发招标文件之前内部先花了两周时间把评估框架定下来然后让所有候选厂商按统一模板应答。框架分四块架构与集成、AI能力、信创适配、生态与服务。每一块都有细分的检查项和赋分标准后面POC阶段再逐项验证。2.1 架构与集成能力能接多少系统决定未来天花板ITSM号称“IT的客服中心”但它真正的价值在于和其他系统的连接。一个ITSM在你们公司的集成深度决定了它能发挥多大作用。评估的时候首先要回答的问题是这个平台是微服务架构还是老式单体架构处理逻辑、流程引擎、消息队列、数据存储能不能独立扩展如果只是把几个模块塞在一个Java应用里后期并发一上来、定制一多基本就废了。其次是API的开放程度。我建议不要只听厂商说“我们有API”要直接要OpenAPI文档重点看几个点是否支持RESTful API和事件回调有没有Webhook能力API是否覆盖了工单的创建、查询、更新、关闭、关联配置项这些核心操作是否支持批量导入API的版本管理策略是什么限流规则和审计日志怎么做。还有一点容易被忽略就是身份认证的对接能力——中大型企业基本都有统一身份系统AD/LDAP或主数据平台ITSM必须能无缝接入做到组织架构同步和单点登录否则账号管理就是一场灾难。集成生态的评估同样重要。把ITSM放到整个IT运维体系里看它至少要跟监控系统、自动化运维平台、CMDB配置管理库、协同办公软件企业微信、钉钉、飞书、OA系统、甚至财务系统工单和结算挂钩打通。这里最怕的情况是API文档写得天花乱坠实际联调的时候发现字段对不上、回调地址不支持、数据同步只能全量不能增量。所以集成能力这块必须在POC阶段用真实系统做几组接口联调测试不能只看PPT。2.2 AI能力怎么评估别只看有没有ChatAI是现在选型最容易被“演示效果”误导的环节。厂商演示的时候智能客服对答如流工单自动分类准确率95%听起来很强但到真实生产环境里百分之八九十的问题出在数据样本上。所以评估AI能力我建议分层来看。先看基础能力层是否支持自然语言处理NLP模型接入比如对工单标题和描述做实体识别、语义分类是否有可训练的分类模型和意图识别模型是否提供标注工具和训练样本管理能力。这些看起来“基础”其实是整个AI能力能够落地的前提。如果厂商只能调用一个外部大模型API做聊天没有自己的分类模型和训练闭环生产环境就用不起来。再看应用场景层AI具体能帮服务台做哪些事。我建议把场景列出来逐项核对包括智能工单分类、自动路由、相似问题推荐、知识库自动生成、SLA风险预测、变更影响分析、智能问答机器人、语音和文本渠道接入。另外要考虑AI是否支持对接企业自己的知识库和文档库。中大型企业里已经有了大量运维知识文档、历史工单、变更记录AI要能在这些私有数据上做检索增强生成RAG而不是只会用通用知识聊天。最后一定要评估安全和权限AI生成的答案是否可溯源、是否记录审计日志、是否做了租户和角色级别的数据隔离大模型是私有化部署还是走云端API。我在实际项目中遇到过厂商吹“AI能力很强”一问模型在云端公网企业数据全部要过一遍外部API就这一条信创和数据合规就都过不了。2.3 信创适配评估兼容性不等于能上线信创这块选型要看的不是厂商PPT里那句“全面支持国产化”而是具体到基础设施底座维度的适配深度。我们内部的检查清单包括CPU是否支持鲲鹏、飞腾、海光、兆芯、龙芯这几个主流国产芯片架构操作系统是否兼容麒麟麒麟V10、银河麒麟和统信UOS数据库是不是真的支持达梦、人大金仓、openGauss、OceanBase这类国产数据库还是仅仅在MySQL上改了个驱动名字中间件是否适配东方通、金蝶天燕等国产中间件浏览器是否兼容奇安信、红莲花这类信创环境下常见的浏览器。如果是中大型企业采购一般还会要求参考信创目录。我建议选型启动前就让采购把目录要求发过来先对照确认候选厂商在不在目录里免得辛辛苦苦做完评估结果最后一轮发现连投标资格都没有白忙一场。这里有个非常重要的判断标准“能装上去”和“能稳定跑生产”是两码事。我们遇到过一个情况产品在麒麟系统上可以正常安装界面也出来了但一接入国产数据库就频繁报错后来发现是底层SQL用了大量MySQL特有的函数国产数据方言不完全兼容。所以信创这块不能只核对兼容性证书必须在POC阶段搭建一套真实或接近真实的生产环境把安装、数据迁移、高可用、性能压测全都跑一遍。3. POC与打分明细把评估落到可执行的测试选型评估最忌讳“看演示打分”。厂商现场Demo做得越顺越说明是反复排练过的反而暴露不了真实水平。我们的经验是提前设计POC场景给厂商一定时间准备所有候选平台用同一套测试数据、同一套业务场景、同一组评分标准最后横向比结果。这样出来的分数才有办法放到决策桌上。3.1 设计评分表与权重评分表是我们整个选型项目的“宪法”。我们内部经过三轮讨论最终定下来五个一级维度功能覆盖度30分、架构与集成20分、AI能力20分、信创适配15分、服务与生态15分。这个权重不是拍脑袋定的而是反映了这次选型的核心目标先保证业务功能完整再考虑未来三到五年的技术扩展尤其是AI和信创这两个方向。功能覆盖度里重点看事件管理、问题管理、变更管理、发布管理、服务请求管理、服务目录、知识管理、CMDB、SLA管理、报表分析这些模块的完整度。架构与集成方面重点看微服务化程度、API开放度、对接生态。AI能力按前面说的基础能力层和应用场景层分别打分。信创适配按CPU、操作系统、数据库、中间件、浏览器五个维度分别给分。服务和生态则关注实施团队的项目经验、原厂和代理商的分工、二开支持和源代码开放策略。打分规则还需要细化比如每个二级指标按0到5分打分然后乘以权重汇总。另外还要约定“一票否决项”比如不支持私有化部署一票否决信创环境POC跑不通一票否决企业组织超过一定规模时单租户性能压测不达标一票否决。有了这些底线规则才不会出现“总分很高但实际没法用”的尴尬情况。3.2 关键测试场景与验证方法POC阶段我们设计了一组场景基本覆盖了中大型企业ITSM日常的核心业务。第一个场景是“智能分单准确率测试”。准备了两百条脱敏后的历史工单数据包括标题、描述、报障人、所属部门、处理方法让候选平台用这些数据做模型训练然后用另外五十条历史工单做盲测统计分类准确率和路由准确率。这个测试很能看出平台AI能力是不是真材实料纯靠规则匹配的产品分数一下就拉开了。第二个场景是“事件、变更、问题联动测试”。模拟一个典型的故障处理流程监控系统触发告警自动创建事件工单事件定位到某个配置项工程师发起变更申请变更审批后关联实施记录最后事件关闭并生成问题记录。这个流程跑一圈能验证平台的流程引擎灵活性、CMDB关联能力、自动化触发能力同时也能看出来流程配置到底要写多少代码、改一个审批节点要花多长时间。第三个场景是“API集成与开放度测试”。我们用官方API文档分别在两个环境里做了三件事通过API创建并分配一张工单通过Webhook监听工单状态变化并推送到内部企业微信群从外部CMDB系统批量同步一百条配置项数据到平台。整个过程记录接口文档的准确性、响应速度、错误提示是否友好。很多平台在这轮直接暴露了API文档和实际接口不一致的问题文档里写的参数根本不存在连起码的联调都做不下去。第四个场景是“信创环境部署测试”。我们实际申请了麒麟V10服务器和海光CPU的测试机要求厂商在上面完成安装部署再用达梦数据库作为后端存储跑一遍核心流程的性能压测。能完整走通这一步的厂商信创适配才是真正过了关光有证书拿不出来跑不起来的统统降级处理。3.3 数据迁移与历史数据准备历史数据迁移是POC里最容易被低估的一个环节。老系统里往往积压着多年的工单数据如果全量导入新平台数据量大、字段标准不一致、附件和流程快照丢失的问题会全面爆发如果只带当前未关闭的工单又会导致历史追溯性变差。我们在POC里专门设计了一个“历史工单迁移”场景让厂商在测试环境中完成一批老工单的迁移考察字段映射、附件导入、流程历史保留、自定义字段兼容这几个点。不要指望老系统的数据能“无损迁移”到新平台这是不可能的。不同产品的数据模型差异太大比如老系统把“优先级”放在工单主表里新系统可能放在扩展字段里老系统的“解决方案”是纯文本新系统可能要求结构化存储。所以更务实的做法是确定一个核心字段集把必需的历史数据迁过去其余非结构化内容采用“归档可查”的方式处理。迁移完成后还要有数据校验环节用脚本抽查关键字段是否完整附件能否正常打开关联关系是否还保持。主数据同步也必须在POC里测。人员组织架构、系统账号、配置项信息这些主数据在新老系统切换期间要保持一致不然流程跑到一半发现负责人已经离职、配置项已经被删掉就会造成大量无效工单。建议在POC阶段就验证好基于接口或中间件的主数据同步方案同时把增量同步和每日对账机制考虑进去。4. 避坑实录中大型企业踩过的那些坑选型做了这么多次踩过的坑和看别人踩过的坑都不少。这里写几个最具代表性的。有些问题在POC阶段就能暴露有些则要等上线以后才回过味来提前知道总比事后补救强。4.1 API开放程度与文档版本脱节有一家厂商在官网公开的API文档写得特别完善各种参数说明、示例代码、错误码定义都有。结果联调的时候发现产品实际部署的版本后台接口跟文档对不上有些接口返回字段缺了一大半有些接口要额外传一个文档里没提到的token参数。后来一查才知道产品迭代太快文档还停留在两个版本之前。这个问题对中大型企业影响很大因为ITSM一旦上线周边系统的集成全绑定在API上API不稳定或者文档不准确后续每一次版本升级都是灾难。我们的对策是把API文档的准确性和版本管理能力写进评标项然后在POC里强制要求用一个文档里第二天再实际调用的方式做盲测让厂商现场演示给你看而不是提前调试好再给你看结果。4.2 AI的Demo与生产两回事AI能力是现在选型里水分最大的环节。有些厂商的智能客服Demo做得确实不错但你仔细一问模型是用通用语料训练的压根没见过你们公司的业务流程和专有名词还有些所谓智能分单其实就是把文本关键词做了一次规则匹配准确率看着不错换个场景就露馅。更麻烦的是生产环境的冷启动问题——新平台上线初期没有历史数据积累AI模型几乎是空白的这个阶段的体验往往很差厂商又没办法短期内把它调好。所以评估AI能力时一定要问清楚三个问题模型训练需要多少历史数据、从上线到模型达到可用水平大概要多久、这段时间有没有兜底的人工处理方案。另外强烈建议在POC里用真实的历史工单数据做一次训练和验证别让厂商拿演示数据糊弄你。4.3 信创“纸面兼容”与跑起来不兼容前面提到过信创环境部署测试的重要性这里展开说一下细节。有的产品号称“全面支持麒麟”实际上只是在麒麟系统上能装、能启动、能看页面一旦并发上来或者涉及文件存储、消息队列、数据加密这些底层操作问题就全出来了。我们还遇到过更隐蔽的问题前端界面在信创环境下的浏览器里功能缺失比如表单组件显示不全、在线编辑器的控件无法使用、导出Excel按钮没反应。这些问题在标准版Chrome里测不出来必须到实际信创终端环境里逐项操作一遍。建议POC阶段就准备一个“信创功能走查清单”把服务台常用操作、审批流程、报表导出、附件上传下载、系统管理这些功能在信创环境里全部点一遍确认没有“能用但不流畅”或“勉强能用但很多操作要退回标准浏览器才能做”的情况。4.4 CMDB与流程之间隔着一道墙最后一个坑是CMDB与流程引擎的割裂。很多企业选型时把CMDB当作ITSM的一个附加模块来看没有意识到CMDB是流程自动化的“数据底座”。如果事件工单不能自动关联到对应的配置项变更审批不能自动识别受影响设备范围问题管理不能基于配置项维度做统计分析那ITSM的流程跑得再顺也只是表面功夫。我们在选型中专门测试了一个场景在CMDB里建一个应用系统关联它的服务器、数据库实例、网络设备然后模拟该应用系统故障上报看系统能不能自动把故障工单关联到相关配置项并计算出影响范围。能做好这一点的产品才算真正把ITSM和CMDB打通了否则上线后CMDB很快就会被业务团队弃用变成一套没人更新的死数据。后续如果还要上自动化运维和AIOps这个底座就更关键了因为所有智能化分析都要建立在准确、实时的配置关系之上。这次选型项目走到最后我们并没有选那个“功能最全、价格最低”的厂商而是选了一个在AI能力和信创适配两个维度都做了真实投入、也愿意在POC阶段拿出对应开发资源的团队。原因很简单中大型企业的ITSM一旦落地至少要用五年以上今天只图工单流转的快明天AI和信创这两个大方向必然要让你重选一次。我自己最大的体会是选型评估不是一场打分游戏而是把你们企业未来三到五年的IT服务运营路线想清楚的过程。尤其是AI相关的能力别指望厂商一次给到位要选那种架构开放、能持续迭代的平台上线以后才能不断把新技术加进去。最后提醒一句POC阶段一定要舍得花时间把真实场景、真实数据、真实环境都跑一遍这笔投入比任何评标文件里的承诺都值钱。