книги / Структурные модели бизнеса DFD-технологии
..pdfСущность представляет собой множество экземпляров реальных или аб страктных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект си стемы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отра жать тип или класс объекта, а не его конкретный экземпляр (например, А ЭРОПОРТ, а не ВНУКОВО).
Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Фактически отношение является ассоциацией между сущно стями, при которой каждый экземпляр одной сущности ассоциируется с произ вольным (в том числе и нулевым) количеством экземпляров другой сущности, и наоборот. Именование отношения осуществляется с помощью грамматическо го оборота глагола {ИМЕЕТ, ОПРЕДЕЛЯЕТ, М ОЖ ЕТ ВЛАДЕТЬ и т.п.).
Другими словами, сущности представляют собой базовые типы инфор мации, необходимые системе, а отношения показывают, как эти типы дан ных взаимоувязаны друг с другом.
Для идентификации-требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Каждая связь соединяет сущ ность и отношение и может быть направлена только от отношения к сущно сти. Значение связи характеризует ее тип и, как правило, выбирается из сле дующего множества: {«О или 1», «О или более», «1», «1 или более», «p:q» ( диа пазон )} . П ара значений связей, принадлеж ащ их одному и том у же отношению, определяет тип этого отношения. Практика показала, что для моделирования большинства систем достаточно использовать следующие типы отношений:
1) 1*1 (один-к-одному). Отношения данного типа используются, как пра вило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко;
2)1 *п (один-ко-многим). Отношения данного типа являются наиболее часто используемыми;
3)п*т (многие-ко-многим). Отношения данного типа обычно использу ются на ранних этапах моделирования с целью прояснения ситуации. В даль нейшем каждое из таких отношений должно быть преобразовано в комбина цию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущ ностей и с введением новых отношений).
Сущность на ERD представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак «#» перед именем атрибута).
Отношения представляются линиями, соединяющими сущности и состо ящими из двух частей (соответствующих паре связей), для которых должны быть определены имя, степень множественности (один или много объектов участвуют в связи) и степень обязательности (т.е. обязательная или необяза тельная связь между сущностями). Для множественной связи линия присое диняется к прямоугольнику сущности в трех точках, а для одиночной связи -
водной точке. При обязательной связи рисуется непрерывная линия до сере дины отношения, при необязательной - пунктирная линия. Вышесказанное иллюстрируется на рис. 1.8.
0-1
Принадлежать |
Кредитная |
карта |
|
Клиент |
|
\ |
#Номер счета |
Владеть |
|
|
Лимит денег |
|
Код сортировки |
Рис. 1.8. Символы ERD
Читается отношение отдельно по каждой связи, демонстрируя, как сущ ность К Л И ЕН Т связывается с сущностью КРЕДИТНАЯ КАРТА, и наоборот. При этом необходимо учитывать степень обязательности выбранного конца связи, для этой цели используются слова «должен (быть)» или «может (быть)». Так, диаграмма, приведенная на рис. 1.7, читается следующим образом:
Каждый КЛИЕНТможет ВЛАДЕТЬ одной или более КРЕДИТНОЙ КАРТОЙ
или Каждая КРЕДИТНАЯ КАРТА должна ПРИНАДЛЕЖАТЬ ровно одному
КЛИЕНТУ.
Основные преимущества DFD-технологий
Наиболее существенное различие между разновидностями структурного анализа заключается в методах и средствах функционального моделирования. С этой точки зрения все разновидности структурного сис темного анализа могут быть разбиты на две группы: применяющие методы и технологию D FD (в различных нотациях) и использующие SADT-методоло- гию. Соотношение применения этих двух разновидностей структурного ана лиза на практике составляет, по материалам наиболее авторитетной в рас сматриваемой области консалтинговой компании CASE Consulting Group, 90% для D FD и 10% - для SADT.
Предварим сравнение рис. 1.9, представляющим SADT - модель компа нии, занимающейся распределением товаров по заказам. Напомним, что ее D FD -эквивалент приведен на рис. 1.5. Простое визуальное сравнение этих рисунков на предмет их понятности для непосвященного читателя свидетель ствует в пользу DFD.
Сравнительный анализ этих двух разновидностей методологий проводит ся по следующим параметрам:
•адекватность средств рассматриваемой проблеме;
•согласованность с другими средствами структурного анализа;
•интеграция с последующими этапами (в частности, с этапом автомати зации бизнес-процесса).
Рис. 1.9. Пример SADT-диаграммы
1. Адекватность. Выбор той или иной структурной методологии напр мую зависит от предметной области, для которой создается модель. Предме том бизнес-консалтинга являются бизнес-системы (точнее, их функциониро вание). Для моделирования таких систем традиционно используется методо логия SADT. Однако статическая SADT-модель не обеспечивает полного решения задач бизнес-консалтинга, необходимо иметь возможность иссле дования динамических характеристик бизнес-процессов. Одним из решений является использование методологии и средств динамического моделирова ния, основанной, например, на цветных (раскрашенных) сетях Петри - CPN (Color Petri Nets). Фактически SADT и CPN служат компонентами интегри рованной методологии бизнес-консалтинга: SADT-диаграммы автоматически преобразуются в прообраз CPN-модели, которая затем дорабатывается и исполняется в различных режимах, чтобы получить соответствующие оценки.
Следует отметить, что не существует принципиальных ограничений в ис пользовании DFD в качестве средства построения статических моделей биз нес-процессов. В настоящий момент доступен ряд методологий и продуктов динамического моделирования (INCOME Mobile, CPN-AMI и др.), базиру ющихся на сетях Петри различного вида и интегрируемых с D FD -моделыо, которые позволяют успешно решать задачи бизнес-консалтинга.
Методология SADT успешно работает только для реорганизации хоро шо специфицированных и стандартизованных западных бизнес-процессов, поэтому она и принята на Западе в качестве типовой. Например, в Мини стерстве обороны США десятки лет существуют четкие должностные инст рукции и методики, которые жестко регламентируют деятельность, делают ее высокотехнологичной и ориентированной на бизнес-процесс. В россий ской действительности с ее слабой типизацией бизнес-процессов, их стихий ным появлением и развитием разумнее ориентироваться на методологию организации и (или) реорганизации потоков информации и отношений: для таких задач методологии, основанные на потоковых диаграммах, не просто допустимы, а являются единственно возможными.
Если же речь идет об информационно-технологическом консалтинге, где методологии применяются к системам обработки информации, а не к систе мам вообще, как это предполагается в SADT, то здесь D FD вне конкурен ции. Практически любой класс систем успешно моделируется при помощи D FD -ориентированных методов: в этом случае вместо реальных объектов рассматриваются отношения, описывающие свойства этих объектов и пра вила их поведения. Примерами таких систем служат системы документообо рота, управления и другие системы, богатые разнообразными отношениями.
SADT-диаграммы значительно менее выразительны и удобны для моде лирования систем обработки информации (сравните рис. 1.5 и 1.8). Так, дуги в SADT жестко типизированы (вход, выход, управление, исполнитель). В то же время применительно к системам обработки информации стирается смыс ловое различие между входами-выходами, с одной стороны, и управлениями и механизмами - с другой: входы, выходы и управления являются потоками данных и(или) управления и правилами их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является бо лее прозрачным и недвусмысленным.
ол
В SADT вообще отсутствуют выразительные средства для моделирова ния особенностей систем обработки информации. D FD с самого начала со здавались как средство проектирования информационных систем (тогда как SADT - как средство проектирования систем вообще) и имеют более бога тый набор элементов, адекватно отражающих специфику таких систем (на пример, накопители данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с вне шним миром).
Наличие мини-спецификаций D FD -процессов нижнего уровня позволя ет преодолеть логическую незавершенность SADT (а именно обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и построить полную функциональную специфи кацию разрабатываемой системы. Это позволит расширить возможности применения созданной модели (например, ее можно будет использовать для автоматизированного и быстрого обучения новых работников конкретному направлению деятельности).
Жесткие ограничения SADT, без исключений запрещающие использовать более 6-7 блоков на диаграмме, в ряде случаев вынуждают искусственно де тализировать процесс, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и, как следствие, ведет к неадекватности модели реаль ной картине. В качестве примера достаточно рассмотреть модель операции по снятию денег с вклада физического лица в банке. В настоящий момент существует более тридцати типов таких вкладов. Для моделирования соот ветствующих операций целесообразно использовать единственную D FD , поскольку все без исключения операции имеют одни и те же входы (сберега тельная книжка и расходный ордер) и выходы (сберегательная книжка и на личные деньги) и различаются лишь механизмами начисления процентов. Если мы будем пытаться структурировать эти операции путем группирова ния по какому-либо признаку (срочные, пенсионные, размеры процентов и т.п.) в соответствии с ограничениями SADT, то получим, как минимум, 6 диаграмм (верхний уровень и округленную в большую сторону дробь 30/7), сложность каждой из которых не меньше сложности единственной диаграм мы, моделирующей все операции.
2. Согласованность. Главным достоинством любых моделей является воз можность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами моделиро вания данных и поведения системы. Согласование SADT-модели с ERD и STD практически невозможно или носит тривиальный характер. В свою оче редь, DFD, ERD и STD взаимно дополняют друг друга и, по сути, являются согласованными представлениями различных аспектов одной и той же моде ли (см. рис. 1.1).
Отметим, что интеграция DFD - STD осуществляется за счет расширения классической D FD специальными средствами моделирования поведенческих аспектов систем (управляющими процессами, потоками), и STD является де тализацией управляющего процесса, согласованной по управляющим пото кам. Интеграция D FD - ERD осуществляется с использованием отсутствую щего в SADT объекта - накопителя данных, структура которого описывает
2 5
ся с помощью ERD и согласуется по соответствующим потокам и другим накопителям на DFD.
3. Интеграция с последующими этапами. Важная характеристика методо логии - ее совместимость с последующими этапами применения результатов моделирования (и прежде всего с этапами автоматизации бизнес-процесса, опирающимися на результаты его моделирования).
DFD могут быть легко преобразованы в модели проектирования инфор мационной системы (структурные карты) - это близкие модели. Более того, известен ряд алгоритмов автоматического преобразования иерархии DFD в структурные карты различных видов, что обеспечивает логичный и безбо лезненный переход от этапа моделирования бизнеса к проектированию сис темы. С другой стороны, авторам неизвестны формальные методы преобра зования SADT-диаграмм в проектные решения системы автоматизации.
В заключение необходимо отметить, что рассмотренные разновидности структурного анализа по сути - два приблизительно одинаковых по мощно сти языка для передачи понимания. И одним из основных критериев выбора является следующий: насколько хорошо каждым из этих языков владеет кон сультант или аналитик, насколько грамотно он может на этом языке выра жать свои мысли. Авторам неоднократно приходилось рецензировать как изумительные по стройности и строгости SADT-модели, так и ни на что не годные модели, выполненные в D FD -технологии.
ГЛАВА
Основы структуризации 2 бизнеса
2Процессный подход и типизация бизнес-процессов
Современное состояние экономики характеризуется перехо дом от традиционной функциональной индустриальной модели Адама Смита к модели процессной. Функциональная модель строится на предпосылке, что работники обладают невысокой квалификацией, поэтому предлагаемые им задачи должны быть очень простыми. Адам Смит доказывал, что люди ра ботают наиболее эффективно тогда, когда им предлагается для выполнения всего одна хорошо понятная им работа. Отсюда и следуют основные прави ла игры: иерархические организационные структуры, конвейерные техноло гии, управление по структурным элементам (подразделениям), взаимодей ствие через структурные элементы более высокого уровня и т.п.
Главными недостатками функционального подхода являются следующие:
•сложность увязывания простейших задач в технологию, производящую реальный товар или услугу;
•отсутствие целостного описания такой технологии;
•отсутствие ответственного за конечный результат;
•высокие затраты на бесполезную работу: согласование, взаимодействие, контроль и т.п.;
•отсутствие ориентации на клиента.
Процессный подход декларирует смещение акцентов от управления от дельными структурными элементами на управление сквозными бизнес-про цессами, связывающими воедино деятельность этих структурных элементов. При этом под бизнес-процессом понимается совокупность действий, проду цирующая результат (товар или услугу), имеющий ценность для клиента.
Важнейшим шагом структуризации любой бизнес-системы являются вы деление и классификация бизнес-процессов. Целесообразно основываться на следующих классах процессов:
•основные процессы;
•сопутствующие процессы;
•вспомогательные процессы;
•обеспечивающие процессы;
•процессы управления,
•процессы развития.
0*7
Основными бизнес-процессами являются процессы, ориентированные на производство товара или оказание услуги, являющиеся целевыми объектами создания предприятия и обеспечивающие получение дохода. Например, для жирового комбината такими процессами являются процесс производства масла и процесс производства майонеза, а для автотранспортного предприя тия - процесс обеспечения перевозок (оказания услуг по перевозкам).
Сопутствующими бизнес-процессами являются процессы, ориентирован ные на производство товара или оказание услуги, являющиеся результатами сопутствующей основному производству производственной деятельности предприятия и также обеспечивающие получение дохода. Например, для жирового комбината такими процессами являются процесс производства мыла и процесс производства глицерина.
Вспомогательными бизнес-процессами являются процессы, предназначен ные для жизнеобеспечения основных и сопутствующих процессов и ориенти рованные на поддержку их специфических черт. Так, для автотранспортного предприятия такими процессами являются процесс ремонта и технического обслуживания транспорта и процесс обеспечения безопасности перевозок.
Обеспечивающими бизнес-процессами являются процессы, предназначен ные для жизнеобеспечения основных и сопутствующих процессов и ориен тированные на поддержку их универсальных черт. Так, для любого предприя тия такими процессами являются процесс финансового обеспечения деятель ности, процесс обеспечения кадрами, процесс юридического обеспечения и т.п.
Бизнес-процессы управления - это процессы, охватывающие весь комп лекс функций управления на уровне каждого бизнес-процесса и бизнес-сис темы в целом. Примерами таких процессов могут быть процессы стратеги ческого, оперативного и текущего планирования, процессы формирования и выполнения управляющих воздействий.
Наконец, бизнес-процессами развития являются процессы совершенство вания производимого товара или услуги, процессы развития технологий, процессы модификации оборудования, а также инновационные процессы.
Принципы структуризации бизнес-системы
Основной принцип процессного подхода регламентирует структурирование бизнес-системы в соответствии с деятельностью и бизнеспроцессами предприятия, а не в соответствии с его организационно-штатной структурой. Именно бизнес-процессы, продуцирующе значимый для потре бителя результат, представляют для него (а значит, и для предприятия-про изводителя) ценность, и именно их улучшением предстоит в дальнейшем за ниматься консультанту. Модель, основанная на организационно-штатной структуре, может продемонстрировать лишь хаос, царящий в организации (о котором в принципе руководству и так известно, иначе оно бы не иници ировало соответствующие работы), на ее основе возможно внести предложе-
оя
ния только об изменении этой структуры. С другой стороны, модель, осно ванная на бизнес-процессах, содержит в себе (не всегда в явном виде) и орга низационно-штатную структуру предприятия.
В соответствии с вышесказанным модель бизнес-системы должна выгля деть следующим образом.
1. Верхний уровень модели должен отражать только контекст системы - взаимодействие моделируемого единственным контекстным процессом пред приятия с внешним миром и ничего более. В случае построения модели биз нес-системы, включающей в себя несколько разнотипных предприятий, на контекстном уровне необходимо отразить каждое из них и их соответствую щие взаимосвязи. Например, контекстная диаграмма горно-обогатительно го комбината может содержать процессы Автобаза, Карьер, Фабрика и Уп равление (см. главу 3); контекстная диаграмма регионального банка Сбер банка РФ может содержать процессы Территориальное Управление, Типовое Отделение, Типовой Филиал.
2.На втором уровне модели должны быть отражены основные деятель ности (тематически сгруппированные бизнес-процессы) предприятия и их взаимосвязи. Например, для автотранспортного предприятия одним из ре шений может быть выделение следующих деятельностей: Эксплуатация ав тотранспорта (группа основных процессов), Ремонт и техническое обслу живание (группа вспомогательных процессов), Контроль безопасности (еще одна группа вспомогательных процессов), Управление производством (груп па процессов управления), Обеспечивающая деятельность (группа обеспечи вающих процессов). В случае большого количества деятельностей некото рые из них можно вынести на третий уровень модели. Так, Обеспечивающая деятельность может включать в себя Учет кадров, Бухгалтерский учет, Эко номическое планирование, Материально-техническое снабжение, Складской учет и т.п. Но в любом случае под деятельности необходимо отводить не более двух уровней модели.
3.Каждая из деятельностей, в свою очередь, должна быть детализирова на на бизнес-процессы (желательно единственного уровня). Например, дея тельность по учету кадров включает в себя бизнес-процессы Прием на рабо ту, Увольнение и т.п.
4.Дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций. Так, процесс Прием наработу содержит в себе функции Прием заявления, Оформление приказа, Регистрация и др. Обычно для моделирова ния бизнес-функции достаточно 2-3 уровней детализации, которая заверша ется на уровне элементарной бизнес-операции.
5.Описание элементарной бизнес-операции (задание алгоритма ее выпол нения) осуществляется с помощью мини-спецификации.
Таким образом, общее число уровней в модели не должно превышать 6-7. Практика показывает, что этого вполне достаточно для построения пол ной функциональной модели современного предприятия любой отрасли.
Структурирование данных во многом базируется на накопителях данных: многие процессы модели связываются не напрямую, а с использованием этих объектов (что реально соответствует чтению/записи информации из/в базу данных, выбору/занесению данных из/в архивы, картотеки, папки и т.п.). При
этом операции типа записи-занесения должны удовлетворять главному кри терию информационного моделирования: данные должны заноситься в на копитель один раз в том месте, где они впервые появляются.
Основное правило введения накопителей данных заключается в следую щем: если данные из некоторого накопителя используются по крайней мере двумя процессами, то этот накопитель должен присутствовать на содержа щей эти процессы диаграмме. Поэтому на втором уровне модели (детализа ции контекстной диаграммы) должны быть введены базовые накопители, к которым осуществляют доступ бизнес-процессы системы. При построении информационной модели базовым накопителям должны соответствовать основные подсхемы информационной модели. К выявлению базовых нако пителей следует подходить чрезвычайно тщательно, поскольку именно с ними будут работать бизнес-процессы и бизнес-функции на всех без исключения уровнях детализации модели.
2 .3 . |
Этапы построения моделей |
|
в DFD-технологии |
||
|
Ниже перечислены основные виды и последовательность работ, рекомендуемые при построении моделей бизнес-систем.
I. Разработка структурной функциональной модели бизнес-системы. Шаг 1. Разработка контекстной диаграммы.
1.1.Идентификация внешних объектов, с которыми система взаимодей
ствует.
1.2.Идентификация основных видов информации, циркулирующей меж
ду системой и внешними объектами.
1.3.Идентификация подсистем бизнес-системы (если в этом есть необхо димость).
1.4.Идентификация основных видов информации, циркулирующей меж ду подсистемами (в случае выполнения п.1.3).
1.5.Построение контекстной диаграммы, на которой подсистемы пред ставляются в виде контекстных процессов, внешние объекты - в виде вне шних сущностей, основные виды информации - в виде потоков между вне шними сущностями и контекстными процессами (а также между контекст ными процессами в случае выполнения п.1.3).
1.6.Группирование потоков (если в этом есть необходимость).
Шаг 2. Разработка диаграммы уровня основных процессов.
2.1.Идентификация бизнес-процессов с указанием их типов.
2.2.Группирование процессов по деятельностям.
2.3.Определение связей между процессами и внешними объектами и их непосредственное связывание с использованием родительских потоков (по токов между внешними сущностями и контекстным процессом).
2.4.Определение информационных потоков между процессами.
2.5.Идентификация базовых накопителей.