ИТ-поддержка реструктуризации бизнеса: Как?

Ссылки сюда (1) →

В журнале Intelligent Enterprise, №4 опубликована статья руководителя проектов и архитектора Виктора Яницкого, посвященная ИТ-поддержке реструктуризации бизнеса. Виктор рассматривает виды реструктуризации, связь бизнес- и ИТ-архитектуры, а также дает практические советы по выбору оптимального способа ИТ-поддержки реструктуризации, исходя из направления и скорости происходящих изменений.

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

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

Реструктуризация бизнеса и ее виды

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

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

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

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

Очень важен и характер происходящих изменений, то есть их направление и скорость. Направление изменений показывает, насколько они совпадают с общим трендом развития отрасли, этот параметр напрямую зависит от степени уникальности самого бизнеса. Скорость изменений показывает, насколько быстро бизнес растет (изменяется), при этом быстрорастущими считаются компании, рост которых превышает 20 % в год. Как мы увидим далее, эти два параметра крайне важны для выбора способа ИТ-поддержки изменений.

Связь бизнес- и ИТ-архитектуры

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

Так, стремительное развитие Интернета и средств электронной коммерции предоставило бизнесу новый канал продаж и «вынудило» многие компании изменить логистическую систему.

Чтобы показать связь бизнеса и ИТ, обратимся к схеме архитектуры предприятия (рис. 1), использующего ИТ-поддержку бизнеса.

Рис. 1. Архитектура предприятия

На концептуальном уровне в архитектуре предприятия выделяются четыре слоя.

• Бизнес-архитектура (БА). Описывает организационную структуру, бизнес-процессы и бизнес-функции компании.

• Информационная архитектура (ИА). Определяет, какие объекты (документы, справочники, события, роли и т. д.) необходимы для поддержания бизнес-процессов, а также описывает условия реализации и долговременного использования этих объектов в прикладных системах.

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

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

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

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

Рис. 2. Запаздывающие изменения ИТ-архитектуры вслед за бизнесом

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

Выбор способа ИТ-поддержки реструктуризации бизнеса

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

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

Выбор оптимального варианта ИТ-поддержки («коробочное» решение, инхаус или заказная разработка) зависит, прежде всего, от характера изменений — их направления и скорости (рис. 3).

Рис. 3. «Векторы» реструктуризации бизнеса и развития ИТ-систем
На рисунке центральная стрелка обозначает вектор (тренд) развития отрасли, а верхняя и нижняя стрелки — вектора развития (реструктуризации) бизнеса двух разных компаний. Каждый вектор имеет направление и скорость (условно обозначаются длиной вектора). Фиолетовые стрелки изображают вектор развития «коробочной» системы, которая поддерживает версионность. Тонкими синими стрелками изображены вектора развития заказного ПО (со своей версионностью), а оранжевой и зеленой — систем, разрабатываемых силами инхауса для разных бизнесов.

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

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

Другое дело, когда и сами бизнес-процессы, и их изменения вполне стандартны — так, в случае изменения законодательства в области бухгалтерского учета 1С реализует необходимые доработки в срок.

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

Но что может предпринять компания, имеющая высокую динамику изменений бизнес-процессов, которые к тому же не вписываются в общий «тренд»?

Возможны три подхода к созданию и развитию своей системы автоматизации:

1) настраивать и адаптировать, насколько это возможно, коробочное решение;

2) растить сильный инхаус и разрабатывать необходимые ИТ-системы собственными силами;

3) отдавать создание специализированного ПО на аутсорсинг — компании, оказывающей профессиональные услуги по разработке ИТ-систем на заказ.

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

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

Главные достоинства инхауса — максимальная оперативность реагирования на требования конечного пользователя и, как следствие, хорошая управляемость краткосрочными рисками; относительная дешевизна.

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

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

Главные достоинства заказной разработки — «взгляд со стороны»; модульность и версионность создаваемого ПО; продумывание архитектуры системы; наличие четких протоколов взаимодействия; создание постановочной и технической документации; вынос непрофильной деятельности за пределы компании-заказчика; улучшение управляемости долгосрочными рисками, но только при условии надежности подрядчика.

Кроме того, у заказной разработки есть «скрытые бонусы»:

• при анализе на этапе постановки (на уровне ИА) неизбежно выявляются проблемные места, что может подсказать направления оптимизации и развития бизнес-процессов (на уровне БА);

• вскрываются проблемы неполноты информационных потоков при межмодульном взаимодействии (на уровне АП);

• уменьшается связность ИТ-системы в целом (на уровне АП), что позволяет упростить и удешевить дальнейшие процессы модификации ПО.

Упомянутые «бонусы» играют существенную роль для самого бизнеса. Анализ бизнес-процессов с точки зрения информационной архитектуры помогает вскрыть имеющиеся противоречия и неэффективные места. Это позволяет бизнесу «заглянуть внутрь» своих бизнес-процессов и наметить направление очередного этапа оперативной реструктуризации. То есть тут в некотором смысле «замыкается круг»: реструктуризация бизнеса требует изменений в ИТ-системах, а реализация изменений в ПО позволяет бизнесу уточнить направление последующей реструктуризации.

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

От теории к практике

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

Можно рекомендовать следующие основные пункты анализа.

• Требования бизнеса. Необходимо оценить, какова степень уникальности и динамичности бизнеса компании относительно «средних» параметров в отрасли. Это даст представление о направлении и скорости оперативной реструктуризации. Оценка делается на уровне бизнес- и информационной архитектуры (БА и ИА).

• Что имеем. Проанализировать существующую структуру ИТ-комплекса компании — долю в ней коробочных, заказных и инхаус-систем. Оценить, какие затраты потребуются на поддержку существующих систем, без развития (АП).

• «Степень кривизны». Попытаться оценить (основываясь на требованиях бизнеса) «перекосы», возникшие в результате развития ИТ-систем, как сложившиеся на данный момент, так и грозящие появиться в перспективе, по каждому из векторов развития системы автоматизации. Оценить продемонстрированную различными ИТ-системами способность поддержать оперативную реструктуризацию, выявить краткосрочные и долгосрочные риски. Сделать выводы о том, какие из существующих «перекосов» необходимо устранить прямо сейчас, а какие могут подождать и как долго (оценка соответствия ИА и АП).

• «Вызовы». Оценить «вызовы», стоящие перед ИТ-комплексом компании в связи с развитием бизнеса, и спрогнозировать, как с этими «вызовами» будет справляться имеющаяся структура (оценка необходимых изменений ИА и АП).

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

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

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

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

---

Репликация: База Знаний «Заказных Информ Систем» → «ИТ-поддержка реструктуризации бизнеса: Как?»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».