Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Об системную схему предпринятия: эх, раз, ещё раз...

Пожалуй, пришло время сделать ещё один содержательный шаг по линии инженерии предприятия: доработать системную схему проекта на базе Essence так, чтобы включить туда описания и возможность развития на уровне программ. Предприятие -- это обычно программа (много проектов), оно выживает смену целевых систем, удерживает как-то сотрудничество многих команд. На этом уровне сразу появляется проблема масштабируемости, "бригады бригад". Именно этот перескок между программой и проектом отличает поколения проектного управления (в P2M нельзя управлять отдельным проектом, только программой в целом, но даже в хвалёном ISO 15288 проектное управление существует как старинное "управление одиночным проектом", хотя и есть отдельно organization-enabling практики, типа добавления проекта к портфелю проектов).

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

Спасибо Александру Турханову, который подтолкнул меня к этим размышлениям: дискуссии прошли в комментах https://www.facebook.com/photo.php?fbid=10211629123980727&set=a.10210218569517747.1073741832.1145074069&type=3 (и пока это выглядело как развитие темы лидерства -- пририсовывание необходимых сущностей к классическим диаграммам, я особо не вдавался в детали), потом это было обозвано системной схемой предприятия и тут я напрягся и понял, что нужно возвращаться к доработке основных диаграмм -- в https://www.facebook.com/alex.turkhanov/posts/10211638656299029

При этом я предпочёл бы пока говорить только об альфах и классическом Essence и его расширении на иженерию предприятия, пока не переходя к ArchiEssence -- и так всё сложно, поэтому решаем задачу по частям: нужно сначала договориться об онтологии, а уж потом о том, чем эту онтологию моделировать в ArchiMate.

Повторю тут часть своих комментов по проблеме из помянутых фейсбуковских тредов:

Я предпочитаю не говорить "модель ЖЦ", но "вид ЖЦ" -- и считать, что это как-то организованные практики. Если же сам ЖЦ, то там и практики и стадии (т.е. работы) -- оба view на ЖЦ. А ЖЦ ещё и воплощение, так что говорим отдельно об определении ЖЦ и о самом ЖЦ. При этом ЖЦ проекта -- только часть полного, "истинного системного" ЖЦ, проходящего через много предпринятий, много проектов.

У меня была уже пара подходов к этому снаряду (типа просто нарисовать рядом пару диаграмм, где предпринятие одного проекта есть воплощение системы другого проекта, я ряд других подобных ходов), но они все не слишком удовлетворительны были.

Классическим ответом было бы, конечно, просто проигнорировать Essence и выдать "определение и воплощение обеспечивающей системы" в зоне интересов предпринятия, но теряется аспект execution и разные view на предприятие (процессы, артефакты, команда).

Тут ещё важно, что нельзя потерять выразительность для инженеров -- если переакцентировать схемы для менеджеров, то инженеры потеряют интерес, и адью коммуникация, будет разговор бизнес-аналитиков с бизнес-аналитиками или аналитиков с реальными менеджерами, а инженеры опять останутся без поддержки. Так сказать, повторение судьбы SPEM и ISO 24744, которые были направлены на поддержку аналитиков и методологов, а не использование стандарта на практике инженерами и менеджерами "в поле".

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10209318674857928
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 5 comments