В вечно актуальной теме взаимоотношений ИТ и бизнеса все еще остаются отдельные вопросы, требующие обсуждения. Они представляются тем более интересными, что вопреки распространенному мнению отнюдь не уникальны именно для ИТ‑направления. Об этом мы беседуем с директором по развитию компании Desan Антоном Сидоренко.

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

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

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

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

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

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

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

Здесь возникает вопрос о формализации отношений. Если есть какой‑либо оптимальный шаблон поведения двух сторон при вступлении в некие взаимоотношения, касающиеся планируемых ИТ-проектов, должны ли они каким‑то образом формально фиксироваться во внутренних методиках, стандартах или иных документах предприятия?

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

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

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

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

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

У нас, к сожалению, нет подобных измерительных шкал. Думаю, что если бы наш ИТ-руководитель сформулировал мне предложение подобным образом, я скорее всего попросил бы его уточнить, что он имеет в виду. Другими словами, попытался бы понять, в чем лично он видит разницу между упомянутой 99%­­‑ной доступностью тех или иных данных для нашего бизнеса и ситуацией, когда эта доступность будет, скажем, составлять 97%. Эти объяснения мне необходимы вовсе не для того, чтобы свалить проблему на коллег и самому не думать над вопросом. Скорее, наоборот, я готов признать, что тезисы ИТ-директора могут не отличаться очень глубоким пониманием наших проблем. Если говорить о доступности данных, то для какой‑то категории сотрудников величина данного параметра в отношении вполне определенной категории данных может быть и выше. Или, наоборот, где‑то без заметного ущерба для бизнеса ее можно даже существенно снизить. Это нюансы, которыми могу владеть я или даже функциональный менеджер более узкого профиля. Однако для обсуждения таких нюансов должен быть запущен содержательный диалог, начало которого я и имел в виду, говоря о необходимости более или менее расширенной трактовки численных характеристик ИТ‑ресурса. Собственно, когда мы говорим о необходимости понимания бизнеса со стороны ИТ, то как раз имеем в виду подобные моменты. Конечно, речь не идет о требованиях разбираться в нюансах. Но способность поддержать диалог при правильном понимании терминов и задач, безусловно, при этом подразумевается.

По большому счету, приведенный пример не касается исключительно сферы ИТ. Когда в компании внедряется культура управления в соответствии с KPI, есть риск определенных перегибов. Иными словами, может случиться так, что все, условно говоря, собрались, поговорили про KPI, и затем каждый по отдельности вернулся к своей работе и начал для себя эти KPI придумывать. Еще раз подчеркну: то, о чем мы сейчас говорим, не касается исключительно ИТ‑направления. Ранее я примерно то же самое слышал от специалистов по логистике. Тезис состоял в том, что мы будем держать такое‑то количество остатков на складе, что обеспечит 99,8% безотказности заявок клиентов. Тем же ИТ‑специалистам, далеким от детальных проблем логистики, может показаться, что это и есть тот самый язык бизнеса, на котором и следует говорить. Тем не менее когда подобную информацию логисты доносят до меня, у меня еще остается масса вопросов. Какова стоимость поддержания таких остатков? Насколько изменится оборачиваемость? Что будет, если уменьшить требования к неснижаемому остатку на складе и соответственно понизить пресловутый параметр безотказности? Сколько нам удастся сэкономить? Если оставить клиенту возможность забрать заказ, условно говоря, не сегодня, а через три дня, что для ряда заказчиков, скажем, не имеет большого значения, как изменится работа склада? Как и в уже рас­­смотренном нами примере, может быть сделано множество уточнений численного параметра. Если весь менеджмент работает в одной системе координат, то здесь не возникает никаких проблем. Но ведь количество различных функциональных направлений в структуре бизнеса порой немалое, и учесть всю специфику терминов и показателей практически невозможно. И ка­сается это далеко не только ИТ-направления.

А у вас в компании развивается культура управления в соответствии с ключевыми показателями результативности? В какой степени она касается ИТ-направления?

Мы внедрили и развиваем у себя в компании систему сбалансированных показателей (ССП) и двигались в этом направлении классическим путем — от формализации стратегии к ее трансляции в оперативную деятельность компании. Перед этим у нас в компании не было сколько‑нибудь серьезной формализации. Определяя, по какому пути идти, мы решили для себя, что ССП наиболее для нас удобна. Система помогла нам скоординировать и объединить деятельность всей компании, а внедрение ERP‑системы Microsoft Dynamics NAV, осу­ществленной нами совместно с компанией NaviСon, стало в каком‑то смысле завершающим этапом.

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

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

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

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

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

Хотелось бы вернуться к вопросу управления ожиданиями и роли ИТ-директора. Некоторый парадокс, на наш взгляд, состоит в том, что от последнего бизнес прежде всего требует бесперебойной работы находящихся в эксплуатации систем. И это вполне объяснимо. Но если говорить об ожиданиях от CIO, здесь все сдвигается в сторону стратегического видения развития информационной поддержки. То есть требования и ожи­дания существенно расходятся. Могли бы вы как‑то прокомментировать данный тезис?

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

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

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

Сейчас очень часто говорят об ИТ‑стратегии как таковой и об отдельном документе с таким названием, который якобы должен существовать в компании. Что вы об этом думаете?

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