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

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

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

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

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

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

Первое, с чего начинается работа бизнес-аналитика в ИТ-проекте, – изучение предметной области заказчика. Невозможно оптимизировать какую-либо деятельность, не понимая ее сути.

Переходя к обсуждению ключевых задач бизнес-аналитика, важно помнить: в основе любого ИТ-проекта лежит некая проблема. Не будь проблемы, у заказчика не было бы и повода обращаться к исполнителю для создания или доработки ИТ-решения. Чтобы устранить данную проблему, ее для начала нужно сформулировать. Казалось бы, очевидно: как решать задачу, которой не понимаешь? Парадоксально, но многие команды именно так и поступают, особенно на ранних стадиях работы над проектом. Естественно, это сказывается на итоговых результатах и порой приводит к необходимости переделывать всю работу. Следовательно, одна из ключевых задач аналитика – минимизировать вероятность подобной ситуации за счет скрупулезного фиксирования информации по проекту и стремления не оставить ни одного вопроса без ответа.

Быстрый съедает крупного». Это значит, что аналитику важно искать золотую середину между обстоятельным сбором данных и скоростью подготовки аналитических материалов