现在的ITSM选型早就不是比谁工单表单更好看、谁能多画几个流程图了。企业运维团队真正头疼的是选了传统大厂产品流程固化严重后续改一个字段都要提需求排期选了开源工具功能看着全但生产环境一跑就各种磨合问题再叠加国产化替代和AI落地的双重压力很多团队在选型会上吵了好几轮都定不下来。我过去几年深度参与过多次ITSM平台从需求梳理、POC测试到上线推广的全过程也帮几个朋友团队做过选型评审。这篇就把我的实际观察和踩坑经验写出来从低代码、AI全链路、信创这三个最关键的维度出发把市面上常见的五类平台掰开揉碎讲清楚让正在做选型的运维负责人、IT主管和技术架构师能少走一些弯路。1. 内容整体设计与三维度选型框架1.1 为什么选型必须盯紧这三个维度先说结论低代码、AI全链路、信创不是三个可以分开评估的加分项而是一根绳子上的三股线哪一股断了整个选型都会出问题。低代码解决的是“流程能不能继续长”的问题。很多企业选型初期只关心工单能不能跑通却忽略了ITSM流程是要持续演化的。新业务上线要加服务目录组织调整要改审批层级合规要求要加变更检查项——这些需求没有低代码能力就意味着每次都要让厂商改代码一改就是几周甚至几个月。我见过一家企业用了某传统商业套件想把自己特有的发布审批流加进去厂商报价够再买一个小型软件了。AI全链路解决的是“人能不能少操心”的问题。如果AI只是做一个聊天机器人放在边上帮你查查知识库、回复一下“密码重置怎么做”那这个AI价值非常有限。真正有意义的AI必须嵌进事件分派、故障诊断、变更风险评估、工单自动完结这些核心环节里也就是所谓的全链路智能。这样AI才能从“玩具”变成“生产力”。信创解决的是“这套系统能不能活得久”的问题。现在不少行业已经把信创纳入硬性考核采购清单里如果有国外商业软件评审阶段可能直接被否。就算当下没有强制要求也要考虑未来三五年内的国产化迁移成本。与其到时候从零开始换系统不如现在就把信创适配度作为硬性门槛。1.2 一套可量化的三维度打分思路针对这三个维度我建议在选型初期就建立一套统一的打分口径不要凭感觉拍脑袋。可以按百分制分配权重信创适配度占40%AI全链路能力占30%低代码灵活度占30%。如果企业已经有明确的信创时间表信创权重还可以提高到50%。每个维度下再拆细项。信创看四点是否支持主流国产芯片和操作系统、数据库能否跑在国产数据库上、中间件是否有国产替代方案、厂商有没有通过相关目录或认证。AI全链路看四点事件管理是否有智能分派和相似工单推荐、问题管理能否做根因辅助分析、变更管理能否做风险评估、工单流转是否有自动总结和知识沉淀。低代码看三点流程设计器是否支持复杂条件分支和子流程、表单是否支持自定义字段和页面布局、接口层面是否易与内部系统打通。这样一套框架下去每类平台都能给出一个客观的横向对比分数比听厂商销售讲PPT靠谱得多。在后面的五类平台拆解中我会基于这个框架逐一点评。2. 五类平台横向拆解与真实优劣势分析2.1 第一类国际老牌ITSM套件流程太重信创是硬伤这里说的主要是以ITIL框架起家的国际商业产品比如ServiceNow、BMC Remedy、ManageEngine这些。它们的特点是功能覆盖非常完整ITIL流程开箱即用事件、问题、变更、发布、资产、知识库全部都有而且在大规模运维场景下有大量验证案例。低代码维度上ServiceNow这类产品的自定义能力其实很强它自带一个PaaS底座可以做很多配置和脚本扩展。但问题在于它的低代码是“外国人思维”的低代码。国内企业习惯的那种“表单下方有个审批框旁边再加个说明字段”的操作在英文界面的配置引擎里折腾起来相当费劲。Remedy更不用说底层表单引擎老态比较明显想实现一个国内常见的会签审批流配置工作量能让工程师怀疑人生。AI维度上ServiceNow这几年确实在大力投入AIITOM和ITSM里都嵌入了不少智能能力比如智能分派、预测性事件影响分析。但对国内企业来说这些AI能力依赖的模型和服务很多跑在海外节点上数据合规和访问延迟都是现实问题。BMC的AI能力在运维监控侧偏强放到ITSM流程侧的智能分析则相对薄弱。信创维度是这类平台的绝对硬伤。国产CPU、国产操作系统、国产数据库的适配基本指望不上就算能适配成本和时间也不可控。我建议除非是外资企业或者对信创完全没有要求的企业否则这类平台直接跳过不要在它身上浪费POC时间。2.2 第二类国内老牌ITSM厂商稳定但需要仔细辨别“低代码成色”国内一批深耕ITSM多年的厂商像广通优云、锐捷、神州泰岳等产品成熟度高案例多对国内企业的运维习惯理解得很透。它们的产品逻辑通常是“为了运维场景深度打磨”所以事件管理、变更管理的流程细节做得相当到位很多开箱即用的流程模板直接贴合国内企业的审批习惯。低代码维度上这类平台近两年都在补课。有些厂商已经把流程设计器改造成了拖拽式表单也可以可视化配置但部分产品的低代码是“半低代码”——配置基础字段和简单流程没问题一旦要写复杂校验逻辑、对接外部系统做数据回写还是得提单让厂商开发介入。换句话说低代码指数的分数必须实际测试“自定义一个带复杂条件的路由流程”才能判定别只看演示DEMO。AI维度上国内老牌厂商普遍处于“刚开始讲故事”的阶段。头部厂商已经有了智能分派、知识库联想、相似工单推荐这类功能部分产品甚至尝试在变更管理里引入风险评估模型。但这些能力多数还是独立模块和核心流程的嵌入程度不深。比如智能分派可能只做到了按服务目录映射到组但不会结合工程师历史负载、技能标签和排班情况做动态推荐。整体而言这个维度的表现中规中矩能用但还谈不上惊艳。信创维度是这类平台的强项。它们基本都完成了主流国产芯片、操作系统、数据库的适配认证不少产品已经在党政、金融、能源行业有规模部署。选这类平台信创方面可以省很多心重点要把精力放在验证它AI能力的实际水平和低代码的“成色”上。2.3 第三类低代码平台自建ITSM灵活但要想清楚边界在哪里低代码平台比如阿里宜搭、简道云、明道云、氚云这类近年来在企业内部很火。很多 teams 觉得ITSM不就是个流程审批系统嘛用低代码平台自己搭一个不就完了。这种思路的初衷是好的——成本低、响应快、不用看厂商脸色但它有一个隐藏的大坑ITSM不等于流程审批。低代码维度是这类平台的绝对优势。它们本身就是为了快速搭建业务应用而生的流程设计、表单设计、权限管理、数据看板都是强项。一个熟练的配置人员几个工作日就能搭出一套支持事件录入、分派、处理、关闭的工单系统。而且后续改流程、加字段真的是所见即所得非常灵活。AI维度上低代码平台这两年也在集成AI能力比如表单自动填充、智能摘要、知识问答机器人等。但ITSM场景中更核心的智能分派模型、根因分析、变更风险评估基本没有现成的需要你基于平台能力自己调模型或对接外部大模型API。这本身就是一个项目不是配置就能搞定的。信创维度上要格外小心。头部低代码平台在信创适配方面做了不少工作但很多功能模块在国产化环境下会有兼容问题比如某些组件渲染异常、打印功能失效、集成插件不可用。用低代码平台自建ITSM相当于自己变成了甲方集成商从选型、设计、开发到测试都是自己的事团队没有足够的研发资源这条路会走得相当挣扎。我给这类方案的定义是适合流程极轻、业务快速变化、没有强合规要求的小团队或者作为ITSM体系的辅助工具。真要承载几百上千人的企业级IT服务管理还是慎重一点。2.4 第四类开源/自研ITSM方案自主可控但全链路落地周期长开源ITSM是很多技术型团队的浪漫。Zabbix做监控OTRS或iTop做工单再用Python或Go写点自动化脚本串起来听起来非常极客也确实是成本最低的路径。还有团队选择基于开源组件自研把Jira Service Management和Confluence做集成配合一套自动化工具链搭出一套贴合自身流程的ITSM。低代码维度上开源方案几乎没有“低代码”这个概念。所有流程逻辑都是代码所有表单都是开发。好处是自由度极高想怎么改怎么改坏处是改动成本全部压在自己的研发团队身上。我见过有团队用Python开发了一套ITSM内部工具用了两年最初的开发走了剩下的工程师没人敢动那套代码。AI维度上开源方案有几条路可以走一是直接用开源的大模型做本地部署然后对接工单系统实现智能分派和知识问答二是用一些开源的自然语言处理库做相似度匹配三是直接调用商业大模型API做智能摘要。本地部署大模型的效果取决于硬件资源人力成本和时间成本都不低。商业API虽然方便但会让“自主可控”的成色打折扣。信创维度上开源方案反而有优势。因为代码在自己手里适配国产化环境只是工作量问题没有什么“厂商不支持”的死结。只要舍得投入麒麟、统信、达梦、人大金仓这些都能跑通。我认可开源方案在部分企业里是现实的选择但它绝不等于“免费的午餐”。把几位核心工程师的工时折算进去开源方案的总拥有成本很可能会超过商业产品。这类方案的适用场景是研发能力强、业务场景独特、对数据安全有极致要求的团队。2.5 第五类智能运维平台延伸出的ITSM模块AI技术与运维场景结合紧密这类平台值得单独说因为它们不是从“工单系统”长出来的而是从“监控平台”或“运维自动化”长出来的。典型的代表包括一些AIOps厂商的产品它们原本做监控告警、日志分析、自动化运维后来往下延伸出了ITSM模块。这类平台的核心逻辑是以数据为中心让ITSM流程直接和监控告警、自动化脚本联动。低代码维度上这类平台的流程配置能力通常不如专业的第二类和第三类那么完善毕竟ITSM不是它们的主业。但因为它们的核心引擎是围绕“事件”和“告警”构建的在做事件工单、变更工单时流程可以非常紧密地绑定监控数据。比如某个服务发生性能劣化系统会依据策略自动开出事件单并且把对应的监控曲线、日志片段、变更记录都挂到工单上这种联动是传统ITSM很难实现的。AI维度是这类平台的看家本领。由于它们天然拥有海量的监控指标、日志和链路数据AI模型训练的数据基础就好。智能告警压缩、故障根因分析可以做得相当深入甚至能在故障发生前给出预测性预警。当这些AI能力与ITSM流程打通后可以实现“告警进来-模型分析-自动分派-自动带上诊断信息-处置完成自动关单”的完整链路这就是AI全链路最实质的落地形态。信创维度上这类平台里纯国产的厂商基本都做了信创适配比较能打。因为他们服务的金融、政务客户往往信创要求最严格产品要出门必须先把兼容性做扎实。这类平台的短板在于ITSM流程管理的细粒度可能不如传统厂商在服务目录体系、SLA精细化管理、复杂审批链配置这些方面需要逐一验证其能力和自定义空间。3. 实操选型过程与核心环节实现3.1 需求梳理用“三张表”锁定真实需求在接触任何厂商之前先把需求梳理清楚。我习惯用三张表来完成这件事。第一张是流程清单表。把所有ITSM相关流程列出来每个流程标明当前状态已有/半自动化/纯线下、流程owner、核心环节数、年度工单量、主要痛点。这张表决定了你需要多强的流程引擎。第二张是集成需求表。ITSM通常需要和监控系统、CMDB、自动化平台、钉钉/企微/飞书、AD域控、邮件网关等周边系统打通。每个集成点要标明对接方式API/数据库/消息队列/手工导入、数据流向、实时性要求。这张表在后续验证厂商的接口开放能力时非常有用。第三张是约束条件表。包括信创合规的时间节点、预算上限、团队研发资源、上线时间要求、数据迁移来源。这张表主要是帮你筛掉不合适的候选产品。三张表做完拿着它去和厂商谈对方几斤几两很容易就摸出来了。张口闭口都能回应你三张表里问题的厂商大概率是靠谱的总是含糊其辞、说“这个功能需要定制”的你就要多留个心眼了。3.2 POC测试必须拿真实场景而不是DEMO场景POC是选型过程中最关键的一环也是最容易被敷衍的一环。我强烈建议POC测试的所有用例都要来自你们自己的真实需求而不是让厂商演示他们的标准流程。具体操作上我建议准备三到五个核心场景分别覆盖“流程类”和“智能类”能力。流程类场景比如模拟一个跨三级的变更审批包含自动判断变更类型、并行会签、到期提醒、超时自动升级、变更窗口冲突检查。智能类场景比如导入你们过去三个月的真实工单数据让厂商现场展示智能分派的效果看看它能不能把不同类别的工单分到合适的处理组。POC期间要和厂商的配置人员建立直接沟通渠道观察他们的响应速度。这一点很重要今天你看到的是厂商满分团队和顺畅的协作方式合作后服务团队的响应机制一般不会有POC期间的表现但至少在POC期间就能看出流程合作效率真正到时候出问题的概率会小一些。这个阶段建议拉上未来的最终用户代表一起参与包括一线服务台、二线技术工程师和流程owner让他们评评分。使用感受这种东西只有真实用户说好才是真的好。3.3 在验证AI全链路时先明确数据基础关于AI全链路我特别想多说一句AI能力的好坏一半在算法一半在数据。POC时如果厂商声称有智能分派一定要问一句这个模型是基于什么样本训练的怎么适配我们的数据初始启动需要提供多少条历史工单有些厂商的AI引擎确实有底子但训练数据是通用的、偏向于某几个行业拿到你的企业里未必好用。比较好的做法是在POC阶段就直接提供一批脱敏的历史工单数据让厂商现场导入跑一个训练或微调闭环然后在同一批测试集上检验效果。在同样的测试集上对比各家表现不管是准确率、覆盖率还是实际落地工作流的可能性都比任何销售话术更能说明问题。3.4 信创验证不能只看“适配认证列表”信创是选型中水最深的环节。初期沟通时厂商都会拿出厚厚一摞兼容性认证证书作为证明包括芯片、操作系统、数据库、中间件等。但千万注意认证列表只能代表某个时间点的特定版本通过了测试不能说明你的目标环境一定没问题。有两点特别值得留意。第一确认配置文件里用的具体版本是不是你需要的国产化版本某些厂商只适配了麒麟V10但你们的生产环境是统信UOS或者反过来都是需要提前确认的。第二有些国产化实践只覆盖了“管理面”但采集终端、代理Agent等组件在国产化服务器上可能仍有兼容问题要让厂商提供在这些环境里完整部件的部署证明而不只是管理端截图。最稳妥的验证方式是在POC阶段就在你们自己目标环境的镜像或服务器上做一次完整安装部署把中间件、数据库全部替换为国产化组件跑一遍核心流程。如果这一步能顺利走通信创风险基本上就控住了。3.5 合同与服务的几个细节选型到后期合同谈判阶段也有关键细节值得留心。一是SLA条款第三方服务商提供的响应时效报修时具体到几级故障多长时间响应相应的处罚或退费机制。二是二次开发的交付物归属如果与厂商合作做了一些定制功能代码和文档的归属问题有时会成为后续分歧的导火索最好在合同里明确。三是数据迁移方案旧平台的历史工单、知识库条目、用户账号、资产台账这些数据怎么迁迁完如何验证完整性也需要有明确方案。四是按年服务和后续升级费用是否明确写入避免用采购价引入后后续每个模块还要“订阅”付费。4. 常见问题与避坑技巧实录4.1 容易踩的坑一把“可配置”和“低代码”混为一谈这是非常多团队会搞混的一点。厂商给你看了一个配置界面上面可以选择不同颜色、拖一拖组件这是不是低代码我认为这只是最低层次的“界面配置”。真正的低代码至少要包含三层能力表单结构可自定义、流程逻辑可编排、外部接口可编排。你可以把低代码能力想象成装修可配置相当于给你几个装修套餐可以选低代码则相当于给你毛坯房加图纸你可以自由改水电、改格局。实际操作中验证一个平台的低代码能力就看一件事让工程师尝试用平台所提供的设计器不写代码或只写极少量的脚本实现一条复杂流程。比如创建一个工单如果在工作时间自动分派给A组同时通知提交者如果是故障类且影响范围涉及核心业务自动升级并通知值班经理。这个流程能做出来说明低代码能力至少及格了。4.2 容易踩的坑二忽略CMDB和自动化能力的底座作用很多TSMP选型只盯着“工单流程”本身但是不要忽略CMDB和自动化能力是ITSM发挥价值的底座。如果CMDB的配置数据不准变更管理中的影响分析就是空谈AI全链路里的根因分析也会因为缺少关联关系而效果大打折扣。如果自动化能力弱流程到了处理环节还是靠人手工登录服务器去操作那么流程自动化做得再漂亮效率也提不上去。所以在选型时建议关注一下这个平台的CMDB建模能力以及它与运维自动化工具、脚本执行通道的集成深度。比较好的体验是同一个平台里既能管流程又能调自动化退而求其次平台与主流自动化工具之间也要有成熟的集成方案。4.3 常见问题速查表为了便于大家选型时快速查阅我把最常见的几类问题整理成一张速查表。常见问题初步判断方向深入验证方法“低代码”是否只是界面换肤询问是否支持复杂条件分支、子流程、外部API编排现场设计一条多分支流程并联调一个外部系统AI能力是演示Demo还是生产可用询问训练数据来源、推理部署方式、模型更新频率导入脱敏历史工单数据做现场训练和效果测试信创支持是否流于纸面查看是否有完整部件含Agent的国产化适配证明在目标国产化环境中完整部署跑测试事件分派是否真的智能询问分派逻辑是否结合人员负载、技能、排班让厂商导出分派规则和实际分派效果日志流程调整是否需要厂商介入由内部人员尝试修改流程并发布到测试环境测试从修改到生效的时间评估复杂度历史数据能否平滑迁移询问迁移工具、迁移脚本、验收标准抽取样本数据做一次迁移演练审批链能否支持会签和或签询问审批节点的操作人设置规则设计一个含会签和或签的测试流程并跑通与国内IM工具集成是否稳定询问是Webhook还是SDK方式是否支持消息卡片实际联调钉钉或企微发一条工单通知并操作一次审批4.4 关于AI本地部署模型的一些经验有朋友问到AI大模型本地部署的具体配置经验。如果你想在ITSM场景中跑一个大模型用来做智能分派、工单摘要、知识问答并且希望数据不出内网那么硬件配置、开源模型选型、数据准备等要点值得认真关注。一个主流参数规模的模型推理环境往往需要配备性能较好的GPU或高算力的NPU卡相关的显卡、专用AI加速卡在国产化服务器里也有对应的选型空间。如果你的团队预算有限也可以先用API方式跑通业务流程之后逐步过渡到私有化部署。4.5 容易踩的坑三忽视“数据接入”和“数据归属”AI全链路落地时最实际的坑出在数据接入和归属层面。有些时候厂商会要求把工单数据发送到他们云端平台做模型训练或优化而这与部分企业数据安全要求相冲突。选型时一定要问清楚AI能力是在本地私有化部署还是依赖厂商云服务日志数据、工单内容、知识库数据会不会离开企业内网模型的持续迭代更新由谁负责训练好的模型权重归谁这些也是不少企业在合同阶段容易忽略的地方。建议把数据归属和本地化部署要求作为一项明确的商务条款写进合同而不是仅停留在口头承诺。5. 最后的经验分享与落地建议选型这件事本质上没有“最好的平台”只有“最适合自己的平台”。我的经验是先把信创约束摆到桌面上不符合的直接排除能省下大量时间再用三张表把需求彻底梳理清楚然后在POC阶段用真实场景把一个候选产品的低代码能力、AI可用性、信创适配度全部验证一遍最后在商务阶段把所有技术承诺落到合同条款里。这样一圈走下来选的平台不敢说完美但至少不会出大的方向性差错。另外还有一点心得想分享选型并不是一次性项目选完以后还需要用一套长效的运营机制来让平台持续发挥价值。ITSM平台上线只是起点流程owner是否愿意持续优化流程、工程师是否愿意把知识沉淀到知识库、管理层是否愿意用数据看板审视运维效率这些运营动作往往比平台本身更能决定成败。低代码能力和AI能力再强也需要有人真正用起来才会产生价值。如果团队预算和技术实力允许我建议可以安排1到2名懂流程又懂一点开发的内部员工参与整个实施过程。包括流程设计、表单搭建、接口联调、甚至AI模型的初始调优。这样既能减轻实施过度依赖外部顾问的风险也能为后续的自主运营和持续优化积累内部力量。我自己当年就是因为培养了一位这样的人才后来平台上几乎所有流程优化都由内部完成响应速度和使用满意度都维持在很高的水平。