Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

dvgu066

.pdf
Скачиваний:
31
Добавлен:
03.06.2015
Размер:
2.1 Mб
Скачать

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

Таким образом, мы приходим к объективно-необходимой интеграции ФСА, SРС и многофункциональной системы процессно-ориентированного управления производственным комплексом в целом.

Раздел 3. Реинжиниринг процессов функционирования производственной системы

3.1. Реинжиниринг: методологии функционального моделирования

Определение реинжиниринга, данное Хаммером и Чэшга в их книге "Реинжиниринг корпораций", звучит как: "фундаментальное переосмысление и радикальное перепроектирование процессов бизнеса для достижения скачкообразных усовершенствований с точки зрения решающих, современных показателей деятельности компании, таких, как затраты, качество, сервис и темпы". В данном определении вроде бы все понятно, но это только на первый взгляд. На самом деле многое здесь не определено достаточно точно, чтобы все понимали это однозначно. В частности, определения бизнес, процессы бизнеса понимаются разными специалистами по-разному. Для того, чтобы такого рода понятия как-то единообразить, формализовать в США в середине 90-х годов 20-го века было разработано семейство методологий IDEF, которое стало государственным стандартом США. В данное семейство вошли методология функционального моделирования IDEFО и методология информационного моделирования IDEF 1/Х/. Предполагалось также методология динамического моделирования IDEF 2, но стандарт на нее так и не был создан. После опубликования этого стандарта он был успешно применен в самых различных областях бизнеса в США, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов, а также в отдельных госструктурах США /ГНИ/. Собственно с широким применением стандарта IDEF / и предшествующей методологииSADT/ и связанно возникновение основных идей популярного ныне понятия –BPR /бизнес-процесс ре инжиниринг/. Особенностью рассматриваемого семейства методологий является уникальная способность "задавать вопросы" в процессе моделирования, неразрывная связь графических средств /нотаций/, методологии и технологии. С этой точки зрения семейство IDEF является системой, которая представляет не только средства отображения бизнес-процессов, но и методологию взаимодействия "аналитик-специалист", а также технологию создания проектов, охватывающую все стадии жизненного цикла - от первичного анализа до Формы представления окончательного проекта через поэтапный процесс создания диаграмм и хранения версий.

В основе нотации и методологии IDEFО лежит понятие "блока" т.е. прямоугольника, который выражает некоторую функцию бизнеса /в соответствии со стандартом функция должна быть выражена глагольным оборотом/. Как известно, прямоугольник имеет четыре стороны. В IDEFО роли /функциональное предназначение/ каждой стороны прямоугольника - блока строго определены: верхняя сторона имеет значение "управления"; левая - "входа"? правая - "выхода"; нижняя - "механизма".

23

Рис. 1 Базовый блок

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

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

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

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

принцип контекстной диаграммы;

принцип ограничения сложности.

Принцип контекстной диаграммы

Моделирование начинается с построения "контекстной диаграммы", то есть

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

24

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

Важнейшим является то, что подобный принцип должен быть применен и при построении любого функционального блока. То есть при определении ЛЮБОГО блока внутри диаграммы ЛЮБОГО уровня нужно четко иметь в виду цель моделирования и точку зрения на модель при определении "миссии" реального субъекта бизнеса, функции которого представлены данным блоком. Тем более если данный блок предназначен для дальнейшей функциональной детализации (декомпозиции).

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

Принцип ограничения сложности

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

ограничение количества блоков на одной диаграмме тремя-шестью;

ограничение количества интерфейсных дуг, входящих (выходящих) к одной стороне блока - четырьмя.

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

Используя приведенные выше базовые элементы, можно сформулировать основную идею моделирования IDEFO следующим образом:

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

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

Завершая краткий обзор методологии IDEFO можно сформулировать ее "миссию":

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

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

25

вход - "товар отгруженный";

механизм - "диспетчер по отгрузке";

управление - "инструкция по отгрузке скоропортящихся грузов";

и т.д.

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

Отсюда вытекает "миссия" методологии IDEF 1(Х) "определить, какая информация требуется для реализации функций, описанных диаграммой IDEF0".

Не имея возможности подробно останавливаться на ее рассмотрении, подчеркнем основные особенности. Методология BDEF1(X) является разновидностью методологии ER-диаграмм (Entity-Relationship - сущность-связь), строго формализованная и адаптированная для совместного использования с IDEFO как "дуальная" (двойственная) к ней, в рамках единой технологии моделирования. Двойственность методологии проявляется в том, что в рамках IDEFO мы детализируем функциональные блоки, в рамках же IDEFl(X) мы детализируем (как правило) потоки, взаимодействующие с функциями (блоками). В связи с тем, что желательно иметь возможность перенесения результатов IDEFl(X) моделирования в системы проектирования программных систем и баз данных с минимальными дополнительными затратами (собственно, для этого данная методология и создавалась), то в методологии (и особенно в ее программных реализациях) предусмотрен целый ряд мер, повышающих эффективность такой деятельности. При отсутствии непосредственной необходимости в указанном выше процессе вместо IDEFl(X) моделирования можно ограничиться детализацией объектов IDEFO моделирования на специальных листах модельной папки (так называемых FEO-диаграммах - диаграммах "Только для комментариев").

Вдополнение можно отметить, что семейство методологий IDEF предоставляет

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

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

1. Статистическое управление запасами /Statistical Inventory Control-SIC/.

2.Планирование потребности при распределенных запасах /Distribution Requirements PlanningDRP/.

3.Объемно-календарное планирование / Master Planning Shedule - MPS/.

4.Планирование материальных /производственных ресурсов / Material / Capacity Requirements PlanningMRP/ CRP/ /на основе объемно-календарного плана производства.

5.Планирование производственных ресурсов в условиях ограниченных мощностей и планирование финансовых ресурсов при этом /(Finite/Finance Requirements PlanningFCRP/FRP).

26

6.Интегрированная методология планирования, включающая в себя методологию MRP/CRP /Manufacturing Resource Planning – MRP II/. Методология используется совместно с MPS и FRP .

7.Бизнес-планирование / Enterprise Resource Planning – ERP/ виде интегрированной системы, выполняющей функции, предусмотренные системами: MPS

MRP /CRP – FRP – SIC.

8.Проектное управление / Project managment -PM/.

Все вышеуказанные методологии поддерживаются соответствующими инструментальными /программно-техническими комплексами/ средствами. Можно указать на одно из них - интегрированная программная система ARIS Toolset которая предназначена для: проектирования и управления компанией; моделирования, анализа и оценки бизнес-процессов; документирования бизнес-процессов в соответствии с требованиями международных стандартов ISO-9000 и его модификаций; разработки и внедрения корпоративной информационной системы. Инструментальное средство ARIS Toolset поддерживает более 80 моделей и методов для описания бизнесдеятельности с различных точек зрения: организации, функций, целей, продуктов, услуг, процессов, данных.

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

При проведении реинжиниринга в качестве основного средства описания текущей /as - is / и предполагаемой / to - be / схем компании, как правило, применяются модели процессов. Однако, не меньшее значение имеют я модели данных, которые, к сожалению, используются значительно реже, Именно они являются основой для понимания и адекватного представления структуры компании и конечных целей ее реорганизации,

Модель данных также может иметь версии /as - is/ и / to - be /. Когда проведение реинжиниринга сочетается с внедрением нового программного обеспечения для автоматизации бизнес-процессов, крайне важно сравнит»

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

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

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

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

рост объемов производства;

расширение ассортимента продукции или услуг;

усилия, направленные на экономию и устранение;

непроизводительных затрат;

давление конкурентов;

исправление ошибок и повторное выполнение операций;

необходимость фиксации промежуточных сведений;

27

и др.

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

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

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

Работающая модель копирует текущую деятельность компании. Это достигается путем прохождения через возможные события в режиме сжатого времени с одновременным отображением "живой" картины производственного процесса при помощи анимации. Так как программное обеспечение имитационного моделирования отслеживает статистические параметры элементов модели, оценка эффективности процесса может быть получена на основе анализа соответствующих выходных данных. Как правило, перед проектом ВР R ставится задача достижения одной или всех из числа ниже перечисленных целей: I/ повышение производительности; 2/ снижение затрат на осуществление рассматриваемого вида деятельности; 3/ сокращение общей длительности цикла процесса; 4/ сокращение времени ожидания изготовления продукта; 5/ снижение затрат на хранение материальных запасов и др.

Марк Янгблад в своей книге "Поедание шоколадного слона" приводит 32 способа достижения вышеназванных целей. Большая часть предлагаемых им принципов составляет основу проектирования промышленных систем. Они десятилетиями применялись и продолжают применяться в условиях производства. Многие из этих принципов применимы в условиях реинжиниринга бизнес-процессов: объединение дублирующих функций, устранение множественных уровней проверки и получения подтверждений, снижение размера выпускаемой партии, регулирование на основе спроса /demand pull/, передача смежникам неэффективно выполняемых функций, устранение перемещений в процессе выполнения данной операции /действия/, организация многофункциональных групп /команд/.

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

28

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

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

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

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

Процессы, связанные с работой над проектом

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

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

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

Производственные процессы

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

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

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

29

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

Распределительные процессы

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

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

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

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

Процессы обслуживания клиентов

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

Процессами обслуживания клиентов могут являться: оказание услуг по телефону (справочные центры), работа «фабрик» услуг (рестораны, центры копирования), «магазинов» услуг (госпитали, ремонтные мастерские) и универмагов.

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

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

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

Виды инструментария для имитационного моделирования

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

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

30

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

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

Process Charter и Optima.

2.Инструментарий динамического моделирования. На следующем уровне располагаются программные продукты аналогового моделирования, которые позволяют отображать динамику системы. Модели, созданные подобными продуктами, состоят из таких специфических для выбранной методологии логические структур, как уровни, стеки, потоки, преобразователи и соединители. Примеры: ithink и PowerSim.

3. Инструментарий дискретно-событийного имитационного моделирования. Наиболее развитым и мощным инструментарием имитационного моделирования

бизнес-процессов являются

программные продукты дискретно-событийного

моделирования. Эти инструменты

поддерживают моделирование потока объектов

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

Примеры: ServiceModel и SIMPROCESS.

3.2.Реинжиниринг: практические подходы к реорганизации

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

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

31

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

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

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

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

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

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

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

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

Кратко назовем эти подходы так: 1. Zero-approach.

2. Подход на основе решений.

3. Детальный анализ.

Далее будем использовать соответствующие краткие названия подходов.

3.3.Основные характеристики подходов к осуществлению реинжиниринга

Выделим основные характеристические признаки и в соответствии с ними сравним три основных подхода к осуществлению реинжиниринга.

Характер, модели

1. С помощью Zero-approach может быть построена подлинно инновационная модели с заданными характеристиками. Действующая модель работы компании при построении новой не используется (поскольку она так или иначе может повлиять на результат).

32

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