Существует немало сфер, в которых нет места разнообразным “Ой, забыл” и “Я писал, а они не ответили”. Просто потому, что на выходе бизнес-процесса должен бесперебойно появляться востребованный продукт, и никаких задержек с этим быть не может. Одна из таких сфер – телевизионное производство: с какими бы сложностями не столкнулась компания и как бы ни старались подвести ее поставщики и подрядчики, включивший телевизор зритель в любом случае должен увидеть качественный и ожидаемый контент.

Сегодняшний гость нашей постоянной рубрики Рассказ от первого лица, руководитель отдела производственной автоматизации компании PikeMediaLab Генрих Петров, знает об этом не понаслышке. И это делает опыт организации этого процесса в ПланФиксе, которым он с нами делится, особенно интересным.

Генрих Петров: Пролог или коротко о нас. Наша компания «ПайкМедиаЛаб» занимается комплексным обслуживанием телевизионных каналов. В настоящее время мы проводим техническую подготовку для более чем 20 телеканалов, вещающих как в России, так и за рубежом. Среди наших клиентов каналы «Мульт» и «МультиМузыка», «Настоящее страшное телевидение» и «Страшное HD», «Русский роман» и «Русский бестселлер», «Моя планета» и «Наука 2.0», и другие.

Как у любого бизнеса, у нас есть множество различных типов задач – производственных, финансовых, юридических, задач по техническому обслуживанию и делопроизводству. Еще три года назад мы решили использовать для управления этими задачами систему автоматизации, и, опробовав пять разных решений, мы остановились в конечном счете на ПланФикс.

Почему ПланФикс?
Во-первых, идеология ПланФикс оказалась достаточно гибкой и позволила нам решать задачи как по управлению производством и проектами, так и по управлению документооборотом.

Во-вторых, построить адаптированную под собственные задачи систему здесь можно без привлечения программистов.

Мы перенесли в ПланФикс не только производственные задачи, но и создали на его базе систему электронного документооборота и внутреннюю службу технического сопровождения. Конечно, не все ещё отлажено до идеала и процесс «доработки напильником» будет длиться ещё некоторое время, но прогресс очевиден.

Дальше я постараюсь без излишней специфической терминологии рассказать и показать, что же у нас получилось.

 

Задачи
Мы определили следующий список задач, которые должны выполняться системой:

• Контроль производственных процессов
  • Проведение ОТК и редакторского отсмотра; подготовка эфирных версий
  • Подготовка сеток вещания; подготовка рекламных и эфирных плей-листов
  • Производство промо материалов
• Электронный документооборот
  • Согласование договоров, доп.соглашений и т.п. документов
  • Хранение промежуточных и финальных версий в редактируемом и сканированном форматах
  • Согласование и проведение заявок; оплата счетов
• Ведение заявок на техническую поддержку
• Сбор статистики и расчет KPI по выполненным задачам
  • Количество или объём
  • Затраченное время и вид операции
  • Количество возвратов на доработку

Подготовка внедрения
Сам процесс подготовки внедрения виделся так:

1. Создание структуры проектов и задач (дерево навигации)
2. Определение необходимых доп.данных в системе
   a. Создание пользовательских справочников
   b. Создание доп.полей проектов и задач
3. Формирование шаблонов
   a. Проектов
   b. Задач
   c. Повторяющихся задач
4. Создание виртуальных почтовых адресов
5. Статусы
   a. Формирование статусных моделей для процессов
   b. Построение автоматических сценариев
6. Настройка автоматических сценариев
7. Заполнение данных
   a. Структура компании
   b. Пользовательские справочники
   c. Контрагенты
8. Пользовательская настройка
   a. Фильтры
   b. Планировщики
   c. Отчёты

Внедрение производственных задач
Итогом нашей работы является то, что каждый зритель видит на экране своего телевизора, поэтому весь производственный процесс подготовки идеально выстроен хронологически. Итог работы – эфирный плей-лист – должен быть сдан в чётко определенное время, ни раньше, ни позже, а каждый из этапов имеет определенную длительность. Это очень похоже на конвейер.

Начинается процесс примерно за 2-3 недели до начала недели вещания с подготовки расписания (по сути – той самой программы передач, которая публикуется практически всеми телеканалами в различных СМИ).

Затем происходит подготовка медиафайлов основных событий (фильмов, программ и т.п.). Файлы проходят технический контроль и редакционную подготовку, происходит разметка под вставку рекламы (куда ж без этого «двигателя»).

На следующем этапе формируется рекламная сетка, простым языком – определяются места и длительность рекламных блоков. Такая рекламная сетка отправляется в рекламное агентство, где происходит заполнение блоков уже фактическими рекламными роликами. Итогом такого заполнения становится рекламный плей-лист, который рекламное агентство присылает нам.

На последнем этапе подготовки рекламный плей-лист импортируется в эфирный день, размещаются различные анонсы, графика и прочая мелочёвка.

По окончании подготовки плей-лист телеканала отправляется в вещательный комплекс, где он проходит финальную проверку.

В общем-то все просто. Однако, каждый из этапов содержит большое количество проверок и различных согласований, в том числе с клиентами или партнерами. При этом на каждом из каналов существуют свои, индивидуальные правила, касающиеся каждого из этапов подготовки.

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

Со статусами мы допустили небольшую ошибку: не учли, что количество статусов ограничено тарифным планом и его нельзя увеличить как, например, количество сотрудников или объём дискового пространства, поэтому делали уникальные статусы под каждый процесс. Впоследствии пришлось некоторые статусы сделать более универсальными и применять один и тот же статус в различных процессах. Например, изначально проверочные статусы были у каждого процесса свои. В последствии оставили один «На проверку». При этом данный статус в одних процессах направлял задачу руководителю подразделения, в других – партнеру или клиенту.

На текущий момент у нас используется 84 статуса (хотя думаю, что можно еще немного оптимизировать). Есть универсальные, есть статусы под конкретные процессы.

 

Следующим этапом подготовки стало формирование пользовательских справочников:

• Телеканалы
• Типы договоров
• Предмет договора
• И несколько специализированных справочников, например, по типам брака для входящих медиафайлов.

Почему именно справочники? Если при формировании шаблона задачи необходимо создать дополнительное поле с заранее известными значениями, то предпочтительнее использовать справочники, даже если значений в нём будет всего 2-3, потому что:

• это экономит время сотруднику при создании задач;
• это позволяет избежать опечаток и ошибок при заполнении;
• это позволяет в дальнейшем на основе данных такого поля строить фильтры задач, использовать в планировщике или отчёте, не опасаясь опечаток или ошибок.

Ещё один специализированный справочник – типы работ. В нем описаны все возможные типы работ для каждого подразделения и эти данные используются сотрудниками при формировании аналитик о фактическом времени работы (об этом подробно будет далее).

 

Следующим этапом было определение под какие задачи требуются специальные шаблоны, построение таких шаблонов и создание повторяющихся задач.

Как уже отмечено выше, процесс подготовки вещания похож на конвейер, где часом ноль является момент сдачи плей-листа в эфирный комплекс и каждая операция проходит в четко заданный промежуток времени. Описание всех процессов займет много времени, поэтому остановимся на подготовке эфирных плей-листов.

Сначала был создан шаблон задачи и настроено доп.поле “Выбор телеканала” ссылающееся на справочник.

 

Затем на основе шаблона созданы повторяющиеся задачи для каждого телеканала.

Настроено создание подзадачи у основной задачи подготовки:

• формирование рекламного плей-листа для отдела трафика. Задача формируется в момент создания основной задачи.
• вещание канала. Задача создается в момент перевода основной задачи в определённый статус.

Назначений у подзадач несколько.
Во-первых, задачи идут по своим статусным моделям и сценариям.
Во-вторых, уменьшение количества почтовых уведомлений у участников. К сожалению, на текущий момент уведомления об изменении статуса задачи нельзя настроить так, чтобы по одному статусу уведомления присылались определённой группе участников, а по другому статусу – нет.

 

 

В итоге у нас получилась следующая схема:

1. За 7 дней до даты вещания автоматически создаётся основная задача пока без подключения исполнителей.
2. Тут же создается подзадача по формированию рекламного плей-листа.
3. Отдел трафика (занимается рекламой) ведёт подзадачу – принимает данные от рекламного агентства, добавляет внутреннюю рекламу, корректирует, согласовывает и т.д.
4. По завершении подзадачи рекламного плей-листа автоматическим сценарием изменяется надзадача – в неё добавляются исполнители – отдел планирования. При этом подзадача по формированию рекламного плей-листа должна закончиться не позднее, чем за 3 дня до даты вещания.
5. Далее основную задачу ведет отдел планирования. Формируется, проверяется и согласовывается эфирный плей-лист.
6. По окончании подготовки основная задача переводится в определённый статус и по этому статусу автоматическим сценарием создается подзадача для специалистов эфирного комплекса, по которой они понимают, что электронный плей-лист можно брать в работу. Дополнительно в этой же подзадаче выкладывается печатная версия эфирного плей-листа в формате Excel.
7. Специалисты эфирного комплекса проводят свои проверки, уведомляют о результатах проверок и проводят вещание эфирного дня телеканала, по окончании которого переводят свою подзадачу в статус «Выполненная».
8. По этому статусу у основной задачи автоматическим сценарием меняется статус для импорта специального лога о фактическом прохождении событий в эфире телеканала. Сотрудник отдела планирования сверяет данные о запланированном порядке выхода событий в эфире т/к с фактическим и готовит специальный отчёт.
9. Руководитель отдела планирования закрывает задачу.

В дальнейшем для удобства были настроены фильтры и планировщик на котором видно всё движение задач

Настроены аналитики затраченного времени и отчёты, по которым видна загрузка сотрудников отдела и количество задач, возвращенных задач на доработку исполнителем (по статусной модели).

 

Путем незначительных манипуляций с Excel получается финальный отчёт по отделу показывающий детальную статистику, в которую можно добавить коэффициенты сложности операций и получить KPI сотрудника.

А вот так выглядит планировщик в эфирном комплексе

 

Создание электронного документооборота
Пожалуй, самым сложным был именно этот этап. Собственных знаний процессов не хватило, поэтому большое спасибо нашим финансистам и делопроизводству за терпение и уделённое время)).

Типов договоров в нашей компании немного. Всего три:

• АХО (административно-хозяйственные)
• Технические
• Производственные

С АХО и Техническими проблем не возникло. А вот производственные договоры добавили нам несколько непростых часов и даже дней размышления. По итогам, финальный вариант работоспособен, но не идеален. Пожалуй, основным минусом является большое количество уведомлений пользователям, но пока вариантов улучшить данное решение мы не нашли.

Сложность заключается в том, что у нас несколько вариантов производственных договоров в зависимости от количества оказываемых услуг. Некоторые каналы у нас идут по полному циклу сборки от А до Я. Некоторые только по каким-либо составляющим, например, только по подготовке контента или по хранению медиафайлов или по рекламному сопровождению.

Соответственно, в каких-то из договоров требуется согласование руководителей всех производственных подразделений, в каких-то только части, а в каких-то нужно согласовать всего с одним. Плюс, хотелось построить универсальный шаблон. Исходя из этой логики был создана вот такая конструкция.

Тип договора и Предмет договора – это поля со ссылкой на соответствующие справочники. Тип – это уже перечисленные три варианта. Предмет договора – это перечень услуг:

Поле «Регулярная отчетность» управляет автоматическим созданием подзадач по закрывающим документам (будет описано ниже).

Поле «Требуется загрузка в Директум» влияет на переход по статусной модели (у одного из наших клиентов установлена система “Директум” и мы обязаны загружать туда документы, ждать согласования и только потом отправлять их на подписание руководителями компании).

Далее логические поля согласования по отделам. Фактически, где флаг установлен, в тот отдел попадет этап согласования.

Первое поле «Требуется проект договора» отвечает за наличие/отсутствие черновика договора. Если его нет – задача попадает к юристам для его создания, а уже затем запускается процесс согласования.

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

Поле «Связанные задачи». По существующей логике ПланФикса, напрямую можно настроить взаимодействие у связки надзадача-подзадача. Можно настроить связь между задачами, находящимися в одном проекте. Но никак нельзя связать задачи из разных проектов.

В нашей модели, в основном это касается технических договоров и связано с профессиональной деятельностью, финансистам иногда требуются дополнительные сведения – для какой цели заключается тот или иной договор. От этого зависит как правильно поставить оборудование или ПО на бухгалтерский учёт и т.п.

Именно в задачах технической дирекции происходит полное описание проекта,внутреннее обсуждение, корректировка, подводятся промежуточные итоги. Бывает и так, что проект один, а договоров на этот проект несколько. Или они могут быть от разных подрядчиков.Или от одного подрядчика, но разные по типу – например, отдельный договор на лицензирование и отдельный договор на работы.

Поэтому схему построили именно так – в задачах тех.дирекции детали какого-либо проекта, а в задаче договора ссылка. Не совсем изящный вариант – но он работает.

Вот так выглядит статусная модель

Некоторые статусы никуда не ведут – это связано с тем, что переходом управляют автоматические сценарии, которые направляют задачу в зависимости от начальных условий.

Вот так выглядят автоматические сценарии при создании задачи. Эти сценарии отвечают за добавление в качестве участников руководителей производственных подразделений, у которых установлены флаги согласования.

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

Вот так выглядит список автоматических сценариев при изменении задачи (увы, все не уместились).

Задачи этих сценариев также не сложные, они перенаправляют задачу последовательно от одного согласующего к другому. Просто их получилось много и чтобы не запутаться – пришлось даже ввести нумерацию в названии.

 

Таким образом был построен процесс последовательного согласования документов и получения подписанных экземпляров.
Выглядит процесс так:

1. Создание проекта (черновика) договора
2. Согласование технических параметров медиафайлов (при необходимости)
3. Согласование производственных подразделений
   a. Отдел программирования детских и развлекательных каналов
   b. Отдел программирования познавательных каналов
   c. Отдел трафика
   d. Отдел приёма и обработки контента
   e. Отдел промотирования
4. Согласование административных служб
   a. Бухгалтерия
   b. Финансовый отдел
   c. Юридический отдел
5. Согласование с контрагентом
6. Согласование и подписание руководством компании
7. Отправка подписанных экземпляров контрагенту
8. Ожидание подписанных экземпляров
9. Загрузка подписанных сканированных копий
10. Перевод задачи в статус «Действующий договор» или «Завершённая»

В финале мы получаем раздел системы, где хранятся все договоры, в редактируемом виде (Word) и отсканированная подписанная версия.
Ну а настроенный планировщик дает возможность всем участникам процесса отслеживать на какой стадии находится определённая задача.

В случае, если у задачи стоит флаг «Регулярная отчетность», то при переводе в статус «Действующий договор» сценарием создается подзадача по формированию закрывающих документов за текущий месяц. В дальнейшем, когда одна подзадача завершается, по ее закрывающему статусу создается новая на следующий период.

По аналогии были созданы процессы по формированию расходных договоров и согласованию счетов, которые идут без договора.

Создан процесс регистрации входящей и исходящей корреспонденции.

Настроен проект по ведению графика встреч компании.

Отдельно несколько слов о проекте ведения задач технической дирекции, как одного из самых значимых подразделений.
Проект состоит из:

• Проекта задач руководства Технической дирекции
  • План-графика бюджета Технической дирекции
• Проектов внутренних задач подразделений
  • По технической поддержке офисной и производственной части
  • По ведению задач инженерного состава эфирного комплекса

Шаблон по задачам руководителей ТД и бюджета выглядит следующим образом.

В принципе, ничего уникального. Код бюджета – справочник, строка – порядковый числовой номер, в текущей версии заполняется руками, так как на момент внедрения бюджет уже был сформирован, в дальнейшем прикрутим автоматическую считалку последовательно прибавляющую +1 к последнему значению. Кстати, такой же принцип работает при регистрации входящей корреспонденции.

В этих задачах происходит полное описание проекта, его обоснование, поставленные цели, ТЭО и т.п. информация.

Задачи в данном проекте являются головными задачами имеющими множество многоуровневых подзадач, некоторые из которых должны быть включены в планировщик, другие нет. Поэтому для включения задач в планировщик есть поле с флагом «Включить задачу в план-график».

 

 

Для удобства проведения летучек в этом проекте настроен процесс «Последний комментарий», который по пятницам рассылает напоминание по задачам со статусом «В работе».

 

В самом шаблоне сделано текстовое поле «Последний комментарий» и настроен сценарий, который при добавлении действия в задачу копирует текст комментария в поле.

Таким образом в планировщике отображается последний комментарий по задаче.

На практике это выглядит так. В пятницу во второй половине дня рассылается автоматическое уведомление (напоминание). Сотрудник, получивший такое уведомление, пишет комментарий с краткими итогами по задаче. И в понедельник утром уже не нужно вспоминать – все кратко отображено на экране.

***

Описать весь используемый функционал в рамках одной статьи практически невозможно – получилось бы много и нудно. Процесс внедрения занял около двух месяцев начиная от написания ТЗ до рабочей версии силами собственной команды без привлечения каких-либо специалистов. В ближайших планах прикрутить 1С бухгалтерию и получать в бюджетных задачах информацию по оплате. Ну а в будущем – идей много, посмотрим…

Генрих Петров 

Заместитель технического директора

 

 

 

P.S. Поделитесь своим опытом использования ПланФикса – наверняка, у вас есть интересные решения и полезные лайфхаки, с которыми интересно будет познакомиться многим нашим читателям. Присылайте свои истории в нашу Службу поддержки с темой “Рассказ от первого лица”, я с удовольствием их опубликую.