Как быстро изучить новую предметную область и провести предпроектное обследование

27.09.23

Бизнес-анализ - Анализ предметной области

Знание предметной области – важная составляющая работы аналитика. Часто именно понимание аналитиком хитросплетений бизнеса позволяет найти эффективное решение. Но на изучение новой (сложной) области может понадобиться несколько месяцев, а проекты и заказчики ждать не будут. Речь в статье пойдет о том, как быстро изучить новую предметную область через концептуальную модель бизнес-анализа и прожекторное видение исследуемой области.

 

 

Меня зовут Ирина Гертовская, я аналитик и руководитель проектов. Прошла все роли в разработке и внедрении ПО, а в последние годы много работаю как аналитик и организатор работы аналитиков.

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

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

Немного поиграем в него.

 

Текущие тренды в ИТ

 

В октябре 2021 года прошла большая конференция «Умные решения – умная страна», где выявили семь текущих трендов в ИТ. Из них для меня имеют наибольшее значение три тренда:

  • ИТ – не сервис, а основа бизнеса. Сейчас нет бизнеса без ИТ. Раньше в компании на всякий случай хранилась стопка бумаг: компьютер отказал – заполняем документы вручную. Сейчас этого уже нет. Все начинается с того, что заводится система, которая помогает людям работать.

  • Сверхавтоматизация. Все, что может быть автоматизировано, должно быть автоматизировано.

  • Локализация производства. Над многими серьезными вещами мы начинаем работать локально. Поэтому нам нужно хорошее понимание бизнеса и наша аналитическая айтишная хватка. Специалисты бизнеса тоже нужны, но они не всегда ведают, что нужно делать. А нам нужно научиться быстро понимать бизнес, тогда мы будем на высоте. Это потребность жизни, поэтому нехватка кадров очень высокая.

 

 

Но у нас есть проблема: когда мы приходим в новую предметную область, она для нас примерно как «Хаос» Айвазовского. Есть белые пятна, но большая часть покрыта мраком, где ничего не понятно.

 

 

Поговорим о проблеме погружения в новую предметную область и о том, что делает проект успешным:

  • о стейкхолдерах;

  • о концептуальной модели бизнес-анализа;

  • рассмотрим чек-лист погружения в новую предметную область;

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

 

Совсем немного «теории»

 

Чтобы успешно запустить систему, нужна осознанность и знание опыта успешных и неуспешных проектов. Т.е. это не совсем теория – это сконцентрированный мировой опыт лучших практик. Он собран в книги, по которым мы работаем.

Что такое «успешные проекты»? Это те проекты, где достигается успех ключевых заинтересованных сторон – тех, кто является благоприобретателем внедряемой системы.

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

Попробуем сейчас понять, как пройти, чтобы этих ошибок было меньше.

 

 

На слайде – схема концептуальной модели бизнес-анализа, которая описана в «Своде знаний по бизнес-анализу» (BABOK Guide).

Она состоит из шести составляющих:

  • Изменение (Change)

  • Потребность (Need)

  • Решение (Solution)

  • Заинтересованная сторона (Stakeholder)

  • Ценность (Value)

  • Контекст (Context)

Из этих шести составляющих строится все понимание, как правильно обследовать и проектировать систему.

 

 

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

  • что нужно стейкхолдерам;

  • что окружает стейкхолдеров – в контексте чего им что-то нужно;

  • а также какие у стейкхолдеров ценности и потребности – ради чего все это.

 

История с бентонитом

 

Немного истории из моей практики.

 

 

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

Я понимала все как-то вот так:

 

 

Или так – я более-менее понимала, какие фабрики и подразделения на комбинате есть.

 

 

Но не более того.

 

 

И однажды начальник ВЦ говорит: «Сходи в отдел снабжения, у них там точно есть проблемы. Узнай, что им нужно автоматизировать».

 

 

Я пошла, поговорила. Они мне сказали: «Да, у нас есть проблема: нам нужен бентонит. Но мало того, что нам нужен бентонит, он нам нужен из Средней Азии». И они мне полчаса или час рассказывали о том, какой замечательный бентонит в Средней Азии.

Я вернулась в ВЦ и рассказала начальнику: «Им нужен бентонит. Как мы его поставим?». Начальник понял проблему и объяснил нам, молодым специалистам, какую роль бентонит играет в общем цикле производства.

 

 

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

  • что там добывают руду;

  • что ее вывозят из карьера;

  • обогащают;

  • отправляют на комбинат и т.д.

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

Сейчас я попробую об этом рассказать, а вы попробуйте понять.

 

Источники информации

 

 

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

  • Нужен консультант, который знает эту предметную область. Хорошо, если он вовлечен.

  • Если такого консультанта нет, берем открытые источники.

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

  • На основе вводных данных идем искать литературу.

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

Каждый источник информации оцениваем по основным параметрам:

  • Дата утверждения – например, для нормативки;

  • Дата ввода в действие;

  • Актуальность;

  • Легитимность.

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

 

Эти источники информации мы пишем в чек-лист и сразу же заводим глоссарий.

 

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

  • За ведение глоссария должен быть единый ответственный. Это может быть один человек или группа людей.

  • У глоссария должна быть история изменений, чтобы было понятно, кто, что, когда и по какой причине правил – там могут быть конфликты интересов или что-то еще.

  • Важно разобраться с понятиями и избежать нестыковок в терминологии.

 

Обязательно нужно фиксировать открытые вопросы – указываем, кто задал вопрос, кто должен на него ответить, кто, когда и что в результате ответил.

И подробно описываем все заинтересованные стороны – это центральная тема нашей истории.

 

Обязательно рекомендую вести реестр заинтересованных сторон. Не список, а именно реестр, он отличается от списка тем, что у элемента реестра есть код. Потому что иногда в составе заинтересованных сторон бывают замены (изменения наименования) или у конкретной заинтересованной стороны меняется должность. В этом случае нужна не нумерация типа 1, 2, 3, а такая, которая всегда остается с этим объектом или субъектом.

По «Своду знаний о бизнес-анализе» BABOK Guide 3.0 заинтересованные стороны – это человек или группа лиц (не организация), которые:

  • могут влиять на систему;

  • как-то к ней относятся – у каждого из этих людей есть какие-то связанные с системой интересы;

  • считают себя затронутыми системой;

  • их выбор может повлиять на выбор путей реализации системы.

Таких людей называют стейкхолдерами. Стейкхолдеры и заинтересованные стороны – это синонимы.

 

В реестр заинтересованных сторон мы пишем:

  • Какую роль играет конкретный стейкхолдер – это колонка «Кто».

  • И колонка «Что» – мы указываем основные функции, назначение, интересы, проблемы, ценности. Важно понять, какие свои проблемы люди могут решить с помощью системы.

Мы говорим еще не о проекте, мы говорим о погружении в предметную область.

 

 

Возвращаемся к понятиям бизнес-анализа. Ближайшие к стейкхолдерам понятия – это их ценности и потребности. Чтобы найти ценности и потребности стейкхолдеров, нужно узнать их основные функции. Где их искать?

 

Идем на официальный сайт компании и смотрим, что там написано.

На первой странице горно-обогатительного комбината написано, что он производит концентрат. Это значит, что основная функция горно-обогатительного комбината – производить концентрат.

 

 

У госорганов тоже есть основные направления деятельности и стратегическая карта (в нее очень полезно смотреть).

И у любого коммерческого предприятия почти всегда есть сайт, где сказано, какие у компании функции, и что там делают.

 

Идем дальше. Контекст – то, что окружает систему.

На слайде картинка из «Свода знаний по бизнес-анализу». У системы есть то, что ее окружает, как-то с системой взаимодействует, влияет. И это не только предметы в физическом мире. В первую очередь, контекст – это:

  • Назначение и цели;

  • Люди;

  • Бизнес-процессы;

  • Технологии;

  • Информационные системы, которые окружают нашу систему и т.д.

 

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

Поэтому основное, что нужно изучить в контексте – это бизнес-процессы.

 

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

 

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

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

По бизнес-процессу я рекомендую писать:

  • Кто благоприобретатель этого процесса – кто получает его результат?

  • Какой результат?

  • Какая цель процесса?

  • Из чего мы получаем этот результат? Что на входе?

  • Какой основной сценарий бизнес-процесса?

  • Какой альтернативный сценарий?

  • Какие у бизнес-процесса условия и ограничения?

Главное – понять благоприобретателя и результат.

 

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

 

Что важно в бизнес-объектах?

  • Назначение – для чего этот бизнес-объект.

  • Не всегда на бизнес-объект есть документ/справочник/отчет/сообщение. Это может быть и что-то физическое из реального мира. Это может быть какая-то вспомогательная часть, которая является источником чего-то, но она есть. Нужно понять ее и выписать. Очень полезно вести эти списки, эти реестры, чтобы потом не вспоминать. Не из головы доставать, а заглядывать в бумажку – помогает.

  • Укажите, откуда этот бизнес-объект появляется.

  • Для чего он используется.

  • Открытая это информация или закрытая.

  • И никогда не забывайте указывать количественные показатели. В зависимости от рода объекта они могут быть разными: объемы, скорости. Эти показатели бывают связаны с ограничениями – до такой-то даты, до такого-то часа. Допустим, компании нужно успевать закрывать операционный день в 10:00. Это значит, что до этого времени должны поступить все документы. Какой их объем – неважно. Поэтому мы должны посчитать объем и сказать: «Ребята, мы это загрузим?» или «Мы это выгрузим?»

Мне недавно рассказывали ситуацию, когда автоматизировали на 1С областную клиническую больницу – они перетащили все в 1С, но были проблемы. Не потянули серверы, не рассчитали нагрузку. Показатели производительности рассчитывают не аналитики, а технические специалисты, архитекторы. Но мы, аналитики, должны им дать эти количественные показатели бизнес-объектов.

 

Дальше составляем реестр потоков для данных и физических объектов.

 

Опять же, нас интересует:

  • кто владелец этого потока;

  • какое у него назначение;

  • откуда и что (какой бизнес-объект) везет этот поток, в каком бизнес-процессе возникает;

  • какая у него критичность – как этот поток данных влияет на бизнес-процесс.

 

Вернемся к железной руде

 

 

Что я сделала в ситуации с бентонитом, чтобы составить представление о предметной области:

  • Для начала я выделила заинтересованные стороны. Несмотря на то, что здесь написаны цеха (подразделения), на самом деле это коллективы этих подразделений, имеющие свой интерес что-то произвести, что-то обработать.

  • Далее обозначила бизнес-процессы, которые выполняются этими цехами.

  • И бизнес-объекты, которые создаются в ходе бизнес-процессов и передаются в физический мир (среди этих бизнес-объектов есть и документы).

 

 

В процессе сбора данных я начала понимать, что есть:

  • основные цеха, объекты и процессы (выделены цветом на слайде);

  • и есть обеспечивающие – они не вспомогательные и тоже очень важны, например, транспортный цех – это ого-го какая махина.

 

 

И вот когда это так распишешь, уже понимаешь, где место бентонита – он участвует в создании окатышей из концентрата.

 

 

Здесь мы включаем прожекторное видение – это еще одна методика, которой я хотела с вами поделиться.

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

Когда мы приходим на большое предприятие, нам ведь не говорят: «Автоматизируйте всё!». Нам говорят: «Давайте начнем с этого» (мне сказали начать со службы снабжения).

 

 

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

  • Для чего у нас бентонит? Для производства окатышей.

  • А производство окатышей для чего? Для службы сбыта, которая отправляет эти окатыши на сталеплавильный комбинат.

  • А почему служба сбыта отправляет именно окатыши? Потому что глина (а бентонит – это глина) позволяет защитить металл при хранении и транспортировке. Концентрат перемешивается с бентонитом и сворачивается в комочки (происходит процесс окомкования). Эти комочки потом обжигаются, становятся окатышами и передаются уже на выплавку металла.

  • Оказывается, глина из Средней Азии повышает качество окатышей, именно поэтому нужен был бентонит из Средней Азии.

 

 

Так все встало на свои места.

 

 

У меня получилась такая картинка.

  • Первый передел – это добыча. Владельцем передела является карьер, результат его труда – руда.

  • Второй передел – обогащение. Владельцем передела является рудообогатительная фабрика, результат ее труда – концентрат.

  • И третий передел – окомкование. Владельцем передела является фабрика окомкования, результат ее труда – окатыши.

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

 

Чек-лист погружения в предметную область

 

 

Идем дальше по чек-листу. При погружении нас интересует:

  • Нормативно-справочная информация. Как о ней появляется информация в системе.

  • Атрибуты качества. Их еще называют нефункциональными требованиями – важно о них не забывать.

  • Конфиденциальность, легитимность. Очень полезно смотреть, легитимен ли процесс, который мы собираемся автоматизировать – мало ли что мы автоматизируем. Конфиденциальность тоже полезно посмотреть. Не забывайте учитывать эти факторы.

  • Бизнес-правила и ограничения. Учитывайте ограничения, чтобы понимать возможности.

  • И, вишенка на торте, границы проекта или MVP. Не растекайтесь на анализ лишних процессов и выделяйте границы для получения минимально полезного результата.

 

 

Итого, что нужно сделать, чтобы быстро погрузиться в новую предметную область:

  1. Найдите консультанта, используйте источники информации.

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

  3. Фиксируйте важное, ведите реестры (списки).

  4. Выявляете ценности – изучайте, кому из заинтересованных сторон что нужно.

  5. Разделите область на задачи. Анализируйте по одной, максимум по двум-трем задачам.

  6. Помните об ограничениях и сразу же задумывайтесь о количественных характеристиках.

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

 

Источники

 

При подготовке к докладу я использовала следующие источники информации:

  1. К. Вигерс, Дж. Битти «Разработка требований к программному обеспечению»

  2. А. Коберн «Современные методы описания функциональных требований к системам»

  3. Д. Леффингуэлл, Д. Уиндриг «Принципы работы с требованиями к программному обеспечению. Унифицированный поход»

  4. А. Коберн «Быстрая разработка программного обеспечения»

  5. IIBA «BABOK Guide v3. Руководство к своду знаний по бизнес-анализу»

  6. Ирина Гертовская «Предпроект. Чек-лист обследования» 

  7. Марина Давыдова «Исследование предметной области, как квест в работе аналитика»

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

Проектирование Анализ предметной области Бесплатно (free)

В девятнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, как и для чего применяют DDD, и почему аналитиком важно знать об этом подходе.

13.05.2024    468    0    Radio_Analyst    0    

3

Анализ предметной области Бесплатно (free)

В этой части статьи обсуждается идея о том, что бухгалтерская реальность (AR) строится как научная (математическая) модель хозяйственной реальности (ER), а также рассмотрены общие принципы построения научных моделей.

03.05.2024    874    0    Polav62    9    

4

Анализ предметной области Бесплатно (free)

В этой части статьи предложен вариант профессиональной мировоззренческой модели на основе пары взаимосвязанных реальностей – хозяйственной реальности и бухгалтерской (виртуальной) реальности.

09.04.2024    1137    0    Polav62    0    

5

Анализ предметной области Анализ потребностей и поиск решений Бесплатно (free)

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

25.03.2024    583    0    alenkaiva    0    

4

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений Платформа 1С v8.3 1С:Управление холдингом Россия Бухгалтерский учет Налоговый учет Управленческий учет Бесплатно (free)

Для сближения всех видов учета и в целом финансовых проектов крайне важна методологическая разработка. В статье расскажем про опыт участия в проектах внедрения «1С:Управление холдингом» департамента 1С ГК «КОРУС Консалтинг». Разберем конфигурации взаимодействия команд, неудачные кейсы и поделимся чек-листами, которые помогают нам снизить риски на этапе разработки методологии.

07.02.2024    587    0    1C_Community    0    

1

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Для руководителей подразделений новые проекты вызывают желание получить максимальный эффект от реализации идей, а также опасения, верно ли выбран ориентир нововведений. О том, как справиться с трудностями, дойти до цели и внедрить 1С:ERP на производственном предприятии, ежедневно выпускающем десятки тысяч единиц готовой продукции, расскажем в статье.

30.01.2024    8132    0    user1578851    16    

23

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений

В седьмом выпуске второго сезона подкаста Радио “Аналитик“ поговорили о том, что такое бизнес-компетенции, для чего они нужны аналитику, к чему может привести их отсутствие и как их развивать.

28.11.2023    901    0    Radio_Analyst    0    

2

Анализ предметной области Бесплатно (free)

В седьмом выпуске подкаста Радио “Аналитик” обсудили, что из себя представляет процесс управления обеспечением, какие существуют варианты обеспечения, как осуществляется планирование и что нужно знать и уметь аналитику для работы с этим процессом.

13.01.2023    644    0    Radio_Analyst    0    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user1950534 27.09.23 14:40 Сейчас в теме
Бизнес- схему функционирования предприятия надо не только знать, но и поддерживать, включая отслеживание изменений, в идеале - на самом начальном этапе

Все больше прихожу к мысли, что современный владелец бизнеса - должен быть в первую очередь айтишник.... по крайней мере в душе))
2. user1669221 15 03.10.23 23:57 Сейчас в теме
(1) Спасибо за комментарий! Хорошая мысль.
Да, бизнес и ИТ прорастают друг в друга. Раньше ИТ был сервисом для бизнеса, сейчас - необходимая составляющая. Вот относительно поддержки в актуальном состоянии - в идеале-то да, нужно. И, по крайней мере, пока не устоялось - необходимо. Ибо изменения нуждаются в отслеживании. Но трассировка на детальном уровне очень трудозатратна. Поэтому уровень отслеживания - отдельный вопрос.
Оставьте свое сообщение