Главная страница

Организация ИТ аутсорсинга_Лаб 1. Лаб 1 — копия. Лабораторная работа 1. Бизнесмодель итаутсорсинговой компании


Скачать 2.21 Mb.
НазваниеЛабораторная работа 1. Бизнесмодель итаутсорсинговой компании
АнкорОрганизация ИТ аутсорсинга_Лаб 1
Дата18.05.2023
Размер2.21 Mb.
Формат файлаdocx
Имя файлаЛаб 1 — копия.docx
ТипЛабораторная работа
#1140714
страница1 из 6
  1   2   3   4   5   6

Лабораторная работа №1.

Бизнес-модель ИТ-аутсорсинговой компании.
Цель работы – разработать бизнес-модель ИТ-аутсорсинговой компании, осуществляющей свою деятельность на территории Краснодарского края.
1. ТЕОРЕТИЧЕСКОЕ ОБОСНОВАНИЕ
Термин аутсорсинг происходит от английских слов "outsourcing - outside resource using" – использование внешних ресурсов, привлечение ресурсов извне. Суть понятия заключается в передаче на выполнение отдельных функций или бизнес-процессов внешней организации, располагающей для этого необходимыми ресурсами, на основе долгосрочного соглашения. В рамках заключенного соглашения активы предприятия, относящиеся к отдаваемым функциям и бизнес-процессам, персонал, управленческая ответственность могут временно передаваться сторонней организации.

Аутсорсинг можно определить, как "перевод внутреннего подразделения или подразделений предприятия и всех связанных с ним активов в организацию поставщика услуг, предлагающего оказывать некую услугу в течение определенного времени по оговоренной цене".

Аутсорсинг позволяет эффективно распределить внутренние и внешние ресурсы, средства организации для успешного достижения её бизнес-целей. Основой концепции является разделение функций предприятия на основные и второстепенные, и дальнейшая передача второстепенных функций внешней организации, которая специализируется на этих функциях и более эффективно решает поставленные перед ней задачи. Часто аутсорсинг рассматривается как инструмент сокращения затрат, а также способ, дающий предприятию возможность сконцентрироваться на основных видах деятельности. Пригодными для аутсорсинга считаются зрелые функции, в которых не используются инновации, дающие организации конкурентные преимущества. Не рекомендуется передавать на аутсорсинг стратегическое развитие предприятия, построение и развитие архитектуры, бизнес процессы, которые имеют стратегическое значение и представляют собой ключевые компетенции предприятия.

Основными причинами применения аутсорсинга как стратегии управления являются:

  • стремление сосредоточить ресурсы собственного предприятия на "центрах прибыли" — профильных бизнес-процессах, в рамках которых создается основная продукция;

  • повышение качества услуг;

  • отсутствие или недостаток собственных квалифицированных специалистов;

  • получение доступа к новым передовым технологиям и техническим знаниям;

  • снижение расходов.

Антонимом термина "аутсорсинг" является понятие "инсорсинг" – передача новых функций на выполнение внутренним подразделениям предприятия или расширение деятельности подразделений для дополнительной загрузки имеющихся мощностей или активов. Примерами инсорсинга может служить использование базы данных клиентов, полученной при продажах определенного вида товара для продаж или продвижения другого товара, сдача в аренду незадействованных в производстве площадей. Инсорсинг позволяет предприятиям снизить издержки неиспользуемой мощности. При применении этого подхода в штатной структуре предприятия может быть создано отдельное подразделение с автономным управленческим учетом, оказывающее специализированные услуги, как другим внутренним подразделениям предприятия, так и внешним контрагентам. Чаще всего инсорсинг применяют для процессов, связанных с финансами, трудовыми ресурсами и информационными системами.
На сегодняшний момент существуют различные подходы к определению ИТ- аутсорсинга. В них данное понятие рассматривается как с разных позиций практики аутсорсинга (снижения затрат, качества обслуживания, набора услуг, доступа к умениям и навыкам, рисков, степени технологической зрелости), так и различных теоретических основ (экономической теории, теории транзакционных издержек, теории управления, теории принятия решений и др.).

ИТ-аутсорсинг можно определить, как "существенный вклад внешних поставщиков в физические и (или) кадровые ресурсы, связанные с ИТ-инфраструктурой клиентской организации в целом или ее (инфраструктуры) отдельными компонентами" или "решение предприятия о передаче части или всех функций обслуживания корпоративной ИС внешнему поставщику (или поставщикам) услуг для того, чтобы компания могла достичь своих целей".

Обобщая теоретические разработки, можно сделать вывод, что, как правило, под ИТ-аутсорсингом понимается передача части или всех ИТ-функций внешнему поставщику услуг на условиях заключенного долгосрочного соглашения, в рамках которого проводится передача или продажа ИТ-активов в совокупности с переводом персонала на оговоренный период.

На многих предприятиях, не относящихся к рынку информационных технологий, роль ИТ-подразделения заключается в выполнении важных, но непрофильных функций, обеспечивающих и поддерживающих основную деятельность предприятия. Поэтому ИТ-функции часто рассматриваются как кандидаты для передачи на аутсорсинг. При этом особое внимание уделяется снижению затрат на ИТ при одновременном обеспечении необходимого уровня производительности, качества, доступности и гибкости ИТ-услуг конечным пользователям.
Институт аутсорсинга (Outsourcing Institute, США), в своих исследованиях выделяет два основных вида аутсорсинга: аутсорсинг бизнес-процессов (BPO - business process outsourcing) и аутсорсинг в области информационных технологий (ИТ-аутсорсинг)


Рисунок 1 - Классификация аутсорсинговых услуг
Аутсорсинг бизнес-процессов (АБП, ВРО - Business Process Outsourcing) – это передача права владеть и управлять каким-либо бизнес-процессом внешней организации для решения задач бизнеса предприятия. Данный вид аутсорсинга направлен на обеспечение более высокой эффективности бизнес-процессов. Его необходимость часто возникает в связи с реструктуризацией предприятия. В этом случаеаутсорсинг является инструментом для управления преобразованиями.

На аутсорсинг передают ведение бухгалтерского учета, расчет заработной платы, материально-техническое обеспечение, маркетинг, логистику, юридическое сопровождение и подготовку договорной документации, решение миграционных вопросов, поиск и подбор персонала, кадровое администрирование, call-центр, уборку помещений, организацию питания, охрану.

Некоторые аналитики в отдельную группу выделяют производственный аутсорсинг. Производственный аутсорсинг заключается в передаче части цепочки производственных процессов или целиком всего цикла производства сторонней компании, в тех случаях, когда процесс производства собственными силами обходится предприятию дороже, чем привлечение внешней компании. В этом направлении выделяют аутсорсинг производства заготовок и комплектующих и аутсорсинг функций и операций по обеспечению производства продукции. Производственный аутсорсинг распространен в автомобильной промышленности, машиностроении, среди производителей электроники и телекоммуникационных компаниях, предприятий добывающих отраслей, организаций фармацевтической промышленности, производстве ракетных и других оборонных и космических комплексов. Он позволяет предприятию сосредоточиться на разработке новых продуктов и услуг, увеличить гибкость производства и вести деятельность в других регионах, используя более дешевую рабочую силу.

С точки зрения состава и предмета работ основными видами услуг в области ИТ-аутсорсинга являются:

  • телекоммуникационные услуги и обеспечение доступа к вычислительным ресурсам (доступ в Интернет, обработка, хранение и передача данных, видеоконференцсвязь др.);

  • техническая поддержка и управление ИТ-инфраструктурой, включая администрирование серверного и системного ПО, вычислительных сетей;

  • управление рабочими станциями;

  • управление единой службой поддержки пользователей;

  • обеспечение информационной безопасности;

  • разработка ПО;

  • управление и поддержка бизнес-приложений;

  • услуги ЦОД (центр обработки данных).


Распределение востребованности этих услуг в России представлено на рисунке 2.

Рисунок 2 - Распределение услуг аутсорсинга российских компаний
Существует другой подход к классификации аутсорсинговых услуг в сфере ИТ. Выделяют три основные формы ИТ-аутсорсинга: ресурсный, функциональный и стратегический ИТ-аутсорсинг.

На российском рынке наиболее распространенной формой ИТ-аутсорсинга является ресурсный аутсоринг. При использовании данной формы аутсорсинга аутсорсер предоставляет предприятию необходимые ресурсы (от оборудования до ИТ- специалистов), отвечая за наличие ресурса и его соответствие требованиям предприятия. Уровень сервиса определяется количеством ресурсов. При этом предприятие, пользующееся такими ресурсами, самостоятельно ими управляет. Причинами преобладания ресурсной формы аутсорсинга являются прозрачность ценообразования, небольшой по сравнению с другими формами аутсорсинга объем подготовительных работ (не требуется описания предоставляемых услуг, инфраструктурных ресурсов), неготовность менеджмента предприятия к использованию более сложных форм аутсорсинга и отсутствие доверия провайдеру услуг со стороны предприятия в области прозрачности и управляемости передаваемых процессов. Примером ресурсной формы аутсоринга является аутсорсинг ИТ-персонала.

При функциональном аутсорсинге провайдеру аутсорсинговых услуг передается выполнение определенных ИТ-функций и управление ими. Этот подход требует большой подготовительной работы, в т.ч. детальной проработки контракта и соглашения об уровне обслуживания, в котором определяется состав, объем и показатели качества предоставления услуг. Российский рынок функционального аутсорсинга находится в стадии становления. Как показывает практический опыт, при установлении прочных партнерских отношений, достижении поставленных целей аутсорсинга растет доверие к провайдеру услуг, и предприятия начинают рассматривать возможность перехода с ресурсного аутсорсинга на функциональный как эволюционный путь развития отношений.

В случае стратегического аутсорсинга аутсорсер берет на себя управление всем ИТ-подразделением предприятия, эксплуатацией и развитием систем, закупками и обслуживанием. Это направление аутсорсинга на сегодняшний день в России не развито.
2. ЗАДАНИЯ ДЛЯ САМОСТОЯТЕЛЬНОЙ РАБОТЫ


  1. Используя шаблон бизнес-модели А. Остервальдера осуществить разработку бизнес-модели организации, оказывающей услуги ИТ-аутсорсинга на территории г. Краснодара или Краснодарского края.

  2. Используя платформу «1С: Предприятие», начать разработку информационной системы, обеспечивающей поддержку принятия решений при проектировании бизнес-модели:

  • спроектировать командный интерфейс;

  • создать справочник Номенклатура;

  • создать справочник Клиенты;

  • создать справочник Конкуренты.



3. АЛГОРИТМ ВЫПОЛНЕНИЯ РАБОТЫ


  1. Используя шаблон бизнес-модели А. Остервальдера осуществить разработку бизнес-модели организации, оказывающей услуги ИТ-аутсорсинга на территории г. Краснодара или Краснодарского края.


На рисунке 3 приведен шаблон бизнес-модели А. Остервальдера.


Рисунок 3 – Шаблон бизнес-модели А. Остервальдера
Проектирование бизнес-модели организации осуществляется на основе теоретических сведений о деятельности аутсорсинговых компаний, приведенных в теоретическом обосновании.


  1. Используя платформу «1С: Предприятие», начать разработку информационной системы, обеспечивающей поддержку принятия решений при проектировании бизнес-модели:


2.1 Проектирование командного интерфейса
Используя объект «Подсистемы» провести разделение прикладного решения на следующие разделы:

  1. Планирование

    1. Ценностное предложение

    2. Клиенты

    3. Бизнес-процессы

    4. Доходы и расходы

  2. Продажи

  3. Проекты


2.2 Создание справочника Номенклатура
При создании справочника Номенклатура, необходимо предусмотреть наличие в нем иерархии групп и элементов. Заполнение справочника в пользовательском режиме осуществлять согласно блоку «Ценностное предложение» разработанной бизнес-модели.
2.2 Создание справочника Клиенты
При создании справочника «Клиенты» необходимо предусмотреть для каждой его записи описание потребительского сегмента, в который он входит. Так, например, потребительский сегмент имеет следующее описание: «В2В; г. Краснодар; РТО; малый бизнес». Соответственно в справочнике необходимо предусмотреть соответствующие реквизиты, которым назначить тип данных Булево. Общее количество подобных реквизитов должно соответствовать выделенным потребительским сегментам в бизнес-модели.

Кроме того, в пользовательском режиме необходимо заполнить сведения по клиентам (минимум 10 для каждого выделенного сегмента) со ссылкой на web-ресурс на котором размещена эта информация. Это реализуется путем добавления в справочник реквизита «Примечание».
2.3 Создание справочника Конкуренты
Основное предназначение справочника «Конкуренты» хранить список конкурентов и информации по ним (адрес, телефон, сайт). Кроме этого, необходимо предусмотреть реквизит «Примечание», который будет содержать ссылку на web-ресурс, на котором размещена эта информация (в том случае, если у организации нет своего сайта).

КОНТРОЛЬНЫЕ ВОПРОСЫ


  1. Определите суть понятия "аутсорсинг".

  2. Укажите основные причины применения аутсорсинга.

  3. Какие факторы мешают развитию аутсорсинга в России?

  4. Дайте определение ИТ- аутсорсинга.

  5. Что подразумевает полный аутсорсинг?

  6. Укажите особенности частичного аутсорсинга.

  7. Какие существуют виды аутсорсинга?

  8. Перечислите основные виды услуг в области ИТ-аутсорсинга.

  9. Каковы ключевые тенденции развития на рынке ИТ-аутсорсинга?

ЛАБОРАТОРНАЯ РАБОТА №2

Классификация ИТ-сервисов

Цель работы: изучить последовательные этапы для составления списка ИТ сервисов.
Краткая теория:

  1. Классификация ИТ-Сервисов

Наряду с Типами Сервисов необходимо также понимать, что сервисы должны подразделяться в соответствии с тремя основными классификациями. Эти классификации особенно важны, когда приходит время применить их к модели затрат. Важно также понимать, что список сервисов, разделенный в соответствии с этими классификациями, должен определяться для каждой организации и будет изменяться в соответствии со средой или применяемой бизнес-моделью.

    1. Ядро и базовые сервисы

    • Базовый сервис – это сервис, который требуется всем потребителям и за который каждый потребитель должен платить соответствующую долю. Эти сервисы как «воздух», они нужны вам, чтобы существовать и у вас нет возможности отказаться от их использования или потребления. Типичными примерами базовых сервисов являются:

      • Передача данных /Локальная сеть

      • Электронная почта

      • Поддержка

      • Голосовая связь

      • Безопасность

    1. Подписные сервисы

    • Подписной сервис – это сервис, который может быть выбран из списка типа «A La Carte» на основе бизнес-функций, в которых заказчик задействован. Эти сервисы появятся в счете клиента только если он использует или подписан на этот сервис. Примерами подписных сервисов обычно являются сервисы, основанные на приложениях, и описываются они в соответствии с бизнес процессом или функцией, которую они поддерживают:

      • Сервисы КИС

      • Банк-клиент

      • Торговые прикладные системы

      • Кадровые системы

      • Исследования рынка

      • И т.д.

    1. Заказные сервисы

    • Заказные сервисы – это сервисы, которые ИТ предоставляет на основе «плати-и-тогда-получишь». Эти сервисы обычно предоставляются клиенту, только если он запрашивает их для специальной деятельности вне стандартного сервисного пакета. Примерами заказных сервисов являются:

      • Управление проектами

      • ИТ-консалтинг

      • Обзор новой технологии

      • Закупки

      • И т.д.

Полное и детальное описание этих сервисов в Каталоге Сервисов с различными вариантами уровня качества и доступности относится к Управлению Уровнем Сервиса и выходит за рамки этой статьи. Для целей моделирования и оценки затрат достаточно, чтобы сервисы были бы определены и классифицированы как исходные данные для Системы Управления Конфигурацией и ИТ Финансами. Забегая вперед, следует сказать, что критичным фактором является согласование определений сервисов, используемых при оценке затрат и подготовке счетов, с Каталогом Сервисов

    1. Порядок определения сервисов

Следующий раздел определяет логические последовательные этапы для составления списка ИТ сервисов. Этими этапами являются:

    • Определение Основных Бизнес Процессов

    • Определение Обеспечивающих Их ИТ Сервисов

    • Отображение ИТ Системы в ИТ Сервисы

    • Отображение ИТ Компонент в ИТ Системы. 

Шаг 1: Определить Основные Бизнес Процессы

Наиболее правильным способом определения ИТ сервисов является взгляд с точки зрения заказчика - учет услуг с точки зрения их параметров качества и, в перспективе, количества и стоимости предоставления. Для того, чтобы определить эту точку зрения ИТ, организация должна понимать, как она облегчает бизнес, делая возможными различные бизнес процессы. Отсюда логически вытекает, что начинать такую деятельность следует с определения, какие бизнес процессы присутствуют в компании. Следующая модель управления ИТ взята из книги ITIL Understanding & Improving – The Business Perspective On Your IT Infrastructure. Эта модель управления ИТ разбивает бизнес процессы на четыре основных категории:

    • Процессы Управления

    • Процессы Поддержки

    • Процессы Инноваций

    • Главные Бизнес Процессы

Каждая из этих категорий в свою очередь имеет подпроцессы, которые нужно определить, чтобы получить приемлемый уровень детализации, позволяющий начать деятельность по определению сервисов.



Шаг 2: Определить ИТ-Сервисы

Многие ИТ сервисы будут определены и названы после определения бизнес процессов и функций, которые эти ИТ сервисы облегчают. Преимущества соотнесения имен ИТ сервисов с бизнес процессами - в том, что это улучшает понимание и клиентов и ИТ персонала того, как технологии помогают в достижении бизнес целей. 

Чтобы проиллюстрировать эту деятельность, ниже выделена категория «Процессы поддержки бизнеса»:

Примеры подпроцессов поддержки бизнеса:

    • Примерами типичных бизнес процессов в этой категории являются:

      • Управление кадрами

      • Корпоративные финансы

      • Поддержка офиса

      • Логистика

      • Связь

      • И т.д.

Хотя многие названия сервисов будут общими для разных компаний, каждая организация должна проделать это упражнение для того, чтобы определить свой персональный список ИТ сервисов. Эта деятельность, по сути, является возможностью для изучения и понимания реального соотношения бизнеса и ИТ.

Шаг 3: Отобразить ИТ-Системы в ИТ-Сервисы

Следующий шаг в этом процессе проходит более естественно для технических специалистов поскольку он включает определение и именование ИТ систем, которые ИТ организация создает и поддерживает, а также отображение этих систем на определение ИТ сервисов. Помните, что ИТ система - это совокупность компонентов, необходимых для предоставления заказчику технологического решения. Часто ИТ система наследует имя основного приложения, работу которого она обеспечивает. Другой принцип, который также следует иметь в виду, состоит в том, что хотя существует одно определение ИТ сервиса, на количество систем, которые могут быть отображены в него ограничений нет.

Некоторые примеры отображений сервис/система приведены ниже:

ИТ Сервис

ИТ Система

Электронная почта

MS Exchange 
Lotus Noyes

Общая инфраструктура

Данные/LAN 
Голосовая связь 
Управление хранением

Управление кадрами

PeopleSoft 
Payroll

Когда все ИТ-сервисы и ИТ-системы определены Управлением Уровнем Сервиса (SLA) эта информация передается Управлению Конфигурацией для облегчения проектирования Объектной модели CMDB и управлению Финансами для разработки Моделей Затрат и Платежей, основанных на сервисах.

Шаг 4: Отобразить ИТ-Компоненты в ИТ-Системы

Последний шаг в этом процессе состоит в отображении ИТ-компонент или CI в ИТ системы. Это функция процесса Управления Конфигурацией и будет выполняться в рамках CMDB. В следующем разделе будет рассмотрена эта тема.

  1. Задание для самостоятельной работы

Определите логические последовательные этапы для составления списка ИТ сервисов относительно закрепленного за вами предмета исследования.
Лабораторная работа №3

Разработка модели затрат на сервис.

Моделирование ИТ-Сервисов.

Следующим шагом после того, как ИТ-сервисы определены и документированы, является моделирование этих сервисов в Базе данных Управления Конфигурацией (CMDB). База данных конфигурационных элементов (CMDB) может быть создана с помощью методов моделирования данных и объектов, чтобы представить как точку зрения бизнес-сервиса, так и технологическую точку зрения на то, как соотносятся CI для поддержки бизнес-процессов. Фактически главной целью Управления Конфигурацией является облегчение создания виртуальной модели ИТ инфраструктуры (CMDB) в реальном масштабе времени с точки зрения того, как она поддерживает и контролирует ИТ.

Задача управления конфигурацией

Управление конфигурацией представляет логическую модель инфраструктуры или сервиса, выявляя, контролируя, поддерживая и проверяя версии существующих конфигурационных элементов.

Цель Управления Конфигурацией заключается в:

    • Учете всего ИТ-имущества и его конфигураций в организации и ее сервисах.

    • Предоставлении точной информации по конфигурациям и их документирование для поддержки всех процессов управления сервисами.

    • Предоставлении прочной базы для Управления Инцидентами, Управления Проблемами и Управления Релизами.

    • Проверке соответствия конфигурационных записей инфраструктуре (CMDB) и исправление всех отклонений.

Управление Конфигурацией – важная часть всей структуры управления сервисами в ITIL. Оно служит центральной точкой для совместного пользования информацией и взаимодействия остальных процессов. Имущество в терминологии ITIL называется конфигурационным элементом. Конфигурационным элементом может быть названо все, что организация хотела бы контролировать.

Необходимо иметь возможность регистрировать в CMDB следующие основные компоненты:

    • Физические CI: Сервер, коммутатор, прикладная система, база данных, документ и т.д. 

    • Логические CI: ИТ сервис, ИТ система, записи состояния инфраструктуры и т.д. 

    • Атрибуты CI: Скорость CPU, серийный номер, версия, автор, дата покупки и т.д. 

    • Отношения между CI: Предок потомок, состоит из, установлено на, предоставляет данные и т.д.

Управление конфигурацией и учет компьютеров при моделировании ИТ-Сервисов

Для того, чтобы смоделировать ИТ сервисы, должны быть разработаны объектная модель и модель данных, что позволит проиллюстрировать каким образом различные типы CI представляются, какие атрибуты они имеют и какие отношения их связывают. Модель данных диктует способ отображения ИТ сервисов в CMDB. Практическое применение этого заключается в создании логических записей, которые представляют ИТ сервисы, включая то как они разбиты на ИТ системы, подсистемы и физические компоненты. Концепция, представленная таким подходом, позволяет соотнести физические CI (аппаратура, ПО, документы и т.д.) с цепочкой ИТ сервисов как это проиллюстрировано ниже.

Используйте аналогию:

Если инфраструктура – это пазл, а CI – это кусочки пазла, то конструкция Объектной Модели Управления Конфигурацией (CMDB) – это картинка на коробке пазла.

Точно также, как трудно составить пазл без картинки, так и трудно понять, какую роль различные CI играют в инфраструктуре без определения объектной модели. 

Некоторыми ключевыми преимуществами, вытекающими из этой модели, являются:

  • Понимание того, как CI связаны с ИТ бизнес-сервисами в рамках процесса

  • Какие прямые и косвенные имущественные затраты связаны с ИТ-сервисами 

  • Как параметры доступности связаны с отдельными CI, группами CI и общими целями доступности сервиса

  • Какие CI обеспечивают несколько сервисов

  • Как определяется приоритет CI в отношении критичности бизнеса и функций

Для каждого ИТ бизнес-сервиса и каждой ИТ-системы, определенных процессом Управления Уровнем Сервиса, в логической структуре CMDB должна быть создана запись. После того, как эта структура будет построена в соответствующем инструменте, логическая структура остается относительно статической, и не будет существенно меняться до появления нового сервиса. 

Объектная модель CMDB и ИТ-сервисы




  • Различия между логическими и физическими конфигурационными элементами

    • Логические: Подсистемы и выше

    • Физические: Компоненты и ниже

Многоуровневое представление вертикально упакованных проектных классов:

    • Сервис

    • Система

    • Подсистема

    • Компонент

Разработка модели затрат, основанной на сервисах

ИТ сражается на многих направлениях, чтобы стать более предусмотрительной в управлении и доставке своих сервисов клиентам. Это нигде так не очевидно, как в способе подсчета затрат на технологию. 

Прискорбно, что обычно в течение года случается следующее: все ИТ затраты и потери собираются в большой центр затрат или общеизвестную корзину, которая в конце отчетного периода ставится на стол, а затем делится поровну на всех клиентов безотносительно к тому кто и как использовал ИТ. 

Нет другой возможности в контроле ИТ для выражения точных затрат на предоставление сервисов клиентам, кроме обеспечения точного отслеживания того, как сервисы потребляются заказчиками. Иная практика не предоставляет возможности использовать подсчет затрат как инструмент управления и планирования поскольку вы не можете улучшать то, что вы не понимаете.

Финансовое управление для ИТ-сервисов

Цель: Финансовое управление является разумным проводником денежных ресурсов организации. Оно поддерживает организацию в планировании и достижении своих бизнес целей и требует единообразного применения принципов по всей организации для достижения максимальной эффективности и минимума конфликтов. 

Интересный момент заключается в том, что в ответ на предложение о наведении дисциплины в части затрат можно достаточно часто услышать, что ИТ является «центром затрат» и находясь вне рынка не может определять цену своих сервисов. Это утверждение часто используется как удобное оправдание для того, чтобы не заниматься дисциплиной в области ИТ затрат в сколько либо значимых деталях. Однако логичным ответом таким организациям является то, что хотя они не могут выставлять счета внутренним клиентам, но, тем не менее, должны учитывать стоимость предоставления ИТ сервисов бизнесу и определять бюджет на следующий период. В последнее время это стало еще более важно в связи с тем вниманием, которое рынок уделяет к снижению затрат и управлению финансами. ИТ организации не могут больше быть по-прежнему легкомысленными, и бизнес требует точных контроля иучёта ИТ-службы, а также отслеживания ИТ-затрат в связи с использованием и потреблением. 

Конечно, нюанс здесь в том, что вам требуется определить и смоделировать эти сервисы, прежде, чем вы сможете определить их стоимость. Попытка разработать методологию расчета затрат без реализации первых двух этапов, описанных в этой статье, становится трудной, если вообще осуществимой с требуемой точностью.

Понимание ИТ-затрат

Общепризнано, что ITIL не определяет, какая именно методология подсчета затрат должна использоваться. Однако в книге ITIL Service Delivery проведен хороший обзор двух главных подходов: «Учет затрат по центрам затрат» и «Учет затрат по деятельностям или сервисам». 

При взгляде сверху Учет затрат и ИТ-услуг по центрам затрат – это практика отнесения всех затрат и расходов в прямой форме на клиента или организационную единицу. Это традиционно наиболее широко используемый метод учета затрат поскольку он хорошо работает с упомянутым ранее методом разделения общей стоимости ИТ на всех клиентов поровну. 

Учет затрат по деятельностям или сервисам – это практика отнесения всех связанных затрат и расходов на определенную деятельность или ИТ-сервис. Подсчитав все затраты на сервис можно определить единицу затрат. И она становится инструментом понимания того, как деятельность или сервис может быть отнесена на заказчика в соответствии с объемом потребления сервиса. 

Чтобы дальше развивать эти понятия необходимо определить несколько ключевых терминов.

Определения:

  • Прямые затраты: Явно относимые на отдельного заказчика/сервис/местоположение.

    • Такие затраты непосредственно относятся и полностью сопоставляются конкретному заказчику или сервису.

  • Косвенные – разделяемые затраты: Выполняемые от имени всех или нескольких заказчиков/сервисов/местоположений

    • Эти затраты разделяются среди нескольких заказчиков или сервисов и сопоставляются пропорционально некоторому параметру, например, количеству пользователей или процентному соотношению.

  • Накладные расходы: Затраты, которые не могут быть прямо отнесены к какому либо заказчику/сервису/местоположению

    • Эти затраты не могут быть отнесены на заказчика или сервис. Примерами накладных расходов являются зарплата руководителей, общая административная деятельность и т.д.

  • Единица затрат: Единица затрат позволяет разбить общую стоимость сервиса на небольшие единицы

    • Единица затрат позволяет разбить затраты, которые требует весь сервис, на части, которые могут быть отнесены на конкретного заказчика. Примером единицы затрат является стоимость на почтовый ящик для выставления счета за пользование электронной почтой.

Важно разработать методологию, которая включает все три типа затрат, так как сервис, затраты на который будут рассчитываться только исходя из прямых затрат, в конце концов не будет окупаться.

Аналогия с молоком:

Приведем пример действия этого принципа не из ИТ области: вычисление общей стоимости стакана молока. Если вы будете учитывать только затраты на обслуживание и питание коров, то единица затрат на один стакан молока может составить всего 50 центов. Однако, когда вы учтете процент стоимости страховки фермы, платежи по закладным и лизингу оборудования фермы, то общая стоимость стакана молока может стать 110 центов. В конце концов, все это придется платить.




Хотя ITIL не указывает явно на предпочтение какой-либо модели расчета затрат, логическим предпочтением является модель затрат на основе сервисов по простой причине: философия управления сервисами в большей степени соответствует такой модели.

Расчет затрат на сервис

В соответствии со своим именем расчет затрат на сервис предполагает представление всей цепочки затрат на предоставление IT-сервиса. Практически это означает, что методология расчета затрат и совокупность центров затрат должны быть определены с помощью определений сервисов полученных в процессе Управления Уровнем Сервисов и опубликованных в каталоге сервисов. В принципе это означает, что каждая строка в клиентском счете должна соответствовать сервису, как он определен в SLA (соглашение об уровне сервиса) и какие CI указаны вCMDB.




Следующий рисунок иллюстрирует как принципы прямых, косвенных и накладных затрат объединяются вместе для получения полной картины расчета затрат на сервис.

Используя перечень CI и роли, которые прописаны в CMDB по отношению к IT-сервису, можно легко вывести прямые затраты на этот сервис с помощью запроса финансовых атрибутов тех CI, которые не связаны с другими сервисами. Могут существовать CI, которые связаны с несколькими сервисами по функциональным возможностям. Например, на одном сервере могут быть установлены несколько прикладных систем и этот сервер должен быть отнесен ко всем сервисам, которые он обеспечивает.

Компонентные сервисы

При установлении косвенных или накладных затрат следует учитывать такой элемент как компонентные сервисы. 

Компонентный сервис или услуги коммунального типа – это полностью расцененный сервис, который прямо не указывается в счетах пользователя или в механизмах возмещения затрат. 

Результатом такого решения является то, что эти сервисы должны учитываться сверх прямых или видимых клиентом сервисов для того, чтобы обеспечить финансовое возмещение. Какие сервисы оказываются компонентными, определяется в процессе Управления IT Финансами при разработке методологии расчета затрат. 

Примером компонентного или коммунального сервиса может быть сервис передачи данных по сети, если организация решит учитывать затраты на него в других сервисах как накладные или косвенные затраты. К коммунальному типу сервисов может быть отнесены затраты на центр данных или коммутационные комнаты. Эти сервисы могут быть учтены в других сервисах, с которыми пользователь сталкивается непосредственно, на основе некоторого определенного принципа. 

Такой принцип есть способ расчета доли стоимости относимой на другие сервисы и может быть одинаковым процентом, пропорциональным численному составу, занимаемой площади или количеству компонент.

Шаги по расчету затрат на сервис

Крупными шагами по расчету затрат на тот или иной сервис в рамках Управления Уровнем Сервиса являются:

    • Шаг 1: Определение IT-сервисов и IT-систем

    • Шаг 2: Проведение классификации сервисов (Базовые, Подписные, Заказные) 

    • Шаг 3: Моделирование сервисов и систем в CMDB 

    • Шаг 4: Выбор сервисов и систем, которые будут указываться в счетах пользователя 

    • Шаг 5: Разнесение ИТ-сервисов, которые не будут присутствовать в счетах клиента, по другим ИТ-сервисам. 

    • Шаг 6: Определение методологии разнесения затрат для компонентных ИТ-сервисов.

    • Шаг 7: Определение единицы затрат для видимых пользователю сервисов на основе способа их использования




Легенда: 

    • HW = Оборудование SW = Программное обеспечение 

    • DB = Базы данных Docs= Документы, контракты, лицензии 

    • FTE = Выделенные людские ресурсы LOC = Здания 

Примечание: Вышеприведенная диаграмма показывает два полностью расцененных ИТ-сервиса, один из которых (Настольные системы) включается в счет клиента, а другой рассматривается, как компонентный сервис (Сеть)), и процент от его стоимости включается в общую стоимость сервиса настольных систем.

Задание к выполнению лабораторной работы:

  1. Изучите теоретический материал по лабораторной работе.

  2. Проведите расчет затрат на сервис для вашего выбранного объекта.

Лабораторная работа 4

ПРОЕКТИРОВАНИЕ ПРОЦЕССА УПРАВЛЕНИЯ ИНЦИДЕНТАМИ

Цель работы: проектирование процесса управления инцидентами в организации.

Краткая теория

На момент ввода в действие системы процессом «Управление инцидентами» в компании занимался ИТ-отдел [8], на рис. 1 в нотации IDEF0 представлена упрощенная модель этого бизнес-процесса в состоянии as-is. В качестве входной информации рассматриваются инциденты, выходной - устраненные инциденты и проблемы, которые передаются разработчику. Выполняет работы ИТ-отдел (механизм). На рис. 2 изображена декомпозиция процесса «Управление инцидентами». Процесс содержит следующие подпроцессы: регистрацию, назначение ответственных, диагностику, устранение инцидентов.



Рис. 1. Модель процесса «Управление инцидентами» в состоянии as-is


Рис. 2. Задачи процесса «Управление инцидентами» в состоянии as-is
Процесс управления инцидентами не автоматизирован в достаточной степени, не оптимизированы диагностика и процесс устранения инцидентов с точки зрения современной методологии ITIL и концепции ITSM.

Для решения проблемы предлагается использовать ITSM-систему 1с ИТИЛИУМ.

На рис, 3 представлена модель бизнес-процесса «Управление инцидентами» в состоянии to-be, т. е. после внедрения продукта ИТИЛИУМ, на рис. 4 изображена декомпозиция этого процесса. Рис. 5, 6 представляют собой декомпозиции бизнес-процессов «Работа 1 уровня» и «Работа 2 уровня» соответственно, реализованные в соответствии с положениями 1T1L.



Рис. 3. Модель процесса «Управление инцидентами» в состоянии to-be


Рис. 4. Задача «Управление инцидентами» в состоянии to-be



Рис. 5. Задача «Работа 1 уровня»


Рис. 6. Задача «Работа 2 уровня»
На рис, 4 представлена модель бизнес-процесса «Управление инцидентами» в состоянии to-be, т. е. после внедрения продукта ИТИЛИУМ, на рис. 4 изображена декомпозиция этого процесса. Рис. 5, 6 представляют собой декомпозиции бизнес-процессов «Работа 1 уровня» и «Работа 2 уровня» соответственно, реализованные в соответствии с положениями 1T1L .

Представленная модель to-be отображает произведенные изменения:

  1. Сотрудники ИТ-отдела делятся по уровням работ на специали­стов Service Desk, оказывающих поддержку при работе с инцидентами первого уровня, технических специалистов, работающих с инцидентами второго уровня, и экспертов, решающих инциденты третьего уровня. Такое разделение позволяет ускорить оказание помощи клиентам и снять излишнюю нагрузку с технических специалистов и экспертов.

  2. Появляется четкий регламент решения инцидентов SLA. Регла­мент организует работу подразделения и дает возможность более объективно оценивать работу сотрудников ИТ-отдела.

  3. Появление нескольких уровней позволяет оптимизировать работу ИТ-отдела, позволяя специалистам более высокого уровня решать соответствующие задачи.

  4. Создание отчетности становится отдельным бизнес-процессом, что дает руководству компании возможность получать объективную картину о происходящих инцидентах и процессе их решения.


Задание на лабораторную работу:


  1. Изучить теоретический материал.

  2. Определить организационную структуру ИТ отдела выбранного объекта исследования.

  3. Представить упрощенную модель (испоьзуя IDEF0) процесса управления инцидентами и проблемами в состоянии as-is.

  4. Представить упрощенную модель (испоьзуя IDEF0) процесса управления инцидентами и проблемами в состоянии to-be.

  5. Закрепить персонал ИТ отдела соответствующиму уровню Service Desk.

3) Оформить лабораторную работу в виде отчета и защитить у преподователя.
Лабораторная работа 5

Создание SLA соглашения
Цель работы: Создание SLA соглашения по выбранному объекту исследования.
Ход выполнения работы:

  1. Изучить пример приведенного в данной работе SLA соглашения.

  2. На основе созданного в лабораторной работе 2 каталоге ИТ-услуг составить SLA (OLA) соглашение сервисного обслуживания выбранного объекта исследования.





Соглашение об уровне сервиса между

ООО «АЛЬШАР» (пример)

и ЗАО «СИГИР»


ИСПОЛНИТЕЛЬ:

ЗАО «СИГИР»
Генеральный директор

_____________________

ЗАКАЗЧИК:

ООО " АЛЬШАР "
Генеральный директор

______________________



Санкт-Петербург,

2009
Содержание

ЛАБОРАТОРНАЯ РАБОТА №2 9

Классификация ИТ-сервисов 9

1.Классификация ИТ-Сервисов 9

Лабораторная работа №3 13

Разработка модели затрат на сервис. 13

Моделирование ИТ-Сервисов. 13

Разработка модели затрат, основанной на сервисах 15

Финансовое управление для ИТ-сервисов 15

1Общие положения 28

1.1Цель Соглашения 28

1.2Определения 28

1.3Контакты 29

1.3.1Контакты со стороны Поставщика 29

1.3.2Контакты со стороны Заказчика 29

2Срок действия соглашения 29

2.1Краткое описание 29

2.2Площадки 29

2.3Структура сервисов 30

2.4Обслуживаемые системы 31

2.4.1Аппаратное обеспечение 31

2.4.2Программное обеспечение 32

2.5Зависимость услуг Поставщика от третьих компаний 33

2.6Корпоративный стандарт на оборудование 33

2.7Обязательства Заказчика 33

2.8Права и привилегии персонала Заказчика 33

3Параметры обслуживания 34

3.1Рамки соглашения 34

3.2Временные параметры 37

3.2.1Время обслуживания 37

3.3Сроки удовлетворения запросов на изменения 37

4Процедуры обслуживания 38

4.1Способы обслуживания Заказчика. 38

4.2Реакция на запросы на обслуживание и инциденты 38

4.3Отчетность 39

4.3.1Автоматизированные отчеты 39

4.3.2Отчеты, создаваемые вручную 39

5Процедуры изменения соглашения 39

5.1Изменение соглашение 39

5.2Преждевременное завершение контракта 40

6Финансы 41

6.1Постоянная часть стоимости обслуживания 41

6.2Переменная часть стоимости обслуживания 41



  1.   1   2   3   4   5   6


написать администратору сайта