Фаза моделирования, как гарантия адекватной оценки ИТ-проекта

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

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

• Экспресс-обследование инфраструктуры.
• Описание функциональных требований.
• Разработка технического задания.

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

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

Бюджет = О + (4*В) + П / 6

Пользоваться только одним методом определения цены было бы недальновидно. Высок риск ошибки, т.к. у каждого способа есть свои допущения и ограничения. Недостаток исходных данных нивелируется законами теории вероятности. Поэтому будет правильным применить несколько вариантов, дополняющих друг друга, в идеале не менее трех.
Хороший результат дает метод функциональных точек. Определяется общее количество функций системы с точки зрения пользователя. Далее они делятся на простые, средние и сложные. В зависимости от уровня определяется время реализации и необходимая степень квалификации персонала. Для простых задач потребуются грэйд junior или middle, средних только middle, сложных – senior.

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

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

Ключевое слово в названии этапа – экспресс. Почему? Классическая схема начала проекта: контакт с заказчиком, контракт, обследование, отчет и переход к следующему этапу, полностью работает не всегда. Установить договорные отношения на период уяснения задачи для определения стоимости получатся не часто и не у всех. Особенно это проблематично в сфере государственного заказа. Поэтому компания-исполнитель идет на риск и проводит этот этап за свой счет, планируя компенсировать затраченные средства при контрактовании. Понятно, что в такой ситуации нужно работать быстро и с минимальными затратами.

На этой стадии также возникает желание пропустить некоторые мероприятия с целью экономии средств. Чаще всего это касается описания процессов «как есть». Здесь нужно занять твердую позицию и объяснить заказчику почему этого делать категорически нельзя. Главная причина проста – если есть необходимость модернизации существующей системы, значит она имеет существенные недостатки. При переходе сразу к схеме «как будет» без анализа существующего положения дел, очень большой риск не устранить старые проблемы.

Еще один важный момент, который нельзя реализовать без описания «as-is», – построение матрицы переходов. Очевидно, что для ее составления понадобятся обе схемы. В результате вместо сложных описаний, где можно запутаться и пойти по неоптимальному пути, получаем простую таблицу. Слева «as-is», справа «to-be» и сразу видно отличия между ними. Нехитрый анализ покажет, что в системе появились объекты, которых ранее не было. Наглядность метода позволит оперативно принять решение, что с этим делать. Например, новый процесс не покрывается соответствующей ролью, взгляд в левую часть таблицы и уже можно определить, нужно для этой роли модернизировать существующий ресурс или понадобится новый и т.д.

Это важно, т.к. автоматизация почти всегда подразумевает изменение организационных структуры. Бывают случаи, когда при глобальных преобразованиях существующей или внедрении новой информационной системы, необходимо менять штатную структуру. Появляются новые роли, подразделения, должностные инструкции. Зачастую меняется базовое окружение: строятся здания, выделяются помещения, расширяются северные и сетевые мощности.
Основная цель итогового документа «Функциональные требования» – получение так называемых gap-ов (разрывов). При определении конфигурации системы и выборе платформы, необходимо четко определить, что реализуется типовым решением, а что нужно дополнительно настраивать или разрабатывать с нуля. Перечень и сущность работ по обеспечению автоматизации процесса в схеме «как будет» ложится в основу разработки технического задания.

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

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

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

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

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