Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Организационная культура компании оказывает существенное влияние на функционирование первой линии ИТ-поддержки. Если в компании поощряется самостоятельное решение задач, инициативность сотрудников и существует культура обмена знаниями без страха ошибок, сотрудники первой линии могут быть обучены не только регистрировать, но и решать большую часть обращений самостоятельно. В такой среде сотрудники готовы брать на себя ответственность и пробовать решать задачи, даже если у них нет полного опыта. Если же в компании сложилась жесткая иерархическая структура с четким разделением обязанностей, где сотрудники первой линии воспринимаются исключительно как «колл-центр», перестроить такую систему на более гибкий формат работы будет значительно сложнее, даже при наличии всех необходимых условий для расширения полномочий первой линии.
Для некоторых бизнес-процессов более критичны частые кратковременные простои из-за особенностей их работы. Например, в вычислительных процессах, требующих длительного времени на выполнение (научные расчеты, моделирование, сложные аналитические операции), каждое прерывание вынуждает перезапускать процесс, теряя все достигнутое прогресс. Если такой процесс требует 10 часов непрерывной работы, то два простоя по 5 минут в начале и середине процесса могут сделать его невыполнимым, тогда как один 10-минутный простой в конце может быть менее критичен. Аналогично, в системах автоматизации производства перезапуск конвейера после каждого кратковременного простоя снижает общую производительность больше, чем один длительный перерыв, после которого система работает безостановочно.
По мере развития команды и увеличения ее самоорганизации роль тимлида должна трансформироваться и сужаться. На начальных этапах тимлид может активно участвовать в принятии решений и управлении процессами, но по мере роста компетентности команды его роль должна смещаться к консультативной и координирующей. Тимлид может продолжать выступать техническим экспертом в сложных областях, но большую часть управленческих функций необходимо равномерно распределить между членами команды. В идеале, по мере взросления команды, формальная роль тимлида должна трансформироваться в неформальную роль среди нескольких лидеров, которые периодически берут на себя ответственность за разные аспекты работы в зависимости от текущих потребностей.
В системе Kanban отсутствует визуализация временных потерь, потому что её основная задача — организация и управление потоком работ, а не анализ и выявление неэффективностей. Kanban фокусируется на том, чтобы регулировать поступление задач в систему, контролировать их прохождение через различные этапы и предотвращать перегрузку отдельных участков процесса с помощью ограничений WIP. Для анализа временных потерь и оптимизации процесса обычно используется инструмент, такой как карта потока создания ценности (VSM), который позволяет подробно оценить не только активное время работы, но и время ожидания на каждом этапе процесса.
Для предотвращения злоупотребления периодами ожидания ответа пользователя необходимо внедрить систему контроля за такими паузами. Следует установить лимиты на время ожидания ответа и автоматически начинать отсчет времени решения снова после определенного периода неактивности. Также важно внедрить механизмы анализа, чтобы выявлять ситуации, когда специалисты необоснованно часто запрашивают дополнительную информацию. Регулярный аудит случаев превышения сроков поможет определить закономерности и принять соответствующие меры по оптимизации процессов.
Основное отличие обработки заявок от обработки инцидентов заключается в том, что заявки связаны с запросами на стандартные услуги или изменения (предоставление прав, настройка рабочего места), тогда как инциденты возникают при нарушении нормальной работы систем. Однако процедура проверки и закрытия заявок во многом схожа с процедурой обработки инцидентов: после выполнения работ необходимо получить подтверждение от пользователя о том, что все сделано верно, и только после этого закрыть заявку или инцидент. Это обеспечивает высокое качество обслуживания и контроль выполнения запросов.
После выявления «известной ошибки» она документируется в специальной базе данных известных ошибок (KEDB - Known Error Database). В запись об ошибке включается информация о корневой причине, описании проблемы, временном обходном решении (workaround), а также данные о влиянии на бизнес и истории связанных с ней инцидентов. Эта информация используется при возникновении аналогичных инцидентов для быстрого применения известного обходного решения. Запись поддерживается в актуальном состоянии и обновляется по мере получения новых данных или поиска постоянного решения проблемы.
При определении влияния изменения инфраструктуры учитываются все компоненты, которые связаны с определенной ИТ-услугой. Это могут быть серверы, сети, базы данных, программные приложения и другие ресурсы. Учет таких связей позволяет определить, какие именно услуги затронет обновление конкретного элемента инфраструктуры, например, обновление сервера. Для этого необходима информация о том, какие ИТ-услуги зависят от данного элемента.
Кроссфункциональность команды предполагает, что команда обладает всеми необходимыми навыками для выполнения задач без внешней помощи, но не требует, чтобы каждый член команды был универсалом во всех областях. Роль тимлида может как поддерживать, так и мешать кроссфункциональности. Если тимлид выступает исключительно как управленец без технической экспертизы, он может создавать разрыв между техническими и организационными аспектами работы. Если же тимлид фокусируется на том, чтобы распределять ответственность и создавать структуры для обмена знаниями, он может способствовать развитию кроссфункциональности. Однако в идеале распределение экспертизы и ответственности должно происходить на уровне всей команды, а не через одного лидера.
Этап трансформации начинается с принятия решения об инвестировании в преобразование и включает поддержание необходимого уровня гибкости организации, целевую работу с областями, выпадающими из процесса изменений, системное внедрение новых практик, процессов и инструментов, перераспределение ролей и ответственности, изменение взаимоотношений с партнерами, уход от устаревших конструкций управления, обеспечение начальной стабильности новых структур, измерение текущего состояния по отношению к целевому и личное участие в изменении системы управления организацией.