Информационное и техническое обеспечение менеджмента в организации, их роль и значение в процессе управления

Результаты предпроектного обследования сводятся в документ ТЗ на проектирование, где содержит полный перечень и описание подтвержденных пользователем (заказчиком) и подлежащих переводу на новую ИТ работ. Существуют государственные стандарт ГОСТ 34.602–89 на разработку ТЗ [2], а также стандарт на разработку информационных систем ГОСТ 34.601–90 [3] на стадии создания.

Проекты по внедрению на

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

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

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

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

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

Перечислю основные этапы разработки и внедрения информационной системы (в Приложении 5 приведен календарный план реализации проекта):

1) Предъявление требований к новой системе и ее архитектуре.

2) Составление технического задания (ТЗ) разработчиком.

3) Утверждение (а если надо то отправка ТЗ на доработку) заказчиком.

4) Разработка системы по ТЗ.

5) Тестовая эксплуатация системы заказчиком и отправка на доработку разработчику.

6) Обучения персонала (сначала офисного, а затем и персонала торговых объектов).

7) Перенос актуальных товарных остатков и необходимых справочников в новую информационную систему.

8) Установка клиентских приложений на рабочих местах.

9) Собственно начало эксплуатации системы.

10) Сопровождение и поддержка системы.

На вид все достаточно просто и логично, но на деле же все оказывается куда сложнее.

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

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

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

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

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

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

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

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

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

 Скачать реферат