Изменение графика предоставления ИТ-услуг, например, сокращение окон обслуживания, может требовать корректировки работы определенных компонентов инфраструктуры. Это может затрагивать серверы, сети, системы хранения данных и другие ресурсы, которые обеспечивают предоставление услуги в течение установленного времени. Для определения конкретных элементов, на которые повлияет изменение, необходимо заранее знать, какие ресурсы связаны с данной услугой.

Для полномочий координаторов изменений необходимо установить четко определенные ограничения, которые балансируют между гибкостью процесса и контролем качества: - Границы самостоятельных решений: определить, какие типы изменений координатор может утверждать самостоятельно, а для каких требуется дополнительное согласование с руководством или экспертом. - Временные ограничения: установить временные рамки для реализации изменений разного уровня риска, включая запрет на проведение критических изменений в определенные периоды (например, в часы пиковой нагрузки). - Ограничения по типам систем: определить, какие ИТ-системы или инфраструктурные компоненты требуют повышенного уровня контроля при внесении изменений. - Требования к документированию: установить обязательные требования к документированию изменений, включая необходимость предоставления результатов анализа влияния, плана отката и подтверждений согласования. - Пределы корректировки стандартных процедур: определить, какие параметры стандартных изменений координатор может изменять самостоятельно, и до каких пределов (например, небольшие отклонения от стандартного времени выполнения). - Уровень ответственности: четко определить уровень финансовой и операционной ответственности координатора за последствия принимаемых решений. - Требования к компетенциям: установить минимальные требования к знаниям и опыту сотрудников, которым могут быть предоставлены расширенные полномочия. Эти ограничения должны быть сформулированы таким образом, чтобы координаторы могли эффективно выполнять свои обязанности, не прибегая к постоянным согласованиям всех мелких деталей, сохраняя при этом необходимый уровень контроля за рисками.

Чтобы определить, какие элементы ITIL подходят для конкретной организации, нужно проанализировать характеристики предоставляемых услуг: если услуги основаны на сложных взаимосвязанных компонентах, постоянно меняются, адресованы конечным пользователям и построены на взаимодействии множества участников, можно использовать широкий спектр процессов ITIL (управление релизами, поставщиками, конфигурациями и др.). Если же услуги проще и основаны преимущественно на деятельности персонала, стоит обратить внимание на управление уровнем услуг, инцидентами и знаниями. Важно не пытаться внедрить все аспекты ITIL, а выбрать те, которые действительно помогут в построении или улучшении сервисной модели данной организации.

Согласно SLA-подходу, работа отдела маркетинга заключается в привлечении и качественной подготовке потенциальных клиентов для отдела продаж. Маркетинг оценивается по числу и качеству контактов потенциальных клиентов, которые были переданы отделу продаж. Работа отдела продаж, в свою очередь, заключается в конверсии этих потенциальных клиентов в реальные продажи. Продажи оцениваются по числу клиентов, которым удалось что-то продать, после чего клиенты передаются далее по цепочке на оказание услуг или поставку товаров. Таким образом, SLA чётко разграничивает ответственность и показатели эффективности каждого из этих подразделений.

Для обоснования необходимости выделения дополнительных ресурсов необходимо: 1. Провести тщательный анализ и подкрепить проблему конкретными, измеримыми данными, показывающими текущее состояние процесса и негативную динамику 2. Четко определить конкретные факторы, негативно влияющие на производительность и их количественное воздействие 3. Сформулировать план мероприятий с учетом ресурсных потребностей для каждого конкретного действия 4. Показать негативные последствия для бизнеса и пользователей от текущей ситуации, подчеркивая, что проблема уже проявляется на клиентах 5. Указать на заинтересованность всех участников ИТ в нормализации ситуации 6. Предложить не просто решение проблемы, а конкретные сроки, этапы реализации и ожидаемые результаты Важно подойти к вопросу предметно, опираясь на данные и факты, а не на субъективные оценки, и обеспечить прозрачность как для исполнителей, так и для лиц, выделяющих ресурсы.

Информирование пользователя по статусу доработки ПО должно быть систематическим и прозрачным. При использовании статуса 'доработка' с остановленным таймером пользователь может отслеживать прогресс через систему управления инцидентами. При закрытии инцидента с особым кодом необходимо наладить отдельный механизм информирования, например, автоматические уведомления при обновлении связанного запроса на доработку или регулярные отчеты от ответственного менеджера. Важно обеспечить понятные статусы и ожидаемые сроки, а также контактную информацию для уточнения деталей.

Базовая ролевая модель представляет собой срез текущих прав сотрудников, полученный автоматическим анализом, и служит основой для разработки окончательной бизнес-ролевой модели. Автоматически сформированные роли не всегда точно отражают реальные бизнес-роли сотрудников, так как могут не учитывать уникальные права или нюансы, характерные для конкретных бизнес-процессов. Окончательная бизнес-ролевая модель требует дополнительного ручного анализа и корректировки для обеспечения полного соответствия бизнес-требованиям и процессам.

В менеджменте распространена классификация процессов на три основные категории: управленческие процессы, которые связаны с руководством и контролем деятельности организации; основные процессы, непосредственно связанные с производством товаров или услуг и созданием ценности для клиентов; обеспечивающие процессы, которые поддерживают основные и управленческие процессы, включая административные, технические и иные вспомогательные функции. На производственных предприятиях иногда выделяют также вспомогательные процессы, но основная структура включает три указанные категории.

В сервисных отношениях с точки зрения потребителя существуют два типа затрат: затраты, снимаемые с потребителя услугой (часть ценностного предложения), которые включают расходы на персонал, технологии и другие ресурсы, которые потребитель нес бы сам без услуги; и затраты, налагаемые на потребителя услугой (затраты на поддержку услуги), включающие цену, взимаемую поставщиком, обучение персонала, расходы на сеть, закупку расходных материалов и другие операционные расходы, связанные с использованием услуги.

К внешним рискам, препятствующим движению задач в ИТ-разработке, относятся: отсутствие синхронизации с другими командами в случае жестких интеграционных зависимостей; изменения в тестовых средах, API или среде эксплуатации, которые могут заблокировать процесс; необходимость согласования с заинтересованными сторонами, такими как заказчики, подрядчики, служба безопасности и другими стейкхолдерами. Эти риски возникают вне непосредственного контроля разработческой команды, но могут серьезно замедлить процесс, если не были выявлены и учтены еще на этапе формирования очереди задач.