Що не так із власною розробкою, і чому вона (майже) завжди програє готовим рішенням. Намагаємося розібратися.
Чому компанії, які не є професіоналами в IT, обирають шлях власної розробки? Кожен хороший у своїй справі. Реальні економічні приклади показують, що виконання своєї ділянки роботи та кооперація з іншими фахівцями призводить до більшої ефективності, ніж якщо один намагатиметься робити все. Згадаймо Генрі Форда та його конвеєр.
Але колеги, поясніть, чому так відбувається?! Чому компанія, яка займається виробництвом продуктів харчування або промислового обладнання, починає створювати ERP, CRM-систему тощо?
Останнім часом ми спостерігаємо, що тема власної розробки знову загострилася. Хоча саме явище існує давно і всі кейси, які я знаю, не пов’язані з подіями останнього року і відходом західних вендорів з нашого ринку. І навіть у цьому випадку, коли ваш постачальник більше не може з вами працювати, власна розробка не повинна бути першим варіантом розв’язання проблеми.
Розберемося в причинах того, що відбувається, з холодною головою. Причини пристрастей щодо власної розробки можна розділити на дві групи – політичні та економічні.
Політичний блок
- Причина #1. Я називаю її “син маминої подруги” і довго на ній зупинятися не буду. Мова про втручання, які комусь цікаві, і тому в компанії пишуть своє рішення самі. Просто так комусь було потрібно. Найчастіше ми стикаємося з цим явищем на ринку чат-ботів. Мабуть, вважають, що комунікацію з клієнтом можна доручити кому завгодно.
- Причина #2. Безпека. Бажання мати тільки свій софт і ні від кого не залежати. Насправді незалежність – це міф. До нас приходять компанії, які самостійно розробили систему і потрапили до неї в заручники. Чому так відбувається? Коли ти розробляєш продукт у відриві від ринку, то список завдань, який потрібно реалізувати, формується не під дією реальних необхідних факторів, а під дією внутрішніх сил. І перемагає той, хто з корпоративних замовників, грубо кажучи, застосував більшу силу.
Іноді роблять усе дуже швидко і до того ж такі речі, які в підсумку не використовуються. Багато ресурсів витрачається даремно, на реальному ринку так не відбувається. Часто буває так, що люди, замість того, щоб задуматися над ефективністю, закривають якісь дірки кодом. У підсумку з’являється купа різного функціоналу і милиць. І таке рішення тільки заважає. Система в безпеці, але, водночас, вона не дає змоги розвиватися.
- Причина #3. Команда. Усередині компанії вважають, що вони краще знають, яким має бути рішення. Або ще може бути такий варіант, що бізнес дуже специфічний і жодна система не здатна реалізувати це, і пишуть власні розробки. Здається розумним. Але тільки на перший погляд.
Якщо у вас не IT-компанія і немає сильної IT-практики, то відбуваються дві речі. Перша – з IT-частини: ви не можете зібрати сильну ІТ-команду і правильно організувати процес розробки, і це призводить до того, що немає можливості архітектурно правильно побудувати і реалізувати свій програмний продукт, так, щоб він у довгостроковій перспективі мав підтримку, розвиток, гнучкість, масштабованість.
З одного боку, не ІТ-компанії рідко можуть створити необхідні умови для команди, з іншого боку, продукт народжується поза конкурентним ринком, що також призводить і до неоптимальних процесів розробки, і до неоптимального результату. Але це менше із зол.
Друга велика проблема – персонал. Усередині компанії потрібно створювати HR-функцію для наймання й утримання IT-фахівців, щоб при цьому не потрапляти в залежність від таких співробітників. Адже люди не працюють на одному місці все життя. Але навіть якщо розробники осідають у компанії на роки, то, як правило, вони не розвиваються, і програми, які вони створюють, вельми застарілі.
Так ми знову повертаємося в пункт, коли компанія стає заручником системи, плюс – розпрощатися з розробниками-старожилами дуже складно, вони носять знання про систему у своїй голові і диктують бізнес-замовникам свою волю, безпосередньо вступаючи в конфлікт з інтересами бізнесу.
Політична частина причин мені незрозуміла від слова зовсім – якщо програмний продукт не йде в ринок або не є частиною твого продукту на ринку, то я не знаходжу виправдань для політичного рішення щодо внутрішньої розробки.
Я знаю компанії, які не є айтішними, але частина їхнього продукту – це IT-система, вони мають сильну практику розроблення, вміють наймати персонал і вибудовувати процеси.
Серед наших клієнтів була відома мережа піцерій. Їхній продукт – франшиза і система управління піцеріями. У складі франшизи є інформаційне рішення, яке є значущою частиною продукту компанії. І, звісно, у себе вони тримають власних розробників із відповідними компетенціями.
Або ще приклад – транспортна компанія. Їхній продукт – це IT-сервіс, який об’єднує вантажоперевізників і відправників. У них вибудувана розробка всередині: це їхній продукт і вони його продають у відкритому конкурентному ринку.
Що робити з політичними причинами?
З першою (де “син маминої подруги”), коли комусь просто необхідно впровадити власну розробку, чесно скажу – не знаю. Напевно, таке явище просто має місце бути. Тим компаніям, у яких поширені 2 останні сценарії, можна рекомендувати трансформуватися і ставати якоюсь мірою IT-компанією. У цьому разі потрібно розуміти, що результатом трансформації буде цифровий продукт, який потрібно буде продавати на ринок. Але не CRM або ERP-система для внутрішнього використання.
Якщо ви виробляєте промислове обладнання, то навіщо вам розробляти свої рішення? Так, у вашому обладнанні може бути софт, який керує цим обладнанням. Але, скажімо, CRM – це не частина продукту.
Деякі компанії стверджують, що власна розробка дешевша як на початковому етапі, так і у володінні – ми переходимо до економічного блоку причин.
Економічний блок
Зроблю відступ. Взагалі ідея цієї статті та експерименту, про який ви прочитаєте нижче, з’явилася після одного з наших вебінарів, на який ми отримали рекордну кількість реєстрацій. Вебінар був про чат-ботів зі штучним інтелектом, на нього просто пачками – по 5-7-10 осіб – приходили команди з різних компаній. І коли ми їх запитали, навіщо їм ця інформація, то отримали відповідь, мовляв, дивимося ідеї, а потім самі реалізуємо.
Я задумався – навіщо, це ж дуже дорого. Це окремий застосунок, який не є для компанії основним продуктом, а на нього працює ціла команда. Причому, до нас тоді приходили навіть не розробники, а різного роду менеджери. Продукт-овнери і ось ці всі “красиві назви”. Тобто в реальності до них додасться ще як мінімум кілька людей, які це все будуть руками робити.
Для порівняння: команда розробки одного з наших вендорів, який займається чат-ботами, складається з 12 осіб. Плюс 5-7 менеджерів. І в мене в голові не сходиться. Ось двадцять людей випускають систему на ринок, її вартість розподіляється між усіма клієнтами, які платять за підписку. І якась одна компанія витрачає ресурси понад десятка співробітників на свій побічний продукт – це ж очевидно дорожче. Вони ходять, дивляться кейси на ринку, коли вендор сам такі кейси збирає від найрізноманітніших клієнтів і потім реалізує їх у своєму рішенні.
Який сенс займатися власною розробкою?
Щоб перевірити адекватність цих міркувань, ми провели експеримент. Взяли анонімне ТЗ на CRМ-систему клієнта і порахували вартість. Виявилося, що розробка системи з нуля у 8 разів (!!!) дорожча. Вартість людино-години у нас однакова, але розробка з нуля програє за рахунок більших обсягів і термінів розробки.
Вартість володіння також вища в разі власного продукту. Ми підрахували вартість володіння – щорічні ліцензійні платежі та вартість підтримки. За попередніми оцінками, вартість володіння свого рішення виявилася у 2 рази вищою.
Усі розрахунки показують, що власна розробка дорожча.
За всю свою практику я знаю тільки 2 приклади, коли власна розробка вийшла дешевшою. І обидва кейси – про компанії, у яких була власна сильна IT-складова. І ці кейси були не про вартість, а про швидкість. Вони співставні або дорожчі, ніж передача розробки на аутсорс, але виконані швидше за рахунок внутрішньої роботи. У даному випадку, це мало критичне значення.
В інших випадках – програші за швидкістю, вартістю, надійністю, незалежністю.
До яких висновків ми дійшли?
Якщо розробка не є частиною основного продукту, який компанія поставляє на ринок, то потрібно однозначно шукати варіанти серед готових рішень. Причому варіантів багато, навіть з урахуванням відходу вендорів з ринку. Повірте моєму 15-річному досвіду і сотням проєктів, у базових бізнес-процесах мало унікального, і якщо вам здається, що ви якісь особливі, то, найімовірніше, справа в неоптимальних процесах.
Ваша унікальність – у продукті, який ви постачаєте на ринок, у сукупному клієнтському досвіді, який ви даєте клієнтам, а базові процеси – продажі, облік та інше – не можуть бути критично унікальними.
Якщо софт, який компанія збирається розробляти, є частиною продукту, що виходить на ринок, то перед власною розробкою потрібно розглянути варіанти спершу аутсорсингу, а потім аутстафінгу. Слід поставити собі запитання: чи є компанія IT-бізнесом і наскільки ви професійні в промисловій розробці ПЗ.
Можливо, має сенс передати розробку повністю на аутсорс, якщо ви не маєте багатого досвіду вибудовування та управління повним циклом розробки: від бізнес-аналітики до тестування і постачання коду в роботу. Окремим завданням є вибудовування HR-процесів в ІТ. Якщо ви можете вибудувати процеси розробки, подумайте, можливо, є сенс віддати HR на сторону і розглянути аутстафінг.
Власна розробка – це крайній випадок, коли вам потрібні права на власний продукт і цей продукт поставляється на ринок.
