Любое обследование компании начинается с анализа бизнес-процессов, их соответствия стратегии развития бизнеса в целом. Особую значимость приобретает наличие общего языка восприятия текущих и окончательных результатов такой работы для принятия взвешенного управленческого решения [1, 2, 4, 7]. Многие годы для аналитиков, проектировщиков, постановщиков задач таким языком являются методологии моделирования бизнес-процессов IDEF0, IDEF3, DFD, диаграммы К. Исикавы, Дерево отказов. В данной статье мы подробнее остановимся на метрологии IDEF0 (Integration Definition for Function Modeling). IDEF0 – методология создания функциональной модели, которая является структурированным изображением функций производственной системы или среды, а также информации и объектов, связывающих эти функции [5, 14, 15]. Часто при разработке данной модели возникают трудности в указании ресурсов на дугах диаграммы, а именно что можно указывать, а что нельзя, ведь в стандарте это не чётко прописано. А загромождение диаграммы приводит к плохой читабельности информации на ней. Как формировать цель и точку зрения? Что можно указывать в функциональном блоке? Может ли человек, обозначенный в точке зрения, находиться в механизме и др.? В рамках исследования данных вопросов нами были разработаны рекомендации по совершенствованию построения модели IDEF0, подробно рассмотренные в пособии «IDEF0, DFD, IDEF3, FISHBONE, FTA: теория и практика бизнес-моделирования». В данной статье мы остановимся на рекомендациях по совершенствованию построения контекстной диаграммы (рис. 1). Рассмотрим подробнее.
1. Функциональный блок, прямоугольник, в котором отображаются описываемый моделью процесс, бизнес-процесс или функция, имеет уникальный идентификационный номер (значение должно быть выражено в отглагольном существительном). Функция – это задача, которую решает компания для собственного выживания и для достижения поставленных целей. Функция отвечает на вопрос «что делать». Бизнес-процесс – это просто реализация функции во времени, способ решения бизнес-задачи, отвечает на вопрос «как делать». Поэтому функции и процессы не являются противоположностями, а представляют лишь различные уровни абстракции. То есть процесс включает в себя «подпроцессы», а «подпроцессы» – функции (первично – процесс, вторично – функция). Например: организация деятельности бухгалтера, продажа товара, учет сырья и материалов, подготовка бухгалтерской отчетности, организация работы предприятия ООО «М» и др. [3, 9, 12]. Процесс (ISO 9000:2000): «совокупность взаимосвязанных или взаимодействующих видов деятельности, которые преобразуют входы в выходы» и т.д. Например: приготовление блюда, организация дня рождения, подготовка к выпускному и др.
2. Интерфейсная дуга, стрелка (имеет уникальное наименование, которое должно быть оборотом существительного; началом и концом дуги могут быть только функциональные блоки; источником может быть только выходная сторона блока, а приемником – любая из трех оставшихся). Рассмотрим виды дуг на диаграмме:
2.1. Входная стрелка (Input) – это все то, что используется для преобразования процесса, бизнес-процесса или функции: субъекты, объекты, данные, информация, документы, программное обеспечение (автоматизированная система (АС), автоматизированная информационная система (АИС), корпоративная информационная система (КИС), автоматизированная система управления (АСУ), автоматизированное рабочее место (АРМ), модуль и т.д.). Так как на входе может быть все то, что используется для преобразования процесса, субъекты на входе будут только в том случае, когда их используют для преобразования этого процесса, т.е. субъект выступает в качестве ресурса. Пример № 1: процесс на контекстной диаграмме – организация работы парикмахера. Субъект (клиент до услуги) будет находиться на входе, на выходе – субъект (клиент после услуги), а парикмахер будет выступать в качестве исполнителя и находиться в «механизме». Пример № 2: процесс на контекстной диаграмме – поступление абитуриента в вуз. Абитуриент будет находиться на входе, на выходе – студент, а технический секретарь приемной комиссии и экзаменатор – в механизме. Значения АС, АИС, КИС, АСУ, АРМ, модуль будут на входе только в том случае, если их модернизируют, сопровождают, утилизируют… В остальных случаях они будут выступать в качестве средства, с помощью которого обрабатывают информацию, а сама информация из АИС будет располагаться на входе.
2.2. Выходные дуги (Output) – изображают значения, полученные в результате выполнения процесса, бизнес-процесса или функции: субъекты, объекты, данные, информация, документы, ПО (АС, АИС, КИС, АСУ, АРМ, модуль и т.д.). Например, бизнес-процесс на контекстной диаграмме – учет готовой продукции (ГП). Так как в отделе для постоянного учета ГП кладовщик ведет книгу ГП, в которой учитывается поступление и выбытие ГП, книга ГП будет отображаться на контекстной диаграмме на входе, а на выходе – книга ГП с информацией о поступлении или выбытии ГП за период с __ и по__.
2.3. В качестве управляющей информации (Control) используются правила преобразования входной информации в выходную: данные, информация, документы. Субъекты, объекты и ПО (АС, АИС, КИС, АСУ, АРМ), модуль не могут находиться в управлении, потому что нельзя управлять человеком, столом или программным средством. Вместо перечисленного будут: положение о деятельности сотрудника, приказы и распоряжения начальника, инструкция по сборке стола, инструкция по работе с программным средством и т.д.
2.4. Дуги механизмов (Mechanism) должны отражать ресурсы и людей, с помощью которых будет происходить реализация процесса: субъекты, объекты, данные, информация, документы, ПО (АС, АИС, КИС, АСУ, АРМ, модуль и т.д.). Стрелки механизма, направленные вниз, являются стрелками вызова.
3. Цель модели – это то, для чего строится модель. Степень точности модели зависит от поставленной цели, которая отражает причину создания модели и определяет ее назначение; цель является получением ответов на совокупность вопросов, которые неявно присутствуют (подразумеваются) в процессе анализа.
Четко определенная цель становится критерием окончания моделирования. Таким образом, цель модели – это набор вопросов, на которые должна ответить модель. Например, бизнес-процесс на контекстной диаграмме – учет готовой продукции (ГП) на складе. Тогда цель может звучать так: сократить временные, трудовые и финансовые затраты по учету ГП на складе; описать бизнес-процесс учета ГП на складе; описать бизнес-процесс учета ГП на складе с целью выявления «узких мест» и др. [6, 8, 13].
Рис. 1. Рекомендации по построению контекстной диаграммы IDEF0
Рис. 2. Пример диаграммы IDEF0. Контекстная диаграмма «Ведение заказов в ОС»
Рис. 3. Пример диаграммы IDEF0. Декомп. контекст. диаграммы «Ведение заказов в ОС»
4. В точке зрения указывается не тот субъект, который разрабатывает данную модель (например, системный аналитик), а тот, который описывает её и «видит сверху» весь процесс, а не выполняет какую-то часть из функций данного процесса. Следовательно, на дуге «механизм» данного субъекта указывать нежелательно. При выборе точки зрения можно фиксировать дополнительные/альтернативные точки зрения.
5. В примечании прописывается дополнительная информация к аналитику модели. Сокращения на модели – это часто встречающиеся слова на диаграммах. Например: И – информация, ОС – отдел сбыта, ГБ – главный бухгалтер, ГП – готовая продукция и др. [10, 11].
Теперь обобщим выше рассмотренные рекомендации в одну сводную схему, представленную на рис. 1, а также на рис. 2 и 3 представлен пример диаграммы IDEF0.
Рецензенты:
Шепелёв С.Д., д.т.н., доцент, декан инженерно-технологического факультета, Челябинская государственная агроинженерная академия, г. Челябинск;
Дмитриев М.С., д.т.н., профессор кафедры автомобильного транспорта, информационных технологий и методики обучения техническим дисциплинам, Профессионально-педагогический институт, Челябинский государственный педагогический университет, г. Челябинск.