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

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

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

Строк залежить від стану даних і від того, скільки систем зачіпає інтеграція. Для орієнтира — реальні строки наших проєктів: модель прогнозування відтоку для Edenred зайняла 5 місяців, аналітика та модель відтоку для Планети Кіно — 8 місяців, прогнозування виробництва для «Нових Продуктів» і рекомендаційна система для GoodWine — по 12 місяців разом із впровадженням.

Перевірити гіпотезу на PoC зазвичай можна значно швидше. Точну оцінку даємо після аудиту даних і фіксації обсягу першого етапу.

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

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

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

Масштабування зазвичай іде двома шляхами: розширення на суміжні задачі та категорії — у «Нових Продуктах» перша модель стала фундаментом для інших товарних напрямів — або підключення нових каналів і систем, як у Планеті Кіно, де рекомендації працюють одночасно в push, email і мобільному застосунку.

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

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

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

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

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

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

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

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

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

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

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

Типові напрями — навчання персоналу фармацевтичної компанії за ролями (виробництво, контроль якості, R&D, маркетинг, медичний відділ, дистрибуція), навчання фармацевтичних представників із перевіркою знань перед виходом на територію, окремі програми під кожен запуск продукту та кілька мов в одній системі для міжнародних команд. У фармацевтичній галузі ми вже працювали: перебудували систему звітності для Servier і спроєктували нову архітектуру даних для «Юрія-Фарм».

Так, як сценарії навчання. Платформа дозволяє призначати GMP- та GxP-програми за ролями й підрозділами, повторювати їх за графіком, фіксувати ознайомлення з внутрішніми політиками та SOP із прив’язкою до версії документа й автоматично перепризначати курс усім, кого стосується оновлена процедура. Статус compliance-програм видно в розрізі підрозділу та окремого працівника на будь-яку дату.

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

Так, і в більшості проєктів саме інтеграції дають головний ефект. Єдиний вхід налаштовується через Active Directory, LDAP або SSO, а працівники та структура відділень синхронізуються з кадрової чи HR-системи, тому прийом, переведення й звільнення відображаються в LMS автоматично, без ручного ведення користувачів.

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

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

Це не окрема послуга «після проєкту», а продовження тієї самої роботи: LMS-платформу, яку ми модернізували для провідного банку України, наша команда супроводжує й далі. Обсяг підтримки визначається разом із вами — від базового технічного супроводу до розвитку платформи новими модулями та звітами.

Базовий магазин на готовій темі, з підключеною оплатою, доставкою та заповненим каталогом ми запускаємо за 2–4 тижні. Проєкт із кастомною темою, нестандартною логікою кошика чи інтеграцією з обліковою системою — від кількох тижнів до кількох місяців. Основний чинник тут не дизайн, а кількість інтеграцій і складність бізнес-правил.

Так. Або адаптуємо готову тему під дизайн-систему бренду, або розробляємо custom Shopify theme з нуля на Online Store 2.0 — з повним контролем над версткою та секціями, якими контент-менеджер керує самостійно. Верстка виконується на Liquid. Окремо стежимо за швидкістю: тема з десятками анімацій легко просідає за Core Web Vitals.

Так, ми робимо приватні застосунки для конкретного магазину: робота з Admin API, обробка вебхуків, власні екрани в адмінці через App Bridge, фонові процеси. Типові задачі — синхронізація залишків і цін з обліковою системою, службові звіти, нестандартна обробка замовлень. Це виправдано, коли підписки на кілька публічних апок дорожчі за власний код.

Так. Обмін будується на Admin API (GraphQL) і вебхуках: замовлення, клієнти, залишки, ціни й статуси. Ми інтегруємо CRM (зокрема Salesforce), ERP та облікові системи, платіжні шлюзи, служби доставки, Klaviyo та аналітику. Перед розробкою фіксуємо джерело істини для кожного типу даних, частоту синхронізації та поведінку при помилці обміну.

Так — з Magento, BigCommerce, WooCommerce і кастомних платформ. Переносимо каталог із варіантами й зображеннями, клієнтів, історію замовлень, контент і навігацію. Найважливіший блок — SEO: 301-редиректи зі старих URL, мета-теги, canonical і sitemap. Після переїзду звіряємо дані до й після, контролюємо індексацію та перевіряємо чекаут на реальних оплатах.

Shopify Plus — тариф для великого e-commerce, від 2300 $ на місяць. Ключові відмінності: кастомізація checkout через Checkout Extensibility, expansion stores під різні країни й валюти, вбудований B2B із прайс-листами та умовами оплати, автоматизація через Shopify Flow і Launchpad, вищі ліміти API. Переходити варто тоді, коли магазин реально впирається в обмеження базового тарифу.

Так. Підтримка Shopify охоплює усунення помилок, контроль інтеграцій, моніторинг оплат і доставки, перевірку сумісності додатків після оновлень платформи та підготовку до сезонних піків. Формат — погоджений обсяг годин на місяць або задачі за запитом. Зміни виходять через staging. Наразі на нашому супроводі понад 37 проєктів.