Справочно-правовые системы.

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

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

Вопрос 14. Создание и внедрение ИСУП: основные принципы проектирования и внедрения ИСУП; характеристика основных концепций внедрения: модульное и полномасштабное внедрение, их преимущества и недостатки; проблемы внедрения ИСУП.

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

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

- Принцип единства функционирования с другими ИС (принцип совместимости) заключается в реализации способности АИС различных видов и уровней совместно функционировать.

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

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

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

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

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

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

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

Проблемы создания ЭАИС тесно связаны с общими основами развития экономики и конкретного экономического объекта (предприятия, банка, фирмы), с одной стороны, а с другой — со спецификой и тенденциями быстро развивающихся ИТ. Поэтому рассмотренные базовые принципы дополняются которые невозможна разработка современных ИС:

- принцип декомпозиции, используемый для разделения системы на части (элементы) и обеспечивающий изучение свойств элементов, подсистем и системы в целом;

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

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

Вопрос 15. Понятие бизнес-процесса. Описание бизнес-процессов предприятия. Необходимость описания бизнес-процессов. Способы формализованного описания бизнес-процессов в информационной системе. Реорганизация бизнес – процессов.

Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т.д. Для каждой такой задачи существует определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае, модель бизнес-процесса должна давать ответы на следующие вопросы: какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата; в какой последовательности выполняются эти процедуры; какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса; кто выполняет процедуры процесса; какие входящие документы/информацию использует каждая процедура процесса; какие исходящие документы/информацию генерирует процедура процесса; какие ресурсы необходимы для выполнения каждой процедуры процесса; какая документация/условия регламентирует выполнение процедуры; какие параметры характеризуют выполнение процедур и процесса в целом.

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

На сегодняшний день наиболее распространенными в России CASE-инструментами для моделирования бизнеса являются ARIS Collaborative Suite компании «IDS Scheer AG (Германия)» и «AllFusion Modeling Suite», в частности «AllFusion Process Modeler» (ранее «BPwin») компании Computer Associates.

Вопрос 16. Нотации IDEF.

1) нотация IDEF0, которая была разработана на основе методологии структурного анализа и проектирования SADT, утверждена в качестве стандарта США и успешно эксплуатируется во многих проектах, связанных с описанием деятельности предприятий.

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

Каждая из четырех сторон функционального блока имеет своё

Нотация IDEF0

Модуль поведения (UOB)

Объект служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.

Стрелка слева

Стрелка описывает входящие документы, информацию, материальные ресурсы, необходимые для выполнения функции.

Стрелка справа

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

Стрелка сверху

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

Стрелка снизу

Стрелка снизу описывает т.н. механизмы, т.е. ресурсы, необходимые для выполнения процедуры, но не изменяющие в процессе ее выполнения свое состояние. Примеры: сотрудник, станок и т.д.

определенное значение (роль), при этом:

• Верхняя сторона имеет значение “Управление” (Control);

• Левая сторона имеет значение “Вход” (Input);

• Правая сторона имеет значение “Выход” (Output);

• Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

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

Модель IDEF0 всегда начинается с представления системы как единого простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0».

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели.

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента.

2) нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур.

Нотация IDEF3

Ссылочный объект

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

Логическое «И»

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

Логическое «ИЛИ»

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

Логическое исключающее «ИЛИ»

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