Реинжиниринг бизнес-процессов

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

Менеджмент бизнес-процессов зародился в рамках концепции всеобщего управления качеством (TQM – Total Quality Management), однако, революцию в управлении бизнес процессами внесли достижения в области современных ИТ, которые дают возможность проведения инжиниринга и ренижиниринта бизнес-процессов.

Согласно определению М. Хаммера и Д. Чемпи ренижиниринг бизнес-процессов (BPR – Business process reengineering)определяется как «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения коренных улучшений в основных показателях деятельности предприятия». Целью BPR является системная реорганизация всех ресурсов, направленная на упрощение организационной структуры, повышение эффективности использования ресурсов, сокращения сроков и повышение качества обслуживания заказчиков (клиентов, потребителей). BPR возможен только на основе интегрированных (корпоративных) экономических информационных систем (КИС), которые обеспечивают поддержку управления деловыми процессами на всех уровнях. Они предполагают трансформацию системы управления на основе концепции автоматизации управления сквозными бизнес-процессами.

Инжиниринг бизнес-процессов – это периодически выполняемый реинжиниринг (3-5-7 лет), непрерывное совершенствование и адаптация бизнес процессов по отношению к внешней среде. Как правило, работы по реинжинирингу бизнес-процессов проводятся не менее чем в течение одного года. Этапы проведения реинжиниринга бизнес-процессов представлены на рис. 3.12.

На стадии идентификации бизнес-процессов выполняются следующие работы:

1. Формулирование (уточнение) миссии предприятия.

2. Определение ключевых факторов успеха (7-8 факторов): длительность, издержки, качество, сервисное обслуживание и т.д.

3. Выявление основных видов бизнес-процессов, как существующих, так и перспективных (10 – 15 процессов).

4. Оценка бизнес-процессов по степени реализации ключевых факторов успеха.

5. Ранжирование бизнес-процессов с указанием приоритетов
реинжиниринга.

6. Неформальное описание отличительных особенностей бизнес-процессов.

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

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

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

10. Определение внешних рисков обеспечения финансовыми ресурсами, надежности партнеров.

11. Обратный инжиниринг – исследование существующих бизнес-процессов.

Рис.3.12 - Этапы проведения реинжиниринга

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

Для оценки эффективности существующих бизнес-процессов используются методологииAMC - Activity Model Costing и ABC - Activity Based Costing.

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

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

Управление и планирование процесса BPR осуществляется на всех стадиях жизненного цикла проекта ремнжиниринга бизнес-процессов. Для решения этих вопросов широко используются программные средства управления проектами, такие как Microsoft Project, Process Engineer, Primavery и другие. Средства планирования и управления проектами существуют также во всех известных КИС.

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

19. Уровневые архитектуры «клиент-сервер»

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

· функции ввода и отображения данных (обеспечивают взаимодействие с пользователем);

· прикладные функции, характерные для данной предметной области;

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

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

· компонент представления отвечает за пользовательский интерфейс;

· прикладной компонент реализует алгоритм решения конкретной задачи;

· компонент управления ресурсом обеспечивает доступ к необходимым ресурсам.

Рис 5.1 - . Компоненты сетевого приложения

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

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

В любой сети, построенной на современных сетевых технологиях, присутствуют элементы клиент-серверного взаимодействия, чаще всего на основе двухзвенной архитектуры. Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовых компонентов между двумя узлами (клиентом и сервером) (рис.5.2).

Рис.5.2 - Двухзвенная (2-tier) клиент-серверная архитектура

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

Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры (рис.5.3):

· сервер терминалов — распределенное представление данных;

· файл-сервер — доступ к удаленной базе данных и файловым ресурсам;

· сервер БД — удаленное представление данных;

· сервер приложений — удаленное приложение.

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

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

Рис.5.3 – Модели клиент-серверного приложения

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

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

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

Преимущества такого подхода очевидны:

· возможно централизованное администрирование прикладных функций;

· снижение стоимости владения системой (TOC, total cost of ownership) за счет аренды сервера, а не его покупки;

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

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

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

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

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

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

1. Представление данных — на стороне клиента.

2. Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).

3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.

Рис.5.4 - Трехзвенная (3-tier) клиент-серверная архитектура

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

Рис.5.5 - Многозвенная (N-tier) клиент-серверная архитектура