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

Intelligent Enterprise: Давайте начнем разговор с проекта по учету и инвентаризации ИТ-средств, который вы сейчас ведете.

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

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

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

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

Я не вижу смысла в планомерном обновлении ПК. Чтобы поддерживать старый парк, нужны два сотрудника, и чтобы заниматься закупками нового оборудования, нужны те же два сотрудника. Иначе говоря, у меня есть те же самые затраты на персонал, только добавляются еще и затраты на новые ПК. Например, никто же не говорит: "Этот автомобиль хороший, работает, но я не могу на нем ездить". Автомобиль должен работать до того момента, пока закупка запасных частей оправданна и не приходится платить за раритетность. К тому же, как известно, из двух сломанных ПК собирается один работающий, и морально устаревшая техника продолжает "жить". Всегда можно придумать, как использовать старый компьютер. Итак, смысла в планомерном обновлении ПК я не вижу.

Аналогичная ситуация и с ПО. Уровень пакетного программного обеспечения, начиная от Microsoft и кончая Hewlett-Packard, крайне низок. Программное обеспечение практически не проходит тестирований. Хуже программного обеспечения делают только документацию к нему. К проекту разработки заказного ПО, на мой взгляд, документации не существует вообще, поэтому, когда программист уходит из компании, работу приходится начинать сначала. Из-за такого качества обновления к тем или иным программам нужно ставить примерно раз в месяц. Это значит, что еще пять сотрудников должны заниматься их установкой, причем четко фиксировать, где что-то уже поставлено, а где нет. Теперь прибавим к этому текучесть кадров и "мягкий" подход к стандартам. В итоге целый штат сотрудников должен заниматься только учетом.

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

Вообще, я сторонник принципа "не тронь, пока работает". Я не верю консультантам, которые говорят: "Вам неплохо бы внедрить то-то", или, как пишут в рекламных проспектах: "Если вы внедрите такую систему, то-то у вас повысится на 15%, а то-то уменьшится на 10%". Нет. С моей точки зрения, реализация проекта целесообразна только в том случае, если без этого вы работать больше не сможете. И тогда возникает воля к внедрению, тогда возникает возможность довести проект до конца.

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

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

Ни в России, ни на Западе не умеют писать планы. Западные специалисты планируют проекты, но это не является гарантией, что этим планам будут следовать. Для оправдания даже придуман специальный термин spiral planning ("спиральное" планирование). Это методика, в которой мы приблизительно ставим цель, делаем шаг и затем уточняем цель. Точно так же, как в России - "глаза боятся, руки делают". Важно, чтобы проект не выходил за рамки бюджета.

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

Получается, что вы реально не можете написать ТЗ на какую-то задачу без пилотного проекта?

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

Вы не считаете, что правильно построенные бизнес-процессы способны повысить эффективность бизнеса?

Все это иллюзии. Если бы компании изначально строились как совокупность бизнес-процессов, прописывали для каждого сотрудника функциональные обязанности, тогда так и было бы. Но ведь в России структура подчинения очень часто является неформальной, а реальный бизнес-процесс состоит в том, кому позвонить (если нужно согласовать договор не за два года, а за три месяца), от кого представиться и что сказать. Зачастую этим и определяется ценность сотрудников в российском понимании, и эта информация ни под каким предлогом не передается. Существует такое условное деление на staff и кадры: у staff есть бизнес-процессы, у кадров есть знакомые люди.

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

Американский подход, когда люди являются винтиками в огромной машине, у нас пока не работает. Конечно, его пытаются использовать, но по моему опыту, даже в тех российских компаниях, которые строятся по западному принципу, - многое строится на межличностных отношениях. По-другому у нас нельзя. Более того, и на Западе тоже нельзя. У меня есть опыт работы в западных компаниях, и я могу сказать, что там тоже все не так красиво, как утверждают консультанты. Иначе не было бы скандалов, когда вдруг выясняется, что в отчетности куда-то пропали 4-5 млрд долларов.

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

Вообще говоря, когда руководителю нужен отчет для принятия решений, ему все равно, каким способом будет получена эта бумажка, а если секретарь имеет хороший почерк, может быть, лучше и от руки. Конечно, данные надо собрать и обработать, но, на мой взгляд, это можно сделать и без компьютеров. Грамотный коммерческий или финансовый директор может построить из людей точно такую же пирамидку, которая ему регулярно будет в девять часов утра класть отчеты на стол. Если это аккуратно сделано, то люди знают, что делать, и бухгалтерия не начинает лихорадочно что-то поднимать в старой отчетности - этот отчет выдается за 30 с по запросу.

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

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

А вы не рассматриваете вариант привлечения сторонних консультантов, которые выполнят аудит и помогут решить те или иные проблемы? Ведь это явно сократит затраты вашего времени и, вполне возможно, сократит издержки.

Увы, независимых консультантов не существует. Даже если консультант не является зависимым напрямую от поставщика услуг по внедрению, то он зависит от своего жизненного опыта. Он продает свой опыт и от него зависим. Если придут два консультанта, и один имел дело со швабрами, а второй с молотками, то, обследовав фирму, первый скажет, что мне не хватает швабры, а второй - что молотков. И каждый будет прав. Консультанты попытаются передать мне опыт, который мне, может быть, и не нужен.

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

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

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

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

А вариант стороннего аудита информационной системы компании?

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

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