Информация и информационная культура

 

 

Обучение группы реинжиниринга

 

 

 

Подготовка плана и  начало работ

 

 

 

Исследования

 

Аналитическое исследование опыта компаний с подобными процессами

 

 

 

Опрос клиентов и контрольных  групп для выявления существующих и будущих требований

 

 

 

Опрос служащих и руководителей  для выявления вопросов; мозговой штурм

 

 

 

Поиск в литературе и прессе данных о тенденциях в отрасли  и о чужом опыте

 

 

 

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

 

 

 

Обзор изменений и вариантов  технологий

 

 

 

Опрос владельцев и представителей руководства

 

 

 

Посещение кружков и семинаров

 

 

 

Сбор данных от внешних  экспертов и консультантов

 

 

 

Проектирование

 

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

 

 

 

Проработка сценариев "а  что, если?" и применение "шаблонов успеха" других компаний

 

 

 

Создание при помощи специалистов 3-5 моделей; разработка комплексных  моделей, в которых собрано лучшее от каждой из предыдущих

 

 

 

Создание картины идеального процесса

 

 

 

Определение моделей нового процесса и их графическое представление

 

 

 

Разработка организационной  модели в сочетании с новым  процессом

 

 

 

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

 

 

 

Выделение краткосрочных  и долгосрочных мер

 

 

 

Утверждение

 

Анализ затрат и преимуществ; расчет прибыли на капитал

 

 

 

Оценка влияния на клиентов и служащих; оценка влияния на конкурентоспособность

 

 

 

Подготовка официального документа для высшего руководства

 

 

 

Проведение обзорных совещаний  для ознакомления и утверждения  деталей проекта оргкомитетом и  высшим руководством

 

 

 

Внедрение

 

Завершение подробной  разработки процессов и организационных  моделей; определение новых рабочих  обязанностей

 

 

 

Разработка систем поддержки

 

 

 

Реализация предварительных  вариантов и первичные испытания

 

 

 

Ознакомление работников с новым вариантом; разработка и  осуществление плана реформы

 

 

 

Разработка поэтапного плана; внедрение как таковое

 

 

 

Разработка плана обучения; обучение работников новым процессам  и системам

 

 

 

Последующие мероприятия

 

Разработка мероприятий  по периодической оценке; определение  итогов нового процесса; внедрение  программы непрерывного совершенствования  нового процесса

 

 

 

Предоставление окончательного отчета оргкомитету и администрации

 

Отображение и моделирование  процессов

 

На сегодняшний день получили распространение три основные методологии  функционального моделирования (и  сопутствующий им инструментарий): IDEF (Integrated DEFinition), UML (Unified Modeling Language) и ARIS (Architecture of Integrated Information Systems). Для каждой из них существуют определенные программные продукты, которые помимо разработки позволяют проводить преобразования и операции для последующей работы с полученными моделями. Наибольшее распространение сегодня получили методологии IDEF и программные продукты BPWin, содержащие методологии IDEF0, IDEF3, DFD (Data Flow Diagrams) и ERWin (IDEF1x) от компании Computer Associates.

 

 

История IDEF начинается с 70-х  годов ХХ века с методологии SADT (Structured Analysis and Design Technique), разработанной Дугласом Россом (Softtech INC). Изначально SADT применялось  Министерством обороны США для  практического моделирования процессов  в рамках программы ICAM (Integrated Computer Aided Manufacturing). Принципиальным требованием  при разработке рассматриваемого семейства  методологий была возможность эффективного обмена информацией между всеми  специалистами - участниками программы ICAM (Icam DEFinition). В последующем эта  методология была трансформирована в стандарт IDEF0 (Function Modeling, FIPS №183). Семейство IDEF включает уже упомянутые IDEF3 (Process Description Capture) и IDEF1x (Data Modeling, FIPS №184).

 

 

После опубликования стандарты  были успешно применены в самых  различных областях бизнеса, показав  себя эффективным средством анализа, конструирования и отображения  бизнес-процессов(к слову сказать, они активно применяются и в отечественных госструктурах, например, в Государственной Налоговой Инспекции). Более того, собственно с широким применением IDEF (и предшествующей методологии SADT) и связано возникновение основных идей популярного ныне понятия "реинжиниринг бизнес-процессов" (Business Process Reengineering - BPR).

 

 

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

 

 

Работа с использованием метода IDEF начинается с постановки цели моделирования. Мировой опыт свидетельствует, что ошибки при постановке цели приводят в среднем к 50% неудач в процессе моделирования. Формулирование цели изначально направляет работу в заданном направлении, а значит, ограничивает круг вопросов для анализа. Практическая работа начинается с определения контекста (Context, Context Diagram), то есть верхнего уровня системы, в нашем случае - предприятия. После формулировки цели необходимо очертить область моделирования (Scope), которая в последующем будет определять общие направления движения и глубину детализации (Decomposition). Собственно, сама методология IDEF определяет стандартизированные объекты для работы и отображения. Например, к таковым относятся функция (Activity), интерфейсная дуга (Arrow), заметка (Note), а также способ их расположения и трактования (Semantics).

 

 

В последнее время на российском рынке появился программный продукт Business Studio, который специально создан для работы с методами IDEF и обладает интуитивным и дружественным  интерфейсом (User-friendly Interface).

 

 

 

 

 

 

Рис. 8.10.  Базовый блок методологии IDEF0

 

 

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

 

 

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

 

 

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

 

 

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

 

 

 

 

 

 

увеличить изображение

Рис. 8.11.  Пример функциональной модели процесса отгрузки и доставки

 

 

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

 

 

Пример функциональной модели процесса отгрузки и доставки продукции  показан на рис. 8.11.

 

 

Степень формализации описания бизнес-процессов может быть различной  в зависимости от решаемых при  этом задач. Для описания информационных процессов разработан специализированный язык BPEL (Business Process Execution Language). BPEL создан на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия Web-служб и включает в эту модель поддержку транзакций.

 

 

В настоящее время активно  развивается методология BPMS (Business Process Management System) - класс программного обеспечения  для управления бизнес-процессами и  административными регламентами. (Употребляются  также термины "BPM-система" и  просто "BPM"). Применение BPMS позволяет  организовать эффективное взаимодействие между управленцами и ИТ-специалистами, лучше использовать существующие подсистемы и ускорить разработку новых.

 

 

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

 

 

Современные методы разработки и развития программного обеспечения  ИС в полной мере стараются ориентироваться  на возможности автоматизированного  оперативного внесения изменений. Наиболее сложным оказался процесс стандартизации языка BPEL для унификации использования  одних и тех же конструкций  программным обеспечением разных производителей. Фирмы IBM и Microsoft определили два довольно-таки схожих языка: WSFL (Web Services Flow Language) и Xlang соответственно.

 

 

Рост популярности BPML и  открытое движение BPMS к пользователям  привело корпорации Intalio Inc., IBM и Microsoft к решению объединить эти языки  в новый язык BPEL4WS. В апреле 2003 года корпорации BEA Systems, IBM, Microsoft, SAP и Siebel Systems передали BPEL4WS версии 1.1 в OASIS (Organization for the Advancement of Structured Information Standards) для стандартизирования в Web Services BPEL Technical Committee. Хотя BPEL4WS появился в версиях 1.0 и 1.1, технический комитет WS-BPEL OASIS проголосовал 14 сентября 2004 года за то, чтобы назвать спецификацию WS-BPEL 2.0. Это изменение было сделано, чтобы выравнять BPEL с другими стандартами Web-сервисов по соглашению об именовании начинаются на WS-.

 

 

В июне 2007 года корпорации Active Endpoints, Adobe, BEA, IBM, Oracle и SAP опубликовали спецификации BPEL4People и WS-HumanTask, в которых описывалось, как может быть реализовано в BPEL взаимодействие с людьми. О дальнейшем направлении разработки BPEL разгорается  жаркая дискуссия. Предполагается добавление семантики в BPEL в форме WS-HumanTask и  других разнообразных дополнений.

Обеспечение процесса анализа  и проектирования ИС возможностями CASE-технологий

 

Термин "CASE" (Computer Aided Software/System Engineering) используется в настоящее  время в весьма широком смысле. Первоначальное значение термина "CASE", ограниченное вопросами автоматизации  разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом.

 

 

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

 

 

Появлению CASE-технологии и CASE-средств  предшествовали исследования в области  методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, средств визуального моделирования и проектирования на базе языка UML (Unified Modeling Language), средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т. д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:

 

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

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

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

 

 

CASE-технология представляет  собой методологию проектирования  ИС, а также набор инструментальных  средств, позволяющих в наглядной  форме моделировать предметную  область, анализировать эту модель  на всех этапах разработки  и сопровождения ИС и разрабатывать  приложения в соответствии с  информационными потребностями  пользователей. Большинство существующих CASE-средств основано на методологиях  структурного (в основном) или объектно-ориентированного  анализа и проектирования, использующих  спецификации в виде диаграмм  или текстов для описания внешних  требований, связей между моделями  системы, динамики поведения системы  и архитектуры программных средств  [Вендров А.М., www.citforum.ru/database/case/index.shtml].