Опыт руководства ИТ-подразделениями в компаниях, работающих в разных отраслях, существенно различающихся по внутренней культуре менеджмента и при этом находящихся в разных внешних рыночных условиях, безусловно, наталкивает на попытки обобщения. При этом подобные попытки позволяют выделить целый ряд универсальных моментов, характерных для всех реализуемых на практике сценариев. Об этом мы беседуем с профессиональным CIO Сергеем Потаповым.
Intelligent Enterprise: Работая в качестве CIO в компаниях различных отраслей, размеров и обладающих разной управленческой культурой, вы наверняка систематизировали собственный опыт, выделив для себя позитивные, нейтральные и негативные сценарии, в которых CIO легче или, наоборот, труднее проявить себя конкретными достижениями. Не могли бы вы поделиться своими мыслями на этот счёт?
Сергей Потапов: Действительно, работая в разных компаниях, невольно систематизируешь для себя полученный опыт, анализируешь примеры успешного выполнения задач, равно как и причины неудачи тех или иных проектов, решений, инициатив. Надо отметить, что с точки зрения задач, которые ставятся перед ИТ-службой, разные бизнесы принципиально не отличаются друг от друга. Всем важно, чтобы системы (прикладные и бухгалтерские, почта, телефон и т.д.) работали стабильно. Чтобы требования бизнеса к ИТ в постоянно меняющейся среде быстро реализовывались, чтобы ИТ обеспечивали гибкость и масштабируемость бизнеса, безопасность и сохранность данных. И еще очень важно, чтобы обеспечивалась конкурентоспособность бизнеса сейчас и в долгосрочной перспективе.
Но вот реализация поставленных задач в разных компаниях различается принципиально. Где-то проекты завершаются и приносят свои плоды, а где-то зависают, принося всем лишь горечь разочарования. С точки зрения ценности и тот и другой опыт одинаково важен. Только один идет тебе в «актив», а другой в «пассив». А разница между этими двумя и составляет ваш профессиональный капитал как менеджера.
Анализировать ситуации, когда что-то не получилось, не менее полезно, чем рассматривать факторы успеха. Успех легко усваивается всеми, кто хоть как-то к нему причастен. А вот неудачи отторгаются и либо списываются на внешние обстоятельства, либо перекладываются на плечи других. Но не проанализировав причины неудачи, мы закладываем почву для повторения ситуации в будущем. Вот почему честный и объективный анализ успешного и неуспешного опыта одинаково важен.
Итак, анализируя предыдущий опыт на первых позициях в ИТ-направлении, а это работа в таких компаниях, как «Вимм-Билль-Данн», ПИК, ГК «Независимость», я бы сказал, что условия успеха, с одной стороны, и причины неудач, с другой, в целом схожи. Эти условия, на мой взгляд, можно сгруппировать следующим образом.
Во-первых, ИТ-грамотность руководства, то есть насколько оно знает и понимает, какое влияние ИТ-служба может оказать на эффективность бизнеса. В компаниях, где такое понимание было, проекты шли более успешно, и наоборот, там, где ИТ-подразделению отводилась сугубо вспомогательная функция, при выполнении проектов были проблемы.
Во-вторых, единство целей и согласованность действий между сотрудниками, менеджментом и акционерами. Там, где такая согласованность была, проекты шли и завершились успешно. Если её не было, проекты «буксовали».
В-третьих, доверие и полномочия. Там, где есть доверие к ИТ-службе, к ее руководителю, к проектной команде, где ИТ-руководителю даны полномочия принимать решения и нести за них ответственность, проекты были успешными. А там, где делегируется лишь ответственность, но не полномочия, где бизнес сам принимает решения о поставщиках и технологиях, а ответственность за издержки внедрения перекладывает на ИТ-отдел, проекты, как правило, не были успешными.
В-четвёртых, последовательность и упорство в реализации проектов. Если, столкнувшись с первыми проблемами, команда внедрения выступала как единое целое, не разделяясь на «своих» и «чужих», то проекты завершались успешно, если же после первых сложностей начинался поиск виновных по принципу «ИТ» — «бизнес» и откат к исходному положению, проекты, как правило, вообще не заканчивались.
И наконец пятое условие — мониторинг достижения целей и контроль после реализации проекта. Если в компании вёлся постоянный анализ достигнутых результатов и была возможность дальнейшего совершенствования, проекты считались успешными. А там, где этого не делали, через какое-то время забывали о целях и результатах и недоуменно спрашивали друг у друга, зачем эта система вообще внедрялась.
О том, насколько важно иметь единую, сплоченную общими целями управленческую команду, действительно говорят очень много. Но говорят, как правило, декларативно, не вдаваясь в суть проблемы. Данный тезис больше воспринимается просто как некий лозунг. В этом смысле хотелось бы проанализировать, что означает наличие или отсутствие такой команды.
Отсутствие единства в управленческой команде вполне можно отождествлять с фактическим самоустранением бизнеса от участия в ИТ-проектах (даже если учесть, что «чистых» ИТ-проектов фактически не существует). С одной стороны, это, естественно, явно не декларируется — никто из бизнес-руководства не скажет прямо: меня не интересует судьба проекта и мне все равно, чем он закончится.
С другой стороны, неучастие бизнеса — это в определенной мере модель развития событий. Такая модель чрезвычайно устойчива, неукоснительно «соблюдается» фактически в любых проектах, и в этом смысле она как раз служит прекрасным индикатором негативного сценария и предвестником появления вполне определенных проблем, даже если формально все заявляют совершенно обратное.
Если бизнес по существу отстраняется от ИТ-проекта, то в лучшем случае всё держится на энтузиазме или созидательном инстинкте некоторых сотрудников (в ИТ-департаменте либо вне его) и, как правило, на страхе наказания за невыполнение данных поручений. Потому что нежелание содержательно участвовать в работе всегда компенсируется более жесткими административными мерами и в результате расцветает формализм, предпринимается попытка выполнить задачи любой ценой, и, как следствие, цели не достигаются. Нежелание же в свою очередь объясняется непониманием, а очень часто и абсолютным отсутствием интереса к реальным возможностям ИТ.
Модель поведения, о которой я говорю, распространяется и на поставщиков ИТ-услуг. Здесь мы также имеем устойчивую картину. Поставщики, как правило, очень хорошо чувствуют ситуацию в проекте и реагируют на нее вполне адекватным с точки зрения их бизнеса образом. Они либо откровенно завышают цены и затягивают сроки, либо скрытым для заказчика образом перебрасывают ресурсы с его проекта на другие. При этом их можно понять: у каждого поставщика своя экономика и свои риски, которые он должен страховать. Но в любом случае подобное поведение ИТ-компании в проекте опять-таки является и индикатором, и следствием тех проблем, о которых мы говорим.
В качестве примера можно привести проект по внедрению CRM-системы на последнем месте моей работы. Всем известно, что по правилам система класса CRM внедряется исходя из требований бизнеса и при полном его вовлечении в проект. Мы же, фактически находясь в обратной ситуации, были вынуждены как-то «подтягивать» функционал к нынешней конфигурации бизнеса — нашего внутреннего заказчика. При этом конечно же у нас имели место те негативные нюансы взаимодействия с поставщиком, о которых я только что сказал.
Кроме неких шаблонов развития проектных работ наверняка существуют и внутренние противоречия во взаимоотношениях между отдельными направлениями бизнеса компании и между теми или иными сотрудниками, отвечающими за разные направления.
Есть такое выражение: «только бизнес — ничего личного». Однако, как мы все хорошо знаем, бизнеса без внутренних конфликтов не бывает. Без конфликтов интересов среди линейных менеджеров, без противоречий на уровне топ-менеджеров и собственников, без личных конфликтов наконец. Прекрасно известно также, что работая на сколь-либо значимых менеджерских позициях, не следует искать конфликтов, но столь же неразумно и пытаться всячески уходить от них.
И всегда возможна ситуация, когда функциональный руководитель считает, что коллеги не понимают его позицию. С этим я сталкивался не раз. Непонимание и даже принципиально различная трактовка может распространяться и на некоторые профессиональные вопросы, касающиеся, скажем, отношения к динамике продаж определенного товара или к методам его учета.
Это тоже вполне штатные конфликты, которые при необходимости локализуются и с которыми объективно можно разобраться. Как я уже говорил, на более высоком уровне могут существовать конфликты отдельных групп собственников, отголоски которых спускаются на уровень менеджмента.
В такой среде крайне важна роль первого лица компании (генерального директора или аналогичной по статусу должности). Прежде всего потому, что при дефиците координирующей функции со стороны первого лица все эти конфликты расцветают пышным цветом. Надо сказать, что необходимость сбалансировать интересы разных «стейкхолдеров» на разных уровнях и при этом содержательно развивать бизнес как раз и является одной из задач высшего руководства. И эта работа отнюдь не проста. Здесь мы почти всегда сталкиваемся с тем, что принято называть политикой, и поэтому от высших руководителей требуются и профессиональные знания, и некая деловая интуиция, и стратегическое мышление.
На уровне функционального управления роль руководителя в обеспечении баланса интересов также важна. Но тут я иногда наблюдал определенные диспропорции. Вот что я имею в виду. Ни один высший руководитель никогда не признается вам, что испытывает недостаток знаний, скажем, в области финансов, продаж, маркетинга или производства. Даже если это отчасти и так, руководитель скорее будет говорить, что он понимает, как работает бизнес целиком, а более детальные задачи оставляет директору по маркетингу, по финансам и т.п. Но, повторю, он всегда будет утверждать, что и знаниями, и ситуацией в необходимой именно ему степени он конечно же владеет. Потому что в противном случае как минимум у его коллег возникнет недоумение.
При этом тот же самый человек может легко и открыто признаваться в том, что он совершенно ничего не понимает в ИТ, и такие заявления как им самим, так и (что еще хуже) всем бизнес-сообществом, включая, кстати, и ИТ-сообщество, воспринимаются как совершенно нормальная ситуация. А я считаю, что невежество в вопросах автоматизации бизнеса — это признак некомпетентности и безграмотности руководителя точно в такой же степени, какова была бы степень его некомпетентности в других ключевых функциональных направлениях.
А дальше такая «диспропорция» отражается на качестве внедрения, о чем мы уже говорили. Бизнес во внедрении не участвует, инсталлированные ИТ-системы оказываются никому не нужными, потому что бизнес не знает, как их использовать, и не использует, находя массу формальных придирок к ИТ-подразделению. Так проходит итерация за итерацией, проект за проектом, время идет, менеджеры проекта и ИТ-руководители меняются, а в ИТ как было «всё плохо» с точки зрения бизнеса, так и остается. Никого не интересуют сложные причинно-следственные связи — в сухом остатке опять «хотели внедрить систему, а получилось как всегда». Названные диспропорции отражаются и на отношениях между функциональными руководителями, и в этом случае о единой команде говорить вообще не приходится. Кто из коллег ИТ-директоров не испытывал отношения к себе как к человеку, который при утверждении бюджета всякий раз имеет скрытый камень за пазухой и чтобы его «протащить», прибегает к шантажу? А раз так, то легче этот камень вообще не искать, а просто уполовинить запрашиваемый им бюджет, что называется, от греха подальше. Я с этим сталкивался лично. И сталкивался как раз там, где общий фон для выполнения ИТ-проектов был неблагоприятным. Точнее, именно такое отношение и создает этот фон. А если это отношение поменять, то добрая половина организационных проблем ИТ-проектов и ИТ-поддержки в целом исчезнет сама собой.
С одной стороны вы признали, что отсутствие полного взаимопонимания в бизнесе в той или иной степени типична и универсальна. Противоречия возникают между многими функциональными направлениями и часто вовсе не затрагивают ИТ-службу. С другой — ИТ-руководителям часто бывает свойственно выделять собственное направление в неком противостоянии бизнесу в целом, и в ваших словах эта мысль тоже сквозит. Действительно ли роль ИТ-подразделения в этом смысле особая?
Позиция особого выделения своего отдела на фоне других функциональных направлений бизнеса для CIO отчасти действительно характерна, и без особых на то оснований подобная позиция не оправданна. Однако мне представляется, что объективные причины для такого выделения все-таки имеются.
Если мы вспомним, как развивался бизнес в России, то, наверное, согласимся с тем, что основным фактором, который ассоциировался с этим развитием, было зарабатывание денег. Во многом это остается справедливым и до сих пор, даже если отбросить радикальный лозунг «деньги любой ценой». Соответственно тезис о том, что бизнес несет в себе некую культуру создания ценности для потребителя, что эту культуру следует совершенствовать, используя в том числе современный технологический ландшафт, иногда отходит на второй план. Для многих функциональных менеджеров бывает вполне комфортно уйти от часто незнакомой для них проблематики автоматизации их же собственных направлений, сказав примерно следующее: «Мы тут зарабатываем деньги для компании, а ИТ-отдел отвлекает нас от этого важного занятия». Конечно, это аргумент весомый, и я думаю, что многие мои коллеги не раз испытали такую ситуацию на себе. Почему так происходит, ведь речь часто идет о проектах, призванных существенно повысить результативность их же собственной работы? А дело все в том, что это и есть классическое проявление формализма, который, как я уже сказал, процветает при формальной же постановке задачи и «силовых» методах контроля достижения результата. Здесь по определению всё оказывается завязано на страхе невыполнения поручений, и попытки снять с себя любую дополнительную ответственность оказываются вполне естественными.
Возвращаясь к роли ИТ-подразделения, можно сказать, что она в такой ситуации действительно особая и, к сожалению, не всегда выигрышная. Ведь по сути своей, как известно, это сервисное подразделение, обслуживающее другие функциональные департаменты. Кроме того, наша работа — это во многом проекты, часто длительные, так что без содержательного и постоянного диалога между ИТ и бизнесом не обойтись. В силу своей роли ИТ-подразделение не может «уйти в сторону» и заниматься своими делами, оно всегда настроено на конструктивное взаимодействие с бизнесом (если, конечно, правильно выполняет свою роль), но, к сожалению, в ряде ситуаций ИТ-служба не получает такого же конструктивного настроя со стороны бизнеса.
Выделяют ИТ-направление и подходы к решению задач. Так, например, если в деловой среде ощущается некоторый спад и пришло время поискать пути сокращения затрат (а это не катастрофа, а вполне штатная ситуация), то заниматься этим должны все подразделения. Такие пути может найти маркетинговый, финансовый, HR-отделы и, разумеется, ИТ-служба. Разница лишь в том, что если кто-то вполне может обойтись волевыми решениями, то в ИТ сократить затраты без потери качества практически невозможно, и это всегда не только волевые усилия, но и интеллектуальные — поиск новых решений, архитектурных трансформаций, изменений формы ИТ-поддержки и т.д. и т.п. Ведь ухудшения качества ИТ-услуг все равно «по умолчанию» никто не ожидает.
Какой же выход из этой ситуации вам видится?
Все рассуждения здесь можно изложить фактически в форме доказательства теоремы. Как я уже сказал, неучастие бизнеса в работе по автоматизации этого же бизнеса, его откровенное (а часто просто демонстративное) нежелание хоть сколь-нибудь разбираться в вопросах ИТ связано с неким глобальным шаблоном поведения в отношении управленческой культуры в компании. Иными словами, если это происходит, развивается тот самый командно-административный стиль, когда делегируется лишь ответственность, но не делегируются полномочия. Руководитель иногда единолично, иногда со ссылкой на мнение своих коллег топ-менеджеров сам принимает решения по поводу технологий и систем, но дальше в процессе внедрения не участвует, а за издержки внедрения спрашивает с ИТ-отдела. К каким деформациям это приводит с точки зрения проектов, я говорил. Отсюда вывод: такое положение вещей несет вред бизнесу, а значит, рассуждая в обратном порядке, содержательное отстранение бизнеса от ИТ-проблем неприемлемо в принципе.
Чтобы это преодолеть, необходимо встречное движение, и это ясно даже из самой общей логики. Лет десть назад я, как и все мои коллеги, думал, что ИТ-специалисты должны учиться языку бизнеса и это тождественно решению вопросов слаженной коллективной работы. Об этом говорили всегда, активно говорят до сих пор, но результата от подобных разговоров на практике пока немного. Бизнес так же как и раньше считает, что он единолично вырабатывает правильную стратегию, при этом часто вообще не представляя себе возможностей ИТ. А ИТ-служба, как может, «подтаскивает» под эту стратегию (а если таковой нет, подтаскивает под то, что есть) какие-то проекты. Это в корне неправильно, и на Западе, кстати, такого нет.
Теперь я твердо убежден, что бизнес тоже должен учиться ИТ-грамоте, чтобы говорить с ИТ-направлением на его языке, хотя бы на базовом уровне. Нам просто необходимо сделать так, чтобы освоение бизнесом ИТ-терминологии, неформальное понимание его возможностей в разных ситуациях ассоциировалось в глазах всего бизнес-сообщества как признак умелого, грамотного управления современным предприятием. Если непредвзято подходить к этому вопросу, окажется, что язык ИТ в том объеме, в котором он необходим бизнесу, совсем не так сложен, как об этом принято думать, и при этом довольно содержателен. Мой опыт показывает, что если и бизнес, и ИТ (как часть бизнеса) в равной степени идут навстречу друг другу, пытаясь совместно решать важные задачи, то больше половины проблем, о которых так много говорится в ИТ-, да и в бизнес-сообществах в России, просто исчезнет. Ведь нет же таких проблем на Западе, и у нас не будет, как только мы повысим «ИТ-грамотность» нашего бизнеса.
