Для начала я хотел бы развести понятия системного менеджмента
(СМ) и системного управления проектами (СУП). Под СМ я подразумеваю
использование системного мышления применительно к предприятию, см. курс Техинвестлаб
по системноменеджерскому мышлению. Под СУП я подразумеваю один из подходов –
Акселос, ПиЭмАй фаундешенел стэндардз, АйСиБи и П2М. При этом, Основные
стандарты (условный ОПМ3) в части ПМБОК берет на себя роль метатекста, давая
онтологию для проектного управления (ПУ), а вместе с остальными основными
стандартами ПиЭмАй является описанием жизненного цикла (ЖЦ), который описывает
5 практик – инициация, планирование, исполнение, контроль, закрытие ко всему
холону плановой деятельности предприятия, с разбивкой этих практик на
подпрактики для проектов, программ и портфтелей. Примерное похожая ситуация с
подходом Акселос, но там, насколько помню, нет метатекста, онтология вшита в
тексты стандартов.
В моем мире все основные СУПы системные и по ОМГ Эссенс покрывают
альфы «Стейкхолдеры» и «Возможности» (Ст. ПгМ и ПфМ это как раз по большей
части про это, как с точки зрения распределения и привлечения ресурсов, так и с
точки зрения управления пользой и рисками, ПгМ и ПфМ явно указывают на подотчетность),
«Требования» (покрыты слабо, но в части управления качеством и конфигурацией
кое-что есть), «Работы» - комментировать даже не стоит, «Команда» (Ст. ПгМ,
ПМБОК явно указывают практики развития команды), «Технологии» (Ст. ПгМ, см. Програм
Сет-ап и Транзишен плэннинг). Здесь есть ключевой момент, важный для дальнейшего
понимания, ПМБОК является метатекстом, основные знания по управлению проектами
лежат в других текстах, и это явно указано в тексте документа, и именно знание
реальных практик проектного управления, а не знание и понимание онтологии ПУ
проверяется на экзамене ПМП. Чаще всего базовыми текстами по ПУ являются Керцнер
и Малкахи.
Разработчики ПиЭмАй осознанно оставили в стороне практики
управления системой – альфы «Требования» и «Воплощение системы», т.к. это как
раз вотчина системной инженерии и создавать новую онтологию смысла никакого
нет. Так что и получается та самая смычка между системными инженерами и инженерными
менеджерами, у которых совпадает мотивация – сделать проект с нужным качеством,
в срок и бюджет, но у каждого из них свой объект управления и свое пространство
выбора. Одни сосредоточены на слое Система, другие на Возможностях и Предпринятии.
И есть у меня подозрение, что если расписать Эссенс по подальфами, то граница
между СИ и ИМ пройдет достаточно четкая, так что можно будет навести интерфейсы
с достаточно жесткими контрактами. И к решению этой задачи, на мой взгляд,
военные ИМ и СМ США подошли ближе всех.
Возвращаясь к основному вопросу – почему же тяжело продавать
СМ, равно как и СУП? Взгляните на ситуацию глазами предпринимателя. Приходят к
нему внедренцы СУП, пусть даже вся святая троица – логисты, вендоры ИТ решения
и организаторы, см. обсуждение https://www.facebook.com/alex.turkhanov/posts/10210400088615611
Что могут показать команды СУП? Огромный многолетний пласт решений,
сотни тысяч кейсов, миллионы специалистов, выбор всего и вся во всех отраслях. Взять
одни только отраслевые журналы, выпускаемые ПиЭмАй, и того хватит за глаза,
чтобы объективно доказать полезность внедрения СУП. Но не хватает, т.к.
внедрение ПУ – это внедрение менеджмента вообще, много раз об этом писал и не
только я. Начинать внедрение ПУ надо с Get Things Done и трекеров, А в части
СМ пространство решений и данных об их эффективности настолько мало, что просто
незаметная величина. И ставить СМ будут только венчурные капиталисты, да и то,
если команда сможет показать, что СМ дает 50% роста эффективности по сравнению
с СУП. А мы тут сами еще не разобрались, что от чего чем отличается, как же мы
продадим другим?
Что еще было по теме?
О регулярном менеджменте хорошо у Александра Фридмана:
ОтветитьУдалитьhttp://www.asfridman.com/