WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 19 |

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

• Уточнение и утверждение онтологии – заключительная стадия процесса.

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

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

• длительность (задача ставится "в последний момент");

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

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

• теоретически высокая стоимость;

• вводящая в заблуждение реклама;

• плохая постановка перспективного планирования • отсутствие формальных критериев или их качественный характер оценки будущей КИС.

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

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

За основу можно взять следующие принципы классификации:

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

• Качество (уровень) взаимосвязи между подсистемами;

• Опция конкретного клиента (например, аппаратная платформа).

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

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

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

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

• Техническая выполнимость: возможность внедрения предложенного решения с учетом наличного программного обеспечения, аппаратных средств и технических ресурсов.

• Экономическая выполнимость: превысят ли результаты от внедрения новой системы затраты на ее создание • Эксплуатация системы: впишется ли предлагаемое решение в рамки существующей управленческой и организационной структуры Обычно, при анализе систем разрабатывается несколько альтернативных вариантов решений. Затем, определяется степень выполнимости каждого из вариантов. В предложении по созданию системы описываются затраты и результаты, преимущества и недостатки каждой из альтернатив. Далее, менеджментом компании принимается решение о том, какое сочетание затрат, результатов и технических характеристик будет наиболее подходящим для организации.

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

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

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

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

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

Рис. 10. Выбор программного обеспечения В "заштрихованную" область попадают те системы, которые пригодны для решения корпоративной задачи управления.

Кроме того, для получения обоснованного решения задачи анализа по вышеуказанной схеме:

• нужно "просмотреть" перспективу развития бизнес процессов, по крайней мере, на два года вперед;

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

• часто происходят организационные изменения (например, слияния – разъединения);

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

• и, опять же, мало квалифицированных менеджеров и аналитиков в самих фирмах Типичные «узкие места» программного обеспечения:

• Низкий уровень функциональности, интегрированности и недостаточное количество настроек.

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

• Нестабильность работы. Наличие устаревших технологий обработки данных (известно, что иногда перевести программное обеспечение на новые технологические рельсы сложнее, чем написать его заново).

• Отсутствие актуальной технической и пользовательской документации.

• Несоблюдение принципа «версионности».

• Несоответствие маркетинговой информации реальным возможностям программного обеспечения.

• Финансовая нестабильность разработчика.

1.5. Основные типы подсистем КИС Системы автоматизации деловых процессов для КИС. Сегодня существует целый ряд систем автоматизации деловых процессов (САДП). Из зарубежных систем это, в первую очередь, Action Workflow фирмы Action Techologies и продукт фирмы Staffware Inc., который так и называется Staffware; из отечественных например, система WorkRoute компании ВЕСТЬ АО.

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

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

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

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

Предполагается, что значения переменных должны считываться не только из базы данных workflow-системы, но и из баз данных прикладных программ, поддерживающих наиболее распространенные промышленные стандарты СУБД. Это позволяет интегрировать систему автоматизации деловых процессов с внешними приложениями в разрезе совместного использования данных.

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

Крайне желательно, чтобы скрипт мог работать с OLE-серверами, запускать внешние программы, взаимодействовать с MAPIсовместимыми почтовыми системами. Если workflow-система рассматривается как основа КИС, то для получения полной интеграции с другими программами и облегчения этого процесса требуется наличие открытого программного интерфейса API, который бы позволил управлять системой из внешних программ.

За разработку стандартов и спецификаций на системы класса workflow отвечает международная организация Workflow Management Coalition (WfMC).

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

Прежде всего, это относится к системам управления документами и делопроизводству, то есть к комплексу операций по созданию, управлению и исполнению документов, ведению электронного архива, организации офисного документооборота. Для реализации таких функций объединяют workflow-систему с системой управления документами (СУД). К системам данного класса относятся, например, DOCS Open американской фирмы PC DOCS, DocuLive (Siemens Nixdorf), Documentum (Documentum, Inc.). Как правило, СУД имеют богатые возможности по интеграции с внешними приложениями (офисными и прикладными программами), которые и “снабжают” СУД документами. Кроме того, СУД изначально ориентирована на КИС масштаба предприятия, в связи с чем все промышленные системы выполнены в архитектуре клиент-сервер и способны работать практически на всех программно-аппаратных платформах, т.е. характеризуются масштабируемостью, переносимостью, безопасностью и надежностью хранения данных, а также обеспечивают распределенный режим работы.

Как правило, составные части КИС поддерживают довольно широкий список оборудования и серверного программного обеспечения, это дает возможность уменьшить затраты, так как увеличивается вероятность того, что необходимые базовые продукты в организации уже есть. На сегодняшний день основными платформами, на которых должны функционировать входящие в состав КИС СУД, САДП и прикладное программное обеспечение, считается Windows NT Server, Novell NetWare, основные разновидности Unix и промышленные СУБД Oracle, Microsoft SQL Server, Oracle или Sybase.

Важно отметить, что КИС на основе САДП и СУД являются довольно универсальными. Подобные комплексы, благодаря имеющимся инструментам интеграции, позволяют объединить офисный, (организационно-распорядительный) документооборот с инженерным, в который входит техническая, технологическая и чертежно-конструкторская документация (она, как правило, разрабатывается в САПР и ГИС, например в AutoCAD, MicroStation, КОМПАС), а также любые другие виды информации, вплоть до мультимедиа. Кроме того, в состав КИС могут органично входить программы бухгалтерского, складского и кадрового учета.

Минимальный уровень интеграции обеспечивает наличие открытых кодов командной строки: лучше, если программа поддерживает стандарт OLE Automation, и, дополнительно, если она имеет сетевую версию, использующую для хранения своих структурированных данных SQL-сервер. Тогда возможно создание мощного и гибкого инструмента, отвечающего современным требованиям по безопасности и надежности. Большинство отечественных фирм-разработчиков программного обеспечения уже выпустили или в ближайшее время выпустят версии программ, соответствующие промышленным стандартам межпрограммного взаимодействия. Кроме того, все зарубежные и отечественные офисные пакеты уже поддерживают OLE и поэтому могут интегрироваться между собой и в рамках единой workflow-системы.

Существующие системы автоматизации деловых процессов, как правило, поддерживают одну из двух форм маршрутизации:

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 19 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.