Набор символов или обозначений, с помощью которых описывается бизнес-процесс, принято называть языком или методологией описания бизнес-процессов.
Наиболее распространенными методологиями, используемыми при моделировании, являются: описание бизнес-процессов, описание потоков работ и описание потоков данных. Для более глубокого понимания сути бизнеса и его ключевых процессов используются графические способы описания процессов и специальные инструменты.
В простых случаях и сегодня используют обычную блок-схему и словесное описание бизнес-процесса.
Обычная блок-схема процесса, изображается с помощью прямоугольников – обозначающих действия, ромбов – обозначающих принимаемые решения и стрелок – соединяющих эти элементы и показывающих их взаимосвязь.
Описание бизнес-процесса, отвечает на вопросы, что, кто, где, как, зачем и почему, а также каковы затраты времени и денежных средств на принятие решений, ожидание и осуществление действий в бизнес-процессе.
Однако, эта простая, наглядная и очевидная методология не всегда достаточна для определения эффективности реализации сложного бизнес-процесса, поэтому был разработан ряд более сложных и эффективных методологий использующих возможности компьютерной техники.
Функционально-ориентированные модели описания бизнес-процессов. VAD, IDEF, DFD
Эти методологии эволюционировали по мере развития технических и программных средств.
В 40-60-е гг. появились алгоритмические языки описания.
В 60-е г. была разработана методология SADT — структурного анализа и проектирования.
В 70-80-е гг. разработаны методологии DFD, ERD, IDEF, IDEF1X и др.
В 90-е и последующие годы появились: UML – универсальный язык моделирования; методология ARIS – архитектура интегрированных информационных систем; методологии компаний Oracle, Baan, ReTrink, Rational и др.
При инжиниринге участвуют специалисты двух типов – профессионалы в области реконструированного бизнеса и разработчики информационных систем. Опыт реинжиниринга показал, что по-настоящему успешное и новаторское внедрение информационных технологий является уникальным творческим процессом, в котором управляющие и специалисты технологи, знакомясь с методами информационных технологий, сами делают открытия относительно возможностей их использования в своем конкретном бизнесе. В то же время создание высококачественных информационных систем требует участия профессионалов в области информационных технологий. Возникает проблема поиска общего языка, интеграции современных технологий моделирования и разработки сложных систем: объективно-ориентированные методы, CASE-технологии, инженерия знаний, имитационное моделирование процессов и методы быстрой разработки приложений RAD (Rapid Application Development).
Сегодня базовой методологией описания бизнес-процессов признано объектно-ориентированное моделирование. Традиционно, создавая информационные системы компаний, разработчики отталкивались от данных и используемые ими подходы были ориентированы на описание данных и сущности их взаимосвязей, но не поведение этих сущностей, поэтому создаваемые на этой основе системы нередко оказывались неадекватны решаемым задачам. Современный инжиниринг использует объективно-ориентированный подход, который ориентирован на процессы, а не на данные. Это позволяет описывать как данные о сущностях, так и их поведение и обеспечивает создание прозрачных, легко модифицируемых моделей бизнеса и информационных систем.
Что такое бизнес-процесс? Моделирование и анализ бизнес-процессов
Имитационное моделирование обеспечивает не только наиболее глубокое представление моделей для непрограммируемого пользователя, но и наиболее полные средства анализа таких моделей. Модели создаются в виде потоковых диаграмм, где представлены основные рабочие процедуры, используемые в компании, описано их поведение, а также информационные и материальные потоки между ними.
Однако построение имитационных моделей довольно трудоемкий процесс и нередко требует от пользователя специальной подготовки, а для описания рабочих процедур может понадобиться дополнительное программирование. Чтобы преодолеть эти трудности, используют методы инженерии знаний. Во-первых, с их помощью можно непосредственно представлять в моделях формализуемые знания менеджеров о бизнес-процессах и, в частности, о рабочих процедурах. Во-вторых, решается проблема создания интеллектуального интерфейса конечного пользователя со сложными средствами анализа моделей. Методы быстрой разработки приложений позволяют сокращать время создания поддерживающих информационных систем и, следовательно, используются не только в ходе инжиниринга, но и на этапе эволюционного развития компании, сопровождающегося модификациями и улучшениями информационных систем.
Методология DFD. Стандарты DFD (Data Flow Diagramming) и WFD (Work From Diagram) содержат набор символов или обозначений, с помощью которых описывается бизнес-процесс. Язык DFD и WFD считают классическим.
Методология DFD использует для описания бизнес-процессов диаграммы потоков данных. Диаграммы позволяют описывать потоки документов (документооборот) и потоки материальных ресурсов, т.е. движение материалов от одной работы к другой, и выявлять основные потоки данных. Описания могут создаваться как по функциональному признаку, так и на основе процессного подхода. В первом случае получаются схема обмена данными между подразделениями, а во втором – модели бизнес-процессов.
Большинство консалтинговых компаний в проектах по оптимизации деятельности организаций в общем случае применяют типовую методологию описания бизнес-процессов. Эта методология использует два типа бизнес-моделей. Одна применяется для описания бизнес-процессов верхнего уровня и является прототипом классической DFD-модели. Вторая – для описания процессов нижнего уровня и соответствует принципам WFD-схемы.
Пример типовой модели описания бизнес-процессов верхнего уровня представлен на рис. 29.
Рис. 29. Пример типового описания бизнес-процессов верхнего уровня в DFD
На первом уровне схематично представляются основные компоненты деятельности организации. В нашем примере это: «закупки», «производство» и «сбыт». Каждый из этих блоков представляет декомпозицию бизнес-процессов второго уровня. В нашем случае бизнес-процесс второго уровня: «обработка заявок – выбор поставщика – создание заказа на закупку и отслеживание его выполнения». Схема бизнес-процесса «выбор поставщика – утверждение заявок – составление сводной заявки» третьего уровня, представляет декомпозицию бизнес-процесса второго уровня «обработка заявок».
Типовая модель описания бизнес-процессов нижнего уровня, используемая консалтинговыми компаниями на основе подхода «Swimmer lanes» представлена на рис. 30.
Рис. 30. Типовая модель описания бизнес-процессов нижнего уровня в WFD
Методология IDEF это наиболее глубоко проработанная и обширная методология, которая позволяет описывать не только бизнес-процессы, но и функциональные блоки (например, маркетинг и финансы), различные объекты в компании и действия над ними (например, весь комплекс процессов обработки и выполнения заказа клиента), а также состояние и динамику развития бизнес-единиц компании в целом. Она включает 14 стандартов. Основные из них:
IDEF0 – методология моделирования функциональных блоков;
IDEF1 – методология моделирования информационных потоков в компании;
IDEF2 – методология моделирования динамики развития компании;
IDEF3 – методология документирования бизнес-процессов в компании;
IDEF4 – методология описания различных объектов в компании и действий над ними;
IDEF5 – методология описания текущего состояния компании и тенденций изменения.
Методология ORACLE. Чтобы осуществить эффективную автоматизацию нужно правильно настроить информационную систему. Поэтому разработчики информационных систем разработали свои стандарты и программные продукты, с помощью которых описывается бизнес-деятельность компании. Наиболее крупные из них SAR/R3, BAAN и ORACLE. Каждый их этих стандартов содержит несколько бизнес-моделей, с помощью которых описываются бизнес-процессы, организационная структура и строятся прочие бизнес-модели.
Методология ARIS (Architecture of Integrated Information Systems – проектирование интегрированных информационных систем) одна из современных методологий бизнес-моделирования, получившая широкое распространение. Ее использует программное средство ARIS Toolset.
Эта методология разработана в компании IDS Scheer AG в Германии. В нее интегрированы существующие стандарты и спецификации описания процессов и данных, в том числе IDEF и DFD. Различные уровни представления и фазы жизненного цикла позволяют упростить описание бизнес-процессов.
При большом количестве используемых для описания, анализа и оптимизации различных аспектов деятельности организации бизнес-моделей (около 100), они объединены в четыре группы:
• группа «Оргструктура» включает модели, с помощью которых описывается организационная структура компании и другие элементы, позволяющие ответить на вопрос «кто отвечает?»;
• группа «Функции» включает модели, используемые для описания стратегических целей компании, функции и элементы функциональной деятельности организации, позволяющие ответить на вопрос «что делают?»;
• группа «Информация» включает модели, с помощью которых описывается информация (потоки и структура), используемая в деятельности организации, позволяющие ответить на вопрос «на основе чего?»;
• группа «Процессы» включает модели, используемые для описания бизнес-процессов, различные взаимосвязей между структурой, функциями и информацией, позволяющие ответить на вопрос «каким образом?».
Система ReTrink, разработана фирмой Gensym (США) и является примером интегрированного подхода к поддержке инжиниринга. При создании системы разработчик ставил своей целью создать удобное средство для реализации различных методологий. В ней объединены возможности ключевых современных информационных технологий: графический объектно-ориентированный язык для описания моделей и проектов, средства анимации и имитационного моделирования реконструируемых процессов, методы искусственного интеллекта для полного и адекватно представления экспертных знаний о процессах. Сочетание прозрачных средств интерактивной графики с возможностями моделирования процессов в реальном времени, что позволяет менеджерам самостоятельно, без помощи программистов, воплощать свои идеи в виде работающих моделей процессов.
Для представления моделей бизнес-процессов используются диаграммы, состоящие из блоков и соединений. Блоки представляют задачи в бизнес-процессах, а соединения – потоки сущностей: документов, информации, а также предметов, фигурирующих в бизнесе (например, запасных частей, или упаковок с отпускаемой продукцией).
В системе реализован ряд стандартных блоков, которые могут быть использованы в качестве сборочных элементов для построения работающих моделей практически любых процессов, например: источник заявок, принятие решения, обработка задания. В случае необходимости пользователь переопределяет поведение блоков или задает новые их классы с помощью встроенных базовых средств.
Все элементы моделей, включая ресурсы процессов, могут модифицироваться непосредственно во время исполнения, результаты изменений можно увидеть сразу же после их введения.
Кроме рассмотренных методологий существуют и другие, предложенные различными компаниями, консалтинговыми фирмами и производителями программных продуктов.
Практика показала, что применение референтных моделей в корпоративных проектах позволяет сократить время и стоимость их реализации более чем на 30%.
Источник: econom-lib.ru
Разработка функциональной модели системы
На фазе анализа строится функциональная модель системы. На основе выделенных требований к системе и анализа предметной области, выделим бизнес-процессы и виды работ, которые выполняются в данной системе.
К основным бизнес-процессам таксопарка относятся: перевозка пассажиров (или обслуживание клиентов), учет клиентов. К вспомогательным – учет кадров, учет материальных средств таксопарка.
Виды работ в таксопарке:
· Оператор принимает вызов у клиента и формирует журнал вызовов.
· Сотрудник выполняет вызов.
· Поставщик снабжает таксопарк мат. Средствами.
· Материальные средства распределяются между ответственными сотрудниками.
· Оператор регистрирует клиента.
· Оператор оформляет прием сотрудника на работу.
· Оператор формирует необходимое досье на клиента.
Построение функциональной модели ИС «Таксопарк» осуществили с помощью методологии IDEF0 с использованием CASE-средства BPwin. Первым шагом в разработке функциональной модели было построение контекстной диаграммы. При этом придерживались основного принципа: структурирование осуществлялось в соответствии с деятельностями и бизнес-процессами предприятия, а не в соответствии с его оргштатной структурой. Это объясняется тем, что для пользователя будущей системы наибольшую ценность представляют именно бизнес-процессы, цель разработки системы заключатся в их улучшении.
Верхний уровень модели отображает только контекст системы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром и ничего более. В контекст входит определение субъекта моделирования, цели и точки зрения на модель (Рис.1.).
Возможно совершенствование данной диаграммы, за счет объединения входных стрелок «работники» и «клиент» в одну, которую можно назвать «человеческий ресурс». Это означает, что кроме обслуживания клиентов разрабатываемая система решает задачу приема работников в штат таксопарка.
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействие с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты, производится построение диаграмм декомпозиции.
Рис. 1. Контекстная диаграмма ИС «Таксопарк»
На диаграмме декомпозиции первого уровня отражены основные деятельности предприятия и их взаимосвязи. Для автотранспортного предприятия одним из решений может быть выделение следующих деятельностей (Рис.2.):
· управление материальными средствами;
Устанавливаем порядок следования деятельностей на диаграмме (определяем доминирующие работы). После связывания граничных и внесения внутренних стрелок создаём новые граничные стрелки выхода «Материальное средство таксопарка» и «Сотрудники» и «Журнал вызовов».
Рис. 2. Диаграмма декомпозиции первого уровня
Такое построение диаграммы декомпозиции соответствует разделению ИС «Таксопарк» на три подсистемы согласно техническому заданию. Каждая из представленных на диаграмме деятельностей, в свою очередь, может быть детализирована. Например, декомпозиция работы «Управление сотрудниками» приводит к созданию диаграммы декомпозиции второго уровня (рис. 3).
Рис. 3. Диаграмма декомпозиции 2 уровня работы «Управление сотрудниками»
Анализ деятельности «Учет кадров» позволяет провести дальнейшую детализацию на бизнес-процессы согласно требованиям к ИС, а именно учет кадров включает в себя – прием на работу, отчет по сотруднику (Рис. 4).
Рис. 4. Диаграмма декомпозиции 3-го уровня работы «Учет кадров»
Также проведена декомпозиция деятельности «Обслуживание клиентов» на бизнес-процессы «регистрация клиента», «формирование вызова» и «проведение вызова» (рис. 5).
Из диаграммы следует, что формирование вызова клиентом будет осуществляться под управлением правил формирования вызова, баланса счета и флага vip-клиента. Если флаг установлен, то у данного клиента существует скидка на услуги, предоставляемые таксопарком. На проведение вызова влияет время вызова (или время заказа) – может возникнуть ситуация, когда вызов от различных клиентов поступает на одного и того же сотрудника на одинаковые, либо пересекающиеся промежутки времени.
Рис. 5. Диаграмма декомпозиции 2-го уровня работы «Обслуживание клиентов»
Декомпозиция работы «Управление мат. средствами» включает в себя «заключение договора на поставку» и «учет сведений о поставщиках» (рис.6). Учет сведений о поставщиках ведется в журнале поставщиков под управлением нормативных правил оформления.
Дальнейшая детализация бизнес-процессов системы осуществляется посредством бизнес-функций. Так, например, процесс «Приём на работу» деятельности «Учет кадров» (см. рис. 4) содержит в себе функции «Приём заявления», «Регистрация» и т. д. Обычно для моделирования бизнес-функций достаточно 2–3 уровней детализации, которая завершается описанием алгоритма.
Рис.6. Диаграмма декомпозиции работы «Управление материальными средствами»
В результате разделения и слияния моделей сформировалось дерево диаграмм проекта (рис. 7).
Рис. 3.7. Дерево диаграмм проекта
Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами (Рис. 8). Работы могут менять свое расположение в дереве узлов многократно. BPwin имеет мощный инструмент навигации по модели — Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде.
Рис. 8. Диаграмма дерева узлов
В результате проектирования, была сформирована полная функциональная модель с глубиной проработки до уровня действий должностного лица структурного подразделения, отображающая функциональную структуру объекта (ИС «Таксопарк»), т.е. производимые им действия и связи между этими действиями.
Источник: lektsia.com
Анализ и моделирование функциональной области внедрения ИС
Организационно- функциональная модель компании строится на основе функциональной схемы деятельности компании рис. 4.12.
Рис. 4.12. Функциональная схема компании
На основании миссии формируются цели и стратегии компании. С их помощью определяется необходимый набор продуктов и, как следствие — требуемые ресурсы. Воспроизводство продукции происходит за счет переработки ресурсов в основном производственном цикле.
Его компоненты формируют необходимые бизнес-функции для поставки ресурсов, производства продуктов и их распределения в места реализации. Для управления указанным процессом воспроизводства формируется совокупность компонентов менеджмента, которая порождает набор функций управления.
Для поддержания процессов воспроизводства и управления формируются наборы соответствующих функций обеспечения (охраны, технического оснащения, профилактики и ремонта и пр.). Такой подход позволяет описать предприятие с помощью универсального множества управленческих регистров (цели, стратегии, продукты, функции, организационные звенья и пр.). Управленческие регистры представляют собой иерархические классификаторы. Объединяя классификаторы в функциональные группы и закрепляя между собой элементы различных классификаторов с помощью матричных проекций, можно получить модель организационной структуры компании.
Для построения организационно- функциональной модели используется всего два типа элементарных моделей.
Древовидные модели (классификаторы) — точные иерархические списки выделенных объектов управления (организационных звеньев, функций, ресурсов, в том числе исполнительных механизмов для бизнес-процессов, документов и их структуры, и т.п.). Каждый элемент классификатора может быть дополнительно охарактеризован рядом атрибутов: тип, шкала , комментарий и т.п. Фактически, классификаторы представляют собой набор управленческих регистров, содержащих, в основном, неколичественную информацию, совокупность которых задает систему координат для описания деятельности компании. Количество таких списков-классификаторов определяется целью построения модели.
Матричные модели — это проекции, задающие систему отношений между классификаторами в любой их комбинации. Связи могут иметь дополнительные атрибуты (направление, название, индекс , шкала и вес ).
В начальной модели применяется всего несколько классификаторов предметной области :
- основные группы продуктов и услуг компании;
- ресурсы, потребляемые компанией в ходе своей деятельности;
- функции (процессы), поддерживаемые в компании;
- организационные звенья компании.
В классификаторе функций обычно выделяют три базовых раздела:
- основные функции — непосредственно связанные с процессом преобразования внешних ресурсов в продукцию и услуги предприятия;
- функции менеджмента — или функции управления предприятием;
- функции обеспечения — поддерживающие производственную, коммерческую и управленческую деятельность.
Главной функцией компании является предоставление продуктов и услуг, поэтому сначала производится формальное описание, согласование и утверждение руководством предприятия перечня его бизнесов (направлений коммерческой деятельности), продукции и услуг. Из этого классификатора внешним контрагентам должно быть понятно, чем предприятие интересно рынку, а для внутренних целей — для чего нужен тот или иной функционал компании .
В результате этих операций производится идентификация функционала и создается единая терминология описания функций предприятия, которая должна быть согласована всеми ведущими менеджерами. При составлении классификатора оргзвеньев важно, чтобы уровень детализации функций соответствовал уровню детализации звеньев. После формирования всех базовых классификаторов с помощью матричных проекций производится их закрепление за оргзвеньями предприятия:
Процесс формирования матрицы проекций функций на оргзвенья на практике напоминает игру в крестики-нолики (рис. 4.10).
Стандартная практика построения моделей организационно- функциональной структуры компаний поддерживает два уровня детализации:
- агрегированную модель;
- детализированную модель.
Агрегированная модель — модель организационной структуры, учетные регистры которой имеют ограничение по степени детализации до 2-3 уровней.
Целью построения данной модели является предоставление информации об организационной структуре высшим руководителям компании для проведения стратегического анализа, анализа соответствия данной структуры стратегии и внешнему окружению компании. Модель может также предоставляться внешним пользователям (например, потенциальным инвесторам как иллюстрация к бизнес-плану, крупным клиентам и др.).
Детализированная модель — модель организационной структуры, детализация учетных регистров которой производится на более глубоких уровнях, чем в агрегированной модели. Степень детализации в модели обусловлена конкретными потребностями компании (создание определенных организационных регламентов).
Целью построения данной модели является предоставление информации о распределении функциональных обязанностей между подразделениями компании, а также об организации бизнес-процессов в компании. Построение детализированной модели позволяет создавать различные внутрифирменные регламенты: Положения об организационной структуре рис. 4.13.
Ниже приведен пример описания фрагментов организационно- функциональной модели производственного предприятия рис. 4.14 и торгового предприятия рис. 4.15. Приведенные матрицы проекций являются основой для выделения бизнес-процессов предприятия и их владельцев на последующих этапах создания ИС.
Источник: intuit.ru