ШІ-система управління виробничим процесом фільму

Простої між змінами та зриви графіка зйомок перевантажують команду і зсувають випуск. Ми розробляємо ШІ-систему управління виробничим процесом під ключ: вона показує вузькі місця заздалегідь і скорочує простої в рази. Обговоримо завдання — повернемося з оцінкою та планом.
Часті запитання

Чому зривається графік знімання: вузькі місця AI кіновиробництва

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

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

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

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

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

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

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

AI кіновиробництво: де скорочуються простої та понаднормові

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

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

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

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

Скорочення простоїв на майданчику йде не за рахунок темпу роботи, а за рахунок точності плану: конфлікт видно за добу, а не в момент виїзду.

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

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

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

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

Режими управління виробництвом: від таблиць до предиктивної моделі

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

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

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

Режим Коли підходить Обмеження
Ручні таблиці Один-два майданчики, короткий блок знімання, стабільний склад групи Правку однієї сцени перераховують вручну; конфлікти щодо людей і техніки видно лише до знімального дня
Правила в обліковій системі Зміни повторюються, типи сцен відомі, календар зафіксований Правила описують «не можна», але не пропонують заміну; зсув через погоду розходиться з планом
Локальні автоматизації Вузька задача: виклики групи, підвезення техніки, облік змін Цілісної картини не бачать; кожен виняток усе одно розбирає людина
Предиктивна модель Довгий графік, паралельні майданчики, багато залежностей Потрібні дані за минулими змінами та зривами; рішення моделі доводиться пояснювати групі

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

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

Впровадження системи управління зніманням: етапи робіт

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

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

  1. Аудит виробничого процесу. Відновлюємо фактичну хронологію змін, ланки погоджень і місця, де строки зриваються. На виході — карта процесу з вузькими місцями та переліком даних, яких бракує для планування.
  2. Схема даних і ролей. Фіксуємо, які сутності описують зміну, локацію, групу й ресурс, хто їх заводить і хто змінює. Ролі визначаємо до налаштування, інакше система швидко обростає ручними правками.
  3. Налаштування системи планування. Обмеження щодо доступності людей і локацій, пріоритети та сценарії замін зводимо в єдину розрахункову модель — календар перестає бути набором таблиць.
  4. Перевірка моделі на історичних даних. Проганяємо минулі зміни й звіряємо з тим, що реально сталося: де порядок був би іншим і чому. Розбіжності розбираємо до запуску, а не під час знімання.
  5. Навчання групи. Показуємо адміністраторам і постановникам, як працювати з чергою змін і що робити в спірних ситуаціях.
  6. Передача та супровід. Віддаємо конфігурації, регламенти й документацію, перші тижні ведемо експлуатацію разом із командою майданчика.

Що замовник отримує на руки: конфігурації, схеми, регламенти

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

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

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

Через кілька тижнів після запуску замовник зазвичай править правила сам — ми залишаємося на змінах логіки та розвитку.

Кейс: як виробництво скоротило простої між змінами

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

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

Що змінили

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

У разі зміни вхідних умов система за хвилини пропонує нові варіанти, показує ціну правки — зсув сцен, понаднормові групи, простій — і зберігає попередню версію плану для відкату. Цей контур усередині назвали «Ритм».

Метрики до і після

Збирання тижневого плану скоротилося з чотирьох годин до 20–30 хвилин. Частка змін із понаднормовими впала з 28% до 8–10%: система заздалегідь показує, де день виходить за ліміт.

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

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

Чим предиктивне планування відрізняється від календарного?

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

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

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

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

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

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

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

Питання інженерів: інтеграції, дані, підтримка

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

Зв’язка йде через програмні інтерфейси та вивантаження в табличних форматах, довідники зіставляються за стійкими ключами, а не за назвами — інакше «Майданчик №2» і «Павільйон 2» стають різними об’єктами й ламають розрахунок. Перший контур запускаємо в режимі лише читання: система радить, рішення залишаються за людьми.

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

На рваній історії не будуємо прогноз — накопичуємо дані на поточному проєкті й поступово розширюємо горизонт.

Чи сумісно це з поточним обліком, чи доведеться змінювати систему?

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

Що робити, якщо історія велася неохайно?

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

Як система працює на майданчику без стійкої мережі?

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

Хто відповідає за коректність даних і підтримку планування?

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

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

Обговоримо задачу: що потрібно для старту робіт

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

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

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

Напрямки AI-розробки

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1543
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1374
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142