Тема 9. Реинжиниринг бизнес-процессов на основе информационных технологий

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

Впервые термин "реинжиниринг бизнес-процессов" (от англ. business process reengineering, BPR) был введен М.Хаммером, который определяет этот вид деятельности как "фундаментальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных актуальным показателях их деятельности: стоимость, качество, услуги и темпы".

В западном мире (и, в первую очередь, в США) реинжиниринг приобретает все большую и большую популярность. Так, компании США затратили на проекты по реинжинирингу бизнес-процессов в 1994 году около 37 млрд. долларов. В течение ближайших лет рост затрат на решение этих задач ожидается на уровне 19% в год.

По данным компании Emst & Young, 100 крупнейших банков Северной Америки затратят в 1999 году около 3,9 млрд. долларов только на реинжиниринг своих подразделений. За последние полтора года правительство США инициировало более 250 поектов по реинжинирингу, а сегодняшний рынок инструментальных средств поддержки BPR оценивается более чем в 100 млн. долларов и растет со скоростью около 60% в год.

По результатам опроса, проведенного Emst & Young среди финансовых директоров 80-ти крупнейших компаний США, основной мотивацией проведения реинжиниринга было улучшение сервиса и качества продукции (услуг), а также снижение расходов.

М.Хаммер рассматривает BPR как революцию в бизнесе, которая знаменует отход от базовых принципов построения предприятий и превращает конструирование бизнеса в инженерную деятельность. Возможность такой революции обусловлена, в первую очередь, новейшими достижениями в области информационных технологий, специалисты которой начинают играть ведущую роль в конструировании бизнеса.

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

Одной из основных особенностей BPR является ориентация реинжиниринга не на функции, а на процессы. Причем из всех концепций менеджмента, основанных на процессах, BPR рассматривается как наиболее эффективная, революционность которой обусловлена современным состоянием информационных технологий.

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

Концепция построения бизнеса	Особенности
Автоматизация бизнес-процессов (business process automation - BPA)	Автоматизация приводит лишь к ускорению существующих бизнес-процессов. Используя информационные технологии, BPA автоматизирует существующий процесс со всеми его недостатками и не ставит перед собой задачу проектирования нового процесса для кардинального повышения эффективности.
Реинжиниринг программного обеспечения	На основе современных технологий производит переписывание устаревших информационных систем без изменения самих автоматизируемых процессов.
Уменьшение размерности (downsizing) предприятия	Уменьшение возможностей компании, вызванные снижением требований рынка. BPR, напротив, увеличивает возможности компании.
Реорганизация (reorganizing) предприятия	Данная концепция имеет дело только с организационными структурами, а не с процессами.
Улучшение качества (quality improvement - QI), глобальное управление качеством (total quality management - TQM)	Хотя управление качеством отводит центральную роль бизнес-процессам, данный метод принимает имеющиеся процессы и старается их улучшить, а не меняя их на новые.
Реинжиниринг бизнес-процессов (business process reengineering)	"Фундаментальное переосмысливание и радикальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных актуальных показателях их деятельности: стоимость, качество, услуги и темпы". (М.Хаммер)

Таким образом, реинжиниринг бизнес-процессов ориентирован на коренную перестройку всей деятельности предприятия, а не на частичные изменения в той или иной сфере управления.

Поскольку BPR оперирует с такими понятиями, как бизнес-процесс, бизнес-система, деловая процедура, то в целях более четкого восприятия этих терминов следует дать следующие определения.

Бизнес-система - это связанное множество бизнес-процессов, конечной целью которойявляется выпуск продукции. Под продукцией, понимают товары, услуги и документы.

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

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

Существуют следующие категории бизнес-процессов:

- процессы, непосредственно обеспечивающие выпуск продукции;

- процессы планирования и управления;

- ресурсные процессы;

- процессы преобразования.

Бизнес-процесс характеризуется:

- существующей технологией реализации бизнес-процесса;

- существующей структурой бизнес-системы;

- средствами автоматизации, оборудованием, механизмами и т.п., обеспечивающими реализацию процесса.

Основными показателями оценки эффективности бизнес-процессов являются:

- количество производимой продукции заданного качества, оплаченное за определенный интервал времени;

- количество потребителей продукции;

- количество типовых операций, которые необходимо выполнить при производстве продукции за определенный интервал времени;

- стоимость издержек производства продукции;

- длительность выполнения типовых операций;

- капиталовложения в производство продукции.

Базовыми принципами, лежащими в основе реинжиниринга бизнес-процессов, являются:

- несколько рабочих процедур объединяются в одну, т.е. происходит горизонтальное сжатие процесса (по имеющимся оценкам, горизонтальное сжатие ускоряет выполнение процесса примерно в 10 раз);

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

- шаги процесса выполняются в естественном порядке;

- процессы имеют различные варианты исполнения ( тот или иной вариант выбирается в зависимости от конкретной ситуации, состояния и т.д.);

- работа выполняется в том месте (подразделении, отделе), где это целесообразно (устраняется излишняя интеграция, что приводит к повышению эффективности процесса в целом);

- уменьшается количество проверок и управляющих воздействий;

- минимизируется количество согласований путем сокращения внешних точек контакта;

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

Подводя итог теме реинжиниринга, заметим, что BPR - это не просто модная тенденция, а следствие жесточайшей конкурентной борьбы, которая требует внедрения наукоемких инновационных технологий как средств повышения производительности и эффективности деятельности предприятия.

Причины возникновения BPR

С середины, еще более - с конца 80-х годов темп изменений внешней среды предприятий ускорился, в том числе за счет ИТ. Во всем мире изменения в организации производственной и управленческой деятельности стали происходить все быстрее. С внешней стороны, стороны потребителей, правильнее всего описывать причины этих изменений с позиций маркетингового анализа:

- возросла доступность товаров и услуг производителей из любой точки мира;

- резко возросли требования потребителей к качеству товаров и услуг любых видов, к срокам их предоставления;

- из-за роста возможностей выбора, который имеют потребители, стало резко уменьшаться время жизни товара или услуги на рынке;

- сильно возросла конкуренция в части предложения новых товаров и повышения их качества.

Соответственно, стали изменяться требования к деятельности субъектов рынков - банков, промышленных предприятий, предприятий индустрии ИТ и др.

Внутренние причины возникновения BPR

В литературе выделяют следующие три, во многом взаимосвязанных причины:

1 Рост сложности новых продуктов. Имеется в виду ускорившийся рост числа и сложности продуктов практически во всех производственных организациях, причем в степени, приведшей к тому, что ни отдельный человек, ни даже группа людей не может знать все технические детали продукта. Это справедливо и для автомобильной промышленности, и для страховых и инвестиционных компаний, и для ресторанов "быстрой еды". Соответственно усложняются управленческие задачи.

2 Непригодность дальнейшего увеличения числа сотрудников на всех уровнях предприятия для решения усложнившихся управленческих задач. Рост числа работников на средних уровнях менеджмента организаций США многие годы являлся ответом на несколько факторов, включая рост сложности продуктов и методов бизнеса, плодовитость правительственных организаций в области законодательного регулирования и глобализацию коммерческой деятельности. Но возникла ситуация, в которой рост числа персонала перестал соответствовать росту удовлетворения клиентов. Одна из причин - стоимость труда: другие страны применили схему бизнеса США при существенно меньшей стоимости рабочей силы.

3 Недостаточная отдача от инвестиций в компьютерные системы и ИТ. Расчеты на то, что использование компьютеров и других ИТ само по себе решит проблемы эффективного управления производством не оправдались. Пример из бизнеса США: с 60-х годов, когда компьютеры стали доступны многим предприятиям, общие затраты на них составили более двух триллионов долларов. Однако рост производительности, соответствующий росту инвестиций, не был получен. Основная причина: использование компьютеров не меняло ничего в том, как собственно велись дела, т.е. как выполнялся бизнес. Не менялись траектории и объем потоков бумаг, точки принятия решений и их число и т.п.

Только появление качественных изменений в ИТ стало приводить, причем вначале - к отдельным очагам изменения ситуации, когда новые ИТ стали и подталкивать к улучшению бизнес-процессов, и давать для этого реальные средства.

BPR: мотивы предприятий

При классификации предприятий по мотивам к проведению BPR выделены три категории предприятий, которые обдумывают и планируют для себя Реконструкцию:

- находящиеся в большой тревоге. Те, например, которые теряют клиентов, объем продаж, имеют плохие финансовые показатели;

- у которых текущие дела - в порядке, но их руководители предвидят серьезные проблемы в будущем, если имеющаяся организация не изменится в принципе;

- которые лидируют в своей области и будут лидировать в обозримом будущем, но хотят реорганизации для того, чтобы еще более затруднить конкуренцию с собой.

Для отечественных условий можно выделить и другие, специфические конкретные мотивы, например:

4 решение выйти на внешние рынки со своими товарами и услугами (банки, экспорт сырья, авиаперевозки и др.);

5 прогноз появления на своем рынке конкуренции иностранных фирм;

6 стремление создать условия, в которых были бы вероятны западные инвестиции в данное предприятие;

7 желание перейти к выпуску качественно новой продукции для начала конкурентной борьбы (как на национальном, так и на зарубежных рынках).

Принципы реинжиниринга предприятия

Изменения в стратегии, производственных процессах, структуре и культуре предприятия могут осуществляться постепенно, в виде мелких шагов, или же радикально, в виде крупных скачков. В этой связи соответственно говорят об эволюционной и революционной моделях изменений. Революционные изменения можно представить в рамках реинжиниринга хозяйственной деятельности.

1 «Фундаментальный».

Должны быть получены ответы на ключевые вопросы о деятельности предприятия: «Почему мы должны делать то, что мы делаем?» и «Почему мы должны делать это тем способом, которым мы это делаем?»

2 «Радикальный»

Радикальность означает отбрасывание всех существующих структур и процедур и воплощение новых способов выполнения работ.

3 «Драматический»

Если предприятие имеет падение производства всего на 10%, если его затраты всего на 10% превышают норму, если показатель качества нужно увеличить всего на 10%, если процесс обслуживания заказчиков требует ускорения всего на 10% — то предприятию не требуется реинжиниринг. В этом случае применимы «обычные» методы, например программы постепенного улучшения качества. РБП должен применяться только тогда, когда есть нужда во «взрывном» воздействии.

4 «Процессы»

Указывается, что хотя это понятие — самое важное в определении реинжиниринга, оно наиболее трудно понимается управляющими предприятий. Большая часть деловых людей не является «процессоориентированными»; они сфокусированы на задачах, на работах, на людях, на структурах, но не на процессах. М.Хаммер и Дж.Чампи определяют бизнес-процесс как «совокупность видов деятельности, которая имеет один или более видов входных потоков и создает выход, имеющий ценность для клиента».

Объектом реинжиниринга являются не организации, а процессы. Предприятия подвергают реинжинирингу не свои отделы продаж или производства, а работу, выполняемую персоналом этих отделов.

Одним из путей улучшения управления процессами, в совокупности образующими бизнес компании, является присвоение им наименований, отражающих их исходное и конечное состояния. Эти наименования должны отражать все работы, которые выполняются в промежутке между стартом и финишем процесса. Термин «производство», звучащий как название отдела, лучше подходит к процессу, происходящему с момента закупки сырья до момента отгрузки готовой продукции. По этому же принципу могут быть названы еще некоторые повторяющиеся процессы, например:

- «разработка продукта» — от выработки концепции до создания прототипа;

- «продажи» — от выявления потенциального клиента до получения заказа;

- «выполнение заказа» — от оформления заказа до осуществления платежа;

- «обслуживание» — от получения запроса до разрешения возникшей проблемы.

Для первичного определения процессов предприятия ориентиром может служить система качества ИСО 9001.  В стандарте ИСО 9001 перечисляются те бизнес-функции предприятия, или, другими словами, элементы качества, на которые распространяется действие стандарта:

- ответственность руководства;

- система качества;

- анализ контракта;

- управление проектированием;

- управление документацией;

- закупки продукции;

- продукция, предоставленная потребителем;

- идентификация продукции и прослеживаемость;

- управление процессами;

- контроль и проведение испытаний;

- контрольное, измерительное и испытательное оборудование;

- статус контроля и испытаний;

- управление несоответствующей продукцией;

- корректирующие и предупреждающие действия;

- погрузочно-разгрузочные работы, хранение, упаковка и поставка;

- регистрация данных о качестве;

- внутренние проверки качества;

- подготовка кадров;

- техническое обслуживание;

- статистические методы.

При определении порядка реинжиниринговых мероприятий после идентификации процессов используются три критерия, определяющих последовательность замены процессов:

Первый — дисфункциональность: осуществление каких процессов сопряжено с наибольшими трудностями.

Второй — значимость: какие процессы оказывают наибольшее воздействие на клиентов компании.

Третий — осуществимость: какие из происходящих в компании процессов могут быть перепроектированы в данный момент наиболее успешно.

Проект по реинжинирингу бизнеса обычно включает в себя следующие четыре этапа:

1 Разработка образа будущей компании;

2 Создание модели существующей компании (обратный инжиниринг);

3 Разработка нового бизнеса (прямой инжиниринг):

- перепроектирование бизнес-процессов;

- разработка бизнес-процессов компании на уровне трудовых ресурсов;

- разработка поддерживающих информационных систем.

4 Внедрение перепроектированных процессов.

Несомненно, приведенная последовательность несколько условна, однако в каждом проекте по изменению бизнеса компании присутствуют данные этапы.

При проведении РБП выделяют несколько ключевых ролей:

- владелец процесса,

- лидер команды,

- коммуникатор,

- участник команды,

- внешний консультант,

- координатор.

Владелец процесса отвечает за ход и результат всего процесса в целом, занимается измерением и совершенствованием эффективности всего процесса. Лидер команды — руководитель группы по реинжинирингу, занимающий влиятельный пост в организации, инициирует проведение реинжиниринга и берет на себя всю ответственность и риск, связанный с ним. Коммуникатор является дополнительным звеном между лидером и группой РБП. Его задачей является формализация в соответствии с технологией идей лидера, проведение обучения группы. Внешний консультант является сторонним по отношению к организации экспертом, что имеет как положительные стороны  для результата проекта, так и отрицательные, об этом не следует забывать. В больших организациях могут параллельно выполняться несколько проектов, следовательно, имеется необходимость в их согласовании, обеспечении связи между разными реинжиниринговыми проектами. Данными вопросами занимается координатор. При малом количестве проектов эта роль может быть совмещена с ролью коммуникатора.

Установлено, что оптимальное число участников команды по РБП колеблется в зависимости от величины проекта от 5 до 7 человек, включая лидера и не считая коммуникатора. Для реализации проекта не обязательна полная занятость всех членов команды, так как выполнение своих непосредственных обязанностей не дает возникнуть чувству оторванности от организации.

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

Установлено, что источником получения ценных идей и знаний руководителями компаний  были беседы с коллегами и знакомство с опытом других предприятий. Поэтому методы «передача передового опыта» и «сравнение с показателями других предприятий» (бенчмаркинг) становятся популярными. Команда по реинжинирингу при анализе существующих и представляемых (будущих) процессов не должна пренебрегать опытом коллег.

Опора на опыт способствует снижению риска, сокращению временных и финансовых затрат, связанных с наработкой собственных схем через экспериментирование. Следует особенно отметить, что использование бенчмаркинга позволит реформируемому предприятию создать команду внутренних консультантов, наработать опыт, подготовить базу для дальнейшего совершенствования организации и управления [6].

Таким образом, реинжиниринг отнюдь не является тенденцией, оторванной от остальных современных инициатив; скорее, это один из последних представителей семейства процессуально ориентированных стратегий и методов управления, к которым относятся также методики «точно в срок» и тотального управления качеством. И реинжиниринг, и тотальное управление качеством, рассматривая предприятие как открытую систему, направлены на наибольшее удовлетворение потребностей клиента и ставят под сомнение эффективность существующих на предприятии процессов. Тем не менее, эти две стратегии различны и дополняют друг друга.

Управление качеством — децентрализованная инициатива персонала, идущая снизу вверх и ориентированная на постепенные усовершенствования текущих процессов, принимаемых за основу. В отличие от этого, реинжиниринг предполагает полное разрушение традиционных организационных границ и замену имеющихся процессов, чтобы добиться резкого улучшения деятельности предприятия. Он всегда инициируется централизованно, сверху вниз.

Новые процессы, возникающие в результате реинжиниринга, обычно имеют отличительные свойства. К ним относятся реинтеграция, или горизонтальное сжатие процесса (несколько операций объединяются в одну), вертикальное сжатие процесса (исполнители, которым делегирована часть властных полномочий, принимают самостоятельные решения), совмещение или распараллеливание части ранее последовательных работ, уменьшение проверок и управляющих воздействий, минимизация согласований, преобладание смешанного централизованно/децентрализованного подхода.

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

При реинжиниринге процесса происходит эволюция трудовых заданий от узкоспециализированных и ориентированных на задачу к более многомерным. Люди, которые раньше действовали в соответствии с инструкциями, теперь сами выбирают вариант из имеющихся альтернатив и принимают решения. Исчезает конвейерный принцип организации работы.

Обобщим изменения, происходящие на предприятии, проводящем реинжиниринг своих бизнес-процессов. Изменяются трудовые задания, равно как и люди, способные их выполнить, отношения между этими людьми и менеджерами, планы личного развития этих людей, способы, с помощью которых их труд оценивается и оплачивается, роли менеджеров и руководителей и даже то, что происходит в головах работников. Можно сделать общий вывод — изменения, инициированные реинжинирингом бизнес-процессов, обязательно изменяют ключевые элементы системной структуры предприятия, поскольку все аспекты ее функционирования — люди, трудовые задания, менеджеры и ценности — связаны друг с другом. Хаммер и Чампи называют их четырьмя элементами многогранной модели системы внутрифирменного управления. Заглавный элемент данной модели — это бизнес-процессы предприятия, то есть способ, которым осуществляется работа; второй — это ее трудовые задания и организационные структуры; третий — системы управления и оценки результатов; четвертый — организационная культура, то есть ценности и убеждения ее работников.

Связи между этими элементами играют ключевую роль. Заглавный элемент многогранной модели системы внутрифирменного управления — процессы — определяет второй — трудовые задания и структуру (рисунок 2). Способы осуществления работы определяют природу трудовых заданий и то, как люди, выполняющие эти задания, сгруппированы и организованы. Фрагментированные процессы, столь характерные для традиционных компаний, обусловливают узкую специализацию трудовых заданий и организаций, основанных на функциональных отделах. Интегрированные процессы порождают многомерные трудовые задания, выполнение которых лучше всего может быть организовано посредством процессных команд.

Аналогично люди, выполняющие многомерные трудовые задания и организованные в команды, должны наниматься, оцениваться, оплачиваться посредством надлежащих управленческих систем. Другими словами, трудовые задания и структуры, сами определяемые характером процессов, в свою очередь, приводят к третьему элементу многогранной модели — типу управленческих систем, которые должно иметь предприятие.

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

Наконец, превалирующие в организации ценности и убеждения должны поддерживать функционирование ее процессов в том виде, в котором они спроектированы. Например, процесс выполнения заказов, спроектированный как действующий быстро и точно, не станет таковым, если люди, осуществляющие его, не считают важными скорость и точность. Здесь возвращаемся на вершину — в реинжиниринге недостаточно перепроектировать лишь сами процессы. Все четыре элемента модели системы внутрифирменного управления должны соответствовать друг другу, иначе у предприятия появляются изъяны в работе и она деформируется.

Рисунок 1 – Многогранная модель системы внутрифирменного управления

Таким образом, реинжиниринг может пониматься как процесс замены многогранной модели управления предприятием, потерявшей свою стройность, на новую.

Информационные технологии при проведении реорганизации

Часто возникает вопрос о проведении реинжиниринга бизнес-процессов в связи с внедрением компьютерных систем управления (табл. 1). Более того, существует устоявшееся мнение,  что процесс внедрения системы управления должен сопровождаться реструктуризацией бизнес-процессов предприятия. Необходимо уяснить, что реинжиниринг и внедрение КИС (корпоративной информационной системы) есть процессы совершенно различные, и ни в коем случае их не следует смешивать. Более того, большинство неудач при внедрении КИС связаны именно с тем, что перед началом проекта не была четко уяснена его цель, в процессе автоматизации становились явными недостатки предыдущей системы, появлялась возможность изменить, ускорить, расширить сложившиеся процессы. В результате принималось решение о локальной реструктуризации, слабо контролируемой и нетехнологичной.

Тем не менее, информационные технологии играют определяющую роль в реинжиниринге бизнеса, современные передовые информационные технологии являются неотъемлемой частью любого реинжинирингового мероприятия, существенным конструктивным фактором его успеха.

М. Хаммер и Дж. Чампи определили значимость информационных технологий для реинжиниринга в виде следующих утверждений:

- компания, которая не способна поменять свое мышление с дедуктивного на индуктивное, не готова к проведению реинжиниринга;

- компания, которая ставит знак равенства между технологией и автоматизацией, не готова к проведению реинжиниринга;

- компания, которая сначала ищет проблемы, а затем для их решения подыскивает технологии, не готова к проведению реинжиниринга.

Можно определить различия данных определений следующим образом: дедуктивное решение есть поиск решения выявленной проблемы, а индуктивное мышление сначала определяет эффективное решение, а затем определяет проблемы, которое найденное решение исключает. А основным инструментом для построения новых возможностей служат информационные технологии, однако их неправильное применение может сорвать реинжиниринг, усиливая как старые способы мышления, так и прежние стереотипы поведения.

Таблица 1 – Этапы РБП и внедрения корпоративной информационной системы

Этапы реинжиниринга	Этапы разработки и внедрения корпоративной информационной системы (КИС)
1. Разработка образа будущей компании	1. Предварительное обследование
2. Создание модели существующей компании (модель «как есть»)	2. Разработка технического задания на создание КИС
3. Разработка нового бизнеса (модель «как должно быть») 3.1 Перепроектирование бизнес-процессов 3.2 Разработка бизнес-процессов компании на уровне трудовых ресурсов 3.3 Разработка поддерживающих информационных систем	3. Создание системы Объектоориентированная, поэтапная, итерационная разработка продукта
4. Внедрение перепроектированных процессов Эволюционные улучшения бизнес-процессов, использование иных методик	4. Внедрение системы 4.1 Подготовка объекта к внедрению системы 4.2 Сдача задач и подсистем в опытную эксплуатацию 4.3 Проведение опытной эксплуатации 4.4 Сдача задач, подсистем, системы в целом в промышленную эксплуатацию

Ключевой функцией процесса преобразований деятельности предприятия является построение моделей деятельности предприятия. На данном этапе осуществляются обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

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

- модели «как должно быть», интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия.

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

Переход от модели «как есть» к модели «как должно быть» осуществляется следующими двумя способами.

1 Совершенствование технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников («легкий» реинжиниринг).

2 Радикальное изменение технологий и переосмысление бизнес-процессов («жесткий» реинжиниринг). Например, вместо попыток улучшения бизнес-процесса проверки кредитоспособности клиента, может быть, следует задуматься, а нужна ли вообще такая проверка? Возможно, затраты на такие проверки каждого из клиентов во много раз превышают убытки, которые может понести предприятие в отдельных случаях недобросовестности (в случае, когда клиентов много, а суммы закупок незначительны).

Построенные модели являются не просто реализацией начальных этапов разработки системы и техническим заданием на последующие этапы. Они представляют собой самостоятельный отделяемый результат, имеющий большое практическое значение, в частности:

1 Модель «как есть» включает в себя существующие неавтоматизированные технологии, работающие на предприятии. Формальный анализ этой модели позволит выявить узкие места в технологиях и выработать рекомендации по ее улучшению (независимо от того, предполагается на данном этапе автоматизация предприятия или нет).

2 Она позволяет осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности предприятия (так как ее технология содержится в модели) с использованием диаграмм (известно, что «одна картинка стоит тысячи слов»).

3 С ее помощью можно осуществлять предварительное моделирование нового направления деятельности с целью выявления новых потоков данных, взаимодействующих подсистем и бизнес-процессов.

Средством реализации предложенных задач могут служить CASE-средства. (Computer-Aided Software/System Engineering). В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Можно определить CASE как технологию, представляющую собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимоувязанных средств автоматизации. CASE — это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий заменить им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки ПО.

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

Несмотря на то что структурные методологии зарождались как средства анализа и проектирования ПО, сфера их применений выходит далеко за рамки названной предметной области. Поэтому CASE-технологии успешно применяются для моделирования практически всех предметных областей, однако устойчивое положение они занимают в следующих областях:

- в бизнес-анализе (фактически модели деятельности предприятий «как есть» и «как должно быть» строятся с применением методов структурного системного анализа и поддерживающих их CASE-средств);

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

Практически ни один серьезный зарубежный программный проект не осуществляется без использования CASE-средств. Известная методология структурного системного анализа SADT (Structured Analysis and Desing Technique), точнее ее подмножество IDEF0 (Icam DEFinition — IDEF), принято в качестве стандарта на разработку ПО Министерством обороны США. Более того, среди менеджеров и руководителей компьютерных фирм считается чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов суметь нарисовать простейшую диаграмму, поясняющую суть дела.

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

Основные методологии обследования организаций. Стандарт IDEF0.

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

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

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

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

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

- финансовой отчетности.

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

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

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

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

Использование методологии IDEF при BPR

Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании. Результатом этого обследование является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению "узких мест" в управлении деятельностью. На основании этого заключения, непосредственно перед проектом внедрения системы автоматизации, проводится так называемая реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная для компании. Это и естественно, сложившийся годами коллектив всегда сложно заставить "думать по-новому". Подобные комплексные обследования предприятий всегда являются сложными и существенно отличающимися от случая к случаю задачами. Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. В настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

2 IDEF1 - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

3 IDEF1X (IDEF1 Extended) - методология построения реляционных структур. IDEF1X относится к типу методологий "Сущность-взаимосвязь" (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

4 IDEF2 - методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (CPN - Color Petri Nets);

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

6 IDEF4 - методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

7 IDEF5 - методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация.

В рамках этой статьи мы рассмотрим наиболее часто используемую методологию функционального моделирования IDEF0.

История возникновения стандарта IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвящанная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках "аналитик-специалист". Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандарам и Технологиям США (NIST).

Основные элементы и понятия IDEF0

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги", а не "производство услуг").

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:

- Верхняя сторона имеет значение "Управление" (Control);

- Левая сторона имеет значение "Вход" (Input);

- Правая сторона имеет значение "Выход" (Output);

- Нижняя сторона имеет значение "Механизм" (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рисунок 1 – Функциональный блок

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

При построении IDEF0 - диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. К примеру, на рисунке 2 изображен функциональный блок "Обработать заготовку".

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

Рисунок 2 – Функциональный блок "Обработать заготовку"

Другое дело, когда технологические указания обрабатываются главным технологом и в них вносятся изменения (рисунок 3). В этом случае они отображаются уже входящей интерфейсной дугой, а управляющим объектом являются, например, новые промышленные стандарты, исходя из которых производятся данные изменения.

Рисунок 3 – Функциональный блок "Корректировать технологические указания"

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.

Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором "А-0".

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

Определение и формализация цели разработки IDEF0 - модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которую бы мы разрабатывали для того же самого предприятия, но уже с целью оптимизации логистических цепочек.

Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком - Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит - родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. Наглядно принцип декомпозиции представлен на рисунке 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую "деталь" на входе в функциональный блок "Обработать на токарном станке" не имеет смысла отражать на диаграммах более высоких уровней - это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных "концептуальных" интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока - приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии - в таком случае, они сначала "погружаются в туннель", а затем, при необходимости "возвращаются из туннеля".

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги "распоряжение об оплате" глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

Рисунок 4 – Декомпозиция функциональных блоков

Принципы ограничения сложности IDEF0-диаграмм

Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:

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

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

Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.

Дисциплина групповой работы над разработкой IDEF0-модели

Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов:

- Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

- Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким спектром компетентных лиц (в терминах IDEF0- читателей) на предприятии. При этом каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.

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

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

Особенности национальной практики применения функционального моделирования средствами IDEF0

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

- Что поступает в подразделение "на входе"?

- Какие функции, и в какой последовательности выполняются в рамках подразделения?

- Кто является ответственным за выполнение каждой из функций?

- Чем руководствуется исполнитель при выполнении каждой из функций?

- Что является результатом работы подразделения (на выходе)?

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

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

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

Контрольные вопросы

1 Сформулируйте причины возникновения BPR.

2 Перечислите принципы реинжиниринга предприятия.

3 Дайте определение процессу.

4 Перечислите основные этапы РБП и внедрения корпоративной информационной системы.

5 Сформулируйте основные стандарты методологии IDEF и поясните основные отличия.

ИТ - лек 82