ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

28.09.2024

Чем страшен ИИ, и с чем его едят

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2016 / Выпуск №10 (63) / Сервисный подход к ИТ: плюсы и минусы. Определение ИТ-процессов и их место в деятельности организации

Рубрика: ИТ-процессы

Марина Аншина, президент фонда ФОСТАС, председатель Комитета по стандартам Российского Союза ИТ‑директоров

Сервисный подход к ИТ: плюсы и минусы
Определение ИТ-процессов и их место в деятельности организации

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

Большой энциклопедический словарь (http://www.vedu.ru/bigencdic) определяет «процесс» так:

1. последовательная смена явлений, состояний в развитии чего-нибудь;
2. совокупность последовательных действий для достижения какого-либо результата (например, производственный процесс).
3. и то, что к теме нашей статьи совершенно не относится: порядок рассмотрения дел в суде, судопроизводство; судебное дело.

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

Относя эти определения к предприятию, стандарт ГОСТ ИСО 9000-2011 (ISO 9000-2005) предлагает такое определение: «Процесс – это совокупность взаимосвязанных ивзаимодействующих видов деятельности, которые преобразуют входы в выходы».

Само слово «процесс» произошло от лат. Processus, что означает «движение вперед», «продвижение», и может применяться к любому объекту и системе. В применении кпредприятию мы будем, естественно, использовать определение из ГОСТа. Любой процесс увешан множеством артефактов, основные из которых приведены на рис. 1.

Рисунок 1. Состав процесса

Уместно будет вспомнить про цикл Деминга – PDCA (Plan – Do – Check – Act, планируй – делай – проверяй – действуй), то есть планируй выполнение процесса – выполняй процесс в соответствии с планом – проверяй качество процесса – принимай решения по улучшению качества процесса и действуй, осуществляя их (см. рис. 2). Привожу рисунок исключительно потому, что недавно с удивлением обнаружила менеджеров, занимающихся управлением процессами, которые не имели о нем ни малейшего представления.

Рисунок 2. Цикл Деминга

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

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

Классики реинжиниринга бизнес-процессов М. Хаммер, Д. Чампи дают такое определение, уточняя, что же на входе и что на выходе процесса: «Бизнес-процесс – совокупность различных видов деятельности, в рамках которой «на входе» используется один или более видов ресурсов, и в результате этой деятельности «на выходе» создается продукт, представляющий ценность для потребителя».

ГОСТ Р 53114-2008 дает определение: «Процессы, используемые в экономической деятельности организации», так что хочется спросить: «А продажи и маркетинг неотносятся к бизнес-процессам?»

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

Но довольно определений, по крайней мере для начала. Давайте ближе к ИТ. Поскольку внятного определения ИТ-процесса мне найти не удалось, возьму на себя смелость сформулировать его самостоятельно.

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

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

Формирование процессного подхода к ИТ тесно связано с технологией ITSM (Information Technology Service Management) и библиотекой лучших практик ITIL (Information Technology Infrastructure Library), которые провозгласили и сформировали грамотное сервисное управление. Это, несомненно, позволило привести в порядок высокоинтеллектуальную и с трудом поддающуюся управлению область и совершенно логично следовало из повышения роли и статуса ИТ в организациях. Ведь если бизнес-процесс или его часть автоматизированы, то ценность создаваемого продукта или услуги компании напрямую зависит от работоспособности ИТ, а, следовательно, какой-никакой порядок наводить просто необходимо.

Я не буду повторять в этой статье основы ITIL, поскольку написано на эту тему предостаточно. И, надеюсь, что в большинстве компаний ITIL в основном внедрена и счастливо работает.

Давайте лучше немного поговорим о его величестве Сервисе.

В широком смысле слова «сервис» значит служить, то есть обслуживать, и происходит от латинского слова «servitum» (рабы, слуги). Когда формировался перевод этого термина на русский, ходили споры, как лучше переводить – «сервис» или «услуга».

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

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

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

• Спецификацию.
• Стоимость.
• Заказчиков и пользователей.
• Затраты на предоставление.
• Выгоды для заказчика.
• Архитектуру.
• Группу исполнителей.
• Полезность в виде удовлетворения потребностей пользователей.
• Параметры качества и способы их оценки.

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

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

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

Что же нужно нашим клиентам?

Спецификация

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

Рисунок 3. Удовлетворенность пользователей как пересечение их ожиданий с тем, что они получают от поставщика

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

Соответствие спецификации

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

Постоянство

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

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

Взаимодействие

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

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

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

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

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

Рисунок 4. Структура Information Technology Service Management

Если в первом варианте в центре событий находятся такие процессы, как

• Управление конфигурациями.
• Управление изменениями.
• то во втором:
• Стратегия развития сервисов.
• Непрерывное развитие сервиса.
• Отчеты и контрольные панели.

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

Не лучше обстоит дело и с ITIL. Вполне возможно, что мне, воспитанной на предыдущей версии, они ближе и роднее. Но, не причисляя себя к закоренелым консерваторам, явсе же рискну отметить, что в ITIL v2 было больше логики и пользы, чем в третьей версии (см. рис. 5).

Рисунок 5. Состав ITIL версии 2 и версии 3

Как вы видите, тут то же самое: движение в сторону стратегического управления и улучшения качества сервисов.

Небольшое отступление. Умеете ли вы вязать? Мне как-то довелось научиться. Конечно, первые опыты были далеки от совершенства: то рукава широкие, то длина неподходящая. Приходилось распускать и начинать заново. Моя учительница тогда сказала: «Ты точно научишься хорошо вязать, потому что не боишься распускать. А непытаешься какими-то искусственными способами скрыть свои ошибки».

Так что я уже давно научилась «распускать свитера», поэтому заплатки и пристройки вызывают у меня здоровый скепсис. Мне кажется, что роль ИТ настолько изменилась итак стремительно продолжает меняться, что нужно, учитывая и опираясь на более чем успешный опыт ITSM и ITIL, разрабатывать что-то новое.

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

1. Большого или, лучше сказать, огромного количества использующих сервис пользователей.
2. Разнообразия типов пользователей, прежде всего по уровню ИТ-грамотности.
3. Необходимости гибкого предоставления ИТ-сервисов, когда постоянство перестает быть обязательным условием, а качество сервиса, да и он сам, формируется «на лету» в зависимости от потребностей пользователя и возможностей поставщика.
4. Когда ИТ-активы не принадлежат компании-заказчику.
5. Когда предоставление сервиса осуществляется сложными цепочками аутсорсеров.

Боясь утомить читателя, не стану продолжать. Но и вышеперечисленного вполне достаточно, чтобы предсказать уже в ближайшее время значительные – можно употребить термин «тектонические» – сдвиги в области управления ИТ-сервисами и ИТ-процессами. Как это будет называться: продвинутый сервис, agile-сервис или еще каким-то термином, я незнаю. Предлагайте! Возможно, ваш вариант окажется лучшим.

На этом позволю себе откланяться. С предвкушением того, что нам еще предстоит много встреч. Вот вам преимущество цикла статей!

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи