Защо реалната стойност на RPA е в автоматизацията на end-to-end бизнес процеса – между SAP, други системи и експертното решение.
В големите организации SAP често е гръбнакът на ключови бизнес процеси – финанси, снабдяване, материално планиране, склад, производство, продажби и управление на основни данни. Но реалният бизнес процес рядко живее само в SAP. Около ERP системата има BI решения, Excel файлове, специализирани приложения, клиентски и доставчически портали, документи, e-mail и множество други „сателитни“ системи. Много често именно хората се превръщат в интеграционния слой между тях. Те извличат информация от една система, проверяват я в друга, обработват я в Excel, вземат решение и след това отразяват резултата обратно в SAP.
| Ключовият въпрос не е „Коя SAP транзакция можем да автоматизираме?“, а „Как изглежда целият бизнес процес и къде в него човекът извършва работа, която системите могат да поемат?“ |
SAP е част от по-голяма екосистема. RPA може да свързва ERP с BI, Excel, документи, e-mail, портали и специализирани приложения.
Material Planning: когато планът се променя всеки ден
Добър пример е материалното планиране в Lufthansa Technik. При ремонтната дейност материалната необходимост не е статична. На дневна база се появяват промени по вече планирани ремонти, нови заявки за ремонт, промени в необходимите материали, количества и срокове, нова информация за наличности, както и промени в поръчките и заявките за доставка.
Planner-ът трябва непрекъснато да реагира на тази динамика. Информацията идва от SAP и други източници, трябва да бъде консолидирана и анализирана, след което специалистът определя какви промени са необходими по съответните поръчки. В реализирания процес автоматизацията събира и обобщава информацията от SAP и BI, а след като експертът определи необходимите промени, роботът актуализира съответните заявки в SAP.
Това е съществена разлика. RPA не замества MRP процеса в SAP, а го подпомага и допълва. Не замества и човека, който планира поръчките. То променя начина, по който се изпълнява процесът: променени бизнес условия → автоматично събиране и обработка на информация → експертно решение → автоматично изпълнение в SAP.
Така специалистът прекарва времето си в анализ и решение, а не в техническо обработване на десетки или стотици промени.
Не всичко трябва да бъде реализирано в SAP
Друг важен принцип е, че автоматизацията не означава непременно целият процес да бъде пренесен или разработен в SAP. Напротив. В много случаи най-добрата архитектура е да използваме само онази част от SAP процеса, която вече работи добре, а специализираната оперативна функционалност да бъде реализирана извън ERP системата.
Добър пример е процес за управление на работно облекло и лични предпазни средства в голяма индустриална компания. Процесът по закупуване започва в SAP. И това е логично – там вече съществуват procurement процесът, доставчиците, поръчките, финансовата логика и одобренията.
Веднага след доставката започва съвсем различен жизнен цикъл на работното облекло и личните предпазни средства (ЛПС). Всяко работно облекло може да има RFID таг; проследява се кое облекло е предоставено на конкретен служител; управляват се брак и подмяна; проследява се прането; контролира се наличното оборудване; а при влизане в производствен цех може да се проверява дали служителят разполага с необходимата окомплектовка.
Няма архитектурна причина цялата тази специфична функционалност да бъде изградена вътре в SAP. По-разумният модел е: SAP Purchase Process → специализирана система → оперативен жизнен цикъл → необходимата информация обратно към SAP или други корпоративни системи.
Така използваме SAP там, където той вече предоставя необходимата бизнес логика, без да го превръщаме в система за всяка специфична оперативна задача.
SAP като част от по-голям процес
Този модел се среща постоянно. При поръчки SAP може да управлява PR/PO, докато потвържденията от доставчици пристигат по e-mail или през външни портали.
При Logistics информацията може да започва в SAP, но след това да бъде обработвана от транспортни, митнически или клиентски системи. При Master Data данните могат да бъдат подготвяни и одобрявани извън SAP, а автоматизацията да извършва контролираното въвеждане и последващата проверка.
При документи – фактури, декларации, сертификати – информацията може да бъде автоматично извлечена, валидирана и едва след това да бъде извършена съответната SAP операция. При работа с външни портали RPA може да действа и като интеграционен слой, включително временно, докато впоследствие бъде наличен API.
RPA не е алтернатива на архитектурата
Това не означава, че всяка ръчна операция трябва да бъде роботизирана. Преди автоматизацията трябва да си зададем няколко въпроса:
- Има ли стандартна SAP функционалност, която вече решава проблема?
- Има ли подходящ API или стандартен интерфейс?
- Трябва ли процесът първо да бъде променен?
- Има ли сателитни системи, между които информацията трябва да се движи?
- Къде е необходима експертна преценка и къде решението е детерминистично?
Практическият модел често е комбинация: SAP + API + RPA + специализирани системи + AI + човешко решение. SAP остава централизираната система там, където това има смисъл. RPA свързва системите и автоматизира рутинното изпълнение. AI може да обработва неструктурирана информация. А човекът остава там, където е необходима бизнес или експертна преценка.
Най-добрият кандидат не е SAP транзакцията
Една SAP операция може да отнема секунди. Истинското предизвикателство често е преди и след нея: събиране на информация, проверки, работа с няколко системи, изчисления, обработка на документи, комуникация, изключения и актуализиране на резултата.
Затова правилният въпрос при автоматизацията е: Коя част от процеса трябва да остане в SAP, коя трябва да бъде изпълнявана от друга система и кои ръчни връзки между тях можем да премахнем?
| Точно там се намира реалният потенциал на RPA: не да автоматизираме повече SAP екрани, а да изграждаме по-добри end-to-end бизнес процеси. |