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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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