Неструктурированный контент и неструктурированные процессы

Обычно термин «неструктурированный» применяется только к контенту, под которым подразумеваются текстовые файлы, презентации, таблицы (кстати, очень хорошо структурированные внутри), чертежи, фотографии, аудио, видео и другая информация, не укладывающаяся в базы данных. Конечно, для организации хранения и учета всего этого хозяйства все-таки приходится такие неструктурированные данные снабдить структурированными метаданными и использовать СУБД, но внутрь самого контента учетные системы обычно не лезут. Можно сказать, что для ECM-системы (Enterprise Content Management) собственно контент остается «вещью в себе», если употребить это философское понятие несколько всуе.

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

ECM-системы заняли свое место в бизнесе, взяв на себя функции управления неструктурированной информацией, но предоставив человеку все прерогативы работы с ней, ее модификации и практического использования. Это, пожалуй, разумное разделение полномочий между машиной и человеком. Согласно тому же ИСО 15489, документ должен обладать следующими основными свойствами: быть аутентичным, достоверным, целостным и пригодным для использования. Если заботу об аутентичности и целостности еще можно возложить на информационную систему, то уж за достоверность и пригодность к использованию — т.е. за содержательную часть — отвечает человек.

Структурировать процессы

Следом за наведением порядка в хранении данных появилась вполне логичная мысль, что таким же образом можно управлять и процессами их обработки, если все рабочие процедуры разложить на отдельные шаги и описать эти элементарные операции, что опять укладывается в некую структурированную модель. Это направление тоже активно развивалось — от первых workflow-систем до современных BPM во всем их методологическом разнообразии.

За пятьдесят лет айтишники настолько приучили пользователей мыслить категориями баз данных, что люди уже и не могут по-другому. Кажется, в голове у всех реляционные таблицы. Но ведь люди не роботы (по крайней мере пока).

Стакан воды — это не всегда просто

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

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

С бизнес-процессами ситуация похожая. Исходная посылка обычно очень проста — обслужить клиента, например. Но дьявол, как всегда, в деталях. Никто заранее не в состоянии предвидеть все возможные сценарии развития событий. И что в результате? Вспомните, сколько раз в роли клиента вы слышали фразу: «Наша система этого не позволяет»! Например, в ресторане, в отеле, в магазине, в салоне связи. Какая-нибудь сущая ерунда, хотя бы просьба дать стакан воды, может вызвать полный ступор — вам могут в ответ принести кипятка со льдом (сам видел!). Потому что лед у них есть, чай по кассе пробить они могут, а налить простой воды они не в сотоянии.

Подобные несуразности являются прямым следствием жестко структурированного подхода к организации бизнес-процессов и данных. Конечно, эпизод со стаканом воды — случай почти анекдотический, но он вполне адекватно отражает суть проблемы. А ведь есть и более серьезные ситуации, в которых ограничения модели ведут к прямым убыткам. Чаще всего это выражается в отказе в обслуживании клиента, т.е. в упущенной выгоде (о чем менеджмент в общем-то и не знает) или в эскалации проблемы, которая не стоит и выеденного яйца, на самый верхний уровень, когда какой-нибудь высокопоставленный руководитель берет дело «под личный контроль». Собственно проблема редко бывает экстраординарной, обычно этот снежный ком лепится просто из нестыковок и противоречий в процессах на более нижних уровнях, и нужно вмешательство начальства, чтобы разрубить очередной гордиев узел.

Кейс-менеджмент: когда есть цель, но нет маршрута

А что если идею неструктурированных данных применить к бизнес-процессам? По всей видимости, мы получим то, что называют кейс-менеджментом, когда у пользователей появляется возможность более гибко реагировать на изменения внешней среды, добавлять свои данные и документы, подключать к работе коллег — договариваться, как решать проблему, а не ссылаться на невозможность что-либо сделать.

Кейс — это сложный информационный объект, который объединяет данные, документы, людей и процессы в одно целое. Максим Смирнов, главный архитектор «Вымпелкома», говорит, что кейс-менеджмент можно рассматривать как архитектуру. В первую очередь как бизнес-архитектуру. То есть вы не делите своих людей на тех, кто только придумывает бизнес-процессы, и тех, кто их исполняет. Архитектор бизнес-процессов должен участвовать в процессе, который он же и спроектировал, и, например, обрабатывать все исключения, в нем возникающие.

Все ключевые вендоры из «большой тройки» ECM — OpenText, FileNet и EMC — уже двинулись в сторону кейс-менеджмента, дополнив свои пакеты продуктами для управления кейсами.

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

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

Кейс — как это сказать по-русски?

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

Большинству потенциальных заказчиков, для которых кейс-менеджмент может быть полезен, само слово вообще ничего не говорит, и это большая проблема для выстраивания маркетинговых коммуникаций. Мы имеем некий ментальный барьер, преодолеть который будет сложно. Мне кажется, по этой причине торнадо на рынке кейс-менеджмента ждать не следует. Разработчикам придется осваивать отдельные ниши, приспосабливая кейс-менеджмент к каждой предметной области.

Например, компания DashBoard, стартап из Сколкова, применяет эту методологию для описания деятельности коллегиальных органов управления, где люди привыкли работать с вопросами. Для члена правления или совета директоров кейс — это вопрос. «Мы автоматизируем не документооборот, а вопросооборот», — говорит Владимир Бернштейн, основатель DashBoard. Ветеран рынка СЭД компания «ИнтерТраст» также смотрит в сторону кейс-менеджмента, чтобы реализовать более целостный подход к автоматизации бизнес-задач; новая версия CompanyMedia включает такую функциональность.

При помощи кейс-менеджмента мы уходим от фрагментарности восприятия, которая присуща концепции обычного документооборота, где каждый документ воспринимается как отдельная сущность, хотя переписка по какому-либо вопросу может длиться годами. Но и клиентов, и руководителей организаций интересует результат, а не процесс. Кейс-менеджмент ориентирован именно на результат, у кейса всегда есть два состояния: он либо открыт и, значит, работа еще не закончена, либо закрыт — то есть вопрос решен. Тогда и систему контроля можно построить по другому принципу, взяв за показатель действительно сделанные дела, а не написанные ответы на входящие документы.

Раньше программистам платили за строки кода. Сейчас так уже никто не делает. Код генерируется автоматически, а от программиста ждут работающей системы. Так почему же работу чиновников нужно измерять числом написанных документов?

В заключение

Определенно лед тронулся. Бизнес признал важность неструктурированной информации. Для того чтобы это случилось на уровне данных, чтобы ECM-системы стали обязательной частью бизнес-ландшафта, потребовалось лет десять. Евангелисты всех компаний без устали повторяли мантру, что «объем неструктурированного контента составляет 80% всей бизнес-информации», что темпы роста очень высоки и нас накроет информационное цунами. Бизнес услышал, прекрасно.

Следующий шаг — принять идею неструктурированной информации на уровне процессов. Одним из ее воплощений можно считать концепцию Adaptive Case Management, ACM. Динамика пока положительная, разработчики выпускают на рынок решения в этой парадигме. И все еще есть риск, что кейс-менеджмент окажется маркетинговым пузырем, такие опасения высказывают эксперты. Вот что говорит Максим Смирнов из «Вымпелкома»: «Мне очень не хотелось бы увидеть в развитии кейс-менджмента традиционный Gartner‘овский сценарий. Когда сначала появляется некоторое новое трехбуквенное сокращение. Затем наступает пик завышенных ожиданий. Одновременно мегавендоры начинают скупать решения данного класса и выводить их в отлаженную систему продаж. После продают эту технологию всем подряд, не задумываясь о её применимости, что неминуемо приводит к всеобщему разочарованию. И потом единицы компаний, вдумчиво подошедшие к внедрению технологий, выводят её у себя на плато продуктивности».

Чтобы кейс-менеджмент реально заработал, нужно больше практических примеров для разных бизнесов и разных отраслей, чтобы заказчики увидели, в чем суть и польза этой технологии. Надеемся, так оно и будет.