В некоторых службах техподдержки есть хак — можно в явном виде попросить проэскалировать вопрос на следующую линию поддержки. Если это знать, то, например, после истечения некоторого «приемлемого» лимита времени общения на первой линии, если вопрос не решился, можно в явном виде попросить перевести вопрос на следующую линию.
Так работает не везде, но где работает — очень помогает.
Спасибо за комментарий. Найду время и постараюсь написать с примерами, как сделать процесс «настольной книгой». Тема непростая, но очень интересная.
На высоком уровне в ITIL процессы, безусловно, описаны. А дальше — дьявол в деталях. Во многих областях есть лучшие практики (а иногда даже законодательные нормы), и есть коробочные продукты, которые им соответствуют, но всё же зачем-то их ещё нужно тюнить и настраивать. Бухгалтерия и расчёт зарплаты, например, — куда более регламентированные вещи, а всё же 1С-ников в стране пруд пруди. Казалось бы, всё написано в законодательных и подзаконных актах, а всё же.
Так что в части управления эксплуатацией тоже есть тонкости, о которых надо думать. Межрегиональное взаимодействие, круглосуточная территориально-распределённая поддержка, управление изменениями и оценка их влияния — очень много разных вещей, которые мало где описаны и сделаны хорошо. Так что, погрузившись глубоко в тему, можно найти много точек для совершенствования.
Так и я о том, коллега. Люди должны смотреть в процесс, и лучше — сразу в системе автоматизации, безусловно. И вкладывать ресурсы нужно не в рисование процессов в сложночитаемых нотациях, а в то, чтобы организация побыстрее начинала получать пользу от процессов. А это возможно, если есть правильное сочетание и взаимодействие трёх компонентов: процессы+люди+технологии. О чём и вы пишете.
Так что полностью с вами согласен. Ну разве что кроме JIRA. Всё же я сотрудник Hewlett Packard Enterprise :)
Я не утверждаю, что использование Agile переворачивает с ног на голову проектное управление. Разумеется, многое остаётся похожим. Но всё же, некоторые коррективы необходимы. И не только в проектном управлении, но и в подходе к финансированию разработки в формате Agile. Если в waterfall-е мы финансируем скоуп, то в agile мы финансируем value, а скоуп у нас может быть очень подвижным.
Краски, возможно, немного сгущаю — но без этого не было бы дискуссии :)
Once industries and professions reach a certain level of maturity, efforts arise to standardize key terminology and concepts to foster improved knowledge exchange and collaboration. When done using an Enterprise Architecture framework or method, such attempts may be termed “reference architecture” or “reference models”. Notable examples of such efforts include:
Frameworx (eTOM), by the TM Forum
BIAN – the Banking Industry Architecture Network
ARTS – the work of the Association for Retail Technology Standards, an affiliate of the National Retail Federation
The ACORD framework – an Enterprise Architecture for the insurance industry
EMMM – the work of The Open Group Exploration, Mining, Metals & Minerals Forum
Нет, под водопадом и «оборачиванием» я подразумеваю то, что в начале проекта мы делаем некую «постановку задачи» (как бы делали это в waterfall-е), а в конце — некую «приёмку результатов проекта». То есть начало и окончание проекта — как в типичной каскадной модели реализации проектов. А середина, где дополнительная постановка задачи, разработка, тестирование, уже частично эксплуатация выпущенных релизов — agile.
Это значит, что всё, что вы делаете — это код. Инфраструктура — это код, документы — это код. Со всеми этими штуками нужно работать по тем же (или почти по тем) правилам, как с кодом. Версионный контроль, тестирование, релизы, приёмка и всё такое.
Сорри, чего-то меня переклинило :) Ок, мне тоже эта тематика интересна, сейчас этим занимаюсь как раз. Напишу в том числе с учётом того, как оно бывает на практике. И да, по факту, здесь в большинстве компаний всё далеко от идеала. Все мыслят портфелями проектов, а не портфелями услуг — в этом, так сказать, ключевой момент.
Артём, вопрос по новизну правильный, его действительно часто задают. Тут дело вот в чём:
IT4IT не про процессы, а про функциональные компоненты. Agile у вас или waterfall, компоненты plan, design, development, testing и т.д. всё равно существуют. Опять же IT4IT не пытается быть только про agile или только про waterfall, она пытается быть инвариантной. Возможно, получается хуже, чем если бы референсная архитектура была заточена под тот или иной вариант. Но тут уже дело вкуса — кто-то любит точность и вариативность, кому-то нужна большая картина "крупными мазками".
Деление на value stream-ы не означает, что "вот тут эта деятельность закончилось, снимаем шапку plan, надеваем шапку development". То есть разные функциональные компоненты — не значит, что это разные люди в разное время делают эти задачи. Опять же, исходя из того, что это не про процессы или хотя бы не только про процессы, design+develop+build+test могут быть весьма blended.
Я очень люблю ITIL v3 и редакцию 2011 года, которые во многим написаны моими коллегами из Hewlett Packard Enterprise, которых я лично знаю и очень уважаю. Но согласитесь, что уровень adoption для книжек Service Strategy, Service Design и Continual Service Improvement оставляет желать лучшего. Поэтому если есть альтернативный взгляд, думаю, это неплохо. К тому же, IT4IT в части эксплуатационных процессов явно ориентируется на ITIL — в той части, где ITIL себя действительно зарекомендовал.
Вообще говоря, референсная архитектура IT4IT она на то и референсная, чтобы мы на неё смотрели и решали, refer или не refer. Радует то, что там есть коллектив авторов, которые не сидят на месте, что-то делают и развивают. Совсем недавно вышла whitepaper про то, что такое услуга — для меня там было много интересного и актуального в контексте тех задач, которые мне прямо сейчас приходится решать.
Я читаю подобные вещи скорее для того, чтобы получить какое-то просветление. Мне кажется, там есть о чём подумать.
Как-то я не пойму:
47 миллиардов сообщений ежедневно (в 2009 году)
1 миллиард пользователей (в 2009 году)
53 сообщения в день отправил каждый пользователь (в 2009 году)
Как они считали, интересно, что у них 47 000 000 000 / 1 000 000 000 = 53
Я, конечно, понимаю, что статистика могла собираться по-разному и разное имелось в виду.
Ну так надо как-то тогда написать, что эти цифры все разные… :(
А также внедрение у заказчика систем (или подключение к внедрённым у аутсорсера системам):
— мониторинга сети, серверов и middleware софта;
— авто-дискавери оборудования и ПО с целью поддержания актуальной CMDB;
— удалённого распространения обновлений и ПО (MS SCCM, HP Radia и т.п.).
По сервис деск вы сказали, без него вообще никуда.
Опять же, с увеличением масштаба эффект усиливается. Но, думаю, даже если у заказчика 1 сервер и 1 канал в интернет, хотя бы мониторинг эффект даст…
В случае небольших компаний ситуация, конечно, несколько другая. Но напишу, как это бывает в общем и целом.
Вообще говоря, серьезная работа аутсорсера предполагает обычно как минимум 5-летний контракт. Потому что аутсорсер — это не временщик, который просто присылает своего более (или ровно такого же) опытного инженера для решения вопросов заказчика.
Профит аутсорсер получает за счёт того, что сразу же после прихода к заказчику инициирует проекты, которые помогают существенно сократить затраты на ИТ, но которые заказчик сам реализовать не мог в силу нерешительности, отсутствия компетенции, недостаточного масштаба.
Например, есть реальные примеры, когда приходящий аутсорсер (из грандов) менял за свой счёт все компьютеры у заказчика, одновременно вводя корпоративный стандарт, что в конечном итоге уменьшило затраты на обслуживание и просто в потолок подняло удовлетворённость заказчика. Конечно, это возможно при большом масштабе и стратегическом уровне взаимодействия.
Или вот был пример — у заказчика есть контора, сидит 20 тетечек в 5 комнатах, у каждой на столе лазерный принтер. А специфика работы такая, что печатать им надо по 500 страниц в день, на что такие принтеры в общем-то не сильно расчитаны. Простой расчёт показал, что если выкинуть эти 20 принтеров и поставить один большой сетевой девайс, экономия на отсутствии поломок, на расходниках проявится достаточно быстро.
Вот у меня, например, конфигурация ушей несовместима с конфигурацией наушников от Apple. И вообще, я всё привык слушать через свои походные Sennheiser PX-100.
И как-то я совершенно не уверен, что Sennheiser сделать хоть одну модель сколько-нибудь нормальных наушников с кнопками по лицензии Apple.
Я понимаю, что целевая аудитория Shuffle, наверное, слегка другая. Но всё равно — на мой взгляд, обладатели Shuffle теперь не будут пересекаться с обладателями нормальных наушников.
ITIL, конечно же, имеет весьма опосредованное отношение к управлению проектами. ITIL ориентирован на управление услугами.
В Великобритании «братом-близнецом» ITIL в части управления проектами являетя PRINCE2. И то, и другое разработано под началом OGC
Так работает не везде, но где работает — очень помогает.
На высоком уровне в ITIL процессы, безусловно, описаны. А дальше — дьявол в деталях. Во многих областях есть лучшие практики (а иногда даже законодательные нормы), и есть коробочные продукты, которые им соответствуют, но всё же зачем-то их ещё нужно тюнить и настраивать. Бухгалтерия и расчёт зарплаты, например, — куда более регламентированные вещи, а всё же 1С-ников в стране пруд пруди. Казалось бы, всё написано в законодательных и подзаконных актах, а всё же.
Так что в части управления эксплуатацией тоже есть тонкости, о которых надо думать. Межрегиональное взаимодействие, круглосуточная территориально-распределённая поддержка, управление изменениями и оценка их влияния — очень много разных вещей, которые мало где описаны и сделаны хорошо. Так что, погрузившись глубоко в тему, можно найти много точек для совершенствования.
Так что полностью с вами согласен. Ну разве что кроме JIRA. Всё же я сотрудник Hewlett Packard Enterprise :)
Краски, возможно, немного сгущаю — но без этого не было бы дискуссии :)
Вообще говоря, референсная архитектура IT4IT она на то и референсная, чтобы мы на неё смотрели и решали, refer или не refer. Радует то, что там есть коллектив авторов, которые не сидят на месте, что-то делают и развивают. Совсем недавно вышла whitepaper про то, что такое услуга — для меня там было много интересного и актуального в контексте тех задач, которые мне прямо сейчас приходится решать.
Я читаю подобные вещи скорее для того, чтобы получить какое-то просветление. Мне кажется, там есть о чём подумать.
47 миллиардов сообщений ежедневно (в 2009 году)
1 миллиард пользователей (в 2009 году)
53 сообщения в день отправил каждый пользователь (в 2009 году)
Как они считали, интересно, что у них 47 000 000 000 / 1 000 000 000 = 53
Я, конечно, понимаю, что статистика могла собираться по-разному и разное имелось в виду.
Ну так надо как-то тогда написать, что эти цифры все разные… :(
Т.к. «оригинального» рассказа про ITSM не существует.
(ITIL != ITSM)
Конечно, книжки читать полезно :)
— мониторинга сети, серверов и middleware софта;
— авто-дискавери оборудования и ПО с целью поддержания актуальной CMDB;
— удалённого распространения обновлений и ПО (MS SCCM, HP Radia и т.п.).
По сервис деск вы сказали, без него вообще никуда.
Опять же, с увеличением масштаба эффект усиливается. Но, думаю, даже если у заказчика 1 сервер и 1 канал в интернет, хотя бы мониторинг эффект даст…
Вообще говоря, серьезная работа аутсорсера предполагает обычно как минимум 5-летний контракт. Потому что аутсорсер — это не временщик, который просто присылает своего более (или ровно такого же) опытного инженера для решения вопросов заказчика.
Профит аутсорсер получает за счёт того, что сразу же после прихода к заказчику инициирует проекты, которые помогают существенно сократить затраты на ИТ, но которые заказчик сам реализовать не мог в силу нерешительности, отсутствия компетенции, недостаточного масштаба.
Например, есть реальные примеры, когда приходящий аутсорсер (из грандов) менял за свой счёт все компьютеры у заказчика, одновременно вводя корпоративный стандарт, что в конечном итоге уменьшило затраты на обслуживание и просто в потолок подняло удовлетворённость заказчика. Конечно, это возможно при большом масштабе и стратегическом уровне взаимодействия.
Или вот был пример — у заказчика есть контора, сидит 20 тетечек в 5 комнатах, у каждой на столе лазерный принтер. А специфика работы такая, что печатать им надо по 500 страниц в день, на что такие принтеры в общем-то не сильно расчитаны. Простой расчёт показал, что если выкинуть эти 20 принтеров и поставить один большой сетевой девайс, экономия на отсутствии поломок, на расходниках проявится достаточно быстро.
рабайтныхИ как-то я совершенно не уверен, что Sennheiser сделать хоть одну модель сколько-нибудь нормальных наушников с кнопками по лицензии Apple.
Я понимаю, что целевая аудитория Shuffle, наверное, слегка другая. Но всё равно — на мой взгляд, обладатели Shuffle теперь не будут пересекаться с обладателями нормальных наушников.
В Великобритании «братом-близнецом» ITIL в части управления проектами являетя PRINCE2. И то, и другое разработано под началом OGC