Портал №1 по управлению цифровыми
и информационными технологиями

Услужливый подход

Опубликовано 26 марта 2011
Рубрики: ITSM, SLA, SLM, BRM, Обо всём на свете
Комментарии

Многие компании освоив первый столп ITIL — процессный подход начинают задумывать о втором — сервисном подходе.

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

Можно ли про такие компании сказать, что у них работает сервисный подход или чего-то не хватает? 

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

Также по теме:

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

Комментариев: 63

  • Александр Жилинский

    Можете забрасывать меня камнями — но я не вижу для большинства организаций в РФ, находящихся на начальном уровне развития (читай базовые процессы — inc, req, chg), так вот — не вижу никакой проблемы в бизнес-каталоге ИТ-услуг, сформированном на основании систем ИТ. Гораздо больше проблем появляется, когда такой организации начинают «по книжке» в глотку запихивать каталог услуг ИТ, с девизом «авось, переварится».

    • Евгений Шилов

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

      Вопрос на самом деле был в другом. Попробую переформулировать:

      Какие виды деятельности, достижения или «артефакты» (например, каталог сервисов) обязательны для того чтобы начать говорить о сервисном подходе в организации?

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

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

      • Вадим Уваров

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

        Вторая предпосылка — опять же осознание и опять же обеими сторонами что любая деятельность (т.е. услуги), «переходящая» эту границу стоит денег, а также желание регулировать объем получаемых услуг в том числе и путем регулирования их оплаты. IMHO «лидером» в таком осознании является бизнес, т.е. пока он не прочувствует что он должен платить и не заставит (или в крайнем случае побудит) ИТ обеспечить нужный объем услуг (с точки зрения содержания).

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

        • Евгений Шилов

          «пока он не прочувствует что он должен платить и не заставит (или в крайнем случае побудит) ИТ обеспечить нужный объем услуг (с точки зрения содержания)».

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

          • Вадим Уваров

            ну ОК, «платить» в бытовом смысле необязательно. Правильнее было сформулировать «приобретать», «получать», «соблюдать правила получения услуг» наконец :о))

      • Олег Скрынник

        «Какие виды деятельности, достижения или «артефакты» (например, каталог сервисов) обязательны для того чтобы начать говорить о сервисном подходе в организации?»

        Я вопрос понял так же.

        Поэтому есть предложение.

        Жень, по итогам дискуссии, когда настанет время — сформулируй её итоги, а? К чему мы придём?

        Занятный список может получиться.

      • Олег Скрынник

        «обязательно взаимодействие с бизнесом для выявления его потребностей» — думаю, что это не обязательное условие.

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

        • Евгений Шилов

          А только ли выявление потребностей важно во взаимодействии с бизнесом? И на каком этапе?

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

    • Вадим Уваров

      Александр, а как же следующее:

      «Формируя каталог услуг, нужно отталкиваться от потребностей заказчика. Заказчику не нужна система XXX, ему нужна, например, автоматизация продажи билетов или управления складом, а такая трактовка услуги уже гораздо более понятная, емкая и измеримая» ?

      • Александр Жилинский

        Вадим,

        а я это (второе, т.е. здесь, у Евгения) специально написал. Я жажду бурной дискуссии на эту тему, у меня переосмысление идет 8)))

        • Вадим Уваров

          Дело в том, что услужливый подход — это всего лишь способ взаимодействия заказчика и поставщика, скажем так, по аналогии с химчисткой: можешь получить что-то только из того перечня, который предлагается поставщиком (почистить или постирать) + возможные комбинации из того же набора (и почистить, и погладить).

          Так вот ключевым пунктом, по-моему, является соглашение об содержании взаимодействия, т.е. составе и содержании услуг. Если они устраивают стороны — то все ОК. В Вашем провокационном примере (система = сервис) на начальном уровне зрелости просто не требуется большего: одни скорее всего не знают как и чего хотеть еще, а другие возможно не знают как это организовать. В итоге имеем некую гармонию (как в семье :о))): немного неудобно, зато привычно и понятно, так что можно потерпеть.

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

          Поэтому в целом такой вариант (система = сервис) — вполне возможен и даже жизнеспособен в определенных пределах и при определенных условиях. Вопрос только в контроле качества: что будет делать бизнес, если что-то не вытанцовывается, но с системами все в порядке? Вспоминается Райкин: «Ребята кто шил костюм? — МЫ!» (тоже, кстати, про сферу услуг)

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

          Потом уже возникнет необходимость перестроить взаимодействие между сторонами, предложив для него другую основу — услуги. Но для этого нужно будет дорасти — созреть... Потом созреть до более эффективного управления этими услугами... ну и так далее...

          • Александр Жилинский

            Вадим, Олег (сразу обоим, т.к. суть ответа — едина).

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

            • Вадим Уваров

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

              Тем не менее, не отрицая нужность и поддержки тоже, воскликну: «Не поддержкой единой!».

              • Евгений Шилов

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

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

                А вот определять продукт (ИТ-услугу) можно по-разному: идти от ИТ-систем, наверное проще всего, при этом для пущего упрощения жизни, ИТ-системы можно объединять в одну ИТ-услугу руководствуясь различными принципами.

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

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

                • Вадим Уваров

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

                  • Евгений Шилов

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

                    • Вадим Уваров

                      Очевидный минус такого подхода — подстава с уровнем сервиса: если одна из систем не работает, то формально уровень сервиса падает, хотя с помощью второй в той или иной мере конкретные бизнес-задачи могут быть решены, т.е. де-факто уровень не нарушен. Аналогия с двумя принтерами (большого формата и не очень) на подразделение: документ на А4 можно напечатать на обоих, а А3 — только на одном (опция для услуги печати документов).

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

                      Ну а специально для юристов пусть так и будет (2 системы — 1 услуга). Кстати, юристы — отличный полигон для внедрения сервисного подхода: требований немного, ограниченный перечень услуг, понимают формальный язык, не могут обоснованно придраться к качеству услуг :о)))

                • old fuddy-duddy

                  «В итоге, соглашусь, что ключевым моментом является наличие взаимодействия ИТ и бизнеса (умение слышать друг друга)»

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

                  • Евгений Шилов

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

                    — на этапе создания/модификации ИТ-услуг

                    — в ходе эксплуатации ИТ-услуги

                    Для этого мы обеспечиваем:

                    — привлечение ИТ, включая людей отвечающих за эксплуатацию на этап проработки требований бизнеса к новой/модифицируемой ИТ-услуге

                    — регулярные встречи представителей/представителя ИТ с представителем/представителями бизнеса.

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

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

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

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

                    • Олег Скрынник

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

                • Олег Скрынник

                  «Дело точно не в названии. А в понимании того, что ИТ предоставляет бизнесу, в чем ценность повседневной работы ИТ-специалистов для бизнес-процессов.»

                  «ключевым моментом является наличие взаимодействия ИТ и бизнеса (умение слышать друг друга)»

                  Ой. Красиво сказано, но согласиться не могу.

                  Для примера откроем стандарт ISO 12207 — «Процессы жизненного цикла программных средств». В нём много сказано про ИТ, про процессы, и почти ничего — про услуги (если только не включать фантазию и не додумывать за авторов стандарта). Основные процессы жизненного цикла ПО включают: Заказ, Поставка, Разработка, Эксплуатация, Сопровождение. Вспомогательные процессы: Документирование, Конфигурация, Решение проблем, Качество и контроль. Орг.процессы: Управление, Создание инфраструктуры, Совершенствование, Обучение.

                  Многие из перечисленных процессов направлены на (или подразумевают) взаимодействие с бизнесом. Понимание бизнес-процессов. Стремление их обеспечить наилучшим образом. Умея слышать друг друга. Как регулярная, повторяемая и контролируемая деятельность.

                  Услуги уже появились или пока нет?

                  Я не про то, что в каком-то стандарте что-то там сказано. Я про то, что можно прекрасно взаимодействовать без всяких ИТ-сервисов. Нет?

                  • Евгений Шилов

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

                    При этом общая картина предоставления ИТ-услуги может быть не видна.

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

                    Олег, а у тебя какая картина мира в голове?

                  • Уваров Вадим

                    Нет, не появились. Откуда им взяться?

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

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

                    Другой пример?

    • Олег Скрынник

      «...не вижу никакой проблемы в бизнес-каталоге ИТ-услуг, сформированном на основании систем ИТ» — трудно не согласиться.

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

  • Александр Жилинский

    А я с трудом могу сформулировать сервисный подход на практике. Что-то вроде «пытаемся мерять конечный результат деятельности, а не ее составляющие».

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

    • Анатолий Павлюченко

      Как объективно и достоверно определить, что «человек по сервису» «умеет работать с заказчиком»?

    • Евгений Шилов

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

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

    • Олег Скрынник

      «ясным индикатором сервисного подхода в организации является наличие четко выделенного человека по сервису» — как-то маловато...

      Представим себе ИТ-подразделение «совсем без сервисов». Есть набор больших и не очень ИТ-систем. Назначить по каждой системе одного-двух бизнес-аналитиков — вполне понятная и привычная ситуация. Они будут переводить программистам с «бизнесового» на «айтишный» и наоборот. Появились ли вслед за назначенными ответственными соответствующие ИТ-сервисы? Вроде пока нет.

      • Евгений Шилов

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

      • Александр Жилинский

        Это не бизнес-аналитик, это скорее аккаунт

  • old fuddy-duddy

    Думается мне, что не в атрибутах дело. Вот, например, есть каталог услуг, есть SLA, есть средства контроля и даже практически есть «выделенный человек по сервису», но нарушение «установленных для себя же нормативов» (и не на проценты, а в разы) вообще никого не волнует. Правда в приведенном примере в организации отсутствует пачка бумаги под названием «Процесс управления уровнем услуг» (или что-то в этом роде), но что-то мне подсказывает, что появление такой бумаги само по себе не очень поможет. Может «Дух сервисного подхода» вызывается как-то иначе?;)

    • Анатолий Павлюченко

      Перефразирую: Для подтверждения сервисного подхода необходимо и достаточно наличие хотя бы одного довора о предоставлении сервиса (SLA) и соблюдения условий этого договора всеми сторонами-участниками. Всё, точка.

      • Евгений Шилов

        А что нужно для «наличия» и «соблюдения»? 🙂

        • Анатолий Павлюченко

          😀 Ну, всё же, «наличие» документа (SLA) уже говорит само за себя. В этом документе должны быть описаны все необходимые атрибуты _сервиса_ и специфика взаимоотношений, включая процедуру проверки «соблюдения».

          Ну, а если всё есть, а «соблюдения» нет, тогда да, бубен в руки и ...

          Там ещё ниже немного напишу.

          • Вадим Уваров

            а не будет точнее — «наличие формализованного соглашения»? документы, как отметили выше, дело муторное.

            • Анатолий Павлюченко

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

              • Вадим Уваров

                IMHO зависит от того, что это за стороны. В простых случаях печати точно не нужны :о)))

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

                • Анатолий Павлюченко

                  Вот мы и добрались до культурных различий. Постсоветская крылатая фраза «Вам шашечки или ехать?!» очень хорошо описывает наш случай. Мы пытаемся натянуть чисто «западный» подход (ITSM) на реалии «нашего городка». Для адептов «шашечек» вопрос о «соблюдении» даже не стоит — законопослушание у них в крови. А любители «процесса» каждый раз мучаются вопросом — что делать, если кто-то не выполняет обязательств? Да, есть уже ответ: «В суд!»

                  А то в последнее время что-то зачастили обсуждения различных аспектов применимости ITSM на постсоветском пространстве и изобретения ex-soviet ITSM версий. Другими словами, «соблюдение правил и обязательств» — это не вопрос ITSM.

                  • Вадим Уваров

                    не согласен

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

              • Александр Жилинский

                И без документов все работает, сам видел 8)

                Может быть, не самым эффективным образом, но работает. Люди и взаимоотношения иногда для сервиса делают больше, чем правильные бумаги!

                • Евгений Шилов

                  Соглашусь с Александром, наличие документов точно не главное. Без них работает, а их наличие не гарантирует, что заработает.

                  И возможность «пойти в суд» тоже, мне кажется, не есть двигатель в данном случае.

      • Олег Скрынник

        «Для подтверждения сервисного подхода необходимо и достаточно наличие хотя бы одного договора о предоставлении сервиса (SLA) и соблюдения условий этого договора всеми сторонами-участниками. Всё, точка»

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

        Аналогично могу представить обратное, правда пока примера компании в голове нет. Нужно поискать 🙂

        Так что я не согласен, что SLA — необходимое и достаточное условие.

        • Анатолий Павлюченко

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

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

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

    • Евгений Шилов

      Пост надо было так и назвать «Как вызвать дух сервисного подхода. Секреты ITSM шаманов». 🙂

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

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

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

      • Анатолий Павлюченко

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

      • Николай

        Похоже, заклинание для вызова духа найдено 🙂

        «Взаимная заинтересованность сторон» — и только она.

        Можно разве что попробовать расшифровать — заинтересованность в чём?

        Например: «услужливый подход — это заинтересованность всех сотруднков ИТ в удовлетворенности бизнеса от использования ИТ».

        Странно кстати, что никто из уважаемых авторов тут про ABC не вспомнил — это именно оно и есть: attitude, culture and behaviour.

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

        Одно настораживает — по ходу дискусии под видом услужливости были попытки «продать» коммерциализацию ИТ. Я имею ввиду такие «качества» как:

        (1) наличие границы — вот здесь «наше»...

        (2) осознание что услуги стоят денег

        (3) ... наличие хотя бы одного SLA и [его] соблюдения

        и т.п.

        Это как мне кажется про то, о чём говорил выше Олег:

        «то же самое может происходить и без сервисного подхода» и «можно прекрасно взаимодействовать без всяких ИТ-сервисов».

        Действительно, коммерчески эффективное предоставление услуг с соблюдением всех формальностей в виде SLA, отчетов и т.п. вполне может происходить и без сервисного подхода — это когда utility получаем, а с warranty (в форме нормального отношения) плоховато.

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

        • Вадим Уваров

          Тогда вопрос: чем «сервисный подход» будет отличаться от «несервисного»? Правда, интересно.

          IMHO ведь до широкого распространения сведений об ITIL ИТишиники как-то работали и их деятельность все равно была направлена на обслуживание ИТ-систем, используемых потребителями (скажем бизнесом). Разве что-то изменилось, кроме слов «а давайте назовем это услугами»?

          • Николай

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

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

            Несервисное ИТ — это когда «деятельность направлена на обслуживание ИТ-систем», а как известно самая бесперебойная система — в которой ничего не меняем и никого к ней не подпускаем.

            Несервисное ИТ — это когда буква СЛА важнее для ИТшника, чем ситуативная потребность бизнеса.

            Несервисное ИТ — это когда просьба бизнеса «нарисовать в отчете треугольный куб» воспринимается как тупость и ламерство, а не как творческий вызов.

            В общем, несервисное ИТ — это когда в головах нет правила «Customer is a King».

            • Вадим Уваров

              Подождите-подождите, какое SLA? подход-то «несервисный», следовательно нет услуг и их атрибутов и характерных для сервисного подхода сущностей. Тем более, что Вы сами определяете как «обслуживание систем». Как это «обслуживание» и «несервисный»? Непорядок, знаете ли? Нужно другой термин как минимум использовать вместо «обслуживания» :о)))

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

              • Николай

                Вадим, я именно об этом и писал: от того, что организация использует СЛА, она не становится сервисной по духу. Сервисный подход может быть без СЛА, а может быть со СЛА — не сервисный.

                Речь о том, что «характерных для сервисного подхода сущностей» нет и быть не может, поскольку услужливость — это дух, а не буква...

                • Уваров Вадим

                  Если кратко, то тоже не соглашусь. SLA — это форма.

                  Но вот как все-таки отличить «дух» от «недуха»? Ведь когда Вы выбираете химчистку или **** или еще что-нибудь «услужливое» — няню, например. Вы руководствуетесь вполне конкретными требованиями и критериями. Пусть даже забудем про цену (хотя в бытовом смысле это важно). Эти требования и критерии описывают для заказчика существо и качество услуги, они составляют некое ее видение. Исполнитель предлагает свое. Если сошлись, договорились — заказчик получает то-то и то-то на таких-то условиях. Если нет — заказчик пошел искать другую «химчистку» или «няню».

                  • Николай

                    Вы меня реально удивили... неужели Вы действительно выбираете няню по формальным требованиям и критериям?! Бедный ваш ребёнок... 🙁

                    Даже при выборе гостиницы большинство известных мне людей почитают сперва отзывы на booking.com или ещё где. Эти отзывы (в отличии от «звёзд», парковки Wi-Fi и прочая) как раз и есть показатель довольства потребителей услуг.

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

                    • Вадим Уваров

                      :о)))

                      тут опять путаница в терминах. Не «формальных», а «конкретных», например «не слишком старая», «с правильным выговором» и т.п. Да и в рекомендациях не всегда такое напишут. Также и с отелем... вот если бы еще туроператоры дошли до предоставления подобной нешаблонной информации...

                      А няни у моего ребенка нет :о)))

  • Олег Скрынник

    Интересную тему Женя поднял. Непростую.

    На вскидку в голову приходит следующее: сервисный подход, в моём понимании, означает минимум две важные вещи. Во-первых, разделение «что» и «как». Об этом очень хорошо рассуждает тов. Майстер, если кто читал. В частности — книга «Управление фирмой, оказывающей профессиональные услуги», глава «Качественная работа не означает качественного обслуживания».

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

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

  • Дмитрий Исайченко

    Сервисный подход оказался как тов. Нетте — и человек, и пароход. Действительно, есть (как минимум) два измерения: формальное и культурное.

    Формальное — есть две стороны, одна для другой что-то делает, чем-то помогает. Открываем ГК РФ — такое взаимодействие может в зависимости от вида результата трактоваться как выполнение работ или предоставление услуг. Если так, то есть два атрибута сервисного подхода: 1) результат не должен иметь материального выражения (осязаемого продукта) и 2) взаимные права и обязанности заказчика и исполнителя должны быть определены в договоре возмездного оказания услуг. Если ИТ-организация — внутренняя, второй артефакт уходит (по крайней мере в юридически-значимом смысле, хотя может быть SLA) и остается только первый, который грубо проводит черту между проектами (создание чего-то нового) и услугами (помощи в текущей жизни).

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

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

    P.S. Но согласитесь, что, являясь потребителем услуг, нам всем очень хотелось бы работать с поставщиками, которые думают не только о формальной стороне вопроса 😉

  • Олег Скрынник

    Ну вот.

    Пришёл Дима и всех развёл.

    • Евгений Шилов

      И не говори 😉

      • Роман Журавлёв

        После того, как он пришёл, вроде неприлично тоже влезать, ну да когда нас это останавливало...

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

        Во-вторых, мне кажется, что если нам так уж нужны _формальные_ критерии наличия сервисного подхода (у провайдера), то они таковы:

        — сервисы идентифицированы

        — для каждого сервиса определен владелец

        — сервисы специфицированы, и критерии их качества коммуницированы всем заинтересованным сторонам

        — выполняется систематическая деятельность по оценке качества сервисов и актуальности спецификаций

        — измеряется удовлетворенность потребителей качеством сервисов и взаимодействием с провайдером

        — по итогам двух предыдущих пунктов ведется работа по совершенствованию.

        То есть признаки сервисного подхода — это признаки зрелой деятельности по управлению сервисами.

        Очевидно, что для применения этого «во-вторых» важно определить, что такое сервис. Здесь мне кажутся важными два соображения:

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

        2. Обязательна ориентация на пресловутую ценность, или, «как это я называю», пользу. В сервисном подходе поставщик старается управлять не только и не столько outputs своей работы, сколько ее outcomes для заказчика. Переведем это, например, как «выходы» и «результаты» (или как «результаты» и «ценность»).

        В итоге получается следующее:

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

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

  • Сериктай

    Спасибо, ребята, за весьма полезный обмен мнениями.

    Уложили в голове то, что там бродило ... 🙂

    Возможно, нужно еще добавить, в SLA должны описываться критерии, интересующие клиента, понятные ему и измеримые им.

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

     

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.