Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Термин «аутсорсинг бизнес-процесса» может быть неточным, так как модель сорсинга изначально подразумевает привлечение ресурсов, а не организации процессов. Процесс как форма управления ресурсами и деятельностью должен существовать внутри организации. Предоставляться извне могут непосредственные функции и ресурсы, но не сам процесс управления. Когда поставщик берет на себя управление, заказчик переходит в режим governance (руководства), где управление ресурсами уже не требуется. Следовательно, речь идет не об аутсорсинге процесса, а об аутсорсинге функций внутри этого процесса.
Математический аппарат методики агрегирования KPI с динамическими весами описывается как не сложнее линейных функций. Основная идея проста: это взвешенное среднее, где вес каждого KPI зависит от его значения (чем ниже значение, тем выше вес). Параметром, который управляет системой, является MS (Marginal Score), определяющий, какое значение получит интегральный показатель при полном провале одного из KPI при условии, что остальные выполнены на 100%. Расчет весов и интегрального показателя осуществляется с использованием относительно простых математических зависимостей, что делает методику доступной для практического применения без сложных вычислений.
Преимущества ручного учета трудозатрат включают большую гибкость и точность в отражении реальной работы, возможность учета непредвиденных обстоятельств и сложных ситуаций, которые автоматические системы не могут распознать. Сотрудник может сам определить, сколько времени действительно было затрачено на решение конкретной проблемы, включая время на ожидание, координацию и внеплановые действия. Также ручной учет позволяет учитывать субъективную сложность задач, которую невозможно формализовать в автоматизированных системах.
Для борьбы с несанкционированными изменениями в программном обеспечении рекомендуется внедрение строгих практик управления доступом и управления изменениями. Это включает проверку и утверждение изменений перед внедрением, разделение полномочий между разработчиками, тестировщиками и администраторами, использование систем контроля версий, проведение аудитов изменений. Также необходимо регулярно обучать персонал политикам безопасности и процедурам управления изменениями, а также внедрять автоматизированные инструменты для мониторинга и регистрации всех изменений в системе.
Использование RASCI-матрицы по сравнению с RACI-матрицей дает следующие преимущества: 1. Возможность более детального распределения ролей за счет добавления позиции S (Supports), которая позволяет отделить тех, кто непосредственно организует работу, от тех, кто просто участвует в ее выполнении. 2. Уменьшение вероятности путаницы в ответственности, когда несколько человек имеют статус R (Responsible), так как становится ясно, кто именно отвечает за организацию процесса, а кто просто оказывает поддержку. 3. Более точное определение зон влияния и контроля для каждого участника проекта, что особенно важно при работе с большими командами. 4. Возможность для руководителей сохранять контроль за процессом через позиции I (Informed) и C (Consulted), даже делегируя фактическое исполнение. 5. Упрощение процесса делегирования задач, так как четко видно, какие функции можно передать без потери контроля над ключевыми аспектами работы.
Какие стратегии помогают в создании привлекательной картины будущего при организационных изменениях?
Стратегии создания привлекательной картины будущего включают: 1) Определение конкретных, измеримых преимуществ изменений для разных групп сотрудников и бизнеса в целом. 2) Использование ярких примеров и историй успеха из практики других компаний или внутренних пилотных проектов. 3) Визуализацию будущего состояния через образы, диаграммы, макеты или демонстрационные версии. 4) Связь будущего состояния с ценностями и миссией компании, делая изменения частью более крупной и значимой цели. 5) Демонстрацию пошагового пути к достижению будущего, чтобы он воспринимался достижимым. 6) Активное вовлечение сотрудников в формирование элементов будущего, что создает чувство собственности над изменениями. 7) Регулярное напоминание о том, что текущее состояние не является стабильным и что неизменность может привести к большему риску, чем изменения. 8) Указание на то, как изменения будут упрощать работу сотрудников, повышать их профессиональный рост или улучшать условия труда.
Для формирования управленческой архитектуры в формате потока ценности необходимы конфигурационная архитектура процессов производства товаров и услуг (бизнес SCMS или CMDB), визуализация путешествия потребителя ценности, а также установление актуальных связей между всеми этими элементами. Только при взаимодействии всех этих компонентов поток ценности может стать эффективным инструментом управления бизнесом.
При реализации изменений через SIP могут быть использованы различные организационные инструменты. Примерами таких инструментов являются механизмы HR-службы (для управления персоналом и вовлеченностью сотрудников), проектного офиса (для контроля выполнения проектов и сроков), а также другие внутренние процессы организации, направленные на управление изменениями. Эти инструменты помогают обеспечить ответственность за выполнение задач, контроль прогресса и решение возникающих сложностей при реализации изменений по улучшению услуг.
Справочник кодов закрытия – это перечень стандартных причин завершения обработки инцидентов, используемый в системах управления инцидентами. Он нужен для обеспечения единообразия в классификации результатов обработки инцидентов, упрощения анализа статистики закрытых обращений, контроля качества обслуживания и формирования отчетности. Наличие четкого справочника помогает избежать субъективности в закрытии инцидентов и обеспечивает прозрачность процесса для всех участников.
Для предотвращения ситуации параллельной работы нескольких линий поддержки над одной заявкой необходимо внедрить четкий механизм оповещения всех заинтересованных сторон о факте эскалации заявки. Это может быть автоматическое уведомление специалисту предыдущего уровня при автоматической передаче заявки на следующий уровень, с требованием прекратить работу над ней. Также важно настроить систему так, чтобы при эскаляции заявки она автоматически становилась недоступной для редактирования или продолжения работы специалистом предыдущего уровня. Дополнительно можно внедрить обязательное подтверждение передачи ответственности между уровнями поддержки, чтобы каждый следующий уровень получал заявку только после официального завершения работы предыдущим уровнем. Это предотвратит дублирование усилий и повысит общую эффективность процесса.