Dynamic business application

Способна ли ваша компания запускать новые продукты быстрее, чем ваше ИТ разрабатывает новые бизнес-приложения? Обычно ответ является отрицательным. Время вывода на рынок нового продукта или услуги не может быть меньше, чем время на разработку или на приобретение и развертывание нового приложения. Длинные циклы внесения изменений в ИТ системы являются существенным тормозом в стремлении предприятий гибко реагировать на меняющиеся потребности рынка.
Причина проблемы кроется в том, что используемые сегодня пакеты бизнес-приложений создавались для реализации типовых стандартных сценариев, создавались на основе требований сформулированных для текущей ситуации и не были предназначены для изменений. Дальше читаем Forrester The Dynamic Business Applications Imperative если найдем в бесплатном доступе

Что роднит BPM и кейс менеджмент

Брюс Сильвер пишет о том, что case managment нацелен на решение тех же управленческих проблем что и BPM:

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

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

Case Management for Knowledge Work

Вебинар Workflow management coalition, состоявшийся 3 марта необходимо посмотреть всем, кто интересуется данной темой. Доступны как слайды, так запись вебинара case management for knowledge work

Несколько идей тезисно:

Knowledge worker – это тот, кто лучше всех в организации разбирается в определенной задаче. (моя вольная интерпретация Друкера)

BPM базируется на следующих допущениях: ваш процесс предсказуем и четко определен; его можно автоматизировать; увеличение “объемов производства” позволяет вернуть вложенные средства. О последнем необходимом условии забывают чаще всего. Интересно, сумел ли Адам Смит продать все булавки, произведенные после эксперимента с разделением труда?

Work-around – старейший киллер производительности труда

Accenture 2009: Companies need to treat innovation with the same discipline as other functions. The most successful companies are generating profitable revenue by managing innovation as a business process.

Enterprise Developer Conference

Пока в Интернет появился всего один отчет о прошедшей накануне Enterprise Developer Conference, а именно размышления Андрея Колесова. Выскажу свои соображения о прошедшем мероприятии. Вернее, не столько о мероприятии сколько, о затронутой теме: разработка ПО внутренними силами предприятия. О самой конференции еще наверняка напишут.

Итак, кто же все эти люди, разрабатывающие ПО, но не являющиеся сотрудниками ни Microsoft ни IBM, ни даже компаний системных интеграторов? Зачем Microsoft собрал их на эту встречу и чему хотел научить? В общем-то, большинство докладов было посвящено именно разработке. Организаторы честно запускали Visual Studio, создавали контролы и редактировали фрагменты кода. Вот только радости участникам конференции, на мой взгляд, это практически не доставляло. Среди гостей мне удалось распознать несколько знакомых ИТ-менеджеров, преподавателей ВУЗов, учебных центров и нескольких журналистов. Вряд ли они так уж часто открывают интегрированные среды разработки. Наверное, потому и не было особой радости на их лицах. Конечно, были и настоящие разработчики, но большинства они не составили. Вспомните «Волшебный котел» Эрика С. Реймонда утверждающего, что до 95% программного кода пишется вовсе не на продажу, а для собственных нужд. Может быть это время ушло(«Волшебный котел» написан в 1999г.) и компании полностью передали разработку ПО на аутсорс? Что-то я сомневаюсь. Скорее внутренние разработчики банков, страховых компаний и прочих предприятий просто не ожидали, что для них может быть организована специальная конференция и потому не пришли. В лучшем случае ограничились просмотром трансляции конференции в Интернет. Потому и тема собственной разработки так и осталась не раскрытой.

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

Впрочем, начало разговора положено. Будем ждать продолжения.

Direct Graph Markup Language

Был вчера на конференции Enterprise developer conference. О конференции чуть позже, сначала про DGML.

Microsoft встроил в Visual Studio функционал построения графических моделей из проектных репозиториев, разработав попутно для этого XML-based язык описания ориентированных графов. Какие объекты использовать в качество узлов графа(сборки, неймспейсы или классы) решать архитектору. Думаю, без больших проблем можно использовать и другие объекты. Или же просто нарисовать такую картинку как эта

В общем-то, идея вполне симпатичная, тем более что GraphVis уже давно не развивается. Посмотрим насколько это новшество приживется в практической деятельности разработчиков

Case management и модели процессов

Продолжаем читать статью Хенка де Мана «Case Management: A Review of Modeling Approaches»

Вчера мы столкнулись с рядом особенностей управления кейсами (CM), ограничивающими возможности по его моделированию при помощи BPMN, т.е. в виде детерминированной последовательности работ, а именно:

  • CM предполагает постоянный сбор информации относительно конкретного рассматриваемого случая. Данная информация существенно влияет на то, как мы обрабатываем кейс.
  • Кейс обладает набором состояний, которые управляются событиями (event-driven), как правило, событиями внешними.
  • Значительное влияние на порядок обработки кейса в CM оказывает конкретный эксперт, формирующий набор активностей, порядок их следования, добывающий необходимую для принятия решения информацию. С другой стороны, CM предполагает интенсивные коммуникации между различными экспертами, отвечающими за определенные аспекты процесса.

Моделирование деятельности такого рода требует от нас более глубоко изучения к подходам по моделированию бизнес процессов. Из литературы Хенк выбрал три подхода к моделированию процессов:

  • Activity-based
  • Artifact-based
  • Communication-based

Первый подход знаком нам по BPMN и BPEL и характеризуются четко отсортированной последовательностью задач. При использовании третьего подхода цель процесса достигается в результате серии взаимодействий между участниками. А вот второй подход достаточно интересен. Он лежит в основе множества специализированный ИТ-решениях, однако в должной степени не стандартизирован.
В основе artifact-based подхода лежит понятие бизнес-объекта. Наиболее частым примером бизнес-объекта является “заказ” (это может быть заявка на приобретение товаров в интернет-магазине, заказ на предоставление услуги и т.п.) . Бизнес-объект обладает множеством различных свойств, таких как уникальный идентификатор, дата создания, результат проверки кредитной истории, ожидаемая дата поставки и т.п., а так же набором состояний: «новый», «ожидает проверки», «выполнен».

Case managment претендует на объединение всех трех изложенных подходов. Задача, безусловно, амбициозная, но… вполне реализуемая. По крайней мере, такие модные фишки как архитектурный стиль REST и семантический web направлены на универсализацию представлений объектов и отношений между ними.

Одним словом, чем дальше, тем интереснее

Ключевые моменты Case Management

По статье Хенка де Мана Case Management: A Review of Modeling Approaches

Хенк де Ман, research director компании Corsys, выделил следующие особенности case management (далее CM):
1. Центральное место в управлении кейсами занимает непосредственно кейс. Так в здравоохранении, из которого проистекает направление СМ, «история болезни» пациента накапливает всю необходимую информацию и определяет дальнейшие действия терапевта.
2. CM предполагает сотрудничество и коммуникацию. Кроме того, участникам обработки кейса придется реагировать на новые события
3. Как правило, действия сотрудников обслуживающих кейс, строго не предопределены. Эксперту понятно, что необходимо сделать в текущей ситуации, а дальнейшие действия вытекают из результатов первого шага.
4. Цель является более ясной, чем путь её достижения. Для достижения цели возможны различные пути. Выбор того или иного конкретного пути будет определяться в ходе достижения цели, а не планироваться заранее.
5. Исполнитель кейса – это эксперт (knowledge worker), владеющий навыками, которые позволяют ему иметь определенную свободу в принятии решения, в рамках зоны своей ответственности.

Что интересно в этих характеристиках. Во-первых, произнеся слова сотрудничество, коммуникация, сбор информации и knowledge worker мы моментально попадаем на территорию социального ПО, т.е. для корпораций – область Enterprise 2.0. Во-вторых, мы не расстаемся с такими понятиями как роли, активности, последовательность действий и пр., т.е. продолжаем пребывать на территории BPM. Одним словом, нас ожидает микс наиболее узнаваемых ИТ идей текущего момента social software и BPM

Продолжение: Case management и модели процессов