企业官网建设流程全解析

1. 别把ITSM做成工单流转：先把场景想清楚

这两年帮几家中大型企业做ITSM（IT服务管理）平台选型评审，有个感受特别明显：很多企业嘴上说“要上一套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能力怎么评估：别只看有没有Chat

AI是现在选型最容易被“演示效果”误导的环节。厂商演示的时候，智能客服对答如流，工单自动分类准确率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阶段一定要舍得花时间，把真实场景、真实数据、真实环境都跑一遍，这笔投入比任何评标文件里的承诺都值钱。