Методология управления изменениями на основе методологии TOGAF и языка моделирования Archimate

02.12.18

Управление проектом

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

Древнее китайское проклятие гласит – чтоб тебе жить в эпоху перемен. Любые перемены, изменения всегда болезненны и приносят множество проблем. Однако именно они и порождают новые возможности. Ицхак Адизес, в своей методологии подчёркивает, что именно рост компании обеспечивает повышение коммерческого дохода. Но рост — это всегда изменение. Будь то переход с этапа младенчества или юности, как и обратное изменение с этапов застоя к расцвету.

Разберём ключевые проблемы с процессом изменяя компании. Их две. Первая - это кто будет их осуществлять. 

Вторая проблема – это как будут осуществляться данные изменения, по каким принципам. Очень часто они происходят бессистемно. В работу компании врываются «бизнес-консультанты» различных направления и начинают либо менять что-то в одном направлении – например срочно внедрять какую-то ERP систему, либо объявляют проблемную функцию, например, логистику и начинают её «модернизировать изо всех сил.  

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

   Поэтому хаотическое внесение изменений не только не решит текущие проблемы, но и создаст массу новых, за счёт нарушения текущих связей.  Кроме этого понятие «проблемы» весьма размыто. Очень часто, их некорректно определяют соответственно и решения, которые призваны их победить порождают новые и новые проблемы. Именно поэтому, существуют инструменты и своды инструкций по осуществлению изменений в компании как в системе. Свод подобных инструкций, разработанных западными экспертами называется TOGAF. Он представляет собой полноценную методологию, описывающую как изменить все элементы компании, с учётом их связей. Методология представляет компанию связью нескольких уровней.

Схема компании с точки зрения TOGAF

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

Схема цикла 

 

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

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

Пример архитектурного видения

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

Второй этап методологии  отвечает за бизнес-логику компании и включает в себя различные элементы бизнеса: процессы, функции, роли, сервисы, события и т.п. Методология подробно описывает, как надо проектировать целевое состояние бизнеса с учётом согласованного архитектурного видения. Здесь вводиться понятие сервисов и их связей с функциями. По сути именно TOGAF предложил перенести принципы принятые в ИТ перенести в организацию бизнеса. Обратите внимание, что физический уровень(материальный мир) также находится здесь

Пример схемы этого уровня

Пример схемы физического уровня

Данная логика появилась не слишком давно, однако доказала свою пользу. Очень часто на проектах блок инфраструктуры оставался неохваченным.

  Третий и четвёртый этапы - это разработка обновлённого состояния ИТ архитектуры необходимого для обеспечения функционирования обновлённой бизнес-логики. ИТ-архитектура включает в себя архитектуру данных, архитектуру бизнес-приложений и технологическую архитектуру. Для удобства предлагается объединять их в системную архитектуру. 

Пример схемы в рамках системной архитектуры

Технологическая архитектура обеспечивает работу системной архитектуры и бизнес-архитектуры.

Пример схемы в рамках технологической архитектуры

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

Схема  концептуальной логики взаимодействия сервисов

Схема примера взаимодействия сервисов

Пятый этап  обеспечивает  конкретные решения для обеспечения перехода от текущего состояния к целевому. Например - определенно изменение - внедрение ERP системы, тогда пятом этапе надо определить конкретного вендора.

   На шестом этапе методология требует от корпоративного архитектора подготовить пакеты работ с результатами и если необходимо, то промежуточными состояниями. Например - компания, которая всё вела в экселе может не сразу переходить на 1С ERP, а начать с 1С КА, и освоив её, позже  перейдёт на 1C ERP. Пакет работ - это внедрение информационной системы. На седьмом этапе происходит само изменение.  Восьмой этап - это контроль достигнутых результатов.

Пример пакетов работ

      В процессе работы корпоративному архитектору, как и архитектору в строительстве требуется проектировать модель компании в различных разрезах. Инструментом корпоративного архитектора является язык Arсhimate. Он гармонично дополняет TOGAF, позволяя моделировать действия, описываемые методологией. Однако необходимо понимать важный момент, данный язык моделирования является высокоуровневым и совершенно не подходит  как для детального описания бизнес-процессов, так и моделирования работы внутренней логики ИТ систем. В этом случае следует применять BPMN и UML. 

Схема применения инструментов моделирования

Теперь мы можем вернуться к первому вопросу. Кто же будет все это делать ? Три уровня корпоративной архитектуры, а недавно в уровне бизнес-архитектуры выделили ещё и физический, как было написано выше. Огромное количество работ объединённых в пакеты. Ответ довольно простой. Понимая, что процесс изменений слишком сложен была создана роль корпоративного архитектора, который отвечал за высокоуровневую работу с архитектурным циклом. При необходимости, у него в подчинении могли быть отдельные архитекторы уровней, например бизнес-архитектор или технологический архитектор. Это зависело от масштаба компании. Но самым важным было отделение от архитектора роли непосредственно реализующей переход, а именно менеджера проектов по направлению. Таким образом получалась схема похожая на организацию работ в строительстве. У менеджеров проектов, при большом объёме вполне может формироваться своя иерархия и тогда корпоративный архитектор взаимодействует уже не со всеми менеджерами проектов, а только с их руководителем. Что касается возникающего вопроса, может ли один человек быть и архитектором и руководителем проектов. Да может, но в очень небольших компаниях и при наличии соответствующих компетенций. 

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

 

Корпоративная архитектура TOGAF менеджмент

См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2734    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14234    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5820    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4655    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2733    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4153    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10594    0    biimmap    79    

73

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13029    0    Evil Beaver    17    

116
Оставьте свое сообщение