Был приятно удивлен вчерашним мероприятием BPMS.RU Выступал Кирилл Курышев (bpexpert) с рассказом о разработанном framework для автоматизации деятельности страховых компаний. Возможно, я услышал именно то, что хотел услышать но, тем не менее, расскажу свое впечатление (надеюсь тем самым не раскрыть каких-либо коммерческих секретов).
Framework создан поверх Oracle BPM и включает в себя: набор шаблонов бизнес процессов, структуры данных предметной области автострахование, набор средств для отображения орг.структуры организации в роли участников процессов, архитектуру интеграции с существующими системами заказчика. Почему тема отраслевого framework для BPM показалась мне интересной. Тем, кто знаком с темой управления бизнес-процессами известно, что современные BPMS похожи на пустой стакан. В них нет никаких бизнес-процессов. Какие именно процессы и как будут реализованы, определяет не вендор BPMS, а системный интегратор, который осуществляет внедрение. В стакан можно налить воду, вино, чай или уксус. Framework делает этот стакан полуполным или, если хотите, полупустым. Я думаю на отечественном ИТ рынке легко найдется несколько десятков компаний, готовых предложить вам услуги по внедрению BPMS от ведущих вендоров Oracle, IBM и т.п. bpExpert вместо этого предлагает отталкивать от реализованных проектов, а не писать решение с чистого листа. Я не знаю хорошо это или плохо с точки зрения управления бизнес-процессами страхования, но с точки зрения маркетинга ИТ услуг такой подход абсолютно верен и вот почему:
Что делает посредственный системный интегратор? Он действует в соответствии с методологией unified process, рекомендациями по управлению требованиями IEEE-STD-830 и прочими аналогичными анахронизмами. Сначала заказчику предлагают написать полные, непротиворечивые, однозначно трактуемые функциональные требования. Понятно, что получается это не очень хорошо, особенно с первого раза. Затем на основании требований начинают сочинять ТЗ, в котором тоже присутствуют недоговоренности и неоднозначности. В ходе проектирования создают модели бизнес-процессов и, в лучшем случае, их даже прототипируют. В общем, примерно через годик, к завершению первой итерации рождается программный монстрик как-то отвечающий страхам и чаяниям заказчика.
Что делает правильный системный интегратор? Он приносит заказчику структуры данных и шаблоны бизнес-процессов и начинает вместе с ним их адаптировать. Никакого насилия в виде сбора требований. Уж тем более заказчика не заставляют описывать процессы в BPMN нотации. Исправить можно все что угодно. Дополнить решение еще несколькими процессами – не вопрос. Естественно, все процессы уже работают. Можно посмотреть, высказать пожелания по готовому прототипу. Что-то не исправили в первую итерацию – исправим в следующую. Кстати, риски того, что к запланированному сроку ничего не заработает – отсутствуют
Честно говоря, ничего нового в этом нет. Внедрение ERP и любых других «готовых систем» осуществляется по аналогичному сценарию. Только ERP системы изначально закрыты. Никто не позволит вам менять структуру СУБД или основные рабочие процессы. Как справедливо заметил Анатолий Белайчук
ERP системы как цемент. Они гибкие, кастомизируемые и настраиваемые, но только однажды. Цементный раствор тоже можно залить в любую ёмкость и он примет её форму. Только сделать это можно всего один раз, пока цемент не застыл.
C BPMS ситуация иная. Исправлять можно и нужно. Инструмент для этого и задумывался.
И еще один важный момент сегодняшнего доклада – уважительное, я бы даже сказал бережное отношение к унаследованным приложениям заказчика. В любой компании существует и работает множество информационных систем (результат кусочно-лоскутной автоматизации). Но в рамках BPM проекта никто не собирается выводить их из эксплуатации. Наоборот BPMS их активно использует, ну, по крайней мере, в качестве хранилища данных.
Like the comparison of ERP with “цемент”.
Not sure that this approach should be called “bottom-up”. It looks more “process-enabled” (or “middle-out”).
Thanks,
AS