Иерархическая структура базы данных
Это древовидная структура представления информации. Ее особенность в том, что каждый узел на более низком уровне имеет связь только с одним узлом на более высоком уровне. Посмотрим, например, на фрагмент иерархической структуры базы данных "Институт":
Из структуры понятно, что на одной кафедре может работать несколько преподавателей. Такая связь называется "один ко многим" (одна кафедра - много преподавателей). Но если мы попытаемся добавить в эту структуру группы студентов, то нам понадобится связь "многие ко многим":
(один преподаватель может работать со многими группами, а одна группа может учиться у многих преподавателей), а такой связи в иерархической структуре быть не может (т.к. связь может быть только с одним узлом на более высоком уровне). Это основной недостаток подобной структуры базы данных.
Сетевая структура базы данных
По сути, это расширение иерархической структуры. Все то же самое, но существует связь "многие ко многим". Сетевая структура базы данных позволяет нам добавить группы в наш пример. Недостатком сетевой модели является сложность разработки серьезных приложений.
Реляционная структура базы данных
Все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные. Подробно об этом мы будем говорить в следующих уроках, здесь же хочется отметить, что эта структура стала настоящим прорывом в развитии баз данных.
Первая нормальная форма
Таблица находится в первой нормальной форме, если все ее поля имеют простые (атомарные) значения. Само понятие атомарности определить достаточно трудно. Значение, атомарное в одном случае, может быть неатомарным в другом. Общий принцип здесь такой: значение не атомарно, если оно используется по частям. Понятнее будет на примере.
В нашей таблице Поставщики есть поле Адрес. Если наш магазин работает только с поставщиками из одного города, то значения поля Адрес можно считать атомарными, а саму таблицу - приведенной к 1НФ.
Но что если наши поставщики находятся в разных городах? Тогда, посылая машину за товарами в определенный город, мы должны быть уверенны, что она заберет товары у всех поставщиков, находящихся в этом городе. Т.е. нам могут понадобиться сведения о поставщикам, находящихся в определенном городе. В этом случае, значения в поле Адрес уже не являются атомарными (т.к. мы используем часть адреса), и для приведения таблицы к 1НФ нам надо выделить еще одно поле - Город:
Таким образом надо проанализировать все таблицы нашей базы данных. Так, в таблице Покупатель есть поле ФИО. Если мы собираемся, например, поздравлять наших покупателей с именинами (которые, как известно, завися от имени), то это поле пришлось бы разбить на три: Фамилию, Имя и Отчество. Наш магазин этого делать не собирается, поэтому поле ФИО можно считать атомарным, а таблицу - приведенной к 1НФ.
Для запросов нашего магазина все остальные таблицы приведены к 1НФ.
Вторая нормальная форма
Эта форма применяется к таблицам с составными ключами. Таблица, у которой первичный ключ включает только одно поле, всегда находится во 2НФ.
Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, а каждое неключевое поле функционально полно зависит от составного ключа.
В нашей базе данных две таблицы имеют составной ключ - Журнал покупок и Журнал поставок. Значение поля Количество зависит, как от Поставки (Покупки), так и от Товара. Значит, наши таблицы находятся во 2НФ.
Но предположим, что на этапе концептуального моделирования нашей базы данных, мы не выделили объекты Поставка и Покупка. Тогда наши таблицы могли бы выглядеть так:
Посмотрим теперь на таблицу Журнал поставок: поле Количество зависит от Наименования товара и от Даты поставки, но не зависит от того, кто поставил товар (поле Поставщика). Т.е. таблица не находится во 2НФ. Если бы на этапе концептуального моделирования нашей базы данных, мы не выделили объекты Поставка и Покупка, нам бы пришлось это делать сейчас. Но мы их выделили, поэтому все наши таблицы находятся во 2НФ.
Третья нормальная форма
Таблица находится в третьей нормальной форме, если она находится во второй нормальной форме, и каждое неключевое поле нетранзитивно зависит от первичного ключа.
Транзитивная зависимость наблюдается в том случае, если одно из двух неключевых полей зависит от первичного ключа, а другое зависит от первого неключевого поля. На примере будет понятнее.
Посмотрим на нашу таблицу Товар. В ней есть поле Цена, но цены, как известно, имеют свойство меняться. Если мы будем их менять прямо здесь, то будет пропадать вся информация о предыдущих ценах. Чтобы не терять эту информацию, надо добавить поле Дата (когда изменилась цена). Тогда наша таблица будет выглядеть так:
Даже не прибегая к 3НФ видно, что такая таблица будет содержать избыточную информацию. Но посмотрим на ее поля: поля Наименование и Дата зависят от id товара, а поле Цена зависит также и от Даты. Т.е. таблица не находится в 3НФ. Для устранения транзитивной зависимости необходимо провести "расщепление" объекта на два:
Все остальные таблицы нашей базы данных находятся в 3НФ. Кстати, в таблице Товар можно было и не вводить поле id товара, а сделать первичным ключом поле Наименование, но как уже говорилось в третьем уроке суррогатные ключи все-таки предпочтительнее.
Подведем итог. Схема нашей базы данных после нормализации несколько изменилась и выглядит теперь так:
Таким образом, мы преобразовали нашу концептуальную модель в реляционную. Дальше необходимо эту модель реализовать в конкретной СУБД. Для этого нам понадобится сама СУБД и знание языка SQL. Этим вопросам будут посвящены Уроки SQL.
А пока подведем итог уроков "Основы БД". Проектирование БД процесс, как правило, трудоемкий и небыстрый. Ведь нужно очень хорошо изучить предметную область, чтобы учесть все нюансы, пожелания и требования пользователей. Затем всю собранную информацию изобразить в виде объектов, атрибутов и связей. Причем сделать это надо наиболее рационально.
Вообще, среди разработчиков наблюдаются различные взгляды на процесс проектирования БД. Одни игнорируют всякую теорию и руководствуются только своим опытом и здравым смыслом. Другие считают этот процесс искусством, отводя главную роль интуиции. Но в любом случае, знания не бывают лишними. И если вы к интуиции и здравому смыслу добавите теорию, то результат будет гораздо лучше.
Да, база данных - это всего лишь хранилище данных, но от того насколько грамотно вы организуете это хранилище, будет зависеть работа вашего приложения, использующего данные. Помните об этом и не пренебрегайте теорией.
В заключение хотелось бы напомнить, зачем вообще вам нужно уметь проектировать базы данных. Предположим, вы решили организовать у себя на сайте регистрацию пользователей с тем, чтобы обеспечить им доступ к закрытым материалам сайта.
Для реализации этого вопроса вам потребуется создать БД, которая будет хранить информацию о пользователях, их логинах и паролях. А также сделать html-формы регистрации и входа в закрытый раздел.
Когда пользователь регистрируется, эти данные программными средствами (например, с помощью языка PHP) заносятся в созданную вами БД. Когда пользователь вводит логин и пароль в форме входа в закрытый раздел, к базе данных отправляется запрос (на языке SQL), есть ли пользователь с такими данными. И если ответ положительный, то пользователю посылается запрашиваемая страница (разумеется тоже с помощью программы на PHP).
Таким образом, чтобы реализовывать такие приложения вам необходимо уметь создавать БД, строить запросы на языке SQL к БД и знать какой-нибудь язык программирования, применимый для разработки динамических web-страниц (например, PHP).
В принципе, вы можете сначала изучить язык программирования, а потом изучать БД и SQL. Но на этом сайте обучение построено в следующем порядке: БД - SQL - PHP. Сделано это потому, что без баз данных ничего интересного на PHP сделать не удастся. Поэтому до встречи в Уроках SQL.
Перед тем, как переходить к уроках SQL, вам потребуется установить сервер MySQL. В принципе вы можете установить только его, но для полноценной дальнейшей работы вам понадобится интерфейс phpMyAdmin, а для работы с ним - модуль PHP и локальный сервер. Поэтому настоятельно рекомендую установить сразу и сервер Apache, и модуль PHP, и MySQL. К тому же вам все-равно придется их устанавливать, когда вы начнете изучать PHP. Так что идите в раздел Предварительные установки и устанавливайте все по порядку, чтобы больше к этому не возвращаться.
Управление бизнес-процессами или «процессный подход» на сегодняшний день является одной из наиболее востребованных методологий управления компаниями. В статье рассмотрены необходимые понятия, смысл процессного подхода.
Процессный подход – подход к организации и анализу деятельности компании, основанный на выделении и рассмотрении ее бизнес-процессов, каждый из которых протекает во взаимосвязи с другими бизнес-процессами компании или внешней средой. «Правильный» набор бизнес-процессов отдельной компании представляет собой их систему или сеть (рис. 1), которая охватывает процессы производственного цикла компании, а также процессы управления, обеспечения необходимыми ресурсами.
Рис.1 Сеть бизнес-процессов
Подтверждением «прогрессивности» управления бизнес-процессами как подхода к управлению компаниями подтверждается и тем, что необходимость реализации процессного подхода является одним из принципов стандартов ISO 9001. Стандарты ISO 9001, по сути, являются нормативной моделью ведения бизнеса, выработанную деловым сообществом с учетом мирового опыта и закрепленную в международных стандартах на системы менеджмента.
Среди преимуществ процессного подхода можно отметить:
· клиентоориентированность;
· нацеленность на результат;
· гибкость, более оперативное принятие решений, проведение инноваций в связи с изменением внешней среды;
· непрерывность управления;
· возможность построения эффективной системы мотивации, направленной на максимальный учет результатов работы;
· прозрачность за счет описания бизнес-процессов, их разумной формализации.
Ключевым понятием процессного подхода является понятие «бизнес-процесса».
Бизнес-процесс – регулярно повторяющаяся последовательность действий, направленных на получение заданного результата, ценного для организации. Существует достаточно много определений этого термина, сформулированными как известными и авторитетными специалистами, так и международными организациями. Также следует сказать, что понятие «бизнес-процесс» достаточно часто в литературе, статьях, интернет-источниках применяется и в широком смысле как «деятельность в целом».
Основными понятиями процессного подхода являются:
Результат бизнес-процесса – то, ради чего осуществляется бизнес-процесс, т.е. деятельность всегда рассматривается вместе с целью этой деятельности – получение на выходе некоторого результата, удовлетворяющего заданным требованиям. Результаты бизнес-процесса часто упоминаются как выходы бизнес-процесса.
Владелец бизнес-процесса – должностное лицо, несущее ответственность за получение результата процесса и обладающее полномочиями для распоряжения ресурсами, необходимыми для выполнения процесса.
Исполнители бизнес-процесса – команда специалистов из различных функциональных областей (кросс-функциональная команда), выполняющих действия процесса.
Вход бизнес-процесса – ресурсы (материальные, информационные), необходимые для выполнения и получения результата процесса, которые преобразовываются или потребляются при выполнении процесса.
KPI – Key Performance Indicator (ключевой показатель эффективности), они применяются в качестве показателей результативности и/или эффективности бизнес-процессов.
Управление бизнес-процесса (в IDEF0) – управляющие воздействия, регламентирующие выполнение процесса.
Исходя из вышеизложенного определения бизнес-процесса, к основным принципам их выделения можно отнести:
· необходимый результат;
· регулярность действий;
· ценность результата для компании.
Глубина и степень детализации при описании (моделировании) бизнес-процессов определяются в зависимости от конкретных задач, вопросов на которые должно ответить это описание (модель), «проблемностью» и важностью процесса. Наиболее часто описание бизнес-процессов используется для получения ответов на вопросы типа: ЧТО, КТО и КАК должен выполнять в рамках деятельности компании.
Основные способы описания бизнес-процессов изложены в табл. 1.
Таблица 1
| Способ описания бизнес-процессов | Пример* | Достоинства* | Недостатки* |
| Текстовое | Стандарты организации, положения, должностные инструкции и др. | Привычность | Взаимосвязи между бизнес-процессами тяжело отслеживать.Высока вероятность неоднозначного понимания. Затрудненный анализ бизнес-процессов из-за избытка малозначимой информации, Значительные трудозатраты на поддержание документов в актуальном состоянии |
| Табличное | Матрица распределения ответственности | Привычность Однозначность | Небольшое число факторов, параметров, которое можно отразить в таблице |
| Визуальное (графическое) | Организационная структура, блок-схема, технологическая карта и др. | Наглядность Однозначность Разработаны нотации под решения задач различной сложности | Возможно наличие требований к квалификации |
| Визуальное (графическое) с помощью специализированного программного продукта – системы бизнес-моделирования, case-средства | Сеть бизнес-процессов, Информационные модели для решения различных задач и т.д. | Возможность комбинированного использования всех предыдущих способов описания бизнес-процессов Возможности коллективной работы Поддержка различных нотаций, автоматическая проверка синтаксиса и др. | Приобретение программного продукта Возможно наличие требований к квалификации |
| Примечание: * - Список примеров, достоинств и недостатков является далеко не исчерпывающим и приведен лишь в качестве общей обзорной информации. | |||
На выбор способа описания бизнес-процессов оказывают влияние такие факторы как:
· задачи, которые компания желает решить, внедряя процессный подход;
· размер и вид деятельности компании;
· сложность бизнес-процессов и их взаимодействия, риски бизнеса;
· квалификация персонала;
· устоявшаяся практика и др.
Оценка функционирования, «качества протекания» бизнес-процесса осуществляется на основании мониторинга и анализа показателей его результативности и/или эффективности, выявленных несоответствий. При управлении бизнес-процессом, его улучшением целесообразно применять цикл PDCA. Применение цикла PDCA для каждого отдельного процесса характеризуется следующим набором действий:
| Этап | Действия |
|
| Планируй (Plan): | Определяй цели (показатели) процесса и процедуры работы, выполнение которых участниками приведет к достижению его целей | |
| Делай (Do): | Доведи до участников процесса цели (показатели) и процедуры работы, обеспечь соблюдение процедур работы участниками | |
| Проверяй (Check): | Контролируй показатели, соблюдение процедур работы участниками - анализируй выявленные несоответствия | |
| Действуй (Action): | Улучшай процесс посредством применения результатов его анализа, устранения причин несоответствий |
Определение (назначение) целей бизнес-процессов производится с учетом стратегии компании. Ключевые показатели эффективности KPI, характеризующие степень достижения стратегических целей целесообразно использовать в качестве показателей результативности и эффективности бизнес-процессов. При выборе показателей необходимо учитывать:
· их соответствие целям;
· возможность и «легкость» контроля.
Эффективное улучшение бизнес-процессов с применением цикла PDCA на постоянной основе возможно лишь в случае наличия заинтересованности участников процесса в его непрерывном совершенствовании. Наилучшим способом задействовать потенциал участников как «движущей силы улучшения» будет учет достижения-недостижения целей бизнес-процесса (показателей KPI) в системе мотивации персонала.
Использовав вышеописанный подход можно «убить нескольких зайцев»:
· во-первых: стратегия, цели компании не «повисают» в воздухе, поскольку они увязаны с текущей деятельностью компании через бизнес-процессы;
· во-вторых: появляется возможность для построения по настоящему эффективной системы мотивации, основанной на учете конкретного результата, достижения показателя KPI.
Управление бизнес-процессами как подход к управлению компанией предусматривает то, что необходимо как совершенствование отдельного процесса в частности, так и системы (сети) процессов в целом. Мировая практика показывает, что система управления, построенная на принципах процессного подхода, является более эффективной и результативной по сравнению с равной ей по масштабу функциональной системой.
КРАТКОЕ ОПИСАНИЕ BPMN С ПРИМЕРОМ
О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» - что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.
Также я хочу сразу обратить ваше внимание на то, что здесь я буду говорить именно о нотации BPMN, т.е. о языке моделирования бизнес-процессов. Я, конечно, постараюсь максимально просто описать основы BPMN так, чтобы они были понятны даже новичкам. Но также важно понимать, что здесь я буду говорить именно о языке, а не о методологии.
Методология моделирования бизнес-процессов - это понятие очень обширное, по сути, это та самая база, знания которой нужны для практического применения языков моделирования бизнес-процессов. О ней я буду говорить в будущих статьях и не раз. Почему я делаю на этом акцент? Многие люди (и я в свое время также) считают, что достаточно выучить язык бизнес-моделирования, и вы сумеете выстраивать бизнес-процессы.
Практика показывает, что без базовых знаний здесь не обойтись. И всем, кто только планирует изучение моделирования, я настоятельно советую сначала ознакомиться с методологией, понять общие принципы бизнес-моделирования, получить определенные навыки бизнес-анализа. И только потом приступать к изучению BPMN или любого другого языка.
А для понимания причин появления BPMN и всех нюансов моделирования при помощи этой системы нотаций, понадобится также знание основных проблем, которые решает BPMN, что для работы использовали до появления BPMN, и с какими сложностями сталкивались. Ведь появление новых систем и нотаций невозможно без понимания определенной проблематики. И я считаю, что этот аспект очень важен для понимания сути вопроса, что же такое на самом деле BPMN.
Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.
В то время Bizagi был относительно простым модулем, в котором присутствовал удобный редактор для моделирования (рисования) бизнес процессов, но еще не было никаких инструментов для исполнения бизнес-процессов. Но даже тогда строгие правила BPMN, принятые в системе Bizagi, помогали избегать значительного числа ошибок, столь частых при обычном «рисовании» бизнес-процессов в графических редакторах или на бумаге.
В поисках оптимального решения для себя я изучал ARIS, инструменты 1С для бизнес-моделирования, различные системы моделирования бизнес-процессов, которые были придуманы различными бизнес-консультантами, как российскими, так и зарубежными. И, конечно же, познакомился с нотацией BPMN.
При первом знакомстве BPMN мне во многом понравился, идея была очень хорошей, а вот исполнение на тот момент с моей точки зрения еще было «сырым». И полноценно пользоваться BPMN я начал около 3 лет назад, после того, как задачи, которые я стал решать, усложнились настолько, что IDEF0 применять полноценно никак не получалось. И оказалось, что нотация развивалась, и теперь я активно пользуюсь BPMN в своей работе.
BPM: ОСНОВНЫЕ ПОНЯТИЯ
Для того чтобы разобраться, что такое BPMN , нужно понимать, что часть этой аббревиатуры «BPM» имеет две расшифровки - Business Process Modeling и Business Process Management. В первом случае – это непосредственно моделирование бизнес процесса, а во втором – управление бизнес-процессами, т.е. общая система, частью которой и является Business Process Modeling.
При этом моделирование бизнес-процессов – является основой и основной целью. При помощи моделирования мы можем описать любой бизнес процесс, а исполняться они могут в самых разных системах управления.
Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.
Можно сказать, что BPMN является частью двух важнейших составляющих:
· BPM (Business Process Modeling) – это та среда, где вы занимаетесь непосредственно моделированием. Самостоятельно или в команде.
· BPMS (Business Process Modeling System) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Comundo,ELMA и пр.
Итак, основные понятия у нас есть. Подробнее о BPM я планирую поговорить в следующих статьях.
НЕМНОГО ИСТОРИИ BPMN
Для большего понимания особенностей моделирования бизнес-процессов и структуры языка моделирования, я хочу немного рассказать об истории появления нотации BPMN. Разработка системы моделирования бизнес-процессов и спецификаций для нее (языка моделирования) ведется относительно давно.
Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative. Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.
Следующая версия BPMN 1.1 выходит в январе 2008, и здесь разработкой и поддержкой занималась уже Object Management Group, организация, появившаяся в результате слияния BPMI с другой компанией-разработчиком программного обеспечения.
Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.
В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.
Из истории можно сделать вывод что период изменений в этом языке миновал,и можно спокойно изучать и использовать его на практике.
Сегодня BPMN – это один из наиболее распространенных методов описания бизнес-процессов, которые сегодня уже «понимают» как бизнес-пользователи, так и программные продукты, предназначенные для работы с бизнес-моделями. Т.е. этот язык описания является стандартным также и для создания исполняемых алгоритмов в сфере управления бизнесом.
Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия BPMN действительно стабильна и все требования к языку обоснованы.
EVENT (СОБЫТИЕ)
Event – это то событие, которое произошло в описании процесса или хореографии (о ней я расскажу отдельно). Эти события могут быть начальными, конечными или промежуточными.
Например, опишем процесс получения заказа от клиента по телефону:
· Событие Старт – это входящий звонок от клиента.
· Событие Финиш – это отправка готового расходного документа на печать.
Конечными могут быть самые разные события. Здесь и запись перечня потребностей клиента, и сохранение документа заказа, и создание на его основе расходной накладной, налоговой и т.д.
ACTIVITY (ДЕЙСТВИЯ)
Activity – это те действия (задачи), которые должны быть выполнены на определенном этапе бизнес-процесса. Их при моделировании обычно обозначают в виде прямоугольников, в которые вписывают суть действия.
Действия могут быть элементарными, т.е. неделимыми на какие-то более простые действия, так и не элементарными, т.е. такими, которые при детализации делятся на последовательность определенных более простых действий.
Обычно действия делят следующим образом:
· Процесс – крупное действие, которое требует дальнейшей детализации при моделировании.
· Задача – элементарное действие, которое уже не может быть дальше детализировано.
GATEWAY (ШЛЮЗ, РАЗВИЛКА)
Gateway – это контрольный узел, который появляется в случае условного ветвления бизнес-процесса. Графически изображается в виде ромба.
Также шлюзы необходимы в случаях, когда порядок действий зависит от тех или иных факторов. Например, при работе с заказчиками шлюз появляется на этапе принятия клиентом решения о покупке – «да или нет». При положительном решении необходимо оформить покупку, при отрицательном – выяснить возможные причины отказа, провести работу с «отказом» и т.д.
POOL (ПУЛ)
Пул – это объект описывающий какой-то один процесс на диаграмме. Он может быть не изображен на диаграмме, но он всегда есть. На одной диаграмме может быть несколько Пулов. Пул можно развернуть для просмотра деталей.
Пул может также содержать, так называемые, «дорожки». Они нужны для того, чтобы указать участников процессов, которые скрыты в пуле. Например, в процессе работы с клиентами участвует менеджер по продажам, руководитель отдела продаж, возможно, бухгалтер или кассир.
MESSAGE (СООБЩЕНИЕ)
Этот элемент необходим, чтобы показать коммуникацию между двумя участниками процесса. Это может быть Email, сообщения внутри системы совместной работы, переписка в каком-либо из мессенджеров, которыми пользуются участники процесса, коммуникации на сайте компании, sms-сообщения и т.д.
ARTEFACT (АРТЕФАКТЫ)
Под артефактами в BPMN понимают объекты, не являющиеся действиями и не связанные с действиями напрямую. Это могут быть любые документы, данные, информация, которая не влияет напрямую на исполнение процесса.
Выделяют два вида артефактов:
· Object Group (Группа объектов)
· Text Annotation (Текстовая аннотация)
Object Group (Группа объектов) – это еще одна возможность объединить под общим символом несколько элементов, чтобы сэкономить место на диаграмме и повысить простоту ее восприятия. Здесь собираются различные активности под одним общим названием. Группу объектов также всегда можно рассмотреть детально. Группа выглядит как прямоугольник с закругленными углами, выполненный штриховой линией с точками.
Text Annotation (текстовые аннотации) применяют для различных уточнений к диаграмме. Это могут быть комментарии, пояснения, другая информация, которая повысит читабельность диаграммы. Аннотации – это незакрытый прямоугольник, выполненный сплошной линией, от которого к объекту аннотации ведет линия, состоящая из точек.
Что такое IDEF0?
IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ).
Википедия
Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.
Пример создания функциональной модели IDEF0
Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи.
Основной блок – «Написать статью».
Пример описания функциональной модели верхнего уровня
Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.
Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».
А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создает аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создает на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи. Корректор проверяет материал на ошибки. А программное обеспечение – это те инструменты, которые используют в работе все участники процесса.
Таким образом, я задал основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом.
На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать. Для этого я декомпозирую общий блок «написать статью» на связанные между собой элементы.
В нашем случае работа делится на 4 основных этапа:
1. Подготовить аудио.
2. Подготовить текст
3. Подготовить текст к публикации.
4. Разместить статью в издании.
Пример описания функциональной модели бизнес процесса второго уровня
На схеме наглядно видно, на каком этапе какие управляющие элементы и какие механизмы задействованы.
Так, автор при создании аудио использует свои знания и опыт, при этом руководствуется планом публикации и требованиями издателя. Копирайтер получает на входе аудиозапись, из которой, руководствуясь правилами русского языка, создает текст. Корректор получает текст и проверяет его, также руководствуясь правилами русского языка. Для размещения статьи в издании необходимо специальное программное обеспечение.
При создании функциональной модели ключевыми параметрами являются цель и точка зрения. Исходя из них, моделирование одних и тех же процессов может выглядеть несколько по-разному. Например, в моем случае целью является «рассказать о процессе написания статьи». А точка зрения копирайтера – это «написание и публикация статьи с точки зрения руководителя процесса».
Так, если бы тот же процесс был описан с точки зрения копирайтера, то входящими были бы опыт и аудиофайл от автора. При этом в таком случае под Опытом подразумевался бы опыт копирайтера, но не руководителя или автора. А потому первое, что нужно определить при создании модели бизнес-процесса – это выбрать точку зрения и четко сформулировать цель.
Такое моделирование не только наглядно, но и очень удобно для принятия эффективных управленческих решений. Например, в описанном выше бизнес-процессе есть два отдельных специалиста — копирайтер и корректор. Если я поставлю задачу оптимизировать финансирование проекта, то я благодаря схеме сразу увижу, где это и как можно сделать. Так, к копирайтер и корректор пользуются примерно одинаковыми правилами, но копирайтер получает аудио, а выдает результат в виде текста, корректор же и принимает, и отдает текст. А потому при необходимости я могу, скажем, за половину стоимости обязанности корректора предложить копирайтеру. Так я сэкономлю средства и время на взаимодействие разных специалистов. Конечно, я понимаю все заслуги корректоров и почему лучше работать с отдельным специалистам. Но напоминаю — у меня стоит задача: оптимизация затрат.
Без такого наглядного инструмента было бы сложнее определить, какие из блоков можно удалить и, таким образом, оптимизировать работу.
Как создавать нотации IDEF0
Существует множество различных программных продуктов, которые можно применять при создании нотаций. Какие-то созданы специально для функционального моделирования, другие предназначены для любой работы с графическими элементами. Где и как вы будете строить эти модели – решать вам.
Я лично считаю, что на первом этапе нет ничего лучше, чем обычная бумага, простой карандаш и ластик, чтобы вносить корректировки в случае ошибок.
Для того чтобы создать нотацию существующих бизнес-процессов, т.е. описать, как сейчас работает компания, необходимо принципы работы изучить. Сторонний специалист (консультант, разработчик) для этого проводит интервью. На первом этапе на вопросы отвечает руководитель компании, далее в процессе детализации нотации проводятся интервью сотрудников, отвечающих за различные этапы работы.
При этом важно понимать, что в результате потребуется 2 нотации. Первая будет отображать бизнес-процессы в виде «как есть». Ее вы создаете на основе интервью и согласовываете каждую детализацию с сотрудниками компании и руководителем. Очень важно, чтобы ваше видение существующих процессов совпало с реальностью, именно для этого и требуется подтверждение на всех уровнях.
Вторая нотация – «как должно быть». Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи.
Требования стандарта IDEF0
Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.
1. В левом верхнем углу всегда – главный элемент.
2. Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
3. Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
4. Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
5. Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.
Стандарт IDEF0 включает в себя также общепринятые обозначения, правила, требования к блокам диаграмм, имеет собственную семантику. Подробно ознакомиться с ними можно в документе «Методология функционального моделирования IDEF0».
Типичные ошибки
Функциональное моделирование выполняют при помощи самых разных инструментов, в том числе, не предназначенных для моделирования. В последнем случае нет проверки на ошибки и ограничения стандарта. Желание повысить наглядность и отсутствие опыта при этом часто оканчиваются ошибками.
Выгоды использования IDEF0
· Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
· Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
· Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
· Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.
Иерархическая структура базы данных
Это древовидная структура представления информации. Ее особенность в том, что каждый узел на более низком уровне имеет связь только с одним узлом на более высоком уровне. Посмотрим, например, на фрагмент иерархической структуры базы данных "Институт":
Из структуры понятно, что на одной кафедре может работать несколько преподавателей. Такая связь называется "один ко многим" (одна кафедра - много преподавателей). Но если мы попытаемся добавить в эту структуру группы студентов, то нам понадобится связь "многие ко многим":
(один преподаватель может работать со многими группами, а одна группа может учиться у многих преподавателей), а такой связи в иерархической структуре быть не может (т.к. связь может быть только с одним узлом на более высоком уровне). Это основной недостаток подобной структуры базы данных.
Дата: 2019-02-02, просмотров: 274.
