Владимир Баронов - Информационные технологии и управление предприятием

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

В ходе разработки концепции должны быть также определены:

• укрупненная структура и классификация групп пользователей системы;

• необходимая и достаточная полнота функциональных возможностей;

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

• требования к структуре программ и распределению функций обработки данных;

• требования к операционным средам функционирования прикладных программных средств;

• требования к сетевым программным средствам;

• требования к технической среде обработки данных системы;

• требования к техническому обеспечению системы передачи данных.

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

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

Наконец, в концепции нужно определить основные этапы построения КИУС:

• определение целей проекта;

• анализ опыта похожих предприятий по созданию КИУС;

• определение целей проекта в контексте системы управления;

• формирование критериев успешности проекта;

• формирование финансового плана;

• подготовка к созданию КИУС;

• организация тендера, выбор генерального подрядчика и поставщика консалтинговых услуг;

• подготовка персонала к неизбежности изменений;

• формирование плана-графика проведения работ на этапе;

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

• формирование и обучение рабочей группы аналитиков;

• проведение обследования предприятия;

• моделирование «как есть» и «как должно быть» и, по необходимости, реорганизация бизнес-процессов;

• утверждение бизнес-модели «как должно быть»;

• уточнение целей и критериев успешности проекта создания КИУС;

• разработка требований к КИУС;

• разработка технических заданий (общего и частных по каждому из компонентов);

• анализ рынка и выработка предложений по компонентам КИУС (включая собственную разработку);

• выбор поставщиков компонентов КИУС;

• формирование требований к поставщику;

• организация презентаций поставщиков;

• выбор поставщиков;

• определение форм сотрудничества и заключение контрактов с поставщиками;

• создание КИУС;

• разработка и утверждение плана-графика создания КИУС;

• формирование и обучение рабочей группы;

• разработка системного проекта;

• настройка и тестирование тиражируемых компонентов;

• разработка уникальных компонентов;

• интеграция компонентов в опытную версию КИУС;

• опытная эксплуатация КИУС;

• разработка методик работы с КИУС;

• обучение и сертификация пользователей и администраторов;

• переход к промышленной эксплуатации КИУС.

Формирование, документирование и анализ требований позволяет реализовать следующие цели:

• достижение взаимопонимания между всеми участниками разработки относительно функций и характеристик КИУС;

• обеспечение возможности «видения» и корректировки будущей системы до того, как она будет реализована физически;

• уменьшение затрат на разработку и внедрение системы;

• обеспечение базиса для планирования, оценки стоимости и времени создания системы.

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

Задача формирования требований является наиболее трудной частью процесса создания КИУС, при их определении возникают следующие проблемы:

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

• требования от различных заинтересованных лиц могут быть противоречивыми;

• требования не всегда ясны и имеют много источников происхождения;

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

• число требований может быть огромным (и разной степени детализации) и вследствие этого неуправляемым;

• требования изменяются и т. д.

Требования к КИУС разбиваются на две самостоятельные группы – требования к функциям и нефункциональные требования. Основой выявления требований первой группы является модель бизнес-процессов предприятия, на базе которой, собственно, и формируется иерархия требований. К числу нефункциональных требований относятся:

• правовые и законодательные требования;

• качественные характеристики создаваемой системы, включая требования к ее практичности, надежности, производительности и возможностям поддержки;

• требования по безопасности;

• другие требования, например касающиеся операционных систем и сред, совместимости и проектных ограничений.

На основании выявленных требований разрабатывается техническое задание (ТЗ) на КИУС и, по необходимости, частные технические задания на ее компоненты (подсистемы). ТЗ создается на основе ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы включает следующие основные разделы:

• Общие сведения;

• Назначение и цели создания системы;

• Характеристика объекта автоматизации;

• Требования к системе;

• Состав и содержание работ по созданию системы;

• Порядок контроля и приемки системы;

• Требования по подготовке и вводу в действие;

• Требования к документированию;

• Источники разработки;

• Глоссарий.

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