Введение
Пост к заданию из курса Системной инженерии - рецензия материала по управлению конфигурацией с привязкой к своей деятельности.
Моя сфера - инфраструктурные проекты, а опираться буду на предложенную книгу, "Configuration Management for Senior Managers", автор Frank Watts.
Книга описывает процесс производства электронного оборудования, и иногда указывает различия в процессах для разработки программного обеспечения. Чувствуется, что написана она практиком с огромным опытом, собравшим за свою карьеру всевозможные шишки в своей дисциплине в различных организациях. Уточнение: мне кажется, не стоит пользоваться книгой как учебником постановок практик конфигурации с нуля. Для этого стоит поискать другую литературу.
Эволюционная лестница CM
Посмотрите на лестницу оценки - если вы видите свои процессы на ней, пусть даже на ступени E, тогда книга будет полезной. Как руководство для поиска подводных камней в существующих процессах, постепенного улучшения, продвижения по лестнице до уровня Best In Class книга - это то, что прописал доктор.
Зачем
Управление конфигурацией (Configuration Management, далее CM) - организация осмысленного, точного, эффективного, понятного, минимально контролируемого, измеряемого процесса проектирования и описания нашей системы в течение всего срока ее существования.
Несколько доводов из книги, почему CM важен для организации:
- Заказчик должен получать то, что он заказал и в обещанные сроки.
- Контроль проектных чертежей, спецификаций и ведомостей оборудования критичен при повторяющемся производственном цикле.
- СМ увеличивает прибыльность через снижение стоимости продукта, повышение скорости выпуска релизов и отработки изменений.
- Отслеживание конфигурации продукта для дальнейшего траблшутинга, обслуживания, модернизации.
- Комплаенс.
- Личная ответственность.
Негативный принцип: Мы не можем найти время, чтобы сделать что-то правильно, но всегда находим, чтобы переделать это заново.
Кажется, любимая автором картинка о важности CM
Базовые блоки
CM система, по книге, состоит из следующих базовых процессов:
- Релизы.
- Запросы на изменения.
- Проведение изменений.
- Ведомости материалов.
Также могут добавиться:
- Оформление заказов.
- Отклонения от спецификации.
Очень важны метрики: мы должны измерять то, чем мы управляем.
Вот именно ситуация с метриками не дает подняться нашей организации со ступеньки D на С, то есть перейти с уровня "приемлемый/сойдет" на "эффективный/двигает вперед". Метрики не считаем и не применяем, поэтому процесс получается статичный, не развивающийся, реактивный:
- сделали проектный документ,
- провели через документ-контроль,
- сделали запись в Excel файла реестра проектной документации с версией, датой выпуска релиза,
- отправили по электронной почте трансмиттал заказчику с проектным документом и выдержкой из реестра,
- получили подтверждение о получении,
- дождались комментария: принято, принято с комментариями (запросом на изменение), отклонено,
- при необходимости, перезапустили цикл.
Нет метрик - не можем видеть, где у нас ограничения в рабочем потоке, насколько нас притормаживают запросы на изменения, как проекты отличаются между собой. Не можем сконцентрироваться на улучшениях в качестве и скорости работы. А может, кто знает, мы и так все лучше и лучше работаем на каждом проекте? Вот был бы приятный сюрприз.
После внедрения метрик:
Собрать команда из максимум 3-4 человек - одного из СМ, второго из инжиниринга, третьего из обслуживания. Цель - разработка новой диаграммы рабочего потока, work flow. Плюс форм и инструкции к ним, стандартов.
Про закуп нового софта и автоматизацию: сначала описываем процесс, и только потом подбираем технологию. Не наоборот.
Подписи
Политика: Утверждения идут по принципу "Ветчина и яйца": курицы участвуют, но полностью вовлечена только свинья.
Хорошая модель для правил работы с подписями: один разработчик документа и один утверждающий. Больше - не надо.
У нас в организационным процессе прописано превышение: утверждающих двое. При следующем цикле улучшений надо провести эксперимент, уменьшить до одного.
CM и документ-контроль
Есть документ-контроль (в книге и нашей организации), а есть управление конфигурацией (в книге). Что надо добавить к документ-контролю, чтобы получить CM:
- координацию технических функций документ-контроля,
- фильтрацию запросов, не добавляющих стоимости,
- разработка метрик (дааааа!),
- доступ к журналу изменений и отчетам,
- управление качеством документов,
- аудит системы,
- бенчмаркинг и постоянное улучшение.
Релизы
Политика: фазы должно четко отражаться на парт-номерах, BoM-ах, а также названии документов и чертежей.
Политика: ответственный руководитель должен убедиться, что CM стандартизирует и отслеживает таблицу маркировки релизов (phase release chart). Это критический стандарт для предприятия
В нашем организационном процессе схожая схема присутствует.
Ведомости материалов и оборудования
По книге: управления конфигурацией ведомостей материалов и оборудования (Bill of Materials, BoM) - важная и неотъемлемая часть CM.
В нашей организации: относимся к BoM как к еще одному проектному документу. То есть, упускаем:
- Контроль внутреннего содержания списка материалов и оборудования и их версионность. Один из советов работы с содержанием, взятый из книги - маркировать новые строчки датой релиза документа, в котором эта строка была изменена.
- Те BoM, что готовятся на стадии предпродажного обсуждения и коммерческих предложений. А ведь там часто проходит обсуждение в несколько итераций, и очень важно, чтобы все изменения отслеживались и проходили процесс управления изменениями.
Управление изменениями
К чему стремиться (и что недостаточно четко прописано и также неважно работает): отработанный процесс управления изменениями в командной работе, с целью минимизировать когнитивные искажения. Обязательно учитывать при go/no-go решениях и расстановке приоритетов окупаемость изменений.
Итоги
Если мы работаем с постоянным улучшением процесса:
- Обязательна поддержка менеджмента
- Должен быть хозяин CM процесса - "миссионер"
- по меньшей времени 50% времени он тратит на улучшение процесса.
- В первую очередь развертываем метрики и диаграммы процессов
- В идеале требуется не менее 50% рабочего времени еще трех человек - с эксплуатации, инжиниринга и закупок.
- Пишем общие стандарты, запускаем, тестируем, пересматриваем, заново запускаем, убеждаемся, подписываем, применяем.
- После общих - внедряем небольшие изменения. В приоритете те, что легче всего внедрить.
- Начинаем с общего стандарта, затем внедряем небольшие изменения.
Платиновая политика - любой процесс, придуманный человеком, может быть улучшен человеком