Как показывает опыт, любой проект или даже знакомство с организацией деятельности ИТ-служб в соответствии с рекомендациями ITIL начинается с вопросов. Как оказалось, все эти вопросы достаточно типичны.
Прежде всего определимся с часто упоминаемыми терминами, вызывающими путаницу. Управление ИТ-услугами (Information Technology Service Management, ITSM) – это сервисный процессный подход к организации работы ИТ-службы. Суть его в том, что вся деятельность ИТ-подразделения рассматривается в разрезе услуг, оказываемых им другим подразделениям в соответствии с соглашениями об уровне услуг. ITSM декларирует, что ИТ-отделом можно управлять, основываясь на тех же принципах, которые применимы к бизнес-подразделениям.
Библиотека ИТ-инфраструктуры (Information Techno-logy Infrastructure Library, ITIL) – это библиотека рекомендаций, обобщающая международный опыт по организации работы ИТ-департаментов и разъясняющая, что надо сделать для реализации подхода ITSM. ITIIL состоит из ряда книг, каждая из которых описывает тот или иной аспект деятельности в виде набора процессов. В настоящее время выпущена вторая версия ITIL, активно ведется работа над созданием третьей. В ITIL описывается, как должна быть организована деятельность ИТ-структур, но не приводятся конкретные шаги по внедрению содержащихся в ITIL рекомендаций. Конкретные методики внедрения ITSM на основе ITIL предлагают компании, которые специализируются на подобных проектах.
СМОТРИМ ДУДЯ и ТРОЯНОВУ (иногда треш)
Как объяснить бизнесу необходимость ITSM?
Этот и подобные вопросы вызвали немало дискуссий. Самый распространенный ответ такой: внедрение процессной модели в соответствии с рекомендациями ITIL позволит бизнесу исходить из собственных потребностей при оценке ИТ-услуг и уже в соответствии с ними планировать расходы на ИТ и определять ключевые показатели эффективности. Кроме того, повышается прозрачность ИТ для бизнеса, что вместо вкладывания денег в «черную дыру ИТ» приводит к прогнозируемому инвестированию в развитие ИТ как в серьезное подспорье для бизнеса и потенциал для развития новых конкурентных преимуществ компании. Такой ответ, как правило, хорошо принимается руководством компании.
Сотрудникам же бизнес-подразделений следует объяснить, что внедрение рекомендаций ITIL обеспечит им более качественное обслуживание, сокращение времени возможных простоев и перебоев, а также быстрое рассмотрение и реакцию на все без исключения обращения в ИТ-службу. У них появится уверенность в том, что каждое обращение будет отработано по принятым правилам в установленный срок.
Как получить финансирование на проект и оценить его окупаемость?
Для получения финансирования проекта по внедрению ITSM часто необходимы убедительные обоснования. В зависимости от конкретного случая это могут быть следующие три основных аргумента.
Повышение прозрачности и управляемости службы ИТ. На практике это означает, что информационные технологии становятся объектом управления с реальной финансовой отдачей. Этот тезис довольно часто требует более детального объяснения.
Что с IT в 2023? Про работу можно забыть? Анализ IT рынка
При внедрении основных процессов, описанных в ITIL (управление инцидентами, проблемами, конфигурациями, изменениями, уровнем обслуживания) происходит самоорганизация ИТ-отдела, повышается прозрачность его деятельности. Последующее внедрение процессов управления непрерывностью, мощностями и доступностью повышает защищенность бизнеса с точки зрения ИТ. Внедрение процесса управления финансами приводит к росту прозрачности финансовой деятельности ИТ-подразделения.
Увеличение эффективности и направление фокуса ИТ-деятельности на решение задач бизнеса. Внедрение даже ограниченного набора процессов ITIL (службы Service Desk и процессов управления инцидентами и уровнем услуг) позволит организовать работу ИТ-службы таким образом, что в центре ее внимания окажется именно бизнес. ИТ-отдел из «вещи в себе» превратится в ориентированную на потребности бизнеса внутреннюю сервисную структуру.
Возможность передать часть функций ИТ на аутсорсинг. В определенный момент может оказаться, что передача части функций ИТ во внешнюю компанию будет эффективнее, нежели их реализация имеющимися ресурсами. Например, в подавляющем большинстве случаев внешний сайт компании целесообразнее размещать у специализированного хостинг-провайдера, а не организовывать хостинг своими силами. При этом возникает ряд вопросов, касающихся взаимодействия компании, предоставляющей услуги аутсорсинга, с заказчиком таких услуг. В случае организованного процесса управления уровнем обслуживания будет легче создать формальные критерии и правила взаимодействия заказчика и исполнителя на основе соглашения об уровне услуг.
Дополнительным аргументом может служить ответ на вопрос об окупаемости проекта по внедрению ITSM. Стоимость решения заявки на этапе промышленной эксплуатации решения, состоящего из процессной части и настроенной системы автоматизации в случае, когда внедрена часть процессов ITIL, по сравнению с ситуацией, когда не внедрен ни один из процессов, в пересчете на единицу времени оказывается ниже. Таким образом, окупаемость проекта по внедрению рекомендаций ITSM может быть вычислена для каждой конкретной организации. В простейшем случае рассчитываются стоимости единицы рабочего времени специалиста каждой из линий поддержки до и после внедрения. Более сложный расчет учитывает стоимость возможного простоя сотрудников бизнес-подразделений, стоимость аренды помещений и т.д.
Следует ли затраты на ИТ распределять по бизнес-подразделениям и бизнес-пользователям?
Ответ на этот вопрос кроется в финансовой учетной политике относительно ИТ на конкретном предприятии. Если ИТ-отдел выделен как независимый центр затрат и прибыли (то есть является самоокупаемой организацией), то затраты на ИТ-услуги могут быть соотнесены с конкретным бизнес-подразделением. Подобная деятельность ведется, как правило, в рамках процесса управления финансами. В этом случае ИТ-служба и бизнес-подразделения становятся полноценными участниками внутреннего рынка ИТ-услуг.
На практике чаще встречается ситуация, когда затраты на оказание ИТ-услуг аккумулируются в ИТ-отделе. Она характерна для предприятий, где не внедрен процесс управления финансами, но присутствуют его элементы, например бюджетирование. При этом затраты на ИТ оплачиваются либо из специально созданного фонда, либо всеми бизнес-подразделениями совместно. Как правило, с ростом предприятия и ИТ-службы происходит постепенный переход от второй модели к первой, поскольку во втором случае даже при наличии распределения затрат механизм количественных оценок стоимости потребленных каждым конкретным подразделением услуг неочевиден и обычно заменяется системой пропорционального распределения затрат в зависимости от натуральных показателей, таких, как численность конкретного бизнес-подразделения или его вклад в общую прибыль компании. Ни количество, ни стоимость реально потребленных услуг при этом не учитывается.
С чего начать внедрение? Какие процессы внедрять?
Проект по внедрению рекомендаций ITIL, как и любой другой, связанный с управлением, следует начать с определения бизнес-требований и анализа состояния дел ИТ-департамента. Для анализа можно применять известные методики (например, Pink Elephant, HP ITSM) или самостоятельно составленные опросные листы. Как правило, дополнительно проводится анализ по бизнес-модели: делается описание того, как работает ИТ-отдел в данный момент, в виде связанной совокупности бизнес-процессов. Следует отметить, что такой анализ полезен даже в случае полной деструктурированности работы ИТ, поскольку помогает выявить внутренние зависимости и связи, опираясь на которые, можно будет спроектировать тот или иной процесс.
Одновременно с построением картины работы «как есть» проводится анализ бизнес-требований к ИТ-отделу на основе сбора и обобщения требований и ожиданий бизнеса от ИТ и возможностей ИТ-службы удовлетворить потребности бизнес-подразделений.
После того как сформировано представление о состоянии дел «как есть» и проанализированы требования бизнеса к ИТ, определяется состав процессов ITIL, которые будут внедрены, и очередность их внедрения. Другими словами, перечень процессов ITIL, которые необходимо внедрить в данной организации, вытекает из бизнес-потребностей предприятия.
Тем не менее практически всегда, когда проводится внедрение процессной модели управления ИТ на основе рекомендаций ITIL, в том или ином виде внедряют процесс управления инцидентами. Что вполне закономерно, поскольку именно этот процесс отвечает за взаимодействие пользователей и ИТ-службы, это своего рода интерфейс между ними. Второй процесс, практически всегда рекомендуемый к внедрению, — управление уровнем услуг. В его рамках непрерывно анализируются потребности пользователей и принимаются меры к повышению качества обслуживания.
Как установить соответствие между услугами, которые бизнес желает (или ожидает) получить от ИТ-подразделения, и ИТ-услугами?
Данная задача решается путем внедрения процесса управления уровнем услуг. Нужно выделить и описать те услуги, которые ИТ-отдел уже предоставляет. Затем надо определить ожидания бизнеса относительно этих услуг. После этого следует понять, какие услуги не вошли в число предоставляемых на данный момент ИТ-службой.
Из полученного обобщенного спектра услуг следует исключить несущественные и неосуществимые в текущий момент. Далее предстоит составить план улучшения услуг, с определением сроков и мероприятий, в рамках которых должна быть обеспечена трансформация ожиданий бизнеса в ИТ-услуги (другими словами, нужно определить время и технологию вывода новых ИТ-услуг на внутренний рынок).
Какие фазы внедрения ITSM существуют? Что влияет на его успешное завершение?
Классический проект по внедрению процессной модели в соответствии с рекомендациями ITIL действительно может проходить в несколько фаз. О первых трех из них (аудите ИТ-службы предприятия, определении бизнес-требований и ожиданий от ИТ, выявлении слабых мест в управлении ИТ-службой, определении состава процессов ITIL, подлежащих внедрению) мы уже рассказали.
Следом за реализацией этих фаз необходимо определить систему для автоматизации выбранных процессов. Результаты аудита и выбора процессов ITIL, а также средства автоматизации представляют руководству предприятия и сотрудникам ИТ. Наконец, после этого осуществляется последовательное внедрение каждого из названных выше процессов. Оно идет в несколько этапов: разработка технического задания или технических требований на внедрение процесса; описание внедряемого процесса; определение требований к системе автоматизации; описание настроек системы автоматизации; настройка системы автоматизации; опытная эксплуатация.
Успех проекта определяется несколькими факторами. Во-первых, он зависит от поддержки руководства предприятия: поскольку во время проекта практически всегда неизбежны столкновения интересов и структурные изменения, поддержка руководства может принести неоценимую пользу. Во-вторых, успех проекта зависит от профессионализма реализующей его команды. В-третьих, от того, как проект принимается сотрудниками ИТ-службы и бизнес-подразделений, то есть от того, насколько полно команда внедрения смогла донести цели и задачи проекта в целом, а также определить личностную мотивацию в рамках данного проекта для каждого конкретного сотрудника.
Обязательно ли организовывать Service Desk?
Внедрение службы Service Desk целесообразно по нескольким причинам. Большинство современных средств автоматизации предусматривает возможность регистрации инцидентов самим пользователем (посредством Web-форм, например). Однако пользователь порой не в состоянии квалифицированно определить суть инцидента. Но даже если он может провести самостоятельную классификацию, все равно требуется уточнение (или, как минимум, подтверждение) специалиста. Автоматизированный ввод инцидентов самим пользователем не отменяет механизма ввода и диспетчеризации оператором Service Desk, поскольку в ряде случаев пользователь просто не имеет возможности завести заявку (инцидент) для автоматической обработки (например, при отсутствии технической возможности доступа к интерфейсу Service Desk).
Наличие Service Desk обеспечивает единую точку входа. Это очень важно, поскольку отпадает необходимость выстраивать персональные отношения с ИТ-специалистами, и пользователь всегда знает, куда ему обратиться с проблемами.
При отказе от Service Desk более вероятно возникновение «очередей» заявок у высококвалифицированных ИТ-специалистов, которые будут совершенно неэффективно тратить свои ресурсы. Запуск же квалифицированной службы Service Desk позволяет спустя некоторое время разрешать до 70% заявок на первой линии благодаря накоплению базы знаний и другим преимуществам правильно организованных процессов. Это экономит время высокооплачиваемых специалистов, и они могут направить его для решения более важных задач. Оставшиеся 30% заявок маршрутизируются таким образом, что гарантируется их скорейшее решение.
При отсутствии службы Service Desk ее функции выполняет вся ИТ-служба.
Как оценить численность сотрудников Service Desk?
Количество операторов первой линии — нелинейная величина, которая зависит в основном от общего числа сотрудников компании, от их умения использовать информационные технологии, от характера их работы, а также от степени квалификации оператора.
В целом, исходя из накопленного опыта, можно утверждать, что на тысячу пользователей достаточно трех-пяти операторов Service Desk.
Нельзя ли обойтись при внедрении рекомендаций ITIL без автоматизированной системы?
Можно обойтись и без внедрения автоматизированной системы, аккумулируя информацию, необходимую для функционирования каждого конкретного процесса в электронных таблицах или бумажных журналах, и организуя документооборот с помощью электронной почты. Но это существенно снизит эффективность внедренных процессов. Кроме того, развитие ИТ будет постоянно тормозиться из-за низкой эффективности и больших временных издержек конкретных ИТ-процесса, что может негативно повлиять на качество процессов, связанных с основной деятельностью предприятия.
Если в компании уже есть система учета заявок, обязательно ли внедрять специализированный продукт для управления ИТ?
Все зависит от состава процессов, которые планируется внедрять, и от возможностей существующей системы. Если речь идет лишь о процессе управления инцидентами, то скорее всего, существующая система будет способна обеспечить его автоматизацию на каком-то уровне. А если в планах стоит, например, внедрение процессов управления финансами и активами, то вероятно придется переходить на специализированную систему, которая позволит автоматизировать эти процессы.
Может ли ITSM помочь при внедрении ERP (CRM и т.д.)?
Если в организации внедрен один или несколько процессов в соответствии с рекомендациями ITIL, безусловно, может. Служба Service Desk возьмет на себя ответы на запросы пользователей и регистрацию инцидентов, связанных с новой системой.
Эти инциденты будут разрешаться в рамках процесса управления инцидентами, анализироваться и использоваться для выявления проблем в рамках процесса управления проблемами. Разрешение инцидентов будет происходить путем проведения изменений в рамках процесса управления изменениями, а информация о конфигурации инфраструктуры будет постоянно актуальной вследствие работы процесса управления конфигурациями. Расчет мощностей, требуемых для внедрения новой системы, будет проведен в рамках процесса управления мощностями, в рамках процесса управления доступностью будут сформированы требования, удовлетворение которых обеспечит требуемый уровень доступности. В рамках процесса управления непрерывностью будет сформирован план обеспечения непрерывности для ERP-системы, финансы на приобретение требуемых серверов и поддержку программно-аппаратного комплекса формируются в рамках процесса управления финансами, мероприятия по обеспечению безопасности конфиденциальных данных в ERP будут обеспечены в рамках процесса управления безопасностью. Далее, имея организованную в соответствии с определенными регламентами службу ИТ, легче проводить планирование внедрения, поскольку при четкой организации деятельности ИТ повышается прозрачность и управляемость ИТ.
Отдельно следует рассмотреть параллельное внедрение ERP и ITSM. В этом случае вероятность успешного завершения каждого из проектов будет ниже, чем при последовательном внедрении. Дело в том, что и тот и другой проект относятся к так называемым «стрессовым» проектам, требующим перестройки как ИТ-службы, так и бизнес-подразделений. Таким образом, на время параллельного внедрения ERP и ITSM повышается нагрузка на сотрудников, возрастает неопределенность и влияние человеческого фактора, в итоге значительно повышаются риски подобного проекта.
Чем ITSM может помочь при организации аутсорсинга?
ITSM позволит организовать правильные отношения между поставщиком и потребителем аутсорсинговых услуг. Если эти отношения строятся на основе формального соглашения об уровне услуг, которое разработано и описано в рамках процесса управления уровнем услуг, то неважно, кто именно является поставщиком — внутренний ИТ-отдел или внешняя компания.
Обязательно ли использовать консалтинг при внедрении ITSM?
Порой проще и выгоднее использовать компанию-консультанта, имеющую опыт внедрения проектов, связанных с ITSM, чем создавать свою команду. Тем более что после завершения проекта наверняка возникнет вопрос, что будет делать его команда. Распущена? Переведена на другие проекты? Как правило, внедрение рекомендаций ITIL — это совместный проект с внешней компанией-консультантом.
Что будет, когда закончится проект?
Формальное окончание проекта совсем не означает, что проект завершен, поскольку в компании начинается ежедневная рутинная работа по улучшению качества обслуживания пользователей, обеспечению доступности и непрерывности ИТ-услуг, разрешению инцидентов, локализации проблем и т.д. Так что в широком смысле, однажды начавшись, проект по внедрению рекомендаций ITIL никогда не заканчивается.
Источник: www.osp.ru
BRMS
BRMS (от англ. Business Rule Management System — система управления бизнес-правилами) — информационная система, являющаяся интегральным компонентом информационной инфраструктуры компании и предназначенная для создания и использования модели, формально описывающей логику принятия решений (бизнес-логику) в виде системы бизнес-правил —- декларативных утверждений в терминах бизнес-пользователей, указывающих на выполнение некоторых действий в случае выполнения определенных условий.
Основные концепции
В отличие от традиционного подхода, когда бизнес-логика реализуется непосредственно в программном коде информационных систем, системы управления бизнес-правилами ориентированы на «человекочитаемое» представление бизнес-логики в виде совокупности описательных утверждений о предметной области (бизнесе), предназначенных для создания и поддержки бизнес-пользователями, а не ИТ-специалистами.
В общем виде бизнес-правило представляется в форме декларативного утверждения вида: Если (условия), то (список действий), иначе (альтернативный список действий).
Бизнес-правила в BRMS объединяются в блоки, представляемые в виде таблиц или деревьев решений.
Основными преимуществами использования основанных на BRMS служб решений по сравнению с традиционной моделью реализации бизнес-логики в непосредственно программном коде являются:
- повышение адаптивности и оперативности реакции информационной среды компании на изменения в стратегии бизнеса за счет вовлечения бизнес-пользователей в процесс управления бизнес-правилами;
- снижение затрат на адаптацию систем к изменившимся условиям бизнеса;
- повышение прозрачности логики принятия решений в компании и её аудита;
- возможность реализации системного подхода к управлению принятием решений в организации (СППР).
BRMS может служить как средством управления бизнес-логикой для отдельных приложений, так и основой служб решений, предоставляющих сервисы принятия решений на основе бизнес-логики для бизнес-приложений в рамках все информационной инфраструктуры компании, например, при использовании SOA.
Использование систем управления бизнес-правилами является важной частью системы управления принятием решений в организации (СППР).
Архитектура
Графический интерфейс редактора правил на примере JBoss Drools 4.0
Как правило, BRMS включает сервер исполнения бизнес-правил (Business Rules Engine), средства создания и редактирования бизнес-правил, их хранилище (репозиторий), средства анализа и тестирования бизнес-правил.
При этом существует несколько подходов к выполнению правил в рамках BRMS. Наиболее простым подходом является последовательное исполнение всех правил в системе. При изменении первыми правилами исходных данных, последующие имеют дело с измененными данными, при этом уже исполненные правила к данным повторно не применяются. Альтернативой последовательному исполнению является применение прямого логического вывода (индукции), учитывающего последовательность выполнения правил и их взаимозависимость на базе алгоритмов выбора, таких как RETE.
Средства создания и редактирования бизнес-правил, ввиду их ориентированности преимущественно на бизнес-пользователей, как правило, обладают помимо поддержки декларативного языка описания правил средствами графического их представления в виде форм описания условий, таблиц и деревьев решений.
Источник: www.tadviser.ru
Отслеживать бизнес-правила в ИТ-отделе?
Я ищу лучший способ отслеживать бизнес-правила как для разработчиков, так и для всех остальных (вспомогательный персонал / руководство) в среде запуска. Задача состоит в том, что наша бизнес-модель требует довольно много различных бизнес-правил, которые создаются в значительной степени на лету и развиваются органически после этого. После запуска этого проекта в течение 3+ лет у нас так много таких правил, что зачастую единственный способ быть уверенным в том, что приложение должно делать в определенной ситуации, — это найти модуль, отвечающий за этот процесс, и проанализировать его код. и комментарии. Это нормально, если у вас есть один разработчик, который создал все приложение с нуля, но каждый новый разработчик должен изучить почти всю кодовую базу, чтобы понять, как работает приложение. Еще большая проблема заключается в том, что нетехнические сотрудники даже не имеют такой возможности и поэтому вынуждены каждый день спрашивать меня, как конкретный случай будет обрабатываться приложением.
Быстрый пример — мы начинаем взимать плату за наши кампании для клиентов только после того, как они были активны в течение как минимум 72 часов, но в то же время мы прекращаем создавать счета для кампаний, принадлежащих неплатежеспособным учетным записям, и закрываем такие учетные записи в течение месяца после первого неудавшегося платежа., Это не относится к учетным записям, для которых установлено «бесплатное», что чаще всего принадлежит нам, поскольку мы сами пользуемся услугой. Счета создаются 1-го числа каждого месяца и включают расходы за предыдущий месяц + любой текущий баланс, который может иметь счет. Однако с некоторых клиентов взимается плата только через 4 дня после выставления счета-фактуры из-за проблем с отделом выставления счетов. В дополнение к этому счета-фактуры также создаются, когда клиент деактивирует свою кампанию, но это можно сделать только в том случае, если кампания не продлена по обязательному 6-месячному контракту, если только менеджер по работе с клиентами не одобрит досрочную деактивацию.
Я знаю, это довольно много правил, которые необходимо учитывать при ответе на вопрос «когда мы выставляем счет нашим клиентам», но на самом деле я мог бы добавить звездочку в конце каждого предложения, чтобы раскрыть некоторые редкие исключения, Конечно, было бы проще просто свести бизнес-правила к минимуму, но нам нужно адаптироваться к меняющемуся рынку — то есть меньше года назад у нас не было никаких контрактов.
Одна идея, которая у меня была до сих пор, была упрощенная вики с категориями, соответствующими таким областям, как «Активация учетной записи», «Выставление счетов», «Процедуры сбора» и так далее. Другой идеей было бы создание гигантской интерактивной блок-схемы, показывающей весь «жизненный цикл» клиента от поиска до деактивации аккаунта.
Каков ваш опыт / предложения?
Источник: stackru.com
