目录
AS-IS 和 TO-BE 是做流程梳理、系统规划、产品设计、数字化转型时非常常见的一对词。
最简单理解：
AS-IS = 现在是什么样 TO-BE = 未来希望变成什么样
中间通常还会有一个：
GAP = 现状和目标之间的差距
所以经常会看到：
AS-IS → GAP Analysis → TO-BE
一、AS-IS 是什么意思？
AS-IS，直译就是：
按现在的样子、现状、当前状态
在工作里通常表示：
- 当前业务流程是怎么跑的
- 当前系统是怎么用的
- 当前有哪些问题
- 当前组织职责怎么分工
- 当前数据是怎么维护的
- 当前审批、操作、协作方式是什么
也可以理解成：
“我们现在到底是怎么干活的？”
例如你要设计一个 CMDB 系统，不能一上来就设计页面，而是先搞清楚 AS-IS。
CMDB 的 AS-IS
假设现在运维资产管理是这样的：
服务器信息放在 Excel A 域名放在 Excel B 数据库账号放在 Excel C 云服务器信息又记录在阿里云、腾讯云后台 业务系统负责人靠微信群询问 系统和服务器之间没有明确关联关系 Excel 更新后也不知道是谁修改的
这就是：
AS-IS：当前资产管理现状。
可以整理成：
| 维度 | AS-IS 当前现状 |
|---|---|
| 服务器 | Excel 手工维护 |
| 域名 | 独立 Excel 管理 |
| 数据库 | 单独表格记录 |
| 业务系统 | 没有统一台账 |
| 资产关系 | 靠人工记忆 |
| 负责人 | 企业微信询问 |
| 变更记录 | 基本没有 |
| 权限控制 | Excel 文件权限 |
| 统计分析 | 手工汇总 |
二、TO-BE 是什么意思？
TO-BE 表示：
未来目标状态、希望达到的状态、设计后的状态
也就是：
“以后我们希望怎么干？”
继续上面的 CMDB 例子。
CMDB 的 TO-BE
希望未来做到：
所有 IT 资产统一进入 CMDB 管理；
服务器、业务系统、数据库、域名、证书、云账号建立关联关系；
每个资产都有负责人、所属公司、环境、生命周期状态；
资产变更有记录；
可以按照公司、系统、负责人、环境进行查询统计。
那么这就是：
TO-BE：CMDB 建设完成后的目标状态。
例如：
| 维度 | AS-IS | TO-BE |
|---|---|---|
| 服务器 | Excel 管理 | CMDB 统一管理 |
| 业务系统 | 靠人工记录 | 建立业务系统模型 |
| 系统与服务器关系 | 靠记忆 | 系统自动关联 |
| 数据库 | 单独 Excel | 关联业务系统、服务器 |
| 域名 | 独立维护 | 关联业务系统 |
| 负责人 | 企业微信询问 | 系统明确责任人 |
| 变更 | 无记录 | 自动记录变更历史 |
| 查询 | 多 Excel 查找 | 全局搜索 |
| 统计 | 手工统计 | Dashboard 自动统计 |
三、最容易理解的例子：请假流程
假设公司现在员工请假。
AS-IS
现在的流程：
员工 → 企业微信找领导 → 领导回复同意 → 员工通知行政 → 行政 Excel 登记
可能出现的问题：
- 领导忘记回复
- 行政不知道审批结果
- Excel 漏登记
- 不知道员工今年请了多少天
- 无法查询历史审批
- 没有统一流程
这就是 AS-IS Process：
员工 ↓ 企业微信找领导 ↓ 领导回复 ↓ 通知行政 ↓ 行政登记 Excel
TO-BE
未来设计 OA 系统：
员工提交请假单 ↓ 系统自动发送给直属领导 ↓ 领导审批 ↓ 系统自动通知员工 ↓ 自动进入考勤系统 ↓ 自动统计剩余年假
这就是 TO-BE Process。
所以：
AS-IS
企业微信 + Excel + 人工通知
↓ 系统改造
TO-BE
OA审批 + 自动通知 + 自动统计
四、再举一个你比较常见的例子：IT 工单
假设现在 IT 运维处理员工问题。
AS-IS
员工电脑有问题：
员工 ↓ 企业微信找运维 ↓ 运维处理 ↓ 处理完成 ↓ 聊天记录结束
存在问题：
- 到底处理了多少问题不知道
- 谁处理的不清楚
- 有没有超时不知道
- 历史问题无法统计
- 同样的问题反复处理
- 老板看不到运维工作量
这就是：
AS-IS：当前 IT 支持模式
TO-BE
引入 IT 服务中心：
员工提交工单 ↓ 自动生成工单编号 ↓ 自动分配运维人员 ↓ 运维处理 ↓ 记录处理过程 ↓ 用户确认 ↓ 关闭工单 ↓ 自动进入统计报表
同时老板可以看到：
- 今日新增工单
- 待处理工单
- 已解决工单
- 平均处理时长
- 每个运维处理数量
- 高频问题
- SLA 达成率
这就是：
TO-BE：未来 IT 服务管理模式
五、AS-IS / TO-BE 在产品经理工作里尤其重要
产品经理经常不是直接画原型，而是：
1. AS-IS 现状调研 ↓ 2. Pain Points 痛点分析 ↓ 3. GAP 差距分析 ↓ 4. TO-BE 目标流程设计 ↓ 5. Product Design 产品设计 ↓ 6. Implementation 系统落地
例如设计一个 CRM。
第一步：AS-IS
了解销售现在怎么管理客户：
- Excel
- 微信
- 手机通讯录
- 企业微信
- 邮件
- 自己的小本本
第二步：找问题
例如：
- 客户资料掌握在销售个人手里
- 销售离职客户可能丢失
- 老板不知道客户跟进情况
- 不知道多少潜在客户
- 不知道哪个销售转化率高
- 客户重复跟进
第三步：TO-BE
CRM 未来设计：
线索 ↓ 客户 ↓ 联系人 ↓ 商机 ↓ 报价 ↓ 合同 ↓ 订单 ↓ 回款
老板可以查看：
客户数量 商机金额 成交率 销售漏斗 销售排名 客户跟进情况 预测收入
这就是典型：
AS-IS → TO-BE。
六、再举一个“系统发布”的例子
比如研发系统发布。
AS-IS
开发： 这个版本可以发了 ↓ 微信通知 运维： 升级哪个系统？ ↓ 再问开发 开发： A系统 2.1 B系统 3.2 ↓ 运维操作 发现数据库脚本没给 ↓ 再找开发
问题：
- 发布内容不明确
- 依赖系统不明确
- 发布负责人不明确
- 数据库脚本遗漏
- 回滚方案缺失
- 没有历史记录
TO-BE
以后全部通过发布工单：
提交发布申请
↓
填写发布版本
↓
填写关联/依赖系统
↓
填写负责人
↓
填写数据库变更
↓
填写发布步骤
↓
填写回滚方案
↓
审批
↓
执行发布
↓
验证
↓
关闭
这就是非常标准的：
AS-IS 流程分析 → TO-BE 流程设计
七、AS-IS 不只是“流程”
很多人误以为 AS-IS / TO-BE 只用于流程，其实范围很广。
例如可以分析：
| 分析对象 | AS-IS | TO-BE |
|---|---|---|
| 业务流程 | 当前怎么操作 | 未来怎么操作 |
| 系统架构 | 当前有哪些系统 | 未来系统架构 |
| 数据 | Excel 分散管理 | 数据统一管理 |
| 组织 | 职责混乱 | 明确责任边界 |
| 权限 | 大家都有权限 | RBAC 权限体系 |
| 运维 | 人工操作 | 自动化运维 |
| 监控 | 多个平台 | 统一监控平台 |
| 发布 | 微信通知 | 工单审批 |
| 资产 | Excel | CMDB |
| 报表 | 人工统计 | Dashboard |
八、还有一个很重要的词：GAP
完整方法论通常是：
AS-IS 当前状态 ↓ GAP 差距 ↓ TO-BE 目标状态
例如 CMDB：
AS-IS
资产全部 Excel 管理。
TO-BE
资产统一进入 CMDB。
GAP
那么中间差什么？
可能包括：
- 没有统一资产模型
- 没有资产编号
- 数据质量差
- Excel 数据格式不一致
- 缺负责人
- 缺系统与服务器关系
- 缺权限体系
- 缺变更记录
- 缺数据导入工具
这些就是：
Gap Analysis（差距分析）。
九、在 PPT / 产品方案里可以怎么写？
如果你以后写产品方案，可以直接使用这样的结构：
1. AS-IS：现状分析
描述：
当前运维资产主要通过 Excel、云平台后台及人工台账进行分散管理，各类资产之间缺乏统一的关联关系，资产负责人、所属业务系统、运行环境等信息维护方式不一致，资产变更缺乏完整记录，难以形成统一、准确、实时的资产视图。
然后列：
数据分散 信息不统一 关系不清晰 更新不及时 无法追溯 统计困难
2. TO-BE：目标蓝图
描述：
建设统一 CMDB 资产管理平台，将服务器、业务系统、数据库、域名、证书、云资源等 IT 资产纳入统一管理，并建立资产之间的关联关系，实现资产全生命周期管理、责任人管理、变更追踪、统一查询及统计分析。
然后画成：
CMDB
│
┌────────────┼────────────┐
↓ ↓ ↓
业务系统 服务器 云资源
│ │
↓ ↓
域名 数据库
│
↓
证书
十、你可以把它理解成“改造前 / 改造后”
如果不想记英文，直接记：
AS-IS = Before = 改造前 / 现状
TO-BE = After = 改造后 / 目标
例如：
AS-IS
Excel 管资产
↓
TO-BE
CMDB 管资产
或者：
AS-IS
企业微信报障
↓
TO-BE
IT 工单系统报障
或者：
AS-IS
人工登录服务器执行 Shell
↓
TO-BE
统一作业平台自动执行
最后给你一个非常实用的公式
以后设计任何系统，都可以先问这 5 个问题：
1. AS-IS 现在是怎么做的？ 2. PAIN POINT 现在有什么问题？ 3. WHY 为什么要改？ 4. TO-BE 未来希望怎么做？ 5. HOW 系统怎么实现？
也就是：
现状 → 问题 → 原因 → 目标 → 产品方案
这个思路特别适合写 CRM、CMDB、工单系统、OMS、运维系统、OA 这类产品方案。