Главная трудность совершенствования процессов в компаниях связана с фактором

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

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

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

Несмотря на ряд общих черт, эти подходы имеют существенные различия:

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

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

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

1. Методика быстрого анализа решения (FAST)

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

В основе этой методики лежат интуитивные методы принятия решения: коллективной экспертной оценки и коллективной генерации идей («мозговой штурм» и метод деструктивной отнесенной оценки). Типичными улучшениями при применении FAST являются снижение затрат и длительности цикла процесса. Уровень ошибок в случае принятия правильных решений снижается на 5-15% на 3-месячный период.

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

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

2. Бенчмаркинг процесса

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

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

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

3. Перепроектирование процесса

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

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

Привлекательность перепроектирования процесса обусловлена тем, что этот метод позволяет уменьшать затраты, сокращать длительность цикла процесса, проводить работы от 80 до 100 дней и снижать количество ошибок на 30-60%.

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

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

4. Инжиниринг процесса

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

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

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

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

5. Реинжиниринг бизнес-процессов (BPR)

Впервые понятие «реинжиниринг бизнес-процессов» возникло в 1990 г. в США. Авторство BPR принадлежит М. Хаммеру и Д. Чампи. Под реинжинирингом бизнес-процессов авторы понимают «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность». С этого времени BPR вызывает активный интерес специалистов в сфере менеджмента и информационных технологий.

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

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

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

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

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

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

Реализация реинжиниринга бизнеса предполагает несколько этапов:

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

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

По оценкам специалистов, в случае правильного проведения реинжиниринга процесса снижаются затраты, длительность цикла сокращается на 60-90% а уровень ошибок — на 40-70%.

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

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

• Совершенствуемые процессы должны удовлетворять современным требованиям к качеству, сервису, гибкости и низкой стоимости, а также быть понятными. Несмотря на интеграцию работ, в бизнес-процессах сохраняется требование простоты конкретного задания.
• Несколько работ объединяются в одну. Различные ранее работы (задания) интегрируются. Функции нескольких специалистов, входивших в разные подразделения, объединяются в работу, выполняемую одним человеком, имеющим доступ к экспертной системе с базой данных.
• Клиент процесса должен выполнять изменяемый процесс. Это требование, которое должны учитывать при совершенствовании процессов, предполагает, что клиент процесса должен быть больше вовлечен в процесс, чем ранее. Это достигается посредством учета требований клиента к результату и ходу процесса.
• Роль поставщика (поставщиков) процесса должна быть такой, будто они являются частью изменяемого процесса или организации. Изменение роли поставщика процесса достигается в результате установления партнерских отношений с участниками процесса или привлечения внешних поставщиков для выполнения отдельных частей процесса.
• Создаются различные версии процессов. Каждый вариант процесса ориентирован на одну соответствующую ему ситуацию (случай). К примеру, в проекте IBM процесс имеет три версии: простые случаи (данные обрабатываются компьютером, без участия специалистов); средние по сложности случаи (обрабатываются специалистами с помощью экспертной системы и базы данных); сложные случаи (обрабатываются специалистом, привлекающим экспертов). Создание различных версий или вариантов процессов — важнейший этап совершенствования; он достигается моделированием процесса. Как только имитационная модель показывает, что вновь разработанный процесс соответствует сформулированному представлению, теоретическая модель реализуется физически для подтверждения концепции.
• Стремление к уменьшению количества входов в процессы направлено на упрощение процесса и является одним из способов повышения контроля и управляемости процесса. Чтобы усовершенствовать процесс, необходимо просто убирать те выходы, которые нужно сопоставлять с другими входами, тем самым снижается количество проводимых проверок и сверок, которые не добавляют необходимой заказчику продукции.
• Ориентация на повышение автономности процессов посредством расширения децентрализации с одновременным углублением централизации обмена информацией. Расширяя децентрализацию при совершенствовании бизнес-процессов, увеличивают полномочия по принятию решений ответственных за процесс, что приводит к повышению автономности и снижению бюрократизации в управлении. Такой подход позволяет осуществлять не только горизонтальное, но и вертикальное сжатие процессов. Вертикальное сжатие происходит в результате того, что в точках процесса, где при традиционной организации работ исполнитель должен обращаться к вышестоящим управленческим уровням, принимающим решения, здесь исполнитель делает это самостоятельно.
• Создание централизованной базы данных, которая обеспечивает оперативность доступа руководителям или участникам процессов, а также расширяет возможности использования информационных технологий с целью обеспечения принятия эффективных управленческих решений.
• Направленность на сокращение временных параметров процесса. Сокращение длительности процесса — важный критерий оптимизации бизнес-процессов, направленный, прежде всего, на повышение производительности и результативности процесса.
• Устранение излишних или длинных потоков. Совершенствование устраняет ненужную, непроизводительную работу. Максимальная ориентация на уход от последовательности операций процесса с включением в него параллельно выполняемых операций позволяет ускорить процесс деятельности.
• Устранение разрывов в бизнес-процессах. Такого рода направленность позволяет устранить «разрывы» и «слепые места» в бизнес-процессах, которые достаточно часто случаются в компаниях при стихийной организации деятельности.
• Вовлечение в бизнес-процесс как можно меньшего количества ресурсов. В каждой задаче, составляющей бизнес-процесс, нужно сократить как можно больше ресурсов, например путем совмещения задач таким образом, чтобы работник выполнял наибольшее их количество. Ключевой задачей здесь является высвобождение работников и совмещение разных функций, в результате чего целые подразделения выводятся за пределы процесса.

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Автор: А.В.Казаченко

Источник: материалы сайта elitarium.ru

Без процесса не понять….

Процесс

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

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

Однако на сегодняшний день не существует универсального процесса разработки ПО – набора методик, правил и предписаний, подходящих для ПО любого вида, для любых компаний, для команд любой национальности. Каждый текущий процесс разработки, осуществляемый некоторой командой в рамках определенного проекта, имеет большое количество особенностей и индивидуальностей. Однако целесообразно перед началом проекта спланировать процесс работы, определив роли и обязанности в команде, рабочие продукты (промежуточные и финальные), порядок участия в их разработке членов команды и т.д. Будем называть это предварительное описание конкретным процессом, отличая его от плана работ, проектных спецификаций и пр. Например, в системе Microsoft Visual Team System оказывается шаблон процесса, создаваемый или адаптируемый (в случае использования стандартного) перед началом разработки. В VSTS существуют заготовки для конкретных процессов на базе CMMI, Scrum и др.

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

• информацию, правила использования, документацию и инсталляционные пакеты средств разработки, используемых в проектах компании (систем версионного контроля, средств контроля ошибок, средств программирования – различных IDE, СУБД и т.д.);
• описание практик разработки – проектного менеджмента, правил работы с заказчиком и т.д.;
• шаблоны проектных документов – технических заданий, проектных спецификаций, планов тестирования и т.д. и пр.

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

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

Совершенствование процесса

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

1. Происходит быстрая смена технологий разработки ПО, требуются изучение и внедрение новых средcтв разработки.
2. Наблюдается быстрый рост компаний и их выход на новые рынки, что требует новой организации работ.
3. Имеет место высокая конкуренция, которая требует поиска более эффективных, более экономичных способов разработки.

Что и каким образом можно улучшать.

1. Переход на новые средства разработки, языки программирования и т.д.
2. Улучшение отдельных управленческих и инженерных практик – тестирования, управления требованиями и пр.
3. Полная, комплексная перестройка всех процессов в проекте, департаменте, компании (в соответствии, например, с CMMI).
4. Сертификация компании (CMM/CMMI, ISO 9000 и пр.).

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

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

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

Pull/Push стратегии. В контексте внедрения инноваций в производственные процессы бизнес-компаний (не обязательно компаний по созданию ПО) существуют две следующие парадигмы.

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

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

Пример использования стратегии technology push – переход компании со средств структурной разработки на объектно-ориентрованные. Еще один пример использования той же стратегии – внедрение стандартов качества ISO 9000 или CMMI. В обоих этих случаях компания не решает какую-то одну проблему или ряд проблем – она хочет радикально изменить ситуацию, выйти на новые рубежи и т.д.

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

Использование стратегии organization pull менее рискованно, вносимые ею изменения в процесс менее глобальны, более локальны. Но и выгод такие инновации приносят меньше, по сравнению с удачными внедрениями в соответствии со стратегией technology push.

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

Еще одно различие обеих стратегий: в случае с organization pull, как правило, возврат инвестиций от внедрения происходит быстрее, чем в случае с technology push.

Классические модели процесса

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

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

Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности.

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

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

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

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

Виды деятельности, фактически, присутствуют, под разными названиями, в каждом методе разработки ПО. В RUP они называются рабочими процессами (work flow), в CMM – ключевыми областями процесса (key process area). Мы будем сохранять традиционные названия, принятые в том или ином методе, чтобы не создавать путаницы.

Водопадная модель была предложена в 1970 году Винстоном Ройсом. Фактически, впервые в процессе разработки ПО были выделены различные шаги разработки и поколеблены примитивные представления о разработке ПО в виде анализа системы и ее кодирования.

Были определены следующие шаги: разработка системных требований, разработка требований к ПО, анализ, проектирование, кодирование, тестирование, использование – см.
рис.
2.1.

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

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

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

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

Однако данная модель продолжает использоваться на практике – для небольших проектов или при разработке типовых систем, где итеративность не так востребована. С ее помощью удобно отслеживать разработку и осуществлять поэтапный контроль за проектом. Эта модель также часто используется в оффшорных проектах^{1От английского offshore – вне берега, в расширенном толковании – вне одной страны.}
с почасовой оплатой труда. Водопадная модель вошла в качестве составной части в другие модели и методологии, например, в MSF.

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

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

Каждый виток имеет следующую структуру (секторы):

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

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

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

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

28.06.2018

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

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

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

Рассмотрим пять основных способов совершенствования бизнес-процессов:

• Методика быстрого анализа решения (FAST). Этот образ действий нацелен на прорыв в некоей конкретной области и близок к идее «мозгового штурма». Группа специалистов в течение одного-двух дней обсуждает один определенный процесс. По итогам совещания предлагаются меры, которые позволят улучшить показатели в течение ближайших 90 дней. Какие из предложений принять, а какие отвергнуть, решает высшее руководство. Но при этом каждый из участников совещания обязан помнить, что несет личную ответственность за выработанные идеи – неудача будет свидетельствовать о непрофессионализме и может иметь негативные последствия для карьеры. Эта система была разработана и усовершенствована в таких успешных компаниях, как IBM, «Форд Мотор» и E&Y.
• Бенчмаркинг. В основе этой схемы лежит сравнение бизнес-процессов внутри организации с регламентами аналогичных действий в компаниях, добившихся лучших результатов. В ходе анализа эксперты определяют, что именно негативно влияет на работу фирмы. Исправление выявленных в итоге ошибок позволяет существенно улучшить качество товаров или услуг, повысить финансовые и иные показатели. Это довольно простой и дешевый комплекс мер, однако порой сложные задачи можно решить как раз самыми очевидными путями.
• Перепроектирование. Тот набор операций, который подлежит редактуре, внимательно изучают и изображают в виде схемы. Затем она критически анализируется и изменяется. Чаще всего при этом устраняется излишняя бюрократия и дублирующие операции, упрощаются приемы работы, внедряется автоматизация и информационные технологии. При этом в самом этом подходе существует опасность чрезмерного формализма и бюрократизации. Важно, чтобы все происходило не только в теории, но и постоянно проверялось на практике и обсуждалось с непосредственными исполнителями.
• Инжиниринг. Под этим термином понимается эволюционное развитие всех существующих операций, постепенное внедрение новых технологий, эксперименты с новыми правилами и неспешное улучшение результатов. Эта схема не приносит в бизнес больших перемен и не обещает мгновенных ярких успехов, но она необходима для того, чтобы компания шла в ногу со временем и не деградировала. В тех организациях, которыми руководят грамотные управленцы, инжиниринг ключевых процессов проводится перманентно.  
• Реинжиниринг бизнес-процессов (BPR). Business process reengineering – осуществляемое группой профессионалов радикальное перепроектирование всех хозяйственных процессов в организации. Это очень сложный и затратный проект. Поэтому к нему прибегают либо компании, находящиеся на грани краха, либо компании-лидеры, чувствующие потребность оставаться на первом месте и обновляться быстрее конкурентов. Первоначально схема каждого процесса (в первую очередь основного) создается в идеальном варианте, а затем ее оттачивают с учетом конкретных обстоятельств, финансирования и иных ресурсов. Цель команды – приблизить реальность к идеалу настолько, насколько окажется возможно. Затем все процессы согласуются между собой, создается либо обновляется корпоративная стратегия, определяются и контролируются критерии эффективности.

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

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

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

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

← Назад к списку

http://www.intuit.ru/department/se/inprogeng/

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

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

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

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

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

4. ПО развивается во времени
   – исправляются ошибки, добавляются
   новые функции, выпускаются новые версии,
   меняется его аппаратная база.

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

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

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

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

4. Нематериальность. ПО
   невозможно увидеть, оно виртуально.
   Поэтому, например, трудно воспользоваться
   технологиями, основанными на
   предварительном создании чертежей,
   успешно используемыми в других
   промышленных областях (например, в
   строительстве, машиностроении). Там на
   чертежах в схематичном виде воспроизводятся
   геометрические формы создаваемых
   объектов. Когда объект создан, эти формы
   можно увидеть. А на чем мы основываемся,
   когда изображаем ПО?

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

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

SWEBOK
(Software Engineering Body of Knowledge) —
документа, подготавливаемого
комитетом Software
Engineering Coordinating Committee, в
который вовлечено
сообщество IEEE
Computer Society. Здесь
IEEE -InstituteofElectricalandElectronicsEngineers.
Международное сообществоIEEE
Computer
Societyобъединяет специалистов в области
компьютерных наук. Назначение SWEBOK —
в объединении знаний поинженерии
программного обеспечения(разработке
программного обеспечения.
Документ делит знания по программной
инженерии на 10 областей знаний (Knowledge
Areas):

• Software Requirements — требования
  к ПО.

• Software Design — проектирование ПО.

• Software Construction — конструирование ПО.

• Software Testing — тестирование ПО.

• Software Maintenance — сопровождение ПО.

• Software Configuration Management —
  управление
  конфигурацией.

• Software Engineering Management —
  управление IT проектом.

• Software Engineering Process —
  процесс программной
  инженерии.

• Software Engineering Tools and Methods —
  методы и
  инструменты.

• Software Quality — качество ПО.

Процесс

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

На сегодняшний день не
существует универсального
процесса разработки
ПО – набора методик, правил и предписаний,
подходящих для ПО любого вида, для любых
компаний, для команд любой национальности.
Каждый текущий
процесс разработки
в рамках определенного
проекта, имеет большое
количество особенностей и индивидуальностей.
Однако целесообразно перед началом
проекта спланировать процесс работы,
определив роли и обязанности в команде,
рабочие
продукты (промежуточные
и финальные), порядок участия в их
разработке членов команды и т.д. Будем
называть это предварительное описание
конкретным процессом,
отличая его от плана работ, проектных
спецификаций и пр. Если программное
обеспечение создается в среде Microsoft
Visual
Studio
то для реализации процесса разработки
ПО используется специальное средство
Microsoft
Visual
StudioTeam
System (VSTS). При этом перед
началом разработки определяется шаблон
процесса. В VSTS существуют заготовки
таких шаблонов для конкретных процессов
на базе различных
технологий программной инженерии CMMI,
Scrum и др.

В рамках компании возможна
и полезна стандартизация всех текущих
процессов, которую будем называть
стандартным процессом.
–
Понятие стандартного
процесса введено и подробно описано в
подходе CMMI
– Capability Maturity Model Integration.
Стандартный процесс,
оказывается некоторой базой данных,
содержащей следующее:

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

описание практик разработки
– проектного менеджмента,
правил работы с заказчиком и т.д.;

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

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

Необходимо отметить, что наличие
стандартного процесса свидетельствует
о наличии «единой воли» в организации,
существующей именно на уровне процесса.

Совершенствование процесса

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

1. Происходит быстрая смена
   технологий разработки ПО, требуются
   изучение и внедрение новых средcтв
   разработки.

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

3. Имеет место высокая
   конкуренция, которая требует поиска
   более эффективных, более экономичных
   способов разработки.

Что и каким образом можно
улучшать.

1. Переход на новые средства
   разработки, языки
   программирования и
   т.д.

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

3. Полная, комплексная
   перестройка всех процессов в проекте,
   департаменте, компании (в соответствии,
   например, с CMMI).

4. Сертификация компании
   (CMM/CMMI,
   ISO 9000
   и пр.).

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

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

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

Pull/Push стратегии.
В контексте внедрения
инноваций
в производственные
процессы бизнес-компаний (не обязательно
компаний по созданию ПО) существуют две
следующие парадигмы.

1. Organization
   pull
   –
   инновации
   нацелены на решение
   конкретных проблем компании.

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

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

Пример использования
стратегии technology
push
– переход компании со
средств структурной разработки на
объектно-ориентрованные. Еще один пример
использования той же стратегии –
внедрение стандартов качества
ISO 9000
или
CMMI.
В обоих этих случаях компания не решает
какую-то одну проблему или ряд проблем
– она хочет радикально изменить ситуацию,
выйти на новые рубежи и т.д.

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

Использование стратегии
organization
pull
менее рискованно,
вносимые ею изменения в процесс менее
глобальны, более локальны. Но и выгод
такие инновации
приносят меньше, по
сравнению с удачными внедрениями в
соответствии со стратегией
technology
push.

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

Еще одно различие обеих
стратегий: в случае с
organization
pull,
как правило, возврат инвестиций от
внедрения происходит быстрее, чем в
случае с technology
push.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

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

Сегодня мы рассмотрим, почему это происходит, и как можно исправить недостатки стратегического управления.

Экспресс-тест качества системы управления компании

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



Пояснения в Telegram

 

Проблемы развития организации проистекают из практики управления

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

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

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

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

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

Почему так происходит?

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

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

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

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

Роль стратегии развития в проблемах роста организации

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

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

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

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

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

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

Отражение проблем развития организации в свойствах стратегии

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

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

Динамическая природа стратегии развития

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

Из свойства динамики вытекает свойство логической взаимосвязи всех элементов стратегии.

Внутренняя логическая взаимосвязь элементов стратегии развития

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

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

Синергия элементов стратегии развития

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

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

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

Такой когнитивно-синергетический эффект маловероятен при отсутствии внутренней логики и целостности стратегии.

Можно ли решить проблемы развития организации без стратегии

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

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

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

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

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

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

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

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

Вывод: лучше быть с гибкой и реактивной стратегией, чем гибким и реактивным без стратегии.

Составные части качественной стратегии развития

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

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

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

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

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

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

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

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

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

Ответственность за процессы разработки и реализации стратегии

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

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

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

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

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

Каскадирование как способ решения проблем развития организации

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

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

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

Почему это происходит?

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

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

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

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

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

Практические аспекты решения проблемы развития организации

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

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

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

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

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

Что это означает?

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

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

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

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

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

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

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

2. Баланс между стратегическим и операционным планированием

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

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

3. Комплексность планирования как способ решения проблемы развития организации

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

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

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

4. Внутриорганизационные коммуникации

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

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

5. Вертикальный обмен информацией и проблемы развития организации

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

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

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

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

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

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

Данная проблематика подробно представлена в онлайн-курсе по внедрению системы стратегического управления.

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

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

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

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

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

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

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

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

Литература по стратегии развития

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

1. Adrian J. Slywotzky. Value Migration: How to Think Several Moves Ahead of the Competition
2. Arthur A. Thompson, Strickland. Strategic Management: Concepts and Cases
3. Craig S. Fleisher, Babette Bensoussan. Strategic and Competitive Analysis: Methods and Techniques for Analyzing Business Competition
4. David J. Teece. Dynamic Capabilities and Strategic Management: Organizing for Innovation and Growth
5. Donald C. Hambrick and James W. Fredrickson. Are you sure you have a strategy? Academy of Management Executive, 2005, Vol. 19, No. 4
6. Göran Roos, Stephen Pike, Lisa Fernstrom. Managing Intellectual Capital in Practice

©Дмитрий Рыцев — автор является основателем проектов Strategium.Space и NooSphereum и специализируется на стратегическом управлении в своей научной и деловой деятельности.

Если вам понравилась статья, не забудьте поделиться с коллегами

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

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

Что такое бизнес-процесс в компании простыми словами

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

Но если объединить все существующие расшифровки в одну, получится следующее:

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

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

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

Что значит оптимизация бизнес-процессов

Несмотря на четкую структуру, бизнес-процесс в компании — это не конвейер. 

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

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

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

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

Что можно оптимизировать

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

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

Какие цели могут стоять перед оптимизаторами:

1. Повышение качества товаров или услуги и уровне удовлетворенности покупателей.
2. Снижение издержек и себестоимости товара.
3. Сокращение трудозатрат на выполнение задач.
4. Перераспределение ресурсов компании.
5. Повышение управляемости.
6. Автоматизация производства.

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

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

Когда необходима оптимизация управления бизнес-процессами

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

Но как понять, когда оптимизация все-таки нужна? 

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

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

Вот признаки, которые помогут понять, что с изменениями не стоит тянуть:

1. Штат увеличился, а показатели предприятия — нет.
2. Качество продукта или услуги значительно уступает конкурентам.
3. Принятие решений и их исполнение постоянно затягивается.
4. Выполнение задач требует бесконечных согласований.
5. Поставленные задачи выполняются на недостаточном уровне или выполняются совсем.
6. Нарушена связь между отделами — что приводит к непониманию или неисполнению определенных этапов работы.
7. Отсутствие единой системы взаимодействия между всеми подразделениями компании.
8. Задачи ставятся некорректно, и рабочий не понимает, что от него требуется.
9. Границы между подразделениями, руководителями и подчиненными слишком размыты.
10. Некоторые функции сотрудников или даже отделов дублируют друг друга.
11. Выполнение задач никак не контролируется, а результаты не фиксируются.
12. На выполнение рутинных задач тратится слишком много времени.

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

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

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

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

Деталей много, поэтому, для экономии времени, объединим их в четыре основных принципа:

1. Локализовать проблему

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

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

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

2. Двигаться от общего к частному

Не стоит пытаться сразу изменить весь порядок дел в компании. 

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

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

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

3. Смотреть на проблему комплексно

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

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

Если изменение значительно снизит продуктивность отдельного участка работ, лучше поискать другое решение. Исправления постфактум потребуют еще больше времени и затрат.

4. Ориентироваться на цифры, а не мнения

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

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

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

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

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

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

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

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

Определение целей оптимизации

Кажется, что ответ на вопрос «зачем вам нужна оптимизация?» очевиден — чтобы производить быстрее и делать больше денег. Но, сформулировав цель настолько абстрактно, вы никогда не поймете, какими путями её можно достичь.

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

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

Как провести подготовку к оптимизации бизнес-процессов

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

Что необходимо сделать до начала изменений:

Задача	Решение
Провести внешний и внутренний аудит	Выделить ключевые бизнес-процессы и провести SWOT-анализ — определить их сильные и слабые стороны, перспективы развития и улучшения. По возможности — собрать данные о похожих бизнес-процессах конкурентов, сравнить с процессами компании и на основе этого составить стратегию изменений.
Назначить ответственного	От руководителя проекта во многом зависит его эффективность. Нужно, чтобы в нем сочетались достаточный статус для принятия решений и подходящий характер. В качестве ответственного чаще всего выбирают топ-менеджера. При выборе руководителя низшего звена возникают дополнительные риски — например, сложности с согласованием.
Организовать проектную группу	В идеале, она должна состоять из сотрудников и специалистов извне — например, экспертов из консалтингового агентства. Первые помогут в совершенствовании существующих бизнес-процессов, а вторые — с внедрением актуальных технологий в работу. При поиске сторонней организации обращайте внимание на репутацию, а не на цену — экономия может стоить вам конфиденциальной информации!
Подобрать инструменты	В зависимости от целей и ситуации будут меняться инструменты, применяемые для усовершенствования системы. Перечислим основные: — Исключение или ликвидация — избавление от сбоев, ненужных затрат и необязательных операций. — Изменение — замена старых алгоритмов, технологий на новые, более современные. — Ускорение — увеличение скорости работы за счет автоматизации производства. — Упрощение — переход к более простому способу приема заказов и распределения задач. — Стандартизация — изучение актуальных методов работы с программами и внедрение их в производство. — Обеспечение взаимодействия — создание единой информационной системы предприятия для обеспечения слаженности действий. — Добавление — установка новых узлов, комплектующих для обеспечения непрерывности производства.

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

Пошаговая инструкция по оптимизации бизнес-процессов в компании

Хотя работа над преобразованиями во многом индивидуальна для каждой организации, существует общий алгоритм действий. Рассмотрим его последовательность:

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

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

1. Оптимизация задачи — автоматизация рутинной работы предприятия

Смысл: заменить ручной труд одной программой.

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

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

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

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

2. Оптимизация процесса — передача обязанностей потребителю

Смысл: расширение уровня самостоятельности клиента позволит избавиться от части задач и ускорить обработку заявок.

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

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

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

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

3. Оптимизация уровня процесса — отказ от согласования

Смысл: сократить срок принятия промежуточных решений за счет проверки итогов постфактум.

Польза: ускорение процесса, сокращение затрат на операционные процессы.

Вред: поздно фиксируются ненужные процессы — те, которые не приносят прибыли.

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

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

4. Оптимизация уровня процесса — выполнение задач параллельно

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

Польза: ускорение процесса.

Вред: затраты на перестройку и сбои в процессе адаптации.

Когда применять: всегда, это должно стать нормой эффективного производства.

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

5. Оптимизация уровня среды — давать возможность, когда она нужна

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

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

Вред: повышение затрат на операционные процессы.

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

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

И еще немного банальных оптимизаций:

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

Где найти еще идеи для оптимизации бизнес-процессов

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

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

Типичные ошибки оптимизации бизнес-процессов

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

Здесь перечислены самые частые промахи процесса оптимизации, которые следует избегать:

1. Начало глобальных изменений с ключевых процессов. Внедрение не обкатанных технологий может разрушить налаженный алгоритм. Сначала стоит менять те, которые не показывают результаты — и после внедрять обновления в остальные.
2. Неверная постановка цели и приоритетов. Некачественный анализ или его отсутствие заставит исправлять ошибки, которые незначительно влияют на результат, и проводить оптимизации ради оптимизации, а не улучшения показателей. 
3. Использование интуиции в качестве аргумента для принятия решений. Иногда хорошие идеи — это продукт мозгового штурма или озарения эксперта. Но не все они приведут к повышению эффективности, поэтому планы должны быть математически подкреплены — так результаты возможно будет зафиксировать и масштабировать.
4. Привлечение топ-менеджмента к проекту. Постоянное вмешательство вызовет задержки в согласовании или саботирует процесс целиком. Руководство — это наблюдатели, а принимает и контролирует решения исключительно ответственный исполнитель.
5. Внедрение готовых решений. Оптимизация — процесс индивидуальный. Ориентироваться на чужой опыт можно, но реализация решений даже в похожих организациях часто показывает разную эффективность. Любой кейс необходимо рассматривать через призму нужд конкретной организации.
6. Экономия на специалистах.  Нередко оптимизация откладывается из-за высокой цены. Но иногда без нее не обойтись — тогда руководство пытается снизить расходы. И теряет больше, чем приобретает: «эксперты», не обладающие нужными компетенциями, приведут к тратам времени и ресурсов компании. 

Ценные советы по оптимизации бизнес-процессов в организации

На что еще стоит обратить внимание перед или в процессе оптимизации: 

Обращать внимание на все детали

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

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

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

Не отказывайтесь от помощи профессионалов

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

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

Просить помощи не зазорно, если это положительно скажется на развитии вашего бизнеса.

Что потом?

Оптимизация — это не только комплексный, но и последовательный процесс. В её задачи входит в том числе предотвращение повторных проблем. 

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

Чтобы избежать негативных последствий, нужно внедрить системы мониторинга. 

Минимум — туда должна входить поддержка, регламентация процесса и контроль за его реализацией. 

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

Выдержки из книги «Оптимизация бизнес-процессов» Джеймса Харрингтона

Книга «Business Process Improvement Workbook Documentation» от H.James Harrington считается библией рационализаторов: здесь содержатся практические советы и методики, которые помогут повысить эффективность производства. 

Например, в одном из разделов автор отмечает, что в процессе оптимизации важную роль играет обучение персонала — если этот момент проигнорировать, весь процесс пойдет прахом:

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

А это отличный тезис о том, как вовлечь руководителей и сотрудников в процесс оптимизации алгоритмов предприятия:

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

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

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

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

Заключение

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

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

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

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