1. Направления ИТ-аутсорсинга
Классифицировать основные направления ИТ-аутсорсингаможно по степени полноты процессов, передаваемых на исполнение другой компании.
Аутсорсинг отдельных ИТ-систем — классический вид аутсорсинга ИТ-услуг. В этом случае все работы по внедрению и поддержке отдельных систем (ERP, CRM и др.) выполняются внешним подрядчиком. При этом ИТ-услуги, относящиеся к другим системам, осуществляются собственными силами ИТ-подразделения компании. Этот вид аутсорсинга применяется в большинстве крупных и средних компаний, использующих типовое ПО корпоративного уровня (системы ERP, CRM, системы документооборота). В случае хорошо развитого ИТ-отдела данный вариант может являться переходным ко второму.
ü Частичный аутсорсинг ИТ-систем
Данный вариант напоминает предыдущий, но на аутсорсинг передаются не все ИТ-процессы, связанные с информационной системой, а только некоторые из них. Например, внедрение системы производится силами внешнего подрядчика, а ее сопровождение — собственными силами. Другой пример: поддержка системы осуществляется собственными силами, а ее развитие — силами внешнего подрядчика. Этот вариант применяется, если имеется хорошо развитый ИТ-отдел, выполняющий поддержку ПО собственной разработки и берущий на себя функции по поддержке покупных систем.
ü Аутсорсинг аппаратного обеспечения
Используется аппаратное обеспечение внешнего подрядчика и осуществляется аутсорсинг процесса поддержки этого оборудования. Этот вид аутсорсинга пока слабо распространен в России. Применяется, в частности, в некоторых компаниях, основанных западным капиталом.
ü Аутсорсинг отдельных процессов в рамках всей ИТ-инфраструктуры
От предыдущего вида отличается тем, что внешние подрядчики выполняют полный цикл отдельных процессов для всей ИТ-инфраструктуры компании. Например, «Сетевая печать», «Доступ в Интернет», «Средства коллективной работы». Применяется в некоторых малых и средних компаниях, где ИТ-стратегия не предусматривает расширения ИТ-отдела и фактор безопасности не является ключевым.
ü Полный аутсорсинг (нет собственных ИТ-специалистов в компании)
Максимально полный вариант предыдущего типа: собственного ИТ-отдела в компании нет, и все ИТ-функции выполняются внешними подрядчиками. Применяется в средних и небольших компаниях, где фактор безопасности не является ключевым.
2. Процедура проведения тендера на внедрение ИС
Процесс проведения тендера состоит из нескольких основных этапов:
6. Оформление результатов;
7. Заключение соглашения с победителем тендера.
1. Инициация проекта
Проект по проведению тендера начинается с определения и обоснования потребностей в новой информационной системе (системах) и определения рамок проекта. На предварительном этапе инициации проекта решаются организационные задачи назначения руководящей тендерной комиссии, участники которого должны будут управлять процессом проведения тендера; происходит мобилизация команды, производящей выбор победителя тендера; подготавливается и утверждается поэтапный план работ по проекту с разбивкой на сроки; готовится регламент проведения тендера.
2. Формирование «длинного списка» поставщиков (long list)
На этапе формирования «длинного списка» поставщиков рассматривается максимально широкий список решений, представленных на рынке. Предварительный отбор систем производится при минимизации затрат на получение дополнительной информации о решении. Т.е. при составлении «длинного списка» используют открытые источники информации, а также личный опыт участников проектной команды и рекомендации коллег, пользующихся доверием. Как правило, это веб-сайты вендоров, содержащие описание основных характеристик систем; обзоры в профессиональной прессе, презентации и демонстрационные ролики, руководства пользователей и т.д. Отбраковка решений из полного списка происходит на основании небольшого числа критичных критериев. Соответствие этим обязательным требованиям является основанием для внесения системы в «длинный список». При оформлении результатов этапа (самого Long List) полезно указывать не только системы, вошедшие в «длинный список», но и все рассматриваемые системы. Например, можно вынести перечень отбракованных решений в отдельный раздел документа. Важно не только перечислить их, но и указать причину исключения системы из рассмотрения — это позволяет вынести обоснованное решение и предупредит возможные вопросы со стороны руководства.
3. Формирование «короткого списка» поставщиков (short list)
Формирование «короткого списка» поставщиков производится из «длинного списка» на основании расширенного состава критериев выбора решения. На данном этапе требования к решению уточняются и систематизируются. Рекомендуется отдельно рассматривать требования к системе, поставщику и проекту.
Требования к системе подразделяют на:
ü Функциональные — перечень функций, которые должна поддерживать система;
ü Нефункциональные — требования к быстродействию, надежности, эксплуатации и обслуживанию системы, к эргономике, защите информации и т.д.;
Требования к поставщику подразделяют на две группы:
ü Общие показатели деятельности — например, требования к численности персонала компании-поставщика решения; время нахождения на рынке, финансовые показатели деятельности компании за отчетный период, отсутствие задолженности перед налоговыми органами;
ü Прочие требования — например, наличие сертифицированных специалистов, заключенные партнерские договора с вендорами, возможность предоставления определенного уровня поддержки, подход к ценообразованию.
Требования к проекту могут быть следующими:
ü Принципы организации проекта и управления проектом;
ü Требования к ресурсам, выделяемым на проект;
ü Сроки начала и завершения отдельных этапов проекта и проекта в целом;
ü Зависимость от критичных для бизнеса дат (дата сдачи отчетности);
ü Зависимость от других проектов;
После того, как требования к решению определены, следует разработать методику формирования «короткого списка» из «длинного» и отбраковать системы, не соответствующие требованиям в соответствии с разработанной методикой. В качестве примера возможных методик сравнения можно привести следующие:
ü Попарное сравнение систем;
ü Балльная оценка систем в с учетом веса каждого критерия выбора системы;
ü Приведенная стоимостная оценка решений, включающая финансовую оценку рисков;
ü Качественное сравнение решений на основе анализа реализации ключевых сценариев (key use cases);
ü TCO (Total Cost of Ownership);
Решения, не вошедшие в «короткий список», следует так же, как и на предыдущем этапе формирования «длинного списка», вынести в отдельный раздел, указав причину их «отбраковки».
4. Рассылка и обработка запросов на предоставление предложений
После того, как все требования к решению сформулированы и состав «короткого списка» определен, потенциальным участникам тендера (поставщикам, перечисленным в short list), высылается запрос на предоставление предложения. Разрабатывать его обычно начинают в самом начале проекта, а при получении из длинного списка короткого списка поставщиков, он может быть расширен дополнительной информацией.
Запрос может состоять из следующих основных блоков:
ü Выдержки из Регламента проведения тендера (основные сроки, правила и процедуры, контактные данные заказчика);
ü Требования к информации в предложении могут включать:
ü Правила заполнения предложения, которые указываются для удобства обработке предложений. Ответы потенциальных участников тендера должны описываться в единой форме для того, чтобы при обработки предложений построить единую таблицу сравнения ответов поставщиков;
ü Требования к участнику — требования, которым должен соответствовать поставщик решения, свидетельствующие о его «успешности», надежности, соответствии проекту;
ü Требования к системе — функциональные, нефункциональные требования, требования к информации о сроках, стоимости решения, истории и опыта ее внедрения;
ü Требования к прочим услугам, оказываемым в ходе проекта: требования к составу работ по проекту (внедрение системы, обучение сотрудников работе с системой, сопровождение).
5. Получение дополнительной информации в ходе презентаций, референс-визитов, консультаций
В ответ на запрос, поставщики высылают свои предложения, таким образом, становясь участниками тендера, и фактически с этого момента начинается собственно проведение тендера. Присланные предложения тщательно анализируются и после приведения их к единообразной форме сопоставляются, ответы поставщиков уточняются. Иногда после обработки предложений «короткий список» поставщиков удается сократить до 2–3 решений. Для оставшихся решений организуются презентации и тестовые демонстрации на территории поставщика или заказчика.
Целей у демонстраций и референс-визитов несколько:
ü Наглядно подтвердить свойства решений, которые заявлены в тендерных предложениях;
ü Подтвердить опыт конкретных проектов, также указанный в тендерных предложениях;
ü Продемонстрировать свойства решений, которые не могут быть оценены на основе предложений (например, юзабилити);
ü Оценить способность команды участника тендера к взаимодействию с заказчиком;
ü Оценить экспертизу команды участника тендера.
Для эффективного проведения презентаций рекомендуется разработать и предоставить участникам тендера единый план или несколько сценариев. Это позволит, во-первых, заставить их показывать то, что действительно интересно компании (а не только сильные стороны системы и поставщика), и, во-вторых, упростит сравнение результатов презентаций различных участников тендера.
6. Оформление результатов
После уточнения всех важных свойств решения, проведения сравнительного анализа систем и выбора победителя оформляется отчет о результатах тендера. В отчете могут быть отражены следующие виды анализа систем:
ü Качественная оценка решений предполагает сравнение систем с точки зрения их функциональности. По сути, качественная оценка является отчетом о проведенных демонстрациях систем;
ü Анализ рисков, сопряженных с выбором каждого решения. При оценке рисков должны учитываться вероятность наступления рисковой ситуации и стоимость расходов при наступлении или предупреждении риска;
ü Финансовая оценка всех затрат, связанных с выбором каждого решения. В качестве одного из подходов можно предложить включать в финансовую оценку наряду с TCO оценку рисков, связанных с выбором конкретного решения.
При принятии решения важно соблюсти принцип коллегиальности и участия всех заинтересованных лиц, иначе могут возникнуть как политические, так и организационные препятствия — причем уже при внедрении системы.
Если окончательный выбор сделать не удается, то следует задаться вопросом: «Какая дополнительная информация позволит склонить чашу весов в ту или иную сторону?» После этого участникам направляются дополнительные запросы и проводятся новые встречи.
В отчете о результатах тендера должно даваться краткое заключение по каждой из рассматриваемых систем. Рекомендуется определять не только единоличного победителя тендера, но и второго «финалиста» — на тот случай, если по каким-либо причинам не удастся заключить договор поставки с победителем.
7. Заключение соглашения с победителем тендера
После того, как победитель определен, с ним заключат соглашение на поставку информационной системы. Предварительно может быть подписан договор о неразглашении. После согласования с поставщиком всех условий поставки договор подписывается, что является точкой в процессе проведения тендера и началом проекта внедрения новой системы. Материалы, использованные в процессе проведения тендера, могут стать хорошей основой для написания технического задания на доработку системы.
Вне зависимости от того, будет ли компания обращаться к помощи консультантов или примет решение все работы проводить самостоятельно, принципы проведения тендера едины:
ü Организация тендера как самостоятельного проекта со своими целями, ресурсами, сроками;
ü Выделение ключевых требований бизнеса как критериев для выбора;
ü Поэтапное уточнение критериев — от «длинного списка» до окончательного выбора победителя;
ü Поэтапное сокращение числа и детализация описания сравниваемых решений.
3. Состояние рынка ИТ-аутсорсинга
Глобальный финансовый кризис выводит тему ИТ-аутсорсинга на повестку дня руководителей предприятий, стремящихся активно и гибко противодействовать негативным явлениям. Согласно исследованиям, 43% крупнейших европейских и североамериканских компаний уже сократили свои ИТ-бюджеты. Большинство из них считают аутсорсинг инструментом для уменьшения ИТ-издержек: так, увеличить долю аутсорсинга приложений планируют 45%, долю аутсорсинга инфраструктуры — 43%, долю технического консалтинга — 38%. Среди ИТ-процессов, которые российские компании намереваются передать на аутсорсинг в течение этого года выделяются услуги дата-центра (10%), управление рабочими станциями (10%), поддержка пользователей и приложений, а также ИТ-консалтинг (по 8%).
Сегодня на первый план среди преимуществ ИТ-аутсорсинга выходит возможность получения компанией большей гибкости в управлении и обслуживании своей ИТ-инфраструктуры. Неоспоримым в текущей ситуации преимуществом аутсорсинга является также возможность оперативного наращивания или сокращения услуг. То, что может быстро обеспечить грамотный подрядчик, не дадут ни набор или сокращение персонала, ни увеличение или уменьшение расходов.
В последние годы внутренние затраты на ИТ российских предприятий и организаций росли существенно (почти в два раза) быстрее, чем внешние. По сути, имел место процесс, обратный аутсорсингу, что способствовало развитию натурального хозяйства. Сейчас для значительного числа компаний это становится непосильной ношей. Наблюдаемое в настоящее время нарастание конкуренции во всех отраслях экономики, резкое сужение горизонтов планирования и, как следствие, необходимость получения информации о деятельности компании в режиме реального времени требуют очень высокого уровня надежности ИТ-систем и качества информации в них.
4. Пример внедрения ИТ-аутсорсинга
Рассмотрим пример ИТ-аутсорсинга на примере внедрения ITIL (IT Infrastructure Library) — библиотеки, описывающей лучшие из применяемых на практике способов организации работы подразделений или компаний
Кратко о Проекте
ü Техническая реализация проекта: на базе Ilient SysAid.
ü Сервер баз данных MS SQL.
ü Время реализации Проекта: 9 месяцев.
Основные результаты
ü Сервисный отдел работает в режиме самоокупаемости; дополнительный доход подразделения около $470K в год;
ü повышение эффективности сервисного отдела на 42% (см. таблица 1);
ü централизованная приемка и обработка заявок;
ü контроль эффективности инвестиций;
ü улучшение эффективности коммуникаций внутри отдела;
ü эффективное управление ресурсами отдела;
ü эффективное распределение зон ответственности;
ü компания может гарантировать выполнение своих договорных обязательств;
ü эффективное управление рисками;
ü повышение лояльности заказчиков;
Проект заложил надежный фундамент преобразований фундамент для дальнейшего развития компании «СП»
Цель данного обзора – на примере из практики продемонстрировать экономический эффект от внедрения процессов ITIL. Для рассмотрения выбран сервисный ИТ-отдел крупной отечественной компании «СП», в которой силами специалистов BENEFFY Consulting был реализовано внедрение ряда процессов ITIL. Согласно с договором о конфиденциальности название компании, в которой был реализован проект, было изменено.О компании «СП»
Компания «СП» специализируется на построении корпоративных информационных систем, телекоммуникационной инфраструктуры, торговле вычислительной техникой.
Сервисный отдел «СП» отвечает за выполнение гарантийных обязательств компании перед заказчиками, осуществляет поддержку пользователей. Кроме этого, в небольшом объеме, отдел предоставляет услуги по ИТ-аутсорсингу: обслуживание ИТ-инфраструктуры Заказчика, расширенная поддержка пользователей.
Территориально компания расположена в Украине, имеет 5 филиалов.
Штат сервисного отдела компании 12 человек. Из них 6 человек в центральном офисе и 6 в филиалах компании.
Толчком к проведению реформирования сервисного отдела в Компании было решение руководства взять на ИТ-аутсорсинг несколько крупных компаний финансового сектора, обладающих распределенной филиальной сетью.
Потребность в изменениях
Руководство «СП» провело анализ деятельности сервисного отдела компании за последний год. В результате анализа эффективность отдела получила негативную оценку.
Данный вывод базировался на следующих фактах.
ü Превышение сроков ремонта гарантийной техники в 2-3 раза стало для компании обычным явлением, более того, участились случаи превышения сроков ремонта в 10 раз.
ü Компания «СП» не в состоянии гарантировать выполнение собственных договорных обязательств касательно гарантийного обслуживания.
ü Качество ремонта неприемлемо низко, в 10% случаев возникает необходимость в повторных ремонтах.
ü Количество жалоб на работу сервисного отдела «СП», за истекший год увеличилось вдвое.
ü По данным опроса, проведенного среди заказчиков «СП», имидж компании заметно ухудшался.
ü Уменьшение заказов постоянных клиентов достигло 20% по сравнению с предыдущим годом.
ü Издержки на содержание сервисного подразделения стали неоправданно большими.
ü Увольнения в сервисном отделе составили 4 человека за год (33% штата).
ü Руководство «СП» ощущало нехватку информации. В результате управленческие решения принимаются на основании субъективных оценок.
ü Существующая структура сервисного отдела не позволяет на его основе развивать направление ИТ-аутсорсинга.Эффект от внедрения Проекта преобразований
После реализации Проекта удалось достичь следующих результатов:
ü Сервисный отдел начал работать в режиме самоокупаемости за счет нового направления ИТ-аутсорсинга.
ü Сервисный отдел получил возможность дополнительного дохода $470K в год (см. раздел Финансовые результаты).
ü На 40% снижены непродуктивные издержки сервисного подразделения.
ü Количество единиц техники на обслуживании увеличено с 75 до 4150.
ü Количество административных единиц (отделений, офисов) взятых на аутсорсинг увеличено с 5 до 58.
ü Число жалоб на работу сервисного подразделения «СП», снизилось на 90%.
ü Нарушения сроков гарантийного ремонта сведены к минимуму (не более 5% случаев).
ü Число повторных ремонтов сведено к 0.5%, благодаря введенной процедуре контроля качества ремонта.
ü Компания может гарантировать выполнение своих договорных обязательств.
ü Введена процедура сбора отзывов заказчиков о качестве и сроках решения инцидентов.
ü Введены механизмы контроля загрузки персонала (минимизировано количество простоя).
ü Расширен спектр предоставляемых сервисным отделом услуг.
ü Принятие управленческих решений опирается на достоверные количественные данные. Описание преобразований
Проект был разбит на 2 этапа;
ü Первый этап – создание службы Service Desk, внедрение процесса управления инцидентами. Основная цель – достижение 100% регистрации инцидентов, накопление и анализ информации, детальное планирование преобразований.