Построение КИУС

Построение КИУС

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

• информационной безопасности;

• управления проектами;

• документационного обеспечения;

• управления качеством.

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

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

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

Ключевым моментом стратегии управления является взаимная увязка системы качества и КИУС. В современных условиях система качества предприятия, построенная в соответствии с требованиями стандартов серии ИСО 9000, выступает как определяющий компонент системы управления.

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

• сети и телекоммуникации;

• оборудование;

• операционные системы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом.