Пет автоматизации, срещу които бихме ви посъветвали

Здравото портфолио от автоматизации отсява 30–50% от кандидатите, преди някой да е написал ред код. Портфолио с 0% отсети няма изключително добри идеи — има декоративни гейтове. Затова въпросът, който си струва да зададете на всеки консултант, нас включително, е срещу кои автоматизации е съветвал напоследък. Ето пет, със сметките.

Дванадесет пускания годишно не издържат автоматизация

Задача, която върви месечно и отнема деветдесет минути, прави осемнадесет часа годишно. При часовата цена на труда в България за 2025 г. — 12,0 EUR, най-ниската в ЕС, при средно 34,9 EUR за Съюза (Евростат) — това са около 216 EUR годишен труд. Всяка бизнес обосновка, писана по западен шаблон, се къса точно тук: същата автоматизация има около три пъти по-дълъг payback в София, отколкото в Амстердам.

Back-office автоматизацията обикновено се държи на payback под дванадесет месеца. Да минете тази летва означава да построите, интегрирате, наблюдавате и поддържате нещото за под 216 EUR. И честната цена не е happy path-ът: наблюдението на Флавиу Кристиан, което Temporal цитира, е че обработката на грешки е над две трети от една производствена система.

Вторият проблем е, че автоматизация с ниска честота не може да бъде експлоатирана. Break rate се мери на сто пускания, а дванадесет пускания годишно дават дванадесет точки. Microsoft Power Automate пази история на изпълненията тридесет дни — счупи ли се декемврийското пускане, ноемврийското го няма. Същата платформа изключва flow-ове след деветдесет дни без активност на тригера, което поставя всяка тримесечна автоматизация в прозореца за изключване по дизайн.

Направете вместо това: атакувайте деветдесетте минути, не дванадесетте повторения. Един фиксиран експорт, една запазена справка или един шаблон обикновено свалят задачата до двадесет минути срещу ден работа и нула постоянна поддръжка.

Когато изключенията надделеят, разходът се мести, а не изчезва

Process mining последователно показва, че топ пет вариантите покриват 60–80% от обема, а зад тях стои опашка от стотици. Плоско разпределение на вариантите означава, че няма процес за автоматизиране — има навици. А ако conformance fitness спрямо документирания модел падне под около 0,8, документираният процес е художествена литература и всяка спецификация, писана по него, също.

Точката на изравняване е едно неравенство. Нека p е делът случаи, които машината приключва без докосване, t — спестените минути на всеки от тях, а x — допълнителните минути, които едно изключение вече струва. Автоматизацията се изплаща само докато p / (1 − p) е по-голямо от x / t.

Членът, който всички зануляват, е x, и той никога не е нула. Проверяващият наследява само трудните случаи, плюс частичен машинен резултат, който трябва да одитира, преди да го приеме или изхвърли. Най-добре документираният пример е плащането на фактури: touchless rate се движи от 20–30% към 65–80% при фактури с PO, но остатъчните изключения се установяват на 15–30% през първата година при реален микс от доставчици. Доставчиците цитират числителя; договаряйте знаменателя.

Отдолу стои по-неприятна находка: в документоемкия back office голяма част от изключенията са дефекти в данните нагоре по веригата — грешна референция към поръчка, липсващи master data в доставчика, сменен IBAN — които никой модел не поправя и никой праг на увереност не отклонява.

Направете вместо това: кодирайте таксономия на изключенията от няколкостотин реални случая, преди да сте определили обхват, с тези дефекти в данните изведени на отделен ред. Често препоръката, която оцелява, е да оправите master data-та на доставчиците и да не купите нищо.

Автоматизация, спряна преди изплащане, е отписана още при обхвата

Ако целта е payback за дванадесет месеца, а cutover-ът на ERP-а е след девет, сметката е приключила преди kickoff-а. По-острата загуба е интеграционната повърхност, която умира дори там, където процесът оцелява: UI селектори срещу стария GUI отиват на нула, а clean core доктрината на SAP е недвусмислена — всичко, писано срещу неосвободени таблици или чрез запис на екрани, е дълг, който ъпгрейд към S/4HANA чупи тихо, докато пускането продължава да рапортува успех.

Опасната версия не е обявената миграция, а тази, която никой не е споменал на работната среща. Два въпроса не струват нищо: кога изтича договорът за ERP-а и кога е бил последният голям ъпгрейд?

Направете вместо това: по време на замразяване стройте само слоя извън ядрото — приемане на документи, валидация, скрининг на master data, опашки за изключения, оркестрация — срещу освободени API-та и отстрани, а не вътре в системата. Този слой преживява cutover-а, а базовата линия от process mining, която сте направили, за да решите, става собствената before/after мярка на миграцията.

Валидацията на схемата не хваща поле, сменило смисъла си

Data contract е обвързващо споразумение между производител и консуматор по четири неща: схема, семантика, свежест и собственост. Защитният код покрива три. Смяна на тип гърми. Null гърми. Закъснял файл вдига проверката за свежест.

Семантиката се чупи безшумно и при пълна пропускливост. Статус 4 е означавал „доставено“; след един релийз нагоре означава „доставено до хъб“. Полето е налично, с правилен тип, в допустимия диапазон — и вече грешно. Автоматизацията продължава да работи, а първият, който забелязва, е клиент. Добавете at-least-once доставка без idempotency key и коригиращото повторение осчетоводява всичко по два пъти.

Затова тестът е организационен, не технически. Сложете четирите ангажимента на една страница — стабилност на схемата с обявен срок за предизвестие, значението на всяка стойност на статуса, SLA за свежест спрямо темпото на решенията, поименен собственик, достижим когато се счупи — и поискайте подпис от собственика нагоре по веригата. Ако откаже, вече знаете с колко предизвестие ще разполагате.

Направете вместо това: пуснете набора от проверки преди автоматизацията — dbt tests, Great Expectations или Soda, които се въртят ежедневно срещу изхода на производителя и алармират него, не вас, ограничени до петте до петнадесет критични полета, които този случай реално консумира. Оставете ги едно тримесечие. Времето му за реакция по тези аларми е данните, от които се нуждаете; ако никой не отговаря, сте купили решение да не строите на цената на един тестов набор.

Автоматизация вместо разговор само отлага разговора

Признаците се повтарят. Спонсорът не може да назове собственика на процеса, чиято опашка се променя. Искането е да се съгласуват таблиците на два екипа, вместо да се реши коя от тях е меродавна. Ползата е „по петнадесет минути на четиридесет души“ — а спестяване под около 0,2 FTE на човек, разпръснато из отдел, никога не се консолидира в нещо, което Финанси ще запишат.

Най-лошата версия е автоматизиране на цикъл от преработка. Повторяемост от 20–40% по полетата за цена и условия на плащане е нормална и обикновено е най-големият скрит разход в процеса. Автоматизирайте цикъла и сте направили преработката по-евтина, следователно по-честа, и сте изтласкали разхода нагоре, където никой не мери.

Има и версия, която законът така или иначе изкарва наяве. Разпределянето на задачи по поведение и наблюдението на представянето на служители попадат в Annex III на AI Act, а член 26, параграф 7 изисква работниците и техните представители да бъдат информирани, преди такава система да заработи на работното място — задължение, което ляга върху HR, не върху IT. Член 22 от GDPR забранява решения, основани единствено на автоматизирана обработка, с правен или сходно значим ефект. Разговорът се случва. Просто по-късно и с адвокати.

Направете вместо това: напишете с едно изречение решението, което автоматизацията замества, и го занесете на този, който може да го вземе. Ако дойде отговор, автоматизацията става по-малка и много по-добре специфицирана. Ако не дойде, намерили сте истинското ограничение и то никога не е било софтуер.

Къде това спира да важи

Нисък обем плюс висока последица обръща първия аргумент. Задължително подаване към институция — поетапното SAF-T отчитане към НАП има месечни секции — се автоматизира заради контрол, не заради труд: грешката струва санкция и повторно подаване, а не деветдесет минути. Оценявайте контрола и спрете да броите часове.

Там, където изключенията са продуктът, а не дефектът — триаж на щети, прием на пациенти, жалби — автоматизацията стои върху маршрутизирането, не върху решаването, и метриката е точност на маршрутизиране, а не touchless rate.

Една граница за нас. Palamed има четири доставени ангажимента: европейски маркетплейс за автомобили с над 300 000 обяви, дигиталният речник на Министерството на образованието и науката на beron.mon.bg, автоматизация на имейл маркетинга за козметична марка, където около -60% време за подготовка на изходящата комуникация е измерване на самия клиент, и NLP модул, който чете, класифицира и подготвя отговори на търговски запитвания по имейл и в Instagram от продуктовите и ценовите данни, които екипът и без това поддържа — клиентът е отчел около 85% по-малко ръчно писане по повтарящите се запитвания, а всеки отговор се одобрява от човек, преди да тръгне. Не сме управлявали функция по плащане на фактури и не сме наследявали парк от ботове; горното е публикуван модел и стандартите зад него.

И ни струва да го напишем. Discovery, което завършва с „не купувайте нищо“, е най-малката фактура, която издаваме, и най-трудната за издаване втори път. Правим го, защото фунията на MIT NANDA — 60% проучени, 20% пилотирани, 5% внедрени — е до голяма степен архив на гейтове, на които никой не е бил склонен да отсее нищо.