среда, 30 ноября 2011 г.

BizAgi Process Modeler - BizAбидный дизайнер бизнес-процессов

Работаю над проектом одного крупного заказчика государевой породы. Техническая среда требует, кроме всего прочего, чтобы бизнес-процессы были спроектированы в BizAgi Modeler.
Штука интересная. Судя по отзывам в сети, активно используется аналитиками (почитать можно здесь и здесь).

Не требует сверхнавыков для начала работы - драг$дроп интерфейс для составления карты БП. Основная палитра (в крайней левой части экрана) не перегружена значками, как в Visio: 5 основных элементов, пара коннекторов, несколько артефактов.

Тип "действия", либо логического оператора, определяется из контекстного меню (правая кнопка мыши на задаче, шлюзе). Детальное описание каждого "действия" сосредоточено в нижней области окна и доступно для редактирования при выделении этого "действия". По мере работы над схемой можно проверять весь workflow на валидность. Однако, чтобы запустить весь процесс, нужно качнуть BizAgi Xpress (~200Mb). Сначала меня это несколько удивило, но потом идея стала понятна: далеко не каждый аналитик использует запуск модели бизнес-процессов, тестирование, трассировку - часто дело ограничивается отрисовкой схемы, - поэтому незачем перегружать продукт специфическими свойствами, кому надо - сам достанет.

Нужно отметить типы импорта/экспорта этой штуковины. буквально одной кнопкой можно сделать экспорт в картинку, word, Acrobat, Visio, xpdl, xml. Импортировать схему БП можно в Visio, xpdl, xml. Кроме того, можно опубликовать web-сервис из только что спроектированной схемы.

Подозреваю, что это лишь верхушка айсберга, и у этой матрёшки много составляющих, ориентированных на разные категории и уровень требований пользователей (архитекторов, аналитиков, BPMN-разработчиков, тестировщиков). Но основную идею инструмента - простоту и легкость использования - я, думаю, уловила.

В ходе работы пока отследила только один недостаток: немного притормаживает по мере роста схемы - увеличения количества операторов и задач (>50).



четверг, 17 ноября 2011 г.

Архитектор vs Пресейл

В одной ИТ-консалтинговой компании принят такой подход к организации работы с заказчиком: выделена специальная группа специалистов для предконтрактной работы с клиентом. В нее набираются специалисты  высокого уровня, способные разработать архитектуру предлагаемого ИТ-решения в соответствии с требованиями клиента. Эдакий эскизный проект, который затем войдет в технико-коммерческое предложение (ТКП) клиенту. Такую группу специалистов компания называет пресейлом, а самих людей - пресейл-менеджерами. 
При  этом подходе предконтрактная работа завершается подписанием договора с клиентом, и зона ответственности пресейл-менеджера заканчивается. В сухом остатке имеем архитектора, разработавшего некое ИТ-решение на основе "быстрых" данных клиента и своего опыта предыдущих проектов. Далее это ИТ-решение передается на реализацию, а архитектор привлекается только как консультант. 

Самый очевидный недостаток этой схемы: архитектор решения работает вне команды проекта. Более того, передав архитектуру исполнителям, он больше не влияет на результат проекта. Строго говоря, архитектор в данном случае заинтересован только в "получении" проекта (в согласии клиента подставить подпись под договором), но никак не в правильном решении.