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

Евгений – генеральный директор о совладелец небольшой компании "Ромашка", сфера деятельности в данном случае значения не имеет.
Алексей – ведущий разработчик собственной системы под названием "Зверобой" для автоматизации основной производственной деятельности компании "Ромашка", он же ИТ-директор.
Николай – менеджер по управлению изменениями в компании "Ромашка".
Пётр – менеджер по управлению изменениями в компании "Цифровая фиалка", предлагающая аутсорсинг ИТ-услуг.

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

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

Дальше Николай каким-то образом оказался в центре истории по разработке калькулятора тарифов в Excel. Гордо реализовал эту задачу на макросах в Excel. Через неделю Алексей нанял нового ИТ-специалиста, который предложил Алексею и Евгению решить проблему с лицензиями на MS Office (а точнее, с их отсутствием, что могло всплыть при проверках) – установить OpenOffice, что и было сделано. В результате Николай сильно удивился, что его калькулятор перестал работать у всего отдела продаж. А произошло это, потому что макросы на Visual Basic из Excel просто так в OpenOffice не работают. Вернули Excel обратно, вроде и решили проблему. Договорились, что Николая хотя бы будут держать в курсе изменений в области ИТ.

Между тем, проблема с лицензиями была не такой пустяковой, да и сбои интернета случались нередко, поэтому Николай решил этим заняться. Он знал, что есть общепринятый подход управления ИТ-услугами, и обратился в компанию, руководство которой также понимало, что такое ITIL/ITSM. Но по итогу обсуждения с Евгением начать решили с несколько нестандартной вещи – внешнего ИТ-директора, или ИТ-директор как услуга. Для Евгения как для руководителя было очевидно, то Алексей не справляется с этой задачей, но и нанимать дорогостоящего руководителя бюджета не было.

Первым внешним ИТ-директором от компании "Цифровая фиалка" стал Пётр, он сделал следующее:

1. Провёл второго интернет-провайдера (ранее Алексей говорил, что других провайдеров нет), и отладил систему переключения между каналами при сбое.
2. Сделал бизнес-кейс, в котором доказал экономическую эффективность перехода на облако компании "Цифровая фиалка".
3. Реализовал перенос приложений 1С, разворачивание удалённых рабочих мест, а также перенос сервера корпоративной электронной почты – все данные и приложения перенесли в облако компании "Цифровая фиалка", сотрудники же стали работать через удалённое подключение (RDP). При этом была решена проблема с лицензиями, поскольку программы покупала компания "Цифровая фиалка" на существенно более выгодных условиях, чем компания "Ромашка".

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

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

Дальше Николай погрузился в систему "Зверобой" и предложил несколько доработок, которые были востребованы клиентами и нужны были для достижения основной цели – вывода компании на прибыльность. Схема была очень простой:

1. В начале недели Николай спрашивал у Алексея, сколько времени займут необходимые доработки.
2. Алексей называл трудоёмкость и последовательность доработок.
3. Николай составлял план доработок на неделю, который утверждался Евгением.

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

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

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

Какие выводы можно сделать из этой истории? Вот мои размышления, напишите пожалуйста в комментариях, на какие мысли это повествование навело вас:

1. Прежде чем начинать масштабные изменения, связанные с бизнес-приложениями, нужно "залить фундамент" – отладить управление базовыми ИТ-сервисами: интернет, почта, серверы. Это так же верно как то, что дом нужно строить с фундамента, иначе он просядет.
2. Главное – настрой на грамотное управление ИТ-сервисами, а не наличие денег на супер-ИТ-директора. Даже в отсутствие собственного ИТ-директора или в целом хотя бы одного грамотного специалиста в ИТ выход есть, например, внешний ИТ-директор.
3. Любой самый близкий к телу генерального директора ИТ-специалист не обладает монополией на правду. Правда строится на фактах, методике управления ИТ-сервисами и расчёте бизнес-кейса, где показывается реальный эффект в деньгах. Любой человек, который обращает внимание на то, что происходит, и мыслит логически, может разобраться с ИТ-сервисами и привлечь грамотных специалистов.
4. Не нужно бороться с людьми, в целом борьба с людьми не является целью. Нужно бороться за проведение изменений, люди же сами сделают свой выбор, принять изменения и остаться или уйти.
5. Менеджер по управлению изменениями обладает ограниченными ресурсами для борьбы с теми, кто сопротивляется изменениям. Именно поэтому он должен построить систему, в рамках которой сотрудники будут работать по целевому бизнес-процессу. Если сотрудники хотят бороться – пусть борются с системой.

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