Ключ до проєктів впровадження: керування очікуваннями клієнтів

Оригінал статті: The Key to Implementation Projects: Manage Customers Expectations | Odoo

Я — розробник. Мені подобається створювати код; це весело та інтелектуально цікаво.

Але, як CEO Odoo, я також знаю, що в проєктах впровадження ERP слід уникати кастомних розробок, наскільки це можливо.

Це не так просто, як може здатися, адже клієнтам притаманно думати, що їм потрібні індивідуальні доопрацювання. З іншого боку, компанії, що займаються впровадженням, радо виставляють рахунки за додатковий часі послуг/розробки для цих налаштувань. Але я мушу попередити обидві сторони: кастомні розробки — це не на користь вам!

Чому варто мінімізувати кастомні розробки?

Для клієнтів: кастомна розробка створює додаткові витрати та затримки в графіку проєкту впровадження, іноді це наражає на ризик зриву проєкту. До того ж індивідуальні доопрацювання призводять до технічного боргу, за який вам доведеться платити протягом наступних років у вигляді збільшення витрат на обслуговування та оновлення. Такий технічний борг коштує близько 25% від вартості розробки ЩОРОКУ (~17% на підтримку + ~8% на оновлення).

Кожна розробка може здаватися простою та доступною. Але складність проєкту зростає пропорційно квадрату кількості доопрацювань, а не лінійно. Ви, ймовірно, хочете виправити те, що вам не подобалося у попередньому програмному забезпеченні; але чи не краще стандартизувати ваші бізнес-процеси та впровадити проєкт удвічі швидше й дешевше?

Для партнерів: кастомні розробки зазвичай коштують дорого, але мають низьку цінність для клієнта. Як часто ви оцінювали розробку функції в 10 днів роботи; але клієнт вважав, що це забагато для такої простої функції, тож ви виставляли рахунок лише за 8 днів роботи; але врешті витрачали 12 днів? О, а коли ми згодом виявляємо проблеми чи зміни, тому що ви поспішали, клієнт не платить за додатковий день, бо «це ж ваша провина». Те, що мало бути послугою з маржею 35%, тепер перетворюється на 6% збитку!

Щоб зростати, легше зосередитися на цінних послугах, які мають кращу маржинальність та знижують ризик неоплачуваних годин. До таких послуг належать: керування проєктами, бізнес-аналіз, налаштування без розробки коду, керування змінами та навчання.

Якщо ви не сформуєте менталітет, спрямований на зменшення кастомних розробок, рано чи пізно станете неконкурентоспроможними. Конкуренти, які краще керують очікуваннями клієнтів, матимуть нижчі витрати на впровадження проєктів. Ви коли-небудь втрачали проєкт через те, що клієнт казав: «у вас надто дорого», а потім дізнавалися, що він обійшовсі значно меншим, ніж ви пропонували?

Звісно, кастомні розробки іноді необхідні для ведення бізнесу. Але, з мого досвіду, більшість запитів клієнтів або не варті витрат на них, або стають неактуальними, щойно вони починають використовувати Odoo, або ж вони можуть обійтися без них, оскільки це не є частиною їх основної діяльності. Погодитесь ви на ці запити чи ні? Усе залежить від вашої методології впровадження та менталітету компанії.

Клієнт, ймовірно, ще не є експертом у продукті, й, напевно, не є експертом у проєктах впровадження. Тому він не може легко зважити вартість конкретної функції проти прибутку, який отримає від неї. Запити клієнтів базуються на викликах, які вони мали зі старим програмним забезпеченням або поточним способом роботи. Більшість із цих проблем зникають або втрачають актуальність, щойно вони переходять на використання Odoo.

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

Якщо запитати сервісні компанії, всі вони скажуть вам, що розробляють лише те, що потрібно клієнту (й вони справді так думають). Насправді ж дуже важко оцінити себе об’єктивно та зрозуміти, чи добре ви вмієте оцінювати повернення інвестицій (ROI) та розв’язувати проблеми за допомогою якісного консалтингу замість розробок.

Щоб зрозуміти різні підходи, погляньмо на структуру впровадження двох сервісних компаній.

КЕЙС 1: Якщо в компанії 8 розробників та 2 проєктні менеджери, їх фокус — робити кастомні розробки. Їх методологія, ймовірно, Scrum (або інша гнучка методологія), а їхній проєктний менеджер витрачатиме більшість часу на написання технічних завдань та тестування розробок. Вони задовольняють клієнтів тим, що розробляють, але такий підхід неминуче призводить до збільшення загальних витрат проєкту (звісно, не навмисне).

(Тут ми переходимо до альтернативного підходу та реальних прикладів керування очікуваннями)

Наприклад, я б рекомендував запустити систему в роботу (go into production) без розробки інтеграції з Magento, використати Odoo протягом 3 місяців, а потім переглянути пріоритети й вирішити, чи варто це робити. На той час у вас є 50% шансів, що клієнт настільки полюбить Odoo, що обере Odoo eCommerce замість конектора для Magento. :)

Щодо керування змінами (change management), завжди краще впроваджувати зміни в бізнес-процесах поступово, а не всі одразу. Завдяки модульності Odoo має сенс розгортати систему в кілька етапів:

1. Те, що клієнту абсолютно необхідно для ведення бізнесу.

2. Тільки після переходу до п.1 — інші функції для підвищення ефективності.

Насправді пріоритети клієнта щодо розробки зміняться, коли він почне працювати в системі. Причини:

• Використовуючи програмне забезпечення, вони виявляють нові потреби в розробці, які є важливішими, і змінюють пріоритети.

• Витративши певну суму на впровадження, вони задоволені результатом та воліють скоротити витрати на непотрібні функції.

• Коли клієнт починає використовувати Odoo в реальній роботі, його мислення змінюється, оскільки він набуває експертизи в продукті.

Чи варто це таких витрат?

По-друге, вам потрібно оцінити вигоду: скільки людино-днів на місяць заощадить клієнт завдяки цій функції. Часто клієнт рахує лише час, який він витрачає на це завдання зараз, та скільки, на його думку, він заощадить у майбутньому. Насправді ж йому все одно доведеться вносити всі дані, необхідні для обчислень, обробляти винятки вручну тощо. (Приклад: навіть якщо клієнт розробить конектор для Magento, йому все одно доведеться вирішувати всі конфлікти, фіксувати знижки в обох програмах, розбиратися з розбіжностями залишків, оскільки синхронізація не відбувається в реальному часі, тощо).

Далі потрібно ефективно оцінити вартість. Часто клієнт бачить лише «разову вартість розробки». Насправді ви можете сміливо множити цю вартість на 2 або 3, оскільки потрібно врахувати безліч факторів: час на тестування, виправлення помилок та додаткові затримки в проєкті, адаптацію документації (адже вона вже не стандартна), майбутнє обслуговування та оновлення протягом наступних 5 років.

Зауважте, що використання модуля спільноти (community module) дозволяє заощадити час на початкову розробку, але вам все одно доведеться врахувати у вартості тестування, обслуговування, затримки проєкту та оновлення. Модуль спільноти — це теж технічний борг.

Чи достатньо значний виграш?

Припустімо, у вас є запит на таку кастомну розробку:

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

Коли ви отримуєте запит на кастомізацію, ваш перший рефлекс має бути таким: поставте під сумнів обсяги. Скільки будівельних проєктів ви виграєте на місяць? Припустімо, клієнт отримує 10 таких проєктів на місяць. Створення та оновлення завдань шляхом дублювання та оновлення шаблонів проєктів займає, ймовірно, 10 хвилин.

Чи варто запускати складну розробку, щоб заощадити менше ніж 2 години роботи на місяць? Звісно, ні. Ця функція коштуватиме близько 10 днів розробки, плюс 25% від цього щороку.

Чи можемо ми досягти тієї ж мети іншим шляхом?

Припустімо, у вас є такий запит від клієнта:

«Я хочу синхронізувати наш календар Outlook з Odoo CRM».

Odoo має конектор із Google Calendar у стандарті, але не з Outlook (на момент написання статті). Але розробка та підтримка конектора може коштувати купу грошей. Проте існує безліч сервісів, які синхронізують Google Calendar з Outlook (наприклад, IFTTT). Отже, рішенням може бути підписка та налаштування такого сервісу.

Ви не можете перемкнутися з одного дня на інший; зміна менталітету компанії та методології впровадження вимагає часу. Але якщо ви зможете перейти від 80/20 до 70/30, ви покращите свої маржі. Потім перейдіть до 60/40 — і ви зробите ще один крок уперед.

Моя рекомендація була б такою:

1. Працюйте над своєю методологією впровадження (почніть з нашої, якщо не маєте власної).

2. Збережіть свою команду, але поступово наймайте кількох додаткових бізнес-аналітиків або проєктних менеджерів, які не мають профілю розробника.

Про що варто пам'ятати:

1. Уникайте того, щоб розробники займалися ще й керуванням проєктами. Стати експертним розробником важко, це вимагає років практики. Щоб стати чудовим проєктним менеджером, також потрібен час і досвід. Якщо ви підвищуєте розробників до проєктних менеджерів, ви отримаєте людей, посередніх в обох ролях, а не відмінних в одній; а наявність посередніх PM-ів зашкодить вашим впровадженням.

2. Уникайте залучення розробників до відносин із клієнтами. Розробники можуть зробити все; вони легко знаходять рішення для технічних проблем. Як наслідок, їм легко сказати «Так» на кастомну розробку, оскільки вони не відчувають болю від необхідності керувати нею в бізнес-контексті. Коли в Odoo було лише 10 працівників (переважно розробників), саме цей крок дозволив мені зростати швидше: я почав наймати проєктних менеджерів без знань розробки та краще структурував ролі кожного.

Якщо клієнт обрав Odoo, хіба не тому, що він хоче всі ці налаштування?

Odoo — це дивовижне програмне забезпечення. Просто використовуючи стандарт Odoo, компанія клієнта зазнає масивної трансформації на краще. Більшість відділів стануть ефективнішими, а працівники отримають інструмент для підвищення своєї продуктивності. Саме в цьому полягає цінність; кастомні розробки становитимуть лише 5%–10% функцій, які клієнт використовуватиме на платформі.

Вам слід керувати очікуваннями клієнта, ще до того як робити пропозицію, і клієнт подякує вам за те, що ви ставите під сумнів його запити; це те, чого вони зазвичай очікують від класних проєктних менеджерів. Це дозволить вам зменшити початковий бюджет і бути більш конкурентоспроможними, обмежуючи дорогі розробки, щоб зосередитися на високій маржі, пов’язаній із бізнес-послугами.

Щойно клієнт почне працювати в реальному середовищі й буде задоволений, він із набагато більшою ймовірністю купить більше ваших послуг, оскільки співвідношення ціни та якості у вас чудове. Існує так багато застосунків, які ви можете розгорнути в Odoo, що потенціал майже безмежний, ви завжди можете розширити обсяг робіт.

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

Чи варто розробляти кастомні функції, якщо їх можна повторно використати в кількох «майбутніх» проєктах клієнтів?

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

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

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

Розробка функцій для продажу кільком клієнтам — це бізнес-модель постачальника програмного забезпечення (як Odoo SA), але це зовсім інша бізнес-модель, ніж у сервісної компанії. Це модель, де вам потрібна маржа 80% на ваші продукти, щоб покрити дуже високі витрати на R&D (дослідження та розробку). Це модель, де >50% ваших витрат — це розробники в R&D, які не виставляють рахунки клієнтам.

Ефективна сервісна компанія націлюватиметься на рівень білінгу (оплачуваних годин) близько 80%. Це те, що потрібно для підтримки здорового зростання. Ви не досягнете такого рівня білінгу, якщо матимете змішану бізнес-модель розробки ПЗ та послуг.

Мої вибачення

Я знаю, що такий допис у блозі може не всім сподобатися. Мої вибачення. Я точно не хочу нікого образити. Я просто хочу бути корисним. А щоб бути корисним, я мушу бути прямим і прозорим.

Будь ласка, не читайте цей блог як точку зору «Постачальника ПЗ». Це насправді речі, яких ми навчилися за останній рік у нашому відділі послуг, зосереджуючись на швидкості проєкту та конкурентоспроможності, роблячи те, що ми вважаємо корисним для успіху проєкту, а не те, що ключові користувачі просять нас зробити. Виявилося, що цей відділ послуг став таким же проривним та ефективним, як і наш продукт, настільки, що це стало величезною конкурентною перевагою.

Ділячись тим, чого ми навчилися, я сподіваюся, що це допоможе деяким партнерам прискорити своє зростання, так само як SAP зробив кілька років тому з ASAP, методологією прискореного впровадження SAP. ASAP відіграла значну роль в еволюції SAP та їхній здатності впроваджувати рішення у складних корпораціях у перші роки. Ключовим компонентом їхнього підходу є дотримання стандарту, «найкращих бізнес-практик». Якщо їхній підхід призводить до успішних впроваджень із застарілим продуктом, як SAP, уявіть, що ми можемо зробити з таким дивовижним програмним забезпеченням, як Odoo!

У нас велика партнерська мережа дуже розумних людей. Наша єдина слабкість: ми молодші, менш зрілі. Якщо нам вдасться зрости в зрілості, ми змінимо ринок швидше, ніж будь-який продукт коли-небудь робив це раніше. Ми змінили спосіб роботи 3,7 мільйона користувачів за кілька років. Але щоб досягти 100 мільйонів користувачів, чудового продукту недостатньо; ми маємо побудувати найкращу партнерську мережу, разом.

​

​