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

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

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

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

Владимир Рахтеенко

Генеральный директор CustIS (Заказные ИнформСистемы)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Репликация: База Знаний «Заказных Информ Систем» → «Автоматизация ключевых бизнес процессов: от действительного до желаемого»

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