Портал №1 по управлению цифровыми
и информационными технологиями

Уверенность в экспресс-внедрении.

TDD

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

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

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

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

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

В такой ситуации у команды внедрения остаются только два основных ресурса, это – знания (или "уверенность в готовности") и время. 

Один из способов по быстрому набору знаний за заданное время заимствован мной из методики разработки программного обеспечения "test driven developent". Идея в том, чтобы собрать максимальное количество "use-case" или сценариев эксплуатации так, чтобы гарантировать достаточную полноту решения. Обычно эту работу по сбору "сырых" сценариев удается сделать за небольшое время в виде семинаров или интервью в дополнение к анализу процессной документации. Эти сценарии в процессе их сбора обогащаются информацией о частоте использования, критичности различных блоков, задач или артефактов и могут быть успешно проанализированы и использованы.

Искренне призываю не жалеть времени на эту работу, потому что она позволяет решить сразу несколько задач:

  1. Дает возможность не выстраивать сеть подъемных кранов там, где достаточно стремянки и четко очертить требуемую архитектуру;
  2. Заставляет консультантов пропустить через себя опыт заказчика, позволяя принимать более взвешенные решения;
  3. Позволяет совместной проектной группе быть уверенной в готовности настроенного решения к запуску в продуктивной среде и живом окружении;
  4. Облегчает головную боль консультанта, связанную с разработкой ролевых инструкций и сценариев тестирования; 
  5. Принципиально снижает вероятность выявления таких блокирующих ошибок сразу после внедрения и в первый "горячий" период, как то: ошибки в настройках и описании процессов, некорректность данных в справочниках, ошибки или нефункциональность интеграций и сервисов обмена данными;
  6. Мотивирует консультантов и заказчика при завершении проекта разработать и приоритезировать мероприятия по дальнейшему развитию действующих процессов и/или ITSM системы, уменьшая постпроектные риски.

Буду рад, если мой скромный опыт будет кому-либо полезен! Обращайтесь!

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 5

  • Идея в том, чтобы собрать максимальное количество "use-case" или сценариев эксплуатации так, чтобы гарантировать достаточную полноту решения…

    Да, но как собрать такие сценарии? То, как заказчик делает сейчас (AS IS), его далеко не во всем устраивает (иначе не было бы проекта, наверно). То, как надо (TO BE), он четко себе не представляет (и его различные сотрудники не представляют по-разному). Вот тут-то и начинаются подъемные краны, как результат буйной фантазии, лишенной ясной постановки задачи и внятных ограничений.

    В итоге, как этим методом пользоваться при постановке задания на автоматизацию, мне очень понятно. А вот как инструмент консалтинга, этот подход мне пока не понятен. Поясните?

  • Поясню.

    Ограничения – есть суть экспресс-внедрения: нечеткая картина "as is", предпочтительные паттерны продиктованные решением, заявленные пожелания и предпосылки к "to be" с процессной и технической стороны, малое время на подготовку к запуску.

    В рамках этих ограничений основной задачей становится непрерывность бизнес и ИТ-процесов заказчика в момент внедрения, с минимально необходимым объемом utility. Предлагаемый способ не несет специальной ценности в виде консалтингового инструмента для развития ИТ-процессов на предприятии, но является практикой, которая с высокой долей вероятности позволит выявить наличие "специальных процедур обработки major инцидентов" заранее, а не по факту их возникновения. 

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

    Безусловно, бездумное применение этой практики с тотальным упором только на имеющиеся данные "as is" скорее принесет больше вреда чем пользы. Экспертный опыт и знания консультанта/внедренца является ключевым связывающим звеном в такой ситуации, когда в краткие сроки нужно построить не космический корабль, а вполне себе работающий экскаватор.

    •  Экспертный опыт и знания консультанта/внедренца является ключевым связывающим звеном в такой ситуации, когда в краткие сроки нужно построить…

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

  • андрей

    Интересно, в каком виде собираются это "максимальное количество "use-case"".

    Ну т.е. это какие-то вербальные формы, текстовые описания, или модели. Если модели, то в какой нотации.

    • В “идеальном” варианте эта информация представлена в виде детально описанного процесса, например в нотации BPMN. Если этой информации в готовом виде нет, то в услових сжатости сроков эти данные чаще оформляются в виде реестра, представляющих собой списки особенностей автоматизирующихся ИТ-процессов. В качестве базы для такого документа можно ипользовать данные о инвентаризации предшествующей (версии) системы автоматизации. Список проритезируется, например с помощью метода (MoSCoW). Согласованная часть этого списка реализуется при внедрении (приоритет “must”), часть признается устаревшей, оставшееся може являться предметом для включение в план последующей автоматизации.  


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM