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

02.12.18

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

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

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

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

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

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

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

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

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

Схема цикла 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3003    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4122    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3451    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

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

20.12.2023    3332    0    1СERP    21    

31

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

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

05.07.2023    15082    0    ASchekachev    37    

55

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

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

28.06.2023    6179    0    stnslv    5    

25

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

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

10.02.2023    5241    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5803    0    MariaTemchina    28    

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