воскресенье, 30 октября 2016 г.

Почему сложно продавать системный менеджмент?


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

1 комментарий:

  1. О регулярном менеджменте хорошо у Александра Фридмана:
    http://www.asfridman.com/

    ОтветитьУдалить