Comments 14
А то человек не в теме решит либо: «А у нас уже есть BPMS. СЭОДО 10 лет как внедрили», либо наоборот захочет проблемы подходящие, скажем для JIRA, решать через BPMS.
В этой компании ответственным за согласование расходов является генеральный директор, и вот что необходимо было сделать, чтобы он смог выполнять свои функции по согласованию:
создать доступ в систему;
обучить работе с необходимыми документами;
настроить интерфейс для удобства использования;
настроить права доступа.
Но ведь это все делается один раз? Не вижу, как можно этого избежать в любой другой системе.
И такой еще вопрос:
Представьте, что счетов очень много. У нас, например, бухгалтерия только платежки носит пачками по 250-300 листов за раз (с сопрводительными документами, естественно). На чем в реальной жизни зарабатывает тортики и даже серьезные откаты финансовый департамент? На ускорении либо замедлении проплат по счетам.
Если финансисту нужно ускорить проплату, он подсовывает упрощенную информацию -сколько/кому/за что — финальной инстанции, а потом собирает сопроводительные документы уже заручившись подписью генерального.
Если же финансист получает деньги угрожая затянуть платеж, то уже после подписи шефа он может подержать счет еще неделю, собирая пропущенную информацию.
Так что, что жестко регламентировать придется каждый этап — и я опять-таки не вижу особой разницы в подходе.
При этом в учетной системе приходилось заполнять много лишней информации для создания и согласования заявки: расчетный счет получателя и собственной компании, контрагент, статья расходов, статья движения денежных средств, основание и т.д. Вся эта информация, на самом деле, не нужна генеральному директору для принятия решения, но, тем не менее, ее необходимо заполнять сотруднику, отправляющему заявку.
Счета приносят, потому что есть контракт. Контракт зарегистрирован в системе. Вышеуказанная «лишняя» информация вносится один раз — контракт, сроки, условия, реквизиты, сумма или бюджет контракта. Автоматизированная система, в которой нужно вносить такую информацию каждый раз по получении чета — недоавтоматизированная система.
Для принятия решения в данном случае интересны только 3 момента:
деньги (сколько мы должны выплатить);
получатель (кому мы должны выплатить);
назначение (за что выплачиваем).
А, значит, заполняя лишнюю информацию, сотрудник теряет время, и процесс согласования затягивается.
В реальном мире ни один руководитель не станет подписывать платежный документ, зная что сопроводительная информация может быть полностью не собрана или сокрыта.
Вы извините, что я чот прям накинулся. Просто с корпоративными проплатами натерпелся.
Основные части BPMS:
1. Красивая схемка т.н. «бизнес процесса», желательно с визуальной программулиной, позволяющей расставлять на листе «ящички». И которая еще позволяет «запускать» процессы и показывать где он сейчас выполняется. Без этого не ничего продастся.
2. Некий навороченный «BPM-движок» весом в 30кб (jBPM), позволяющий «выполнять» позадачно диаграмму. Практически всегда требует базу данных, чтобы состоянию было куда-то сохраняться.
3. Fallback в какую-нибудь реальную среду проргаммирования: java, xquery, PL, etc… Как ни вертись, а ящики на диаграмме никакой полезной нагрузки не несут — приходится все-таки на чем-то кодить.
4. Паровозом предлагают средства интеграции с внешним миром: какую-нибудь самопальную ESB, JEE коннекторы, адаптеры, вебсервисы, etc…
5. Ну и самая основная часть — портал для Human Task-ов. Без него все ваши BPMS вообще не имеют смысла (а до 2005 года они скромно назывались Workflow). Визуально список папок по таскам а ля Outlook, на каждую задачу убогая стандартная формочка с данными, которую чтобы кастомизировать, то проще свой портал написать.
Что не так с BPM? А практически все.
— Вопреки изначальной идее, как ни старайся, динамически процесс изменить не удастся. Бизнес аналист расставит ящики и стрелочки. Затем каждый ящик закодит кодер. Затем аналист поменяет местами ящики в надежде, что все будет работать, но процесс благополучно упадет. Сколько ни пытался Oracle сделать колаборацию двух тулзов: BAM и BPM — хорошо все только на поверпоинтах.
— Резко поменалась бизнес логика, но половина процессов еще идет по старой версии. А интерфейсы, среда, база, модель — все уже новое. Версионность — основной бич всех BPM. Если в своем велосипеде ты полностью контролируешь педали, и можно эволюционировать запущенные процессы, просто актуализнув базу, то в пропиетарной BPMS — хрен ты до чего докопаешься.
— Возможности портала убоги. Всегда плохо адаптируется к реальным потребностям в интерфейсе. Интегрировать BPM в свой корпоративный портал тот еще танец с бубном.
— Одним BPM-ом сыт не будешь. Ящики должны выполнять какие-то полезные действия. Не всем же только управлять! Поэтому кодить все-равно придется. Но всегда где-то сбоку в окошке или через задницу.
— Интеграция. Достижение нашей BPMS в том, что есть специальный ящик, который умеет вызывать вебсервис. Правда хост намертво прибит гвоздями без возможности поменять, и все мэппинги нужно мышкой прокликивать в специальном окошечке, но это не беда.
— Ну и как бы зачем? Есть миллион других способов биться головой об стенку. Практика показывает, что эти решения не работают.
Вобщем, BPM — это исключительно инструмент бизнес-аналиста, и пусть таким и остается. А у нас, кодеров, свои приблуды. И нехрен мешать дерьмо с мармеладом!
Но всё таки это, немного, видение ситуации со стороны программиста. Положительный эффект для организации от внедрения BPMS может достигаться несмотря на весь негатив от ИТ. Только сформулировать его для себя я пока не могу.
Автоматизация основных бизнес-процессов? Не лучше в ERP это сразу делать. Настраиваемые бизнес-процессы сейчас даже в 1С есть.
Автоматизация неосновной деятельности? Здесь есть СЭДО, всевозможные issue-tracker’ы. Тоже все с воркфлоу.
Интеграционная платформа? Тут тоже явно есть более зрелые кандидаты. BizTalk, например. Тоже с оркестрацией.
При этом рынок BPMS вроде растёт, какие-то внедрения идут.
Что это? Чистый гербалайф?
Хотелось бы услышать от автора статьи его мнение, какой он идеальный для клиента кейс внедрения BPMS?
Отвечу я, как бывший главный аналитик проекта, который был признан "BPM-проектом года" на конкурсе проектов в области BPM в 2017 г. (https://bpmaward.ru/cat/2017/; презентация проекта тут: https://bpmaward.ru/wp-content/uploads/2017/09/Сбербанк-BPM-проект-года.pdf).
0. Термины и определения. BPM - это управление бизнес-процессами (Business process management) - дисциплина. Придумана, чтобы управлять бизнес-процессами процессами (автоматизация - часть управления, и IT видит бизнес-процессы лишь в части задач автоматизации, но как правило, не как полный цикл управления). BPMS - система для управления бизнес-процессами, автоматизирующая исполнение и часть функций управления бизнес-процессами. Их не надо путать.
1. Нам (за счет того, что мы явно разделили работу с данными и работу с задачами на уровне проектируемых процессов, ввели переиспользуемые процессы, продумали, как версионировать процессы, и сделали еще много достаточно толковых вещей) удалось сократить time to market при изменениях в автоматизируемых бизнес-процессах в 1,5 раза.
2. Популярность BPMS в западных странах где-то в 2010-х (после перехода к более-менее осмысленному внедрению BPMS) немного снизилась, а потом опять пошла вверх (думаю, не в последнюю очередь за счет появления отраслевых стандартов и open source движков для BPMS). Клиенты BPMS - банки, страховые компании, медицинские учреждения, телеком - те, кто ведет своих клиентов через достаточно строго регламентированные процедуры. В Европе в конце 2010-х каждый пятый банк внедрял BPMS.
3. Лично я очевидное преимущество BPMS вижу в том, что высоких требований к искусству программирования (т.е. к квалификации) поддерживающих ее программистов они, как правило, не предъявляют (BPMS - это вообще про low code). В общем, толковый аналитик с минимальным опытом программирования на том языке, который используется для написания кода на той платформе, на которой реализована BPMS, вполне справится.
4. Из BPMS в последнее время наибольшую популярность приобретает Camunda (вот и Тинькофф банк, например, нашел для нее нишу; популяризует BPMN 2.0 https://bpmn2.ru/). На сайте https://bpmaward.ru/ можно найти примеры живых внедрений BPMS. Наша, к слову скажем, реализация BPMS до сих пор живее всех живых, является частью платформы Platform V.
Так что опыт разный, отношение к BPMS тоже разное.
Что такое BPMS