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