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