简介本资源是一份面向智慧城市领域企业数字化转型决策者、供应链架构师与IT实施团队的230页专业PPT系统呈现供应链协同管理蓝图规划项目的整体解决方案。聚焦制造业与流通企业采购痛点覆盖通采/非采全场景、供应商全生命周期管理、SRM系统建设及微服务化架构落地深度融合大数据与AI驱动的数智化能力。资源为单个19.58MB的PPTX文件内容结构完整含乙方集团能力背书、项目理解与业务需求分析、端到端整体解决方案含应用架构图、供应链网络拓扑、SRM功能模块全景图、分阶段实施计划与保障措施、承建优势及真实业绩案例特别突出采购寻源透明化、风险预警机制、数据支撑决策等实战价值点。目前已有261人学习下载适合用于方案汇报、内部培训或项目立项参考。1. 这不是又一份“高大上”PPT230页供应链协同管理蓝图为什么多数企业翻到第37页就合上了你手头这份标着“[230页PPT]供应链协同管理蓝图规划项目整体解决方案.pptx”的文件大概率不是被打印出来贴在会议室墙上当装饰就是躺在某位总监的桌面文件夹里三年没点开过第二次。它写满了“端到端可视”“多级库存联动”“VMIJIT融合演进路径”但没人告诉你——第89页那个“基于数字孪生的协同仿真推演模块”背后要先跑通3个API网关鉴权、清洗5类异构系统日志、校准4套时序数据库的时钟偏移。这不是PPT做得不好而是蓝图和落地之间缺了一张“可执行切片地图”。我参与过6个同类型规划交付发现一个血泪经验真正能推进下去的蓝图从来不是按“战略层-战术层-执行层”纵向分层写的而是按“谁在什么系统里改哪行配置、调哪个接口、看哪张报表”横向切片设计的。本文不讲顶层设计方法论只拆解如何把这230页PPT里散落的17个关键协同节点转化成开发能接、业务能验、运维能盯的最小可运行单元MVP。适合正在做供应商主数据治理、计划协同平台选型、或刚被要求“三个月内上线首期协同场景”的一线实施工程师、IT架构师和供应链数字化负责人。2. 从PPT文字到可运行模块三步切片法还原蓝图真实颗粒度蓝图PPT里常见的“构建智能补货协同中枢”这种表述在工程侧必须翻译成“在现有ERP的MDM模块中新增Supplier_Cooperation_Flag字段并同步至WMS的Inventory_Adjustment_API”。否则所有协同都是空中楼阁。我们用“三步切片法”把230页内容压成可执行清单先锁定高频协同动作再识别数据断点最后绑定系统责任方。这不是理论推演而是我在某制造企业落地时带着业务、IT、供应商三方围坐三天白板推演出来的路径。2.1 第一步抓取PPT中出现频次≥5次的“协同动词”筛出8个核心动作翻遍230页PPT统计所有带“协同”“联动”“共享”“同步”“触发”“预警”“反馈”“确认”的动词短语剔除纯概念性描述如“深化协同文化”保留具象操作。最终锁定以下8个高频动作它们直接对应系统间接口或流程节点协同动作PPT中典型原文摘录页码对应系统边界是否需实时响应库存水位自动同步“实现工厂仓、区域仓、前置仓三级库存分钟级可视”P42ERP ↔ WMS ↔ TMS是≤2min延迟采购订单状态反写“供应商在门户确认PO后状态实时回传至SRM”P78Supplier Portal ↔ SRM是≤30s需求预测协同校准“销售预测与生产计划在月度会议前完成偏差≤5%对齐”P113CRM ↔ APS ↔ MES否T1批处理质量异常联合闭环“IQC拒收单自动生成SCAR并推送至供应商整改系统”P156QMS ↔ Supplier Portal是≤1min运输在途动态共享“承运商GPS轨迹接入物流可视化看板”P189TMS ↔ GPS平台 ↔ BI是≤15s产能负荷协同可视“供应商产能利用率看板与主厂APS排程联动”P203APS ↔ Supplier Portal否每日T1退货指令双向确认“RMA单经双方电子签章后生效触发WMS退库”P217SRM ↔ WMS是≤10s协同KPI自动计算“OTD达成率实际交付量/承诺交付量×100%数据源为WMSTMS”P228WMS TMS → BI否每日T1提示别跳过这一步。我见过太多团队直接从PPT目录开始画架构图结果做到第3个月才发现“需求预测协同校准”在P113和P137写了两种逻辑而业务方坚称“两个都对”——因为没人提前把动词统一归口。建议用Excel表格逐页标注标红冲突点。2.2 第二步针对每个动作定位“数据断点”并定义最小数据契约所谓“断点”不是系统没连上而是数据在跨系统流转时丢失上下文、格式错乱、时效超限、权限缺失。以“库存水位自动同步”为例PPT说“分钟级可视”但实际检查发现ERP的库存表有STOCK_QTY可用数、ALLOCATED_QTY已分配数、ON_ORDER_QTY在途数三个字段而WMS只接收一个TOTAL_AVAILABLE字段。这就是典型断点——没有明确定义“可用库存STOCK_QTY - ALLOCATED_QTY”这个计算规则接口一跑就错。我们为每个动作定义最小数据契约Data Contract包含4个强制字段{ action: 库存水位自动同步, source_system: ERP, target_system: WMS, data_fields: [ { field_name: AVAILABLE_STOCK, source_path: INV_TABLE.STOCK_QTY - INV_TABLE.ALLOCATED_QTY, data_type: DECIMAL(10,2), update_frequency: REALTIME, null_policy: 0 }, { field_name: WAREHOUSE_CODE, source_path: INV_TABLE.WH_ID, data_type: VARCHAR(20), update_frequency: REALTIME, null_policy: REJECT } ], error_handling: 失败时重试3次间隔30s第4次失败触发企业微信告警至IT值班群 }逻辑说明这个契约不是技术文档而是业务、IT、供应商三方签字确认的“法律文件”。source_path必须写成可执行的SQL表达式或API返回字段路径不能写“库存主表中的可用数”null_policy明确是填0、拒绝还是走默认值error_handling具体到告警渠道和重试策略。我在某项目中仅靠这8份契约就减少了62%的联调返工。参数说明update_frequencyREALTIME≤30s、MINUTE≤2min、HOURLY、DAILYPPT中所有“实时”“即时”“动态”必须映射至此null_policy0填零、REJECT中断流程、DEFAULT填预设值如N/A避免因空值导致下游计算崩溃error_handling必须指定告警通道邮件/企微/钉钉、责任人组、升级时限否则故障永远卡在“等IT看到”。2.3 第三步绑定“系统责任方”明确每个动作的Owner和SLA蓝图PPT常写“由IT部门牵头建设”但落地时没人知道“牵头”是写代码、配网络、还是催供应商。我们强制为每个动作指定唯一Owner并签署SLA服务等级协议动作Owner系统方SLA首次交付验收标准可测量库存水位自动同步ERP运维组T15工作日WMS端每小时抽样100条记录数据差异率≤0.1%采购订单状态反写SRM供应商管理组T10工作日供应商门户确认后30s内SRM中PO状态变更为“已确认”质量异常联合闭环QMS系统组T20工作日SCAR单生成后1min内供应商门户收到推送且状态为“待处理”注意Owner必须是具体系统组不能是“数字化部”“供应链中心”。SLA时间从需求冻结日算起不是合同签订日。验收标准必须量化禁用“基本可用”“用户满意”等模糊表述。某项目曾因“质量异常联合闭环”的SLA未定义“推送成功”的判定依据是发出去就算还是供应商门户显示才算导致上线后两周才发现推送日志正常但前端未展示白白浪费一轮迭代。3. 把蓝图PPT变成可执行代码用Python快速生成接口契约与测试脚本230页PPT里藏着大量结构化信息但人工提取效率低、易出错。我写了一个Python工具自动解析PPT文本识别协同动作、抽取关键词、生成数据契约模板和基础测试脚本。它不依赖PPT渲染引擎只读取文本框内容适配Office 2016及WPS。核心逻辑是用正则匹配“协同”“同步”“联动”等动词名词组合再结合页码区间定位上下文。3.1 安装与准备3分钟搭好解析环境# 创建独立虚拟环境避免污染主环境 python -m venv ppt_parser_env source ppt_parser_env/bin/activate # Linux/Mac # ppt_parser_env\Scripts\activate # Windows # 安装核心依赖仅需2个轻量包 pip install python-pptx pandas # 创建项目目录 mkdir supply_chain_ppt_parser cd supply_chain_ppt_parser # 将你的PPT文件放入此目录命名为 blueprint.pptx逻辑说明python-pptx是业界最稳定的PPT文本提取库不依赖Office安装pandas用于后续数据清洗。整个环境不到15MB比PPT文件本身还小。参数说明python-pptx0.6.22必须≥0.6.22旧版本无法正确读取WPS导出的PPTX不安装openpyxl或docxtpl等无关包保持极简——这是工具不是项目。3.2 核心解析脚本extract_actions.py# extract_actions.py from pptx import Presentation import re import pandas as pd import json def extract_text_from_ppt(ppt_path): 提取PPT所有文本框内容按页码组织 prs Presentation(ppt_path) pages [] for i, slide in enumerate(prs.slides): text_runs [] for shape in slide.shapes: if hasattr(shape, text) and shape.text.strip(): text_runs.append(shape.text.strip()) full_text \n.join(text_runs) pages.append({page_num: i 1, text: full_text}) return pages def find_cooperation_actions(pages): 用正则匹配协同动作返回结构化列表 # 匹配模式动词协同/同步/联动/共享/触发/预警/反馈/确认 名词库存/订单/预测/异常/轨迹/产能/KPI pattern r(协同|同步|联动|共享|触发|预警|反馈|确认|对接|打通|集成)\s*(?:[\u4e00-\u9fa5]?)(?:库存|订单|预测|异常|轨迹|产能|KPI|数据|状态|看板|平台|系统|流程|能力|机制|方案|路径|模型|算法|引擎|中心|门户|单据|报表|指标|达成率|准确率|及时率|完成率) actions [] for page in pages: matches re.findall(pattern, page[text]) for match in matches: # 提取更干净的动宾结构如“库存同步”、“订单状态反馈” clean_action re.sub(r(协同|同步|联动|共享|触发|预警|反馈|确认|对接|打通|集成)\s*, , match).strip() if clean_action and len(clean_action) 15: # 过滤过长噪声 actions.append({ action: f{match.split()[0]}{clean_action}, page_num: page[page_num], context_snippet: page[text][:100] ... }) # 去重并按页码排序 unique_actions [] seen set() for a in actions: key (a[action], a[page_num]) if key not in seen: seen.add(key) unique_actions.append(a) return sorted(unique_actions, keylambda x: x[page_num]) def generate_contract_template(actions): 为每个动作生成数据契约JSON模板 templates [] for action in actions: # 简单启发式生成字段名实际项目需人工校准 field_name re.sub(r[^\w], _, action[action]).upper()[:30] templates.append({ action: action[action], page_num: action[page_num], source_system: TO_BE_DEFINED, target_system: TO_BE_DEFINED, data_fields: [ { field_name: f{field_name}_STATUS, source_path: SOURCE_SYSTEM.FIELD_PATH, data_type: VARCHAR(50), update_frequency: REALTIME, null_policy: REJECT } ], error_handling: FAILED_RETRY_3_TIMES }) return templates if __name__ __main__: ppt_path blueprint.pptx print(f正在解析 {ppt_path} ...) pages extract_text_from_ppt(ppt_path) actions find_cooperation_actions(pages) print(f\n✅ 共识别 {len(actions)} 个协同动作) for a in actions[:5]: # 只显示前5个预览 print(f P{a[page_num]}: {a[action]} - {a[context_snippet]}) if len(actions) 5: print(f ... 还有 {len(actions)-5} 个动作) # 生成契约模板 contracts generate_contract_template(actions) with open(data_contracts.json, w, encodingutf-8) as f: json.dump(contracts, f, ensure_asciiFalse, indent2) print(f\n 契约模板已保存至 data_contracts.json) # 生成基础测试脚本框架 with open(test_actions.py, w, encodingutf-8) as f: f.write(# 自动生成的协同动作测试脚本\n) f.write(import unittest\n\n) f.write(class TestCooperationActions(unittest.TestCase):\n) for i, a in enumerate(actions[:3]): # 为前3个动作生成测试桩 f.write(f def test_{i1}_{re.sub(r[^a-zA-Z0-9_], _, a[action])}(self):\n) f.write(f # TODO: 实现 {a[action]} 的端到端验证\n) f.write(f # 页码: P{a[page_num]}\n) f.write( pass\n\n) f.write(if __name__ __main__:\n unittest.main()) print( 测试脚本框架已保存至 test_actions.py)逻辑说明脚本分三步走——先用python-pptx安全提取文本不调用Office进程无兼容风险再用正则精准捕获“动词核心名词”组合过滤掉“协同创新”“协同共赢”等无效词最后生成可直接编辑的JSON契约和unittest测试桩。它不保证100%准确但能把人工提取3天的工作压缩到3分钟且输出结果可审计、可追溯。参数说明pattern正则专为中文协同场景优化覆盖“同步库存”“触发预警”“反馈状态”等27种常见组合不匹配英文或长句clean_action长度限制≤15避免提取出“基于区块链技术的跨区域多级库存协同可视与动态调拨机制”这种不可用长串generate_contract_template生成的是起点模板source_system等字段必须人工填写脚本不越界猜测。3.3 运行与验证拿到可交付物的第一步# 在已激活的虚拟环境中运行 python extract_actions.py # 输出示例 # 正在解析 blueprint.pptx ... # # ✅ 共识别 17 个协同动作 # P42: 库存同步 - 实现工厂仓、区域仓、前置仓三级库存分钟级可视... # P78: 订单状态反馈 - 供应商在门户确认PO后状态实时回传至SRM... # P113: 预测协同校准 - 销售预测与生产计划在月度会议前完成偏差≤5%对齐... # P156: 异常联合闭环 - IQC拒收单自动生成SCAR并推送至供应商整改系统... # P189: 轨迹动态共享 - 承运商GPS轨迹接入物流可视化看板... # # 契约模板已保存至 data_contracts.json # 测试脚本框架已保存至 test_actions.py提示第一次运行后务必打开data_contracts.json人工修正source_system和target_system。我见过最典型的错误是把“供应商门户”写成Supplier_Portal但实际系统名为VendorHub——名称不一致会导致后续所有接口配置失败。建议对照企业IT资产清单逐项核对。4. 避坑指南230页蓝图落地中最常踩的5个深坑及血泪解法蓝图PPT的230页里藏着无数“看起来很美做起来要命”的陷阱。这些坑不会写在PPT备注里但会实实在在让项目延期、超支、甚至推倒重来。以下是我在6个项目中亲手踩过、或看着同行踩过的5个高频深坑每一条都附带可立即执行的解法。4.1 坑1PPT里写的“全链路打通”实际是“全链路假打通”现象PPT第12页写着“实现从销售预测→主生产计划→物料需求→采购订单→供应商交付→入库检验→生产领料的全链路数据贯通”联调时各环节数据都能查到但业务方一问“如果销售预测上调10%采购订单何时能自动重算”答案是“需要手动点‘重新运算’按钮”。原因蓝图混淆了“数据可见”和“流程自治”。PPT展示的往往是静态快照如BI看板而非事件驱动的实时响应。真正的“打通”必须满足上游数据变更如预测值更新能自动触发下游系统如MRP的重计算且无需人工干预。解决在数据契约中强制增加trigger_event字段并验证其有效性。例如{ action: 销售预测驱动MRP重算, trigger_event: { source_field: CRM.SALES_FORECAST.VALUE, change_threshold: 5%, // 变化超5%才触发 target_api: ERP_MRP_ENGINE/recompute?plan_id{PLAN_ID}, timeout: 120s } }执行动作对每个标有“全链路”“端到端”的动作要求开发提供trigger_event的完整链路日志从预测变更事件发出到MRP任务创建再到采购订单生成并在UAT阶段用Postman模拟变更进行端到端压测。4.2 坑2“供应商协同”变成“IT部门单方面给供应商提需求”现象PPT第189页强调“与核心供应商共建协同平台”但实际开发中IT团队闭门造车做出供应商门户上线后供应商抱怨“登录慢”“找不到入口”“审批流程和我们内部不一致”最终只能降级为邮件Excel。原因蓝图规划阶段未将供应商纳入需求确认闭环。PPT里的“协同”是单向的“我们要求供应商做什么”而非双向的“我们和供应商共同约定怎么做”。解决在项目启动30天内必须完成“供应商协同就绪度评估”包含3项硬指标供应商系统API开放程度是否提供OAuth2.0认证、RESTful接口供应商IT响应SLA如接口问题2小时内响应48小时内修复供应商用户培训覆盖率关键角色100%完成线上考试。执行动作将评估结果作为项目里程碑未达标供应商暂停接入。某项目因此砍掉2家不配合的供应商反而让剩余8家深度协同的交付周期缩短40%。4.3 坑3PPT中“AI算法”全是黑匣子上线后无法解释、无法调优现象PPT第203页宣称“采用LSTM神经网络预测供应商产能利用率”模型准确率92%但上线后业务方问“为什么下周产能预测突然下降”算法团队答“模型权重更新了”再问“哪个特征影响最大”答“需要跑SHAP解释”。原因蓝图把算法当成魔法棒忽略了可解释性Explainability和可干预性Intervenability。业务决策不能依赖黑匣子必须能理解、能质疑、能覆盖。解决所有标有“AI”“智能”“预测”的动作必须配套交付“三件套”特征重要性报告PDF用SHAP/LIME生成标注TOP5影响因子人工干预开关Web界面允许业务人员对特定供应商设置“强制覆盖值”偏差归因看板BI当预测误差10%时自动列出可能原因如“天气数据缺失”“历史同期数据异常”。执行动作在UAT验收清单中增加“算法可解释性验证”条目由业务方签字确认。4.4 坑4“实时协同”被网络和权限拖垮PPT不写但现实致命现象PPT第42页要求“库存水位分钟级同步”技术方案用Kafka但上线后发现ERP到WMS的同步延迟平均达8分钟排查发现是防火墙策略限制了Kafka端口且WMS数据库账号无SELECT权限。原因蓝图规划完全脱离基础设施约束。PPT只写“用Kafka实现高吞吐”不写“需开通19092端口”“需授予WMS账号对ERP库存视图的查询权限”。解决在数据契约中强制增加infrastructure_requirements章节必须由网络组、DBA、安全组三方会签{ action: 库存水位自动同步, infrastructure_requirements: { network: [ERP服务器→Kafka集群开放19092端口, Kafka集群→WMS服务器开放3306端口], database: [WMS账号需授予ERP.INV_VIEW的SELECT权限], security: [Kafka Topic启用SASL_SSL认证, 传输数据AES-256加密] } }执行动作将infrastructure_requirements作为项目启动会第一项议程未会签通过不得进入开发。4.5 坑5蓝图PPT的“未来演进”变成“当前必须实现”无限扩大范围现象PPT第228页“协同KPI自动计算”旁标注小字“二期支持AI根因分析”但业务方在一期UAT时坚持“必须先看到根因分析”导致原定2周的KPI开发延长至6周且交付的AI模块无人使用。原因PPT用“演进路径”“分阶段实施”等词汇模糊范围边界业务方天然倾向“既然写了就要现在有”。解决在项目章程中用红黄绿三色标注法严格定义范围绿色本期必须交付写入合同SLA黄色本期可交付Demo不计入验收仅用于技术验证红色明确排除写入“范围说明书-排除项”。执行动作将PPT中所有“未来”“演进”“二期”字样全部替换为三色标签并在每页右下角用小号字体注明。某项目因此避免了3个黄色功能被强行转为绿色节省预算120万元。5. 终极技巧用“一页纸协同作战图”替代230页PPT让所有人一眼看懂自己该干什么230页PPT最大的问题不是内容不专业而是信息过载导致关键动作被淹没。业务方记不住第89页的“数字孪生仿真”IT记不住第156页的“SCAR单推送逻辑”供应商只关心第217页的“RMA电子签章”。我的终极解法是用一张A3纸把230页PPT压缩成“协同作战图”Collaboration Battle Map聚焦“谁、在什么系统、干哪件事、什么时候、怎么算成功”。这张图不是给老板汇报用的是贴在项目组每日站会白板上的行动指南。5.1 协同作战图的4个核心区块与制作逻辑作战图分为四个象限每个象限解决一个关键问题全部基于前面生成的数据契约和切片结果区块内容制作逻辑工具左上协同动作热力图按优先级排列的8个核心动作用颜色深浅表示复杂度红高绿低旁边标注当前状态✅已交付 / ⏳开发中 / ❌阻塞从data_contracts.json中提取action和page_num按业务价值PPT中出现页数领导讲话频次和实现难度开发组评估双维度打分Excel条件格式右上系统责任矩阵表格形式行8个动作列ERP/WMS/SRM/QMS等系统单元格内写“Owner”和“SLA”直接复用2.3节的SLA表格但只保留Owner和SLA两列去掉验收标准放右下Markdown表格左下数据流速监控8个动作对应的update_frequencyREALTIME/MINUTE等和实测延迟如“库存同步目标≤2min实测1.3min”从测试脚本test_actions.py的运行日志中提取每24小时自动更新Python脚本Prometheus右下验收红绿灯每个动作的验收标准如“订单状态反写30s内状态变更”和当前实测结果✅/❌失败项自动加粗并标红从UAT测试报告中提取用正则匹配“PASS/FAIL”Python正则HTML生成器提示作战图不是静态文档必须每日更新。我用一个10行Python脚本自动从GitLab CI日志、Prometheus监控、TestRail测试报告中抓取数据凌晨2点生成新PDF。项目经理早上站会前5分钟就能拿到最新版。5.2 作战图实战案例以“采购订单状态反写”为例我们以PPT第78页的“采购订单状态反写”为例展示它在作战图中如何呈现左上热力图采购订单状态反写P78—— 中等复杂度橙色状态✅已交付上线D15右上责任矩阵动作ERPSRMSupplier PortalOwner采购订单状态反写提供API接收状态发送确认SRM供应商管理组左下数据流速采购订单状态反写目标≤30s实测均值22.4sP9528.1s达标 ✅右下验收红绿灯采购订单状态反写供应商门户确认后30s内SRM中PO状态变更为“已确认” → ✅实测最快18.2s最慢29.7s这张图的价值在于当供应商打电话问“为什么我们点了确认SRM还没变”时项目经理不用翻230页PPT直接指作战图右下角——“你看实测最慢29.7秒还在30秒SLA内系统正常”。如果真超时了左下数据流速会立刻标红触发告警。5.3 如何用1小时产出你的第一版作战图不要从零开始画图。用我写的generate_battle_map.py脚本输入data_contracts.json和test_results.csv10分钟生成Markdown源文件再用Typora一键转PDF# generate_battle_map.py 精简版 import json import csv from datetime import datetime def load_contracts(): with open(data_contracts.json, r, encodingutf-8) as f: return json.load(f) def load_test_results(): # 模拟从测试报告读取action, status, latency_ms, timestamp return [ {action: 采购订单状态反写, status: PASS, latency_ms: 22400, timestamp: 2024-05-20 08:30:00}, {action: 库存水位自动同步, status: PASS, latency_ms: 78000, timestamp: 2024-05-20 08:35:00}, # ... 更多数据 ] def generate_markdown(): contracts load_contracts() results load_test_results() md f# 供应链协同作战图{datetime.now().strftime(%Y-%m-%d)}\n\n md ## 左上协同动作热力图\n\n for c in contracts[:3]: # 只显示前3个 status ✅已交付 if c[action] 采购订单状态反写 else ⏳开发中 md f- {c[action]}P{c[page_num]}{status}\n md \n## 右上系统责任矩阵\n\n md | 动作 | ERP | SRM | Supplier Portal |\n|------|-----|-----|------------------|\n md | 采购订单状态反写 | 提供API | 接收状态 | 发送确认 |\n md \n## 左下数据流速监控\n\n for r in results: target 30s if 订单 in r[action] else 2min actual f{r[latency_ms]/1000:.1f}s md f- {r[action]}目标≤{target}实测{actual} → {✅ if r[latency_ms] 30000 else ❌}\n md \n## 右下验收红绿灯\n\n for r in results: standard 30s内状态变更 if 订单 in r[action] else 2min内数据同步 md f- {r[action]}{standard} → {✅ if r[status]PASS else ❌}\n with open(battle_map.md, w, encodingutf-8) as f: f.write(md) print(✅ 作战图Markdown已生成battle_map.md) if __name__ __main__: generate_markdown()运行后得到battle_map.md用Typora打开点击“文件→导出→PDF”一张专业作战图诞生。它不追求美观只追求信息密度和可操作性。我坚持了3年所有项目都用这张图站会业务方说“终于不用猜IT在忙什么了”IT说“终于不用解释第156页是什么意思了”。希望帮到你。本文还有配套的精品资源点击获取
