Вышедшая неделю назад заметка Дмитрия Исайченко "О пользе предпроектных обследований" сподвигла меня поделиться мыслями на тему того, что делать в случае, когда от предпроектного обследования было решено отказаться, и экономия вкупе со сжатостью сроков требуют выполнения экспресс-внедрения ITSM решения "как есть".
Первое, что необходимо осознать – это выгоды от экспресс-внедрения ITSM решения как для исполнителя-консультанта, так и для заказчика! Абсолютно естественно, что эти выгоды выражаются повышенными рисками неудачного внедрения, рисками выполнения постпроектной эксплуатации своими силами, высоко установленной планкой качества решения и самого внедрения, а также пропорционально краткими сроками и малым бюджетом.
На практике, проектная команда консультантов мала и состоит из одного, реже двух профессионалов, которые принимают, выполняют и сдают проект от начала и до конца. В этих условиях у всей проектной команды, включая заказчика, нет права на совершение ошибок.
Перед ведущим консультантом или архитектором в таком проекте стоят как минимум два вызова, которые препятствуют ему в обеспечении гарантии проведения успешного и максимально безболезненного для заказчика внедрения.
- В подавляющем большинстве случаев внедряемое решение содержит не только требуемую, но и заведомо избыточную функциональность. Любое современное ITSM решение представленное на рынке предлагает колоссальный спектр возможностей для применения.
- Все заказчики очень и очень разные, даже находящиеся в рамках одной отрасли! Всего лишь один набивший оскомину процесс управления инцидентами, который в таком внедрении почти никогда не обходится стороной, может реализовываться добрым десятком различных способов.
В такой ситуации у команды внедрения остаются только два основных ресурса, это – знания (или "уверенность в готовности") и время.
Один из способов по быстрому набору знаний за заданное время заимствован мной из методики разработки программного обеспечения "test driven developent". Идея в том, чтобы собрать максимальное количество "use-case" или сценариев эксплуатации так, чтобы гарантировать достаточную полноту решения. Обычно эту работу по сбору "сырых" сценариев удается сделать за небольшое время в виде семинаров или интервью в дополнение к анализу процессной документации. Эти сценарии в процессе их сбора обогащаются информацией о частоте использования, критичности различных блоков, задач или артефактов и могут быть успешно проанализированы и использованы.
Искренне призываю не жалеть времени на эту работу, потому что она позволяет решить сразу несколько задач:
- Дает возможность не выстраивать сеть подъемных кранов там, где достаточно стремянки и четко очертить требуемую архитектуру;
- Заставляет консультантов пропустить через себя опыт заказчика, позволяя принимать более взвешенные решения;
- Позволяет совместной проектной группе быть уверенной в готовности настроенного решения к запуску в продуктивной среде и живом окружении;
- Облегчает головную боль консультанта, связанную с разработкой ролевых инструкций и сценариев тестирования;
- Принципиально снижает вероятность выявления таких блокирующих ошибок сразу после внедрения и в первый "горячий" период, как то: ошибки в настройках и описании процессов, некорректность данных в справочниках, ошибки или нефункциональность интеграций и сервисов обмена данными;
- Мотивирует консультантов и заказчика при завершении проекта разработать и приоритезировать мероприятия по дальнейшему развитию действующих процессов и/или ITSM системы, уменьшая постпроектные риски.
Буду рад, если мой скромный опыт будет кому-либо полезен! Обращайтесь!
Да, но как собрать такие сценарии? То, как заказчик делает сейчас (AS IS), его далеко не во всем устраивает (иначе не было бы проекта, наверно). То, как надо (TO BE), он четко себе не представляет (и его различные сотрудники не представляют по-разному). Вот тут-то и начинаются подъемные краны, как результат буйной фантазии, лишенной ясной постановки задачи и внятных ограничений.
В итоге, как этим методом пользоваться при постановке задания на автоматизацию, мне очень понятно. А вот как инструмент консалтинга, этот подход мне пока не понятен. Поясните?