Как уже было сказано выше, одной из задач информационного менеджмента является принятие решения о создании информационной системы либо собственными силами, либо путем приобретения и внедрения готовой информационной системы.
В связи с этим далее рассматриваются вопросы моделирования бизнес-процессов с использованием различных методологий и нотаций на предмет проверки соответствия полученных моделей какой-либо готовой информационной системе. Если же в условиях конкретного предприятия готовую систему использовать невозможно, то возникает необходимость разработки оригинальной системы.
Кроме того, целью моделирования деятельности предприятия могут быть сокращение затрат на выпуск продукции, создание должностных и рабочих инструкций при внедрении стандартов ISO-9000 и т.д. В общем случае модель бизнес-процесса должна давать ответы на следующие вопросы: Какие функции (работы) необходимо выполнить для получения заданного конечного результата?
В какой последовательности выполняются эти функции? Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса? Кто выполняет функции процесса? Какие входящие документы (информацию) использует каждая функция процесса? Какие исходящие документы (информацию) генерирует каждая функция процесса?
Бизнес процессы, лекция 6-1. Моделирование бизнес-процессов. Основы. Нотации
Какие ресурсы необходимы для выполнения каждой функции процесса? Какая документация (условия) регламентирует выполнение функций? Какие параметры характеризуют выполнение функций и процесса в целом?
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, которые позволяют отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, так как ее можно будет подвергнуть анализу и реорганизации.
В структурном и объектно-ориентированном анализах используются средства, моделирующие в форме диаграмм определенного вида деловые процессы и отношения между данными в системе.
Этим средствам соответствуют определенные виды системных моделей, наиболее распространены среди них следующие: IDEF (Integrated Definition) — семейство структурных моделей и соответствующих им диаграмм; DFD (Data Flow Diagrams) — диаграммы потоков данных; ERD (Entity-Relationship Diagrams) — диаграммы «сущность — связь»; технология управления потоками работ Workflow; нотация BPMN (Business Process Modeling Notation)-, средства имитационного моделирования, основанные на математическом аппарате раскрашенных сетей Петри (Color Petri Nets, CPN) объектно-ориентированные методологии на основе унифицированного языка моделирования UML интегрированные средства и методологии широкого назначения, например ARIS.
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатывается. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Кроме того, в современных инструментальных средствах моделирования процессов и в системах управления ими реализуется поддержка языков описания бизнес-процессов: BPEL (Business Process Execution Language), XPDL (XML Process Definition Language), BPML (Business Process Modeling Language), XLANG (XML Language), WSFL (Web Services Flow Language). В частности, инструментарий ActiveWebflow Professional Designer поддерживает наиболее популярный сегодня язык BPEL.
Главные модели построения бизнес процессов! Моделирование бизнес процессов!
CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. В настоящее время на рынке представлено достаточно большое количество CASE-сштеи, многие из которых позволяют создавать описания (модели) бизнес-процессов предприятий.
Можно привести (например, по категориям) классификацию таких средств, которая определяет степень их интегрированности по выполняемым функциям: локальные, решающие небольшие автономные задачи и поддерживающие один-два типа моделей и методов (Design/IDEF, ProCap, Power Designer, IDEPQ/EM Tool)’, малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin) средние интегрированные средства моделирования, поддерживающие от четырех до 10—15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000); крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset).
На начальном этапе необходимо описать входы и выходы процесса (поставщиков и потребителей), управляющие воздействия (внутренние и внешние) и виды ресурсов (людские и материальные). Для этого составляется «Ведомость определения процесса». Необходимо описать субпроцессы (в виде таблиц), а также виды сопроводительной документации и риски срыва процесса. Описание бизнес-процесса должно содержать блок- схему и логику процесса.
Блок-схема включает процесс, представленный в виде сущностей (прямоугольников произвольной формы), связанных отношениями (стрелками), задающими последовательность выполнения функций процесса. Блок-схема содержит описание следующих атрибутов процесса: владелец процесса, условия начала процесса, заказчик процесса и ожидаемые выходные результаты. При получении выходных данных происходят оценка процесса и анализ фактических показателей. Затем формируются требования к дополнительным ресурсам для улучшения деятельности процесса и определяются виды ресурсов.
Рассмотрим исходные данные для моделирования. В рамках создания моделей должен быть осуществлен анализ функциональной деятельности структурных подразделений предприятия, их функционального и информационного взаимодействий, внутреннего документооборота и информационных потоков.
По результатам анализа и моделирования осуществляется оценка эффективности деятельности структурных подразделений предприятия, на основе которой формируются предложения по совершенствованию его структуры, технологии работы структурных подразделений и предприятия в целом. В качестве входной информации для построения моделей обычно используются действующая организационная структура, положения о структурных подразделениях (отделах), а также данные опроса руководителей и сотрудников предприятия.
Положение об отделе (далее — Положение) содержит сведения об основных структурных звеньях, которые входят в данное подразделение; функциях, которые они выполняют; правах и обязанностях. Положение содержит следующие разделы. Общие положения; Руководство отделом; Перечень функций; Взаимоотношения подразделений; Права; Ответственность; Реорганизация и ликвидация подразделений; Структурная схема отдела и матрица распределения ответственности по элементам системы качества.
Первый раздел включает краткую информацию об отделе и его месте в иерархии управления. Также здесь описываются основные задачи подразделения и документы, которыми руководствуются сотрудники.
Во втором разделе содержится информация следующего характера: кто возглавляет отдел, кем назначается и освобождается от занимаемой должности, кто утверждает структуру и штатное расписание отдела, какую работу выполняет руководитель отдела, а также основные показатели оценки деятельности подразделения. Третий и четвертый разделы Положения связаны с составлением перечня видов деятельности и функций структурных звеньев, а также с описанием взаимоотношений между подразделениями. Разработка третьего раздела Положения опирается на процедуры определения зон ответственности организационных звеньев за реализацию видов деятельности и функций. Пятый и шестой разделы содержат перечни соответственно прав отдела и действий, за которые его руководитель несет ответственность. В седьмом разделе указывают изменения, которые необходимо осуществить в подразделениях в ОС, функциях, регламентах работ и составе персонала.
Восьмой раздел завершает разработку Положения и содержит структурную схему отдела и матрицу распределения ответственности.
Во время опроса руководителей и сотрудников подразделений уточняются данные по организационной структуре, стратегические цели и перспективы развития предприятия, а также распределение функций по подразделениям. При этом выявляются функциональные деятельности подразделений и функциональные взаимодействия между ними, а также внешние по отношению к предприятию информационные взаимодействия. Исходные данные для моделирования можно представить в виде таблицы, данной в приложении.
Модель «как есть» («as-is») представляет собой «снимок» положения дел на предприятии (оргструктура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные процессы) на момент обследования и позволяет понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации. В процессе анализа моделей бизнес-процессов «как есть» следует выяснить, соответствуют ли привлекаемые для выполнения процесса ресурсы поставленным задачам. Может оказаться, что для обеспечения выполнения процесса привлечены лишние ресурсы: материальные, финансовые, человеческие и т.д. Устранение лишних ресурсов должно привести к снижению стоимости бизнес-процесса в целом. Модель «как должно быть» объединяет перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков по совершенствованию деятельности предприятия.
Источник: economy-ru.com
CASE-технологии
CASE-технологии (Computer-Aided Software/System Engineering) — инструментальные средства, используемые при проектировании систем. CASE-технологии охватывают весь спектр работ по созданию и сопровождению программного обеспечения (главным образом, анализ и разработку, составление проектной документации, кодирование и тестирование системы).
CASE-технологии имеют ряд характерных особенностей:
- обладают графическими средствами для проектирования и документирования модели информационной системы
- имеют организованное специальным образом хранилище данных, содержащее информацию о версиях проекта и его отдельных компонентах
- расширяют возможности для разработки систем за счет интеграции нескольких компонент CASE-технологий
Современные CASE-средства поддерживают также множество технологий моделирования информационных систем, начиная от простых методов анализа и регламентации и заканчивая инструментами полной автоматизации процессов всего жизненного цикла программного обеспечения.
CASE-технологии можно классифицировать по функциональной направленности на
- средства моделирования предметной области
- средства анализа и проектирования
- технологии проектирования схем баз данных
- средства разработки приложений
- технологии реинжиниринга программного кода и схем баз данных
В настоящий момент на рынке программного обеспечения насчитывается более 300 различных CASE-средств. Наиболее известными являются CA ERwin Process Modeler (ранее BPwin), CA ERwin Data Modeler (ранее ERwin), Rational Rose, ARIS.
CA ERwin Process Modeler — CASE-технология фирмы Computer Associates, предназначенная для описания, анализа и моделирования бизнес-процессов. Использует семейство нотаций IDEF (а именно, IDEF0 и IDEF3), DFD, интегрируется с Erwin Data Modeler и входит совместно с данным средством в пакет CA ERwin Modeling Suite.
CA ERwin Data Modeler — CASE-средство от Computer Associates для моделирования баз данных, использующее методологию IDEF1X. Имеет два уровня представления модели — логический и физический — и позволяет строить одно из представлений на основе другого.
Rational Rose — технология фирмы Rational SoftWare Corporation, предназначенная для автоматизации этапов анализа и проектирования программного обеспечения, а также для генерации кодов на различных языках и выпуска проектной документации. Использует нотацию UML.
ARIS (Architecture of Integrated Information Systems) — CASE-технология фирмы IDS Scheer, ориентированная на описание бизнес-процессов организации. Методология ARIS рассматривает предприятие как совокупность взглядов на организационную структуру, структуру функций, структуру данных и структуру процессов. Использует нотации EPC (event-driven process chain), ERM (Entity-Relationship Model), UML.
CASE-технологии обладают очевидными достоинствами, поскольку существенно упрощают процесс разработки программного обеспечения и проектирования информационных систем и повышают его качество. Однако, несмотря на это, CASE-технологии находятся в стороне от непосредственного управления бизнесом. Они помогают разобраться с существующей и желаемой ситуацией, но не являются средством автоматизации процессов, что обуславливает целесообразность использования продуктов класса workflow, BPMS в сочетании с программами учета. Примером подобного продукта является «ПитерСофт: Управление процессами» на весьма распространенной в России платформе 1С.
Смотри также:
- Бизнес-моделирование
- Описание бизнес-процесса
- Модель бизнес-процесса
- Графическая нотация
- Нотация бизнес-процесса
- Модели системы при проектировании
Источник: piter-soft.ru
Разработка и внедрение информационной системы
Термин » CASE » ( Computer Aided Software / System Engineering ) используется в настоящее время в весьма широком смысле. Первоначальное значение термина » CASE «, ограниченное вопросами автоматизации разработки только лишь программного обеспечения ( ПО ), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом.
Теперь под термином » CASE -средства» понимаются программные средства , поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (приложений) и баз данных, генерацию кода, тестирование, документирование , обеспечение качества, конфигурационное управление и управление проектом , а также другие процессы.
Появлению CASE-технологии и CASE -средств предшествовали исследования в области методологии программирования . Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования , средств визуального моделирования и проектирования на базе языка UML ( Unified Modeling Language ), средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т. д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:
- подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;
- широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;
- внедрение сетевой технологии, которая предоставила возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
CASE -технология представляет собой методологию проектирования ИС , а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей . Большинство существующих CASE -средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств [Вендров А.М., http://www.citforum.ru/database/case/index.shtml].
CASE -средства позволяют создавать не только продукт, практически готовый к применению, но и обеспечить «правильный» процесс его разработки. Основная цель технологии — отделить проектирование программного обеспечения от его кодирования, сборки, тестирования и максимально «скрыть» от будущих пользователей все детали разработки и функционирования ПО . При этом значительно повышается эффективность работы проектировщика: сокращается время разработки, уменьшается число программных ошибок, программные модули можно использовать при следующих разработках.
Большинство CASE -средств основано на парадигме «методология/метод/ нотация /структура/средство».
Методология задает руководящие указания для оценки и выбора проекта разработки ПО , этапы и последовательность работ , правила применения тех или иных методов.
Метод — систематическая процедура или технология генерации описаний компонент ПО (например, описание потоков и структур данных).
Нотации предназначены для описания системы в целом, ее элементов, таких как графы, диаграммы, таблица , блок-схемы , алгоритмы, формальные языки и языки программирования.
Структуры являются средством для реализации структурного анализа и построения структуры конкретной системы.
Средства — технологические и программные инструменты для поддержки и усиления методов.
CASE-технологии обладают следующими основными достоинствами, которые позволяют широко использовать их при разработке информационных систем:
- ускоряют процесс коллективного проектирования и разработки;
- позволяют за короткий срок создать прототип заказанной системы с заданными свойствами;
- освобождают разработчика от рутинной работы, оставляя время для творчества;
- обеспечивают эффективность и качество разрабатываемого ПО за счет автоматизации контроля всего процесса разработки;
- поддерживают сопровождение и развитие системы на высоком уровне.
Следует отметить, что, несмотря на все потенциальные возможности CASE -средств, существует достаточно много примеров их неудачного внедрения, в результате которых CASE -средства становятся «полочным» ПО ( Shelfware ).
В связи с этим необходимо учитывать следующее:
- CASE-средства не обязательно дают немедленный эффект, он может быть получен только спустя какое-то время;
- реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
- CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения, эффективного обучения пользователей и регулярного применения.
Можно также перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE -средств:
- широкое разнообразие качества и возможностей CASE-средств;
- относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;
- широкое разнообразие в практике внедрения различных организаций;
- отсутствие детальных метрик и данных для уже выполненных и текущих проектов;
- широкий диапазон предметных областей проектов;
- различная степень интеграции CASE-средств в различных проектах.
Некоторые аналитики считают, что реальная выгода от использования некоторых типов CASE -средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.
Ниже перечислены основные виды и последовательность работ , рекомендуемые при построении логических моделей предметной области в рамках CASE-технологии анализа системы управления предприятием.
- Проведение функционального и информационного обследования системы управления (административно-управленческой деятельности) предприятием ( рис. 8.12):
- определение организационно-штатной структуры предприятия;
- определение функциональной структуры предприятия;
- определение перечня целевых функций структурных элементов (подразделений и должностных лиц);
- определение круга и очередности обследования структурных элементов системы управления согласно сформулированным целевым функциям ;
- обследование деятельности выделенных структурных элементов;
- построение FD-диаграммы системы управления с указанием структурных элементов и функций, реализация которых будет моделироваться на DFD -уровне.
- выделение множества внешних объектов, оказывающих существенное влияние на деятельность структурного элемента;
- спецификация входных и выходных информационных потоков ;
- выявление основных процессов, определяющих деятельность структурного элемента и обеспечивающих реализацию его целевых функций;
- спецификация информационных потоков между основными процессами деятельности, уточнение связей между процессами и внешними объектами;
- оценка объемов, интенсивности и других необходимых характеристик информационных потоков ;
- разработка иерархии диаграмм потоков данных , образующих функциональную модель деятельности структурного элемента;
- объединение DFD -моделей структурных элементов в единую модель системы управления предприятием.
- определение сущностей модели и их атрибутов;
- проведение атрибутного анализа и оптимизация сущностей;
- идентификация отношений между сущностями и определение типов отношений;
- анализ и оптимизация информационной модели;
- объединение информационных моделей в единую модель информационного пространства.
- определение границ автоматизации — составление перечня автоматизируемых структурных элементов, разбиение процессов основной деятельности на автоматические, автоматизированные и ручные;
- составление перечня подсистем и логических АРМов (автоматизированных рабочих мест), определение способов их взаимодействия;
- разработка предложений по очередности проектирования и реализации подсистем и отдельных логических АРМов , входящих в состав ИС;
- разработка требований к средствам базового технического обеспечения ИС;
- разработка требований к средствам базового программного обеспечения ИС.
Логическая модель, отображающая деятельность системы управления предприятием, и информационное пространство , в котором эта деятельность протекает, представляют собой «снимок» положения дел ( функциональная структура , роли должностных лиц, взаимодействие подразделений, принятые технологии обработки управленческой информации, автоматизированные и неавтоматизированные процессы и т. д.) на момент обследования. Эта модель позволяет понять, что делает и как функционирует предприятие с позиций системного анализа, и затем сформулировать предложения по улучшению ситуации.
Развитие логической модели предметной области , ее последовательное превращение в модель целевой ИС, позволит интегрировать перспективные предложения руководства и ведущих сотрудников предприятия, экспертов и системных аналитиков, сформировать видение новой, реорганизованной и автоматизированной деятельности предприятия ( рис. 8.12).
Построенная модель является законченным результатом по следующим причинам.
- Она включает в себя модель существующей неавтоматизированной технологии, принятой на предприятии. Формальный анализ этой модели позволяет выявить узкие места в управлении предприятием и сформулировать рекомендации по его улучшению (независимо от того, предполагается ли дальнейшая разработка автоматизированной системы или нет).
Источник: intuit.ru