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

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

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

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

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

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

Существует три основных взаимосвязанных стандарта, регулирующих использование Role-Based Access Control: INCITS 359-2012 «Information Technology - Role Based Access Control», который содержит референтную модель ролевого управления доступом; INCITS 494-2012 «Information technology - Role Based Access Control - Policy Enhanced», являющийся дополнением к первому стандарту в части обработки динамических ограничений; и INCITS 459-2011 «Information Technology - Requirements for the Implementation and Interoperability of Role Based Access Control», описывающий допустимые сочетания компонентов и интерфейсы. Первые два стандарта определяют модель и функциональные возможности RBAC, а третий обеспечивает совместимость и правильную комбинацию компонентов.

Объемный документ "описание процесса" не подходит для рядовых специалистов, потому что их работа в рамках процесса часто ограничена выполнением одной процедуры. Для выполнения своих обязанностей им не нужно знать все детали процесса, а достаточно иметь общее представление о нем и понимать свою роль. Читать документ объемом, например, в 80 страниц, когда необходимо знать лишь узкий участок работы, нецелесообразно. Таким сотрудникам больше подойдут ролевые инструкции, детализирующие их непосредственные задачи.

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

Указание основания для обращения в деловом письме важно, так как оно отвечает на вопрос получателя: «По какой причине ко мне обращаются?». Основание может быть, например, «На основании приказа №…», «По результатам встречи…» или «В продолжение переговоров по телефону…». Отсутствие основания может значительно затруднить или затянуть процесс принятия решения по письму, так как получатель не будет понимать, откуда взялся запрос и на чем он основан. Наличие четкого основания усиливает легитимность запроса и помогает получателю быстрее оценить его приоритетность и важность.