Структурный (процессный) подход
К МОДЕЛИРОВАНИЮ БИЗНЕС-ПРОЦЕССОВ
3.2.1.
ПРИНЦИПЫ ПРОЦЕССНОГО ПОДХОДА
Основной принциппроцессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, формирующие значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься. Модель, основанная на организационно-штатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором в принципе руководству и так известно, иначе оно бы не инициировало соответствующие работы), на ее основе можно только внести предложения об изменении этой структуры. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.
В соответствии с этим принципом бизнес-модель должна выглядеть следующим образом:
1. Верхний уровень модели должен отражать только контекст системы — взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.
2. На втором уровне модели должны быть отражены основные виды деятельности (тематически сгруппированные бизнес-процессы) предприятия иих взаимосвязи. В случае большого их количества некоторые из них можно вынести на третий уровень модели. Но в любом случае под виды деятельности необходимо отводить не более двух уровней модели.
3. Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций — совокупностей операций, сгруппированных по определенным признакам. Бизнес-функции детализируются с помощью элементарных бизнес-операций.
4. Описание элементарной бизнес-операции осуществляется посредством задания алгоритма ее выполнения.
Принципы формирования бизнес-модели на верхних уровнях декомпозиций:
· следует избегать чрезмерной детализации (модель бизнес-процесса верхнего уровня должна содержать не более 6-8 блоков функций);
· следует использовать реально существующие названия функций или работ;
· не следует пытаться детально отразить всю существующую логику процесса (это будет сделано при формировании детальных моделей);
· важно отразить общую последовательность работ, подразделения участвующие в их исполнении, основные ресурсы;
· важно отразить основную логику процесса.
Общее число уровней в модели (включая контекстный) не должно превышать 5—6. Практика показывает, что этого вполне достаточно для построения полной функциональной модели современного предприятия любой отрасли.
3.2.2.
ПРИМЕНЕНИЕ ДИАГРАММ
ПОТОКОВ ДАННЫХ
При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей «AS-IS» и «AS-TO-BE», отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними. При этом описание используемых в организации и данных на концептуальном уровне, независимом от Средств реализации базы данных (СУБД), выполняется с помощью ERM.
Ниже перечислены основные виды и последовательность работ при построении бизнес-моделей с использованием методики Йордона (пример ее применения приведен в подразд. 3.2.5).
1. Описание контекста процессов и построение начальной контекстной диаграммы.
Начальная контекстная диаграмма потоков данных должна содержать нулевой процесс с именем, отражающим деятельность организации, внешние сущности, соединенные с нулевым процессом посредством потоков данных. Потоки данных соответствуют документам, запросам или сообщениям, которыми внешние сущности обмениваются с организацией.
2. Спецификация структур данных.
Определяется состав потоков данных и готовится исходная информация для построения концептуальной модели данных в виде структур данных. Выделяются все структуры и элементы данных типа «итерация», «условное вхождение» и «альтернатива». Простые структуры и элементы данных объединяются в более крупные структуры. В результате для каждого потока данных должна быть сформирована иерархическая (древовидная) структура, конечные элементы (листья) которой являются элементами данных, узлы дерева являются структурами данных, а верхний узел дерева соответствует потоку данных в целом. Результат можно представить в виде текстового описания, подобного описанию структур данных в языках программирования.
3. Построение начального варианта концептуальной модели данных.
Для каждого класса объектов предметной области выделяется сущность. Устанавливаются связи между сущностями и определяются их характеристики (мощность связи и класс принадлежности). Строится диаграмма «сущность-связь» (без атрибутов сущностей).
4. Построение диаграмм потоков данных нулевого и последующих уровней.
Для завершения анализа функционального аспекта деятельности организации детализируется (декомпозируется) начальная контекстная диаграмма. При этом можно построить диаграмму для каждого события, поставив ему в соответствие процесс и описав входные и выходные потоки, накопители данных, внешние сущности и ссылки на другие процессы для описания связей между этим процессом и его окружением. После этого все построенные диаграммы сводятся в одну диаграмму нулевого уровня.
Проверяется соответствие между контекстной диаграммой и диаграммой нулевого уровня (каждый поток данных между системой и внешней сущностью на диаграмме нулевого уровня должен быть представлен и на контекстной диаграмме).
Процессы разделяются на группы, которые имеют много общего (работают с одинаковыми данными и/или имеют сходные функции). Они изображаются вместе на диаграмме более низкого (первого) уровня, а на диаграмме нулевого уровня объединяются в один процесс. Выделяются накопители данных, используемые процессами из одной группы.
Декомпозируются сложные процессы и проверяется соответствие различных уровней модели процессов.
Накопители данных описываются посредством структур данных, а процессы нижнего уровня — посредством спецификаций.
5. Уточнение концептуальной модели данных.
Определяются атрибуты сущностей. Выделяются атрибуты-идентификаторы. Проверяются связи, выделяются (при необходимости) зависимые от идентификатора сущности и связи «супертип-подтип».
Проверяется соответствие между описанием структур данных и концептуальной моделью (все элементы данных должны присутствовать на диаграмме в качестве атрибутов).
3.2.3.