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

Вопрос из зала: строим каталог в терминах бизнес-услуг

Опубликовано 2 марта 2016
Рубрики: SLA, SLM, BRM, Вопрос из зала
Комментарии

В редакцию портала Real ITSM поступил вопрос:

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

Сейчас каталог услуг сформирован в терминах приложений: «Доступ к ПО ZZZ», «Доступ к ПО YYY» и т.д.
После прочтения некоторой литературы и посещения курсов по ITIL Foundation пришло чёткое осознание что каталог необходимо пересмотреть и сформулировать в терминах бизнес-услуг.
По части каталога, касающейся поддержки пользователей, управления ролями и доступом вопросов не возникает, там всё понятно и очень просто формулируется в терминах бизнес-полезности.
А вот что делать с собственно ПО пока понимания нету.

Вижу следующие варианты решения данного вопроса:

  1. Оставить как есть – сформулированные в терминах приложений (проблема: каждый вид ПО охватывает достаточно большой диапазон деятельности. Виды ПО: CRM, FRM, ERP, HRM)
  2. Разбить по автоматизируемым бизнес-процессам (проблема: многие процессы не описаны и брать из головы их названия как бы не очень правильно)
  3. Разбить по подразделениям (или рабочим местам) (проблема: в различных отделах могут пользоваться одной и той же функцией + в рамках одного отдела может быть несколько уникальных ролей и наборов прав доступа)
  4. Разбить по функциональным блокам ПО (проблема: документирование сведений о релизах и CMDB ведутся не больше года, большой кусок архитектуры систем не описан)

Вот так вот весело.

Буду очень рад любой помощи в формулировании правильного бизнес-ориентированного каталога услуг.
Сам склоняюсь к варианту №2, но опять-таки, отсутствие во вменяемом виде хотя бы списка всех бизнес-процессов (про менеджеров БП даже не упоминаю) всё очень сильно осложняет.

Заранее спасибо.

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление уровнем услуг и каталогом услуг
Разработка каталога, SLA, метрик качества, расчёт доступности

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

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

  • Игорь Смирнов

    Игорь Смирнов

    А древний индейский ритуал “На*уа?” уже проведен? Кого и по какой именно причине не устраивает существующее положение вещей? Ответ: “Не по феншуй” не принимается…

    • Dmitry Korolev

      Dmitry Korolev

      Игорь, вопрос риторический, ответ известный (консультантов)

  • Игорь

    "После прочтения некоторой литературы и посещения курсов по ITIL Foundation пришло чёткое осознание что каталог необходимо пересмотреть и сформулировать в терминах бизнес-услуг."

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

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

      Интересно. Почему?

      • Игорь

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

         

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

          В рамках данного кейса потребность бизнеса или производства в реализации изменений не формализована, следовательно, потребности такой нет, либо она не выявлялась

          Ни в коем случае не спорю с необходимостью постановки задачи. Но мне кажется, что из представленного текста выводы об отсутствии задачи не следуют. Корректнее, наверно, сказать, что нам (читателям) это пока неизвестно.

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

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

    • Nargiza Suleymanova

      Можно я немного вмешаюсь в разговор двух интереснейших участников?

      ИМХО, у автора вопроса, как и у многих специалистов, занятых проектами ITSM (а том числе у меня), было много болячек в текущей реализации, они скапливались понемногу, времени и ресурсов решать их не было, потому что все силы уходили на операционку. И вот ты читаешь полезный материал в сети/слушаешь вебинар/проходишь курс и тут внезапно находится РЕШЕНИЕ. Мне кажется, автор понял, что его болячки могут быть решены как раз при помощи каталога в терминах бизнес-услуг. Почему бы и не да? 🙂

  • Игорь

    "Есть вполне серьезные люди, полагающие, что посещение курсов, напротив, должно становиться причиной изменений."

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

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

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

      А Вы априори исключаете возможность, что такой анализ мог быть проведен до приобретения курса? И что сам факт похода на курс явился результатом этого анализа, а не случайным стечением обстоятельств?

  • Игорь

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

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

      Как я и писал выше, я считаю, что у нас об этом пока нет информации.

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

      • Игорь

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

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

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

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

          Но ведь не сами новые знания причина изменений!?

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

          • Игорь

            Дмитрий. Причина = неэффективность, Факт ее (неэффективности) наличия должен быть. Если есть только знания, но факта неэффективности нет, то ни о каких изменениях речи быть не может. Задача автора – формализовать в чем неэффективность. Он этого не сделал. А лишь сообщил, что согласно неким скрижалям – должно быть иначе.  Не совсем понимаю смысл дальнейшего спора?

  • Игорь

    Внедрение ЛЮБОГО процесса ради факта наличия процесса – несусветная глупость.

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

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

    1. Как можно подойти к решению задачи формирования каталога ИТ-услуг в терминах бизнес-процессов, описано в статье http://www.cleverics.ru/ru/subject-field/articles/627-service-actions-method.

    2. НО. Прежде, чем создавать какой-либо каталог, важно определиться, для решения каких задач Вы его собираетесь использовать. В зависимости от задачи, Вы придете к разным вариантам построения каталога (а может быть, придете к выводу, что Вам вообще не нужен каталог или нужен не каталог). Подробнее об этом есть в статье http://www.cleverics.ru/ru/subject-field/articles/630-service-catalog-approaches.

  • Альберт

    Если подходить к задаче комплексно, то нужно использовать 1,2,3,4 и ещё много чего. Т.е. отношение должно быть многие ко многим. Начните с критичных для бизнеса приложений, установите взаимосвязи, определитесь с уровнем детализации.

  • Андрей

    Коллеги, добрый день.

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

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

    1. Показать руководству полезность отдела (в условиях жёсткой экономии и сокращения расходов на IT)

    2. Дать пользователям понятный перечень услуг, которыми они могут пользоваться.

    3. Описать структуру затрат в разрезе, понятном финансовой службе.

    4. Описать SLA (описанные SLA в таких терминах приводят к тому что при нарушении одного из компонентов системы, даже самого маленького, мы получаем инцидент вида "не работает вся система").

    Это если в кратце.

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

    Всем откликнувшимся заранее спасибо.

     

     

  • Игорь

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

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

    Теперь по остальными пунктам.

    1. Показать руководству полезность отдела (в условиях жёсткой экономии и сокращения расходов на IT)

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

    2. Дать пользователям понятный перечень услуг, которыми они могут пользоваться.

    Сама по себе задача полезная при наличии такой потребности у пользователей. Они хотят это знать?

    3. Описать структуру затрат в разрезе, понятном финансовой службе.

    Тоже полезная вещь, но одним каталогом услуг она не решаема. 

  • Игорь

    4. Описать SLA (описанные SLA в таких терминах приводят к тому что при нарушении одного из компонентов системы, даже самого маленького, мы получаем инцидент вида "не работает вся система").

    Это задача из разряда построения модели здоровья и детализации SLA. Опять же только краем касается процесса управления каталогом услуг. 

  • Игорь

    Итого получаем следующую картину. 

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

    В такой ситуации доказать свою полезность можно единственным способом – постараться включиться в процесс обсуждения способов сокращения и аргументированно отстоять важные ДЛЯ БИЗНЕСА позиции, согласившись пустить под нож или предложив альтернативу для второстепенных направлений.

     

    • Андрей

      Игорь,

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

  • Андрей

    Я видимо несколько припозднился, но добавлю свои 5 копеек:))

    1. Есть принципиальная разница между Design и Operations. Если вы хотите построить единый каталог(а это нормально и по-человечески в отношении пользователей) то услуги из области Operation и Design надо разделить по разным разделам, поскольку принципиально разные процедуры согласования, SLA и т.д. Т.е. в каталоге будет отдельный раздел – разработки/доработки. Внутри раздела можно ввести отдельное деление но с этим будут проблемы – очень часто необходимые доработки выходят за рамки одной системы и одного бизнесспроцесса. На пример – консолидированный отчет из нескольких систем. Если совсем по-хорошему, то заявка на доработку/разработку из каталога должна уходить в PPM и уже от туда приходить в Operations в виде конкретного Chage Order.

    2. Я не разделяю вашего оптимизма по поводу простоты "управления ролями и доступом вопросов не возникает". На самом деле это та еще задачка. К сожалению Роль – это в общем случае доступ к более чем одной системе, и видов доступа несколько – Incert, Delit, Read, Wright. Более того, разные Роли с разной комбинацией доступов к разным сервисам еще и выдвигают разные требования к SLA на основе требований к процессам, в которых эти роли используются. И вот всё это хозяйство содержать в целостном и не противоречивом виде очень не просто.

  • Файрушин Дмитрий

     

    Причина = неэффективность, Факт ее (неэффективности) наличия должен быть. Если есть только знания, но факта неэффективности нет, то ни о каких изменениях речи быть не может. Задача автора — формализовать в чем неэффективность. 

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

     

  • Файрушин Дмитрий

    Incert, Delit, Read, Wright

    Простите, но как учитель английского по образованию, не могу не отметить шедевральность, 3 ошибки в 4 словах)))

    • Nargiza Suleymanova

      А некоторые сумели сдержаться, между прочим. Хоть и не учителя ни разу )

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

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

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