Изъяны бизнес-процессов прячутся в данных

Пока я беззаботно отдыхал на горнолыжных склонах Италии, вокруг статьи Анатолия Белайчука ACM: парадигма или фича? разгорелась довольно оживленная дискуссия. Дискуссия, в основном, проходила в англоязычной блогосфере, однако, краткий русскоязычный обзор оной можно почитать здесь BPM, ACM, Social BPM – что говорят эксперты? (Спасибо WJ)

Честно говоря, мне не хочется сейчас отвечать на вопрос дискуссии. ACM родилась в недрах BPM (или может BPMS), однако причины, вызвавшие её появление, на мой взгляд, лежат значительно глубже. Они в изменении характера деятельности современного служащего

Давайте перенесемся лет на 15 назад и посмотрим, чем занимались обычные офисные служащие. Большинство из них работало с документами. Некоторые – с материальными ценностями. В любом случае, все работали с предметами. Возьмем для примера ИТшника. Он либо монтировал сервера, либо разрабатывал программы, либо писал/согласовывал документы. Что делает ИТшник сегодня? Думаете, он пишет программы или настраивает оборудование? Ничего подобного. Современный ИТшник решает инциденты, исправляет дефекты, обрабатывает запросы на изменения. Вроде бы и ребята те же самые, но благодаря внедрению процессного подхода в ИТ их образ мысли изменился до неузнаваемости. Они больше не работаю с предметами реального мира, а трудятся в пространстве виртуальных объектов. Сервер, документ, даже программа – вещи вполне материальные. У них есть набор четко определенных свойств. Вы легко их можете описать и сохранить в базе данных. У сервера есть, как минимум длина, ширина и высота, которые никуда не денутся и, по всей видимости, не изменятся. А вот что такое инцидент? Вообще-то, это образ обращения клиента. Вот только свойства у него, по большей части, виртуальные. Приоритет, важность, затрагиваемые конфигурационные единицы… Один сбои может породить массу инцидентов и наоборот в ходе решения одного инцидента может выявиться несколько несвязанных проблем. И подобные виртуальные сущности развелись не только в ИТ

Оккама безнадежно забыт. Современные бюрократические машины без устали генерят виртуальные сущности сверх всякой меры. Проектный подход, процессный подход выплескивают как на бумагу, таки в компьютеры колоссальное количество мнимых объектов, не имеющих аналога в материальном мире. И куда все это попадает? Ну, вообще говоря, в реляционные базы данных. Но реляционная модель придумывалась для объектов и событий реального мира, учета оборудования, регистрации бумажных документов и т.д., т.е. объектов с заданным набором четко определенных свойств. Вы, конечно, можете засунуть в реляционную базу данных и виртуальные сущности, но проблема в том, что в момент проектирования такой базы данных вы сами до конца не понимаете, что именно вы там собрались хранить. Какие у этого «виртуального зверя» свойства и как они соотносятся друг с другом. А потому, можно совершенно четко, не прибегая к помощи астролога, предсказать, что требования к вашей системе изменятся. А потом еще раз изменятся. И еще несколько раз изменятся. Причем здесь процессы? Да процессы завязаны на данные. Собственно говоря, именно данные и определяют, по какой ветке будет развиваться процесс. Только процессы, а порядок сложнее данных, потому как несут в себе историю, да еще и коррелируют друг с другом. Процессы породили эти виртуальные сущности. Процессы сами являются такими сущностями, данными об экземплярах, их состояниях. Одним словом, процессы не сумели справиться сами с собой.

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

Изъяны бизнес-процессов прячутся в данных: 7 комментариев

  1. “А потому, можно совершенно четко, не прибегая к помощи астролога, предсказать, что требования к вашей системе изменятся. А потом еще раз изменятся. И еще несколько раз изменятся. Причем здесь процессы?”

    Change of requirements to a system leads to changes of some system’s artefacts (rules, roles, events, documents, services, etc.). To change those changes rather efficient, a) all artefacts should be versionable and b) it should be easy to (re-)assemble complex artefacts from smaller ones. Processes are the mean to assemble artefacts. (Also, process is one of those artefacts). Important that such “assembling” is _explicit_ to a (super-)user.

    In my experience, use of the power of processes reduced the amount of classic IT efforts (implementation, deployment, exploitation) in about 10 times.

    Thanks,
    AS

    1. Александр, спасибо за комментарий.

      Безусловно, версионирование артефактов и возможность внесения изменений в процессы важны. Собственно говоря, значительная часть деятельности ИТ-поставщиков и заключается в сопровождении систем, т.е. адаптации их под постоянно меняющиеся требования. Но я написал немного о другом. Причина, по которой требования постоянно меняются – в «виртуальности» объекта автоматизации. Идет своего рода «гонка вооружений». Чем быстрее вносятся изменения, тем больше возможности по появлению новых требований. Для ИТ это хорошо. Для эффективности бизнеса – не уверен.

      Я думаю, что контроль за адекватностью требований это вопрос методологии. В частности, BPM – значительный шаг, позволивший преобразовать требования из списка «хотелок» в описание связных последовательности скоординированных действий. Но главное, что в отличии от требований у процессов есть цель.

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

  2. Уж и так наследил я тут в комментах, пора себя сдерживать, но увидев фразу “Оккама безнадежно забыт” не мог не ответить 🙂 Забыть-то его можно, но только так же, как склероз, который вылечить нельзя, а можно о нем забыть. Принцип Оккама безнадежно забыт очень многими в ИТ, если не всеми, апофеозом стала ОС Vista от MS, сконцентрировавшая в себе мировой тренд “новизна подменяется сложностью”. Когда сказать нечего, идей нет, а новые версии надо выпкскать, чтобы генерить инком, тогда и получаются такие монстры. И с BPM такая же история.

    А ACM можно трактовать как ответ рынка на затянувшиеся мучения пользователей с BPM. Как возврат к простоте и фундаментальному принципу монаха Оккама

    1. Johnker, Ваши комментарии интересны.
      Относительно принципа Оккама, так забыт он из тривиальных маркетинговых соображений. К сожалению, в современном нам ИТ побеждают не те компании, которые умеют делать хороший софт, а те, кто наилучшим образом извлекает прибыль.

  3. Thanks Maxim.

    “Для ИТ это хорошо. Для эффективности бизнеса – не уверен.” – My experience is completely opposite: IT does not like the flexibility brought by BPM and the business loves it (no need for the systematic involvement of IT).

    Agree about your “дальнейшее движение к эффективности”.

    Thanks,
    AS

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

    Отлично сказано! Вообще, статья в целом замечательная. И ведь действительно, основная проблема многих проектов в том, что заранее требования к структуре данных никто не знает. Точнее говоря, все знают, что скоро они – точно изменяется. Сразу же после того, как процесс пойдет в эксплуатацию. Прямо Зазеркалье какое-то…

    Но вот я сейчас работаю с хранилищем данных Google App Engine, и там есть кроме традиционного объекта Model также объект Expando, к которому можно присоединять в любом месте дополнительные свойства. Я не знаю точно, как они там это технически реализовали, но похоже на какую-то XML-технологию, которая используется для хранения данных. Это придает данным куда большую гибкость! И значительно расширяет возможности по гибкой адаптации процессов к меняющимся требованиям. То есть с одной стороны можно хранить устойчивые данные о реальных объектах и меняющиеся данные виртуальных сущностей.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *