Заказ работы

Заказать
Каталог тем

Самые новые

Значок файла SQL: SELECT-ЗАПРОСЫ -АГРЕГИРОВАНИЕ И ГРУППОВЫЕ ФУНКЦИИ Методические рекомендации к лабораторной работе по курсу «Автоматизированные информационно-управляющие системы» для студентов специальности 2101 по направлению Т-02 (6)
(Методические материалы)

Значок файла SQL: ИЗВЛЕЧЕНИЕ ДАННЫХ - команда SELECT Методические рекомендации к лабораторной работе по курсу «Автоматизированные информационно-управляющие системы» для студентов специальности 2101 по направлению Т-02 (8)
(Методические материалы)

Значок файла Основы архитектурно-конструктивного проектирования Часть 2 «Основы архитектурного проектирования» (5)
(Методические материалы)

Значок файла Осипов Ю.К. Архитектурные конструкции. Часть I. Фундаменты. Учебное посо-бие / СибГИУ, Новокузнецк, 2003 – 130 стр. (6)
(Методические материалы)

Значок файла Ряды: методические указания /Сост.: М.С.Волошина, С.Ф.Гаврикова: СибГИУ. – Новокузнецк, 2005. – 42 с. (16)
(Методические материалы)

Значок файла Пределы: Метод. указ./ Составители: С.Ф. Гаврикова, И.В. Касымова.–Новокузнецк: ГОУ ВПО «СибГИУ», 2003. (12)
(Методические материалы)

Значок файла Предел. Непрерывность: Метод. указ. / Сост.: Л.А. Кильман: СибГИУ. – Новокузнецк, 2005. - с. (12)
(Методические материалы)

Каталог бесплатных ресурсов

Куда делся руководитель

Куда делся руководитель?


В.В. Репин, к.т.н., руководитель Отдела Консалтинга \\ Консалтинговая компания «TENGRY group». Аналитический обзор посвящен вопросам формирования моделей бизнес-процессов, используемых для регламентации и управления. Рассматривают проблемы, связанные с описанием бизнес-процессов в виде потоков работ (Work flow). При построении таких моделей особенно остро встает вопрос описания деятельности руководителя (владельца процесса).  Модели потоков работ (ARIS eEPC, IDEF3, блок схемы в Visio) предназначены для подробного описания операций (работ), выполняемых последовательно во времени по определенной технологии. Эти модели (нотации), особенно ARIS eEPC, активно используются в настоящее время на практике. Крупнейшие российские компании приобрели систему ARIS Toolset и занимаются описанием бизнес-процессов, в основном, в нотации eEPC. Другие компании ориентируются на IDEF3 и систему BPWin. На практике возникает ряд проблем, связанных с применение указанных моделей, которые целесообразно разделить на две группы:1)     проблемы, связанные с отсутствием понимания сути процесса и процессного подхода и, как следствие, некорректная постановка задачи описания процессов с использованием потоковых диаграмм;2)     неумение эффективно использовать сами модели при описании бизнес-процессов.Когда в организации бизнес-процесс понимается как плоская графическая схема, дело внедрения процессного подхода (описания, реорганизации и управления процессами), без сомнения, обречено на неудачу. В своей практике процессного консалтинга мы наблюдаем много таких примеров. В чем же основная проблема, как эффективно описывать и регламентировать бизнес-процесс, как отобразить в модели деятельность руководителей? В этом обзоре мы коснемся только одного аспекта, связанного с созданием моделей процессов, учитывающих деятельность руководителей. В последующих статьях будет подробно раскрыт комплексный подход к описанию, регламентации и управлению процессами.Что значит фраза «описать бизнес-процесс», что кроется за  этой краткой формулировкой? Прежде чем дать ответ на этот вопрос, отметим, что схемы процессов рассматриваются нами в качестве одного из  необходимых элементов описания процессов, но далеко на самого важного. Для целей дальнейшего изложения сделаем несколько необходимых определений. Бизнес-процесс -  устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя. Владелец бизнес-процесса – должностное лицо, которое имеет в своем распоряжении персонал, инфраструктуру, программное и аппаратное обеспечение, информацию о бизнес-процессе, управляет ходом бизнес-процесса и несет ответственность за результаты и эффективность бизнес-процесса. Вход бизнес-процесса – ресурс, необходимый для выполнения бизнес-процесса.Выход бизнес-процесса – результат (продукт, услуга) выполнения бизнес-процесса.Модель – графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность.Поставщик -  субъект, предоставляющий ресурсы.  Потребитель (клиент) – субъект, получающий результат бизнес-процесса. Потребитель может быть:а) внутренний – то есть находящийся в организации и, в ходе своей деятельности, использующий результаты (выходы) предыдущего бизнес-процесса; б) внешний – то есть находящийся за пределами организации и использующий или потребляющий результат деятельности (выход) организации.Операция (работа) – часть бизнес-процесса.Регламент  бизнес-процесса  документ, описывающий последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по улучшениям.Ресурсы – информация (документы, файлы), финансы, материалы, персонал, оборудование, инфраструктура, среда, программное обеспечение, необходимые для выполнения бизнес-процесса.Функция – направление деятельности элемента организационной структуры, представляющие собой совокупность однородных операций, выполняемых на постоянной основе.IDEF 0 –FIPS 183 США «Integration definition for function modeling (IDEF0)» – «Интеграционное определение для моделирования функций»IDEF 3 –  (workflow modeling, Рrocess Description Capture Method) методология описания бизнес-процессов (потоков работ). Наше определение бизнес-процесса основано на определении, сформулированном в стандарте ISO-9001:2000. Мы считаем, что это наиболее адекватное, практически важное определение. Из него вытекают требования к описанию бизнес-процесса и подходы к его управлению. В нашем понимании описать бизнес-процесса означает:1)    определить владельца бизнес-процесса;2)    определить границы бизнес-процесса (границы ответственности и полномочий владельца процесса по управлению процессом);3)    определить клиентов и выходы бизнес-процесса;4)    определить поставщиков и входы бизнес-процесса;5)    определить ресурсы, необходимые для выполнения бизнес-процесса (- находятся в распоряжении владельца процесса);6)    описать технологию выполнения бизнес-процесса (например, с использованием графических схем в выбранных нотациях);7)    разработать показатели, по которым оценивается бизнес-процесс, его результаты и удовлетворенность клиентов бизнес-процесса;8)    описать работу владельца по анализу и улучшению бизнес-процесса, а так же его отчетность перед вышестоящим руководителем. Управление бизнес-процессом осуществляется по определенным технологиям и с использованием определенных документов, в число которых входят: регламент выполнения бизнес-процесса, положение о подразделении, должностные и рабочие инструкции, методические документы по измерению показателей бизнес-процессов, отчетные формы, спецификации входов/выходов и т.д. (см. рисунок 1). Таким образом, задача регламентации и эффективного управления бизнес-процессом не сводится к разработке только графических схем процессов. Графические схемы (модели) бизнес-процессов являются только частью документации, как правило, несущей информацию по пошаговой технологии выполнения процесса. Важно понимать, что помимо разработки графических схем необходимо выполнить много другой, важной работы по описанию и регламентации процесса.      Обратимся собственно к графическим схемам или, другими словами, моделям бизнес-процессов. В настоящее время для целей описания бизнес-процессов часто используют схемы потоков работ (Work Flow): ARIS eEPC, IDEF3, блок-схемы в Visio или MS Word. В основе указанных подходов лежит принцип построения бизнес-процесса в виде последовательно выполняемых во времени операций (работ), как показано на рисунке 2.Модель потока работ состоит из операций (работ), символов логики, стрелок. Логические символы или, как их принято называть в IDEF3, перекрестки представляют собой логическое «И», логическое «ИЛИ», исключающее «ИЛИ». Они служат для отображения ветвления и слияния процесса. Стрелки могут использоваться для отображения последовательности выполнения операций во времени или потока объектов (документы, ресурсы). В различных подходах (нотациях) в модели потока работ могут отображаться исполнители, документы, используемое оборудование, программные средства и т.д. Суть схем процессов от этого не изменяется – модели остаются плоскими и показывают поток работ, переходящий от одного рабочего места к другому.      При построении моделей потоков работ можно использовать декомпозицию, когда каждая операция описывается более подробно на отдельном листе в виде модели в той же (или другой) нотации. При проведении декомпозиции возникает ряд проблем с увязкой моделей на разных уровнях и моделей в рамках одного уровня. Так как они являются преимущественно техническими,  то рассматриваться в нашем обзоре не будут.      Остановимся на следующем вопросе. Если мы хотим использовать схему бизнес-процесса для регламентации (например, в документе «Регламент выполнения бизнес-процесса»), то эта схема должна удовлетворять следующим требованиям:1)     все отображенные на схеме операции бизнес-процесса должны существовать реально и быть закрепленными за конкретными исполнителями; 2)     на схеме должны отображаться реальные документы, файлы, ресурсы;3)     схема процесса должна быть проста и понятна для визуального восприятия;4)     схема процесса должна иметь компактный размер.     Эти требования означают, что строить потоковую диаграмму имеет смысл при описании операций уровня рабочего места исполнителя, в крайнем случае – для –операций небольшого (3-4 человека) подразделения. На более крупном уровне модели потоков работ могут дать общую информацию о процессе, но использовать такие модели для регламентации затруднительно вследствие размывания ответственности между исполнителями процесса.      Если мы описываем бизнес-процесс на детальном уровне, то на выходе этой работы получаем схемы, содержащие поток операций и их исполнителей. Именно при формировании таких моделей и возникает важнейшая, на наш взгляд, проблема: из рассмотрения полностью исключаются руководители. Возникает следующая ситуация. Группа аналитиков (или внутренних экспертов) приходит в подразделение, получает разрешение руководителя, начинает работать с исполнителями процесса, переходя от одного рабочего места к другому в соответствии с ходом движения бизнес-процесса.     Формируется модель бизнес-процесса, включающая операции всех рядовых исполнителей, но лишенная даже намека на руководителей, владельцев бизнес-процесса. Кроме того, такие модели чаще всего описывают нормальный ход бизнес-процесса. Возможные отклонения очень часто остаются вне рассмотрения. Так же часто опускают такие важные моменты, как: действия при получении не соответствующих входов (например, документ из соседнего подразделения), получение несоответствующих требованиям выходов (брак, недоработка), регистрацию параметров процесса (измерения), контроль и т.д. Нужен ли такой результат работы руководителю? Ответ очевиден. Полученные схемы бизнес-процесса являются плоскими, неполными, не могут эффективно использоваться для внедрения системы процессного управления. Тем не менее, многие компании, особенно крупные, выполняют отдельные проекты по созданию внутренних стандартов моделирования «плоских» бизнес-процессов, «создания баз знаний компании по бизнес-процессам» и т.п. В итоге, полученные «горы» четко структурированной, но «однобокой», неполной информации оказываются практически бесполезными для целей реального управления. На рисунке 3 показан «объемный» бизнес-процесс. Он состоит из нескольких моделей потоков работ, сформированных для каждого уровня: исполнители, зам. руководителя, руководитель (владелец) бизнес-процесса.На рисунке 3 видно, что руководитель и его заместитель активно участвуют в процессе. Существует постоянный, цикличный поток информации по ходу процесса от исполнителей - вверх, и управленческих решений от руководителей - вниз. Даже если (в предельном случае) мы полностью делегируем все права на принятие управленческих решений по процессу исполнителям, у руководителя останется ключевая функция – анализ эффективности бизнес-процесса и его улучшение с ориентиром на стратегические цели компании (если таковые имеются). Улучшение процесса руководитель осуществляет за счет управления ресурсами: персонал, финансы, материалы, оборудование, программное обеспечение, информация и т.д.      Каким же образом увязать деятельность руководителей и исполнителей при построении моделей потоков работ (ARIS eEPC, IDEF3)?  Очевидно, что сделать это можно несколькими способами. Первый и самый простой способ состоит в следующем: отдельно описываются потоки работ, выполняемых как руководителями, так и исполнителями. Такой простейший подход имеет несколько недостатков, основной их которых состоит в том, что взаимодействие руководителя и исполнителя становится в модели неявным, а опосредованным при помощи обратных связей по информации. Другой способ состоит в том, что при описании работ исполнителей можно указать прямые ссылки на процессы, выполняемые руководителями, или прямо отобразить их вмешательство в работу. Сказанное иллюстрирует рисунок 4.На рисунке 4, вверху показана простейшая цепочка бизнес-процесса, состоящая из двух операций. Представим себе, что эти операции выполняются исполнителем и требуют управления со стороны руководителя. Как мы можем отобразить этот факт на модели? Согласно первому предложенному выше способу, мы указываем на модели процесса обратную связь по информации. В данном примере, нотация ARIS eEPC позволяет показать входящий и исходящий документ А, содержащий некоторую информацию. Документ А попадает от исполнителя руководителю после выполнения функции 2, и затем может быть возвращен на доработку при выполнении функции 1. При этом, «где-то в другом месте» мы должны описать работу руководителя по проверке этого документа и принятию решения. Это означает, что мы должны создать модель, описывающую деятельность руководителя. На рисунке 4 приводится еще два способа «встраивания» руководителя в бизнес-процесс. Первый из них предполагает прямое включение в процесс «Функции управления», второй – в виде дополнительного события «Принято управленческое решение». 

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



Размер файла: 59 Кбайт
Тип файла: doc (Mime Type: application/msword)
Заказ курсовой диплома или диссертации.

Горячая Линия


Вход для партнеров