|
|
  |
Главная страница / Архитектура отрасли «В СВЯЗКЕ ОДНОЙ...»Говорят, что самая высокая ступень, на которую может подняться системный интегратор, – это обретение статуса «доверенного советника». Так уж получилось, что, начав исследование темы, мы обратились сначала к компаниям-интеграторам, которые «переключили» на себя фокус данного материала. Таким образом, сегодняшний разговор будет посвящен среднему (читай – центральному) звену обозначенной цепочки. В наших следующих публикациях мы расскажем об остальных участниках «трио». Схема взаимодействия №1: типичный проект Представим себе то, что обозначено в названии нашего материала: есть поставщик (вендор), есть заказчик, который хочет получать услуги, и есть системный интегратор. Последний исполняет функции некоего медиума в том случае, если заказчику требуется решение не от одного поставщика, а от нескольких. Одной из задач интегратора является выбор решения из всего существующего многообразия и дальнейшая его интеграция в инфраструктуру заказчика. Если изобразить возникшую цепочку схематически, то получится достаточно универсальная модель (рис. 1). Именно в диалоге поставщика и системного интегратора и проявляется их отличие: поставщик кровно заинтересован в своих продуктах, тогда как интегратор трудится на заказчика. Поставщику, безусловно, важен конечный результат, но он всегда будет считать, что только с помощью его продукта заказчик получит то, что ему требуется, в самом лучшем виде. А задача выбрать правильное решение ложится на плечи интегратора и самого заказчика. Здесь возникает ряд очень важных проблем, решение которых зависит от четкости сформулированных заказчиком требований, от его понимания бизнес-ожиданий, а также от взаимоотношений клиента и интегратора. В России уже сейчас используется классический западный подход: большинство проектов начинается с аудита и постановки бизнес-задачи, потом разрабатывается бизнес-стратегия, осуществляется выбор определенного решения и реализуется IT-задача, которая должна соответствовать стратегической цели, а не быть «вещью в себе». Приведем один пример. Проект начался с аудита инфраструктуры заказчика и анализа ее дальнейшего развития. Следующий этап – формулирование задачи по выбору аппаратной платформы и инфраструктурной части. Был проведен тендер между поставщиками/вендорами (между IBM, SUN и Hewlett-Packard), в процессе которого фирма-интегратор помогала заказчику выбрать оптимальное решение. Затем последовала реализация проекта. В настоящее время фирма-клиент запросила аудит по результатам внедрения и изъявила желание обзавестись автоматизированной системой управления предприятием (АСУП) для упорядочения финансово-хозяйственной деятельности. Под описываемую модель (рис. 1) подходят как обычные поставки (например, заказчик выбирает модели компьютеров), так и более сложные. Если продолжить разговор о выборе АСУП, то и здесь одной из основных трудностей, с которой приходится сталкиваться заказчикуто предлагаемые на рынке АСУП различаются маркетингом, который, к сожалению, тоже не решает всех проблем. У этих систем, если можно так выразиться, существуют «глубинные» отличия в их предназначении. Одни системы больше подходят для непрерывного бизнеса, другие – для дискретного, в сервисных компаниях своя, отличающаяся от первых двух схема бизнес-процессов и т. д. Для выбора оптимального решения имеется достаточно много критериев и методик, каждая из них является ноу-хау («секретом фирмы») компании-интегратора. Схема взаимодействия № 2: уникальный проект Помимо автоматизации основных бизнес-процессов существует еще один уровень управления предприятием – управление инфраструктурой и сервисами. Присутствующие в данном секторе продукты и предметные области тоже достаточно многообразны: управление сетевой инфраструктурой, серверами, базами данных, системами хранения данных. Верхняя ступень – системы управления сервисами, управление приложениями. Рассмотрим решение этой задачи на достаточно показательном примере телекоммуникационной отрасли, поскольку бизнес-процессы операторов связи обладают определенной спецификой. Для телекомов их инфраструктура фактически и есть бизнес. Каждая компания, поставляющая телекоммуникационное оборудование, создает для него собственную систему управления. Пирамида интеграционного проекта и термоядерный взрыв Понимание роли IT в бизнесе зависит от зрелости и бизнеса, и самих технологий. Это оказывает непосредственное влияние и на степень сложности проектов. Конечно, встретить профессионала, имеющего богатый опыт использования для бизнеса IT-инструментов, всегда приятно. Это позволяет реализовать бизнес-цели заказчика максимально эффективно. Как справедливо отмечено, в интеграционном проекте есть три составляющих – поставщик, системный интегратор и заказчик. Поставщик кровно заинтересован в решении задачи, ведь это показатель востребованности его решений, возможность их продвижения и его репутация. Для системного интегратора нерешение задач заказчика IT-средствами противоречит самой сути его существования, это его основная функция. Интерес заказчика также очевиден. Все вместе они работают над проектом, ищут оптимальное решение. Зная лучше, чем производитель, бизнес заказчика, его требования и нужды, системный интегратор выступает для заказчика в качестве «единой точки входа», которая, с одной стороны, решает проблемы, привлекает необходимые ресурсы – партнеров, поставщиков, с другой – берет на себя все риски, связанные с реализацией IT-проекта. Серьезных заказчиков это привлекает. Полный аудит, в том числе и информационной инфраструктуры, должен осуществляться лишь после определения бизнес- задачи организации. При нечетко сформулированной цели проводить аудит инфраструктуры не имеет смысла. Ведь аудит – это проверка состояния, некое сравнение для выяснения «дельты» между тем, что должно . бизнес-цель. Это необходимо для установления того, насколько исследуемая инфраструктура (программно-аппаратная, телекоммуникационная и др.) отвечает сформулированным требованиям. Затем вырабатывается алгоритм решения бизнес-задач средствами IT в целом и с разбивкой на отдельные составные части. Решение бизнес-задач в первую очередь ложится на программные бизнес-приложения (АСУП). Аппаратная инфраструктура сама по себе ничего не решает, она лишь обеспечивает функционирование определенных бизнес-приложений. Развитие пирамиды интеграционного проекта идет соответственно: бизнес-задача, IT-задача, приложения и инфраструктура, которая обеспечивает работоспособность этих приложений. Квалификация специалистов наращивается по-разному. Случается, что при реализации сложных, уникальных проектов необходимо объединение знаний и опыта системного интегратора и производителя. От такого сотрудничества выигрывают все – производитель получает возможность попрактиковаться в «боевых» условиях, глубже понять требования потребителя. Системный интегратор повышает свою квалификацию, профессионально растет. Создавать «в домашних условиях» «термоядерный взрыв», разумеется, не стоит, особенно если это можно сделать на полигоне производителя. Для специалистов вендора подобное общение тоже полезно – оно позволяет им более оперативно реагировать на ожидания рынка. Так что это не одностороннее движение, а двустороннее взаимодействие. Владимир Кириллов, директор по маркетингу, технический эксперт компании КРОК Многие операторы имеют несколько поставщиков, в связи с чем им необходима интегрированная, обобщающая система, на которой можно было бы построить некую общую панель для управления. Продукты такого класса имеются, но беда в том, что интеграторов такого уровня, способных самостоятельно поднять эту систему и выполнить задачу, практически нет. Здесь можно работать только в связке с поставщиком/вендором, чье оборудование поставляется. Обычно заказчик так и поступает, потому что слишком много ресурсов поставщика решений должно использоваться для построения этой системы. По опыту одной из компаний-интеграторов, поставщики в подобных ситуациях не могут «отчуждать» знания, полученные в ходе проекта, поскольку каждая инсталляция уникальна (впрочем, на этот счет есть другое мнение, см. В. Кириллов, «Пирамида интеграционного проекта...»). Иными словами, после таких проектов нельзя написать единый «рецепт» на все случаи жизни, ведь модели получаются совершенно разные. Тем не менее здесь не обойтись без участия интеграторов, потому что одно дело – первоначальная настройка, другое – последующая поддержка системы: внедренную систему необходимо развивать и интегрировать с уже существующими системами управления. Модели взаимодействия могут быть самые разные, и наша картинка обретает новые черты (рис. 2). Третья модель реализуется, когда системный интегратор напрямую представамостоятельно поддержку и ведет работу с заказчиком. Но на ней мы останавливаться не будем, поскольку она является вариантом схемы №1. Где взять полигон? Как можно понять из всего вышесказанного, в интеграционных проектах очень важны степень участия поставщика и заказчика, а также размер и уникальность бизнеса последнего. В любом из описанных случаев знания поставщика, обретенные им во время реализации проекта, переходят к партнеру-интегратору. Поставщик понимает, что все сделать сам он не в состоянии и если осуществляемый проект на данной «территории» не единственный и планируется последующее развитие, то без партнеров не обойтись. Кроме того, заказчику, и это не секрет, легче и проще работать с местными партнерами, чем с зарубежными поставщиками, к тому же дешевле. Однако мы упомянули, что существуют уникальные решения, для реализации которых специалистов у нас пока нет. Продолжим рассмотрение «телекоммуникационного» примера. Инвестиции в обучение сотрудников и сила интегратора Для достижения высокого уровня проектов системный интегратор должен, с одной стороны, поощрять и способствовать профессиональному росту своих сотрудников, следовательно, вкладывать довольно значительные средства в их обучение, с другой – обеспечивать широкий выбор множества решений для заказчика от различных поставщиков. Например, развивая практику в области OSS/BSS систем, наша компания наряду с уже известными на российском рынке мировыми брендами использует и пока не очень известные в России, однако обладающие мощным потенциалом и зарекомендовавшие себя на мировом рынке. Реализация и поддержка столь широкого круга решений требуют высокой квалификации специалистов. Их обучение – весьма затратный и технологически сложный, но абсолютно оправданный подход, позволяющий достигать максимальных результатов, а значит – работать на бизнес и репутацию компании системного интегратора. Интегратор лучше, чем кто-либо, осознает уровень своих возможностей и никогда не возьмется за решение непосильной для себя задачи. Однако только он, а не заказчик сможет грамотно поставить задачу производителю и проконтролировать качество ее выполнения. Наверное, в этом и заключается одна из основных ролей интегратора – решать проблему заказчика, выступая от его имени в общении с субподрядчиками (в том числе производителями). Алена Сало, директор департамента системных решений IBS Стоимость системы управления инфраструктурой составляет примерно 1 млн долл. Естественно, заказчиков, готовых отдать такие деньги, не так много. В этом случае перед интегратором (партнером поставщика) встает вопрос: вкладывать деньги в обучение специалиста, которое обойдется в 50 тыс. долл., или нет? Ведь подготовленный специалист должен где-то «тренироваться», инсталлировать подобные системы, осуществлять окончательную доводку продуктаму что ни один интегратор не может себе позволить обустройство «полигона» с огромным количеством коммутаторов от разных поставщиков, и экспериментировать с ними. Это можно делать только у заказчика. Безусловно, если таковых – считанные единицы, а цена вопроса очень велика и на кон поставлена репутация, поставщик предпочтет работать напрямую. В данном случае вероятность вовлечения или передача проекта полностью в руки партнера-интегратора крайне мала. И тогда ситуация становится упрощенной до предела (рис. 3). С этой точки зрения интересно посмотреть на эволюцию компании SAP в России и СНГ. Сначала компания занималась внедрением только через представительство, без привлечения партнеров. Внедрения были считанными, система – очень дорогой. По мере увеличения количества инсталляций уровень квалификации российских специалистов, принимавших участие в проектах, значительно возрос. Более того, сформированные на предприятии в период таких внедрений команды по окончании проекта и введению системы в эксплуатацию покинули предприятие, поскольку приобрели востребованную рынком квалификацию интеграторов. Это привело к тому, что сейчас на рынке довольно значительное предложение квалифицированных ресурсов, которые могут заниматься внедрением систем класса ERP, например продуктов этой фирмы. Так что теперь значительная часть проектов отдана российским фирмам-интеграторам, выросшим, в частности, на таких проектах, чьи услуги сделали подобные системы более доступными для предприятий, и количество инсталляций вполне закономерно возросло. *** Говорят, что самая высокая ступень, на которую может подняться системный интегратор, – обретение статуса «доверенного советника». Оборотной стороной подобного признания высокой квалификации внедренца является мнение, что системный интегратор – это некая сила, способная сделать все: от приторачивания кабель-каналов до перестройки и формализации бизнес-процессов. Такое мнение не случайно. Приходится признать, что у нас пока нет четкого разделения труда в области оснащения предприятий IT-инфраструктурой, поскольку предпроектные обследования, реинжиниринг и формализация бизнес-процессов – прерогатива консультантов, тогда как на долю внедренца приходится аппаратная часть проекта и установка программного обеспечения, которые в свою очередь поставляют дистрибьюторы компаний-производителей. Нередко все эти функции совмещают в себе компании-интеграторы. Теоретически цепочка участников может быть сколь угодно сложной, но в любом случае, как заявили все компании-интеграторы, во главу угла ставятся интересы заказчика. Мы надеемся в следующих материалах продолжить исследование методологии интеграционных проектов и выяснить, каким образом достигаются цели всех участников этого действа. Материал подготовила Ольга Белова Главная страница / Архитектура отрасли |