尧图网站建设 
最近我把德勤发布的2025全球ITAM调研报告翻来覆去看了两遍越看越觉得题目里那句ITAM迈向战略核心不是公关话术而是过去三四年行业变化的真实落点。ITAM也就是IT资产管理以前在很多企业里就是个干杂活的角色登记一下电脑型号、统计一下软件授权、年底配合财务盘个点。但云和AI这两股力量一股脑涌进来之后这套玩法明显撑不住了——云资源弹性伸缩、AI模型和数据集大量涌现、订阅式软件越买越多资产台账再靠Excel和手工登记出来的数据只能是历史文物压根没法支撑任何决策。我见过不少企业云账单一个月几十万问财务花在哪了不知道问运维有多少实例在用不知道问研发哪些资源能停也不知道。这就是ITAM没跟上云时代节奏的典型症状。德勤这份调研就是把这个问题摆到了台面上ITAM不再是一个后台支撑职能而是直接影响成本、合规、安全和AI落地速度的战略级能力。整篇报告看下来我认为最有价值的不是那些趋势判断而是它对ITAM职责边界的重新定义。这篇文章我会顺着调研的核心逻辑把云与AI时代ITAM为什么变重要、具体怎么落地、有哪些坑要避开完整梳理一遍适合正在做IT资产、云成本治理、或准备搭建ITAM体系的同学参考。1. 为什么ITAM突然从配角变成了主角1.1 传统ITAM的困局台账越全用处越小很多企业做ITAM做了十几年资产库里的数据不可谓不全每台服务器的采购日期、保修期限、存放机房每套软件的采购单价、授权数量、到期时间全都登记得清清楚楚。但问题恰恰在于这些数据在云和AI时代变得全而无用。一台物理服务器的生命周期是3到5年采购时记录一次报废时更新一次中间基本不用管。但云上的虚拟机可能只活几个小时容器实例可能只有几分钟的生命周期如果还用采购登记的思维去管理等你手工录入完成资源早就销毁了。更麻烦的是成本维度。传统ITAM关注的是资产原值和折旧这对财务做固定资产核算没问题但对今天的成本优化来说远远不够。云资源的成本是持续发生的运营支出今天开一台高配实例明天忘了关就是实打实的浪费。我遇到过一个案例某团队为了跑一次数据迁移任务开了一台GPU实例任务跑完忘了释放整整挂了一个月账单上多了十几万。负责ITAM的同事说资产台账里记录了这台机器但记录不等于管理更不等于控制。这就是传统ITAM的核心困局它在用管理静态资产的思路应对动态化的IT环境它在用登记信息的方式回应决策对实时数据的需求。德勤调研之所以说ITAM要迈向战略核心本质上是因为过去那套记录资产现状的玩法已经无法回答老板们真正关心的问题——比如我们的云成本为什么涨了40%这些AI算力投入到底产生了多少业务价值我们的软件授权到底有没有合规风险。1.2 战略核心意味着什么从记账员到决策支撑当ITAM从记账转向决策支撑它的角色定位会发生三个明显变化。第一个变化是服务对象变了。传统ITAM主要服务财务和采购部门提供的是审计材料和预算依据现在ITAM要同时服务CFO、CIO、CTO、安全负责人甚至业务线负责人。CFO想知道云成本为什么波动CTO想知道研发环境有多少资源在空转安全负责人想知道哪些资产存在漏洞暴露风险这些需求没有一个能从传统的资产台账里直接得到答案但每一个都需要ITAM提供底层数据支撑。第二个变化是工作节奏变了。过去ITAM一个月出一份报告就算勤快现在云成本按小时计费、安全合规实时监测ITAM的数据更新频率必须从月度压缩到每日甚至实时。这不是简单增加人手就能解决的必须依赖自动化采集和持续发现机制靠人肉盘点在这个节奏下没有任何可行性。第三个变化是能力边界变了。战略级的ITAM不再是单纯的资产管理它要融合成本管理FinOps、安全合规、架构治理和供应商管理。一个典型的场景是某业务线要上线一个AI推理服务需要采购GPU资源。这时候ITAM要能回答——现有的GPU资源利用率如何是否还有闲置算力可以复用新采购的预算是否已经纳入年度计划供应商的报价与市场行情相比是否合理。这一串问题本质上已经是一个IT资产战略顾问要做的事而不是资产管理员能搞定的。德勤调研把这种变化概括为ITAM从支持业务走向驱动业务这个说法我很认同。当ITAM的数据能直接帮助业务做决策——比如通过分析资源利用率决定要不要扩容、通过分析软件使用数据决定是否续费——它就真正进入了战略核心圈层。2. 德勤调研释放的三个关键信号2.1 信号的底层逻辑资产边界正在消失德勤调研里有一个判断我认为切中要害云和AI打破了传统IT资产的边界。过去IT资产的边界很清晰——这台服务器在机房里那个软件装在指定的机器上边界清楚归属明确。但在云环境里一个应用可能由几十个微服务组成每个微服务又依赖不同的云资源这些资源还随时在扩缩容你说这项资产的边界在哪里在AI场景下边界的模糊程度更高一个训练任务要消耗大量GPU算力模型文件存储在对象存储里训练数据散落在多个数据桶中这些都是资产但它们与传统意义上的硬件资产软件资产完全不是一回事。边界消失带来的直接后果是传统基于清单的管理方式失效了。你无法通过一份静态清单来管理一个动态的、有机关联的资产网络。调研里强调的资产关系管理——也就是搞清楚某项资产被哪个应用使用、依赖哪些其他资产、成本如何分摊——恰恰是应对边界模糊化的正确思路。这就像城市管理不能只统计每一栋楼还要知道每栋楼的水电从哪里来、垃圾往哪里去、与周边设施是什么关系才能真正做出有效规划。2.2 信号的核心路径ITAM与FinOps走向融合调研另一个值得注意的观点是ITAM和FinOps不再是两套并行体系而是正在走向深度融合。过去ITAM管资产FinOps管云成本两边各干各的。但实际操作中你会发现这两件事根本分不开——你连有哪些云资源都不知道怎么做成本优化连各业务线的资源用量都分不清怎么摊账连哪些资源的利用率长期偏低都不知道怎么降本我自己的经验是ITAM提供的是云成本分析的骨架资源清单、归属关系、生命周期状态。FinOps在这个骨架上填充血肉费率数据、计费模型、分摊规则、优化动作。没有骨架的血肉是瘫软的没有血肉的骨架是干枯的。德勤调研把这种融合关系正式点出来了对企业最大的启发是不要再单独建设一套ITAM系统、再买一套FinOps工具而是要让他们共享同一份数据底座。工具可以各用各的但资产元数据必须统一。2.3 信号的未来指向AI让ITAM智能化也要管理AI资产调研里关于AI的部分我认为包含两层含义而且很多人只看到了第一层。第一层是AI赋能ITAM——用AI技术提升资产管理的效率和能力。比如用机器学习做异常成本检测用自然语言处理自动识别合同关键条款用智能推荐算法给出资源优化建议。这些应用在部分领先企业里已经不是概念而是实际在跑的能力。我在后面第4部分会详细展开。第二层是ITAM要管理AI资产——AI模型、训练数据集、推理服务、GPU资源池这些都成为企业的新型IT资产需要纳入管理范畴。这一层代表企业容易忽略因为大家习惯了把AI当成项目而不是资产。但实际上一个已经投入生产的模型和一个运行中的业务系统一样都是需要持续管理、监控成本、控制风险的核心资产。德勤调研把AI资产管理作为未来ITAM的重要方向我认为这个信号对所有正在大规模落地AI的企业都值得认真对待。3. 云资产管理实操要点从发现到治理的完整链路3.1 第一步把云资产找全是地基工程做云时代的ITAM第一个拦路虎就是发现——你连自己家到底有哪些云资产都说不清楚。这不是危言耸听我在不少企业实测过通过云厂商的控制台和API拉出来的资源清单和实际运行中的资源数量往往有20%到30%的差距。差距主要来自几个方面开发人员临时创建的测试资源、通过基础设施即代码IaC工具自动创建但没有登记的资源、容器平台内部动态调度的Pod实例、以及一些长期遗忘的存量资源。要把资产找全单纯靠云厂商的控制台人工翻一遍是完全不够的。实操中建议至少叠加三层发现机制。第一层是调用云厂商的API做全量资源列举覆盖计算、存储、网络、数据库等所有资源类型这一步是基础但必须做而且要定期跑形成资产基线。第二层是结合云厂商的账单数据做反向验证账单里出现的每个产品线都应该能在资产清单里找到对应的资源对不上号的就是发现遗漏点。第三层是网络层发现通过分析VPC流日志、DNS解析记录和负载均衡配置找出那些通过API创建但没进CMDB的资源这招对影子IT尤其有效。补充一个实操细节多账号场景下要特别注意发现的完整性。很多企业用了云厂商的资源组或者账号分离策略开发、测试、生产各一套账号如果发现脚本只覆盖了主账号那数据就是残缺的。建议构建账号维度全覆盖的采集机制把每个账号的只读权限配好然后定时全量扫描将结果统一汇总到资产库里。这里我踩过的坑是权限配置不全——某个子账号漏开了只读权限导致该账号下的几十台实例完全没被发现直到月底账单出来才对上号。3.2 第二步资产建模不能照搬传统CMDB思路资产找全之后怎么把这些数据组织起来是个更考验功力的问题。很多团队把云资源直接塞进传统的CMDB表结构结果发现根本存不下——传统的配置项模型是为相对静态的对象设计的而云资源的属性变化太快。今天创建一台实例明天可能就换了规格后天可能就被弹性伸缩组销毁了用传统一台记录一行的方式记录不了这种动态变化。正确的做法是建立资源-关系-状态三层模型。资源层记录资源本身的属性比如实例ID、规格、可用区、镜像ID、标签等关系层记录资源之间的关系比如这个实例归属于哪个应用、连接了哪个负载均衡、挂载了哪块云硬盘状态层记录资源的生命周期状态包括运行中、已停止、待释放、已释放以及状态变更的时间线。关系和状态这两层是云资产管理与传统资产管理最大的区别也是价值密度最高的部分。举个实际例子排查成本浪费时一个实例本身可能看不出问题但如果你看到这个实例属于测试环境、已经连续运行30天、CPU平均利用率不到5%结论就很清晰了。没有关系层的数据你根本不知道这个实例属于哪个环境没有状态层的跟踪你也不知道它是长期运行还是刚刚创建判断自然做不出来。3.3 第三步标签治理是成本分摊和归属管理的前提云资产管理最容易被低估的一项工作就是标签治理。标签Tag是云平台用来标记资源的键值对听起来很简单但实际执行中的混乱程度远超想象。有的团队用departmenttech这样的标签有的用owner张三有的干脆不标任何标签结果就是成本账单出来之后谁也没法判断某个资源是哪个业务线的权责不清直接导致优化推不动。标签治理的落地建议是少而精再加强制策略。标签体系不要设计得太复杂通常4到6个核心标签就够了应用名称、环境类型、业务线、成本中心、负责人、创建渠道。标签多了没人愿意打也容易打错效果反而不如几个核心标签踏实。强制策略是指通过云平台的标签策略功能规定某些资源类型必须携带指定标签否则拒绝创建或自动标记为未归属性资源。这个策略推行初期肯定会有人抱怨流程变重了但坚持两三个月后当大家发现翻账单、做分摊一下子容易了很多抵触情绪会自然消退。我在一家制造企业推标签治理时用了两个账单周期的过渡期第一个周期只要求新创建资源必须打标签存量资源给了两周自查期第二个周期开始所有没有标签的资源由ITAM团队统一标记为待认领财务按未归属性成本单独列账并通知相关业务线限期认领。结果第一个月就有超过七成的存量资源被主动认领了剩下没认领的基本都是废弃资源清理掉反而是好事。4. AI赋能与AI资产的落地路径4.1 用AI提升ITAM数据质量从清洗规则到智能判断AI对ITAM最直接的价值体现在数据质量治理上。传统资产数据治理靠写规则比如名称里包含test的就是测试资源这种规则简单粗暴误判率很高。一个开发环境的实例名称可能完全不包含任何test字样一个生产实例搞不好名称里反而带着test因为创建时图省事随便起的。规则越写越多维护成本越来越高效果还不见得好。用AI做这件事的核心思路是让模型从历史数据中学习规律。比如资源用途分类可以把历史上有明确归属的资源数据作为训练样本让模型学习实例规格、名称特征、绑定的安全组、所属VPC、运行时间规律等多维特征从而预测一个新资源应该归属到哪类用途。内测阶段准确率可能会超过八成再配合少量人工复核效率远高于纯规则方案。异常检测是另一个AI的高价值场景。云成本数据是典型的时间序列数据非常适合用机器学习做异常识别。比如某个业务线的日成本突然从5万涨到8万AI异常检测模型会自动捕获这个变化并且通过下钻分析提示可能是哪些资源类型导致的。这套能力用传统阈值告警很难做好——阈值设得太松小波动全部漏掉设得太严每天告警刷屏没人看。机器学习模型可以学到正常波动范围把告警集中到真正需要关注的偏离事件上实测下来能把有效告警率提升一个量级。4.2 把AI资产纳入ITAM模型、数据、算力一个都不能少企业在AI建设上投入越来越大但针对AI资产的ITAM管理往往是一片空白。我见过不少企业GPU集群规模已经不小了但问到你到底有多少GPU资源在跑训练、多少在跑推理、空闲率是多少一个都答不上来。这种情况跟十年前大家搞不清自己有多少服务器如出一辙只不过这次的主角换成了GPU和模型。AI资产管理至少需要覆盖三个层面。算力层要管好GPU资源的分配和利用率包括每台GPU服务器上运行的训练任务、任务占用的显存和算力、任务结束后的释放情况。模型层要记录模型的版本、部署环境、依赖的数据集、调用频次和响应性能相当于给每个模型建立资产档案。数据层是最容易被忽视的——训练数据集本身就是重要的数据资产它们存放的位置、版本、访问权限、合规属性都要纳入资产管理范围。实操中建议从算力利用率单点切入因为这是最容易量化也最容易产生短期效果的方向。通过采集GPU利用率数据识别长期低占用的算力资源把空闲资源回收或重新分配通常一两个季度就能省下可观的成本。之后再逐步扩展到模型版本管理和数据资产治理让AI资产的ITAM体系逐步完善起来。4.3 AI与ITAM协同的边界工具可以辅助决策仍需人来做说句实话AI在ITAM领域能做的事情很多但把ITAM完全交给AI这种想法我是坚决反对的。AI可以帮你发现问题、提建议、做预测但最终的资源调整决策、成本优化动作、供应商合同变更都涉及真金白银和组织关系必须由人来拍板。举个我在实践中反复遇到的情况AI模型提示某台实例利用率连续30天低于2%建议释放。但这个实例可能是某个关键业务系统的备用节点虽然平时不用但故障发生时需要立即接管。如果ITAM团队不加判断就执行了AI的建议真出事的时候连回退的余地都没有。所以我的经验是AI在ITAM的定位是超级分析助手——它负责把海量数据变成清晰的问题清单和行动建议人负责做决策和承担责任。在流程设计上AI建议可以走自动生成工单、人工审批执行的路径既不拖慢节奏也保留风险控制环节。5. 把ITAM推向战略核心的落地方法5.1 组织定位ITAM不能只挂在行政部门或财务下面很多企业推进ITAM很难有起色根子上的问题在组织归属。ITAM如果挂在行政或后勤下面定位就是物资管理话语权很弱数据质量没人重视业务配合度也低如果挂在财务下面会偏重成本核算而忽视技术侧的资产运行状态如果挂在运维下面又容易变成资源监控忽略合规和采购视角。德勤调研里反复强调ITAM要变成战略职能组织定位就必须往上提。我认为比较合理的方式是ITAM团队直接向CIO或CTO汇报与运维、财务、采购、安全平级协作。ITAM负责人应该拥有跨部门协调权能推动各部门IT资产数据的责任归属。在一些先进企业里ITAM负责人已经类似IT资产战略官要定期向经营管理层汇报资产全景、成本趋势、合规风险。这个角色定位看起来有点超前但在云和AI投入占比越来越高的企业里它就是刚需。组织归属调整的同时人员结构也要变化。传统ITAM团队清一色是资产管理员懂Excel但不懂云、不懂API、不懂成本模型。战略级的ITAM团队需要三类角色搭配资产分析师负责数据治理和流程规范技术工程师负责云API对接、自动化采集和工具建设成本分析师负责账单分析、成本建模和优化建议。三类角色配齐了ITAM才真正有了战略支撑的能力底座。5.2 用影响力而不是权力推动协同ITAM的天然属性是功夫在别人身上——资产数据靠研发、运维、采购各环节产生ITAM团队自己不创造资产只负责管理和分析。这样一个协同依赖极强的职能如果靠行政命令去推动效果通常很差。研发在赶版本你要求他停下来填写资产登记信息他嘴上不说心里也烦。所以我一直强调ITAM要建立自己的影响力机制。影响力机制的核心是让配合ITAM的人获得好处。研发配合打了标签那ITAM就帮他们做成本可视化和优化分析让研发团队清楚知道自己的云成本花在哪运维配合提供了实例清单ITAM就帮他们自动发现闲置资源减轻运维的排查负担。当ITAM从催你交数据变成帮你解决问题协同阻力会小很多。另外一个实操经验是不要在流程上给配合者增加太多负担——标签规范、资产登记尽量自动化能通过接口采集的就不让人手工填写这样大家自然愿意配合。5.3 指标体系用数据向上证明战略价值ITAM想在企业里站稳战略地位光靠嘴上说重要没用要拿指标出来证明。建指标体系的逻辑是从活动指标到结果指标再到价值指标层层递进。活动指标包括采集覆盖率、标签覆盖率、数据准确率等这些证明你的基础工作做到了结果指标包括云成本浪费率、闲置资源占比、软件许可合规率等这些证明ITAM对运营产生了效果价值指标包括单位业务成本下降比例、通过资产优化节省的金额、因合规风险规避避免的损失等这些是给管理层看的直接关联企业收益。我建议ITAM团队在季度汇报时把这三层指标串成一个故事因为采集覆盖率从80%提升到了98%活动发现了价值300万的闲置资源结果经过与业务确认后回收了其中200万的资源价值。这种叙事方式比单纯罗列数据有说服力得多长期坚持下来管理层对ITAM的认知会从成本部门转为省钱部门甚至价值创造部门。6. 常见问题与避坑实录6.1 云资产识别的三大盲区根据我接触大量企业的经验云资产识别主要有三个高频盲区。第一个盲区是容器与无服务器资源。很多企业的资产盘点还停留在ECS和RDS层面但实际的业务负载已经大量跑在容器服务上了这些Pod和函数计算实例因为生命周期短、自动扩缩容很难被传统盘点手段覆盖而它们产生的成本占比往往已经被忽视地抬高。第二个盲区是云市场与第三方服务。企业通过云市场订购的中间件、SaaS服务、生态工具这些都是花钱的资产但因为没有对应的实例列表经常在盘点时被漏掉。对于这类资产建议从账单反查把云市场订单拉出来逐个登记。第三个盲区是跨账号共享资源。比如企业统一建了一个日志账号各业务线往里面投日志这个账号下的存储和流量成本被所有业务共享但传统按账号归属的盘点方式没法分摊最终变成隐性成本。对这种资源需要建立共享资源的成本分摊规则宁可粗略分摊也比不摊好。6.2 资产数据准确性没有一次性能解决的方案我得坦诚地说资产数据的100%准确是个理想状态现实中几乎不可能达到。云资源的动态性决定了数据会持续变化今天准确不代表明天准确。我的经验是与其追求绝对准确不如追求可用的准确和偏差可控。采集频率拉起来每日增量同步加每周全量对账让数据滞后控制在可接受范围内关键数据字段归属、成本中心、环境类型做强制校验保证核心维度不出错定期做账实核对以账单数据为基准反向验证资产清单的完整性。数据出问题的时候追责不是重点优化采集和治理机制才是重点。我曾经遇到过资产归属信息大面积丢失的情况排查发现是某个采集脚本批量修改标签时覆盖了原有数据。后来我们在脚本里加了保护逻辑修改标签前先备份、变更后自动校验、异常字段自动告警。这类问题每发生一次就补一个机制数据质量就会越来越稳。6.3 推进节奏的忠告不要试图一步到位最后一个我想认真分享的教训是ITAM战略化是一个演进过程不要指望几个月的项目就能从资产台账一步跨到战略决策中心。有的企业一开始就规划了宏大的蓝图——要上全套工具、要建立完整的资产图谱、要实现全自动优化闭环结果项目推进半年连基础数据都没填齐团队士气反而被消耗殆尽。更务实的路径是找到那个最能产生短期价值的切入点先跑起来。有些企业适合从云成本浪费治理切入因为效果直接、容易量化有些企业适合从软件合规切入因为审计风险逼在眼前有些企业适合从安全资产暴露面管理切入因为安全事件驱动的关注度高。无论选哪个切入点逻辑都一样先在小范围内证明ITAM的价值再逐步扩大范围、加深能力。我用过一句话来概括这个策略先做一个窄但深的成功案例再推广为广而实的全面能力。每一步都能看到实际收益战略化的路反而走得比一步到位的蓝图更远。德勤2025这份调研给行业提了个醒ITAM这个曾经在IT管理体系里最不起眼的角落正在变成云和AI时代组织能力的分水岭。那些能看清资产底数、管住成本流向、配好算力资源的企业在AI投入上会明显比对手更有底气。这个转变不会因为某份报告而一夜完成但它正在每一家企业的账单、每一份资产清单、每一次资源审批里悄悄发生。 云与AI时代ITAM迈向战略核心：从资产记账到决策支撑的落地路径
最近我把德勤发布的2025全球ITAM调研报告翻来覆去看了两遍越看越觉得题目里那句ITAM迈向战略核心不是公关话术而是过去三四年行业变化的真实落点。ITAM也就是IT资产管理以前在很多企业里就是个干杂活的角色登记一下电脑型号、统计一下软件授权、年底配合财务盘个点。但云和AI这两股力量一股脑涌进来之后这套玩法明显撑不住了——云资源弹性伸缩、AI模型和数据集大量涌现、订阅式软件越买越多资产台账再靠Excel和手工登记出来的数据只能是历史文物压根没法支撑任何决策。我见过不少企业云账单一个月几十万问财务花在哪了不知道问运维有多少实例在用不知道问研发哪些资源能停也不知道。这就是ITAM没跟上云时代节奏的典型症状。德勤这份调研就是把这个问题摆到了台面上ITAM不再是一个后台支撑职能而是直接影响成本、合规、安全和AI落地速度的战略级能力。整篇报告看下来我认为最有价值的不是那些趋势判断而是它对ITAM职责边界的重新定义。这篇文章我会顺着调研的核心逻辑把云与AI时代ITAM为什么变重要、具体怎么落地、有哪些坑要避开完整梳理一遍适合正在做IT资产、云成本治理、或准备搭建ITAM体系的同学参考。1. 为什么ITAM突然从配角变成了主角1.1 传统ITAM的困局台账越全用处越小很多企业做ITAM做了十几年资产库里的数据不可谓不全每台服务器的采购日期、保修期限、存放机房每套软件的采购单价、授权数量、到期时间全都登记得清清楚楚。但问题恰恰在于这些数据在云和AI时代变得全而无用。一台物理服务器的生命周期是3到5年采购时记录一次报废时更新一次中间基本不用管。但云上的虚拟机可能只活几个小时容器实例可能只有几分钟的生命周期如果还用采购登记的思维去管理等你手工录入完成资源早就销毁了。更麻烦的是成本维度。传统ITAM关注的是资产原值和折旧这对财务做固定资产核算没问题但对今天的成本优化来说远远不够。云资源的成本是持续发生的运营支出今天开一台高配实例明天忘了关就是实打实的浪费。我遇到过一个案例某团队为了跑一次数据迁移任务开了一台GPU实例任务跑完忘了释放整整挂了一个月账单上多了十几万。负责ITAM的同事说资产台账里记录了这台机器但记录不等于管理更不等于控制。这就是传统ITAM的核心困局它在用管理静态资产的思路应对动态化的IT环境它在用登记信息的方式回应决策对实时数据的需求。德勤调研之所以说ITAM要迈向战略核心本质上是因为过去那套记录资产现状的玩法已经无法回答老板们真正关心的问题——比如我们的云成本为什么涨了40%这些AI算力投入到底产生了多少业务价值我们的软件授权到底有没有合规风险。1.2 战略核心意味着什么从记账员到决策支撑当ITAM从记账转向决策支撑它的角色定位会发生三个明显变化。第一个变化是服务对象变了。传统ITAM主要服务财务和采购部门提供的是审计材料和预算依据现在ITAM要同时服务CFO、CIO、CTO、安全负责人甚至业务线负责人。CFO想知道云成本为什么波动CTO想知道研发环境有多少资源在空转安全负责人想知道哪些资产存在漏洞暴露风险这些需求没有一个能从传统的资产台账里直接得到答案但每一个都需要ITAM提供底层数据支撑。第二个变化是工作节奏变了。过去ITAM一个月出一份报告就算勤快现在云成本按小时计费、安全合规实时监测ITAM的数据更新频率必须从月度压缩到每日甚至实时。这不是简单增加人手就能解决的必须依赖自动化采集和持续发现机制靠人肉盘点在这个节奏下没有任何可行性。第三个变化是能力边界变了。战略级的ITAM不再是单纯的资产管理它要融合成本管理FinOps、安全合规、架构治理和供应商管理。一个典型的场景是某业务线要上线一个AI推理服务需要采购GPU资源。这时候ITAM要能回答——现有的GPU资源利用率如何是否还有闲置算力可以复用新采购的预算是否已经纳入年度计划供应商的报价与市场行情相比是否合理。这一串问题本质上已经是一个IT资产战略顾问要做的事而不是资产管理员能搞定的。德勤调研把这种变化概括为ITAM从支持业务走向驱动业务这个说法我很认同。当ITAM的数据能直接帮助业务做决策——比如通过分析资源利用率决定要不要扩容、通过分析软件使用数据决定是否续费——它就真正进入了战略核心圈层。2. 德勤调研释放的三个关键信号2.1 信号的底层逻辑资产边界正在消失德勤调研里有一个判断我认为切中要害云和AI打破了传统IT资产的边界。过去IT资产的边界很清晰——这台服务器在机房里那个软件装在指定的机器上边界清楚归属明确。但在云环境里一个应用可能由几十个微服务组成每个微服务又依赖不同的云资源这些资源还随时在扩缩容你说这项资产的边界在哪里在AI场景下边界的模糊程度更高一个训练任务要消耗大量GPU算力模型文件存储在对象存储里训练数据散落在多个数据桶中这些都是资产但它们与传统意义上的硬件资产软件资产完全不是一回事。边界消失带来的直接后果是传统基于清单的管理方式失效了。你无法通过一份静态清单来管理一个动态的、有机关联的资产网络。调研里强调的资产关系管理——也就是搞清楚某项资产被哪个应用使用、依赖哪些其他资产、成本如何分摊——恰恰是应对边界模糊化的正确思路。这就像城市管理不能只统计每一栋楼还要知道每栋楼的水电从哪里来、垃圾往哪里去、与周边设施是什么关系才能真正做出有效规划。2.2 信号的核心路径ITAM与FinOps走向融合调研另一个值得注意的观点是ITAM和FinOps不再是两套并行体系而是正在走向深度融合。过去ITAM管资产FinOps管云成本两边各干各的。但实际操作中你会发现这两件事根本分不开——你连有哪些云资源都不知道怎么做成本优化连各业务线的资源用量都分不清怎么摊账连哪些资源的利用率长期偏低都不知道怎么降本我自己的经验是ITAM提供的是云成本分析的骨架资源清单、归属关系、生命周期状态。FinOps在这个骨架上填充血肉费率数据、计费模型、分摊规则、优化动作。没有骨架的血肉是瘫软的没有血肉的骨架是干枯的。德勤调研把这种融合关系正式点出来了对企业最大的启发是不要再单独建设一套ITAM系统、再买一套FinOps工具而是要让他们共享同一份数据底座。工具可以各用各的但资产元数据必须统一。2.3 信号的未来指向AI让ITAM智能化也要管理AI资产调研里关于AI的部分我认为包含两层含义而且很多人只看到了第一层。第一层是AI赋能ITAM——用AI技术提升资产管理的效率和能力。比如用机器学习做异常成本检测用自然语言处理自动识别合同关键条款用智能推荐算法给出资源优化建议。这些应用在部分领先企业里已经不是概念而是实际在跑的能力。我在后面第4部分会详细展开。第二层是ITAM要管理AI资产——AI模型、训练数据集、推理服务、GPU资源池这些都成为企业的新型IT资产需要纳入管理范畴。这一层代表企业容易忽略因为大家习惯了把AI当成项目而不是资产。但实际上一个已经投入生产的模型和一个运行中的业务系统一样都是需要持续管理、监控成本、控制风险的核心资产。德勤调研把AI资产管理作为未来ITAM的重要方向我认为这个信号对所有正在大规模落地AI的企业都值得认真对待。3. 云资产管理实操要点从发现到治理的完整链路3.1 第一步把云资产找全是地基工程做云时代的ITAM第一个拦路虎就是发现——你连自己家到底有哪些云资产都说不清楚。这不是危言耸听我在不少企业实测过通过云厂商的控制台和API拉出来的资源清单和实际运行中的资源数量往往有20%到30%的差距。差距主要来自几个方面开发人员临时创建的测试资源、通过基础设施即代码IaC工具自动创建但没有登记的资源、容器平台内部动态调度的Pod实例、以及一些长期遗忘的存量资源。要把资产找全单纯靠云厂商的控制台人工翻一遍是完全不够的。实操中建议至少叠加三层发现机制。第一层是调用云厂商的API做全量资源列举覆盖计算、存储、网络、数据库等所有资源类型这一步是基础但必须做而且要定期跑形成资产基线。第二层是结合云厂商的账单数据做反向验证账单里出现的每个产品线都应该能在资产清单里找到对应的资源对不上号的就是发现遗漏点。第三层是网络层发现通过分析VPC流日志、DNS解析记录和负载均衡配置找出那些通过API创建但没进CMDB的资源这招对影子IT尤其有效。补充一个实操细节多账号场景下要特别注意发现的完整性。很多企业用了云厂商的资源组或者账号分离策略开发、测试、生产各一套账号如果发现脚本只覆盖了主账号那数据就是残缺的。建议构建账号维度全覆盖的采集机制把每个账号的只读权限配好然后定时全量扫描将结果统一汇总到资产库里。这里我踩过的坑是权限配置不全——某个子账号漏开了只读权限导致该账号下的几十台实例完全没被发现直到月底账单出来才对上号。3.2 第二步资产建模不能照搬传统CMDB思路资产找全之后怎么把这些数据组织起来是个更考验功力的问题。很多团队把云资源直接塞进传统的CMDB表结构结果发现根本存不下——传统的配置项模型是为相对静态的对象设计的而云资源的属性变化太快。今天创建一台实例明天可能就换了规格后天可能就被弹性伸缩组销毁了用传统一台记录一行的方式记录不了这种动态变化。正确的做法是建立资源-关系-状态三层模型。资源层记录资源本身的属性比如实例ID、规格、可用区、镜像ID、标签等关系层记录资源之间的关系比如这个实例归属于哪个应用、连接了哪个负载均衡、挂载了哪块云硬盘状态层记录资源的生命周期状态包括运行中、已停止、待释放、已释放以及状态变更的时间线。关系和状态这两层是云资产管理与传统资产管理最大的区别也是价值密度最高的部分。举个实际例子排查成本浪费时一个实例本身可能看不出问题但如果你看到这个实例属于测试环境、已经连续运行30天、CPU平均利用率不到5%结论就很清晰了。没有关系层的数据你根本不知道这个实例属于哪个环境没有状态层的跟踪你也不知道它是长期运行还是刚刚创建判断自然做不出来。3.3 第三步标签治理是成本分摊和归属管理的前提云资产管理最容易被低估的一项工作就是标签治理。标签Tag是云平台用来标记资源的键值对听起来很简单但实际执行中的混乱程度远超想象。有的团队用departmenttech这样的标签有的用owner张三有的干脆不标任何标签结果就是成本账单出来之后谁也没法判断某个资源是哪个业务线的权责不清直接导致优化推不动。标签治理的落地建议是少而精再加强制策略。标签体系不要设计得太复杂通常4到6个核心标签就够了应用名称、环境类型、业务线、成本中心、负责人、创建渠道。标签多了没人愿意打也容易打错效果反而不如几个核心标签踏实。强制策略是指通过云平台的标签策略功能规定某些资源类型必须携带指定标签否则拒绝创建或自动标记为未归属性资源。这个策略推行初期肯定会有人抱怨流程变重了但坚持两三个月后当大家发现翻账单、做分摊一下子容易了很多抵触情绪会自然消退。我在一家制造企业推标签治理时用了两个账单周期的过渡期第一个周期只要求新创建资源必须打标签存量资源给了两周自查期第二个周期开始所有没有标签的资源由ITAM团队统一标记为待认领财务按未归属性成本单独列账并通知相关业务线限期认领。结果第一个月就有超过七成的存量资源被主动认领了剩下没认领的基本都是废弃资源清理掉反而是好事。4. AI赋能与AI资产的落地路径4.1 用AI提升ITAM数据质量从清洗规则到智能判断AI对ITAM最直接的价值体现在数据质量治理上。传统资产数据治理靠写规则比如名称里包含test的就是测试资源这种规则简单粗暴误判率很高。一个开发环境的实例名称可能完全不包含任何test字样一个生产实例搞不好名称里反而带着test因为创建时图省事随便起的。规则越写越多维护成本越来越高效果还不见得好。用AI做这件事的核心思路是让模型从历史数据中学习规律。比如资源用途分类可以把历史上有明确归属的资源数据作为训练样本让模型学习实例规格、名称特征、绑定的安全组、所属VPC、运行时间规律等多维特征从而预测一个新资源应该归属到哪类用途。内测阶段准确率可能会超过八成再配合少量人工复核效率远高于纯规则方案。异常检测是另一个AI的高价值场景。云成本数据是典型的时间序列数据非常适合用机器学习做异常识别。比如某个业务线的日成本突然从5万涨到8万AI异常检测模型会自动捕获这个变化并且通过下钻分析提示可能是哪些资源类型导致的。这套能力用传统阈值告警很难做好——阈值设得太松小波动全部漏掉设得太严每天告警刷屏没人看。机器学习模型可以学到正常波动范围把告警集中到真正需要关注的偏离事件上实测下来能把有效告警率提升一个量级。4.2 把AI资产纳入ITAM模型、数据、算力一个都不能少企业在AI建设上投入越来越大但针对AI资产的ITAM管理往往是一片空白。我见过不少企业GPU集群规模已经不小了但问到你到底有多少GPU资源在跑训练、多少在跑推理、空闲率是多少一个都答不上来。这种情况跟十年前大家搞不清自己有多少服务器如出一辙只不过这次的主角换成了GPU和模型。AI资产管理至少需要覆盖三个层面。算力层要管好GPU资源的分配和利用率包括每台GPU服务器上运行的训练任务、任务占用的显存和算力、任务结束后的释放情况。模型层要记录模型的版本、部署环境、依赖的数据集、调用频次和响应性能相当于给每个模型建立资产档案。数据层是最容易被忽视的——训练数据集本身就是重要的数据资产它们存放的位置、版本、访问权限、合规属性都要纳入资产管理范围。实操中建议从算力利用率单点切入因为这是最容易量化也最容易产生短期效果的方向。通过采集GPU利用率数据识别长期低占用的算力资源把空闲资源回收或重新分配通常一两个季度就能省下可观的成本。之后再逐步扩展到模型版本管理和数据资产治理让AI资产的ITAM体系逐步完善起来。4.3 AI与ITAM协同的边界工具可以辅助决策仍需人来做说句实话AI在ITAM领域能做的事情很多但把ITAM完全交给AI这种想法我是坚决反对的。AI可以帮你发现问题、提建议、做预测但最终的资源调整决策、成本优化动作、供应商合同变更都涉及真金白银和组织关系必须由人来拍板。举个我在实践中反复遇到的情况AI模型提示某台实例利用率连续30天低于2%建议释放。但这个实例可能是某个关键业务系统的备用节点虽然平时不用但故障发生时需要立即接管。如果ITAM团队不加判断就执行了AI的建议真出事的时候连回退的余地都没有。所以我的经验是AI在ITAM的定位是超级分析助手——它负责把海量数据变成清晰的问题清单和行动建议人负责做决策和承担责任。在流程设计上AI建议可以走自动生成工单、人工审批执行的路径既不拖慢节奏也保留风险控制环节。5. 把ITAM推向战略核心的落地方法5.1 组织定位ITAM不能只挂在行政部门或财务下面很多企业推进ITAM很难有起色根子上的问题在组织归属。ITAM如果挂在行政或后勤下面定位就是物资管理话语权很弱数据质量没人重视业务配合度也低如果挂在财务下面会偏重成本核算而忽视技术侧的资产运行状态如果挂在运维下面又容易变成资源监控忽略合规和采购视角。德勤调研里反复强调ITAM要变成战略职能组织定位就必须往上提。我认为比较合理的方式是ITAM团队直接向CIO或CTO汇报与运维、财务、采购、安全平级协作。ITAM负责人应该拥有跨部门协调权能推动各部门IT资产数据的责任归属。在一些先进企业里ITAM负责人已经类似IT资产战略官要定期向经营管理层汇报资产全景、成本趋势、合规风险。这个角色定位看起来有点超前但在云和AI投入占比越来越高的企业里它就是刚需。组织归属调整的同时人员结构也要变化。传统ITAM团队清一色是资产管理员懂Excel但不懂云、不懂API、不懂成本模型。战略级的ITAM团队需要三类角色搭配资产分析师负责数据治理和流程规范技术工程师负责云API对接、自动化采集和工具建设成本分析师负责账单分析、成本建模和优化建议。三类角色配齐了ITAM才真正有了战略支撑的能力底座。5.2 用影响力而不是权力推动协同ITAM的天然属性是功夫在别人身上——资产数据靠研发、运维、采购各环节产生ITAM团队自己不创造资产只负责管理和分析。这样一个协同依赖极强的职能如果靠行政命令去推动效果通常很差。研发在赶版本你要求他停下来填写资产登记信息他嘴上不说心里也烦。所以我一直强调ITAM要建立自己的影响力机制。影响力机制的核心是让配合ITAM的人获得好处。研发配合打了标签那ITAM就帮他们做成本可视化和优化分析让研发团队清楚知道自己的云成本花在哪运维配合提供了实例清单ITAM就帮他们自动发现闲置资源减轻运维的排查负担。当ITAM从催你交数据变成帮你解决问题协同阻力会小很多。另外一个实操经验是不要在流程上给配合者增加太多负担——标签规范、资产登记尽量自动化能通过接口采集的就不让人手工填写这样大家自然愿意配合。5.3 指标体系用数据向上证明战略价值ITAM想在企业里站稳战略地位光靠嘴上说重要没用要拿指标出来证明。建指标体系的逻辑是从活动指标到结果指标再到价值指标层层递进。活动指标包括采集覆盖率、标签覆盖率、数据准确率等这些证明你的基础工作做到了结果指标包括云成本浪费率、闲置资源占比、软件许可合规率等这些证明ITAM对运营产生了效果价值指标包括单位业务成本下降比例、通过资产优化节省的金额、因合规风险规避避免的损失等这些是给管理层看的直接关联企业收益。我建议ITAM团队在季度汇报时把这三层指标串成一个故事因为采集覆盖率从80%提升到了98%活动发现了价值300万的闲置资源结果经过与业务确认后回收了其中200万的资源价值。这种叙事方式比单纯罗列数据有说服力得多长期坚持下来管理层对ITAM的认知会从成本部门转为省钱部门甚至价值创造部门。6. 常见问题与避坑实录6.1 云资产识别的三大盲区根据我接触大量企业的经验云资产识别主要有三个高频盲区。第一个盲区是容器与无服务器资源。很多企业的资产盘点还停留在ECS和RDS层面但实际的业务负载已经大量跑在容器服务上了这些Pod和函数计算实例因为生命周期短、自动扩缩容很难被传统盘点手段覆盖而它们产生的成本占比往往已经被忽视地抬高。第二个盲区是云市场与第三方服务。企业通过云市场订购的中间件、SaaS服务、生态工具这些都是花钱的资产但因为没有对应的实例列表经常在盘点时被漏掉。对于这类资产建议从账单反查把云市场订单拉出来逐个登记。第三个盲区是跨账号共享资源。比如企业统一建了一个日志账号各业务线往里面投日志这个账号下的存储和流量成本被所有业务共享但传统按账号归属的盘点方式没法分摊最终变成隐性成本。对这种资源需要建立共享资源的成本分摊规则宁可粗略分摊也比不摊好。6.2 资产数据准确性没有一次性能解决的方案我得坦诚地说资产数据的100%准确是个理想状态现实中几乎不可能达到。云资源的动态性决定了数据会持续变化今天准确不代表明天准确。我的经验是与其追求绝对准确不如追求可用的准确和偏差可控。采集频率拉起来每日增量同步加每周全量对账让数据滞后控制在可接受范围内关键数据字段归属、成本中心、环境类型做强制校验保证核心维度不出错定期做账实核对以账单数据为基准反向验证资产清单的完整性。数据出问题的时候追责不是重点优化采集和治理机制才是重点。我曾经遇到过资产归属信息大面积丢失的情况排查发现是某个采集脚本批量修改标签时覆盖了原有数据。后来我们在脚本里加了保护逻辑修改标签前先备份、变更后自动校验、异常字段自动告警。这类问题每发生一次就补一个机制数据质量就会越来越稳。6.3 推进节奏的忠告不要试图一步到位最后一个我想认真分享的教训是ITAM战略化是一个演进过程不要指望几个月的项目就能从资产台账一步跨到战略决策中心。有的企业一开始就规划了宏大的蓝图——要上全套工具、要建立完整的资产图谱、要实现全自动优化闭环结果项目推进半年连基础数据都没填齐团队士气反而被消耗殆尽。更务实的路径是找到那个最能产生短期价值的切入点先跑起来。有些企业适合从云成本浪费治理切入因为效果直接、容易量化有些企业适合从软件合规切入因为审计风险逼在眼前有些企业适合从安全资产暴露面管理切入因为安全事件驱动的关注度高。无论选哪个切入点逻辑都一样先在小范围内证明ITAM的价值再逐步扩大范围、加深能力。我用过一句话来概括这个策略先做一个窄但深的成功案例再推广为广而实的全面能力。每一步都能看到实际收益战略化的路反而走得比一步到位的蓝图更远。德勤2025这份调研给行业提了个醒ITAM这个曾经在IT管理体系里最不起眼的角落正在变成云和AI时代组织能力的分水岭。那些能看清资产底数、管住成本流向、配好算力资源的企业在AI投入上会明显比对手更有底气。这个转变不会因为某份报告而一夜完成但它正在每一家企业的账单、每一份资产清单、每一次资源审批里悄悄发生。