Ковалев Сергей Михайлович
Ковалев Валерий Михайлович
(Журнал "Консультант директора", № 12, Июнь, 2004 г.)

Семь "золотых" правил описания бизнес-процессов

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

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

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

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

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

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

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

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

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

Правило 4. Создавайте схемы деятельности, а не организационных структур.

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

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

Правило 5. Избегайте излишней детализации бизнес-процессов, особенно на схеме "как есть".

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

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

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

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

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

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

Правило 7. Не смешивайте понятия "как есть", " как должно быть", "как будет".

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

Станислав Тульчинский

Генеральный директор и партнер ООО «b2b.Технологии развития»

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

С чего чаще всего начинается

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

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

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

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

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

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

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

Несколько замечаний по постановке задачи

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

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

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

Третьей проблемой является надежда на то, что новая программа MRP, ERP, CRM, SCM, BPM, DFM и т. д. и т. п. (зачастую флагман западной экономики), которая (со слов ее продавцов) является неиссякаемым источником мудрости и референсных моделей бизнеса, после внедрения сотворит чудо. И бизнес сам изменится в «правильную» сторону. Увеличатся доходы, будут выбраны правильные сегменты рынка, сократятся издержки и конфликты между сотрудниками. Но, как говорят продавцы «волшебной» программы, для того, чтобы ее внедрить, надо описать процессы.

Опыт показывает, что окончание проекта, в котором заложены такие умолчания, будет, скорее всего, весьма неопределенным. Браться за такой проект, все равно, что играть в русскую рулетку с пистолетом «ТТ» — шансы очень невелики.

Важное замечание про оптимизацию

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

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

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

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

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

Переход на новые (оптимизированные) процессы

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

Выбор инструментария и методологии для описания процессов

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

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

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

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

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

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

Поверхностный анализ Интернета показывает, что данная тема (выбор методологии и инструментария) недостаточно освещена (анализ META Group мало того, что больше ориентирован на IT-решения, так еще и практически не учитывает особенностей Российского рынка, рассматривает только типичных представителей сложившегося западного рынка). Наиболее часто встречаются статьи сравнения методологий ARIS и IDEF. Другой наиболее распространенной темой является перечисление сильных и слабых сторон (обычно методологий) без учета того, применительно к какой задаче эти качества анализируются. Становится несколько странно: неужели, например, грузоподъемность грузовика всегда является неоспоримым преимуществом, независимо от того, для чего я выбираю машину?

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

• CA ERwin Data Modeler (ранее называвшийся AllFusion Data Modeler, BPwin). Наиболее удачно реализована возможность описания взаимосвязанных сложных моделей, задачи описания алгоритмов и последовательности действий реализованы заметно слабее. Простые (лаконичные) нотации описания. Сложно, либо вообще никак не реализуются дополнительные задачи (увязка целей и процессов, создание дерева показателей, проведение имитационного моделирования);
• ARIS (набор программных обеспечений, модулей компании IDS Scheer). Само название (Architecture of Integrated Information Systems) говорит о том, что программное обеспечение изначально было ориентировано на решение задачи описания алгоритмов и последовательности действий. Все остальное в ARIS тоже можно делать, но это будет получаться очень непросто. Для описания бизнес-процессов придётся использовать большое количество моделей (в ARIS их более 80, и количество их растет) достаточно сложной семантики, в которой путаются даже наиболее ярые адепты. Без большого опыта и существенного переосмысления основ методологии реализовать сложные описания взаимосвязанных моделей непросто;
• Corporate Modeler (Casewise Systems) во многом является английским более юным аналогом ARIS — не по методологии и решениям, но по самим идеям 1 ПО. Также ориентировано на помощь в описании бизнес-процессов для последующей разработки программного обеспечения. Но стоит оно в среднем дешевле;
• iGrafx Enterprise Central (подразделение Corel Inc) пока менее известное в России, но очень симпатичное решение из Канады. Включает в себя целый набор модулей по описанию, моделированию процессов, приложения по планированию и управлению качеством управлением рисками. Существенным ее минусом является ее нераспространённость;
• Business Studio (ГК «Современные технологии управления»). Наиболее известная российская разработка из семейства рассматриваемого ПО. Пожалуй (на наш частный взгляд), удачно совмещает (насколько это возможно) некоторые наиболее полезные возможности BPwin и ARIS, чем-то напоминая по своему решению iGrafx (но не по стоимости). Если для заказчика важно соотношение цена/возможности, наверное, это оптимальный выбор для российских предприятий. Имеет один недостаток, так как очень плотно интегрирована с MS Office (Word, Excel, Visio), а поэтому все шероховатости этих решений автоматически переносятся и на Business Studio.

Что может получить заказчик

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

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

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

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

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

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

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

Не лучшее решение

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

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

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

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

• Определить какие именно бизнес-задачи (бизнес-показатели) бизнес хочет улучшить. Чего на самом деле заказчик хочет достичь, задумывая изменения в своем бизнесе? Для этого, вполне возможно, нужно будет переосмыслить видение бизнеса;
• Определить критерии оптимизации для бизнес-процессов: что компания хочет в них улучшить и насколько улучшить. Важным моментов в этой задаче будет осмысление явных (не мнимых) ограничений — что в организации определенно неприемлемо, а что точно менять нельзя;
• Определить программу действий по достижению поставленных целей, которая может включать в себя описание бизнес-процессов, а может и не включать. Обязательно детально проработать в программе действия по переходу на новые (оптимизированные) процессы;
• Выбрать достаточный для выбранной программы действий и поставленных целей необходимый набор инструментов (прежде всего, потребное программное обеспечение), которое лучшим образом соответствует поставленным целям;
• Только после того, как описанная в первых пунктах работа проделана, поискать достойных исполнителей для поставленной задачи.

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

1 «Для каждого существующего продукта будет разработан такой же аналог, интегрируемый с решениями SAP. Этим будет заниматься отдельное подразделение в нашей компании. Поэтому, можно сказать, что мы выходим на новый сегмент рынка в мировом масштабе — нашими клиентами станут заказчики SAP». Из интервью Бернарда Фишера, Президента компании Casewise.

Мы рассмотрели основные понятия бизнес-процессов. В данной части мы рассмотрим моделирование бизнес-процессов и приведем пример моделирования.

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

Моделирование – процесс исследования деятельности организации с целью построения формализованного (графического, табличного, текстового) описания бизнес-процессов организации.

• интервьюирование;
• работа с законодательством, документами организации;
• методы мозгового штурма и т.д.

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

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

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

Схема, иллюстрирующая алгоритм моделирования показана на рисунке ниже:

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

• дополнить существующую модель ответвлениями;
• предусмотреть отдельно действия «альтернативного» процесса.

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

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

Для фиксации бизнес-процессов в графическом виде используется система условных обозначений элементов (нотация). Наиболее известные нотации: SADT/IDEF0, IDEF3, DFD, BPMN, ARIS, UML. Рассмотрение и сравнительный анализ нотации не входит в предмет обсуждения данной статьи; интересующимся в интернете можно найти массу статей на темы сравнения нотаций, например «IDEF vs ARIS».

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

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

1. Сбор исходного материала.

1.1 Предоставление отпуска регламентируется Трудовым Кодексом (при сборе материала необходимо опираться на последнюю редакцию, на момент написания статьи – с изменениями от 30 декабря 2015 г. № 434-ФЗ), статьей 128 Отпуск без сохранения заработной платы

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

Работодатель обязан на основании письменного заявления работника предоставить отпуск без сохранения заработной платы:

• участникам Великой Отечественной войны — до 35 календарных дней в году;
• работающим пенсионерам по старости (по возрасту) — до 14 календарных дней в году;
• родителям и женам (мужьям) военнослужащих, сотрудников органов внутренних дел, федеральной противопожарной службы, органов по контролю за оборотом наркотических средств и психотропных веществ, таможенных органов, сотрудников учреждений и органов уголовно-исполнительной системы, погибших или умерших вследствие ранения, контузии или увечья, полученных при исполнении обязанностей военной службы (службы), либо вследствие заболевания, связанного с прохождением военной службы (службы), — до 14 календарных дней в году;
• работающим инвалидам — до 60 календарных дней в году;
• работникам в случаях рождения ребенка, регистрации брака, смерти близких родственников — до пяти календарных дней;

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

1.2. Документооборот при оформлении отпуска регламентируется постановлением Госкомстата РФ от 05.01.2004 N 1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты», раздел «Приказ (распоряжение) о предоставлении отпуска работнику».

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

Составляются работником кадровой службы или уполномоченным им на это лицом, подписываются руководителем организации или уполномоченным им на это лицом, объявляются работнику под расписку. На основании приказа (распоряжения) о предоставлении отпуска делаются отметки в личной карточке (форма N Т-2 или N Т-2ГС(МС)), лицевом счете (форма N Т-54 или N Т-54а) и производится расчет заработной платы, причитающейся за отпуск, по форме N T-60 »Записка-расчет о предоставлении отпуска работнику».

Приводим данные, необходимые для моделирования бизнес-процесса (действуем согласно описанной ранее схеме):

1. Результат бизнес-процесса - оформленные согласно законодательству РФ и стандартам организации документы .

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

3. Набор и порядок действий :

написание заявления -> составление приказа -> -> –> .

В последовательности действий отсутствует расчет заработной платы, т.к. статья Трудового Кодекса, согласно которой оформляется отпуск, – Отпуск без сохранения заработной платы.

4. Исполнители бизнес-процесса. . Для более наглядного предоставления информации приведем последовательность шагов и исполнителей в таблице:

5. События . Дополним вышеуказанную таблицу информацией о событиях:

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

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

№ действия	Входящее событие	Наименование действия	Документ, информация	Исполнитель	Исходящее событие	№ след. действия
	Инициатору необходим отпуск за свой счет	Написание заявления	Заявление на отпуск за свой счет	Инициатор	Составлено заявление на отпуск за свой счет
	Составлено заявление на отпуск за свой счет	Составление приказа	Приказ на отпуск	Сотрудник кадровой службы	Составлен приказ об отпуске
	Составлен приказ об отпуске	Подписание приказа у руководителя инициатора	Приказ на отпуск	Сотрудник кадровой службы	Приказ об отпуске подписан руководителем инициатора
	Приказ об отпуске подписан руководителем инициатора	Подписание приказа у инициатора	Приказ на отпуск	Сотрудник кадровой службы	Приказ об отпуске подписан инициатором
	Приказ об отпуске подписан инициатором	Оформление кадровых документов		Сотрудник кадровой службы	Оформлены кадровые документы на отпуск

7. Проведем анализ «что если».

• Что если заявление будет содержать ошибки (начиная от грамматических, заканчивая неправильным указанием реквизитов)? Инициатор заявления не обязан иметь достаточную квалификацию для безошибочного заполнения заявления (а обязан уметь грамотно выполнять свои непосредственные обязанности). Для устранения случая неправильного заполнения заявления добавим действие проверки заявления в основной процесс, т.к. нам важно предотвратить наличие ошибочного документа в процессе.
• Что если приказ на отпуск будет неправильно составлен? Т.к. в обязанности специалиста кадровой службы входит составление кадровых документов, то мы предполагаем, что в большом количестве случаев приказ составляется правильно. Это не отменяет проверку квалификации специалиста кадровой службы (процессы приема на работу и аттестации) и проведение периодической проверки документов (процесс аудита кадровых документов).
• Что если руководитель не подпишет приказ и инициатор:
  • имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос запишем в открытые вопросы по данному процессу и зададим его Владельцу процесса при согласовании процесса. Всю ответственность за исполнение процесса несет Владелец процесса, именно он определяет правила выполнения работы во вверенном ему подразделении;
  • не имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос также запишем в открытые вопросы.

• Что если инициатор откажется подписывать приказ (например, у него изменились обстоятельства, согласно которым он брал отпуск)? Мы прекращаем процесс.
• Что если внесение отметок в кадровые документы Т-2 и Т-54а будет некорректным? Данный вопрос аналогичен вопросу, рассматриваемому в п. 3.2.

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

Открытые вопросы

• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор имеет право на отпуск, согласно 128 статье Трудового кодекса
• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор не имеет право на отпуск, согласно 128 статье Трудового кодекса

Краткое обозначение элементов нотации ARIS eEPC приведено в таблице ниже (описаны не все элементы нотации, а используемые. Графическое обозначение элементов взято из пакета MS Visio):

Схема, отображающая взаимодействие элементов показана ниже:

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

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

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

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

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

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

- Я думаю, все дело в исполнителях. Достаточно найти грамотных исполнителей и мы получим хороший результат. Как в твоем примере – надо найти грамотного кадровика, только и всего.

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

- Даже если 2 000 человек и даже если специалисты будут ошибаться. Какова цена ошибки – всего-лишь неправильно оформленные кадровые документы, эти бумажки.

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

Спасибо читателям, что дошли до этого места. Можно было бы многое сказать дополнительно: рассказать про инструменты, используемые при описании бизнес-процессов, подробнее коснуться нотаций… Но это всё продолжение введения в бизнес-процессы.

Евгений Пономарёв

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

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

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

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

- собираемся с ответственным за процесс и основными участниками/ экспертами (до 3 человек);
- определяем границы процесса, участников, входы/ выходы, этапы процесса – блоки, на которые разбиваем процесс и результаты этих этапов;
- договариваемся и в итоге рисуем такую схему процесса:

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

В описании мы используем обозначения:

В результате схема процесса (этапа) выглядит так:

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

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

Мы описываем процесс так:

1. Организуем рабочее совещание участников процесса и экспертов;

2. Готовим «клейкую стену» , карточки формата A5, маркеры;

3. Определяем модератора, который ведет дискуссию, пишет и клеит карточки на стену;

4. Размечаем горизонтальные строки малярным скотчем;

5. Определяем участников процесса, записываем на карточках и клеим слева на стене в соответствующих строках;

6. Определяем (подтверждаем) вход/ выход процесса (желтые карточки);

7. Участников разбиваем на две группы, каждая группа обсуждает и пишет на карточках действия процесса от «входа» до «выхода». Раскладывает на столе;

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

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

10. Фотографируем и отдаем на оцифровку.

В итоге получаем схему в MS Visio, как на предыдущем рисунке.

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

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

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

Кейс. Как описать бизнес-процессы самому?

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

Шаг 1.

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

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

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

Рис. 1. Системный оператор.

1. НАСТОЯЩЕЕ.

1.1 Исследуемая система: бизнес-процессы.

Система бизнес процессов, особое внимание сквозным бизнес-процессам (затрагивающим работу 2 и более отделов или групп). Гибкость процессов.

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

1.2. Надсистема.

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

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

1.3. Подсистемы.

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

2. ПРОШЛОЕ 30-е гг. 20 века.

2.1. Система.

Человек на рабочем месте, инструкции руководителей (именно «инструкции»).

Одной из самых известных методологий описания организаций как организационно-технических систем, стала методология структурного анализа и проектирования систем SADT (Structured Analysis and Design Technique) . Она была разработана американцем Дугласом Россом (D. Ross) в 1973 г. Особенно широкое применение получило одно из подмножеств SADT — методология функционального моделирования IDEF0 (Integration Definition For Function Modeling). Инициатором ее разработки и дальнейшей стандартизации было Министерство обороны США. Методология IDEF0 успешно применялась в военных, коммерческих организациях для решения широкого спектра задач (от разработки программного обеспечения для оборонных систем до разработки систем материально-технического снабжения и управления финансами). Наличие возможностей и опыт применения IDEF0 в различных предметных сферах, наряду с растущей компьютерной поддержкой, сделало ее еще более доступной в использовании. Это, в свою очередь, также привело к широкому использованию IDEF0 как методологии для описания бизнес-процессов организаций. Во многом популярность методологии функционального моделирования IDEF0 обусловлена простотой нотации, основными элементами которой являются функциональный блок и стрелка.

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

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

3.2. Надсистема.

3.3. Подсистемы.

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

4. БУДУЩЕЕ.

4.1. Система.

Гибкие карты бизнес-процесса, интегрированные в CRM-системы и системы более высокого уровня (ERP-системы).

4.2. Надсистема.

Саморазвивающийся бизнес (компания), дальнейшее развитие LEAN , CRM-система, ERP-системы с интеграцией , .

4.3. Подсистемы.

Мгновенный доступ к самообновляющейся информации. Гибкая система бизнес процессов (модель), управление ответственностью, управление персоналом, регламентация процессов, автоматическая отчетность по показателям, гибкое управление эффективностью процессов. Автоматизация, роботизация, система развития компетенций, knowledge management .

Шаг 2.

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

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

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

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

1. Подсистемы: Быстрый доступ к информации. Система бизнес процессов (модель), управление ответственностью, управление персоналом, регламентация процессов, отчетность персонала, автоматизация процессов, управление эффективностью процессов. Мы видим, что бизнес-процессы должны иметь возможность быстро извлекаться из информационной среды, иметь высокую гибкость, иметь реперные точки, которые покажут, что изменится в надсистеме при изменении бизнес-процесса на уровне конкретной должности.
2. Стратегический менеджмент, система сбалансированных показателей. Бережливое производство, система менеджмента качества. Рынок, конкуренция… Относительная стабильность, постепенная, плавная смена обстановки (существенное отличие от НС «Настоящее» ).Действующее законодательство. При проектировании бизнес-процессов должна быть разработана система показателей: KPI (ключевые показатели эффективности) и управленческие индикаторы, по которым мы отслеживаем эффективность достижения KPI. Будущее показывает нам, что бизнес-процессы должны быть включены с систему управления знаниями, то есть должна быть разработана система показателей, завязанная на модель компетенций. Предусмотреть здесь отсутствие разрыва! Автоматическому сбору статистики по показателям следует уделить особое внимание, развивать культуру работы с цифрами, постепенно подготавливая систему управления к применению методов машинного обучения в будущем.

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

1. Учесть, что чувство времени у людей хоть и развилось со времен А.К. Гастева, но все же далеко от идеала, поэтому бизнес-процессы должны быть автоматизированы в CRM-системе с функцией автоматического уведомления, но в любом случае, перед тем как готовить ТЗ для CRM, куда в конечном итоге попадет описание БП, создается бумажный документ. Важно учесть, что пытаться все подряд регламентировать глупо, а в небольших компаниях такое внимание к администрированию чревато потерей бизнеса. Поэтому перед регламентацией процессов следует определить положение компании на S-кривой (удобнее всего по И. Адизесу) и исходя из этого назначить «масштаб» регламентации, то есть определить степень детализации процесса. Также важно определить степень свободы принятия решения сотрудника в изменении бизнес-процессов с целью повышения их эффективности. Как было указано выше, предусмотреть возможность оперативного изменения процесса, но с простановкой маркеров, какие из смежных процессов будут невольно затронуты. Следует предусмотреть разграничение прав доступа по изменению процессов.

1. Изучение успеха IDEF0 показывает нам, что для представления бизнес-процессов необходимо стараться максимально уходить от текстовых инструкций в пользу графики — инфографики, рисунки с короткими пояснениями. Если необходимо более подробное разъяснение, его можно дать в качестве примечания к соответствующему пункту инфограммы. Такие инструкции воспринимаются и запоминаются гораздо лучше, но здесь есть и подводные камни. Хорошая инфографика — лучший вариант с точки зрения восприятия инструкции пользователем, но у нее есть огромный минус в том, что рисовать схемы очень дорого и долго по времени. Не все сотрудники могут этим заниматься. Сегодня указанная проблема решена. В 2016 - 2017 годах происходит настоящий бум по интеграции графического отображения бизнес-процессов в CRM-системах согласно рекомендациям IDEF0. Отсюда понятно, что стоит обратить внимание на CRM-системы, обладающие именно такими возможностями и использовать их. При этом важно учесть мониторинг по показателям, указанным выше, разграничение прав доступа, сигнализацию по реперным точкам при внесении изменений.

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

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

1. При описании БП следует учесть взаимодействие между подразделениями. Именно на стыке отделов происходит наибольший дефект коммуникаций, искажение информации и различного рода сбои. Рекомендации - см. выше. Дополнительно: при определении профиля личности место не рассматривать изолировано, а посмотреть в связке с подразделениями и владельцами процессов, с которыми бизнес-процессы переплетены наиболее тесно. Задачу решать на уровне мест, в свойства материала не уходить (см. рекомендации по схематизации)!

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

Шаг 3.

Когда мы брались за эту задачу, то уже тогда понимали, что одни и те же рекомендации не могут применяться для компаний на разных этапах своего развития. Поэтому на данном шаге мы решили посмотреть, как меняется найденная нами концепция решения в зависимости от ее положения компании на S-кривой . Наилучшим образом этапы развития компании описывает S-образная кривая в концепции И. Адизеса (рис. 2):

Рис. 2. Стадии развития компании по И. Адизесу.

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

• Цели деятельности;
• Системное описание бизнес-процессов (функциональной бизнес-модели бизнеса);
• Организационная структура предприятия;
• Должностные инструкции сотрудников;
• Системы управленческой отчетности;
• Регламенты деятельности (стандартизации);
• Процедуры управления стандартами;
• Механизмы контроля исполнения стандартов на предприятии.

Теперь мы можем описать требования к БП на каждом этапе развития компании в соответствии с выбранными критериями.

1. ухаживание:

Цели: во главе стоит идея и интуиция. Бизнеса как такового еще нет, но есть огромное желание реализоваться.

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

Организационная структура: отсутствует.

Должностные инструкции: отсутствуют, все рабочие отношения строятся на словах. Должностные обязанности не прописаны.

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

Регламенты: отсутствуют.

Управление стандартами: отсутствуют.

Отсутствуют.

2. младенчество:

Цели: начинает зарождаться целеполагание, но оно строится не по методике SMART (SMART - это аббревиатура методики целеполагания и постановки задач. Расшифровка S.M.A.R.T.: Specific (цель должна быть конкретна), Measurable (измерима), Achievable (достижима), Relevant (быть релевантной, т.е. соответствовать деятельности и потребностям предприятия, уместной), Timed (определена во времени).

У руководителя не хватает навыка постановки целей и не достаточно рыночной информации, чтобы конкретизировать их. Цели звучат как лозунги: “быть №1 (или просто лучшими) в отрасли (нише)”, “занять максимальную часть рынка”, “стать лидером на рынке”, “добиться максимальной прибыли” и т.д. и т.п.

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

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

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

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

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

Управление стандартами: отсутствует.

Контроль исполнения стандартов: отсутствует.

3. Давай-давай:

Цели: цели становятся более конкретными с приходом опыта, побед и ошибок. Становятся видны перспективы развития и накапливается статистика.

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

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

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

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

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

Регламенты: руководители начинают ощущать потребность в создании регламентов деятельности и приступают создавать мини-инструкции, например, как правильно принять заявку клиента, упаковать продукт или построить разговор с клиентом (скрипты переговоров). Инструкции создаются интуитивно, носят характер затыкания “дырок” в работе (локальная стандартизация). Методика регламентации отсутствует.

Управление стандартами: регламенты не проходят в компании процедуры согласования и утверждения, спускаются “сверху” персоналу. Часто воспринимаются сотрудниками как дополнительная нагрузка и вызывают негодования по поводу того, что зачем это все нужно и так “все работают на все 100% и, не покладая рук”. Руководитель проводит стихийные обучения по мере выявления “косяков”. Считает, что сотрудники и так все должны сами знать и понимать самостоятельно.

Контроль исполнения стандартов: отсутствует.

4. юность:

Цели: цели на предприятии определяются в терминах SMART.

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

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

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

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

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

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

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

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

5. Расцвет:

Цели: цели на предприятии определяются в терминах SMART с применением системы сбалансированных показателей (финансы, маркетинг, процессы, развитие персонала).

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

Возникает необходимость проведения аналогичной работы с постоянными поставщиками/подрядчиками.

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

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

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

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

Регламентация деятельности становится корпоративной культурой.

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

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

Контроль исполнения стандартов: контроль исполнения начинает проводится в форме аудита в масштабе всей компании. Процесс контроля регламентирован.

6. Стабильность:

Цели: цели на предприятии определены в терминах SMART с применением системы сбалансированных показателей, создана система показателей эффективности деятельности компании. Цели и показатели каскадированы до каждой должности.

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

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

Должностные инструкции: корректируются и улучшаются с целью повышения качества работы персонала.

Отчетность: регулярно корректируется и дополняется создающими ценность показателями и аналитикой.

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

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

Контроль исполнения стандартов: ведется регулярное проведение аудитов.

7. Аристократия:

Цели: цели перестают пересматриваться и актуализироваться.

Бизнес-процессы: четкое администрирование стало привычкой, но пошла на спад работа по регулярному совершенствование бизнес-модели и процессов. Компания считает, что достигла совершенства, отрыва от конкурента “навечно” и начинает “почивать на лаврах”.

Организационная структура: не актуализируется. Все привыкли к существующему положению дел.

Должностные инструкции: перестают корректироваться с целью повышения качества работы персонала.

Отчетность: не корректируется и не дополняется создающими ценность показателями и аналитикой.

Регламенты: снижение активности компании в области стандартизации. Владение методикой теряется как навык. Бизнес-процессы и система автоматизации устаревает.

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

Контроль исполнения стандартов: качество проведения аудитов не контролируется.

8. охота на ведьм:

Цели: цели устарели, не актуальны.

Бизнес-процессы: потеря актуальности.

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

Должностные инструкции: перестают быть актуальными.

Отчетность: перестает быть актуальной.

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

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

Контроль исполнения стандартов: аудиты отменены.

9. Бюрократия:

Цели: цели устарели, не актуальны.

Бизнес-процессы: полная потеря актуальности и структуры бизнес-процессов.

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

Должностные инструкции: устарели, либо создаются без ориентации на бизнес-модель.

Отчетность: потеря актуальности, бесконтрольное сокращение объема отчетной информации. Уход работы “в тень”.

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

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

Контроль исполнения стандартов: отсутствует.

Шаг 4.

Это инструментальный шаг (берите и делайте).

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

При этом учтите следующее:

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

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

1. Определить положение компании на S-кривой;
2. Исходя из п.1, сформулировать цели описания БП, поставить акценты;
3. Сформулировать название процесса;
4. Провести работу над видением и целью БП;
5. Определить границы процесса (начало и конец);
6. Определить входы (ресурс) и выходы (результат) процесса в целом;
7. Назначить владельца процесса;
8. Определить состав и последовательность выполнения работ (создать цикл );
9. Определить действия , границы, входы и выходы каждого этапа;
10. Определить сроки каждого этапа;
11. Определить ответственных за каждый этап;
12. Оформить процесс документально (подготовить Стандарт).

Для удобства использования полученной концепции результат сведем в матрицу.

Таблица 1. Рекомендации по описанию бизнес-процесса в зависимости от положения компании на S-образной кривой (что должно входить в состав описания БП на различных этапах развития компании):

Сокращения:

Бизнес-процессы (БП)

Организационная структура (Орг.)

Должностные инструкции (ДИ)

Отчетность (Отч.)

Регламенты (Р)

Управление стандартами (Упр. ст.)

Контроль исполнения стандартов (КИС)

Таблица 2. Рекомендации по описанию бизнес-процесса в зависимости от положения компании на S-образной кривой (кто должен прописывать БП):

Сокращения:

“-” отсутствует;

К — команда;

Ко — консультант (эксперт).

Литература:

1. Как преодолеть кризисы менеджмента. Диагностика и решение управленческих проблем / Ицхак Калдерон Адизес — М.: Манн, Иванов и Фербер, 2014.
2. Найти идею: Ведение в ТРИЗ - теорию решения изобретательских задач / Генрих Альтшуллер - 3-е изд. - М.: Альпина Паблишерз, 2010.