Электронная библиотека

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

"Видео"
129
"Статей"
208
"Просмотров"
2234549
"Книг"
67

Введение в BPMS

Версия для печати
Дэвид М`Говеран

Дэвид М`Говеран 

"BPM и связанные с ним технологии (реализованные в BPMS) являются многообещающими и сулят многие выгоды для бизнеса. Тем не менее, в строгом соответствии со стратегией и технологией компании, использование технологий BPM и BPMS должно быть обоснованным и экономических эффективным". Статья Дэвида М`Говерана посвящена исследованию BPMS, обсуждению его ключевых функций и связей с другими технологиями. 22 Марта 2005 г.

08.11.2010
0
2948

Полный текст

Система управления бизнес-процессам (Business Process Management System - BPMS) представляет собой набор интегрированных между собой приложений, разработанных для управления бизнес-процессами (Business Process Management - BPM).

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

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

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

Категории поставщиков

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

Можно выделить восемь наиболее важных категорий поставщиков BPMS:

  1. поставщики только BPMS; изначально были созданы для разработки BPMS систем (или систем очень близких по архитектуре) и рассматривают эти продукты в качестве основных;
  2. поставщики EAI-систем (Интеграция корпоративных приложений - Enterprise Application Integration); рассматривают дополнение в виде интеграции и автоматизации процессов в качестве естественной эволюции их продуктовой линейки.
  3. поставщики Workflow-систем; будучи очень похожими на поставщиков EAI-систем, поставщики WFMS (Workflow management system) имели возможность войти на рынок BPMS с минимальными усилиями. Workflow можно рассматривать в качестве особенно четко структурированного бизнес-процесса.
  4. поставщики BPA (Business process analysis) и BPR (Business process reengineering); существующие поставщики приложений для анализа бизнес-процессов существенно подогрели свой рынок за счет интереса к BPR. Эти поставщики часто имеют значительный опыт в анализе, определении и имитационном моделировании процессов. Некоторые из них расширили возможности своих продуктов, включив в них средства для выполнения и мониторинга процессов. 
  5. поставщики EAS (Enterprise application servers) и IDE (Integrated development environment) систем. Эти поставщики считают переход на рынок BPM все более привлекательным. Первым шагом на этом пути является добавление графических возможностей (управляемых правилами или процессами) для интеграции с IDE (особенно для Web-сервисов и корпоративных Java приложений), что обеспечивает быстрое развитие приложений, основанных на процессах. Расширение этого технического взгляда на процесс требует добавления средств анализа и разработки процессов и настоящего процессного движка, который может управляться внешними факторами.
  6. поставщики корпоративных приложений; корпоративные приложения (т.е. ERP-системы) включают в себя как интегрированные средства workflow, так и некоторые возможности EAI для обеспечения кастомизации и интеграции. С учетом конкуренции на рынке, недавно они стали активно демонстрировать функциональные возможности этих приложений, расширять и активно переориентировать их, все в большей степени удовлетворяя потребности в BPMS-системах.
  7. поставщики BRE (Business rules engines), BAM (Business activity monitoring) и EEM (Enterprise event management); продукты этих поставщиков играют значительную роль в BPMS. Некоторые из них расширяют в настоящее время свои продукты, чтобы обеспечить более полный функционал BPMS. Некоторые поставщики использовали движки правил для внедрения методики управляемого правилами выполнения процесса.
  8. поставщики BI (Business intelligence) и OLAP (Online analytical processing); эти поставщики появились в качестве поставщиков BPMS в части приложений для управления эффективностью бизнеса (например, EPM - Enterprise performance management). Они начали осознавать, что поддержка BPM или workflow является необходимым функционалом, удовлетворяющим требованиям управления эффективностью. Можно ожидать, что они выдут за приделы аналитических приложений в область поддержки процессов.

Компоненты BPMS

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

  • интерфейсы пользователя;
  • BPA/М функционал;
  • исполняемые приложения;
  • BAM и EPM;
  • инфраструктура;
  • администрирование системы.

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

Инструменты BPA/M Система BPMS включает в себя набор инструментов BPA/М. Они представляют собой функциональности, при помощи которых пользователи BPMS взаимодействуют с системой. Они должны быть тесно интегрированы так, чтобы пользователь мог переключаться между ними, не теряя содержимое. Объекты, созданные при помощи этих инструментов, хранятся в репозитории, где к ним может быть получен прямой доступ при помощи исполняемого приложения. - средство моделирования бизнес-процессов.

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

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

Средство моделирования IT-настройки используется для определения и поддержания технических потоков, таких как потоки сообщений и данных, преобразование данных, управление транзакциями и т.д. Именно это средство используется с управляемой процессами системой IDE (Integrated development environment) в виде сервера приложений или поддерживающего эти приложения продукта. В идеальной BPMS оно поддерживает картирование между определениями бизнес-процессов и техническими настройками.

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

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

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

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

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

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

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

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

Компонент по выполнению анализа BPMS-системы должен быть настроен для использования в соответствующем бизнес-окружении. Библиотеки заранее запрограммированных аналитических отчетов и мастера для анализа определенных бизнес-процессов будут для такой BPMS ценным добавлением. Эти возможности часто являются существенными компонентами BAM или EPM-продуктов.

Run-time компоненты (исполняемые компоненты)

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

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

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

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

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

Движок правил может помочь менеджеру ресурсов оптимизировать присваивание ресурсов, хотя скорость выполнения подчас является критическим фактором. Заметим, также, что движок ресурсов играет важную роль в BAM и EPM, особенно в части событий, метрик и отчетов. - менеджер оборудования. Это возможность позволяет BPMS поддерживать деятельность, связанную с управлением механизмами, использующими цифровое программное управление (CNC, computerized numerical control), роботизированный интерфейсы, интерфейсы для контроля за ходом процессов и т.д. Она позволяет, например, запускать подъемные краны, закрывать каналы, производить оборудование и многое другое. - менеджер интерфейса. BPMS ничего не дает, если процессный движок не может взаимодействовать с бизнес-функциями, которые выполняются. Должна быть возможность взаимодействия потока контроля и потока данных, хотя они могут быть определены по отдельности и существенно различаться. (Это не тривиально.

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

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

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

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

Мониторинг бизнес-процессов и управление эффективностью

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

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

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

Выполнение действий могут привносить в процессы запуск новых операций, вызывать определенные события, изменять правила остановки процесса и т.п. - интеграция корпоративных информационных ресурсов. EPM и BAM требуют доступ широкому спектру источников данных. Эта функция продукта для интеграции корпоративной информации (EII), в то время как большинство BPMS продуктов (и отдельно стоящие BAM и EPM продукты) обеспечивают интегрированный доступ только к ограниченному числу источников данных. - управление контентом. Большинство данных реального бизнеса содержится в документах. Интеграция функциональности управления контентом в BAM-средство позволяет определять широкий спектр событий, связанных с изменением данных.

Инфраструктура

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

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

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

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

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

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

Заключение

Современные системы BPMS развились из простых средств автоматизации workflow с ручной поддержкой BPA/M и BAM несколько лет назад. Они поддерживают множество комплексных процессов, включающих как автоматизированные, так и ручные работы.

Поддержка BPA/M существенно улучшена. Поддержка как BAM, так и EPM продолжают развиваться. Все это весьма обнадеживает. Тем не менее, мы ожидаем несколько улучшений, которые появятся в ближайшие 4-5 лет.

Наиболее важно следующее:

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

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

Дэвид М`Говеран