2.4.4.2. Средства автоматизированного проектирования организационных систем

Главная постановочная цель автоматизированного проектирования – создание внешней и внутренней моделей организационной системы.

В существующей практике «ролевой подход» – основа описания внешней модели (модели взаимодействия клиентов с организацией) при реинжиниринге бизнес-процессов. Суть данного подхода – описание всех функций, в которых субъектом управления является клиент бизнеса, а объектом управления – бизнес-структура и ее механизмы. Методологически организационное проектирование пока опирается на принципы объектно-ориентированного программирования. Частичным недостатком данных принципов является произвольное, ориентированное в большей степени на автоматизацию процессов программирования, определение объектов, отношений и их классов. Как уже было сказано выше, используется подход «снизу». В этом смысле, в качестве фундаментальных средств объектно-ориентированного программирования, давших толчок различным методологиям организационного проектирования можно отметить теорию нормализации отношений Эдгара Френка Кодда (методологическую основу реляционных СУБД) и язык программирования С++, имеющий в своей основе универсальный теоретико-множественный подход, пригодный для описания любой структурированно-событийной системы. Естественно, что подобная универсальность приводит к необходимости создания дополнительных тезаурусов, комментариев и т.д.

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

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

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

Заметим, что системным проектированием занимаются специалисты-разработчики автоматизированных систем управления: постановщики, программисты, системные аналитики. Для автоматизации собственного труда наиболее продвинутые разработчики специализировались в области разработки специальных, так называемых CASE (Computer Aided Software Engineering) – программных средств. Естественно, что подобные программные средства опираются на определенный стандарт, называемый методологией системного проектирования. Можно сказать, что разработчики данных методологий обеспечили взгляд «снизу» на организационное проектирование.

Рассмотрим самую распространенную методологию системного проектирования.

Методология структурного анализа и проектирования – SADT (Structured Analysis and Design Technique), интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования.

Метод SADT разработан в 1973 году Дугласом Россом (SoftTech, Inc.). Министерство обороны США выступило инициатором разработки стандарта IDEF0 (Icam DEFinition) – основанном на методологиии SADT. Стандарт IDEF0 предназначен для моделирования бизнес-процессов. Представляет собой главную часть программы ICAM (Integrated Computer Aided Manufacturing - интегрированной компьютеризации производства).

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

 Описание модели SADT организовано в виде иерархии взаимосвязанных диаграмм. Вершина этой древовидной структуры представляет собой самое общее описание системы, а ее основание состоит из наиболее детализированных описаний.

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

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

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

•  функция - некоторое действие, необходимое для решения задачи.

•  декомпозиция функции - разбиение функции на множество подфункций.

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

Метод основан на следующих концепциях:

•  графическое представление блочного моделирования;

•  строгость и точность;

•  отделение организации от функции (исключение влияния административной структуры на функциональную модель).

Диаграммы - главные компоненты модели, на которых в виде блоков и дуг представлены все функции (работы) организации и интерфейсы.

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

Использование для моделирования стандартов семейства IDEF

На основе методологии SADT в России были разработаны и утверждены «Рекомендации по стандартизации «Методология функционального моделирования» — Р 50.1.028-2001, являющиеся аналогом стандарта IDEF0 [43].

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

Стандарт функционального моделирования IDEF0 поддерживается разными программными продуктами: CAERwinProcessModeler(ранееBPwin),BusinessStudio,IDEF0.EMTool,Design/IDEF3.5,Ramus, MS Visio.

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

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

Основные элементы стандарта IDEF0

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

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

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

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

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

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

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

В зависимости от того, к какой из сторон подходит интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”.

Рис.2.3. Функциональный блок