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


1. Расставлять приоритеты и планировать узкие места

Если посмотреть на нашу доску канбан, где отображены все задачи, можно увидеть, что строка «Антон» запружена стикерами (всего в работе находится более 20 задач). Фактически это означает, что в нашей системе производство в лице Антона является «бутылочным горлышком». Задачи здесь застревают. Оно и понятно – изготовление детали на станке из металлической болванки, а потом термообработка детали занимает несколько больше времени, чем проектирование детали. На изготовление детали может уйти от нескольких часов до двух недель. К тому же у нас существует правило, что серийный выпуск продукции важнее, чем любая проектная работа. От этого возникают проблемы при планировании. Но и тут, несмотря на некоторый уровень неопределенности, был предпринят ряд действий.



Во-первых, проведен анализ ресурсов производства и выявлены следующие: менеджмент, работа руками, работа головой. М (или менеджмент) – это то, что можно делегировать сотрудникам производства. Например, отдать в работу операторам станков с ЧПУ изготовление деталей. Р (работа руками) – это то, что своими руками создает Антон. Например, сваривает стеллаж, проводит испытания на прочность. Г (голова, работа головой) – это работа, связанная с созданием документов, файлов, схем, работа за компьютером.



Во-вторых, каждой задаче присвоен буквенно-числовой номер (01М, 03Р, 50Г и т.д.). Буква означает тип ресурса, описанный выше, цифра – порядковый номер проекта в дорожной карте проектов. Чем меньше число – тем важнее проект. В информационной системе в наименовании каждой задачи производства этот номер присутствует. Поэтому можно в пару кликов отсортировать задачи по приоритетам. Таким образом, было сформулировано правило: «Чем выше задача в списке, тем она важнее».



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

В-четвертых, выработано правило: «Не ставить задач на производство, если не хватает всех входных данных (техпроцесса, конструкторской документации, материалов, заготовок, стандартных изделий, оснастки)». Это просто сохраняет нервы, как исполнителям на производстве, которые судорожно ищут комплектующие, а их просто-напросто не привезли, так и менеджеру проектов, которому лишний раз не нужно объяснять ситуацию о причинах задержки комплектующих. Пускай менеджер седеет в одиночку, но убережет нервы производства.

2. Создавать и поддерживать поток задач

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



Мало просто расставить задачи, важно понимать, что необходимо поддерживать их постоянное движение. Когда задач много, они похожи на толпу людей, пытающихся пролезть в одну узкую дверь, но застревают в ней. Анализ, проведенный выше, позволяет понять пропускную способность ресурсов и создать более или менее ровную очередь из задач, когда единовременно в дверь заходит ровно одна задача. Такой подход обоснован законом Литтла. Он сводится к тому, что чем короче очередь, тем быстрее выполняются задачи в очереди. Это интуитивно понятно, но далеко не всегда нами выполняется. Как напоминание вынес данное правило себе на рабочий ноутбук.



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

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

3. Искать резервы ресурсов внутри предприятия

Задуматься на тему поиска ресурсов внутри предприятия и оптимизации ресурсов пришлось, когда я обнаружил, что у Сергея, нашего технического писателя, на исполнении стоит около 30 задач разного уровня сложности. Это не настолько удивительно, так как одновременно на разных стадиях разработки у нас находится 16 проектов. На ежедневных летучках мне просто приходилось отражать натиск маркетолога, что Сергей занят чем угодно, но только не маркетинговыми задачами. Кроме того, что технический писатель занимался написанием статей в блог компании, разработкой инструкций по эксплуатации, SMM, на его мужские плечи легла обязанность разработки инструкций по упаковке продукта. При том, что фактически же при разработке инструкций по упаковке Сергей работал, как это мы называем, печатной машинкой – он всего лишь сводил в один файл информацию, полученную с участка упаковки. Эта обезьянья работа сводила на нет профессиональные возможности нашего техписа.

Как удалось высвободить ресурс?

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

Давайте посмотрим на результаты:

— число задач по проектам у технического писателя сократилось до 4;
— высвободилось время на SMM и маркетинг;
— время на разработку инструкций по упаковке сократилось в несколько раз за счет того, что заниматься ими стали люди на местах. Здесь я руководствовался следующим принципом японских производств: «Если хочешь решить проблему, иди в гемба [рабочее место], где эта проблема возникла». Другими словами, люди которые работают по инструкциям, лучше знают, как эта инструкция должна выглядеть. Поэтому и разработка инструкций стала занимать меньше времени.

Таким образом, фактически исчезла потребность текущего контроля задачи по разработке инструкции по упаковке – она решается в фоновом режиме и требует не более 10-20 минутного контроля еженедельно. Вопрос упаковки выпал из повестки летучек.

4. Разрабатывать и внедрять регламенты

Как говорят японцы: «Всякий раз, когда в текущем процессе появляются отклонения, надо задать следующие вопросы: «Это случилось потому, что у нас не было стандарта? Это случилось потому, что мы не следовали стандарту? Это случилось потому, что стандарт не был адекватным?» (Гемба кайдзен: Путь к снижению затрат и повышению качества; Масааки Имаи).

Потери в ресурсах часто возникают от того, что люди не знают, как правильно действовать (нет стандарта), нарушают стандарт (не следуют стандарту), или стандарт плохой и его нужно пересматривать.

В любом случае наличие стандарта всегда лучше, чем его отсутствие. Стандарт является инструментом для дальнейшего совершенствования и диалога между людьми внутри предприятия.

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

На настоящий момент все процессы, схемы рисуются в обычном документе excel. В будущем планируем все эти процессы перенести в bpm-систему.



5. Следовать логическим этапам проекта

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

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

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

6. Учитывать задачи вне проектов

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

Приведу пример.

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

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

Таким образом, стремимся к тому, чтобы любая задача должна быть учтена.

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