?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Управление конфигурацией [27 May 2011|11:56am]
Управление конфигурацией (configuration management) -- это про связь наших ожиданий (проектов) с реальностью.

Как всегда, "управление чем-то" ни разу не "управление", а обозначает "всё необходимое, чтобы это что-то было в приличном состоянии".

Конфигурация -- это знание о том, какова работающая (актуальная) система, выделенная из множества ее возможных вариантов (т.е. какие насосы лежат запчастями на складе, а какие таки установлены и работают; какой из пяти рассматривавшихся вариантов реализации предохранительного клапана пошёл в проект, а какие только остались в виде эскизов; какие из требований были отклонены, а какие утверждены и поэтому требуют внимания).

Управление конфигурацией -- это техническая дисциплина системной инженерии, обеспечивающая поддержание надлежащей (задуманной, одобренной) конфигурации системы во время всего её жизненного цикла. Если говорить попроще, то управление конфигурацией -- это практика, обеспечивающая на протяжении всего жизненного цикла совместимость версий (отсутствие коллизий!) и полноту частей системы (отсутствие коллизий!).

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

Управление конфигурацией включает в себя "истинную теорию", ибо имеет собственные понятия: базис (baseline) -- утвержденная конфигурация, версия/ревизия (version/revision). Конечно, наличествует и "управленческиконфигурационный шовинизм", когда в состав управления конфигурацией записывают и много чего другого. Из этого "многого другого" нужно прежде всего выделить общую теорию учёта/регистрации. Это ведь общее знание для бухгалтерского, депозитарного, складского, регистрационного, конфигурационного учёта: каким образом обеспечивать взаимное соответствие реальности и записей о реальности.

Дисциплина управления конфигурацией имеет следующие основные основные практики:

1. Идентификация -- поддержка инженерных разбиений (классификаций, кодировок) и именования/кодировки отдельных конфигурационных единиц (configuration items). Именно тут обсуждаются PBS, GBS, WBS и разные системы кодировок типа RDS-PP, KKS, RTM, S1000D и т.д.

2. конфигурационный (т.е. специализированный -- так же, как бухгалтерский, депозитарный, складской и т.д.) учет/регистрация -- административное обеспечение взаимного соответствия: 1. проекта (включая требования), 2. исполнительной документации (as built, "что мы думаем о реальной системе"), 3. самой системы "в железе и бетоне". Обычно обеспечивается наличием конфигурационной базы данных (CMDB -- сonfiguration management data base) и административными процедурами по её ведению. Учёт включает в том числе и административные процедуры по назначению ведущего учёт (регистратора), передаче ведения учёта от регистратора регистратору, делегированию полномочий по учёту в порядке распределенной учётной деятельности и т.д.

3. контроль версий (version/revision control): обеспечение того, что базис (утвержденная для каких-то целей конфигурация) собирается из взаимно соответствующих версий частей системы (будь то версии проектной или исполнительной документации, или же версии самой системы "в железе и бетоне"). Софтверщикам с их CVS и SVN против git и Mercurial должно быть понятно, о чем это.

Управление конфигурацией очень просто, когда есть один административный центр, который вводит
а) обязательную идентификацию
б) обязательный регламент учёта
в) централизованное версионирование

Проблемы возникают при распределенной разработке (collaborative engineering, concurrent engineering), где каждая из участвующих в проекте организаций имеет собственные предпочтения по управлению конфигурацией (кодировки, учётные регламенты, версионирование). Собрать из этого распределенного конфигурационного месива базис обычно представляет собой непростую задачу. Так, любая PLM-cистема поддерживает управление конфигурацией. Но вот если у вас в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то у вас немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ), а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.

Коллизии, возникающие из проблем управления конфигурацией -- самые распространенные. Отсутствие управления конфигурацией как раз и характеризуется словами "у них там бардак". Поэтому разворачивание технологии управления конфигурацией -- центральная забота при создании СУЖЦ.

Конечно, управление конфигурацией требует указания метода (управлять конфигурацией можно очень и очень по-разному, есть самые разные теории на этот счёт -- теории идентификации, учёта, версионирования). Управление конфигурацией требует обучения людей -- это дисциплина, её нужно знать, и ей нужно дисцилинированно следовать. Управление конфигурацией требует разворачивания в организациях технологии: конфигурационных баз данных, справочников по кодировкам, систем версионирования и т.д.
22 comments|post comment

Управление технологией как второй контур зрелости проектного управления [27 May 2011|07:43pm]
Выступал сегодня как key speaker на круглом столе "Зрелость в управлении проектами -- цель или средство". Второй key speaker полностью раскрыл тему зрелости как таковой, и мне оставалось только рассказать про "Управление технологией как второй контур зрелости проектного управления", для чего я приготовил целых три слайда:



Вот кратенько несколько тезисов:

1. Методов проектного управления множество, и это нельзя недооценивать. Более того, этих методов уже четыре поколения :
-- первое, где проектами называлось отнюдь не всё, и важна была роль сетевого планирования.
-- второе, где проектами обзывается всё что угодно, и проектное управление шовинистически захватывает большие куски других дисциплин
-- третье, где проекты, программы, и вообще менеджмент тесно склеены друг с другом (собственно, это деление на поколение как раз обсуждается в документах методологии третьего поколения P2M -- http://www.pmaj.or.jp/ENG/P2M_Download.htm).
-- четвертое, моделе-ориентированное -- где модели продукта и модели проекта (project) тесно связываются друг с другом, а методология опирается больше на динамическое планирование и last planners ("полевых инженеров"), нежели на предварительное и first planners (специальных планировщиков в штаб-квартире). Грубо говоря, планирование становится еще более инженерным, а менеджмент -- еще более личностно-ориентированным.

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

3. В силу "проектного шовинизма" сам предмет проектного управления стал совсем неохватным за счёт прихвата самых разных менеджерских дисциплин, и сейчас почти эквивалентен уже "просто менеджменту". Поэтому разговор о технологиях замыливается обсуждением общеменеджерских ситуаций, в которых специфика собственно проектного управления никак не проявляется. При этом зачастую забывается, что проектное управление более глубоко изучается в курсах инженерного менеджмента, нежели на курсах MBA -- прежде всего за счет более глубокого изучения предмета исследования операций ("фабричной физики" -- как потоки материалов и работ движутся по предприятию в ходе жизненного цикла продукции).

4. Четвертое (моделеориентированное) поколение пока еще очень молодо. Но сама тема планирования работ, основанная на технологических производственных моделях и моделях продуктов уже поднимается во многих и многих организациях. Так, активно обсуждается (а кое-где уже делается) порождение графика работ из 3D-модели, где каждая деталька должна быть вовремя закуплена, вовремя выдана в монтаж, вовремя и без проблем с ресурсами смонтирована, вовремя проверена -- и так для всего инженерного объекта в целом. План работ включает в себя не только плашку из диаграммы Гантта, но и мультфильм, где рабочему показывается, какую именно работу и с какими именно объектами делает этот рабочий, и за какое время ожидается, что он эту работу выполнит.

5. Всё вышесказанное относится, увы, больше к более-менее понимаемым строительно-монтажным, машиностроительным и прочим "строительным/сборочным" по типу работам. Ежели речь идёт о творческой работе типа проектирования/конструирования, то тоже можно говорить о проектном управлении, но опять-таки, меняются его методы. Управление коллективным проектированием (collaborative design) и управление сооружением (construction management) -- это совсем разные управления, и методы управления проектами (project) в их составе будут крайне разные. Кстати, проектный шовинизм приводит к тому, что управление проектированием и управление сооружением часто включают внутрь проектного управления, а не наоборот -- задумайтесь, насколько это полезно для дела.

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

navigation
[ viewing | May 27th, 2011 ]
[ go | previous day|next day ]