Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Впечатления от семинара BPMS.ru 24.06.09

Первое и главное впечатление: это действительно был “семинар 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 разработка.) Что дешево достается, то ровно настолько же и ценится.

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

26.06.09 | Отклики | , ,    

Комментарии (11)

  1. Julia Wagner 26.06.09 15:45

    По поводу “бесплатности”. Я предпочитаю рассматривать не “стоимость продукта”, а “стоимость владения продуктом”. При этом второе может оказаться дороже.
    А по семинару полностью согласна с твоим мнением. У тебя, кстати, нет ощущения, что идем по нарастающей? Посмотрим, что получится у Федорова.

  2. bas 26.06.09 20:44

    Отлично. Можно что-то взять у Вас на вооружение :)
    Жалко, что не получилось прийти, узнаю почему-то в последний момент. Толи РСС с вашего сайта плохо работает, то ли что-то еще.
    Где можно почитать про следующий семинар - что когда где?

  3. Anatoly Belychook 28.06.09 20:03

    Э… Саша, разве ты не регистрировался на этот семинар? Похоже проблема не в РСС, а где-то между стулом и клавиатурой ;)

    Следующий планируется 8 июля, потом пауза скорее всего до октября.

  4. bas 29.06.09 14:16

    Да, я регистрировался, но узнал про него за 1 день, поэтому не получилось, но хотелось очень …
    Если можно, то публикуйте новость заранее с его описанием.

  5. Anatoly Belychook 29.06.09 14:54

    Так точно, объявление публикуется за две недели. На bpms, на livents и здесь. Только что опубликовано объявление о семинаре в следующую среду. (В этот раз меньше двух недель, потому что интервал короткий.) Все дружно регистрируемся!

  6. amikheev 30.06.09 18:17

    Ответы на вопросы:

    1. Использование Runa WFE с jBPM и вообще технологическим стеком jBOSS.
    Проект JBOSS JBPM - ориентирован скорее не на конечных пользователей, а на разработчиков программного обеспечения, встраивающих JBOSS JBPM в свои программные продукты.

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

    Я пробовал договориться с JBOSS JBPM чтобы они взяли эти компоненты в проект. Одно наше решение они даже взяли, но потом написали, что мы пишем очень много кода и они не в состоянии этот код проверять, а нести ответственность за чужой код не хотят и предложили мне вести отдельный проект на sourceforge.

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

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

    3. Докладчик упомянул, что в какой-то момент возникли проблемы с масштабированием, которые были успешно решены. Хотелось бы получить подробности…

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

  7. Anatoly Belychook 01.07.09 09:47

    Андрей

    Спасибо за подробные пояснения. Хорошо, что есть возможность после семинара расставить точки над i.

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

  8. amikheev 03.07.09 19:21

    В каких случаях бумажные документы могут быть “приводными ремнями”?

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

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

  9. LaptevDMV 10.07.09 09:19

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

  10. Alexander 17.08.09 18:58

    Анатолий,
    Немного отвлеку от темы семинаров, хотя они и для меня, ни разу до этого не побывавшего на них , представляют персональный интерес (просьба, если возможно, - оповещать/пригласить мэйлом).
    Весьма занятной оказалась ваша июльская полемика, - местами переходящая в заметную, хотя и политкорректную, перебранку (со стороны Макса) с вами и Кейтом - как расширенная реакция на публикацию в блоге последнего на тему “80% автоматизации”. А также обратил на себя внимание ваш богатый и практически безупречный аглицкий…
    Но должен заметить, что там обсуждается смесь расхождений идеологических ( с точки зрения наличия agility, etc.) и принципиальных разработческих/технических и др. возможностей. Работая в ЛУКОЙЛ-ИНФОРМе, я как “молодой боец” (несмотря на достаточно преклонный возраст в представлении ИТшников) на “фронте ВРМ”, не просто обращался с подобными перспективными предложениями в Корпоративный центр, но недавно даже выпустил в рабочей версии концептуальный трактат с обоснованием необходимости комплексного конструирования, интеграции, контроля, мониторинга и оптимизации бизнес-процессов именно с помощью инструментов BPMS + BI +CEP/ВАМ, а не “рисовалок” вроде стандартного ARIS.
    Дело в том, что нашими “верхами” затеян суперпроект с сочным названием “СССУ- Глобальная ИСУ Группы”, предусматривающий процессно-ориентированную реоганизацию и совершенстование всей системы управления, с соответствующей раб. группой по БП, в коей я имею честь присутствовать.
    Но, как всегда, идея скоренько была выхолощена. Во-первых, проектом ( с участием гибких консультантов с мировым именем!) затрагивается в основном верхний уровень, а во-вторых - главный предмет предобразований - правильно выстроенная система разграничения полномочий и ответственности владельцев и участников среднего звена и контроль результативноси (естественно, с сохранием существующего положения с бумажным документооборотов. И размер бизнеса с профилем компании тут ни причем - проблемы со старозаветскими гос.требованиями к отчетности и т.п. еще более бюрократически-жестки, чем для “немейджоров”!!). По крайней мере, на второй фазе проекта расхождение между начальным замыслом и унылой реальностью спустя полгода столь велико, что от энтуазизма мало что осталось, Хотя по третьему этапу надежды на возможность существенной модернизации все еще остаются. Посему рассуждения о “…закрытости корпоративных систем, стоящих перед тяжелым выбором: либо использовать встроенные в них средства workflow и бороться с их ограничениями, либо использовать внешние BPMS и бороться с проблемами интеграции, или выбрать оригинальное решение: взять на вооружение и то, и другое…. навести мосты между внешней и внутренней BPMS…” кажутся грустно-забавными…
    Однако это тема отдельного, скорее приватного и более глубокого обсуждения….

  11. Anatoly Belychook 17.08.09 22:10

    Александр

    Спасибо за ваш интерес. Чтобы не пропустить семинар, подпишитесь на RSS здесь или на bpms.ru. Или в linkedin запишитесь в группу bpms.ru - члены группы получают уведомления по почте.

    Забавно… бывал я у вас, причем как раз с презентацией продукта Кейта. Ну и всех идей BPM, естественно. Знаете, что мы услышали в ответ? “Нам ничего не надо, у нас уже все бизнес-процессы в САПе”. Правда, было это несколько лет назад. Так что видите, налицо прогресс. Это я пытаюсь излучать PMA - positive mental attitude ;)

    Если серьезно, то проекты, в которых верхний уровень не затрагивается, представляют собой не менее печальное зрелище. Типичный вариант - бизнес-процесс “обращение в ИТ сервис-деск”. Вопрос в том, как именно браться за этот самый верхний уровень. Если отталкиваться от референтных моделей имени уважаемых Arthur Andersen и Price Waterhouse, то скорее всего, на выходе будет только удовлетворение любознательности топов: “надо же как интересно оказывается у нас тут все устроено”. Но если расписать value chain в духе заветов Rummler/Brache и/или Lean Office, то это достаточно быстро выводит на операционные процессы и на существенное повышение операционной эффективности.

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

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

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

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

    Более предметные разговоры - в личке.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии