Архитектурный ансамбль

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

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

Для каких предприятий и в каких случаях бизнес-архитектура и ИТ-архитектура имеют значение? Каким предприятиям реально требуются специалисты, которые ею управляют?

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

Полагаю, что малому бизнесу формализация архитектуры предприятия не особенно требуется. Но если бизнес растет, укрупняется, то архитектуру следует формализовать хотя бы на уровне базовых моделей, например модели Джона Захмана. Большому бизнесу формализованная архитектура просто необходима: крупный бизнес не сможет существовать без этого «скелета» — на эти несущие конструкции опираются все бизнес-процессы компании.

Что может стимулировать предприятие серьезно заняться своей архитектурой?

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

В ОМК сложился более благополучный сценарий: разработка архитектуры стала логичным шагом в поступательном развитии компании, стержнем которого является управление цепочками поставок. К счастью, в нашей компании собралась очень сильная команда специалистов в этой области. С созданием архитектуры вся конструкция системы управления обрела полноту. На верхнем уровне архитектуры — модель целей, главные из них — качество в широком смысле этого слова (включая своевременность поставок, точность оформления документов — все, что связано с удовлетворением потребностей наших клиентов) и скорость — необходимость удовлетворять спрос как можно быстрее (для этого нам приходится находить баланс между уровнем запасов и уровнем спроса). Эти цели определяют всю деятельность компании, включая закупки, перевозки, производство, хранение, продажи, для этого выстроены процессы, которые ведут к их достижению. В их основу положена модель SCOR (The Supply Chain Operations Reference Model), мы взяли этот стандарт, поскольку он впитал в себя лучший мировой опыт в области логистики. Для нас важно, что эта хорошо развитая модель продолжает интенсивно развиваться и совершенствоваться.

Построение архитектуры предприятия начали с модели Захмана. На разных уровнях детализации для разных ролей модель дает ответы на вопросы по организации деятельности (как, когда, кто, где) и на главный вопрос — зачем? Архитектуре предприятия подчинена функциональная архитектура — набор бизнес-процессов, использующих единые данные и реализующих требования архитектуры. Самым нижним уровнем детализации функциональной архитектуры являются регламенты и инструкции.

Бизнес-процессы формируют требования к автоматизации, на основе которых формируется техническая архитектура, описывающая автоматизированные информационные системы и инфраструктуру.

Как я понимаю, инициатива формализации архитектуры предприятия должна исходить от высшего руководства. Что говорит ваш опыт — когда, в какой момент топ-менеджмент задумывается о бизнес-архитектуре?

Хорошо, если компания начинает подобную работу не когда «жареный петух клюнул» (сразу вспоминается кризис 2008 года, когда все сразу стали суперэнергичными и креативными, но не все успели осуществить свои планы). На мой взгляд, не так важно, откуда пришла инициатива формализации архитектуры предприятия и затем управления ею. Важно другое: поддержало ли руководство эту инициативу и была ли она реализована? В конце концов сама по себе идея управления бизнес-архитектурой ценности не представляет, реальное значение имеет ее реализация.

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

Каким образом выстроено управление бизнес-архитектурой и ИТ-архитектурой в ОМК? Есть ли в компании свое «архитектурное бюро»? Каковы здесь сферы ответственности, задачи, функции?

Высший орган, рассматривающий архитектурные вопросы в ОМК, — комитет по архитектуре и ИТ, он действует при президенте компании. В этот комитет входят вице-президенты и директор по ИТ, отвечающий за реализацию существенной части решений.

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

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

«Основной критерий оценки архитектуры предприятия прост: насколько эта архитектура ведет к достижению целей бизнеса», Юрий Рощин, директор по ИТ Объединенной металлургической компании

Каков уровень влиятельности бизнес-архитекторов и ИТ-архитекторов вашего предприятия? На какие решения они влияют? В каких этапах их рассмотрения и принятия они участвуют?

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

Каким образом удается связать долгосрочные цели и задачи бизнеса с планами в области развития (и, если необходимо, трансформации) бизнес-архитектуры и ИТ-архитектуры? Другими словами, как вы определяете целевые архитектурные модели, к реализации которых следует стремиться?

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

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

Как соотнести целевую бизнес-архитектуру и целевую бизнес-модель компании? Другими словами, как связать архитектуру и то, каким образом компания будет зарабатывать деньги?

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

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

Как показывает наш опыт, на рынке имеется много специалистов по описанию бизнес-процессов «как есть» и очень мало толковых консультантов, способных понять, что надо делать, и спроектировать новый процесс — описать модель процессов «как должно быть», то есть как это действительно должно быть. Обычно консультанты действуют достаточно формально: проводят интервью и по их результатам — без реального бизнес-анализа — готовят свои рекомендации. Это тупиковый путь: отдельно взятый сотрудник может рассказать, как он видит свою работу, но общую картину бизнес-процессов он все же не представляет. В результате получается система процессов, состоящая из отдельных «островков» и не являющаяся ни цельной, ни эффективной, К счастью, в штате нашей компании есть специалисты (хотя, увы, их не хватает), имеющие цельное представление о том, как должны быть выстроены ее процессы. Именно они формируют целевую архитектуру предприятия.

К процессам верхнего уровня у нас привязаны более детальные процессы (подпроцессы), они на самом нижнем уровне детализируются с помощью регламентов. Таким образом, выстроена пирамида, в самой верхней части которой — архитектура предприятия. Она детализируется до уровня функциональной архитектуры (бизнес-процессов), затем технической (ИТ-систем, поддерживающих эти процессы). Соответственно, возникают роли: имеется архитектор, отвечающий за архитектуру предприятия, а также его коллеги — технический и функциональный архитекторы. В настоящее время часть функциональных архитекторов работают в составе ИТ-подразделения, часть — в бизнес-структурах, но, думаю, в будущем они все переберутся в бизнес-подразделения. Это действительно ключевые специалисты, определяющие, какой будет компания!

Какие факторы могут стать причиной серьезных архитектурных трансформаций?

Одной из причин такой трансформации может стать резкое изменение рыночных условий. Пример — начавшийся в 2008 году кризис. Когда такие события случаются, они становятся очень сильным стимулом для глубокого анализа деятельности компании и ее пересмотра с целью адаптации к новым условиям. Правда, если кризисные явления уже проявились, то что-то серьезно менять, скорее всего, уже поздно. Но, к сожалению, «пока гром не грянет», мало кто из руководителей готов к радикальным улучшениям, поскольку нет серьезных побуждающих мотивов. В периоды относительного спокойствия и благополучия руководители обычно ограничиваются постепенным улучшением плановых показателей. А когда «грянет», выясняется, что свободных денег уже нет. Вот такой порочный круг получается. Ну а идеальный, на мой взгляд, вариант — это ситуация, когда причиной архитектурной трансформации является тщательно продуманный заказ на изменения, исходящий от первого лица организации.

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

Технологические инновации могут быть действенным стимулом для архитектурных трансформаций?

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

Как часто следует подвергать ревизии целевую бизнес-архитектуру и ИТ-архитектуру?

Их действительно следует периодически актуализировать. Один-два раза в год — я считаю, это оптимальная частота пересмотров архитектуры предприятия. Делать это чаще сложно, поскольку специалисты, скорее всего, не успеют толком осознать и осмыслить имеющиеся тенденции. Пересматривать архитектуру реже раза в год, полагаю, тоже неправильно.

По каким признакам можно определить момент, когда бизнес-архитектуре или ИТ-архитектуре компании необходима серьезная трансформация?

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

Какие схемы, способы, подходы к архитектурной транс­формации вы считаете наиболее эффективными?

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

Какие структуры предприятия обычно охватывает архитектурная трансформация бизнеса? Какие должностные лица оказываются ею обычно охвачены?

Пожалуй, пока не осмелюсь обобщать, все-таки не так уж много опыта накоплено... Представляется, что архитектурная трансформация должна начинаться с первых лиц компании, возможно, также — с ее акционеров (если они являются заказчиками таких изменений). Основная ответственность ложится на людей, отвечающих за функционирование тех или иных процессов (владельцев процессов). Оказываются вовлечены и исполнители решений по архитектурной трансформации, то есть архитекторы, в первую очередь функциональные, — им достается основной объем работ, именно им предстоит забыть про выходные на время проведения изменений.

Кто должен выступить лидером архитектурной транс­формации?

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

Каково соотношение различных составляющих в транс­формации бизнес-архитектуры и ИТ-архитектуры?

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

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

Кстати, еще одна серьезная проблема — развитие персонала организации. Бизнес-процессы описываются в том числе посредством ролей, но среди сотрудников компании может не оказаться тех, кто соответствовал бы этим ролям. Тогда необходимо заранее проработать вопрос с кадрами и либо переучить кого-то из своих сотрудников, либо пытаться найти подходящую кандидатуру на рынке труда, что бывает непросто.

Каковы наиболее сложные вопросы, связанные с управлением изменениями в архитектуре предприятия?

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

Еще одна проблема помельче — отсутствие инструментов для проектирования организационных изменений.

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

Какие уроки вы извлекли из своего опыта построения архитектуры?

Главное — я убедился в том, что эта задача, имеющая первоочередную важность для любого бизнеса, вполне решаемая: мы в нашем коллективе успешно реализуем архитектуру предприятия. Если не побояться взяться за эту задачу, если опираться на слаженный коллектив единомышленников, то все трудности можно преодолеть. И еще: технологии и оборудование можно приобрести или взять в аренду, но архитектуру надо строить самостоятельно.