Методология обследования предприятия и создание информационной модели бизнеса

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

• бизнес-функции, описывающие, ЧТО делает бизнес;
• основные, вспомогательные и управленческие процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;
• организационно-функциональную структуру, определяющую, ГДЕ исполняются бизнес-функции и бизнес-процессы;
• фазы, определяющие, КОГДА (и в какой последовательности) должны быть внедрены те или иные бизнес-функции;
• роли, определяющие, КТО исполняет бизнес-функции и КТО является "хозяином" бизнес-процессов;
• правила, определяющие связь и взаимодействие между всеми ЧТО, КАК, ГДЕ, КОГДА и КТО.

2.2. Стадии разработки

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

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

 
Рисунок 4 - Схема обследования предприятия

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

Третья стадия анализа, содержащая элементы проектирования, - создание усовершенствованной обобщенной логической модели, отображающей реорганизованную предметную область или ее часть, которая подлежит автоматизации - модель "Как должно быть" (As To Be).

Заканчивается процесс (четвертая стадия) разработкой "Карты автоматизации", представляющей собой модель реорганизованной предметной области, на которой обязательно обозначены "границы автоматизации".

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

 
Рисунок 5 - Стадии построения модели информационной системы

На стадии анализа требований к проектируемой системе вводятся:

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

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

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

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

Производительность и  надежность являются главными факторами, определяющими эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

• проектирование структур данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• проектирование конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры, параллельной обработки, распределенной обработки данных и т.п.

На основе результатов  системного анализа на стадии предварительного проекта разрабатываются:

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

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

На стадии детального проектирования разрабатываются:

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

Стадия реализации ИС предусматривает разработку и тестирование компонентов и комплексное тестирование системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Степень формализации описания бизнес-процессов  может быть различной в зависимости  от решаемых при этом задач. Для описания информационных процессов разработан специализированный язык 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 соответственно.