Март 19

Customer journey з погляду бізнес-аналітика. Як зацікавити клієнта

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

За більше ніж 9 років досвіду в бізнес-аналізі у мене назбиралося багато інсайтів. Нині я співпрацюю з ЕРАМ Ukraine і відповідаю за проєкти у банківській сфері. Займаюся моделюванням, підготовкою та координацією процесів аудиту інфраструктури підприємств, впровадженням рішень RPA тощо.

Customer journey з погляду бізнес-аналітика чи Product Owner — це пошук найкращого рішення для розв’язання проблем клієнта. І це процес, який може тривати місяці. Адже потрібно зрозуміти домен замовника, потреби його бізнесу, виявити прогалини в наявних процесах, запропонувати нові рішення, затвердити їх. Потім продукт треба правильно проштовхнути на ринок і пересвідчитися, що все запрацювало так, як було передбачено. А згодом ще й проаналізувати, що в підсумку отримує клієнт. Понад те, якщо ви заходите до клієнта як бізнес-аналітик, то маєте бути готові запропонувати йому не тільки дієве рішення, а й збільшити дохід.

З мого досвіду клієнти бувають двох типів:

ті, які знають, що потрібно щось поліпшити, але не знають, як і що саме;
ті, які розуміють, що саме хочуть змінити, їм потрібно лише допомогти.

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

Якщо ж досвіду у вас менше, то з другим типом клієнта працювати буде легше. Принаймні спочатку вас «проведуть» до того, що варто зробити. Проте як з першим, так і з другим типом ВА буде проходити ключові етапи customer journey, і від того, наскільки якісно ви пропрацюєте їх та погодите із замовником, буде залежати кінцевий результат. Я не буду зосереджуватися на очевидних речах, про які можна прочитати в ВАВОК, проте поділюся своїми думками про те, на що варто звертати увагу під час customer journey.

Ключові етапи customer journey з погляду BA

Awareness and Engagement

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

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

Розкажіть про ваш бізнес.
Що вам подобається та не подобається у ньому?

Скажете, що банально? Проте цей підхід працює у 90% випадків. У мене не спрацювало лише одного разу, коли клієнт був не налаштований на взаємодію, проте головний стейкхолдер потребував змін у бізнес-процесах (зрозуміти настрій, позицію та «політику» клієнта — складне завдання і тема для окремої статті).

Коли ви з’ясували проблему/складність/потребу та маєте розуміння бізнес-процесів, вам потрібно розібратися в очікуваннях. Іншими словами, що, на думку замовника, має бути зроблено, щоб проблема була вирішена та які є обмеження (за ціною, часом, технологіями тощо).

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

Здебільшого на цьому етапі бізнес-аналітик йде працювати над пропозиціями. Але якщо так сталось, що ви ще й трохи менеджер і/або менеджера з вами немає, а клієнт хоче максимально докладну пропозицію з командою та оцінкою (estimations), обговоріть стандартний трикутник: cost — time — quality.

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

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

Крім того, на етапі Awareness ми визначаємо, чи це має бути застосунок, чи просто бекенд-процес, на який не треба нічого «навішувати». Якщо це має бути UI, то відразу приєднуємо до процесу дизайнера. Він паралельно з ВА чи РО працює з клієнтом та валідує візуальні рішення з погляду кінцевого користувача. Саме дизайнер допомагає РО зробити бенчмаркетинг чи маркет-аналіз, зрозуміти, чи є аналоги на ринку, якщо такі є, то які в них плюси/мінуси тощо.

Після того як ми ознайомилися з проблемою клієнта, маємо її структурувати, задокументувати та перевірити із замовником. Забігаючи наперед: валідувати інформацію з клієнтом необхідно настільки часто, наскільки це можливо. Особливо для недосвідчених ВА чи РО.

Результати цього етапу: SWOT analysis, Benchmarking results, Product high level overview.

Proposal and Consideration

З клієнтом ми познайомилися, з’ясували, над чим будемо працювати, а тепер до роботи. Варто підготувати необхідні документи, більш деталізоване бачення рішення та обсяг робіт. Обговорюємо це все із замовником. Коректуємо. У результаті починають вимальовуватися epics and features.

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

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

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

Архітект, знаючи все вищеперелічене, може оцінити в людино-годинах витрати на розробку продукту. А це стає точкою відліку для формування зобов’язань клієнту та набору команди. І не варто забувати, що будь-яка оцінка має відхилення 60%, тому якщо архітект каже, що продукт можна зробити за 20 тижнів, то він може бути зроблений як за 8, так і за 32 тижні.

Результати цього етапу: Vision and scope, High level decomposition and estimation.

Solution implementation and Delivery

Далі — розробка самого продукту.

Увага! Якщо ви відкрили цю статтю, щоб прочитати про техніку customer journey, саме на етапі імплементації не забувайте іноді в неї поглядати, щоб переконатися щодо правильності напрямку розробки продукту.

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

У мене був досвід на одному з проєктів, де бізнес-аналітики протягом двох років робили застосунок, що мав задовольнити потреби рекрутингу і ресурс-менеджменту. Тобто це і найм нових людей з ринку, і управління спеціалістами, які вже працюють у компанії. Мене долучили до проєкту на стадії UAT. Ми проводимо UAT, а користувачі постійно запитують: як це зробити? А чому такої функціональності немає?

І коли я почала розбиратися, чому ж не працює продукт так, як потрібно, то виявилося, що під час з’ясування вимог велику групу користувачів просто не спитали про те, які задачі вони вирішують. Колеги довірилися уявленню менеджера про роботу свого відділу. Як зазвичай трапляється, керівник відділу ніколи не працював з самим функціоналом і не вирішував операційних задач. Він розумів процеси тільки на своєму вищому рівні й не замислювався про деталі, бо це не є його зона відповідальності. У результаті значну частину функціоналу упустили. А доробляння до рівня, коли продукт можна запустити на продакшн, зайняло ще 6 місяців.

Результати цього етапу: Standard BA artifacts (User Stories, Use Cases, Release Notes, etc.).

Postproduction and Retrospective

Отже, продукт розроблений, у продакшн вийшли. Треба переконатися, що він працює. Зазвичай цифри важливіші за 1000 слів. Тому рахуємо метрики. Які саме — залежить від продукту. Якщо це сайт, то необхідна статистика відвідуваності, профіль аудиторії, співвідношення кількості купівель до кількості заходів на сайт тощо. Проте якщо ваш продукт спрямований на оптимізацію процесів, то необхідно виводити порівняльні метрики, наприклад: співвідношення часу на опрацювання запиту до і після впровадження нової системи. Для автоматизованих процесів (типу RPA) основною метрикою залишається ROI.

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

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

Результати цього етапу: Metrix, lesson learned, User guides.

Корисні інструменти для побудови customer journey

Кожен користується своїми інструментами. Хтось малює в майндмепі, хтось створює Visio-діаграми, а хтось має чек-лист в Excel. Мені найзручніший OneNote. Там я маю поділені комірки за ключовими секціями. Коли вони заповнені, експортую їх у PDF-файл і маю готовий артефакт.

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

Де найчастіше припускаються помилок

Нижче — список причин, через які часто не вдається виявити помилки ще до стадії розробки:

Не зовсім правильно прокомунікували з клієнтом (всі ми люди зі своїми контекстами). У мене був випадок, коли новому аналітику на проєкті доручили розробку процесу, а вже під час демо виявили, що завершальні 20% упущені. Довелося швидко доробляти. Хоча помилка виявилася радше на стороні клієнтів, які забули розповісти про завершальний етап.

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

Недостатньо якісно провели бенчмаркетинг. Якось ми запустили новий напрям готівкового кредитування у банку, яке лобіював новопризначений директор. Продукт видався непоганий, але фактично ідентичний до продукту конкурента. Лише завдяки вдалому маркетингу він запрацював, проте перші зміни почали вносити аж через тиждень.

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

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

Будь-який консалтинг потребує декілька поглядів, наприклад ВА чи власника продукту, а також Solution Architect чи техліда. Це допоможе мінімізувати ризики некоректного розуміння потреб клієнта.

Як пересвідчитися, що правильно зрозуміли клієнта

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

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

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

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

Як правильно обрати стейкхолдерів і провести аналіз

Як я уже зауважувала, стейкхолдерів ми визначаємо на стадії Consideration. Переважно із СЕО обговорюємо перелік ключових людей, з якими варто поспілкуватися. Коли вже знаємо потреби клієнта, даємо пропозицію. Проте щоб її провалідувати та отримати більше інформації, збираємо представників зацікавлених сторін. Вони мають дати головні орієнтири (primary points). Далеко не завжди директор департаменту, з яким вас сконтактував СЕО/СІО/VP, є власне тим носієм «сакральних» знань.

У мене був випадок, коли ми розробляли disaster recovery процедуру та не могли зрозуміти, як працює одна з критичних систем компанії та хто за неї відповідає. VP of Infrastructure Office намагався це згадати та відправив мене до людини «А». Працівник «А», не маючи уявлення, про що я у нього питаю, відпровадив мене до працівника «Б». І так мої пошуки відповідального закінчились на «Д». І схожі колізії не рідкість, бо складно пам’ятати усіх, хто звільнився, змінив напрям роботи тощо.

Що робити, якщо різні стейкхолдери кажуть різне

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

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

Півтора року тому до мене як до делівері-менеджера проєктів звернувся клієнт з проханням допомогти завершити тестування системи, яку вже рік розробляють, бо «щось в них не йде». Знайшли досвідченого тестера, і вже за кілька тижнів він почав натякати, що бізнесове рішення не життєздатне через певний перелік обмежень тієї In the Box платформи, яку вони використовують. Ми порадились з девлідом і написали РоС своєї платформи, яка покриватиме потреби клієнта і водночас буде гнучкою до змін. У результаті у нас +2 позиції та чудова платформа, яка вже 8 місяців у продакшені і стала стратегічним продуктом клієнта.

Висновок

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