Этот контент доступен на языках: English.

Слыхали выражение “Гамбургский счёт”? Существует полу-легенда, что в конце XIX - начале XX века профессиональный борцы со всего света собирались раз в год в какой-то таверне в Гамбурге и там выясняли, кто из на самом деле сильнее. Без публики, потому что где публика, там шоу-бизнес, а тут для себя…

Эта ассоциация возникла у меня на конференции bpmNEXT из-за ее уникальной атмосферы. Ничего похожего на типичное BPM-мероприятия - ни маркетинговой туфты, ни охоты за потенциальными покупателями, ни рассуждений на тему что такое BPM. Только профессиональные демонстрации завтрашнего BPM. » читать дальше

16.05.12 сообщество BPMS.ru при поддержке МЭСИ провело очередной мастер-класс из серии “BPMS в действии”: методологию S-BPM и систему Metasonic представляла компания “Логика бизнеса 2.0″. Запись мастер-класса выложена на youtube.

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

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

» читать дальше

Семинар получился оживленным - интересными были и сам доклад, и последующие выступления - и нестандартным по тематике. Если обычно на семинаре мы разбираем опыт конкретных проектов BPM, то в этот раз была доложена концепция, существующая пока только в теории. Доклад планируется опубликовать на bpms.ru. По существу доложенного, абсолютно правомерной мне представляется постановка задачи. Действительно, существуют проблемы 1) совмещения в организации элементов функционального и процессного управления (а вообще-то еще и проектного, для полноты картины) и 2) отторжения творческими личностями сильно формализованных процессов, в которых они чувствуют себя “винтиками”. Но предложенное решение, на мой взгляд, откровенно утопично. Сервисно-ориентированное управление вполне имеет право на жизнь, но в несколько ином виде - более авторитарном, чем было предложено автором. Попытался в своем выступлении вкратце изложить, как такая схема могла бы выглядеть, но боюсь получилось скомкано; эта тема заслуживает отдельного рассмотрения.

На следующей неделе по приглашению организаторов выступлю на конференции ReqLabs с докладом “Управление требованиями в проектах BPM”. Вообще-то экспертом в управлении требований себя не считаю, но как в рамках BPM реализуется управление быстро меняющимися требованиями знаю хорошо. Рассчитывать, что аудитория хорошо знает что такое BPM, не приходится, поэтому половина доклада будет предоставлять собой ликбез. А что прикажете делать, если BPM является междисциплинарным подходом? Вот и приходится на конференциях по BPM рассказывать про управление проектами, а на конференции по управлению требованиями рассказывать про BPM.

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

Качество докладов было на высоте. Особенно мне понравились:

• Роман Ткачев (операционный директор БиАй Телеком, партнера Lombardi в России) рассказал про проекты в банке ВТБ-24 и в ритейловой компании. Отличный программный продукт, грамотный консалтер - мы вправе были рассчитывать на интересный доклад, и мы его получили. В кулуарах задал Роману пару ключевых вопросов. Во-первых, заплатили ли клиенты деньги за лицензию? Ответ - да. Вопрос, на мой взгляд, важный, так как проводит грань между инициативным пилотом, выполняемым поставщиком за свой счет и фактически без обязательств со стороны клиента, и следующей ступенью - продуктивным пилотом, выполняемым за деньги клиента и в условиях, когда клиент уже четко осознал, что ему это нужно. Второй вопрос - на каком уровне поддерживались проекты, конкретно - кто выступал в роли спонсора. Ответ - в ВТБ-24 проект поддерживался на уровне председателя правления банка. Это еще один ключик, позволяющий отличить “игрушечный” проект с сомнительными перспективами от реального. В общем, я рад за коллег из BI Telecom. Роман согласился, что ему стоило бы акцентировать эти моменты в презентации - что ж, так бывает, что самое интересное для аудитории для докладчика оказывается само собой разумеющимся.
• Алексей Будин (директор компании “Элевайз”, отечественного разработчика BPM-системы ELMA) живо и убедительно представил два взгляда на BPMS: со стороны заказчика и со стороны поставщика. Судя по презентации, система выглядит достаточно симпатично. А наличие интеграции с 1С (подтвержденной сертификатом “1С-совместимо”) является серьезным конкурентным преимуществом на отечественном рынке. Ведь поставщики импортных BPMS об интеграции с 1С не беспокоятся, а для среднего бизнеса в России 1С - практически стандарт. Поскольку мы тоже ориентируемся в основном на средний бизнес, сделал для себя вывод, что стоит познакомиться с этой системой поближе.
• Алексей Бойко (руководитель методического центра по проектированию бизнес-процессов КЭС-Холдинг) поделился опытом внедрения процессного управления в крупном энергетическом холдинге. Выдающееся достижение - то, что удалось заразить этой идеей высшее руководство. Причем видно, что для них это не увлечение, а систематическая работа по организации бизнеса сверху-вниз на принципах BPM. Для каждого бизнес-процесса верхнего уровня назначен владелец на уровне вице-президента, и в соответствии с утвержденным положением, владелец процесса отвечает в том числе за дизайн процесса. Наличие владельца процесса - это отличный критерий чтобы определить, является ли процессное управление для компании преходящим увлечением и поводом поговорить или же образом жизни. Алексей отдельно остановился на том, как повлиял на их планы кризис: они отказались от “ковровых бомбометаний” и перешли работе адресной, малыми силами, в сжатые сроки. Похоже, они сами не поняли как им повезло: кризис случился в самый подходящий для них момент, буквально заставив их начать работать так, как собственно и рекомендуется теоретиками BPM. Если бы не кризис, они бы наверное продолжали действовать в духе старого доброго реинжиниринга, и мы бы имели шанс услышать доклад из серии “как мы дошли до документирования четвертого уровня бизнес-процессов и поняли, что до шестого мы не дойдем никогда”. А так благодаря кризису получился такой “Lean поневоле”. С другой стороны, систематически пройти два уровня процессов сверху-вниз безусловно полезно. Из доклада осталось не до конца понятно как они расставляют приоритеты процессам - похоже, интуитивно-волевым способом. Если так, то им стоило бы подойти к этому более систематически - попробовать применить TOC, на основе экспертных оценок определить потенциал улучшения процессов. Да, и до использования BPMS (а следовательно, до детального моделирования и поддержки исполнения процессов в реальном времени) они еще не дошли. А я все-таки не очень верю в BPM без BPMS. Это как бухгалтерия без компьютера - теоретически возможно, в рамках обучения полезно, но в практической работе смысла не имеет.
• Самым солидным мне показался доклад Александра Башкова (менеджер бизнес-приложений компаний “Тетра Пак”). До этого я про компанию не знал ничего, кроме названия, теперь знаю - это один из лидеров в управлении бизнес-процессов в мировом масштабе. Александр очень хорошо рассказал как организовано процессное управление на уровне глобальной компании, и что особенно интересно, про кастомизацию на региональном уровне. Известно, что компании, достигшие выдающихся достижении в области управления бизнес-процессами, зачастую добровольно делятся своим опытом - я слышал такие истории про Toyota, Xerox, Motorolla. Поэтому я задал вопрос Александра после его доклада, и он подтвердил, что действительно, в их компании такое тоже практикуется. Так что если ваша компания вынашивает амбициозные планы в области BPM, я настоятельно советую попробовать обратиться к Тетра Пак за опытом. И пожалуйста напишите здесь в комментариях, что из этого вышло.

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

Аудитория производила впечатление подготовленной - и вопросы, и кулуарные разговоры были содержательными. Диссонировали, на мой взгляд, только вопросы представителя Академии при госслужбы при Президенте РФ: как-то странно на конференции по BPM спрашивать у докладчика чем BPMS отличается от Sharepoint.

Большой упрек организаторам - заявленная дискуссия фактически не состоялась. Даже те куцые 15 минут, которые были отведены в конце регламента, не были использованы. Складывается впечатление, что организаторам это просто не нужно. Вступительный доклад сделали? сделали. Спонсорам за их деньги выступить дали? дали. А дискуссия - какой от нее прок? Только аудиторию занимать, а ее аренда денег стоит. Неправильная, близорукая позиция. Причем, это становится тенденцией - конференции не только CNews, но остальные все больше становятся похожими не на конференции, а на шоу.

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

Кирилл Курышев рассказал о бизнес-процессе “Управление заявкой на предоставление услуги связи”, которым команда bpexpert занималась в одной крупной телекоммуникационной компании.

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

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

1. Отсутствие четко сформулированных требований на входе проекта. В настоящих проектах BPM по-другому не бывает. Начиная, ты никогда не знаешь какой процесс у тебя получится в результате. Выявление процесса (process discovery) в ходе проекта, пять итераций схемы процесса от старта проекта до запуска процесса в эксплуатацию - это классика.
2. Разработка в стиле agile: короткими циклами, с постоянной обратной связью с заказчиком. Говорим BPM - подразумеваем agile!
3. Добротный инструмент Oracle BPM Studio (aka BEA AquaLogic BPM). Бывает так, что основное содержание проекта - борьба с инструментом. Но не в данном случае. Докладчик отметил: были моменты, когда у них возникали затруднения с реализацией в Oracle требований заказчика. В этих случаях они поступали очень правильно: не насиловали инструмент, а пытались работать в том стиле, который он предлагает. В частности, им удалось обойтись “малой кровью” в решении задач, связанных с авторизацией, ролями, делегированием, замещением и т.п. (п.8 моей недавней заметки). Удалось заинтересовать заказчика возможностями имитационного моделирования (simulation), действительно неплохими в Oracle.
4. Удалось принести пользу “заказчику заказчика”, т.е. клиентам компании: среднее время обработки заказа уменьшилось с 5 до 3 дней. В рамках пилотного, по сути, проекта, этого добиться удается не часто.
5. Использование eTOM не как инструкции - “делай раз - делай два”, а как справочника. Т.е. живешь, все-таки своим умом, но время от времени сверяешься с образцом. Такая сверка позволяет существенно повысить ценность решения при незначительном расширении проекта, что и было наглядно нам продемонстрировано.
6. Стремление сделать протекание процесса если не полностью автоматическим (т.е. довести его до STP, straight-through process), то максимально гладким. Похоже, проектная команда интуитивно нашла известный, в общем-то, магистральный путь: направлять человеку только те задания, которые не удалось обработать автоматически. Т.е. использовать человека в качестве “обработчика бизнес-исключений”.
7. И главное: всего за 20 рабочих и 30 человеко-дней им удалось запустить процесс в промышленную эксплуатацию. Скептики посрамлены!
8. Причем есть одна пикантная подробность: на самом деле это была вторая попытка компании-заказчика чего-то добиться при помощи BPM. Причем в первой попытке BPM-система была та же самая, только исполнитель другой. Как я и говорил однажды на конференции: прежде чем критиковать BPM, убедитесь сначала, что то, что вы делаете - это действительно BPM. По-видимому, первая попытка как раз и не была попыткой BPM. И тем ценнее результат команды bpexpert, ведь добиться успеха после фальстарта вдвойне труднее.
9. И последнее - то, что стало предметом оживленной дискуссии после доклада: удалось не только успешно выполнить проект, доведя его до промышленной эксплуатации; по утверждению докладчика, им удалось передать заказчику и компетенцию, и интерес к тому, чтобы продолжать работать над процессом все в большей и большей мере самостоятельно. Этим могут похвастаться очень немногие проекты, а ведь без этого, положа руку на сердце, тоже нельзя говорить о BPM в полном смысле слова.

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

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

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

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

Вроде очевидно? Не будем торопиться с выводами.

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

И вот яркое выступление на TED Video, объясняющее эту загадку: “Dan Pink on the surprising science of motivation“.

Конспективно:

Дэн начинает с описания несложной задачи, требующей, тем не менее, определенной изобретательности,- “the candle problem”. Экспериментаторы взяли две группы людей, предложили каждому решить эту задачу и измерили время, которое они потратили. При этом люди из одной группы решали задачу “за так”, а во второй группе пообещали денежную премию тем, кто окажется в числе 25% лучших по скорости.

Как вы думаете, насколько более успешной оказалась вторая группа? Ответ: если в нормальных условиях люди решают задачу за 5-7 минут, то при наличии материального стимулирования они тратят на нее на 3.5 минуты больше.

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

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

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

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

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

1. Самостоятельность (autonomy): стремление человека самому распоряжаться собой - нечто прямо противоположное идее менеджмента. Пример: сотрудники Google имеют право 20% своего времени заниматься чем пожелают. Результат: примерно половина новых продуктов рождаются именно в эти 20% времени, которым сотрудники могут распоряжаться самостоятельно.

2. Мастерство (mastery): стремление человека постоянно совершенствоваться в чем-то, что для него важно.

3. Предназначение (purpose): стремление человека тем, что он делает, служить чему-то большему, чем он сам.

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

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

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

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

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

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

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

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

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

Первое и главное впечатление: это действительно был “семинар BPM-профессионалов“, как несколько пафосно было объявлено. Серьезный разговор, тон которому задал докладчик словами “я буду рассказывать не как должно быть, а как реально было и есть”. Вопросы и обсуждение ни разу не скатились до уровня ликбеза.

Правда, был момент, когда дискуссия свернула не туда: мы чуть не свалились в религиозную войну на тему “что такое BPM”. А заодно - “что такое процессное управление”, “что такое документооборот” и в итоге “так что же такое, в конце концов, бизнес-процесс”?! Все это можно обсуждать и спорить, только лучше не на семинаре - никто ведь не отменял форумы, блоги и т.п. Например, есть новая площадка BPM Nexus, которую люди организовали специально для сверки и сближения позиций, а в идеале - для выработки консенсуса. У семинара другая, уникальная функция: рассмотрение реальных проектов, конкретных проблем создания BPM-систем (и в смысле ПО, и в смысле организации как системы). Как показывает опыт, для этого не подходят ни онлайновые ресурсы, ни конференции. Поэтому давайте оставаться именно в этом формате, ценить время семинаров и не тратить его на вопросы, которые можно обсуждать в других рамках.

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

По регламенту. Если время вышло, а докладчик закругляться не собирается, то председатель должен прервать его словами: “отведенное регламентом время закончилось, сколько еще вам надо?” и, получив ответ, обратиться уже к аудитории: “ну как, дадим?”. Это способствует атмосфере взаимного уважения.

Переходя к существу доклада - нам был представлен уникальный, без преувеличения, опыт тотального внедрения процессного управления (и процессного мышления) в компании численностью 700 человек. К тому же мы получили “два доклада в одном”: помимо основной темы использования Runa WFE нам рассказали про реализацию управление бизнес-процессов средствами 1С. Сравнение получилось интересным и поучительным.

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

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

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

Осталось у меня и несколько вопросов по докладу:

1. Использование Runa WFE с jBPM и вообще технологическим стеком jBOSS. Особенно с учетом того, что выходит 4-я версия jBPM, которая мне представляется весьма интересной. В частности, в ней jBPM переходит к нотации, близкой к BPMN.
2. Привязка к бумажным документам. Непонятно почему нельзя обойтись без них, непонятно даже - рассматривалась ли вообще безбумажная альтернатива. Вместо того, чтобы гонять в процессе бумажные документы, можно было собирать структурированную информацию, передавать электронные задания, а бумаги печатать на основе собранных данных только там, где это абсолютно необходимо (например, командировочное удостоверение, с которым сотрудник поедет  в чужую организацию). Но зачем в виде документов нужны заявление на отпуск или авансовый отчет - я не понимаю. Вроде мы рассматривали не колхоз “сорок лет без урожая”, а прогрессивную организацию! Естественно, в результате возникла масса проблем - ну не рассчитаны BPMS на такую работу.
3. Докладчик упомянул, что в какой-то момент возникли проблемы с масштабированием, которые были успешно решены. Хотелось бы получить подробности, но понятно, что все рассказывать в подробностях - никакого регламента не хватит.

Еще возник вопрос философского плана, не столько к докладчику, сколько к самому себе: нет ли связи между отмеченной неохотой расширять использование системы и ее “бесплатностью”? (Runa WFE - Open Source разработка.) Что дешево достается, то ровно настолько же и ценится.

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

Не могу удержаться и не утащить к себе на память цитату из: Madhav N. Sinha, “Winning back angry customers”, Quality Progress, American Society for Quality Control, November 1993. Отдельные пункты из этого списка цитируются часто, но в полном виде он производит гораздо более сильное впечатление.

1. Потребитель, недовольный продукцией или услугами, в среднем сообщает об этом 9-10 другим людям. В то же время, если жалоба должным образом удовлетворена и фирма разрешила возникшую у него проблему, то он информирует об этом только 5 человек.
2. На 1 зафиксированную жалобу приходится 19 неудовлетворенных потребителей, которые предпочли не обращаться с жалобой.
3. Привлечение нового потребителя обходится в 5-10 раз дороже удержания существующего.
4. Для преодоления у потребителя негативного впечатления от 1 случая требуется 12 позитивных.
5. Большинство компаний тратят 95% времени на устранение последствий возникших проблем, и всего лишь 5% на поиск причин.
6. Предпринимая попытку рассмотрения жалоб потребителя, более чем в 50% случаев компания только усиливает негативное впечатление о себе.

Конечно уместны вопросы о представительности статистики и о применимости ее к тому или иному рынку. Надо думать, за прошедшие 15 лет потребители стали еще более требовательными (если угодно - капризными), более информированными (в том числе благодаря Интернету) и менее склонными сносить плохой сервис. Если что и позволяет компаниям в некоторых случаях пренебрегать качеством сервиса, так это то, что “у других еще хуже”. Ну или локальная монополия.

В общем случае, надо стремиться, чтобы качество сервиса у тебя было заметно выше, чем у конкурентов. Конкуренты подтянулись - найди способ оторваться от них еще на шаг. Причем в отрыв уходить не надо - “идеальный” сервис слишком высоко поднимет издержки. Где-то я читал, что потребитель готов переплачивать за “абстрактно” более высокое качество - т.е. за то, без чего в принципе он мог бы обойтись - не более 15%. Даже если цену удалось удержать, у клиента может разыграться паранойя - “слишком уж тут круто, наверное в другом месте можно найти то же самое, но без понтов и дешевле”.

Тут как в прыжках с шестом - выгоднее 10 раз улучшать мировой рекорд по 1 сантиметру, чем один раз сразу на 10. В идеале надо иметь программу таких улучшений, т.е. просчитывать на несколько ходов вперед и отслеживать шаги конкурентов. А вывод из приведенной выше статистики заключается в том, что поле для такой игры есть!