Организационные изменения: зачем и почему?

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

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

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

Смотреть шире

Организационные изменения всегда вовлекают и оказывают влияние на огромное число людей (это и сотрудники компании, и её партнеры, и клиенты). По этой причине сложно представить ситуацию, когда масштабное изменение может быть успешно реализовано при отсутствии ясного понимания, как добиться ожидаемого эффекта, как уложиться в отведенные сжатые сроки и ограниченный бюджет. Любое организационное изменение – это сложная комплексная задача для бизнеса и ИТ.

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

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

Камни преткновения

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

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

Схожий случай был в нашей практике, когда мы столкнулись с откровенным неприятием даже мысли об изменении сложившейся практики работы. Мы строили в компании единый процесс управления изменениями для всей ИТ-службы, сотрудники отдела разработки ПО в штыки восприняли необходимость участия в нем их подразделения. Самые горячие дискуссии развернулись вокруг необходимости учета изменений в системе автоматизации единого процесса. «Зачем, – спрашивали разработчики, – нам ваша система, когда у нас есть своя, гораздо лучше? Ведь она создана нами именно для наших нужд и во всем отвечает нашим требованиям».

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

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

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

Связь с ITSM

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

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

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

Роль и значимость соприкосновения тематик организационных изменений и принципов ITSM признается и в деталях рассматривается в большинстве методологий, описывающих сервисный подход, например, в Cobit 5 (книга Implementation) и ITIL v3 (книга Service Transition). В обеих книгах отмечается, что эффективный переход к новым методам работы или взаимодействия между ИТ и бизнесом невозможен без соответствующего управления организационными изменениями, которое предполагает непрерывные коммуникации со всеми заинтересованными в изменениях сторонами и последовательную адаптацию сотрудников к новым условиям.

Российский опыт

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

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

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

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

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

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

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

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