Популярні питання

Перша зустріч – це відверта розмова. Ми ставимо питання про бізнес-контекст, поточні проблеми та очікуваний результат, ви розповідаєте про своє бачення. На виході маємо розуміння з обох сторін, як підійти до задачі.

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

Lakehouse поєднує принципи data lake і data warehouse: дає змогу працювати з великими масивами різнотипних даних і водночас підтримувати структуровану аналітику. Але універсально кращого варіанта немає: вибір між data lake, data warehouse і data lakehouse залежить від типів даних, задач аналітики та вимог до архітектури.

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

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

Підтримка після релізу – окремий напрямок роботи. За потреби підписуємо SLA і беремо відповідальність за uptime, усунення багів та оновлення. Формат залежить від проєкту: десь потрібна реакція протягом години, десь достатньо регулярного перегляду логів раз на тиждень. Тривалість теж гнучка: від кількох місяців до довгострокового супроводу.

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

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

RLS обмежує доступ до окремих рядків моделі даних залежно від ролі користувача. Тому один і той самий звіт може показувати різні дані різним людям.

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

Створіть RLS-роль, задайте правило фільтрації, протестуйте його, опублікуйте модель і призначте користувачів або групи до ролі в Power BI Service. Окремо перевірте їхні права в робочому просторі та доступ до звіту.

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

У внутрішніх системах обмежуємо доступи та впроваджуємо багаторівневу авторизацію. У BI ізолюємо середовища і контролюємо права аж до рівня окремих дашбордів. В e-commerce – захист API, шифрування платежів, аудит трафіку. Працювали з банками, держструктурами та юридичними компаніями, де вимоги до безпеки особливо жорсткі.

У статичному RLS правило фільтрації закріплене за роллю. У динамічному воно може змінюватися залежно від користувача, наприклад через USERPRINCIPALNAME() і таблицю відповідності.

Для цього використовують RLS Power BI: правила моделі визначають, які дані побачить користувач після входу.

У Power BI Desktop використовуйте View as, щоб перевірити звіт від імені ролі. Після публікації роль також можна протестувати у Power BI Service.

Типові помилки: помилка в DAX-фільтрі, некоректно призначені ролі робочого простору, застаріла таблиця відповідності та спроба замінити RLS звичайними фільтрами у звіті.

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

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

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

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

Здебільшого це або інструменти для внутрішньої роботи компанії, або продукти, з якими взаємодіють клієнти чи партнери. Перші – це системи управління, облікові платформи, інтеграційні рішення між існуючими сервісами. Другі – веб і мобільні додатки, партнерські портали, e-commerce. Часто одне переплітається з іншим: наприклад, платформа для дистриб'юторів, яка всередині підключена до ERP і аналітики. Конкретний набір завжди залежить від того, який процес треба вирішити.

Від складності та обсягу. Інколи MVP можна зібрати за місяць, а повноцінну систему за декілька місяців. Якщо потрібна глибока інтеграція або розробка складної аналітики з нуля, терміни довші. Розробка завжди розбивається на фази, і перші результати з'являються раніше, ніж проєкт завершується повністю.

Починаємо з Discovery-етапу. Тут ми разом з'ясовуємо реальну задачу, обмеження і критерії результату. Це точка, де ми перевіряємо, чи правильно сформульована задача, перш ніж починати її вирішувати.

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