Как редакция «ФедералПресс» искала идеальный софт

Все редакции, особенно большие, рано или поздно сталкиваются с проблемой системы управления процессами. В штате медиахолдинга «ФедералПресс», например, больше 100 человек: первые трудности в управлении и согласованности действий команды мы стали испытывать, когда наш штат перевалил за 40 человек. В большой команде оказалось непросто контролировать загрузку каждого сотрудника, сроки решения задач, учитывать время выполнения редакционных заданий.

К тому же по мере роста холдинга все более остро вставал вопрос объединения баз контактов журналистов во всех регионах нашего присутствия в одну большую и общедоступную «записную книжку». Словом, необходимость менять систему управления стала более чем очевидной.

КАК МЫ РАБОТАЛИ РАНЬШЕ

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

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

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

Работа с базой ньюсмейкеров стала отдельной болью: все контакты экспертов, клиентов, коллег хранились в разных базах. Даже по одной категории контактов, например, могло быть несколько баз, причем у кого-­то они были личные. И чтобы добыть телефон, например, регионального министра, надо было пройти семь кругов ада. В единую базу собрать все не получилось, тогда мы попробовали около пяти разных программ для хранения данных: от обычного Excel в сетевой папке и «облака» до Vtiger и Microsoft Dynamics CRM.

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

Весь процесс коммуникации и постановки задач в нашей большой команде был построен на двух программных продуктах: первый — через корпоративную почту обычно отправлялись распоряжения и официальные бумаги; второй — обсуждения, обмен планами или ситуативное реагирование на обстановку проходили в чатах популярных мессенджеров. Там же иногда и «прилетали» задачи. А если чат активный и ты не успел еще где­-то зафиксировать поручение, то со 100-­процентной вероятностью можно сказать, что оно не будет выполнено.

Большие сложности вызывала работа с общим календарем событий, которые необходимо посетить, встреч, командировок, мероприятий и т. д. Это была огромная «простыня» на популярном сервисе, в которую смотришь и негодуешь, потому что она пестрит всем и сразу, а выделить что­то действительно важное для себя было сложно.

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

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

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

ЧТО МЫ СДЕЛАЛИ

Первоначально хотели объединить все контакты в одну базу данных. Идеально для этого подходили CRM­-платформы. За всю историю медиахолдинга мы пытались использовать около пяти разных CRM­-систем, в которых намеревались объединить все контакты из всех отделов. Для начала мы попытались сэкономить и использовали open-­source-­платформы, но ни одна CRM-­система у нас не заработала так, как мы хотели. Не все сотрудники ею пользовались, не все делились контактами.

SugarCRM оказалось неудобно пользоваться, да и дизайн был на любителя. К тому же ее конструкция нам показалась сложной, ее нужно было «допиливать» под специфику СМИ.

Тогда мы попробовали Vtiger. Эта платформа предполагает создание какого угодно количества и формата полей, но возникла другая проблема: чтобы удовлетворить потребности всех подразделений холдинга, пришлось делать карточки контактов достаточно развернутыми. Их заполнение занимало много времени, а с незаполненными полями система не позволяла сохранить контакт в базу.

Следующая попытка также не увенчалась успехом: мы попробовали OnlyOffice. Но и эта система оказалась несовершенна: в ней нельзя было дополнять поля в адресной книге. При этом OnlyOffice рассматривалась и как «облачный» редактор.

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

Microsoft Dynamics CRM была очень даже хороша вместе с предложением от Microsoft Office 365, но все вместе оказалось очень дорого.

«Яндекс Коннект» — с этой системой ситуация шла от обратного: система проста, интересна, начали ее использовать в бесплатном варианте, но смутило наличие рекламы на страницах и, честно говоря, «сыроватость» этой системы. У нашей команды сложилось впечатление, что самый крупный IT-­холдинг в России еще «допиливает» ее.

Мы поняли, что дело не только в CRM­-системе. Дело в отсутствии единой экосистемы для всех сотрудников: чаты в одном мессенджере, почта в другом почтовом клиенте, планы редакции в «облаке», контакты в CRM, а планы на день — в ежедневнике.

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

Нашам команда начала исследовать разные кейсы. Первое, что мы рассматривали, — это редакционный софт. Мы потестили CoSchedule — неплохой сервис, позволяет создавать редакционный план, назначать исполнителей, следить за ходом работ, делать автоматический постинг в некоторых социальных сетях (пока, увы, без «ВКонтакте» и «Одноклассников») и даже отслеживать аналитику. Он работает через браузер, сервис платный. Для большой компании с расширенной функциональностью стоимость приемлемая. Вместе с тем данная система нам показалась все­-таки не совсем отвечающей специфике российских СМИ. В частности, смутило отсутствие русифицированной версии и автопостинга в популярнейших социальных сетях СНГ. 

Потом мы попробовали использовать программный продукт Setka. Это софт, который разработала команда Look At Media. Нам он понравился по дизайну, в целом был довольно интересный вариант. Стоимость — около 40 тысяч рублей в месяц. Эта программа решала, на наш взгляд, задачи по редакционному планированию. Она позволяла в любой момент узнать всю информацию о редакционных процессах, посмотреть, кто над чем работает, на какой стадии подготовки находятся материалы. Но в ней оказалось много элементов, которыми мы не хотели пользоваться, нам они мешали. Кроме того, в ней надо было разбираться, учиться, причем учиться всем сразу, времени на это не было. Мы надеялись, что сотрудники проявят сознательность и каждый будет сам осваивать продукт. Но оказалось, что не все смогли разобраться, и от этого потерялся смысл использования этой программы.

И после того, как мы поняли, что на рынке нет готового продукта под нас, мы решили сделать его под свои потребности. Промониторив программные продукты, мы выбрали «Битрикс». Сначала нас смутило то, что в основном он используется в продажах, но решили все-­таки попробовать. Пригласили интеграторов; они спросили нас, чего мы хотим. Получив ответ в общих чертах, специалисты начали под нас настраивать «облако». Оказалось, что они делают свою работу, ориентируясь на стандартные процессы, и совсем не учитывают специфику нашей деятельности; к сожалению, они не разбираются в наших бизнес-­процессах и не очень понимают, как правильно настроить систему, чтобы закрыть наши потребности, о которых мы даже еще не подозревали.

Команда разработчиков «Битрикс» не поняла «сущность» компании, и все, что они сделали, — это настройка работы одного коммерческого менеджера одного региона, который продавал баннерную рекламу на внутренних страницах сайта. Все остальные — самые важные — процессы не были автоматизированы совсем. Сложилось впечатление, что с нами работали по стандартному чек­листу интернет­-магазина. Более того, мы столкнулись с традиционной проблемой нежелания сотрудников заходить в новую систему управления.

Но первые необходимые шаги мы все-­таки сделали: избавили редакцию от хаоса и получили полную прозрачность в работе большой команды. Теперь мы можем точно оценить нагрузку каждого сотрудника, его рабочее время, можем четко сформулировать типовые задания внутри коллектива. Особенно радует, что мы перестали переспрашивать друг друга о дедлайнах разных проектов и их целях. Все ТЗ у каждого сотрудника и его руководителя всегда перед глазами. Забегая вперед, скажу, что мы все-­таки остановились на «Битриксе», но его интеграция в редакционную работу — это уже отдельный «путь боли», о котором я расскажу в следующей статье.