我为什么要做一个开源 ITSM 项目

云与数字化 | 开源 ITSM AI日志

很多企业不是没有系统，而是系统之间没有流程。

不是没有数据，而是数据无法在流程里流动。

过去几年，我一直在观察企业数字化项目。

一个很明显的现象是：企业买了很多系统，也上线了很多平台，但一到真实业务现场，很多事情还是回到了微信群、Excel、邮件、电话和人工协调。

出了故障，先在群里喊人。

有个需求，先找熟人问一下。

系统要变更，流程走一半，线下又补一堆沟通。

资产信息在 Excel 里，配置关系靠老员工记忆。知识库看起来有，但真正解决问题的时候，还是靠人翻历史聊天记录。

这不是某一家企业的问题。

这是很多企业数字化进入深水区后，都会遇到的问题。

系统越来越多，流程却越来越碎。

数据越来越多，上下文却越来越少。

工具越来越多，协同成本却没有真正下降。

所以我开始做一个开源 ITSM 项目。

项目已经开源在 GitHub：

https://github.com/heidsoft/itsm

我的目标很直接：

对标 ServiceNow，做一个面向国内企业、可扩展、AI Native 的开源 ITSM 平台。

这篇文章，我想讲清楚三件事：

1. 为什么我认为 ITSM 是企业数字化的一个关键入口；

2. 为什么中国企业需要一个开源、可控、可扩展的 ITSM 平台；

3. 为什么下一代 ITSM 一定会是 AI Native 的。

01

企业数字化真正卡住的地方，不是没有系统

很多企业数字化做了很多年。

OA 有了。ERP 有了。CRM 有了。监控系统有了。日志系统有了。运维平台有了。低代码平台有了。知识库也有了。

但一个真实问题来了，比如：

某个核心业务系统突然变慢，用户开始投诉，研发说不是代码问题，运维说资源指标正常，网络说链路没问题，业务说客户已经在催。

这时候，企业最需要的不是再打开一个系统。

企业最需要的是：

- 谁来接这个事件；

- 当前影响范围是什么；

- 关联哪些系统和资产；

- 最近有没有变更；

- 历史上有没有类似问题；

- 谁负责升级处理；

- 处理过程如何记录；

- 后续是否要转成问题管理；

- 是否需要形成知识库。

你会发现，真正的难点不是“有没有工具”。

真正的难点是：企业缺少一个能够把人、流程、系统、数据、知识连接起来的工作底座。

很多公司的数字化系统是“烟囱式”的。

每个系统都能解决一部分问题，但跨系统协同时，流程就断了。

监控系统能发现告警，但不知道业务影响。CMDB 有资产信息，但和工单处理脱节。知识库有文档，但不能自动进入处理流程。流程系统能审批，但不理解 IT 服务上下文。协同工具能沟通，但沟通过程无法结构化沉淀。

于是，企业越数字化，系统越多，人的协调负担反而越重。

这也是我为什么重新看 ITSM。

ITSM 不是一个简单的工单系统。它更像是企业 IT 运行过程中的流程中枢。

02

ITSM 不只是工单系统，而是企业服务管理的入口

很多人一听 ITSM，第一反应是：不就是工单系统吗？

这个理解太窄了。

工单只是 ITSM 的表层形态。真正的 ITSM，要解决的是企业 IT 服务如何被定义、交付、运营、改进。

按照 ITIL 的思想，ITSM 关注的是服务生命周期。

从用户提交一个服务请求，到 IT 团队处理一个事件；从分析一个长期问题，到执行一次变更；从管理资产和配置项，到形成知识沉淀和服务目录。

它背后是一整套流程体系。

事件管理：出了故障，如何快速恢复服务；

问题管理：反复出现的问题，如何找到根因；

变更管理：系统调整，如何控制风险；

发布管理：版本上线，如何可控交付；

服务请求：账号、权限、资源，如何标准化处理；

知识管理：处理经验如何沉淀和复用；

CMDB：资产、系统、应用、服务之间的关系如何管理。

如果这些能力只是分散在不同系统里，企业就很难形成闭环。

一个事件处理完了，如果没有问题管理，根因就没人追。一个变更上线了，如果没有 CMDB，影响范围就只能靠经验判断。一个故障解决了，如果没有知识管理，下次还会从头再来。一个服务请求完成了，如果没有流程数据，管理层看不到服务质量。

所以 ITSM 的核心，不是“记录工单”。

而是把企业 IT 运行过程结构化。

结构化之后，才有可能度量。

有了度量，才有可能优化。

有了优化，才有可能自动化。

有了自动化，AI 才真正有上下文可以工作。

03

为什么要对标 ServiceNow

谈 ITSM，绕不开 ServiceNow。

ServiceNow 最厉害的地方，不是它做了一个工单系统。

而是它把 ITSM 做成了一个企业级平台。

它有流程，有数据模型，有 CMDB，有自动化，有集成能力，有生态，有应用扩展能力。

这说明一件事：

ITSM 可以从一个工具，演进成企业数字化平台。

很多企业一开始只是想解决工单问题，但做着做着就会发现，工单背后连接的是更大的东西：

- 组织和角色；

- 服务目录；

- 资产和配置；

- 权限和审批；

- 供应商和合同；

- 变更和发布；

- 风险和合规；

- 知识和自动化；

- 用户体验和服务质量。

ServiceNow 的价值就在于，它不是只解决某一个点，而是围绕“服务管理”构建了一个平台。

但对国内企业来说，也有自己的现实问题。

第一，成本问题。

不是所有企业都能承担大型商业平台的采购和实施成本。

第二，本土化问题。

国内企业大量使用飞书、企业微信、钉钉、国产 OA、内部自研系统。这些系统的集成方式、组织结构、审批习惯、权限体系，都有明显的本土特点。

第三，私有化和可控问题。

很多企业对数据安全、部署环境、二次开发、国产化适配有明确要求。

第四，生态问题。

如果平台不可扩展，企业就只能依赖厂商交付。但企业内部系统太多、流程差异太大，单靠标准产品很难覆盖全部场景。

所以我认为，国内需要一个开源的 ITSM 平台。

不是简单复制 ServiceNow。

而是学习它的平台化思路，同时面向国内企业环境重新设计：

- 更容易私有化部署；

- 更适合国内协同工具；

- 更开放的连接器机制；

- 更灵活的流程自定义；

- 更适合 AI Native 的架构；

- 更低门槛的二次开发和生态扩展。

开源在这里不是一个口号。

开源意味着透明，意味着可控，意味着可以被验证，也意味着可以围绕真实用户需求持续演进。

04

为什么是 AI Native ITSM

现在很多系统都在讲 AI。

但我不太认同一种做法：

给原来的系统加一个聊天框，然后就叫 AI 化。

对于 ITSM 来说，AI 的价值不应该停留在“问答”。

AI 应该深入到流程、数据、知识和动作里面。

我理解的 AI Native ITSM，至少包括几个层次。

第一，AI 能理解工单。

用户提交一段自然语言：我的电脑连不上 VPN，昨天还能用，今天早上开始报错，影响远程办公。

系统不应该只把它当成一段文本。它应该识别这是事件还是服务请求，可能属于哪个服务目录，优先级大概是多少，是否有类似历史工单，应该分派给哪个团队，是否可以直接推荐解决方案。

第二，AI 能辅助处理。

工程师接到工单后，不应该从零开始查。AI 可以基于历史工单、知识库、监控数据、CMDB 关系，给出处理建议。

第三，AI 能生成流程。

未来企业创建流程，不应该完全依赖拖拽表单和人工配置。用户可以直接描述：我需要一个服务器申请流程，先由部门负责人审批，再由 IT 资源管理员分配资源，超过 32 核 CPU 需要架构组复核，完成后自动通知申请人。

AI 应该能够把这段话转成流程草稿，包括表单字段、审批节点、条件分支、通知动作、权限规则、关联资产和 SLA 要求。人再去审核和调整。

第四，AI 能调用连接器执行动作。

真正有价值的企业 AI，不只是回答问题，而是完成动作。比如在飞书里通知审批人，在企业微信里发送告警，在钉钉里创建待办，调用云平台创建资源，调用监控系统查询指标，调用 CMDB 更新配置项，调用知识库生成处理文档。

这就需要连接器市场、插件市场和 Skill 市场。

AI 不能孤立存在。AI 必须连接企业内部系统，才能从“助手”变成“执行者”。

这也是我为什么在 ITSM 项目里会考虑连接器、插件、Skill、CLI 这些方向。

下一代企业软件，不只是页面和表单。它还应该是 AI 可以理解、调用和扩展的平台。

05

这个开源 ITSM 项目准备做什么

我对这个项目的定位，不是做一个轻量工单系统。

而是做一个面向企业数字化场景的开源 ITSM 平台。

第一阶段，先把 ITSM 的主干打稳。

包括事件管理、问题管理、变更管理、服务请求、用户、组织、角色、权限、SLA、知识库、CMDB、服务目录、基础报表和审计。

这一阶段的核心目标是：让企业可以用它跑起来基础 ITSM 流程。

第二阶段，强化平台能力。

包括自定义表单、自定义流程、多租户、权限模型、操作审计、通知中心、报表分析、API 开放能力。

这一阶段的目标是：让它从一个应用，变成一个可扩展的平台。

第三阶段，打通国内企业协同系统。

包括飞书、企业微信、钉钉、邮件、Webhook、内部 OA、监控系统、云平台、代码仓库、CI/CD 系统。

这一阶段的目标是：让 ITSM 不再是孤岛，而是企业内部系统连接的流程入口。

第四阶段，建设生态能力。

包括连接器市场、插件市场、Skill 市场、模板市场、流程市场、CLI 工具、开发者文档。

这一阶段的目标是：让更多人可以基于这个平台扩展能力，而不是所有东西都由项目本身完成。

第五阶段，走向 AI Native。

包括 AI 工单分类、AI 工单摘要、AI 知识推荐、AI 流程生成、AI 变更风险评估、AI 故障复盘、AI 运维助手、AI 驱动的连接器调用。

这一阶段的目标是：让 ITSM 从记录系统，变成理解系统，再变成执行系统。

06

为什么我选择开源

做企业软件，开源不是一条容易的路。

尤其是 ITSM 这种系统。

它涉及流程、权限、数据模型、组织架构、系统集成、企业场景理解。复杂度很高。

但我还是选择开源，原因有几个。

第一，我希望这个项目被真实使用者验证。

企业软件最怕闭门造车。流程系统尤其如此。不同企业的组织结构、流程习惯、审批方式、系统环境都不一样。只有开源，才能让更多人看到设计，也能让真实问题更早暴露出来。

第二，ITSM 本身适合生态化。

一个 ITSM 平台不可能内置所有连接器，也不可能覆盖所有行业流程。未来一定需要社区、开发者、企业用户一起扩展。

第三，开源更适合建立信任。

企业软件不是一个简单 App。用户会关心数据怎么存、权限怎么控、是否能私有化、能不能二次开发、出问题能不能自己排查、会不会被厂商锁死。

第四，我也希望用开源作为一人创业的基础。

一个人做企业软件，最缺的不是想法，而是信任、反馈和分发。公众号可以建立认知，GitHub 可以承载产品，文章可以持续解释理念，社区可以带来反馈。如果这些能形成闭环，一个人也可以逐步构建一个长期项目。

开源至少给了用户一个基本答案：你可以看见它，理解它，修改它，也可以参与它。

07

我对这个项目的长期判断

我认为未来企业软件会发生几个变化。

第一，流程会越来越重要。

因为系统越多，越需要流程来连接。没有流程，系统只是数据库和页面。有了流程，系统才进入企业真实运行。

第二，数据上下文会越来越重要。

AI 要在企业里真正有用，不能只靠大模型本身。它需要知道用户是谁，属于哪个组织，正在处理什么流程，关联哪个系统，影响哪些资产，有哪些历史记录，当前权限是什么，下一步能做什么。

第三，企业 AI 会从问答走向动作。

过去大家问 AI：这个问题怎么解决？未来会变成：帮我创建流程，帮我分析故障影响，帮我生成变更方案，帮我通知相关负责人，帮我调用系统完成处理，帮我沉淀知识库。

第四，开源企业软件会有新的机会。

特别是在 AI 时代。因为企业不希望关键流程完全黑盒化，也不希望所有数据都被锁在某个封闭平台里。开源、私有化、可扩展、本土化，会成为很多企业的重要选择。

这也是我做这个项目的底层判断。

08

接下来我会持续记录这个过程

这个项目不会一篇文章讲完。

接下来，我会在“云与数字化”持续记录它的设计、开发和思考。

- ITSM 产品设计；

- ITIL v3 流程拆解；

- CMDB 建模；

- 工作流引擎设计；

- 多租户和权限体系；

- 连接器市场设计；

- 插件和 Skill 机制；

- AI Native ITSM 架构；

- 对标 ServiceNow 的产品研究；

- 一个技术人如何通过开源做一人创业。

我也会写一些更具体的文章，比如：

《中国企业为什么需要一个开源版 ServiceNow》

《CMDB 为什么难做？因为它不是一张资产表》

《AI Native ITSM 不是给工单系统加一个聊天框》

《连接器市场：企业 AI 落地绕不开的基础设施》

《企业数字化的深水区，其实是流程问题》

这不是一个短期项目。

更像是我给自己设定的一条长期路线。

用开源项目承载产品。用公众号沉淀思考。用真实用户反馈推动迭代。用 AI 重新设计企业流程系统。

结语

很多企业已经不缺系统了。

真正缺的是把系统连接起来的流程底座。

不缺数据。

缺的是让数据在流程里流动的上下文。

不缺工具。

缺的是一个能把人、流程、资产、知识、自动化和 AI 连接起来的平台。

这就是我为什么要做一个开源 ITSM 项目。

项目地址：

https://github.com/heidsoft/itsm

如果你关注 ITSM、AIOps、CMDB、企业数字化、AI Native 企业软件，欢迎一起交流。

我正在做一个开源 ITSM 项目，目标是对标 ServiceNow，构建面向国内企业的 AI Native ITSM 平台。

方向包括：ITIL v3、CMDB、流程引擎、连接器市场、插件市场、Skill 市场、企业 AI 自动化。