СУХР нулевых - это СУБД девяностых

Системы управления ходом работ обзаводятся стандартами и становятся коробочными продуктами.

В начале восьмидесятых уже никто не писал собственных операционных систем. И почти прекратили писать собственные компиляторы. А вот собственные СУБД, часто даже не называя их так, писали почти все серьезные программисты. И не потому, что СУБД тогда еще не было на рынке. Просто к заимствованию типового сложного инструмента программистам нужно было привыкнуть.

Сегодня никто не пишет собственных компиляторов. И практически прекратили писать собственные СУБД. Но собственные СУХР, никогда не называя их так, пишут почти все серьезные программисты. И не потому, что СУХР сейчас нет на рынке. Просто программистам нужно привыкнуть к использованию СУХР независимых поставщиков.

Так, тихо и без фанфар, внедряется очередная концепция, по масштабности сравнимая с отделением программ обработки данных от их массивов. На этот раз отделяется выполнение работ от управления их ходом. Мысль весьма нехитра, и сегодня приходит в голову очень многим. И воплощается во всевозможных системах управления ходом работ (СУХР) - как обособленных, так и встроенных в другие приложения. Эх, по-русски как-то сухо, не торжественно и буднично получается. По-английски гораздо звучнее: workflow management и workflow management systems.

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

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

Именно так. Так же, как в 80-х каждая уважающая себя программистская контора ваяла для себя на коленках маленькую proprietary СУБД, в 90-х каждый солидный проектный интегратор разрабатывает какие-то proprietary СУХР. Эх, нет на них стандарта, каким для СУБД стал SQL! Но зачем им стандарт? Это же выгодно - получать заказы на написание большого количества кода!

Правда, фирмы, массово поставляющие собственные proprietary системы автоматизации управления производством, столкнулись с проблемой. Оказывается, производственные процессы переходят границы подразделений фирмы и даже границы собственно фирм. А в соседнем подразделении или фирме часто оказывалась система управления производственным процессом конкурирующего производителя. И не всегда принималось решение оставить для управления объединенным рабочим процессом систему, ранее управлявшую только его частью, - зачастую побеждали конкуренты. Поэтому фирмы быстро сообразили, что их системы автоматизации управления производством должны стыковаться между собой, несмотря на то, что одни фирмы работы называли задачами, другие - процессами, третьи-операциями. И тогда эти фирмы создали Workflow Management Coalition (www.wfmc.org) и начали стандартизировать интерфейсы своих СУХР. Этих интерфейсов, кстати, оказалось не так мало - целых пять. Это означает, что WfMC разрабатывает и поддерживает пять стандартов для СУХР. Никто не знает, не постигнет ли этот набор стандартов та же судьба, что и спецификацию CODASYL для сетевых баз данных, но эксперты уже сейчас поговаривают, что поддержка хода работ с использованием СУХР в 00-х (а как еще сказать про первое десятилетие после года 2000?!) годах займет такое же важное место, как в 90-х заняла поддержка данных с использованием СУБД.

Прогресс идет тут семимильными шагами: в июле этого года WfMC объявила, что стандарты, по которым объединяются СУХР различных производителей, будут включать в себя поддержку Internet. А также криптопротоколы.

Не хватает, на мой взгляд, всего одного, но существеннейшего, момента.

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

Впрочем, я увлекся. Пока же системы управления ходом работ тесно путаются с системами управления ходом документов (вполне логично: управление ходом работ в докомпьютерную эпоху проходило посредством бумажных документов), а архитектуры систем разных производителей отличаются друг от друга не меньше, чем архитектуры систем управления иерархическими базами данных от аналогичных реляционных. И тысячи безвестных изобретателей по всему миру говорят про себя: «Эврика! Пусть у нас в отделе N рабочих мест под управлением М начальников, и на этих рабочих местах выполняется L различных элементарных операций. Тогда...»