Файл: Проектирование реализации операций бизнес-процесса «Совершенствование существующих продуктов».pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) Разработка ТЗ: 10500 руб.

2) Разработка информационной системы: 83000 руб.

3) Выезды специалистов: около 15000 руб.

4) Оплата дополнительных разработок (не по ТЗ) около 20000 руб.

Стоимость программных средств:

1) 1С:Предприятие 8.1 «Управление торговлей»: 12800 руб.

2) Дополнительное рабочее место: 4500 руб.

Стоимость торгового оборудования:

1) Фискальные регистраторы Феликс 02К: 16200 руб.

На разработку затрачено 128 500 руб.

Затраты на обеспечение офиса программными средствами(11 рабочих мест): 12 800+10*4 500= 57 800 руб.

Затраты на торговые объекты с одним фискальным регистратором (6 торговых объектов): 6*(12 800+16 200) =174 000 руб.

Затраты на торговые объекты с двумя фискальными регистраторами (4 торговых объектов): 4*(12 800+16 200*2) =180 800 руб.

Итого первоначальная стоимость внедрения с обеспечение торговых объектов необходимыми техническими и программными средствами составила: 128 500+57 800+174 000+180 800=541 100 руб.

Что составило около 0,26% от торговой выручки за 2007 год. Эти расходы уже указанны ( см. табл. 3) в статье расходов «оргтехника».

Из этой суммы около 150 000 руб. было оплачено в июне-июле 2007 года, а остальные средства были выплачены в ноябре-декабре 2007 года, что позволило сократить нагрузку на финансовые ресурсы фирмы.

Стоимость внедрения относительно масштабов фирмы оказалась не значительной. Осталось провести анализ оценки успешности самого проекта. А точнее проанализировать его экономическую эффективность. Как мы условились ранее, определять мы ее будем в следующих аспектах: как соотношение между затратами и получаемым результатом; как степень достижения поставленной перед ИС управления организацией цели и как результат сравнения экономических показателей деятельности управленческих служб, выявленных на этапе предпроектного обследования организации, с аналогичными показателями в условиях применения внедренной СЭД.

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

В нашем случае проводить анализ, используя апостериорный путь( т.е.сравнение с показателями в условиях применения внедренной СЭД) еще рано т.к. 3 месяца с начала эксплуатации это очень маленький срок чтобы делать какие-нибудь выводы. Системе еще предстоит долгая «обкатка» в «боевых» условиях, что потребует дополнительных затрат на сопровождение и доработку программных модулей. Но по многим операциям получено сокращение существенное сокращение времени выполнения ( см. табл. 5).

Постоянное сопровождение системы тоже дает положительные результаты в плане сокращение рутинного труда и приведу оценку доработок программных модулей за март месяц 2008 года (см. табл. 6).

Следует добавить что цифры приведенные в столбцах (см табл. 6) стоимость исполнения функции без автоматизации и с автоматизацией это суммы затрачиваемые ежемесячно, а вот суммы приведенные в столбце затраты на автоматизацию это суммы выплаченные разработчику одноразово. Итого за март месяц стоимость разработки программных модулей составила 13650 руб. При этом без учета коэффициентов экономия на автоматизации составила 33240 руб. в месяц, а если еще принять во внимание коэффициенты оценки требований к человеческому фактору а также значимости данных для других операций то экономия составит около 120 тыс. руб., что составит более 20% от стоимости внедрения системы.

Эти коэффициенты приведены весьма грубо, но в целом они достаточно верно дают представление об автоматизируемой операции. Т.о. грубая оценка эффекта только доработок системы за 1 месяц март позволяет за 5-6 месяцев вернуть инвестиции направленные на разработку системы и закупку нового оборудования.

Таблица 5.

Сравнение времени выполнения операции в старой и новой системе.