Скоро нам стали мешать очевидные ограничения этой таблицы – кто угодно мог случайно удалить данные, сложно было отличить плановые цифры от окончательных, не было извещений, напоминаний, чек-листов, а главное – обмена данными с другими системами: кадровой, бухгалтерской. Приходилось переносить данные вручную, а где ручной ввод – там и ошибки. И мы подумали – а как другие издатели управляют проектами?
У Алексея были дружеские отношения с Линетт Оуэн из издательства Pearson Education. В дни Лондонской книжной ярмарки в 2005 г. мы попросились к ней на экскурсию, чтобы понять, какие у них информационные системы. Помню, как долго ехали из Лондона по пробкам (хуже, чем в Москве!), пока не оказались в сельской местности, где посреди огромных зеленых полей для гольфа стояло огромное стеклянное здание с деревьями на крыше – офис Pearson Education, одного из крупнейших на тот момент мировых издательств. Поговорили с руководством, с IT-отделом, с несчастным программистом (он у них был один!), который с утра до вечера разбирался с ошибками кода. У них было две системы, для контроля продаж и для управления проектами. Данные они переносили вручную, протокола обмена не было.
В Москве я посетил пару конференций, на которых крупные IT-производители предлагали решения для издательского бизнеса – чуть модифицированные версии крупных и дорогих продуктов типа SAP ERP[41]. У нас таких денег не было.
Проблема отсутствия денег, как обычно, подсказала решение. Мы стали делать собственную издательскую систему. Я тогда не был знаком с методологией Scram, но действовал похоже: сделать прототип, собрать идеи пользователей и идти дальше. Основным плюсом нашей системы стало то, что мы делали ее для себя, похожей на ту самую табличку Excel, и нам не требовалось переобучаться на другой интерфейс, на другую логику представления результатов.
Заметили, что в одной книге мы забыли разместить автора на корешке, – добавили это в чек-лист перед сдачей проекта. Поняли, что после верстки не все проставляют количество страниц (а это необходимо для закупки бумаги), – сделали невозможным завершить верстку без ввода этого значения. Сделали обязательным поле контактов аутсорсера. Заодно поняли важный принцип взаимодействия IT и менеджмента: именно руководитель должен планировать процесс, подобно программисту, и кодировать его посредством создания ТЗ в информационной системе.
К началу 2006 г. у нас появилась вполне работоспособная система управления проектами, которая высылает извещения, предупреждает о наступлении следующего этапа, хранит все параметры книг в базе данных, может выгружать параметры в интернет-магазин или в бухгалтерскую программу. Программист – талантливый парень из Санкт-Петербурга по имени Алекс – многим сотрудникам представлялся мифической фигурой вроде Ворошилова из ранних выпусков «Что? Где? Когда?»: голос есть, а как выглядит ведущий, никто не знает. Зато все понимали, что если написать ТЗ, то Алекс все сделает. Когда? Когда доберется: может, сегодня вечером, а может, и через месяц.
В 2004 г. Алекс делал нам сайт интернет-магазина alpina.ru и показал себя прекрасно. Один из его уроков я запомнил на всю жизнь: если программист говорит тебе, что что-то невозможно, – гони его взашей. Код – это виртуальный мир, там можно все. Вопрос только во времени и в деньгах: что-то можно сделать быстро, а что-то – путем переписывания всего ядра. Но невозможного нет.
В 2005 г. он очень хотел получить от нас следующий заказ, и по дороге из Петербурга в Москву на скорости 140 км/ч столкнулся с лосем – машина в хлам, у самого ни царапины, даже не опоздал на назначенную встречу. «Буду быстрее работать, чтобы заработать на новую машину», – сказал человек, который еще несколько часов назад был на волосок от смерти.
Алекс был веселым программистом и не записывал пароли, а помнил их, так как придумывал запоминающиеся фразы на русском и вводил их с клавиатуры с латинской раскладкой. Мнемотехника! Один из его заказчиков решил расшифровать пароль «uyjqysqyfhjcn, bpytcf» и остался весьма недоволен черным юмором исполнителя.
Процедуры и блок-схемы
Когда начинается хаос, а это периодически происходит в любой организации, руководителей посещает мысль упорядочить процессы. Мысль правильная, но реализуется она часто неверным путем: через привлечение внешних ресурсов (хорошо, если консультант, хуже – если знакомый студент), которые долго расспрашивают ключевых руководителей и через пару месяцев выдают толстый фолиант, испещренный линиями, квадратиками и стрелками – нечто среднее между выкройкой из журнала «Бурда» и схемой подземных помещений аэропорта из фильма «Крепкий орешек – 2». Практическая ценность таких схем равна нулю.
Мы пошли другим путем: сделали для основных бизнес-процессов простые блок-схемы и «зашили» их в нашу издательскую систему управления проектами. Сотрудники редакций просто заполняют поля параметров и меняют статусы, а система сама подсказывает следующий шаг. И бумажную блок-схему смотреть не нужно, и ошибки минимизированы. Когда что-то в нашем бизнес-процессе меняется, а это происходит часто, мы добавляем контрольные точки или извещения, вводим новые поля базы данных для параметров, разграничиваем права доступа. На каждое изменение процессов мы отвечаем новым чек-боксом, статусом или контрольным пунктом. Неожиданно для самих себя мы стали IT-компанией.
Письменная процедура у нас в редакции тоже есть, в ней пока 50 страниц. Очень удобно иметь все процедуры и регламенты в одном файле – ничего не теряется. А как только приняли новое решение – сразу обновляем процедуру, чтобы не искать важные решения в переписке.
Такие информационные системы, сделанные для конкретного заказчика, настолько упрощают работу и минимизируют хаос и ошибки, что служат ключевым фактором обеспечения качества книг.
Несколько процессных лайфхаков
● Нет ничего хуже для издательства, чем перепутать версии файлов – хотя был случай, когда в типографии подшили в одну книгу тетрадку из совершенно другого издания. Типография признала ошибку и все переделала. Помню первые дни работы в редакции: в структуре папок, где хранятся файлы по конкретному проекту, в папке «Текст» я заметил папку «Окончательные версии». Не сразу понял весь абсурд такого названия, но это соответствовало факту: там действительно мог быть с десяток окончательных версий, включая самую окончательную и самую-самую окончательную. Стоило переименовать папку – и окончательная версия стала только одна, а все остальные – рабочие – остались в другой папке.
● Качество любого текста удобно оценивать по четырем параметрам: язык (стилистика, грамматика), факты, логика и единообразие. Эти и подобные вещи о принципах и подходах работы с текстом резюмированы у нас в документе «Дао Альпина», который мы просим изучить всех новых сотрудников, не говоря уже об аутсорсерах.
● В организации главное не вертикальная структура – кто кому подчиняется, а горизонтальная – какой процесс идет следующим, кто хозяин процесса, как организована передача продукта с этапа на этап. Все проблемы, как правило, происходят на стыках процессов или отделов – и именно с этих стыков надо начинать оптимизацию. Например, с передачи проекта из продюсирования в редакцию, из редакции в маркетинг, из маркетинга обратно в редакцию для обсуждения переизданий.
● Плоская структура всегда будет бить вертикальную. Если у двух исполнителей пять начальников – это беда. Если для того, чтобы решить проблему, нужно записываться к руководителю за неделю – это беда. Если проблему можно решить за пять минут в личной беседе, но люди собирают многочасовое совещание с модераторами, фасилитаторами и флипчартами – это беда.
● Первый раз любой процесс дает сбой. Новое решение может быть понято неправильно и исполнено не так, как предполагал руководитель. Принцип испорченного телефона применим даже к самым грамотным людям, не стоит их идеализировать. Просто надо иметь в виду это человеческое свойство и время от времени уточнять – как идут дела, правильно ли понята задача, что именно происходит в данный момент. Errare humanum est.
● Если ошибка случилась один раз, она не очень значительна, а риски невелики – ну и ладно, проехали. Контрольные проверки нужны только для существенных ошибок, возникающих регулярно, или для крайне редких случаев, несущих огромные риски. Излишняя бюрократизация может быть бо́льшим злом, чем те редкие ошибки, которые она купирует.
● Точечная оценка почти никогда не показывает состояние системы, нужна динамика и некоторый период наблюдений. Отдельные ошибки не говорят о качестве процесса в целом – точно так же, как редкие опоздания не говорят о дисциплине. Те, кто опаздывает, часто потом задерживаются. Если штрафовать опоздавших, то стоит премировать задержавшихся, но так никто не делает.
● Сложную систему нельзя описать одной моделью. Именно поэтому никакая концепция менеджмента, никакая история успеха не может быть на 100 % применена к другой компании, хотя все концепции и истории полезны и поучительны.
● Руководитель должен вникать в суть работы сотрудников, глубоко разбираться в специфике их работы. Нельзя управлять только по показателям или изучая красивые отчетные презентации раз в квартал. Краеугольная ошибка американского менеджмента в том, что он допускает необязательность понимания топ-менеджерами предметной области. Японский, советский и классический немецкий менеджмент предполагает, что руководитель вырастает из обычного работника. (Я часто вспоминаю о министре путей сообщения царской России князе Хилкове, который, уже будучи министром, не раз садился за рычаги паровоза и кидал уголь в топку.)
Цифровизация и ИИ
Цифровизация, то есть автоматизация ручного труда, – это прекрасно, мы занимаемся этим с 2005 г. Но мы не забываем и контрольные доски: как бы ни были развиты информационные системы, некоторые вещи нагляднее и проще контролировать с помощью обычной белой доски с маркерами и фишками.