Издательская система «Альпины Паблишер»

Преамбула

Раз уж все прогрессивное человечество делится своим опытом создания ИТ-систем управления бизнесом, то и я не могу не отреагировать на призыв моей коллеги Ирины Гусинской рассказать нашу историю. Тем более что систему управления издательством мы создавали сами без какой-либо внешней помощи и работаем на ней практически без изменений уже 9 лет. По ходу дела поведаю не только о функционале того, что получилось, но и о пути, который пришлось пройти. Коснусь немного и сайта нашего интернет-магазина alpina.ru, который я создавал в 2004 году, то есть до перехода в редакцию.

Исходные условия

При создании ИТ-систем важно понимать размер бизнеса и круг задач, которые ИТ-система должна решать. Если у вас 1000 человек, и ИТ-система должна делать практически все, и у вас большой бюджет — тогда решение одно: решения класса ERP. А если у вас около 100 человек, и системой пользуется примерно половина сотрудников, и лишних денег нет, тогда решение будет совершенно другое. У нас в 2005 году, на седьмой год работы издательства, было около 50 человек, из которых дай бог пятнадцати была нужна система. Поэтому мы решили не усложнять.

Как работали «до»

До 2005 года проектами мы управляли в обычном Excel-файле. Была закреплена область с названиями и типами книг, а все процессы, на каждый из которых отводилось по ячейке, просматривались через прокрутку. Текущие проекты были наверху, линия времени шла вниз, а процессы — в ячейках слева направо. Книги, которые должны были выйти в определенный месяц, группировались вместе, то есть основной принцип издательской системы — группирование проектов по месяцам выхода, заложен был еще тогда. Когда книга приходила из типографии, проект перемещался на другой лист Excel, который помечался «готово». Соответственно активный лист назывался «план». Неудобств в Excel много, начиная от того, что это по сути доска для записей, которая никак не подсказывает логику работы и не напоминает, что надо сделать и когда (про макросы мы тогда боялись даже думать, хотя с их помощь можно много поправить). Тем не менее для первых лет работы издательства Excel было более чем достаточно. Более того, не рекомендую сразу, без простых решений, переходить к сложным, особенно в первые годы работы фирмы. Руководителю нужно «почувствовать» логику работы ИТ-системы самому, понять что удобно, а что — нет, и только потом переходить к более сложным системам. Если этого не сделать, то программисты напишут то, что удобно им, и вам придется свои процессы менять в угоду ИТ-системе, хотя правильно как раз наоборот: писать ИТ-систему, которая отвечает вашей индивидуальной системе работы с процессами. Или еще хуже будет: вы привыкнете работать в «созданной вовне» ИТ-системе, но не будете понимать, как один параметр связан с другим, какова «внутренняя кухня» системы, почему она ведет себя так, а не иначе. Чем меньше в вашем ведении таких «черных ящиков», тем проще управлять. Все надо вначале «потрогать руками», а уже потом усложнять.

Кто должен писать ТЗ

ТЗ и основные требования к ИТ-продукту должен высказывать ее главный пользователь. Как правило, это руководитель фирмы/отдела. Например, когда я был директором интернет-магазина alpina.ru, именно я писал ТЗ «от и до» и считаю это единственно правильным. Если руководитель является архитектором и оперативным управляющим процессами, то только он знает, где расставить контрольные точки, как должны быть связаны между собой процессы, какие временные параметры по переходу с процесса на процесс стоит заложить в систему для контроля. Тем более это актуально, если вы создаете не стандартную систему, которая есть у конкурентов, а что-то индивидуальное, с расчетом с ее помощью получить конкурентное преимущество. На «просвещенном Западе» руководителям не западло самим рисовать блок-схемы процессов, а ведь ИТ-система — это, по сути, закодированная блок-схема процесса (проекта). У нас же часто эту задачу по ТЗ поручают программистам или «девочке-секретарю». Надеюсь, сейчас не так распространено как было в начале 2000-х, в эпоху повального увлечения системой описания проектов IDEF, которую не понять даже после пол-литра.

Изучение аналогов

Мы исследовали аналоги, но весьма вяло: мне в те годы было на порядок интереснее сделать все самому, чем затачивать «коробочную версию» и спорить с программистами по поводу того, как ее заставить раскрашивать ячейки в разные цвета. Однажды, будучи на книжной ярмарке в Лондоне, мы заехали в издательство Pearson Education (одно из крупнейших в мире), чтобы посмотреть, какие у них есть ИТ-системы управления издательскими проектами. Оказалось, что у них есть две системы, одна для «плана», другая для «факта», и они между собой особо не дружат. Соответственно те, кто делает книги, и те, кто анализирует их эффективность, тоже между собой контачат слабо. Типичная «болезнь» большой компании. Особо позабавил их главный айтишник, который дико радовался, сколько багов они находят еженедельно и как быстро они все исправляют. Короче говоря, все при деле. Мы сказали им спасибо и решили все делать сами.

Кто все это делал

Автором ТЗ был я как человек, который в тот момент в должности заместителя главного редактора был брошен на управление издательским процессом. Обсуждали ТЗ мы с акционерами компании, которые непосредственно были вовлечены в работу компании и каждый из которых планировал пользоваться издатсистемой (далее ИС) для своих целей: продажи, работа со спонсорами, реклама.

Нам очень повезло, что не пришлось тратить время на поиск программиста. Этот путь мы прошли в 2004 году, когда весьма долго искали человека или компанию, которая могла бы сделать нам интернет-магазин alpina.ru. Вроде задача простая и стандартная, но мне хотелось сделать по-настоящему крутую систему, с заранее зашитым законом перехода статусов заказа (чтобы никто не говорил, что «пусть этот заказ вот здесь полежит, деньги привезу потом, а чек мы сделаем завтра», или чтобы ни один заказ не потерялся, в каком бы статусе он не находился), с контролем за финансами и автоматическим формированием ведомости зарплат курьерам в зависимости от выполнения нормы и соблюдения временных параметров доставки. Самым сложным при создании сайта оказалось, как ни странно, найти программиста (или ИТ-фирму), который мог сделать автоматическое изменение статуса заказа по сканеру штрих-кода на бланке заказа в зависимости от того, кто держит в руках сканер (работник склада, начальник курьерской службы, кассир) и статуса, на котором сейчас находится заказ клиента. Почему-то порядка десятка весьма достойных ИТ-компаний, которые хотели получить контракт, эта задача по переходу статусов ставила в тупик. Хотя единственное, что делает сканер штрих-кода — это считывает цифровой код и ставит «Enter», то есть дает команду на ввод. Я решил, что первый, кто эту «сложнейшую» задачу сможет решить, и получит контракт. Им оказался Алекс Илинский из Питера (рекомендую, кстати). Он вообще не придал этой задаче какое-то значение, как и должен был сделать нормальный квалифицированный программист. Сайт, с учетом всех доработок, прожил лет шесть. Я в процессе создания сайта узнал много интересного из мира ИТ, в частности такую максиму, что «в программировании нет ничего невозможного». Часто мне это потом помогало в переговорах.

Минус у этого сайта был один: индивидуальное решение конкретного программиста. Поскольку никто не любит доделывать продукт, не им созданный (если это не коробочное решение), мы были жестко привязаны к Алексу и по доделкам, и по техподдержке. Это, кстати, базовая проблема создания любой ИТ-системы, ведь коробочное решение имеет границы индивидуализации под ваши потребности (что бы ни говорили поставщики), а талантливый индивидуал сделает вам все, что душе угодно, однако потом без него вам не обойтись, даже если он злоупотребит спиртной напиток и пропадет на неделю (я не про нашего программиста, Бог миловал). Впрочем, сейчас коробочные версии более продвинутые, и найти решение под себя существенно проще.

Кстати подивитесь на одну из схем в ТЗ на сайт alpina.ru. Горжусь. :) Когда Алекс ее увидел, он больше не задавал ни одного вопроса касательно того, как и что надо делать.

Базовые требования к ИС

Самым главным решением, о котором мы не жалеем, было условие сделать что-то похожее на то, что у нас уже было на тот момент, то есть файл excel, построенный по логике группирования проектов «сверху вниз» по месяцам выхода. Очень важно, чтобы система обладала свойством визуализации, то есть с первого раза было бы понятно, какой процесс на какой находится стадии (посредством цветовой дифференциации статусов), каковы основные параметры книги и их статус (объем, окончательный или рабочий, размеры обложки и пр.).

Мы не планировали создавать аналог MS Project — никаких схем критических путей, никаких сетевых графиков, никаких связей между работами через стрелочки. Процесс создания книги достаточно типичен, поэтому последовательность процессов, за редким исключением, жестко задана заранее и от проекта к проекту ее менять не надо. Для переводной книги это перевод, редактирование, верстка, корректура, вычитка, подготовка к сдаче, печать. Это критический путь, где задержка на одном процессе задерживает весь проект. На некритическом пути, который начинается с окончания перевода и заканчивается сдачей книги, находятся еще три процесса: обсуждение и утверждение названия и дизайн обложки, а также поиск спонсора/рекламодателя. Если книга на русском языке, выпадает только процесс перевода, остальное без изменений.

Процесс создания ИС

Не углубляясь далеко в технические требования, скажу лишь, что я совершил типичную ошибку начинающего руководителя, который принимается описывать процессы. Я описал все слишком подробно, чуть ли не до нормирования числа файлов по каждой книге и ежедневных отчетов для редакторов о содеянном. Начинающему руководителю всегда сложно понять, что надо прописывать четко, а что — оставить на личный контроль или предоставить решение на откуп исполнителям. Соответственно если бы программист реализовал все 150 страниц ТЗ в неизменном виде, мы бы получили монстра, в котором половину функционала за ненадобностью пришлось бы выбросить (или мучиться с кучей ненужных проверок, которые без переделки системы не выбросишь). На наше счастье, Алекс в положенный срок сделал лишь базовый костяк ИС, который мы усложнили ровно настолько, насколько нужно, ибо к тому времени я уже имел достаточно опыта управления редакцией, чтобы отделить важное от неважного.

Еще одной ошибкой ТЗ было создать систему управления издательством в целом. Нам хотелось там и анализировать темпы продаж (интеграция с бухгалтерской системой), и хранить файлы (уйти от виндовой файловой системы!!!), и прослеживать выплаты авторских, хранить сканы контрактов, следить за загрузкой редакторов и корректоров, заполнять тайм-шиты по исполнителям. Ведь коли идет работа над системой управления редакцией, почему бы не добавить то, се, и пятое-десятое? Каждому же хочется избавиться от того или иного вручную формируемого файла и по-взрослому все автоматизировать.

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

Что получилось

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

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

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

Другие системы в издательстве

В итоге у нас в издательстве оказалось пять разных ИТ-систем: издательская система, система управления производством (то есть отслеживание типографий), 1С, Microsoft CRM (рекламодатели и спонсоры, авторские права) и новый сайт интернет-магазина на Битриксе, которые связаны между собой протоколами экспорта и импорта данных, зачастую весьма замысловатых. Но если четко следить за тем, какой параметр в какой системе создается и хранится как источник и куда он попадает в результате экспорта из другой системы, тогда никаких проблем не возникнет, как ни сложна была бы интеграция. Да, еще важно не забыть о репортах, которые ежедневно должны сигнализировать о том, правильно ли работает интеграция, идут ли бэкапы. Но это уже не так интересно, по крайней мере мне как главному редактору.

Доски визуального контроля

Многие задачи, которые изначально были «делегированы» для контроля издатсистеме, на практике оказалось проще отслеживать вручную, на магнитных досках. Процесс получения прав на книгу, процесс написания книги русским автором, процессы перевода, редактирования и корректуры оказалось удобнее контролировать, перемещая проект (магнитная полоска) с одной доски на другую. Поскольку все руководители проектов находятся рядом с доской, каждый может понять, свободен ли переводчик или редактор, пришли ли файлы от правообладателя, и значит можно ли начинать работу. Логику работы с досками я позаимствовал у японцев, а точнее — из книг про японский менеджмент, в частности — про бережливое производство и Toyota, с которыми мы сами как издательство впервые познакомили российских читателей.

Вот как эти доски выглядят.

Резюме

Не стану бить себя в грудь и говорить, что у нас лучшая система управления издательскими проектами в мире (хотя полагается, вроде бы, такую статью закончить ура-патриотическими нотками). Более того, уверен, что если бы мы делали не 80 новинок в год, а, например, 800, все пришлось бы кардинально менять. Однако для текущей работы сложившаяся система сочетания ручных систем визуального контроля проектов и ИТ-решений (которые в целом тоже визуализированы) позволяет нам быть уверенными в том, что все выйдет вовремя, ни один проект не потеряется и ни один параметр не будет реализован без надлежащего утверждения и проверки авторизованным персоналом. А это именно то, что нужно издательству, которое желает уверенно поддерживать свои лидерские позиции на рынке.

P.S. Просьба услуги по созданию ИТ-систем не предлагать. Надо будет — сам найду ☺

Сергей Турко

Главный редактор издательства деловой литературы «Альпина Паблишер»