Очевидно же? Или нет? Видимо нет, судя по регулярно возобновляющимся дискуссиям и аргументам типа «мы к стандарту BPMN 2.0 относимся творчески, у нас принят собственный набор правил, более понятных пользователям» или, мое любимое, «мы улучшили стандарт».
С аргументом «нам так удобнее» спорить сложно, т.к. удобно-неудобно – критерий абсолютно субъективный. Ваше мнение против моего – ничего доказать невозможно в принципе.
Но давайте вспомним, а зачем собственно люди придумывали стандарт? Причем надо понимать, что это потребовало серьезных интеллектуальных и организационных усилий – как свидетельствует Брюс Сильвер, «выпуск спецификации BPMN 2.0 полностью исчерпал ресурсы команды разработчиков».
Я бы выделил три ключевые проблемы:
- Отсутствие стандарта приводит к искажениям смысла: трактовка диаграммы процесса оказывается неоднозначной – автор (например, аналитик) имел в виду одно, а читатели (бизнес-пользователь, программист) увидели другое.
- Отсутствие стандарта приводит к зависимости от производителя программного обеспечения. Программные продукты несовместимы друг с другом – перенести модель из одного в другой можно только «экспортом-импортом через принтер». (Справедливости ради, еще до появления стандарта BPMN WfMC разработал формат XPDL, который частично решал эту проблему.)
- Отсутствие стандарта затрудняет накопление компетенций – это все равно как вместо общенационального языка, универсальных учебников, толковых словарей и великолепной классической русской литературы у нас в стране была бы только куча диалектов с ограниченным числом носителей у каждого.
Соответственно, когда компания отказывается от следования международному стандарту, подменяя его локальными нормативно-методическими документами, она получает все эти проблемы:
1. Чтобы понять, что изображено на диаграмме, недостаточно знать BPMN – необходимо предварительно проштудировать локальное соглашение о моделировании.
Для начала кто-то должен будет его написать. Тут надо понимать, что даже крупной компании сложно выделить ресурсы для такой разработки с качеством, сравнимым с качеством международного стандарта. Поэтому скорее всего, документ получится неполным, противоречивым, неконкретным, но при этом объемным и многословным.
2. Все заинтересованные стороны – аналитики, айтишники, бизнес-пользователи – должны будут усвоить внутренний стандарт. Вероятно, придется развернуть внутренние тренинги, разработать учебные материалы.
Имеющуюся обширную литературу по BPMN использовать не получится, ведь она будет противоречить внутреннему стандарту. Отправить сотрудников на внешний тренинг – аналогично.
3. Компания не сможет просто взять с рынка труда сертифицированного аналитика, знающего BPMN – его придется переучивать.
Причем чем более квалифицированный специалист, чем лучше он знает и умеет применять BPMN, тем сложнее его переучивать и тем больше риск, что он не захочет терять квалификацию и компания в итоге его потеряет.
4. Придется кастомизировать программное обеспечение, чтобы оно поддерживало наши специфические правила и стиль моделирования.
Это дорого, это зависимость от разработчика программного продукта. Разрабатывать собственный еще дороже, для большинства – запретительно дорого. ПО с открытым кодом не спасает, т.к. как только мы начинаем вносить в него свои правки, поддерживать его в дальнейшем будет не сообщество разработчиков, а мы сами, за свой счет.
5. Обмен моделями с внешними консультантами, бизнес-партнерами, поставщиками окажется затруднен.
Они не смогут импортировать наши модели, потому что они содержат элементы или конструкции, не предусмотренные стандартом. Мы не сможем импортировать их модели, потому что наше соглашение запрещает элементы, предусмотренные стандартом.
Таким образом, собственный «локальный стандарт BPMN» – это потери. А с потерями что полагается делать? Правильно – устранять.
Но дело не только в потерях.
Пример 1.
Вы затеяли у себя дома ремонт – не просто переклеить обои, а перепланировка с переносом стен, заменой электрики и т.п. Архитектор сделал проект – экспликация помещений, развертки стен, силовая проводка, слаботочная проводка, водопровод-канализация, …
Но в архитектурном бюро принята собственная система обозначений для схемы электропроводки с оригинальными значками для розеток, светильников и выключателей. Проект принят, приходят строители. Профессионал-электрик смотрит на чертеж – ЧТО ЭТО?!
Оно вам надо?
Пример 2.
Вы решили совершить небольшой круиз на парусной яхте с наемным шкипером. Обсуждаете с ним маршрут, и тут выясняется, что он нетвердо знает условные значки на карте.
Решитесь выйти с ним в море?
6. Знание стандартов и следование стандартом – признаки профессионала.
Непрофессионализм – это всегда риски, зачастую непросчитываемые.
