Разработка системы процессов организации (часть 1)

Лекция 26 Разработка системы процессов организации (часть1) Определение системы процессов организации Основные концепции и технологии моделирования бизнес-процессов. Описание процессов с помощью MS Excel Цели разработки системы процессов организации Определение системы процессов организации В лекции 4 рассмотрим методику описания системы процессов организации. Приведем определение системы процессов. Описание системы процессов организации означает создание модели, в которой в структурированном виде представлена информация обо всех процессах организации. Построение системы процессов не означает комплексного описания процедур (алгоритмов) выполнения всех процессов на всех уровнях управления, то есть создания так называемой комплексной модели процессов. Речь здесь идет только о дереве процессов. Для компании среднего размера можно разработать систему процессов за два-три месяца, в то время как описание всех процессов на операционном уровне займет несколько лет (в зависимости от количества выделенных ресурсов), что нецелесообразно. Описывать нужно только те процессы, которые предполагается оптимизировать и регламентировать.[1] Система процессов может быть описана в файле MS Excel или в виде специального справочника в инструментальном средстве моделирования процессов[2]. Как правило, система процессов организации представляет собой иерархический справочник процессов следующего вида: 1. Процессная категория (1-й уровень). 1.1. Процессная группа (2-й уровень). 1.1.1. Процесс (3-й уровень). 1.1.1.1. Операционный процесс (4-й уровень). 1.1.1.1.1. Операция (5-й уровень). 1.1.1.1.1.1. Транзакция (6-й уровень). 1 В табл. 1 представлены основные определения, которые можно использовать при формировании системы процессов организации. Таблица 1.- Определения уровней деятельности в системе процессов организации 2 Рис. 1.- Пример представления системы процессов организации в виде графической схемы 3 Система процессов может строиться сразу в виде иерархического справочника процессов. Другой возможный вариант – описание модели деятельности компании на верхнем уровне в некоторой нотации с последующим представлением в виде иерархического справочника. Если речь идет о построении системы процессов для действующей организации, то полезно разрабатывать систему процессов сразу в виде справочника, не формируя графическую модель верхнего уровня. Форма справочника более понятна большинству руководителей. Далеко не все топ-менеджеры могут воспринимать сложные графические модели структурного типа (например, в нотации IDEF0[3]). Концепция IDEF0 Методология IDEF0 (Integrated Definition Function Modeling) основана на подходе, разработанном Россом (Douglas T.Ross) в начале 70-х годов и получившем название SADT (Structured Analysis & Design Technique, - метод структурного анализа и проектирования) [ 3]. На рисунке 2 представлен пример IDEF0-модели. Рисунок 2 - Пример IDEF0-модели 4 Основу подхода и, как следствие, методологии IDEF0 составляет графический язык моделирования систем, обладающий следующими свойствами: 1. графический язык - полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других процессов и операций предприятия на любом уровне детализации; 2. язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания. 3. язык облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (предприятия); 4. язык может генерироваться рядом CASE-средств, например, BPwin (компания Computer Associates, http://www.ca.com). Эти свойства предопределили выбор методологии IDEF0 в качестве базового средства анализа и синтеза производственно-технических и организационно-экономических систем, что нашло свое отражение в принятии методологии в 1993 г. федеральным стандартом Национальным институтом по стандартам и технологиям США (NIST) [ 4 ]. В 2000 г. методология IDEF0 была использована в нормативном документе Российской Федерации по функциональному моделированию в статусе «Рекомендации по стандартизации» [ 3 ]. Методология положениях: IDEF0 основана на следующих концептуальных Модель - искусственный объект, представляющий собой отображение системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А. Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих элементов, выполняющих некоторую полезную работу. Элементами системы могут быть любые комбинации разнообразных сущностей, включающих людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергоносители. Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит. 5 Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF0 - представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Связи, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась. Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых систем. Итеративное моделирование. Разработка модели в IDEF0 представляет собой итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению и последующему редактированию, после чего цикл повторяется. Отделение «организации» от «функций». При разработке моделей следует избегать изначальной привязки функций исследуемой системы к существующей организационной структуре моделируемого объекта. Организационная структура должна явиться результатом использования модели. Сравнение результата с существующей структурой позволяет: оценить адекватность модели, предложить решения, направленные на совершенствование этой структуры. Смыловые компоненты концепции IDEF0 IDEF0 - это методология функционального моделирования и поэтому имя блока описывающее функцию, должно быть глаголом или глагольным оборотом. Примеры имен функций: производить детали, наблюдать за выполнением. 6 Стрелки и их сегменты помечаются существительными или оборотами существительных. Примеры меток стрелок: менеджер, бюджет. Каждая сторона блока имеет своё определенное значение с точки зрения связи блок-стрелка. Верхняя сторона имеет значение «управление», левая - «вход», правая - «выход», а нижняя - «механизм». В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Пример блока представлен на рисунке 3. Рисунок 3 - Основные компоненты IDEF0 В IDEF0 различают пять классов стрелок - стрелка входа, стрелка выхода, стрелка управления, стрелка механизма, стрелка вызова. Стрелка входа - это материал или данные, которые преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелка входа рисуется как входящая в левую грань блока. Допускается, что функция может не иметь ни одной стрелки входа. Часто бывает сложно определить, являются ли данные входом, или управлением. В том случае, когда данные изменяются или перерабатываются, это вход, если нет управление. 7 Стрелка управления - это правила, стратегии, процедуры, стандарты, которые определяют условия, необходимые функции, чтобы произвести правильный выход. Стрелка управления рисуется как входящая в верхнюю грань блока. Каждая функция должна иметь хотя бы одну стрелку управления. Управление влияет на функцию, но не преобразуется функцией. Если цель функции - изменить процедуру, то такая процедура будет для функции входом. В случае возникновения неопределенности в классифицировании стрелки (вход или управление) рекомендуется создавать стрелку управления. Стрелка выхода - это данные или материальные объекты, произведенные функцией. Стрелка выхода рисуется как выходящая из правой грани блока. Каждая функция должна иметь хотя бы одну стрелку выхода. Функция без выхода не имеет смысла и не должна моделироваться. Стрелка механизма - это ресурсы (персонал, техника, оборудование), поддерживающие выполнение функции. Стрелка механизма рисуется как входящая в нижнюю грань блока. Стрелка механизма может не изображаться на модели. Стрелка вызова - это стрелка, указывающая на другую модель. Стрелка вызова рисуется как исходящая из нижней грани блока. Такая стрелка используется как указание на то, что некоторая функция выполняется за пределами моделируемой системы. IDEF0-модели состоят из трех типов документов: графических диаграмм, текста, глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма - главный компонент модели, содержащий блоки, стрелки, соединения блоков и стрелок. Диаграмма является единицей описания системы и располагается на отдельном листе. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть декомпозированы на составные части и представлены в виде более подробных диаграмм. Процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте. 8 Модель может содержать следующие типы графических диаграмм: контекстная, декомпозиции, дерева узлов, иллюстрации. Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма А-0 устанавливает область моделирования и ее границу. Необходимо установить, что входит в систему, а что лежит за ее пределами, то есть определить, что будет рассматриваться как компоненты системы, а что - как внешнее воздействие. В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы и зафиксирована точка зрения. Цель - это краткая формулировка причины создания модели. Цель должна отвечать на вопросы: Почему этот процесс должен быть смоделирован? Что должна показать модель? Что может получить читатель? Точка зрения - это указание на должностное лицо или подразделение организации, с позиции которого разрабатывается модель. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться. Это связано с тем, что в конечном итоге финансового директора не интересуют аспекты обработки сырья на производственном оборудовании, а главному технологу ни к чему прорисованные схемы финансовых потоков. Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции посредством создания дочерней диаграммы. В свою очередь, каждая из этих подфункций может быть разложена на составные части посредством создания дочерней диаграммы следующего, более низкого уровня. Каждая дочерняя диаграмма содержит дочерние блоки и стрелки, обеспечивающие дополнительную детализацию родительского блока. Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же область, что и родительский блок, но описывает ее более подробно. Таким образом, дочерняя диаграмма как бы вложена в свой родительский блок. 9 Диаграмме может быть поставлен в соответствие текст, представляющий собой краткий комментарий к содержанию диаграммы. Текст не должен использоваться для описания и без того понятных блоков и стрелок на диаграмме. Глоссарий - это список определений для ключевых слов, фраз, аббревиатур, связанных с блоками, стрелками или с моделью в целом. Глоссарий определяет термины, которые должны одинаково понимать все участники разработки. Диаграммы иллюстрации используются в качестве дополнений, поясняющих специфику содержания основных диаграмм, для иллюстрации альтернативной точки зрения. Такие диаграммы могут не подчиняться правилам IDEF0. Диаграммы дерева узлов показывают иерархию функций в модели и позволяют рассмотреть всю её целиком. На диаграммах узлов нет стрелок. Диаграмм узлов может быть в модели сколько угодно, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня. В современном менеджменте известны моделирования бизнес-процессов помимо IDEF0: несколько концепций 1. IDEF1 2. . методика моделирования IDEF1X 3.функциональное моделирование в методике IDEF3 Методология IDEF3 (Integrated Definition Process Description Capture Method) была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Эта методика, в отличии от IDEF0, не стандартизирована. С ее описанием и другими концепциями моделирования можно познакомиться на сайте http://www.idef.com ; 4. IDEF4 5. IDEF5 6. концепция DFD DFD (Data Flow Diagrams) - диаграммы потоков данных - это способ представления процессов обработки информации. Авторы методики Гейн и Сарсон разработали ее независимо от IDEF0. Эта методика, в отличии от IDEF0 не стандартизирована. 10 После того как система процессов в виде иерархического справочника построена, при необходимости могут быть созданы модели деятельности в виде графических схем. На уровнях 1–3 целесообразно использовать структурные типы моделей (например, IDEF0). С уровня 4 (для небольших компаний –с уровня 3), как правило, описание выполняют при помощи схем в формате Work Flow. Удобный способ их визуального представления – кросс-функциональные схемы, содержащие дорожки. На каждой дорожке указываются операции, выполняемые подразделениями/сотрудниками/бизнес-ролями. Пример: «начальник отдела продаж» – сотрудник, «инициатор договора» – бизнес-роль. Подробно методики описания графических схем в формате Work Flow рассмотрены в лекции 6. Как правило, на уровне операционных процессов в системе процессов компании определяются и согласуются между собой входы/выходы процессов. Вопрос определения и согласования входов/выходов не такой простой, как кажется. Дело в том, что определение входов/выходов – весьма неоднозначная и ресурсоемкая задача. Если есть уверенность в том, что система процессов построена адекватно (а это зависит от методики и опыта бизнес-аналитиков), то входы/выходы могут быть корректно определены уже на следующем этапе – описания бизнес-процессов. Конечно, при этом в систему придется вносить некоторые изменения. Но система процессов – не застывшая, а живая, развивающаяся модель деятельности организации. Поэтому не стоит бояться вносить в нее изменения. Важно определить и регламентировать правила их внесения. Описание процессов с помощью MS Excel Для описания системы процессов организации можно использовать MS Excel. Форма представления системы процессов в MS Excel показана на рис.4. Каждая процессная категория находится на отдельном листе файла. Рис. 4. Представление системы процессов в виде таблицы MS Excel 11 Рис.унок 4.- Представление системы процессов в виде таблицы MS Excel При формировании дерева процессов и описании его в виде таблицы (рис. 4) возникает вопрос – как правильно показывать входы/выходы для процессов? Для нижнего уровня (четвертого и, возможно, третьего) ответ очень прост: следует описывать конкретные документы (бумажные, электронные) и материальные потоки. Но что делать при описании входов/выходов для процессов верхнего уровня (первый-второй, иногда третий)? Существует как минимум три основных варианта: 1. Агрегировать информационные и материальные потоки и показывать их в обобщенном виде, соответствующем уровню процессов. 2. Не показывать входы/выходы на тех уровнях процессов, где нужно делать агрегирование (то есть там, где невозможно или слишком сложно показывать потоки реальных документов/материалов). 3. Дублировать описание входов/выходов в виде списка, повторяя все входы/выходы, определенные для процессов нижних уровней. Первый вариант предполагает, что бизнес-аналитики, проектирующие систему процессов организации, достаточно квалифицированны, чтобы выполнять декомпозицию/агрегирование как процессов, так и потоков ресурсов (информационных и материальных). Если в этом есть сомнения, то лучше оставлять ячейки с описанием входов/выходов для процессов верхнего уровня пустыми (вариант 2), заполняя их только для детальных процессов конкретными наименованиями документов/материалов. 12 Третий вариант – наименее удобный, так как ведет к дублированию большого количества информации в таблице и усложнению ее восприятия. Заполнение таблицы процессов вида 2 в MS Excel сопряжено с существенными затратами рабочего времени. Ее лучше всего использовать на начальной стадии проекта внедрения процессного подхода, пока нет возможности применить более эффективные инструменты (например, среду моделирования процессов). Перенос системы процессов из таблицы в среду моделирования требует незначительных трудозатрат. На первых стадиях внедрения процессного управления использование таблицы в MS Excel – самый простой и удобный вариант. Для небольших компаний дерево процессов в MS Excel вполне может использоваться постоянно, без переноса в какую-либо другую систему. Цели разработки системы процессов организации Практика показывает, что задача создания адекватной системы процессов актуальна для организаций различного масштаба: от крупных холдингов до небольших частных компаний. Приведу несколько примеров. Построение системы процессов организации означает упорядочение ее деятельности в виде процессов. Древовидная структура процессов и согласованные границы позволяют четко определить зоны ответственности руководителей на всех уровнях управления, исключить зоны безответственности и зоны размытой ответственности (пересечения ответственности). Четкое определение зон ответственности руководителей позволяет организовать оперативное управление процессами, не дожидаясь их подробного описания и регламентации. Сказанное иллюстрирует рис. 5. В ситуации 1 процессы не выделены и не управляются. В ситуации 2 процессы выделены, границы процессов четко определены, руководители приступили к организации управления процессами на основе системы показателей. В ситуации 3 процессы регламентированы, оперативно управляются и совершенствуются на основе цикла PDCA. 13 Рисунок 5 - Упорядочение деятельности организации в виде процессов Управление процессами означает, что для каждого из них разработаны и используются показатели. Если не создать систему процессов, то не к чему будет привязывать эти показатели (не будет идентифицированных объектов управления)[3]. Если система процессов будет построена некорректно (например, состав и границы выделенных процессов окажутся неадекватны реальной деятельности[5]), то организация управления такими «процессами» – бессмысленное занятие. Поэтому корректно построенная система процессов – это основа для успешного внедрения процессного подхода. В целом система процессов организации обеспечивает достижение следующих целей: • упорядочение деятельности организации в виде процессов, анализ существующей организационной структуры и обоснование возможных и целесообразных направлений ее реорганизации; • организация управления процессами, в том числе создание основы для разработки системы показателей для управления процессами; • четкое определение зон ответственности руководителей, исключение зон безответственности, зон дублирования ответственности; • четкое определение границ процессов по входам/выходам и событиям; 14 • повышение эффективности межфункционального взаимодействия подразделений за счет определения, описания и оптимизации сквозных процессов; • создание основы для последующего системного описания и регламентации процессов; • создание основы для успешного внедрения различных средств автоматизации деятельности; • прочее. Литература : 1.Репин В.В.,Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов.- М.: РИА «Стандарты икачество», 2004.408 с.. 2.Репин, В.В Бизнес-процессы: моделирование, внедрение , управление 3. Хаммер М., Хершман Л. Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов. – М.: Альпина Паблишер, 2012. 4. Репин В. В. Бизнес-процессы компании: регламентация. М.: Стандартыи качество, 2007. построение, анализ, 5. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007. 6. Бьёрн А. Бизнес-процессы. Инструменты совершенствования. – М.: Стандарты и качество, 2003. 7. Де Гиус А. Живая компания. Рост, научение и долгожительство в деловой среде. – СПб.:Стокгольмская школа экономики в Санкт-Петербурге, 2004. 15