Лекция 7ВР (Лекции в PDF)

Лекция7Стандарты проектирования ИС.В настоящее время в России резко возрос интерес к общепринятым на Западе стандартамменеджмента, однако, в реальной практике управления существует один оченьпоказательный момент. Многих руководителей до сих пор можно поставить в тупикпрямым вопросом об организационной структуре компании или о схеме существующихбизнес-процессов.

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

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

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

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

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

С помощью наглядногографического языка IDEF0, изучаемая система предстает перед разработчиками ианалитиками в виде набора взаимосвязанных функций (функциональных блоков - втерминах IDEF0). Как правило, моделирование средствами IDEF0 является первымэтапом изучения любой системы;IDEF1 – методология моделирования информационных потоков внутри системы,позволяющая отображать и анализировать их структуру и взаимосвязи;IDEF1X (IDEF1 Extended) – методология построения реляционных структур.IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – EntityRelationship) и, как правило, используется для моделирования реляционных базданных, имеющих отношение к рассматриваемой системе;IDEF2 – методология динамического моделирования развития систем.

В связи свесьма серьезными сложностями анализа динамических систем от этого стандартапрактически отказались, и его развитие приостановилось на самом начальномэтапе. Однако в настоящее время присутствуют алгоритмы и их компьютерныереализации, позволяющие превращать набор статических диаграмм IDEF0 вдинамические модели, построенные на базе “раскрашенных сетей Петри” (CPN –Color Petri Nets);IDEF3 – методология документирования процессов, происходящих в системе,которая используется, например, при исследовании технологических процессов напредприятиях.

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

На основе этих утверждений формируются выводы одальнейшем развитии системы и производится её оптимизация.В рамках этой статьи мы рассмотрим наиболее часто используемую методологиюфункционального моделирования IDEF0.История возникновения стандарта IDEF0Методологию IDEF0 можно считать следующим этапом развития хорошо известногографического языка описания функциональных систем SADT (Structured Analysis andDesign Teqnique). Несколько лет назад в России небольшим тиражом вышла одноименнаякнига, посвящанная описанию основных принципов построения SADT-диаграмм.Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширнойпрограммы автоматизации промышленных предприятий, которая носила обозначениеICAM (Integrated Computer Aided Manufacturing) и была предложена департаментомВоенно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало своеобозначение от названия этой программы (IDEF=ICAM DEFinition).

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

C 1981 года стандарт IDEF0 претерпел несколько незначительныхизменения, в основном ограничивающего характера, и последняя его редакция былавыпущена в декабре 1993 года Национальным Институтом По Стандарам и ТехнологиямСША (NIST).Основные элементы и понятия IDEF0Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежатчетыре основных понятия:Первым из них является понятие функционального блока (Activity Box).Функциональный блок графически изображается в виде прямоугольника (см.

рис. 1) иолицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы.По требованиям стандарта название каждого функционального блока должно бытьсформулировано в глагольном наклонении (например, “производить услуги”, а не“производство услуг”).Каждая из четырех сторон функционального блока имеет своё определенное значение(роль), при этом:••••Верхняя сторона имеет значение “Управление” (Control);Левая сторона имеет значение “Вход” (Input);Правая сторона имеет значение “Выход” (Output);Нижняя сторона имеет значение “Механизм” (Mechanism).Каждый функциональный блок в рамках единой рассматриваемой системы должен иметьсвой уникальный идентификационный номер.Рисунок 1. Функциональный блок.Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow).Также интерфейсные дуги часто называют потоками или стрелками.

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

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