Через череду сложностей и недопонимания ИТ-отдел концерна «Силовые машины» сформировал собственное представление о том, как нужно общаться с топ-менеджментом компании и как правильно вести ИТ-проект. Своим опытом делится руководитель центра информационных систем компании «Силовые машины» Сергей Малахов.
|
Родился в 1961 году в Москве. В 1984 году закончил факультет экономики и права УДН им. Патриса Лумумбы, в 1989 — защитил диссертацию (кандидат экономических наук) на факультете экономики и права УДН.
|
Intelligent Enterprise: Давайте сначала опишем организационную структуру ИТ-отдела «Силовых машин». Насколько нам известно, она не совсем стандартная…
Сергей Малахов: Да, у нас она не очень стандартная. У нас не существует CIO в традиционном виде, и это объясняется разными причинами. На сегодняшний день функции ИТ-службы разделены между двумя подразделениями. Я возглавляю центр информационных систем и отвечаю за проектирование и внедрение систем. Параллельно в «Силовых машинах» существует управление информационных технологий, которое отвечает за эксплуатацию систем. У этих подразделений еще и разное подчинение. Такое решение достаточно долго обсуждалось, и руководство пришло к выводу, что, скажем, аналитика и проектирование систем — это прежде всего компетенция директора по стратегии, а эксплуатация корпоративной информационной системы — это прерогатива административной дирекции, которая отвечает за текущее состояние дел.
Но такое разделение ведет и к существенным проблемам. Например, при передаче систем в эксплуатацию. Для многих предприятий это огромная проблема — переход системы от тех, кто разрабатывает и внедряет, к тем, кто эксплуатирует.
Да, это проблема, и часто передача систем в эксплуатацию проходит очень сложно. К примеру, на «Заводе турбинных лопаток» до сих пор функциональную поддержку ERP-системы осуществляют сотрудники центра информационных систем. К управлению информационных технологий, которое отвечает за эксплуатацию систем, она не перешла. Объясняется это тем, что последний год принес нам очень серьезные организационные перемены. Все заводы объединились в одно юридическое лицо. Но хотя юридически объединение состоялось, структурные подразделения были еще обособлены. Создавалась единая финансовая дирекция, единый финансовый центр, и поэтому постоянно росло количество новых задач. В этих условиях было очень трудно провести грань между поддержкой системы и ее проектированием. Но что касается передачи в эксплуатацию, наша ИТ-служба — не самый лучший пример.
Какие проекты вы ведете в области автоматизации управления?
Наш бизнес — один из самых сложных. Наши ключевые проекты — это строительство электростанций в России и за рубежом, собственное производство энергетического оборудования, его закупки, как в России, так и за рубежом, в которых участвуют более двухсот контрагентов, проектирование станций (работа с конструкторами и конструкторским подразделениями, как собственными, так и субподрядчиками), поставка оборудования. Причем у нас достаточно большая логистическая цепочка, транспортировка иногда проходит через полмира, маршруты очень разнообразны. Сложность бизнеса и была одной из причин выбора в 2001 году корпоративной информационной системы. В качестве основы мы остановились на решениях SAP, прежде всего потому, что Siemens, наш традиционный партнер и конкурент, принял mySAP Business Suite как основное решение.
Сегодня mySAP Business Suite внедрена на трех заводах (Ленинградском металлическом заводе, «Электросиле» и на «Заводе турбинных лопаток») и в головном офисе. На сегодняшний день мы имеем в терминологии SAP промышленную эксплуатацию всех логистических и финансовых модулей. А именно: «Электросила» — промышленная эксплуатация модулей FI, CO, MM, SD, AA, «Завод турбинных лопаток» — модулей FI, CO, MM, SD, AA, PP(I), «Ленинградский металлический завод» — модулей FI, СО, MM, SD, AA, PS и головная компания — BW/SEM. В целом функционал достаточно большой.
Однако проект внедрения mySAP Business Suite не закончен. На ЛМЗ пока осуществляется параллельная эксплуатация старых и новой систем. Актуальна и проблема интеграции данных. Поэтому сейчас мы планируем инсталлировать и освоить портальное решение — SAP NetWeaver, которое позволяет на сегодняшнем этапе организовывать совместную работу всех участников проекта: руководства концерна, проектной организации, заводов-изготовителей, экспедиторов и экспертов заказчика и так далее (подробнее об этом читайте в интервью с Сергеем Малаховым и Александром Никитиным «На трех ERP-системах, как на трех китах» в № 22 2004). Мы не заглядываем далеко вперед в освоении Web-технологий, но понимаем, что возможности Web-сервера гораздо больше.
У концерна «Силовые машины» богатая история. Традиционно на подобных предприятиях высок процент собственных разработок…
mySAP Business Suite составляет основу нашей корпоративной информационной системы. Да, у нас есть собственные разработки. Но опыт работы с ними скорее негативный, хоть они и одни из лучших. Вы правы, наши заводы не были пустыми в плане автоматизации, при них существовали институты математиков, которые разрабатывали ПО, постоянно развивая его и наращивая. Одним из таких заводов был «Ленинградский металлический завод», там все эти задачи практически были решены. Но сейчас ситуация несколько поменялась: возникли новые требования в области налогового учета, начинает меняться учетная политика. И ситуация с собственными разработками оказалась тупиковой.
Вы отмечали, что хотя юридически объединение состоялось, структурные подразделения концерна еще обособлены. Насколько в такой ситуации можно говорить о централизованном принятии решений в области ИТ?
На самой ранней стадии существования холдинга наши заводы, которые сегодня являются филиалами — «Ленинградский металлический завод», «Электросила» и «Завод турбинных лопаток», — обладали очень большой автономностью. Многие вопросы решались более чем коллегиально, с учетом мнений директоров заводов. Они и сейчас зачастую решаются так же, хотя директора филиалов имеют меньше полномочий, чем имели директора заводов.
Поэтому мне специально приходилось выстраивать отношения с топ-менеджментом на каждом из питерских заводов и «продавать проект внутри». Трудовые коллективы этих заводов уникальны, каждый из них обладает своей специфической внутренней корпоративной культурой. В этом смысле между ними знак равенства ставить было нельзя. В каждом из трех случаев, так же как и в головном офисе, для внутренней продажи проекта использовались различные способы и методы.
Расскажите подробнее о методах внутренней продажи проекта. Оцениваете ли вы ROI?
По профессии я экономист. Достаточно долго преподавал корпоративные финансы и выполнял проекты по анализу хозяйственной деятельности (так в советское время именовался управленческий учет) на многих промышленных предприятиях России. Поэтому могу с уверенностью сказать, что когда сегодня заводится разговор о попытках рассчитать ROI — это наследие прагматичной экономической философии второй половины XX века. Обязательное требование ROI — это догма. Более того, это догма даже среди самих экономистов. По большому счету, если вы проанализируете статистику соответствия финансовых результатов инвестиционных проектов и плановых оценок по этим проектам, то статистика будет явно не в пользу последних. Однако, как правило, на уровне корпорации это внутренняя информация, и ею не делятся. Мало кто признается, насколько точно результаты проекта соответствовали прогнозу. Если взять, например, статистику Мирового банка и его инвестиционных проектов, то окажется, что не более 10% его проектов соответствуют прогнозам. А ИТ — это та сфера, где очень много побочных эффектов, где очень часто играют роль немонетарные факторы, которые сложно учесть. Поэтому когда финансовые директора корпорации требуют предоставить ROI ИТ-проекта, мне кажется, что таким образом они просто отмахиваются от ИТ-директоров.
Я ни в коем случае не говорю, что количественные оценки не нужны и невозможны. Однако серьезный финансовый анализ ИТ-проекта предполагает более развитые инструментарии, например опционную модель. По большому счету, всем нам знакомое понятие «пилотный проект» есть не что иное, как опцион. Мы вкладываем небольшие средства, смотрим, как проект развивается, а потом либо реализуем опционное развитие, либо нет. То есть исходим из понятия, что проект — это не «черный ящик» (здесь я просто отсылаю читателей к главе 10 одного из самых известных учебников по корпоративным финансам — «Принципы корпоративных финансов» Ричарда Брейли).
Чтобы было понятнее, хочу привести масштабный пример использования опционной модели. Например, мы внедрили все стандартные для первой фазы проекта внедрения ERP-системы функциональности управления. То есть на всех заводах стоит: материально техническое снабжение, управленческий учет, финансы. Это больше чем пилотный проект по внедрению SAP R/3. Тем не менее надо развиваться дальше.
Кстати, мне часто приходилось отвечать на вопрос: «Сколько можно тратить на R/3?». На мой взгляд, ответ зависит от освоенной функциональности. Эффективность системы R/3 существенно возрастает, когда вы выходите за рамки некоего стандартного набора модулей (рис. 1). Ранее мы внедряли ту функциональность ERP-системы, которая просто обеспечивает поддержку корпоративной информационной системы, но ни в коем случае не добавляет стоимости самой компании. Добавление стоимости в нашем конкретном случае — это та клиент-ориентированная функциональность, которая нам необходима при выходе на международные рынки и которую мы сейчас начали развивать (оперативная логистика, CRM, управление проектами, продажами и сервисом).
Именно здесь лежит ответ на вопрос о затратах на R/3. То есть можно говорить о «внутренней» и «внешней» стоимости R/3. Первая предполагает освоение функциональности, необходимой для жизнеобеспечения компании. Имеются в виду финансовый и управленческий учет, управление логистикой, оборудованием и персоналом. Экономическая эффективность в этом случае может формироваться только путем снижения затрат, то есть повышения рентабельности. «Внешняя» стоимость проекта — это та функциональность, за счет которой компания привлекает больше клиентов и наращивает обороты. Если у компании хватит терпения и денег преодолеть первый этап, то на втором этапе она будет получать реальную отдачу от ИТ-проекта. К сожалению, и терпение, и деньги — это ограниченные ресурсы.
Когда прежде объявлялся тендер на строительство электростанции за рубежом, российские участники тендера всегда выглядели очень бедно, так как тендерные вопросы пересылались в Москву, там делали какие-то расчеты на бумагах, и все это пересылалось обратно. Портальное решение, в необходимости которого мы убедили руководство концерна, позволяет заказчику непосредственно, начиная с тендера, видеть весь предварительный план проекта, сетевой график и так далее. Скажем, турбина изготавливается довольно долго, полтора-два года. За эти полтора-два года на завод чуть ли не каждый месяц приезжает делегация заказчика и контролирует, как идет работа. А теперь представьте, что процесс изготовления турбины или станции разбросан по нескольким заводам. Сегодня нашим несомненным конкурентным преимуществом является то, что мы можем отслеживать логистические маршруты и даем эту возможность клиенту. Для нашего заказчика управление бизнес-проектом становится прозрачным. Руководство осознало необходимость в этом и даже в условиях жестких бюджетных ограничений дало добро на внедрение NetWeaver. Вот такой маленький масштабный пример использования опционной модели в нашей практике.
Однако у опционного подхода есть, на мой взгляд, два основных ограничения. Это временной горизонт доверия — неизвестно, сколько высшее руководство будет терпеть ИТ-руководителя, который говорит: «Давайте потренируемся, сделаем пилот». Вероятность увольнения или потери доверия резко возрастает. Второе ограничение — понятийный горизонт управления. Что я под этим понимаю? Если говорить честно, то далеко не всегда финансовые директора, директора по экономике воспринимают аргументы в пользу ИТ-проекта, которые формировались, скажем так, на их собственной территории. У нас был аналогичный опыт, когда мы пытались показать, что именно благодаря информационным технологиям можем более эффективно нормировать оборотные средства. Однако, к сожалению, некоторые наши специалисты по экономике и финансам восприняли это как покушение на их компетентность, как «выход на их поле».
Очень часто внутренняя продажа проекта заключается в том, что на уровне топ-менеджмента выделяется один из ведущих топ-менеджеров, который фактически является движущей силой проекта. И проект стартует и развивается в значительной степени благодаря организационному административному ресурсу данного конкретного топ-менеджера.
Это я называю «гонка за лидером». На мой взгляд, такая стратегия оказывается очень эффективной только в краткосрочном периоде, с чем нам и пришлось столкнуться на одном из наших заводов. Мы запустили проект, удовлетворили все пожелания такого лидера — и в результате получили «кривое» решение, неспособное к дальнейшему саморазвитию. В дальнейшем на двух других проектах мы отказались от следования пожеланиям лидеров, а ставили своей задачей прежде всего работу с остальными службами предприятия.
Ведь на уровне принятия бюджета ИТ-проекта возникают различного рода коалиции. Иными словами, существует масса внутренних решений, которые будут поддерживаться двумя или тремя топ-менеджерами компании. Например, возьмем три подразделения: производство, где первый заместитель по производству является безусловным лидером, ИТ-отдел и службу снабжения. Как показала практика, создать коалицию ИТ-отдела со снабжением в данном случае более эффективно, чем потакать прихотям безусловного лидера внутренней корпоративной структуры. Наглядно это можно продемонстрировать при помощи матрицы дилеммы двух «заключенных» — ИТ и снабжения (рис. 2; цифры, указанные в матрице, используются для наглядности).
Предположим, при формировании бюджета у ИТ существует вариант: кооперироваться со снабжением или подстроиться под лидера. На практике это означает выбор между лоббированием ИТ-проекта либо в области логистики, либо в области производства. На первый взгляд, выбор должен быть сделан в пользу второго, ведь в союзе с лидером — руководителем производства гораздо легче «выбить» строку в бюджете. Однако это далеко не так. Ведь перед руководителем логистики стоит точно такой же выбор — например, бороться за увеличение поставок оборудования либо за автоматизацию логистических процессов. Первый вариант — это гонка за лидером, второй — коалиция с ИТ-руководителем. И если руководитель логистики и ИТ-руководитель будут подстраиваться под руководителя производства, то они рискуют получить лишь «крохи с барского стола» — их собственные бюджеты прирастут незначительно. А создав коалицию, они «выбьют» гораздо больше. Руководитель логистики может рассчитывать на повышение окладов своих сотрудников, квалификация которых растет в ходе работы над ИТ-проектом, новое оснащение рабочих мест и тому подобное. А руководитель ИТ-подразделения получает проект, в котором его полномочия по факту будут гораздо шире, ведь руководитель логистики — равноправный партнер, а не безусловный лидер.
Что у нас получается? Когда бюджет ИТ-проекта составляется строго под лидера внутренней корпоративной культуры, а все остальные службы ищут коалиции с ним, то в результате каждая из этих служб получает меньше, чем если бы они консолидировались на горизонтальном уровне. В моей практике был случай, когда мы консолидировались именно таким образом. Вопрос стоял так: развивать систему вглубь производства или в логистическом направлении? Нам удалось убедить специалистов по логистике, и это дало нам дополнительные ресурсы, в итоге именно в этом направлении стала развиваться система. А через некоторое время производственники сами подтянулись к проекту — но уже как ведомые. Иными словами, кооперация ИТ-отдела и отдела снабжения часто дает оптимальный результат.
Но, конечно, главный аргумент при продаже проекта — это ответственность за его результаты. Поэтому, планируя проект, необходимо выделять этапы с осязаемым итогом. Это очень сложно при внедрении систем класса ERP. Очень часто здесь главенствует модульный подход, при котором нарушается логика интегрированной системы, а ее дальнейшее развитие всегда требует «переделок», «перенастроек» и так далее. Поэтому лучше сохранять верность припнципу ИСУ: автоматизировать максимально глубоко, но отдельные процессы.
