Аналіз даних в епоху ШІ: з чого починати замість Excel

Починати аналітику даних із наскрізного курсу «Excel → SQL → Python → BI» більше не варто. Технічну роботу з видобутку й обробки даних тепер бере на себе ШІ. Людині лишилося те, чого модель не зробить сама: розуміння бізнес-процесу і вміння сформулювати, що саме рахувати. Тому починайте з системи показників.

Нижче розберемо, як побудувати її за чотири кроки на прикладі невеликого інтернет-магазину, як формулювати запити до ШІ і який мінімум з інструментів усе ж доведеться вивчити.

Маршрут «спершу Excel, потім SQL, потім Python, потім BI» втратив сенс як стартовий: вивантаження, очищення й обробку даних забрав ШІ. Замість нього працюють чотири кроки: визначте галузь і сценарій, опишіть бізнес-процес, назвіть результат цього процесу, знайдіть показники на кожному етапі. З інструментів потрібен мінімум: поняття показника й розрізу, фільтри й розрахунки, зведені таблиці, з'єднання таблиць і базовий SQL, щоб точно ставити задачу моделі та перевіряти її відповідь. Заглиблюватися в програмування більшості аналітиків не доведеться. ШІ прибирає технічний бар'єр, але не потребу розуміти бізнес.

Короткий словник

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

Чому старий маршрут «Excel → SQL → Python → BI» більше не працює

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

Стіна впала.

Що саме забрав на себе ШІ

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

Що лишилося людині

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

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

З чого починати насправді: система показників за чотири кроки

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

Крок перший: визначити галузь і сценарій

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

Крок другий: описати бізнес-процес

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

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

Крок третій: назвати результат процесу

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

Крок четвертий: знайти показники на кожному етапі

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

Наскрізний приклад: система показників для невеликого інтернет-магазину

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

Від першого дотику до повторної покупки

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

Далі до кожного етапу стає показник. Покази і переходи на першому. Частка відвідувачів, які дійшли до картки товару, на другому. Частка кошиків, доведених до оформлення, на третьому. Частка замовлень, доставлених вчасно, на етапі доставки. І частка клієнтів, які купили вдруге протягом кварталу, на останньому.

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

Де брати дані для кожного показника

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

Як просити ШІ про допомогу: три сценарії та формулювання запитів

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

Класифікація клієнтів і товарів

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

Схема встановлення трекерів для збору даних

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

Узгодження фінансових і операційних показників

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

Різниця між цими двома запитами не в довжині, а в тому, що другий містить процес і склад даних. Загальні правила вибору формулювань розібрані окремо в матеріалі про те, який ШІ-інструмент для роботи обрати.

Дві послідовності аналітичного мислення: гіпотеза перед даними і дані перед гіпотезою

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

Коли починати з гіпотези

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

Коли починати з розбору даних

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

Обидві послідовності сходяться в одній точці: висновок і дія. Практикувати варто обидві на звичних для компанії ситуаціях.

Що з Excel, SQL, Python і BI все ж треба знати — і в якому обсязі

Заголовок цієї статті не означає, що вчити не треба нічого. Він означає, що обсяг змінився.

Показник і розріз: два поняття, без яких не обійтися

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

Мінімум SQL, який окупається

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

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

Чому Python можна відкласти

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

Як перевірити відповідь ШІ, якщо ви не пишете код

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

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

Типові помилки початківця в епоху ШІ

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

Що освоювати далі: готові аналітичні моделі замість програмування

Коли система показників стоїть і на неї регулярно дивляться, наступний крок не в бік коду. Беріть готові аналітичні моделі під конкретні питання. Воронка показує, де відпадають клієнти. Когортний розбір пояснює, чим відрізняється поведінка різних наборів покупців. ABC-розбір ділить товари і клієнтів за внеском. Юніт-економіка відповідає, чи заробляєте ви на одному клієнті. A/B-тест перевіряє зміну, а прогноз попиту допомагає планувати закупівлі.

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

Межі підходу: коли без технічного фахівця не обійтися

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

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

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

Порядок дій на перші тижні

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

Перший прохід зазвичай виявляє, що частини потрібних даних просто немає. Це нормальний результат: він означає, що наступним завданням стає збір, а не аналіз.