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

СОКРАТИТЬ ДО 2-3 СТРАНИЦ, ДОБАВИТЬ ПРИМЕНЕНИЕ В ГОССЕКТОРЕ (КАНАДА, ВЕЛИКОБРИТАНИЯ, ГЕРМАНИЯ). ВЫВОД О ПЕРЕХОДЕ К ORGWARE ВМЕСТО МОДЕЛИРОВАНИЯ ИСКЛЮЧИТЕЛЬНО ПРОЦЕССОВ. РАСШИРИТЬ ОПИСАНИЕ Casewise

Задачи моделирования решаются инструментами бизнес-моделирования и анализа. Таких инструментов в мире имеется достаточно много, причем они все они обладают различной функциональностью и используют различные методологии. Среди лидеров по функциональности и возможностям полноты описания Gartner выделяет несколько инструментов, из которых на российском рынке представлены только продукты компаний IDS Scheer и Casewise, помимо этих продуктов, хотелось бы отметить менее мощные, по мнению Gartner, но известные на рынке инструменты компаний Computer Associates и Microsoft. Наиболее интересной и значимой частью любого инструмента является его методология. Следует отметить, что инструмент MS Visio компании Microsoft является чисто графическим инструментом, не имеющим методологии, поэтому он не рассматривается далее.

Продукты Computer Associates поддерживают стандарты семейства IDEF, компания IDS Scheer предлагает собственную методологию описания – методологию ARIS, разработанную проф. Шером, Corporate Modeler компании Casewise использует известную методологию Захмана. Также стоит отметить нотацию UML, которая также представляет интерес для решения определенного круга задач.

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

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

Перечислим также и другие требования:

· Методология должна обеспечивать полноту моделирования, включать четкие правила деления модели по уровням детализации и правила связи между ними;

· Большим плюсом являлось бы наличие возможности создания диаграмм Ганта для визуализации сетевого графика работ административно-управленческого процесса;

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

· Несомненным преимуществом являлась бы возможность поддержки процессов управления требованиями;

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

· Инструментальная среда должна обеспечивать возможности проведения определенного рода анализов модели;

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

Остановимся на каждом требовании из вышеперечисленных подробнее.

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

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

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

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

Уже упоминалось, что не стоит забывать о нотации UML, которая является особенно удобной для использования при проектировании информационных систем. Помимо этого, с помощью методологии UML можно также проводить оптимизацию использования ресурсов. Поэтому инструментальные среды ARIS (IDS Scheer) и Corporate Modeler (Casewise), в отличие от Bpwin[1], поддерживают возможность создания диаграмм, в соответствии с нотацией UML.

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

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

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

Модель в свою очередь включает в себя большой объем информации, полезной для управления требованиями, поэтому Casewise и ARIS имеют средства интеграции с системами управления требованиями, такими как Rational Requisite Pro, Telelogic DOORS.

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

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

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

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

· Сбор исходных данных, необходимых для модели;

· Построение адекватной модели;

· Подготовка модели к динамическому моделированию, т.е. заполнение атрибутов объектов модели;

· Проведение динамического моделирования;

· Анализ результатов.

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

· Среднее время подготовки;

· Среднее время обслуживания работы;

· Количество используемых ресурсов;

· Количество сотрудников, требуемых для выполнения работы;

· Прямые и косвенные затраты для каждой функции;

· Минимальная партия работ, необходимая для инициации работы функции;

· Максимальная партия работ, которую может обслужить функция;

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

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

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

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

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

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

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

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

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

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

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

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

Настоящая Концепция основана на принципиальном отличии принципов управления в государственном и частном секторах.

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

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

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

Вставка 1.

Зарубежные исследователи Олсон и Марч[2] выделили два принципа архитектуры органов власти: административные ценности и политические соображения. В первом случае отталкиваются от соображений эффективности, отзывчивости и результативности, во втором – руководствуются соображениями текущего политического момента. Как правило, структура является балансом риторики эффективности и политической риторики. Однако, в случае реализации четких критериев классификации административно-управленческих процессов органов исполнительной власти, влияние политической риторики будет ограничено: приоритетным будет преследование целей эффективности и результативности.

В Российской Федерации при организационном проектировании доминируют соображения политической ситуации. Органы власти создаются или преобразовываются под конкретных лиц. В этом случае они являются либо «площадками подскока», либо «политическим домом престрарелых», где тот или иной чиновник может спокойно доработать до пенсии. Таким образом, отсутствие четких критериев облегчает незаконное влияние частных интересов при построении системы органов исполнительной власти и дальнейшем её функционировании. В данном контексте интересно мнение заместителя руководителя федерального ведомства России. Отвечая на вопрос «Кем и как принимаются решения о создании новых структур в госаппарате?[3]», бывший высокопоставленный чиновник заявил: «Я думаю, что подобные решения (решения в отношении создания, реорганизации структур ОИВ) относительно большинства структур - результат лоббирования. Например, Росспецстрой - Федеральное управление специального строительства. Есть такая, на мой взгляд, совершенно ненужная структура. При Кириенко решили его ликвидировать, и был соответствующий указ президента, и нет никаких причин, никаких функций госуправления, которые бы оправдывали ее существование. Какие-то предприятия были ему переданы, которыми майоры и полковники совершенно не умеют управлять. Но при Примакове эта структура была частично воссоздана - как Федеральное управление специального строительства при Госстрое. А сейчас оно опять появилось как отдельная структура. То есть тот указ президента был забыт, и появилась новая структура. Что это? Результат лоббирования».