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

- Дмитрий Выволокин, первый заместитель генерального директора ЗАО НЦИТ «ИНТЕРТЕХ»,

- Максим Галимов, директор по перспективным исследованиям компании DIRECTUM,

- Денис Катюшин, руководитель дирекции по реализации проектов в промышленном секторе Optima consulting,

- Олеся Майорова, руководитель практики SAP компании «Verysell Проекты»,

- Максим Монженко, руководитель практики ERP-решений Navicon Group,

- Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы» (CustIS),

- Александр Саксин, заместитель директора департамента КСУ IBS,

- Александр Слесаренко, управляющий партнер группы «БДО Юникон».

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

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

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

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

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

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

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

— Какие области деятельности компаний изменения затрагивают в первую очередь?

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

А. Слесаренко: Компании, выходящие на IPO, должны отвечать международным требованиям по внутреннему контролю, срокам предоставления отчетности и т. д. И тут возникает необходимость в инновационных изменениях. Для оперативного формирования отчетности нужна методология «Fast close». В отличие от РСБУ, где требуется подтверждение первичными документами, которые не могут быть предоставлены естественными монополиями в срок, используется так называемый метод начислений — стоимостная оценка хозяйственных операций. Кроме этого, требуется регламентация учета с уровня первичного документа до получения консолидированной отчетности.

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

А. Слесаренко: На самом деле процесс закупок с точки зрения инноваций очень интересен. Здесь есть где уменьшать издержки. И если раньше речь в основном шла о понимании складских остатков и минимизации неликвида, то сейчас речь идет о планировании потребности в материалах, оборудовании и услугах к определенному сроку, о переводе взаимоотношений с поставщиками с краткосрочных на долгосрочные, о минимизации собственных складских помещений. Это действительно инновационные проекты, которые реально экономят огромные деньги и окупаются за короткий срок. Еще одно поле для инновационных процессов — управление инвестициями. Это приоритизация проектов, оценка экономических последствий инвестиционных решений. У компании существует денежный поток от операционной деятельности, которого может не хватать на все инвестиционные проекты. Тогда возникает необходимость либо в привлечении заемных средств, либо в приостановке менее приоритетных проектов. В этом случае необходимо моделировать экономический эффект от того или иного решения и соотносить с достижением стратегических целей. В управлении финансами для холдинговых структур интересна инновация cash pooling. Сейчас компании подошли или подходят к более умному управлению производством, ремонту оборудования, проектному управлению. Речь уже идет о моделировании эффекта от производственно-
хозяйственных решений до принятия плана и бюджета.

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

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

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

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

О. Майорова: Разрыв в требуемом и реализованном функционале возникает даже при внедрении. Ведь за время проекта, который длится не один месяц, успевают пройти изменения в текущих бизнес-процессах.

М. Монженко: Совершенно верно. Процесс внедрения ИС достаточно долог: например, полномасштабное внедрение ERP-системы в среднем может занять от 8 до 18 месяцев. За это время на предприятии могут произойти различные события, способные значительным образом изменить существующие там бизнес-процессы. Например, из компании может уволиться ключевое лицо, и на его место приходит человек с новой концепцией ведения бизнеса, или предприятие выходит на новый рынок, или начинает развивать непрофильное направление бизнеса… Все это приводит к изменению бизнес
процессов, зафиксированных ранее на этапе проектирования ИС. Часто встречается и такая ситуация: молодая, быстрорастущая компания с неустоявшимися бизнес-
процессами надеется при помощи внедрения ИС решить свои проблемы, связанные с организацией бизнеса. Руководство компании настаивает на использовании стандартных бизнес-процессов, реализованных в системе, но в момент запуска приходит к пониманию, что они не в полной мере соответствуют специфике бизнеса. Последствия изменения бизнес-процессов на поздних этапах проекта внедрения или использования ИС могут быть довольно плачевными — от значительного увеличения сроков и бюджета проекта до принятия решения о его остановке и признания внедрения провальным.

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

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

А. Слесаренко: Актуальной описанная проблема может быть в ситуациях, когда бизнес начинает укрупняться, когда появляются новые его виды, когда он требует другого управления, когда изменяется организационная структура и вводятся различные новые механизмы, по-иному строятся взаимоотношения с партнерами и т. д., — то есть когда вносятся кардинальные изменения, носящие инновационный характер. Тогда действительно предстоит много сделать по приведению функционала в соответствие с потребностями бизнеса. А в остальных случаях это просто достраивание системы. Саму систему мы при этом сильно не изменяем. Кардинальные изменения могут быть только в одном случае: когда принимается решение, допустим, о том, что в холдинге создается централизованная система. Существует огромное количество бизнесов, которые были приобретены на протяжении существования компании. Одни из них работают на «1С», другие на SAP, третьи на Axapta, четвертые на Oracle… Для того чтобы добиться прозрачности данных, принимается решение о переводе информационной поддержки всех видов бизнеса на единую платформу, под единым шаблоном, в который и закладывается вся аналитика, требуемая для получения прозрачности. Все процедуры, касающиеся сбыта, закупок, финансов, стандартизируются. Однако и в этом случае ограничения идут не со стороны платформ: все платформы хорошо проработаны. Как правило, все упирается в людей, которые представляют собой «экосистему».

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

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

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

А. Саксин: Я бы все-таки не забывал, что функция ИТ в компании — сервисная. Это служба, которая должна поддерживать эффективное функционирование бизнеса. Если исходить из этого, то никакого функционального разрыва при правильно организованной работе ИТ-службы возникать просто не должно! Да, бизнес непрерывно трансформируется, но как только возникают новые бизнес-потребности — это автоматически означает постановку задачи на внесение изменений в информационную систему. Таким образом, сама система непрерывно эволюционирует вместе с бизнесом. Вопрос о том, каким образом требования бизнеса будут реализованы в информационной системе — чисто техническая проблема, которую обязаны уметь решать ИТ-директор и ИТ-консультант.

— Какие же варианты развития событий подстерегают компанию, реализующую изменения?

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

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

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

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

В. Рахтеенко: У любой компании всегда есть альтернатива.

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

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

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

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

М. Монженко: Как ни банально это звучит, но преодолеть функциональные разрывы поможет грамотное проектное управление. Его методы находят свое отражение в любом современном стандарте управления проектами PMBOK, PRICE и т. д. Их можно свести к следующему: вовремя выявить потребность в изменении бизнес-процесса; оценить его влияние на проект; донести информацию о возможных изменениях сроков, бюджета, ресурсов до лиц, принимающих решение; зафиксировать и утвердить решение по изменению рамок; проконтролировать выполнение задач с учетом внесенных изменений.

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

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

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

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

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

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

> Стратегическое управление оперирует изменениями, которые будут реализованы путем полной замены существующей модели или путем создания новой модели.

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

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

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

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

М. Галимов: В целом благодаря гибкости информационных систем планирование изменений на верхнем уровне, уровне бизнес-задач и целей, должно минимально ориентироваться на ограничения ИС, хотя не учитывать их, конечно, нельзя. Фактически нужно стремиться к тому, чтобы проблемы изменений в информационной системе носили чисто технический характер. Это задача и разработчиков систем, и ИТ-службы самой организации: в части выработки правильной политики изменений и следования рекомендациям поставщиков.

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

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

А. Слесаренко: Дело в том, что стратегия — это не догма. Это просто инструмент, при помощи которого компания нацеливает свой вектор. И, как правило, каждый год пересматривает свою стратегию, всякий раз глядя на то, что ей нужно сделать в текущем году и как это отразится на горизонте в 5, 10, 20 лет. И эти изменения должны находить отражение и в стратегии ИТ. Следовательно, говорить о стратегии изменений — это планировать изменения на текущий год и корректировать стратегию ИТ. Поэтому уровень бизнеса и уровень ИТ следуют друг за другом с определенным разрывом и с определенными возможностями компании. И решения, которые подбираются, тоже зависят от возможностей и потребностей компании.

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

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

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

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

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

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

Д. Выволокин: Любые изменения (как на уровне бизнеса, так и на уровне ИТ) необходимо вначале тщательно планировать. Должен быть разработан подробный план перехода, определены возможные риски и способы их предупреждения и/или минимизации потерь при наступлении рисковых событий. План перехода и действия по предупреждению и минимизации рисков должны быть согласованы с представителями бизнеса и с функциональными пользователями. Обязательно должны быть учтены все замечания и предложения функциональных пользователей по доработке плана перехода. Только после разработки детального плана перехода и стратегии действий по предотвращению и минимизации рисков можно начинать реализовывать необходимые изменения.

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

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

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

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

В. Рахтеенко: Большие изменения, присущие стратегическому и тактическому горизонтам управления, должны производиться обозримыми порциями. Для этого мы используем метод бережного внедрения для новых частей системы и метод управляемой санации для ее старых компонентов.

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

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

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

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

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

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

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

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

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