Техническо задание за бизнес автоматизация: какво да подготвите, преди да поискате оферта

Две фирми могат да получат едно и също изречение („искаме AI да обработва заявките ни“) и да предложат напълно различни решения. Едната ще разбере автоматично разпознаване на имейли, другата нов клиентски портал, а третата ще включи и промяна на CRM процеса. Добро техническо задание за софтуер премахва точно тази неяснота. То не трябва да е документ от 50 страници, а честно описание на работата, границите и резултата, който бизнесът ще приеме.

Какво трябва да постигне заданието

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

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

1. Опишете бизнес целта и границата на процеса

Първият абзац трябва да отговори на четири въпроса:

• Какъв проблем наблюдавате днес?
• Къде започва и къде завършва процесът?
• Какво трябва да се промени след внедряването?
• Как ще разберете, че промяната е полезна?

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

Запишете и какво остава извън първата версия: например договарянето на отстъпки, подписването на договор и прогнозата за наличности. Така офертата няма скрито да включи три отделни проекта.

2. Начертайте текущия процес, включително неудобните варианти

Опишете как работата се извършва сега, преди да описвате бъдещата автоматизация. За всяка стъпка запишете:

1. какво задейства процеса;
2. кой човек или екип поема задачата;
3. в коя система работи;
4. какво решение взема;
5. на кого предава резултата;
6. какво се случва при липсващи или грешни данни.

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

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

3. Дефинирайте входовете, изходите и качеството на данните

Всяка автоматизация получава нещо и произвежда нещо. Ръководството на Microsoft за входове и изходи препоръчва те да се определят преди автоматизирането на процеса. За SME brief е достатъчна таблица като тази:

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

4. Направете списък на системите и достъпите

За всяка засегната система посочете име, предназначение, собственик във фирмата, доставчик, среда за тестове и налична техническа документация. Важно е да се знае дали има API, файлов обмен, webhook или само потребителски интерфейс, но не е нужно вие да избирате метода за интеграция.

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

Направете проста матрица на достъпите: коя автоматизация чете, създава, редактира или изтрива данни във всяка система. Принципът е да се дадат само необходимите права. Това съответства на препоръката за least privilege в ръководството на OWASP за оторизация. Използвайте отделни тестови профили и уговорете кой създава, сменя и отнема производствените достъпи.

5. Посочете ролите, одобренията и изключенията

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

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

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

6. Преведете нефункционалните изисквания на бизнес език

Функционалното изискване казва какво прави решението. Нефункционалното описва колко надеждно, сигурно и удобно трябва да го прави. Актуалният модел ISO/IEC 25010:2023 дава общ речник за оценяване на качеството на софтуерни продукти. Не е нужно малката фирма да преписва стандарт; нужно е да отговори на практичните въпроси:

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

Логовете не са само техническа подробност. CISA препоръчва на малки и средни организации да използват наблюдение и известия за рискови събития. Ако процесът обработва лични данни, опишете целта, минимално необходимите полета, сроковете за съхранение и отговорностите; официалният текст на Регламент (ЕС) 2016/679 поставя акцент върху ограничаването на целта и данните до необходимото. При съмнение включете отговорния за защита на данните или правен специалист още в discovery етапа.

7. Напишете критерии за приемане и Definition of Done

Критерият за приемане е наблюдаем резултат, а не общо обещание. GOV.UK описва acceptance criteria като списък от резултати, с който се проверява дали услугата е изпълнила нуждата на потребителя. Полезна формулировка е „готово е, когато…“.

За автоматизация на документ например:

• Готово е, когато валиден документ създава чернова с правилно пренесени задължителни полета.
• Готово е, когато дублиран документ не създава втори запис и се маркира за проверка.
• Готово е, когато липсващо задължително поле изпраща задачата към определена опашка, без окончателно записване.
• Готово е, когато прекъсната връзка не губи документа и отговорният човек вижда грешката.

Към това добавете Definition of Done за проекта: тестовете са приети от собственика на процеса, производствените достъпи са ограничени, мониторингът е активен, има инструкция за ръчна намеса, определен е собственик на поддръжката и е договорено как се заявяват промени. NIST посочва, че добрите изисквания трябва да могат да бъдат проверени, да са разбираеми и недвусмислени. Това е полезен тест и за кратък бизнес brief.

Попълнен мини пример: документ от имейл към счетоводна система

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

Краткото задание може да изглежда така:

• Цел: да се подготвя проверима чернова, без автоматично осчетоводяване.
• Начало и край: от ново съобщение с приложение до чернова или опашка за ръчен преглед.
• Входове: PDF или изображение; реалните формати и обичайният/пиковият обем се прилагат от клиента.
• Изходи: чернова, линк към оригинала, резултат от проверките и статус.
• Системи: обща поща и счетоводна система; API достъпът и тестовата среда подлежат на техническа проверка.
• Правила: съществуващ доставчик, задължителни полета, проверка за дубликат.
• Изключения: нечетим файл, липсващ доставчик, несъответствие или недостъпна система отиват към счетоводител.
• Приемане: тестов набор от анонимизирани нормални и проблемни документи покрива всеки описан маршрут.

Това е достатъчно за смислен discovery разговор и първоначален обхват. Не е обещание, че цената може да бъде фиксирана преди проверката на системите и данните.

Кратък шаблон за копиране

Име на процеса:
Собственик и финален одобряващ:
Бизнес проблем и измерена начална стойност:
Желан резултат и показател за успех:
Начало и край на процеса:
Текущи стъпки и участници:
Обичаен и пиков обем:
Входове, формати и задължителни полета:
Изходи и получатели:
Системи, собственици и налична документация:
Роли, права и човешки одобрения:
Бизнес правила и изключения:
Сигурност, лични данни, логове и съхранение:
Критерии за приемане:
Какво е извън първата версия:
Срокови или бюджетни ограничения:
Неизвестни, които трябва да се проверят:

Кога краткият brief не е достатъчен

Преминете към отделен платен или ясно ограничен discovery етап, ако процесът минава през много отдели и системи, няма надежден собственик на данните, наследеният софтуер е недокументиран, изключенията са повече от нормалния маршрут или грешка може да причини сериозна финансова, договорна или клиентска вреда. Същото важи при чувствителни данни, сложна миграция, външни доставчици с различни условия за достъп или необходимост от правна и security оценка.

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

Какво да не фиксирате предварително

Не е нужно да определяте конкретен AI модел, automation платформа, облак, база данни, архитектура или точния начин на API връзката, освен ако фирмена политика не ги налага. Не проектирайте и всеки екран преди да е потвърден процесът. Това са решения, които изпълнителят трябва да обоснове спрямо обхвата, риска и поддръжката.

Фиксирайте истинските ограничения: задължителните системи, правилата за данни, кой одобрява, какво не бива да се изпълнява автоматично, крайни срокове и реална бюджетна рамка. Оставете неизвестните видими. Един добър brief не се преструва, че всички отговори са известни; той прави ясно кои въпроси трябва да бъдат решени, преди автоматизацията да бъде построена.

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