Hi There!

Это перевод статьи "Norman Thuswaldner с сайта BA Times". Статья 2014-ого года, но мне показалась очень актуальной и в 2018-ом.

Начинаем!

Требования к данным — Должен ли бизнес-аналитик заботиться?

Однажды, директор ИТ-отдела сказал мне, чтобы я не думал о требованиях к данным и сосредоточился только на бизнес-требованиях. Система должна была быть разработана за 6-8 месяцев но потребовалось более двух лет, и немногие остались довольны конечным результатом. [читая этот текст, я не могу ни радоваться насколько у нас хорошо организованный проект, я работаю над созданием IT продукта, практически в каждом проекте у нас есть отдельный человек, который заботится только о данных]

Должны ли бизнес-аналитики заботиться о требованиях к данным? Что вы думаете?

К сожалению, бизнес-аналитики тратят гораздо больше времени на анализ бизнес-процессов, чем на анализ бизнес-информации. Это часто приводит к требованиям, которые рассказывают только половину истории. Когда дело доходит до построения IT систем, понимание данных не менее важно, чем понимание процессов. В современном мире немногие организации могут позволить себе перестраивать только построенную систему.

Существуют способы, который помогут собрать требования и позволят создать полную картину того, что необходимо (и только то, что необходимо), чтобы получить максимальную отдачу от проекта с первого раза. [заинтриговал]

Так что насчет данных?

Как бизнес-аналитики, мы являемся экспертами в нахождении корня проблемы или возможности, и у нас есть много методов для этого. Выбор методов, которые мы используем зависят от множества факторов, включая бизнес-среду, предпочтения заинтересованных сторон (stakeholders), наличие экспертов по тематике (SME), доступность систем, соответствующую документацию и др. Когда мы разрабатываем модели бизнес-процессов, мы часто моделируем текущие «as-is» и целевые «to-be» бизнес-процессы. Примеры использования, диаграммы потоков данных, функциональные разложения, диаграммы последовательности и диаграммы состояний — всего лишь несколько доступных методов. Когда дело доходит до моделирования бизнес-процессов, у нас есть полный арсенал методов в нашем наборе инструментов, но понятие документирования информации часто отсутствует.

Бизнес-аналитики иногда забывают или игнорируют требования к данным. Это может быть потому, что они думают, что это не их работа, или что кто-то другой позаботится об этом. Возможно, они запуганы видом тех диаграмм со всеми этими прямоугольниками и линиями. Независимо от причин, если вы являетесь частью команды, которая строит IT систему, и вы документируете бизнес-процессы без какого-либо представления о данных, вы делаете только половину своей работы.

Почему я должен заботиться?

Если вы понимаете требования к данным, у вас есть множество преимуществ. Когда бизнес-аналитик понимает бизнес-процессы и данные, есть отличная возможность перекрестно проверить обе области. Например, если есть бизнес-процесс, который не использует (или не производит) данных, скорее всего, это не бизнес-процесс. Аналогичным образом, если в модели данных есть элемент данных, который не используется каким-либо бизнес-процессом, возможно, мы упустили бизнес-процесс или элемент данных не входит в систему. В любом случае, эти знания могут быть использованы для полного завершения анализа бизнес-процессов и учета всех требований к данным.

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

Требования к данным

1. Моделирование данных

Модель данных является одним из наиболее мощных инструментов, используемых для сбора требований к информации. Это отличный подход, потому что каждый элемент данных может быть тщательно задокументирован, включая его тип данных, длину поля и его связь с другими элементами данных. Как уже упоминалось ранее, модель данных является прекрасным средством проверки полноты модели бизнес-процесса.
Другим аспектом моделирования данных, который делает его мощным, является то, что, как только он будет установлен и проверен SME, бизнес-аналитик может работать с администратором базы данных, чтобы перепроектировать модель в физическую базу данных, особенно если модель была разработана с использованием инструмента моделирования данных.

Моделирование данных требует практики, и, если у вас нет опыта в этом методе, может потребоваться пройти курс обучения и работать с опытным коллегой или наставником, который может помочь вам учиться.

2. Словарь данных

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

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

3. Анализ отчетов и прототипов

Другим способом, который бизнес-аналитик может описать требованиями к данным, является разработка серии макетов отчетов. Предполагается, что все данные, поступающие в систему, выводятся в той или иной форме в отчете. В конце концов, если данные не будут отображаться в отчете, зачем вообще помещать их в базу данных? Теоретически, как только бизнес-аналитик имеет набор мак��тов отчетов, которые были проверены SME, у него есть все элементы данных, которые он не может упустить.

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

4. Обратный инжиниринг

Многие проекты по разработке IT систем сосредоточены на коммерческих готовых решениях Сommercial Off-The-Shelf Solutions (COTS), поскольку большинство организаций осознают риск и затраты на разработку индивидуальных решений. При внедрении COTS, организации, которые не выполняют "домашнее задание", с точки зрения определения их бизнес-процессов и требований к данным, довольно легко рискуют провалиться. Недостаточно все просто доверить поставщику, вы сами полностью должны быть уверены в том, что получите на выходе.

Технология обратного проектирования включает в себя приобретение пробной версии рассматриваемого COTS и копирование БД программного обеспечения в инструмент моделирования данных для создания физической схемы БД. Затем схема сравнивается с моделью данных, представляющей требования к данным организации. Анализ различий между ними определит области, в которых должны быть приняты решения. Например, если решение не поддерживает определенные требования к данным, организация должна будет реши��ь, может ли он жить без него, или добавить ручную работу или определить, можно ли настроить продукт. Существует множество причин, по которым не всегда возможно обратное проектирование базы данных поставщика, и даже если это возможно, требуется определенное техническое ноу-хау.

Да, ты можешь!

Вы не должны быть экспертом по моделированию данных для сбора требований к данным. Вам только нужно быть любопытным, иметь желание попробовать что-то новое и быть готовым работать с другими IТ-специалистами, которые могут знать что-то, чего не знаете вы. Это легко, выйти из зоны комфорта и вступить в зону, которая является бизнес-анализом

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

Cheers!