Предпроектное обследование

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

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

• описание текущей деятельности организации и информационной системы. Данное описание становится более наглядным и полезным,
если выполнено в графическом формате с текстовыми пояснитель-
ными записками;

• перечень документов, участвующих в документообороте, их состояние и печатные формы;

• альбом отчетности, формируемой в организации;

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

• подробный план перехода от текущей модели к перспективной с указанием ресурсов, сроков и исполнителей;

• список доработок информационной системы, утвержденный к вне-
дрению.

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

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

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

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

Составление плана работ

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

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

Реалистичность объема проектных задач и сроков — это первый
экзамен, который должен успешно сдать менеджер проекта при начале
работ и закрепить его в плане проекта. Самое легкое — отвечать на все
предложения: «Мы это сделаем и очень скоро», ведь проект только на-
чинается. Но ответственный руководитель проекта должен быть песси-
мистом, учитывать опыт других проектов и очень реалистично оцени-
вать имеющиеся силы и ресурсы и уметь говорить «нет», аргументируя
свою позицию. Менеджер проекта, видя перед собой постоянно основ-
ную цель проекта, должен уметь находить компромисс и убеждать все
стороны.

Как же может быть сокращен и адекватно оценен объем требова-
ний? Основным приемом снижения объемов работ является поиск ра-
ботающих прототипов. Если требуются новые отчеты при расчете нало-
гов, надо выяснить, нет ли аналогичных отчетов в других областях. Если
требуется организация новой услуги, надо посмотреть, как она реали-
зована в других банках. А если ее там нет, то еще раз проанализиро-
вать ее необходимость.

Общий алгоритм поиска прототипа заключается в следующем. Сна-
чала идет поиск аналогов решения всей задачи. Если их нет, то форму-
лируется более общая задача и ищутся подобные решения. И так до тех
пор, пока не будет найдено ближайшее по смыслу работающее реше-
ние. Затем определяются доработки к нему. Например, если нужна сис-
тема межфилиальных расчетов, за основу можно взять систему расче-
тов в РКЦ или SWIFT, или систему «банк — клиент». Всегда есть анало-
гичные системы, доработка которых существенно дешевле и надежнее, чем разработка системы с нуля. Кроме того, если в приведенном при-
мере система расчетов будет создаваться на базе системы «банк — кли-
ент», то побочным эффектом будет расширение предлагаемого клиен-
там сервиса.

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

Рассмотрим теперь технические вопросы составления самого плана
проекта. Самая лучшая формула, которой можно при этом руководство-
ваться, — это «Плохой план проекта сегодня лучше, чем хороший завт-
ра». Многие руководители проектов пишут планы месяцами, они состав-
ляют десятки страниц. Но, к сожалению, их никак не могут дописать и
согласовать. План может быть объемным, но 2-3-страничный план, осо-
бенно на начальных стадиях, не только является допустимым, но и бо-
лее предпочтительным.

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