Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Чтобы сделать процесс заполнения форм удобным, необходимо следовать нескольким принципам: вопросы должны быть минимальными и понятными, вместо текстового ввода, по возможности, должны быть списки для выбора (например, выбор модели принтера из предустановленного списка, а не ручной ввод). Для обязательного текстового ввода необходимы подсказки с примерами или шаблонами. Это снижает вероятность ошибок и упрощает заполнение. Также важно разработать интерфейс, который направляет пользователя логическим путем, без необходимости переключения между разделами или сложных многоуровневых меню.
Основные формы сопротивления включают: утверждения о ненадежности данных и сложности сбора метрик, декларирование непонимания процесса измерений несмотря на обучение, критику предложенных метрик без конструктивной альтернативы, некорректное заполнение систем учета по принципу 'garbage in - garbage out', пассивное игнорирование требований к измерению. Такое сопротивление замедляет трансформацию и снижает эффективность изменений в управлении процессами.
Для оценки и прогнозирования уровня доступности метод FTA используется следующим образом: после построения дерева отказов и идентификации всех базовых событий (простейших возможных сбоев) собирается статистика по частоте или вероятности этих базовых событий. Используя логические операторы («и», «или» и т.д.) дерева, вычисляется вероятность достижения топ-события (отказа конкретной функциональности). Эта вероятность позволяет рассчитать ожидаемое время простоя и, соответственно, фактический уровень доступности. Имея прогнозы по базовым событиям, можно также спрогнозировать будущие уровни доступности при изменении конфигурации системы или инфраструктуры. Это мощный инструмент как для обоснования инвестиций в повышение надежности, так и для согласования SLA с заказчиками.
На этапе стратегического планирования BRM (Business Relationship Management) выполняет несколько ключевых функций. BRM должен держать руку на пульсе изменений в бизнесе заказчика и знать его текущую деятельность, задачи и структуру спроса на услуги. Это позволяет ИТ-функции своевременно реагировать на изменения. BRM выступает представителем сервис-провайдера в ключевых дискуссиях по стратегии заказчика. Задачи BRM на этом этапе включают коммуникацию стратегических целей заказчика ИТ-специалистам, что позволяет переоценить ИТ-стратегию, проанализировать возможности и риски, а также пересмотреть портфель услуг. BRM обеспечивает постоянную связь между бизнес-требованиями и ИТ-планами, учитывая, что бизнес-потребности меняются в зависимости от внутренних и внешних факторов.
Роль агента изменений на начальном этапе перехода к продуктовому подходу заключается в том, чтобы помочь команде понять текущее состояние процессов, определить необходимые изменения и выстроить маршрут движения по дорожной карте развития. Агент изменений действует как наставник, а не как нянька, сопровождая команду на первых этапах, когда сопротивление к изменениям максимально велико. Продолжительность такого сопровождения обычно составляет 3-4 месяца, после чего команда должна стать достаточно зрелой для самостоятельного продвижения по намеченному маршруту. Длительное сопровождение тем же специалистом становится неэффективным и слишком затратным.
Успешность преобразования теоретических знаний в практические навыки при обучении сервисному подходу зависит от нескольких факторов. Во-первых, от способности участников осознавать необходимость уточнения требований у заказчика и выходить за рамки школьного стереотипа «решать задачу с тем, что дано». Во-вторых, от наличия тренировки в создании условий для диалога с клиентом и формирования привычки уточнять информацию. В-третьих, от индивидуальных особенностей сотрудников — некоторым проще выстраивать сервисные отношения из-за внутренней склонности к общению. Однако ключевую роль играет не только выбор правильных кандидатов, но и систематическое развитие у всех сотрудников навыков активного взаимодействия с клиентами через регулярные практические упражнения.
Крупные компании предпочитают самостоятельно подготавливать агентов изменений, а не нанимать их извне, потому что внешние специалисты все равно требуют глубокого погружения в контекст конкретной организации: принятые стандарты разработки, качества, особенности корпоративной культуры и исторически сложившийся ИТ-ландшафт. Наличие собственных агентов изменений, подготовленных с учетом стратегических целей компании, позволяет достичь единого видения целей развития на системном уровне и избежать деятельности ради деятельности без измеримого результата. Это также более экономически эффективно в долгосрочной перспективе, несмотря на первоначальные затраты на подготовку.
Данные о поведении клиентов объективно отражают, что произошло, в отличие от высказываний, которые могут искажаться из-за субъективности восприятия, желания угодить или непонимания своих истинных мотивов. Например, клиент может сказать, что ценит быстрое обслуживание, но при этом часто прерывает процесс из-за сложных шагов интерфейса. Только анализ реальных действий позволяет выявить такие противоречия и понять, какие элементы клиентского пути требуют улучшения. Поэтому ключевой принцип CXM — опираться на поведенческие метрики, а не только на обратную связь в формате опросов.
Для улучшения пользовательского опыта важно сделать интерфейс портала максимально интуитивным и простым. Не стоит перегружать пользователя многоуровневыми меню и большим количеством опций — вместо этого следует вывести в первые уровни наиболее часто используемые категории обращений. Кроме того, вопросы в форме должны быть минимальными, понятными и, по возможности, иметь подсказки или выбор из списка. Пользователь должен четко видеть выгоду от использования портала — например, более быструю обработку его запросов. Также важно обеспечивать обратную связь по статусу обращения, чтобы пользователь понимал, что его заявка обрабатывается.
Переход крупной ИТ-организации полностью на гибкие методы маловероятен и часто нецелесообразен по нескольким причинам. Во-первых, масштабная ИТ-инфраструктура с сотнями систем содержит множество legacy-систем и процессов, которые не могут быть быстро изменены без риска нарушения критически важных бизнес-процессов. Во-вторых, различные части организации имеют разные потребности: некоторые системы требуют стабильности и предсказуемости, тогда как другие могут развиваться быстро и гибко. В-третьих, не все сотрудники готовы или могут работать в гибкой среде, особенно если организация долгие годы использовала традиционные методы. Поэтому вместо полного перехода к гибким методам рациональнее применять бимодальный подход, где часть систем и команд работает по традиционным методам, а часть - по гибким, с акцентом на координацию и взаимодействие между этими режимами.