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

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

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

Бизнес и экономика

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

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

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

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

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

Важно! Прибыль, как кровь для кровеносных сосудов. Она дает жизнь предприятию. Не будет прибыли - дело прекратит свое существование.

Предпринимательство и спортивный характер

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

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

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

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

Вопросы, на которые необходимо ответить:

Какие наиболее важные расходы предполагает бизнес-модель?

Какие из ключевых ресурсов самые дорогие?

Какие ключевые виды деятельности требуют наибольших затрат?

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

2 Алгоритм формализации бизнес-модели

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

Рис. 1. Алгоритм формализация бизнес-модели

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

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

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

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

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

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

Уровень 1. Определение продукта и точки монетизации

Определить продукт / услугу (Что будет продаваться на рынке).

Определить кому требуется этот продукт /услуга (потребителя).

Определить сколько потребитель может и готов платить за данный продукт / услугу

Провести сегментацию (выделить группы потребителей)

Есть ли аналоги на рынке, какие есть конкуренты

Уровень 2. Определение затрат

2.1 Определение технологию производства продукта (оказание услуги)

2.2 Определить необходимые ресурсы

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

2.4 Найти поставщиков

Уровень 3. Создание системы

3.1 Определение 9 элементов бизнес-модели

3.2 Определение взаимосвязей и процессов между элементами бизнес-модели.

Перспективы развития бизнеса

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

Выделить перспективные сегменты рынка;

Показать направления развития продуктов и технологий компании;

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

Введение 2-3

Введение

Что такое бизнес-процесс?

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

модель бизнеса .

должностные инструкции

Формализация компании

Что включает в себя понятие «формализация компании» ?

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

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

Начнем рассмотрение с концепции IDEF как более простой и доступной в виде большого числа программных продуктов, поддерживающих эту концепцию (BPWIN, БИТ-Мастер, MS Visio и др.).

IDEF технология используется, начиная с конца 1980-х годов. Department of Defense USA (Министерство обороны США) является основным пользователем данной технологии. Ею пользуются также некоторые крупные корпорации в США.

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

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

Рисунок №1. Диаграмма в формате IDEF

Каждая из сторон прямоугольника имеет свое предназначение:

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

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

Цель

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

К этим рисункам (диаграммам) нужно предъявить следующие требования:

• Они должны достаточно подробно и точно описывать логику процесса. При этом для различных сочетаний требований к «подробности и точности» желательно использовать одни и те же диаграммы.
• Они должны быть понятны, причём одинаково, различными людьми, заинтересованными в работе с этими рисунками. Это, в первую очередь, люди бизнеса (Клиенты, сотрудники организации), чью работу необходимо описать, а также бизнес-аналитики, консультанты и т.п.. В идеале, любой человек, знакомый с использованным способом описания процесса, должен правильно понимать то, что изобразили.
• Во-вторых, необходимо построить «модель» процессов, из которой можно получить не только рисунки, но и, например, текстовые отчёты о составе модели и т.п. Поэтому для описания процесса нужно используем не карандаш и бумагу или их компьютерный аналог: программу - «рисовалку» типа Adobe Photoshop, - а специальное «инструментальное средство моделирования». Традиционно под этим термином известны продукты ARISи BPWin, однако не следует ассоциировать способ описания процессов с конкретным продуктом. Более того, зависимость от конкретного продукта сегодня уже является минусом как самого способа описания бизнес-процессов, так и

что же конкретно мы хотим получить от модели бизнес-процессов?

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

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

И наоборот: наличие обратной связи от Системы к её модели замыкает контур управления Системой, делает реальностью циклическую разработку (round - trip engineering), которая сейчас является необходимым элементом любой серьёзной среды разработки автоматизированных систем.

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

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

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

Рис. 2. Пример бизнес-процесса

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

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

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

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

3. "Оплата товаров и оформление доставки". Клиент вместе со своими выбранными товарами (он везет их на тележке) следует к кассе и оплачивает то, что он выбрал. Далее, с оплаченными товарами, он переходит в отдел доставки, где оформляет и оплачивает доставку своей мебели, а также ее сборку (если ему это нужно); после этого он уезжает домой.

4. "Доставка". Оплаченные товары клиенту доставляют в течение трех дней.

5. "Сборка". После этого, если клиент оформил сборку, то к нему приезжает мастер-сборщик и собирает доставленную мебель.

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

Введение 2-3

Ø Что такое бизнес-процесс?...............................................................................................2

Ø Причины формализации бизнес-процесса…………………………………………….3

2. Формализация компании…………………………………...………………………3-6

Ø Основные проблемы формализации и методы их решения………………………….5

3. Методы описания бизнес-процесса……………………………………………….6-8

Ø Текстовый формат описания…………………………………………………………...6

Ø Табличный формат описания…………………………………………………………..7

Ø Графический формат описания………………………………………………………...7

4. Языки графического описания бизнес-процессов……………………………...8-13

Ø IDEF (Integration Definition for Function Modeling)…………………………………...8

Ø UML как средство описания бизнес-процессов………………………………………9

Ø еЕРС – событийно-функциональные диаграммы…………………………………...10

Ø Сравнительный анализ нотаций ARIS и IDEF………………………………………12

5. Описание бизнес-процессов как один из этапов автоматизации……………13-15

6. Процедурные карты……………………………………………………………….16-17

7. Пример бизнес-процесса…………………………………………………………..17-19

8. Регламентация бизнес-процесса………………………………………………….19-24

Ø Описание процесса «как есть»…………………………………………………………19

Ø Разработка показателей результативности бизнес-процесса………………………...20

Ø Определение целевых значений показателей результативности бизнес-процесса...20

Ø Формализация проблем бизнес-процесса……………………………………………..21

Ø Разработка регламента бизнес-процесса «как должно быть»………………………..21

Ø Разработка плана внедрения бизнес-процесса «как должно быть» и утверждение всего пакета документов по бизнес-процессу………………………………………...21

Ø Публикация материалов по бизнес-процессу на корпоративном портале………….22

Ø Проведение обучения основных участников бизнес-процесса……………………...22

Ø Введение бизнес-процесса в опытную эксплуатацию………………………………..23

Ø Доработка бизнес-процесса и ввод в эксплуатацию………………………………….23

9. Заключение…………………………………………………………………………….24

10. Литература…………………………………………………………………………….25

Введение

Что такое бизнес-процесс?

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

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

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

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

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

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

Причины формализации бизнес-процесса.

Необходимость в описании и оптимизации бизнес-процессов компании особенно остра, если:

Ø Структура организации не отражает реальных процессов ее функционирования

Ø У сотрудников компании нет четкого понимания того, кто и за что несет ответственность

Ø Нет четко построенных связей и взаимодействий между сотрудниками и отделами

Ø Существуют зоны безответственности или дублирования

Ø Различия в административном и функциональном подчинении приводят к проблемам и конфликтам

Ø Эффективность процессов не позволяет предупреждать отрицательные результаты и совершенствовать деятельность

Какие преимущества получает владелец, решивший формализовать свой бизнес?

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

2. Повышение прозрачности бизнеса для владельца и менеджмента.

3. Увеличение привлекательности компании для цивилизованного инвестора.

4. Рост эффективности бизнеса.

5. Возможность отойти от дел: продать бизнес или поставить наемного руководителя.

Формализация компании

Что включает в себя понятие «формализация компании» ?
В первую очередь, необходимо разделить власть в компании на два уровня: законодательную и исполнительную.

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

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

Основные проблемы формализации и методы их разрешения:

1)внутреннее сопротивление владельцев бизнеса;

2)сопротивление переменам со стороны менеджмента и сотрудников.

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

Методы описания бизнес-процесса.

Описание бизнес процессов можно проводить различными методами:

• Текстовый;
• Табличный,
• Графический.

У каждого формата есть свои преимущества и недостатки.

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

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

Графа «№» - показывает порядковый номер функции. Для описания декомпозиции процесса мо

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

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

Пример постановки процесса из 1900-х

Рабочие на заводе Форда собирают детали на конвейере. Рабочий получает 5 баксов в день и собирает 30 единиц продукции. Генри Форд в течение часа смотрит на рабочего и понимает, что тот делает много лишних действий. Он пробует сам собрать деталь по новой схеме, и понимает, что, по идее, это можно делать быстрее, но нужно чуть изменить конвейер, подвинуть оборудование, и, главное, научить рабочего совершать другие движения. Через «не хочу» он обучает этого человека делать как надо - и, вуаля! - он всё ещё продолжает получать 5 баксов в день, но производит уже 42 единицы продукции.

Привычно? Нет. Интуитивно-понятно? Нет. Выгодно? Да, если затраты на переобустройство и переобучение рабочих меньше, чем предполагаемая прибыль.

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

Хронология борьбы с бардаком

Мы прошли вот такие стадии:

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

Нужны ли процессы, если команда из 10 человек?

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

Пример 1: простой, но знакомый до боли - фича от клиента.

1. Встреча клиента и менеджера для постановки задачи.
2. Согласование критериев приёмки задания.
3. Руководитель отдела составляет техзадание разработчику.
4. Техзадание или контрольные точки согласовываются с клиентом.
5. Ведётся разработка.
6. Руководитель отдела проводит приёмку.
7. Менеджер проводит сдачу проекта клиенту.

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

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

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

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

1. Обращается к старшему точки и сообщает о проблеме.
2. Старший точки обращается к региональному координатору и сообщает о проблеме.
3. Координатор стучит к руководителю отдела АХО и сообщает о проблеме.
4. Руководитель отдела АХО ставит задачу разнорабочему.
5. Разнорабочий утверждает бюджет у своего руководителя на новую полку.
6. Финансовому директору на стол ложится счёт под подпись.
7. Наступает следующий день.
8. Рабочий наконец-то ставит новую полку.

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

Теперь та же ситуация выглядит так:

1. Продавец обращается в АХО и сообщает о проблеме.
2. Сотрудник АХО принимает решение о целесообразности использования средств.
3. Рабочий ставит новую полку.

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

Если АХО выставляет счёт, который выходит за план их отдела, генерится алерт для руководства, где есть две кнопки: «дать люлей» и «разрешить». При желании можно нажать обе. Суть механики: путь короче и быстрее, но полный контроль при этом сохраняется. Никаких лишних действий.

Метрики

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

Работу закупщика оценивать уже сложнее: но построение бизнес-процесса даёт возможность понимать, что именно дальше стало с товаром, как именно оно стало и насколько эффективно.

Косяки

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

Когда десантируются сектоиды

Говорят, у военных есть инструкции на все случаи жизни: даже если прилетит НЛО с плазменными танками, у них есть точный план действий на этот случай. Так и с процессами: в идеале они есть на все случаи жизни сотрудника. Когда у сотрудника нет плана на непредвиденный случай, происходит два события:

• Он обращается к тому, кто отвечает за этот вопрос (скорее всего, не отвлекая своего руководителя).
• Если ситуация повторяется, создаётся процесс-правило для обработки таких случаев.

Как это всё внедряется в компанию

1. Сначала аналитик разговаривает с руководителем и понимает задачу. Бывает так, что процессы внедряются для галочки, чтобы потом выгоднее продать бизнес иностранцем, бывает, что для понтов, а бывает - что для дела. Последний случай наиболее интересный и сложный.
2. Выставляется счёт, вызывающий оху когнитивный диссонанс. В этот момент нужно договариваться на такие условия, что оплата производится при повышении конкретных показателей. Грубо говоря, стали получать на 20% больше прибыли в результате внедрения - платите.
3. Затем аналитик обходит всю компанию и задаёт много-много вопросов о том, как оно работает.
4. Потом каждому сотруднику приходит анкета с просьбой указать свои выполняемые задачи (заполняется полчаса).
5. Аналитик напряжённо думает и составляет блок-схему взаимодействия, из которой растут процессы и оргсхема компании.
6. Компания реорганизовывается под новые процессы.
7. Сотрудникам доносится суть изменений. Если сотрудники в возрасте, они понимают туго, но делают сразу. Если молодые - понимают отлично, но изменяются медленно.
8. Корректируются баги. Структура меняется по мере изменения компании и её процессов.

Сроки

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

Зачем ещё нужно внедрять такие штуки

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

Резюме: плюсы и минусы

Плюсы:

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

Минусы:

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

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

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

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

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

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

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

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

Логичный вопрос: "где в этом примере автоматизация?"

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

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

Зачем тратить на это время? Может лучше внедрить какую-нибудь CRM-систему?

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

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

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

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

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

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

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

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

Ну и переход количества в качество. Это, так сказать, на сладенькое.

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

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

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

Так что перед тем, как что-то автоматизировать, крайне полезно это "что-то" формализовать.

Документы