 |
Андрій Барабаш Керівник відділу розробки best-run Consulting |
Чому розробник — це не просто кодер, а бізнес-архітектор у світі ERP
У розробці аддонів для SAP Business One легко зупинитися на поверхні: є погоджене технічне завдання — реалізуй. Код має бути стабільним, логіка — відповідати опису. І наче цього достатньо. Але з досвідом приходить розуміння: реально корисні рішення зʼявляються тоді, коли ти починаєш мислити не тільки як розробник, а як інженер бізнес-цінності.
ERP — це не просто функціонал
SAP — це не просто програма чи мобільний застосунок. Це серце обліку й управління компанії. Тут кожен клік має наслідки, кожне поле — роль, а кожна кнопка потенційно впливає на гроші, час і людей.
І коли ти працюєш із цією системою, не можеш просто додати кнопку чи змінити звіт “як попросили”.
Потрібно зрозуміти логіку процесу, побачити ширшу бізнес-картину — навіть якщо не спілкуєшся з кінцевим користувачем напряму.
ТЗ — точка зору чи технічне завдання
У нашій компанії з клієнтами працюють консультанти. Вони збирають потреби, узгоджують рішення, формують технічне завдання. І навіть коли воно виглядає чітким — завжди є простір для аналітики.
З мого досвіду, ТЗ — це не завжди фінальна істина, а версія розуміння бізнес-проблеми. І саме тут починається найцікавіше.
Архітектор vs. Виконавець
- Виконавець бере задачу і програмує її буквально.
- Архітектор — ставить питання (навіть всередині себе), мислить на кілька кроків уперед, аналізує наслідки.
ERP — складна система. Змінив одне — вплинув на інше. Якщо цього не враховувати, можна створити проблему, яку потім довго будуть розгрібати колеги з підтримки.
Роль розробника — бути частиною логіки процесу
Навіть без прямого контакту з бізнесом, важливо навчитися його “відчувати”.
У мене були ситуації, коли щось у задачі виглядало нелогічно — і ми з командою звертали увагу консультанта:
«Ця логіка вже є в іншому модулі»
або
«А якщо зробити цей функціонал універсальнішим — ним зможуть користуватись й інші департаменти»
Це не просто технічна оптимізація. Це вже продуктове мислення. Це — бізнес-архітектура.
Що допомагає мислити стратегічніше:
- думати не тільки “як реалізувати”, а “навіщо це бізнесу”;
- розуміти структуру SAP, логіку модулів, зв’язки;
- не боятись ставити запитання консультантам;
- уявляти себе на місці користувача.
Практичні уроки з досвіду:
- Аддон — це не фіча, а частина процесу. Якщо він існує окремо — він або заважатиме, або ламатиметься.
- Іноді краще змінити процес, ніж додати код. Особливо, якщо задача — це обхід стандартної логіки SAP.
- Якщо після демо не треба пояснювати, як працює функція — значить, ми зробили правильно.
- Переобтяжені аддони — як перевантажені інтерфейси: зручність губиться ще до релізу.
І на кінець
Розробка в ERP — це завжди більше, ніж здається.
Якщо бачиш задачу глибше — твоя робота перестає бути просто технічною. Вона стає стратегічною.
Якщо ти розробник, який хоче не просто “виконувати задачі”, а створювати реальні зміни — вчися мислити як архітектор.
Бо врешті-решт, ми не просто кодимо — ми проєктуємо логіку бізнесу. І це зовсім інший рівень впливу.
