В процессе подготовки и сдачи экзаменов уровня Intermediate потока Capability (SOA, PPO, RCV, OSA) выработал для себя ряд правил, которые помогают найти правильный ответ или по крайней мере отсеять заведомо неправильный. Делюсь.
Все должности и роли в процессном управлении являются
необходимыми для правильного функционирования всей системы. Но есть несколько
высокоуровневых стратегических ролей, качество исполнения которых влияет на всю
систему целиком. Одна из таких ролей – Business Relationship Manager. Человек, который
должен одновременно понимать потребности бизнеса и обладать достаточными
полномочиями чтобы открывать двери в необходимые кабинеты, а с другой стороны
иметь хорошую техническую подготовку и опыт в сфере IT чтобы правильно перевести потребности
бизнеса на «птичий» язык айтишников.
Пожалуй, самый животрепещущий вопрос управления – что и как
измерять, чтобы контролировать процесс. Как выбрать показатели, которые будут
адекватным образом отражать положение дел, и что из них должно стать KPI для сотрудников?
Этим материалом начинаю цикл статей, посвящённых измерениям
процессов в IT. Сегодня
про основы.
Про четвёртый выпуск свода знаний ITIL не писал, наверное, только самый
ленивый. Я, похоже, очень ленивый, и добрался написать только сейчас. Решил
собрать в одном материале всё что на данный момент известно про ITIL 4 и схемы сертификации.
Вдохновившись идеями библиотеки ITIL решил попробовать внедрить у себя
систему оценок, которую пользователи ставят за выполнение обращений в службу
технической поддержки. После недолгих манипуляций с нашей ServiceDesk системой запилили
функционал. Разослали пользователям инструкции о том как выставлять оценки,
подкреплённые просьбой выставлять оценки за закрытые задачи. Но что-то пошло не
так…
Вместо предисловия, выдержка из ITIL Service Strategy:
«Многие компании верят, что приобретя или разработав какой-то инструмент, все их проблемы будут сразу решены. Но очень просто забыть о том, что они всё ещё зависят от процессов, функций и, что особенно важно, людей. И запомните – дурак с инструментом – всё ещё дурак».
Сегодня мои размышления про выбор программного обеспечения.
Краткое пособие о том как прочитать процесс, описанный с помощью IDEF0 нотации.
IDEF0 — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Традиционно применяется для описания процессов в укрупнённых блоках, с указанием связей между ними. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность.
Начальная страница диаграммы содержит только один блок. Это «чёрный ящик», описывающий предметную область или систему в целом. Все остальные страницы называются «декомпозицией» и могут содержать произвольное количество функциональных блоков.
Мы все любим себя. В той или иной степени. Гордимся своими достижениями и стараемся при возможности их показать. Это очень сильно заметно например в тренажёрном зале. Не успел ты набрать (ну, или сбросить, в зависимости от целей) 1-2 кило как уже вместо эффективных занятий всё чаще заглядываешь в зеркала, так удачно развешанные по всему залу, поигрывать мышцами на публику и всячески себя со всех сторон осматривать. Думаю, многим такое знакомо. Признаюсь честно, я тоже вёл себя так и очень быстро заметил, что результаты приходят медленнее, а тренировка становится не такой эффективной. Я нанял тренера, который составил мне программу тренировок и ходил за мной по залу от первого до последнего упражнения. Всё записывал и контролировал. И что произошло? Правильно, тренировка стала эффективнее, результаты заметнее и приходили быстрее. И вот какая мысль мне пришла в голову. А ведь очень часто так же происходит и с организацией работы. Ты выстраиваешь систему управления, налаживаешь процессы, пишешь регламенты и правила и дико гордишься тем, как у тебя всё хорошо работает. Но так ли это на самом деле? Читать далее
Разбирали намедни с системным архитектором очередной запрос от пользователя. С одной стороны, требования понятны, пользователь ясно изложил пожелания, оценил эффект от реализации пожелания, всё по правилам и инструкциям. Но вот какая незадача. Прорабатываешь варианты реализации, и уже на подкорке головного мозга понимаешь что местами в заявке написано что-то неадекватное, что придётся делать кучу проверок разного рода, что придётся писать очень строгие правила ролевых ограничений. И всё по одной причине: подсознательно считаешь что пользователь — это некая мифическая неадекватная личность, способная на непредсказуемые действия. И уж ни в коем случае не стоит надеяться на то, что пользователь будет делать так, как заложен алгоритм работы, а попытается с помощью бухгалтерской системы запускать ядерные боеголовки. И меня очень сильно заинтересовал вопрос о том, откуда же такое отношение появилось и можно ли что-то с этим сделать? Мои размышления на эту тему ниже.