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

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

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

Чтобы не потерять критически важную информацию во время внедрения учет велся и в новой и в старой системе параллельно.

Помимо процесса внедрения СЭД остаются вопросы по сопровождению новой системы.

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

Это отдельный пласт задач, которые, так или иначе надо решать.

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

Можно выделить основные направления [16]:

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

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

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

4) Профилактическое сопровождение (preventive maintenance) — это модификация программного продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, как они приведут к реальным сбоям.

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

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

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

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

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

3.2. Оценка экономических результатов от реализации первого этапа проекта

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

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