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

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

Семинар по BPM для аудитории UML2.ru

Коллеги с дружественного ресурса UML2.ru проявляют все больший интерес к теме BPM. Причем интерес специфический - идущий не от ИТ-шника, что встречается чаще, а аналитика.

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

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

Дата: четверг 18.12, время: с 18:00 до 21:00, адрес: Покровский бульвар. Доступ открытый и бесплатный, но внимание: при условии заблаговременной регистрации. Все подробности и регистрация - на livents.ru.

10.12.08 | Новости | ,    

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

  1. nvoynov 12.12.08 14:13

    > интерес от аналитика

    А зачем оно ай-тишнику, и кто он такой настоящий ай-ти-шник? Если программист то все сам запрограммирует :)

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

    Я как-то разговаривал с авторами runa wfe (http://wf.runa.ru/), построенной на JBoss jBPM и они в своих статьях наставали на упрощении языка (BPEL ругали сложностью .. уже позабыл аббревиатуры (: ). Опять же по поводу JBoss jBPM можно вспомнить Исмаэля CIO Intalio, как он его ругал и ратовал за рисование связей в своем датаМаппере, а сейчас они переходят на SimPEL скриптовой язык на основе Ruby. Потом последняя находка OpenWFEru - open source Ruby workflow and BPM engine - тоже свой язык, никак не связанный со стандартами …

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

  2. nvoynov 12.12.08 14:14

    сори рисовать BPMN

  3. Anatoly Belychook 12.12.08 14:42

    Николай

    “Your words, not mine” - разве я где-то говорил о BPMN? Напротив, я всем говорю, что BPMN - это типа как “стандартный SQL”: изучать можно и нужно, но если собираешься делать что-то реальное, то готовься к плотному изучению диалекта конкретной СУБД и ее же СУБД особенностей в части тюнинга и т.д. Только в случае BPMS все гораздо более запущено, так как технология моложе DBMS на 20 лет. Но вот я сейчас пишу статью для “Открытых систем”, и чем мне там иллюстрировать схемы процессов? Естественно, BPMN - не вендорской нотацией же.

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

  4. Alexander Samarin 12.12.08 20:12

    The scenarion of joint work is realistic.

    But a BPM suite and an established modelling procedure should protect a business analyst from
    “несоответствия сложившейся инфраструктуре, корпоративными стандартами и вообще требованиям реализации”

    Thanks,
    AS

  5. Anatoly Belychook 12.12.08 22:52

    Он конечно should, кто бы спорил. В идеальном мире. В Швейцарии :) Но большинство из нас не может представить себе жизни иной, чем жизнь на вулкане :)

    Если серьезно, то тут есть риск впасть в другую крайность. Я знавал людей (некоторые из них были моими подчиненными), которые, принимаясь за любое дело, начинали с того, что принимались за разработку корпоративных стандартов. Все-таки первичен результат. За него тебе платят зарплату, а за корпоративные стандарты и вообще за вклад в дело мира и культуру организации платят премию.

    Надеяться, что от этого спасет BPMS? Не знаю. Word страхует от грамматических ошибок, но не от содержательных.

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

  6. Alexander Samarin 13.12.08 13:05

    Ну насчет тезиса о первичности результата надо сначала уточнить понятия – мы тут в футбол-хоккей играем или как?

    Как известно, ИТ индустрия давно глобальна, так что подавляющее большинство участников (независимо от ландшафта) не следует классическому “лучше меньше да лучше“.

    Стандарты, как часть архитектуры, направлены на уменьшение стоимости программных решений на всем их жизненном цикле. Конечно, утром архитектура, вечером стандарты.

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

    Thanks,
    AS

  7. nvoynov 17.12.08 15:52

    .. про BPM, аналитик и каким боком BPMN. Я нашел BPM через рисование. Давно люблю рисовать - с удовольствием и часто пользой рисовал в свое время ER/SADT/UML. Прецеденты (кажется те, которые выше уровня моря по Алистеру Коуберну) отличная описательная штука процессов (не use-case диаграммы) и вполне неплохо описываются посредством BPMN. Т.е. мне кажется - заинтересованность аналитиков - именно описание рабочих процессов предметной области.

  8. Anatoly Belychook 19.12.08 13:07

    Распространенная первая реакция при знакомстве с BPMS: “подумаешь, я видел рисовалки и покруче”. И это в общем-то правильно: “фишка” BPM не в рисовании.

  9. Natalya Fominykh 25.12.08 17:11

    Анатолий, спасибо Вам огромное за проведённый семинар! Очень важно реально ощутить вокруг себя людей увлекающихся тем же, что и ты сам. Для меня доклад пролил свет на многие моменты - и по большому счету не только структурировал взгляд на “BPM и BPMS вообще”, но и наглядно дал представление о BPMS в действии. Это здорово, что проектируя, и отлаживая бизнес-процессы можно в текущем режиме исправлять неочевидные перекосы. На мой взгляд, данная концепция при внедрении на предприятиях дисциплинирует не только служащих, но и руководителей.

  10. Anatoly Belychook 25.12.08 17:48

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

    Более обстоятельную демонстрацию можно посмотреть тут: http://www.unify.ru/demo/bpm/index.html, а составить представление как оно может выглядеть не в демонстрации, а в реальном проекте - тут: http://www.b-k.ru/solutions/logisticdemo/

    Обращаюсь к Вам и к другим участникам: какие еще вопросы, по вашему мнению, стоило бы осветить, что осталось за кадром?

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

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

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

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