SF流程与规范：管理层任务依赖效率提升关键指标

去年我帮一家做智能硬件的公司做流程诊断，他们的研发副总给我看了一张流程图：从需求评审到量产交付，节点清清楚楚，泳道图也画得很漂亮。但他补了一句让我印象很深的话："流程是完整的，可项目还是平均延期 11 天。"我让他把最近 30 个延期项目拉出来，逐个标注延期发生在哪里。结果 30 个项目里，只有 4 个是真正"节点任务做慢了"，其余 26 个的延期时间主要消耗在同一件事上，等前置任务交付、等审批拍板、等另一个部门把接口对完。

换句话说，流程图没有告诉你项目为什么慢，因为慢的地方根本不在节点内部，而在节点之间的依赖缝隙里。

这就是"SF流程与规范"落地时最容易被忽略的一层：流程规范管的是"谁在什么时候做什么"，而管理层真正该管的是"任务之间的依赖有没有被量化、被跟踪、被升级"。本文围绕《SF流程与规范：管理层任务依赖效率提升关键指标》这个主题，给出一套可以直接拿去用的依赖分类、指标口径、看板结构和 30/60/90 天落地路径。文章里用到的所有数据都来自我参与过的项目观察，属于样本推演和情景模拟，不是行业基准，请按自己企业的基线重新校准。

一、先给核心结论：流程效率的大头在依赖等待，不在节点处理

先把最关键的判断放在前面，避免读者看到最后才发现方向错了。

结论一：SF流程规范能否生效，取决于你是否承认"依赖等待"是一个独立可测量的效率损失项。大多数企业的流程管理停留在"节点是否按时完成"，而跨部门项目的真实周期里，等待时间往往占一半以上。你不测量它，它就不会被管理。

结论二：管理层任务依赖效率的提升，主指标应当是"依赖等待时长"和"阻塞任务数"，而不是任务完成率。任务完成率是结果指标，滞后且容易被"提前标记完成"污染；依赖等待时长是过程指标，能直接指向可干预的动作。

结论三：指标不需要多，需要的是每个指标都有定义、公式、数据源和责任人。我见过太多团队列了 20 个流程 KPI，最后一个都没跑起来。下面我会给出 9 类指标，但建议你先只上 3 个。能持续跑通的 3 个指标，价值远高于挂在墙上的 20 个。

关于本文中"SF"的指代，需要先说明清楚。SF 在不同语境下可能指 CRM 平台、物流企业、制造现场管理或企业内部流程系统的缩写。本文讨论的是企业内部流程与规范意义上的 SF，即一套跨部门、跨角色、有明确节点和交付标准的流程体系。无论你所在的行业是研发、制造、供应链还是服务交付，依赖关系的管理逻辑是相通的。如果你所在企业的 SF 有特定含义，请把下面的框架映射到你的实际场景。

二、背景和真实场景：项目为什么"卡在等人"

先说清楚问题的来源，否则后面的指标会显得像是凭空造出来的。

1. 一个真实的延期结构拆解

回到开头那家智能硬件公司。我把 30 个延期项目的延期天数做了归类，结果大致是这样的：纯粹因为某个节点执行超时的，占延期总天数的 14%；因为前置任务交付延迟导致后置任务无法启动的，占 31%；因为审批或决策等待的，占 27%；因为信息口径不一致导致返工的，占 19%；其余为外部因素（供应商、认证等），占 9%。

这组数字不是行业基准，是我在那个项目里的实测样本。但它说明了一件事：如果把依赖等待、审批等待和返工加起来，占比接近 77%，远超节点执行本身。而这家公司的流程图和流程规范文件，恰恰只覆盖了那 14% 的部分。

2. 五种任务依赖，各自的等待形态不同

在多个项目里，我习惯把任务依赖分成五类。分类的意义在于：不同类型的依赖，治理动作完全不同，混在一起谈就会变成空话。

• 顺序依赖：A 完成后 B 才能开始。典型场景是需求评审通过后才能进入开发排期。它的等待表现为"后置任务空等"，治理靠明确的交付标准和完成定义。
• 资源依赖：多个任务共用同一批人、预算、设备或系统环境。典型场景是测试环境只有一套，两个项目排队。它的等待表现为"排队"，治理靠资源日历和优先级仲裁机制。
• 信息依赖：后置任务需要前置方提供数据、口径、文档或需求说明。典型场景是财务口径和业务口径不一致，报表反复改。它的等待表现为"返工"，治理靠输入物模板和口径确认单。
• 审批与决策依赖：需要管理层、法务、财务会签或拍板。典型场景是超预算采购需要两级审批。它的等待表现为"决策响应时间"，治理靠 SLA 和授权分级。
• 跨部门接口依赖：两个部门之间有明确交接动作。典型场景是研发交付给生产，生产交付给售后。它的等待表现为"交接延迟和交接质量不达标"，治理靠接口人和交接验收清单。

这五类依赖里，顺序依赖和信息依赖最容易改，审批依赖最难改但收益最直接，跨部门依赖最容易被误判为"部门墙"。下面会逐一展开。

3. 为什么流程图看不出来这些问题

流程图是静态的，它表达的是"应该怎么走"，不表达"实际等了多久"。一张泳道图能画出谁负责哪个节点，但画不出"这个节点在等上一个人的交付物，而那个交付物迟了 5 天"。

更麻烦的是，流程规范文件通常只定义节点责任，不定义节点之间的输入条件、完成标准、等待上限和升级路径。于是流程看起来完整，运行起来全靠个人推动。谁催得紧，谁的活先干，这不是流程管理，这是人情调度。

三、拆解常见误区：为什么你的流程规范没提速

我复盘过不少流程优化失败的项目，失败原因高度集中在几个误区上。这些误区有一个共同特征：听起来都对，但没法执行。

1. 把"画完流程图"当成流程规范完成

流程图只是流程规范的第一个交付物，不是最终交付物。真正让流程跑起来的，是节点之间的约定：输入物是什么格式、什么时候必须给出、达不到标准怎么办、超时了谁升级。

判断标准很简单：如果你的流程文件里没有"超时升级"这四个字，那它就不是可执行规范，而是示意图。

2. 指标堆太多，没有主指标

很多团队一上来就定义十几个 KPI：周期时间、按时率、返工率、满意度、自动化率、合规率……结果第一次月度复盘会就开不下去，因为数据口径对不上，没人认领。

我的建议是一个阶段只上一个主指标加两个辅助指标。比如第一个季度主指标是"依赖等待时长"，辅助指标是"阻塞任务数"和"审批周期"。其余指标等主指标跑稳了再加。

3. 把依赖冲突当成"部门墙"，用沟通会解决

"加强沟通协作"是流程问题里最没用的一句话。跨部门交接延迟，通常不是态度问题，而是没有定义交接标准和交接人。你没有告诉对方"什么算交接完成"，对方交出来的东西自然反复退回。

换一个动作：在关键交接点设置"接口人 + 交接验收清单"。接口人负责推动，清单负责判断合格与否。这比开三次协调会有效得多。

4. 用行业基准替代企业自身基线

我经常被问到"行业平均审批周期是多少天"。这个问题本身就有问题。行业基准可以作为参考，但你必须先建立自己的基线，否则无法判断改善是否真实发生。

正确做法是：先跑一个月的数据，算出当前基线（比如平均审批周期 4.2 天），设定一个改进目标（比如压到 2.5 天），然后持续跟踪。没有基线的目标都是口号。

5. 只上线看板，不建立会议机制和责任人

看板是工具，不是机制。我见过团队做了很漂亮的流程驾驶舱，但没人看，因为没有对应的会议节奏。

数据要进入管理动作，必须绑定三件事：谁负责、多久看一次、看到红灯做什么。缺任何一件，看板就会变成装饰品。

四、专业判断逻辑：管理层该盯什么、怎么盯

这一节讲判断框架。框架的作用不是让你记住更多概念，而是让你在开会时能快速定位问题类型。

1. 流程效率的可分解公式

我习惯用一个简单的分解式来和业务负责人沟通：

流程总周期 = 节点处理时间 + 依赖等待时间 + 审批决策时间 + 返工修复时间

这个公式的价值在于：它把"流程效率"从一个模糊概念变成了四项可分别测量的时间。节点处理时间是执行层的问题，后三项是管理层的问题。而大多数企业的管理注意力，恰恰都压在第一项上。

流程总周期拆解示例（某硬件企业项目均值，单位：天）
总周期 = 42.0

节点处理时间 = 18.5 （44%，执行效率）

依赖等待时间 = 11.2 （27%，顺序/资源/接口依赖）

审批决策时间 = 7.6 （18%，授权与响应）

返工修复时间 = 4.7 （11%，信息不一致）

说明：数据为项目实测样本，用于说明管理注意力的分配错位

如果你只优化节点处理时间，最多能压缩 18.5 天里的几个百分点。但如果你把依赖等待从 11.2 天压到 6 天，效果立竿见影。这就是为什么管理层任务依赖效率是关键指标，而不仅仅是执行层的 KPI。

2. 判断依赖是否"失控"的三个信号

在没有数据的初期，可以用三个信号做快速判断：

1. 同一个任务被反复标记"进行中"超过两个统计周期。这通常不是任务本身难，而是它在等某个外部输入。
2. 跨部门交接没有验收清单，退回靠口头沟通。这说明交接标准缺失，返工率一定偏高。
3. 审批超过 3 天没人追问，也没有升级动作。这说明审批 SLA 和升级路径都不存在。

三个信号里命中两个以上，基本可以确定依赖管理是失控的。

3. 管理层任务依赖的两种理解，不要混淆

"管理层任务依赖"有两种读法，容易混。第一种是"管理层之间的任务依赖"，即高管之间、高管与部门负责人之间的审批和决策依赖。第二种是"管理层需要关注的任务依赖"，即管理层作为管理者去盯下属团队之间的依赖。

我的判断是：这两个都要管，但节奏不同。前者属于决策响应效率，用审批周期和授权分级解决；后者属于流程运行效率，用泳道图、接口人和 SLA 解决。混在一起谈，就会变成既没优化决策效率，也没管好执行依赖。

五、关键指标清单：9 类指标的定义、公式与数据源

这一节是全文最"硬"的部分。每个指标我都会给出定义、计算公式、数据来源和预警线思路。请注意，所有阈值都是建议基准，你需要用自己的基线校准。

1. 依赖等待时长（主指标）

定义：后置任务具备启动条件的时间点，减去前置任务实际完成的时间点。它衡量的是"本可以不等待却等待了多久"。

公式：依赖等待时长 = 后置任务可开始时间 − 前置任务实际完成时间

数据源：任务系统中前置任务的完成时间戳、后置任务的启动时间戳。前提是任务之间的依赖关系在系统里被显式登记，而不是靠口头约定。

预警线思路：先跑一个月的基线，取中位数作为参考，把超过基线 1.5 倍的依赖关系标记为异常。连续两周异常，进入周度阻塞会讨论。

2. 审批周期与决策响应时间

定义：从审批请求提交到最终决策（通过/驳回/退回补充）的时间间隔。

公式：审批周期 = 决策时间点 − 审批提交时间点

数据源：审批系统或 OA 流程日志。关键是区分"等待审批人查看"和"审批人已查看但在等待补充材料"。

预警线思路：按审批金额或风险等级分层。低风险审批超过 1 个工作日、中风险超过 2 个工作日、高风险超过 5 个工作日，触发提醒；再超一倍触发升级。

3. 一次通过率与返工率

定义：一次通过率是指提交后无需退回修改直接通过的任务占比；返工率是相反口径。

公式：返工率 = 返工任务数 ÷ 总交付任务数 × 100%

数据源：任务系统的退回记录、评审记录。注意要把"补充说明后通过"和"实质性返工"区分开，否则返工率会被低估或高估。

预警线思路：返工率本身没有绝对好坏，关键是看趋势和归因。如果返工集中在某几个接口，说明是标准问题，不是态度问题。

4. 跨部门交接准时率

定义：在约定时间内完成交接，且交接物符合验收清单的比例。

公式：交接准时率 = 按时且合格交接次数 ÷ 应交接总次数 × 100%

数据源：交接清单签署记录、验收结论。

预警线思路：这个指标低于 80% 时，说明交接标准或接口人机制有问题，应该立即复盘，而不是等季度总结。

5. 阻塞任务数与逾期依赖数

定义：阻塞任务数是指当前因依赖未满足而停滞的任务数量；逾期依赖数是指超过约定等待上限仍未满足的依赖关系数量。

公式：阻塞任务数 = 当前状态为"等待依赖"的任务总数

数据源：任务系统的状态字段和依赖字段。

预警线思路：阻塞任务数是一个"绝对值 + 趋势"指标。绝对值高说明问题多，趋势上升说明治理动作没生效。

6. 流程遵从率

定义：按规范流程执行的任务数占总任务数的比例，包括是否在规定系统中登记、是否走规定审批、是否提交规定输入物。

公式：流程遵从率 = 合规执行任务数 ÷ 总任务数 × 100%

数据源：系统日志与流程规范的比对。

预警线思路：遵从率长期偏低，往往不是员工偷懒，而是流程本身设计过重。先怀疑流程，再怀疑人。

7. 线上化与自动化率

定义：无需人工干预即可流转的环节占比，以及流程数据在系统中自动采集的占比。

公式：自动化率 = 自动化流转环节数 ÷ 总环节数 × 100%

数据源：流程系统配置与运行日志。

预警线思路：依赖等待时长和审批周期都严重超标的环节，优先自动化。

8. 协同满意度或内部 NPS

定义：上下游协作方对交接质量、响应速度、沟通体验的主观评价。

数据源：季度匿名调研，建议用 0-10 分打分制，并追问原因。

预警线思路：主观指标不用于考核，用于发现问题。当主观评分和客观数据出现背离时，往往藏着未被记录的隐性返工。

9. 依赖关系覆盖率（治理类指标）

定义：已在系统中显式登记依赖关系的任务占比。这是元指标，衡量你是否有能力测量其他指标。

公式：依赖覆盖率 = 已登记依赖关系的任务数 ÷ 应登记依赖关系的任务数 × 100%

数据源：任务系统的依赖字段完整度检查。

预警线思路：这个指标不达标，其他依赖指标都不可信。建议第一阶段优先把覆盖率做到 90% 以上。

六、落地案例与数据观察：用真实项目验证指标有效性

指标如果不能落地，就是一堆名词。这一节讲一个我参与过的落地过程，并说明工具在其中承担什么角色。

1. 案例背景与试点选择

这是一家中型制造企业，员工规模约 600 人，产品从立项到量产平均周期 5 个月。痛点是"流程文件齐全，但项目老是拖"。我们没有全公司铺开，而是选了一个试点：新产品导入（NPI）流程。选择理由是它跨部门多（研发、工艺、采购、生产、质量），依赖密集，且周期短，两个月内就能看到数据。

2. 第一步：把依赖关系显式登记

试点开始前，团队的所有依赖关系都靠邮件和口头确认。我们先做了一件事：把 NPI 流程的关键依赖关系梳理出来，并在任务系统里显式登记。这一步是全部工作的地基，没有依赖关系登记，依赖等待时长根本算不出来。

在这个环节，我们使用了 PingCode 来承载流程和任务依赖关系。PingCode 主要服务中大型企业及 100 人以上组织，对这类跨部门流程场景比较适配。它的任务依赖可以配置前后置关系，依赖未满足时后置任务会显式处于等待状态，这就让"等待"从隐性变成了显性、可统计。此外，PingCode 支持私有化部署，对流程数据有合规要求的企业更友好；同时支持从 Jira 平滑迁移，对于原来使用 Jira 的团队，历史流程数据可以延续，不必推倒重来。

3. 第二步：建立基线并设定目标

我们跑了四周的数据，得到试点前的基线。下面是试点前四周和试点后八周的关键指标对比。所有数据为该项目实测样本，用于说明指标变化方向，不代表行业水平。

需要说明的是，这些变化不是单一工具带来的，而是"指标定义 + 依赖登记 + SLA + 升级机制 + 周度阻塞会"这一整套动作的结果。工具的作用是让数据可采集、可追溯，机制的作用是让数据进入管理动作。

4. 第三步：周度阻塞会怎么开

这是我认为最值得复制的动作。周度阻塞会只讨论一件事：当前被阻塞的任务，以及阻塞它的依赖关系。会议控制在 45 分钟内，流程固定：

1. 看板展示本周阻塞任务数和逾期依赖数，对比上周趋势。
2. 逐个过阻塞超过 3 天的依赖关系，确认责任人和预计解除时间。
3. 需要管理层拍板的，当场决策或指定授权人，记录决策时间。
4. 复盘上周承诺的解除时间是否兑现，未兑现的说明原因。

这个会议不讨论"流程重不重要"，只讨论"哪一个依赖卡住了、谁负责、什么时候解除"。把流程管理从理念讨论变成堵点清除，是提效的关键转折。

5. 数据观察：哪些动作的边际收益最高

从试点数据里，我总结出三个边际收益最高的动作，按性价比排序：

• 登记依赖关系：投入小，但它决定了你能否测量。覆盖率从 32% 到 94%，是所有其他改善的前提。
• 定义交接验收清单：投入中等，直接作用于跨部门交接准时率和返工率，这两个指标改善幅度最明显。
• 设置审批 SLA 和分级授权：需要管理层参与，但审批周期改善直接进入项目总周期，收益最直接。

而投入产出比最低的动作，是"重新画一遍流程图"。它看起来工作量很大，但对依赖等待几乎没有影响。

七、不同情况下的行动建议

企业规模、流程成熟度、系统基础不同，起点动作也应该不同。下面按四种典型情况给出建议。

1. 情况一：流程文件齐全，但没人按流程走

这种情况的根因通常不是员工不配合，而是流程设计过重、节点过多、审批层级过深。

建议动作：先做流程遵从率统计，找出被绕开最多的三个环节。对这三个环节做减法，能合并的合并，能授权的授权，能自动化的自动化。先让流程变轻，再谈遵从。

2. 情况二：跨部门项目延期严重，但找不到具体原因

这是最典型的情况，也是本文的核心适用场景。

建议动作：选一个跨部门流程做试点，先做依赖关系登记，把覆盖率达到 90% 以上，然后跑一个月基线，算出依赖等待时长和阻塞任务数。数据出来之后，原因自然浮现。不要在没有数据的时候开协调会，那只会变成互相指责。

3. 情况三：已有项目管理工具，但只用来记任务

很多企业的项目管理系统停留在"任务清单"阶段，依赖字段空着，状态字段靠人工维护。

建议动作：先激活依赖关系配置能力。以 PingCode 为例，可以把前后置任务依赖显式配置，让后置任务在依赖未满足时处于等待状态，这样依赖等待时长就有了数据基础。如果原来用 Jira，PingCode 支持平滑迁移，历史数据可以延续。同时，私有化部署选项对有数据合规要求的中大型企业更合适。工具的价值不在于功能多少，而在于它能否把隐性等待变成可统计的数据。

4. 情况四：管理层想直接看结果，不想看过程指标

这种情况很常见。管理层关心的是周期、成本、交付。

建议动作：给他们一页驾驶舱，把过程指标和结果指标绑定呈现。例如：依赖等待时长上升 → 项目总周期上升 → 交付延期风险上升。让管理层看到过程指标是结果指标的先行信号。一旦他们发现依赖等待时长能提前两周预警延期，就会主动盯这个指标。

八、给管理层的一页驾驶舱：三层结构与阈值机制

指标要发挥作用，必须进入一个固定的查看结构。我建议按三层组织，每层关注不同的问题。

1. 战略层：看周期与风险

这一层只放三个数字：流程总周期、延期项目占比、依赖等待时长占比。作用是在月度经营会上回答"整体流程健康度如何"。

依赖等待时长占比这个指标特别值得关注。它的计算方式是：依赖等待时间 ÷ 流程总周期。当这个比例超过 25% 时，说明流程的主要矛盾在依赖管理，而不是执行效率。

2. 流程层：看阻塞、返工、SLA

这一层放：阻塞任务数、逾期依赖数、返工率、审批 SLA 达成率、跨部门交接准时率。作用是在周度运营会上定位需要干预的流程环节。

3. 节点层：看审批、交接、异常

这一层放具体到节点和人：待办审批时长分布、交接退回明细、异常任务清单。作用是在日常管理中快速处理具体堵点。

4. 红黄绿阈值与周度阻塞会

三层指标都要有阈值。我建议的初始设置方式是：以基线为基准，设定绿色（基线以内）、黄色（基线 1 到 1.5 倍）、红色（基线 1.5 倍以上）。

红灯触发三个动作：立即通知责任人、进入本周阻塞会议程、要求给出解除时间承诺。这三个动作要写进流程规范，而不是靠临时协调。

九、30/60/90 天落地路径

落地节奏很重要。一次性全公司铺开的流程变革，失败率极高。下面的路径是我在多个项目中验证过的节奏。

1. 第一个 30 天：定义与试点准备

1. 选一个跨部门、周期适中的试点流程，不要选最复杂的主流程。
2. 梳理该流程的关键依赖关系，在任务系统中完成显式登记，目标覆盖率达到 90%。
3. 为每个关键指标定义公式、数据源、统计周期和责任人。
4. 跑基线数据，至少两周，确定中位数或平均值。

这个阶段的目标不是改善，而是让数据能够被采到、被信任。

2. 第 31 到 60 天：机制上线

1. 上线流程驾驶舱，按三层结构组织，设置红黄绿阈值。
2. 建立关键节点的 SLA 和升级路径，明确超时后谁来处理。
3. 建立周度阻塞会，固定议程和时间盒。
4. 对审批环节做分级授权，低风险审批下放。

这个阶段的核心是让数据进入会议和责任机制，否则看板很快会被遗忘。

3. 第 61 到 90 天：复盘与推广

1. 对比试点前后指标，确认改善是否真实发生。
2. 识别瓶颈环节，针对性优化或自动化。
3. 把验证有效的动作写成流程规范，纳入制度。
4. 选择第二个流程做推广，复用同一套指标和机制。

推广时要注意：不同流程的依赖类型不同，指标阈值必须重新校准，不能直接套用。

十、常见误区与规避动作

最后集中回应几个高频误区，每条附一个替代动作。

1. 误区：只画流程图，不量等待时长

替代动作：在流程文件的每个关键节点后补充三个字段，输入物、完成标准、等待上限。等待上限就是 SLA 的雏形。

2. 误区：指标太多，没有主指标

替代动作：每季度只设一个主指标和两个辅助指标。第一个季度强烈建议以依赖等待时长为主指标。

3. 误区：把依赖冲突当成部门墙，靠开会解决

替代动作：在跨部门交接点设置接口人和交接验收清单。清单要能判断合格与否，不能是笼统的"完成即可"。

4. 误区：指标没有数据源和责任人

替代动作：每个指标必须写清三件事：数据从哪个系统取、多久更新一次、谁对指标负责。三者缺一，指标就不可持续。

5. 误区：用行业基准替代企业自身基线

替代动作：先跑自己的基线，再设定目标。行业数据只作为参考，不作为考核依据。

6. 误区：看板做了，但没人看

替代动作：把看板绑定到固定会议。战略层月度看，流程层周度看，节点层日常看。看板进入议程才有人看。

7. 误区：追求一次到位，全公司同时推行

替代动作：先试点、后推广。试点验证的是方法有效性，推广复用的是方法，不是阈值。

十一、总结与下一步行动

回到最初那个问题：流程规范做得很完整，为什么项目还是慢？因为流程规范管的是节点，而项目周期的大头在节点之间的依赖缝隙里。你不把依赖关系显式登记、不把等待时长量化、不把 SLA 和升级机制建立起来，流程图就只能证明"我们设计过流程"，证明不了"流程在高效运行"。

本文的独特判断可以归纳成一句话：SF流程与规范的核心不是画得更细，而是把任务依赖从隐性变成显性、从显性变成可测量、从可测量变成可管理。依赖等待时长应该成为管理层盯流程效率的第一主指标，阻塞任务数应该成为每周必看的先行信号，依赖关系覆盖率应该成为流程治理的元指标。

接下来建议你按这个顺序行动：

1. 今天先做一件事：挑一个跨部门流程，列出它的关键依赖关系，看有多少已经在系统里显式登记。这个数字就是你的依赖关系覆盖率基线。
2. 本周内为依赖等待时长、阻塞任务数、审批周期三个指标写好公式和数据源，指定责任人。
3. 两周后跑出第一份基线报告，据此设定红黄绿阈值。
4. 第三周建立周度阻塞会，把红灯依赖纳入固定议程。

工具层面，如果现有系统只能记任务、记不了依赖，建议优先评估支持显式依赖配置、支持私有化部署、且能承接既有历史数据的项目管理平台。以 PingCode 为例，它对中大型企业及 100 人以上组织的跨部门流程场景比较适配，支持 Jira 平滑迁移，国产替代场景下迁移成本相对可控。但请记住：工具解决的是"能不能测量"，机制解决的才是"测量之后能不能改善"。两者缺一，流程规范都落不了地。