ERP системата падна в събота: какво става с продажбите, влезли междувременно

За 1 минута

ERP система, която пада за известно време, не е рядкост: има поддръжка, актуализации и повреди. Скъпо е онова, което се случва с продажбите, влезли междувременно. Ако всяка продажба се запазва, преди да бъде обещана, опитва се отново с търпение, не се дублира при повторение, а онова, което не минава, се отделя с причината си, прекъсването става рутинна процедура. Ако не — става дни ръчно въвеждане, двойни поръчки и приключване, което не се равнява.

Представете си компания, която продава онлайн и на гише. Тя е измислена, но прилича на много други. Една събота нейната ERP система спира да отговаря. Може да е актуализация, която се е проточила, сървър, който се е рестартирал, или прекъсната връзка; за онова, което следва, няма значение. Онлайн магазинът остава отворен. Клиентите продължават да купуват. И всяка продажба трябва да стигне до ERP системата, за да се извади от наличността, да се отчете приходът и после да се издаде фактура.

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

1. Да затвори магазина, докато ERP системата се върне. Сигурно е и е скъпо: губи се продажбата, а понякога и клиентът.
2. Да продължи да продава и „да въведе после“. Някой изнася поръчките в таблица и после ги въвежда на ръка. Евтино е по време на прекъсването и скъпо на следващия ден.
3. Да продължи да продава, като всяка продажба се пази в подредено чакане, което наваксва, когато ERP системата се върне, проектирано да не дублира и със списък на онова, което не е успяло да мине.

Тази статия е за онези, които ръководят операциите, финансите или технологиите в компания, чиито системи зависят една от друга. Тя защитава една идея: прекъсването не е проблемът; проблемът е да не знаете какво е останало чакащо. И обяснява на езика на бизнеса петте елемента, които превръщат третия път в нормалното.

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

Всичко, което следва, е нарочно общо. Важи за ERP система, система за фактуриране, куриерска фирма или системата на партньор: всяка дестинация, която един ден не отговаря.

Прекъсването не е проблемът: проблемът е да не знаете какво е останало чакащо

Никоя система не отговаря през цялото време. Производителите публикуват прозорци за поддръжка, мрежите прекъсват, сървърите се рестартират. Самият стандарт на уеб запазва код за това: 503 означава, че сървърът не може да обслужи заявката поради временно претоварване или планирана поддръжка, което вероятно ще се реши след известно време (свободен превод) [7]. С други думи, индустрията приема за даденост, че дестинацията понякога няма да е налице.

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

• Колко продажби влязоха, докато ERP системата беше паднала?
• Колко вече стигнаха, колко още чакат и колко няма да минат от само себе си?
• Стигна ли някоя два пъти?

Ако отговорът на който и да е от тях е „трябва да проверим“, едно кратко прекъсване се превръща в дни ръчна работа и равняване. И най-лошото не е времето: а това, че никой не може да твърди със сигурност, че списъкът е пълен.

Какво става във всеки момент на прекъсването

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

Петте елемента, които следват, пазят влизащото по време на прекъсването; следващият раздел обхваща връщането и приключването.

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

1. Продажбата се запазва, преди да бъде обещана

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

Най-известният начин да се направи това има име в индустрията: изходяща кутия (на английски, transactional outbox). При записа на продажбата в същата стъпка се отбелязва и „трябва да се уведоми ERP системата“. Отделен процес чете тази кутия и прави изпращането. Така продажбата не се записва без своята задача [3]. Внимание: това пази случващото се вътре в компанията; не потвърждава, че ERP системата я е получила. Това потвърждение идва после, когато ERP системата отговори.

Ако между двете системи има съобщителна система, съществува допълваща идея — осигурената доставка (на английски, Guaranteed Delivery): след като съобщителната система приеме съобщение, тя го пази в хранилището си и не го изтрива, докато следващата стъпка не го получи [6].

На езика на комитета: ако ERP системата не отговаря, продажбата чака записана, вместо да се загуби.

2. Нов опит — с търпение и с разстояние

Когато изпращането се провали, естественото е да се опита отново. И това е добре, с две предпазни мерки.

Търпение: всеки нов опит чака малко повече от предишния, до таван, за да не се опитва прекалено [1]. Ако ERP системата ще се забави да се върне, няма смисъл да я питате всяка секунда. И това важи за временните повреди: ако ERP системата отхвърли продажба заради грешно въведени данни, новият опит не я поправя (това е елемент 5).

Разстояние: новите опити на много продажби не бива да падат в един и същ миг. Ръководството на Amazon за новите опити го обяснява така: ако всички неуспели повиквания чакат едно и също време, при новия опит те отново пристигат заедно и отново претоварват дестинацията; решението е към чакането да се добави малко случайност, за да се разпределят във времето [1]. Същото ръководство го обобщава с фраза, която си струва да се занесе на комитета: новите опити са егоистични (свободен превод); всеки нов опит изисква от дестинацията да изразходва повече ресурси, за да го обслужи, и ако дестинацията вече е претоварена, новият опит влошава претоварването, вместо да го облекчи [1].

Ако дестинацията отговори с предложение колко да се чака — стандартът на уеб предвижда технически сигнал за това, наречен Retry-After [7], — то се взема предвид заедно с договореното правило за нови опити.

3. Да се спре чукането на вратата

Има момент, в който новият опит вече не помага. Ако ERP системата не отговаря от доста време, изпращането на всяка продажба, за да се провали една по една, само хаби ресурси и от двете страни и води до повтарящи се грешки, които не помагат на работата.

За това съществува предпазителят (circuit breaker). Martin Fowler го описва така: повикването към другата система се обвива в обект, който брои грешките; когато те стигнат определен праг, предпазителят „изключва“ и следващите повиквания се връщат с грешка, без повикването дори да бъде опитано; и е добре, когато изключи, да уведоми някого [2]. Не всяка грешка трябва да го задейства — само грешките, определени за това [2]. От време на време той пропуска контролиран опит; ако дестинацията вече отговаря, потокът продължава.

На езика на комитета: компанията научава за прекъсването от сигнал, а не от клиент, който пита за фактурата си.

4. Повторението да не дублира

Това е елементът, който пази най-много пари. Нов опит може да пристигне два пъти: изпращането е тръгнало, ERP системата го е записала, но отговорът се е загубил по пътя; изпращачът не знае дали е стигнало и го изпраща отново. Ръководството на Amazon го казва направо: че едно повикване се е провалило или времето му е изтекло, не означава, че ефектът му не е настъпил, а операция с ефекти не е безопасна за нов опит, освен ако не е проектирана за това [1]. Изходящата кутия носи същото предупреждение: процесът, който изпраща, може да изпрати съобщение повече от веднъж — например ако падне веднага след изпращането и преди да го отбележи, — затова получателят трябва да разпознава вече обработеното [3].

Начинът да се постигне това е всяка продажба да пътува с уникален референтен номер, който дестинацията разпознава и пази: ако пристигне два пъти, вторият път не създава нова поръчка, а връща същия отговор като първия. Референтният номер работи само ако дестинацията наистина го сравнява, и се изпитва с всяка участваща система, включително тази за плащанията. Платежните процесори правят така; Stripe например пази отговора на първата заявка с ключ и ако пристигне друга със същия ключ, връща запазения отговор, вместо да повтаря операцията; освен това сравнява данните с тези на първата заявка и пази ключа за определено време, а не безсрочно [5]. Това свойство се нарича идемпотентност: повторението не променя резултата.

На езика на комитета: новият опит е проектиран така, че клиентът да има една поръчка и едно плащане, а равняването накрая го проверява.

5. Отделяне на онова, което не минава — с причината

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

Обичайната практика е да се зададе ограничение на опитите и, когато то бъде достигнато, продажбата да се премести в отделна опашка (на английски, dead-letter queue). Опашката сама не пази причината: заедно с продажбата се записват грешката, опитът и кой решава следващата стъпка. Документацията на Amazon за опашките го описва така: задава се колко пъти се опитва едно съобщение, преди да бъде преместено в тази опашка, а отделянето служи, за да се изолира необработеното и да се разбере защо [4].

Важна не е опашката, а това тя да има отговорник. Отделена продажба без отговорник е загубена продажба с по-хубаво име.

Когато ERP системата се върне: редът и темпото

Най-деликатният момент не е прекъсването, а връщането. Има две чести грешки.

Изпращане на всичко наведнъж. След дълго прекъсване може да има стотици чакащи продажби. Ако се изпратят всички едновременно, току-що вдигнатата ERP система получава лавина и може да падне отново. Това е същият урок като в точка 2, в голям мащаб: чакащото се изпраща с темп, който ERP системата издържа, и този темп се решава и изпитва предварително, а не в разгара на извънредната ситуация.

Изпращане без ред. Ако клиент е купил и после е отказал, ERP системата трябва да получи първо покупката и после отказа. Наобратно отказът не намира какво да откаже и покупката остава жива. За всяка продажба се определя редът на онова, което ѝ се случва — например с референтния ѝ номер и номер на стъпката, — и правилото за прилагането му, така че отказът да не се обработи преди покупката дори при нови опити. Различни продажби могат да напредват паралелно. А ако една продажба е минала през опашката за отделените, при връщането ѝ този ред се спазва; документацията на Amazon за опашките предупреждава, че такава опашка може да наруши реда на съобщенията [4].

И накрая — равняване: изпратеното срещу потвърденото от ERP системата, със списък на липсващото. Това не е недоверие към проектирането; това е доказателството, че прекъсването наистина е приключило.

Какво вижда клиентът междувременно

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

• „Получихме поръчката ви“ може да излезе веднага, защото продажбата вече е запазена в компанията.
• „Фактурата ви е готова“ излиза едва когато фактурата съществува, не преди това.
• Ако наличността се води в ERP системата, добре е магазинът междувременно да резервира продаденото от своя страна, за да не продаде два пъти последната бройка.

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

Рисковете на езика на бизнеса

Пет въпроса за следващия ви комитет

1. Последния път, когато ERP системата — или системата за фактуриране, или куриерът — не отговори, колко продажби влязоха междувременно и колко време отне на компанията ви да разбере?
2. Къде се пазят тези продажби, докато дестинацията не отговаря? Ако отговорът е „в програмата, която ги изпраща“, те се губят, когато тази програма се рестартира.
3. Ако една продажба се изпрати два пъти, създава ли ERP системата две поръчки? Помолете технологиите да го докажат с тестове, а не да го твърдят.
4. Кой отговаря за продажбите, които не минаха от само себе си, и как разбира?
5. Когато ERP системата се върне, кой решава с какъв темп наваксва? Ако никой не е решил предварително, решава дежурният в разгара на извънредната ситуация.

Ако няколко отговора са „не знам“, приемете го като сигнал да измерите потока преди следващия прозорец за поддръжка.

Откъде да започнете тази седмица

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

• Колко продажби влязоха по време на учението и колко стигнаха до дестинацията, когато тя се върна?
• Стигна ли някоя два пъти?
• Кои не минаха и разбра ли някой, без да ги търси?
• Колко време отне на дестинацията да навакса и издържа ли темпото?
• Получи ли някой сигнала за прекъсването и разпознава ли крайното равняване всеки референтен номер като потвърден или чакащ?

Листът, който се получи, е много конкретна спецификация на онова, от което се нуждае дейността ви.

Какво прави Hábil

В Hábil изграждаме по поръчка пространството между системите ви: магазина, ERP системата, фактурирането, куриерите и партньорите. Точно там се решава какво става с една продажба, когато дестинацията не отговаря.

Ако диагнозата ви потвърди, че едно прекъсване се превръща в дни ръчно въвеждане, предложението е в Hábil MDW: слоят, който застава между системите, които вече имате, без да ги заменяте. Всяко изпращане остава с отговора си или с причината за неуспеха, а повторните опити са проектирани да не повтарят ефекта. За всяка операция остава какво е изпратено, какво е отговорила всяка система, в колко часа и, ако нещо се е провалило, защо. Обхватът, свързваните системи и темпото на възстановяване се разглеждат с вашия случай.

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

Поискайте първия си разговор, безплатно.

Проверени на 12 ноември 2026 г. Всеки източник носи степента си на доверие: висока (прочетен първичен източник).