Вы успешно подписались на блог Naumen
Статьи доступны к чтению
Добро пожаловать! Регистрация прошла успешно.
Отлично! Ваш аккаунт активирован, контент доступен.
Success! Your billing info is updated.
Billing info update failed.
Этап обследования как точка опоры ИТ-проекта

Этап обследования как точка опоры ИТ-проекта

7 минут чтения

«Дайте мне точку опоры, и я переверну Землю!»
Архимед

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

К каждому из описываемых шагов добавлены артефакты-примеры из реальных бизнес-кейсов.

Составляем план ИТ-обследования

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

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

  • что сейчас хорошо;
  • что сейчас плохо;
  • кто и за что отвечает.

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

Поэтому важно помнить, что взгляд со стороны всегда полезен, не стоит упускать этот шанс, ведь «большое видится на расстоянии».

Однажды мы проводили обследование по процессу управления инцидентами в компании, где пользователи сервисов исчисляются тысячами, а сотрудники сервисных подразделений сотнями. Для помощи в проведении работ по некоторым направлениям обслуживания техники заключались контракты с внешними сервисными организациями, поэтому процесс управления инцидентами по оборудованию выходил за рамки обследуемой компании. Чтобы комплексно разобраться в выстроенных процессах, наши консультанты погрузились в изучение договоров поддержки с внешними сервисными организациями. Договоры были объемными и сложными. Пояснения к ним, как со стороны сотрудников обследуемой компании, так и со стороны внешних организаций, предоставлялись неохотно и ограниченно. В итоге, победив долгое и мучительное построение витиеватой процессной цепочки, наш консультант воскликнул: «Наконец-то мы разобрались и поняли ваш договор!». На что представитель обследуемой компании ответил: «Теперь и мы поняли свой договор!»

На основе накопленного опыта в ИТ-проектах сформировался комплексный план обследования, который позволяет проводить его максимально эффективно:

  1. Подготовка и организация ключевой встречи.
  2. Сбор данных.
  3. Обработка информации.
  4. Демонстрация результатов обследования.
  5. Старт проектирования.

2-steps

Остановлюсь подробнее на особенностях каждого из шагов.

Готовимся к встрече с клиентом

На первом шаге знакомимся и устанавливаем контакт между специалистами заказчика и проектной командой.

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

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

Ключевая встреча проходит гораздо эффективнее в тех организациях, где руководитель проекта со стороны заказчика проводит подготовительные работы:

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

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

  • Сформировать на основе ОШС схему подразделений.
  • Сформулировать перечень основных видов деятельности в рамках текущих процессов в «крупную клетку» и их условное обозначение:

    16-red-icon – отделы, сотрудники которых отвечают за прием обращений от пользователей (звонки, устно).

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

    18-blue-icon – отделы, сотрудники которых выполняют работы по обращениям (принял, диагностировал, вернул/решил).

    19-yellow-icon – отделы, сотрудники которых передают обращения подрядчикам и контролируют их выполнение.

  • Распределить виды деятельности по подразделениям, указать контактные данные их представителей, задействованных в текущей практике процессов.
  • 15-sheme

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

2. Мотивирует участников. Выделяет для них ценность проекта.

Для сотрудников хорошо работает личная мотивация. Можно бесконечно рассказывать о том, какие прекрасные горизонты развития у компании, о ее росте, о повышении оборота при успешном завершении проекта, но эффективнее обозначить личную пользу для участников, например: 1) снижение рутинного ручного труда посредством автоматизации, 2) развитие, возможность профессионального роста, 3) получение новых знаний.

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

14-icon ОШС
14-icon План обследования

Собираем данные

На втором шаге собираем информацию для последующего анализа и использования на всех этапах проекта.

Области обследования всегда предопределены границами проекта. Если проекта нет, но необходимо провести ревизию деятельности подразделения самостоятельно, то лучше определить и зафиксировать границы условно. Например, сфокусироваться на одном из ITSM-процессов.

Подготовка материалов для обследования в ИТ-проекте – это зона ответственности подрядчика. И наработки готовы, и понимание того, какая информация может быть востребована, и что необходимо.

Сбор данных проводится по трем направлениям:

  • заполнение анкет;
  • интервью;
  • изучение документации по текущим процессам (инструкции, регламенты, отчеты, ОШС).

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

14-icon Опросник по процессу
14-icon Протокол интервью

Обрабатываем информацию

На третьем шаге оцениваем текущую ситуацию, выделяем зоны оптимизации.

Вся полученная информация консолидируется в единый документ. По факту готовности он рассылается всем участникам.

Примерная структура документа:

  1. Краткая информация о деятельности организации, стратегия.
  2. Оргструктура и распределение зон ответственности.
  3. Контактные данные участников обследования, их анкеты и интервью, перечень предоставленных документов для анализа.
  4. Текущая практика по обследуемой области.
  5. Используемые средства автоматизации, скриншоты.
  6. Проблемы, пожелания, рекомендации от участников.
  7. Резюме с выводами по итогам результатов обследования.

Самое сложное – сделать правильные выводы. Лучше всего опираться на методологию по тематике проекта. Если мы говорим про ITSM, то здесь выбор широк. Процессы достаточно емко проработаны в ITIL, CobiT.

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

Здесь влияет множество внешних факторов:

  • размер компании;
  • структура компании;
  • корпоративная культура;
  • стратегия бизнеса;
  • территориальное расположение.

Поэтому вряд ли получится просто скопировать ИТ-практики, взятые из предыдущего опыта.

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

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

Но и для таких случаев готовы инструменты: множество методологий аудита измерения и оценки процессов. Например: Software Process Improvement and Capability Determination (SPICE), Capability Maturity Model Integration (CMMI), CobiT PAM.

В своей практике для формулирования выводов и решений по результатам обследования предпочитаю использовать CobiT 5 PAM.

20-table

Представляем результаты обследования

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

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

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

Лучше планировать небольшие 20-30 минутные встречи и коллективно принимать решения. Это позволяет всем высказаться, почувствовать массовые тенденции, а также услышать и понять индивидуальные проблемы каждого отдельного участника.

5-pres

14-icon Презентация по результатам обследования

Стартуем проектирование

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

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

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

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

– Почему вы не сообщили об этом раньше? Это может повлиять на формат процесса.
– Почему вы сами не знаете таких элементарных вещей? Вы же опытный консультант!

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

К выводам

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

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