例如，在a、c、f、g、m等步骤中，Bot-A的操作过程和操作行为几乎和人一模一样。员工A打开什么界面，Bot-A就打开什么界面；员工A怎么录入信息，Bot-A就怎么录入信息；员工A点击“提交”按钮，Bot-A就点击“提交”按钮。整个处理过程从后端系统看，是没有办法分辨员工A和Bot-A的区别的。另外Bot-A的整个模拟过程，对于用户是可见的，即用户可以看到Bot犹如魔法一般快速操作各类应用软件的整个过程。
这不单只是追求炫目的视觉效果，其实是在更深层面让用户对计算机产生了某种信任感，拉近了IT和用户的心理距离。由于传统应用软件的运行情况对于用户来讲就是个黑盒子，再加上用户缺乏对软件编程的足够了解，经常会出现用户不知道后端系统在做什么的情况，一旦出现系统响应延迟、不断报错等问题，用户就会抱怨。如果一个IT系统能够让最终用户眼见为实，会给这项技术加分不少，这也是为什么更多的计算机仿真和模拟程序不断出现的原因。
例如Bot-A在d、e、f等步骤的处理中，需要依据事先已经预设好的规则来执行，比如预设邮件筛选的规则，包括选取什么时间段、由哪个邮箱地址后缀发出来、邮件标题中含某字段标识或是某种更加特殊的标志。筛选规则可以是简单的，利用脚本程序直接实现；也可以是复杂的，利用规则引擎来实现。如果是人工查找一封邮件，会先按照发件人或者时间排序，然后用目光进行搜索，找到那个熟悉的关键字后，再仔细看邮件的标题是否符合要求。
如果我们靠机器人和规则来实现，那么就不能再简单地模仿人的行为，而是需要让计算机明白那些业务规则。所以说，RPA模拟的只是人的行为，而不是人的思维，只会执行人类预先设计好的逻辑规则，而不会自己去思考如何工作。而人类的思维需要靠人工智能来“模仿”，这部分内容在3.4节详细描述。
如例子中从a到o的所有步骤，RPA会按照确定的顺序来执行，且不会随意调整，这也与人类的行为习惯存在很大差别。虽然目前一些企业中已经有明确员工行为的规程或操作手册，但是由于无法做到细致的监督和管控，所以在真正的业务运行环境中，员工还是可以随意调整操作步骤的，因为人们通常觉得只要自己最后交付的成果是有效的就可以，过程并没有那么重要。但是很多生产问题恰恰是与操作顺序有关的。
例如办理“个人定期存款到期转存”业务时，银行柜员应该按照“先借后贷”的顺序，先办理个人定期存款到期销户业务，再办理新开户。如果柜员颠倒操作过程，一旦出现客户遗忘密码等不能正常取款的情况，就会产生银行垫款等风险隐患。所以，利用RPA来固化员工的业务操作顺序，也是一个重要的考虑因素。
另外，因为RPA的操作过程中不会出现任何人类常犯的一些错误，如敲错键盘、选错位置、点错按钮等，所以当同一逻辑、同一规则的RPA脚本执行完以后，处理结果都是相同的。如果对比上述例子中人工和自动化两个处理过程，就会发现在RPA的处理环节中少了i和j步骤，而这两个步骤就是我们通常所说的业务复核。业务复核是业务流程中最为常见的一种做法，其实就是希望复核人员能够再一次检查录入人员的录入结果，避免不必要的错误发生。甚至在一些特别重要的信息输入环节，很多企业还采取了“两录一校”的处理方式，即双人录入、一人校验的方式。但是我们可以发现，由于RPA执行带来的一定是确定性结果，并不需要再用一个机器人来加以校验，也就避免了复核环节。这项能力对于业务的效率提升以及人力成本的节省都是非常明显的。
企业的管理者一直都希望能够了解和获取真实的业务运营情况，包括人员服务效率、事务周转率、各项作业时间等，基于此来衡量企业内部的作业成本、服务效率等。目前在数字化转型的趋势下，大多数企业主要通过信息系统中的数据分析来获取这些信息，但其中存在两个制约因素。
第一，由于运营流程中通常会涉及多个系统，流程中相关的运营数据也就散落在各个系统中，而且由于数据标准和质量的问题，很难将这些数据完整地串接和拼装成运营流程的全貌。
第二，即使拿到了系统中的数据，仍不能获取业务人员办理业务时真正的耗时情况，因为信息系统只能记录业务人员提交业务信息，即点击“提交”按钮那一时刻的时间，而并不清楚业务人员是从什么时候开始办理这项业务的，以及在各个环节中的耗时情况。
RPA替代人工完成了相应的操作，所以在自动化处理过程中也顺便留下了所有的操作痕迹，即操作日志。通过这些日志信息，管理者可以了解某项业务是什么时间开始、结束或者中断的，中间过程都与哪些信息系统或桌面软件做了交互，操作了几个软件，每段操作的耗时如何，并可以反向推导出业务人员的劳动效率、不同人员之间的协作效率、流程是否遇到瓶颈等问题，同时也为企业的内控合规人员和内外部审计人员提供了数据支持。
原文：https://www.cnblogs.com/nikki-RPA/p/13616509.html