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

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

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

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

Кому это надо

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

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

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

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

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

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

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

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

Разумеется, возможны и другие причины – или комплекс причин, по которым проектирование системы управления становится необходимым. Главное, при принятии решения не следует забывать простую истину: «Если работает – не ремонтируй!». (В ходе написания статьи у авторов возникли некоторые разногласия в трактовке этой поговорки. Остановились на таком ее уточнении: то, что прекрасно работает сегодня – завтра может стать проблемой. И конечно, дальновидный руководитель просто обязан предусмотреть соответствующий «ремонт»).

Немного примеров из жизни

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

ИТ-компания – типичное предприятие среднего бизнеса. Основные направления деятельности:

● Продажа средств автоматизации бизнеса – от продажи бухгалтерских и офисных программ до полномасштабных АСУП

● Внедрение средств автоматизации бизнеса

● Системная интеграция

● Услуги по обучению и сертификации специалистов Заказчика

● Производство и реализация собственного программного обеспечения.

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

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

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

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

С чего начать?

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

Рисунок 1.

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

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

Какие элементы подвергаются анализу? В первую очередь, ассортимент предлагаемых компанией товаров и услуг. Составляется реестр – полный пакет этих предложений – и производится его анализ. Все ли из того, что мы производим, выгодно, полезно и способствует достижению основных целей? Стоит ли расширить наш ассортимент? Нужно ли сократить его в части невыгодных товаров или услуг? Можно ли невыгодные товары или услуги сделать выгодными (а выгодные – супер-прибыльными?). Составляется перспективный пакет продуктов и услуг, для которого и будет производиться моделирование бизнес-процессов. Для продуктового анализа можно, например, использовать матрицу Boston Consulting Group (рисунок 2).

Рисунок 2.

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

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

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

Команда участников

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

Стратег. Он же Руководитель проекта. Задача этого человека в проекте – воплощать ожидания собственника в стратегию их достижения, координировать действия остальных участников, решать конфликты в тех случаях, когда требуется видение ситуации целиком. Стратег, если применять военные ассоциации, должен представлять картину сражения в целом – то есть, должны выполняться оборонительные действия. На одних участках – наступательные, на других – конница в определенный момент должна выскочить из засады для обеспечения прорыва, танки воспользоваться этим прорывам для прорыва в тыл и разгрома противника… Его не волнует, каким строем будут двигаться танки – это местная тактическая задача. Его не волнует, какой транспорт будет использован для подвоза боеприпасов – их просто должны доставить в нужном количестве. В то же время, если отдел снабжения и командир танковой бригады не смогут договориться о количестве и сроках подвоза снарядов, стратег, зная общую логику работы системы, должен разрешить конфликт между службами, руководствуясь своим мнением о необходимом балансе. Одна из наиболее реальных кандидатур на выполнение этой функции – генеральный директор (впрочем, бывает и так, что генеральный директор является «свадебным генералом», либо слишком занят и может доверить функцию стратега заместителю или внешнему консультанту). В зависимости от опыта, загруженности, наличия специальных знаний, в помощь ему могут привлекаться как заместители, так и внешние консультанты (например, руководитель или координатор проекта со стороны исполнителя). Однако принятие окончательных решений остается все-таки именно за этим единственным человеком, либо иногда за собственником предприятия.

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

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

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

Пример – единственный менеджер по кадрам средней компании осуществляет свою функцию в рамках единственного бизнес-процесса, который называется просто «подбор персонала». Учитывая, что практически всю работу он выполняет самостоятельно, никакого регламента для этой работы писать не требуется. Другое дело – отдел кадров крупной компании, где существует разделение различных функций между сотрудниками. Процесс «подбор персонала» в таком случае складывается уже из десятков более простых действий, выполняемых различными людьми – и вот их взаимодействие и требуется описать бизнес-процессами нижнего уровня. Конечным уровнем для деления бизнес-процессов является бизнес-операция – процесс, полностью выполняемый и контролируемый одной кадровой единицей. И для очень крупных компаний вполне реальны тысячи бизнес-процессов. Теперь сделаем воображаемую проекцию картины бизнес-процессов на схему подразделений предприятия. Очевидно, что некоторые бизнес-процессы будут полностью укладываться в рамках одного подразделения. Будут также и процессы, за выполнение которых отвечает (в той или иной степени) два и более подразделения. И самые неприятные ситуации, это те, в которых ответственность за выполнение бизнес-процесса неоднократно переходит от одного подразделения к другому (забегая вперед, скажем, что таких бизнес-процессов рекомендуется, по возможности, избегать). На рисунке 4 схематично показаны бизнес-процессы условного предприятия по производству продукции. Часть бизнес-процессов, показанная черными стрелками – протекает внутри подразделений. Другая часть – синие стрелки – переходит из одного подразделения в другое. И, наконец, третья часть – процесс, в котором задействовано несколько подразделений. Красный пунктир.

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

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

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

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

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

Собственно проектирование…

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

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

Концентрация усилий на выполнение стратегических целей. Бизнес-процессы, не имеющие влияния на ключевые показатели, разрабатываются в последнюю очередь, либо не разрабатываются вообще. Проведем простейший расчет: для предприятия, имеющего три уровня бизнес-процессов (то есть не очень большое унитарное предприятие) мы имеем 7-8 процессов верхнего уровня, каждый из которых делится на 7-8 БП второго уровня, такой же принцип деления сохраняется и ниже. Как результат, уже на третьем уровне имеем более 350 бизнес-процессов. В среднем, каждый бизнес-процесс состоит из десятка операций, что дает четыре тысячи операций в целом для предприятия. И это только для небольшого! Геометрическую прогрессию до четвертого и пятого уровня предлагаю посчитать самостоятельно. Конечно, пятого уровня детализации требуют только такие монстры, как Газпром или РАО ЕЭС – но и для четвертого уровня число операций оказывается не маленьким. Каждый процесс, каждую операцию, в идеале, нужно оптимизировать, регламентировать и пересматривать хотя бы раз в год или по мере изменения внешних условий. Учитывая количество операций, понимаем, что идеал, как обычно, недостижим, а погоня за ним приведет лишь к неоправданному перерасходу ресурсов. Приходится принимать грустное, но верное решение – взяв стратегическую карту, проектировать лишь те бизнес-процессы, которые соответствую указанным в ней целям. И, если уборка внутренней территории не влияет ни на одну из целей или подцелей стратегической карты, не воздействует ни на один показатель из ССП – то пусть ее регламентируют сами уборщики. Хотя бы до тех пор, пока мы не разобрались окончательно с производством, сбытом и снабжением…

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

Не забывать при проектировании задавать основные параметры бизнес-процесса (рисунок 5).

Рисунок 5. Основные параметры бизнес-процесса

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

Оценка проблемности и важности процесса. Также позволяет понять, какие процессы следует проектировать сразу, а какие могут и подождать. Среди основных критериев здесь могут быть рассмотрены: 1) критичность для бизнеса. То есть насколько неправильное исполнение процесса может навредить компании – повысить затраты, привести к потере клиента, задержать принятие важного решения… 2) Частота повторения процесса (редко, часто, регулярно). 3) Количество передач ответственности в рамках одного процесса, например, от подразделения к подразделению. Такие процессы потенциально опасны и тянут за собой множество проблем.

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

Рисунок 6. Иллюстрация процессного подхода

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

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

Что ожидаем в итоге

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

Регламенты бизнес-процессов (по крайней мере, ключевых), стандартные бланки документации, как наружной, так и внутренней, положения о подразделениях, должностные инструкции, штатное расписание предприятия – вот ее минимальный перечень. Не менее важно и внедрение системы, реализация регламентов на практике. Только после этого можно говорить о том, что силы и ресурсы на проектирование потрачены не напрасно. Хорошо, если удастся разделить внедрение на небольшие этапы и участки (например, сначала отдел закупок, потом складское хозяйство и т.п.) Помимо того, что это позволит сохранять уверенный контроль за процессом внедрения инноваций, каждый небольшой успех будет становиться хорошим стимулирующим фактором для продолжения дальнейшей работы. Правда, возможность разделить внедрение на отдельные независимые участки имеется далеко не всегда. Даже если новая система полностью позволяет избежать разделения ответственности между подразделениями, если структура новых бизнес-процессов строго линейна и проста – даже тогда необходимость внедрять измерения «на ходу» (кто же позволит остановить предприятие, приносящее прибыль?) приводит к тому, что внедрение одного нового процесса затрагивает десятки старых, которые, в свою очередь, заменены десятками «новых», каждый из которых… (и далее, по нарастающей). Поэтому в большинстве случаев по ходу внедрения коллектив вынужден какое-то время работать по старой системе, параллельно имитируя новую деятельность (большинство ваших сотрудников люди грамотные и прекрасно понимают, что долгое время придется делать двойную работу только ради того, чтобы итоговая нагрузка на них возросла бы по сравнению с изначальной – отсюда и сопротивление инновациям). В наиболее запущенных случаях для внедрения системы управления оказывается проще построить недалеко новый завод (именно так приходится поступать, например, на «АвтоВАЗе», где унаследованные из советских времен несуразности, помноженные на благоприобретенные в процессе перестройки создали среду, инновациям в которой сопротивляется практически каждый сотрудник). И, наконец, еще один закономерный результат проектирования – внедрение автоматизированной системы управления предприятием. Давно доказано, что автоматизация повышает эффективность работы. Особенно заметный эффект автоматизация дает на предприятиях, где имеется четкая и рациональная система управления, регламентированы все бизнес-процессы. И, напротив, автоматизировать управление без предварительного проектирования – значит обречь внедрение АСУ на провал (мы уже упоминали невозможность автоматизации неопределенным образом происходящих случайно возникающих взаимоотношений?). Наличие же строгой системы бизнес-процессов позволит подойти к внедрению АСУ с точки зрения максимальной эффективности. Теперь уже вполне реально автоматизировать сначала наиболее критичные участки работы, на вырученные или сэкономленные в результате деньги – следующие по важности… Можно делать это с той постепенностью, какую позволяют ресурсы или требует внешняя ситуация.

Оценка потребности в ресурсах

Если вам ранее доводилось заниматься подобной деятельностью – то вы уже представляете себе, насколько облегчит проектирование Ваш расчетный счет, скольких сотрудников вы временно потеряете, как полноценные боевые единицы (и скольких вообще потеряете). Рассуждения ниже скорее для тех, кто впервые планирует приступать к такой работе – ведь опасно как переоценить, так и недооценить масштабы грядущих потерь. Завышенная оценка сложности может привести к отказу от проекта вообще (вместе с надеждами стать лидером отрасли), либо к излишне высоким суммам по договору с исполнителем. Заниженная оценка приведет к тому, что в какой-то момент ресурсов не хватит и проект будет заброшен – что снова означает потерянные деньги. Временная оценка не менее важна – и по тем же соображениям. Практика показывает, что компании среднего размера – от 500 до 1000 человек – разрабатывают и внедряют новую систему управления целиком за один год. Компаниям с 10 тыс. сотрудников потребуется примерно 2-3 года. Впрочем, в зависимости от сложности ситуации, время внедрения может увеличиться и в два и в три раза.

Из потребности в людских ресурсах можно предположить на весь этот период постоянную команду из 3-4 человек (стратег, аналитики) и необходимость привлечения к работе сотрудников предприятия по мере необходимости – начальников подразделений и рядовых исполнителей. Начальники будут привлекаться, приблизительно на один-два месяца чистого времени на протяжении всего цикла проектирования и внедрения, рядовые исполнители – меньше, от 2 недель до месяца. Затраты на своих специалистов, учитывая это время, можно оценить. Внешние консультанты стоят недешево. Услуги специалиста могут обойтись от 1,5 до 25 тыс. рублей за час работы.

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

Вопрос: Можно ли снизить затраты на проектирование системы управления?

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

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

● Вторая причина берет исток в понимании основ эффективности. Часто повторяющиеся процессы являются критичными для общего хода дела – ведь, несмотря на простоту и шаблонность, их вклад в общие трудозатраты весьма значителен. В проектировании бизнес-процессов достаточно много шаблонных, повторяющихся действий, которые, при ручной работе, заберут львиную долю всего времени разработки. Конечно, применение методик CTRL-C – CTRL-V заметно облегчает работу в WORD или Excel при их вводе, однако специализированное ПО предоставляет еще более удобную среду для проектирования.

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

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

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

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

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

Определение

Бизнес-процессы (БП) – это последовательность определенных действий, отвечающая следующим условиям:

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

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

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

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

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

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

Группы бизнес-процессов

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

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

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

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

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

Описание и анализ бизнес-процессов в организации: пример

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

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

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

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

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

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

Ответственным за написание и утверждение БП должен быть его владелец . Это позволит снизить вероятность «саботажа» основными исполнителями, если они не принимали участия в составлении соответствующего регламента.
Результаты, которые получаются на выходе процесса, должны быть четко сформулированы, измеримы и понятны . Если на объяснение положений регламента сотрудникам уходит много времени, то следует поработать над изменением формулировок в регламентирующем документе.
Используйте простые схемы . Правила описания алгоритма представлены в любом учебнике информатики для старших классов. Это простой и интуитивно понятный язык. Выбор программы для визуализации процессов не принципиален: можно успешно обойтись стандартными программами пакета MS Office.
Основное внимание следует уделять наиболее критичным для развития бизнеса процессам. Наука, производство и продажи – это три столпа добавленной стоимости. Нет большого смысла вкладывать ресурсы в контроль работы бэк-офиса, если продажи и производство никак не контролируются.
Все участники процесса должны быть учтены и прямо указаны . Каждый из них должен знать:
- что от него требуется,
- в какие сроки следует выполнять поставленные задачи,
- как будет измеряться результат его работы,
- каким будет вознаграждение в случае успешного исполнения
Используйте простые и стандартные термины и определения. Процесс описывается для сотрудников компании, а не для самовыражения.
Акцентируйте внимание руководства компании, что самым дисциплинированным исполнителем принятых регламентов должны стать генеральный директор и топ-менеджмент компании. Процесс перестанет генерировать добавочную стоимость, если будет периодически нарушаться руководством компании.
Контролируйте исполнение положений принятого документа и применяйте дисциплинарные взыскания за необоснованные нарушения.
Акцентируйте работу на поиске узких мест . На практике приходится сталкиваться с удивительными вещами. Например, новое современное производство не оснастили линией розлива достаточной мощности. В итоге качественные препараты были произведены, но розлив в тару существенно замедлил весь процесс и свел на нет большую часть работы коммерческого департамента.
Привлечение консультанта для описания и утверждения БП сопоставимо с привлечением высоко классифицированного модератора, но не более. Никто не знает ваш бизнес лучше вас и вашей команды. Бизнес-процесс в организации эффективнее описывать совместно с командой.
Если процесс «не работает», то уделяйте время анализу причин и внесению необходимых изменений. Методы оптимизации БП хорошо известны:
- Упрощение (например, когда из процесса исключаются не влияющие на результат звенья);
- Объединение (исключение дублирующих частей БП);
- Аутсорсинг (передача исполнения дискретных задач сторонним компаниям);
- Оптимизация сроков (сокращение или увеличение сроков для регламентированных задач);
- Стандартизация (например, подготовка шаблонов документов или ввод дополнительных инструкций).

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

«Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
«Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
«Процедура» системы Business Studio (один из возможных вариантов представления);
ARIS eEPC.

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

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы, ни то, и ни другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т. п. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы и т. п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

На Рис. 3 представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы нестандартным образом — не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т. п.

Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

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

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

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

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

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

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1-3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

При формировании схемы Рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т. п.

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

Выводы

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

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

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

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность

Типовые структуры бизнес-процессов (Process Frameworks) разработаны Группой компаний «Современные технологии управления» в качестве методической основы для построения моделей бизнес-процессов реальных компаний. Типовые структуры представлены в формате PDF для ознакомления и в формате XML для использования в Business Studio (доступны для загрузки на странице Пакеты для самостоятельной загрузки).

Оказание услуг (PDF)

Проектная деятельность (PDF)

Производство (PDF)

Управляющая компания (PDF)

Уникальная возможность

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

Модели бизнес-процессов, созданные в системе Business Studio

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

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

Внимание!

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

Модель производственного предприятия

Характеристика предприятия

Основные направления деятельности:

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

Численность персонала: 1200 человек.

Описание модели

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

Модель включает:

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

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

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

Техническое задание на автоматизацию

Нормативная 8-процессная модель деятельности производственного предприятия

Модель разработана компанией «БКГ» и лично ведущим российским специалистом в области организационного развития компаний Т.Р. Кадыевым. Может применяться как основа для последующей локализации на конкретном предприятии.

Модель включает в себя:

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

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

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

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

Модель включает:

Модель бизнес-процессов и процедур, включая цели и показатели процессов;
Организационную структуру компании;
Финансовую структуру компании;
Бюджетную структуру компании;
Раздел СМК, содержащий требования стандартов ИСО 9001:2000 и ИСО/ТУ 16949, Руководство по качеству ;
Структуру информационной системы и Техническое задание на автоматизацию .

Данная модель содержится в демо-версии системы Business Studio.

Модель производственной деятельности в соответствии со стандартом ИСО 9001:2000

Рост конкуренции между западными и отечественными компаниями за право преобладания на Российском рынке товаров и услуг заставляет последних активнее использовать современные методы управления, в частности, построение системы менеджмента качества (СМК), соответствующей требованиям ИСО 9001:2000 г. Данный стандарт представляет собой набор требований к подсистеме управления качеством выпускаемой продукции или оказания услуг организации. Функционирующая СМК позволяет утверждать, что организация способна выпускать качественную продукцию (оказывать услуги) на регулярной основе, а значит, имеет большие преимущества перед конкурентами. Однако построение СМК дело непростое, зачастую требующее от организации внесения значительных изменений в ее производственно-хозяйственную деятельность, в бизнес-процессы предприятия. Для облегчения понимания требований самого стандарта ИСО 9001:2000 г., а также в качестве примера построения СМК предлагается модель деятельности организации, осуществляющей производство продукции. Модель включает в себе все стандартные процессы, начиная от проектирования и заканчивая сервисным обслуживанием продукции.

Для описания модели организации использовалась нотация функционального моделирования IDEF0. Процессы верхнего уровня модели соответствуют ключевым разделам стандарта ИСО 9001:2000 г., далее они декомпозируются на подпроцессы нижнего уровня уже непосредственно в привязке к производственно-хозяйственной деятельности организации. Таким образом, модель представляет собой совокупность бизнес-процессов организации с интегрированными в них требованиями ИСО 9001:2000 г. При этом существуют ограничения в интерпретации требований стандарта (переложении их на деятельность организации), связанные с тем, что за основу была принята достаточно условная организация, без какой-либо отраслевой специфики. В связи с этим, на практике, такую модель можно использовать как основу для анализа соответствия деятельности предприятия (по зонам ответственности — разделы стандарта) требованиям ИСО 9001:2000, а также как нормативную модель для разработки и внедрения СМК.

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

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

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

Как на практике осуществляется анализ и моделирование бизнес-процессов вы узнаете тут:

Цели процесса

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

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

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

Чтобы вникнуть в детали работы предприятия необходимо:

Провести: аудит бухгалтерской отчетности. Как провести вы узнаете в публикации по ссылке;
Изучить производственные бумаги;
Выполнить опись производства;
Изучить процесс на деле.

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

Чтобы этого достигнуть необходимо совокупное применение нескольких методик:

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

Моделирование бизнес-процессов и управление ими

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

Моделирование состоит из нескольких последовательных стадий:

Определение процессов и построение начальной модели, как на самом деле;
Диагностика, изучение и улучшение построенной модели;
Разработка модели с исправлениями;
Ее тестирование и применение;
Исправление ошибок.

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

Пример анализа бизнес-процесса

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

В ходе исследования проблем выявлены такие недочеты:

Неравномерное использование рабочей силы;
Отсутствие соответствующих условий;
Нет автоматизации.

Ранжирование – выявленные проблемы отсортированы по степени важности.
Варианты избавления от проблем:

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

Все это обеспечило скорость обслуживания поступающих заказов.

Оценка проведенных действий

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

При этом формируются ответы на ключевые вопросы:

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

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

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

Основные способы оптимизации

Методы оптимизации бизнес-процессов могут быть разными в зависимости от получения желаемых результатов и избранного варианта решения проблемы:

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

Важно: все способы оптимизации применяются в зависимости от возникновения причины.

Заключение

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

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