Цитаты из книг автора «Вадим Миронов»

Бизнес-процессы. Моделирование, внедрение, управление» Владимир Репин

Исмагилова из Школы системного анализа.

работа с изменениями – это попытка контролировать хаос. Тем не менее инструменты для контроля хаоса есть, и они достаточно простые. В английской терминологии используется термин Matrix of change requests – «матрица запросов на изменение». Русскую версию такой матрицы иногда называют ЛУК – «лист учета комментариев». В листе учета комментариев скрупулезно регистрируются любые запросы заказчика на изменение документации либо функционала ИТ-решения.

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

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

В основе процессных требований лежат карты процессов «как есть» и «как должно быть». Эти требования описывают текущее и целевое состояние бизнес-процесса, зоны ответственности, используемые в работе программные продукты и т. д. Также в процессных требованиях могут фиксироваться как фактические, так и целевые измеримые показатели процесса. Например, в них может указываться, что внедрение ИТ-решения должно увеличить среднюю скорость выполнения процесса на X минут или Y процентов. Особое внимание в процессных требованиях уделяется различиям между текущим процессом и целевым. Так, в них отражаются все изменения, связанные с последовательностью выполнения функций, форматом их выполнения, ответственными исполнителями и т. д.

Некоторые заказчики стремятся сразу же перейти к описанию процесса «как должно быть». Они говорят: «Я и так прекрасно знаю, что меня не устраивает! Давайте обсудим идеальный процесс!» Можно ли приступать к работе над идеалом без рассмотрения текущей ситуации? Можно, но нежелательно. Дело в том, что карта «как есть» позволяет избежать узкого, субъективного взгляда на текущую деятельность. Вероятность выявить существенные детали при описании процесса «как есть» намного выше. Это касается взаимодействия разных подразделений, логических развилок, зон ответственности и т. д. Если же сразу начинать с процесса «как должно быть», можно упустить важные детали. Более того, существует риск, что при обсуждении целевого процесса подразделение-заказчик забудет об интересах других. Каждый руководитель в первую очередь исходит из нужд своего собственного подразделения. Возможна ситуация, при которой вы, как аналитик, потратите время и усилия на создание карты процесса «как должно быть», а потом окажется, что она не учитывает особенности работы других подразделений, поскольку заказчик в ходе работы подумал только о себе. В этом случае карты процессов придется переделывать.

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

Выстраивая карты процессов «как есть», бизнес-аналитик погружается в предметную область заказчика. Ему становятся понятны логика и цель действий, выполняемых участниками процесса. Если специалист имеет на руках наглядную схему текущей деятельности, ему намного проще зафиксировать проблемные зоны процесса, в том числе так называемые «бутылочные горлышки». «Бутылочное горлышко» – это узкое место в процессе: функция или набор функций с низкой пропускной способностью. Русская пословица гласит: «Где тонко, там и рвется». В случае же с бизнес-процессами можно сказать: «Где узко – там потеря времени и денег».

Тем более невозможно четко поставить задачу разработчикам решения, если до конца не ясен контекст его использования в будущем.