Портал №1 по управлению цифровыми
и информационными технологиями

Press any key...

На недавно проведенном учебном курсе "Основы ITIL" возникла дискуссия. Курс корпоративный, соответственно трудности слушателей общие, и их хочется dummy vs computerколлективно обсудить. 

Проблема состоит в низком уровне компьютерной грамотности бизнес-пользователей. Причем довольно серьезная, вплоть до того, что ИТ-специалистам приходится удаленно входить в компьютер пользователя и выполнять бизнес-операции за пользователя, или чтобы понять суть ошибки, то есть что конкретно у него "сломалось". А в контексте проекта, в рамках которого все и собрались на курсе, проблема навыков работы с компьютером бизнес-пользователей вырастает в разы.  

Становится очевидным, что при внедрении любой услуги\системы автоматизации, требования должны быть двусторонние, — как бизнеса к услуге, предоставление которой обеспечивает ИТ, так и ИТ к бизнесу — какой объем навыков должен иметь пользователь для работы с данной услугой\системой. И об этом, кстати, говорит стандарт ISO 38502. Он, собственно, про руководство ИТ, но в нем есть также и требования к использованию ИТ организацией с декомпозицией до бизнес-пользователей, — какими навыками должен обладать бизнес пользователь при выполнении своих операций с помощью тех инструментов, систем, которые предоставляет ИТ.  

То есть при планировании ввода в эксплуатацию новой услуги бизнесу нужно подумать о том, смогут ли этой услугой в полном объеме пользоваться его люди. Отсюда, как следствие, сможет ли ИТ предоставлять её на согласованном уровне, в рамках SLA. 

Что можно предложить?

  1. Оцените общий уровень грамотности бизнес-пользователей и масштаб бедствия. Если проблема масштабная, ищите кардинальные меры. Выводите проблему на уровень выше. Подготовьте учебные материалы, используйте внешних провайдеров обучения, подумайте про дистанционные курсы (они дешевле), запустите инициативу по обучению, отведите разумное время – к какому сроку эти задачи должны быть решены.  Определите требуемое целевое состояние, зафиксируйте что такое минимальный уровень грамотности любого пользователя, договоритесь что будет с теми, кто по итогам года его не достиг, как они будут обслуживаться (если будут). Это требования к профпригодности персонала, работающего с информацией, на которой строится работа организации.
  2. Если проблема имеет не масштабный характер, а есть отдельные слабые места – фиксируйте в регламентирующих документах или SLA требуемый уровень квалификации пользователя и определите зоны ответственности в ситуации, если уровень ниже, например, должны ли ИТ специалисты обучать пользователей компьютерной грамотности? В каком объёме? Кого? Когда? Каким способом?
  3. Если в целом всё хорошо, но странные вопросы приходят – ведите FAQ, отправляйте туда. Подумайте над правилом «Третий раз не отвечаем на один и тот же глупый вопрос, а отправляем в базу знаний по ссылке, на четвёртый раз информируем руководство». Ведите анализ того сколько и какие статьи читались, подумайте над проведением массового обучения по этим темам.

В моем прошлом опыте эти требования фиксировались в специальном документе, регламентирующем обязательства по вопросам обучения обеих сторон . По-моему, это было обоснованно, и опять же, сохраняло ответственность того, кто предоставляет обучение только в том объеме, за который он брался. Обучить работе с SAP\Oracle\etc не равно научить пользоваться компьютером в объеме простого пользователя. 

Возникают ли у вас такие сложности, и как вы с ними справляетесь?1356801743_babushka-kompyuter

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT