Как работает BPM-система. Построение системы управления бизнес-процессами в крупной компании Управление бизнес процессами организации

Размещено на сайте 07.05.2009

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

В.А. Лопатин, Внешэкономбанк

Введение

Словосочетание «управление бизнес-процессами» (УБП) стало активно использоваться в литературе относительно недавно, с середины 90-х годов прошлого столетия, практически одновременно с английским аналогом Business Process Management (BPM).

В свою очередь, BPM появился в противовес BPR (Business Process Reengineering), что означает реинжиниринг бизнес-процессов, или «принципиальное переосмысление и радикальная перестройка бизнес-процессов для достижения кардинальных улучшений критических современных показателей эффективности: стоимости, качества, сервиса и оперативности» 2 .

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

С момента своего появления BPM редко рассматривался только как направление менеджмента. В частности, среди его определений можно встретить следующие:

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

Систематический и структурированный подход к анализу, совершенствованию, контролю и управлению процессами с целью совершенствования качества 4 ;

Концепции, методы и технологии для поддержки проектирования, администрирования, конфигурирования, исполнения и анализа бизнес-процессов 5 ;

Метод эффективного выстраивания организации в соответствии с пожеланиями и нуждами клиентов 6 .

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

В современном варианте BPM и УБП являются развитием идей процессного подхода, получившего распространение в многочисленных системах менеджмента качества и в методах проектирования и реинжиниринга процессов. Они интегрируют наиболее адекватные, результативные и эффективные методы всеобщего контроля качества TQC (Total Quality Control), всеобщего менеджмента качества TQM (Total Quality Management), реинжиниринга бизнес-процессов BPR, непрерывного совершенствования Kaizen, производства «шесть сигм» Six Sigma, «бережливого производства» Lean Production и т.д.

Интерес к BPM/УБП постоянно растет, что выражается в увеличении спроса на специалистов по бизнес-процессам, издании многочисленной специальной литературы, включении BPM/УБП в программы MBA, проведении разнообразных семинаров и конференций и т.д. Основные причины интереса, как можно предположить, следующие:

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

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

— на рынке появился новый тип программного обеспечения — BPMS (Business Process Management System), который позволяет организациям разрабатывать процессно-ориентированные решения, способные объединять людей, системы и данные 7 ;

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

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

1. Основные понятия

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

На рисунке 1 показана структурная схема системы управления бизнес-процессами (СУБП), причем стрелками обозначено ее взаимодействие с внешней средой.

Обсуждение СУБП логично построить вокруг изучения следующих вопросов:

В какую систему СУБП входит как часть?

Какую функцию выполняет СУБП?

Какова внутренняя структура СУБП?

Что представляют собой элементы структуры СУБП?

Что представляет собой СУБП как система управления?

Но до обсуждения этих вопросов необходимо определиться с базовой категорией — «бизнес-процессами», что подразумевает поиск ответов еще на два вопроса: что такое бизнес-процесс и чем управление одним бизнес-процессом принципиально отличается от управления совокупностью бизнес-процессов?

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

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

1.1. Процесс

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

Слово «процесс» произошло от латинского слова processus (продвижение) и означает 9:

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

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

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

Во втором случае речь идет о действиях одного или нескольких субъектов, направленных на достижение результата. Субъектами обычно являются люди, подразделения и иногда машины 10 .

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

На самом деле речь идет не о двух видах процесса, а о двух представлениях (аспектах) одного процесса:

— объектно-центрированном представлении или представлении, ориентированном на состояния объектов, задействованных в процессе;

— субъектно-центрированном представлении или представлении, ориентированном на действия субъектов, участвующих в процессе.

Кстати, действия могут быть самые разные, и среди них могут быть такие, которые уничтожают одни объекты и создают вместо них другие.

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

Фактически мы вынуждены рассматривать не реальные процессы, а их модели, то есть их описания на каком-либо формализованном языке. Например, описания действий и состояний субъектов и объектов в виде текстов на русском, английском и других языках. Или диаграммы представлений процессов, например объектно-центрированные Object-Centered View и субъектно-центрированные Process-Centered View в нотации IDEF3 11 .

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

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

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

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

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

На рисунке 4 показана модель процесса, созданная в виде диаграмм объектно-центрированного и субъектно-центрированного представлений в нотации IDEF3.

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

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

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

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

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

1) даже очень сложные шаблоны не могут предусмотреть все ситуации;

2) чем сложнее шаблон, тем больше ошибок моделирования;

3) чем сложнее шаблон, тем сложнее находить и исправлять дефекты модели.

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

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

1.2. Идентификация процессов

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

Процесс представляет собой совокупность взаимосвязанных действий субъектов и обусловленных этими действиями изменений состояний объектов, которая:

а) существует ограниченное время (процесс имеет начало и окончание);

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

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

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

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

При выделении процессов возникают две проблемы.

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

Например, выдачу кредита можно представить в виде шести действий:

1) получение документов заемщика;

2) проверка документов;

3) анализ документов;

4) получение согласия кредитного комитета;

5) заключение договоров;

6) предоставление средств в распоряжение заемщика.

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

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

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

Внесение изменений в проект договора можно включить как в совокупность действий по подготовке проекта договора, так и в совокупность действий по согласованию договора.

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

1.3. Система процессов

Существует огромное количество определений термина «система». Одни обращают внимание на совокупность элементов и связей между ними. Другие выделяют целостность системы. Третьи рассматривают систему как средство для выражения проблемы и т.д. 12

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

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

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

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

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

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

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

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

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

— входы, выходы, ресурсы и продукты каждого процесса;

— совокупность действий, составляющих процесс и логику осуществления действий;

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

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

Знание структуры системы процессов позволяет осуществить классификацию процессов.

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

Наиболее часто используются системы группировки на основе иерархической (вертикальной) структуры.

Например, в соответствии со стандартом функционального моделирования IDEF0 (стандартизован Национальным институтом по стандартизации США и в 2001 г. рекомендован Госстандартом России 14) все процессы группируются по четырем уровням иерархии («деятельность», «процесс», «операция» и «действие»), к которым при необходимости могут быть добавлены еще два («субдеятельность» и «субпроцесс»).

А в соответствии с классификацией PCF (Process Classification Framework) 15 , созданной и обновляемой Американским центром производительности и качества APQC (American Productivity & Quality Center), процессы группируются по четырем уровням иерархии («категории», «группы процессов», «процессы» и «виды деятельности») и по группам в пределах каждого уровня (12 категорий, 63 группы процессов, 229 процессов и 646 видов деятельности).

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

Например, в PCF все 12 категорий групп процессов разбиты на две части (рис. 5). В первую часть (операционные процессы) входят процессы, составляющие основную деятельность компании по переработке входных ресурсов в выходной продукт и представленные в виде цепочки из пяти категорий групп процессов (кстати, эта цепочка является примером еще одного вида процессов — сквозных процессов): разработка видения и стратегии; разработка и развитие продуктов и услуг; маркетинг и продажа продуктов и услуг; поставка продуктов и услуг; послепродажное обслуживание.

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

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

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

1.4. Система бизнес-процессов

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

Прежде чем перейти к правилам выделения СБП, остановимся на центральном понятии настоящей статьи — термине «бизнес-процесс».

Трудно сказать, кто автор словосочетания «бизнес-процесс», но активно оно стало использоваться с начала 90-х годов прошлого столетия основателями реинжиниринга бизнес-процессов Дэвенпортом, Хаммером, Чампи и др. До этого для тех же целей употреблялся термин «процесс» (в основном в системах менеджмента качества).

Существует огромное количество определений терминов «процесс» и «бизнес-процесс».

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

Во-вторых, существуют объективные причины для построения сложных и замысловатых определений, в частности:

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

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

С появлением реинжиниринга и термина «бизнес-процесс» специалисты стали чаще анализировать процессы с точки зрения бизнеса.

Чтобы осознать разнообразие терминов «процесс» и «бизнес-процесс», приведем семь наиболее известных определений:

1) «процесс — завершенная с точки зрения содержания, временной и логической очередности последовательность операций, необходимых для обработки экономически значимого объекта» 17 ;

2) «процесс — совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы» 18 ;

3) «процесс — последовательность взаимосвязанных работ, имеющих своей целью потребление входов процесса и их преобразование в выходы, требующиеся внутренним или внешним потребителям, сопровождаемое созданием добавленной стоимости» 19 ;

4) «бизнес-процесс — это устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя» 20 ;

5) «бизнес-процесс — комплекс действий, в котором на основе одного или более видов исходных данных создается ценный для клиента результат» 21 ;

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

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

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

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

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

В данной статье используется второй вариант:

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

б) определение видов процесса осуществляется на этапе идентификации процессов;

в) выбор вида процесса для названия «бизнес-процесс» осуществляется на этапе выделения из СП меньшей по размеру СБП, исходя из субъективного критерия удобства использования СБП в качестве объекта управления СУБП.

Можно привести несколько правил, которыми можно руководствоваться при выделении СБП из СП:

— желательно ограничить СБП двумя уровнями вертикальной структуры СП, назвав их, например, «бизнес-процессы» и «виды деятельности» 24 ;

— выбор уровней желательно осуществлять с учетом полномочий владельца СБП. Например, СУБП руководителя банка и СУБП руководителя департамента банка будут иметь существенно различные СБП;

— желательно ограничить СБП размером не более 20 бизнес-процессов. Оптимальным, по мнению автора, является число от 7 до 15 бизнес-процессов;

— размер каждого бизнес-процесса в рамках СБП желательно ограничить размером не более 50 видов деятельности. Оптимальным, по мнению автора, является число от 15 до 30 видов деятельности (хотя, надо сказать, автор встречал бизнес-процесс, построенный из 230 видов деятельности 25).

2. Управление бизнес-процессами

Как известно, под управлением может пониматься:

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

Типичный процесс управления в банке — совокупность действий руководителя по принятию решений при отклонении действий подчиненных от стандартов или при возникновении иных обстоятельств, изменяющих результат работы подчиненных;

б) система управления, которая включает процесс управления и объект управления. При этом объектом управления является некоторый процесс или система процессов.

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

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

2.1. Управление системой бизнес-процессов

Система управления бизнес-процессами (СУБП) является подсистемой системы управления организацией в целом. Как правило, при выделении СУБП в отдельное направление менеджмента перед СУБП ставят две основные цели:

1) обеспечить конкурентоспособность бизнес-процессов;

2) обеспечить бесперебойную работу бизнес-процессов.

Для достижения первой цели СУБП должна решать задачи перспективного совершенствования бизнес-процессов и развития средств совершенствования бизнес-процессов.

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

Чтобы понять, каким образом СУБП решает поставленные задачи, вспомним, что объект управления — СБП — имеет две грани: шаблон СБП и экземпляр СБП. Шаблон СБП, как обычно, представляет собой модель используемой СБП, а экземпляр СБП — реальную СБП, управление которой осуществляет владелец СБП.

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

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

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

Заметим, что управление экземпляром СБП также включает два направления:

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

2) управление связями между отдельными бизнес-процессами.

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

В заключение приведем определение термина «управление системой бизнес-процессов» (точнее «система управления бизнес-процессами», или СУБП), соответствующее вышеприведенным рассуждениям:

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

Если частично пожертвовать строгостью, можно дать более короткое определение:

СУБП — система управления, в рамках которой владелец СБП обеспечивает функционирование и совершенствование СБП для достижения целей организации.

2.2. Управление отдельным бизнес-процессом

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

Управление отдельным бизнес-процессом включает:

а) управление шаблоном бизнес-процесса;

б) управление совокупностью экземпляров бизнес-процесса.

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

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

Может возникнуть вопрос: каким образом автоматизация бизнес-процесса изменяет шаблон бизнес-процесса?

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

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

Управление шаблоном бизнес-процесса направлено на изменение параметров шаблона и осуществляется:

— с целью адаптации бизнес-процесса к локальным изменениям внешней и внутренней среды. Например, путем внесения небольших изменений в порядок осуществления валютного контроля при выходе очередного документа Банка России или при изменении функций какого-либо подразделения банка;

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

Управление совершенствованием бизнес-процесса подробно будет обсуждаться в следующем разделе настоящей статьи.

Управление совокупностью экземпляров бизнес-процессов (или управление текущим функционированием бизнес-процесса) включает (рис. 7):

— управление каждым экземпляром бизнес-процесса в отдельности;

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

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

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

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

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

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

Перечислим возможные дефекты алгоритма управления функционированием:

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

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

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

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

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

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

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

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

Автоматизация бизнес-процессов осуществляется с использованием огромного числа систем, включая системы класса АБС, ERP, CRM и т.д. При этом современные тенденции автоматизации нацелены на широкую интеграцию систем разного класса с использованием средств интеграции приложений EAI (Enterprise Application Integration), сервис-ориентированной архитектуры SOA (Service-Oriented Architecture), сервисной шины предприятия ESB (Enterprise Service Bus) и др.

Автоматизацию средств проектирования, развертывания и мониторинга может обеспечить внедрение системы класса BPMS (Business Process Management System), которая, как правило, включает модуль проектирования бизнес-процессов BPD (Business Process Design), развертывания бизнес-процессов BPE (Business Process Engine) и мониторинга бизнес-процессов BAM (Business Activity Monitoring).

Наконец, автоматизацию средств анализа и оценки бизнес-процесса можно осуществить с помощью аналитической системы класса BI (Business Intelligence).

2.3. Управление совершенствованием бизнес-процесса

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

Рис. 8. Совершенствование бизнес-процесса

Как правило, решение проблемы состоит из трех этапов:

1) выявление и анализ проблемы;

2) конструирование решения;

3) реализация решения.

Рассмотрим более подробно эти этапы.

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

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

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

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

оценка актуальности решения проблемы. Учитывая, что невозможно решить все проблемы, их необходимо выстроить в порядке приоритета. И уже в зависимости от приоритета выделить для решения проблемы те или иные ресурсы;

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

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

определение дефектных элементов существующей системы. На данном этапе осуществляется оценка структурных элементов процесса путем использования различных методов анализа, включая стратегический анализ, финансовый анализ, анализ рисков и т.д. В частности, на этом этапе может использоваться анализ бизнес-процесса с точки зрения сбалансированной системы показателей BSC (Balance Score Card) и калькуляции затрат по направлениям деятельности ABC (Activity Based Costing);

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

Конструирование решения включает:

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

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

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

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

Наконец, реализация решения включает:

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

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

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

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

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

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

3. Проблема согласования функционального и процессного подходов

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

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

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

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

3.1. Недостатки функционально-организационной структуры

В основе функционального подхода лежат следующие базовые принципы:

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

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

3) организация закрепляет функции за соответствующими организационными единицами (подразделениями и должностями), устанавливая однозначное соответствие между организационной и функциональной структурами;

4) исходя из установленных целей и задач, организация разрабатывает технологические инструкции, в которых регламентирует действия, необходимые для достижения заданных результатов;

5) по мере изменения целей и задач технологические инструкции изменяются. Если внесение изменений в технологические инструкции не позволяет достичь нужных целей, проводится реорганизация — изменяются организационная и функциональная структуры.

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

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

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

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

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

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

3.2. Недостатки процессно-организационной структуры

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

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

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

3.3. Цепочка «функции—процессы—результаты»

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

Источник различий в содержании терминов «процесс» и «функция» можно определить, анализируя понятие «функция».

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

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

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

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

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

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

3.4. Функционально-процессный подход

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

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

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

1 - ГОСТ Р ИСО 9000. Системы менеджмента качества. Основные положения и словарь.

2 - Хаммер М., Чампи Дж. Реинжиниринг корпорации. Манифест революции в бизнесе. — М.: Манн, Иванов и Фербер, 2006.

3 - Джестон Дж., Нелис Й. Управление бизнес-процессами. Практическое руководство по успешной реализации проектов. — СПб.-М.: Символ-Плюс, 2008.

4 - Chang James F. Business Process Management Systems. Auerbach Publications, 2006.

5 - Mathias Weske. Business Process Management. Concepts, Languages, Architechures. Springer, 2007.

6 - http://en.wikipedia.org/wiki/Business_Process_Management

7 - Chang James F., op. cit.

8 - Розенблют А., Винер Н. Бигелоу Дж. Поведение, целенаправленность и телеология. / В кн.: Винер Н. Кибернетика, или управление и связь в животном и машине. — М.: Наука, 1983.

9 - Словарь иностранных слов. — М.: Русский язык, 1988.

10 - Например, иногда в процессах выделяют действия типа system-to-system, которые выполняют компьютеры.

11 - Стандарт описания процессов IDEF3 Process Description Capture Method (http://www.idef.com/pdf/Idef3_fn.pdf).

12 - Никаноров С.П. Системный анализ: этап развития методологии решения проблем в США / В кн.: Оптнер Ст. Л. Системный анализ для решения проблем бизнеса и промышленности. — М.: Советское радио, 1969.

13 - Эмерджентность — не

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

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

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

Рис. 1.1

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

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

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

Под бизнес-процессом базового уровня понимается последовательность взаимосвязанных процедур, которые выполняются разными исполнителями и приводят к законченному и значимому результату для организации. К примеру, заключенный договор, акт сдачи-приемки Ильин В.В. , Реинжиниринг бизнес-процессов с использованием ARIS, - М.: - Вильямс, 2009. - С. 120.

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

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

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

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

Основной задачей управления бизнес-процессами является адекватное и быстрое перестроение взаимосвязанных процессов в зависимости от изменяющихся параметров внешней и внутренней среды, будь то поставки, расчеты с контрагентами или расширение рынка Практическое руководство по реинжинирингу бизнес-процессов, Майк Ротер, Джон Шук. - HE LEAN ENTERPRISE INSTITUTE, США, 2009. - С. 42.

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

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

Этап 1. Становление организации и освоение рынка.

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

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

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

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

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

Этап 2. Рост организации.

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

Основные задачи при организации управления:

Организация делегирования полномочий руководителя;

Сохранение пропорций между ростом численности персонала и ростом выручки;

Поиск резервов снижения себестоимости из-за повышения конкуренции;

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

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

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

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

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

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

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

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

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

Для организации системы управления, которая базируется на процессном подходе, следует пройти ряд этапов (рисунок 1.2).

Рис.1.2

Этап 3. Развитие сетевой структуры, открытие новых представительств, филиалов.

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

Основные задачи при организации управления:

Разработка формализованной технологии открытия новых подразделений;

Организация контроля всех аспектов деятельности филиалов Рыбаков М. Как навести порядок в своем бизнесе. Как построить надежную систему из ненадежных элементов. Практикум. - М: "Издательство ИКАР", 2011. - С. 217.

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

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

Зачастую при этом в комплексе используются следующие инструменты:

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

Адаптивная и отвечающая требованиям внешней среды оптимальная структура;

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

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

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

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

В сегодняшней статье мы ответим на 3 вопроса, которые задают себе руководители крупных компаний:

Что дает процессный подход крупному бизнесу?

С чего начать построение системы управления бизнес-процессами?

Для чего строить систему управления бизнес-процессами?

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

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

Взгляд на процессы позволяет:

Уровни зрелости бизнес-процессов

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

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

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

Основные процессы – суть деятельности компании. Процессы, которые приносят деньги.

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

Кроме этого, важно понимать, что у каждого процесса существуют уровни зрелости:

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

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

Уровень 3 (автоматизированный, измеримый). Процесс, либо его часть, автоматизирован в ИТ-системе (SAP, 1С, Oracle, Axapta, Галактика, Парус и т.д.)

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

Уровень 5. Развитие процессов связано со стратегией компании.

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

Уровень зрелости 2

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

Уровень зрелости 3

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

На этом этапе компания может столкнуться с рядом сложностей:

Внедрение классических ИТ-систем для автоматизации бизнес-процессов в формате «бери и используй» не удовлетворяют потребностям предприятия.

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

Метрики процесса остаются за рамками проекта внедрения.

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

В автоматизированной системе процесс «цементируется» и не меняется годами.

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

Таким образом, мы коротко рассмотрели два базовых уровня зрелости бизнес-процессов – регламентацию и автоматизацию. Как правило, в крупном бизнесе большая часть процессов находится именно на этих уровнях. Однако основная работа с процессами начинается дальше. Управление процессами – не просто автоматизация. Его основная цель – осознанное изменение и улучшение бизнес-процессов для достижения большей эффективности. И управленцу нужно четко понимать, какие процессы с уровня 2, а тем более с уровня 3, переводить на следующие уровни зрелости.

С каких процессов начать?

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

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

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

В ходе развития компании не стоит браться за все процессы организации сразу. Их может быть очень много, и они имеют разную ценность для предприятия. Пусть менее ценные пока останутся на бумаге, а вот значимые процессы стоит переводить на 4 уровень зрелости. Это позволит понять их КПД, и решить, как можно улучшить ценный для компании бизнес-процесс.

Система управления бизнес-процессами концентрируется именно на 4 и 5 уровнях зрелости. Если в компании есть ERP либо учетная система, это хорошо, но это только часть управления процессами предприятия. Основная задача системы управления бизнес-процессами – развитие процессов, которое позволяет увеличить экономический потенциал с операционной и стратегической точек зрения.

Система управления процессами предприятия

Система управления бизнес-процессами должна охватывать 4 уровня работы компании. Только в этом случае она будет работать.

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

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

Разумеется, процессы должны исполняться.

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

Уровень управления процессами

Управление любым бизнес-процессом компании предполагает контроль метрик и показателей его продуктивности.

Например, в процессе «Обработка заказа клиента» можно выделить следующие метрики и показатели:

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

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

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

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

Таким образом, развитие процессов до 4 и 5 уровней зрелости, на которое ориентирована система управления бизнес-процессами – не просто автоматизация исполнения. Нам нужно знать текущие метрики и KPI бизнес-процессов, чтобы понимать, как развивать процессы для достижения стратегических целей компании. Оперативно вносить изменения и отслеживать результаты.

Уровень исполнения процессов (автоматизация)

На уровне исполнения бизнес-процессов встречаются три возможных сценария развития событий:

Для чего устранять лоскутную автоматизацию и переводить процесс в BPMS?

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

Когда высшее руководство ставит задачу по совершенствованию работы компании – например, снизить количество брака, владелец процесса транслирует эту задачу ниже:

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

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

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

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

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

Аннотация: Принципы создания информационной системы. Реинжиниринг бизнес-процессов. Отображение и моделирование процессов. Обеспечение процесса анализа и проектирования ИС возможностями CASE-технологий. Внедрение информационных систем.

4. Разработка и внедрение информационной системы

4.1. Принципы создания информационной системы

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

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

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

Принцип "открытости" информационной системы

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

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

Это определение, сформулированное специалистами института IEEE (Institute of Electrical and Electronic Engineers), унифицирует содержание среды, которую предоставляет открытая система для широкого использования. В настоящее время общепризнанным координационным центром по разработке и согласованию стандартов открытых систем является OASIS (Organization for the Advancement of Structured Information Standards).

Общие свойства открытых информационных систем можно сформулировать следующим образом:

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

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

Структура среды информационной системы

Обобщенная структура любой ИС может быть представлена двумя взаимодействующими частями:

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

С этим разделением тесно связаны две группы вопросов стандартизации:

• стандарты интерфейсов взаимодействия прикладных программ со средой ИС, прикладной программный интерфейс (Application Program Interface - API);
• стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface - EEI).

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

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

Эта модель используется более 20 лет и определяется системной сетевой архитектурой (SNA), предложенной IBM в 1974 году. Она основана на разбиении вычислительной среды на семь уровней, взаимодействие между которыми описывается соответствующими стандартами, и обеспечивает связь уровней вне зависимости от построения уровня в каждой конкретной реализации (рис. 4.1). Основным достоинством этой модели является детальное описание связей в среде с точки зрения технических устройств и коммуникационных взаимодействий. Вместе с тем она не принимает в расчет взаимосвязь с учетом мобильности прикладного программного обеспечения.

Рис. 4.1.

Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизованные интерфейсы (API), которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды ИС.

Более подробно о применении технологии и моделей открытых систем будет рассказано в "лекции 18" .

Модель создания информационной системы

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

Компания является сложной онтологической (понятийной) структурой, состоящий из определенной совокупности сущностей и взаимосвязей (рис. 4.2).

Рис. 4.2.

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

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

• основные цели бизнеса, которые можно достичь посредством автоматизации процессов;
• перечень участков и последовательность внедрения модулей ИС;
• фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;
• реальные оценки сроков развертывания и запуска ИСУ;
• ключевых пользователей ИС и уточненный список членов команды внедрения;
• степень соответствия выбранного вами прикладного программного обеспечения специфике бизнеса вашей компании.

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

• бизнес-функции, описывающие ЧТО делает бизнес;
• основные, вспомогательные и управленческие процессы, описывающие КАК предприятие выполняет свои бизнес-функции;
• организационно-функциональную структуру, определяющую ГДЕ исполняются бизнес-функции и бизнес-процессы;
• фазы, определяющие КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
• роли, определяющие КТО исполняет бизнес-функции и КТО является "хозяином" бизнес-процессов;
• правила, определяющие связь и взаимодействие между всеми ЧТО, КАК, ГДЕ, КОГДА и КТО.

После построения бизнес-модели (или параллельно с этим) можно приступать к формированию модели проектирования, реализации и внедрения самой ИС (рис. 4.3).

Рис. 4.3.

Опыт создания и использования "заказных" ИС позволяет условно выделить следующие основные этапы их жизненного цикла:

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

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

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

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

Разработка перечисленных выше спецификаций при создании ИС, предназначенной для автоматизации управленческих процессов, в общем случае проходит четыре стадии.

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

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

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

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

Заканчивается процесс (четвертая стадия) разработкой "Карты автоматизации", представляющей собой модель реорганизованной предметной области, на которой обязательно обозначены "границы автоматизации".

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

Рис. 4.5.

На стадии анализа требований к проектируемой системе и вводятся:

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

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

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

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

Производительность и надёжность являются главными факторами, определяющими эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

• проектирование структур данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• проектирование конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры, параллельной обработки, распределенной обработки данных и т. п.

На основе результатов системного анализа на стадии предварительного проекта разрабатываются:

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

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

На стадии детального проектирования разрабатываются:

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

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

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

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

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

4.2. Реинжиниринг бизнес-процессов

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

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

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

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

Рис. 4.6.

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

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

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

Существует несколько базовых правил, которых следует придерживаться в процессе проведения реинжиниринга:

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

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

Рис. 4.7.

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

• Какие новые вызовы предъявляют нам изменившиеся условия бизнеса?
• Что представляет предприятие сейчас, и что мы хотим от него в будущем?
• Каких именно потребителей мы обслуживаем, насколько мы удовлетворяем их требования и ожидания, и что нужно сделать для привлечения новых?
• Какие именно показатели определяют эффективность деятельности предприятия, производительность труда и качество продукта, является ли это определение полным и адекватным?
• Какие именно информационные технологии и средства помогут нам в этом?

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

Рис. 4.8.

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

Результатом такого описания является:

• уточненная карта сети процессов;
• матрица взаимосвязей процессов и подразделений, вовлеченных в эти процессы;
• информация о том, какие системы автоматизации существуют, при выполнении каких операций используются, где и какие данные используются, какие системы автоматизации и информатизации необходимо разработать;
• функциональные схемы потоков данных (Data Flow), работ (Work Flow), финансовых потоков (Cash Flow), потоков управленческих воздействий (Control Flow) и документооборота (Doc Flow).

Функциональная модель поможет составить точные спецификации всех операций, процедур и взаимосвязей между ними. Такая модель, если она построена правильно, обеспечивает исчерпывающее описание о функционирующем процессе и обо всех имеющихся в нем потоках информации. Эта модель описывает состояние "Как есть" (As Is). По результатам анализа возможных путей улучшения от реальной модели нужно перейти к модели, характеризующей улучшения - модель "Как будет" (As To Be), вариант - "Как должно быть" (рис. 4.9).

Рис. 4.9.

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

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

Таблица 4.1. Основные этапы реинжиниринга

Этап	Мероприятия
Планирование и начало работ	Выявление главных причин проведения реформы на предприятии и оценка последствий отказа от такой реформы
	Выявление важнейших процессов, требующих реинжиниринга
	Выявление единомышленников среди руководства и создание рабочей группы из представителей администрации
	Обеспечение поддержки проекта руководством
	Подготовка плана проекта: определение объема, обозначение измеримых целей, выбор методологии, составление подробного графика
	Согласование целей и объемов проекта с руководством
	Формирование группы реинжиниринга
	Выбор консультантов или внешних экспертов
	Проведение вводного совещания
	Доведение целей проекта до руководителей низшего звена; начальное информирование всей организации
	Обучение группы реинжиниринга
	Подготовка плана и начало работ
Исследования	Аналитическое исследование опыта компаний с подобными процессами
	Опрос клиентов и контрольных групп для выявления существующих и будущих требований
	Опрос служащих и руководителей для выявления вопросов; мозговой штурм
	Поиск в литературе и прессе данных о тенденциях в отрасли и о чужом опыте
	Оформление подробных документов на исходные процессы и сбор рабочих данных; выявление недоработок
	Обзор изменений и вариантов технологий
	Опрос владельцев и представителей руководства
	Посещение кружков и семинаров
	Сбор данных от внешних экспертов и консультантов
Проектирование	Мозговой штурм и выработка новаторских идей; упражнения по творческому мышлению, чтобы "снять шоры"
	Проработка сценариев "а что, если?" и применение "шаблонов успеха" других компаний
	Создание при помощи специалистов 3-5 моделей; разработка комплексных моделей, в которых собрано лучшее от каждой из предыдущих
	Создание картины идеального процесса
	Определение моделей нового процесса и их графическое представление
	Разработка организационной модели в сочетании с новым процессом
	Определение технологических требований; выбор платформы для новых процессов
	Выделение краткосрочных и долгосрочных мер
Утверждение	Анализ затрат и преимуществ; расчет прибыли на капитал
	Оценка влияния на клиентов и служащих; оценка влияния на конкурентоспособность
	Подготовка официального документа для высшего руководства
	Проведение обзорных совещаний для ознакомления и утверждения деталей проекта оргкомитетом и высшим руководством
Внедрение	Завершение подробной разработки процессов и организационных моделей; определение новых рабочих обязанностей
	Разработка систем поддержки
	Реализация предварительных вариантов и первичные испытания
	Ознакомление работников с новым вариантом; разработка и осуществление плана реформы
	Разработка поэтапного плана; внедрение как таковое
	Разработка плана обучения; обучение работников новым процессам и системам
Последующие мероприятия	Разработка мероприятий по периодической оценке; определение итогов нового процесса; внедрение программы непрерывного совершенствования нового процесса
	Предоставление окончательного отчета оргкомитету и администрации

4.3. Отображение и моделирование процессов

На сегодняшний день получили распространение три основные методологии функционального моделирования (и сопутствующий им инструментарий): IDEF (Integrated DEFinition), UML (Unified Modeling Language) и ARIS (Architecture of Integrated Information Systems). Для каждой из них существуют определенные программные продукты, которые помимо разработки позволяют проводить преобразования и операции для последующей работы с полученными моделями. Наибольшее распространение сегодня получили методологии IDEF и программный продукт BPWin, содержащий методологии IDEF0, IDEF3, DFD (Data Flow Diagrams) и ERWin (IDEF1x) от компании Computer Associates.

История методологии IDEF начинается с 70-х годов ХХ века с методологии SADT (Structured Analysis and Design Technique), разработанной Дугласом Россом (Softtech INC). Изначально SADT применялось Министерством Обороны США для практического моделирования процессов в рамках программы ICAM (Integrated Computer Aided Manufacturing). Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами - участниками программы ICAM (Icam DEFinition). В последующем эта методология была трансформирована в стандарт IDEF0 (Function Modeling, FIPS № 183). Семейство IDEF включает уже упомянутые IDEF3 (Process Description Capture) и IDEF1x (Data Modeling, FIPS № 184).

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

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

Работа с использованием метода IDEF начинается с постановки цели моделирования. Мировой опыт свидетельствует, что ошибки при постановке цели приводят в среднем к 50 % неудач в процессе моделирования. Формулирование цели изначально направляет работу в заданном направлении, а значит, ограничивает круг вопросов для анализа. Практическая работа начинается с определения контекста (Context, Context Diagram), то есть верхнего уровня системы, в нашем случае - предприятия. После формулировки цели необходимо очертить область моделирования (Scope), которая в последующем будет определять общие направления движения и глубину детализации (Decomposition). Собственно, сама методология IDEF определяет стандартизированные объекты для работы и отображения. Например, к таковым относятся функция (Activity), интерфейсная дуга (Arrow), заметка (Note) а также способ их расположения и трактования (Semantics).

В последнее время на российском рынке появился программный продукт Business Studio, который специально создан для работы с методами IDEF и обладает интуитивным и дружественным интерфейсом (User-friendly Interface).

Рис. 4.10.

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

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

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

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

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

Пример функциональной модели процесса отгрузки и доставки продукции показан на рис. 4.11 .

Степень формализации описания бизнес-процессов может быть различной в зависимости от решаемых при этом задач. Для описания информационных процессов разработан специализированный язык BPEL (Business Process Execution Language). BPEL создан на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия Web-служб и включает в эту модель поддержку транзакций.

В настоящее время активно развивается методология BPMS (Business Process Management System) - класс программного обеспечения для управления бизнес-процессами и административными регламентами. (Употребляются также термины BPM-система и просто BPM). Использование BPMS позволяет организовать эффективное взаимодействие между управленцами и ИТ-специалистами, лучше использовать существующие подсистемы и ускорить разработку новых.

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

Современные методы разработки и развития программного обеспечения ИС в полной мере стараются ориентироваться на возможности автоматизированного оперативного внесения изменений. Наиболее сложным оказался процесс стандартизации языка BPEL для унификации использования одних и тех же конструкций программным обеспечением разных производителей. Фирмы IBM и Microsoft определили два довольно-таки схожих языка: WSFL (Web Services Flow Language) и Xlang, соответственно.

Рост популярности BPML и открытое движение BPMS к пользователям привело корпорации Intalio Inc., IBM и Microsoft к решению объединить эти языки в новый язык BPEL4WS. В апреле 2003 года корпорации BEA Systems, IBM, Microsoft, SAP и Siebel Systems передали BPEL4WS версии 1.1 в OASIS для стандартизирования в Web Services BPEL Technical Committee. Хотя BPEL4WS появился в версиях 1.0 и 1.1, технический комитет WS-BPEL OASIS проголосовал 14 сентября 2004 за то, чтобы назвать спецификацию WS-BPEL 2.0. Это изменение было сделано, чтобы согласовать BPEL с другими стандартами Web-сервисов, которые на основании "Соглашения об именовании" начинаются сочетаниями букв "WS-".

Корпорации Active Endpoints, Adobe, BEA, IBM, Oracle и SAP опубликовали согласованные спецификации BPEL4 People и WS-HumanTask, в которых описывалось, как может быть реализовано в системе и нотациях BPEL взаимодействие процессов с людьми. Предполагается добавление в BPEL семантики в форме WS-HumanTask и других разнообразных дополнений.

4.4. Обеспечение процесса анализа и проектирования ИС возможностями CASE-технологий

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

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

Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, средств визуального моделирования и проектирования на базе языка UML (Unified Modeling Language), средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т. д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:

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

CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств [Вендров А. М. ,www.citforum. ru/database/case/index.shtml ].

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

Большинство CASE-средств основано на парадигме "методология/метод/нотация/структура/средство".

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

Метод - систематическая процедура или технология генерации описаний компонент ПО (например, описание потоков и структур данных).

Нотации предназначены для описания системы в целом, ее элементов: графы, диаграммы, таблица, блок схемы, алгоритмы, формальные языки и языки программирования.

Структуры являются средством для реализации структурного анализа и построения структуры конкретной системы.

Средства - технологические и программные инструменты для поддержки и усиления методов.

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

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

Следует отметить, что, несмотря на все потенциальные возможности CASE-средств, существует достаточно много примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (Shelfware).

В связи с этим необходимо учитывать следующее:

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

Можно также перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств:

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

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

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

1. Проведение функционального и информационного обследования системы управления (административно-управленческой деятельности) предприятия (рис. 4.2):
   • определение организационно-штатной структуры предприятия;
   • определение функциональной структуры предприятия;
   • определение перечня целевых функций структурных элементов (подразделений и должностных лиц);
   • определение круга и очередности обследования структурных элементов системы управления согласно сформулированным целевым функциям;
   • обследование деятельности выделенных структурных элементов;
   • построение FD-диаграммы системы управления с указанием структурных элементов и функций, реализация которых будет моделироваться на DFD-уровне.
2. Разработка моделей деятельности структурных элементов и системы управления в целом:
   • выделение множества внешних объектов, оказывающих существенное влияние на деятельность структурного элемента;
   • спецификация входных и выходных информационных потоков;
   • выявление основных процессов, определяющих деятельность структурного элемента и обеспечивающих реализацию его целевых функций;
   • спецификация информационных потоков между основными процессами деятельности, уточнение связей между процессами и внешними объектами;
   • оценка объемов, интенсивности и других необходимых характеристик информационных потоков;
   • разработка иерархии диаграмм потоков данных, образующих функциональную модель деятельности структурного элемента;
   • объединение DFD-моделей структурных элементов в единую модель системы управления предприятием.
3. Разработка информационных моделей структурных элементов и модели информационного пространства системы управления:
   • определение сущностей модели и их атрибутов;
   • проведение атрибутного анализа и оптимизация сущностей;
   • идентификация отношений между сущностями и определение типов отношений;
   • анализ и оптимизация информационной модели;
   • объединение информационных моделей в единую модель информационного пространства.
4. Разработка предложений по автоматизации системы управления предприятия:
   • определение границ автоматизации - составление перечня автоматизируемых структурных элементов, разбиение процессов основной деятельности на автоматические, автоматизированные и ручные;
   • составление перечня подсистем и логических АРМов (автоматизированных рабочих мест), определение способов их взаимодействия;
   • разработка предложений по очередности проектирования и реализации подсистем и отдельных логических АРМов, входящих в состав ИС;
   • разработка требований к средствам базового технического обеспечения ИС;
   • разработка требований к средствам базового программного обеспечения ИС.

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

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

Рис. 4.12.

Построенная модель является законченным результатом по следующим причинам.

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

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

Paradigm Plus - моделирование приложений и генерация объектного кода;

Rational Rose - моделирование бизнес-процессов и компонентов приложений

Rational Suite AnalystStudio - пакет для аналитиков данных;

Oracle Designer (входит в Oracle9i Developer Suite) - высоко функциональное средство проектирования программных систем и баз данных, реализующее технологию CASE и собственную методологию Oracle - CDM. Позволяет команде разработчиков полностью провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Сложное CASE-средство, имеет смысл использовать при ориентации на линейку продуктов Oracle.

Самым мощным из указанных программных пакетов является пакет Rational Rose (RR) компании IBM-Rational, с помощью которого можно спроектировать и сопровождать весь жизненный цикл разработки программного продукта (рис. 4.15 Рис. 4.16. Сопровождение ЖЦ программного продукта с RR

4.5. Внедрение информационных систем

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

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

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

Следуя этой логике, становится понятно, что хотя корпоративная ИС предназначена в целом для обеспечения всех пользователей необходимой информацией, управление разработкой и внедрением КИС является прерогативой высшего руководства компании! Понимают ли это руководители?

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

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

К настоящему времени сложился стандартный набор приемов внедрения ИС. Основное правило: выполнять обязательные фазы последовательно и не пропускать ни одной из них.

Критически важными для внедрения являются следующие факторы:

• наличие четко сформулированных целей проекта и требований к ИС;
• наличие стратегии внедрения и использования ИС;
• проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";
• планирование работ, ресурсов и контроль выполнения плана внедрения;
• участие высшего руководства во внедрении системы;
• проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;
• регулярный мониторинг качества выполняемых работ;
• быстрое получение положительных результатов хотя бы в части внедренных модулей ИС или в процессе её опытной эксплуатации.

Перед началом разработки проекта внедрения необходимо:

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

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

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

Кроме того, что перечислено выше, надо задать технологические требования к внедрению ИС:

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

Основные фазы внедрения информационной системы

Фаза "Предварительные работы по подготовке проекта внедрения ИС". В ходе предпроектного обследования предприятия (рис. 4.1.4) собирается подробная информация о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимая для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза "Подготовка проекта". После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

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

Последний очень важный момент почему-то часто пропускается при составлении плана внедрения. А ведь от него в огромной степени зависит успех всего проекта! После начала финансирования проект считается запущенным к исполнению.

Фаза "Концептуальная проработка проекта". В течение этой фазы:

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

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

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

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

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

Главные цели управления бизнес процессами

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

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

1. Моделирование процесса;
2. Создание;
3. Улучшение.

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

Этап создания всегда оказывается самым затратным. Здесь происходит создание и внедрение тех идей, на определенные которых направлен первый этап. Самый ответственный этап – сопоставление реальной ситуации с тем, что было в планах. Приведение реальности как можно ближе к «идеальной» ситуации, которая описана на бумаге.

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

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

Современные методы совершенствования бизнес процессов

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

• Быстрое принятие решений;
• Инжиниринг;
• Реинжиниринг;
• Перепроектирование определенного процесса;
• Бенчмаркинг.

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

Быстрое принятие решений

Данную методику можно свести к словосочетанию «Мозговой штурм». Группа аналитиков ставит перед собой задачу улучшить работу определенного процесса на короткий срок – до 90 дней. Обычно на то, чтобы придумать рабочий метод уходит совещание, которые продолжается 1-2 рабочих дня. Руководство может как одобрить такое решение, так и отклонить. Из плюсов можно выделить оперативное принятие решение.

Минус – решение только локальных проблем. Чаще всего лечится далеко не сама причина, а лишь её последствия. Такой способ подойдет для консервативных организаций, которые не хотят чего-либо существенно менять

Бенчмаркинг

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

Перепроектирование процесса

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

Инжиниринг

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

Реинжениринг

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

Перепроектирование процесса

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

Актуальность процесса совершенствования

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

Для новой компании, совершенствование – отличный способ заявить о себе. Ведь то, что постоянно меняется, следуя за рынком, неизменно идет на волне популярности.

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

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

Независимо от размера фирмы, постоянное совершенствование бизнес процессов – залог успешного развития и постоянного получения прибыли.

Рабочие программы для совершенствования бизнес процессов

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

Aris Express

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

Business studio

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

Fox Manager

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

Существует множество программ вроде IBM business modeler, elma и прочих, которые также позволяют выполнять схожие задачи. Но они не настолько просты, и для работы потребуются специалисты, которые ранее осуществляли деятельность в этих программах.

В общем и целом, для тех, кто хочет постоянного совершенствования, быть активным и конкурентоспособным, подходит только путь постоянного совершенствования. А как его осуществлять – решать только руководству и сотрудникам компании.

Вконтакте