简介SAP CS 客户服务模块概览课件面向客户服务顾问、PM 与 SD 顾问及希望系统认识 CS 功能的 SAP 学习者用于快速梳理模块定位、主数据、服务周期与跨模块集成关系。课件以单份 PPT 呈现压缩包仅含 1 个文件大小约 487KB便于轻量查阅与课前预习。内容覆盖技术对象设备、功能位置、序列号物品与车队对象、服务通知与订单处理、通过销售周期向客户计费、保修管理、已安装基础、服务规划、测量点与测量文档并给出 PM/CS 与 SD 的组织结构、企业结构示例同时说明 CS 与 FI/CO、SD、MM、PS 等模块的集成以及工厂维护流程、销售流程和客户服务流程。已有 103 人学习适合需要建立 SAP CS 知识框架、理解服务场景与流程衔接的初、中级顾问作为入门概览材料。1. 先搞懂 SAP CS它到底在管什么“服务”一台空调卖出去故事才刚开始客户打电话说制冷不行了客服在系统里翻出三年前那台机器的档案派单给片区师傅师傅上门换了一块主板走的时候客户签字过几天账单寄到费用里零件、人工、保修抵扣分得清清楚楚。这一连串动作在 SAP CS客户服务模块里各自有明确的位置。通俗地说SAP CS 是把“已经卖给客户的设备”当作主角围绕它管理报修、派工、备件、工时、保修和收费的一整套流程骨架。它不负责把设备卖出去而负责设备卖出去之后的每一件事。值得搞懂的原因很实在卖设备是一次性的服务是持续的。一台设备用十年中间可能报修五次、保养八次、换件若干回每一次都牵扯到谁去修、用什么件、收多少钱、还算不算保修。这些事如果没有一套统一记录就只能靠人的记忆和散落的表格撑着人一走账就乱。搞懂 CS 的结构等于搞懂了“服务这门生意是怎么被记录下来的”。2. 为什么服务要单独建一个模块三条流程的对比设备卖出去之后公司面对的问题跟卖之前完全不是一回事。卖之前关心报价、合同、发货、收款卖之后关心这台机器现在在谁手里、坏没坏、谁去修、修的时候换没换件、这笔钱算保修还是算收入。前者是一条以“成交”为终点的短链路后者是一条以“设备生命周期”为长度的长链路。CS 模块就是为这条长链路准备的容器。2.1 工厂维护、销售、客户服务三条流程像在哪、差在哪先看三条流程各自从头到尾走一遍。工厂维护流程的起点是一张维护通知记录某台机器需要维护接着创建维护订单订单进入计划环节把人、料、外协服务排进去然后执行维护执行完做维护订单确认把消耗的资源记下来最后订单和通知一起完成维护订单结算成本在财务模块里过账。这条线的终点是“内部成本落在了哪里”。销售流程的起点是客户询价然后报价、形成销售订单、交货拣配、包装、发货、收入确认、给客户开票。这条线的终点是“货出去了、钱进来了”。客户服务流程的起点是一张服务通知记录客户投诉然后创建服务订单并做计划执行服务做服务订单确认订单和通知完成后通过销售周期给客户开票再完成收入确认。这条线的终点是“服务干完了、账也结了”。三条线放在一起骨架几乎是同一个记录需求、排计划、执行、确认、结算。所以第一次接触的人经常会觉得 CS 和 PM工厂维护差不多或者觉得 CS 就是 SD销售加了点售后字段。差别藏在细节里对比项工厂维护销售客户服务起点维护通知客户询价服务通知主角自家设备物料客户手里的设备计划载体维护订单销售订单服务订单执行内容维修、保养拣配、发货上门服务、换件结算去向内部成本收入与开票开票与收入确认是否判断收费不判断按订单收要判断保修与收费真正的分水岭是最后一列CS 必须回答“这单收不收钱”。同样一次上门保修期内是成本保修期外是收入这个判断在 PM 和 SD 里都不存在只有在 CS 里才成为一个必须处理的动作。这也是为什么服务不能简单挂在销售下面也不能简单挂在维护下面它需要自己的一层结构。2.2 两套组织结构为什么要在 CS 里会合服务这件事天然同时属于两个世界而这两个世界用的是两套完全不同的组织语言。一套按“东西在哪里、谁来修”组织。公司代码下面分工厂工厂是技术对象安装、实际维护执行的地方工厂下面再分功能位置、计划员组、工作中心设备挂在功能位置下任务清单挂在工厂下。这套结构的核心问题是“活儿在哪儿干、谁干”。另一套按“卖给谁、走什么渠道、开什么票”组织。公司代码下面分销售组织销售组织下面再分分销渠道和部门三者组合成销售区域。这套结构的核心问题是“钱从哪个口子进来”。CS 的有趣之处在于它是这两套结构唯一的交汇点。同一台设备维修视角里它挂在某个维护工厂的某个功能位置下归某个计划员组管收费视角里它又属于某个销售组织下的某个分销渠道和部门。修的人在工厂视角里收钱的人在销售视角里两边说的是同一台机器但用的不是同一套坐标。打个比方这就像一家物业公司工程部按楼栋、单元、房号派师傅财务部按业主姓名、合同号、缴费渠道开票。两个部门必须能对上同一套房否则师傅修完了财务不知道找谁收钱。CS 里的技术对象和销售区域就是那套“对得上”的机制。这也是初学者容易翻车的地方只盯着功能位置建得漂不漂亮忘了销售区域没配好结果服务订单做完了开不出票。组织结构不是背景板它是流程能不能走通的前提。2.3 CS 的五大组件和它绕不开的四个邻居把 CS 拆开看主要由四块拼成。第一块是技术对象包括设备、功能位置、序列号物品和车队对象。它们回答“服务的是什么东西、在哪儿”。第二块是服务通知与服务订单处理。通知负责记录问题订单负责计划、执行和结算两者一前一后接力。第三块是通过销售周期向客户计费。服务干完之后账单不是凭空开的它要走销售订单、交货、开票这条既有链路。第四块是保修、已安装基础、服务规划、测量点和测量文档。保修决定收不收钱已安装基础回答“客户现场到底装了哪些设备”服务规划把重复性的保养变成任务清单和维护计划测量点则持续记录设备运行数据。这四块没有一块能孤立存在。师傅上门换的那块主板库存从物料管理来账单从销售模块出成本记到财务与控制模块如果是一次成规模的大修还可能挂到项目系统下按项目走。CS 像一张桌子四条腿分别搭在物料、销售、财务和项目上哪条腿短了桌子就晃。理解这一点后面看技术对象和通知订单的细节时才不会把它们当成孤立的表单而会知道每张表单背后都连着一笔库存、一笔成本或一张发票。3. 技术对象的身份体系系统怎么“认出”一台设备服务现场最常见的一句话是“就是那台机器坏了”。在人嘴里“那台”靠手指和记忆就能定位在系统里不行系统必须把“那台”拆成一组可以查询、可以挂接、可以计费的身份信息。技术对象就是这套身份体系。3.1 功能位置设备装在哪里的“门牌号”功能位置是维护工厂内部的一个组织单元按功能、流程或空间标准来划分代表某项维护任务要执行的地点。它描述的是一块位置一项功能而不是具体某台机器。打个比方功能位置是门牌号设备是住在这个门牌号里的人。人搬走了门牌号还在同一个门牌号可以先后住进不同的人。换成设备语言某车间 101 号工位的配电柜位置是一个功能位置今天装的是 A 型号配电柜五年后换成 B 型号功能位置不变挂上去的设备变了。这个区分在服务里非常实用。客户报修时说“三号厂房二楼东侧那台空压机”你首先定位到的是功能位置然后才在功能位置下找到当前装的那台设备。如果只按设备找设备一换历史记录就断了如果只按功能位置找又说不清是哪一台具体机器出的问题。两者配合才能既保留位置的历史又锁定具体的对象。功能位置主数据就是客户这些位置的档案挂在维护工厂下记录该位置上装过什么、发生过什么。它是服务历史的“地基层”。3.2 设备与子设备一台整机拆成能单独维修的部件设备的定义是被当作一个独立单元来维护的单个物理对象。注意“独立单元”四个字它意味着这台机器可以单独报修、单独计算保修、单独挂一笔服务成本。但一台整机往往还能往下拆。材料里的例子很典型设备 PC7560 下面挂着子设备 CPU 和 Monitor。为什么要拆到这一层因为维修时你可能只换 CPU不换整台机器保修也可能按部件算主板保三年、外壳保一年。如果不建子设备所有这些细粒度信息就只能写在备注里查不了、统计不了、也没法自动带进通知。设备主数据则是所有卖给不同客户的设备的总档案。它记录的不只是型号还包括这台设备挂在哪个功能位置、属于哪个客户、保修起止时间、序列号是多少。服务通知里的参考对象页签、保修页签很多字段就是从设备主数据自动带出来的不用人手敲。把一台设备的身份信息摊开大致是这么一层结构# 一台设备在 CS 里的身份卡字段名是示意不是系统里的真实表名 equipment { maintenance_plant: 1000, # 维护工厂谁负责修 functional_location: XXXX-1000-101-PC, # 功能位置装在哪 equipment_no: PC7560, # 设备号这是哪一台 sub_equipment: [CPU, MONITOR], # 子设备能单独拆修的部分 serial_no: SN-0001, # 序列号同型号之间靠它区分 warranty: {start: 2023-04-01, end: 2026-03-31}, # 保修期 }这段结构里维护工厂决定这活儿归哪个厂管功能位置决定它装在哪设备号决定是哪一台子设备决定坏了能不能只换一部分序列号决定同型号之间怎么区分保修期决定这次收不收费。字段不多但每一个都对应服务流程里的一个判断点。少一个流程走到某一步就得停下来人工确认。3.3 序列号与车队对象同型号怎么分清这一台同一款设备卖了一万台型号、物料编码完全一样系统怎么知道客户报修的是哪一台靠序列号。材料里的说法是当需要交易销售同类型设备时使用序列化技术为与设备关联的物料编码创建序列号它本质上是同类设备的识别码。通俗地说序列号就是设备的身份证号型号是“人类”序列号是“具体某个人”。这件事在服务里不是可选项。没有序列号保修期就没法按台计算维修历史也没法按台累积你只能知道“这个型号最近坏得多”却不知道“这一台已经修过三次了”。而后者往往才是判断该修还是该换的依据。车队对象是技术对象里的另一类用于管理成批的、可移动的资产。它和设备的区别在于管理视角设备更强调单台的身份与历史车队对象更强调一组资产的整体状态。两者不是替代关系而是同一批资产在不同粒度上的两种看法。测量点和测量文档则是给技术对象加上“读数”的能力。设备运行时的温度、压力、振动、累计运行小时都可以挂在测量点上持续记录形成测量文档。这些读数本身不产生工单但它们是服务规划的依据读数异常可以触发通知读数趋势可以调整保养周期。技术对象负责“是谁”测量点负责“现在怎么样”两者合起来才是一台设备在系统里的完整画像。4. 从一句抱怨到一张账单通知与订单怎么接力客户在电话里说的是“你们这机器又坏了”这句话进系统之后要变成一串结构化记录再变成一张能结算的订单最后变成一张发票。中间这段路是 CS 最核心的流程。4.1 服务通知把口头描述变成五个页签的结构化记录服务通知描述的是客户现场某个技术对象出现的问题状态。它的作用不是修东西而是把“问题”本身固定下来什么时候开始的、发生在哪台设备上、什么部位、什么现象、可能是什么原因、客户报了什么诉求。创建一张通知大致要走这么几步选通知类型填描述。参考对象页签挂设备或功能位置。这两个字段通常从设备主数据或功能位置主数据里带出来不用手填。同一页签里还有收货方和客户地址从客户主数据带出。项目页签填项目代码、损坏代码、原因代码。任务页签填通用任务代码。活动页签填通用活动代码。保修页签显示客户保修信息从设备主数据复制过来。故障详情页签填故障开始日期和时间。如果打开了故障标识系统会计算故障小时数也就是故障开始到结束之间的总时长。这套页签设计经常被初学者嫌麻烦觉得一张报修单为什么要填这么多。但每一个页签都在回答一个后面会用到的问号。项目、损坏、原因三个代码分开是因为“哪个部位坏了”“坏成什么样”“为什么坏”是三件不同的事混在一起就没法统计任务和活动分开是因为“要做什么”和“实际做了什么”经常不一致保修页签自动带出是为了让开单的人当场就知道这单收不收费而不是等账单寄出去才发现还在保修期。所有信息填完之后发布通知通知进入处理状态任务完成后关闭通知。发布和关闭这两个动作看着轻其实是流程的分界线发布之前是记录问题发布之后才能往订单转关闭之前可以追加关闭之后就是历史。4.2 S1、S2、S3通知类型不是随便选的系统里预置了几种标准通知类型每种对应一种不同的业务场景。S1 是问题通知用来记录设备出了故障。这是最常用的一种客户报修、巡检发现异常都走它。S2 是活动报告记录的是“我去干了什么”重点在活动本身不一定对应一个故障。比如按计划做了一次保养、做了一次现场培训用 S2 记录过程比用 S1 更贴切。S3 是服务请求记录的是客户提出的一个需求还没确认是不是故障。它更像一个待确认的入口客户说“最近声音有点大你们来看看”这时候事实还没查清先用服务请求接住确认之后再转成问题通知或直接安排订单。三者的区别可以用一句话概括S1 记“坏了”S2 记“干了”S3 记“要看”。选错类型不会立刻报错但后面统计故障率、保养次数、响应时效的时候数据就会对不上。这类错在初期特别常见属于典型的踩坑点单子能开、流程能走等到季度复盘才发现一半保养被记成了故障。4.3 服务订单什么时候必须开单SM01/SM02/SM03 怎么选服务订单是任务详细计划及其伴随文档的载体。材料里有一句关键判断当有成本发生比如需要备件或需要人力时就开服务订单。也就是说通知负责“记录问题”订单负责“花钱干活”。订单可以从通知直接生成也可以单独创建。生成之后订单里要排人、排料、排工时执行完做确认最后结算。订单类型是订单的分类特征里面带着管理这张订单所需的控制信息。标准系统里常见的三种是订单类型含义典型场景SM01有收入的服务订单保修期外向客户收费SM02无收入的服务订单保修期内或内部服务SM03维修订单以修复为主要目的通常涉及返修选型的判断逻辑其实不复杂难的是每次都认真判断# 什么情况下开哪种服务订单判断逻辑示意不是系统配置 def pick_order_type(has_revenue: bool, is_repair: bool) - str: if is_repair: return SM03 # 维修订单以修复为主要目的 if has_revenue: return SM01 # 有收入要向客户收费 return SM02 # 无收入保修期内或内部服务三个参数分别对应三个问题这次是不是返修这次收不收费这次是不是以修复为主。三个问题里最容易含糊的是“收不收费”因为它取决于保修页签带出来的日期而不是现场师傅的判断。所以正确的顺序是先看设备主数据里的保修期再决定订单类型而不是先开单再补判断。这一步做反了后果不是单据错而是收入确认错。保修期内的单子开成 SM01月底收入虚增保修期外的单子开成 SM02该收的钱没进账。这类错误往往要到财务对账才暴露属于典型的“后悔药没处买”。4.4 服务规划与任务清单把重复劳动模板化服务里有一大类工作是完全重复的每季度保养一次、每半年校准一次、每年更换一次易损件。这类工作如果每次都从零开始排人排料效率低不说还容易漏项。任务清单就是为这件事准备的。它是一组操作针对特定应用挂有物料组件并定义了工作中心、控制码、所需人工小时等信息。通俗地说任务清单是一张“标准作业套餐”做一次保养要做哪几步、每步用哪些备件、在哪个工作中心做、大概几个工时全都写在里面。服务主数据则把“服务”本身变成一种可以销售或采购的物料。材料里说得很清楚服务在系统里被定义成物料标准物料类型是 DIEN服务产品是带任务清单的服务物料。这意味着服务既能像商品一样进销售订单又能像作业一样展开成具体操作。把任务清单、维护项目和维护计划组合起来就是服务规划哪些设备、多久做一次、每次做哪些操作、用哪些备件、提前多久备料。已安装基础回答“客户现场有哪些设备”服务规划回答“这些设备接下来要做什么”。两者合起来预防性服务才跑得起来而不是等客户打电话才被动响应。5. 易混概念辨析五组长得像、用起来完全不同的词CS 里有一批词单看定义都懂放到一起就分不清。下面五组是最容易混的。5.1 维护工厂与计划工厂易混点两个都叫工厂都跟维护有关还经常出现在同一张单子上。为什么混名字只差两个字功能描述里又都出现“维护订单”“维护通知”这些词初读时很容易当成同义词。怎么区分维护工厂回答“东西在哪、活儿在哪干”技术对象安装在它下面实际维护也在它那里执行。计划工厂回答“计划在哪做、物料在哪备”任务清单在它下面定义物料计划按任务清单里的 BOM 来做维护计划在它那里管理和排程。一个计划工厂可以替好几个维护工厂做计划反过来则不成立。判断方法很简单问一句“这张单子的活儿在哪儿干”答案指向维护工厂问“这套保养方案在哪儿定义”答案指向计划工厂。5.2 功能位置与设备易混点两者都挂在维护工厂下都能出现在服务通知的参考对象里界面上还经常并排显示。为什么混它们描述的是同一现场里的两样东西而且经常一起出现看多了就以为是可以互换的字段。怎么区分功能位置是位置设备是物体。功能位置代表维护任务执行的地点设备是被当作独立单元维护的单个物理对象。一个功能位置可以先后装多台设备一台设备也可以换位置。判断方法问“这个东西会不会被搬走”会搬走的是设备不会搬走的是功能位置问“换了一台新机器这个编号还留着吗”留着的是功能位置换掉的是设备。5.3 物料主数据、服务主数据与服务产品易混点三者都是主数据都能进销售订单名字里都带“服务”或“物料”。为什么混服务在系统里本身就是一种物料所以“服务主数据”和“物料主数据”在结构上有大量重叠看字段看不出区别。怎么区分物料主数据是所有物料组件的总档案管的是“这个东西是什么、库存怎么管”。服务主数据是把服务本身定义成可销售或可采购的物料标准物料类型是 DIEN管的是“这项服务能不能卖”。服务产品则是带任务清单的服务物料管的是“这项服务具体包含哪些操作”。三者是层层收窄的关系物料是大类服务是其中一类服务产品是服务里带作业清单的那一种。判断方法问“这东西有没有库存”有库存走物料没库存走服务问“这项服务要不要展开成操作步骤”要展开就是服务产品。5.4 服务通知与服务订单易混点两者都来自客户报修都挂在设备上编号还经常前后脚出现。为什么混业务上它们确实是一前一后接力很多人把“开单”笼统地理解为“开通知”或“开订单”口语里不区分。怎么区分通知记录问题订单花钱干活。通知可以没有订单比如远程判断后不需要上门通知记录完就可以关订单通常从通知生成但它管的是计划、备件、工时和结算。判断方法问“这张单子要不要消耗备件或人力”要消耗就得有订单问“这张单子只是留个记录吗”只是记录就是通知。5.5 内部维护与客户服务易混点两者共用技术对象、功能位置、任务清单等大量结构界面长得几乎一样连菜单都常放在一起。为什么混它们共享同一套主数据和同一套作业逻辑差别不在界面而在业务终点。怎么区分内部维护维护的是自家资产活儿干完成本落到内部成本中心流程就结束了。客户服务维护的是客户资产活儿干完还要通过销售周期向客户开票、确认收入流程才结束。判断方法问“这单最后要不要给外面的人开票”要开票就是客户服务不开票就是内部维护。这也是为什么 CS 必须同时懂工厂视角和销售视角而纯做内部维护的人往往只熟悉前一半。6. 什么时候该用这套骨架边界与一个具体取舍前面把结构拆得比较细最后落到一个实际问题什么样的业务值得把这套骨架搭起来什么样的业务搭了反而累。先说要用的情形。如果卖出去的是需要持续服务的设备客户分散、设备数量多服务过程涉及备件、人工、保修判断和收费那就值得用。因为这四个条件同时成立时手工记录一定会出问题设备一多保修期就记不住订单一多备件库存就对不上收费一多收入确认就会拖。CS 的价值不是把表单电子化而是把“设备身份、问题记录、作业计划、成本与收入”这四件事绑在同一条链上让任何一张单子都能往前追到设备、往后追到钱。再说别硬套的情形。只卖耗材、没有售后服务的不需要。服务完全外包、公司不打算管过程的也不需要因为这套结构的核心是“自己记录过程”过程不在自己手里结构就是空壳。一次性项目型交付、交付完就结束的同样不需要项目系统比 CS 更合适。团队规模很小、设备数量在几十台以内的用表格反而更轻硬上系统会把简单事情复杂化。中间地带最考验判断。举个虚构的例子某设备制造商卖出去几千台设备售后由各地经销商代做公司只负责发备件和结算费用。这种业务表面上像客户服务但公司并不直接管上门过程真正需要的是备件管理和经销商结算CS 里最重的通知与订单流程反而用不上。硬套的结果是经销商不愿意填单数据全是补录的最后系统里的记录比 Excel 还不可信。一个更常见的取舍发生在“通知要不要细到代码”这件事上。项目代码、损坏代码、原因代码填得越细后面统计越有用但现场师傅如果嫌麻烦就会统一选一个“其他”数据看起来完整实际全是噪声。我的做法是先只强制两三个最关键的代码等现场用顺了再逐步加细而不是一上来就要求全填。这类事没有标准答案只有“现场愿不愿意填”这个现实约束。我自己的教训来自很早的一次配置当时为了图省事把一批设备的保修期统一填成了同一个日期想着反正以后可以改。结果半年后一批保修期外的单子被当成保修内处理收入少确认了一大截财务对账时才发现。从那以后我每次建完设备主数据都会强制走一遍“保修期逐台核对”的检查哪怕看起来麻烦。这个习惯帮我省掉过好几次返工。这套结构的价值不在于它多完整而在于它让每一个服务动作都有据可查。搞懂它比记住它更重要。希望帮到你。本文还有配套的精品资源点击获取