Сьогодні абревіатура АСУ (тобто «автоматизована система управління») якщо і зустрічається, то виключно в поєднанні з ТП (АСУ технологічних процесів). Але так було не завжди. Спочатку була просто АСУ, причому не в якості суми технологій, а як затверджений керівництвом країни курс. Абсолютно точно, що вперше термін АСУ був запропонований академіком В.М. Глушковим для позначення комплексних систем управління, починаючи з рівня підприємства і далі аж до загальнодержавної автоматизованої системи управління економікою країни (ЗДАС). Потім, слідуючи цим курсом, стали з'являтися АСУ «того і сього», в тому числі і ТП, але з часом все вони вимерли, і АСУ ТП залишилися на самоті.
Грандіозні плани створення АСУ, стрункі і бездоганні на словах, ламалися при спробах практичного впровадження. У статті «Історія створення автоматизованих систем управління в нашій країні» ( 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 ( «працівники розумової праці»), не відповідають їх реальним потребам. Це в рівній мірі відноситься і до канальним методам передачі даних (електронна пошта, різного роду системи миттєвого обміну повідомленнями), і до платформного (портали, сайти) і, що особливо цікаво, до спеціалізованих систем управління знаннями. Прогнози, які пророкували бурхливе зростання технологій для роботи зі знаннями, до сих пір не виправдалися.
Макафі створив свою «таблицю Менделєєва», припустивши, що система, необхідна для роботи людини, яка оперує знаннями, повинна володіти шістьма властивостями. Перерахуємо їх.
Можливість пошуку (Search).
Наявність апарату посилань (Link).
Свобода авторства (Authoring).
Підтримка тегів, що забезпечують «фолксономія» (Folksonomy), тобто систему класифікації, створену багатьма людьми.
Можливість розширення (Extension), тобто наявність рекомендацій, заснованих на принципі «якщо вам сподобалося це, то, можливо, буде цікаво наступне».
Повідомлення про зміни сигналами (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 дозволить, використовуючи відносно недорогі методи, реально наблизитися до завдань бізнесу. В даному випадку проглядається очевидна аналогія з популяризацією ідей ЦОД, коли з простих і дешевих серверів і систем зберігання збираються потужні інфраструктури.
Технології для Enterprise Web 2.0Блог (blog) - двостороннє комунікаційний засіб, що дозволяє у вільному стилі розміщувати ідеї, пропозиції і коментарі, в зворотній хронологічній послідовності. Записи ( «блог-пости») можуть містити тексти, зображення, посилання на інші блоги, Web-сторінки і інші джерела. Блоги можуть бути приватними, тобто доступними всередині організації, або публічними. Запис в блозі складається з заголовка, тіла, поля permalink (від permanent link - «довгострокова зв'язок»), дати, коментарів, поля тега і покажчиків Linkback. Поле permalink займає локатор URL, який вказує вхідну крапку, яка приписана записи, після того як запис видалена з першої сторінки в архів. Завдяки тому, що permalink залишається незмінною, вдається виключити ймовірність «ерозії зв'язків». Поле Linkback служить для інформування автора блога про те, що інший автор послався на даний блог. Існує три різновиди таких посилань - Trackback, Pingback і Refback. Поле тегів служить для створення так званого «хмари тегів», яке формується користувачами, відображає їх бачення переваги, допомагає знайти потрібний об'єкт, не використовуючи традиційну ієрархічну таксономії. Перерахованими коштами створюється соціальна спільність - блогосфера.
RSS (Really Simple Syndication) - сімейство форматів, призначених для агрегування контенту, що надходить з блогів і Web-сторінок. Файл в форматі RSS являє собою XML-файл, який інформує користувача про зміни в тих місцях, які представляють для нього інтерес.
Вікі (wiki) - засіб колективної роботи з текстами, що включає в себе власну мову розмітки Wikitext, просту структуру і засоби для навігації, підтримку багато режиму роботи і засоби пошуку.
Колажі (mashups) дозволяють компонувати на одному інформаційному ресурсі дані і сервіси з безлічі інших джерел і ресурсів.
Карр пише, а караван йде http://www.osp.ru/cw/2004/01/72152
Управління знаннями та інформаційні технології http://www.osp.ru/os/2000/10/178275
Управління знаннями та інформаційні технології http://www.osp.ru/os/2000/10/178275
Web 2.0 http://www.osp.ru/os/2005/11/380523
Чому ж спочатку були приречені все багатообіцяючі проекти?Дивно, але ніхто і ніколи до Карра не задавався питанням в такий безапеляційного формі: «А чи варто взагалі вкладати кошти в комп'ютери?
