Я уже писала ранее, что внедрение дата-практик в компании затрагивает все слои бизнеса, добавляются не только новые процессы по управлению данными, но и меняются существующие. На мой вкус, среди всех изменений есть одно, казалось бы, незначительное, но очень ёмкое по результативности. Это изменение касается документации по сбору требований на доработку информационных систем или создание новых проектов/продуктов.
"Это один маленький шаг для человека отдела аналитики и огромный скачок для человечества организации".
Итак, вносим изменения в процесс сбора бизнес-требований, чтобы стать data-driven компанией. Что такое data-driven и зачем он нужен - разбирались тут. Конечно, чтобы стать data-driven нужна целая программа мероприятий, но можно "подстелить соломки" и начать точечно вводить изменения там, где не будет сильного импакта на процесс. И одним из таких изменений является доработка шаблона бизнес-требований. Посмотрите на свой шаблон БТ - видите в нём раздел "Требование к данным" или "Описание данных"? Если нет, то приготовьтесь его добавить. Есть несколько вариантов изменений: сознательные, бессознательные и стратегические. Условное разделение :) , можете придумать своё. Рассмотрим все три варианта и посмотрим, что нужно сделать в каждом отдельном случае с процессом и шаблоном по сбору бизнес-требований. Представим, что мы те самые бизнес-аналитики и нам предстоит меняться.
1. Бессознательные изменения. Очень просто сделать и откатить. Это когда вы чувствуете, что нужно что-то менять, но зачем вам это нужно - толком объяснить не можете. Вот только документ бизнес-требований часто возвращают на доработку, а исполнители (разработчики) жалуются, что в ваших требованиях нет ничего для них полезного. Опять же, никто вас не заставляет меняться: ни заказчики, ни руководители, ни коллеги по цеху. Но все требуют, чтобы ты - бизнес-аналитик или руководитель отдела аналитики - работал лучше и эффективнее. И вот тут можно сделать маленький шаг всем навстречу и добавить в свой шаблон бизнес-требований раздел "Требования к данным". Для начала достаточно будет вот такой таблички, потом доработаете:
Обратите внимание, мы добавили в БТ всего один раздел, информацию по которому вы и так собираете, просто она у вас остаётся не систематизированной и не сгруппированной по каким-либо признакам, и размазана по всему тексту ваших бизнес-требований. Сам процесс при этом абсолютно не изменится. Когда полезны подобные телодвижения? Когда в компании уже говорят про работу с данными, но пока ещё ничего серьёзного не предпринимают. Скажу больше, в тех случаях, когда вы оформляете бизнес-требования на прием/передачу информации в/из системы (интеграция), наличие подобной информации просто необходимо. Если её не собираете вы, то за вас это точно делает кто-то другой. Но ведь это ваша работа, да?
Плюсы: Изменения в шаблоне БТ ни с кем не нужно согласовывать. Благодаря наличию раздела "Требования к данным", ваши бизнес-требования будут очень быстро проходить этапы согласования на стороне системных аналитиков и разработчиков. Возможно, вам скажут спасибо и поставят в пример, похвалят за инициативу.
Минусы: кроме ваших разработчиков реальную пользу никто не ощутит, да и у вас "запал" через пару-тройку упражнений, наверное, пройдёт, и всё вернётся на круги своя. Если вам не удастся убедить остальных перейти на аналогичный шаблон, бизнес-эффект будет незначительный, а убеждать и уговаривать людей измениться - та ещё морока! Поэтому ситуация у нас тут как в старом анекдоте*: "Ничего не трогай, ничего не меняй!"
2. Сознательные изменения - это изменения средней сложности. Обычно происходят, когда в вашей компании идут полным ходом изменения, связанные с внедрением дата-практик, и вот, наконец, они докатились и до вас - надо что-то менять, но бюджет не выделен, проект не открыт :). Часто бывает, что никто толком и не говорит что нужно менять, но очень много лозунгов про лучшую жизнь и про то, что "надо всем вместе собраться с силами" и придумать "как нам стать лучше". В этом случае вам с коллегами по цеху нужно будет самостоятельно решить что вы будете менять и каков масштаб этих изменений. И вот тут как раз нужно "подстелить соломки" - предлагаю вам для начала изменить шаблон БТ, чтобы он отвечал новым вызовам. То есть мы добавляем раздел "Требования к данным" и одним махом удовлетворяем запрос руководства стать data-driven в отдельно взятом направлении бизнес-аналитики.
За основу можем брать таблицу из п.1. Что добавлять в таблицу зависит от запроса на изменения, но, вероятно, вам понадобятся такие поля: термин (бизнес-имя), названия систем-источников, систем-приемников, мета-данные для каждой информационной системы-участника (имена атрибутов), признак "сущность"/"атрибут", имя бизнес-домена или дата-домена, имя ответственного за данные и пр. и пр. Идеально, если на данном этапе вы начнёте централизованный сбор описаний данных, т.е. все таблички из БТ будут консолидироваться в отдельном пространстве. Оптимально, если это будет не Confluence или Excel, а инструмент Бизнес-глоссарий. Хорошим подспорьем будет также внедрить процесс моделирования данных с использованием диаграмм, например, сущность-связь (см. статью про моделирование), но моделированием чаще занимаются системные аналитики или архитекторы данных.
Плюсы: Совместно с коллегами по цеху вы вольны самостоятельно принимать решение о том что и в каком объеме хотите добавить/изменить в существующем шаблоне. Процесс не изменится, если вы не начнёте пользоваться новыми инструментами.
Минусы: Если нет четкого видения как нужно меняться, чтобы получить требуемый эффект от изменений, готовьтесь к долгим дебатам и спорам, и не только внутри, но и со смежными подразделениями. Нужно будет выделить время на обучение работе с новыми инструментами, как правило в ущерб текущим задачам. Также потребуется менять процесс с учетом новых вводных и инструментов. Если нет отдельного проекта и бюджета под все эти активности, то у всех будет ощущение жуткой неопределённости, а поставленная задача будет прямо как в анекдоте: "Мыши! Станьте ёжиками!" :)
3. Стратегические - это сложные комплексные изменения, затрагивающие не только ваше подразделение, но и смежные. Вся производственная цепочка ИТ и все бизнес-функции будут вовлечены в процесс изменений, у всех, наверное, будет понимание зачем это нужно делать. Скорее всего, к вам придут эксперты/профессионалы, которые объяснят и разложат всё по полочкам, расскажут что и как нужно менять в вашем процессе сбора требований. Ну а если нет, то вас точно отправят на какие-нибудь курсы. Должно быть инициировано несколько проектов по внедрению специализированных инструментов управления данными, в том числе по сбору требований к данным, кого-то из вас включат в рабочие группы, и вы примите активное участие во всех нововведениях. Всех всему научат :)
В случае реализации третьего сценария и внедрения у вас Data Governance процессов, работа по сбору требований к данным будет вестись в автоматизированных системах типа Каталог Данных, которые позволяют разрабатывать и хранить карты данных, модели данных и т.п. В цикл сбора требований к данным будете вовлечены не только вы - бизнес-аналитики, но и сотрудники других подразделений, каждый внесёт свой вклад в общее дело, добавит свои требования к данным.
Плюсы: Вы точно знаете, что нужно идти в data-driven подход и у вас есть поддержка на всех уровнях руководства. Профессионалы расскажут вам что нужно делать и как, иначе говоря, за вас подумали. Вам останется только принять изменения, протестировать новый подход и вернуть обратную связь: что хорошо, а что не получилось.
Минусы: У вас практически нет свободы выбора, скорее всего вы загнаны в жесткие рамки по срокам, а коллеги по цеху продолжают роптать, не хотят переходить на новые рельсы и в целом ощущение, что настали смутные времена: "Хочется то ли водки, то ли революции" :) Не пугайтесь, это стандартный процесс принятия изменений, вы на первой его стадии - отрицание.
Шаблон БТ из п.1 (бессознательные изменения) с разделом Требования к данным можно скачать на Boosty в одноименном посте.
Послесловие: требования к данным по п.3 (стратегические изменения) в формате эл.таблиц можно скачать на boosty, выложено в посте DQ: Бизнес-требования к качеству данных
Поддержать канал | Подписаться на скачивание файлов | Читать в телеграм
*анекдот №1:
Жили-были мыши. Все их обижали. Однажды пришли мыши к сове:
-Мудрая сова, помоги! Все нас едят. Скоро нас не останется. Что делать ?
Подумала сова и говорит:
-Мыши! Станьте ежами! Будете колючими и для охотников недоступны.
Побежали мыши радостно:
-Станем ежами! Станем ежами!
Вдруг одна остановилась:
-А кто-нибудь знает: как стать ежами?
Никто. Побежали обратно к сове.
-Сова! А как нам стать ежами???
-Мыши! Идите на фик! Я не тактик, я - стратег!
*анекдот №2:
Сидит программист глубоко в отладке.
Подходит сынишка:
- Папа, почему солнышко каждый день встает на востоке,
а садится на западе?
- Ты это проверял?
- Проверял.
- Хорошо проверял?
- Хорошо.
- Работает?
- Работает.
- Каждый день работает?
- Да, каждый день.
- Тогда ради бога, сынок, ничего не трогай, ничего не меняй.
Вот такой пятничный нарратив. Всем хорошего времени суток! :)
Если статья была полезна или просто понравилась, помогите другим быстрее найти её - поставьте лайк.
