Workflow в Confluence

Продолжаю развлекаться с продуктами Atlassian, а именно с Confluence и плагинами к нему. Очень простой в установке и использовании плагин Ad hoc workflow демонстрирует нам очередной прагматичный подход к организации рабочих процессов.

Процессы создаются без рисования развесистых картинок в стиле BPMN простым описанием состояний, переходов и правил оповещения. Язык описания workflow(не графический, а нормальный, человеческий) понятен будет школьнику младших классов. Кстати, такие продукты как Confluence не плохо бы включить в школьную программу.

Подробнее про workflow в Confluence см. видео

Интранет и кейс-менеджмент

Существуют различные мнения о востребованности тех или иных социальных приложений в интранет. Кто-то отдает предпочтение блогам и форумам, кто-то вики. Одни аналитики концентрируются на корпоративном поиске, другие на синдикации контента, третьи на мессенджерах. Некоторые, радикально настроенные разработчики, признавая перспективы Web 2.0 для предприятий, скептически относятся к идее использования социального ПО внутри компаний. Я настроен в этой заметке позиционировать решения класса adaptive case management как основное интранет приложение. Приложение, которое позволяет эффективно решать задачи документооборота, управления корпоративным контентом, сотрудничества, управления проектами и процессами. Читать далее Интранет и кейс-менеджмент

Email наносит ответный удар. По интранет-порталам

Удивительно своевременное сообщение на 1b LiveBusiness Люди, по крайней мере, офисные служащие, консервативны. И они любят электронную почту. Неважно какую. Это может быть почтовый ящик в Интернет, доступный через броузер, толстый клиент или же безумно тяжелое и кривое приложения для доступа к корпоративной электронной почте. Люди все равно его любят. Можно часами рассказывать о преимуществах распространения информации по принципу «публикация-подписка» и клеймить менталитет рассылки. Стивен Теллин сделал это 15 лет назад. И как, подействовало? Да абсолютно не подействовало. Чем в пустую убеждать человека в эффективности блогов, лучше завести список рассылки. 90% обычных пользователей(не айтишников) предпочтут добавить в копию письма адрес списка рассылки, а не опубликовать сообщение в блог. Столь же неэффективно побуждать людей делиться информацией. Но видимо это свойство человеческой натуры: держать на локальном диске или в персональном почтовом ящике копии электронных документов. Пусть это будут неактуальные, десять раз перепутанные копии. Главное чтоб у себя, в компьютере, да еще и на флешке на всякий случай и в бумажной копии, чтоб почитать перед сном. Хотите видеть, как работают ваши подчиненные – заведите групповой почтовый ящик и забудьте про сетевые каталоги, версионные хранилища и порталы.

А еще люди любят приложения. Приложения для персональных компьютеров, мобильных телефонов и прочих гаджетов. Меня всегда удивляло как можно «продать» proprietary клиента электронной почты для телефона, тем более что на большинстве современных моделей уже предустановлен универсальный IMAP/SMTP клиент. Оказывается можно. Кривого, ущербного, непрерывно пожирающего трафик и деньги… Можно. Без проблем.

Одним словом, почтовый клиент – это приложения с которым необходимо считаться. Если взять простенькую программу для чтения электронной почты, добавить к ней механизм меток(тегов), группировку сообщений, общие папки, календарь, адресную книгу и, для груманов, RSS-reader, то про корпоративные интранет-порталы никто и не вспомнит.

Почему Интранет должен стать 2.0

21 марта 2000 года обвалился индекс NASDAQ. Накануне он достиг своего максимума 5048 пунктов, тем самым удвоив показатели всего годичной давности, а потом обвалился. Сотни интернет компаний обанкротились. Но некоторые, все же, выжили. ИТ-сообществу потребовалось несколько лет, чтоб осознать, в чем секрет уцелевших компаний. Внятный ответ на этот вопрос был дан Тимом О’Рейлли  в 2005 году и назывался он Web 2.0.

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

Enterprise 2.0 для чайников

Умение раскрыть сложное парой простых и понятных фраз, безусловно, сродни таланту. Не обладая в достаточной мере, указанной добродетелью, я все же рискну обнародовать свое видение идеи Enterprise 2.0 в формате, который принято называть «на пальцах».

Итак, как известно из школьного курса информатики компьютерные информационные системы включают в себя оборудование, данные и программное обеспечение. Слова, сопровождаемые индексом 1.0 – это, как правило, о данных. Web 1.0 Изменил наше представление об информационном ресурсе. До появления всемирной паутины информация была рассредоточена по закрытым системам и доступна только ограниченным группам пользователей этих систем. Унифицировав формат данных и протокол доступа, Web 1.0 сделал информационное пространство единым (самое интересное, что это случилось в физически и организационно распределенной сети). Идея Web 2.0 сделать то же самое с поведением информационных систем, т.е. с программным обеспечением. Свободное сочетание сервисов и композитные приложения в основе идей сопровождаемых цифрой 2.0.

А что же в Enterprise? Говоря честно, в корпоративных информационных системах дело обстоит существенно хуже. Концепция Стивена Теллина, известная миру под названием Intranet (Web 1.0 для enterprise) уже лет пятнадцать не находит должного понимания в корпоративной среде (см. «Интранет и адаптивные инновации»). Большинство компаний успокоились, прицепив лейбл Intranet к внутреннему web-сайту, что естественно intranet-ом никак не является. О переходе в состояние 2.0 остается только мечтать.

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

Речь впрочем, идет не только об интеграции приложений, но и об интеграции данных. Пока система одна, серьезных проблем с семантикой данных обычно не возникает. Логическая структура данных проста и целостна. Пользователь без труда справляется с одной системой. Но, вот возникает вторая система, третья… они начинают обмениваться информацией структурированной в соответствии с разными принципами и подходами, а сквозные бизнес-процессы запутывают все окончательно. На ранних этапах процесса пользователи переносят данные между системами в стиле copy/paste. Затем им это надоедает и начинается автоматизация интеграции приложений и данных. Терабайты семантически несогласованной, структурированной в соответствии с разными принципами информации, величаво переливаются между серверами.

Вспомните web. Подход к информации там прямо противоположный. Данные создаются и развиваются в рамках собственного информационного ресурса и на другие ресурсы не переносятся. Информационные ресурсы повязаны гиперссылками. Копировать чужие данные на свой ресурс не то чтоб нельзя, но просто как-то не принято. Да и зачем, можно просто на них сослаться. Структура данных, доступность, актуальность и целостность – головная боль соответствующего web-сайта. Компаниям, которым в какой-то мере удалось приблизиться к этому можно давать сертификат соответствия Intranet. Для Enterprise 2.0 понадобится чуть больше, а именно объединение классических клиент-серверных приложений и средств коллективной работы для поддержки слабоструктурированных бизнес-процессов, присущих нескончаемой череде перемен…

28 апреля 2009

Семантическая сеть предприятия

Последнее время мне все чаще хочется каких-то странных вещей. Хочется дождя, хочется снега, хочется новую  информационную систему. Систему похожую, то ли на twitter, то ли на wiki, одним словом хочется следующего:

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

Пример варианта использования такой системы:
Руководитель проекта создает новый проект в корпоративной системе управления проектами. Для назначения ролей участникам рабочей группы проектная система вызывает соответствующий программный интерфейс Links и предоставляет список, ну например архитекторов. Руководитель проекта выбирает архитектора, что приводит в системе Links к образованию семантической связи между проектом и конкретным сотрудником. Естественно, система работы с персоналом может запросить у Links список проектов, в которых участвует конкретный сотрудник. В общем, механизм прямых и обратных ссылок из MediaWiki, только вынесенный в отдельное хранилище и независимый от остальных систем.

Может кому-нибудь доводилось видеть что-то подобное? Поделитесь, пожалуйста, знанием

MindTouch 2010

Не могу обойти своим внимание появление  MindTouch 2010 Напомню, что MindTouch наиболее концептуально-целостное решение из класса Enterprise 2.0, выросшее из Mediawiki, но лишенное многих недостатков этого продукта.

Эти ребята находятся в определенной оппозиции к другим вендорам платформ этого класса. Тем временем, как другие проповедуют повсеместное использование внутри компаний социального ПО, они говорят о том, что корпорациям не нужны блоги, вики и пр. Корпорациям нужны бизнес-приложения. Но архитектура этих бизнес-приложений должна соответствовать принципам Enterprise 2.0. (вот ведь фантазеры заморские)

Open source версия доступна только для Linux-ов. Коммерческая и для Windows Server. Надеюсь, что установка десятки окажется такой же простой как и установка предыдущей версии. Впечатлениями обязательно поделюсь в ближайшее время.

Adaptive Case Management + Semantic Web

Развитие идей предыдущего сообщения другими словами.

Традиционный кейс менеджмент – это практика, предполагающая сбор в единой папке всех документов, относящихся к определенному случаю. Помните, были такие картонные папки с надпись «Дело №…». Adaptive case management позволяет нам ассоциировать с некоторым конкретным случаем (делом) не только документы, но и людей, процессы, сообщения, любые информационные ресурсы. Т.к. мы люди умные, то не будем физически подшивать эти ресурсы в папку, т.е. засовывать их внутрь, а соберем в кейсе гиперссылки на необходимые нам ресурсы: контент, карточку сотрудника, страницу бизнес-события и экземпляра бизнес-процесса.

Однако, простые гиперссылки не обладают семантикой. Т.е. ссылка на человека не будет отличаться от ссылки на документ. Это плохо. Поэтому мы будем использовать семантические ссылки, т.е. ссылки помеченные определенной меткой(тэгом). Например, ссылка на исполнителя кейса будет иметь тэг «case worker», а ссылка на инициирующее создание кейса событие будет иметь тэг «trigger». Естественно, нам не помешает механизм обратных ссылок, присутствующий в блогах, wiki и других социальных инструментах.

Это все! Очень простая и вполне законченная логическая архитектура ACM построена

Advanced case management от IBM

Сегодня заскочил на мероприятие IBM в Москве, на котором впервые были произнесены слова про advanced case management. К сожалению, не смог остаться до конца, но суть, думаю, уловил.

Как и ожидалось, рассказ был про FileNet Это IBM-овское решение, позиционируется как ECM. На мой вопрос, а является ли оно Enterprise 2.0 ответ был положительным. У каждого документа есть постоянная гиперссылка, к документу можно прицеплять метки(тэги), устаивать обсуждения и т.д. Живьем не видел, но посмотрел скриншоты, на которых обсуждение из чата сохраняется в кейсе. ACM выстраивается поверх ECM (а я ведь говорил, что эти люди съедят BPMS с потрохами и не подавятся). Основная концепция сформулирована достаточно четко: case объединяет все – документы(контент), процессы, люди, события, т.е. любые ресурсы. Для кейса можно задать набор ролей и назначить им определенные задачи, увязанные в последовательность шагов. Все это рисуется простой диаграммкой с дорожками.

В отдельном инструменте можно нарисовать более сложный граф переходов. Кстати, интересный момент. Для такого инструмента определены две роли: бизнес и ИТ. Человек с ролью «бизнес» в каждом узле пишет какие-либо слова, типа требования. Человек с ролью «ИТ» из этих слов делает делает запросы, формы и т.д. Такая вот простенькая модель взаимодействия.

Что насторожило. Решение старое, судя по всему тяжелое и разбираться в нем можно много лет. Лицензируется по пользователям. В общем, если бы я был разработчиком, то инвестироваться в изучение этой платформы не стал бы.

Насколько я понял докладчика, IBM собирается в этом году раскручивать тему ACM. Посмотрим…

Update: Нашел демонстрашку  FileNet P8

Назад в будущее

Я с большим интересом слежу за блогом, который ведет Keith Swenson и сегодня с удовольствием обнаружил в нем сообщение 15 Social Requirements for ACM Насколько мне известно, это первый список конкретных требований к социальной системе управления, по крайней мере, к системе класса adaptive case management. Мне нравится этот перечень, но для себя я бы скомпоновал требования немного иначе:

  1. Case – это ресурс в корпоративной информационной сети, обладающий уникальным неизменным идентификатором (URL) и доступный посредством простых операций CRUD (впрочем, насчет D[elete] я бы еще подумал). При описании требований к системе, я бы объединил понятия case и case folder, хотя эти понятия и используются для обозначения разных сущностей.
  2. Главным требованиям к структуре case folder(case) является freeform. Я бы ограничился статусом, коллекцией вложенных ссылок на бизнес-объекты и историей изменений. Впрочем, статусы можно реализовать набором меток(тэгов). Возможно, это предложение сейчас слишком инновационное, но по мере роста популярности Semantic Web, статус кейса станет семантической ссылкой на один из допустимых статусов.
  3. Безусловно, необходимы механизмы уведомления об изменениях кейса в виде RSS/Atom/e-mail, допускающие свободную подписку в соответствии с правами доступа.
  4. Связывание кейсов между собой производится на основе гиперссылок и меток(тегов). Причем, основное внимание надо уделить на использование меток для классификации кейсов. Некоторые метки могут обозначать использование в данном кейсе типовых сценариев и задач. Более того, когда Case Worker принимает решение о необходимости реализации в рамках отработки кейса той или иной активности, соответствующая метка типа активности должна добавляться к кейсу автоматически.
  5. Безусловно, отношения между кейсами и людьми – это самое главное. В этом Кейт абсолютно прав. Я считаю, что ассоциация кейса с сотрудником должна быть той самой задачей из check list. Другими словами, сотрудник привлекается к кейсу не просто так, а для того чтоб внести свой, вполне конкретный вклад в его решение, реализовав одну из задач кейса. Это не запрещает консультироваться с экспертами и взаимодействовать коллегами по поводу кейса. Но главный акцент остается на конкретном вкладе эксперта в достижение общей цели.

Возможно, после повторного прочтения сообщения Кейта Свенсона мне придет на ум что-то еще. Однако и первое прочтение меня достаточно впечатлило.