Оригинальное название Defining Metrics for the Service Desk
Автор Stuart Rance
Дата публикации 3.5.15
Достоинства: подробно рассмотрены
- понятие целей (objectives) и критических факторов их достижения (CSFs) и их отличие от ключевых показателей (KPIs)
- для чего использовать KPIs и почему в отчетности фокусироваться на целях и CSFs
Недостатки - слишком компактно.
Уровень - базовый
Оценка - 8/10.
Оригинал How to Make Sure Your KPIs Are Balanced
автор Stuart Rance, дата публикации 21.10.14
Достоинства: написано простым, доступным языком, качественные примеры.
Недостатки: слишком компактно.
Уровень сложности - средний.
Полезность - 7/10.
Статья об одном из варианте, как сделать ИТ и бизнес более понятными друг другу в постановке целей и предоставлении отчетности о результатах. Если в компании уже используется система сбалансированных показателей, то будет гораздо проще.
Большая просьба, если будете минусовать, потратьте немного своего времени, чтобы отметить в комментариях, что не понравилось.
Здесь и далее курсивом замечания переводчика.
Еще одна компактная статься Стюарта Рейнса про то, чем измерять результативность процессов.
Оригинал Defining Metrics for Incident Management By Stuart Rance
Опубликовано September 23, 2014
Достоинства - хорошая иллюстрация декомпозита цели-показатели-метрики, качественный пример показателей, настойчивое напоминание о подходе “адаптируй и применяй”
Недостатки - очень компактно написано, хочется чуть больше примеров и пояснений к ним.
Сложность материала - базовая.
Оценка - 8/10.
Здесь и ниже курсовом комментарии переводчика.
Оргинал: Defining Metrics for Problem Management
By Stuart Rance | Originally published on June 24, 2014 in ITIL | Updated on November 28, 2017
Это перевод второй статьи на тему определения показателей для процессов Управления ИТ- услагами. Ценность ее в применении техники формулирования показателей на основе требований к результатам процесса (здесь и далее курсивом выдлелены комментарии переводчика).
Многие подбирают ключевые показатели (KPIs) для своих процессов Управления ИТ услугами по книгам (таких как ITIL Service Operation) или копируя метрики, используемые в других компаниях. Это редко приводит к хорошим результатам, потому что дословно KPIs - это дословно Показатели Результативности Ключевых задач, которыми вы занимаетесь. Хуже только ITSM процессы с огромным количеством одинаково названных показателей, которые измеряются, по ним пишутся отчеты, но результаты этого никто не использует ни для изменения деятельности в рамках процессах, ни для улучшения бизнес результатов.
Ранее я уже писал заметку "Как определять метрики для процесса Управления изменениями" (перевод, оригинал) , в которой я описывал, как можно создать ключевые показатели (KPIs), которые поддерживают именно ваши цели. Читатели (оригинала) после прочтения просили привести примеры, как выделять ключевые показатели (KPIs) для остальных процессов управления ИТ-услугами. В результате я решил написать эту статью для показателей процесса Управления проблемами (problem management), потому что в большинстве компаний, где я работал, у этого процесса были очень куцые показатели.
Напоминаю, что не стоит бездумно копировать приводимые здесь результаты процесса (outcomes), его критичные факторы успешности (CSFs) и ключевые показатели (KPIs). Содержание статьи стоит использовать только для понимания подхода и методологии, которые мною используются. И задуматься о том, что важно именно для вас, выделить метрики, для измерения задачи, за которые вы отвечаете.
Оригинал Defining Metrics for Change Management
By Stuart Rance | Originally published on April 28, 2014 in ITIL | Updated on September 12, 2017
Начало цикла из 3-х статей про процесс определение показателей для оценки практик управления предоставления ИТ услуг. Чем может быть интересна? Ходом рассуждений автора. (здесь и далее курсивом комментарии переводчика).
Недавно я работал с заказчиками, и они спросили какие ключевые показатели результативности (key performance indicators, KPIs) им использовать для измерения результатов ИТ-процесса Управления изменениями (change management). После обдумывания я предложил им несколько вариантов. И сейчас хочу поделиться ими здесь, потому что это может быть еще кому-нибудь полезно . Только, пожалуйста, бездумно не копируйте себе предлагаемые показатели (KPIs), ведь они предложены под конкретных заказчиков, но внимательно просмотрите за процессом их опеределения и задумайтесь, а что стоит измерять в вашей ситуации.
Новая подборка по переводческим решениям для еще одного популярного слова в ИТ- и бизнес-литературе. Смотрите, пользуйтесь.
Начнется все с самого простого, например с выбора фильма для просмотра.
It starts with simple things, like deciding which movie to watch.
Когда Великобритания оказалась перед выбором, выходить из ЕС или нет…
… when Britain needed to decide whether it should leave the EU…
Недавно в ПО для видеоконференций Microsoft Teams наконец появилась функция поднятия руки, но внимательных русскоязычных пользователей позабавит ее подпись: Поднимите руку. Глаголы рядом подписаны в неопределенной (инфинитивной) форме: Показать, Включить, Начать. А здесь использовано повелительное наклонение (императив), как будто программа нам приказывает: Поднимите руку! Как так получилось?
Казалось бы, база данных она и в Африке database, но читая аутентичную техническую литературу по СУБД (которую русские переводчики традиционно переводят как DBMS — database management system), я ни разу этот термин — DBMS — там не увидел (не исключаю, что плохо смотрел, но ей-богу не вру).
Получается, этот термин выдуман? И много ли такого самопала?
В этой публикации я собрал из разной ИТ-литературы англоязычных авторов так называемое «семантическое поле» вокруг термина database — какие базы данных бывают, что с ними делают и с чем их едят. Мне показалось, что это будет явно нагляднее и достовернее, чем обычные глоссарии. Решать, конечно же, вам.
Итак, поехали.
Объектные базы данных появились в конце 1980-х — начале 1990-х годов и снова вышли из моды.
Object databases came and went again in the late 1980s and early 1990s.
В начале 2000-х появились базы данных XML, но нашли только узкое применение.
XML databases appeared in the early 2000s, but have only seen niche adoption.
Есть еще один куст слов, по которому в голову большинства переводчиков (я в их числе) в голову лезет только один дежурный набор вариантов:
участник/участие > take part/participate/participant.
Как обычно, мы посмотрели несколько переведенных с английского книг по бизнесу и ИТ (список книг внизу), развернули направление перевода (стало русско-английским), вытащили около 300 вариантов перевода, отбросили те, которые с дежурным переводом, и разложили по полочкам наиболее интересные и применимые.
Поехали.
Здесь необходимо участие обеих сторон.
It takes two to tango.
Единство мнений других участников рынка отражает цена.
That’s because the consensus view is baked into the price.
Если в переводном тексте кто-то что-то где-то начинает — то у меня сразу всплывают три дежурных варианта: begin/beginning, start/starting, first/firstly.
Судя по тому, что я вижу в присылаемых мне на проверку переводах, эта бедность речи наблюдается не только у меня. Зато у наших американских переводчиков я такого не наблюдаю — тут тебе и синонимы красивые, или вообще без всяких begin/start дело обходится.
Я подумал, что пришло время устранить этот пробел в знаниях, делюсь наиболее интересными находками.
Самые экзотические варианты (напр. ignite) сюда впихивать не стал, вроде и без них есть из чего выбрать (но если в будущем экзотика тоже интересует, напишите в комментах).
Поехали.
Я принял все предложения без споров и оправданий и начал действовать.
I accepted their advice without arguing or defending and acted on it.
