В своих проектах я использую классическую технологию управления waterfall – проект делится на этапы работ, которые выполняются последовательно и охватывают все функциональные области, которые вошли в границы проекта. Перечислю этапы и что мы на них делаем:
- Обследование заказчика – сбор требований, моделирование контрольных примеров, демонстрациях их представителям заказчика и подготовка некой сводной модели – то, как предприятие-заказчик будет работать во внедряемой системе. Что это за модель – поговорим отдельно. Также на этапе обследования производится первоначальная настройка системы под требования заказчика – в части базовых настроек, а также описывается методика загрузки начальных данных – справочников, остатков и пр.
- Доработка типовой конфигурации – в процессе моделирования мы обнаруживаем функциональные разрывы – там, где базовая функциональность системы не устраивает заказчика, на этапе доработки мы дорабатываем типовую систему для устранения этих разрывов. Также на этапе доработки пишутся обработки для загрузки начальных данных.
- Обучение пользователей – подготовка программы обучения, возможное написание инструкций для пользователей, проведение обучения.
- Перенос начальных остатков во внедряемую систему – загрузка данных и выверка их пользователями.
- Опытно-промышленная эксплуатация – передача системы в работу, контроль за использованием, помощь пользователям, исправление ошибок.
- Передача в промышленную эксплуатацию – перевод поддержки пользователей на ИТ службу заказчика или на договор поддержки (если поддержка идет со стороны подрядчика).
С описанием этапов вроде все логично, но вот на практике такая схема почему-то постоянно дает сбой – мы вот что-то такое распланировали, но сказать, где конкретно внутри этапа мы сейчас находимся, сколько нам осталось, где у нас затруднения – нам это неизвестно. В итоге сроки постоянно плывут, заказчик недоволен, руководитель проекта в панике мечется, команда проекта фрустрирована.
Лечить данную болезнь предпочитают через симптомы – начинают закручивать дисциплинарные гайки, увеличивают количество отчетности, проводят больше статусов. И вот уже с проекта потянулись наиболее адекватные сотрудники, пошли задержки с оплатой и т.д. вплоть до отказа от работ подрядчика и выбора нового – который умеет управлять.
Хотят сама проблема лежит на поверхности – мы нарезали в этапы слишком большие куски работ – нужно декомпозировать этапы в подэтапы – тогда будет проще понять где мы. Моя декомпозиция выглядит следующим образом:
- Этап Обследование
- Опрос заказчика, сбор требований
- Подготовка демо-модели в 1С:ERP
- Защита демо-модели перед заказчиком
- Фиксация модели в проектных документах:
- Фиксация настроек системы
- Написание регламентов/сценариев работы пользователей
- Фиксация методов загрузки начальных данных
- Фиксация функциональных разрывов
- Этап Доработка типовой системы
- Подготовка и согласование технических заданий на доработку
- Программирование по техническим заданиям
- Сдача доработок заказчику
- Уточнение проектных документов по итогам сдачи
- Фиксация настроек системы
- Написание регламентов/сценариев работы пользователей
- Фиксация методов загрузки начальных данных
- Этап Обучение пользователей
- Подготовка программы обучения и списка необходимых инструкций
- Написание инструкций
- Проведение обучения
- Этап Перенос начальных остатков
- Подготовка данных из исторических систем/ручная подготовка
- Загрузка данных в 1С:ERP
- Проверка данных и исправление ошибок
- Этап Опытно-промышленная эксплуатация
- Этап Передача в промышленную эксплуатацию
Вроде стало более понятно, но появилась другая проблема – в одном этапе разные функциональные блоки автмоатизации могут находится на разных подэтапах.
Например, мы выполняем комплексный проект, функциональные границы которого затрагивают сбыт продукции, производство и закупки. Плюс обеспечивающие процессы учета и анализа затрат, подготовки бухгалтерской и налоговой отчетности, финансового планирования.
И вот в этом проекте мы достаточно быстро разобрались со сбытом, неплохо идут дела с закупками, но вот с производством все пока плохо. Как, гляди на декомпозицию этапов и подэтапов увидеть эту проблему – там ведь нет функциональных блоков?
Первое что приходит в голову (что пришло в голову мне) – это добавить к плану проектных работ еще одну декомпозицию – функциональный блоки. То есть, например, для обследования это будет выглядеть следующим образом:
- Этап Обследование
- Опрос заказчика, сбор требований
- Сбыт
- Производство
- Закупки
- ….
- Подготовка демо-модели в 1С:ERP
- Сбыт
- Производство
- Закупки
- ….
- Защита демо-модели перед заказчиком
- Сбыт
- Производство
- Закупки
- ….
- …….
- Опрос заказчика, сбор требований
То есть, мы добавляем третий уровень декомпозиции по функциональным блокам. Но задачи по функциональным блокам могут выполняться параллельно – то есть для Сбыта мы можем уже пройти все подэтапы вплоть до Защиты демо-модели, а вот для Производства работа еще находится на подэтапе опроса.
Итого нам нужна какая-то двухмерная картина управления проектом, которая, например, по горизонтали разворачивается по этапам и подэтапам работ, а по вертикали по функциональным блокам работ.
В каждой ячейке такой управляющей таблицы мы можем хранить данные по плановым срокам, оценочному проценту готовности, фактическому/прогнозному сроку окончания работ. Это уже рабочий инструмент управления – то есть мы видим некую детальную картину работ и можем предметно разговаривать и со своей командой, и с заказчиком.
Но что происходит внутри каждого функционального блока – как там обстоят дела – почему же блок Производство у нас значительно отстаёт от других блоков? Текущая картина управления ответ на этот вопрос не дает и если заказчик большой и команда большая, то все опять сводится к росту отчетности, статусам и прочему. То есть детализация проблем уже лучше, но все равно высокая доля ручного управления и обременительных действий.
Для решения этой задачи я опять предлагаю декомпозицию – но уже процессную.
Любой функциональный блок состоит из действий, которые в нем совершаются, а действия объединятся в процессы, которые можно также сегментировать по функциональным блокам.
Например, у нас есть процесс позаказного производства продукции, который начинается в отделе продаж, а потом идет в производство, потом опять возвращается в продажи:
БП 01 Позаказное производство
- Продажи:
- Оформления договора
- Оформление заказа клиента
- Производство:
- Оформление заказа на производство
- Производство продукции
- Продажи:
- Отгрузка товара клиенту
Добавим его в нашу карту управления и получим следующую картину:
Добавим еще процессы, которые мы уже выявили:
По каждой ячейке у нас так же есть сроки, есть прогноз выполнения, есть оценочный процент готовности, который проставляют консультанты. Теперь нам уже не нужны длительные разбирательства – мы видим узкие места проект и можем адресно с ними работать.
Важные замечания по организации работ:
- За каждой строкой в карте управления проектом должны стоять конкретное ответственные лица, как со стороны подрядчика, так и со стороны заказчика, с кем Вы, как руководитель проекта, можете обсудить текущую ситуацию по этой задаче.
- Вы должны контролировать состояние дел по строкам – если постоянно сдвигаются прогнозные сроки окончания работ, если работа застыла и процент готовности не меняется – Вы должны вмешиваться и помогать двигать работу дальше.
- Если работа вдруг поползла назад (была подготовка модели и вдруг опять опрос) – это ПРОБЛЕМА, которая требует Вашего срочного вмешательства, потому что такой цикл может уйти в бесконечность – тут или заказчик не серьезно относится к работе или исполнитель со стороны подрядчика не справляется – Ваша задача как руководителя проекта.
Теперь FAQ и рекомендации:
Вопрос: Откуда берется список бизнес процессов?
Ответ: Вы обследуете заказчика и создаете это список – на начальном этапе все может быть весьма укрупненно, по каким-то общим процессам. Потом Вы погружаетесь в специфику и становится более менее ясно как все устроено – процесс выявления бизнес-процессов итерационный – главное двигаться. Поменьше догматизма – ненужно ждать пока у Вас получится идеальный список процессов – нужно последовательно идти к нему.
Вопрос: Как понять где у нас узкое место проекта?
Ответ: Какая строка карты управления отстает от других - там и узкое место. В процессе работы Вы будете все дальше двигаться по этапам и подэтапам работ - где-то будете убегать вперед, где-то наоборот. Ваша задача как руководителя проекта контролировать, чтобы движение было равномерным - подталкивать отстающие строки.
Вопрос: А вот у меня за один процесс отвечают несколько людей – их много, тяжело управлять такой большой группой – что делать?
Ответ: Поделите процесс на несколько процессов и внесите их в реестр и в карту управления – документ может и должен регулярно уточняться.
Вопрос: Мой консультант слишком долго возится с одним процессом – что делать?
Ответ: Смените консультанта, если он объективно не справляется, или поделите большой процесс на части и добавьте еще одного консультанта. Например, процесс позаказного производства я мог бы разбить на два подпроцесса:
- БП-01-01 Позаказное производство – оформление договора и заказа
- БП-01-02 Позаказное производство – производство и отгрузка
Вопрос: Как часто нужно вносить и актуализировать информацию?
Ответ: Пару раз в неделю достаточно – главное, чтобы консультанты не забывали, что им нужно отчитываться. Ну и Вы должны смотреть на данные и разговаривать с людьми – кого-то призвать работать активнее, кого-то похвалить, кому-то дать еще помощников, кому-то помочь с заказчиком – адресно вмешаться в ситуацию. Ни что так не демотивирует людей, как работа, которая никому не нужна – если Вы перевели команду на какую-то систему управления, то Вы должны ей пользоваться, а не спать месяц, а потом судорожно пытаться понять «Кто я, Где я, Зачем все это, ГОСПОДИ ПОМОГИ ?!».
Вопрос: Как это соотносится с листами учета рабочего времени?
Ответ: Отлично соотносится – просите консультантов указывать на какой процесс в каком функциональном блоке он потратил время – будете понимать за что Вы платите людям и куда уходят часы проекта.
Вопрос: Все это как-то сложно выглядит – а есть какая-то система проектного управления, которая использует такой подход?
Ответ: В бытность свою я написал свою, когда понял, что проджекта не хватает. Написал традиционно на 1С, как расширение для 1С:Документооборота. Сейчас готовлюсь выложить на Инфостарт – добавьте статью в избранное и посмотрите через месяц – будет обновление – выложу скорее всего за какие-нибудь символически 2-3 стартмани.
Что будет дальше – дальше я планирую написать о том, как выглядит проектная бюрократия – что за документы мы оформляем на каждом этапе и подэтапе работ, как они выглядят и зачем они нам нужны.
Традиционный блок с предыдущими материалами (последние две статьи как-то незаслуженно мало людей увидело - рекомендую):
Как умирают розовые единороги, или бизнес-автоматизация как способ сделать людей несчастными
Как успешно выполнить проект автоматизации и получить от этого удовольствие – часть первая
