Просмотр исходного текста страницы Автоматизация ключевых бизнес процессов: от действительного до желаемого

== Автоматизация ключевых бизнес-процессов крупных предприятий ==

Журнал ''CIO (Компьютерра), № 10, 14 декабря 2009.'' [http://offline.cio-world.ru/2009/88/486980/  http://offline.cio-world.ru/2009/88/486980/]

;[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]]: Генеральный директор CustIS (Заказные ИнформСистемы)

<blockquote>В журнале CIO, № 10/2009 опубликован материал Елены Некрасовой «Перемены? К лучшему!». Какими способами может быть преодолен разрыв между функционалом информационной системы и потребностями постоянно изменяющегося бизнеса? На вопросы журналистки отвечали представители нескольких ИТ-компаний, в том числе — '''Владимир Рахтеенко''', генеральный директор компании '''CustIS (Заказные ИнформСистемы).'''</blockquote>

<big>'''1. Ключевые бизнес-процессы крупных предприятий непрерывно развиваются и трансформируются под влиянием инновационных процессов. Насколько динамичны и глубоки эти трансформации?'''</big>

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

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

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

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

<big>'''2. Как следствие, неизбежно возникает разрыв между (разницей) функционалом ИС, который необходим бизнесу и функционалом, который реализован в ее модулях. Насколько серьезна и характерна эта проблема?'''</big>

При каждом изменении бизнес-процессов возникает разрыв между функционалом информационной системы и потребностями бизнеса — это объективная проблема. Бизнес закономерно предъявляет претензии к IT, если информационная система тормозит его развитие и не успевает поддерживать изменения в нужном темпе. Но также закономерно, что IT не может мгновенно реагировать на изменения и появление новых бизнес-процессов, как того требует бизнес.

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

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

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

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

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

<big>'''3. Какими способами может быть преодолен функциональный разрыв?'''</big>

Из перечисленных выше сценариев видно, что всегда есть альтернатива:

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

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

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

<big>'''4. Как выстроить стратегию изменений (уровень бизнеса и уровень ИТ)?'''</big>

Говоря о стратегии изменений, следует исходить из наличия нескольких горизонтов управления изменениями:

# '''Оперативное'''. На этом горизонте идет управление изменениями, которые попадают под сценарии: «будут реализованы в рамках существующей модели» и «могли бы быть реализованы путем частичного изменения существующей модели, но в моменте их реализация перекладывается на персонал».
# '''Тактическое'''. Здесь происходит управление такими изменениями, которые решаются частичной доработкой существующей модели, а также такими, которые могли бы быть реализованы путем полной замены существующей модели, но их реализация на продолжительный срок перекладывается на персонал.
# '''Стратегическое''' управление оперирует с изменениями, которые будут реализованы путем полной замены существующей модели или путем создания новой модели.

Здесь есть несколько правил, которые легко сформулировать, но сложно выполнить.

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

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

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

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

<big>'''5. Как вносить необходимые изменения, не инициируя процесс разрушений? Какие советы можно дать по организации процесса внесения изменений со стороны бизнеса, со стороны ИТ, по взаимодействию со сторонними консультантами и разработчиками?'''</big>

Как организовать работу IT-службы для поддержки изменяющихся бизнес-процессов? Для начала следует как к должному и неизбежному относиться к непрерывно меняющимся бизнес-процессам и к неизбежности временных решений для их поддержки.

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

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

{{replicate-from-custiswiki-to-lib}}
[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:2009 год (Статьи)]]
[[Категория:CIO (Публикации)]]