Готова програма чи розробка під себе: як вирішити бізнесу

Готове рішення чи індивідуальна розробка — відповідь залежить від одного питання: чи цей процес відрізняє ваш бізнес від конкурентів. Якщо ні, беріть готову програму й підлаштуйте процес під неї; якщо так, варто прорахувати розробку під себе, і часто вона не замінює готові сервіси, а з'єднує їх.

Ключові висновки

• Готове рішення беріть для функцій, які є в усіх: каса, бухоблік, пошта. Свою розробку — для того, чим ви відрізняєтесь від конкурентів.
• Часто найкращий варіант — не «або-або», а готові сервіси, з'єднані своєю інтеграцією.
• Порівнюйте не лише вартість старту, а й залежність від постачальника, доступ до даних і те, хто платить за зміни.
• Права на код програми, написаної на замовлення, визначає договір. Перевірте цей пункт до підписання.

Зміст

Нижче — як це перевірити на своєму бізнесі: коли вистачить готового, коли варто писати своє, який є третій шлях і що з'ясувати до підписання договору. Без цін і обіцянок, лише критерії, за якими рішення можна ухвалити самостійно.

Готове рішення чи індивідуальна розробка: головне питання

Інженер і автор Martin Fowler ділить програми на два типи. Утилітарні підтримують функції, які мають працювати надійно, але не роблять вас кращими за конкурентів. Стратегічні підтримують те, чим ви виграєте. Для першого типу він радить купувати готовий пакет і підлаштовувати під нього процес, а для другого — не брати те саме ПЗ, що й у конкурентів, бо це забирає змогу відрізнятися (Martin Fowler, Utility vs strategic dichotomy).

Для українського малого й середнього бізнесу це звучить так. Каса, бухоблік, пошта, документообіг — утилітарні функції: у них немає «вашого» способу, є лише правильний. А от як ви приймаєте замовлення, рахуєте індивідуальну ціну, ведете клієнта від заявки до повторної покупки — це часто і є ваша перевага. Саме там готова програма починає заважати, і саме там варто прорахувати автоматизацію бізнес-процесів під ваш спосіб роботи.

Якщо ви вже бачите, що потрібне своє, подивіться усі послуги розробки на замовлення: від окремої інтеграції до повноцінної системи.

Коли вистачить готової програми

Готове рішення — правильний вибір, коли виконано більшість умов нижче:

• Функція однакова в усіх. Чек, накладна, звітність, облік рахунків працюють за правилами, які задає закон або ринок, а не ви.
• Процес ще не усталився. Якщо ви тільки запускаєте напрям і не знаєте, як він працюватиме за пів року, писати під нього код зарано. Готовий інструмент дасть змогу перевірити ідею.
• Готова програма закриває потребу без обхідних шляхів. Тобто люди не ведуть паралельну таблицю «бо в програмі так не можна».
• Є кому її налаштувати й підтримувати. Навіть готова програма потребує людини, яка знає її налаштування.

Добрий приклад — каса. У жовтні 2022 року Державна податкова служба випустила безкоштовний програмний РРО для iOS і вебу та оновила версії для Windows і Android, назвавши його рішенням «переважно для мікро та малого бізнесу» у торгівлі й послугах (Кабінет Міністрів України, 03.10.2022). Тож якщо вам потрібно просто видавати чеки, спершу перевірте готові касові програми, а не пишіть свою.

Те саме з SaaS — програмами, за які платять підпискою і якими користуються через браузер. Як працює ця модель і чому вона зручна на старті, ми розбирали в статті що таке SaaS і як працює бізнес-модель.

Коли варто розробляти під себе

Розробка під себе виправдана, коли програма підтримує процес, яким ви заробляєте, і готові рішення змушують цей процес спрощувати. Ознаки, що ви вже там:

• Дані переносять руками. Менеджер копіює замовлення з сайту в обліковий застосунок, потім — у службу доставки, потім звіряє оплати з банківською випискою.
• Поруч із програмою живуть таблиці. Частина правил (знижки, графіки, розрахунок вартості) існує лише в таблиці чи в голові однієї людини.
• Кожна нова ідея впирається в «система так не вміє». Ви змінюєте процес не тому, що так краще, а тому, що так дозволяє програма.
• Вам потрібен свій продукт для клієнтів. Особистий кабінет, калькулятор, сервіс бронювання з вашою логікою — те, що бачать покупці і чого немає в конкурентів.

Своя розробка — це не лише більші витрати на старті. Вона потребує людей, які розуміють систему, бюджету на підтримку і чіткої постановки задачі. Тому чесне питання до себе звучить не «чи хочемо ми своє», а «чи окупить своє те, що ми втрачаємо зараз на обхідних шляхах».

Третій шлях: готові сервіси плюс своя інтеграція

Часто вибір не бінарний. Каса, облік, банк і доставка можуть лишитися готовими, а розробляється лише те, що їх з'єднує: передача замовлень, оплат, статусів і залишків між системами без участі людини.

Це можливо, бо багато сервісів відкривають свої дані через API — програмний інтерфейс для обміну з іншими системами. Наприклад, у monobank є публічна документація API еквайрингу, де описано створення рахунку для оплати і перевірку його статусу (monobank, API еквайрингу). Сайт чи ваша внутрішня система може створювати рахунок і отримувати статус оплати сама, без менеджера.

Інтеграції між вашими системамиПишемо API і конектори, які з'єднують сайт, облік, оплати й доставку в один процес.

У такому підході важливо домовитися, хто стежить за інтеграцією після запуску: чужі сервіси оновлюють свої API, і код, що з ними працює, теж треба оновлювати. Тому супровід інтеграції — окремий пункт договору, а не «якось потім». У нашій розробці API та інтеграцій оновлення коду інтеграції, коли сторонні платіжні чи логістичні системи змінюють свої API, входить у супровід.

Порівняння за критеріями

Таблиця не дає переможця. Вона показує, за що ви платите в кожному варіанті: у готовому — гнучкістю, у своєму — часом і бюджетом на старті, у змішаному — складністю зв'язки між системами.

Що перевірити до рішення

У готової програми чи SaaS:

• чи можна вивантажити всі ваші дані (клієнти, товари, історія) у відкритому форматі, і як швидко;
• чи є API і що саме через нього доступно, бо без нього інтеграція неможлива;
• що станеться з вашими даними, якщо ви перестанете платити або постачальник закриє продукт;
• де зберігаються дані і хто до них має доступ;
• як змінювались тарифи й умови останніми роками.

У розробки під себе:

• кому належать права на код. Закон України «Про авторське право і суміжні права» охороняє комп'ютерні програми окремою статтею 20, а за його статтею 15 майнові права на твір, створений за замовленням, переходять до замовника з моменту створення твору у повному складі, якщо інше не передбачено договором замовлення (Закон № 2811-IX, ст. 15 і 20). Водночас стаття 430 Цивільного кодексу каже, що майнові права на об'єкт, створений за замовленням, належать творцеві й замовникові спільно, якщо інше не встановлено договором або законом (Цивільний кодекс України, ст. 430). Норми різняться, тож вирішальний — текст договору: перехід прав має бути записаний у ньому прямо, і читати його треба до підписання. Це не юридична консультація;
• чи отримуєте ви доступ до репозиторію, документацію і все, що потрібно, щоб інша команда могла продовжити роботу;
• як влаштовано супровід після запуску: хто виправляє помилки, хто оновлює інтеграції;
• як розбито роботу на етапи і що ви отримуєте після кожного.

У нашій роботі права на код та інтелектуальну власність переходять клієнту повністю, а NDA ми підписуємо до детального обговорення проєкту. Але навіть із нами перевірте це в договорі: правило має бути записане, а не обіцяне.

Чекліст на одну сторінку

Візьміть процес, про який думаєте, і дайте на кожне питання відповідь «так» чи «ні»:

1. Цей процес приносить гроші або відрізняє нас від конкурентів?
2. Готова програма закриває його без таблиць поруч і ручного перенесення даних?
3. Процес стабільний і ми знаємо, як він працюватиме через рік?
4. Готові програми, якими ми вже користуємось, мають API?
5. Ми можемо вивантажити свої дані з поточних програм?
6. У нас є бюджет не лише на старт, а й на супровід?

Якщо на перше питання «ні», а на друге «так», — лишайтеся на готовому. Якщо на перше «так», а на друге «ні», — розробка під себе або своя інтеграція варта розрахунку. Якщо відповіді змішані, почніть з інтеграції: вона прибирає ручне перенесення даних між програмами і не вимагає міняти ті, до яких звикла команда.

Висновок

Готова програма — не компроміс, а правильний інструмент для функцій, які однакові в усіх. Розробка під себе потрібна там, де готове змушує спрощувати ваш спосіб заробляти. Між ними є третій шлях — залишити готові сервіси й з'єднати їх своєю інтеграцією. Буває, що готового інструменту вистачає, — тоді своя розробка не потрібна, а дані між наявними програмами можна з'єднати інтеграцією.

Якщо не впевнені, до якого випадку належить ваш процес, опишіть його нам — обговоримо, що можна лишити готовим, а що варто розробити.

Часті питання

Що дешевше — готова програма чи розробка під себе?

На старті зазвичай дешевша готова програма: ви платите за ліцензію чи підписку, а не за розробку. Чесне порівняння — за кілька років: підписки на кожного користувача, доплати за модулі, ручна робота там, де програма не робить потрібного, і вартість інтеграцій. Своя розробка дорожча на старті й потребує бюджету на підтримку, але не прив'язує вас до тарифів постачальника.

Чи можна почати з готового рішення, а потім перейти на своє?

Так, і це розумний шлях, якщо процес ще не усталився. Умова одна: ви маєте змогу вивантажити свої дані в зрозумілому форматі. Перевірте це до того, як заведете в програму клієнтів, товари й історію замовлень.

Кому належить код програми, розробленої на замовлення?

За статтею 15 Закону України «Про авторське право і суміжні права» майнові права на твір, створений за замовленням, переходять до замовника, якщо інше не передбачено договором. А стаття 430 Цивільного кодексу для об'єкта, створеного за замовленням, називає власниками майнових прав творця і замовника спільно, якщо інше не встановлено договором або законом. Норми різняться, тож вирішує договір: перед підписанням перевірте, що права на код і доступ до репозиторію прямо передаються вам. Це не юридична консультація.

Чим доопрацювання готової програми відрізняється від розробки під себе?

Доопрацювання — це зміни всередині чужого продукту: вони живуть за правилами постачальника, і після його оновлення їх доводиться перевіряти. Розробка під себе — окремий код, який належить вам. Між ними є третій варіант: готові програми лишаються як є, а своя інтеграція з'єднує їх між собою.

Як зрозуміти, що бізнес переріс готову програму?

Типові ознаки: дані між програмами переносять руками, частина процесу живе в таблицях поруч із програмою, а кожна нова потреба впирається у «так система не вміє». Якщо це стосується процесу, яким ви заробляєте, час прорахувати, чи окупиться своя розробка або інтеграція.

Джерела

1. Martin Fowler — Utility vs strategic dichotomy
2. Кабінет Міністрів України — ДПС: нові безкоштовні версії ПРРО для iOS та Android
3. Закон України «Про авторське право і суміжні права» № 2811-IX
4. Цивільний кодекс України № 435-IV
5. monobank — документація API еквайрингу