№146.11.Барщевский
.pdf121
Для реинжиниринга характерны следующие фазы.
1.Постановка задачи.
2.Модель компании.
3.Перепроектирование.
4.Разработка новых бизнес-процессов.
5.Разработка поддерживающей информационной системы.
6.Внедрение.
В процедуре реинжиниринга следует выделить такие составляющие:
1)упрощение (уменьшение транзакций);
2)стандартизация (форматы EDI);
3)автоматизация;
4)интеграция (координация, например, БП закупок, получения товара и расчетов с поставщиками).
Реинжиниринг в значительной мере - неформальная процедура и требует тщательного осмысления и большой аккуратности. В противном случае возможны неудачи с результатами реинжиниринга, причинами которых могут быть:
1)недостаточная четкость понимания задачи;
2)слабая мотивация;
3)неактивная позиция руководства;
4)недостаточно твердая методологическая основа. Пример реинжиниринга дан в приложении 5.
7.2.Порядок выделения бизнес-процессов
Процедура выделения бизнес-процессов связана с учетом:
1)структурных особенностей системы бизнес-функций;
2)ответственности за соответствующий бизнес-процесс;
3)времени «работы» бизнес-функций как внутри бизнес-процесса, так и при взаимодействии бизнес-процессов.
Всоответствии с основной целью перехода от подсистемного представления к процедурному представлению резонно в качестве критерия выделения бизнес-процессов принять минимум количества информационных связей между структурными элементами.
Вто же время в известных способах выделения бизнес-процессов используются такие критерии:
1) приращение стоимости с расположением основных бизнес-процессов по технологической линии;
2) использование структуры MRPII;
3) назначение ответственных за бизнес-процесс с построением матрицы ответственности;
4) ежедневная прозрачность финансовых потоков;
5) «бригадный» метод.
122
1.Приращение по стоимости применено в предложении Американского центра производительности и качества (рис. 7.2). Этот способ напрямую использует приведенное в даной работе определение бизнес-процесса. По своей структуре система бизнес-процессов похожа на рассмотренную ранее подсистемную структуру.
Разница, как отмечалось, заключается в следующем. При плановых отношениях основной задачей автоматизированной системы является выполнение плана. Экономическая оценка чаще всего отходит на второй план.
При рыночных отношениях цель автоматизированной системы – прибыль, в связи с чем в выделенных бизнес-процессах присутствуют финансовые бизнес-функциии (финансовый аспект – при планировании, бухгалтерский аспект – при учете).
В то же время использование критерия приращения стоимости не дает однозначного решения даже при использовании стандартных оболочек BAAN и SAP/R3. Так, в автоматизированной системе картонно-полиграфического комбината (КПК), базирующегося на системе BAAN, выделено три основных (заключение контракта на поставку продукции; производство продукции; реализация продукции) бизнес-процесса и шестнадцать вспомогательных бизеспроцессов. Последние просто «привязаны» к соответствующим пунктам СМК
(ИСО 9000).
2.В системе Галактика (рис. 7.3) вместо понятий «бизнес-процесс» и «бизнес-функция» введены термины «контур» и «модуль».
Понятие «контур» при этом достаточно расплывчато. Можно предположить, что контур, при неудачном его названии, это структурная единица, выделяемая по неформальному признаку с позиций последовательного предоставления пользователю для внедрения отдельных блоков - относительно законченных частей системы.
Приведенное понимание контура в какой-то мере подтверждается эволюционным изменением в системе Галактика числа контуров (четыре – в начальной версии и семь – в последних версиях).
Если модуль в какой-то степени является аналогом бизнес-функции, то связать термин «контур», который не определяется ни в документации на систему, ни при обучении персонала, с понятием «бизнес-процесс» не представляется возможным. Чтобы уйти от этой неопределенности, в Галактике «привязывают» контуры и модули к структуре и соответствующим этапам MRPII (рис. 6.9), как это описано в главе 14.
Описанный прием применяют и при разработке «своих» автоматизированных систем.
Недостатком этого способа выделения является необходимость последующей проверки правильности связей бизнес-функций с оформлением базы данных и построением графа связей функций по данным и технологии использования. Вне поля зрения метода остается и фактор времени.
3.Наличие ответственных в бизнес-процессах может быть отражено так называемой swim-схемой. Она представляет собой матрицу, в которой по горизонтали откладываются имена ответственных, а по вертикали – имена соответ-
123
ствующих бизнес-функций или бизнес-процессов. По клеткам матрицы отражается технология выполнения работ (потоки работ) при реализации бизнеспроцессов.
В swim-схеме используются следующие принципы.
1)Дорожка (вертикальная) может представлять однородные объекты (сотрудник, отдел, служба).
2)Любая функция обязательно различается на дорожке.
3)Для любой дорожки обязательны три дуги: вход, выход управление.
4)Дорожка определяется на множестве дуг «механизм».
5)«Механизм» заменяется на дополнительную исходящую дугу функции.
6)Группировка функций в фазы производится по основным функциям менеджмента и является отражением уровня сложности IDEF-схемы.
7)На схеме обязательно отмечается внешний источник данных.
8)Процесс изображается сверху вниз.
Недостаток такого способа – отсутствие фактора времени, что затрудняет анализ процессов с часто встречающимися разными масштабами времени.
4.Ежедневный контроль финансовых потоков более характерен для процедуры реинжиниринга. Метод базируется на построении схем, пример которой приведен в главе 14. По-прежнему недостатком способа является неучет фактора времени и сложности с разномасштабными по времени процессами.
5.В ряде случаев преследуют цель уменьшения количества уровней иерархической структуры управления. Для этого ряд бизнес-процессов объединяется под единое руководство, как это сделано в АСУП картоннополиграфического комбината.
Отметим, что в качестве основных критериев выделения бизнеспроцессов могут быть также:
1) простота построения «цепочек» задач АСУП в интерфейсе пользователя при компьютерной реализации автоматизированной системы;
2) минимальное количество уровней иерархии управляющей части. Перечисленные способы отличаются несистемным учетом ранее опреде-
ленных факторов выделения бизнес-процессов и их полезно упорядочить в определенную систему.
Поскольку в качестве рабочего принципа выбрано выделение бизнеспроцессов по технологическому принципу, целесообразно дать технологическую последовательность основных бизнес-процессов..
Напомним, что одной из основных причин перехода от подсистемного к процедурному представлению является ускорение процесса принятия решений. Это возможно при минимуме обмена информацией между бизнес-процессами (минимум информационных связей).
Чтобы решить такую задачу, дадим первоначально технологическую картину работы автоматизированной системы в виде укрупненных бизнеспроцессов (рис. 7.4).
Рис. 7.4 позволяет проанализировать связь задач АСУП (рис. 5.3) и биз- нес-функций (рис. 5.8).
124
Из рис. 5.3 видно, что информационных связей между функциональными подсистемами фактически минимально.
Покажем, что бизнес-процессная структура отличается от подсистемной другим распределением бизнес-функций между структурными элементами.
Одновременно предложенный подход по минимуму связей, совпадая с понятием «основной бизнес-процессс», позволяет систематизировать приведенные ранее способы выделения бизнес-процессов.
ERP (MRPII) фактически повторяет рис. 7.4.
ВГалактике в составе контуров определяют систему бизнес-функций (модулей), обращение к которым периодически повторяется.
Вавтоматизированной системе картонно-полиграфического комбината ряд основных бизнес-процессов объединяется в схеме «бригадный подряд». Однако, как показано в табл. 7.1, количество связей как между основными биз- нес-процесами, так и между основными и вспомогательными бизнеспроцессами весьма значительно.
125
126
127
В табл. 7.1 приняты следующие обозначения: Б и О – основные и вспомогательные бизнес-процессы., М бизнес-процессы менеджмента.
Анализ варианта выделения бизнес процессов Американского центра производительности и качества показывает (рис. 7.5), что количество связей между бизнес-процессами значительно и это не способствует повышению оперативности принятия решений.
Рынок
1
1 2
3
Продажи
2
1 2
Производство |
||
5 |
|
|
1 |
2 |
3 |
|
|
|
|
4 |
|
Трудовые |
||
8 |
2 |
|
1 |
||
|
||
3 |
6 |
|
4 |
5 |
Информация |
|
|
||
|
9 |
|
|
|
1 |
2 |
3 |
4 |
5 |
Улучшения |
|
|
|
|
|
13 |
|
|
|
1 |
2 |
3 |
4 |
5 |
Обслуживание |
|
7 |
|
1 |
2 |
Финансы |
|
|
10 |
|
|
1 |
2 |
4 |
|
|
|
|
3 |
|
Продукты |
|
|
3 |
|
|
1 |
2 |
3 |
|
4 |
|
|
5 |
|
|
|
Рис. 7.5. Система бизнес-процессов Американского центра производительности и качества
128
7.3.Математическая графическая модель процедурного представления
иее компьютерная поддержка
Для описания процессов в автоматизированных системах используется значительное количество моделей, в связи с чем их полезно классифицировать, например, так, как показано на рис. 7.6. Связь методов со стандартами может быть представлена в виде рис. 7.7.
Автоматизированная система
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Программный продукт |
|
|
ИПС |
|
|
ИСС |
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Подсистемное |
|
Процедурное пред- |
|
|
|
|
Учет обратной связи |
||||||
|
|
представление |
|
ставление |
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Имитационная мо- |
||||
|
|
|
|
|
|
|
БД |
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
дедь |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ДИММ |
|
Сеть |
||
|
|
Матричные |
|
IDEF, |
CASE- |
|
|
||||||||
|
|
|
|
|
|
|
Петри |
||||||||
UML |
модели, гра- |
|
ARIS |
методы |
|
|
|
|
|||||||
|
|
фические мо- |
|
|
|
|
|
|
|
|
|
|
|
|
дели
Рис. 7.6. Области применения графических моделей
TQM
QMS
Структура |
Функции |
IDEF |
ARIS |
ERP |
APS |
|
|
|
|
Имитационная |
Оптимизаци- |
|
Рис. 7.7. Связь стандартов |
модель |
онная модель |
|
|
и методов |
|
|
|
129
Для описания бизнес-процессов используют графические модели (нотации) стандартов IDEF и ARIS.
Стандарт IDEF (Icam DEFinition) насчитывает более десяти вариантов, из которых наиболее часто используются IDEF0, IDEF1, IDEF3.
Модель IDEF0 предназначена для построения функциональных моделей. Их построение возможно представить четырьмя позициями.
1. В качестве элемента модели используется функциональный блок, показанный на рис. 7.8. Связи могут быть горизонтальными и вертикальными (декомпозиция).
Рис. 7.8. Стандарт IDEF0
2.Элементы соединяются дугами (обычно сплошной линией со стрелкой). Пунктирными дугами показывают комментарии, а дугами с двойной стрелкой – потоки. Число блоков на одном уровне – 3–6, у блока число дуг каждого вида – не более четырех. Пример модели второго уровня приведен на рис. 7.9.
3.По вертикали производится декомпозиция блоков. Блок самого верхнего уровня называют контекстной диаграммой. Число уровней – не более семи.
4.Для пояснения модели создается глоссарий, включающий необходимые определения и ключевые слова.
Недостатком IDEF0 является завуалированная привязка процессов к исполнителям через вход “Механизм”.
IDEF3 является стандартом документирования технологических процессов в производстве и управлении. Последовательность процессов называют сценарием. Данная модель – фактически граф с узлами и дугами. Модель IDEF3 для рис. 6.10 показан на рис. 7.10.
В зависимости от того, что приписывается узлам и дугам, возникает две разновидности моделей.
Если процессы – узлы, а связи – дуги, то получается диаграмма описания потоков процесса (Process Flow Description Diagram – PFDD), показанная на рис. 7.11. В этом случае используются обозначения следующих логических операций (табл. 7.2).
130