Шест начина автоматизацията да се провали след go-live

Повечето разбори на автоматизационни проекти са за проекти, които никога не са тръгнали. Те са лесният случай: бюджетът е свършил, обхватът е избягал, някой е напуснал. По-трудният случай е проектът, който тръгна, работи, беше отпразнуван — и осемнайсет месеца по-късно никой в организацията не може да каже точно какво прави.

Това разпадане има форма. По-долу са шестте режима, срещу които проектираме, и конкретната проверка, която хваща всеки от тях, преди да стане необратим.

1. Опашката от изключения тихо се превръща в процеса

Всяка автоматизация има праг на увереност. Над него машината действа, под него решава човек. По време на пилота тази опашка винаги е обслужена — обикновено от човека, който е лобирал за проекта, мотивиран и бърз.

После този човек сменя ролята си или излиза от компанията. Опашката продължава да се пълни. Никой не е записан като неин собственик, защото при пилотния обем никога не е трябвало.

Шест месеца по-късно опашката е процесът. Хората започват да заобикалят автоматизацията, за да не ѝ подават работа, която после сами ще трябва да разчистват.

Проверката: преди go-live собственикът на опашката се назовава писмено, с таван на обема и правило за ескалация. Ако отговорът на въпроса „кой обработва тази опашка в деветия месец“ е роля, която още не съществува, автоматизацията не е готова за пускане.

2. Прагът е настроен веднъж и остарява заедно с данните

Прагът е настроен върху данните, които сте имали тогава. Данните се движат: нов доставчик с друго оформление на фактурата, нова продуктова категория, ребрандинг, който сменя хедъра на всеки документ, промяна в изискванията за електронно фактуриране.

Моделът не знае, че разпределението се е изместило. Той продължава да връща уверени отговори върху входове, каквито не е виждал.

Проверката: следете седмично дела на записите, паднали под прага, а не само точността. Опашка, която внезапно се е свила наполовина, е толкова тревожна, колкото и опашка, която се е удвоила — обикновено означава, че нещо се обработва уверено и грешно, вместо да бъде правилно спряно. Ако имате достъп до входните разпределения, PSI или прост тест на Колмогоров–Смирнов върху ключовите полета струват по-малко от един ден работа и се пускат по график.

3. Най-опасната интеграция не се проваля, а успява погрешно

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

Наблюдавали сме този модел цяла година в система, където статусно поле се пишеше в deprecated таблица. Всичко рапортуваше успех. Надолу по веригата не се променяше нищо. Същото важи за webhook, който връща 200 — това означава „приех“, не „приложих“.

Проверката: проверявайте обратното четене, не записа. След като запишете, прочетете записа през същия интерфейс, който ползва бизнесът, и сравнете. Ако интеграционният ви тест не прави пълен цикъл, той тества вашия код, а не системата.

4. Смени ли се методът на измерване, резултатът е съвпадение

Този режим убива подновяванията на договора и е изцяло самопричинен.

Измервате базата по един метод — хронометриран извадков замер, ръчен одит — а после измервате резултата по друг, защото дотогава вече имате телеметрия, а телеметрията е по-лесна. Подобрението, което отчитате, е отчасти реално и отчасти артефакт от смяната на инструмента.

Единственото число от този тип работа, което цитираме, е около -60% време за подготовка на изходящата комуникация при beauty бранд — и го цитираме така, както е: измерено от клиента, с неговия метод, върху неговия период. Всеки път, когато го споменем, споменаваме и това. Число, произведено с различен метод от базата, не е резултат.

Проверката: методът на измерване се замразява заедно с базата, писмено, преди да е започнала разработка. Ако се налага смяна на инструмента, двата се въртят паралелно един пълен цикъл и разликата между тях се публикува, вместо да се прикрива.

5. Документация, писана последна, не издържа тест за възстановяване

Документите за предаване се пишат накрая, от човека, който вече не се нуждае от тях, за читател, който още не съществува. Описват щастливия път в сегашно време и спират там.

Тестът не е дали документът съществува. Тестът е дали човек извън проекта може да възстанови системата с него.

Проверката: учение по възстановяване преди последната фактура. Някой, който не е участвал в разработката, взима runbook-а и връща услугата на счупена инстанция. Всичко, което този човек попита на глас, е дупка в документацията. Ние самите не издържахме този тест първия път, когато го проведохме — и затова го въведохме като задължителен.

6. Автоматизираният счупен процес просто греши по-бързо

Най-скъпият провал, защото най-дълго прилича на успех.

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

Проверката: четете event log-а, преди да гледате диаграмата от работилницата. Диаграмата описва процеса, който хората вярват, че изпълняват; времевите отпечатъци в ERP-а описват този, който наистина изпълняват. Conformance checking върху извлечения лог — с Celonis или с безплатен PM4Py, няма значение — показва разминаването за дни. Там, където двете не съвпадат, процесът се поправя преди автоматизация, или се автоматизира поправената версия и това се казва изрично.

Къде спира този списък

Пет от шестте режима не са технологични. Те са организационни, а шестият е дисциплина в тестването. Това съвпада с публикуваните данни за отпадането на пилотните проекти: ограничението рядко е моделът.

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

Затова нашите ангажименти завършват с условие за спиране, а не с парти по повод пускането. Нещо, което не може да се провали видимо, не може да му се вярва. И нещо, което няма собственик в деветия месец, всъщност никога не е било предадено.