От того как будет организован процесс сопровождения системы зависит эффективность её использования
Проект внедрения завершен, автоматизированная система передана в промышленную эксплуатацию, слышны хлопки шампанского - финальный банкет в самом разгаре, проектная команда исполнителя с чувством выполненного долга покидает объект, руководство заказчика потирает руки в предвкушении ожидаемых от использования АС эффектов, пользователи утирают пот и слезы в надежде, что «такое» больше не повторится. Пока мало кто думает, что от того как будет организован процесс сопровождения системы зависит эффективность её использования.
Первый вопрос, который нужно решить еще до завершения проекта — кто будет обслуживать систему после передачи в промышленную эксплуатацию: собственная служба поддержки в составе IT-подразделения, компания-разработчик системы или другая аутсорсинговая фирма. Собственные специалисты, на первый взгляд, могут показаться предпочтительнее — всегда «под рукой» и готовы решать текущие задачи сопровождения «бесплатно» в рамках существующего бюджета подразделения. Однако в этом случае стоит заранее побеспокоиться о повышении квалификации этих сотрудников — отправить на соответствующие курсы, включить в состав экспертов на период опытной эксплуатации системы. В случае передачи поддержки на аутсорсинг, наличие собственных высококвалифицированных специалистов не обязательно, так как все задачи сопровождения должна решать обслуживающая компания. Выбор обслуживающей компании может оказаться очень «простым», если отсутствует документация на систему, то кроме компании-разработчика другой альтернативы нет. Необходимо заранее позаботиться, чтобы на выходе из проекта все документация не только была в наличии, но и была актуализирована, в этом случае можно избежать жесткой зависимости от компании-разработчика.
Второй вопрос — как будет осуществляться поддержка? Перечень задач, условия и сроки оказания услуг необходимо подробно описать в регламенте сопровождения. В качестве примера можно использовать предлагаемые ITIL (IT Infrastructure Library) соглашения об уровне сервиса SLA (Service Level Agreement), задающие параметры качества предоставляемых бизнесу ИТ-услуг и позволяющие управлять ожиданиями пользователей. Перечень основных разделов SLA:
- Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения.
- Дни и часы, когда сервис будет предлагаться, включая тестирование, поддержку и модернизацию.
- Число и размещение пользователей и/или оборудования, использующих данный сервис.
- Описание процедуры отчетов о проблемах, включая условия эскалации на следующий уровень.
- Описание процедуры запросов на изменение системы.
- Спецификации целевых уровней качества сервиса, включая:
- среднюю доступность, выраженную как среднее число сбоев на период предоставления сервиса;
- минимальную доступность для каждого пользователя;
- среднее время отклика сервиса;
- максимальное время отклика для каждого пользователя;
- среднюю пропускную способность;
- описания расчёта приведённых выше показателей и частоты отчётов.
- Описание платежей, связанных с сервисом.
- Ответственность клиентов при использовании сервиса (подготовка, поддержка соответствующих конфигураций оборудования, программного обеспечения или изменения только в соответствии с процедурой на изменения).
- Процедура разрешения рассогласований, связанных с предоставлением сервиса.
- Процесс улучшения SLA.
Особое внимание следуют уделить проработке списка ключевых показателей эффективности предоставляемых сервисов. Это должны быть измеримые параметры качества, согласованные с бизнес-целями организации. Например, правильно заданный показатель «максимальное время восстановления доступа к системе после сбоя» поможет избежать потерь сотен человеко-часов. Отдельно стоит прописать процедуру реализации дополнительных пожеланий к системе (нового функционала) — как происходит сбор требований, принятие решений о выполнении доработок, оценка стоимости работ, подготовка релиза системы, тестирование и установка в рабочую базу.
Когда регламент сопровождения определен, следует озадачиться подбором или созданием удобного средства регистрации обращений пользователей, которое позволит организовать и контролировать процесс обслуживания. Даже самая простая система, в которой пользователь может в заявке описать проблему и способ её воспроизведения, прикрепить для наглядности скриншот (снимок экрана), позволяет оперативно поручать задачи исполнителям, устанавливать приоритет каждой заявки, плановые сроки её отработки и контролировать их. Добавив в эту систему описание способа решения проблемы и полнотекстовый поиск, можно получить готовую базу знаний, которая сэкономит время не только пользователям, но и самим специалистам поддержки. Так как не нужно будет повторно (по уже задокументированным вопросам) тратить время на выяснение, что это: баг (ошибка программиста); глюк (заблуждение пользователя, неподдающиеся воспроизведению) или фича (недокументированная возможность системы, неожиданная для самого разработчика). Анализируя количество и характер обращений, можно выявлять проблемные места системы и «проблемных» пользователей, которым необходимо повторное обучение, а так же формулировать требования на изменение АСУ, инициировать актуализацию пользовательских инструкций и описания системы. Дополнительно по заявкам можно вести учет трудозатрат и рассчитывать фактическую стоимость обслуживания.
Следование этим простым советам позволит избежать распространенных проблем сопровождения: отсутствия ответственных за решение текущих задач, больших не лимитированных сроков решения вопросов и неконтролируемого роста расходов.