Взаимодействие ИТ и бизнеса на основе itsm

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

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

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

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

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

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

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

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

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

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

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

Если в предоставлении услуг участвуют внешние поставщики, например, когда к службе Service Desk или к обслуживанию персональных компьютеров привлекаются внешние ресурсы, тогда Показатели качества определяются во Внешних Договорах. Это соглашение с внутренним ИТ-подразделением, в котором конкретизируются договоренности о предоставлении определенных элементов сервисов, например, доступности сети или доступности серверов печати. Например, если соглашение SLA содержит временные показатели в разрешении инцидентов с высоким приоритетом, то Соглашение OLA должно определять цели для каждого элемента цепочки поддержки параметры для службы Service Desk — время ответа на звонки, эскалация инцидентов и т.

Операционные Соглашения об Уровне Услуг помогают ИТ-организации в общем процессе предоставления услуг. Внешний Договор Underpinning contract — UC. Это договор с внешним поставщиком, который определяет договоренности по предоставлению конкретных услуг, например, поддержку рабочих станций или аренду линии связи.

Действие такого договора аналогично внешней реализации соглашения OLA. Во многих организациях ИТ-услуги предоставляет внутреннее ИТ-подразделение.

В этом случае соглашения SLA и OLA в большей степени представляют собой описание того, о чем договорились между собой внутренние подразделения, чем юридический документ.

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

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

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

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

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

Составление или обновление Каталога Услуг с указанием в нем доступных для заказчиков услуг;. Регулярное предоставление отчетов заказчику и ИТ-организации о реальных текущих Уровнях Предоставления Услуг в сравнении с общим достигнутым Уровнем Service Level Achievement. Возможно инициирование Программы улучшения сервиса, если это необходимо.

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

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

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

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

Для них необходимо распределить роли в процессе. Кроме того, встречаются ветвления и параллельные действия. Поэтому представление в виде маршрутов очень удобно. Блок-схемы используются для расшифровки логики действий команды. Матрица таблица анализа взаимодействия процессов позволяет выделить самые важные бизнес-процессы, установить их взаимосвязь и оценить степень влияния процессов на функционирование СМК. Анализ цепочки процессов обнаруживает, что обмен информацией идет между всеми подпроцессами.

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

Параллельно разрабатывается методология бизнес-моделирования, предназначенная именно для данной организации. На основании этой методологии выдвигаются требования к инструментарию — набору функциональных элементов одной или нескольких систем Aris, All Fusion, Microsoft Project.

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

Мы в рамках своих проектов, как правило, формулируем "соглашения о моделировании" и составляем глоссарий, содержащий термины, принятые в компании. Этот документ описывает, что в данном случае будет пониматься под процессом, подпроцессом, функцией, операцией и т.

Далее начинается совместная работа консультантов и заказчика по описанию бизнес-процессов. Самостоятельно, в отрыве от заказчика, консультант никогда не создаст живую модель бизнеса, — подчеркивает Борис Носков. Модель бизнеса "как есть" в рамках проекта может быть до конца не описана.

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

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

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

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

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

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

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

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

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

Агаева Т.А. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ - ОСНОВА РЕИНЖИНИРИНГА. БИЗНЕС-ПРОЦЕССОВ. В процессе перехода российской экономики к рынку стала очевидна необходимость появления новых ориентиров, новых механизмов и новых методов менеджмента, стимулирующих ускорение экономических преобразований. Многие российские предприятия оказались не готовы к коренным изменениям. В силу различных причин организации оказались не способными провести реструктуризацию производства и собственных финансовых обязательств перед кредиторами, привлечь инвесторов, внедрять новшества. Бизнес-процесс — это совокупность операций, совершаемых для решения одной из задач бизнеса. Основная цель современных специалистов ИТ — автоматизировать эти процессы без участия сотрудников. hooper в +1. Тогда становится важным описать деятельность ИТ-подразделения на основе принятой методологии для однообразного восприятия всех процессов организации. Отметим также, что при данном подходе хорошо просматривается стадийность этапов процессов, в том числе и при взаимодействии с процессами других подразделений. Используя этот подход, мы видим и описываем процессы сверху. Стоит отметить, что данный подход в полной мере соответствует методологии процессного подхода в управлении.  Во-вторых, в случае этого подхода взгляд на бизнес-процессы ИТ-подразделения - со стороны самого ИТ-подразделения, т.е. изнутри. Вы находитесь внутри механизма.

О двух подходах к описанию бизнес-процессов IT-подразделений

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

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

Таким образом, измерение и оценка ИТ-процессов выполняются в интересах двух основных групп заинтересованных лиц stakeholders:. Для обеспечения потребностей в измерении и оценке в системе управления ИТ создаются необходимые инструменты — разрабатываются метрики и KPI, реализуются средства сбора и обработки информации о процессах, определяется необходимость привлечения аудиторов и критерии оценки, которые они применяют.

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

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

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

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

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

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

Результативность процессов обеспечивается за счёт использования ресурсов организации, расходуемых на исполнение процессов и обеспечение их зрелости.

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

Основной принцип обеспечения и оценки рациональности системы управления можно сформулировать так: Метрики продуктивности характеризуют объём работ по исполнению и контролю процесса.

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

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

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

Описан процесс выбора стандарта для решения конкретной задачи. В третьей практической главе описывается организация процесса создания моделей и регламента бизнес-процесса производства программного обеспечения в компании.

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

Posted Ноябрь 23rd, by admin.

Основой стандарта. COBIT являются 34 высокоуровневые цели контроля, по одной на каждый ИТ- процесс, которые сгруппированы в 4 домена. 23 нояб. г. - Разработка регламента бизнес-процесса производства IT компании с главеописываются предпосылки, которые служат основой для. 28 сент. г. - взгляд на бизнес-процессы IT-подразделения — со стороны самого предоставляет, на наш взгляд, хорошую основу для этого.

Найдено :

Случайные запросы