Для команды на уровне «Зрелость» нужен не лидер-слуга и даже не лидер-наставник, а лидер-партнер с особыми характеристиками: он должен быть наделен полномочиями, достаточными для поддержки командных инициатив на высоких уровнях компании; обладать широкой осведомленностью о стратегическом направлении развития компании, чтобы донести его до команды; иметь достаточный авторитет внутри организации для интеграции целей команды с общекорпоративными целями. Лидер-партнер выступает как связующее звено между командой, которая стала агентом изменений и стремится расширить свою зону влияния, и высшим руководством компании. На этом уровне команда полностью контролирует свой рабочий процесс и несет ответственность за продукт на уровне P&L, поэтому лидер должен фокусироваться на создании условий для дальнейшего развития и реализации стратегических инициатив.

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

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

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

Основные направления развития современной системы управления ИТ в Enterprise включают: - Создание мощной службы HR внутри ИТ-подразделения, которая будет активно искать таланты, решать вопросы найма, вовлечённости, мотивации и развития персонала. - Переход от традиционных иерархических структур к альтернативным принципам управления, таким как продукты вместо проектов, самоорганизующиеся команды вместо отделов, коллективная ответственность вместо тим-лида, управление задачами вместо управления людьми. - Развитие внутренних сообществ по ролям и по интересам, организация митапов, обмена находками и идей, совместной работы над исследованиями и разработками (R&D).

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

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

Предложены следующие основные процедуры процесса управления ИТ-финансами: 1) Построение модели учета и аллокации ИТ-затрат; 2) Бюджетирование и тарификация; 3) Обеспечение учета затрат и доходов; 4) Анализ и поиск возможностей по оптимизации затрат; 5) Формирование отчетов и информирование заинтересованных сторон.

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

Этап регистрации заявок в системе самообслуживания должен предусматривать возможность заполнения специализированных форм, которые отличаются по типам заявок. Должен быть реализован контроль данных на форме: обязательные поля, проверка корректности ввода и максимально возможное использование справочников. Пользователи должны иметь возможность указывать список сотрудников в одной заявке, например, когда руководитель одновременно запрашивает доступ нескольким подчиненным. Также важно разделить понятия «заявитель», «пользователь» и «контактное лицо», чтобы четко определить, кому и когда направлять уведомления и запросы в ходе обработки заявки.