Реорганизация бизнес-процессов: как выглядит наше будущее?

Алексей Сапегин

Анализируя текущее состояние дел или столкнувшись с трудностями и обнаружив причину неудовлетворительных результатов работы, руководству фирмы, действующему по принципу: “Лучше синица в руках, чем журавль в небе”, легче постоянно “бороться с отдельными недостатками”, чем принять решение о реорганизации бизнес-процессов с целью “расшивки узких мест”. Почему это происходит? Можно найти немало примеров, когда такая позиция выглядела вполне оправданной: процесс реорганизации не только не приносил желаемых результатов, а еще больше осложнял положение компании. Однако, эти примеры, в основном, относятся к организациям, которые “решались” на реорганизацию, когда все остальные средства были уже испробованы. А это как раз тот случай, когда реорганизация хотя и жизненно необходима, но условий и времени для ее успешного проведения уже нет. Поэтому, в бизнесе, так же, как и в медицине, решающим фактором успеха часто является не только раннее обнаружение симптомов неблагополучия, но и своевременное устранение его причин. “Сегодня любая компания может оказаться вытесненной из бизнеса, если не сумеет вовремя приспособиться... Иногда на осознание необходимости преобразований требуется несколько лет, и, бывает, понимание приходит слишком поздно” - делится своими наблюдениями Билл Гейтс, президент фирмы Microsoft (ComputerWeek-Moscow, 11, 1996, с.49).

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

Пример таких корпораций, как банк Emprise в США, планировавший повысить производительность бизнес-процессов на 22% при затратах на реорганизацию в 3,5 млн. долл., а фактически добившийся роста производительности в 12-15 раз и израсходовавший на эти цели только 750 тыс. долл., показывает, что переход на новую аппаратную платформу и современную информационную технологию является необходимым, но не достаточным условием успеха. И этот успех достигается не за счет сокращения расходов, а путем резкого повышения эффективности работы на, так называемых, “интегрированных” рабочих местах и, как следствие, значительным расширением количества и спектра оказываемых услуг при непременном условии высокого качества и оперативности обслуживания клиентов. К сожалению, находясь под влиянием идеи разбиения работы на относительно простые задачи, берущей свое начало еще со времен Адама Смита, большинство людей, работающих в бизнесе, не ориентировано на процессы. Они сосредоточены на выполнении отдельных задач, поручаемых соответствующим специалистам, например, оформлении заказа, получении товаров на складе и т.д. - и имеют тенденцию терять из виду конечную цель, то-есть, доставку товаров в руки заказчика. С этой точки зрения под словами “бизнес-процесс” следует понимать всю совокупность действий, которая приводит к получению полезного для клиента результата - получению товара. В данном примере, доставка товаров потребителю и есть та ценность, которую создает процесс. Поэтому, рабочее место, которое организуется для того, чтобы обеспечить своевременную доставку товара, будет “интегрировать” в себе всю цепочку необходимых для этого действий - процесс обслуживания клиента. Так процессы порождают интегрированные рабочие места.

Ряд ведущих компаний - IBM Credit, Ford Motor и Kodak своим примером для многих открыли путь к реорганизации, ориентированной на бизнес-процессы.

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

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

В первую очередь, руководство фирмы хотело бы иметь ответы на главные вопросы: где находятся наиболее слабые и “уязвимые” места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким (кардинальным) изменениям подвергнется существующая структура организации бизнеса. Анализ “узких мест” в организации бизнес-процессов лучше всего начать с построения модели предметной области “AS-IS” - как она есть, т.е., существующей организации работы. Для создания этой модели можно воспользоваться любой из многочисленных методик моделирования процессов, которые хотя и различаются изобразительными средствами, но основаны на одном и том же подходе - использовании DFD (Data Flow Diagram) - диаграмм потоков данных. Поэтому, выбор средств моделирования и соответствующего программного обеспечения, как правило CASE (Computer-Aided Software Engineering) - автоматизированного средства проектирования, зависит от методологических предпочтений системного аналитика и опыта работы. Однако, разработанные для проектирования программного обеспечения, средства DFD ориентированы на системных аналитиков и разработчиков (программистов) и не учитывают особенностей восприятия менеджерами своей предметной области. Для описания бизнес-процессов менеджерам требуются более мощные выразительные средства, чем описание входов и выходов на диаграммах потоков данных.

С точки зрения менеджеров, наиболее подходящим языком моделирования бизнес-процессов на стадии создания моделей предметной области является IDEF0 (аббревиатура слов ICAM Definition Methods - руководства, где были описаны языки моделирования процессов - IDEF0, данных - IDEF1, позже расширен до поддержки реляционных моделей - IDEF1X и IDEF2 - для описания динамических систем). Это язык моделирования появился в результате применения SADT (Structured Analysis and Design Technique) - технологии структурного анализа и проектирования в программе интегрированной компьютеризации производства (ICAM - Integrated Computer-Aided Manufacturing), разработанной около 20 лет назад. К настоящему времени IDEF0, как язык описания бизнес-процессов, стал федеральным стандартом в США и быстро распространяется в Европе. Его успеху, в немалой степени, способствовала фирма Logic Works (США), создав на основе IDEF0 свой популярный среди менеджеров программный продукт BPwin.

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

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

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

Отмеченные в модели “AS-IS” недостатки существующей организации бизнеса можно учесть при создании модели “TO-BE” - модели новой организации бизнес-процессов.

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

Создаваемые в BPwin функциональные модели могут существенно упростить разработку проектов реорганизации бизнес-процессов с помощью средств календарного и сетевого планирования в таких распространенных программных продуктах как MS Project (Microsoft) и Time Line (Symantec). Однако, еще более эффективным является использование BPwin-моделей на первых двух этапах - планирования и анализа, жизненного цикла (включающего, также, этапы проектирования, реализации, тестирования и сопровождения) создания информационной системы. В этом случае, удается гораздо быстрее и точнее сформулировать требования к создаваемой информационной системе и проанализировать различные варианты ее реализации с использованием встроенных в BPwin средств анализа стоимости (ресурсов, затрат) по типу: “что, если...”, аналогичных применяемым в известном программном продукте EasyABC фирмы ABC Technologies (США).


Interface Ltd.

Ваши замечания и предложения направляйте по адресу:
webmaster@interface.ru

Reklama.Ru. The Banner Network.