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

Intelligent Enterprise: В чем состоит суть процесса управления изменениями? В чем заключается специфика в отношении ИТ‑департамента?

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

Следствием каких задач должно стать изменение программного обеспечения?

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

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

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

Естественно, мы сразу не запускаем все изменения и даже не проводим пилотных проектов без начального моделирования и оценки полученных результатов. Для построения моделей существует специальное и, следует отметить, довольно разнообразное по функционалу программное обеспечение. Здесь можно говорить, например, как о Rational компании IBM, так и о небезызвестной на российском рынке системе ARIS от Software AG. Если по итогам моделирования оказывается, что результат нас не удовлетворяет, часто приходится отказываться от модификации бизнес-процессов, даже в случае, когда изменения инициированы высшим руководством. Но это скорее исключение, чем правило.

Вы только что упомянули некоторые программные инструменты, которые в той или иной мере призваны помочь в проведении изменений. Как вы оцениваете перспективы их применения?

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

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

Процесс управления изменениями у нас четко регламентирован с методологической точки зрения. Описана последовательность действий, начиная от инициации изменения и заканчивая приемкой его в эксплуатацию (user-accepted test). На нынешнем этапе этого вполне достаточно, и я не вижу необходимости тратить ресурсы на внедрение специализированных продуктов. Но при более крупных изменениях ситуация может быть рассмотрена индивидуально.

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

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

В основном здесь все зависит от масштаба изменений. Под сравнительно небольшие изменения средства закладываются в операционный бюджет, даже не в инвестиционный. Подобные изменения связаны с операционной деятельностью и соответственно не требуют отдельных проектов.

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

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

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

Сейчас понятие Change Management в связи с рядом факторов тесно ассоциируется с классическими идеями ITIL и их конкретной реализацией на базе ITSM того или иного вендора. Как вы полагаете, насколько накопленные в процессе освоения ITIL/ITSM методические знания и практический опыт применимы в отношении управления изменениями прикладных систем?

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

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

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

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

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

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

Трудно сказать, какова ситуация в ритейле, но в промышленности, например, целесообразность изменений и их детальность зависят не только от бизнес-процессов, но и от используемого оборудования. Если оно устаревшее, то вряд ли есть смысл, скажем, проводить изменения. В ритейле тоже есть некое подобие оборудования нижнего уровня. Хотелось бы понять, имеются ли подобные зависимости здесь…

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

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

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