Файл: Лабораторная работа 1. Бизнесмодель итаутсорсинговой компании.docx

Объектная модель 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

---