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

Сокращаются единовременные затраты на создание КИУС, так как бюджет может быть распределен во времени.

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

Интегрирующим компоненты КИУС механизмом являются подсистемы управления потоками работ (workflow-системы). Подсистемы данного класса существуют на рынке в трех ипостасях:

• в виде самостоятельных систем (например, Staffware от Staffware Inc., Action Workflow от Action Technologies);

• в виде компонентов так называемых интеграционных платформ, таких как, например, решение компании BEA Systems – Weblogic E-Business Platform;

• в виде компонентов систем управления (прежде всего ERP-систем).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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