1. Начинать лучше ... сначала
Управленческий консалтинг
Современные технологии для работы со структурами организации
. Бумага и карандаш - уже инструмент
Хорошо известен замечательный пример о том, как с первой попытки даже опытному руководителю трудно сосчитать "количество бизнесов" в рамках одного предприятия (фирмы). Однако практически всегда стоит задача не просто пересчитать бизнесы,а определить их взаимодействие, по возможности оптимальным образом.
Естественно, прежде чем заниматься этой, более сложной, задачей, необходимо, действительно, по крайней мере "пересчитать" все элементы бизнеса, то есть создать орг-штатаную структуру компании. Следующий этап - попытаться графически изобразить взаимосвязи между различными элементами ранее определенной структуры. Для этого можно использовать простейшие графические средства - в результате получится известная на всю страну схема, украшавшая ( да и украшающая сейчас) стены многих административных кабинетов. Для первого раза и это уже большой прогресс. Однако если вы участвовали в "создании" подобных "иллюстраций", то наверяка наете как много неожиданных проблем порождает это простейшее графическое упражнение. Большинство этих проблем также уже было рассмотрено в предыдущих выпусках. В результате, вместо одного-двух дней, "процесс изображения структуры" затягивалсяна месяцы, если вообще заканчивался. Если же все-таки он завершался успешно, то этого было достаточно, чтобы удовлетворить руководство и с гордостью утверждать: "у нас хорошо проработанная структура организации". В условиях современного бизнеса, к сожалению, этого может оказаться недостаточно (хотя и этот первый шаг исключительно важен, если он не имел места). Дело в том, что кроме собственно оргштатной структуры важнейшее значение имеет система взаимодействия между ее элементами, тем более в условиях динамично изменяющегося, диверсифицированногобизнеса. Такая система взаимодействия имеет три основных аспекта:
- административный;
- финансовый;
- материальный (товарный).
А с учетом новейших технологий можно было бы добавить и еще два:
- информационный;
- коммуникационный.
Наиболее существенными для бизнеса являются вопросы организации трех процессов финансового взаимодействия:
- финансового планирования (бюджетирования);
- финансирования (исполнения бюджетов);
- финансовой отчетности.
Естественно, что подобное взаимодействие не обходится без бумагооборота (более изящно называемого, как правило, документооборотом). Для отображения документооборота приходится применять уже более изощренные средства, одним изкоторых явяляются "диаграммы потоков данных".
"Диаграммы потоков данных". имеют один существенный недостаток: они показывают перемещение только тех данных (документов), которые мы смогли "увидеть". Из трех перечисленных выше систем взаимодействия подразделений наиболее хорошо поддержана формализованным документооборотом финансовая система, административное и материальное взаимодействие поддержано документооборотом, как правило, только в части тесно связанной с финансами. Кроме того, напрактике есть масса дополнительных факторов, оказывающих влияние на документооборот, но стандартно не формализуемых. Например, как отразить тот факт, что в реальном офисе заявку может подать только "дядя Вася", то есть фактически проводится процесс "визирования", не отраженный в бумажной формедокумента. Подобные "тонкости" не находят должного отражения при моделировании систем с помощью "диаграмм потоков данных" (ДПД). Тем не менее весьма эффективны ДПД-диаграммы как простейшее средство формализации взаимодействия междуобьектами бизнеса, в двух случаях: или когда вы хотите наиболее простыми средствами отразить уже идельно отлаженный механизм бизнеса (напрмер, для целей построения компьютерной системы) или же, наоборот, если перед вами совершенно "темный лес", и вы делаете первые наброски, пытаясь найти "луч света в темном царстве". Для полноты картины следует упомянуть, что существуют более изощренные методики ДПД-моделирования, входящие в семейство CASE (computer aided software engineering)- компьютерное проектирование программных систем) и предназначенные для профессионалов информационных систем. Однако их практическое применение высокоэффективно, как правило, только для отражения информационных структур бизнес-процесса, оптимизация которого проведена уже другими средствами.
2. Если средств не хватает ... ищите методы.. Если дело кажется сначала очень простым - лучше не начинать, все плохо кончится
. Если кажется, что все трудности уже преодолены - значит вскоре вы окажетесь в тупике
Вывод: Не ищите простых путей - ищите средства передвижения
В большинстве случаев имеет место значительно более сложная ситуация, промежуточная между двумя описанными выше крайностями: интуитивно все вроде бы понятно, но при попытках формализовать взаимоотношения возникает "сплошной туман". В данной ситуации существенно помочь может хорошо разработанное семейство методологий IDEF, являющееся государственным стандартом в США. Данное семейство состоит из методологии функционального моделирования IDEF0 и методологии информационнго моделирования IDEF1(X). Предполагалось создание стандарта на методологию динамического моделирования IDEF2, однако по хорошо известным причинам оптимизм в вопросах моделирования динамических систем угас по сравнению с эпохой ранней компьютеризации и стандарт так и не был создан (тем не менее существуют реализации систем динамического моделирования, преобразующие статические модели семейства IDEF0 в модели на базе "раскрашенных сетей Петри"). IDEF - методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между ВСЕМИ специалистами - участниками программы ICAM (отсюда название: Icam DEFinition - IDEF). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов (к слову сказать, он активно применяется и в отечественных госструктурах, например в Государственной Налоговой Инспекции). Более того, собственно с широким применением IDEF ( и предшествующей методолoгии - SADT ) и связано возникновение основных идей популярного ныне понятия - BPR (бизнес-процесс реинжиниринг).
Особенностью рассматриваемого семейства методологий является, во-первых, уникальная способность "задавать вопросы" в процессе моделирования, а, во-вторых, неразрывная связь графических средств (нотации), методологии и , наконец, технологии. С этой точки зрения семейство IDEF является, пожалуй, единственной системой,которая предоставляет не только средства отображения бизнес-процессов, но и методологию взаимодействия "аналитик-специалист", и, кроме того, технологию создания проектов, охватывающую все стадии "жизненного цикла" - от первичного анализа до формы представления окончательного проекта, через поэтапный процесс создания диаграмм и хранения версий.
3. Хорошая методология - хорошо структуированная методология.. Если используя инструмент моделирования, каждый шаг нужно придумывать самому, ТО ЗАЧЕМ ОН ТАКОЙ НУЖЕН !
В основе нотации и методологии IDEF0 лежит понятие "блока", то есть прямоугольника, который выражает некоторую функцию бизнеса (в соответствии со стандартом функция должна быть выражена глагольным оборотом). Как известно,прямоугольник имеет четыре стороны. В IDEF0 роли (функциональные значения) всех сторон различны:
верхняя сторона имеет значение "управления"
левая - "входа"
правая - "выхода"
нижняя - "механизма"
Рис. 1 (базовый блок)
Вторым элементом методологии и нотации является "поток" (в стандарте называемый - "интерфейсная дуга") - элемент, описывающий данные, неформальное управление, или что-либо другое "оказывающее влияние" на функцию, изображенную блоком. Потоки обозначаются оборотом существительного. В зависимости от того к какой стороне блока направлен поток, он, соответственно, носит название "входной", "выходной", "управляющий". Изобразительным элементом, представляющим "поток", является стрелка. Используя модную ныне терминологию, можно интерпретировать поток как представление "обьекта", под которым понимается как информационный обьект, так и обьект реального мира.
Важным фактором является то, что, как правило, "источником" и "приемником" потоков (то есть началом и концом стрелки) могут быть только блоки, причем источником может являться только "выходная" сторона блока, приемником - любая из трех оставшихся. Если же необходимо подчеркнуть внешний характер потока, то может быть применен метод "туннелирования" - скрытие или появление интерфейсной дуги из "туннеля".
И, наконец, "третьим китом" методологии IDEF0 является принцип "функциональной декомпозиции" блоков. Данный принцип представляет собой модельную интерпретацию той практической ситуации, что любое действие (тем более такое сложное, как бизнес-процесс) может быть разбито (декомпозировано) на более простые операции (действия, бизнес-функции). Или, другими словами, функция может быть представлена как совокупность элементарных функций. Графически, при использовании программных средств, принцип декомпозиции представляет собой возможность, "провалившись" в функциональный блок, "рассмотреть" его "изнутри", или, по-другому, возможность воспользоваться "увеличительным стеклом" для детального изучения состава функции, представленной на более высоком уровне одним блоком.
4.
Принципы превыше всего. Если нет принципов, то и критиковать нечего, что неитересно
. Если принципы есть, то как приятно иметь собственное мнение по их применению
Для того, чтобы закончить описание базовых принципов методологии IDEF0, обратим внимание на два базовых прниципа моделирования:
- принцип контекстной диаграммы;
- принцип ограничения сложности.
Принцип контекстной даграммы.
Моделирование начинается с построения "контекстной диаграммы", то есть диаграммы, на которой система (обьект моделирования) представлена одним-единственным блоком. Все потоки на данной диаграмме подразумеваются приходящими извне, по отношению к обьекту моделирования. Для идентификации блока используется определение "миссии", которую должна выполнять система по отношению к внешнему миру (несколько патетический тон в данном случае очень важен, так как существует большой соблазн ограничиться понятными, но фактически ничего не значащими фразами типа "продавать окорочка"). При определении "миссии" необходимо иметь в виду "цель" (моделирования) и "точку зрения" (на модель). Вполне понятно, что одна и та же система (фирма) может быть представлена по-разному, в зависимости от того, например, рассматривать ли ее с точки зрения налогового инспектора или с точки зрения владельца. Если мы моделируем систему с целью построения информационной системы, то, опять же, получим модель отличную от той, которая имела бы место в случае моделирования для целей оптимизации финансового управления фирмой.
Важнейшим является то, что подобный принцип должен быть применен и при построении любого функционального блока. То есть при определении ЛЮБОГО блока внутри диаграммы ЛЮБОГО уровня нужно четко иметь в виду цель моделирования и точку зрения на модель при определении "миссии" реального субьекта бизнеса, функции которого представлены данным блоком. Тем более если данный блок предназначен для дальнейшей функциональной детализации (декомпозиции).
Контекстная диаграмма и ее диаграммы декомпозиции образуют "папку", оформляемую и используюемую участниками проекта в соответствии с определенными требованиями.
Принцип ограничения сложности.
Диаграммы IDEF0 несут в себе очень концентрированную информацию, в связи с чем необходимо применять специальные меры по повышению их разборчивости и удобочитаемости, известные как принципы ограничения сложности. Основными
являются два приципа:
- ограничение количества блоков на одной диаграмме
тремя-шестью;
- ограничение количества интерфейсных дуг, входящих
(выходящих) к одной стороне блока - четырьмя.
Естественно, в реальной работе данные ограничения не должны становиться догмой, однако как показывает опыт работы, они весьма практичны, отражая естественные закономерности управляемых систем. Значительные нарушения перечисленных принципов служат четким указанием на недостаточную проработку модели аналитиком.
5. Немного патетики не помешает даже компьютеру.. Патетика необходимо, главное чтобы она не мешала пониманию сути
. Если ее нет совсем, то за что же бороться ?
Используя приведенные выше базовые элементы, можно сформулировать основную идею моделирования IDEF0 следующим образом:
бизнес-процессы (функции реального обьекта бизнеса) представляются как некоторые преобразования входного (и, возможно, управляющего) потока в выходной под контролем (управлением) управляющего потока с использованием для преобразования "механизма". Бизнес-процессы должны быть представлены на более высоком уровне диаграммы достаточно общим образом, позволяющим уяснить их суть, однако, без излишней детализации, усложняющей понимание и чтение диаграмм.
При необходимости более детального рассмотрения они могут быть "декомпозированы", то есть представлены в виде отдельной диаграммы (папки диаграмм), для которой исходный функциональный блок играет роль контекстной диаграммы.
Завершая краткий обзор методологии IDEF0 можно сформулировать ее "миссию":
"определить, что требуется сделать для выполнения миссии обьекта, обозначенной в контекстной диаграмме, имея в виду цель моделирования и точку зрения на модель".
Если цель моделирования и точка зрения на модель позволяют, то можно оставить детализацию обьектов, представленных на диаграммах потоками, на описательном уровне, например:
вход - "товар отгруженный";
механизм - "диспетчер по отгрузке" ("дядя Вася");
управление - "инструкция по отгрузке скоропортящихся
грузов".
и т.д..
Однако поскольку, как правило, моделирование проводится в тех случаях, когда требуется не просто описать обьект, а выявить его новое (или хорошо забытое старое) содержание, например, для целей создания (внедрения) корпоративной информационно-аналитической системы и/или бизнес-процесс реинжиниринга, то все потоки в системе должны быть выявлены и описаны достаточно детализированно (кроме, быть может, потоков механизмов)
Отсюда вытекает "миссия" методологии IDEF1(X): "определить, какая информация требуется для реализации функций, описанных диаграммой IDEF0"
Не имея возможности подробно останавливаться на ее рассмотрении, подчеркнем основные особенности. Методология IDEF1(X) является разновидностью методологии ER-диаграмм (Entity-Relationship - сущность-связь), строго формализованная и адаптированная для совместного использования с IDEF0 как "дуальная" (двойственная) к ней, в рамках единой технологии моделирования. Двойственность методологии проявляется в том, что в рамках IDEF0 мы детализируем функциональные блоки, в рамках же IDEF1(X) мы детализируем (как правило) потоки, взаимодействующие с функциями (блоками). В связи с тем, что желательно иметь возможность перенесения разультатов IDEF1(X) моделирования в системы проектирования программных систем и баз данных с минимальными дополнительными затратами (собственно, для этого данная методология и создавалась), то в методологии (и особенно в ее программных реализациях) предусмотрен целый ряд мер, повышающих эффективность такой деятельности. При отсутствии непосредственной необходимости в указанном выше процессе вместо IDEF1(X) моделирования можно ограничиться детализацией обьектов IDEF0 моделирования на специальных листах модельной папки (так называемых FEO-диаграмах - диаграммах "Только для комментариев").
В заключение, отвлекаясь от специальной терминологии, можно сказать, что семейство методологий IDEF предоставляет в распоряжение менеджера, специалиста, руководителя мощный, высокоэффективный язык как для описания их повседневной деятельности, так и для планирования изменений, и, даже, для проработки идей, устремленных в будущее.
© Сергей Колесников; 1998, 1999
