Давайте начнем разговор об автоматизации крупных компаний с ФСК, для которой вы являетесь генеральным системным интегратором. Какие задачи вы решаете сегодня в ФСК?
ФСК ЕЭС - компания по сути производственная, для нее очень важна поддержка
производственного процесса. Компания была создана как организация, обеспечивающая
управление национальной электрической сетью, и ее главной задачей является надежность
работы и эффективная организация обслуживания всей инфраструктуры передачи электроэнергии.
Поэтому одним из критичных бизнес-приложений для ФСК является система управления
основными фондами, то есть поддержка процессов ремонта и обслуживания объектов
электросети (в качестве такого решения была выбрана система IFS Applications).
С другой стороны, в сферу ответственности ФСК ЕЭС входит предоставление услуг по передаче электроэнергии субъектам оптового рынка электрической энергии. И с этой точки зрения, как для коммерческой компании, ей важен точный учет стоимости предоставленных услуг. Можно сказать, что ФСК - специфичная компания, поскольку в ее деятельности сочетаются государственные методы управления (как естественная монополия ФСК контролируется государством) и предпринимательский менеджмент - в компании работают прогрессивные менеджеры, стремящиеся организовать эффективную коммерческую структуру. С этих позиций возникают задачи автоматизации, близкие скорее к задачам крупных дистрибьюторов.
Кроме этого, у ФСК сегодня существует еще целый круг задач, попадающих под понятие "обеспечение актуальности данных". Это и обеспечение актуальности финансовой информации, и консолидация отчетности, и оптимизация процессов бюджетирования, и организация единой системы документооборота, охватывающей все региональные подразделения компании. Как генеральный системный интегратор TopS BI выполняет консалтинговые функции, помогает в управлении возникающей в такой ситуации программой проектов.
Для решения этих задач есть несколько путей. Почему ФСК пошла по пути выбора генерального системного интегратора?
Ситуация сложилась так, что в ФСК, в отличие от многих российских крупных компаний, не было собственного крупного ИТ-отдела. После выделения ФСК из РАО ЕЭС ИТ-системы, которые используются компанией, остались на обслуживании в "ГВЦ энергетики". При этом позиция ведущих менеджеров компании в отношении создания и обслуживания информационной системы состоит в максимальном использовании аутсорсинга. "ГВЦ энергетики" не является аутсорсинговой и сервисной компанией и не мог обеспечить решение новых задач.
Вообще, в ФСК с самого начала задача была поставлена, на мой взгляд, очень правильно. Сегодня в России редко кто из руководителей ставит задачу таким образом: "Вот наши бизнес-процессы, дайте нам не ИТ-решение, а ИТ-поддержку этих процессов". Как правило, заказчики стремятся автоматизировать какой-то отдельный участок, например: "нам надо автоматизировать бухгалтерию", "надо создать систему бюджетирования" или "мы консолидированную отчетность не получаем вовремя, надо эту проблему решить". И консультанту приходится сначала разбираться, что неправильно организовано в бизнес-процессах, находить и устранять причину проблемы. Но нередко эту проблему вообще невозможно решить одним проектом. Можно построить, скажем, систему бюджетирования, и система будет работать, однако для того чтобы получить от нее реальный эффект, на "входе" в систему должна поступать актуальная и достоверная информация. И получается, что консультанты стараются, внедряют какую-то систему, а заказчик потом спрашивает: "Ну внедрили мы систему, и какой от нее прок?"
Таким образом, надлежащий эффект от информатизации крупных компаний получается лишь при комплексном подходе. И с этой точки зрения руководители ФСК поставили задачу совершенно верно: надо выделить так называемый приоритетный комплекс проблем (невозможно параллельно решать сразу все вопросы автоматизации) и двигаться от ИТ-поддержки основных бизнес-процессов к автоматизации вспомогательных процессов, внедряя комплекс соответствующих систем. Понятно, что это уже ведет не к одному проекту, а к программе, то есть набору согласованных проектов.
Что касается стремления ФСК отдать создание и обслуживание систем в аутсорсинг, то эта идея сама по себе, на мой взгляд, очень здравая. Да, она сложная и для России нехарактерная. К сожалению, ситуация с аутсорсингом в нашей стране сильно отличается от западной. Во-первых, здесь пока большого спроса на такие услуги нет и, как следствие, предложение очень ограничено. Во-вторых, можно на аутсорсинговых началах создать систему, однако надо правильно управлять этим процессом. Нельзя все отдать на аутсорсинг, заплатить и потом только читать отчеты исполнителей. Необходимо управлять ими.
Но если мы постоянно говорим о важности правильного управления проектом, то для программы важность управления программой как со стороны исполнителя, так и со стороны заказчика возрастает многократно…
Да, это одна из главных проблем программ проектов. Методология управления программами достаточно сложна. Если в проекте, как правило, используется одно "главное" приложение, то в программе этих приложений несколько. Например, ситуация в ФСК по-своему уникальна - там внедряются сразу две ERP-системы (IFS и SAP R/3). Существует практика, когда разные системы внедряются на разных "уровнях" (например, в ряде случаев на заводе хорошо использовать систему Baan, она и дешевле, и легче внедряется, чем SAP и Oracle, а "сверху", на уровне управляющей компании, ставится другая ERP-система, которая поддерживает свой комплекс задач, в основном финансовых). Но в ФСК ситуация сложнее - основные бизнес-процессы, связанные с ремонтом и обслуживанием сетевой инфраструктуры, здесь будет поддерживать IFS, а система SAP R/3 должна закрывать все остальные функциональные задачи.
Это достаточно сложное решение, и отношение к нему до сих пор неоднозначное. С одной стороны, теоретически развивать "зоопарк систем" неправильно. С другой стороны, существует подход "best of breed", когда выбираются лучшие в своей области решения, которые потом интегрируются. Еще года 2-3 назад аналитики Gartner писали, что интеграционные платформы развиваются с огромной скоростью, что за этим будущее, поэтому выбирайте лучшее и интегрируйте. Однако сегодня выяснилось, что задачи интеграции могут оказаться гораздо сложнее, чем выбор и внедрение одной системы и решение на ее основе всех основных задач. Поэтому на сегодняшний день однозначного решения, какой подход предпочтительнее, не существует. Поставленная в ФСК задача, с одной стороны, сложная и очень интересная, но с другой стороны - определяет появление дополнительных сложностей в управлении программой таких проектов.
При этом грамотное управление проектом со стороны исполнителя еще не является залогом успеха. Я вообще не могу сказать, что наша методика управления проектом является чем-то уникальным, хотя многие заказчики почему-то считают иначе (так, один крупный заказчик потребовал, чтобы мы изложили методику, в соответствии с которой управляем проектами, как будто каждый исполнитель обладает собственной такой методикой). На самом деле существует теория, общепринятая методология управления проектами, которой мы все следуем, внося небольшие нюансы, в зависимости от типа проекта и конкретной ситуации. А вот что гораздо важнее - это наличие у заказчика сильной службы, способной управлять такими программами проектов.
Руководитель службы заказчика должен служить интерфейсом между руководством компании и поставщиком ИТ-услуг, должен грамотно транслировать потоки информации в ту и в другую сторону. Не является ли статус генерального системного интегратора попыткой заменить слабость такого менеджера в компании-заказчике?
Нет, это невозможно. Внешний контроль не может заменить наличие сильного менеджера в компании, поскольку ответственность за принятие решения целиком лежит на заказчике. Мы выступаем исключительно как консультанты. Причем в ФСК мы не имеем статуса генподрядчика, только статус генерального системного интегратора, то есть занимаемся фактически консалтинговыми функциями.
Тут стоит отметить, что в успехе любого ИТ-проекта техническая составляющая занимает, как правило, относительно небольшую долю (естественно, я имею в виду ситуацию, когда компания-исполнитель владеет "инструментом" и в состоянии предложить и реализовать адекватное решение). Оставшийся вклад в успех проекта вносят организационные и политические аспекты. На переговорах заказчики нередко цитируют мнение, что "90 % внедрений ERP завершились неуспешно", и это заставляет их сомневаться в целесообразности внедрения ERP-систем. При этом не учитывается, что очень часто заказчики тщательно выбирают сначала систему, потом команду, а оказывается, что все причины неуспеха лежат дальше - в плохой организации проекта, причем в основном со стороны заказчика. Нет, я не стремлюсь преуменьшить проблемы, возникающие по вине исполнителя. Многие проблемы сегодняшнего рынка ERP-систем связаны с отсутствием должного опыта. ERP-системы невозможно просто купить, изучить и затем без проблем поставлять в компании. Даже после обучения консультанты не обладают достаточным опытом, опыт приходит только при выполнении реальных проектов. Но большая часть неудачных проектов, действительно, связана с проблемами управления проектом со стороны заказчика. И в нашей практике были такого рода неудачи.
Поэтому для успеха необходимы два условия. Первое - чтобы в компании-заказчике был менеджер с опытом управления проектом или хотя бы соответствующими навыками. Он должен понимать, как управляется проект, какие этапы необходимо проходить и т.д. И второе - статус руководителя проекта со стороны заказчика должен быть высоким.
Какого уровня? Часто приходится слышать, что курировать проект должен генеральный директор…
Нет, это не обязательно должен быть генеральный директор или его заместитель, это нереально. Но руководитель проекта должен иметь возможность выходить на генерального директора и решать вопросы напрямую. Яркий пример такого подхода - компания "ЦВ Протек". Там сегодня работает функциональность Oracle E-Business Suite, которая в России была реализована впервые, и даже c мировых позиций этот проект по сложности является уникальным для компаний-фармдистрибьюторов. Статус ERP-проекта в "Протеке" очень высокий. Например, там каждую неделю проводится заседание управляющего комитета проекта, и 80% заседаний проходят с участием генерального директора компании. При этом генеральный директор не руководит проектом непосредственно, скорее его присутствие является проявлением политической воли руководства, что способствует успеху.
Конечно, отнюдь не во всех компаниях такое возможно. Но авторитет, политический вес руководителя проекта в организации должны быть, безусловно, высокими. И при этом руководитель должен разбираться в управлении проектами, понимать, как устроен процесс внедрения (либо иметь знающего сотрудника, который, в свою очередь, является для руководителя безусловным авторитетом в этом вопросе). Консультант и заказчик должны говорить на одном языке, хотя бы с точки зрения организации работ.
Кстати, не обязательно владеть именно западными методологиями и стандартами. Сейчас на предприятиях очень ценятся специалисты, которые прошли школу советских ГОСТов в этой области. Внедрение АСУ в советское время по сути не отличалось от сегодняшних проектов автоматизации. Методологиям можно давать какие угодно названия, суть от этого не меняется. Конечно, раньше существовали административные рычаги, планы, а сегодня этого нет. С другой стороны, раньше был большой ресурс времени, а сегодня рынок меняется настолько быстро, что фактор времени стал играть важную роль. Получается, что сегодня та же самая задача решается в условиях жесточайшего ограничения временных и финансовых ресурсов. Но суть задачи не изменилась.
В каких случаях для заказчика логично идти по пути выбора генерального подрядчика и субподрядчиков, а в каких cлучаях организовывать проектную программу с генеральным системным интегратором в качестве консультанта?
Вопрос, стоит ли выбрать генерального подрядчика или привлечь генерального системного интегратора - очень сложный. Генеральный подрядчик отвечает за все работы по созданию информационной системы, а генеральный системный интегратор - только за автоматизацию ключевых процессов и внедрение ключевых приложений. При отсутствии генерального подрядчика компании-подрядчики управляются контрактами с самим заказчиком, и единая точка контроля оказывается у руководителя проектного офиса заказчика. Но в этой ситуации требуется серьезное руководство проектным офисом, нужна сильная проектная группа на стороне заказчика. Например, в компании АВТОВАЗ, где TopS BI также имеет формальный статус генерального системного интегратора, очень сильная собственная ИТ-служба, достаточно хорошая производственная система собственной разработки, много грамотных разработчиков, и существенная часть вопросов автоматизации там уже закрыта.
В случае выбора генерального подрядчика, он сам управляет субподрядчиками, а это в сервисном бизнесе - довольно сложная и специфическая работа, поскольку у субподрядчиков разная культура, разная скорость работы. И риски по консультационным проектам ложатся тоже на Генерального подрядчика. Кстати, далеко не каждая компания, работающая на рынке ИТ-консалтинга, возьмется за генеральный подряд, поскольку это, вообще говоря, материальная ответственность. С другой стороны, при выборе генерального подрядчика возникает риск, связанный с тем, что все "сходится" в одной точке. При возникновении внутренних проблем у генерального подрядчика заказчик рискует всем проектом информатизации, в который вложены существенные средства и ресурсы. Кроме того, есть опасность, что генеральный подрядчик решит все работы выполнить самостоятельно: поставить оборудование, внедрить все системы и т. д. Но не существует компании, которая одинаково хорошо владела бы всеми аспектами создания информационной системы, поэтому неизбежно возникает риск, связанный с качеством работ.
На мой взгляд, правильный путь сегодня - выбрать не генерального подрядчика, а генерального системного интегратора, но обязательно с привлечением внешнего аудитора проектов. Очевидно, что для российских условий генеральный подряд на построение информационной системы - это пока экзотика, вопросы генподряда и субподряда на ИТ-проектах пока сложны для нашего рынка. Поэтому в качестве временной альтернативы я считаю целесообразной связку "генеральный системный интегратор - аудитор". Таким образом обеспечивается устойчивость ситуации. Например, в крупном ИТ-проекте внедрения Oracle E-Business Suite в холдинге "Связьинвест" изначально была построена такая же модель: генеральный системный интегратор ("Открытые Технологии") и генеральный консультант (Accenture). Правда, потом там ситуация изменилась, и "Открытые Технологии" взяли на себя функции генерального подрядчика.
Генеральный системный интегратор является носителем знаний, поставщиком услуг, он берет на себя ключевые аспекты проекта, начиная с методологии управления программой проектов. Фактически заказчик не обязан сам вырабатывать инструкции по созданию проектного офиса, но он должен контролировать этот процесс. Внешний аудитор и представляет интересы заказчика. Это нормальная практика, выгодная и заказчику, и исполнителю. Например, мы предпочитаем, чтобы наши крупные ERP-проекты подвергались стороннему аудиту, прежде всего, со стороны вендора как первого носителя информации. Если аудит проводит конкурирующая ИТ-компания, то возможны сомнения в ее искренности. В случае вендора эти сомнения отпадают. И хотя аудит от вендора - достаточно формальная процедура, в рамках которой проверяется соответствие проектной методике, он все равно полезен.
Замечу, что некоторые крупные российские компании сегодня идут по другому пути - они не выбирают генерального системного интегратора, а объявляют конкурс на каждую задачу. На мой взгляд, это очень сомнительный подход. Мало того, что невозможно выработать нормальные партнерские отношения - консультантам нет смысла глубоко "погружаться" в проблемы предприятия, так как они понимают, что завтра их здесь уже может и не быть.
С чего разумно начинать работу с потенциальным генеральным системным интегратором?
Если бы я был на месте директора компании-заказчика, я бы начинал с ИТ-стратегии, как ни пафосно это звучит. Пусть для начала привлеченные ИТ-консультанты проведут аудит проблем информатизации, которые стоят перед компанией. Я бы не поручал разработку ИТ-стратегии внутреннему менеджеру, а нанял для этого внешних консультантов, которые в интерактивном режиме, вместе с менеджерами предприятия создали бы ИТ-стратегию. Интерактивный режим (в стиле "вопрос-ответ") здесь принципиально важен: когда внешний консультант приносит полностью готовый "том" ИТ-стратегии, менеджерам заказчика очень трудно понять, корректно ли она разработана, сыграет ли она свою роль или нет. К слову, в TopS BI очень часто обращаются крупные предприятия с задачей провести аудит существующей у них ИТ-инфраструктуры и предложить решение по ее развитию. Да, часто такой аудит не перерастает в проекты, но подход этих предприятий, несомненно, правильный.
После разработки ИТ-стратегии я бы выбирал генерального системного интегратора и аудитора проектов. На мой взгляд, крупному предприятию целесообразно идти именно по этому пути. Тогда при наличии квалифицированного менеджера, управляющего проектом или программой со стороны заказчика, создается устойчивый треугольник. Причем на роль управляющего ИТ-менеджера лучше брать именно того специалиста, с которым в интерактивном режиме разрабатывалась ИТ-стратегия. Ну и при хорошем стечении обстоятельств ИТ-консультант, который помогал разрабатывать ИТ-стратегию, должен стать генеральным системным интегратором.
Как делать выбор такого потенциального генерального системного интегратора?
А как выбирать себе врача? Ведь не по диплому же… Скорее всего - по совету знакомого. Тут аналогичная ситуация, ИТ-консультанты чем-то похожи на врачей. Поэтому мы так заботимся о своем имидже, стараемся избавиться от сотрудников, которые не нравятся заказчикам, меняем руководителей и консультантов проектов.
Можно сказать, что формальным признаком "хорошего ИТ-врача" являются успешно реализованные проекты. Тем не менее, на мой взгляд, самый правильный путь при выборе компании-консультанта - это общение с претендентами, проведение презентаций, получение личных впечатлений от консультантов той или иной компании. Целесообразно также понять, как консультанты видят перспективы проекта, что бы они посоветовали делать в дальнейшем, после реализации запланированного объема работ. Мне кажется, заказчику правильнее организовать две-три таких презентации, потратить время на личное общение, чем просто сличить формальные опросники и тендерные документы. Опросники работают при выборе поставщика техники, но не при выборе ИТ-консультанта.
Ведь в чем здесь проблема: мы гарантируем соблюдение параметров проекта, закрепленных в контракте, но проект выполняет конкретный руководитель. И если он уйдет из компании, проект, вне всякого сомнения, станет другим. И в этом есть огромные риски для заказчика. Поэтому во многих контрактах у нас записано, что заказчик не имеет права снимать консультантов с проекта без согласования с нами. С другой стороны, заказчики часто просят на проект конкретного консультанта и даже ставят конкретную кандидатуру руководителя проекта условием заключения контракта с нами. И я понимаю почему - это уменьшает риски проекта.
