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

<blockquote>
''В журнале [http://www.iemag.ru/numbers/index.php?YEAR_ID=1359&ID=25659 Intelligent Enterprise, №4] опубликована [http://www.iemag.ru/analitics/detail.php?ID=25696 статья] руководителя проектов и&nbsp;архитектора [[:Категория:Виктор Яницкий (Статьи)|Виктора Яницкого]], посвященная ИТ-поддержке реструктуризации бизнеса. Виктор рассматривает виды реструктуризации, связь бизнес- и&nbsp;ИТ-архитектуры, а&nbsp;также дает практические советы по выбору оптимального способа ИТ-поддержки реструктуризации, исходя из направления и&nbsp;скорости происходящих изменений.''
</blockquote>

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

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

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

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

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

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

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

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

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

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

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

Чтобы показать связь бизнеса и&nbsp;ИТ, обратимся к&nbsp;схеме архитектуры предприятия<ref>[http://www.intuit.ru/department/itmngt/entarc/5/1.html Элементы архитектуры предприятия. Бизнес-архитектура и архитектура информации]&nbsp;/ А.&nbsp;В.&nbsp;Данилин, А.&nbsp;И.&nbsp;Слюсаренко&nbsp;// Архитектура предприятия: курс лекций.&nbsp;— Интернет-университет информационных технологий INTUIT.ru.</ref> (рис. 1), использующего ИТ-поддержку бизнеса.

[[Файл:Архитектура предприятия.jpg|thumb|313px|center|<center>'''Рис. 1.''' Архитектура предприятия</center>]]

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

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

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

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

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

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

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

[[Файл:Запаздывающие изменения.jpg|thumb|494px|center|<center>'''Рис.&nbsp;2.''' Запаздывающие изменения ИТ-архитектуры вслед за бизнесом</center>]]

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

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

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

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

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

[[Файл:Векторы реструктуризации.jpg|thumb|606px|center|<center>'''Рис. 3.''' «Векторы» реструктуризации бизнеса и&nbsp;развития ИТ-систем<br>На рисунке центральная стрелка обозначает вектор (тренд) развития отрасли,
а&nbsp;верхняя и&nbsp;нижняя стрелки&nbsp;— вектора развития (реструктуризации) бизнеса двух разных компаний.
Каждый вектор имеет направление и&nbsp;скорость (условно обозначаются длиной вектора).
Фиолетовые стрелки изображают вектор развития «коробочной» системы, которая поддерживает
версионность. Тонкими синими стрелками изображены вектора развития заказного ПО
(со&nbsp;своей версионностью), а&nbsp;оранжевой и&nbsp;зеленой&nbsp;— систем,
разрабатываемых силами инхауса для&nbsp;разных бизнесов.</center>]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= От теории к&nbsp;практике =

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

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

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

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

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

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

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

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

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

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

[[Категория:Intelligent Enterprise (Публикации)]]
[[Категория:Виктор Яницкий (Статьи)]]
[[Категория:2012 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}