Е. Всяких - Практика и проблематика моделирования бизнес-процессов

Схожими по своей природе с «неучетом» существующего лингвистического обеспечения являются проблемы наличия ошибок в проектировании системы «модель бизнес-архитектуры предприятия». Данные ошибки можно условно разделить на две категории:

♦неполнота и некорректная реализация заявляемого функционала;

♦отсутствие возможности эффективного развития модели.

Часть оценок в отношении проектных ошибок может носить субъективный характер со стороны заказчика. Такого рода субъективные ошибки могут быть связаны с «личностной» интерпретацией представителями заказчика рамок технического задания (ТЗ) на разработку. Безусловно, может быть и объективная природа у проектных ошибок.

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

Типичные проектные ошибки в отношении проектирования модели бизнес-архитектуры предприятия могут быть связаны с:

♦неполнотой охвата состава бизнес-процессов;

♦недостаточным уровнем детализации;

♦недостаточным уровнем чувствительности моделей;

♦неполнотой функциональных средств анализа и построения отчетов;

♦неправильным отражением логики бизнес-процессов;

♦неправильным (неоптимальным) отражением окружения бизнес-функций;

♦«недружелюбностью» интерфейса и т. д.

Соответственно, в зависимости от выбранной архитектуры построения выявляемые ошибки могут классифицироваться как быстро устраняемые, равно как и долго устраняемые.

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

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

♦нагрузочное решение при работе в многопользовательском режиме;

♦«прогон» модели по максимально возможному количеству входных ситуаций (желателен перебор всех ситуаций);

♦различные сочетания использования разработанного прикладного функционала.

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

Отдельного упоминания заслуживают риски, связанные с таким феноменом, как «паралич» детализации. Желание сразу охватить все бизнес-процессы с максимально возможной подробностью может сыграть злую шутку как с исполнителем, так и с заказчиком. Слишком детальная и слишком чувствительная модель может оказаться очень дорогой и непрактичной. Дорогой – поскольку потребует значительных ресурсов не только на свою реализацию, но и на поддержку. Непрактичной – потому что будет реагировать на непринципиальные изменения, отвлекая внимание и создавая угрозу пропуска (неучета) действительно важных событий.

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

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