CC BY
197
СИСТЕМЫ УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССАМИ КАК НОВАЯ ПАРАДИГМА СОЗДАНИЯ КОРПОРАТИВНЫХ ИС1
УДК 004
Игорь Григорьевич Фёдоров,
к.т.н., доцент кафедры экономических информационных систем и информационной безопасности Российский Экономический Университет им. Г.И. Плеханова E-mail: Igor.Fiodorov@mail.ru
Неправильно сводить смену парадигмы к изменению технологии, появлению новых программных и технических средств. Разработка корпоративных информационных программных сред на базе систем управления бизнес-процессы означает радикальное изменение наших взглядов на методы моделирования бизнес-процессов, способы разработки и внедрения программных систем, методы управления предприятием.
Ключевые слова: системы управления бизнес-процессами, СУБП, лучшие практики, реинжиниринг бизнес-процессов.
Igor G. Fiodorov,
PhD in Computer Science, the Department of Computer Systems in Economics, Plekhanov Russian University of Economics (PRUE)
E-mail: Igor.Fiodorov@mail.ru
BUSINESS PROCES MANGEMNET SYSTEMS AS A NEW PARADIGM OF IT DEVELOPMENT
It would be wrong to reduce the paradigm shift in IT development to a change in technology, the emergence of new software or hardware. The development of enterprise information systems based on the bPm is a radical change in our views on methods for business process modeling and for organisation management.
Keywords: business process management, BPMS, best practices, reengineering.
1. Статистика провалов при внедрении корпоративных информационных систем
В 1995 г. ассоциация Standish Group's опубликовала пугающую статистику провалов при внедрении корпоративных информационных систем (КИС) в США [1]. Авторы определяли проект по внедрению как успешный, если минимальный требуемый объем функциональности был реализован в запланированное время и за предусмотренные средства. При этом, не анализировались другие важные характеристики, например, степень управления рисками или способность адаптировать КИС под грядущие изменения условий бизнеса. Согласно полученным данным, в 1994 году 31,1% всех проектов внедрения КИС были прекращены и не доведены до конца, а вложения полностью потеряны. Еще 52,7% проектов выбились из расписания и превысили сметную стоимость более чем на 189%, при этом потери из-за неполноты внедрении и косвенные потери не учитывались. Только 16,2% проектов были признаны успешными - внедрены в назначенное время и без существенного превышения бюджета, но при этом, некоторая часть не в полном объеме. Например, для проектов крупных компаний соотношение первоначально запланированной и внедренной функциональности составляет только 42%, для компаний малого и среднего бизнеса соотношение достигает 78%. Если принять во внимание, что в 1994 г. объем затрат на внедрение КИС в США оценивался в 250 миллиардов долларов, то получается, что $81 миллиард был потрачен на проекты, которые были прекращены и деньги потеряны, еще $59 миллиард были потрачены из-за превышения бюджета.
В своих ежегодных отчетах, озаглавленных The Chaos Chronicles [2], авторы опросили более чем 5000 руководителей, проводившихся за прошедшее десятилетие проектов, зафиксировали случаи провалов, превышения бюджета, невыполнения задач в срок и т.д. Отмечается, что хотя ситуация в целом улучшалась и к 2012 году число успешных проектов возросло почти вдвое, достигнув 39%, ситуация все равно остается пугающей. Уровень прекращенных проектов остался на уровне 43%, а превышенных по бюджету и времени - 18%. Авторы задают риторический вопрос, смог бы быть коммерчески успешным производитель, например, автомобилей, если только 39% его продукции выпускалось успешно, а остальная с превышением бюджета и сроков? Ответ очевиден - конечно не смог. Статистика успехов и неудач внедрений КИС по годам представлена на рисунке 1 [2].
Рис. 1. Успех внедрения КИС
1 Работа выполнена при поддержке Минобрнауки России, в рамках базовой части государственного задания № 2014/122 шифр 2966
Аналогичные данные приводятся в отчете фирмы Forrester [3]. Приблизительно одна треть респондентов оказалась не удовлетворена временем реализации проекта внедрения КИС, такое же количество опрошенных сообщали о неудовлетворенности функционалом разработанного ПО, причем одна пятая жаловались на оба фактора сразу. В России точной статистики внедрения КИС не ведется, однако по косвенным данным ситуация в целом остается такой же, как и на мировом рынке, а может быть даже и хуже [4]. Один из главных выводов отчета заключается в разрыве между ожиданиями бизнеса и реальной достигнутой функциональностью корпоративной ИС.
Авторы цитированных выше отчетов выделяют две главные причины столь высокого уровня неудач проектов внедрения КИС: недостаточную спецификацию всех деталей на стадии проектирования и попытки внести изменения в проект на этапе исполнения. Сравним проекты, например, в строительстве и в ИТ. В первом случае все проектные нормы заранее специфицируются до мельчайших деталей, на этапе проектирования, разрабатываются максимально подробные чертежи, определяется технология изготовлении, выбираются используемые материалы. По ходу проекта никакие изменения не допускаются, отклонения пресекаются, замены запрещены. Напротив, при внедрении ИТ начальный проект делается достаточно поверхностно, детализация решения обычно недостаточно подробная, требования меняются как заказчиком, так и исполнителем вплоть до этапа реализации. Неудивительно, что такое количество внедрений КИС завершается провалом.
Индустрия ИТ пытается найти решение существующих проблем. Что бы объяснить заказчикам ситуацию и найти решение проблем, возникающих при внедрении КИС, разработчики постоянно изменяют парадигму использования бизнес-процессов. В доказательство рассмотрим ретроспективу подходов к использованию бизнес-процессов, сменявшиеся за последнее десяти-
летие. Можно выделить три сменившиеся за последние несколько лет подхода: реинжиниринг бизнес-процессов [5], лучшие практики [6], сейчас панацеей объявили управление бизнес-процессами [7]. Аналитики подтверждают, именно методы описания и способы реализации бизнес-процессов являются ключевым фактором успеха внедрения КИС. Мы рассмотрим ниже эти подходы, чтобы определить, в какой степени они способны решить первую проблему.
Вторая проблема связана с изменчивостью требований, предъявляемых к КИС. Для решения этой проблемы предлагается отойти от каскадной модели выполнения работ, в которой жестко зафиксированы фазы выполнения всех работ, и перейти к спиральной модели разработки [8] и гибкой методологии управления проектами SCRUM [9]. Необходимо проанализировать, способна ли эта методология решить проблему управления изменениями в ходе исполнения проекта.
Парадигма есть совокупность признанных всеми научных достижений, представлений и терминов, которые в течение определенного времени дают модель постановки проблем и пути их решений [10]. Изменение парадигмы принципиально изменяет подход к решению поставленной проблемы. Неправильно сводить смену парадигмы к изменению технологии, появлению новых программных и технических средств. Она заключается в коренном изменении наших взглядов на решаемую проблему, появлению новых методологий ее решения.
Целью данной работы является рассмотрения смены парадигм создания КИС, выявление новых представлений, которые смогут помочь успешному созданию и внедрению корпоративных информационных систем. Постараемся доказать, что переход на системы управления бизнес-процессами повлечет за собой следующие существенные изменения. Модели станут более точными, полными и детальными, что потребует пересмотра методик моделирования. Разработка и внедрение станут более предсказуемыми как по
времени исполнения и затраченному бюджету, так и по реализованной функциональности. Изменится парадигма управления предприятие, в центре внимания окажется операционная деятельность.
2. Реинжиниринг бизнес-процессов
М. Хаммер и Д. Чампи совершенно правильно поставили цель радикального переосмысления и коренного перепроектирования бизнес-процессов компании, однако они не ставили задачу разработки методологии моделирования бизнес-процессов. В реинжиниринге описание бизнес-процессов проводится с целью дальнейшей реорганизации. Для этого необходимо понять, как исполняется процесс, поэтому достаточно ограничиться его укрупненным описанием. Чем детальнее описание, тем сложнее оно становится для восприятия, понимания и дальнейшего согласования, поэтому многие аналитики предпочитают опускать детали, зачастую достаточно важные, ограничиваются показом только самых вероятных сценариев, опускают редкие маршруты и исключительные ситуации. Такие модели следует называть аналитическими, они кажутся простыми и понятными. Однако простота обманчива, разработчикам ИТ систем приходится повторно собирать пропущенные сведения, причем их представление о процессе может существенно отличаться от взглядов аналитика. Часто, обнаружив несоответствие модели процесса требованиям заказчика, разработчики вносят соответствующие изменения прямо в программный код и не корректируют соответствующую модель процесса. В результате этого, модель быстро теряет свою актуальность. Итак, первое противоречие заключается в недостаточной полноте описания всех сценариев исполнения и неадекватной глубине декомпозиции процесса.
В отсутствии методологии моделирования модель БП может оказаться бесполезной для заказчика, поскольку многие используемые приёмы и способы моделирования БП относятся к классу функциональ-
ных, полученные модели отвечают на вопрос «что делает предприятие», но не раскрывающих деталей о том «как оно это делает». Сложно представить себе руководителя, который бы не знал, что делает его компания. Получается, модель рассказывает то, что уже хорошо известно, но умалчивает о действительно важных вопросах. Таким образом, второе противоречие заключается в попытке перейти к процессному управлению через функциональное моделировании [11].
Но даже в тех случаях, когда существуют качественные модели, описывающие процессы компании, разработчики ИС проектируют функционально-ориентированные средства автоматизации. Давайте вспомним многочисленные примеры внедрения различных КИС, которые начинались с описания процессов, а заканчивались автоматизацией бухгалтерии, склада или отдела кадров. При этом происходит чудовищная подмена понятий - вместо «ломки границ между функциональными подразделениями», к чему нас призывают Хаммер и Чампи, функциональная автоматизация возводит крепостные стены вокруг этих подразделений. Таким образом, на лицо третье противоречие между целью и средствами ее достижения.
Недопустимо подменять цель по улучшению управляемости предприятия его автоматизацией. Хотя реинжиниринг уделяет много внимания показателям процесса, он обходит молчанием вопрос управления этими показателями. Реинжиниринг рассматривается как однократный акт по улучшению показателей, но не как постоянная деятельность по поддержанию показателей в норме. КИС, где автоматизация оказалась впереди управления, страдают от однобокости, позволяя контролировать только ограниченный набор метрик. Они не годятся для целей операционного управления, хотя именно оно обеспечит огромный потенциал повышения эффективности.
Идеи реинжиниринга являются абсолютно правильными, но их оказалось недостаточно, чтобы решить наболевшие практические проблемы.
3. Лучшие практики
Осознав, что в отсутствии методологии моделирования создать качественную схему, описывающий работу компании не удается, лидеры индустрии ПО предложили отказаться от подстройки программы под процессы заказчика, а вместо этого подстраивать работу заказчика в соответствии с заранее созданными и запрограммированными моделями бизнес-процессов передового опыта. Лучшая практика это формализация уникального успешного практического опыта с целью повторного его использования в аналогичных ситуациях [6]. В литературе по менеджменту англ. термин часто переводится на русский как передовой опыт.
Раньше разработчики разрабатывали ПО индивидуально для каждого заказчика в отдельности, теперь они зашивают процессы в КИС, делая их неразделимыми от программного кода. Лучшие практики реализуют представление разработчика о том, как наиболее эффективно исполнять бизнес-процесс [12]. Как считают авторы исследования, проведенного в университете Людвигсхафена, опросившие 192 ИТ руководителя предприятий, внедрявших ERP SAP, этот подход помог сократить время реализации проекта на 22%, так что в среднем оно составило 12 месяцев, стоимость внедрения уменьшилась на 20%, совокупная стоимость владения на 11%, а риски на 71%. Примечательно, что только 40% опрошенных оказались удовлетворены функциональностью, реализованной в КИС, остальным потребовались изменения.
Как отмечается в исследовании Panorama Consulting, в отдельных сферах бизнеса, например, в области управления человеческими ресурса-
ми, использование «чужих» лучших практик оправдано, однако в большинстве случаев, внедряя передовой опыт, компания рискует потерять свои конкурентные преимущества [13]. Предприятия, безоглядно внедряющие чужие процессы, рискуют погрязнуть в трудоемкой и тяжелой работе по собственной реорганизации. По данным этого исследования, почти 90% респондентов меняли процессы лучших практик, зашитые в КИС.
Авторы исследовали отношения организаций, внедряющих КИС к собственным бизнес-процессам и установили, что 38% брали за основу процессы лучших практик, реализованные в КИС, подстраивали под них свои процессы; 21% респондентов не заостряли внимания на бизнес-процессах, не считали их критическим фактором успеха внедрения; 29% респондентов пытались настроить КИС на собственные бизнес-процессы; наконец 12% опрошенных полагали, что их существующие процессы представляют для них существенную ценность и выбирали КИС, которая бы позволила реализовать их собственные процессы (см. рис. 2.). Авторы утверждают, что предприятие, внедряющее КИС, должно с самого начала сделать выбор, как оно планирует развивать далее свои процессы. Только после этого можно подходить к выбору системы и методики внедрения.
Будем разделять понятия лучшие практики и стандартизация процесса. Ф. Тейлор сформулировал положение, что «среди всего многообразия методов и инструментов, используемых в каждый момент каждого процесса, всегда есть один метод и инструмент, который работает быстрее и лучше остальных» [14].
% участников опроса ■ Заменяли свои бизнес-процессы на
процессы лучших практик КИС (38%)
■ Не фокусировали внимания на своих
бизнес-процессах, не считая их
Ж 38% критическим фактором успеха (21 %)
ООО/ ■ Пытались насторить КИС на свои бизнес-
¿У /о процессы (29%)
■ Выбирали подходящую КИС для
^ 21% существующих бизнес-процессов (12%)
Рис. 2. Подстраивать процессы под КИС или КИС под процессы
Как отметил М. Имаи - «невозможно заниматься совершенствованием процесса, пока он не стандартизован, иначе любое усовершенствование будет представлять собой еще один вариант исполнения процесса, который иногда используется, но большей частью выпускается из вида» [15]. Стандартизация - это выбор из всего многообразия способов исполнения работ компании такого, который наиболее оптимально соответствует потребностям данного предприятия. Однако остается под большим вопросом, кто и на основании каких критериев оценивал качество процессов передового опыта? Достаточно сложно ответить на вопрос, насколько способ достижения цели, оказавшийся эффективным в одном месте, оказаться столь же эффективным и в другом?
Следует различать лучшие практики и справочные модели процесса [11]. Последняя представляет собой «идеальный» взгляд на деятельность организации. Две компании, работающие в одной сфере бизнеса, выполняют одинаковые наборы действий, однако очередность операций в них может отличаться, поскольку предприятия обладают различной организационной структурой, про-извод с твен но й культу р ой и т.д . Справочная модель есть каталог функций, иерархически организованный справочник работ, в котором перечислены все действия, выполняемые субъектами. Имея «полный» набор функций, можно скомпоновать систему, применяя повторно используемые компоненты.
Из сказанного можно сделать два вывода: не следует отказываться от лучших практик выполнения процессов, но и не следует слепо копировать этот опыт, бездумно переносить его на другую компанию. Анализ чужого передового и оценка его применимости в данной ситуации опыта есть главнейшие задачи реинжиниринга. Но, как было отмечено выше, работа по улучшению процессов должна стать постоянной и непрерывной. Поскольку лучшие практики не стали панацеей от проблем внедрения КИС, вендоры изобрели новую парадигму, она называется управлении бизнес-процессами [16].
4. Системы управления бизнес-процессами
Под системами управления бизнес-процессами (СУБП) обычно понимают (а) методологию реорганизации и оптимизации бизнес-процессов, направленную на управление бизнесом путем непрерывной оптимизации бизнес процессов через реализацию замкнутого цикла их моделирования, исполнения и анализа, (б) программное обеспечение - инструментарий, преобразующий графическую модель бизнес-процесса в исполняемую форму. СУБП относятся к двум классам: процес-сно-ориентированным и управляемым моделью. Они предназначены, чтобы организовать эффективное взаимодействие всех участников процесса, позволяют контролировать выполнение заданий, как по времени, так и по качеству в соответствии с заранее определенными критериями, помогают владельцу процесса преодолеть результаты отклонений, возникающих в ходе исполнения процесса.
Логика работы таких систем полностью основывается на исполняемой визуальной модели бизнес-процесса, программирование требуется для описания нестандартных ситуаций. Исполняемая модель бизнес-процесса - это описание участников процесса: людей и машин, а также порядка и времени выполняемых ими операций и действий, которое может быть использовано для автоматизации взаимодействия участников друг с другом и машинами без дополнительного кодирования и программирования [7]. Исполняемая модель бизнес-процесса должна реализовывать полный и точный алгоритм работы системы, в математическом смысле этого слова. Для этого она обязана показывать все возможные маршруты исполнения процесса, иначе работа соответствующей системы окажется невозможной.
5. Исполняемая модель бизнес-процесса
В отличие от аналитической модели, показывающей только некоторые маршруты, по которым исполняются наибольшее число про-
цессов, исполняемая модель должна описывать все сценарии исполнения, включая замедляющие переходы назад для повторной обработки и ускоряющие вперед, в обход операций, особые и исключительные ситуации, например, отказ клиента от своего заказа, недоступность требуемой информации или ресурса. Должны учитываться нестандартные ситуации, когда по прямому указанию менеджмента процесс исполнятся в обход существующих правил и ограничений в режиме ручного управления и исключения, описывающие реакцию системы на нештатную или ошибочную ситуация. Аналитическая модель процесса имеет право на существование, когда планируется разработать функциональную информационную систему, где человек определяет порядок исполнения операций. Но мы строим процес-сно-ориентированную систему, где порядок операций определяется системой, следовательно, модель должна покрывать все возможные сценарии исполнения иначе работа окажется невозможной [17].
Аналитические модели часто имеют ограниченную глубину детализации, определяя общий порядок следования работ, но не описывая деталей исполнения. Такой подход обоснован, если предположить, что исполнитель хорошо знает состав действий, образующих операцию. Однако, в большинстве случаев, специалисты склонны варьировать свои действия в соответствии с индивидуальным опытом, полученным в компаниях с отличной организацией процесса или уровнем автоматизации. Разрабатывая исполняемую модель процесса, аналитик должен описать процесс значительно более детально, опускаясь на уровень элементарных действий. Существующая рекомендация аналитикам, ограничиваться 7 уровнями декомпозиции является умозрительной, не имеет иного обоснования, чем магическое число семь, описанное Миллером [18]. Исполняемая модель должна иметь глубину декомпозиции до уровня элементарных действий исполнителя, а число уровней определяется архитектурой процесса.
Главный вывод заключается в том, что не следует рассматривать СУБП только как новую ИТ технологию и методологию управления, помимо этого она представляет собой новый подход к моделированию бизнес-процессов. Исполняемая модель требует принципиально новых методов моделирования, которые обеспечат полноту, требуемую детализацию и корректность модели. Если модель окажется неточной, ее исполнение окажется невозможной.
6. Спиральная модель разработки СУБП
Благодаря свойству моделе-ори-ентированности, СУБП позволяют реализовать замкнутый цикл Демин-га-Шухарта, что, в конечном счете, означает пригодность для деятельности по непрерывному улучшению процессов. Используемый при реализации СУБП проектов подход наиболее близок по подходам современной методологии экстремального программирования. Обоим присущи следующие особенности:
• Короткий цикл обратной связи
• Разработка через тестирование
• Игра в планирование
• Заказчик всегда рядом
• Непрерывный, а не пакетный процесс
• Непрерывная интеграция
• Частые небольшие релизы
Создание СУБП осуществляется
на основе спиральной модели жизненного цикла информационных систем [7]. Эта модель уделяет повышенное внимание анализу рисков, влияющих на достижение результатов разработки и, для этого, предлагает сосредоточиться на идентификации требований и ограничений на их достижение. Предлагается отбрасывать необоснованные, неисполнимые или рискованные требования и альтернативы, а обоснованные требования ранжировать по степени их значимости для заказчика. Методология спиральной разработки в СУБП предполагает доминанту бизнес логики процесса над презентационной логикой и интеграцией. Это означает, что бизнес-аналитик должен вначале выявить бизнес логику, убедиться, что процесс оперирует необходимыми данными
и лишь заем переходить к моделированию презентационной логики и описывать интеграцию. Работа начинается с проектирования моделей, описывающих частные перспективы, создания интегрированной модели бизнес-процесса. Интегрированная модель процесса является исполняемой, м.б. запущена в СУБП без дополнительного программирования.
Важнейшим этапом проверки бизнес логики есть процедура валидации, позволяющая удостовериться, что логика работы соответствует представлениям конечного пользователя о будущей системе. Она осуществляется с использованием прототипа СУБП, базирующегося на исполняемой модели бизнес-процесса в СУБП. Для валидации достаточно простейших пользовательских интерфейсов, автоматически создаваемых СУБП. Интеграция на этом этапе осуществляется с помощью программных заглушек, реализующих режим ручного ввода данных. Дело в том, что проверка полноты данных на экранных формах должна осуществляться до начала работ графическому оформлению этих экранных форм
В отличие от метода читатель-писатель, применяемого при классическом реинжиниринге, валидация путем прототипирования позволяет быстро и точно проверить логику процесса. Этапы разработки СУБП и участие в них бизнес-аналитика и разработчика показаны на рис. 3. Только после завершения валидации можно переходить к графическому оформлению экранных форм и интеграции процесса в ИТ инфраструктуру предприятия. Эти этапы так же
выполняются итерационно, периодически приходится возвращаться на предыдущий шаг с целью внесения изменений в исходную модель.
Такой подход к разработке обеспечивает высокое качество получаемой модели, сокращает время и средства, затрачиваемые на разработку, упрощает внесение изменений. Последнее свойство обладает двояким эффектом. С одной стороны, оно позволяет нивелировать сложности, возникающие при изменении требований, с другой - способствует размыванию первоначальных границ проекта. Дело в том, что спиральная модель разработки не предполагает различий между разработкой программного продукта и его сопровождением. Положительное свойство метода в том, что он предлагает рассматривать поддержку, как развитие и доработку системы. В то же время, этот подход затрудняет фиксацию окончательной функциональности в исходном задании на систему. Как следствие, у заказчика могут возникнуть ложные представления о трудозатратах и стоимости реализации полного проекта.
Несмотря на описанные сложности, можно сделать вывод, что методы создания систем управления бизнес-процессами в наибольшей степени соответствуют современной парадигме спиральной разработки, базирующейся на выпуске частых релизах с ограниченной функциональностью каждого. Используя приоритезацию требований, удается выделить те из них, которые критически необходимы для эффективной работы предприятия, отбросить
Обнаружение процесса Моделирование Создание Прототипа Валидация Доработка модели Опытная Эксплуатация
Артефакты модели СН - 1 1 1 1 г
Модель процесса нпп в ■ ___|
Исполняемая модель У 1шЧг г
Пользовательский интерфейс 9 13 1!1 ЯП
Интеграция с приложениями С ■III
Система Управления Бизнес Процессами и*.
Рис. 3. Методология выявления процесса и создания СУБП
другие, которые не несут за собой явных улучшений, но увеличивают трудоемкость работ.
7. Место и роль СУБП в ИТ ландшафте предприятия
Большинство существующих КИС (ERP, CRM, БИС и т.д.) разрабатывались как функциональные и учетно-аналитические. Они автоматизируют необходимый набор функций, при этом порядок исполнения заданий определяется вручную оператором. Их сила заключается в средствах сбора и анализа информации на долгосрочном временном интервале. Они фиксируют случившееся, помогают проанализировать работу компании за отчетный период, в отдельных случаях могут оповестить об некоторых событиях, но сами не пытаются управлять производственным процесс, т.е. по сути являются пассивными. Процессный подход предполагает создание активных управляющих систем.
Договоримся различать управление предприятием с использованием бизнес-процессов и управление собственно процессами. Управление предприятием с использованием бизнес-процессов есть деятельность, направленная на получение синерге-тического эффекта от скоординированных действий организационных единиц компании. Этот вид управления имеет общее название - процессный подход и достаточно подробно описан в литературе. Управление собственно бизнес-процессами есть деятельность, направленная на преодоление результатов отклонений, возникших в ходе исполнения процесса. Оно включает выявление отклонений в каждом производственном задании, выяснение причин их возникновения, выработку действий по их корректировке. Таким образом, СУБП помогает осуществлять управление на нескольких уровнях, вплоть до управления отдельным производственным заданием. Можно говорить, что традиционная КИС дает картину происходящего в реальном времени, а СУБП позволяет управлять компанией в реальном масштабе времени. Это потребует, в частности, изменения моделей бизнес-процессов, они должны содер-
жать средства контроля отклонений от нормального исполнения, инструменты, реализующие контрольные мероприятия, предназначенные, что бы вернуть исполнение в норму.
Таким образом, можно сделать вывод, что СУБП следует рассматривать как новую парадигму управления предприятием. При этом нельзя считать, что СУБП заменит на предприятиях «корпоративные» системы. Системы СУБП не предназначены для долговременного хранения результатов, они не слишком удобны для анализа показателей продукта. Как показывает практика, конвергенция СУБП и корпоративных информационных систем рассматривается как фактор получения основных конкурентных преимуществ [19].
8. Выводы
Организации, которые ставят амбициозные задачи развития, рано или поздно должны выбрать для себя стратегию развития: экстенсивную, за счет количественного увеличения факторов производства или интенсивную — за счет использования все более эффективных средств производства. Хорошо известно, что при реализации экстенсивной стратегии, организация столкнется с ситуацией, когда усилия на координацию действий сотрудников становятся сопоставимы с эффектом от их деятельности.
Мы привыкли думать, что переход от экстенсивного к интенсивному пути развития лежит через автоматизацию. Прискорбно, но автоматизация позволяет сократить расходы на выполнение отдельных операций, тогда как основные проблема лежит в области координации выполнения работ - межфункциональном взаимодействии подразделений. Автоматизация это однократный акт, направленный на улучшение выбранных характеристик процесса. Управление это постоянная деятельность по мониторингу показателей исполнения процесса и выполнению корректирующих воздействий, с целью не допустить отклонений.
Неправильно сводить СУБП исключительно к новой технологии, реализующей моделе-ориентирован-ный способ разработки или к мето-
дологии процессного управления предприятием. Парадигма СУБП предполагает новую методологию описания бизнес-процессов. Последняя предполагает переход от аналитического моделирования к созданию исполняемых моделей. Аналитическая модель отличается высокой точность и детальностью, глубиной декомпозиции, причем вопросы качества модели определяются на индивидуально аналитиком,
СУБП реализуют новую парадигму управления, смещая фокус на операционный уровень, обеспечивая контроль за исполнением отдельного экземпляра производственного процесса. Это позволит высвободить труд руководителей, которые сегодня тратят существенную долю своего времени на рутинные операции контроль за исполнением заданий подчиненными, позволит им сконцентрировать больше внимания на более важных задачах.
Наконец СУБП соответствует новой парадигме создания и внедрения информационных систем, основывающейся на выпуске частых релизов с ограниченной функциональностью каждого и приоретизации требований. Таким образом удается в наилучшей степени выделить и реализовать именно ту функциональность КИС, которая явно ведет к повышению эффективности, отбросить второстепенные и несущественные требования.
Оценивая в целом эффект, который может принести новая парадигма создания и внедрения СУБП, можно воспользоваться оценками Gartner [20], которые показали, что 67% всех проектов СУБП были успешно завершены менее чем за 4 месяцев, в т.ч 50% менее чем за 1 месяц, все проекты имели ROI более 10%, в т.ч. 78% имели ROI более 15%.
Литература
1. The Standish Group Report, «Chaos,» The Standish Group, 1995.
2. The Standish Group, «Chaos Manifesto 2013,» The Standish Group, 2013.
3. Forrester Report, «Corporate Software Development Fails to Satisfy on Speed or Quality,» Forrester Research, April 11, 2005.
4. Смородина Т., «Клиент всегда не прав,» «Эксперт», №21 (281), Июнь 2001.
5. Тельнов Ю. Реинжиниринг бизнес-процессов. Финансы и статистика, 2003.
6. O'Dell C. G.C., «If Only We Knew What We Know,» California Management Review , Vol. 40, No. 3, SPRING 1998.
7. Фёдоров И. Процессно-ори-ентированные информационные системы // In: Информационные системы и технологии. Юнити-Да-на, 2012.
8. Boehm B., «A Spiral Model of Software Development and Enhancement,» Computer, May 1988. pp. 61-72. May 1988.
9. Кон М. Scrum: гибкая разработка ПО. Москва: Вильямс, 2011.
10. Кун Т. Структура научных революций. - М.: 2009, АСТ, 2009.
11. Тельнов Ю.Ф., Федоров И.Г., «Функциональные и процессные модели бизнес-процессов» Экономика, Статистика, Информатика, Вестник УМО №. 2, 2012.
12. Monk E. Wagner B. Concepts in enterprise resource planning. Thomson Course Technolog, 2006.
13. Consulting AP, «2013 ERP Report: Organizational change and business process management,» Solutions Research Report 2013.
14. Нив Г. Пространство доктора Деминга: Принципы построения устойчивого бизнеса. - М.: Альпина Бизнес Букс, 2005.
15. Имаи М. Кайдзен: ключ к успеху японских компаний, - М.: Альпина Бизнес Букс, 2004.
16. Sutherland J. S.K.. The Crisis in Software: The Wrong Process Produces the Wrong Results. J. Wiley & Sons.
17. Фёдоров И., «Интегрированная модель бизнес-процессов» Открытые системы, №. 9, 2012.
18. Miller G., «The Magical Number Seven, Plus or Minus Two,» The Psychological Review, Vol. 63, 1956. с. 81-97.
19. Белайчук А. BPM, SOA и новый IT-ландшафт // ИТ для финансового бизнеса: от интеграции приложений к интегрированным сервисам [Электронное издание]
20. Sinur J., «Justifying BPM Projects,» Gartner Inc., 2004.
21. Минцберг Г. Структура в кулаке: создание эффективной организации. Издательский дом «Питер», 2004.
