Абсолютно бесплатно можно скачать проект перевода ISO 20000, адаптированный моими коллегами к суровой реальности общепринятой терминологии. Саше Сарычевой, Кириллу Иванову и Диме Салову - собственно, браво! По итогам этого дела немного обновился и сам глоссарий, свежая версия будет выложена ближайшее время.
И (барабанная дробь), бинго! Стартовал проект перевода ITILv3 на русский язык! О книге Service Strategy и общей реалистичности сроков позвольте скромно умолчать. Думаю, к концу года (оптимистично - к концу лета) у сообщества есть шансы потрогать первую напечатанную книжку.
четверг, 14 января 2010 г.
Куча новостей itSMF Ru: перевод ISO 20000, скоро обновленный глоссарий и ITILv3!
Real ITSM хохмит теперь на русском
Коллеги из Cleverics (Роман Журавлев и Олег Скрынник) перевели вот такую смешную книжку от высокоскептичного товарища и брата нашего Роба Ингланда (aka IT Skeptic). В воскресенье перевод будет оценен. Содержание смешное, тем кто разбирается в темах - час веселья при чтении книги гарантирован.
среда, 13 января 2010 г.
Подведем итоги и планы (2009-2010)
С одной стороны, как-то не получается занести этот год в актив – из запланированного сделано было мало, поделиться удалось не всем, чего наработали. С другой стороны, наработано в консалтинговых проектах достаточно много интересного. Да и общественно-полезные проекты стартуют в ближайшие месяцы. Что радует.
TQM, TOC, LEAN. Снова окунулся в Project Management, задвинутый когда-то в угоду ITSM к задворкам сознания. Прочитано более 15 книг за год (треть из них полезны зело – очень неплохой показатель). Еще десяток книг уже ждут своего часа в 2readlist. Блог года – "Лабораторный журнал" от Анатолия Левенчука http://ailev.livejournal.com/, без сомнения (читается назад во времени взахлеб, когда есть возможность). Приятно осознавать, что разделяешь один временной промежуток с гением.
За прошлый 2009 в блог попало 48 записей, что ровно в 2,4 раза больше, чем в позапрошлый 2008. Планы на 2010 год не формулируются в количестве записей – надеюсь, этот блог станет более интересным, и треть содержания будет постепенно склоняться к очень практической направленности. Тренируемся в растягивании времени, запускаем совершенно новый проект под крылом itSMF Ru. Всех с праздниками, товарищи коллеги!
суббота, 19 декабря 2009 г.
Выбор системы автоматизации
Пару месяцев назад написал короткую заметку о принципах выбора системы автоматизации. На примере системы Service Desk, разумеется. Читать здесь: OmniWay.ru. Это, по сути, синопсис будущего цикла статей о выборе систем автоматизации вообще и Service Desk, в частности. Цикл запланирован на 2010 год. Там будет общая статья, поясняющая тему выбора и подходы. Будет статья с описанием методики выбора. Ну и конечно отдельно напишу завершающую цикл статью на конкретных примерах вендоров и самых распространенных в России систем (HP, Naumen, Itilium - берегись!). И о новых, наступающих. Так как последняя статьи будет ближе к концу 2010, решение от MS тоже имеет шансы туда попасть. Аминь. Главное, чтобы времени и сил хватило.
Очень часто меня упрекают: вот вы внедряете конкретную систему и ее, мол, активно пиарите. Чтобы не повторяться, запишу здесь - товарищи, никогда не путайте причину и следствие. Причина здесь в том, что OmniTracker была выбрана основным решением на основе тестирования нескольких лучших и опыта работы с лихим десятком систем. Причина в том, что OmniTracker наиболее хорошо подходит под нашу методику внедрения. А следствие уже рассказ про выбранную систему. Какая она чертовски гибкая и кастомизируемая на три девятки!
Кстати, про OmniTracker рассказывать очень тяжело. То, что у многих других - маркетинговое фуфло, в нем запросто реализуемая ценность. Ну кто тебе поверит в неограниченно создаваемые и настраиваемые объекты управления? Приходится молчать, давать слово заказчику. Или рисовать видео-уроки, типа "простой процесс за 2 минуты 46 секунд".
А вообще, нужно быть гибким и внедрять любые системы. Вот будет Service Desk от MS охрененным решением - обязательно включай его в свой каталог продуктов и "внедряй" (с).
четверг, 17 декабря 2009 г.
Переводы Голдратта
Кстати, вот здесь http://zhurnal.lib.ru/s/stepenko_a_o/ в свободном доступе несколько переводов Голдратта. Та самая цель, Теория ограничений, Синдром стога сена. Читать в обязательном порядке, начинать с "Та самая цель", потом "Синдром стога сена".
По случаю попалась в руки Цель-3 "Необходимо, но не достаточно", дочитываю.
Вспоминаю свои впечатления после первого прочтения Голдратта. Тоже было дело случая.
http://itsmnotes.blogspot.com/2008/03/blog-post.html
Не думал, что в жизни еще раз встретятся книги, хотя бы немного изменяющие мировоззрение целиком. Книги, полезные не только десятком строк из сотен страниц. Однако именно такая книги по случайному совпадению была прочитана в недавней командировке. Вообще не относящаяся к ИТ, слегка относящаяся к финансовому учету, и совсем немного относящаяся к консультированию, эти книги и теории в них заставила мысленно побегать "по потолку" пару дней. Это Элияху Голдратт, книга "Синдром иголки в стоге сена", а также "Цель. Процесс непрерывных улучшений", "Цель. Дело не в везении". Пока слишком ошеломлен, чтобы делать выводы, ищу другие книги того же автора
Игра в ассоциации
Последние две недели выдались такими, что вздохнуть некогда - не то что в блог писать. А написать о многом нужно - о проектном и процессном управление, практике использования bpmn 1.1 чуть-чуть, почти дописана обзорная статья по финансам ИТ, и пр. и пр.
А пока: результат игры в ассоциации. По одному из плакатов - не смог удержаться, ниже ассоциация на пословицу. Внедренцам софта hp и прочим понимающим ржать полчаса.
(с) Авторство известно, но не раскрываемо.
Что же это?!
понедельник, 7 декабря 2009 г.
Интересная цитата
"Чтобы не содержать дорогостоящих специалистов, занятых только обслуживанием инструментария Service Desk, и не обращаться к услугам внешних интеграторов, решено было внедрять коробочное решение" (с)
На этой цитате я пресс-релизом заинтересовался. Вообще редко кто понимает внедрять коробочное решение правильно: поэтому число провальных по срокам проектов внедрения SAP так велико. Стал читать дальше - еще круче, исполнительный директор оперирует понятиями ITIL, CMDB. Подумал было, что статью написал itil-падаван, ан нет - Алексей Артюхов со знанием дела и довольно интересно рассказывает о том, как внедряли различные IncM's в копейке, и не только для ИТ. Умудрившись при этом ни разу не упомянуть имя вендора!
А я упомяну. Axios софт очень специфический, на любителя. Именно что коробочный - используй, что дают и не лезь вправо-влево. Я этот софт лично смотрел на стенде - когда начинался наш внутренний мини-тендер на самого успешного заместителя HP Service Desk 4.5 для консалтинговых проектов. Приехавший консультант продал все так внятно и так грамотно, что я просто диву давался. Но первый же пяток сформулированных ключевых вопросов поддержке по итогам двухдневного тестирования показал - дело швах.
Ответ на четыре штуки - нет, на один - возможно, но очень дорого. Это для человека, нуждающегося в легкости и мощности кастомизации - было слишком. Да и вопросы были не очень сложные, признаться. На Axios была поставлена печать "жесткая коробка", и больше я его года полтора в глаза не видел.
А Копейка вон смотри-ка внедряет. Правда, совсем уж не обратиться к услугам внешних интеграторов - это отчасти, по-видимому, лукавство.
Сертификационная схема ITILv3 спроектирована
Не прошло и трёх лет, как APMG доработала сертификационную схему до (ранее неизвестного) уровня ITILv3 Master, который будет много круче красного ромба ITILv2. Вот здесь об этом официальная новость, а вот здесь перевод и неофициальный комментарий от Романа Журавлева.
Жаль, не успел поглумиться, коллеги опередили. Кратко, что этот диплом выделяет - неясно абсолютно. Пока есть ощущение, что защита реализованного проекта сложностью 100 и защита полувыдуманного проекта сложностью 0,1 одинаково зачтется к диплому. Нужно бы успеть сдать ITIL Bridge, чтобы застать все веселье в первых рядах.
пятница, 27 ноября 2009 г.
Работаем с метриками
В одном известной российском банке ввели систему измерения удовлетворенности пользователей услуг. Билет электронной очереди можно опустить при выходе в синюю коробочку (хорошо) или в красную (нехорошо). Коробочки я заметил не сразу, а только когда пристально вгляделся в текст на них.
Вроде разумно и просто?
Встретил уже двух кассиров, которые просят пользователей сдавать им билеты электронной очереди. Большинство пользователей, конечно же, сдают. Вопрос - что нужно поменять в системе сбора показателей, или в самих показателях, чтобы исключить ловкость рук кассиров-коллекционеров?
Оффтопик между строк
Из нерабочего: больше половины ноября съел какой-то вирус, подкравшийся незаметно. Полторы недели не читал почты, статей, ничего. Потом еще неделю отходил.
Поднимает настроение текущий проект - один из самых интересных за все время. Сформулированы уже две забавные системные задачи. И не факт, что они решаемы: тем интереснее!
Сменил рабочий ноутбук на asus ul50vg. Машинка на батарее выдерживает 8 часов, что прелестно. Обычно предпочитаю "предпоследнюю" версию Windows, но в связи с заменой ноутбука перешел на Windows 7 + Office 2007. На удивление просто. Две недели - полет нормальный!
четверг, 29 октября 2009 г.
И снова прекрасное
Идет семинар по некоей платформе, весьма отдаленно касающейся процессов поддержки. На этой платформе презентуется новейший workflow-продукт, позволяющий настроить гибкий процесс управления изменениями.
И тут неизвестный герой (НГ) поднимается с места и речёт сокровенным тоном. А знаете ли вы, заходит наш НГ издалека. Знаете ли вы, потрясает он перстами, что Управление Изменениями - всего лишь ЕДИНСТВЕННЫЙ процесс из 26 (двадцати шести), описанных в ITILv3.
В самом ITILv3, вы подумайте! 26 штук!
среда, 21 октября 2009 г.
Процесс Управления Работами (workorder management, task management)
Общение на форуме в очередной раз подтолкнуло к вопросу о процессе Управления Работами (нарядами, задачами, заданиями, операциями и т.д.). Наверное, он появился благодаря софтовым решениям класса Service Desk, где периодически вспыхивали процессы workorder management, task management, activity management. Там же он появился благодаря тем службам ИТ, которые нуждались в таком процессе. Мы его уже проектировали, внедряли - и каждый раз с новыми, отличными от предыдущих акцентами в процессе. Здесь - для одной цели, тут - для другой, а тут - просто чтобы прибить под управление инцидентами и управление изменениями.
Когда возникает необходимость в подобном процессе управления? Симптомы следующие: проблемы при оперативных координации работ для разных исполнителей в рамках одного запроса на обслуживание, инцидента или изменения. Необходимость получения отчетности выполненной работы в инцидентах, запросах на обслуживание, изменениях в разрезе исполнителей, рабочих групп, департаментов. Нужно учитывать и контролировать исполнение регламентных работ. Нужно учитывать ресурсы и рабочее время в разрезе типов выполняемой деятельности.
Похвастаюсь немного. Ну и публичное упоминание будет, для последующих патентов. Неделю назад мой коллега, Саша Цимбалистов выдвинул гениальную идею в части способа расчета и корректировки нормативов на выполняемые работы. Разговоры о нормах на выполнение работ возникают то тут, то там постоянно. Есть вопрос конечного заказчика - почему под эту работу отведено именно столько времени, нельзя ли быстрее? На этот вопрос едва ли ответит даже утвержденный ГОСТ\ТУ (которых нет с 98 года).Каждый, кто сталкивается, более или менее успешно старыми тропинками пытается разрешить вопрос с нормами. Увы, гораздо чаще - менее успешно.
А наша идея абсолютно новая (насколько мне известно, сейчас в ИТ по России никто так не делает, на Западе - судя по публикациям, тоже). Мы сейчас эту идею попробуем сразу практически реализовать в проекте. По результатам посмотрим.
ITIL ChangeLog
В связи с планируемым выходом новых редакций ITIL v3 (заметка-перевод "Не путайте версии с редакциями" от Романа Журавлева) актуальным становится официальный ChangeLog. Доступен вот здесь: http://www.best-management-practice.com/changeLog/ (открытый доступ, нужна регистрация).
Наиболее же известный неофициальный ErrorLog ведется на сайте ИТ скептика, BOKKED. Краткий свод наиболее критичных, интересных ошибок (26 штук) можно посмотреть в этой заметке.
понедельник, 19 октября 2009 г.
понедельник, 12 октября 2009 г.
Снова об ITILv3, функции и процессы
Тут в комментариях Георгий просил еще статей из почившей серии ITEMS откомментировать. Комментирую. Лучшая статья: вот здесь Роман Журавлев рассуждает о понимании функций и процессов в ITIL v3. Кто интересуется темой и не читал - читать в обязательном порядке.
Самое важное:
- Процессы структурируют деятельность для достижения целей.
- Функции структурируют возможности и ресурсы для обеспечения работы процессов.
То есть, "Процессы направляют усилия к цели. Функции управляют возможностями" (с) Здесь подписываюсь, как под своим.
И еще, Роман отмечает: "Между прочим, с этой точки зрения возникают большие сомнения в процессной природе таких явлений, как управление доступом и управление событиями (которое в оригинале event management)". За управление доступом ручаться не готов, а вот Управление Событиями - это явно не есть процессная структура. Правда, я там дальше по толкованию не согласен, но суть вопроса Роман раскрыл очень четко. Пожалуй, статья о "Полезность и гарантия" от Олега плюс вот эта статья от Романа - лучшее, что было в ITEMS.
Остальные как-то полемического задора не вызывают. Скучноватые комментарии к ITIL, ах этот Портфель услуг это не совсем каталог услуг, ах процессом нужно управлять и это должен делать менеджер. Разве что еще статья "Переход на ITIL - это куда?" заслуживает поощрения за прекрасное полуцензурное название в стиле поручика Ржевского, ну и за эпиграф.
MS Service Desk == MS SCSM, есть русскоязычный блог по продукту!
Полку Service Manager'ов прибыло - любим говорить мы о сертифицированных ITSM специалистах. Теперь можно и о ПО аналогичным образом. К известному HP Service Manager вскоре добавится MS SC Service Manager. Выпущена бета №2, и шансы на релиз-кандидат высоки, крайне высоки. А вот здесь доступен самый настоящий русскоязычный блог по MS SCSM от Владимира Бахметьева, program manager'а данного продукта!
пятница, 9 октября 2009 г.
Полезность и гарантия – странное враг хорошего
Поговорим честно о полезности и гарантии. Без прикрас и реверансов. Начнем, как водится, издалека.
Осенью 2008 года стартовал проект ITEMS (публикация коротких статей с пояснениями и комментариями относительно идей ITIL). Проект делался в явно маркетинговых целях, но основная идея была очень правильная. Ибо публичных комментариев практиков не хватает. ITEMS успешно стартовал, чтобы в феврале 2009 благополучно свернуться, да и автор статьи уже работает вовсе не там.
Ну не суть. В наборе одна из статей сразу привлекла внимание: "Полезность и гарантия – глупость или гениальная идея?" от Олега Скрынника. Внимательно прочел. Давно хотел по поводу полезностей и гарантий письменно подискутировать, жаль руки не доходили. Комментарий Олега – повод прекрасный. Кстати, кому интересно узнать мою версию ответа на вопрос "глупость или гениальная идея", те могут подсмотреть смело в окончание поста, там все есть.
Разделение понимания ценности сервиса на полезность и гарантию – это то, что сразу заинтересовало в первых чтениях ITIL v3, и при попытках внятного перевода этих понятий на русский. С коллегами очень долго раздумывали, прикладывали так и так к практическим работам, размышляли как использовать в проектах. В результате плюнули, добавили понятие в курс и забыли до времени. Спустя некоторое время возникла возможность на курсах задать вопрос консультанту Getroniсs, а зачем новое понятие введено в текст, какие задачи оно решает? Так как консультант увидел меня минут 15 назад, то он с ответом замялся, но выудил ответ из общих соображений. Но так как консультант был изрядно подкован многими проектами, а не просто голой теорией – то через два дня знакомства он признался, что если бы авторы ITIL v3 меньше сочиняли новых понятий, текст был бы значительно яснее и проще.
О чем пишет Олег в своей статье. Первое – описывает и комментирует определения полезности, гарантии из третьей версии нашей любимой библиотеки передового опыта. В результате приходит к выводу, что полезность-гарантия скорее нужна, чем нет. Варианты переводов терминов "Полезность сервиса", "Гарантия сервиса" на русский язык можно посмотреть в официальном глоссарии ITIL v3, ну или у в статье Олега (определения почти одинаковы). Я же так долго о воздушных терминах распинаться не буду. Определим проще, по-крестьянски.
Полезность сервиса, это "что сервис делает", какие требования закрывает, какой функционал предоставляет. Вообще, сия полезность известная под агентурной кличкой "функциональность".
Гарантия сервиса еще проще – "как сервис делает", т.е. формализованное обещание обеспечить параметры уровня собственно сервиса, нужный уровень безопасности и прочее, и прочее. Это то, что всю жизнь называлось уровнем качества услуги, уровнем сервиса.
Вы видите в этих понятиях что-то концептуально новое? Я лично – нет. Все разрабатываемые соглашения об уровне услуги (SLA) так или иначе делятся на два раздела: функционала сервиса и параметров уровня качества сервиса. Что представляет услуга "Почта" с точки зрения функционала: отправка \ прием почтовых сообщений, уведомления о вручении, актуальная книга контактов в компании, адресные рассылка по компании. Что представляет "Почта" с точки зрения уровня качества: доступность 98%, часы поддержки 9.00 – 18.00, время устранения критического инцидента 2 часа, восстановление из бэкапа истории переписки за полгода, условия безопасности, етц. Не припомню нужды в разделении. А что даст надпись к ряду параметров подраздела Полезность, а к другому Гарантия? (еще попробуйте написать "гарантия" в юридически значимый SLA, хлопот не оберетесь).
Если вы думаете, что данное понятие было введено для структуризации текста – вы ошибаетесь. Понятие полезности - гарантии в верном контексте упоминается, кроме Service Strategy в прочих книгах ITIL порядка 12 раз, из них SO – 0!!! раз, SD – 4 раза (не считая глоссария и заголовков), в ST чаще всего – 8 раз (если считать упоминания рядом за одно), и в CSI – 0!! раз. Нормально? Если это простая несогласованность планов выпуска, то можно только аплодировать архитектуре библиотеки.
Так все-таки, полезность и гарантия – глупость или гениальная идея? Мы с бритвой Оккама и принципом МЕСЕ считаем, что это лишнее звено эволюции: непригодное для практического применения, громоздкое, ненужное определение. В общем, типичная производная air management. Ничего не проясняющее и не поясняющее. На языке кайдзен это именуется короче – му'да (извините за прямую цитату).
Внесены разработчиками ITIL новые определения, разумеется, с наилучшими побуждениями. Нагнать тексту и сделать структуру понятий более запутанной и непрозрачной. А любителей мистического прочтения второй, третьего и n-ного слоя ITIL прошу ответить на простой вопрос: параметры качества процессов управление инцидентами и проблемами, поддерживающих искомый сервис, это гарантия или не гарантия?
И помните - "истинно лишь то, что отвечает практической успешности действия" (с) Уильям Джеймс.
вторник, 6 октября 2009 г.
"Прекрасное" (с)
Половина британских компаний считает, что использование рекомендаций ITIL не приносит конкурентных преимуществ. По данным Vanson Bourne, лишь четверть их ИТ-персонала проходила тренинги по какой-либо из версий ITIL. Главной причиной этого стало отсутствие очевидных бизнес-эффектов от подобных курсов повышения квалификации. Другим озвученным фактором является высокая стоимость обучения. С учетом нынешних бюджетных ограничений, он также играет важную роль. (с)
Прекрасное пришло вот отсюда: новость на osp.ru
пятница, 2 октября 2009 г.
Забудьте о KPI ! (часть 1, или простые ошибки)
Забудьте о KPI !
Навсегда забудьте о KPI! Стройте и улучшайте процессы управления ИТ с четко поставленными целями. Тогда создавать KPI в творческих муках просто не будет необходимости. Показатели и так будут у вас под рукой. Парадокс? Давайте попробуем разобраться.
Ситуация в большинство ИТ-отделов с практикой создания и использования процессных метрик действительно удручает. Фразу "если не измеряешь, значит не управляешь" многие компании выучили наизусть, и ошибка номер раз – полное отсутствие измерения ИТ процесса – постепенно вымирает на просторах отечественного ИТ. Хоть что-нибудь, но померяем. Качественно ли измерим, то ли измерим, что нужно – второй вопрос. Средняя температура известна. И после шага один становится немного сложнее. Дальше нас подстерегают интересные, познавательные грабли.
До сих пор во многих известных и уважаемых компаниях наиболее используемым отчетом Service Desk все еще остается простой реестр инцидентов с главным показателем – количество инцидентов. Это хороший KPI процесса управления инцидентами? Прошу вас, после чтения этой статьи – взгляните на этот простой вопрос и ответьте на него еще раз.
Основные ошибки.
Попробуем типизировать наиболее распространенные ошибки создания и внедрения показателей:
1) Не измеряем вообще.
2) Набор показателей формируем на основе списка, взятого из литературы, системы, уже реализованного проекта или просто придуманного человеком, в глаза не видевшего измеряемого процесса.
3) Ключевых показателей формируем столько, сколько это возможно в принципе – чем больше, тем лучше.
Номер раз обсуждать не будем – ясно без микроскопа.
Ошибка номер два наиболее логично вытекает из нашей любимой библиотеки ITIL. Там со времен второй версии к KPI относились так, что иногда становилось жутко. Как тонко подметил когда-то один коллега: берем аналогию процесса с автомобилем, где ключевые показатели – спидометр, тахометр и пр. Тогда KPI, приведенные в ITIL v2 – это намек на прибор, измеряющий обороты двигателя в милях, скорость в фаренгейтах и температуру двигателя в градусах. Цельсия или угловых градусах – изволь читающий угадать сам. А еще разработчики ITIL любят давать по несколько штук таких приборов, дублирующих показания в разных шкалах.
О чем говорят эти метрики? Общее количество чего – зарегистрированных, закрытых, открытых за период, или всего в системе? Каким средне- или долгосрочным целям соответствуют метрики? Каковы пороги "удовлетворительно – нормально – хорошо – отлично" для этих метрик? А что делать, если неудовлетворительно, если инциденты сваливаются в backlog мы их закрываем медленнее, чем регистрируем? Количество инцидентов вдруг сократилось на 20%, а потом еще на 30%? Это как, хорошо или плохо? Если хорошо – мы проактивны! Если плохо – чем же мы будем заниматься?
Ну ладно, бог с ITIL'ом. Наша любимая библиотека никогда не акцентировалась особенно на шаге измерения. Спасибо и за цикл Деминга, положенный в основу процессной модели. Возьмем разработанные системы Helpdesk. Их разработчики (о боже!) тоже читали ITIL и умеют фантазировать на тему KPI. Возьмем оттуда, ведь эта система была выбрана нами, а значит там должно быть большинство необходимых отчетов для подсчета KPI. На семинарах часто наблюдаю одна и та же забавную картину, где рабочая группа приступает к проектированию KPI. Процесс спроектирован, теперь его нужно как-то измерять. Хорошо, если в наличии шаблоны реализованных проектов. А давайте посмотрим на существующие наборы KPI? Те, что понравятся – оставим, а остальные додумаем уже потом. Я не то, чтобы против "посмотреть", однако в большинстве случаев такое "посмотрим" приводит к бездумному копированию чужих измерителей эффективности и результативности процесса на свой собственный.
Копирование возможно только в одном случае – если копируемый процесс соответствует поставленным целям, содержит качественные, опробованные KPI и он копируется целиком!
Ошибка номер три, пожалуй, самая известная и распространенная при пользовании ИТ вообще – обусловленная кажущейся легкостью получения данных, годных для отчетности в информационных системах. В момент, когда мы перестаем различать просто данные и информацию (данные, годные для анализа с целью принятия решений), обычно стартует ошибка номер три. "Мы пока сами не знаем, какая именно информацию нам понадобится" – а поэтому давайте разработаем как можно больше отчетности, избыточной, дублирующей друг друга. Отчеты – это же так просто! "Пусть их будет как можно больше, а уж мы точно разберемся, какие использовать" – обычная для многих проектов формулировка. И заказчики процессов управления ИТ стараются не отставать: сколько у вас KPI для процесса? Всего двадцать?! Да вы что, в гроб меня загнать хотите. Конечно нужно больше! И пошла-поехала генерация любых показателей, выдаваемых за KPI.
Ценная информация быстро тонет в бесконечном, фрагментарно обрабатываемом потоке данных. Отсутствует любая, хотя бы самая простая технология проектирования KPI.
Далее, в следующих разделах:
Определим терминологию и типы показателей
Несколько простейших советов, как избежать простых ошибок
Каким образом формировать цели для внедряемого процесса?
Если процесс уже функционирует, нужна ли ему цель?
Наброски к будущей технологии проектирования KPI
Эксперимент - статья на блоге, онлайн
В загашнике давно лежит структура и начало статьи о наболевшем - хорошие практики проектирования KPI (метрик, показателей эффективности, KGI и иже с ними). Тема старая и очень интересная. Есть мысли о том, чтобы сделать простую, работоспособную технологию проектирования KPI.
Увы, но статья эта пишется не в одиночку и делит мои временные ресурсы по остаточному принципу. То есть движения текста за полгода практически никакого. Было принято волевое решение: пишу статью на блоге онлайн, для чего будет заведен специальный тег "article-online" - которым можно будет отделить онлайн-статью от других записей. Ну, или несколько онлайн-статей в будущем, если эксперимент покажет себя успешно.
Поехали: Забудьте о KPI! Часть 1, или основные ошибки.
Подписаться на:
Сообщения (Atom)
