怎么自动筛选SAS里去年至今的超期维修单？规则搭建与自动推送

在SAS中自动筛选去年至今的超期维修单，关键不是先导出报表，而是先把受理日期、承诺完成日期、当前状态、责任人四个字段口径统一，再用去年1月1日至今天作为时间窗，筛出未完工且已超过承诺日期的工单，并补上定时执行、消息推送和审计留痕，这样才不会每次都靠人工重复核对。

一、先把去年至今和超期这两个口径定死

很多团队筛不准，不是SAS不会写，而是业务口径一直在变。真正要先定清楚的是时间范围、超期定义、状态排除、统计粒度四件事。

1. 时间范围怎么取

• 自然年口径：去年1月1日至今天，适合经营分析、审计和年度复盘。
• 滚动口径：今天往前推365天，适合过程监控和SLA跟踪。
• 建议：如果搜索意图是去年至今，默认优先采用自然年口径，避免与滚动365天混算。

2. 超期怎么判定

• 优先使用承诺完成日期。承诺完成日期早于今天，且工单状态不属于已完工、已关闭、已作废，即可判定为超期。
• 没有承诺完成日期时，可用受理日期加SLA时限推导应完成日期，但这类工单要单独打标，避免与标准工单混算。
• 挂起待料、客户待确认这类状态是否算超期，要由业务规则先写清楚，否则同一张单可能被不同部门算出不同结果。

3. 最容易漏掉的字段

字段	作用	常见问题
受理日期	限定去年至今的统计范围	日期时间混算导致边界错位
承诺完成日期	判断是否超期	空值未处理，导致超期漏判
当前状态	排除已结束工单	状态字典不统一，出现重复统计
责任人	决定通知和催办对象	当前责任人与首次责任人混用

如果口径前后不一致，同一批数据今天查出120单、明天查出97单，问题通常不在SAS，而在字段解释不统一。

二、SAS里可直接落地的筛选逻辑

若数据已经在SAS库中，最稳妥的做法是先标准化日期字段，再执行筛选，最后输出责任维度汇总表。先把结果查准，再谈自动化。

示例逻辑

%let start_dt=%sysfunc(intnx(year,%sysfunc(today()),-1,b)); %let end_dt=%sysfunc(today()); proc sql; create table work.overdue_repair as select order_id, apply_date, promise_finish_date, status, owner, today()-datepart(promise_finish_date) as overdue_days from saslib.repair_order where datepart(apply_date) between &start_dt and &end_dt and status not in ('已完工','已关闭','已作废') and not missing(promise_finish_date) and datepart(promise_finish_date) < &end_dt; quit;

这段逻辑解决的是基础筛选，但业务上通常还要补三层规则。

1. 空值补偿：没有承诺完成日期时，是否使用SLA推导日期。
2. 状态修正：挂起待料、待客户确认、返工重开等状态是否纳入超期。
3. 责任归属：输出当前责任人、班组、区域、供应商等多维字段，便于后续派发。

建议输出字段

• 工单编号、设备编号、故障类别
• 受理日期、承诺完成日期、超期天数
• 当前状态、责任人、所属班组
• 是否高优先级、是否重复返修

Gartner预计，到2028年33%的企业软件将内置Agentic AI能力，而2024年这一比例不足1%。这意味着企业只会查表已经不够，更需要能判断、能执行、能回写的自动化链路。

三、真正耗时的不是筛选，而是通知、复核和留痕

人工处理这类任务通常卡在三步：查数、发人、追责。一次筛选只要几分钟，但每天人工复核和跨部门通知会持续占用时间。

环节	人工做法	自动化做法
取数	手动导表	定时任务自动跑批
判定	人工筛选状态和日期	规则引擎统一判定
通知	逐人发群消息或邮件	按责任人自动分发
留痕	聊天记录零散	日志、附件、回写记录统一沉淀

如果要把这件事做成长期运营，最少要补齐下面四个动作。

• 定时执行：每天固定时点自动跑批，避免人工忘查。
• 异常推送：按责任人、车间、区域或供应商分组发送。
• 结果回写：把超期标记、超期天数回写到工单系统或台账。
• 审计留痕：保存筛选规则版本、执行日志和推送记录。

McKinsey在2023年的研究指出，生成式AI每年有望带来2.6万亿至4.4万亿美元经济价值。对维修场景而言，这种价值往往不是来自写一段查询，而是来自把发现异常到通知处理的链路真正闭环。

四、适合维修工单场景的自动化方案怎么搭

如果企业不只想一次性导出名单，而是希望形成长期运行的异常监控机制，可以把SAS筛选与实在Agent结合：前者负责结构化数据筛选，后者负责跨系统执行、消息推送、附件生成、审计追踪和异常回写。

可落地的技术路径

1. 通过数据库连接、API或界面自动化读取SAS或相关工单系统数据。
2. 把受理日期、承诺完成日期、状态、责任人等字段映射为统一模型。
3. 按规则引擎执行去年至今筛选、超期计算、状态排除和优先级分层。
4. 自动生成超期清单，按责任人或组织维度推送消息，并沉淀执行日志。
5. 必要时将日志生成PDF附件，随相关单据或任务同步，便于审计追溯。

为什么这类方案比单点脚本更稳

• 长链路闭环：不止找出超期单，还能继续推送、催办、回写。
• 权限隔离：支持按业务、共享、管理等角色进行精细化权限管理，减少越权查看。
• 个性化规则说明：不同维修类型可配置不同审核说明、处理指引和提示信息。
• 本土系统适配：对中文字段、国产软硬件和私有化部署更友好。

在某类共享服务审核场景下，该方案已经实现自动将日志生成PDF附件并随单据同步，满足审计追溯要求；同时支持按业务、共享、管理角色划分权限，并可按业务类型配置规则说明和流程指引。虽然这不是直接面向维修单的案例，但迁移到超期维修单监控时，正好对应留痕、分权、规则说明三类核心需求。

数据及案例来源于实在智能内部客户案例库

五、上线前先检查这5个细节

1. 去年至今到底是自然年起算，还是滚动365天。
2. 超期起点是承诺完成日期、计划完成日期，还是SLA时限。
3. 状态排除是否已去掉已完工、已关闭、已作废和挂起待料。
4. 时间字段是否统一到日期层，而不是日期时间混算。
5. 责任归属采用当前责任人还是首次分派责任人，避免推送错人。

只要这5个点统一，SAS筛选很快就能稳定下来；如果再叠加自动推送与留痕，超期维修单管理才会真正从报表动作升级为运营动作。

❓常见问题

Q1：去年至今一定要从去年1月1日开始吗？

A：如果是经营复盘、审计统计，通常用自然年，即去年1月1日至今天；如果是过程监控，也有不少企业采用滚动365天。关键不是哪种更对，而是口径必须统一。

Q2：没有承诺完成日期，还能筛超期单吗？

A：可以。可用受理日期加SLA时限得到应完成日期，再判断是否超期。但这类口径要单独标记，避免与有承诺完成日期的工单混算。

Q3：只有SAS报表，没有接口，能做自动化吗？

A：能。可以通过数据库直连、报表订阅或界面自动化方式取数，再执行筛选、推送和日志留痕。接口不是唯一前提，关键在于字段可识别、规则可固化、结果可追踪。

参考资料：2024年Gartner Top Strategic Technology Trends for 2025: Agentic AI；2023年McKinsey The economic potential of generative AI: The next productivity frontier。