Стратегия развития предпринятия и её моделирование
"Стратегия развития предпринятия" -- чтобы разобраться, нужно ответить на вопросы:
-- что такое стратегия и как стратегировать(ся)
-- что такое развитие и как развивать(ся)
-- что такое предпринятие (а поскольку предприНятие это социотехническая система, то что такое система и какие особенности у социотехнической системы).
Дополнительная проблема в том, что "стратегия", "развитие" и "предпринятие" невидимы. Ответы на все эти вопросы абстрактны в силу абстрактности самого предмета обсуждения.
Нужно моделирование, что бы невидимое сделать видимым -- обсуждать их нужно, используя модели. Стратегия невидима и поэтому плохо обсуждаема, но стратегическое описание вполне видимо и обсуждается много проще. Развитие невидимо, но описание развития вполне видимо. Для обсуждения стратегии развития предпринятия нужно моделировать.
Чтобы моделировать, нужно иметь соглашение о моделировании:
-- что является важным, а что не важным (модель сохраняет только важные для того или иного интереса свойства объекта). Что важно для выражения стратегии, развития, предпринятия?
-- какие термины, какую нотацию мы выберем для обозначения объектов и отношений (или объектов и свойств, если моделирование объект-ориентированное), какой моделер будет удобен в использовании?
Королём всех моделеров на сегодня является MS Word, а королевской нотацией -- естественный язык, на котором потенциально можно выразить всё. Но естественный язык:
-- не позволяет компактифицировать описание. Формула, написанная словами обычно нечитаема и плохо понятна. 2*2=4 и "два умноженное на два равно четырём": почувствуйте разницу.
-- с текстом нельзя производить синтаксические/доктринальные преобразования (типа формульных подстановок, когда можно отвлечься от физического содержания формул и оперировать только с алгебраической формой)
-- не позволяет легко проверять модель. Если в тексте написано "пойти" или "послать", то можно только гадать, что там имелось ввиду. Модель в этом случае может требовать указать, куда именно -- и отсутствие указания может быть найдено чисто формально. Синтаксические ошибки моделирования это явно не все возможные виды ошибок, но их нахождение будет хоть какой-то помощью софта моделера для пытливого стратегирующего и развивающего предпринятие ума.
Так что мы будем использовать формальное моделирование и дальшейшее рассуждение показывает один из вариантов использования моделирования в стратегировании.
Предпринятие -- это социотехническая система. Те стейкхолдеры, которые озабочены развитием предпринятия, имеют к нему стратегический интерес, интерес целеполагания. Помним, что предприНятие это и предприятие (которое со счётом и владельцами), и рабочая группа проекта, и какая-нибудь "система проектного управления нашего холдинга" (состоящая в том числе из организованных для проектного управления людей и поддерживающих их софта).
Стратегия (определение стратегии, strategy definition, данное нам в ощущениях-рабочих продуктах как стратегическое описание, стратегическая модель) -- это модель целеполагания (motivation model, типа OMG BMM http://www.omg.org/spec/BMM/, или ArchiMate motivation extension http://pubs.opengroup.org/architecture/archimate2-doc/chap10.html#_Toc371945252, если говорить об архитектурных языках). Это разные изводы GORE (goal-oriented requirements engineering -- http://ailev.livejournal.com/811715.html), развитие идеи системного подхода о том, что всё есть системы, у систем есть стейкхолдеры, у стейкхолдеров к системам есть деятельностные интересы и эти интересы крайне важны для фокусирования требований к системе.
Развитие предпринятия -- это постановка новых практик работы, это и есть продвижение предпринятия по его жизненному циклу, чтобы оно осваивало всё новые и новые умения делать своё дело (http://ailev.livejournal.com/1032324.html, и там можно ещё различить развитие и совершенствование. Для совершенствования не нужна постановка новых практик -- http://ailev.livejournal.com/1032133.html). Стратегия развития -- это зачем и какие новые практики работы осваивает предприятие. Обратите внимание, я не использую слова "внедрение", "впендюривание" и прочие push-слова. Хотя слово "постановка" в постановке практи и подразумевает того, кто ставит и того, кому ставят эти практики, но оно как-то более конструктивно.
Практики -- это дисциплина плюс технология. Развить предприятие -- это получить по-новому дисциплинированных (т.е. образованных в новой дисциплине -- своих обучить или новых нанять) людей и развернуть технологию (купить или разработать софт, станки, изменить процессы и т.д.). Например, если в стратегии развития указана постановка практик проектного управления, то нужно обучить проектному управлению людей (или нанять уже обученных), закупить проектный софт и выстроить работу по-новому. Постановка практики проектного управления или создание системы проектного управления (как социотехнической подсистемы предпринятия)-- это одно и то же.
Если постановка практики сводится к созданию системы, то используем традиционный инженерный подход: стратегия это про нужды (needs) использующей системы и фокусирование их в требования (что и зачем мы будем делать, "чёрный ящик"), а ещё нам при стратегировании потребуется принять основные решения по тому, как будет устроена наша новая технология: принять архитектурные решения.
Для того, чтобы обсудить добавление новой (или изменение старой) технологии работы, нужно иметь архитектурное описание предпринятия as is и to be: отмоделировать, как взаимодействуют люди, как бегают софты и как урчит оборудование. Если мы хотим подчинить архитектуру стратегии, то мы должны показать, как эти изменения соответствуют модели целеполагания, т.е. стратегии.
Итого: стратегия это модель целеполагания, а стратегия развития предпринятия -- это архитектура предприятия, поддерживающая новые практики работы с указанием целеполагания в части изменения этой архитектуры.
Конечно, идеальным вариантом тут будет использовать ArchiMate 2.1, в котором мы должны будем:
-- представить модель стратегии через motivation extension (помним, что там учли и опыт OMG BMM, и KAOS и i*, результат получился довольно приличный)
-- представить практики работы (можно ограниченно использовать ArchiMate как язык онтологического моделирования дисциплины и вначале выполнить что-то типа domain-driven architecture design по идеям DDD -- https://en.wikipedia.org/wiki/Domain-driven_design. А можно и без дисциплины -- сразу задействовать основной набор элементов ArchiMate для представления технологии, разве что там традиционные проблемы с моделированием физического сырья и обрабатывающего оборудования).
-- представить модель изменений (формально в ArchiMate это implementation and migration extension -- http://pubs.opengroup.org/architecture/archimate2-doc/chap11.html#_Toc371945277, но работать с этим в простейших моделерах типа Archi я не понимаю как: нужны продвинутые моделеры, чтобы удерживать и to be, и as is архитектуры, и много чего ещё).
-- есть ещё часть архитектуры, в которой представляется "штаб" развития, предпринятие развития. То есть нам нужно ещё определить и отмоделировать практики штабной/стратегической работы, технологии развития. Нужно ли заниматься стратегированием стратегирования, думайте сами. В принципе, этот пост как раз про стратегию стратегирования в самом общем виде! В ArchiMate это может быть примерно по идеям http://masteringarchimate.com/2011/05/21/modelling-it-in-your-organization-a-broader-perspective/, но равно можно использовать и последнюю картинку из http://ailev.livejournal.com/1160014.html, там в основе OMG Essence:
Тут мы подошли к ещё одному вопросу: ибо OMG Essence тоже язык описания практик работы предпринятия. Мы тут используем модификацию OMG Essence в варианте для системной инженерии (модификация описана в учебнике системноинженерного мышления http://techinvestlab.ru/systems_engineering_thinking или краткий английский текст Towards a Systems Engineering Essence http://arxiv.org/abs/1502.00121).
Если ArchiMate изначально нацелен на "процессы" и описание технологий, то Essence нацелен на управление жизненным циклом проекта с акцентом на дисциплины и использование контрольных вопросов к специальным объектам-альфам, определяемым дисциплиной практики.
Хотелось бы иметь если не полноценный и всеховатный язык системного моделирования (SysMoLan, http://ailev.livejournal.com/1127145.html), то хотя бы ArchiEssence -- стиль моделирования в ArchiMate, который поддерживал бы выражение тех идей, для которых обычно используется Essence. Для создания ArchiEssence нужно решить огромное число онтологических проблем в обоих языках, и мы тут двигаемся потихоньку (например, наши уточнения для модели целеполагания/стратегирования в ArchiMate -- http://ailev.livejournal.com/1199268.html).
Прежде всего, давайте убедимся, что в ArchiMate у нас достаточно средств для выражения основных альф и выражающих их рабочих продуктов:
-- возможности: тут мало что можно сказать, но это место мутновато и в Essence. Needs можно пробовать моделировать через расширение целеполагания ArchiMate (требования/задачи/обеспечения и ограничения, http://ailev.livejournal.com/1199268.html). Ну, и всё остальное по мелочи. Тут Essence используем в качестве чеклиста: "в вашей ArchiMate модели нужно отразить Возможности".
-- роли и стейкхолдеры (для команды и стейкхолдеров). Там есть нюансы различий между Business Role и Stakeholder в ArchiMate, и замечание в Essence, что Teammember является одновременно подальфой Stakeholders и Team, но давайте не будем пока вдаваться в подробности. Важней то, что в ArchiMate есть ещё и способ выразить "рабочий продукт" для роли -- исполнителя, назначаемого на роль (Actor).
-- воплощение системы. Тут проблемы, ибо ArchiMate нацелен исключительно на определение системы (т.е. каждый объект деятельности в нём представляет информационный объект, а не физический! Для моделирования физического мира ArchiMate не предназначен. См. на краткое описание проблем тут: http://masteringarchimate.com/2014/06/23/modelling-physical-enterprise-architecture-with-archimate/ и http://masteringarchimate.com/2014/07/04/reframing-archimate-about-the-physical-domain-layers-and-recursion/). Но если в целевой системе только люди и компьютеры (но не сырьё и станки), то ArchiMate тут как-то справится.
-- определение системы: определения/definitions разного рода в ArchiMate это business object, объект деятельности (business это "дело" в переводе). И его выражает рабочий продукт -- representation (представление/описание/description), об этом немного в http://ailev.livejournal.com/955954.html.
-- команда: роли в деятельности и как рабочие продукты назначенные на них люди (business roles и actors).
-- технологии: мне кажется, что наиболее близко к artifact-based представлению деятельности тут практики (business functions), которые суть деятельность в её абстрагировании от последовательности исполнения (то есть абстрагировании от activity-based представления, "процессного").
-- работа: процессы (processes).
Для каждой подальфы нужно будет принимать решение, как её моделировать. Но Essence тут выполняет роль списка контрольных вопросов: что нужно моделировать, какие объекты внимания нужно иметь в предпринятиях по постановке практик (помним, что таких предпринятий два -- развивающее и развиваемое предпринятие).
Ещё в Essence хороши состояния альф и контрольные вопросы. Моё предложение -- моделировать эти состояния архимейт-событиями (event) наступления этих состояний альф, в том числе частных состояний ответа на отдельные вопросы. Я бы не рекомендовал при этом делать трюки типа трактовки отношения часть-целое в ArchiMate как темпоральной части: не поймут-с. Нет, объект держит идентичность (имя), связанные с ним события держат изменения его состояния, практики меняют его состояние (отношение доступа, access).
Отдельно нужно упомянуть и Strategy and Tactics Tree Голдратта (http://ailev.livejournal.com/567097.html, и даже попытку выражать это в ISO 24744 http://praxos.livejournal.com/6777.html), но об этом как-нибудь в другой раз. В любом случае, это тоже можно будет выражать на ArchiMate и тоже сводится к определению практик для их постановки (у Голдратта, конечно, это практики TOC).
Тут нужно помнить, что никакой ArchiMate или Essence не позволят вам записать стратегию, т.е. определить цели и выбрать практики по их достижению. Это лишь иероглифы, которые содержат совсем чуть-чуть знаний о предметной области инженерии предприятий. Что этими иероглифами записывать -- это совсем отдельный разговор. Роли стратега и модельера стратегии могут исполняться одним и тем же лицом, но могут быть разнесены и на разные лица.
Но эти иероглифы из ArchiMate и знание о том, что важно в предпринятии из альф и чеклистов Essence позволяют организовать мышление и не упустить что-то важное.
Последний часто встречающийся вопрос: показывать ли все эти модели стратегии менеджерам и прочим стейкхолдерам? Ответ: скорее всего, не показывать. Им нужно показывать упрощённые powerpoint слайды. Моделировать стратегию нужно для того, чтобы по-инженерному вгрызаться в детали, находить и исправлять ошибки, оценивать риски и вообще заниматься стратегией профессионально. А "вовне" из этой кухни выдаются глянцевые картинки. У "железных инженеров" тоже их 3D-модели и прочностные расчёты никому не показываются, а всем внешним стейкхолдерам предъявляются красивые фотореалистические модели внешнего вида. Инженеры предприятия тут ничем не лучше и не хуже, только вместо 3D САПР у них ArchiMate моделер, а вместо программы фотореалистического рендеринга продукта у них PowerPoint.
При всём при том модели стратегии и архитектуры предпринятия (даже в их ручном переложении в PowerPoint слайды) -- это великолепные коммуникационные продукты, они делают невидимое видимым и позволяют обсуждать то, что без них скорее всего ушло бы от осознания. Это значит, что с ними будет выявлено и учтено больше рисков, с ними будет выявлено и удовлетворено больше разных интересов стейкхолдеров.
-- что такое стратегия и как стратегировать(ся)
-- что такое развитие и как развивать(ся)
-- что такое предпринятие (а поскольку предприНятие это социотехническая система, то что такое система и какие особенности у социотехнической системы).
Дополнительная проблема в том, что "стратегия", "развитие" и "предпринятие" невидимы. Ответы на все эти вопросы абстрактны в силу абстрактности самого предмета обсуждения.
Нужно моделирование, что бы невидимое сделать видимым -- обсуждать их нужно, используя модели. Стратегия невидима и поэтому плохо обсуждаема, но стратегическое описание вполне видимо и обсуждается много проще. Развитие невидимо, но описание развития вполне видимо. Для обсуждения стратегии развития предпринятия нужно моделировать.
Чтобы моделировать, нужно иметь соглашение о моделировании:
-- что является важным, а что не важным (модель сохраняет только важные для того или иного интереса свойства объекта). Что важно для выражения стратегии, развития, предпринятия?
-- какие термины, какую нотацию мы выберем для обозначения объектов и отношений (или объектов и свойств, если моделирование объект-ориентированное), какой моделер будет удобен в использовании?
Королём всех моделеров на сегодня является MS Word, а королевской нотацией -- естественный язык, на котором потенциально можно выразить всё. Но естественный язык:
-- не позволяет компактифицировать описание. Формула, написанная словами обычно нечитаема и плохо понятна. 2*2=4 и "два умноженное на два равно четырём": почувствуйте разницу.
-- с текстом нельзя производить синтаксические/доктринальные преобразования (типа формульных подстановок, когда можно отвлечься от физического содержания формул и оперировать только с алгебраической формой)
-- не позволяет легко проверять модель. Если в тексте написано "пойти" или "послать", то можно только гадать, что там имелось ввиду. Модель в этом случае может требовать указать, куда именно -- и отсутствие указания может быть найдено чисто формально. Синтаксические ошибки моделирования это явно не все возможные виды ошибок, но их нахождение будет хоть какой-то помощью софта моделера для пытливого стратегирующего и развивающего предпринятие ума.
Так что мы будем использовать формальное моделирование и дальшейшее рассуждение показывает один из вариантов использования моделирования в стратегировании.
Предпринятие -- это социотехническая система. Те стейкхолдеры, которые озабочены развитием предпринятия, имеют к нему стратегический интерес, интерес целеполагания. Помним, что предприНятие это и предприятие (которое со счётом и владельцами), и рабочая группа проекта, и какая-нибудь "система проектного управления нашего холдинга" (состоящая в том числе из организованных для проектного управления людей и поддерживающих их софта).
Стратегия (определение стратегии, strategy definition, данное нам в ощущениях-рабочих продуктах как стратегическое описание, стратегическая модель) -- это модель целеполагания (motivation model, типа OMG BMM http://www.omg.org/spec/BMM/, или ArchiMate motivation extension http://pubs.opengroup.org/architecture/archimate2-doc/chap10.html#_Toc371945252, если говорить об архитектурных языках). Это разные изводы GORE (goal-oriented requirements engineering -- http://ailev.livejournal.com/811715.html), развитие идеи системного подхода о том, что всё есть системы, у систем есть стейкхолдеры, у стейкхолдеров к системам есть деятельностные интересы и эти интересы крайне важны для фокусирования требований к системе.
Развитие предпринятия -- это постановка новых практик работы, это и есть продвижение предпринятия по его жизненному циклу, чтобы оно осваивало всё новые и новые умения делать своё дело (http://ailev.livejournal.com/1032324.html, и там можно ещё различить развитие и совершенствование. Для совершенствования не нужна постановка новых практик -- http://ailev.livejournal.com/1032133.html). Стратегия развития -- это зачем и какие новые практики работы осваивает предприятие. Обратите внимание, я не использую слова "внедрение", "впендюривание" и прочие push-слова. Хотя слово "постановка" в постановке практи и подразумевает того, кто ставит и того, кому ставят эти практики, но оно как-то более конструктивно.
Практики -- это дисциплина плюс технология. Развить предприятие -- это получить по-новому дисциплинированных (т.е. образованных в новой дисциплине -- своих обучить или новых нанять) людей и развернуть технологию (купить или разработать софт, станки, изменить процессы и т.д.). Например, если в стратегии развития указана постановка практик проектного управления, то нужно обучить проектному управлению людей (или нанять уже обученных), закупить проектный софт и выстроить работу по-новому. Постановка практики проектного управления или создание системы проектного управления (как социотехнической подсистемы предпринятия)-- это одно и то же.
Если постановка практики сводится к созданию системы, то используем традиционный инженерный подход: стратегия это про нужды (needs) использующей системы и фокусирование их в требования (что и зачем мы будем делать, "чёрный ящик"), а ещё нам при стратегировании потребуется принять основные решения по тому, как будет устроена наша новая технология: принять архитектурные решения.
Для того, чтобы обсудить добавление новой (или изменение старой) технологии работы, нужно иметь архитектурное описание предпринятия as is и to be: отмоделировать, как взаимодействуют люди, как бегают софты и как урчит оборудование. Если мы хотим подчинить архитектуру стратегии, то мы должны показать, как эти изменения соответствуют модели целеполагания, т.е. стратегии.
Итого: стратегия это модель целеполагания, а стратегия развития предпринятия -- это архитектура предприятия, поддерживающая новые практики работы с указанием целеполагания в части изменения этой архитектуры.
Конечно, идеальным вариантом тут будет использовать ArchiMate 2.1, в котором мы должны будем:
-- представить модель стратегии через motivation extension (помним, что там учли и опыт OMG BMM, и KAOS и i*, результат получился довольно приличный)
-- представить практики работы (можно ограниченно использовать ArchiMate как язык онтологического моделирования дисциплины и вначале выполнить что-то типа domain-driven architecture design по идеям DDD -- https://en.wikipedia.org/wiki/Domain-driven_design. А можно и без дисциплины -- сразу задействовать основной набор элементов ArchiMate для представления технологии, разве что там традиционные проблемы с моделированием физического сырья и обрабатывающего оборудования).
-- представить модель изменений (формально в ArchiMate это implementation and migration extension -- http://pubs.opengroup.org/architecture/archimate2-doc/chap11.html#_Toc371945277, но работать с этим в простейших моделерах типа Archi я не понимаю как: нужны продвинутые моделеры, чтобы удерживать и to be, и as is архитектуры, и много чего ещё).
-- есть ещё часть архитектуры, в которой представляется "штаб" развития, предпринятие развития. То есть нам нужно ещё определить и отмоделировать практики штабной/стратегической работы, технологии развития. Нужно ли заниматься стратегированием стратегирования, думайте сами. В принципе, этот пост как раз про стратегию стратегирования в самом общем виде! В ArchiMate это может быть примерно по идеям http://masteringarchimate.com/2011/05/21/modelling-it-in-your-organization-a-broader-perspective/, но равно можно использовать и последнюю картинку из http://ailev.livejournal.com/1160014.html, там в основе OMG Essence:
Тут мы подошли к ещё одному вопросу: ибо OMG Essence тоже язык описания практик работы предпринятия. Мы тут используем модификацию OMG Essence в варианте для системной инженерии (модификация описана в учебнике системноинженерного мышления http://techinvestlab.ru/systems_engineering_thinking или краткий английский текст Towards a Systems Engineering Essence http://arxiv.org/abs/1502.00121).
Если ArchiMate изначально нацелен на "процессы" и описание технологий, то Essence нацелен на управление жизненным циклом проекта с акцентом на дисциплины и использование контрольных вопросов к специальным объектам-альфам, определяемым дисциплиной практики.
Хотелось бы иметь если не полноценный и всеховатный язык системного моделирования (SysMoLan, http://ailev.livejournal.com/1127145.html), то хотя бы ArchiEssence -- стиль моделирования в ArchiMate, который поддерживал бы выражение тех идей, для которых обычно используется Essence. Для создания ArchiEssence нужно решить огромное число онтологических проблем в обоих языках, и мы тут двигаемся потихоньку (например, наши уточнения для модели целеполагания/стратегирования в ArchiMate -- http://ailev.livejournal.com/1199268.html).
Прежде всего, давайте убедимся, что в ArchiMate у нас достаточно средств для выражения основных альф и выражающих их рабочих продуктов:
-- возможности: тут мало что можно сказать, но это место мутновато и в Essence. Needs можно пробовать моделировать через расширение целеполагания ArchiMate (требования/задачи/обеспечения и ограничения, http://ailev.livejournal.com/1199268.html). Ну, и всё остальное по мелочи. Тут Essence используем в качестве чеклиста: "в вашей ArchiMate модели нужно отразить Возможности".
-- роли и стейкхолдеры (для команды и стейкхолдеров). Там есть нюансы различий между Business Role и Stakeholder в ArchiMate, и замечание в Essence, что Teammember является одновременно подальфой Stakeholders и Team, но давайте не будем пока вдаваться в подробности. Важней то, что в ArchiMate есть ещё и способ выразить "рабочий продукт" для роли -- исполнителя, назначаемого на роль (Actor).
-- воплощение системы. Тут проблемы, ибо ArchiMate нацелен исключительно на определение системы (т.е. каждый объект деятельности в нём представляет информационный объект, а не физический! Для моделирования физического мира ArchiMate не предназначен. См. на краткое описание проблем тут: http://masteringarchimate.com/2014/06/23/modelling-physical-enterprise-architecture-with-archimate/ и http://masteringarchimate.com/2014/07/04/reframing-archimate-about-the-physical-domain-layers-and-recursion/). Но если в целевой системе только люди и компьютеры (но не сырьё и станки), то ArchiMate тут как-то справится.
-- определение системы: определения/definitions разного рода в ArchiMate это business object, объект деятельности (business это "дело" в переводе). И его выражает рабочий продукт -- representation (представление/описание/description), об этом немного в http://ailev.livejournal.com/955954.html.
-- команда: роли в деятельности и как рабочие продукты назначенные на них люди (business roles и actors).
-- технологии: мне кажется, что наиболее близко к artifact-based представлению деятельности тут практики (business functions), которые суть деятельность в её абстрагировании от последовательности исполнения (то есть абстрагировании от activity-based представления, "процессного").
-- работа: процессы (processes).
Для каждой подальфы нужно будет принимать решение, как её моделировать. Но Essence тут выполняет роль списка контрольных вопросов: что нужно моделировать, какие объекты внимания нужно иметь в предпринятиях по постановке практик (помним, что таких предпринятий два -- развивающее и развиваемое предпринятие).
Ещё в Essence хороши состояния альф и контрольные вопросы. Моё предложение -- моделировать эти состояния архимейт-событиями (event) наступления этих состояний альф, в том числе частных состояний ответа на отдельные вопросы. Я бы не рекомендовал при этом делать трюки типа трактовки отношения часть-целое в ArchiMate как темпоральной части: не поймут-с. Нет, объект держит идентичность (имя), связанные с ним события держат изменения его состояния, практики меняют его состояние (отношение доступа, access).
Отдельно нужно упомянуть и Strategy and Tactics Tree Голдратта (http://ailev.livejournal.com/567097.html, и даже попытку выражать это в ISO 24744 http://praxos.livejournal.com/6777.html), но об этом как-нибудь в другой раз. В любом случае, это тоже можно будет выражать на ArchiMate и тоже сводится к определению практик для их постановки (у Голдратта, конечно, это практики TOC).
Тут нужно помнить, что никакой ArchiMate или Essence не позволят вам записать стратегию, т.е. определить цели и выбрать практики по их достижению. Это лишь иероглифы, которые содержат совсем чуть-чуть знаний о предметной области инженерии предприятий. Что этими иероглифами записывать -- это совсем отдельный разговор. Роли стратега и модельера стратегии могут исполняться одним и тем же лицом, но могут быть разнесены и на разные лица.
Но эти иероглифы из ArchiMate и знание о том, что важно в предпринятии из альф и чеклистов Essence позволяют организовать мышление и не упустить что-то важное.
Последний часто встречающийся вопрос: показывать ли все эти модели стратегии менеджерам и прочим стейкхолдерам? Ответ: скорее всего, не показывать. Им нужно показывать упрощённые powerpoint слайды. Моделировать стратегию нужно для того, чтобы по-инженерному вгрызаться в детали, находить и исправлять ошибки, оценивать риски и вообще заниматься стратегией профессионально. А "вовне" из этой кухни выдаются глянцевые картинки. У "железных инженеров" тоже их 3D-модели и прочностные расчёты никому не показываются, а всем внешним стейкхолдерам предъявляются красивые фотореалистические модели внешнего вида. Инженеры предприятия тут ничем не лучше и не хуже, только вместо 3D САПР у них ArchiMate моделер, а вместо программы фотореалистического рендеринга продукта у них PowerPoint.
При всём при том модели стратегии и архитектуры предпринятия (даже в их ручном переложении в PowerPoint слайды) -- это великолепные коммуникационные продукты, они делают невидимое видимым и позволяют обсуждать то, что без них скорее всего ушло бы от осознания. Это значит, что с ними будет выявлено и учтено больше рисков, с ними будет выявлено и удовлетворено больше разных интересов стейкхолдеров.