Формализации бизнес процессов необходимо предпринять следующие шаги. Что даёт формализация бизнес-процессов

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

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

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

Прежде чем начать

Суть идеи формализации процесса по методу SIPOC заключается в том, что мы:

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

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

Что такое SIPOC

Итак, SIPOC - это акроним от английских слов Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (заказчик) . Эта модель позволяет описывать процессы с точки зрения последовательности действий, движения информации/товаров/услуг между этапами процесса, а так же взаимоотношений, возникающих в результате процесса между различными участниками. Модель позволяет проследить бизнес-логику процесса, с высоким, но управляемым уровнем абстракции.

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

(S) ООО «Рога и копыта» -> (I) Требования к информационной системе -> (P) Формализация требований -> (O) Техническое задание -> (C) 1С:Франчайзи

Читаем слева направо: Заказчик озвучивает требования к информационной системе, которые формализуются, в результате чего появляется техническое задание для 1С:Франчайзи.

Визуально отображаем:

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

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

I - Input (вход) . В нашем примере это требования к информационной системе. Эти требования могут быть в виде электронного письма, описаны устно на переговорах или запротоколированы в предыдущих интервью. Здесь описывается все, что необходимо для процесса. К этому описанию применяются требования (requirements), поэтому акроним SIPOC можно увидеть в некоторых источниках, как SIRPORC. Эти требования, как видно из акронима применяются как к входу, так и к выходу.

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

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

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

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

O - Output (выход) . Здесь мы описываем то, что должно было получиться из предыдущего этапа. В нашем примере это техническое задание. К техническому заданию как к «выходу» из процесса предъявляются свои требования, которые формулируются заказчиком (customer"ом). Например, 1С:Франчайзи имеет стандарт оформления технического задания. Требование «техническое задание должно соответствовать стандарту» описывается нами в приложении. Но, чтобы закрепить визуально, дорисуем:

С - Customer (заказчик) . В нашем примере это 1С:Франчайзи, которое получает техническое задание в результате проведенной формализации требований.

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

Тонкости

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

Если у нас несколько поставщиков «входящих» объектов или несколько самих «входящих» объектов, то их можно отобразить вот так:

То же самое касается и «исходящих» объектов и заказчиков:

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

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

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

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

А как же цикличные процессы? А как же параллельные процессы? А как же ветвления?

Отвечу на все вопросы по порядку.

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

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

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

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

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

Есть разные уровни управления и соответствующие им разные уровни масштаба.

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

Нельзя одновременно видеть все и в деталях. Должны быть разные карты для разных точек обзора. Если соблюдать это требование, то практически все процессы, соответствующие детализацией «высоте» обзора, можно описать моделью SIPOC. Из этого я в свое время сделал такой вывод: если процесс описывается методом SIPOC , то «высота» обзора процесса соответствует уровню детализации . Возможно, это покажется спорным утверждением. Надеюсь на то, что если я не прав, то более компетентные товарищи меня поправят в комментариях. Я всегда готов к совершенствованию. Но пока опытным путем не удалось столкнуться с обратным.

Как рисовать карту процесса?

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

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

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

Если процесс мы читаем слева направо сверху вниз, то рисовать процесс мы начинаем справа налево снизу вверх! То есть:

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

Process: Потом мы описываем сам процесс, как последовательность действий и ответственного за исполнение этого этапа.

Input: Описываем, что необходимо для выполнения этого этапа и требования к этому.

Supplier: Описываем, кто будет поставлять процессу необходимые компоненты.

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

Теперь, если вспомните, чуть выше я писал о стыках этапов процессов. Пришел их черед. Как правило, на обследовании (это свойственно вообще этапу обследования) вскрываются различные нюансы. Вдруг выясняется, что для выполнения этапа процесса необходим был какой-то документ, но оказывается, что его никогда не было и этап процесса выполнялся до этого без учета этого документа. Более того, т.к. документа никогда не было, то не понятно, кто должен его поставлять для этапа процесса. Или выясняется, что на каком-то этапе выдается «выход» (output), который оказывается никому не нужен, т.е. когда мы просматриваем процесс позднее и видим «потребителей» (costumers), которые потребляют «выходы» (outputs) и нигде потом больше не участвуют, то вполне возможно, что что-то делается зря. Это не всегда так, например, выходом может быть печатная форма, которая позднее уходит в бухгалтерию, а в рамках автоматизации бухгалтерский учет не присутствует. Для описания процесса такой «выход» будет лишним, но в рамках ограничений процесса это допустимо. В любом случае проверить никогда не будет лишним.

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

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

Не явные бонусы

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

Сами карты SIPOC легко читаемы и легко воспринимаются ЛПР. Это позволяет создавать «продающие» обследования. Часто встречали на средних и крупных проектах, что ЛПР, не умел читать нотации серии IDEFх. В этом случае мы переводили их на более понятный уровень, если это было возможно, т.к. иногда был откровенный бред. Если мы работаем с ИТ-отделом, то дальнейшее описания в проектных документах мы согласуем с ними, если они не высказываются «против», то мы продолжаем придерживаться нотации SIPOC. Но бывает, что требуют другие нотации, как правило, IDEF0 и/или IDEF1, это бывает очень редко. Пока, что весомого аргумента в пользу этих нотаций, кроме того, что это привычный стандарт, а SIPOC они в глаза не видели, я не услышал. За исключением проекта, где требовалось автоматизировать процесс маршрутизации клиента по отделам в зависимости от того, что он закупает, в каком объеме и пр., там было очень много ветвлений. Фактически это автоматизация сложного оперативного управления, картам SIPOC там не место.

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

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

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

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

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

6 сигм, бережливое производство…

… и пожалуй все.

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

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

Эффективно управлять бизнесом без ясного и однозначного понимания всеми сотрудниками бизнес-процессов компании - невозможно!

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

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

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

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

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

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

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

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

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

Табл. 1. План действий по методике FAST

№ п/п	Описание	Ответственный
	Формулирование целей службы поддержки	Руководитель подразделения Руководитель службы
	Анализ имеющейся документации, информации	Менеджер по персоналу
	Составление списка бизнес-процессов службы Определение процессов для FAST	Руководитель службы Менеджер по персоналу
	Разработка блок-схем бизнес-процессов	Менеджер по персоналу
	Определение плана мероприятий для реализации процессов	Руководитель службы Менеджер по персоналу
	Презентация руководству компании Утверждение предложенных улучшений	Руководитель службы Менеджер по персоналу
	Описание и документирование процессов	Менеджер по персоналу
	Информирование сотрудников подразделения о новых процессах	Руководитель службы Менеджер по персоналу
	Информирование сотрудников смежных подразделений об изменениях	Руководитель службы Менеджер по персоналу
	Обновление квалификационных требований к работникам службы поддержки Проведение оценки исполнения (performance appraisal )	Руководитель службы Менеджер по персоналу
	Контроль соблюдения процессов работниками	Руководитель службы
	Обеспечение процесса постоянного улучшения	Руководитель подразделения

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

Далее мы проанализировали действовавшее на тот момент «Положение о службе поддержки», в котором были описаны утвержденная структура подразделения, должностные обязанности и компетенции консультантов по поддержке. Анализ показал, что:

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

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

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

Фактическое отклонение по срокам выполнения работ в соответствии с типами поддержки и приоритетами задач.
Количество оплачиваемых часов (для консультантов по поддержке).
Показатели удовлетворенности клиентов.

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

Затем мы приступили к разработке первоначальной версии блок-схем4 этих процессов. Проанализировав первые наработки, внесли в них корректировки, в том числе - в отношении участников процессов и зон их ответственности. Например, было принято решение об аннулировании позиции Helpline Representative (помощника-консультанта) - часть этих обязанностей передали младшим консультантам. В итоге, на основании проделанного анализа блок-схем бизнес-процессов, а также анализа фактической работы сотрудников службы была изменена ее структура - с учетом специфики матричных структур, характерных для проектных организаций (рис. 1 ).

Рис. 1. Изменение организационной структуры подразделения

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

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

Рис. 2. Пример процесса реализации заявок
()

Рис. 3. Пример процесса взаимодействия с другими подразделениями
(представлен в сокращенном виде )

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

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

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

Табл. 2. Квалификационные требования к сотрудникам отдела поддержки
(представлена в сокращенном виде )

Вес навыка для должности:		Грейд 1	Грейд 2	Грейд 3	Грейд 4
Профессиональные навыки и знания
	Знания предметной области
	Описание тест-кейсов
	Описание тестового сценария
	Умение написать техническую спецификацию
	Проведение тренингов для заказчиков
	Знание и использование проектной методологии
Общие навыки
	Коммуникационные навыки
	Навыки работы в команде
	Управление временем
	Ориентация на заказчика
Потенциал
	Способность к обучению
	Проактивность
	Инновационность
Сертификаты
	221 NAV C/SIDE Introduction
	225 NAV Financials


	226 NAV Installation & Configuration
Количество сертификатов

Табл. 3. Стандартный план обучения сотрудника службы поддержки

План обучения сотрудника для подтверждения грейда 2
Описание	Приоритет	Форма обучения	Сроки

В этом уроке мы рассмотрели 3 темы:

1. Формализацию бизнес-процессов. Почему это важно при создании бизнес-процессов и не так сложно, как может показаться не подготовленному специалисту.
2. Работу с бизнес-процессам в Битрикс24
3. Редактор бизнес-процессов, работу c "Действиями"

Описание бизнес-процесса "Оформление договора":
Менеджер компании подготавливает договор с клиентом. Каждый договор должен быть согласован с руководителем отдела (может выполняться многократно!).
Если сумма договора больше 15 000 руб., то в договор бухгалтер должен внести доп. условия. Если меньше, то доп. условия не требуются.
Каждый договор должен быть согласован с юристом (может выполняться многократно!).
После всех согласований менеджер подписывает договор у директора и отправляет его по почте клиенту.
Когда менеджер получает подписанную клиентом копию договора, он регистрирует её.

Графическая формализация бизнес-процесса "Оформление договора":

Видео запись вебинара

Презентация вебинара, скачать >>

Задание для закрепления материала

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

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

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

3. Внести доработку в БП «Заявление на командировку» и пройти его под всеми участниками БП
- Добавить уведомление для любого пользователя (на ваш выбор) в Б24, что БП запустился
- Добавить сотруднику, запустившему БП, задачу «Передать дела перед отпуском».

Антон Тимохин

Руководитель проектов дирекции по развитию НПО «ЭЛСИБ»

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

Начало начал

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

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

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

Список можно продолжить.

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

Слепая вера топ-менеджмента компании в то, что внедрение новой программной системы (ERP, CRM, MRP и др.), которая (по заверению ее разработчиков) после внедрения и использования лучших практик, заложенных в референтных моделях, совершит чудо и бизнес сам начнет изменяться в положительную сторону…;
Сложившийся факт, что описание бизнес-процессов многими рассматривается как универсальный инструмент решения проблем. Но на практике это далеко не так — описание может помочь в устранении проблемных зон, но не само по себе, а в рамках комплексного подхода, одним из компонентов которого может быть как раз формализация бизнес-процессов компании;
Отсутствие бизнес-задачи. Компания работает, приносит некоторую прибыль. Да, при этом есть некоторые сложности в коммуникациях, но не более чем «рабочие моменты». Зачем менять сложившуюся практику выполнения работ, тем более, что описание бизнес-процессов потребует инвестиций в программное обеспечение, обучение специалистов, отвлечение сотрудников от рабочего процесса? Снижение эффективности компании и увеличение издержек неизбежно, если в цели проекта не входит увеличение бизнес-показателей.

Несколько слов об оптимизации

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

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

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

Про инструменты и методологии

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

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

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

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

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

Что можно получить в итоге

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

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

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

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

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

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

Лучшие практики

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

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

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

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

Этап первый — инициация проекта

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

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

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

Этап второй — бизнес-задача

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

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

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

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

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

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

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

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

Этап третий — программное обеспечение

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

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

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

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

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

Этап четвертый — методология

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

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

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

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

Организационную структуру;
Информационные системы, поддерживающие выполнение бизнес-процессов;
Носители информации, используемые в процессах.

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

Этап пятый — бизнес-модель, рабочие группы

Дальнейшая схема выполнения проекта подробно представлена на рисунке 1.

Рисунок 1. Схема выполнения основной фазы проекта по описанию и оптимизации бизнес-процессов

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

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

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

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

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

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

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

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

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

Этап шестой — моделирование, оптимизация

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

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

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

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

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

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

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

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

Этап седьмой — внедрение

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

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

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

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

Вместо заключения

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

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

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

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

Суть формализации бизнес-процессов

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

Если этого не сделать, неизбежны следующие проблемы:

Не всегда понятно, какой сотрудник за что отвечает.
Часто неочевидно, кто отвечает за конкретную задачу.
Решение каждой задачи задерживается, так как отсутствует чёткий алгоритм.
Задачи (документы, клиенты, заявки) совершают большой «путь» по компании, пока будут решены, при этом задействуются избыточные для данного случая сотрудники.

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

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

Задачи формализации бизнес-процессов

Формализация бизнес-процессов может быть выполнена разными методами, например, с помощью систем BPM, либо «вручную». Однако она всегда предполагает выстраивание чёткого алгоритма:

Закупка сырья.
Доставка сырья на склад.
Хранение на складе.
Отправка в цех.
Производство продукции.
Отправка продукции на склад.
Доставка продукции клиенту после покупки.

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

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

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

Формализация бизнес-процессов путём автоматизации

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

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

Если же формализация бизнес-процессов проводится с помощью систем BPM, то появляются дополнительные весьма важные возможности:

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

Последняя возможность особенно важна, потому что она помогает, в том числе:

Узнать, кто из сотрудников работает эффективно, а кто не очень.
Увидеть реальный объём всей работы, выполненной каждым работником. Может, кто-то лишь делает вид, что чем-то занят?
Избавиться от риска самых разнообразных злоупотреблений персонала.

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