Александр Капустин - кандидат технических наук, заместитель генерального директора НТЦ "Северо-запад". Работал директором ИТ-департамента банка "Петрокоммерц". Имеет ряд успешных ИТ-проектов: автоматизация "интеллектуального" здания центрального офиса, автоматизация 20 новых филиалов банка, ИТ-аудит 5 приобретенных банков, организация смены АБС в этих банках, или обеспечение взаимодействия с "головной" АБС, построение и развитие платежной системы ACCORD и платежной системы на базе международных систем Mastercard\VISA.
Александр Михайловский - начальник отдела информационного обеспечения управляющей компании холдинга "Металлоинвест", принимал участие в разработке ПО, руководил рядом ИТ-проектов как со стороны ИТ-компаний, так и заказчиков.
В 8 номере Intelligent Enterprise (19 апреля 2004 года) было опубликовано интервью с начальником ИТ-отдела холдинга "Металлоинвест" Александром Михайловским "Прагматичный подход к ИТ". Честно говоря, некоторые тезисы Александра Михайловского, что называется, "задели за живое". Уж слишком, на мой взгляд, спорным оказывается его "прагматичный" взгляд. Поэтому хотелось бы высказать несколько своих мыслей по обсуждаемым вопросам. Мне кажется конструктивная полемика может быть интересна широкому кругу читателей, которых я и приглашаю к обсуждению поднятых вопросов.
О стандартах на ПК
Александр Михайловский: "Жесткий подход [к стандартам на ПК] хорош,
но только в тех случаях, когда мы говорим об отделе с фиксированным количеством
задач, например бухгалтерии, где есть достаточно жесткие должностные инструкции,
жесткое распределение функций, когда отдел замкнут и нет взаимодействия с окружающей
средой. В противном случае выясняется, что… нужны архиваторы каких-то новых
версий и так далее. Мягкий подход не предполагает такой фиксированной схемы.
В итоге, когда количество стандартов на компьютеры в компании превосходит 20,
это уже не стандарты".
Александр Капустин: Безусловно согласен, что 20 стандартов на ПК - это
не стандарты. Однако даже при более мягком подходе к стандартам он не должен
переходить некоторые рамки. На мой взгляд, в обычной управляющей компании просто
неоткуда взяться 20 стандартам на ПК. Даже в крупных финансовых институтах таких
стандартов не более 5. И этого оказывается вполне достаточно, никаких проблем
с "архиваторами" нет. Стандарт должен обязательно включать в себя
стратегическое решение - применение техники международных брендов или ПК российской
сборки. Дальнейшие различия в стандартах - это размер памяти (этот стандарт
для основной массы работников диктуется требованиями операционной среды), размер
жесткого диска (стандарт значительно сужается, если учесть, что диски менее
60 Гб приобретать бесперспективно), необходимость внешних накопителей (стандарт
также в значительной степени сужается, если в организации "правильная"
служба информационной безопасности), ну и, конечно, тип и размер монитора (там,
где на столе необходимо иметь несколько мониторов - например, у ИТ-администратора,
брокеров в банках и т. д - а также у тех категорияй работников, которые по должностным
обязанностям много времени проводят за "экраном"). Хотя и последний
стандарт может быть значительно сужен, если учесть, что разница между стоимостью
17-дюймового ЭЛТ-монитора и 15-дюймового ЖК-монитора уже очень несущественна.
В этой же связи хочу заметить, что идеальная конструкция - это применение Х-терминалов, чем, собственно, и пользуются многие компании похожего профиля. Заодно решается и проблема стандартизации и учета ПО и обновлений, и "апгрейдить" нечего. Кроме того, очень просто решается проблема информационной безопасности. Ну а распространенная проблема дороговизны каналов связи легко оценивается. Думаю, для крупных корпораций, имеющих свою корпоративную сеть, такое решение очень перспективно.
Обновление парка ПК
Александр Михайловский: "Я не вижу смысла в планомерном обновлении ПК. Чтобы поддерживать старый парк, нужны два сотрудника, и чтобы заниматься закупками нового оборудования, нужны те же два сотрудника. Иначе говоря, у меня есть те же самые затраты на персонал, только добавляются еще и затраты на новые ПК".
Александр Капустин: На мой взгляд, связывание планомерности смены парка ПК с количественным составом ИТ-службы - принципиально неверно. Автоматизация уже давно (пожалуй, со времен изобретения паровых машин), не ставит целью сокращение персонала. Есть объективная реальность: если бизнес хочет развиваться, то придется менять и парк ПК.
Да, конечно, подход "не трогать, пока работает" имеет серьезный плюс - всегда можно сказать руководству: "Я ведь экономлю". Возможно, в некоторых случаях это оправданно. Но, на мой взгляд, намного важнее умения экономить - умение "экономно" вкладывать, и отвечать за правильное и своевременное освоение вложений для обеспечения задач бизнеса. Кроме того, подход "не трогать, пока работает" достаточно опасен. Ведь в тот момент, когда от бизнес-подразделений придет заявка на новые ПК, можно просто не успеть, ведь кроме покупки оборудования и ПО нужен еще обученный ИТ-персонал, четкие процедуры миграции, тестирования и т.д.
Поэтому, на мой взгляд, планирование замены парка ПК необходимо. Из перспективных планов развития бизнеса достаточно просто посчитать инвестиции в обновление парка ПК. Более того, можно коррелировать эти планы с возможностями инвестиций поставщиков оборудования в виде кредитных линий, лизингов или отсрочек платежей. Это даст возможность построить динамично развивающуюся вместе с бизнесом ИТ-инфраструктуру.
Пилотные проекты
Александр Михайловский: "Выбор решения надо проводить снизу, по нарастающей. Взять наиболее простой и дешевый продукт и посмотреть, можно ли с его помощью решить поставленную задачу. Если нет - нужно начинать рассматривать более дорогие варианты. И как только появится возможность решения, останавливаемся и делаем пилотный проект".
Александр Капустин: Полностью согласен, пилотные проекты действительно необходимы. Однако мое понимание пилотного проекта достаточно сильно отличается от того, которое есть у Александра Михайловского. С моей точки зрения, вопросы применимости системы и ее экономическая целесообразность оцениваются на этапе выбора системы и подготовки предприятия к внедрению. А далее, когда решение уже принято, определяется последовательность внедрения с организационной и функциональной точек зрения и выбирается место для пилотного проекта. И цель пилотного проекта - стандартизировать и отработать процессы и решения, чтобы далее сделать некий прототип и далее его тиражировать. А попытка сделать что-то на наиболее дешевом ПО - это не пилотный проект. Пилотный проект может (и, как правило, делается) на условно бесплатной версии ПО, предварительно подобранной и с позиции ценовых характеристик, закрывающего требуемый фунционал и обладающего перспективами развития.
Написание ТЗ
Александр Михайловский: "Второй вариант [написания ТЗ] - обратиться к консультанту. Тут те же проблемы, потому что у консультантов есть заготовка правильных, с их точки зрения, бизнес-процессов, и они начнут "натягивать" ваши задачи на эти бизнес-процессы - через "литры крови", а потом порекомендуют все "снести" и внедрить SAP R/3, сотрудников уволить, а других набрать".
Александр Капустин: Не могу согласиться с тем, что постановщик ИТ-услуг не сможет быстро написать хорошее ТЗ на проект. По моему опыту, это вполне правильный путь, дающий реальные результаты. Для примера могу привести организацию работы в "УралСибе", где вообще не было программистов, а в штате ИТ были банковские аналитики, которые и занимались написанием ТЗ. Другая модель организации работ - банк "Петрокоммерц", где есть свои программисты, и они же выступают в роли постановщиков задач при заказах объемных доработок или формированием ТЗ на интеграционные процессы при приобретении новых продуктов. На мой взгляд, последняя модель более оптимальна. Да, бывают и неудачи, но если консультант имеет за спиной более крупный (или равный по сложности) успешный проект (это обязательное условие, и во многих случаях гарантия), то он сможет сделать грамотное ТЗ. А уж ядро ТЗ вообще может быть написано достаточно быстро.
Управленческая отчетность
Александр Михайловский: "Конечно, данные надо собрать и обработать, но, на мой взгляд, это можно сделать и без компьютеров. Грамотный коммерческий или финансовый директор может построить из людей точно такую же пирамидку, которая регулярно в девять часов утра будет класть отчеты на стол. Если это аккуратно сделано, то люди знают, что делать… этот отчет выдается за 30 с по запросу".
Александр Капустин: Согласен, такую "пирамидку" можно построить без ИТ, что, собственно, и подтверждено огромным опытом управления, который существовал до активного внедрения информационных технологий. Но опыт показывает, что "пирамидки" могут быть разные. "Пирамидка" может быть установлена и на вершину - когда внизу находится один (или несколько) очень умный специалист по отчетам, который хорошо знает структуру отчетов во всех мелочах, и почти единолично готовит их в срок. Но в этом случае она неустойчива: стоит ему заболеть, уйти в отпуск, уволиться - и пирамида рухнет. Либо она может быть установлена на основание - когда внизу находится много специалистов по отчетам, готовящих массу узких отчетов с консолидацией "снизу-вверх". Но в этом случае, без применения ускоряющей этот процесс ИТ-инфраструктуры, она неповоротлива. Ведь, как правило, при получении управленческих отчетов задача так и ставится - речь не идет о том, что отчетности нет, а как раз о том, что она приходит поздно и на ее получение тратится настолько много времени, что она теряет актуальность. Именно здесь и необходим ускоритель этого процесса в виде ИТ, предоставляющий, кроме того, замечательные возможности по ее хранению, быстрому поиску историй, возможностям аналитики по новым схемам и т.д.
Привлечение аудиторов и консультантов
Александр Михайловский: "Увы, независимых консультантов не существует. Даже если консультант не является зависимым напрямую от поставщика услуг по внедрению, то он зависит от своего жизненного опыта. Он продает свой опыт и от него зависим. Если придут два консультанта, и один имел дело со швабрами, а второй с молотками, то, обследовав фирму, первый скажет, что не хватает швабры, а второй - что молотков. И каждый будет прав. Консультанты попытаются передать мне опыт, который мне, может быть, и не нужен".
Александр Капустин: На мой взгляд, в этом рассуждении есть доля правды, однако это совершенно не значит, что ИТ-консультанты не нужны. Разумный ИТ-консалтинг конечно же необходим, другое дело, в какой форме и объемах. И именно на это влияют среда и история предприятия. А плюсы есть, и немалые. Ведь как это ни печально, любая существующая модель ИТ в российских компаниях уже была проверена кем-то в мире, и нет ничего страшного в том, чтобы уметь переступать лишние ступеньки с помощью консалтинга. Это значит экономить время и деньги. По моему опыту общения с консультантами, при подготовке ИТ-решений всегда возникает проблема доказательства необходимости инвестиций в эти решения и необходимость в консалтинге в крупных ИТ-проектах зачастую возникает именно на этом этапе. Необходимость в ИТ-консалтинге появляется не по инициативе ИТ-служб, а по инициативе инвестиционных подразделений или высшего руководства. Возможно, в принципе, надо было бы обидеться - "проверяют квалификацию". А на самом деле иногда действительно подсказывались более оптимальные решения, и самое главное - это всегда помогало получить инвестиции в проекты.
На мой взгляд, консалтинг полезен и необходим. Правильный бизнес-руководитель, имеющий личный ИТ-консалтинг (желательно, чтобы ИТ-служба о нем не знала), и благодаря ему разбирающийся в вопросах ИТ, будет содействовать правильно заявленным инвестициям в ИТ. И это продвинет предприятие вперед. Ведь существуют, скажем, примеры, когда ИТ-стратегия формулировалась внешними консультантами в основном для того, чтобы функциональные руководители предприятия смогли сформировать свое видение развития ИТ в компании. Правильное понимание топ-менеджментом компании места информационных технологий необходимо для нормальной работы ИТ-подразделений в компании.
