Современные технологии для работы со структурами организации

Бумага и карандаш - уже инструмент

Хорошо известен замечательный пример о том, как с первой попытки даже опытному руководителю трудно сосчитать "количество бизнесов" в рамках одного предприятия (фирмы). Однако практически всегда стоит задача не просто пересчитать бизнесы, а определить их взаимодействие, по возможности оптимальным образом.

Естественно, прежде чем заниматься этой, более сложной, задачей, необходимо, действительно, по крайней мере "пересчитать" все элементы бизнеса, то есть создать оргштатаную структуру компании. Следующий этап - попытаться графически изобразить взаимосвязи между различными элементами ранее определенной структуры. Для этого можно использовать простейшие графические средства - в результате получится известная на всю страну схема, украшавшая ( да и украшающая сейчас) стены многих административных кабинетов. Для первого раза и это уже большой прогресс. Однако если вы участвовали в "создании" подобных "иллюстраций", то наверняка знаете как много неожиданных проблем порождает это простейшее графическое упражнение. Большинство этих проблем также уже было рассмотрено в предыдущих выпусках. В результате, вместо одного-двух дней, "процесс изображения структуры" затягивался на месяцы, если вообще заканчивался. Если же все-таки он завершался успешно, то этого было достаточно, чтобы удовлетворить руководство и с гордостью утверждать: "у нас хорошо проработанная структура организации". В условиях современного бизнеса, к сожалению, этого может оказаться недостаточно (хотя и этот первый шаг исключительно важен, если он не имел места). Дело в том, что кроме собственно оргштатной структуры важнейшее значение имеет система взаимодействия между ее элементами, тем более в условиях динамично изменяющегося, диверсифицированного бизнеса. Такая система взаимодействия имеет три основных аспекта:

- административный;
- финансовый;
- материальный (товарный).

А с учетом новейших технологий можно было бы добавить и еще два:

- информационный;
- коммуникационный.

Наиболее существенными для бизнеса являются вопросы организации трех процессов финансового взаимодействия:

- финансового планирования (бюджетирования);
- финансирования (исполнения бюджетов);
- финансовой отчетности.

Естественно, что подобное взаимодействие не обходится без бумагооборота (более изящно называемого, как правило, документооборотом). Для отображения документооборота приходится применять уже более изощренные средства, одним из которых являются "диаграммы потоков данных".

"Диаграммы потоков данных". имеют один существенный недостаток: они показывают перемещение только тех данных (документов), которые мы смогли "увидеть". Из трех перечисленных выше систем взаимодействия подразделений наиболее хорошо поддержана формализованным документооборотом финансовая система, административное и материальное взаимодействие поддержано документооборотом, как правило, только в части тесно связанной с финансами. Кроме того, на практике есть масса дополнительных факторов, оказывающих влияние на документооборот, но стандартно не формализуемых. Например, как отразить тот факт, что в реальном офисе заявку может подать только "дядя Вася", то есть фактически проводится процесс "визирования", не отраженный в бумажной форме документа. Подобные "тонкости" не находят должного отражения при моделировании систем с помощью "диаграмм потоков данных" (ДПД). Тем не менее весьма эффективны ДПД-диаграммы как простейшее средство формализации взаимодействия между объектами бизнеса, в двух случаях: или когда вы хотите наиболее простыми средствами отразить уже идеально отлаженный механизм бизнеса (например, для целей построения компьютерной системы) или же, наоборот, если перед вами совершенно "темный лес", и вы делаете первые наброски, пытаясь найти "луч света в темном царстве". Для полноты картины следует упомянуть, что существуют более изощренные методики ДПД-моделирования, входящие в семейство CASE (computer aided software engineering)- компьютерное проектирование программных систем) и предназначенные для профессионалов информационных систем. Однако их практическое применение высокоэффективно, как правило, только для отражения информационных структур бизнес-процесса, оптимизация которого проведена уже другими средствами.

1. Если дело кажется сначала очень простым -
лучше не начинать, все плохо кончится

2. Если кажется, что все трудности уже преодолены -
значит вскоре вы окажетесь в тупике

Вывод: Не ищите простых путей -
ищите средства передвижения

В большинстве случаев имеет место значительно более сложная ситуация, промежуточная между двумя описанными выше крайностями: интуитивно все вроде бы понятно, но при попытках формализовать взаимоотношения возникает "сплошной туман". В данной ситуации существенно помочь может хорошо разработанное семейство методологий IDEF, являющееся государственным стандартом в США. Данное семейство состоит из методологии функционального моделирования IDEF0 и методологии информационного моделирования IDEF1(X). Предполагалось создание стандарта на методологию динамического моделирования IDEF2, однако по хорошо известным причинам оптимизм в вопросах моделирования динамических систем угас по сравнению с эпохой ранней компьютеризации и стандарт так и не был создан (тем не менее существуют реализации систем динамического моделирования, преобразующие статические модели семейства IDEF0 в модели на базе "раскрашенных сетей Петри"). IDEF - методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности - ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между ВСЕМИ специалистами - участниками программы ICAM (отсюда название: Icam DEFinition - IDEF). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов (к слову сказать, он активно применяется и в отечественных госструктурах, например в Государственной Налоговой Инспекции). Более того, собственно с широким применением IDEF ( и предшествующей методологии - SADT ) и связано возникновение основных идей популярного ныне понятия - BPR (бизнес-процесс реинжиниринг).

Особенностью рассматриваемого семейства методологий является, во-первых, уникальная способность "задавать вопросы" в процессе моделирования, а, во-вторых, неразрывная связь графических средств (нотации), методологии и , наконец, технологии. С этой точки зрения семейство IDEF является, пожалуй, единственной системой, которая предоставляет не только средства отображения бизнес-процессов, но и методологию взаимодействия "аналитик-специалист", и, кроме того, технологию создания проектов, охватывающую все стадии "жизненного цикла" - от первичного анализа до формы представления окончательного проекта, через поэтапный процесс создания диаграмм и хранения версий.

Если используя инструмент моделирования, каждый шаг нужно придумывать самому, ТО ЗАЧЕМ ОН ТАКОЙ НУЖЕН!

В основе нотации и методологии IDEF0 лежит понятие "блока", то есть прямоугольника, который выражает некоторую функцию бизнеса (в соответствии со стандартом функция должна быть выражена глагольным оборотом). Как известно, прямоугольник имеет четыре стороны. В IDEF0 роли (функциональные значения) всех сторон различны:

• верхняя сторона имеет значение "управления"
• левая - "входа"
• правая - "выхода"
• нижняя - "механизма"

Рис. 1 Базовый блок

Вторым элементом методологии и нотации является "поток" (в стандарте называемый - "интерфейсная дуга") - элемент, описывающий данные, неформальное управление, или что-либо другое "оказывающее влияние" на функцию, изображенную блоком. Потоки обозначаются оборотом существительного. В зависимости от того к какой стороне блока направлен поток, он, соответственно, носит название "входной", "выходной", "управляющий". Изобразительным элементом, представляющим "поток", является стрелка. Используя модную ныне терминологию, можно интерпретировать поток как представление "объекта", под которым понимается как информационный объект, так и объект реального мира.

Важным фактором является то, что, как правило, "источником" и "приемником" потоков (то есть началом и концом стрелки) могут быть только блоки, причем источником может являться только "выходная" сторона блока, приемником - любая из трех оставшихся. Если же необходимо подчеркнуть внешний характер потока, то может быть применен метод "туннелирования" - скрытие или появление интерфейсной дуги из "туннеля".

И, наконец, "третьим китом" методологии IDEF0 является принцип "функциональной декомпозиции" блоков. Данный принцип представляет собой модельную интерпретацию той практической ситуации, что любое действие (тем более такое сложное, как бизнес-процесс) может быть разбито (декомпозировано) на более простые операции (действия, бизнес-функции). Или, другими словами, функция может быть представлена как совокупность элементарных функций. Графически, при использовании программных средств, принцип декомпозиции представляет собой возможность, "провалившись" в функциональный блок, "рассмотреть" его "изнутри", или, по-другому, возможность воспользоваться "увеличительным стеклом" для детального изучения состава функции, представленной на более высоком уровне одним блоком.