Мое личное мнение — все эти проблемы с определением из-за круговорота продуктов и услуг, т.е. мы любим оборачивать продукт в услугу, а услуги в продукт.
Публикую от имени коллеги Андрея Князева, который пока не может здесь комментировать.
………
Прочитал, есть вопросы по 5ти признакам услуги. Я знаю, что это классика, но все не так однозначно, особенно в современном мире…
Неосязаемость: как быть с услугой по вводу в эксплуатацию, написанием ПО, созданием прототипа. Между прочим часто услуги передаются по акту приемки- передачи и даже ставятся на балланс ( ввод в эксплуатацию).
Наверняка логичное объяснение — что я описал результат услуг, а не сами услуги. Но вот услуга предоставления collocation — вполне себе измеряема и осязаема.Несохраняемость — как известно мы стремимся сделать из услуги коробку, чтобы ее было легче продавать, те описав и задокументировав услугу мы можем ее сохранить для других клиентов. Потом, сделав сервисцентр ты одну и ту же услугу предоставляешь разным клиентам с одинаковым качеством по своим стандартам. Или услуга предоставления электричества: провайдер запасает услугу в дизельном топливе и батареях, чтобы в случае сбоя предоставить клиенту.
Неотделимость: сделав автоматическую услугу ( облачный сервис) и продав ее другому поставщику — я нарушаю первые 3 определения услуги
Непостоянство качества — товары также обладают этим свойством, для чего есть гарантийный сервис. К тому же мы, как поставщики услуг стремимся к воспроизводимому качеству и автоматическому предоставлению = одинаковому качеству.
Вовлечение — смотря что имеется в виду, заказчик точно всегда вовлечен в процесс оплаты услуги и контроля качества, а вот в процесс потребления может быть и не вовлечен — например услуга по покупке репетитора для ребенка, можно найти и другие примеры — например перепродажа услуги доя конечного клиента — заказчик вовлечен в процесс перепродажи и приемки/ сдачи, а в предоставление не вовлечен, это делает конечный клиент…
Заказчик должен составить для себя список ключевых требований к аутсорсеру с приоритетами. Например,
— «Решает индиценты быстрее других» — 10 баллов макс
— «Цена» — 8 баллов макс
— «Обязательное наличие подтвержденного опыта с похожими заказчиками» — 10 баллов
— «Кол-во сертифицированных инженеров в каком-то домене» — 7 баллов
и т.п.
Прогнать по списку все возможные кандидатуры и выбрать лучшего.
Работаю в компании-топикстартере, но мнение больше частное.
Согласен, что отдавать совсем бизнес-критичные процессы на аутсорс не всегда оправданно, в статье после комикса есть упоминание об этом.
На самом деле какой-то критичностью обладает каждый процесс. И даже банальный простой из-за принтера может повлиять на эффективность работы компании. А пользователям вообще любая их проблема видится самой критичной на свете.
Вопрос, кто быстрее и дешевле решает эти критичные и не очень проблемы – собственные айтишники или аутсорсер?
И что делать с собственными айтишниками, если они не в состоянии решать проблемы достаточно быстро? Например, из-за перегруженности другими задачами в данный конкретный момент? В случае с аутсорсером — в договоре фиксируется время решения инцидентов в соответствии с критичностью (SLA). Так же фиксируются и штрафы, и если аутсорсер не выполняет обязательства, то штрафы покрывают возможные простои и потери бизнеса.
Критичность бизнес-процессов каждый определяет для себя сам. Кто-то не аутсорсит даже уборку территории, в то время как другие, желая добиться максимальной эффективности и конкурентоспособности, аутсорсят ит-функцию практически полностью. Например, ведущие мировые банки.
Про резервных поставщиков согласен. Заказчик должен знать рынок и помнить про лучшее альтернативное решение. И про стоимость перехода на это решение в случае чего.
А чтоб «в случае чего» не случалось, выбирать лучших и заключать с ними добротный контракт с покрытием рисков через штрафы если поставщик факапит.
Про привлечение к проектированию и развитию – тоже весьма за!
ИТ-директор может (и должен!) знать куда идет бизнес, как он развивается или планирует развиваться, он должен думать о том, как можно сделать бизнес лучше, используя ИТ и владеть дорожной картой развития ИТ. И при принятии решений ему весьма полезно знать мнение тех, кому это потом реализовывать и обслуживать :)
Но обязывать не можем. Если он уверен в своих силах и готов решать самостоятельно – это его право.
Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.
Ждем автора статьи для его ответов :)
………
Прочитал, есть вопросы по 5ти признакам услуги. Я знаю, что это классика, но все не так однозначно, особенно в современном мире…
Неосязаемость: как быть с услугой по вводу в эксплуатацию, написанием ПО, созданием прототипа. Между прочим часто услуги передаются по акту приемки- передачи и даже ставятся на балланс ( ввод в эксплуатацию).
Наверняка логичное объяснение — что я описал результат услуг, а не сами услуги. Но вот услуга предоставления collocation — вполне себе измеряема и осязаема.Несохраняемость — как известно мы стремимся сделать из услуги коробку, чтобы ее было легче продавать, те описав и задокументировав услугу мы можем ее сохранить для других клиентов. Потом, сделав сервисцентр ты одну и ту же услугу предоставляешь разным клиентам с одинаковым качеством по своим стандартам. Или услуга предоставления электричества: провайдер запасает услугу в дизельном топливе и батареях, чтобы в случае сбоя предоставить клиенту.
Неотделимость: сделав автоматическую услугу ( облачный сервис) и продав ее другому поставщику — я нарушаю первые 3 определения услуги
Непостоянство качества — товары также обладают этим свойством, для чего есть гарантийный сервис. К тому же мы, как поставщики услуг стремимся к воспроизводимому качеству и автоматическому предоставлению = одинаковому качеству.
Вовлечение — смотря что имеется в виду, заказчик точно всегда вовлечен в процесс оплаты услуги и контроля качества, а вот в процесс потребления может быть и не вовлечен — например услуга по покупке репетитора для ребенка, можно найти и другие примеры — например перепродажа услуги доя конечного клиента — заказчик вовлечен в процесс перепродажи и приемки/ сдачи, а в предоставление не вовлечен, это делает конечный клиент…
Заказчик должен составить для себя список ключевых требований к аутсорсеру с приоритетами. Например,
— «Решает индиценты быстрее других» — 10 баллов макс
— «Цена» — 8 баллов макс
— «Обязательное наличие подтвержденного опыта с похожими заказчиками» — 10 баллов
— «Кол-во сертифицированных инженеров в каком-то домене» — 7 баллов
и т.п.
Прогнать по списку все возможные кандидатуры и выбрать лучшего.
Согласен, что отдавать совсем бизнес-критичные процессы на аутсорс не всегда оправданно, в статье после комикса есть упоминание об этом.
На самом деле какой-то критичностью обладает каждый процесс. И даже банальный простой из-за принтера может повлиять на эффективность работы компании. А пользователям вообще любая их проблема видится самой критичной на свете.
Вопрос, кто быстрее и дешевле решает эти критичные и не очень проблемы – собственные айтишники или аутсорсер?
И что делать с собственными айтишниками, если они не в состоянии решать проблемы достаточно быстро? Например, из-за перегруженности другими задачами в данный конкретный момент? В случае с аутсорсером — в договоре фиксируется время решения инцидентов в соответствии с критичностью (SLA). Так же фиксируются и штрафы, и если аутсорсер не выполняет обязательства, то штрафы покрывают возможные простои и потери бизнеса.
Критичность бизнес-процессов каждый определяет для себя сам. Кто-то не аутсорсит даже уборку территории, в то время как другие, желая добиться максимальной эффективности и конкурентоспособности, аутсорсят ит-функцию практически полностью. Например, ведущие мировые банки.
Про резервных поставщиков согласен. Заказчик должен знать рынок и помнить про лучшее альтернативное решение. И про стоимость перехода на это решение в случае чего.
А чтоб «в случае чего» не случалось, выбирать лучших и заключать с ними добротный контракт с покрытием рисков через штрафы если поставщик факапит.
Про привлечение к проектированию и развитию – тоже весьма за!
ИТ-директор может (и должен!) знать куда идет бизнес, как он развивается или планирует развиваться, он должен думать о том, как можно сделать бизнес лучше, используя ИТ и владеть дорожной картой развития ИТ. И при принятии решений ему весьма полезно знать мнение тех, кому это потом реализовывать и обслуживать :)
Но обязывать не можем. Если он уверен в своих силах и готов решать самостоятельно – это его право.
Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.
Очень хотелось бы обратный отсчет дней до 30\40\50 лет.
Теперь год надо прожить так, чтоб красными клетками выложилось заветное трех буквенное слово :)