|
Персональные инструменты |
![]() |
||
|
![]() |
![]() ИТ-поддержка реструктуризации бизнеса: Как?Материал из CustisWiki
Мы живем в эпоху перемен. Изменения, большие и малые, происходят постоянно и повсеместно. Темп изменений практически во всех областях человеческой деятельности таков, что и в жизни каждой компании, и в жизни каждого индивидуума мелкие изменения происходят постоянно, а крупные — периодически. Период, за который происходят радикальные изменения, для любого живого, динамично развивающегося бизнеса сейчас составляет не десятилетия, как это было 50 лет назад, а годы. Период небольших изменений, которые могут повлиять на успешность бизнеса, — месяцы. СодержаниеРеструктуризация бизнеса и ее видыНепрерывные изменения приводят к тому, что в любой компании, в любом бизнесе постоянно происходит реструктуризация. Не вдаваясь в подробную классификацию причин, а также форм и способов реструктуризации, обозначим лишь основные из них. Реструктуризация может быть стратегической (крупной, кардинальной) и оперативной (постоянной и поступательной). Стратегическая реструктуризация, как правило, связана с тем, что бизнес «ищет себя», свою нишу, определяется «по-крупному», при этом происходит существенное изменение содержания и способов ведения бизнеса. Оперативная реструктуризация не затрагивает каких-либо глобальных процессов в компании, но, тем не менее, она жизненно важна. Она обеспечивает и оптимизирует бизнес-процессы, дающие компании конкурентное преимущество и поддерживающие ее рост и развитие.
Причины реструктуризации могут быть внутренними и внешними. Внутренние причины обусловлены развитием самой компании — это может быть изменение структуры и (или) масштаба бизнеса, территориальная экспансия и — как отдельный случай — продвижение в другие страны. Внешние причины связаны с «давлением» извне: меняется законодательство, новые рынки диктуют свои условия, в мире появляются новые технологии и способы ведения бизнеса. Очень важен и характер происходящих изменений, то есть их направление и скорость. Направление изменений показывает, насколько они совпадают с общим трендом развития отрасли, этот параметр напрямую зависит от степени уникальности самого бизнеса. Скорость изменений показывает, насколько быстро бизнес растет (изменяется), при этом быстрорастущими считаются компании, рост которых превышает 20 % в год. Как мы увидим далее, эти два параметра крайне важны для выбора способа ИТ-поддержки изменений. Связь бизнес- и ИТ-архитектурыСегодня ИТ играет все большую роль в бизнесе, зачастую привнося в производство существенные качественные изменения. При этом не только бизнес влияет на ИТ, но и ИТ оказывает влияние на способы ведения бизнеса, предоставляя ему новые возможности. В частности, возможна ситуация, когда реструктуризация бизнеса происходит из-за изменений в ИТ-индустрии.
Чтобы показать связь бизнеса и ИТ, обратимся к схеме архитектуры предприятия[1] (рис. 1), использующего ИТ-поддержку бизнеса. На концептуальном уровне в архитектуре предприятия выделяются четыре слоя.
Описанные слои, с одной стороны, относительно независимы (между ними можно провести более-менее четкую границу), а с другой — оказывают постоянное взаимное влияние. Так, если проектируются изменения в бизнес-архитектуре, то они неизбежно повлекут за собой перемены во всех нижележащих слоях (слой ТА, будучи чисто техническим, интересует нас меньше остальных). Причем эти изменения будут естественным образом запаздывать относительно изменений в бизнес-архитектуре (рис. 2), и здесь существенным становится время этого запаздывания. Ведь для бизнеса порой жизненно важно, чтобы требуемые изменения в ИТ-системах были реализованы в срок.
Выбор способа ИТ-поддержки реструктуризации бизнесаПоскольку изменениям подвержен любой бизнес, а ИТ сегодня играет огромную роль в обеспечении его эффективности, практически любая компания рано или поздно сталкивается с проблемой выбора оптимального способа ИТ-поддержки реструктуризации. Сразу определимся, о каких изменениях пойдет речь. Стратегическая реструктуризация влечет за собой кардинальные изменения в ИТ, поэтому мы сосредоточимся на роли ИТ при оперативной реструктуризации. Выбор оптимального варианта ИТ-поддержки («коробочное» решение, инхаус или заказная разработка) зависит, прежде всего, от характера изменений — их направления и скорости (рис. 3). ![]() На рисунке центральная стрелка обозначает вектор (тренд) развития отрасли, а верхняя и нижняя стрелки — вектора развития (реструктуризации) бизнеса двух разных компаний. Каждый вектор имеет направление и скорость (условно обозначаются длиной вектора). Фиолетовые стрелки изображают вектор развития «коробочной» системы, которая поддерживает версионность. Тонкими синими стрелками изображены вектора развития заказного ПО (со своей версионностью), а оранжевой и зеленой — систем, разрабатываемых силами инхауса для разных бизнесов. Очевидно, что для автоматизации уникальных бизнес-процессов и их уникальных же изменений, которые не совпадают с трендом развития отрасли, «коробочное» решение малопригодно.
Другое дело, когда и сами бизнес-процессы, и их изменения вполне стандартны — так, в случае изменения законодательства в области бухгалтерского учета 1С реализует необходимые доработки в срок. Таким образом, для компаний, не имеющих большого числа уникальных бизнес-процессов, а также для медленно развивающегося бизнеса сочетание готовых систем и небольшого собственного инхауса является достаточным для эффективной и своевременной поддержки такой «неспешной» реструктуризации. Если бизнесу хорошо подходит «коробочное» решение и не видно рисков, связанных с упомянутыми недостатками готовых систем, — то это, безусловно, самое хорошее и дешевое решение. Но что может предпринять компания, имеющая высокую динамику изменений бизнес-процессов, которые к тому же не вписываются в общий «тренд»? Возможны три подхода к созданию и развитию своей системы автоматизации:
Первый способ имеет существенные ограничения: настраивать готовое решение можно только в каких-то пределах, и стоимость таких «доработок» может превзойти стоимость самой системы. Все дело в том, что вносить изменения в слой АП (архитектуры приложения) «коробочной» системы могут только ее авторы. Изменить что-либо самостоятельно можно только обходными путями (к примеру, пристраивая что-то «сбоку»), что крайне неэффективно и очень дорого. Поэтому большинство быстрорастущих компаний с оригинальными бизнес-процессами вынуждены выбирать между заказным ПО и сильным инхаусом. Следует отметить, что только инхаус или только заказное ПО — это крайности, и эффективнее в каждом конкретном случае искать какое-то сочетание этих подходов, некий взвешенный компромисс. Иначе «перегибы» — как в ту, так и в другую сторону — приведут к неоправданному увеличению проектных рисков и стоимости ИТ-поддержки. Постараемся обосновать это утверждение, рассмотрев преимущества и недостатки инхауса и заказной разработки. Главные достоинства инхауса — максимальная оперативность реагирования на требования конечного пользователя и, как следствие, хорошая управляемость краткосрочными рисками; относительная дешевизна. Основные недостатки разработки силами собственного ИТ-подразделения — отсутствие полноты картины и взгляд на компанию и ее процессы «изнутри» (как следствие — фрагментарность постановок); малое количество документации, что приводит к невозможности «оторвать» ПО от инхаус-разработчиков; необходимость содержать большое собственное ИТ-подразделение, которое занимается непрофильной для компании деятельностью; недостаточная масштабируемость и плохая управляемость долгосрочными рисками. К недостаткам создания ИТ-систем «на заказ» можно отнести среднюю оперативность; более высокую стоимость (чем при создании ПО силами инхауса); возможное ухудшение управляемости краткосрочными рисками; необходимость предпринимать существенные усилия для повышения эффективности взаимодействия между заказчиком и подрядчиком, чтобы «успевать» за оперативной реструктуризацией; в случае ненадежного подрядчика — существенное увеличение проектных рисков. Главные достоинства заказной разработки — «взгляд со стороны»; модульность и версионность создаваемого ПО; продумывание архитектуры системы; наличие четких протоколов взаимодействия; создание постановочной и технической документации; вынос непрофильной деятельности за пределы компании-заказчика; улучшение управляемости долгосрочными рисками, но только при условии надежности подрядчика. Кроме того, у заказной разработки есть «скрытые бонусы»:
Упомянутые «бонусы» играют существенную роль для самого бизнеса. Анализ бизнес-процессов с точки зрения информационной архитектуры помогает вскрыть имеющиеся противоречия и неэффективные места. Это позволяет бизнесу «заглянуть внутрь» своих бизнес-процессов и наметить направление очередного этапа оперативной реструктуризации. То есть тут в некотором смысле «замыкается круг»: реструктуризация бизнеса требует изменений в ИТ-системах, а реализация изменений в ПО позволяет бизнесу уточнить направление последующей реструктуризации.
От теории к практикеЗадача выбора оптимального способа ИТ-поддержки изменений не имеет простого решения. Однако если вас как CIO не удовлетворяет то, как функционирует ваш ИТ-комплекс, насколько оперативно он реагирует на вызовы реструктуризации — значит, вам предстоит проанализировать текущую ситуацию и найти пути и способы ее изменения. Можно рекомендовать следующие основные пункты анализа.
Задача, которую необходимо решить для оптимизации ИТ-структуры компании, формулируется крайне просто: при имеющихся возможностях достичь максимума целей. Конечно, здесь нет готовых формул. Выбор подходящего способа ИТ-поддержки изменений зависит от множества факторов — каждая ситуация уникальна, и многое зависит как от обстоятельств, в которых оказалась компания, так и от профессионализма и опыта CIO и его команды.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |