Литература:

• Статьи
• Обзоры:    0    0    17    16    15    14    13    12    11    10    9    8    7    6    5    4    3    2    1  
• Форумы
• Стандарты
• Книги
• Авторы

Отзыв о VI Форуме BPM

В среду, 14 декабря, в Москве прошел VI Форум по BPM, проводимый AHConferences.

Первое, что приятно удивило – новые докладчики и, соответственно, доклады. То есть не несколько новых, а практически все (кроме двух). Некоторые доклады показались очень интересными, о них расскажу подробнее.

Алексей Борисов, директор по развитию, Software AG в России и СНГ, выступавший первым, в начале своего доклада, как обычно, рассказывал про ARIS, WebMethods и всю продуктовую линейку. А вот во второй части он поделился результатами исследования, которое провели три компании – Software AG, IDC Россия и Global CIO в мае-октябре 2011 г. В исследовании приняли участие 445 респондентов. Кратко по интересным фактам:

Из результатов опроса видно, что в 43% из опрошенных компаний описаны ключевые процессы, в 30% - описаны единичные процессы, в 4% - описаны все (!) процессы. А 12% и 11% собираются и вообще не собираются этого делать соответственно. Для какой цели описываются процессы? 70% ответили, что для дальнейшей автоматизации, 60% - для регламентации и оптимизации. В 51% компаний нет подразделений, отвечающих за описание и оптимизацию процессов (хотя интересно, борьба с функциональным управлением путем создания еще одной функциональной единицы – это «клин клином»?). В 38% существует, в 9% планируется, а вот в 2% компаний такое подразделение уже расформировано. Следующий вопрос, на самом деле, более показательный: назначены ли в компании владельцы процессов? В 58% владельцами процессов являются руководители функциональных подразделений «по долгу службы», в 29% - назначены. (Что ж, не так уж плохо). Были также вопросы, касающиеся частоты изменений процессов, поддержки со стороны бизнеса, использования инструментария и т.д. В целом опрос показал, что медленно, но верно BPM свои позиции укрепляет.

Интересный, цельный доклад «Bitter BPM: в чем причины неудач внедрения BPM» представил ИТ архитектор BNP Paribas Group Алексей Букавнев. Он высказал сомнение по поводу оптимизма многих исследователей, в том числе и Gartner, о том, то большинство проектов BPM являются успешными. Алексей считает, что если проект выходит за рамки бюджета либо не укладывается в запланированные временные рамки, то такой проект не может считаться успешным. Утверждение спорное, но причины провалов, которые назвал Алексей, проясняют его позицию. Особенно ценно, что Алексей не просто перечисляет причины неудач, но и предлагает пути их преодоления.

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

Существенная причина, которую можно ставить на первой место в топ-10 – это отсутствие в организации методологии разработки и оптимизации бизнес-процессов. Алексей советует адаптировать существующие методологии, такие как, скажем, «Six Sigma + Lean», под реалии конкретной организации.

Симптомами провала можно считать «бесконечный», тянущийся многие месяцы проект, без ввода бизнес-процесса в production–среду. Ожидание большого взрыва (Big Bang) вместо непрерывных улучшений (Continuous Improvement) – порочная практика. Лучше запустить работающий процесс, пусть не самый оптимальный, а дальше его улучшать, чем дожидаться, когда он устареет и потеряет актуальность.

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

Среди причин называются также непрозрачность для топ-менеджмента, отсутствие «драйвера» проекта со стороны бизнеса, перегибы типа BPM, как игрушка ИТ либо BPM  без автоматизации, а также проблема кадров.

Директор департамента системных платформ и архитектуры компании Диасофт Константин Варов рассказал об их опыте внедрения BPM в российских банках. Доклад так и назывался, «Опыт использования BPM-подхода для автоматизации бизнеса в российском финансовом секторе».

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

Следующий доклад «Опыт применение BPM для построения фронт-офисной системы страховой компании», представленный Павлом Селезневым, начальником управления начальником управления фронт-офисных систем компании Кит Финанс Страхования, на 2/3 состоял из описания деятельности компании (вероятно, чтобы дать прочувствовать слушателям, насколько важен BPM для страховой компании). Ну и дальше немного сумбурно, с пропуском части слайдов, о самом BPM. Как выбирали (выбрали flextera от Диасофт) и как теперь жить хорошо.

Генеральный директор Астерос Лабс Алексей Демидов в начале своего доклада (доклад назывался «Платформа автоматизации бизнес-процессов клиентского обслуживания») обрисовал текущую ситуацию – клиентоориентированную экономику, тенденции к укрупнению компаний, зависимость мировой экономики от ИТ. Дальше он рассказал о семействе продуктов Астерос Контакт – платформу отраслевых приложений.

Юрий Лиц, руководитель отдела бизнес-систем и ИТ компании VELUX делал доклад о «Реализации Lean-проектов в sales-компаниях». По сравнению с докладом, который он делал на конференции CNews, в этот раз Юрий уделил больше внимания теме BPM, что явно пошло докладу (или слушателям) на пользу. Юрий выбрал в качестве ключевой темы доклада тезис – как продать BPM в торговой компании (имея в ввиду, разумеется, продажу идеи BPM бизнесу). Основная идея – заинтересовать бизнес правильной подачей. К примеру, вместо повышения качества говорить о сокращении расходов, вместо повышения скорости – о конкурентном преимуществе, а вместо контроля над процессами – об увеличении эффективности метрик и показателей. Юрий, как специалист Lean, как никто может оценить привязку Lean к BPM. Кстати, они и называют свои проекты «Lean и BPM проекты». Наполненные методологическим содержанием, BPM проекты имеют все шансы стать успешными. Тем более, что основных ошибок, таких как ограничение рамками одного подразделения, начало проектов BPM с автоматизации, фиксация процессов они избегают. 

Доклад неплохой, но 40 минут – это перебор. Под конец доклада народ «потерялся». Правда, к вопросам снова оживился. И, как показали вопросы, реализация методологии (и не обязательно Lean) больше волнует, нежели вопросы технологические, с которыми уже более-менее все понятно.

Доклад Сергея Гарбука, начальника Центра информационных технологий оборонопромышленного комплекса, ФГУП НИИСУ Минпромторга России «BPM в контексте стандартов менеджмента качества серии ISO 9000» - наискучнейшее перечитывание пунктов стандарта. И, к тому же, весьма оригинальное понимание (точнее сказать, полное непонимание) BPM.  Впервые сталкиваюсь с мнением, что процессный подход можно реализовать без управления бизнес-процессами. Хотя, тоже мнение, и имеет право быть.

Заключительный доклад из серии «академических» «BPM: ИТ-инструментарий или философия бизнеса» Сергея Федотова, независимого ИТ-эксперта. Сергей сделал попытку дать определение BPM. И хотя это дело весьма неблагодарное, ему это неплохо удалось, определение получилось не хуже других. Особой новизны он не представлял (что не снижает ценности доклада!), просто очень понятно изложил некоторые концептуальные вещи – историю, философию, основные ценности BPM. И в заключение несколько слов о взаимодействии бизнеса и ИТ.

Один из вопросов, которые озвучил Сергей, перешли в обсуждение во время дискуссии. Это вопрос о критериях выбора системы BPMS. Можно ли выбирать BPMS путем «открыживания» компонент и функций системы? «- Моделер – есть, портал – есть, BPMN – есть, симулятор – есть…» «- А точно вам все это надо?» «- Не знаю… надо, наверное… хуже не будет». А вот это не факт! Избыточность в данном случае может сослужить плохую службу.

Еще один интересный вопрос, поднятый на дискуссии – что лучше, интегрировать множество разрозненных приложений или просто купить одну систему и все загнать туда. Мнения, как и следовало ожидать, разделились. В общем, благодаря нескольким активным участникам, дискуссия получилась достаточно живая, но с такой интересной особенностью: представители бизнеса задавали вопросы, скорее относящиеся к ИТ (хотя при этом заявляли, что всяких технических тонкостей им не надо).  Наверное не так уж «не разбирается» бизнес в ИТ ;-) 

Организаторам форума хочется высказать благодарность за хорошую работу. Как всегда, на высоте!

=WJ

>> Комментарии (всего 0)

Слияния и приобретения на рынке BPM :)

Singularity

Автор: Adam Deane

Оригинал: http://adamdeane.wordpress.com/2011/12/06/obituary-to-singularity/

Ten BPM vendors sitting on the wall,
Ten BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be nine BPM vendors sitting on the wall.

Nine BPM vendors sitting on the wall,
Nine BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be eight BPM vendors sitting on the wall.

Eight BPM vendors sitting on the wall,
Eight BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be seven BPM vendors sitting on the wall.

Seven BPM vendors sitting on the wall,
Seven BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be six BPM vendors sitting on the wall.

Six BPM vendors sitting on the wall,
Six BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be five BPM vendors sitting on the wall.

Five BPM vendors sitting on the wall,
Five BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be four BPM vendors sitting on the wall.

Four BPM vendors sitting on the wall,
Four BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be three BPM vendors sitting on the wall.

Three BPM vendors sitting on the wall,
Three BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be two BPM vendors sitting on the wall.

Two BPM vendors sitting on the wall,
Two BPM vendors sitting on the wall,
And if one BPM vendor should accidentally be bought,
There’ll be a lot of middleware, crm, ecm and technology vendors making a mess on the wall.

>> Комментарии (всего 0)

Отзыв о мероприятии "Интеграция сложных прикладных систем (ICAS 2011)"

23 ноября Агентство корпоративных коммуникаций OSP-Con провело в Москве Форум «Интеграция корпоративных прикладных систем (ICAS-2011)», на котором теме BPM была посвящена одна из секций.

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

В этом обзоре отобраны наиболее интересные доклады, касающиеся темы BPM.

Доклад Виктора Голубева, директора по ИТ-консалтингу «ТБС Консалтинг» назывался «Интеграция: взгляд со стороны IT Governance и Enterprise Architecture». Но помимо темы интеграции Виктор затронул и такой острый на сегодняшний день вопрос, как инвестиции в ИТ и взаимодействие ИТ и бизнеса. Действительно, постоянно возрастающая роль ИТ требует самого пристального внимания к нему со стороны бизнеса. Но чем сложнее становятся технологии, тем сложнее ИТ и бизнесу найти общий язык. Зависимость от технологий с каждым годом становится все больше, и уже сегодня практика показывает, что большинство задач, решаемых в организации, так или иначе связаны с ИТ. Виктор привел пример организации, которая, при заполнении матрицы контролей (это такое подтверждение что и как вы делаете) 85% контролей перекладывают на ИТ. Отсюда напрашивается однозначный вывод: организация управления ИТ – это зона ответственности высшего руководства, «ИТ – слишком важная область, чтобы доверять ее айтишникам».

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

Доклад произвел очень цельное впечатление, плюс к этому – эмоциональная подача, с определенной долей провокации. И, как результат – бурное обсуждение после доклада.

Исходный посыл доклада Сергея Лихарева, руководителя направления по управлению информацией департамента ПО IBM EE/A (доклад: «Интеграция данных, приложений и бизнес-процессов») звучал так: бизнес-среда значительно изменилась.  Реальность такова, что на любом предприятии существует несколько разных систем (зоопарк), откуда следуют такие проблемы как:

• неформализованные задачи
• неэффективное рабочее окружение
• неясная приоритезация работ
• неполные потоки данных
• недостаток контроля над системами
• недостаточное понимание процессов

Основные проблемы бизнеса:

• бизнес не может расти
• неудовлетворенность клиентов

Ключ к повышению эффективности системы – процессы.

Дальше, как водится, Сергей перечислял достоинства IBM, в частности, говорил и про «облако», на котором можно оказаться с Blueprint. Но сразу хочу заметить, что с облака Blueprint придется очень скоро спуститься на землю, т.к. представители IBM советуют: берите облако, помоделируйте в нем, а потом, если понравится, переносите на локалку. Кстати, сам IBM тоже борется со своим зоопарком, поскольку, в результате различных слияний и приобретений, в зоопарке обитают и SAP, и Siebel CRM.

Откровенно порадовал доклад (точнее – два доклада) от руководителя направления Отдела архитектуры и перспективных разработок Сбербанка РФ Михаила Демидова. Сбербанк так долго оставался в тени, не особо афишируя свои успехи, особенно в части BPM, что это казалось даже странным на фоне активности других банков. Но то, о чем рассказал на Форуме Михаил, вызвало, по меньшей мере, уважение. А учитывая авторитет Сбербанка, это может послужить хорошим стимулом (а кое-кому и уроком) для тех, кто успокаивал себя его пассивностью.

По докладу: можно сказать, что это был один доклад из двух частей, первая из которых прозвучала в пленарной части (доклад назывался «Опыт управления интеграционной архитектурой и построения распределенной интеграционной инфраструктуры в Сбербанке России»), а вторая – «Реальный BPM: применение в крупном банке» - на секции Управление бизнес-процессами. В первом докладе Михаил рассказал, как реализована SOA в Сбербанке, причем, как технические аспекты – построение архитектуры с использованием корпоративной сервисной шины ESB, так и управленческие – реализация функций управления в области SOA и управление интеграционной архитектурой в проектах.

Отвечая на вопрос, зачем SOA бизнесу, Михаил перечислил несколько весомых причин, таких как:

• упрощение централизации, замены устаревших автоматизированных систем
• снижение рисков и повышение качества проектов с интеграцией
• упрощение контроля SLA на уровне сервисов и процессов
• сокращение сроков реализации проектов

Во втором докладе Михаил отвечал на два вопроса:

• Зачем бизнесу BPM
• Как проходит внедрение BPMS в Сбербанке

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

Очень убедительно прозвучала аргументация отказа от использования систем электронного документооборота для автоматизации бизнес-процессов. В то же время в банке не исключается возможность интеграции BPMS с СЭД для реализации организационно-распорядительного документооборота.

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

Интересна позиция по отношению к лучшим практикам. Как правило, все эти лучшие практики переделываются под себя. Тогда, собственно, зачем они нужны? (Хорошо, что хоть кто-то это понимает!)

Анатолий Белайчук, президент компании Бизнес-Консоль представил взгляд на интеграции с позиции BPM. В своем докладе, «Интеграция в проектах BPM», он отметил, что большинство интеграционных проектов могут и обходятся без BPM. А вот полноценная BPM-система едва ли обойдется без интеграции. Но потенциальная ловушка кроется здесь: с точки зрения бизнеса не всякий процесс, безупречно реализованный в BPMS, с полной интеграцией всех взаимодействующих элементов, представляет собой ценность. Поэтому интеграция в BPM не является основной ценностью. Вопрос не стоит нужна ли интеграция в BPM системе. Рано или поздно она там будет. Вопрос – когда?

Анатолий привел несколько примеров из практики компании, в которых при помощи BPMS решались разнообразные задачи, некоторые, на первый взгляд, казались совершенно «непроцессными». Как, например, один из заказчиков – логистическая компания – вообще обратилась за решением задачи интеграции. А в результате выяснилось, что компания не достаточно хорошо понимает свои процессы, и решение процессной задачи дало значимый результат. А в еще одном проекте при помощи системы BPMS была решена задача интеграции нескольких приложений в контексте процессов, была реализована  средствами BPMSнедостающая CRM функциональность, налажена коммуникация и контроль над сквозным процессом.  Из этих и других приведенных примеров стало понятно, что часто организации пытаются лечить проблемы исключительно технологическими средствами, тогда как проблема может крыться в самих процессах.

Доклад Юрия Полянского, директора по рискам, члена Правления Минского транзитного банка (МТБанк) – это, по его собственному определению, взгляд человека, который ставит задачи, а не реализует их в BPM. В докладе «Организация бизнес-процессов принятия кредитных решений с учетом рисков конкретного вида бизнеса»  Юрий рассматривал процесс верификации клиентов с точки зрения целесообразности его автоматизации на разных уровнях и для разных банков и кредитов. В некоторых случаях процесс верификации настолько прост и предсказуем, что его автоматизация попросту может себя не окупить. А вот, к примеру, в розничном микрокредитовании, когда решение (к примеру, при покупке бытовой техники) должно быть принято в течение 10 минут, BPM может дать весомое преимущество.

Кирилл Курышев, начальник отдела разработки bpEXPERT, в докладе «Разработка интегрированной модели бизнес-процесса для BPMS» рассматривает модель процесса как совокупность взаимоувязанных моделей, каждая из которых описывает отдельные аспекты функционирования бизнес-процесса, а все вместе они образуют интегрированное, комплексное и полное представление о процессе и его исполнении. Составными частями интегрированной модели являются шаблон процесса, ресурсная, информационная и интеграционная модели, которые связаны между собой посредством ролей, информационных объектов и структур хранения, а также с организационной структурой и внешней информационной средой через сотрудников и API. Одного шаблона, по мнению Кирилла, недостаточно для создания исполняемого процесса. Необходимо описать каждую из этих моделей, формализовав связи между ними. Отсутствие моделей или их неверное использование приводит к созданию программного кода.

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

Подробно с презентациями можно ознакомиться здесь: http://www.ospcon.ru/node/7901

 

>> Комментарии (всего 1)

Семь смертных грехов BPM

На сайте www.finexpert.ru опубликован перевод статьи Криса Тейлора, BPM консультанта Nimbus (компании TIBCO) Seven Deadly Sins of Business Process Management.

(перепечатано с www.finexpert.ru)

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

1. Употребление слова «управление» всуе

Горе тому, кто использует понятие «управление», говоря об автоматизации.

Понятие «управление бизнес-процессами» неоднозначно воспринимается разными людьми. Достаточно рассмотреть отдельно слова «процесс» и «управление» – многие интерпретируют их по-своему, основываясь на личных интересах(1). Часто для BPM-разработчиков и практиков управление процессами означает их автоматизацию. Конечно, автоматизация важна, но это еще не управление. На мой взгляд, управление подразумевает эффективное руководство; каждый процесс должен рассматриваться как важный актив – нужно уметь им владеть, понимать его, правильно использовать и непрерывно совершенствовать.

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

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

(1) В более ранней статье What BPM Hat are you wearing? рассматриваются разные интересы четырех основных заинтересованных сторон в сфере управления бизнес-процессами: конечных потребителей, IT-специалистов, системных провайдеров и специалистов в области обеспечения соответствия нормативным требованиям и анализа рисков.

2. Процессная работа в рамках функционального подразделения

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

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

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

Похожая проблема состоит в том, что постоянно возникают разные специализированные проекты, которые удваивают усилия по выявлению процессов, потому что компания не обладает основной базой процессных знаний. Хороший пример – типичный ERP- или CRM-проект. Команда консультантов – специалистов по интегрированным решениям создает блоки диаграмм Visio для временного пользования. Как только система запущена или завершено ее обновление, контент сохраняется в сетевых папках, к которым никогда больше не обращаются. Через пять лет происходит его обновление. Контент устаревает, и к нему относятся недоверчиво.Следующий разработчик программного обеспечения (обычно это другая компания) делает то же самое – создает контент, который не имеет остаточной стоимости или она очень мала. 

Между тем инициируются разнообразные проекты, цель которых – понять и усовершенствовать процесс. Например, проекты по выявлению соответствия нормативным требованиям, оценке и повышению качества, управлению рисками, совместному оказанию услуг, аутсорсингу, бережливому производству, методологии «шесть сигм», слиянию/приобретению компаний и другие. 

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

• соблюдения нормативов (FDA, EPA, SOx);
• соответствия стандартам качества (ISO, TCF);
• обучения персонала и поддержки выполнения задач;
• управления эффективностью, при котором системы показателей связаны с соответствующими функциями и операциями процессов;
• пути клиента;• соответствия классификаторам (модели управления цепочкой поставок (SCOR), общему классификатору процессов (PCF) Американского центра производительности и качества) и т.д. 

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

3. Изобретение колеса заново

Обнаружив колесо, Иезекииль не стал заново изобретать его

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

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

• управление контентом – наподобие десятичной системы Дьюи;
• бенчмаркинг и системы показателей;
• возможность обойти индивидуальные особенности и политические мотивы («приносянеудобство каждому в равной степени»);
• анализ работы и недочетов;
• предотвращение дублирования.

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

Идополнительный бонус: вероятно, в разных базах данных, существующих в вашей организации, остаются «обрывочные» сведения о процессах, и их целенаправленное объединение очень перспективно при отсутствии основного классификатора.

4. Затруднение поиска информации

Ищите и вы легко найдете

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

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

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

5. Неспособность поддерживать актуальность информации

Вы назначаете владельца, и он будет вам подотчетен

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

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

6. Затруднение восприятие информации

Да не путайте слова своих последователей с чужим мнением

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

 

 

Рис. 1. Модель владения и выполнения

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

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

7. Неспособность к внедрению новшеств

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

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

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

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

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

>> Комментарии (всего 1)

Отзыв о конференции CNews от 6 октября 2011

Конференция CNews «BPM 2011: инновации и реалии», прошедшая 6 октября в Москве, на этот раз была не очень многочисленной, но, как всегда, насыщенной и интересной. Немного жаль, что программа была сокращена на одну кофе-паузу, т.к. кулуарные беседы ничуть не менее интересны, чем дискуссии в зале. Но зато на обсуждение докладов и дискуссию было выделено больше времени – и это порадовало.

Традиционно конференцию открыла Мария Попова, старший аналитик CNews Analytics. В своем докладе она, как обычно, рассказала об общих тенденциях рынка BPM, в основном с акцентом на Россию. По мнению Марии, наблюдается трансформация задач BPM – от латания дыр к трансформации бизнеса, но, как она деликатно подметила, «еще не слишком успешно, но есть стремление». Насчет научности и осведомленности заказчика – тут, пожалуй, можно согласиться (делать еще боимся, но порассуждать...  :-).  Основные тенденции - смещение фокуса в сторону стандартизации, акцент на метрики, SOA, как основной архитектурный подход , Open Source BPM, BPM в облаке, социальный BPM (о последнем Мария заметила, что конкретных подтверждений пока нет, только слова).

Андрей Коптелов, директор по консалтингу Software AG & IDS Scheer в России и СНГ начал свой доклад с объявления, что бренд IDS Scheer перестает существовать, и что компания будет впредь называться Software AG. А дальше Андрей представил новый флагманский продукт компании – BP Excellence – АРМ директора. Он видит за этим продуктом хорошее будущее, поскольку наблюдается явный интерес к показателям бизнеса, руководители хотят руководить. Но при этом многие клиенты, как заметил Андрей, сосредоточены только на описании бизнес-процессов, тогда как правильно было бы решать задачи в комплексе: регламентация, бизнес-анализ, автоматизация в BPM-системе, описание архитектуры, повышение операционной эффективности, непрерывное усовершенствование.  В общем, все слова правильные, докладчик Андрей превосходный. Видимо, поэтому доклад не вызвал даже вопросов из зала ;-)

Следующий докладчик, президент компании Бизнес-Консоль Анатолий Белайчук, всегда отличается академичностью докладов. В своем докладе «Серьезный BPM консалтинг» Анатолий ушел от технических деталей и Success Stories, а остановился на том, что понимается под BPM в разных компаниях, об уровнях BPM и о проблемах внедрения BPM (или, другими словами, «как продать BPM»).  По мнению Анатолия, существует 4 уровня BPM (от 0 до 3), и даже в очень продвинутых компаниях одновременно присутствуют они все. И, что самое главное, нет необходимости избавиться от более отсталых уровней, поскольку более высокие уровни являются более затратными, а далеко не все процессы оправдывают такие затраты. Анатолий предлагает соблюдать определенный баланс, не стремясь объять необъятное. И главное, на что призывает Анатолий обратить внимание – это на формирование у заказчика четкого понимания того, чего именно он стремится достичь, и как будет оценивать результаты проекта.

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

Следующий доклад – «Реализация проекта онлайн обработки кредитных заявок в банке Тинькофф Кредитные системы» представляли сразу два докладчика – Андрей Кирейко, руководитель Управления систем поддержки принятия решений Дирекции ИТ банка Тинькофф и Роман Ткачев, операционный директор, заместитель генерального директора BI-Телеком. Процесс обработки кредитных заявок – это один из ключевых процессов банка, включает в себя привлечение клиентов и выдачу кредитов. Если до внедрения BPM-системы обработка заявки на выдачу кредита составляла несколько дней, а целью было сократить время обработки до 15 минут, то достигнутый результат – 5 минут – можно назвать более чем успешным. По словам Андрея Кирейко, такое ускорение позволило повысить привлекательность банка в глазах клиентов. Этот проект выполнялся совместно с BI-Телеком, а в настоящее время в банке готовятся начать новый проект, собственными силами.  В части доклада от BI-Телеком Роман рассказал о технической стороне предложенного решения.

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

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

Владимир Алешин, профессор АНХ при Правительстве РФ  отвечая на обозначенный в названии доклада вопрос «Чего хочет бизнес от BPM?»  высказал интересную мысль о том, что бизнесу не интересно считать полученные  от ИТ услуги. Ему интересны импульсы и результаты. Перефразировав, можно сказать, что бизнес мыслит иными категориями, нежели ИТ. И основная проблема – это передача информации от бизнеса к ИТ. Но Владимир почему-то считает, что бизнес не в состоянии понимать схемы (возможно, что некоторые схемы действительно не так просто понять), но зато бизнес поймет матрицу Захмана  (спорное утверждение). Но, в принципе, не так важно, какой именно язык передачи информации между бизнесом и ИТ можно считать наиболее удобным, тут важна сама постановка вопроса: единый язык нужен. А какой окажется жизнеспособным – покажет время.

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

И в завершение конференции Юрий Лиц, Business Systems & IT manager, VELUX, рассказал о реализации Lean проектов в торговых компаниях. Бесспорно, для соответствующего тематического мероприятия доклад был бы неплох. Но, поскольку он не имеет прямого отношения к теме  конференции (я называю такие доклады докладами про блоху, которая есть у собаки), то оставлю его без комментария.

В завершение конференции, как обычно, дискуссия. Правда, начало было непонятное – еще один доклад  от аналитика CNews, непонятно о чем и к чему. Грозил затянуться, но как-то его благополучно свернули, и вернулись к вопросу «Чего-таки хочет бизнес?».  Немного попытали представителя Сбера, как там у них жизнь с Pega. В общем, получилось немного хаотично, но вроде как и поговорили. 

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

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

• Взгляд эксперта
• Видеоотчет
• Фотогалерея
• Отзыв Андрея Коптелова
• Отзыв Максима Смирнова

=WJ

>> Комментарии (всего 1)

PoC или как выбрать BPMS

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

Многие вендоры, понимая бесперспективность подобных попыток, предлагают заказчикам различные варианты облегчения выбора, такие как бесплатные пробные версии, пилотные проекты, демонстрации и т.п. В заметке 5 Tips for Selecting the Best BPM Software Vendor for your next BPM Project ("5 Советов по выбору BPM вендора для вашего следующего BPM проекта") описывается взгляд со стороны вендора на проблему выбора BPM или Workflow системы.

Ниже следует список рекомендаций по выбору лучшего BPM или Workflow вендора для вашего следующего проекта автоматизации BPM.  Я видел разные версии такого списка от множества аналитиков в области BPMS.Вот что они обычно говорят о том, как лучше выбрать программное обеспечение BPMS или Workflow:

1. НЕ создавайте RFP (Request for Proposal)  или RFI (Request for Information) для выбора BPMS вендора
2. Составьте список из трех вендоров и предложите им сделать PoC (Proof of Concept) на вашей площадке
3. Выберите для PoC процесс, замкнутый на внешнего заказчика
4. Выберите процесс, в котором есть одна или две точки интеграции и на котором можно легко измерить произведенные улучшения
5. Настаивайте, чтобы ваши специалисты работали бок о бок со специалистами вендора, чтобы они могли задавать вопросы о том, почему вендор делает то или это при создании процесса.

В заключение, помните, что если вы делаете PoC в соответствии с этими рекомендациями, и,то он не продемонстрирует масштабируемость. Лучший способ оценить масштабируемость решения – попросить референсы и поговорить с ними.

С этими рекомендациями, конечно, сложно спорить. Они основательны. Некоторые из них не всегда реалистичны. Если вендор не запрашивает за проект масштаба предприятия от 200 тысяч долларов в год, то не стоит ожидать, что конкурирующие вендоры, придут на вашу площадку делать PoC. В этом случае альтернативой может быть дистанционный PoC или ПО типа Workflow Software Quick Start (Cloud Process Maker).

Что здесь действительно важно – это совершенно очевидные рекомендации не делать выбор на основе RFP или RFI. Я получаю, по меньшей мере, один RPF или RFI в неделю от компаний, озабоченных покупкой программного обеспечения BPMS. Когда я смотрю на эти RFI, у меня возникает одна и та же мысль – о чем эти ребята думают?

Если вы покупаете машину, вы сядете, составите список функций и затем пошлете его куче производителей автомобилей, а затем сделаете свой выбор на основании их ответов? Конечно нет! Или, например, покупка смартфона – вы смотрите на список функций и покупаете его только потому, что вы отметили галочкой в списке все ключевые функции? Конечно же нет!

Дело в том, что софтверные функции – это вовсе не софтверные функции. Это верно и для машин, и для смартфонов, и для BPMS. В жизни и в технологиях есть хорошо разработанные и элегантные функции, но также есть и плохо продуманное барахло. Ручка MontBlanc выполняет те же функции, что и стандартная одноразовая ручка Bic, купленная в обычном магазине – так? Но разве они одинаковы?

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

1. Дружественный BPMN 2.0 дизайнер – да/нет?
2. Интуитивно понятный инструмент для создания веб-форм – да/нет?

Как, предполагается, BPMS вендор ответит на этот вопрос? Конечно, у нас у всех это все есть, и все мы поставим «да» в соответствующей клетке. Так для чего тратить свое и наше время, пытаясь таким образом выбрать Workflow или BPM систему?

Не все BPM или Workflow системы одинаковы. Просто помните один маленький совет. Вспомните, как вы покупали свой смартфон, а потом подумайте, как ваша организация проводит анализ, выбирая  BPMS или Workflow… есть ли в этом смысл?

 

PoC или, как его чаще называют, пилотный проект – это наиболее распространенная практика, которую применяет большинство вендоров BPMS. Но эта практика имеет и свои подводные камни, о которых недавно писал в своем блоге один из авторитетных экспертов в области BPM Анатолий Белайчук. По его мнению, проблема кроется не столько в самой идее PoC, сколько в отношении заказчика к пилотному проекту. Анатолий называет по меньшей мере две причины, по которым практика выполнения пилотных проектов не оправдывает себя:

 1) Бесплатные пилотные проекты – это абсолютно порочная практика: что бесплатно достается, то ровно настолько же и ценится. К сожалению, в нашей практике было несколько случаев, когда отличный, добросовестно сделанный проект в итоге оказывался в мусорной корзине. Решение банально не принималось: ни положительное, ни отрицательное –  никакое. Повлиять на заказчика невозможно: даже если по договору он обязан принять решение – что, судиться с ним?

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

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

К сожалению, это тоже не сработало. Проблема в том, что как мы не бьемся, объясняя заказчику, что цель пилота – не разработать для него некую автоматизированную систему, а предоставить информацию для принятия решения о том, подходят ему или нет предлагаемые управленческие подходы и программное обеспечение – до конца он этого не понимает. На словах соглашается, а на деле требует все новых и новых доработок а) совершенно непринципиальных и б) о которых не было речи в начале проекта. Слишком сильна оказывается инерция взгляда на BPM как на проект автоматизации.

Да и простое проявляется, извините, жлобство: сумма фиксирована – значит, надо выжать по-максимуму. «Вот какой я молодец, заставил исполнителя сделать еще одну фичу.» А то, что при этом принятие решения откладывается, время идет и система, которая могла бы уже начать приносить пользу, не внедряется, никого не волнует. Значит не так уж было нужно? Не получается втолковать заказчикам простую истину: в пилотном проекте время важнее функциональности!

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

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

=WJ

>> Комментарии (всего 1)

Покупка дня: OpenText купил Global 360

OpenText - известный ECM вендор объявил сегодня о покупке не менее известного BPM вендора Global 360.

По словам Джона Шеклтона, президента и генерального директора компании OpenText, в настоящее время все больше компаний связывают свои ECM и BPM проекты в рамках единой стратегии. Поэтому, по его мнению, объединение компаний позволит предложить клиентам единое решение от крупного вендора. Принимая во внимание то, что в феврале этого года OpenText уже приобрел одного крупного BPM вендора - Metastorm, можно сделать вывод, что компания намерена существенно расширить рынок, как за счет новых предложений клиентам, так и (что больше похоже на правду) за счет клиентского рынка обеих компаний.

Зачем OpenText понадобился еще один вендор BPM? Два этих продукта - Metastorm и Global 360 дополняют друг друга. В частности, Metastorm больше ориентирован на взаимодействие людей,  у него больше возможностей анализа бизнес-процессов. В то время как Global 360 предлагает Dynamic Case Management. К тому же, Global 360, так же как и OpenText и Metastorm является поставщиком решений для клиентов Microsoft.

Ну что же, никто уже не удивляется подобным событиям. И с каждым разом только усиливается любопытство: что же на этот раз получится из симбиоза - новый улучшенный продукт или минус две BPM системы. Время покажет.

=WJ

>> Комментарии (всего 0)

BPM и ERP

Недавно Пол Хармон (BPTrends) опубликовал интересную подборку статей, в которых обсуждалась тема взаимодействия ERP и BPM. Стоит отметить, что несмотря на то, что эти обсуждения появились в прессе с того самого момента, когда появились BPM-системы, вопрос и по сей день остается открытым, и однозначного мнения на этот счет нет. Во многом эта тема обязана своей актуальностью тем, что все ERP (или платформенные) вендоры уже включили BPM в свои пакеты предложений, тем самым внеся неразбериху в сознание тех, кто до сих пор для себя четко не уяснил, что же такое BPM, для чего нужны BPM системы и чем они отличаются от учетных систем, таких как ERP или CRM. BPTrends неоднократно обращался к этой теме, и в этом обзоре Пол Хармон оглядывается на десятилетие назад, крупными штрихами обозначив основные «milestones» развития ERP систем параллельно с BPMS (Хармон пометил, что в этой теме он объединил в понятии ERP и CRM, и SCM и другие подобные системы).

(Хармон приводит все публикации, затрагивающие тему ERP. В этот обзор включены те, которые затрагивают одновременно ERP и BPMS)

Обратившись к ранним 80-м прошлого столетия, Хармон напоминает, что в то время многие крупные компании разрабатывали свои собственные приложения, большинство из которых были узкоспециализированными (например, отдельно ПО для продаж, для учета и т.д.) и не предусматривали обмена данными.  В 90-х, с движением в сторону клиент-серверных приложений, крупные компании, подобные Oracle или SAP создали наборы приложений, которые использовали уже единую базу данных, и предназначались для широкого использования внутри всей компании. К концу 90-х многие компании начали отказываться от собственных разобщенных приложений, применяя у себя программное обеспечение от крупных софтверных производителей (так называемые ERP системы).

В то же самое время Том Дэвенпорт написал книгу «Mission Critical: Realizing the Promise of Enterprise Systems», в которой он представлял ERP как способ стандартизации процессов в компании. ERP вендоры так же утверждали, что их системы поддерживают все процессы компании, хотя на самом деле явной поддержки процессов в них не было. Надежды на то, что ERP будут поддерживать процессы различных компаний обернулись для многих из них кошмаром и дорогостоящими неудачами. Многие компании продолжают использовать ERP системы, но они испытывают трудности в применении собственных уникальных процессов, которые должны обеспечивать им конкурентное преимущество. Какое-то время те, кто выступал в поддержку ERP систем и те, кто ратовал за создание уникальных процессов для получения конкурентных преимуществ, были в явной оппозиции друг к другу. Но в начале 2000-х появилась идея использовать интернет протоколы для создания систем управления бизнес-процессами (BPMS). Создание модели процесса и перевод ее в исполняемый код дали, наконец, компаниям то, что они долгое время надеялись получить от клиент-серверных ERP систем.

В 2003-2005 годах, когда интерес к BPMS начал расти, ведущие ERP вендоры начали задумываться о реинжиниринге своих систем с тем, чтобы они отвечали идеологии BPMS. Этот процесс в Oracle и SAP сейчас идет полным ходом, хотя сделать это не так-то быстро.  Многие считают, что борьба развивается между теми, кто предоставляет отдельные BPM продукты (например, IBM) и теми, кто ищет способы включить BPMS функциональность в ERP системы. Кто победит в этом споре – не известно, но, скорее всего, те, кто уже является клиентами SAP или Oracle, не откажутся от использования их ПО, и будут приобретать новые версии с элементами BPMS. Этот процесс, несомненно, займет десятилетия, но в любом случае, гораздо проще создавать, адаптировать и модифицировать mySAP (Netweaver), чем старые приложения SAP, так что тенденция все же к ускорению.

Статья ERP, CRM, and BPM, опубликованная в октябре 2005 года – одна из первых ласточек – предвестников будущих дебатов. В это время рынок программного обеспечения в большей доле принадлежал именно ERP системам, и именно крупные ERP вендоры обещали единственно верный путь к всеобщему информационному счастью. Мечта получить «все в одном флаконе» настолько прочно поразила умы и сердца пользователей, что BPMS стали возмутителями спокойствия не только в рядах ERP вендоров (как потенциальные конкуренты), но и в сердцах потребителей. Внедрение ERP, которое длилось годами, съедало огромное количество ресурсов, казалось пределом, за которым уже не о чем будет беспокоиться… и тут появились процессы, которыми надо не просто управлять, а управлять быстро, качественно и – главное – постоянно!

В статье «ERP, CRM and BPM» Пол Хармон остановился на том, как BPM системы могут сделать существующие ERP и CRM системы более гибкими и полезными. Хармон разделил тех, кто потенциально заинтересован в применении BPM систем, на две группы. Первая – это те, кто уверен, что при помощи BPMS надо создавать абсолютно новую систему, которая будет более гибкой, чем существующие пакетные приложения, такие как SAP или Oracle. Другая группа – это те, кто склоняется к использованию BPMS для того, чтобы управлять уже имеющимися приложениями. Налицо типичный для любых новых технологий конфликт целей. Но Хармон тут же отмечает, что ERP вендоры вкладываются в разработку собственных BPM компонент, планируя включать их в пакет предложений. У SAP есть NetWeaver, Oracle представил BPEL Process Manager, у Microsoft есть BizTalk. И каждый из этих вендоров спешит представить наиболее гибкие способы связать свои модули и приложения в процессы. Но в это время пакетные вендоры предлагали создавать процессные диаграммы, к примеру, в VISIO, с тем, чтобы иметь наглядное представление (в картинках) о том, как должна работать организация. Понятно, что с появлением BPM систем клиенты ERP вендоров вправе были ожидать и от своих поставщиков, чтобы эти диаграммы были как-то связаны с модулями системы. То же можно было сказать и о бизнес-правилах, которые в ERP системах были жестко описаны в каждом модуле.

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

В апреле 2006 года Пол Хармон снова обратился к этой теме. В статье A Single Instance of ERP он приводит пример предприятия, имеющего распределенные офисы продаж по всему миру. Во всех филиалах установлена одна и та же ERP система, но специфика продаж в разных филиалах различна, что привело к тому, что ERP система в них настроена по-разному. К тому же, одни филиалы продают промышленное оборудование, другие – мелкие товары. То есть различаются и процессы продаж (и не только они). Таким образом, количество филиалов, умноженное на количество различаемых процессов в несколько раз увеличивает различия и, следовательно, увеличивает стоимость поддержки и обслуживания программного обеспечения. Добавьте сюда необходимость адаптации всего этого многообразия к новым релизам вендора, и вы убедитесь, что ERP обойдется вам в копеечку.

Поставив перед собой задачу снижения затрат на содержание системы, компания приняла решение стандартизировать процессы филиалов. Но как это сделать? Сделать это в ERP системе не представляется возможным из-за непомерной стоимости таких работ. Да и требуемой гибкости достичь не удастся, поэтому филиалам придется подстраиваться под стандартные процессы. А это не вызывает восторга у менеджеров филиалов. Единственно возможным решением для компании стало внедрение BPM системы, которая позволила связать процессы филиалов с ERP системой, перенеся всю настройку процессов в BPMS. И, несмотря на то, что у компании были серьезные опасения относительно BPMS, поскольку технологии на тот момент были еще слишком новыми. Но альтернативой было только «размножение» ERP, что и обусловило выбор в пользу BPMS.

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

Что же представляют из себя эти «более интересные задачи»? Какие цели должна преследовать организация, которая действительно стремится получить конкурентное преимущество и выделиться на рынке? На эту тему в мае 2009 Хармон опубликовал интереснейшую статью Porter, ERP and BPMS. Как видно из названия, автор обращается к автору теории конкурентных преимуществ Майклу Портеру и к его книге «Competitive Advantage», а дальше очень метко связывает теорию Портера с практикой применения автоматизированных систем.

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

Операционная эффективность, в терминах Портера, достигается за счет достижения лучших результатов в выполнении каждого отдельного действия. Для этого многие компании тратят значительные средства и силы на изучение и приобретение так называемых «best practices» . Но Портер не считает это эффективной стратегией. Стремясь использовать лучшие практики, применяемые в других компаниях, компания всего лишь бежит с ними на одной дорожке, отставая или догоняя, но все же на одной. При этом то же самое будут делать и конкуренты. Поэтому применение лучших практик – это бесконечный марафон, где все участники всегда будут находиться в примерно одинаковых условиях, а затраты на копирование все лучших и лучших практик будут постоянно расти. По словам Портера, некоторые компании могут добиться успеха за счет повышения операционной эффективности, но с каждым днем им будет все труднее это делать.

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

Дальше Пол Хармон обращается от теории к практике. Первые попытки воплотить идеи Портера в жизнь были предприняты в 90-х годах прошлого столетия и представляли собой не что иное, как Business Process Reengineering. Идеологи реинжиниринга предлагали интегрировать бизнес-процессы с ИТ системами в контексте цепочки создания ценности. Но в то время реализация этих идей требовала значительных инвестиций в софтверную разработку. Поэтому многие крупные компании к концу 90-х остановили свой выбор на ERP системах, которые предлагали использовать клиент-серверные приложения, связанные одной реляционной базой данных. Но, несмотря на то, что эти системы решали многие задачи, они все же не могли решить проблемы, обозначенные Портером. Ведь, в сущности, ERP – это те самые «лучшие практики»,  которые относятся к операционной эффективности, и не связаны с цепочкой создания ценности. Некоторые компании пошли по пути «подгонки» ERP систем под собственные нужды, но этот путь делает системы дорогостоящими и сложно модифицируемыми.

Ситуация усугубилась в начале 2000-х с приходом dot.com технологий. Большинство компаний в настоящее время предпочитают использовать интернет-технологии в своем бизнесе (может быть, не все так преуспели в этом, как, скажем, Amazon.com, но многие к этому стремятся).  И вот тут компании, которые «привязаны» к своим ERP системам, начинают испытывать существенные трудности, поскольку им крайне сложно изменить бизнес-модель без переделки системы.

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

Дальше Хармон предлагает статью Тома Беллинсона (Tom Bellinson) The ERP Software Promise («Обещания ERP»), вышедшую в июле 2009 . Том Беллинсон, являясь ярым приверженцем ERP систем, не соглашается с Хармоном в том, что перспектива ERP – это интеграция с BPMS. Основным аргументом против он приводит то, что репозиторий BPM-систем не является центральным хранилищем данных, и что для создание единой модели требуется интеграция. А, по утверждению Тома, то, что надо интегрировать, никогда не может быть таким же эффективным, как целое.  И что BPMS, несмотря на то, что механизмы интеграции у них достаточно сильные, все же остается еще одной точкой интеграции, которой надо управлять. Все, что, по его мнению, необходимо ERP – это упрощение процедуры согласования изменений процессов.

В качестве модели ERP будущего, он приводит следующую архитектуру:

 

И дальше приводит в пример SAP, который в настоящее время предпринимает шаги по разделению своих приложений, и делает акцент на разработке NetWeaver – ВРМ приложения. Однако здесь Беллинсон явно надевает розовые очки, потому что один NetWeaver не в состоянии решить все проблемы интеграции, поскольку для этого потребуется серьезная доработка остальных модулей. Ну и факт, который констатирует Беллинсон – это стоимость продуктов SAP.

При этом вера Беллинсона в торжество единства непоколебима. Признавая, что переделки существующих ERP систем займут годы, он допускает право BPMS на временное существование. Но в светлом будущем, по его мнению, все же победит единая система.

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

 =WJ

>> Комментарии (всего 0)