Алексей АнаньинРодился 1 ноября 1961 года в городе Орджоникидзе. Окончил МВТУ им. Баумана по специальности "инженер -- механик-исследователь", МГУ им. Ломоносова по специальности "математик". Кандидат технических наук.Работал в НИИ проблем машиностроения, возглавлял лабораторию в ЦНИИ Министерства обороны РФ. В бизнесе с 1991 года, с 1996 года -- генеральный директор ЗАО "Борлас Ай-Би-Си". С 2001 года -- генеральный директор группы компаний "Борлас", с 2004 года -- президент консалтинговой группы "Борлас". |
Intelligent Enterprise: Каковы, с вашей точки зрения, потребности российских компаний в области автоматизации управления? Есть устойчивое мнение, что главная цель внедрения ERP-системы -- это учет финансов.
Алексей Ананьин: Да, такое мнение существует, и есть примеры проектов, в которых полный, достоверный и оперативный финансовый учет -- основная задача. Но из самого названия продукта -- ERP -- следует, что возможности его гораздо шире. Системы
планирования ресурсов оказываются востребованными там и тогда, где и когда возникает необходимость задуматься об эффективности производства, эффективности экономических механизмов предприятия, о рациональном расходовании ресурсов. И в наиболее успешных проектах последнего времени на Oracle E-Business Suite (в частности, на Магнитогорском металлургическом комбинате (ММК), на «Уралкалии») действительно реализован функционал планирования ресурсов. Именно это и было одной из основных целей проектов.
Когда предприятие выбирает стратегию поэтапного внедрения модулей ERP-системы, цели подпроектов, а следовательно, и последовательность действий определяются реальными «проблемными зонами». Так, например, в одном из наших первых проектов в области автоматизации бизнес-процессов предприятий на основе приложений Oracle -- АСУ «Персонал» в ММК были достигнуты несколько целей - обеспечение руководства и служб комбината полной, достоверной и оперативной информацией о персонале, совершенствование бизнес-процессов кадрового учета, учета рабочего времени, расчета заработной платы, управления организационно-штатной структурой, создание «фундамента» для дальнейшего развития проекта. Требовалось начать автоматизацию управления ресурсами именно с этой области, поскольку социальная сфера, персонал всегда были и остаются зоной повышенного внимания руководства ММК, а устаревшие ко времени начала проекта учетные системы и технологии работы с персоналом вызывали нарекания у работников и приводили к финансовым потерям.
В одном из наших интервью была высказана мысль, что автоматизация HR-функций всегда идет вторым эшелоном, после автоматизации управления другими ресурсами, потому что в России человеческие ресурсы достаточно дешевы, их много и так далее.
Это определяется приоритетами руководства и конкретной ситуацией. ММК -- предприятие градообразующее, в городе живет около 500 тыс. человек, и большая часть взрослого населения так или иначе связана с комбинатом. Это предприятие, на котором держится вся социальная сфера города. Одна из задач системы управления персоналом заключалась в том, чтобы предотвратить напряженность в вопросах зарплат и пенсий в масштабах города. Руководству комбината важно было обеспечить четкое понимание всеми сотрудниками политики в области зарплат и надбавок. Кроме того, благодаря традиционно сильной IT-службе комбината проблемы автоматизации основных функций не оказались слишком остры. Да, система не была интегрированной, да, были отдельные проблемы с «самописками», но не такие, которые ведут к остановке предприятия или существенной потере денег. Однако выбор в пользу интегрированной системы, базирующейся на приложениях Oracle, был сделан. Первым этапом проекта стала модернизация системы управления персоналом.
Какие еще конкретные проблемы в области планирования ресурсов решают российские предприятия с помощью ERP-систем?
Учет ресурсов -- это только начало и ERP-система -- это система именно планирования ресурсов для достижения заданных значений показателей эффективности производства. В металлургии, например, как и во многих других непрерывных производствах, есть одна очень серьезная проблема, связанная с планированием. Дело в том, что конечный продукт производственного процесса может отличаться от запланированного по ряду характеристик. И нельзя в классическом виде реализовать идеологию производства под заказ. Тем не менее функциональные возможности Oracle E-Business Suite и решения проектных команд позволяют решить главную задачу -- планирование ресурсов. А эффекты от рационального планирования очевидны -- это снижение операционных и управленческих затрат, минимизация остатков на складах, рациональные закупки… Именно поэтому мы имеем успешные проекты в металлургии и химии.
К сожалению, у нас пока нет богатого опыта автоматизации дискретного производства, но мы очень к этому стремимся. В настоящее время мы работаем с конструкторским бюро авиационной техники, где идет, в нашей терминологии, «горизонтальный» интеграционный проект. То есть помимо внедрения достаточно большого функционала Oracle E-Business Suite проводится его интеграция с параллельно внедряемыми системами документооборота, календарного планирования проектов, управления жизненным циклом изделий и др. Здесь ERP-система -- интегрирующее ядро информационной системы.
Еще один пример -- проект на одной из электростанций. Здесь планирование тоже остается ключевым моментом, но акценты другие. Для предприятий такого типа самый главный вопрос -- техническое обслуживание и ремонт оборудования, основная производственная деятельность -- это поддержание основных агрегатов в рабочем состоянии. И «сердцем» ERP-системы здесь должен стать модуль Enterprise Assets Management, обеспечивающий автоматизацию именно этой функциональной области. Хотя здесь, по логике проекта, внедрение этого модуля не стало задачей первого этапа. Сначала были решены задачи управления финансами, сейчас идет второй этап, задачи которого -- управление закупками, запасами, сбытом и персоналом. Управление ремонтами -- это самая важная задача, но и самая сложная, и чтобы к ней подойти, нужно выполнить серьезную предварительную работу по систематизации нормативно-справочной информации, спецификаций оборудования и другой технической документации. Это трудоемкий и длительный процесс.
Вообще, интерес к автоматизации управления техническим обслуживанием и ремонтами в российских компаниях сейчас очень высок. Так, в нашем проекте в одной из авиакомпаний одна из основных задач -- организация рационального обслуживания самолетов. У Oracle есть специальный функциональный модуль, связанный с комплексным обслуживанием и ремонтом объектов. Он, по сути, и является центральным в проекте, хотя это не умаляет важности управления финансами, материально-техническим снабжением и всем, что связано с планированием остальных ресурсов.
Вообще, применяя ERP-систему, каждое предприятие находит свою изюминку. И соответственно разными будут эффекты от внедрения. Кому-то важнее управлять себестоимостью, и процент снижения затрат -- это замечательный эффект, то, ради чего внедряется ERP-cистема. А в некоторых компаниях рентабельность исчисляется даже не двухзначными, а трехзначными числами, и там эффект от внедрения ERP-системы выражен в другом: не так важен точный учет затрат, потому что уменьшение себестоимости еще на 2% будет просто незаметно на фоне 100%-ной рентабельности. Здесь гораздо важнее управлять эффективностью инвестиционных проектов, обоснованно принимать решения о том, куда вкладывать заработанные деньги. ERP-система способна дать эффект и здесь.
Давайте поговорим о взаимодействии нескольких поставщиков ИТ-услуг в сложных проектах. Ведь больших проектах, где практически всегда работают несколько подрядчиков, возникает дополнительный риск, связанный с взаимодействием разных поставщиков ИТ-услуг…
Я бы разделил этот вопрос на два. Первый -- это формирование единой проектной команды из представителей разных компаний. И второй -- взаимодействие разнопрофильных поставщиков ИТ-услуг или оборудования при реализации проекта.
Мы имеем опыт работы в проектах, где проектная команда создавалась из представителей нескольких компаний, например, под руководством вендора как генерального подрядчика. Это не является проблемой и не создает каких-то препятствий для нормальной, слаженной работы команды. При этом руководитель проекта может даже не являться представителем генерального подрядчика. У нас был положительный опыт работы в команде, когда генеральным подрядчиком проекта была корпорация IBM, а руководитель проекта представлял "Борлас". На мой взгляд, здесь ничто не противоречит нормальной логике и методологии ведения проекта. Руководитель проекта подбирает команду из тех специалистов, с которыми ему, по определенным профессиональным, человеческим, социально-этическим признакам, комфортно работать. Он знает, что ему нужно достичь результата, в заданные сроки выполнить заданный объем работ, и подбирает себе команду, которая наилучшим образом это сделает. Однако нельзя не отметить риски такой организации работ. Были прецеденты, когда проектная команда работала неэффективно из-за различия культуры ведения проектов. Ведь единая методология (например, AIM у всех партнеров Oracle) -- это еще не все. Есть свой стиль работы с заказчиком, взаимодействия внутри команды, отличаются также механизмы материального стимулирования сотрудников, и соответственно возможно разное отношение к работе. Для кого-то важно закончить этап в срок, потому что иначе у него будут проблемы с начислением бонусов, а кому-то это абсолютно не важно, потому что ему платят за каждый час, проведенный на проекте. Это предмет особого внимания руководителя проекта на начальных этапах, это нужно хорошо понимать и учитывать при формировании проектной команды
Как быть в таком случае с рисками? Все риски принимает на себя генеральный подрядчик?
Риски и ответственность перед заказчиком -- это вопрос организации работ в команде исполнителей. В нашей практике есть примеры разделения ответственности между исполнителями. Если всем важен результат и все нацелены на сотрудничество во имя его достижения, то финансовые риски, например, делятся на всех. Заказчику же важно иметь одного ответственного перед ним за результат проекта и это совершенно правильно. И в этой связи я хочу вернуться к другому виду сотрудничества в рамках комплексного проекта : сотрудничества поставщиков ИТ-услуг и оборудования, компаний, поставляющих серверное оборудование, оборудование для рабочих мест, строящих сетевую инфраструктуру, и, например, компании, внедряющей ERP-систему. Когда между этими компаниями существуют только формальные отношения, нет понимания того, что делается одно общее дело, возможны проблемы с синхронизацией действий и решений и в связи с этим -- серьезные риски для проекта. Мы считаем, что оптимальный вариант и для заказчика, и для исполнителей -- единый центр ответственности, то есть генеральный подрядчик. Именно он (конечно, с согласия заказчика) собирает альянс поставщиков, с которыми ему будет удобно работать. У заказчика не будет болеть голова о том, на ком лежит ответственность за результат. Но хотя с этой логикой трудно не согласиться, к сожалению, не всегда получается реализовать ее на практике.
Однако существует мнение, что на каждый проект в рамках программы нужно проводить отдельный независимый тендер. Иногда подобное требование прописано на уровне корпоративной политики. Как правило, аргументы в пользу подобного подхода сводятся к страховке от единой точки сосредоточения рисков проекта.
Да, это так. Но, не все понимают, что исполнение этих корпоративных правил, переносимых, как правило, на IT-проекты из общих правил закупки товаров, оборудования и услуг, предъявляет серьезные требования к самому заказчику. Это возможно, во-первых, только в том случае, если у заказчика жесткая технологическая дисциплина, он сможет правильно организовать и синхронизировать работу разных поставщиков. А во-вторых, решаемая задача должна быть четко структурирована, а ее «кусочки» -- методологически безукоризненно сшиты. Компании, принимающие участие в тендере на последующие этапы программы, должны хорошо понимать, как реализовывались предыдущие проекты и как в дальнейшем части программы проектов они будут соединены вместе. Примеры такого подхода со стороны заказчика есть, но это гораздо более рискованный вариант. Все-таки наличие генерального подрядчика как единого центра ответственности предпочтительнее для заказчика. Единая точка обращений в случае каких-то нештатных ситуаций всегда гораздо эффективней, чем споры о том, кто был не прав, и аргументы типа «к пуговицам претензии есть?».
А привлечение в этом случае внешнего аудитора проекта не уменьшает подобные риски?
Аудитор проекта -- это очень популярное и эффективное в последнее время решение. Сегодня любой серьезный проект имеет аудитора, только совсем не обязательно внешнего. Аудит может быть и внутренний. Например, в некоторых наших проектах, где мы работаем вместе с Oracle, аудитором выступает сам Oracle. Этот аудит считается внутренним, но фактически он -- внешний, потому что его проводят специалисты европейского офиса Oracle.
В другом нашем проекте аудитором была компания Tops BI. В свою очередь, мы выступали аудитором одного из их проектов. Аудит в большом проекте необходим еще и из-за того, что, находясь внутри проекта, какие-то вещи можно и пропустить. Глаз, что называется, "замыливается". Аудит действительно очень полезен и повышает шансы на успех проекта.
В каких случаях вы позволяете себе отклоняться от стандартной методологии внедрения ERP-системы, рекомендованной вендором? Ведь это повышает риски проекта…
Методология Oracle (AIM), которой мы пользуемся, достаточно гибка. Однако отклонения есть, и они зависят от многих факторов, например, от индивидуальных особенностей предприятия и даже предпочтений конкретного руководителя проекта. При этом важно «с водой не выплеснуть ребенка». Отклонения обычно связаны с различной трудоемкостью одних и тех же задач в разных проектах. Скажем, работа с унаследованными системами. Здесь одна из главных задач -- «поднятие» и загрузка данных в новую систему, их очистка. На некоторых проектах этим мы вынуждены заниматься с первого этапа, иначе просто не осилить этот огромный пласт работы. Такие коррективы всегда на пользу делу и нормально воспринимаются и заказчиком, и вендором.
Или подготовка отчетов. На мой взгляд, совсем не обязательно иметь все необходимые для промышленной эксплуатации отчеты до запуска системы в промышленную эксплуатацию. Например, один наш заказчик, имевший уже опыт не одного проекта, высказал, казалось бы, парадоксальную мысль: «Я давно понял, не нужно делать отчеты на стадии опытной эксплуатации. Чтобы посмотреть, как работает система, мы залезем в таблицы, вытащим данные. Но те отчеты, с которыми персонал будет работать уже регулярно, нужно делать только после запуска системы. Два-три месяца она поработает в промышленной эксплуатации, и вот тогда станет понятно, какие отчеты кому действительно нужны». И он прав. Опыт показывает, что если отчеты делать заранее, то впоследствии используются только 30--40% из них. А ведь отчеты на самом деле штука не дешевая. Каждый раз тратится три--пять человекодней для легких отчетов и 20--40 для тяжелых. И если умножить на ставку консультанта, а отчетов нужно 300--400, получаются серьезные суммы. Поэтому очень важно изначально ограничить число отчетов. Если дать сотрудникам возможность потребовать все, что им кажется нужным, -- это будут тысячи отчетов. В одном проекте у нас была удивительная ситуация -- заказчик запросил несколько тысяч отчетов: «Вот эту строчку здесь, эту повыше, а эту пометить красным…». Потом, после нескольких итераций, количество отчетов свелось к нескольким сотням. Такие абсурдные ситуации бывают.
С другой стороны, методология AIM прогрессирует. Ее последняя версия, AIM for Business Flow, стала еще более гибкой. Она позволяет сокращать сроки, но и дает большую степень свободы, больше творческих возможностей для исполнителей. При этом, безусловно, есть вещи, которые пропустить нельзя. Есть цепочка документов, которые должны быть созданы, иначе существенно нарушатся правила документирования, нарушится план передачи информации, и соответственно будет потерян контроль над проектом. Это рамки, но флуктуации в этих рамках не вредны, а даже полезны.
В одном их наших интервью мы обсуждали своеобразный подход к внедрению ERP-системы. Он даже получил название «эволюционного». Такой подход применяется, когда организация находится на таком этапе развития, что серьезные изменения в бизнесе или изменения оргструктуры, происходят часто, и просто непонятно, какова будет часть бизнес-процессов через два года. Соответственно невозможно применить традиционную классическую методологию внедрения ERP-системы…
Реальных примеров таких проектов я не знаю. Учитывая все нюансы неорганизованности российских компаний и склонность всегда искать некую специфику и идти особым путем, не думаю, что этот подход может быть успешным в российских компаниях. Когда бизнес-процессы компании нестабильны, то, с моей точки зрения, ERP-систему внедрять не надо. Если ты начинаешь движение, но не знаешь, куда идти, кто скажет, правильно ты идешь или нет? Я не сторонник движения ради движения. Ведь организация будет работать так, как заложено в системе. Настраивать систему, понимая, что завтра все может кардинально измениться, -- бессмысленно. Оптимальный вариант -- когда логика и архитектура системы строятся исходя из стратегического замысла. Стратегический замысел порождает действия, которые в конечном итоге приводят к логике бизнес-процессов. Например, у нас в компании сейчас идет проект внедрения ERP-системы, несмотря на то что мы растем примерно на 100% в год. До последнего времени в "Борлас" работала (и работает сейчас) учетная система, созданная на основе нашего продукта АС+. Менеджеры получают всю необходимую управленческую информацию, хотя она где-то несколько более агрегирована, чем это нужно, и необходимую аналитику. К проекту мы подошли именно сейчас, а не год или два назад. Это связано с тем, что именно сейчас у нас в компании сложилось понимание того, как мы будем развиваться, какова будет организационная структура компании. Поэтому сейчас можно говорить о том, что бизнес-процессы, которые лягут в основу внедряемого решения, будут работать как минимум два-три года. Да, мы будем расти и меняться, но в рамках того "скелета", который запланировали, тех механизмов, которые мы для себя определили.
Если же компания находится в ситуации поиска, постоянного реформирования и изменения, то нужно не внедрять ERP-системы, а решать те задачи, которые актуальны сегодня. Это, например, автоматизация бухгалтерского учета, консолидация отчетности, перекладка отчетности в международные стандарты, автоматизация каких-то участков работы с персоналом. Однако нужно понимать, что если позже будет принято решение о создании интегрированной информационной системы, многое придется переделывать. В принципе постоянное реформирование компании не должно быть причиной остановки поступательного движения по автоматизации каких-то участков. И примеров тому много. Крупные холдинговые компании начинают с того, что создают систему консолидации отчетности или систему сквозного бюджетирования предприятий холдинга. И при этом менеджеры компании понимают, что, если отсутствует полноценная учетная система на некоторых предприятиях, данные будут корректными в пределах некоторого допуска. Часто такие системы создаются, чтобы выявить тенденции на уровне холдинга или подготовить высокоуровневую отчетности акционерам. В таких случаях погрешности в объеме холдинга нивелируются, и результирующая ошибка не велика.
Какова с вашей точки зрения роль ИТ-директора крупной компании. С одной стороны, мы слышим, что CIO должен принимать участие в стратегическом планировании компании и влиять на ее бизнес. С другой -- мало где это происходит в реальности и есть точка зрения, что ИТ-отдел должен выполнять исключительно сервисные функции…
Роль CIO определяется позиционированием ИТ-службы в компании. Сегодня нет необходимости доказывать, что полная, достоверная и оперативная информация – один из основных стратегических ресурсов, определяющих эффективность управления, а следовательно и эффективность предприятия. И там, где это понимают, реализация ИТ-стратегии предприятия четко связана с реализацией бизнес-стратегии. И не принципиально, какой курс выбран: аутсорсинг или собственная полноценная ИТ-служба. Если взят курс на аутсорсинг (а таких предприятий уже немало), выделение ИТ-функций во внешние сервисы и превращение ИТ-службы в службу заказчика, ИТ-стратегия и деятельность CIO направлены на то, чтобы правильно организовать работу этой службы. Основными задачами становятся: организация кооперации исполнителей, постановка задач и контроль их исполнения. Если же ИТ-служба - составная часть бизнес-структуры предприятия, причем одна из самых важных, то в этом случае у CIO несколько другая роль. Как правило, и в том, и в другом случае , на нем лежит ответственность и за сервисные функции, но, главная задача, безусловно, обеспечение менеджмента информацией. И примеров очень серьезного отношения к этой роли уже достаточно много.
