Заказчики: Нафтогаз Украины НАК Подрядчики: SI BIS Дата проекта: 2010/12
|
Ляшенко Александр, директор департамента информационных ресурсов и технологий НАК «Нефтегаз Украины»:
Какие требования к подрядчикам по ИТ-проектам сформированы у НАК «Нефтегаз Украины»?
В первую очередь, это наличие соответствующего опыта реализации проектов и высокий уровень компетенции сотрудников. Также очень важно умение и желание подрядчика выбрать оптимальное для нас техническое решение с точки зрения экономики, функциональности и надежности. Большую роль играет репутация компании на рынке, способность в полной мере выполнять взятые на себя обязательства. В наше время надежность партнера – это один из ключевых факторов ведения успешного бизнеса. Помимо этого, всегда легче и приятнее работать с компанией, которая обладает гибкостью. Также важна способность партнера идти на компромисс и не подходить к своим обязательствам только с формальной стороны. В проектах часто всплывают необозначенные на старте проблемы, которые, так или иначе, нужно решать. Именно в таких случаях успешность проекта зависит от гибкости компании и ее способности адаптироваться под новые условия.
Мы сотрудничаем с компаниями, которые работают на рынке не один день, а наш опыт позволяет иметь неплохое представление обо всех участниках этого рынка и их возможностях. Если говорить о специфических профильных проектах, то мы можем не знать в полном объеме всю информацию о компетенциях компании в этой области. В таком случае, мы проводим детальный анализ и смотрим на выполнение реальных проектов теми сотрудниками, которые есть в компании. Может быть ситуация, когда компания в прошлом выполняла ряд громких и успешных проектов в определенной сфере, но та команда уже разошлась. Формально компания обладает опытом выполнения таких проектов, но реально его делать некому. Обратная ситуация тоже возможна: неизвестная молодая компания может обладать блестящей командой исполнителей, которые как нельзя лучше реализуют проект. Мы всегда оцениваем технологическую состоятельность выполнения проекта и, в зависимости от конкретной ситуации, можем отдать предпочтение молодой перспективной команде.
Начало сотрудничества с компанией SI BIS: какие факторы стали ключевыми при выборе интегратора?
«Нефтегаз Украины» - государственная компания, у которой есть определенные, установленные законом требования к выбору контрагента. Поэтому мы не можем выбрать подрядчика только потому, что мы с ним друг другу симпатизируем, а должны это делать исключительно по объективным причинам. Все вышеописанные критерии отбора ложатся в конкурсную документацию в виде квалификационных и прочих требований ко всем участникам. Та компания, которая наилучшим образом соответствует всем требованиям конкурса, становится подрядчиком в проекте. Все просто и прозрачно.
В результате открытых торгов по внедрению системы Service Desk среди всех претендентов компания SI BIS предложила самое интересное и выгодное решение, поэтому мы пришли к фактическому заключению договора.Работа с артефактами разработки: каким отечественным инструментом заменить Sonatype Nexus и JFrog Artifactory
Имея необходимую информация о профессионализме компании, ее опыте выполнения сложных проектов, наличии компетенций, а также гибкости и мобильности, у нас не было оснований сомневаться в успешной реализации проекта
Когда было принято решение об организации службы поддержки пользователей, какие были предпосылки и задачи?
Наш портфель проектов не возникает просто так под бюджет. В прошлом году была сформулирована роль ИТ в нашей компании и ее основные функции. Задача департамента информационных ресурсов и технологий в НАК «Нефтегаз Украины» заключается в обеспечении деятельности и развития компании, предоставляя ИТ-услуги высокого качества на основе передовых технологий. Мы также определили основные направления деятельности, с помощью которых планируем выполнять эту задачу. Среди этих направлений: оптимизация ИТ-процессов, внедрение автоматизированных систем и бизнес-приложений, а также обновление ИТ-инфраструктуры. В рамках каждого из этих направлений формировался определенный портфель проектов. Т.е. выполнялась декомпозиция роли ИТ в направления деятельности, в каждом из которых выделялись основные цели и задачи, исходя из которых, в свою очередь, формировались проекты. Именно такая схема утверждена и работает в нашей компании. Проект по внедрению Service Desk возник из необходимости формализации ИТ-услуг и функции поддержки нашей ИТ-инфраструктуры. Было принято решение о внедрении инструментов, которые позволяют эффективно управлять этими процессами. Проект стал комплексным, поскольку нам было необходимо произвести постановку всех процессов, чтобы они происходили не ситуативно, а системно, а также обеспечить работу инструментов, выполняющих поддержку и управление процессами. Таким образом, как результат этих целей и задач, появился проект по внедрению Service Desk. Мы определяли платформу этого решения, присматриваясь к продуктам от разных поставщиков. Важным фактором в этом выборе были не только возможности продуктов, а и наличие локальной компетентной команды, способной в сжатые сроки обеспечить необходимый результат. Нашей целью было не просто получить программный продукт, который мы будем бесконечно дорабатывать, а запустить решение, способное сразу выполнять все наши задачи.
В рамках проекта происходило обследование и постановка процессов. Работа была двусторонняя: с одной стороны нужно было учитывать особенности оргструктуры, штатного расписания, отраслевых нюансов ведения бизнеса компании; а с другой – придерживаться общей практики, которая описывает стандартные положения. Была разработана методологическая база, которую мы дополнили нашими специфическими требованиями.
Как проходил процесс реализации проекта: этапы, сроки, непредвиденные обстоятельства?
Первым этапом было проведено обследование нашей ИТ-инфраструктуры и соответствующих процессов. После этого последовала разработка технического задания, архитектуры системы с точки зрения программной и процессной среды. Затем компания SI BIS произвела установку базовой конфигурации и последующую ее настройку в соответствии с техническим заданием, после которой состоялось внесение первичной информации, тестирование и ввод системы в промышленную эксплуатацию.
Сначала система тестировалась непосредственно в проектной группе, а на первых этапах ввода в эксплуатацию мы задействовали ресурсы ИТ-департамента, который проводил работу в старой системе и дублировал ее в новой. На этом этапе все пользователи продолжали работать в старой фронт-системе. При этом, конечно, возросла нагрузка на операторов, поскольку они дублировали все обращения в Service Desk. Около двух недель сотрудники департамента ИТ работали в тестовом режиме для поиска ошибок в системе и адаптации к условиям работы в новой системе. Это позволило безболезненно пережить изменения в оперативной деятельности и быстро привыкнуть к выполнению формальных процедур: регистрации инцидентов и заявок, отметки хода исполнения, описание и закрытие заявок и т.д.
Также проводилось обучение пользователей работе в Service Desk. По истечению периода тестирования мы отключили фронт-систему, и весь персонал уже был готов работать в новой системе. Реализация всего проекта до полного ввода в эксплуатацию заняла полгода.
Что касается непредвиденных обстоятельств, то в любом проекте всегда возникают некоторые непредвиденные сложности, поскольку на этапе планирования есть только цели и задачи, и формируются некоторые допущения и ограничения. Но когда дело доходит уже до реализации конкретного процесса, возникает множество нюансов, как организационных, так и технологических. Очень часто в таких ситуациях приходится идти на компромисс. Для этого нужно уметь найти компромиссное решение и быть готовым принять его.
Именно здесь всплывает способность исполнителя быть гибким, ведь с точки зрения методологии все может быть верно, но с точки зрения реального использования системы, работа может быть неудобной и не эффективной. Помимо этого, часто возникают проблемы, связанные исключительно с технологическим циклом – например, банальная процедура многослойного наката патчей может ввести систему в нестабильное состояние. В таком случае приходится открывать кейсы вендоров для точного определения причины некорректной работы системы или ее отказа. В гетерогенных инфраструктурах могут возникать кроссплатформенные ошибки. В этом случае искать причину нужно не в работе отдельных систем, а в их совместимости. Все это может значительно задержать оперативное внедрение системы.
Но, в данном проекте, компанией SI BIS были выдержаны все сроки мастер-плана, несмотря на некоторые перепланировки. В нашем случае это было очень важно, поскольку требование по срокам было одним из основных при выборе исполнителя. Конечный срок выполнения проекта не мог отодвигаться ни при каких условиях. Более того, после составления договора, мастер-плана, и устава проекта, и даже после начала работ несколько изменились приоритеты в компании с точки зрения портфеля проектов. По окончанию этого проекта нужно было начинать ряд новых, поэтому пришлось несколько урезать сроки реализации службы поддержки Service Desk. Исполнителю в лице SI BIS было выдвинуто условие о том, что проект нужно сдать на месяц раньше, не смотря на то, что изначальные сроки были довольно жесткими. Это требование было соблюдено, и мы сдали проект раньше первичного плана.
Какой результат имеется на сегодняшний день? Какие процессы по этому проекту должны быть выполнены в будущем?
На данный момент мы полностью запустили управление запросами на обслуживание, управление проблемами и управление активами. Идет донастройка процессов управления конфигурациями, изменениями и уровнями услуг. На этом пилотный проект будет завершен окончательно. Есть определенное видение развития этого проекта в будущем, но мы хотим завершить все существующие процессы для более четкого формирования наших требований. Для этого, мы сознательно возьмем тайм-аут на три-четыре месяца, поскольку мышление человека не дискретно, и оно не может меняться моментально – это непрерывный процесс. По мере выполнения этого проекта у наших людей менялось представление о работе, их подход к выполнению повседневных задач. Пауза необходима для того, чтобы люди могли в спокойном режиме доосмыслить новые процессы, выйти за рамки своих стереотипов и сознательно принять новые возможности. Большинство людей не любит изменений и неизвестности, поэтому нужно помочь им свыкнуться, принять изменения и избавиться от неизвестности методом получения новых знаний.
Какого результата можно добиться благодаря внедрению управления активами?
Управление активами — это в первую очередь, наведение порядка в инфраструктуре, четкое понимание имеющихся ресурсов и аналитика своих возможностей в автоматическом режиме, без привлечения человеческих ресурсов. Иногда очень важно моментально получить информацию по детальному запросу. Благодаря этому, значительно упрощается процесс принятия решений, планирование мощностей, бюджета и модернизации. Также это помогает избежать узких мест в инфраструктуре при внедрении новых информационных систем. Управление активами позволяет иметь всевозможную характеристику всех имеющихся на предприятии ресурсов и постоянно анализировать их состояние. Помимо этого, есть проблема переездов офисов и перемещения оборудования. Управление активами позволяет оперативно провести инвентаризацию, навести порядок на новом месте и поднять историю о том, где что стояло на прежних площадях. Это очень разгружает ИТ-персонал и избавляет их от множества рутинной бумажной работы, благодаря чему он лучше фокусируется на своих непосредственных функциях. В связи с переездом отдел ИТ может выпасть из основной оперативной деятельности на месяц и более, что приводит к существенным потерям для организации. Управление активами в значительной мере помогает избавиться от этих потерь. Для ИТ-директора выполнение оркестровки всей инфраструктуры таким удобным образом снимает всю головную боль и освобождает рабочие часы для решения других задач.
Беседовал Денис Кривов, ITPartner