Подгответе задание за B2B платформа, като опишете как клиентът поръчва днес, кои данни идват от ERP системата и как ще проверите готовото решение. Започнете с реална поръчка и нейните изключения, а не със списък от екрани.
- Доброто задание за B2B платформа описва процеси, отговорници и проверими резултати, не само функции.
- За всяко поле определете коя система го управлява и какво става при грешка в ERP интеграцията.
- Отделете задължителния първи обхват от следващите подобрения.
- Изпратете еднакво задание на изпълнителите, за да сравнявате еднаква работа.
Как да подготвите задание за B2B платформа?
- Опишете сегашния път на поръчката и местата с ръчно въвеждане.
- Разделете фирмените клиенти, потребителите и техните права.
- Документирайте каталога, мерните единици и правилата за ценообразуване.
- Определете обмена с ERP и поведението при прекъсване.
- Разделете първата версия от бъдещите функции.
- Запишете критерии за приемане, отговорници и условия за поддръжка.
Това е документ за възлагане на работа, не предварително написан софтуерен проект. Не е необходимо сами да определяте архитектурата. Необходимо е изпълнителят да разбере кое поведение е задължително за вашата B2B платформа за дистрибутори и кое остава за уточняване.
Защо списъкът с функции не стига
„Каталог, клиентски профил и поръчки“ описва почти всеки онлайн магазин. Не показва дали един клиент купува от няколко юридически лица, дали търговецът променя договорна цена или дали складът изпълнява поръчката на части. Именно тези правила определят обхвата на разработката.
При подготовка на задание през 2026 г. отделете бизнес изискването от предложеното техническо решение. Изискване е клиентът да получи правилните договорни условия. Конкретен плъгин, екран или технология е възможен начин за изпълнение, който трябва да бъде проверен.
Проверимо изискване е това, за което можете да покажете начални данни, действие и очакван резултат. Така разговорът с изпълнителя остава конкретен, а приемането не зависи от различни тълкувания на думата „готово“.
Опишете реална поръчка от начало до край
Вземете пример от ежедневната работа и премахнете личните и поверителните данни. Проследете кой избира продуктите, кой потвърждава условията и кога поръчката става задължение за изпълнение. Добавете документите, които се създават по пътя.
Към стандартната поръчка приложете 3 примерни сценария като препоръчителен начален комплект: поръчка с договорни условия, поръчка с липсващ продукт и поръчка, която изисква одобрение. Това не е универсален минимум за всеки проект. Целта е да извадите различните правила наяве още преди офертата.
За всеки сценарий запишете:
- Кой потребител започва и от името на коя фирма.
- Откъде идват продуктите и търговските условия.
- Какво потвърждава клиентът преди изпращане.
- Кога поръчката се записва в ERP системата.
- Какво виждат клиентът и служителят при отказ или забавяне.
Добавете и ограниченията на сегашния процес. Ако поръчката не може да се редактира след изпращане към склада, напишете го изрично. Ако промяната става през търговски представител, платформата трябва да отрази този ред, а не да предлага неподдържана самостоятелна редакция.
Разделете фирмените акаунти от хората, които ги използват
Една фирма не е един потребител. Купувачът подготвя поръчка, ръководителят я одобрява, а счетоводителят търси документ. Запишете тези роли с думите, които използвате във вашата организация.
Опишете връзката между юридическо лице, клон, обект и адрес за доставка. Уточнете дали един човек има достъп до няколко фирми и дали условията се променят според избрания обект. Имейл адресът сам по себе си не описва тези отношения.
Полезна таблица за заданието е:
| Роля | Какво прави | Какво не трябва да може |
|---|---|---|
| Купувач | Подготвя и изпраща разрешените поръчки | Да вижда чужди фирмени документи |
| Одобряващ | Потвърждава поръчки по договорените правила | Да променя права извън своята организация |
| Счетоводен потребител | Преглежда разрешени финансови документи | Да поръчва, ако няма такова право |
| Търговски представител | Обслужва определени клиентски акаунти | Да влиза без следа в чужд профил |
Таблицата е примерен модел, не готова конфигурация. Посочете кои роли действително ви трябват и кой одобрява достъпа. Запишете и как се прекратяват правата при напускане на служител на клиента.
Подгответе каталога и търговските правила
Избройте видовете продукти, а не само броя им. Един артикул с различни разфасовки, заместители и технически параметри изисква различно описание от продукт с един код и една мерна единица. Приложете анонимизирана извадка от реалните данни.
Снимки на екрани помагат, но не заменят структурата. Изпълнителят трябва да вижда кои полета са задължителни, кои идват от ERP и кои се редактират от вашия екип. При голям каталог уточнете и как клиентът търси: по код, размер, съвместимост или собствен артикулен номер.
Запишете приоритета на правилата
Не е достатъчно да напишете „индивидуални цени“. Опишете кое правило важи, когато договорна отстъпка, количество и кампания се отнасят за една и съща поръчка. Уточнете кой има право да направи изключение и как се пази историята му.
Включете:
- Мерни единици и допустими преобразувания.
- Минимално количество и стъпка на поръчване.
- Видимост на продукти по клиент или група.
- Приоритет на договорите и отстъпките.
- Условия за плащане и проверки преди потвърждение.
Не оставяйте основното правило единствено в електронна таблица на търговския отдел. Ако ERP системата не го съдържа, отбележете това като отделен въпрос за проекта. Иначе платформата ще автоматизира само част от действителния процес.
Определете обмена с ERP по вид данни
Посочете името и използваната версия на ERP системата, нейния доставчик и човека за технически контакт. Например Microsoft Dynamics NAV и Business Central не са взаимозаменяеми описания на една среда. Самото име на системата не доказва какъв обмен е достъпен във вашата инсталация.
През 2026 г. конкретната версия, направените доработки и разрешеният достъп остават част от проверката преди възлагане. Приложете наличната документация за обмена, без да изпращате пароли в заданието. Ако документацията липсва, запишете кой ще я осигури.
| Данни | Водещ източник за уточняване | Какво да решите |
|---|---|---|
| Артикули и мерни единици | ERP или продуктов регистър | Кои полета се обменят и кои са задължителни |
| Клиенти и търговски условия | ERP или друга договорена система | Как се свързват фирмата и потребителите |
| Поръчки | Платформа при подаване, ERP при обработка | Кога записът е приет и кой пази номера му |
| Документи и изпълнение | Счетоводна или складова система | Кои състояния вижда клиентът |
Това са възможни отговорности, не предписание за всяка фирма. За всяка група данни определете един водещ източник и ясен ред за промяна. Две системи, които свободно променят едно и също поле, създават спор коя стойност е вярна.
Задайте допустимото забавяне, вместо да пишете „в реално време“
Опишете кога остарялата информация пречи на поръчването. За едни данни е нужен обмен при събитие, за други е достатъчна периодична задача. Решението се съгласува с възможностите на ERP и с действителното натоварване.
Попълнете реалните си измервания: артикули, активни фирми, поръчки на ден и редове в натоварена поръчка. Ако не ги знаете, отбележете ги за измерване. Не подменяйте липсващите данни с прогноза, представена като сегашно състояние.
Опишете какво става при прекъсване
Клиентът трябва да разбира дали поръчката е приета, чака потвърждение или е отхвърлена. Запишете кой получава известие и как операторът проверява проблемния запис. Повторното изпращане не трябва да създава нова поръчка за същото намерение.
В заданието включете следа от обработката, безопасен повторен опит и отговорник за грешките. Не задавайте на бизнеса да избира конкретна технология за опашки или съобщения. Задайте резултата, който технологията трябва да осигури.
Разделете първата версия от бъдещите подобрения
Подредете обхвата в 2 етапа като работна рамка: необходимото за първото реално поръчване и следващите подобрения. Това е предложение за планиране, не обещание за срок. Всяка отложена функция трябва да има ясно име и причина да не блокира старта.
| Етап | Възможен обхват | Условие за включване |
|---|---|---|
| Първа версия | Достъп, каталог, договорни условия, подаване на поръчка, основен обмен | Без него избраният процес не работи |
| Следващ етап | Допълнителни справки, удобства и разширени сценарии | Може да се добави без да оставя основния процес неработещ |
Не отлагайте контрол върху достъпа, проверка на условията или обработка на грешки само защото не се виждат на началния екран. Това са части от работещата поръчка, а не декоративни подобрения.
Emporica разработва B2B платформи и ERP интеграции за дистрибутори, търговци на едро и производители. Разработката по поръчка е подходяща, когато стандартният процес не покрива вашите правила; ако готово решение ги изпълнява, допълнителната разработка не е цел сама по себе си.
Запишете критерии за приемане с реални сценарии
Заданието за B2B платформа трябва да позволява проверка от човек, който не е писал кода. За всяка задължителна функция добавете начални данни, действие, очакван резултат и отговорник за приемането. Формулировката „работи коректно“ не е достатъчна.
Препоръчителен формат е 1 сценарий на ред в общ документ. Например: одобрен купувач подава поръчка, ERP я приема, клиентът вижда потвърждение и същия референтен номер. Отделен сценарий проверява отказ от ERP, вместо да го скрива в общия тест.
Проверете и неприятните случаи:
- Потребител опитва да отвори документ на друга фирма.
- Обменът прекъсва след изпращане на поръчката.
- Клиент повтаря действието, защото не вижда отговор.
- Условията се променят, докато поръчката е в подготовка.
- Артикул от приложен файл не съвпада с каталога.
Определете кой има право да приеме ограничение и как то се документира. Ако за временно изключение е нужен ръчен процес, посочете кой го изпълнява. Иначе временното решение остава без собственик.
От какво зависи обхватът на заданието?
Обхватът се определя от различните правила, не от броя страници в документа. За проект, възлаган през 2026 г., проверете най-вече:
- Колко различни вида клиенти и права имате.
- Колко източника на продуктови и търговски данни участват.
- Какви промени са възможни след подаване на поръчка.
- Кои операции зависят от външен доставчик.
- Как се проверяват и разрешават изключенията.
Запишете неизвестните в отделен списък с отговорник. Непотвърдената възможност на ERP не трябва да се превръща мълчаливо в обещан обхват. Поискайте проверка, преди изпълнителят да поеме съответния ангажимент.
Какво да поискате от изпълнителя заедно с офертата?
Изпратете една и съща версия на заданието и поискайте отговор по всяка задължителна точка. Нека бъде ясно кое е включено, кое изисква проучване и кое остава извън проекта. Така сравнявате обхват, а не само крайни суми.
Поискайте описание на зависимостите от ERP доставчика, реда за промени и предаването на проекта. Включете собствеността върху кода, достъпа до хранилището, служебните акаунти и документацията. Уточнете и границата между отстраняване на дефект и нова функционалност.
Emporica посочва на страницата си за B2B разработка, че кодът, хранилището, хостингът и служебните акаунти са на клиента. Това е конкретен въпрос, който можете да поставите на всеки изпълнител, без да предполагате, че всички работят по еднакъв модел.
Трябва ли да изберете технология преди заданието?
Не. Първо опишете ограниченията, данните и процеса, а след това поискайте обосновано техническо предложение. Изключение е вече взето бизнес решение, например задължително използване на съществуваща платформа, което трябва да бъде записано като ограничение.
Може ли да започнете без готови продуктови данни?
Можете да започнете проучването, но не представяйте неподготвените данни като решен въпрос. Опишете кои полета липсват, кой ще ги попълни и кога ще се предостави представителна извадка за проверка.
FAQ
Кой трябва да подготви заданието за B2B платформа?
Заданието се подготвя от бизнеса с участие на търговския екип, склада, счетоводството и човека, отговорен за ERP. Изпълнителят помага да се уточнят техническите зависимости и проверките.
Трябва ли заданието да съдържа готов дизайн?
Не, готовият дизайн не е условие за полезно задание. Първо опишете действията, данните и правата, след което екраните се проектират спрямо тях.
Как да опишем ERP интеграцията, ако не познаваме техническите подробности?
Посочете системата, версията, доставчика и данните, които трябва да се обменят. Оставете непотвърдените възможности като въпроси за съвместна проверка, вместо да ги приемате за налични.
Нужно ли е да включим всички бъдещи функции?
Опишете бъдещите идеи отделно от задължителната първа версия. Така изпълнителят вижда посоката, без всяка идея да се превръща в условие за стартиране.
Как се сравняват оферти за B2B платформа?
Сравнявайте отговорите по една и съща версия на заданието. Проверете включения обхват, изключенията, зависимостите от ERP доставчика и условията за приемане и поддръжка.
Трябва ли да дадем истински клиентски данни за първоначалната оферта?
За първоначалното уточняване използвайте анонимизирани примери, които запазват структурата и бизнес правилата. Не изпращайте пароли, лични данни или поверителни договори в общото задание.
Последна проверка преди изпращане
Добавете раздел „Какво платформата няма да прави“. Там запишете отложените функции, непроменяните системи и операциите, които остават ръчни. Липсващата функция създава по-малко спорове, когато е изрично изключена, отколкото когато всяка страна предполага различен обхват.
Ако подготвяте проект през 2026 г., започнете с реалния си процес и оставете архитектурните решения за проверка с изпълнителя. Emporica може да обсъди разработката на B2B платформа на тази основа: кой поръчва, по какви условия и как поръчката достига до системата за изпълнение.