Enterprise Web 2.0, или Вторая жизнь АСУ

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

Грандиозные планы создания АСУ, стройные и безукоризненные на словах, ломались при попытках практического внедрения. В статье «История создания автоматизированных систем управления в нашей стране» (www.corpsys.ru/History/CorpSys/Russia.aspx) ситуация, связанная с внедрением АСУ, представлена как анекдот: «К созданию системы были подключены достаточно серьезные силы, и уже в 1968 году был разработан аванпроект, затем эскизный и рабочий проекты системы ‘Кунцево’ на ЭВМ второго поколения ‘Минск-22’. А в 1969 году в точном соответствии с Постановлением Ввоенно-промышленной комиссии был разработан технический проект системы ‘Кунцево’ на ЭВМ ‘Минск-32’ в 150 томах… В том же 1969-м году проект был доведен до уровня внедрения, однако внедрение задерживалось — стандарты, существовавшие в то время, были приспособлены только для ручной обработки информации. Директор Московского радиотехнического завода, где предполагалось внедрять АСУ, говорил: ‘Вы с Глушковым страну по миру пустите. Я вот приду утречком на завод, часик похожу по цехам и мне все ясно, что надо делать на заводе. Нужен мне ваш АСУ!’».

По существу директор был прав, и был он вовсе не ретроградом, как его представляют, а реальным менеджером. Почему же изначально были обречены все многообещающие проекты? Их авторы исходили из идеального, не существовавшего в природе, образа плановой экономики. Каждому мало-мальски знакомому с тем, в каких условиях приходилось тогда работать, было понятно, что надо вести двойную и тройную бухгалтерию, хитрить, заниматься приписками и т.д. Проекты АСУ останутся одним из нематериальных памятников ушедшей эпохи. В условиях рыночной экономики, располагая не то что ‘Минском-32’, а техникой на порядки более мощной, никто и не пытался сделать нечто подобное, прекрасно понимая, что никакого компьютера не хватит для задач подобного масштаба. Верить в возможности планового механизма управления — значит признавать, что можно построить экономику на жестких связях. Жизнь показала, что в чистом виде на жестких связях не может работать даже мобилизационная экономика, что уж говорить о динамической и развивающейся экономической системе. Управлять такой системой можно, лишь разумно воздействуя на слабосвязанные между собой компоненты, предполагая в них способность к автономной деятельности. Что, собственно, и делал директор Московского радиотехнического.

Но все-таки АСУ нужны. Бизнес растет, и системы управления должны адекватно развиваться. Сегодня недостаточно видеть происходящее глазами одного человека — требуется системный подход к управлению, учитывающий реальную сложность управляемых систем. Отсюда и нынешний колоссальный интерес к Enterprise Web 2.0.

Автоматизация бизнес-процессов и слабая связанность

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

Системы управления бизнесом по традиции никогда не ставят в один ряд с технологическими системами управления. Это происходит, скорее всего, потому, что их создают специалисты, обладающие совершенно иной ментальностью, обычно не имеющие достаточной кибернетической подготовки и знаний по теории автоматического регулирования. Однако помимо их воли, общие тенденции, характерные для развития систем автоматизации, распространяются и на системы управления бизнесом. Просто в силу великого множества объектов автоматизации с отличительными свойствами и требованиями в этой сфере разнообразие возможных решений гораздо шире, и пока не существует общей теории автоматического управления, подобной той, что есть в технике. В отсутствии необходимой теории автоматизация бизнеса развивается методом проб и ошибок — периодически какая-то очередная новация входит в моду, на нее делают ставку, а потом она как-то незаметно исчезает. В жизни нет одного общего решения. В зависимости от сложности объекта управления в одних случаях для оптимизации управления достаточно того, что называют «бизнес-анализом в реальном времени», то есть более удобного способа информирования о текущих процессах, а в других потребуется полноценная система управления знаниями. Отдельные составляющие существуют, но для комплексной автоматизации бизнеса до сих пор не хватало суммирующей технологий, отсюда и частные решения типа ERP, CRM и т.п.

Комплексные системы в технологических процессах возможны потому, что технические системы проще. В них не предполагается наличие такого качества, как гибкость, возможность изменений с целью адаптации к новым условиям; грубо говоря, в них для связи между источником данных и приемником достаточно пары проводов — связь между компонентами сильная. В бизнес-системах такой детерминированности быть не может, поэтому в данном случае для сборки компонентов в систему необходима слабая связанность (loosely coupling). Идею слабой связанности как метода создания сложных систем предложил специалист по системной организации и организационному развитию Карл Вейк. Он опубликовал в 1982 году статью «Управление изменениями в среде слабосвязанных элементов», где показал преимущества и слабости замены сильных связей слабыми.

XML и слабая связанность

Практическая возможность внедрения идей о слабой связанности Вейка в информационные системы открылась примерно десять лет назад, когда был предложен язык разметки XML. Собственно, в этом и состоит его основное достоинство: материализация слабой связанности основывается на том, что данные не передаются из пункта А в пункт Б, а интерпретируются. Интерпретация возможна потому, что в дополнение к собственно данным сообщение на XML несет в себе сведения о контексте этих данных, и теперь их можно интерпретировать не по умолчанию, как это было прежде; это открывает немыслимую ранее возможность для перехода к слабой связанности системных компонентов, то есть интеграции отдельных составляющих в единую систему. Решающую роль в создании XML сыграл консорциум World Wide Web Consortium и исследователи из Sun Microsystems Йон Борсак и Тим Брей. Им удалось свести более чем 500-страничное описание SGML до 26-страничного описания XML, показав, что последний мало в чем уступает по функциональности.

Следующий вполне естественный шаг был сделан в 2000 году, когда рабочая группа из W3C предложила стандарт Simple Object Access Protocol (SOAP), служащий для замены традиционных вызовов удаленных процедур (RPC) сервисами, которые обеспечивают слабую связанность. Идея состояла в том, чтобы преобразовать параметры и данные вызова в XML, а затем посредством сервиса передать их и распаковать на месте. Отсюда, собственно, и пошли Web-сервисы. В 2001 году W3C опубликовал первую версию языка описания Web-сервисов WSDL (Web Service Definition Language), а затем усилиями UDDI.org был создан реестр Universal Description, Discovery and Integration (UDDI) для доступа к сервисам, созданным сторонними организациями. Однако пока эта технология практически не используется — реестры используемых сервисов и без того сложны, а потому составляются вручную. Так сложилось первое поколение сервис-ориентированных архитектур; его-то, собственно, и стали называть SOA.

На протяжении последних трех-пяти лет дискуссия, связанная с SOA, сосредотачивалась на технологических аспектах. Особенно сильный импульс сервис-ориентированная архитектура получила, когда компания Sonic, ныне входящая в Progress Software, предложила идею «сервисной шины предприятия» (Enterprise Service Bus, ESB). С ее помощью удается уподобить реализацию сервис-ориентированной архитектуры шинным конфигурациям, хорошо известным в аппаратных системах. Но техническое решение не самоцель, и сегодня фокус внимания сместился на интеграцию с управлением бизнес-процессами (Business Process Management, BPM), то есть на создание автоматизированных систем управления бизнесом.

Как бы ни были привлекательны методы, основанные на стеке SOAP, WSDL и UDDI, их внедрение чрезвычайно сложно и дорого. Даже на минимальном уровне (по классификации корпорации IBM этот уровень называется foundational level) стоимость проекта измеряется сотнями тысяч или миллионами долларов, а также предполагает участие в проекте специалистов высокой специализации. Нетрудно представить себе, во что обойдется полноценная реализация на старших уровнях. Не случайно, например, из 7 тыс. компаний, так или иначе использующих технологии SOA от IBM, только каждая десятая вышла на второй-червертый уровни освоения SOA. И еще одно обстоятельство. Автоматизация «связкой SOA-BMP» реализует один из возможных подходов, а именно, со стороны бизнес-процессов, который применим только в больших организациях с хорошо детерминированными процессами. Этот подход далеко не единственный, и ему есть альтернатива. Можно, к примеру, начинать автоматизацию не с бизнес-процессов, а с деятельности людей.

Enterprise 2.0 и парадокс продуктивности

Системный подход к автоматизации с точки зрения оптимизации управленческой деятельности персонала нашел свое отражение сначала в концепции Enterprise 2.0, а потом мигрировал в Enterprise Web 2.0. Эта концепция пребывает сейчас на пике внимания, и нынешний 2008 год рассматривается как рубежный, поскольку заимствованные из Web 2.0 технологии открывают реальную возможность реализации перехода от автоматизации отдельных бизнес-процессов к автоматизации бизнеса в целом, причем не с процессной, а с человеческой точки зрения.

Технологии, поддерживающие Enterprise Web 2.0, важны и интересны. Однако давайте сначала обсудим экономическую сторону дела, потому что принятие этой концепции позволит, наконец, больше не задаваться вопросом, а зачем вообще нужны информационные технологии, оправдывают ли они себя и тому подобное. Вспомните бурную реакцию на публикации Николаса Карра, поставившего под сомнение целесообразность применения ИТ — концепция Enterprise Web 2.0 их просто снимает.

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

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

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

Однако никто не учитывает тот факт, что информация как предмет ИТ не существует отдельно от людей. Собственно технологии имеют дело с данными, и только человек способен превратить данные в информацию. До тех пор пока мы будем рассматривать компьютеры как инструмент для обработки данных, ни о какой оценке эффективности речи быть не может — не данные, а информация является предметом потребления. Компьютеры и коммуникационные устройства в корпоративных условиях есть ни что иное, как инструмент, повышающий эффективность управления, осуществляемого людьми. Следовательно, стремление искать оценку эффективности ИТ, как инструмента, отдельно от тех, кто его использует, является грубой методологической ошибкой, и здесь никакого парадокса не существует. Не может быть эффектности отдельно взятого молотка. Такое, пожалуй, тривиальное объяснение ложной, — да-да, именно ложной, — природы парадокса продуктивности стало возможным теперь, когда ИТ достигли определенного уровня развития. Концепция Enterprise Web 2.0 ставит точку в этом споре: без автоматизации бизнес не может существовать, как невозможно без встроенных систем построить любое сложное устройство. Сила Enterprise Web 2.0 в том, что с помощью этой концепции удается восстановить естественное отношение к ИТ.

Происхождение Enterprise 2.0

В 2006 году Эндрю Макафи, профессор Слоановской школы бизнеса Массачусетского технологического института, предложил концепцию, названную им Enterprise 2.0.

Макафи убедительно показал, что все традиционные способы информирования категории сотрудников, которых по-английски называют knowledge worker («работники умственного труда»), не соответствуют их реальным потребностям. Это в равной степени относится и к канальным методам передачи данных (электронная почта, разного рода системы мгновенного обмена сообщениями), и к платформным (порталы, сайты) и, что особенно любопытно, к специализированным системам управления знаниями. Прогнозы, предрекавшие бурный рост технологий для работы со знаниями, до сих пор не оправдались.

Макафи создал свою «таблицу Менделеева», предположив, что система, необходимая для работы человека, оперирующего знаниями, должна обладать шестью свойствами. Перечислим их.

1. Возможность поиска (Search).
2. Наличие аппарата ссылок (Link).
3. Свобода авторства (Authoring).
4. Поддержка тегов, обеспечивающих «фолксономию» (Folksonomy), то есть систему классификации, созданную многими людьми.
5. Возможность расширения (Extension), то есть наличие рекомендаций, основанных на принципе «если вам понравилось это, то, возможно, будет интересно следующее».
6. Уведомления об изменениях сигналами (Signal), например, по технологии RSS.

По первым буквам получается название «Принципы SLATES». оказывается, что реализация этих принципов не представляет собой чего-то невероятно сложного и вполне достаточно тех технологий, которые принято называть Web 2.0, хотя в ряде случаев требуется специализированный инструментарий для работы со знаниями. Известный аналитик Дайон Хинчклифф предложил свою, близкую по смыслу, но несколько расширенную систему классификации с мнемоникой FLATNESSES (Freeform, Links, Authorship, Tagging, Network Oriented, Extensions, Search, Social, Emergence, Signals).

Если посмотреть на концепцию Enterprise Web 2.0 с системной точки зрения, то самое важное в ней заключается в возможности организации желаемой слабой связанности, но не на уровне обмена сообщениями между аппаратно-программными компонентами, а между людьми. Средства Enterprise Web 2.0 позволяют связать людей в единую систему и снабдить их необходимыми технологиями для коммуникации.

Еще одна сильная сторона технологий Web 2.0 — в их массовости (рис. 1). Освоение технологий Web 2.0 происходит намного естественнее и органичнее, чем SOA на основе стека протоколов SOAP/WSDL/UDDI. Кроме того, при создании информационных систем на принципах Enterprise Web 2.0 не будет проблем с подготовкой и поиском специалистов, что имеет место в случае классической схемы SOA.

Чтобы оценить значение технологий Web 2.0 для предприятий, аналитики из Economist Intelligence Unit, провели в 2007 году опрос 500 руководителей бизнес-подразделений крупных корпораций. Оказалось, серьезный бизнес уверен — Web 2.0 идет на предприятия (рис. 2). Если учесть, что на момент проведения опроса концепции Web 2.0 было всего два года, то приведенные данные поражают воображение. Можно быть уверенным, что сегодня показатели еще выше.

***

Если обобщить мнения аналитиков, высказанные по поводу перспектив Enterprise Web 2.0, то можно сделать следующий вывод. ИТ-руководителям и другим лицам, ответственным за принятие решений, связанных с автоматизацией бизнеса, необходимо проделать большую работу, связанную с переосмыслением приоритетов. Они привыкли к тому, что главными всегда были традиционные «тяжелые» решения, а инструменты Web 2.0 рассматривали как нечто второстепенное. Ориентация на Enterprise Web 2.0 позволит, используя относительно недорогие методы, реально приблизиться к задачам бизнеса. В данном случае просматривается очевидная аналогия с популяризацией идей ЦОД, когда из простых и дешевых серверов и систем хранения собираются мощные инфраструктуры.