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

При замене системы необходимо: 1) Составить перечень архивируемых системных ролей из старой системы и новых ролей из новой. 2) Создать таблицу соответствия 'старая-новая' роль для выявления аналогов. 3) Архивировать роли старой системы после перехода и обновить бизнес-роли (которые включали старые системные роли), заменив их на новые. 4) Назначить пользователям обновлённые бизнес-роли через новые записи доступа. Например, если в старой системе роль 'Кассир' соответствует новой роли 'Оператор кассы', бизнес-роль 'Финансовый сотрудник' будет перестроена под новый набор системных прав.

Актуализацией матрицы бизнес-ролей должна заниматься отдельная структура внутри компании, объединяющая представителей ИТ и ключевых бизнес-подразделений. Эта группа отслеживает изменения в бизнес-процессах (например, появление новых задач или реорганизацию отделов), согласовывает обновления ролей и внедряет их в систему. Например, если в маркетинговом отделе внедряется новый инструмент аналитики, группа определяет, какие роли должны получать доступ к нему, и корректирует матрицу. Без такой структуры матрица быстро устаревает, что приводит к несоответствию прав реальным задачам сотрудников.

Система мотивации играет ключевую роль в управлении процессами, так как она напрямую влияет на вовлеченность сотрудников. Когда соблюдение процессов связано с материальными или нематериальными стимулами, вероятность их добровольного исполнения значительно повышается. Мотивация помогает сформировать культуру ответственности, снижает уровень сопротивления изменениям и способствует постоянному улучшению процессов через активное участие сотрудников.

Управление рисками требует оценки не только вероятности возникновения проблем, но и их потенциального влияния на бизнес-результаты. Например, проблема с системой резервного копирования может иметь низкую вероятность проявления, но если при сбое данные будут потеряны, это может привести к остановке производства и убыткам. Понимание этого влияния позволяет выделить больше ресурсов на предотвращение таких проблем, даже если они технически сложны в решении, что снижает общий уровень риска для бизнеса.

Продуктовый подход не стоит применять к управлению ИТ-системами, если система является внутренней, приобретенной сторонней разработки и кастомизируемой для автоматизации бизнес-процессов компании. В таких случаях обычно отсутствуют ключевые критерии продуктового подхода: динамически меняющиеся возможности, высокая неопределенность и необходимость в активном развитии продукта для целевой аудитории. Например, когда речь идет о внутренней системе для отдела логистики или бухгалтерии, где требования относительно стабильны, а целевая аудитория не платит за использование системы, применение таких практик продуктового подхода как CustDev или измерение retention становится нецелесообразным. В этом случае проектный подход может быть более эффективным.

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

Практическую пользу от использования CMDB можно обеспечить, сначала определив, какие именно данные необходимы сотрудникам для их повседневной работы. Это требует общения с заинтересованными сторонами для понимания их потребностей и рабочих процессов. После этого необходимо настроить CMDB так, чтобы она предоставляла именно ту информацию, которая упрощает работу сотрудников. Важно также провести обучение, чтобы показать, как использовать систему для решения конкретных задач, и внедрить механизмы мониторинга использования, чтобы регулярно улучшать качество и релевантность данных. Регулярная демонстрация успешных кейсов использования CMDB также способствует повышению её ценности.

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

Пороги производительности — это установленные временные или количественные рамки, превышение которых расценивается как недоступность услуги. Например, для электронной почты порогом может быть время задержки при отправке или получении писем, выходящее за определенный временной интервал. Если сервис работает, но время ответа превышает установленный порог, это учитывается как период недоступности в расчетах уровня доступности.