ТОП-5 распространенных проблем при сопровождении корпоративных клиентов и способы их решения

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

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

Чтобы организовать работу, которая устроит как Заказчика, так и Исполнителя, приходится пройти довольно длинный путь – столкнуться с трудностями и невидимыми на первый взгляд препятствиями.

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

Проблема №1. Отсутствие ответственного лица со стороны Заказчика.

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

Решение: Выбор ответственного за сопровождение информационных систем.

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

Проблема №2. Потеря информации при обсуждении задачи.

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

Решение: Ведение системы учета задач.

Использование системы учета задач позволяет пользователям держать все задачи в одном месте, просматривать историю их выполнения, выставлять приоритет, прикреплять файлы и т.д.

В зависимости от потребностей и ресурсов компаниями могут использоваться разные системы: начиная от google таблиц, заканчивая полноценными service desk системами.

Система учета задач на примере google таблицы:

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

Проблема №3. Недостаточное описание ошибки/отсутствие четкого технического задания.

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

Недостаточное описание ошибки при формировании заявки от пользователя влечет за собой трату большого количества времени Исполнителя на её поиск и воспроизведение.

Пример некорректно составленной заявки:

Добрый день! Прошу изменить механизм работы документа.

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

Решение: Формирование регламента по созданию заявок.

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

Одним из возможных вариантов решения проблемы может выступать использование user story. User story – это небольшой сценарий, имеющий формат: Я, как (пользователь продукта), хочу (необходимо описать задачу/действие, которое необходимо пользователю), чтобы (описать ценность, которую он получит). User story описывает функционал так, чтобы всем было понятно, какую ценность пользователю он принесет в итоге.

Пример корректно составленной заявки:

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

При таком варианте заявки соблюдаются все условия user story. Мы видим роль, потребность и получаемую ценность.

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

Пример задачи, требующей предоставление технического задания:

Добрый день! Я, как сотрудник расчетного отдела, хочу видеть доработанный документ «Премия», чтобы я мог получать данные, согласно принятому в нашей компании положению о премировании. Файл с положением во вложении.

Несмотря на то, что задача составлена в соответствии с правилами User story, постановка задачи слишком общая, что влечет за собой множество вопросов после её прочтения.

Проблема №4. Завышенный приоритет у большинства задач.

Для каждого пользователя, создающего задачу, его задача – самая срочная и самая важная. Выставление большей части задач критичного приоритета может повлечь за собой выполнение тех, которые в конечном счете окажутся менее приоритетны, чем другие. Как итог – приоритет потеряет свой смысл, так как большое количество необъективно срочных задач смешается с действительно срочными.

Пример некорректной приоритизации задач:

Из таблицы видно, что на 65 задач, находящихся в работе, приходится 56 критичных, что составляет 86% от общего числа задач. При таком расставлении приоритетов своевременное выполнение действительно критичной заявки практически сводится к нулю.

Решение: Использование Kanban-методики.

Для достижения того, чтобы срочность задач, определяемая пользователями, отражала реальность, очень эффективно обеспечить наглядность выполнения пула задач для Заказчика. Одним из инструментов, с помощью которого это можно сделать, является Kanban-методика.

Основным инструментом Kanban-методики является Kanban-доска – это доска, разбитая на колонки, отражающие этапы рабочего процесса. Количество таких колонок может быть любым, важно только соблюдать их верную последовательность, чтобы увидеть полную цепочку прохождения задачи от принятия в работу до сдачи Заказчику.

Также для методики-Kanban характерно использование WIP-лимитов. WIP-лимиты – это максимальное количество задач, которое может находиться в столбце. Если количество задач достигает максимума по столбцу, то команде необходимо сосредоточить все ресурсы на проблемном столбце и в ближайшее время сдвинуть задачи в другую колонку. Если игнорировать WIP-лимит, то будет расти количество незавершенных задач, что совершенно противоречит главной цели их использования – максимальной скорости прохождения задачи по доске.

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

Пример Kanban-доски:

Все задачи, согласно примеру, разделяются на 3 приоритета:

1. Высокий – красные карточки.

2. Средний – желтые карточки.

3. Низкий – зеленые карточки.

Пример данной Kanban-доски демонстрирует соблюдение главных правил её применения: количество задач не выходит за пределы WIP-лимитов, первоочередно в работу берутся заявки с высоким приоритетом.

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

Проблема №5. Долгое и несвоевременное предоставление обратной связи по задаче.

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

Решение: Подписание соглашения об уровне обслуживания (SLA).

Для того чтобы Заказчик и Исполнитель были удовлетворены выполненной работой, необходимо «на берегу» определить правила работы. Для этого используется такой инструмент, как SLA, в котором могут быть зафиксированы такие параметры, как: 

• скорость реакции на задачу; 

• время принятие задачи в работу с разным типом срочности; 

• сроки предоставления обратной связи по решенным задачам; 

• сроки получения ответов на уточняющие вопросы; 

• матрица разделения ответственности при выполнении задач;

• скорость устранения неисправности. 

Подписанное SLA позволяет сверять Заказчику и Исполнителю ожидания от услуги с реальностью.

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