Функциональные карты и диаграммы вариантов использования

FMapСегодня несколько слов о техниках работы бизнес-аналитика. Уже пару десятков лет основной техникой моделирования функционала информационных систем является разработка вариантов использования (use cases). Техника, действительно, неплохая. Особенно если бизнес-аналитик  прочитал книжку Алистера Коберна «Современные методы моделирования функциональных требований» или посетил учебный курс по разработке юзкейсов. Однако визуализация вариантов использования в виде соответствующей UML диаграммы до сих пор вызывает сдержанную ухмылку у разработчиков и легкое недоумение у функциональных заказчиков. Пару месяцев назад в заметке Так ли уж близки корпоративная архитектура и бизнес-процессы? я писал о том, что на уровне бизнес-архитектуры никто никаких юзкейсов не рисует. Для отображения деятельности организации используется Business Capability Map – техника, позволяющая отобразить все виды деятельности предприятия на одной картинке. Довольно часто звучит и другой термин: функциональная карта. Что это такое и как использовать эту карту в проектах я позволю себе изложить в виде небольшой истории о вымышленном проекте разработки системы управления инцидентами, рассказанной от лица ведущего бизнес-аналитика этого проекта. Читать далее Функциональные карты и диаграммы вариантов использования

Чему ИТ может научить бизнес. Пара замечаний о Product Development.

лиса и журавльВ компании, из которой я недавно уволился, я не все время работал Главным ИТ архитектором. Несколько лет я проработал менеджером по запуску новых продуктов (value added services). Правда, в определенный момент пришло осознание того, что мы делаем все не очень правильно. Собственно,  потому я и перешел в ИТ на позицию архитектора. Архитектор, особенно архитектор предприятия (Enterprise Architect) – это тот человек, который может исправить некоторые ошибки бизнеса (я оставлю за скобками вопрос, кто такой EA и почему в отечественных реалиях такая должность не встречается в бизнес-подразделениях). Я надеюсь, что в будущем компания успешно справится с болезнями роста и скорректирует процессы развития и управления продуктами, но во время моей работы этот процесс был таким, каким он был.   Читать далее Чему ИТ может научить бизнес. Пара замечаний о Product Development.

Software architecture workshop

use-caseПару недель назад я поделился в фейсбуке мыслью организации воркшопа по ИТ архитектуре и пообещал подробнее написать в блоге как это будет выглядеть. Software architecture workshop это собрание рабочей группы проекта часика на 3-4 в ходе которого осуществляется проектирование ИТ решения для конкретного проекта. Происходить он должен через 2-3 недели после инициации проекта к  моменту, когда заказчик может хоть как-то сформулировать требования. На вход такого воркшопа и поступает заказчик, способный сформулировать требования. На выходе получаем 2-3 варианта реализации этих требований в виде зарисовок архитектуры и список вопросов  для дальнейшей проработки, другими словами – набор задач участникам рабочей группы на фазу планирования. Читать далее Software architecture workshop

Новый учебный курс по архитектуре ИС

designerМне предложили пересобрать “Краткий путеводитель по архитектуре информационных систем” в новом формате. Это будет практически новый учебный курс, вернее мастер-класс в формате 2 дня по 4 часа. Отличаться от того, что было раньше он будет не только по форме, но и по содержанию, а именно:

1. Фокусироваться я буду только на одной задаче: архитектура программного продукта. Т.е., если использовать англоязычную терминологию, то речь пойдет об application architecture. Читать далее Новый учебный курс по архитектуре ИС

Адаптивный кейс-менеджмент маскируется под BPM

Именно так бы охарактеризовал я своё впечатление от прошедшей сегодня конференции CNews BPM 2011: направления развития. К сожалению, я не смог выслушать два последних выступления но и остальных докладов хватило для того чтоб понять, что призрак adaptive case management потихоньку пробирается из Европы и в нашу страну. Причем, если старожилы BPM сообщества в своих докладах упоминали термин case management, то «новички» рассказывали про BPM в стиле «управление и автоматизация бизнес-процессов без консервантов BPMN». Но обо всем по порядку:

Читать далее Адаптивный кейс-менеджмент маскируется под BPM

Маргинальный подход к моделированию бизнес-процессов

В 2002 году под заголовком «Современные методы описания функциональных требований к системам» на русском языке была выпущена книга Алистера Коберна «Writing Effective Use Cases» (скачать русскую версию в djvu можно по этой ссылке)
Книжка эта, конечно, в первую очередь о требованиях, но и не только о требованиях. В действительности, автор излагает подход к моделированию процессов, позволяющий не использовать графическую нотацию. Я предвижу праведный гнев бизнес-аналитиков. Однако считаю совершенно необходимым поделиться с экспертами, занимающимися бизнес-процессами, данным подходом к их моделированию.
Читать далее Маргинальный подход к моделированию бизнес-процессов

Worklist applications

Пришло время испортить бочку светлого меда адаптивного кейс-менеджмента небольшой ложкой дегтя. Довольно много сказано о потенциальных опасностях, подстерегающих BPM проект. Можно посмотреть здесь или здесь. Мне наиболее близка точка зрения Андрея Коптелова, изложенная в Russian ARIS Blog:

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

Сопротивления изменениям не просто характеристика отдельных людей, а скорее свойство человеческой натуры. Как, впрочем, и недостаток дисциплины и терпимости. Не буду дальше распространяться на эту тему. Лучше чем у Алистера Коберна у меня это все равно не получится. Желающих углубиться в тему отсылаю к Главе 2 «Индивидуумы» его книжки «Быстрая разработка программного обеспечения». Мы же примем эти особенности людей как данность и поразмышляем о том, как этот прискорбный факт повлиял на эволюцию BPMS. Читать далее Worklist applications

Петли обратной связи

Управляющие процессы изобилуют корректирующими петлями (запросами на проверку и уточнение)

Не маленьких размеров камешек забросил в огород любителей тяжеловесных формализованных процессов Алистэр Коуберн в работе «The New Face of Software Engineering». Алистэр очень педантичный исследователь и потому, разбирая ту или иную тему, докапывается до сути. Его рассуждения интересны и поучительны.

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

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