Описание на работен процес: какво да запишете, преди да купите софтуер

Защо софтуерът не оправя процес, който никой не е описал

По данни на Евростат за 2025 г. 46,45% от фирмите в ЕС с 10 и повече заети ползват ERP система. В България делът е 26,64%. CRM система ползват 28,51% от фирмите в ЕС и 11,92% от българските. Тоест много български фирми тепърва ще избират първата си такава система и ще го правят без опит в предишно внедряване.

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

Описанието на процеса е евтино в сравнение с тази грешка. Нужни са ви хората, които вършат работата, малко търпение и таблица.

Какво значи един процес да е описан

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

За всеки процес записваме едни и същи неща:

• Какво го започва: обаждане на клиент, поръчка от сайта, сигнал от склада, дата в календара.
• С какво свършва: изпратена пратка, издадена фактура, затворена рекламация. Краят трябва да може да се провери.
• Стъпките поред, всяка с глагол и с човек: „операторът проверява адреса“, „складът сканира артикула“.
• Какви данни влизат и излизат на всяка стъпка и откъде идват.
• Какво вижда човекът на екрана в този момент: бутон, списък, съобщение.
• Изключенията: какво става, когато нещо липсва, закъснее или е сгрешено.

Как да съберете описанието: гледайте работата, а после питайте

Най-честата грешка е описанието да се пише в кабинета на управителя. Управителят знае как процесът трябва да върви. Операторът знае как върви. Двете версии рядко съвпадат, а на вас ви трябва втората.

От обслужването на клиенти съм научил, че разликата между инструкцията и практиката излиза още при първото необичайно обаждане. Затова седнете до човека, който върши работата, и го гледайте как обработва десет реални случая. Записвайте какво натиска, къде преписва на ръка, кога отваря друга програма или тетрадка, кога вдига телефона, за да пита колега. Всяко преписване и всяко „питам колегата“ е място, където процесът зависи от паметта на един човек.

После питайте за редките случаи. Хората помнят лесно ежедневието и забравят това, което става веднъж месечно. А точно то най-често не е предвидено в новата система.

Изключенията са по-важни от основния път

Основният път е лесен за описване и всяка система го поддържа: поръчка, плащане, събиране, изпращане. Разликите между фирмите са в изключенията. Затова в описанието на всеки процес отделям поне толкова място за тях, колкото за основния път.

Ето няколко изключения, които при нас излязоха наяве чак когато системата вече работеше. Артикули без баркод тихо изпадаха от събирането, защото процесът предполагаше, че всичко се сканира. Поръчка, отказана направо в Shopify, оставаше в започната сесия за събиране, защото процесът предполагаше, че отказите минават през нашия екран. При наложен платеж статусът „платено“ в магазина не отговаряше на реалните пари, защото повечето такива поръчки никога не получаваха този статус. Нито едно от трите не е сложно. Всяко от тях обаче щеше да се види предварително, ако някой беше попитал „ами ако…“ за всяка стъпка.

Въпросите, които задаваме за всяка стъпка:

• Какво става, ако данните липсват или са грешни (адрес, телефон, баркод)?
• Какво става, ако клиентът промени поръчката, след като е започнала обработката?
• Какво става при отказ отвън: куриерът не приема пратката, банката отказва плащането?
• Какво става, ако същото действие се направи два пъти (два клика, повторно изпратено съобщение)?
• Кой разбира, че нещо е заседнало, и откъде разбира?

Кой какво натиска: един момент, един човек

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

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

Третото правило е за автоматичните действия. Когато описвате процеса, се изкушавате да добавите „и тук системата сама ще…“. Записвайте такива идеи отделно, като желания. Всяко автоматично действие, което никой не натиска, е място, където нещо може да заседне, без никой да разбере. Решението дали да го има се взима след описанието, не по време на него.

Нужна ли ви е специална нотация като BPMN

BPMN е стандарт на OMG за изобразяване на бизнес процеси. Последната му версия, 2.0.2, е публикувана през януари 2014 г. Според OMG нотацията е предназначена да се ползва пряко от хората, които проектират, управляват и изпълняват бизнес процесите. Полезна е, когато процесът е голям и когато го предавате на външен изпълнител, който вече работи с нея.

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

Как описанието се превръща в тест за доставчика

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

Така сравнявате системите по вашата работа. Където доставчикът казва „това ще го направим допълнително“, записвате цена и срок. Където казва „при нас така не се работи“, решавате дали да промените процеса или да търсите друга система. И двете са нормални решения, стига да са взети съзнателно.

Ние работим по същия начин, когато правим система за клиент: първо описание на процесите, после код. Как изглежда това на практика, описваме в „Как работим“, а за управлението на клиенти и поръчки в „CRM и ERP“.

1. Изберете трите до пет процеса, през които минават парите: поръчка, плащане, доставка, връщане, доставчици.
2. Опишете всеки с начало, край, стъпки и хора.
3. Добавете изключенията за всяка стъпка.
4. Направете таблицата „кой какво натиска“ и проверете дали всяка стъпка се вижда на екрана.
5. Превърнете описанията в сценарии за демонстрация.