Древнее китайское проклятие гласит – чтоб тебе жить в эпоху перемен. Любые перемены, изменения всегда болезненны и приносят множество проблем. Однако именно они и порождают новые возможности. Ицхак Адизес, в своей методологии подчёркивает, что именно рост компании обеспечивает повышение коммерческого дохода. Но рост — это всегда изменение. Будь то переход с этапа младенчества или юности, как и обратное изменение с этапов застоя к расцвету.
Разберём ключевые проблемы с процессом изменяя компании. Их две. Первая - это кто будет их осуществлять.
Вторая проблема – это как будут осуществляться данные изменения, по каким принципам. Очень часто они происходят бессистемно. В работу компании врываются «бизнес-консультанты» различных направления и начинают либо менять что-то в одном направлении – например срочно внедрять какую-то ERP систему, либо объявляют проблемную функцию, например, логистику и начинают её «модернизировать изо всех сил.
Необходимо понимать, что компания является сложной системой с множеством звеньев и связей между ними. Отличной аналогией является строительство, в процессе которого обязательно участвует архитектор, задачей которого является либо проектирование здания с нуля либо здания после проведения модернизации. В компании совокупность всех элементов и их связей называется корпоративной архитектурой. Общепринятые решения, например - цепь поставок или облачная ИТ инфраструктура в облаке называются архитектурными блоками. Например, ITIL
Поэтому хаотическое внесение изменений не только не решит текущие проблемы, но и создаст массу новых, за счёт нарушения текущих связей. Кроме этого понятие «проблемы» весьма размыто. Очень часто, их некорректно определяют соответственно и решения, которые призваны их победить порождают новые и новые проблемы. Именно поэтому, существуют инструменты и своды инструкций по осуществлению изменений в компании как в системе. Свод подобных инструкций, разработанных западными экспертами называется TOGAF. Он представляет собой полноценную методологию, описывающую как изменить все элементы компании, с учётом их связей. Методология представляет компанию связью нескольких уровней.
Схема компании с точки зрения TOGAF
Начинается методология с важнейшего указания, что она в связи с избыточностью, должна быть адаптирована к каждой конкретной компании. Основой методологии является строго описанный порядок действий, который называется архитектурным циклом.
Схема цикла
На стадии предварительной фазы, оценивается необходимость архитектурного проекта и проводиться адаптация методологии. Дело в том, что в небольшой компании, примерно человек до 50, применение методологии является излишеством, либо придётся при практическом применении из неё слишком многое не использовать, и она потеряет смысл. В рамках адаптации принимаются организационные решения, насколько глубоко архитектура будет прорабатываться и какие части методологии будут использоваться в работе.
На стадии разработки видения архитектуры рассказывается про то как грамотно и правильно определять проблемы и ставить задачи.Это первый этап процесса изменения компании. Он же является ключевым этапом архитектурного цикла! Не допускается его пропускать или упрощать. На этом этапе определяются заинтересованные лица, болевые точки их задевающие, последствия существования этих точек и способы их излечения с учётом существующих в компании ограничений. Все дальнейшие этапы отталкиваются именно от этапа разработки архитектурного видения, поскольку именно на нём должны быть сформулированы цели компании, которые должны быть достигнуты при завершении архитектурного цикла.
Пример архитектурного видения
Важный момент, на этом этапе вполне может возникнуть ситуация, когда у разных заинтересованный сторон, будет разное архитектурное видение. Обязательным условием дальнейшего движения по проекту является выработка единого и согласованного всеми заинтересованными сторонами архитектурного видения. В противном случае на следующих этапах, вместо конструктивной работы корпоративного архитектора ожидает непрерывный саботаж.
Второй этап методологии отвечает за бизнес-логику компании и включает в себя различные элементы бизнеса: процессы, функции, роли, сервисы, события и т.п. Методология подробно описывает, как надо проектировать целевое состояние бизнеса с учётом согласованного архитектурного видения. Здесь вводиться понятие сервисов и их связей с функциями. По сути именно TOGAF предложил перенести принципы принятые в ИТ перенести в организацию бизнеса. Обратите внимание, что физический уровень(материальный мир) также находится здесь
Пример схемы этого уровня
Пример схемы физического уровня
Данная логика появилась не слишком давно, однако доказала свою пользу. Очень часто на проектах блок инфраструктуры оставался неохваченным.
Третий и четвёртый этапы - это разработка обновлённого состояния ИТ архитектуры необходимого для обеспечения функционирования обновлённой бизнес-логики. ИТ-архитектура включает в себя архитектуру данных, архитектуру бизнес-приложений и технологическую архитектуру. Для удобства предлагается объединять их в системную архитектуру.
Пример схемы в рамках системной архитектуры
Технологическая архитектура обеспечивает работу системной архитектуры и бизнес-архитектуры.
Пример схемы в рамках технологической архитектуры
Возникает резонный вопрос. Как все эти уровня связанны друг с другом ? А для этого существуют в методологии понятия сервисов и интерфейсов. Сервис представляет собой определённый уровень услуг, удовлетворяющий потребности внутреннего или внешнего клиента. Для внешних систем сервис предоставляет определенную ценность, что и является мотивацией существования сервиса. Доступ к сервисам осуществляется через интерфейсы. Примером может быть сервис любого подразделения, который предоставляется внешним или внутренним клиентам. Сервисы бывают внешние и внутренние. Внутренние связывают различные уровни архитектуры компании, внешние связывают компанию с бизнес-средой
Схема концептуальной логики взаимодействия сервисов
Схема примера взаимодействия сервисов
Пятый этап обеспечивает конкретные решения для обеспечения перехода от текущего состояния к целевому. Например - определенно изменение - внедрение ERP системы, тогда пятом этапе надо определить конкретного вендора.
На шестом этапе методология требует от корпоративного архитектора подготовить пакеты работ с результатами и если необходимо, то промежуточными состояниями. Например - компания, которая всё вела в экселе может не сразу переходить на 1С ERP, а начать с 1С КА, и освоив её, позже перейдёт на 1C ERP. Пакет работ - это внедрение информационной системы. На седьмом этапе происходит само изменение. Восьмой этап - это контроль достигнутых результатов.
Пример пакетов работ
В процессе работы корпоративному архитектору, как и архитектору в строительстве требуется проектировать модель компании в различных разрезах. Инструментом корпоративного архитектора является язык Arсhimate. Он гармонично дополняет TOGAF, позволяя моделировать действия, описываемые методологией. Однако необходимо понимать важный момент, данный язык моделирования является высокоуровневым и совершенно не подходит как для детального описания бизнес-процессов, так и моделирования работы внутренней логики ИТ систем. В этом случае следует применять BPMN и UML.
Схема применения инструментов моделирования
Теперь мы можем вернуться к первому вопросу. Кто же будет все это делать ? Три уровня корпоративной архитектуры, а недавно в уровне бизнес-архитектуры выделили ещё и физический, как было написано выше. Огромное количество работ объединённых в пакеты. Ответ довольно простой. Понимая, что процесс изменений слишком сложен была создана роль корпоративного архитектора, который отвечал за высокоуровневую работу с архитектурным циклом. При необходимости, у него в подчинении могли быть отдельные архитекторы уровней, например бизнес-архитектор или технологический архитектор. Это зависело от масштаба компании. Но самым важным было отделение от архитектора роли непосредственно реализующей переход, а именно менеджера проектов по направлению. Таким образом получалась схема похожая на организацию работ в строительстве. У менеджеров проектов, при большом объёме вполне может формироваться своя иерархия и тогда корпоративный архитектор взаимодействует уже не со всеми менеджерами проектов, а только с их руководителем. Что касается возникающего вопроса, может ли один человек быть и архитектором и руководителем проектов. Да может, но в очень небольших компаниях и при наличии соответствующих компетенций.
В завершении статьи подчеркну, что несмотря на мою попытку максимально охватить данный вопрос, очень многое осталось за "бортом". Поэтому рекомендую ознакомиться на сайте разработчиков с полной версией методологии и описанием языка моделирования.
