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

После рассказа на habr.com о нашей технологии разработки сайтов количество заявок на наши услуги выросло в несколько раз. Только за март 2012 года было выставлено около 60 (для нас тогда это было очень много) коммерческих предложений, и большая часть из них превращалась в договоры. И тут наше производство затрещало по швам. Практически сразу заявки стали становиться в очередь. Несмотря на высокую организованность, менеджеры начали путаться в проектах, разработчики не успевали, в процессе разработки стало появляться очень много незавершенных проектов, все стали проситься в отпуск. Себестоимость проектов резко начала расти, а рентабельность — падать. Ситуация становилась напряженной...

Осознание проблемы

Первое, что нам пришлось сделать, — это временно увеличить обещанный срок разработки с 5 до 8, а иногда и до 10 дней. У нас просто не было выхода. Клиенты отнеслись с пониманием и были готовы ждать. А вот мы не были готовы ждать, пока ситуация станет еще более напряженной. Нужно было что-то предпринимать. По всем показателям (и нормативам) мы должны были справляться, но этого не происходило.

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

Процесс непрерывного улучшения

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

Одно звено принимает заявки, другое — проект в работу (дизайн, сборка, доработка), еще одно занимается тестированием и выкладкой и т.д. Если хотя бы одно звено дает сбой, то весь процесс тормозится или останавливается. И тут есть важный момент. Что определяет прочность цепи? Естественно, самое слабое звено. Надо заметить, что самое слабое звено в цепи — одно, и это ключевой момент подхода к управлению производством. Этот подход в промышленном мире описан теорией ограничений (Theory Of Constraints).

Поясню подробнее. Допустим, в цепи производства ваша роль — сборка сайта из готового дизайна. Вы — не самое слабое звено. В результате собственной гениальности и трудоспособности вы начали собирать в два раза больше. Насколько вы увеличили производительность всей цепи? Правильно, ни на сколько. Абсолютно ни на сколько. Большинство локальных улучшений не помогает производительности всей команды. Это значит, что «чем больше, тем лучше» не является тем путем, который приводит к повышению общей эффективности.

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

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

Мы усилили звено, и оно больше не являлось слабым. Теперь необходимо было вернуться на стартовую позицию и заново начать поиск слабого звена. Это процесс непрерывного улучшения, которому мы следовали (и следуем) в поисках скрытых ресурсов команды.

Синхронизируем скорость работы, балансируем производство

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

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

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

Распараллеливание проектов уменьшает скорость всей цепи и повышает затраты

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

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

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

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

5 проектов на менеджера

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

5 дней на проект

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

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

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

Все остальное оказалось малозначительным по сравнению с первыми двумя причинами.

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

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

Благодаря этому для большей части проектов мы вернули клиентам обещанные пять дней и восстановили спокойствие в команде. Производительность на тот момент выросла до 36 проектов в месяц. И самое главное: мы почти вернули нормальную себестоимость проектов, что позволило бизнесу опять генерировать прибыль и расти.

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

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

Резюме

Кратко резюмируем подход по непрерывному улучшению потокового производства.

Найти ограничение системы. Что в настоящий момент задает ее максимальную производительность?

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

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

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

Оценивать систему в целом и периодически возвращаться к шагу № 1.

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

Конечно, для того чтобы все это работало, нужно не просто наблюдать. В современном мире это называется Data Driven Company. Нужно собирать показатели эффективности на всех участках конвейера. Желательно, чтобы все данные собирались автоматически, без привлечения отдельного человека. Для большинства этапов мы это реализовали в CanapeCRM. Любой желающий может воспользоваться этим инструментом или написать свой, опираясь на наш опыт и метрики.

Уникальность WebCanape в «древней» истории, амбициях и инвестициях в собственные технологии. Сначала компания делает конвейер, а затем конвейер делает компанию. Агентство развивалось во всех своих продуктах и услугах с нуля. Развитие направлений тут же получало поддержку в виде внутренних сервисов. В итоге у компании есть своя информационная инфраструктура, в которой учтены основные потребности всех отделов, сервисы с отлаженными бизнес-процессами. Их совершенствование не прекращается.

Алексей Момот, ведущий разработчик

Полезные ссылки

1. Запись на бесплатный вебинар Диджитал на конвейере, который состоится 6 августа.

2. «Бизнес на конвейере, или Как построить прибыльное агентство в кризис» на Ridero.

3. Телеграм-группа @webbizz, в которой можно задать вопросы автору книги.

Предыдущие главы книги

1. Зачем нужен бизнес-план, когда он не сбывается?

2. Команда, которая станет фундаментом устойчивого бизнеса

3. Теперь мы продаем не услуги, а продукты

4. Как построить отдел продаж, который выполняет план?

5. Автоматизация отдела продаж, или Один менеджер на 120 заявок

6. Производство на конвейере — гарантия сроков и качества