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

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

Записи с ключевым словом ‘BPMS’

О юридических гарантиях компетентности

Текст ниже - перевод отличной статьи из блога Скотта Фрэнсиса.

“Ваша цель - создать условия, приводящие к успеху.”

 
Нам в BP3 множество раз приходилось идти спасать проекты BPM, которые до этого не удалось запустить большим консалтинговым компаниям широкого профиля. Я решил, что будет полезно объяснить, почему подобные провалы происходят и как нам удается избежать подобных ловушек. Для начала, что мы обычно наблюдаем в таких проектах.

  1. Невероятно детальные спецификации софта, игнорирующие собственные возможности используемой платформы.
  2. В контракте поименно закреплены ресурсы (исполнители).
  3. Контракт охватывает все или большинство спецификаций, связывает поставщика конкретным описанием реализации и устраняет любые сомнения о желаемом продукте.
  4. Контракт очень жесткий, с требовательными спецификациями, штрафами за низкую производительность и очень низкими средними ставками исполнителей, участвующих в проекте.

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

06.07.15 | Guests | ,     Комментарии: закрыто

О самолетах для войны и для мирного времени

Мой дед Иван Феофанович Орленко был военным летчиком-торпедоносцем. Воевал на Балтике в 1944-1945, закончил войну командиром полка. (Пользуясь случаем, рекомендую тем, кто интересуется военной историей, сайт моего брата Олега Белайчука.)

На фотографии дед в центре с орденом Ушакова и двумя Красного знамени. А на борту машины можно разглядеть маркировку - это американский Бостон A-20G, поставлявшийся в СССР по ленд-лизу.

Среди множества историй, которые дед рассказывал (а он и книгу написал), запомнилась история про технику для военного и для мирного времени. Перескажу своими словами, как запомнил:

Когда мы получили Бостоны, машины поразили своим комфортом - в них было тепло! Можно было обойтись без унтов и меховых полушубков, к которым мы все привыкли. Но с началом боев обнаружилось, что Бостоны слишком хорошо горят. В чем дело? Стали разбираться и выяснили, что отопление работает от бензиновой печки, а бензопровод тянется через всю машину. Пуля, осколок - и машина сбита. В общем, демонтировали отопление и снова достали унты с полушубками.

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

BPM: вернуться к истокам

Почему все счастливые семьи счастливы одинаково, а несчастные несчастливы по-своему. Что такое канонiчный BPM, а что - BPM-ересь.

Мой доклад на BPM-конференции AHConferences. Впервые - вместе с полной аудиозаписью выступления:

Откуда есть пошли контент-менеджмент и документооборот

(Продолжение. Начало тут.)

Конечно хорошо, когда данные структурированы и лежат в БД в нормализованном виде: можно удобно и быстро извлекать, группировать, сравнивать. Чтобы делать это еще быстрее, поверх СУБД накрутили OLAP и гиперкубы, а чтобы не потеряться в лабиринте баз данных, которые создает под себя каждая прикладная система, придумали MDM.

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

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

Напрашивается идея выделить отдельный класс софта с перечисленным функционалом для обслуживания сущности под названием контент. Почему отдельный? Да потому что чем бы вы не занимались - регистрировали заказ в ERP, или выполняли задание в BPMS, или управляли проектом с помощью MS Project - вам везде потребуется контент и стандартный функционал для работы с ним. Ситуация в точности та же, что и с DBMS, и с BPMS: чем прикручивать этот функционал то там, то здесь, лучше один раз взяться и сделать как следует.

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

В результате в СУБД можно “немножко” реализовать и процессы (через смену состояний объекта и/или возможные переходы), и хранение контента (через binary поля); BPMS норовят похранить в себе, как в черном ящике, и данные, и контент; ECM претендует и на хранение вообще всего, а не только неструктурированного контента, и на то, что в нем можно автоматизировать процессы. Все подобные проявления, конечно же, следует категорически осудить.

И в частности, реализацию процессов в ECM, которую у нас называют документооборотом. (Есть еще слово workflow, но оно ругательное иностранное и поэтому широкими массами трудящихся заказчиков не воспринимается.) Документооборот в разумных пределах - вещь вполне осмысленная: в конце концов, в уважающей себя организации должны как-то учитываться официальные входящие и исходящие.

Беда в том, что особо ретивые автоматизаторы на этом не останавливаются. Хотите автоматизировать прием на работу - не вопрос, это ведь, в их трактовке, движение документа “заявление о приеме на работу”. Закупки? Тем более понятно, это ничто иное, как документ “Заявка на приобретение”. Какие еще структуры данных, какие схемы процессов? Все можно сделать с помощью вордового документа, его состояний и списка согласующих.

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

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

В общем, концепция документооборота это вот что:

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

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

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

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

Откуда есть пошли бизнес-процессы

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

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

ОК, сказано-сделано. Лет через 10 - к середине 80-х - появились коммерческие СУБД, в которых, в принципе, было все нужное для жизни. Появление 1) СУБД и 2) стандартного SQL стало мощным толчком для разработки бизнес-приложений - прошло еще лет пять, и буйным цветом расцвели ERP, чуть позже - CRM, PLM и прочие.

Правда нельзя сказать чтобы СУБД так уж гладко вошли в жизнь программистов. Сегодняшняя молодежь уже не представляет, что данными можно управляться как-то по-другому, а в свое время было достаточно много критиков, заявлявших “вот еще, придумали какие-то СУБД на нашу голову. Да я на ISAM-файлах сделаю алгоритм, который уделает вашу СУБД.”

Но победила точка зрения, что структурирование данных подчиняется своим законам и в общем-то не зависит от алгоритмов обработки. Грамотно спроектированная БД позволяет реализовывать хоть такие алгоритмы, хоть эдакие - в отличие от “программ, работающих на ISAM-файлах”. Кое-кто и посей день тащится от этой идеи. И вправду изящной, и что важнее - правильной, но не окончательной.

Сначала некоторое уточнение внесло ООП, в котором на вопрос “что важнее - члены или методы класса” ответ однозначный: методы. Данные могут быть структурированы любым способом, главное - поведение объекта. Это отличается от подхода к разработке корпоративных систем, в котором алгоритмы пляшут от данных, и который, если разобраться, восходит еще к мейнфреймам и коболу. В результате получили: с одной стороны - СУБД с приматом данных, с другой - ОО-алгоритмы с приматом поведения. Пришлось создавать науку под названием Object-Relational Mapping, чтобы технологично связать одно с другим.

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

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

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

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

Примерно в это же время наметился кризис в разработке приложений: давнее соперничество между концепциями “best of breed” и “single vendor” закончилось победой первой за неявкой противника. Ведь сегодня single vendor-ов уже фактически нет, а то, что преподносится в качестве таковых софтверными мега-вендорами, является слабосвязными наборами программных продуктов, собранными в результате слияний и поглощений.

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

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

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

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

Но впрямую отрицать идею инструментального управления бизнес-процессами все же чревато - заказчики не поймут - и производители ERP и CRM стали встраивать процессные движки в свои системы. Можно из них извлечь пользу? Безусловно. Способны ли они заменить специализированные BPMS? Сомнительно. Вспоминаются 90-е годы, когда в России были буквально сотни бухгалтерских программ. Многие из них работали на собственных самопальных СУБД, и это преподносилось как достоинство: “купив нашу программу, вы сможете не только автоматизировать бухгалтерию, но сами разрабатывать базы данных для любых задач”. Ну и где сейчас эти самопальные СУБД?

В конечном итоге, разработка прикладного и системного (инструментального и промежуточного тож) софта - это разный бизнес, с разными законами выживания и преуспевания. Чтобы быть конкурентоспособным на рынке DBMS или BPMS, их надо продавать не конечным пользователям, а разработчикам приложений. А кто будет покупать процессный движок у SAP или 1С, чтобы разрабатывать приложения? Правильно - никто. Разработчикам, уже работающим на этих платформах, покупать незачем - они его получают вместе с платформой. А остальным это и в голову не придет.

Из-за этого шансов успешно конкурировать с независимыми разработчиками BPMS у разработчиков прикладных систем нет, в долгосрочной перспективе. Прогресс в этой области не останавливается: надо обеспечивать поддержку стандартов (BPMN, WS, REST), надо реализовывать модную функциональность (мобильность, социальность, облака), надо или реализовывать самим, либо обеспечивать бесшовную интеграцию с дополнительными сервисами (BRMS, CEP, BAM)… надо или участвовать в гонке, или сходить с дистанции. SAP тянул собственную СУБД много лет, но в итоге с дистанции сошел.

В общем, история продолжается. Оставайтесь на связи, будет интересно.

Будущее BPM: замена или расширение?

Gartner, Pega и IBM начинают форсить новые аббревиатуры:

  • IBO = Intelligent Business Operations
  • iBPMS = Intelligent Business Process Management Suite

Судя по отзывам экспертов, особой концептуальной новизны не наблюдается - скорее идет эволюционный процесс интеграции смежных технологий: BPMS, BAM, BRE, CEP, ACM… Похоже кое-кто решил, что настало время переклеивать новые лейблы поверх старых BPM/BPMS.

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

Хотелось бы видеть прорывы в технологии и методологии, а не в акронимах. С этой точки зрения мне более интересна инициатива bpmNEXT. Цитирую меморандум Брюса Силвера и Натаниеля Палмера:

Мы оба не согласны с тем, что BPM мертв… или что BPM устал. На самом деле инновации, связанные с облаками, событийной аналитикой, кейс-менеджментом, мобильными приложения и социальными сетями питают инновации в области BPM с интенсивностью, которой мы не наблюдали годами.

Для сравнения, 10 лет назад в процессном управлении произошел достаточно радикальный пересмотр и методологии, и технологии:

  • непрерывное усовершенствование вместо однократного реинжиниринга
  • интегрированные BPM Suite вместо разрозненных средств моделирования и workflow-движков
  • Agile разработка вместо “водопада”

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

И очень хорошо - хватит уже начинать с чистого листа: TQM, реинжиниринг, BPM… Это разрушает рынок, так как порождает у потенциальных заказчиков чувство неуверенности. Какой смысл браться за реализацию нового акронима, когда предыдущий, с которым те же самые консультанты носились последние годы, так легко сдали в утиль?

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

Размышления об S-BPM

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

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

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

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

Мастер-классы BPMS.ru

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

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

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

Предпочтительный формат мастер-класса - живая демонстрация создания проекта “с нуля”. Что не удастся показать вживую - про то рассказать словами. Время на доклад - 1 час.

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

Первый мастер-класс пройдет в среду 14 декабря, начало в 19 часов, регистрация на bpms.ru. Обсуждать можно там же, а также на linkedin и facebook.

Желающих выступить с докладом и презентовать любимую систему BPMS у организаторов достаточно. На первом мастер-классе собиралась выступить компания Элевайз с системой Элма, но в последний момент они отказались, чем подвели организаторов и 100+ зарегистрировавшихся на мероприятие.

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

В планах - демонстрация Oracle, отечественной Runa, IBM (ex-Lombardi) и других систем. Оставайтесь на связи.

10.12.11 | Новости | , ,     Комментарии: закрыто

Законы робототехники BPM

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

В самом деле: что мы имеем в виду, когда говорим о контроле за бизнес-процессами? И надо ли считать параноиками участников процесса, когда они подозревают, что на самом деле цель всей этой затеи - контролировать их самих?

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

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

Это сложные задачи. Реально сложные.

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

Пример:

  • Небольшая торговая компания, специализирующаяся на товарах «с изюминкой» - гаджетах, прикольных подарках, дизайнерских аксессуарах для ванн и т.п.
  • Группа процессов под названием «Управление ассортиментом»: несколько сотрудников постоянно мониторят интернет, ходят на выставки, заглядывают в магазины конкурентов - ищут новые идеи, бренды, новых поставщиков. С одной стороны, в силу специализации компании ассортимент должен постоянно пополняется модными штучками, а с другой - ассортимент не может быть слишком большим, его надо постоянно прореживать.
  • Эти несколько человек ежемесячно оценивают до тысячи кандидатов на включение в ассортимент. Компания выработала трехступенчатое сито отбора: сначала экспертная экспресс-оценка, бракующая большинство идей. Затем переговоры с поставщиком, проработка логистики и оценка возможной прибыльности. Затем - раз в месяц - ранжирование идей, прошедших первую и вторую квалификацию, и отбор кандидатов на пробную закупку и реализацию с учетом имеющегося на данный момент бюджета на расширение ассортимента.
  • Параллельно, также примерно раз в месяц, весь текущий ассортимент анализируется с точки зрения фактической продаваемости, разнообразия и т.д.

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

Что тут можно сделать, если идти по пути наименьшего сопротивления? Ну например, можно автоматизировать оценку кандидатов на включение в ассортимент - сделать процесс из пяти последовательных шагов:

  1. узнать цены у поставщика
  2. узнать условия поставки
  3. оценить продаваемость
  4. назначить рейтинг
  5. принять решение о пробной закупке

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

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

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

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

Но по пути вам придется преодолеть их недоверие - изначально внизу никто ничего хорошего от словосочетания «бизнес-процесс» не ждет. Вот как я это делаю в разговорах с людьми:

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

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

Кто, скажите мне, откажется от такого помощника?

К тому же BPM-робот безопасен, потому что он подчиняется законам - хотя и не тем, что у Айзимова.

Законы робототехники BPM:

  1. Робот никогда не сможет сделать все то, что можете сделать вы.
  2. Робот будет делать только часть того, что делаете вы.
  3. Робот будет делать только ту часть вашей работы, которую вы сами не захотите делать.

Моделирование в BPMN решений, принимаемых людьми

К сожалению, вопрос “как в BPMN моделировать решения, принимаемые людьми” не относится к числу часто задаваемых.

“К сожалению” потому, что ответ, который новичку кажется очевидным, на самом деле неправилен. Это вот не развилка, это распараллеливание процесса:

На выходе из задачи “Рассмотреть заявку” процесс продолжится параллельно по исходящим ветвям вне зависимости от того, что на них написано.

Правильная BPMN-диаграмма выглядит так:

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

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

Пользовательский интерфейс для шага, на котором принимается решение, выглядит примерно так:

По кнопке “Выполнено” форма закрывается, и задача считается выполненной.

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

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

Будь моя воля, я бы ввел в BPMN явную поддержку решений, принимаемых людьми. Так как первая диаграмма вверху на самом деле интуитивно больше походит на принятие решения, чем правильная BPMN-диаграмма, я бы оттолкнулся от нее:

Здесь к существующим типам потока управления Control Flow, Conditional Flow и Uncontrolled Flow добавлен еще один: Human Controlled Flow, помеченный двойной поперечной черточкой.

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

Если от человека требуют принять решение, то форма должна выглядеть так:

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

Впрочем, такой подход можно ведь практиковать и для стандартных BPMN-диаграмм:

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

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

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